In 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.
At 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
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 future
Another 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
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
Comments (8 posted)
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.
Comments (none posted)
Collabora 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.
Comments (1 posted)
GNU 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
vast amounts of detail.
Full Story (comments: 8)
It turns out that the long wait for MPlayer 1.0 was in vain - the project
went straight to a 1.1
. "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.
Comments (8 posted)
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
for more information.
Full Story (comments: none)
Version 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
" See the
Full Story (comments: none)
Tiago 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.
Comments (51 posted)
The 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.
Full Story (comments: 2)
Newsletters and articles
Comments (none posted)
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.
Comments (none posted)
Page editor: Jonathan Corbet
Next page: Announcements>>