2006-11-27

Eye candy

I retract my previous jest regarding being in with the IT guys. One of them hooked my workstation up with Beryl and I'm gushing like the geek I am. I remember seeing some vids/demos of it over this past year and I thought it was nifty... I never thought I'd actually play with it. A) I don't have root at work and B) my linux box at home is not that powerful.

But now I can. Yes it's completely useless, doesn't do anything that I actually need, and it's kind of distracting; I find myself playing more with the window manager than I am working at times. However, I think there's nothing wrong with eye candy, and I think no matter how much people harp on bloated overkill waste-of-cycles things, they internally know that style counts for something. I mean, just look at cars and cell phones and Apple products. "function over form"... yes, but not that's not to say that form doesn't count. As for me, anything to break the monotony of the screen I stare at all day is a plus.

2006-11-08

Linux Layout

Over the course of my life in the Unix/Unix-like world it's every so often occurred to me that there's just gotta be a better directory layout for the beast. 2 things about that: 1) it's messy with items belonging to the same program spread all over the place and mixed in with other applications making it hard to keep track of; and 2) the places programs want to install to are root-owned so adding new programs on my own as a non-root become more work, if not downright frustrating, to put it somewhere else.

WHY!!! is it standard operating procedure in the Linux community to assume that everyone has root?

Anyhow, one of the frustrating things is wanting to try out new packages and having to jump through hoops to get it to work in place without installing files into X different directories. I'd envisioned many times a system where applications were self contained in their own sub-directory tree that can be easily maintained and deleted if desired. There would of course be a convention for searching and sharing dependent libraries and items. I guess this is how it's done in the new OS-X world, good for them.

I recently read about a Linux distro that does exactly that: GoboLinux. It's nearly exactly what I was thinking of and I strongly suspect that it has occurred to the minds of a LOT of Unix/Linux users.

Reading the forums and talkbacks and comments though, it seems like there are a lot of people that are against the idea of re-organizing the Unix layout of /bin /sbin /usr/bin /usr/sbin /usr/lib /opt /etc etc. etc. They seem to fall into 3 camps:

  1. Too Windows like... dumbing it down for the n00bs... things of that nature
  2. There are good reasons for the layout, aint-broke-don't-fix
  3. Too set in our ways
Number 1 I dismiss outright... partly because I don't find it really true (being more Windows like) and partly because I think they just like being "in the know" of some esoteric stuff and want a barrier to entry.

Number 2 probably has some valid points but I don't fully buy it. They seem to think Unix was designed to be sensible. There were indeed decisions for the layout but by and large I'm convinced that it grew organically from a day when there were far far fewer applications and when memory and space and speed were at a premium. IMHO, there was really no long-term plan for this organization and this directory structure just doesn't scale well to the number of users and applications now. It's created a mess and all the work on packaging and dependency tracking were grafted on and only serve to obfuscate the basic underlying cause being this antiquated file tree.

Number 3 is probably why we're forever going to be stuck with complicated system management.

Thing of it is, there are already good examples to refute the reasons not to have an alternate organization scheme for applications and files. OS-X is one example it's a BSD based system. But there are other sub-examples in the typical Linux world. Rubygems comes to mind immediately. It's relatively simple (only 1 command organizes the whole thing), gracefully handles multiple versions of the same package, and casual inspection of the tree proves it to be fairly logical.

I may try out GoboLinux at some point, they even have a Live CD which I find impressive. They made a couple of design decisions that I find practical and interesting and possibly even better than what I was originally imagining. The linking of pertinent files to the old tree structure is sensible. I had imagined turning the includes, paths, and library finding features into more of a device such that any attempted access to /usr/local/lib/xxx.so would be handled by the system as a redirect, like the way web pages are. It was just a thought experiment. Links (and the possibly clever use of hiding) seems more practical. I just fear that dependence on the old tree structure will remain if one always assumes it's there.

But again there's the inertia problem. Not enough people would conform to the new layout. The spark of hope is that if developers would make their program installs well enough to easily allow installation to non-standard places, then this may become less and less of an issue. I'd certainly welcome a system where the organization is implicit and not reliant on a myriad of package handlers where there are as many as there are distributions.