Martin Pool's blog

Mail me RSS Bazaar distcc Canonical is hiring! flickr

Bill Joy on writing vi

The Register quotes a Linux Mag interview with Bill Joy on the design constraints for writing vi:

What happened is that Ken Thompson came to Berkeley and brought this broken Pascal system, and we got this summer job to fix it. While we were fixing it, we got frustrated with the editor we were using which was named ed. ed is certainly frustrating.

We got this code from a guy named George Coulouris at University College in London* called em - Editor for Mortals - since only immortals could use ed to do anything. By the way, before that summer, we could only type in uppercase. That summer we got lowercase ROMs for our terminals. It was really exciting to finally use lowercase.

So we modified em and created en. I don't know if there was an eo or an ep but finally there was ex. [laughter] I remember en but I don't know how it got to ex. So I had a terminal at home and a 300 baud modem so the cursor could move around and I just stayed up all night for a few months and wrote vi.

Linux Mag then asked: "So you didn't really write vi in one weekend like everybody says?"

No. It took a long time. It was really hard to do because you've got to remember that I was trying to make it usable over a 300 baud modem. That's also the reason you have all these funny commands. It just barely worked to use a screen editor over a modem. It was just barely fast enough. A 1200 baud modem was an upgrade. 1200 baud now is pretty slow.

9600 baud is faster than you can read. 1200 baud is way slower. So the editor was optimized so that you could edit and feel productive when it was painting slower than you could think. Now that computers are so much faster than you can think, nobody understands this anymore.

The people doing Emacs were sitting in labs at MIT with what were essentially fibre-channel links to the host, in contemporary terms. They were working on a PDP-10, which was a huge machine by comparison, with infinitely fast screens.

So they could have funny commands with the screen shimmering and all that, and meanwhile, I'm sitting at home in sort of World War II surplus housing at Berkeley with a modem and a terminal that can just barely get the cursor off the bottom line.

It was a world that is now extinct. People don't know that vi was written for a world that doesn't exist anymore - unless you decide to get a satellite phone and use it to connect to the Net at 2400 baud, in which case you'll realize that the Net is not usable at 2400 baud. It used to be perfectly usable at 1200 baud. But these days you can't use the Web at 2400 baud because the ads are 24KB.

Even now latency from (say) Australia to the US is high enough that being able to type a long way ahead in the way that vi supports is quite worthwhile.

George Coulouris writes, about vi:

The system support person (I don't recall his name, but I have a vague recollection that he went to Bell Labs later. Bill Joy might be able to tell you his name) said something like: "That's very nice, but if we made it available to all of our users the overheads associated with running in raw mode (a process swap on each key depression) would swamp the cpu".

I was rather depressed by this reaction, thinking "I guess I have been unrealistic in developing an editor that is so expensive to run - it's ok in our small system, but it's no use in the big Unix environment at Berkeley".[...]

By the way, 'em' stands for 'editor for mortals' - I christened it that after Ken Thompson visited our lab at QMC while I was developing it and said something like: "yeah, I've seen editors like that, but I don't feel a need for them, I don't want to see the state of the file when I'm editing".

posted Mon 15 Sep 2003 in /software/people | link

LinuxWorld interview with tridge

Good brief interview with Andrew Tridgell in LinuxWorld.com.au:

One of the most memorable parts of that evening was when my Linux NFS [Network File System] server died, to the point that the console seemed completely dead (the load of all those Doom WAD files obviously got to it). I was about to press reset when Linus stepped in and said he wanted to work out why it had crashed, so he could fix it. I then watched in complete amazement as Linus exploited a remote file truncation bug he knew about in the NFS server I was running which allowed him to peek into the proc filesystem on the apparently dead server and work out enough to find the bug. Up till then I had considered myself to be a pretty good programmer, and quite good at debugging system crashes, but that incident taught me that I would always be an also-ran who just isn't in the same league as people like Linus.

posted Tue 2 Sep 2003 in /software/people | link

Hanging Out with Smart People

Rusty's slides from OLS are now up on the web. They are amusing and thoughtful.

This is what really should be in "Software Engineering" classes, but I've never heard of it being taught.

posted Mon 11 Aug 2003 in /software/people | link

Linux Journal interview with Kernighan

Interview with Brian Kernighan.

posted Thu 31 Jul 2003 in /software/people | link

Hans Reiser interview

Slashdot has an interview with Hans Reiser

There will always be more features that I would like to implement than I can implement. Users and sponsors for the most part want good things to be added, and it is really not so bad to first implement the features that someone is willing to pay for, and hope that in a few years someone else will pay for other features. I take a 30 year perspective on the project, and I have as my final objective the elimination of reasons to not use the filesystem as the unifying namespace of the operating system. That makes for quite a lot of features that I am willing to add.;-) [....]

It is important to be true to oneself. You should maybe understand that some years ago I put the suit my mother bought me into the fireplace along with all my ties. If a restaurant requires a suit and tie, I just don't go there, it is not for the likes of me. If you need some corporately commercial justification for our website design, then let it be that I am willing to be cool and appealing to the younger generation, etc., instead of bland. If a pedagogical justification will work for you, then let me point out that military manuals with their cartoon based approach are far more effective in engaging the reader than the pedagogical techniques employed by most college textbooks. The military is more advanced in its pedagogical technique than the university system, which is really rather amusing, and I think it is due to the greater pretentiousness of universities in this matter. [...]

I predict that in 20 years version control in filesystems will be standard and expected by all users as a basic feature. [...]

This is very interesting. I have never previous thought that version control (as such) in the filesystem was a good idea. I think having some kind of backup/rollback facility as in NetApp is a good idea, and I wrote a very sketchy prototype of that years ago. But version control is so much more that just keeping backups: it implies being able to annotate and label versions, merge them intelligently and so on. The filesystem interface is just not really rich enough to do this, so you need some external support. (So Clearcase does some things through the filesystem, primarily retrieving versions, but most modifications and queries require extra commands.)

After thinking about Hans's comments, I think I would refine that to: the *Unix* filesystem interface is not rich enough to do it. If you could create copy-on-write trees, or attach annotations, or view all edits with a single operation then it might make sense. Being able to directly edit a comment on a version *as a file* without needing to then do some kind of commit operation would be great.

However, the plain-hierarchical filesystem has been remarkably resiliant (or stubborn.) Scores of commercial, academic and hobby projects have tried to replace it with some kind of content-addressible or richly structured database and few or none have been really broadly successful. Probably some large fraction of this is due to technical conservatism, but I think it's also hard to think of a new design that is really generally useful. A plain tree is adequately useful by itself, and allows you to innovate in the application space.

Hans is probably right that making the tree more efficient and flexible is a start though.

Are you sure that it wouldn't be better to hang out in cafes and bookstores for 4 years, and at the end of it write some piece of a filesystem? Cafes, bookstores, and attending random seminars will educate you better, and writing some piece of a filesystem will employ you better.

If only one could get student loans for the purpose of hanging out in cafes and bookstores for 4 years I would have been so happy....

When something becomes stable enough for you to use it yourself without it crashing, and you don't know how to make it crash, you should release it (with lots of warnings). Fortunately, there are people who like to play with technology, and they will help you find its bugs while understanding that it is still experimental code. Each order of magnitude increase in the number of users will find as many bugs as the previous order of magnitude. After some number of years, if you are kind to your users and only do new features on a new branch, the stable branch will get to where months go by and there are no bug reports at all even though there are millions of users.[...]

Linux is an ecosystem, and in this ecosystem there is fast growth vegetation and slow growth vegetation. The fast growth vegetation are the people who took what had already been done by Unix, and without changing its design they copied it while making coding improvements.

Then there are those who look at Unix, err, Linux, and see something just barely begun that needs a complete overhaul. These are the slow growth vegetation. Namesys is slow growth vegetation that got started a long time ago.

Now it is human nature that however a human being is, he is inclined to think that is the right way to be. There are those who think that design does not matter, and one should just make incremental coding improvements. There are also those who think that just coding without introducing fundamental new ideas is unimportant. Both of these sets of persons are fools. To say that one approach is better than another is like saying that grass is better than trees, or trees are better than grass. For Linux to prosper as an ecosystem it must have both.

posted Thu 19 Jun 2003 in /software/people | link

Copyright (C) 1999-2007 Martin Pool.