Linux Loses Con Kolivas

There is quite a lot of noise about Con Kolivas, and his recent quiting Linux kernel development. Kolivas made enormous contributions in the way of improving desktop usability and responsiveness, drawing attention to this increasingly coalescing factor when few people were paying attention, presumably something of which Torvalds’ himself was not aware.

Con Kolivas’ quiting explains various issues with Linux these days. First, that Linux is primarily optimized for the uses of those that fund its continued development to the detriment of common desktop users (think IBM, they’ve invested millions of dollars into Linux –last I read– and have a lucrative server business based on Gnu-Linux). Meaning, that the continued development of the Linux kernel has been toward the server end and not the desktop user. That is to say, the Linux kernel does not meet ordinary desktop user needs. This is extraordinary. After all, Linux was initially an end user product, as Torvalds envisioned it to meet his university student needs — AFAIK these were not of the server kind in nature. Thus, Linux has lost it’s original vision of meeting the needs of the ordinary user, graphical in nature –albeit– nowadays.

What does this mean? Well, simply that Linux for the desktop is slow. Kolivas points out that given the processor speed increases, desktop responsiveness should be excellent. I can attest, it’s not, although he seems to allow a lack of hardware innovation to explain some of the discrepancy.

The other problem is the hostile Linux development environment where meritocracy does not assure the best ideas or code is accepted into the official kernel. What’s happened with Kolivas is that his ideas were rejected at first because evidence was initially anecdotal. So he designed his own test called “Contest” (one of two created) which demonstrated his code improves responsiveness (for everyday end users). More so, Kolivas’ scheduler code was demonstrated to be equally efficient as a later implementation of Kolivas’ idea –written by a Torvalds sanctioned coder. Torvalds’ justification for not committing the earlier scheduler is that Kolivas is openly aggressive with bug reporters and does not maintain his code, despite the lack of evidence or the evidence to the contrary (Torvalds admits to not reading -ck’s mailing list). On one end, this shows Torvalds plays surreptitious favourites, and on the other end this shows he makes uninformed decisions –perhaps being manipulated or swayed by the “good ol’ boy’s club”. I don’t know which is better or worse. In any case this suggests incompetence on Torvalds’ part and a weak developmental Linux model.

These problems are idiosyncratic of a dictatorship, and to this effect Torvalds is referred to as a “benign dictator”. Although, I don’t know how benign this may be when (as a consequence of your management style) you have a talented kernel debugger calling it quits, permanently. This brings one to ponder the BSD development model, which has a reputation for being closed to outside code development. Even so, it seems BSD’s board-like infrastructure entails accountability because it does not depend on one charismatic leader, thus limiting arbitrary decisions, as what happened with Kolivas’ contributions. Of course, this does at times fail, as it did with the disagreeable Theo de Raadt and NetBSD (but this may simply reflect de Raadt’s predisposition and NetBSD’s tolerance). The other critique given to BSD’s development model is its slow speed. Often code for new hardware technology is rejected. Sometimes this is for good reasons, such as low code quality. Other times, this development slows or even halts due to the monopolization of projects that do not advance, while others that might be more productive are not considered. I know this only too well as I’ve been waiting for FreeBSD’s PPC port for many years. It literally advances at a snail’s pace. In the end I got tired of waiting. (As a side note and as a result of helping out a newly arrived PPC ignorant egotistical developer, I was politely told to go out and run a Linux distro –presumably by the project leader. Thus, I installed NetBSD and wrote my own NetBSD-PPC install guide while at it.) But don’t take my word for BSD developmental problems, read Charles M. Hannum’s –one of NetBSD’s founding fathers- words,

"Often these projects stagnated, or never

progressed at all.  If they did, the motivators were often very slow.

As a result, many important projects have moved at a glacial pace, or

never materialized at all."
(<http://mail-index.netbsd.org/netbsd-users/2006/08/30/0016.html>)

Oddly, Charles M. Hannum credits Linux’s strong leadership (presumably Torvalds’) in part for Linux’s success in that email. It can be said that Torvalds’ failure to implement Kolivas’ ideas, or give the job to someone else (as with the scheduler), created a similar development slowdown.

It may be possible to unite the best of both developmental models, carefully avoiding the pitfalls (such as the tyranny of the Linux model. But one thing is clear for me, and that is … Linux development is dysfunctional. When you lose talented individuals such as Con Kolivas on nothing more than uninformed arbitrary decisions, something is rotten at the core.

Rather than waiting for a revolution in Linux development, perhaps it’s best to look at non-Linux based Libre OSes. If using non-Linux developed utilities is distasteful, as it is for me (I’ve become accustomed to apt-get’s simplicity, dependency resolution efficiency, and worry free “upgrade-ability”), there are options that provide the best of both worlds, the stability of BSD (or BSD based) kernels along with Debian’s utilities. Specifically, Debian GNU/kFreeBSD, Debian GNU/NetBSD, and Nexenta come to mind.

Of course if you’re not adamant about the Gnu user-land or associated utilities –but you still want a desktop from the get-go– you can look at either of MidnightBSD, DesktopBSD or PC-BSD. Although in this case I’d probably install their mother projects, but that’s just me showing my love for maximum GUI configurability. That is, I don’t like large graphical environments such as KDE, default on both DesktopBSD and PC-BSD. MidnightBSD is “between” window managers. It presently uses WindowMaker, but will use Étoilé (more of an environment, that incorporates WindowMaker) at a later date. Better yet, you can benefit from DesktopBSD and PC-BSD innovations by going along with the default install and un-installing their large desktop environments post-install.

If I were Kolivas I would look at the above projects for further participation, assuming that their development models avoid Linux failings. There is also Haiku and Syllable, both desktop oriented OSes. I’m unaware of their infrastructure.

Maurice Cepeda

For more info on Kolivas,
http://kerneltrap.org/node/465
http://weblog.infoworld.com/enterprisedesktop/archives/2007/09/desktop_linux_s.html

For the other side of the argument, although I find it unconvincing,
http://www.linux.com/feature/119256

This is licensed under the Attribution-NonCommercial-ShareAlike 3.0 Unported Creative Commons License. All brands mentioned are properties of their respective owners. By reading this article, the reader forgoes any accountability of the writer. The reading of this article implies acceptance of the above stipulations. The author requires attribution –by full name and URL– and notification of republications.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s