*BSD News Article 12087


Return to BSD News archive

Xref: sserve comp.org.usenix:3270 comp.unix.bsd:11571 comp.org.sug:654 comp.os.386bsd.misc:50
Newsgroups: comp.org.usenix,comp.unix.bsd,comp.org.sug,comp.os.386bsd.misc
Path: sserve!manuel.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!bogus.sura.net!udel!intercon!psinntp!uuneo!sugar!peter
From: peter@NeoSoft.com (Peter da Silva)
Subject: Re: How to vote on POSIX Printing
Organization: NeoSoft Communications Services -- (713) 684-5900
Date: Mon, 1 Mar 1993 11:50:46 GMT
Message-ID: <C37Kwn.Hx5@sugar.neosoft.com>
References: <C36JrI.E8K@ra.nrl.navy.mil>
Lines: 20

In article <C36JrI.E8K@ra.nrl.navy.mil> atkinson@itd.nrl.navy.mil (Randall Atkinson) writes:
> Palladium was at one time widely installed at MIT, but large
> portions of MIT removed it because Palladium was unusable.  Palladium
> is significantly different from the existing practice of System V's
> "lp" and friends and is also different from the existing practice of
> BSD's "lpr" and friends.

Actually, Palladium (based on the papers I FTP-ed on the subject) appears
to be a derived at least in the design from Berkeley "lpr". It has all the
same limitations, as far as being strictly a *print* queue manager, as lpr,
and only slightly improves its extensibility in the area of file formats
and conversions. It seems mainly of interest to very large networks that are
more-or-less homogenous. It is not, as some have claimed, a general batch
queue mechanism, and I don't understand why Posix has even bothered to assign
a whole committee to print queueing, rather than queue management in general.
-- 
Peter da Silva.  <peter@sugar.neosoft.com>.
 `-_-'   Oletko halannut suttasi tänään?
  'U`    
Tarjoilija, tämä ateria elää vielä.