Inferno 4 Available for Download 287
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."
License (Score:4, Interesting)
Any ideas why they didint use GPL/BSD or any other standard license. Or is there some subtle(or obvious) licensing issue
New p2p (Score:4, Interesting)
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.
Alternative to VMWare? (Score:5, Interesting)
Re:License (Score:5, Interesting)
Re:Inferno? (Score:5, Interesting)
-- Anon Coward
Re:Inferno? (Score:4, Interesting)
Trust me, it is all very interesting stuff. Just don't let it slip that you use the heathen UNIX, especially on #plan9 on FreeNode.
Re:we don't want you to burn in hell (Score:2, Interesting)
Discreet's Inferno (Score:4, Interesting)
http://www.discreet.com/inferno/
Re:Discreet's Inferno (Score:3, Interesting)
It was distributed-only, where the Disk-subsystem ran as seperate (networked) nodes from the CPU-subsystem(s), which were seperate from the Terminal(s), etc, etc. It seemed an awful lot like a mainframe-style system using commodity parts, but you had to invest in at least 3 nodes in this way, if not more. This could have been expensive for what was mostly a research or hobby system at the time -- at least if you were going to get anything usable, speed-wise. (Others more intimate with the details may be able to correct/corroborate this)
Soon after, they released Inferno, which was basically the same idea, but the distributed-ness of the components was up to you.
I'd be surprised if much 3D software that old would still be considered anything like high-end.
Re:Inferno? (Score:3, Interesting)
Compilers do not need them if properly designed, as with the many modern languages I cited.
But C and C++ require this. Ever notice how in C and C++, you can't refer to an undeclared type, even if it is declared later in the file? You have to provide at least a forward definition. ("class Bob;") Likewise functions, data members, etc. This is most annoying in C++, with inline functions. You have to pay attention to ordering. In other languages, you do not.
There is actually a very good (programmer-centric) reason for doing having separate interface/implementation: If you want to remain completely (binary or source) interface-compatible you just lock down the interface file.
Okay...that's great for those 1% of people who want the interface file to remain absolutely static. And I mean absolutely static. No new methods. No changes to the comments. No nothing. (In fact, I doubt there are even 1% of people who want this, once they give it some thought.)
For the remaining 99% of us, this is unwanted Bondage and Discipline.
Maybe the people who want the interface to remain static can do so in a more intelligent way. Like comparing javap output on check-in and ensuring the old methods are there, with the same signatures as before. If they're this strict, that shouldn't be a problem - they already have checkin tests to ensure all unit tests pass. Adding another condition shouldn't be a problem.
Re:New p2p (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".
Re:Inferno? (Score:4, Interesting)
substantial software under Inferno. It has
some nice features, and is by far the
cleanest environment for multithreading
that I've ever seen.
At the time (c. 2000), it had a few misfeatures,
such as no way to signal that you've closed
a channel between two threads, but hopefully
that's been fixed. Limbo is a nice, clean
language. It isn't object oriented: think of
it as the ideal C, rather than python, java or
C++. However, interestingly enough,
you can do large-scale OO things reasonably
nicely in two ways:
First, for objects that are more like lightweight
daemons, you can have a thread that simulates
a file (or file system, even). The rest of
the program can then read and write to that
special file to interact.
One can be OO by implementing a whole directory,
where each file corresponds to a OO message
(member function).
Second, for even ligher weight stuff,
you can easily (trivially easily, compared
to most languages) spawn a thread that
talks via the rendevous mechanism,
and treat that as a little light-weight
server to which you can pass
arbitrary data structures.
There's no support for fine-grained OO,
which was, I think, a reaction to some
of the OO-idiots out there that
insist on making objects out of things
that aren't naturally separable.
The failing is that there are not
extensive libraries, and there is certainly
not much in the line of applications that
one can download.
It is very elegant in many respects.
If you need to write multi-threaded things,
and can live without much in the way of
libraries or applications, you should think
about it.
Re:New p2p (Score:2, Interesting)
As I am currently developing a language which will, among other things, use bytecode, I'd like for this myth to die sometime soon.
Re:Distributed Operating System? (Score:4, Interesting)
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
* I've always wondered why network interfaces (at least under Linux, not sure if this is the same under other OSes) are not files like almost everything else in the UNIX world.
* *IX lacks a good, common secure, easy to set up a distributed filesystem. It would be really nice if AFS was a piece of cake to set up, supported large files out of box, and was present on all *IX systems. If it could serve the role that SMB/CIFS does in the Windows world (Joe User can easily make a share), but with better performance and security, and the ability to easily distribute, we'd definitely be going somewhere.
* *IX lacks a good, common, secure, easy to set up messaging client. Talk was absolutely wonderful back in the day, but firewalls and other nastiness have made it very uncommon. This is not just for desktop systems -- messaging can be a CLI application for troubleshooting and the like. I'd personally hope that such a system be able to do end-to-end encryption.
Re:Tryst with Plan9 (Score:5, Interesting)
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).
Re:yay! (Score:4, Interesting)
Re:Good introduction to Limbo (Score:5, Interesting)
there are options for getting existing C code into the Inferno world. at a high level, 3.
- 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.
- 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.
- 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.
You can save me hours of boring, repetitive... (Score:3, 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 [netbsd.org]. The FreeBSD logo gives the initial impression that it is the OS of choice for computers gotten from a dumpster.
I often need to go to people who don't have much technical knowledge and explain to them why I have chosen a software package. You can save me hours! You can save me hours of boring, repetitive explanation that the software is great, it is just the communication skills that are lacking.
Also, good managers know that communication is a large part of the total cost of implementation of software. They are correct to be scared when they see evidence of poor communication.
Re:License (Score:3, Interesting)
as a trivia point, with the exception of legacy ones like
on to your question proper: i, of course, am neither a lawyer nor british, but from what i was told GB law doesn't allow one to disclaim all warranty in the way the GPL does. of course, none of that's ever been tested in court, and i don't know what GB law says about survivability of agreements in the case of a particular clause being invalid.
Re:yay! (Score:3, Interesting)
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.
Re:OSS authors: Think carefully about communicatio (Score:3, Interesting)
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.)
Re:You can save me hours of boring, repetitive... (Score:3, Interesting)
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).