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.
Thread beginning with comment 313007
To read all comments associated with this story, please click here.
Another comment
by Adam S on Tue 6th May 2008 01:10 UTC
Adam S
Member since:
2005-04-01

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.

My point is, there are some really cool ideas in here, but ultimately, I think it needs a lot of refinement. Storing the settings in a separate space just means you've improperly used the home directory in the first place (see my above comment). Your permissions *will* be screwy when you put settings in one top level directory and user data in another. This is why there are hidden directories. Also, your arbitrary requirement of the settings directory sharing the name of the software package will need some sort of low-level monitor. It also means that when I release a new version of a package and choose to rename it with a version number, I can't reliably find your user settings from any of the last several versions of my software, I have to try every possible combo or not let you migrate your settings from any version but the last one.

Frankly, I think the current OS X way is near perfect, with plenty of room for small improvements. I don't think that, with disk space as it is, the system is "cluttered" by having lots of settings file - stored properly where settings should be stored! The idea is that it's persistent, it's there the next time you install the app. And I think Leopard's Spotlight is plenty fast enough for 99% of users. Live queries are very cool, but very few people would use them in a mainstream OS, and existing technologies provide most of the end result.

Reply Score: 4

RE: Another comment
by Thom_Holwerda on Tue 6th May 2008 10:12 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

RE: Another comment
by xiaokj on Tue 6th May 2008 15:21 in reply to "Another comment"
xiaokj Member since:
2005-06-30

internal versions can be easily confined to specific programs.

A more practical concern would be the fact that programs can change names. However, it can also be overcome with a specific file, in the program bundles, that state the previous names.

Reply Parent Score: 1