To view parent comment, click here.
To read all comments associated with this story, please click here.
The busses are abstracted by the HAL. Card specific native code could be uploaded to the card. But card specific code is not hardware platform specific.
That is exactly my point. The human-readable code is obfuscated by a compiler which emits VM runtime specific code.
No, the OS I dream of does not have any platform dependent code. Device depend (e.g. firmware for a NIC) maybe, but no platform dependent code at all.
Netbeans for example has a identical code base for all hardware platforms. You can copy the installation directory tree from one platform to another. I "migrated" a Netbeans installation from Solaris 9 SPARC64 to RHEL on x86. It works. Just tar the directory tree on one platform and untar it on the other.
Yes, the installation routine requires a burn in script to be run. Also patches need a burn in script.
Well, yesterday I updated my private Windows XP system. Hey it took almost 1 1/2 hours until the updater has determined which patches are required. Even on a Solaris system patching may take hours. So, if you take the Debian apt-get mechanism instead of the Windows or Solaris update mechanisms you have a lot of time saved, which could be used to run the burn in ;-)
pica
PS I am home now. So, till tomorrow.
Well, sounds like this would require a bit of help from the hardware (eg at loading time, for the loading process to be platform-independent). Personally, I think that an hybrid solution where a compilable source (obfuscated if vendors want) AND binary images for the main target platforms are provided would be better as far as performance is concerned, but we agree when it comes to saying that the hardware-dependent part of an OS should be kept minimal...
About netbeans, it works so because it's coded in Java. This cannot work for a kernel since to run java programs you need the JVM and the standard Java library, and implementing that basically requires one to code a whole OS whose sole role is to be a JVM (as has been done in research projects some times).
Edited 2010-10-25 16:58 UTC




Member since:
2010-03-08
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...
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