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.
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.
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.