Yes, this is why the STEPS proposal was careful to avoid "the current day 

For example, one of the many current day standards that was dismissed 
immediately is the WWW (one could hardly imagine more of a mess). 

But the functionality plus more can be replaced in our "ideal world" with 
encapsulated confined migratory VMs ("Internet objects") as a kind of next 
version of Gerry Popek's LOCUS. 

The browser and other storage confusions are all replaced by the simple idea of 
separating out the safe objects from the various modes one uses to send and 
receive them. This covers files, email, web browsing, search engines, etc. What 
is left in this model is just a UI that can integrate the visual etc., outputs 
from the various encapsulated VMs, and send them events to react to. (The 
original browser folks missed that a scalable browser is more like a kernel OS 
than an App)

These are old ideas, but the vendors etc didn't get it ...



> From: Reuben Thomas <>
>To: Fundamentals of New Computing <> 
>Sent: Tuesday, February 28, 2012 1:01 PM
>Subject: Re: [fonc] Error trying to compile COLA
>On 28 February 2012 20:51, Niklas Larsson <> wrote:
>> But Linux contains much more duplication than drivers only, it
>> supports many filesystems, many networking protocols, and many
>> architectures of which only a few of each are are widely used. It also
>> contains a lot of complicated optimizations of operations that would
>> be unwanted in a simple, transparent OS.
>Absolutely. And many of these cannot be removed, because otherwise you
>cannot interoperate with the systems that use them. (A similar
>argument can be made for hardware if you want your OS to be widely
>usable, but the software argument is rather more difficult to avoid.)
>> Let's put a number on that: the first public
>> release of Linux, 0.01, contains 5929 lines i C-files and 2484 in
>> header files. I'm sure that is far closer to what a minimal viable OS
>> is than what current Linux is.
>I'm not sure that counts as "viable".
>A portable system will always have to cope with a wide range of
>hardware. Alan has already pointed to a solution to this: devices that
>come with their own drivers. At the very least, it's not unreasonable
>to assume something like the old Windows model, where drivers are
>installed with the device, rather than shipped with the OS. So that
>percentage of code can indeed be removed.
>More troublingly, an interoperable system will always have to cope
>with a wide range of file formats, network protocols &c. As FoNC has
>demonstrated with TCP/IP, implementations of these sometimes made much
>smaller, but many formats and protocols will not be susceptible to
>reimplementation, for technical, legal or simple lack of interest.
>As far as redundancy in the Linux model, then, one is left with those
>parts of the system that can either be implemented with less code
>(hopefully, a lot of it), or where there is already duplication (e.g.
>Unfortunately again, one person's "little-used architecture" is
>another's bread and butter (and since old architectures are purged
>from Linux, it's a reasonable bet that there are significant numbers
>of users of each supported architecture), and one person's
>"complicated optimization" is another's essential performance boost.
>It's precisely due to heavy optimization of the kernel and libc that
>the basic UNIX programming model has remained stable for so long in
>Linux, while still delivering the performance of advanced hardware
>undreamed-of when UNIX was designed.
>fonc mailing list
fonc mailing list

Reply via email to