Linked by Thom Holwerda on Sat 23rd Oct 2010 22:23 UTC
Permalink for comment 446978
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Features
Linked by Thom Holwerda on 05/21/13 21:38 UTC
Linked by Thom Holwerda on 05/20/13 11:29 UTC
Linked by Thom Holwerda on 05/18/13 21:33 UTC
Linked by David Adams on 05/16/13 4:23 UTC
Linked by Thom Holwerda on 05/11/13 21:41 UTC
Linked by Thom Holwerda on 05/08/13 14:22 UTC
Linked by Thom Holwerda on 05/02/13 15:28 UTC
Linked by Thom Holwerda on 04/29/13 21:06 UTC
Linked by Thom Holwerda on 04/24/13 22:24 UTC
Linked by Thom Holwerda on 04/18/13 11:21 UTC
More Features »
Sponsored Links



Member since:
2005-07-10
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.