Comment by ValdikSS
17 hours ago
Spent about 2 years improving printing and scanning stack of Linux: CUPS, SANE, AirSane, as well as some legacy drivers, and also x86 proprietary driver emulation on ARM with Box86.
Even that "modern" printing stack in Linux is 20+ years old, there's still such an unbelievable amount of basic bugs and low-hanging-fruit optimizations, that it's kinda sad.
Not to mention that it still maintains ALL its legacy compatibility, as in supporting ≈5 different driver architectures, 4 user-selectable rasterizers (each with its own bugs and quirks).
The whole printing stack is supported by 4 people, 2 of whom are doing that since the inception of CUPS in 1999. Scanning is maintained by a single person.
Ubuntu 26.04 LTS is expected to be the last version with CUPS v2. CUPS v3 drops current printer driver architecture and introduces proper modern driverless printing with the wrapper for older drivers. Many open-source drivers are already use this wrapper, but expect a huge disarrangement from the users, as none of the proprietary drivers would work out of the box anymore.
Do you care about printing? Want to improve printing & scanning stack? Contact OpenPrinting! https://github.com/OpenPrinting/
This is awesome, thank you for doing this work; it’s not glamorous but it’s a key feature to making computers productive.
I know it’s not a popular opinion here but I think that Windows has two killer features that are always overlooked- the standard print dialog (and all the underlying plumbing), and the standard file dialog (at least until Windows 8).
The ability to print and to interact with files, that just works, without having to retrain people every time a new OS comes out, and without having to reprogram your apps or write your own drivers and/or UI, is incredibly important.
Yes, I know Linux and Mac have the same, but IMO Windows was light years ahead for decades, and is still more consistent and easy to use.
Was going to say the same thing, I'm not a big fan of Windows but the printing Just Works. Having read the OPs explanation of why CUPS is the way it is, yeah, now it makes sense.
Maybe CUPS needs a Heartbleed-scale problem to motivate more support.
Mac has always had print to PDF from the start, I'm not sure if even the latest windows comes with that OOB. I'm sure Linux is the same (as in the same as Mac).
Any relation to this project? https://www.opentools.studio
Nah, I got into printing because nobody made a commercially available print server, and I ended up making my own, with all the involvement in the stack in the process.
I wish Openprinter luck, as it has been announced in the end of September but nothing out there yet, not even the crowdfunding campaign.
Ah dang, I was hoping. I'm super interested in that and love that you're modernizing something BigTech doesn't seem to care about.
Great initiative. I wonder, how likely is it for a complete beginner to break their own printer or scanner by making a mistake in driver implementation? Or is it possible to work on hardware support without having a physical device? I assume it is impossible to test each and every one printer and scanner, so there is probably some clever tricks there, right?
I work mostly with the old microcontroller-based cheap consumer ("GDI") USB models circa 2000-2010, these are hardly possible to brick with software, as some of them even don't have a firmware and expect the PC to upload it on each power on sequence.
The hardware safety mechanisms are usually robust (USB communication is handled by "Formatter Board", all the mechanical stuff is in the "Engine Controller" power).
Newer Linux-based models have filesystems, software, and vulnerabilities, printer hacking on Pwn2Own is an every year common occurrence. These could be permanently bricked by the software in a common sense, and would require a firmware reflash using the bootloader or external means.
>Or is it possible to work on hardware support without having a physical device?
Absolutely, but for me this is very inconvenient—like the debugging over the phone.
Sometimes the bug is as low-level as in the USB stack: https://lore.kernel.org/linux-usb/3fe845b9-1328-4b40-8b02-61...
>I assume it is impossible to test each and every one printer and scanner, so there is probably some clever tricks there, right?
Not much, unfortunately. There's ongoing work on modern (driverless) printer behavior emulation, but it is under heavy development and not ready yet: https://github.com/OpenPrinting/go-mfp
Nothing for the older printers and scanners which require it's own driver, of what I'm aware.
You're not actually telling a modern printer: "step this motor so many times to move some assembly so far this way", or "turn on so much current in such and such circuit" or whatever. The driver doesn't have enough responsibility for such things to be able to break anything.
A printer driver is something like a protocol converter. Roughly speaking, it binds some printing API's in the some kind of printer framework or service on the host to the right language (which may have vendor-specific nuances even if it is some kind of standard0.
Thank you. I have thrown printers out the literal window.
Ah, so you're Russian then. If you were American you'd have shot them.
He's our hero
> Thank you. I have thrown printers out the literal window.
I have literally thrown one of those "winmodems" [1] out of the window back in the days. I then went out and drove with my car on it. I then put it in a bench vise until its PCB shattered to pieces. Utter destruction, much to the amusement of my brothers.
These were the days.
And big thanks to GP for his work of CUPS / Linux printing.
[1] https://en.wikipedia.org/wiki/Softmodem
I miss when hatred for technology was tangible.