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."
inferno? (Score:5, Funny)
Re:inferno? (Score:5, Funny)
Yes and no. (Score:2)
Re:inferno? (Score:5, Funny)
Re:inferno? (Score:2)
Managing daemon apps is apparently very easy, but sending stuf to /dev/null can be quite spectacular ;-)
Or so they tell me, I am stuck with Windows, the orginal devils OS.
Just what we need (Score:5, Funny)
Re:Just what we need (Score:5, Funny)
Inferno? (Score:4, Funny)
Re:Inferno? (Score:5, 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").
-fren
Re:Inferno? (Score:5, Interesting)
-- Anon Coward
Re:Inferno? (Score:5, Insightful)
No, I think mistake that Bell Labs made was to charge everybody (including Joe User, the hobbyist) for the OS. Nobody could download it for free and try it out. You had to pay for it.
If I'm a hobbyist and just want to try something out, I don't feel like shelling out $100 for something that seems quite esoteric.
Basically, BL's desire to milk it completely destroyed Plan9's chances. Couple that with Linux's surge, and Plan9 was doomed.
Later, much later, they released it for free, but by then it was too little, too late.
Re:Inferno? (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:Inferno? (Score:2, Informative)
Re:Inferno? (Score:5, Informative)
I don't see the resemblance to Python. Limbo has:
I don't see any redeeming qualities.
Re:Inferno? (Score:5, Insightful)
Wrong. Compilers do not need separate interface definitions. They might just as well use the source files and find all the definitions there.
There is actually a very good (programmer-centric) reason for doing having separate interface/implementation: If you want to remain completely (binary or source) interface-compatible you just lock down the interface file. If the language is strongly typed and pedantic about matching type/function/value definitions exactly it will complain if you accidentally change the declaration of a function (this is particularly easy to do accidentally in type-inferenced languages like ML). Thus, you can ensure interface compatibility in this very simple way.
(Of course, in C/C++ this is not nearly that useful because compilers usually don't actually check any of this. But it works very well).
Re:Inferno? (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++, wi
Re:Inferno? (Score:5, Insightful)
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: It doesn't compile, but it DOES work if you use: (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.
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
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: 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.
You call that intelligent? Instead of just having the compiler do it? It already knows all about type aliases, what types are compatible,
etc. etc. (i.e. all the stuff that makes checking such things using a postprocessor extremely error-prone).
Re:Inferno? (Score:5, Informative)
Of particular note is that Dennis Ritchie has written exactly two language reference manuals in his life: C and Limbo. that says a lot to me, anyway.
name dropping aside, Limbo really is a huge win for user-mode programming. the channel stuff isn't bizarre at all - it's a very elegant way to handle inter-process communication. Python's got nothing on Limbo for this.
Re:Inferno? (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:Inferno? (Score:3, Insightful)
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 exist
informative (Score:4, Funny)
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
Re:License (Score:5, Interesting)
Re:License (Score:5, Informative)
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 [mirror5.com] it a "free software license incompatible with the GPL". From the GNU site:
Inferno's license seems to be the same as the new plan 9 one. (But I haven't looked in depth).
Re:License (Score:2, Insightful)
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 incompatibl
Re:License (Score:2, Insightful)
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 rele
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
Shall Jesux rise again? (Score:5, Funny)
INSERT WITTY BSD DAEMON JOKE HERE
Re:Shall Jesux rise again? (Score:3, Informative)
Yeah I tried it (Score:4, Funny)
Re:Yeah I tried it (Score:3, Funny)
Re:Yeah I tried it (Score:5, Funny)
yay! (Score:5, Funny)
Re:yay! (Score:4, Interesting)
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 - t
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.
Re:New p2p (Score:5, Insightful)
The problem with Java is that its GUI toolkit is slow.
In any case, with a file sharing app, CPU efficiency is certainly not an issue. You should never worry abot CPU efficiency if you don't need to, as you will only be making things harder on yourself.
And, finally, writing portable C/C++ code is really not that hard if you know what you are doing. Certainly you'd be better off with that than you would be asking all of your users to install an extra OS over their current one just to run your program. Really, the most important factor in making file sharing successful is to get lots and lots of users, and most of those users are going to be people who have absolutely no idea what an operating system even is.
Re:New p2p (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. How
Re:New p2p (Score:3)
> 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.
Why the last link? (Score:2, Insightful)
we don't want you to burn in hell (Score:2)
I did not submit the article but I believe that the last link was included for the sake of non-believers.
On a related note, what do you think of the sounds supposidly recorded from hell [av1611.org] [RealAudio] on that webpage? It sounds kind of electronic to me but maybe it really is from hell?
Re:we don't want you to burn in hell (Score:2)
Re:we don't want you to burn in hell (Score:2, Interesting)
Off topic, and scary. (Score:2)
The editors reserve the right to be off topic.
Woooo! It's scary:
YOU will see HELL. .
YOU will smell HELL. .
YOU will breathe HELL. .
YOU will hear HELL. .
YOU will feel HELL. .
YOU WILL BE HELL. . .
Re:Why the last link? (Score:2)
Comment removed (Score:3, Funny)
Re:Thanks for the nightmares! (Score:3, Funny)
Re:Thanks for the nightmares! (Score:3, Offtopic)
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
Hell comes in many flavors (Score:5, Funny)
I am not sure which part of hell the Tk UI toolkit represents, but I feel their pain.
Re:Hell comes in many flavors (Score:3, Funny)
hmm.
prooooogramming awaaaay
full of open source
in the language C
myyyyy mallocs are freeeeee
Re:Hell comes in many flavors (Score:3, Informative)
Good introduction to Limbo (Score:5, Informative)
I've briefly looked into trying out Inferno, but bear in mind it's not designed as a desktop system. Instead, the market it seems to be used in is the embedded market - so it'd be interesting to see how easy you can write server apps for application boxes with it.
However, it initially appears that Limbo is the only way to program for Inferno (prove me wrong please), which would be an obvious impediment to developer take-up.
Re:Good introduction to Limbo (Score:5, Informative)
"Features
Compact
Runs on devices with as little as 1MB of RAM
Complete Development Environment
Including Acme IDE, compilers, shell, UNIX like commands & graphical debugger
Limbo
An advanced modular, safe, concurrent programming language with C like syntax.
Library Modules
Limbo modules for networking, graphics (including GUI toolkit), security and more...
JIT Compilation
Improves application performance by compiling object code on the fly (Just In Time).
Namespaces
Powerful resource representation using a single communication protocol. Import and export resources completely transparently.
Full Source Code
Full source code for the whole system and applications, subject to licence terms
And more...
# Online manual pages
# Full unicode support
# Dynamic modules
# Advanced GUI toolkit
# Javascript 1.1 web browser
# C cross compiler suite
# Remote Debugging
# Games, Demos & Utilities"
Most relevant on the list is the C cross compiler suite. Theres at least one language other than Limbo you can code in (although it seems limbo is designed by many of the guys who wrote C and other minor items of note such as Unix).
If there is one language any developer you'd really want on the playing field knows, it's C.
Re:Good introduction to Limbo (Score:2, Informative)
Still, I think the compiler might be one of the most valuable parts of this distribution. It was originally written by Ken Thompson; it is fast; its code is small and readable.
If enough people notice, that could be a worty competition to GCC.
Re:Good introduction to Limbo (Score:5, Interesting)
there are options for getting existing C code into the Inferno world. at a high level, 3.
and yes, it has been an impediment to developer take-up, which is a real shame. Limbo is a simply beautiful language.
was that really necessary? (Score:2)
OSS authors: Think carefully about communication. (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 [sourceforge.net]".
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? [freebsd.org]
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.
Re:OSS authors: Think carefully about communicatio (Score:5, Funny)
OSS authors:Think carefully about [making money] (Score:5, Insightful)
The cURL license seems okay now: (Score:3, Informative)
The cURL license seems okay now: cURL license [curl.haxx.se]. I suppose it wouldn't be on Sourceforge [sourceforge.net] if it weren't okay.
Don't confuse [curl.haxx.se] cURL with Curl, from the Curl Corporation [curl.com].
Re:OSS authors: Think carefully about communicatio (Score:5, Insightful)
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.
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 s
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 (poli
Re:OSS authors: Think carefully about communicatio (Score:5, Insightful)
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,
Re:OSS authors: Think carefully about communicatio (Score:4, Funny)
FreeBSD is not alone in this, as can be seen from why Mac is bad [jesussave.us] ;-)
Re:OSS authors: Think carefully about communicatio (Score:3, Funny)
Well, I've seen better names than ProjectTraq Intranet System Services aka "PISS" [freshmeat.net] anyway..
Re:OSS authors: Think carefully about communicatio (Score:2)
The number one rule of marketing is that there is no such thing as bad press. Every time I see an absolutely awful commercial on TV, I'll talk about it with my friends, and we'll all agree that the commercial was terrible.
Except it isn't - it's brilliant.
We're all sitting around talking about a commercial we would have otherwise forgotten.
The same principle applies here - if you get a clever or mem
Looks right. (Score:3, Funny)
Yup. All related to hell.
Re:Looks right. (Score:2)
Alternative to VMWare? (Score:5, Interesting)
Inferno on Lucent BRICK Firewal (Score:4, Informative)
All jokes aside... (Score:5, Insightful)
A multi-platform OS, it can run standalone, as a virtual machine on every major OS (including every linux distro) and give full blown access to the system? Plus it can run in a sort of transparent mode so you can port your app to it and have your app appear to be a native app?
From the description it sounds like it's multi-threaded and designed with distributed systems (read cluster) in mind.
Plus it already has a language designed by the fathers of C and C cross compiler (wonder how well it works, also being designed by the fathers of C).
So in one sweep we have a solution suitable (sounds like it carries 1mb ram overhead) for most applications. Anything written for it magically runs on every major platform, it's highly scriptable and carries most of the magic of Unix packed with it wherever it's run from.
If it's significantly faster than Java I'd say we have a solution to the multi-distro problem as far as apps go.
Re:All jokes aside... (Score:5, Informative)
operating system that lends itself to clustering
applications, and Vita Nuova has a few big clients
looking at exactly this.
Plus the Vita Nuova people are very approachable.
(Their office is virtually within sight of mine).
One of the great advantages is that just about
everything looks like a file so it is very easy
to create namespaced collections of device-type
files that might be resident on your machine, or
just as easily resident on a collection of
disparate machines. It makes prototyping GRID
applications very much easier.
Personally I am very keen on looking more at
Inferno for GRID computing just as soon as I have
more time to spend on it. It's not a solution to
all ills, but it has definite advantages, and
seems to be very robust and has a small footprint.
I've seen it running happily on a fairly old
PDA being used to seamlessly integrate a whole
series of remote devices.
Aaron Turner, University of York
Re:All jokes aside...(scary) (Score:3, Funny)
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
Re:All jokes aside... (Score:3, Informative)
Re:All jokes aside... (Score:4, Insightful)
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.)
environment (Score:2, Insightful)
When's the last time you saw an app so well developed that it ran on almost any platform - not to mention as its own OS.
At this point, I don't even care what it does, I think that part shows a level that many other applications need to strive for.
Re:environment (Score:5, Funny)
Emacs :-P (at least the "own OS" part).
Inferno on the Mac G5 (Score:3, 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.
I seem to remember... (Score:2, Informative)
Re:I seem to remember... (Score:3, Informative)
Discreet's Inferno (Score:4, Interesting)
http://www.discreet.com/inferno/
Re:Discreet's Inferno (Score:2)
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-wi
Tinkered with an early version of Inferno (Score:3, Informative)
Re:Tinkered with an early version of Inferno (Score:5, Informative)
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).
Call me when they get to (Score:5, Funny)
A few obvious questions:
"I was made by the first power, the first holiness and the first love"
And if the above sounds like raving, just google for Dante Alighieri...
Re:Call me when they get to (Score:3, Funny)
Well, duh. Why do you think the ninth circle is made of ice?
And considering what the core [appstate.edu] looks like, I'm glad they've expanded the traditional four rings of protection to nine...
My favorite user license term ever (Score:3, Funny)
"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.
Additional License issue (Score:3, Insightful)
This is realistically commercial software with a "demo" license. You can't do anything serious with it. (Compare to Perl/PHP/Apache)
Re:Cool ... (Score:5, Funny)
In hell it is always the 1980s (Score:2)
Re:In hell it is always the 1980s (Score:2)
Re:I thought a better unix was ... (Score:5, Informative)
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 [vitanuova.com], 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
Re:Inferno 4... (Score:2)
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:Distributed Operating System? (Score:3, Informative)
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,
* 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 c
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:really cool... (Score:5, Informative)
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:
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.