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."
If anything, printing has not become more personal, not mobile. All I see used in practice these days are huge office high performance machines, you know, the ones that can spew 100 pages per minutes, with documents being sent to them from real computers.
The mobile devices (smartphones and especially tablets) made electronic documents viable and portable, so nobody prints things from their phones or tablets - they already have a presentation of the document, a paper copy is not needed. Definitely there is no smartphone to printer workflow at homes.
https://www.cups.org/software.php
Was that really that hard?
Your geek card is void. Return it asap.
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.
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.
It's a classic 'responsive' layout that probably looks great at standard widths, but in between weird things happen, such as buttons just disappearing. I've edited many Wordpress themes that have this issue and I've been generally astonished that developers think that it's OK for UI elements to just disappear. It's also stupid that the CUPS website has their download button only appear as a top menu item and as a 'call to action' type button. It should also be there as a standard anchor in paragraph text since it's kind-of important.
Calm down, GnuTLS supports SSL, they've just decided that they're happier using GnuTLS as their encryption backend.
I think the keyword there is companies. The main reason for CUPS is support for IPP, a particularly enterprisey protocol. I could tell that it's enterprisey because it's full of XML and I couldn't figure out how it's supposed to work. Once I got printing to work, I didn't bother to look further into it. Printing is just an occasional hassle for me.
Of course, once CUPS got the momentum, then CUPS got more support, more printer drivers, more GUI front-ends, so right now it's just easier to get a working system using CUPS than LPRng. I'm surprised that LPRng is still seeing development as late as 2012, and the web site apparently got tweaked in March this year.
Have a nice time.
not exactly, the web interface is just secondary, mostly because it doesn't allow for automation.
The canonical way are lpstat, lpadmin, lpoptions and friends
CLI paste? paste.pr0.tips!
...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.
GnuTLS is just one of the supported TLS toolkits. It uses the Security framework on OS X, and SChannel on Windows.
You've convince me! Your anecdotal experience is enough for me to believe that no one needs to print from mobile devices....
CUPS was horrible then, but Linux printing in general was about 15,000x times more horrible with LPD/LPR being the standard and leaving you with pretty much the choice between a postfix printer (which was pretty pricey until the mid-'00s) or an Epson dot matrix printer. There were a handful of print solutions but they were either very expensive or totally sucked.
CUPS made printing on Linux mostly painless.
The Christian Right is Neither (Christian nor right). See: Matthew 23, Matthew 25, Ezekiel 16:48-50
Me too! And I do it all the time.
No more, thank god.
This signature intentionally left blank
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.
Our office has pretty much replaced laptops with iPads for 90% of the people. They didn't need a portable device for anything other than checking their calendar, email and basic web browsing (since almost all of our apps are now designed for the browser, we don't need custom, PC based apps anymore). It turns out, when you do that, those people start to demand to be able to print their emails, web pages, etc. from those mobile devices.
And this is a growing trend. Look at all the business people carrying around iPads / Tablets in favor of heavier laptops.
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.