One of the biggest advantages of free software is that it is usually
written with the needs of its users in mind. Proprietary software,
instead, has more of a tendency to reflect the interests of its owners.
Thus, free applications do not normally implement "features" which allow
their users to do less. One might think that the consensus against "antifeatures
in free software is nearly universal, but, as the case of the okular
PDF reader in Debian shows, there
are still exceptions.
The PDF file format includes a number of protection flags which specify
whether the reader is allowed to print the file, make changes, or to copy
out excerpts. There is nothing in the format which actively prevents such
activities; these flags are simply instructions which any application
operating on PDF files is expected to observe. If the "no copy" flag is
set, cutting and pasting text from the file should - by the standard - be disabled in any
reader application. Developers of free applications have, as a general
rule, never quite gotten around to implementing this kind of restriction -
even though the low-level poppler PDF-processing library
makes such support possible. Applications which do implement this
"feature" tend to disable it by default.
This is not the case with Okular, though. An attempt to select text from a
suitably-marked PDF file yields a rather confusing dialog which reads "copy
forbidden by DRM" (see the image to the right). Amusingly, the application
will still allow the selected region to be saved as an image file, but
sending the text to the clipboard is not allowed. There is a configuration
option which disables this behavior, but the default setting is to enforce
the copy restriction flag.
John Goerzen encountered this behavior in
Debian's Okular package; suffice to say he was not pleased. He filed a
bug and asked:
So what I want to know is: why are people putting code into Debian
that limits our freedom? Why are people putting such code into KDE?
And can we please patch it to stop that?
One of the important roles played by distributors is to serve as an
intermediary between upstream projects and their users. If a development
project does something which is not in the interests of its users,
distributors have the opportunity, thanks to free licensing, to fix the
problem. A look at a typical distributor's source packages will reveal
that a number of applications have been patched in ways which change their
behavior and generally make them fit in better. This final bit of finish
is part of the value that distributors add.
Given that it's hard to
find users who are asking for copy restriction features, one might think
that this would be an ideal place for the Debian developers in charge of
Okular to provide a more friendly default.
But they do not want to do that. Okular developer Pino Toscano justifies the copy-restriction antifeature by saying that it's
part of the PDF format specification. Since Okular is meant to follow the
standard, it must do so in this case as well. Beyond that, Pino says:
If tomorrow a corporate person complains that Okular does not
respect the PDF format in that sense and that they cannot make use
of it because of that, what should I tell them? They would be
right. Look, having the "power of developers" does not imply
developers should feel like crackers, disabling restrictions just
because they can or in the name of some "freedom".
Additionally, Debian KDE maintainer Sune Vuorela claims that the overhead of maintaining a
patch to Okular would exceed the value gained - though it has been pointed out that the patch is trivial - and
that the real problem is that people are
downloading PDF files with restrictions in the first place. He states that
Okular should not help users to "violate the conditions of use" associated
with the file, but does not say why, if that is a concern, the ability to
ignore copy restrictions is not patched out altogether.
Beyond that, others have raised concerns that failure to enforce copy
restrictions could lead to legal problems in some jurisdictions. It is not
clear which jurisdictions those would be, though. The copying of excerpts
is allowed by fair use rules almost everywhere. Even the DMCA should not
come into play here; the "do not copy" flag is simply a piece of advice
found in the file which does not constitute an "effective technological
measure" in any way. There has been a distinct shortage of legal problems
(or even threats) associated with any of the other PDF readers which fail
to implement this particular behavior. And, if such threats did exist,
the existence of an option to ignore copy restrictions would be problematic
regardless of its default value.
The evince PDF reader ran into this
issue back in 2005. It is now rare to find a distributor shipping a
version of evince which implements copy restrictions. Xpdf implements copy restrictions
unconditionally, but Debian patched that code out in 2002, and that patch
has spread to other distributors as well. In general, as one would
expect, free PDF readers tend not to implement this behavior. Okular is
about the only exception that your editor can find; it's interesting to
note that the version of Okular shipped with Fedora Rawhide also implements
copy restrictions by default. Perhaps this behavior is result of the
relative newness of this application; as it accumulates more users, the
pressure for more user-friendly behavior is likely to grow.
As that pressure mounts, Okular's developers and packagers may find it hard
to justify keeping copy restrictions in place. Linux, at all levels, has
felt free to ignore standards when following them makes no sense. And one
could argue that the copy-restriction flag - which interferes with fair-use
rights while doing nothing to prevent copying of the file or its contents -
makes little sense indeed. This is not a feature which adds value for
Linux users; such features still tend to disappear over time.
Comments (224 posted)
Some programming languages forge new ground, others are refinements of
previously existing ideas, and still others tackle a specific problem in a
new and better way. This article will look at two up-and-coming languages
that are not yet as widely adopted as C, C++, or Java, but offer developers
some intriguing benefits: Vala and
Clojure. Vala is designed specifically
to build native applications for the GNOME desktop environment, and Clojure
brings the power of Lisp
and functional programming to the Java Virtual Machine (JVM).
GNOME itself is written in C, but many of the higher-level libraries
that make up the GNOME platform (such as GTK+ and Pango) make heavy use of
the GLib and GObject
frameworks, which implement a complete object system including types,
messaging, classes, and all of the other components that make up a typical
object oriented application program interface (API). GObject makes it
possible to write object oriented GNOME applications in C, and also makes
it simple to provide wrappers to GNOME for object oriented languages like
C++ or Python.
While GObject makes object-oriented programming in C possible, it
remains somewhat cumbersome. The GObject wrappers for other languages can
be even worse, introducing yet another layer of dependencies which can
include virtual machines of their own. Vala was created in an attempt to
address these problems and make GNOME programming easier. Vala provides a
C#-like syntax that
integrates GObject features, but the valac compiler compiles to C
rather than assembly. The resulting C compiles normally with gcc, plus it
can be distributed as source packages fully usable on platforms that do not
have Vala installed. That allows the developer to use Vala's modern
language features — dynamic type system, assisted memory management,
and so on — while still making source releases compatible with C
applications and libraries.
In addition to GLib and GObject, the Vala project produces bindings to the major GNOME libraries: GTK+, GDK, Cairo, SDL, GStreamer, D-Bus, GIO, and many more. In addition,
several external projects provide their own bindings for Vala (such as Clutter), and there are third-party efforts
to create bindings for other libraries, such as OpenGL. Plugins for Vala
support are available for the Eclipse, Anjuta, and MonoDevelop IDEs, as well as for the
editors Emacs, Vim, and GEdit. Val(a)IDE, still in development, is a
dedicated Vala IDE written in Vala itself.
The latest release of
Vala is 0.7.3, which went public on May 26, 2009. It is a bugfix release
for the 0.7 series, which is intended to be the last development series
before 1.0. The biggest change in the 0.7 series, according to developer
Jürg Billeter, is to C header file generation. In previous
releases, Vala would generate a .h header file for every
.vala source file,
which caused problems:
This caused various issues when the
dependencies between the .vala source files get complex or more
specifically, circular, and it did not allow us to have internal methods
that can be used in multiple .vala files but remain outside the public
API. Therefore we decided to move to a single public C header file with 0.7
and stop using separate header files for internal methods.
change demanded making changes to the build system for existing Vala
applications, but Billeter said it should be the last such headache for a
Vala 1.0 is scheduled
to be released in September of 2009, coinciding with the release of GNOME
2.28. According to Billeter, the project is on track to make the 1.0
deadline, which will mark the start of a long stable release cycle during
which application developers can count on language stability. The bindings
to GNOME libraries are maintained separately, Billeter said, and are added
to and enhanced on an as-needed basis, so they are not subject to the same
The project offers a tutorial and sample
code for those new to Vala; some familiarity with GObject is expected.
between Vala and C show no significant execution speed losses (in some cases,
Vala even beats plain C).
The project maintains a list
of applications developed using Vala, in whole or in part, including GNOME
panel applets and full-fledged applications. The webcam utility Cheese is currently
maintaining a Vala branch in addition to its main trunk, just to road test
the viability of the language. Billeter noted that although people
generally think of using Vala only when starting a new project, it is
possible to incorporate it into an existing C code base, too. "Among
our users are both, people writing C that now want to move to something
higher level and also people that just start programming in the GNOME
environment," he said.
While Vala is a language designed around a particular object system,
targeting a particular desktop environment, Clojure could not be more
different. It is a dialect of the functional-flavored programming language
implemented on the Java platform. That makes it cross-platform; Clojure
applications are compiled to Java bytecode, so they can run on any platform
with a well-supported JVM.
Creator Rich Hickey has explained that building on top of
the JVM grants Clojure automatic platform stability from a broad user and
developer community, but that itself was not the goal of creating the
language. Hickey's primary interest was concurrency — he wanted the
ability to write multi-threaded applications, but increasingly found the
mutable, stateful paradigm of object oriented programming to be part of the
problem. "Discovering Common Lisp after over a decade of C++, I said
to myself — 'What have I been doing with my life?', and resolved to
at some point code in Lisp. Several years of trying to make that practical,
with 'bridges' like jFli, Foil etc, made it clear that bridges weren't
going to be sufficient for the commercial work I was doing."
Hickey became less enamored of object oriented programming and started
adopting a functional-programming style in his work, which he found to make
the code more robust and easier for him and for his coworkers to
understand. Eventually, maintaining that style in other languages like C#
became more trouble than it was worth:
The idea of a functional Lisp
integrated with a commercially accepted host platform just seemed like
chocolate and peanut butter. It can be hard to remember the exact time in
which you decide to do the crazy thing that is designing a new language -
you just find yourself doing it because you have to. Coming up with
persistent data structures that were fast enough was the tipping point for
my considering it viable.
Clojure does provide persistent data structures, although it does
considerably more. For those unfamiliar, functional programming (the style
from which Lisp and Clojure originate) places a greater emphasis on
functions as first-class objects, meaning that functions can be placed into
data structures, passed as arguments to other functions, evaluated in
comparisons, even returned as the return value of another function.
Moreover, functions do not have "side effects" — the ability to
modify program state or data. This paradigm focuses on computation in the
mathematical sense, rather than procedural algorithms, and is a completely
different approach to programming.
As a language, Clojure is a Lisp-1, part of the same
family of Lisp variants as Scheme,
notable for sharing a single namespace between functions and variables.
Clojure differs from Scheme and other Lisp dialects in several respects documented at the Clojure web site.
For application developers, the most significant distinction is that
Clojure defaults to
making all data structures immutable. To maintain program state,
developers must use one of four special mutable structures that are
explicitly designed to be shared between threads: refs, vars, atoms, and
agents. Clojure uses software
transactional memory (STM) to coordinate changing these mutable
structures while keeping them in a consistent state, much like a
transactional database. This model makes it considerably simpler to write
thread-safe code than it is in object oriented languages. No locks are
required, therefore there are no deadlocks or race conditions.
Like other Lisp implementations, Clojure is interpreted through a console-like
read-eval-print-loop (REPL). The user launches the REPL from a .jar file
and is presented with the REPL command prompt, from which he or she can
load Clojure programs or directly write and execute functions and macros.
The code is compiled on-the-fly to Java bytecode, which is then in turn
executed by the JVM. The REPL environment is much like an interactive IDE
and debugger all rolled into one, but for distribution purposes, Clojure
code can be compiled ahead of
time into ordinary Java applications. Because it is hosted by the JVM,
Clojure can automatically make use of its features, including the type
system, thread implementation, and garbage collector, rather than having to
re-implement each of them. Clojure code can also call Java libraries, opening up
a wealth of classes and interfaces to Clojure programmers.
Clojure 1.0 was released on May
4, 2009. There are several good resources online for learning about the
language and for getting started, although a general introduction to Lisp
is probably warranted for those with no experience in functional
programming. Though there are not large-scale projects using Clojure, an
active community is growing
around it, including several local users' groups. The Clojure site offers
documentation of the language
syntax and examples (including example code), there is a very active Google
forum, and Mark Volkmann's Clojure page at Object
Computing tracks articles, slides, and wikibooks about Clojure.
Vala and Clojure seem to have little if anything in common; one is
object oriented and the other functional, one aimed at a specific desktop
system and the other intentionally cross-platform. They are kindred
spirits in one sense, however — they seek to build a more modern,
robust language implementation on top of an existing, established platform.
Vala's goal is to let C programmers more easily take advantage of the power
of GObject and GNOME, and Clojure's is to let developers easily write
concurrent applications on top of the stability of the JVM.
What is equally important is that both projects maintain bi-directional
compatibility with their underlying languages and platforms. A Vala
program can use any C library, and a C program can use any library written
in Vala. Likewise, Clojure code can be compiled to Java, and Clojure
applications can use any Java class or interface. Such interoperability
will likely increase adoption of both of these languages, and it is a welcome
sight in any project.
Comments (39 posted)
Chrome was released for Windows on September 2, 2008, it attracted
instant attention. With increased speed, security, and stability, Chrome
seemed every bit the modern rethinking of the web browser that Google
proclaimed it. But despite the fact that Chrome is an open source project
with different portions of it released under a variety of free licenses,
the GNU/Linux version is still in early development. However, the recent
availability of regular builds in Ubuntu
packages promises to make casual experimentation with Chrome much easier,
and revived the original interest. Unfortunately, the current state of the
GNU/Linux version seems unlikely to satisfy the level of interest, as the
development team continues to struggle with unexpected challenges.
Asked how many people were part of Chromium, the Google team that is
building Chrome, and how many were working on the GNU/Linux version
specifically, Mike Smith, Product Manager for Google Chrome, declined to
give numbers. "We don't go into details about the number of Google
employees on any particular product," he explained. However, an
of those working on Chrome in September 2008 included 42 names, 3 of whom
had Linux listed as an area of expertise. This number, which has probably
changed in the last nine months, is supplemented by several developers with
experience in writing cross-platform applications, including Firefox
alumnae Darin Fisher, Pam Greene, and Ben Goodger, Chrome's technical
lead. In addition, the Chromium tasks in the
2009 Summer of Code include nine possible GNU/Linux-related improvements
that students might undertake.
Another reason that the numbers are fuzzy, Smith pointed out, is that
Chromium works closely with other Google teams, including Gears, a plug-in that enhances both
online and offline performance of web applications; Native Client, whose goal
is to allow traditional applications to run as web applications; and O3D, which seeks to add 3-D
capabilities to web applications. When such considerations are taken into
account, it seems that, while the Windows version seems to have highest
priority, since it was released first, the GNU/Linux one is still far from
The challenges of designing for GNU/Linux
So far as possible, the code for the GNU/Linux, Mac, and Windows versions
of Chrome "share as much as is possible — not only in terms of
core aspects share with other source projects, such as with the Webkit
team, but also from UI [User Interface] design choices and other
implementation aspects of the technology," Smith said. However, as
the Ars Technica highlighted in a review
of a pre-alpha release, the sheer variety of options under GNU/Linux can
often prove a challenge.
For example, Smith mentions the difficulties of implementing sandboxing
— the running of applications in restricted environments as a
On Windows, getting
a process sandboxed in a way that's useful to us is pretty complicated
— the relevant source code consists of over 100 files and is located
under the sandbox directory in Chromium's Open Source repository. But on
Linux there are a number of different sandboxing mechanisms
available. Different Linux distributions ship with different (or no)
sandboxing APIs, and finding a mechanism that is guaranteed to work on
end-user's machines is a challenge.
The issues include whether to
use ftrace or a modified
version of Seccomp to
intercept system calls for sandboxing, and whether system call interception
is necessarily the best mechanism for sandboxing.
Other challenges in GNU/Linux include the lack of a standard developer's
toolkit, the variety of software available for the same purpose, and the
limitations of the GTK+ toolkit. In the Ars Technica review, the
frustrations with these limits were attributed to Goodger alone. But if you
look at the original
discussion thread, working around the conditions in GNU/Linux are a
challenge for all the Chromium developers. At the very least, the team felt
the need for common standards to simplify their work.
Google Chrome's visual style was designed with
the assumption that the window manager is a stable target. On Windows and
Mac, we have used this assumption to allow the tabs to blend seamlessly
into the window title bar, creating Google Chrome's distinctive skyline. We
also use the dominant system theme (the blue Luna theme on Windows XP, Aero
Glass on Windows Vista, and the standard grey appearance on OS x) to inform
the general appearance.
Building an application with these objectives in mind is much more
challenging on Linux because of the lack of general consensus as to what
the default user interface toolkit, theme system, and window managers
are. Because of how extensively the system can be customized and how
frequently this is actually done by a large number of Linux users, many of
the assumptions that drove the design of Chrome's UI are more challenging
to apply. That said, the Linux team has some clever ideas for how they may
be able to support the best of both worlds, and so I look forward to these
At least part of the time, the solutions that emerged were a compromise or
stopgap measure. For example, despite the team's reservations about the
ability of GTK+ to produce an interface comparable to those on Windows or
OSX, Smith says that "In the end, we decided that GTK+ gave the best
compromise in terms of being able to deliver a quick, clean user experience
that was clearly still Google Chrome."
In much the same way, Smith described the release of nightly builds for
Ubuntu as being due to the fact "that we have to start
even though the plans are to support "multiple popular distributions." He
added that, "Being open source means we're happy to have volunteers provide
support for other, potentially less popular or more specific distros that
we may not get around to for a while."
The Chromium team declined to give an exact road map for the GNU/Linux
version. However, Smith did say that "We hope to release a version of
Google Chrome for Linux on the developer channel very soon." Those
who are interested in tracking Chrome's progress can track it on the developer
Still to come are an extensions
platform intended to give Chrome the rich ecosystem of development
enjoyed by Firefox. Smith also suggested that Chrome's ability to quickly
communication system. "We certainly expect Wave to work best in
modern browser environments which have good support for open web
standards," Smith said.
Meanwhile those wanting to investigate Google Chrome on their own can download
packages from Ubuntu's Launchpad site, which include packages for the last
three Ubuntu releases as well as the upcoming Karmic Koala
release. However, if you do, be warned that, at this stage of development,
there is no guarantee that you will actually be able to run Chrome. On
three separate machines with several different builds and packages, I was
able to install the browser, but received only an "Illegal instruction"
message when attempting to run it.
Such failures are not surprising in software in such an early stage of
development. No doubt, too, the particular hardware and builds figure
heavily in them. All the same, they suggest that the Google could be
hard-pressed to deliver on its promise
of a GNU/Linux release in the first half of this year. At the most, an
early beta might be ready by that deadline.
Meanwhile, users can keep trying the Ubuntu packages. They might also try
compiling the source
code, or downloading Crossover
Chromium, which runs under the WINE code. The only other alternative is
to wait for the still-indefinite final release.
Comments (13 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Google's Native Client; New vulnerabilities in drupal, kernel, libsndfile, php-smart,...
- Kernel: How many page flags do we really have?; Xen again; Page sanitization, part 2.
- Distributions: An interview with openSUSE community manager Joe Brockmeier; openSUSE 11.2 Milestone 2; OpenSolaris 2009.06; Fedora 11 slips again; Some openSUSE Factory changes.
- Development: Jetpack: Firefox extensions as they should be, new versions of MySQL, PowerConsole, BusyBox, TurboGears, SUMMON, GNOME, KDE, Butterfly FPGA, VMPK, HylaFAX, KOffice, IcedTea, Rakudo Perl 6, SLV2.
- Press: Free software in the recession, IBM's Linux mainframe push, Microsoft and Firefox extensions, Novel profits, UN promotes Linux for schools, Python Web Frameworks, Xorg's LLVM, Google Chromium alpha review, multi-core SoC, Nilfs2 filesystem review.
- Announcements: FSF's AdBard, Openmoko's future, PLplot's 10K milestone, USRP v2, 26C3 cfp, ACSAC cfp extended, FRHACK cfp extended, SELinux Summit cfp, DebConf11 call for location, EuroSciPy presentations, LPI's 10th at LinuxTag, PyPy EU Sprints, savannah.gnu.org RAID failure, Bilski goes to Supreme Court.