TUHS

tuhs@tuhs.org

29 participants
6557 discussions

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, 6 months

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, 6 months

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, 6 months

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, 6 months

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, 6 months

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, 6 months

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, 6 months

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, 6 months

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, 6 months

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, 6 months

Happy birthday, Ken Thompson!

by Norman Wilson

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

7 years, 6 months

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, 6 months

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, 6 months

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, 6 months

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, 6 months

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, 6 months

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, 6 months

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, 6 months

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, 6 months

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, 7 months

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, 7 months

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, 7 months

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, 7 months

!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, 7 months

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, 7 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS