LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||
Developmentprinterd modularizes Linux printingIn May, Red Hat's Tim Waugh and Richard Hughes announced the printerd project; a new print spooler implemented as a D-Bus system service. Printerd is deemed experimental by its creators, but it offers a different approach from the CUPS-based Linux printing system that has dominated distributions for years. CUPS, of course, includes a number of modules that connect together to form the life-cycle of a print job. There is the spooler, which schedules print jobs initiated by applications, followed by a series of filters that transform the data (including scaling, format changes, color-to-grayscale conversions, and N-up placement), plus back-end drivers for specific printers. Printerd is an effort to write a new scheduler from scratch — one that can be integrated directly with the system services of a modern Linux-based OS. System servicesAt a basic level, that design decision means two things. First, the printerd spooler interacts with applications over D-Bus, and second, the spooler uses PolicyKit to enforce security. The CUPS API is based on the Internet Printing Protocol (IPP), which allows client applications to connect to the print server and request information (such as a list of available printers or their capabilities) or submit and check on print jobs. Policy, such as which users are allowed to access a printer, is spelled out in the cupsd.conf configuration file. It allows administrators to control access on the basis of function (such as sending printer jobs or canceling jobs), IP address, username, or group, and it covers general settings like authentication method. Printerd's D-Bus API is modeled on IPP, but it is not intended to be an IPP implementation, and thus has some minor differences. Waugh said in the initial announcement that "the aim is to be able to implement an IPP server on top of the D-Bus API as a separate process." This separates the IPP server from the local print spooler, allowing computers with only un-shared, local printers to dispense with managing an IPP service. By using D-Bus, printerd also allows client applications to access the print spooler asynchronously, which is not possible with CUPS. This would be useful for shared printers, but also for programs that need to print automatically. As it is today, printing through CUPS either blocks the application or forces it to start a new thread. PolicyKit integration does not offer different security features than CUPS's own security framework, but it does make it easier to deploy a system-wide policy across user accounts. As Waugh explains in a May 23 blog post, there is a CUPS plugin called cups-pk-helper that uses PolicyKit to enforce a security policy, but it works by bypassing the cupsd.conf settings altogether. Thus, to restrict access to a certain function (e.g., canceling all print jobs on a shared printer), one would need to specify the security rule in both CUPS and PolicyKit. Print pipelines and the futureAnother modernizing choice in printerd design is that it supports only PDF as its print job format. Waugh's rationale is that basing the workflow on PDF dramatically simplifies the job assembly process; PDF has support for selecting and arranging individual pages built in to the format itself (which is necessary, for example, in automatic duplex printing). The other main contender for a job format is PostScript, but although there are vendor-specific conventions for page-selection and layout manipulation, they are not consistently implemented. Nevertheless, commenters on the blog took issue with Waugh's assertion that "generally people print from applications that generate PDF." While it might be true that most documents can be rendered to PDF for printing, not all can, and not all applications are designed to produce PDF. Plain text files, for example, are handled automatically by CUPS filters, and would require a special filter to be printed with printerd. Many specialized printers, such as those designed for printing labels or photos, need lower-level output formats than the standard file types embedded in a PDF, although in practice they tend to use special drivers (such as those maintained by the Gutenprint project) as well, so they are already exceptions to the standard pipeline. In spite of the alarm expressed by some over printerd's PDF-only policy, it is important to remember that PDF print queues are already the plan settled upon by the vendor-neutral OpenPrinting workgroup at the Linux Foundation. GTK+ and Qt, the two most widely-used application toolkits, already support PDF printing pipelines, as do LibreOffice and Mozilla, two large projects which, together, arguably generate as much of the printed matter on a typical Linux desktop as the toolkits. Ubuntu formally became a PDF-pipeline distribution with the 11.10 release, and the IEEE's Printer Working Group seems poised to adopt PDF as its standard page format, too. That said, it is interesting to note that when we last examined PDF print queues in March 2012, the issue at hand was that Apple, the corporate parent of CUPS, had begun making changes to the stack that adversely affected non-Apple systems. The changes in CUPS 1.6 introduced some additional work for Linux printing system maintainers, but the bigger fear was that those changes were just the tip of the iceberg, and that future releases would make CUPS less and less relevant to Linux. At that time, Waugh commented that a Linux-centric CUPS replacement had been discussed, but that it was not in the works "for the time being." Waugh still describes printerd as "experimental" and cautions readers of his blog that it is an attempt to test and develop print pipeline ideas. Among his interests he lists several outstanding problems he would like to solve, including the lag time between canceling a print job and having the printer stop the paper feed, and separating the filter pipeline into a separate process from the driver backend, in order to better more efficiently multiplex multiple simultaneous print jobs. Technically, applying a filter chain to a print job is a different part of the pipeline than the spooler, so that work would probably not be part of printerd itself. But it seems clear that Waugh is envisioning a post-CUPS printing landscape. Furthermore, regardless of how long it takes to arrive or whether or not printerd is ultimately part of the final product, he seems intent on splitting the individual steps in the print pipeline into separate tools. That is probably a good approach; today it is difficult to explain what CUPS is (at least succinctly) because it bundles so many discrete steps into a single, monolithic package. Modularizing the tools could make it simpler to maintain quality printer drivers, plus cleanly separate local and IPP printing. There is no telling if or when such a modular printing stack would prove preferable to CUPS, but for now printerd and related experiments may at least offer the opportunity to find out.
Brief items Quotes of the week
Never let root try to do a job the operating system should do
itself. Furthermore, never let a user try to do it, either.
Unless you prefer a system you never let people onto. And if that
is your use case, you are better off choosing something which has
infinite flexibility, and then disconnecting it from the net.
— Theo de Raadt
Managing a volunteer open source project is a lot like herding
kittens, except the kittens randomly appear and disappear because
they have day jobs.
— Matt Mackall
I'm worried that an ecosystem one-tenth the size of the current
desktop market will be uninteresting to Microsoft and Apple. They
will continue to make the desktop computing experience more
mobile-like in an effort to please the larger market. This is where
I think the desktop Linux vendors can really shine. Since they
aren't as dependent on direct profit, they can thrive in a smaller
market (which is still less than 10% today). However, this means
they should focus on the needs of advanced users, not on trying to
make a desktop that everyone in the world can use.
— Josh
Marinacci
Collabora and Fluendo launch GStreamer SDKCollabora and Fluendo, the two primary development companies behind the open source GStreamer media framework, have created a cross-platform software development kit (SDK) for building GStreamer-based applications. The announcement says the SDK will build applications "to be functionally identical on Windows XP, Windows Vista, Windows 7, Mac OS X (version 10.5 or later on Intel) and all supported Linux platforms." The kit appears to be shell-based, and include a lengthy set of tutorials along with build and packaging tools.
Emacs 24.1 releasedGNU Emacs 24.1 is out. New features include (finally) a mechanism for dealing with package installation and repositories, bidirectional text support, an improved completion system, and more. See the NEWS file for vast amounts of detail.
MPlayer 1.1 releasedIt turns out that the long wait for MPlayer 1.0 was in vain - the project went straight to a 1.1 release. "We gave up on 1.0 After a long pause, we decided that it might be a good idea to make a new release. While we had our fun with the naming scheme with lots of 'pre' and 'rc' it seemed time to move on and with everyone incrementing major versions between weekly and monthly we hope to be forgiven for jumping ahead to 1.1." There's a lot of new stuff in this audio and video player release, much of which comes from the recent FFmpeg 0.11 release.
Postgres-XC 1.0.0Postgres-XC is "an open source project to provide a write-scalable, synchronous multi-master, transparent PostgreSQL cluster solution. It is a collection if tightly coupled database components which can be installed in more than one hardware or virtual machines.." Version 1.0.0—the project's first stable release—is now available; see the documentation page for more information.
GNU Radio 3.6.1Version 3.6.1 of the GNU Radio software-defined radio package is out. "This release contains numerous bug fixes, some new signal processing blocks, a new Python API documentation system, and the first steps in the code reorganization that will become complete in the 3.7 API release." See the changelog for details.
Vignatti: X on WaylandTiago Vignatti describes the mechanism by which X clients will be supported on a Wayland display server. "All X windows created from now on will be redirected to offscreen pixmap and stored on a DRM buffer (via the xwayland video driver); that’s how compositing works on Wayland. The idea is that a X client will behave very likely as a regular Wayland client. Therefore, there’s no protocol calls or any major task involved on xwayland and all happens seamlessly, with the protocol 'conversion' penalty close to nil."
X11R7.7 releasedThe X.org project has released X11R7.7, which includes "both new features and stability and correctness fixes, including support for reporting multi-touch events from touchpads and touchscreens which can report input from more than one finger at a time, smoother scrolling from scroll wheels, better cross referencing & formatting of the documentation, pointer barriers to control cursor movement, and synchronization fences to coordinate between X and other rendering engines such as OpenGL."
Newsletters and articles Development newsletters from the last week
Open crowdsourcing arrives with PyBossa (The H)The H looks at PyBossa, a Python framework developed by the Open Knowledge Foundation to build crowdsourcing features. "Pulling together volunteers to work on tasks can be a difficult logistical task, especially if the tasks are small like classifying the contents of a picture or transcribing some text from an existing document. For paid work like that, solutions like Amazon's Mechanical Turk divide up the load and then make the tasks available to a pool of workers, but for open data, open source or other open projects, there haven't been many options until the arrival of PyBossa."
Page editor: Jonathan Corbet |
|||||||||||||