Yeah, I might be just re-inventing the wheel here, who knows? But I had this (original? I doubt it) idea a few months ago and I was meant to write about it for some time now. So, my idea is about creating a new operating system that is like none of the current ones. It would be so different, that porting applications from other "traditional" systems wouldn't be possible. But the gains would be much more important of what we would lose by implementing a brand new new system.
Permalink for comment
To read all comments associated with this story, please click here.
So you say...
I believe that many changes will have to be done in the kernel of such an existing OS to have it working the way described in the article. It is possible, but it won't be as "pure" when trying to implement it on top of an existing OS. It will hit limitations that they wouldn't naturally be there, if the whole architecture was thought out and implemented from scratch.
Then when someone broaches the issue that this doesn't really require any sort of kernel support, you again mention...
Read my above comment as to why I would recommend to use a base OS that is made for something like this from Day 1.
I'm still failing to see what part the kernel plays in this at all. Perhaps you'd need an entry in the filesystem for a MIME type, but other than that, I see two implementation avenues:
Whenever you wish to manipulate a resource (I'm guessing this system would support network resources in addition to files) you start a new HWP which looks at the MIME type and decides the best way to "display" the contents.
From here you may either dynamically link with a set of modules which are loaded as LWPs, so everything shares the same memory space, or...
You can start additional HWPs which perform additional functions.
The latter is essentially the Unix philosophy... a bunch of simple applications which perform a single task well, linked together with pipes.
I think you're probably aiming more toward the former. I think implementing this would require some sort of abstract filter graph architecture which can determine how to plug the modules together.
You'd also need lots of talented people designing tons and tons of APIs for all resource types you wish to handle. The OS would have to come with some sort of "base applications" into which the modules could be plugged (for example, if you open a text document, you'd need a base text editor application onto which you could tack your spell checker/various format exporters/etc)
So yes, a cool idea to be sure, but I don't see how this can't be done completely in userspace on top of the multithreaded kernel of your choice.
So you say...
I believe that many changes will have to be done in the kernel of such an existing OS to have it working the way described in the article. It is possible, but it won't be as "pure" when trying to implement it on top of an existing OS. It will hit limitations that they wouldn't naturally be there, if the whole architecture was thought out and implemented from scratch.
Then when someone broaches the issue that this doesn't really require any sort of kernel support, you again mention...
Read my above comment as to why I would recommend to use a base OS that is made for something like this from Day 1.
I'm still failing to see what part the kernel plays in this at all. Perhaps you'd need an entry in the filesystem for a MIME type, but other than that, I see two implementation avenues:
Whenever you wish to manipulate a resource (I'm guessing this system would support network resources in addition to files) you start a new HWP which looks at the MIME type and decides the best way to "display" the contents.
From here you may either dynamically link with a set of modules which are loaded as LWPs, so everything shares the same memory space, or...
You can start additional HWPs which perform additional functions.
The latter is essentially the Unix philosophy... a bunch of simple applications which perform a single task well, linked together with pipes.
I think you're probably aiming more toward the former. I think implementing this would require some sort of abstract filter graph architecture which can determine how to plug the modules together.
You'd also need lots of talented people designing tons and tons of APIs for all resource types you wish to handle. The OS would have to come with some sort of "base applications" into which the modules could be plugged (for example, if you open a text document, you'd need a base text editor application onto which you could tack your spell checker/various format exporters/etc)
So yes, a cool idea to be sure, but I don't see how this can't be done completely in userspace on top of the multithreaded kernel of your choice.