LWN.net Weekly Edition for February 7, 2013

LCA: Linux gaming at last

At the beginning of his talk on Linux game development at linux.conf.au 2013, Eric Anholt noted that his original motivation for getting into graphics driver development was that he wanted to be able to play games on alternative operating systems. At that time, there were a few games available, but the graphics drivers were in such a poor state that he ended up working on drivers instead of playing games. Thus, he has now been working in Intel's graphics driver team for seven years; currently, he works mainly on Mesa's OpenGL graphics drivers.

Eric's talk took the form of a short review of some recent history in Linux game development followed by a description of his experiences in the Intel open source graphics driver team working with Valve Software to port the Steam game platform to Linux.

Recent history of game development on Linux

Eric started with a summary of significant changes that have taken place in the graphics stack over the last seven years. These changes include kernel mode setting and improvements to memory management so that multiple processes can reliably employ memory on the graphics card. On the OpenGL side, things have improved considerably. "Back when I started, we were about ten years behind". The then-current OpenGL version on Linux was 2.1, no modern games ran on Linux, and there was no OpenGLES on Linux. However, by now, Linux supports OpenGL 3.1 and has reached Khronos-certified OpenGLES 2.0 conformance, and Open GLES 3.0 certification seems to be quite close.

Development of open source games seems to have lagged. Eric suggested a number of reasons for this. One of these is that creating a game requires building a multi-talented team composed of artists, developers, and designers. It's difficult to put a team like that together. And then, even if one does manage to assemble such a team, it's hard to agree on a direction: when it comes to game design, the design space is so large that it can be difficult to agree on what you are creating. Finally, the move into open source game development means that you spend less time doing the thing you want to do: playing games.

Nevertheless, there have been a few open source games, such as etracer (Extreme Tux Racer), Neverball, Xonotic, Foobillard, and Wesnoth. In addition, there were closed source games such as Quake (later open sourced), Unreal Tournament 2004, Loki, Minecraft, and whatever users could force to run with Wine.

In May 2010, the Humble Indie Bundle appeared. The concept was a package of games made available DRM-free, with the user choosing the price that they would pay. "They've actually released some surprisingly good games for Linux." One of those games was Braid, and Eric noted that the developers who participated in Humble Bundle learned an important lesson from an earlier attempt to port that game to Linux.

The developer of Braid, Jonathan Blow, made a blog post asking for help on how to port Braid to Linux, asking questions such as "how do I deal with mouse grabs, so that mouse clicks only go to the game window?" and "how do I output sound?" The community did try to help: in all, the blog post got 251 responses, many of them containing directly conflicting advice. In response, the developer gave up: he couldn't justify spending the time to determine the correct way to do the port for what was a small target market.

The lesson that the Humble Bundle developers learned from the Braid experience was that game developers should not be burdened with the task of porting games. So instead, they employed Ryan C. Gordon, a developer who had already ported a number of games to Linux, to port all of their games. This approach has been surprisingly successful at quickly getting games to run on Linux.

Working with Valve on the Linux port of Steam

There have been petitions for Valve Software to port Steam to Linux for as long as Steam has been around, Eric said. The Intel graphics driver team started working with Valve Software in July 2012. During the porting project, the Intel team had access to the Steam source code and worked with Valve on both tuning Steam to work better with the Mesa graphics library and tuning Mesa to work better with Steam. The closed beta test for the port was started in November 2012, and the open beta started in December. The port included the Steam's Source engine and the game Left For Dead 2.

The cooperative work between the graphics developers and Valve proved to be quite productive, but in the process, the graphics developers learned about a number of things that Valve found really disappointing. The first of these disappointments concerned ARB_debug_output. This is an extension in the Windows development environment for OpenGL that provides a general event logging infrastructure between the graphics layer on one side and middleware and applications on the other side. This is an important debugging tool in the Windows environment, "where you don't really have the console so much". There is an implementation of ARB_debug_output in Mesa, but it is rudimentary, supporting only two event types.

Another major disappointment concerned bad debugging and performance-measurement tools. The Valve developers described the tools they used for debugging on Windows, and wanted to know what equivalents existed on Linux. In response, the graphics developers were excited to show Valve an API-tracing tool that they had developed. API tracing is a technique that is extremely useful for driver developers because it allows them to obtain a reproducible trace of the graphics operations requested by the application. This means driver developers can get the application out of the way while they replay the trace in order to debug problems in the driver or improve the driver's performance. However, this sort of low-level tool provides little assistance for analyzing performance at the application level.

By contrast, Windows has some good tools in this area that allow the application programmer to insert tracepoints to track application steps such "starting to draw the world", "starting to draw a figure", and "starting to draw a helmet". This enables the application developer to obtain a hierarchical view of performance and determine if (say) drawing helmets takes a long time. Linux has to do a lot to catch up in this area.

The Valve developers also complained that Mesa was simply too slow. Many of the code paths in Mesa are not well optimized, with enormous switch statements containing nested conditionals. One possible solution is to offload some of the graphics work onto a separate thread running on a different core. Some work has been done in this area, but, so far, performance is no better than for the existing single-threaded approach. More work is required.

Notwithstanding the disappointments, there were other aspects of working on Linux that the Valve developers loved. For example, they greatly appreciated the short development cycles that were made possible when using open source drivers. Although the support for ARB_debug_output was poor on Linux, the Valve developers were impressed when Eric was able to quickly implement some instrumentation of driver hotspots, so that the driver would log messages when the application asked it to carry out operations that were known to perform poorly. The Valve developers were also surprised that the logging could be controlled by environment variables, so that the same driver would be used in both quiet and "logging" mode.

A final pleasant surprise for the Valve developers was that drivers could be debugged using breakpoints. That possibility is unavailable with closed source Windows drivers. More generally, the Valve developers don't have much insight into the closed source drivers that they use on Windows (or, for that matter, closed source drivers on Linux). Thus, they have to resort to experimentation to form mental models about performance problems and how to get around them.

Concluding remarks

For gaming enthusiasts, the announcement by Valve—one of the largest producers of game software—that Steam would be ported to Linux was something of a watershed moment. The Linux gaming landscape is poised to grow much bigger, and even those of us who are not gamers can reflect that a much-improved games ecosystem will at the very least widen interest in Linux as a platform for desktop computer systems.

Comments (17 posted)

FOSDEM: State of the GNUnion

The Free Software Foundation (FSF) has received criticism in recent months for its copyright assignment policies and for being slow in dealing with reported GPL violations. In a talk at FOSDEM on February 3, John Sullivan, the Executive Director of the FSF, addressed some of these issues. In his "State of the GNUnion" talk, Sullivan highlighted the FSF's recent licensing and compliance activities and described challenges that are important to the organization for 2013.

Licensing and Compliance Lab

Sullivan started with an overview of the members of the Licensing and Compliance Lab and its activities. The team is led by Josh Gay, the former FSF campaigns manager, and Donald Robertson, who has been handling copyright assignments for some time. While Sullivan helps to define the overall strategy employed for licensing in order to promote freedom, the team is supported by Richard Stallman, Bradley Kuhn (a Director of the FSF) and lawyers from the Software Freedom Law Center, in particular Aaron Williamson and Eben Moglen. Finally, there's a team of volunteers that helps out with questions that come in through the licensing@fsf.org address. Sullivan noted that it is important for the FSF to communicate with people about license choices and related topics.

The Licensing and Compliance Lab focuses on a number of areas. A big one is the production of educational materials about GNU licenses. It also investigates license violations, especially for code entrusted to the FSF. Finally, it certifies products that use and require only free software.

Licensing is important, Sullivan said, because all software is proprietary by default. The GPL grants rights to users and he believes that the GPL is the right license to boost free software adoption. He mentioned claims that the use of the GPL is declining, but criticized those studies for not publishing their methodology or data. His own study, based on Debian squeeze, showed that 93% of packages contained code under the GPL family. He noted the difficulty of measuring GPL adoption: does a package count if it contains any GPL code, or should you count lines of code? And what about software that is abandoned? Sullivan noted that his interest in GPL adoption is obviously not because the FSF makes money from licensing but because of his belief that the GPL provides the "strongest legal protection to ensure that free software stays free".

Sullivan highlighted a new initiative to create more awareness of GNU licenses. The lab has started publishing interviews on its blog to share insights about the license choice of different projects. Recent posts have featured Calibre and Piwik.

Compliance efforts and copyright assignment

The FSF collects copyright assignments in order to enforce the GPL, Sullivan said, but there are a number of misconceptions about that. He explained that the GNU project does not mandate copyright assignment and that individual projects have a choice when they join the GNU project. However, if a project has chosen to assign copyright, all contributions to that project have to be assigned to the FSF.

The FSF hears frequent complaints that the logistics of copyright assignment slow down software development within the GNU project. It has made a number of changes to improve this process. Historically, the process involved asking for information by email, then mailing out a paper form, getting it signed, and then sent back. These days, the FSF can email out forms more quickly. It also accepts scanned versions in the US and recently expanded this option to Germany after getting a legal opinion there. Sullivan noted that the laws in many places are behind the times when it comes to scanned or digital signatures. Having said that, the FSF is planning to accept GPG-signed assignments for some jurisdictions in the future.

Sullivan lamented that the FSF's copyright assignment policy is often used by companies to justify copyright assignment. He noted that there are significant differences between assigning copyright to an entity like the FSF and a company with profit motives. Not only does the FSF promise that the software will stay free software but it would also jeopardize FSF's non-profit charity status if they were to act against their mission.

One reason the FSF owns the copyright for some GNU projects is to perform GPL enforcement on behalf of the project. He discussed recent complaints that the FSF is not actively pursuing license violations, notably the issues raised by Werner Koch from the GnuPG project. Sullivan explained that this was, to a large degree, a communication problem. The FSF had in fact gone much further than Koch was aware of, but they failed to communicate that. He promised to keep projects better informed about the actions taken. Unfortunately, a lot of this work is not discussed publicly because of its nature. The FSF usually approaches companies in private and will only talk about it in public if no agreement can be reached. Also, if it comes to legal action, the FSF once again cannot talk about it in public.

The lab closed 400 violation reports in 2012, Sullivan said. Out of those, some turned out not to be violations at all, but the majority of violation reports were followed up by actions from the lab that resulted in compliance. He also noted that the FSF is planning to add additional staff resources in order to respond to reported violations more quickly.

JavaScript and non-free code running in browsers

Sullivan then went on to cover a number of challenges facing the free software world. Richard Stallman described the "JavaScript Trap" a few years ago, which is the problem of non-free code running in web browsers.

Sullivan explained that these days browser scripts can be quite advanced programs but "for some reason we've been turning a blind eye" to their typically non-free nature. The FSF is spending a lot of time on tackling this problem and has created LibreJS, which is an extension for Mozilla-based browsers. LibreJS identifies whether JavaScript files are free software, and it can be configured to reject any script that's not free.

In order for this to work the FSF developed a specification that web developers can follow to mark their JavaScript code as free software. Developers can either put a specific header in their JavaScript files or publish license information using JavaScript Web Labels. Gervase Markham pointed out that Mozilla uses web server headers and Sullivan agreed that LibreJS could be enhanced to support that method too.

Sullivan added that many JavaScript files are free software already, but that developers have to start marking them as such. They are working with upstream projects, such as MediaWiki and Etherpad Lite, on doing so.

Certification program

The FSF has launched a certification program to identify hardware that only uses free software. It wants to make it easy for people to care. Sullivan emphasized that the label has to be attractive and hopes it will cause manufacturers to respect user freedom more. He showed a different label similar in style to the warning note on a cigarette package ("This product may contain material licensed to you under the GNU General Public License") and explained that this "is not what we want to do". The actual logo (seen at right) shows the Liberty Bell along with the word "freedom". The first product to achieve certification is the LulzBot 3D printer.

User freedom

As an alternative to Android, Sullivan recommended Replicant—a fully free Android distribution—for those willing to sacrifice some functionality (such as WiFi and Bluetooth on Sullivan's mobile phone) for freedom. He also encouraged Android users to take advantage of the F-Droid Repository to download free software apps for their devices. F-Droid also provides the option to make donations to the authors of the free software apps.

Sullivan also briefly commented on UEFI secure boot. He said that while the FSF is obviously "annoyed by it", it is not fully opposed—there is nothing inherently wrong with secure boot as long as the power remains with the users. However, it's important to make a distinction with what he called "restricted boot". Restricted boot can be found on ARM-based Windows devices which lock down the device and don't give users any choice. This is obviously not acceptable, according to the FSF.

Concluding remarks

Sullivan gave an interesting overview of the FSF's recent activities and upcoming challenges it intends to tackle. He is aware of concerns that have been expressed by members of the GNU community in recent months and is keen to improve the situation. The talk showed that the FSF is working on many activities and that it hopes to improve and expand its work as funding allows.

Comments (28 posted)

Trademarks and their limits

A user looking for the Firefox browser on a Debian system may come away confused; seemingly, that program is not shipped by Debian. In truth, the desired software is there; it just goes under the name "iceweasel." This confusing naming is a result of the often controversial intersection of free software and trademarks. Critics claim that trademarks can remove some of the freedoms that should come with free software, while proponents assert that trademarks are needed to protect users from scam artists and worse. A look at the activity around free office suites tends to support the latter group — but it also shows the limits of what trademarks can accomplish.

The core idea behind a trademark is that it gives the owner the exclusive right to apply the trademarked name to a product or service. Thus, for example, the Mozilla Foundation owns the trademark for the name Firefox as applied to "computer programs for accessing and displaying files on both the internet and the intranet"; a quick search on the US Patent and Trademark Office site shows other owners of the name for use with skateboards, bicycles, wristwatches, power tools, and vehicular fire suppression systems. Within the given domain, the Mozilla Foundation has the exclusive right to control which programs can be called "Firefox". The Foundation's trademark policy has been seen by some as being overly restrictive (almost no patches can be applied to an official release without losing the right to the name); that is why Debian's browser is called "Iceweasel" instead. But those same restrictions allow the Mozilla Foundation to stop distribution of a program called "Firefox" that sends credit card numbers to a third party.

The Document Foundation (TDF) owns a trademark on "LibreOffice" in the US, while the Apache Software Foundation (ASF) owns "Apache OpenOffice" and "OpenOffice.org". Both foundations have established trademark usage policies (TDF, ASF) intended to ensure that users downloading their software are getting what they expect: the software released by the developers, without added malware. Without this protection, it is feared, the net would quickly be filled with corrupted versions of Apache OpenOffice and LibreOffice that would barrage users with ads or compromise their systems outright.

How effective is this protection? To a degree, trademarks are clearly working. Reports of systems compromised by corrupt versions of free office suites are rare; when somebody attempts to distribute malware versions, trademarks give the foundations the ability to get malware distributors shut down relatively quickly. It seems hard to dispute that the application of trademark law has helped to make the net a somewhat safer place.

Questionable distributors

One might ask: safer from whom? Consider, for example, a company called "Tightrope Interactive." Tightrope was sued by VideoLan.org (the developers of the VLC media player) and Geeknet (the operators of SourceForge) in 2010; they were accused of "trademark infringement, cyberpiracy and violating California's consumer protection law against spyware." Tightrope had been distributing "value-added" versions of VLC from its site at vlc.us.com; it was one of many unwanted VLC redistributors during that time. That litigation was settled in 2011; the terms are mostly private, but they included the transfer of vlc.us.com over to VideoLan.org, ending the use of that channel by Tightrope.

On Friday, April 15, 2011, Oracle announced that OpenOffice.org would be turned into a "community project" of an (at that point) unspecified nature. On April 18 — the next business day — Tightrope Interactive filed for ownership of the OpenOffice trademark in the US. That application was eventually abandoned, but not willingly; as Apache OpenOffice contributor Rob Weir recently noted in passing, "It took some special effort and legal work to get that application rejected." Companies in this sort of business clearly see the value in controlling that kind of trademark; had Tightrope Interactive been successful, it would have been able to legally distribute almost any software under the name "OpenOffice." The fact that the project successfully defended the trademark in this case should impede the distribution of corrupted versions of Apache OpenOffice in the future.

Sample OpenOffice ads

Or so one would hope. Your editor's daughter recently acquired a laptop computer which, alas, appears to be destined to run a proprietary operating system. After looking for an office suite for this machine, she quickly came asking for help: which version should she install? In fact, one need not search for long before encountering ads like those shown to the right: there is, it seems, no shortage of sites offering versions of OpenOffice and paying for ad placement on relevant searches. One of those — openoffice.us.com — just happens to be run by the same folks at Tightrope Interactive.

A quick search of the net will turn up complaints (example) about unwanted toolbars and adware installed by redistributed versions of OpenOffice, including Tightrope's version. This apparently happens often enough that the Apache OpenOffice project felt the need to put up a page on how to safely download the software, saying:

This problem is not restricted to Apache OpenOffice; a search for LibreOffice will turn up a number of similar sites. Given that, one might well wonder whether trademarks are actually living up to the hopes that have been placed on them. Isn't this kind of abusive download site just the sort of thing that trademarks were supposed to protect us from?

One answer to that question can be found on one of the LibreOffice download sites, where it is noted that clicking on the "Download" button will start with the "DomaIQ" installer. This bit of software is described in these terms:

Herein lies the rub. The version of Apache OpenOffice or LibreOffice offered by these sites is, most likely, entirely unmodified; they may well be shipping the binary version offered by the project itself. But the handy "installer" program that runs first will happily install a bunch of unrelated software at the same time; by all accounts, the "suggestions" for "additional free software" tend to be hard to notice — and hard to opt out of. So users looking for an office suite end up installing rather more software than they had intended, and that software can be of a rather unfriendly nature. Once these users find themselves deluged with ads — or worse — they tend to blame the original development project, which had nothing to do with the problem.

The purveyors of this software are in complete compliance with the licensing and trademark policies for the software they distribute; at least, those that continue to exist for any period of time are. That software is unmodified, links to the source are provided, and so on. What they are doing is aggregating the software with the real payload in a way that is quite similar to what Linux distributors do. Any attempt to use trademark policies to restrict this type of aggregation would almost certainly bite Linux distributors first.

Consider an example: a typical Linux distribution advertises the fact that it includes an office suite; it also comes with an installer that can install software that presents advertisements to the user (the music stores incorporated into media players, for example, or Amazon search results from Unity), phones home with hardware information (Fedora's Smolt) or exposes the system to external compromise (Java browser plugins). It is hard to imagine a trademark policy that could successfully block the abuses described in this article while allowing Linux distributors to continue to use the trademarked names. Free software projects are generally unwilling to adopt trademark policies of such severity.

As a result, there is little that the relevant projects can do; neither copyright nor trademark law can offer much help in this situation. That is why these projects are reduced to putting up pages trying to educate users about where the software should actually be downloaded from. The conclusion that one might draw is that trademarks are only partially useful for the purpose of protecting users. They can be used as a weapon against the distribution of overtly compromised versions of free software programs, but they cannot guarantee that any given distribution is safe to install. There is still no substitute, it seems, for taking the time to ensure that one's software comes from a reliable source.

Comments (58 posted)

Page editor: Jonathan Corbet

Inside this week's LWN.net Weekly Edition

• Security: CSP for cross-site scripting protection; New vulnerabilities in chromium, java, libupnp, samba, ...
• Kernel: User-space lockdep; A simplified IDR API; Trinity.
• Distributions: Systemd lightweight containers; Fedora ARM, Linaro, ...
• Development: GNOME developer experience hackfest; KDE 4.10; MySQL 5.6.10; developing for GNOME; ...
• Announcements: GNOME's Outreach Program for Women, The FSF licensing team's 2012 report, LCA and FOSDEM videos, ...

Next page: Security>>