Linked by J. Scott Edwards on Fri 17th Dec 2004 18:51 UTC
OSNews, Generic OSes Every hard-core OS aficionado has done it: Laid out a grand scheme for creating the perfect OS. Taking all the best features and attributes from the OSes we love, and making sure to assiduously avoid the pitfalls of the OSes we don't. Maybe our goals were modest, and we just wanted a slightly tweaked version of an existing OS. But sometimes we're feeling ambitious, and we have large, creative ideas for revolutionizing computing. Long-time OSNews reader and contributor J. Scott Edwards just couldn't help himself, and he has set about to not only plan, but to try to build his dream OS.
Permalink for comment
To read all comments associated with this story, please click here.
Comments
by Another matthew on Sat 18th Dec 2004 00:33 UTC

Hmmm... ok, I've read the story, here's how I think about this kind of stuff.

In the olden days of computers there was no kernel, programmers spoke directly to hardware, but as computers got faster and the abstraction was proved useful we added another layer with the kernel api.

Then ontop of kernels came other layers like programming libraries, a GUI layer, a network layer, and this provided abstraction.

Some abstractions have come along but they weren't deemed necessary at the time, so the layer failed. This proved that abstraction isn't always good, either because the programmers/managers didn't understand the value, because it was complexity, or because of bad code, etc.

An operating system is an ever changing thing. It's not just the kernel layer, the registry, the gui, browser... recently it's also been the VM layer, of Java and .Net (and, I guess, Parrot).

These doesn't sound like revolutionary ideas to anyone I hope. I didn't find this story particularly revolutionary either but I think that's a good thing. Good technology tends to be evolution, not revolution.

So with the current stack of operating systems layers it actually sounds like what you're wanting here is feasible, as opposed to an operating system dream.

With a VM layer in the operating system you can serialize objects to disk, and you've got a working time-tested
oo model in Java and .Net (maybe IKVM is the bridge). Also both languages can do (as I understand it) aspect oriented programming, functional programming, etc.

So I went through and picked out a few ideas to see whether they were plausible at the vm layer, or possibly above as a library.

Data storage
Serializing objects is supported in .Net/Java. Can be done now.

Where's it stored?
The unix home directory still seems good, and depending on the setup can be hosted remotely on Subversion which provides versioning. Better gui integration is needed, but Subversion does it well for me.

Maybe it needs more pervasive use of OpenLDAP to provide location independence, as the NZ Police Force does.

Indexing... there's a lot of software for this. We just need it better integrated into the gui. It's not much matching strings in files, we need structured responses from email data, chat logs, everything.

Security
Sure, programmers could say that the kernel must understand OO in order to securely implement the OO security model that you propose, however lots of applications implement security from databases and code, not at the kernel level. If it's done correctly as it done every day then it could be done at any level.

SELinux doesn't get to the object layer, I think. But then I don't think it should be done there, it sounds more like a VM level security like sandboxing.

Network connections being encrypted, I completely agree. Most people beyond dialup can support it.

Ram Cache of OO
I think generally this is a good idea -- in that you're considering ram as a version that's derived from disk. I haven't heard of any performance problems with this yet but I'd like to hear some benchmarks.

Deeper down
I think this is a bad idea. I don't see a benefit from combing the layers here (or maybe you haven't articulated what benefits this would give). I don't think that these layers should be blended. I don't think an OO kernel would be practical, because I trust Linus's opinion that they do OO type stuff where they want but often it's in the way at the layer.
I think it should be done at the VM layer.

Code syntax / design by contract
I don't think code syntax is something that should be expressed in OO.

Design by contract is a good idea, but I think it's a social thing that shouldn't be forced.

Object editor
I think that beyond mime-types we've got more complex objects coming out that we need editors for. I mean, an object store may be as simple as a registry/gconf, but with an array of vorbis audio bytearrays do you have an "object editor" or do you just pass them to Audacity? I think, obviously, you'd pass them to audacity -- because editing them isn't something easy to write. But we do need a way of editing, say, serialized Vorbis Audio files and saving them back into the serialized version. So it's more a framework that handles this, I think.

The framework that handles serializing, updating, loading into ram, would be interesting to see. I think the caching in ram is already done by many operating systems though, if a file has been touched recently -- right?

Endian
VM handles this.

Interfaces
As text is -by its nature- two-dimensional, I think most of the time will be spent looking at a 2d figure on screen. That 2d figure should be able to be spun around, maybe with some badass lens flare Gimp effects -- infact the GUI should be 3d to support the scaling, rotation, transparency, of windows. But I just don't think it'll help users for most current desktop applications because they're 2d, and I've never heard or seen a mockup of anything that looked like a 3D interface that people would use (but I'm willing to be proved wrong).

The Looking Glass proejct is the same old 2d windows spining around thing... that's good tech, and I'd want that at the core of the GUI and done with OpenGL and stuff like that

In conclusion...
They don't sound like big dreams, and I think you'll get them all in ten years or so.