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ä.