- TUHS - www.tuhs.org

Do Interface specifications such POSIX or the LSB Still Matter

by Clem Cole

I've send a couple of you private messages with some more details of why I ask this, but I'll bring the large question to debate here: Have POSIX and LSB lost their usefulness/relevance? If so, we know ISV’s like Ansys are not going to go ‘FOSS’ and make their sources available (ignore religious beliefs, it just is not their business model); how to we get that level of precision to allow the part of the market that will be 'binary only' continue to create applications? Seriously, please try to stay away from religion on this question. Clearly, there are a large number of ISVs have traditionally used interface specifications. To me it started with things like the old Cobol and Fortran standards for the languages. That was not good enough since the systems diverge, and /usr/group then IEEE/ANSI/ISO did Posix. Clearly, Posix enabled Unix implementations such a Linux to shine, although Linux does not doggedly follow it. Apple was once Posix conformant, but I'd not think they worry to much about it. Linux created LSB, but I see fewer and fewer references to it. I worry that without a real binary definition, it's darned hard (at least in the higher end of the business that I live day-to-day) to get ISV's to care. What do you folks think? Clem

7 years, 4 months

7
12
0 0

Re: [TUHS] Happy birthday, Niklaus Wirth!

by Norman Wilson

As an aside about Wolfram and SMP (and one that actually has something to do with UNIX): I ran the VAX on which Wolfram et al (and it was very much et al) developed SMP. It started out running UNIX/TS 1.0. I know how that system was snuck out of Bell Labs, but if I told you I'd have to terminate you with extreme prejudice. (I wasn't involved anyway.) SMP really needed dynamic paging; the TS 1.0 kernel had only swapping. We had quite a few discussions about what to do. Moving wholesale to 3BSD or early 4BSD (this was in 1981) would have been a big upheaval for our entire user community. Those systems were also notorious at the time for their delicate stability: some people reported that they ran well, others that they crashed frequently. Our existing system was pretty solid, and I had already put some work into making it more so (better handling of low-level machine errors, for example). Somehow we ended up deciding that the least-painful path was to lift the VM code out of 4BSD and shoehorn it into our existing kernel, creating what we called Bastardized Paging UNIX. I did most of the work; I was younger and more energetic back then. Also considerably grumpier. In the heart of the page-in (I think) code, the Berkeley guys had written a single C function that stretched to about ten printed pages. (For those too young to remember printers, that means about 600 lines.) I was then and still am adamant that that's the wrong way to write anything, but I didn't want to take the time to rewrite it all, so (being young and grumpy) I relieved my feelings by adding a grumpy comment at the top of the source file. I also wrote a paper about the work, which was published in (of all places) AUUGN. I haven't read it in years but it was probably a bit snotty. It nevertheless ended up causing a local UNIX-systems-software company to head-hunt me (but at the time I had no interest in leaving Caltech), so it must not have been too rude. What days those were, when a single person could understand enough of the OS to do stuff like that in only a month or two, and get it pretty much right too. I did end up finding some interesting race-condition bugs, probably introduced by me, but fascinating to track down; e.g. something that went wrong only if a page fault happened at exactly the right time with respect to something else. Norman Wilson Toronto ON

7 years, 4 months

2
1
0 0

Re: [TUHS] PDP-7 Unix Paper

by Norman Wilson

Donald ODana: already 20 years ago I met a guy (masters degree, university) who never freed dynamically allocated memory. He told me he is 'instantiating a object', but had no idea what an heap is, and what dynamically allocated memory means. ==== This is the sort of programmer for whom garbage collection was named: his programs are a collection of garbage. Norman Wilson Toronto ON (In 1127-snark mode this evening)

7 years, 4 months

2
1
0 0

Re: [TUHS] Of birthdays etc

by Rudi Blom

>Date: Sat, 17 Feb 2018 17:47:22 +1100 (EST) >From: Dave Horsfall <dave(a)horsfall.org> >To: The Eunuchs Hysterical Society <tuhs(a)tuhs.org> >Subject: [TUHS] Of birthdays etc >Message-ID: <alpine.BSF.2.21.1802171649520.798(a)aneurin.horsfall.org> >Content-Type: text/plain; format=flowed; charset=US-ASCII > >... >Harris' Lament? Look it up with your favourite search engine (I don't use Google). > probably early 1995 I dabbled a bit in AltaVista Search. So even now still using Yahoo somehow :-) Keep it coming Dave, it's appreciated, at least by me. >From a former DECcie, uncle rubl

7 years, 4 months

1
0
0 0

Of birthdays etc

by Dave Horsfall

Blimey... How was I to know that a throw-away remark would almost develop into a shitfight? It would help if people changed the Subject line too, as I'm sure that Ken must've been a little peeved... It would also help if users didn't bloody top-post either, but I suspect that I've lost that fight. Anyway, this whole business started when I thought it might be a good idea to post reminders of historical events here, as I do with some of the other lists that I infest^W infect^W inhabit. I figured that the old farts here might like to be reminded of (IMHO) significant events, and similarly the youngsters might want to be reminded that there was indeed life before Linux (which, by the way, I happen to loathe, but that's a different story). I'm glad that some people appreciate it; and don't worry, Steffen, you'll soon catch up, as they should all be in the archives :-) A long-term goal (if I live that long) is to set up one of those "this day in history" sites, but it looks like Harris' Lament[*] has already applied :-( I've had a number of corrections (thanks!), some weird comments on pronunciation (an Englishman can probably pick my ancestry from me saying "castle" as "c-AH-stle" and "dance" as "d-A-nce" etc), but oddly enough no criticism (well, unless I'm talking about mounting a magtape as a filesystem; no, I will not forget the implication that I was a liar), and Warren has yet to spank me... For the morbidly curious I keep these events in Calendar on my MacBook (which actually spends most of its time in Terminal, and I don't even know how to use the Finder!), and am always noting things which interest me and therefore possibly others. Anyway, thanks all; it is an honour and a privilege to share a mailing list with some of the people who wrote the software that I have both used in the past and still use to this day. [*] Harris' Lament? Look it up with your favourite search engine (I don't use Google). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 4 months

1
0
0 0

Re: [TUHS] TUHS Digest, Vol 27, Issue 37

by Paul McJones

> On Feb 14, 2018, Dave Horsfall <dave(a)horsfall.org> wrote: > > Computer pioneer Niklaus Wirth was born on this day in 1934; he basically > designed ALGOL, one of the most influential languages ever, with just > about every programming language in use today tracing its roots to it. Wirth designed many languages, including Euler, Algol W, Pascal, Modula, and Oberon, but he did not design Algol; more specifically, he did not design Algol 60. Instead, a committee (J. W. Backus, F. L. Bauer, J. Green, C. Katz, J. McCarthy, P. Naur, A. J. Perlis, H. Rutishauser, K. Samelson, B. Vauquois, J .H. Wegstein, A. van Wijngaarden, and M. Woodger) designed it, and Peter Naur edited the remarkable Algol 60 specification. A few others, including Edsgar Dijkstra, who completed the first implementation, participated in meetings leading up to the final design.

7 years, 4 months

1
0
0 0

Re: [TUHS] Happy Birthday, Nicklaus Wirth

by Paul Ruizendaal

From: Doug McIlroy <doug(a)cs.dartmouth.edu> > Like PL/I, it also > borrowed the indispensable notion of structs from business languages > (Flowmatic, Comtran, Cobol). That is an interesting insight. I always thought that structs were inspired by the assembler DORG construct, and hence the shared namespace for members. The above insight goes some way to explain why PDP11 “as” did not have a DORG construct, but early C did have ‘struct'. Paul

7 years, 4 months

1
0
0 0

And it's time to close the C vs. Lisp thread

by Warren Toomey

as it's strayed too far from the charter of the TUHS mailing list. There must be a more suitable forum to discuss language issues! Thanks, Warren

7 years, 4 months

1
0
0 0

lisp challenge

by Larry McVoy

So people have called me on the claim that lisp is not fast. Here's a rebuttal. Please write a clone of GNU grep in lisp to demonstrate that the claim that lisp is slower that C is false. Best of luck and I'll be super impressed if you can get even remotely close without dropping into C or assembler. If you do get close, I will with draw my claim, stand corrected, point future "lisp is slow" people at the lisp-grep, and buy you dinner and/or drinks. --lm

7 years, 4 months

6
11
0 0

Re: [TUHS] lisp challenge

by jnc＠mercury.lcs.mit.edu

> From: Larry McVoy <lm(a)mcvoy.com> > the proof here is to show up with a pure lisp grep that is fast as the C > version. ... I've never seen a lisp program that out performed a well > written C program. Your exact phrase (which my response was in reply to) was "lisp and performance is not a thing". You didn't say 'LISP is not just as fast as C' - a different thing entirely. I disagreed with your original statement, which seems to mean 'LISP doesn't perform well'. Quite a few people spent quite a lot of time making LISP compiler output fast, to the point that it was possible to say "this compiler is also intended to compete with the S-1 Pascal and FORTRAN compilers for quality of compiled numeric code" [Brooks,Gabriel and Steele, 1982] and "with the development of the S-1 Lisp compiler, it once again became feasible to implement Lisp in Lisp and to expect similar performance to the best hand-tuned, assembly-language-based Lisp systems" [Steele and Gabriel, 1993]. Noel

7 years, 4 months

1
0
0 0

[Re: Happy Birthday, Nicklaus Wirth

by Doug McIlroy

> Computer pioneer Niklaus Wirth was born on this day in 1934; he basically > designed ALGOL, one of the most influential languages ever, with just > about every programming language in use today tracing its roots to it. Rather than "tracing its roots to it", I'd say "has some roots in it". Algol per se hardly made a ripple in the US market, partly due to politics and habit, but also because it didn't espouse separate compilation. However, as asserted above, it had a profound impact on language designers and counts many languages as descendants. To bring the subject back to Unix, C followed Fortran's modularity and Algol's block structure. (But it reached back across the definitive Algol 60 to pick up the "for" statement from Algol 58.) Like PL/I, it also borrowed the indispensable notion of structs from business languages (Flowmatic, Comtran, Cobol). It adopted pointers from Lisp, as polished by BCPL (pointer arithmetic) and PL/I (the -> operator). For better or worse, it went its own way by omitting multidimensional arrays. So C has many roots. It just isn't fashionable in computer-language circles to highlight Cobol in your family tree. Doug

7 years, 4 months

1
0
0 0

Re: [TUHS] Happy birthday, Niklaus Wirth!

by jnc＠mercury.lcs.mit.edu

> From: Larry McVoy <lm(a)mcvoy.com> > I don't know all the details but lisp and performance is not a thing. This isn't really about Unix, but I hate to see inaccuracies go into archives... You might want to read: http://multicians.org/lcp.html Of course, when it comes to the speed/efficientcy of the compiled code, much depends on the program/programmer. If one uses CONS wildly, there will have to be garbage collection, which is of course not fast. But properly coded to stay away from expensive constructs, my understanding is that 'lcp' and NCOMPLR produced pretty amazing object code. Noel

7 years, 4 months

2
1
0 0

Re: [TUHS] Happy birthday, Niklaus Wirth!

by Paul McJones

Actually, Algol 60 did allow functions and procedures as arguments (with correct static scoping), but not as results, so they weren’t “first class” in the Scheme sense. The Algol 60 report (along with its predecessor and successor) is available, among other places, here: http://www.softwarepreservation.org/projects/ALGOL/standards/ On Feb 16, 2018, Bakul Shah <bakul(a)bitblocks.com> wrote: > They did lexical scoping "right", no doubt. But back when > Landin first found that lambda calculus was useful for > modeling programming languages these concepts were not clearly > understood. I do not recall reading anything about whether > Algol designers not allowing full lexical scopin was due to an > oversight or realizing that efficient implementation of > functional argument was not possible. May be Algol's call by > name was deemed sufficient? At any rate Algol's not having > full lexical scoping does not mean one can simply reject the > idea of being influenced by it. Often at the start there is > lots of fumbling before people get it right. May be someone > should ask Steele?

7 years, 4 months

2
1
0 0

Re: [TUHS] Clueless programmers

by Rudi Blom

Clueless or careless? A customer program worked for many years till one of the transaction messages had a few bytes added. Looking into it I discovered that the program had only worked because the receive buffer was followed by another buffer which was used in a later sequence. Only when also that buffer overflowed some critical integers got overwritten and used as index in tables that gave a lot of fun. Well, as all here know, C is fun :-)

7 years, 4 months

2
1
0 0

Re: [TUHS] Happy birthday, Niklaus Wirth!

by jnc＠mercury.lcs.mit.edu

> From: Larry McVoy <lm(a)mcvoy.com> I am completely non-LISP person (I think my brain was wired in C before C existed :-), but... > Nobody has written a serious operating system Well, the LISP Machine OS was written entirely in LISP. Dunno if you call that a 'serious OS', but it was a significantly more capable OS than, say, DOS. (OK, there was a lot of microcde that did a lot of the low-level stuff, but...) > or a serious $BIG_PROJECT in Lisp. Have you ever seen a set of Symbolics manuals? Sylph-like, it wesn't! > Not one that has been commercially successful, so far as I know. It's true that Symbolics _eventually_ crashed, but I think the biggest factor there was that commodity microprocessors (e.g. Pentium) got faster so much faster than Symbolics' custom LISP hardware, so that the whole rationale for Symbolics (custom hardware to run LISP fast) went away. They still exist as a software company selling their coding environment, FWTW. > C performs far better even though it is, in the eyes of lisp people, far > more awkward to do things. I think it depend on what you're doing. For some kinds of things, LISP is probably better. I mean, for most of the kind of things I do, I think C is the bees' knees (well, except I had to add conditions and condition handlers when I went to write a compiler in it), but for some of the AI projects I know a little about, LISP seems (from a distance, admittedly) to be a better match. Noel

7 years, 4 months

5
4
0 0

Re: [TUHS] Happy birthday, Niklaus Wirth!

by Paul McJones

On Feb 15, 2018, Ian Zimmerman <itz(a)very.loosely.org> wrote: >> >> So, how's this relevant to Unix? Well, I'd like to know more about the >> historical interplay between the Unix and Lisp communities. What about >> the Lisp done at Berkeley on the VAX (Franz Lisp). > > I know one of the Franz founders, I'll ask him when I have a chance. There is some information about Franz Lisp and its origins here: http://www.softwarepreservation.org/projects/LISP/maclisp_family/#Franz_Lis… (And lots more information about many other varieties of Lisp at the same web site.)

7 years, 4 months

1
0
0 0

Re: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!)

by Dan Cross

On Sat, Feb 3, 2018 at 5:59 PM, Dave Horsfall <dave(a)horsfall.org> wrote: > On Sat, 3 Feb 2018, Arthur Krewat wrote: > >> I would imagine that Windows wouldn't be what it is today without UNIX. >> Matter of fact, Windows NT (which is what Windows has been based on since >> Windows ME went away) is really DEC's VMS underneath the covers at least to >> a small extent. >> > > I thought that NT has a POSIX-y kernel, which is why it was so reliable? > Or was VMS a POSIX-like system? I only used it for a couple of years in > the early 80s (up to 4.0, I think), and never dug inside it; to me, it was > just RSX-11/RSTS-11 on steroids. The design of the original NT kernel was overseen by Dave Cutler, of VMS and RSX-11M fame, and had a very strong and apparent VMS influence. Some VAX wizards I know told me that they saw a lot of VMS in NT's design, but that it probably wasn't as good (different design goals, etc: apparently Gates wanted DOS++ and a quick time to market; Cutler wanted to do a *real* OS and they compromised to wind up with VMS--). It's true that there was (is? I don't know anymore...) a POSIX subsystem, but that seemed more oriented at being a marketing check in the box for sales to the US government and DoD (which had "standardized" on POSIX and made it a requirement when investing in new systems). Now days, I understand that one can run Linux binaries natively; the Linux-compatibility subsystem will even `apt-get install` dependencies for you. Satya Nadella's company isn't your father's Microsoft anymore. VSCode (their new snazzy editor that apparently all the kids love) is Open Source. Note that there is some irony in the NT/POSIX thing: the US Government standardized on Windows about two decades ago and now can't seem to figure out how to get off of it. A short story I can't resist telling: a couple of years ago, some folks tried to recruit me back into the Marine Corps in some kind of technical capacity. I asked if I'd be doing, you know, technical stuff and was told that, since I was an officer no, I wouldn't. Not really interested. I ended up going to a bar with a recon operator (Marine special operations) to get the straight scoop and talking to a light colonel (that's a Lieutenant Colonel) on the phone for an hour for the hard sell. Over a beer, the recon bubba basically said, "It was weird. I went back to the infantry." The colonel kept asking me why I didn't run Windows: "but it's the most popular operating system in the world!" Actually, I suspect Linux and BSD in the guise of iOS/macOS is running on a lot more devices than Windows at this point. I didn't bother pointing that out to him. Would VMS become what it was without UNIX's influence? Would UNIX become >> what it later was without VMS? >> >> Would UNIX exist, or even be close to what it became without DEC? >> > > I've oft wondered that, but we have to use a new thread to avoid > embarrassing Ken :-) > The speculation of, "what would have happened?" is interesting, though of course unanswerable. I suspect that had it not been for Unix, we'd all be running software that was closer to what you'd find on a mainframe or RT-11. - Dan C.

7 years, 4 months

31
62
0 0

Clueless programmers

by Ron Natalie

> already 20 years ago I met a guy (masters degree, university) who never freed dynamically allocated memory. He told me he is 'instantiating a object', but had no idea what an heap is, and what dynamically allocated memory means. Years ago, I had an new programmer who I just couldn't teach. He never understood the difference between an array and pointer, and apparently couldn't be bothered to learn. After string him along for three months, I was on my way into his office to fire him when I found out he had quit, but not before he checked a bunch of drek into our source code control system. I thought I backed all his commits out at the time. Years later I was running "purify" on our product looking for memory leaks. I found this small utility function that predated the source code control system leaking. This, I thought was odd, as it had been there FOREVER and was well tested. I brought up the source code system and checked it anyhow and found the afore mentioned programmer had checked in one change: he deleted the "free" call in it. I KNOW what happened. He did something else to corrupt the malloc heap in his code and often this causes a core dump in a subsequent malloc/free call. Apparently this was the place it struck him, so he just deleted the free call there.

7 years, 4 months

4
4
0 0

Oddness in V6 'mv'

by jnc＠mercury.lcs.mit.edu

So, in: http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/s2/mv.c what's the point of this piece of code: p = place; p1 = p; while(*p++ = *argp3++); p2 = p; while(*p++ = *argp4++); execl("/bin/cp","cp", p1, p2, 0); I mean, I get that it's copying the two strings pointed to by 'argp3' and 'argp4' into a temporary buffer at 'place', and leaving 'p1' and 'p2' as pointers to the copies of said strings, but... why is it doing that? I at first thought that maybe the execl() call was smashing the stack (and thus the copies pointed to by 'argp3' and 'argp4'), or something, but I don't think it does that. So why couldn't the code have just been: execl("/bin/cp","cp", argp3, argp4, 0); Is this code maybe just a left-over from some previous variant? Noel

7 years, 4 months

1
0
0 0

pdp-11 assembly as a hll?

by Warner Losh

I don't suppose anybody has written a pdp-11 assembler to C translator... My google fu is insufficient for the day. Warner

7 years, 4 months

5
7
0 0

Re: [TUHS] pdp-11 assembly as a hll?

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall <dave(a)horsfall.org> > I'd like to see it handle "JSR PC,@(SP)+"... Heh! But that does point out that the general concept is kind of confused - at least, if you hope to get a fully working program out the far end. The only way to do that is build (effectively) a simulator, one that _exactly_ re-creates the effects on the memory and registers of the original program. Only instead of reading binary machine code, this one's going to read in the machine language source, and produce a custom simulator, one that can run only one program - the one fed into it. Think of it as a 'simulator compiler'! :-) Noel

7 years, 4 months

1
0
0 0

PDP-7 Unix Paper

by Warren Toomey

All, my journal paper on PDP-7 Unix has just been licensed under CC-BY-SA, so here's a link to the PDF version: http://minnie.tuhs.org/Y5/wkt_hapop_paper.pdf Cheers, Warren

7 years, 4 months

10
10
0 0

Re: [TUHS] pdp-11 assembly as a hll?

by Paul Ruizendaal

>> I was wondering what it would take to convert the v6/v7 basic program >> into something that can be run today. > > Hmmm... If it were C-generated then it would be (somewhat) easy, but it's > hand-written and hand-optimised... You'd have to do some functional > analysis on it e.g. what does this routine do, etc. > >> Its 2128 lines. It doesn't have that fun instruction in it :) > > I know! Say ~2,000 lines, say ~100 people on this list, distributed > computing to the rescue! That's only 20 lines each, so it ought to be a > piece of cake :-) I'm up for that! However, only if the resulting C program can be compiled/run on a V6/PDP11 again. Let's assume that reverse engineering a subroutine of 20 lines takes an hour. That then makes for 100 hours. If 10 people participate and contribute one hour/routine per week, it will be done by May. However, the initial analysis of the code architecture is a (time) hurdle. Paul PS: the Fortran66 of V6 is also assembler only...

7 years, 4 months

1
0
0 0

Why BSD didn't catch on more, and Linux did

by Dan Stromberg

IMO: 1) It kinda did catch on, in the form of macOS, but there was a time when it was nearly dead as the major vendors moved to System V. For some reason, Sun was the last major vendor to make the move, but they caught most of the flack. 2) I think the main reason BSD nearly died, was the AT&T lawsuit. At the time, Linux appeared to be a safer bet legally. 3) Linux got a reputation as an OS you had to be an expert to install, so lots of people started it to install it to "prove themselves". This was sort of true back when Linux came as 2 floppy images, but didn't remain true for very long. 4) I believe the SCO lawsuit "against Linux" was too little, too late to kill Linux's first mover advantage in the opensource *ix department. 5) I think FreeBSD's ports and similar huge-source-tree approaches didn't work out as well Linux developers contributing their changes upstream.

7 years, 4 months

18
32
0 0

qd32 trouble

by Jacob Ritorto

Hi all, Would anyone here be able to help me troubleshoot my qd32 controller? I have a pdp11/73 that's mostly working, boots 2.11 from rl02 okay, but I need my big disk to work so I can load the rest of the distro. I've been following the manual for the qd32 to enter the geometry of my real working m2333 (jumpered correctly according to the manuals), but when I load the special command into the qd32's SP register that's supposed to load the geometry table from the pdp11 memory to the novram, I get a bad status value from the qd32's SP register and it remains unresponsive when I try to store the geometry. If I go ahead and try the built-in qd32 format command, it responds similarly. When I pull in mkfs from tape (vtserver) and try anyway, despite the failures, to run mkfs on the m2333, I get an !online error from the standalone unix mkfs. The disk does respond (the select light flashes and I can hear heads actuating), but without geometry and format, I'm obviously dead in the water. Any suggestions on how to proceed? thx jake

7 years, 4 months

1
0
0 0

Re: [TUHS] Device special files

by Doug McIlroy

> Why is it that umount(2) took the device special file name rather than the mount point directory name, anyway? Symmetry. You unmount what you mount. A competing model is that of links. Link makes an old file available under a new name. But you unlink by the new name. Necessarily so, because there may be many new names for one old file. This is reminiscent of Don Norman's screed about the unnaturalness of Unix. He didn't like strcpy because the arguments come in the opposite order to those of cp. But stcpy is part of C, and in C the destination of assignment comes before the source. But Norman didn't rail at C. You pays your money and takes your choice. Doug

7 years, 4 months

1
0
0 0

Device special files

by ron minnich

these were in by the time I can along but I was wondering when they got it. They've also always felt a bit like a thing that did not fit to me. I'm pretty sure I was not alone, given that the Unix authors worked out a way to get rid of them in later efforts. I know what came after, in Plan 9; what came before, in Unix, that led to special files?

7 years, 4 months

15
29
0 0

RIP John von Neumann

by Dave Horsfall

We lost computer pioneer John von Neumann on this day in 1957; the "von Neumann" architecture (stored program etc) is the basis of all modern computers, and he almost certainly borrowed it from Charles Babbage. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 5 months

1
0
0 0

Re: [TUHS] Device special files

by jnc＠mercury.lcs.mit.edu

> From: Greg Lehey >> V3 and earlier still *called* them special files, but it seems they >> were essentially just magic inode numbers (there was no physical file >> on disk, just any directory entry with the given inode would be the >> special file). > Isn't that still the case? >From reading the manual page (URL sent earlier), in V3 and before it really was just an inode _number_ (less than 50, IIRC). The first inode, in the first disk block after the super-block, was inode #51. This is of course different from later Versions, where there is an _inode_ for devices, but still no actual _file_. Noel

7 years, 5 months

1
0
0 0

Happy birthday, Ken Thompson!

by Dave Horsfall

Co-inventor of Unix, he was born on this day in 1943. Just think: without those two, we'd all be running M$ Windoze and thinking that it's wonderful (I know, it's an exaggeration, but think about it). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 5 months

15
20
0 0

And .. a reminder of the charter of the TUHS list

by Warren Toomey

TUHS: The Unix Heritage Society So topics that relate to Unix, its development, old Unix systems, Unix anecdotes please! Thanks, Warren

7 years, 5 months

1
0
0 0

Re: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!)

by Doug McIlroy

> My experience is that the problems involved in making a program faster are > often quite interesting and fun to work on. But the problems making things > fit in a small space are, IMHO, really deadly. First make things "as simple as possible, but no simpler" (Einstein). Ken and Dennis not only cut out fat, they also found generalizations that combined traditionally disparate features, so the new whole was smaller (and more comprehensible) than the sum of the old parts. The going gets tough in the presence of constraints on space or time. Steve's perception, I think, is colored by the experience of facing hard limits on space, but not on time. Describing one complication of hard time constraints, John Kelly used to say that the Packard Bell 250 was "the only machine I ever used where you transfer to a time of day rather than a memory location". (The delay- line memory had two instruction formats: one was operation + address-of- next-instruction, the other was just the operation--the next instruction being whatever came out of the delay line when the operation ended. The latter mode minimized both execution time and code space, but the attention one had to pay to time was, to borrow Steve's phrase, "really deadly".) Design tradeoffs for efficiency pose an almost moral conundrum: whether to make things fast or make them easy. For example, the classic Unix kernel typically did table lookup by linear search, whereas Linux (when I last looked) typically used binary search. The price of Linux's choice is that one must take care to keep the tables sorted. Heavy discipline has to be imposed on making entries and deletions. Doug

7 years, 5 months

1
0
0 0

Re: [TUHS] Happy birthday, Ken Thompson!

by Daniel Camolês

What do you mean plan9 is dead? It's even possible make a facebook post from inside plan9 nowadays! https://twitter.com/bigatojj/status/949838932841201664 See vmx(1) Em 3 de fev de 2018 23:25, "Steve Simon" <steve(a)quintile.net> escreveu: Hi, I have to take issue with the “plan9 is dead” statement, I agree it seems on a downward spiral, but are a few who fight on. [sent from my plan9] -Steve

7 years, 5 months

2
1
0 0

Fwd: [math-fun] Outside In written accompaniement

by William Cheswick

Concerning the sphere eversion video, Tamara writes: > > There's a DVD-supplement bundle that includes a single DVD and the two hardcopy supplements for both Outside In and Not Knot. > https://www.amazon.com/Outside-Not-Knot-DVD-Booklets/dp/1568814534 <https://www.amazon.com/Outside-Not-Knot-DVD-Booklets/dp/1568814534> > https://www.crcpress.com/Outside-In-and-Not-Knot-DVD--two-Booklets/The-Geom… <https://www.crcpress.com/Outside-In-and-Not-Knot-DVD--two-Booklets/The-Geom…> > > That's the only way to get access to the written supplements, they're not posted online. I don't even have the PDF of either one of these in my own possession, I tried to hunt those down when I converted the original master videos onto the DVD version in 2009 but those files have gotten lost in the mists of time... > > So you could order the bundle just for access to the booklets! The Not Knot one is black and white rather than color, but a similar level of care went into the mathematical exposition for that one too. > > Cheers, Tamara > > ---- > Tamara Munzner > Professor, Department of Computer Science, University of British Columbia > http://www.cs.ubc.ca/~tmm <http://www.cs.ubc.ca/~tmm>, tmm(a)cs.ubc.ca <>

7 years, 5 months

1
0
0 0

Re: [TUHS] Happy birthday, Ken Thompson!

by Daniel Camolês

You can use make as much as you like; Go just doesn't need it. You can use Go to fetch code from internet if you like, or you can do it yourself if you prefer. Regarding the "hardwired" directories, you can change it through an environment variable. Em 3 de fev de 2018 23:20, "Lyndon Nerenberg" <lyndon(a)orthanc.ca> escreveu: That's the second endorsement I've seen for Go; I guess I should learn it. > In the scheme of "current" languages, Go is pretty good. With two major caveats, IMO: 1) The build system. It doesn't work with make(1). That makes it a non-starter for anything other than trivial projects at $WORK. While I appreciate the arguments for the apparent simplicity of the "go" command, that doesn't work for us. Which would have been fine, but for the entirely antagonistic bent they have taken against being able to build Go programs with make(1). Our build environment entirely precludes Go's promiscuous insistence on unfettered internet access, and hardwired directory paths. 2) Hardwired directory paths for the development/build environment (see above). It seems they have unlearned all the UNIX lessons. Sad, really. I would love to toss out Python, Ruby, PHP, Perl, et al. And could make the argument for it, I think. But the build environment will never work in our shop, therefore Go won't either. And that ... sucks.

7 years, 5 months

2
1
0 0

Happy birthday, Ken Thompson!

by Norman Wilson

Or as we old 1127ers would put it: What day is it, Ken?

7 years, 5 months

1
0
0 0

Dynamics between BSD and Linux

by Kevin Bowling

Hi, Interested in some perspective here since the list has influential Linux people like Ted Tso. Linux has been described as influenced by Minix and System V. The Minix connection is well discussed. The SysV connection something something Linus had access to a spec manual. But I’d guess reality would be more gradual — new contributors that liked CSRG BSD would have mostly gravitated to the continuations in 386/BSDi/Net/Free that were concurrent to early and formative Linux development.. so there’d be an implicit vacuum of BSD people for Linux development. What I am curious about is the continuing ignorance of BSD ideas. Linux isn’t exactly insular; a lot of critical people and components came much later on from other SysV flavors (lvm, jfs, xfs, RCU) The kinds of BSD things I am talking about are ufs, kqueue, jails, pf, Capsicum. Linux has grown alternatives, but with sometimes willful ignorance of other technology. It seems clear epoll was not a good design from the start. Despite jails not being taken to the logical conclusion of modern containers like zones, the architecture is fundamentally closer aligned to how people want to securely use containers versus namespaces and cgroups. And Google ported Capscicum to Linux but it’s basically been ignored in lieu of nebulous concepts like seccomp. And then there seems to be outright hostility toward other platforms from the postmodern generation with things like systemd. This seems strange to me as BSD people are generally open to other /ideas/, we have to be careful with Linux code due to license incompatibility, but the converse is does not seem true either in interest in other ideas or license hampering code flow. The history of UNIX is spectacularly successful because different groups got together at the table and agreeed on the ideas. Is there room for that in the modern era where Linux is the monopoly OS? The Austin Group is still a thing but it’s not clear people in any of the Freenix communities really care about evolving the standards. I get that, but not so much completely burrying ones head in the sand to what other OSes are doing. Is there any future for UNIX as an “open system” in this climate or are people going to go there separate ways? Regards, Kevin

7 years, 5 months

7
10
0 0

Happy birthday, John von Neumann!

by Dave Horsfall

We gained John von Neumann on this day in 1903, and if you haven't heard of him then you are barely human... As computer science goes, he's right up there with Alan Turing. There is speculation that he knew of Babbage's work; see https://cstheory.stackexchange.com/questions/10828/the-relation-between-bab… . -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 5 months

9
9
0 0

Re: [TUHS] Odd behaviour on V6 startup, etc

by jnc＠mercury.lcs.mit.edu

> From: Sergio Pedraja > I am very interested in your work exactly for the reasons you explain We will generally be sending messages about it to the CCTalk list (for collectors of 'classic' computers), so if you want to be notified about it, sign up there. We currently have only wire-wrap prototypes (the FPGA is on an off-the-shelf daughter-card); we're hoping to produce PCB production versions 'soon'. We do have the technology for getting PCB's, which we have used for doing 'indicator panels': http://ana-3.lcs.mit.edu/~jnc/tech/DECIndicatorPanels.html We have those working (they've been a big help in debugging, actually :-), and they'll be available too. I don't personally have one of them yet, I'm _really_ looking forward to watching the lights blink as UNIX boots... :-) > The only difference is that my PDP-11 is one 23/PLUS. There are some > differences between this one and the PDP-11/23 and perhaps your emulator > woudln't work in this PDP-11 model. No, AFAIK the /23 and /23-PLUS are effectively identical, as far as the QBUS goes. (Obviously the -PLUS has devices, etc, the plain /23 doesn't, but they don't enter into whether our board will work with one.) We also plan at UNIBUS version; the two busses are similar enough that we'll probably start with a PCB version for that one. > I will test the working state of my PDP. If all is fine perhaps I could > help doing with some tests on it. Sure; use CCTalk. Noel

7 years, 5 months

1
0
0 0

Odd behaviour on V6 startup, etc

by jnc＠mercury.lcs.mit.edu

As I mentioned recently, Dave Bridgham and I are doing an RK11 emulator (and soon an RP11, which just will take editing the Verilog a tiny bit) using an SD card for storage, for heritage computer collectors who want to run their PDP-11's but don't want to risk a head crash (since replacement heads are now un-obtainium) - and also for people who have an -11, but no mass storage. So the last stage was bringing up V6 on a hardware PDP-11/23, using the emulated RK11, and we were having an issue (which turned out to be partial block reads/writes not working properly; this has since been fixed, and we have successfullly booted V6 on the -11/23 with only an SD card). In the process of debugging that issue, I added logging to the RK driver, and noticed that in the process of attempting to boot single-user, the system was trying to do some swapping - two writes, and two reads - before it even tried doing the fork() to create the shell process, followed by opening /dev/tty8 and doing the exec() of /bin/sh. This confused me, since both newproc() and expand() have code which uses a memory-memory copy if there is enough free memory - and on first booting, there definitely was. Why was it swapping? So I added some more logging, and the cause turned out that at one point, I had re-compiled /etc/init - and without thinking about it too hard, had made it a pure-text program. And that's what did it: in exec() (called when process 1 tries to exec() /etc/init), it calls xalloc(), which i) if the text was not already available, gets together the pure text, and puts a copy on the swap device, and ii) if the text is not already in core, swaps the rest of the process out, because, as the code explains: * if the calling process * is misplaced in core the text image might not fit. * Quite possibly the code after "out:" could check to * see if the text does fit and simply swap it in. If you're looking at the code, the process doesn't have a data segment at that point, just the U area; the data will be set up later in the exec() code, after the call to xalloc() returns, after the process is swapped back in. In fact, the process will _never_ have anything other than a U area when in this code; the only call to xalloc() in the system is immediately preceeded by an "expand(USIZE)" which throws away everything except the U area. So I'm contemplating doing what the comment suggests - adding code to check to see if there's enough memory available to hold the pure text, and if so, avoiding the swap-out/in of the process' U-only data segment. If done 'right', it should also be possible to allow avoiding the reading-in of the text from the swap device, when first exec'ing a pure text... Probably not as interesting a project as doing the splice() system call was, but no doubt it will teach me about a corner of the system I don't know very well (back in the day, doing networking stuff, I was mostly looking at I/O code). Although there is potentially a certain amount of amusement in an additional enhancement, which is trying to make sure there's enough room for both the text and the data; immediately upon the return from xalloc(), the process is expanded to have room for the data. Which might involve _another_ swap-out/in sequence... So perhaps the U area should simply be moved out of the way via a direct memory-memory copy, rather than swapping it out/in, just before doing it again! You are not expected to understand this... :-) I guess I should first take a look at the PWB1 pure text code, which is heavily modified from the stock V6, to see what it does - this all may have already been done there. Noel

7 years, 5 months

2
1
0 0

Calgary buffer modifications

by Paul Ruizendaal

For a while I had been wondering about the origins of a modification to the V6 kernel that places the kernel buffers in a separately mapped area, freeing up space for other things. It is used in some of the early networking code, i.e. both the UoI code and the V6 BBN code (as available on the TUHS Unix Tree). I came across the following reference in https://www.osti.gov/scitech/servlets/purl/12130675: “One widely distributed (though undocumented) solution to this hardware limit on the model 40 was a version of Unix by Robert Sidebotham, Faculty of Environmental Design, University of Calgary. His solution was to move the I/O buffers out of kernel space.” This would explain the modifications being bracketed with "#ifdef UCBUFMOD”. Some questions for the old hands: - Was this patch indeed widely known / distributed? - Widely distributed is not the same as widely used: was it?

7 years, 5 months

3
2
0 0

Happy birthday, Douglas Engelbart!

by Dave Horsfall

Born on this day in 1925, he was a pioneer in human/computer interaction, and invented the mouse; it wasn't exactly ergonomic, being just a square box with a button. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 5 months

2
1
0 0

V6 UNIX main() oddness

by jnc＠mercury.lcs.mit.edu

So, while bringing up V6 on a hardware PDP-11/23 with an RK11 emulator using an SD card for storage which Dave Bridgham and I are doing, I found this piece of code in main() on V6 Unix: rootdir = iget(rootdev, ROOTINO); rootdir->i_flag =& ~ILOCK; u.u_cdir = iget(rootdev, ROOTINO); u.u_cdir->i_flag =& ~ILOCK; I don't get why two separate calls to iget(), with the same arguments; why not replace the second pair of lines with: u.u_cdir = rootdir; rootdir->i_count++; What am I missing? Noel

7 years, 5 months

3
2
0 0

LSX swapping

by Paul Ruizendaal

>>> LSX has a maximum of three processes that are swapped in and out in a >>> stack-like fashion. Only one process is ever in core. > > I'm having a hard time working out how this works. If process A is swapped > out, and then B, B has to be swapped in before A can be? But only one process > is ever in core at a time? To get A in, B has to be moved out? But then B > would be the last one out, and would have to come in before A? > > Anyway, I don't understand why the OS could/would care which order processes > we swapped in - unless it's something like the 'onion skin' memory allocation > algorithm of CTSS (which also had only a single process resident at a time, > IIRC), where, when a small process had to be swapped in, and a large one was > already in, it only swapped out enough of the large one to make room for the > small one. The process could recurse, hence the name. The LSI-11 had 40KB of core. The lower 16KB held the LSX kernel, the upper 24K was for the active process. LSX has 3 process slots and 2 swap slots (on floppy!). Optionally, LSX could be built with an additional background process ("BGOPTION"), but this does not work very well. Process numbers and swap slots have a 1:1 relationship. There is a global variable, cpid, with the process number of the current process, initially zero. Upon boot, LSX will load a shell as process 0. (There is no swapper process and no init in LSX). The original LSI-11 kernel code is here: http://minnie.tuhs.org/cgi-bin/utree.pl?file=LSX/sys I can refer to source lines in the repository for my TI990 port of it: https://1587660.websites.xs4all.nl/cgi-bin/9995/artifact/b6ec9496e23efe8c When a process forks, it writes the current core image out to the corresponding swap slot (this swaps out the parent) and the core image is repurposed as the new process (i.e. cpid is incremented and the proc table filled in): https://1587660.websites.xs4all.nl/cgi-bin/9995/artifact/3617ec3245c40a69?l… The child now runs and the parent remains suspended until the child completes. Yes, this implies no pipes. The shell is modified to emulate pipes with files. When the child completes, it stores its u area / exit code in its swap slot (as it is running, the swap slot must be empty. Process 3 has a small swap slot just for this). Next LSX decreases cpid and the parent process is reloaded from its swap slot: https://1587660.websites.xs4all.nl/cgi-bin/9995/artifact/b9c07dfc5add9fc5?l… The actual swapping happens here: https://1587660.websites.xs4all.nl/cgi-bin/9995/artifact/b6ec9496e23efe8c?l… The original PDP11 source has code to compress the empty space between _end and the stack pointer, which I did not get to work properly. LSX works well enough to run the standard V6 binaries unmodified. Some need to be tweaked (e.g. table space in cpp) and the shell needed the pipe change. It can run the V6 c compiler, but not with a wild card argument: that requires 4 stacked processes (sh, glob, cc and cpp/c0/..) and LSX allows only 3. Hope the above makes it a bit more clear.

7 years, 5 months

1
0
0 0

RIP Marvin Minsky

by Dave Horsfall

We lost AI pioneer Marvin Minsky on this day in 2016 from a cerebral haemorrhage, aged 88. Amongst other things, along with John McCarthy he co-founded the MIT AI Lab, co-invented the Logo "turtle", was mentioned in Arthur C. Clarke's novel "2001: A Space Odyssey", and built the first randomly wired neural network learning machine, SNARC, in 1951. He is now thought to be cryogenically preserved as "Patient 144" at Alcor (he started cooling on 27/1/2016). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 5 months

1
0
0 0

Re: [TUHS] Swapping (Was: !mail tuhs@minnie.tuhs.org)

by jnc＠mercury.lcs.mit.edu

> From: Doug McIlroy >> From: Paul Ruizendaal >> LSX has a maximum of three processes that are swapped in and out in a >> stack-like fashion. Only one process is ever in core. I'm having a hard time working out how this works. If process A is swapped out, and then B, B has to be swapped in before A can be? But only one process is ever in core at a time? To get A in, B has to be moved out? But then B would be the last one out, and would have to come in before A? Anyway, I don't understand why the OS could/would care which order processes we swapped in - unless it's something like the 'onion skin' memory allocation algorithm of CTSS (which also had only a single process resident at a time, IIRC), where, when a small process had to be swapped in, and a large one was already in, it only swapped out enough of the large one to make room for the small one. The process could recurse, hence the name. > V1 was a time-sharing system; for which LIFO swapping is > inappropriate. And I don't follow that either... V1 ran on the 11/20 without memory management hardware, though, right? (Although there's that cryptic reference to the KS11 in "Odd Comments and Strange Doings in Unix", although I've never been able to find out anything else about the KS11.) So presumably one would not have wanted more than one process resident at a time, as that decreases the odds of a buggy program trashing another process? Noel

7 years, 5 months

1
0
0 0

origin of C header files

by Wesley Parish

Hi I've just had an interesting experience, explaining C header files to a nephew programmer who didn't understand them. I pointed him in the direction of Minix as an example of a small well-engineered system which would display their use. Which raised the question: when did header files come into use? Who was the first to use header files to store common system-wide or application-wide data definitions? Was it used in any languages prior to C? Thanks Wesley Parish

7 years, 5 months

5
6
0 0

OT: Need help from a *BSD guru

by arnold＠skeeve.com

Hi. Can a modern BSD guru please contact me off-list? I have a set of related tests in the gawk test suite that consistently fail on just about every *BSD system. It has me stumped, and I'd like to see these tests working if possible. (They've been not working for quite a while. That I get no complaints from BSD users tells me that gawk isn't popular in that world, but that's another story. :-) Thanks, Arnold

7 years, 5 months

2
4
0 0

!mail tuhs@minnie.tuhs.org

by Doug McIlroy

Re: [TUHS] Kernel Sizes > I've often thought that LSX was V5 'regressed' to the concepts of > V1, which was facing similar hardware constraints. Is that a > reasonable view? > LSX has a maximum of three processes that are swapped > in and out in a stack-like fashion. Only one process is ever in core. > Is that how V1 was organized? The rocess limit was higher in V1. And V1 was a time-sharing system; for which LIFO swapping is inappropriate. So LSX seems to have "regressed" to some pre-Unix state. doug

7 years, 5 months

1
0
0 0

Re: [TUHS] Kernel Sizes

by Rudi Blom

16K kernels? Well, I came late to the UNIX world. I only remember getting a SCO UNIX 3.2V4.2 kernel onto a single 3-1/2" diskette and still have all I wanted including (with scripts on a second diskette of course :-) ). That was 25 years ago. Mind you, from there I moved to Digital UNIX /vmunix 9,613.712, Tru64 17.930.976 to HP-UX 11iv2 66.161.464 and HP-UX 11iv3 127.929.032 Of course, I also got lots more functionality I'm supposed to want and need :-) Cheers, rudi

7 years, 5 months

1
0
0 0

Kernel Sizes

by Warner Losh

For a presentation I'm doing this summer on FreeBSD, I thought it would be cool to get the kernel sizes for various old flavors of Unix. I see numbers for v5, v6 and v7 in the tuhs tree view, and it appears these versions are complete enough for me to extract the kernels themselves. However, I see nothing prior to that. The archives seem to be somewhat incomplete, but I'm wondering if people have sizes for earlier versions. Later versions are more problematic because they move to new hardware, instruction sets, etc. For this graph to be meaningful, it would need to be pdp-11 only, though I'm of the opinion more data is better than less. I'll also be extracting the different V7 commercial kernels: V7M, Ultrix and Venix and the BSD 2.x releases, but those appear to be intact enough in the archives to extract data on my own. I've heard rumors there's a SysV for the pdp-11, but I've not been able to locate images for that. I don't need the actual images, just sizes with some reference for the source of the data. It's just for one slide in the talk, so I don't want to burn a ton of time on it... The larger picture is that I've written what's effectively modprobe for FreeBSD and will be talking about it in detail. How it's like modprobe, how it's different, how all the pieces fit together, history of similar efforts, etc. Part of the driving force here is the bloated FreeBSD GENERIC kernel. Of course, I'll share the final report I'm planning on sizes with the group. Thanks for any data you can provide. Warner

7 years, 5 months

11
13
0 0

Re: [TUHS] Kernel Sizes

by Paul Ruizendaal

> A self-imposed limit of 16K held in v1, and was quite fully utilized. > When the iernel was rewritten in C, the limit (perhaps larger by then) > influenced the C compiler. More than one optimization was stimulated > by the need to keep the kernel in bounds. > > Doug The LSX kernel was kept within a self-imposed limit of 16KB as well. I've often thought that LSX was V5 'regressed' to the concepts of V1, which was facing similar hardware constraints. Is that a reasonable view? For example, LSX has a maximum of three processes that are swapped in and out in a stack-like fashion. Only one process is ever in core. Is that how V1 was organized? I realize that LSX was API compatible with V5/V6 and I don't mean 'regressed' in that sense. Paul

7 years, 5 months

1
0
0 0

Re: [TUHS] Kernel Sizes

by Doug McIlroy

> I seem to remember that at some point early on, we spent some of our > capital budget on buying another 16K bytes for the PDP-11. As I > recall, the deal was that the OS got 8K and users got 8K. I also > recall that that purchase was 20% of our capital budget for the > year... > Doug, did I remember this correctly? > Steve Things did happen that way. I don't specifically remember the numbers, but those you state have the ring of truth. Memory came in (expensive) 4K increments. When the keepers of Unix in the Charlotte wire center wanted to add 4K, their management consented only on the condition that the wizards in Research would confirm that roposed new functionality really required it. doug

7 years, 5 months

1
0
0 0

Re: [TUHS] Kernel Sizes

by Doug McIlroy

>> A self-imposed limit of 16K held in v1 > 16k words or 16k bytes? Bytes. doug

7 years, 5 months

1
0
0 0

Subject: Re: KernelSizesA self-imposed limit of 16K held in v1, and was quite fullyutilized.Subject:Re: Kernel Sizes

by Doug McIlroy

A self-imposed limit of 16K held in v1, and was quite fully utilized. When the iernel was rewritten in C, the limit (perhaps larger by then) influenced the C compiler. More than one optimization was stimulated by the need to keep the kernel in bounds. Doug

7 years, 5 months

3
2
0 0

OT - Has anyone seen / have a copy of computer lore story about a DC consolidation?

by Grant Taylor

Sorry for the off topic post. I'm hoping that someone here might have seen a (what I consider to be) a computer lore type story about a contractor that was brought in part way through a project to consolidate three DCs into one. - In the end he managed to do it early and under budget. The kicker is that they quite literally physically moved and re-connected everything the way that it was. Meaning that there were still WAN circuits (local only of course) between equipment that was previously in different DCs. I would like to find a copy of this story and save it in my archive. But I've not been able to do so. Thus I'm asking a wider audience to see if anyone might be able to give me a pointer. -- Grant. . . . unix || die

7 years, 5 months

1
0
0 0

RIP Ed Yourdon

by Dave Horsfall

We lost Ed Yourdon on this day in 2016; a computer pioneer, he helped to design the underpinnings of relational databases, and pretty much wrote the book. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 5 months

2
1
0 0

Happy birthday, John Lions!

by Dave Horsfall

Dr. Prof. John Lions was born on this day in 1937; I had the pleasure of having him as one of my Computer Science lecturers in the early 70s, and he drilled into us the Principle of Least Astonishment (or POLA), better known as "why the fsck did it do that?" (but he was far too genteel to express it that way). And yes, that's my name in the credits; I helped with the proof-reading and provided the use of the high-quality printer in the CSU. You are not expected to understand this. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 5 months

2
1
0 0

Scot Hacker's 1999-2001 "BeView" columns for Byte.com (BeOS)

by Arrigo Triulzi

Scot Hacker has re-published his BeOS columns for Byte. BeOS was an interesting operating system with a clear Unix inheritance built for a dual-PowerPC system, similar to the Macs of that era. http://birdhouse.org/beos/byte/ Its inheritance can be found in Haiku (https://www.haiku-os.org) Arrigo

7 years, 5 months

2
2
0 0

Some resources for V6/PDP/SIMH newbs like me

by Will Senn

All, While it's fresh, I thought I'd share some resources I've found helpful in learning about the venerable v6 as a relative newb... Learning Unix V6 in the modern era is an interesting and enormously educational experience. In the process of using it I have had to learn how to host it in a simulator (SimH in my case, but there are others), install it, communicate with it, configure it, build special files for it, attach devices to it, communicate with the devices attached to it and to SimH, build a kernel, install the kernel, boot the kernel, work with a variety of media intended to work with it, extend it, and so on. In addition, I have had to learn a bit about the PDP-11 (as arguably the most convenient architecture for learning about V6), about its architecture, its instruction set, its devices, its memory structure, and so on. None of this exploration would have been possible without the excellent work of Bob Supnik, Mark Pizzolato, and co. on the SimH pdp-11 simulator, the Simh mailing list, Warren Toomey and TUHS for making the bits available, the TUHS mailing list, PUPS, Bitsavers, and a slew of readily available documentation and texts including these notables: Setting Up Unix 6th Edition from the V6 Programmer's Manual The Unix V6 Programmer's Manual in its entirety The SimH and SimH PDP-11 Manuals A large number of blogs with SimH specific V6 installation logs The V6 Source Code and man pages (don't forget to install man - the 1bsd version works, and is superior)! The DEC PDP-11/05-10-35-40 1973 Handbook (the 11/40 handbook is not as detailed with respect to memory management) Lions's Commentary on the Sixth Edition source code Now that I'm over the beginner's hump, so to speak, I'm exploring things differently and I thought I'd share some resources that I am currently finding useful and interesting in my explorations... To bone up on assembly language, Lions's commentary is exceptionally helpful in explaining assembly as it is implemented in V6. The manual itself is really thin, and the source is a bit cryptic, for the newcomer. Lions explains the idioms used in the main source of V6. However, without a background in assembly language, Lions is pretty meaningless, so I went looking for something that was PDP specific that would bridge the gap and help me understand Lions's words. I found a number of texts that were really good. Most require a working RT11 instance to actually try out the coding examples and do the exercises (SimH and Bitsavers to the rescue): Arthur Gill - Machine and Assembly Language Programming of the Pdp-11 Charles A. Kapps and Robert L. Stafford - Assembly Language for the PDP-11 Glenn H. MacEwan - Introduction to Computer Systems: Using the PDP-11 and Pascal James F. Peters - The Digital Way: Macro-11 Assembler Programming (PDP-11) Michael G. Schneider - The Principles of Computer Organization: With Assembly Language Programming for the PDP-11 PDP-11 Processor Handbook (pretty much any edition) Thomas A. Frank - Introduction to the PDP-11 and its Assembly Language All of these are useable with a running RT11 instance. But, I think the Peters and Frank books are the standouts. Peters because all of the exercises that I have tried (dozens) have worked as printed and Frank because he is rigorous in his treatment of the subject and builds up from digital logic all the way through program execution. Frank is an excellent complement to Lions work because he explains the details that Lions assumes. To learn about digital logic, and a special thanks to Warren for his work on Crazy Small CPU, I have been introduced to logisim. It is a great playground for exploring digital logic. I had no idea that a sketchpad for digital logic simulation was available and accessible to the layperson. Logisim development stopped around 2014 and while there are a number of successors out there, I am using logisim-evolution: https://github.com/reds-heig/logisim-evolution The rabbit trails never seem to end... in order to learn how to use logisim, I went through the excellent tutorial and then went looking for a book of experiments in digital logic and found: digital computer lab workbook from 1969 http://bitsavers.trailing-edge.com/pdf/dec/handbooks/Digital_Computer_Lab_W… digital equipment corporation computer lab teacher's guide from 1968 http://www.so-much-stuff.com/pdp8/pdf/ComputerLabTeachersGuide.pdf These two are useable with very little modification as a source of digital logic exercises that work great with logisim and are related to the architectural lineage of the PDP-11. These resources fit together nicely in my pursuit to better understand digital logic, the pdp-11, assembly language, and unix v6. In sum: Source code for v6 for what really is supposed to happen in v6 operation Lions for understanding Unix V6 sources and for unix assembly language information PDP-11 Hanbook for quick reference on PDP-11 assembly language instruction set Frank for assembly language details and for details on digital logic and its relationship to the PDP-11 architecture. Logisim to test logic constructs The digital lab workbook for practice with digital logic Later, Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF

7 years, 5 months

2
2
0 0

Re: [TUHS] origin of C header files

by Lars Brinkhoff

The book "Expert C Programming" claims Alan Snyder suggested the addition of a preprocessor.

7 years, 5 months

1
0
0 0

2018: eighteen months to the Unix 50th anniversary

by Warren Toomey

Hi all, Happy New Year. As it's now only eighteen months to the Unix 50th Anniversary, I thought I'd poll you all to get an update of what is being done to celebrate the anniversary, and/or what could we organise that has not yet been organised. Cheers, Warren

7 years, 5 months

10
16
0 0

Happy birthday, C.A.R. Hoare!

by Dave Horsfall

Sir Charles Antony Richard Hoare FRS FREng was born on this day in 1934; a computer pioneer (one of the greats) he gave us things like the quicksort algorithm and ALGOLW (a neat language). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 5 months

5
6
0 0

Re: [TUHS] 2018: eighteen months to the Unix 50th anniversary

by jnc＠mercury.lcs.mit.edu

> From: George Michaelson > Try this on the birth of the ICL 2900. Along the same lines, there's this: https://www.netjeff.com/humor/item.cgi?file=GenesisForProjects with its great closing line.. Noel

7 years, 5 months

2
1
0 0

Happy birthday, Donald Knuth!

by Dave Horsfall

Computer pioneer Donald Knuth was born on this day in 1938; amongst other things he gave us the TeX typesetting language, and he's still working on "The Art Of Computer Programming" fascicles (I only got as far as the first two volumes). I really must have a look at his new MMIX, too; I love learning new programming languages (I've used about 50 the last time I looked, and I'm happy to post a list for my coterie of disbelievers). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 5 months

2
1
0 0

Re: [TUHS] [TUHS} 2018: eighteen months of the Unix 50th anniversary

by Doug McIlroy

> I will be happy to forward pertinent suggestions. Here's one. If Bell Labs holds some kind of symposium on the lines of the dmr memorial, how about a plenary session with TV participation from remote venues (think Berkeley/Silicon Valley and Wollongong/Sydney--a nine-hour span of time zones). Any thoughts about this or other possibilities? Doug

7 years, 5 months

2
1
0 0

Re: [TUHS] [TUHS} 2018: eighteen months of the Unix 50th anniversary

by Doug McIlroy

I don't think I'm violating anyone's confidentiality by revealing that Marcus Weldon, current president of the Labs, at the suggestion of Martin Carroll, expects the Labs to embark soon on plans to mark the occasion. I, and no doubt Martin, will keep you posted. Meanwhile I will be happy to forward pertinent suggestions. Doug

7 years, 5 months

1
0
0 0

RIP John Mauchly

by Dave Horsfall

We lost a co-inventor of ENIAC, John Mauchly, on this day (that's 8th January like my headers say) in 1980. ENIAC is claimed to be the "first general purpose electronic digital computer", but I guess it comes down to a matter of definition[*], as every culture likes to be the "first" (just ask the Penguins, for example); for "computer" you could go all the way back to the Mk-I Antikythera (Hellenic variation, from about the 100BC production run)... [*] Analogue/digital/hybrid Mechanical/electrical/electronic/hybrid General/special Wired/programmable/Turing Prototype/production Harvard/Neumann/quantum Etc... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 6 months

1
0
0 0

Re: [TUHS] OT: critical Intel design flaw

by jnc＠mercury.lcs.mit.edu

> From: Andy Kosela > it appears this is a fundamental Intel bug that exists in all x86_64 > CPUs. I'm highly amused by the irony. Intel throws bazillions of transistors at these hyper-complex CPUs in an attempt to make them as fast as possible - and (probably because of the complexity) missed a bug, the fix for which involves... slowing things way down! I wonder how many other bugs are lurking in these hyper-complex designs? Didn't anyone at Intel stop to think that complexity is bad, in and of itself? But I guess the market demands for faster and faster machines outweighed that - until it bit them in the posterior. The real question is 'how many more times will it have to happen before they get a clue'? There's an interesting parallel between this, and uSloth's struggle with security and bugs. For a long time, it seemed it was more important to the market to add features (i.e. complexity), and security be damned - until poor security really started to become an issue. So now they're trying to catch up - but seemingly still haven't got there, in terms of the fundamental architecture of the OS, as the never-ending stream of bug patches attests. The sad thing is that how to provide good security (not perfect, but much, much better than what we have) was worked out a long time ago, and Intel hired Roger Schell to add the necessary hardware underpinnings when they did the 386: http://conservancy.umn.edu/bitstream/11299/133439/1/oh405rrs.pdf Mutatis mutandis. Noel

7 years, 6 months

14
35
0 0

Re: [TUHS] OT: American Culture

by Norman Wilson

Random832 (a good year for randomness, that): Who says right is positive? ===== Good question. Norman Wilson Toronto ON Left-handed

7 years, 6 months

4
3
0 0

Re: [TUHS] OT: critical Intel design flaw

by Norman Wilson

Clem Cole: IIRC this is part of the argument Dykstra made with the THE paper years ago, Parnas in his information hiding paper -- i.e. why microkernels and proper layering are a good idea. Keep is simple and do one thing well/protect yourself against other subsystems not being 100%. ===== Indeed. Complexity creates needless RISC, er, risk. Norman Wilson Toronto ON

7 years, 6 months

1
0
0 0

OT: critical Intel design flaw

by Andy Kosela

http://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/ Including here as it concerns Unix kernel and leaking memory from kernel space to userland. This is big -- it appears this is a fundamental Intel bug that exists in all x86_64 CPUs. It will be interesting to watch the ramifications and impact of this on the industry as a whole. --Andy

7 years, 6 months

3
2
0 0

Re: [TUHS] OT: American Culture

by Doug McIlroy

> A lingering gripe that explains my latent anti-Americanism goes back to > when I had to support Uniplus 2.2/2.4 (sorta SysIII-ish) on the WICAT boxes > in here in Australia. At installation time, we had to express the time > offset as hours *west* of GMT; this left me with a lingering belief that > Americans didn't want to be perceived as being backwards (yeah. it saved an > entire keystroke out of the dozens that were otherwise required). But east postive is an artifact of north up. I remember Australian souvenir shops selling maps on "MacQuarrie's corrective projection", in which south is up. In fact this orientation was not uncommon in Europe between medieval maps that really were oriented, with east up, and later convention that put north up and shoved Australia down under. Surely an Aussie would prefer south up and west positive! Doug

7 years, 6 months

2
1
0 0

Re: [TUHS] OT: American Culture

by Clem Cole

On Sun, Dec 31, 2017 at 7:15 PM, Dave Horsfall <dave(a)horsfall.org> wrote: > > A lingering gripe that explains my latent anti-Americanism goes back to > when I had to support Uniplus 2.2/2.4 (sorta SysIII-ish) on the WICAT boxes > in here in Australia. At installation time, we had to express the time > offset as hours *west* of GMT; this left me with a lingering belief that > Americans didn't want to be perceived as being backwards (yeah. it saved an > entire keystroke out of the dozens that were otherwise required). Dave I'm not so sure it's about being perceived as forward or backwards - its just shallow, provincial and often lazy because the program did not really knowing any better. The problem is too many American', (particularly younger ones that experience our 'excellent' educational system), have often never travelled that much and experiences other places, cultures or social norms. I admit this is extreme example, but about 8 years ago, my daughter had a friend, who was approx 16 at the time, that we took to the big city (Boston) to play in a orchestra concert at Symphony Hall when they both were named 'All State' for the instruments. I don't remember why said friends family did not/could not come - but it made sense and we said we would take her with us. On the drive in-town, we were talking with her and I discovered that she had never gone to Boston before ... ever -- she was excited to see it (we live less than 1hr North mind you. Note quite the boon-docks). She had not gone to a 'Bo Sox' game or anything. Never went to the Science Museum, etc. She grew up in her town (mind you happy) and using TV as her window to world. Which brings me to >>my complaint<<. We, as American's, project so much about 'us' via TV. The said truth is most Americans are not like what they see on TV [e.g. Rice-A-Roni is made up!!, Benihana's is an American invention, and "the big yellow school bus" is dirty/noisy and usually without seat belts]. Sadly, many Americans do not know any better - queue the famous quote about never under-estimating the taste of the American public. But think about what folks outside the US see and think? Many of my European friends in particular all want to visit NYC. [I tell them all, visit Boston or Philadelphia first if you can. Those cities are much more representative of America then LA, NYC or Dallas; if for no other reason they are more 'European' in feel]. When I run into things like what you just described (and I seem to run into then most often with MicroSoft based tools), I think to myself, it must have been a cold day in Redmond, WA and some programmer did not want to make an effort to do make her/his solution really general ;-) Clem FWIW: Not only did we take my kids all over the world as children, we brought the world to them by sponsoring kids from all sorts of countries. But I fear, my wife and I are less the norm then I would wish. ᐧ ᐧ

7 years, 6 months

2
1
0 0

Re: [TUHS] OT: Grace Hopper, Unix epoch, ARPAnet converted to TCP/IP

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall > What timezone did you say you were in again? Ah; didn't realize you wanted the exact time, not just a date! :-) Well, according to this: http://www.rfc-editor.org/rfc/museum/ddn-news/ddn-news.n19.1 it was _planned_ to happen at "00:01 (EST) 1 Jan 1983". Whether it did happen at that moment, or if in reality there was some variance, I don't know (IIRC, I was off sailing in the Caribbean when it actually happened :-). Noel

7 years, 6 months

3
2
0 0

, ARPAnet converted to TCP/IP

by Ron Natalie

It was sort of a soft change over. All the did on January 1, 1983, is disable link 0 on the IMPs. This essentially blocked NCP from working anymore. You could (and many of us were) run IP on the Arpanet for years before that. In fact the weeks before we were getting ready for the change and we had our TCP/IP version of the system up. It crashed. We rebooted it and set about debugging it. It crashed again. Immediately my phone rang. It was Louis Mamakos, then of the University of Maryland. He had tried to ping our system. I called out the information to Mike Muuss who was across the desk from me. We set to find the bug. It turned out that the ICMP echo handling in the 4.1c (I believe this was the version) that we'd cribbed our PDP-11/70 TCP from had a bug where it used the incoming message to make the outgoing one, AND it freed it, eventually causing a double free and crash. It was at this point we realized that BSD didn't have a ping client program. Mike set out to write one. It oddly became the one piece of software he was most known for over the years. The previous changeover was to long leaders on the Arpanet (Jan 1, 1981?). This changed the IMP addressing space from eight bits (6 bits for imp number, 2 for a host on imp) to 16 bits for imp number and 8 for a host on imp. While long leaders were available on a port basis for years earlier, they didn't force the change until this date. The one casualty we had a PDP-11/40 playing terminal server running software out of the University of Illinois called "ANTS." Amusingly the normal DEC purple and red logo panels at the top of the rack were silkscreened with orange ANTS logos (with little ants crawling on it). The ANTS wasn't maintained anymore and stuck in short-leader mode. We used that option to replace that machine with a UNIX (we grabbed one of our ubiquitous PDP-11/34's that were kicking around). I kept the racks and the ANTS logo for the BRL Gateways. I turned in the non-MM PDP-11/40. A year later I get a call from the military supply people. ME: Yes? GUY: I need you to identify $65,000 of computer equipment you turned in. ME: What $65,000 machine? GUY: One PDP-11/40 and accessories. ME: That computer is 12 years old... and I kept all the racks and peripherals. Do you know how much a 12-year-old computer is worth? The other major cut over was in October of 1984. This was the Arpanet-Milnet split. I had begged the powers that be NOT to do the change over on the Jan 1st as it always meant I had to be working the days leading up to it. (Oct 1 was the beginning of the "fiscal" year). Our site had problems. I made a quick call to Mike Brescia of BBN. This was pre-EGP, and things were primarily static routed in those days. He'd forgotten that we had routers at BRL now on the MILNET (all the others were on the ARPANET) and the ARPANET-MILNET "mail bridge" routers had been configured for gateways on the MILNET side.

7 years, 6 months

1
0
0 0

Re: [TUHS] OT: Grace Hopper, Unix epoch, ARPAnet converted to TCP/IP

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall <dave(a)horsfall.org> > the ARPAnet got converted from NCP to TCP/IP in 1983; ... have a more > precise date? No, it was Jan 1. It wasn't so much a 'conversion', as that was the date on which, except for a few sites which got special _temporary_ dispensation to finish their preparations, support for NCP was turned off for most ARPANET hosts. Prior to that date, most hosts on the ARPANET had been running both, and after that, only TCP worked. (Non-ARPANET hosts on the then-nascent Internet had always only been using TCP before that date, of course.) Noel

7 years, 6 months

3
4
0 0

OT: Grace Hopper, Unix epoch, ARPAnet converted to TCP/IP

by Dave Horsfall

Some interesting historical stuff today... We lost Rear Admiral Dr. Grace Hopper USN (Retd) in 1992; there's not much more than can be said about her, but I will mention that she received (posthumously) the Presidential Medal of Honor in 2016. As every Unix geek knows, today is the anniversary of The Epoch[tm] back in 1970, and at least one nosey web site thinks that that is my birthdate too... And according to my notes, the ARPAnet got converted from NCP to TCP/IP in 1983; do any greybeards here have a more precise date? -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 6 months

1
0
0 0

Re: [TUHS] Why did PDPs become so popular?

by Larry McVoy

On Fri, Dec 29, 2017 at 04:04:01AM -0700, Kevin Bowling wrote: > Alpha generally maintained integer/ALU and clockspeed leadership for > most of the '90s > http://www.cs.columbia.edu/~sedwards/classes/2012/3827-spring/advanced-arch… Wow, that first graph is the most misleading graph on CPU performance I've ever seen. Ever. So from 1993 to 2000 the only CPUs released were Alphas? That era was when I was busy measuring performance across cpus and operating systems and I don't ever remember any processor being a factor of 2 better than its peers. And maybe I missed it, I only owned a couple of alpha systems, but I never saw an Alpha that was a game changer. Alpha was cool but it was too little, too late to save DEC. In that time period, even more so now, you had to be 2x better to get a customer to switch to your platform. 2x cheaper 2x faster 2x more reliable Do one of those and people would consider switching platforms. Less than that was really tough and it was always, so far as I remember, less than that. SMP might be an exception but we went through that whole learning process of "well, we advertised symmetric but when we said that what we really meant was you should lock your processes down to a processor because caches turn out to matter". So in theory, N processors were N times faster than 1 but in practice not so much. I was very involved in performance work and cpu architecture and I'd love to be able to claim that we had a 2x faster CPU than someone else but we didn't, not at Sun and not at SGI. It sort of make sense that there weren't huge gaps, everyone was more or less using the same sized transistors, the same dram, the same caches. There were variations, Intel had/has the biggest and most advanced foundries but IBM would push the state of the art, etc. But I don't remember anyone ever coming out with a chip that was 2x faster. I suspect you can find one where chip A is introduced at the end of chip B's lifespan and A == 2*B but wait a few month's and B gets replaced and A == .9*C. Can anyone point to a 2x faster than it's current peers chip introduction? Am I just not remembering one or is that not a thing? --lm

7 years, 6 months

7
13
0 0

Re: [TUHS] Why did PDPs become so popular?

by Rudi Blom

A bit off the PDPs, but to do a minor correction on mail below The commercial version of 'UNIX' on Alpha was maybe first called Digital Unix OSF/1, but quickly changed to Digital Unix at least with v3 and v4.0 (A - G). From there we had a 'break' which only in part was due to take over by Compaq and we had Tru64 UNIX v5.1A and V5.1B. The V5.1B saw updates till B-6. As for the Digital C compiler, I'm still using DTCCMPLR650 installed Compaq C Version 6.5 for Compaq Tru64 UNIX Systems When I get some old source (some even developed on SCO UNIX 3.2V4.2) I like to run it through all compiler /OS-es I got handy. With the Compaq C compiler and HP-UX ANSI C I mostly get pages of warning and a few errors. By the time I 'corrected' what I think is relevant some nasty coredumps tend to disappear :-) Compile for a better 2018, uncle rubl >Date: Fri, 29 Dec 2017 21:30:11 -0500. >From: Paul Winalski <paul.winalski(a)gmail.com> >To: Ron Natalie <ron(a)ronnatalie.com> >Cc: TUHS main list <tuhs(a)minnie.tuhs.org> >Subject: Re: [TUHS] Why did PDPs become so popular? >Message-ID: <CABH=_VRwNXUctFPav5rHX83wfUS0twMQuBhinRZ6QEY1cB3TNQ(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" > >On 12/29/17, Ron Natalie <ron(a)ronnatalie.com> wrote: > The Alpha was hot > stuff for about nine months. Ran OSF/1 formerly DigitalUnix formerly > OSF/1. >Digital UNIX for the VAX was indeed derived from OSF/1. The port to >Alpha was called Tru64 UNIX. >Tru64 UNIX was initially a pure 64-bit system, with no provision for >building or running 32-bit program images. This turned out to be a >mistake . DEC found out that a lot of ISVs had code that implicitly >"knew" that sizeof() a pointer was the same as sizeof(int) was the >same as 4 bytes. Tru64 was forced to implement a 32-bit compatibility >mode. >There was also a problem with the C compiler initially developed at >DECwest in Seattle. It supported ONLY ANSI standard C and issued >fatal errors for violations/extensions of the standard. We (DEC >mainstream compiler group) called it the Rush Limbaugh >compiler--extremely conservative, and you can't argue with it.

7 years, 6 months

3
2
0 0

Re: [TUHS] origin of C header files

by Doug McIlroy

Warning: off-topic info > I was told once that McIlroy and Morris invented macro instructions > for assembly language. And certainly they wrote the definitive > paper on macros, with, as I recall, something like 10 decisions you > needed to make about a macro processor and you could generate 1024 > different macro systems that way. I wonder if that ever got > published The suggestion that I invented macros can also be found on-line, but it's not true. I learned of macros in 1957 or before. GE had added a basic macro capability to an assembler; I don't know whether they invented the idea or borrowed it. In 1959 George Mealy suggested that Bell Labs install a similar facility in SAP (SHARE assembly program). Doug Eastwood wrote the definition part and I handled expansions. Vic Vyssotsky later asked whether a macro could define a macro--a neat idea that was obviously useful. When we went to demonstrate it, we were chagrinned that it didn't work: definition happening during expansion resulted in colliding calls to a low-level string-handling subroutine that was not re-entrant. Once that was fixed, Steve Johnson (as a high-school intern!) observed that it allowed the macro table to serve as an addressable memory, for which the store and load operations were MOP (macro define) and MAC (macro call). Probably before Steve's bright insight, Eastwood had folded the separate macro table into the opcode table, and I had implemented conditional assembly, iteration over a list, and automatic generation of symbols. These features yielded a clean Turing-complete language-extension mechanism. I believe we were the first to achieve this power via macros. However, with GPM, Christopher Strachey showed you don't need conditionals; the ability to generate new macro names is enough. It's conceivable, but unlikely, that this trick could be done with earlier macro mechanisms. As for publication, our macroprocessor inspired my CACM paper, "Macro nstruction extension of compiler languages", but the note that Steve remembers circulated only in the Labs. A nontrivial example of our original macros in action--a Turing machine simulator that ran completely within the assembler--was reproduced in Peter Wegner's programming book, so confusingly described that I am glad not to have been acknowledged as the original author. Doug

7 years, 6 months

1
0
0 0

Re: [TUHS] Why did PDPs become so popular?

by jnc＠mercury.lcs.mit.edu

> From: Paul Winalski > Lack of marketing skill eventually caught up to DEC by the late 1980s > and was a principal reason for its downfall. I got the impression that fundamentally, DEC's engineering 'corporate culture' was the biggest problem; it wasn't suited to the commodity world of computing, and it couldn't change fast enough. (DEC had always provided very well built gear, lots of engineering documentation, etc, etc.) I dunno, maybe my perception is wrong? There's a book about DEC's failure: Edgar H. Schein, "DEC is Dead, Long Live DEC", Berett-Koehler, San Francisco, 2003 which probably has some good thoughts. Also: Clayton M. Christensen, "The Innovator's Dilemma: When New Technologies Cause Great Firms to Fail", Harvard Business School, Boston, 1997 briefly mentions DEC. Noel

7 years, 6 months

6
6
0 0

tuhs@minnie.tuhs.org

by Mutiny

'FUNCTION: To save the programmer effort by automatically incorporating         library subroutines into the source program.'in Cobol whole 'functions' (subroutines) and even code snipplets are 'copied' into the main source file by the copy statement. That's different to preprocessor macros, -definitions, -literals and, since ansi c, function prototypes. 

7 years, 6 months

1
0
0 0

tuhs@minnie.tuhs.org

by Mutiny

'FUNCTION: To save the programmer effort by automatically incorporating         library subroutines into the source program.'in Cobol whole 'functions' (subroutines) and even code snipplets are 'copied' into the main source file by the copy statement. That's different to preprocessor macros, -definitions, -literals and, since ansi c, function prototypes. 

7 years, 6 months

1
0
0 0

History of exploits - request for authors

by Arrigo Triulzi

Dear all, I am starting a new “history” section of the “weird machines and security” publication PoC||GTFO (https://www.alchemistowl.org/pocorgtfo for my mirror, https://www.nostarch.com/gtfo for a printed compilation of the first 15 issues). Ideally we would like some articles about the history of security exploits where the historical importance is emphasised: we always get authors willing to tell us about the latest and greatest web exploit but they often lack any historical perspective about what has been done before. As PoC||GTFO has a strong emphasis on weird machines and generally forgotten hardware and software I thought that the contributors to TUHS would be ideally placed to write something about their preferred security exploits in the past. I have fond memories of taking over a machine using and NFS /home filesystem exported to the wide-world, of someone trying to hack into my MasPar via the DEC Ultrix which controlled it, etc. but I am really rather interested in other perspectives. I hope a few of you will want to contribute something to the collection, there is still space for the January 2018 edition if anyone is so inclined. Cheers, Arrigo

7 years, 6 months

6
10
0 0

Why did PDPs become so popular?

by Alec Muffett

I apologise if this is too far from the main topic, but I wanted to check an urban legend. There is a story - as I have heard it told - that PDPs established their place (and popularity) in the marketplace by pointedly *not* advertising themselves as "computers", but instead as "programmed data processors". This was because - so the story goes - that everyone in corporations of the time simply *knew* that "computers" came only from IBM, lived in big datacentres, had million-dollar price-tags, and required extensive project management to purchase; whereas nobody cared enough about a thing called a "programmed data processor" to bother bikeshedding the few-tens-or-hundreds-of-thousands-of-dollars purchase proposal to an inevitable death. Thus, they flitted under the purchasing radar, and sold like hotcakes. I wonder: does this story have substance, please? Aside from anything else: I draw parallels to the adoption of Linux by Wall St, and the subsequent adoption of virtualisation / AWS by business - now reflected in companies explaining to ISO27001 auditors that "well, we don't actually possess any physical servers..." - alec -- http://dropsafe.crypticide.com/aboutalecm

7 years, 6 months

4
5
0 0

Why did PDPs become so popular?

by Dave Ritchie

I think that steep educational discounts and equipment grants from Digital to major collages also had a major impact,as did the existence of DECUS that made a lot of software readily available. Best regards, David Ritchie

7 years, 6 months

5
6
0 0

Happy birthday, Charles Babbage!

by Dave Horsfall

Charles Babbage KH FRS was born on this day in 1791; pretty much the father of the computer, a model of his "difference engine" built to the standards of the day worked, complete with its printer. What is not so well known about him was that he dabbled in cryptography, and broke the Vigenère cipher; unfortunately for him it was classified as a military secret, so one Friedrich Kasiski got the credit instead. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 6 months

3
4
0 0

Scanned: Xenix Abstract (1982)

by Toby Thain

Hi, Found this in a box of papers... Scanned it in yesterday. Posting in case it's of list interest: https://docs.telegraphics.com.au/Microsoft_The%20Xenix%20Operating%20System… An OCR'd PDF version will eventually appear here: http://chiclassiccomp.org/docs/index.php?dir=%2Fcomputing/Microsoft (but it's not there yet). --Toby

7 years, 6 months

1
0
0 0

Old tar bug in SVR4.2 was: SYSTEM V R1 HELP

by Arthur Krewat

Somewhat tangentially related to the other thread... So, back in the days when I was using Consensys SVR4.2, I found a bug in tar. It goes like this: If there is a symbolic link in the tree that you are taring, the first one works fine. If a second symbolic link has a shorter destination name than the first, the extra characters from the first symbolic link destination are appended to the end of the second. So for example: a -> abcdef b -> zyx Tar will actually tar these symbolic links as: a -> abcdef b -> zyxdef Being that I happen to have found, on the Internet, the sources to AT&T SVR4.2, and some other System V variants, I went and investigated. The relevant piece from AT&T SVR4.2 tar.c (broken): Jan 25 1993 ./ATT/ATT-SYSVr4/cmd/tar/tar.c case S_IFLNK: <SNIP> i = readlink(shortname, filetmp, NAMSIZ - 1); if (i < 0) { vperror(0, "can't read symbolic link %s", longname); return; } From USL-4.2 (apparently fixed): Jan 22 1994 ./USL/usl-4.2-source/src/i386/cmd/tar/tar.c case S_IFLNK: <SNIP> i = readlink(shortname, filetmp, NAMSIZ - 1); if (i < 0) { vperror(0, ":462:Cannot read symbolic link %s", longname); return; } else filetmp[i] = '\0'; /* since readlink does not supply a '\0' */ From Solaris 2.5: case S_IFLNK: <SNIP> i = readlink(shortname, filetmp, NAMSIZ - 1); if (i < 0) { vperror(0, gettext( "can't read symbolic link %s"), longname); if (aclp != NULL) free(aclp); return; } else { filetmp[i] = 0; } BSD 4.4: case S_IFLNK: <SNIP> i = readlink(shortname, dblock.dbuf.linkname, NAMSIZ - 1); if (i < 0) { fprintf(stderr, "tar: can't read symbolic link %s: %s\n", longname, strerror(errno)); return; } dblock.dbuf.linkname[i] = '\0'; Anyone know when/why/how tar diverged between the two branches? Note the readlink directly into dblock.dbuf, while the SVR4 variants use a temp string and then sprintf it in later. From: http://www.catb.org/esr/faqs/usl-bugs.txt 17. tar(1) fails to restore adjacent symbolic links properly Arthur Krewatt <...!rutgers!mcdhup!kilowatt!krewat> reports: SVR4 tar has another strange bug. Seems if when restoring files, you restore one file that is a link, say "a ->/a/b/c/d/e" and there is another link just after it called "b ->/a/b/c" tar will restore it as "b ->/a/b/c/d/e" This just seems to be a lack of the NULL at the end of the string, like someone did a memmov or memcpy(dest,src,strlen(src)); where it should be strlen(src)+1 to include the NULL. Esix cannot reproduce this under 4.0.4 or 4.0.4.1, they think it's fixed.

7 years, 6 months

1
0
0 0

SYSTEM V R1 HELP

by William Corcoran

Hello Team TUHS: I am having a problem with my PDP-11 SVR1 running under a recent SIMH build. My problem occurs on both MAC OS X and FreeBSD. First, I created a six disk (RP06) and eight port TTY (DZ) kernel, with swap placed on drive 1. The system behaves beautifully as FSCK reports clean. Eight users can login with no problem. Second, I reverted to a pristine PDP-11 SVR1 with one drive (RP06) and no DZ and booted the default kernel (gdtm) and I see the same problem described below. Third, when using the tape driver instead of /dev/null i get the same results. Next, here is the issue: cd / find . -print | cpio -ocvB > /dev/null It runs for a short while and then shitz a core: I am using /dev/null to take the tape driver out of the equation. Here is the backtrace for cpio: $c __strout(053522,043,0,053012) __doprnt(046652,0177606,053012) _fprintf(053012,046652,053522) ~main(02,0177636) Now, interestingly, I run into a similar issue when using tar: cd /usr tar -cvf /dev/null . Again, this will run for a while, then drops a core. Here is the backtrace for tar: $c __strout(043123,02,0,045506) __doprnt(043123,0167472,045506) _fprintf(045506,043123,0170600) ~putfile(0170600,0170641) ~putfile(0171654,0171704) ~putfile(0172730,0172745) ~putfile(0174004,0174016) ~putfile(0175060,0175066) ~putfile(0176134,0176136) ~putfile(0177672,0177672) ~dorep(0177632) ~main(04,0177630) This really bugging me since my SVR1 is otherwise working flawlessly. I was able to remake the entire system and custom kernels that boot with no problem. Also, I configured my main port to run inside the AWS Lightsail and now I have access to SVR1 from anywhere in the world! I was also wondering if doing a CPIO or TAR on the entire system was overflowing some link tables and maybe this is expected behavior for the minimal resource of the PDP-11? Thank you for any help. Would you expect tar or cpio to dump core if you attempted to copy large filesystems (or the entire system) on a PDP-11? Note: All of my testing has been in single user mode. Truly, Bill Corcoran

7 years, 6 months

6
14
0 0

Re: [TUHS] OT: Happy birthday, Tommy Flowers!

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall > Colossus, arguably the world's first electronic computer Well, it all depends on your definition of "computer"... :-) I myself prefer to reserve that term for things that are programmable, and Turing-complete. (YMMV... :-) So I call things like Colossus and ABC "digital electronic calculating devices" (or something similar). None of which is to take anything away from the incredible job done by Flowers and his cohorts. It was an amazing device, and had a major effect on history. Noel

7 years, 6 months

1
0
0 0

OT: Happy birthday, Tommy Flowers!

by Dave Horsfall

Tommy Flowers MBE was born on this day in 1905; an electrical and mechanical engineer, he designed Colossus, arguably the world's first electronic computer, which was used to break the German "Lorenz" high-level cipher (not Enigma, as some think). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 6 months

2
1
0 0

Various Unix

by Jose R. Valverde

Before we had to phase out our FTP server, I kept on it several versions of UNIX clones and related OS that were mostly not on TUHS. This post is to remember some of these systems. Many of these were open sourced or widely available at some time and were related to UNIX one way or another. I may not have the latest versions or all the versions, but at least I do keep something. The following ones have been open sourced at some point in time (I believe): ChorusOS Coherent EXOS L4 Lunix MaRTE-OS Mach OpenBLT OpenSolaris Sprite (I also own the original distribution CD) Trix UniFlex agnix amoeba bkunix bsd386 hurd iunix jaluna-c5 lsx-unix mini-unix minix omu opensolaris starunix thix from tliquest.net/local/unix: uzi and various other bits tme tropix tunix unix-v8 unix-wega uzi xhomer xinu xv6 yoctix Plus several archaic CDs with early versions of Linux, Open/Free/NetBSD, (Walnut Creek, InfoMagic, etc. CD/ROMs) and even the Beowulf/Extreme Linux CDs (plus I must keep around the mirror we hosted for a long time of the Beowulf site). The hobbyist CDs for OpenSolaris 8 (and I believe 9) with sources. Oh, and MOSIX/OPENMOSIX. In addition, I have many other sources whose Copyright status I'm not aware of, but which are interesting for archival purposes. Regarding QNX, yes, it was open sourced (at least for hobbyist use, I have to check the license) for several distributions. I ported some bioinformatics software and kept for some time a distribution repository, and I'm pretty certain I must have the sources as well as the virtual machines. I'll try to verify the licenses to see if it can be redistributed, although I doubt they can. Oh, and I also own the mentioned famous 3.5" diskette. I think I digitized it long ago. Would have to check. Off the Net, it has been possible, one time or another, to recover executables and, sometime, even sources, of many systems. Archive.org has -I believe- a copy of a once famous repo of abandonware with binaries of SCO, System V, AIX, etc... I know that AIX, ATT systemV vI, II, III and IV, Solaris V6, Tru64, OSF-1, Dynix, Ultrix 11, BSDI, Ultrix-32 etc... have been out there at some time or another in source code format, and binaries of IRIX, Lisa, QNX, A/UX, xenix... Some years ago, I had more free time and could test many systems on emulators, and built images and accompanying scripts ready ti run. I also made some tools to be able to transfer data in and out of old unix versions (so I could edit the software off the virtual machine while back-porting a screen editor to V6, v5, etc... with only vt100 support). Not UNIX-related, I also keep copies of many other ancient operating systems and software and hardware emulators. Well, as I said at the beginning, everything that I had, I should still keep while the hard disks continue spinning. If there is any interest in adding any of these to TUHS, I can try to find a way to send it all. If I find time to browse through everything, I would like to upload all the source code to GitHub (at least anything that's redistributable). If I find the time... But, Warren, if you are interested in anything, let me know and I'll find a way to give you access. j -- Scientific Computing Service Solving all your computer needs for Scientific Research. http://bioportal.cnb.csic.es

7 years, 6 months

2
1
0 0

pre-UNIX legacy in UNIX?

by Nigel Williams

I blundered today into the GECOS field in /etc/passwd: https://en.wikipedia.org/wiki/Gecos_field "Some early Unix systems at Bell Labs used GECOS machines for print spooling and various other services,[3] so this field was added to carry information on a user's GECOS identity." I had forgotten about this field and I don't recall it being previously described as related to GECOS (I likely didn't take note at the time I first encountered it). Aside from the influence of Multics and other things on UNIX design are there other tangible[1] manifestations of non-UNIX operating system things like the GECOS field that were carried forward intact in later UNIX implementations? [1] things can be pointed at, rather than design ideas

7 years, 6 months

8
8
0 0

Re: [TUHS] pre-UNIX legacy in UNIX?

by jnc＠mercury.lcs.mit.edu

> From: Doug McIlroy > In fact, I don't recall being aware of the existence of the ITS > movement at the time Unix arose. For background, here are a few selected timeline items: ?/1967 ITS design starts 7/67 ITS first becomes operational 12/67 Multics single process boot on 645 10/68 Initial Multics milestone (8 users) 01/69 Limited Initial Multics milestone (12 users) 04/69 Bell Labs drops out of Multics (I included the latter since I'm assuming the "time Unix arose" is after the Bell Labs departure.) Note: I'm not saying or implying anything about the 3 systems with this; this is purely data. Noel

7 years, 6 months

1
0
0 0

Re: [TUHS] pre-UNIX legacy in UNIX?

by Doug McIlroy

> > are there other tangible[1] manifestations of non-UNIX operating > > system things like the GECOS field that were carried forward intact in > > later UNIX implementations? > > Job control was inspired by ITS job control capabilities. Control-Z > does pretty much the same thing in both operating systems. I don't think "carried forward" describes job control, which I believe was never in any Research system. "Borrowed" would be more accurate. In fact, I don't recall being aware of the existence of the ITS movement at the time Unix arose. Doug

7 years, 6 months

2
2
0 0

Re: [TUHS] pre-UNIX legacy in UNIX?

by Richard Tobin

> > In fact, I don't recall being aware of the existence of the ITS > > movement at the time Unix arose. > Was there ever a movement? It was just four machines at MIT. When AT&T sued BSD Inc over (among other things) the phone number 1-800-ITS-UNIX, the joke was that MIT should have sued them too. -- Richard -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

7 years, 6 months

1
0
0 0

Re: [TUHS] OT: trains [Was: Date madness]

by Norman Wilson

Ian Zimmerman: > How do other train systems handle [DST], e.g. the European intercity > system? Dave Horsfall: UTC? It's not hard to get used to it. ===== You misunderstand the problem. Suppose I'm planning to board a train at 0300 on the morning Daylight Time ends. Now suppose the train actually departs an hour early, at 0200, because it originated before the time change and some nerd who never rides trains declared that it shall not wait the extra hour until scheduled departure time. Nerds may be happy, but the paying passengers won't be. Telling passengers to set their watches to UTC just won't happen. (Some of us nerds actually had our watches on GMT for a few months back in the years that gave the `Nixon table' in old ctime.c its (informal) name, but gave up because it was just too damn much work to stay in sync with the real world.) Once upon a time, before railways had radio communications and proper track-occupancy signalling, the consequences were more serious than that: if you run an hour ahead of schedule, you risk colliding with another train somewhere. That is why it was the railways that first accepted and promoted standard time zones. Nowadays it's not about scheduling and safety, just about having an acceptable user interface. In a similar vein, I know of at least one case in which Amtrak changed the official departure time of a train (that requires advance reservations and often runs full) from 0000 to 2359, because people would get confused about which day midnight falls on and show up a day late. (Actually the Amtrak timetable read 1200 midnight and 11:59 PM, but 24-hour time is one of the changes I agree people should just accept and use.) Norman Wilson Toronto ON

7 years, 6 months

3
2
0 0

Early Clones / Rewrites for TUHS archives

by Clem Cole

My question about SOL got me thinking a bit. It would be nice to have section in TUHS of any early clones that could be collected. The two that I can think of that probably should be there are (other feel free to point ones that we should try to find): 1.) Idris, which was fairly true to V6 (enough that the one time I test it, things from pretty much just worked). It was notable from being first. Although the C compiler and the 'anat' (the assembler) were a tad different. It the system that got Bill Plauger in trouble @ USENIX @ UDEL when he was booed for a 'marketing' talk. 2.) CRDS (pronounced Cruds by those of use that use it at the time) - Charles River Data Systems. It was a UNIX-like system, although I do not think really attempted to hold to a V7 API much more than intent. Although if my memory serves me, one of the unique features was the use of Reed & Kanodia synchronization in its kernel [REED79], which I was a always a fan. The system was slow as sin bit it ran on a 68000. [CRUDS system, a Fortune box and our Vax/750 running BSD4.1 were the systems Masscomp used to bootstrap]. Clem [REED79] D.P. Reed and R.K. Kanodia, "Synchronization with Eventcounts and Sequencers"

7 years, 6 months

17
21
0 0

Re: [TUHS] Date madness

by Norman Wilson

Arnold: ISTR that the vaxen did have such things. Or rather, I ran some BSD 780s for several years and I don't remember having to set the date / time every time I did a reboot. They sat in a data center, so I may have never done a cold boot from power on. It was a LONG time ago now, so there's undoubtedly lots that I just plain don't remember. ==== I believe all the VAXes had time-of-year clocks, though the implementation and the method of access varied from model to model. On `Big' VAXes, the clock was considered part of the console front-end, and accessed through the model-specific console scheme. MicroVAXes had no console front-end; I believe the clock was accessed through registers, but it was an off-the-shelf digital-watch chip with some funny format (separate registers for year, month, day, hour, minute, second). So they all had proper battery-backed-up clocks, but of many different types. It wasn't as simple as reading a single counter out of a register, sensible as that might seem. If anyone's really interested I can dig up details for the several models of Big and MicroVAX I dealt with; I still have all the code lying around. Norman Wilson Toronto ON

7 years, 6 months

7
7
0 0

OT: Konrad Zuse

by Dave Horsfall

We lost Konrad Zuse on this day in 1995; he invented the world's first programmable computer -- the Z3 -- which was unfortunately lost in the Berlin bombing during 1943. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 6 months

2
1
0 0

Date madness

by jnc＠mercury.lcs.mit.edu

Heh, my V6 machine thinks (via 'date') that today is _Monday_, December 12th. Oddly enough, 'cal 17 2017' on it produces the right thing. Guess the date code is probably missing the '400 year' exception. Noel

7 years, 6 months

10
14
0 0

shell PS1/PS2 which survive cut-paste

by George Michaelson

I tried a long time ago to set PS1 and PS2 to character sequences which would permit cut-paste to work. I failed, but I didn't try very hard. The choice of "# " and "> " interests me. Because roots prompt of "hash" has a side effect of making a cut-paste over it a comment in most shells. But.. it predates being *able* to cut-paste so it has to be a side-effect, not a design choice. "> " is more dangerous in cut-paste. Which again feels like a side-effect both by anachronistic time effects, and intent: nobody would be that suicidally mad to make cut-paste invoke shell pre-forming the command sequence which neccessarily zeros out the > targets before executing the cmd... -G

7 years, 6 months

11
17
0 0

Re: [TUHS] Date madness

by jnc＠mercury.lcs.mit.edu

> From: Arnold > One would think that SIMH I'm using Ersatz-11... > into the simulated computer's time of day clock. What Time of Day clock? We're talking PDP-11's here! :-) The very last DEC models of the -11 (/93-94) had a ToY clock; I'm pretty sure none of their others did. And of course V6 long pre-dated the /93-94. Noel

7 years, 6 months

8
10
0 0

Re: [TUHS] Date madness

by Doug McIlroy

>>> Flipping it to unsigned int was the quickest way out to kick the can until Sun Feb 6 06:28:15 2106. If you have source it’s incredibly trivial to change, and nothing changes size wise. >> >> Easy, but perhaps unwise. The sign bit is a potential escape hatch for >> times, just as it is for characters in UTF-8. > > I'm not sure what you're suggesting - UTF-8 works because it's a variable length encoding - a variable length timestamp might be interesting as an academic exercise, but there's no way for time() to specify how much space is needed, or be informed of how much space is allocated Like UTF-8, a variable-length time would be something normal programs aren't supposed to see--it would be a format for external media (i.e. file systems). Times in inodes would be variable-length. Times returned by stat() and time() would be full length. Only the kernel needs to know the encoding. One may note that inodes already use a variable-length encoding for the list of physical block addresses, so there is nothing radical here. I admit, though, that if the kernel can tell "old" from "new" inodes, then they could have different time encodings rather than one variable-length encoding. Doug

7 years, 6 months

3
2
0 0

Re: [TUHS] Early Clones / Rewrites for TUHS archives

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > It would be nice to have section in TUHS of any early clones that could > be collected. The Unix Tree does have a section for "Unix Clones", and it has Coherent, Xinu, Minix and some early Linuxes. Another one that's missing (although in a different category) is Ultrix-32.> Noel

7 years, 6 months

6
6
0 0

Partition table rationales?

by Random832

Is there any information on the rationales behind the sizes and positions of the hardcoded partitions in the rp/hp drivers in V6? There are odd gaps of unused space between ones that appear to be intended to be used together (I think I have some pieces of the puzzle worked out below, but not all). For the rp driver, only rp[01] uses the whole disk - rp2 and rp3 are 9200 blocks. The hp partitions looked more complicated, but it looks like the manpage is wrong about where partition 2 starts - 84018 vs 48018. Partitions 0123 are 161584 blocks, 4567 are 162400 blocks. 4567 start on 100-cylinder boundaries, but are only a bit over 97 cylinders long - in fact, they are the same length as rp[01]: 203 RP03 cylinders. rp6 and rp7 are not mentioned in the manpage, and are 15600 blocks, making rp[65] and 47 reasonably non-wasteful configurations. Is there something special about 9200 blocks? rp2 and rp3 are that size, and hp1 is that size rounded to the next cylinder. V7 is much simpler: rp0 is the whole disk, 123 is a non-overlapping set with no wasted space. hp[0145], 016, and 017 are non-overlapping sets.

7 years, 6 months

1
0
0 0

Re: [TUHS] Date madness

by Doug McIlroy

> Flipping it to unsigned int was the quickest way out to kick the can until Sun Feb 6 06:28:15 2106. If you have source it’s incredibly trivial to change, and nothing changes size wise. Easy, but perhaps unwise. The sign bit is a potential escape hatch for times, just as it is for characters in UTF-8. Doug

7 years, 6 months

2
2
0 0

Difference in purpose of /var/spool vs /var/lib

by Grant Taylor

Can anyone enlighten me on the effective difference in the use of /var/spool vs /var/lib? It's my understanding that spools are for files that are in transit. Effectively like packages moving through a shipping depo or people waiting in line. I.e. they come in, they hang around for a while, and then they leave. I'm of the opinion that files in /var/lib should stick around longer and are not nearly as dynamic (if at all, save for code updates). As sure as I type this, I can't think of a reason library files would go under /var vs a different */lib directory. Does it make any difference if the files are actually executed and / or consumed on the system? I don't consider the POP3 / IMAP / NNTP server to be processing files when people access messages / articles (read: files) via the respective protocols. Back story: I'm considering writing something that will download a file every day and process the last day's / week's / month's file(s) to generate output which is itself stored elsewhere. - I feel like these files should live in the /var/spool/<bla> subdirectory. -- Grant. . . . unix || die

7 years, 6 months

2
1
0 0

Re: [TUHS] Date madness

by jnc＠mercury.lcs.mit.edu

> From: Tom Ivar Helbekkmo > My /83s have them, but I'm not so sure it's a feature of the CPU board: > there's this thought nagging in the back of my head that the ToY thing > actually sits in the front panel module with the various buttons on it. /83 documentation seems to be very thin on the ground, alas. It's definitely not the CPU; the KDJ11-B CPU (of the /83) manual (EK-KDJ1B-UG-001) makes no mention of it; and in the PDP-11/94E System User and Maintenance Guide (EK-KDJ1E-UG-001), section D.2 "PDP-11/94 and 11/84 Hardware Differences" (the /?3 and /?4 models use the same CPU board, but a different backplane, with QBUS/UNIBUS converter, so this could equally well be titled "PDP-11/93 and 11/83 Hardware Differences") says "Time of Year Clock", indicating the 83/84 don't have one. Several companies made after-market ToD clocks to plug into the QBUS, e.g. here: https://www.ebay.com/itm/371284594072 Is something like that what your /83 has? Noel

7 years, 6 months

1
0
0 0

Other history lists...

by Grant Taylor

Does anyone know of any other similar history discussion mailing lists / newsgroups to discuss things like Mainframes or (Open)VMS? I have some questions as I try to broaden my horizons, but I don't think they fit in the TUHS context. -- Grant. . . . unix || die

7 years, 6 months

5
5
0 0

V7 Addendem

by Warner Losh

>From the tuhs web site: "This is a set of addenda to Seventh Edition Unix, possibly put out by the Labs." and "The identity of the person who donated them is unknown." Two questions: Was this put out by the Labs? Second: There was recently a discussion about a tape found at some public location during an early Unix user group meeting. Is this that tape? Warner

7 years, 6 months

16
27
0 0

Re: [TUHS] Date madness

by jnc＠mercury.lcs.mit.edu

> From: Arnold > So how did you manage to lose a whole year? Time travel? :-) No, I just haven't booted the V6 often in the last year, and when I did, I never bothered to reset the time; so it was still on Nov, 2016. Noel

7 years, 6 months

2
1
0 0

Re: [TUHS] Date madness

by jnc＠mercury.lcs.mit.edu

> So, I looked at the code, and the bug is not obvious. Because there _was_ no bug!!! :-) It was saying December 12 was a Monday because the _year_ was still set to _2016_, and in 2016, December 12 _was_ a Monday! {Smacks forehead!} Noel

7 years, 6 months

2
1
0 0

Re: [TUHS] Date madness

by jnc＠mercury.lcs.mit.edu

> Guess the date code is probably missing the '400 year' exception. So, I looked at the code, and the bug is not obvious. (The routine for detecting leap years in V6's ctime.c is so minimalistic it actually works for 2000!) The version I'm currently running had been worked on some, to have a hack fix for the overflow of the number of 8-hour periods since the epoch ("hack" since the 'fixed' version will break in 2029 or so), and I was worried that 'fix' was wrong and caused the week-day problem, but I don't think so. Noel

7 years, 6 months

1
0
0 0

The French SOL Project

by Clem Cole

In the early 1980s, a bunch of French researchers set out to build a clone of UNIX/V7 in Pascal (using a ukernel IIRC). The project was the SOL project [Gien, 1983]. I believe it eventually begat the Chorus system (which was C++); which UI was going to use for System V/R5 before it all blew up. 1) Does anyone know what happen to SOL? Was it finished, deployed, used for anything? 2.) Did the sources and doc survive (and who owns the IP)? I think those should be in the TUHS archives, as I think this was the first attempt at a rewrite of UNIX in something other than C (or assembler). 3.) On a similar thought, did the Chorus code survive and who owns the IP? Clem [Gien, 1983]*“The SOL Operating System*”, Michel Gien, USENIX Association, 1983, Proceedings of the Summer ’83 USENIX Conference, Toronto, On, Canada, July, 1983, Pages 75-78

7 years, 6 months

4
3
0 0

Re: [TUHS] Early Clones

by Rudi Blom

actually not an early clone but a late(r), Philips MPX (Multi-processor UNIX) based on SystemV running on Moterola CPUs. Mostly sold in the (Retail) Banking Industry as branch server. The "M" was more related to having various boards running their own UNIX. That would be an Ethernet board and one Networking board for SDLC and X.25. These boards run their own copy of unix to 'offload' the main CPU. I've worked with this UNIX but more a system tester, interface to National Sales Organisations. No idea where the source is, but guess it would be IP of Philips (or DEC, or Compaq, or HP, or HPE) if anyone still remembers that is. For a (very) short while there was also an Intel CPU based version, but dropped in favour of SCO UNIX when DEC bought Philips Computer division. A very little bit in this 1987 article. https://www.cbronline.com/news/better_late_philips_enters_the_uk_unix_marke… Cheers, uncle rubl

7 years, 6 months

1
0
0 0

Re: [TUHS] Date madness

by jnc＠mercury.lcs.mit.edu

> From: Warner Losh > So at some point you had to hack things in to make 20xx work, no? I had a number of date issues with V6; more here: http://mercury.lcs.mit.edu/~jnc/tech/V6Unix.html#Issues That one was the easiest to fix! (Although this one will probably also be pretty easy, too.) Noel

7 years, 6 months

1
0
0 0

Re: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > IP and datagrams were very much built on no central control Well, yes and no. One can easily have a centrally controlled datagram network (q.v. the ARPANET) - although it's true that its path-selection algorithms, etc were not centrally controlled - but other aspects of the network were. (Interestingly, after various routing disasters the Internet caused by improper configuration, some aspects of path selection in _parts_ of it are now effectively centrally controlled; but I digress.) The IP Internet was designed with no _overall_ central control, but as a collection of autonomous entities. > In the end, it was MetCalfe's law (which was formulated on observations > about the phone system) that caused IP to win Over any and all comers, including other decentralized datagram networks like CLNP. MetCalfe's law doesn't talk about decentralized, it's just about 'first to field'. > all want to see the net neutrality go away This whole 'net neutrality' campaign drives me completely crazy. If all people wanted was a rule saying 'ISPs can't give third parties _worse_ service, or - more importantly - deny service altogether, unless those parties pay up' (i.e. what would amount to targeted extortion), I'd be _all for_ a rule like that. But the 'net neutrality' aficionados (most of whom, I'm fairly sure, are not aware of/thinking about these details) are all signing up for a much more expansive rule, one that says 'no ISP can offer anyone _better_ service for paying more money' - which is quite different. My problems with this latter form are two-fold. First, what's wrong with that anyway? Do we have a rule saying you can't get better road service if you pay? Absolutely not - restricted toll lanes are becoming more and more common. So there's clearly no societal agreement on this principle. (I suspect this 'net netrality' campaign has as a goal some sort of 'forced equality' thing - unless the people behind it simply don't even understand the difference.) Second, that rule is, with a little extra work on the ISPs' part, ineffective anyway. All they have to do is build _two_ networks, one better provisioned than the other - and priced accordingly. You want better service? Sign up for the second network; you'll pay more, but it's your choice. Noel

7 years, 6 months

5
4
0 0

Re: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]

by jnc＠mercury.lcs.mit.edu

> From: George Michaelson > I didn't mean to disrespect the people who did the models or the > protocol or standards work btw. Oh, I personally have no problem with you saying hard things about this work, as long as it's what you really think. One never finds the truth unless one is willing to look hard, neh? And I'm pretty sure Dave Clark (who was a leading light in IntServ) would be OK with you doing so too (I worked very closely with him for years, to the point where I deputized for him at meetings). I honestly don't remember exactly what my take was on IntServ and RSVP; I'd have to go look. I recollect seeing the case that _if resources were limited_, certain classes of application (I guess we called them 'inelastic') would need reservations to work properly. So I was probably susceptible to the argument that 'if we've got bandwidth to light our <insert flammable objects> with, we don't need resource reservation'. And I remember being not _thrilled_ with RSVP, but I don't recall exactly why. But, as, you said, wrong list. Maybe internet-history: http://mailman.postel.org/mailman/listinfo/internet-history if you did want to delve into it. Noel

7 years, 6 months

1
0
0 0

Re: [TUHS] MERT?

by jnc＠mercury.lcs.mit.edu

> From: Jon Steinhart > Probably the best person to ask is Heinz Lycklama. I checked my email log for my previous MERT enquiries, and that's the exact same advice I got from Brian Kernighan when I asked him (a couple of years back) if he had any suggestions for tracking it down. I guess I need to finally get a 'round tuit'... unless there's someone else here who knows him well, and wants to give it a go. Noel

7 years, 6 months

1
0
0 0

Re: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]

by jnc＠mercury.lcs.mit.edu

> From: George Michaelson > I don't think this list is the right place to conduct that particular > debate. Not disagreeing; my message was a very short gloss on a very complicated situation, and I wasn't trying to push any particular position, just pointing out that work (whether the right direction, or not, I didn't opine) had been done. > Its true RSVP didn't get traction, but the economics which underpin it > are pretty bad, for the current Internet model of settlement Yes, but would _any_ resource reservation system, even one that _was_ 'perfect', have caught on? Because: > it would not surprise me if there is ... more dropped packets than > strictly speaking the glass expects. This is related to something I didn't mention; if there is a lot more bandwidth (in the loose sense, not the exact original meaning) than demand, then resource reservation mechanisms buy you nothing, and are a lot of complexity. While there were bandwidth shortages in the 90s, later on they pretty much went away. So I think the perception (truth?) that there was a lot of headroom (and thus no need for resource reservation, to do applications like voice) played a really big role in the lack of interest (or so people argued at the time, in saying IntServ wasn't needed). Noel

7 years, 6 months

2
1
0 0

Re: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]

by jnc＠mercury.lcs.mit.edu

> From: Steve Johnson > Recently I've been attempting to Skype on a group call with 5 people in > Europe. I would LOVE to have a guaranteed bandwidth for my call. The Internet engineering community did quite a bit of work on resource guarantees. (Google 'IntServ' and 'RSVP' - the latter is the control protocol.) Unfortunately, there was never much interest in it. People started doing voice with just plain 'best effort' service, and I guess it worked 'well enough' that nobody was interested in IntServ/RSVP. Noel

7 years, 6 months

2
1
0 0

Re: [TUHS] net neutrality

by jnc＠mercury.lcs.mit.edu

> From: Larry McVoy <lm(a)mcvoy.com> > Did you read the reddit link I sent? No, because I despise Reddit. > Because if you had you wouldn't be asking this. Now that I look at it, most of what I lists is ISP's _blocking_ sites. I _already_ said I wanted to see a rule preventing that. > unregulated businesses will do whatever they can to make more money with > absolutely no concern about the consequences Sure - like content providers. Noel

7 years, 6 months

2
1
0 0

Re: [TUHS] net neutrality

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > Just like the electric company, needs to deliver electrons at some > rate/force. If you want electrons at more than X bazillion per second, you'll have to pay to have a higher-amperage service. And if you use more electrons, you pay more. What's your problem with ISPs doing the same? Noel

7 years, 6 months

3
2
0 0

Re: [TUHS] net neutrality

by jnc＠mercury.lcs.mit.edu

> From: Larry McVoy <lm(a)mcvoy.com> > look at the history, various ISPs like Verizon, Comcast, etc, have done > stuff like block bittorrent, skype, etc Bittorrent is a complex situation, some ISPs were ordered by a court to block it. As to Skype, I agree ISPs shouldn't block sites - but if you read my message, I already said that. > The problem is I paid for the bits. Bits is bits. I paid for a rate, > that's what they got paid for, why should they get to charge a second > time for the same bits? That's exactly what they want to do. Fine, you pay your money, you get X Mbits/second. If you (or the site you're getting bits from) wants _more_ than X Mbits/second, charging you - or them, which is I gather mostly what ISPs want to do - for that privilege is a problem... how? Noel

7 years, 6 months

2
1
0 0

Re: [TUHS] Happy birthday, Grace Hopper and J.F.Ossana!

by Rudi Blom

Anyone on TUHS who made the list? Greeting from your Dutch uncle rubl For all the sound advise you don't want to hear. Date: Sun, 10 Dec 2017 13:23:13 +1100 (EST) From: Dave Horsfall <dave(a)horsfall.org> To: The Eunuchs Hysterical Society <tuhs(a)tuhs.org> Subject: Re: [TUHS] Happy birthday, Grace Hopper and J.F.Ossana! Message-ID: <alpine.BSF.2.21.1712101314210.35694(a)aneurin.horsfall.org> Content-Type: text/plain; charset=US-ASCII; format=flowed On Sat, 9 Dec 2017, Ralph Corderoy wrote: >> Yeah, but all the same, two famous people in the same industry would >> surely lengthen the odds somewhat... > > Yeah, you're pulling my leg. :-) > https://en.wikipedia.org/wiki/List_of_computer_scientists OK, it was worth a try :-) (I'm a born stirrer, and I blame my parents for that.) -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 6 months

2
1
0 0

Grace Hopper

by Dave Horsfall

(At the risk of being flamed because it's not strictly Unix...) We gained Rear Admiral Grace Hopper on this day in 1906; known as "Amazing Grace", she was a remarkable woman, both in computers and the Navy. She coined the term "debugging" when she extracted a moth from a set of relay contacts from a computer (the Harvard Mk I) and wrote "computer debugged" in the log, taping the deceased Lepidoptera in there as well. She was convinced that computers could be programmed in an English-like language and developed Flow-Matic, which in turn became, err, COBOL... She was posthumously awarded the Presidential Medal of Freedom in 2016 by Barack Obama. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 7 months

9
11
0 0

Happy birthday, Grace Hopper and J.F.Ossana!

by Dave Horsfall

As promised :-) Augusta Ada King-Noel, Countess of Lovelace (and daughter of Lord Byron), was born on this day in 1815; arguably the world's first computer programmer and a highly independent woman, she saw the potential in Charles Babbage's new-fangled invention. J.F.Ossanna was given unto us on this day in 1928; a prolific programmer, he not only had a hand in developing Unix but also gave us the ROFF series. Who'ld've thought that two computer greats would share the same birthday? -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 7 months

2
4
0 0

Card reader on Unix

by Dave Horsfall

Something's been bothering me for a while... I've just remembered that our 11/40 with more peripherals than you could shake a stick at -- it had just about everything except a DECtape -- also had, so help me, a card reader! As I dimly recall, 'twas a slow CDC (?) model; we didn't have it for long, either because it was on loan or because it was so unreliable, I simply don't remember. Anyway, our driver handled it in two modes: you either got a raw image of each card (likely via DMA instead of column by column, but I could be wrong) i.e. 80 words with each column of 12 holes fitting nicely into a 16-bit word, or there was a half-arsed attempt at converting EBCDIC to ASCII, with trailing blanks replaced by a newline (i.e. think of it as a line printer in reverse). Or was it converting from whatever KRONOS used to ASCII? Now, what I *distinctly* remember was writing two scripts: "/etc/cdc" and "/etc/dec" which switched between the two modes, quite likely by patching the in-core kernel! I'd give a testicle to have that "CSU tape" back again (and no doubt so would Warren), but can anyone else remember this (or dare to call me a liar; yes, I'm still touchy about that)? The snag is, towards the end of the CSU before they were about to be engulfed by the admin suits and forced to support payroll programs in COBOL etc, I was the only senior Unix bod left, so it's unlikely that the CSU source code followed someone else home... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 7 months

1
0
0 0

AT&T 3B2/400 Emulator

by Seth Morabito

Hello everyone, A few weeks ago, I merged my work-in-progress AT&T 3B2/400 emulator into the main SIMH source tree, and I realized that I should mention it here, where there may be particular interest. The 3B2 and 3B5 were main porting platforms for AT&T System V Release 3, and when I realized how scarce the equipment has become to find, I set out to write an emulator for the 3B2. It was rough going at points due to lack of documentation, but I was able to reverse engineer quite a bit of the system through reading the SVR3 source code, and of course strapping my own 3B2/310 to a logic analyzer. The emulator is fairly complete. It certainly works well as a standalone, single-user UNIX system. Support for multiple terminals is coming very soon (as soon as I find the time, that is) so it will soon be possible to allow multiple users to telnet into virtual terminals, similar to how the SIMH PDP-11 and VAX emulators work. For now, information about the emulator lives here: https://loomcom.com/3b2/emulator/ Best Wishes, -Seth -- Seth Morabito web(a)loomcom.com

7 years, 7 months

6
6
0 0

V7 32V 3BSD dates

by Warner Losh

OK. I'm confused. Maybe people here can help me understand. Looking at the V7 sources, it looks for all the world like they were released Jan 10, 1979. This release was PDP-11 only. So far, so good. 32V, a port to the VAX, is listed as 'early 1979'. Dates in the files in the archive suggest March 26th, 1979 (though there are dates as late as May 3rd and April 30th on two files that are trivial). The tape we have in the archive has a date Feb 22, 1980 written on it. Given the dates, that's only 3 months after V7 was released. This seems very fast, but maybe it's OK since it's a swapping release.... 3BSD, The Berkeley 32V has file dates as late as Mar 22, 1980... This seems reasonable for turning V7 from swapping into paging... about a year is fast but not crazy fast. My question is: did these three events really happen in this quick succession? Did USDL folks get started with a preliminary V7 for V32 or was the port really done in 2 and a half months? Likewise with UCB and 3bsd: did they start early? Warner

7 years, 7 months

2
2
0 0

What UNIX Artifacts Are Still Missing?

by Paul Ruizendaal

> Venix/86 and Venix/86R might be interesting... I have impure versions of > both... +1 Venix/86 is the first Unix to run on PC hardware that I’m aware of. It could go together with Idris and Minix as examples of early PC Unix.

7 years, 7 months

14
22
0 0

Re: [TUHS] Grace Hopper

by Nelson H. F. Beebe

For more on Admiral Grace Murray Hopper, by one who knew her well, see Jean Sammet's remembrance: Farewell to Grace Hopper: end of an era! https://doi.org/10.1145/129852.214846 A Ph.D. thesis about her: The Contributions of Grace Murray Hopper to Computer Science and Computer Education https://digital.library.unt.edu/ark:/67531/metadc278692/m2/1/high_res_d/100… Books: Grace Hopper: Admiral of the Cyber Sea 1-59114-978-9 Grace Hopper and the Invention of the Information Age ISBN 0-262-51726-4 Grace Hopper: Computer Whiz ISBN 0-7660-2273-0 [juvenile literature] I've always found it amusing that she was a strong proponent of the work ethic: "Act first, get permission later", which is in direct opposition to the military chain of command, despite her rank as Rear Admiral of the US Navy. See also ACM Grace Murray Hopper Award https://awards.acm.org/hopper https://awards.acm.org/hopper/award-winners [Awarded to the outstanding young computer professional of the year, selected on the basis of a single recent major technical or service contribution. This award is accompanied by a prize of $35,000. The candidate must have been 35 years of age or less at the time the qualifying contribution was made. Financial support of the Grace Murray Hopper Award is provided by Microsoft.] Don Knuth of Stanford was the first GMHA winner, in 1971; other well-known people include Steve Wozniak (1971), Bob Metcalf (1980), Dan Bricklin (1981), Brian Reid (1982), Bill Joy (1986), John Ousterhout (1987), Guy Steele (1988), Richard Stallman (1990), Bjarne Stroustrup (1993), Vern Paxson (2007), Craig Gentry (2010), ... There is also a 1983 interview on a popular US news broadcast that celebrates its 50th anniversary this year: The 60 Minutes interview with Grace Murray Hopper https://www.cbsnews.com/news/the-60-minutes-interview-with-grace-murray-hop… ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

7 years, 7 months

4
3
0 0

Re: [TUHS] V7 Addendem

by jnc＠mercury.lcs.mit.edu

> I've never seen a detailed description of UNIX/TS, although I have seen > the "Unix Program Description" (January 1976) which documents the USG > version, and of course PWB is described in the BSTJ issue, and UNIX/TS > is supposedly a merge of those two. > ... > Did the later USG versions takeup some of the PWB work, does anyone > know? (My thinking is 'if I find traces of PWB [in the MIT system], > would that be from /TS, or could it be a later USG version' - I think > there were 1-3, from something I saw online.) So I seem to have stumbled on something interesting here (or maybe it's not, and the history is just unclear - well, unclear to me at least, I'm sure someone knows). Looking at "Unix Program Description" (January 1976), it's clearly marked as "Published by the UNIX Support Group". (I have an actual hardcopy, which I don't recall how I came by, but for those who wish to follow along this document is available in the TUHS archive, at: http://www.tuhs.org/Archive/Distributions/USDL/unix_program_description_jan… and in other TUHS mirrors). So, given the credit, I _assume_ that it documents some version of the USG system. So I started looking at that, and the PWB version that's in the archive: http://www.tuhs.org/Archive/Distributions/USDL/spencer_pwb.tar.gz to see how they compare, and it turns out (somewhat to my surprise) that the USG document describes what seems to be an older version of the system. For example, in text.c, it doesn't cover xlock()/xunlock()/xexpand(), all in the PWB system - just xalloc()/xccdec()/xfree()/xswap(). Even more telling, in sys1.c, the USG document describes the older version of exec(), where arguments are collected in a disk buffer, not (as in the PWB system) in swap space. (I had thought that this change was mentioned in the PWB paper in the BSTJ issue, but on checking, it appears my memory was incorrect. Many of the PWB changes appear to be to things like the shell, not the OS.) So it seems the USG document describes a system very close to the 'classic' V6 - not what I had expected. This may also make it hard to recognize USG source (at least, the early versions). More generally, it would be good to try and elucidate the relationship among all these early Bell/AT+T versions: Research, USG, PWB, etc. Clearly the two latter (from what we know now) are descended from V6 - but was there any interchange between USG and PWB? And did either of them feed back into V7? Or, perhaps more likely, were the improvements to text.c, exec() etc _Research_ improvements that got fed into PWB? More questions than answers, sadly... I'm not at all familiar with V7, I'll have to go read it at some point, and compare it to PWB. Not that I expect it will answer many (any?) of these questions, but maybe we'll get lucky and there will e.g. be stuff in this PWB which isn't in V7. Speaking of which, I seem to recall there's more than one PWB version. I wonder which one we have (above). Although there's another 'PWB' tape in the archive: http://www.tuhs.org/Archive/Distributions/USDL/bostic_pwb.tar.gz (much larger than the other one), when I poked around a bit through that, seeing what's there, and comparing it to the other one, the system sources I looked at there all seemed to be the same as the one on the Spencer tape. > I should look at the MIT kernel and see how much of it is USG, and see > if I can find any traces of the changes described as done for PWB. I > know the MIT version has provisions for longer exec() arguments, and > text.c is considerably more complex than the one in V6 (and IIRC matches > the description in the USG document) So, my memory was in error here; the text.c matches the one from the PWB tape, _not_ the USG document. In general, the parts of the MIT system seem to be a close match to what's on the PWB tape, with the exception that the MIT one seems to be slightly earlier (no 'register' argument types). > Perhaps the MIT system really was /TS Without a better understanding of what was really in /TS, this is totally opaque. > I've always described it as a hacked PWB1, but I might be wrong there. And for once, I think I was right. The MIT system _does_ closely match the one on the 'PWB' tapes - whatever that was! Noel

7 years, 7 months

1
0
0 0

A nice review of a retrospective paper on the PDP-11

by Arnold Robbins

https://dave.cheney.net/2017/12/04/what-have-we-learned-from-the-pdp-11 Arnold

7 years, 7 months

1
0
0 0

Re: [TUHS] how do I unsubscribe

by jnc＠mercury.lcs.mit.edu

So, I'm getting the impression, from the reactions about civility, etc, that people aren't disagreeing with the characterization of "rudeness" (which can only be meaning my posts). Can someone please point to text in my messages which they consider "rude"? Thanks. Noel

7 years, 7 months

3
2
0 0

ARPAnet now 4 nodes

by Dave Horsfall

The ARPAnet reached four nodes on this day in 1969 (anyone know which?); at least one "history" site reckoned the third node was connected in 1977 (and I'm still waiting for a reply to my correction). Well, I can believe that perhaps there were only three left by then... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 7 months

3
3
0 0

looking for a quote

by ron minnich

A long time ago, dmr wrote about something that IIRC BSD had done he did not like: unlimited length identifiers in C, maybe? His argument was that being too general was not a good thing. Can't quite find the quote, anyone remember it? Would have been ca. 1980. ron

7 years, 7 months

8
11
0 0

Re: [TUHS] V7 Addendem

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > it's direct predecessor (UNIX/TS) which was not officially released made > its way to number of places ... heavily hacked systems that were combo's > of V6, PWB [1.0], UNIX/TS plus local additions. UNIX/TS had a newer > kernel, updated FS and the compiler that was released with troff - > a.k.a. 'Typesetter C' I'm not sure quite what the MIT system was. I've never seen a detailed description of UNIX/TS, although I have seen the "Unix Program Description" (January 1976) which documents the USG version, and of course PWB is described in the BSTJ issue, and UNIX/TS is supposedly a merge of those two. (If we ever do find V6+ USG source, it should be easy to verify - that document is pretty detailed.) I should look at the MIT kernel and see how much of it is USG, and see if I can find any traces of the changes described as done for PWB. I know the MIT version has provisions for longer exec() arguments, and text.c is considerably more complex than the one in V6 (and IIRC matches the description in the USG document); but I don't recall withough careful checking, what was done where. Perhaps the MIT system really was /TS, and I didn't know that - I've always described it as a hacked PWB1, but I might be wrong there. Did the later USG versions takeup some of the PWB work, does anyone know? (My thinking is 'if I find traces of PWB, would that be from /TS, or could it be a later USG version' - I think there were 1-3, from something I saw online.) I initially got /TS mixed up with /RT, which is the system I'd _really_ like to find - well, MERT, actually. I think that's a really early micro-kernel system (although I haven't done any research to confirm that), a direction I think is important. (I think the 'THE Multiprogramming System' may be the earliest work in that direction, although I'd be interested to hear of anything else.) I actually got contact info for some of the original MERT people, and was going to contact them to see if they still retained anything, but I never got a 'round tuit'... too many other projects. :-( Noel

7 years, 7 months

2
1
0 0

how do I unsubscribe

by Deborah Scherrer

Could someone please tell me how to get off this list? I was rather appalled at the rudeness in the previous conversation... Deborah

7 years, 7 months

8
10
0 0

Re: [TUHS] What UNIX Artifacts Are Still Missing?

by jnc＠mercury.lcs.mit.edu

> From: Larry McVoy > an altruistic person trying to make things better. They aren't all bad. I would echo that. During my time on the IESG, I'd say the vast majority of the people in the IETF really did want to make things better for everyone. Of course, that statement covers a vast range of subtle variations, from people who had nothing at all to gain personally, and thus really were pushing what they thought was best; through people who did stand to gain, but truly thought that what they were advocating was in everyone's interest; etc. But the people who I felt were deliberately and knowingly putting their own interests before the community's, i.e. recommending something they knew to be harmful because it was good for them - they were very rare. My recollection is now somewhat dim (too much was happening, at too high a pace) of the details of those later days (well, 'later' only in that they were considerably later than the very early days :-), but my sense is that people like that didn't last long in the community; I have the distinct impression that people figured them out, and as an eventual result, they tended to fade from the scene. The IETF culture was not welcoming to that kind of thinking. I dunno, maybe I'm just being naive (and I would certainly welcome correction if I'm wrong), but that's how I saw it. Noel

7 years, 7 months

2
1
0 0

Misguided standsads (was What UNIX Artifacts Are Still Missing?)

by Doug McIlroy

> Standards committees are not filled with altruistic folks working to > make something great. Not only in big ways, such as to sway the market. An example from Posix is the undefined meaning of malloc(0). As I understand it, just one committee member held out for malloc(0) to be an optional error, thus confounding a harmless corner case with a fatal error. This nit has burdened conscientious programmers ever since, all so one company's easily fixable variant could be grandfathered into compliance. Doug

7 years, 7 months

1
0
0 0

Early Xenix source code (was: What UNIX Artifacts Are Still Missing?)

by Paul Ruizendaal

> They might actually. Gates isn’t in charge, and there has been a major effort to being Linux compatibility into the Windows 10 kernel. I agree that they might. Once there was strong commercial logic to disown their Unix history; that commercial logic may have reversed in the last decade. > The biggest issue will be the never ending tangle of licenses, if they had other stuff integrated into there. Let’s analyse that bit: - They could pick the Nokia solution, i.e. to simply make an undertaking not to sue and thus avoid taking a position on Unix ownership etc. - It would seem that Xenix 2 (no apparent version 1?) was more or less V7 and for internal use only (lacking a binary redistribution license, as Clem pointed out). Very little chance of 3rd party source code in there, but also of little interest for the historical record. - The first real ports occur with Xenix 2.x in 1981-83. This would appear to have been based on System III with the PDP-11, Z8000, 68000 and 8086 as targets. Considering the size of MS at the time and how busy they were with IBM and DOS I don’t think they would have had much time to do more than a basic port: they contracted out much of the work to SCO, a two man shop at the time. It would seem that MS owned the IP with SCO being a contractor & part-owned subsidiary. - This Altos manual https://web.archive.org/web/20170222131722/http://www.tenox.net/docs/xenix/… actually says that Xenix 2.x was still based on V7 and would seem to be a vanilla port, i.e. unlikely to include other stuff than V7, some 2BSD and of course MS' own stuff. - The next release, Xenix 3.0 in 83-84, still appears to be SysIII based and would remain easy from that perspective. However, given two years of polishing it may have picked up bits and pieces from the outside and the tool chains probably started to include MS’ own compilers, it would be harder to figure out what could be released. However, looking at this highly interesting leaflet http://www.os2museum.com/wp/wp-content/uploads/2012/10/IBM-Seminar-Proceedi… it would seem that it is still all SysIII, BSD and Microsoft code. In my opinion the real hurdle is finding a retired MS VP who’s interested in knocking on doors and making the case for this public relations move. Paul PS: There is scope for confusion over version numbers. It would seem that MS never directly sold Xenix, only via OEM’s. For example, IBM PC Xenix 1.0 would appear to be the same as MS Xenix 3.0

7 years, 7 months

1
0
0 0

standard types

by Larry McVoy

I have my own types.h that I carry around that has stuff like typedef unsigned char u8; typedef unsigned short u16; typedef unsigned int u32; typedef unsigned long long u64; typedef signed char i8; typedef signed short i16; typedef signed int i32; typedef signed long long i64; and I wonder why the original Unix authors didn't make something similar? Instead we have uint64_t and I don't see the added value of more chars. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm

7 years, 7 months

3
2
0 0

Re: [TUHS] THANK YOU for flavors! (fwd)

by Dave Horsfall

On Thu, 7 Dec 2017, Greg 'groggy' Lehey wrote: >> On Thu, 7 Dec 2017 11:01:51 +1100 (EST), Dave Horsfall wrote: > > Since we're being pedantic, note that this should be AEDT. EST is > ambiguous, but in general refers to the east coast of the USA. That appears to be how Alpine formats it (I certainly didn't write it)... If it can be overridden then naturally I'm all ears. >>> Serious question: is "FLAVOUR" accepted as an alias, or does the rest >>> of the world have to put up with American spelling? > > Think of it as a keyword. No national origin necessary. Fair enough, I suppose. > We really have better things to think of. Indeed; in the meantime I see you finally fixed your DNS... Yes, I 4xx mail from servers with an improper chain, in the hope that they'll eventually notice (it catches a lot of spammers). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 7 months

1
0
0 0

Re: [TUHS] Dash options

by Steffen Nurpmeso

Hello. ||On Wednesday, 29 November 2017 at 20:16:43 +0100, Steffen Nurpmeso wrote: ||> Greg 'groggy' Lehey <grog(a)lemis.com> wrote: ||>> On Monday, 27 November 2017 at 21:51:13 -0800, Jon Steinhart wrote: ||>>> Does anybody know the history of dash options? Were they ||>>> a UNIX thing or did UNIX borrow them from something earlier? ||>> ||>> If you mean specificall the dash, I can't help much. But there were ||>> similar ideas elsewhere. UNIVAC EXEC-8 (for the 1108, late 1960s) had ||>> options that followed the command with a comma, like: ||>> ||>> @RUN,G GOPU,STANDARD,STANDARD ||>> @ADD,PL ASGDMS . ASSIGNIERT DATENBASIS ||> ||> "WEIßT DATENBASIS ZU" or "ZUWEISUNG DATENBASIS" ... ||>> @ASG,A PF. . PF IST PROGRAMM-FILE MIT GOPU ||> ||> "PF IST PROGRAMM-DATEI MIT GOPU" or so. ... I have apologised for this brusque and rude tone in private. Unfortunately Greg Lehey was the one who took up that thread. Puh; he is also right correcting my statements, it should have been "Weist Datenbasis zu" and "PF ist Programmdatei mit GOPU" instead of what i falsely claimed. |The question that should have been asked with mild interest and |very kind should have been "Why has German been used to comment |this code?" at first, i am afraid to realize. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

7 years, 7 months

2
1
0 0

Re: [TUHS] [groff] [UTROFF] references, summary, index

by Doug McIlroy

Ralph, > > On unjustified text, fmt (which uses an algorithm purported to be like > > Knuth-Plass) > > I wonder if that accounts for modern, coreutils 8.28-1, fmt's weirdness > that I've seen for a while but never got around to investigating? > > $ yes x | fmt | awk '{print length, $0}' | uniq -c | sed 5q You threw it something of a curve ball--an infinite paragraph. At some point I suppose it chokes, and tries its best to make a semiparagraph of equal-length lines. (Since the real paragraph is not yet complete, it would be wrong to make the last line of the semiparagraph short.) Equilibrating apparently led to the split between 69- and 71-letter lines. Whether the alternation of 11 of one and 16 of the other is an infinite pattern or a subpattern is not clear. It could be part of a continued-fraction approximation, related to the staircse appearance of a bitmap "straight line". Doug

7 years, 7 months

2
1
0 0

What UNIX Artifacts Are Still Missing?

by Rudi Blom

Regarding Theodore Bashkow I found a reference in this article http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.53.880&rep=rep1&ty… "[Jain 90a], N. Jain, M. Schwartz and T. R. Bashkov, "Transport Protocol Processing at GBPS Rates.", Computer Communications Review, Vol. 20 (4), 1990, pp. 188-199." No idea if this 'bashkov' is the 'bashkow' in the 'what's missing' discussion. Cheers, rudi

7 years, 7 months

1
0
0 0

What UNIX Artifacts Are Still Missing?

by Warren Toomey

All, it's time to nudge the conversation away from debugging 2017 OOM issues and the pre-UNIX history of the Arpanet. We've been able to recover quite a deal of UNIX artifacts in the past two decades, but what artifacts (in your opinion) are still out there that we should try and unearth? Remember that the 50th anniversary is coming up in 2019. Here's my list: - more PDP-7 source code: the shell, the rest of the utilities - more 1st Edition source code: the rest of the utilities - ditto the missing bits of 3rd, 4th and 5th Editions - the Phil Foglio artwork that became a Usenix t-shirt (Armando, any ideas?) - more details on who was Ted Bashkow, and the story behind his (+ others?) analysis of the 1st Edition kernel at http://www.tuhs.org/Archive/Distributions/Research/Dennis_v1/PreliminaryUni… - a firm date on the day that Ken added pipes to the kernel :) What else should be we looking for? What physical artifacts (drawings, artwork etc.) have we missed that should be sought after? Cheers, Warren

7 years, 7 months

8
8
0 0

Re: [TUHS] V7 Addendem

by Doug McIlroy

> Was this [v7 addenda] put out by the Labs? It is definitely Research code from the Labs. How it

7 years, 7 months

2
2
0 0

V10 spell vs. spell.old?

by Aharon Robbins

Hi. What's the difference between spell.old and spell in the V10 sources? I'm guessing spell.old is the original version for the small-address-space PDP-11 and that plain spell takes better advantage of the roomier vax... Thanks, Arnold

7 years, 7 months

1
0
0 0

Re: [TUHS] shell PS1/PS2 which survive cut-paste

by Paul Ruizendaal

>> The choice of "# " and "> " interests me. Because roots prompt of >> "hash" has a side effect of making a cut-paste over it a comment in >> most shells. > > "#" as the root prompt predates # as the comment in the Bourne shell, > not to mention predating copy/paste entirely. (My understanding is that > the do-nothing command, ":" was used for comments. Talk about minimalist!) > > Same point for ">", since copy/paste didn't exist in the late 70s when > Bourne was doing the shell, it wasn't an issue. As early as V5 the (thompson) shell prompts were “#” and “%”, and “:” for a label. As the goto command exists in V4 (there is a man page for it), I would assume that those characters were used in V4 as well. So it would seem to go back to 1974. In the V7 (bourne) shell the default non-root prompt is “$”. Goto is dropped at this point. Don’t know when or where “>” was first used on Unix as a prompt character (on my boxes it still is “$”). Paul

7 years, 7 months

2
1
0 0

What UNIX Artifacts Are Still Missing?

by Paul Ruizendaal

> We've been able to recover quite a deal of UNIX artifacts in the past two > decades, but what artifacts (in your opinion) are still out there that > we should try and unearth? Remember that the 50th anniversary is coming up > in 2019. I’d be interested in anything on Spider/Datakit networking in V4-V7. (at them moment the trail starts at V8, with just a few hints in earlier source materials, and the bits that Noel found). My thinking is that there were two main lines of early networking development on Unix (and I realise that this gross simplification excludes many other worthy projects): 1. The “sockets” lineage from UoI NCP Unix -> BBN NCP Unix -> BBN TCP Unix -> 4.1a BSD -> 4.2 BSD 2. The “device” lineage from Spider -> Datakit -> UUCP -> streams -> STREAMS In the first lineage there is much material available, in the second very little. This is probably because Datakit was AT&T confidential at the time.

7 years, 7 months

1
0
0 0

Re: [TUHS] What UNIX Artifacts Are Still Missing?

by Nelson H. F. Beebe

Warren Toomey <wkt(a)tuhs.org> asks on Wed, 6 Dec 2017 08:21:13 +1000: >> - more details on who was Ted Bashkow, and the story behind his (+ others?) I found a short obituary at http://engineering.columbia.edu/web/newsletter/spring_2010/memoriam which is, in full: >> ... >> Theodore R. Bashkow Dr. Theodore R. Bashkow, professor emeritus of >> electricial engineering and computer science, died Dec. 23, 2009, at >> his home in Katonah, N.Y. See PDF version >> >> He was born in St. Louis, Mo., and attended Washington University, >> where he received his BS degree in mechanical engineering. He went on >> to receive his master’s and doctorate degrees at Stanford >> University. He served in the U.S. Air Force as a first lieutenant >> during World War II from 1943 to 1945. >> >> While in the Air Force, he served as maintenance officer and helped to >> stage the Enola Gay. In the 1950s, while at Bell Labs, Professor >> Bashkow became well known for his development of a new method for >> analyzing linear electrical networks, Professor Bashkow’s A matrix. He >> also became involved with digital computers. He joined the faculty of >> the Columbia Electrical Engineering Department in 1958 and helped >> transform the Electrical Engineering Department into the Department of >> Electrical Engineering and Computer Science. >> >> When, in 1979, this department was divided into the Electrical >> Engineering and Computer Science departments, Bashkow became one of >> the founding faculty members of Computer Science. He taught courses in >> digital logic, computer organization, and computer programming. He did >> research on parallel processing. In collaboration with Herbert >> Sullivan, he pioneered a new approach to that subject through the >> development of CHoPP, Columbia Homogeneous Parallel Processor, a >> large-scale, homogeneous, fully distributed parallel machine. A number >> of Columbia graduate students and a junior faculty member, David >> Klappholz, were also involved at various stages. >> >> In 1980, the Computer Science Department instituted an annual award in >> his honor, the Theodore R. Bashkow Award. Among his many affiliations, >> Professor Bashkow was an active member of IEEE, ACM, and Sigma Xi >> organizations. >> ... He is apparently not in Wikipedia. I then searched our local bibliography archives and found this publication-title summary (Bashkow is an uncommon name, so I didn't attempt to disambiguate the reported articles): MariaDB [bibtex]> select filename, label, substr(title,1,80) from bibtab where (author like '%Bashkow%') order by year, filename; +-------------------------+--------------------+----------------------------------------------------------------------------------+ | filename | label | substr(title,1,80) | +-------------------------+--------------------+----------------------------------------------------------------------------------+ | jacm.bib | Bashkow:1958:CPR | A ``Curve Plotting'' Routine for the Inverse Laplace Transform of Rational Funct | | ieeetranscomput.bib | Bashkow:1963:RDA | R63-106 The D 825 Automatic Operating and Scheduling Program | | ieeetranscomput.bib | Bashkow:1963:C | Contributors | | ieeetranscomput.bib | Bashkow:1963:PSD | A Programming System for Detection and Diagnosis of Machine Malfunctions | | ieeetranscomput.bib | Bashkow:1964:SCA | A Sequential Circuit for Algebraic Statement Translation | | fortran1.bib | Bashkow:1967:SDF | System Design of a FORTRAN Machine | | ieeetranscomput.bib | Bashkow:1967:SDF | System Design of a FORTRAN Machine | | ieeetranscomput1970.bib | Bashkow:1971:BSS | B71-6 System Structure in Data, Programs, and Computers | | ieeetranscomput1970.bib | Bashkow:1971:BIC | B71-2 Introduction to Computer Organization | | ieeetranscomput1970.bib | Bashkow:1973:CRO | Comment on Review of Operating Systems Survey | | ovr.bib | Sullivan77b | A Large Scale, Homogeneous, Fully Distributed Parallel Machine | | ovr.bib | Sullivan77a | A Large Scale Homogeneous Fully Distributed Parallel Machine | | sigarch.bib | Sullivan:1977:LSHb | A Large Scale, Homogenous, Fully Distributed Parallel Machine, II | | sigarch.bib | Sullivan:1977:LSHa | A large scale, homogeneous, fully distributed parallel machine, I | | ieeetranscomput1980.bib | Ghafoor:1989:BFT | Bisectional Fault-Tolerant Communication Architecture for Supercomputer Systems | | super.bib | Ghafoor:1989:BFT | Bisectional Fault-Tolerant Communication Architecture for Supercomputer Systems | | ieeetranscomput1990.bib | Ghafoor:1991:SOG | A study of odd graphs as fault-tolerant interconnection networks | +-------------------------+--------------------+----------------------------------------------------------------------------------+ 17 rows in set (2.67 sec) ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

7 years, 7 months

1
0
0 0

Re: [TUHS] ARPAnet now 4 nodes

by jnc＠mercury.lcs.mit.edu

> From: Jon Forrest > LBL has never been part of UC Berkeley. It's (always?) been a > Department of Energy laboratory managed by the Univ. Actually, I think if you go back far enough (1930's), it was part of UCB, back when Lawrence first started it. And of course the DoE didn't exist until 1977, so during the early ARPANET era if would have been under the AEC, and then I assume the Energy Research and Development Administration after 1974 (I assume it didn't go with the NRC when the AEC was split up). Noel

7 years, 7 months

1
0
0 0

Re: [TUHS] ARPAnet now 4 nodes

by Paul Ruizendaal

This page: http://www2.lbl.gov/Publications/75th/files/exhibit.html mentions 3 links between LBL and Arpanet: - In 1974, the Lab’s CDC 6600 became the first online supercomputer when it was connected to ARPANET, the Internet’s predecessor. - In 1986, when the Internet was on the verge of collapse from congestion, a Berkeley Lab researcher, Van Jacobson, co-developed the congestion control algorithms that allowed the Internet to keep growing. - In 1995, Jacobson and Steven McCanne developed MBone, the first successful software for multiparty audio and video conferencing over the Internet.

7 years, 7 months

3
2
0 0

Re: [TUHS] ARPAnet now 4 nodes

by Paul Ruizendaal

I don’t think anybody was thinking you wilfully misrepresented things, it is always interesting to hear about strands of history that might have been missed earlier. It would be helpful to better understand the time period, people involved and the scope of work. I’m a bit confused as to what time period you are referring to: I think you are referring to the initial development of Arpanet, i.e. the second half of the sixties. Is that correct? There is a page here with some info on events in that period and it may have missed some interesting development work done at LBL: https://www.livinginternet.com/i/ii_roberts.htm Paul > > Message: 7 > Date: Mon, 4 Dec 2017 19:46:21 -0800 > From: Deborah Scherrer <dscherrer(a)solar.stanford.edu> > To: tuhs(a)minnie.tuhs.org > Subject: Re: [TUHS] ARPAnet now 4 nodes > Message-ID: <8254fc85-12e6-4730-8f14-faf060ad6a70(a)solar.stanford.edu> > Content-Type: text/plain; charset=windows-1252; format=flowed > > Yes, Van Jacobson was involved. Great guy. So sorry you feel the need > to think I am lying. Why would I make up this stuff? I was a > teeny tiny piece of it. Doesn't affect my career one way or other. I > don't care what you believe, but this really did happen. > > D

7 years, 7 months

1
0
0 0

Re: [TUHS] ARPAnet now 4 nodes

by jnc＠mercury.lcs.mit.edu

> From: Deborah Scherrer > I don't know about the historical record. But everything I said is true, > based on my own personal experience. ... I was there, this happened. If > people didn't write it down, I don't know why. FWIW, I was actually at many of those meetings. (You can find my name in a lot of those Meeting Notes.) Nobody from LBL, or UCB in general, was involved - and the Meeting Notes (which, you will note, are quite detailed) indicate the same thing. (Later on, of course, Van Jacobson of LBL did some imporant work on TCP congestion control, but that was in '87 or so - I can't instantly lay my hands on my copy of Van's famous e-mail, to get a more exact date - some years after the full-scale deployment of TCP/IP in January, 1983.) > Why would I misrepresent? Perhaps you are conflating several different things in your memory? Human memory is very fallible, which is why historians prefer contemporary documents (and even those sometimes have errors). Here: http://www.chiappa.net/~jnc/nontech/tmlotus.html is a mildly amusing example (from a completely different arena) of all that. Noel

7 years, 7 months

3
2
0 0

Re: [TUHS] ARPAnet now 4 nodes

by jnc＠mercury.lcs.mit.edu

> From: Deborah Scherrer <dscherrer(a)solar.stanford.edu> > A lot of the TCP/IP development was done at the Lab. I think this is incorrect. The "Birth of the Internet" plaque: http://ana-3.lcs.mit.edu/~jnc/history/BirthInternetL.jpg mentions a number of organizations, but not UCB. Also, if you look at early TCP/IP Meeting Notes, which list all the meeting attendees, e.g.: http://www.postel.org/ien/txt/ien3.txt http://www.postel.org/ien/txt/ien121.txt http://www.postel.org/ien/txt/ien134.txt http://www.postel.org/ien/txt/ien121.txt http://www.postel.org/ien/txt/ien160.txt http://www.postel.org/ien/txt/ien175.txt (plus a bunch more only available in PDF form here: http://www.postel.org/ien/pdf which I couldn't be bothered to look at, since they are huge scans which take a while to download - see the IEN Index for the numbers) you won't find anyone from UCB listed in any of them. Berkeley did produce a now-common _implementation_ of TCP/IP, it's true, but it had nothing to do with the "development" of TCP/IP. Noel

7 years, 7 months

2
1
0 0

signals and blocked in I/O

by Larry McVoy

Does anyone remember the reason that processes blocked in I/O don't catch signals? When did that become a thing, was that part of the original design or did that happen in BSD? I'm asking because I'm banging on FreeBSD and I can wedge it hard, to the point that it won't recover, by just beating on tons of memory. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm

7 years, 7 months

13
29
0 0

Re: [TUHS] ARPAnet now 4 nodes

by jnc＠mercury.lcs.mit.edu

> From: Deborah Scherrer > the initial research on the arpanet was done at Lawrence Berkeley Lab I was interested to find out more about this: I looked in Hafner, "Where Wizards Stay Up Late" (the popular, but well-researched, book on the ARPANET) but couldn't find 'Lawrence Berkeley' or 'LBL' in the index (although it did have Lawrence Livermore); there were a couple of 'Californa, University of (at Berkeley' listings, but none covered this. In Abbate, "Inventing the Internet" (the first half of which covers the ARPANET), nothing under any of 'Lawrence Berkeley', 'LBL', 'Berkeley' or 'California'. In Norberg/O'Neill, "Transforming Computer Technology" (the standard ARPA history, which has extensive coverage of the ARPANET project), there was one entry for 'Californa, University (Berkeley)', which might be about the work you refer to: "IPTO issued a contract for a 'network' project at the Berkeley campus of the University of California ... because of the presence at Berkeley of specialists in programming languages and heuristic programming". But there's nothing about what was produced. Is there anything you can point me at that provides more detail? Thanks! Noel

7 years, 7 months

3
3
0 0

Re: [TUHS] ARPAnet now 4 nodes

by jnc＠mercury.lcs.mit.edu

> SRI, UCSD, UCLA, Utah: Ooops, typo: UCS_B_. Noel

7 years, 7 months

1
0
0 0

Re: [TUHS] ARPAnet now 4 nodes

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall > The ARPAnet reached four nodes on this day in 1969 (anyone know which?) SRI, UCSD, UCLA, Utah: http://www.chiappa.net/~jnc/tech/arpageo.html All West Coast, plus Utah. Next was BBN; if you look at the IMP numbers, in HOSTS.TXT, they were assigned in order of installation. > at least one "history" site reckoned the third node was connected in > 1977 ... Well, I can believe that perhaps there were only three left by > then... No: http://www.chiappa.net/~jnc/tech/arpalog.html 1977 was not too many years before the peak in size (with the MILNET split coming in October, 1983). Per: http://www.chiappa.net/~jnc/tech/arpanet.html "Prior to the split, in 1983, there were 113 IMPs in the ARPANET; after the ARPANET/MILNET split, the MILNET consisted of 65 nodes, leaving the ARPANET with 68 nodes." Noel

7 years, 7 months

1
0
0 0

Re: [TUHS] RIP J.F.Ossanna

by Larry McVoy

On Wed, Nov 29, 2017 at 08:00:55PM +0100, Steffen Nurpmeso wrote: > Larry McVoy <lm(a)mcvoy.com> wrote: > |On Mon, Nov 27, 2017 at 07:06:51PM -0500, Ron Natalie wrote: > |> 1977 marks my entry into the world of UNIX. I've always stated there was > |> only one person who truly understood nroff and he was dead. > |> I mourn the fact that of all the UNIX greats I've met, I missed out on > |> Ossanna. > > |I think one could argue that James Clark has a pretty good handle on > |roff (having written the GNU version of nroff/troff/tbl/eqn/pic etc). > > And Werner Lemberg, who carried the torch for the last almost two > decades. He brought in some really great improvements, like > arguments for strings, which allows to write pretty much TeX like > a.k.a. inline if you want to (as in "this is \*[I talic] text"). Yep. James exited stage left and Werner stepped in. I mean no disrespect to anyone, I was just saying that James has a really good handle on roff, he redid it all. I admire him for doing so (even though I curse the fact that he did it in C++).

7 years, 7 months

3
3
0 0

Unix on PDP8?

by Will Senn

All, Was Unix ever ported to a PDP8, or any other 12 bit environment, for that matter? If not, why not? My understanding, such as it is, is that Unix was created on the PDP7 - btw, thank you very much, Ken Thompson, you definitely changed my world :), which is an 18bit machine, and that it soon found its first real home on the 16 bit PDP11 series of machines (an 11/20), and from there, ever upward or at least ever onward. I'm curious about it for historical reasons, of course, but also because I've been messing around in the PDP8 emulation world and enjoying the excursion into simplified ISA and memory architectures. -will

7 years, 7 months

8
12
0 0

Re: [TUHS] UNIX on S/370

by Larry McVoy

So tape I can see being more weird, but isn't raw disk just "don't put it in buffer cache"? >From what I've been able to gather early tape in Unix was dicey, something about the driver doing seek. Was there more to it than that? On Tue, Nov 21, 2017 at 02:33:55AM +0000, Clem Cole wrote: > It???s not so much that they don???t mix, it???s not quite the same. Some > coprocessor ideas work really well into the Unix I/O model, others don't. > Raw disk and tape I/O ala a PDP11 or VAX for instance is not easy on an > IBM channel controller or a CDC PPU. > > > > > > > > > On Mon, Nov 20, 2017 at 6:45 PM Larry McVoy <lm(a)mcvoy.com> wrote: > > > On Mon, Nov 20, 2017 at 06:43:28PM -0500, Ron Natalie wrote: > > > > > > > > > > I get that PDP-11 and VAX used memory mapped I/O but was that somehow > > > exposed above the device driver layer? If so, I missed that, because I > > had > > > no conceptual or technical problem with talking to an I/O > > > > > > > channel, it was pretty easy. And I suck at writing drivers. > > > > > > There's nothing that restricts a device driver to memory mapped I/O. > > You > > > do what ever you have to do to initiate the I/O. Even the x86's > > originally > > > used special instructions to start the I/O (in/out). The DENELCOR HEP > > > supercomputer (we did this port around 1983) we had to bounce I/O > > requests > > > off a separate I/O processor different from where the kernel was running. > > > Similar constucts were used on other machines. > > > > Yeah, that's what I thought. But other people were saying that I/O > > processors and Unix didn't mix. I don't get that, seems like whatever > > the model is is hidden under the driver, that's the whole point of the > > driver design is it not? > > > -- > Sent from a handheld expect more typos than usual -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm

7 years, 7 months

3
2
0 0

Re: [TUHS] Dash options

by jnc＠mercury.lcs.mit.edu

> From: Charles Anthony > Entry points are usually defined as "foo$bar", where "foo" is the > segment name, and "bar" an entry point in the segment symbol table. I > believe that the degerate case of "foo$" is treated as "foo$foo" by the > shell. So I'm curious about how this, and additional names, interact. (For those who aren't familiar with Multics, a segment [file, sort of] can have multiple names. This is sort of like 'hard links' in Unix, except that in Multics one name, the "primary name" is very slightly preeminent. See here: http://web.mit.edu/multics-history/source/Multics/mdds/mdd006.compout page 2-5, for more, if you're interested.) So if I have a segment with primary name 'foo', and additional names 'bar' and 'zap', and I say 'zap' to the Multics shell, I assume it does a call to zap$zap, which finds the segment with the primary name 'foo', and calls the 'zap' entry therein? > Multics rulez; UNIX droolz Dude, you clearly have Very Large brass ones to send that to this list! :-) Noel

7 years, 7 months

2
1
0 0

Dash options

by Jon Steinhart

Does anybody know the history of dash options? Were they a UNIX thing or did UNIX borrow them from something earlier? Jon

7 years, 7 months

10
10
0 0

Re: [TUHS] Dash options

by Doug McIlroy

Early on, when multics was understood to have one big, segemented address space, it was expected that PL/I name qualification ($) would serve to address segments. I do not know whether that idea was actually implemented. Doug

7 years, 7 months

3
2
0 0

/bin/true (was [TUHS] basic tools / Universal Unix)

by Ron Natalie

My favorite reduction to absurdity was /bin/true. Someone decided we needed shell commands for true and false. Easy enough to add a script that said "exit 0" or exit 1" as its only line. Then someone realized that the "exit 0" in /bin true was superfluous, the default return was 0. /bin/true turned into an empty, yet executable, file. Then the lawyers got involved. We got a version of a packaged UNIX (I think it was Interactive Systems). Every shell script got twelve lines of copyright/license boilerplate. Including /bin true. The file had nothing but useless comment in it.

7 years, 7 months

15
22
0 0

Re: [TUHS] Dash options

by jnc＠mercury.lcs.mit.edu

> Multics had some kind of `attach' and `detach' of I/O streams, well > known to Ossanna, so perhaps dup(2), and a Thompson-shell syntax to go > with it meant `>' was earmarked early on. According to "The Evolution of the Unix Timesharing System", full path names arrived later than I/O redirection, so by they time they needed a separator, '>' and '<' were gone. '/' also has the advantage of being a non-shift character! Noel PS: Re-reading that, I see that early Unix did not have an exec() call (as I was just discussing); it was done in user mode, with normal read and write calls.

7 years, 7 months

3
2
0 0

Re: [TUHS] Dash options

by Paul Ruizendaal

> On Tue, Nov 28, 2017 at 2:36 PM, Paul Winalski <paul.winalski(a)gmail.com> > wrote: > >> MS/DOS patterned its command line >> >> syntax after RT-11 and inherited the slash as a command option >> introduction from there. > > Minor correction... To do a CDC style patient zero history ;-) RT11 took > it from DOS/8, CP/M took it from RT11, then finally DOS-86 which became > PC-DOS ney MS/DOS took it from CP/M. I think Gary Kildall was very much into the PDP-8 when teaching at the Naval Post Graduate School in the early 70's (doing the FORTRAN/8 compiler for instance). Can't find the link now, but I read somewhere that his work with the 8008 and 8080 was guided by the idea of having a PDP-8 like machine in his home office. For CP/M's command syntax RT11 probably did not come into it. I just had a quick glance through the CP/M 1.4 - 2.2 manuals, and I did not see slash options (or any other option character). Microsoft bought QDOS as a base for PC-DOS/MS-DOS. The QDOS system calls were done such that converting existing 8080 CP/M code with Intel's source level 8080-to-8086 asm converter would generate the correct code. The FAT file system was modeled after the one used by MS Disk BASIC for the 8086. Not sure where the QDOS command line came from, other than CP/M. MS did a lot of its early development on a PDP-10: perhaps that was an inspiration too. Sorry for getting off-Unix-topic...

7 years, 7 months

1
0
0 0

Re: [TUHS] Harvard and Von Neumann Architectures and Unix

by jnc＠mercury.lcs.mit.edu

> From: Doug McIlroy > But if that had been in D space, it couldn't have been executed. Along those lines, I was wondering about modern OS's, which I gather for security reasons prevent execution of data, and prevent writing to code. Programs which emit these little 'custom code fragments' (I prefer that term, since they aren't really 'self-modifying code' - which I define as 'a program which _changes_ _existing_ instructions) must have some way of having a chunk of memory into which they can write, but which can also be executed. > Where is the boundary between changing one instruction and changing them > all? Or is this boundary a figment of imagination? Well, the exec() call only overwrites existing instruction memory because of the semantics of process address space in Unix - there's only one, so it has to be over-written. An OS operating in a large segmented single-level memory could implement an exec() as a jump.... BTW, note that although exec() in a single address-space OS is conventionally something the OS does, this functionality _could_ be moved into the user space, provided the right address space primitives were provided by the OS, e.g. 'expand instruction space'. So the exec() code in user space would i) find the executable, ii) see how much of each kind of memory it needs, iii) get the OS to give it a block of memory/address space where the exec() code can live while it's reading in the new code, iv) move itself there, v) use standard read() calls to read the new image in, and then vi) jump to it. Yes, it's probably simpler to implement it in the OS, but if one's goal is to minimize the functionality in the kernel... Noel

7 years, 7 months

9
9
0 0

A sober reminder of why distributed archiving is important

by Will Senn

In case you missed it: https://www.spectrum.ieee.org/view-from-the-valley/tech-history/silicon-rev… It is important to keep the conversations alive and not to file your memory boxes away in the attic. Thanks for sharing what you know and especially for making your documents and bits available. -will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF

7 years, 7 months

2
1
0 0

TTY8

by Ron Natalie

OK, we were discussing terminals this morning with some other old guys. If I knew the answer to this I've forgotten. Every PDP-11 UNIX I ever used had the console KL-11 as /dev/tty8. The question is why. My guess is that for some reason an 8 terminal multiplexor (DZ-11?) was stuck at tty0, but why?

7 years, 7 months

4
3
0 0

Re: [TUHS] Harvard and Von Neumann Architectures and Unix

by jnc＠mercury.lcs.mit.edu

> From: Larry McVoy >> they aren't really 'self-modifying code' - which I define as 'a program >> which _changes_ _existing_ instructions > Isn't that how dtrace works? I'm not familiar with dtrace(), but if it modifies some other routine's code, then it would not be "self" modifying, right? Oh, another category, sort of like biological viruses (which are in a grey zone between 'alive' and not): the PDP-11 paper tape bootstrap: http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/bootloader.mac in which the program's own code _is_ modified - but not by program instructions, but by data on the paper tape it is reading in. It's entertainingly convoluted (the copy above should be well-enough commented to make it pretty easy to understand what's going on). Noel

7 years, 7 months

2
1
0 0

RIP J.F.Ossanna

by Dave Horsfall

We lost J.F. Ossanna on this day in 1977; he had a hand in developing Unix, and was responsible for "roff" and its descendants. Remember him, the next time you see "jfo" in Unix documentation. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 7 months

3
3
0 0

Re: [TUHS] UNIX on S/370

by jnc＠mercury.lcs.mit.edu

> From: Kevin Bowling > The earliest stuff may be covered by Novell's grant of early code. > ... > Would be fun to run *ix on any of them. Alas, the Bell port of Unix to the /370 needs that underlying layer of code from IBM, and that's probably not going to escape. Too bad, it would be pretty cool. Noel

7 years, 7 months

2
1
0 0

Harvard and Von Neumann Architectures and Unix

by Will Senn

I am curious about how the Harvard Architecture relates to Unix, historically. If the Harvard Architecture is predicated on the separation of code from data in order to prevent self-modifying code (my interpretation), then it would seem to me to be somewhat at odds with a Unix philosophy of extreme abstraction (code, data, it's all 0's and 1's, after all). In my naive understanding, the PDP-11 itself, with the Unibus and apparently agnostic ISA seem to summarily reject the Harvard Architecure... My question is - was there tension around Harvard and Von Neumann architectures in Unix circles and if so, how was it resolved? Thanks, Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF

7 years, 7 months

3
2
0 0

Datakit in V7

by Paul Ruizendaal

There are some little bits in the public V7 source code that suggest that it had support for Datakit, but that it was scrubbed from the public release: There is a Datakit header file: http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/include/dk.h and Datakit state bits are defined in 'sys/tty.h': http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/include/sys/tty.h Does anyone know if this assumption (Datakit support in V7) is correct? Perhaps more specific, was there a remote login program for V7/Datakit, of for V6/Spider? For V8/Datakit there was 'dcon', but perhaps this was built on earlier programs. (I'm aware of 'cu' of course, but that does not support Datakit or Spider). Being able to login to another host on the network seems so useful that it is hard to believe that a precursor to 'dcon' did not exist for V6 and/or V7.

7 years, 7 months

1
0
0 0

Re: [TUHS] TCP/IP networking in 8th edition unix

by Paul Ruizendaal

Thanks for explaining that. I think it may be for 10th edition though. I searched for ipcopen() and 'gated' in the 8th edition source and could not find them. In that search I did find a few bits that strongly suggest that IP over Datakit was what was used in late '85 (when dmr posted about this). In /usr/src/cmd/inet/READ_ME there is an example configuration that seems to match with dmr's example. In that file an IP over a Datakit channel appears to be configured. (see http://chiselapp.com/user/pnr/repository/v8unix/artifact/6d09b05c7f06a2cc?l…) The program 'dkipconfig' sets up a circuit and pushes the IP discipline on the stream, both on the local end and on the remote end. It sets fixed local and remote addresses, much the same as with a 'slip' line. (see http://chiselapp.com/user/pnr/repository/v8unix/artifact/6c5f3267b58721a6?l…) On Sat, Nov 25, 2017 at 4:50 PM, William Cheswick <ches at cheswick.com> wrote: > > Nope, not IP over Datakit, as I recall. It was quite interesting to work at > a site (Bell Labs) where there were two distinct network technologies. > > [--snip--] > > This library was socks about seven years before socks, originally written by > Presotto and Howard Trickey. The relay program was originally called > “gated”, but that wouldn’t do after a while. I renamed it “proxyd”, and > that is the first use of “proxy" in this context that I am aware of. > > If you were on AT&T’s intranet and wanted to connect externally, you ripped > out the entire socket dance and replaced it with an ipcopen call. I also > distributed common modified clients, like ptelnet, pftp, pfinger, etc. > > I still have all this code, and I suppose it ought to go in an archival > repository. I can’t imagine that AT&T/Lucent/Alcatel/Nokia would care at > this point. Anyone want it? >

7 years, 7 months

1
0
0 0

TCP/IP networking in 8th edition unix

by Paul Ruizendaal

I'm trying to figure out how tcp/ip networking worked in 8th edition Unix. I'm starting from dmr's paper about streams (http://cm.bell-labs.co/who/dmr/st.html) the V8 man pages (http://man.cat-v.org/unix_8th/3/) and browsing the source code (tarball here http://www.tuhs.org/Archive/Distributions/Research/Dan_Cross_v8/) In the below I use 'socket' to mean a file descriptor bound to a network connection. My current understanding is like this: - The hardware interface is exposed as a character device; for tcp/ip only ethernet is supported. Directly accessing this device reads/writes ethernet frames. - One can push an 'ip' module (only) onto an ethernet device; this module also handles ARP. Once this is done IP messages are queued to the virtual ip devices, /dev/ipXX. The device minor number XX equals the protocol number, i.e. the ip packets are demultiplexed into separate virtual devices. IP packets from multiple ethernet cards all end up on the same virtual ip devices. I'm not sure if one can still read/write to the ethernet device after pushing the ip module, but I think you can, creating a raw IP interface so to say. - On /dev/ip6 one can push a TCP module. The TCP module handles the TCP protocol and demultiplexes incoming traffic to the virtual /dev/tcpXX devices. On /dev/ip17 one can push a UDP module. The UDP module handles the UDP protocol and demultiplexes incoming traffic to the virtual /dev/udpXX devices. Not sure wether the ip6 and ip17 devices can still be read/written after pushing these disciplines. - There are 100 udp devices, /dev/updXX. To open a UPD socket, one opens an unused udp device (through linear search). This socket accepts binary commands ('struct upduser') through the read()/write() system calls. There is a command to set the local port (effectively 'bind') and a comment to also set the foreign address and port (effectively 'bind+connect'). As long as the socket is not connected actual datagrams are preceded by a command header with the address/port information (effectively 'sendto'/'recvfrom'). Once the socket is connected, it is no longer possible to send further commands, but each write/read is a datagram. For udp sockets it is not possible to specify the local address: it is chosen by the system to match with the given foreign address. - There are 100 tcp devices /dev/tcpXX. Initial connection is always over an odd numbered device. To open a TCP socket, one opens an unused tcp device (through linear search). This socket accepts binary commands ('struct tcpuser') through the read()/write() system calls. There is a command to actively connect (effectively 'connect' with optional 'bind'), and a command to passively listen (effectively 'bind'+'listen'). If the connect command is sent, one can read one more response block and then the socket becomes a regular tcp socket. If the listen command is sent, one can read multiple response blocks, one for each new client (effectively 'accept'). Those response blocks contain a device number for the new client connection, i.e. one has to subsequently open device /dev/tcpXY to talk to the client. This number is always even, i.e. locally initiated tcp connections are over odd numbered tcp devices, and remotely initiated connections are over even numbered tcp devices - not sure what the significance of this is. - The above seems to be modeled on the Datakit setup, where the network is exposed as 520 virtual devices, one for each channel, as /dev/dk/dkXXX. These channels than also seem to accept binary command blocks through the read()/write() interface, with a 'connect' type command changing the connection into a data only channel. Anybody on the list with 8th edition experience who can confirm that the above understanding is about correct? Paul

7 years, 7 months

4
4
0 0

Re: [TUHS] Harvard and Von Neumann Architectures and Unix

by jnc＠mercury.lcs.mit.edu

> From: Will Senn <will.senn(a)gmail.com> > I am curious about how the Harvard Architecture relates to Unix, > historically. If the Harvard Architecture is predicated on the > separation of code from data in order to prevent self-modifying code (my > interpretation) That's not the 'dictionary' definition, which is 'separate paths for instructions and data'. But let's go with the 'no self-modifying code' one for the moment. The thing is that self-modifying code is pretty much an artifact of the dawn of computers, before the economics of gates moved from that of tubes, to transistors, and also before people understood how important good support for subroutines was. (This latter is a reference to how Whirlwind did subroutines, with self-modifying code.) Once people had index registers, and lots of registers in general, self-modifying code (except for a few small, special hacks like bootstraps which had to fit in tiny spaces) became as dead as the dodo. It's just a Bad Idea. > then it would seem to me to be somewhat at odds with a Unix philosophy > of extreme abstraction (code, data, it's all 0's and 1's, after all). The people who built Unix were fundamentally very practical. Self-modifing code is not 'practical'. (And note that Unix from V4: http://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/ken/text.c onward has support for pure text - for practical reasons). > the PDP-11 itself, with the Unibus and apparently agnostic ISA seem to > summarily reject the Harvard Architecure... You could say that of a zillion computers. The only recent computer I can think of offhand with separate instruction and data paths was the AMD 42K (nice chip, I used it in a product we built at Proteon). They had separate ports for instructions and data purely for performance reasons. (Our card had a pathway which allowed the CPU to write the instruction memory, needed during booting, obviously; the details as to how we did it escape me now.) > From: Jon Steinhart > For all intents and purposes instructions were separate from data from > the PDP 11/70 on. s/70/45/. And the other -11 memory management (as on the /40, /23, etc) does allow for execute-only 'segments' (they call them 'pages' in the later versions of the manual, but they're not) - again, separating code from data. Unix used this for shared pure texts. And note that those machines with separate I+D space don't meet the dictionary definition either, because they only have one bus from the CPU to memory, shared between data and instruction fetches. Noel

7 years, 7 months

5
5
0 0

Re: [TUHS] Harvard and Von Neumann Architectures and Unix

by jnc＠mercury.lcs.mit.edu

> From: Doug McIlroy > Optimal code for bitblt (raster block transfers) in the Blit Interesting case. I'm not familiar with BitBLT codes, do they actually modify the existing program, or rather do they build small custom ones? Only the former is what I was thinking of. Noel

7 years, 7 months

5
4
0 0

Re: [TUHS] Harvard and Von Neumann Architectures and Unix

by Doug McIlroy

>From the discussion of self-modifying code: >> Optimal code for bitblt (raster block transfers) in the Blit > > Interesting case. I'm not familiar with BitBLT codes, do they actually modify > the existing program, or rather do they build small custom ones? Only the > > former is what I was thinking of. > It built small custom fragments of code. But if that had been in D space, it couldn't have been executed. >> Surely JIT compiling must count as self-modifying code. > > If it does, then my computer just runs one program from when I turn it > on. It switches memory formats and then is forever extending itself and > throwing chunks away. Exactly. That is the essence of stored-program computers. The exec system call is self-modification with a vengeance. Fill memory-and-execute is the grandest coercion I know. What is data one instant is code the next. It's all a matter of viewpoint and scale. Where is the boundary between changing one instruction and changing them all? Or is this boundary a figment of imagination? Doug

7 years, 7 months

1
0
0 0

Re: [TUHS] TTY8

by jnc＠mercury.lcs.mit.edu

> From: "Ron Natalie" > Every PDP-11 UNIX I ever used had the console KL-11 as /dev/tty8. > The question is why. Blast! I have this memory of reading an explanation for that somewhere - but I cannot remember what it was, or where! I've done a grep through my hoard of Unix documents, looking for "tty8", but no hits. Noel

7 years, 7 months

1
0
0 0

Re: [TUHS] Harvard and Von Neumann Architectures and Unix

by Doug McIlroy

> The thing is that self-modifying code is pretty much an artifact of the dawn > of computers, [...] > > It's just a Bad Idea. Surely JIT compiling must count as self-modifying code. Optimal code for bitblt (raster block transfers) in the Blit

7 years, 7 months

4
3
0 0

Re: [TUHS] Spell - was tmac: Move macro diagnostics away from `quotes'

by Doug McIlroy

Repeat, slightly modified, of a previous post that got shunted to the attachment heap. > I am curious if anyone on the list remembers much > about the development of the first spell checkers in Unix? Yes, intimately. They had no relationship to the PDP 10. The first one was a fantastic tour de force by Bob Morris, called "typo". Aside from the file "eign" of the very most common English words, it had no vocabulary. Instead it evaluated the likelihood that any particular word came from a source with the same letter-trigram frequencies as the document as a whole. The words were then printed in increasing order of likelihood. Typos tended to come early in the list. Typo, introduced in v3, was very popular until Steve Johnson wrote "spell", a remarkably short shell script that (efficiently) looks up a document's words in the wordlist of Webster's Collegiate Dictionary, which we had on line. The only "real" coding he did was to write a simple affix-stripping program to make it possible to look up plurals, past tenses, etc. If memory serves, Steve's program is described in Kernighan and Pike. It appeared in v5. Steve's program was good, but the dictionary isn't an ideal source for real text, which abounds in proper names and terms of art. It also has a lot of rare words that don't pull their weight in a spell checker, and some attractive nuisances, especially obscure short words from Scots, botany, etc, which are more likely to arise in everyday text as typos than by intent. Given the basic success of Steve's program, I undertook to make a more useful spelling list, along with more vigorous affix stripping (and a stop list to avert associated traps, e.g. "presenation" = pre+senate+ion"). That has been described in Bentley's "Programming Pearls" and in http://www.cs.dartmouth.edu/~doug/spell.pdf. Morris's program and mine labored under space constraints, so have some pretty ingenious coding tricks. In fact Morris has a patent on the way he counted frequencies of the 26^3 trigrams in 26^3 bytes, even though the counts could exceed 255. I did some heroic (and probabilistic) encoding to squeeze a 30,000 word dictionary into a 64K data space, without severely affecting lookup time. Doug

7 years, 7 months

4
3
0 0

Re: [TUHS] Spell - was tmac: Move macro diagnostics away from `quotes'

by Nelson H. F. Beebe

BibTeX entries for the complete contents of the Bell System Technical Journal family are in the TeX User Group archives at http://www.math.utah.edu/pub/tex/bib/bstj1970.bib [change 1970 to other decades, and .bib to .html for live hyperlinks]. The PDF URLs for bstj.bell-labs.com no longer work, and the ones for www.alcatel-lucent.com, such as http://www.alcatel-lucent.com/bstj/vol57-1978/articles/bstj57-6-2155.pdf now redirect to an HTML page. Otherwise, articles are available from the Wiley site at http://onlinelibrary.wiley.com/journal/10.1002/(ISSN)1538-7305/issues/ but are behind a paywall. There are also copies in the IEEE eXplore database at http://ieeexplore.ieee.org/xpl/RecentIssue.jsp?reload=true&punumber=6731002 I tried to find the URLs at https://web.archive.org/, but it does appear to have them. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

7 years, 7 months

8
8
0 0

Re: [TUHS] Spell - was tmac: Move macro diagnostics away from `quotes'

by jnc＠mercury.lcs.mit.edu

> From: "Nelson H. F. Beebe" > The PDF URLs for bstj.bell-labs.com no longer work, and the ones for > www.alcatel-lucent.com ... now redirect to an HTML page. With any luck, someone scraped them before they went. I've gotten in the habit of scraping all the Web content I look at, since it has (as above) a distressing tendency to vapourize. Noel

7 years, 7 months

2
1
0 0

Re: [TUHS] A man easter-egg (gimme gimme gimme)

by Nemo

On 24 November 2017 at 10:11, Nemo <cym224(a)gmail.com> wrote: > On 22 November 2017 at 03:48, <arnold(a)skeeve.com> wrote (in part): >>> As a former developer and manager, I would be really pissed off if my >>> programmers wasted their time on writing useless frippery instead of >>> quality code, and I would certainly have a little chat with them... >> >> I think that this is totally appropriate for code being developed >> for a paid product. > > I would say this is context-sensitive (industry, customers, ...). One > version of MS Word had an animation of a cartoon monster crushing "WP' > (somewhere in the credits, I recall). > > N. I really must be more careful with replies. The above was meant for TUHS, not just Arnold. N.

7 years, 7 months

1
0
0 0

First CRT terminal on Unix?

by Nigel Williams

I stumbled into a reddit post on Unix with the claim about early Unices only being accessed via printing terminals, and it suggested a question to me as to the first “glass teletype” or CRT terminal to be used with Unix. Given the DEC-centric nature of early Unix I would guess perhaps a VT05 or VT52 but I’m keen to know if anyone from those early years recollects what happened and when regarding Unix terminal access alternatives aside from the venerable 33KSR or 33ASR.

7 years, 7 months

10
19
0 0

A man easter-egg (gimme gimme gimme)

by Edouard KLEIN

Hi all, An easter-egg in the version of man that is installed on the most popular Linux distros has recently been discovered after being there for 6 years: https://unix.stackexchange.com/questions/405783/why-does-man-print-gimme-gi… It is for example discussed here: https://news.ycombinator.com/item?id=15747313 It makes man print 'gimme gimme gimme' if called at "Half past twelve", as in the ABBA song. I check on BSD, but man seems to be a shell script on FreeBSD, so it's immune from the easter egg: https://github.com/freebsd/freebsd/blob/master/usr.bin/man/man.sh Do you have any UNIX easter-egg stories ? Putting some in, or discovering one... Was this kind of humor tolerated in the professional settings where UNIX first circulated, or was it frowned upon ?

7 years, 7 months

10
13
0 0

Re: [TUHS] A man easter-egg (gimme gimme gimme)

by jnc＠mercury.lcs.mit.edu

> From: "Ron Natalie" > After making a stink about it, Proteon removed (or just changed) the > password. We added a 'disable field service password' option to the configuration (for those who wanted to keep FS out), changed the password (since the old one was blown), and stored the new one in encrypted form - hence the message! :-) Noel

7 years, 7 months

1
0
0 0

OT: XPL compiler available

by Arnold Robbins

Path: eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!adore2!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: Shoefoot <shoefoot(a)gmail.com> Newsgroups: comp.compilers Subject: Announcing the initial release of an XPL Compiler Date: Tue, 21 Nov 2017 09:25:43 -0800 (PST) Organization: Compilers Central Sender: news(a)iecc.com Approved: comp.compilers(a)iecc.com Message-ID: <17-11-001(a)comp.compilers> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="19370"; mail-complaints-to="abuse(a)iecc.com" Keywords: history, translator Posted-Date: 21 Nov 2017 14:37:00 EST X-submission-address: compilers(a)iecc.com X-moderator-address: compilers-request(a)iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: feeder.eternal-september.org comp.compilers:3921 Announcing the initial release of the XPL to C source translator. The XPL language is a dialect of PL/I created by McKeeman, Horning and Wortman and documented in their book "A Compiler Generator" published in 1970. XPL is a procedural language with structured program flow. The language supports integer arithmetic and logical operations. XPL supports dynamic string variables and powerful character string manipulation features. The compiler and the runtime are written in C. The compiler generates C source so anyone with a working C compiler can compile and execute code written in XPL. XPL and the BNF analyzer were the cutting edge of compiler technology 50 years ago. This release includes both the compiler and the BNF analyzer written in the late 60s. You can download the source here: https://sourceforge.net/projects/xpl-compiler

7 years, 7 months

1
0
0 0

Re: [TUHS] A man easter-egg (gimme gimme gimme)

by arnold＠skeeve.com

Warner Losh <imp(a)bsdimp.com> wrote: > On Wed, Nov 22, 2017 at 9:11 AM, <arnold(a)skeeve.com> wrote: > > > Ian Zimmerman <itz(a)very.loosely.org> wrote: > > > > > On 2017-11-22 01:48, arnold(a)skeeve.com wrote: > > > > > > > Try: > > > > > > > > gawk --nostalgia > > > > > > ~$ gawk --nostalgia > > > awk: bailing out near line 1 > > > Aborted > > > > > > Maybe it still needs a program? > > > > No, that was the joke. Early Unix awk used to say exactly that > > message, on almost any problem, often followed by a core dump. > > > > (I never claimed the easter egg was non-lame.) > > > > There were T-Shirts of this at early conferences as well. Showed a picture > of a vaguely puffin-like bird baling of an airplane made up of what looked > like ascii characters {}()|/... Google is unable find one though, so my > memory may be rusty here... > > Warner I have such a shirt. Maybe I can scan it. :-) Arnold

7 years, 7 months

1
0
0 0

Re: [TUHS] APPLIX-L EPROM programmers

by Dave Horsfall

On Thu, 23 Nov 2017, Matthew Geier wrote: > There is a brake computer for the centre bogie and a microprocessor in > the auxillary converter too. Centre bogie? How does that work on curves? Or is it part of the coupler? -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 7 months

1
0
0 0

UNIX on S/370

by Nemo

Recent commentary on porting led me to read the article on porting UNIX to S/370 (https://www.bell-labs.com/usr/dmr/www/otherports/ibm.pdf) to support 5ESS development because the existing PDP11s were being overwhelmed. I confess to not having this read this before and find it interesting. Any recollections from anyone on the matter. And whatever happened to it? N.

7 years, 7 months

13
36
0 0

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