PSA: lpd/lpr will be removed from FreeBSD

1984 all over again? Friggin' enough babysitting and nannying - until you discover just how many users don't know how to think critically, in their own best interests, and actually need somebody to step in and call the shots for them...
:rolleyes:
 
astyle said:
1984 all over again? Friggin' enough babysitting and nannying - until you discover just how many users don't know how to think critically, in their own best interests, and actually need somebody to step in and call the shots for them...
:rolleyes:
Click to expand...
Looking at the mailing list, I think they are deciding what "shot" is the correct one. So far two things:
  1. Overly modularise and reduce things. Typical developer mindset which creates DIY Linux-like platforms rather than operating systems.
  2. Maintain the status quo which accrues cruft and legacy
I lean towards the latter because find Linux an utter mess. However as people flee Linux, they do take the mindset with them which is why FreeBSD may just become a kernel in future if things keep getting stripped.
 
kpedersen said:
I lean towards the latter because find Linux an utter mess.
Click to expand...
I lean toward the later because I am not developer, not distribution architect or such.

I just use the computer, I like UNIX with BSD flavor.

And if one wants, can also dismember FreeBSD and mix it with other software.
 
Whoa the lpd/lpr discussions made it over to the forums from mailing list 👀

I have to study for the semester what is the gist. The context is probably older than me is my guess
 
kpedersen said:
Looking at the mailing list, I think they are deciding what "shot" is the correct one. So far two things:
  1. Overly modularise and reduce things. Typical developer mindset which creates DIY Linux-like platforms rather than operating systems.
  2. Maintain the status quo which accrues cruft and legacy
I lean towards the latter because find Linux an utter mess. However as people flee Linux, they do take the mindset with them which is why FreeBSD may just become a kernel in future if things keep getting stripped.
Click to expand...
Do you know which mailing list and month by chance? I checked hackers, and current for march and have not been able to find it so far.
 
Jose said:
Hm, no one has addressed Lehey's question. Maybe they took the discussion to a private channel.
Click to expand...
Maybe. Though I doubt anything so vulnerable was found in a disabled by default binary that they need to be discreet. Its more likely they don't have a strong enough rationale to even present to the OpenBSD guys for open discussion.

"Old == Bad" isn't particularly insightful. I suspect they are just starting to pick at PkgBase, just as predicted and turning FreeBSD into a DIY/flatpack hobbyist platform.

The following mailing list message will appear within the next 6 months I rekon: "FreeBSD doesn't need 3+ text editors like ed, vi and ex, lets remove them and allow users to choose from ports". And lpd could well be used as a precident argument.
 
rcbsdpge said:
So no one bothered to reference any mirrors of base system to comb over the codebase 🤨
Click to expand...
?

I think many of us have a local snapshot on our machines. No real need for a web link.

Any specific part you recommend combing over? I'm not against the idea. Though I suspect it won't really change Dag's mind because they seem stuck in a rut between not breaking legacy compatibility and... removal before 16-RELEASE.

If only there weren't compromises to be had. Doing nothing or breaking compatibility perhaps? :-/
 
There was mention the codebase is decades neglected. It doesn’t seem like it from the GitHub mirror to me. I should run local tests on my machines

Why do they require a rewrite. I’ll read over the thread again
 
Jose said:
Hm, no one has addressed Lehey's question. Maybe they took the discussion to a private channel.
Click to expand...
Fair point. Are the other BSD’s running lpd/lpr in their operating system. If so, what is the latest there.

kpedersen said:
Whilst I don't disagree in principal (after all, cups is generally needed for most printers anyway), the dependencies pulled in are fairly extreme for functionality simply to replace lpd.



Highlight includes, not one but two python interpreters (naturally)
Click to expand...
I agree that is a big mixed bag of dependencies. Combing over these dependencies zstd-1.5.7_1 is developed by Meta. A bit surprised but not too surprised it’s at FreeBSD port collection.
 
cracauer@ said:
Just FYI, lpd/lpr (the printer tools) will be removed. They are insecure and nobody volunteered to rewrite them.
Click to expand...
Wait, when will they be removed? I use them regularly to print stuff. What will be my alternatives?

I'm not against removing them, but I use FreeBSD as a desktop and do all my daily tasks on it, so naturally I'm in need of printing something from time to time. Recently, I have seen a warning of CUPS being unmaintained, if I remember correctly, but still. I don't know what to replace it with.
 
UJuwMLAx said:
Wait, when will they be removed? I use them regularly to print stuff. What will be my alternatives?

I'm not against removing them, but I use FreeBSD as a desktop and do all my daily tasks on it, so naturally I'm in need of printing something from time to time. Recently, I have seen a warning of CUPS being unmaintained, if I remember correctly, but still. I don't know what to replace it with.
Click to expand...
If you print with CUPS, this does not effect you. This impacts (pun intended) band printers, line printers, teletypes, daisy wheel printers and dot matrix printers. Ink Jet and laser printers should be okay.
 
This is good, because it will force a compliant implementation to come along.
T-Aoki said:
Need fix, or need replacing with secure and BSD-compatibully-licensed implementation.

FYI: Some work seems to be ongoing.
Click to expand...
3 major changes so far in 2026 in response to that mailing list thread, hardly any before this most recently.
Hiroo Ono said:
1. sysutils/LPRng
2. print/cups
Click to expand...
sysutils/lprng is GPL. It didn't work for me on FreeBSD when I tried it: in this case, for an HP printer.
hardworkingnewbie said:
there's also an active fork by OpenPrinting
Click to expand...
It seems to be a Linux Foundation sponsored implementation. CUPS required gmake to build, when the main printing application should use base compilers and tools.
kpedersen said:
CUPS is is a (heavyweight) compromise and workaround, rather than the goal.
Click to expand...
Good, but heavy, that it requires a browser, network settings, and uses lots of non BSD components.
fjdlr said:
I installed HPLIP, and everything works. Some HP printers expose a small internal HTTP API via their embedded web server. So, no more CUPS.
Click to expand...
When I used HPLIP, it required CUPS as a dependency. If you use HP, then that's the driver to use.

CUPS and LPRng have LPR implementations in their own relevant directories.

CUPS needs a lightweight fork which uses BSD components as dependencies. Otherwise, there's a need for a command line BSD replacement for LPR, which is jointly maintained by NetBSD and OpenBSD. LPR uses the description of RFC1179, so this RFC is more important than the old implementation itself.

What is lacking is a Scanner version of CUPS with a browser interface. There was an online mention of one, such as a college hobbyist attempt, but nothing solid.

The mailing list discussions are good.


https://lists.freebsd.org/archives/freebsd-arch/2026-February/001231.html
Some of the issues with lpd cannot be fixed because they are inherent to its design, which cannot be changed without breaking compatibility, which is _the only reason_ to keep lpd. The rest of the world has
moved on to IPP.
Click to expand...
There is no spec. RFC 1179 is not a specification for LPDP, but a
description of how lpd works, written after the fact by a third party
who... didn't understand how lpd actually works.
Click to expand...

CUPS uses both IPP and an implementation of LPR. In the mailing lists as well as in this thread, using the -s option with LPR was also mentioned. The purpose of firewalls and keeping daemons local to protect such applications was also mentioned in the mailing list.
 
sidetone said:
Good, but heavy, that it requires a browser, network settings, and uses lots of non BSD components.
Click to expand...
CUPS can be used without a browser, and with a printer connected by USB (though I've only used network connnections for years). I'm not trying to be argumentative, and I'm sure you're correct about the non BSD part. I have a page that includes using cups without a browser (and covers CLI scanning, though with scanimage) at https://srobb.net/cliscanprint.html I've mentioned it in this thread already,but figure it's worth it as the thread has gone on awhile.
sidetone said:
CUPS needs a lightweight fork which uses BSD components as dependencies. Otherwise, there's a need for a command line BSD replacement for LPR, which is jointly maintained by NetBSD and OpenBSD. LPR uses the description of RFC1179, so this RFC is more important than the old implementation itself.
Click to expand...
This is why I gave the like to your post. It would be good to have a cups-minimal somehow. As a non-coder, I have no idea how much work it would be. And to be fair, cups has greatly improved from the days when we'd say it stood for
Can't Usually Print Stuff. (It might have started its improvement after Apple bought it, though my memory is hazy and I could easily be wrong.)
 
scottro said:
CUPS can be used without a browser, and with a printer connected by USB (though I've only used network connnections for years). I'm not trying to be argumentative, and I'm sure you're correct about the non BSD part. I have a page that includes using cups without a browser (and covers CLI scanning, though with scanimage) at https://srobb.net/cliscanprint.html
Click to expand...
CUPS does have a console interface, though, I haven't been able to configure it that way. Though, having browser accessibility is great. That's a good link. That looks like the equivalent from the command line.

In the past, a leading CUPS page said it required gmake and optionally Avahi for ZeroConf. That may have changed as not a requirement, but stayed as the default on FreeBSD. According to print/cups, it also uses dbus and gnutls. These requirements aren't exactly BSD. I'll settle with Avahi, though it is heavy, because the BSD or Apache equivalents for ZeroConf are difficult, minimal or not there, and also have lacking documentation. To clean up Avahi, they'll fight tooth and nail there, as they'll claim everything is needed for Linux features. Dbus may be acceptable to some extent as well. Though, for some programs, it stays on and clogs up efficiency:for instance dbus processes stop or there are too many, then, I have to use the command line to kill these processes for a restart of the application needing them. There's really no BSD strictly with Apache implementation of CUPS due to currently required dependencies. CUPS is combo Apache/BSD/Linux/LGPL in total build due to dependencies, while it should be all Apache/BSD in build, while obviously retaining GPL2 linking compatibility. Now, the modern version is intended for all OS'es which aren't from Apple, as that version is Apple CUPS.
 
sidetone, that's what that page is, equivalent from command line. All I remember is what I set up with that printer a few years ago. Using nc worked out of the box. I list what I installed to get both scanning and printing working. I didn't have to run avahi. Sane-airscan had a package message that avahi daemon should be run, but I never did and scanning was fine. Though I do have avahi installed. I think it was pulled in by something else. (I see removing avahi-app will remove 99 other packages as well.)
 
You must log in or register to reply here.
Back
Top