Many of my neighbors are retirees who have computers their children or grandchildren gave them primarily for email. We’re talking Windows 98 or Windows 95 more often than not, and there always seem to be problems since these tend to be castoff machines to begin with. I try to help when I can. But you know what? I’d like my computer to “just work” too.
I republished Adam Doxtater’s review of the new SuSE commercialized “Linux Desktop” with all kinds of add-ons included because, as I pointed out at the time, he said pretty much the same things I was going to say in the review I was getting ready to write when he offered his to us.
Here’s a paragraph from Adam’s review:
– YaST Online Update – This is a great tool in theory, but I cannot get it to work to save my life. Even when I was using SuSE as my main workstation distro, I couldn’t get it to work reliably. First, I would recommend that SuSE find some faster, more reliable mirrors for their updates. The current list is horrible. Most of the time, YaST will just hang searching for the update server. I know this isn’t a connection problem on my end because I’m on a 3MB connection where everything downloads at the speed of light… and for YaST to search for twenty minutes and hang looking for a mirror is unacceptable.
Presumably someone, somewhere can get YaST Online Update to work, but neither Adam nor I have had any success with it. This is an important tool, one SuSE boasts about as a reason to buy their distro instead of others, and it’s not even Open Source but a “secret sauce” thing. It’s not some contributed package for which SuSE can disclaim responsibility, but their own work. Except it doesn’t work — at least for several people I know, including some who otherwise love SuSE’s products.
I can also pick on Mandrake about broken supermount and DrakSync in some versions they’ve shipped, and on Red Hat for the old “wrong GCC version” fiasco and some other major bloopers. Pick any packaged Linux distro, and it’s almost certain to have something in it that simply doesn’t work.
The list of proprietary software “doesn’t work” bloopers is so long that NewsForge’s parent, OSDN, doesn’t have enough server space to hold them all — and we have a huge cage at a big Exodus facility.
Mind you, I’m not nitpicking about little screwy things or even a crash now and then, but about things that don’t work at all, like you click on the button and nothing happens.
I have raved about Bluefish and NEdit many times. These are two programs I use daily. There are more sophisticated text and HTML editors out there, and I’m sure vi and emacs are far superior to either one in every way (in some people’s eyes), but these two programs just work for me. They do what I need, quietly, without complaint, without any effort on my part. They are good tools, and I appreciate good tools.
I didn’t have much respect for Mozilla for a long time. I’d hear that release 0.67.1568 was fairly stable, but when I got around to downloading it, the latest build would be 0.68.1476, and it would crash every 10 seconds. I got tired of playing “Mozilla build roulette” and stuck to an older, clunkier browser that crashed less often.
Then Mozilla got decent, and now I happily use it. Flaws and frustration? Sure. Plenty. Enough for an entire article I’ll probably write sooner or later. But on the whole Mozilla does most of what it’s supposed to do fairly well.
I’ve tried plenty of other browsers, including recent versions of MSIE (on other people’s computers), and Mozilla is my favorite. If Microsoft came out with a native Linux port of Explorer tomorrow, I would still use Mozilla. Opera is nice, Galeon is great, Konqueror has many good aspects to it, and I still fire up Lynx once in a while out of sheer Luddite cussedness, but Mozilla is my “daily driver” and will probably remain so for the forseeable future.
Software is the most complicated thing people make
A great excuse. But not necessarily true. Each physical part in a car took plenty of skill to design and make. If you equate each design and manufacturing operation with a line of code, suddenly the car and a major piece of software look quite close to each other in complexity. Don’t forget, a lot of the work that goes into the car isn’t just shaping metal and plastic, but making the raw metal and plastic in the first place. Materials science adds a whole level of complexity to almost any physical manufacturing process, one that software does not have.
I am on the Bluefish developers’ email list, and I watch the amount of care and testing that goes into each change, bug fix, and feature addition. I watch project leader Olivier Sessink worry — even agonize — over every “major number” release. I watch patches and new features get submitted, and tested, and revised, and tested again, and finally accepted.
This is a volunteer project, with developers and helpers in a number of countries, not all of whom have time they can afford to contribute every month. And yet, because of careful testing, it all seems to work, and every major Bluefish release is better than the one before.
I seem to recall hearing about another volunteer software project called something like Line Icks — or maybe it was Lean Ox — or something like that, anyway, that follows a similar pattern and seems to turn out some pretty good work.
So we know it can be done — that software made by volunteer development teams can just work. I’ve seen software written by professional, all-in-the-same-place corporate developers that just worked, too.
Attention to detail is important
A developer may not think a little missing feature is important. SuSE may think their product is so wonderful that my inability to get updates easily will not overcome my love for the rest of their offering.
Wrong.
Another car comparison: The way body panels fit together on most American cars built in the 1970s was lousy. You’d look at a door on a brand-new Chevrolet Malibu, and the gap between it and the rest of the body would taper from top to bottom or bottom to top. To General Motors this bit of slop was apparently no big deal; it didn’t affect performance, gas mileage or comfort. A little paint run on the bottom edge of a fender? With a good coat of wax, who would notice?
Customers noticed. They noticed that Japanese cars, on the average, had much better “fit and finish” than American cars. Suddenly, given a choice between a small Ford and a Toyota that got similar gas mileage and gave similar performance, American car buyers started to choose the Toyota, to the point where many Toyota dealers were adding “additional dealer markups” of up to $1000 to each car’s price because they couldn’t get enough of them to meet the demand, while American car dealers were giving deep discounts and special finance deals in an attempt to get someone, anyone, to please buy a car from them instead of from the Japanese car dealers.
The “slop” in 70s American car design and manufacture was, sadly, not confined to body parts. Many mechanical “details” were just as poorly thought out and put together, and some of them — like wiring connectors not fully seated — caused needless trips to dealer service departments for warranty repairs and, all too often, calls to towing companies.
Software is the same way. Little bugs — from the developers’ viewpoint — can create problems that are big in users’ eyes. There is huge temptation to add features instead of trying to make simple things that work well in both software and cars. Electric windows don’t do any good if a car overheats after 10 minutes and becomes useless. Added software features don’t do any good if the program doesn’t run smoothly in the first place. Attention to detail is the key, along with constant testing. Customers/users are usually right when they assume poorly-done visible details are an indication of sloppy work all through a product.
The mindset that produces clean, efficient code almost always results in a smooth user experience as well. You can turn this statement around if you like. It’s true from either direction.
Linux distributions that try to do too much
I see a healthy trend away from a “one size fits all” mentality in Linux distributions. I believe a “let’s put every package we can think of in our distro by default so we can boast about offering more than anyone else” thought pattern is harmful. I would rather have a distribution that installs exactly the desktop tools I need, and puts them on a well-organized menu where I can find them easily, and gives me an easy way to find out what each package does. Server admins don’t need the same packages I do, and need different documentation.
A distribution that just works for me may not work well for someone with different requirements. I’m sure I would find Red Hat’s top-end server product daunting and unwieldly, while someone who needs most or all of its features would find Red Hat’s personal edition nearly useless.
The problem, of course, is that different desktop users and different server admins all have different requirements. The ability to customize an installation therefore becomes supremely important. Gentoo is going in this direction, and LinuxFromScratch takes the idea of a personally-customized distribution as far as it can possibly go. Sadly, neither one does a “point and click” user much good at this stage of their development.
Debian offers plenty of customization options and is reknowned for stability (“it just works”) — once you get everything installed and, if you’re a point/click user, the menus set up the way you want them. Again, the installation process is too geeky for many. But in the case of Debian, the commercial Libranet and Xandros distributions can help a newcomer get a basic install going without a lot of command line work, and offer GUI-based front ends to the classic, highly-regarded Debian APT package management system.
The latest vs. the greatest
Wow! A great new feature! A new piece of software! I’ve got to have it! Today! Where can I download it??!!
A common personal trait among Linux users — even among us point/click people at the bottom of the Linux skill ladder — is a desire to experiment and try new things. I mean, if we weren’t a little more curious than the average computer user, why would we have tried Linux in the first place?
The problem is, this urge often gets us into trouble. It is also the force that leads us to request endless new features from developers and distribution publishers, who often listen to us even when it would be wiser for them to make their current products run smoother and more reliably.
The tech media — including NewsForge — feed this problem. “Ooooh! New and Shiny Stuff For You!” is a groovier headline than “Incremental Improvement Makes Popular Program a Little Bit Better.”
It’s an endless circle. Readers (software users) like to hear about the latest stuff. Reporters and editors shamelessly feed this desire. Developers who want recognition (or money) try to come up with a constant stream of new features and/or products to feed this hunger.
And some of those new products and features really aren’t ready for prime time. More often than not, the latest is not the greatest.
Breaking the cycle
I’m personally moving away from the latest software (or latest release) and sticking more to “tried and true” products, at least for everyday use. Part of my job is obviously to test and review new software. I’m going to put a separate partition on my next computer (my current one has a tiny hard drive) and do all test installs there.
As long as I can restrain myself, and keep from suddenly deciding I must have untestedware v 0.01 on my “real work” partition because of its many new and exciting features, I will have a more stable system.
I’ll also try to write and run more stories about incremental improvements in existing software. This is an area that doesn’t get enough publicity.
But that’s all I can do — myself — to break the sad software development cycle of endless new features that may or may not work.
The rest is up to you, whether you are a developer, a journalist or a software user — or fit into two or three of these roles, as so many do.
Category:
- Migration
