Mark Mischke's Weblog

Linux, Day One

I got started with my Linux experiment a little early, but I'll still use it through the end of March. It seems that I'll use just about anything as an excuse to put off packing more stuff into boxes. I'm moving in two days.

Back to Linux. My machine is a 2.6 GHz P4, with 1 GB of RAM and all the trimmings. It runs Windows XP. Red Hat 9.0 (or whichever '.x' version was the most current on the FTP site) was installed in a Virtual PC 2004 session, and has 384 MB of RAM allocated to it. I did a custom install, choosing KDE and a variety of productivity tools (no dev stuff or server stuff). Performance under VPC is crisp, but I wish I had another fast machine to dedicate to Linux. I earn my living with this box, so I have to keep my toys in a sandbox... :-)

A couple of initial observations. I really like KDE. I'd guess that most users would find it as easy to use as any other major OS shell. They all have their pros, cons, quirks and personalities. It seems there's still a way to go with hiding the fact that you're running *NIX, though. Many Linux enthusiasts might not consider this important, or even desireable, but if Linux is to achieve its goal of mass appeal, hiding *NIX is essential. I see two major areas where it bleeds through:

1) Seeing all those modules load at boot-up. Geeks like me enjoy watching them, but my mother might not find them so entertaining, and might even think that she'd broken something.

2) Some of the bundled applications have clever, yet arcane names, possibly with origins in the developer's favorite fantasy role-playing game. These apps need to be renamed to something more descriptive, or the average user will be afraid of them.

Windows used to show a lot of stuff loading at boot time. It confused most people, and now we just see a clean, pretty graphic while everything's starting up. Linux/KDE/Red Hat (etc.) might consider mimicing this approach.

It's also pretty easy to pooch the display, by applying invalid video settings. Windows used to let you do that, and it was the cause of many headaches. Now they make you try newly-selected modes before committing to them. Linux needs that, too. The dude in Marketing probably appreciates that his old settings were saved as XF86Config.backup, but he probably doesn't appreciate that he now needs a geek to get him running again. All he was trying to do was get some more screen real estate to work on that fancy presentation that's due tomorrow. :-)

The purpose of my living in Linux for a month is not to bash it, or to give undue credit to its competition. It's to learn about an OS that I've dabbled with for about eight years, but never really invested the time to understand.

Cell phones and hiking

I'm an avid hiker. I enjoy nothing more than a full day of peak bagging. I'm also very much in tune with the risks of playing in the mountains. I've completed several backcountry first-aid courses and dealt with a few situations miles out in the bush, ranging from frostnip to minor head injuries to medication-induced thermoregulatory problems. I have a basic appreciation of how serious a problem can become when you're far from professional help.

I always carry a cell phone when I hike, and thankfully I've never needed to use it. This is a topic of much debate. There have been stories of hikers reaching a summit with their last iota of energy, and then placing a rescue call, expecting Superman to swoop down and deliver them to a warm hotel. These people represent the fringe of the Bell curve, and I believe that a cell phone should be a part of every day hiker's toolkit.

A cell phone should never be an excuse to push beyond the limts you'd set if you didn't have the cell phone, but it can make all the difference if you run into trouble.

If a medical emergency should arise, a cell phone can make all the difference - IF YOU HAVE A SIGNAL. If not, you need to fall back to conventional methods. Some people will try to climb to a ridge to get a signal. Bad idea. If you have a problem, and have a cell signal, use it. If not, deal with the situation with the tools that you DO have.

Multiday backpackers may feel that the weight of a cell phone is prohibitive. That's valid. These folks often saw the handles off their toothbrushes to save weight. :-) Still, I'd consider the weight-to-potential-benefit ratio. Personally, I'd pump a little more iron before my trip and carry the phone. Just make sure you seal it in a ziplock.

One caveat: turn the damn thing off. On one hike, my buddy accidently left his on vibrate, and during the descent, it started buzzing each time it caught a signal. Neither of us could figure out what was going on. We're like 'what the hell was that?', looking around for some natural phenomenon responsible for the noise. :-)

A month with Linux

I've decided to use Linux as my primary operating system for one month, to get a better take on how useful it is. My first experience with Linux was in the mid-90's - one of the Slackware releases, installed from floppies onto a 386 box with 8 MB of RAM. While impressive, it was hard to install, hard to configure and kludgy. Getting X to run could require days of tweaking. Over the years, I've played with new releases, but very little had changed up until recently.

I'll still have to use my XP box for my work, since I'm a .Net developer, but this won't stand in the way of the experiment. I've been using my iBook for all my non-work computing for well over a year. For the month of March, I'll use Linux instead.

I suppose that comparing Linux to my Mac will be unavoidable, but that's not much of a sin, because they're both *NIX. Apple succeeded in bringing *NIX to the masses, and hiding its details. The OpenSource crowd was a little late in figuring this part out, although the latest cuts of KDE and Gnome are pretty cool. I expect a lot. I expect my overall experience with Linux to be on par with that of Windows or OS X. I don't expect the experience to be the same - just on par.

I'm a geek. I write software for a living. I understand computers down to the metal - CPU registers, assembly language, compilers, the whole nine yards. Despite all that, I spend a lot of my time surfing the Web, pulling stuff off of USENET, emailing friends and ripping movies to DVD. My bar is set high when it comes to features and usability. I don't want to think about CPU registers or deal with arcane user interfaces when writing a document.

The Linux crowd has been vocal during the past few years, just as I've been harshly critical of them. Let's see if they've been as busy with their software as they've been with running their mouths. I'll post as I go...

Why most software sucks

This rant was inspired by a conversation with a user interface designer friend who has significantly more patience with developers than I would have if I were in her shoes. :-)

Software developers are people who write computer code and design the underlying architecture of software applications. With few exceptions, they are not automobile mechanics, they are not master chefs and they are also not user interface designers. I am a software developer, so I know what we are and what we aren't.

Many developers have never worked with UI designers, because many companies are unaware that the discipline exists. This is not meant as sarcasm. It's a fact that I've observed from working with a wide variety of clients as a software consultant. It's also the reason why most software sucks, and the reason why Apple products don't (no, this isn't going to turn into a pro-Apple rant...).

Because so many firms don't include proper UI design as part of the development lifecycle, the task often falls to the developers. Just as developers are not qualified to give tax advice, they are also not qualified to design user interfaces. The disciplines are distinctly different, and complimentary.

The process often follows this pattern: the developer takes a decent stab at creating a clean UI, then various other people - product managers, marketing folks and even development managers - suggest changes. This continues through several iterations until everyone is happy. The result is often a clean UI with a variety of interesting features that lacks uability. Basic elements of good UI design principles and practice were not followed because no one involved in the process had this domain knowledge. Everyone gets an A for effort, but the product might wind up getting a C.

Developers are very close to the code, and their lower-tier architectural creativity often bleeds up through the presentation layer. We all know about tiered architecture, yet why do so few developers make proper use of the presentation layer? The presentation layer is supposed to hide the details of the logic and data layers from the user. When presented with a well-designed UI to implement, it is never permissable for a developer to rebut with 'but the database design stipulates...' or 'but our object model requires...'. Those statements suggest that the architecture was designed in a vacuum, is inflexible and doesn't support the needs of the product. This leads to crappy products, poor sales and layoffs.

UI design should happen first, in parallel with the initial functional specification, and long before any code is written or any UML bubbles are pushed around in Rose or Visio. Developers should not drive the UI design process, or even have much say in it. It's not what we're good at.

Let it snow!

Attention greater Boston! I would like to introduce you to an invention that, when properly used, will change life as you know it. It's called the snowplow. I'll admit that I certainly see a lot of guys driving around with big blades on the front of their trucks, as well as a plethora of big orange trucks operated by various municipal DPWs. The problem is that none of them actually _plow_.

Never having operated a snowplow, I'm wholly unqualified to give advice on technique, but doesn't the plow have to make contact with the ground in order to be effective? What I see going on is plows hovering an inch or three above the asphalt, and leaving a slippery, packed layer of snow behind.

This doesn't happen anywhere other than in greater Boston. I grew up in Connecticut, and knew several plow operators. There, the roads were always plowed down to the pavement. I've driven home from New Hampshire's White Mountains in many a snowstorm, and plowing was aggressive during the storm, and the roads were bone dry afterward. As I said, I don't know much about plowing technique, but I _am_ qualified to compare end results. C'mon, guys. You'd have to improve just to get an F.

To illustrate how bad it is here, let's look at Cambridge. The side streets don't even get plowed. They pretty much just let the cars wear the snow away. We had four inches fall this lovely morning, and the major roads and minor highways in and around the area were a complete mess, with nary a plow in sight. This was hours after it began accumulating.

I'll get off my soapbox now. I have a Jeep, so I really don't give a rat's ass how much snow is on the ground. In fact, I like it when it's messy. :-)