<geek mode alert!>
I have been musing a lot lately, regarding what would be the perfect operating system (IMO), or as close as it could get. Here it is, in a not-so orderly manner, various characteristics, that I would desire, in my “perfect” operating system.
Kernel
- The kernel would be a microkernel, with everything from the drivers, to applications, running in userspace.
- I liked the idea of the re-incarnation server from Minix. Throw that in as well.
- Every system-critical binary (system files/drivers) will have a stable and a current version (known stable version and latest from repository), and re-incarnation server will automatically bring up the stable if the current crashes at any point.
- Obviously, it would be a 64-bit kernel, with software emulation of 128-bit data as well (not even sure if that makes sense here).
- The scheduler would automagically schedule tasks across CPUs as available. This might necessitate a different programming paradigm than one with a single entry point at main() (be it C/C++/Java.. etc) i.e. the user doesn’t explicitly specify threads or mandate scheduling stuff. He specifies tasks and transcations. Guess this deserves a post of its own.
- A display of VGA@16-bit would be assumed to be available by default. There is no reason for a “text mode” boot with the DM switching it to a “graphics” mode later. The kernel would boot up and put the display into a VGA@16-bit mode with a graphical boot progress, with the DM switching over to a different resolution and display as and when he gets loaded. Possibly, the DM can enable the “proper” video driver on-the-fly before switching resolutions.
VM
- I personally favour Ruby over Python, but I accept that both are equally capable (with Python being more matured in comparison). That said, I still am gonna pick Ruby as the OS’s “native language”. For/against arguments for this decision are not in the scope of this discussion.
- The kernel would launch a VM, a Ruby VM, who would take care of the remaining “booting”.
- Possibly, derive inspirations from the Dalvik VM. Register-based. Opcode loading. Hmmm.. need to read up some stuff here.
- (Going against my initial impulses) application code would reside in their byte-code compiled forms, instead of .rb text files.
- Provide “compilers” for various languages which convert them to said bytecode. Python, Perl, Smalltalk, Java, Lisp etc. should be relatively easy. C, C++, Objective-C would be tougher, but possible (or so I believe).
Graphics sub-system
- A kick-ass software renderer. With the advent of multi-core CPUs, I think we could have a kick-ass software renderer. Will provide OpenGL as a wrapper over its “native” interface 😛
Window Manager
- <many many thoughts upcoming here.. watch this space..>
System API
- Non-time critical “system” API would be exposed via IPC, possibly D-bus. E.g. audio, telephony, location, etc.
- Time-critical “system” API would be exposed via library calls onto the VM. E.g. IPC mechanisms, filesystem access, graphics (??), timers, etc.
Applications
- Applications are sandboxed. Period. You can push messages to other applications via IPC but no direct access to another applications resources are allowed. Also to be taken, caged filesystem areas for each application, as well as a global repository (more on filesystems later).
- Central software repository. Catalogue/store application. Screenshots/reviews/ratings etc.
- Delivered as opcode-binaries. Source available for any OSS applications. Closed-source also possible.
- Capabilities. As in, security mechanism. There will be various capabilities and by default, an application will have only the bare-minimum (or logical minimum). Any action to be taken which needs greater capabilities, will throw a prompt for user-permission to continue (a la UAC). The user can configure an application to be “allowed” to do stuff (see Suite settings in Application Manager.. S60 5th Edition.. for Java apps) without prompting.
This post will be constantly updated. Stay tuned.