Slashdot Mirror

No, thanks. I'll stick with Frederik Brooks' "Plan to throw one away, you will anyway".

50 years of wisdom are not to be discarded lightly.

But, then again, perhaps because people have forgotten this rule we've been stuck with the same OS design for the past 30 years -- people keep adding to it without really understanding the problem. On the other hand the new developments are shunned and soon forgotten.

System software research is irrelevant.

Go ahead, reuse the same code over and over again until it becomes a bloated behemoth which nobody understands, contrary to what are probably the three best rules of software development -- Simplicity, Clarity, Generality.

They should teach kids at school that as soon as they have understood the problem they should rewrite their code to reflect the fact.

No, thanks. I'll stick with Frederik Brooks' "Plan to throw one away, you will anyway".

50 years of wisdom are not to be discarded lightly.

But, then again, perhaps because people have forgotten this rule we've been stuck with the same OS design for the past 30 years -- people keep adding to it without really understanding the problem. On the other hand the new developments are shunned and soon forgotten.

System software research is irrelevant.

Go ahead, reuse the same code over and over again until it becomes a bloated behemoth which nobody understands, contrary to what are probably the three best rules of software development -- Simplicity, Clarity, Generality.

They should teach kids at school that as soon as they have understood the problem they should rewrite their code to reflect the fact.

Where can I buy this 'internet explorer'?

Does it run on plan 9?

It will be interesting to see if they separate IE from Windows in a way they said was impossible!

Your answer is too simplistic.

Here is an excellent overview of exactly what is wrong with current systems research.

The gist of it is (IMHO): the current research atmosphere is too short term to support a truly revolutionary systems research program - and a good one requires more resources than one can justify. The problems are nowhere near solved - everyone has just settled on some fixpoint.

Then, with more and more languages, especially ones with VMs, you get further and further away from the hardware. The end result: you lose performance. It does more and more for you, but at the expense of real optimizations, the kind that only you can do.

Now the zealots will come out and say, "Language X is better than language Y, see!" To me this argument is boring. I tend to use the appropriate tool for the job. So:

• Python for scripts, prototypes, proofs of concept, or components where performance generally is not an issue.
• For desktop apps, Visual Basic (yep, most IT apps are in VB). There is no justifiable reason for an IT department group to write a sales force reporting system in C++! If you want C++, go get a job at a software company. Stop wasting money and time making yourself feel like a hotshot. [I'd consider Kylix here if it was based on Basic. Why? Because honestly, Pascal is just about dead, and Basic is the king of the simple app. Let's just live with it and move on. I do want a cross-platform VB . . . ]
• For web apps, well, I stick around PHP/ASP.NET. Why? Portability! And moreover, the sticking point in a web-based app is not the UI layer; it's usually the underlying data extraction and formatting. Don't waste your time with lower level languages there. IMHO it's just not worth it. JSP and Java stuff, yuck! Too much time for too little bang.
• Java/C# (also consider mono/LISP for most production apps. Why? Portability! I want no vendor holding me by the balls. I want platform independence on the back end, and these are the few ways to achieve it. I'd include Haskell/OCAML here when appropriate. Perl? I'm loathe to use Perl as production, considering most Perl code cannot be understood 2 weeks after it's written. I'd rather take the hit in performance and be able to pass the code to someone else later.
• C++/C for components--just components--where performance is at an absolute premium or there exists some critical library that only has this kind of interface. But this step has to be justified by the team, with considerable explanation why a different architecture could not suffice. Otherwise, the team could waste time checking for dangling pointers when instead it could be doing other things, like finishing up other projects.
• Assembly? Only when there is not a C complier around. Embedded stuff. Nowadays, you just do not have the time to play.

Yes, my teams use many languages, but they also put their effort to where they get the biggest bang for the buck. And in any business approach, that's the key goal. You don't see carpenters use saws to hammer in nails or drive screws. Wise up!

I was also under the impression that all the original UNIX header files are covered under the license discussed here that came out of the original AT&T/USL/BSDi cases, or are not copyrightable at all as you point out.

It
Sure
Is

BSDI has agreed to substitute a port of the University of California's forthcoming new release to be known as 4.4 BSD(Lite) for BSD/386. For a limited period of time, BSDI may continue to distribute its BSD/386 product, although certain portions of the code may be distributed in binary form.

AT&T

Bell Labs

IBM

I'd say that these are fair trades for what you say is monopoly. The fact is that like nobody will invest the huge amounts of capital required unless a return is somewhat guaranteed. Not all monopoly is bad.

Most theoretical work on sorting has assumed randomly-sorted input data

I seem to recall that insertion sort is also O(n) on nearly-sorted input, so it would be a much safer choice than bubblesort for the situation you describe. You have to consider best- and worse- case scenerios as well as the nominal path. IMHO, bubble sort has no place outside of an instructional setting.

Welcome to my world

Plaintiff's first argument is that Defendants have copied the filenames and header files from 32V. ... One fact does seem clear: the header files, filenames, and function names used by Defendants are not trade secrets.

The ruling from Judge Debevoise was on whether the header files could be considered trade secrets. Berkeley had a license to copy and distribute derivative works, so the trade secret argument was an attempt to prevent them from distributing the source. The judge ruled for the Defendents.

#include

I am not a lawyer. I am not a paralegal. I do not offer legal advice to anyone, ever.
As someone who uses Linux and BSD every day, I do have an interest in this case, and in the history of UNIX.

Remember, copyright law has changed since UNIX was written. Be careful not to make incorrect assumptions based on what the law says today .

I have one question: are the BSD header files subject to copyright ? I really tought that these files were declared as "no copyrightables" in 1973

Not quite. IIRC they were not "declared 'no copyrightables'" in 1973 but in 1993 the court found that 32V may have entered the public domain due to AT&T's not following copyright rules in effect between 1978 and 1986.

Please read this document, esp. the section titled "1. Copyright Infringement".
http://cm.bell-labs.com/cm/cs/who/dmr/bsdi/930303. ruling.txt
Please note that this is a ruling denying an injunction that would have prevented distribution of BSD, not a dismissal of the entire case. So it's not as strong as we might like.

There is a lot of information about the BSD case on the web, start here . Of course, the settlement itself is sealed, so it's hard to say exactly what it contains. However, such a settlement would restrict USL, BSDI and the Regents of the University of California, not the Linux developers or IBM.

And the general feeling is that USL asked for the seal because they had their ass handed to them, not because the wanted to spare the Regents a public humiliation.

<grin>

Does this help clear things up?

#include

I am not a lawyer. I am not a paralegal. I do not offer legal advice to anyone, ever.
As someone who uses Linux and BSD every day, I do have an interest in this case, and in the history of UNIX.

Remember, copyright law has changed since UNIX was written. Be careful not to make incorrect assumptions based on what the law says today .

I have one question: are the BSD header files subject to copyright ? I really tought that these files were declared as "no copyrightables" in 1973

Not quite. IIRC they were not "declared 'no copyrightables'" in 1973 but in 1993 the court found that 32V may have entered the public domain due to AT&T's not following copyright rules in effect between 1978 and 1986.

Please read this document, esp. the section titled "1. Copyright Infringement".
http://cm.bell-labs.com/cm/cs/who/dmr/bsdi/930303. ruling.txt
Please note that this is a ruling denying an injunction that would have prevented distribution of BSD, not a dismissal of the entire case. So it's not as strong as we might like.

There is a lot of information about the BSD case on the web, start here . Of course, the settlement itself is sealed, so it's hard to say exactly what it contains. However, such a settlement would restrict USL, BSDI and the Regents of the University of California, not the Linux developers or IBM.

And the general feeling is that USL asked for the seal because they had their ass handed to them, not because the wanted to spare the Regents a public humiliation.

<grin>

Does this help clear things up?

>Of course you'd be nuts to store dates as text.

why? atoi is your friend

It's called 'human readable text'

It also removes endian problems for numbers stored in binary form across platforms.

Think of the difference between user.dat and what regedit displays.

That's why plan9 continued what Unix started and uses plain text for all configuration files.

Binary config files are the devil's spawn.

then you might like plan9

It has r/w addressable video memory.

And being plan9 it is even available across the network, like all memory, modulo permissions.

9p

Unix originally didn't even have a network stack, so you would have a hard time finding a way to "root it in minutes", not to mention that TCP/IP didn't even exists at the time.

Shadow passwords are more complex than the original UNIX design
Shadow passwords are not a solution, shadow passwords are an ugly hack. Of course the most secure solution is not the simplest. In the this case, shadow passwords were barely enough for stand-alone systems; in a networked environment you need a different kind of distributed authentication framework, and that is what factotum/secstore provide with a relatively low complexity keeping in mind the implicit complexity of the problem domain.

As for problems with how in Unix "everything is a file", the problem is not with the original Unix ideas, but with how some misguided souls(*cough* USL, *cough* BSD, *cough* SUN, *cough* RMS/GNU, *cough* Linux, *cough* GNOME, ...) didn't have a clue what they were doing(not to mention they even did a pathetic job at fucking up the original Unix ideas... hell, at least VMS had technical quality and some consistency!).

Who added most of the networking functionality to Unix? a bunch of clueless undergrads in Berkeley, really, who is surprised about the result(BIND, sendmail, etc..)?

Unix, in it's original and "pure" form, evolved, and most if not all the original problems where *fixed*, and so Plan 9 was born, more than 10 years ago, but the "UNIX community"(read, "bunch of misguided clueless religious fanatics") never even understood what Unix was supposed to be like, and more than 30 years later they keep repeating the same mistakes again and again, but now they don't have enough with their own mistakes, that they need to copy others mistakes too(see GNOME...).

There is nothing wrong with the original Unix ideas; yes, there were some horrible mistakes(*cough* suid, /etc/passwd, ...) but the basic ideas were solid(and in good part based in the best of MULTICS), the problems is people that _never_ understood those ideas, the people that really understood them fixed the problems and kept moving forward(until Lucent killed them anyway).

None of the problems you mention applies to Plan 9(and some of them nor to the last version of Research Unix), and in most cases neither to what Unix was originally.

BTW, Plan 9 doesn't even have the concept of "root" or "Administrator", so it can hardly be rooted, as for buffer overflows, all you need is sane libs to deal with string manipulation, which it's true the original Unix didn't have, but the problem is people that in more than 30 years is incapable of fixing a broken lib design, the original Unix designers fixed the "problem" *long* ago.

Best wishes

uriel

Unix originally didn't even have a network stack, so you would have a hard time finding a way to "root it in minutes", not to mention that TCP/IP didn't even exists at the time.

Shadow passwords are more complex than the original UNIX design
Shadow passwords are not a solution, shadow passwords are an ugly hack. Of course the most secure solution is not the simplest. In the this case, shadow passwords were barely enough for stand-alone systems; in a networked environment you need a different kind of distributed authentication framework, and that is what factotum/secstore provide with a relatively low complexity keeping in mind the implicit complexity of the problem domain.

As for problems with how in Unix "everything is a file", the problem is not with the original Unix ideas, but with how some misguided souls(*cough* USL, *cough* BSD, *cough* SUN, *cough* RMS/GNU, *cough* Linux, *cough* GNOME, ...) didn't have a clue what they were doing(not to mention they even did a pathetic job at fucking up the original Unix ideas... hell, at least VMS had technical quality and some consistency!).

Who added most of the networking functionality to Unix? a bunch of clueless undergrads in Berkeley, really, who is surprised about the result(BIND, sendmail, etc..)?

Unix, in it's original and "pure" form, evolved, and most if not all the original problems where *fixed*, and so Plan 9 was born, more than 10 years ago, but the "UNIX community"(read, "bunch of misguided clueless religious fanatics") never even understood what Unix was supposed to be like, and more than 30 years later they keep repeating the same mistakes again and again, but now they don't have enough with their own mistakes, that they need to copy others mistakes too(see GNOME...).

There is nothing wrong with the original Unix ideas; yes, there were some horrible mistakes(*cough* suid, /etc/passwd, ...) but the basic ideas were solid(and in good part based in the best of MULTICS), the problems is people that _never_ understood those ideas, the people that really understood them fixed the problems and kept moving forward(until Lucent killed them anyway).

None of the problems you mention applies to Plan 9(and some of them nor to the last version of Research Unix), and in most cases neither to what Unix was originally.

BTW, Plan 9 doesn't even have the concept of "root" or "Administrator", so it can hardly be rooted, as for buffer overflows, all you need is sane libs to deal with string manipulation, which it's true the original Unix didn't have, but the problem is people that in more than 30 years is incapable of fixing a broken lib design, the original Unix designers fixed the "problem" *long* ago.

Best wishes

uriel

...it grew up together with the Internet as a networked OS. This was not an afterthought.

http://www.cs.bell-labs.com/cm/cs/pearls/sec073.ht ml

I think every software developer should read that... perhaps annually. :-)

this articles a good read so take the time to go through it as it summarises innovation from the early internet years to date.

innovation. The trick is finding that one crazy idea. The problem with crazy ideas, though, is that for every one good crazy idea, there's a thousand bad crazy ideas

the eternal quest for an idea. you better start with a good idea. if you don't, no matter how hard you try it wont pan out.

the Internet community back then, the key technical people, didn't want the Internet to become easy to use or graphical, ... Only smart people could use the Internet ...so we needed to keep it hard to use

what other examples can you think of right now?... only smart people can use [insert you own example]

Mosaic started with 12 users in February 1993. It had 1,000 users within three or four weeks. About 10,000 users by spring. It was up to 1 million by early 1994

Posters who question why Andreessen has such prominence should reflect on this. No Mosaic (mozilla), no Microsoft Internet Explorer (IE Based on NCSA Mosaic code base licensed from Spyglass), no World Wide Web in the early to mid 90's. No doubt someone else may have invented the browser but how much longer would it have taken?

At first that makes you like a little bunny rabbit ... Everybody wants to play with you ....within a year ... fearsome competitors shooting at your head with high-powered ammunition

Larry, Sergi do you feel the hot breath of the MS juggernaut as you approach your IPO. Will google will be a repeat of Netscape/MS tussle?

Oracle database was a huge success ... Larry's spent the last 25 years trying to come up with the next product

it sure helps when the government (CIA) is your preferred backer. Why does oracle feel the need to keep trying to re-innovate or create the next best idea?

innovation comes from companies that are 2 years old, populated by 19-year-olds ... preposterous that Marc should think that innovation is .. the province of little entrepreneurial companies.

In fact it's both. The technical revolution was spurred on the back of the transistor. This was the combined effort of Bardeen, Brattain and shockley at Bell Labs - no small comany there ... but look at Intel, though a big company now, it was started with the (not so young) Noyce, Moore and Grove. What about the Linux kernel, third person shooters and that other search engine, Yahoo?

I think it's reasonable to assume you are talking about Linux not Windows.

Get a grip. He could be talking about any Unix version or clone thereof.

What is the kid researching data storage technology doing in the library in the first place? The Net would have much more up to date information than a library would. A quick search on Google reveals almost 6 million results for "data storage technology". While, admittedly, many of the are for online storage services such as XDrive, or manufacturers such as Seagate or APS Tech, there are still quite a few diamonds, such as a webpage about IBM's Millipede storage technology, a Network Computing article on storage disasters, a Bell Labs press release on holographic data storage, etc.

There's just no way a library would buy such obscure and expensive books on data storage technologies when they could be buying children's books, novels, and reference books, which have far wider appeal than stuff on data storage technologies. Anyway, isn't this what the Net's for? To get otherwise obscure, expensive information cheaply and efficiently?

``Not only is UNIX dead, it's starting to smell really bad.'' -- rob pike, Bell Labs 1991

And I'm sorry to tell you that every bit of that applies to Linux and *BSD.

Of interest is also "Systems Software Research is Irrelevant".

Get the only OS that doesn't stink while you still have a chance:
Plan 9 from Bell Labs
(and now it's *really* OpenSource)

Plan 9 is what the creators of UNIX thought UNIX should have been. Here is the paper that explains why and how they decided to replace UNIX:
http://www.cs.bell-labs.com/sys/doc/9.html

uriel

``Not only is UNIX dead, it's starting to smell really bad.'' -- rob pike, Bell Labs 1991

And I'm sorry to tell you that every bit of that applies to Linux and *BSD.

Of interest is also "Systems Software Research is Irrelevant".

Get the only OS that doesn't stink while you still have a chance:
Plan 9 from Bell Labs
(and now it's *really* OpenSource)

Plan 9 is what the creators of UNIX thought UNIX should have been. Here is the paper that explains why and how they decided to replace UNIX:
http://www.cs.bell-labs.com/sys/doc/9.html

uriel

``Not only is UNIX dead, it's starting to smell really bad.'' -- rob pike, Bell Labs 1991

And I'm sorry to tell you that every bit of that applies to Linux and *BSD.

Of interest is also "Systems Software Research is Irrelevant".

Get the only OS that doesn't stink while you still have a chance:
Plan 9 from Bell Labs
(and now it's *really* OpenSource)

Plan 9 is what the creators of UNIX thought UNIX should have been. Here is the paper that explains why and how they decided to replace UNIX:
http://www.cs.bell-labs.com/sys/doc/9.html

uriel

and for a little walk through memory lane The UNIX Story. Also also lets not forget MS UNIX, Xenix IIRC

Rus

How will common file systems and OS designs have to change to accommodate WORM media?

Plan 9 from Bell Labs already has.

How will common file systems and OS designs have to change to accommodate WORM media?

Plan 9 from Bell Labs already has.

So my understanding of the state of the art, as understood by real UI people, is that windows should tile on the screen instead of overlapping. If your windows don't all fit on the screen, you need a new screen.

This is the way I do it: Have 9 virtual screens (natively in GNU/Linux or via Altdesk on Windows), with each screen bound to one of the keys in the 3x3 square defined by Q-E-C-Z (Ctrl-Shift-q for screen 1, C-S-e for screen 3, C-S-a for screen 4, etc.)

Rows are for machines: Q-W-E is the local machine, Z-X-C is shells and windows on my home machine, A-S-D is shells and windows on other machines. Columns are applications: Q-A-Z is random shells and small applications, W-S-X is full-screen apps (e.g. web browser & email client), E-D-C is programming (Studio or emacs + shells depending).

I've found that hitting C-S-whatever becomes pretty much automatic when I want to get to a particular app; there are a couple of overlaps (sometimes I'll have email and web both open at home, so I'll have to say C-S-x then click in the taskbar), but on the whole I can juggle quite a few programs without ever having to hunt through the taskbar.

= 9J =

Early versions of C did not have all of the integral types that we are now used to having. I remember using an old C compiler that only had "char", "int", "unsigned" and "long". The only 32-bit type was long, which was signed.

Later surpassed by "Plan 9 from Bell-Labs", which distills the ideas from UNIX and improves in many areas it lacked:

Plan 9 from Bell-Labs

Somebody else mentioned Rob Pike already, pity you can't find any of his older (pre-Plan 9) papers online anymore: "The Hideous Name" and "Cat -v Considered Harmful":

R. Pike, P. Weinberger, "The Hideous Name" USENIX Summer 1985, pp 563-568.

and an abstract of the other: http://gaul.org/files/cat_-v_considered_harmful.ht ml

As for history repeating itself, let me quote Ron Minnich:

You want to make your way in the CS field? Simple. Calculate rough time of amnesia (hell, 10 years is plenty, probably 10 months is plenty), go to the dusty archives, dig out something fun, and go for it. It's worked for many people, and it can work for you.

http://www.cs.bell-labs.com/who/rob/

be sure to catch "Systems Software Research is Irrelevant"

You will probably see a lot worse links than :

Bell Labs - formerly known as heaven.

http://www.cs.bell-labs.com/who/rob/

be sure to catch "Systems Software Research is Irrelevant"

You will probably see a lot worse links than :

Bell Labs - formerly known as heaven.

Shannon's 1948 paper, "A Mathematical Theory of Communication", the seminal work on information theory and coding.

...but Claude E. Shannon's paper, A Mathematical Theory of Communication has changed our outlook on information and communication. The importance of this paper on modern communication cannot be stressed enough, and it is very readable. If I had 10 papers to take to a desert island, surely this one would be on my list (:

The linux loader also supports plan9 and Inferno

So why watse your life with Linux when you can use professional software.

oh, and inferno comes with tetris too

Venti. Filesystem-level, research project, and it was Plan 9 not UNIX. In other words, pretty much totally unlike what I was talking about.

Venti is described as a "block-level" system. Yes, it uses different technology from the buzzword-laden approach you are taking, although it doesn't sound like your user experience will be any better. And, no, it's not what I was talking about. Venti is only one of several such systems at Bell Labs.

What I had used is described in "Sean Quinlan. A cached WORM file system. Software---Practice and Experience, 21(12):1289--1299, December 1991.". While the server ran on Plan 9, it was exported to Research UNIX systems, which is where I think most real users used it.

Furthermore, others have already mentioned it on this very thread and said it was useful to them, putting the lie to your claim that it's not useful.

Yes, probably in the same sense that the other systems you talk about are "useful" to someone: mostly people with deep pockets looking for a silver bullet to intrinsically hard data management problems. Hey, your company may have a market there as well--silver bullet sales are up again.

Nice troll, kid.

I'm always grateful for compliments about my youthful appearance. Now, go back read some research papers on file systems, replication, and versioning--you really seem to need it.

Plan9 has the mantra : "file creation is forever"

Automated incremental backups are a way of life.

With Venti one can even back up two windows/linux machines and *not* use up disk space for commonly used blocks, so backing up 100 machines wont use up the usual 1Gb each for the duplicate libs/windows directories.

The yesterday command give you the power to browse back through your life

Find what has changed in the C library since March 1:

yesterday -d -0301 /sys/src/libc/port/*.c

When did you say this guy did the innovation again?

Plan9 has the mantra : "file creation is forever"

Automated incremental backups are a way of life.

With Venti one can even back up two windows/linux machines and *not* use up disk space for commonly used blocks, so backing up 100 machines wont use up the usual 1Gb each for the duplicate libs/windows directories.

The yesterday command give you the power to browse back through your life

Find what has changed in the C library since March 1:

yesterday -d -0301 /sys/src/libc/port/*.c

When did you say this guy did the innovation again?

C= Wlog2(1+S/N)

S= kEb/T

(Eb/N0)>= (lim as nmax->0){log2(((2^nmax)-1)/nmax)}

What you *really* need is a better way for libraries, and other code, to expose their functionality.

Unix started down this road with 'everything is a file' but failed to follow through on that promise.

When the Unix creators decided to take what they already knew and start again, 'everything is a file' became a design philosophy.

Consequently, devices can be accessed through the file system
One can draw to a screen via files, or open a internet network connection

The magic for all off this is a unified protocol 9p. All file access is via 9p so if your program can speak 9p it can serve files to anyone. One binds a programs namespace into your own and off you go. The network becomes utterly transparent.

In this way one waves bye bye to bindings and other marshalling techniques, who needs 'em.

If your programming language can open and read and write files, it can do anything.

It is just one of the many benefits that plan9 has brought to us.
Too bad people are letting it slip past them.

What you *really* need is a better way for libraries, and other code, to expose their functionality.

Unix started down this road with 'everything is a file' but failed to follow through on that promise.

When the Unix creators decided to take what they already knew and start again, 'everything is a file' became a design philosophy.

Consequently, devices can be accessed through the file system
One can draw to a screen via files, or open a internet network connection

The magic for all off this is a unified protocol 9p. All file access is via 9p so if your program can speak 9p it can serve files to anyone. One binds a programs namespace into your own and off you go. The network becomes utterly transparent.

In this way one waves bye bye to bindings and other marshalling techniques, who needs 'em.

If your programming language can open and read and write files, it can do anything.

It is just one of the many benefits that plan9 has brought to us.
Too bad people are letting it slip past them.

What you *really* need is a better way for libraries, and other code, to expose their functionality.

Unix started down this road with 'everything is a file' but failed to follow through on that promise.

When the Unix creators decided to take what they already knew and start again, 'everything is a file' became a design philosophy.

Consequently, devices can be accessed through the file system
One can draw to a screen via files, or open a internet network connection

The magic for all off this is a unified protocol 9p. All file access is via 9p so if your program can speak 9p it can serve files to anyone. One binds a programs namespace into your own and off you go. The network becomes utterly transparent.

In this way one waves bye bye to bindings and other marshalling techniques, who needs 'em.

If your programming language can open and read and write files, it can do anything.

It is just one of the many benefits that plan9 has brought to us.
Too bad people are letting it slip past them.

What you *really* need is a better way for libraries, and other code, to expose their functionality.

Unix started down this road with 'everything is a file' but failed to follow through on that promise.

When the Unix creators decided to take what they already knew and start again, 'everything is a file' became a design philosophy.

Consequently, devices can be accessed through the file system
One can draw to a screen via files, or open a internet network connection

The magic for all off this is a unified protocol 9p. All file access is via 9p so if your program can speak 9p it can serve files to anyone. One binds a programs namespace into your own and off you go. The network becomes utterly transparent.

In this way one waves bye bye to bindings and other marshalling techniques, who needs 'em.

If your programming language can open and read and write files, it can do anything.

It is just one of the many benefits that plan9 has brought to us.
Too bad people are letting it slip past them.

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

The Fourth Edition of Plan 9 includes a substantially reworked security architecture, described in the USENIX Security 2002 conference paper [html, ps, pdf] by Russ Cox, Eric Grosse, Rob Pike, Dave Presotto, and Sean Quinlan.

One particular aspect that other operating systems may wish to adopt is our single-signon solution. A process called factotum is used to hold credentials like passwords and public/private keypairs and perform cryptographic operations. Factotum allows clients to speak a variety of cryptographic protocols and therefore legacy application servers can participate in our single-signon system without change and without even knowing it exists.

The factotum has no direct permanent storage, but rather fetches credentials at startup from a secstore server on the network. To authenticate safely with the secstore, Password Authenticated Key-exchange is used; this implies that the user just has to remember and type one password and passive eavsdroppers or even active malicious intermediaries can not launch even a dictionary attack against the system. The credentials are encrypted for storage on secstore, so even an administrator there would have difficulty reading them.

Yep. I'm thinking about that guy in the very first Unix systems that trojaned the C compiler to trojan itself to trojan the login program.

For those who don't know, that guy in the very first Unix was the Unix coinventor, Ken Thompson himself. He wrote about this Trojan horse (the most brilliant one in the history, I might add) in Communication of the ACM, Vol. 27, No. 8, August 1984 -- Reflections on Trusting Trust. Truely outstanding article.

Turns out you need an ACM subscriptiong to the link to the PDF above.
Ken Thompson has been kind enough to post a link to a free online version in the classics library at the ACM.