Slashdot Mirror

sometimes doing a bit more work is worth it for the other benefits it provides (we're talking about a system that uses a VM here!). if you want to avoid runaway memory usage (and in the process improve cache performance and necessity for swap/paging) then ref counting is the way to go.

Inferno uses this technique (actually it uses a generational GC as well to catch the more unusual circular references) and we can happily run a system doing useful stuff (shell, GUI apps, etc) in 512K of RAM.

as any real-time afficionado will tell you, predictability is often more important than raw performance - and that's what ref counting gives you. most OS paging algorithms are designed around the concept of a "working set" of memory that a process needs to be able to compute with. conventional GC often works to foil this approach.

cheers,
rog.

i'll keep plugging this 'cos i think it deserves attention. i would do so even if i wasn't working for the company...

Limbo which has a similar thread-communication model to Occam's (if anyone's heard of Occam... no, thought not).

it uses synchronous channels:

somefunction()
{
ch := chan of int;
spawn otherfunction(ch);
ch <-= 99; # send value down channel
}

otherfunction(ch: chan of int)
{
print("received %d\n", <-ch);
}
easy to use, and easy to reason about. one thread blocks until the other has received the value, hence the primitive can be used for locking, etc.(sorry, can't remember how to do indentation in html...)

well said. C's my 2nd favourite language. i used Objective-C for about 6 years and came across all the problems with its object model that i can see all too clearly in Java.

if you're interested in new languages, check out Limbo. IMHO it has all the simplicity and power that you're after, and its well designed semantics mean that programs are generally easy to debug and easy to maintain. the APIs are almost without exception very well designed and "as simple as possible without being too simple"...

it's a concurrent language and has a threading model that isn't based on archaic 1970s technology unlike Ja^H^Hsome other languages.

plus programs will run without change (unconditionally) on linux, bsd, plan 9, windows and on several native platforms (e.g. the Ipaq)

if you have access to a Windows system with internet explorer, there's plugin that allows you to play around with some demos (source code included), or you can download a version for another platform (only that one's 14MB, ouch).

it's a beautiful language, and that can't be said of many...

well said. C's my 2nd favourite language. i used Objective-C for about 6 years and came across all the problems with its object model that i can see all too clearly in Java.

if you're interested in new languages, check out Limbo. IMHO it has all the simplicity and power that you're after, and its well designed semantics mean that programs are generally easy to debug and easy to maintain. the APIs are almost without exception very well designed and "as simple as possible without being too simple"...

it's a concurrent language and has a threading model that isn't based on archaic 1970s technology unlike Ja^H^Hsome other languages.

plus programs will run without change (unconditionally) on linux, bsd, plan 9, windows and on several native platforms (e.g. the Ipaq)

if you have access to a Windows system with internet explorer, there's plugin that allows you to play around with some demos (source code included), or you can download a version for another platform (only that one's 14MB, ouch).

it's a beautiful language, and that can't be said of many...

well said. C's my 2nd favourite language. i used Objective-C for about 6 years and came across all the problems with its object model that i can see all too clearly in Java.

if you're interested in new languages, check out Limbo. IMHO it has all the simplicity and power that you're after, and its well designed semantics mean that programs are generally easy to debug and easy to maintain. the APIs are almost without exception very well designed and "as simple as possible without being too simple"...

it's a concurrent language and has a threading model that isn't based on archaic 1970s technology unlike Ja^H^Hsome other languages.

plus programs will run without change (unconditionally) on linux, bsd, plan 9, windows and on several native platforms (e.g. the Ipaq)

if you have access to a Windows system with internet explorer, there's plugin that allows you to play around with some demos (source code included), or you can download a version for another platform (only that one's 14MB, ouch).

it's a beautiful language, and that can't be said of many...

i disagree. the java socket interface is not abstracted enough. it's still tied to TCP/IP. plan 9 and inferno have the cleanest networking interface i've seen.

want to make a connection?

connection := sys->dial("tcp!slashdot.org!httpd");

that's all! the address is a string with a protocol explicitly mentioned, so can easily be passed in dynamically as an argument. the program itself is protocol independent. if i had an ATM interface, i could use "atm!someATMaddress!56446" and the program would continue to work unchanged. IPV6? no problem, just change the underlying implementation...

not to mention the fact that access is through a filesystem-like abstraction - the actual network interface might not even be on the local machine...

of course, i'm completely biased, as i work for the company (Vita Nuova) that distributes it. it's not as bad as it might seem though, because the only reason i went for this job was that i'd already fallen in love with the language! but seriously, Limbo is a truly excellent language which, like Java, takes much of its heritage from C but, unlike Java, gets the fundamental language design right.

i know that Java is here to stay, but if you've done much Java programming, you'll know that there are reasons why you might want to keep an eye on alternatives. Limbo is a language that C programmers will like but C++ programmers will probably hate. there's no object-hierarchy! so you actually know what code is being invoked by a function call. debugging code does not require an intimate knowledge of obscure class hierarchies.

o it's completely type-safe. unlike java, it's impossible to get a run-time type exception.
o the syntax is very readable, but terse enough not to frustrate a C programmer...
o the type system is rich enough to make data-structures easy to create and manipulate, and the type syntax is beautifully clear. consider:
x: list of array of (string, int);
o memory management is automatic (garbage collected) but unlike most other GC languages, memory usage is economical and predictable, because almost all data structures are collected by reference counting. so when memory is tight, you have tight control on what memory is allocated, and when it's freed.
o and best of all, programs written in Limbo are completely portable, because they're surrounded by an entire virtual operating system, Inferno.

i could rant on for ages about nice aspects of the system, which is not surprising, given the people involved in its creation (Rob Pike and Dennis Ritchie amongst others).

anyway, we've had a free download available for some time, but our resident Windows-head has just come up with an Internet Explorer plug-in that runs Inferno inside a web page. the download is under 720K.

we've had fun coming up with a few demo programs so you can see how it performs compared to Java and what a typical Limbo program looks like. you can even even get a shell prompt inside IE. (not that you can do a lot from it, as it's sandboxed...).

have fun! and bear in mind that the binaries of these programs will run unchanged under any incarnation of inferno... the "applet" API is identical to the normal one.

i hope that at least some people will Get It...

cheers, rog.
PS. i'm sorry we don't have a linux or netscape version, but we will have!

of course, i'm completely biased, as i work for the company (Vita Nuova) that distributes it. it's not as bad as it might seem though, because the only reason i went for this job was that i'd already fallen in love with the language! but seriously, Limbo is a truly excellent language which, like Java, takes much of its heritage from C but, unlike Java, gets the fundamental language design right.

i know that Java is here to stay, but if you've done much Java programming, you'll know that there are reasons why you might want to keep an eye on alternatives. Limbo is a language that C programmers will like but C++ programmers will probably hate. there's no object-hierarchy! so you actually know what code is being invoked by a function call. debugging code does not require an intimate knowledge of obscure class hierarchies.

o it's completely type-safe. unlike java, it's impossible to get a run-time type exception.
o the syntax is very readable, but terse enough not to frustrate a C programmer...
o the type system is rich enough to make data-structures easy to create and manipulate, and the type syntax is beautifully clear. consider:
x: list of array of (string, int);
o memory management is automatic (garbage collected) but unlike most other GC languages, memory usage is economical and predictable, because almost all data structures are collected by reference counting. so when memory is tight, you have tight control on what memory is allocated, and when it's freed.
o and best of all, programs written in Limbo are completely portable, because they're surrounded by an entire virtual operating system, Inferno.

i could rant on for ages about nice aspects of the system, which is not surprising, given the people involved in its creation (Rob Pike and Dennis Ritchie amongst others).

anyway, we've had a free download available for some time, but our resident Windows-head has just come up with an Internet Explorer plug-in that runs Inferno inside a web page. the download is under 720K.

we've had fun coming up with a few demo programs so you can see how it performs compared to Java and what a typical Limbo program looks like. you can even even get a shell prompt inside IE. (not that you can do a lot from it, as it's sandboxed...).

have fun! and bear in mind that the binaries of these programs will run unchanged under any incarnation of inferno... the "applet" API is identical to the normal one.

i hope that at least some people will Get It...

cheers, rog.
PS. i'm sorry we don't have a linux or netscape version, but we will have!

of course, i'm completely biased, as i work for the company (Vita Nuova) that distributes it. it's not as bad as it might seem though, because the only reason i went for this job was that i'd already fallen in love with the language! but seriously, Limbo is a truly excellent language which, like Java, takes much of its heritage from C but, unlike Java, gets the fundamental language design right.

i know that Java is here to stay, but if you've done much Java programming, you'll know that there are reasons why you might want to keep an eye on alternatives. Limbo is a language that C programmers will like but C++ programmers will probably hate. there's no object-hierarchy! so you actually know what code is being invoked by a function call. debugging code does not require an intimate knowledge of obscure class hierarchies.

o it's completely type-safe. unlike java, it's impossible to get a run-time type exception.
o the syntax is very readable, but terse enough not to frustrate a C programmer...
o the type system is rich enough to make data-structures easy to create and manipulate, and the type syntax is beautifully clear. consider:
x: list of array of (string, int);
o memory management is automatic (garbage collected) but unlike most other GC languages, memory usage is economical and predictable, because almost all data structures are collected by reference counting. so when memory is tight, you have tight control on what memory is allocated, and when it's freed.
o and best of all, programs written in Limbo are completely portable, because they're surrounded by an entire virtual operating system, Inferno.

i could rant on for ages about nice aspects of the system, which is not surprising, given the people involved in its creation (Rob Pike and Dennis Ritchie amongst others).

anyway, we've had a free download available for some time, but our resident Windows-head has just come up with an Internet Explorer plug-in that runs Inferno inside a web page. the download is under 720K.

we've had fun coming up with a few demo programs so you can see how it performs compared to Java and what a typical Limbo program looks like. you can even even get a shell prompt inside IE. (not that you can do a lot from it, as it's sandboxed...).

have fun! and bear in mind that the binaries of these programs will run unchanged under any incarnation of inferno... the "applet" API is identical to the normal one.

i hope that at least some people will Get It...

cheers, rog.
PS. i'm sorry we don't have a linux or netscape version, but we will have!

of course, i'm completely biased, as i work for the company (Vita Nuova) that distributes it. it's not as bad as it might seem though, because the only reason i went for this job was that i'd already fallen in love with the language! but seriously, Limbo is a truly excellent language which, like Java, takes much of its heritage from C but, unlike Java, gets the fundamental language design right.

i know that Java is here to stay, but if you've done much Java programming, you'll know that there are reasons why you might want to keep an eye on alternatives. Limbo is a language that C programmers will like but C++ programmers will probably hate. there's no object-hierarchy! so you actually know what code is being invoked by a function call. debugging code does not require an intimate knowledge of obscure class hierarchies.

o it's completely type-safe. unlike java, it's impossible to get a run-time type exception.
o the syntax is very readable, but terse enough not to frustrate a C programmer...
o the type system is rich enough to make data-structures easy to create and manipulate, and the type syntax is beautifully clear. consider:
x: list of array of (string, int);
o memory management is automatic (garbage collected) but unlike most other GC languages, memory usage is economical and predictable, because almost all data structures are collected by reference counting. so when memory is tight, you have tight control on what memory is allocated, and when it's freed.
o and best of all, programs written in Limbo are completely portable, because they're surrounded by an entire virtual operating system, Inferno.

i could rant on for ages about nice aspects of the system, which is not surprising, given the people involved in its creation (Rob Pike and Dennis Ritchie amongst others).

anyway, we've had a free download available for some time, but our resident Windows-head has just come up with an Internet Explorer plug-in that runs Inferno inside a web page. the download is under 720K.

we've had fun coming up with a few demo programs so you can see how it performs compared to Java and what a typical Limbo program looks like. you can even even get a shell prompt inside IE. (not that you can do a lot from it, as it's sandboxed...).

have fun! and bear in mind that the binaries of these programs will run unchanged under any incarnation of inferno... the "applet" API is identical to the normal one.

i hope that at least some people will Get It...

cheers, rog.
PS. i'm sorry we don't have a linux or netscape version, but we will have!

of course, i'm completely biased, as i work for the company (Vita Nuova) that distributes it. it's not as bad as it might seem though, because the only reason i went for this job was that i'd already fallen in love with the language! but seriously, Limbo is a truly excellent language which, like Java, takes much of its heritage from C but, unlike Java, gets the fundamental language design right.

i know that Java is here to stay, but if you've done much Java programming, you'll know that there are reasons why you might want to keep an eye on alternatives. Limbo is a language that C programmers will like but C++ programmers will probably hate. there's no object-hierarchy! so you actually know what code is being invoked by a function call. debugging code does not require an intimate knowledge of obscure class hierarchies.

o it's completely type-safe. unlike java, it's impossible to get a run-time type exception.
o the syntax is very readable, but terse enough not to frustrate a C programmer...
o the type system is rich enough to make data-structures easy to create and manipulate, and the type syntax is beautifully clear. consider:
x: list of array of (string, int);
o memory management is automatic (garbage collected) but unlike most other GC languages, memory usage is economical and predictable, because almost all data structures are collected by reference counting. so when memory is tight, you have tight control on what memory is allocated, and when it's freed.
o and best of all, programs written in Limbo are completely portable, because they're surrounded by an entire virtual operating system, Inferno.

i could rant on for ages about nice aspects of the system, which is not surprising, given the people involved in its creation (Rob Pike and Dennis Ritchie amongst others).

anyway, we've had a free download available for some time, but our resident Windows-head has just come up with an Internet Explorer plug-in that runs Inferno inside a web page. the download is under 720K.

we've had fun coming up with a few demo programs so you can see how it performs compared to Java and what a typical Limbo program looks like. you can even even get a shell prompt inside IE. (not that you can do a lot from it, as it's sandboxed...).

have fun! and bear in mind that the binaries of these programs will run unchanged under any incarnation of inferno... the "applet" API is identical to the normal one.

i hope that at least some people will Get It...

cheers, rog.
PS. i'm sorry we don't have a linux or netscape version, but we will have!

of course, i'm completely biased, as i work for the company (Vita Nuova) that distributes it. it's not as bad as it might seem though, because the only reason i went for this job was that i'd already fallen in love with the language! but seriously, Limbo is a truly excellent language which, like Java, takes much of its heritage from C but, unlike Java, gets the fundamental language design right.

i know that Java is here to stay, but if you've done much Java programming, you'll know that there are reasons why you might want to keep an eye on alternatives. Limbo is a language that C programmers will like but C++ programmers will probably hate. there's no object-hierarchy! so you actually know what code is being invoked by a function call. debugging code does not require an intimate knowledge of obscure class hierarchies.

o it's completely type-safe. unlike java, it's impossible to get a run-time type exception.
o the syntax is very readable, but terse enough not to frustrate a C programmer...
o the type system is rich enough to make data-structures easy to create and manipulate, and the type syntax is beautifully clear. consider:
x: list of array of (string, int);
o memory management is automatic (garbage collected) but unlike most other GC languages, memory usage is economical and predictable, because almost all data structures are collected by reference counting. so when memory is tight, you have tight control on what memory is allocated, and when it's freed.
o and best of all, programs written in Limbo are completely portable, because they're surrounded by an entire virtual operating system, Inferno.

i could rant on for ages about nice aspects of the system, which is not surprising, given the people involved in its creation (Rob Pike and Dennis Ritchie amongst others).

anyway, we've had a free download available for some time, but our resident Windows-head has just come up with an Internet Explorer plug-in that runs Inferno inside a web page. the download is under 720K.

we've had fun coming up with a few demo programs so you can see how it performs compared to Java and what a typical Limbo program looks like. you can even even get a shell prompt inside IE. (not that you can do a lot from it, as it's sandboxed...).

have fun! and bear in mind that the binaries of these programs will run unchanged under any incarnation of inferno... the "applet" API is identical to the normal one.

i hope that at least some people will Get It...

cheers, rog.
PS. i'm sorry we don't have a linux or netscape version, but we will have!

of course, i'm completely biased, as i work for the company (Vita Nuova) that distributes it. it's not as bad as it might seem though, because the only reason i went for this job was that i'd already fallen in love with the language! but seriously, Limbo is a truly excellent language which, like Java, takes much of its heritage from C but, unlike Java, gets the fundamental language design right.

i know that Java is here to stay, but if you've done much Java programming, you'll know that there are reasons why you might want to keep an eye on alternatives. Limbo is a language that C programmers will like but C++ programmers will probably hate. there's no object-hierarchy! so you actually know what code is being invoked by a function call. debugging code does not require an intimate knowledge of obscure class hierarchies.

o it's completely type-safe. unlike java, it's impossible to get a run-time type exception.
o the syntax is very readable, but terse enough not to frustrate a C programmer...
o the type system is rich enough to make data-structures easy to create and manipulate, and the type syntax is beautifully clear. consider:
x: list of array of (string, int);
o memory management is automatic (garbage collected) but unlike most other GC languages, memory usage is economical and predictable, because almost all data structures are collected by reference counting. so when memory is tight, you have tight control on what memory is allocated, and when it's freed.
o and best of all, programs written in Limbo are completely portable, because they're surrounded by an entire virtual operating system, Inferno.

i could rant on for ages about nice aspects of the system, which is not surprising, given the people involved in its creation (Rob Pike and Dennis Ritchie amongst others).

anyway, we've had a free download available for some time, but our resident Windows-head has just come up with an Internet Explorer plug-in that runs Inferno inside a web page. the download is under 720K.

we've had fun coming up with a few demo programs so you can see how it performs compared to Java and what a typical Limbo program looks like. you can even even get a shell prompt inside IE. (not that you can do a lot from it, as it's sandboxed...).

have fun! and bear in mind that the binaries of these programs will run unchanged under any incarnation of inferno... the "applet" API is identical to the normal one.

i hope that at least some people will Get It...

cheers, rog.
PS. i'm sorry we don't have a linux or netscape version, but we will have!

of course, i'm completely biased, as i work for the company (Vita Nuova) that distributes it. it's not as bad as it might seem though, because the only reason i went for this job was that i'd already fallen in love with the language! but seriously, Limbo is a truly excellent language which, like Java, takes much of its heritage from C but, unlike Java, gets the fundamental language design right.

i know that Java is here to stay, but if you've done much Java programming, you'll know that there are reasons why you might want to keep an eye on alternatives. Limbo is a language that C programmers will like but C++ programmers will probably hate. there's no object-hierarchy! so you actually know what code is being invoked by a function call. debugging code does not require an intimate knowledge of obscure class hierarchies.

o it's completely type-safe. unlike java, it's impossible to get a run-time type exception.
o the syntax is very readable, but terse enough not to frustrate a C programmer...
o the type system is rich enough to make data-structures easy to create and manipulate, and the type syntax is beautifully clear. consider:
x: list of array of (string, int);
o memory management is automatic (garbage collected) but unlike most other GC languages, memory usage is economical and predictable, because almost all data structures are collected by reference counting. so when memory is tight, you have tight control on what memory is allocated, and when it's freed.
o and best of all, programs written in Limbo are completely portable, because they're surrounded by an entire virtual operating system, Inferno.

i could rant on for ages about nice aspects of the system, which is not surprising, given the people involved in its creation (Rob Pike and Dennis Ritchie amongst others).

anyway, we've had a free download available for some time, but our resident Windows-head has just come up with an Internet Explorer plug-in that runs Inferno inside a web page. the download is under 720K.

we've had fun coming up with a few demo programs so you can see how it performs compared to Java and what a typical Limbo program looks like. you can even even get a shell prompt inside IE. (not that you can do a lot from it, as it's sandboxed...).

have fun! and bear in mind that the binaries of these programs will run unchanged under any incarnation of inferno... the "applet" API is identical to the normal one.

i hope that at least some people will Get It...

cheers, rog.
PS. i'm sorry we don't have a linux or netscape version, but we will have!

Its not. Its a pain in the ass
I'm almost glad to hear it but it's sad that the two widget kits are so awkward.

I've used MFC & the Windows API and the best thing I found to do was to make ActiveX Controls for the logic and Visual Basic for the UI then you get the best of both worlds - and the worst of course.

The winner of course though is *nix 'cos you've got so many to choose from. Non-standard Windows controls make a program clunky no matter how uch better it make the programming. The days or Borlands OWL stuff and non-standard buttons (standard meaning native) just felt plain wrong.

I've tried wxWindows with Python and that was interesting.

What has anyone else tried for fun and seen some promise in?

Obviously the *nix world offers more potential for experimentation with it's abstraction of machine from display.

I'm hoping to start a project on Inferno with it's blend of TK and Limbo (a wierd pascal / c hybrid).

I'm also keep an eye on the Berlin Project with it's 3d co-ordinate system and transparent windows.

Anyone got any direct experience with those two?
.oO0Oo.

because unix-style documentation is concise, clear, and tells you what you need to know?

and because it's infinitely better than the style of reference documentation found all too often these days, in tutorial style, telling you randomly distributed pieces of information that you need to know, but will never be able to find again...

the unix reference-manual style might require a certain amount of knowledge as a pre-requisite ("you mean i actually have to read the intro?!"), but for conveying to the reader the specifics of how to use components of a system, i've not seen anything to beat it.

for overview and tutorial information on how the various components fit together, there are various papers which try to provide this. (and more to come, when we get some space away from software development to work on documentation, yum!)

cheers, rog.

The only reason Inferno made it into this Slashback was the fact that Inferno can run on a Lego brick. Pathetic.

Inferno is a virtual OS that runs on many platforms, including tiny ones like Web phones. It even has its own programming language which is C-like, runs in a VM and has often been compared to Java.

Hmmm the lack of technical info on C# looks asif they have rushed this press release out rather quickly. One wonders if they are trying to detract from Inferno???

you didn't miss it. we haven't put the binaries out yet. we're going to do so very soon. as with all these things, we're up against a very tight schedule, and have been spending most of the last couple of months writing the manuals... blah blah blah, i hate doing documentation! still, it's almost all done now (and online) and we're going to make the binaries available any time soon.

not forgetting that it's only the core VM source that is part of the "subscriber" arrangement and binary only if you haven't paid your $300; everything else in the system is Open Source, including the web browser, all the apps (over 200000 lines of code), and the build tools.

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.

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.

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.

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.

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.

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.

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 dunno whether you're talking about plan 9 or inferno there. plan 9's got a great gui - it just doesn't fit into how our microsoft-warped brains think a GUI should look like.

inferno however... well, the GUI does need a bit of looking at. and i am looking at it! i'm currently working on the window manager, which was written a few years ago in a weekend and hasn't changed much since.

but it's not a big job. applications aren't heavily tied into the look and feel of the GUI, which makes for less bloated apps. the main GUI is based on a variant of tk which means that the underlying GUI code can be changed in one place, and the whole feel of the thing changes. inferno hasn't had any hardcore graphics designers let loose on it, but if it did, believe me, it could look beautiful!

inferno isn't great because of its GUI, but because of what's underneath. look at the lego brick demo for a flavour of what can be done with devices under inferno.

we've got all the manual pages on line, so if you're interested in techie details about the system, you can see them here.

i dunno whether you're talking about plan 9 or inferno there. plan 9's got a great gui - it just doesn't fit into how our microsoft-warped brains think a GUI should look like.

inferno however... well, the GUI does need a bit of looking at. and i am looking at it! i'm currently working on the window manager, which was written a few years ago in a weekend and hasn't changed much since.

but it's not a big job. applications aren't heavily tied into the look and feel of the GUI, which makes for less bloated apps. the main GUI is based on a variant of tk which means that the underlying GUI code can be changed in one place, and the whole feel of the thing changes. inferno hasn't had any hardcore graphics designers let loose on it, but if it did, believe me, it could look beautiful!

inferno isn't great because of its GUI, but because of what's underneath. look at the lego brick demo for a flavour of what can be done with devices under inferno.

we've got all the manual pages on line, so if you're interested in techie details about the system, you can see them here.

as far as performance goes, there's also the fact that there hasn't yet been a great deal of work done optimizing the compiler output or the JIT (i.e. currently the JIT does little registerisation, where the design of the DIS VM means that registerisation should be relatively easy to do - see this). i have a feeling that it's quite a lot faster than most java versions.

what's it good for? all sorts of things. it's a really clean environment to write programs in. where plan 9 is really clean in the namespace and the system interface, but still uses C as the application programming language, Inferno has all that, but uses Limbo as the language with Dis underneath.

the main advantage it gives you when writing programs is that your programs are unconditionally portable - if i've written a Limbo program to run on a screen phone (bare hardware, ARM SA1100) then, assuming enough memory, i have no doubts about it running perfectly on any other platform on which Inferno is supported.

that, coupled with the fact that limbo is a really, really nice language means that i don't want to develop for anything else. i started off as a C developer about 10 years ago, managed to escape Ingres (eugh) after a couple of years, hacked some Occam (which is a nice language, but somewhat limited in its type system), ended up in Objective-C under NeXTstep/Openstep/(macosX?). so i've hacked in a number of languages, and Limbo wins hands down.

why? it's difficult to say. it's a combination of many factors that all go to make up for a thoroughly enjoyable programming experience. i love C (not C++ though!) and it keeps the "power at your fingertips" feel that you get with C, but without pointers, with garbage collection, with complete type safety... perhaps the main feature is that when you read a Limbo program, you can actually tell what it's doing! (shock horror). all the names that are accessible to a fragment of code are easily findable. there's no overloading. the OO paradigm works entirely around aggregation - no inheritance whatsoever. the inbuilt types work really nicely - value types mean that in a multi-threaded environment, which Inferno/Limbo is, you are utterly certain that a value can't be changed underneath you).

what programs are for it? well, there's a web browser, but if you're running it hosted, then you'll probably have one anyway (that doesn't have to conform to the restriction of needing to run in 4MB). i've written what i think is a fairly cool programmable shell for it which is pretty small as well (main binary for it is 36K). i also wrote a passable version of Tetris (which is great 'cos now i can play the same version against people in the office running windows, linux, plan 9 and screenphones!), and i'm finishing off a pretty nice FIBS client. most of that stuff i did in my spare time. there's a version of Acme that's been ported, so you can see how the original compares to Wily.

how easily can you port programs from *NIX? (shouldn't that be *N[UI]X ? :-]) depends on what sort of program you're talking about. what inferno does *not* have (and this is the reason it's so small) is all the legacy stuff that *NIX has picked up over the years. this it has in common with plan 9. it does not have cursor addressing programs (although i wouldn't mind porting a decent vt100 emulator). it does not have termcap/terminfo/curses/ioctl/fcntl or sockets. so porting anything that relies on that stuff (e.g. emacs, slrn) won't be at all easy. BUT, straight C usually goes very nicely into Limbo. most of the standard unix command line programs (i.e. the ones that just munge stdin to stdout) go fine. The Limbo arithmetic expression syntax uses the same precedence rules as C, so all those nightmare mathematical equations are little problem (unless they've got dodgy type promotion going on, which you want to know about anyway).

the best thing about inferno is that it's a truly component oriented architecture. OO systems with inheritance don't give you that as there's too much interdependence between objects at different levels. Limbo modules under the dis VM really do work as plug & play s/w...

hope this helps!

as far as performance goes, there's also the fact that there hasn't yet been a great deal of work done optimizing the compiler output or the JIT (i.e. currently the JIT does little registerisation, where the design of the DIS VM means that registerisation should be relatively easy to do - see this). i have a feeling that it's quite a lot faster than most java versions.

what's it good for? all sorts of things. it's a really clean environment to write programs in. where plan 9 is really clean in the namespace and the system interface, but still uses C as the application programming language, Inferno has all that, but uses Limbo as the language with Dis underneath.

the main advantage it gives you when writing programs is that your programs are unconditionally portable - if i've written a Limbo program to run on a screen phone (bare hardware, ARM SA1100) then, assuming enough memory, i have no doubts about it running perfectly on any other platform on which Inferno is supported.

that, coupled with the fact that limbo is a really, really nice language means that i don't want to develop for anything else. i started off as a C developer about 10 years ago, managed to escape Ingres (eugh) after a couple of years, hacked some Occam (which is a nice language, but somewhat limited in its type system), ended up in Objective-C under NeXTstep/Openstep/(macosX?). so i've hacked in a number of languages, and Limbo wins hands down.

why? it's difficult to say. it's a combination of many factors that all go to make up for a thoroughly enjoyable programming experience. i love C (not C++ though!) and it keeps the "power at your fingertips" feel that you get with C, but without pointers, with garbage collection, with complete type safety... perhaps the main feature is that when you read a Limbo program, you can actually tell what it's doing! (shock horror). all the names that are accessible to a fragment of code are easily findable. there's no overloading. the OO paradigm works entirely around aggregation - no inheritance whatsoever. the inbuilt types work really nicely - value types mean that in a multi-threaded environment, which Inferno/Limbo is, you are utterly certain that a value can't be changed underneath you).

what programs are for it? well, there's a web browser, but if you're running it hosted, then you'll probably have one anyway (that doesn't have to conform to the restriction of needing to run in 4MB). i've written what i think is a fairly cool programmable shell for it which is pretty small as well (main binary for it is 36K). i also wrote a passable version of Tetris (which is great 'cos now i can play the same version against people in the office running windows, linux, plan 9 and screenphones!), and i'm finishing off a pretty nice FIBS client. most of that stuff i did in my spare time. there's a version of Acme that's been ported, so you can see how the original compares to Wily.

how easily can you port programs from *NIX? (shouldn't that be *N[UI]X ? :-]) depends on what sort of program you're talking about. what inferno does *not* have (and this is the reason it's so small) is all the legacy stuff that *NIX has picked up over the years. this it has in common with plan 9. it does not have cursor addressing programs (although i wouldn't mind porting a decent vt100 emulator). it does not have termcap/terminfo/curses/ioctl/fcntl or sockets. so porting anything that relies on that stuff (e.g. emacs, slrn) won't be at all easy. BUT, straight C usually goes very nicely into Limbo. most of the standard unix command line programs (i.e. the ones that just munge stdin to stdout) go fine. The Limbo arithmetic expression syntax uses the same precedence rules as C, so all those nightmare mathematical equations are little problem (unless they've got dodgy type promotion going on, which you want to know about anyway).

the best thing about inferno is that it's a truly component oriented architecture. OO systems with inheritance don't give you that as there's too much interdependence between objects at different levels. Limbo modules under the dis VM really do work as plug & play s/w...

hope this helps!

as far as performance goes, there's also the fact that there hasn't yet been a great deal of work done optimizing the compiler output or the JIT (i.e. currently the JIT does little registerisation, where the design of the DIS VM means that registerisation should be relatively easy to do - see this). i have a feeling that it's quite a lot faster than most java versions.

what's it good for? all sorts of things. it's a really clean environment to write programs in. where plan 9 is really clean in the namespace and the system interface, but still uses C as the application programming language, Inferno has all that, but uses Limbo as the language with Dis underneath.

the main advantage it gives you when writing programs is that your programs are unconditionally portable - if i've written a Limbo program to run on a screen phone (bare hardware, ARM SA1100) then, assuming enough memory, i have no doubts about it running perfectly on any other platform on which Inferno is supported.

that, coupled with the fact that limbo is a really, really nice language means that i don't want to develop for anything else. i started off as a C developer about 10 years ago, managed to escape Ingres (eugh) after a couple of years, hacked some Occam (which is a nice language, but somewhat limited in its type system), ended up in Objective-C under NeXTstep/Openstep/(macosX?). so i've hacked in a number of languages, and Limbo wins hands down.

why? it's difficult to say. it's a combination of many factors that all go to make up for a thoroughly enjoyable programming experience. i love C (not C++ though!) and it keeps the "power at your fingertips" feel that you get with C, but without pointers, with garbage collection, with complete type safety... perhaps the main feature is that when you read a Limbo program, you can actually tell what it's doing! (shock horror). all the names that are accessible to a fragment of code are easily findable. there's no overloading. the OO paradigm works entirely around aggregation - no inheritance whatsoever. the inbuilt types work really nicely - value types mean that in a multi-threaded environment, which Inferno/Limbo is, you are utterly certain that a value can't be changed underneath you).

what programs are for it? well, there's a web browser, but if you're running it hosted, then you'll probably have one anyway (that doesn't have to conform to the restriction of needing to run in 4MB). i've written what i think is a fairly cool programmable shell for it which is pretty small as well (main binary for it is 36K). i also wrote a passable version of Tetris (which is great 'cos now i can play the same version against people in the office running windows, linux, plan 9 and screenphones!), and i'm finishing off a pretty nice FIBS client. most of that stuff i did in my spare time. there's a version of Acme that's been ported, so you can see how the original compares to Wily.

how easily can you port programs from *NIX? (shouldn't that be *N[UI]X ? :-]) depends on what sort of program you're talking about. what inferno does *not* have (and this is the reason it's so small) is all the legacy stuff that *NIX has picked up over the years. this it has in common with plan 9. it does not have cursor addressing programs (although i wouldn't mind porting a decent vt100 emulator). it does not have termcap/terminfo/curses/ioctl/fcntl or sockets. so porting anything that relies on that stuff (e.g. emacs, slrn) won't be at all easy. BUT, straight C usually goes very nicely into Limbo. most of the standard unix command line programs (i.e. the ones that just munge stdin to stdout) go fine. The Limbo arithmetic expression syntax uses the same precedence rules as C, so all those nightmare mathematical equations are little problem (unless they've got dodgy type promotion going on, which you want to know about anyway).

the best thing about inferno is that it's a truly component oriented architecture. OO systems with inheritance don't give you that as there's too much interdependence between objects at different levels. Limbo modules under the dis VM really do work as plug & play s/w...

hope this helps!

as far as performance goes, there's also the fact that there hasn't yet been a great deal of work done optimizing the compiler output or the JIT (i.e. currently the JIT does little registerisation, where the design of the DIS VM means that registerisation should be relatively easy to do - see this). i have a feeling that it's quite a lot faster than most java versions.

what's it good for? all sorts of things. it's a really clean environment to write programs in. where plan 9 is really clean in the namespace and the system interface, but still uses C as the application programming language, Inferno has all that, but uses Limbo as the language with Dis underneath.

the main advantage it gives you when writing programs is that your programs are unconditionally portable - if i've written a Limbo program to run on a screen phone (bare hardware, ARM SA1100) then, assuming enough memory, i have no doubts about it running perfectly on any other platform on which Inferno is supported.

that, coupled with the fact that limbo is a really, really nice language means that i don't want to develop for anything else. i started off as a C developer about 10 years ago, managed to escape Ingres (eugh) after a couple of years, hacked some Occam (which is a nice language, but somewhat limited in its type system), ended up in Objective-C under NeXTstep/Openstep/(macosX?). so i've hacked in a number of languages, and Limbo wins hands down.

why? it's difficult to say. it's a combination of many factors that all go to make up for a thoroughly enjoyable programming experience. i love C (not C++ though!) and it keeps the "power at your fingertips" feel that you get with C, but without pointers, with garbage collection, with complete type safety... perhaps the main feature is that when you read a Limbo program, you can actually tell what it's doing! (shock horror). all the names that are accessible to a fragment of code are easily findable. there's no overloading. the OO paradigm works entirely around aggregation - no inheritance whatsoever. the inbuilt types work really nicely - value types mean that in a multi-threaded environment, which Inferno/Limbo is, you are utterly certain that a value can't be changed underneath you).

what programs are for it? well, there's a web browser, but if you're running it hosted, then you'll probably have one anyway (that doesn't have to conform to the restriction of needing to run in 4MB). i've written what i think is a fairly cool programmable shell for it which is pretty small as well (main binary for it is 36K). i also wrote a passable version of Tetris (which is great 'cos now i can play the same version against people in the office running windows, linux, plan 9 and screenphones!), and i'm finishing off a pretty nice FIBS client. most of that stuff i did in my spare time. there's a version of Acme that's been ported, so you can see how the original compares to Wily.

how easily can you port programs from *NIX? (shouldn't that be *N[UI]X ? :-]) depends on what sort of program you're talking about. what inferno does *not* have (and this is the reason it's so small) is all the legacy stuff that *NIX has picked up over the years. this it has in common with plan 9. it does not have cursor addressing programs (although i wouldn't mind porting a decent vt100 emulator). it does not have termcap/terminfo/curses/ioctl/fcntl or sockets. so porting anything that relies on that stuff (e.g. emacs, slrn) won't be at all easy. BUT, straight C usually goes very nicely into Limbo. most of the standard unix command line programs (i.e. the ones that just munge stdin to stdout) go fine. The Limbo arithmetic expression syntax uses the same precedence rules as C, so all those nightmare mathematical equations are little problem (unless they've got dodgy type promotion going on, which you want to know about anyway).

the best thing about inferno is that it's a truly component oriented architecture. OO systems with inheritance don't give you that as there's too much interdependence between objects at different levels. Limbo modules under the dis VM really do work as plug & play s/w...

hope this helps!

From this introduction at the web site:

Inferno is intended to be used in a variety of network environments, for example those supporting advanced telephones, hand-held devices, TV set-top boxes attached to cable or satellite systems, and inexpensive Internet computers, but also in conjunction with traditional computing systems.

Have we not seen this before? There certainly seems to be a proliferation of "network" operating systems for non-computer systems at the moment. Whilst I'm not knocking Inferno, I don't really know much about it, it has to be said that this are is fast becoming saturated, and the competition is likely to be fierce.

One thing I found interesting is that Inferno, as well as being a stand-alone OS, can also be run as an application under Windows NT, Windows 95, Unix (Irix, Solaris, FreeBSD, Linux, AIX, HP/UX) and Plan 9. This could give it an edge since it increases the number of places where its applications (written in Limbo?) can be run. So even if it doesn't become hugely popular, it might still survive on other platforms.