Return to BSD News archive
Received: by minnie.vk1xwt.ampr.org with NNTP id AA7506 ; Fri, 22 Jan 93 11:45:51 EST Xref: sserve comp.org.sug:627 comp.org.usenix:3171 comp.unix.wizards:28315 comp.unix.bsd:10289 Newsgroups: comp.org.sug,comp.org.usenix,comp.unix.wizards,comp.unix.bsd,news.sys-admin Path: sserve!manuel.anu.edu.au!munnari.oz.au!uunet!gatech!news.byu.edu!ux1!fcom.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (A Wizard of Earth C) Subject: Re: IMPORTANT: POSIX threatens our use of lp/lpr and friends Message-ID: <1993Jan21.213838.9374@fcom.cc.utah.edu> Sender: news@fcom.cc.utah.edu Organization: Weber State University (Ogden, UT) References: <C15sst.JqA@ra.nrl.navy.mil> Date: Thu, 21 Jan 93 21:38:38 GMT Lines: 92 In article <C15sst.JqA@ra.nrl.navy.mil> Ran Atkinson <atkinson@itd.nrl.navy.mil> writes: > The IEEE has a group called "POSIX" that is working on UNIX-related >standards that eventually go to ISO and have a strong impact on what >the UNIX systems that we all use look/behave like. [ ... ] > Now another subgroup of POSIX, namely POSIX.7 which works on system >administration stuff, has proposed standardising printing commands and >interfaces based on the PALLADIUM software developed by certain firms >of the Closed Software Foundation. They propose to do this despite >the widespread use of lp/lpr/lprm/lpq/lpstat/lpadmin within the UNIX >world. If they succeed, you may expect that your existing printing >commands WILL eventually go away and be replaced by this Palladium >stuff. We users and administrators will lose big time if this >marketing ploy within POSIX succeeds. > > The Palladium supporters maintain that it was developed and used at >MIT. However, when someone else from NRL went up to investigate this >first hand, he found out that it is not widely used, that MIT disowns >Palladium, and that a number of parts of MIT removed Palladium because >it was unusable. If this becomes the standard, we're all in trouble. Palladium is out of Project Athena, based at MIT and supported, at least initially, by DEC. This is the same genesis as the X window system. Note the distinction between this and official support for Palladium by MIT (I don't know if such support exists or not; it's irrelevant to the statement). A lot of Palladium information and, I believe, a reference model, is available from export.lcs.mit.edu, the base archive for releases from the work done by Project Athena, including all new officially sanctioned versions of X. While not actually endorsing Palladium personally, I don't think the purely political statements present in this "call to arms" should be taken at face value by the majority of readers. Palladium, as a research project, has a lot to offer in terms of print technology, including what I believe to be it's best contribution: a programmatic interface to the print subsystem. Currently, there is no way within the "accepted practices" of UNIX to exercise queue controls, redirect jobs, or easily distribute printing facilities between BSD and SVR4 systems (SVR4 is abominable even in a homogenous environment). Yes, there is the difference in queuing model (push vs. pull), but this enables remote servicing of quese and the distribution of print responsibilities (ie: a 300lpm and 600lpm printer servicing the same queue will not cause the same number of jobs to be enqueued to both so as to leave the 600lpm printer idle). Currently, one is hard pressed in UNIX to cause two printers to service the same queue, and, in fact, such juggling usually requires complex filtering if it is done at all. Just like X, Palladium brings a lot of VMS to the table (the call-back functions, service routine registration, library implementation of of the main control-flow mechanism, XtMainAppLoop(), and terminolgy "server" for display device are all "VMSisms" of X). There is no need to "throw the baby out with the bath water", as it were, when talking about Palladium. I think the term "common practice" when applied to UNIX printing fits only at the gross level. One need only examine a SPARCPrinter or NeXT printer or the complex, non-standard daemons needed to make them run to see that this is true. Again, I personally am not associated with MIT or Project Athena, and do not endorse Palladium; but neither do I endorse existing UNIX print services on the single issue of the fear of change. It may be that Ran has had a bad experience with some Palladium implementation; if so, I would be much more interested in a description of the experience than a call for dismissal of the software on his say-so... even if I knew which particular implementation of Palladium had bitten him. Either way, a standards vote should be based on a well-informed opinion, and Ran has provided us with his opinion, and not the information he used to reach his conclusions. I would not vote against (or for!) something without sufficient information to draw my own conclusions. Terry Lambert terry@icarus.weber.edu terry_lambert@novell.com --- Any opinions in this posting are my own and not those of my present or previous employers. -- ------------------------------------------------------------------------------- "I have an 8 user poetic license" - me Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial -------------------------------------------------------------------------------