The Utopia of Program Management
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.
E-mail Print r 4   · Read More · 69 Comment(s) http://osne.ws/f7j
Thread beginning with comment 313053
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Another comment
by Thom_Holwerda on Tue 6th May 2008 10:12 UTC in reply to "Another comment"
Thom_Holwerda
Member since:
2005-06-29

If each program has an "internal" version number, then perhaps the corresponding /Settings/User/X directory be the version number instead of the program name? So if Garden Designer is v846, then the file is /Settings/User1/846. This way, you'd really be able to run parallel versions of apps.

But there's another problem - there might be another program that is internally 846. We need a unique number. Wait, that already exists!; enter the GUID.


And how user friendly is that? The hierarchy I devised is supposed to be 'human readable' - actually, that was one of its primary goals. File systems have been a mess since day one, and it simply needs to be fixed. OS X made tremendous strides in that regard, but in the end it's just a virtual directory structure draped over a traditional UNIX/POSIX structure.

This is why there are hidden directories.


Hidden directories are evil. If a system needs to be secretive in order to not confuse a user, there's a design error somewhere.

Also, your arbitrary requirement of the settings directory sharing the name of the software package will need some sort of low-level monitor.


I addressed that issue with a typical utopian statement in the article:

"To prevent the mess Mac OS X has with separating settings files from the program bundles, the system should somehow 'know' the two belong together - this shouldn't be too hard to realise. One option would be to use BFS-like attributes; the Garden Designer settings file could have an attribute attached to it that links it to the Garden Designer application bundle, for instance. This way, when you want to remove Garden Designer from your system, the system can ask you if you want to delete its settings files too."

Reply Parent Score: 0