Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
News

Inferno Source Release 98

Posted by Hemos from the burn-it-up-baby dept.
shawk writes "Vita Nuova today announced that it has obtained the exclusive, worldwide rights to the Inferno Operating System from Lucent Technologies' Bell Labs and that it is to publish the Inferno source code under inexpensive, commercial licence terms. Vita Nuova has also announced that Lucent Technologies and a UK investor have invested equity capital into Vita Nuova to develop and market Inferno. Personal Inferno Subscriptions cost $300 with a 50% discount for academics and students. Corporate subscriptions cost from $1000 for five developers. You can order your Inferno boxed set including CD, programmer's manual and papers today. Full details can be found at the Vita Nuova."
This discussion has been archived. No new comments can be posted.

Inferno Source Release More

Inferno Source Release

Comments Filter:
  • I've followed inferno for quite some time hoping lucent would do something with it. Now that source code is somewhat available I'll get the chance play fiddle with this on Alpha. Groovy
    --
    www.alphalinux.org

  • Re:"New Ideas" in Inferno (Score:1)

    by Anonymous Coward
    "1. Runs on a Virtual Machine
    Inferno only runs directly on one architecture: the Dis virtual machine ..."

    That's wrong. If you read the documentation you will see that Inferno runs directly on the hardware. It's the applications that run in the VM.

    From the website: [Limbo programs are compiled into byte-codes representing instructions for a virtual machine called Dis]

    Much like Java applets. It would be more acurate to say that Inferno IS a VM.

    "2. Written in Limbo
    Most of Inferno was written in a new language called Limbo ..."

    From the website: [Inferno is, to the extent possible, written in standard C and most of its components are independent of the many operating systems that can host it.]

    Again, it's the applications that are written in Limbo, not the OS. Limbo compiles into bytecode. The bytecode is executed by a VM. Again, sounds like: Java.

    I don't see why one would spend time with this OS that only supports an obscure language. If it had been Java it would have been much more useful.

    Breace.
  • Can anyone make it clearer what, besides Limbo and the VM, differentiates Inferno from Plan 9? NameSpaces, everything is a file and network transparency are all Plan 9 hallmarks, yes?
  • Because the inchfan is so L337 that we have to screen candidates. [slashdot.org] It's a long and grueling application process, and I'm not quite sure that you could hack it. We're talking a half dozen phone interviews, of about 45 minutes each, 4 days personal interview (though we do put you up in a local hourly motel when we're through with you), complete reference check going back to third grade, require a sizeable tithe bi-monthly. IF you pass the first round, then there are further trials you must pass, but I can't let you know what they are until you past the first day.

    Rule one: No one talks about the Inchfan.

    Rule two: Don't listen to a word I say ;-)
  • actually, i read the book, it's not about hell, it's a love story. Dante' tranversion of all levels of the afterlife to return to his beloved Betrice(sp?). Very good book, Inferno, recommend the entire series, keept me entranced for a whole summer in 10th grade.
  • This is actually a very good question.

    Inferno comes from Lucent, which was once Bell Labs. Plan9 comes from AT&T, which Bell Labs was once a subsidiary of.

    However, I have looked and found no evidence of a common heritage (beyond both of them being unices).
  • well, it's only the core OS that's being charged for - most of the development environment is free (as in beer & liberty), unencumbered, open source, whatever you want to call it. that includes (at the last count) 225460 lines of Limbo source code doing all sorts of cool things outside the kernel.

    you can do with that what you want. if you want to hack the kernel, port it to a new platform, whatever, then, yes you have to pay your $300 and become a subscriber. but once one person has done that, they can distribute the kernel binaries with no hinderance, and due to the portable nature of inferno, all worked under it will still work under the new version.

    if i wasn't involved in inferno development and was stuck under Windows of some description, then i'd get a copy, just for the environment. unix-like shells under NT are ok, but they don't give you that "my whole environment is pliable under my fingers" feel that having a complete environment does.

    the beauty of inferno includes the fact that once you've got something in your namespace (and everything, including network connections, is accessed through the namespace) you can transparently export it through any type of datalink, with whatever sort of encryption/authentication you want, and use it as if it was local. i don't know any other system that provides that much flexibility for so little protocol overhead.

  • Cleanliness vs. Performance. (Score:3)

    by be-fan ( 61476 ) on Wednesday June 21, 2000 @06:40AM (#986278)
    I was reading through the Inferno docs, and I must say, I'm quite impressed. It looks like a very clean and unified architecture. However, does the cleanliness of the design outweigh the performance disadvantages of this? Sure it may make it easier to port, and the whole "everything is a file!" think may make it a more unified design, but in the end is it worth it? Two things.
    A) Most operating systems only run one major architecture. Portability is good, but excessive portability at the expense of speed is bad. I think Linux strikes a nice balance in this regard, it uses ugly performance code when it has to, but keeps the whole thing pretty portable. Also, according to the Be developers, "there is no such thing as portable code, only code that has been ported."
    B) Everything is not a file! To some extent, it makes sense, but I never understood the whole file concept. Isn't it much simpler to treat everything as a region of memory? So if you are writing a driver, you simply write to regions of memory starting from a base address rather than doing ioctls, which seem to abstract it to much. Also, when stuff like DNS lookups are done through files, isn't it getting a little silly? Isn't it simpler to map closer to the way the software is actually working? Especially in the cases of stuff like DNS lookups which don't totally make sense being treated as a file. Also, doesn't going through the FS create some overhead? In BeOS a region of shared memory (an "area") is simply a region of memory. You get a pointer to it through the create_area() function, and you tell the OS that you're done with it through delete_area(), kind of like malloc() and free(). In kernel 2.4, it is treated as a file mounted at /var/shm, and means that every access incurs a slight overhead by having to go through the file system.
  • Small nitpick. QNX is also a(n) UNIX.
  • I wouldn't say they compete. They complement each other.

    I expect to see them working more closely together now that they have both been made generally available.

  • Isn't it much simpler to treat everything as a region of memory? So if you are writing a driver, you simply write to
    regions of memory starting from a base address rather than doing ioctls, which seem to abstract it to much.

    Well, you could treat your disk as a linear array of blocks, but for all the different things you use it for its convenient to have a hierarchical organization. Trees are very nice because they allow you to handle a large quantity of heterogenous data to potentially organize huge volumes of information in an fractal manner.

    Maybe it would be more correct to ask whether you would prefer to organize everything you deal with in a flat address space like a hash table or in a directed, possibly cyclic graph. Maybe there are better abstractions, but if you have to live with one, DCGs are probably a good choice.

    Also, when stuff like DNS lookups are done through files, isn't it getting a little silly? Isn't it simpler to map closer
    to the way the software is actually working?

    No, I think its easier to read the contents of the virtual file "/network/IP/dns/www.slashdot.org" than to learn a custom set of function calls just for DNS. DNS is a critical, but very small part of many programs. It is bad to have a large number of small, critical parts to a program, each with its own idiosyncratic abstraction and needing its own set of mental and software tools. The fact that a mechanism may closely tracks the underlying implementation has no particular virtue -- why provide abstractions at all unless they transform the underlying problem in a significant way? The application programmer typically has no more interest in the underlying design of something like TCP/IP sockets than he does in the physical geometry of his hard disk. It's a necessary evil.

  • yeah, leave it to the techies over at bell labs to ruin a great os by tying it to a ridiculous gui... how 'bout those smiley faces though :)

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

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

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

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

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

  • Apart from the two things that you mention the one big difference is that it can run as a virtual operating system - i.e. as an application within Plan 9, Linux, Windows, etc.

    Programs running under Inferno neither know nor care whether they are running natively or hosted on one of these operating systems.

    Vita Nuova [vitanuova.com] has an Inferno plug-in for Internet Explorer which allows a Dis (Compiled Limbo) program to run in a window in a web page. The same compiled program can run (without re-compilation) under Inferno on, say Linux, or on one of the web-phones here in the office.

  • In fact many elements of Inferno have been eponymously named after Dante's Divine Comedy. Inferno and Limbo you have already covered. DIS, the virtual machine, is the citidal at the centre of hell, STYX, the protocol, is the river that runs through hell and Charon, the browser, was the boatman who ferried souls from Limbo into hell. Vita Nuova also has a link. Dante's first work which was a book of poetry about his first love, Beatrice, is called La Vita Nuova - meaning new life. Beatrice features again in the Divine Comedy as it was she who sent Virgil to guide Dante through the Inferno.
  • I agree. I am also reminded of an incident in Dublin a few years ago; when lost in the city I asked a taxi driver for directions to the airport. His response was 'I would not start from here'. Linux has proven very effective in the server space but if you were to ask me for directions on how to make it embedded I would reply with the same response as the taxi driver. The alternative is to pay as little as $150 and get the source code to an OS that was designed for the embedded space and use that as your starting point.
  • To consider Inferno as just an OS is to miss the point some what. Inferno is a collection of technologies to support the development of distributed applications across a range of devices from the tiny (see the lego brick example at the Vita web site) to the large. I observe that the radical difference between it and other approaches is that it emphasises the distribution of protocol not program in its model. For example, in the Java world distribution relies upon the support of the Java VM (a large program) which for small devices is problematic. Inferno, on the other hand utilises a simple, unifying protocl Styx to support the 'represent everything as a file metaphor' and can be implemented on legacy systems and tiny devices with ease.

    Analogies are sometimes useful. If you like the Inferno distribution metaphor then you can implement Styx without subscribing to Inferno, in the same way you can implement http without using Netscape or IE. The Inferno OS provides an environment (both native and hosted) that leverages Styx and provides a complete, simple and scaleable solution for constructing distributed applications.
  • > As to where the Inferno kernel runs in regard to the Dis VM and the actual hardware, I'm not really sure.

    Clearly the Dis VM is run inside the kernel. There are two kinds of Inferno kernel. The first kind runs directly on the hardware much like other operating systems - natively. The second, often refered to as a hosted kernel, runs on top of another operating system.

    The hosted form is likely to be of interest to new users of Inferno. It runs as an application on, amongst others, Windows, Linux, Plan 9, Free/BSD and Solaris. The same Dis virtual machine runs in this virtual operating system - you can run the same programs unmodified, including the entire Limbo development environment. In its hosted form, the kernel uses the services of the hosting operating system. So for example, it uses the NT or Linux filesystem, it uses the X or Windows low level graphics primitives, it uses their networking services to reach the outside world. This means that it instantly leverages the effort that has been put into developing drivers for other operating systems such as Linux and NT.

    An Inferno application doesn't need to know which kind of kernel it is running on - they all look the same to it. Take the Lego brick [vitanuova.com] on the Vita Nuova website. This can be controlled by a Limbo application. That same Limbo application can be run from Windows, Linux, Plan 9, the screenphone on my desk (running native Inferno) or even from within a web page in Internet Explorer (using the Inferno plug-in) - without re-compiling it.

  • Okay, I'm thinking of it as code associated with a name space. However, when you have a function, you actually have a pointer to the memory where that code is, and a function call is simply a jump to those instructions. For example, In Linux: You call gethostbyname(). It calls a system trap which jumps to that code inside the kernel (or netoworking library or whatever.) That function then procedes to get the host name and return it.

    that's almost exactly how it happens in Inferno too. the fact that the metaphor for the gethostbyname call looks like a file system really causes hardly any overhead. this is how it happens in inferno (and in plan 9 for that matter only there you need a trap to get out of user mode into supervisor mode):

    first you open the file /net/cs. if the network device is local, which it usually is, then the entry in the file descriptor table is now a pointer to a kernel Chan that has been provided by the device serving /net. Inside this Chan is a set of function pointers, one for each of the basic file operations (i.e. open, read, write, stat, etc). when you do a write of, say tcp!slashdot.com!http, the kernel just has to do a single indirect function call to the write() function in the Chan and you're in the device driver. this is probably just as efficient as a Linux system call, especially since that in Inferno there's no distinction between user mode and supervisor mode (the language is safe), so you don't have the overhead of doing a processor trap.

    In Inferno: You write something to a virtual file. The Inferno filesystem intercepts the write. It takes a look at what command you are trying to do, takes a look at the stuff you feed it (parameters) and then passes that info onto the networking code in the kernel via a function call. This step of having the kernel intercept the call and decode it is what introduces the overhead.

    the kernel doesn't have to ``decode'' the call any more than a linux kernel does. yes, it has to verify that the file descriptor is valid (big deal, if (fd >=0 && fd <= fdgrp->maxfd)) it's the device driver itself that does the decoding of the request, and since in the case of gethostbyname() you're just mapping from a string anyway, there is no more overhead.

    Also, since it is a virtual file, memory writes and reads have to be done than during a funciton call. All this is what introduces the overhead.

    nope. inferno system calls do not make any copies of the data unless they have to. i just had a look at the relevant code, and the pathway between a user program doing write() and the device getting that call probably about 20 to 30 machine instructions executed. there is no real overhead compared to the traditional syscall interface.

    BUT what you do get is consistency across all device interfaces. because gethostbyname() is not just a system call, but is part of the namespace, i can export that down any data connection. so, say i've got a little handheld device that has no tcp/ip stack, no DNS, nothing apart from some sort of serial driver and the Styx driver (which is very small), then i can connect it up to my desktop PC, import the network devices + /net/cs from it, and bingo i've got what looks like direct access to the net. yes, i've now got to send those requests over the serial link now, but i can do something that i couldn't do otherwise without inventing my own, use once, limited purpose protocol...

    that applies to all inferno devices. the fact that the interface is an abstract one does not necessarily mean that it's inefficient. if you're interested, have a look at the plan 9 [cmu.edu] code (login 9fan, password glenda) that does the same thing. i think you'll find that the path from user program to system call implementation code compares favourably with most *NIXen.

    the file abstraction in inferno is a wonderful thing - if you're using it, it means you don't have to write a specialised protocol for every new network service - if a service is running locally, it's efficient; if it's running remotely, the protocol work is done for you.

  • Point 2. 'Most of Inferno is written in Limbo' is not qutie correct. The operating system itself, device drivers etc. are written in C. The bulk of the applications many of which are familiar commands (see the Vita web site for details) are written in Limbo. One gets an interesting insight into the efficacy of the language when comparing these implementations to the C equivalents.
  • yes. Lucent stands for Lucifer Enterprises.
    figure that out u grasshopper.
  • True, in the case of DNS it is definitely network traffic. But what about more important syscalls and calls to stuff like graphics or sound libraries? These functions are called many times repeatedly, and often (as in the case of some graphics calls like putpixel) the function call actually takes less time to exectute than the actual function.
  • Is there any relationship between Inferno and Plan9?


  • finally, an operating system that will work with my legos... this is a pivotal turning point in cad development
  • Think of it... where'd that name come from?

    is it because someone said "what the hell is that for?"

  • There is alot more info at the Bell Labs website. It appears to be yet another Network OS but I think it is well work a look. Running it as an application under linux won't cost me anything so I may give it a try. Also Bell Labs has some great documentation on the OS at their site, including a programmers manual for Limbo the OS's programming language various other things that might be of interest read or download it all here [bell-labs.com]. I gotta admit that the screenshot [bell-labs.com] of the Inferno desktop doesn't inspire me. I don't think that the GUI is the main concern of these developers and that IMHO is a good thing. Peace
  • yeah, leave it to the techies over at bell labs to ruin a great os by tying it to a ridiculous gui... how 'bout those smiley faces though :)
  • How many other OS choices do we need?

    As many as possible, please. Choice is good, the more choice you have, the better chance is that you can find an OS that suits you and your needs best. Not only that, but as long as people continue to create new OSes, new ideas can be introduced and computers can continue to get better.

    Linux wouldn't be where it is today if Linus had thought "Oh, we already have BSD, DOS, AmigaOS, SunOS etc. etc." (Except, he would probably have thought it in Swedish.)
  • There is a minority of Swedish-speakers in Finland. Linus is one of this minority.

  • What all products are currently using the Inferno OS?

    I know that the Lucent Managed Firewall / VPN Gateway does, and I have to say, even though it has quite a price tag (>$10k), it's still a very nice device. They integrate a full feature ICSA and NSA-certified hybrid firewall including anitivirus control and URL blocking. I believe the throughput is in the 75 Mbps range for 3DES (with a few thousand VPN tunnels). Real nice box, but yeah, you pay for it.

  • Ever since I had to support there Winmodems I have thought that Lucent should really have been called Lucifer and now Inferno. They are Satan stay away stay away.
  • AC is right in that I did botch a few of these points. I apologize for the inaccuracies; I was listing things off the top of my head without consulting the official sources.

    Specifically, Inferno was indeed written mostly in C (not in Limbo). Limbo is the language for application developers, and is compiled to bytecode for running on the Dis VM. As to where the Inferno kernel runs in regard to the Dis VM and the actual hardware, I'm not really sure. Check the websites for more info.

    My other previous comments are accurate to my knowledge (namespaces, files, Styx, etc.)

  • Anyone know if Plan9 got the FSF and OpenSorce org's stamp of approval?
  • Qouth an A.C....and quite frankly, there's nothing that can provide suffering like a several hundred page poem about hell..

    Haven't used '98 or NT much, eh?
  • How hard would it be to make Linux do that? I'd think that User Mode Linux [sourceforge.net] would be a very good start.

    Shouldn't be too hard. The host OS needs the ability to intercept and annull system calls. There are some other things which would be nice to have, but probably can be worked around if they're not there.

    NT allegedly has the capabilities, 98 is iffy, and 95 is out. I've looked at FreeBSD (and one other, I think NetBSD) and they don't seem to have system call interception. I don't know about the other Unices.

    Jeff

  • I'm not sure that they were looking for it!
  • Besides, you can do incredible things with mere sh scripts in inferno, since everything is a file.

    had to respond to this, as i've recently finished writing the inferno shell. (unless that's anonymous coward chris, ya bugger, in which case i've just been trolled, sorry folks)

    where else can you make a distributed app in one line of shell script?
    file2chan /dev/shellctl {} {somecommand ${unquote ${rget data}}}
    that one line makes a file in the namespace - any write to that file runs somecommand with the arguments that have been written to the file. i.e. i can do:
    echo ${quote arg1 'arg 2'} > /dev/shellctl
    or even better:
    fn somecommand {
    echo ${quote $*} > /dev/shellctl
    }
    somecommand arg1 'arg 2'
    and it'll run
    somecommand arg1 'arg 2'
    in the original process. the properties of the inferno namespace mean that i can then export that across the network transparently, encrypted, etc. corba eat your heart out. :-)

  • This operating system is targeted for appliances and the such. That is why they are selling source code. Now I'll agree that it might take a little more time to obtain the proper documentation to develop under linux, its out there and its not as bad as we make it out to be. Not to mention the large developer base and the fact that if you open source your project others with similar needs will help to solve your problems. And commercial support is available and getting better all the time.

    Linux is not perfect nor the final answer for everything. However, there are other free thing out there that come with better documation. The open source BSDs are well documented, commercial support is available for them, and have 20 years of history.
  • The Dis VM performance is far superior to the JVM, because it uses a register model that is close to actual architectures. So the Dis bytecode compiler basically maps Dis bytecodes to machine instructions, doing a bit of virtual->actual register allocation along the way. Claimed performance is a third to half the speed of compiled C, and the bytecode translator is a few thousand lines of code. The JVM stack architecture is fine for a college term project, interpreter, but not global deployment -- it takes lots of optimization resources to transform a stack-based program to efficiently use registers. This should be done once in the compiler, not in the bytecode translator. Java JITs are massive behemoths because of this fundamental mistake. Also, Java garbage collection stinks, and Java lacks the channels of Limbo. The Java language also needs generics. Limbo has its own problems, and Lucent did a miserable job of marketing Inferno. But Pike, Ritchie, et al are good engineers -- they get the design right, and then refine the implementation.
  • I for one would rather be involved in the embedded Linux effort.

    If you knew anything about embedded programming, you wouldn't want Linux to be an embedded OS. You don't really want an embedded system with the "unlimited resources" attitude of UNIX. That's not to say Linux is bad, just that it is out of place for embedded systems work.
  • what's this "growing up" thing? oh, and about the motels, all new inchfan candidates have to turn a few while they're not being screened. Just remember, you might be the pimp around here, but I'M the pusher, and if you want the crack to stay under $3 (and don't be telling me it's just for the mods, Smokey) then you best know your place. Unless you don't value your kneecaps.
  • Sure, there are dozens of press releases about Linux or WinCE settop boxes or stereos, but precious few of them have ever made it past the vaporware stage (so far).

    Does the name TiVO ring a bell?

  • Judging from the prominent (aka "big-ass") quote on their website [lucent.com], it was inspired by Dante's opus of the same name. It also fits in nicely with the name of the related programming language: Limbo.
  • FreeBSD/NetBSD have system call interception. That's how their Linux/BSDi/etc "emulation" works.
  • The intent is not to penalise the individual to the contrary. Consider the prices in absolute terms and corporations pay three times that of an individual. I doubt anyone will begrudge the discount to academics or students as they are the grassroots of tomorrow.
  • FreeBSD/NetBSD have system call interception. That's how their Linux/BSDi/etc "emulation" works.

    Could you point me at the code in the kernel that implements it? Or anything on a FreeBSD system that uses it?

    I looked at the FreeBSD system call path and saw no sign of any kind of tracing or interception. Also, the ptrace headers contain nothing resembling PTRACE_SYSCALL, and strace doesn't exist on the system I looked at.

    Jeff

  • It's too bad Limbo is such a horrid language (Score:3)

    by Doubting Thomas ( 72381 ) on Wednesday June 21, 2000 @11:04AM (#986316)
    I looked at Inferno when it first came out, and it was very impressive in 1996, and it's still impressive today. Javasoft is attempting to target the same market with Jini, and meeting with equally glazed eyes, unfortunately.

    But what sent me running away screaming was the programming language you were expected to use. Here was a language that looked like it was a solid step backward from C! And I'm sure everyone from procedural to functional programmers and everything in between can agree that this is an undesirable first impression to make upon someone.

    -
  • You are sooooooo fucking lame!
  • Firstly, programmers transitioning to other design paradigmns is always fraught with trouble. It surprises me very little to hear you say that functional programmers didn't see the big deal with two OO languages. Now, if you'd said Smalltalk, Objective C or C++ programmers, we'd have a different discussion.

    Limbo is Just Another Procedural Language. Most people fighting over the future of programming either side with functional, OO, or something yet to be determined. You don't hear too many well thought-out debates by respected individuals calling for a return to our software roots. And even were it not a procedural language, it has a very unimpressive set of primitive types, and some grammar changes are a tease. You're likely to forget you're not programming in C-progeny syntax, and botch something mightily.

    -
  • It suprises me very little to hear you say that PROCEDURAL programmers didn't see the big deal with OO languages.

    -

  • other related info... (Score:4)

    by kootch ( 81702 ) on Wednesday June 21, 2000 @05:00AM (#986320) Homepage
    many of the original developers from the Inferno project are now working for a comany called <a href="http://www.savaje.com">savaJe tech</a> that is working on a product called jscream, a java kernel and os for information appliances.
  • I believe Microsoft holds the trademark for their own Infernal OS. This company's just looking to get themselves sued!

    Wait, Inferno?
  • Posted by 11223:

    It seems that this company is publishing two OS's from Bell Labs - and is trying to enter the alternative OS market. I've played with the inferno emulation environment under Linux, and it was interesting but horridly slow. I hope the standalone version corrects that. However, I do have a few questions: What is it good for? What programs are for it? How easily can I port programs from *NIX?
  • sorry, forgot to turn on html... savaJe [savaje.com]

  • if Inferno is in competition with Microsoft (being an operating system) does that mean That Bill Gates is God and Microsoft is heaven?

    Ol' Bill ain't evil, he's just misguided. We should buy him a Guide Pengiun.


    ==============================
    http://www.geek-ware.co.uk

  • This just screams application hosting. Lets have a hodown!

  • Too little for too much $$$ (Score:3)

    by jheinen ( 82399 ) on Wednesday June 21, 2000 @05:06AM (#986326) Homepage
    Charging $300 a pop will certainly drive developer acceptance. I'm rushing right out to get my copy.

    Wait. Linux is *free* you say?!?!? Never mind.

  • One thing I found interesting is that Inferno, as well as being a stand-alone OS, can also be run as an application under Windows NT, Windows 95, Unix (Irix, Solaris, FreeBSD, Linux, AIX, HP/UX) and Plan 9.

    How hard would it be to make Linux do that? I'd think that User Mode Linux [sourceforge.net] would be a very good start.
    --
  • i had to work on a pre-orbix corba compliant orb that came out of lucent/bell labs... it was pretty cool, but they really hyped it and it got squashed. it was designed for smart people with no care for the java-programmer-types... who knows, maybe they'll have more luck with inferno.
  • Given that it's called 'Inferno', not 'Infernal'. If they had called it 'Godfucker' then yeah, there might have been a response...
  • I didn't know they spoke Swedish in Finland.

  • Notice who pays the full price (Score:3)

    by stevens ( 84346 ) on Wednesday June 21, 2000 @05:45AM (#986331) Homepage
    This is something that I never really noticed until now. Note how the price structure works:
    • Students -- big discount
    • Academics -- big discount
    • Commercial, volume purchases -- discount
    • Single Hobbyist/Developer -- full price

    Not that I'm complaining--they're entitled to go after any market they like. It's just plain from the price structure that they've no interest in the grassroots individual developer market at all.

    It's probably not a bad choice, if they want to keep it for use only with "network devices" rather than PCs. But still, as PalmOS has shown, having grassroots developer support for non-PC computing devices is certainly an asset.

    Steve

  • be-fan wrote: Also, when stuff like DNS lookups are done through files, isn't it getting a little silly? Isn't it simpler to map closer to the way the software is actually working? Especially in the cases of stuff like DNS lookups which don't totally make sense being treated as a file. Also, doesn't going through the FS create some overhead?

    I don't think it's silly to use files for DNS lookups, especially considering that it means I don't have to deal with those ugly gethostbyname()-related structs anymore when I'm programming. As far as this being inefficient "because it's going through the filesystem", this is not true. You are thinking of the old concept of filesystem, which refers to things on a big magnetic disk. The Inferno "filesystem" files are not necessarily files at all in the traditional sense. Many of them (including the DNS-related files) do not reside on the hard drive at all. They reside in memory, and they run code when people open/read/write them. There is no inherent inefficiency in this.

  • "New Ideas" in Inferno (Score:5)

    by nestler ( 201193 ) on Wednesday June 21, 2000 @05:46AM (#986333)
    Just to inform people that may not know too much about Inferno, I thought I'd post a few unique things about it (and some ideas that the developers wanted to focus on). I've done work for Lucent related to it, so I know a few useful things about it.
    1. Runs on a Virtual Machine

    2. Inferno only runs directly on one architecture: the Dis virtual machine. This isolates in a very clean way the platform-specific parts that need to be changed to get Inferno to run on various architectures: just rewrite the Dis machine wherever you want Inferno to run.
    3. Written in Limbo

    4. Most of Inferno was written in a new language called Limbo. It's authors seem to like this language, although I've seen a good bit of criticism of it from others ("the infernal language"). I don't know much at all about Limbo first hand.
    5. Namespaces

    6. This concept is borrowed from Plan 9. The concept is that different processes have different views of the system called namespaces. Each namespace is essentially a hierarchical file system that presents available resources to the process. If a process does not have enough privilege to use something, it won't even see it. What are these resources? This gets into the next point...
    7. Files, Files, Files

    8. This concept is borrowed from Unix but is taken to new extremes. All resources in the namespace are presented as files. The idea is to unify the interfaces to a variety of things by having an open/close/read/write way to use a variety of resources. Unix presented devices this way (/dev). Inferno goes a step further by presenting other machines, network cards, and a variety of other resources as files. For example, DNS lookups and socket programming can be done simply by reading and writing files. This is not so under Unix.
    9. Transparency of Networked Machines (or toasters)

    10. By using this hierarchical filesystem view of everything, Inferno can essentially hide that parts of this file system are remote (like NFS mounts). The hope is that programmers can write programs that read like simple shell scripts (open, read, etc.) to manipulate local and remote data and machines.
    11. Styx Protocol

    12. Styx is the protocol that is spoken over the network in order to present this filesystem abstraction remotely. Note that these 'files' are not traditional files: they can have arbitrary semantics (they can make things happen on the server when read/written; the possibilities are endless). A Styx server exports some filesystem to a Styx client. Note that the server decides what the semantics are for this filesystem (writing file A causes some configuration to be rewritten, reading file B reads off the current configuration, etc.) The client can mount this filesystem so that it appears in the namespaces of processes on the client machine.

    I think Inferno has a lot of potential, even if only for simple management of networks. Today, management of heterogeneous network can be pretty complicated (managing routers with LDAP, SNMP, etc.). If routers implemented Styx servers to expose their configuration options as a filesystem, then some Inferno machine could mount all of the routers in a directory and run a simple script to configure them all. This would be much simpler than what goes on today.

  • Re:New OS's from this company... (Score:5)

    by rpeppe ( 198035 ) on Wednesday June 21, 2000 @08:10AM (#986334)
    well i don't think it's still "horridly slow"; i use it a lot of the time and it is slower than C, but not bad at all.

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

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

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

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

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

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

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

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

    hope this helps!

  • Yes. They were developed by more or less the same set of developers at Bell Labs. Inferno came along after Plan 9 and includes the virtual machine and Limbo programming language which are not present in Plan 9. There is a lot of similarity at the source code level in the kernel and anyone familiar with the Plan 9 kernel would quickly get to grips with Inferno kernel development. They share the same C cross-compiler suite for a variety of machine architectures. One big difference, though, is that Inferno can run as a hosted operating system on Plan 9, Linux, Free/BSD, Windows, Solaris, and others as well as running natively in its own right.
  • > Anyone know if Plan9 got the FSF and OpenSorce org's stamp of approval? They did not get FSF's approval. See the posting with the message-id 200006130543.BAA25935@cse.psu.edu in comp.os.plan9 on deja.com.
  • Shut your hole, pimp. What, do I look like some kinda vending machine to you? You think you just put a quarter in my mouth and I shit out crack rocks for you? Is that it? HUH? I'm talking to YOU, dickhead. Who gave you the money to start up in this town? You think it just fell out of the motherfucking SKY? You keep up this uppity shit, and your tab is gone, and you can fucking forget about that interest rate decrease I promised you.

    You want the rock you're gonna have to EARN it. Now, I know this guy, owes me a lot of money. You want rock, you go "remind" him who his friends are, 'cause it gets REAL lonely at the bottom of the river, and we all want to be friends here, right? That's what I thought. Nice and easy.

    Jimmy, escort him out.
  • Come on, this is an awesome OS!!

    Garbage-collection and run-time type safety are both very nice. From the sound of things, you can even have a direct pointer to something in someone else's address space. Plus, the security model sounds much better than Unix's.

    In fact, it has everything on my wish list for a good OS except for automatic checkpointing the way EROS has. It's just too bad the thing costs $150....

  • Doubting Thomas wrote:Here was a language that looked like it was a solid step backward from C!

    You obviously didn't try it!

    It took me a couple of hours to get going with Limbo and it was well worth it.

    The language has threads and inter-thread communication built in at the grass-roots. These are no after-thought strap-ons or additional libraries with clunky interfaces. They are part of the language in a very elegant and powerful form.

    The language also features a very effective garbage collector, really useful string and array manipulation primitives and lists. (Never underestimate the usefulness of builtin lists in a language.) All absolutely fabulous.

    I find Limbo programs smaller than the equivalent C, much more readable and predictable. By predictable I mean that a quick scan of the code can reveal what it is doing - there are none of the GOTCHAs you get in other languages e.g C++ or Java where you cannot be sure what a particular statement or expression means without recourse to a Class browser (or prayer).

    The language is easy to learn, clean, type safe, innovative,elegant and FUN! What are you afraid of?

  • It has been very popular with some Far Eastern companies as the native operating system for their webphones. Probably partly due to the slick way that Limbo and Tk work together to provide the graphics in a very small footprint. I think too that the fact that you can run native inferno in a device like a phone and run Inferno emulated on, say Windows, and then mount the namespace from the phone into your Windows Inferno make application development and debugging much easier. Your phone applications can also run in an identical environment under Windows, Linux, Plan 9 for testing.

    I use the Acme development environment (which both Inferno and Plan 9 have) as my editor of choice on Linux, Windows and Plan 9.

  • I couldn't disagree more.
    I have worked with a lot of programmers whose background is rooted in C. They have all experienced the C++ and Java euphoria and come out of it wondering what all the excitement was about - me included.

    Limbo was a breath of fresh air. It retains the salient and useful parts of the C language. It is surprising how easy it is to port C applications to Limbo. Take, as an example, the code from the `cat' command to copy a file to standard output:

    cat(file: string)
    {
    n: int;
    fd: ref FD;
    buf := array[8192] of byte;

    if(file == "-")
    fd = fildes(0);
    else {
    fd = open(file, OREAD);
    if(fd == nil) {
    fprint(fildes(2), "cat: cannot open %s: %r\n", file);
    raise("fail: bad open");
    }
    }
    for(;;) {
    n = read(fd, buf, len buf);
    if(n <= 0)
    break;
    if(write(stdout, buf, n) < n) {
    fprint(fildes(2), "cat: write error: %r\n");
    raise("fail:write error");
    }
    }
    if(n < 0) {
    fprint(fildes(2), "cat: read error: %r\n");
    raise("fail:read error");
    }
    }

    It isn't going to take a C programmer long to work out what is going on there.
    They might notice that the file isn't closed - but thats because its closed automatically when `fd' goes out of scope (when the function returns).
    They might notice that the array of bytes pointed to by `buf' is never freed - but that happens automatically the instant that `buf' goes out of scope. I can still do anything to `buf' that I might want to do to it in a C program: copy it, slice it, change it, even pass it down a channel to another thread but it will be freed instantly the minute the last reference to it goes away. I find that little things like this combined with the clean, fresh, minimalist nature of the language and operating system make it a pleasure to work in.
    Oh, and strings are a basic type too - its C without the headaches!

    The source for all the system commands is included with Inferno - in fact its freely distributable.

    The limbo reference manual (written by Dennis Ritchie) is also very precise in its definition of the language.
  • The above post is an impostor.
  • Broadcom [broadcom.co.kr] and Umec [umec-web.com] both use Inferno natively as the operating system for their newest webphones.
  • I think treating a device as anything other than a region of memory is pretty silly, because that's exactly what it is. Maybe its just from doing so much DirectX work, but I find stuff that maps to the hardware (like Direct3D) much easier to program for than stuff that gives me abstractions that the author thought was appropriate (OpenGL). Say you're writing a graphics driver. You know that you have to write certain values to certain locations from a certain offset. Say writing 5 to BASE+0x5 results in a video mode change. Under the whole file paradigm, you have to convert this to the ioctl format or a stream based thing, wheras in the memory region way, you could just set 0x5 above the pointer to 5. Also, devices don't exactly have depth. Probaly the deepest tree you'll have in the case of an Inferno device would be that of something like a Voodoo2, where you'd have a root dir, and two files representing texture memory and frame buffer. Lastly, having this overhead doesn't sit well with me. Not only does inferno run everything in a VM (kinda like a Java OS? Last time I checked, Java was barely fast enough for those porn feeds, much less and OS!) but it makes these abstractions that result in a further performance hit. Performance penalties should be optional. Why not have a base API designed for performance, and then wrap these abstractions around that?

  • Not a Good Idea(tm) (Score:1)

    by Anonymous Coward
    Are you insane? What about intellectual property rights? If source is released for Inferno, then source for Pergatorio and Paradisio must follow suit!!! But sadly, most people never get beyond the first book anyway. All anyone wants to see is suffering, and quite frankly, there's nothing that can provide suffering like a several hundred page poem about hell.

    What exactly would an open source hell provide anyway? Could we tweak our sufferings such that they maximize redemption value? The most molten iron poured beneath our eyelids that we can sustain for hopes of salvation? Actually, that's not too terrible of an idea. After all, we should be able to tweak demon rotation routines, because being tortured by the same demon for too long gets predictable, and I can't think of a single religion that would prefer their hell be predictable. After all, what you can predict, you can learn to deal with. But then again, if you can deal with what you're given, odds are you're not going to end up in hell anyway.

    Take my grandmother for example. Six years ago she died, having driven her Oldsmobile straight into a bus full of nuns. No faster way to hell than that. Which begs the question of why do senior citizens always buy Oldsmobiles anyway? Is it the name? I mean, I'd personally prefer to NOT be reminded everytime I leave the house that I'm past my usefulness. Let alone the jarring discontinuity of buying a new Olds. No wonder she killed herself.

    Ummm . . . what was I talking about?

  • How useful is this? (Score:5)

    by Jon Erikson ( 198204 ) on Wednesday June 21, 2000 @05:09AM (#986347)

    From this introduction [vitanuova.com] at the web site:

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

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

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


    ---
    Jon E. Erikson
  • Following the Open Sourcing of Plan9, it was only a matter of time for this to happen. I have tried out the Inferno OS in an emulated mode before (as they provided a developer's kit a few years ago), and after studying its functionality as compared to Plan9, they seemed similar as to what they achieve. Did anyone else note any real applicitive use? This isn't to say that Inferno is not a good OS, I just couldn't find any use for me to use it.
  • Posted by 11223:

    You troll. Linus is ethnic Swedish.
  • Shrinkwrap products are expensive even if your time has value.
  • For example, DNS lookups and socket programming can be done simply by reading and writing files. the last time i looked at my middleware it was using file descriptors for socket connections. i wonder if their sockets only support "r" "r+" "w+".. options
  • Any times someone talk about interpreted language or about virtual machines, I have a reflex (due to a poor Java experience) what about performances ?

    Does anyone here has used, the Inferno system?
    What is the performance?

    And since it is a "new" product, is-it usable? Is there many bug left ?

    PS: I'm not trying to start a flamewar, just looking about some hands-on experiments.
  • And a bit more from the docs :

    * Portability across processors: it currently runs on Intel, Sparc, MIPS, ARM, HP-PA, and PowerPC architectures and is readily portable to others.

    (means they've got the virtual machine for those)

    * Portability across environments: it runs as a stand-alone operating system on small terminals, and also as a user application under Windows NT, Windows 95, Unix (Irix, Solaris, FreeBSD, Linux, AIX, HP/UX) and Plan 9. In all of these environments, Inferno applications see an identical interface.

    * Distributed design: the identical environment is established at the user's terminal and at the server, and each may import the resources (for example, the attached I/O devices or networks) of the other. Aided by the communications facilities of the run-time system, applications may be split easily (and even dynamically) between client and server.

    * Minimal hardware requirements: it runs useful applications stand-alone on machines with as little as 1 MB of memory, and does not require memory-mapping hardware.

    (Not too bad for a full fill+networking system)

    * Portable applications: Inferno applications are written in the type-safe language Limbo, whose binary representation is identical over all platforms.

    * Dynamic adaptability: applications may, depending on the hardware or other resources available, load different program modules to perform a specific function. For example, a video player application might use any of several different decoder modules.

    Note that the namespace and a homogeneous model of the system are ideas that have been suggested as desirable for some time.

  • Last time I looked at my middleware it was using file descriptors for socket connections
    Of course it was. But to get those descriptors, it had to call things like socket(), bind(), etc. Inferno attempts to get rid of some of that non-file baggage by letting you just open and read some files rather than having to use network-specific system calls.

    I wonder if their sockets only support "r" "r+" "w+" options
    To my knowledge, their implementation supports any TCP socket options.

  • No, actually I was not thinking hard disk files. I assumed that they'd be virtual in-memory files, kind of like shared memory is under Linux. In Linux, when you call gethostbyname(), it directly maps to how the software is designed. In Inferno, the call has to be relayed through the file system (context switch to kernel) which has to relay it to the appropriate code. Even if the file never hits the harddisk (now that would be silly!) it still incurs the overhead of having to have the filesystem code deal with the write and call the appropriate code.
  • >If you knew anything about embedded programming, you wouldn't want
    >Linux to be an embedded OS. You don't really want an embedded system
    >with the "unlimited resources" attitude of UNIX. That's not to say
    >Linux is bad, just that it is out of place for embedded systems work.

    Yeah. 9 out of 10 Microsoft Astroturfer surveyed knows that Windows CE should be used in embedded systems instead...
  • It depends on the nature of the device and the level of the interface you want to present to the user. I agree that when working directly with the hardware at a low level it is often necessary to access them through the memory space, because that after all is where they are mapped. Inferno device drivers are written in C and access the hardware in such a fashion. What is nice is the flexibility that Inferno gives to device driver writers to present their device to the outside world.

    If I'm using the serial port from an application it is much more attractive to be able to open a file and write data to it, or open a file and read from it - blocking until some data arrives than to mess around with polling memory locations or waiting for an interrupt. If I want to control the device (baud rate, handshaking etc) instead of ioctl() or similar specific system calls I write a well defined message to its control file. See [vitanuova.com] the serial device man page. In fact, I could probably consider writing my simple application as a shell [vitanuova.com] script.

    It has other advantages too: the same technique works on all platforms - no need to change my application; no need to worry about byte ordering issues; I can use file system permissions to control access to my device.

    But what if I haven't got a serial port? Not a problem either, just import one across the network from a machine that does, bind it into /dev as /dev/eia0, /dev/eia0ctl etc and run the same application. Not much use for ioctls and memory accesses here!

    Presenting this information in the file namespace has many advantages. If an application can get a service such as DNS lookup by opening, writing and reading from a file then if a particular machine doesn't have such a service it can simply bind the file into its namespace from a machine which does and then the service is available.

    A really great example of this is remote debugging. In Inferno everything needed to control a process for debugging is encapsulated in the '#p' prog [vitanuova.com] device. It presents a subdirectory for each running process with control files in each directory. The ps [vitanuova.com] command and the debugger [vitanuova.com] use this device which is conventionally bound into /prog. To debug a process running on, say, my screenphone which serves Styx on a serial port I just run
    mount /dev/eia0 /n/phone
    bind /n/phone/prog /prog
    and now `ps' will show me all the processes running on the phone and the debugger will let me debug them.

    It boils down to letting the device driver writer make sensible decisions about which services are made visible to its users and how they are presented.

  • Don't think of it as a file in the filesystem. Best to think of it as a name in the namespace to which a piece of code is attached which gets called when you write to it or read from it. There doesn't have to be any kind of storage associated with the file. Don't see it as an inherent overhead - the system was designed to work efficiently that way.

    A filesystem (in the traditional sense) is just the contents of another device mounted in the namespace - there's nothing special about it. Many Inferno systems either import their storage from another system or use flash or just don't need permanent storage.

  • Okay, I'm thinking of it as code associated with a name space. However, when you have a function, you actually have a pointer to the memory where that code is, and a function call is simply a jump to those instructions. Under this method, however, the filesystem part of the OS has to step in to decode the reads and writes to that virtual file and turn them into requests for the DNS address. For example,
    In Linux: You call gethostbyname(). It calls a system trap which jumps to that code inside the kernel (or netoworking library or whatever.) That function then procedes to get the host name and return it.
    In Inferno: You write something to a virtual file. The Inferno filesystem intercepts the write. It takes a look at what command you are trying to do, takes a look at the stuff you feed it (parameters) and then passes that info onto the networking code in the kernel via a function call. This step of having the kernel intercept the call and decode it is what introduces the overhead. Also, since it is a virtual file, memory writes and reads have to be done than during a funciton call. All this is what introduces the overhead.
  • Indeed, there is a proliferation of network operating environments at the moment. To claim that it's a pretty saturated market is accurate as well, but the fact that few people are catching on to is that Inferno is in no way new. I read about it and downloaded the environment to toy with around two years ago. It's made an appearance in several phones with an interface, among other places. This isn't an up-and-coming product, but rather one that is already in place.
  • In Linux: You call gethostbyname(). It calls a system trap which jumps to that code inside the kernel (or netoworking library or whatever.) That function then procedes to get the host name and return it.

    You're oversimplifying things on the Linux end, methinks. gethostbyname() is a simple library call, but if you have a system-wide cache of host info (such as is offered by nscd in Solaris), it still has to do interprocess communication (which implies context switching) with nscd to check whether the host is in the cache before it does the socket stuff to talk to the domain name server.

    I would expect that the real bottleneck in doing DNS lookups is the network traffic, which is exactly the same in the Inferno and Linux implementations.

  • > Could you point me at the code in the kernel that > implements it? Look at the ktrace stuff (/sys/kern/kern_ktrace.c, etc). User-level utilities are truss(1) and ktrace(1).
  • No problem with your posting more than I do, but it's time you took personal responsibility for what you write. Right now, you're putting on a mask of my face and then giving the thin self-justification that it's not perfect and occassionally you admit the deception. From here, it seems far more cowardly than honestly labeling yourself as an AC.

    The things you write generally seem rational but they aren't what I would write. Your posting on the Academy tonight was especially far off.

    Get your own name, already, cowboy.

    Bruce

  • Lucent's PathStar Access Server also uses Inferno. This is a serious piece of iron which has to provide high availability while it processes 1000's of voice and data connections.
  • Lucent is not the only one which failed to get commercial advantage from a project like this one. Lots of companies all over the world have tons of reasearch material which never make out to the open even if it failed to be of any good to them. Its nice to see that Lucent has taken a lead in this effort.

  • How many other OS choices do we need?! Didn't QNX just attempt a similar sort of pricing structure change in order to attract new developers?

    It's true, choice is a Good Thing(tm) when it comes to OSes, but I think that these companies are really starting to get jealous of the developer interest and support that the *Nixes enjoy and want a piece of the action.

    I for one would rather be involved in the embedded Linux effort.

  • Re:How useful is this? (Score:1)

    by Anonymous Coward
    The difference is that Inferno/Limbo is a very well-established network operating system which is actually used in many devices today. Sure, there are dozens of press releases about Linux or WinCE settop boxes or stereos, but precious few of them have ever made it past the vaporware stage (so far).
  • It's a typo. And the stupid thing is, I previewed the message twice. :)

Slashdot Top Deals

Almost anything derogatory you could say about today's software design would be accurate. -- K.E. Iverson

Close