Wednesday, March 25, 2009

The year of the Linux desktop... again.

As usual, there have been a couple of recent articles surround Linux on the desktop including one from Infoworld and another on Datamation. Of course they were covered and discussed by all of the usual suspects. I feel that it's time for me to give my two cents on the topic.

Before we get too far into things, I think we need to get some nomenclature down. I use "Linux Desktop" to describe the case where Linux is the primary or sole operating system with which a user interacts with their computer on a routine basis. This implies that all of the applications that this user uses on anything other than a special case basis all all native Linux applications running on their desktop. If a user must maintain a virtual machine with some other operating system in it to run applications which they routinely (~daily) use, I'm not sure that this person is really running a "Linux Desktop".

There are several different scenarios or places for a "desktop". Each of these has distinct needs and uses cases for which Linux may, or may not, be a fit.

The first general area is a corporate setting. There are a couple of places in this setting where Linux makes sense and some where it doesn't. The most simple and most fitting place is as a desktop for technical users who are doing specific technical work for which there is native Linux software. These users are primarily working with applications native to Linux with other routine desktop tasks such as email, web browsing or office applications (spreadsheets, word processors, etc) being secondary uses of their machine. For this class of user, Linux makes perfect sense and other operating systems or end up being little more than terminals to some other UNIX machine. The next place where it makes sense is for very strictly configured desktops providing access to a very specific and limited set of applications -- most likely very task specific custom built applications. In this case, the desktop is little more than a modern green-screen terminal. Then there is the case where Linux simply won't work as the desktop. This is really driven by applications that are not available for Linux. For example, consider a user in the finance department that uses Crystal Reports and Microsoft Excel and shares documents with partner companies. Yes, OpenOffice.org provides a spreadsheet, but sharing anything other than the most basic files can be problematic. There are projects similar to Crystal Reports, but again, they are not 100% identical and bound to be problematic. It simply doesn't make sense to have to retrain staff to use tools that different than those generally accepted and used in their profession and then to deal with document conversions and corrections when sharing with other organizations -- the costs of this are just too significant to justify the Linux desktop for these users. In summary on the corporate front, there are a number of special cases where a Linux desktop makes sense, but plenty where it does not. My thought of the "perfect" corporate environment is one that recognizes that there are different tools and systems that suit different tasks. Users should use the tools that best suit their needs, not just force everyone to use the "corporate standard". The standards should be open standards that allow everything to work together -- think IMAP(S)/SMTP vs MAPI.

The other big area is the home setting, and like the corporate environment there are a number of different use cases. The simple use case, and the one where Linux makes sense, is for the technical user or hobbyist. These users specifically seek out Linux and understand its strengths and weaknesses. The next use case is what I'll call "grandma". When reading about "Linux on the desktop" I often read stories that pretty much go like "I blew away Windows on Grandma's computer and installed Linux for her. I remotely manage everything for her via ssh. All she does is basic web browsing and read email via web mail. She couldn't be happier with Linux." The keys to this is that (a) the computer is really nothing more than a basic web browser to the user and (b) there is someone much more technically skilled doing all of the work of patching the system, installing software, and troubleshooting things. For Grandma, it boils down to the computer being a simple tool that someone else takes maintains. Linux fits perfectly well here, but so does pretty much any other operating system. The last category is "Joe Six-pack" -- the typical person that buys a computer, maintains it themselves and may do any range of tasks on it. This is the largest user base and the one where Linux simply falls flat on its face and doesn't work.

So why doesn't Linux work for "Joe Six-pack"? There are several extremely important reasons that seem to often be lost on proponents of the Linux desktop.
  • Different distributions. Joe thinks of his computer as simply the computer. He may vaguely understand that there is this thing called "Windows" on it, but exactly what it is and the concept of an operating system are outside of his grasp, and more importantly his concern. He bought it at some big box store, plugged it in and turned it on. It's "The Computer". He doesn't care about the details of what's running as long as he can complete his tasks. One of the great strengths of Linux is the many different distributions and the innovation that comes with that. It's also a major problem for Joe. Given he can understand (or even wants to) he's running Linux (whatever that is), having to then further understand he's got Ubuntu or Fedora or RedHat or Suse or Gentoo or Mandriva or Kubuntu or Edubuntu or whatever is just too much. It's bad enough being an experienced technical user and having to translate what works on one distro to another -- it's simply far too much to ask of Joe. Hit with those questions, he'll look for a more simple solution. Remember that Joe wants a tool to complete a task, he doesn't want to learn all the details of the computer. The more he has to know and think about what's running on his computer, the less useful it is to him.
  • Different desktop environments. All of the different desktops have great attributes as do the stand alone window managers and simple text only console. The problem is, like the distribution issue, can quickly confuse Joe. I've been on a number of Linux User Group mailing lists where "newbies" ask simple UI questions like "my menu thingy disappeared, how do I get it back". Though these are "newbies" they are well above Joe and understand something about the community and joining the mailing lists for help. These answers always start off trying to help the "newbie" figure out which distribution, which desktop and which version of which desktop they are running. Again, this won't work for Joe. He just needs his menu back and having to go through this series of steps just won't work for him -- it's overly complex and requires effort and knowledge which Joe could care less about.
  • Applications. In the end, Joe's world is all about applications. The problems are two part. First with finding software and the second is the availability of software that actually meets his needs.
    • Finding Software: Joe is perfectly happy to stop by whatever store is nearby and buy a box with a CD/DVD with the application he needs. This is the same paradigm he uses for everything else in his world. If he needs a hammer, he goes to the store and chooses one from the shelf. If he's hungry, he goes to the grocery store and picks up what looks good. The current state of package managers is simply not good enough. First, it is a different paradigm than everything else in Joe's life (going to the store and buying it) but that is becoming less of an obstacle as people are accustomed to downloading and installing software. Joe is more likely to go to his favorite search engine, find software he wants and then want to click "download and install" and start using the application -- just as he can do with the predominant deskopt operating systems. With the plethora of distributions, this doesn't happen. Even if Joe finds a Linux compatible application, the likely hood of being able to click and install from that products web site is slim and at least would require him to understand which distribution he's using and probably require him to manually resolve some list of dependencies (does he really care what libfoo.1.4.3 is and if it's already on his machine?). The current state of package managers and the couple of line description of the software they provide is equally as confusing to Joe. It doesn't provide a rich and easy way to find an application and understand if it is what he wants.
    • Getting the right application. There are simply places where Linux does not have applications that would meet Joe's needs. He can't get tax preparation (TurboTax) software to do his taxes. OpenOffice.org is nice for most things Joe needs to do, but standby for flames the first time he has a problem importing or exporting an Microsoft Office document he got from a friend. Then there are the more difficult tasks such as video editing -- I've heard that it's going to be the year of video editing on Linux about as much as I've heard it's going to be the year of the Linux Desktop, and I'm still waiting. For technically inclined people, the above are not always issues since they understand the challenges, understand their options and in many cases simply enjoy working around the problems and coming up with solutions. Joe just wants to perform a task.
In many cases open source projects provide the best solution, regardless of price. There are, though, areas where these offerings just don't measure up, and the desktop for the typical/average user is one of those places. The desktop for the vast majority of users is about applications and completing a task. If they have to think too much about what an operating system is, let alone which one they have, or can't simply and easily find and use software for any wide range of tasks, then that desktop is simply not a viable option.

I've used Linux and other open source systems and tools for many years. I hope that this article will be considered constructive criticism and not just a rant or attack. I think competition and diversity ultimately result in the best solution, but that often has to be balanced with what the goal.

Wednesday, March 18, 2009

Back to Window Maker

What seems like ages ago, Window Maker was my choice of window managers on my unix workstations. I ran Window Maker on both my Linux and Solaris machines. As updates to Window Maker got fewer and farther between, I eventually succumb to the trend of "desktop environments" and started using Gnome. After enough fighting, tweaks and compromises, I got to a tollerable place and just lived with Gnome.

The other day at work, I decided to see how Window Maker was doing after all these years and what it would be like to go back to just a simple window manager instead of a "desktop environment". After quick install and a log out/log in, I was back in time to Window Maker. A few minutes of minor adjustments later, and good ol' version 0.92 was again making using X far more pleasurable than any "desktop environment" ever did. The simplicity and ease of configuring everything is a pleasant change from the complexity of Gnome.

What is it that makes Window Maker so nice (in my ever so humble opinion):
  • Very light weight. I don't end up with so many additional process for very little value (at least to me) as I would have with Gnome.
  • Aesthetically very pleasing. Granted this is mostly a copy of NeXTStep, but there is an amazing utilitarian beauty that's hard to find elsewhere. I spend a lot of time, seems like most of my waking hours, looking at computer screens so I would like something attractive to look at.
  • Simplicity of configuration. A nice GUI tool, WPrefs.app, can do pretty much all of the configuration. Of course, you're not limited to that either. All of the configuration is contained in six very simple text files. No XML. No longer many different files scattered across a myriad of different hidden directories. No more plethora of different GUI tools needed to adjust different aspects of the desktop.
  • Did I mention simple and straight forward and configurable with only vi?

A screen shot of my Linux workstation at home.


It's great to have switched back. It's even more exciting to see that development on the project seems to really be starting back up.

Monday, March 2, 2009

Avoiding Stalingrad

During World War II, the German operations on the eastern front ground to a halt at Stalingrad. Taking this city became a near obsession for the Germans forgetting their real objective, the oil fields of the Caucasus. The battle for Stalingrad embroiled the Wehrmacht in bloody urban combat for which their highly mechanized forces where ill-suited. Ultimately they chose to fight the wrong battle and ended up losing the war.

Though this is a short history lesson far outside of the IT industry, it has direct correlation to situations we face every day in designing and operating our systems. We end up focusing on the details of the immediate issue and band-aiding it instead of looking at the bigger picture and different solutions that do an end-run around the immediate problem. Moving to a fundamentally different solution is often hard for us for a couple of reasons. First, those of us in the IT industry tend to be very detail focused and looking at the details of the immediate problem is simply a natural thing for us. Second is our aversion to risk. We've learned, for better or worse, to only take small steps and make small changes in our systems to minimize the risk of something unexpected being introduced. Both of these can be very good traits in our day to day lives, but they can also lead us to our own Stalingrads when the problem is much bigger.

Now let's make all of this a bit more concrete with an example. Let's consider an internet facing OLTP system where, not surprisingly, the database is the single point of failure. This system also has a non-trivial SLA requiring very high levels of availability.

A very popular way to solve this problem, at least for projects that have a decent budget, is to build an active-passive shared storage cluster. This typically comprises the following components:
  • An enterprise RDBMs
  • A pair (or more) of proprietary UNIX servers
  • A enterprise storage array and its associated SAN
  • Clustering software to move LUNs on the storage array between server nodes and start/stop the RDBMs
All of these come with big feature lists and when assembled properly and meticulously maintained can provide rather respectable availability numbers.

This system design began life in the corporate back office where availability requirements and expectations where rather modest when compared to that of internet facing systems. Problems with this design begin to surface as we move this system to the internet and increase the availability requirement to nearly 100%. On a good day, we find that a simple server node fail over puts our SLA in jeopardy not to mention the bad day when the complexity of this system results in front page news.

A typical approach to solving this availability problem is to simply look at what causes problems in our cluster and try to band-aid them. We go back to the various vendors that sold us parts of our systems and add more of their features. We may look at their active-active database solutions to try and eliminate node fail over time. We may buy more disks and/or more storage arrays and replicate more copies of our database. We may buy the next greatest (and expensive) proprietary server with claims of greater uptime. We may try a different cluster package in hopes that its weaknesses will be better than the weaknesses of our current package. We keep trying to take this one system and add or incrementally change things to increase its availability.

This attempt to solve the availability problem is a typical occurrence in many companies. The focus is on how to fix a database cluster that doesn't measure up. The changes are incremental (minimized risk) band-aids to that cluster. Like the Germans trying to fight an urban battle with an army design for Blitzkrieg battles on large open planes, attempts to increase the availability of the closely coupled database cluster are ultimately futile. Closely coupled systems always have some common component that becomes a single point of failure. Adding more features to these clusters only adds complexity which in the long run further reduces availability . To win this specific war one has to:
  • Stop focusing on the database cluster. It's going to fail at some point no matter what you do. In fact, expect everything to fail at some point, design and operate around it (see ROC as one way to do look at this).
  • Solve the system problem, not the database problem. Look at the system as a whole and understand what it needs to functionally accomplish. Build a solution around this need -- don't just try to solve a database problem.
  • Expect to do things different than in the past since your requirements are non-trivially different than the past. If you find yourself saying "this is what we always do" or anything like that, you're probably going to end up with what you've always had -- something that doesn't meet the new requirements.
The moral of this story is that the skills that help us in our routine day to day life can actually be hindrances when bigger problems emerge. We have to realize when we are in this situation, pull ourselves out of it and fight to win the war, not the battle.

Sunday, March 1, 2009

First Posting

Well, I finally joined the world of "Web 2.0" and created a blog. In the past, I've always chosen to manage all of my web content myself on my own server (shared with several friends). I chose to use Blogger instead of doing it all myself. My motivation for this is really driven out of time, or rather my lack thereof. I definitely don't have time to write my own blog application. The time to maintain (update, patch, watch after spam, etc) an open source application running on my own server is also a bit too much at this time. "Out sourcing" all of this work makes sense for now and lets me focus on content.

Now that I have this blog up and running, we'll see how regularly I manage to post to it, and if the world ends up seeing value in what I post.

That's it for now.