Sounds very "Deus ex machina" like. Although it's hard to staple a ghost
to your notebook.
-----Original Message-----
From: Bakul Shah
To: Rob Pike
Cc: The Eunuchs Hysterical Society
Sent: 6/16/21 12:13 PM
Subject: Re: [TUHS] 70th anniversary of (official) programming errors
https://spectrum.ieee.org/the-institute/ieee-history/did-you-know-edison
-coined-the-term-bug
<https://spectrum.ieee.org/the-institute/ieee-history/did-you-know-ediso
n-coined-the-term-bug>
Like Edison, she (Grace Hopper) was recalling the word’s older origins
in the Welsh bwg, the Scottish bogill or bogle, the German bögge, and
the Middle English bugge: the hobgoblins of pre-modern life, resurrected
in the 19th century as, to paraphrase philosopher Gilbert Ryle, ghosts
in the machine.
Electrical circuits can have "bad connections" so I do wonder if Edison
coined this word based on "ghost like" faults that magically appear and
disappear!
-- Bakul
On Jun 15, 2021, at 8:48 PM, Rob Pike <robpike(a)gmail.com> wrote:
There are citations from Edison in the 19th century using the word, and
a quote somewhere by Maurice Wilkes about the stairwell moment when he
realized much of the rest of his life would be spent finding programming
errors.
That moth was not the first bug, nor the first "bug", it was the first
recorded "actual bug".
-rob
On Wed, Jun 16, 2021 at 9:46 AM Dan Cross < crossd(a)gmail.com
<mailto:crossd@gmail.com> > wrote:
On Tue, Jun 15, 2021 at 6:55 PM John Cowan < cowan(a)ccil.org
<mailto:cowan@ccil.org> > wrote:
On Tue, Jun 15, 2021 at 6:25 PM Steffen Nurpmeso < steffen(a)sdaoden.eu
<mailto:steffen@sdaoden.eu> > wrote:
As not being hard-to-the-core i may have missed it, but also in
1951, in March, the wonderful Grace Hopper "conceives the first
compiler, called A-O and later released as Math-Matic. Hopper is
also credited with coining the term 'bug' following an incident
involving a moth and a Mark II.
Yes, but wrongly. The label next to the moth is "First actual case of
bug being found", and the word "actual" shows that the slang term
already existed then. Brief unexplained faults on telephony (and before
that telegraphy) lines were "bugs on the line" back in the 19C.
Vibroplex telegraph keys, first sold in 1905, had a picture of a beetle
on the top of the key, and were notorious for creating bugs when
inexperienced operators used them. (Vibroplex is still in business,
still selling its continuous-operation telegraph keys, which ditt as
long as you hold the paddle to the right.)
Indeed, the Vibroplex key is called a "bug". I suspect this has
something to do with its appearance more than anything else, though (it
kinda sorta looks like, er, a bug).
- Dan C.
I understand the preference for a bottom-up entry, with somebody already sympathetic.
If there is no such entry point, top-down may work at Microfocus. I guess the ask is for a statement for SysV similar to the Nokia statement for 8th-10th Edition:
https://media-bell-labs-com.s3.amazonaws.com/pages/20170327_1602/statement%…
According to Companies’ House, the general counsel is Jane Smithard:
https://find-and-update.company-information.service.gov.uk/company/01504593…
She appears to be 67, to have a long tenure with Microfocus and maybe is just the right person:
"Jane has more than 25 years’ experience as a lawyer in the IT industry and software sector. She has worked with Micro Focus for over 20 years providing a wide range of commercial and corporate legal services, from leading the efforts through the 2005 IPO to driving the legal aspects of the group’s mergers, acquisitions and divestitures strategy including the acquisition of HPE Software and divestiture of SUSE. Jane leads a team of approximately 60 lawyers and other professionals worldwide, the majority of whom are focused directly on supporting the Company’s commercial teams and business.”
https://www.microfocus.com/en-us/about/leadership-about
Her e-mail appears to be jane (dot) smithard (at) microfocus (dot) com
But I guess that Dan Doernberg already knows all that. His book project sounds intriguing, by the way.
Paul
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
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
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
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
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
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.