I hold a grudge, I admit it. Months ago, when X started acting up on my central machine, I realized the time and effort spent trying to fix it could be alleviated completely by omitting it altogether.

And as I mentioned then, things have only gotten better. Steering clear of X and anything related has slimmed the system down to nothing without losing a sliver of function, made my system far more reliable, and taught me a thing or two about using still older machines.

But thinking back, my grudge goes deeper than just the failure of the siliconmotion driver (something, to my knowledge, that still doesn’t work), and really extends all the way to November, when all of X turned sour for me. When X shifted to a reliance on hal and dbus, and I had to rely on obscure options (that don’t seem to work anymore, I should add) to avoid using them, I realized the relationship had gone south.

Nowadays I’m hard-pressed to come up with a reason to like X as it travels in the direction it has taken. Consider:

• hal and dbus are heavier than I like. I realize that both are a mere speck in the grand scheme of things, but to me, it’s still more processes than used to be required. I am not so much of a code monkey to fully understand all the reasons why they’re necessary, but I know it has made things harder on me.

  I’ve scrambled a half-dozen installations simply by forgetting to start both hal and dbus before starting X, and without some sort of fallback or preventative check, the only result is that complete lockup. Power down the hard way, file systems go nutty, and the system needs major surgery to get back on its feet. 😐

• I don’t know what else to call it, so I’ll just say it: I don’t like the dontzap behavior. I got used to having CTRL+ALT+Backspace, and I’m one of those people who thinks there ought to be an escape route by default, not as an add-on.

  If X were 100 percent foolproof, if it never made a mistake and configured everything correctly every time, I couldn’t complain.

• But it doesn’t, and correcting it when it goes wrong is just as much work as setting it up the old way. In some cases, it’s actually more. As an example, I exchanged e-mails for a few days last month with a person setting up keyboard-switching in IceWM. To hear it explained, the old system required only a brief edit of xorg.conf, but the new arrangement needs much more attention.

  I don’t have the final details so maybe it’s not fair to hold that up to scrutiny, but it’s the way things seem to go for me too. My Inspiron, with an Arch installation in place (and yes, with hal and dbus running 🙄 ) can’t find the touchpad, or any of the four buttons unless there’s a PS2 mouse connected. It can find the pointer stick — which is important — but if there’s no mouse plugged in, it’s buttonless.

Maybe I’m being hypocritical, since I obviouly still use X on the Inspiron. I’m pleased to say that you can still run a hal-less and dbus-less system with Crux, but I get a sinking feeling every time there’s an update within xorg, because I know at some point that’s going to change.

Or maybe I just complain too much, and do too little, and should take some of my own advice. But instead I take the roundabout solution, and like I mentioned, I omit X altogether, for at least two (and sometimes more) machines.

That’s because short of fully preconfigured systems, like Ubuntu, I see now that X is not nearly as useful (or important) as I thought it was. Or maybe I should say, I see now that there is a lot to learn — and a lot to be gained — by leaving it out.