Author Charles Stross recently lamented
that times have gotten sufficiently interesting that the writing of
near-future science fiction is currently impossible. Too much is changing,
in too many interesting and unpredictable ways, for anybody to make
projections of the future that don't look ridiculous long before that
future arrives. Your editor can certainly understand that concern. But,
then, your editor's predictions have always
looked ridiculous in
short order. So there's no reason not to continue with business as usual.
Here's a set of wild guesses as to what we might see this year. Woe
unto anybody who takes any of this seriously.
The net is full of guesses about what the currently-unfolding financial
crisis will mean for free software; many of those are wildly optimistic.
Your editor is a bit more guarded: the free software community will
emerge from this mess stronger than ever, but it may well be a difficult
ride. Much of the commercial Linux industry draws a fair amount of its
income from the financial industry, and many players in that industry -
there should still be one or two left - are likely to be looking to cut
their expenses somewhat. So money for little things like critical
infrastructure may be a little short until the bonus pool can be brought
back to a satisfactory level. Other parts of the economy will be suffering
similar pain. All told, economic trouble will make life harder for a number
of free software companies - and the people they employ.
Still, the lower cost of free software, along with its flexibility, can
only serve to make it more appealing to companies which are trying to
develop a successful business strategy for difficult times. The commercial
ecosystem around free software should continue to grow, but it may go
through some interesting changes along the way.
One thing that will help is that open embedded systems will grow in
appeal and become more successful. The iPhone showed what can be done
with an interesting hardware platform; at the same time, it has spawned a
steady industry devoted to opening up the device. Android-based platforms
are quickly showing that it's possible to make an equally (or almost
equally) nice device without locking it down in the same way. Awareness of
the value of open gadgets will grow, and there will be more of them on the
market by the end of 2009. These gadgets may not be as completely open as
many LWN readers would like, but they will be a big step in the right
As that happens, your editor thinks that Android will grow in
popularity, perhaps to the point where it eclipses other Linux-based
handset platforms. Android has no shortage of flaws, but it is a
sufficiently well thought-out and developed system that it should be able to
attract a real development community - especially if Google opens up its
processes sufficiently. And if Google maintains an overly-firm hand on
Android, we may well see forked versions aimed at the hardware devices
which can run them.
The pace of GPL enforcement actions will drop as a result of two
independent developments: more companies will figure out that free software
licensing matters, and developers will decide that they do not want to be
part of a high-profile lawsuit. That said, there will be some significant
actions on this front in 2009. Meanwhile, the FSF's GPL-infringement
lawsuit against Cisco will be settled in a flurry of "win-win" press
GPLv3 migrations will slow, especially among projects that people
have actually heard of.
A formerly friendly company may pull an SCO. The sad fact is that
failing companies have a certain tendency to look toward their "IP
portfolio" as a last-ditch source of revenue. 2009 is likely to see more
than the usual number of failing companies; do not be surprised if one of
them grasps at this particular straw.
Debian Lenny will be released. Now that the ritual firmware flame
war and general resolution obligations have been satisfied, it looks like
even Debian would be hard put to not get a release out this year. Debian
will also make a serious attempt to avoid a repeat of the recent general resolution
mess. There will be changes to how resolutions find their way to a
vote, and the scripture-like authority of the "foundation documents" may be
We still won't know about Fedora's "infrastructure issues". But
they'll promise to fill us in as soon as they possibly can. In the mean
time, Fedora will crank out two more solid releases, one of which will
eventually show up (somewhat transformed) as the next RHEL release.
openSUSE will make it easier for outside developers to maintain
packages in an attempt to bolster its relevance in the development
The 2.6.33 kernel will be released. In other words, the kernel
development cycle will continue at its fast pace, and the numbering scheme
will not be changed.
The realtime patch set will be mostly merged by the end of the
year. It really has to happen this time. What could possibly go wrong?
After many years of effort, 3D graphics will be a solved problem on
Linux systems. We will no longer be second to other systems with regard to
functionality or performance - at least, if you buy your video hardware
from cooperative companies. Some of the code may still be working its way
through the distribution system, but the work will be done.
It will be a make-or-break year for Perl. If the Perl developers
cannot either bring new life to Perl 5 or turn Perl 6 into
something real, this language will, by the end of the year, have moved well
down the road to "legacy" status.
By the end of the year, KDE 4 will have stabilized, and most users
will have forgotten what all of the flames were about. Meanwhile, the
first pieces of GNOME 3 may be out, but they are likely to be
received without great enthusiasm.
The distributed version control system debates will continue in full
force through the year. A number of major projects will make the jump
to a DVCS, and most of them will go to git. But Mercurial and Bzr (at
least) will remain strong contenders.
As a result of declining contributions from Sun and frustration felt by
outside developers, OpenOffice.org will be forked. The new project
is likely to have some initial troubles - OpenOffice.org is a big
program - but it will eventually become the focus of a much more dynamic,
This article would not be complete without a prediction that free
software will be stronger than ever at the end of 2009. Some
predictions are easy to make; that has been the trend for many years, after
all. Still, it is going to be interesting to see what we will be able to
accomplish over the next twelve months. As always, it is going to be fun.
Finally, it will be a hard year for Linux-related media; we have
already seen a foreshadowing of the situation with Groklaw's shift
into maintenance mode and the recent demises of
LinuxWorld.com and Linux.com. It is a hard time to be in the media
business in general, and the free software realm offers challenges of its
own even in the best of times. That said, LWN appears to be holding steady
so far, thanks to thousands of readers who feel that this enterprise is
worth supporting. So your editor is able to confidently predict that we'll
still be here for the traditional mocking of these predictions in
Comments (51 posted)
Is Compiz dying? Possibly not, but the consensus among developers of the
compositing window manager seems to be that the project is in serious need
of reorganization if it is going to survive.
Founded three years ago, Compiz quickly gained recognition as one of the
first projects to deliver 3-D graphical effects on the desktop. Probably
its best-known effect is the presentation of multiple workspaces on a
rotating cube. The current state of the project dates from the merger of
Compiz and Beryl, a fork of Compiz, at the end of March 2007.
Since then, development has been divided into two projects: Compiz, which
includes the core functionality and basic plugins, and Compiz Fusion, which includes
utilities and more plugins. In theory, the two projects were supposed to
merge, but in practice, that has never happened. The projects still
maintain separate web sites, mailing lists, and bug trackers, despite the
fact that most developers of one project also work on the other.
The community appears to lack both organization and
direction, with many developers working on their own branches of Compiz in
secret rather than face endless discussion about their goals. Still
other developers have drifted away from the project. Under these
circumstances, the community has not only been unable to manage a 1.0
release, but, 18 months after the last stable release, is still struggling
to complete version 0.8.
More recently, the community has been affected by the withdrawal of Compiz
project leader David Reveman. Reveman's departure, apparently made without
any official announcement, has led to a lack of leadership, since no
experienced Compiz developer appears willing to assume the role of
community organizer. Just as importantly, Reveman's refusal to respond to
emails after his withdrawal has caused practical difficulties for other
developers because much of the Compiz code base is undocumented.
The result is that Compiz, once seen as an exciting, leading-edge project
is now being openly denigrated in some circles. For instance, one commenter on a recent
Compiz video on YouTube wrote:
Dramatically ugly, unusable, slow, badly animated and unconsistent.
Open source development without a serious, expert maintainers can result in
chaotic growth of the project and waste of human resources into pointless
The Compiz-Fusion project is certainly the most representative example of
The situation came to a head in late December when developer Dennis Kasprzyk announced
the creation of a new compiz++ code branch. This new branch is written in
C++ as opposed to the C programming language of the main branch, and would
require numerous changes in the behavior of plugins. A few days later,
Kasprzyk's announcement motivated Kristian Lyngstol, another developer, to
begin a thread on the Compiz mailing list on "The
Future of Compiz." This thread was echoed in an article called "Compiz is dying and we
need to fix it" by Kevin Lange. Since then, discussions about the state
of Compiz have emerged on numerous other mailing lists, especially those
dedicated to specific distributions.
According to Lyngstol, "there has been the equivalent of no progress
since the merger. We've basically been in maintenance mode. The reason for
this, from my point of view, is a complete lack of direction and
Lyngstol sees several reasons for the current state of Compiz. To start
with, he suggests that project members have been waiting too long for
"something that will change everything," and the result has
been too many code branches, many of which are incompatible with each
other. "The reality is that all these branches are
counter-productive, regardless of how fun or flashy they are,"
Lyngstol writes. He continues:
If we are to have a healthy development environment, and any hope of
bringing Compiz out of a constant alpha-stage, we need to have clear
development goals and a way to cooperate. Before somebody puts 6+ months of
development into their work then present it as a final solution.
Next, Lyngstol notes that the community remains small, with less than 20
people contributing code, if the subscription list for Compiz-Fusion Planet is an
indication. In fact, Lyngstol writes, "Unless I'm missing something
obvious, we haven't seen a single new core developer that contributes
significantly to [the main branch] since the merge. We have, however, lost
Lyngstol goes on to suggest the reasons for the lack of developers. Because
the project has no direction, he writes, "all development and design
is done as a solo race. There's no way to know whether you can work on
something without losing your work because some obscure branch gets
Even worse, the merge of Compiz and Compiz-Fusion that was supposed to
happen never has, resulting in a duplication of effort that Lyngstol
describes as "messy." Much the same state of chaos exists in
the code, which is both "undocumented" and "not
particularly pretty." Moreover, when new code is added, its functions
"do more than C functions should do." But the basic problem,
according to Lyngstol, is that "Compiz is a research project,"
in a constant state of change and is not focused on producing a stable
To solve this situation, Lyngstol suggests a merger of the various code
branches — or perhaps, an agreement that some or all are forks
— and some serious attention paid to project management. "We
should have clear goals for every major release," he writes,
"and finding those goals should be the top priority after a stable
release. For each point-release in a development series, we should also
have a clear goal. This will make it easier to predict releases and for
developers to help."
Perhaps the greatest indicator of the state of the Compiz community is not
Lyngstol's critique, but the polite agreement with which it has been
greeted so far.
Perhaps the greatest indicator of the state of the Compiz community is not
Lyngstol's critique, but the polite agreement with which it has been
greeted so far. To date, those who have responded to Lyngstol's posting
have quibbled over the details of some of his points while not seriously
contesting his overall observations or his suggested solutions.
Another, more unfortunate indicator is that, while posters have agreed that
leadership and direction are needed, so far none of them have come forward
to offer it. Instead, Lyngstol and several other active developers have
gone out of their way to state that, while they would support change, they
were unwilling or unable to take on any leadership role.
So far, no one has suggested possible external reasons for the diminishment
of Compiz. But it may be that, now that the novelty of 3-D special effects
have worn off, few reasons exist to develop them; the few practical
effects, such as zooms, are too slight to encourage the majority to move
away from standard 2-D desktops.
Another possible factor is that 3-D video drivers that are both stable and
released under a free license are taking longer to arrive than anyone
anticipated, and their lack reduced users' interest in projects like Compiz
that require them.
Still another suggestion was made in an anonymous comment on Lange's
Perhaps Compiz has served its purpose by
proving that the free desktop could surpass Windows or OS X in eye
candy. However, not everyone would agree — developer Quinn
Storm, for example, posted a comment
to the Compiz mailing list in
which she makes clear that she thinks that Compiz has that goal, but has
yet to reach it.
Whatever the reasons and whatever happens, one consolation is that, in free
and open source software, nothing is really lost. But, as things stand now,
with no one willing to assume the leadership of the project, a very strong
possibility exists that the the Compiz will continue to diminish, with its
members aware of the situation but unable or unwilling to change it.
Comments (18 posted)
Your editor's long-suffering spouse will attest that gadgets are never in
short supply in the house. Many of them pass below her interest, but a new
one has come in which has attracted attention throughout the household: an
, otherwise known as the fully unlocked version of the G1
phone offered by T-Mobile. This phone is certainly a fun toy, but it has
the potential to be a lot more than that.
The details of this device have been well publicized for a while now. It
includes a nice touchscreen display, QWERTY keyboard, GPS receiver,
accelerometer, 3.2 megapixel camera, and more. The whole thing is
powered by Google's Linux-based Android platform. The Dev Phone is
essentially the same device as that sold by T-Mobile, but with a crucially
important difference: it is unlocked in all senses. This means not just
that it can be used with any mobile carrier's SIM, but also that the base
operating software has not been locked down. This is a phone for which the
entire system can be rebuilt and replaced at will.
The Dev Phone thus joins the OpenMoko Neo Freerunner on the very short list
of truly open mobile handsets. This device, though, has the advantage of
being a bit more of a finished product with what appears to be a rather
stronger software development team behind it. It also, for what it's
worth, has some nice hardware capabilities that the Neo lacks: quad-band
GSM, 3G (though not on the bands used by your editor's carrier, alas),
keyboard, etc. Your editor believes that it will be a successful product.
Over the course of the next few months, your editor plans to dig into this
device and report on what he finds. How open is the device really? What does
it take to put a new kernel onto it? What might it take to put a different
operating system onto it altogether? And, in general, how does this whole
Android thing work? Assuming that he does not brick the device early on,
your editor hopes to get a real sense for what can be done with this
device, how close its software is to what we normally think of as Linux,
and where it might go into the future. It should be a fun project.
First, though, one has to get through the stage of simply playing with the
new toy. So the rest of this article will be a user-level review of
The hardware: it feels generally solid. The device is larger and heavier
than handsets your editor has used in the past, but that is to be
expected. The keyboard works better than one might think given its size; even your
relatively fat-fingered editor is able to type with reasonable speed and
accuracy. The vibrator lacks strength. The camera seems to take nice
photos (for a phone camera), but it is exceedingly slow. As with most color-screen
devices, the display is entirely unreadable when the backlight is off. A
nice touch with this phone is an indicator LED which blinks when the phone
has something to tell you - an unread text message, for example - but the
use of the LED seems to be somewhat inconsistent.
Your editor has yet to get a sense for what the battery life would be in
the absence of children playing with the device all day long. Complaints
about battery life can be found on the net, but it appears that the phone
should be able to get through two or three days of moderate usage where the
GPS receiver is off most of the time. On the other hand, if you let your
kids use it to mess around on video sites, the battery runs down relatively
On the software side, this phone gets off to a bit of a rough start. It
first requires the user to configure the phone to access data service from
the carrier, a process which must be done by hand if that carrier is not
T-Mobile. Your editor's last new phone recognized the carrier from the SIM
and handled this task automatically. More annoying, though, is that the
phone requires the creation of a Gmail account as part of its setup
process. The fact that one does not have - and does not want - such an
account is not relevant. So now your editor has an entry in the Gmail
account database which will never be used.
That, of course, ties in to why Google has gotten into this exercise in the
first place. There are many features of the Android platform which are
designed to tie the user in more closely to services provided by Google.
Some features, such as the calendar, are really just an extension of the
online offerings. The phone wants to sync the contacts list
to...somewhere...and turning the feature off leads to unpleasant behavior.
It is possible to use many of the features of the device without
connecting back to the Google mother ship, but it's not the natural mode of
Another example is email handling. There is a separate icon for Gmail which
just works; that application offers the features (such as threading)
provided by that service. One can run a different mail application to
connect to a POP or IMAP account somewhere, but it's a separate setup
process. Later, with luck, one discovers the improved K9 client, which must be
installed separately and which requires one to go through the setup process
again. Even with K9, the non-Gmail mail client is not what it should be.
There is no threading of messages, many basic commands (refiling messages,
for example) are missing, etc. Then there's little problems like refusing
to connect to a server if it doesn't think it can trust the SSL certificate
and failing to authenticate if the user's password contains special
characters. One assumes that this client will improve,
or that other clients will be ported to the platform, but, for now, it
doesn't seem to be a priority for the Android developers.
More generally, though, the Android software is pretty slick. A fair amount of
thought has been given to how interaction should work on this kind of
device. Once one gets used to a few specific differences (holding a finger
on an item on the screen for a few seconds often brings up otherwise hidden
options, for example), navigating through applications comes fairly
naturally. Only in some cases do inconsistencies pop up - some
applications have different notions for how to zoom in and out than others
is one that your editor has noticed. As a whole, the interface comes
across as polished and attractive.
That said, use of the display could be improved. On a small display, there will
always be a certain tension between getting enough information on-screen
and avoiding the creation of headaches through severe eye strain.
Different users will do better with small fonts than others. But if
Android offers an option to configure default font sizes, your editor
cannot find it. So it becomes necessary to manually zoom almost every web
page, almost every email, etc. to get a sufficient amount of information
onto the screen. That gets a little tiresome after a while.
The "Android Market" offers a wealth of applications, most of which are
available as free software or, at least, in a free-beer mode. When
browsing applications, one runs into the Android security model, which is
oriented around a
long set of capabilities which can be granted to applications. A
program which needs do things like access the net, obtain location data,
change hardware settings, etc. must declare the capabilities it needs;
these are then presented to the user at installation time. Most users will
probably just say "yes," but it is worth taking a closer look. Your editor
decided to decline the installation of a Mahjongg game after being unable
to figure out why it was asking for full network access.
Beyond the inevitable games (including one of the worst Tetris
implementations seen in a while), there is a wide variety of available
applications. The "Locale"
tool makes up for the (surprising) lack of the sort of "profile" feature
found on almost every handset your editor has ever seen; it performs tricks
like using the GPS
receiver to automatically change profiles when the phone enters the office
or a theater. The "bubble" application (shown on the left) turns the
handset into a portable
level. There's no shortage of "smart shopper" applications, most of which
can read a barcode using the camera and look up prices for items. There is
a "power manager" which attempts to configure the device for optimal power
use in a number of situations; it provides a basic profile functionality as
well, though the user should be prepared to spend some time configuring the
options into a workable form.
There's plenty of travel-oriented applications which will fetch weather
reports, currency rates, or call a taxi.
One notable omission, with both the base phone and the available
applications, is voice over IP functionality. This handset should be able
to do VOIP beautifully, but almost no such functionality is available.
There appears to be a tool for Skype users, but that's about it.
There are a couple of applications that are of particular interest to your
editor. ConnectBot is
an SSH client which works surprisingly well; the developers are clearly
working toward the creation of a tool useful for people logging into
Linux-like systems. And the terminal emulator provides that all-important
feature: a shell prompt on the device. Even more fun, on the Dev Phone, a
simple "su" with no password will yield a root shell.
Playing around on the device, your editor sees that the ARM processor
provides a mighty 383 bogomips. It appears to have a little over 100MB of
usable memory. It's running a 2.6.25 kernel (known to be heavily modified)
with a single loadable module called "wlan." And so on. As useful as the
keyboard is, trying to use it to type commands at a shell which lacks a
history mechanism gets painful after a while. Time to go looking for an
There are other useful applications, of course, such as the one which actually
makes phone calls. Like the others, it lacks perfection, but one can only
assume that, on a platform driven by free software, that imperfect
applications will be improved or replaced. How easy it is to do such
things is part of what your editor intends to find out in the coming
months. Stay tuned.
Comments (37 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Filesystem capabilities in Fedora 10; New vulnerabilities in OpenSSL, samba, xen, xterm,...
- Kernel: 2.6.29 merge window, part 1; The future for grsecurity; Btrfs aims for the mainline
- Distributions: Social networking and the Linux distribution; Fedora Unity F9 respins; FreeBSD 7.1-RELEASE; GNUmed Live CD 0.3.8; Lunar Linux 1.6.4; Tin Hat 20081229; Debian votes to move forward with Lenny release; Debian FOSDEM talks!
- Development: BleachBit: Does GNU/Linux need the equivalent of a Windows registry cleaner?, Firebird Roadmap, AMD releases R600/700 3D code, GNOME DVCS survey, finance apps for Linux, new versions of PyGreSQL, BusyBox, Samba, Hosts3D, Twisted, matplotlib, gEDA/gaf, SQL-Ledger, Lepton, Wine, binutils, RFIDIOt, Valgrind, Mercurial, monotone.
- Press: 2009 predictions, a look at 2008, Palm to unveil Linux-based Nova, screen videos with Linux, NEPOMUK Project review, Splashtop review, Android on the netbook.
- Announcements: vxVistA open-sourced, FSFE New Year's Resolution Fellowship campaign, OLPC changes, Openmoko in 2009, Metasploit eXploits contest, UK Perl tutorials, Python training, audio compilation cfw, FOSDEM GNOME Devroom cfp, LAC cfp, OpenSource World cfp, SeacureIT cfp, uCon cfp, Belgian Perl, FOSS Nigeria, LCA miniconfs.