Re: The future of lpr and lpd

On 20 Feb 2026, at 13:39, Dag-Erling Smørgrav wrote:

> Hi,
>
> Due to low code quality, known bugs, and a general lack of interest 
> over
> the past several decades, we are currently considering retiring the
> entire lp* suite (lp(1), lpc(1), lpd(8), lpq(1), lpr(1), lprm(1),
> lptest(1), pac(8)) from base.

As I noted a few weeks ago in a reply to in a different thread on 
`lpr`/`lpd`, I did quite a lot of work on FreeBSD's lpr/lpd back in the 
early 2000's.  I made lots of commits, with lots of feedback from Bruce 
D Evans and Garrett.  Up until about the mid-2010's I used FreeBSD's 
`lpr` as part of a "printing empire" that I had built up at RPI starting 
back in 1990.  I compiled my version of `lpr` on several unix platforms. 
  In its heyday, my print servers accepted print jobs from over a 
thousand clients running a variety of OS's.  RPI made enough money from 
the printing empire that I could drop whatever I was doing to work on 
`lpr` whenever I wanted to.  If anyone had contacted me with any 
problems, I could have worked on those problems.  There may have been a 
lack of interest in people **using** `lpr` on FreeBSD, but if issues had 
come up I could have worked on it.

I'll note that while I did a lot of work on FreeBSD's version of 
`lpr`/`lpd`, there are a lot of features in my own version of those 
which I still haven't had the time to incorporate in FreeBSD's version.  
That's because the code which implements those features is a mess, and I 
need to refactor it before letting anyone see just how badly I can code 
when I'm a hurry because some Dean has some output he needs printed 
before 8am the next morning.

In the later 2010's RPI decided to move from my printing empire (where 
all the print-servers were unix machines) to any new printing empire 
which had print-servers running on MS-Windows.  This was understandable 
given that I was getting close to retirement age.  There are several 
ways I think this has resulted in a few steps backwards, but maybe I'm 
biased.

> Nothing is changing in FreeBSD 14.x or 15.x except the addition of a
> deprecation notice to the documentation.  However, it is likely that
> these utilities will be gone in FreeBSD 16.0.
>
> It would be extremely helpful if those of you who are using base lpr /
> lpd today could take the time to try out the lprng package / the
> print/lprng port (which should be a drop-in replacement) and let me 
> know
> if there is any loss of functionality.

In 2000's I also looked into working with both LPRng and CUPS.  The 
original developer of LPRng (Patrick) had a staggeringly large wealth of 
experience with all the absurd glitches and oddities of individual 
models of printers, and LPRng includes all kinds of special hooks to 
handle those issues.  But the code was also a confusing and convoluted 
mess.  Patrick was great at coming up with specialized fixes for 
whatever problems people were having with specific models of printers, 
but I found him hard to work with as a developer.  I could point to 
specific `if` clauses which had bugs in them — bugs that I was running 
into while testing — and he'd insist that the combination of 
circumstances which would trigger that bug could never happen in real 
life.  This even though there would be other `if` statements in the same 
routine where it was clear that those events did happen, and even though 
I was **actively** running into crashes due to those bugs.  Nope.  He 
was the expert, and I was the dummy.  He'd refuse an update where I 
added a check for some pointer being nil, because he was certain it 
couldn't possibly be nil.  A five-line update which couldn't possibly 
cause any new problems — Nope!  While I haven't looked a LPRng in 20 
years, I suspect users will find it fails in weird ways in unusual 
circumstances.

I also took a serious look at CUPS for a while.  After all, it supports 
several aspects of printing which my printing empire did not support.  
That was some time ago, so my experience with it is out-of-date.  
However, back in the days I did look at it, there were enough problems 
in the code (if it is used in high-volume situations) that I decided 
against using it.  In one of the other emails from Greg Lehey, he 
mentions that Theo commented on CUPS as:

>> "Well, let them enjoy cups.  I have studied that monster a few times. 
>>  It is a huge piece of software lacking any attempt at a security 
>> architecture, and a culture around it that will never make changes."

While I an hesitant to be that emphatic about it since I haven't looked 
at CUPS in at least a decade, that certainly matches the opinion I had 
of CUPS back when I did look at it.  I never did try to work with the 
CUPS developers as much as I tried working with Patrick.  I was not 
encouraged by seeing how those developers (back at **that** time) worked 
with the requests that I saw other people making.

In my own opinion, both LPRng and CUPS are probably fine if you're 
talking about no more than a few people working on some unix machine, 
and all they need is to send jobs to one or two printers.  But if you're 
running print-servers which have to accept print jobs from thousands of 
other computers only to turn around and print then on a wide variety of 
devices, then you'll run into mysterious failures which you'll never 
have the time to track down.  And it doesn't help that every 
manufacturer of printers is an idiot who can't be bothered to figure out 
**their** side of a network connection.

The challenge is that most people writing alternatives to `lpr`/`lpd` 
are not aware of some of the subtle issues in how the protocols work.  
Here is one such detail.  In protocol of `lpd`, there is a "control" 
file and one or more "data" files.  In order to process a job, the 
print-client software obviously has to start by reading in the control 
file.  Many implementations therefore immediately transfer the control 
file to the other side of the connection (aka "the print server").  
There are multiple problems that this can cause if the print server is a 
busy one accepting many jobs from many clients.  BSD's `lpr` sends the 
data files **first**, and then sends the control file only after all the 
data files have been successfully transferred.  There are very good 
reasons for that, but those reasons are not documented anywhere.  If 
your print server is receiving print jobs from many clients, then any 
client which sends the control file first can trigger some very weird 
problems in certain situations.  Since this triggers problems on the 
print **server**, I added code to FreeBSD's `lpd` so that it does a 
little dance when receiving the control file in case it is receiving a 
job from a **client** which does not understand these issues.

There are print queues setup at RPI which exist for no other reason than 
some models of printers will behave in bad ways if two computers send a 
job to the printer at the same time.  You might think that it must be 
extremely rare for that to happen, but consider a printer which runs out 
of paper while processing a large print job.  That print job remains 
active while some poor sap runs around the building trying to find a 
fresh ream of paper.  In the meantime, there are other people who might 
want to send jobs to that printer, and who don't realize it is out of 
paper.  Imagine a dorm, for instance, where you have 30 people on a 
floor who share one printer which is in a room at one end of the 
hallways.

The perceptive reader of this email will notice that I haven't offered 
any better solution.  IMO there is no good and quick fix for the current 
state of printer-supporting software on open-source unix OS's.  I'm just 
saying that of the options which are available, there will be someone 
who will have very good reasons to be unhappy with the result no matter 
which option you pick.  Sorry that I couldn't write up a more cheerful 
message.

And the reason for that gets back to DES's original comment:  There 
really has been a general lack of interest in printing for at least two 
decades.  And not just a lack-of-interest in **supporting** packages 
like `lpr`, `LPRng`, and `CUPS`, but a lack of interest among 99% of 
users.  All they want is "Can I send one print job a week to some dumb 
printer that I bought for $200?".  They'd use the `cat` command if they 
thought they could get away with it.

I do remember some effort (probably in the mid-2000's) to write up a new 
all-encompassing and standardized architecture to handle printing.  It 
included input from many of the main computer companies (both hardware 
and software, IIRC).  I was on some mailing list(s) for it.  It spent 
years writing up the perfect architecture, and ended up with something 
which was so complicated that it could never be implemented.  The 
"second-system syndrome" on steroids.  Sigh.

And let me close by saying I still miss exchanging emails with Bruce 
Evans.  He could be pretty intense and was obsessed with all the minute 
details of programming ... which is right up my alley.  Okay, sometimes 
that could also be very frustrating, but still!  He was quite an 
impressive guy to work with.

> DES
> -- 
> Dag-Erling Smørgrav - [email protected]


-- 
Garance Alistair Drosehn           =   [email protected]
Lead Developer @rpi               and        [email protected]
Rensselaer Polytechnic Institute;             Troy, NY;  USA