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.
Design Brief
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. Stability 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. Implementation 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. Software Installation 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. Standard Tools 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.
http://en.wikipedia.org/wiki/Coreutils ]
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
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.
Conclusion
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.
And it’s called Gentoo
http://www.gentoo.org/
Your comment is out of place, Gentoo is no different from any other Linux distribution or even very far off of one of the BSDs.
Besides, if anything, portage is the opposite of what the article says Mike wants. Mike wants an apt-get or a pkg_add, not an emerge.
To me it sounds more like GoboLinux or perhaps even more the dead LinuxSTEP (especially file system layout and appfolders).
yep, gobolinux was one of the first things that came to mind when reading all these pages.
a very interesting rethink of the basics of a distro, without breaking much.
“…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’…”
I recommend the author to read a few Plan9 papers, especially this one:
http://plan9.bell-labs.com/sys/doc/names.html
Also the author should look more into OS X. It already has a lot of these features, especially the whole fonts bit. Fonts are stored in /Library/Fonts for all users, or ~/Library/Fonts for yourself. And it has an X server. And it has a decent GUI, but not nearly as efficient as xfce.
I actually don’t get what’s so great about XFCE. Everthing else about the article I understand, but XFCE… I guess I just don’t get it. Personally I find its interface far too limiting in terms of customizability compared to the likes of KDE or Gnome, and not particularly visually attractive either. (I admit that KDE can seem a bit flashy and have too many options sometimes, but if you put in the effort it can be customized to perfection). Anyway, the last version of XFCE I tried was over a year ago, when everyone was suddenly espousing the greatness of XFCE as the best DE alternative…. and within a few minutes of using it I got annoyed because it seemed near impossible to add all the icons I wanted, in whatever order I wanted, to the bar without jumping through hoops, so I gave up on it. What makes XFCE (current version or just in general) so special? Or is it just another case of certain people liking minimalism, the same thing which has always kept customizers like me steering clear of the likes of Fluxbox?
Edited 2006-10-12 18:57
I would suggest just trying Xfce 4.4 when it comes out (shouldn’t be too long). The panel app has been completely rewritten, so you may find it more customizable. Thunar with desktop icons also makes a nice addition (my favorite file manager, much better than xffm IMO).
Thunar with desktop icons also makes a nice addition (my favorite file manager, much better than xffm IMO).
I suspect people who like Xfce (me) would still be happy with twm if it looked better. I could probably count the number of times I’ve used the gnome file manager here at work on one hand, and hate icons on the desktop (they just get hidden behind windows). Xfce (to me) is just something to manage windows. All the my work is done in a terminal and Firefox, with a dabble in VMware Server Console once in awhile.
I suppose if I were using a machine to manage my multimedia extravaganza at home, I might have different preferences. Fedora 4-5 and Ubuntu 5.10-6.06 seem to hate the network (Intel 82257) and USB on my home system (MSI K7 board), so I use FreeBSD and XP.
I hate having things on the backdrop as well.
I might have a go at putting more system monitors there at some point though. Sometimes, I’m watching a film and it would be nice to look over at the computer and see the time, current downloads, IM icons etc.
I find the idea of getting to backdrop to click an icon rather counter-intuitive.
Mike
Xfdesktop allows the option of desktop icons, minimized window icons, or none. As far as I know, the desktop icons are enabled by default. If you prefer no icons, just choose that option in the desktop preferences.
Thanks for the tip; I just might.
Thanks I’ll take a look at at the OS9 docs.
Whenever I’ve looked at OS9, it didn’t look like the kind of thing that was very close to being able to run X11 with a standard window manager. Part of the criteria stated in the article is that it must be doable with 1 mil Euros and 1 year.
I knew about the app folders implementation in OSX. The fonts layout sound like it’s well designed too. Unfortunately, OSX is tied to proprietary hardware that I can’t afford. I haven’t used MacOS since 7.x but I wonder if a lot of the good apps are still shareware rather than free? That was one of the other criteria, that the system be based on OSS and give access to loads of FOSS.
How viable running X11 (for day to day use) on top of MacOS would be, I’m not quite sure as I don’t have much experience with a recent MacOS.
Mike
Edited 2006-10-13 01:27
Right, Gentoo with it’s 100’s of USE flags, standard Linux lay-out, ‘etc-update’, 100’s of different applications for the same thing etc… That is not what Mike wanted
(not to bash Gentoo as I’m running it on non-x86 hardware…)
What Mike want sounds more like BeOS or Syllable with a different filesystem lay-out and the Mac OS X way of installing applications…
Heh, I like to of it as the RiscOS/Amiga way of installing applications 😉
From everything I’ve read about it, Gentoo sounds like a great distro but, you’re right, it’s not at all what I had in mind when laying out the specs for the OS.
Mike
Have you checked out BeOS, Syllable or Mac OS X? (Mind you, Syllable is very very pre 1.0 software
)
Nice article, I wonder how much work would really be needed to accomplish what was outlined. My OS dreams are somewhat more far-fetched that this.
I like the idea of the ‘alias’ symlink ‘libs:’. However what I would like more is an aggregate symlink.
Sort of like a folder which concatenates lots of folders. So a /fonts folder could be defined such that `ls /fonts` would spew out the contents of /usr/fonts /usr/share/fonts /usr/X11R6/defoma/pango/fonts/…
New files created would automatically be placed in a predefined folder. Also some sort of file-name pecking order would need to be defined to stop collisions, but it would greatly simplify some things
.
That is a neat idea. I wonder how viable it is or if someone somewhere has created a tool that can do this?
Mike
Maybe you were inspired by GoboLinux, or maybe you don’t know about it. What you say about the filesystem layout has many similarities with what GoboLinux is aiming to achieve.
The idea of Gobo’s filesystem layout is simplicity (also inspired by MacOSX). They have sensibly named directories, and applications are logically installed in a nice and tidy fashion. But in order to retain compatiblity with the ‘legacy’ layout, they have to have tonnes of symlinks pointing from the standard directories (/bin,/usr/bin etc.) which makes a mess.
Then to make it worse, they’ve hacked the kernel to hide those standard directories so you don’t see them. In my opinion this is bad and it still doesn’t remove the need for a good package manager.
Some interesting ideas, but I think I’d stick with Gentoo for now 🙂
Edited 2006-10-12 19:14
I was also thinking about GoboLinux when I read the article. Altho I never used Gobo, it seemed like a nice idea. I didn’t know about those tonnes of symlinks tho.
well its either that or having to go over every programs source with a fine tooth comb, looking for hardcoded paths.
atleast now you can more often then not grab the source of a unknown program, throw the tar-ball at compile (the gobo tool for managing source based intstalls) and more often then not get a compiled program (gobo will even pull down either precompiles or source of known libs that are not allready installed) parked inside the correct /programs/”programname”/”version”/ directory.
my next linux install will be a gobo install
Edited 2006-10-12 20:47
I was more thinking of a linuxSTEP (linux with GNUstep with a FHS following OPENSTEP specifications).
It’s so much alike my thoughts that it’s scary. Compatiblity with normal file system layout could be done through a compatibility package installing the necessary symlinks.
“But in order to retain compatiblity with the ‘legacy’ layout, they have to have tonnes of symlinks pointing from the standard directories (/bin,/usr/bin etc.) which makes a mess.”
That’s because there’s a lot of application that isn’t well behaved and has hard coded paths in the source. If there was an ideal world, those symlinks wouldn’t be needed.
“Then to make it worse, they’ve hacked the kernel to hide those standard directories so you don’t see them. In my opinion this is bad and it still doesn’t remove the need for a good package manager.”
First of all, this kernel hack is completly optional. One does not have to use it to be able to use GoboLinux, one can manage with any configuration of the kernel.
Second, even if the directories (or symlinks) are hidden, they are still usefull. One could still do ‘cd /etc’ to get to the directory with the settings, just that ‘etc’ doesn’t show when you do ‘ls /’
Library Computer Access and Retrieval System
Actually, I think that an LCARS system could be pretty good for some uses and some people. For most people overlapping windows are a power user feature that just causes confusion. Most PDA OSes, for example use a layout of that type.
Another technique that could be adapted to such a layout would be the abandoned IBM/Apple OpenDoc system. With that (if I understood it fully), if you wanted to edit some rich text on a webpage, the ‘word processor’ would provide the editing tools within your web browser. Similarly, it would work in much the same way if you need to edit an SVG in the middle of a document.
Mike
Edited 2006-10-13 01:48
windows 1.0, and that os that first showed of the WMI interface both where unable to have overlapping windows.
there are some WM’s for X available that do non-overlapping. ION i think is the best known one.
the original idea was, as you said, to avoid confusion when one window partialy or fully overlapped another.
hell, i have recently found me playing with the idea of having a PDA like interface to the computer. just look at these widgets and all that turns the desktop area into a kind of quick check for trivial data.
and that opendoc stuff reminds me of some other toughts i have had, about rather then installing software, you install functions. so that rather then installing photoshop and having to remember the way photoshop works each time you use it you just selects to edit a photo and presto. ie, 100% document/file/object-centric working, compared to todays application-centric working.
Once they have been installed/compiled, Linux applications sometimes leave behind no clue as to where they went!
Look into the –prefix option. If you want to know which files belong to a given program, install it to some temporary location such as ~/tmp_install.
My personal convention is to only ever install system wide programs with the package manager. (apt-get in my case.) If I need to compile and install something manually, I install it within my home directory, and each program within its own directory. For me, this is ~/local/programs
So whenever I run ./configure, I always use ./configure –prefix /home/david/local/programs/NameOfProgram
Once it’s installed, I’ll setup any necessary symlinks to my ~/local/usr/bin directory which is in my path.
That keeps compiled programs all contained in their own area. And since they are all installed to a single directory, if I want to get rid of the program, I just rm -rf ~/local/programs/NameOfProgram and it’s gone. (If I created a symlink in ~/local/usr/bin, I’ll delete that too.)
“Look into the –prefix option. If you want to know which files belong to a given program, install it to some temporary location such as ~/tmp_install.”
You should take a look on the packagin system used by FreeBSD. Installed programs (packages) are listed in the package database /var/db/pkg; every package has a directory with package name and version. It contains files thatt tell you about package purpose and description (+COMMENT, +DESCRIPTION), installed files (+CONTENTS).
This is a good way to find out which package a file belongs to.
You should take a look on the packagin system used by FreeBSD.
What does the packaging system for FreeBSD have to do with anything mentioned in the article, or anything I wrote in my comment?
“What does the packaging system for FreeBSD have to do with anything mentioned in the article, or anything I wrote in my comment?”
This is the reference text:
By blixel (1.88) on 2006-10-12 20:27:50 CET {
Look into the –prefix option. If you want to know which files belong to a given program, install it to some temporary location such as ~/tmp_install.
}
I just mentioned this packaging system because it is modified by a “make install” command. So, if you want to know wich files belong to a given program, you would only have to ask the package database.
I just mentioned this packaging system because it is modified by a “make install” command. So, if you want to know wich files belong to a given program, you would only have to ask the package database.
Right … but in context to the part of the article I was quoting, the original author was talking about doing manual “make installs” … i.e. without the aid of a package management system. So my reply was all about managing manual installs. (Because the author said “Once they [they being manual program installations using “make install”] have been installed/compiled, Linux applications sometimes leave behind no clue as to where they went!”)
blixel (1.86) on 2006-10-12 22:10:32 CET in reply to “”
Right … but in context to the part of the article I was quoting, the original author was talking about doing manual “make installs” … i.e. without the aid of a package management system. So my reply was all about managing manual installs. (Because the author said “Once they [they being manual program installations using “make install”] have been installed/compiled, Linux applications sometimes leave behind no clue as to where they went!”)
You’re completely right. I mentioned the MUST of a funcional automated packaging system in order to avoid things like this. I think a “my dream” operating system just should contain such a thing.
“Look into the –prefix option. If you want to know which files belong to a given program, install it to some temporary location such as ~/tmp_install. ”
Thanks, I’ll take a look into that. I’d dabbled with –prefix to some extent in order to keep a couple of different builds of Lyx installed at the same time. But I hadn’t though of using it in that way.
Mike
“So whenever I run ./configure, I always use ./configure –prefix /home/david/local/programs/NameOfProgram
Once it’s installed, I’ll setup any necessary symlinks to my ~/local/usr/bin directory which is in my path.”
You should really take a look at GoboLinux then. It does the exact same thing; everything is installed into it’s own directory and then symlinked into the directory in the path. Just that there are tools for it to simplify the process.
One that works and has functionality, Linux based but with the kernel modules more secluded and protected to keep the thing from hanging up.
Plus an interface that is slick (ie – kde) but very stable and apps that to not crash.
Plus, a speedy boot up time.
Personally, I’d take the concept of Squeak http://www.squeak.org and put it on top of the Linux kernel.
It wouldn’t necessarily be based on Smalltalk. Actually, I’d rather have it based off of Slate http://slate.tunes.org. Slate is basically a Smalltalk/Self/Lisp hybrid that is a very interesting language.
I’d also probably skin another syntax like Applescript (or something as natural language as possible) on top of it too.
But the real interesting thing from a user perspective is that it would be “Turtles all the way down”. What that means is that as much of the system (at least everything above the kernel) would be written in a highly, introspective language like Smalltalk or Slate or maybe even Lisp.
What that gives you is basically everything on your desktop is a “live object”. It can be inspected and manipulated. Little applets are completely trivial to make for a non-programmer. You could have a little visual language too. See squeak again.
It might be hard to imagine, but for those of you that have worked in Smalltalk environments, you know what I mean. Of course it would be modern, GPU-accelerated with lots of eye-candy (unlike Squeak).
1) “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.”
Very true. This is never stressed enough. Hardware is improving at a very fast rate, software is lagging behind badly. It is more than anything a kind of “denial”. Microsoft has done nothing to promote XP 64bit, and I wonder how much they are going to in order to promote Vista 64.
The FOSS community isn’t much better either. How often I have read: “64bit? What is the big deal?”. SUSE has been the only exception. Mac OS X is also very progressive from this point of view.
2) “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.”
This point is so obvious that everybody should agree.
I can understand that if your name is Microsoft or Apple you might disagree, but if you are trying to create a tiny hobby OS, trying to keep it closed source shows a total lack of basic common sense.
3)Software installation: well, that is very similar to the OS X way or perhaps the PC-BSD one. It also vaguely reminds me of autopackage. But in any case he has got a very good point.
Mac OS X, but on a range of different hardware, and completely open-source.
Naah.. More like NeXTSTEP before it was ruined
pretty much ;D
I’ll take the shrink-wrapped OSX, but forget about it being open source, or you don’t get OSX.
SO basically…OSX users in general have no idea how OSX works nor do they care so should probably go read something else. The author wouldn’t bother writing this if OSX is what he wanted. What is wrong with you people?
Not everyone wants a Mac. Say it over and over again. Repeat after me: NOT EVERYONE WANTS A MAC.
OSX users in general have no idea how OSX works nor do they care
Lame, old prejudice. We’re not living in 1980 anymore..
And back on topic: MikeOS seems IMHO pretty close to an open source MacOSX clone
The operative word here is “My”.
The user wants the focus, simplicity and design of Mac OS, but the openess of Linux. You can’t have both.
By being open source, everybody has the ability to input, and it’s very difficult to get a comunity to agree on one way of doing things, one GUI, one of each subsystem. Only closed source, or controlled source can do this.
That’s not correct. At least not entirely.
It’s perfectly posssible to combine the focus, simplicity and design of Mac OS with the openness of Linux. GNUstep proves this, and is perhaps closer to the real thing than Mac OS X
Controlled sources are a must here, I agree, but open source does not equal lack of control. It’s perfectly possible to control submissions, and there lack of control is no more likely than with closed source. But that of course makes it likely enough anyway.
There are several GPL’ed and MIT-licensed projects with great control and strict focus. And there are many closed source projects with no control and no focus.
Anyway, it’s possible to get both. And creating such a distribution is reasonably easy. The problem is to maintain it.
“The user wants the focus, simplicity and design of Mac OS, but the openess of Linux. You can’t have both. ”
You could in theory and perhaps in practice too. The 1 million Euros provides the ‘steering’ to shape the layout of the OS.
Mike
ubuntu anyone?
Is this a compendium (a summary with some considerations) or an addendum (a part joined subsequently) to Alternative OS contest?
I asked this, because this Dream OS article deals mainly with the characteristics featured by alternative OSes all grouped toghether to create a new mythical OS…
And by the way, just for the fact I am here…
Can I ask to moderators why the GEOS article won Alternative OS Contest?
Hasn’t GEOS article being published online AFTER the deadline of 14 of July?????
[off-topic]
Can I ask to moderators why the GEOS article won Alternative OS Contest?
Hasn’t GEOS article being published online AFTER the deadline of 14 of July?????
They almost all were published after 14 july IIRC. That doesn’t mean they weren’t sent in before that date.[/off-topic]
A good compromise to all desires of the Author it is MorhpOS OS, except for the fact it is not Open Source…
…But, maybe in the future it could being released OPen Source as it has just happened with its GUI called Ambient.
Not only but MorphOS memory protection capabilities should be improved by finishing developing sandbox of QBOX environment directly related to its microkernel Quark, and not being only stucking with sandbox with Amiga API called ABOX.
So the author could get finally its dream OS ecoming real stuff.
From another point of view he had also considered AROS into its discussions. And sure AROS seems to me close to his desires, bus as being AmigaOS 3.1 Like, then AROS has no memory protection.
Well. But AROS is Open Source OS.
Any person could co-operate the project, join with other programmers in a distributed worldwide effort, and helping adding new features such as Memory Protection to AROS little, joung and promising OS.
So, when AROS will begin to deal with Protected Memory and other features, that actually are still missing, then Mr. Reed could at least make true his dream OS.
Please programmers. Help improving AROS:
http://www.aros.org
Ambient has been open source for a long time.
Does anybody still use programs on their OS?
I would very much love to see a “perfect” OS.
But I still prefer great programs running on it.
In practice, it’s better to just ‘fall in love’ with your OS, in spite of all its shortcomings. That’s the charm of it.
My dream OS would be a lot like Mike’s, although I’ve often wondered if there isn’t a way to get the best of both worlds situation with the RiscOS model and the Linux model, using NTFS’s file system.
First, a hard link is a file with two names. It’s the same exact data on the disk, with two different names/directories.
NTFS, if I recall correctly, has a feature that amounts to semi-hard links. It stores identical files as a single hard-linked file, but unlike a real hard link, it will create a new file if you change one of them. The ones that are unchanged continue to be the same data, the one you changed is now its own data in a different location on the disk.
Could you use such a thing to simultaneously have the ease of RiscOS drag’n’drop installation, but avoid the trouble of duplicated libraries taking up space?
The system I envision would store identical libraries (say, GTK+2.8.9) once and make fake hard links in each of the folders the file’s supposedly in… Now, suppose you upgrade The Gimp to a new version that requires GTK+2.8.10. Now the files in The Gimp’s folder are NOT hard-linked; they’re GTK+2.8.10. All the others point remain pointing to 2.8.9 and remain working just as they used to.
The next difficulty in a RiscOS system is that a bug-fix to a library would have to be applied to EACH program that uses that library. (correct me if I’m wrong)
Suppose you make a special case where each library (or other shared file) on the system is ACTUALLY hard-linked to… uh, /usr. To upgrade all applications from 2.8.9 to 2.8.9a, you would apply the bugfix to that file. Yeah, I suppose you’d end up with the same problems if 2.8.9a broke application X.
Oh, and since one feature of hard (and “hard”) links is that the data isn’t removed from the disk until all the directory entries to it are removed, so you can still remove applications by deleting their folder.
All this work would probably put a serious strain on the filesystem.
Actually, all this could be done with symlinks (but that would involve adding more physical files, and keeping track of how many symlinks point to each file)
My only other ‘big wish’ is that the OS could have a bunch of, say, audio-playing interfaces, so that every player that connects to that audio interface could use all the plugins installed. Let’s say you have an ancient music playing program that calls the audio interface. Add the Ogg Vorbis playing plugin to your system and… Voila, your music player can now play Ogg Vorbis because your system knows how to deal with it now. Yes, this would make audio players more uniform in terms of their playback… but there are other ways to differentiate yourself.
I know several OSes (such as BeOS) have done things like this… Windows does it with video codecs. All I have to do is install an XviD codec and WMP, Winamp and the rest now understand XviD.
Edited 2006-10-12 22:10
This description looks like PC-BSD, don’t you think so?
all i can ever think when people whine on about how appdirs in linux would cure cancer or something i just cant help but think about ROX, sitting there with its full desktop of appdirs and its drag and drop saving and loading classes.
and of course gnustep.
First we get publicity in article and now we get publicity in front of the web page.
I am obliged to close a publicity before I can read something on this site each time I open the website or click on a link to see comment/read an article.
This site has too much publicity (and don’t tell me that you gain no money with it), it is full of crap now. Thanks, I will save my time and not come back again. I hope this site will disappear from the net.
Edited 2006-10-13 05:14
I didn’t find ur ideas worth; you have stressed less on the ideas but talked more about here and there.
these ideas are no-where near to throw away windows; not even any good linux distro these days;
what it will take to do that is completly outstanding OS, which no one has done so far.
but wait for some more time; i’ll be putting it on the stage.
it’s 2006 nex, so why is your computer really big hot and takes an age to actually do anything, you know, things like switch on and er switch off, what do you actually use your computer for? if it’s so fikkin great why does it take so much time and wasted energy to do it? so ask yourself, if it’s 2006 why is my computer a piece of spit… this rant goes on a bit more but you get the jist..
My dream OS would actually be a virtualized Mac OS 9 environment with each application running in its own sandbox, or Mac OS 9 environment and servers so that Apps can communicate with each other and the underlying system. Hopefully with parts re-written in i86 architecture with non-portable code running in seperate powerpc sandbox.
Mike, I hate to say it, but MikeOS isn’t really very ambitious.
You’re basically describing a custom Linux distro, and nothing more. As folks here have pointed out just about everything you desire exists in one form or another. It seems to me that your entire OS project would probably be concerned with picking the components and then making the required edits to sort out the directory structure. I’d expect this could be accomplished for considerably less than 1m Euros, and probably within just 6 months rather than a year.
What you’re describing also seems to me to be fairly close to Haiku – excepting of course being based on the Linux kernel and running X-Windows.
Basically the guy wants an Amiga like OS with a few enhancements from the Unix world! what a shame! some people have no imagination at all.
The following text descibes my own ideal operating system. But before that, I would like to stretch the fact that hardware is far from ideal as the author says. The reason is that each device should be independent of O/S, all devices should have an object-oriented interface and the driver code should be in bytecode format loaded into their flashable roms, thus allowing very easy integration with the host O/S. Instead of that, what we get is a list of I/O ports or memory locations and a specification for some types of devices that is usually not implemented 100% and is fixed in the rom.
Let’s go to the operating system…I want an operating system where:
1) there are no applications/drivers/filesystem whatsoever.
2) all data and code is stored in a relational database.
3) code is stored as functions.
4) data is automatically persisted and indepentent of code.
5) code is stored as bytecode; the kernel translates the bytecode to native code and caches the result, handling security as well.
6) programs are composed by the user with the help of a GUI, by chaining functions together. The GUI is ‘function centric’, i.e. it allows the user to process data using one or more functions. Let’s name these programs ‘tasks’.
7) tasks are full screen, with a small bar in the end of the screen which contains a view of open tasks. Clicking the other tasks brings them on the screen.
8) the system knows the data types of data, so it is possible to do queries across the system.
9) the system is distributed. Computations can run in any available node.
10) the system is reactive; state change can be intercepted and handled accordingly.
All the above is coordinated by the kernel (the only native code in the system).
Basically the guy wants an Amiga like OS with a few enhancements from the Unix world!
And can you really blame him!? 😉
Gold is a new operating system from scratch designed for desktop use and modern computing, you can see it here http://icculus.org/gold/
This operating system has really nice things, for example, see this about his GUI, http://www.jbit.net/~jbit/Golem-Stuff.txt
This is probably what you would want, it simply rocks!
* _NEVER_ steal the keyboard/mouse focus.
(Game devs, try to not steal them outside of gameplay)
* _NEVER_ put a new object/window/etc ontop of where the user is currently working.
(like, don’t put a notification above the text input box currently focused)
* _NEVER_ put keyboards/mice/etc into weird modes without a visual indicator and a clear way out.
If only vista had this implemented….
The File vs Objects concept is really nice too, you can read that on their web site, and they are in #gold @freenode.
I hope that the Linux developers are reading this. This guy’s points are quite obvious if you’ve played around a little with Linux. I don’t understand why is it so hard for the developers to figure them out.
You can’t specify a meaningful assignment for ‘libs:’ if your library files are scattered over 120 directories.
You can have different directories sharing the same assign, so that you don’t have to mix them all in the same place, obviously if you copy something to libs: it will go to the master assign, but for looking it will hunt those 120 directories until it finds the correct library, it doesn’t mean ´per se´that it is meaningful.
You can have a libs: assign at user space avoiding the system completely
PC_BSD. Especially with PBI”s for package installation.