Announcing printerd
It is a polkit-enabled D-Bus system service, written using the GLib object system. Although modeled on concepts from IPP (Internet Printing Protocol), printerd is not in itself an IPP server. Its only interface is D-Bus, although the aim is to be able to implement an IPP server on top of the D-Bus API as a separate process. Having a D-Bus interface means that applications wanting to print automatically get to use printerd asynchronously."
Posted May 22, 2012 13:45 UTC (Tue)
by cthart (guest, #4457)
[Link] (12 responses)
Posted May 22, 2012 14:04 UTC (Tue)
by rfunk (subscriber, #4054)
[Link]
I can guess that having a printing system not controlled by Apple might also be a goal, although printerd would still require CUPS drivers.
Posted May 22, 2012 14:21 UTC (Tue)
by aaron (guest, #282)
[Link] (6 responses)
Posted May 22, 2012 15:11 UTC (Tue)
by mbt (guest, #81044)
[Link]
If all your users are sitting at seats around your single host, you don't need network transport for reaching printerd/systemd. It can even wake up your printer when you start printing.
Argh! With all these daemons around, we need an exorcism.
Posted May 22, 2012 15:19 UTC (Tue)
by nye (subscriber, #51576)
[Link] (3 responses)
Posted May 22, 2012 15:35 UTC (Tue)
by drag (guest, #31333)
[Link]
Normally I am happy to see new developments, but I personally really don't understand the point. The 'print spool' itself has never been much of a problem.
It's the printers themselves and the applications needed to properly support print jobs.
Like: I have to print labels in a automated manner on a Xerox Laser using PCL. Or a home label maker. Or if I want to use a Lexmark printer in Linux or the dozens and dozens of things that Linux tends to really suck at.
The task 'Add or remove pdfs from print spool' doesn't strike me as a problem that users had to overcome in the past. Other then the fact that the GUIs for selecting printers and printer features are miserable, tend to be missing controls, and have no consistency.
Posted May 22, 2012 15:39 UTC (Tue)
by gioele (subscriber, #61675)
[Link] (1 responses)
From the dbus homepage:
> D-Bus […] makes it simple […] to launch applications and daemons on demand when their services are needed.
Posted May 22, 2012 23:05 UTC (Tue)
by lindi (subscriber, #53135)
[Link]
Posted May 22, 2012 16:14 UTC (Tue)
by randomguy3 (subscriber, #71063)
[Link]
Although printerd can be on-demand, due to the D-Bus interface. Or it could provide a cups compatibility layer.
> 6. Force everyone to go graphical/PDF, since we don't need to support receipt/invoice/check/line/Braille printers anymore.
Presumably applications where that is relevant wouldn't use printerd's D-Bus interface, but talk to (and require) cups directly.
Posted May 22, 2012 22:01 UTC (Tue)
by raven667 (subscriber, #5198)
[Link]
I don't understand that either. The announcement just has a list of buzzwords but doesn't explain to me the rationale behind this development or how it'll integrate with the system. I'm not sure how this is different from, improves upon or integrates with CUPS which is by far the most widely deployed and most supported printing environment (except for Windows native drivers but that has a non-portable design anyway).
It'd be useful to see a longer form article of the whys and wherefores by the authors of this software instead of the wild and misinformed speculation that is likely to occur given the lack of information.
Posted May 22, 2012 23:22 UTC (Tue)
by lindi (subscriber, #53135)
[Link] (1 responses)
Posted May 26, 2012 14:33 UTC (Sat)
by jond (subscriber, #37669)
[Link]
Posted May 23, 2012 12:34 UTC (Wed)
by nsoranzo (guest, #34668)
[Link]
http://cyberelk.net/tim/2012/05/10/announcing-printerd/co...
Posted May 22, 2012 14:28 UTC (Tue)
by jmorris42 (guest, #2203)
[Link] (10 responses)
Posted May 22, 2012 16:18 UTC (Tue)
by ms (subscriber, #41272)
[Link] (9 responses)
Posted May 22, 2012 17:07 UTC (Tue)
by jreiser (subscriber, #11027)
[Link] (8 responses)
Posted May 22, 2012 17:33 UTC (Tue)
by vivo (subscriber, #48315)
[Link]
to restart a printer do it in maintenaince
Posted May 22, 2012 17:38 UTC (Tue)
by nybble41 (subscriber, #55106)
[Link]
It's in the "maintenance" drop-down list after you select "Printers" and then the name of your printer. Besides "cupsenable", this is also equivalent to:
> lpadmin -p $printername -E
The error behavior is also configurable with:
> lpadmin -p $printername -o printer-error-policy=retry-current-job
or by changing the ErrorPolicy line in /etc/cups/printers.conf.
This is for a more recent version of CUPS (1.5.2), and I'm not sure how well it translates to version 1.4.8. The maintenance drop-down, at least, has been around for quite some time.
Posted May 22, 2012 18:57 UTC (Tue)
by job (guest, #670)
[Link] (2 responses)
I normally just let gs speak directly to lp0, and use lpr/lpd to connect over a network. That does not give me all access to all the bells and whistles of modern printers, but it just works and it has worked for some fifteen years.
Posted May 22, 2012 19:41 UTC (Tue)
by boog (subscriber, #30882)
[Link] (1 responses)
Doesn't prevent a more traditional API also being used.
Moreover, the way printer and peripheral support for Linux is going (in the wrong direction as far as I can see), a general move to embedded web technologies is quite helpful.
Posted May 23, 2012 7:56 UTC (Wed)
by rvfh (guest, #31018)
[Link]
Posted May 23, 2012 11:44 UTC (Wed)
by jengelh (guest, #33263)
[Link] (1 responses)
No, since lp* is out. But there is "cupsenable".
Posted May 23, 2012 22:56 UTC (Wed)
by jjs (guest, #10315)
[Link]
Posted May 26, 2012 23:23 UTC (Sat)
by butlerm (subscriber, #13312)
[Link]
Whatever the rationale is, the default for this on CUPS could hardly be more unfriendly. This sort of thing makes it look like a full employment program for system administrators. No wonder people want to replace it.
Posted May 22, 2012 14:31 UTC (Tue)
by nix (subscriber, #2304)
[Link] (8 responses)
- local AF_UNIX sockets with randomly-assigned names in a fixed directory, with a name exported via an environment variable (the default). Local system only, you're on a remote system? Sucks to be you.
- remote IP connection, not really per-session as there is no automatic port assignment, SSH forwarding or anything else. i.e. you can say
<listen>tcp:host=localhost,bind=*,port=10315</listen>
in session.conf, but what you cannot say is 'assign a port automatically, and export it in an environment variable', let alone 'get SSH to forward-and-proxy a connection to the dbus session bus', which would allow a secure session bus across the network. This is not rocket science -- it's the preferred way of handling X connections -- but as far as I can see D-Bus is incapable of it. Am I wrong?
(Obviously doing this securely would involve -- fairly trivial -- changes to OpenSSH as well.)
Posted May 22, 2012 16:22 UTC (Tue)
by randomguy3 (subscriber, #71063)
[Link]
In the case of printerd, I think it's meant to be a purely local printing framework. If you want a print server, run Cups. Or Samba. printerd can then make use of either of those servers, but applications only talk directly to the local printerd (in the same way they might talk directly to a local character device in /dev, say).
And the announcement does suggest that there will be an IPP interface along soon, which is the right way to do printing over the network, really.
Posted May 23, 2012 12:28 UTC (Wed)
by krake (guest, #55996)
[Link] (4 responses)
Can you explain how SSH can be used to forward Unix sockets other than X11's?
I have been looking for that for years but never found any example on how to do that.
Posted May 24, 2012 0:28 UTC (Thu)
by nix (subscriber, #2304)
[Link] (3 responses)
Posted May 24, 2012 9:31 UTC (Thu)
by hppnq (guest, #14462)
[Link] (2 responses)
Posted May 28, 2012 13:01 UTC (Mon)
by nix (subscriber, #2304)
[Link]
Posted May 30, 2012 1:35 UTC (Wed)
by dkg (subscriber, #55359)
[Link]
Posted May 23, 2012 14:57 UTC (Wed)
by Jluis (guest, #28564)
[Link] (1 responses)
Posted May 24, 2012 0:34 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Posted May 22, 2012 15:39 UTC (Tue)
by bkw1a (subscriber, #4101)
[Link]
Posted May 22, 2012 15:53 UTC (Tue)
by kragil (guest, #34373)
[Link] (1 responses)
I know we all love C, but wouldn't have Vala been the better(as in more productive) choice?
Posted May 22, 2012 18:43 UTC (Tue)
by HelloWorld (guest, #56129)
[Link]
Posted May 22, 2012 16:11 UTC (Tue)
by randomguy3 (subscriber, #71063)
[Link] (14 responses)
It will presumably be able to talk to IPP servers (via the relevant cups driver?), which might either run on the local machine (if you sometimes have more demanding requirements, like receipt printing) or on a remote machine (particularly in businesses, for example).
The issue, of course, is the transition period, where everyone will have to support everything. The announcement suggests that there will be a lightweight IPP server available at some point, which could be used to support CUPS-only applications (but negates the on-demand part of printerd), but applications using printerd's D-Bus interface will also have to support cups (or one of its compatibility modes, like lpr) directly to work on systems that don't have printerd.
Posted May 22, 2012 16:56 UTC (Tue)
by drag (guest, #31333)
[Link] (13 responses)
I don't understand the point of writing less capable software just so that when somebody needs to be able to do what is relatively easily done in any other OS they must rip out your software and/or reconfigure their OS.
> It will presumably be able to talk to IPP servers (via the relevant cups driver?),
Typical 'cups driver' is just a postscript description file.
Postscript is a programming language that is used to instruct the printer on how you want you page printed. Cups will take the postscript from your application and then insert additional instructions to it based on the PPD file (aka 'driver') and your configuration dialogs. Instructions on how to handle ink, line speed, stapling, duplex, etc etc.
This is why you need things like Ghostscript, because CUPS must have the ability to tear down postscript 'documents' and then rebuild them for specific printer models.
Then, of course, there are a large number of printers that do not support postscript, proprietary psuedo-ascii line/serial printers, or printing tasks that require other languages like PCL.
On top of all that modern printers are designed to be really stupid. They tend to no longer understand proper printing languages. Instead they are little more then over-glorified USB accessories were you have a proprietary (as in printer-specific) daemon that is able to take the postscript/pcl/etc instructions and transform them to the device-specific instructions necessary to operate the printer head and emulate a traditional printer device.
All and all even relatively 'basic' printing tasks tend to be fiendishly complicated and require a heavyweight solution.
So unless printerd can replace CUPS in it's entirety there is no point in having it do anything except just being a spool manager that replaces some fraction of CUPS functionality.
Posted May 22, 2012 19:23 UTC (Tue)
by butlerm (subscriber, #13312)
[Link] (12 responses)
This is evidence of a dedicated printer mentality. Why in the world should a typical user configure a 'printer' in order to get a specific print job to print the way he wants it to? Users should have the ability to control all of that from within some sort of print dialog in the application.
>This is why you need things like Ghostscript, because CUPS must have the ability to tear down postscript 'documents' and then rebuild them for specific printer models.
A much saner system for graphical printing would be for applications to use some combination of shared libraries to discover what printers are available, what properties they have, allow the user to configure the specific print job, render (ultimately) through a standard API directly to a printer driver loaded in-process, and send the output of the printer driver to the spooler on a local or remote system.
Then the system wouldn't be in the position of rendering to some baroque programming language, and loading and reinterpreting it into something printer specific. X style process separation for the printer driver could be kept if necessary, but the idea that Postscript should be the lingua franca for communication to a printer driver is positively perverse.
Posted May 22, 2012 20:40 UTC (Tue)
by drag (guest, #31333)
[Link] (11 responses)
Configuring a printer from a print dialog is exactly what I am talking about.
You select color quality, line quality, print speed, stapling, collation of reports, and all that stuff. A person must decide this when printing.
That's 'configuring'.
If you want to be able to print anything other then plain single-sided black and white documents then the ability to edit postscript documents and insert the proper printer-specific control sequences on the fly is a absolute requirement.
Depending on the printer you can send usually postscript directly to it. Over a parrellel port or USB port or over IPP connection. It may need to be rendered into USB control sequences for cheapy ones using a proprietary daemon.
> A much saner system for graphical printing would be for applications to use some combination of shared libraries to discover what printers are available,
So you want to distill the functionality provided by CUPS and Ghostscript (and related filters, tools, and programs) into application libraries and then load that into each and every application? How would that work out well?
> Then the system wouldn't be in the position of rendering to some baroque programming language, and loading and reinterpreting it into something printer specific.
So instead you want each and every application will be in the position of rendering to some baroque programming language, and loading and reinterpreting it into something printer specific.
That seems completely ass-backwards. Typically the OS wants to make things easier for programmers to do by providing common functionality instead of making it worse...
Posted May 22, 2012 21:21 UTC (Tue)
by dlang (guest, #313)
[Link] (10 responses)
That's actually almost exactly what is done today. the "baroque programming language" is postscript.
but we've seen what happens when every program needs to adjust it's document to the printer in question, the result is the windows printing mess where loading a different printer driver can change your document layout drastically.
Posted May 23, 2012 1:23 UTC (Wed)
by drag (guest, #31333)
[Link] (9 responses)
Of course. That's why I _said_ it.
Postscript, in this context, cannot be thought of as a document format. It's a printer control language.
It's wrong to treat it like it's a document. It's a scripting language that instructs printers on how to print out documents. And as such it needs to be edited on the fly and based on the preferences of users in different manners for different printers.
Which is why it's important that you use a centralized program to manage this as much as possible. The program should just tell the daemon that 'I want low quality color collated front to back with pages 1-5 stapled together' and have the system deal with it as much as possible.
> but we've seen what happens when every program needs to adjust it's document to the printer in question, the result is the windows printing mess where loading a different printer driver can change your document layout drastically.
That's not surprising since each printer can be drastically different and different PPD files (aka 'printer drivers', aka 'postscript printer description' files) expose different capabilities.
Unless your program can change the document to suite the printer then it's just a guessing game on the part of the user as to how it's going to look when printed. However, obviously you don't want to force every application to be a desktop layout suite. So therefore you want the system to handle as much as the complexity as possible for applications that don't need it.
This is why you will always needs CUPS or something just as complex to replace it. You can't get away from it. Printing is a huge pain the ass.
Posted May 23, 2012 19:48 UTC (Wed)
by butlerm (subscriber, #13312)
[Link] (8 responses)
There is nothing in principle more difficult in rendering to a high resolution printer than in rendering to a display. For a wide variety of reasons, it is uncommon to require applications to generate Postscript fragments to display anything on the screen. Virtually every graphical application uses some sort of internal or library provided rendering API to display output on the screen, why should it use a different one to generate output for printing?
As a consequence of this common architecture, a Turing-complete programming language like Postscript is massive overkill for contemporary printer interface. PDF is much better (because it is not a programming language), but it tends to be a rather inefficient processing format as well.
A high performance page rendering interface should be based on a binary wire protocol vaguely similar to X, or a serialized version of OpenGL. PDF is more than a little inefficient by comparison. Contemporary display devices render hundreds of extraordinarily complex scenes per second.
Is there any fundamental reason why a printer driver can't be as efficient? Or why we shouldn't prepare for a world where nearly all page rendering is handled on the host system rather than by a ridiculously underpowered, buggy, and resource impaired piece of firmware on the printer?
Posted May 23, 2012 20:30 UTC (Wed)
by nybble41 (subscriber, #55106)
[Link] (5 responses)
Modern OpenGL (with shaders rather than fixed-function pipeline stages) essentially _is_ a Turing-complete programming language. For similar reasons, I don't think non-Turing-completeness is a reasonable requirement for any rendering API, and for printing I'd actually prefer something like a scene graph with attached shader programs. Naturally, as with rendering for the display, the shaders would be subject to various resource limitations, including a limit on runtime. It should be possible to rasterize the print job via commonly-available embedded, OpenGL ES-capable GPUs.
> Or why we shouldn't prepare for a world where nearly all page rendering is handled on the host system rather than by a ridiculously underpowered, buggy, and resource impaired piece of firmware on the printer?
A network-attached printer ought to be able to perform its own rasterization, to conserve I/O. For printers designed to be connected only to a host PC, however, I'd just as soon standardize on a simple raster-based printing protocol and do the heavy lifting on the host--ideally with GPU acceleration.
Posted May 24, 2012 0:26 UTC (Thu)
by nix (subscriber, #2304)
[Link] (1 responses)
Like it or not, there's going to be either a bitmap or a vector language (or, more likely, both) in any plausible printer for a very long time to come.
Posted May 24, 2012 2:53 UTC (Thu)
by nybble41 (subscriber, #55106)
[Link]
Posted May 24, 2012 8:30 UTC (Thu)
by butlerm (subscriber, #13312)
[Link]
This is a nice benefit, but the problem is that in most cases it is a program of planned obsolescence for otherwise perfectly adequate printer hardware. Short of mid-range printer manufacturers adopting a standard for rasterizer plugin cards, host (or print server) based rasterization ought to be the most effective way to keep a decent printer from not so gradually turning into an expensive paperweight.
As an example, I have a ~$1K laser printer from a name brand manufacturer that is less than five years old that is in the habit of taking more than a minute to print single pages from innocent looking PDF files. Certainly any well written host based rasterizer could run circles around that.
>Modern OpenGL (with shaders rather than fixed-function pipeline stages) essentially _is_ a Turing-complete programming language.
OpenGL serialization was a poor choice for an example. Something more like a efficient serialization of the PDF rendering model was what I had in mind. A serialization of OpenVG might work nicely, but it appears to be a little too simple.
Posted May 24, 2012 9:00 UTC (Thu)
by pkern (subscriber, #32883)
[Link] (1 responses)
You really want to drive network-attached printers with rasterized input as well. It has the computing power of a toaster, the only plus is that it can start printing when it completed the image of the first page. PDF can have multiple layers and hence may overload a rasterizing printer easily. Even PCL XL is already too complex and certain outputs will cause the printer to take a walk. The only part that worries me about printers that really only take raster input is the fact that you then need to bother with uploading their firmware and the newest and greatest proprietary inventions of rasterization on-the-wire formats to reverse engineer.
Posted May 24, 2012 18:35 UTC (Thu)
by butlerm (subscriber, #13312)
[Link]
If there isn't any serious way to generate and stream a PDF document one page at a time, PDF would seem to be a uniquely unsuitable format for the printing of large documents not already composed and linearized in PDF format in any kind of a hurry. Perhaps SVG Print would be a better long term alternative for that reason alone.
Posted May 24, 2012 18:02 UTC (Thu)
by jsanders (subscriber, #69784)
[Link] (1 responses)
Posted May 24, 2012 18:25 UTC (Thu)
by jsanders (subscriber, #69784)
[Link]
Posted May 22, 2012 16:57 UTC (Tue)
by jimparis (guest, #38647)
[Link]
Unfortunately, they're still using the CUPS backends, which are the part I'm having the most problems with. You'd think that printing to a networked Postscript printer would be a walk in the park, but it's turned out to be an ordeal. It's frustrating trying to debug, because one small problem means that your printer suddenly starts spewing ten pages of unrendered PDF before you run over and shut it off for the umpteenth time. I'm still working on trying to figure out the actual problem enough to report a bug, though...
Posted May 22, 2012 18:34 UTC (Tue)
by bredelings (subscriber, #53082)
[Link] (6 responses)
As far as other formats, some current print queues already convert text to PS before printing. This is different than disallowing text -- text is still allowed, but it isn't sent directly to the printer. Whether the everything-is-a-PDF paradigm has enough benefits to offset the cost of converting all documents to PDF before printing is something I'm not completely sure about.
Posted May 22, 2012 19:01 UTC (Tue)
by job (guest, #670)
[Link] (2 responses)
Posted May 22, 2012 19:15 UTC (Tue)
by alexl (subscriber, #19068)
[Link]
Also, the fact that its not a general programming language, so you can't write a raytracer in a PDF is kinda nice on the server side.
Also, I think there is some metadata storage in PDF so that you can tell the printer things about how to print the document, etc.
Posted May 22, 2012 19:22 UTC (Tue)
by sfeam (subscriber, #2841)
[Link]
- PDF can handle CJK and other large font sets without the hackish and painful workarounds required in PostSCript, which was designed assuming that an 8 bit character index was all you needed.
- PDF can handle alpha channel color. The PostScript work-around for the lack of alpha-channel support is to expand all the relevant areas into bitmaps with pre-merged colors rather than carrying forward overlapping vector-based elements with transparency. This works so poorly that I hesitate to even call it a work-around.
Posted May 22, 2012 19:01 UTC (Tue)
by dlang (guest, #313)
[Link] (1 responses)
the biggest overhead of converting between pdf and ps is the overhead of dealing with the compression.
Posted May 22, 2012 20:17 UTC (Tue)
by mgedmin (subscriber, #34497)
[Link]
You're mistaken.
The drawing commands in a PDF file are a (non-Turing-complete) subset of PostScript, though, so the mistake is understandable.
Posted May 22, 2012 19:17 UTC (Tue)
by drag (guest, #31333)
[Link]
Seems like a tall order.
I am guessing your 'PDF printer' really just uses some daemon already to convert the PDF to PS or some other control language that the printer understands. If it is a network printer then I suppose it runs a embedded CUPS daemon on Linux or some proprietary alternative to do the work.
Posted May 22, 2012 23:55 UTC (Tue)
by cmccabe (guest, #60281)
[Link] (1 responses)
Solution: throw out all the common infrastructure and re-do it. If the infrastructure is shiny enough, nobody will notice that they can't actually print.
Brilliant. I expect a long time period during which the maintainers blame buggy printer drivers for the fact that nothing works under the new infrastructure, a la Pulse Audio.
Posted May 23, 2012 0:46 UTC (Wed)
by shemminger (subscriber, #5739)
[Link]
Posted May 23, 2012 4:35 UTC (Wed)
by nhippi (subscriber, #34640)
[Link] (15 responses)
Instead of starting with declaring
1) what the problem is
They go and explain how it going to be great since they use dbus and gobject?
Sounds like one of the many cases where the needs of architecture takes over the needs of users.
Posted May 23, 2012 5:45 UTC (Wed)
by martinfick (subscriber, #4455)
[Link] (4 responses)
This message isn't just aimed at you (so forgive me if it feels too strong of a response to your post). I just felt upset reading the many replies above which had somewhat angry tones and yours was the last one in the series. It has become more and more common here to direct such anger or contempt towards free software creators. These are people who are hopefully just sharing with you and others. As long as they are just sharing freely without trying to extort you in some way, or maliciously convince you to use their malware it feels wrong to attack them (even if their code or designs are flawed). I know that I would feel upset reading the reception that these authors are getting here if I were them, and I don't think they were even asking for a reception.
Posted May 23, 2012 7:35 UTC (Wed)
by nhippi (subscriber, #34640)
[Link] (1 responses)
Creating a competitor for a existing system disrupts Linux ecosystem while the transition is going on, and fragments Linux further if it fails to be clearly superior than the historic alternative. Yes sometimes that has to happen, but it is not a decision to be taken lightly.
I think people take too easily the route of having fun of creating their project from scratch using their favourite technologies (like gobject and d-bus) than to joining the existing project and working with their preferred methods to make existing project work better for everyone.
I guess it is a bit of fame issue as well. Nobody will get famous plumbing an existing free software project, while someone who creates a new project will be known as the author of the new project...
Let me bow to the unsung heroes of free software development: plumbers of existing projects.
Posted May 23, 2012 9:07 UTC (Wed)
by dgm (subscriber, #49227)
[Link]
It's absolutely right -even critical- to create alternatives to existing projects. It ensures there's no single point of failure at any level, and that we don't get stuck too long because of evolutionary dead-ends.
The _problem_ starts when bigger projects (desktops and distros) push an immature alternative, sometimes for shady reasons. Sometimes is because of someone's agenda, but often is just a combination of stupidity and stubborness (we are all humans after all).
So, I salute and thank the developers for the effort they are putting into this, but distros and desktops better stay clear from it, at least until they can demonstrate that it brings something valuable to the table _and_ can take over the functions of whatever is being replaced.
Posted May 23, 2012 11:09 UTC (Wed)
by intgr (subscriber, #39733)
[Link] (1 responses)
Look at the announcement of systemd for example: http://0pointer.de/blog/projects/systemd.html -- when reading it, I immediately recognized a few of my pet peeves listed and understood the value of the project.
> If you don't like their ideas or software don't use them
It's not as simple as that. The author of this project is also a Fedora developer. I think that users have the right to complain when they see a distro going in a direction that they don't like.
Posted May 23, 2012 12:44 UTC (Wed)
by kmike (guest, #5260)
[Link]
> It's not as simple as that. The author of this project is also a Fedora developer. I think that users have the right to complain when they see a distro going in a direction that they don't like.
Exactly. I wouldn't be surprised to see printerd as the default in Fedora 19.
Posted May 23, 2012 7:19 UTC (Wed)
by alexl (subscriber, #19068)
[Link] (9 responses)
Just because the announcement doesn't fulfill your wet dream about how a perfect project announcement should look, please don't assume that the people involved are complete idiots who have no idea about the problem they are trying to solve. It just makes you look bad. Smart people don't think others are stupid.
Posted May 23, 2012 12:07 UTC (Wed)
by nye (subscriber, #51576)
[Link] (8 responses)
(Your personal attack on the other hand I found offensive and obnoxious)
Posted May 23, 2012 13:31 UTC (Wed)
by alexl (subscriber, #19068)
[Link] (6 responses)
"Architecture astronauts take over"
It might not be all that easy to understand what printerd is for from the announcement, but that doesn't mean you should jump to the wrong conclusions and flame the people doing the work about those.
Tim has been working on Linux printing for the last decade. To claim that he has no knowledge about the needs of users, or that he just does this so he can use dbus or gobject is ridiculous. He is one of the few people who actually work to make printing work in Linux, and what does he get for it? Flames by people who do not even understand the problem (although the lack of understanding is partly the fault of the announcement).
Posted May 23, 2012 14:49 UTC (Wed)
by spaetz (guest, #32870)
[Link] (5 responses)
Posted May 23, 2012 15:01 UTC (Wed)
by alexl (subscriber, #19068)
[Link] (4 responses)
printerd is more like a session print spooler. It lets you enumerate printers, submit jobs to them, etc. If the printer was a network (ipp) printer that supports pdf, or a cloud service like Google Cloud Print then everything will run without any instance of CUPS.
However, if you're printing to a local printer, or a printer attached to a print server (on linux) then printerd will hand the pdf over to CUPS, running locally or on the server.
Tim has a nicer explanation in an earlier blog entry:
Posted May 23, 2012 16:56 UTC (Wed)
by cmccabe (guest, #60281)
[Link] (3 responses)
CUPS already has support for being a print spooler. It already allows you to "enumerate printers, submit jobs to them, etc." What is printerd going to provide that CUPS does not?
Please keep in mind that another layer of software is another layer of bugs that we will all have to debug. Even the best programmers sometimes make mistakes. If there's no value add from the additional abstraction, then I would prefer to keep things simple.
I would love to see something take over from cups, but only if it provides the same features that cups provides. I'm not really interested in running the printer daemon version of "duelling banjos."
Posted May 23, 2012 18:42 UTC (Wed)
by alexl (subscriber, #19068)
[Link] (2 responses)
However, if you're not using a local printer, but rather some network printer or cloud service then having to have a local system-wide print spooler is completely unnecessary, and printd would just forward the job to the spooler on the remote server, working completely in the user session.
Running in the session has some advantages besides just needing less code. It also allows the spooler to do things like authenticate to the cloud service in a normal way, as its part of the user desktop session, rather than some system service.
Anyway, Tim knows this stuff better, and he posted a new blog entry: http://cyberelk.net/tim/2012/05/23/some-benefits-of-print...
Posted May 23, 2012 22:41 UTC (Wed)
by cmccabe (guest, #60281)
[Link]
My printer is a USB printer. It requires a printer driver to work. A driver which, incidentally has not been updated or fixed in years, and is not officially supported by the distro. Luckily I know enough about the plumbing to know how I can get this thing to work. (Should "work" be in quotes?)
At work, there is an IPP printer which I mostly use. The time I spent setting it up in CUPS was about 5 minutes, including printing test pages and all that.
> Running in the session has some advantages besides just needing less code.
Again, I just don't care. I've never used a multi-seat Linux machine (and I've had 5 jobs where I used Linux, including one where we used it in the cloud.) I also don't see what fundamentally prevents CUPS from doing the same thing-- i.e., accepting or rejecting jobs based on the user id that submitted them.
So far, printerd has not proposed to solve any of the problems I have ever had. Of course, I'm just one user-- perhaps others will have different needs.
Posted May 23, 2012 23:02 UTC (Wed)
by jjs (guest, #10315)
[Link]
So other than adding another layer between the application and CUPS, what does printerd do?
Posted May 24, 2012 7:05 UTC (Thu)
by jku (subscriber, #42379)
[Link]
It's true that the announcement should have come with a link to http://cyberelk.net/tim/2012/05/23/some-benefits-of-print... but lets not make that omission a larger issue than it is.
Posted May 24, 2012 15:33 UTC (Thu)
by njd27 (subscriber, #5770)
[Link] (20 responses)
Posted May 25, 2012 3:45 UTC (Fri)
by quotemstr (subscriber, #45331)
[Link] (19 responses)
Or at least that's what the Wayland people taught me.
Posted May 25, 2012 10:35 UTC (Fri)
by dgm (subscriber, #49227)
[Link]
Now seriously: that's exactly what you have been doing for a few years now unless you limit yourself to Motif applications, because all popular toolkits draw on the client side and then send the pixmaps to the X display via XRender these days. Or at least that's what they told to me.
Posted May 25, 2012 11:55 UTC (Fri)
by sdalley (subscriber, #18550)
[Link] (17 responses)
No, that is outside the scope of Wayland. To support remote rendering you need to define a rendering API, which is something I've been very careful to avoid doing. The reason Wayland is so simple and feasible at all is that I'm sidestepping this big task and pushing it to the clients. It's an interesting challenge, a very big task and it's hard to get right, but essentially orthogonal to what Wayland tries to achieve. This doesn't mean that remote rendering won't be possible with Wayland, it just means that you will have to put a remote rendering server on top of Wayland. One such server could be the X.org server, but other options include an RDP server, a VNC server or somebody could even invent their own new remote rendering model. Which is a feature when you think about it; layering X.org on top of Wayland has very little overhead, but the other types of remote rendering servers no longer requires X.org, and experimenting with new protocols is easier. It is also possible to put a remoting protocol into a wayland compositor, either a standalone remoting compositor or as a part of a full desktop compositor. This will let us forward native Wayland applications. The standalone compositor could let you log into a server and run an application back on your desktop. Building the forwarding into the desktop compositor could let you export or share a window on the fly with a remote wayland compositor, for example, a friend's desktop.
Posted May 25, 2012 14:28 UTC (Fri)
by renox (guest, #23785)
[Link] (4 responses)
Obviously Wayland devs would say that that Wayland won't create issues for using remote display in a WAN, in practice we will see: it's very possible that this will be a mess..
In a way, it *is* already a bit of a mess: NX isn't integrated in X as it should be IMHO.
Posted May 25, 2012 17:16 UTC (Fri)
by sdalley (subscriber, #18550)
[Link] (3 responses)
We all wish that the Linux desktop experience was better today. But what are your technical objections to Wayland? You admit that the current state of X is non-optimal. Have you got some constructive suggestions to improve the situation?
"The one who says something cannot be done should never interrupt the one who is doing it."
Posted May 25, 2012 18:30 UTC (Fri)
by dlang (guest, #313)
[Link]
Posted May 25, 2012 18:56 UTC (Fri)
by renox (guest, #23785)
[Link] (1 responses)
Not really: the reason why X is not in a good state is due to chronic lack of manpower ( http://www.phoronix.com/scan.php?page=news_item&px=MT... )..
Wayland will "help" by doing less, OK, but let's not pretend that the existence of Wayland is a good thing..
Posted May 25, 2012 22:25 UTC (Fri)
by sdalley (subscriber, #18550)
[Link]
There seems to be some memo that I didn't get. _Why_ is the existence of Wayland a _bad_ thing? What else would be better? It is a long overdue refactoring of the display/rendering/windowing plumbing that is careful not to reinvent new wheels but replace old and wobbly ones. In the medium term it will allow X to drop a load of old cruft.
This will surely end up making the overstretched X maintainers' lives easier, and more fulfilling than bodging improvements that are better and more simply done elsewhere.
It seems to be well supported by Red Hat and hopefully Canonical will soon be getting actively involved too.
As for remote-X issues, I certainly don't disagree there's problems there.
These problems, however, are not within Wayland's scope at present. Its design carefully leaves a clear field in which to fix them. And so long as workarounds like Xvnc and Xpra continue to work, we should at least not go backwards.
What's not to like? It seems to me that Wayland deserves our support and help during the inevitable teething issues rather than criticism.
Posted May 26, 2012 23:51 UTC (Sat)
by butlerm (subscriber, #13312)
[Link] (11 responses)
This is where I get confused. Presumably, the use of direct-to-Wayland backends with toolkits like GTK and QT will normally make things worse (if not impossible) for remote operation. So are the advantages of Wayland with X layered on top substantial enough that it is a major improvement over the status quo? Or do the real advantages of Wayland only come when you eliminate the X layer in-between?
Furthermore, if Wayland does the compositing and the input arbitration, is it really necessary for X to run out of process in this case? Couldn't you just have libXCB or whatever have multiple backends, one a stub for remote operation using the X protocol, and the other an in-process rasterizer for use with Wayland, etc?
Posted May 27, 2012 10:25 UTC (Sun)
by Jonno (subscriber, #49613)
[Link] (3 responses)
Option 1: Remote rendering *on top of* Wayland. In this scenario clients (applications) don't do rendering themselves, but sends rendering commands to the display server, which render the windows and ask the Wayland compositor to display them. This will ofcourse require changes to the clients, or to the toolkit they use. You can use the standard compositor (e.g. Weston) on the display server, but will need a rendering server and protocol as well. One existing solution is to use xserver and X11, but developing a better protocol is a possible future improvement.
Option 2: Remote composition *below* Wayland. In this scenario clients render the windows themselves and ask the local compositor to display them. The local compositor, however, does not, but instead compress the windows and sends them over the network to the display server, which in turn asks its Wayland compositor to display them. This will work with all Wayland clients without modification. You can use the standard compositor (e.g. Weston) on the display server, but will need a proxy compositor and client to forward the windows over the network. This is not yet implemented in production-ready code (though there are abandoned proof-of-concept code for older Wayland versions), but is expected to be the default once done.
Option 2 is often called VNC-like because you send pre-rendered images over the network, but unlike actual VNC, you will get rootless windows that integrate just as well as remote X11 windows, so a better description would be Xpra-like. For most (but not all) applications option 2 will require more bandwidth than option 1, but option 2 will require less roundtrips and are thus not as sensitive to lag (a.k.a. poor ping times).
User of dial-up connections and users on over-saturated local networks might want to deploy option 1 (i.e. no change from today), but most use cases will be better served by option 2 (i.e. better performance than today).
Posted May 27, 2012 21:12 UTC (Sun)
by raven667 (subscriber, #5198)
[Link] (2 responses)
Posted May 28, 2012 5:52 UTC (Mon)
by butlerm (subscriber, #13312)
[Link] (1 responses)
Posted May 28, 2012 6:43 UTC (Mon)
by raven667 (subscriber, #5198)
[Link]
I'm not sure if that's the chicken or the egg, these protocols (RDP, ICA) have been deployed for more than 20 years and I'm not sure that the standards you references aren't just ex post facto documentation of existing practice.
> the usual set of rendering operations, font and image caching, and so on
One more thing to point out is that all the protocols I listed are add-ons to an existing system (mostly MS Windows) that isn't designed around remoting applications and so has to integrate with an infrastructure designed around local display, the same kind of problems that would need to be solved to remote native Wayland applications.
The methods for local display and remote display have little relation to one another and I think experience has shown that this is a good arrangement, trying to do both with the same method leads to a design that is poor for both cases.
Does any of that sound similar to your understanding of the situation? 8-)
Posted May 28, 2012 6:33 UTC (Mon)
by raven667 (subscriber, #5198)
[Link] (6 responses)
The existing robust X backends aren't just going to evaporate, the toolkits are already multi-platform and Wayland is just an additional backend.
> So are the advantages of Wayland with X layered on top substantial enough that it is a major improvement over the status quo?
Yes, it takes the hardware handling out of X and leaves it with just the protocol to support existing apps. The hardware handling can be much better done outside of the X framework than within it. X can be much simpler and more robust if it isn't trying to handle the underlying hardware.
> Or do the real advantages of Wayland only come when you eliminate the X layer in-between?
There is probably sufficient advantage even if the only native Wayland client was the X server although in practice toolkits are going to have a direct Wayland option and eliminate the middleman for local display (only).
> Couldn't you just have libXCB or whatever have multiple backends, one a stub for remote operation using the X protocol, and the other an in-process rasterizer for use with Wayland, etc?
I may be talking above my knowledge level but my guess is that X apps and toolkits just aren't architected in a way where that makes any sense. The people who are designing and implementing Wayland are also the ones who designed and maintain X so my guess is that they are aware of the different architectural options and are picking the best ones.
Posted May 28, 2012 15:59 UTC (Mon)
by butlerm (subscriber, #13312)
[Link] (5 responses)
My question here is basically can the toolkit switch dynamically so that the same application binary be run in both X mode or Wayland mode, depending on the runtime environment?
If so, that would be outstanding, if not that could put a major impediment in the deployment of such applications until some form of remote operation is working. I can't see a server distribution standardizing on applications that can't be accessed remotely.
Posted May 28, 2012 16:19 UTC (Mon)
by raven667 (subscriber, #5198)
[Link]
Posted May 28, 2012 17:40 UTC (Mon)
by Jonno (subscriber, #49613)
[Link] (3 responses)
NB: For Qt 4.8 you need to explicitly configure Qt with -qpa to get the new modular backends, the default is X11 only. In Qt 5.0 the hard-coded X11 port will be gone and replaced with a modular xcb backend.
Posted May 29, 2012 7:51 UTC (Tue)
by butlerm (subscriber, #13312)
[Link] (2 responses)
Posted May 29, 2012 21:53 UTC (Tue)
by nix (subscriber, #2304)
[Link] (1 responses)
Posted May 30, 2012 5:47 UTC (Wed)
by aquasync (guest, #26654)
[Link]
Announcing printerd
Announcing printerd
Some reasons, off the top of my head:
Announcing printerd
Tim's code looks good, and I'm quite certain he is sincere in his intent to improve things, but it does lead me to wonder: how much code + innovation + promotion does it take to troll the Linux community?
Announcing printerd
Announcing printerd
Announcing printerd
Announcing printerd
Announcing printerd
Announcing printerd
Announcing printerd
Announcing printerd
Announcing printerd
Announcing printerd
Because CUPS finally 'just works'
Because CUPS finally 'just works'
Because CUPS finally 'just works'
Because CUPS finally 'just works'
printers => administration => Set Default Options => Policy
s/stop printer/abort job/
Because CUPS finally 'just works'
Because CUPS finally 'just works'
Disagree - web interface a GOOD idea.
Disagree - web interface a GOOD idea.
Because CUPS finally 'just works'
Because CUPS finally 'just works'
Because CUPS finally 'just works'
Announcing printerd
Announcing printerd
Announcing printerd
Since it works for X11 it can't be rocket science but so far all indicators I've seen say that SSH is incapable of it.
Announcing printerd
Perhaps one could use socat.
Announcing printerd
Announcing printerd
Yes, you can certainly use socat with ssh to forward UNIX-domain sockets.
forwarding unix-domain sockets over ssh [was: Announcing printerd]
Announcing printerd
Announcing printerd
Other IPP servers?
Old school
Old school
Speak for yourself please.
Announcing printerd
Announcing printerd
Announcing printerd
Announcing printerd
Announcing printerd
Announcing printerd
Announcing printerd
Announcing printerd
Announcing printerd
Announcing printerd
Announcing printerd
Announcing printerd
Announcing printerd
Announcing printerd
Announcing printerd
Announcing printerd
Pros and Cons of PDF print queues?
Pros and Cons of PDF print queues?
Pros and Cons of PDF print queues?
Pros and Cons of PDF print queues?
Pros and Cons of PDF print queues?
Pros and Cons of PDF print queues?
Pros and Cons of PDF print queues?
Announcing printerd
Announcing printerd
Architecture astronauts take over
2) how their new software will solve it
Please take a deep breath before posting.
Please take a deep breath before posting.
Please take a deep breath before posting.
Please take a deep breath before posting.
Please take a deep breath before posting.
Its *possible* that Tim Waugh, maintainer of printing in Red Hat since time immemorial and one of the very few long term active participants in the Linux upstream printing echosystem has made a mistake, and that some random commenter on LWN has a point to make. However, this seems more like a no-brain cheap complaint about the announcement text, making fun of some techical decissions with no apparent real thought behind it.
Architecture astronauts take over
Architecture astronauts take over
Architecture astronauts take over
"going to be great since they use dbus and gobject"
"the needs of architecture takes over the needs of users"
Architecture astronauts take over
Architecture astronauts take over
http://cyberelk.net/tim/2012/03/08/session-printing/
Architecture astronauts take over
Architecture astronauts take over
For the case of a local printer printerd would just call out to the local cups daemon just like currently, and printerd would be nothing more than a frontend for cups with an API that is nicer for async code (ever tried to write async code using libcups?).
Architecture astronauts take over
> It also allows the spooler to do things like authenticate to the cloud
> service in a normal way, as its part of the user desktop session, rather
> than some system service.
Architecture astronauts take over
Architecture astronauts take over
Announcing printerd
Announcing printerd
Announcing printerd
Ho, ho, very amusing. But you and the GP demonstrate that the Wayland people haven't been able to teach you anything at all.
Remote display of an entire desktop (as opposed to an X window) is an orthogonal problem. See the Wayland FAQ:
You betray your ignorance of wayland
Is Wayland network transparent / does it support remote rendering?
As far as existing remote X functionality is concerned, look at http://wayland.freedesktop.org/architecture.html , and then at http://wayland.freedesktop.org/xserver.html . You will see from this that the Xserver merely becomes another Wayland client. The intention is that nothing that X was able to do before (e.g. remote windows over the network) is going to be lost, because remote X clients can continue to connect to the X server just as they always have.
Strong words
Strong words
Strong words
Strong words
But what's the better alternative to Wayland?
Using Linux desktops over network X clients has been getting steadily worse over recent years, not because X is getting worse but because it is being asked to do more and more. GLib/cairo-based software expects textures and gradients where previously it was just pixels. SunRay thin clients got round to adding the X RENDER extension a couple of years ago, making the performance of GLib-based software on them merely sucky instead of snailishly unusable.
You betray your ignorance of wayland
You betray your ignorance of wayland
You betray your ignorance of wayland
You betray your ignorance of wayland
You betray your ignorance of wayland
You betray your ignorance of wayland
You betray your ignorance of wayland
You betray your ignorance of wayland
You betray your ignorance of wayland
You betray your ignorance of wayland
You betray your ignorance of wayland
You betray your ignorance of wayland