This article is a inspired by some of the ideas which seem be constantly floating around my mind whenever I think about or read about operating systems. Surely, every time-served OS-geek carries a mental list of this sort around with them? This is a summary of all of the features which I would like to see in my dream FOSS based Operating System.
Unfortunately, I don’t have the technical skills to actually go out and make this OS myself and this fact should be pretty obvious to anyone who reads the article. There are some areas of the design which aren’t actually fully explained and probably some fairly important areas that I have forgotten to address. In the same way that most Star Trek nit-picks can be explained away with “It happens for some reason which is obvious to the characters although never actually shown on screen”, I ask you to grant this article the same suspension of disbelief.
Although this article is concerned with a hypothetical, fantasy operating system, its value would be diminished if the fantasy were not forced to exist within some limits. In that spirit, let’s lay down some criteria with which to limit the scope of the fantasy.
Let’s say, for the purposes of devising plausible fantasy that stays within reasonable limits, that I were to win five million Euros on the lottery: No need to work, no need worry about material wants ever again. I’m sitting on the beach, in the sunshine, with a spanking new laptop on my lap, suddenly really popular with members of the opposite sex and the rest of the chaps down at the comic shop but then the realisation hits me that something is missing from my life: All of the money in the world can’t buy me a decent computer.
It’s not the hardware, you understand; the hardware is great; it’s really moved on a lot since the 8 bit BBC Micro that I started with at age 7. Besides, I don’t have THAT much money.
In fact, that can be rule 1: I’m not going to do anything about the hardware. No quantum computers or anything like that.
Over the years, I’ve moved through the BBC’s MOS, RISCOS, Amiga OS, DOS, OS/2, Linux, Windows 3.0>Windows 2000, often moving back and forth between them. There is a saying that ‘every woman has her charms’ and with the exceptions of Margret Thatcher and most super models, it’s one that I would agree with. In the case of a super-turbo-geek such as myself, I’d say that the scope of that statement could be extended to include computers; every computer that I have ever used has had its own special charm. Every system that I have used had some feature that I wished that I could transplant into the others.
So, it seems that my manifesto is beginning to achieve some definition: In the fantasy created, parallel dimension in which I have won five million Euros, I have decided to devote 1 million Euros (I have to keep some for myself, those Blake’s 7 DVDs are expensive) to the formation of The Mike Operating System Foundation. The purpose of TMOSF will be to, within one year, create a completely new operating system. This operating system will be tailored to the needs of Mike. It’s my gift to the world, or rather, my gift to all the Mike-type-persons; there must be at least a few of us.
This can be the second rule: It’s an operating system that reflects the values, needs, preferences and lifestyle of Mike. In other words, it’s not necessarily going to be the worlds greatest server OS.
A million Euros sounds like quite a lot of cash but, being practical, it’s not nearly as much as other commercial operating system developers can throw at a project. However, even this can be turned to our advantage because these limitations can serve to further focus the goals of the project.
Firstly, the most efficient use of of resources can be made by, wherever possible, reusing existing technology; there’s no need to create a kernel from scratch when there already exists a number of suitable, well supported and maintained kernels. By the same token, there is no need to create, for example, a grep tool; it already exists in the form of GNU Grep.
Taking the idea further, given an infinite amount of financial resources, it might be nice to create, from scratch, every application that the users of the OS might want but as we have placed finite limits on financial resources, it just isn’t possible. For these reasons, there is a huge gain in efficiency to be made by making this OS reasonably compatible with other operating systems.
The second way of making the money go as far as possible would be to make the OS itself open source. This means that, if other people like the look of Mike OS, they can contribute to it. I don’t care about personally profiting from the OS in monetary terms – I’ve still got four million Euros, remember. I’m not going to get dragged into an argument about the best licence to use; let’s just say that it’s a licence that means that anyone can contribute to the OS and also that, we can help ourselves to most of the FOSS freely available on other platforms.
Therefore, the Foundation is going start the MikeOS project and get it to a state where it is usable. This will use up the first million Euro and from that point onwards, it will have to survive on its own.
With that, we have specified rule three: Wherever possible, reuse rather than create components from scratch.
And rule four: The OS must be be open source and freely distributable.
Now it is time to define exactly what we want the OS to do. What are Mike’s needs from an OS? Like most geeks I like to do a bit of everything with my computer. I need most of the standard, consumer-grade applications. These applications would include media players, office applications and Internet applications. It almost goes without saying that I want to run these applications within a stable, multitasking GUI environment. Why GUI-centric? Because it’s what Mike likes!
This raises an interesting point about FOSS in general: A lot of people who have only ever used a mainstream OS are unaware that alternative OSes like Linux have access to more free applications than a commercial OS like Windows. If you want to burn CDs, edit text files or play video files for example, you might run into the problem of there being too much choice with Linux. You might try three or four text editors, all of the them of a high quality and completely free, before you settle on the one that suits the way you want to work. This, for me, is part of the attraction of a FOSS OS.
Defining ‘stability’ in absolute terms is not an easy thing to do. In this case, I am specifying what I expect in terms of OS stability; improving universal application stability is beyond the scope of this project. I consider stability to be an area in which most modern operating systems have improved over the older generation. Some people seem to have a different memory of these things than I but I seem to remember that my RISC OS, Amiga OS and OS/2 based machines would crash quite often. Every Amiga-head must shudder at the memory of the pointer going stiff, shortly before the power light begins to flicker.
In contrast, my Windows 2000 and Ubuntu machines are very reliable. In fact, if either of them suddenly reset the machine or froze, my thoughts would probably turn first towards hardware failure. I regard this, ‘one complete crash per year, if that’ expectation of stability to be a realistic one and one that is representative of an area of genuine progress in modern operating systems.
Rule five: Multi-tasking, with modern audio video media facilities. It has to be as stable as reasonably possible – about as stable as other modern operating systems.
These specifications are, again, useful as they help us to narrow the field a little bit. For example, the open sourced version of GEM can’t be used as the basis of the project because it’s not multitasking and it doesn’t have a powerful multimedia subsystem. [for more info about GEM, see this article – [ http://en.wikipedia.org/wiki/Graphical_Environment_Manager ]
Similarly, AROS can’t be used either. AROS is a portable Amiga OS-like with freely available source code but it’s multimedia features are not complete. Another strike against it is that, in order to maintain some backwards compatibility at the source code level, it doesn’t support full memory protection. There isn’t much one can do when the MP3 player application has just corrupted the workspace of the word processor. Even for a high luck character, it seems fairly certain that this design could never consistently maintain the sort of stability that MikeOS specifies. [For more info about AROS, see their homepage – http://www.aros.org/ ]
Other things that Mike likes to do include music production and playing games. Unfortunately, we need to make the OS successful before commercial development houses will start to port over their commercial grade games and media creation utilities. For this reason, I’m willing to keep dual booting for these two things for the time being. Don’t give up hope though, a quick Google for the words ‘Steinberg’ and ‘BEOS’ reveal that, in 1998, some BEOS support for VST plug-ins had been completed and that work had begun on a BeOS port of a variant of Cubase.
This highlights another advantage of both making MikeOS a FOSS project and of basing it upon existing FOSS components – it can’t be killed stone dead by the financial problems of a parent company and neither can it be held back due to legal difficulties. In the same way, there is no way a huge corporation can buy it just simply to kill it.
Single user, Client Orientated, Media OS
Another specification of MikeOS will be that it is basically oriented around the single-user model. By this I don’t mean that MikeOS would have no multi-user features such as multiple log on identities and subsequent per-user /home directories; I think that features such as these are relevant to the single user experience I am attempting to specify. My point is that, advanced multi-user facilities such as being able to run a program from another machine on the Internet or the ability to allow hundreds of other users to simultaneously execute programs on your machine should not get in the way of the single-user client experience.
This emphasis that MikeOS would be designed for a smooth single user experience leads us to rule 6.
Rule 6: One of each of the components that make up the base installation.
This means, one shell, one GUI, one sound subsystem etc. Software installation is discussed further down.
Having specified, in broad terms, what I want from the OS, let’s talk about the actual implementation. We’ll start at the lowest levels: The boot manager and the kernel. To these questions I say – GRUB plus the Linux kernel. As with all of MikeOS, exact method by which these things are going to be achieved is a more difficult question to answer. But not a question that I intend to answer, this is what I shall pay my team of technicians for!
Besides, this is my fantasy; how would you l like it if I popped up in the middle of one of your fantasies with a “How would she even know where you lived?” or “Isn’t that illegal in EU?” or a quick, fantasy-ruining “Where would one even get that sort of edge connector in the middle of the of night and wouldn’t the cooking oil cause it to short out?” to bring you crashing back down to reality?
I specify Linux rather than the BSD kernel simply because I presume that the Linux kernel has more native hardware support. As it’s a consumer oriented OS, I want to make MikeOS compatible with as much hardware as possible. I’m not so naive as to believe that a kernel-level support for the USB chipset will, on its own, make my digital camera work; however, having kernel-level support for the USB chipset isn’t going to increase the amount of work needed to make the digital camera work.
As with all areas of the MikeOS design stage, there exists the possibility that my team of advisers might point out clever reasons as to why we should go with BSD or MACH or even something else. If their arguments seemed strong enough, I might allow it. Mike is kind dictator, who listens to his subjects.
It should be obvious by now that a lot of MikeOS would be built around Linux/GNU. This is in keeping with the design philosophy specified in rule 3 – “Wherever possible, reuse rather than create components from scratch“.
At this point, some readers might be asking themselves how MikeOS differs from Linux. So far, Linux would seem fulfil all of the specified criteria. This is where the Linux bashing begins. Look away now if you have a little model of Linus on your bedside table.
File system/File Layout
Firstly, the file system would not be case sensitive from a user perspective. That is, the file system should be able differentiate case but differences in case should not be apparent to the user when he specifies a file. I realise that this will annoy some of you who have, in the past, loaded up ‘mybirthday.mpeg’ on an occasion on which they had meant to load up a file called ‘MyBirthday.mpeg’ from the same folder.
The user should be able to specify case when naming a file – I presume that this is how Windows works. As it stands, when using Linux, I simply avoid using capitalisation when naming files and directories as, at a later date, I might fail to remember the exact combination of upper and lower case I had used. I can’t think of any advantage of case sensitivity in a consumer OS.
Secondly, the directory layout would not be based around Unix/Linux conventions. For example, why not store the fonts in ‘/fonts’? Again, I know that some Linux people find “either /usr/opt/etc/X11/fonts or /etc/X11/usr/fonts depending on the phase of the moon” a bit easier to remember than ‘/fonts’ but I am willing to risk confusing a few Linux die-hards on this issue – MikeOS might not be the OS for them anyway.
AmigaOS has a directory layout which I feel contains some sensible ideas. In AmigaOS, system files are located in sensibly named directories which are located in the root directory of the boot drive. The fonts are in /fonts, the shared library files are in /libs, the device drivers are in ‘/devs’ and so on. MikeOS could take this approach but at the same time improve and update it
Actually, most of the system directories can be placed in other locations on AmigaOS. And this leads me to another useful feature of that OS. Using the ‘assign’ command, you can create an association between a variable name suffixed with a colon and real directory. For example, upon issuing the command “assign fonts: /sys/fonts/”. You can subsequently copy ‘MyFont.font’ to your fonts directory with the command “copy MyFont.font fonts:”. It doesn’t matter where your font directory really is. When the OS looks for the font it needs, it looks in the ‘fonts:’ directory. This is another useful feature which we could implement if my tech advisers deem it practical. Again, this feature is only practical if conventional Unix and Linux file arrangement conventions are abandoned. You can’t specify a meaningful assignment for ‘libs:’ if your library files are scattered over 120 directories.
I don’t like the idea of having all of my system files in the root directory so we could move them into a parent directory called /sys. So, the fonts would be located in /sys/fonts. Even having some subdirectories within these system directories seems not unreasonable when compared to the Human Rights violating torture which passes for some Linux file location specifications. Having the shared libs relating to networking located in ‘libs:/networking/’ doesn’t strike me as at all unreasonable.
Personally, I consider the idea of a completely hierarchical file system to be a superiority of the Unix file system. MikeOS can place actual drives beyond the system drive in ‘/drives’. There would be no directory higher than ‘/’ and no file system objects can exist outside of the root file system, only within it.
The best elements of the Linux/Unix file system conventions can be retained. As you might have surmised by now, MikeOS would probably be using Linux file system code, there would be no point in ‘switching off’ useful facilities such as hard and soft-links.
Here’s another area in which I would like to break with Unix conventions. MikeOS would use RISC OS/MacOS X style application folders. I like to know what is on my system and where it is. Installing a Linux application generally involves scattering the files over 20 or so directories. This approach might seem acceptable when the package manager works flawlessly but unfortunately, no package manger ever does. What about all of the smaller utilities which don’t update the package database following a “make install”? I am writing this article in Lyx 1.4.2 (self compiled to get the latest version) yet according to the package manager, I only have version 1.3.6 installed.
Once they have been installed/compiled, Linux applications sometimes leave behind no clue as to where they went! At this moment, I can’t remember if the Amiga Emulator is even installed; the only way to find out would be to open up a CLI and type ‘uae’ (or ‘UAE’ or is it ‘e-uae’ for this version?). I wonder what other things are lurking on my system, once installed but now forgotten?
Basically, as MikeOS would be a consumer orientated OS, programmers would create the packages for users to install. The applications can be installed under ‘/applications’ other, not Unix-based OSes seem to be able to support an analog of ‘/applications/firefox/’ for the Firefox install directory (with shared libs going into a shared libs directory).
We can put command line tools into ‘/bin’. The proof that this is feasible is that I was able to install lots of the GNU tools such as ‘grep’ and ‘ls’ onto my OS/2 box without a maze of historically-inspired directories. If, in a typical Linux application package, a significant proportion of the files in an application directory are shared resources, which need to be used by other programs, why are they in the application package?
Perhaps the same approach could be taken towards drivers and services? If it was feasible, could I drop a service that I wanted started at boot time into ‘/sys/services/’? Mac OS 7.x had an ‘extensions’ system that worked a bit like this. I don’t mind resetting to add major system-level components of that sort; MikeOS isn’t designed to run a phone company database server which must be kept running 24/7. Drag the files across, configure what needs configuring and then go to make another cup of tea while the system reboots.
Being heavily based on Linux, MikeOS would make every effort to retain compatibility with standards such as Posix. This is because it would allow make the maximum reuse of standard tools. All of the GNU tools, for example would be usable for ‘free’, once we had an OS that could boot to a command line and that would be able to support a compiler/build environment. The GNU tools include all of the standard tools that one would expect of CLI such as ls (dir), grep, cp (copy), etc.[A good summary, of the GNU Core Utilities exists on the wikipedia page:
The CLI itself, would be Bash. In keeping with the MikeOS philosophy, there is only one choice of shell and it comes standard with the OS installation.
Likewise sound subsystem, peripheral device support and networking would, wherever possible, be provided through the reuse of existing technology.
The GUI would be based around X11 and a standard Window manager.
Ideally, MikeOS would have its own, custom made GUI system; however, the independent re-creation of a GUI system would be too draining on time and money resources. The other problem that the creation of a custom GUI subsystem creates is that it greatly complicates the porting of existing software.
There exist some, mostly experimental projects which attempt to create a replacement of X-Windows for Unix-like operating systems. However what none of them can offer is a the guarantee of continued maintenance and improvement that X11 benefits from. This way, every time X gets an improvement, MikeOS gets that improvement.
In keeping with the slick, custom nature of the OS it would use XFCE as its window manager. XFCE offers a good balance between looks, speed and features.
Some people might conjecture at this point that this system would face huge compatibility problems when porting standard applications. However, it’s worth pointing out that the X11 server running on OS/2 has been able to run applications such as The Gimp and the Enlightenment window manager for years, even though it is not very Unix-like in terms of its system file layout.
On the other hand, I doubt that MikeOS would offer “./configure – make – make install” compatibility, right out of the box. As stated above, programmers would port the applications and users would install the packages.
The Base Install
This is another key feature of the OS. The base install is just that – a base system. It doesn’t include three word processors as some Linux installs do. Basic tools such as the text editor and perhaps the web browser would be allowable. The target user of MikeOS is a geek who might happen not to be a Unix God; he or she knows what an application is and has experience of installing software on other operating systems. When I make a fresh installation of an operating system, after establishing the network connection, my first move is to gather together all of the tools and applications I want. In the case of a fresh Linux install, I’m just as likely to start by uninstalling some of the junk which was installed by default. In the case of my current Ubuntu setup, there must be a significant number of icons in the application selector which I have never even clicked on.
This highlights an area of difference between the philosophy of MikeOS and that of an OS such as Ubuntu Linux. The people behind Ubuntu have tried to standardise the entire OS experience, with a standard choice of WM, email program, web browser etc. You can add your own choices of application but it is clear that they expect most of their users to stick with Evolution as their Email Client.
The emphasis of MikeOS would be on standardising the Base Operating System. The Base Install would be free of applications. The difference is that the Base Install could be considered more restrictive than a typical Linux install such as Ubuntu. There wouldn’t be any support for moving over to KDE as your desktop and If you simply can’t do your work with Bash as your CLI shell, Linux might be a better OS for you. However, the OS would be less prescriptive in terms of the apps that you run.
So, there you have it – Mike’s Dream OS. It’s slick, fast and oriented around the sort of things that I like to do (like Helena Bonham Carter). I suspect there are other people who aren’t entirely happy with the way that Linux works. This is a class of user – the fiddler-geek – who understands tech, loves the world of FOSS but just isn’t prepared to do what it takes to become a Linux God.
About The Author:
Michael Reed is a super computer geek of the highest order. Come and find out more about his never to be finished writing and music projects on his website.
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.