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