Slashdot Mirror


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."

89 of 287 comments (clear)

  1. inferno? by wvitXpert · · Score: 5, Funny

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

    1. Re:inferno? by earlgreen · · Score: 5, Funny

      No, that's called Windows.

    2. Re:inferno? by Anonymous Coward · · Score: 5, Funny

      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.

    3. Re:Inferno? by frenetic3 · · Score: 4, Informative

      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

      --
      "Where are we going, and why am I in this handbasket?"
    4. Re:Inferno? by Anonymous Coward · · Score: 5, Interesting

      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

    5. Re:Inferno? by zhenlin · · Score: 3, Interesting

      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.

    6. Re:Inferno? by Anonymous Coward · · Score: 2, Informative

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

    7. Re:Inferno? by slamb · · Score: 4, Informative
      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.

    8. Re:Inferno? by warrax_666 · · Score: 4, Insightful
      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).
      --
      HAND.
    9. Re:Inferno? by anothy · · Score: 4, Informative

      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.

      --

      i speak for myself and those who like what i say.
    10. Re:Inferno? by slamb · · Score: 3, Interesting
      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.

    11. Re:Inferno? by Anonymous Coward · · Score: 4, Interesting

      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.

    12. Re:Inferno? by warrax_666 · · Score: 5, Insightful
      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).
      --
      HAND.
    13. Re:Inferno? by Quixote · · Score: 4, Insightful
      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.

    14. Re:Inferno? by rpeppe · · Score: 2, Insightful
      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).

  2. Just what we need by Anonymous Coward · · Score: 5, Funny

    Oh great, a Christian operating system. Lovely.

    1. Re:Just what we need by Veridium · · Score: 5, Funny

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

      --
      Think for yourself, destroy your television.
  3. Inferno? by Anonymous Coward · · Score: 4, Funny

    Is the company in cahoots with the BSD daemon?

  4. informative by Anonymous Coward · · Score: 4, Funny

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

  5. License by vinit79 · · Score: 3, Interesting

    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

    1. Re:License by Tarantolato · · Score: 5, Informative
      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).
    2. Re:License by illuminata · · Score: 2, Insightful

      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.

      --


      Until Slashdot fixes the funny modifier, use insightful or interesting. The poster knows your intentions.
    3. Re:License by runderwo · · Score: 4, Interesting
      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.

    4. Re:License by Anonymous Coward · · Score: 2, Insightful
      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.
    5. Re:License by anothy · · Score: 2, Interesting

      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.

      --

      i speak for myself and those who like what i say.
  6. Shall Jesux rise again? by cant_get_a_good_nick · · Score: 4, Funny

    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

    1. Re:Shall Jesux rise again? by root_42 · · Score: 2, Informative

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

      --
      [--- PGP key and more on http://www.root42.de ---]
  7. Yeah I tried it by Orion+Blastar · · Score: 4, Funny

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

    --
    Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
    1. Re:Yeah I tried it by 0racle · · Score: 2, Funny

      Administrator? I thought superuser was Dante?

      --
      "I use a Mac because I'm just better than you are."
    2. Re:Yeah I tried it by JanneM · · Score: 5, Funny

      No, he just had a guest account.

      --
      Trust the Computer. The Computer is your friend.
  8. yay! by Lord+Ender · · Score: 4, Funny

    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.

    --
    A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
    1. Re:yay! by anothy · · Score: 3, Interesting

      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.

      --

      i speak for myself and those who like what i say.
    2. Re:yay! by anothy · · Score: 2, Interesting

      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.

      --

      i speak for myself and those who like what i say.
  9. New p2p by hsidhu · · Score: 4, Interesting

    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.

    1. Re:New p2p by Temporal · · Score: 5, Insightful

      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.

    2. Re:New p2p by Darren+Bane · · Score: 3, Interesting

      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".

      --
      Darren Bane
    3. Re:New p2p by Temporal · · Score: 2, Interesting

      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. :)

    4. Re:New p2p by hummassa · · Score: 2

      >> 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.

      --
      It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
  10. Why the last link? by Naked_Ninja · · Score: 2, Insightful

    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.

  11. Comment removed by account_deleted · · Score: 3, Funny

    Comment removed based on user account deletion

  12. Hell comes in many flavors by warkda+rrior · · Score: 5, Funny
    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.
    --
    You need to install an RTFM interface.
    1. Re:Hell comes in many flavors by kalidasa · · Score: 2, Informative

      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).

    2. Re:Hell comes in many flavors by scrytch · · Score: 2, Funny

      > 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...

      --
      I've finally had it: until slashdot gets article moderation, I am not coming back.
  13. Good introduction to Limbo by harikiri · · Score: 5, Informative
    ...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.

    --
    Man watching 6 MSCE's around a sun box, looks alot like the opening scene's of 2001:space odyssey...
    1. Re:Good introduction to Limbo by shaitand · · Score: 4, Informative

      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.

    2. Re:Good introduction to Limbo by goga · · Score: 2, Informative

      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.

    3. Re:Good introduction to Limbo by anothy · · Score: 4, Interesting
      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.
      --

      i speak for myself and those who like what i say.
  14. OSS authors: Think carefully about communication. by Futurepower(R) · · Score: 5, Insightful


    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.

  15. Re:Cool ... by CdBee · · Score: 4, Funny

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

    --
    I have been a user for about 10 years. This ends Feb 2014. The site's been ruined. I'm off. Dice, FU
  16. Looks right. by jcuervo · · Score: 3, Funny
    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.
    --
    Assume I was drunk when I posted this.
  17. Re:OSS authors: Think carefully about communicatio by shaitand · · Score: 4, Funny

    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 ;)

  18. OSS authors:Think carefully about [making money] by Anonymous Coward · · Score: 5, Insightful

    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.

  19. Alternative to VMWare? by gbulmash · · Score: 4, Interesting
    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.

  20. Re:OSS authors: Think carefully about communicatio by molnarcs · · Score: 4, Insightful
    "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.

  21. Re:I thought a better unix was ... by Tarantolato · · Score: 5, Informative

    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.

  22. Inferno on Lucent BRICK Firewal by hytrex · · Score: 4, Informative

    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

  23. All jokes aside... by shaitand · · Score: 5, Insightful

    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.

    1. Re:All jokes aside... by Anonymous Coward · · Score: 5, Informative

      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

    2. Re:All jokes aside... by shaitand · · Score: 2, Informative

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

    3. Re:All jokes aside... by HiThere · · Score: 3, Insightful

      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.)

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
  24. Re:OSS authors: Think carefully about communicatio by drgonzo59 · · Score: 5, Insightful

    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

  25. Re:OSS authors: Think carefully about communicatio by Homology · · Score: 3, Funny
    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.
  26. environment by cybergrunt69 · · Score: 2, Insightful

    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.

    --
    --- "To ignore race and sex is racist and sexist!" -- Jesse Jackson
    1. Re:environment by mritunjai · · Score: 4, Funny
      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).

      --
      - mritunjai
  27. Inferno on the Mac G5 by Watts+Martin · · Score: 2, Informative

    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.

  28. Re:we don't want you to burn in hell by gunpowder · · Score: 2, Interesting
  29. I seem to remember... by AgentAce · · Score: 2, Informative

    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.

    1. Re:I seem to remember... by zhenlin · · Score: 2, Informative

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

  30. Discreet's Inferno by tinrobot · · Score: 3, Interesting

    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/

    1. Re:Discreet's Inferno by wildjim · · Score: 3, Interesting

      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.

  31. Tinkered with an early version of Inferno by Anonymous Coward · · Score: 3, Informative

    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 .

    1. Re:Tinkered with an early version of Inferno by anothy · · Score: 4, Informative

      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).

      --

      i speak for myself and those who like what i say.
  32. Call me when they get to by panurge · · Score: 4, Funny
    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...

    --
    Panurge has posted for the last time. Thanks for the positive moderations.
    1. Re:Call me when they get to by pnot · · Score: 2, Funny

      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...

  33. Re:OSS authors: Think carefully about communicatio by Per+Wigren · · Score: 2, Funny

    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.. ;)

    --
    My other account has a 3-digit UID.
  34. Re:Thanks for the nightmares! by tigersha · · Score: 2, Funny

    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.

    --
    The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
  35. Already taken by molekyl · · Score: 2, Informative

    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.

  36. Re:Thanks for the nightmares! by BiggerIsBetter · · Score: 2, Offtopic

    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.

    --
    Forget thrust, drag, lift and weight. Airplanes fly because of money.
  37. Re:Distributed Operating System? by 0x0d0a · · Score: 3, Interesting

    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.

  38. Re:Tryst with Plan9 by anothy · · Score: 4, Interesting

    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).

    --

    i speak for myself and those who like what i say.
  39. Re:Distributed Operating System? by zhenlin · · Score: 2, Informative

    *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.

  40. Re:All jokes aside...(scary) by gosand · · Score: 2, Funny
    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.

    --

    My beliefs do not require that you agree with them.

  41. You can save me hours of boring, repetitive... by Futurepower(R) · · Score: 2, Interesting


    "... 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.

    1. Re:You can save me hours of boring, repetitive... by molnarcs · · Score: 2, Interesting
      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).

  42. Re:really cool... by rpeppe · · Score: 4, Informative
    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.

  43. My favorite user license term ever by m_evanchik · · Score: 2, Funny

    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.

  44. Re:OSS authors: Think carefully about communicatio by HiThere · · Score: 2, Interesting

    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.)

    --

    I think we've pushed this "anyone can grow up to be president" thing too far.
  45. Additional License issue by Harik · · Score: 2, Insightful
    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)

  46. The cURL license seems okay now: by Futurepower(R) · · Score: 2, Informative


    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.