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 313074
To read all comments associated with this story, please click here.
RE: Comment by Thom_Holwerda
by JonathanBThompson on Tue 6th May 2008 13:06 UTC in reply to "Comment by Thom_Holwerda"
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