Mac users are always quick to point out the benefits of their self-contained applications; one package to download, no installation procedures, easy to remove. While this seems ideal, there are many problems with the actual Mac OS X implementation of this idea. Applications in Mac OS X are generally not easy to remove at all, because they leave a trail of files around outside of
/Applications that normal users rarely encounter. Over the course of time, this can amount to quite the mess. In addition, Mac OS X provides no way of updating applications in a central way, resulting in each application in OS X having its own updater application; hardly the user-friendly and consistent image Apple tries to adhere to.
The Windows world is not much better off - in fact, it is probably worse. Not only does it have to deal with the same problems as OS X, it also has too deal with dreadful installers. Some of them are such usability disasters they make me want to curl up in foetal position and cry. And then, when I'm done crying, I can start all over again because the uninstallation procedure is just as dreadful.
This leaves us with the Linux world. They have the centralised, easy updating application - the update application in for instance Ubuntu is an excellent example of proper balance between providing enough technical information for experts, but still hiding all that fluff from normal users. However, Linux suffers from other problems. Dependency hell, while not nearly as huge a problem as it used to be, still exists to this day. Downloading a package outside of the repositories is a risky business, but it really shouldn't be. You are completely dependent on your distributor updating his repositories and keeping them clean - nothing is as annoying as knowing there is a new version of Super Awesome Garden Designer Ultimate Edition, only to realise all the distributions except yours already packaged it.
Basically, the proposal you're about to read will incorporate bits and pieces from all over the operating system world, but will also include some new ideas of my own. The goal of my proposal is to make the installation, updating, and uninstallation of applications as easy as possible, while at the same time providing features advanced users and developers might appreciate.
I started working on this proposal ages ago, and as I went along, I realised I needed to alter a lot of things about the operating system itself (most notably, the filesystem layout) before I could continue working on the proposal itself. Consequently, I have created a new filesystem layout, and most likely a new filesystem - as I am not sure to what extent existing filesystems can accommodate this plan. Consequently, this article starts out with detailing the privilege model required, followed by an explanation and breakdown of the filesystem layout I devised. It will then move on to the importance and benefits of using BFS-like attributes and queries for updating and maintaining applications, ending with a conclusion (I bet you didn't see that coming).
It might seem a little odd to start an article on a utopian method of managing applications with a section on privileges - and you're right, it is. The reason I'm starting with it anyway is because in my opinion, the privileges a user has is vital in the process of managing applications - or programs, as I will call them from now on (don't worry, this arbitrary decision will become clear). Don't pay an awful lot of attention to the names of the directories yet, I will explain those later on.
By default, a user has either User rights, or System rights. When in normal, day-to-day operation, the user and his programs/processes utilise User rights. This means the user and his programs can only write to their home directory (
/Users/User 1) and their settings directory (
/Settings/User 1). Write access to all other parts of the system is restricted - of course programs and processes may read contents in the restricted directories, but they may not write there. Consequently, installing and uninstalling applications requires the System password. User 1 may not read or write to files in other users' home and settings directories.
This is similar to other operating systems, and has the usual and understood benefits: processes and programs launched by a user can only damage his or her own files, and cannot ruin the entire system or other users' files.
Which brings us to System rights. Users can elevate their rights either on a need, or a perceived-need basis, to System rights, which gives them the ability to change system settings or access content in otherwise restricted directories. With 'on a need basis', I mean that programs, processes, or actions initiated in User rights mode, may require System rights at some point (changing a systemwide setting, writing a file to a restricted directory, and so on). With 'on a perceived-need basis', I mean that the user can switch to System rights without there being a specific need; this may come in handy when setting up the machine in question, when doing heavy system modifications, or simply when an experienced user wants to know more about the system. This is one of the complaints behind UAC: you can't tell it to maintain System rights.
Of course, switching to System rights requires the System password at all times.
The reason I settled on the naming convention of User and System rights (instead of things like root or administrator) is because I find them clearer to the user. You either have 'User-wide' access (Home and Settings directories) or 'System-wide' access. I find 'root' to be an inherently meaningless term in computing, and administrator sounds too much like someone who works for the government. And nobody likes government people. In addition, these names happen to fit quite well into the new filesystem layout.
Even though these two permission levels are the default, advanced users are of course free to fine grain permissions, add different permission levels, forbid specific users from elevating permissions, create a System user account that always has access to everything (root, basically), and so on. In addition, advanced users may also sandbox applications at will, by specifically forbidding certain programs or processes from gaining System privileges. This level of control is needed in for instance larger organisations or server environments, but can also prove to be valuable for programmers who want to test drive their latest code in a secure, non-destructive manner.
Of course, this is nothing new, but in my utopian system, this should actually be easy to accomplish. I've been wrestling with the Group Policy editor thing in Server 2003 for a while now, and dear lord, I have absolutely no idea what I'm doing. I'm reviewing a tool that allows me to fine grain the rights of processes and programs, but it's so utterly complicated I'm completely lost. I see the potential - it just needs to be easier to accomplish.
Let's move on to the real deal.