Linked by Thom Holwerda on Sat 23rd Oct 2010 22:23 UTC
Windows "Windows 7 might be a massive commercial success and an undeniably rock solid piece of software, but Microsoft is apparently unwilling to rest on those soft and cozy laurels. Asked about the riskiest product bet the Redmond crew is currently developing, its fearless leader Steve Ballmer took no time in answering 'the next release of Windows'." Also of note in this same video interview thing: Ballmer states that Silverlight is now pretty much strictly a client, non-cross platform thing, while explicitly stating that when it comes to doing something universal, "the world's gone HTML5".
Thread beginning with comment 446951
To view parent comment, click here.
To read all comments associated with this story, please click here.
Neolander
Member since:
2010-03-08

would be modular and scalable. As a result it would support
* embedded systems
* mobile Phones
* tablets
* desktops
* servers

It would just have a minimal hardware abstraction layer. This HAL only would cover CPU, busses and memory. Only this tiny HAL and a small VM "bootloader" would be CPU Architecture dependend.

Okay, until there I follow you. Sounds like a microkernel.

The VM runtime "bootloader" is a simple interpreter. It's only purpose is to bootload an optimizing VM runtime utilizing JIT technics. Everything else even the optimizing VM runtime itself would run on the optimizing VM runtime. This would include device drivers like graphic card, NIC or SATA drivers. As a result it would support several processor architectures. IMHO at least x86, x86-64, ARM Cortex Mx and Ax and MIPS 32bit and 64bit should be supported.

There I'm lost. It sounds like you would like to write almost all of this OS in interpreted code. This basically means recompiling most of the OS at every boot (except is JITed code is cached in some way). Performance would be horrible. Apart from technological achievement, what's the point of using this instead of platform-independent compiled languages like C and C++ ?

Also the OS itself the schedulers -- I think of schedules as "plugins" --, filesystems, etc. would run on the VM runtime.

Again, why not a microkernel and high-level components written in platform-independents component languages instead ? What's the added benefit ?

It would optionally offer a remote shell, a GUI optimized for handheld devices or a GUI optimized for desktops. The desktop optimzed GUI would support remote access.

Couldn't a properly done GUI infrastructure optimize for both ? (I'm thinking about this in my own OS project, but I'm not there yet so I can't tell about it being doable in practice)

Edited 2010-10-25 13:47 UTC

Reply Parent Score: 2

The benefit is ...
by pica on Mon 25th Oct 2010 15:19 in reply to "RE: Maybe OT: The OS I am dreaming of"
pica Member since:
2005-07-10

... that even closed source components (e.g. some graphic card drivers are closed source) are available on all hardware platforms.

The part up to the optimizing VM runtime can be provided be the hardware vendor.

The OS vendor provides the running on that runtime OS. Here is another benefit: The OS vendor only has to provide a single image. Has to patch only each issue once.

pica

Reply Parent Score: 1

RE: The benefit is ...
by Neolander on Mon 25th Oct 2010 16:15 in reply to "The benefit is ..."
Neolander Member since:
2010-03-08

... that even closed source components (e.g. some graphic card drivers are closed source) are available on all hardware platforms.

The part up to the optimizing VM runtime can be provided be the hardware vendor.

1/Graphic card drivers are generally linked to a single hardware platform, so how do they benefit from that interpreted ecosystem, knowing that they'll include a large amount of bus-specific code anyway ?
2/The vendor does have to provide some kind of source code (as opposed to platform-dependent binary) if we want the program to be compiled/interpreted on multiple platforms. If he does not want it to be human-readable, the best he can do is using an automated code obfuscation system like the one offered by Java...

The OS vendor provides the running on that runtime OS. Here is another benefit: The OS vendor only has to provide a single image. Has to patch only each issue once.

Wrong, he must provide several images, since as you said a (tiny but necessary) part of the OS has to be hardware-dependent. Moreover, if the code has been properly written, the OS vendor generally only has to patch it once too. The extra step is to recompile it once for each supported platform, but if he doesn't do it, someone will have to do it at his place.

You can see it this way : either the OS vendor compiles one image per platform, or each user, on each platform, will have to compile an image in real-time at first boot and experience the sluggish Gentoo-style first impression that this leads to.

Edited 2010-10-25 16:18 UTC

Reply Parent Score: 2

About performance ...
by pica on Mon 25th Oct 2010 15:26 in reply to "RE: Maybe OT: The OS I am dreaming of"
pica Member since:
2005-07-10

you gave the answer yourself: native code caching would do the trick.

Maybe also a burn in script to initially fill the native code cache(s) would help.

pica

Reply Parent Score: 1