The VM does not just support a single language.
It executes Dis code, much as the Java virtual
machine executes Java byte code. There's nothing
to stop other languages using the VM.
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.
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.
Limbo programs are compiled to produce Dis executables. The plugin lets you run a Dis executable using a window on a web page for interaction with the user. When the Dis program runs it is running within the confines of the Inferno operating system with mouse, keyboard and screen connected to the web browser.
The program has no idea that it is running inside a web browser - the same program could run in any other Inferno platform.
Sun's Java2 plugin works in a similar
fashion, but connects to the Java 2 runtime
environment, bypassing the builting browser
Java runtime environment.
One big difference is that the Inferno application
cannot reach out and touch anything that it can't
already see in its Inferno sandbox.
> Throwing out new ideas with such little understanding is a great way to stand still.
Far from throwing out new ideas Limbo retains the strengths of C-like languages and introduces many new ideas. See the Limbo reference manual - written by Dennis Ritchie.
> As to where the Inferno kernel runs in regard to the Dis VM and the actual hardware, I'm not really sure.
Clearly the Dis VM is run inside the kernel. There are two kinds of Inferno kernel. The first kind runs directly on the hardware much like other operating systems - natively. The second, often refered to as a hosted kernel, runs on top of another operating system.
The hosted form is likely to be of interest to new users of Inferno. It runs as an application on, amongst others, Windows, Linux, Plan 9, Free/BSD and Solaris. The same Dis virtual machine runs in this virtual operating system - you can run the same programs unmodified, including the entire Limbo development environment. In its hosted form, the kernel uses the services of the hosting operating system. So for example, it uses the NT or Linux filesystem, it uses the X or Windows low level graphics primitives, it uses their networking services to reach the outside world. This means that it instantly leverages the effort that has been put into developing drivers for other operating systems such as Linux and NT.
An Inferno application doesn't need to know which kind of kernel it is running on - they all look the same to it. Take the Lego brick on the Vita Nuova website. This can be controlled by a Limbo application. That same Limbo application can be run from Windows, Linux, Plan 9, the screenphone on my desk (running native Inferno) or even from within a web page in Internet Explorer (using the Inferno plug-in) - without re-compiling it.
Don't think of it as a file in the filesystem. Best to think of it as a name in the namespace to which a piece of code is attached which gets called when you write to it or read from it. There doesn't have to be any kind of storage associated with the file. Don't see it as an inherent overhead - the system was designed to work efficiently that way.
A filesystem (in the traditional sense) is just the contents of another device mounted in the namespace - there's nothing special about it. Many Inferno systems either import their storage from another system or use flash or just don't need permanent storage.
It depends on the nature of the device and the level of the interface you want to present to the user. I agree that when working directly with the hardware at a low level it is often necessary to access them through the memory space, because that after all is where they are mapped. Inferno device drivers are written in C and access the hardware in such a fashion. What is nice is the flexibility that Inferno gives to device driver writers to present their device to the outside world.
If I'm using the serial port from an application it is much more attractive to be able to open a file and write data to it, or open a file and read from it - blocking until some data arrives than to mess around with polling memory locations or waiting for an interrupt. If I want to control the device (baud rate, handshaking etc) instead of ioctl() or similar specific system calls I write a well defined message to its control file. See the serial device man page. In fact, I could probably consider writing my simple application as a shell script.
It has other advantages too: the same technique works on all platforms - no need to change my application; no need to worry about byte ordering issues; I can use file system permissions to control access to my device.
But what if I haven't got a serial port? Not a problem either, just import one across the network from a machine that does, bind it into/dev as/dev/eia0,/dev/eia0ctl etc and run the same application. Not much use for ioctls and memory accesses here!
Presenting this information in the file namespace has many advantages. If an application can get a service such as DNS lookup by opening, writing and reading from a file then if a particular machine doesn't have such a service it can simply bind the file into its namespace from a machine which does and then the service is available.
A really great example of this is remote debugging. In Inferno everything needed to control a process for debugging is encapsulated in the '#p' prog device. It presents a subdirectory for each running process with control files in each directory. The ps command and the debugger use this device which is conventionally bound into/prog. To debug a process running on, say, my screenphone which serves Styx on a serial port I just run mount/dev/eia0/n/phone bind/n/phone/prog/prog and now `ps' will show me all the processes running on the phone and the debugger will let me debug them.
It boils down to letting the device driver writer make sensible decisions about which services are made visible to its users and how they are presented.
I couldn't disagree more. I have worked with a lot of programmers whose background is rooted in C. They have all experienced the C++ and Java euphoria and come out of it wondering what all the excitement was about - me included.
Limbo was a breath of fresh air. It retains the salient and useful parts of the C language. It is surprising how easy it is to port C applications to Limbo. Take, as an example, the code from the `cat' command to copy a file to standard output:
It isn't going to take a C programmer long to work out what is going on there. They might notice that the file isn't closed - but thats because its closed automatically when `fd' goes out of scope (when the function returns). They might notice that the array of bytes pointed to by `buf' is never freed - but that happens automatically the instant that `buf' goes out of scope. I can still do anything to `buf' that I might want to do to it in a C program: copy it, slice it, change it, even pass it down a channel to another thread but it will be freed instantly the minute the last reference to it goes away. I find that little things like this combined with the clean, fresh, minimalist nature of the language and operating system make it a pleasure to work in. Oh, and strings are a basic type too - its C without the headaches!
The source for all the system commands is included with Inferno - in fact its freely distributable.
The limbo reference manual (written by Dennis Ritchie) is also very precise in its definition of the language.
Apart from the two things that you mention the one big difference is that it can run as a virtual operating system - i.e. as an application within Plan 9, Linux, Windows, etc.
Programs running under Inferno neither know nor care whether they are running natively or hosted on one of these operating systems.
Vita Nuova has an Inferno plug-in for Internet Explorer which allows a Dis (Compiled Limbo) program to run in a window in a web page. The same compiled program can run (without re-compilation) under Inferno on, say Linux, or on one of the web-phones here in the office.
It has been very popular with some Far Eastern companies as the native operating system for their webphones. Probably partly due to the slick way that Limbo and Tk work together to provide the graphics in a very small footprint. I think too that the fact that you can run native inferno in a device like a phone and run Inferno emulated on, say Windows, and then mount the namespace from the phone into your Windows Inferno make application development and debugging much easier. Your phone applications can also run in an identical environment under Windows, Linux, Plan 9 for testing.
I use the Acme development environment (which both Inferno and Plan 9 have) as my editor of choice on Linux, Windows and Plan 9.
Yes. They were developed by more or less the same set of developers at Bell Labs. Inferno came along after Plan 9 and includes the virtual machine and Limbo programming language which are not present in Plan 9. There is a lot of similarity at the source code level in the kernel and anyone familiar with the Plan 9 kernel would quickly get to grips with Inferno kernel development. They share the same C cross-compiler suite for a variety of machine architectures. One big difference, though, is that Inferno can run as a hosted operating system on Plan 9, Linux, Free/BSD, Windows, Solaris, and others as well as running natively in its own right.
Slashdot Mirror
> One of our key products that is a very intensive search app outperforms every other company on the web today.
That must have taken some time to verify.
The VM does not just support a single language. It executes Dis code, much as the Java virtual machine executes Java byte code. There's nothing to stop other languages using the VM.
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:
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.
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.
Sun's Java2 plugin works in a similar fashion, but connects to the Java 2 runtime environment, bypassing the builting browser Java runtime environment.
One big difference is that the Inferno application cannot reach out and touch anything that it can't already see in its Inferno sandbox.
No, its an operating system. It's true it has a virtual machine, but it's an operating system.
Far from throwing out new ideas Limbo retains the strengths of C-like languages and introduces many new ideas.
See the Limbo reference manual - written by Dennis Ritchie.
Clearly the Dis VM is run inside the kernel. There are two kinds of Inferno kernel. The first kind runs directly on the hardware much like other operating systems - natively. The second, often refered to as a hosted kernel, runs on top of another operating system.
The hosted form is likely to be of interest to new users of Inferno. It runs as an application on, amongst others, Windows, Linux, Plan 9, Free/BSD and Solaris. The same Dis virtual machine runs in this virtual operating system - you can run the same programs unmodified, including the entire Limbo development environment. In its hosted form, the kernel uses the services of the hosting operating system. So for example, it uses the NT or Linux filesystem, it uses the X or Windows low level graphics primitives, it uses their networking services to reach the outside world. This means that it instantly leverages the effort that has been put into developing drivers for other operating systems such as Linux and NT.
An Inferno application doesn't need to know which kind of kernel it is running on - they all look the same to it. Take the Lego brick on the Vita Nuova website. This can be controlled by a Limbo application. That same Limbo application can be run from Windows, Linux, Plan 9, the screenphone on my desk (running native Inferno) or even from within a web page in Internet Explorer (using the Inferno plug-in) - without re-compiling it.
A filesystem (in the traditional sense) is just the contents of another device mounted in the namespace - there's nothing special about it. Many Inferno systems either import their storage from another system or use flash or just don't need permanent storage.
If I'm using the serial port from an application it is much more attractive to be able to open a file and write data to it, or open a file and read from it - blocking until some data arrives than to mess around with polling memory locations or waiting for an interrupt. If I want to control the device (baud rate, handshaking etc) instead of ioctl() or similar specific system calls I write a well defined message to its control file. See the serial device man page. In fact, I could probably consider writing my simple application as a shell script.
It has other advantages too: the same technique works on all platforms - no need to change my application; no need to worry about byte ordering issues; I can use file system permissions to control access to my device.
But what if I haven't got a serial port? Not a problem either, just import one across the network from a machine that does, bind it into /dev as /dev/eia0, /dev/eia0ctl etc and run the same application. Not much use for ioctls and memory accesses here!
Presenting this information in the file namespace has many advantages. If an application can get a service such as DNS lookup by opening, writing and reading from a file then if a particular machine doesn't have such a service it can simply bind the file into its namespace from a machine which does and then the service is available.
A really great example of this is remote debugging. In Inferno everything needed to control a process for debugging is encapsulated in the '#p' prog device. It presents a subdirectory for each running process with control files in each directory. The ps command and the debugger use this device which is conventionally bound into /prog. To debug a process running on, say, my screenphone which serves Styx on a serial port I just run /dev/eia0 /n/phone /n/phone/prog /prog
mount
bind
and now `ps' will show me all the processes running on the phone and the debugger will let me debug them.
It boils down to letting the device driver writer make sensible decisions about which services are made visible to its users and how they are presented.
Broadcom and Umec both use Inferno natively as the operating system for their newest webphones.
I couldn't disagree more.
:= array[8192] of byte;
I have worked with a lot of programmers whose background is rooted in C. They have all experienced the C++ and Java euphoria and come out of it wondering what all the excitement was about - me included.
Limbo was a breath of fresh air. It retains the salient and useful parts of the C language. It is surprising how easy it is to port C applications to Limbo. Take, as an example, the code from the `cat' command to copy a file to standard output:
cat(file: string)
{
n: int;
fd: ref FD;
buf
if(file == "-")
fd = fildes(0);
else {
fd = open(file, OREAD);
if(fd == nil) {
fprint(fildes(2), "cat: cannot open %s: %r\n", file);
raise("fail: bad open");
}
}
for(;;) {
n = read(fd, buf, len buf);
if(n <= 0)
break;
if(write(stdout, buf, n) < n) {
fprint(fildes(2), "cat: write error: %r\n");
raise("fail:write error");
}
}
if(n < 0) {
fprint(fildes(2), "cat: read error: %r\n");
raise("fail:read error");
}
}
It isn't going to take a C programmer long to work out what is going on there.
They might notice that the file isn't closed - but thats because its closed automatically when `fd' goes out of scope (when the function returns).
They might notice that the array of bytes pointed to by `buf' is never freed - but that happens automatically the instant that `buf' goes out of scope. I can still do anything to `buf' that I might want to do to it in a C program: copy it, slice it, change it, even pass it down a channel to another thread but it will be freed instantly the minute the last reference to it goes away. I find that little things like this combined with the clean, fresh, minimalist nature of the language and operating system make it a pleasure to work in.
Oh, and strings are a basic type too - its C without the headaches!
The source for all the system commands is included with Inferno - in fact its freely distributable.
The limbo reference manual (written by Dennis Ritchie) is also very precise in its definition of the language.
I'm not sure that they were looking for it!
Programs running under Inferno neither know nor care whether they are running natively or hosted on one of these operating systems.
Vita Nuova has an Inferno plug-in for Internet Explorer which allows a Dis (Compiled Limbo) program to run in a window in a web page. The same compiled program can run (without re-compilation) under Inferno on, say Linux, or on one of the web-phones here in the office.
I expect to see them working more closely together now that they have both been made generally available.
I use the Acme development environment (which both Inferno and Plan 9 have) as my editor of choice on Linux, Windows and Plan 9.
Yes. They were developed by more or less the same set of developers at Bell Labs. Inferno came along after Plan 9 and includes the virtual machine and Limbo programming language which are not present in Plan 9. There is a lot of similarity at the source code level in the kernel and anyone familiar with the Plan 9 kernel would quickly get to grips with Inferno kernel development. They share the same C cross-compiler suite for a variety of machine architectures. One big difference, though, is that Inferno can run as a hosted operating system on Plan 9, Linux, Free/BSD, Windows, Solaris, and others as well as running natively in its own right.