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 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
Thom_Holwerda
Member since:
2005-06-29

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

JonathanBThompson Member since:
2006-05-26

Having had a personal conversation with Thom (more than a few times) and also having had thoughts about this sort of thing, I'm convinced that part of the problem with the article is Thom has unintentionally assumed people fully understand how BeOS/Haiku attributes work, and has left some things unconnected between what he wrote in this article and in his mind, compared to what's going through the mind of the readers.

When used correctly, and with a copy utility that's attribute-aware, the attributes of BeOS/Haiku make it feasible and practical to not get your panties all in a twist as to the exact human-readable directory structure, because when used correctly, you can think of a combination of attributes as an explicitly set directory path that can be set in any particular order. Indeed, attributes are stored in separate indexes which are a form of filesystem directory to start with, that you don't typically see, at least... not without the native index listing tools.

Where am I going with this? Well, think of it like this: each added attribute makes it more readily found for any particular file attached to an application and/or user, and they aren't mutually exclusive. Here is an example of how things could be tied between applications and users:

1. All applications have a human-friendly name: for all applications and their settings files, add the attribute to the files called "ApplicationName" and fill it accordingly.

2. All applications *should* have a version: for all applications and their settings files, add the attribute "ApplicationVersion" and fill it accordingly.

3. All applications have users, even if it is only the System: for all applications and their settings files, add the attribute "User" and fill it accordingly.

4. Someone above mentioned different hosts: for grins, we do exactly the same thing! Ditto for filling that accordingly.

5. Sometimes you want to experiment with different settings: explicitly have a separate date attribute for this purpose, and by default, use the latest dated files: this provides for versioning of settings at will. Ditto for filling that accordingly.

6. For external library dependencies, we do something similar: the library has its "ApplicationName" filled with itself, and lists all applications with their versions as their "users" and we thus get a nice symmetrical solution for handling all that the same way. As soon as there are no users of that particular library, it's safe to blow it away. If you want to blow it away, by running the query, you can tell exactly which applications/libs also depend on it, and which users depend on those, and deal with it accordingly.

By doing a query along the lines of:

finding application name A
With latest version
With user name B
With Host name C
With latest version of settings D
With Libs defined by attributes E

You can explicitly choose to copy or execute any version of any application on the system, assuming you have permissions. Because permissions also exist on the attributes itself, you can hide details from the user where they don't have the rights, and inform those running a query, "One or more dependencies exist for this" that they can't change. The nice thing is because how attributes work, they effectively provide a symbolic link for each time you add one, to their respective information, but it's location-independent: as long as the attribute indexes are built on each volume, the location of the file that has all these attributes (and it'd have to match for each one: because of all the differences in attributes, if you have two different users with otherwise identical attributes, they get two separate files) can be anywhere on the filesystem, so Thom can have his organizational method, and you can have yours, if you so desire: perhaps Thom hasn't convinced you of the wisdom of having a Settings directory outside your home directory, so you have a Settings directory as a subdirectory of your home directory. Regardless of which one you do, you *still* need to have an attribute-aware copy/backup program, and it still requires the filesystem properly index and work with attributes.

An added note: for those libs which are badly abused for names where the names stay the same, but different actual versions end up getting put over them, each application should have a set of "Uses" libs files for each one in its directory that lists the MD5 checksum for each one, so the application (or the application loader) can detect that there's been a change, and at least warn the user of that.

While all these attributes do indeed provide a heck of a lot of power to make things more manageable without an explicit package manager, here are the costs:

1. The user must always have a rather intelligent copy facility that's aware of this information and how it is used.

2. Application developers need to use this internally: this is clearly not POSIX-compliant (for the current state of POSIX) and thus ported applications aren't going to have this if they're simply recompiles.

3. This requires fully indexed attribute storing filesystems: this isn't the problem for the attributes, as Windows NT-based NTFS has attributes, though I don't recall whether they've got their own indexes outside the standard file metadata.

4. Working with applications and files with all these attributes has a time overhead for all the disk seeks: once we move away from rotating media, this likely will be a non-issue, but it exists for now for most non-Flash-based filesystems.

5. I'll be surprised if I didn't forget something...

Reply Parent Score: 2