Linked by Thom Holwerda on Sat 23rd Oct 2010 22:23 UTC
Thread beginning with comment 446951
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
The benefit is ...
by pica on Mon 25th Oct 2010 15:19
in reply to "RE: Maybe OT: The OS I am dreaming of"
... 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
... 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 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
About performance ...
by pica on Mon 25th Oct 2010 15:26
in reply to "RE: Maybe OT: The OS I am dreaming of"





Member since:
2010-03-08
* 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.
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++ ?
Again, why not a microkernel and high-level components written in platform-independents component languages instead ? What's the added benefit ?
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