I have a bit of a history for playing with different operating systems, and as I try each one, I have become less forgiving over things which just don't work.
But just recently I was asked, if I was to design my own operating system, what would it be like?
Well, in short, it would be like a prison for the programs, with the user having complete control over their system... even the operating system itself would obey the user... which is quite different to current operating systems, where it seems that applications get equal rights as users, primarily because they run under the users accounts.
We start with a UNIX file system, where the root contains the following folders:
Ignore the first two for now, they will be discussed later.
The "users" folder works just like the "home" folder in UNIX systems or the "users" folder in OSX... where each computer user will have their own folder to save their files in. Example sub-folders for each user include "desktop", "documents" and "preferences"... of which the "preferences" folder is of most importance to this operating systems setup.
As you will find out later, the programs running on this operating system will not have direct permission to write to files in the "users" folder... instead it will be a couple of API's the operating system will provide, so that the programs can get (restricted) access to the users files and folders.
The "system" folder will hold everything relating to the operating system itself, from the init process, to the kernel... one interesting point to note though, the operating system will not provide a GUI... instead it will be more like how X, Gnome and KDE work, whereby they will be programs installed like all other programs... more on this later.
Like on OSX, there needs to be a central control panel which provides several customisation areas. These will be discussed later, however it should be noted that this area is completely controlled by the operating system. Unlike OSX, programs do not really have a preference area in the control panel. Instead the programs must provide their own preferences interface. In the case of programs which are more of a daemon (like Teleport), they should be installed in the "utilities" folder (again, discussed later). Normally they will be running in the background, but when they are launched (i.e. double click on the programs icon), they can provide their own GUI for changing the preferences.
It is the "applications" and "utilities" folders (discussed above) which we are interested in at the moment... as these are where the programs will be stored. Programs which users expect to be launched and be used in a GUI sense, like photo editing programs, are stored in the "applications" folder... whereas programs which tend to run in the background, like Apache, will be store in the "utilities" folder.
Each program will be a folder, very much like how OSX works... but it will use a very strict folder structure, so the operating system knows where to find certain support files.
At the root of the programs folder will be the version information. For example, the full paths at this level could be:
The purpose of this folder layer is to help with software updates... in much the same way as how MySQL currently recommends its own installation.
When the operating system is upgrading a program (more on this later), a new folder will be created using the version number... after the upgrade, the "current" symlink will be updated to point to this new folder. This allows the program to continue running without interruption or missing resource files. Old versions will be deleted by the operating system on the next system or program re-start, as it will know that the older programs version is no longer being used.
In addition to these version folders, the "library" folder provides a consistent location for additional files, like the preferences, which need to be stored outside of the versioning system.
Within each of the (version) folders, the operating system will expect to find the following folders:
The details for each of these folders will be explained later.
The programs will be provided to the system in a zip file (gzip), either from a download, disk, or any other file transfer method.
This file will have a unique extenuation (like ".prog"), so when the user double clicks on it (GUI mode), the operating system will know that the file is a program, and that it should now install it.
The install process is handled entirely by the operating system, so the user can be confident that the program is installed in a standard process, without files littering the system.
The install process is:
From a GUI point of view, the program will start with a simple double click of the icon found within the "applications" or "utilities" folders, or by using the file extension association (more on this later).
The program will run under the programs user, created on install, not under the user who started the program... this it because the main user has too many privileges, that the program should not have... although the users id will be passed to the program so it knows who to work with on a multi-user system.
The operating system must make sure that all of the required services (as defined in the "requires.xml" file) are either installed, or are running... for example "PHP" may require the "MySQL" utility to be running, while the "SSHD" utility may require the "Terminal" application to be installed (for the shell binaries).
When the program is running, it can only write directly to its own program folder.
If the program needs a lock file, then it can quite easily create one under its own "library" folder, the same with any temporary, cache and spool files... there will not be a central area for these, unlike traditional UNIX systems.
If the program needs to create a preference file for the user, such as config files, account details, storage of emails... i.e. any files that are unique to the user, that the user does not need to know about... then the program will ask the operating system to save the file using a special API, that restricts the write action to the /users/me/preferences/ folder... as discussed later, when the program is removed, the user will be promoted if they also want to delete this folder as well - to completely remove all traces of the program.
If the program is going to save a file, like an image, then it can use one of two API calls to the operating system... the only difference between the two is that one creates a single file (used most of the time) and the second will create a folder so multiple files can be created. The API will ask the user to select a location (like the current "save as" dialogues used in most programs today), and the program will also have the opportunity to add its own custom panel area, under the file/folder selection area... this is like some "save as" dialogues in OSX, so that the program can request additional configuration options, like the file type and image compression. Once the user presses the "save" button, the program is given a random key (10 characters long) and the opportunity to create the file/folder in the programs "./library/save/" folder where the name is set to that random key... it then returns control to the operating system when its done, so the operating system can move the file, and change the permissions so that the computer user has control over it.
If a file was opened where its extension is assigned to a program, then that program is provided with an API interface that allows it to save data to that file... again controlled by the operating system.
Briefly mentioned above, the program will have a "./info/permissions.xml" file, which was used during installation.
As the program will be heavily firewalled, this file will allow the program to request certain permissions, such as network ports and communicating with external devices like digital cameras and speakers... it also lists all of the file extensions which are associated with the program (more on file associations later)... and it defines if the application is automatically started as a daemon.
The user can be informed of these permissions, such as during installation, and they can view and even change them at any time though the control panel... with a quick link in the GUI mode, where the user could right click on the installed program, and choose the "permissions" option from the context menu.
For most users, these permissions will be too advanced, so it should be hidden away slightly, with the program getting the permissions it asks for by default. However, each permission setting in the XML file will need to explain why it needs such access (a brief sentence) and if its optional or required... although in reality the "required" message is only visually shown to the user in the control panel, the user can still has the ability to disable all permissions.
As an example, a web browser may ask for outbound port 80 (http) and 443 (https) to be open, but mark port 21 (ftp) as optional.
From a networking point of view, the program will only ask for port numbers, it will be the operating system which converts these to names. In addition, it will need to specify either source or destination, as a web server will want to bind to local port 80, and a web browser will want to talk to remote port 80.
If any of the required permissions was to change though, such as a different port number for the web server, the program can call the operating system, though an API, to re-read the "./info/permissions.xml" file... this may trigger a dialogue for the user to confirm the change.
As this XML file is stored within a (version) folder for the program, it could contain a single node which informs the operating system of an alternative path for the permission file, such as within the "library" folder... this change in location could be triggered if the user asks the program to use a non-standard setup which needs to be preserved over updates.
It should also be noted that an alternative way for programs to communicate is to create a PID file with the group read-only permission set, so that programs like PHP can read the file within the MySQL programs folder... where PHP will have its own preferences file so it knows where to find this PID file.
At all times though, the current permissions can be viewed and edited by the user in the control panel.
In the "./info/permissions.xml" file, the file associations will be defined in two levels. The first being that the program is "capable" of opening that file extension, so for example PhotoShop could say that it can open ".jpg" and ".png" files... and the second level is that it "should" be assigned as the primary program for that file extension, so for PhotoShop it should the primary program for ".psd" files.
The basis for these two levels is that when a file is double clicked (opened), it will use the primary program assigned to its extension, such as using TextMate for ".html" files... but the user could right click and on the "open with" option in the context menu, to choose one of the "capable" programs... like how OSX works.
If a program asks to be the primary program for an extension which has already been associated, then the user is asked if they want to change it.
If a file extension does not have a primary program, when a user double clicks (opens) it, the operating system will give the user a choice of the available programs which can open the file, where the dialogue box will also give the user the choice to set the chosen program as the default, like Windows.
But like all of these configuration options, they are set by default for most people (advanced users may request to be prompted on all changes)... but the user can go into the control panel and either add/edit/remove the file associations for each program... and these associations will be on a per user basis.
In addition to this, a program can be started (if not already running) by the user dragging and dropping a file onto the programs icon (folder), like how OSX works, which will provide another way to get the program to open the file, but without using the file extension association... although it might be the case that program will need to inform the user if it really cannot open the selected file.
In the "./info/permissions.xml" file, mentioned above, there can be a node which allow the application to define itself as an active daemon which needs to be running all the time, in the same way that Windows has services... the XML node will just be a path to the required binary, of which the usual "start" and "stop" parameters will be used.
Any applications which do mark themselves as active daemons are started automatically after install, and each time the computer is restarted. The order of startup is defined by the "requires.xml" and "provides.xml" files in every application. If the application does not receive all the "required" services, then it cannot start until the user makes the relevant changes... the operating system will not start any programs which need to be running without them also being defined as active daemons first. There will also be a log file to show the order of which the programs were started, and why any programs were skipped, which is shown on login if there are any errors.
In addition, a user can define which applications start when they login. This will work in the same way as OSX, whereby a list of programs is created by the operating system, but it will be the user who adds the programs. It will be possible for the "./info/permissions.xml" file to add a node so that during installation, the user is asked (by the operating system) if they want to start the application on login, but when the user is asked, the default will be off.
The control panel will provide two areas, one with a list of daemons, and secondly a list of applications that need to be started for that user. In both lists, programs can be added, removed or temporarily disabled by the user.
Using the "./info/update.xml" file, the operating system will get a list of URLs to look for updates... this could point to a http://, ftp://, smb:// file:// etc address, of which the URL is a change-log XML file... most programs will only provide one URL, however it provides the ability to have mirrored / load distributed upgrade servers.
The URLs can contain a [V] tag, so the currently installed version number can be passed in a query string. This allows the servers response to be tailored to only include relevant chances and information.
This change-log XML file will contain information, such as the version, where to download the latest ".prog" file and other additional information such as important new features or bug fixes. This information will be provided to the user, so they can either request to perform the upgrade or change their upgrade settings.
When the user initially gets informed of the upgrade, the operating system could potentially begin to start downloading the files in the background, while the user is reading the list of changes.
The operating system will also provide an interface in the control panel so the user can change their preferences on how each program is updated... for example they could choose to check for updates "daily", "weekly", "manually" or "never".
During the installation of the update, it will work like the install, in that the ".prog" file would be extracted, the "./info/" files will be read, the relevant version folder for the program will be created, and then populated with the files found within the ".prog" file, and finally the "current" link will be updated... after this, the user will be shown a message that says the program will need to be restarted before the update will take effect, where the user will be given a choice to "restart now" or "ignore"... if the user chooses to "ignore", then the dialogue is dismissed and the user can continue using the program undisturbed... although if the GUI uses a dock like interface, like in OSX, the applications icon could be marked with a small icon to symbolise the update is ready to be used.
You may have noticed at the beginning mention of a couple of folders along with the /info/ folder.
Technically they are not required, however each one does have a special useuse:
This should be trivial for the user, it should just be a matter of dragging the application (in GUI mode) to the bin... like how it works in OSX.
However, the operating system should notice this as a special action, and ask the user if they also want to remove the applications preferences... effectively removing all traces of the application. The preferences will include the file extension association, startup items, software update details, and the preferences folder found in the current users directory... it cannot remove the preferences folder for other users, as we don't know if it contains important information, like calendar events.
Utilities
Applications
Any feedback would be greatly appreciated, I don't include comments due to the admin time required, but if you email me, I will reply and make appropriate updates. Also, if you would like to take a copy of this article, please read the terms this article is released under. This article was originally written Sunday 22nd July 2007.