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."
I haven't turned on my printer in 5 years.
The future of printing is that tablets will make it obsolete,
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.
www.cups.org top-of-page for me has links/dropdown-menus/etc as follows: CUPS.org Login Blog Bugs Help Lists [gap] [Searchbox] It's as if someone at some major computer company didn't think about portability among browsers (or smaller displays, or whatever other assumption they made) that causes that other link not to appear (or render off-screen or be hidden behind some other element)
Personally, I never got why the Open Source companies didn't get behind a project like LPRng. In the early 2000s, LPRng was awesome. It was basically an lpd on steroids. It worked like LPD and read printcap, but had support for pretty much any printing protocol, filter, access control lists, quota system, etc. The syntax of the configuration file made managing large site a breeze.
But you see, the open source companies like RedHat decided that simple printcap syntax was too complicated, so they had to throw away LPRng and switch to a significantly more complex syste like CUPS, just because it has a nice GUI and all that.
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.
CUPS 2.0, girl 1
captcha: quantify
Yes, and we use mainly laptops, projectors and large TVs for the video-conferences.
The only paper I use is the one I write on with a pen. No printer there.
What exactly do you use a printer in an office nowadays? Do you print your mails? Do you print Power Point slides? Excels?
No, wait. Trying to imagine your office I found one use I make of the printer. I print flight tickets for work trips, in case my phone dies on the path to the airport.
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....
True, but when we're talking about an office environment producing word processed documents, spreadsheets, printing emails etc., even hardcore old school unix fans generally don't want to drop down to a shell to manage a print queue. It's one of the many tasks that a GUI is well-suited to and usually quicker to work with.
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.
OpenSSL is also incompatible with GPL, so projects like CUPS need to ship with an exception.
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.
If you logged in, the system would happily remember your preference. When you tell the system that you don't want to be remembered, don't blame it for not remembering you.
You're special forces then? That's great! I just love your olympics!
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.
He should have said Apple is not the "original" developer of CUPS which is true. They are the current developer and owner of CUPS.
Well, there's spam egg sausage and spam, that's not got much spam in it.
LLVM and Clang were developed at the University of Illinois.
And Apple hired the team that developed LLVM to continue to develop it further. Just like CUPS. As for Clang, it was developed originally by Apple to work with LLVM because Apple had performance and philosophical issues with gcc.
OpenCL is a standard, not a program.
OpenCL standards for Open Computing Language. It is also a standard as many companies have adopted it. That's like saying C99 isn't language but a standard.
Zeroconf is a standard, not a program.
Again, because something becomes a standard does not mean it isn't used for what it was originally designed.
WebKit is a fork of KHTML from the KDE project. Try again.
Originally, WebKit was based entirely on KHTML. As development as continued, it is bears little resemblance to the original code. Apple has chosen to continue to release as open source even parts they were not required to do.
Well, there's spam egg sausage and spam, that's not got much spam in it.
I will admit there are two things still missing.
There is quite a bit more than two things missing though I agree with the deficiencies you identify among others.
Job instructions can be kept in text files that can be pushed to tablets. Guaranteeing that every person has updated instructions.
You REALLY do not want tablets on most manufacturing floors. The products we work with would trash a tablet in about a week if not sooner and we don't even do anything especially messy. Furthermore that would require buying an expensive computer for every worker on our shop floor, many of which would, ummm... disappear. What we do is keep the Controlled master copy online and then print a reference copy at the beginning of each job. The reference copy then circulates back to engineering or other parties that need it and the master controlled copies get updated for the next job. Works quite well actually.
Tablets have a variety of problems for document management:
1) The problem you mentioned that you cannot effectively annotate documents. In manufacturing, work instructions frequently need to be updated, annotated, etc. People are working on the problem but there is no universally practical solution imminent that I'm aware of.
2) Tablets break and get stolen. My wife works in a doctor's office and they use ipads for documenting patient data (good use of them) and they've had several of them stolen and one dropped and broken. You can drop paper all day long and it won't break.
3) If the software on the tablet you are working with doesn't fit your need it's a much bigger problem to fix than just modifying some paper forms.
4) Tablets are hugely impractical in a dirty production environment. Greasy/dirty fingers and tablets don't mix well.
5) Tablets require either buying or developing software to accommodate most work flows. This can be a very expensive proposition.
6) Tablets are a capital expense that has to be depreciated.
7) Most tablets are designed with consumer markets in mind rather than business needs. They are hard to lock down tightly if needed.
I can keep going. I think tablets are going to make huge inroads over time but anyone that thinks they will eliminate paper from offices is delusional.