Killer Operating System

KillerOperatingSystem is quite a nebulous concept. The precise things we want in a killer operating system change frequently, which means that it is probably doomed stay in the realm of our imaginations. Nevertheless, it is a great inspiration.

However, being all things to all people is hardly a good idea for most things - operating systems included. (WorseIsBetter). It may or may not be possible to combine all OperatingSystemsDesignPrinciples. Some people go so far as to say that instead of KillerOperatingSystem, we should KillTheOperatingSystem.

A killer operating system would hardly be killer without appealing to the masses - it must have a KillerUserInterface.

And appealing to the masses is not enough for us programmer-types - it must have the things we like: TransparentPersistence, KillerFileSystem, and KillerReliability?.

There is an enormous wish list at NewOsFeatures.

A killer OperatingSystem would implement AllDataRelatesToOtherData and therefore interface with a ThreeDimensionalVisualizationModel to a UnifiedDataModel. Applications, instead of being monolithic, closed apps would be modular, loosely-coupled mash-ups that work with UserData? and the InternetAsCloudStorage. The user-machine becomes used less as a computer, and more as a terminal, because the greater data is out there.

The relationships should be reactive, too, i.e. such that a change or repair in data in one location propagates to all the other data related to it. I expect synchronous concurrency will be necessary, to formally address the diamond-shaped dependency graphs and conditions where many things change at once or to avoid missing critical intermediate values. And we'll probably need to model latency relationships logically if we are to scale beyond a spreadsheet or integrate effects.

We've already seen a KillerOperatingSystem: SkyNet. ;)

Don't forget Hal and GLaDOS
See WhyDoOperatingSystemsSuck


EditText of this page (last edited May 24, 2013) or FindPage with title or text search