Wild predictions for 2008 [LWN.net]

By Jonathan Corbet
December 31, 2007

It's that time of year again: the beginning of the new year - along with the lack of much else going on - inspires editors to make predictions about what they think may happen in the coming months. Your editor is not immune to these forces, and he has long since ceased to fear the possibility of looking like a fool in front of thousands of people. He's used to looking like a fool in front of thousands of people. So, without further ado, here's a set of wild guesses about what may await us in 2008.

Development

Support for Flash media will reach a usable state in 2008 - at least, on the playback side. The ability to waste time on video sites using only free software will doubtless prove appealing for many Linux users, while the ability to display Flash-based advertising may prove less so. But Flash is an important medium for video content and various types of interaction; good, free support for this medium is an important prerequisite for true World Domination. Arguably even more important is the ability to create Flash media on Linux, but that will take a little longer to come around.

KDE 4.0 will be released early in the year. This is a huge, milestone release for the KDE development community, but the developers who have worked so hard toward this goal may find the user community's response a little disappointing. For all of the great work which has gone into 4.0, it remains a dot-zero release, and a big one at that. The remaining bugs and missing features are certain to put off some early adopters. One need only think back to the early GNOME 2.x releases, though, to realize that this is a normal part of the development process and that things will get much better quickly.

The focus on power consumption will intensify this year, continuing a trend from 2007. Linux should, by all rights, consume less power than competing systems on the same hardware - but it doesn't. We now have the tools to identify and track down the worst offenders in this area, and we have the low-level support needed to make low-power Linux possible. Mobile applications may continue to drive this push, but there may be even more low-hanging fruit on fixed systems. There is just no end of reasons to reduce power consumption on all systems running Linux, and we're now in a position to get that job done.

The merging of the realtime Linux tree will be substantially complete by the end of the year. Your editor is out on a limb here; the remaining realtime code includes some of the most intrusive changes. But distributors are shipping this code now, and it has been well tested in a number of environments. So it seems likely that, by the end of 2008, the mainline Linux kernel will be fully capable of running in a realtime mode.

Legal issues and related overhead

The OOXML standardization debate will continue, and Microsoft may well prevail in getting its document format recognized as a standard by the end of the year. The free software community will react as it always has - it's just another data format to support.

More projects will move to GPLv3 in 2008, creating occasional fallout at the distributor level when newly-created licensing conflicts are found. The most interesting potential change is the GNU C library, which remains at LGPL 2.1 as of this writing. A GPLv3-licensed glibc would have to be user-replaceable, which could be problematic on locked-down devices. So, if this change happens, expect a increased interest in alternative C libraries for embedded applications.

GPL enforcement activities will continue and may even increase. Patience with companies which use the code without complying with its license is at a low point, and that will not change. Chances are that, once again, almost every company which is confronted on GPL-violation issues will come into compliance without going to court.

There will be no more Microsoft patent deals, at least with companies of any significance. Those who are inclined to make such agreements have already done so; the holdouts are unlikely to change their minds at this point.

Commercial and related

The OLPC project will start to think seriously about the successor to the XO. There will be many opportunities to build a platform which can be even more empowering for small children; for example, the GNU Radio folks are already pondering ways to bring software-defined radio capabilities to this machine. Meanwhile, deployments of the XO will continue to happen and we'll see the first effects of putting truly free systems into the hands of children. Some of those effects will certainly surprise us.

The days of hardware support hassles will be over. By the end of 2008, we should have good support for ATI graphics adapters, Atheros wireless chipsets, and even, via the Nouveau project, NVidia adapters. There will always be exceptions, but the rule will be clear: we will be able to buy hardware secure in the knowledge that it will work with our Linux systems.

Competition between distributors will grow in intensity. We saw some hints of this in the sniping between Red Hat and Novell toward the end of 2007; there will be more as these businesses increase their focus on the bottom line. Ubuntu will also push harder, though, interestingly, it often seems like that distributor's biggest perceived competitor is Fedora. Your editor believes (and hopes) that cooperation at the development level will remain strong despite increasing drama at the public relations level.

Along these lines, expect intensified competition from Sun, which will continue to try to aggressively push Solaris into Linux shops while simultaneously presenting a friendly face to the community. We may also see more of the less-friendly side of the BSD community for similar reasons.

Community

There will be a major technical Linux event in the United States - the first in some years. The Linux Plumbers Conference, planned for mid-September, will be unique in its focus on the kernel and the software layers immediately surrounding it. Getting the "greater kernel ecosystem" together in one place is an overdue move which should help integration and development of the plumbing we all depend on.

Participation in the development community will grow. That, of course, has been true every year for at least two decades. In 2008, though, we can expect to see a stronger push to encourage developers from parts of the world which traditionally have not contributed so strongly to our community; Asia, in particular, should continue to increase its presence. We will also continue to see companies in the embedded systems area figure out that, if they do not participate in the development of the code they use, others will have a much stronger influence on how that development goes.

Tolerance for anti-social behavior on mailing lists, IRC channels, etc. will continue to drop as development communities try to attract and provide a welcoming environment for more participants. Many communities have formal codes of conduct now; others may well try to adopt them. But even less-formal groups will increasingly understand that a harsh and unfriendly environment hurts the project as a whole.

As usual, we'll come back to these predictions at the end of the year and mock them without mercy. Until then, best wishes for a great 2008 from the LWN editorial team!

(Log in to post comments)

GPLv3 glibc

Posted Jan 3, 2008 2:50 UTC (Thu) by jimparis (subscriber, #38647) [Link]

That's interesting, I hadn't realized that. For the benefit of others, the relevant clause:

If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corresponding Source conveyed under this section must be accompanied by the Installation Information. But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM).

GPLv3 glibc

Posted Jan 4, 2008 3:15 UTC (Fri) by dmag (subscriber, #17775) [Link]

Nowadays, Flash is cheaper than ROM for all but the smallest microcontrollers (like 8 bit
size). GlibC is huge, so it doesn't make sense to put it in ROM. If it's in flash, they're
going to leave themselves a way to write it (even if it's just thru JTAG). Therefore it's
unlikely anyone distributes a completely non-writable GlibC (or even Linux kernel for that
matter).

This is already an issue with LGPL v2

Posted Jan 3, 2008 4:43 UTC (Thu) by JoeBuck (subscriber, #2330) [Link]

Even with LGPL v2 (the existing glibc license) there has to be a way to replace the library. For that reason, there have long been alternative C libraries for embedded systems, for example newlib, first developed by Cygnus.

This is already an issue with LGPL v2

Posted Jan 3, 2008 5:46 UTC (Thu) by stevenj (subscriber, #421) [Link]

Just as for the GPLv2, it is debatable whether this clause has any teeth when there is a hardware-signature mechanism that prevents replacement code from working. Certainly, the FSF was worried enough about this "Tivoization" loophole to explicitly address it in v3 of the license.

Wild predictions for 2008

Posted Jan 3, 2008 14:56 UTC (Thu) by iabervon (subscriber, #722) [Link]

The XO generation won't be at all the same thing as the current generation of the free
software community; they'll be as different as the kids who grew up with cell phones are from
the early adopters with the phones that were only luggable in cars. I think that generation
will reject any application software they can't modify. Not just software they aren't
permitted to modify, but software that's not sufficiently clearly written or whose rebuild
process is too slow or complicated.

I can just see RMS's consternation when he finds millions of users specifically rejecting
emacs because they don't know elisp and can't find their way through the flow control, and
therefore can't each make their own personal changes.