An old OS idea is new again: non-installation

As an OS designer who prefers well-thought-out simplicity over ever-deeper-layers of complexity, I've been annoyed for the last couple decades as I've watched most OS designs pack more and more files into their system and library (including DLL) directories. Eventually, the entire system becomes a mangled wreck of software components that require complex installers, tools, and conventions in order to manage. Take a look at any "modern" operating system as an example, Windows or Linux for instance. What a mess.

This concept of throwing shared libraries into OS global directories has long been thought of as a necessity to allow for greater sharing of common code and data. Back in the days when disks were small and RAM was only a few MB, that approach made a lot of sense. But, those days are long gone and every so many years you've got to re-examine your requirements relative to the advancements in hardware.

Non-installation

Since the late 1990's, I figured if I ever wrote another OS, I'd set it up differently. I never liked the concept of installation of anything (apps, devs, libs), with perhaps the OS kernel itself as the only exception.

While it's useful to perform some kind of unpacking or decompression step as part of app setup (unzip), the idea of scattering application files into all sorts of mysterious places just makes things harder for everyone, developers and users included. And then, there's also the system registry, but don't even get me started on that.

The nice thing about "non-installing" is that your entire app is in one place -- pretty much just a copy of the distribution itself sitting right there. And, wouldn't that be handy in itself, both in terms of backup and also for ease of app removal?

So, you ask, if an app isn't installed, how does the OS know about it, it's icon, file types, boot options, related tools, and other such things? Well, I'm glad you asked. That's the concept of binding, and there's no reason it needs to be done during installation. You could quite easily perform that step during boot by inspecting application header files (preferably written in REBOL) that define those relationships, located in each application directory, of course. I would claim that step would take less boot time than that required these days to sort through the tangled mess of files in the system directories.

In addition, you need a user-specific storage area for prefs and other special data. But, there are several ways to do that, even via user-specific symbolic links. Not a problem.

New or old idea?

Is this really a new concept? No, in fact it's a really old idea. You could setup apps this way on the Amiga back in 1985-86. You'd use an assign (essentially a symbolic link) to access the app's base dir. Pretty simple.

Is it possible on modern OSes? Aren't they just too complex for such a simple approach. Well, it's nice to see someone put together a Linux distro called GoboLinux that does just that. And, they even kept it compatible, so check it out.

Are there others? Quite possibly, and I know you'll post a list in the comment section.

Anyway, I point this out because I really like to see rebellious developers working to make computing systems cleaner and simpler, rather than the usual case of making them insanely complex. Good work, keep it up.

Now, if we can just get rid of the rest of the garbage that clutters up modern OSes, maybe I will find an OS (other than AmigaOS, of course) that I actually like using.

48 Comments

Updated 10-Mar-2024   -   Copyright Carl Sassenrath   -   WWW.REBOL.COM   -   Edit   -   Blogger Source Code