LWN.net Weekly Edition for June 4, 2009

Okular, Debian, and copy restrictions

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:

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:

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)

A look at two new languages: Vala and Clojure

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).

Vala

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 output 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:

That change demanded making changes to the build system for existing Vala applications, but Billeter said it should be the last such headache for a while.

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 schedule.

The project offers a tutorial and sample code for those new to Vala; some familiarity with GObject is expected. Benchmarks 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.

Clojure

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 Lisp, 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:

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 Groups discussion forum, and Mark Volkmann's Clojure page at Object Computing tracks articles, slides, and wikibooks about Clojure.

Two-way interoperability

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)

Waiting for Google Chrome

When Google 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 unofficial list 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 being neglected.

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 security precaution:

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.

Goodger explained:

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 somewhere," 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."

Looking ahead

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 site.

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 render JavaScript should make it ideal for the recently announced Google Wave, an online collaboration and 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.

Next page: Security>>