Inferno 4 Available for Download

Tarantolato writes "A new preliminary public release of the Inferno distributed operating system is now available for downloading from Vita Nuova's website. Inferno is meant to be a better Plan 9, which was meant to be a better Unix. It can run as a standalone OS, as an application on top of an existing one, or even as a browser plugin. Also, all of its major components are named after things related to hell."

Comments

inferno?

[wvitXpert]

never heard of it... is it hell to use?

Re:inferno?

[earlgreen]

No, that's called Windows.

Re:inferno?

[Anonymous Coward]

Just download, burn the CD, and fire it up. You may think it smokes, but I'll be damned if I can see what the devil is so hot about it.

Re:Inferno?

[frenetic3]

If you look at some of the docs, there seem to be a bunch of Bell Labs folks contributing (perhaps even principal developers)... including a doc by Brian Kernighan and lo and behold, Dennis Ritchie, the authors of one of the canonical C books ("The C Programming Language" -- more affectionately known as "K&R".)

Could be interesting stuff, especially the Limbo "C-like, concurrent" programming language (though the syntax seems like an ugly version of Python with some bizarre odds and ends tacked on like a <- operator for "channels").

-fren

Re:inferno?

[MrIrwin]

" is it hell to use?"

Managing daemon apps is apparently very easy, but sending stuf to /dev/null can be quite spectacular ;-)

Or so they tell me, I am stuck with Windows, the orginal devils OS.

Re:Inferno?

[Anonymous Coward]

Those circles and arrows aren't tacked on. They wrote the entire thing using lightweight pipes AKA 'rendezvous'. It's some clever combination of kernel and user-level threading. Inferno was *almost* famous. It had the grave misfortune of being released 1 year after java 1.0. The final nail in the coffin came from Oracle's Ellison, who pussyfooted around with the idea of using it in the Network PC (remember that?) before putting the kibosh on the whole deal.

-- Anon Coward

Re:Inferno?

[zhenlin]

This is mostly because it is based on Plan 9, which was developed at Bell Labs, where UNIX was developed.

Trust me, it is all very interesting stuff. Just don't let it slip that you use the heathen UNIX, especially on #plan9 on FreeNode.

Re:Inferno?

[Anonymous Coward]

K&R, also the authers of the C language, but I suppose the book was more of an achievement?

Re:Inferno?

[slamb]

Could be interesting stuff, especially the Limbo "C-like, concurrent" programming language (though the syntax seems like an ugly version of Python with some bizarre odds and ends tacked on like a <- operator for "channels").

I don't see the resemblance to Python. Limbo has:

• explicit static typing to Python's dynamic typing. (I don't like either; I prefer ML-style type inference.)
• declarations and definitions in separate files. This is an aid to the compiler, not the person; the compiler should be able to separate them as with Java, Python, C#, Ruby, Perl, and every other modern language. When editing, it's much more friendly to change these in one place. If you want to see the declarations only, you still can - through Javadoc-style tools or through a folding text editor.
• graphics through Tk. Meaning embedded strings in a completely different, interpreted programming language. With escaping hassles, because stuff like button names is right in the middle of the embedded control string.
• curly braces to denote scope, rather than Python's whitespace. Like many languages, but I like the Python way better.
• no functional programming features (lambda functions, tail recursion, etc). Or if it has them, they're not mentioned in this paper.
• no support for keyword arguments, that I can see. (Like Python, PL/SQL, Ada, VHDL, etc. have. They make function calls much easier to interpret without flipping back and forth to a API manual.)
• the channel feature you mentioned. It seems like a suckier version of Erlang's message-passing.

I don't see any redeeming qualities.

Re:Inferno?

[warrax_666]

declarations and definitions in separate files. This is an aid to the compiler, not the person;

Wrong. Compilers do not need separate interface definitions. They might just as well use the source files and find all the definitions there.

There is actually a very good (programmer-centric) reason for doing having separate interface/implementation: If you want to remain completely (binary or source) interface-compatible you just lock down the interface file. If the language is strongly typed and pedantic about matching type/function/value definitions exactly it will complain if you accidentally change the declaration of a function (this is particularly easy to do accidentally in type-inferenced languages like ML). Thus, you can ensure interface compatibility in this very simple way.

(Of course, in C/C++ this is not nearly that useful because compilers usually don't actually check any of this. But it works very well).

Re:Inferno?

[anothy]

Inferno was developed by the same lab - and many of the same individuals - who developed Plan 9 and, earlier, Unix. that lab did all the early development, and while the primary development is now done by Vita Nuova, there remains collaboration between them (and it helps that Plan 9 and Inferno are very similar under the hood).

Of particular note is that Dennis Ritchie has written exactly two language reference manuals in his life: C and Limbo. that says a lot to me, anyway.

name dropping aside, Limbo really is a huge win for user-mode programming. the channel stuff isn't bizarre at all - it's a very elegant way to handle inter-process communication. Python's got nothing on Limbo for this.

Re:Inferno?

[slamb]

Wrong. Compilers do not need separate interface definitions. They might just as well use the source files and find all the definitions there.

Compilers do not need them if properly designed, as with the many modern languages I cited.

But C and C++ require this. Ever notice how in C and C++, you can't refer to an undeclared type, even if it is declared later in the file? You have to provide at least a forward definition. ("class Bob;") Likewise functions, data members, etc. This is most annoying in C++, with inline functions. You have to pay attention to ordering. In other languages, you do not.

There is actually a very good (programmer-centric) reason for doing having separate interface/implementation: If you want to remain completely (binary or source) interface-compatible you just lock down the interface file.

Okay...that's great for those 1% of people who want the interface file to remain absolutely static. And I mean absolutely static. No new methods. No changes to the comments. No nothing. (In fact, I doubt there are even 1% of people who want this, once they give it some thought.)

For the remaining 99% of us, this is unwanted Bondage and Discipline.

Maybe the people who want the interface to remain static can do so in a more intelligent way. Like comparing javap output on check-in and ensuring the old methods are there, with the same signatures as before. If they're this strict, that shouldn't be a problem - they already have checkin tests to ensure all unit tests pass. Adding another condition shouldn't be a problem.

Re:Inferno?

[Anonymous Coward]

When I was at Bell Labs, I wrote some fairly
substantial software under Inferno. It has
some nice features, and is by far the
cleanest environment for multithreading
that I've ever seen.

At the time (c. 2000), it had a few misfeatures,
such as no way to signal that you've closed
a channel between two threads, but hopefully
that's been fixed. Limbo is a nice, clean
language. It isn't object oriented: think of
it as the ideal C, rather than python, java or
C++. However, interestingly enough,
you can do large-scale OO things reasonably
nicely in two ways:

First, for objects that are more like lightweight
daemons, you can have a thread that simulates
a file (or file system, even). The rest of
the program can then read and write to that
special file to interact.
One can be OO by implementing a whole directory,
where each file corresponds to a OO message
(member function).

Second, for even ligher weight stuff,
you can easily (trivially easily, compared
to most languages) spawn a thread that
talks via the rendevous mechanism,
and treat that as a little light-weight
server to which you can pass
arbitrary data structures.

There's no support for fine-grained OO,
which was, I think, a reaction to some
of the OO-idiots out there that
insist on making objects out of things
that aren't naturally separable.

The failing is that there are not
extensive libraries, and there is certainly
not much in the line of applications that
one can download.

It is very elegant in many respects.
If you need to write multi-threaded things,
and can live without much in the way of
libraries or applications, you should think
about it.

Re:Inferno?

[martinde]

> Ever notice how in C and C++, you can't refer to an undeclared type, even if it is declared later in the file?

You could "fix" this feature of C/C++ inside a single file by doing a two pass compilation, but since there is no mapping from function name to file name you cannot fix it in general without doing something very radical. (Scan all source files to build a symbol table, require each function be in its own file, or something else really ugly.)

A C++ compiler could enforce it's own file-naming standard for classes (like Java) and then it would know where to look for class and method definitions when it sees them for the first time. Such a compiler would be non-compliant with the standard of course.

> And I mean absolutely static. No new methods. No changes to the comments. No nothing. (In fact, I doubt there are even 1% of people who want this, once they give it some thought.)

Ummm, even in C/C++ you can change comments in an interface and it won't break its linkage. You cannot, of course, add methods to a class, change signatures, etc. without breaking the interface.

But again, just looking at Java, I _think_ you could add methods to an interface and old users of the library would continue to function without recompilation. (You definitely can't modify signatures in existing methods.) This is because the Java Virtual Machine does resolution of class and method names at runtime - it does a symbolic lookup the first time it uses a class or method.

In languages like C/C++ the compiler generates calls to functions and methods using fixed offsets that are calculated at compilation time. Move one offset and suddenly your library is incompatible.

I tend to agree with the first poster that having the capability to define separate interfaces and implementations is a nice feature in a language. I don't know that it should be forced down your throat, but having the capability is nice.

Re:Inferno?

[warrax_666]

Compilers do not need them if properly designed, as with the many
modern languages I cited.

But C and C++ require this. Ever notice how in C and C++, you can't refer to an undeclared type, even if it is declared later in the file? You have to provide at least a forward definition. ("class Bob;") Likewise functions, data members, etc. This is most annoying in C++, with inline functions. You have to pay attention to ordering. In other languages, you do not.

This is unrelated to whether or not you require a separate interface file. The reason that the forward declaration exists is that you cannot declare circular types (such as linked list elements) without them. In all other cases, you can just sort the declarations topologically and write them out in that order.

Besides, what you're saying is true even of "properly designed languages" like ML. Just try:

type list_of_a =
Cons a list_of_a
| Nil;

type a =
int;

It doesn't compile, but it DOES work if you use:

type list_of_a =
Cons a list_of_a
| Nil
and type a =
int;

(note the and)

So you're basically talking about a syntactical problem in C/C++ which forces you to declare (textuall) things in a topological order.

Okay...that's great for those 1% of people who want the interface file to remain absolutely static. And I mean absolutely static. No new methods. No changes to the comments. No nothing. (In fact, I doubt there are even 1% of people who want this, once they give it some thought.)

For the remaining 99% of us, this is unwanted Bondage and Discipline.

Making up a statistic is never a good way to argue a point.

Besides, nobody said anything about forcing you to use separate interface/implementation. I just said to it could be a good thing to use it and have it be supported by the compiler.

In my preferred language, OCaml, you have the option of having a separately declared interface (a .mli file) or not having one. If you have one, the compiler will rigorously check that your code complies with the declared interface. If you don't have one, it will just generate the interface your code implements.

By the way, since you brought them up, declaring a proper interface is much more important in type-inferencing languages, since even tiny
changes to code can cause completely different types to be inferred. For example, in OCaml:

let f x =
x + 5;

let g x =
x +. 5;

f and g have different signatures even though the difference is tiny. If you're interfacing to binary libraries it helps immensely to know that the library would not have compiled if such a type-altering change has occurred in the "hidden" code.

Maybe the people who want the interface to remain static can do so in a more intelligent way. Like comparing javap output on check-in and
ensuring the old methods are there, with the same signatures as before.

You call that intelligent? Instead of just having the compiler do it? It already knows all about type aliases, what types are compatible,
etc. etc. (i.e. all the stuff that makes checking such things using a postprocessor extremely error-prone).

Re:Inferno?

[Quixote]

Inferno was *almost* famous. It had the grave misfortune of being released 1 year after java 1.0.

No, I think mistake that Bell Labs made was to charge everybody (including Joe User, the hobbyist) for the OS. Nobody could download it for free and try it out. You had to pay for it.
If I'm a hobbyist and just want to try something out, I don't feel like shelling out $100 for something that seems quite esoteric.
Basically, BL's desire to milk it completely destroyed Plan9's chances. Couple that with Linux's surge, and Plan9 was doomed.
Later, much later, they released it for free, but by then it was too little, too late.

Re:Inferno?

[vegetasaiyajin]

K&R, also the authers of the C language, but I suppose the book was more of an achievement?

Only Dennis Ritchie is the author of the C language. Kernighan was involved only in the book.

Re:Inferno?

[F2F]

s/BL/Lucent/g

if it was up to BL Plan 9 would have been released under a BSD license long ago.

Re:Inferno?

[Tellalian]

graphics through Tk. Meaning embedded strings in a completely different, interpreted programming language. With escaping hassles, because stuff like button names is right in the middle of the embedded control string.

You make some good points, but it should be noted that Python also has graphics through Tk, in the form of Tkinter, a Tk based GUI library. However, since the API is completely wrapped in Python, there's no similar hastle to what you've mentioned.

Re:Inferno?

[rpeppe]

expicit static typing to Python's dynamic typing. (I don't like either; I prefer ML-style type inference.)

Actually, Limbo does use a certain amount of type inference (although it doesn't go nearly as far as ML). I can say: x := y; and x will be given the same type as y and assigned its value. This is more useful when dealing with functions, e.g.

x := f();
g(x);
h(x);

You don't need to know what the return type of f is called, but the code gets properly statically checked. This is more than just syntactic convenience; it makes code transformation easier, because the code has less dependencies.

declarations and definitions in separate files....When editing, it's much more friendly to change these in one place

Inferno is very much about reusable software - it is formed of specialised components that can plug together in many different ways in order to create the system you're after. The key here is to have specialised, replacable components with narrow interfaces. Limbo modules are designed with this in mind. The declaration and the definition of a Limbo module are two completely independent things. All modules are loaded dynamically (but with assured static type checking). When you write a module, you implement a particular interface. Many modules might implement an interface (each differently), and many modules might use a particular interface - it's the interface itself (the header file) which is the most important component. Hence it makes complete sense for this to be in its own file. Implementation and interface are two completely separable things (you can declare your own interface locally if you wish to be completely independent).

graphics through Tk. Meaning embedded strings in a completely different, interpreted programming language.

This is debatable. For a start, Limbo strings are dead easy to use, 'cos they're a first class type, like integers or reals. So strings are actually quite a convenient representation for many things within the language.

Also, a GUI toolkit is a really big and complex thing. If you do everything in the language proper, you have to map all the GUI concepts to abstractions within the language. This results in an interface that is really big, and not necessarily easier to use (although it will let the compiler do more checking).

The Limbo tk module interface is 25 lines, comprising a grand total of 10 functions. It's really quite easy to comprehend what's going on - and the fact that all commands are strings makes it trivial to write a little prototyping shell, where you can knock up little GUI components interactively, or experiment without having to write an limbo code. You can even write little UI components in the shell.

the channel feature you mentioned. It seems like a suckier version of Erlang's message-passing

Channels are one of Limbo's most important features. Unlike Erlang's message passing, Limbo's channels are strictly local affairs - and synchronous. They're used to solve a different problem from Erlang's messages - Erlang's messages are intentionally asynchronous and unreliable. If you wish to pass messages reliably between system components, you have to build some reliability on top.

Limbo's channels are designed to make it easy to manage concurrency. In a networked application, you've usually got many things happening simulataneously - very cheap processes and message passing down channels makes it easy to structure an application as separate, independent processes, each dealing with one aspect of the program's concurrent behaviour. The usual thread-library stuff (locks, semaphores, etc) is stone age compared to this.

I don't see any redeeming qualities

Try using it. You'd be pleasantly surprised. It really is a beautiful language.

Re:Inferno?

[rpeppe]

At the time (c. 2000), it had a few misfeatures, such as no way to signal that you've closed a channel between two threads

Actually, that's not a misfeature, but a fundamental (and desirable, I think) part of the way that channels work. The point is that, unlike pipes, channels have just a single endpoint. Any process can use that endpoint for reading or writing as it likes - the runtime system will sort out the rendezvous.

So there's no real concept of a channel being "between" two threads. It just exists, and processes use it to exchange data. If a reader of a channel gets killed off, who is to say that that is not intentional?

Channels are a local thing, in the same way that function calls are a local thing. You can use them to structure your program in a similar kind of way that you might use functions. If you want to make one section of your program reslient to another sesction crashing, then channels are not the way to do this - you can use the namespace, which does provide such notification, instead (this also lets you distribute functionality across machines).

Re:Inferno?

[scrytch]

> the channel feature you mentioned. It seems like a suckier version of Erlang's message-passing.

And as far as local process control goes, not so different than stackless python. Stackless channels can be subclassed, and tasklets can be pickled, so turning that into remoteable channels ala Erlang is, well, an exercise to the reader (as in not requiring any C)

Arguably it's a better VM than Java for applications that demand erlang-like concurrency and footprint. But Tcl/Tk, eww..

Re:Inferno?

[killjoe]

I kind of like Delphi way of making you put the interface on top of the module. When you are programming it's kind of a pain but when you want to use somebody elses modules or even your own modules that you wrote long time ago it's awsome to have all the function signatures listed on top of the file.

There are many things in delphi that annoy me to no end but that's one aspect that I really like.

Re:Inferno?

[anothy]

i downloaded Inferno for free to play around with in '96. i believe it stayed that way. you didn't get the C source, but you got all the Limbo source (possibly not the compiler, if i remember right). it's not everything, but it's plenty if you're really just interested in trying it out.

also, you're improperly conflating plan 9 and inferno. this is fine in many technical senses, but the license histories are quite different. you're closer to the mark WRT plan 9, which was ~$350 to get anything beyond the very minimal 4-floppy distribution.

Re:Inferno?

[slamb]

Ahh. Yeah, there you do. I was thinking of:

def a(): b()
def b(): a()

Python actually has it easy in that it doesn't check stuff like this is valid until the function is called. I could made a() call c() (which is never declared) and I wouldn't get an error until I call a().

Re:Inferno?

[slamb]

You could "fix" this feature of C/C++ inside a single file by doing a two pass compilation, but since there is no mapping from function name to file name you cannot fix it in general without doing something very radical.

Right. I don't really expect anyone to change this about an existing language (or backward-compatible one like C++ or Objective-C). But here they made an entirely new language and did the same thing. I don't understand why; every other modern language I've seen has decided the #include system is inadequate. You can (through import or however) refer to an externally-defined class that in turn refers to the one you're about to define. Without worrying about forward definitions or paying attention to ordering at all.

Ummm, even in C/C++ you can change comments in an interface and it won't break its linkage.

Right, which is why it would be silly to completely lock down the file which defines the interface, as the original poster was advocating.

You cannot, of course, add methods to a class, change signatures, etc. without breaking the interface.

As you mentioned, the first of these (the "fragile base class" problem) does not apply to Java. I'd hope it doesn't apply to Limbo either, since it's also a VM system.

I tend to agree with the first poster that having the capability to define separate interfaces and implementations is a nice feature in a language. I don't know that it should be forced down your throat, but having the capability is nice.

Of course it's good to be able to define a separate interface and implementation. That's what Java's interface is for, or just completely-abstract classes in C++.

But that's distinct from the redundant declarations that C/C++/Objective-C and Limbo force you to do. Those declarations accomplish nothing - to achieve a meaningful separation, you need a separate class. They're just redundant, and painfully so.

Re:Inferno?

[slamb]

So you're basically talking about a syntactical problem in C/C++ which forces you to declare (textuall) things in a topological order.

Yes. Limbo shares it, and I don't understand why. If it were like Java in this way, these declarations and forward definitions would not be necessary.

Besides, nobody said anything about forcing you to use separate interface/implementation. I just said to it could be a good thing to use it and have it be supported by the compiler.

Limbo is forcing me to use them, as near as I can tell from the tutorial.

By the way, since you brought them up, declaring a proper interface is much more important in type-inferencing languages, since even tiny changes to code can cause completely different types to be inferred.

Good to know. I haven't yet built a system in OCaml large enough to run into that problem.

You call that intelligent? Instead of just having the compiler do it? It already knows all about type aliases, what types are compatible, etc. etc. (i.e. all the stuff that makes checking such things using a postprocessor extremely error-prone).

More intelligent than just checking that the interface's text file hasn't changed. I see now that wasn't what you were describing, but when I wrote my reply, I thought it was.

Re:Inferno?

[warrax_666]

I just re-read my reply (the parent), and realize I came off as a bit rude. Apologies for that, no offense meant.

Re:Inferno?

[slamb]

Actually, Limbo does use a certain amount of type inference (although it doesn't go nearly as far as ML).

Cool! You should mention that in "A Descent into Limbo"; it's a nice feature. (I can see how it would indeed be useful for code transformation.)

When you write a module, you implement a particular interface. Many modules might implement an interface (each differently), and many modules might use a particular interface - it's the interface itself (the header file) which is the most important component.

It is more than the redundant declarations/definitions of C/C++, then. That's cool. It'd still be nice if I didn't have to go through this for the "Hello world" module, though, or for other situations where the one implementation is enough. I prefer simple abstract classes or Java's interface. They're there but not mandatory.

Also, a GUI toolkit is a really big and complex thing. If you do everything in the language proper, you have to map all the GUI concepts to abstractions within the language. This results in an interface that is really big, and not necessarily easier to use (although it will let the compiler do more checking).

I'm missing the advantage of having a smaller interface in the language proper, when you've just moved it to another language embedded in strings rather than simplifying it.

What I am seeing is the pain of dealing with two syntaxes. And the pain of escaping things if your interface is dynamic. For instance, localized strings. This is ugly:

tk->cmd(t, "button .b -text {" + _("hello, world") + }");

and error-prone. What if the dynamically-generated string contained a }? You have escaping worries. Which is a continual problem for people in SQL. I always use bind variables to avoid it. I don't see an equivalent structure here.

None of that would be necessary with a Java-style interface:

Button b = new Button(_("hello world"));

Plus, as you mentioned, the compiler could find errors for you. I like catching errors as soon as possible; that's why I prefer type inference to dynamic typing.

Limbo's channels are designed to make it easy to manage concurrency. In a networked application, you've usually got many things happening simulataneously - very cheap processes and message passing down channels makes it easy to structure an application as separate, independent processes, each dealing with one aspect of the program's concurrent behaviour. The usual thread-library stuff (locks, semaphores, etc) is stone age compared to this.

True. This is what attracted me to Erlang. I confess; I don't quite understand the distinction between the two that you are making.

Try using it. You'd be pleasantly surprised. It really is a beautiful language.

Maybe. But there are so many languages; I don't have time to try them all. I want to at least do more with OCaml and Erlang a while first.

Re:Inferno?

[slamb]

Accepted gladly. An apology is a rare thing on slashdot.

Re:Inferno?

[rpeppe]

It'd still be nice if I didn't have to go through this for the "Hello world" module, though"

Actually, the only reason that the "hello world" example contains its own module declaration is so that the ps listing shows the correct name for the newly written process. You could just as easily do:

implement Command;
include "sys.m";
include "draw.m";
include "sh.m";

init(ctxt: ref Draw->Context, argv: list of string)
{
sys := load Sys Sys->PATH;
sys->print("hello, world\n");
}

Here, the "sh.m" header file provides the declaration of the Command module interface.

...or for other situations where the one implementation is enough.

Actually, the above code is one of the canonical examples where one implementation is not enough. The only reason the above program can be invoked by the shell is that the shell loads it as a module, expecting it to implement the Command interface. Every command-line program is an implementation of the Command module!

If a module doesn't implement any module interface, then there's no way for any other module to invoke it, so it might as well not exist! (although a module interface containing nothing at all can occasionally be useful - it's compatible with all other module interfaces, for example, so you can use it to cache modules, even though you can't do anything with them).

The best bit about the module interface stuff is that there's no inheritance - you can look at one interface declaration and see the whole picture; conversely, when designing a piece of software, you can start by designing the interface, deferring entirely how you might implement it. This really helps to keep the number system interdependencies (and hence overall complexity) down.

What if the dynamically-generated string contained a }

I agree that the combining of the two languages isn't very pretty... then again what you lose in prettiness you gain in other ways. BTW The Inferno tk has a superquote convention, so you could do:

tk->cmd(t, "button .b -text '"+_("hello, world"));

and it would work regardless of what the string translated to. There's also a "quote" function in the tk module, so:

tk->cmd(t, "button .b -text "+tk->quote(_("hello world")));

would work fine too.

Plus, as you mentioned, the compiler could find errors for you. I like catching errors as soon as possible; that's why I prefer type inference to dynamic typing

While I agree in principle here, I think you'll find that any language has a more-or-less arbitrary dividing line between static and dynamic typing, depending on where you draw the line between language-level objects and program-interpreted values. A static type system is a way of expressing some invariants in the program such the compiler can check that they will never be broken. You can't do this for all aspects of every program, otherwise we'd have a compiler that could prove any program correct (which we know to be impossible).

So, for any given API, where we draw the line between statically- and dynamically-checked aspects of the program is a matter of taste. If we were to go down the statically checked route with Tk objects, we'd have to map all aspects of the tk interface into Limbo objects. So your new Button(...) example is vastly incomplete. In the Tk interface, for a new button, one can specify background colour, foreground colour, justification, font, etc, etc. One would have to invent language-level objects for all these things (instead of using "red", you'd perhaps have to create a new Colour object, initialised in an appropriate way that you could then pass to the Button's "setcolour" method (excuse brit spelling).

I like the way that by defining a small, special-purpose language, one

Re:Inferno?

[slamb]

I'm starting to understand what you're saying with the module stuff. So:

• one module interface, many module implementations
• any functionality not given in a module interface is inaccessible to other modules
• no inheritance of module interfaces
• no inheritance of implementations, either. (As far as I saw.)

But I don't agree that it's superior to Java's way. Namely, that you can optionally implement an interface or share a superclass. public members of a class can be called without one, at the cost of tying yourself to a particular implementation. I like inheritance; I disagree that it complicates things.

There's also a "quote" function in the tk module, so:

tk->cmd(t, "button .b -text "+tk->quote(_("hello world")));

would work fine too.

My concern is that people will forget to do this (or your first way, which I omitted for brevity). They already regularly forget to do so when sending things to the shell, to an XML processor, to a web browser's HTML engine, to a SQL database, etc. It causes huge problems. So when you have to be continually careful, I get uneasy.

So your new Button(...) example is vastly incomplete. In the Tk interface, for a new button, one can specify background colour, foreground colour, justification, font, etc, etc. One would have to invent language-level objects for all these things (instead of using "red", you'd perhaps have to create a new Colour object, initialised in an appropriate way that you could then pass to the Button's "setcolour" method (excuse brit spelling).

There is indeed a balance to be struck. Colors don't need to be first-class objects; they could be strings:

b = new Button(_("hello world"), color: "red")

Where I use keyword arguments for the optional stuff. The color is simply another string. More static than your way, less than Java's. From my perspective of a user of the language, this is about as simple as it gets. One place to look for a description of the API. One syntax to learn. Yet simple.

But in my understanding, the Erlang message passing is intended to transport messages transparently between machines. Limbo's channels don't try to do any such thing. Sending a value down a Limbo channel is exactly the same as passing it to a function, except that the value goes to another process on the same machine. No marshalling, no distributed objects.

Erlang's message-passing is also the only way to send messages between Erlang processes. And when it is on the same machine, I do not believe any marshalling happens. It's certainly fast. And there's no worry about distributed objects, either: Erlang is a pure functional language, so you can't send a mutable value. No need to keep two copies in sync as they change, since they won't.

You can actually build up quite sophisticated protocol descriptions this way - an example of an area where perhaps more static type checking is used in Limbo than in other languages (but maybe it's trivial to do these things in Erlang too, I dunno).

Erlang lets you send arbitrary messages to a process. It has a receive that matches one or more patterns and takes the associated action. So yes, Limbo does seem to be more static. But I think you'd lose something if you specified an allowed pattern beforehand; you'd end up keeping the receive patterns and that one in sync, which would be a pain. So here you are doing things more statically, and I still don't like it. You can't win. ;)

Check out Concurrent Programming in Erlang, PDF page 100 / written page number 89. It has a good example.

Re:Inferno?

[rpeppe]

But I don't agree that it's superior to Java's way

Actually, it's demonstrably superior to Java's way, as Java doesn't maintain the Liskov Substitution Principle. With no subclassing, Limbo doesn't have this problem.

I wouldn't say that Limbo's way was superior in the same way to all languages with subclassing, as that's a matter of taste. I'll just say that IMHO, the main obstacle to writing sound, maintainable programs is the problem of complexity.

A big contributor to the complexity of a system is the amount of interdependency between its components, which is often encapsulated by class/module interfaces. In a system with subclassing, I cannot understand a subclass unless I have understood all its interface superclasses; likewise I cannot understand a class implementation unless I have understood all its implementation superclasses.

Instead of encapsulating complexity behind an interface as narrow as possible, subclassing promotes unnecessary interdependency between software components, and therefore makes for a more complex and less maintainable system.

This page has more references on this kind of thing.

You'd end up keeping the receive patterns and that one in sync, which would be pain

That's what type checking's about, dude! As far as I can see, with Erlang message passing, if you accidentally send a message of the wrong type, it'll just hang around, lost in transit. The type checking on Limbo channels is just the same as that on function calls, and that's great. For looser, untyped, interconnections, you've got files (which in Inferno can represent any external resource).

That's not to say I don't think that Erlang isn't cool - I do, and I like functional programming languages. I'm just saying that Inferno has a great deal to offer too, and perhaps more in some areas.

Just what we need

[Anonymous Coward]

Oh great, a Christian operating system. Lovely.

Re:Just what we need

[Veridium]

I understand the kernel doesn't panic, it just dies for your sins...

Re:Just what we need

[Ricardo Lima]

Yeah, but nowadays my boss would kill me if I told him that he will return in three days

Inferno?

[Anonymous Coward]

Is the company in cahoots with the BSD daemon?

related to Hell?

[Anonymous Coward]

Since when did Alabama become the utopia of the Unix world?

Yes and no.

[Trejkaz]

Well, it does ship with Acme...

Inferno 4...

[Anonymous Coward]

I've heard its hella good...

Re:Inferno 4...

[ozric99]

Excellent!. What a devilishly witty pun my good man.

informative

[Anonymous Coward]

thanks for the link about hell. I know all about inferno 4 and plan 9, but I've never heard of that one before :)

License

[vinit79]

The VITA NUOVA LIBERAL SOURCE LICENCE seems to be pretty good (free as in speech).

Any ideas why they didint use GPL/BSD or any other standard license. Or is there some subtle(or obvious) licensing issue

Re:License

[Tarantolato]

Read some of Stallman's rants about the Plan9 license(s). Vita Nuova's license has the same problems.

Plan 9 had a license where you couldn't sue Lucent on an unrelated matter if you used it. They've now changed that (as of June 2003), and Stallman now considers it a "free software license incompatible with the GPL". From the GNU site:

• This is a free software license, incompatible with the GNU GPL. We recommend that you not use this license for new software that you write, but it is ok to use and improve Plan 9 under this license.

Inferno's license seems to be the same as the new plan 9 one. (But I haven't looked in depth).

Re:License

[illuminata]

Read some of Stallman's rants about the Plan9 license(s). Vita Nuova's license has the same problems.

How did you get the time to read his rants about the Plan 9 license? I'm still working on his rants from 2002.

But seriously, what necessarily makes a license that might not be Stallman compliant a problem? Can't it just be different? As far as I can tell, he's not some sort of supreme licensing authority. Also, he doesn't have the power to actually enforce his ideas on what's GPL compatible or incompatible; that would be something for a court to decide pending that they also find the GPL to actually be a valid license.

Re:License

[runderwo]

It's not liberal. It claims to cover any use of the software, which puts it in the class of licenses known as 'EULA', as opposed to simply being a permissive copyright license.

Re:License

[Anonymous Coward]

But seriously, what necessarily makes a license that might not be Stallman compliant a problem? Can't it just be different? As far as I can tell, he's not some sort of supreme licensing authority.

Don't be assanine, he's allowed to give his advice and that's all he is doing. Licences aren't rejected just on Stallman's say so but because, more often than not, any problems that Stallman points out are potentially serious; whether for the developer or the end user.

I'm getting really bored with this relentless Stallman bashing on Slashdot. I wouldn't mind, but his views are often misrepresented, deliberately or not, and the myths are perpetuated. As in this post by Illuminata, a well known tactic is used -- misrepresent RMS as some pseudo-diety by presenting his actions as having more significance than they actually do; then, point out how ridiculous this is, thereby causing readers new to the concept of Free software to dismiss his advice all together.

Re:License

[anothy]

my understanding, not cannon:
they didn't use BSD because they wanted to prevent people taking the stuff, using it to make tons of money, giving nothing back to the community, and not paying VN. a reasonable approach for a commercial company, i think.
they didn't use GPL because (minor issue) they didn't want a license with a philosophical statement in the front of it and (bigger issue) they needed something catered to GB law.

Re:License

[Ithika]

Sorry, do you mean Great Britain by GB? If yes, what are the issues involved with the GPL and UK law? I've never heard anyone mention this before.

(I'm pondering releasing one of my programs under GPL and - as I'm a UK resident - would like to know if it may be less effective under local law than in the US.)

Re:License

[anothy]

yes, GB is the ISO/UN country code for the United Kingdom ("what's GB stand for?" "United Kingdom." "oh, okay."). don't ask me why they didn't use the more obvious (and more common) UK, but they chose to use GB instead, and i try to use the proper codes when i can.
as a trivia point, with the exception of legacy ones like .su for the former soviet union, .uk is the only ccTLD that isn't an ISO/UN code.

on to your question proper: i, of course, am neither a lawyer nor british, but from what i was told GB law doesn't allow one to disclaim all warranty in the way the GPL does. of course, none of that's ever been tested in court, and i don't know what GB law says about survivability of agreements in the case of a particular clause being invalid.

Re:License

[Ithika]

don't ask me why they didn't use the more obvious (and more common) UK, but they chose to use GB instead, and i try to use the proper codes when i can.

Not to mention why they choose to omit Northern Ireland... (as in, the "United Kingdom of Great Britain and Northern Ireland", so UK != GB).

Thanks for the info on GPL. Why is there never a lawyer around when you need one? :)

Re:License

[anothy]

they're too busy bothering the people who'd rather not have 'em around. ;-)

Re:License

[dnamaners]

Hmmm from my not legal point of view this looks like GLP with law suit limitations and a reserved right to retract the license. but as i reiterate i am no lawyer

here is a fun snip from the license:

/begin snip
7.1.
YOU agree that the laws of England shall apply to any dispute arising from this LICENCE. YOU agree for the benefit of VITA NUOVA that the Courts of England have exclusive jurisdiction to hear and decide any suit, action or proceedings (``Proceedings''), and to settle any disputes, which may arise out of or in connection with this LICENCE and, for these purposes YOU irrevo-cably submit to the jurisdiction of the English Courts.
/end snip

English courts eh? cant say i like that bit. however it seems to me that this would be needlessly restrictive... however i wonder if Slovenia (or any contry that tends to not support foreign copy rights) would even care?

"If you have a dispute you automatically agree to our contries way of settling clams.... 6 months into dispute...... Our champion No-Nuts will now 'Ro-sham-bo" your weak CEO for the copyrights! Kiss your balls good bye, MUHAHA HAHA......"

Re:License

[HiThere]

Besides....he has a track record of being right in an uncomfortably large number of instances. Usually about things where most other people had an attitude of comfortable acceptance.

Re:License

[Tarantolato]

Ah, okay. That was exactly the thing that RMS was unhappy about the Plan 9 license. It would also kills any chance of it being used by most US universities, since nearly all state universities require litigation to happen in the state itself, and many private ones do the same.

Re:License

[illuminata]

Don't be assanine, he's allowed to give his advice and that's all he is doing. Licences aren't rejected just on Stallman's say so but because, more often than not, any problems that Stallman points out are potentially serious; whether for the developer or the end user.

Potentially serious? They could be if the courts were on the GPL's side. But, that hasn't been proven yet, so all of the "problems" that he points out are mere empty threats and arguments with no legal proof. Without that, I'd say that the potential for a licensing problem is pretty low, considering that the license has been around for quite a while. It's pretty spooky that the largest parts of the open source "movement" are riding atop an unproven license, isn't it?

As in this post by Illuminata, a well known tactic is used -- misrepresent RMS as some pseudo-diety by presenting his actions as having more significance than they actually do; then, point out how ridiculous this is, thereby causing readers new to the concept of Free software to dismiss his advice all together.

I'm not the one misrepresenting RMS as some pseudo-diety; you can blame that one on the zealots. If you've spent enough time on Slashdot (too bad this was a coward post, otherwise I wouldn't have to guess), you'd know what I'm speaking of. Half of the time it's amazing that they are even able to type out a response because their arms are wildly flailing in the air. Well, one could at least imagine that with the anger put behind those posts. For the most part, it's only a matter of time until somebody gets jumped on over saying anything remotely bad about RMS. And, what exactly makes this "tactic" well known? It wouldn't be some sort of attempt to invalidate the bad things said about RMS, would it? Nah, couldn't be.

No, I'm not trying to say that his actions have any true significance at all; I'm saying that they really shouldn't have significance. And how would my criticism of one person somehow hurt the concept of free software? I'm of the opinion that his advice should be dismissed for the most part; is that so wrong? Also, it's not my fault that RMS has collected a fanbase which believes that a possible incompatability is automatically a problem. However, I'd have a problem believing that RMS doesn't perpetuate that line of thinking based on his ideas and opinions.

But, all of that might not matter. The GPL still hasn't been proved enforcable.

hell

[Anonymous Coward]

Well this matches perfectly... The core OS components are named after Hell, and if it is run on an Intel proc... we now have the hot temperatures to match the Hell description as well.

Shall Jesux rise again?

[cant_get_a_good_nick]

I would be one to say that Jesux shall smite this thing you call hell, but there hasn't been much activity on the website in a while. I wonder if they'll ship creationism as their mailer/Outlook replacement, for they surely cannot ship evolution .

INSERT WITTY BSD DAEMON JOKE HERE

Re:Shall Jesux rise again?

[root_42]

Oh no, it's slashdotted. Check this out -- a google cached version.

Yeah I tried it

[Orion Blastar]

had to key in "666" for the administrator password. Got a visit from the Asmodeus Daemon after I logged on. ;)

Re:Yeah I tried it

[0racle]

Administrator? I thought superuser was Dante?

Re:Yeah I tried it

[JanneM]

No, he just had a guest account.

yay!

[Lord Ender]

An operating system that can run as a browser plugin! Just what I have been waiting for! Now after I've been towing my mobile home on my bicycle, or flossing my teeth with boat anchor chain, I can come back to my computer for some equally well-matched technology.

Re:yay!

[anothy]

okay, it sounds insane on its own, yeah. but the point isn't "ooh, look what i can do", it's the idea of being able to run the same app anywhere. i like (as does my company) the idea of only writing code once, and being able to install it on our (mixed-OS) desktops and also letting external parties use it without having to install as much (installing a browser plug-in is fairly unobtrusive compared to installing a stand-alone app). OS-in-a-browser isn't exciting on its own, but becomes really interesting with everything else already in place.

Re:yay!

[The Infamous Grimace]

i like (as does my company) the idea of only writing code once, and being able to install it on our (mixed-OS) desktops...

Isn't that called Java?

...and also letting external parties use it without having to install as much (installing a browser plug-in is fairly unobtrusive compared to installing a stand-alone app).

Isn't that called JavaScript?

And wouldn't you still have to install a stand-alone app to run inside the OS that's running inside the browser?

(tig)

Re:yay!

[anothy]

no, no, and no, in that order.
one: the idea of portable executables is not a new thing to Java, nor is a virtual machine. Java and Inferno were started at about the same time, Java just beat Inferno to market. the fact that some solution to a problem exists shouldn't deter anyone from seeking a better one. Inferno takes a very different approach to platform portability than Java does, and manages to preserve the write-once-run-everywhere promise than Java does.
two: javascript has nothing to do with java - the name was chosen as a (successful) marketing ploy. it isn't really a first-class language and certainly has no compatibility with Java. the point of my comment was that i could use Inferno/Limbo in all these places, with the same app. your suggestion of using Java for part and JavaScript for another part misses this.
three: you can (and i have) build a custom inferno that starts up your app automatically, or only your app (and supporting infrastructure as needed), or simply includes it somewhere in the package for the user to run. there's no reason you'd have to distribute something separate, although you could do that if you wanted as well.

Cool ...

[cmcginty]

Features sound great ... but does it play OGG's ??

Re:Cool ...

[CdBee]

Yes, and apparently it will burn CDs too - burn them in the flames of hell you unholy pirate !!!

New p2p

[hsidhu]

How about building a new p2p file sharing app on top of this thing? A truly cross platform app since it would run on top of the following architectures:

Host Operating Systems

Windows NT/2000/XP
Linux
FreeBSD
Solaris
Plan 9

Supported Architectures

Intel x86 (386 & higher)
Intel XScale
IBM PowerPC
ARM StrongARM (ARM & Thumb)
Sun SPARC

and it supports crypto and since its native code its faster than java.

Re:New p2p

[Temporal]

Java compiles to native code. Just because the translation is done at program startup doesn't mean it is slower. In fact, because of this, it can perform optimizations that couldn't be used in a C compiler (optimizing for specific CPU's, etc.).

The problem with Java is that its GUI toolkit is slow.

In any case, with a file sharing app, CPU efficiency is certainly not an issue. You should never worry abot CPU efficiency if you don't need to, as you will only be making things harder on yourself.

And, finally, writing portable C/C++ code is really not that hard if you know what you are doing. Certainly you'd be better off with that than you would be asking all of your users to install an extra OS over their current one just to run your program. Really, the most important factor in making file sharing successful is to get lots and lots of users, and most of those users are going to be people who have absolutely no idea what an operating system even is.

Re:New p2p

[warrax_666]

The problem with Java is that its GUI toolkit is slow.

Oh, I see... could that possibly be because it's written in Java? ;)

Actually, I kind of agree with you, in that I think Java is usually "fast enough". However, I have never ever seen any real-world examples where Java is faster than C. I can't recall ever seeing any actual proof of JIT run-time optimizations which are better than can be generated with a "static native" compiler w/profiling (except in artificial settings where you can obviously just select your benchmarks to give the results you want). If you know about any such examples, I would love to see them.

One can, of course, theorize that e.g. branch prediction can be done better by a JIT than at compile time (which is certainly true in theory), but I really don't think it's that much of an issue since the processors are already so good at branch prediction themselves.

Re:New p2p

[Anonymous Coward]

Well, look here and here.

Re:New p2p

[Darren Bane]

I must admit to a bias, as I quite like Inferno. But here are a few rebuttals to your points anyway.

Java may compile to native code, but it's not done at program startup. The Inferno VM has a Harvard architecture which prohibits the byte-code manipulation that's allowed at Java run-time. This allows a one-off translation to native code at module load time. In contrast, the Java VM must JIT hotspots as you hit them (which does make it slower).

I agree that CPU efficiency shouldn't be a factor. However, programmer efficiency should; and Inferno was designed as a distributed OS. Hence it makes lots of networking tasks easier than would otherwise be the case.

Lastly, as well as a native OS, Inferno can run identically as an application under a host OS, which is trivial to install. This is like Oberon, and the DrScheme people published a paper calling this architecture a "Higher-Order OS".

Re:New p2p

[Temporal]

I'm no Java fan. Certainly the language itself is designed in such a way that certain types of tasks are necessarily going to be less efficient. It depends on what you are doing, of course. However, the "Java is slow" assumption made by many people is quite exaggerated, mainly because most people don't understand how Java works. People like the original poster think "bytecode = interpreted = slow". I guess the concept of translating bytecode to native code just never occured to them.

As I am currently developing a language which will, among other things, use bytecode, I'd like for this myth to die sometime soon. :)

Re:New p2p

[anothy]

In fact, because of [java compiling at runtime], it can perform optimizations that couldn't be used in a C compiler (optimizing for specific CPU's, etc.).

C can optimize for specific CPUs, too.

The problem with Java is that its GUI toolkit is slow.

The problem with java? there's only one? ;-)

You should never worry abot CPU efficiency if you don't need to, as you will only be making things harder on yourself.

i think this is an overstatement of an otherwise reasonable principle. certainly, one shouldn't obsess over every optimization, and CPU speed (overall) is not a bottleneck in most applications. it's also true that the amount of time you spend optimizing for the last few percent improvement is almost always overtaken by Moore's Law. however, that's not the same as saying don't think about it. you want to organize your data structures in a way that makes sense to the program. you want to think about elegant structure. thinking about these things helps the readability and maintainability of code.

Certainly you'd be better off with [writing portable C/C++] than you would be asking all of your users to install an extra OS over their current one just to run your program.

but you don't do that, you just say "here, install this app". to the underlying OS - and in most ways, to the user - it just shows up as another app. you just happen to be able to run other things in it. you can (and i have) build custom versions of Inferno that run a specific app on startup - say a full screen (full Inferno screen, that is) gui app. then there's really very little difference for your users.

Re:New p2p

[hummassa]

>> The problem with Java is that its GUI toolkit is slow.

> Oh, I see... could that possibly be because it's written in Java? ;)

No, the problem with the Java GUI / other std libraries toolkits is that they are bloated. As in: they mount very deeply in the top of each other, for the sake of consistency, but... this means every time you take one, you take the whole family.

Re:New p2p

[anothy]

if you're really looking for "as fast as possible", run-time optimization isn't the way to go. not saying it isn't plenty fast, and i'm not a fan of obsessing over every last speed tweak, but the fact remains.

Re:New p2p

[warrax_666]

Note, I said C. Not C++. There is a big difference since C++ is notoriously hard to write really efficient code in (well, unless you restrict yourself to the C "subset").

Re:New p2p

[Crayon Kid]

However, the "Java is slow" assumption made by many people is quite exaggerated, mainly because most people don't understand how Java works. People like the original poster think "bytecode = interpreted = slow". I guess the concept of translating bytecode to native code just never occured to them. As I am currently developing a language which will, among other things, use bytecode, I'd like for this myth to die sometime soon. :)

Perhaps the bytecode issue isn't the cause of the "Java is slow" myth. Perhaps instead it has something to do with "I click on a Java application and oh my God it takes ages to start". Sure, I exagerate, but by the basics of it it's still true today, even if only in the form of a small delay. It's probably not even Java's fault, but of the virtual machine. When you run Java as a server application it will be fast, but the desktop user still notices the delay. Hence the myth lives.

Re:New p2p

[angel'o'sphere]

and it supports crypto and since its native code its faster than java.


Neither is Inferno native code ... erm at least Limbo is usually not compiled to native code but to byte code as well, nor is native code faster than Java :D

Limbo applications are executed on a VM, just like Java applications are.

angel'o'sphere

Re:New p2p

[Synistar]

> The problem with Java is that its GUI toolkit
> is slow.

This is fixed by SWT ( http://www.eclipse.org/ ). Native widget library for Java. It was developed by IBM for the Eclipse project. Java with SWT is pretty much indistinguishable from a more traditionally compiled program.

Re:New p2p

[Surt]

Java is slow is less of an assumption, and more of an experience.

Swing renders slowly.

[] is slow too, and non-trivial apps don't see much benefit from the hoisting JIT changes.

Loading the VM is a huge overhead for small applications.

Why the last link?

[Naked_Ninja]

I hate to bitch, but why put that last link in the article description? I assume its purpose is to add some humor, but seriously, horrid web design isn't that funny. A little more discretion should have been used here when posting links to the frontpage of slashdot. Think before unleashing slashdot's hordes on unsuspecting people and wasting their bandwidth. Even nutballs like this guy deserve this courtesy.

Re:Why the last link?

[zakezuke]

Perhpas he misread the first line like I did "And in hell he lift up his eyes, being in torrents. . ." Luke 16:23

Comment removed

[account_deleted]

Comment removed based on user account deletion

Hell comes in many flavors

[warkda rrior]

Slashdot says:

[...] all of its major components are named after things related to hell.

I see on the Inferno website the following components:

The Inferno operating system [...] includes the Dis virtual machine, integral support for the Styx network protocol, and an implementation of the Tk user interface toolkit.

I am not sure which part of hell the Tk UI toolkit represents, but I feel their pain.

Re:Hell comes in many flavors

[radja]

ofcourse, Dante also had greek myth to fall back on for ideas...

Re:Hell comes in many flavors

[kalidasa]

Indeed. In case folks don't get Radja's point, Dis, Styx, and Charon are all from Greek myth (e.g, Styx goes back at least as far as Hesiod).

Re:Hell comes in many flavors

[scrytch]

> integral support for the Styx network protocol

hmm.

prooooogramming awaaaay
full of open source
in the language C
myyyyy mallocs are freeeeee ...ok i think i'm done, i'm already a bit nauseous...

Good introduction to Limbo

[harikiri]

...as in the programming language for Inferno, written by Brian Kernighan, is available here.

I've briefly looked into trying out Inferno, but bear in mind it's not designed as a desktop system. Instead, the market it seems to be used in is the embedded market - so it'd be interesting to see how easy you can write server apps for application boxes with it.

However, it initially appears that Limbo is the only way to program for Inferno (prove me wrong please), which would be an obvious impediment to developer take-up.

Re:Good introduction to Limbo

[shaitand]

From the website:

"Features
Compact
Runs on devices with as little as 1MB of RAM

Complete Development Environment
Including Acme IDE, compilers, shell, UNIX like commands & graphical debugger

Limbo
An advanced modular, safe, concurrent programming language with C like syntax.

Library Modules
Limbo modules for networking, graphics (including GUI toolkit), security and more...

JIT Compilation
Improves application performance by compiling object code on the fly (Just In Time).

Namespaces
Powerful resource representation using a single communication protocol. Import and export resources completely transparently.

Full Source Code
Full source code for the whole system and applications, subject to licence terms

And more...

# Online manual pages
# Full unicode support
# Dynamic modules
# Advanced GUI toolkit
# Javascript 1.1 web browser
# C cross compiler suite
# Remote Debugging
# Games, Demos & Utilities"

Most relevant on the list is the C cross compiler suite. Theres at least one language other than Limbo you can code in (although it seems limbo is designed by many of the guys who wrote C and other minor items of note such as Unix).

If there is one language any developer you'd really want on the playing field knows, it's C.

Re:Good introduction to Limbo

[goga]

The C cross compiler suite, as far as I can tell, is something they use to port their VM between platforms. When you program _for_ the VM, you have to use Limbo.
Still, I think the compiler might be one of the most valuable parts of this distribution. It was originally written by Ken Thompson; it is fast; its code is small and readable.
If enough people notice, that could be a worty competition to GCC.

Re:Good introduction to Limbo

[Darren Bane]

Ok, so maybe only a hobby programmer would use it as a desktop -- it's pointless to try compete with Microsoft, OS X, GNOME and KDE here. However, it can be used for more than embedded work.

Its background as a distributed OS makes it easy to develop network servers. There's a lot of library support for that kind of thing, and several examples (e.g. httpd) included.

Re:Good introduction to Limbo

[anothy]

to clear up a sibling: the C cross-compilers are used for building inferno, not for programming in inferno. you are correct that, at present, the only language you can write user-mode stuff in is Limbo (well, unless you count writing Dis assembly). anything that can be made to compile down to Dis bytecode is possible, though. there was a Java implementation some years ago (way out of date, not maintained or distributed), and a summer student at Bell Labs did an implementation for some scripting language (i forget which, but Perl or Python are sticking out at me; he was working with a bunch of web folks, so it seems likely). there's no theoretical reason why lots of languages couldn't compile down to Dis (C/C++ has issues in particular, however).

there are options for getting existing C code into the Inferno world. at a high level, 3.

1. keep it stand alone (on another OS) and provide a Styx interface to it. Styx is nice and simple; a project i was on did this with existing OCR software.
2. put it in the kernel as a file server. this is how, for example, the network stack works. it's all C code, but the kernel provides a Styx interface up to applications. we've done this with something, but i can't remember what. TTS maybe.
3. put it in the kernel and provide a module interface to it. this is how the fundamental stuff - like the Sys module, which provides the nearest analogue to libc for Limbo - works.

all three are more work than a simple ports, but the results of the first two give you distribution for free, and all three make things easily available to all your apps and the environment.

and yes, it has been an impediment to developer take-up, which is a real shame. Limbo is a simply beautiful language.

Re:Good introduction to Limbo

[anothy]

i'm not sure it's a pun, technically, but it's a real pain in conversation:
"when i run it through the Dis assembler it..."
"hold on, why are you trying to disassemble it?"
"no, no... the Dis (pause) assembler!"
kind of a pain around the lab. thankfully, nobody really writes Dis directly.

was that really necessary?

[ashot]

who else went straight for the hell link?

OSS authors: Think carefully about communication.

[Futurepower(R)]

It amazes me how bad open source people are at marketing. Why make your project, which requires a huge amount of excellent thinking, the butt of jokes?

Why give a name to your open source project that will cause those who have less than complete technical knowledge to feel uncomfortable about adopting what you have done?

One question is, how bad can it get? Will there one day be a "Worthless" project? There is already a "Waste".

The funniest bad name for an open source project was "Killustrator". It's easy to see how the name was chosen. Everything in KDE began with a K, as much as possible, and Killustrator is an open source illustration program. It didn't seem to bother anyone that the first syllable of the name was "Kill". I can imagine the Killustrator author thinking how convenient it is that the word illustrator begins with a vowel; that makes it easy, just put a K at the beginning, and you have a name!

The name Killustrator gave everyone a million dollars worth of laughs, and did perhaps $10 million damage to Adobe's reputation when the CEO of Adobe overreacted, saying people would confuse Killustrator with Adobe Illustrator.

Do open source authors believe that there are only a few concepts available, not enough for everyone? Why copy the FreeBSD devil idea?

And Why did the FreeBSD project adopt that idea? I know FreeBSD is an excellent OS, and the favorite BSD for ISPs, but there are some who will be discouraged by the amateurish baby red devil marketing scheme.

Looks right.

[jcuervo]

Also, all of its major components are named after things related to hell.

Hmm...

* many Unix-like tools: mv, cp, rm, xd, wc, grep, ps, diff, tr, man, ls ...

Yup. All related to hell.

Re:Looks right.

[Too Much Noise]

why, certainly - one man's hell is another man's ... err, sorry about that, I meant a Unix user's workstation.

Re:Looks right.

[nytes]

They missed one. I see nothing called "marriage".

Re:Looks right.

[anothy]

i'm not sure these qualify as "major components".

Re:Looks right.

[fucksl4shd0t]

They missed one. I see nothing called "marriage".

It's called 'cat'

we don't want you to burn in hell

[polished look 2]

I did not submit the article but I believe that the last link was included for the sake of non-believers.

On a related note, what do you think of the sounds supposidly recorded from hell [RealAudio] on that webpage? It sounds kind of electronic to me but maybe it really is from hell?

Re:we don't want you to burn in hell

[BiggerIsBetter]

Sounded like a typical crowd scene with a muffled PA and one crazy woman. Or it might be Hell and we are all doomed. Who knows.

Re:we don't want you to burn in hell

[gunpowder]

No, it isn't

Off topic, and scary.

[Futurepower(R)]

The editors reserve the right to be off topic.

Woooo! It's scary:

YOU will see HELL. . .
YOU will smell HELL. . .
YOU will breathe HELL. . .
YOU will hear HELL. . .
YOU will feel HELL. . .
YOU WILL BE HELL. . .

Re:OSS authors: Think carefully about communicatio

[shaitand]

You've obviously never seen the devil girl. I'm a linux man myself but a couple more runins with her when the wife isn't around and I may convert ;)

OSS authors:Think carefully about [making money]

[Anonymous Coward]

I got a better question. Why does everything have to be commercialized? Can't we have some FUN with our software without having to pay a tribute to the marketing gods? Some of us simply don't care, to put it bluntly.

Alternative to VMWare?

[gbulmash]

Considering it runs as a service, it sounds like it might be marketed as an alternative to VMWare if it had a decent ports collection... at least for those who want to have a generic GUI *nix they can access from Windows instead of dual booting.

Re:Alternative to VMWare?

[gbulmash]

Its not windows so it must be unix, right?

Plan9 is not unix. And not in the same way that
GNU is not unix.

The post you're replying to said *nix, not Unix. AFAIK, that's shorthand for "Unix-like operating systems". Plan9, Inferno, Linux, etc. are not Unix. But I thought calling OSes in their class *nix was acceptable. If I am mistaken, I apologize.

Re:OSS authors: Think carefully about communicatio

[molnarcs]

"It amazes me how bad open source people are at marketing."

Maybe these folks don't give shit about marketing ... they just do it because they like it. WASTE is a good name IMHO - funny reference to Pynchon's Crying of lot 49. I don't think WASTE author wanted to 'take over the market' with his prog either.

FreeBSD's beastie ... yeah, sure, the OS logo is the first thing everyone would consider when choosing a solution (yahoo seems very much discouraged by chuck - name for beastie btw -, as does NYInternet, Pair Networks, netcraft itself or the apache project).

Linux was criticized for the 'idiotic' looking penguin as well, remember? Yet I don't think that its market entry was very much hindered because of its logo.

In hell it is always the 1980s

[konmaskisin]

... that's just the way things turned out ...

Re:In hell it is always the 1980s

[miu]

Shit, am I going to spend all eternity voting Carter/Mondale?

Re:I thought a better unix was ...

[Tarantolato]

I thought a better unix was linux!

Linux is better mostly because it's free. It does not fix some of the imperfections in the core design (for good reasons; that would break Posix compatibility). According the Inferno Design Principles, Inferno takes Unix ideas and applies them more consistently. For instance: everything is a file. In Inferno, what you're typing in a text editor window can be queried in something like /gui/window/...etc. Also, the network protocol is entirely file-based. Your desktop system (or smartphone, or brower plugin) sees the server or another client as part of the same filesystem that its own resources sit in.

Inferno on Lucent BRICK Firewal

[hytrex]

Friend told me that Lucent is using Inferno (version 3) on Lucent BRICK firewall (model 20, model 80 ... model 1000). It is stateful firewall and works well! he says

Re:Inferno on Lucent BRICK Firewal

[anothy]

the Lucent Brick firewall does use Inferno, but i'm not sure it's 3ed. if i remember correctly, they're using something akin to a hybrid 2ed/3ed Inferno.
but yes, it's a very nice product. at the time of its introduction, it was arguably the best firewall available. it's still very good, but the rest of the world hasn't stood still, of course.

Re:Inferno on Lucent BRICK Firewal

[hytrex]

Last night I got two Lucent Brick 20 and two Lucent Brick 80 + External Floppy + LSMS 7.2 for managing ... Very nice tranparent firewall!!! Been up all night ... LSMS is kind slow on log updates but hey, you can manage 10000 (says Lucent) Brick with on LSMS server!

Bizarre - "Connections Syntax"?

[ab5tract]

Seriously, I can't believe some of the shit yall be talkin about. This system is my dream arriving. Praise to shaitand for dropping some data from the site.

_This_ is the ideal shit, baby! Where the hell its mirrors at? Does Vita Nouva gotta get more poetic on your ass or what?

All jokes aside...

[shaitand]

Is this what I think it is?

A multi-platform OS, it can run standalone, as a virtual machine on every major OS (including every linux distro) and give full blown access to the system? Plus it can run in a sort of transparent mode so you can port your app to it and have your app appear to be a native app?

From the description it sounds like it's multi-threaded and designed with distributed systems (read cluster) in mind.

Plus it already has a language designed by the fathers of C and C cross compiler (wonder how well it works, also being designed by the fathers of C).

So in one sweep we have a solution suitable (sounds like it carries 1mb ram overhead) for most applications. Anything written for it magically runs on every major platform, it's highly scriptable and carries most of the magic of Unix packed with it wherever it's run from.

If it's significantly faster than Java I'd say we have a solution to the multi-distro problem as far as apps go.

Re:All jokes aside...

[Anonymous Coward]

You're not too far off the track. It is a network
operating system that lends itself to clustering
applications, and Vita Nuova has a few big clients
looking at exactly this.

Plus the Vita Nuova people are very approachable.
(Their office is virtually within sight of mine).

One of the great advantages is that just about
everything looks like a file so it is very easy
to create namespaced collections of device-type
files that might be resident on your machine, or
just as easily resident on a collection of
disparate machines. It makes prototyping GRID
applications very much easier.

Personally I am very keen on looking more at
Inferno for GRID computing just as soon as I have
more time to spend on it. It's not a solution to
all ills, but it has definite advantages, and
seems to be very robust and has a small footprint.
I've seen it running happily on a fairly old
PDA being used to seamlessly integrate a whole
series of remote devices.

Aaron Turner, University of York

Re:All jokes aside...

[Anonymous Coward]

The following link might also be of interest:

http://www.wrgrid.org.uk/conference2004_slides.htm l

(Link to Vita Nuova talk about 2/3 of the way down the page).

Aaron Turner

Re:All jokes aside...

[anothy]

Plus the Vita Nuova people are very approachable. (Their office is virtually within sight of mine).

um, does this mean you can see it virtually? like, with a web cam or some such? ;-)

oh, and isn't posting AC kinda silly with your name in your name in your sig?

Re:All jokes aside...

[shaitand]

Everything those gentlemen have produced thus far has been too good to be true. C, Unix, etc. Why should this be any different?

Re:All jokes aside...

[HiThere]

Unfortunately, the libraries are very limited. And the number of machines the system can interface well is limited to the number of machines BOTH linked to a network and running it. For some applications this isn't a problem, but for many it is.

In fact, I'd say that most applications won't be able to use this. And only a few will find it the best choice. (A part of the reason that it's so small is that it doesn't hold much. Useful stuff, but not much of it.)

Re:All jokes aside...

[shaitand]

ok, a few things to note. unlike you I didn't qualify my statement. Who said anything about "long running". I mean across the board, or I suppose anything in which APPLICATION performance is an issue (as opposed to device performance or tasks which require so little speed compared to the hardware that speed is irrelevant, ie "hello world!").

I know java fans like to believe java is fast, well if your comparing java to a random perception, maybe it is fast to you.

If you compare java to other languages with VM's it's not bad either.

If however you broaden the comparison to include traditional programming languages, java and all languages in it's class (including C#) don't even begin to get in the ballpark. Hell even VB outstripes Java and VB compared to other traditional languages is dog arse slow and bloated.

In my mind at least the benchmark to look for is C, since I've never seen another high level language outperform C, some other high level languages come close to matching C (python in some cases, perl in many cases, C++ in many cases, Pascal in a few cases). Compared with C code Java doesn't even hold a candle.

What I mean by significantly and consistantly faster than Java is seeing the program in cases where the code used is virtually identitical (simple things, like counting instances of the letter c in a 2gb text file stored on a ramdrive raid on a 486dx with 8mb ram). If I can see performance across the board match say, pascal, or even VB (although you admittedly couldn't do that particular test with VB), then I'd say the language is ready to replace most apps.

Until then, there is a reason we aren't exactly seeing much Java or any comparable vm language outside the Valley and buzzword industries.

Re:OSS authors: Think carefully about communicatio

[drgonzo59]

I think that the people who work on these projects are not "market oriented." They do what they do because it is fun and they probably could care less if some manager dude thinks the name of the software will offend or drive away the potential clients. Maybe it's supposed to drive away the people who lack a sense of humour. /* flaimbait start */ Let them use microsoft products /* flaimbait end */ And besides, I don't think they copied the FreeBSD's devil idea, I think they got their inspiration from Dante Alighieri

Re:OSS authors: Think carefully about communicatio

[Homology]

And Why did the FreeBSD project adopt that idea? I know FreeBSD is an excellent OS, and the favorite BSD for ISPs, but there are some who will be discouraged by the amateurish baby red devil marketing scheme.

FreeBSD is not alone in this, as can be seen from why Mac is bad ;-)

But there are even darker undertones to this company than most are aware of. Consider the name of the company and its logo: an apple with a bite taken out of it. This is clearly a reference to the Fall, when Adam and Eve were tempted with an apple3 by the serpent. It is now Apple Computers offering us temptation, thereby aligning themselves with the forces of darkness.

environment

[cybergrunt69]

I haven't finished RTFA yet, but from the quick overview, this looks outstanding for one particular item: it runs as an app or as the entire OS!

When's the last time you saw an app so well developed that it ran on almost any platform - not to mention as its own OS.

At this point, I don't even care what it does, I think that part shows a level that many other applications need to strive for.

Re:environment

[mritunjai]

When's the last time you saw an app so well developed that it ran on almost any platform - not to mention as its own OS.

Emacs :-P (at least the "own OS" part).

Re:environment

[lovemayo]

"Hello World" ?

Re:environment

[10am-bedtime]

"never an Emacs Chip"

no worries, we're working on it...

Re:OSS authors: Think carefully about communicatio

[afd8856]

Maybe because Inferno is not such a bad marketing idea. Discreet uses Inferno and Flame as names for some of its high end compositing applications.

Inferno on the Mac G5

[Watts Martin]

Just wondering -- has anyone else tried this, successfully? I downloaded the demo disk and ran the OS X install script, and when the script got to the part where it started running the "emu" binary, all sorts of fascinating and wonderful errors began, starting with malloc messages. I finally ended up having to kill the process.

Re:Inferno on the Mac G5

[anothy]

i'm currently running it on my PowerBook G4, although i'm not sure if i had to do anything "special" to make it work. ask on the mailing list, or search the archives (or the archives for the plan9 list "9fans" (or comp.os.plan9) which still gets some inferno traffic).

Re:OSS authors: Think carefully about communicatio

[cabraverde]

I know FreeBSD is an excellent OS, and the favorite BSD for ISPs, but there are some who will be discouraged by the amateurish baby red devil marketing scheme.

If so, these people should not be making technical decisions. They put themselves at an unnecessary disadvantage.

I seem to remember...

[AgentAce]

this being developed by Lucent several years ago, around the time that they just switched names from Bell Labs. I'd read about it somewhere on their website and never heard anything about it until now. It sure seems to have taken on a completely different form.

Re:I seem to remember...

[zhenlin]

There is still such a system being developed at Bell Labs. It's called Plan 9.

Discreet's Inferno

[tinrobot]

A lot of high-end movie effects are created using a product by Discreet called Inferno. It's been around for years. I smell a trade name suit coming.

http://www.discreet.com/inferno/

Re:Discreet's Inferno

[DarkDust]

But Inferno is also around for a few years... I think I remeber seeing it in the Yahoo! directory as early as 1998 or so.

Re:Discreet's Inferno

[wildjim]

I remember 'Plan 9' news around 10+ years ago.
It was distributed-only, where the Disk-subsystem ran as seperate (networked) nodes from the CPU-subsystem(s), which were seperate from the Terminal(s), etc, etc. It seemed an awful lot like a mainframe-style system using commodity parts, but you had to invest in at least 3 nodes in this way, if not more. This could have been expensive for what was mostly a research or hobby system at the time -- at least if you were going to get anything usable, speed-wise. (Others more intimate with the details may be able to correct/corroborate this)
Soon after, they released Inferno, which was basically the same idea, but the distributed-ness of the components was up to you.
I'd be surprised if much 3D software that old would still be considered anything like high-end.

Re:Discreet's Inferno

[anothy]

not likely.
leaving aside all the questions of them being in separate domains (they're both software, but they do totally unrelated things), there's precedence questions. Discreet's only been around since 1999; Inferno (the one originally by Lucent, now from VN) has been around since 1996. Inferno (the later) is a properly registered trademark and all that.

Re:Discreet's Inferno

[nurble]

not that it matters in the slightest, but flame's been around since at least 1993, and inferno since probably 95 or 96. i'd be surprised if the trademark application didn't include most of their product names at the outset...

Re:Discreet's Inferno

[zhenlin]

Plan 9 is designed for use in a mainframe-style network, true. However, many have successfully used it as a PC-OS. But it's true what they say, you don't "get" Plan 9 if you don't use it as a mainframe-style network.

Think of Plan 9 as the OS that makes a bunch of networked computers look like one mainframe.

Inferno is Plan 9 taken to various extremes (for commercial reasons) -- Portable/WORA, for one. Embedded/low memory, for another.

Re:Discreet's Inferno

[jackbird]

They were "Discreet Logic" until bought by Autodesk in 1999, who changed the name to "Discreet" and rebranded their Kinetix division (IOW 3D Studio MAX) as discreet.

Re:Discreet's Inferno

[AveryT]

Wrong.

The inferno trademark was filed by Discreet Logic in 1993 and registered in 1997.

Re:Discreet's Inferno

[anothy]

that's interesting and informative. Inferno got it's in 1996 (latest, but i'm pretty sure that's right). registered. so at least on paper, the PTO doesn't think there's a conflict (and in this case i'm inclined to agree, which is rare)

Tinkered with an early version of Inferno

[Anonymous Coward]

Way back in 97 as part of MS directed research stuff @ USC. Came to a screeching halt when Lucents marketing weenies decided that a source license would cost in excess of $1M. Funny bit after that was the marketing person called one of the guys on our project team and was complaining that she got chewed out by D Ritchie. He'd posted the details of the licensing deal to comp.os.inferno .

Re:Tinkered with an early version of Inferno

[anothy]

well then check it out again! :-)
the license has changed substantially (it's free if your work is), a commercial source license is now a couple orders of magnitude cheaper, and the tech has progressed substantially since 1997 (which, if i recall properly, was before even the 1.0 release).
MS, incidentally, found it interesting enough to offer to buy it twice in 1996 and 1997.

oh, and having met Dennis Ritchie in a work environment, i'm thinking that if your co-worker was chewed out, he/she deserved it. the big three - Dennis, Ken, and Brian - are some of the easiest geniuses to work with i've ever met (and Bell Labs had plenty wandering around).

Not so....

[NEOtaku17]

One of the college teams down here is the Sun Devil from Arizona State University and everyone seems to love them around here. People like cute little red gusy with horns.

Unix?!

[NEOtaku17]

Anyone on Slashdot is "smart" enough to know that the devil uses Windows! I mean come on now.

Re:Unix?!

[TheLink]

If I were evil I might sell windows or even give it away for free, but why would I use it myself?

Might pretend to use it.

All major components are named after hell.

[blindcoder]

So, what component is "Good Intentions?" Graphical User Interface?

Re:All major components are named after hell.

[BiggerIsBetter]

The road to hell is paved with good intentions.

Call me when they get to

[panurge]

Paradiso.

A few obvious questions:

• Do all comments have to be in terza rima
• Is there an annoying help popup called Virgil?
• Presumably the processor needs extreme cooling?

Oh, and isn't it a bit arrogant of the designers:
"I was made by the first power, the first holiness and the first love"

And if the above sounds like raving, just google for Dante Alighieri...

Re:Call me when they get to

[pnot]

Presumably the processor needs extreme cooling?

Well, duh. Why do you think the ninth circle is made of ice? ;-)

And considering what the core looks like, I'm glad they've expanded the traditional four rings of protection to nine...

Re:Call me when they get to

[kalidasa]

The root password is probably Beatrice.

Re:Call me when they get to

[dodobh]

Nine rings for mortal men doomed to die

Hmmm, so their next release will have just one ring?

Tryst with Plan9

[nikkipolya]

I tried using Plan9 a few years ago upon reading its features out of curiousity. First, it wont start in console mode (probably, unless its hacked) It needs working graphics card. With much difficulty I got my card recognised. Next it didnt recognise my sound card and modem. After great difficulty trying to get it to recognise them, I gave up. Plus its GUI sucked. I still have remnants of Plan9, a 700MB partition now formated as reiserfs and configured as /tmp for my Linux Box!

All the best. Try your "luck" with it!

Re:Tryst with Plan9

[anothy]

yes, plan 9 has driver issues. so will any small project. if you want to try things outside the mainstream, you're going to have to get over that.

also, "its GUI sucked" is an overly broad and essentially content-free statement. a large part of it is subjective. the gui is certainly minimalist, but i really like that. i try hard to get any X11 system i have to use to look as much like it as possible. there's a number of things which you simply can't say "suck" - things like the chording in Acme, the exact window positioning with sweeping on creation, the underlying model. all amazing. particularly the underlying model - built using the same primitives as everything else in the system. you get things like distribution and recursion for free. wonderful stuff.

all that being said, if you can't get Plan 9 working, that's a good reason to check out Inferno. all the Plan 9 concepts, with one or two others in the mix, and can run hosted (read: no driver worries).

Pah!

[BabyDave]

Applications, browser plugins ... where's my EMACS mode, dammit!

Slashdotted

[smokeslikeapoet]

Hell has been slashdotted. Why didn't God think of that?

Re:OSS authors: Think carefully about communicatio

[Per Wigren]

One question is, how bad can it get? Will there one day be a "Worthless" project? There is already a "Waste".

Well, I've seen better names than ProjectTraq Intranet System Services aka "PISS" anyway.. ;)

Re:Thanks for the nightmares!

[tigersha]

Geez, if it is so easy to dig into hell why don't we launch a rescue mission? Gives the US Army somthing to do! Mind you, it might give all thos ex-Red Army soldiers something to do, since this is in Siberia.

Compatible

[shibbie]

But is it Windows 98 compatible?

Re:Compatible

[mobby_6kl]

Yes it is :) They've got a 98/NT "platform component" here

Re:OSS authors: Think carefully about communicatio

[nemesisj]

Actually, you're demonstrating how little you know about true marketing by acting as if a name can be bad.

The number one rule of marketing is that there is no such thing as bad press. Every time I see an absolutely awful commercial on TV, I'll talk about it with my friends, and we'll all agree that the commercial was terrible.

Except it isn't - it's brilliant.

We're all sitting around talking about a commercial we would have otherwise forgotten.

The same principle applies here - if you get a clever or memorable name, that is infinitely more marketable than some made-up corporate name that sounds like a new Viagra replacement.

Stop acting like you're so commercial savvy when you clearly don't have a clue. There are plenty of huge "stupid" company and product names....how about Google? Packeteer? Apple? They all turned out ok.

Already taken

[molekyl]

This naming scheme, or at least something very similar, is used by Discreet
for their effects, editing & compositing software.

Products include Inferno, Fire, Smoke, Flame, Combustion, etc.

tk is from hell?

[RussRoss]

From the download page:

"...which includes the Dis virtual machine, integral support for the Styx network protocol, and an implementation of the Tk user interface toolkit."

So Tk gets lumped in with all the other hell stuff. And here I always thought it was Tcl that was demonspawn...

- Russ

Re:tk is from hell?

[anothy]

you're right. that's why the dumped Tcl (well, from the core, anyway). Tk, of course, was already named.

Re:OSS authors: Think carefully about communicatio

[harikiri]

Apparently, because of the mascot, BSD is more popular in Japan than Linux. I believe this is due to the Japanese' crazy addiction to gimmicks.

This is based on an article I read a while back, so it's entirely anecdotal. But the point is still there, at least in one place, the mascot has made it more popular and well known.

Re:Thanks for the nightmares!

[BiggerIsBetter]

I read the snopes link and am not even religous, so take this with a grain of salt, but...

Imagine for a moment that we could drill a hole to Hell and rescue all these tormented souls. Millions upon millions - 40 billion, I think was the number cited - many of whom have been writhing in agony for thousands of years, and you just open the door for them? A couple of billion pissed off spirts running loose is not my idea of fun. If there was some way to offer them repentance before exit then sure, it's worth a shot, but giving some of the worst criminals of all time a free escape from the worst. place. evar? I don't think so, Tim.

Re:OSS authors: Think carefully about communicatio

[anothy]

the names were not chosen by marketers - or open source developers. the names were chosen by the original Bell Labs researchers who developed it. the same guys who named their last OS Plan 9, after Plan 9 from Outer Space, an earlier window system 8½ after the movie by the same name, and an earlier OS Unix, as a pun on a the last project they were involved in, Multics.

you, um, may have heard of that Unix project.

Re:Inferno on the Mac G5 --ISO DAMAGED!!

[iNiTiUM]

Use the tar file downloads instead, it did the same thing on my g3, on the fonts/ collection somewhere. Follow the instructions it works fine!

Hell DOES exist, in Norway!

[matsh]

Read about it here or google for "hell norway".

Re:Distributed Operating System?

[0x0d0a]

A better UNIX, though, sounds like a nice idea.

Not that this is bad, but it isn't just "UNIX++".

Distributed operating systems are cool -- to do research on. However, they suffer from some serious real-world-usage problems. Unless you really know what you're doing and frequently are writing the application you plan to use, you don't "magically get lots more speed" because most tasks that people want to do just don't parallelize all that well (and even if they do, take more work to parallelize). There are only a couple of non-unique software systems that *really* parallelize really, really well. Raytracing is one. The problem is that these systems are so few and far between that it's often better to just write application-specific distributed code rather than trying to write a general distributed OS that gives less good performance. There's often a fair amount of overhead involved in distributing an OS, so the vast majority of common tasks run with overhead they they wouldn't need to on a traditional OS.

*IX is pretty good. There aren't a whole lot of obvious changes I'd like to see. Hmm...if I could make changes:

* Standard home directory structure redone. I wrote a detailed proposal on Slashdot for this that allows a standard mechanism for dropping off files, having public files without exposing the contents of one's home directory, and not having config files litering ones home directory.

* ACLs being standardized (and ideally used minimally or not at all on vanilla boxes). ACLs are terribly useful for end users, as it's much easier to do many tasks (and you can do things that you can't do with the standard *IX permission scheme). Minimal use is important to keep things easy to audit.

* Linux has a fully-ordered init system rather than a partially-ordered init system. This is not that great from a performance and usability perspective. Partial orderings allow a full ordering to be forced, if necessary. However, full orderings prevent clever things being done like getting the desktop up as quickly as possible on a desktop-based system, but the nfs server up as quickly as possible on a fileserver.

* *IX lacks a standard utility that can escape all non-line-terminators. This is terribly important for dealing with files with spaces and parens and things in their name. I have a replacement awk script called "myxargs" that does this and lets me do all the standard *IX file operations easily without having my stuff barf on files named using Windows conventions.

* *IX does not have a standard set of features -- and on Linux, no easily-end-user-available features at all for transparent file encryption. Windows does. This is an embarassment.

* Chroot is very cool, but also overkill for a lot of things. I'd like to see a support for a standard Linux restricted /proc, so that things can be sandboxed without being able to see everything else running on the system (and so that users can't see what other users are running -- this has traditionally been a bit of a nasty security hole, where newbies write scripts that take passwords or other critical data as a command line argument).

* I've always wondered why network interfaces (at least under Linux, not sure if this is the same under other OSes) are not files like almost everything else in the UNIX world.

* *IX lacks a good, common secure, easy to set up a distributed filesystem. It would be really nice if AFS was a piece of cake to set up, supported large files out of box, and was present on all *IX systems. If it could serve the role that SMB/CIFS does in the Windows world (Joe User can easily make a share), but with better performance and security, and the ability to easily distribute, we'd definitely be going somewhere.

* *IX lacks a good, common, secure, easy to set up messaging client. Talk was absolutely wonderful back in the day, but firewalls and other nastiness have made it very uncommon. This is not just for desktop systems -- messaging can be a CLI application for troubleshooting and the like. I'd personally hope that such a system be able to do end-to-end encryption.

Re:OSS authors: Think carefully about communicatio

[Triskele]

Damn the xtians have scarpered. Tried to follow the jesussave.us url and it just led to a web hosting site and a paid survey site. Shame - that looked to be a good laugh.

Tried it, it changed my file perm's and ownership

[Anonymous Coward]

to 666, beatrice.beatrice!

wtf??

Re:OSS authors: Think carefully about communicatio

[pnot]

It amazes me how bad open source people are at marketing.

Obviously, if Vita Nuova's marketing is bad, it must be because there's an open source version of Inferno! Tell me, if I buy the commercial version, does the name Inferno magically become more apposite?

Do open source authors believe that there are only a few concepts available, not enough for everyone?

Try to be sensible. There's a fairly tenuous connection between naming your company and product after the works of a fourteenth-century Italian poet, and having a cute red devil logo. Why not claim they're ripping off "Stain Devil" stain removers while you're at it?

And Why did the FreeBSD project adopt that idea?

I always assumed it was a visual pun on "daemon".

I know FreeBSD is an excellent OS, and the favorite BSD for ISPs, but there are some who will be discouraged by the amateurish baby red devil marketing scheme.

Well quite. Just as people are discouraged from Linux by the amateurish fat penguin drawn by some sysadmin who's never studied marketing, right? Let's hear it from Linus himself:

I've talked to some people who are in advertising, and they love the penguin. They think it's the greatest logo ever. And it's funny thinking back. Because we made it for, I think, the 2.0 release. Like, in '95 or something? And a lot of people hated it because it wasn't serious enough. But it's great. The advertising people really like the fact that you can do things with it. "That's the stroke of genius! The guy who came up with the penguin is a marketing genius!

( http://www.oetrends.com/news.php?action=view_recor d&idnum=277 )

I think the same arguments apply to the BSD devil.

Still, the great thing about open source is that you don't have to sit there moaning, you can pitch in. Perhaps you could offer some of your marketing genius to an OSS project encumbered with a substandard logo or name. I think it's a good fortnight since Firefox last changed name -- maybe you could find them a new one :-).

In the hell link....

[MrByte420]

I particually liked this
The great 'pit' [hell] would only need to be about 100 miles or less in diameter to contain, with much room to spare, all the forty billion or so people who have ever lived, assuming their 'spiritual' bodies are the same size as their physical bodies."

Glad to see the scientific method at work.

Re:Distributed Operating System?

[latroM]

* Linux has a fully-ordered init system rather than a partially-ordered init system.

Wrong. Linux is only a kernel and it doesn't have any kind of init system. You can tell linux to use whatever executable you have on your machine (like init=/bin/bash) if you are talking about GNU/Linux then say so.

Small correction.

[warrax_666]

I didn't mean to give the impression that I think Java is very slow (the "fast enough" comment might be interpreted that way). I don't. But I don't think it is generally as fast as C, either.

I know of one case where it definitely is faster than C, though: If you implement the Fibonacci function in a naive way, then Java will be quite a bit faster than C, but this is only because it implements its stack on the heap. If you do the same in C it again beats Java.

Re:Distributed Operating System?

[serviscope_minor]

I'm going to address a few points in this post:

First about distributed OSs. Speed of a single application is not the only advantage. If some users on the system are in the habit of running several heavyweight processes, and others only tend to run lightweight ones, then the processing in that manner cn be distributed around the network. You can also transparently implement a system whereby you have mostly dumb terminals, and a few high-powered servers located in a sound-proofed, air conditioned room. You should also be able to add servers easily to this system.

Anyway, on to some specific points.

*IX is pretty good. There aren't a whole lot of obvious changes I'd like to see.

Spelling creat with a "e" :-)

* Linux has a fully-ordered init system rather than a partially-ordered init system.

Linux is really just a kernel. You can stick whatever init system you want on top of it. Redhat seem to use a bastard hybrid of sysV and BSD. I can't comment on any other distros.

* *IX lacks a standard utility that can escape all non-line-terminators.

Yes the UNIX system tools (required to have an OS rather than a kernel) could do with this in some ways. It can be a royal pain the the bum to deal with "bad" characters in a filename.

* *IX does not have a standard set of features -- and on Linux, no easily-end-user-available features at all for transparent file encryption.

Not quite sure what you mean here. If you create an encrypted loopback, then all file encryption becomes completely transparent on that filingsystem.

* I've always wondered why network interfaces (at least under Linux, not sure if this is the same under other OSes) are not files like almost everything else in the UNIX world.

What do you mean exactly? Sockets are (almost). They're not opened with open(). I think one could change that by having some layer recognose filenames and translate them in to socket calls. However, once opened, they behave like files. THat's why you can even write a wevsercer in sed, provided you get inetd to transfer the socket to stdin/stdout. Or do you mean the actual physical interfaces? If so, it's not quire obvious what to do in that case, since the file primitives work in byte streams, but network interfaces work in packets.

* *IX lacks a good, common secure, easy to set up a distributed filesystem.
What are you saying about NFS (gak) ?

There's a few features I'd like to see. One is a KDE-style IO slaves. This could be done at the libc level. In essence, it would recognise URLs, and use a program to open the URL and shove it's output in to a file descriptor for the program. Then you could do stuff like :

cp http://foo.com/bar.html .

which would be quite neat. Or,

cp cdda://* .

To rip CDs. Now, to a UNIX hacker, what could be a more intuitive interface?

Anyway, when I have some free time, I will implement this. It should be quite easy to override the system calls using LD_PRELOAD.

Don't confuse communication with making money.

[Futurepower(R)]

"Why does everything have to be commercialized?"

Please don't confuse communication with making money. It is not fun if the name you have chosen for your project causes some people to avoid it. Part of what makes a project a success is communicating about it.

Marketing is just communicating about your product or idea. It's true that most marketing contains some element of dishonesty, but that is due to the intellectual limitations of the people who write commercial ads and brochures and web sites, and their managers, and not due to the concept itself. Most people learn to hate the idea of marketing because they hate the lies, but communicating persuasively is often necessary for success.

"Some of us simply don't care, to put it bluntly."

I agree that's true, but I think it is unfortunate. It's true that communication largely determines how much you will be offered in pay when you get a new job, so money is sometimes involved. But communication also largely determines how well you will do in finding a significant other. Communication is a large percentage of everything people do.

I found it very, very difficult learning how to communicate better, but the results were worth the many years of effort.

You need communication every time you want people to go in a different direction than they would have chosen on their own. You need communication every time you want to manage or lead or convince.

My grandparent post got 14 replies in 6 hours. Why? Why didn't people just ignore it? Because I thought a lot about what I wanted to say, and then used my skill in writing to communicate it. Because it was well communicated, people could more easily decide whether they agreed or disagreed.

Part of learning how to communicate well is deciding that communication is important to you. I'm hoping to help convince some OSS authors that communication is important because I spend many hours evaluating and trying to implement open source software. Often open source web sites don't even contain explanations about the purpose of the project.

Here's an open source project that does it right: cURL. I had no trouble learning to use cURL.

On the other hand, I spent 5 hours last Saturday night learning how to set parameters for another open source project. Five hours is a lot of time to lose! And that's just for one project. Multiply the lost time on one project by thousands of projects and millions of users. The lost time because of poor communication is huge!

Re:Don't confuse communication with making money.

[HiThere]

Communication is important, and names can be important, but don't confuse the two. If you can't learn a product because it's called Inferno, that says more about you than about the product. And everything offends SOMEBODY, so one can't be hypercritical about the names.

OTOH, cURL isn't one of the languages that I've followed. And not because of the name, but because I read the license. They may have changed it, I've never bothered to look back, and won't, unless it becomes important to me. Their license made it unuseable for my applications (which require the ability to distribute freely, so the GPL is no hinderance). I could use GPL, LGPL, MPL, CPL, or any of several other licenses. But the cURL license didn't make the cut. (As I said, that was awhile ago...and I'm still not really committed, but no license that potentially allows someone else to start charging for what I've done will be acceptable.)

If you like, their license made my hair cURL. But that *IS* just being silly.

Re:Distributed Operating System?

[zhenlin]

*IX is pretty good. There aren't a whole lot of obvious changes I'd like to see.

Spelling creat with a "e" :-)

And umount with an n... (Plan 9 has unmount. Don't know about create though. It also lacks the root of string overflows, /str[^n].*/.)

* I've always wondered why network interfaces (at least under Linux, not sure if this is the same under other OSes) are not files like almost everything else in the UNIX world.

In Plan 9... the whole network interface and system is done as files, not merely the channel. (For at least the TCP part)

1. Open /net/tcp/clone (Keep the file handle, call it f_ctl) You'll end up with /net/n/ctl when you open it.
2. Write 'connect 192.168.1.1 23' into f_ctl.
3. If there is no error from the write, then read from f_ctl a number. Call it tcp_n.
4. Open "/net/" + tcp_n + "/data". (Call the file handle f_data)
5. Use f_data like a socket/pipe.

Lo and behold, you have a telnet connection to 192.168.1.1:23. You can write a whole server in a shell script without needing a wrapper.

Relevant man pages:
ether (3)
ip (3)

Anyway, when I have some free time, I will implement this. It should be quite easy to override the system calls using LD_PRELOAD.

Statically compiled binaries may not respect LD_PRELOAD and ignore your overrides, calling their static copy of libc directly.

Re:All jokes aside...(scary)

[gosand]

Is this what I think it is?

A multi-platform OS, it can run standalone, as a virtual machine on every major OS (including every linux distro) and give full blown access to the system? Plus it can run in a sort of transparent mode so you can port your app to it and have your app appear to be a native app?

(snip)

So in one sweep we have a solution suitable (sounds like it carries 1mb ram overhead) for most applications. Anything written for it magically runs on every major platform, it's highly scriptable and carries most of the magic of Unix packed with it wherever it's run from.

If it's significantly faster than Java I'd say we have a solution to the multi-distro problem as far as apps go.

While I was reading your summary, it sounded like the makings of some kind of super virus to me.

You can save me hours of boring, repetitive...

[Futurepower(R)]

"... funny reference to Pynchon's Crying of lot 49".

To those who understand the reference, it may be funny. To everyone else, it is just confusing.

FreeBSD's little devil logo is well-drawn and cute. But the logo doesn't match the subject. FreeBSD is seriously important! It's the OS of choice for those who want to run a secure web server. It's not clear to me why FreeBSD is chosen more than the other BSDs, but FreeBSD has become important to the world. The FreeBSD license allows mixing with closed source software, and commercial sale, and that's important to many commercial users. But does the logo say that? No, the logo tells first-time visitors to expect something cute.

NetBSD is also extremely important. It allows commercial companies to strip out everything unnecessary and to sell an OS that is dedicated to being an extremely secure mail server, for example. However, I don't understand the connection with a bunch of devils taking ownership over a few broken-looking computers. The FreeBSD logo gives the initial impression that it is the OS of choice for computers gotten from a dumpster.

I often need to go to people who don't have much technical knowledge and explain to them why I have chosen a software package. You can save me hours! You can save me hours of boring, repetitive explanation that the software is great, it is just the communication skills that are lacking.

Also, good managers know that communication is a large part of the total cost of implementation of software. They are correct to be scared when they see evidence of poor communication.

Re:You can save me hours of boring, repetitive...

[molnarcs]

a concession: I see you your point, but I don't think its that much an decision influencing factor as orig. post would suggest. Besides, your points I think are mainly valid for the entry level. FreeBSD already has an established market, which showed (according to netcraft - hello trolls btw :)) a steady growth over the years. I think, at this point, brand recognition (including logo) outweigh the potential hidrance.

On the other hand, I think you are right about netbsd logo, but for different reasons (political climate doesn't favor 'parodies' or jokes nowdays), and absolutely right about the project from hell :) - but I think they are not for conquering the market just yet. They are for geeks who appreciate wacky humour. Devs are not as touchy as PHBs you know. In other words, I don't think Inferno is ready for the market anyway... (the market might be ready for Inferno though, if current tendencies continue).

Maybe our RE's are *NOT* better than their RE's.

[Futurepower(R)]

The link works for me. Gee, maybe our religious extremists are not less crazy than their religious extremists.

Not only is the writing sadly funny, but I learned something. I learned that the Apple Darwin logo is named Hexley.

Inferno == furnace of creativity

[Futurepower(R)]

That's completely different. Discreet is not talking about hell or devils. The words inferno and flame and fire there mean a place where important creativity is molded.

Re:OSS authors: Think carefully about communicatio

[LWATCDR]

Well if the first syllable was not kill it would be ill. Is that any better? Why should names be important. I admit that the hell motif for inferno is just dumb. It will bother some people. I think it all comes down to AT&T or Bell Telephone or what ever you want to call it was for many many years the largest company that didn't have a marketing department!
Lets face it Unix, c, Plan 9, and Inferno all are just dumb names. Do not blame it on Open Source. These names came from a multi-billion dollar company.

really cool...

[Antilles]

this stuff is really cool, no doubt about it. The one thing IS, though, to write an application that running in parallel across many machines, well, only part of the code can do this, and many times code is not suited to be broken up and run in parallel like that. We have run into all the basic communication problems with this while writing a small distributed project for ant colony simulations. An ACO algo is well suited for parallelization when using them to build Traveling Salesman routes because of the nature of the algo having a loop that goes through many "fitness functions" that can be done in parallel. This is also true for things like Genetic Algorithms, Genetic Programming, and Particle Swarm Optimization, among others. However, just having a really well done "grid framework" such as this isnt the complete "puzzle", still software needs to be designed for it and not all models will see decent improvements being parallelized. Still, I'm sure Inferno would be at the front of the list of suitable frameworks to use to build on given its pedigree...

a list of papers on methods of parallelization of the ant algo for reference.

http://www.google.com/search?hl=en&i e=UTF-8&q=ants+site%3Aipdps.eece.unm.edu

Re:really cool...

[rpeppe]

Inferno isn't entirely about speeding things up through distributed computation, although we have done that - most importantly, it provides an appropriate set of tools for dealing with today's distributed, networked world.

By using a single, simple metaphor to represent external resources (a hierarchical filesystem with streamlined semantics), it's possible to write general purpose components that are not conceivable in other systems, because their resources are not available in such a uniform way.

For instance:

• Distributed resources: A simple, but deeply-thought-out protocol allows access to a resource hierarchy to be made available, transport independently, through a channel. Thus, any resource in the filesystem can trivially be made available over the network. This includes graphics, network interfaces, serial devices, raw disks, user-level filesystems, user-level program interfaces, etc, etc.
• Authentication: Inferno can use a single well-defined authentication protocol to secure access to all external resources in a transparent, end-to-end fashion. Applications need not have any knowledge of this, but nonetheless gain all the benefits. If you're using this stuff, you couldn't care less about 802.11 security (or lack of it) - it's irrelevant.
• Transformation: it's easy to "layer" resources; for instance I could export a read-only version of a particular resource just by forbidding all Styx Twrite, Tremove, Twstat, etc operations.
• Application transparency: because everything looks like a file, and all the traditional unix tools just work on files (or byte-streams - same difference), it's possible to use all of Inferno's unix-like tools directly on devices, or aspects of a program's external interface without any extra "glue" code at all. This vastly decreases the dev-time, as you can just write independent components, test them individually, and just stick 'em together to make the final application.

Basically it's all about isolating complexity, network and everything else, into independently verifiable bits; the system lets you plug it all together.

Almost all of the complexity in most conventional systems today comes from backward compatibility requirements. Inferno can do what it does by discarding that backward compatibility - the obvious cost is that it's quite an effort to get your old programs to run underneath it. However, for many applications, that's not an issue, whereas the unreasonable complexity of other "modern" systems is.

Re:OSS authors: Think carefully about communicatio

[double_h]

Actually, there is such a thing as bad press. this didn't help [entertainment company], this didn't help [soft drink manufacturer].

Yes, it did help them -- it got you to give those companies free advertising up there.

Re:Distributed Operating System?

[the chao goes mu]

cp http://foo.com/bar.html . There are three utilities to do this already:

fetch
wget
lynx [-source|-dump]


You could easily wrap cp in a perl script (if $arg[1]=~/http:\/\//){`fetch ...`;}else{`cp ....`;} and so on) then alias your cp command to this script.
Why bother reinventing the wheel?

Re:Distributed Operating System?

[0x0d0a]

Wrong. Linux is only a kernel and it doesn't have any kind of init system. You can tell linux to use whatever executable you have on your machine (like init=/bin/bash) if you are talking about GNU/Linux then say so.

If it offends your sensibilities, please feel free to use s/Linux/Most Linux distributions/. For brevity, readability, and because most folks know what I'm talking about, I frequently make this shortening. Given that the initscripts I run on my system are SysV init but not a GNU project, it hardly seems fair to give GNU the credit for them.

Re:Distributed Operating System?

[serviscope_minor]

cp http://foo.com/bar.html . There are three utilities to do this already:

fetch
wget
lynx [-source|-dump]

You could easily wrap cp in a perl script (if $arg[1]=~/http:\/\//){`fetch ...`;}else{`cp ....`;} and so on) then alias your cp command to this script. Why bother reinventing the wheel?


Because the solution you suggest is very non generic, ie it only works for http:// and it only works for the cp command. What I suggest is not much different from what you suggest. I'm suggesting wrapping the relavent bits of libc to call those programs such as wget on demand (based on per-user configuration, of course). That way you could make it work for every program that wasn't statically linked and didn't use syscalls directly.

It isn't reinventing the wheel, it's using the large body of existing code to do the really hard work (like getting web pages).

Re:Distributed Operating System?

[0x0d0a]

I've just reposted it to my journal.

Dunno if "detailed proposal" is fair, though, in retrospect, but it's more than just a vague idea.

Re:Distributed Operating System?

[0x0d0a]

If some users on the system are in the habit of running several heavyweight processes, and others only tend to run lightweight ones, then the processing in that manner cn be distributed around the network.

Mmm...yes, theoretically, but a desktop system is pretty powerful these days -- the draw isn't what it once was. You have to have a process that is so heavy that the user wants to put it on another system, not heavy enough that it has its own custom distributed system (like a raytracer or custom scientific computation system), and you have to work to avoid processes that depend on each other winding up on different nodes.

You can also transparently implement a system whereby you have mostly dumb terminals, and a few high-powered servers located in a sound-proofed, air conditioned room. You should also be able to add servers easily to this system.

Yeah, but there are an awful lot of ways to pull this off without using a full-blown distributed system. A nameserver with lightestloaded.foobar.edu, for instance.

Spelling creat with a "e" :-)

Hey, some of us get RSI! Seriously, I guess if I had a single irritation on this level, I'd like to see "less" renamed to something a bit more newbie-friendly.

Linux is really just a kernel. You can stick whatever init system you want on top of it. Redhat seem to use a bastard hybrid of sysV and BSD. I can't comment on any other distros.

Sure, but other than Slack, I don't think any mainstream distros use non-SysV.

Not quite sure what you mean here. If you create an encrypted loopback, then all file encryption becomes completely transparent on that filingsystem.

Windows encryption -- check "encrypted" box on directory/file property tab.

Linux encryption -- not supported with end-user-friendly interface on most boxes, where "pretty end user interface is present, support for mounting my home directory unencrypted at login time is present, no standard way for user to specify what things he'd like encrypted/unencrypted -- you'd need to hack some sort of suid filesystem creation utility up". Since support is at the block device level rather than the filesystem level, mixing encrypted and unencrypted files is a PITA. Not a standard *IX-wide way to do this.

There's a few features I'd like to see. One is a KDE-style IO slaves. This could be done at the libc level. In essence, it would recognise URLs, and use a program to open the URL and shove it's output in to a file descriptor for the program.

Mmm. One problem is that this breaks long-standing guarantees about the format of UNIX paths, which means that a number of programs would break.

FUSE (kinda like LUFS, if you're more familiar with that project) provides KDE IOSlave support at mount time, just not open time.

Old, old, stuff

[agin]

I had a client that was developing appliances for Inferno back in 1997. They licensed it from Inferno Network Software Solutions, which was part of Lucent.

TuxScreen

[ecloud]

So does this mean it's now possible to develop software to run on the TuxScreen, in its unmodified form? I never did get around to installing Linux on it...maybe just developing Inferno apps would be easier.

My favorite user license term ever

[m_evanchik]

The thankfully short license agreement for Plan 9 includes the following provision:

"I will not be using Plan 9 in the creation of weapons of mass destruction to be used by nations other than the US."

There are so many ways that this is funny. There are enough jokes in that one line to keep a sitcom running for two years, maybe more.

Re:OSS authors: Think carefully about communicatio

[HiThere]

Both BSD and Inferno probably got their inspiration from a paper called something like "Pandaemonium, activation by a collection of daemons" (I really don't remember the name of the paper, it's WAY back! It may be in an old FJCC or SJCC proceedings...or possibly in some issue of Communications of the ACM. Check during the '70s or '80s.)

Anyway, that was the first encounter I had with the idea of a daemon as a program that just sat around waiting for an activation command. (It may not have been new then, but that was my first encounter with it.)

Now Unix et al. are definitely run on a development of that principle, so it makes sense to represent them with an iconic depiction of one of their important characteristics (which other OSs of the time didn't have [or if they did, I never heard of it...but I was generally running my programs as the only active program in any time slice on an IBM 360 [DOS, as I recall, though I heard about MFT occasionally]).

Inferno definitely blended in inspiration from Dante, and that may have inspired the authors of the Pandaemonium paper, but I really doubt if the BSD authors were thinking of that. (Check out the depictions of devils & demons in Dante's Inferno...not a close match.)

Additional License issue

[Harik]

You must make available all source code for your applications and Inferno to:

• Anyone to whom you distribute
• Anyone to whom you provide a service using Inferno

Yikes! So, If I write a custom inferno-based anything and use it internally, I probably have to release _MY_ source to any/all of my clients, paying or not?

This is realistically commercial software with a "demo" license. You can't do anything serious with it. (Compare to Perl/PHP/Apache)

Re:Additional License issue

[justins]

Realistically, it's not any more "restrictive" than linking against GPLed libraries or something, which would require you to GPL your app. The "services" part is a bit unusual but I wouldn't be surprised to see it in a future version of the GPL, or some other mainstream OSS license. Being able to offer software as a "service" is considered a loophole of the GPL by many.

Re:Additional License issue

[Harik]

Well, I can understand it for things like ASP functionality, but there's a difference between ASP and "used to provide a service". The latter could mean that if I write code for someone I have to give them access to our home-built development environment.

Imagine if the "services loophole" was closed in the GPL. If I used Gnumeric to keep track of clients, with a custom-written DB connector to oracle: I suddenly couldn't, since the oracle libraries are non-free. WHAT? There's nothing in the GPL stopping me from linking to whatever I want, but I can't distribute incompatably-licenced software. If I suddenly can't _USE_ incompatably-licensed software, it makes using GPLed software for internal purposes neigh-useless.

The cURL license seems okay now:

[Futurepower(R)]

The cURL license seems okay now: cURL license. I suppose it wouldn't be on Sourceforge if it weren't okay.

Don't confuse cURL with Curl, from the Curl Corporation.

I don't believe in hell

[HermanZA]

should I believe in inferno?

Re:OSS authors: Think carefully about communicatio

[justins]

It amazes me how bad open source people are at marketing. Why make your project, which requires a huge amount of excellent thinking, the butt of jokes?

Why give a name to your open source project that will cause those who have less than complete technical knowledge to feel uncomfortable about adopting what you have done?

I would think the only people rendered uncomfortable by their marketing would be subliterates who don't know who Dante is. I mean, who cares?

Native download?

[justins]

Is the native version available for download, or just the "hosted" versions? The fact that's it's omitted from their list doesn't make it entirely clear - I guess I'm hoping the native version is somewhere else on their site.

Allusion to Dante's works

[Geoffreyerffoeg]

Dante Alighieri wrote The Inferno, of course, but he also wrote a book called La Vita Nuova , "The New Life", a poetic expression of his love for Beatrice.

The organization that released Inferno is thus called Vita Nuova.

Re:Thanks for the nightmares!

[tigersha]

Ok, valid point. It would be like busting the doors on a major high-security prison: all the badass types would get out!

On the other hand my experience with some Christian whackos would indicate that launchins a rescure mission into heaven would unleash, well, hell.

Re:Distributed Operating System?

[the chao goes mu]

I don't know if I would want evey call to any fiel read to go to a matching web page. It seems like it might open a whole lot of security holes. After all, most firewalls pass out any request. So, if you have a webserver, to get exploit code on a machine all you have to do is find a badly written cgi and pass the argument template="http://badman.com". The suggestion to modify all of libc would give your entirte OS the weaknesses inherent in languages like PHP, the inability to tell the difference between more secure local files and totally insecure remote files.
Admittedly, my wrapper would add this weakness to cp, but only on a per-user basis, and only from the login shell. Still a security hole, but a much smaller one.

Re:Thanks for the nightmares!

[Syberghost]

Read Peter F. Hamilton's Night's Dawn trilogy for an interesting take on this from a science fiction angle.

FreeBSD has powerful marketing: Quality.

[Futurepower(R)]

FreeBSD has powerful marketing: Quality. There are many obvious indications of quality. However, as I said, I think the presentation works a little against this. It is possible to be humorous and engaging without being self-defeating, I think, but doing so is a big intellectual challenge in a field in which technical people often don't suspect is so complicated and demanding.