Slashdot Mirror

It
Sure
Is

Hosted Inferno is great for rapid prototyping of distributed cross-platform applications and the creation of grid-like environments on demand.

This sounds like too much buzzwordism, I know, but take a look at http://www.vitanuova.com/grid/ and, if you have IE, play around with their grid demos. From your web browser!

Now imagine doing the same thing to a cluster of thousands of Inferno CPU machines clustered together, effectively serving as an addition to your environment. And you don't even need to change your OS.

I'm sorry if it looks like I'm preaching here, but this stuff just gets me excited, while being low-key enough that it never gets mentioned on slashdot, so we have only the cool guys interested in it :)

The linux loader also supports plan9 and Inferno

So why watse your life with Linux when you can use professional software.

oh, and inferno comes with tetris too

Too bad Limbo is too deeply tied to Inferno. It's unfortunate. From looking at how it's been designed it seems that Dennis Ritchie still hasn't lost his touch as an exceptional language designer. The Dis virtual machine that goes with it is supposedly designed to make a JIT simpler and more efficient, and well, according to Vita Nuova it gets something like 50% to 75% of the performance of compiled C/C++ code, which, if the article and Vita Nuova's benchmarks are accurate, totally blows C# and Java out of the water performance-wise. Now if only Vita Nuova would care to make it half as platform-neutral as Java... But hey, who cares, I'm already trying to do that. :)

Too bad Limbo is too deeply tied to Inferno. It's unfortunate. From looking at how it's been designed it seems that Dennis Ritchie still hasn't lost his touch as an exceptional language designer. The Dis virtual machine that goes with it is supposedly designed to make a JIT simpler and more efficient, and well, according to Vita Nuova it gets something like 50% to 75% of the performance of compiled C/C++ code, which, if the article and Vita Nuova's benchmarks are accurate, totally blows C# and Java out of the water performance-wise. Now if only Vita Nuova would care to make it half as platform-neutral as Java... But hey, who cares, I'm already trying to do that. :)

i -- a browser attempt by Howard Trickey done sometime around 1996. you can view slightly less complex pages without crashing with probability of around 50%. i know of at least one masochist that uses it regularly.

charon -- the browser packaged with VitaNuova's Inferno operating system which runs native atop Plan 9 (among other OS's). this is your best bet if you want to stick to using Plan 9 only.

Everything else the runs under UNIX/Windows (see Opera lurking in the background?). you only need to have a machine to run VNC on.

links -- two people have started a port of this graphical browser to Plan 9, one may succeed, who knows :)

as for mozilla, there is a slight problem with porting it to Plan 9 -- the browser sources are twice the size of the entire Plan 9 operating system (including the PostScript viewer).

I use Inferno and it does (optionally) just in time compiling, the speed difference is discernable but not inhibiting.

If you are interesting in VM design you might enjoy this light read :

The design of the Inferno virtual machine
Phil Winterbottom Rob Pike Bell Labs,
Lucent Technologies {philw,rob}@plan9.bell-labs.com

NOTE: Originally appeared in IEEE Compcon 97 Proceedings, 1997.

I use Inferno and it does (optionally) just in time compiling, the speed difference is discernable but not inhibiting.

If you are interesting in VM design you might enjoy this light read :

The design of the Inferno virtual machine
Phil Winterbottom Rob Pike Bell Labs,
Lucent Technologies {philw,rob}@plan9.bell-labs.com

NOTE: Originally appeared in IEEE Compcon 97 Proceedings, 1997.

As each manufacturer customises the environment to suit their needs it will be interesting to see which are prepared to release their firmware under the GPL.

Surely it will be tricky to program for Linux embedded devices without some developer cutting and pasting some GPL source code along the line.

Ah well, it won't be my ass on the line anyway. I'll keep on using Inferno which seems to have a lot more technically interesting things going for it.

Demos here

Demos here

Demos here

http://www.vitanuova.com/inferno

It's a Virtualised OS in Windows/FreeBSD/Linux,plan9 and also runs native on x86, ARM & others

Dennis Ritchie is one of it's fathers, what more could you ask for?

Virtualising the OS means it's feels like the bare metal but's it's just a reflection map.

It truly is "write once, run anywhere".

you should pay a visit to

http://www.vitanuova.com/inferno

It's a virtualised machine that runs hosted on Windows, Lunix & FreeBSD (& maybe others) and also runs native on some hardware (such as my IPAQ)

It has some really neat features, many borrowed from plan9.

Version 3 and below is not totally open (the source is $100).

The next version is considering making changes (see http://www.vitanuova.com/inferno/4thedoverview.htm l )

Even if you never downlaod it, it's still worth reading the documentation.

Inferno follows the concept that threads are cheap (as an experiment someone recently had 90,000 concurrent threads passing a message from one to the other (admitedly it took .84 secs per tx but still)

You'll wonder why anybody uses Java at all.

http://plan9.bell-labs.com/plan9

http://www.vitanuova.com/inferno

anyone with any experience in Wireless nows that WEP is an insecure method of communication that is brute force breakable.

It is therefore easier to assume that all WEP protected comms are effectively plain text.

It is from this position that one should build the network.

Personally I would be using Inferno

from http://www.vitanuova.com/inferno/papers/bltj.html

Security in Inferno

Inferno provides security of communication, resource control, and system integrity.

Each external communication channel may be transmitted in the clear, accompanied by message digests to prevent corruption, or encrypted to prevent corruption and interception. Once communication is set up, the encryption is transparent to the application. Key exchange is provided through standard public-key mechanisms; after key exchange, message digesting and line encryption likewise use standard symmetric mechanisms.

Inferno is secure against erroneous or malicious applications, and encourages safe collaboration between mutually suspicious service providers and clients. The resources available to applications appear exclusively in the name space of the application, and standard protection modes are available. This applies to data, to communication resources, and to the executable modules that constitute the applications. Security-sensitive resources of the system are accessible only by calling the modules that provide them; in particular, adding new files and servers to the name space is controlled and is an authenticated operation. For example, if the network resources are removed from an application's name space, then it is impossible for it to establish new network connections.

Security mechanisms

Authentication and digital signatures are performed using public key cryptography. Public keys are certified by Inferno-based or other certifying authorities that sign the public keys with their own private key.

Inferno uses encryption for:

*
mutual authentication of communicating parties;
*
authentication of messages between these parties; and
*
encryption of messages between these parties.

The encryption algorithms provided by Inferno include the SHA, MD4, and MD5 secure hashes; Elgamal public key signatures and signature verification [4]; RC4 encryption; DES encryption; and public key exchange based on the Diffie-Hellman scheme. The public key signatures use keys with moduli up to 4096 bits, 512 bits by default.

anyone with any experience in Wireless nows that WEP is an insecure method of communication that is brute force breakable.

It is therefore easier to assume that all WEP protected comms are effectively plain text.

It is from this position that one should build the network.

Personally I would be using Inferno

from http://www.vitanuova.com/inferno/papers/bltj.html

Security in Inferno

Inferno provides security of communication, resource control, and system integrity.

Each external communication channel may be transmitted in the clear, accompanied by message digests to prevent corruption, or encrypted to prevent corruption and interception. Once communication is set up, the encryption is transparent to the application. Key exchange is provided through standard public-key mechanisms; after key exchange, message digesting and line encryption likewise use standard symmetric mechanisms.

Inferno is secure against erroneous or malicious applications, and encourages safe collaboration between mutually suspicious service providers and clients. The resources available to applications appear exclusively in the name space of the application, and standard protection modes are available. This applies to data, to communication resources, and to the executable modules that constitute the applications. Security-sensitive resources of the system are accessible only by calling the modules that provide them; in particular, adding new files and servers to the name space is controlled and is an authenticated operation. For example, if the network resources are removed from an application's name space, then it is impossible for it to establish new network connections.

Security mechanisms

Authentication and digital signatures are performed using public key cryptography. Public keys are certified by Inferno-based or other certifying authorities that sign the public keys with their own private key.

Inferno uses encryption for:

*
mutual authentication of communicating parties;
*
authentication of messages between these parties; and
*
encryption of messages between these parties.

The encryption algorithms provided by Inferno include the SHA, MD4, and MD5 secure hashes; Elgamal public key signatures and signature verification [4]; RC4 encryption; DES encryption; and public key exchange based on the Diffie-Hellman scheme. The public key signatures use keys with moduli up to 4096 bits, 512 bits by default.

There are various bits of UNIX (and I include Linux here, as it's essentially a UNIX clone) that have been bolted on without regard for the elegance of the whole system. In particular, graphics, pseudo terminals and networking were all added late in UNIX's lifetime and considerably clutter the system and limit its capabilities.

Take the ubiquitous psueudo terminals as an example. Almost nobody actually uses a genuine VT220 (or whatever) as their input device. However, the output from every command-line program in UNIX goes through something that pretends to be such a device. The kernel has much elaborate stuff (the tty driver) built in to convince command line programs that they're talking to a real terminal. The kernel knows about command line editing, it knows how to print control characters nicely, and it knows what key means "word erase".

This is all crap! It adds unnecessary complexity to the kernel, and not only that, but every command line program that wants a a slightly more sophisticated interface (e.g. cursor-based editing) has to do it itself (c.f. GNU readline). This not only bloats the kernel and many of its applications, it also means that the commands are less versatile than they could be (requiring people to use tools like expect to demangle their output).

Under Plan 9, there are no special system calls devoted to terminals or networking: instead, the interface to device drivers is made more versatile (all you need is open, read and write to access a device driver, no fancy ioctls or fcntls required. This gets back to the original purity of the 7th Edition programming interface: programs are a joy to write, and once written can be put to many more uses, as the currency of command line programs (text written to stdin/stdout) is also the currency of device drivers.

Because everything is unified under one hood (the name space), I don't have to write a special program to get fancy functionality. Want to find out what programs have a particular file open?
grep filename /proc/*/fd
Plan 9 is all about the joys of writing less code, more cleanly, and finding it more useful when written; of having a box of tools that can be plugged together in a multitude of different ways, transparently and securely across networks; of having a clean user interface that is concerned principally with power and simplicity rather than appearance.

Of course in this day and age, when a word processor takes >2,000,000 lines of code and "features" are rated more highly than overall usability, it's not surprising that Plan 9 isn't that well known, or that Dennis Ritchie reverts to Windows NT in order to browse the web.

As for myself, I'll stick to Plan 9's (and Inferno's) deep joy for as long as I possibly can!

Lucent developed an experimental Distributed VM cum OS.

The idea is that the whole machine / OS is virtualised and thus standard across architectures rather than Java's seemingly halfway house. With users & groups and plenty of runtime features.

Better to take a look yourself than rely on my patchy description.

The source code is available if you pay. [& other stuff]

Inferno's not an OS/Language hybrid but it is a virtualised unix like OS that will run with identical interfaces, including GUI, on differing hardware & software combinations. It will run natively on some hardware [such as my IPAQ] and hosted elsewhere - such as Windows & Linux.

It was a project started before Java and shares many of it's aims but went that one step futher by retaining the concept of an OS where you can read and write files etc.

Dennis Ritchie talks about Inferno and other things

It depends on the thread abstractions that are used for synchronisation and thread communication. The most commonly used abstractions today (semaphores, locks, etc) date from the 1970s; there are much better ways to do it!

One way derives from a mathematical notation created by Tony Hoare, called CSP. There is one unit of thread communications and synchronisation, called a channel. It's like a rendezvous point that allows a value to be passed between threads. If one thread tries to send a value on a channel, it will block until another thread tries to read from the channel (also, reading from the channel will block until another thread tries to send on it).

This scheme is incredibly versatile, easy to use and cheap. There are also some tools that can aid in automatic verification of software built in this way. It's true that it's possible to deadlock in concurrent systems, but it's almost always possible to structure the system in such a way that it's deadlock-free by construction. For instance, if my program is structured as a one-way pipeline, it's impossible to deadlock.

Concurrency at this level in a GUI application can greatly enhance the simplicity and maintainability of a program. This is because it's generally much easier to write a straightforward piece of imperative code than encode the same thing as a state machine, e.g.

while (buttons != 0) {
(buttons, point) = <-mouse;
drawat(point)
}


(where <- receives from a channel), versus:


callback(buttons, point) {
if (state == DRAGGING) {
if (buttons != 0)
drawat(point);
else
state = NOTDRAGGING;
}
}

You say:
That would be the case if interaction was a parallel activity, but unfortunately it's not.

But it is! Yes, the user themselves only contributes one thread to the activity, but the program itself is often dealing with multiple activities at the same time; for instance updating itself in response to network activities or updating graphics on a time-step basis.

The most important thing it gives you, in my experience, is the sense of control. As a separate thread, you are free to structure your application in a way directly appropriate to the task being solved. In a callback system, you are at the mercy of the caller; you can't just wait for an event, then do the next thing, you have to encode your current state, return, and wait to be called back, whereupon you have to figure out where you just were!

For a language that exemplifies this, see Limbo, the language of choice in the Inferno environment. No problems with thread unsafe graphics there!

It depends on the thread abstractions that are used for synchronisation and thread communication. The most commonly used abstractions today (semaphores, locks, etc) date from the 1970s; there are much better ways to do it!

One way derives from a mathematical notation created by Tony Hoare, called CSP. There is one unit of thread communications and synchronisation, called a channel. It's like a rendezvous point that allows a value to be passed between threads. If one thread tries to send a value on a channel, it will block until another thread tries to read from the channel (also, reading from the channel will block until another thread tries to send on it).

This scheme is incredibly versatile, easy to use and cheap. There are also some tools that can aid in automatic verification of software built in this way. It's true that it's possible to deadlock in concurrent systems, but it's almost always possible to structure the system in such a way that it's deadlock-free by construction. For instance, if my program is structured as a one-way pipeline, it's impossible to deadlock.

Concurrency at this level in a GUI application can greatly enhance the simplicity and maintainability of a program. This is because it's generally much easier to write a straightforward piece of imperative code than encode the same thing as a state machine, e.g.

while (buttons != 0) {
(buttons, point) = <-mouse;
drawat(point)
}


(where <- receives from a channel), versus:


callback(buttons, point) {
if (state == DRAGGING) {
if (buttons != 0)
drawat(point);
else
state = NOTDRAGGING;
}
}

You say:
That would be the case if interaction was a parallel activity, but unfortunately it's not.

But it is! Yes, the user themselves only contributes one thread to the activity, but the program itself is often dealing with multiple activities at the same time; for instance updating itself in response to network activities or updating graphics on a time-step basis.

The most important thing it gives you, in my experience, is the sense of control. As a separate thread, you are free to structure your application in a way directly appropriate to the task being solved. In a callback system, you are at the mercy of the caller; you can't just wait for an event, then do the next thing, you have to encode your current state, return, and wait to be called back, whereupon you have to figure out where you just were!

For a language that exemplifies this, see Limbo, the language of choice in the Inferno environment. No problems with thread unsafe graphics there!

Vita Nuova say in their most recent newsletter that they are considering "a dual-licence scheme that makes the Inferno software free for non-commercial use, but with a more traditional software licence for commercial use."

A quick glance at the features of the upcoming release reveals some clarification on this:

• It is available as `Free Software' (in the sense of the Free Software Foundation) if the use you make of it will also be made available on the same terms, as Free Software.
• A more conventional software licence if the result of your work using Inferno will not or cannot be made Free Software.

Inferno is the very interesting cousin OS to Plan 9 (both modern descendants of UNIX). This would be a very cool thing.

Vita Nuova say in their most recent newsletter that they are considering "a dual-licence scheme that makes the Inferno software free for non-commercial use, but with a more traditional software licence for commercial use."

A quick glance at the features of the upcoming release reveals some clarification on this:

• It is available as `Free Software' (in the sense of the Free Software Foundation) if the use you make of it will also be made available on the same terms, as Free Software.
• A more conventional software licence if the result of your work using Inferno will not or cannot be made Free Software.

Inferno is the very interesting cousin OS to Plan 9 (both modern descendants of UNIX). This would be a very cool thing.

Vita Nuova say in their most recent newsletter that they are considering "a dual-licence scheme that makes the Inferno software free for non-commercial use, but with a more traditional software licence for commercial use."

A quick glance at the features of the upcoming release reveals some clarification on this:

• It is available as `Free Software' (in the sense of the Free Software Foundation) if the use you make of it will also be made available on the same terms, as Free Software.
• A more conventional software licence if the result of your work using Inferno will not or cannot be made Free Software.

Inferno is the very interesting cousin OS to Plan 9 (both modern descendants of UNIX). This would be a very cool thing.

Vita Nuova say in their most recent newsletter that they are considering "a dual-licence scheme that makes the Inferno software free for non-commercial use, but with a more traditional software licence for commercial use."

A quick glance at the features of the upcoming release reveals some clarification on this:

• It is available as `Free Software' (in the sense of the Free Software Foundation) if the use you make of it will also be made available on the same terms, as Free Software.
• A more conventional software licence if the result of your work using Inferno will not or cannot be made Free Software.

Inferno is the very interesting cousin OS to Plan 9 (both modern descendants of UNIX). This would be a very cool thing.

Vita Nuova say in their most recent newsletter that they are considering "a dual-licence scheme that makes the Inferno software free for non-commercial use, but with a more traditional software licence for commercial use."

A quick glance at the features of the upcoming release reveals some clarification on this:

• It is available as `Free Software' (in the sense of the Free Software Foundation) if the use you make of it will also be made available on the same terms, as Free Software.
• A more conventional software licence if the result of your work using Inferno will not or cannot be made Free Software.

Inferno is the very interesting cousin OS to Plan 9 (both modern descendants of UNIX). This would be a very cool thing.

the connectivity and security are as versatile (or more so) as unix pipes; also you can write programs for it that run without change (really!) on any supported platform ('cos it provides an OS level view of everything rather than trying to shoehorn itself into the parent environment like java).

the security model is public-key based and because it's end to end, you don't need to worry at all about little things like 802.11 insecurities...

plus it's all small, clean and beautiful as befits something coming from CSRG at bell labs.

most of the source code (applications, libraries, etc)
is free and open source.

i believe this compares favourably with Linux (many
embedded linuxen have proprietary bits) PalmOS
(where's the source code to that?), and many other
embedded systems such as QNX and VXworks.
not to mention being the coolest OS on the planet.

most of the source code (applications, libraries, etc)
is free and open source.

i believe this compares favourably with Linux (many
embedded linuxen have proprietary bits) PalmOS
(where's the source code to that?), and many other
embedded systems such as QNX and VXworks.
not to mention being the coolest OS on the planet.

compared to C++ you're right, but java really isn't
the clean language it's hyped up to be.

for a nice clean language that fits in the embedded niche,
you should check out Limbo, which
is a genuinely clean language (designed by the same
group that designed C).

the crucial thing about Limbo, though, is that, unlike Java,
it doesn't try to solve all portability problems in the language
itself. The Inferno OS effortlessly solves all
the problems that Java struggles over. It runs fast, packing
lots of functionality into a small footprint (1MB RAM is sufficient
to run significant GUI apps), and provides some extremely
powerful primitives for composing distributed applications.

we had a little distributed app that a colleague had
knocked up over a couple of days (two files, 800 lines of code total).
it implemented a "shared piece of paper" - i.e. all users
see anything that anyone draws on the app.
talking to someone that had tried to do a similar thing in
Java on a PalmOS based device, they were amazed - they'd
taken months to do the same thing, and it was slow, big,
and didn't provide as much functionality.

the real plus side is just how beautiful the environment
is to program in. it gives you power and doesn't make you
pay for it via huge and convoluted API interfaces.
(and that's why it's fast and small too).

compared to C++ you're right, but java really isn't
the clean language it's hyped up to be.

for a nice clean language that fits in the embedded niche,
you should check out Limbo, which
is a genuinely clean language (designed by the same
group that designed C).

the crucial thing about Limbo, though, is that, unlike Java,
it doesn't try to solve all portability problems in the language
itself. The Inferno OS effortlessly solves all
the problems that Java struggles over. It runs fast, packing
lots of functionality into a small footprint (1MB RAM is sufficient
to run significant GUI apps), and provides some extremely
powerful primitives for composing distributed applications.

we had a little distributed app that a colleague had
knocked up over a couple of days (two files, 800 lines of code total).
it implemented a "shared piece of paper" - i.e. all users
see anything that anyone draws on the app.
talking to someone that had tried to do a similar thing in
Java on a PalmOS based device, they were amazed - they'd
taken months to do the same thing, and it was slow, big,
and didn't provide as much functionality.

the real plus side is just how beautiful the environment
is to program in. it gives you power and doesn't make you
pay for it via huge and convoluted API interfaces.
(and that's why it's fast and small too).

Yes. Inferno applications are written in a concurrent programming language called Limbo. the language reference manual is available online, as are varous descriptions of programming in the language (and some other papers as well). the language is C-like in structure, with influences from many other places, like Pascal and Algol. of particular note are channels, a data type for inter-process communication which makes writing multi-threaded and/or distributed apps easier than in maybe any other system. it's a beautiful language.

Yes. Inferno applications are written in a concurrent programming language called Limbo. the language reference manual is available online, as are varous descriptions of programming in the language (and some other papers as well). the language is C-like in structure, with influences from many other places, like Pascal and Algol. of particular note are channels, a data type for inter-process communication which makes writing multi-threaded and/or distributed apps easier than in maybe any other system. it's a beautiful language.

I'm no expert in all things fractal, but aren't fractals supposed to infinitely repeat? If so, then the fractal program for the Inferno plugin doesn't really generate fractals. Check it out yourself....just keep zooming in. Eventually it gets all pixellated.

If I'm wrong, set me straight and mod me down and explain fractals to me again...

i may well be in the minority among this crowd, but i think you should avoid autoconf like the plauge. people's most common reason for using autoconf/configure is portability, but that's a cop-out.
basically, the autoconf/configure school of portability says "forget about actually writing portable code, just write it for each variant and let the build process pick". that's whacked. you'll continually be running accross new variants, new ways in which systems are different, or just new systems. for example, i use Plan 9, which has a very good ANSI/POSIX compatability system (better than many *nix systems). despite being near-fully ANSI compliant, pretty much every autoconf fails because it doesn't recognize the output of uname or something stupid like that (of course, that says noting about when programs that claim to be ANSI or POSIX arn't, like including non-ANSI/POSIX headers, typically BSD stuff).
this school of portability also typically makes your code far less readable - littering it with ifdef's every third line - and much larger. it ends up taking much more time than just slowing down and disiplining yourself to write real portable code.
the argument 'configure ; make ; make install' is easy is stupid, as well. y'know why? 'cause 'make install' is easier. build your makefiles well. the 'install' target should have prerequisits, obviously. make will build them for install. and 'configure' is slower and more prone to failure than 'cp makefile.linux.386 makefile'. and light years more reliable. and editing an example makefile is way easier than putzing with autoconf/configure if something doesn't work. not to mention easier to debug (uh, 'echo' anyone?).

on a personal note, having done portability work a good bunch, i'd offer just a little extra advice: do not require GNU-specific stuff. don't use any of the gmake-specific features or gcc language extentions. GNU propaganda, that'll just kill your portability. and if you need something both simpler and more powerful than make, check out mk from the Plan 9 and Inferno distrubutions. Vita Nuova's got a version that runs on various unixes and win32 systems. it's very similar to make, but a bit more general and flexible. but, given that you've already got all the makefiles, i'd suggest your best bet is just sticking with plain makefiles and cleaning them up.

Each of these notices of a hardware vendor dropping a product are good news for the Linux Hackers out there. I've got an I-Opener running Linux and a Compaq IA for that matter, which is still a shipping product.

I'm also deeply involved in the TuxScreen project. This is a discontinued WebPhone that used to sell for $650 running Inferno. The remaining discontinued units are now available to Linux hackers everywhere for $99 usd. ARM Linux is now running on the devices, so they at least work as an X terminal.

The challenge with each of these discontinued hardware "bargins" is to get enough technical details from the original vendor to make them useful to Linux Hackers.

Linux on your phone, now that's hot ;-)

Good luck and happy hacking!

The latest Inferno/Plan 9 newsletter mentions a port of the Inferno operating system to the iPAQ. If you pay for an Inferno subscription, then you can get the port `for free'. I believe that the source would be available to you.

Vita Nuova was able to hack the iPAQ thoroughly; if you can't get the information that you want, you could use Inferno source code as documentation or the basis of your own hacks. If I wanted to set up a wireless mobile network with custom software on it, this would be the easiest prepackaged solution of which I know. (I would rather use Erlang than Limbo for a distributed system, but it would take effort to get it on an iPAQ.)

low memory usage isn't the coolest thing about it, though... currently i'm not using any local flash storage; everything is being dragged across via the wavelan card. that includes not only files, but even the network interface !

everything (apart from the itsy bitsy screen) is exactly the same as any other inferno installation... and even though i haven't turned on JIT compilation, it's highly responsive and nicely nippy.

forget java, which is fundamentally memory hungry and bloated... inferno makes it incredibly easy to do things which are hard (or impossible) under other platforms.

now there's just the question of how best to use these funny little devices. typing on this wee sw kbd ain't the easiest, long term! .

low memory usage isn't the coolest thing about it, though... currently i'm not using any local flash storage; everything is being dragged across via the wavelan card. that includes not only files, but even the network interface !

everything (apart from the itsy bitsy screen) is exactly the same as any other inferno installation... and even though i haven't turned on JIT compilation, it's highly responsive and nicely nippy.

forget java, which is fundamentally memory hungry and bloated... inferno makes it incredibly easy to do things which are hard (or impossible) under other platforms.

now there's just the question of how best to use these funny little devices. typing on this wee sw kbd ain't the easiest, long term! .

Personally, I don't believe that Java is the right way to go in that respect (although there are worse languages: my old comp sci dept started to teach Ada as a first language after I left...). Two main reasons:

• Inheritance-based OO programming is a naturally obfuscated way of writing code, and is hard even for experts to get right. This page holds, amongst other things, a couple of paragraphs I wrote giving some of the reasons why.
• The Java class libraries, partly for the above reasons, are a huge, tangled mess, and extremely hard for a beginner to come to terms with.

My personal choice for a first language to teach would be Limbo, a beautiful language, designed by some of the original designers of C (who've come a long way since then!). Amongst other things, it:

• encourages simple, understandable code. Reuse is through encapsulation rather than inheritance.
• has a powerful set of primitive data-types with natural and useful semantics.
• runs on many platforms under the Inferno OS, e.g. Windows and Linux.
• is completely type-safe (unlike Java)
• has a simple but powerful set of libraries which can be understood, and are useful, in isolation from each other.

• Lisp-style lists are nice for teaching recursion ("car" and "cdr" become the more natural "hd" and "tl")
• Proper by-value strings (unlike Java's) make string handling sinple and natural.
• Interprocess communication is supported in Limbo by first-class channels, enabling threading and concurrency to be explored without constantly struggling against thread primitives and associated pitfalls which belong to the 1970s.

I'd love to teach it as a first language. No more "ahh yes, that array just turned into a pointer because you looked at it funny"... oh happy memories...

Personally, I don't believe that Java is the right way to go in that respect (although there are worse languages: my old comp sci dept started to teach Ada as a first language after I left...). Two main reasons:

• Inheritance-based OO programming is a naturally obfuscated way of writing code, and is hard even for experts to get right. This page holds, amongst other things, a couple of paragraphs I wrote giving some of the reasons why.
• The Java class libraries, partly for the above reasons, are a huge, tangled mess, and extremely hard for a beginner to come to terms with.

My personal choice for a first language to teach would be Limbo, a beautiful language, designed by some of the original designers of C (who've come a long way since then!). Amongst other things, it:

• encourages simple, understandable code. Reuse is through encapsulation rather than inheritance.
• has a powerful set of primitive data-types with natural and useful semantics.
• runs on many platforms under the Inferno OS, e.g. Windows and Linux.
• is completely type-safe (unlike Java)
• has a simple but powerful set of libraries which can be understood, and are useful, in isolation from each other.

• Lisp-style lists are nice for teaching recursion ("car" and "cdr" become the more natural "hd" and "tl")
• Proper by-value strings (unlike Java's) make string handling sinple and natural.
• Interprocess communication is supported in Limbo by first-class channels, enabling threading and concurrency to be explored without constantly struggling against thread primitives and associated pitfalls which belong to the 1970s.

I'd love to teach it as a first language. No more "ahh yes, that array just turned into a pointer because you looked at it funny"... oh happy memories...

Sorry, these links should work better:

Vita Nuova

Plan 9

the moment i read "a superset of all those other shells", i shuddered. "all those other shells" are bourne shell-like, and they are all broken. none of them fix the main problem with the bourne shell: the horrible quoting semantics. this is the main cause of bugs and security flaws in shell scripts around the world. the classic "change IFS and watch everything break" problem.

starter question for 3 points: what does $@ do in the bourne shell? why is it there?

for a small and simple shell that actually fixes some of the fundamental problems with the original bourne shell design, check out rc. it was designed for plan 9, but the above version runs under most versions on UNIX. despite being smaller and simpler, it's more powerful. it provides branching pipelines for example:

% cmp <{echo hello world} <{echo hello Xorld}
/fd/6 /fd/5 differ: char 7

along similar lines, i wrote a shell for inferno which is even smaller (39K), simpler and more powerful. but what's the point, if monstrosities like zsh and bash continue to exist? :-(

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.

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.

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.