Slashdot Mirror

There are various bits of UNIX (and I include Linux here, as it's essentially a UNIX clone) that have been bolted on without regard for the elegance of the whole system. In particular, graphics, pseudo terminals and networking were all added late in UNIX's lifetime and considerably clutter the system and limit its capabilities.

Take the ubiquitous psueudo terminals as an example. Almost nobody actually uses a genuine VT220 (or whatever) as their input device. However, the output from every command-line program in UNIX goes through something that pretends to be such a device. The kernel has much elaborate stuff (the tty driver) built in to convince command line programs that they're talking to a real terminal. The kernel knows about command line editing, it knows how to print control characters nicely, and it knows what key means "word erase".

This is all crap! It adds unnecessary complexity to the kernel, and not only that, but every command line program that wants a a slightly more sophisticated interface (e.g. cursor-based editing) has to do it itself (c.f. GNU readline). This not only bloats the kernel and many of its applications, it also means that the commands are less versatile than they could be (requiring people to use tools like expect to demangle their output).

Under Plan 9, there are no special system calls devoted to terminals or networking: instead, the interface to device drivers is made more versatile (all you need is open, read and write to access a device driver, no fancy ioctls or fcntls required. This gets back to the original purity of the 7th Edition programming interface: programs are a joy to write, and once written can be put to many more uses, as the currency of command line programs (text written to stdin/stdout) is also the currency of device drivers.

Because everything is unified under one hood (the name space), I don't have to write a special program to get fancy functionality. Want to find out what programs have a particular file open?
grep filename /proc/*/fd
Plan 9 is all about the joys of writing less code, more cleanly, and finding it more useful when written; of having a box of tools that can be plugged together in a multitude of different ways, transparently and securely across networks; of having a clean user interface that is concerned principally with power and simplicity rather than appearance.

Of course in this day and age, when a word processor takes >2,000,000 lines of code and "features" are rated more highly than overall usability, it's not surprising that Plan 9 isn't that well known, or that Dennis Ritchie reverts to Windows NT in order to browse the web.

As for myself, I'll stick to Plan 9's (and Inferno's) deep joy for as long as I possibly can!

We do not plan that the C language be bootstrapped by means of a simple interpreter of an intermediate language; instead an acceptably efficient code generator must be written. The compiler will indeed be designed carefully so as to make changes easy, but for each new machine it will inevitably demand considerable skill even to decide on data representations and run-time conventions, let alone code sequences to be produced.

OK, maybe it's not exactly the same concept, but I still found it rather interesting...

Compiler geeks: flame away!

Yes, indeed. See the Plan9 FAQfrom comp.os.plan9.

Plan 9 is supposed to correct what's wrong with the development Unix after Unix was "embrace and extended" by the Unix commercial vendors.

I used Plan 9 for about 9 months back in 1996. Here are some of the ideas behind it.

Everything in the system are files: This was a simple notion but powerful abstraction. Everything in the system is access through the file system API and all objects in the system have a representation in the file systems including low level network and graphics.

A per process private file name system: Plan 9 has the notion of a private file name space for each process. That means that I can create file system namespace on a individual process level.

A file system base network protocol call 9P All network services for Plan 9 are export as files to another machine.

A single sign on authentication system This has been featured a while ago. Check it out here

With these simple abstraction, you can do really cool things:

• Recursive windowing system: the framebuffer of the systme is mounted at /dev/graph (or similar name. It was a while ago). Since one can build private name space for each process, just open up a new windows, mount its graphic context at the /dev/graph and launch another copy of the windowing system in the process. The new windowing system will think the windows as the whole screen. Comes pretty handy hacking windowing system.
• Build firewall through remote file system. Say you have a machine that's on the edge with two ethernet cards and no routing enable between the two interfaces. Bascially a firewall. You can gain remote access by login into the machine, mount its /dev/eth0 to your current process's /dev/eth0 and launch browser in the process. Now, you are browsing using the firewall's external interface. This is done securely because of the private name space and single sign on. You are the only one open to the outside. The configuration of this firewall is "local" to you.

Build upon this and taking the Unix Small is Beautiful approach to problem solving. Plan 9 allows each program to perform small tasks well and provide the way to unified them together through private file name space.

Plan 9's design has a lot of impact on Linux, probably more then Linus would admit. /proc file system, process as thread, and others. These abstract can be traced back to Plan 9. Seeing those implementation on Linux (a traditional Unix clone), it become evidenced why original Unix folks like Dennis Richite wanted to start a new project to correct the mistakes of Unix. ;)

Plan 9 From Bell Labs is the Plan 9 manifesto. Good overview into the system and the rest of the documents.

Plan 9 is supposed to correct what's wrong with the development Unix after Unix was "embrace and extended" by the Unix commercial vendors.

I used Plan 9 for about 9 months back in 1996. Here are some of the ideas behind it.

Everything in the system are files: This was a simple notion but powerful abstraction. Everything in the system is access through the file system API and all objects in the system have a representation in the file systems including low level network and graphics.

A per process private file name system: Plan 9 has the notion of a private file name space for each process. That means that I can create file system namespace on a individual process level.

A file system base network protocol call 9P All network services for Plan 9 are export as files to another machine.

A single sign on authentication system This has been featured a while ago. Check it out here

With these simple abstraction, you can do really cool things:

• Recursive windowing system: the framebuffer of the systme is mounted at /dev/graph (or similar name. It was a while ago). Since one can build private name space for each process, just open up a new windows, mount its graphic context at the /dev/graph and launch another copy of the windowing system in the process. The new windowing system will think the windows as the whole screen. Comes pretty handy hacking windowing system.
• Build firewall through remote file system. Say you have a machine that's on the edge with two ethernet cards and no routing enable between the two interfaces. Bascially a firewall. You can gain remote access by login into the machine, mount its /dev/eth0 to your current process's /dev/eth0 and launch browser in the process. Now, you are browsing using the firewall's external interface. This is done securely because of the private name space and single sign on. You are the only one open to the outside. The configuration of this firewall is "local" to you.

Build upon this and taking the Unix Small is Beautiful approach to problem solving. Plan 9 allows each program to perform small tasks well and provide the way to unified them together through private file name space.

Plan 9's design has a lot of impact on Linux, probably more then Linus would admit. /proc file system, process as thread, and others. These abstract can be traced back to Plan 9. Seeing those implementation on Linux (a traditional Unix clone), it become evidenced why original Unix folks like Dennis Richite wanted to start a new project to correct the mistakes of Unix. ;)

Plan 9 From Bell Labs is the Plan 9 manifesto. Good overview into the system and the rest of the documents.

not easy to summarise

try reading the papers

user level file systems :
Instead of having one protocol for interrogating the disks, one for the network etc. plan9 uses the 9p protocol. In this way the physical devices are abstracted and one can use a single set of tools to inspect them. It taes the concept of Everything is a file to it's logical conclusion.
Want to know where the mouse is : cat /dev/mouse

Get slashdot homepage using the shell :

conn = `{cat /net/tcp/clone} # ( `{} is like bash's `` )

<[4] $conn { # keeps it open
echo 'connect slashdot.org!80' > /net/tcp/$conn/ctl
echo 'GET http://slashdot.org/ HTTP/1.0' > /net/tcp/$conn/data
cat /net/tcp/$conn/data
}

I wrote an irc bot as an exercise in rc. It dangerously executes given commands and returns the results

There are also other great technologies.
Incremental backups are built in.
Acme is an interactive editor that does all sorts of interesting things.

The plumber - forget file associations. The plumber uses regular expressions and executes whatever commands you would like it to for a set of given strings. So if you see http://slashdot.org in ANY piece of on-screen text, right click and select plumb and it will open it. [hehe not it plan9's web browser - that is one area seriously lacking.

The really sad part is that Lucent's financial troubles means that people have been shed from Bell-Labs. No-one is being paid to maintain plan9 any more. The heroes remaining and some outside [Rob Pike, Russ Cox, Dave Pressotto, C H Forsyth, et. al.] are doing it in their own time. And doing a great job.

I could go on but I need to leave the house. [that always seems to be the case when plan9 gets mentioned here!]

Has anybody else taken a look at his other lives ?

LMAO at his disclaimer about Stale Urine .

Has anybody else taken a look at his other lives?

I was laughing when I read the one in Brazil.

She has some great stuff. Her comics and drawings used to run in R.Crumb's "Weirdo" back in the 80's, and she's since come out with many of her own comics, including "Grit Bath", to name one of to several.

I was just cruising through her site, and came across this really weird rabbit. There's other great stuff there.. check it out. Her stuff is definitely 'from outer space' ;)

I dig surreal black+white illustrations myself; have some of my own work posted here and here.

--naked

Please support his OS - Plan 9. If you won't do it for the geeky sake, please..do it for Glenda!

"already has libraries written" = "someone else had to write it". That tells nothing about how difficult it was.

I could similarly say that "Quicksort can be implemented as 2 lines of C code (because a library's already written)".

Besides, Erlang isn't really a purely functional language. Well, "pure functional" languages hardly ever amount to more than academic toys, but there are other languages that come a lot closer.

Here's a one line Erlang program:
hello() -> io:fwrite("hello\n").

See that "fwrite"? It means "write to the file called io". Telling the computer to do something- that's imperative.

Here's the equivalent in ML:
val it = "hello" : string
The criticial distinction here is that there's no verb-equivalent. In a functional style, everything is either a statement of fact- standalone like a noun (constant), or relative to another like an adjective (function). ML isn't purely functional either, but it looks closer.

Of course, any useful language can be used for programming in either imperative or functional styles (with some small additional awkwardness). Take the QuickSort example someone gave. Even though they're called "imperative" languages, developers working in C++, Java, or Perl would tend to implement something that directly follows the functional outline.

(Note that some academics will say that the criticial distinction of a functional language is that functions are treated as first-class objects. "functional vs non-functional". I'm using the simpler definition- functions as per math functions- which treats the distinction as "functional vs imperative")

Nintendo uses Lisp for game programming, maybe even Mario64.

Of course I haven't seen the code, but if they're at all like most game developers, Mario64 isn't written in Lisp- it is C and assembler. "Behaviors of monsters inside the game" may be in Lisp, that's a fairly common approach. But not "the game" itself. Things like "load the texture resources from disk, calculate normals for polygonal models, run a 40hz event loop on gamepad input"... they're just too hard to describe functionally.

... be that as it may, it's not the only dark cloud. Here are three more that, each in its own way, address some of the issues raised by Mr. Lanier:

Cloud 1: Information

Let's go back to the middle of the 20th century, to a very brilliant, first generation of serious hackers that included people like Alan Turing, John von Neumann, and Claude Shannon. Their primary source of coding experience involved coding information that could be sent over a wire. - J. Lanier

Claude Shannon, in his paper A Mathematical Theory of Communication (PDF version) begins with the oft forgotten statement that, and I'm paraphrasing here (badly), of course he doesn't really mean "information" as that would imply a whole host of semantic issues he doesn't need to deal with but, what the heck, it's a nice word.

It's certainly an interesting word, but when it comes to what can be stored and/or transmitted, it's the wrong word. That Shannon used it and no one seems to mind speaks volumes about the "programmer's mindset" in the past 50 years and goes a long way towards explaining why GOFAI (good old fashioned AI) has failed so completely.

Information is a phenomenological experience of the mind's response to stimuli. You may find what you're reading here informative, but that does not mean this arrangement of dark and light pixels on your screen is information or that, when I posted this message, information was transmitted. The illusion of information is very real, so real that it makes it difficult to see that behind it is a mind doing some incredibly complex processing and that without mind, there is no information.

The illusion of information is borne on the wings of assumption. Call this a message or posting or whatever, but it is really a designed encoding of data, its design intended to evoke particular responses and guided by my assumption that you read and can comprehend English (one of many assumptions). We are so adept at language that most of what goes on when we speak and listen (or write and read) goes on below the level of consciousness. It takes effort to see that the illusion of information requires mind and even more effort to see that mind requires society (i.e., that minds are social -- they require the shared conventions and knowledge represented by the society they are immersed in).

Anyone who's written even a simple program has experienced the "absence of mind" in the wonderful world of Information Processing/Technology. Without mind, programs are required to simulate particular mind-like functions in order to simulate "information." We state or assume conventions and knowledge (e.g., protocols) in some subroutine so it can "think" about the "information" passed to it. We spend an inordinate amount of effort and time trying to design and follow conventions in our programs. In the "human interface" areas of our programs we expend even more effort trying to get the "stupid" user to supply information according to the conventions our programs are expecting and to decorate (format) information for human consumption.

To the extent that the knowledge and conventions within a program are complete and consistent, the current "art of programming" works surprisingly well. The larger the program, the more difficult the completeness and consistency becomes and the more dangerous the fallacy that information is storable and transmittable becomes. It becomes too easy for a programmer to assume that "information" produced or consumed by some subroutine they're working on is, and will remain informative. One can easily imagine someone at NASA working on a subroutine that transmits thrust information to a spacecraft. Would they ever imagine that what they have encoded in Pounds will be interpreted by another subroutine in Newtons if they believe their subroutine actually transmits the information? (Not that anything like this would really happen, of course.)

Cloud 2: System Boundaries

We need a system in which errors are more often proportional to the source of the error. - J. Lanier

How do we know what is and isn't part of a system? We look outside and see a car, a tree, a person. The tree has a root system. The car has a brake system and an exhaust system. The person has a cardiovascular system. And yet, the best definition I have for a "system membership function" is: Anything that affects and is a affected by a system is part of that system.

A little thought in that direction will get you to the conclusion that it's pretty much all one system and everything we deal with is a subsystem. We haven't evolved to look at the world this way. In fact, we try not to as such a holistic view is far too complex. We'd be stuck in analysis paralysis before we ever got started. We have a tendency to begin with the smallest version of "system" we can get by with and expand its domain only when it's the only way to accommodate some "outside" fact.

In my experience with programming (and technology, in general), the "source of the error" is frequently outside of the "system" we thought we were dealing with. It's not unusual to find that the destination of the error is outside of the "system" we thought we were dealing with, as well. Programmers are all very aware of the effects of system boundary errors (although most would not recognize them as such). These errors manifest themselves in usually annoying, and sometimes frustrating problems. But the consequences can be far more devastating.

In December of 1996, The Bright Field (a 763-foot freighter loaded with 56,380 long tons of corn) was positioning itself to navigate a turn in the Mississippi River when a primary oil pump failed. Automation software detected the failure and attempted to start a secondary oil pump but it wouldn't start so the automation shut down the engine. When viewed from the perspective of the "engine system," the automation behaved in a perfectly reasonable manner (and had this occurred on the open sea, everyone would congratulate the automation designers for a job well done). But if you jump up a level you see that shutting off the engine makes it impossible to steer or stop the "ship system." Jump up another level and on that day in December you see that you now have an extremely heavy ship drifting straight towards a New Orleans wharf. (The crew was able to finally get the engine started but not in time to stop the ship. It destroyed 200 feet of dock, tore the front off of a hotel and shopping mall and injured 116 people.)

Cloud 3: Complexity

If you look at other things that people build, like oil refineries, or commercial aircraft, we can deal with complexity much more effectively than we can with software. - J. Lanier

Note: I assume (and hope) Mr. Lanier meant: "we can deal with their complexity much more effectively than we can with software's."

There is a hint in Mr. Lanier's comment of the belief that complexity is somehow undesirable or problematic. In common usage, complexity seems to share some of the semantic space occupied by complicated. Let complicated handle all things messy, difficult and hard to use. Complexity is about connections (physical, social, ideological, ...) between things and it is the source of power in anything we think productive or capable of fending off entropy.

Having lived near an oil refinery that blew up I have my doubts about our ability to deal with their complexity, and no one needs reminding of what commercial aircraft are capable of. You may be tempted to come to Mr. Lanier's defense here, stating that this isn't exactly the kind of "dealing with" he meant. To which I would reply: yes I know, but that's exactly why complexity seems like such a problem, often times in very surprising ways.

People, it seems, like to forget that: a) complexity is no less productive just because we didn't intend to create it, and b) complexity is not constrained in any way by our good intentions. Programmers are also fond of thinking of their code as something that simplifies things, but new software always increases the complexity of the system. In fact, when it comes to adding complexity, nothing is faster or easier than software (and this is most likely at the root of Mr. Lanier's comment). It's rather interesting to consider how programmers try simplifying something and end up making things more complex... Some guy named Tim tries to simplify the exchange of scientific documents and, voila! out pops amazon.com.

It's worth noting that all or most of the significant "events" in human history have resulted in (or enabled or supported) huge increases in complexity. Language, agriculture, population expansion, civilization, transportation (roads, ships, etc.), writing, the printing press, electronic communication, and so on; they have all increased the connections (usually both in number and frequency) between people. (It's possible that Kurzweil's theory of exponential growth of technology is focused on an effect rather than a cause. It seems more likely to me that complexity is growing exponentially and, for the moment, technology is a parallel effect of that growth.)

Bell Labs also have a history of Unix on their web site, written by one of the creators of UNIX. Do not miss the "Next" links below the articles and read how the story of Unix unfold! I almost did and thought they just had a short blurb about it. :-P

It's actually pretty in-depth and I found it interesting at least. :-)

It also discuss how the B language (first letter in BCPL; the basis for B) evolved into C, and some of the obstacles they met when creating "The bext B" that became C, the idea of Unix pipes, a discussion of the syntax of Unix commands,

It proceeds into discussing the Unix "wars" between Sun and AT&T, the creation of the Open Software Foundation, etc.

Some quotes:

"Like another legendary creature whose name also ends in 'x,' UNIX rose from the ashes of a multi-organizational effort in the early 1960s to develop a dependable timesharing operating system."

"He [Ken Thompson] put pipes into UNIX, he put this notation into shell, all in one night," McElroy said in wonder.

"Thirty years after its creation, UNIX still remains a phenomenon," Ritchie marveled.

i don't know, but if someone really want to read a book/article about How to be a Programmer?. i always recommend this book: The Practice of Programming, by Brian W. Kernighan and Rob Pike.

you know what's wrong with your article? you just list a few books, and say: "go learn programming there", then you start talking about debugging, in section Beginner! what a misleading...yes, i know bug happens, we can never finish a project without debugging, but, you should not emphasize this and forgot the more important thing: Write Simplicity/Clarity/Generality code, eliminate bugs (not all, of course) at the first place.

So, now, when you learn about computer science, you learn about the file as if it were an element of nature, like a photon. That's a dangerous mentality.

But the file makes a pretty decent photon. Plan9

What's happended to Bell Labs?

It got broken into a number of pieces, just as AT&T split up.

(is it somewhere in Lucent?)

The piece called Bell Labs did.

How about HP?

HP Labs still exists; whether they're doing less, or just doing stuff other than the commodity stuff HP's using more of, is another matter.

But, as has been noted, there are some research departments in big companies that are doing interesting stuff, such as IBM and even a favorite whipping boy on Slashdot. How pure the research of any given company is might be a different matter.

Pike, Ritchie et.al. got a usable product out of the door and crammed with innovation that the rest of the world will eventually find is The Right Thing.

Single sign on - yup & secure too
Security included by default, not as an add on like in Unix & Windows which both evolved from single user systems and the problems that brings [I mean root - how crazy!]
Totally re-entrant in all sorts of ways [get a prompt, type 'rio', and the windowing system runs inside that window - great for testing and you can even choose to transparently run it on remote CPUs]

I hope the hurd does get something out of the door.

User level file systems are a beautiful thing.

I hope one can run GEOM filters in userland. Sounds like a way to implement a totally soft file system.

I'll use the eponymous plan9 example of ftpfs

ftps -m /n/FreeBSD ftp://ftp.freebsd.org/pub/FreeBSD

This would mount the remote ftp site into your local namespace so that when you did ls /n/FreeBSD you got the directory listing of ftp://ftp.freebsd.org/pub/FreeBSD

Shell programmers will instantly see the advantage of such a system over application level ftp clients.

You can use all the tools you presently use for files for manipulating the remote filesystem. None of your applications will have to understand ftp to operate and you can write new ones without even worrying about ftp libraries or whatever difficult protocol you can envisage.

plan9 achieves all this by employing a kind of universal protocol called 9p [now 9p2000]. It's quite a simple protocol and just does not much more than read, write, walk.

It sounds like the filtering system is a way to implement virtual file systems. I do hope so.

There are many interesting applications for such a concept. The list supplied with plan9 is here

I hope one can run GEOM filters in userland. Sounds like a way to implement a totally soft file system.

I'll use the eponymous plan9 example of ftpfs

ftps -m /n/FreeBSD ftp://ftp.freebsd.org/pub/FreeBSD

This would mount the remote ftp site into your local namespace so that when you did ls /n/FreeBSD you got the directory listing of ftp://ftp.freebsd.org/pub/FreeBSD

Shell programmers will instantly see the advantage of such a system over application level ftp clients.

You can use all the tools you presently use for files for manipulating the remote filesystem. None of your applications will have to understand ftp to operate and you can write new ones without even worrying about ftp libraries or whatever difficult protocol you can envisage.

plan9 achieves all this by employing a kind of universal protocol called 9p [now 9p2000]. It's quite a simple protocol and just does not much more than read, write, walk.

It sounds like the filtering system is a way to implement virtual file systems. I do hope so.

There are many interesting applications for such a concept. The list supplied with plan9 is here

I hope one can run GEOM filters in userland. Sounds like a way to implement a totally soft file system.

I'll use the eponymous plan9 example of ftpfs

ftps -m /n/FreeBSD ftp://ftp.freebsd.org/pub/FreeBSD

This would mount the remote ftp site into your local namespace so that when you did ls /n/FreeBSD you got the directory listing of ftp://ftp.freebsd.org/pub/FreeBSD

Shell programmers will instantly see the advantage of such a system over application level ftp clients.

You can use all the tools you presently use for files for manipulating the remote filesystem. None of your applications will have to understand ftp to operate and you can write new ones without even worrying about ftp libraries or whatever difficult protocol you can envisage.

plan9 achieves all this by employing a kind of universal protocol called 9p [now 9p2000]. It's quite a simple protocol and just does not much more than read, write, walk.

It sounds like the filtering system is a way to implement virtual file systems. I do hope so.

There are many interesting applications for such a concept. The list supplied with plan9 is here

This is old news. Check out the technical background article from September 1998. Essentially they are creating a set of parallel paths, using multiple transmit and receive antennas, by using signal processing at the receivers to separate out the individual signals (which are, of course, affected by multipath).

Intelligent Antennas and BLAST for 3G - CDMA

BLAST Technical Background

Lucent has a 'BLAST'

ISART-98 V-BLAST Presentation

BLAST High-Level Overview

BLAST Technical Background

Intelligent Antennas and BLAST for 3G - CDMA

BLAST Technical Background

Lucent has a 'BLAST'

ISART-98 V-BLAST Presentation

BLAST High-Level Overview

BLAST Technical Background

Intelligent Antennas and BLAST for 3G - CDMA

BLAST Technical Background

Lucent has a 'BLAST'

ISART-98 V-BLAST Presentation

BLAST High-Level Overview

BLAST Technical Background

Intelligent Antennas and BLAST for 3G - CDMA

BLAST Technical Background

Lucent has a 'BLAST'

ISART-98 V-BLAST Presentation

BLAST High-Level Overview

BLAST Technical Background

Intelligent Antennas and BLAST for 3G - CDMA

BLAST Technical Background

Lucent has a 'BLAST'

ISART-98 V-BLAST Presentation

BLAST High-Level Overview

BLAST Technical Background

Yes, it does go against that philosophy. Still, UNIX developers are pragmatic--that sort of thing may be OK for a few key services.

However, in Plan 9, the original UNIX developers have been trying to address this issue better.

Although K really isn't a scripting langauge (neither is C), results were done for it, too (being faster and having less code). There is also a shallow introduction to K on Kuro5hin.org.

awk essential for pipe work.

you'll see it here used like
wget -O - http://domain/info.html | awk -f proc.awk | mysql -u news newsdb

rc shell and it's unix implmentation

Vita Nuova say in their most recent newsletter that they are considering "a dual-licence scheme that makes the Inferno software free for non-commercial use, but with a more traditional software licence for commercial use."

A quick glance at the features of the upcoming release reveals some clarification on this:

• It is available as `Free Software' (in the sense of the Free Software Foundation) if the use you make of it will also be made available on the same terms, as Free Software.
• A more conventional software licence if the result of your work using Inferno will not or cannot be made Free Software.

Inferno is the very interesting cousin OS to Plan 9 (both modern descendants of UNIX). This would be a very cool thing.

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

Acid: A Debugger Built From A Language

Phil Winterbottom
philw [ a t ] plan9.bell-labs.com

ABSTRACT

NOTE: Originally appeared in Proc. of the Winter 1994 USENIX Conf., pp. 211-222, San Francisco, CA

Acid is an unusual source-level symbolic debugger for Plan 9. It is implemented as a language interpreter with specialized primitives that provide debugger support. Programs written in the language manipulate one or more target processes; variables in the language represent the symbols, state, and resources of those processes. This structure allows complex interaction between the debugger and the target program and provides a convenient method of parameterizing differences between machine architectures. Although some effort is required to learn the debugging language, the richness and flexibility of the debugging environment encourages new ways of reasoning about the way programs run and the conditions under which they fail.

Here's a link to a site where a guy describes his plans to restore one of these classic machines.

It's a short read, but it's nice to see someone trying to restore one of thse boxes.

Ken Thompson used to have a link on his page to someone who was restoring one of these. But since he's retired, it's not there now.

Ok, showing my age ....

Odd Comments and Strange Doings in Unix

Of course the most famous of all is the comment in the task switching code of the original v6 Unix (Lyons commentary era) which said ... /* You are not expected to understand this */

And, of course, it means something like "this won't be on the exam". See Odd Comments and Strange Doings in Unix for more of this kind of fun.

I'd argue that C isn't useful at all to teaching the way hardware works, especially as time passes. "Pointer arithmetic" is obviously useless even for optimizations today, as all major architectures employ virtual memory and caches on the processor. It's become an abstraction, that's now more trouble than it's worth (yeah, byte strings work great until you get to Unicode!). And how many modern compilers completely ignore register declarations?

...maybe we could just lock in the coordinates on our freight transporter and teleport it directly into the sun. You're thinking 1000 years, not 100. Think of what we have accomplished in the past 100 years and stop being ridiculously optimistic.

Look, in contrast, at the "next generation UNIX shell", rc, from Bell Labs. "rc" intends to simplify, remove unnecessary functionality, and factor out features like job control and command line editing.

Here is a neat paper describing how Plan9 made the full transition to Unicode. Not exactly an easy feat, although it was harder than necessary for them because they decided to do it back when Unicode was still being standardized. And of course, ASCII isn't going away anytime soon, as there are plenty of systems that don't need it but do need all the memory they can get.

http://plan9.bell-labs.com/plan9dist/screenshot.ht ml

Lucent even now provides a pre-packaged VMWare image

You have to click a EULA to get this link but it exists :

http://plan9.bell-labs.com/magic/9down4e/compres se d/$CODE/vmware.zip

start here - http://plan9.bell-labs.com/plan9dist/download.html

You can keep the byte orientation and still have Unicode support. See this.

Now wait a minute

Examples of good procedures could be. *Systems provide automated roll back.

This isn't a procedure. This is a potential feature of the system itself. When I was a unix admin, I versioned config files, because unix doesn't provide automatic versioning of files, allowing rollback of config changes. However, as the person who set up the versioning system, if I had gone bad I would have been able to sabotage the files under revision control as well. Unless the system itself enforces this (i.e, the system keeps all versions of all files and does not allow an admin to change, in any manner, old versions), this sort of precaution can be bypassed.

*Changes can only be applied through a script that is run by xyz and required GOD access (say knowlage of a password that changes daily)

This, also, sounds good. However, on some Unix systems, at least, there have been issues with setuid scripts related to how the system loads and executes them, allowing race conditions that can lead to root access. Note that the issue I'm talking about is -not- a bug in the script, but rather a side effect of how #! loading is handled by some systems. A large percentage of the Unix S.A.s I know rightly disallow the use of setuid scripts for this reason, and the fact that it's easy to write a script that allows things like /tmp races and other bugs that lead to root access and/or clobbering of files.

*System should be configured to audit any changes that take place.

Again, not a procedure, but a potential feature of the system. If the system doesn't allow this directly, how do you propose to implement it?

*A review process, where by any changes are reviewed by another member of staff

"Hey Dave, I'm sabotaging the system -- Can you review my change for me? Thanks!" - Do you really think someone's going to let a change like that get into the queue for a review process? Are you advocating a line-by-line code/config review of -everything- every single time a change is made, and do you realize how impractical that is, especially if the deployed system is complex or the number of deployed machines is large? Do you understand that it is possible to make a change that cannot be reviewed?

You can do things to attempt to prevent this sort of thing, but you have to understand that there is no procedural solution for this problem -> the best you can do is reduce the odds that someone can do this and not get caught. This is a laudable goal, but, while in pursuit of this goal, the practical limitations need to be kept in sight.

The moral of the story is, it's very easy to post on Slashdot saying 'x, y, and z would have prevented this', with x, y, and z being impractical/impossible to implement, and through some twist of logic, come to a conclusion such as:

the sysadmin was bad the company was useless, I'm not supprised he quit and tried to take the company down.

totally agree with you. computer science is not the forefront of technology anymore -- it's too commercialized. or maybe it's just too complex these days (always a good read -- "System Software Research is Irrelevant", a talk by rob pike that summarizes most people's feelings towards operating systems and computer science in general).

the next big thing (speaking from the point of view of someone who has spent the last 7 years in a north american university) is biotechnology...

of course i hope i'm disproved -- i like computers, not counting genes...

but who can guarantee me that the binaries don't have those backdoors and trojans.

Take that one step further and read Ken Thompson's masterpiece Reflections on Trusting Trust

Try Bell Labs to get more details. The 'Perfect Lens' part refers to the fact that nature is reliably and repetitivly making defect free lenses.

Eiffel is a very underrated language in the free software community for some strange reason..

From this point of view, an open-source compiler is ideal. Perl and Python are effectively single-vendor (i.e. single development team) but at no risk.

Aside: at the time (commercial) Eiffel first appeared, we were working on a Standard ML language and compiler (in fact there were several different development teams building compilers, since the language had a formal semantics and definition). The New Jersey compiler was open-source from the start (around, oh, 1987?), and was self-compiling, generating native code for 680x0, Alpha, Vax and Mips architectures.

This was around the time that OO programming was getting trendy, and SML, despite being very-high-level, strongly-typed, memory-managed, having a superb modules system etc., wasn't really OO and so fell out of fashion. It's still around, though, and still being developed (see the link above).

I strongly suggest you spend a few months each on Perl, Python, a functional language like Haskell, and several APIs of some sort, like wxWindows or XML parsing.

I agree totally. I just wanted to chime in and say that while you're out checking out new languages, give Ruby a try. It's a beautful language that falls in the same family as Perl and Python but has it's own charm all the same. I use it for all of my development in an environmental lab, and it's served me quite well.

If you want to explore functional programming, you also may want to check out SML.
There are several free implementations available, and it's easy to learn. It's very fast and quite powerful for a variety of tasks. Last but not least, check out ANSI Lisp or at least Scheme. Everybody serious programmer should know at least one dialect of Lisp because it's the original hackers language.

I believe ESR did a rant somewhere on how to become a real programmer or something along those lines. Google could probably dig it up rather quickly. It's worth a read as he outlines languages to learn to explore the various development methodologies(functional, OOP, procedural, etc).

umm, here is what i mean (see section 4.2)...

It's big and slow.

In some cases, it's faster than C++.

Don't believe me? Download the Markov examples from Kernighan & Pike's "The Practise of Programming" and time the C++ and Java examples. On a P3-550 I get 3.63 seconds for the C++ and 2.90 seconds for the Java version.