Slashdot Mirror

you're right vi is the best,

and emacs aint all that.

=)

> So are you suggesting that firefox should be implemented as several thousand small applications joined together with pipes?? :)

Not thousands but why not, in principle ?

Downloading files from the internet and caching them is a very different job from rendering HTML. Having them in different processes would not be difficult or undesirable. Yet we have this monolith of a web browser, that by admission, is so complex the director of engineering says : of course it leaks memory.

Unix has lost its way. Thank goodness some people didn't forget what they started. The CREATORS of Unix stopped using it in the late 80s.

Mazal tov! You should have a happy marrage together.

Meanwhile, I got another friend getting married to Ms Plan 9

I wonder how the lot of you going to have sex.

binary packaegs not available
ccache no use - the ports system wipes the old code

Anyway that point is moot, the code takes along time to compile because gcc is a poor compiler.

> If you don't want buttons, X and toolkits you could just stick with a CLI interface- nobody is forcing you to use GTK or Qt.

Application writers make poor choices.

I have an entire OS with a GUI with no buttons and no toolkits. Sadly, it is also without Firewire and some other stuff I need.

As I said, buttons suck.

I think it's not an original idea; if you mentioned that near anyone who knew anything about Plan 9, you'd probably get one of those famous Replies. =)

gnome-vfs, kioslaves, etc aren't the optimal approach to this stuff, either - they're accessed via libraries, meaning applications have to specifically support them. Wake me up when I can, for example, use KDE's leet CD ripper with nothing but /bin/bash and /bin/cp on my side. Can't do that right now - applications need to be wired up properly to understand those.

Well, fortunately, there's light ahead in this respect. Maybe in a few years.

Dynamic objects have a lot of power, but they also carry significant risk. First, the complexity of classes increases tremendously when you start writing magic methods. These classes are harder to understand, debug, and maintain. In addition, as integrated development environments (IDEs) become more intelligent, they may experience problems with dynamic classes such as these because when they look up methods on a class, they won't find them.

Maybe not. As anyone who has read this classic essay by Ken Thompson knows, the only way you can really trust a peice of software is if you not only wrote it yourself, but also wrote (or created) the OS, the compiler all the libraries you app is linked against and even the hardware your software runs on. Any one of those items could easily be modified to detect that you are compiling or running a "significant" application and insert a back door into it.

Spoken like someone who's never read Reflections on Trusting Trust...

For WORM oriented storage Venti is really good, for the details see the paper "Venti: a new approach to archival storage"

It was originally developed for Plan 9 as the replacement of the dedicated fs kernel that used WORM jukeboxes, but now you can use it under Linux, BSD and other Unix systems because it's part of the Plan 9 from User Space" port of Plan 9 tool to Unix systems.

For WORM oriented storage Venti is really good, for the details see the paper "Venti: a new approach to archival storage"

It was originally developed for Plan 9 as the replacement of the dedicated fs kernel that used WORM jukeboxes, but now you can use it under Linux, BSD and other Unix systems because it's part of the Plan 9 from User Space" port of Plan 9 tool to Unix systems.

No, the first iteration of UNIX (originally spelt Unics), was a single-tasking command-line based OS. Users, multitasking and games all came later.

See: http://www.bell-labs.com/history/unix/

plan9 does this

and you get a day by day (or however much you fancy) snapshot so you can roll back your files to any snapshot in time you have recorded, on a process by process basis. I.E. you can have two different days open at the same time in different processes.

And, to add compliment to health, it doesn't use up extra space but uses Venti

Venti is also available for Unix-likes via plan9port

while I'm here, plan9 is secure BY DESIGN. No super user, networked authentication, networked file storage, diskless terminals etc. et bloody cetera.

Okay, I won't go on about stuff I am clueless about, *but* wasn't UNIX inspired by MULTICS, and wasn't MULTICS a pretty secure o/s, by design?

How hard would it be to start fresh, apply the Linux method to MULTICS or something like it, to have a an networking-oriented o/s with comprehensive security?

nope

$0 is nice but I bought my first copy of Slackware long before I could download it, I even had to copy it to (I think 22) floppies from cdrom so I could install it.

And even after I have downloaded them, I've paid for FreeBSD, plan9 and Inferno.

Free as in Freedom is more important than you give it credit for.

Just one business case is that one can mitigate risk by having multiple OS vendors to choose from. I know that if my chosen OS goes kaput or gets litigated out of existence then I won't go with it. And it doesn't cost me a fortune to try out the alternatives.

Wow. An entire thread devoted to this question, and so far this is the only answer that actually addresses the problem. Every other suggestions seems to be "changes languages", or "here's how to avoid bugs".

Anyway, let's talk specifics here. For the theoretical end of software fault tolerance, you can get a quick overview here or here.

In terms of practicalities, I know of an older fault tolerance library for Unix that includes watchdog, checkpointing, and replication utilities, and was created by AT&T (details and downloads here). A newer version appears to be available for Windows under the name SwiFT. Disclaimer: I haven't actually used either of these, and they both seem a little old. But I don't know of anything newer that isn't a proprietary in-house solution.

Finally, in terms of general design patterns for fault-tolerant distributed systems, you can't go past Joe Armstrong's PhD thesis, "Making reliable systems in the presence of software errors". While it's mostly about Erlang, many of the ideas he presents are readily applicable to other languages too.

They promised that they will port it to Plan 9, anyone know anything details on when?

The "D" name is misleading: it has absolutely nothing to do with the creators of B or C at Bell Labs. The successor of C was Alef(the first latter of a different alphabet) which was used for the original edition of Plan 9[1], and a later descendant by the same team was Limbo(Introduction paper by no other than Dennis M. Ritchie) for the Inferno.

Both Alef and Limbo are much more interesting languages than "D", they keep the clarity and simplicity of C while providing a high level framework for concurrent systems. The only other language with a good concurrency model I know of is Erlang which is quite different but also very interesting and sadly rather under valuated.

uriel

[1] To avoid having to maintain Alef compilers for many architectures Plan 9 is ported to, it was replaced with a C library, libthread, that provides the same concurrency model, for high level programming Limbo replaced it. Libthread, despite it's name is completely different from other threading models and uses CSP to handle concurrency while avoiding locks and many other problems with traditional "threading" systems. Libthread is part of Plan 9 from User Space so you can use it in "legacy" Unix/Linux/BSD systems too(of course Inferno runs on all those systems too...)

Who cares about Java?

We already have something far better, Limbo, it was design at Bell Labs by, Dennis Ritchie (the inventer of the C language and Co-inventer of Unix), Sean Dorward, Phil Winterbottom and Rob Pike (a lot of the Plan 9 design is thanks to him).

It is in a more free than Java (no crazy policies on what can be called Limbo), and has a more free licence than GPL2.

Unlike Java is has sane garbage collection that works, ONE sane fast toolkit module, advanced concurrency and has a C-like synax. You can read more about them in the docs.

A few more related links:
http://www.vitanuova.com/inferno/design.html
http://en.wikipedia.org/wiki/Inferno_(operating_sy stem)
http://en.wikipedia.org/wiki/Limbo_programming_lan guage
http://www.cs.bell-labs.com/sys/doc/

If you like on disk file systems you should read Venti: a new approach to archival storage.

Plan9's primary on-disk storage is Fossil, which runs in user mode. (Plan9 doesn't have a super user)

You can run arbitrary programs in Plan9 that present a file/folder directory structure by using the common 9P protocol. All devices look like files and folders and can be manipulated like any other, even at the permission level.

For instance, I have an image mounter that takes a tga file and presents 1 folder containing 4 files, red, green, blue and alpha.
I can then use any tool I like to manipulate those files using the file semantics we are all familiar with. I even have a flag that mounts the files as textual rather than binary, i.e :
00 00 ff ff
00 00 ff ff
ff ff 00 00
ff ff 00 00

and I can do image processing with awk !

If you like on disk file systems you should read Venti: a new approach to archival storage.

Plan9's primary on-disk storage is Fossil, which runs in user mode. (Plan9 doesn't have a super user)

You can run arbitrary programs in Plan9 that present a file/folder directory structure by using the common 9P protocol. All devices look like files and folders and can be manipulated like any other, even at the permission level.

For instance, I have an image mounter that takes a tga file and presents 1 folder containing 4 files, red, green, blue and alpha.
I can then use any tool I like to manipulate those files using the file semantics we are all familiar with. I even have a flag that mounts the files as textual rather than binary, i.e :
00 00 ff ff
00 00 ff ff
ff ff 00 00
ff ff 00 00

and I can do image processing with awk !

Yeah, try Plan9, though it has no full-featured web browser ;-) A non-x86 CPU would help as well. Or one could just use OpenBSD.

But some exploits are targetted at applications (say Firefox) and would work on most OS.

I'd rather live with the unmatched convenience of apt, than try to morph my system into some mix of Plan 9 and GNU/Linux.

At the end of the day, all our software is designed to work with the FHS, and no amount of fraglie automated scripts to create compatability directories for binaries, include files, library files, man pages, info pages, gstreamer elements, pam modules, iptables modules, firmware, bonobo components, gimp plugins, browser plugins, and so on ad infinitum is going to circumvent that.

As a Debian user of 7 or 8 years I get a little nervous at this. My choice of (vastly superior) operating system is what makes me feel different. Have a little mercy on a nerds elitist insecurities please! Im the guy who always discovered underground bands years ahead of everyone else, and when they finally became mainstream I wanted to disown them. My 'discovery' felt _violated_ by the hoards of unwashed sheep jumping on the wagon.

well, if you think Debian is getting too mainstream, there's always the wild wooly frontiers of something like Plan 9...

Ideas and Information, by Arno Penzias

http://www.bell-labs.com/user/apenzias/books.html/

For backups I run some nice Plan 9 magic - the Venti archiving file server. No-hastle incremental backups, snapshots of previous days, identical-block compression, and so on. It's been ported to Unix (and so runs on my Mac), and provides more peace of mind (coupled with the raid) about my data than I thought possible.

For backups I run some nice Plan 9 magic - the Venti archiving file server. No-hastle incremental backups, snapshots of previous days, identical-block compression, and so on. It's been ported to Unix (and so runs on my Mac), and provides more peace of mind (coupled with the raid) about my data than I thought possible.

Exactly. I would love to buy a copy of OS X for x86 on my PC, even if it cost me $400 to do so. It is worth the price, IMO. I will kill for an operating system on plain vanilla x86 machines that is almost perfect. Windows is insecure and needs to be scrapped, and Linux is just too hard to use for an everyday user. OS X is the perfect operating system. It is easy to use for both regular users and is great for computer science majors and other people who need Unix. But, as I see it, Apple will never give in and sell Mac OS X to people with vanilla x86 boxes, or collaborate with Dell and HP and bundle OS X with their machines. Once that happens, we can kiss Apple and OS X goodbye.

The time is ripe for a brand new operating system on the x86 platform. I would love to see something with the architecture and/or the ideas of Plan 9 or something like the L4 microkernel, the compatibility of *nix and Windows (via Wine) so that way we don't all have to start from scratch, the security of OpenBSD, a kick-butt windowing system like Aqua (except better), radical new ideas for user interfaces, rapid software development, and overall just knocks the socks off of everything else that we have seen so far. It will be much like NeXTSTEP back in the day or Mac OS X is currently. I would love to see an operating system that solves nearly all of the technical problems, security issues, and usability issues that we face today. Mac OS X does well in all of these regards, but it isn't available for everybody. Imagine if we had an operating system that was not only better than OS X is, but is also available for all computers that can handle it. Regular users who desperately want to leave Windows must either shell out $$$ for a Macintosh (which requires that they buy a new computer), or endure the learning curve that switching to Linux entails. My ideal OS will have no restrictive licensing that tells me that I can only install it on a Pear x86 box, and no DRM that sends the helicopters flying over my house when I install PearPC OS on my vanilla x86 box. Any volunteers?

Recall Brian Kernighan's famed Trojan Horse speech.

Are you referring to this? That was Ken Thompson.

He's right, to some point. When unix was created (linux is just a unix clone, bsd a unix derivate, windows is just a "unix sucks so we're going to reimplement the same ideas in a different way") there was no internet.

And then, internet was created. And TCP/IP was created on top of the current unix design, but nobody wasted time redesigning unix to make it not suck with networks.

The guys at the labs where unix was created (bell labs) realized that unix sucked. It sucked so much that they decided to redesign the whole OS, and they created Plan 9, a really beautiful OS where the system is really integrated in the network, but nobody cares about plan9 because, you know "unix rules" (notice the irony) and all that.

Take a look at one of the plan 9 papers to realize why unix sucks WRT to networks, and why current unix design can NOT really handle internet properly (regardless of that internet works thanks to big unix irons). It's time for the unix community to stop thinking that unix is the best operative system design you can get and start fixing it.

if you fronted it with an archived storage system such as Venti then it would be far more attractive.

see also :

http://en.wikipedia.org/wiki/Fossil_(file_system)

They act as a archive/cache type system so that only recently used data needs to be on the HD and archive older files but keep them available on the same filename AND you can also see all the versions of the file you've ever had :

------
To access a snapshot, one would connect to a running fossil instance ("mount" it) and change directory to the desired snapshot, e.g. /snapshot/yyyy/mmdd/hhmm (with yyyy, mm, dd, hh, mm meaning year, month, day, hour, minute). To access an archive (permanent snapshot), a directory of the form /archive/yyyy/mmdds (with yyyy, mm, dd, s meaning year, month, day, sequence number) would be used. Plan 9 allows modifying the namespace in advanced ways, like redirecting one path to another path (e.g. /bin/ls to /archive/2005/1012/bin/ls). This significantly eases working with old versions of files.

------

Well, at least Rob Pike, one of the Plan 9 developers (and, of course, of Unix fame), works at Google since he left Bell Labs. A network-centric OS like Plan 9 (or it's successor, Inferno) would probably be an ideal match for a Google infrastructure.

I think his point is that you can mislead a programmer pretty easily because they'll read the English before they read the C, and when they read the C, the C itself can be misleading. Witness the IOCCC. A programmer who knows their code will be visible to the world may take extreme steps to obfuscate and mislead, at least in the portion of the code that contains sensitive information and/or algorithms.

If you read the binary, you see exactly what the machine executes and no more. A lazy programmer that's shipping only a binary might figure compilation alone is sufficient to obscure the key and the algorithm and thus won't take steps to further obscure the key or its corresponding algorithm. Thus, the object code will likely be very direct and easier to reverse.

For an extreme case where browsing the source doesn't help you one bit, read Reflections on Trusting Trust, by none other than Ken Thompson.

--Joe

Reinvent unix, you mean like Linux?

http://www.cs.bell-labs.com/wiki/plan9/plan_9_wiki /

http://www.cs.bell-labs.com/plan9dist/

(Sorry, I'm not attacking Linux, I just find your post ironic....)

Reinvent unix, you mean like Linux?

http://www.cs.bell-labs.com/wiki/plan9/plan_9_wiki /

http://www.cs.bell-labs.com/plan9dist/

(Sorry, I'm not attacking Linux, I just find your post ironic....)

Wow. I've read this story before - back when it was J. Hendrik Schon faking experiments at Bell Labs, with his collaborators eventually stuck with retracting 17 Science and Nature papers.

The similarities are incredibly striking, including (according to the New Scientist) duplicated figures within papers and between papers claiming to be different samples.

What motivates someone to (apparently) fake results like this, when they're almost sure to be caught?

Sounds suspiciously like the "everything is a file" approach promoted by the Plan 9 OS. Not that I think that necessarily makes it a bad idea.

I keep telling them they're in danger of giving rise to dom.

• The Pragmatic Programmer
• Code Complete
• The Practice of Programming

In short, they all suggest writing readable code is more important than commenting spaghetti, but there are also good points on commenting. (Can't be bothered to copy-paste them here, though, see for yourself.)

And really, what would be the point of having access to half of the software stack?

You haven't read Ken Thompson's famous bit on how to trojan the compiler and a particular application so that you can't find any trace of the trojan in the source code for either one, then? (Was the first hit on a Google for "compiler trojan trust".)

Basically, if you don't have the entire stack, and a completely independent way to compile it, you have no idea what is happening in a completed stack. Especially if the code running at high privilege; you could have your I/O drivers replacing code blocks on load so that the application suite audits correctly.

Look at how much spyware for Windows works by intercepting basic system calls. Unless you have a trustable, independent way of re-creating the software stack, and then verifying that exact stack is actually running on the machine, you've got no reason to trust the box.

So, for any environment where trust is important, almost any operating system is too complicated.

Maybe not "COMMODORE BASIC V2", even though it's from Microsoft.

You're leaving out "someone with authorized access to the server and to the code could send out malicious code with the next software update".

Disregarding any personal anecdotes about the integrity of the known authors and dealing strictly with statistics, this about 5 times as likely as an external hacker doing it. I personally doubt it's going to happen, but it can't be discounted as a possibility.

Trust but verify.

On top of those mechanisms, even slower interprocess communication systems are typically implemented, such as OpenRPC and CORBA. (For even more inefficiency, there's XPC. In Perl. But I digress.)

Because of this history, there's a perception that interprocess communication has to be slow. It doesn't.

What you really want looks more like what QNX has - fast interprocess messaging that interacts properly with the scheduler. QNX has to have interprocess communication done right, because it does everything through it, including all I/O. This works out quite well. You take a performance hit (maybe 20% for this), but you get much of that back because the higher levels become more efficient when built on good IPC.

The QNX messaging primitives are available for Linux, although the implementation isn't good enough for inclusion in the standard kernel. That work should be redone for the current kernel.

IPC/scheduler interaction really matters. If you get it wrong, each interprocess transaction results in an extra pass through the scheduler, or worse, both the sending process and the receiving process lose their turn at the CPU. This is easy to test. Start up two processes that communicate using your IPC mechanism. Measure the performance. Then start up a compute-bound process and measure again. If the IPC rate drops by much more than a factor of 2, something is wrong. Don't be surprised if it drops by two orders of magnitude. That's an indication that IPC/scheduler interaction was botched.

Sun addressed this in the mid-1990s with their "Doors" interface in Solaris, which had roughly the right primitives. But that idea never caught on.

The article here implements a message-passing system via shared memory, which is not exactly a new idea, even for UNIX. I think it first appeared in MERT, in the 1970s. It's an attempt to solve at the user level something that the OS should be doing for you.

Shared memory is a hack. It's hard to make it work right. With it, one process can crash other processes in hard-to-debug ways. Sometimes you need it because you're moving vast amounts of data, (by which I mean more than just a video stream) but that's rarely the case.

There's a good example of this in The Practice of Programming, by Kernighan and Pike, with sample code in C, C++, Java, AWK and Perl for a markov chain text creator. The example is to demonstrate data structures and compare running time of different languages, but the code itself is kind of cool.

It's here

Dennis Thompson? I didn't know that Dennis Ritchie and Ken Thompson fused and merged together back in the 60s to become ... Dennis Thompson.

Dennis Thompson? I didn't know that Dennis Ritchie and Ken Thompson fused and merged together back in the 60s to become ... Dennis Thompson.

I can and will argue that

or rather, I'll just provide a link to this

The Use of Name Spaces in Plan 9

        Rob Pike
        Dave Presotto
        Ken Thompson
        Howard Trickey
        Phil Winterbottom
        Bell Laboratories, Murray Hill, NJ, 07974 USA

http://plan9.bell-labs.com/sys/doc/names.html

The inventors of Unix scrapped symlinks when they did their next OS

Symbolic links make the Unix file system non-hierarchical, resulting in multiple valid path names for a given file. This ambiguity is a source of confusion, especially since some shells work overtime to present a consistent view from programs such as pwd, while other programs and the kernel itself do nothing about the problem.

http://plan9.bell-labs.com/sys/doc/lexnames.html

NT *was* going to have executables that pretended to be files, i.e. when you opened the executable to get the contents it would run and return the output rather than the by bytes of the executable, with a special NT syscall to read the *real* contents. Kind of like a named pipe. I was looking forward to this but it didn't work out.

Bell labs only changed their name. They're still around today operating as Lucent. http://www.bell-labs.com/

Except that the Bell Labs are now mostly empty and seen as a cost, not as an asset and provider of future technologies.

Bell Labs are dead, and that's one of the few thing to regret of what came from the AT&T breakup.

Not just pulars. Remember, they also (trying to identify a source annoying noise) discovered cosmic background radiation. They helped find the *really* big map with the "you are here" marker :-)

Bell Labs' Cosmology page.

-t

Mr. Gates writes "We have a research lab in Cambridge, we have one now in China, one in India and that is where the top problems in computer science are going to be solved."

Really ?

Here's some of the top problems in CS.

Here's the research lab in India - working on technology implementations, certainly not top CS problems.

Here are the 10 innovations that will blow you away - coming out of Beijing. Again, some very sound implementations, but not exactly top 10 CS problems.

But yes, Cambridge is looking at some of the top 10 CS problems. However, MS is no Bell Labs when it comes to taking on research problems. They end up successfully monetizing tech solutions, but that is quite different from pioneering fundamental breakthroughs like inventing a transistor or laser.