Linked by Thom Holwerda on Mon 5th May 2008 21:00 UTC
OSNews, Generic OSes Ever since I started using computers, I've been baffled by the relative clumsiness of installing applications. Whether we are talking the really old days (launching the Rambo game off a tape), the '90s (running Keen or using installers in Windows 95), or the modern days (still those installers, but now also package management and self-contained applications); it's all relatively cumbersome, and they all have their downsides. I decided to put my money where my mouth is, and come up with my idealistic, utopian method of installing, running, updating, and uninstalling applications.
Permalink for comment 313049
To read all comments associated with this story, please click here.
Comment by Thom_Holwerda
by Thom_Holwerda on Tue 6th May 2008 10:00 UTC
Member since:

Quite a few constructive comments already, thanks guys and lady - that's exactly what I was aiming for. It's one thing to come up with an idea, it's another to be flexible and open enough to take in any criticism (valid or not) and deal with it. I'll address the two repeating issues here, and will address any specific questions in replies to their respective comments.

First I'd like to point out to everyone that this is supposed to be the utopia of program management. Utopia kind of implies that it is impossible to achieve fully. Take any utopia, and you'll see there's massive overlooking of details, or simply not answering certain pressing questions as to ignore certain weaknesses (Earth in Star Trek, anyone?). So, certain things are most likely never fixable or addressable.

What about shared libraries?

This is the most valid of criticisms, and also the hardest to properly address. A typical utopian solution is this: common libraries go into /System, and any special or uncommon libraries go into the program bundle they belong to. Nice utopia, of course, but this raises the question: what is common, and what isn't? I can imagine the operating system vendor/programmers making that decision - they can provide a base set of libraries from the get go, and then listen to developer feedback as to which libraries they like and want in the basic set of libraries.

But you all have a very valid point: this is one of those things that requires balancing on a very thin line. For a company like Apple, something like this is easy to solve (Apple is god in their world), for Microsoft it's a lot more difficult, and for the open source world it's nigh on impossible.

Why not put /Settings in /Users/User 1?

Because that goes against my personal (it's MY utopia, after all ;) ) idea about what the home directory should contain: a user's home directory is for files like photos, documents, pr0n - not for settings or config files. I always find it extremely clumsy to see stuff in my home directory that I would rarely manually touch anyway. I created the separate /Settings hierarchy for this purpose. Settings files != user docs, simply put.

Like I said, this is my utopia, and it might very well be that just about anyone else would like /Settings in their home directory - I don't know. A few of you proposed something like /Users/User 1/Settings - I could probably live with that ;) .

Reply Score: 1