Slashdot Mirror
Apple Releases CUPS 2.0
kthreadd writes: 15 years after the release of CUPS 1.0, Apple has now released version 2.0 of the printing system for GNU/Linux and other Unix-style operating systems. One of the major new features in 2.0 is that the test program for ippserver now passes the IPP Everywhere self-certification tests. Also, they've made an interesting blog post looking at the past and future of printing. Since the first major release in 1999, printing has become much more personal. Printer drivers are going away, and mobile usage is now the norm."
Printer drivers are going away
It's about time
"First they came for the slanderers and i said nothing."
Apple is not the developer of CUPS. Apple bought CUPS back in 2007 and hired its main developer.
CUPS is an example of the sort of hairy mess that open-source developers don't like to deal with, like OpenSSL. It was the inspiration for Eric Raymond (the main guy of the Open Source movement) to scold the OSS community back in 2004. I think Eric Raymond's ire is misplaced; CUPS was uniquely horrible back then. But printing in Unix has always been bad, and CUPS made it much better than before, so everybody standardized on it.
Have a nice time.
One day someone will try to return a faulty printer to a company that insist they print the return label...
Because it makes the printer a standalone computer and allows usage without the need of any extra driver, therefore not only your mac/pc but any smartphone, game console, electric car, smart rice cooker, etc can use it without support from the actual printer manufacturer. That is particular important as the number of computing platforms is increasing, and the cost to support every single one of them is not small. We've came in to an age that even a dollar ARM cortex M3 CPU can host a web server. Why not use this abundant extra computing power? Security? The incompetence with computers of strangers is not my concern.
...because web protocols are universal and easy to use.
Ask yourself this question. Should I use a standard protocol with tons of tools an an ecosystem to support it or should I use a totally custom protocol to handle everything?
Why you'd need to write custom complicated protocols from scratch for everything always riddled me.
Maybe you think because theres less overhead it's better. IDK, but I reject that premise.
Disclaimer: I work with a bunch of stubborn hardware engineers that sometimes refuse to give up their false permises about software.
Apple is not the developer of CUPS. Apple bought CUPS back in 2007 and hired its main developer.
So... the guy that works on it is hired by Apple, and the project is owned and financed by Apple. Isn't that essentially the same as Apple develops CUPS?
No. If Apple had developed it, it would not have had any command-line interface except for XML files and the "defaults" program, its interfaces would have been proprietary to Apple, and it would have been even more confusingly documented. It would never have become widely adopted across the Unix world, partly because Apple would not have chosen GPLv2. Instead, Lennart Poettering would have been so in awe of it that he would have created his own unstable version of it, which would immediately have been adopted across the Linux distributions to the exclusion of any other printing system, because Lennart is the best programmer and all crashes are everybody else's fault. It would have stabilized when he got bored and started copying another Apple innovation. Like, say, launchd.
CUPS was widely used before Apple bought it. Apple can't turn it into an Apple-like program without causing a user revolt, so it's still very much like how it was before Apple bought it.
Have a nice time.
You've convince me! Your anecdotal experience is enough for me to believe that no one needs to print from mobile devices....
The recent OpenSSL vulnerabilities were just the nail in the coffin. It was more a matter of limited developer resources and the relative difficulty of implementing certification validation with the OpenSSL APIs vs. GNU TLS. (and don't forget we also support SecureTransport on OS X and Schannel on Windows...)
Much better to focus on making support for one popular TLS library on Linux/*BSD than to do a half-assed job for two libraries, one of which has known vulnerabilities and API/forking issues.
I print, therefore I am.
No. If Apple had developed it, it would not have had any command-line interface except for XML files and the "defaults" program, its interfaces would have been proprietary to Apple,
Yes that's why LLVM, Clang, OpenCL, Zero-Configuration, and WebKit only works on Apple machines.
and it would have been even more confusingly documented.
Yes because all open source software is meticulously documented.
It would never have become widely adopted across the Unix world, partly because Apple would not have chosen GPLv2.
Yes Apple would never choose GPLv2 unlike all the other GPLv2 software they've chosen to use.
CUPS was widely used before Apple bought it. Apple can't turn it into an Apple-like program without causing a user revolt, so it's still very much like how it was before Apple bought it.
Yes Apple is EVIL for not completely changing the software they own to be proprietary and they are also EVIL for forking software they didn't own (WebKit). Face it folks, Apple can do no right.
Well, there's spam egg sausage and spam, that's not got much spam in it.
Because then you have to write a front-end GUI for every OS out there -- Linux (all 200 flavors of it, because, you know..), Windows, MacOS, Android, iOS, Blackberry, Canon DSLRs, etc., etc.
It turns out, writing your GUI on top of HTTP is really nice, and means you just have to expose it, and let the browser on the existing OSs take care of the hard work of drawing the button on the screen.
IPP doesn't use XML, it uses a (flat) binary message encoding. I imagine that had IPP been developed a few years later things would have been different... And while it definitely supports what is needed in the enterprise, it also satisfies the consumer space - ~500 million printers in service today (from consumer inkjets to big iron office copiers) support IPP, as does *every* consumer and enterprise computer and mobile device (billions of devices). IPP scales well.
The problem with LPRng was that it was a mess of scripts and hacks to make a variety of printers work. Every "driver" worked differently, and (having spent a fair amount of time with it 20 years ago) making it all work without an expert supporting it was basically impossible. It continued to use an extended version of the LPD protocol (which has nothing other than an informative RFC to document it, with most implementations varying from the RFC in some way) and did not address some pretty basic security issues like hiding job information from other users.
Back in 1998 there was little support for standard languages or doing a proper protocol so that you could monitor a printer's state or cancel a job. Vendors used proprietary languages and protocols to lock you into their drivers, their platform, their products. The whole point of CUPS was to define a standard interface with standard options for drivers while providing a better security model. Yes, that did make it more complicated than LPD/LPRng, but that complexity was needed since printing is *hard* and the software needed to support it is non-trivial. IPP was chosen as the underlying protocol and model because it offered everything needed from regular users to enterprise.
Ultimately CUPS succeeded because it allowed people to print without becoming experts. It allowed Linux distributors to actually support printing, and for printer manufacturers and third parties to provide drivers that "just worked". And it did it using public standards and the very UNIX-y interface of piped commands.
While CUPS continues to carry some old baggage around to keep supporting old printers, the day will come when that is no longer necessary and a leaner version (possibly based on the ippserver code) will be able to replace it. Today the economics favor printers implementing common, open standards so that all platforms can support them without extra, expensive development. Within a few years, it should be possible to retire printer drivers entirely.
I print, therefore I am.
The web server serves as a non graphical front-end too.
You can ssh into the piece of crap computer with parallel port laser printer attached, and run elinks from there.
That's the power of web 1.0 for you.