From tuhs at tuhs.org Mon Jan 1 03:30:44 2024 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Sun, 31 Dec 2023 11:30:44 -0600 Subject: [TUHS] Question about BSD disklabel history Message-ID: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> Hi, I've found myself wondering about partitions inside of BSD disk labels. Specifically, when and where was the convention that "a" is root, "b" is swap, etc? I also understand the "c" partition to be the entire disk, unless it isn't, at which point it's the entire slice (BIOS / MBR partition) containing the BSD disklabel and "d" is the entire disk. I also found something last night that indicated that OpenBSD uses disk labels somewhat differently than FreeBSD. Aside: This is one of the dangers of wondering how something curious came to be and why it came to be when working on 10-15 year old FreeBSD systems. -- Grant. . . . -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4033 bytes Desc: S/MIME Cryptographic Signature URL: From arnold at skeeve.com Mon Jan 1 03:38:55 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 31 Dec 2023 10:38:55 -0700 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> Message-ID: <202312311738.3BVHctA1018336@freefriends.org> The different overlapping partitions predates disk labels. Up to and including 4.3 BSD, to change the size of partitions on a particular disk, you had to recompile the kernel. They were that way so that if you had multiple disks, you could use one for root + swap + some thing small and use another whole disk for a single filesystem. It was also helpful, if you had the drives, to nightly dd your real root to the "a" partition on another, identical drive, so that you could boot the backup root in an emergency. I don't remember for sure, but I think that Ultrix may have been the first BSD-style system to have disk labels, followed by some version of SunOS. All of that is way in the distant past though: mid- to late 80's. I am guessing that the original conventions date back to V7 or 32V, but one would have to go looking at code to be sure. HTH, Arnold Grant Taylor via TUHS wrote: > Hi, > > I've found myself wondering about partitions inside of BSD disk labels. > > Specifically, when and where was the convention that "a" is root, "b" is > swap, etc? > > I also understand the "c" partition to be the entire disk, unless it > isn't, at which point it's the entire slice (BIOS / MBR partition) > containing the BSD disklabel and "d" is the entire disk. > > I also found something last night that indicated that OpenBSD uses disk > labels somewhat differently than FreeBSD. > > Aside: This is one of the dangers of wondering how something curious > came to be and why it came to be when working on 10-15 year old FreeBSD > systems. > > > > -- > Grant. . . . From imp at bsdimp.com Mon Jan 1 06:07:41 2024 From: imp at bsdimp.com (Warner Losh) Date: Sun, 31 Dec 2023 13:07:41 -0700 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: <202312311738.3BVHctA1018336@freefriends.org> References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> <202312311738.3BVHctA1018336@freefriends.org> Message-ID: On Sun, Dec 31, 2023 at 10:39 AM wrote: > The different overlapping partitions predates disk labels. > Up to and including 4.3 BSD, to change the size of partitions > on a particular disk, you had to recompile the kernel. > Yes. Disk partitions were implemented in the disk driver dating back at least to the 5th edition. Lack of sources makes it harder to know for sure. The man pages for each of the disk drivers included the partition layout (IIRC, I didn't cross verify). > They were that way so that if you had multiple disks, you > could use one for root + swap + some thing small and use another > whole disk for a single filesystem. > Yes. Unlike today, the partitions covered the disk in different, overlapping ways. And allowed for some parts of the disk to be uncovered by a partition. You could then patch the offset and length into the kernel with adb and use that area of the disk for swap space. > It was also helpful, if you had the drives, to nightly dd > your real root to the "a" partition on another, identical > drive, so that you could boot the backup root in an emergency. > > I don't remember for sure, but I think that Ultrix may have > been the first BSD-style system to have disk labels, followed > by some version of SunOS. All of that is way in the distant > past though: mid- to late 80's. > When I looked into it years ago, I convinced myself that SunOS was the first to have it (since the very first version of SunOS 1.0 had disk labels) and that all the other vendors followed suit within a couple of years. Ultrix-11 had the fixed labels through its EOL. I didn't see any disklable stuff in the Ultrix-32M that we have, but it was admittedly a quick look. > I am guessing that the original conventions date back to > V7 or 32V, but one would have to go looking at code to be sure. > Yes. The conventions are as old as Unix. And did change at least between V5 and V6 and I think maybe again for some drivers between V6 and V7 (though I'm less sure of this). BSD4.3 Tahoe, the first release after BSD4.3, fixed the disklabel format. Sun's vtoc format (aka sunlabel) was different from that, but quite similar. This is why it's called 4.3BSD format in many places, even though it wasn't in the original 4.3BSD release. OpenBSD and FreeBSD's disklabels are the same format. However, OpenBSD's have twice as many entries than FreeBSD's. And there's a number of other fussy details about what different labels mean based on the shared history and divergent evolution of the two systems. OpenBSD also supports both endians, while FreeBSD only supports native endian. So these changes and different decisions lead to the situation today where it's hard to read them on each-other's systems. Plus with the new, larger disks FreeBSD has effectively abandoned them in lue of GPT partitioning. There is a disklabel64 format too, but I'm unsure how widely that's deployed. All the commercial Unixes also had their own format. AIX, HPUX, DG, etc. That's a topic for another time... Warner > Grant Taylor via TUHS wrote: > > > Hi, > > > > I've found myself wondering about partitions inside of BSD disk labels. > > > > Specifically, when and where was the convention that "a" is root, "b" is > > swap, etc? > > > > I also understand the "c" partition to be the entire disk, unless it > > isn't, at which point it's the entire slice (BIOS / MBR partition) > > containing the BSD disklabel and "d" is the entire disk. > > > > I also found something last night that indicated that OpenBSD uses disk > > labels somewhat differently than FreeBSD. > > > > Aside: This is one of the dangers of wondering how something curious > > came to be and why it came to be when working on 10-15 year old FreeBSD > > systems. > > > > > > > > -- > > Grant. . . . > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at ultimate.com Mon Jan 1 06:27:20 2024 From: phil at ultimate.com (Phil Budne) Date: Sun, 31 Dec 2023 15:27:20 -0500 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: <202312311738.3BVHctA1018336@freefriends.org> References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> <202312311738.3BVHctA1018336@freefriends.org> Message-ID: <202312312027.3BVKRK5d049733@ultimate.com> arnold at skeeve.com wrote: > I am guessing that the original conventions date back to > V7 or 32V, but one would have to go looking at code to be sure. Looking at the hp (RP-04/5/6) man page in V7, 32/v, and 3bsd the convention was rpN, where 0 <= N <= 7 were partitions on the first drive, and rp8 was the first partition on the second drive. rp0 was root, rp1 was swap, rp2 and rp3 (in the v7 man page) are unassigned. The rpNx convention, where N is the drive number, with "c" as the whole disk is present in the 4.1BSD hp(4) man page. From imp at bsdimp.com Mon Jan 1 07:02:00 2024 From: imp at bsdimp.com (Warner Losh) Date: Sun, 31 Dec 2023 14:02:00 -0700 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: <202312312027.3BVKRK5d049733@ultimate.com> References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> <202312311738.3BVHctA1018336@freefriends.org> <202312312027.3BVKRK5d049733@ultimate.com> Message-ID: On Sun, Dec 31, 2023 at 1:27 PM Phil Budne wrote: > arnold at skeeve.com wrote: > > I am guessing that the original conventions date back to > > V7 or 32V, but one would have to go looking at code to be sure. > > Looking at the hp (RP-04/5/6) man page in V7, 32/v, and 3bsd the > convention was rpN, where 0 <= N <= 7 were partitions on the first > drive, and rp8 was the first partition on the second drive. rp0 was > root, rp1 was swap, rp2 and rp3 (in the v7 man page) are unassigned. > > The rpNx convention, where N is the drive number, with "c" as the > whole disk is present in the 4.1BSD hp(4) man page. > This was just a change to MAKEDEV. The kernel used the same minor number encoding. 4BSD still used the V7 make script in /dev, but at some point before 4.1cBSD (I don't have the 4.1BSD exploded locally) it changed, both in name from MAKE to MAKEDEV and to start the [a-h] suffix for partitions. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Mon Jan 1 07:31:00 2024 From: clemc at ccc.com (Clem Cole) Date: Sun, 31 Dec 2023 16:31:00 -0500 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> Message-ID: Below... apologies if I forgot something -- this is pretty much as I knew it/play it out. On Sun, Dec 31, 2023 at 12:31 PM Grant Taylor via TUHS wrote: > Hi, > > I've found myself wondering about partitions inside of BSD disk labels. > > Specifically, when and where was the convention that "a" is root, "b" is > swap, etc? > > I also understand the "c" partition to be the entire disk, unless it > isn't, at which point it's the entire slice (BIOS / MBR partition) > containing the BSD disklabel and "d" is the entire disk. > > I also found something last night that indicated that OpenBSD uses disk > labels somewhat differently than FreeBSD. > > Aside: This is one of the dangers of wondering how something curious > came to be and why it came to be when working on 10-15 year old FreeBSD > systems. > > A long, strange trip as were. Step one was the introduction of DEC RP04 disks -- 19 Heads, 21 Sectors/Track, 411 cylinders or 163989 blocks which will overflow a 16-bit PDP-11 register. You find it in the V5 code, but I have Dennis's rp.c driver showing split the RP04 into from v6: struct { char *nblocks; int cyloff; } rp_sizes[] { 40600, 0, /* cyl 0 thru 202 */ 40600, 203, /* cyl 203 thru 405 */ 9200, 0, /* cyl 0 thru 45 */ 9200, 360, /* cyl 360 thru 405 */ -1, 0, /* cyl 0 thru 327 */ -1, 78, /* cyl 78 thru 405 */ 15600, 0, /* cyl 0 thru 77 */ 15600, 328, /* cyl 328 thru 405 */ }; (V5/V6 C does not have an unsigned or longs; char * is how the compiler created a type that was treated as an unsigned 16-bit integer). If you look at things like the rk05 in V6, we reserve a few blocks at the end of the disk for swap. Remember quotas and file single file management are not there yet, so the scheme with the RP04 starts to be the way of the world. Also, remember Ted has not introduced what would later be called fsck(1), so recovery from a crash was painful. The corruption was often on the root disk, a quick dd(1) of the root FS you were quickly back - or at least bookable and then you could use check, ncheck, *et al *on the other partitions. Also, with PWB - a new set of tools was created for disk management that Research did not pick up: volcopy, cpio, et al. The V6 version of PWB is where *disklabels are first added to the superblock* BTW. In fact, when we did the original fsck(8) at CMU, we had v5 then v6. No, PWB pollution into our IP stream. So the original fsck I recently recovered for V6 does not have the disklabel code in it. When Ted goes to USG later, he adds the label support (which is why if you compile the version in the V7 addenda, it will get errors -- that one is the version on UNIX/TS - which the kernel supported disklabels). I had to look at the code, I think labels are simple, just names not information about that specific FS. The labels are not per disk pack. Meanwhile back in Murray Hill .... With V7, we have long int, but the partition scheme is already in use and has some nice side effects, so it is now a feature, and with the RP06 -- so Dennis's new scheme: struct size { daddr_t nblocks; int cyloff; } hp_sizes[8] = { 9614, 0, /* cyl 0 thru 22 */ 8778, 23, /* cyl 23 thru 43 */ 0, 0, 0, 0, 161348, 44, /* cyl 44 thru 429 */ 160930, 430, /* cyl 430 thru 814 */ 153406, 44, /* cyl 44 thru 410 (rp04, rp05) */ 322278, 44, /* cyl 44 thru 814 (rp06) */ }; At this point, as Arnold said, people would change the size/shape of the tables locally by recompiling and setting up the disk they way you wanted. It could be awkward, you typically needed a second disk pack, *etc*. With DEC's release of V7m, 2.x (2.1, I think), Fred Cantor of DEC put the first versions of labels into what would later become Ultrix-11. That code was released to CRSG (it is also where 2.9 et al. get Fred's wonderful swapping support). Shannon (still at DEC) helped Sam add some of that into a 4.1a/b/c stream... This was where Sam added things like newfs(8) and /etc/disktab and started to try to make BSD more resilient to different types of disks. But my memory is that it was nascent in the 4.2 release, so you had /etc/disktab and some of the tools but not everything until later, 4.3, when what you know today came into being. Meanwhile, in Pittsburgh ... CMU is working on the Mach2.5 project. Intel had donated some of the original 386 PC support to Rasid's group (they were partial funding) that they had developed with ISC/AT&T *et al* to handle things particular to the PC architecture -- such as the PC's fdisk(1) since PC's have a completely different way of partitioning things. Bob Baron did the Mach version - as to what was new and what was from Intel I'm not 100% sure. But CMU did have the tools that Intel felt they owned and were not part of System III/V. The key is that a PC's fdisk(1) - creates a UNIX partition within the DOS partition table so DOS knows to leave it alone, but then Unix sub-partitions using its own scheme. My memory here is hazy, I think the sub-partition code Bob used is different from the ATT's 386 [which most people saw as ISC's 386/ix who did the original work under contract for AT&T] Meanwhile, across the pond ... Andy's team starts to want a V7 for the PC/XT and starts the Minux project. I know they had CMU's Mach 2.5 stuff and there fdisk, while it seems to be independent (i.e. clean room) is very similar to Bob Baron's scheme. Meanwhile, in Walnut Creek ... Jolitiz *et al.* started 386BSD, which would begat FreeBSD/NetBSD/OpenBSD. At some point, Baron's fdisk (1) and support tools make their way to that project. This was why all the original UNIX for a PC used the same PC fdisk "type" ID number (the ISC 386/ix type -- from the original 386 port). [Linus built his own tools, which I think started from the Minux tools, and thus he did his own thing --- so Linux disks were not marked with the same types). If you look at the sources to both Mach and early 386BSD, you'll see Intel markings as well as Bob's name in a couple of places [Truth in advertising here (different story) -- I wrote most of the original AT disk driver Bill used -- I was consulting for NCR and had access to the WD specs as well as the CMU code but I was not the conduit of the CMU code base to Bill]. At some point, 386BSD started to go one way, and what would become FreeBSD started to ramp up. Jordan Hubbard wants an "easy install" like Microsoft has for Win98, so very early FreeBSD has the first PC-based install that can run without much intervention. At some point, Jordon or someone else in the FreeBSD team introduced what they called slices, furthering the BSD scheme but designed to overlay the PC better. The NetBSD folks had already split off, so they did not pick it up. When OpenBSD split from NetBSD, they did something similar but different to FreeBSD's slices... Meanwhile, in Cupertino .... Next (ney Apple) started with the Mach code base from CMU. There was a push in the Valley in those days for something called OpenFirmware [Warner help here -- I think that it was forth based IIRC, and Sun may have had their hand in it also]. But the key is that it ran on 68K's. So Next's original partition scheme was influenced if not based on some of Bob's work, although they did not need the silly BIOS stuff, so they did make it all talk to OpenFW (BTW: I think that was still all Next) By the time the Intel Mac's BIOS had begun to be replaced in the WINTEL world by UEFI, Apple committed to using a flavor of it. My old lab partner, Guy Sotomayer (*a.k.a.* gss on many mailing lists) was mixed up during his time at Apple. He might be able to fill in some details if I ask him. I also know that Apple was not happy with how disks were handled with the original partition scheme, and by later release started over with their partitioning scheme(s) at least once. I've undoubtedly left stuff out, such as much of Linux - but this is all part of the UNIX war I was a player. -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman at oclsc.org Mon Jan 1 07:55:03 2024 From: norman at oclsc.org (Norman Wilson) Date: Sun, 31 Dec 2023 16:55:03 -0500 (EST) Subject: [TUHS] Question about BSD disklabel history Message-ID: Disk sections (I don't think anyone in Research called them partitions--certainly the Research manuals didn't) were originally defined in the device driver, not by data on the disk. In those days, system management included recompiling stuff, including the OS kernel, and it was not unusual for sites to edit hp.c or whatnot to adjust things to local preference. There was nothing magic about the mapping between device names and minor device numbers either; the system came with certain conventions on the original tape, but it was not at all uncommon to change them. By the time I arrived at the first Unix site I ever helped run, in a physics group at Caltech, we already used a different naming convention: a BSD-like ddNs, where dd was a driver name, N the physical drive unit number, s a section letter. I don't know whether that was borrowed from BSD (it must have started during the 3BSD era, since I started there in mid-1980 and 4BSD appears to have been released late in that year). Looking at my archival copy of that much-locally-hacked source tree, I see that we later moved the definitions of all the disk-section tables to a single file compiled at system-configuration time (we used a USG-like scheme that compiled most of the system into libraries, rather than compiling every file separately for each target system a la V7 and BSD). That simplified handling our somewhat- complicated disk topology: all but system disks were connected through System Industries 9400 disk controllers, which were a neat design (each controller could interface to as many as four hosts and four disks) but in practice were not always reliable. On one hand, we arranged for one disk to be used in parts by our main time-sharing VAX and a subsidiary PDP-11/45, making the 11/45 cheaper to keep around; on the other, the main VAX had two paths to each of its disks, through different SI controllers, so when an SI controller conked out we could run without it until the service guys fixed it. (Each disk was dual-ported, as was common in the SMD world, hence connected to two controllers.) Reliability took rather more work in those days. A different data point: by the time I moved from California to New Jersey and joined 1127, Research was also using a different naming scheme for disk sections. By then the internal naming convention was e.g. ra17 for physical unit 1, section 7; by further convention 7 (the highest-numbered section). At some point a little later we added an ioctl to set the starting block and size of a particular section on a particular drive, but we never went to having the OS itself try to find a label and trust its contents (something that still makes the 1980s part of me feel a little creepy, though 21st century me has come to terms with it). Norman Wilson Certified old fart Toronto ON From imp at bsdimp.com Mon Jan 1 08:07:45 2024 From: imp at bsdimp.com (Warner Losh) Date: Sun, 31 Dec 2023 15:07:45 -0700 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> Message-ID: On Sun, Dec 31, 2023 at 2:31 PM Clem Cole wrote: > Below... apologies if I forgot something -- this is pretty much as I knew > it/play it out. > > On Sun, Dec 31, 2023 at 12:31 PM Grant Taylor via TUHS > wrote: > >> Hi, >> >> I've found myself wondering about partitions inside of BSD disk labels. >> >> Specifically, when and where was the convention that "a" is root, "b" is >> swap, etc? >> >> I also understand the "c" partition to be the entire disk, unless it >> isn't, at which point it's the entire slice (BIOS / MBR partition) >> containing the BSD disklabel and "d" is the entire disk. >> >> I also found something last night that indicated that OpenBSD uses disk >> labels somewhat differently than FreeBSD. >> >> Aside: This is one of the dangers of wondering how something curious >> came to be and why it came to be when working on 10-15 year old FreeBSD >> systems. >> >> A long, strange trip as were. > > Step one was the introduction of DEC RP04 disks -- 19 Heads, 21 > Sectors/Track, 411 cylinders or 163989 blocks which will overflow a 16-bit > PDP-11 register. You find it in the V5 code, but I have Dennis's rp.c > driver showing split the RP04 into from v6: > > struct { > > char *nblocks; > > int cyloff; > > } rp_sizes[] { > > 40600, 0, /* cyl 0 thru 202 */ > 40600, 203, /* cyl 203 thru 405 */ > 9200, 0, /* cyl 0 thru 45 */ > 9200, 360, /* cyl 360 thru 405 */ > -1, 0, /* cyl 0 thru 327 */ > -1, 78, /* cyl 78 thru 405 */ > 15600, 0, /* cyl 0 thru 77 */ > 15600, 328, /* cyl 328 thru 405 */ > > }; > > (V5/V6 C does not have an unsigned or longs; char * is how the compiler > created a type that was treated as an unsigned 16-bit integer). > > If you look at things like the rk05 in V6, we reserve a few blocks at the > end of the disk for swap. Remember quotas and file single file management > are not there yet, so the scheme with the RP04 starts to be the way of the > world. Also, remember Ted has not introduced what would later be called > fsck(1), so recovery from a crash was painful. The corruption was often > on the root disk, a quick dd(1) of the root FS you were quickly back - or > at least bookable and then you could use check, ncheck, *et al *on the > other partitions. > > Also, with PWB - a new set of tools was created for disk management that > Research did not pick up: volcopy, cpio, et al. The V6 version of PWB is > where *disklabels are first added to the superblock* BTW. In fact, > when we did the original fsck(8) at CMU, we had v5 then v6. No, PWB > pollution into our IP stream. So the original fsck I recently recovered > for V6 does not have the disklabel code in it. When Ted goes to USG > later, he adds the label support (which is why if you compile the version > in the V7 addenda, it will get errors -- that one is the version on UNIX/TS > - which the kernel supported disklabels). I had to look at the code, I > think labels are simple, just names not information about that specific > FS. The labels are not per disk pack. > > Meanwhile back in Murray Hill .... > > With V7, we have long int, but the partition scheme is already in use and > has some nice side effects, so it is now a feature, and with the RP06 -- > so Dennis's new scheme: > > struct size > { > > daddr_t nblocks; > int cyloff; > > > } hp_sizes[8] = > > { > 9614, 0, /* cyl 0 thru 22 */ > 8778, 23, /* cyl 23 thru 43 */ > 0, 0, > 0, 0, > 161348, 44, /* cyl 44 thru 429 */ > 160930, 430, /* cyl 430 thru 814 */ > 153406, 44, /* cyl 44 thru 410 (rp04, rp05) */ > 322278, 44, /* cyl 44 thru 814 (rp06) */ > > }; > > At this point, as Arnold said, people would change the size/shape of the > tables locally by recompiling and setting up the disk they way you wanted. > It could be awkward, you typically needed a second disk pack, *etc*. > > With DEC's release of V7m, 2.x (2.1, I think), Fred Cantor of DEC put the > first versions of labels into what would later become Ultrix-11. That > code was released to CRSG (it is also where 2.9 et al. get Fred's wonderful > swapping support). Shannon (still at DEC) helped Sam add some of that > into a 4.1a/b/c stream... This was where Sam added things like newfs(8) > and /etc/disktab and started to try to make BSD more resilient to > different types of disks. But my memory is that it was nascent in the 4.2 > release, so you had /etc/disktab and some of the tools but not everything > until later, 4.3, when what you know today came into being. > Except I can't find any of this in our V7m or ultrix-11 that we have. This is 2.1. And there all the device drivers still have the fixed tables: grep sizes * | grep '\[[0-9]' hk.c:} hk_sizes[8] = hk.c_i:} hk_sizes[8] = hk.c_id:} hk_sizes[8] = hm.c:} hm_sizes[24] = hp.c:} hp_sizes[24] = and the ultrix-11 3.1 sources we have are similar, but move all of the above into /usr/sys/conf/dksizes.c. The early disktab stuff encoded the default tables into a text file to make it easier to cope with all the different types of disks, but didn't affect what we know as bsdlabels until after 4.3BSD. The naming convention was there, but the 'write bits to the disk to describe partitioning' I couldn't find at all in ultrix. I think you may be confusing that stuff (which was a very clever way to cope with all these disks that have different partitioning in a increasingly generic way) with disk labeling which I think. Sun was first to market with. Maybe you can help me find it? I did find the SunOS 0.x images (UniSoft V7 port) didn't appear have a disk partition, but 1.0 (post 4BSD pre 4.1BSD) and later did. That puts it at 1982. Although based off BSD, the disk label stuff wasn't in BSD for another 5 years when the BSD folks started the Tahoe port. It's entirely possible one of the early UniSoft ports had this feature, and that was adapted into SunOS and I've not seen the paper trail (studying the early UniSoft ports is rather problematic for a variety of logistical reasons)... Not least of which is the fragmentary nature of the surviving source, the difficulty in obtaining boot images, etc. This is a very under-documented time. It wouldn't surprise me if someone produced evidence of Sun's partitioning scheme coming from this mess... Or a very similar thing. And Pixar may have been involved (though that's a memory I have that I don't have in my notes documented). Maybe that's the Sam Leffler connection (though I thought his time at Pixar post-dated this period somewhat). Meanwhile, in Pittsburgh ... > > CMU is working on the Mach2.5 project. Intel had donated some of the > original 386 PC support to Rasid's group (they were partial funding) that > they had developed with ISC/AT&T *et al* to handle things particular to > the PC architecture -- such as the PC's fdisk(1) since PC's have a > completely different way of partitioning things. Bob Baron did the Mach > version - as to what was new and what was from Intel I'm not 100% sure. > But CMU did have the tools that Intel felt they owned and were not part of > System III/V. > > The key is that a PC's fdisk(1) - creates a UNIX partition within the DOS > partition table so DOS knows to leave it alone, but then Unix > sub-partitions using its own scheme. My memory here is hazy, I think the > sub-partition code Bob used is different from the ATT's 386 [which most > people saw as ISC's 386/ix who did the original work under contract for > AT&T] > > Meanwhile, across the pond ... > Andy's team starts to want a V7 for the PC/XT and starts the Minux > project. I know they had CMU's Mach 2.5 stuff and there fdisk, while it > seems to be independent (i.e. clean room) is very similar to Bob Baron's > scheme. > Yea, the fdisk stuff came from early versions of PC-DOS to partition hard drives in 2.0 / 1983. I do know the DEC Rainbow had yet another set of partitioning (which the PRO and DecMATE didn't share). It never adopted what today is the MBR partitioning scheme because it's hard disk support pre-dates this. It quickly became standard, and we see evidence of support for it in the Venix/86 sources that we have (both the XT version and the AT version, though I think that was disk controller version, and not MBR data). > Meanwhile, in Walnut Creek ... > > Jolitiz *et al.* started 386BSD, which would begat > FreeBSD/NetBSD/OpenBSD. At some point, Baron's fdisk (1) and support > tools make their way to that project. This was why all the original > UNIX for a PC used the same PC fdisk "type" ID number (the ISC 386/ix type > -- from the original 386 port). [Linus built his own tools, which I think > started from the Minux tools, and thus he did his own thing --- so Linux > disks were not marked with the same types). If you look at the sources to > both Mach and early 386BSD, you'll see Intel markings as well as Bob's name > in a couple of places [Truth in advertising here (different story) -- I > wrote most of the original AT disk driver Bill used -- I was consulting for > NCR and had access to the WD specs as well as the CMU code but I was not > the conduit of the CMU code base to Bill]. > At some point, 386BSD started to go one way, and what would become FreeBSD > started to ramp up. Jordan Hubbard wants an "easy install" like Microsoft > has for Win98, so very early FreeBSD has the first PC-based install that > can run without much intervention. At some point, Jordon or someone else > in the FreeBSD team introduced what they called slices, furthering the BSD > scheme but designed to overlay the PC better. The NetBSD folks had > already split off, so they did not pick it up. When OpenBSD split from > NetBSD, they did something similar but different to FreeBSD's slices... > Yea, this was 1992 or 1993. In FreeBSD 1.x you just had BSD Labels which would default in interesting ways to what the MBR of the disk was (I've not double checked the code, this is my memory). The 'c' partition was the entire BSD partition while the 'd' partition was the entire disk. And that duality lived on for a while. The slice code came in during the 3.x series (or after 2.0, which used the same scheme as 1.x). And it was mostly an attempt to make the BSD labels independent of each other. There was some weird code for bsd-label only disks but most of the visible changes from slices came in device naming (if you had only one disk label, and it was on the first partition it was compatible with old bsd labels by and large). FreeBSD wouldn't have true nested MBR and bsd labels until 5.0 and geom entered the tree... A lot of the 'differences' between the BSDs were in presentation of the data to the user, rather than physical differences on the disk (though such differences did exist, especially in endian). It was a real mess of NIH + incompatible UI + almost-but-not-quite compatible on-disk formats coupled with a bunch of bugs that differed among the BSDs. I do not miss these days. > Meanwhile, in Cupertino .... > > Next (ney Apple) started with the Mach code base from CMU. There was a > push in the Valley in those days for something called OpenFirmware [Warner > help here -- I think that it was forth based IIRC, and Sun may have had > their hand in it also]. But the key is that it ran on 68K's. So Next's > original partition scheme was influenced if not based on some of Bob's > work, although they did not need the silly BIOS stuff, so they did make it > all talk to OpenFW (BTW: I think that was still all Next) > I'm not sure about Next's partitioning scheme. I do know that Apple adopted the OpenFirmware partitioning scheme for PPC Mac leading to the APM scheme which FreeBSD supports to this day for PowerPC. This was different from Sun's sunlabels (which differed from BSD labels since they pre-dated them by half a decade. By the time the Intel Mac's BIOS had begun to be replaced in the WINTEL > world by UEFI, Apple committed to using a flavor of it. My old lab partner, > Guy Sotomayer (*a.k.a.* gss on many mailing lists) was mixed up during > his time at Apple. He might be able to fill in some details if I ask him. > I also know that Apple was not happy with how disks were handled with the > original partition scheme, and by later release started over with their > partitioning scheme(s) at least once. > Yea, GPT partitioning came along a lot later, kinda sort with EFI which Intel and Apple did (intel for ia64, Apple for 32-bit x86 macs). It's one of the few partitioning schemes I rather like. > I've undoubtedly left stuff out, such as much of Linux - but this is all > part of the UNIX war I was a player. > Yea, not to mention the HP, AIX, DG and other partitioning schemes that grew up in the late 80s and early 90s to have parity with MBR disks at the feature level, but rarely at the disk format level. A lot of it is documented, but in hard to find places and I've not done a systematic survey. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.branden.robinson at gmail.com Mon Jan 1 08:46:49 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Sun, 31 Dec 2023 16:46:49 -0600 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> Message-ID: <20231231224649.h45pogxycgkgs673@illithid> At 2023-12-31T16:31:00-0500, Clem Cole wrote: > Next (ney Apple) started with the Mach code base from CMU. There was > a push in the Valley in those days for something called OpenFirmware > [Warner help here -- I think that it was forth based IIRC, and Sun may > have had their hand in it also]. I'm not Warner but I owned and operated a few OpenFirmware based machines. > But the key is that it ran on 68K's. I don't think that's the case. OpenFirmware (OF) ran on SPARC and PowerPC hardware, at least. And since it was indeed Forth-based, in principle it could have been ported practically anywhere (assuming memory requirements for OF itself were met). The m68k "Old World" PowerMacs used a different firmware entirely; I assume boot ROM code descended from the original Macintosh (or even Lisa, maybe). The PowerPC "New World" PowerMacs, which immediately departed from the beige color scheme, did come in with Apple's acquisition of NeXT. This may have been the last good thing that Steve Jobs had a hand in. On Sun SPARC machines you could get to an OF prompt at any time by typing "Stop+A" (a.k.a. "L1+A"), using one of the funny left-hand side function keys on a generation or two (Type 4??) Sun keyboards. This was a lot like the "programmer's switch" on some m68k Macs, which was wired directly to an NMI that MacOS ("Classic") had a fixed vector for. Open Firmware was an excellent idea; true peripheral portability was achieved by having "option ROMs" on devices that needed them implemented in Forth like OF itself. A lot of flexibility here. I don't know how much of a performance price was paid--people did and do enjoy getting into bootup-time races--but even if it were competitive, the PC side of the industry would have stridently claimed it wasn't. A lot of non-x86 Cisco kit in the 2000s (some PowerPC, and _maybe_ some MIPS stuff too(?)) used some kind of cut-down descendant of OF called OpenHackWare. I'm not sure what its dimensions were; it may have mostly been just the conventions and format that we now recognize as "device tree" (DTS/DTB), which has perhaps been OpenFirmware's proudest legacy. It beat the hell out of the PC BIOS alternative for device enumeration, which always appeared to me to be pure binary chaos with no standard apart from whatever Microsoft wanted for Windows. By contrast, OpenFirmware was standardized in IEEE 1275. > By the time the Intel Mac's BIOS had begun to be replaced in the > WINTEL world by UEFI, Apple committed to using a flavor of it. Originally EFI, without the "U". I first saw these on first-generation Itanium machines--huge, hot deskside HP boxes whose innards appeared to use composite foam like that from aircraft wings for heat piping. The company I worked for was contracted to help achieve the Linux ia64 port. I was immediately horrified by EFI's huge step backwards in concept and implementation. All this technical progress just to return to unportable device driver ROMs and a C:\ prompt. The hatred of the Wintel duopoly toward elegance or cleanliness in any aspect of computing cannot be overstated. I'm weakly hopeful that the RISC-V community will rediscover OpenFirmware. It has to date had the good sense to avoid UEFI. A wise choice, as if they they hand Intel that much control over their ecosystem, they will surrender all independence, and possibly the architecture itself, at least in real silicon. Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From lm at mcvoy.com Mon Jan 1 09:06:15 2024 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 31 Dec 2023 15:06:15 -0800 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: <20231231224649.h45pogxycgkgs673@illithid> References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> <20231231224649.h45pogxycgkgs673@illithid> Message-ID: <20231231230615.GE19322@mcvoy.com> On Sun, Dec 31, 2023 at 04:46:49PM -0600, G. Branden Robinson wrote: > At 2023-12-31T16:31:00-0500, Clem Cole wrote: > > Next (ney Apple) started with the Mach code base from CMU. There was > > a push in the Valley in those days for something called OpenFirmware > > [Warner help here -- I think that it was forth based IIRC, and Sun may > > have had their hand in it also]. > > I'm not Warner but I owned and operated a few OpenFirmware based > machines. > > > But the key is that it ran on 68K's. > > I don't think that's the case. OpenFirmware (OF) ran on SPARC and > PowerPC hardware, at least. And since it was indeed Forth-based, in > principle it could have been ported practically anywhere (assuming > memory requirements for OF itself were met). OpenFirmware is Mitch Bradley's baby. I believe it ran on 68k Suns, there was some sort of boot prom there. I mostly used it on SPARC. It was pretty powerful but my personal feeling is the choice of Forth didn't help. Yeah, I get it, Forth is like some weird lisp and the lisp people love lisp. What the lisp people don't get is there are a lot more people who don't love lisp than do love lisp. And trying to get everyone to love lisp isn't gonna happen. That said, what else could Mitch have used at the time? Tcl? Please, another weird lisp. Perl? Not really something that wants to talk to the bare metal. It's a serious question, is there anything that Mitch could have used that would have had wider appeal? And I agree whole heartedly with the EFI crap being a giant step backwards. From phil at ultimate.com Mon Jan 1 09:08:36 2024 From: phil at ultimate.com (Phil Budne) Date: Sun, 31 Dec 2023 18:08:36 -0500 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: <20231231224649.h45pogxycgkgs673@illithid> References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> <20231231224649.h45pogxycgkgs673@illithid> Message-ID: <202312312308.3BVN8aQ5052682@ultimate.com> G. Branden Robinson wrote: > OpenFirmware (OF) ran on SPARC and PowerPC hardware, at least. OF had its origin in Sun OpenBoot PROM (OBP), which, ISTR, first appeared in the SPARCstation 1 (sun4c kernel arch) along with SBus. Earlier (VME) based SPARC (sun4 kernel arch) systems had only a Sun-3 like boot PROM (single letter commands, no Forth). From aek at bitsavers.org Mon Jan 1 09:37:43 2024 From: aek at bitsavers.org (Al Kossow) Date: Sun, 31 Dec 2023 15:37:43 -0800 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: <20231231230615.GE19322@mcvoy.com> References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> <20231231224649.h45pogxycgkgs673@illithid> <20231231230615.GE19322@mcvoy.com> Message-ID: <57c26b28-af60-689b-c315-828d6561d178@bitsavers.org> On 12/31/23 3:06 PM, Larry McVoy wrote: > OpenFirmware is Mitch Bradley's baby. I believe it ran on 68k Suns, > there was some sort of boot prom there. I mostly used it on SPARC. It was developed for SPARC and never ran on Sun-3's. The point of it was to be processor independent. I was involved in bringing it up on Power Macs. It was championed by Ron Hochsprung there, who is also a FORTH fan. In theory, you should have been able to use PCI expansion cards at boot time across vendors by using it, but in practice that didn't happen because very few vendors ever bothered to support anything in their BIOS ROMs other than the PC. And when Apple went with x86 they used the PC's way of the world, like everyone else. From g.branden.robinson at gmail.com Mon Jan 1 09:37:56 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Sun, 31 Dec 2023 17:37:56 -0600 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: <20231231230615.GE19322@mcvoy.com> <202312312308.3BVN8aQ5052682@ultimate.com> Message-ID: <20231231233756.jgyx4pzptucv5kav@illithid> At 2023-12-31T15:06:15-0800, Larry McVoy wrote: > On Sun, Dec 31, 2023 at 04:46:49PM -0600, G. Branden Robinson wrote: > > At 2023-12-31T16:31:00-0500, Clem Cole wrote: > > > But the key is that it ran on 68K's. > > > > I don't think that's the case. > > OpenFirmware is Mitch Bradley's baby. I believe it ran on 68k Suns, > there was some sort of boot prom there. At 2023-12-31T18:08:36-0500, Phil Budne wrote: > OF had its origin in Sun OpenBoot PROM (OBP), which, ISTR, first > appeared in the SPARCstation 1 (sun4c kernel arch) along with SBus. > Earlier (VME) based SPARC (sun4 kernel arch) systems had only a Sun-3 > like boot PROM (single letter commands, no Forth). Thanks for the clarifications, gentlemen. My first Sun experience was a SPARC IPC--a bunch of them, actually, in a "freshman engineering lab"... Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From alec.muffett at gmail.com Mon Jan 1 09:41:44 2024 From: alec.muffett at gmail.com (Alec Muffett) Date: Sun, 31 Dec 2023 23:41:44 +0000 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: <20231231230615.GE19322@mcvoy.com> References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> <20231231224649.h45pogxycgkgs673@illithid> <20231231230615.GE19322@mcvoy.com> Message-ID: On Sun, 31 Dec 2023, 23:25 Larry McVoy, wrote: > Yeah, I get it, Forth is like some weird lisp > and the lisp people love lisp. > HERESY! Forth is a RPN stack language. It's closer to Java bytecode in a whole bunch of ways, but its lineage comes squarely out of embedded systems like radio telescope control. It's a solid choice. Funny I was only posting about it earlier today in respective of the recent iPhone privilege escalation / exploit: https://alecmuffett.com/article/108789 ...which links to some Forth examples. -a -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.branden.robinson at gmail.com Mon Jan 1 09:50:23 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Sun, 31 Dec 2023 17:50:23 -0600 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: <20231231224649.h45pogxycgkgs673@illithid> References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> <20231231224649.h45pogxycgkgs673@illithid> Message-ID: <20231231235023.dqi3pxchnn3paeax@illithid> [self-follow-up] At 2023-12-31T16:46:51-0600, G. Branden Robinson wrote: > The m68k "Old World" PowerMacs used a different firmware entirely; I Sorry, I was missing the word "and" after "m68k" here. I certainly would not deliberately claim that Old World PowerMacs were m68k boxes. > assume boot ROM code descended from the original Macintosh (or even > Lisa, maybe). The PowerPC "New World" PowerMacs, which immediately > departed from the beige color scheme, did come in with Apple's > acquisition of NeXT. ...and used OpenFirmware for their boot ROMs universally. It's my understanding that the OLPC ("One Laptop Per Child") laptop used OF as well, and would have been one of the more unusual devices to do so, but I never got to play with one of those. Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From imp at bsdimp.com Mon Jan 1 09:59:34 2024 From: imp at bsdimp.com (Warner Losh) Date: Sun, 31 Dec 2023 16:59:34 -0700 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: <20231231233756.jgyx4pzptucv5kav@illithid> References: <20231231230615.GE19322@mcvoy.com> <202312312308.3BVN8aQ5052682@ultimate.com> <20231231233756.jgyx4pzptucv5kav@illithid> Message-ID: On Sun, Dec 31, 2023, 4:38 PM G. Branden Robinson < g.branden.robinson at gmail.com> wrote: > At 2023-12-31T15:06:15-0800, Larry McVoy wrote: > > On Sun, Dec 31, 2023 at 04:46:49PM -0600, G. Branden Robinson wrote: > > > At 2023-12-31T16:31:00-0500, Clem Cole wrote: > > > > But the key is that it ran on 68K's. > > > > > > I don't think that's the case. > > > > OpenFirmware is Mitch Bradley's baby. I believe it ran on 68k Suns, > > there was some sort of boot prom there. > > At 2023-12-31T18:08:36-0500, Phil Budne wrote: > > OF had its origin in Sun OpenBoot PROM (OBP), which, ISTR, first > > appeared in the SPARCstation 1 (sun4c kernel arch) along with SBus. > > Earlier (VME) based SPARC (sun4 kernel arch) systems had only a Sun-3 > > like boot PROM (single letter commands, no Forth). > > Thanks for the clarifications, gentlemen. My first Sun experience was a > SPARC IPC--a bunch of them, actually, in a "freshman engineering lab"... > The Sun 3 systems had a similar interface (L1/a etc) but no 4th and a different set of ROMs. Warner Regards, > Branden > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aek at bitsavers.org Mon Jan 1 10:09:19 2024 From: aek at bitsavers.org (Al Kossow) Date: Sun, 31 Dec 2023 16:09:19 -0800 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: <20231231235023.dqi3pxchnn3paeax@illithid> References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> <20231231224649.h45pogxycgkgs673@illithid> <20231231235023.dqi3pxchnn3paeax@illithid> Message-ID: >> assume boot ROM code descended from the original Macintosh (or even >> Lisa, maybe). The PowerPC "New World" PowerMacs, which immediately >> departed from the beige color scheme, did come in with Apple's >> acquisition of NeXT. Sorry, I don't see the original of this misstatement The first generation Nubus PowerMacs use essentially an unmodified 68K ROM for booting, emulating a 68LC040 to do so. Also, Mac and Lisa firmware are completely different from each other. The second generation machines with PCI had Open Firmware. "New World" refers to ROM in RAM systems which have pretty much just some hardware init and OF in them and started around the time of the iMac From bakul at iitbombay.org Mon Jan 1 10:13:02 2024 From: bakul at iitbombay.org (Bakul Shah) Date: Sun, 31 Dec 2023 16:13:02 -0800 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> <202312311738.3BVHctA1018336@freefriends.org> Message-ID: On Dec 31, 2023, at 12:07 PM, Warner Losh wrote: > > Yes. Unlike today, the partitions covered the disk in different, overlapping > ways. And allowed for some parts of the disk to be uncovered by a > partition. You could then patch the offset and length into the kernel with > adb and use that area of the disk for swap space. > >> It was also helpful, if you had the drives, to nightly dd >> your real root to the "a" partition on another, identical >> drive, so that you could boot the backup root in an emergency. >> >> I don't remember for sure, but I think that Ultrix may have >> been the first BSD-style system to have disk labels, followed >> by some version of SunOS. All of that is way in the distant >> past though: mid- to late 80's. > > When I looked into it years ago, I convinced myself that SunOS > was the first to have it (since the very first version of SunOS 1.0 > had disk labels) and that all the other vendors followed suit within > a couple of years. Ultrix-11 had the fixed labels through its EOL. > I didn't see any disklable stuff in the Ultrix-32M that we have, but > it was admittedly a quick look. I wrote the first 2-3 HD drivers for Fortune Systems. I had the first one up and running[1] by late 1981. IIRC we used an ioctl to read/write sector 0 of a disk, which is where we stored partition info. I think by 1983 we were using some 4.1a bits (or at least influenced by it) so likely disklabel was used by then. The first disk drive was 5MB and cost $1700. But 5 1/4" disk capacities were growing fast so there was no question of hardwiring a disktab in source code. I even had a program that would try to "step" through cylinders until it ran into errors, to find at usable capacity! [1] Well, more like walking! Initially DMA didn't work on the first wirewrap boards so had to use PIO (programmed IO), at 25KB/s. A quick hack doubled that performance, while an ST506 disk could do 5Mbits/sec. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Mon Jan 1 10:26:12 2024 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Sun, 31 Dec 2023 18:26:12 -0600 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: <202312311738.3BVHctA1018336@freefriends.org> References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> <202312311738.3BVHctA1018336@freefriends.org> Message-ID: On 12/31/23 11:38, arnold at skeeve.com wrote: > The different overlapping partitions predates disk labels. Okay. That in and of itself doesn't surprise me much that a convention of overlapping partitions was carried forward from the driver based partitioning into label based partitioning. > Up to and including 4.3 BSD, to change the size of partitions on a > particular disk, you had to recompile the kernel. So I've learned over the last couple of years as I read more about Unix history. > They were that way so that if you had multiple disks, you could use > one for root + swap + some thing small and use another whole disk > for a single filesystem. I'm not understanding how /overlapping/ partitions helps make use of portions of disks. Maybe I should back up and ask for clarification. What /overlapping/ partitions means in this context? My naive assumption was that partition -- I use that term loosely -- "c" overlaps / contains / all other partitions on the disk; "a", "b", and maybe "d". I'm eliding the "c" MBR partition vs "d" entire drive" distinction for the moment. I see some value in the "c" partition being the entire disk as used by BSD so that it's possible to point backup / restore / copy utilities at the entire disk. But I don't understand value in having partitions overlap / contain each other's blocks, save for backup via "c". I do see some value in extending the "c" is the entire MBR partition methodology to "d" is the entire disk containing multiple MBR partitions. Again, the value seems to be in backup and recovery. But I still simply do not understand why I would ever want partition "e" to be blocks 100-199, partition "f" to be blocks 195-299, and partition "g" to be blocks 295-399. What value is there in having partitions e, f, and g overlap each other? I get dd if=/dev/0c of=/dev/rmt. Or even /dev/0d. I fail to understand why I'd ever want other partitions to overlap. > It was also helpful, if you had the drives, to nightly dd your real > root to the "a" partition on another, identical drive, so that you > could boot the backup root in an emergency. Sure. But I don't see what that has to do with overlapping partitions. I'd naively think that I could do something like the following: dd if=/dev/0a of=/dev/1a And get the same effect. > I am guessing that the original conventions date back to V7 or 32V, > but one would have to go looking at code to be sure. "a" for root makes some intuitive sense as the root file system is required to do anything else. Then when you want swap, the next partition is "b". Wanting another partition that is the entire disk (as seen by BSD) makes some logical sense to me too, so "c". Were subsequent partitions sort of used as needed and had less consistency? Especially when "d" because the entire disk containing multiple MBR partitions when "c" was restricted to the MBR partition the label was in? Aside: Would that mean that the following "d" partitions would be the same thing, as in the entire /dev/ad0 disk? /dev/ad0s0d /dev/ad0s1d Wherein I'm borrowing the FreeBSD slice nomenclature -- as I understand it -- to identify the first (zero) and second (one) MBR partition on /dev/ad0 History and how we got to where we are today can be both very confusing and even more enlightening once you understand it. What's more is that once you understand it, things start making more intuitive sense when you look at them. -- Grant. . . . -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4033 bytes Desc: S/MIME Cryptographic Signature URL: From imp at bsdimp.com Mon Jan 1 12:22:06 2024 From: imp at bsdimp.com (Warner Losh) Date: Sun, 31 Dec 2023 19:22:06 -0700 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> <202312311738.3BVHctA1018336@freefriends.org> Message-ID: 8 On Sun, Dec 31, 2023, 5:26 PM Grant Taylor via TUHS wrote: > On 12/31/23 11:38, arnold at skeeve.com wrote: > > The different overlapping partitions predates disk labels. > > Okay. That in and of itself doesn't surprise me much that a convention > of overlapping partitions was carried forward from the driver based > partitioning into label based partitioning. > Many editors dont let you do this... > Up to and including 4.3 BSD, to change the size of partitions on a > > particular disk, you had to recompile the kernel. > > So I've learned over the last couple of years as I read more about Unix > history. > > > They were that way so that if you had multiple disks, you could use > > one for root + swap + some thing small and use another whole disk > > for a single filesystem. > > I'm not understanding how /overlapping/ partitions helps make use of > portions of disks. > Maybe I should back up and ask for clarification. What /overlapping/ > partitions means in this context? > It means you either use one set of non overlapping partitions or another set. They were setup in clever ways My naive assumption was that partition -- I use that term loosely -- "c" > overlaps / contains / all other partitions on the disk; "a", "b", and > maybe "d". > > I'm eliding the "c" MBR partition vs "d" entire drive" distinction for > the moment. > > I see some value in the "c" partition being the entire disk as used by > BSD so that it's possible to point backup / restore / copy utilities at > the entire disk. > > But I don't understand value in having partitions overlap / contain each > other's blocks, save for backup via "c". > > I do see some value in extending the "c" is the entire MBR partition > methodology to "d" is the entire disk containing multiple MBR > partitions. Again, the value seems to be in backup and recovery. > > But I still simply do not understand why I would ever want partition "e" > to be blocks 100-199, partition "f" to be blocks 195-299, and partition > "g" to be blocks 295-399. What value is there in having partitions e, > f, and g overlap each other? > > I get dd if=/dev/0c of=/dev/rmt. Or even /dev/0d. > > I fail to understand why I'd ever want other partitions to overlap. > It's more like you can use two or three partitions with non overlapping sets that cover the whole disk. > It was also helpful, if you had the drives, to nightly dd your real > > root to the "a" partition on another, identical drive, so that you > > could boot the backup root in an emergency. > > Sure. But I don't see what that has to do with overlapping partitions. > > I'd naively think that I could do something like the following: > > dd if=/dev/0a of=/dev/1a > > And get the same effect. > > > I am guessing that the original conventions date back to V7 or 32V, > > but one would have to go looking at code to be sure. > > "a" for root makes some intuitive sense as the root file system is > required to do anything else. > > Then when you want swap, the next partition is "b". > > Wanting another partition that is the entire disk (as seen by BSD) makes > some logical sense to me too, so "c". > > Were subsequent partitions sort of used as needed and had less > consistency? Especially when "d" because the entire disk containing > multiple MBR partitions when "c" was restricted to the MBR partition the > label was in? > > Aside: > > Would that mean that the following "d" partitions would be the same > thing, as in the entire /dev/ad0 disk? > > /dev/ad0s0d > /dev/ad0s1d > > Wherein I'm borrowing the FreeBSD slice nomenclature -- as I understand > it -- to identify the first (zero) and second (one) MBR partition on > /dev/ad0 > Yes. But ancient Unix didn’t have nested partitioning schemes like FreeBSD supports... History and how we got to where we are today can be both very confusing > and even more enlightening once you understand it. What's more is that > once you understand it, things start making more intuitive sense when > you look at them. > Think more of a limited number of ways to mix and match for greater flexibility w/o editing the tables. A silly example: a is first 2/3 of the disk. B is 2nd 2/3, c d and e are 1/3 each. Warner -- > Grant. . . . > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Mon Jan 1 13:24:22 2024 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Sun, 31 Dec 2023 21:24:22 -0600 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> <202312311738.3BVHctA1018336@freefriends.org> Message-ID: On 12/31/23 20:22, Warner Losh wrote: > It means you either use one set of non overlapping partitions or > another set. They were setup in clever ways > > It's more like you can use two or three partitions with non overlapping > sets that cover the whole disk. ... > Think more of a limited number of ways to mix and match for greater > flexibility w/o editing the tables. > > A silly example: a is first 2/3 of the disk. B is 2nd 2/3, c d and > e are 1/3 each. Okay. This makes more sense. Pre-define overlapping partitions but only use non-overlapping. Sort of like tool boxes that come with a bunch of supports for dividers, but you can only put so many dividers in the pre-defined spots, but contents between the dividers doesn't overlap. Sort of like how many squares are in this bigger grid of dots that is itself a big square. > But ancient Unix didn’t have nested partitioning schemes like > FreeBSD supports... Understood and appreciated. -- Grant. . . . -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4033 bytes Desc: S/MIME Cryptographic Signature URL: From clemc at ccc.com Tue Jan 2 02:00:07 2024 From: clemc at ccc.com (Clem Cole) Date: Mon, 1 Jan 2024 11:00:07 -0500 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> Message-ID: Warner -- thanks... On Sun, Dec 31, 2023 at 5:07 PM Warner Losh wrote: > > > Except I can't find any of this in our V7m or ultrix-11 that we have. This > is 2.1. And there all the device drivers still have the fixed tables: > .... > > and the ultrix-11 3.1 sources we have are similar, but move all of the > above into /usr/sys/conf/dksizes.c. > I remember dksizes.c -- I'll take your word for it being 3.X, not 2.X; I'm pretty sure that was the start of the work in Merrimack by Fred Cantor to make things more independent. Shannon would have been aware of all of it, and before he went to Sun, he and Jean were working with the folks at CSRG (Sam, in particular), moving some of the DEC I/O support into BSD. Bill Munson convinced his management that it was worth it for DEC to at least make sure the DEC peripherals were being well handled and in mostly the same manner. IIRC Jean spent 6-9 months embedded in the CSRG working on much of that. > The early disktab stuff encoded the default tables into a text file to > make it easier to cope with all the different types of disks, but didn't > affect what we know as bsdlabels until after 4.3BSD. > Right. > The naming convention was there, but the 'write bits to the disk to > describe partitioning' I couldn't find at all in ultrix. I think you may be > confusing that stuff (which was a very clever way to cope with all these > disks that have different partitioning in a increasingly generic way) with > disk labeling which I think. > Quite possible. The key is that partitioning the disk to allow its use for different things and disk geometry support get all mixed together in the different schemes. As we discussed, it often happens in multiple places (since the ROMs, like the PC's BIOS, need at least some of the info at boot), and the loaded OS (particularly ones with multiple OSs on them) might want to do something completely different. This is why Grant's question is a little hard to answer directly - as I said, it is a long, slow trip. UNIX Partitioning, like what Dennis did, came first. If you look at PDP-11 and later Vaxen, the "disk support" for booting is pretty crude and built into the ROM -- *i.e*., boot RP0 or RK0 -- the "disk geometry" is hidden in the Boot ROM. But when so many disks start to show up using the same controllers, the ROM needs to be smarter. So, some way to encode geometry is needed. But Partitioning for the OS is still something that is handy and so often got put into the same support (such as the PC's BIOS tables - which were a good idea, poorly executed). > Sun was first to market with. > To be fair, Masscomp's "disk geometry" code that Paul Cantrell wrote pre-dated Sun by at least a year or more. I did not include it in my history, as it is private to their boot ROM. Nice scheme, actually - but proprietary, and I don't think any of the ideas went anywhere else - other than later Sun ROMs supported a similar functionality, and they would have at least seen them at customers and known about it, particularly since Sun picked up the Xylogic disk and tape controllers that they developed for Masscomp originally (Paul spent many hours at Xylogics helping with their Microcode). The point is, by that time, the proliferation of different disk manufacturers -- something to make the boot ROMs and OS's more independent was forced on the different systems providers if they were going to have any chance of being able to be flexible in the market/field. > > Maybe you can help me find it? > I'll see what I can dig up. > > I did find the SunOS 0.x images (UniSoft V7 port) didn't appear have a > disk partition, but 1.0 (post 4BSD pre 4.1BSD) and later did. That puts it > at 1982. Although based off BSD, the disk label stuff wasn't in BSD for > another 5 years when the BSD folks started the Tahoe port. > Right, this is all of the MK0, CSRG, and Sun connection via Fred, Bill, and Sam. At a minimum, they knew what the other was doing/had done, and some of it definitely migrated. WRT to OpenFW, my memory is that Larry points out that Sun was the primary driver. But a lot of the Motorola club got interested in using it, too, during the "JAWS" timeframe. I am pretty sure that there were versions for 68K, 88K, and PPC, as well as the SPARC version from Sun. Somewhere I have early source distribution. ᐧ ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Wed Jan 3 04:49:56 2024 From: imp at bsdimp.com (Warner Losh) Date: Tue, 2 Jan 2024 11:49:56 -0700 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> Message-ID: On Mon, Jan 1, 2024 at 9:00 AM Clem Cole wrote: > > Warner -- thanks... > > On Sun, Dec 31, 2023 at 5:07 PM Warner Losh wrote: > >> >> >> Except I can't find any of this in our V7m or ultrix-11 that we have. >> This is 2.1. And there all the device drivers still have the fixed tables: >> .... >> >> and the ultrix-11 3.1 sources we have are similar, but move all of the >> above into /usr/sys/conf/dksizes.c. >> > I remember dksizes.c -- I'll take your word for it being 3.X, not 2.X; I'm > pretty sure that was the start of the work in Merrimack by Fred Cantor to > make things more independent. Shannon would have been aware of all of it, > and before he went to Sun, he and Jean were working with the folks at CSRG > (Sam, in particular), moving some of the DEC I/O support into BSD. Bill > Munson convinced his management that it was worth it for DEC to at least > make sure the DEC peripherals were being well handled and in mostly the > same manner. IIRC Jean spent 6-9 months embedded in the CSRG working on > much of that. > I don't have access to anything but Ultrix-11 3.1 sources. But there's no disk label stuff there. The dksizes.c file is just the individual partition sizes removed from the respective driver and added to dksize.c, presumably so it could be rebuilt easily w/o giving away any Unix IP. And the disktab stuff is way better than what came before. It enshrined into a text file what the right partitions should be for each of the devices. And even that took a lot of effort and would feed into the defaults for partitioning disks when that came along. > The early disktab stuff encoded the default tables into a text file to >> make it easier to cope with all the different types of disks, but didn't >> affect what we know as bsdlabels until after 4.3BSD. >> > Right. > > > >> The naming convention was there, but the 'write bits to the disk to >> describe partitioning' I couldn't find at all in ultrix. I think you may be >> confusing that stuff (which was a very clever way to cope with all these >> disks that have different partitioning in a increasingly generic way) with >> disk labeling which I think. >> > Quite possible. > > The key is that partitioning the disk to allow its use for different > things and disk geometry support get all mixed together in the different > schemes. As we discussed, it often happens in multiple places (since the > ROMs, like the PC's BIOS, need at least some of the info at boot), and the > loaded OS (particularly ones with multiple OSs on them) might want to do > something completely different. This is why Grant's question is a > little hard to answer directly - as I said, it is a long, slow trip. > Yes. There's all kinds of compounding factors, as we saw play out when old-school BSD disklabels started existing in a MBR world. > UNIX Partitioning, like what Dennis did, came first. If you look at > PDP-11 and later Vaxen, the "disk support" for booting is pretty crude and > built into the ROM -- *i.e*., boot RP0 or RK0 -- the "disk geometry" is > hidden in the Boot ROM. But when so many disks start to show up using the > same controllers, the ROM needs to be smarter. So, some way to encode > geometry is needed. But Partitioning for the OS is still something that is > handy and so often got put into the same support (such as the PC's BIOS > tables - which were a good idea, poorly executed). > Yes. Dennis did it in like 75, and it wasn't until the mid to late 80s that most disks had their partitioning encoded on the drive itself. Some of the encoding schemes included the geometry of the device (some implicitly, some explicitly), while others didn't. It was a real mess. > Sun was first to market with. >> > To be fair, Masscomp's "disk geometry" code that Paul Cantrell wrote > pre-dated Sun by at least a year or more. I did not include it in my > history, as it is private to their boot ROM. Nice scheme, actually - but > proprietary, and I don't think any of the ideas went anywhere else - other > than later Sun ROMs supported a similar functionality, and they would have > at least seen them at customers and known about it, particularly since Sun > picked up the Xylogic disk and tape controllers that they developed for > Masscomp originally (Paul spent many hours at Xylogics helping with their > Microcode). The point is, by that time, the proliferation of different > disk manufacturers -- something to make the boot ROMs and OS's more > independent was forced on the different systems providers if they were > going to have any chance of being able to be flexible in the market/field. > I have no data on Masscomp's / Xylogic's ROMs, alas. And I know that getting the geometry from the disk lived in the driver for a long time because of issues like this, and why bootstrapping these machines were always a complex affair. I don't recall there being any Xylogic specific labels on the drives we had at Solbourne, though. And did Masscomp's stuff write data to the media that was then used to figure out the geometry / partitioning? Or was it still a largish table of drive model X has geometry x/y/z (which PC BIOS had initially after the AT mainstreamed winchester disks there). > > >> >> Maybe you can help me find it? >> > I'll see what I can dig up. > Yea. I'd be quite keen on the details before Sun's scheme, which was the first I could find in the artifacts we have today. But there's so many artifacts they are all hard to go through. Especially scanned manuals that have no OCR encodings... I did find the SunOS 0.x images (UniSoft V7 port) didn't appear have a disk >> partition, but 1.0 (post 4BSD pre 4.1BSD) and later did. That puts it at >> 1982. Although based off BSD, the disk label stuff wasn't in BSD for >> another 5 years when the BSD folks started the Tahoe port. >> > Right, this is all of the MK0, CSRG, and Sun connection via Fred, Bill, > and Sam. At a minimum, they knew what the other was doing/had done, and > some of it definitely migrated. > What's MK0? Is that the group at DEC that did Unix? > WRT to OpenFW, my memory is that Larry points out that Sun was the primary > driver. But a lot of the Motorola club got interested in using it, too, > during the "JAWS" timeframe. I am pretty sure that there were versions for > 68K, 88K, and PPC, as well as the SPARC version from Sun. Somewhere I > have early source distribution. > > Yea, I have a memory of the Sun 3 (68k) machines having a different ROM than the Sun 4 (sparc) machines in the late 80s/early 90s with similar interfaces, but the Sun 3's being simpler. Maybe I just worked with older Sun 3's that didn't have a newer OpenFirmware. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From chet.ramey at case.edu Wed Jan 3 05:30:46 2024 From: chet.ramey at case.edu (Chet Ramey) Date: Tue, 2 Jan 2024 14:30:46 -0500 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> Message-ID: <798cf2fb-68b7-44b2-96ec-eb164c5b2a5c@case.edu> On 1/2/24 1:49 PM, Warner Losh wrote: > Right, this is all of the MK0, CSRG, and Sun connection via Fred, Bill, > and Sam.  At a minimum, they knew what the other was doing/had done, > and some of it definitely migrated. > > > What's MK0? Is that the group at DEC that did Unix? I don't know what MK0 is either, but Bill Shannon and Sam Leffler had been friends since they were both grad students here at CWRU, so I would assume they kept in touch about what they were doing. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From crossd at gmail.com Wed Jan 3 05:50:52 2024 From: crossd at gmail.com (Dan Cross) Date: Tue, 2 Jan 2024 14:50:52 -0500 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> Message-ID: On Tue, Jan 2, 2024 at 2:00 PM Warner Losh wrote: > [snip] > Yea, I have a memory of the Sun 3 (68k) machines having a different ROM than the Sun 4 (sparc) machines in the late 80s/early 90s with similar interfaces, but the Sun 3's being simpler. Maybe I just worked with older Sun 3's that didn't have a newer OpenFirmware. Sun 3/50 and Sun 3/60 definitely had a different PROM arrangement than SPARCstations. However, I have a vague memory that the Sun 3/80 used OpenFirmware. The 3/80 (and similar Sun-3x machines introduced at the same time) would have been among the last, if not the last, MC68k-based Sun3 machine. I may be wrong, though; it's been a while. Regardless, I vaguely remember the "ok" prompt on a 3/80. - Dan C. From jcapp at anteil.com Wed Jan 3 05:55:36 2024 From: jcapp at anteil.com (Jim Capp) Date: Tue, 2 Jan 2024 14:55:36 -0500 (EST) Subject: [TUHS] Question about BSD disklabel history In-Reply-To: Message-ID: <7536431.12274.1704225336145.JavaMail.root@zimbraanteil> The "ok" prompt is from "OpenBoot", a boot manager, written in FORTH: https://docs.oracle.com/cd/E19253-01/816-1177-10/816-1177-10.pdf Jim From: "Dan Cross" To: "Warner Losh" Cc: "Grant Taylor" , "The Unix Heritage Society" Sent: Tuesday, January 2, 2024 2:50:52 PM Subject: [TUHS] Re: Question about BSD disklabel history On Tue, Jan 2, 2024 at 2:00 PM Warner Losh wrote: > [snip] > Yea, I have a memory of the Sun 3 (68k) machines having a different ROM than the Sun 4 (sparc) machines in the late 80s/early 90s with similar interfaces, but the Sun 3's being simpler. Maybe I just worked with older Sun 3's that didn't have a newer OpenFirmware. Sun 3/50 and Sun 3/60 definitely had a different PROM arrangement than SPARCstations. However, I have a vague memory that the Sun 3/80 used OpenFirmware. The 3/80 (and similar Sun-3x machines introduced at the same time) would have been among the last, if not the last, MC68k-based Sun3 machine. I may be wrong, though; it's been a while. Regardless, I vaguely remember the "ok" prompt on a 3/80. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Jan 3 06:07:45 2024 From: clemc at ccc.com (Clem Cole) Date: Tue, 2 Jan 2024 15:07:45 -0500 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: <798cf2fb-68b7-44b2-96ec-eb164c5b2a5c@case.edu> References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> <798cf2fb-68b7-44b2-96ec-eb164c5b2a5c@case.edu> Message-ID: On Tue, Jan 2, 2024 at 2:31 PM Chet Ramey wrote: > On 1/2/24 1:49 PM, Warner Losh wrote: > > > Right, this is all of the MK0, CSRG, and Sun connection via Fred, > Bill, > > and Sam. At a minimum, they knew what the other was doing/had done, > > and some of it definitely migrated. > > > > > > What's MK0? Is that the group at DEC that did Unix? > DEC Merrimack NH Site - where Telephone Industries Group (TIG) and Custom Special Systems (CSS) were located. It was originally the site dedicated to supporting DEC's largest customer - AT & T. Bill Munson originally ran TIG. Armando, Jean, Shannon, Cantor, *et al.* worked in TIG. Those folks eventually moved to ZK03 - Spit Brook Road, in Nashua, with the other OS teams when Ultrix was created. Sorry, old habits are hard to change. Except for the Mill itself, many, if not most, of us from the old days still refer to the different DEC sites (particularly the original New Englands) by their site code. For instance, my old offices were in MR02 (Marlboro, MA) and ZK03. Years later, the compiler team (in ZK02) was sold twice, and they never moved their desk. Hence, when I later joined Intel, my desk was placed in ZK02 with the compiler folks like Paul W. In fact, when Intel finally moved us out, we realized that folks like Steve Hobbs had not moved his desk in 30 years. I don't know what MK0 is either, but Bill Shannon and Sam Leffler had been > friends since they were both grad students here at CWRU, so I would assume > they kept in touch about what they were doing. > Indeed, and having been friends with them both, I can verify that they did. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Wed Jan 3 06:11:04 2024 From: crossd at gmail.com (Dan Cross) Date: Tue, 2 Jan 2024 15:11:04 -0500 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: <7536431.12274.1704225336145.JavaMail.root@zimbraanteil> References: <7536431.12274.1704225336145.JavaMail.root@zimbraanteil> Message-ID: On Tue, Jan 2, 2024 at 2:55 PM Jim Capp wrote: > The "ok" prompt is from "OpenBoot", Yes. See Phil Bunde's message earlier in this thread. - Dan C. > a boot manager, written in FORTH: > > https://docs.oracle.com/cd/E19253-01/816-1177-10/816-1177-10.pdf From crossd at gmail.com Wed Jan 3 06:30:25 2024 From: crossd at gmail.com (Dan Cross) Date: Tue, 2 Jan 2024 15:30:25 -0500 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> Message-ID: On Tue, Jan 2, 2024 at 2:50 PM Dan Cross wrote: > On Tue, Jan 2, 2024 at 2:00 PM Warner Losh wrote: > > [snip] > > Yea, I have a memory of the Sun 3 (68k) machines having a different ROM than the Sun 4 (sparc) machines in the late 80s/early 90s with similar interfaces, but the Sun 3's being simpler. Maybe I just worked with older Sun 3's that didn't have a newer OpenFirmware. > > Sun 3/50 and Sun 3/60 definitely had a different PROM arrangement than > SPARCstations. However, I have a vague memory that the Sun 3/80 used > OpenFirmware. The 3/80 (and similar Sun-3x machines introduced at the > same time) would have been among the last, if not the last, > MC68k-based Sun3 machine. I may be wrong, though; it's been a while. > Regardless, I vaguely remember the "ok" prompt on a 3/80. Hmm: correcting myself here. I can find no evidence that the 3/80 used OBP, but I can find documentation to the contrary (mostly in the form of documentation on how to rewrite the HostID when the NVRAM battery fails...Gah, the things one not only forgets but actively blots out of one's memory). It seems likely that Sun never shipped OF on 68k. - Dan C. From crossd at gmail.com Wed Jan 3 06:48:28 2024 From: crossd at gmail.com (Dan Cross) Date: Tue, 2 Jan 2024 15:48:28 -0500 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: <20231231230615.GE19322@mcvoy.com> References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> <20231231224649.h45pogxycgkgs673@illithid> <20231231230615.GE19322@mcvoy.com> Message-ID: On Sun, Dec 31, 2023 at 6:25 PM Larry McVoy wrote: >[snip] > OpenFirmware is Mitch Bradley's baby. I believe it ran on 68k Suns, > there was some sort of boot prom there. I mostly used it on SPARC. > It was pretty powerful but my personal feeling is the choice of > Forth didn't help. Yeah, I get it, Forth is like some weird lisp > and the lisp people love lisp. What the lisp people don't get is > there are a lot more people who don't love lisp than do love lisp. > And trying to get everyone to love lisp isn't gonna happen. > > That said, what else could Mitch have used at the time? Tcl? > Please, another weird lisp. Perl? Not really something that > wants to talk to the bare metal. > > It's a serious question, is there anything that Mitch could have > used that would have had wider appeal? The thing about FORTH isn't that it's Lisp-like (as Alec mentioned), though its supporters do often exhibit a fervor reminiscent of Lispers. Rather, I think FORTH shows up in places like this because it's possible to write _incredibly_ lean threaded-code interpreters for it that can run in really primitive environments, so you can shove a really small interpreter in a ROM and keep your big CPU in reset while you run it out of a tiny SRAM on an 8-bit microcontroller or something until you've got enough of an environment going to train DRAM and transfer over to the real thing. E.g., something like: https://pygmy.utoh.org/3ins4th.html What could you have done differently? Meh; I don't really know, but see below. > And I agree whole heartedly with the EFI crap being a giant step > backwards. Ironically, the UEFI people have done something _similar_ to OF in the form of AML (ACPI Machine Language), which is a byte-code serialization ASL (ACPI Source Language); presumably that's system independent. The idea of a p-code representation is about where the similarity ends, though: AML exposes a mechanism to talk to the UEFI OS for a whole slew of stuff, which is rather unlike what OF did (though I again have a vague memory that on SPARCstations some devices went through the PROM monitor; the text console, for example, and maybe the keyboard? It's been too long now to properly remember). Anyway, an alternative to FORTH might have been a well-defined p-code and a little VM in ROM to drive it. Then one could compile to that using whatever language one liked (and was willing to write a compiler for!). Perhaps the feeling is that that is what FORTH was; for that I guess I don't see any reason one couldn't transpile to FORTH from some other language. - Dan C. From clemc at ccc.com Wed Jan 3 06:50:09 2024 From: clemc at ccc.com (Clem Cole) Date: Tue, 2 Jan 2024 15:50:09 -0500 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> Message-ID: I never said Sun or anyone else actually shipped it -- only that it was around, and there was a lot of discussion about using it/trying to create a boot ROM standard one of some type. IIRC I remember that NCR was messing with it for their 88K boxes (which I had a hand in killing). But NCR switched to all x86-based (their "7 levels "strategy) for everything from Cash Registers/ATMs to their largest Database machines. They had always been in the "better and cheaper than IBM" business, particularly in their computer products. [1] So after they switch, their boots start to be all BIOS and EBIOS flavored. But other Motorola folks I was working with at the time were exploring OF. I had it on a 68K and another 88K prototype machine at one point (I remember the "ok" prompt), and I remember I somehow had a source distribution tape. I was an independent consultant then and wrote a couple of drivers under contract for some different folks. I can not think of the firm's name now -- there was another 68K workstation firm here in Lowell, MA. They actually wrote and made a MacOS emulator work with their UNIX under covers. I've forgotten most of the details now, but they may have been one of the folks who was playing with OF. My memory is that I first encountered it at one of my consulting gigs. Clem 1] When they threw the x86 everywhere die, they also started using Microchannel (the only large licensee I know of for it -- everyone else stayed with ISA/EISA and then later PCI from DEC/AMD) - tossing out all the Moto IP like VME that so many UNIX systems had used). ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Wed Jan 3 07:04:16 2024 From: crossd at gmail.com (Dan Cross) Date: Tue, 2 Jan 2024 16:04:16 -0500 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> Message-ID: On Tue, Jan 2, 2024 at 3:50 PM Clem Cole wrote: > I never said Sun or anyone else actually shipped it -- only that it was around, and there was a lot of discussion about using it/trying to create a boot ROM standard one of some type. Sorry! I didn't mean to imply that you had; rather, I thought that they had because I thought I remembered seeing it on Sun-3x, but I think I'm just misremembering. > IIRC I remember that NCR was messing with it for their 88K boxes (which I had a hand in killing). But NCR switched to all x86-based (their "7 levels "strategy) for everything from Cash Registers/ATMs to their largest Database machines. They had always been in the "better and cheaper than IBM" business, particularly in their computer products. [1] So after they switch, their boots start to be all BIOS and EBIOS flavored. Poor suckers. :-( > But other Motorola folks I was working with at the time were exploring OF. I had it on a 68K and another 88K prototype machine at one point (I remember the "ok" prompt), and I remember I somehow had a source distribution tape. I was an independent consultant then and wrote a couple of drivers under contract for some different folks. I can not think of the firm's name now -- there was another 68K workstation firm here in Lowell, MA. They actually wrote and made a MacOS emulator work with their UNIX under covers. I've forgotten most of the details now, but they may have been one of the folks who was playing with OF. > > My memory is that I first encountered it at one of my consulting gigs. That's cool. It's sad that, around the time of the 386, we didn't have more x86 vendors doing something like OF. Maybe we could have avoided a bunch of big messes. Maybe not. > 1] When they threw the x86 everywhere die, they also started using Microchannel (the only large licensee I know of for it -- everyone else stayed with ISA/EISA and then later PCI from DEC/AMD) - tossing out all the Moto IP like VME that so many UNIX systems had used). I knew a bunch of folks in the early/mid 90s who were pretty tight in the IBM camp; RS/6000's were shipping on MCA and they said they saw better IO performance than with PCI for a couple of generations. - Dan C. From cowan at ccil.org Wed Jan 3 07:17:54 2024 From: cowan at ccil.org (John Cowan) Date: Tue, 2 Jan 2024 16:17:54 -0500 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> <20231231224649.h45pogxycgkgs673@illithid> <20231231230615.GE19322@mcvoy.com> Message-ID: On Tue, Jan 2, 2024 at 3:49 PM Dan Cross wrote: Perhaps the feeling is that that is what FORTH was; for that I > guess I don't see any reason one couldn't transpile to FORTH from some > other language. Henry Baker wrote a beautiful little paper (see https://www.plover.com/~mjd/misc/hbaker-archive/ForthStack.html>) showing the mapping between Linear Lisp (a Lisp in which all variables are referenced once and only once) and a Forth-style "frameless stack". There is also a discussion of Forth as a set of linear combinators: Manfred von Thun's Joy is a Forth-like using nested lists in which the stack is the top-level list. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Wed Jan 3 13:33:45 2024 From: tytso at mit.edu (Theodore Ts'o) Date: Tue, 2 Jan 2024 22:33:45 -0500 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> <20231231224649.h45pogxycgkgs673@illithid> <20231231230615.GE19322@mcvoy.com> Message-ID: <20240103033345.GA108362@mit.edu> On Tue, Jan 02, 2024 at 03:48:28PM -0500, Dan Cross wrote: > On Sun, Dec 31, 2023 at 6:25 PM Larry McVoy wrote: > > Ironically, the UEFI people have done something _similar_ to OF in the > form of AML (ACPI Machine Language), which is a byte-code > serialization ASL (ACPI Source Language); presumably that's system > independent. The idea of a p-code representation is about where the > similarity ends, though: AML exposes a mechanism to talk to the UEFI > OS for a whole slew of stuff, which is rather unlike what OF did ACPI (Advanced Configuration and Power Interface) predates UEFI. ACPI was released in 1996, and was originally intended to be a replacement for APM (Advanced Power Management). With APM, the OS would crowbar itself into x86 Real mode in order to call into the APM BIOS in order to suspend the laptop, fetch power management events from the APM, etc. Later on, APM grew 32-bit protected mode interfaces, but effectively, the OS would completely lose control of the thread of execution while running APM BIOS code, which made life "exciting" for OS engineers. So ACPI was originally intended to solve a problem, where the OS could incorporate a byte code interpreter to do those things that would be very hardware specific (for example, how to diddle the various random I/O ports on a HP laptop to bring the perpipherals into a low power state, which of course would be completely different on a Dell or IBM laptop. Previously, the APM bios was the abstraction layer; ACPI was the new abstraction layer. UEFI came later. UEFI was the second system disease replacement for EFI (extensible firmware interface), which Intel had developed. EFI was an implementation that attempted to retain full backwards compatibility with the de factor standard originally established by the IBM BIOS. UEFI was an attempt to completely rework the interface between the OS boot code (which before would talk to the BIOS interface) with the all new singing, all dancing UEFI interface. Being a second system, of course it was made horribly complicated, so as to meet all of the requirements that might be dreamed up by the industry committee that put it together. Normally, once the OS has gotten to a certain point in its OS initialization, the OS can "terminate UEFI services". At that point, the OS can no longer call into the UEFI functions --- but it also doesn't have to worry about the UEFI code servicing an interrupt take taking control of the CPU away from the OS. However, the OS can still execute various ACPI functions, assuming the OS has its own AML interpreter. (Of course, the UEFI BIOS has its own AML interpreter --- and scheduler --- and everything else that a simple OS might have.) Ron Minnich has a number of really good presentations about the "joys" of working with UEFI. See the YouTube video, "Replace your Expoit-ridden Firmware with Linux"[1] and prepare to be horrified about what horrors lurks in the heart of UEFI.... [1] https://www.youtube.com/watch?v=iffTJ1vPCSo So you can very much be *not* using UEFI, and still be using ACPI --- either if you are using a pre-2004 computer, or if you are using a more modern platform which uses LinuxBoot. - Ted From imp at bsdimp.com Wed Jan 3 13:57:34 2024 From: imp at bsdimp.com (Warner Losh) Date: Tue, 2 Jan 2024 20:57:34 -0700 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: <20240103033345.GA108362@mit.edu> References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> <20231231224649.h45pogxycgkgs673@illithid> <20231231230615.GE19322@mcvoy.com> <20240103033345.GA108362@mit.edu> Message-ID: On Tue, Jan 2, 2024 at 8:33 PM Theodore Ts'o wrote: > On Tue, Jan 02, 2024 at 03:48:28PM -0500, Dan Cross wrote: > > On Sun, Dec 31, 2023 at 6:25 PM Larry McVoy wrote: > > > > Ironically, the UEFI people have done something _similar_ to OF in the > > form of AML (ACPI Machine Language), which is a byte-code > > serialization ASL (ACPI Source Language); presumably that's system > > independent. The idea of a p-code representation is about where the > > similarity ends, though: AML exposes a mechanism to talk to the UEFI > > OS for a whole slew of stuff, which is rather unlike what OF did > > ACPI (Advanced Configuration and Power Interface) predates UEFI. ACPI > was released in 1996, and was originally intended to be a replacement > for APM (Advanced Power Management). With APM, the OS would crowbar > itself into x86 Real mode in order to call into the APM BIOS in order > to suspend the laptop, fetch power management events from the APM, > etc. Later on, APM grew 32-bit protected mode interfaces, but > effectively, the OS would completely lose control of the thread of > execution while running APM BIOS code, which made life "exciting" for > OS engineers. > > So ACPI was originally intended to solve a problem, where the OS could > incorporate a byte code interpreter to do those things that would be > very hardware specific (for example, how to diddle the various random > I/O ports on a HP laptop to bring the perpipherals into a low power > state, which of course would be completely different on a Dell or IBM > laptop. Previously, the APM bios was the abstraction layer; ACPI was > the new abstraction layer. > > UEFI came later. UEFI was the second system disease replacement for > EFI (extensible firmware interface), which Intel had developed. EFI > was an implementation that attempted to retain full backwards > compatibility with the de factor standard originally established by > the IBM BIOS. UEFI was an attempt to completely rework the interface > between the OS boot code (which before would talk to the BIOS > interface) with the all new singing, all dancing UEFI interface. > Being a second system, of course it was made horribly complicated, so > as to meet all of the requirements that might be dreamed up by the > industry committee that put it together. > Not quite. EFI was the second system. It didn't try to retain any backwards compatibility with the original IBM BIOS. It was completely different. Early Intel macs used it to boot. Intel and Apple worked on it together. Intel wrote it for the Itanium IA64 fiasco because it couldn't use the IBM BIOS interfaces and such to boot its new machine because IA64 lacked many of the low-level tricks that you used to interface. to the BIOS. It was an attempt to redo things from scratch. Intel did then turn it over to something more public to manage, but it was well on its way to being an insane mess before it morphed into UEFI. But even in EFI times it was clearly on the way to being the trainwreck it became. > Normally, once the OS has gotten to a certain point in its OS > initialization, the OS can "terminate UEFI services". At that point, > the OS can no longer call into the UEFI functions --- but it also > doesn't have to worry about the UEFI code servicing an interrupt take > taking control of the CPU away from the OS. > There's a 'however' here. The OS may call UEFI Runtime Services from time to time (to interact with non-volatile variables), and it has to carefully arrange things to do this (it has to swap in a special memory map, etc). So UEFI isn't completely gone away.. You just don't have to worry about it fielding interrupts after you exit boot services. > However, the OS can still execute various ACPI functions, assuming the > OS has its own AML interpreter. (Of course, the UEFI BIOS has its own > AML interpreter --- and scheduler --- and everything else that a > simple OS might have.) Ron Minnich has a number of really good > presentations about the "joys" of working with UEFI. See the YouTube > video, "Replace your Expoit-ridden Firmware with Linux"[1] and prepare to > be horrified about what horrors lurks in the heart of UEFI.... > > [1] https://www.youtube.com/watch?v=iffTJ1vPCSo > > So you can very much be *not* using UEFI, and still be using ACPI --- > either if you are using a pre-2004 computer, or if you are using a > more modern platform which uses LinuxBoot. > Indeed. I got to deal with all of that, and more. I have finished writing LinuxBoot support for FreeBSD. The normal kexec-tools, u-root, etc aren't sufficient for FreeBSD because FreeBSD's kernel expects the boot loader to setup a number of meta-data items that go with the kernel that include all the information about the system that the kernel simply can't get once you've entered long mode... Even with LinuxBoot, you are booting with UEFI, albeit with a much small much smaller UEFI. The PEI is still there (the pre-efi initialization phase: that runs the CPU vendor's binary blobs, and does other baisc bringup of the machine). In addition, UEFI's runtime services remain. Linux's EFI capsule replaces almost all fo the DEX drivers, though, which is a huge win It's a stub that acts as the first EFI program that runs before UEFI gets too far along (MDS on x86, Shell,efi on all the others). It completely takes over, modulo the callbacks to Runtime Services. Why am I on about Runtime Services so much? That was one of the pain points of my port. ExitBootServices had been called, and SetVirtualMapping had been as well by the time my boot loader got to run. So I had to pass all that into FreeBSD's kernel (along with an interesting amount of metadata to work around chip errata) and the FreeBSD kernel expected 1:1 PA:VA mapping, but the Linux kernel doesn't do that and if I want to run there I have to cope. Thankfully, the kernel only needed one bug fix and two asserts removed to work... So even with LinuxBoot you still have a tiny bit of UEFI left behind... Though the huge ugly mess of it finding what to boot, executing another boot loader, and that loading the kernel is thankfully gone. My BSDcan talk, my EuroBSDcon talk and a forthcoming article on booting FreeBSD in a LinuxBoot environment are all on this. https://2023.eurobsdcon.org/slides/eurobsdcon2023-warner_losh-kboot.pdf are the slides, but the videos aren't up for some reason.... It was very eye-opening doing this work... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Wed Jan 3 14:03:31 2024 From: imp at bsdimp.com (Warner Losh) Date: Tue, 2 Jan 2024 21:03:31 -0700 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> <20231231224649.h45pogxycgkgs673@illithid> <20231231230615.GE19322@mcvoy.com> <20240103033345.GA108362@mit.edu> Message-ID: On Tue, Jan 2, 2024 at 8:57 PM Warner Losh wrote: > . It didn't try to retain any backwards > compatibility with the original IBM BIOS. > I should have added... Later, UEFI also added CSM booting mode to boot legacy mode that was a bit compatible. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Wed Jan 3 14:30:36 2024 From: tytso at mit.edu (Theodore Ts'o) Date: Tue, 2 Jan 2024 23:30:36 -0500 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> <20231231224649.h45pogxycgkgs673@illithid> <20231231230615.GE19322@mcvoy.com> <20240103033345.GA108362@mit.edu> Message-ID: <20240103043036.GB108362@mit.edu> On Tue, Jan 02, 2024 at 08:57:34PM -0700, Warner Losh wrote: > > Indeed. I got to deal with all of that, and more. I have finished writing > LinuxBoot support for FreeBSD. The normal kexec-tools, u-root, etc aren't > sufficient for FreeBSD because FreeBSD's kernel expects the boot loader > to setup a number of meta-data items that go with the kernel that include > all the information about the system that the kernel simply can't get once > you've entered long mode... > > Even with LinuxBoot, you are booting with UEFI, albeit with a much small > much smaller UEFI. Yeah, one of the older names of LinuxBoot was NERF (Non-Extensible Reduced Firmware). I was confusing LinuxBoot with coreboot, which is used on all ChromeOS devices after 2012, and which completely doesn't use any magic binary blobs supplied by the mainbord vendor. The tradeoff is that coreboot only supports a very restricted set of hardware, since it has to do all of the things that are "normally" done by the vendor's binary blobs to initialize the hardware devices, etc. This only works if you have very tight control over hardware, and you have enough influence that you can lean on the mainboard vendors to allow the low-level programming details of their devices to be released in open source code which that can be independently verified and digitally signed by the OS vendor (such as Google in the case of ChromeOS). Many hyper-scale cloud companies will tend to use coreboot or related software instead of UEFI. A public/published example of this is Facebook's Open Compute Project. It *is* nice not to have to deal with UEFI at all, if you're lucky enough to be able to use hardware where it's not necessary.... Of course you won't be able to run Windows on those systems, but some would consider that a feature. :-) - Ted From imp at bsdimp.com Wed Jan 3 15:10:40 2024 From: imp at bsdimp.com (Warner Losh) Date: Tue, 2 Jan 2024 22:10:40 -0700 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: <20240103043036.GB108362@mit.edu> References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> <20231231224649.h45pogxycgkgs673@illithid> <20231231230615.GE19322@mcvoy.com> <20240103033345.GA108362@mit.edu> <20240103043036.GB108362@mit.edu> Message-ID: On Tue, Jan 2, 2024 at 9:30 PM Theodore Ts'o wrote: > On Tue, Jan 02, 2024 at 08:57:34PM -0700, Warner Losh wrote: > > > > Indeed. I got to deal with all of that, and more. I have finished writing > > LinuxBoot support for FreeBSD. The normal kexec-tools, u-root, etc aren't > > sufficient for FreeBSD because FreeBSD's kernel expects the boot loader > > to setup a number of meta-data items that go with the kernel that include > > all the information about the system that the kernel simply can't get > once > > you've entered long mode... > > > > Even with LinuxBoot, you are booting with UEFI, albeit with a much small > > much smaller UEFI. > > Yeah, one of the older names of LinuxBoot was NERF (Non-Extensible > Reduced Firmware). I love the secondary meaning for nerf from gaming too: "to reconfigure (an existing character or weapon), making it less powerful." > I was confusing LinuxBoot with coreboot, which is > used on all ChromeOS devices after 2012, and which completely doesn't > use any magic binary blobs supplied by the mainbord vendor. The > tradeoff is that coreboot only supports a very restricted set of > hardware, since it has to do all of the things that are "normally" > done by the vendor's binary blobs to initialize the hardware devices, > etc. This only works if you have very tight control over hardware, > and you have enough influence that you can lean on the mainboard > vendors to allow the low-level programming details of their devices to > be released in open source code which that can be independently > verified and digitally signed by the OS vendor (such as Google in the > case of ChromeOS). > I think that some of the open laptops might have a binary blob or two buried deep in their coreboot implementation. But it is far more open system than EDK2 is... Most of the open parts of EDK2 are what are nerfed by LinuxBoot. The private hidden ones are all that remain, alas. So if you are large enough, you can get all the sources. If not, then you have to put up with the binary blob, or not run on some computers. :(. There's also a rewrite of coreboot in Rust called 'oreboot' which is coreboot without the 'C', since they want it to be even safer. Many hyper-scale cloud companies will tend to use coreboot or related > software instead of UEFI. A public/published example of this is > Facebook's Open Compute Project. > Yes. It was a concerted effort of all these stakeholders that got the Linux kernel so it could tolerate such an early handoff. > It *is* nice not to have to deal with UEFI at all, if you're lucky > enough to be able to use hardware where it's not necessary.... Of > course you won't be able to run Windows on those systems, but some > would consider that a feature. :-) > Yea... There's several experimental attempts at booting windows on at least the UEFI-remnant machines. And it's (a) too F'ing weird and (b) to far afield to get into here... https://www.osfc.io/2019/talks/booting-windows-on-linuxboot/ has all the horrors of one such attempt. I think this is the 'create an exec handler in Linux that can run .efi programs and emulate UEFI' version... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Thu Jan 4 00:39:06 2024 From: crossd at gmail.com (Dan Cross) Date: Wed, 3 Jan 2024 09:39:06 -0500 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: <20240103033345.GA108362@mit.edu> References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> <20231231224649.h45pogxycgkgs673@illithid> <20231231230615.GE19322@mcvoy.com> <20240103033345.GA108362@mit.edu> Message-ID: On Tue, Jan 2, 2024 at 10:33 PM Theodore Ts'o wrote: > On Tue, Jan 02, 2024 at 03:48:28PM -0500, Dan Cross wrote: > > On Sun, Dec 31, 2023 at 6:25 PM Larry McVoy wrote: > > > > Ironically, the UEFI people have done something _similar_ to OF in the > > form of AML (ACPI Machine Language), which is a byte-code > > serialization ASL (ACPI Source Language); presumably that's system > > independent. The idea of a p-code representation is about where the > > similarity ends, though: AML exposes a mechanism to talk to the UEFI > > OS for a whole slew of stuff, which is rather unlike what OF did > > [Ted's excellent history of ACPI/UEFI elided for brevity.] > > Normally, once the OS has gotten to a certain point in its OS > initialization, the OS can "terminate UEFI services". At that point, > the OS can no longer call into the UEFI functions --- but it also > doesn't have to worry about the UEFI code servicing an interrupt take > taking control of the CPU away from the OS. Warner corrected this: UEFI remains resident and callable. > However, the OS can still execute various ACPI functions, assuming the > OS has its own AML interpreter. (Of course, the UEFI BIOS has its own > AML interpreter --- and scheduler --- and everything else that a > simple OS might have.) Ron Minnich has a number of really good > presentations about the "joys" of working with UEFI. See the YouTube > video, "Replace your Expoit-ridden Firmware with Linux"[1] and prepare to > be horrified about what horrors lurks in the heart of UEFI.... > > [1] https://www.youtube.com/watch?v=iffTJ1vPCSo I'm well aware. :-) But I'll see your LinuxBoot and raise you this: https://www.osfc.io/2022/talks/i-have-come-to-bury-the-bios-not-to-open-it-the-need-for-holistic-systems/ Of course, we at Oxide have the luxury of controlling the hardware in addition to the software that runs [directly] on it, so we can get away with doing our own thing. It's not so easy in the larger world, where integrating components from disparate vendors demands _some_ kind of interface. It's just unfortunate that UEFI is the interface that we got; see also Mothy Roscoe's OSDI'21 keynote about rediscovering hardware. > So you can very much be *not* using UEFI, and still be using ACPI --- > either if you are using a pre-2004 computer, or if you are using a > more modern platform which uses LinuxBoot. Indeed; caveat the details that have already been mentioned about coreboot/oreboot/holistic boot vs LinuxBoot (which replaces the UEFI DXE layer). However, note that the ACPI spec has fallen under the auspices of the UEFI forum for the last ten years or so, which is what I meant (e.g., that one finds the ACPI spec on uefi.org). It's true, though, that I was being unacceptably imprecise by not mentioning the history at all and that ACPI came before UEFI. - Dan C. From crossd at gmail.com Thu Jan 4 01:56:14 2024 From: crossd at gmail.com (Dan Cross) Date: Wed, 3 Jan 2024 10:56:14 -0500 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> <20231231224649.h45pogxycgkgs673@illithid> <20231231230615.GE19322@mcvoy.com> <20240103033345.GA108362@mit.edu> <20240103043036.GB108362@mit.edu> Message-ID: On Wed, Jan 3, 2024 at 12:10 AM Warner Losh wrote: > On Tue, Jan 2, 2024 at 9:30 PM Theodore Ts'o wrote: >> [snip] >> I was confusing LinuxBoot with coreboot, which is >> used on all ChromeOS devices after 2012, and which completely doesn't >> use any magic binary blobs supplied by the mainbord vendor. The >> tradeoff is that coreboot only supports a very restricted set of >> hardware, since it has to do all of the things that are "normally" >> done by the vendor's binary blobs to initialize the hardware devices, >> etc. This only works if you have very tight control over hardware, >> and you have enough influence that you can lean on the mainboard >> vendors to allow the low-level programming details of their devices to >> be released in open source code which that can be independently >> verified and digitally signed by the OS vendor (such as Google in the >> case of ChromeOS). > > I think that some of the open laptops might have a binary blob or two > buried deep in their coreboot implementation. But it is far more open > system than EDK2 is... Most of the open parts of EDK2 are what are nerfed > by LinuxBoot. The private hidden ones are all that remain, alas. Sadly the situation is even more complex than this. Consider AMD's EPYC processors: before the x86 cores start up, the PSP (Platform Security Processor) starts up and does a lot of pre-pre-initialization: it does DRAM timing training, for instance. It's also responsible for loading the x86 payload out of the local flash and setting up the x86 environment so that when those cores come out of reset, they're running whatever was loaded (for instance, they can load %cs on the BSC so that it starts somewhere other than the architecturally-defined segment right below 4GiB). While cool in some ways ("I don't have to train DRAM? Score!") the PSP is embedded in the SoC and the firmware is a signed blob you get from AMD. I know there's an ARM Cortex-A5 in there, but don't know much more about it and even if I did, I have no way to generate signed images for it. :-/ The point is, even if you've got a completely open stack running on x86 from the reset vector, there's almost certainly something else somewhere that's not open (yet). > So if you are large enough, you can get all the sources. If not, then you > have to put up with the binary blob, or not run on some computers. :(. Yup. :-( - Dan C. From tytso at mit.edu Thu Jan 4 02:37:00 2024 From: tytso at mit.edu (Theodore Ts'o) Date: Wed, 3 Jan 2024 11:37:00 -0500 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> <20231231224649.h45pogxycgkgs673@illithid> <20231231230615.GE19322@mcvoy.com> <20240103033345.GA108362@mit.edu> <20240103043036.GB108362@mit.edu> Message-ID: <20240103163700.GA136592@mit.edu> On Wed, Jan 03, 2024 at 10:56:14AM -0500, Dan Cross wrote: > Sadly the situation is even more complex than this. > > Consider AMD's EPYC processors: before the x86 cores start up, the PSP > (Platform Security Processor) starts up and does a lot of > pre-pre-initialization: it does DRAM timing training, for instance. > It's also responsible for loading the x86 payload out of the local > flash and setting up the x86 environment so that when those cores come > out of reset, they're running whatever was loaded (for instance, they > can load %cs on the BSC so that it starts somewhere other than the > architecturally-defined segment right below 4GiB). While cool in some > ways ("I don't have to train DRAM? Score!") the PSP is embedded in the > SoC and the firmware is a signed blob you get from AMD. I know there's > an ARM Cortex-A5 in there, but don't know much more about it and even > if I did, I have no way to generate signed images for it. :-/ > > The point is, even if you've got a completely open stack running on > x86 from the reset vector, there's almost certainly something else > somewhere that's not open (yet). Or there's something running on a completely different x86 core with unpatched securiy bugs in the Minix and Apache cores that you can't even disable (unless you are the National Security Agency).... Sadly, Intel refuses to make it available the magic bits to disable the Intel ME to anyone else. :-( - Ted From crossd at gmail.com Thu Jan 4 02:41:52 2024 From: crossd at gmail.com (Dan Cross) Date: Wed, 3 Jan 2024 11:41:52 -0500 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: <20240103163700.GA136592@mit.edu> References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> <20231231224649.h45pogxycgkgs673@illithid> <20231231230615.GE19322@mcvoy.com> <20240103033345.GA108362@mit.edu> <20240103043036.GB108362@mit.edu> <20240103163700.GA136592@mit.edu> Message-ID: On Wed, Jan 3, 2024 at 11:37 AM Theodore Ts'o wrote: > On Wed, Jan 03, 2024 at 10:56:14AM -0500, Dan Cross wrote: > > Sadly the situation is even more complex than this. > > > > Consider AMD's EPYC processors: before the x86 cores start up, the PSP > > (Platform Security Processor) starts up and does a lot of > > pre-pre-initialization: it does DRAM timing training, for instance. > > It's also responsible for loading the x86 payload out of the local > > flash and setting up the x86 environment so that when those cores come > > out of reset, they're running whatever was loaded (for instance, they > > can load %cs on the BSC so that it starts somewhere other than the > > architecturally-defined segment right below 4GiB). While cool in some > > ways ("I don't have to train DRAM? Score!") the PSP is embedded in the > > SoC and the firmware is a signed blob you get from AMD. I know there's > > an ARM Cortex-A5 in there, but don't know much more about it and even > > if I did, I have no way to generate signed images for it. :-/ > > > > The point is, even if you've got a completely open stack running on > > x86 from the reset vector, there's almost certainly something else > > somewhere that's not open (yet). > > Or there's something running on a completely different x86 core with > unpatched securiy bugs in the Minix and Apache cores that you can't > even disable (unless you are the National Security Agency).... Sadly, > Intel refuses to make it available the magic bits to disable the Intel > ME to anyone else. :-( ...and let's not even get started on SMM. :-( - Dan C. From crossd at gmail.com Thu Jan 4 05:35:00 2024 From: crossd at gmail.com (Dan Cross) Date: Wed, 3 Jan 2024 14:35:00 -0500 Subject: [TUHS] Sad news: Niklaus Wirth Message-ID: [TUHS as Bcc] I just saw sad news from Bertrand Meyer. Apparently, Niklaus Wirth passed away on the 1st. :-( I think it's fair to say that it is nearly impossible to overstate his influence on modern programming. - Dan C. From arnold at skeeve.com Thu Jan 4 18:42:26 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 04 Jan 2024 01:42:26 -0700 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: <20240103163700.GA136592@mit.edu> References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> <20231231224649.h45pogxycgkgs673@illithid> <20231231230615.GE19322@mcvoy.com> <20240103033345.GA108362@mit.edu> <20240103043036.GB108362@mit.edu> <20240103163700.GA136592@mit.edu> Message-ID: <202401040842.4048gQsN004587@freefriends.org> Things have wandered a little far afield... :-) "Theodore Ts'o" wrote: > Or there's something running on a completely different x86 core with > unpatched securiy bugs in the Minix and Apache cores that you can't > even disable (unless you are the National Security Agency).... Sadly, > Intel refuses to make it available the magic bits to disable the Intel > ME to anyone else. :-( I worked for a number of years in the design center where the firmware and software for the ME were develped. Although it's possible that the firmware developers were sworn to secrecy, I never heard anything about back doors for the NSA or anyone else. Intel took security and code quality in the ME very seriously, and during my tenure the quality of the ME firmware improved a lot. ISTR that the BIOS had settings for disabling the ME. Is that no longer true? I know there are lots of people who despise the ME, which I never understood. It was designed to solve the very real problem of remote PC management, and for that it works. My own feeling is, if you don't want the ME, buy a processor without it; there are plenty from Intel and AMD. Quite seriously, and with no animosity, I'd be happy to learn what I'm missing here. Thanks, Arnold From kevin.bowling at kev009.com Fri Jan 5 04:26:34 2024 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Thu, 4 Jan 2024 11:26:34 -0700 Subject: [TUHS] Question about BSD disklabel history In-Reply-To: <202401040842.4048gQsN004587@freefriends.org> References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> <20231231224649.h45pogxycgkgs673@illithid> <20231231230615.GE19322@mcvoy.com> <20240103033345.GA108362@mit.edu> <20240103043036.GB108362@mit.edu> <20240103163700.GA136592@mit.edu> <202401040842.4048gQsN004587@freefriends.org> Message-ID: On Thu, Jan 4, 2024 at 1:42 AM wrote: > > Things have wandered a little far afield... :-) > > "Theodore Ts'o" wrote: > > > Or there's something running on a completely different x86 core with > > unpatched securiy bugs in the Minix and Apache cores that you can't > > even disable (unless you are the National Security Agency).... Sadly, > > Intel refuses to make it available the magic bits to disable the Intel > > ME to anyone else. :-( > > I worked for a number of years in the design center where the firmware > and software for the ME were develped. Although it's possible that > the firmware developers were sworn to secrecy, I never heard anything > about back doors for the NSA or anyone else. > > Intel took security and code quality in the ME very seriously, > and during my tenure the quality of the ME firmware improved a lot. > > ISTR that the BIOS had settings for disabling the ME. Is that > no longer true? > > I know there are lots of people who despise the ME, which I never > understood. It was designed to solve the very real problem of remote > PC management, and for that it works. My own feeling is, if you don't > want the ME, buy a processor without it; there are plenty from Intel > and AMD. I have tried out the AMT stuff for OS development and it is a mess. I am skeptical anyone seriously uses it. Laptops already have microcontrollers for various functionality so it is hard to see why the already standardized NC-SI and IPMI couldn't be applied to the problem space in some way that is secure, standardized, and doesn't significantly change the BOM cost. For whatever reason, intel makes it difficult to impossible to remove the ME in later generations. It seems more than accidental incompetence since people have figured out how to force it into a brain dead state (coreboot with me_cleaner). It is doubly suspicious that the US government has a killswitch for it that the commercial and general public do not. Which are the intel CPUs without the ME? Just because a CPU doesn't have vPro licensed doesn't mean the ME isn't there. > Quite seriously, and with no animosity, I'd be happy to learn what > I'm missing here. https://en.wikipedia.org/wiki/Intel_Management_Engine has a good enough survey and links to other soruces. It's a complete mess on the NIC too, the firmware on e1000 NICs has all sorts of issues and much of it is related to the insane errata and complexity of transitioning to and fro Management mode and different interpretations of who is responsible for power management. > > Thanks, > > Arnold From tuhs at tuhs.org Fri Jan 5 05:10:02 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 04 Jan 2024 19:10:02 +0000 Subject: [TUHS] [COFF] Intel ME, UEFI, User Control was Re: Question about BSD disklabel history Message-ID: [TUHS bcc, moved to COFF] On Thursday, January 4th, 2024 at 10:26 AM, Kevin Bowling wrote: > For whatever reason, intel makes it difficult to impossible to remove > the ME in later generations. Part of me wonders if the general computing industry is starting to cheat off of the smartphone sector's homework, this phenomenon where whole critical components of a hardware device you literally own are still heavily controlled and provisioned by the vendor unless you do a whole bunch of tinkering to break through their stuff and "root" your device. That I can fully pay for and own a "computer" and I am not granted full root control over that device is one of the key things that keeps "smart" devices besides my work issued mobile at arms length. For me this smells of the same stuff, they've gotten outside of the lane of *essential to function* design decisions and instead have now put in a "feature" that you are only guaranteed to opt out of by purchasing an entirely different product. In other words, the only guaranteed recourse if a CPU has something like this going on is to not use that CPU, rather than as the device owner having leeway to do what you want. Depends on the vendor really, some give more control than others, but IMO there is only one level of control you give to someone who has bought and paid for a complete device: unlimited. Anything else suggests they do not own the device, it is a permanently leased product that just stops requiring payments after a while, but if I don't get the keys, I don't consider myself to own it, I'm just borrowing it, kinda like how the Bell System used to own your telephone no matter how many decades it had been sitting on your desk. My two cents, much of this can also be said of BIOS, UEFI, anything else that gets between you and the CPUs reset vector. Is it a nice option to have some vendor provided blob to do your DRAM training, possibly transition out of real mode, enumerate devices, whatever. Absolutely, but it's nice as an *option* that can be turned off should I want to study and commit to doing those things myself. I fear we are approaching an age where the only way you get reset vector is by breadboarding your own thing. I get wanting to protect users from say bricking the most basic firmware on a board, but if I want to risk that, I should be completely free to do so on a device I've fully paid for. For me the key point of contention is choice and consent. I'm fine having this as a selectable option. I'm not fine with it becoming an endemic "requirement." Are we there yet? Can't say, I don't run anything serious on x86-family stuff, not that ARM and RISC-V don't also have weird stuff like this going on. SBI and all that are their own wonderful kettle of fish. BTW sorry that's pretty rambly, the lack of intimate user control over especially smart devices these days is one of the pillars of my gripes with modern tech. Only time will tell how this plays out. Unfortunately the general public just isn't educated enough (by design, not their own fault) on their rights to really get a big push on a societal scale to change this. People just want I push button I get Netflix, they'll happily throw all their rights in the garbage over bread and circuses....but that ain't new... - Matt G. From tuhs at tuhs.org Fri Jan 5 10:55:59 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 05 Jan 2024 00:55:59 +0000 Subject: [TUHS] 1998 UNIX RTR Reference Manual (And Other 5ESS-2000/3B20D Stuff) Message-ID: Got some exciting stuff in the mail today, and for once it isn't going to amount to sitting in front of a scanner for hours: https://archive.org/details/5ess-switch-dk5e-cd-1999-05 After the link is the April/May 1999 issue of the 5ESS-Switch DK5E-CD, a collection of documents and schematics concerning the 5ESS-2000 variant of the 5ESS switch, as supported at the time by Lucent-Bell Labs. Of particular UNIX interest is the following: https://ia601200.us.archive.org/view_archive.php?archive=/12/items/5ess-switch-dk5e-cd-1999-05/5ESS-DK5E.zip&file=5EDOCS%2F93447.PDF This is the November 1998 issue of the 5ESS-2000 Switch UNIX RTR Operating System Reference Manual (235-700-200, Issue 7.00). From the text it appears to be a descendant of the standard UNIX literature, although it only contains the intro, basic info, section 1, as well as a section on administration as well as an EMACS paper. It alludes to a more complete manual although I have not located that in this document collection (granted I'm busy on a work thing right now, just taking the time to upload and spread the word ATM.) There's probably plenty of other relevant stuff in there, plus plenty of content regarding the 5ESS and 3B20D generally. These CDs were included with a paper binder of installation and identification info. The binder appears to be largely for training programs and I have yet to verify whether its contents are included in these CDs or the two supplement each other. Either way, this should present plenty of leads on more potential sources of 5ESS, 3B20D, and maybe UNIX RTR stuff. Unfortunately the discs only seem to contain documents, there wasn't the holy grail of a snapshot of UNIX RTR in there that I was kinda hoping might be bumping around. Thus the hunt for 3B20 UNIX continues... - Matt G. P.S. This is a bit more modern than what I've been dealing with generally, hopefully given the current state of 5ESS and Nokia-Bell Labs seeming to be winding things down, that means this isn't a problem to have put up. I just urge caution on any use of this stuff that even remotely smells of commercial activities, but I probably don't have to tell anyone that. Just covering my bases. From tuhs at tuhs.org Fri Jan 5 14:15:46 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 05 Jan 2024 04:15:46 +0000 Subject: [TUHS] 3B2/400 and Documents on eBay Message-ID: Wanted to share this in case anyone is in the market for one. Someone's posted a 3B2/400 to eBay along with many documents and some peripherals and such. Kicker is it's $2,000 altogether... https://www.ebay.com/itm/186237940947 Way outside what I'm wiling to sink into one, although a 3B2 would be very nice to have around. Anywho, figured I'd spread the word in case someone in the far flung UNIX-verse is seeking one and has the funds to spare. - Matt G. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aram.h at mgk.ro Fri Jan 5 20:24:37 2024 From: aram.h at mgk.ro (=?UTF-8?B?QXJhbSBIxIN2xINybmVhbnU=?=) Date: Fri, 5 Jan 2024 12:24:37 +0200 Subject: [TUHS] Lost Origins of the Plan 9 C Compiler Message-ID: The Plan 9 C compiler must predate Plan 9 and therefore it must have been created on Research Unix. The v10 manual doesn't mention them, fair enough, they document Unix and not Plan 9, but they do say that rc(1) is the Plan 9 shell... Research Unix of the time ran on VAX. A natural question arises, was VAX the original target of the Plan 9 compilers? Where is it? Why isn't it mentioned anywhere? If VAX was never a target, then what was the original purpose of these compilers and how were they tested on a target that Research Unix never ran on? One might think they might have been used for the Jerq/Blit/DMD-5620, but no, the Unix manual documents a different compiler used for these (which is distinct from the main C compiler). The Plan 9 compilers seems to have appeared out of thin air, but this certainly can't be the case. -- Aram Hăvărneanu From tuhs at tuhs.org Fri Jan 5 20:30:44 2024 From: tuhs at tuhs.org (Tom Ivar Helbekkmo via TUHS) Date: Fri, 05 Jan 2024 11:30:44 +0100 Subject: [TUHS] Lost Origins of the Plan 9 C Compiler In-Reply-To: ("Aram =?utf-8?Q?H=C4=83v=C4=83rneanu=22's?= message of "Fri, 5 Jan 2024 12:24:37 +0200") References: Message-ID: Aram Hăvărneanu writes: > The Plan 9 compilers seems to have appeared out of thin air, but > this certainly can't be the case. I think this may be what you are looking for: http://doc.cat-v.org/bell_labs/new_c_compilers/ -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in computer science. --Alan Kay From aram.h at mgk.ro Fri Jan 5 20:47:50 2024 From: aram.h at mgk.ro (=?UTF-8?B?QXJhbSBIxIN2xINybmVhbnU=?=) Date: Fri, 5 Jan 2024 12:47:50 +0200 Subject: [TUHS] Lost Origins of the Plan 9 C Compiler In-Reply-To: References: Message-ID: > I think this may be what you are looking for: > http://doc.cat-v.org/bell_labs/new_c_compilers/ Since I have worked on a derivative of the Plan 9 C compiler, I assure you I have read all the available papers and documentation about it and they answer none of the questions raised above. -- Aram Hăvărneanu From robpike at gmail.com Fri Jan 5 21:33:52 2024 From: robpike at gmail.com (Rob Pike) Date: Fri, 5 Jan 2024 22:33:52 +1100 Subject: [TUHS] Lost Origins of the Plan 9 C Compiler In-Reply-To: References: Message-ID: You shouldn't dismiss so lightly. The cited document answers the question of the first target, which was the National 32000. It ran on a Sequent multiprocessor, a machine we were thinking about using for other work. So no, it was not created on Research Unix, or at least not for it. We wanted a faster compiler for a number of reasons, and Ken had ideas about that. Because of its architecture, it was easy to port to other RISC architectures, such as the MIPS and SPARC, although both those machines had wrinkles that needed ironing out. -rob On Fri, Jan 5, 2024 at 10:05 PM Aram Hăvărneanu wrote: > > I think this may be what you are looking for: > > http://doc.cat-v.org/bell_labs/new_c_compilers/ > > Since I have worked on a derivative of the Plan 9 C compiler, I > assure you I have read all the available papers and documentation > about it and they answer none of the questions raised above. > > -- > Aram Hăvărneanu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mennis at corvus.net Sat Jan 6 05:16:30 2024 From: mennis at corvus.net (Michaelian Ennis) Date: Fri, 5 Jan 2024 11:16:30 -0800 Subject: [TUHS] Lost Origins of the Plan 9 C Compiler In-Reply-To: References: Message-ID: There is additional context about what was happening at the time in Rob's talk at GopherCon 2016: Rob Pike - The Design of the Go Assembler . Ian On Fri, Jan 5, 2024 at 3:34 AM Rob Pike wrote: > > You shouldn't dismiss so lightly. The cited document answers the question of the first target, which was the National 32000. It ran on a Sequent multiprocessor, a machine we were thinking about using for other work. > > So no, it was not created on Research Unix, or at least not for it. We wanted a faster compiler for a number of reasons, and Ken had ideas about that. Because of its architecture, it was easy to port to other RISC architectures, such as the MIPS and SPARC, although both those machines had wrinkles that needed ironing out. > > -rob > > > On Fri, Jan 5, 2024 at 10:05 PM Aram Hăvărneanu wrote: >> >> > I think this may be what you are looking for: >> > http://doc.cat-v.org/bell_labs/new_c_compilers/ >> >> Since I have worked on a derivative of the Plan 9 C compiler, I >> assure you I have read all the available papers and documentation >> about it and they answer none of the questions raised above. >> >> -- >> Aram Hăvărneanu From steve at quintile.net Sat Jan 6 06:49:49 2024 From: steve at quintile.net (Steve Simon) Date: Fri, 5 Jan 2024 20:49:49 +0000 Subject: [TUHS] plan9 c / vax Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: apple-touch-icon-114x114.png Type: image/png Size: 4011 bytes Desc: not available URL: From falcon at freecalypso.org Sat Jan 6 08:17:23 2024 From: falcon at freecalypso.org (Mychaela Falconia) Date: Fri, 05 Jan 2024 14:17:23 -0800 Subject: [TUHS] Original print of V7 manual? Message-ID: <20240105221729.371EA37401DA@freecalypso.org> Hello fellow lovers of old UNIX, Would anyone happen to have a raster scan (not OCR) of the original printing of UNIX Programmer's Manual, 7th edition? Does such a thing exist? Given that Brian S. Walden produced and published a PDF reprint of this manual (presumably done with some "modern" version of troff) back in 1998, I reason that there probably wasn't much interest in preserving the original print by painstaking scanning (and the files from such a scan would have been ginormous by 1998 standards), hence I am not certain if such a scanned version exists - but I thought I would ask nonetheless. I was however very pleased to discover that some very kind soul named Erica Fischer did scan and upload the complete set of Usenix printed books for 4.2BSD and 4.3BSD - here is the 4.2BSD version: https://archive.org/details/uum-ref-4.2bsd https://archive.org/details/uum-supplement-4.2bsd https://archive.org/details/upm-ref-4.2bsd https://archive.org/details/upm-supplement-4.2bsd https://archive.org/details/smm-4.2bsd and here is 4.3BSD: https://archive.org/details/uum-ref-4.3bsd https://archive.org/details/uum-supplement-4.3bsd https://archive.org/details/upm-ref-4.3bsd https://archive.org/details/upm-sup1-4.3bsd https://archive.org/details/upm-sup2-4.3bsd https://archive.org/details/smm-4.3bsd https://archive.org/details/uum-index-4.3bsd It is my understanding that all supplementary docs (the papers that were originally in volumes 2a and 2b in the V7 manual) were retroffed by UCB/Usenix for 4.3BSD edition, but the earlier 4.2BSD Usenix print seems to be different - it looks like for 4.2BSD they only did a new troff run for all man pages and for new (Berkeley-added) supplementary docs, but in the case of docs which originally appeared in V7 vol 2, it appears that Usenix did some kind of analogue mass reproduction from a historical V7 master, *without* doing a new troff run on those docs. *If* this hypothesis is correct, then Erica's uploaded scan of 4.2BSD manuals can serve as a practical substitute for the presumably- missing scan of the original printing of V7 manual - but I would like to double-check my hypothesis with others who are presumably more knowledgeable about this ancient history (some of you actually lived through that history, unlike me!), hence the reason for this post. I would appreciate either confirmation or correction of the guesses and conjectures I expressed above. M~ From tuhs at tuhs.org Sat Jan 6 09:19:15 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 05 Jan 2024 23:19:15 +0000 Subject: [TUHS] Original print of V7 manual? In-Reply-To: <20240105221729.371EA37401DA@freecalypso.org> References: <20240105221729.371EA37401DA@freecalypso.org> Message-ID: On Friday, January 5th, 2024 at 2:17 PM, Mychaela Falconia wrote: > Hello fellow lovers of old UNIX, > > Would anyone happen to have a raster scan (not OCR) of the original > printing of UNIX Programmer's Manual, 7th edition? Does such a thing > exist? > > M~ I'm not aware of any existing scans. I do, however, have on hand for about one more day a nearly original V7 manual set, both volumes, that I'm fairly certain were used with 4.1BSD, as they also include Vol 2C (albeit the rest of Vol 2 is one volume, no actual 2A 2B split, dunno how that plays in.) Additionally, the Volume 1 has some changes, mostly additions like the RAND editor, I'm pretty sure od(1) was the only base page replaced. I mention I have access to this for a day because I'm quite tardy on mailing these to Jacob Ritorto, another list member, and I don't want to keep kicking the can down the road, already delayed a few times. In any case, there's a second Volume 2 binder, also V7, that I donated to the bookshelf in the compsci lounge of the local university, I can always go check that back out and take any scans that would help. Would just be Volume 2 stuff but that represents much more typographical variety. I additionally have an almost complete Usenix 4.2BSD set, just missing the Programmer's Reference Guide, so if you're interested in any visual inspections between the two, happy to sit down at my desk with the magnifying glass tonight and see if I can help out with what you're working on. - Matt G. From will.senn at gmail.com Sat Jan 6 10:12:09 2024 From: will.senn at gmail.com (Will Senn) Date: Fri, 5 Jan 2024 18:12:09 -0600 Subject: [TUHS] Original print of V7 manual? In-Reply-To: References: <20240105221729.371EA37401DA@freecalypso.org> Message-ID: I have a set... 2 volumes - they look like phone books. Dunno if it’s “original” printing, but it seems like it’s got v7 only stuff. Bought it on amazon, used, several years back. If anyone’s gung ho about scanning them, I’d be up for contributing them (with the expectation of getting the scans). Will Sent from my iPhone > On Jan 5, 2024, at 5:19 PM, segaloco via TUHS wrote: > >> On Friday, January 5th, 2024 at 2:17 PM, Mychaela Falconia wrote: >> >> >> Hello fellow lovers of old UNIX, >> >> Would anyone happen to have a raster scan (not OCR) of the original >> printing of UNIX Programmer's Manual, 7th edition? Does such a thing >> exist? >> >> M~ > > I'm not aware of any existing scans. I do, however, have on hand for about one more day a nearly original V7 manual set, both volumes, that I'm fairly certain were used with 4.1BSD, as they also include Vol 2C (albeit the rest of Vol 2 is one volume, no actual 2A 2B split, dunno how that plays in.) Additionally, the Volume 1 has some changes, mostly additions like the RAND editor, I'm pretty sure od(1) was the only base page replaced. I mention I have access to this for a day because I'm quite tardy on mailing these to Jacob Ritorto, another list member, and I don't want to keep kicking the can down the road, already delayed a few times. > > In any case, there's a second Volume 2 binder, also V7, that I donated to the bookshelf in the compsci lounge of the local university, I can always go check that back out and take any scans that would help. Would just be Volume 2 stuff but that represents much more typographical variety. > > I additionally have an almost complete Usenix 4.2BSD set, just missing the Programmer's Reference Guide, so if you're interested in any visual inspections between the two, happy to sit down at my desk with the magnifying glass tonight and see if I can help out with what you're working on. > > - Matt G. Sent from my iPhone > On Jan 5, 2024, at 5:19 PM, segaloco via TUHS wrote: > > On Friday, January 5th, 2024 at 2:17 PM, Mychaela Falconia wrote: > > >> Hello fellow lovers of old UNIX, >> >> Would anyone happen to have a raster scan (not OCR) of the original >> printing of UNIX Programmer's Manual, 7th edition? Does such a thing >> exist? >> >> M~ > > I'm not aware of any existing scans. I do, however, have on hand for about one more day a nearly original V7 manual set, both volumes, that I'm fairly certain were used with 4.1BSD, as they also include Vol 2C (albeit the rest of Vol 2 is one volume, no actual 2A 2B split, dunno how that plays in.) Additionally, the Volume 1 has some changes, mostly additions like the RAND editor, I'm pretty sure od(1) was the only base page replaced. I mention I have access to this for a day because I'm quite tardy on mailing these to Jacob Ritorto, another list member, and I don't want to keep kicking the can down the road, already delayed a few times. > > In any case, there's a second Volume 2 binder, also V7, that I donated to the bookshelf in the compsci lounge of the local university, I can always go check that back out and take any scans that would help. Would just be Volume 2 stuff but that represents much more typographical variety. > > I additionally have an almost complete Usenix 4.2BSD set, just missing the Programmer's Reference Guide, so if you're interested in any visual inspections between the two, happy to sit down at my desk with the magnifying glass tonight and see if I can help out with what you're working on. > > - Matt G. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aek at bitsavers.org Sat Jan 6 11:06:19 2024 From: aek at bitsavers.org (Al Kossow) Date: Fri, 5 Jan 2024 17:06:19 -0800 Subject: [TUHS] Original print of V7 manual? In-Reply-To: <20240105221729.371EA37401DA@freecalypso.org> References: <20240105221729.371EA37401DA@freecalypso.org> Message-ID: On 1/5/24 2:17 PM, Mychaela Falconia wrote: > Hello fellow lovers of old UNIX, > > Would anyone happen to have a raster scan (not OCR) of the original > printing of UNIX Programmer's Manual, 7th edition? Does such a thing > exist? I have volume 2 of the published version 0-03-061742-1 and  0-03-061742-x on bitsavers http://bitsavers.org/pdf/att/unix/7th_Edition Earlier internal versions exist. Volume 1 appears to be well over $100 now on the used book market. From falcon at freecalypso.org Sat Jan 6 11:26:26 2024 From: falcon at freecalypso.org (Mychaela Falconia) Date: Fri, 05 Jan 2024 17:26:26 -0800 Subject: [TUHS] Original print of V7 manual? In-Reply-To: References: <20240105221729.371EA37401DA@freecalypso.org> Message-ID: <20240106012631.D984037403FB@freecalypso.org> Hi Matt, Thank you for taking the time to respond to my odd inquiry! > In any case, there's a second Volume 2 binder, also V7 [...] > Would just be Volume 2 stuff but that represents much more typographical > variety. > > I additionally have an almost complete Usenix 4.2BSD set, just missing the > Programmer's Reference Guide, so if you're interested in any visual > inspections between the two, happy to sit down at my desk with the magnifying > glass tonight and see if I can help out with what you're working on. The main thing I am looking for is either confirmation or refutation of my hypothesis that those Vol2 docs that aren't Berkeley-new have remained entirely unchanged (and *not* retroffed) between V7 and 4.2BSD Usenix print. Perhaps flip through a few randomly selected docs and see if all page breaks line up exactly or not - when UCB/Usenix retroffed these docs for 4.3BSD, they used a newer typesetter (APS-5) driven by a slightly newer troff (early ditroff), and the font metrics are different enough to displace line breaks and page breaks throughout the corpus of the text. Also if you have time, here are some specific spots in V7 Vol2 which I would appreciate getting looked at: * Vol 2a doc 8, "Typing Documents on the UNIX System", M. E. Lesk: the last page of this paper exhibits a "Figure 1" drawing that appears to have been done literally by hand, with someone taking a pen (or pencil or whatever other handwriting implement) to the output of the typesetter (was it photographic paper that had to be developed first?) and drawing the figure, before the resulting master was then used for mass reproduction. In Erica's scan of 4.2BSD UNIX User's Manual Supplementary docs book, this hand drawing appears on page 346. Does it look exactly the same in V7 original? * Vol 2a doc 12, "NROFF/TROFF User's Manual", J. F. Ossanna - please look at the following details: - in Table I (Font Style Examples), is the square character hollow in all 3 fonts (like in 4.2BSD print), or is it filled in bold or in any other font? - the two pointing hand characters in Special Mathematical Font, do they look exactly the same between V7 and 4.2BSD? - if you spot any other diffs, please let me know! * Vol 2a doc 13, "A TROFF Tutorial", B. W. Kernighan: is there a final page titled "Appendix A: Phototypesetter Character Set", or is it missing? This page comes from ttcharset troff source file, it is included in Brian S. Walden's 1998 PDF reprint, but it is missing in both 4.2BSD and 4.3BSD prints from Usenix. - If this Appendix A page is included, how does \(sq look? Is it hollow in the main table but filled in bold, or is hollow in both places? (Or something else?) * Vol 2a doc 16, "Make - A Program for Maintaining Computer Programs", S. I. Feldman: first of all, do page breaks line up perfectly between V7 and 4.2BSD prints? If they do, please look at the top of page labeled "- 6 -": there is a drawing that was apparently done by hand, similarly to the one in the -ms document, although this one is a bit simpler. Does it look like the drawing in 4.2BSD version is exactly the same as in V7? * Vol 2b doc 31, "UNIX Implementation", K. Thompson: does it look exactly the same between V7 and 4.2BSD? Do all page breaks line up? There is Fig 1 on page 2 and Fig 2 on page 8 - do they look the same between the two prints? Once again, it is a mystery to me how these two figures were produced originally: pic didn't exist yet, and the troff source only leaves blank space for each figure. But they don't look hand-drawn either - so how were they made... Finally, in Volume 1 - how does eqnchar(7) page look in the original V7 version? The version in 4.2BSD print was clearly retroffed anew, as the date in the footer is 1983 - so I wonder how the original V7 version looked. Is the "blot" character a black filled square, or is it something else? Are "square" and "circle" just above it both hollow? TIA for all this scrutiny, Your resident troff nut Mychaela From tuhs at tuhs.org Sat Jan 6 11:45:08 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sat, 06 Jan 2024 01:45:08 +0000 Subject: [TUHS] Original print of V7 manual? In-Reply-To: References: <20240105221729.371EA37401DA@freecalypso.org> Message-ID: On Friday, January 5th, 2024 at 5:06 PM, Al Kossow wrote: > > Volume 1 appears to be well over $100 now on the used book market. First Al welcome back, sorry I'm an idiot that caused some animosity in the past, we're working towards the same goal and I'm glad to see your name around here again. Second, I've got paper copies of both HRW volumes, I would more than happily cover shipping both ways if you'd be interested in the Volume 1 to add with this. Your scan facilities are much more sophisticated than mine. My only condition is a non-destructive scan, I would want it back afterwards. Otherwise if there's interest I can add it to my own backlog just remember I'm scanning on a crappy little Canon LiDE scanner from Goodwill. It's all I've got, not humming and hawing around until I get the perfect setup to take care of business. Anywho, Mychaela thanks for the thorough inquiry, I'm glad you've thought out what it is you're seeking already, makes it much easier to pipeline it. While I'm at it I'll also satisfy my own curiosity and note whether the discrepancies you're noting are also apparent in some way in Release 3.0 and 4.0 print materials vs Version 7. AFAIK pretty much everything had been remastered by the time System V rolled around, I'm fairly certain the osdd macro package was used for those, my understanding of osdd macros were that they were used for producing more "BSP-ish" typesetting of papers, what with a select code, issue number, and date in the upper right, fonts that align with BSPs, etc. Release 4.0 is the last one in the USG/PWB line, to my understanding, liable to have pages in the print documents taken from the same plates that go back to V7 (except for the AT&T branded Release 4.0-ish "Starter Packages", still haven't found these in the wild.) More to come! - Matt G. From falcon at freecalypso.org Sat Jan 6 13:02:48 2024 From: falcon at freecalypso.org (Mychaela Falconia) Date: Fri, 05 Jan 2024 19:02:48 -0800 Subject: [TUHS] Original print of V7 manual? In-Reply-To: References: <20240105221729.371EA37401DA@freecalypso.org> Message-ID: <20240106030254.B8D7537401FF@freecalypso.org> Al Kossow wrote: > I have volume 2 of the published version 0-03-061742-1 and\u00A0 > 0-03-061742-x on bitsavers > http://bitsavers.org/pdf/att/unix/7th_Edition Thank you for this very interesting bit! My observations: * It would have been impossible for this entire book to be troffed in the same timeframe on the same setup. In the font sample on page 226 (original page number, PDF page 235) the \(sq character is hollow in all 3 fonts, but on page 244 (the page that is missing in 4.2BSD and 4.3BSD prints) \fB\(sq\fP (the same character in the same Bold font) is a filled square - and the fact that the author of the document (bwk) explicitly called it out indicates that this property of \fB\(sq\fP existed at the time of writing. * My hypothesis is that Ossanna's original troff document was troffed some time around the date of its authorship (1976-10-11), and at that time the font set on Bell Labs' Graphic Systems typesetter had a hollow square for \(sq in all 3 fonts. At some point between 1976-10-11 and 1978-08-04 (authorship date of bwk's troff tutorial document), the font set on the very same Graphic Systems typesetter was updated to a newer version that had \(sq as a filled square in Times Bold font - and bwk's doc specifically shows this character in regular and bold, when all others were shown only in regular. Furthermore, the design of /usr/pub/eqnchar was made at the time of \fB\(sq\fP being a filled square, as this construct is used for the "blot" made-up character. * The production of the complete book must have included some clever touch-up, as far as page headers/footers go. The document-local page numbers have been removed, and instead each page has a continuous (across the book) page number on it. It would have been impossible to do a single troff run across all those diverse documents, hence I can only reason that the addition of those book-wide page numbers (and removal of original "local" ones) must have been a post-troff touch-up. Plus the font difference: the newly applied headers/footers with page numbers and document names are in a sans-serif font clearly different from the text body. What was the physical form of this book? Was it a "perfect bound" book? Comb binding like BSD books? Or was it just a 3-ring binder which anyone could open and add/remove pages easily? This is a part of early UNIX history which I am ignorant about, hence I would love to be educated. Was the "original" V7 manual printed (provided to licensees?) in a form where one could "easily" (without ripping apart a fully bound book) extract individual pages and reuse them in a different compilation, like Usenix presumably did for 4.2BSD? Was the "original" V7 manual available with each document page bearing only a "local" in-document page number, rather than an across-the-book one like in Al's version? M~ From g.branden.robinson at gmail.com Sat Jan 6 13:22:36 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Fri, 5 Jan 2024 21:22:36 -0600 Subject: [TUHS] Original print of V7 manual? In-Reply-To: <20240106030254.B8D7537401FF@freecalypso.org> References: <20240105221729.371EA37401DA@freecalypso.org> <20240106030254.B8D7537401FF@freecalypso.org> Message-ID: <20240106032236.llpryldqt7lbondn@illithid> At 2024-01-05T19:02:48-0800, Mychaela Falconia wrote: > * My hypothesis is that Ossanna's original troff document was troffed > some time around the date of its authorship (1976-10-11), and at that > time the font set on Bell Labs' Graphic Systems typesetter had a > hollow square for \(sq in all 3 fonts. At some point between > 1976-10-11 and 1978-08-04 (authorship date of bwk's troff tutorial > document), the font set on the very same Graphic Systems typesetter > was updated to a newer version that had \(sq as a filled square in > Times Bold font - and bwk's doc specifically shows this character in > regular and bold, when all others were shown only in regular. > Furthermore, the design of /usr/pub/eqnchar was made at the time of > \fB\(sq\fP being a filled square, as this construct is used for the > "blot" made-up character. My belief, based on the evidence I have from these publications colophons reporting which phototypesetter was used, is that the \(sq special character was not filled in Graphic Systems C/A/T fonts used by Bell Labs, but _was_ filled in the bold face by the Autologic APS-5. I have documented this understanding in the groff_char(7) man page, so if it is incorrect, for could be made more precise, I would appreciate finding out. Also, my copies of these books are overseas, but I seem to remember that the Holt/Reinhart/Winston (HRW) 1983 reprint of the Seventh Edition Programmer's Manual also featured an additional article on bibliography preparation. (The original white paper on "refer" was pretty rough going for a normal user, and primarily concerned with hash map implementation performance. Bill Tuthill's paper in BSD is much more tractable.) > What was the physical form of this book? Was it a "perfect bound" > book? The HRW copies I have are perfect bound. But I can't remember if they were 3-hole punched as well. Where did you discover the identity and date of the 1998 retypeset of the V7 Volume 2 manual? I have wondered about this for years. In part to complain, because while it is a _fairly_ faithful reproduction of the original, it is not perfect, and this has led to some arguments on the groff mailing list with people who impute excessive authority to it. (I guess they couldn't see the little hollow gray boxes where the PostScript renderer had no defined character, if we're talking about the same document.) Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From jsg at jsg.id.au Sat Jan 6 14:06:03 2024 From: jsg at jsg.id.au (Jonathan Gray) Date: Sat, 6 Jan 2024 15:06:03 +1100 Subject: [TUHS] Original print of V7 manual? In-Reply-To: <20240106032236.llpryldqt7lbondn@illithid> References: <20240105221729.371EA37401DA@freecalypso.org> <20240106030254.B8D7537401FF@freecalypso.org> <20240106032236.llpryldqt7lbondn@illithid> Message-ID: On Fri, Jan 05, 2024 at 09:22:36PM -0600, G. Branden Robinson wrote: > Where did you discover the identity and date of the 1998 retypeset of > the V7 Volume 2 manual? I have wondered about this for years. In part > to complain, because while it is a _fairly_ faithful reproduction of the > original, it is not perfect, and this has led to some arguments on the > groff mailing list with people who impute excessive authority to it. > > (I guess they couldn't see the little hollow gray boxes where the > PostScript renderer had no defined character, if we're talking about the > same document.) Brian Walden's notes on creating them: http://web.archive.org/web/20080217213120/http://plan9.bell-labs.com/7thEdMan/bswv7.html http://web.cuzuco.com/~cuzuco/v7/ CreationDate in the pdfs is 1998 From falcon at freecalypso.org Sat Jan 6 14:06:36 2024 From: falcon at freecalypso.org (Mychaela Falconia) Date: Fri, 05 Jan 2024 20:06:36 -0800 Subject: [TUHS] Original print of V7 manual? In-Reply-To: <20240106032236.llpryldqt7lbondn@illithid> References: <20240105221729.371EA37401DA@freecalypso.org> <20240106030254.B8D7537401FF@freecalypso.org> <20240106032236.llpryldqt7lbondn@illithid> Message-ID: <20240106040642.D949B37403C1@freecalypso.org> G. Branden Robinson wrote: > My belief, based on the evidence I have from these publications > colophons reporting which phototypesetter was used, is that the \(sq > special character was not filled in Graphic Systems C/A/T fonts used by > Bell Labs, I disagree. While the "NROFF/TROFF User's Manual" document proves that \(sq was hollow in all 3 fonts _as of 1976-10-11_ (the original date of this doc), bwk's document from 1978-08-04 indicates that this char had to have changed to a filled square by this date. However, troff in 1978 was still completely, utterly incapable of driving anything other than a C/A/T! Now bwk, the author of this doc, is the very same fine gentleman who wrote ditroff, the creature that was finally capable of driving a Linotron 202 or Autologic APS-5 or whatever - but the timeline does not match up. BWK's troff tutorial is dated 1978-08-04, but his work on ditroff (as I understand it) happened some time around 1980 or 1981. He may have started ditroff work in 1979, but definitely not in 1978. > but _was_ filled in the bold face by the Autologic APS-5. 4.3BSD Usenix books prove otherwise: these must have been troffed on APS-5, as many notes from that time attest, but they feature hollow square in bold. Even eqnchar(7) is "wrong" in 4.3BSD print in that "blot" is a hollow square, clearly counter to original intent of that named eqn character. > I have documented this understanding in the groff_char(7) man page, Ahh, so you are involved with groff - got it. I wrote my own version of troff (based on V7, running under 4.3BSD and directly emitting DSC-conforming PostScript) in 3 "bursts" of work around 2004, 2010 and 2012, but I never got around to releasing it. I am now in the process of cleaning it up for release, hoping to finally have it out in another week or two. And I put a _lot_ of work into replicating the original troff character set... > Also, my copies of these books are overseas, but I seem to remember that > the Holt/Reinhart/Winston (HRW) 1983 reprint of the Seventh Edition Thank you for clarifying what HRW is - so this 1983 version of 7th ed UPM is *not* the original? > > What was the physical form of this book? Was it a "perfect bound" > > book? > > The HRW copies I have are perfect bound. But I can't remember if they > were 3-hole punched as well. Thank you for the clarification! But if HRW version is not the original, then what was the original like? > Where did you discover the identity and date of the 1998 retypeset of > the V7 Volume 2 manual? https://plan9.io/7thEdMan/bswv7.html http://web.cuzuco.com/~cuzuco/v7/ The second page includes a link to this tarball: http://web.cuzuco.com/~cuzuco/v7/v7add.tar.gz Dates inside that tarball are 1998-12-13. There was also a place where Brian missed the retroffing date - see page 287 of his v7vol2a.pdf. > I have wondered about this for years. In part > to complain, because while it is a _fairly_ faithful reproduction of the > original, it is not perfect, What _I_ don't like about BSW's PDF rendition of V7 manuals is that it is a sort of "closed source" product: there is no published source package that retraces every step in the flow from ancient troff sources to the finished product. In the same 3 "bursts" of activity (2004, 2010 and 2012) when I worked on my own version of troff, I also worked toward doing a PostScript reprint of 4.3BSD Usenix books. 4.3BSD happens to be my personally preferred version of UNIX, but the same methods I use for 4.3BSD books can also be applied to V7. I am hoping that in the next week or two I will find time to release not only my version of troff, but also the partial set of 4.3BSD books I got done so far. Out of the 7 books that comprise 4.3BSD Usenix set, the breakdown is as follows: * URM, PRM and USD: I got these done already, only need to write new colophons to be added to the end of each book. These are the ones I am hoping to put out Real Soon Now. * PS1, PS2 and SMM remain to be worked on, but are part of my more distant plans. * The "Master Index" volume, I plan to skip that one - too difficult, and non-essential in my view. And yes, I am much more "perfectionist" about replicating troff details than BSW was for his V7 PDF version. M~ From tuhs at tuhs.org Sat Jan 6 15:08:28 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sat, 06 Jan 2024 05:08:28 +0000 Subject: [TUHS] Original print of V7 manual? In-Reply-To: <20240106012631.D984037403FB@freecalypso.org> References: <20240105221729.371EA37401DA@freecalypso.org> <20240106012631.D984037403FB@freecalypso.org> Message-ID: Alright here's some commentary on and pictures of key pieces (I'll make reference to USG/PWB stuff in here too, but don't have pictures, 4.0 and 5.0/System V docs are scanned, variations on System III docs as well, can point those out to you if needed): > * Vol 2a doc 8, "Typing Documents on the UNIX System", M. E. Lesk: the > last page of this paper exhibits a "Figure 1" drawing that appears to > have been done literally by hand ... > ... this hand drawing appears on page 346. Does it look exactly > the same in V7 original? https://i.imgur.com/CiUz01n.jpg - V7 left, 4.2BSD right https://i.imgur.com/i8uxEbv.jpg - V7 revised left, V7 right The V7 and 4.2BSD pages are closer than the V7 and V7 HRW Revised edition. Most noticeably there is some schmutz there around RP that is in both V7 and 4.2BSD, but not the HRW version. This paper is not in the USG/PWB 3.0 and onward stuff, MM is fully entrenched as the standard macro package in that lineage. There is a Typing Documents with MM but this is a little foldout reference card. > * Vol 2a doc 12, "NROFF/TROFF User's Manual", J. F. Ossanna - please > look at the following details: > > - in Table I (Font Style Examples), is the square character hollow in > all 3 fonts (like in 4.2BSD print), or is it filled in bold or in any > other font? > > - the two pointing hand characters in Special Mathematical Font, do > they look exactly the same between V7 and 4.2BSD? https://i.imgur.com/k3OflK4.jpg - 4.2BSD left, V7 right https://i.imgur.com/ZBPj8kK.jpg - V7 left, V7 revised right Nothing really jumps out at me as significantly different. The smaller pressing on the Usenix stuff makes some of the busier characters (e.g. copyright) look pretty filled in, but this may not represent a difference in exposures of original plates. The pointing characters are likely the same, but the smaller pressing makes it quite difficult to see the cuffs clearly, in my physical copy of 4.2BSD it's barely intelligible that there's a cuff on the left hand. For the record, the System III's Table 1 looks pretty shoddy, like a several generations removed photocopy of the V7 version. Release 4.0's table I think reflects Bell's shift into ditroff territory, as it has wholly new fonts, and now the Special Mathematical Font is noted as prepared by Wang Laboratories, Inc. rather than Graphic Systems, Inc., reflecting the purchase of GSI by Wang. The System V document drops this font table entirely. > * Vol 2a doc 13, "A TROFF Tutorial", B. W. Kernighan: is there a final > page titled "Appendix A: Phototypesetter Character Set" ... missing in > both 4.2BSD and 4.3BSD prints from Usenix. > > - If this Appendix A page is included, how does \(sq look? Is it > hollow in the main table but filled in bold, or is hollow in both > places? (Or something else?) https://i.imgur.com/cDpAXTS.jpg - V7 single shot https://i.imgur.com/iHKuuYE.jpg - V7 left, V7 revised right Bold square is filled, regular is hollow in both printings. Nothing I can spot that really tells them apart. The story is the the same with System III, just a kinda fuzzier later generation from the same plate. Gotta remind myself anything being distributed in earnest as "System III" is a few years down the line from V7, probably not worth it to try and go find the plates and make really clean copies again. The page in Release 4.0 is revamped, and also reflects the new font, along with additional characters and details, although the square fill/no-fill is the same. I can't find a section of the System V Document Processing Guide that resembles A TROFF Tutorial, that specific paper may not be represented in documentation after 4.0. > * Vol 2a doc 16, "Make - A Program for Maintaining Computer Programs", > S. I. Feldman: first of all, do page breaks line up perfectly between > V7 and 4.2BSD prints? If they do, please look at the top of page > labeled "- 6 -": there is a drawing that was apparently done by hand, > similarly to the one in the -ms document, although this one is a bit > simpler. Does it look like the drawing in 4.2BSD version is exactly > the same as in V7? https://i.imgur.com/ZihxD0P.jpg - V7 left, 4.2BSD right Nothing noticeably different, same is true with V7 revised, didn't bother to take a picture. Same in System III. Release 4.0 once again is changed with the new typesetter. This changes yet again in System V. Here's a picture since this is the one of that lot not scanned yet: https://i.imgur.com/C0Hm9DO.jpeg > * Vol 2b doc 31, "UNIX Implementation", K. Thompson: does it look > exactly the same between V7 and 4.2BSD? Do all page breaks line up? > There is Fig 1 on page 2 and Fig 2 on page 8 - do they look the same > between the two prints? https://i.imgur.com/fpYnC0S.jpg - Fig. 1, V7 left, 4.2BSD right https://i.imgur.com/KfZbhSB.jpg - Fig. 2, Same Arrangement No noticeable difference, same is true of the HRW volumes. I only have System III Volume 2A, this is a 2B paper so can't vouch for it, although there's a Plexus System III Volume 2B on bitsavers that I believe contains papers that are also BTL typesetting exposures, just packed in with some fluff from Plexus. These diagrams do appear to be revamped for Release 4.0, and like A TROFF Tutorial I don't think there's a variation on this paper included with the System V set. It's a bit complicated with those since they in some cases broke down the barriers between different documents, merged them together, dropped some pieces, added some others...etc, the transformation from Release 4.0 to System V pretty much brought an end to the conventional papers format and ushered in the style of the commercial era literature. > Finally, in Volume 1 - how does eqnchar(7) page look in the original > V7 version? The version in 4.2BSD print was clearly retroffed anew, > as the date in the footer is 1983 - so I wonder how the original V7 > version looked. Is the "blot" character a black filled square, or is > it something else? Are "square" and "circle" just above it both > hollow? https://i.imgur.com/bpolKEF.jpg - 4.2BSD left, V7 right https://i.imgur.com/QmaqCe0.jpg - V7 left, V7 HRW right The V7 and 4.2BSD material appears to originate from the same plate, although the V7 and V7 revised are noticeably different. For instance, note the change in size of the blot square. Goodness gracious did the situation lead to a little rabbit hole with the USG/PWB line: https://i.imgur.com/NH4hk8c.jpeg - 3.0 left, 4.1 middle, 5.0 right https://i.imgur.com/xVQVOMu.jpeg - System V (DEC, 3B20) left, System V (3B5) middle, SVR2 (HRW) right So Release 3.0 looks a lot like the original V7 stuff, but then into 4.1 and 5.0, instead you see the larger blot symbol and addition of scrL, among other differences. However, both System V documents, while having for instance the addition of scrL, *also* have the smaller blot symbol that hasn't been in this documentation line since probably 3.0. This isn't the only thing like this, for instance the System V variants refer to a "UNIX (System) User Guide" but then the Release (i.e. internal) stuff has "UNIX (System) User's Guide". There are other such very, very minor discrepancies between the USG internal releases and the published System V stuff, almost as if they technically split earlier and were just cross-pollinating since, but what strikes me as odd is 4.1 does get the updated blot character, so System V not having it was either a regression in the document typesetting *or* evidence that whatever became the System V eqnchar(5) page shares a separate branch point from 3.0 than that seen in 4.1 and 5.0. Speculation though, can't say for sure, it's just...odd... Finally, you'll note that the page in the HRW book is goofed, none of the characters are actually there, just a copy of the string invoking them. Whoops, it happens. > What was the physical form of this book? Was it a "perfect bound" > book? Comb binding like BSD books? Or was it just a 3-ring binder > which anyone could open and add/remove pages easily? Here are some angled shots of some of these books, some of the stuff scans and cover pictures don't really catch: https://i.imgur.com/tQ7wP80.jpeg - V7 HRW https://i.imgur.com/plKh9Ji.jpeg - 4.2BSD Usenix (Not first editions, those apparently had white combs?) https://i.imgur.com/0ONBep9.jpeg - System III Volume 2A and Release 4.0 Starter Packages https://i.imgur.com/hM7F0R4.jpeg - System V various bindings Anything research V7 and back was largely just papers in ringed binders or report covers. I've seen some pictures of literature in Bell Labs report covers of similar motif to the Release 3.0 manual cover (Saul Bass logo, blue/yellow stripe) with a window to see the titlepage through. Dunno if that was something commonly done or just someone's copy for their desk they put together with available covers. V8 was a comb bound manual, V9 appears to be a hard cover (Doug M. sent me a cover scan for the wiki), and external V10 at least were perfect bound. BSD documentation was largely similar to research documentation until the Usenix run. There were a limited number of 4.1BSD documents printed on both blank-covered and Bell Labs-covered comb-bound media for a particular Bell Labs group, these also include the Marx supplement. Other folks here can probably tell you oodles more about that stuff. 4.2 is then the start of the Usenix manuals, although it is also quite common for loose/binder distribution at this time as well, same for 4.3BSD. That compsci lounge bookshelf has a few 4.3BSD binders that look old enough, they've got that V7 volume 2 keeping them company now. Finally, 4.4BSD documents were perfect bound by O'Reilly. I believe at least some USG Program Generic documentation was comb bound in the 70s. The only specimen I know of is a document describing the kernel routines in Program Generic II. Available CB-UNIX documentation appears to be papers in binders. Early PWB I'm fairly certain was also distributed like this, although I have some curiosity if the publication quality improved somewhat with PWB 2.0 as there is a quite nice bibliography document from around that time with a nicely made cover in maroon with the Saul Bass logo among other things. If a bibliography got such nice treatment, maybe the manuals handed out to employees did as well, but I wasn't there. PWB 3.0, which drops the PWB to become Release 3.0, is then when comb bound is the norm for manuals from USG. However, at this time the supplementary papers are still typically just loose pages in a report cover or binder. As seen above, when WECo goes to distribute this commercially, the secondary volumes were bound in report covers. The large Release 4.0 documentation set was similarly two volumes of papers, but Bell Labs also cut a smaller subset of the documents in the form of two "Starter Packages" geared towards programmers and typists respectively. These as you can see are the large form but comb bound, something I don't think I've seen with other Bell System UNIX stuff. I quite like this format, if I had to travel with these documents this format is what I'd pack in my luggage. Getting on to Release 5.0 and System V, these also featured comb-bound manuals, although the supporting literature was distributed in a few different formats. From the picture above you can see that they shipped binders, perfect bound books (with 7 holes punched in them Bell style), and papers in report covers. Of all the materials, the papers in the report covers look the most "TROFF-ish", the rest are very BSP-ish. For the 3B5 release of System V, WECo opted towards small three ring binders instead, a trend that would continue into SVR2. Internal to Bell Labs, their expanded manual was also a comb-bound issue for System V, just with a different cover, but the BTL issue of SVR2 features a completely different binder, down to the rings, plastic, etc. not even sourced from the same kind as the ones out in the world. Still it was a binder, something that would continue with the red SVR2 and SVR3 binders distributed with ATTIS products. Finally, Bell has some other perfect bound stuff in that the revised V7 manual discussed here is of course bound this way (also with the punched holes, only three of them though) as well as the HRW 5 volume SVR2 set (the one with the metalic alphabet block cover.) There are then SVR3 and SVR4 perfect bound manuals, the former being generally grey with a colorful globe picture bearing "UNIX" in the middle with lines going all over the globe from it, while the latter start off as a series of blue books with a globe and big gold "V" and UNIX superimposed on it. Later SVR4 stuff transitioned to a series of solid color covers and then on to white covers with some small landscape picture (SVR4.2 era pretty sure.) There are other odds and ends but that covers a good chunk of what I'm aware of. > TIA for all this scrutiny, > Your resident troff nut Mychaela Oh I think we've got a few of those :) By the way, this is lots of stuff, thanks for bearing with me, I saw this as an opportunity to attempt to summarize much of what I've learned the past few years about how all of this documentation was produced and presented. That said, I may have parts of the story inaccurate as again, I wasn't there, so apologies for any misrepresentations and corrections to the record are welcome and encouraged! Finally, just because it's worth pointing out, here's comparisons of the binder V7 set covers vs published V7 set covers: Vol 1: https://i.imgur.com/kJ3LcjH.jpg Vol 2: https://i.imgur.com/rdjnrkP.jpg Whew. I'm tapped out. If you have any further questions I'll probably chit chat 1 on 1 but figured it might be good to tie all these threads together in a message on list, especially so I can be corrected, I'm a secondary source after all. - Matt G. From falcon at freecalypso.org Sat Jan 6 16:12:44 2024 From: falcon at freecalypso.org (Mychaela Falconia) Date: Fri, 05 Jan 2024 22:12:44 -0800 Subject: [TUHS] Original print of V7 manual? In-Reply-To: References: <20240105221729.371EA37401DA@freecalypso.org> <20240106012631.D984037403FB@freecalypso.org> Message-ID: <20240106061250.4860437401FF@freecalypso.org> Hi Matt, > Whew. I'm tapped out. Thank you very much for this very awesome work you just did! > Goodness gracious did the situation lead to a little rabbit hole > with the USG/PWB line: Someone else (whoever is more interested in this line) will have to thank you for this portion of the work, but the parts I am happiest for are these: > The V7 and 4.2BSD pages are closer than the V7 and V7 HRW Revised edition. > [...] > The V7 and 4.2BSD material appears to originate from the same plate, > although the V7 and V7 revised are noticeably different. For instance, > note the change in size of the blot square. Thank you for confirming all of my hypotheses here! Thus it appears that: 1) 1983 HRW version of V7 manual is not "the real thing", instead that Holy Original status belongs to the ringed binder version; 2) All non-Berkeley supplementary docs in 4.2BSD Usenix print are from the same plates as Holy Original V7 docs, thus the scans uploaded to archive.org by Ms. Erica Fischer can serve as a perfect reference for exactly how those Holy Original docs looked, for those of us who don't have a physical copy of that Holy Original to look at. Once again, thank you very much for this very awesome work! M~ From amp1ron at gmail.com Sun Jan 7 00:42:41 2024 From: amp1ron at gmail.com (amp1ron at gmail.com) Date: Sat, 6 Jan 2024 09:42:41 -0500 Subject: [TUHS] Original print of V7 manual? In-Reply-To: References: <20240105221729.371EA37401DA@freecalypso.org> Message-ID: <002801da40ae$9b1ce420$d156ac60$@gmail.com> I have a copy of the HRW version of the Unix Programmer's Manual "Revised and Expanded Edition" for the 7th edition. Copyright 1983, 1979 Bell Telephone Laboratories, Incorporated. Perfect bound and 3-hole drilled. It's complete and in almost new condition. No markings at all except for a stamped price ($35.45) on the first inside cover page which is not numbered but is page Roman numeral i. Thankfully I picked it up cheap a few years ago. I only bought it because I could only find Al's bitsavers volume 2 scan online (plus copies of that scan at various other places) and I also wanted volume 1. I'll be glad to send it to Al for scanning. No conditions. Cutting off the spine for scanning is OK with me. And I don't need it sent back to me after scanning. If there's a good scan of it available to me, I'd rather have that than a physical copy that I probably won't be able to find when I need it -- but I've got it on my desk right now. If Al wants this, he can just let me know what address to ship it to. -- Ron Pool From will.senn at gmail.com Sun Jan 7 00:52:48 2024 From: will.senn at gmail.com (Will Senn) Date: Sat, 6 Jan 2024 08:52:48 -0600 Subject: [TUHS] Original print of V7 manual? In-Reply-To: <20240106032236.llpryldqt7lbondn@illithid> References: <20240105221729.371EA37401DA@freecalypso.org> <20240106030254.B8D7537401FF@freecalypso.org> <20240106032236.llpryldqt7lbondn@illithid> Message-ID: On 1/5/24 21:22, G. Branden Robinson wrote: > At 2024-01-05T19:02:48-0800, Mychaela Falconia wrote: >> What was the physical form of this book? Was it a "perfect bound" >> book? > The HRW copies I have are perfect bound. But I can't remember if they > were 3-hole punched as well. I'm a little slow on the uptake here, so if this has been answered later in the thread, apologies. The version I have, is the HRW, 1983, Revised and Expanded set. Volume 1: 0-03-061742-1 Volume 2: 0-03-061743-X It's perfect bound, 3 hole punched, with perforated pages. Volume 1 is missing an ld manpage (not missing as in ripped out, missing as in not printed or indexed in the book, so far as I can tell. The ISBN Al's got is the same one I have for vol 1, but for volume two, he lists 0-03-061742-X, whereas mine is 0-03-061743-X, I looked at his scan and it looks just like my copies, but mine have the ISBN's printed on the back cover in a little white box, with black letter. Also, his doesn't appear to have the holes punched. Here are some pics Front covers: https://ibb.co/zVdw3Ws Back covers: https://ibb.co/0Y1Lmqf Will From will.senn at gmail.com Sun Jan 7 01:06:22 2024 From: will.senn at gmail.com (Will Senn) Date: Sat, 6 Jan 2024 09:06:22 -0600 Subject: [TUHS] Original print of V7 manual? In-Reply-To: References: <20240105221729.371EA37401DA@freecalypso.org> <20240106012631.D984037403FB@freecalypso.org> Message-ID: On 1/5/24 23:08, segaloco via TUHS wrote: > Alright here's some commentary on and pictures of key pieces (I'll make reference to USG/PWB stuff in here too, but don't have pictures, 4.0 and 5.0/System V docs are scanned, variations on System III docs as well, can point those out to you if needed): > > > Whew. I'm tapped out. If you have any further questions I'll probably chit chat 1 on 1 but figured it might be good to tie all these threads together in a message on list, especially so I can be corrected, I'm a secondary source after all. > > - Matt G. No wonder, you're tapped out. Great job pulling this together. Finally, I'm catching up with this awesome thread. Does the original have an LD page? and, surely I missed this, but are you or have you scanned it for posterity... and interested parties :)? Will From aek at bitsavers.org Sun Jan 7 02:52:31 2024 From: aek at bitsavers.org (Al Kossow) Date: Sat, 6 Jan 2024 08:52:31 -0800 Subject: [TUHS] Original print of V7 manual? In-Reply-To: References: <20240105221729.371EA37401DA@freecalypso.org> <20240106030254.B8D7537401FF@freecalypso.org> <20240106032236.llpryldqt7lbondn@illithid> Message-ID: <936aea08-35cd-8f2c-bd59-9fd64ea8a0f0@bitsavers.org> I just checked the catalog and we have a couple of different sets of V7 manuals at CHM I've never bothered to scan them because of the existence of the pdf repros. The 4.1BSD set would probably be something good to scan. From aek at bitsavers.org Sun Jan 7 02:54:35 2024 From: aek at bitsavers.org (Al Kossow) Date: Sat, 6 Jan 2024 08:54:35 -0800 Subject: [TUHS] Original print of V7 manual? In-Reply-To: <936aea08-35cd-8f2c-bd59-9fd64ea8a0f0@bitsavers.org> References: <20240105221729.371EA37401DA@freecalypso.org> <20240106030254.B8D7537401FF@freecalypso.org> <20240106032236.llpryldqt7lbondn@illithid> <936aea08-35cd-8f2c-bd59-9fd64ea8a0f0@bitsavers.org> Message-ID: On 1/6/24 8:52 AM, Al Kossow wrote: > I just checked the catalog and we have a couple of different sets of V7 manuals at CHM I also just ordered a copy of the 1983 Vol 1 to compliment the Vol 2 I had already done. From g.branden.robinson at gmail.com Sun Jan 7 04:28:37 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Sat, 6 Jan 2024 12:28:37 -0600 Subject: [TUHS] Original print of V7 manual? In-Reply-To: References: <20240105221729.371EA37401DA@freecalypso.org> <20240106030254.B8D7537401FF@freecalypso.org> <20240106032236.llpryldqt7lbondn@illithid> Message-ID: <20240106182837.bvy76ykpxps5322j@illithid> At 2024-01-06T08:52:48-0600, Will Senn wrote: > The ISBN Al's got is the same one I have for vol 1, but for volume > two, he lists 0-03-061742-X, whereas mine is 0-03-061743-X, This sounds like a misprint; the last element of an ISBN is a check digit, so any change to a single earlier numeral should also change the check digit (where in old ISBNs--"ISBN-10"--before the invariant "978-" prefix of ISBN-13, "X" counted as a numeral). https://en.wikipedia.org/wiki/ISBN#ISBN-10_check_digit_calculation Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From clemc at ccc.com Sun Jan 7 04:33:18 2024 From: clemc at ccc.com (Clem Cole) Date: Sat, 6 Jan 2024 13:33:18 -0500 Subject: [TUHS] Original print of V7 manual? In-Reply-To: <20240106040642.D949B37403C1@freecalypso.org> References: <20240105221729.371EA37401DA@freecalypso.org> <20240106030254.B8D7537401FF@freecalypso.org> <20240106032236.llpryldqt7lbondn@illithid> <20240106040642.D949B37403C1@freecalypso.org> Message-ID: Hmmm.. I was thinking of keeping out of this food fight, but a couple of comments concern me a little as they seem to differ from the history as I recall it. @Branden, your observation of the font differences is exactly what I remember between the C/A/T-4 and the APS-5. I never used the Merganthaler, so I can not comment. Anyway -- here is what I remember from those days. On Fri, Jan 5, 2024 at 11:07 PM Mychaela Falconia wrote: > However, troff in 1978 was still completely, utterly incapable of driving > anything other than a C/A/T! For the original two versions of troff, that is a true statement, but I suspect that you might be in error; for those of us who lived in the era, I remember the details of the details differently, and the 3rd version was available in that timeframe. @Jon S - please feel free to chime in/update/correct my memory -- you lived this period as an Explorer Scout > Now bwk, the author of this doc, is the very same fine gentleman who > wrote ditroff, the creature that was > finally capable of driving a Linotron 202 or Autologic APS-5 or whatever This is true - although I believe that the processor was from Autologic, the typesetter was from Alphanumeric Corp. > - but the timeline does not match up. Hmmm - I think that they do. > BWK's troff tutorial is dated 1978-08-04, That sounds about right and would have been when a lot of this topic was starting to be discussed. > but his work on ditroff (as I understand it) > happened some time around 1980 or 1981. Brian worked on the second edition of ditroff in the early 1980s [which is in the AT&T Tool Chest], but an earlier version was released on its own (well bundled with a new C compiler - but as a separate "product" (sort of), you could get Al Arm's folks - *i.e.*, the Tool Chest does not yet exist), Note that this version spurred the name of the new C compiler for the 1978 version of the K&R (which I thought was set on the APS-5 for the first version - although it may have been on the Meganthaler). While I still have a first edition, at one time, I had a copy of the proofs, which I got from tjk in late 1977 IIRC - it might have been the Fall of '78 [sadly, I think those pages were lost in the flood of a few years ago, as I have not seen then in my files]. He may have started ditroff work in 1979, but definitely not in 1978. > Well, the ideas for ditroff started before Joe died ('76/'77 timeframe), although Brian probably did not really start *direct work* in it until '78 -- taking over for Joe; he was there initially. Ok, so here goes how to date things in my mind... [note: a few internet searches should validate some/most/if not all of these dates] - Joe Ossana wrote the original troff in PDP-11 assembler in the early 1970s ['73, I think] - He rewrote it around '75 in C - both versions target the Singer GSI C/A/T (Computer Assisted Typesetter) - C/A/T-4 typesetter (FWIW: Wang bought the rights to GSI later, but that's not relevant to the story. [Those that remember the C/A/T, it worked but had several interesting issues, and it was expensive to operate]. - Alphanumeric Corp released the Alphanumeric Photocomposition System (APS) #5 in 1976 using an Autologic-73 mini to drive it. - AT&T (Computing Facilities/Documentation center folks) decided to buy one or more APS-5, although Research went for a Morganthaler to replace the GSI unit (there is a wonderful article about Ken and Co - hacking the Morganthaler -- I think we have it on TUHS -- I know I have a copy somewhere). - Discussions about making troff more independent of the output device began, and Brian was certainly part of that. - Remember, compiler people in those days had started to go to the idea of an ISA intermediate language and make the ISA-specific "back-end" a separate thing. So, the idea of a typesetter independent "IL" and the target program followed and certainly was part of that discussion. - Ossana died of a heart attack (in the hospital where he was recovering from an earlier one, IIRC) on 28-Nov-77. - Note: Research is running the Sixth Edition at this point. - Through the Sixth Edition, most C programs did I/O themselves via read/write (like the C troff had), although Mike Lesk's Portable C Library had started to be available ?? with V5 IIRC ?? But it was distributed with V6 (see the V6 doc directory for iolib), and a few people (I knew in those days) seemed to be actively using it. Plus, iolib has some interesting schemes, like using "-1" as the first parameter to printf(3) or scanf(3) to say things were "special." [I'll let the reader go find a copy - it's a fun read. I remember using iolib when I first learned C back in the day]. - Brian has already been developing the new device-independent version of troff to target the C/A/T-4, Linotron 202 (Meganthaler), and APS-5 (I'm not sure if the latter two had been delivered when he started, but they were on the horizon and POR as it were, so the need to support them by then was real]. - During his development of the new system, Brian wanted some changes to C itself to make writing this system easier, but most importantly, he pushed Dennis for some standardization for the I/O. - So Dennis updates C, including his new libS.a - which is the new Standard I/O library - *a.k.a.* . - Brian is now the Editor/Convener of the new CS Book Series for PH [which would eventually push out a lot of titles many of us have at least read if not in our collection -- I would become a reviewer for a number of them]. - Also, Dennis and Brian started to write what would become K&R, which is the dialectic of the language the book describes. - V7 is still about a year in the future. - Troff had leaked at our labs in the Universities, and some of us had it in source, but most everyone at least had the original binary. In fact, the University of Toronto would write their version of that [which is related to Tom Ferrin's from UCSF - which is where I got it, but Rob has made me think Tom started with UT's version. - Many of us wanted it formally and were pushing Al Arms in AT&T's Patent and Licensing office to get a distribution of it (pre-Judge Green, so what we can get and what cannot is often a little dicey). This would be released in late '78, requiring Dennis' new C compiler with the libS.a to compile. - K&R was about to be published, so Dennis knew that we needed a way to seed and "update" the community. - The result was the original release, which included a new C compiler (which cost extra money) -- but that is why many of us refer to this flavor of C as 'Typesetter C." - The V7 Ritchie C compiler would be a slightly improved version of the one in the typesetter release. Anyway - the point is (I believe that) the second release of ditroff (ditroff2, if you will) is what you are referring to as the later 1980s version. This was primarily available via the Tool Chest -- *i.e*., is post Judge Green. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Sun Jan 7 07:04:54 2024 From: rich.salz at gmail.com (Rich Salz) Date: Sat, 6 Jan 2024 16:04:54 -0500 Subject: [TUHS] Original print of V7 manual? In-Reply-To: References: <20240105221729.371EA37401DA@freecalypso.org> <20240106030254.B8D7537401FF@freecalypso.org> <20240106032236.llpryldqt7lbondn@illithid> <20240106040642.D949B37403C1@freecalypso.org> Message-ID: Also https://www.cs.princeton.edu/~bwk/202/index.html has some papers with Brian as co-author that talk about the history or the 202 and the background work (troff->ditroff) involved. I am sure these have been posted here before. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sun Jan 7 07:38:06 2024 From: clemc at ccc.com (Clem Cole) Date: Sat, 6 Jan 2024 16:38:06 -0500 Subject: [TUHS] Original print of V7 manual? In-Reply-To: References: <20240105221729.371EA37401DA@freecalypso.org> <20240106030254.B8D7537401FF@freecalypso.org> <20240106032236.llpryldqt7lbondn@illithid> <20240106040642.D949B37403C1@freecalypso.org> Message-ID: Rich - thanks, that's the paper I referred to. Note date -- 6-Jan-80 - the work being done in the summer of '79. A number of us had been using ditroff as it had existed for a couple of years by that time, and as the abstract says - they got the Mergenthaler in the Summer of '79. What I did not remember was when the Mergenthaler work started. I did remember that it was after the APS-5 had been available for a while. Just for completeness, Judge Green mandated the breakup of the Bell System on January 8, 1982 -- Tool Chest *et al*. is set up later -- all part of the ability for AT&T to be in the commercial computer business. ᐧ ᐧ On Sat, Jan 6, 2024 at 4:05 PM Rich Salz wrote: > Also https://www.cs.princeton.edu/~bwk/202/index.html has some papers > with Brian as co-author that talk about the history or the 202 and the > background work (troff->ditroff) involved. > > I am sure these have been posted here before. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at cuzuco.com Sun Jan 7 09:15:59 2024 From: tuhs at cuzuco.com (Brian Walden) Date: Sat, 6 Jan 2024 18:15:59 -0500 (EST) Subject: [TUHS] Fred Grampp Message-ID: <202401062316.406NFxKA000795@cuzuco.com> This isn't directly UNIX related, and yes, the thread is 3 years old. But since it made national news last night, probably due to its proximity to Newark Airport. The enormous fire in Elizabeth, NJ, I recognized in the local news as the old Singer factory. That factory was the catalyst that linked me into finding out more on Fred Grampp, and his ancestry. Here's a non-paywalled link that also mentions it is indeed the old Singer factory: https://newjersey.news12.com/elizabeth-nj-fire-industrial-building On Tue, Mar 16, 2021 at 11:12 AM M Douglas McIlroy wrote: > > Serendipitous find! I hadn't realized that Fred had been the third > generation in the hardware store. > His father ("Pops") retired to Drayton Island in the St Johns River > about 60 miles south of Jacksonville. > Fred often visited him, driving the 19-hour trip in one stint. > > Doug > > On Mon, Mar 15, 2021 at 6:47 PM Brian Walden wrote: > > > > Amazing coincidences. A week prior I was researching Topper Toys > > looking for their old factory ("largest toy factory in the world") > > As there was litte on it's location and it lead me to find out > > in 1961 it took over the old Singer Factory in Elizabeth, NJ. > > So looking up the Singer factory led me to "Elizabeth, > > New Jersey, Then and Now" by Robert J. Baptista > > > > https://ia801304.us.archive.org/11/items/ElizabethNewJerseyThenAndNowSecondEdition2015/ElizabethNewJerseyThenNowThirdEditionApril102018607Pages.pdf > > > > Which had no information on Topper, but had had this paragraph in it's Singer > > section on page 28 -- > > > > Boys earned money "rushing the growler" at lunchtime at the Singer plant. > > German workers lowered their covered beer pails, called growlers, on ropes > > to the boys waiting below. They earned a nickel by filling them with beer > > at Grampp's saloon on Trumbull St. One of these boys was Thomas Dunn who > > later became a long term Mayor. In the early 1920s Frederick Grampp went > > into the hardware business at the corner of Elizabeth Ave. and Reid St. > > > > > > When I read it I thought funny, as I know the name Fred Grampp. But beleived > > just a coincidenental same name. After reading the biography post, I went back > > to the book as it turns out that Fred Grampp is your Fred Grampps's > > grandfather. You can find more his family and the hardware store and > > Grampp himself on pages 163-164, and 212. > > > > -Brian > > > From falcon at freecalypso.org Sun Jan 7 12:17:02 2024 From: falcon at freecalypso.org (Mychaela Falconia) Date: Sat, 06 Jan 2024 18:17:02 -0800 Subject: [TUHS] Original print of V7 manual? In-Reply-To: References: <20240105221729.371EA37401DA@freecalypso.org> <20240106030254.B8D7537401FF@freecalypso.org> <20240106032236.llpryldqt7lbondn@illithid> <20240106040642.D949B37403C1@freecalypso.org> Message-ID: <20240107021710.F0B92374013D@freecalypso.org> Hi Clem, > Hmmm.. I was thinking of keeping out of this food fight, but a couple of > comments concern me a little as they seem to differ from the history as I > recall it. Thank you for various juicy details - but I still have a hard time accepting your timeline. BWK's paper "A Typesetter-independent TROFF" (troff source here, file date 30-Mar-1983: http://medialab.freaknet.org/martin/tape/stuff/ditroff/docs/indep_troff ) contains these passages: | Early in 1979, | the Computing Science Research Center | decided to acquire a new typesetter, | primarily because of our interests in typesetting graphics. | At the same time, | the Murray Hill Computer Center | began to investigate the possibility of replacing their | family of aging CAT's | with a new, high-performance typesetter, then | Accordingly, in the spring of 1979, | I set about to modify | .UC TROFF | so that it would run hence\%forth without change | on a variety of typesetters. then | This version of | .UC TROFF | has been in use | since September of 1979. | Most of our experience with it has been on the | 202 and Tektronix scopes, but the CAT and APS-5 drivers have been | exercised to some degree. The "summer vacation" paper gives a similar timeline: 202 acquired in summer of '79, troff preparatory work done "ahead of time" (consistent with "spring of 1979" in indep_troff paper), production use by Sept of 1979 just like indep_troff says. I admit that I was wrong in my first recollection of 1980 or 81 - but I still have a hard time believing that there was a _working_ ditroff setup in '78. Ideas and thoughts about moving away from CAT-specific troff - sure - but a working setup is a different story. But of course I wasn't there, and you say you were... If ditroff really did exist in 1978-August when BWK wrote the "Troff tutorial" paper (the one that appears right away Ossanna's original manual in V7, 4.2BSD and 4.3BSD docs), why does that paper not contain a single word about it, talking only about the Graphic Systems typesetter? Was the existence of ditroff a closely guarded secret then? Back to my original assertion about \(sq character in Bold having changed from hollow to filled square while still on CAT-4. Let's say I am wrong here and you are right that it became a filled square only in some non-CAT ditroff setup. But if ditroff was secret, non-releasable stuff in 1978 leading up to V7, why did they define "blot" as \fB\(sq\fP in /usr/pub/eqnchar? The distributed system (as of V7) contained only CAT-driving troff and no ditroff - so surely eqnchar was produced to be usable by users of the as-is distributed system... My hypothesis still stands: until someone convinces me otherwise, I shall continue to believe that *every* paper that made its way into V7 Volume 2 (including BWK's trofftut) was typeset on the original CAT-driving troff, and that the filled \(sq in Bold in V7 manuals (in this trofftut document and eqnchar(7) man page in Vol1) indicates that this filled square was present in Bold on CAT-4. Yet this square being hollow in all 3 font samples in Ossanna's original 1976 manual in the very same V7 Vol2 indicates that the font was different back in '76. The only explanation that fits is that some time between 1976-10 and 1978-08 the Bold film strip on the CAT was changed to an updated version from GSI. > This is true - although I believe that the processor was from Autologic, > the typesetter was from Alphanumeric Corp. So why are all papers from those days (ditroff docs, Usenix print notes for 4.3BSD) referring to it as Autologic APS-5? > the 1978 version of the K&R (which I thought was set on the APS-5 for the > first version - although it may have been on the Meganthaler). While I > still have a first edition, at one time, I had a copy of the proofs, which > I got from tjk in late 1977 IIRC - it might have been the Fall of '78 Now this part is intriguing. Wikipedia says the 1st ed of K&R C book was published February 22, 1978. Are you *absolutely certain* it was troffed on APS-5 or Linotron 202 etc? (I never got a copy, so I don't have a colophon to look at.) If this book, published in early 1978, was indeed produced on a setup that was only possible with ditroff, then why did BWK tell the story of *beginning* ditroff coding work (actual implementation, not just thoughts/ideas) in spring of '79 in preparation for 202 arriving that summer? Another inexplicable mystery with this hypothesis: if ditroff was in some working state (good enough to publish a book) in 1978-Feb, why in the world was it excluded from V7 release - and not only excluded as in shipping code, but total suppression of any mention of its existence? > - Alphanumeric Corp released the Alphanumeric Photocomposition System > (APS) #5 in 1976 using an Autologic-73 mini to drive it. Thank you for decoding what APS stood for! Although in my mind it will probably always be "avtomaticheskiy pistolet Stechkina" in my native Russian. :-) M~ From aek at bitsavers.org Sun Jan 7 12:25:37 2024 From: aek at bitsavers.org (Al Kossow) Date: Sat, 6 Jan 2024 18:25:37 -0800 Subject: [TUHS] Original print of V7 manual? In-Reply-To: <20240107021710.F0B92374013D@freecalypso.org> References: <20240105221729.371EA37401DA@freecalypso.org> <20240106030254.B8D7537401FF@freecalypso.org> <20240106032236.llpryldqt7lbondn@illithid> <20240106040642.D949B37403C1@freecalypso.org> <20240107021710.F0B92374013D@freecalypso.org> Message-ID: <4f328b80-a17f-e5e6-10a1-c9134c9d5832@bitsavers.org> The SRI reprints of the 1979 Seventh Edition vols 1 and 2a are on bitsavers now, along with my copy of the Sixth Edition programmers manual From phil at ultimate.com Sun Jan 7 12:54:58 2024 From: phil at ultimate.com (Phil Budne) Date: Sat, 06 Jan 2024 21:54:58 -0500 Subject: [TUHS] Original print of V7 manual? In-Reply-To: <20240107021710.F0B92374013D@freecalypso.org> References: <20240105221729.371EA37401DA@freecalypso.org> <20240106030254.B8D7537401FF@freecalypso.org> <20240106032236.llpryldqt7lbondn@illithid> <20240106040642.D949B37403C1@freecalypso.org> <20240107021710.F0B92374013D@freecalypso.org> Message-ID: <202401070254.4072swca006665@ultimate.com> Mychaela Falconia wrote: > My hypothesis still stands: until someone convinces me otherwise, I > shall continue to believe that *every* paper that made its way into V7 > Volume 2 (including BWK's trofftut) was typeset on the original CAT-driving > troff FWIW (likely little), CAT-driving troff *was* used to drive other printers, and least for the unwashed. At Boston University in the mid 80's we had a Talaris 1200 (the same Xerox print engine (2700?) as the DEC LN01). The name QMS (and QUIC) were mixed in there was well. We had a "qtroff" command that ran the standard 4BSD troff against custom kerning files (in a.out format!) and interpreted the C/A/T output for the printer. Then we got the transcript package from Adobe which had a "ptroff" command that similarly converted C/A/T output to PostScript(*). I'm not saying interpreting C/A/T output was done at the mother ship, but it's not impossible either. The big wins with [td]itroff were more than four fonts, and graphics. (*) Transcript also came with a "psroff" script that would use ditroff, if you had it, and the original "enscript" command was in the transcript package. From falcon at freecalypso.org Sun Jan 7 13:21:32 2024 From: falcon at freecalypso.org (Mychaela Falconia) Date: Sat, 06 Jan 2024 19:21:32 -0800 Subject: [TUHS] Original print of V7 manual? In-Reply-To: <202401070254.4072swca006665@ultimate.com> References: <20240105221729.371EA37401DA@freecalypso.org> <20240106030254.B8D7537401FF@freecalypso.org> <20240106032236.llpryldqt7lbondn@illithid> <20240106040642.D949B37403C1@freecalypso.org> <20240107021710.F0B92374013D@freecalypso.org> <202401070254.4072swca006665@ultimate.com> Message-ID: <20240107032140.BE8393740314@freecalypso.org> Phil Budne wrote: > FWIW (likely little), CAT-driving troff *was* used to drive other > printers, and least for the unwashed. Oh yes, I know! In the branch of UNIX closest to my heart, CSRG at UCB had vtroff(1) for driving Varian/Versatec raster output devices with a CAT-emulating post-processor to original troff. My recent discovery of scanned 4.2BSD Usenix docs (thank you, Ms. Erica Fischer, whoever and wherever you are!) tells me that vtroff(1) for casual prints plus a real CAT for serious typesetting was still the only troff setup at UCB as of 4.2BSD, i.e., no ditroff yet. In the days of 4.3BSD CSRG used ditroff internally, but could not ship it because of licensing nonsense, and by this point some early Xerox EP printer (speaking Interpress, apparently) replaced Varian/Versatec as the "default" device for casual prints, whereas APS-5 took the place of CAT for serious typesetting jobs. > I'm not saying interpreting C/A/T output was done at the mother ship, > but it's not impossible either. The big wins with [td]itroff were > more than four fonts, and graphics. Second sentence: I agree absolutely. But while people did take output of original troff and converted it to either raster or PostScript, I am not quite sure if one could drive something like APS-5 in this manner - I'll have to think about it. M~ From clemc at ccc.com Sun Jan 7 13:55:31 2024 From: clemc at ccc.com (Clem Cole) Date: Sat, 6 Jan 2024 22:55:31 -0500 Subject: [TUHS] Original print of V7 manual? In-Reply-To: <20240107021710.F0B92374013D@freecalypso.org> References: <20240105221729.371EA37401DA@freecalypso.org> <20240106030254.B8D7537401FF@freecalypso.org> <20240106032236.llpryldqt7lbondn@illithid> <20240106040642.D949B37403C1@freecalypso.org> <20240107021710.F0B92374013D@freecalypso.org> Message-ID: Nothing was secret. As for 78 or 79 the typesetter release with the Dennis’s new c compiler was before v7 which was late 79. I believe that typesetter and Dennis new C compiler code was released from Patent and Licensing about a year before V7. We had it had CMU before I graduated in early ‘79. I can ask Steve Glaser but I remember he telling me he has it at Rice also. I’m not sure what MIT but I can ask Ward Cunningham if he remembers if Purdue was using it. There is some stuff in the early USENIX archives. As I said I know Tom Ferris was using the vcat and that the version on the BSD tapes. Rob has suggested Joy had his version from of vcat Toronto. Vcat was modified to talk to ditroff although We all started with the assembler version troff but Joes C rewrite had leaked and many folks had it outside of the labs. The version of the compiler from the first Typesetter C release has been extensively discussed here and in other places although the libS.a from it is available with search. Plus K&R1 can be found in used form in the used market and have at least two copies and I’ve seen an PDF scan in the wild (it’s poor quality). What I don’t have is the tape from those days. I know I have the later Tool Chest version without the compiler from my Masscomp days - 83/84. As well as Adobe Transcript. This is not the same version we had at CMU and Tektronix that flavor does not seem to be in anything I have found - although I did recover the first version of the original CMU fsck. There are some files from that recovery I have not examined so I may find that code at some point. As for what K&R was set on I don’t remember. It could have been the C/A/T in research. But I thought it was set on the larger and newer system in the MH computer center. As I said, I once had a xerographic copy of the proofs but I know are lost. That said, the actual book is easy to find in wild. BTW Brian K was on Brian Reid’s Thesis Committee in 1979 PHD committee (Brian Reid wrote Scribe at CMU) and his Thesis was on typesetting. The first (Pascal) version of Tex was released by Knuth at Stanford around the same time(and it’s predessor Stanford’s PUB had been around the ARPanet sites for at least 4 years on the PDP-10 using the XGPs. The point is that the ideas in ditroff were all being discussed before Joe died. His death in the late 70s forced a rewrite by someone else (Brian) and the APS-5 in the computer center I remember as the original driver. I might be mis remembering but I don’t think so since the dates of the release of the original typesetter and new compiler code from patent and licensing as well as the publication date of K&R are well documented as being on V6 not V7 and all of that is pre Judge Green changes to how ATT does business 3 years later. Btw I do have an original V7 manual in a US standard 3 ring binder on a shelf — as it came from Patent and Licensing which we had printed in Teklabs after we go the V7 tape. Btw this is not the funky 2 ring BTL binding that was used in the labs or the more popular format used for PWB and later the Marx printing of the BSD manuals and later USENIX BSD versions. But Sadly the troff tutorial section is missing - I remember I used to have a copy of the troff related stuff in a separate file that was in a shelf in my office next to my terminal and I bet I put the troff tutorial in it. I’ll look through some of my file cabinets to see if I can find that file - I must have put into in a cabinet firing a job change and might have the missing pages from the binder. Sent from a handheld expect more typos than usual On Sat, Jan 6, 2024 at 9:17 PM Mychaela Falconia wrote: > Hi Clem, > > > Hmmm.. I was thinking of keeping out of this food fight, but a couple of > > comments concern me a little as they seem to differ from the history as I > > recall it. > > Thank you for various juicy details - but I still have a hard time > accepting your timeline. BWK's paper "A Typesetter-independent TROFF" > (troff source here, file date 30-Mar-1983: > http://medialab.freaknet.org/martin/tape/stuff/ditroff/docs/indep_troff ) > contains these passages: > > | Early in 1979, > | the Computing Science Research Center > | decided to acquire a new typesetter, > | primarily because of our interests in typesetting graphics. > | At the same time, > | the Murray Hill Computer Center > | began to investigate the possibility of replacing their > | family of aging CAT's > | with a new, high-performance typesetter, > > then > > | Accordingly, in the spring of 1979, > | I set about to modify > | .UC TROFF > | so that it would run hence\%forth without change > | on a variety of typesetters. > > then > > | This version of > | .UC TROFF > | has been in use > | since September of 1979. > | Most of our experience with it has been on the > | 202 and Tektronix scopes, but the CAT and APS-5 drivers have been > | exercised to some degree. > > The "summer vacation" paper gives a similar timeline: 202 acquired in > summer of '79, troff preparatory work done "ahead of time" (consistent > with "spring of 1979" in indep_troff paper), production use by Sept of > 1979 just like indep_troff says. I admit that I was wrong in my first > recollection of 1980 or 81 - but I still have a hard time believing > that there was a _working_ ditroff setup in '78. Ideas and thoughts > about moving away from CAT-specific troff - sure - but a working setup > is a different story. > > But of course I wasn't there, and you say you were... If ditroff > really did exist in 1978-August when BWK wrote the "Troff tutorial" > paper (the one that appears right away Ossanna's original manual in V7, > 4.2BSD and 4.3BSD docs), why does that paper not contain a single word > about it, talking only about the Graphic Systems typesetter? Was the > existence of ditroff a closely guarded secret then? > > Back to my original assertion about \(sq character in Bold having > changed from hollow to filled square while still on CAT-4. Let's say > I am wrong here and you are right that it became a filled square only > in some non-CAT ditroff setup. But if ditroff was secret, non-releasable > stuff in 1978 leading up to V7, why did they define "blot" as \fB\(sq\fP > in /usr/pub/eqnchar? The distributed system (as of V7) contained only > CAT-driving troff and no ditroff - so surely eqnchar was produced to > be usable by users of the as-is distributed system... > > My hypothesis still stands: until someone convinces me otherwise, I > shall continue to believe that *every* paper that made its way into V7 > Volume 2 (including BWK's trofftut) was typeset on the original CAT-driving > troff, and that the filled \(sq in Bold in V7 manuals (in this trofftut > document and eqnchar(7) man page in Vol1) indicates that this filled > square was present in Bold on CAT-4. Yet this square being hollow in > all 3 font samples in Ossanna's original 1976 manual in the very same > V7 Vol2 indicates that the font was different back in '76. The only > explanation that fits is that some time between 1976-10 and 1978-08 > the Bold film strip on the CAT was changed to an updated version from > GSI. > > > This is true - although I believe that the processor was from Autologic, > > the typesetter was from Alphanumeric Corp. > > So why are all papers from those days (ditroff docs, Usenix print notes > for 4.3BSD) referring to it as Autologic APS-5? > > > the 1978 version of the K&R (which I thought was set on the APS-5 for the > > first version - although it may have been on the Meganthaler). While I > > still have a first edition, at one time, I had a copy of the proofs, > which > > I got from tjk in late 1977 IIRC - it might have been the Fall of '78 > > Now this part is intriguing. Wikipedia says the 1st ed of K&R C book > was published February 22, 1978. Are you *absolutely certain* it was > troffed on APS-5 or Linotron 202 etc? (I never got a copy, so I don't > have a colophon to look at.) If this book, published in early 1978, > was indeed produced on a setup that was only possible with ditroff, > then why did BWK tell the story of *beginning* ditroff coding work > (actual implementation, not just thoughts/ideas) in spring of '79 in > preparation for 202 arriving that summer? > > Another inexplicable mystery with this hypothesis: if ditroff was in > some working state (good enough to publish a book) in 1978-Feb, why in > the world was it excluded from V7 release - and not only excluded as > in shipping code, but total suppression of any mention of its existence? > > > - Alphanumeric Corp released the Alphanumeric Photocomposition System > > (APS) #5 in 1976 using an Autologic-73 mini to drive it. > > Thank you for decoding what APS stood for! Although in my mind it will > probably always be "avtomaticheskiy pistolet Stechkina" in my native > Russian. :-) > > M~ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsg at jsg.id.au Sun Jan 7 17:03:34 2024 From: jsg at jsg.id.au (Jonathan Gray) Date: Sun, 7 Jan 2024 18:03:34 +1100 Subject: [TUHS] Early supported UNIX manual In-Reply-To: <202212221852.2BMIqMRk003859@ultimate.com> References: <202212221852.2BMIqMRk003859@ultimate.com> Message-ID: On Thu, Dec 22, 2022 at 01:52:22PM -0500, Phil Budne wrote: > Rather than increase subject drift on a thread I started > "UNIX on (not quite bare) System/370", here's a new thread. > > Since the TUHS archive seems to now include documentation, > I decided to take a look and see if the earliest UNIX manual I have > is in the archive: > > It was given to me by a friend at Stevens Tech in Hoboken NJ (c. 1980) > who had graduated, and worked for AT&T. > > It's hole punched for a four ring binder > (I found an unused Bell System Project Telstar binder to put it in). > > The cover page has: > > Upper left corner: > Bell Telephone Laboratories Incorperated > PROGRAM APPLICATION INSTRUCTION > > Upper right corner: > PA-1C300-01 > Section 1 > Issue 1, January 1976 > AT&TCo SPCS > > Center: > UNIX PROGRAMMER'S MANUAL > Program Generic PG-1C300 Issue 2 > Published by the UNIX Support Group > January, 1976 now available on bitsavers thanks to Al Kossow: https://bitsavers.org/pdf/att/unix/6th_Edition/ > > The preface starts with: > > This document is published as part of the UNIX Operating System Program Generic, > PG-1C300 Issue 2. The development of the Program Generic is the result of the > efforts of the members of the UNIX Support Group, supervised by J.F. Maranzano > and composed of: R. B. Brant, J. Feder, C. D. Perez. T. M. Raleigh, R. E. Swift, > G. C. Vogel and I. A. Winheim. > > and ends with > > For corrections and comments please contact C. D. Perez, MH 2C-423, Extension > 6041. > > Not knowing who else I could ask, I brought it to a Boston Usenix (in > the 90's or oughts), and asked DMR if he could identify it. He said > it was an early supported UNIX, and he signed the preface page for me. > > The manual has sections I through VIII; all manual pages start with page -1- > > I found https://www.tuhs.org/Archive/Distributions/USDL/unix_program_description_jan_1976.pdf > > with cover page: > UNIX PROGRAM DESCRIPTION > Program Generic PG-1C300 Issue 2 > Published by the UNIX Support Group > January 1976 > > contents: > NUMBER ISSUE TITLE > PD-1C301-01 1 Operating System > PD-1C302-01 1 Device Drivers Section 1 > PD-1C303-01 1 Device Drivers Section 2 > > And consists of descriptions of kernel functions. > > So it seems likely that my manual is a companion to that. > > I have a Brother printer/scanner, but the paper is fragile, so unless > it's of immediate and burning value to someone, it's unlikely to rise > to the top of my ever-static list of documents to scan.... > > But if someone has specific questions I can look up, let me know.... From aek at bitsavers.org Sun Jan 7 20:38:52 2024 From: aek at bitsavers.org (Al Kossow) Date: Sun, 7 Jan 2024 02:38:52 -0800 Subject: [TUHS] Early supported UNIX manual In-Reply-To: References: <202212221852.2BMIqMRk003859@ultimate.com> Message-ID: <429f452e-eee9-5b8f-ffa4-07dea148cede@bitsavers.org> On 1/6/24 11:03 PM, Jonathan Gray wrote: >> Center: >> UNIX PROGRAMMER'S MANUAL >> Program Generic PG-1C300 Issue 2 >> Published by the UNIX Support Group >> January, 1976 > > now available on bitsavers thanks to Al Kossow: > https://bitsavers.org/pdf/att/unix/6th_Edition/ > I left my name on the scan because this is the oldest Unix manual I've collected. It was given to me in the 70s by someone at Indian Hill when we were bringing up his 11/40 at home to run V6. It was the first Unix system I was able to use. From tuhs at cuzuco.com Sun Jan 7 20:54:55 2024 From: tuhs at cuzuco.com (Brian Walden) Date: Sun, 7 Jan 2024 05:54:55 -0500 (EST) Subject: [TUHS] Original print of V7 manual? In-Reply-To: <20240106040642.D949B37403C1@freecalypso.org> References: <20240105221729.371EA37401DA@freecalypso.org> <20240106030254.B8D7537401FF@freecalypso.org> <20240106032236.llpryldqt7lbondn@illithid> Message-ID: <202401071055.407Ast6p014321@cuzuco.com> Since this is my work, and it was the first PDF produced from the troff sources. So let me set the stage, and this should answer some of the issues you and others have with my work. This was 25 years ago. There were not any scanned images of these documents it be found anywhere online. There was only the incomplete troff sources that were available on a bell labs web page, and that was hardly usable. I wanted an online human readable, computer searchable and a print it anywhere document. That meant one format to me, PDF. So I went about to produce one. It was so much harder than anticipated. I spent a lot of my spare time doing it, it took me months to complete. Someone all ready posted my notes on how I made it in an earlier message. Once I got it to a state where I was happy with it, I stopped. Also the only thing I had to compare my version to was a physical copy of a reprint of the The Bell System Technical Journal Vol 57, No 6, Part 2, July-August 1978 (It had a red cover with the AT&T death star logo, not the original blue cover, nor the 1984 version with a yellow cover). And the book's pages were not US printer paper size of 8.5"x11" but were 5"x8". It was made under Solaris 2.6, on an Ultra 2 ("Pulsar"), using the troff, tbl, eqn, pic, refer and macros as supplied by Sun at that time, and NOT any GNU ones. Why? These were the versions written by AT&T that Sun got directly from them during their SVR4 collaboration. I used the PostScript output option to troff (which obviously did not exist in 1979). That code to produce PostScript outout, had a high probability of being written by the graphics group run by Nils-Peter Nelson in Russ Archer's Murray Hill Computer Center (department 45268). As in the mid 1980s, the computer centers had a SRP (small remote printer) initiative that deployed QMS laser printers (they could only do PostScript level 1) in common areas near where their users were, and connected via datakit or direct serial lines. These QMS printers obsoleted the large and chemically nasty phototypesetters, so they all disappeared from the computer centers. Anyway, now I have a whole bunch of PostScript files, that is hardly usable to read on screen. Nor very searchable, and ONLY printable on PostScript printers. The place I was working at the time decided to save a few dollars, they did not get Adobe licenses for most of their printers, so they could only print PCL. Luckily the free Adobe Acrobat Reader (version 3) which was available on most platforms, could print to PCL. So I need to convert this into PDF. In 1998 there are not too many options. I tried ghostscript but it was too immature to produce anything acceptable to me. I ended up buying my own Adobe Distiller out of pocket, the Windows 95 version, since it was much cheaper than the Solaris as that was only available as a Distiller "server" version. So I then transferred the PostScript files to my windows machine and turned them into the 3 PDFs. But there was a bug in Distiller, it had and offset problem on the lines of every tbl, eqn, or pic, on every platform it was an obvious problem, either viewing it on screen or printing it (both PS and PCL). So I wrote a awk script to modify many of the PostScript files to fix the wrong offset. If you viewed or printed a modified PS file, it looked like it had offset error, but now in the opposite direction. But once distilled into a PDF, that PDF looked and printed like it should. So those modified PS files wound be of no value to share. I then manually add the bookmarks and blank pages that allowed two side printing using the same windows distiller. I had shown it to some others and they thought it was pretty great. But I cannot publish nor host these as this is not my intellectual property and I would need permission. At this time there was not very much available on TUHS, some binary versions all without any source code, that you could boot up on SIMH. I decided I should drop a note to Dennis Ritchie with a copy of the PDFs to see what he tought. Since I had known Dennis slightly from my time working at Murray Hill. I lived across the street from the labs on Burlington Rd and skateboarded into work. It was just across the east employee parking lot, and I would use that eastern entrance. Dennis also lived in the neighborhood, a bit farther from the labs than me, in a cul-de-sac. For a full week once, Dennis kept the complete opposite hours than I did. We would passed each other at the guard station at the entrance. After a few times it got to be a bit comical. Me entering 9ish, "good night Dennis" He would smile. Me leaving 5-6ish: "good morning Dennis". We would exchange pleasantries. I had to walk the skateboard past the guard a bit and not jump back on it, else the guard would give chase, yelling not to skate in the hallway. I always had the idea if someone wanted to sneak into the labs they'd just need to wait for me to go in in the morning, and once the guard was chasing me, they could just walk on in unchallenged. If you worked in MH from 1990-1992 and saw someone on a black on top, neon green bottom skateboard, headed from 2F-164 to the stock room, that was me. Dennis really like the PDFs, and we had a email discussion on what to do with it as it was a derivative work of copyrighted material that I did not have the rights to. He said he needed to do some checking (lawyers?). Eventually he said they would host the PDFs, as it was their property, but would give me full credit for producing it. And once it was freely available on their site, anyone, including myself, could host copies. I provided Dennis with all the added files and all the modified versions of their files, the new run shell and sed scripts and even the awk postscript pre-distiller fixer script. He (or Lucent) declined not put them up along side the PDFs, for whatever reason, and since they were not providing them, I was not to give out those files either. Only files I made myself or the files I found that were all ready available by Lucent (such as the missing headers) were OK for me to host too. This is that v7add.tar.gz file you found, that I only hosted. I also decided (and I told Dennis) I was going to make it so I could identify the PDF files that was my work. In volume 2B, I fixed the typo "oe" to "one" on the RATFOR paper, and I figured no one is going to put in a typo back in. In volume 2A on the "UNIX Programming" page I left the .ND macro as is so it would print the date it was troff'd (December 3, 1998). I did have a volume 2A that also had the correct 7th Edition C Reference Manual in it. The one you get in my 1988 PDF is from the 6th Edition, notice it is the old =+ syntax and not the += one. Dennis said that not even Lucent could provide that as a free PDF, as it was a published book by Prentice-Hall. I was asked to destroy all PDFs that had that version in it. I was going to do something similar to volume 1, but I forgot to do it before that December 3rd run and it got sent to Dennis without a change. And I was not going to tell Dennis and say hey pull that one down and put this one up, thanks. Too late is simply too late. That at some point after they had been out for a while I noticed Dennis added gzipped postscript versions of them, and credited it to Aharon Robbins, who still posts here. I was upset at first, as it looked like half the credit was going to someone who did a print to file and then ran gzip on it. And second, the point of the PDF was so it could print anywhere, those cannot. Anyway I got over it, as none it was mine to start with. And most would probably use the PDF anyway. Larry McVoy asked me for my modified files to make the PDFs too, in 1999 or 2000, for bitkeeper or bitsavers. But since I was not allowed to share them and I had moved companies, I had lost them. I thought I had saved a copy but I could no longer find it. I asked Dennis if he still had them, he did not. This work is truly lost. The next, and last, time I saw Dennis was at the 2000 Summer USENIX in San Diego. I just thought it was funny the looks I got from people when he came up to me to say hello. -Brian Mychaela Falconia wrote: > G. Branden Robinson wrote: > > > My belief, based on the evidence I have from these publications > > colophons reporting which phototypesetter was used, is that the \(sq > > special character was not filled in Graphic Systems C/A/T fonts used by > > Bell Labs, > > I disagree. While the "NROFF/TROFF User's Manual" document proves > that \(sq was hollow in all 3 fonts _as of 1976-10-11_ (the original > date of this doc), bwk's document from 1978-08-04 indicates that this > char had to have changed to a filled square by this date. However, > troff in 1978 was still completely, utterly incapable of driving > anything other than a C/A/T! Now bwk, the author of this doc, is the > very same fine gentleman who wrote ditroff, the creature that was > finally capable of driving a Linotron 202 or Autologic APS-5 or > whatever - but the timeline does not match up. BWK's troff tutorial > is dated 1978-08-04, but his work on ditroff (as I understand it) > happened some time around 1980 or 1981. He may have started ditroff > work in 1979, but definitely not in 1978. > > > but _was_ filled in the bold face by the Autologic APS-5. > > 4.3BSD Usenix books prove otherwise: these must have been troffed on > APS-5, as many notes from that time attest, but they feature hollow > square in bold. Even eqnchar(7) is "wrong" in 4.3BSD print in that > "blot" is a hollow square, clearly counter to original intent of that > named eqn character. > > > I have documented this understanding in the groff_char(7) man page, > > Ahh, so you are involved with groff - got it. I wrote my own version > of troff (based on V7, running under 4.3BSD and directly emitting > DSC-conforming PostScript) in 3 "bursts" of work around 2004, 2010 and > 2012, but I never got around to releasing it. I am now in the process > of cleaning it up for release, hoping to finally have it out in another > week or two. And I put a _lot_ of work into replicating the original > troff character set... > > > Also, my copies of these books are overseas, but I seem to remember that > > the Holt/Reinhart/Winston (HRW) 1983 reprint of the Seventh Edition > > Thank you for clarifying what HRW is - so this 1983 version of 7th ed > UPM is *not* the original? > > > > What was the physical form of this book? Was it a "perfect bound" > > > book? > > > > The HRW copies I have are perfect bound. But I can't remember if they > > were 3-hole punched as well. > > Thank you for the clarification! But if HRW version is not the > original, then what was the original like? > > > Where did you discover the identity and date of the 1998 retypeset of > > the V7 Volume 2 manual? > > https://plan9.io/7thEdMan/bswv7.html > http://web.cuzuco.com/~cuzuco/v7/ > > The second page includes a link to this tarball: > > http://web.cuzuco.com/~cuzuco/v7/v7add.tar.gz > > Dates inside that tarball are 1998-12-13. There was also a place > where Brian missed the retroffing date - see page 287 of his > v7vol2a.pdf. > > > I have wondered about this for years. In part > > to complain, because while it is a _fairly_ faithful reproduction of the > > original, it is not perfect, > > What _I_ don't like about BSW's PDF rendition of V7 manuals is that it > is a sort of "closed source" product: there is no published source > package that retraces every step in the flow from ancient troff sources > to the finished product. > > In the same 3 "bursts" of activity (2004, 2010 and 2012) when I worked > on my own version of troff, I also worked toward doing a PostScript > reprint of 4.3BSD Usenix books. 4.3BSD happens to be my personally > preferred version of UNIX, but the same methods I use for 4.3BSD books > can also be applied to V7. I am hoping that in the next week or two I > will find time to release not only my version of troff, but also the > partial set of 4.3BSD books I got done so far. > > Out of the 7 books that comprise 4.3BSD Usenix set, the breakdown is > as follows: > > * URM, PRM and USD: I got these done already, only need to write new > colophons to be added to the end of each book. These are the ones I > am hoping to put out Real Soon Now. > > * PS1, PS2 and SMM remain to be worked on, but are part of my more > distant plans. > > * The "Master Index" volume, I plan to skip that one - too difficult, > and non-essential in my view. > > And yes, I am much more "perfectionist" about replicating troff details > than BSW was for his V7 PDF version. > > M~ > From arnold at skeeve.com Sun Jan 7 22:12:21 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 07 Jan 2024 05:12:21 -0700 Subject: [TUHS] Original print of V7 manual? In-Reply-To: <202401071055.407Ast6p014321@cuzuco.com> References: <20240105221729.371EA37401DA@freecalypso.org> <20240106030254.B8D7537401FF@freecalypso.org> <20240106032236.llpryldqt7lbondn@illithid> <202401071055.407Ast6p014321@cuzuco.com> Message-ID: <202401071212.407CCLGa001414@freefriends.org> Thanks for this history Brian. It was a long time ago, but I think all I did was figure out how to turn the PDF back into postscript, since I had a postscript printer at the time and it was easier for me to print postscript. I sent the files to Dennis _only_ with the thought that they might be useful to other people, and certainly with no intent to steal any credit. Your files were great; I printed out hardcopy at the time and still have them on a shelf in my basement. Thanks! Arnold Brian Walden wrote: > Since this is my work, and it was the first PDF produced from the troff > sources. So let me set the stage, and this should answer some of the > issues you and others have with my work. This was 25 years ago. > There were not any scanned images of these documents it be > found anywhere online. There was only the incomplete troff sources that were > available on a bell labs web page, and that was hardly usable. I wanted an > online human readable, computer searchable and a print it anywhere document. > That meant one format to me, PDF. > > So I went about to produce one. It was so much harder than anticipated. > I spent a lot of my spare time doing it, it took me months to complete. > Someone all ready posted my notes on how I made it in an earlier message. > Once I got it to a state where I was happy with it, I stopped. Also the > only thing I had to compare my version to was a physical copy of a reprint > of the The Bell System Technical Journal Vol 57, No 6, Part 2, July-August > 1978 (It had a red cover with the AT&T death star logo, not the original blue > cover, nor the 1984 version with a yellow cover). And the book's pages > were not US printer paper size of 8.5"x11" but were 5"x8". > > It was made under Solaris 2.6, on an Ultra 2 ("Pulsar"), using the troff, tbl, > eqn, pic, refer and macros as supplied by Sun at that time, and NOT any GNU > ones. Why? These were the versions written by AT&T that Sun got directly from > them during their SVR4 collaboration. I used the PostScript output option to > troff (which obviously did not exist in 1979). That code to produce PostScript > outout, had a high probability of being written by the graphics group run by > Nils-Peter Nelson in Russ Archer's Murray Hill Computer Center (department > 45268). As in the mid 1980s, the computer centers had a SRP (small remote > printer) initiative that deployed QMS laser printers (they could only do > PostScript level 1) in common areas near where their users were, and connected > via datakit or direct serial lines. These QMS printers obsoleted the large > and chemically nasty phototypesetters, so they all disappeared from the > computer centers. > > Anyway, now I have a whole bunch of PostScript files, that is hardly > usable to read on screen. Nor very searchable, and ONLY printable on > PostScript printers. The place I was working at the time decided to save > a few dollars, they did not get Adobe licenses for most of their printers, > so they could only print PCL. Luckily the free Adobe Acrobat Reader (version 3) > which was available on most platforms, could print to PCL. So I need to convert > this into PDF. In 1998 there are not too many options. I tried ghostscript but > it was too immature to produce anything acceptable to me. I ended up buying my > own Adobe Distiller out of pocket, the Windows 95 version, since it was much > cheaper than the Solaris as that was only available as a Distiller "server" > version. > > So I then transferred the PostScript files to my windows machine and turned > them into the 3 PDFs. But there was a bug in Distiller, it had and offset > problem on the lines of every tbl, eqn, or pic, on every platform it was > an obvious problem, either viewing it on screen or printing it (both PS and > PCL). So I wrote a awk script to modify many of the PostScript files to fix > the wrong offset. If you viewed or printed a modified PS file, it looked like > it had offset error, but now in the opposite direction. But once distilled > into a PDF, that PDF looked and printed like it should. So those modified PS > files wound be of no value to share. I then manually add the bookmarks and > blank pages that allowed two side printing using the same windows distiller. > > I had shown it to some others and they thought it was pretty great. But I > cannot publish nor host these as this is not my intellectual property and > I would need permission. At this time there was not very much available on > TUHS, some binary versions all without any source code, that you could boot > up on SIMH. > > I decided I should drop a note to Dennis Ritchie with a copy of the PDFs > to see what he tought. Since I had known Dennis slightly from my time working > at Murray Hill. I lived across the street from the labs on Burlington Rd and > skateboarded into work. It was just across the east employee parking lot, and I > would use that eastern entrance. Dennis also lived in the neighborhood, a > bit farther from the labs than me, in a cul-de-sac. For a full week once, > Dennis kept the complete opposite hours than I did. We would passed each other > at the guard station at the entrance. After a few times it got to be a bit > comical. Me entering 9ish, "good night Dennis" He would smile. Me leaving > 5-6ish: "good morning Dennis". We would exchange pleasantries. I had > to walk the skateboard past the guard a bit and not jump back on it, else the > guard would give chase, yelling not to skate in the hallway. I always had the > idea if someone wanted to sneak into the labs they'd just need to wait for > me to go in in the morning, and once the guard was chasing me, they could just > walk on in unchallenged. If you worked in MH from 1990-1992 and saw someone > on a black on top, neon green bottom skateboard, headed from 2F-164 to the > stock room, that was me. > > Dennis really like the PDFs, and we had a email discussion on what to do with > it as it was a derivative work of copyrighted material that I did not have the > rights to. He said he needed to do some checking (lawyers?). Eventually he > said they would host the PDFs, as it was their property, but would give me > full credit for producing it. And once it was freely available on their site, > anyone, including myself, could host copies. I provided Dennis with all the > added files and all the modified versions of their files, the new run shell and > sed scripts and even the awk postscript pre-distiller fixer script. He (or > Lucent) declined not put them up along side the PDFs, for whatever reason, > and since they were not providing them, I was not to give out those files > either. Only files I made myself or the files I found that were all ready > available by Lucent (such as the missing headers) were OK for me to host too. > This is that v7add.tar.gz file you found, that I only hosted. > > I also decided (and I told Dennis) I was going to make it so I could identify > the PDF files that was my work. In volume 2B, I fixed the typo "oe" to "one" > on the RATFOR paper, and I figured no one is going to put in a typo back in. > In volume 2A on the "UNIX Programming" page I left the .ND macro as is so > it would print the date it was troff'd (December 3, 1998). > > I did have a volume 2A that also had the correct 7th Edition C Reference Manual > in it. The one you get in my 1988 PDF is from the 6th Edition, notice it is > the old =+ syntax and not the += one. Dennis said that not even Lucent could > provide that as a free PDF, as it was a published book by Prentice-Hall. I > was asked to destroy all PDFs that had that version in it. > > I was going to do something similar to volume 1, but I forgot to do it > before that December 3rd run and it got sent to Dennis without a change. > And I was not going to tell Dennis and say hey pull that one down and put > this one up, thanks. Too late is simply too late. > > That at some point after they had been out for a while I noticed Dennis added > gzipped postscript versions of them, and credited it to Aharon Robbins, who > still posts here. I was upset at first, as it looked like half the credit was > going to someone who did a print to file and then ran gzip on it. And second, > the point of the PDF was so it could print anywhere, those cannot. Anyway > I got over it, as none it was mine to start with. And most would probably > use the PDF anyway. > > Larry McVoy asked me for my modified files to make the PDFs too, in 1999 or > 2000, for bitkeeper or bitsavers. But since I was not allowed to share them > and I had moved companies, I had lost them. I thought I had saved a copy but > I could no longer find it. I asked Dennis if he still had them, he did not. > This work is truly lost. > > The next, and last, time I saw Dennis was at the 2000 Summer USENIX in San > Diego. I just thought it was funny the looks I got from people when he came > up to me to say hello. > > -Brian > > Mychaela Falconia wrote: > > G. Branden Robinson wrote: > > > > > My belief, based on the evidence I have from these publications > > > colophons reporting which phototypesetter was used, is that the \(sq > > > special character was not filled in Graphic Systems C/A/T fonts used by > > > Bell Labs, > > > > I disagree. While the "NROFF/TROFF User's Manual" document proves > > that \(sq was hollow in all 3 fonts _as of 1976-10-11_ (the original > > date of this doc), bwk's document from 1978-08-04 indicates that this > > char had to have changed to a filled square by this date. However, > > troff in 1978 was still completely, utterly incapable of driving > > anything other than a C/A/T! Now bwk, the author of this doc, is the > > very same fine gentleman who wrote ditroff, the creature that was > > finally capable of driving a Linotron 202 or Autologic APS-5 or > > whatever - but the timeline does not match up. BWK's troff tutorial > > is dated 1978-08-04, but his work on ditroff (as I understand it) > > happened some time around 1980 or 1981. He may have started ditroff > > work in 1979, but definitely not in 1978. > > > > > but _was_ filled in the bold face by the Autologic APS-5. > > > > 4.3BSD Usenix books prove otherwise: these must have been troffed on > > APS-5, as many notes from that time attest, but they feature hollow > > square in bold. Even eqnchar(7) is "wrong" in 4.3BSD print in that > > "blot" is a hollow square, clearly counter to original intent of that > > named eqn character. > > > > > I have documented this understanding in the groff_char(7) man page, > > > > Ahh, so you are involved with groff - got it. I wrote my own version > > of troff (based on V7, running under 4.3BSD and directly emitting > > DSC-conforming PostScript) in 3 "bursts" of work around 2004, 2010 and > > 2012, but I never got around to releasing it. I am now in the process > > of cleaning it up for release, hoping to finally have it out in another > > week or two. And I put a _lot_ of work into replicating the original > > troff character set... > > > > > Also, my copies of these books are overseas, but I seem to remember that > > > the Holt/Reinhart/Winston (HRW) 1983 reprint of the Seventh Edition > > > > Thank you for clarifying what HRW is - so this 1983 version of 7th ed > > UPM is *not* the original? > > > > > > What was the physical form of this book? Was it a "perfect bound" > > > > book? > > > > > > The HRW copies I have are perfect bound. But I can't remember if they > > > were 3-hole punched as well. > > > > Thank you for the clarification! But if HRW version is not the > > original, then what was the original like? > > > > > Where did you discover the identity and date of the 1998 retypeset of > > > the V7 Volume 2 manual? > > > > https://plan9.io/7thEdMan/bswv7.html > > http://web.cuzuco.com/~cuzuco/v7/ > > > > The second page includes a link to this tarball: > > > > http://web.cuzuco.com/~cuzuco/v7/v7add.tar.gz > > > > Dates inside that tarball are 1998-12-13. There was also a place > > where Brian missed the retroffing date - see page 287 of his > > v7vol2a.pdf. > > > > > I have wondered about this for years. In part > > > to complain, because while it is a _fairly_ faithful reproduction of the > > > original, it is not perfect, > > > > What _I_ don't like about BSW's PDF rendition of V7 manuals is that it > > is a sort of "closed source" product: there is no published source > > package that retraces every step in the flow from ancient troff sources > > to the finished product. > > > > In the same 3 "bursts" of activity (2004, 2010 and 2012) when I worked > > on my own version of troff, I also worked toward doing a PostScript > > reprint of 4.3BSD Usenix books. 4.3BSD happens to be my personally > > preferred version of UNIX, but the same methods I use for 4.3BSD books > > can also be applied to V7. I am hoping that in the next week or two I > > will find time to release not only my version of troff, but also the > > partial set of 4.3BSD books I got done so far. > > > > Out of the 7 books that comprise 4.3BSD Usenix set, the breakdown is > > as follows: > > > > * URM, PRM and USD: I got these done already, only need to write new > > colophons to be added to the end of each book. These are the ones I > > am hoping to put out Real Soon Now. > > > > * PS1, PS2 and SMM remain to be worked on, but are part of my more > > distant plans. > > > > * The "Master Index" volume, I plan to skip that one - too difficult, > > and non-essential in my view. > > > > And yes, I am much more "perfectionist" about replicating troff details > > than BSW was for his V7 PDF version. > > > > M~ > > From douglas.mcilroy at dartmouth.edu Sun Jan 7 23:42:03 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sun, 7 Jan 2024 08:42:03 -0500 Subject: [TUHS] Original print of V7 manual? Message-ID: >> What was the physical form of this book? Was it a "perfect bound" >> book? > The HRW copies I have are perfect bound. But I can't remember if they > were 3-hole punched as well. The Holt Rinehart edition was 3-hole punched. The original V7 (and its predecessors) were prepared for AT&T standard 4-hole binders, but distributed in Accopress binders that used only 2 of the 4. 4-hole paper was punched 2" and 3 3/8" from top and bottom of 11" paper. This reduced the stress concentration that makes the isolated end holes in 3-hole paper vulnerable to tearing out. It was a let-down when AT&T eventually acceded to a sort of loose-leaf Gresham's law and switched to 3 holes. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at ultimate.com Mon Jan 8 01:27:57 2024 From: phil at ultimate.com (Phil Budne) Date: Sun, 07 Jan 2024 10:27:57 -0500 Subject: [TUHS] Early supported UNIX manual In-Reply-To: <429f452e-eee9-5b8f-ffa4-07dea148cede@bitsavers.org> References: <202212221852.2BMIqMRk003859@ultimate.com> <429f452e-eee9-5b8f-ffa4-07dea148cede@bitsavers.org> Message-ID: <202401071527.407FRvT0019300@ultimate.com> > https://bitsavers.org/pdf/att/unix/6th_Edition/ When I showed my copy of the manual to Dennis Ritchie at a Usenix, and asked him to identify it (and autograph it), he described it as "very early supported UNIX". I think of "Nth Edition" or "Version N" as releases (of the manual) from the "research" group, and this manual is for something _close_ to 6th Edition, but it's not, in the strict sense, v6. Not that I can tell you an easy name for what to call it! From tuhs at tuhs.org Mon Jan 8 03:21:14 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sun, 07 Jan 2024 17:21:14 +0000 Subject: [TUHS] Early supported UNIX manual In-Reply-To: <202401071527.407FRvT0019300@ultimate.com> References: <202212221852.2BMIqMRk003859@ultimate.com> <429f452e-eee9-5b8f-ffa4-07dea148cede@bitsavers.org> <202401071527.407FRvT0019300@ultimate.com> Message-ID: On Sunday, January 7th, 2024 at 7:27 AM, Phil Budne wrote: > Not that I can tell you an easy name for what to call it! I've just been referring to these as "PGs" for short, so USG PGII. The MERT manual on the archive is visually similar to this one, as one would expect since it is based on PGIII. Very very cool to see this finally, thanks Al! One more down, I believe someone on list has confirmed ownership of a PGIII manual as well, but I'm not sure if the very first issue even had print manuals distributed. Program Generic is a bit obscure given the earliness of it but my understanding is that it served both as the standard supported UNIX for computer users in the Bell System *and* as the standard base for UNIX-based projects that weren't butted right up against research (e.g. MERT.) I've seen this "Generic" nomenclature used for other such things in Bell System literature, representing a "stock" version of some technology prior to differentiation into separate products. It's actually used later in UNIX releases too, a 3B20S document refers to the UNIX Release as the time as "the latest Generic(sic)". I believe this capitalization points to similar naming influences. First thing I looked for but couldn't find is a reference to what macro package was used for these documents. You can see the same style in both the PGII program description document and the MERT 0 manual. I suspect there's some connection between this and the OSDD package but that's currently just an assumption based on this also looking somewhat BSP-ish in select code, date, etc presentation in the header. The existence of the program description document leads me to believe there were other such secondary documents distinct from the Volume 2 documents, but this is just a hunch. Either way, this'll certainly help my manual diffing efforts! - Matt G. From aaronscohen at gmail.com Mon Jan 8 07:40:02 2024 From: aaronscohen at gmail.com (Aaron) Date: Sun, 7 Jan 2024 16:40:02 -0500 Subject: [TUHS] Fwd: Re: Fred Grampp References: <202401062316.406NFxKA000795@cuzuco.com> Message-ID: <6FC39B03-961D-4A6D-9E1F-D5239892D72D@gmail.com> Ah, Fred Grampp—brings back memories. For several years Fred had an office next to mine in Building 7 @ Murray Hill. I used to come in early to share a pot of lapsang souchong tea and listen to Fred’s stories. I still retell some of them today. In 1981 Fred picked us up at Newark Airport when my wife and I returned from vacation. He told me my Department Head was perturbed that he couldn’t reach me while we were away (I hadn’t left a contact number). He then (while driving) opened two cans of beer to toast my promotion to supervisor which had been announced. I was duly surprised. Begin forwarded message: > From: Brian Walden > Date: January 6, 2024 at 6:25:28 PM EST > To: tuhs at tuhs.org > Subject: [TUHS] Re: Fred Grampp > > This isn't directly UNIX related, and yes, the thread is 3 years old. But since it made national news last night, probably due to its proximity to Newark Airport. The enormous fire in Elizabeth, NJ, I recognized in the local news as the old Singer factory. That factory was the catalyst that linked me into finding out more on Fred Grampp, and his ancestry. > > Here's a non-paywalled link that also mentions it is indeed the old Singer factory: https://newjersey.news12.com/elizabeth-nj-fire-industrial-building > > >> On Tue, Mar 16, 2021 at 11:12 AM M Douglas McIlroy wrote: >> >> Serendipitous find! I hadn't realized that Fred had been the third >> generation in the hardware store. >> His father ("Pops") retired to Drayton Island in the St Johns River >> about 60 miles south of Jacksonville. >> Fred often visited him, driving the 19-hour trip in one stint. >> >> Doug >> >>> On Mon, Mar 15, 2021 at 6:47 PM Brian Walden wrote: >>> >>> Amazing coincidences. A week prior I was researching Topper Toys >>> looking for their old factory ("largest toy factory in the world") >>> As there was litte on it's location and it lead me to find out >>> in 1961 it took over the old Singer Factory in Elizabeth, NJ. >>> So looking up the Singer factory led me to "Elizabeth, >>> New Jersey, Then and Now" by Robert J. Baptista >>> >>> https://ia801304.us.archive.org/11/items/ElizabethNewJerseyThenAndNowSecondEdition2015/ElizabethNewJerseyThenNowThirdEditionApril102018607Pages.pdf >>> >>> Which had no information on Topper, but had had this paragraph in it's Singer >>> section on page 28 -- >>> >>> Boys earned money "rushing the growler" at lunchtime at the Singer plant. >>> German workers lowered their covered beer pails, called growlers, on ropes >>> to the boys waiting below. They earned a nickel by filling them with beer >>> at Grampp's saloon on Trumbull St. One of these boys was Thomas Dunn who >>> later became a long term Mayor. In the early 1920s Frederick Grampp went >>> into the hardware business at the corner of Elizabeth Ave. and Reid St. >>> >>> >>> When I read it I thought funny, as I know the name Fred Grampp. But beleived >>> just a coincidenental same name. After reading the biography post, I went back >>> to the book as it turns out that Fred Grampp is your Fred Grampps's >>> grandfather. You can find more his family and the hardware store and >>> Grampp himself on pages 163-164, and 212. >>> >>> -Brian >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From falcon at freecalypso.org Mon Jan 8 07:59:20 2024 From: falcon at freecalypso.org (Mychaela Falconia) Date: Sun, 07 Jan 2024 13:59:20 -0800 Subject: [TUHS] My own version of troff Message-ID: <20240107215931.4C9043740235@freecalypso.org> Hello fellow lovers of old UNIX, After almost 20 y of intermittent development (started in the fall of 2004), I just made the first official release of my version of troff: https://www.freecalypso.org/pub/UNIX/components/troff/qjtroff-r1.tar.Z https://www.freecalypso.org/pub/UNIX/components/troff/qjtroff-r1.tar.gz (The .Z is the native format; the .gz is for greater accessibility.) The README file inside the tarball gives the full story, but basically it is my own derivative from classic V7 troff (not derived from ditroff, and certainly not groff) that runs under 4.3BSD and emits PostScript. Only PS output is supported, no non-PS targets of ditroff. I started it in 2004, but I still use it to this day (on a real MicroVAX running my "organically grown" 4.3BSD variant) to write various TPS reports and technical manuals etc, for my other projects that don't have much of anything to do with Ancient UNIX. For anyone who loves intricacies of troff and/or PostScript, you might find the source code quite interesting to study. :) Some Time Soon I am hoping to put out my PostScript reprint of the first 3 books of the 4.3BSD manual set (namely, URM, USD and PRM books) made with this troff. The actual book reformatting job is already done (for these 3 books, not for the other 3 yet), but I need to write new colophons to be appended (with pstmerge, a tool from my troff suite) at the end of each book. (The colophons I wrote for URM and PRM back in 2012 are in need of corrections and updates, and I didn't have the USD book done in 2012.) I will also be responding to BSW's detailed account of V7 PDF reprint in the other thread shortly - but I wanted to get this troff release out first, so I won't be in a position of saying "please look at my creation" when that creation is not publicly accessible. M~ From falcon at freecalypso.org Mon Jan 8 10:20:35 2024 From: falcon at freecalypso.org (Mychaela Falconia) Date: Sun, 07 Jan 2024 16:20:35 -0800 Subject: [TUHS] Original print of V7 manual? In-Reply-To: <202401071055.407Ast6p014321@cuzuco.com> References: <20240105221729.371EA37401DA@freecalypso.org> <20240106030254.B8D7537401FF@freecalypso.org> <20240106032236.llpryldqt7lbondn@illithid> <202401071055.407Ast6p014321@cuzuco.com> Message-ID: <20240108002046.18A2A37401CC@freecalypso.org> Hi Brian, > Since this is my work, and it was the first PDF produced from the troff > sources. So let me set the stage, and this should answer some of the > issues you and others have with my work. This was 25 years ago. Thank you for this very detailed account! It certainly helps clear the air, and helps people like me (who weren't there at the time) understand this history a little better. > So I went about to produce one. It was so much harder than anticipated. > I spent a lot of my spare time doing it, it took me months to complete. > Someone all ready posted my notes on how I made it in an earlier message. > Once I got it to a state where I was happy with it, I stopped. I am doing something similar with 4.3BSD manuals. When I started on this quest in 2004, I didn't have any reference for how the original looked, I was flying blind, and the draft I produced that year was so poor (by my own judgment) that I never took it further. In 2010 I was able to score a real paper copy (relic) of 4.3BSD Usenix print, I made some improvements to my troff, but then I had to put it down and switch to other projects. I picked it up again in 2012, got URM and PRM books done (these are easy, man pages only, 4.3BSD equiv of Vol1), was working on USD book (first big book of supplementary docs, has all docs for troff suite), but then again I got switched to a different (and very big) project, the one in my current domain name. I am revisiting it now, and I was _*very*_ pleased when I found published scans on archive.org, by Erica Fischer, of all Usenix books from *both* 4.2BSD and 4.3BSD sets, uploaded in 2017. Now I don't have to feel guilty about "hoarding" my treasured physical copy of the original Usenix 4.3BSD print! I still desire to finish my PostScript reprint of all 6 4.3BSD books: the historical ones I got are very fragile, the plastic binding combs already got several broken teeth, and given that I like to use 4.3BSD "for real", I would really love to have physical reference books on my bookshelf that aren't fragile and can take abuse - hence the desire for a new physical print. Plus the feel-good of publishing PostScript files, one perfectly DSC-conforming PS file for each book, that anyone in the community can do with as they please, plus full recipes for recreating them... If someone desires a more perfectionist PostScript reprint of the V7 manual, let's revisit this discussion in another few weeks when I put out my current reprints of 4.3BSD URM, USD and PRM - it will be easier to refer to those when discussing possible ideas for V7. > It was made under Solaris 2.6, on an Ultra 2 ("Pulsar"), using the troff, tbl, > eqn, pic, refer and macros as supplied by Sun at that time, and NOT any GNU > ones. Why? These were the versions written by AT&T that Sun got directly from > them during their SVR4 collaboration. I used the PostScript output option to > troff (which obviously did not exist in 1979). You did the right thing: the version you used certainly feels much more "right" than anything from GNU. > That code to produce PostScript > outout, had a high probability of being written by the graphics group run by > Nils-Peter Nelson in Russ Archer's Murray Hill Computer Center (department > 45268). So it is a different ditroff-to-PS chain than psdit from Adobe Transcript? I am not too familiar with the latter, as I ended up writing my own troff (derived from V7 version, just published) that emits PS directly, but it is my understanding that Back In The Day most people used psdit for this type of workflow. > I did have a volume 2A that also had the correct 7th Edition C Reference > Manual > in it. The one you get in my 1988 PDF is from the 6th Edition, notice it is > the old =+ syntax and not the += one. Dennis said that not even Lucent could > provide that as a free PDF, as it was a published book by Prentice-Hall. I > was asked to destroy all PDFs that had that version in it. Ouch, until you pointed it out in this ML post, I hadn't even noticed that the C Reference Manual doc is "wrong" in your PDF version! But here comes the really important question: if you once had a PDF reprint with the "right" version of this doc, where did you get the troff source for it? This is the source that was actually censored from the V7 tape: https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/doc/cman I don't have this problem for my 4.3BSD reprint: the source for 4.3BSD version of this doc is included on the tape; the corresponding SCCS log begins with "document received from AT&T", checked in on 86/05/14, and then revised by BSD people into what they wanted printed in their version of the manual. But if someone wishes to do a *proper* reprint of the V7 manual (or 4.2BSD, where this doc and many others were literally unchanged duplications from V7 master at the plate level), we need the troff source for the V7 version of this doc. If this source is totally lost, we as in community can probably do an OCR from a surviving scan (for example, the one in 4.2BSD PSD book) and then painstakingly produce a new troff source that would format into an exact replica - but if there is a leaked copy of the original source somewhere, it would certainly make our job way easier. > Larry McVoy asked me for my modified files to make the PDFs too, in 1999 or > 2000, for bitkeeper or bitsavers. But since I was not allowed to share them > and I had moved companies, I had lost them. I thought I had saved a copy but > I could no longer find it. I asked Dennis if he still had them, he did not. > This work is truly lost. Aside from the unresolved issue of "cman" document, we as in community can produce an even better work if we so wish. I am deferring a more detailed discussion until I put out my 4.3BSD PS reprint, so I can point to it as a reference for how I like to do things, and maybe by then we'll have some clarity on what happened to V7 "cman" troff source. M~ From g.branden.robinson at gmail.com Mon Jan 8 13:24:28 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Sun, 7 Jan 2024 21:24:28 -0600 Subject: [TUHS] Original print of V7 manual? / My own version of troff In-Reply-To: <20240108002046.18A2A37401CC@freecalypso.org> <20240107215931.4C9043740235@freecalypso.org> Message-ID: <20240108032428.co3ozmlneoop6sa2@illithid> At 2024-01-07T16:20:35-0800, Mychaela Falconia wrote: > > It was made under Solaris 2.6, on an Ultra 2 ("Pulsar"), using the > > troff, tbl, eqn, pic, refer and macros as supplied by Sun at that > > time, and NOT any GNU ones. Why? These were the versions written by > > AT&T that Sun got directly from them during their SVR4 > > collaboration. I used the PostScript output option to troff (which > > obviously did not exist in 1979). > > You did the right thing: the version you used certainly feels much > more "right" than anything from GNU. This sort of broad, nonspecific, reflexive derogation of groff (or GNU generally) is unproductive and frequently indicative of ignorance. Admittedly, groff does not attempt pixel-perfect reproduction of classic Unix documentation, particularly not C/A/T output. There's a good reason for that, and one that will challenge your efforts as well, if you draw your scope as far back as the C/A/T. (If your horizon is 4.3BSD documents rendered as PostScript, you may be in luck.) The problem is fonts. The C/A/T's fonts did not even exist in the digital domain. They were produced from photographic plates. Their reproduction is consequently something of a pickle. The good news is that the Adobe PostScript Times faces and their URW clone are "pretty close" equivalents. Close enough that I was able to reproduce Kernighan & Cherry's "Typesetting Mathematics User's Guide -- Second Edition" (a.k.a. "the eqn manual") with fairly high fidelity. https://github.com/g-branden-robinson/retypesetting-mathematics This work required (1) some bug fixes to the GNU ms macros, now applied; and (2) fine-tuning of the line length and page offset to compensate for the different metrics of Adobe/URW Times versus the C/A/T's. There is a third problem, whose resolution is in progress, when producing PDF output from this document; slanted Greek symbols are present but "not quite right". This is because unlike PostScript, PDF font repertoires generally don't provide a "slanted symbol" face. gropdf author Deri James has committed some work to groff's Git repository synthesizing such a face. We expect it in groff 1.24. But if you are going for pixel-perfect reproduction of documents that used fonts you don't have, you're going to need to recreate the fonts somehow--perfectly (at least for the glyphs that a given document uses). One of the reasons Knuth was able to be so meticulously perfectionistic with TeX and avoid regressions at the pixel placement level is because he developed his own fonts along with just about everything else. AT&T troff did not make that choice. Like AT&T troff, groff attempts to be a practical typesetting system. One way I measure its success is by the fact that practiced AT&T troff users like Brian Kernighan[1] and Doug McIlroy[2] use it for the composition of new works, and speak of it with approval. (Doug reports bugs, some of which we manage to address.) groff is not, primarily, a vehicle for nostalgia trips. > After almost 20 y of intermittent development (started in the fall of > 2004), I just made the first official release of my version of troff: > > https://www.freecalypso.org/pub/UNIX/components/troff/qjtroff-r1.tar.Z > https://www.freecalypso.org/pub/UNIX/components/troff/qjtroff-r1.tar.gz But there is room in the world for such things, particularly if they are Free Software. I was unable to determine that qjtroff is, except for a few portions retaining UC Regents' copyright notices from the 1980s,[3] and if these contain further original work by you (or others), then the lack of a clear copyright notice and licensing information renders the project "all rights reserved", meaning among other things that people cannot redistribute to others, let alone make modifications--say, to add the documentation that is not present. README: > Documentation: in 2012 I started writing a proper manual, but ran out > of time (had to switch to other projects). Because it can easily be > another year or two or ... before I can get back to that documentation > and finish it, I decided to release this software as-is, without docs. > Too many projects, too little time... In any event, the groff mailing list is the de facto water cooler for all *roff developers, and I invite you to join it to stay abreast of developments. Discussion of non-groff *roffs is rare but welcomed. Since there is no standard for *roff, it is the most useful forum for discussion of, for instance, unspecified details of formatter or macro package behavior. (Unfortunately, sometimes people ask for help with Heirloom Doctools troff and receive solutions that are applicable only to groff; Heirloom's own community seems sadly too shy, or perhaps too attenuated, to share its expertise.) Regards, Branden [1] https://technicallywewrite.com/2023/06/01/groff [2] https://lists.gnu.org/archive/html/groff/2023-07/msg00062.html [3] There were also Adobe copyright notices in AFM files, which are not necessarily a problem since font _metrics_ are not copyrightable[4] and of course several false positives arising from the existence of "copyright" as a named glyph in fonts. [4] At least not in the United States, and perhaps not in many countries of the world that are signatories to the various trade treaties (URAA-GATT, TRIPS, and so forth) through which WIPO has exported U.S. copyright law to a nearly global scope. IANAL. TINLA. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From falcon at freecalypso.org Mon Jan 8 15:10:38 2024 From: falcon at freecalypso.org (Mychaela Falconia) Date: Sun, 07 Jan 2024 21:10:38 -0800 Subject: [TUHS] Original print of V7 manual? / My own version of troff In-Reply-To: <20240108032428.co3ozmlneoop6sa2@illithid> References: <20240108032428.co3ozmlneoop6sa2@illithid> Message-ID: <20240108051049.7643537404E9@freecalypso.org> G. Branden Robinson wrote: > This sort of broad, nonspecific, reflexive derogation of groff (or GNU > generally) is unproductive and frequently indicative of ignorance. I don't have enough spoons to engage in political fights any more, so I'll just focus on technical aspects. > The C/A/T's fonts did not even exist in the digital domain. They were > produced from photographic plates. Their reproduction is consequently > something of a pickle. I am very keenly aware of this fact! > But if you are going for pixel-perfect reproduction of documents that > used fonts you don't have, you're going to need to recreate the fonts > somehow--perfectly (at least for the glyphs that a given document uses). The problem you are describing is one which I am *not* actively working on presently. I am _contemplating_ this problem, but not actively working on it. In my current stage of 4.3BSD document set reprinting, I am willing to accept that hyphenations, line breaks and page breaks will be different from the original because of slightly different font metrics, and accept the use of only fi and fl ligatures (in running text, outside of explicit demonstrations) because Adobe's version dropped ff, ffi and ffl. (In places where original troff docs explicitly demonstrate the use of all 5 ligatures, I have a hack that pulls the missing ligs from a different, not-really-matching font.) I am willing to accept this imperfection because it is fundamentally no different from what UCB/Usenix themselves did in 1986: they took Bell Labs docs that were originally written for CAT and troffed them on their APS-5 ditroff setup - but those two typesetters also had slight diffs in their font metrics, causing line and page breaks to move around! OTOH I am very willing to entertain, as an intellectual exercise, what would it take to produce a new font set that would *truly* replicate the CAT font set at Bell Labs. The spacing widths of the original fonts (the key determinant of where breaks will land) are known, right here: https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/troff/tab3.c Back in 2004 in one afternoon I threw together a quick-hack program that takes the output of original troff (CAT binary codes) and prints it in PostScript, using standard Adobe fonts. The character positioning is that of original troff, but because the actual font characters don't perfectly match these metrics, the result is not pretty - but the non-pretty result does show *exactly* where every line and page break lands per original intent! So what would it take to do such a re-creation properly? My feeling is that the task would require hiring a professional typeface designer to produce a modified version of Times font family: modify the fonts to produce good visual results (change actual characters as needed) to fit the prescribed, unchangeable metrics as in spacing widths. And design all 5 f-ligatures while at it. I have no slightest idea how much it would cost to hire a professional typeface designer to do what I just described, hence I have no idea whether or not it is something that the hobbyist community could potentially afford, even collectively. But it is an interesting idea to ponder nonetheless - which is where I leave it for now. > There is a third problem, whose resolution is in progress, when > producing PDF output from this document; slanted Greek symbols are > present but "not quite right". This is because unlike PostScript, PDF > font repertoires generally don't provide a "slanted symbol" face. Can you please elaborate? I personally hate PDF with a passion, but I concede that in order to make my documents readable by people other than me, I have to rcp my .ps file from the 4.3BSD machine to a semi-modern-ish (Slackware) Linux box and run ps2pdf on the file. But what "slanted symbol" font are you talking about that exists in PostScript but not in PDF? The only PostScript fonts whose existence I take as a given (as opposed to downloading the font explicitly) are the standard 14: 4 Times family fonts, 4 Helvetica family fonts, 4 Courier family fonts, Symbol and ZapfDingbats. Which of these 14 is missing in PDF, and how does "standard" ps2pdf (Ghostscript) handle it? > Like AT&T troff, groff attempts to be a practical typesetting system. I wrote *my* version of troff with exact same goals, and I've been using it as my personal everyday TPS report formatter for the past 20 y. It's just that for deeply personal reasons which I would rather not go into on this list, I chose to develop my own tool instead of using one that bears GNU branding. I also wanted my troff to run under 4.3BSD, using only K&R C, which I reason would probably be impossible with groff. (I recall reading somewhere that groff is written in C++ - so it is completely out of consideration for something that needs to run under 4.3BSD.) > But there is room in the world for such things, particularly if they are > Free Software. I was unable to determine that qjtroff is, except for a > few portions retaining UC Regents' copyright notices from the 1980s,[3] My software is written BY a pirate (me) FOR other pirates. If you are not a pirate, my sw is not for you. M~ From g.branden.robinson at gmail.com Mon Jan 8 17:11:09 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Mon, 8 Jan 2024 01:11:09 -0600 Subject: [TUHS] Original print of V7 manual? / My own version of troff In-Reply-To: <20240108051049.7643537404E9@freecalypso.org> References: <20240108032428.co3ozmlneoop6sa2@illithid> <20240108051049.7643537404E9@freecalypso.org> Message-ID: <20240108071109.ykg42tw2gjeacs5f@illithid> At 2024-01-07T21:10:38-0800, Mychaela Falconia wrote: > G. Branden Robinson wrote: > > > This sort of broad, nonspecific, reflexive derogation of groff (or > > GNU generally) is unproductive and frequently indicative of > > ignorance. > > I don't have enough spoons to engage in political fights any more, so > I'll just focus on technical aspects. That may be a wise choice. A good supplement would be, when expressing a negative opinion of GNU or any software project to which people contribute their volunteer labor, to briefly state your grounds for not using it. "I just can't go along with the copyleft thing" or "I refuse to use anything written in C++" might or might not strike people as rational, but such frankness places the responsibility for starting an argument squarely on _their_ shoulders. Any issues people have with groff's implementation quality should be submitted to its bug tracker. (One can do so anonymously, or create an account to be emailed when subsequent activity happens.) There are plenty of defects demanding repair and features needing implementation. I wish there were fewer. I do what I can. https://savannah.gnu.org/bugs/?group=groff > > But if you are going for pixel-perfect reproduction of documents > > that used fonts you don't have, you're going to need to recreate the > > fonts somehow--perfectly (at least for the glyphs that a given > > document uses). > > The problem you are describing is one which I am *not* actively > working on presently. I am _contemplating_ this problem, but not > actively working on it. In my current stage of 4.3BSD document set > reprinting, I am willing to accept that hyphenations, line breaks and > page breaks will be different from the original because of slightly > different font metrics, and accept the use of only fi and fl ligatures > (in running text, outside of explicit demonstrations) because Adobe's > version dropped ff, ffi and ffl. (In places where original troff docs > explicitly demonstrate the use of all 5 ligatures, I have a hack that > pulls the missing ligs from a different, not-really-matching font.) > > I am willing to accept this imperfection because it is fundamentally > no different from what UCB/Usenix themselves did in 1986: they took > Bell Labs docs that were originally written for CAT and troffed them > on their APS-5 ditroff setup - but those two typesetters also had > slight diffs in their font metrics, causing line and page breaks to > move around! Right. I think this is a reasonable place to erect a threshold of "fidelity" in document rendering, for two reasons: (1) when you don't have control over the fonts in use, it's likely the best you can do anyway, and (2) as a document author you might want to leave yourself room to change your mind about the typeface you use, particularly for running text (which will have the greatest impact on the locations of line and page breaks for most documents). That I was able to get the breaks in "Typesetting Mathematics" almost all the same as the published version even though the Times I used was certainly not the C/A/T's was a due to a combination of (a) good fortune and (b) the power of binary search when selecting values for the LL and PO registers. > OTOH I am very willing to entertain, as an intellectual exercise, what > would it take to produce a new font set that would *truly* replicate > the CAT font set at Bell Labs. The spacing widths of the original > fonts (the key determinant of where breaks will land) are known, right > here: > > https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/troff/tab3.c Right. Nowadays we call these (and other measurements besides width) the "font metrics". > Back in 2004 in one afternoon I threw together a quick-hack program > that takes the output of original troff (CAT binary codes) and prints > it in PostScript, using standard Adobe fonts. The character > positioning is that of original troff, but because the actual font > characters don't perfectly match these metrics, the result is not > pretty - but the non-pretty result does show *exactly* where every > line and page break lands per original intent! Nice! A tool I'd like to get added to groff someday is a modern "cat2dit". It's come up on these mailing lists before; apparently Adobe had a proprietary one back in the 1980s, and, as I recall, polymath wizard Henry Spencer wrote one but it's long since become a relic. John Gardner wrote yet another but it's in JavaScript so not maximally convenient for a Unix command line grognard. But best of all would be a "cat2dit" in Seventh Edition Unix-compatible C, because that would be super convenient for running on a PDP-11 under SIMH using Ossanna troff. The output would be easy to export because the device-independent troff output format is plain text (and not too strict about whitespace), and SIMH of course runs in a terminal window so it's easy to copy and paste. This would make it much easier to use Ossanna troff as a regression test bed for groff (or other modern formatters). > So what would it take to do such a re-creation properly? My feeling > is that the task would require hiring a professional typeface designer > to produce a modified version of Times font family: modify the fonts > to produce good visual results (change actual characters as needed) to > fit the prescribed, unchangeable metrics as in spacing widths. And > design all 5 f-ligatures while at it. Another approach would be to obtain the C/A/T font plates and describe them numerically. Since the only means of scaling was via an optical lens (from 6 to 36 points), we can conclude that they weren't "hinted" as digital fonts often are. Since those plates are presumably nearly all in landfills these days I suppose the same could be accomplished with sufficiently high-resolution scans of the copy of CSTR #54 in the Seventh Edition Unix manual (because it depicts all possibly glyphs). And of course if a person wants a gratuitous thing to put on their résumé/CV, you could obtain a large number of Times roman faces from a variety of foundries, render a huge volume of text using them in every possible combination and at a large number of sizes, and then use those renderings to train an LLM to generate an "archetypal" Times face for rendering C/A/T-produced documents. You then unleash it on the world and wait for the lawsuits to roll in, which should get a person enough notoriety to land a day job at someplace where the buzzword "AI" excites hard-charging middle managers. > I have no slightest idea how much it would cost to hire a professional > typeface designer to do what I just described, hence I have no idea > whether or not it is something that the hobbyist community could > potentially afford, even collectively. But it is an interesting idea > to ponder nonetheless - which is where I leave it for now. Hobbyist font designers do exist. Some may lurk on one or both of these lists. I would ask them if it's more or less a solved problem already. > > There is a third problem, whose resolution is in progress, when > > producing PDF output from this document; slanted Greek symbols are > > present but "not quite right". This is because unlike PostScript, > > PDF font repertoires generally don't provide a "slanted symbol" > > face. > > Can you please elaborate? I personally hate PDF with a passion, but I > concede that in order to make my documents readable by people other > than me, I have to rcp my .ps file from the 4.3BSD machine to a > semi-modern-ish (Slackware) Linux box and run ps2pdf on the file. Doug McIlroy still does this.[1] > But what "slanted symbol" font are you talking about that exists in > PostScript but not in PDF? The only PostScript fonts whose existence > I take as a given (as opposed to downloading the font explicitly) are > the standard 14: 4 Times family fonts, 4 Helvetica family fonts, 4 > Courier family fonts, Symbol and ZapfDingbats. Which of these 14 is > missing in PDF, and how does "standard" ps2pdf (Ghostscript) handle > it? Sorry, I elided too much from my response on this point. I should not have implied that "slanted symbol" is a standard PostScript font; it is not, per my copy of the _PostScript Language Reference Manual_ (3e) [see Appendix E]. "Slanted symbol", a.k.a. "SS", is a supplemental face in groff...of old provenance--it goes back to groff 1.06 (September 1992) at least. It exists to solve a problem that can be observed when you compare two documents already referenced above. 1. Adobe's _PostScript Language Reference Manual_, p. 794. Table E.13, "Symbol Encoding Vector" 2. CSTR #54 "Nroff/Troff User's Manual" (1976), p. 226*. Table I, "Font Style Examples" * using the page numbering in the HRW reprint of Volume 2 recently discussed on TUHS You will quickly observe that the C/A/T's "Special Mathematical Font", bearing the pellucid name "S" in the Ossanna/Thompson naming convention popular at Bell Labs, renders all its lowercase Greek letters in italic form. PostScript's Symbol font does not. A problem for any post-C/A/T typesetting is how to get upright versions of lowercase Greek letters. AT&T troff was engineered around the assumption that the lowercase Greek letters typically used for mathematical and scientific typesetting are slanted/italic rather than upright. This assumption is baked into the semantics of special character names *a, *b, *g, and so forth. (Except when using nroff, of course, where one "naturally" expects upright glyphs instead, just like the good old Greek box on the Teletype Model 37.) The eqn preprocessor furthermore--and consequently--assumes it doesn't need to do anything special for these special characters to show up in italics (making its rendering to terminals inconsistent with troff output). If you couldn't guess, I plan to change this in groff. It won't break eqn documents because what I "take away" in the semantics of the special characters (an implied font style, which doesn't belong there), I will "put back" via updated eqn character definitions, so people who say sin ( 2 theta ) ~ = ~ 2 ~ sin theta cos theta will continue to get what they expect. eqn users who bust down to *roff special characters to get Greek will, unfortunately, need to adapt. But GNU eqn has features to support doing so with minimal pain.[2] I have read that modern standards of mathematical typography mandate that constants, like every non-mathematician's favorite, π, should be set upright, not italicized as people of my generation (and I guess older ones) are accustomed to seeing it. The idea is that only _variables_ get italics. But I cannot speak further to this point, as it's well out of my wheelhouse. If it's true, I hope the increased flexibility I plan for groff and its eqn will make life easier for those who typeset math. https://savannah.gnu.org/bugs/index.php?64231 https://savannah.gnu.org/bugs/index.php?64232 gropdf(1) has not to date supported a slanted symbol font. But it needs to for the reasons explored on the groff list last June in a lengthy thread, the relevant portion of which starts here. https://lists.gnu.org/archive/html/groff/2023-06/msg00088.html > I also wanted my troff to run under 4.3BSD, using only K&R C, which I > reason would probably be impossible with groff. (I recall reading > somewhere that groff is written in C++ - so it is completely out of > consideration for something that needs to run under 4.3BSD.) Probably, unless someone wants to resurrect cfront... C is not my favorite programming language, and C++ even less so. In a better universe, by my lights, James Clark would have written groff in Ada. I acknowledge that a lot of people would characterize such a universe as a variety of Hell. > My software is written BY a pirate (me) FOR other pirates. If you are > not a pirate, my sw is not for you. Arrrrrr. I believe I take your meaning. Piracy is an occupational hazard of rentierism. Regards, Branden [1] https://lists.gnu.org/archive/html/groff/2023-08/msg00028.html [2] See eqn(1), subsection "Spacing and typeface". -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From kevin.bowling at kev009.com Tue Jan 9 12:54:31 2024 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Mon, 8 Jan 2024 19:54:31 -0700 Subject: [TUHS] SunOS 4.1.3 and 4.1.4 Release Manuals Message-ID: Would anyone happen to have a link to these? I am curious to read the changes in the final SunOS 4.1 versions and see how it yielded to Solaris during that period. Here is the 4.1.2 version for reference https://vtda.org/docs/computing/Sun/software/800-6645-10_SunOS4.1.2ReleaseManualRevA_Dec91.pdf. Regards, Kevin From tuhs at cuzuco.com Tue Jan 9 16:32:52 2024 From: tuhs at cuzuco.com (Brian Walden) Date: Tue, 9 Jan 2024 01:32:52 -0500 (EST) Subject: [TUHS] Original print of V7 manual? Message-ID: <202401090633.4096WqwR015447@cuzuco.com> Arnold, Thank you, it's nice to have one's work appreciated. And I know, you were doing exactly what I was doing, trying to make it more accessible to more people. And Dennis, being who he was, always gave credit where credit was do. There's nothing else he could or would have done. And like I said, it was long ago and has not bothered me in a very long time. Thanks for your continued dedication to gawk. Awk still just flows out of my fingers without even needing to think much or at all. Professionally, I have programmed in python for years, and have never gotten to the same level intimacy I have with awk. -Brian arnold at skeeve.com wrote: > Thanks for this history Brian. > > It was a long time ago, but I think all I did was figure out how > to turn the PDF back into postscript, since I had a postscript printer > at the time and it was easier for me to print postscript. > > I sent the files to Dennis _only_ with the thought that they might be > useful to other people, and certainly with no intent to steal any credit. > > Your files were great; I printed out hardcopy at the time and > still have them on a shelf in my basement. > > Thanks! > > Arnold From tuhs at cuzuco.com Tue Jan 9 18:24:32 2024 From: tuhs at cuzuco.com (Brian Walden) Date: Tue, 9 Jan 2024 03:24:32 -0500 (EST) Subject: [TUHS] Original print of V7 manual? Message-ID: <202401090824.4098OWBm019126@cuzuco.com> Mychaela Falconia falcon at freecalypso.org wrote: . . . > > It was made under Solaris 2.6, on an Ultra 2 ("Pulsar"), using the troff, tbl, > > eqn, pic, refer and macros as supplied by Sun at that time, and NOT any GNU > > ones. Why? These were the versions written by AT&T that Sun got directly from > > them during their SVR4 collaboration. I used the PostScript output option to > > troff (which obviously did not exist in 1979). > > You did the right thing: the version you used certainly feels much more > "right" than anything from GNU. I was just tryting to use the tool that would give the path of least resistance for that troff source. Even between flavors of UNIX in the 1980s, there were issues getting correctly formatted output bewteen Documenter's Workbench (DWB) and UCB. > > That code to produce PostScript > > outout, had a high probability of being written by the graphics group run by > > Nils-Peter Nelson in Russ Archer's Murray Hill Computer Center (department > > 45268). > > So it is a different ditroff-to-PS chain than psdit from Adobe > Transcript? I am not too familiar with the latter, as I ended up > writing my own troff (derived from V7 version, just published) that > emits PS directly, but it is my understanding that Back In The Day > most people used psdit for this type of workflow. The DWB way of troff to PostScript is -- $ pic file | tbl | eqn | troff -mm -Tpost | dpost >file.ps $ # if you want to print it near the "bird cage" printer, near a famous stair case in MH $ i10send -dbirdie -lpost file.ps $ # which would eventually call postio for you $ postio -l /dev/tty?? file.ps As this is pre-ethernet time, QMS printers are connected via RS-232 serial lines and postio does the communication to the printer. You can find dpost at https://www.tuhs.org/cgi-bin/utree.pl?file=OpenSolaris_b135/cmd/lp/filter/postscript/dpost/dpost.c (or at https://github.com/n-t-roff/DWB3.3/blob/master/postscript/dpost/dpost.c ) Looking at the last few lines of https://www.tuhs.org/cgi-bin/utree.pl?file=OpenSolaris_b135/cmd/lp/filter/postscript/README it is signed, Richard Drechsler MH 2F-241 x7442 mhuxa!drexler Which is that group I mentioned. Rich wrote dpost for sure, also if you look at the last person thanked in the Preface of The C programming Language, Second Edition (1988) -- Rich Drechsler helped greatly with typesetting. On a sad side note, Carmela L'Hommedieu, I was going to say "recently," but it's been almost four years now, who also worked in that group, has passed https://www.tributearchive.com/obituaries/10822663/Carmela-Scrocca-LHommedieu > > > I did have a volume 2A that also had the correct 7th Edition C Reference > > Manual > > in it. The one you get in my 1988 PDF is from the 6th Edition, notice it is > > the old =+ syntax and not the += one. Dennis said that not even Lucent could > > provide that as a free PDF, as it was a published book by Prentice-Hall. I > > was asked to destroy all PDFs that had that version in it. > > Ouch, until you pointed it out in this ML post, I hadn't even noticed > that the C Reference Manual doc is "wrong" in your PDF version! But > here comes the really important question: if you once had a PDF reprint > with the "right" version of this doc, where did you get the troff > source for it? This is the source that was actually censored from the > V7 tape: > > https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/doc/cman Yes that is the missing C Reference Manual. I was gifted the troff source for it, and unfortunately I do not have that gifted copy anymore. > > I don't have this problem for my 4.3BSD reprint: the source for 4.3BSD > version of this doc is included on the tape; the corresponding SCCS > log begins with "document received from AT&T", checked in on 86/05/14, > and then revised by BSD people into what they wanted printed in their > version of the manual. But if someone wishes to do a *proper* reprint > of the V7 manual (or 4.2BSD, where this doc and many others were > literally unchanged duplications from V7 master at the plate level), > we need the troff source for the V7 version of this doc. > > If this source is totally lost, we as in community can probably do an > OCR from a surviving scan (for example, the one in 4.2BSD PSD book) > and then painstakingly produce a new troff source that would format > into an exact replica - but if there is a leaked copy of the original > source somewhere, it would certainly make our job way easier. > > > Larry McVoy asked me for my modified files to make the PDFs too, in 1999 or > > 2000, for bitkeeper or bitsavers. But since I was not allowed to share them > > and I had moved companies, I had lost them. I thought I had saved a copy but > > I could no longer find it. I asked Dennis if he still had them, he did not. > > This work is truly lost. > > Aside from the unresolved issue of "cman" document, we as in community > can produce an even better work if we so wish. I am deferring a more > detailed discussion until I put out my 4.3BSD PS reprint, so I can > point to it as a reference for how I like to do things, and maybe by > then we'll have some clarity on what happened to V7 "cman" troff source. You will need to check on the legality of that. It is missing because it was published as Appendix A of the first edition of The C Programming Language in 1978 by Prentice-Hall, which means they (not Bell Labs, nor successor compaies, AT&T, Lucent, Alcatel, Nokia) contractually own the rights to it for some period of time. I you read Dennis' old home page at https://www.bell-labs.com/usr/dmr/www/ you'll see this verbage -- "The version of the C Reference Manual Postscript (250KB) or PDF, (79K) that came with 6th Edition Unix (May 1975), in the second volume entitled ``Documents for Use With the Unix Time-sharing System''. For completeness, there are also versions of Kernighan's tutorial on C, in Postscript or PDF format. There is also a slightly earlier (January 1974) version of the C manual, in the form of an uninterpreted PDF scan of a Bell Labs Technical Memorandum, visible here, if you can accommodate 1.9MB. No updated version of this manual was distributed with most machine readable versions of the 7th Edition, since the first edition of the `white book' K&R was published about the same time. The tutorial was greatly expanded into the bulk of the book, and the manual became the book's Appendix A. However, it turns out that the paper copies of the 7th Edition manual that we printed locally include not only what became Appendix A of K&R 1, but also a page entitled "Recent Changes to C", and I retyped this. I haven't been able to track down the contemporary machine-readable version (it's possible that some tapes were produced that included it). This is available in PostScript or PDF format." As we know from the recent public domaining of Mickey Mouse, copyright is retained 70 years past the date of death of the (last surviving) author. So if Brian Kernighan lives to the ripe old age of 101, this work cannot be used without permisson until 2113, unless the rights holders place it into the public domian before hand. Since the 1st edition is out of print, it's rights *may* have reverted back, but to which companies? Probabaly Nokia and AT&T jointy. But there is no way to know if you can use it, without an official notice of such. -Brian From falcon at freecalypso.org Tue Jan 9 19:05:45 2024 From: falcon at freecalypso.org (Mychaela Falconia) Date: Tue, 09 Jan 2024 01:05:45 -0800 Subject: [TUHS] Original print of V7 manual? In-Reply-To: <202401090824.4098OWBm019126@cuzuco.com> References: <202401090824.4098OWBm019126@cuzuco.com> Message-ID: <20240109090559.48A6937401DE@freecalypso.org> Brian Walden wrote: > You will need to check on the legality of that. I am not the type of person who cares about legalities; on the contrary, I consider it one of my life goals to break as many laws as possible before I croak. M~ From falcon at freecalypso.org Tue Jan 9 19:38:37 2024 From: falcon at freecalypso.org (Mychaela Falconia) Date: Tue, 09 Jan 2024 01:38:37 -0800 Subject: [TUHS] Original print of V7 manual? / My own version of troff In-Reply-To: <20240108071109.ykg42tw2gjeacs5f@illithid> References: <20240108032428.co3ozmlneoop6sa2@illithid> <20240108051049.7643537404E9@freecalypso.org> <20240108071109.ykg42tw2gjeacs5f@illithid> Message-ID: <20240109093851.2A29737401E3@freecalypso.org> G. Branden Robinson wrote: > Right. Nowadays we call these (and other measurements besides width) > the "font metrics". Not just "nowadays": font metrics has always been the standard term, including original troff days. But I specifically said "spacing widths" because it is the _only_ metric that matters for the purpose of pleasing otroff and keeping all line and page breaks where they were originally. All other metrics matter not in the "pleasing otroff" category, but in the category of "visual beauty" or "recreating exact appearance", which would be next-level-up from simply satisfying otroff. > You will quickly observe that the C/A/T's "Special Mathematical Font", > bearing the pellucid name "S" in the Ossanna/Thompson naming convention > popular at Bell Labs, renders all its lowercase Greek letters in italic > form. PostScript's Symbol font does not. Yes, this difference exists. However, let me point out that *both* official troff-to-PS toolchains that existed in traditional UNIX world (Adobe TranScript is one and Bell Labs DWB is the other) took the path of accepting non-slanted Greek letters as-is from Symbol. Seeing that Bell Labs themselves deemed this change as acceptable tells me that the slanted nature of lowercase Greek letters in original typesetter fonts (C/A/T, APS-5) was not considered an absolutely essential feature of these characters that MUST be preserved in every new troff implementation. > "Slanted symbol", a.k.a. "SS", is a supplemental face in groff...of old > provenance--it goes back to groff 1.06 (September 1992) at least. OK, fair enough: your lineage made a different choice in this regard. But seeing that both Adobe TranScript and Bell Labs' own later troff took the same approach as I took in my troff (using Symbol as-is), I don't feel guilty about not doing the same SS manipulation you do in groff. There is also a historical/timeline factor for me: A.D. 2010 was the first time I laid my eyes on the output of a traditional pre-PostScript troff typesetter (that was when I scored a physical copy of 4.3BSD books), and by that point I had been using my own troff for 6 y since 2004. Yes, I wrote it blindly at first: because of my younger age, I didn't get to live through the era of traditional typesetters, I totally missed it, but I needed a working troff under my then-production OS (4.3BSD) - so what was I supposed to do?... M~ From aek at bitsavers.org Wed Jan 10 02:27:03 2024 From: aek at bitsavers.org (Al Kossow) Date: Tue, 9 Jan 2024 08:27:03 -0800 Subject: [TUHS] Original print of V7 manual? / My own version of troff In-Reply-To: <20240109093851.2A29737401E3@freecalypso.org> References: <20240108032428.co3ozmlneoop6sa2@illithid> <20240108051049.7643537404E9@freecalypso.org> <20240108071109.ykg42tw2gjeacs5f@illithid> <20240109093851.2A29737401E3@freecalypso.org> Message-ID: Tracing the origins of the typefaces used on the GSI/Wang typesetter is a fun rathole going back to Singer Graphic Systems and to Singer-Friden (ie Flexowriter) before that From tuhs at tuhs.org Wed Jan 10 03:18:30 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 09 Jan 2024 17:18:30 +0000 Subject: [TUHS] Original print of V7 manual? / My own version of troff In-Reply-To: References: <20240108032428.co3ozmlneoop6sa2@illithid> <20240108051049.7643537404E9@freecalypso.org> <20240108071109.ykg42tw2gjeacs5f@illithid> <20240109093851.2A29737401E3@freecalypso.org> Message-ID: On Tuesday, January 9th, 2024 at 8:27 AM, Al Kossow wrote: > Tracing the origins of the typefaces used on the GSI/Wang typesetter is a fun rathole > going back to Singer Graphic Systems and to Singer-Friden (ie Flexowriter) before that > On the subject of troff origins, in a world where troff didn't exist, and one purchases a C/A/T, what was the general approach to actually using the thing? Was there some sort of datasheet the vendor supplied that the end user would have to program a driver around, or was there any sort of example code or other materials provided to give folks a leg up on using their new, expensive instrument? Did they have any "packaged bundles" for users of prominent systems such as 360/370 OSs or say one of the DEC OSs? Similarly, were any vendor-or-locally-provided solutions used prior to the maturation of troff to the point it was used for the Fourth Edition manual typesetting? Or was the C/A/T from day one of "production" use being driven pretty much exclusively by troff? I admit my knowledge of this stuff is fuzzy, such as whether troff+C/A/T was the plan from the outset of acquiring the C/A/T or if there was ever a time where folks at research may have been cooking on a different approach to using the thing. - Matt G. From phil at ultimate.com Wed Jan 10 04:05:14 2024 From: phil at ultimate.com (Phil Budne) Date: Tue, 09 Jan 2024 13:05:14 -0500 Subject: [TUHS] Original print of V7 manual? / My own version of troff In-Reply-To: References: <20240108032428.co3ozmlneoop6sa2@illithid> <20240108051049.7643537404E9@freecalypso.org> <20240108071109.ykg42tw2gjeacs5f@illithid> <20240109093851.2A29737401E3@freecalypso.org> Message-ID: <202401091805.409I5EYv074287@ultimate.com> Matt G wrote: > On the subject of troff origins, in a world where troff didn't > exist, and one purchases a C/A/T, what was the general approach to > actually using the thing? ... or say one of the DEC OSs? Off-topic for this list, BUT: At DEC/LCG (Large (36-bit) Computer Group) in the 80's when we got a DEC LN01 (Xerox 2700 engine?) someone adapted an old typesetter version of RUNOFF to drive it. I heard tell that there was a dusty C/A/T in one of the labs. Mentions of Typeset-8, Typeset-10, and Typeset-11: http://www.bitsavers.org/pdf/dec/pdp10/typeset-10/Typeset-10_Product_Proposal_197310.pdf Typeset-8: http://www.bitsavers.org/pdf/dec/pdp8/typeset8/ https://www.hewlettpackardhistory.com/item/at-the-turn-of-a-key/ Digital Equipment Corporation’s TYPESET-8 pioneered the “turnkey” computer system, where a system was custom designed for a specific application and was ready to perform that application at the press of a button (or the turn of a key). The TYPESET-8 hardware and software package originally sold with the classic PDP-8 as its CPU and functioned as a computerized typesetting system. Digital Equipment Corporation joined Hewlett-Packard in 2002. Typeset-11: http://www.bitsavers.org/pdf/dec/pdp11/typeset-11/ TMS-11 is pretty sophisticated: RSX-11D with options a real disk (RP03) or RK05, and a swap device (RF11/RS11), OCR input, VT20 (VT05 + 11/05-- first I've heard of it) but still with up to four paper tape readers/punches. The diagram at http://www.bitsavers.org/pdf/dec/pdp11/typeset-11/EK-T11SY-OP-001_TMS-11_System_Managers_and_Usrs_Guide_Feb1975.pdf shows direct hardware connection to a "photocomp machine", or via punched tape. But, I haven't spotted any mention of specific typesetter hardware. https://terminals-wiki.org/wiki/index.php/DEC_VT20 says: The DEC VT20 terminal is a variant of the DEC VT05 terminal with special facilities for typesetting. The VT20/B is another variant with a different enclosure. Two VT20/B terminals were connected to single PDP-11/05 (a variant of the 11/10) which was connected via RS232 to a host system, either a larger PDP-11 or a DECsystem-10, running Typeset-11 or Typeset-10. Newspapers using Typeset-10 were The Kansas City Star, the Chicago Tribune, and the London, Ontario, Free Press. The PDP-11/05 was booted by toggling in the bootstrap using the switches on the front of the machine, then downloading the abs loader and actual software through the RS232 interface from the host. The PDP-11/05 buffered text (news stories) downloaded from the host and allowed editing on the VT20. On Typeset-11 it was page oriented, a page would be downloaded, edited, then uploaded back to the host. On Typeset-10 the text was downloaded, but an associated memory system mirrored changes made on the text in the -11 to a copy on the -10. When the "save" button was pressed, the text was copied from associative memory into the actual text file on the DECsystem-10. This allowed for virtual scrolling through large files without having to save and load pages. The VT20s were eventually replaced by the VT72s, which featured a micro PDP-11 internally, with twice the memory of the old PDP-11/05s that controlled the VT20s. Interestingly enough, Digital no longer supported the associative memory version of the editing software, requiring page level editing. The Kansas City Star rewrote the PDP-11 software for the VT20s to run on the VT72, allowing for further virtual scrolling of large files, and making saving edits faster. The VT72 was replaced by the VT172, virtually the same terminal but in a VT100 From tuhs at tuhs.org Wed Jan 10 04:30:15 2024 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Tue, 9 Jan 2024 12:30:15 -0600 Subject: [TUHS] Original print of V7 manual? / My own version of troff In-Reply-To: <202401091805.409I5EYv074287@ultimate.com> References: <20240108032428.co3ozmlneoop6sa2@illithid> <20240108051049.7643537404E9@freecalypso.org> <20240108071109.ykg42tw2gjeacs5f@illithid> <20240109093851.2A29737401E3@freecalypso.org> <202401091805.409I5EYv074287@ultimate.com> Message-ID: <278d5933-ab69-1d05-9718-785a594d17c1@tnetconsulting.net> On 1/9/24 12:05 PM, Phil Budne wrote: > Two VT20/B terminals were connected to single PDP-11/05 (a variant > of the 11/10) which was connected via RS232 to a host system, > either a larger PDP-11 or a DECsystem-10, running Typeset-11 or > Typeset-10. Does that mean that the PDP-11/05 was functioning similarly to -- what I believe is called -- a terminal controller in IBM SNA parlance? The booting (2nd stage) from the host over the serial connection thereto really seems familiar. }:-) -- Grant. . . . unix || die From aek at bitsavers.org Wed Jan 10 06:29:21 2024 From: aek at bitsavers.org (Al Kossow) Date: Tue, 9 Jan 2024 12:29:21 -0800 Subject: [TUHS] Original print of V7 manual? / My own version of troff In-Reply-To: References: <20240108032428.co3ozmlneoop6sa2@illithid> <20240108051049.7643537404E9@freecalypso.org> <20240108071109.ykg42tw2gjeacs5f@illithid> <20240109093851.2A29737401E3@freecalypso.org> Message-ID: <66b2d0b2-87ab-8dd0-b275-5c54a1a9dfdb@bitsavers.org> On 1/9/24 9:18 AM, segaloco via TUHS wrote: > On the subject of troff origins, in a world where troff didn't exist, and one purchases a C/A/T, what was the general approach to actually using the thing? Short answer is you bought their proprietary typesetting turnkey systems They had to reverse-engineer the phototypesetter hardware to work with any homegrown software to drive it. From aek at bitsavers.org Wed Jan 10 06:31:28 2024 From: aek at bitsavers.org (Al Kossow) Date: Tue, 9 Jan 2024 12:31:28 -0800 Subject: [TUHS] Original print of V7 manual? / My own version of troff In-Reply-To: <66b2d0b2-87ab-8dd0-b275-5c54a1a9dfdb@bitsavers.org> References: <20240108032428.co3ozmlneoop6sa2@illithid> <20240108051049.7643537404E9@freecalypso.org> <20240108071109.ykg42tw2gjeacs5f@illithid> <20240109093851.2A29737401E3@freecalypso.org> <66b2d0b2-87ab-8dd0-b275-5c54a1a9dfdb@bitsavers.org> Message-ID: On 1/9/24 12:29 PM, Al Kossow wrote: > On 1/9/24 9:18 AM, segaloco via TUHS wrote: > >> On the subject of troff origins, in a world where troff didn't exist, and one purchases a C/A/T, what was the general approach to actually >> using the thing? > Short answer is you bought their proprietary typesetting turnkey systems > > They had to reverse-engineer the phototypesetter hardware to work with any homegrown software to drive it. > and that is a very deep rathole I've gone down before with Compugraphic typesetters From clemc at ccc.com Wed Jan 10 08:07:40 2024 From: clemc at ccc.com (Clem Cole) Date: Tue, 9 Jan 2024 17:07:40 -0500 Subject: [TUHS] Original print of V7 manual? / My own version of troff In-Reply-To: References: <20240108032428.co3ozmlneoop6sa2@illithid> <20240108051049.7643537404E9@freecalypso.org> <20240108071109.ykg42tw2gjeacs5f@illithid> <20240109093851.2A29737401E3@freecalypso.org> Message-ID: Not really UNIX -- so I'm BCC TUHS and moving to COFF On Tue, Jan 9, 2024 at 12:19 PM segaloco via TUHS wrote: > On the subject of troff origins, in a world where troff didn't exist, and > one purchases a C/A/T, what was the general approach to actually using the > thing? Was there some sort of datasheet the vendor supplied that the end > user would have to program a driver around, or was there any sort of > example code or other materials provided to give folks a leg up on using > their new, expensive instrument? Did they have any "packaged bundles" for > users of prominent systems such as 360/370 OSs or say one of the DEC OSs? > Basically, the phototypesetter part was turnkey with a built-in minicomputer with a paper tape unit, later a micro and a floppy disk as a cost reduction. The preparation for the typesetter was often done independently, but often the vendor offered some system to prepare the PPT or Floppy. Different typesetter vendors targeted different parts of the market, from small local independent newspapers (such as the one my sister and her husband owned and ran in North Andover MA for many years), to systems that Globe or the Times might. Similarly, books and magazines might have different systems (IIRC the APS-5 was originally targeted for large book publishers). This was all referred to as the 'pre-press' industry and there were lots of players in different parts. Large firms that produced documentation, such as DEC, AT&T *et al*., and even some universities, might own their own gear, or they might send it out to be set. The software varied greatly, depending on the target customer. For instance, by the early 80s, the Boston Globe's input system was still terrible - even though the computers had gotten better. I had a couple of friends working there, and they used to b*tch about it. But big newspapers (and I expect many other large publishers) were often heavy union shops on the back end (layout and presses), so the editors just wanted to set strips of "column wide" text as the layout was manual. I've forgotten the name of the vendor of the typesetter they used, but it was one of the larger firms -- IIRC, it had a DG Nova in it. My sister used CompuGraphic Gear, which was based on 8085's. She had two custom editing stations and the typesetter itself (it sucked). The whole system was under $35K in late-1970s money - but targeted to small newspapers like hers. In the mid-1908s, I got her a Masscomp at a reduced price and put 6 Wyse-75 terminals on it, so she could have her folks edit their stories with vi, run spell, and some of the other UNIX tools. I then reverse-engineered the floppy enough to split out the format she wanted for her stories -- she used a manual layout scheme. She still has to use the custom stuff for headlines and some other parts, but it was a load faster and more parallel (for instance, we wrote an awk script to generate the School Lunch menus, which they published each week). ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rp at servium.ch Wed Jan 10 14:22:06 2024 From: rp at servium.ch (Rico Pajarola) Date: Tue, 9 Jan 2024 20:22:06 -0800 Subject: [TUHS] XID register In-Reply-To: References: Message-ID: SPARCv9 has %tick register which just counts up on each clock cycle. Older SPARCs don't have that. I'd still suspect you'd get non-unique results in a multi CPU machine without additional effort. On Sat, Dec 2, 2023 at 10:02 PM ron minnich wrote: > SunRPC, among other protocols, needs transaction IDs (XIDs) to distinguish > RPCs.For SunRPC, it's important that XIDs not be reused (not for all > protocols; 9p has no such requirement). Stateless protocols like NFS and > reused XIDs can get messy. > > There is a vague, 30 year old memory, I have, that at some point SPARC got > a time register, or some other register, that always provided a different > answer each time it was read, even if read back to back, in part to enable > creation of non-reused XIDs. Note that things like the TSC or RISC-V MTIME > register make no such guarantee. > > I am pretty sure someone here can fill me in, or tell me I'm wrong, about > my SPARC memory. > > thanks > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mparson at bl.org Thu Jan 11 02:32:49 2024 From: mparson at bl.org (Michael Parson) Date: Wed, 10 Jan 2024 10:32:49 -0600 Subject: [TUHS] Original print of V7 manual? In-Reply-To: References: <20240105221729.371EA37401DA@freecalypso.org> <20240106030254.B8D7537401FF@freecalypso.org> <20240106032236.llpryldqt7lbondn@illithid> <20240106040642.D949B37403C1@freecalypso.org> Message-ID: <0e512393f3fab5914a9c8c079d9b48d1@bl.org> On 2024-01-06 15:04, Rich Salz wrote: > Also https://www.cs.princeton.edu/~bwk/202/index.html has some papers > with > Brian as co-author that talk about the history or the 202 and the > background work (troff->ditroff) involved. > > I am sure these have been posted here before. The omputerphile Youtube channel did a video about 10 years ago about "The Great 202 jailbreak:" https://www.youtube.com/watch?v=CVxeuwlvf8w A few years ago, a friend of mine gifted me a copy of the book they were working on that lead to that hack, _The Sicilian Defence_, for which Ken Thompson designed what is considered to be the first chess font. I'm not a big chess player, but it is still a neat piece of history. -- Michael Parson Pflugerville, TX From mparson at bl.org Thu Jan 11 02:53:44 2024 From: mparson at bl.org (Michael Parson) Date: Wed, 10 Jan 2024 10:53:44 -0600 Subject: [TUHS] Original print of V7 manual? In-Reply-To: <20240107021710.F0B92374013D@freecalypso.org> References: <20240105221729.371EA37401DA@freecalypso.org> <20240106030254.B8D7537401FF@freecalypso.org> <20240106032236.llpryldqt7lbondn@illithid> <20240106040642.D949B37403C1@freecalypso.org> <20240107021710.F0B92374013D@freecalypso.org> Message-ID: On 2024-01-06 20:17, Mychaela Falconia wrote: >> the 1978 version of the K&R (which I thought was set on the APS-5 for >> the >> first version - although it may have been on the Meganthaler). >> While I >> still have a first edition, at one time, I had a copy of the proofs, >> which >> I got from tjk in late 1977 IIRC - it might have been the Fall of '78 > > Now this part is intriguing. Wikipedia says the 1st ed of K&R C book > was published February 22, 1978. Are you *absolutely certain* it was > troffed on APS-5 or Linotron 202 etc? (I never got a copy, so I don't > have a colophon to look at.) If this book, published in early 1978, > was indeed produced on a setup that was only possible with ditroff, > then why did BWK tell the story of *beginning* ditroff coding work > (actual implementation, not just thoughts/ideas) in spring of '79 in > preparation for 202 arriving that summer? My 16th printing of the 1978 K&R C book says: This book was set in Time Roman and Courier 12 by the authors, using a Graphic Systems phototypesetter driven by a PDP-11/70 running under the UNIX operating system. UNIX is a Trademark of Bell Laboratories Given my understanding of how those pages were made, the 1st ed should have been identical, except that the line showing the "printings" numbers would have looked like: 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 And maybe a line that said "first edition" Subsequent printings would have simply masked out that line and the numbers for the other printings, to where my copy just has the numbers 20 down to 16. FWIW, my 13th printing copy of the 1988 ANSI version of the book says: UNIX is a registered trademark of AT&T. This book was typeset (pic|tbl|eqn|troff -mm) in Times Roman and Courier by the authors, using an Autologic APS-5 phototypesetter and a DEC VAX 8550 running the 9th Edition of the UNIX® operating system. My copy of the 1984 _The UNIX Programming Environment_ was typeset on on a 202 driven by a VAX 11/750 running the 8th edition. -- Michael Parson Pflugerville, TX From clemc at ccc.com Thu Jan 11 03:45:53 2024 From: clemc at ccc.com (Clem Cole) Date: Wed, 10 Jan 2024 12:45:53 -0500 Subject: [TUHS] Original print of V7 manual? In-Reply-To: References: <20240105221729.371EA37401DA@freecalypso.org> <20240106030254.B8D7537401FF@freecalypso.org> <20240106032236.llpryldqt7lbondn@illithid> <20240106040642.D949B37403C1@freecalypso.org> <20240107021710.F0B92374013D@freecalypso.org> Message-ID: On Wed, Jan 10, 2024 at 11:53 AM Michael Parson wrote: > My 16th printing of the 1978 K&R C book says: > Thanks for the idea. I went to the bookshelf. I had not thought to do that to see what the book would tell us -- duh. FWIW: I have two copies of the '78 edition (K&R1) that has a naked 3, and the second one has 10 9 8 7 6 5 4 3 - but still has a CMU Book Store sticker on its back saying it was $10.95 ;-) [I used to keep one in my office and one at home]. So yes, it was set on the GSI C/A/T system, and I'm guessing the 3rd set was the first one that was actually sent to the printers. I wish I still had the copies of the proofs from Ted. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Thu Jan 11 04:25:25 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Wed, 10 Jan 2024 13:25:25 -0500 Subject: [TUHS] Original print of V7 manual? Message-ID: > The omputerphile Youtube channel did a video about 10 years ago about > "The Great 202 jailbreak:" https://www.youtube.com/watch?v=CVxeuwlvf8w It may be superfluous in this forum, but one should note that the video's characterization of Brian Kernighan as the father of typesetting at Bell Labs does great disservice to Joe Ossanna, who single-handedly brought the first phototypesetter to the labs, subjected it to computer control, and wrote troff (which lives on 50 years later) to drive it. In passing, the video denigrates the C/A/T because it had a fixed font repertoire and no general graphic capability. But without the antecedent of C/A/T and troff, the famous Linotron summer-vacation project would never have been undertaken. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at cuzuco.com Thu Jan 11 04:50:44 2024 From: tuhs at cuzuco.com (tuhs at cuzuco.com) Date: Wed, 10 Jan 2024 13:50:44 -0500 (EST) Subject: [TUHS] Original print of V7 manual? / My own version of troff Message-ID: <202401101850.40AIoixQ026700@cuzuco.com> No idea what COFF is, but in the early 1980s, two non-troff options on the software side were - 1) TeX. From Donald Knuth, which means tau epsilon chi, pronounced tech not tex. The urban legend was upon seeing an inital copy of one of his books sometime in the 1970s, he yelled "blech!" and decided that if you wanted your documents to look right, you need to do be able to it yourself, and TeX rhymes with blech. 2) Scribe. From Brian Reid, of Carnegie-Mellon See http://www.columbia.edu/cu/computinghistory/scribe.pdf -Brian Clem Cole clemc at ccc.com wrtoe: > Not really UNIX -- so I'm BCC TUHS and moving to COFF > > On Tue, Jan 9, 2024 at 12:19b/PM segaloco via TUHS wrote: > > > On the subject of troff origins, in a world where troff didn't exist, and > > one purchases a C/A/T, what was the general approach to actually using the > > thing? Was there some sort of datasheet the vendor supplied that the end > > user would have to program a driver around, or was there any sort of > > example code or other materials provided to give folks a leg up on using > > their new, expensive instrument? Did they have any "packaged bundles" for > > users of prominent systems such as 360/370 OSs or say one of the DEC OSs? > > > Basically, the phototypesetter part was turnkey with a built-in > minicomputer with a paper tape unit, later a micro and a floppy disk as a > cost reduction. The preparation for the typesetter was often done > independently, but often the vendor offered some system to prepare the PPT > or Floppy. Different typesetter vendors targeted different parts of the > market, from small local independent newspapers (such as the one my sister > and her husband owned and ran in North Andover MA for many years), to > systems that Globe or the Times might. Similarly, books and magazines > might have different systems (IIRC the APS-5 was originally targeted for > large book publishers). This was all referred to as the 'pre-press' > industry and there were lots of players in different parts. > > Large firms that produced documentation, such as DEC, AT&T *et al*., and > even some universities, might own their own gear, or they might send it out > to be set. > > The software varied greatly, depending on the target customer. For > instance, by the early 80s, the Boston Globe's input system was still > terrible - even though the computers had gotten better. I had a couple of > friends working there, and they used to b*tch about it. But big newspapers > (and I expect many other large publishers) were often heavy union shops on > the back end (layout and presses), so the editors just wanted to set strips > of "column wide" text as the layout was manual. I've forgotten the name of > the vendor of the typesetter they used, but it was one of the larger firms > -- IIRC, it had a DG Nova in it. My sister used CompuGraphic Gear, which > was based on 8085's. She had two custom editing stations and the > typesetter itself (it sucked). The whole system was under $35K in > late-1970s money - but targeted to small newspapers like hers. In the > mid-1908s, I got her a Masscomp at a reduced price and put 6 Wyse-75 > terminals on it, so she could have her folks edit their stories with vi, > run spell, and some of the other UNIX tools. I then reverse-engineered the > floppy enough to split out the format she wanted for her stories -- she > used a manual layout scheme. She still has to use the custom stuff for > headlines and some other parts, but it was a load faster and more parallel > (for instance, we wrote an awk script to generate the School Lunch menus, > which they published each week). > From dds at aueb.gr Thu Jan 11 08:04:53 2024 From: dds at aueb.gr (Diomidis Spinellis) Date: Thu, 11 Jan 2024 00:04:53 +0200 Subject: [TUHS] Original print of V7 manual? / My own version of troff In-Reply-To: <202401101850.40AIoixQ026700@cuzuco.com> References: <202401101850.40AIoixQ026700@cuzuco.com> Message-ID: <03660f89-c378-4354-9a10-07e26f495fc8@aueb.gr> Knuth opens his TeXbook, explaining TeX's origin and pronunciation. “English words like ‘technology’ stem from a Greek root beginning with the letters τεχ…; and this same Greek word means art as well as technology. Hence the name TeX, which is an uppercase form of τεχ.” He then indeed introduces blecchhh, but he doesn't connect it with the absence of quality. “Insiders pronounce the χ of TeX as a Greek chi, not as an ‘x’ so that TeX rhymes with the word blecchhh.” (I couldn't help noticing that in my 1989 edition of the book, ellipsis after τεχ appears to be set as three periods ‘...’ rather than a real ellipsis ‘…’. The (modern) Greek words for art and technology are τέχνη (techni) and τεχνολογία (technologia), respectively. Diomidis On 10-Jan-24 20:50, tuhs at cuzuco.com wrote: > No idea what COFF is, but in the early 1980s, two non-troff options on > the software side were - > > 1) TeX. From Donald Knuth, which means tau epsilon chi, pronounced tech > not tex. The urban legend was upon seeing an inital copy of one of his > books sometime in the 1970s, he yelled "blech!" and decided that if you > wanted your documents to look right, you need to do be able to it > yourself, and TeX rhymes with blech. From tuhs at tuhs.org Thu Jan 11 09:46:56 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 10 Jan 2024 23:46:56 +0000 Subject: [TUHS] Original print of V7 manual? / My own version of troff In-Reply-To: <03660f89-c378-4354-9a10-07e26f495fc8@aueb.gr> References: <202401101850.40AIoixQ026700@cuzuco.com> <03660f89-c378-4354-9a10-07e26f495fc8@aueb.gr> Message-ID: Just to swing this back around to V7 docs, this auction has been on eBay for a little bit now: https://www.ebay.com/itm/134767543042 After the link is an auction for the HRW V7 manuals, as well as a second Volume 1, the second edition of the Nemeth administration book, and a Fall '84 software catalog from AT&T. I might jump on this in a week or so if it is still up, although all I really want is the software catalog. That to say, if someone else does pick this up, all I'd ask is I would like to purchase the catalog then from you or otherwise see to it that it gets scanned. Otherwise if I do pick it up, expect a follow up posting offering up the V7 pair, I'd take the other Volume 1 (and Nemeth book) to that uni bookshelf I donated a V7 Volume 2 binder to. If you get this and disappear the software catalog into a memory hole, your mother is a hamster and father smells of elderberries. - Matt G. P.S. For those who don't go looking often but might be interested, these are currently listed on eBay in various places: - 1 Bell Laboratories UNIX Release 3.0 User's Manual. - 3 Western Electric UNIX Release 5.0 User's Manuals. - 1 Western Electric UNIX Release 5.0 Error Message Manual. - Lots of picture-less auctions (you're selling books, pictures are the least you can do...) of allegedly parts of the HRW UNIX SVR2 5 Volume set. These are small form with metallic alphabet blocks otherwise resembling the motif on the V7 manuals cover. Distinct from the black and red binders distributed closer to actual machine purchases. - The usual gaggle of SVR3 and SVR4 manuals, there's always a rotation of them up so not going to point out specifics. The Release 5.0 Error Message Manual is particularly interesting in that the cover looks virtually identical to the usual Release 5.0/System V motif but the text says "UNIX Operating System" instead of just "UNIX System" like the Release 5.0 and System V copies I have. Most literature just says "UNIX System" so I suspect the "Operating" text is on earlier runs of the covers. Just speculation though, can't say for certain. From falcon at freecalypso.org Thu Jan 11 12:20:19 2024 From: falcon at freecalypso.org (Mychaela Falconia) Date: Wed, 10 Jan 2024 18:20:19 -0800 Subject: [TUHS] Original print of V7 manual? / My own version of troff In-Reply-To: References: <202401101850.40AIoixQ026700@cuzuco.com> <03660f89-c378-4354-9a10-07e26f495fc8@aueb.gr> Message-ID: <20240111022038.13FAF374007B@freecalypso.org> Hi Matt, > Just to swing this back around to V7 docs, this auction has been on eBay > for a little bit now: https://www.ebay.com/itm/134767543042 I just snarfed it. I am only interested in the V7 book pair; the other 3 books (extra vol1, the Nemeth book and the catalog you are most interested in) will be going to you, my dear. Please send me your mailing/shipping address off-list. > That to say, if someone else does pick this up, all I'd ask is I would like > to purchase the catalog then from you or otherwise see to it that it gets > scanned. I have neither the setup nor the time to do any scanning, so I'll just send you the physical book. > If you get this and disappear the software catalog into a memory hole, > your mother is a hamster and father smells of elderberries. I hereby swear before my Goddesses that I shall not disappear that catalog; if it arrives in my hands from the ebay seller, I shall do everything in my power to get it to you, dear brother. Mychaela N. Falconia, HPS From arnold at skeeve.com Thu Jan 11 18:51:31 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 11 Jan 2024 01:51:31 -0700 Subject: [TUHS] V10 monk program Message-ID: <202401110851.40B8pVhG001029@freefriends.org> Hi All. V10 had a program called "monk" which was a "document compiler". It produced troff and know how to run eqn, tbl, and pic and I'm guessing also refer. It seems to have been inspired by Scribe. The V10 files from Dan Cross have the device independent troff output for the paper that describes monk. G. Branden Robinson was kind enough to turn it into PostScript for me; his story is below, forwarded by permission. I'm also attaching the PostScript file. I'm curious, did this see a lot of use inside Research or outside of it? At first glance, it looks like the kind of thing that might have caught on, especially for people who weren't already used to troff. Thanks, Arnold > Date: Wed, 10 Jan 2024 12:25:53 -0600 > From: "G. Branden Robinson" > To: Aharon Robbins > Subject: Re: v10 ditroff output file > > Hi Arnold, > > At 2024-01-09T08:50:28+0200, Aharon Robbins wrote: > > Hi. > > > > The file of interest is attached. It's from vol2/monk in Dan Cross's > > V10 sources in the Distributions/Research directory from TUHS. > > > > If you can get postscript out of it somehow, > > Bad news and good news. > > ...unfortunately there was too much impedance mismatch with groff/grops. > > Some font names differ but that's not a big deal. (Also, today I > learned: the troff that generated this reloaded all the fonts at each > new page.) The troff(1) that generated this also attempted vertical > motion before starting the first page. That also wasn't a big deal. I > thought I was going to be able to text-edit my way to a solution...but > then... > > grops really wants the device resolution to be 72,000 dpi, not 720, and > we'd have to write a rescaling feature to support that. Just editing > the output file won't do because the file uses Kernighan's optimized, > anonymous output command pervasively. > > groff_out(5): > ddc Move right dd (exactly two decimal digits) basic units u, > then print glyph with single‐letter name c. > > In groff, arbitrary syntactical space around and within this > command is allowed to be added. Only when a preceding > command on the same line ends with an argument of variable > length a separating space is obligatory. In classical > troff, large clusters of these and other commands were used, > mostly without spaces; this made such output almost > unreadable. > > So all these two-digit motions would need to become five-digit motions > or all the glyphs would pile up on each other. (And that's exactly what > I happened after doing a couple of fixups and throwing gxditview(1) at > it.) > > Out of curiosity, I tried DWB 3.3 troff. > > It did well, until the fourth page, when it fell over and produced > PostScript that made Ghostscript very angry. > > So I tried Heirloom Doctools troff. > > 20 pages of goodness. > > But be advised: some sort of extension was used to embed other > PostScript files: > > ./bin/dpost: can't open picture file samples/tailor.ps (line 1493) (page 2) > ./bin/dpost: can't open picture file samples/memo.ps (line 1749) (page 3) > ./bin/dpost: can't open picture file samples/tmbody.ps (line 2151) (page 4) > ./bin/dpost: can't open picture file samples/tmcs.ps (line 2694) (page 5) > > So I went to minnie.tuhs.org to see if they were there... > > ...and they were. > > So here you go. Renders without errors (though Heirloom is nowhere near > as validation-happy as groff), and the output seems plausible. > > > I'll really appreciate it. :-) > > Enjoy! > > Regards, > Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: monk.ps Type: application/postscript Size: 239405 bytes Desc: not available URL: From f4grx at f4grx.net Thu Jan 11 23:52:09 2024 From: f4grx at f4grx.net (Sebastien F4GRX) Date: Thu, 11 Jan 2024 14:52:09 +0100 Subject: [TUHS] Original print of V7 manual? / My own version of troff In-Reply-To: <202401101850.40AIoixQ026700@cuzuco.com> References: <202401101850.40AIoixQ026700@cuzuco.com> Message-ID: <3318dded-dc86-4403-b732-4f5d62cddbd4@f4grx.net> Hi, Very interesting trivia, I didnt know, thanks! Funnily, this scribe document has a joke about hyp- henation. Sebastien Le 10/01/2024 à 19:50, tuhs at cuzuco.com a écrit : > No idea what COFF is, but in the early 1980s, two non-troff options on > the software side were - > > 1) TeX. From Donald Knuth, which means tau epsilon chi, pronounced tech > not tex. The urban legend was upon seeing an inital copy of one of his > books sometime in the 1970s, he yelled "blech!" and decided that if you > wanted your documents to look right, you need to do be able to it > yourself, and TeX rhymes with blech. > > 2) Scribe. From Brian Reid, of Carnegie-Mellon > See http://www.columbia.edu/cu/computinghistory/scribe.pdf > > -Brian > > Clem Cole clemc at ccc.com wrtoe: >> Not really UNIX -- so I'm BCC TUHS and moving to COFF >> >> On Tue, Jan 9, 2024 at 12:19b /PM segaloco via TUHS wrote: >> >>> On the subject of troff origins, in a world where troff didn't exist, and >>> one purchases a C/A/T, what was the general approach to actually using the >>> thing? Was there some sort of datasheet the vendor supplied that the end >>> user would have to program a driver around, or was there any sort of >>> example code or other materials provided to give folks a leg up on using >>> their new, expensive instrument? Did they have any "packaged bundles" for >>> users of prominent systems such as 360/370 OSs or say one of the DEC OSs? >>> >> Basically, the phototypesetter part was turnkey with a built-in >> minicomputer with a paper tape unit, later a micro and a floppy disk as a >> cost reduction. The preparation for the typesetter was often done >> independently, but often the vendor offered some system to prepare the PPT >> or Floppy. Different typesetter vendors targeted different parts of the >> market, from small local independent newspapers (such as the one my sister >> and her husband owned and ran in North Andover MA for many years), to >> systems that Globe or the Times might. Similarly, books and magazines >> might have different systems (IIRC the APS-5 was originally targeted for >> large book publishers). This was all referred to as the 'pre-press' >> industry and there were lots of players in different parts. >> >> Large firms that produced documentation, such as DEC, AT&T *et al*., and >> even some universities, might own their own gear, or they might send it out >> to be set. >> >> The software varied greatly, depending on the target customer. For >> instance, by the early 80s, the Boston Globe's input system was still >> terrible - even though the computers had gotten better. I had a couple of >> friends working there, and they used to b*tch about it. But big newspapers >> (and I expect many other large publishers) were often heavy union shops on >> the back end (layout and presses), so the editors just wanted to set strips >> of "column wide" text as the layout was manual. I've forgotten the name of >> the vendor of the typesetter they used, but it was one of the larger firms >> -- IIRC, it had a DG Nova in it. My sister used CompuGraphic Gear, which >> was based on 8085's. She had two custom editing stations and the >> typesetter itself (it sucked). The whole system was under $35K in >> late-1970s money - but targeted to small newspapers like hers. In the >> mid-1908s, I got her a Masscomp at a reduced price and put 6 Wyse-75 >> terminals on it, so she could have her folks edit their stories with vi, >> run spell, and some of the other UNIX tools. I then reverse-engineered the >> floppy enough to split out the format she wanted for her stories -- she >> used a manual layout scheme. She still has to use the custom stuff for >> headlines and some other parts, but it was a load faster and more parallel >> (for instance, we wrote an awk script to generate the School Lunch menus, >> which they published each week). >> From rich.salz at gmail.com Fri Jan 12 01:08:23 2024 From: rich.salz at gmail.com (Rich Salz) Date: Thu, 11 Jan 2024 10:08:23 -0500 Subject: [TUHS] V10 monk program In-Reply-To: <202401110851.40B8pVhG001029@freefriends.org> References: <202401110851.40B8pVhG001029@freefriends.org> Message-ID: > V10 had a program called "monk" which was a "document compiler". > Man those guys from Joisey had the best names. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Fri Jan 12 08:48:54 2024 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 12 Jan 2024 09:48:54 +1100 (EST) Subject: [TUHS] Original print of V7 manual? / My own version of troff In-Reply-To: <202401101850.40AIoixQ026700@cuzuco.com> References: <202401101850.40AIoixQ026700@cuzuco.com> Message-ID: On Wed, 10 Jan 2024, tuhs at cuzuco.com wrote: > No idea what COFF is, but in the early 1980s, two non-troff options on > the software side were - COFF (Computer Old Farts Followers) is the sister list to this one; it was set up to take the off-topic posts from TUHS (I suggested the name to Warren). Subscribe in the usual way... -- Dave From grog at lemis.com Fri Jan 12 09:47:24 2024 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Fri, 12 Jan 2024 10:47:24 +1100 Subject: [TUHS] Original print of V7 manual? / My own version of troff In-Reply-To: References: <202401101850.40AIoixQ026700@cuzuco.com> Message-ID: On Friday, 12 January 2024 at 9:48:54 +1100, Dave Horsfall wrote: > On Wed, 10 Jan 2024, tuhs at cuzuco.com wrote: > >> No idea what COFF is, but in the early 1980s, two non-troff options on >> the software side were - > > COFF (Computer Old Farts Followers) is the sister list to this one; it was > set up to take the off-topic posts from TUHS (I suggested the name to > Warren). > > Subscribe in the usual way... In fact, no. I replied yesterday and first checked the details. To subscribe, you need to ask Warren personally. That's not the case for TUHS. Warren, why the difference? Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From tuhs at tuhs.org Fri Jan 12 09:59:34 2024 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Fri, 12 Jan 2024 09:59:34 +1000 Subject: [TUHS] Subscribing to TUHS and COFF In-Reply-To: References: <202401101850.40AIoixQ026700@cuzuco.com> Message-ID: On Fri, Jan 12, 2024 at 10:47:24AM +1100, Greg 'groggy' Lehey wrote: > To subscribe, you need to ask Warren personally. > That's not the case for TUHS. Warren, why the difference? For both COFF and TUHS you have to e-mail me personally to get on the list. I've disabled the on-line subscription mechanism. Cheers, Warren From tuhs at tuhs.org Wed Jan 17 10:20:09 2024 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Wed, 17 Jan 2024 10:20:09 +1000 Subject: [TUHS] PCS kernel sources Message-ID: All, I got this e-mail from Holger a while back. Somehow it went into a folder and has lurked unseen for way too long. Does anybody know any more about PCS Unix and, if so, where should I place the code that Holger has donated into the Unix Archive? Many thanks, Warren ----- Forwarded message from hveit01 at web.de ----- From: hveit01 at web.de To: wkt at tuhs.org Subject: PCS kernel sources Hi Warren, Some time ago I subscribed to the tuhs mailing list because of my interests in Unix. I have been working on regenerating the ancient PCS unix (see more details in the README file in the attached archive). Now it is in a state to publish the results. You may decide to put this up on the TUHS website for reference. PCS UNIX (dubbed MINUX) is special in the way that it is derived from an SVR3.2 UNIX with the Newcastle connection integrated. The Newcastle connection is an early attempt for multicomputer networking; it provides a shared file system over the network, similar to the later NFS. To my knowledge, it is the first time that source for it are described (beyond some publicly availablereasearch paper); I haven't yet managed to find the original sources of this. Regards Holger Veit ----- End forwarded message ----- From tuhs at tuhs.org Wed Jan 17 10:23:44 2024 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Wed, 17 Jan 2024 10:23:44 +1000 Subject: [TUHS] PCS kernel sources In-Reply-To: References: Message-ID: <7f6c29cd-57ed-42dd-a897-749d03ba5fde@tuhs.org> On 1/17/24 10:20, Warren Toomey via TUHS wrote: > Does anybody know any more about PCS Unix and, if so, where should > I place the code that Holger has donated into the Unix Archive? I should have attached the README that Holger provided. It's below! Cheers, Warren This is part 1 of the reverse engineered sources of the PCS Cadmus MUNIX-1.2 kernel (32bit) which can be found on the IS0371 tapes (check FTP server of Computermuseum Stuttgart, Germany, contact Klemens Krause). PCS was a German systems vendor in the 80s, located in Munich, hence "MUNIX": Munich Unix. They came up with an AT&T base Unix for a QBUS-based (!) 68010 machine (later an 68020) machine. The interesting feature of this Unix derivation was the inclusion of the so called Newcastle connection which is an early multicomputer network (similar to the later NFS) which like later SUN workstations allowed disk based as well es diskless hosts. Newcastle connection uses an own raw Ethernet protocol; it implemented basic layer 2 stuff (ARP, ICMP) but did not use TCP/IP. It is AFAIK documented here for the first time. The package includes the 32 bit 1.2 kernel from Jan, 1988, including all kernel support libraries as well as some standard libs (libc, libm, etc). There are also the rebuilt sources of the MINITOR boot monitor. To guarantee correctness of the rebuilt sources, I used the following process: - I ignore describing the unpacking and conversion of the distribution tape - many files are CPIO archives, possibly   with some uninteresting byte-sex issues. - The distribution contains a set of libraries (under /usr/src) that allow regenerating a new kernel. They are   plain AR files, without the standard .a extension. These were unpacked into the .o files of the kernel. MUNIX uses   COFF in an obscure incarnation - it uses the VAX magic, but internally contains 68K code. This is why well-known   IDA disassembler cannot handle this without some patching, but even after fixing the magic it has severe issues with   calculating .data and .bss addresses. This is why I wrote an own disassembler (pcsdis) and only used IDA for code   containing 68881 FP instructions (was to lazy to put them in - they are only used in libm.a anyway). - With the knowledge of the include headers, it was possible to transform the disassembly output back into C code.   Fortunately, the PCC-based C compiler produces rather regular code.   Looking up similar sources from elsehere, like Bitsavers and Tuhs, I could identify the original parts from AT&T code   und find the modifications that PCS made to it. The whole I/O devices library was non-AT&T code, some of it resembled   PDP11 QBUS device handlers, but most of it was hard work to compare the driver code with DEC documentation   e.g. from Bitsavers. - After having the regenerated source code, it was necessary to verify its correctness. I wrote, based on the 68K Musashi   emulator code, a syscall emulator (pcsrun) that translated the most important MUNIX syscalls (COFF loader, open, close, read, write,   fork, etc.) into corresponding OS calls, so that an original MUNIX executable like CC itself basically worked with files   from the underlying OS (in my case Windows, or Linux, resp.). It contains only the syscalls that the compiler/linker etc.   used, however, so it won't allow to try out network code. This way, I could run my C code through the original compiler   from the MUNIX distribution, and compare its output with the original binaries. This way I found numerous anachronisms   that resulted from some rather obscure type casts (which messed up register usage), as well as unused variables an even   several bugs that appear to come from sloppy adaption of original AT&T code to the platform. When trying to get the LD linker   to run, it turned out that this will work only after relaxing seg fault handling on NULL pointers - some strcmp(xxx,(char*)0)   were found in the code. - For reference, pcsdis and pcsrun are also included, however the code is ugly - they were just work horse for the purpose of   getting stuff done. Beyond references to unmodified AT&T copyrighted sources from elsewhere which were included for documentation where the code came from, all files may be freely used. Holger Veit hveit01 at web.de 26.7.2022 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Wed Jan 17 17:03:04 2024 From: tuhs at tuhs.org (Veit, Holger via TUHS) Date: Wed, 17 Jan 2024 08:03:04 +0100 Subject: [TUHS] PCS kernel sources In-Reply-To: <7f6c29cd-57ed-42dd-a897-749d03ba5fde@tuhs.org> References: <7f6c29cd-57ed-42dd-a897-749d03ba5fde@tuhs.org> Message-ID: <9b1806e9-3593-4f32-97a6-37f08d308b56@web.de> Am 17.01.2024 um 01:23 schrieb Warren Toomey via TUHS: > On 1/17/24 10:20, Warren Toomey via TUHS wrote: >> Does anybody know any more about PCS Unix and, if so, where should >> I place the code that Holger has donated into the Unix Archive? > > I should have attached the README that Holger provided. It's below! > > Cheers, Warren > > [...] > The current code can be found on https://github.com/hveit01/{pcsdis, pcsrun, pcs-munix}, however, I haven't found enough time to make more significant progress in reverse engineering it. There is quite more stuff in the queue, including the graphical display support with an old X10 (no, not X TEN as in home automation, but the prececessor of the X11 Window system). But work will continue. Regards Holger From g.branden.robinson at gmail.com Thu Jan 18 00:08:21 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Wed, 17 Jan 2024 08:08:21 -0600 Subject: [TUHS] Original print of V7 manual? / My own version of troff In-Reply-To: References: <20240108032428.co3ozmlneoop6sa2@illithid> <20240108051049.7643537404E9@freecalypso.org> Message-ID: <20240117140821.lqjaa3z3zdp4isns@illithid> Hi John, At 2024-01-18T00:43:41+1100, John Gardner wrote: > I'm a professional graphic designer with access to commercial typeface > authoring software. Send me the highest-quality and most comprehensive > scans of a C/A/T-printed document, and I'll get to work. If you don't have my scan of CSTR #54 (1976), which helpfully dumps all of the glyphs in the faces used by the Bell Labs CSRC C/A/T-4, let me know and I'll send it along. I won't vouch for its high quality but it should be comprehensive with respect to coverage. > Thanks for reminding me, Branden. :) I've yet to get V7 Unix working > with the latest release of SimH, Let me know in private mail where you got stuck. Maybe I can help. > I'm still up for this, assuming you've not already started. No, I haven't--perhaps because I am an Ada fanboy, the prospect of coding in pre-standard C and its mission to turn anything that can be lexically analyzed into _some_ sequence of machine instructions has not stoked my excitement. (Which isn't to say that one _can't_ write safe code using K&R C; my fear is that having to remember all of the things the compiler won't do for you would overwhelm the task at hand. Too bad Unix V7 didn't have Perl, since this is basically a text transformation problem.) Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From brad at anduin.eldar.org Thu Jan 18 01:32:26 2024 From: brad at anduin.eldar.org (Brad Spencer) Date: Wed, 17 Jan 2024 10:32:26 -0500 Subject: [TUHS] Original print of V7 manual? / My own version of troff In-Reply-To: <20240117140821.lqjaa3z3zdp4isns@illithid> (g.branden.robinson@gmail.com) Message-ID: "G. Branden Robinson" writes: [snip] > (Which isn't to say that one _can't_ write safe code using K&R C; my > fear is that having to remember all of the things the compiler won't do > for you would overwhelm the task at hand. Too bad Unix V7 didn't have > Perl, since this is basically a text transformation problem.) > > Regards, > Branden I may be very much misremembering this, but I think that Perl 3 might exist for V7. I have very vague memories of bring up V7 in SimH and noted that a perl binary existed there.... but it might have been 2.x BSD...(this is actually the most likely) or something else in SimH. All of the history says Perl 1 was created in late 1987, so V7 certainly would have been around and I wouldn't be suprised that someone attempted to port it. I could not find which OS Perl was an initial target for and I didn't want to grovel though the old Usenet posts. -- Brad Spencer - brad at anduin.eldar.org - KC8VKS - http://anduin.eldar.org From clemc at ccc.com Thu Jan 18 01:48:38 2024 From: clemc at ccc.com (Clem Cole) Date: Wed, 17 Jan 2024 10:48:38 -0500 Subject: [TUHS] Original print of V7 manual? / My own version of troff In-Reply-To: References: <20240117140821.lqjaa3z3zdp4isns@illithid> Message-ID: Larry wrote it for admin help of his 4.1 BSD vaxen at NASA. (Which was PCC based compiler K&R1 syntax). I do not remember if any one tried to get it running on the 11 because of address space issues. As Brad says you can check all usenet files. Sent from a handheld expect more typos than usual On Wed, Jan 17, 2024 at 9:33 AM Brad Spencer wrote: > "G. Branden Robinson" writes: > > [snip] > > > (Which isn't to say that one _can't_ write safe code using K&R C; my > > fear is that having to remember all of the things the compiler won't do > > for you would overwhelm the task at hand. Too bad Unix V7 didn't have > > Perl, since this is basically a text transformation problem.) > > > > Regards, > > Branden > > > I may be very much misremembering this, but I think that Perl 3 might > exist for V7. I have very vague memories of bring up V7 in SimH and > noted that a perl binary existed there.... but it might have been 2.x > BSD...(this is actually the most likely) or something else in SimH. All > of the history says Perl 1 was created in late 1987, so V7 certainly > would have been around and I wouldn't be suprised that someone attempted > to port it. I could not find which OS Perl was an initial target for > and I didn't want to grovel though the old Usenet posts. > > > > > > -- > Brad Spencer - brad at anduin.eldar.org - KC8VKS - http://anduin.eldar.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Thu Jan 18 02:25:00 2024 From: rich.salz at gmail.com (Rich Salz) Date: Wed, 17 Jan 2024 11:25:00 -0500 Subject: [TUHS] Original print of V7 manual? / My own version of troff In-Reply-To: References: <20240117140821.lqjaa3z3zdp4isns@illithid> Message-ID: https://usenet.trashworldnews.com/?thread=614089 posted February 1988 Perl Kit, Version 1.0, Copyright (c) 1987, Larry Wall -------------- next part -------------- An HTML attachment was scrubbed... URL: From falcon at freecalypso.org Thu Jan 18 17:00:14 2024 From: falcon at freecalypso.org (Mychaela Falconia) Date: Wed, 17 Jan 2024 23:00:14 -0800 Subject: [TUHS] Original print of V7 manual? / My own version of troff In-Reply-To: References: <20240108032428.co3ozmlneoop6sa2@illithid> <20240108051049.7643537404E9@freecalypso.org> Message-ID: <20240118070019.43FB3374021A@freecalypso.org> John Gardner wrote: > I'm a professional graphic designer with access to commercial typeface > authoring software. Send me the highest-quality and most comprehensive > scans of a C/A/T-printed document, and I'll get to work. Are you offering to donate your labor in terms of typeface design, or will it be a type of deal where the community will need to collectively pitch in money to cover the cost of you doing it professionally? In either case, the "C/A/T-printed document" of most value to this project would be the same one G. Branden Robinson is referring to: > If you don't have my scan of CSTR #54 (1976), which helpfully dumps all > of the glyphs in the faces used by the Bell Labs CSRC C/A/T-4, let me > know and I'll send it along. I won't vouch for its high quality but it > should be comprehensive with respect to coverage. The paper in question is Nroff/Troff User's Manual by Joseph F. Ossanna, dated 1976-10-11, which was indeed also CSTR #54. The document is 33 pages long in its original form, and page 31 out of the 33 is the most interesting one for the purpose of font recreation: it is the page that exhibits all 4 fonts of 102 characters each. Here are the few published scans I am aware of: 1) Page 245 of: http://bitsavers.org/pdf/att/unix/7th_Edition/UNIX_Programmers_Manual_Seventh_Edition_January_1979_Volume_2A_SRI_Reprint_June_1980.pdf 2) Page 235 of: http://bitsavers.org/pdf/att/unix/7th_Edition/UNIX_Programmers_Manual_Seventh_Edition_Vol_2_1983.pdf 3) Page 239 of: http://bitsavers.org/pdf/att/unix/7th_Edition/VA-004A_UNIX_Programmers_Manual_Edition_Seven_Volume_2A_197901.pdf 4) Page 499 of: https://archive.org/details/uum-supplement-4.2bsd Question to Branden: the scan you are referring to as "my scan", how does it compare to the 4 I just linked above? If your scan has better quality than all 4 versions I linked above, can you please make it public? M~ From falcon at freecalypso.org Thu Jan 18 18:22:32 2024 From: falcon at freecalypso.org (Mychaela Falconia) Date: Thu, 18 Jan 2024 00:22:32 -0800 Subject: [TUHS] Original print of V7 manual? / My own version of troff In-Reply-To: References: <20240108032428.co3ozmlneoop6sa2@illithid> <20240108051049.7643537404E9@freecalypso.org> <20240118070019.43FB3374021A@freecalypso.org> Message-ID: <20240118082236.ED365374021A@freecalypso.org> Hi again John, > I only meant "professional" insofar as aptitude with graphics is concerned. > I won't accept money; I'm offering my labour out of love for typography, > computer history and its preservation, and of course, the technology that > got Unix the funding it needed to revolutionise computing. In any case, > there's no actual "design" work involved: it's literally just tracing > existing shapes to recreate an existing design. I do stuff like this > > for *fun*, for crying out loud. Sounds great! If you are indeed serious about trying to recreate the ancient C/A/T character set in PostScript fonts (or some other font format that can be converted into a form that can be downloaded into a genuine PostScript printer), I'll try to find some time to produce the following: 1) A set of C/A/T binary files corresponding to that CSTR #54 manual, as well as BWK's troff tutorial which usually follows right after in book compilations. This step is simply a matter of running the original troff executable (with -t option) on the original source files for these docs - but since I actually run an OS that still includes that original version of troff and you said you don't, it would probably be easier for me to produce and publish these files. 2) A converter tool from C/A/T binary codes to PostScript, using whatever fonts you give it. I'll test it initially using the set of fonts which I developed for my 4.3BSD-Quasijarus pstroff - all characters will be there, all positioning will come from original troff, but it won't look pretty because most PS native font characters don't match those of C/A/T. Then as you progress with your font drawing project, you should be able to substitute your fonts instead of mine, and see how the output improves. > Nice! The more material I have, the merrier. As for the scan that Branden > and I were referring to, I've uploaded a copy to Dropbox Using pdfimages utility with -list option, I compared the image format and resolution in various scans I described in my previous mail, plus this new one you just shared, and concluded that the best quality is contained in these two: http://bitsavers.org/pdf/att/unix/7th_Edition/UNIX_Programmers_Manual_Seventh_Edition_January_1979_Volume_2A_SRI_Reprint_June_1980.pdf http://bitsavers.org/pdf/att/unix/7th_Edition/VA-004A_UNIX_Programmers_Manual_Edition_Seven_Volume_2A_197901.pdf Here are extracted PNG images of just the relevant page from both PDFs: https://www.freecalypso.org/members/falcon/troff/cstr54-fontpage-sri.png https://www.freecalypso.org/members/falcon/troff/cstr54-fontpage-ucb.png Each PNG is a lossless extract from the corresponding PDF, made with pdfimages utility. Each image is described as being 600x600 DPI in PDF metadata, and the print is said to be in 12 point - numbers for converting from pixels to .001m units in font reconstruction... M~ From tuhs at tuhs.org Thu Jan 18 21:33:25 2024 From: tuhs at tuhs.org (Paul Ruizendaal via TUHS) Date: Thu, 18 Jan 2024 12:33:25 +0100 Subject: [TUHS] PCS kernel sources Message-ID: > All, I got this e-mail from Holger a while back. Somehow it went into > a folder and has lurked unseen for way too long. > > Does anybody know any more about PCS Unix and, if so, where should > I place the code that Holger has donated into the Unix Archive? I don’t know much about PCS Unix, but I did come across many references to Newcastle Connection (and Unix United) when researching early networking and the various approaches to giving early Unix a networking API. I think there is no other set of surviving sources for this. Maybe Holger disagrees, but I would say that PCS Unix is best placed in the “Early networking” section. By the way, for those interested, here is a start to read up on Unix United: https://en.wikipedia.org/wiki/Newcastle_Connection To some extent, it is similar to the “RIDE” software developed at Bell Labs Naperville by Priscilla Lu and to S/F Unix developed by GWR Luderer at Murray Hill. As far as I know the sources for both of those have been lost to time, afaik. From g.branden.robinson at gmail.com Thu Jan 18 23:27:32 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Thu, 18 Jan 2024 07:27:32 -0600 Subject: [TUHS] Original print of V7 manual? / My own version of troff In-Reply-To: <20240118070019.43FB3374021A@freecalypso.org> References: <20240108032428.co3ozmlneoop6sa2@illithid> <20240108051049.7643537404E9@freecalypso.org> <20240118070019.43FB3374021A@freecalypso.org> Message-ID: <20240118132732.3hafhrjzrcamwiel@illithid> Hi Mychaela, At 2024-01-17T23:00:14-0800, Mychaela Falconia wrote: > http://bitsavers.org/pdf/att/unix/7th_Edition/UNIX_Programmers_Manual_Seventh_Edition_January_1979_Volume_2A_SRI_Reprint_June_1980.pdf > > 2) Page 235 of: > > http://bitsavers.org/pdf/att/unix/7th_Edition/UNIX_Programmers_Manual_Seventh_Edition_Vol_2_1983.pdf > > 3) Page 239 of: > > http://bitsavers.org/pdf/att/unix/7th_Edition/VA-004A_UNIX_Programmers_Manual_Edition_Seven_Volume_2A_197901.pdf > > 4) Page 499 of: > > https://archive.org/details/uum-supplement-4.2bsd > > Question to Branden: the scan you are referring to as "my scan", how > does it compare to the 4 I just linked above? By "my scan", I meant "the copy of the scan I happen to have handy", rather than one I'd done myself. What I had handy was the same as your #2, above. > If your scan has better quality than all 4 versions I linked above, > can you please make it public? Sorry to disappoint. Thanks for all these links, though! More people should familiarize themselves with Volume 2 of the Seventh Edition Manual, and I hope they will. Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From g.branden.robinson at gmail.com Sat Jan 20 02:52:19 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Fri, 19 Jan 2024 10:52:19 -0600 Subject: [TUHS] Original print of V7 manual? / My own version of troff In-Reply-To: References: <20240108032428.co3ozmlneoop6sa2@illithid> <20240108051049.7643537404E9@freecalypso.org> Message-ID: <20240119165219.fldgcfqruiyw4qzx@illithid> Hi Lennart, At 2024-01-18T15:45:55+0000, Lennart Jablonka wrote: > Quoth John Gardner: > > Thanks for reminding me, Branden. :) I've yet to get V7 Unix working with > > the latest release of SimH, so that's kind of stalled my ability to develop > > something in K&R-friendly C. > > I went ahead and write a little C/A/T-to-later-troff-output converter in > v7-friendly and C89-conforming C: > > https://git.sr.ht/~humm/catdit This is an exciting prospect but I can't actually see anything there. I get an error. "401 Unauthorized You don't have the necessary permissions to access this page. Index" > I’m not confident in having got the details of spacing right (Is that > 55-unit offset when switching font sizes correct?) I've never heard of this C/A/T feature/wart before. Huh. > and the character codes emitted are still those of the C/A/T, > resulting in the wrong glyphs being used. The codes should probably be remapped by default, with a command-line option to restore the original ones. I would of course recommend writing out 'C' commands with groff special character names. > I created the attached document like this: > > v7$ troff -t /usr/man/man0/title >title.cat > host$ catdit title.ps > > (Where do the two blank pages at the end come from?) Good question; we may need to rouse a C/A/T expert. > PS: Branden, for rougher results, if you happen to have a Tektronix > 4014 at hand (like the one emulated by XTerm), you can use that to > look at v7 troff’s output. Tell your SIMH to pass control bytes > through and run troff -t | tc. I'd love to, just please make your repo available to the public. :) Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From ggm at algebras.org Sat Jan 20 12:27:41 2024 From: ggm at algebras.org (George Michaelson) Date: Sat, 20 Jan 2024 12:27:41 +1000 Subject: [TUHS] (Off topic) Dave Mills Message-ID: Dave Mills, of fuzzball and ntp fame, one time U Delaware died on the 17th of January. He was an interesting, entertaining, prolific and rather idosyncratic emailer. Witty and informative. G -------------- next part -------------- An HTML attachment was scrubbed... URL: From royce at techsolvency.com Mon Jan 22 17:41:46 2024 From: royce at techsolvency.com (Royce Williams) Date: Sun, 21 Jan 2024 22:41:46 -0900 Subject: [TUHS] Mills' initial implementation of FTP - best citation? Message-ID: What is the best public, unambiguous, non-YouTube reference I can cite for the late David Mills' initial FTP work? I see that the wording on his Wikipedia page has the ambiguous phrase "had the first implementation of FTP", which has been flagged as needing clarification, so I intend to provide it. In both this interview: https://conservancy.umn.edu/bitstream/handle/11299/113899/oh403dlm.pdf ... and this video recording of Mills himself giving a lecture at UDel: https://youtu.be/08jBmCvxkv4?t=428 ... it's quite clear that it's literally true - he authored, compiled, installed, implemented, and tested the very first (and apparently second) FTP server. But Wikipedia's guidelines discourage YouTube-only citations, and the text in the interview seems insufficiently detailed to have citation value. What is the best reference I can cite? Thanks! -- Royce -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.donner at gmail.com Mon Jan 22 22:53:37 2024 From: marc.donner at gmail.com (Marc Donner) Date: Mon, 22 Jan 2024 07:53:37 -0500 Subject: [TUHS] Mills' initial implementation of FTP - best citation? In-Reply-To: References: Message-ID: We need a code repository for original code like this. Cue the backup restoration. On Mon, Jan 22, 2024, 02:59 Royce Williams wrote: > What is the best public, unambiguous, non-YouTube reference I can cite for > the late David Mills' initial FTP work? > > I see that the wording on his Wikipedia page has the ambiguous phrase "had > the first implementation of FTP", which has been flagged as needing > clarification, so I intend to provide it. > > In both this interview: > > https://conservancy.umn.edu/bitstream/handle/11299/113899/oh403dlm.pdf > > ... and this video recording of Mills himself giving a lecture at UDel: > > https://youtu.be/08jBmCvxkv4?t=428 > > ... it's quite clear that it's literally true - he authored, compiled, > installed, implemented, and tested the very first (and apparently second) > FTP server. But Wikipedia's guidelines discourage YouTube-only citations, > and the text in the interview seems insufficiently detailed to have > citation value. > > What is the best reference I can cite? > > Thanks! > > -- > Royce > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Mon Jan 22 22:54:04 2024 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Mon, 22 Jan 2024 07:54:04 -0500 Subject: [TUHS] (Off topic) Dave Mills In-Reply-To: References: Message-ID: I took a couple of his classes in the EE dept at Univ of Delaware.  His teaching style was unique.  Lecture was maybe half teaching and half story time with topically related history, usually his personal experiences.  Very nice guy and always patient and helpful during his office hours. Mike Markowski On 1/19/24 9:27 PM, George Michaelson wrote: > Dave Mills, of fuzzball and ntp fame, one time U Delaware died on the > 17th of January. > > He was an interesting, entertaining, prolific and rather idosyncratic > emailer. Witty and informative. > > G -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Tue Jan 23 02:15:44 2024 From: pnr at planet.nl (Paul Ruizendaal) Date: Mon, 22 Jan 2024 17:15:44 +0100 Subject: [TUHS] Mills' initial implementation of FTP - best citation? Message-ID: <7B9EBFA7-C16A-4109-BDB1-B26D7E9DE5AF@planet.nl> > I see that the wording on his Wikipedia page has the ambiguous phrase "had > the first implementation of FTP", which has been flagged as needing > clarification, so I intend to provide it. > > In both this interview: > > https://conservancy.umn.edu/bitstream/handle/11299/113899/oh403dlm.pdf > > ... and this video recording of Mills himself giving a lecture at UDel: > > https://youtu.be/08jBmCvxkv4?t=428 > > ... it's quite clear that it's literally true - he authored, compiled, > installed, implemented, and tested the very first (and apparently second) > FTP server. It may be impossible to provide hard evidence. From RFC 354 it seems to me that the protocol took on a recognisable shape around July 1972 and from RFC 414 it seems to me that there were a number of implementations by November 1972, and unfortunately Dave Mills is not mentioned. His recollection may well be correct, but finding proof he was the first in a 4 months time slot 50+ years ago may be too ambitious. https://www.ietf.org/rfc/rfc354.txt https://www.ietf.org/rfc/rfc414.txt Maybe the internet history list can shed some more light on the matter: https://elists.isoc.org/mailman/listinfo/internet-history From jnc at mercury.lcs.mit.edu Tue Jan 23 07:29:53 2024 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 22 Jan 2024 16:29:53 -0500 (EST) Subject: [TUHS] Mills' initial implementation of FTP - best citation? Message-ID: <20240122212953.6CA5718C084@mercury.lcs.mit.edu> > From: Paul Ruizendaal >> the ambiguous phrase "had the first implementation of FTP", which >> has been flagged as needing clarification > From RFC 354 ... and from RFC 414 Those are NCP FTP, a slightly different protocol, and implementation, from TCP FTP. (The code from the NCP one was sometimes recycled into the TCP one; see e.g.: https://github.com/PDP-10/its-vault/blob/master/files/sysnet/ftpu.161 which has both in one program.) These RFC's you listed are obviously pre-TCP; the first TCP RFC is RFC-675. (The first RFC that even mentions TCP seems to be RFC-661.) RFC's are all NCP-related until around #700 or so, when the mix starts to change. Maybe the "needing clarification" refers to these two different FTP's? Without an explicit classifier, does that text refer to NCP FTP or TCP FTP? Noel From bakul at iitbombay.org Tue Jan 23 12:04:28 2024 From: bakul at iitbombay.org (Bakul Shah) Date: Mon, 22 Jan 2024 18:04:28 -0800 Subject: [TUHS] Mills' initial implementation of FTP - best citation? In-Reply-To: <7B9EBFA7-C16A-4109-BDB1-B26D7E9DE5AF@planet.nl> References: <7B9EBFA7-C16A-4109-BDB1-B26D7E9DE5AF@planet.nl> Message-ID: On Jan 22, 2024, at 8:15 AM, Paul Ruizendaal wrote: > >> I see that the wording on his Wikipedia page has the ambiguous phrase "had >> the first implementation of FTP", which has been flagged as needing >> clarification, so I intend to provide it. >> >> In both this interview: >> >> https://conservancy.umn.edu/bitstream/handle/11299/113899/oh403dlm.pdf >> >> ... and this video recording of Mills himself giving a lecture at UDel: >> >> https://youtu.be/08jBmCvxkv4?t=428 >> >> ... it's quite clear that it's literally true - he authored, compiled, >> installed, implemented, and tested the very first (and apparently second) >> FTP server. > > It may be impossible to provide hard evidence. From RFC 354 it seems to me that the protocol took on a recognisable shape around July 1972 and from RFC 414 it seems to me that there were a number of implementations by November 1972, and unfortunately Dave Mills is not mentioned. His recollection may well be correct, but finding proof he was the first in a 4 months time slot 50+ years ago may be too ambitious. > > https://www.ietf.org/rfc/rfc354.txt > https://www.ietf.org/rfc/rfc414.txt > > Maybe the internet history list can shed some more light on the matter: > > https://elists.isoc.org/mailman/listinfo/internet-history I asked Abhay Bhushan (author of the above two RFCs) and he had this to say: Dave Mills recently honored was not part of FTP development and specifications. Many groups were implementing early versions of FTP, so I don't know who got it working first. It was not Dave as he joined the Arpanet community later. He was part of NSFNet, so could have got first FTP on NSFnet or a laterversion of FTP. FYI. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Tue Jan 23 14:39:56 2024 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 22 Jan 2024 23:39:56 -0500 (EST) Subject: [TUHS] Mills' initial implementation of FTP - best citation? Message-ID: <20240123043956.1DEEF18C085@mercury.lcs.mit.edu> > From: Bakul Shah > He was part of NSFNet, so could have got first FTP on NSFnet or a > later version of FTP. You all are talking about _two separate FTP's_ (as I pointed out previously). If you all would stop confusing yourselves, you'd be able to sort out the bogons. In this particular case, the NSFnet appeared at a _much_ later stage of the growth of the Internet (yes, it is spelled with a capital 'I'; the morons at the AP were not aware that 'internet' was a pre-existing word with a _different meaning_) than when Dave was working with the Fuzzball, and by that point there were _many_ TCP FTP's (e.g. the ITS one I previously sent the URL to the source for), so the 'first FTP on NSFnet' is a non-concept. The best bet for accurate data is to look at the TCP meeting minutes from the IEN series: https://www.rfc-editor.org/ien/ien-index.html Looking quickly, the first one that Dave appears in might be IEN-160, "Internet Meeting Notes -- 7-8-9 October 1980". (He wasn't in the "Attendees" lists of any of the earlier ones I looked at.) Look in the "Status Reports" sections to see if he says anything about where he's at. The one for this one says: "Dave described the configuration of equipment at COMSAT which consists of a number of small hosts, mainly LSI-11s. ... COMSAT has also used NIFTP to transmit files between their hosts and ISIE. The NIFTP software was provided by UCL. ... COMSAT plans to .. arrange a permanent connection to the ARPANET." I have no idea what a "NIFTP" might be. Also, there is a reason that serious historians prefer contemporary written records, not people's memories. Noel From ggm at algebras.org Tue Jan 23 15:19:22 2024 From: ggm at algebras.org (George Michaelson) Date: Tue, 23 Jan 2024 15:19:22 +1000 Subject: [TUHS] Mills' initial implementation of FTP - best citation? In-Reply-To: <20240123043956.1DEEF18C085@mercury.lcs.mit.edu> References: <20240123043956.1DEEF18C085@mercury.lcs.mit.edu> Message-ID: NIFTP was the UK Coloured book File Transfer Protocol. The JANET X.25 based comms stack which included different coloured fasicles for each applications protocol. If memory serves me right NIFTP was grey book but I'd have to go and check. I worked on Yorkbox, the LSI-11 based X.25 system which had a UNIX applications suite connected to X25 by a DR11-W link. I did applications level bugfixes, I completely bolloxed it up, probably wrecked the York University IPR in this project, pissed off my project partners at least one of whom left because I was such a crap coder. Happy days. Later on I worked at UCL at the end of the SATNET era when Bob Braden wrote up the project: https://dl.acm.org/doi/pdf/10.1145/1035237.1035286 Funny story: UCL was very unhappy with my ex-employer York Uni because they had coded the LSI-11 work and then lost the contract to maintain it. They kept operating a gateway from JANET to ARPANET which required use of fiddly kermit logins to get from a PAD X.25 login into a system to send real FTP commands, and there was a translator to take NIFTP command streams and somehow gateway them into FTP like in JCL (there was another applications stack in coloured. book for real JCL which was coded at Bristol uni if I recall correctly) BTW Noel is right that written reports outweigh faulty memory every time. But my memory of what a bad job I did continues to haunt me. From pnr at planet.nl Tue Jan 23 23:36:56 2024 From: pnr at planet.nl (Paul Ruizendaal) Date: Tue, 23 Jan 2024 14:36:56 +0100 Subject: [TUHS] Mills' initial implementation of FTP - best citation? In-Reply-To: <20240122212953.6CA5718C084@mercury.lcs.mit.edu> References: <20240122212953.6CA5718C084@mercury.lcs.mit.edu> Message-ID: > On 22 Jan 2024, at 22:29, Noel Chiappa wrote: > > Maybe the "needing clarification" refers to these two different FTP's? Without > an explicit classifier, does that text refer to NCP FTP or TCP FTP? > > Noel That is a good point. I looked at a longer section of his talk and indeed the FTP reference is part of his discussion the NCP->TCP transition. Here it becomes easier to find references to support the claim. The strongest one that I could find is in the TCP-IP Digest mailing list from that era. The first issue has a summary of what is already out there and David Mills work is mentioned: https://jaist-g.dl.sourceforge.jp/pub/RFC/museum/tcp-ip-digest/tcp-ip-digest.v1n1.1 ==== COMSAT Date: 30 Apr 1980 From: Dave Mills 1. The TCP/IP implementation here runs in an LSI-11 with a homegrown operating system compatible in most respects to RT-11. Besides the TCP/IP levels the system includes many of the common high-level protocols used in the ARPANET community, such as TELNET, FTP and XNET. ===== Although this date precedes the date of the RFC by a few months, I do believe that it is correct and not a typo. For example, IEN-194 (July 1981) discusses the system from a perspective of experience, not of recently completed code. All that said, I wonder if “doing the first FTP” is a true reflection of his contribution in this era. After all, porting NCP FTP to TCP FTP is not all that big a deal (see for instance https://www.tuhs.org/cgi-bin/utree.pl?file=BBN-Vax-TCP/src/ftp). Maybe the sentence on Wikipedia should say that beyond NTP, he was an important contributor to several other early internet protocols.