TUHS

tuhs@tuhs.org

16 participants
6536 discussions

Unix taste (Re: terminal - just for fun)

by Doug McIlroy

> To each their own. Indeed. > As a Vi user, nothing beats having Esc on the home row. A symptom of why I have always detested emacs and vi. With ^D, ^C, and ^\, Unix has more than enough mystery chords to learn. Emacs and vi raised that number to a high power--an interface at least as arcane and disorganized as the DD card in OS 360--baroque efflorescences totally out of harmony with the spirit of Unix. (Perhaps one could liken learning vi to learning how to finger the flute, but the flute pays off with beautiful music. To put the worst face on vi, it "pays off" only by promoting frantic tinkering.) A modern-day analog of the undisciplined exuberance of emacs and vi: for a good time on linux try less --help | wc Does comment on taste belong in a discussion of history? I think so. Unix was born of a taste for achieving big power by small means rather than by unbounded accumulation of facilities. But evolution, including the evolution of Unix, does not work that way. An interesting question is how the corrective of taste manages ever to recenter the exuberance of evolution. The birth of Unix shows it can happen. When will it happen again? Can one cite small-scale examples that gained traction within the larger evolution of Unix? Doug

10 years, 11 months

Re: [TUHS] Unix taste (Re: terminal - just for fun)

by jnc＠mercury.lcs.mit.edu

> From: Doug McIlroy <doug(a)cs.dartmouth.edu> > A symptom of why I have always detested emacs and vi. With ^D, ^C, and > ^\, Unix has more than enough mystery chords to learn. Emacs and vi > raised that number to a high power--an interface at least as arcane and > disorganized as the DD card in OS 360--baroque efflorescences totally > out of harmony with the spirit of Unix. I will agree that the Emacs user interface is not simple - although there are levels, and one can start out e.g. without knowing the commands to move by word, and get by with the commands to move by character - and of course nowadays, the arrows, etc, keys on keyboards are bound to the appropriate commands, for novices. But it's a subtle debate; yes, it's not for everyone, but i) as an application, not everyone has to use it (unlike a kernel), and ii) as the editor is the principal tool which most programmers spend hours a day using, it is not insensible to have a more complex but powerful tool which takes a while to fully master. (Like playing a violin...) Back on V6, we started using one written by someone at BBN (memory fails me as to exactly who), and it improved my productivity immensely (with 'WYSIWG' editing - i.e. you always see the current contents of the buffer, multiple buffers, multiple windows, etc). I had been using 'ed' (although I had access to Emacs on the ITS machines), and although I was (and remain) fairly skilled at 'ed', the factors I just listed are immense, IMO. Being able to see the code as I work on it really, really helps (for me, at least). But a lot of that is orthogonal to Emacs command interface; you can have 'WYSIWYG', multiple buffers, etc with a wholly different command interface, and get much the same benefit. (E.g. uSoft Word has most of those; real WYSIWG [i.e. with multiple fonts], multiple files open at once, etc, etc.) Does something like Word produce the same reaction for you? I don't use it much, but my wife does (she's an engineer, and uses it to write papers), and its complexity drives her crazy sometimes. As for the size of Emacs, everyone needs to distinguish between GNU Emacs, and Emacs-like editors. Just as GCC is a beast, but other C compilers are and were much smaller, there are small Emacses out there. Back on V6 (on a PDP-11, of course), it had to fit into 64KB; the one we used didn't have the kind of extensibility common in them now, but it was still a much better tool for me than 'ed'. As I recall the performance was pretty good (albeit it chewed CPU time, since it woke up on every character - Multics had an Emacs which tried to avoid that, and only woke up on non-printing characters, and used system echoing for the others). I don't know for sure (I don't have the source to hand at the moment - that's one of the things I hope to recover if/when I can read those backup tapes), but I suspect that it 'windowed' files (i.e. didn't read the whole thing in); with the 65KB address space of the 11, that would be almost inevitable. I have been using another Emacs, Epsilon, for almost 30 years now; it started as basically Emacs for MS-DOS, and later became Emacs for Windows, and it is small and very fast. The Windows executable is about 250KB, and it loads a 'state file' (mostly interpreted 'compiled' intermediate code, written in something that's 99.2% 'C', in which a lot of the editor is actually written) of about 200K (for mine, which has a lot of extensions I wrote). It starts fast, and runs blindingly fast. It also uses the file 'windowing' techniques, and can handle much larger files than its address space (this dates back to its MS-DOS days). So Emacs != big (at least, not necessarily). > A modern-day analog of the undisciplined exuberance of emacs and vi: > for a good time on linux try I basically agree with you on this; I want to go away and collect my thoughts before responding, though. Noel

10 years, 11 months

Re: [TUHS] Unix taste

by Ed

Arrow keys? Vi does arrow keys? But then I'd have to move my hand from home. That's not vi. -- Ed Skinner, ed(a)flat5.net, http://www.flat5.net/ -------- Original message -------- From: Doug McIlroy <doug(a)cs.dartmouth.edu> Date: 08/02/2014 8:38 AM (GMT-07:00) To: tuhs@minnie.tuhs.org,lm@mcvoy.com Subject: Re: [TUHS] Unix taste > So Doug, ed? Or what? Yes, ed for small things. It loads instantly and works in the current window without disturbing it. And it has been ingrained in my fingers since Multics days. But for heavy duty work, I use sam, in Windows as well as Linux. Sam marries ed to screen editing much more cleanly than vi. It has recursive global commands and infinite undo. Like qed (whence came ed's syntax) and Larry's xvi it can work on several files (or even several areas in one file) at once. I would guess that a vi adept would miss having arrow keys as well as the mouse, but probably not much else. Sam offers one answer for my question about examples of taste reigning in featurism during the course of Unix evolution. Doug _______________________________________________ TUHS mailing list TUHS(a)minnie.tuhs.org https://minnie.tuhs.org/mailman/listinfo/tuhs

10 years, 11 months

Re: [TUHS] Unix taste

by Doug McIlroy

> So Doug, ed? Or what? Yes, ed for small things. It loads instantly and works in the current window without disturbing it. And it has been ingrained in my fingers since Multics days. But for heavy duty work, I use sam, in Windows as well as Linux. Sam marries ed to screen editing much more cleanly than vi. It has recursive global commands and infinite undo. Like qed (whence came ed's syntax) and Larry's xvi it can work on several files (or even several areas in one file) at once. I would guess that a vi adept would miss having arrow keys as well as the mouse, but probably not much else. Sam offers one answer for my question about examples of taste reigning in featurism during the course of Unix evolution. Doug

10 years, 11 months

Re: [TUHS] First Unix that could run on a PDP-11 with QBUS

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall <dave(a)horsfall.org> > I recall that there were other differences as well, but only minor. In > my paper in AUUGN titled "Unix on the LSI-11/23" it will reveal all > about porting V6 to the thing. I did a google for that, but couldn't find it. Is it available anywhere online? (I'd love to read it.) I seem to recall vaguely that AUUGN stuff were online, but if so, I'm not sure why the search didn't turn it up. > I vaguely remember that the LTC had to be disabled during the boot > process, for example, with an external switch. I think you might be right, which means the simulated 11/23 I tested on wasn't quite right - but keep reading! I remember being worried about this when I started doing the V6 11/23 version a couple of months back, because I remembered the 11/03's didn't have a programmable clock, just a switch. So I was reading through the 11/23 documentation (I had used 11/23s, but on this point my memory had faded), trying to see if they too did not have a programmable clock. As best I can currently make out, the answer is 'yes/no, depending on the exact model'! E.g. the 11/23-PLUS _does_ seem to have a programmable clock (see pg. 610 of the 1982 edition of "microcomputers and memories"), but the base 11/23 _apparently_ does not. Anyway, the simulated 11/23 (on Ersatz11) does have the LTC (I just checked, and 'lks' contains '0177546', so it thinks it has one :-). But this will be easy to code around; if no link clock is found (in main.c), I'd probably set 'lks' to point somewhere harmless (054, say - I'm using 050/052 to hold the pointer to the CSW, and the software CSW if there isn't a hardware one). That way I can limit the changes to be in main.c, I won't have to futz with clock.c too. Noel PS: On at least the 11/40 (and maybe the /45 too), the line clock was an option! It was a single-height card, IIRC.

10 years, 11 months

Re: [TUHS] First Unix that could run on a PDP-11 with QBUS

by jnc＠mercury.lcs.mit.edu

> From: Mark Longridge <cubexyz(a)gmail.com> > I was digging around trying to figure out which Unixes would run on a > PDP-11 with QBUS. It seems that the very early stuff like v5 was > strictly UNIBUS and that the first version of Unix that supported QBUS > was v7m (please correct me if this is wrong). That may or may not be true; let me explain. The 11/23 is almost indistinguishable, in programming terms, from an 11/40. There is only one very minor difference (which UNIX would care about) that I know of - the 11/23 does not have a hardware switch register. Yes, UNIBUS devices can't be plugged into a QBUS, and vice versa, _but_ i) there a programming-compatible QBUS versions of many UNIBUS devices, and ii) there were UNIBUS-QBUS converters which actually allowed a QBUS processor to have UNIBUS peripherals. So I don't know which version of Unix was the first run on an 11/23 - but it could have been almost any. It is quite possible to run V6 on an 11/23, provided you make a very small number of very minor changes, to avoid use of the CSWR. I have done this, and run V6 on a simulated 11/23 (I have a short note explaining what one needs to do, if anyone is interested.) Admittedly, this is not the same as running it on a real 11/23, but I see no resons the latter would not be doable. I had started in on the work needed to get V6 running on a real 11/23, which was the (likely) need to load Unix into the machine over a serial line. WKT has done this for V7: http://www.tuhs.org/Archive/PDP-11/Tools/Tapes/Vtserver/ but it needs a little tweaking for V6; I was about to start in on that. > I have hopes to eventually run a Unix on real hardware As do a lot of us... :-) > It seems like DEC just didn't make a desktop that could run Bell Labs > Unix, e.g. we can't just grab a DEC Pro-350 and stick Unix v7 on it. I'm not sure about that; I'd have to check into the Pro-350. If it has memory mapping, it should not be hard. Also, even if it doesn't have memory mapping, there was a Mini-Unix done for PDP-11's without memory mapping; I can dig up some URLs if you're interested. The feeling is, I gather, very similar. > it would be nice to eventually run a Unix with all the source code at > hand on a real machine. Having done that 'back in the day', I can assure you that it doesn't feel that different from the simulated experience (except that the latter are noticeably faster :-). In fact, even if/when I do have a real 11, I'll probably still mostly use the simulator, for a variety of reasons; e.g. the ability to edit source with a nice modern editor, etc, etc is just too nice to pass up! :-) Noel

10 years, 11 months

First Unix that could run on a PDP-11 with QBUS

by Mark Longridge

Hi folks, I was digging around trying to figure out which Unixes would run on a PDP-11 with QBUS. It seems that the very early stuff like v5 was strictly UNIBUS and that the first version of Unix that supported QBUS was v7m (please correct me if this is wrong). I was thinking that the MicroPDP-11's were all QBUS and that it would be easier to run a Unix on a MicroPDP because they are the most compact. So I figured I would try to obtain a Unix v7m distribution tape image. I see the Jean Huens files on tuhs but I'm not sure what to do with them. I have hopes to eventually run a Unix on real hardware but for now I'm going to stick with simh. It seems like DEC just didn't make a desktop that could run Bell Labs Unix, e.g. we can't just grab a DEC Pro-350 and stick Unix v7 on it. Naturally I'll still have fun checking out Unix v5 on the emulator but it would be nice to eventually run a Unix with all the source code at hand on a real machine. Mark

10 years, 11 months

Re: [TUHS] First Unix that could run on a PDP-11 with QBUS

by norman＠oclsc.org

Many Q-bus devices were indeed programmed exactly as if on a UNIBUS. This isn't surprising: Digital wanted their own operating systems to port easily as well. That won't help make UNIX run on a Pro-350 or Pro-380, though. Those systems had standard single-chip PDP-11 CPUs (F11, like that in the 11/23, for the 350; J11, like that in the 11/73, for the 380), but they didn't have a Q-bus; they used the CTI (`computing terminal interconnect'), a bus used only for the Pro-series systems. DEC's operating systems wouldn't run on the Pro either without special hacks. I think the P/OS, the standard OS shipped with those systems, was a hacked-up RSX-11M. I don't know whether there was ever an RT-11 for the Pro. There were UNIX ports but they weren't just copies of stock V7. I vaguely remember, from my days at Caltech > 30 years ago, helping someone get a locally-hacked-up V7 running on an 11/24, the same as an 11/23 except is has a UNIBUS instead of a Q-bus. I don't think they chose the 11/24 over the 11/23 to make it easier to get UNIX running; probably it had something to do with specific peripherals they wanted to use. It was a long time ago and I didn't keep notebooks back then, so the details may be unrecoverable. Norman Wilson Toronto ON

10 years, 11 months

Re: [TUHS] Excise process from a pipe

by jnc＠mercury.lcs.mit.edu

>> the downstream process is in the middle of a read call (waiting for >> more data to be put in the pipe), and it has already computed a pointer >> to the pipe's inode, and it's looping waiting for that inode to have >> data. > I think it would be necessary to make non-trivial adjustments to the > pipe and file reading/writing code to make this work; either i) some > sort of flag bit to say 'you've been spliced, take appropriate action' > which the pipe code would have to check on being woken up, and then > back out to let the main file reading/writing code take another crack > at it > ... > I'm not sure I want to do the work to make this actually work - it's > not clear if anyone is really that interested? And it's not something > that I'm interested in having for my own use. So I decided that it was silly to put all that work into this, and not get it to work. I did 'cut a corner', by not handling the case where it's the first or last process which is bailing (which requires a file-pipe splice, not a pipe-pipe; the former is more complex); i.e. I was just doing a 'working proof of concept', not a full implementation. I used the 'flag bit on the inode' approach; the pipe-pipe case could be dealt with entirely inside pipe.c/readp(). Here's the added code in readp() (at the loop start): if ((ip->i_flag & ISPLICE) != 0) { closei(ip, 0); ip = rp->f_inode; } It worked first time! In more detail, I had written a 'splicetest' program that simply passed input to its output, looking for a line with a single keyword ("stop"); at that point, it did a splice() call and exited. When I did "cat input | splicetest | cat > output", with appropriate test data in "input", all of the test data (less the "stop" line) appeared in the output file! For the first time (AFAIK) a process succesfully departed a pipeline, which continued to operate! So it is do-able. (If anyone has any interest in the code, let me know.) Noel

10 years, 12 months

Hazards of open source.

by Doug McIlroy

10 years, 12 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS