Linux: Not Ready for the Big Time

This entry is the first in a series covering GNU/Linux, an Operating System consisting of the Linux Kernel and applications from the Free and Open Source Software (FOSS) community, with an emphasis on its connections to the developing world.  These articles assume at least a moderate understanding of the Linux and FOSS communities.  For more information regarding these, I would direct interested parties to Linux.org as well as the Free Software Foundation and finally, for the truly interested, the GNU Manifesto. With all of this knowledge now in hand, I hope you enjoy the series.Tux

Many an article has been written regarding how, “Linux,” is not ready for the big time.  It seems every year, and with every new iteration of a major distribution such as Debian, Ubuntu, or Fedora, yet another computer pundit decides to come out and emphasize why Linux is not ready to even attempt at replacing Windows as the dominant Operating System for home computer use.  I am going to continue in this trend, and I won’t even try to sell my reasons as different, or more profound from these other articles.  Instead, I am hoping the article is simply able to stand under its own weight as well as provide groundwork for future articles in this series.

Sound

To begin, let us take a look at some of the more annoying technical reasons that prevent Linux from becoming Big Time.  The first and foremost technical issues preventing primacy are two: lack of a unified sound system and lack of a standard Graphical User Interface toolkit or API.  Let us take sound first.  We all know that when a problem arises in a system, growing the system size in an attempt to fix the problem will only add to system complexity.  This has been the result of the Linux sound subsystem.  Problems with existing sound systems such as ALSA lead to forks in projects, or completely different projects to begin with such as OSS and PulseAudio.

However, there is a lack of control over which system is dominant, and it seems each layer of the software stack is able to change sound system preferences, adding significantly to troubleshooting time.  If my sound is not working in an application, I must first check the system’s sound preferences to see which subsystem my OS is using, then confirm that my application and all intermediary applications (such as a mixer) are also using the same system.  This creates far too many points of failure for the common user, especially when sound is such a critical selling point in these days of Media PCs, MP3s and playlists.

User Interface API

The duplication of functionality in sound systems is also apparent in GUI APIs.  With Windows, there is a dominant GUI API in the form of Win32.  On Mac, there is a strong programmer emphasis to use the Cocoa Application Framework.  However, with Linux, which API do you use?  If you are a GNOME developer, it’s GTK.  If you are a KDE developer, it’s Qt.  But what if you are like me and you jump around from platform to platform (including to Windows and Mac)?  Tk? wxWidgets?  These offer native look and feel, but they do not offer the same access to API layers as programming for GNOME or KDE specifically.

Computer users nowadays expect a certain level of sameness from application to application, especially with refinements in Human-Computer Interaction (HCI) best practices, and a unified User Experience (UX) API makes such sameness achievable with minimal pain inflicted upon the developer.  It also makes teaching applications much easier when all application development follows some form of guideline for their HCI, guidelines which are provided by GNOME an KDE , but of which there is again, no uniform agreement within the Linux Community as a whole.

Advertisements

2 Comments

Filed under Linux

2 responses to “Linux: Not Ready for the Big Time

  1. Excellent article. We have a Linux (Ubuntu 9.10) box stand as our FOG imaging server, web server and Samba server (because of a lack of hardware). Seems as though every day I come into the classroom and have to wrestle with it just to make it cooperate throughout the day. I am learning Linux as I go, which is fun, but considering sustainability, I’m not sure how my counterpart will handle keeping the thing going after my term here.
    So, reading between the lines of your article, I have to whole-heartedly agree that Linux is not ready for deployment in the developing world. However, there is one keen advantage and that is that people in the developing world are not as reliant on proprietary formats. +1 for Linux.

  2. Glad you agree. The issues you described about your servers are very common place amongst new sys admins, but I promise you, once it gets up and running, it just works (a point that comes up next week).

    As for the developing world, I actually tend to disagree a little bit. I think Linux is ready enough that with proper instruction, we can teach more abstract computer use scenarios without locking people into the Windows mindset. It is what I am slowly trying to do. It just takes, like a server, a lot of setup to create situations where your students do not fall into the common pitfalls of Linux based distributions.

    I wish I could say the same about proprietary formats in Kenya, but this country is deluged by mp3 CDs and the most hideously encoded VideoCDs and DVDs I have ever seen. Even VLC has trouble handling most of them. Trying to convince some local artists I know to switch off of their illegal Fruitloops and MP3 was like trying to milk a bull: it just wouldn’t work for so many reasons!

    My third article in the series will hopefully be the most development oriented, so stay tuned and thanks for reading!