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.So, here is the idea: You got a fully multi threaded, multi-buzzworded OS with all the latest modern goodies in it, but no applications. Yes, the OS would not include any application with the traditional sense of the word. Instead, all it will support would be modules. The UI would be task-based and file-based at the same time. The way you access your work files is by a panel that includes all the mime types and depending which mime type you pick from the list, you can sort their resulted files found on your hard drive based on how much you are using them, recently modified, file size and more such criteria (sometimes, different criteria for files with different MIME types).
Let’s say that you want to load a PNG graphics file. You open the file and you got the graphics image in front of you. Now, you must decide what you want to do with this file.
Let’s say that you want to apply a filter, resize it and then save it. But there is no application like The Gimp, or Photoshop or PaintShopPro to do so. Instead, the OS provides the use of modules to carry out such actions. Each module is like a very small library/application, loaded by the system for use with specific MIME types (each module should include a header section where describes itself, its relationship with other modules and the system) and each of these modules only do a very-very specific job. So, you use one module to save as PNG, you will need another module to apply the “watermark” filter, and another one to be able resize the image. All these modules can be written by completely different authors, but because they are doing a very specific job, these can be easily and timely implemented by developers. So, even if you think “wow, no applications for this OS?”, the reality is that the most common needs will be satisfied in a very short period of time from a general release.
As you can see, with this system, there will never be Photoshop and PaintShopPro fighting for market share. There will be NO full applications whatsoever about any kind of usage (no sound apps, no CAD apps, no DTP full apps etc). Some pros and cons for this system on top of my head:
Pros:
* Natural multi threaded code, pretty responsive implementation by design.
* The user will get a default OS installation with only the most needed features and not one more that he/she might not need.
* Adding new modules will be easy, downloading and installing via the web, and each module will hardly be more than 20-100 KB (depending on what is for), so download times are not an issue at all and almost instant even for modem users.
* The user will know exactly how to use his/her computer because the number of modules installed are decided by the user and they are probably there because he/she needs them in the first place. The operation of the computer is now simpler and fully customized.
* Price of operating a computer is now lower (e.g. no need to buy Photoshop for $500 and then only use 20% of its capabilities – you only have installed what you need each time). Renting software is now much easier and lots of free modules will be available anyway.
* Less bugs and security concerns overall, as debugging a smaller piece of code is way easier.
* Infinite functionality. The more modules you install, the more functionality you get. There are no functionality barriers.
* No more “leaning” on a particular piece of application or big corporations who might ask big amount of money for some of their full pledged applications that include features that you might never use.
* Modules are able to communicate with other modules and some modules can only be used if another third party module is installed. This way, even modules themselves can be extended, not just the root level of OS functionality.
* Such a modularity and with the help of (maybe an XML-based) description for each module can make an Artificial Intelligence system on top of the base OS way easier to be implemented.
Cons:
* It will be a challenge to create an OS in such a way that it doesn’t deadlock with all these modules and at the same time is able to inter operate between them seamlessly.
* Designing the UI for such an OS is also a challenge, as having, let’s say, 300 modules particular to sound files, is a challenge of its own on how to sort them out logically so the user can easily find what he/she needs each time.
* Destroying big markets of applications, can never be good for the IT market. However, a new kind of market would emerge, where the user is more in control.
* This system is fundamentally different from everything around today in the small server/desktop OSes market, so that means that nothing will be able to get ported, as the whole philosophy is different. Developers might have trouble programming for this OS, at first.
* Too much work to have something like this up and running. Today, most new OSes just use some freely available tools and libraries to speed up their development instead of re-inventing the wheel (eg. Gnu tools). For this OS, a lot of re-invention and re-coding will have to be done.
* General consistency between modules might be an issue as they come from completely different developers. General inter operability between modules might be an issue too, at least until the system matures.
Microsoft with .NET and Oberon have some similar concepts, but none go to the extreme of implementing this architecture. (Update: readers now tell me that the Taligent/OpenDOC architecture had some similar concepts, but still, not quite the same.)
What do you think? Would something like it work? Try to think “out of the box” before trying to answer though.
The Phoenix Developers Consortium http://phinixi.com has been working on this concept for several years, and has a comprehensive whitepaper written on it.
We have many goals similar to those proposed here, but we have some other ways (ie: middle-ware) of achieving them. Which I feel help solve some the problems mentioned. Our system would also work transparently over a network, or internet with a virtual private network.
There is not much on the site at present- I was about to release a major overview of our INDI project, and do a post on OSNews as well.
On the issue of module-management hell for beginners, you don’t have to install everything one tool at a time, but can install packages with tool sets in them. This makes for much easier management, and of course the option of having individual control of each tool is there for experts as well.
I don’t see there being hundreds of different tools to choose from, just a base default set that comes with the system (as we want to provide opportunity for 3rd party devs, and not do what MS does in this regard), and maybe just some tool sets being upgraded to better and/or extended ones. At most you would likely only have the default set, and maybe two others, with experts taking, the best tools of the three.
You have to remember that the 3rd party tools won’t all be necessarily open-source, if you have to pay for them, you are unlikely to be buying more than one type of toolset, just as you wouldn’t with a monolithic app.
And there is a precedence for this, the Amiga had Datatypes (BeOS had something similar, but I’m not familiar with the system), which autotranslated and displayed/played graphics, sounds, text etc for apps. Now there was several 3rd party developers, that produced additional Datatypes for the system, most people just ended with one set from one developer- there wasn’t a great problem there. What we’re basically adding such a system is the ability to save, and edit as well.
As for GUI problems, well I see that there still would be traditional apps as such, like a paint program, but the tools it uses can be mixed and matched, and added to. The app would provide a consistent UI, and manage the tools appropriately, while allowing the user to fully customise toolbars etc as well.
The modules would provide a self-documenting interface, so the paint program would know what gadgets/widgets to provide the user for what tool. For example for a transparency tool, a slider widget with 0-100% would be documented for it’s interface. Then when the tool is activated, the % parameter would be fed to the tool.
I would also note there is a precedence for this too- it’s called MS Office! If you want to edit an object embedded in an another object, it calls up the appropriate tools/toolbars. Now the question you should be asking yourselves here, is do you want to use MS-only tools here, or have the option of using any 3rd-party tools, as soon there may be little choice…
Currently Phoenix’s solution is intended to be commercial and closed-source, because IMO something this large and complex cannot be easily managed open-source. You need to define many APIs and systems, and having one company dedicated to defining the standards (with input obviously) would work better.
Now I could be wrong there, and we may open-source some or all of our IP, and we are open to discussion with others with similar ideas here. If we did, we would most likely open-source it after APIs etc are done.
As far as OSes are concerned, we’ve been designing around QNX, as it has a modular nature, and fast messaging, and other advanced design, like Resource Managers, and QNet. Another option for us would be Morphos as it is fast and modular too. From what I hear BeOS has similar qualities too.