Slashdot Mirror

for instance, the Sys module is documented in sys-intro(2), sys-read(2),sys-open(2), etc.

man 2 sys gets you sys-intro. this also works for commands, for instance the shell (sh, not the Bourne shell) is documented along with its loadable modules, e.g. sh(1), sh-std(1), sh-expr(1).

i'd concur with the people that like the standard format of man pages - writing a man page forces you to put your thoughts into order, rather than splurge your current mindset. this is great for searching for information.

traditionally, unix has used the "paper" format for tutorial or detailed descriptions of larger commands. the man page for troff, for example, doesn't mention all the troff directives - for that you need the troff paper (/sys/doc/troff.ms on plan 9)

call me a die-hard if you like, but the man page format has survived as well as it has for a reason (actually it predated unix by some time) - it makes for an excellent reference manual. the fact that it uses [nt]roff is not entirely relevant - the important thing is that the sections are standard, so if you want to find info on a command, you know where to look.

for instance, the Sys module is documented in sys-intro(2), sys-read(2),sys-open(2), etc.

man 2 sys gets you sys-intro. this also works for commands, for instance the shell (sh, not the Bourne shell) is documented along with its loadable modules, e.g. sh(1), sh-std(1), sh-expr(1).

i'd concur with the people that like the standard format of man pages - writing a man page forces you to put your thoughts into order, rather than splurge your current mindset. this is great for searching for information.

traditionally, unix has used the "paper" format for tutorial or detailed descriptions of larger commands. the man page for troff, for example, doesn't mention all the troff directives - for that you need the troff paper (/sys/doc/troff.ms on plan 9)

call me a die-hard if you like, but the man page format has survived as well as it has for a reason (actually it predated unix by some time) - it makes for an excellent reference manual. the fact that it uses [nt]roff is not entirely relevant - the important thing is that the sections are standard, so if you want to find info on a command, you know where to look.

So why, pray tell, would I spend more for a possibly useless OS for a system I bought for $200? Thanks but no thanks...

If UNIX/LINUX treats everything like a file, why not TCP/IP ports, too? That way, you could assign a port to a group/user who could access that port without being root!!!

Ahh, yes. Somebody finally noticed. Unfortunately TCP/IP was not added to UNIX until BSD in the 80's. So we have BSD Sockets and the "Everything is a File" mantra no longer holds.

I believe that Plan9, now known as Inferno, works this way. It was developed in the late 80's/early 90's by the original UNIX people at Bell Labs. Lucent (Bell Labs) has released Plan9 source under their own license, source and binaries can be downloaded here.

Have Fun!

It is an interesting way to tackle certain problems: rather than writing a whole operating system to abstract away the complexity of working with the hardware, you get another operating system to do the heavy lifting, and all you have to worry about is interfacing with the [hopefully well documented, or better still open source] API. And since Moore's Law is on your side, you can get away with this layered approach without too much of a performance hit, freeing you do work on more interesting high level problems.

This is all assuming, of course, that the underlying OS is more of an assistant than a straightjacket -- we want enough rope to not only hang ourselves, but to do so in a cool variety of ways :) -- and then you get into some other interesting-yet-pointless-and-kinda-boring questions about the difference between one of these "new operating systems" and pre-existing layered techniques like, say, Flash in web browsers or Gnome on top of X-Windows. Yeah, I'll agree that it's a stretch (at best) to call Gnome or Flash an operating system, and yeah I'll agree that there might not be so much difference between those plugin components and this idea.

But so what? If what you're dealing with is some kind of extension to existing tech that makes it in fact something pretty fundamentally a different thing, does that not make it any less interesting? Put another way, if you're into cars (which I'm not, but this is the best example I can think of), is a souped up hotrod any less impressive than a factory built sports car? The Porsche/Linux may be a more impressive machine for being designed so well from the ground up, but at the same time, the rebuilt VW-Bug-with-the-911-engine/Athena goes just as quick, and it's impressive to see what people can do with that platform.

I dunno, it's an interesting but probably unresolvable question. If Athena can be made to run on it's own, as BeOS can, that'll win it some cred points. I'm not sure if that matters though -- if they can accomplish some of their design goals while working inside the sandbox, it's still going to be an interesting achievement. I'm all for seeing people do new & interesting things with too-stale platforms like Windows & Linux...

...And for multithreaded programs, a message passing paradigm is generally the best approaching my experience...

If you are looking for languages that make avoiding bugs easier, look beyond C++...

Inferno's Limbo uses just that. And has a nice GUI multithreaded debugger. Runs on all platforms. And the source is publicly available.

...And for multithreaded programs, a message passing paradigm is generally the best approaching my experience...

If you are looking for languages that make avoiding bugs easier, look beyond C++...

Inferno's Limbo uses just that. And has a nice GUI multithreaded debugger. Runs on all platforms. And the source is publicly available.

...And for multithreaded programs, a message passing paradigm is generally the best approaching my experience...

If you are looking for languages that make avoiding bugs easier, look beyond C++...

Inferno's Limbo uses just that. And has a nice GUI multithreaded debugger. Runs on all platforms. And the source is publicly available.

Contrast both SOAP and Corba to Styx/9P, the object protocol of Inferno and Plan 9, also available for other environments as a product which at least used to be called InfernoSpaces. It was available as Java classes and C libraries for several development environments.

See The Styx Architecture for Distributed Systems, Styx/9P-search on Google, a real life example of an interface to remote functionality, Styx manual pages, Inferno home and Plan 9 home.

Listing, naming and accessing of "remote objects" become trivial. Permanent and transient objects look the same, and just like regular files. Commands are usually issued as text content. So bindings to functions are language independent.

Optional authentication, data integrity and confidentility are built in, and can be configured at run time, transparent to the programmer.

Contrast both SOAP and Corba to Styx/9P, the object protocol of Inferno and Plan 9, also available for other environments as a product which at least used to be called InfernoSpaces. It was available as Java classes and C libraries for several development environments.

See The Styx Architecture for Distributed Systems, Styx/9P-search on Google, a real life example of an interface to remote functionality, Styx manual pages, Inferno home and Plan 9 home.

Listing, naming and accessing of "remote objects" become trivial. Permanent and transient objects look the same, and just like regular files. Commands are usually issued as text content. So bindings to functions are language independent.

Optional authentication, data integrity and confidentility are built in, and can be configured at run time, transparent to the programmer.

Contrast both SOAP and Corba to Styx/9P, the object protocol of Inferno and Plan 9, also available for other environments as a product which at least used to be called InfernoSpaces. It was available as Java classes and C libraries for several development environments.

See The Styx Architecture for Distributed Systems, Styx/9P-search on Google, a real life example of an interface to remote functionality, Styx manual pages, Inferno home and Plan 9 home.

Listing, naming and accessing of "remote objects" become trivial. Permanent and transient objects look the same, and just like regular files. Commands are usually issued as text content. So bindings to functions are language independent.

Optional authentication, data integrity and confidentility are built in, and can be configured at run time, transparent to the programmer.

Contrast both SOAP and Corba to Styx/9P, the object protocol of Inferno and Plan 9, also available for other environments as a product which at least used to be called InfernoSpaces. It was available as Java classes and C libraries for several development environments.

See The Styx Architecture for Distributed Systems, Styx/9P-search on Google, a real life example of an interface to remote functionality, Styx manual pages, Inferno home and Plan 9 home.

Listing, naming and accessing of "remote objects" become trivial. Permanent and transient objects look the same, and just like regular files. Commands are usually issued as text content. So bindings to functions are language independent.

Optional authentication, data integrity and confidentility are built in, and can be configured at run time, transparent to the programmer.

The Styx Architecture for Distributed Systems

Just invoking the word "bytecode" or compiling a language to bytecode doesn't suddenly make the virtual machine language independent.

Java bytecode, for instance, is significantly tied to the Java language specification. Go browse The Java VM Specification if you like -- classes fields, members, construction, interfaces, and garbage collection are built into the VM.

Admittedly, I am ignorant of Dis code, but when I see "Inferno applications are written in Limbo" in the Inferno FAQ, my confidence in a language independent Inferno VM is shaken.

It does indeed run outside of the browser.
In fact the plug-in is using the same kernel code as the other hosted versions of inferno. These exist for Linux, Windows(95/98/ME/NT/2000), FreeBSD, Solaris, Irix and HP-UX.

Inferno also runs natively on the raw hardware. Ports exist for Compaq IPAQ, various web-phones, various pieces of network gear including a firewall, set-top-boxes etc. etc.
Check out the Vita Nuova website for info on ports and how to get the software.

As for targeting other browsers, yes there is already a Linux/Netscape version in production. With others to follow.

the system dependent part of the inferno kernel (devfs.c) could map all slashes that it saw when reading the filesystem to unicode character 2215 (division slash) or 2044 (division slash) or even 2298 (circled division slash) if you wanted the distinction to be crystal clear. the translation would work the other way when filenames were presented to the kernel by inferno programs.

in this way, the whole thing works ok. of course, it's not entirely perfect if the user wants to be able to type in those pathnames, (the name isn't exactly what they would have expected) but using the standard graphical file browser, everything would work just fine.

the goal of Inferno is to have programs that genuinely run the same in any environment, not to have programs that are kind of chameleon-like, adopting some of the traits of the host environment. this decision is arguable, but it is the only way to get true write once, run anywhere software. you don't true portability? you know where to find Java.

Dare you assume that I don't need to know the endianness of the machine? A lot of what I do is getting systems to interoperate. Say I have a program, compiled for two different machines. It saves its data in the endianness of the host machine (just does a memory dump or such). Now I want to write a (binary) portable program to run on both machines to interpret these data files. Without knowing the endianness of the machine, I'm stuffed.

that's not true.
without knowing the endianness of the data file, you're stuffed. this is a distributed system, remember. filesystems, data, network interfaces, and devices can all be imported an exported completely transparently across machine boundaries. it sounds like you're still living in the old world, where the data on the file system you're accessing is guaranteed to be on the same machine. that's just not true any more (and hasn't been for at least a decade, if truth be told).

under Inferno, applications are completely unaware of where the files that they're accessing have come from. (and don't forget that device access is also through the "file" namespace). the file i'm accessing might go straight to the local hard disk, or it might have been imported from a mounted connection obtained by using an imported network interface, connected over a USB link to some machine over an ATM link running a Limbo program that's exporting the file.

the resource deployment can be as simple or as complex as you like, but the applications themselves are blissfully unaware of what might be happening behind the scenes.

any binary data file worth its salt should either keep the data in a predefined endianness, or declare the endianness in the header. that way, someone on a sparc box will still be able to interpret the data file that you email them from a linux x86 box.

Whether they'll work correctly or not is another matter. Is it not possible to make incorrect assumptions about the virtual hardware (such as whether there is a graphics interface available or not) or is the virtual hardware interface strictly defined?

all the hardware device interfaces reside in the namespace, so it's easy to probe to see whether a given device has been provided or not. an incorrect assumption will generate only a "file not found" error.

if the hardware is found, it will act according to its specifications - device control is all through the file interface. low bandwidth data is generally encoded in that universal, endian-independent format: text.

so, for instance, the interface to a tv device contains two files /dev/tv and /dev/tvctl. i can execute the shell command:

echo window 20 20 300 300 > /dev/tvctl

to set the currently displayed tv image rectangle. a captured tv image can be read in a standard image file format with:

cp /dev/tv /tmp/image.pic

it's as simple as that. this interface means that it's possible to (for instance) write a user-level program to simulate a device for which i haven't got the hardware, or to use the namespace access protocol, Styx, to import or export the device across the network securely.

Note that I'm not trying to dis Inferno overall, I'm just not sure that the Inferno method of path handling is "correct". Heck, I'd even say that assuming a traversable directory tree is suspect (What a program should really call is system.UserFileInterface and let the underlying system handle it).

if the underlying system doesn't provide a hierarchical filesystem, that's not a problem. the person porting to that system needs to make a decision how to map that filesystem into the inferno model. the "files" that are accessed under inferno aren't really "files" as most people think of them; it might be helpful to think of them as "hierarchical resources" which are accessed in exactly the same way as files.

a "file" under inferno requires no physical resources; it is merely an interface to some underlying software, whether that's a device driver, interpreting writes as commands, or a disk filesystem, storing the data in each write to disk, as you'd expect of a normal file.

you could also think of the inferno namespace as a kind of hierarchical object space, in which each file provides a common set of methods (open, read, write, etc) which can be interpreted as appropriate for the object. looked at that way, directory reading (inspecting metadata) becomes a kind of "reflection", exposing capabilities of the system to an inquisitive program, which can then use them as appropriate.

for instance i could write a little shell script:

if {ftest -f /dev/tv} {
echo channel 3 > /dev/tvctl
echo window 0 0 40 40 > /dev/tvctl
}

this enquires to see if there is a tv device available, and if so sets a particular channel and creates a small window for it at the top left of the screen. all without using any commands written specifically for the device.

that's true power.

What many folks may not realise is that Inferno was in fact written in answer to Java. Development started more than 6 years back when the first Netscape browsers were released with Java support.

The first Netscape with Java embedded came out a year before Java was released? Yowza. :-)

Or were you saying that Bell Labs is so danged advanced, they had a competing product out before there was anything to compete with?

Or were you choosing to ignore Bell Labs'own documents, which say that they were trying to extend Plan 9 to network devices, and were unaware of the Java work?

With it you can mount the file server from Inferno and read and write to ODBC databases. The file server presents a name space that looks like this:

/db/new
/db/n/cmd
/db/n/ctl
/db/n/data
/db/n/error
/db/n/format
/db/n/status

Each open of the `new' file results in a new conversation with the server. You can send management commands to the `ctl' file, SQL commands to the `cmd' file, read the format of results from the `format' file and the actual result data from the `data' file. You can manipulate the database through the namespace, from a Limbo program, or even from the shell like so:

mount -A tcp!localhost!6700 /n/remote
{
d=/n/remote/db/`{cat}
echo 'connect cellar' >$d/ctl
echo 'select name from wine' >$d/cmd
cat $d/data
}</n/remote/db/new

Through the namespace you can control the format of the returned results, control transactions, connect to new databases, execute commands, and of course read the results.

The server runs under Windows on a remote machine and connects to its local ODBC service. In common with all Inferno servers it then exports those services over a network (not just TCP/IP) to other Inferno systems using the Styx protocol.

Its easy to write servers for other databases, and indeed other kinds of service. One of the nice things about such servers is that they can be explored using common commands like: ls, cat, awk, pwd, cp, echo, acme and even perl, i.e. without specialised interfaces in each program.

With it you can mount the file server from Inferno and read and write to ODBC databases. The file server presents a name space that looks like this:

/db/new
/db/n/cmd
/db/n/ctl
/db/n/data
/db/n/error
/db/n/format
/db/n/status

Each open of the `new' file results in a new conversation with the server. You can send management commands to the `ctl' file, SQL commands to the `cmd' file, read the format of results from the `format' file and the actual result data from the `data' file. You can manipulate the database through the namespace, from a Limbo program, or even from the shell like so:

mount -A tcp!localhost!6700 /n/remote
{
d=/n/remote/db/`{cat}
echo 'connect cellar' >$d/ctl
echo 'select name from wine' >$d/cmd
cat $d/data
}</n/remote/db/new

Through the namespace you can control the format of the returned results, control transactions, connect to new databases, execute commands, and of course read the results.

The server runs under Windows on a remote machine and connects to its local ODBC service. In common with all Inferno servers it then exports those services over a network (not just TCP/IP) to other Inferno systems using the Styx protocol.

Its easy to write servers for other databases, and indeed other kinds of service. One of the nice things about such servers is that they can be explored using common commands like: ls, cat, awk, pwd, cp, echo, acme and even perl, i.e. without specialised interfaces in each program.

In early 1995, we set out to apply the ideas of the Plan 9 operating system [1] to a wider range of devices and networks. The resulting system, Inferno [2], is a small operating system and execution environment that supports application portability across a wide variety of processors and operating systems. Unaware of the contemporary work to establish Java [3] from the technology of the Oak project, we independently concluded that a virtual machine (VM) was a necessary component of such a system [4]. Because of improvements in processor speed and the feasibility of on-the-fly compilers, a VM can execute quickly enough to be economically viable.

It claims (without proof) to be a lot faster than Java: 1.5 - 3 times slower than C (according to this document, the source of much of the following information).

It's all tooled up with both the bad bways of Garbage Collection. Yes, let's hear it, folks, for Mark and Sweep and his old sparring partner Reference Counting. Still doesn't stop it churning perceptibly in the ticker applet. (They claim RT scheduling but that's no good when you're sitting inside IE with JavaScript turned on in a force 9 pr0n gale.) The polyhedra demo is fast and smoothe and reasonably svelte.

'array of array of vector of arse'. Gak! Neither I nor the compiler are amused that dcl is now compulsory.

It can run Limbo source or binaries, not just bytecode.

Dennis Ritchie encourages the development of a C compiler, and maybe the one bundled with Plan 9 has a few tricks up its sleeve. With a gcj-style Dis backend you could install signed X and Gnome/GTK/KDE/Qt (or the unbelievably cool Ion Window Manager) applets to replace the embarrassingly retro interface. How about writing DHTML in Perl or Python instead of JavaScript? Can you say .GNET?

The site's 3 years old and the guy may be talking out of his arse. I'll give him this, though: he sure knows how to diss up C++ with a zeal for hellfire and damnation truly worthy of his dear OS's name:

C++ objects and their complexities are happily left out. There is no polymorphism or tricky exception handling (the difficulty of understanding exception handling caused the explosion of the Ariane 5 rocket).

It's not every day you download and install an operating system in a couple of seconds (ADSL). Didn't even have to powercycle IE let alone reboot its other OS plugin, Windows. If they don't open the source I'm sure there's someone somewhere who's looking at his/her 1 floppy Linux distro and hatching a cunning plan. What a shame Theo de Raadt's so down on a pocket OpenBSD (reminds me of Guido's antipathy to a Python shared object, Linus's allergy to a kernel debugger). That fireproof sonofabitch would be a perfect fit for plug-in World Domination.

It claims (without proof) to be a lot faster than Java: 1.5 - 3 times slower than C (according to this document, the source of much of the following information).

It's all tooled up with both the bad bways of Garbage Collection. Yes, let's hear it, folks, for Mark and Sweep and his old sparring partner Reference Counting. Still doesn't stop it churning perceptibly in the ticker applet. (They claim RT scheduling but that's no good when you're sitting inside IE with JavaScript turned on in a force 9 pr0n gale.) The polyhedra demo is fast and smoothe and reasonably svelte.

'array of array of vector of arse'. Gak! Neither I nor the compiler are amused that dcl is now compulsory.

It can run Limbo source or binaries, not just bytecode.

Dennis Ritchie encourages the development of a C compiler, and maybe the one bundled with Plan 9 has a few tricks up its sleeve. With a gcj-style Dis backend you could install signed X and Gnome/GTK/KDE/Qt (or the unbelievably cool Ion Window Manager) applets to replace the embarrassingly retro interface. How about writing DHTML in Perl or Python instead of JavaScript? Can you say .GNET?

The site's 3 years old and the guy may be talking out of his arse. I'll give him this, though: he sure knows how to diss up C++ with a zeal for hellfire and damnation truly worthy of his dear OS's name:

C++ objects and their complexities are happily left out. There is no polymorphism or tricky exception handling (the difficulty of understanding exception handling caused the explosion of the Ariane 5 rocket).

It's not every day you download and install an operating system in a couple of seconds (ADSL). Didn't even have to powercycle IE let alone reboot its other OS plugin, Windows. If they don't open the source I'm sure there's someone somewhere who's looking at his/her 1 floppy Linux distro and hatching a cunning plan. What a shame Theo de Raadt's so down on a pocket OpenBSD (reminds me of Guido's antipathy to a Python shared object, Linus's allergy to a kernel debugger). That fireproof sonofabitch would be a perfect fit for plug-in World Domination.

http://www.vitanuova.com/inferno/binary_licence.ht ml

You can write and compile applications with the download and then distribute them on the Internet. You don't need to pay any licence fee for doing that - they're your applications!

Whats more there is nothing in the licence to stop you from making money from applications that you develop in this way - you can sell them.

However, I remember an Othello game for the Apple II; I think it moved randomly. Therefore, I could almost always win, even back then. So I don't see the advantage.

well try beating this one! if you don't have IE and Windows, you can always get the free download for Linux, and the source code from here, run "limbo reversi.b" and away you go.

the same applies to tetris, if you're interested.

However, I remember an Othello game for the Apple II; I think it moved randomly. Therefore, I could almost always win, even back then. So I don't see the advantage.

well try beating this one! if you don't have IE and Windows, you can always get the free download for Linux, and the source code from here, run "limbo reversi.b" and away you go.

the same applies to tetris, if you're interested.

However, I remember an Othello game for the Apple II; I think it moved randomly. Therefore, I could almost always win, even back then. So I don't see the advantage.

well try beating this one! if you don't have IE and Windows, you can always get the free download for Linux, and the source code from here, run "limbo reversi.b" and away you go.

the same applies to tetris, if you're interested.

However, I remember an Othello game for the Apple II; I think it moved randomly. Therefore, I could almost always win, even back then. So I don't see the advantage.

well try beating this one! if you don't have IE and Windows, you can always get the free download for Linux, and the source code from here, run "limbo reversi.b" and away you go.

the same applies to tetris, if you're interested.

A paper on the shell is available here

Given Inferno's namespace approach to devices and resources, the shell becomes very powerful. For example, network connections can be established with simple shell commands such as cat and echo. This makes it possible to write things like Chat servers and clients using shell scripts - indeed this has already been done!

Info on licensing...
The license for the plug-in is exactly the same as that for the free Inferno download

A paper on the shell is available here

Given Inferno's namespace approach to devices and resources, the shell becomes very powerful. For example, network connections can be established with simple shell commands such as cat and echo. This makes it possible to write things like Chat servers and clients using shell scripts - indeed this has already been done!

Info on licensing...
The license for the plug-in is exactly the same as that for the free Inferno download

To develop limbo applications you will need to download the free version of Inferno. This comes with compilers, source code for all the standard applications and libraries, the Acme development environment and full documentation. More than enough to get you started.

There is even a paper on writting limbo applications for distribution using the plug-in

To develop limbo applications you will need to download the free version of Inferno. This comes with compilers, source code for all the standard applications and libraries, the Acme development environment and full documentation. More than enough to get you started.

There is even a paper on writting limbo applications for distribution using the plug-in

To develop limbo applications you will need to download the free version of Inferno. This comes with compilers, source code for all the standard applications and libraries, the Acme development environment and full documentation. More than enough to get you started.

There is even a paper on writting limbo applications for distribution using the plug-in

it's funny you should say that. i just had a look at the Linux ICQ client, and the compressed source is 370K, more than half the size of the Inferno plugin...

one of the nicest things about inferno is that it's not bloatware. given that it has Styx protocol support built in to its core, that has already solved many of the hardest problems that people seem to reinvent badly with each custom protocol, such as the one ICQ presumably uses.

Yup, I'm working on the security model right now (when I'm not reading /. !!!) Once we're happy with it, an update will be made available which will open up the networking support.

We have some pretty cool applets available that use the networking. These will be put up on the vita nuova web site, with the plug-in update once the security model is right.

(screenshot is here)

Tetris I can take or leave, but I love Reversi.

However, I remember an Othello game for the Apple II; I think it moved randomly. Therefore, I could almost always win, even back then. So I don't see the advantage.

Try again; you won't be able to seduce me to your wicked ways!


---
pb Reply or e-mail; don't vaguely moderate.

I just installed the plug-in here at my work. And the samples are keeping me extremely entertained. It's pretty neat, a little better than javascript i'd say.

If you actually have a point in implying that Inferno can do oh so much more, come forth and tell us about it instead of attacking people for failing to do something you apparently haven't done yourself.

Moron.

think it's not really an OS, just a shell. Whoever said "OS" was simply slightly misguided

Inferno is an OS which can be gleaned by checking the Overview papers on Inferno, Limbo is the scripting/programming language for the inferno OS. The plugin merely allows you to run Limbo programs in a browser which is exactly what Java plugins enable one to do with applets.

Grabel's Law

After reading the information on the plugin, I fail to see how this is an OS in a browser.

The plugin allows you to run applications written in a specific language(Limbo) for the Inferno OS on your browser but isn't an OS in your browser from what I can see.

This is more akin to being able to run Java applets in your browser via the Java Virtual Machine than any OS in the browser crap.

From the Inferno plugin page
The Inferno Internet Explorer plug-in allows a Limbo program to run inside a web page when displayed by Microsoft Internet Explorer 4 or 5. The plug-in executes Dis within a sandbox in the Inferno Dis virtual machine which provides the execution environment for all programs running under the Inferno Operating System

Grabel's Law

Yes you'll need to audit that first limited OS and kernel, and yes it'll probably be in C, but let's limit the scope of that code severely. Plan to take a huge performance hit on running everything on that VM but make sure that it's totally secure, do whatever it takes to make sure that everything running on it is protected from itself and other programs. This is the only possible way to make an extensible operating system that is in any way secure, otherwise any software that is later added to the system will either need to be painstakingly audited or not installed. Performance should be a minor concern at this point as VMs can later be optimized, and security should be of prime importance.

this is exactly the approach taken by Inferno, which was designed and built by some of the best minds in computer science. (e.g. Dennis Ritchie, Rob Pike)

the approach works very well; the only downside is that because you are doing things better, they are different which means you actually have to learn some new stuff. even if the new stuff is actually more simple, easier to use, and safer than the original. people seem to prefer to learn new immensely complex interfaces such as Windows or Java... beats me why!

you can get it from http://www.vitanuova.com/inferno/.

and it's not slow either.

Yes you'll need to audit that first limited OS and kernel, and yes it'll probably be in C, but let's limit the scope of that code severely. Plan to take a huge performance hit on running everything on that VM but make sure that it's totally secure, do whatever it takes to make sure that everything running on it is protected from itself and other programs. This is the only possible way to make an extensible operating system that is in any way secure, otherwise any software that is later added to the system will either need to be painstakingly audited or not installed. Performance should be a minor concern at this point as VMs can later be optimized, and security should be of prime importance.

this is exactly the approach taken by Inferno, which was designed and built by some of the best minds in computer science. (e.g. Dennis Ritchie, Rob Pike)

the approach works very well; the only downside is that because you are doing things better, they are different which means you actually have to learn some new stuff. even if the new stuff is actually more simple, easier to use, and safer than the original. people seem to prefer to learn new immensely complex interfaces such as Windows or Java... beats me why!

you can get it from http://www.vitanuova.com/inferno/.

and it's not slow either.

Many Plan 9 ers have lamented the loss of Alef. If you are interested in Alef like languages you should check out Limbo, the inferno programming language. Inferno runs hosted under Plan 9 and many other operating systems. There's even an browser plug-in so that you can run limbo apps in an Internet Explorer web-page!

plan 9 is cool (it's the OS that i use for development), but due to the usual difficulty of developing PC drivers (in particular graphics cards) it probably won't work with your existing h/w configuration.

however, as dennis says in the interview, most of plan 9's features are in Inferno. in fact, Inferno's is basically a slimmed down Plan 9 with virtual machine and a new language (Limbo) in which Ritchie has had a strong influence.

in lots of ways, Inferno is considerably more sleek than plan 9 - it is a real OS, but it's also a "virtual OS" that will run hosted under plan 9 or Windows or Linux or BSD or... the same programs run identically on all Inferno platforms.

there's even a version of Inferno that runs as a plug-in inside Internet Explorer on Windows! if you want to get a feel for it, there's even a shell prompt to play with for command line addicts. not to mention a few other little demos to get a feel for the performance of the thing. i'm afraid the plugin doesn't currently run under Netscape or platforms other than Linux, but the full download does.

Inferno and Plan 9 are both OSs "done right", maintaining a healthy balance between performance-related pragmatism and theoretical purity. compared to the tangled morass that is Java or any of the more recent Unix variants (and i'm afraid i don't exclude Linux), they're a breath of fresh air.

it was plan 9 which John Carmack once described as "achingly beautiful" and he's not wrong.

plan 9 is cool (it's the OS that i use for development), but due to the usual difficulty of developing PC drivers (in particular graphics cards) it probably won't work with your existing h/w configuration.

however, as dennis says in the interview, most of plan 9's features are in Inferno. in fact, Inferno's is basically a slimmed down Plan 9 with virtual machine and a new language (Limbo) in which Ritchie has had a strong influence.

in lots of ways, Inferno is considerably more sleek than plan 9 - it is a real OS, but it's also a "virtual OS" that will run hosted under plan 9 or Windows or Linux or BSD or... the same programs run identically on all Inferno platforms.

there's even a version of Inferno that runs as a plug-in inside Internet Explorer on Windows! if you want to get a feel for it, there's even a shell prompt to play with for command line addicts. not to mention a few other little demos to get a feel for the performance of the thing. i'm afraid the plugin doesn't currently run under Netscape or platforms other than Linux, but the full download does.

Inferno and Plan 9 are both OSs "done right", maintaining a healthy balance between performance-related pragmatism and theoretical purity. compared to the tangled morass that is Java or any of the more recent Unix variants (and i'm afraid i don't exclude Linux), they're a breath of fresh air.

it was plan 9 which John Carmack once described as "achingly beautiful" and he's not wrong.

plan 9 is cool (it's the OS that i use for development), but due to the usual difficulty of developing PC drivers (in particular graphics cards) it probably won't work with your existing h/w configuration.

however, as dennis says in the interview, most of plan 9's features are in Inferno. in fact, Inferno's is basically a slimmed down Plan 9 with virtual machine and a new language (Limbo) in which Ritchie has had a strong influence.

in lots of ways, Inferno is considerably more sleek than plan 9 - it is a real OS, but it's also a "virtual OS" that will run hosted under plan 9 or Windows or Linux or BSD or... the same programs run identically on all Inferno platforms.

there's even a version of Inferno that runs as a plug-in inside Internet Explorer on Windows! if you want to get a feel for it, there's even a shell prompt to play with for command line addicts. not to mention a few other little demos to get a feel for the performance of the thing. i'm afraid the plugin doesn't currently run under Netscape or platforms other than Linux, but the full download does.

Inferno and Plan 9 are both OSs "done right", maintaining a healthy balance between performance-related pragmatism and theoretical purity. compared to the tangled morass that is Java or any of the more recent Unix variants (and i'm afraid i don't exclude Linux), they're a breath of fresh air.

it was plan 9 which John Carmack once described as "achingly beautiful" and he's not wrong.

plan 9 is cool (it's the OS that i use for development), but due to the usual difficulty of developing PC drivers (in particular graphics cards) it probably won't work with your existing h/w configuration.

however, as dennis says in the interview, most of plan 9's features are in Inferno. in fact, Inferno's is basically a slimmed down Plan 9 with virtual machine and a new language (Limbo) in which Ritchie has had a strong influence.

in lots of ways, Inferno is considerably more sleek than plan 9 - it is a real OS, but it's also a "virtual OS" that will run hosted under plan 9 or Windows or Linux or BSD or... the same programs run identically on all Inferno platforms.

there's even a version of Inferno that runs as a plug-in inside Internet Explorer on Windows! if you want to get a feel for it, there's even a shell prompt to play with for command line addicts. not to mention a few other little demos to get a feel for the performance of the thing. i'm afraid the plugin doesn't currently run under Netscape or platforms other than Linux, but the full download does.

Inferno and Plan 9 are both OSs "done right", maintaining a healthy balance between performance-related pragmatism and theoretical purity. compared to the tangled morass that is Java or any of the more recent Unix variants (and i'm afraid i don't exclude Linux), they're a breath of fresh air.

it was plan 9 which John Carmack once described as "achingly beautiful" and he's not wrong.

plan 9 is cool (it's the OS that i use for development), but due to the usual difficulty of developing PC drivers (in particular graphics cards) it probably won't work with your existing h/w configuration.

however, as dennis says in the interview, most of plan 9's features are in Inferno. in fact, Inferno's is basically a slimmed down Plan 9 with virtual machine and a new language (Limbo) in which Ritchie has had a strong influence.

in lots of ways, Inferno is considerably more sleek than plan 9 - it is a real OS, but it's also a "virtual OS" that will run hosted under plan 9 or Windows or Linux or BSD or... the same programs run identically on all Inferno platforms.

there's even a version of Inferno that runs as a plug-in inside Internet Explorer on Windows! if you want to get a feel for it, there's even a shell prompt to play with for command line addicts. not to mention a few other little demos to get a feel for the performance of the thing. i'm afraid the plugin doesn't currently run under Netscape or platforms other than Linux, but the full download does.

Inferno and Plan 9 are both OSs "done right", maintaining a healthy balance between performance-related pragmatism and theoretical purity. compared to the tangled morass that is Java or any of the more recent Unix variants (and i'm afraid i don't exclude Linux), they're a breath of fresh air.

it was plan 9 which John Carmack once described as "achingly beautiful" and he's not wrong.

plan 9 is cool (it's the OS that i use for development), but due to the usual difficulty of developing PC drivers (in particular graphics cards) it probably won't work with your existing h/w configuration.

however, as dennis says in the interview, most of plan 9's features are in Inferno. in fact, Inferno's is basically a slimmed down Plan 9 with virtual machine and a new language (Limbo) in which Ritchie has had a strong influence.

in lots of ways, Inferno is considerably more sleek than plan 9 - it is a real OS, but it's also a "virtual OS" that will run hosted under plan 9 or Windows or Linux or BSD or... the same programs run identically on all Inferno platforms.

there's even a version of Inferno that runs as a plug-in inside Internet Explorer on Windows! if you want to get a feel for it, there's even a shell prompt to play with for command line addicts. not to mention a few other little demos to get a feel for the performance of the thing. i'm afraid the plugin doesn't currently run under Netscape or platforms other than Linux, but the full download does.

Inferno and Plan 9 are both OSs "done right", maintaining a healthy balance between performance-related pragmatism and theoretical purity. compared to the tangled morass that is Java or any of the more recent Unix variants (and i'm afraid i don't exclude Linux), they're a breath of fresh air.

it was plan 9 which John Carmack once described as "achingly beautiful" and he's not wrong.

plan 9 is cool (it's the OS that i use for development), but due to the usual difficulty of developing PC drivers (in particular graphics cards) it probably won't work with your existing h/w configuration.

however, as dennis says in the interview, most of plan 9's features are in Inferno. in fact, Inferno's is basically a slimmed down Plan 9 with virtual machine and a new language (Limbo) in which Ritchie has had a strong influence.

in lots of ways, Inferno is considerably more sleek than plan 9 - it is a real OS, but it's also a "virtual OS" that will run hosted under plan 9 or Windows or Linux or BSD or... the same programs run identically on all Inferno platforms.

there's even a version of Inferno that runs as a plug-in inside Internet Explorer on Windows! if you want to get a feel for it, there's even a shell prompt to play with for command line addicts. not to mention a few other little demos to get a feel for the performance of the thing. i'm afraid the plugin doesn't currently run under Netscape or platforms other than Linux, but the full download does.

Inferno and Plan 9 are both OSs "done right", maintaining a healthy balance between performance-related pragmatism and theoretical purity. compared to the tangled morass that is Java or any of the more recent Unix variants (and i'm afraid i don't exclude Linux), they're a breath of fresh air.

it was plan 9 which John Carmack once described as "achingly beautiful" and he's not wrong.

Rubbish - the type system is flawed and the syntax is ugly.

and before you ask - yes I DO know what I'm on about. I worked on a Validated Ada compiler. It was the most compact (lines of code) validated compiler of its day. I worked on several areas of validation suite compliance and an Ada Debugger.

I then went on to work on much more interesting things and a much more interesting and elegant language - Limbo