Our 2013 predictions started off with an assertion that "the full messiness of the secure boot situation" would come to the fore. In some sense that can be said to have occurred; see the ongoing discussion over the hazards of the kexec() system call, for example. Secure boot has sparked an ongoing debate over what powers the root account should really have. But it also has not turned out, so far, to be anywhere near as messy as some had feared. For the most part, systems with secure boot Just Work, and, when they Just Don't Work, the ability to turn it off is always there.
Also, notably, Microsoft has made no hostile moves toward blocking Linux from booting on machines with secure boot enabled. The threat is always there, though, and it drives the discussion on what functionality can be allowed on secure-boot-enabled systems. It remains true that Linux is subject to the good will of a competing company in this regard, and it may yet come back to haunt us.
Regarding the prediction that maintaining access to our hardware will continue to be a problem: it will not be surprising that such a safe prediction was borne out. Locked-down hardware and hardware requiring proprietary drivers to function continues to exist. On the other hand, there were some good developments if one looks closely. Motorola's decision to continue a handset's warranty after it has been unlocked is one small example, as NVIDIA's first cautious steps to provide documentation to the Nouveau project and Google's open-source firmware work. There are still a lot of problems in this area, but recognition of those problems is widespread.
An even safer prediction was the one that software patent issues would continue to be a problem. Someday, maybe, that problem will be fixed, but that day did not come in 2013.
Your editor predicted that the 3.12 kernel would be released on November 20. Predicting software releases can be hazardous, and your editor will confess that he completely blew it this time around: the 3.12 release happened on November 3, more than two weeks earlier than predicted. Last January's prediction failed to account for one of the more significant changes in the kernel development process: despite the increasing number of changes going into each release, the time required to get through the mainline development cycle is steadily shrinking. A kernel released in 2011 required 74 days to prepare. 2012's releases required 69 days, while, in 2013, that time dropped to 66 days. It will be interesting to see how much farther this trend can go.
The community, your editor predicted, would become increasingly intolerant of unpleasant behavior from its members. The "donglegate" episode in March and the kernel mailing list blowup in July would appear to bear that prediction out. But there is an undercurrent in these discussions that is worth noting: a significant percentage of our community appears to have come to believe that public confrontations and "name and shame" actions can, themselves, make our environment more hostile. There will continue to be pressure for better behavior in the future, but, perhaps, it will take a more subtle form.
Your editor suggested that it may be time for a change of management at the Free Software Foundation and the GNU Project. Regardless of whether it was actually time, no such change occurred or was even discussed.
January's predictions included one to the effect that talk of "vertical integration" would be heard often. In truth, the discussion has abated a bit, but the work in that direction continues at full speed. In many corners of our community it's an article of faith that our scattered approach to development has impeded the success of the Linux platform. Thus far, none of the attempts to create a more integrated platform have come close to rivaling Android, but that could certainly change in the future.
"Some distribution will ship a release based on Wayland," we predicted. Your editor is guessing that RebeccaBlackOS may not be accepted by all readers as a fulfillment of that particular prediction. Major changes to our systems can take a long time to reach users; Wayland is just one more example of a project that has had a lot of maturing to do before it becomes ready for widespread use. The prediction that several new Linux-based platforms would ship was similar; FirefoxOS is, indeed, commercially available, but Sailfish OS and Tizen are just getting off the ground and Ubuntu Touch is even further behind. We will see some interesting Linux-based platforms out there, but we'll have to be patient.
So, as usual, some predictions were hits, and others were not. But it is just as important to ask: what was missed altogether? One thing your editor didn't see coming was Canonical's decision to pass up Wayland and write its own display server. This move stirred up the community which, for the most part, would have rather seen Canonical put its resources into making Wayland better. Whether going its own direction here (as with many other things) will pay off for Canonical remains to be seen.
In retrospect, something like the Snowden leaks had to happen at some point, but it would have been hard to foresee the actuality in 2013. Those leaks have had a significant effect on our community, making it clear that we are under attack, but also that we arguably have the best defense available against institutionalized surveillance. We have always known that closed-source software can act contrary to its users' interests; now the wider world is learning that lesson as well. Free software, in the end, may have an important role to play in maintaining the freedom of our societies.
Something that perhaps should have been foreseen was the funding of the CyanogenMod developers and the formation of Cyanogen Inc. By the time a software project builds up a few million users, somebody with money is bound to be interested in making a company out of it. So far, the funding of CyanogenMod appears to have resulted in quicker releases and the prospect of a handset or two sold with CyanogenMod preinstalled. At some point, though, some sort of revenue model will have to be developed; one hopes that can be done without alienating the CyanogenMod user base.
Finally, none of these could have been predicted, but let us remember one more time the members of our community who we lost this year: Atul Chitnis, Ray Dassen, Jan Schubert, Aaron Swartz, Malcolm Tredinnick, Seth Vidal, and others who certainly deserve mention here. We miss you all.
It was a busy year here at LWN. We put out 51 Weekly Editions, on schedule, containing 459 internally-written feature articles and 56 articles by outside authors. Those editions also included over 4700 security updates, 800 vulnerabilities, and 2000 kernel patches. According to our conference index (added this year), we had coverage from no less than 36 events in 2013; that probably explains why we get a lot of spam from airlines. We have tried to expand our coverage range while maintaining the strength of our core coverage with, we hope, some success. We feel good about what we were able to produce this year.
On the other hand, our in-house writing capability suffered with the departure of Michael Kerrisk in April. While we are not currently actively looking, we remain interested in talking with good writers, especially anybody with an interest in writing on kernel topics.
Individual subscriber numbers remained essentially flat in 2013, as they did in 2012, while the number of group subscriptions grew slightly. Subscriptions remain LWN's life blood; advertising only generates enough money to make us keep it around despite its many frustrations. It would thus be nice to see a return to growth in subscriptions. For those looking for a late gift idea, LWN.net gift certificates are affordable and require no shipping time. Readers who use Linux at work may want to consider getting their employer to buy a group subscription for them; these groups have become an increasingly important part of our subscriber mix.
But above everything else we would like to express our deepest thanks to our reader community which has kept us going through our sixteenth year. Your interest and support are what keeps LWN operating after all these years; it is hard to imagine a better community to write for. Best holiday and new-year wishes to all of you from the LWN staff; we'll be back to do it all again in January.
Game publisher Valve Software released the first installation images of its Linux-based SteamOS late on Friday the 13th of December. Valve had announced the SteamOS project at LinuxCon North America in September, calling it the best way to push video game development forward as Windows and proprietary game consoles become increasingly difficult to develop for. Since that announcement, the Linux community has been eager to take a peek at the first release—as has the gaming community, albeit for different reasons. Now that the first beta of SteamOS has hit the street, it is undergoing scrutiny from both angles. While gamers presumably have a lot to gain from a leaner and more customizable operating system, SteamOS's impact on Linux as a whole may be harder to pin down.
The SteamOS beta (dubbed "Alchemist") was announced on the Steam Universe discussion forum on December 13. Officially speaking, installing SteamOS on one's own hardware is regarded as "building your own Steam Machine," since Valve's primary target for the project is developing an OS for Steam Machines: living-room consoles built out of commodity PC hardware. Two downloads are available; one is a cloned disk image designed to be written directly to a hard drive, while the other is a more traditional installer meant for a USB thumb drive.
The installer route requires several steps, including logging in with one of the pre-defined user accounts and setting up the Steam client software, then logging in again with a different account and running a post-installation script. Despite that manual process, the installer is configured to automatically repartition the computer's first hard drive and install SteamOS over it, so testing the release does require dedicating some hardware for the task (primarily meaning a dedicated hard disk, although it should also be noted that multiple monitors and other hardware configurations have been found to prevent SteamOS from running). Valve also imposes some hard requirements on the machine itself (such as requiring UEFI boot), in addition to some softer demands on component selection. For instance, the release FAQ says that only NVIDIA graphics cards are supported, but early investigators discovered that drivers are included for AMD and Intel GPUs as well.
A workaround is required to get the installer to boot on a non-UEFI system, but it is possible. Shortly after the release announcement, volunteers at Reddit began dissecting the installer to modify it for use on older BIOS machines.
Out of the box, SteamOS offers two login sessions: one devoted solely to running the Steam client software, and one that presents a largely unmodified Linux desktop environment. Lest there be any confusion, the Steam client software is not open source, and it requires agreeing to a EULA and setting up a Steam account in order to get started. SteamOS also includes binary video drivers for the target graphics cards.
The basic operating system itself, however, is a bare-bones Debian 7.1 with a set of patches applied to hone gaming performance. Valve has an Apt repository running at repo.steampowered.com/steamos/ where one can scrutinize the included packages. The major changes are an updated and patched 3.10 kernel (Debian uses 3.2), an eglibc 2.17 (backported from Debian sid; Debian 7.1 includes 2.13), and a custom display compositor.
The compositor attracted considerable attention in discussion forums at release time, with plenty of Linux users evidently eager to hear whether SteamOS would "take sides" in the race between Wayland and Mir. Both camps were no doubt let down that Valve went with neither option. Instead, steamos-compositor is adapted from the venerable xcompmgr, a lightweight X.org compositor much older than Wayland and Mir. Perhaps that should be no surprise; as the release FAQ put it, the compositor is designed to provide nice transitions between the Steam client and games—which, presumably, will run full screen OpenGL. Those keeping score on intra-community competition will also want to note that SteamOS uses sysvinit, rather than systemd or Upstart (although, to be frank, it is hard to imagine anyone who had a strong opinion about any of these debates being particularly swayed by Valve's choices for SteamOS).
The choices for the kernel and graphics drivers are probably of more general interest. The kernel package [tar.xz] includes, among others, a large number of realtime patches and a patch set for the aufs union filesystem. Ostensibly, the issue that Valve cares most about is improving game performance (and indeed Valve is reported to have worked on improvements to the binary NVIDIA drivers included with SteamOS). Over at Phoronix, Michael Larabel posted a set of benchmarks running the NVIDIA binary drivers on the SteamOS kernel, a vanilla 3.10 kernel, and the most recent Ubuntu kernel. Larabel's level of detail is thorough as always, but his results show the SteamOS kernel to provide the lowest framerate performance of the bunch (although he also notes that the beta testing itself is probably what will lead to improvements).
Then again, there are plenty of other factors that go into gaming performance. Framerate is generally viewed as a simple metric for apples-to-apples comparisons—all else being equal, if altering one component on the system can draw frames to the screen faster, then it should be able to do everything else faster. What Valve expects from the realtime patches is unclear; realtime offers deterministic performance but rarely if ever does it offer faster performance. There are certainly metrics that the kernel could be optimized for, but it would be more informative to hear from Valve about their choices. Things like delivering reliable network performance, in order to reduce perceived lag between the game client and the remote server, are usually high on gamer's lists after framerate, as is responsiveness to input. Aufs is probably used for simple backup and restoration (which is important for any "appliance" computer); the SteamOS installer creates a recovery image as soon as it has finished pulling in package updates on first run.
On the gaming front, sadly, I must confess that I am simply not a gamer at heart—and thus not qualified to dispense advice on game performance where SteamOS or anything else is concerned. I installed the SteamOS beta on a machine that primarily serves as a home theater PC (HTPC). Thus the box is connected to a flatscreen TV, and is about ten feet from seating (which is the canonical distance for this sort of user experience). But the hardware in question sports an aging-by-today's-standards fanless video card whose specs would probably make most dedicated gamers weep with sorrow. It is an NVIDIA card, though, so SteamOS's "BigPicture" interface will run on it without any tweaking.
The experience is certainly smooth, and it is easier to get started with than many other distributions. On the other hand, the desktop session is a bit of a puzzle in light of SteamOS's stated purpose. Users can launch a run-of-the-mill GNOME 3 or GNOME Classic session, but there is not much software available from Valve's SteamOS repositories. Other than Iceweasel and development tools, it is a bare-bones environment. One can add the Debian repositories, of course, and apart from conflicting kernel and eglibc packages set up more or less a standard desktop Linux system. The SteamOS FAQ notes that Valve may expand the package set its repository provides, but says little else. Thus it is hard to escape the feeling that Valve is not terribly interested in what people do with the SteamOS "desktop" experience. There is no guidance for users, and the Steam site still recommends that users interested in running Linux go download Ubuntu.
The company is open about its intention for Steam Machines to supplant console video game systems; as such, it may not care at all what else users do with their hardware. Linux is still an officially supported platform for the Steam client, but more of Valve's marketing muscle about consumer desktops is focused on Steam's ability to stream game content live from one machine (say a Steam Machine) to another (for example, a Windows box).
That may mean that only a few SteamOS users will ultimately be drawn into desktop Linux usage. Of course, the size of the PC gaming market is so enormous that even a tiny percentage of its users could constitute a massive influx. The company's current statistics show around 6.3 million concurrent users at the daily peak. But so far there is no indication that Valve has any interest in becoming a "normal" Linux distribution. So any additional users are most likely to end up either in Debian directly or perhaps with a derivative like Ubuntu.
From a distribution development standpoint, though, SteamOS could provide considerable benefits to the rest of the Linux community: a slice of those 6.3 million concurrent users would no doubt push improvements to video drivers to start with (hopefully both binary and open source, as gamers are wont to try everything in search of additional performance). Getting games running on SteamOS is likely to impact OpenGL game development and debugging tools, and result in more work on compositing performance (again, mostly through Valve's compositor, but others would likely be put to the test, too). Furthermore, the last big element in Valve's SteamOS push is the next-generation "Steam Controller" (which is currently only available to designated beta testers). The good news there, however, is that the controller presents itself as a standard USB HID-class peripheral, which means it should work out of the box on Linux systems.
It is also worth noting that, whatever Valve's plans involve for the desktop, at the moment the SteamOS release is available through the Apt repository alone. While it would be nice for the company to work upstream and host source in public version control, they are not doing so at the moment. Certainly they are not obligated to do so, but one would hope that it is a step still to come. Valve does host a public issue tracker for SteamOS on GitHub, so there is reason to be hopeful.
SteamOS may yet evolve to become a major factor in desktop Linux development, or it may remain an appliance-like specialty distribution focused on its own core mission. In either case, the rest of the Linux community has something to learn by watching its progress—millions of prospective users are nothing to sneeze at. Perhaps the best advice other distributions could heed in the wake of the first SteamOS release is that they should get ready, watch how Valve's kernel tweaks impact performance, and listen to what all of those new-to-Linux users have to say about their first foray into the Linux desktop.
Here is LWN's sixteenth annual timeline of significant events in the Linux and free software world for the year. As per tradition, we divide up the timeline up into quarters; this is our account of October–December 2013. Timelines are also available covering was January through March, April through June and July through September; the combined timeline for all of 2013 will appear after the start of the new year, including any late-breaking stories.
There are almost certainly some errors or omissions; if you find any, please send them to firstname.lastname@example.org.
LWN subscribers have paid for the development of this timeline, along with previous timelines and the weekly editions. If you like what you see here, or elsewhere on the site, please consider subscribing to LWN.
For those readers in a retro mood, our timeline index page includes links to the previous timelines and other retrospective articles that date all the way back to 1998.
GNU Make 4.0 is released (announcement).
The AtypI Conference is held in Amsterdam, October 9 to 13 (LWN coverage).
-- Chris DiBona
Wayland / Weston 1.3 is released (announcement).
Version 2.0 of the Cinnamon desktop environment is released (announcement).
XBMC DevCon 2013 is held in Munich, October 11 to 13 (report).
LinuxCon Europe is held in Edinburgh, October 21 to 23 (LWN coverage).
-- Russ Nelson
GStreamer Conference 2013 is held in Edinburgh , October 22 to 23 (LWN coverage).
The 2013 Kernel Summit is held in Edinburgh, October 23 to 25 (LWN coverage).
The Yocto project releases version 1.5 (announcement).
The Open Source Initiative appoints Patrick Masson as General Manager (announcement).
Embedded Linux Conference Europe is held in Edinburgh, October 24 to 25 (LWN coverage).
The Fall Automotive Linux Summit is held in Edinburgh, October 24 to 25 (LWN coverage).
The Linux Foundation elects its Technical Advisory Board for the coming year (announcement).
Cisco announces the release of a BSD-licensed H.264 video decoder and promises to absorb all of the MPEG-LA licensing costs associated with its use downstream (announcement). Mozilla announces that it will include the decoder in Firefox.
The first Tizen-powered tablet goes on sale in Japan (report).
The Realtime Linux Workshop is held in Lugano, October 28 to 31 (LWN article). Realtime patchset maintainer Thomas Gleixner expresses concern for the future of the project.
Former Lavabit and Silence Circle founders announce the Dark Mail Alliance, whose mission (in the wake of the Snowden disclosures and subsequent government investigations) is to bring end-to-end email encryption to the masses (LWN article).
OpenBSD 5.4 is released (announcement).
Debian debates whether and how to select an init–replacement system, a technical choice on which the distribution has previously remained silent (LWN article).
SystemTap 2.4 is released (announcement).
Blender 2.69 is released (announcement).
PyDev 3.0 is released (announcement).
Django 1.6 is released (announcement).
This just confirms my theory that most parts of this industry just work by chance.
Valgrind 3.9.0 is released (announcement).
The Korea Linux Forum is held in Seoul, November 13 to 14 (LWN coverage).
Dart SDK 1.0 is released (announcement).
The Go language celebrates four years (announcement).
openSUSE 13.1 is released (announcement).
Creative Commons releases version 4.0 of its licenses for artistic and creative works (LWN article).
Checkpoint/restore tool 1.0 is released (announcement).
The Jailhouse hypervisor is announced (announcement).
OpenMandriva Lx 2013.0 is released, the first stable release from the OpenMandriva Association (announcement).
*but*, I'm not saying that's actually what we should do. I quite like building exciting prototypes. Building Corollas probably ain't as much fun.
CyanogenMod 10.2.0 is released, marking the last CM release to be based on the Android 4.3 code (announcement).
Keith Packard joins the Debian Technical Committee (announcement).
Version 39.0 of the Emacspeak audio desktop is released (announcement).
GCC gains a front-end for the Rust language (announcement).
EFL 1.8 is released (announcement).
CyanogenMod begins integrating end-to-end encrypted messaging via WhisperPush (LWN article).
KDevelop 4.6.0 is released (announcement).
Firefox 26 is released. Among other changes, this release implements H.264 decoding on Linux via a GStreamer plug-in (announcement).
-- Mel Gorman
FreeBSD decides that it no longer regards crypto chips from Intel and Via as trustworthy, in light of allegations about secret US government efforts to weaken cryptographic algorithms (Ars technica report).
The Linux Foundation announces the AllSeen Alliance to work on standards and best practices for "Internet of Things"–style projects (announcement).
Fedora 20 is released (announcement).
Google becomes an Open Invention Network board member (announcement).
Page editor: Jonathan Corbet
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds