User: Password:
|
|
Subscribe / Log in / New account

Leading items

Okular, Debian, and copy restrictions

By Jonathan Corbet
June 1, 2009
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.

[Okular] 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)

A look at two new languages: Vala and Clojure

June 3, 2009

This article was contributed by Nathan Willis

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:

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.

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:

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

June 3, 2009

This article was contributed by Bruce Byfield

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:

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.

Goodger explained:

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 being implemented.

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
Next page: Security>>


Copyright © 2009, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds