dcsimg

Myths Holding Back Linux

It's easy to pontificate about what computer users do and do not need, but nothing beats the real world when it comes to providing an education. I got mine many years ago, when I worked in tech support for a software company. One day, two old ladies working at a garbage dump in Washington, DC asked me to solve a major problem they were having. The problem turned out to be a loose ISA card, but to discover this the two ladies had to first open their computer. These women were not only oblivious to the operating system they were using (Dell Unix, believe it or not), they didn't even know you could open a computer. Still, they happily followed my instructions and removed cables, screws, and casing parts to fix this basic bug. They were great; I've worked with doctors who had much less patience than these two.








Trenches
TONY KLASSEN

It’s easy to pontificate about what computer users do and do not need, but nothing beats the real world when it comes to providing an education. I got mine many years ago, when I worked in tech support for a software company. One day, two old ladies working at a garbage dump in Washington, DC asked me to solve a major problem they were having. The problem turned out to be a loose ISA card, but to discover this the two ladies had to first open their computer. These women were not only oblivious to the operating system they were using (Dell Unix, believe it or not), they didn’t even know you could open a computer. Still, they happily followed my instructions and removed cables, screws, and casing parts to fix this basic bug. They were great; I’ve worked with doctors who had much less patience than these two.

In no time, their system was up and running. The lesson: It is personality, not just technical expertise that solves the problem. And a desktop is a very personable place in the Linux world. Users are not dumb. They are not fearful of their computers. When we talk about what the typical user does or does not want, we should give him a little more credit. People will invest time in computers, if they feel there’s something in it for them. Reasonable documentation goes a lot further than a Start button.

Which brings me to the Four Big Fallacies. Everyone has an opinion on what it will take to catapult Linux into the mainstream, but it seems to me that a lot of this thinking is actually based upon faulty premises. These are the four most egregious:

First Big Fallacy: Linux Needs to Look and Act Like Windows.

This mistaken maxim has its roots in the business world, where bosses think that if it’s not Windows it must not work very well. People hear this and think that the key to growing Linux on the desktop is a unified graphical environment, with a single set of API’s for components and toolkits. This was true during the painful early birth of desktop computing, but it’s not anymore. Linux isn’t just another child; it’s a whole new family dependent on choice, not uniformity. Uniformity is as much a limiting factor as it might be (and this is doubtful) a quick means to ease of use. Linux doesn’t need a unified UI. It will grow much faster with the adoption of — and adherence to — underlying standards.

The key here is that things interoperate, not that they look the same. Do we care what system we use to access the Internet? Not really. We can log on with any of a thousand different devices these days — telephones, pagers, PCs — but we do care that they all conform to the TCP/IP architectures designed for such interoperability. End users adapt to the different interfaces of these devices. In fact, they can choose the ones that meet their own specific needs, whether they’re Unix developers or a WebTV couch potatoes. It’s good for these disparate users to have different interfaces.

We old timers remember the rigors (and boredom) of working on the same ol’ interfaces for years. How many mainframe programmers really got a thrill out of MVS? Variety is not only the spice of life, it is the impetus to expand and grow. Standardizing the UI is like saying everyone should live on peanut butter and jelly sandwiches. Maybe it would work, but I’d rather live in a world with enchiladas and steak.

Some of you probably don’t remember the ugliness of working with Motif. True, it worked, and it standardized the Unix user interface, but it was ungodly bland in comparison to what you get with Qt and GTK+. One main advantage of the X Window System is that it unshackles you from the single-UI world of Windows or the MacOS. But ironically, it’s only been in recent years that people have begun to truly take advantage of X’s power. Without choice, without variety, we would never be able to push the boundaries of what can be done. And that, in turn, would limit what can be done for and by end users.

The Second Big Fallacy: Having Multiple Toolkits and Environments Breaks Compatibility Across Distributions

Having different toolkits doesn’t break compatibility across different distributions so long as those distributions can support those toolkits. Currently, that’s not a big problem with Qt and GTK+. Heck, it’s not even a problem with Motif anymore. There are even some that say we can’t go on with competing distributions. What? Are you kidding me? Isn’t this what we just fought so long and hard against Microsoft for? Competition is a good thing. In the long run, the most successful (though not necessarily the best technically) survive. It happens everywhere: the automobile and airline industries, the cola-wars, even publishing. We get down to a few serious competitors supported by groups of loyal followers. There is nothing wrong with GNOME and KDE competing. In fact, they’ll drive each other to work for improvements.

In his March 2000 Linux Magazine article on this very topic, Dave Whitinger pointed out that the community tends to fracture into hundreds of similar projects. In some cases that’s true (3D modelers come to mind). But with toolkits we’re pretty much set with three major players: GTK+, Qt, and Motif. With windowing environments we have many choices (Window Maker, Enlightenment, Blackbox, etc.), but it makes sense to have so many choices. These environments are targeted at different users running in different computing environments. Blackbox on my big bad graphics system is boring, while Enlightenment on the Pilot would be overkill. No one windowing environment can meet every need. Certainly not one that looks and behaves just like Microsoft’s sloth of an interface. Choice is key. Even when we’re confining the discussion to just the desktop.

But what the toolkits and the desktop environments (KDE and GNOME) have to agree upon is underlying services: drag and drop, component reuse, access to services, and so forth. It doesn’t matter what interface you plop on top of a word processor, but it does matter how that word processor determines which printer to use and what fonts are available.

The Third Big Fallacy: Microsoft is a Genius at Catering to the Developer Community

Microsoft is a genius at convincing developers they need what Microsoft has, but the company doesn’t cater to anyone but itself. As a developer, I can get more done with cscope, gdb, a few well placed printfs, and hand written makefiles than most people get done with integrated, graphical development environments. The best tool here is personal choice.

Microsoft’s development tools are not popular because developers love them; they’re popular because if you want full access to the Windows APIs, you really have no choice but to use them. What are the alternatives? Where is the choice? I can sow a field with ox and plow too, but given a choice of tools I’ll take a tractor.

The Fourth Big Fallacy: Linux Drivers Require Kernel Rebuilds

Device drivers intended for end user installation require kernel recompiles for Linux because driver authors tend to like living on the bleeding edge of kernel development. Youth loves a challenge. Experience says “just make it work.”

The problem here isn’t that Microsoft Windows doesn’t require kernel rebuilds — it’s that Linux driver authors do. Targeted development is a new arena for driver authors, but it requires stable distributions to become widespread. That’s happened. Now we can move towards binary distributions of drivers for end users (binary in that non-technical users need not worry about compiling software — the source code must still remain free and open to all of those who want it).

Driver authors need to understand who their target audience is. They need to be able to deliver binary, installed versions of the drivers for existing distributions and not expect that every Joe Schmo is using — or even wants to use — the bleeding edge.

Forget the killer application. Just get the common applications (office products, accounting, etc.) stable, usable, and compatible. The rest, by means of competing projects, will take care of itself.

The one area where we have a serious problem is Web browsing. We need Opera, Mozilla, and at least one other project. A choice of one (as it pretty much stands now) does little to improve the state of the art.

Those of us who remember the monotony and stagnation that had ossified the industry before Linux are excited to see these new choices. New interfaces, a choice of developer tools — these are part of the solution, not the problem. End users aren’t dumb — they’re not even scared, just inexperienced. No one has shown them the alternatives. We don’t want to follow the old world just to get a piece of the pie. We’re cooking a whole new meal.





Michael Hammel is the author of Artists Guide to the GIMP. He can be reached at mjhammel@graphics-muse.org.

Comments are closed.