Your editor was strongly tempted to skip out on the task of writing the
2012 year-end retrospective article. After all, the process of going
through January's predictions and seeing how wrong they were is somewhat
painful and embarrassing. Even worse, according to reliable sources, the
world is scheduled
just after this article is to be published, so it
hardly seems worth the effort. But a quick consideration of how your
editor's investment portfolio has performed under the guidance of similarly
reliable sources suggests that covering all the bases might be prudent;
it seems that some other peoples'
predictions are even worse than those found here.
So, with a heavy heart, the process of reviewing last January's predictions began. And, in
fact, the news wasn't all bad. The mobile patent wars did, indeed, get
worse, to the point that it has gotten difficult to market certain devices
in certain parts of the world. The fight for a free Internet continues,
and SOPA was turned back as predicted. Red Hat did indeed have a good
year. A number of the other, relatively obvious predictions also came
through reasonably well. There is value, it seems, in not going too far
out on a limb.
Another prediction read that we would see more focused competition between
distributors, with each seeking to differentiate more from the others. To
an extent that has certainly happened; witness all the work that has gone
into making Ubuntu different from the rest. Other times, though,
differences have not been seen as a selling point; Oracle's attempt to woo
CentOS users is a case in point. So this prediction was, at best,
only partially right. In the end, we are still far from having an
understanding of what makes a perfect Linux distribution, even when judged
through the narrow lens of commercial success.
At the beginning of the year, it appeared that the Linux Mint project had
taken on too many projects; given that it had several versions of its
distribution to support, along with two desktop forks, your editor
reasoned that a
"reckoning with reality" was in the works. At the end of the year, one
might conclude that progress has slowed in some areas, especially with the
MATE desktop. But, if a "reckoning with reality" has occurred, it must be
concluded that reality does not drive a particularly hard bargain. The
Linux Mint project appears to be vital and healthy.
Similarly, one might well conclude that the LibreOffice project is
broader-based and stronger than Apache OpenOffice, but the former has not
eclipsed the latter as predicted. The Apache project has managed to get
its organizational issues worked out and graduate from the Apache
incubator; clearly, it has more staying power than many of us
might have thought.
Perhaps the worst, most wishful-thinking-tinged prediction, though, was the
one that "the GNOME 3 wars will be long forgotten by the end of the year."
One need only have a look at the comment stream that appears on any
GNOME-related news to see that the wounds are still open and fresh.
Someday the community will accept GNOME as it is, but that did not come to
pass in 2012. Learning from experience, your editor is unlikely to predict
a calming of the waters around GNOME 3 (or systemd) in 2013.
So it appears that this year's predictions were, as usual, a mixed bag.
A true evaluation of a set of predictions is not complete, though, without
looking at what was not predicted. As is often the case, your
editor missed a few things that, in retrospect, should have been on the
For example, the regime change in the GNU libc
project was well underway when the 2012 predictions were written. A
more attentive eye would have called attention to the increasingly
consensus-oriented way in which that project was being run. Making this
project more contributor-friendly without a fork was a major achievement
for everybody involved; one can only hope that this type of change will be
repeated in other projects where it is necessary.
Mandriva's decision to hand control of its
distribution to the community also makes sense in retrospect. Letting go
of a project and hoping for community help is, after all, often the
response of a company with
intractable financial problems, especially if the company is somewhat
community-oriented to begin with. It has been clear for a while that
Mandriva SA has not been able to pull together the resources to develop its
distribution properly; hoping that the community can do better is an
obvious response to that situation.
Two items that would have been easy to predict in general — but difficult
in the specifics — were the leap-second bug
backdooring of Piwik.
It is well understood that infrequently tested code will develop bugs over
time; the leap second code had not been invoked in the real world since
2008. One could argue that somebody should have checked the code
for cobwebs as the 2012 leap second approached, but nobody foresaw the
Meanwhile, it has been a while since the addition of backdoors to
software distributions seemed to be a regular occurrence. But free
software projects, especially those producing net-facing software like
Piwik, will remain an attractive target for those who would like easy ways
into otherwise well-secured systems. We will see this kind of thing
Finally, sometimes the most difficult-to-predict events can do the most to
strengthen one's faith in humanity. An interesting trial in Oracle's
software patent suit against Google was easy to foresee. But who would
have imagined that the judge would learn Java and implement some of the
claimed techniques on his own? We are far from fixing the patent system in
the US (or anywhere else, for that matter), but there are signs that
influential people are starting to figure out that there is a problem.
Of course, some things are just too routine to predict. Once upon a time,
a community that could release six major kernels and an uncountable number
of major releases of higher-level software in one year would have been seen as
a hopeless fantasy. Now such things go almost unnoticed. Our community is
strong, and free software continues relentlessly toward world domination.
As a whole, it has been another good year.
We at LWN would like to thank our readers who have supported us through yet
another year; it is worth noting that LWN will celebrate its 15th
anniversary in January. We never predicted that we would be doing this for so
long; it has been a good ride and we are far from done. Thanks to all of
you who make it possible for us to continue to write from the heart of the
Linux development community. On a personal note, your editor would like to
especially thank all of you who offered your support through an
exceptionally difficult year; you made a difference and it is much
Comments (16 posted)
Copyright assignment is a topic that brings out strong passions in
the free software community, especially when the assignee is a corporate
entity. Assignment to a nonprofit entity such as the Free Software
Foundation (FSF) may eliminate some of the problems that can occur
when assigning copyright to a company. However, recent events in the
GnuTLS project are a reminder that copyright assignment can have a number
of downsides even when assigning to a nonprofit chartered with the goal
of protecting free software.
The problem with (corporate) copyright assignment
Copyright assignment tends to evoke polarized opinions in the free
software community. On the one hand, various companies have promoted copyright
assignment agreements as being in the best interests of free
software—Canonical is perhaps the
most prominent example in recent times. On the other hand, the community at
large seems more skeptical of the value of these agreements; Michael Meeks
is among those who put the counterarguments well. Project Harmony, an attempt to create a
standardized set of copyright licensing agreements, has met with a chilly reception from various quarters of the
community, and (so far) seems to have gained little traction in the free
post by Richard Stallman on the FSF web site highlights the most
significant of the risks of assigning copyright when contributing code to a
commercially owned free software project. One of the powers conferred by a
copyright assignment agreement is control of the choice of license of the
software: as the copyright owner, the assignee (alone) has the power to
change the license of the project. Commonly, corporate copyright assignment
agreements place no restriction on the choice of license that the assignee
may in the future choose, thus putting a great deal of power in the hands
of the assignee. As Richard notes:
[The company] could release purely proprietary modified or extended
versions including your code. It could even include your code only in
proprietary versions. Your contribution of code could turn out to be, in
effect, a donation to proprietary software.
On the other hand, the Free Software Foundation requires copyright
assignment for many of the projects hosted under the GNU umbrella. This is
a choice of the
project creators when making the project a GNU project. The main reason given
for this is that being the sole copyright holder puts the FSF in the best
position to enforce copyright in the event of a GPL violation.
Of course, being the sole copyright owner also gives the FSF the
ability to change the license on a GNU project. However, the
motivations of a company and the FSF differ substantially: whereas
a company is ultimately motivated by profit (and its motivations can change
with shifting financial circumstances and changes of company ownership), the
FSF is a non-profit charity chartered to further the interests of free
software. Thus, its copyright assignment agreement includes
an explicit promise that any future distribution of the work will be
under some form of free software license.
GnuTLS and the FSF
GnuTLS is "a secure
communications library implementing the SSL, TLS and DTLS
protocols". The project was founded in 2000, under the GNU umbrella,
by Nikos Mavrogiannopoulos. Over the life of the project, the other major
contributor has been Simon Josefsson.
That there was a problem in the project became unmistakable on December
10, when Nikos posted the following note
(entitled "gnutls is moving") to the gnutls-devel mailing list:
I'd like to announce that the development of gnutls is moving outside the
infrastructure of the GNU project. I no longer consider GnuTLS a GNU
project and future contributions are not required to be under the copyright
of FSF. The reason is a major disagreement with the FSF's decisions and
practices. We note however, that we _do_ support the ideas behind the FSF.
This elicited a rather blunt response
(entitled "GNUTLS is not going anywhere") from Richard Stallman:
Nikos, when you volunteered to maintain GNUTLS, the GNU Project
entrusted its development to you. Your contributions so far are
appreciated. However, the project GNUTLS does not belong to you.
If you want to stop doing this job, you can. If you want to develop a
fork of GNUTLS under another name, you can, since it is free software.
But you cannot take GNUTLS out of the GNU Project. You cannot
designate a non-GNU program as a replacement for a GNU package.
We will continue the development of GNUTLS.
Richard's response raises a number of interesting issues. The matter of
ownership of the project name is perhaps the simplest, and was
acknowledged by Nikos:
I pretty much regret transferring all rights to FSF, but it seems there is
nothing I can do to change that. If I receive a formal request
from FSF I'll change the name of gnutls and continue from there.
In the days since then, however, the name hasn't changed and there does
not seem to have been a formal (public) request to do so. One possible
reason for this might be found in a response to Richard's mail from Werner Koch
(maintainer and primary author of GnuPG and libgcrypt, both of which are
Nikos started the development of GNUTLS under the GNU label on my
suggestion. He is the principal author of GNUTLS and gave away his
legal rights on that work without any compensation or help. The success
of GNUTLS is not due to the GNU project but due to Nikos' and Simon's
Claiming that the FSF has any moral rights on the name of that software
Indeed, of the somewhat more than 11,000 commits in the GnuTLS Git
repository, all but around 400 are by either Nikos or Simon. Simon has not
spoken up in the current mail thread, but he remains an active
contributor to the project.
Thus, while the FSF might have some legal claim on the project name
based on common law trademarks, such a claim is, morally speaking, less
clear. Furthermore, there are existing projects, such as
gnuplot and Gnutella that riff on the
"GNU" name without being official
GNU projects; indeed, Gnutella does this despite an FSF request that
the name should be changed. Also noteworthy in this context is the fact
that the gnutls.org domain is registered to Nikos.
Having worked within the framework of the GNU project for 12 years,
Nikos's reasons for wanting to move out of the project must have been
important ones. In response to a question
from Eli Zaretskii about his reasons, Nikos said:
The main issue is that I'm tired of pretending that I'm
participating to a project I am only allowed to contribute code (and not
even express a different opinion).
Nikos then went on to outline three criticisms of the FSF and GNU
projects. The first of these related to copyright assignment:
(a) I felt particularly frustrated when FSF (when gnutls started around
2000) was insisting the transfer of the copyright to it, even though I had
decided to transfer the copyright to FSFE (this is a very old issue but it
had great influence on me as I realized that the transfer of rights was not
simply for protection against copyright violations).
As Richard confirmed, assignment of
copyrights for all GNU projects (that employ assignment) is solely to the
US-based FSF, rather to one of the regional sister organizations (located
in Europe, India, and South America). One can easily imagine a number of
reasons for this state of affairs. Given the FSF's desire to have a single
copyright holder, it makes sense to assign all copyrights in an individual
GNU project to a single entity, and for administrative and legal reasons it
is probably simpler to assign copyrights for all projects to the same
However, one can also imagine that when the primary developers of a
project reside outside the US—both Nikos and Simon are in
Europe—the requirement to assign to the US-based FSF, rather than FSF
Europe, is irksome. In addition, the FSF Europe tends to have a quieter,
less confrontational style of working than its US counterpart, which may
also have been a factor in Nikos desire to assign copyright to the European
The other theme that came out in Nikos's criticisms was the problem of
feeling figuratively distanced from the parent project:
(b) The feeling of participation in the GNU project is very low, as even
expressing a different opinion in the internal mailing lists is hard if
(c) There is no process for decision making or transparency in GNU.
The only existing process I saw is "Stallman said so"…
The lack of openness was a theme echoed by Werner in reply to Eli's question:
I can't speak for Nikos, but there are pretty obvious reasons knowable
to all GNU maintainers. I don't know whether you, as GDB maintainer,
are subscribed and follow email@example.com. We had a long
discussion a year ago about the way the GNU project is managed and first
of all about all of the secrecy involved there. The occasion was a
request to have at least an open archive of the g-p-d list, so that
non-GNU hackers would be able to learn about architectural discussions
pertaining to the GNU project.
The content of the discussion that Werner refers to is, of course,
unavailable, so it is difficult to gain further insight into why
discussions on the gnu-prog-discuss mailing list need to be
Clearly, at least a few GNU project maintainers are quite unhappy with
the current governance of the umbrella project. And when a maintainer of
twelve years' standing wants out of the GNU project, that suggests that
there are some serious governance problems.
Of course, this is hardly the first time that governance issues have
caused significant division in GNU projects. The GCC project is one of the
most notable cases, providing an example both in the late 1990s, with the
egcs fork of the GCC
compiler (where the fork ultimately supplanted
the original GCC project inside the GNU project), and more recently when questions on plugin
licensing led the FSF to pressure the GCC project to delay the GCC 4.4
release, to the disgruntlement of many GCC hackers.
The problems of assigning copyright to a nonprofit
The events in the GnuTLS project reveal a number of the problems of
copyright assignment that remain even when assigning to a nonprofit such as
The first of these problems has already been shown above: who owns the
project? The GnuTLS project was initiated in good faith by Nikos as a GNU
project. Over the lifetime of the project, the vast majority of the code
contributed to the project has been written by two individuals, both of whom
(presumably) now want to leave the GNU project. If the project had been
independently developed, then clearly Nikos and Simon would be considered
to own the project code and name. However, in assigning copyright to the
FSF, they have given up the rights of owners.
The mailing list thread also revealed another loss that developers
suffer when signing a copyright assignment agreement. As noted above, the
ability of the FSF—as the sole copyright holder—to sue license
violators is touted as one of the major advantages of copyright
assignment. However, what if, for one reason or another, the FSF chooses
not to exercise its rights? Juho Vähä-Herttua raised this point in the mail thread:
As a side note, I find Werner's accusations, as written on his blog, of FSF
not defending its rights in case of GnuPG copyright violations very
serious. When a copyright holder transfers their rights to FSF they also
transfer their rights to defend against copyright violations.
post that Juho refers to questions a number assumptions around FSF
copyright assignment. In the post, Werner states:
My experience with GnuPG and Libgcrypt seems to show that the FSF does not
care too much about [copyright violations]. For example, at least two
companies in Germany sold crypto mail gateways with OpenPGP support
provided by GnuPG; they did not release the source code or tell the
customers about their rights. The FSF didn't act upon my requests to stop
them violating their (assigned) copyright on GnuPG.
Once a developer assigns copyright, they are at the mercy of the
assignee to enforce the copyright. In this particular case, one can
speculate that the failure to pursue the violation was likely a shortage of
human resources. As Richard noted,
"We have staff for GPL enforcement, […] but there are so many
violations that they can't take action on all."
But that very response throws into question the wisdom of assigning a
large number of copyrights to a resource-starved central organization. A
more distributed approach to dealing with copyright violations would seem
more sensible. And indeed, organizations such as gpl-violations.org and the Software Freedom Conservancy have
shown that the GPL violations can be successfully fought without being the
sole copyright holder in a work of code. By now, the argument that
copyright assignment is necessary to successfully enforce free software
licenses is rather weak.
Werner outlines a few other problems with FSF copyright assignment. One
of these is the seemingly arbitrary nature of copyright assignment across
GNU projects. He points out that there are two cryptographic libraries that
are part of the GNU project, one of which (libgcrypt) requires copyright
assignment while the other (Nettle) does not. The seeming arbitrariness in
this example was further emphasized by the fact that GnuTLS (which, as we
already saw, requires copyright assignment) switched from using libgcrypt to
The rationale that copyright assignment is necessary to allow
relicensing also strikes Werner as dubious. He considers the two likely
scenarios for relicensing GPLed software. One of these is relicensing to a
later version of the GPL. This scenario is in most cases already covered by
the default "or later" language that is usually applied to software licensed
under the GPL. Although there are projects that deliberately exclude the
"or later" clause when applying the GPL—most notably the Linux
kernel—it's likely that few or no GNU projects exclude that
clause. Projects that exclude the "or later" language of the GPL are likely
also to avoid using copyright assignment.
The other likely scenario for relicensing a GPL project is to relax the
license constraints—for example, switching from GPL to LGPL, so as to
allow interoperability with software that is not under a GPL-compatible
license. Such relicensing can be performed even when the project lacks a
copyright assignment (as was recently done
for portions of the VLC code base). However, this requires a formidable
effort to obtain permissions from all contributors. But, Werner
points out, the FSF has in practice rarely been interested in
relaxing licensing constraints in this way.
In summary, using copyright assignment as a tool to allow relicensing
seems to serve little practical use for the FSF, and comes at the cost of
removing the contributor's freedom to relicense their code.
Werner's blog post highlighted one more problem with copyright
assignment—a problem that occurs with assignment both to companies
and to nonprofits. The requirement to sign a copyright assignment agreement
imposes a barrier on participation. Some individuals and companies simply
won't bother with doing the paperwork. Others may have no problem
contributing code under a free software license, but they (or their
lawyers) balk at giving away all rights in the code. In general, those
contributors just silently fail to appear. By chance, a discussion on
copyright assignment is currently taking place in the Gentoo project, where
Greg Kroah-Hartman, a long-standing contributor to the project, commented on this point:
On a personal note, if any copyright assignment was in place, I would
never have been able to become a Gentoo developer, and if it were to be
put into place, I do not think that I would be allowed to continue to be
one. I'm sure lots of other current developers are in this same
situation, so please keep that in mind when reviewing this process.
To illustrate his point, Werner
related his recent experience with the libgcrypt project. Concluding that
copyright assignment served little practical use, he relaxed that
requirement for libgcrypt: starting in April of this year, he permitted
contributions accompanied by an emailed kernel-style developer
certificate of origin. The result was a noticeable increase in patches
sent in to the project.
The risks of assigning copyright to corporate entities have in the past
been well publicized. Assigning copyright to a nonprofit eliminates the
most egregious of those risks, but carries its own burdens and risks, which
have not necessarily been so well publicized. One of those burdens is the
necessity of buying into an associated governance model, one that may or
may not work well for project developers. The FSF governance model is, it
seems, not working well for a number of GNU projects. Developers should
consider (in advance) the questions of project ownership that are bound to
arise if the governance model does not work for them and they want to
separate from the governing project.
In addition, the costs of assigning copyright to a nonprofit should be
balanced against the (supposed) benefits. The assertion that assigning
copyright to a single entity improves the chances of successful prosecution
of a copyright violations looks dubious when one considers that the
assignee may not be well enough resourced to prosecute every violation. To
that should be added the facts that assignment means that the assigner
loses the ability to themselves prosecute copyright violations and that
copyright violations have been successfully prosecuted even when there is
no single copyright holder. Finally, the value of copyright assignment as a
tool that permits the FSF to relicense code seems rather limited in
practice. In summary, the arguments for copyright assignment start to look
decidedly weak, even when the assignee is a nonprofit such as the FSF, and
it is hard to find any justification for the FSF maintaining this
(Thanks to Carlos Alberto Lopez Perez for the heads-up.)
Comments (83 posted)
Here is LWN's fifteenth annual timeline of significant events in the
Linux and free software world. We have broken the timeline up into
quarters, and this is our report on October-December 2012 (updated on
December 31). Eventually, the
quarterly timelines will be stitched together to create a timeline for the
year as a whole, but in the meantime, you can find the other quarterly
This is version 0.8 of the 2012 timeline. 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.
If you'd like to look further back in time, our timeline index page has links to the
previous timelines and some other retrospective articles going all the way
back to 1998.
That is not how open source works, you need to do 90% of
the work upfront, people only join when you have something useful.
Samsung releases the F2FS filesystem (blurb and article).
KDE releases a manifesto (LWN blurb).
HTTPS Everywhere 3.0 is released (announcement).
Systemtap 2.0 is released (announcement).
The first Korea Linux Forum is held in Seoul, October 11-12 (LWN report).
When I was on Plan 9, everything was connected and
uniform. Now everything isn't connected, just connected to the cloud, which
isn't the same thing. And uniform? Far from it, except in mediocrity. This
is 2012 and we're still stitching together little microcomputers with HTTPS
and ssh and calling it revolutionary. I sorely miss the unified system view
of the world we had at Bell Labs, and the way things are going that seems
unlikely to come back any time soon.
-- Rob Pike
Canonical provides users with a mechanism to directly fund development
of Ubuntu (LWN article).
NetBSD 6.0 is released (announcement).
The Whonix distribution makes an alpha release (LWN article).
The Privacyfix browser plugin is released (LWN article).
Plasma Active Three is released (LWN blurb).
The 2012 Realtime Minisummit is held in Chapel Hill, North Carolina,
in conjunction with the 14th Real Time Linux Workshop, October 18-20
(LWN minisummit coverage; LWN coverage of
workshop sessions: Modeling systems with Alloy; Realtime Linux for aircraft).
An ext4 data corruption bug receives wide media coverage, but in
practice is rather difficult to trigger (LWN blurb and article).
The Debian technical committee renders a judgement regarding
long-standing difficulties between the maintainers of various Debian Python
packages (LWN article).
Ubuntu 12.10 (Quantal Quetzal) is released (announcement).
Apache OpenOffice graduates from the Apache Incubator (announcement).
If you want to pick a fight, insult a designer by asking
why we don’t “just learn to code.”
Git 1.8.0 is released (announcement).
Wayland and Weston 1.0 are released (announcement).
Arduino 1.5 is released (announcement).
Yocto 1.3 "danny" is released (announcement).
The Linaro Enterprise group is formed (announcement).
The openSUSE project releases openSUSE 12.2 for ARM (announcement).
Put another way, having the career of the beloved CIA
Director and the commanding general in Afghanistan instantly destroyed due
to highly invasive and unwarranted electronic surveillance is almost enough
to make one believe not only that there is a god, but that he is an ardent
Greenwald, commenting on the process leading to the fall of CIA
Director David Petraeus
The Fedora project announces an alpha release of Fedora 18 that
supports ARM; the Fedora ARM developers hope
to make F18 the first release that supports ARM as a primary architecture.
OpenBSD 5.2 is released (LWN blurb and article on some challenges that OpenBSD the
other BSDs face in trying to keep pace with Linux).
Asterisk 11 is released (LWN blurb).
The release date of Fedora 18 slips significantly, from the
originally expected November to January (announcement, LWN article).
LinuxCon Europe is held in Barcelona, Spain, November 5-9 (LWN
coverage: Challenges for Linux networking;
Systemd two years on; The failure of operating systems and how we can
fix it; All watched over by machines of
loving grace; Realtime, present and
future; Checkpoint/restore in user space:
are we there yet?; Don't play dice with
The GNOME project announces that fallback mode will be dropped in the
upcoming 3.8 release (LWN blurb; a
short time later, the project announces
plans for a "classic" mode).
Our patent system is the envy of the world.
Kappos, head of the United States Patent and Trademark Office
Android 4.2 is released (LWN article).
The VLC projects completes relicensing much of its code from GPL
to LGPL (LWN article).
The Portuguese government adopts ODF (LWN blurb).
A backdoor is inserted into the Piwik web server; the problem is
quickly fixed and notified (LWN blurb).
Linux Mint 14 is released (announcement).
Upstart 1.6 is released (LWN blurb).
The CyanogenMod project starts releasing stable builds of
CyanogenMod 10 (LWN article on running this version on the Nexus 7
Wikipedia rolls out an HTML5 video player (LWN article).
Ubuntu makes a distribution for the Nexus 7 (LWN article).
Darktable 1.1 is released (LWN article).
So next time you're not happy about something: just prefix your criticism
with "I think". You may be surprised what difference it makes to the
Oh, two other magic words: "for me". Compare "This workflow is
completely broken" vs "This workflow is completely broken for me". Amazing
what difference those two words make...
The Google Summer of Code Doc Camp 2012 takes place in Mountain
View, California, December 3-7 (LWN coverage: Documentation unconference; Book sprints).
NetBSD 5.2 is released (announcement).
The MariaDB Foundation is formed (announcement).
Ekiga 4.0 is released (announcement,
The first "shim" UEFI secure bootloader is released (announcement).
Linux 3.7 is released (announcement; KernelNewbies summary; LWN
merge window summaries: part 1, part 2, and part
3; LWN development statistics article).
I once scoffed at the idea that anyone would write in
COBOL anymore, as if the average COBOL programmer was some sort of
second-class technology citizen. COBOL programmers in 1991, and even today,
are surely good programmers — doing useful things for their jobs. The same
is true of Perl these days: maybe Perl is finally getting a bit old
fashioned — but there are good developers, still doing useful things with
Perl. Perl is becoming Free Software's COBOL: an aging language that still
Perl turns 25 years old today. COBOL was 25 years old in 1984, right at
the time when I first started programming. To those young people who start
programming today: I hope you'll learn from my mistake. Don't scoff at the
Perl programmers. 25 years from now, you may regret scoffing at them as
much as I regret scoffing at the COBOL developers. Programmers are
programmers; don't judge them because you don't like their favorite
Firefox OS Simulator 1.0 is released (LWN article).
SparkleShare 1.0 is released (LWN blurb).
Bison 2.7 is released (announcement).
Richard Stallman criticizes desktop searching in Ubuntu Unity,
which relays search terms to Canonical servers (LWN blurb and article).
Samba 4.0 is released (announcement and earlier article).
A number of Samsung Android phones are revealed to have a
significant security hole, a device file that gives write access to all
physical memory on the phone (LWN blurb).
Eudev, a project to create a Gentoo-based fork of udev,
is launched (announcement, LWN
Qt 5.0 is released (LWN blurb).
PulseAudio 3.0 is released
The status.net service is phased out, and replaced by pump.io
Gnumeric 1.12 released (announcement).
The Perl programming language turns 25 this month
from Perl Foundation News).
So after I released 3.7-nohz1, I shut down the light then sat down
in front of an empty wall in my flat and waited in the darkness with
a black tea for december 21th's apocalypse.
But then after a few days, I've been thinking I should have taken a
second cup of tea with me.
So I eventually got up and turned the light on. Then I booted my
computer and started working on that new release of the full dynticks
-- Frederic Weisbecker learns that the apocolypse
is not nigh
A hash-based DoS attack on Btrfs is disclosed (LWN blurb).
LLVM 3.2 is released (announcement, release notes).
Discontent in the GNU project becomes evident as the GnuTLS
maintainer moves the project outside GNU and the GNU sed maintainer
resigns (sed maintainer resignation note, LWN article on events in the GnuTLS project).
Awesome 3.5 is released (LWN blurb
and earlier article on this window manager).
Enlightenment 0.17 is released (announcement and earlier LWN article on this window manager).
The GNU C library (glibc) version 2.17 is released (announcement).
FreeBSD 9.1 is released (announcement,
BlueZ 5.0 is released (announcement, LWN article).
GNU Automake 1.13 is released (announcement).
Comments (none posted)
This is the last LWN Weekly Edition for 2012; following our longstanding
tradition, we will be taking a break during the last week of the year to
rest, be with our families, and recover from too much good food and wine.
We wish the best holidays to all of our readers, and a happy new year as
well. The Weekly Edition will return on January 4.
Comments (2 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Fedora and secure release upgrades; New vulnerabilities in aptdaemon, kernel, squashfs-tools, tomcat, ...
- Kernel: 3.8 Merge window part 2; Virtualization and the perf ABI; Removing uninitialized_var().
- Distributions: Fedora ponders Software Collections; CyanogenMod, IPFire, PC-BSD, UCS, ...
- Development: Inkscape; Qt 5.0; StatusNet and pump.io; Perl at 25; ...
- Announcements: FSFE 2012 Annual Report; LF year in review video; EUPL revision; Defending the GPL; ...