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
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
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
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:
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
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.
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)
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 email@example.com
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
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
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
assign copyright, all contributions to that project have to be assigned to
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
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
Sullivan then went on to
cover a number of challenges facing the free software world. Richard
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
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
pointed out that Mozilla uses web server headers and Sullivan agreed that
LibreJS could be enhanced to support that method too.
that developers have to start marking them as such. They are working with
upstream projects, such as MediaWiki and Etherpad Lite, on doing so.
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
logo (seen at right) shows the Liberty Bell along with the word "freedom". The first
product to achieve certification is the LulzBot 3D printer.
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
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.
Sullivan gave an interesting overview of the FSF's recent activities and
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
Comments (29 posted)
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
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
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
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:
When we at the Apache OpenOffice project receive reports like this
-- and we receive them a couple of times every week -- the first
thing I ask is, "Where did you download OpenOffice from?" In
today's case, when the user checked his browser's history he found
what I suspected, that it was not downloaded from
www.openoffice.org, but was a modified version, from another
website, that was also installing other applications on his system,
programs that in the industry are known as "adware", "spyware" or
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
DomaIQ™ is an install manager which will manage the installation of
your selected software. Besides handling the installation of your
selected software, DomaIQ™ can make suggestions for additional free
software that you may be interested in. Supplemental software could
include toolbars, browser add-ons, game apps, and other types of
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, ...