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.
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.
User Interface Experience
Of course, GUI problems are only an issue if one is using the GUI to begin with. In the Linux community there is still a prevalent attitude that every computer user should have, at least to some degree, a willingness to open a Command Line Interface (CLI) and type away at their computer. This will not fly with an expanded userbase. GUI and CLI are completely different types of interaction. A CLI session requires an extremely large amount of recall memory, knowing exactly which, “magic words,” (i.e. commands, parameters and syntax) will create the desired effect. Knowing these words is also a willingness to devote part of one’s memory to remembering them as is. There are manuals, but needing to always refer to a manual removes from the experience and creates a hurdle for many users.
GUIs on the other hand provide the user with clues and feedback to help aid their memory. You do not need to always remember which switch or button does what because many times they are labeled according to the action. Menus use language that also aids in narrowing down possibilities to find what you want. Instead of spending time remembering the magic words for each and every application you will ever need to use, GUI applications provide a much more comprehensive paradigm, where learning the paradigm once will translate into being able to understand and manipulate many more applications. A far more practical use of memory.
Lack of Attention to Detail
Simply deciding to use a GUI over a CLI does not immediately prepare your application (or Operating System) for the Big Time however. Once ported into a GUI, many Linux applications still fail in their lack of attention to detail. For example, take the new Network Manager being used extensively in Ubuntu and Fedora. It provides a very nice interface to ifconfig and iptables. When I connect my USB 3G modem from one profile I am able to subsequently select, “Disconnect,” and it will sever the connection. If I try to connect to a different profile, that disconnect function does not work. I cannot think of a logical reason why this would be the case. Network Manager only handles one modem connection, and in fact is only handling one connection period. Should the disconnect not sever that one existing connection? This is just but one example where expected behavior is not met, which would cause an average user to cry bloody murder, call the application stupid and move back to another operating system completely.
The lack of attention to detail also comes into play when Linux GUI applications fail. When a Windows application fails, it tends to seize the whole system and require a complete reboot. Users are accustomed to this, and usually know not to repeat the action that caused the seize (or at least some do…). When a Mac application fails, many times it will simply close the window, claim that the application has performed unexpectedly and been closed, or ask if you want to force quit. An upgrade from the Windows alternative, as it usually does not require a complete reboot, simply a restart of the specific application.
Linux applications have demonstrated, at least in some cases, a level even better than Mac (which in my opinion is a more graceful crash than Windows). Linux applications, at least the GNOME and cross-platform apps I have used, when encountering an application-wide issue, will freeze a bit (oftentimes locking up the entire windowing system) but then resume operation, provide a crash report in some external window (or pop up a terminal), and continue on their merry way. This action, though from a performance standpoint is very specific and does not crash an entire system, or even the app itself, is too much for the average user.
Crash reports can be scary, including scary messages, scary memory addresses, and scary words, which are often some obscure API class name or function call and are completely unhelpful in resolving the problem. Popping up windows also confuses users, who may not be aware that that single warning frame has grabbed focus (even though it popped up behind the full-screened application). Users are not accustomed to applications telling them what is wrong, and telling them what is wrong in computer-speak only is not a way to educate users as to their mistakes. Until developers create more graceful and informative crash/error reports and dialogs, maybe it is better to just crash the app completely in a Mac-style way.
File Formats
Crashing and user experience are all about making the user comfortable in the environment out of the box, because that is the expectation of users these days. As developers, we all know that out-of-the-box experience is not only a combination of application functionality, but also of the ability to manipulate all types of data that user may throw at it and right now Linux does not handle the most important formats of all: MP3s and DVD video. Of course there are very legitimate reasons for this from an FOSS-philosophy standpoint, but new users will not care about this.
This is not to say they shouldn’t however. Instead of simply not allowing the formats, if there is a true belief in FOSS-mentality amongst all users of Linux and FOSS, then there should be transition tools to help migrate users into new formats. Services should be set up so that for inexpensive costs, entire music collections can legally be migrated to .ogg or .flac. Movements should be made to somehow secure legal rights to the DVD video codecs so that users can play their favorite formats. Users should be educated in which music-playing hardware can support FOSS multimedia codecs. Yet this does not happen, and instead of people condoling them, they offer obnoxious workarounds or sometimes even simple, “Deal with it,” atitudes.
The Community
Yet all of these small, nit-picky, programmatic issues regarding the actual architecture of Linux and many FOSS projects are simply the user-level indicators of much larger community trends, which when the stereotypes are fulfilled, are single-handedly preventing Linux from making it to the Big Time. In fact some may ask, does the community really even want Linux to go Big Time?
Let’s attack the community where it lives: the Internet. There exist very few common-user appropriate, “real space,” helpful institutions or companies that are willing to promote Linux. The Linux community has always existed on the web, in forums and Usenet, ftp servers and mailing lists. And though these are more common nowadays, the average computer user still does not make use of the Web in such as a fashion as Linux users have been doing for going on twenty years now. Until Linux people can step out of their cyber-realms and into the physical world, people will continue to perceive Linux as something ethereal, existing only for the most wizardly of computer users in Cyberspace.
The community has also always developed amongst the elite computer users of the world: the system administrators, the, “basement hackers,” scientists and researchers. It is because of this that many of the above problems exist in the first place. Many of these groups are highly oriented towards speed, efficiency, and thus as a result, customization; mixing and matching parts like the mad scientists some of them are to create the perfect beast of a computer, highly optimized for specific tasks. Who needs graceful crashing when you wrote the program in the first place and know exactly why it crashed.
Finally, there is the notion of the community to push out any code that is at least, “dog-foodable,” (term taken from the Chandler Team) and then get everyone in on development. It also means that a Linux perspective of a finished application is different from many other applications. I can probably count the number of applications (qualifier: GUI-based, common-user perception of application, i.e. not locate or gcc, etc.) on my desktop with a version > 1.0 on one hand. And this is out of the dozens I use regularly. This difference in perception actual creates many hurdles bringing over new users who expect that by the time they install an application, it will have a high degree of polish in everything it does.
The Other Issues
Of course, these larger issues do not even begin to cover all of the minor issues that need to be resolved before Linux hits the Big Time, including device support, an overall more responsive and fast windowing system, lack of big name applications like Microsoft Office (even Mac has Microsoft Office), or the Adobe Creative Suite. Not to mention lack of big name games. Not to mention a different, and also exposed, notion of libraries. Not to mention the plethora of branding applied to the community (distribution branding, flavor branding, etc). Not to mention the rapid-release cycle of new applications and updates. Not to mention the lack of a single entity to go complain to (people like to have targets). I am pretty sure I could continue this list. But I think we get the point.
Conclusion
It’s obvious that Linux is not ready for the Big Time. The reasons spelled out above, and by almost all of the articles on the web regarding this same topic, are fairly conclusive, even if only in an anecdotal sense. The common user is a picky creature, wanting certain things, expecting certain capabilities from their computer, and intolerant of that which does not provide per spec. Yet there exists a thriving Linux community, and somehow Linux is making its way into the public perspective.
In spite of all mentioned above, the real problem with Linux is not sound or GUIs or crash reports, but a much bigger one: we, as a Linux Community, don’t know where we want it to go. Many of us joined because we disliked Microsoft of Unix and wanted to beat them at their own game, which means taking over desktops and servers. We are at a time in the software’s life where we need to decide, what do we actually want? Do we still want simply to beat Microsoft and Unix? Stay tuned for Part Two of this series next week: Linux, Do We Want To Go Big Time?
Powered by ScribeFire.





Subscribe to RSS!

