Slashdot Mirror

Don't get me wrong: those systems had their own share of problems, not the least of which was that they required expensive hardware to run well. They also lacked some of the niceties and safety check of modern programming languages (by which I mean languages like ML, not C++).

So, what can you do? Don't blindly use C/C++ for everything. Those languages have their place, but they require you to spend a lot of time on stuff that isn't related to getting the job done. Learn something new, and learn about the history of all this. Here are some suggestions:

• Learn about functional programming with Haskell and OCAML, and SML/NJ
• Learn about logic programming with one of the Prolog implementations.
• Read up on CommonLisp, Flavors, CLOS, and the Lisp Machine Window System. You can get CommonLisp implemenations at cons.org
• Read up on Scheme and get a Scheme programming environment. PLT Scheme looks pretty good.
• Read up on Smalltalk-80 and its programming environment (you can get a so-so Smalltalk-80 implementation at Squeak).

While those systems may or may not help you in your day-to-day work, they teach a lot about what programming can be.

For your day-to-day work, consider using languages and environments like Python, Perl, and Java. They aren't quite as convenient as the more academic systems I mention above, but they still let you focus much more on the problem rather than the mechanics of programming.

Have you ever wondered why C uses octal? Or why Unix (and therefore chmod(1)) takes octal numbers for permissions? It's because C and Unix were initially developed on 36-bit DEC machines. A 36-bit word has four 9-bit bytes, each represented by three octal digits.

According to a long list of computers, the PDP-7 was an 18-bit machine and the PDP-11 was 16 bits. Not mentioned on the list, the GE 635 had a 36-bit word.

Early history of Unix according to Ritchie.

Start with a 36 bit word and 18 bit addresses. Add sixteen "accumulator/index registers" and locate them at (octal) addresses 0..17 in main memory. Actually 16 GP registers is a decent complement, though being able to reference them as absolute memory locations is of dubious value.

Could be worse. 32 bit words are great for packing that limited 6 bit character set, once so popular in the DEC world: all the letters and numbers plus (IIRC) '$' and '.'. Two words give you 12 characters, more than enough for unique identifiers in any serious programming effort. "ASCII" then was generally a 7-bit "Half-Ascii" encoding to match up with most DEC unit record equipment at the time; 5 chars per word with a bit to spare. Imagine all the applications that were tempted to muck with that spare bit! Eight bit bytes were possible but not preferred because they wasted 4 bits in each word, but that led to the obvious solution: 9 bit character codes -- seven bits plus ESC and META, thus inevitably leading to EMACS.

Only thing that made this character endoding workable was the PDP10 had special so-called "byte" operations, where you could manipulate "byte" fields consisting of arbitrary bit ranges within a word. Further you could index bytes in packed arrays of such stuff.

On the plus side, the PDP10 was one of the first CISC minicomputers; it had a fairly complete instruction set, including a full complement of arithmetic and test operations, plus stack maniuplations and indirect addressing modes. This is probably why many early users loved it so -- it was the first mini where assembly language programming was NOT a royal pain in the ass.

On the other hand, the accepted wisdom these days is that nice, uniform RISC machines are a better match for compiler writers. Nevertheless, countless programmers devoted innumerable man years to compilers that tried to exploit every detail of the PDP10 instruction set.

In particular, The '10 had instructions to push and pop PC+status to/from a stack. However, there was no dedicated stack register. Rather the language designer presumably would designate one from the GP registers.

Further, the PDP10 retained traditional, non-reentrant "return jump" instructions, where the first word of your subroutine was overwritten with a jump to the point following the call. To return from sub you jump (perhaps indirectly) through address 0 in your subroutine. Although it makes re-entancy impossible (an infinite loop))this was a common mechanism in the old days. DEC10 Fortran compilers used this mode. Other languages used a variety of other calling conventions, though reentrancy and auto variables generally were a novel feature.

Of course, back in those days, 99% of computer cycles and programmer energy went to noble "systems" work. Programmers generally avoided working on ucky user applications.

Probably more than anything, the PDP-10 deserves credit for hosting a lot of the original development for the computer languages BLISS and BCPL, precursors to C [praise be to Ritchie].

For further reading, check out this PDP10 instruction reference in one try. Or read more about PDP10 History generally.

--JayBee [still waiting for a password]

The more usual literature on "namespaces" can be found discussed with The Use of Name Spaces in Plan 9. That's actually a quite useful/relevant thing that would represent a really cool thing to add to Linux in the future.

The critical extension is that rather than mount being associated with a "global" filesystem space, where all mounted FSes are associated with /etc/mtab it is associated with a particular hierarchy of processes.

Thus, my user ID might mount a DBM file via something analagous to mount -t dbm /home/cbbrowne/data/something.dbm /n/something ; that presents the DBM file in some sort of filesystem mode under /n/something . Unlike traditional mounting:

• It's a "private" mount, visible only to the process that did the mounting and its children;
• The mount doesn't require root access.

Alex Viro has occasionally commented on this being a potential neat thing to add to Linux; that's what would make "namespaces" really cool and useful; I don't see it happening 'til Linux 2.7, and it absolutely should not have anything to do with a particular filesystem implementation.

I've got some LaTeX sources, it's a mess though, that's why I haven't put it on the web. Anyway, why don't you install GSview on that windoze box?

Won't work. Not everyone wants to be a priest. Not everyone is brave enough to talk to the Goddess all by herself. Some people just want to linger at the edge of the Circle, or lean back in the pews, and let someone else do all the dirty work. They just want things to work without them having to think too much. As long as they can doubleclicky on the thingamabob and the spinner goes spinny and brings them the latest edition of Dilbert, everything's cool, everything's fine. They'd have no idea what to do with a hash prompt.

Now, this is not to say that a properly set up Be or *BSD or even (gasp) Linux won't do this just as well if not better than WinDoze. As long as they have someone like me to call when a power-out causes fsck to hang on boot-up.... but then how many folks actually install their own WinDoze?

Frankly, I think if any of the "new" OS's have a chance, other than the ones I mentioned above, it's Plan 9. If for no other reason than the rather serious amount of propellorhead power behind it... after all, we're talking about the same folks who dreamed up Unix in the first place, and the transistor before it. Never, ever underestimate the raw power of Ma Bell.

--
Open standards. Open source. Open minds.
The command line is the front line.

Know it.

Love it.

Contrast both SOAP and Corba to Styx/9P, the object protocol of Inferno and Plan 9, also available for other environments as a product which at least used to be called InfernoSpaces. It was available as Java classes and C libraries for several development environments.

See The Styx Architecture for Distributed Systems, Styx/9P-search on Google, a real life example of an interface to remote functionality, Styx manual pages, Inferno home and Plan 9 home.

Listing, naming and accessing of "remote objects" become trivial. Permanent and transient objects look the same, and just like regular files. Commands are usually issued as text content. So bindings to functions are language independent.

Optional authentication, data integrity and confidentility are built in, and can be configured at run time, transparent to the programmer.

There are some photos of MEMS mirrors at CalTech and Bell Labs, and page 90 of the January Scientific American.

As for Java vs. C++, well Java isn't a bad language, and having threading built in rather then slapped on as a bag on the side makes it nicer (pop quiz: what C++ facet operations are thread safe?). On the other hand I feel a bit limited in Java, and I miss the STL. As far as I know SPIN will help Java coders as well.

I don't think Solaris x86 is a good idea. If you want Solaris, get a SPARC. Otherwise you are always behind the support curve, and the hardware support is far more limited then Linuxes. Besides the SPARC hardware is extreamly reliable (if not all that fast), and works great for lights-out operations.

Inferno and Java comparison from your favorite Bell labs.

A news item that I got by just searching for inferno and java on google. I suggest you do the same.

How about this link? That URL comes incorrect when I post with Dec 7 nightly build of Mozilla. Remove the garbase after .html.

lots harder.
in plan 9, any old program can present a filesystem, and it can then interpret operations on that filesystem at will. basically, you can mount one end of a pipe. filesystem requests on any file or directory below the mountpoint turn into RPC messages down the pipe. so MIME mailboxes are presented as a filesystem, the editor cum window system acme allows program interaction through a filesystem, access to ftp is provided through a filesystem, etc, etc.

plan 9 doesn't have an ioctl call, which means that an enormous amount of functionality is available via straight shell commands (echo, cat, et al).

ok, so the ideas might not be completely new, but the implementation works really well in practise. and it means that a sophisticated system can be built out of small chunks of code, which in turn means that the whole system is more understandable and more reliable.

i can create windows with echo, look back through history with cd and extract parts of cpio archives with cat - and all of this functionality can be transparently exported and imported securely across the net.

tell me that's not pushing it further!

lots harder.
in plan 9, any old program can present a filesystem, and it can then interpret operations on that filesystem at will. basically, you can mount one end of a pipe. filesystem requests on any file or directory below the mountpoint turn into RPC messages down the pipe. so MIME mailboxes are presented as a filesystem, the editor cum window system acme allows program interaction through a filesystem, access to ftp is provided through a filesystem, etc, etc.

plan 9 doesn't have an ioctl call, which means that an enormous amount of functionality is available via straight shell commands (echo, cat, et al).

ok, so the ideas might not be completely new, but the implementation works really well in practise. and it means that a sophisticated system can be built out of small chunks of code, which in turn means that the whole system is more understandable and more reliable.

i can create windows with echo, look back through history with cd and extract parts of cpio archives with cat - and all of this functionality can be transparently exported and imported securely across the net.

tell me that's not pushing it further!

lots harder.
in plan 9, any old program can present a filesystem, and it can then interpret operations on that filesystem at will. basically, you can mount one end of a pipe. filesystem requests on any file or directory below the mountpoint turn into RPC messages down the pipe. so MIME mailboxes are presented as a filesystem, the editor cum window system acme allows program interaction through a filesystem, access to ftp is provided through a filesystem, etc, etc.

plan 9 doesn't have an ioctl call, which means that an enormous amount of functionality is available via straight shell commands (echo, cat, et al).

ok, so the ideas might not be completely new, but the implementation works really well in practise. and it means that a sophisticated system can be built out of small chunks of code, which in turn means that the whole system is more understandable and more reliable.

i can create windows with echo, look back through history with cd and extract parts of cpio archives with cat - and all of this functionality can be transparently exported and imported securely across the net.

tell me that's not pushing it further!

lots harder.
in plan 9, any old program can present a filesystem, and it can then interpret operations on that filesystem at will. basically, you can mount one end of a pipe. filesystem requests on any file or directory below the mountpoint turn into RPC messages down the pipe. so MIME mailboxes are presented as a filesystem, the editor cum window system acme allows program interaction through a filesystem, access to ftp is provided through a filesystem, etc, etc.

plan 9 doesn't have an ioctl call, which means that an enormous amount of functionality is available via straight shell commands (echo, cat, et al).

ok, so the ideas might not be completely new, but the implementation works really well in practise. and it means that a sophisticated system can be built out of small chunks of code, which in turn means that the whole system is more understandable and more reliable.

i can create windows with echo, look back through history with cd and extract parts of cpio archives with cat - and all of this functionality can be transparently exported and imported securely across the net.

tell me that's not pushing it further!

Ken Thompson isn't the only gray-beard to move away from Bell Labs this year. Just last summer, Brian Kernighan, who wrote The C Programming Language with Dennis Ritchie and The UNIX Programming Environment with Rob Pike, left full time work there for a professorship at Princeton.

I've never seen what he looks like, but I'm guessing the Unix engineer is the heavy-set bald guy with a bushy beard.

I've never seen what he looks like, but I'm guessing the Unix engineer is the heavy-set bald guy with a bushy beard.

Linux, I am your father.

Take a look at where he writes about his trip to moscow to fly the MIG 29 and L 39 trainers.

Oh yeah, so long Ken. You've done great things that helped a lot of people get through their day.

i disagree. the java socket interface is not abstracted enough. it's still tied to TCP/IP. plan 9 and inferno have the cleanest networking interface i've seen.

want to make a connection?

connection := sys->dial("tcp!slashdot.org!httpd");

that's all! the address is a string with a protocol explicitly mentioned, so can easily be passed in dynamically as an argument. the program itself is protocol independent. if i had an ATM interface, i could use "atm!someATMaddress!56446" and the program would continue to work unchanged. IPV6? no problem, just change the underlying implementation...

not to mention the fact that access is through a filesystem-like abstraction - the actual network interface might not even be on the local machine...

of course, i'm completely biased, as i work for the company (Vita Nuova) that distributes it. it's not as bad as it might seem though, because the only reason i went for this job was that i'd already fallen in love with the language! but seriously, Limbo is a truly excellent language which, like Java, takes much of its heritage from C but, unlike Java, gets the fundamental language design right.

i know that Java is here to stay, but if you've done much Java programming, you'll know that there are reasons why you might want to keep an eye on alternatives. Limbo is a language that C programmers will like but C++ programmers will probably hate. there's no object-hierarchy! so you actually know what code is being invoked by a function call. debugging code does not require an intimate knowledge of obscure class hierarchies.

o it's completely type-safe. unlike java, it's impossible to get a run-time type exception.
o the syntax is very readable, but terse enough not to frustrate a C programmer...
o the type system is rich enough to make data-structures easy to create and manipulate, and the type syntax is beautifully clear. consider:
x: list of array of (string, int);
o memory management is automatic (garbage collected) but unlike most other GC languages, memory usage is economical and predictable, because almost all data structures are collected by reference counting. so when memory is tight, you have tight control on what memory is allocated, and when it's freed.
o and best of all, programs written in Limbo are completely portable, because they're surrounded by an entire virtual operating system, Inferno.

i could rant on for ages about nice aspects of the system, which is not surprising, given the people involved in its creation (Rob Pike and Dennis Ritchie amongst others).

anyway, we've had a free download available for some time, but our resident Windows-head has just come up with an Internet Explorer plug-in that runs Inferno inside a web page. the download is under 720K.

we've had fun coming up with a few demo programs so you can see how it performs compared to Java and what a typical Limbo program looks like. you can even even get a shell prompt inside IE. (not that you can do a lot from it, as it's sandboxed...).

have fun! and bear in mind that the binaries of these programs will run unchanged under any incarnation of inferno... the "applet" API is identical to the normal one.

i hope that at least some people will Get It...

cheers, rog.
PS. i'm sorry we don't have a linux or netscape version, but we will have!

of course, i'm completely biased, as i work for the company (Vita Nuova) that distributes it. it's not as bad as it might seem though, because the only reason i went for this job was that i'd already fallen in love with the language! but seriously, Limbo is a truly excellent language which, like Java, takes much of its heritage from C but, unlike Java, gets the fundamental language design right.

i know that Java is here to stay, but if you've done much Java programming, you'll know that there are reasons why you might want to keep an eye on alternatives. Limbo is a language that C programmers will like but C++ programmers will probably hate. there's no object-hierarchy! so you actually know what code is being invoked by a function call. debugging code does not require an intimate knowledge of obscure class hierarchies.

o it's completely type-safe. unlike java, it's impossible to get a run-time type exception.
o the syntax is very readable, but terse enough not to frustrate a C programmer...
o the type system is rich enough to make data-structures easy to create and manipulate, and the type syntax is beautifully clear. consider:
x: list of array of (string, int);
o memory management is automatic (garbage collected) but unlike most other GC languages, memory usage is economical and predictable, because almost all data structures are collected by reference counting. so when memory is tight, you have tight control on what memory is allocated, and when it's freed.
o and best of all, programs written in Limbo are completely portable, because they're surrounded by an entire virtual operating system, Inferno.

i could rant on for ages about nice aspects of the system, which is not surprising, given the people involved in its creation (Rob Pike and Dennis Ritchie amongst others).

anyway, we've had a free download available for some time, but our resident Windows-head has just come up with an Internet Explorer plug-in that runs Inferno inside a web page. the download is under 720K.

we've had fun coming up with a few demo programs so you can see how it performs compared to Java and what a typical Limbo program looks like. you can even even get a shell prompt inside IE. (not that you can do a lot from it, as it's sandboxed...).

have fun! and bear in mind that the binaries of these programs will run unchanged under any incarnation of inferno... the "applet" API is identical to the normal one.

i hope that at least some people will Get It...

cheers, rog.
PS. i'm sorry we don't have a linux or netscape version, but we will have!

The software at that link is System V Release 2, and as far as I know there is no way to get that legally for free. You can get current System V Release 4 for free (depending on how you plan to use it) from places like SCO and Sun.

SysVR2 is about 15 years too late to be "original Unix", though. You can get binary versions of much earlier systems -- Fifth, Sixth, and Seventh Edition research Unix -- free for personal use, with Supnik's simulator at DEC's ftp site.

If you want to get early Unix source, and some versions other than those above, you can get a suitable Unix source license for free from SCO.

For information on early Unix, you could start with The UNIX Heritage Society, or perhaps Dennis Ritchie's home page.

...it was not well into 1970 that Brian Kernighan suggested the name 'Unix,' in a somewhat treacherous pun on 'Multics'...

two points of criticism. first, the article itself is pretty minimal in the context it provides. it doesn't talk about what went on before or after, nor what was going on at the same time. still some good information, but nothing to get worked up over.
second, the actual work described wasn't as revolutionary as people here are saying. very good, to be sure, but the really revolutionary stuff came when the idea made its way into other people's hands, and other systems. try to imagine a shell without pipes or even IO redirection. the shell, as it first existed, was mostly an evolution of batch processing. a big improvement, to be sure, but just evolution. the really interesting stuff showed up with the Unix shell, at the hands of Thompson, Ritchie, and a few others.
see this paper by Dennis Ritchie, particularly the sections on process control, IO redirection, and (most especially) pipes for some really revolutionary developments in the history of the shell.

Great site! I have this(it's not goatsex!) picture from that page taped to the back of my monitor. Folks who stop by to visit look at it rather oddly and with a blank look in their eye. When I tell them what it's about, they just nod and walk away :)

If you're impatient, you can check out DMR's webpage.

He's got a ton of stuff on the old days of Unix, C, etc.
Thus sprach DrQu+xum, SID=218745.

... learn Common Lisp. Seriously. XML is really just S-expressions (in drag, with redundant, overblown syntax - see here; (sorry about the pdf)), so why not use a language designed for munging them?

Perl and XML don't really get along well, primarily because Perl and arbitrarily nested data structures don't really get along well (see here if you want a less biased, but still discouraging opinion).

Strangely enough, Java and XML aren't getting along as well as one would think, if this article on the JDOM project is any indication. Java also has the shifting sands problem - vendor-controlled standards are evil, no matter who the vendor is.

Common Lisp has an ANSI standard that hasn't changed since 1995, open-source multi-threaded web servers that you can add native code to on the fly (see AllegroServe or CL-HTTP) and a lot of other good stuff that I don't have time to list here.

And if you think you want to be self-sufficient, dig up an old copy of "Spacehounds of IPC", where the hero has to do things such as build a generator by smelting copper, building a wire-pulling machine, manufacture electrical insulation, making bearings, inventing a lubricant, building a coil-winding machine, then building the generator... [Thanks to the Web, I see that this book is Reference 21 in "Interprocess Communication in the Ninth Edition Unix System"]

..use tags that say what the information is, not what it looks like...

The ability to capture and transmit semantic and structural data made possible by XML ...

Computers, of course, are not that smart; they need to be told exactly what things are, how they are related and how to deal with them. Extensible Markup Language (XML for short) is a new language designed to do just that, to make information self-describing.

So is there some steak among all of this sizzle?

(And yes, I'm well aware of the fact that CORBA is brain damaged as well.)

..use tags that say what the information is, not what it looks like...

The ability to capture and transmit semantic and structural data made possible by XML ...

Computers, of course, are not that smart; they need to be told exactly what things are, how they are related and how to deal with them. Extensible Markup Language (XML for short) is a new language designed to do just that, to make information self-describing.

So is there some steak among all of this sizzle?

(And yes, I'm well aware of the fact that CORBA is brain damaged as well.)

There is a similar project in the Internet Mapping Project, whcih some of you may remember. It has been going on for a while. Other interesting mapping and visualization projects are at The Stillman Projects and C5's 1:1.

Actually, generic programming does exist for Java, it just hasn't been officially incorporated yet. Generic Java

He's right. Learning some things will definitely help the way you think about things. The incredibly strong typing of something like pascal will definitely kick your *ss if you've been doing nothing but C for a while, and I think that's actually a Good Thing. Learning Eiffel if you already know smalltalk is a very different experience.

Even something like Algol will probably change your views and get you closer to the hardware in many respects (not that you can get Algol to run on most machines anymore....;-)

What about Ada? Programming by Contract really will teach you something serious about how you actually interact with the rest of your application, and while you'll curse it ("I KNOW what I'm trying to do and it's correct, dammit!") you'll be happier for learning it. Older, but happier.

And as long as the languages keep coming, there'll pretty much never be a chance to really run out.

My list would include:

• C
• C++
• Pascal& lt;/a>
• Lisp (anything but eLisp)
• Python
• Perl
• Smalltalk
• ML
• prolog&l t;/a>
• Eiffel
• Ada
• a RISC Assembler
• Cobol (those who do not learn from history are doomed to repeat it)
• Java
• BASIC (the non-Visual kind).

As for the performance degradation that the -kernel architecture imposes on the system, there has been quite a lot of research in the last ten years indicating that this effect can be alleviated. Moreover, much of the performance degradation due to the added number of context switches in -kernel systems is due to inneficient/inapropriate hardware mechanisms and design. By harnessing state of the art hardware design (e.g., IA-64), we may come to see that the added overhead of context switches is ignorable. There is work underway to create efficient -kernels for these more arcane architectures, and only time will tell whether our hopes can be reached or not.

Also, -kernel technology is believed to pose a compelling soultion to the one-size-fits-all problem that you address in conjunction with Linux. To put it short, one would compile the operating system components so that they match the exact requirements that you meet in, e.g., pervasive computing or big irons. In fact, IBM is doing joint research with a number of universities aiming at providing a multiserver version of Linux - SawMill Linux - with these exact goals in mind. This work may of course fail (that's the beauty of research), but I think it is a bit early yet to put the last nail in the coffin for multiserver operating systems.

And just for the records: SawMill is hopefully going GPL any time soon now, enabling people to use it with the GPLed Fiasco or newly developed L4Ka -kernels. (That should probably make you GPL zealots happy. ;-)

"organic" chemicals are not chemicals made by mother nature & sold in your health food store. they're not bacteria or any other biological system, including proteins. organic chemicals are exactly what the topic said : carbon based molecules. anything made of solely carbon, nitrogen, oxygen & hydrogen is generally considered organic. this would be as opposed to inorganic chemicals which contain metals, non-metals (like silicon) or either of the lanthanides or actinides.

when this article refers to organic chemicals it means stuff made in a lab by chemists & includes, as was mentioned previously, polymers, plastics etc.

the reason these systems are so interesting is their versatility. bell labs, uh sorry, lucent scientists recently showed some really neat behaviour in the anthracene/tetracene family (as in mothballs) including lasing (albeit at low temperatures, but you've got to cool most lasers anyways) & superconductivity. they've managed to build field-effect transistors out of single crystals of pentacene. all very cool stuff & some of it came out recently in either PRL or nature, ok now i can tell you it's science. if you do an authour search for batlogg you'll get a chronological list of what they've been up to. i will attempt to link the search results here (fingers crossed). you should be able to read the abstracts at least.

hope this clears up why organic chemicals have nothing to do with the organic world & why the NY times is so excited about organics.

chris

"organic" chemicals are not chemicals made by mother nature & sold in your health food store. they're not bacteria or any other biological system, including proteins. organic chemicals are exactly what the topic said : carbon based molecules. anything made of solely carbon, nitrogen, oxygen & hydrogen is generally considered organic. this would be as opposed to inorganic chemicals which contain metals, non-metals (like silicon) or either of the lanthanides or actinides.

when this article refers to organic chemicals it means stuff made in a lab by chemists & includes, as was mentioned previously, polymers, plastics etc.

the reason these systems are so interesting is their versatility. bell labs, uh sorry, lucent scientists recently showed some really neat behaviour in the anthracene/tetracene family (as in mothballs) including lasing (albeit at low temperatures, but you've got to cool most lasers anyways) & superconductivity. they've managed to build field-effect transistors out of single crystals of pentacene. all very cool stuff & some of it came out recently in either PRL or nature, ok now i can tell you it's science. if you do an authour search for batlogg you'll get a chronological list of what they've been up to. i will attempt to link the search results here (fingers crossed). you should be able to read the abstracts at least.

hope this clears up why organic chemicals have nothing to do with the organic world & why the NY times is so excited about organics.

chris

• You can either "mount" the resultant FS publicly, so that anyone on your system can see it, or
• Each and every program that wants to go after encrypted data needs to individually explicitly include cryptographic support to read keys and access/update encrypted data.

As is nicely outlined here , the Plan 9 operating system provides the ability to do this Another Way, using the concept of namespaces. The basic idea is that the "file tree" is no longer a global thing, but is, instead, localized to processes.

In effect, I might, from my shell, run the command:

mount -t crypto /home/cbbrowne/encrypted-stuff /mounts/plaintext

This results in the encrypted stuff in my home area getting attached to the file tree under /mounts/plaintext

The two clever things about this are that:

• /mounts/plaintext is visible to the shell that invoked the mount, as well as to its children.
• /mounts/plaintext is not visible to any other processes.

  Entertainingly, perhaps not even to root.

Why should this be considered relevant to Linux? Because there has been considerable discussion of namespaces in relation to the Linux kernel. It won't be in 2.4, but it's the sort of thing Alex Viro is liable to consider experimenting with in 2.5 or some such version.

Oh, and as a bonus, they take the kids on a free plane ride one afternoon (one of the planes being flown by Thompson).

Indeed. No computer can say "Mosht things in here don't react too well with bulletsh." like he can.
Bell Labs doesn't even have a Russian accent option.

Great book, possibly the best, on what makes software development organizations work: Peopleware by DeMarco and Lister. (Link is to Fatbrain, but everyone carries it.) Possibly the most relevant to your new position: the list of ten things you can do to prevent teams from forming. (There's nothing you can do to make teams form, but lots you can do to prevent them.)

Other good reads: Jim Coplien's organization patterns (don't worry about the word "process," Cope doesn't believe that process generates quality), also found in the first PLoP book; DeMarco's The Deadline: A Novel About Project Management ; maybe Jerry Weinberg's The Psychology of Computer Programming ; and (as others have suggested) many books by Steve McConnell.

All these boil down to one thing: You can't do it all. (If you can, you don't need to manage anyone.-) 99.44% of your success will depend on the success of the people who report to you. 99.44% of your job means making sure they're excited, hard working, and pointed in the right direction.

That's how to make this change. Here's why you might consider it.

The best managers (and former managers) I know decided the most important thing about an organization's success was about how the organization worked, not how they as individuals could contribute. They either expressed interest in that, or made an impact without being asked. (The latter is how I got promoted to management in my last job. No one in my group was sure if I was their boss or not. I was happy with the ambiguity. My boss wasn't, so he promoted me.)

You can go home again. When I changed companies (the old company rolled the dice on a new technology and lost), the new position was purely technical, and I'm still there and still happy there. Smart companies will let you "step down" in place, somehow preventing it from being a demotion. Dumb companies aren't worth staying at anyway.

Don't do it unless you really want it. Don't do it unless you can make more of a difference where you're pointed than where you are now. (But don't let fear hold you back.) If your boss says you have no choice ... remember how many choices you really have. --PSRC

Great book, possibly the best, on what makes software development organizations work: Peopleware by DeMarco and Lister. (Link is to Fatbrain, but everyone carries it.) Possibly the most relevant to your new position: the list of ten things you can do to prevent teams from forming. (There's nothing you can do to make teams form, but lots you can do to prevent them.)

Other good reads: Jim Coplien's organization patterns (don't worry about the word "process," Cope doesn't believe that process generates quality), also found in the first PLoP book; DeMarco's The Deadline: A Novel About Project Management ; maybe Jerry Weinberg's The Psychology of Computer Programming ; and (as others have suggested) many books by Steve McConnell.

All these boil down to one thing: You can't do it all. (If you can, you don't need to manage anyone.-) 99.44% of your success will depend on the success of the people who report to you. 99.44% of your job means making sure they're excited, hard working, and pointed in the right direction.

That's how to make this change. Here's why you might consider it.

The best managers (and former managers) I know decided the most important thing about an organization's success was about how the organization worked, not how they as individuals could contribute. They either expressed interest in that, or made an impact without being asked. (The latter is how I got promoted to management in my last job. No one in my group was sure if I was their boss or not. I was happy with the ambiguity. My boss wasn't, so he promoted me.)

You can go home again. When I changed companies (the old company rolled the dice on a new technology and lost), the new position was purely technical, and I'm still there and still happy there. Smart companies will let you "step down" in place, somehow preventing it from being a demotion. Dumb companies aren't worth staying at anyway.

Don't do it unless you really want it. Don't do it unless you can make more of a difference where you're pointed than where you are now. (But don't let fear hold you back.) If your boss says you have no choice ... remember how many choices you really have. --PSRC

Lov Grover, who proposed the theory, has a website with links to his publicatiions.

I couldn't figure out from the abstracts which paper EE Times was referring to.

There's no bug in the system (if by system you mean Python). There are multiple postings pointing out that

• from os import * is a Bad Thing(TM). I suppose that the fact it's allowed at all could be considered a bad feature of the language, but it does exactly what it's advertised as doing, so it's not a bug.
• open requires the full path, which you're not giving it.

It's worth remembering that on the overwhelming majority of occasions, when you think you've found a bug in the language/compiler/whatever, you just don't understand your program well enough (Kernighan and Pike say this in the chapter on Debugging in The Practice of Programming).

(Now everyone will reply with anecdotes about finding compiler bugs...)

http://www.cs.bell-labs.com/who/dmr/ index.html

I'm a little karma-whore, short and stout...

The funny thing is, I can't find any papers on their sites (nor at Secure Systems Research Department) at bell labs

The funny thing is, I can't find any papers on their sites (nor at Secure Systems Research Department) at bell labs

The funny thing is, I can't find any papers on their sites (nor at Secure Systems Research Department) at bell labs

The funny thing is, I can't find any papers on their sites (nor at Secure Systems Research Department) at bell labs