Return to BSD News archive
Received: by minnie.vk1xwt.ampr.org with NNTP
id AA7437 ; Fri, 22 Jan 93 11:44:47 EST
Xref: sserve comp.org.sug:623 comp.org.usenix:3164 comp.unix.wizards:28299 comp.unix.bsd:10264
Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!howland.reston.ans.net!paladin.american.edu!news.univie.ac.at!hp4at!mcsun!uknet!comlab.ox.ac.uk!dominic
From: dominic@natcorp.ox.ac.uk (Dominic Dunlop)
Newsgroups: comp.org.sug,comp.org.usenix,comp.unix.wizards,comp.unix.bsd
Subject: Re: IMPORTANT: POSIX threatens our use of lp/lpr and friends
Summary: Those friends deserve to be threatened
Message-ID: <1993Jan21.100223.17722@onionsnatcorp.ox.ac.uk>
Date: 21 Jan 93 10:02:23 GMT
References: <C15sst.JqA@ra.nrl.navy.mil>
Followup-To: comp.std.unix
Organization: British National Corpus, Oxford University, GB
Lines: 62
Originator: dominic@onions.natcorp.ox.ac.uk
[Sorry about all this cross-posting. The correct forum is the one
group to which the posting to which I'm replying was not sent:
comp.std.unix, a moderated group. If you reply to this posting,
please consider directing discussion to that group. Thanks. DD]
If you want a point-by-point reply to Ran's (IMHO over-heated)
whistle-blowing, hit 'n' now...
At a UK Sun User Group meeting earlier this month, a Sun Distinguished
Engineer (whom I shan't name, as he's eminently capable of self-
publicity, should he feel it appropriate) admitted that there were
just two things in Solaris 2.1 that he'd have to say he was
embarrassed about. One of these was the printing system. With
Solaris 2, Sun has switched from Berkeley-descended lpr to
AT&T-descended lp. Problem is, ``lp is not better. It's just
different.'' Having used both, I have to agree. There's something
broken here, and I think POSIX is right to set out to fix it.
When compared with the printing systems found in proprietary,
business-orientated environments, the lack of controllability, security
features, forms control and resilience of both lp and lpr are all too
noticeable. (And I didn't even mention issues of network
transparency.) If I'm printing cheques using either system, and
something happens to the printer in the middle of the run, how can I
resume the job such that every cheque that should have been printed is
printed exactly once? You tell me. (OK, then. I'll tell you. If
you want to print cheques, you do it on an unspooled printer, driven
directly by the application. By bypassing lp or lpr, you're in with a
chance. Even so, you'd better be careful if the printer has an
internal buffer of any size.)
(Oh. You're in science, medicine, or engineering, not commerce?
s/bar-code stickers for your randomized samples/cheques/
)
Some UNIX implementations (for example, NCR's and, I believe IBM's)
have provided proprietary alternatives. But that's their problem:
they're proprietary, and have not found widespread acceptance. Again,
POSIX ought to be the solution, by providing a non-proprietary,
consensus answer.
Whether POSIX will manage it is another issue: the ``tar wars'' of old
bear many points of similarity with the current debate: both tar and
cpio are manifestly inadequate -- although their wide use is proof
that neither is totally useless. I believe that POSIX has been trying
for eight years to come up with a standard specification for a better
and more complete alternative... Hopefully, this experience will
inform the development of a standard print-spooling system.
As for lp being threatened, it ain't: lp (albeit in a somewhat
loosely-defined form) is specified in 1003.2, so it's going to stay.
(Why is the specification loose? Partly because it's really the
common subset of the features of lp and lpr, so as to keep both camps
happy. Well, happyish.) So, for users, life should get better, not
different, as POSIX addresses the administrative support for printing.
For administrators, yes, life will get different. But, if 1003.7 does
its work well, life should also get a whole lot better, provided that
the standard properly addresses those areas where existing tools are
inadequate. We should be supporting POSIX in that effort.
--
Dominic Dunlop