it isn't so strange if you realise that the vast majority of what people consider "UNIX" (i.e. POSIX) is horrible bloat that has nothing to do with the fundamentals of UNIX - which is at heart a simple and intuitive beast.
"Do one thing and do it well", a maxim that works excellently, but that most developers seem unaware of.
for an OS done by people who really know what they're doing, rather than yet another "i wanted to understand operating systems so i wrote one" project, check out Plan 9.
It's open source, written by some of the best people in the business, (the source code is beautiful) and its whole raison d'etre is to investigate how things should be done, instead of how they are usually done.
you might find some of your fundamental assumptions challenged and your paradigms shifted, but isn't that the point?! it keeps fundamentals of UNIX while discarding all the crud that's built up since the 7th Edition...
Now that we found out that the human geonome is so short, where is all the information stored @ now? What makes us up if our genes don't contain all the information?
the answer to this question should be obvious to anyone that thinks about it... but i think our blinkered, reductionist, view of biology ("genotype == phenotype", "genes == organism") stops it being obvious to many people.
the information is stored in the molecules that make up your body, in combination with the laws of physics. think about a pool of water. you can describe it with a simple "take one molecule of water, replicate by 10^30". however, does that information describe the pool of water? nope - think about waves, interference patterns, surface tension, etc, etc...
the point is that the genes can create a structure that is initially uniform, but allows structure to form by virtue of the interactions of its elements. think about Conway's Life - it's described by some very, very simple rules - its complexity evolves from those rules (its "laws of physics") and the cells (its "molecules")
so you can see that our genes don't need to describe us in our entirety, but merely describe a structure from which something like us can arise, given the usual laws of physics and interactions with the external environment.
i sent this as an email, but thought i'd post it here too, just in case someone is still reading this...
It's nice to see that there are those Plan9 and Inferno folks out there - those that want to take all the Unix loveliness and fix the misfeatures and bugs. Too bad that it'll never catch on;-( (Not trying to be a bastard here -- just being objective.)
well, we can always hope. because it is genuinely better, and perhaps the snowball will keep on getting bigger rather than breaking apart... it took a long time for unix to become mainstream, for example.
i'd like this to be the sort of world where it was possible for problems with existing systems to be fixed, not one in which we carry the broken legacy of the past into the 22nd century just because "it's always been that way"...
at least it's possible to use inferno inside existing systems, so i can use my (lovely!:-]) shell under most of the existing platforms today...
I also took a closer look at rc and your sh. (Wouldn't a different name have been appropriate?)
yes! but i couldn't think of a decent one, so it ended up as sh by default... basic requirements: ideally it should be a max of 4 letters, ending in "sh", and characteristic of the shell itself. originally i'd named it "shell", for want of a better name - that was deemed too long (and it's not exactly more descriptive!)
They have some really powerful features. Especially the file descriptor replacement thing that you exemplify. (zsh-workers! Steal this feature!)
actually, from an earlier reply, it seems that someone already has... along with every other feature in the book, after the true GNU "cat -v" style...
actually, my shell doesn't have this feature in the core shell syntax - it's a builtin command, "pipe":
% cmp ${pipe from {echo hello}} ${pipe from {echo helloX}} /tmp/pipes/pipe.121.1y/tmp/pipes/pipe.121.0y differ: char 6
it's somewhat more wordy, but this facility isn't used that often anyway, and you can do it...
By the way, zsh has a multiple redirection feature, but I'm pretty sure it won't work for stuff like cmp that needs two different inputs. It just concatenates things together into the input file descriptor, like "cat < file1 < file2")
what's the point? isn't it always possible to use cat and pipes to get this, in a much more regular way. e.g. cat file1 file | command
what does it buy you? 2 characters of typed input?
But one thing that you miss is that these shells (zsh, bash, tcsh, etc.) are intended (at least in my mind) for interactive use. There's little need for being able to scroll back up in command history if you're programming a script.
my view is that the features for interactive use should be delegated to the interactive parts of the system. this allows a much more generally applicable approach; if you put such features in at a higher (lower?) level, then all command line commands, not just the shell, can benefit from them.
to illustrate, neither my inferno shell, or rc, contain any sort of command-line editing. however, i can always edit my command lines, because the window containing the shell (not a vt100 emulator!) allows editing of the command-line text before sending it to the application reading from/dev/cons (aka/dev/tty in unix). i can put the window into "hold mode"; then even if i press return, the shell doesn't see the input... until i exit hold mode. this allows me to edit multiple lines, for any command, without any command needing to be changed.
for instance, for creating small text files on the file, i can type (ESC toggles hold mode)
ESC cat > myfile some text or a little script ^D ESC
my point is that the only reason $@ is there is because of the broken quoting semantics of the original bourne shell (inherited by csh, bash, zsh, tcsh, ksh, etc, etc, but not by rc). consider the following bourne shell script: $ x() { > for i in $*; do echo $i; done > } $ x 'a b' c a b c $ but i gave only two arguments to the function! ok, so in this particular case, you can use $@ to get around the problem. but what if i wanted to store the value of $* in another shell variable? i can't do it and maintain the original distinction between arguments.
this sort of thing can cause terrible security problems when filenames contain whitespace. it also makes it very hard to write robust shell scripts - you always have to be on your guard for quoting slip-ups.
the basic problem is that shell variables are simple strings, whereas the commands invoked by the shell take a vector of strings. so the shell splits up variables based on $IFS, not according to how they were originally created. i.e. the input is rescanned every time a command is invoked.
it's all unnecessary: the way rc copes is by holding everything as flat lists. so you can say:
% x=('a b' c) % for (i in $x) echo $x a b c no problem. you know what you've got, and it remains the same. isn't it lovely (not) when you can write:
$ cmd='ls' $ IFS=s $ $cmd -l l: not found
yes, zsh and kin might have crept enough features to sink a battleship, but they still keep the old real problems from the original bourne shell.
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:
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?:-(
as far as i'm concerned, prediction means being able to predict the behaviour of a system without actually executing that system. by running the totally deterministic rules of Conway's Life, you aren't predicting the state of the system, but executing that system.
it's as if i said, "i can predict the weather perfectly - i just wait and see what happens, and that's my prediction!". of course, the difference between Conway's Life and the normal universe is that we can take a copy of all the cells in a game of Life and run them independently of the "main" simulation. i don't think that's a fundamental distinction though. if the universe really was a game of Life at the bottom level, we'd be just as unable to predict it as if it was completely random underneath, because we're unable to find out the whole state of the universe in order to copy it and run it independently (not to mention you'd have to run a copy of the universe inside itself, a bit hard methinks!)
so, functionally, i don't think we could possibly tell the difference between a deterministic universe and a non-deterministic universe.
of course i agree that CAs are fundamentally deterministic (i've programmed enough of them!), but i do maintain that they're fundamentally unpredictable, in the same way that predicting arbitrary runtime properties of an arbitrary program is impossible - without actually running the program in question.
what's interesting is that you can prove certain properties of some programs, in the same way that you can find some invariants using the above CA topology display. i like to think of those invariants as the "laws of nature" in that CA. it's very obvious when you look at a few different CAs that each set of rules produces its own stable structures and its own emergent set of rules by which those interact. (think of the gliders, glider guns, blinkers, etc in Life).
i think this a nice way in which to perceive our own universe. the fact that something as simple as 2 bit single-dimensional CA can be fundamentally unpredictable should tell us much about the fundamental limits of scientific endeavour.
life doesn't depend on randomness, but unpredictability. it doesn't really matter if all those random mutations were genuinely random, or just the result of an extremely big pseudo-random number generator - the results will be similiar.
the thing about Conway's Life is that the smallest bit of the system can radically affect the whole; but you can't predict how... without solving the Halting Problem.
this is just like the real universe, where the effects of chaos amplify infinitesimally small noise into macroscopic effects. as the number of components in a deterministic system rises, the overall effect becomes more and more similar to "true randomness".
e.g. imagine a version of Conway's Life with 10^24 cells (a very small number by real-universe standards); and running at 10^12 steps per second. in one second, every one of the cells in this simulation is potentially influenced by every other, in a completely unpredicable way. if you're looking at one tiny bit of that system, then you'd find it extremely hard (nay, impossible!) to tell whether there were truly random impulses going on in the system.
by the above argument, i don't think that the distinction between deterministic and non-deterministic is so important. if you're looking at a small part of a very large system, the thing that really matters is the structure of that small part (i.e. how it reacts to external influences), not whether the system as a whole is predictable.
the universe as a whole might be deterministic, but we have no way of telling...
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.
genes form a boolean net, a kind of cellular automaton, that is turing complete - i.e. the interaction of the genes *themselves* is equivalent to a computer program, and therefore quite possibly fundamentally unsolvable.
this is because proteins that genes produce can do more than just go away and make stuff for bodily processes, they can affect (turn off, turn on, conditonally flip, etc) the action of other genes.
so many people seem to have this idea that genes are just like a recipe, a linear list of stuff that goes to make up the organism. they're nothing like that.
your genes are a program like the worst spaghetti code ever written, multiplied a billion-fold. every emergent property of the system will be used - there's nothing to tell evolution to Keep It Simple, Stupid.
where does that leave the Human Genome Project? well, they know *something*. but my bet is that there are fundamental limits on the amount that we can ever actually know about how our genes work.
check out the papers on this page for a fascinating example of how evolution can create things we don't understand, even in an extremely limited domain.
also, Stuart Kauffman (of the Santa Fe Institute) has written a book "at home in the universe", the first part of which gives an excellent exposition of the above boolean net stuff. highly recommended.
anyway, isn't it obvious that the complexity of a system bears no relationship the complexity of the rules of that system. think of Life for example: only three rules, but given a large enough arena to play in, those rules are sufficient to simulate any computer... start it off from a random state, and it's fundamentally impossible to predict what it's going to do!
i have no problem with OO programming when it's about encapsulation of data behind a well-specified interface. that's the part that makes sense, allowing independent components to be reimplemented independently.
inheritance breaks all that. in particular the fact that you can (and probably will) inherit inappropriate superclass methods means that objects can often be broken by calling those methods.
instead of a "one interface, one purpose" scenario, you get "large numbers of slightly different interfaces, obscure numbers of purposes"! look at a diagram of the Java class hierarchy sometime to see what i mean.
i have found that the best code reuse is to be found by choosing well-designed, tight, and simple object APIs, using no inheritance at all. this approach avoids the constant fretting familiar in OO circles "how can i mutate that interface into the one i'm after?" a.k.a. "what should i inherit this object from?".
But that is a problem with the program as written, not with the interpreter. Say I had a file called blue/beard.txt (note: not a file called beard.txt in the directory blue). How do I ask Infernal to open it for me? I admit this is a specious argument but it could happen.
the system dependent part of the inferno kernel (devfs.c) could map all slashes that it saw when reading the filesystem to unicode character 2215 (division slash) or 2044 (division slash) or even 2298 (circled division slash) if you wanted the distinction to be crystal clear. the translation
would work the other way when filenames were presented to the kernel by inferno programs.
in this way, the whole thing works ok.
of course, it's not entirely perfect if the
user wants to be able to type in those pathnames, (the name isn't exactly what they would have expected) but using the standard graphical file browser, everything would work just fine.
the goal of Inferno is to have programs that genuinely run the same in any environment, not
to have programs that are kind of chameleon-like,
adopting some of the traits of the host environment. this decision is arguable, but it
is the only way to get true write once, run anywhere software. you don't true portability?
you know where to find Java.
Dare you assume that I don't need to know the endianness of the machine? A lot of what I do is getting systems to interoperate. Say I have a program, compiled for two different machines. It saves its data in the endianness of the host machine (just does a memory dump or such). Now I want to write a (binary) portable program to run on both machines to interpret these data files. Without knowing the endianness of the machine, I'm stuffed.
that's not true.
without knowing the endianness of the data file, you're stuffed. this is a distributed system, remember. filesystems, data, network interfaces, and devices can all be imported an exported completely transparently across machine boundaries. it sounds like you're still living in the old world, where the data on the file system you're accessing is guaranteed to be
on the same machine. that's just not true any more
(and hasn't been for at least a decade, if truth be told).
under Inferno, applications are completely unaware of where the files that they're accessing
have come from. (and don't forget that device access is also through the "file" namespace). the file i'm accessing might go straight to the local hard disk, or it might have been imported from a mounted connection obtained by using an imported network interface, connected over a USB link to some machine over an ATM link running a Limbo program that's exporting the file.
the resource deployment can be as simple or as complex as you like, but the applications themselves are blissfully unaware of what might be happening behind the scenes.
any binary data file worth its salt should either keep the data in a predefined endianness,
or declare the endianness in the header. that way,
someone on a sparc box will still be able to interpret the data file that you email them from a
linux x86 box.
Whether they'll work correctly or not is another matter. Is it not possible to make incorrect assumptions about the virtual hardware (such as whether there is a graphics interface available or not) or is the virtual hardware interface strictly defined?
all the hardware device interfaces reside in the namespace, so it's easy to probe to see whether a given device has been provided or not. an incorrect assumption will generate only a "file not found" error.
if the hardware is found, it will act according to its specifications - device control is all through the file interface. low bandwidth data is generally encoded in that universal, endian-independent format: text.
so, for instance, the interface to a tv device contains two files/dev/tv and/dev/tvctl. i can execute the shell command:
echo window 20 20 300 300 >/dev/tvctl
to set the currently displayed tv image rectangle.
a captured tv image can be read in a standard
image file format with:
cp/dev/tv/tmp/image.pic
it's as simple as that. this interface means that
it's possible to (for instance) write a user-level
program to simulate a device for which i haven't got the hardware, or to use the namespace
access protocol, Styx, to import or export the device across the network securely.
Note that I'm not trying to dis Inferno overall, I'm just not sure that the Inferno method of path handling is "correct". Heck, I'd even say that assuming a traversable directory tree is suspect (What a program should really call is system.UserFileInterface and let the underlying system handle it).
if the underlying system doesn't provide a hierarchical filesystem, that's not a problem.
the person porting to that system needs to make a decision how to map that filesystem into the inferno model. the "files" that are accessed under inferno aren't really "files" as most people think of them; it might be helpful to think of them as "hierarchical resources" which are accessed in exactly the same way as files.
a "file" under inferno requires no physical resources; it is merely an interface to some underlying software, whether that's a device driver, interpreting writes as commands, or a
disk filesystem, storing the data in each write to disk, as you'd expect of a normal file.
you could also think of the inferno namespace as a kind of hierarchical object space, in which each file provides a common set of methods (open, read, write, etc) which can be interpreted as appropriate for the object. looked at that way,
directory reading (inspecting metadata) becomes a
kind of "reflection", exposing capabilities of the system to an inquisitive program, which can then use them as appropriate.
this enquires to see if there is a tv device available, and if so sets a particular channel and
creates a small window for it at the top left of the screen. all without using any commands written specifically for the device.
ok, so that's not run everywhere, but
we're doing our best:-). i've probably forgotten a few.
and you could take any inferno program and run it
without change on any of the above platforms.(memory requirements permitting -
keeping a 1MB web image is difficult on a device with only 512K of RAM!)
ports to Netscape, MacOS X, and others should be forthcoming. happy?:-)
Heck, it's just a matter of abstraction. If you want to be able to use / then subclass the File object or something.
the way java does it, unless everyone writing java programs is extremely careful to write in a portable manner, you're going to end up with unportable programs.
the way inferno does it, you'd have to try extremely hard to write an unportable program.
what does that tell you about the relative portability of Java and Inferno programs?
And you know, there may be a filesystem where / is a valid part of a filename, then where is your Inferno?
i'll bet you most java programs won't cope properly when the path element separator is any possible character. (i remember
a system where '.' was the path
separator.
in the inferno way, all you
have to do is define a two-way mapping between
file names in the host system and file names
seen by programs inside inferno. as inferno uses Unicode throughout, you've got enough characters to play with.
The only safe way for platform portability is to have everything transparent.
that's rubbish, i'm afraid. in C, everything is transparent. the path separator is transparent, the endianness of the machine is transparent, in fact almost everything is transparent.
it's possible to write portable programs
in ANSI C, if you try hard, but that doesn't mean
that C is a particularly portable language.
Interestingly, using c++ on winnt, you can use either the '/' or '\' as a path separator which is quite handy for portability.
it's not handy for portability, it's handy for porting. programs written under c++ on winnt won't be any more or less portable than programs written under other c++ platforms.
in inferno, all programs are portable,
even if they're badly written.
they've got to glorify one of their worst nightmares from the past, that everything is a file, as if it weren't a horrible mistake.
it isn't a horrible mistake. it's an extremely well informed design decision.
There's nothing "universal" about a one-dimensional stream of 8 bit characters
no? apart from the fact that all computer data can be represented as bits... that sounds fairly universal to me!
representing resources as files provides an extremely useful abstraction layer and hierarchical naming scheme. in the inferno/plan9 scheme,
it also means that resources can be transparently exported through the network (a network being anything that provides a bidirectional stream of bits); no application knowledge or intervention is required.
it means that some simple tools become useful for an incredible range of tasks. compare to CORBA or Java for example, where you need a specialised piece of code for everything, giving you more bugs, less maintainability and lower productivity.
BTW, neither plan 9 or inferno have ioctl, one of unix's nastiest system calls.
So I could run a web browser inside IE5 ? If so, will inferno be avalaible as a plugin for that browser ?
yes, some day...:-)
for the moment, the web browser is small (works ok in 4MB, no hard disk), and keeping it unbloated
is more important to us than putting in loads of new plugin functionality.
the source code to the browser is free though, so if you want to do it, you're very welcome!
However, I remember an Othello game for the Apple II; I think it moved randomly. Therefore, I could almost always win, even back then. So I don't see the advantage.
well try beating this one!
if you don't have IE and Windows, you can always get the free download for Linux, and the source code from here, run "limbo reversi.b" and away you go.
I cannot imagine one single thing that this plugin enables you to do that the Java VM built into Internet Explorer already gives you. Apart from a 750k download, that is. It's got Tk, whoopy-f'n-doo: IE's got dhtml, Java, COM/ActiveX, Script, XML/XSLT.
one single thing?
the ability to run the exact same programs on
any of the platforms that run Inferno, native or hosted?
the freedom to write for a small, elegant
and powerful API in the most beautiful C-derived
language that there is?
if you've spent years learning the ins and outs of COM, Active X, etc, yes, it might come as a bit of shock to see that you can write sophisticated programs in a small amount of readable code.
but you can in Inferno. it's a genuinely better system, as you'd see if you actually tried using it. however, most people seem to be blind advocates of the nice, cosy, bloated system that
they're already familiar with.
After reading the information on the plugin, I fail to see how this is an OS in a browser.
The plugin allows you to run applications written in a specific language(Limbo) for the Inferno OS on your browser but isn't an OS in your browser from what I can see.
depends what you want to call an OS!
of course, from the host OS point of view, it's just another user-level program (or plug-in, for IE), but...
the environment provided to programs running inside Inferno is indistinguishable from the environment that they'd see if Inferno was running as a genuine OS on bare hardware (as it does, on several architectures, in as little as 512K of RAM).
moreover, at the OS source code level, the great majority of the code is identical from platform to platform (no ifdefs - this is genuinely portable C written by gurus of the language)
so, given that programs inside it can't tell the difference, i'd say there was a very strong case for saying it's an OS inside a browser. (even if the entire OS is booted just to run one program - boot time in 0.5 seconds, not too bad...)
I just wonder when a program similar to ICQ will be released.
it's funny you should say that.
i just had a look at the Linux ICQ client,
and the compressed source is 370K,
more than half the size of the Inferno plugin...
one of the nicest things about inferno is that
it's not bloatware. given that it has
Styx protocol support built in to its core, that has already solved
many of the hardest problems that people
seem to reinvent badly with each custom protocol, such as the one ICQ presumably uses.
The developers need to sit down for a minute so that they realize what they did: they built an OS into IE. Do you know how incredibly wrong that is?
well, i agree that given the horrible nature of IE, doing anything with it is incredibly wrong... (even using it:-])
however, it isn't like this is something unique to IE - Inferno runs as a "virtual OS" under all sorts of platforms, and this is just one of them.
the aim of Inferno is to provide a genuinely write once, run anywhere
programming environment, and the IE port is just
a slightly bizarre "somewhere".
it means that if you have a distributed system that incorporates several components running in different places, you can choose dynamically (no code modifications required) exactly where each component should go.
so for instance, if you had a peer-to-peer system,
the exact same program might be running under IE5, Linux, Plan 9, a PDA and a web phone,
and all communicating seamlessly.
if you write a program for Inferno, you get
all the platform support for free. unlike java,
the VM and libraries are not implemented independently (and subtly incompatibly) by multiple different companies.
and it's the very fact that it's an OS,
providing a layer of abstraction defining a general
interface for devices and other low-level resources, that allows it to be so good at its
job.
depending on how many other references still exist (and the reason you're using any form of collection is you don't know that
well, you don't know that in general, but it's quite possible to verify for specific cases. the collection just means that even if you do get your sums wrong, the maximum penalty is some extra memory usage, rather than a memory leak or some corrupt memory, as you'd get without a collector (e.g. in C).
Your working set will be bigger while the collector is running, but smaller the rest of the time
for a system like Inferno, designed to work on smallish devices, the maximum memory requirements are crucial. the ref counting scheme means that a given piece of code can have a tightly bounded memory usage independent of any other piece of code. this is important if you're trying to verify parts individually and create a system where the whole is the same as the sum of the parts.
And I thought the hit for paging was so catastrophic that realtime guys wired down their entire working set and ignored VM...
Inferno isn't a hard real-time system, and has never pretended to be. (the design of the system doesn't preclude it though, AFAIK). in particular, it can run hosted under another OS, such as Windows or Linux, in much the same way as the Java VM. it's my belief that part of the reason it performs well in this environment compared to Java is that the vast majority of garbage gets collected immediately, so the VM's run-time size never grows enormously, which in turn means that the process is less likely to be paged/swapped out.
mind you, probably the main reason for Inferno's good performance is the slim design of the whole system; an efficient garbage collector can only get you so far...
2. The proper approach seems to be a very limited operating system, perhaps in C, with a virtual machine over that which is proven secure, thereby giving at least strong security to every application then running ontop of that VM.
Yes you'll need to audit that first limited OS and kernel, and yes it'll probably be in C, but let's limit the scope of that code severely. Plan to take a huge performance hit on running everything on that VM but make sure that it's totally secure, do whatever it takes to make sure that everything running on it is protected from itself and other programs. This is the only possible way to make an extensible operating system that is in any way secure, otherwise any software that is later added to the system will either need to be painstakingly audited or not installed. Performance should be a minor concern at this point as VMs can later be optimized, and security should be of prime importance.
this is exactly the approach taken by
Inferno, which was designed and built by some of the best minds in computer science.
(e.g. Dennis Ritchie, Rob Pike)
the approach works very well; the only downside is that because you are doing things better, they are different which means you actually have to learn some new stuff.
even if the new stuff is actually more simple,
easier to use, and safer than the original.
people seem to prefer to learn new immensely complex interfaces such as Windows or Java... beats me why!
Slashdot Mirror
"Do one thing and do it well", a maxim that works excellently, but that most developers seem unaware of.
It's open source, written by some of the best people in the business, (the source code is beautiful) and its whole raison d'etre is to investigate how things should be done, instead of how they are usually done.
you might find some of your fundamental assumptions challenged and your paradigms shifted, but isn't that the point?! it keeps fundamentals of UNIX while discarding all the crud that's built up since the 7th Edition...
the answer to this question should be obvious to anyone that thinks about it... but i think our blinkered, reductionist, view of biology ("genotype == phenotype", "genes == organism") stops it being obvious to many people.
the information is stored in the molecules that make up your body, in combination with the laws of physics. think about a pool of water. you can describe it with a simple "take one molecule of water, replicate by 10^30". however, does that information describe the pool of water? nope - think about waves, interference patterns, surface tension, etc, etc...
the point is that the genes can create a structure that is initially uniform, but allows structure to form by virtue of the interactions of its elements. think about Conway's Life - it's described by some very, very simple rules - its complexity evolves from those rules (its "laws of physics") and the cells (its "molecules")
so you can see that our genes don't need to describe us in our entirety, but merely describe a structure from which something like us can arise, given the usual laws of physics and interactions with the external environment.
Yes!
It's nice to see that there are those Plan9 and Inferno folks out there - those that want to take all the Unix loveliness and fix the misfeatures and bugs. Too bad that it'll never catch on ;-( (Not trying to be a bastard here -- just being objective.)
well, we can always hope. because it is genuinely better, and perhaps the snowball will keep on getting bigger rather than breaking apart... it took a long time for unix to become mainstream, for example.
i'd like this to be the sort of world where it was possible for problems with existing systems to be fixed, not one in which we carry the broken legacy of the past into the 22nd century just because "it's always been that way"...
at least it's possible to use inferno inside existing systems, so i can use my (lovely! :-]) shell under most of the existing platforms today...
I also took a closer look at rc and your sh. (Wouldn't a different name have been appropriate?)
yes!
but i couldn't think of a decent one, so it ended up as sh by default... basic requirements: ideally it should be a max of 4 letters, ending in "sh", and characteristic of the shell itself. originally i'd named it "shell", for want of a better name - that was deemed too long (and it's not exactly more descriptive!)
They have some really powerful features. Especially the file descriptor replacement thing that you exemplify. (zsh-workers! Steal this feature!)
actually, from an earlier reply, it seems that someone already has... along with every other feature in the book, after the true GNU "cat -v" style...
actually, my shell doesn't have this feature in the core shell syntax - it's a builtin command, "pipe":
% cmp ${pipe from {echo hello}} ${pipe from {echo helloX}}
/tmp/pipes/pipe.121.1y /tmp/pipes/pipe.121.0y differ: char 6
it's somewhat more wordy, but this facility isn't used that often anyway, and you can do it...
By the way, zsh has a multiple redirection feature, but I'm pretty sure it won't work for stuff like cmp that needs two different inputs. It just concatenates things together into the input file descriptor, like "cat < file1 < file2")
what's the point? isn't it always possible to use cat and pipes to get this, in a much more regular way. e.g.
cat file1 file | command
what does it buy you? 2 characters of typed input?
But one thing that you miss is that these shells (zsh, bash, tcsh, etc.) are intended (at least in my mind) for interactive use. There's little need for being able to scroll back up in command history if you're programming a script.
my view is that the features for interactive use should be delegated to the interactive parts of the system. this allows a much more generally applicable approach; if you put such features in at a higher (lower?) level, then all command line commands, not just the shell, can benefit from them.
to illustrate, neither my inferno shell, or rc, contain any sort of command-line editing. however, i can always edit my command lines, because the window containing the shell (not a vt100 emulator!) allows editing of the command-line text before sending it to the application reading from /dev/cons (aka /dev/tty in unix). i can put the window into "hold mode"; then even if i press return, the shell doesn't see the input... until i exit hold mode. this allows me to edit multiple lines, for any command, without any command needing to be changed.
for instance, for creating small text files on the file, i can type (ESC toggles hold mode)
ESC
cat > myfile
some text
or a little script
^D
ESC
> for i in $*; do echo $i; done
> }
$ x 'a b' c
a
b
c
$
but i gave only two arguments to the function! ok, so in this particular case, you can use $@ to get around the problem. but what if i wanted to store the value of $* in another shell variable? i can't do it and maintain the original distinction between arguments.
this sort of thing can cause terrible security problems when filenames contain whitespace. it also makes it very hard to write robust shell scripts - you always have to be on your guard for quoting slip-ups.
the basic problem is that shell variables are simple strings, whereas the commands invoked by the shell take a vector of strings. so the shell splits up variables based on $IFS, not according to how they were originally created. i.e. the input is rescanned every time a command is invoked.
it's all unnecessary: the way rc copes is by holding everything as flat lists. so you can say:
% x=('a b' c)
% for (i in $x) echo $x
a b
c
no problem. you know what you've got, and it remains the same. isn't it lovely (not) when you can write:
$ cmd='ls'
$ IFS=s
$ $cmd -l
l: not found
yes, zsh and kin might have crept enough features to sink a battleship, but they still keep the old real problems from the original bourne shell.
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? :-(
it's as if i said, "i can predict the weather perfectly - i just wait and see what happens, and that's my prediction!". of course, the difference between Conway's Life and the normal universe is that we can take a copy of all the cells in a game of Life and run them independently of the "main" simulation. i don't think that's a fundamental distinction though. if the universe really was a game of Life at the bottom level, we'd be just as unable to predict it as if it was completely random underneath, because we're unable to find out the whole state of the universe in order to copy it and run it independently (not to mention you'd have to run a copy of the universe inside itself, a bit hard methinks!)
so, functionally, i don't think we could possibly tell the difference between a deterministic universe and a non-deterministic universe.
of course i agree that CAs are fundamentally deterministic (i've programmed enough of them!), but i do maintain that they're fundamentally unpredictable, in the same way that predicting arbitrary runtime properties of an arbitrary program is impossible - without actually running the program in question.
what's interesting is that you can prove certain properties of some programs, in the same way that you can find some invariants using the above CA topology display. i like to think of those invariants as the "laws of nature" in that CA. it's very obvious when you look at a few different CAs that each set of rules produces its own stable structures and its own emergent set of rules by which those interact. (think of the gliders, glider guns, blinkers, etc in Life).
i think this a nice way in which to perceive our own universe. the fact that something as simple as 2 bit single-dimensional CA can be fundamentally unpredictable should tell us much about the fundamental limits of scientific endeavour.
the thing about Conway's Life is that the smallest bit of the system can radically affect the whole; but you can't predict how... without solving the Halting Problem.
this is just like the real universe, where the effects of chaos amplify infinitesimally small noise into macroscopic effects. as the number of components in a deterministic system rises, the overall effect becomes more and more similar to "true randomness".
e.g. imagine a version of Conway's Life with 10^24 cells (a very small number by real-universe standards); and running at 10^12 steps per second. in one second, every one of the cells in this simulation is potentially influenced by every other, in a completely unpredicable way. if you're looking at one tiny bit of that system, then you'd find it extremely hard (nay, impossible!) to tell whether there were truly random impulses going on in the system.
by the above argument, i don't think that the distinction between deterministic and non-deterministic is so important. if you're looking at a small part of a very large system, the thing that really matters is the structure of that small part (i.e. how it reacts to external influences), not whether the system as a whole is predictable.
the universe as a whole might be deterministic, but we have no way of telling...
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.
this is because proteins that genes produce can do more than just go away and make stuff for bodily processes, they can affect (turn off, turn on, conditonally flip, etc) the action of other genes.
so many people seem to have this idea that genes are just like a recipe, a linear list of stuff that goes to make up the organism. they're nothing like that.
your genes are a program like the worst spaghetti code ever written, multiplied a billion-fold. every emergent property of the system will be used - there's nothing to tell evolution to Keep It Simple, Stupid.
where does that leave the Human Genome Project? well, they know *something*. but my bet is that there are fundamental limits on the amount that we can ever actually know about how our genes work.
check out the papers on this page for a fascinating example of how evolution can create things we don't understand, even in an extremely limited domain.
also, Stuart Kauffman (of the Santa Fe Institute) has written a book "at home in the universe", the first part of which gives an excellent exposition of the above boolean net stuff. highly recommended.
anyway, isn't it obvious that the complexity of a system bears no relationship the complexity of the rules of that system. think of Life for example: only three rules, but given a large enough arena to play in, those rules are sufficient to simulate any computer... start it off from a random state, and it's fundamentally impossible to predict what it's going to do!
inheritance breaks all that. in particular the fact that you can (and probably will) inherit inappropriate superclass methods means that objects can often be broken by calling those methods.
instead of a "one interface, one purpose" scenario, you get "large numbers of slightly different interfaces, obscure numbers of purposes"! look at a diagram of the Java class hierarchy sometime to see what i mean.
i have found that the best code reuse is to be found by choosing well-designed, tight, and simple object APIs, using no inheritance at all. this approach avoids the constant fretting familiar in OO circles "how can i mutate that interface into the one i'm after?" a.k.a. "what should i inherit this object from?".
the system dependent part of the inferno kernel (devfs.c) could map all slashes that it saw when reading the filesystem to unicode character 2215 (division slash) or 2044 (division slash) or even 2298 (circled division slash) if you wanted the distinction to be crystal clear. the translation would work the other way when filenames were presented to the kernel by inferno programs.
in this way, the whole thing works ok. of course, it's not entirely perfect if the user wants to be able to type in those pathnames, (the name isn't exactly what they would have expected) but using the standard graphical file browser, everything would work just fine.
the goal of Inferno is to have programs that genuinely run the same in any environment, not to have programs that are kind of chameleon-like, adopting some of the traits of the host environment. this decision is arguable, but it is the only way to get true write once, run anywhere software. you don't true portability? you know where to find Java.
Dare you assume that I don't need to know the endianness of the machine? A lot of what I do is getting systems to interoperate. Say I have a program, compiled for two different machines. It saves its data in the endianness of the host machine (just does a memory dump or such). Now I want to write a (binary) portable program to run on both machines to interpret these data files. Without knowing the endianness of the machine, I'm stuffed.
that's not true.
without knowing the endianness of the data file, you're stuffed. this is a distributed system, remember. filesystems, data, network interfaces, and devices can all be imported an exported completely transparently across machine boundaries. it sounds like you're still living in the old world, where the data on the file system you're accessing is guaranteed to be on the same machine. that's just not true any more (and hasn't been for at least a decade, if truth be told).
under Inferno, applications are completely unaware of where the files that they're accessing have come from. (and don't forget that device access is also through the "file" namespace). the file i'm accessing might go straight to the local hard disk, or it might have been imported from a mounted connection obtained by using an imported network interface, connected over a USB link to some machine over an ATM link running a Limbo program that's exporting the file.
the resource deployment can be as simple or as complex as you like, but the applications themselves are blissfully unaware of what might be happening behind the scenes.
any binary data file worth its salt should either keep the data in a predefined endianness, or declare the endianness in the header. that way, someone on a sparc box will still be able to interpret the data file that you email them from a linux x86 box.
Whether they'll work correctly or not is another matter. Is it not possible to make incorrect assumptions about the virtual hardware (such as whether there is a graphics interface available or not) or is the virtual hardware interface strictly defined?
all the hardware device interfaces reside in the namespace, so it's easy to probe to see whether a given device has been provided or not. an incorrect assumption will generate only a "file not found" error.
if the hardware is found, it will act according to its specifications - device control is all through the file interface. low bandwidth data is generally encoded in that universal, endian-independent format: text.
so, for instance, the interface to a tv device contains two files /dev/tv and /dev/tvctl. i can execute the shell command:
echo window 20 20 300 300 > /dev/tvctl
to set the currently displayed tv image rectangle. a captured tv image can be read in a standard image file format with:
cp /dev/tv /tmp/image.pic
it's as simple as that. this interface means that it's possible to (for instance) write a user-level program to simulate a device for which i haven't got the hardware, or to use the namespace access protocol, Styx, to import or export the device across the network securely.
Note that I'm not trying to dis Inferno overall, I'm just not sure that the Inferno method of path handling is "correct". Heck, I'd even say that assuming a traversable directory tree is suspect (What a program should really call is system.UserFileInterface and let the underlying system handle it).
if the underlying system doesn't provide a hierarchical filesystem, that's not a problem. the person porting to that system needs to make a decision how to map that filesystem into the inferno model. the "files" that are accessed under inferno aren't really "files" as most people think of them; it might be helpful to think of them as "hierarchical resources" which are accessed in exactly the same way as files.
a "file" under inferno requires no physical resources; it is merely an interface to some underlying software, whether that's a device driver, interpreting writes as commands, or a disk filesystem, storing the data in each write to disk, as you'd expect of a normal file.
you could also think of the inferno namespace as a kind of hierarchical object space, in which each file provides a common set of methods (open, read, write, etc) which can be interpreted as appropriate for the object. looked at that way, directory reading (inspecting metadata) becomes a kind of "reflection", exposing capabilities of the system to an inquisitive program, which can then use them as appropriate.
for instance i could write a little shell script:
if {ftest -f /dev/tv} { /dev/tvctl /dev/tvctl
echo channel 3 >
echo window 0 0 40 40 >
}
this enquires to see if there is a tv device available, and if so sets a particular channel and creates a small window for it at the top left of the screen. all without using any commands written specifically for the device.
that's true power.
oh yes, i forgot:
IE is just the latest addition to the current set of Inferno platforms.
at the moment, it runs on:
ok, so that's not run everywhere, but we're doing our best :-). i've probably forgotten a few.
and you could take any inferno program and run it without change on any of the above platforms.(memory requirements permitting - keeping a 1MB web image is difficult on a device with only 512K of RAM!)
ports to Netscape, MacOS X, and others should be forthcoming. happy? :-)
the way java does it, unless everyone writing java programs is extremely careful to write in a portable manner, you're going to end up with unportable programs.
the way inferno does it, you'd have to try extremely hard to write an unportable program.
what does that tell you about the relative portability of Java and Inferno programs?
And you know, there may be a filesystem where / is a valid part of a filename, then where is your Inferno?
i'll bet you most java programs won't cope properly when the path element separator is any possible character. (i remember a system where '.' was the path separator.
in the inferno way, all you have to do is define a two-way mapping between file names in the host system and file names seen by programs inside inferno. as inferno uses Unicode throughout, you've got enough characters to play with.
The only safe way for platform portability is to have everything transparent.
that's rubbish, i'm afraid. in C, everything is transparent. the path separator is transparent, the endianness of the machine is transparent, in fact almost everything is transparent.
it's possible to write portable programs in ANSI C, if you try hard, but that doesn't mean that C is a particularly portable language.
Interestingly, using c++ on winnt, you can use either the '/' or '\' as a path separator which is quite handy for portability.
it's not handy for portability, it's handy for porting. programs written under c++ on winnt won't be any more or less portable than programs written under other c++ platforms.
in inferno, all programs are portable, even if they're badly written.
it isn't a horrible mistake. it's an extremely well informed design decision.
There's nothing "universal" about a one-dimensional stream of 8 bit characters
no? apart from the fact that all computer data can be represented as bits... that sounds fairly universal to me!
representing resources as files provides an extremely useful abstraction layer and hierarchical naming scheme. in the inferno/plan9 scheme, it also means that resources can be transparently exported through the network (a network being anything that provides a bidirectional stream of bits); no application knowledge or intervention is required.
it means that some simple tools become useful for an incredible range of tasks. compare to CORBA or Java for example, where you need a specialised piece of code for everything, giving you more bugs, less maintainability and lower productivity.
BTW, neither plan 9 or inferno have ioctl, one of unix's nastiest system calls.
yes, some day... :-)
for the moment, the web browser is small (works ok in 4MB, no hard disk), and keeping it unbloated is more important to us than putting in loads of new plugin functionality.
the source code to the browser is free though, so if you want to do it, you're very welcome!
However, I remember an Othello game for the Apple II; I think it moved randomly. Therefore, I could almost always win, even back then. So I don't see the advantage.
well try beating this one! if you don't have IE and Windows, you can always get the free download for Linux, and the source code from here, run "limbo reversi.b" and away you go.
the same applies to tetris, if you're interested.
one single thing?
the ability to run the exact same programs on any of the platforms that run Inferno, native or hosted?
the freedom to write for a small, elegant and powerful API in the most beautiful C-derived language that there is?
if you've spent years learning the ins and outs of COM, Active X, etc, yes, it might come as a bit of shock to see that you can write sophisticated programs in a small amount of readable code.
but you can in Inferno. it's a genuinely better system, as you'd see if you actually tried using it. however, most people seem to be blind advocates of the nice, cosy, bloated system that they're already familiar with.
more buzzwords don't imply a more useful system.
The plugin allows you to run applications written in a specific language(Limbo) for the Inferno OS on your browser but isn't an OS in your browser from what I can see.
depends what you want to call an OS! of course, from the host OS point of view, it's just another user-level program (or plug-in, for IE), but...
the environment provided to programs running inside Inferno is indistinguishable from the environment that they'd see if Inferno was running as a genuine OS on bare hardware (as it does, on several architectures, in as little as 512K of RAM).
moreover, at the OS source code level, the great majority of the code is identical from platform to platform (no ifdefs - this is genuinely portable C written by gurus of the language)
so, given that programs inside it can't tell the difference, i'd say there was a very strong case for saying it's an OS inside a browser. (even if the entire OS is booted just to run one program - boot time in 0.5 seconds, not too bad...)
it's funny you should say that. i just had a look at the Linux ICQ client, and the compressed source is 370K, more than half the size of the Inferno plugin...
one of the nicest things about inferno is that it's not bloatware. given that it has Styx protocol support built in to its core, that has already solved many of the hardest problems that people seem to reinvent badly with each custom protocol, such as the one ICQ presumably uses.
well, i agree that given the horrible nature of IE, doing anything with it is incredibly wrong... (even using it :-])
however, it isn't like this is something unique to IE - Inferno runs as a "virtual OS" under all sorts of platforms, and this is just one of them. the aim of Inferno is to provide a genuinely write once, run anywhere programming environment, and the IE port is just a slightly bizarre "somewhere".
it means that if you have a distributed system that incorporates several components running in different places, you can choose dynamically (no code modifications required) exactly where each component should go.
so for instance, if you had a peer-to-peer system, the exact same program might be running under IE5, Linux, Plan 9, a PDA and a web phone, and all communicating seamlessly.
if you write a program for Inferno, you get all the platform support for free. unlike java, the VM and libraries are not implemented independently (and subtly incompatibly) by multiple different companies.
and it's the very fact that it's an OS, providing a layer of abstraction defining a general interface for devices and other low-level resources, that allows it to be so good at its job.
well, you don't know that in general, but it's quite possible to verify for specific cases. the collection just means that even if you do get your sums wrong, the maximum penalty is some extra memory usage, rather than a memory leak or some corrupt memory, as you'd get without a collector (e.g. in C).
Your working set will be bigger while the collector is running, but smaller the rest of the time
for a system like Inferno, designed to work on smallish devices, the maximum memory requirements are crucial. the ref counting scheme means that a given piece of code can have a tightly bounded memory usage independent of any other piece of code. this is important if you're trying to verify parts individually and create a system where the whole is the same as the sum of the parts.
And I thought the hit for paging was so catastrophic that realtime guys wired down their entire working set and ignored VM...
Inferno isn't a hard real-time system, and has never pretended to be. (the design of the system doesn't preclude it though, AFAIK). in particular, it can run hosted under another OS, such as Windows or Linux, in much the same way as the Java VM. it's my belief that part of the reason it performs well in this environment compared to Java is that the vast majority of garbage gets collected immediately, so the VM's run-time size never grows enormously, which in turn means that the process is less likely to be paged/swapped out.
mind you, probably the main reason for Inferno's good performance is the slim design of the whole system; an efficient garbage collector can only get you so far...
cheers, rog.
Yes you'll need to audit that first limited OS and kernel, and yes it'll probably be in C, but let's limit the scope of that code severely. Plan to take a huge performance hit on running everything on that VM but make sure that it's totally secure, do whatever it takes to make sure that everything running on it is protected from itself and other programs. This is the only possible way to make an extensible operating system that is in any way secure, otherwise any software that is later added to the system will either need to be painstakingly audited or not installed. Performance should be a minor concern at this point as VMs can later be optimized, and security should be of prime importance.
this is exactly the approach taken by Inferno, which was designed and built by some of the best minds in computer science. (e.g. Dennis Ritchie, Rob Pike)
the approach works very well; the only downside is that because you are doing things better, they are different which means you actually have to learn some new stuff. even if the new stuff is actually more simple, easier to use, and safer than the original. people seem to prefer to learn new immensely complex interfaces such as Windows or Java... beats me why!
you can get it from http://www.vitanuova.com/inferno/.
and it's not slow either.