TUHS

tuhs@tuhs.org

4 participants
6478 discussions

Re: [TUHS] Help Contacting Unix Legal People

by Jason Stevens

I tried sending a letter a while back asking how much is a commercial SYSV license anyways, never got a reply. I called their legal and they didn't know what a Unix was. I guess shockingly all the public facing micro focus is all on cobol -----Original Message----- From: Warren Toomey To: tuhs(a)tuhs.org Sent: 6/10/21 8:32 AM Subject: [TUHS] Help Contacting Unix Legal People All, we need help contacting some people so that Dan Doernberg can make progress on a new Unix book that he's working on. I've attached his request to the TUHS list below. If you can help out in any way, please contact Dan directly. Cheers, Warren From: Peer-to-Peer Communications LLC <dan(a)peerllc.com> Hello all, I’m the publisher of Lions' Commentary on UNIX (still going strong after 25 years!) and I have an “Ancient UNIX” book project in mind that I need some community help with. To avoid running into any “who has copyright rights to UNIX” legal problems, we’re trying to reach out in advance to any companies/organizations that may have such rights (Micro Focus, Xinuos, Nokia, are there others?) in advance. To that end, I’m trying to find staffers there who are: 1. sympathetic to sharing information about “ancient UNIX” with the operating system/UNIX communities 2. somewhat familiar with the past legal issues and controversies over UNIX ownership (perhaps someone in the legal department) If you know any such person(s) at Micro Focus, Xinuos, Nokia, and/or other relevant organizations that has either quality (or ideally a unicorn with both!), please pass on their name and email address to me (even better, add any context about why they might be helpful to me, if it’s OK to say that you referred me to them, etc.]. Thanks much, all referrals greatly appreciated! Dan Doernberg dan(a)peerllc.com

3 years, 10 months

System IV

by Warner Losh

So I've seen a number of places that talk about Unix TS 3.0 -> 4.0 -> 5.0 progression and how System III was released and System V was released and System IV was internal only. What I've not seen is the "why" part of this. Why was it internal only? Warner

3 years, 10 months

Help Contacting Unix Legal People

by Warren Toomey

All, we need help contacting some people so that Dan Doernberg can make progress on a new Unix book that he's working on. I've attached his request to the TUHS list below. If you can help out in any way, please contact Dan directly. Cheers, Warren From: Peer-to-Peer Communications LLC <dan(a)peerllc.com> Hello all, I’m the publisher of Lions' Commentary on UNIX (still going strong after 25 years!) and I have an “Ancient UNIX” book project in mind that I need some community help with. To avoid running into any “who has copyright rights to UNIX” legal problems, we’re trying to reach out in advance to any companies/organizations that may have such rights (Micro Focus, Xinuos, Nokia, are there others?) in advance. To that end, I’m trying to find staffers there who are: 1. sympathetic to sharing information about “ancient UNIX” with the operating system/UNIX communities 2. somewhat familiar with the past legal issues and controversies over UNIX ownership (perhaps someone in the legal department) If you know any such person(s) at Micro Focus, Xinuos, Nokia, and/or other relevant organizations that has either quality (or ideally a unicorn with both!), please pass on their name and email address to me (even better, add any context about why they might be helpful to me, if it’s OK to say that you referred me to them, etc.]. Thanks much, all referrals greatly appreciated! Dan Doernberg dan(a)peerllc.com

3 years, 10 months

32V memory management: not quite V7 style swapping -- source code update

by Paul Ruizendaal

I just noticed that the 32V tape on the TUHS Unix Tree page includes a directory “slowsys”: https://www.tuhs.org/cgi-bin/utree.pl?file=32V/usr/src/slowsys This “slowsys” directory appears to contain the 32V kernel with a pure swapping architecture. It is not quite the kernel described in the well known 32V paper, as it seems to have advanced from a fixed 192KB image size mapping to a more variable mapping of up to 1MB — but otherwise the code appears to be as described in the July 1978 paper. The directory https://www.tuhs.org/cgi-bin/utree.pl?file=32V/usr/src/sys contains the scatter loading, partial swapping version of the 32V kernel. Paul

3 years, 10 months

Looking for a 1987 paper - origins of “phishing”

by Arrigo Triulzi

Dear TUHS, would anyone happen to have a copy of: Felix, Jerry & Hauck, Chris (September 1987). "System Security: A Hacker's Perspective". 1987 Interex Proceedings. I can only find references to it on the web but no link to an electronic version. Cheers, Arrigo

3 years, 10 months

32V memory management: not quite V7 style swapping

by Paul Ruizendaal

Received wisdom is that 32V used V7 style swapping for memory management. Over the past days I’ve come to the conclusion that this is a very partial truth and only holds true for 32V as it existed in the first half of 1978. In the second half of ’78 it implemented something that is referred to as “scatter loading” which is an interesting halfway house on the road to demand paging. It was also used in the VAX version of Sys III (and presumably in SysV R1 and early R2). In the 32V report from July 1978 it says: "Like the UNIX system for the PDP-11, the current implementation for the VAX-11/780 maintains each process in contiguous physical memory and swaps processes to disk when there is not enough physical memory to contain them all. Reducing external memory fragmentation to zero by utilizing the VAX- 11/780 memory mapping hardware for scatter loading is high on the list of things to do in the second implementation pass. To simplify kernel memory allocation, the size of the user-segment memory map is an assembly parameter which currently allows three pages of page table or 192K bytes total for text, data, and stack.” (https://www.bell-labs.com/usr/dmr/www/otherports/32v.pdf) It turns out that scatter loading was added in the next months, and it was this version that was used as the basis for 3BSD and SysIII. Babaoglu & Joy write: "Except for the machine-dependent sections of code, UNIX for the VAX was quite similar to that for the PDP-11 which has a 16-bit address space and no paging hardware. It made no use of the memory-management hardware available on the VAX aside from simulating the PDP-11 segment registers with VAX page table entries. The main-memory management schemes employed by this first version of the system were identical to their PDP-11 counterparts -- processes were allocated contiguous blocks of real memory on a first-fit basis and were swapped in their entirety. A subsequent version of the system was capable of loading processes into noncontiguous real memory locations, called scatter loading, and was able to swap only portions of a process, called partial swapping, as deemed necessary by the memory contention. This would become the basis for the paging system development discussed in this paper.” (https://www.researchgate.net/publication/247924813_Converting_a_swap-based_…) The 32V code on the TUHS website (e.g. here https://www.tuhs.org/cgi-bin/utree.pl?file=32V) is actually this later scatter loading code, and not the early 1978 code that used V7 style memory management. The 32-bit Sys III code is closely related (see https://www.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/uts/vax) === My current understanding of how scatter loading worked (based on a brief code review) is as follows: (Note that on the VAX pages/frames are 512 bytes and the page list is essentially single level; page lists grow quickly. It is also unusual in the sense that user page table entries point to kernel virtual memory, but kernel page table entries point to physical memory). - Each process keeps a list of pages in its u-area (a page table prototype, if you will). This list is fixed size and allows up to 512KB per process in 32V and ~2.5MB per process in Sys III (i.e up to 1024 resp. 5120 pages). - The kernel keeps a bitmap of free/used frames in physical memory. - When a process loads/grows, the bitmap is scanned for free frames, these are marked as in-use, and added to the u-area list. If there are not enough free pages a process is selected for swapping out. Swapping out is gradual, in 8KB chunks in 32V and 32KB chunks in SysIII. When a process shrinks or completes, its pages are added back to the bitmap. - When a partially swapped out process needs to run, the swapped out part is loaded back similar to the above. Partial swap-outs truncate the process, so everything above the remaining size needs to re-load. - The user process page table is not swapped, but recreated from the u-area data instead. - When switching between user processes, the kernel needs to update 16 (32V) or 40 (SysIII) kernel page table entries to update the user memory map. Scatter loading and partial swapping seem to be a major improvement over V7 style swapping, although it of course falls short of demand paging. So far I have not seen bits of code that suggest ‘lazy loading’ or copy-on-write functionality in 32V or Sys III, but these things would not seem impossible to do in this memory management scheme. In short, the view that “32V used V7 style swapping” seems to be an oversimplification.

3 years, 11 months

Early Unix paging

by Paul Ruizendaal

Following the recent discussion on this list about early paging systems and John Reiser’s work in this area, I succeeded in reaching out to him. It is all very long ago, but John’s recollection is that his paging system work was initially done late in 1979 or maybe 1980. This matches with Rob Pike’s memory of seeing it demoed in early 1981. John’s recollection confirms that his design implemented mmap and copy-on-write, and was integrated with the file buffer cache (all features that Norman Wilson also remembered). I have appended John’s message below (with permission). I am not sure I understand - at this time - how John’s code was multiplexing page table entries with kernel data structures beyond what is mentioned, but I think it might be an interesting summer project to see how much of the design can be resurrected using related code, old documents and memories. Paul ==== > I joined Bell Labs department 1135 ("Interactive Computer Systems Research") > at Holmdel, NJ in Feb.1977. I soon gained fame by re-writing the C pre-processor, > which was bug-infested and slow. (" 1.e4 " was recognized as an opportunity > to expand the macro "e4", instead of as a floating-point constant.) > cpp used to take 15% to 18% of total CPU compile time. My replacement code > was 2% to 3%. The average improvement was a factor of 7; the minimum: > a factor of 5; the best: a factor of 11 or 12. > During the rest of 1977, I became dissatisfied with our PDP-11/45 (and other's > PDP-11/70), having spent a few student years at Stanford Univ and its AI Lab, > where PDP-6 and PDP-10 reigned. So Tom London and I wrote an "internal grant" > for $250,000 to get a new machine, with a "research goal" of exploring CCD > (charge coupled device) which was promised to replace spinning harddrive. > Actual CCD product never appeared until flash memory devices in 1990s > and SSD (current solid state drive) later. > > Our VAX-11/780, the first one delivered to a customer, arrived Feb.12, 1978 > (Lincoln's Birthday). Tom and I had been preparing using PDP-11/45 since > December, and we achieved "login: " on the console DECwriter by April 15 > (the deadline for US income tax filing). The rest of 1978 was "tuning", > and preparing for the release of "UNIX-32/V" to UC Berkeley. My annual > performance review in early 1979 said "Well done; but don't ever do it again" > because it was not regarded as "Research". > So what did I do? I did it again; this time, with demand paging. > I designed and implemented mmap() based on experience with PDP-10/Tenex > PMAP page mapping system call. I fretted over introducing the first > UNIX system call with 6 arguments. > > The internal design of the paging mechanism "broke the rules" by having a > non-hierarchical dependency: A1 calls B1 calls A2 calls B2 where {A1, A2} > are parts of one subsystem, and {B1, B2} are parts of another subsystem. > (One subsystem was the buffer cache; I forget what was the other subsystem.) > Our machine started with 512KB of RAM, but within a few months was upgraded > to 4 MB with boards that used a new generation of RAM chips. > The hardware page size was 512 bytes, which is quite small. Strict LRU > on 8,192 pages, plus Copy-On-Write, made the second reference to a page > "blindingly fast". It was impressive, running sometime in 1979 or 1980, > I think. But it was not "Research", so I got many fewer accolades. > My internal design strategy was to use the hardware page table entry > (4 bytes per page, with "page not present" being one bit which freed > the other 31 bits for use by software) as the anchor to track everything > about a page. This resulted in a complicated union of bitfield structs, > which became a headache. When other departments took over the work, > the first thing they did was use 8 bytes per page, which meant shuffling > between the software and the hardware descriptors: its own mess. > I wasn't interested in maintaining a paging system, so I moved on > to other things such as design of integrated circuits using > Carver-Mead methodology.

3 years, 11 months

H.J. Lu Bootable Root & Base System disks

by Grant Taylor

Is it okay for me to ask a question about Linux that's from '91~'92? Does anyone happen to have copies of H.J. Lu's Bootable Root and the associated Linux Base System disk images from the early '90s? I've managed to find a copy of 0.98.pl5-31 bootable root disk. But I can't find any base disks to go along with it. The files used to be on tsx-11.mit.edu:/pub/linux/GCC in rootdisk and basedisk subdirectories. Unfortunately all of the mirrors I'm finding of tsx-11 are newer, have the basedisk directories, but no image files there in. -- Grant. . . . unix || die

3 years, 11 months

Some mysteries solved and other musty history

by Jon Steinhart

More mildewy items from my dödsstäda project. Finally found my March 1974 BTL directory. A while ago I was trying to figure out who the people with the initials EPR, LIS, and MAS were in the 516-TSS documents. Best guesses via vgrep on an ancient single-processor are that EPR is Peter E. Rosenfeld, supervisor of Computer Graphics Design Group, LIS is Loretta I. Stukas in Programming Aids Software And Techniques Group. No reasonable looking matches on MAS. Nothing else spectacular in this box - it does have my Lyons books and a whole bunch or original UNIX docs such as the C manual, introduction to ed, and so on which I think are all sufficiently preserved that I don't need to scan them in. Jon

3 years, 11 months

Status of Net/2

by Warner Losh

What's the current status of net/2? I ask because I have a FreeBSD 1.1.5.1 CVS repo that I'd like to make available. Some of the files in it are encumbered, though, and the University of California has communicated that fact. But what does that actually mean now that V7 has been released and that's what the files were based on? Are they no longer encumbered? Warner

3 years, 11 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