TUHS

tuhs@tuhs.org

34 participants
6418 discussions

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."

6 years, 12 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

6 years, 12 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

6 years, 12 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

6 years, 12 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

6 years, 12 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

6 years, 12 months

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

6 years, 12 months

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

6 years, 12 months

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

6 years, 12 months

Re: [TUHS] Kernel Sizes

by Doug McIlroy

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

6 years, 12 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS