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.