On 2/28/2012 2:30 PM, Alan Kay wrote:
Yes, this is why the STEPS proposal was careful to avoid "the current day world".

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

I don't think "the web" is entirely horrible:
HTTP basically works, and XML is "ok" IMO, and an XHTML variant could be ok.

granted, moving up from this, stuff quickly turns terrible (poorly designed, and with many "shiny new technologies" which are almost absurdly bad).

practically though, the WWW is difficult to escape, as a system lacking support for this is likely to be rejected outright.

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)

it is possible.

in my case, I had mostly assumed file and message passing.
theoretically, script code could be passed along as well, but the problem with passing code is how to best ensure that things are kept secure.

in some of my own uses, an option is to throw a UID/GID+privileges system into the mix, but there are potential drawbacks with this (luckily, the performance impact seems to be relatively minor). granted, a more comprehensive system (making use of ACLs and/or "keyrings" could be potentially a little more costly, rather than simple UID/GID rights checking, but all this shouldn't be too difficult to mostly optimize away in most cases).

the big issue is mostly to set up all the security in a "fairly secure" way.

currently, by default, nearly everything defaults to requiring root access. unprivileged code would thus require interfaces to be exposed to it directly (probably via "setuid" functions). however, as-is, it is defeated by most application code defaulting to "root".

somehow though, I think I am probably the only person I know who thinks this system is "sane".

however, it did seem like it would probably be easier to set up and secure than one based on scoping and visibility.

otherwise, yeah, maybe one can provide a bunch of APIs, and "apps" can be mostly implemented as scripts which invoke these APIs?...

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

browser vendors originally saw the browser merely as a document viewing app (rather than as a "platform").

support for usable network file systems and "applications which aren't raw OS binaries" are slow-coming.

AFAIK, the main current contenders in the network filesystem space are SMB2/CIFS and WebDAV.

possibly useful could be integrating things in a form which is not terrible, for example:
OS has a basic HTML layout engine (doesn't care where the data comes from);
the OS's VFS can directly access HTTP, ideally without having to "mount" things first;

in this case, the "browser" is essentially just a fairly trivial script, say: creates a window, and binds an HTML layout object into a form with a few other widgets; passes any HTTP requests to the OS's filesystem API, with the OS managing getting the contents from the servers.

a partial advantage then is that other apps may not have to deal with libraries or sockets or similar to get files from web-servers, and likewise shell utilities would work, by default, with web-based files.

"cp http://someserver/somefile ~/myfiles/"

or similar...

actually, IIRC, my OS project may have actually done this (or it was planned, either way). I do remember though that sockets were available as part of the filesystem (under "/dev/" somewhere), so no sockets API was needed (it was instead based on opening the socket and using "ioctl()" calls...).

side note: what originally killed my OS project was, at the time, reaching the conclusion that it wouldn't have been likely possible for me to compete on equal terms with Windows and Linux, rendering the effort pointless, vs instead developing purely in userspace. does bring up some interesting thoughts though.

or such...



    *From:* Reuben Thomas <r...@sc3d.org>
    *To:* Fundamentals of New Computing <fonc@vpri.org>
    *Sent:* Tuesday, February 28, 2012 1:01 PM
    *Subject:* Re: [fonc] Error trying to compile COLA

    On 28 February 2012 20:51, Niklas Larsson <metanik...@gmail.com
    <mailto:metanik...@gmail.com>> 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.

-- http://rrt.sc3d.org
    fonc mailing list
    fonc@vpri.org <mailto:fonc@vpri.org>

fonc mailing list

fonc mailing list

Reply via email to