From crossd at gmail.com Sun Jan 1 00:59:59 2023 From: crossd at gmail.com (Dan Cross) Date: Sat, 31 Dec 2022 09:59:59 -0500 Subject: [TUHS] Porting the SysIII kernel: boot, config & device drivers In-Reply-To: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl> References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl> Message-ID: On Fri, Dec 30, 2022 at 1:26 PM Paul Ruizendaal wrote: >[snip] > It would seem that the next step for Unix in the area of boot, config and device drivers came with Sun’s OpenBoot in 1988 or so. This also appears to be the first appearance of device trees to describe the hardware to the bios and the kernel. Moreover, it would seem to me that OpenBoot is a spiritual ancestor of the modern Risc-V SBI specification. Maybe by 1988 the IO hardware had become sufficiently complex and/or diverse to warrant a break from tradition? > > Was there any other notable Unix work on better organising the boot process and the device drivers prior to OpenBoot? I think that BSD supported autoconfiguration on the VAX well before OpenBoot; the OpenBSD man page says it dates from 4.1 (1981) and was revamped in 4.4. SBI was/is an attempt to define a common interface to different devices using RISC-V CPUs, but it's growing wildly and tending more towards UEFI+ACPI than something like OpenBoot, which was much simpler. In general, the idea of a BIOS isn't terrible: provide an interface that decouples the OS and hardware. But in practice, no one has come up with a particularly good set of interfaces yet. Ironically, BSD-style autoconfig might have been the best yet. - Dan C. From jon at fourwinds.com Sun Jan 1 04:49:54 2023 From: jon at fourwinds.com (Jon Steinhart) Date: Sat, 31 Dec 2022 10:49:54 -0800 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <20221231114037.7D30921FB4@orac.inputplus.co.uk> References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <8ca17d52-a25a-dbbf-e1f0-d743b8884cfa@in-ulm.de> <202212302048.2BUKmBBs253245@darkstar.fourwinds.com> <20221231114037.7D30921FB4@orac.inputplus.co.uk> Message-ID: <202212311849.2BVIntjP356028@darkstar.fourwinds.com> Ralph Corderoy writes: > Hi Jon, > > > > I guess in interactive use most users would only miss one thing: > > > the history & line editing capability? > > > > Job control? > > Just as history and line editing were a possible enhancement to the TTY > driver, didn't Pike comment that job control was cooked up in foreign > climes because they couldn't drag out a new TTY window in pixels? > > Was something like screen(1)'s ‘Ctrl-A c’ considered in the TTY driver > to spin up another pseudo-TTY rather than suspend the long job with > Ctrl-Z and ‘bg’ it? My memory is really fuzzy on this. I recall that job control came along with csh which I used until bash. At the time there were hardly any graphics displays used as interactive devices. I'm talking Berkeley job control here; I seem to remember that someone got wedged into System V that was awful and unusable. Jon From clemc at ccc.com Sun Jan 1 05:08:10 2023 From: clemc at ccc.com (Clem Cole) Date: Sat, 31 Dec 2022 14:08:10 -0500 Subject: [TUHS] Porting the SysIII kernel: boot, config & device drivers In-Reply-To: References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl> Message-ID: On Sat, Dec 31, 2022 at 10:02 AM Dan Cross wrote: > I think that BSD supported autoconfiguration on the VAX well before > OpenBoot; the OpenBSD man page says it dates from 4.1 (1981) and was > revamped in 4.4. > I can verify that. The PDP-10's had it first, then VMS. During the VMS vs UNIX war at ARPA, when Joy did the FASTVAX work, autoconfig first appeared. Sam rewrote it with what eventually became 4.2 with his configuration system. At the point of the vendors like, DEC, DG, HP, then Masscomp, Apollo and Sun all had their own boot systems. For Vaxen that was ok, as the busses were DEC defined, but folks like Xylogics, Emulex and such wanted to sell boards for the Multibus, VME as well as Unibus or proprietary busses. So boot driver were something they had to offer in source, at least to their OEM's [actually Masscomp (Paul Cantrell) wrote Xylogic's reference code for a number of them and licenses them back, which Sun used later as it turns out]. Larry and Rob G can comment on the OpenBoot stuff what was birthed later on as a way to solve some of that problem. IIRC, the SPARC may have been a partial driver for that as offering boot rooms and driver for 68000 or 8086 based boards was not going to be helpful for that market. > > SBI was/is an attempt to define a common interface to different > devices using RISC-V CPUs, but it's growing wildly and tending more > towards UEFI+ACPI than something like OpenBoot, which was much > simpler. > UEFI+ACPI got/gets a bad rep because of the original IBM BIOS implementations. > > In general, the idea of a BIOS isn't terrible: provide an interface > that decouples the OS and hardware. Exactly - the idea is actually a good one. But the problem was the BIOS designed/implemented by HW people, but OS folks. Things like concurrency minimum use of the CPU was not in the higher order bits. > But in practice, no one has come > up with a particularly good set of interfaces yet. Ironically, > BSD-style autoconfig might have been the best yet. > ??Maybe because it was OS types who knew what the OS needed to discover/report/deliver back from the HW. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sun Jan 1 05:24:46 2023 From: clemc at ccc.com (Clem Cole) Date: Sat, 31 Dec 2022 14:24:46 -0500 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <202212311849.2BVIntjP356028@darkstar.fourwinds.com> References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <8ca17d52-a25a-dbbf-e1f0-d743b8884cfa@in-ulm.de> <202212302048.2BUKmBBs253245@darkstar.fourwinds.com> <20221231114037.7D30921FB4@orac.inputplus.co.uk> <202212311849.2BVIntjP356028@darkstar.fourwinds.com> Message-ID: below On Sat, Dec 31, 2022 at 1:50 PM Jon Steinhart wrote: > My memory is really fuzzy on this. I recall that job control came along > with csh which I used until bash. Close. That was the wide distribution of it. Kulp created it originally for his PDP-11 system in the late 1970s. I'm not sure how, but wnj saw it and imported the idea to UCB. Joy had stopped hacking on the 11 by then. So he added the kernel support for Job Control to 4.0 and hacked on his own shell to add the user interface. This would get widely distributed as in 4.1BSD and since job control was in csh, and not in sh (and job had made the root use csh ) BSD users learned to used job control from there; since 4.1BSD release that spread with wings. > At the time there were hardly any > graphics displays used as interactive devices. I'm talking Berkeley job > control here; Right - which is Kulp job control to be fair. > I seem to remember that someone got wedged into System V > that was awful and unusable. > IIRC it was in SVR2 that a version of a job control system added some of the semantics of Kulp's scheme to the kernel, but not all as you point out and it was pretty disappointing if you had grown up on BSD systems. Later POSIX would pick up the Kulp/BSD Job Control definition and by SVR3/SVR4 AT&T fleshed out all all of the semantics. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Sun Jan 1 06:02:38 2023 From: pnr at planet.nl (Paul Ruizendaal) Date: Sat, 31 Dec 2022 21:02:38 +0100 Subject: [TUHS] Porting the SysIII kernel: boot, config & device drivers In-Reply-To: References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl> Message-ID: <45C94BFE-693D-4D86-8E4A-8DCC8C88774C@planet.nl> > On 31 Dec 2022, at 15:59, Dan Cross wrote: > > On Fri, Dec 30, 2022 at 1:26 PM Paul Ruizendaal wrote: >> [snip] >> It would seem that the next step for Unix in the area of boot, config and device drivers came with Sun’s OpenBoot in 1988 or so. This also appears to be the first appearance of device trees to describe the hardware to the bios and the kernel. Moreover, it would seem to me that OpenBoot is a spiritual ancestor of the modern Risc-V SBI specification. Maybe by 1988 the IO hardware had become sufficiently complex and/or diverse to warrant a break from tradition? >> >> Was there any other notable Unix work on better organising the boot process and the device drivers prior to OpenBoot? > > I think that BSD supported autoconfiguration on the VAX well before > OpenBoot; the OpenBSD man page says it dates from 4.1 (1981) and was > revamped in 4.4. That is interesting. Are you referring to this: https://www.tuhs.org/cgi-bin/utree.pl?file=4.1cBSD/a/sys/conf https://www.tuhs.org/cgi-bin/utree.pl?file=4.1cBSD/usr/man/man8/config.8 Or is auto configuration something else? > SBI was/is an attempt to define a common interface to different > devices using RISC-V CPUs, but it's growing wildly and tending more > towards UEFI+ACPI than something like OpenBoot, which was much > simpler. > > In general, the idea of a BIOS isn't terrible: provide an interface > that decouples the OS and hardware. But in practice, no one has come > up with a particularly good set of interfaces yet. Ironically, > BSD-style autoconfig might have been the best yet. When it comes to abstracting devices, it would seem to me that virtio has gotten quite some traction in the last decade. Looking at both the systems of 40 years ago and the Risc-V SoC’s of last year, I could imagine something like: - A simple SBI, like the Berkeley Boot Loader (BBL) without the proxy kernel & host interface - Devices presented to the OS as virtio devices - MMU abstraction somewhat similar in idea to that in SYSV/68 [1] Together this might be a usable Unix BIOS that could have worked in the early 80’s. One could also think of it as a simple hypervisor for only one client. The remaining BBL functionality is not all that different from the content in mch.s on 16-bit Unix (e.g. floating point emulation for CPU’s that don’t have it in hardware). A virtio device is not all that different from the interface presented by e.g. PDP-11 ethernet devices (e.g. DELUA), the MMU abstraction was contemporary. High end systems could have had device hardware that implemented the virtio interface directly, low end systems could use simpler hardware and use the BIOS to present this interface via software. [1] From mmu.h in the SYSV/68 source tree: /* @(#)mmu.h 2.26 This is the header file for the UNIX V/68 generic MMU interface. This provides the information that is used by the various routines that call: mmufork () mmuexec () mmuexit () mmuread () mmuwrite () mmuattach () mmudetach () mmuregs () mmualloc () mmuinit () mmuint () The above routines and secondary routines called by them are contained in io/mmu1.c and io/mmu2.c. */ From imp at bsdimp.com Sun Jan 1 07:04:34 2023 From: imp at bsdimp.com (Warner Losh) Date: Sat, 31 Dec 2022 14:04:34 -0700 Subject: [TUHS] Porting the SysIII kernel: boot, config & device drivers In-Reply-To: <45C94BFE-693D-4D86-8E4A-8DCC8C88774C@planet.nl> References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl> <45C94BFE-693D-4D86-8E4A-8DCC8C88774C@planet.nl> Message-ID: On Sat, Dec 31, 2022, 1:03 PM Paul Ruizendaal wrote: > > > > On 31 Dec 2022, at 15:59, Dan Cross wrote: > > > > On Fri, Dec 30, 2022 at 1:26 PM Paul Ruizendaal wrote: > >> [snip] > >> It would seem that the next step for Unix in the area of boot, config > and device drivers came with Sun’s OpenBoot in 1988 or so. This also > appears to be the first appearance of device trees to describe the hardware > to the bios and the kernel. Moreover, it would seem to me that OpenBoot is > a spiritual ancestor of the modern Risc-V SBI specification. Maybe by 1988 > the IO hardware had become sufficiently complex and/or diverse to warrant a > break from tradition? > >> > >> Was there any other notable Unix work on better organising the boot > process and the device drivers prior to OpenBoot? > OpenBoot also had device drivers written in 4th for OS agnostic goodness. It never caught on, though the concept lives on in AML in ACPI which aims lower in its abstraction... > > > I think that BSD supported autoconfiguration on the VAX well before > > OpenBoot; the OpenBSD man page says it dates from 4.1 (1981) and was > > revamped in 4.4. > > That is interesting. Are you referring to this: > https://www.tuhs.org/cgi-bin/utree.pl?file=4.1cBSD/a/sys/conf > https://www.tuhs.org/cgi-bin/utree.pl?file=4.1cBSD/usr/man/man8/config.8 > > Or is auto configuration something else? > Config == what is in the kernel with some strong hints of where to look for root and some devices (depending on the busses involved). Autoconf == discovering devices during early boot on the system (maybe with hints from config) and connecting them to the right driver (later with a bidding system for self identifying busses). This process allows GENERIC kernels and for hardware changes. The two are tightly coupled, but happen at different times. Config happens once per build, autoconf happens once per boot (though latter day BSDs will run some subset of this for module loads and device hotplug). Warner > SBI was/is an attempt to define a common interface to different > > devices using RISC-V CPUs, but it's growing wildly and tending more > > towards UEFI+ACPI than something like OpenBoot, which was much > > simpler. > > > > In general, the idea of a BIOS isn't terrible: provide an interface > > that decouples the OS and hardware. But in practice, no one has come > > up with a particularly good set of interfaces yet. Ironically, > > BSD-style autoconfig might have been the best yet. > > When it comes to abstracting devices, it would seem to me that virtio has > gotten quite some traction in the last decade. > > Looking at both the systems of 40 years ago and the Risc-V SoC’s of last > year, I could imagine something like: > > - A simple SBI, like the Berkeley Boot Loader (BBL) without the proxy > kernel & host interface > - Devices presented to the OS as virtio devices > - MMU abstraction somewhat similar in idea to that in SYSV/68 [1] > > Together this might be a usable Unix BIOS that could have worked in the > early 80’s. One could also think of it as a simple hypervisor for only one > client. The remaining BBL functionality is not all that different from the > content in mch.s on 16-bit Unix (e.g. floating point emulation for CPU’s > that don’t have it in hardware). A virtio device is not all that different > from the interface presented by e.g. PDP-11 ethernet devices (e.g. DELUA), > the MMU abstraction was contemporary. > > High end systems could have had device hardware that implemented the > virtio interface directly, low end systems could use simpler hardware and > use the BIOS to present this interface via software. > > > [1] From mmu.h in the SYSV/68 source tree: > > /* > @(#)mmu.h 2.26 > This is the header file for the UNIX V/68 generic > MMU interface. This provides the information that > is used by the various routines that call: > > mmufork () > mmuexec () > mmuexit () > mmuread () > mmuwrite () > mmuattach () > mmudetach () > mmuregs () > mmualloc () > mmuinit () > mmuint () > > The above routines and secondary routines called > by them are contained in io/mmu1.c and io/mmu2.c. > */ > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Sun Jan 1 07:11:48 2023 From: pnr at planet.nl (Paul Ruizendaal) Date: Sat, 31 Dec 2022 22:11:48 +0100 Subject: [TUHS] Porting the SysIII kernel: boot, config & device drivers In-Reply-To: References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl> Message-ID: > On 31 Dec 2022, at 20:08, Clem Cole wrote: > > [snip] > > In general, the idea of a BIOS isn't terrible: provide an interface > that decouples the OS and hardware. > Exactly - the idea is actually a good one. But the problem was the BIOS designed/implemented by HW people, but OS folks. Things like concurrency minimum use of the CPU was not in the higher order bits. My limited experience of working with "board support packages" does support the idea that these are written by the hardware designers as a quick afterthought after completing the chip. From crossd at gmail.com Sun Jan 1 07:10:47 2023 From: crossd at gmail.com (Dan Cross) Date: Sat, 31 Dec 2022 16:10:47 -0500 Subject: [TUHS] Porting the SysIII kernel: boot, config & device drivers In-Reply-To: References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl> Message-ID: On Sat, Dec 31, 2022 at 2:08 PM Clem Cole wrote: > On Sat, Dec 31, 2022 at 10:02 AM Dan Cross wrote: >> [snip] >> SBI was/is an attempt to define a common interface to different >> devices using RISC-V CPUs, but it's growing wildly and tending more >> towards UEFI+ACPI than something like OpenBoot, which was much >> simpler. > > UEFI+ACPI got/gets a bad rep because of the original IBM BIOS implementations. I'm going to push back on this slightly: UEFI+ACPI get a bad rap because, well, they're really pretty bad. Oh sure, some things are reasonable: the ACPI table formats aren't awful. But I've been inside a couple of these now and phew golly, they stink pretty badly. The code is poor quality, and encourages running blobs of really dubious provenance. See below.... >> In general, the idea of a BIOS isn't terrible: provide an interface >> that decouples the OS and hardware. > > Exactly - the idea is actually a good one. But the problem was the BIOS designed/implemented by HW people, but OS folks. Things like concurrency minimum use of the CPU was not in the higher order bits. > >> But in practice, no one has come >> up with a particularly good set of interfaces yet. Ironically, >> BSD-style autoconfig might have been the best yet. > > ??Maybe because it was OS types who knew what the OS needed to discover/report/deliver back from the HW. Perhaps this is what it is, but I think taking a step back and looking at the problem more generally, it's because they're mutated into solving the wrong problem. Consider AML: isn't this something that ought to be handled in, I don't know, a device driver? Yes, that driver may need access to some platform-specific firmware to abstract the details, but an entire virtual machine running random code to provide abstractions for the firmware writers who are running, basically, a parallel operating systems is a bit on the nose. This goes way beyond OpenBoot's forth modules on option ROMs (which were kind of a nifty idea for device discovery and such things). Mothy Roscoe gave a really interesting keynote at OSDI'21: https://www.youtube.com/watch?v=36myc8wQhLo I love how he describes the interfaces we have now as having "congealed." But in some ways, UEFI+ACPI are the antithesis of what the OS should be doing. - Dan C. From clemc at ccc.com Sun Jan 1 07:39:31 2023 From: clemc at ccc.com (Clem Cole) Date: Sat, 31 Dec 2022 16:39:31 -0500 Subject: [TUHS] Porting the SysIII kernel: boot, config & device drivers In-Reply-To: References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl> Message-ID: On Sat, Dec 31, 2022 at 4:11 PM Dan Cross wrote: > > I'm going to push back on this slightly: UEFI+ACPI get a bad rap > because, well, they're really pretty bad. Oh sure, some things are > reasonable: the ACPI table formats aren't awful. But I've been inside > a couple of these now and phew golly, they stink pretty badly. > Fair enough. UEFI+ACPI started from BIOS and really should have been a full re-think and write by senior OS people. It was not. The problem for us techies, is that doing that was not going to save or make anyone $s. The problem for management was they wanted to keep the old BIOS around (that's what the customer wanted - cheapest path forward) and unless there was a reason to break from tradition, they were not going too. Apple could (and did) but HP/Dell et al did not want too. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Sun Jan 1 07:41:38 2023 From: crossd at gmail.com (Dan Cross) Date: Sat, 31 Dec 2022 16:41:38 -0500 Subject: [TUHS] Porting the SysIII kernel: boot, config & device drivers In-Reply-To: <45C94BFE-693D-4D86-8E4A-8DCC8C88774C@planet.nl> References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl> <45C94BFE-693D-4D86-8E4A-8DCC8C88774C@planet.nl> Message-ID: On Sat, Dec 31, 2022 at 3:02 PM Paul Ruizendaal wrote: > > On 31 Dec 2022, at 15:59, Dan Cross wrote: > > I think that BSD supported autoconfiguration on the VAX well before > > OpenBoot; the OpenBSD man page says it dates from 4.1 (1981) and was > > revamped in 4.4. > > That is interesting. Are you referring to this: > https://www.tuhs.org/cgi-bin/utree.pl?file=4.1cBSD/a/sys/conf > https://www.tuhs.org/cgi-bin/utree.pl?file=4.1cBSD/usr/man/man8/config.8 > > Or is auto configuration something else? Warner answered this better than I could. :-) > > SBI was/is an attempt to define a common interface to different > > devices using RISC-V CPUs, but it's growing wildly and tending more > > towards UEFI+ACPI than something like OpenBoot, which was much > > simpler. > > > > In general, the idea of a BIOS isn't terrible: provide an interface > > that decouples the OS and hardware. But in practice, no one has come > > up with a particularly good set of interfaces yet. Ironically, > > BSD-style autoconfig might have been the best yet. > > When it comes to abstracting devices, it would seem to me that virtio has gotten quite some traction in the last decade. Virtio is solving a very, very different problem: this is limited paravirtualization of devices for virtual machines. The idea of virtio devices is predicated on a hypervisor somewhere providing a matching implementation that, in turn, plugs into whatever primitives the host provides for device management. Put another way, devices don't expose virtio interfaces directly (generally speaking), and you need something somewhere to translate from the virtio interfaces a guest sees to actual useful services that the guest makes use of via those interfaces. A host _could_ emulate something like an actual physical hardware device (for some category of device) but it turns out that's often not particularly efficient; for instance virtio-net tends to be somewhat faster than an emulated e1000. Still, virtio has some problems; you can program DMA to anywhere in the guest physical address space, which can be expensive to handle without an exit from the guest context: virtio-net isn't as fast as Google's gvnic. > Looking at both the systems of 40 years ago and the Risc-V SoC’s of last year, I could imagine something like: > > - A simple SBI, like the Berkeley Boot Loader (BBL) without the proxy kernel & host interface This, I think, is really the hard part. The issue is that systems are configured a myriad of different ways depending on the platform, vendor, particular combination of IO devices, etc. That makes figuring out where the host OS image is and getting it loaded into memory a real pain in the booty; not to mention on modern systems where you've got to do memory training as part of initializing DRAM controllers and the like. Not to mention power-sequencing, initializing IO buses and all that business: who assigns PCI BARs? What if the kernel is on a PCI device, like an NVMe SSD or similar? Turning on a modern CPU is really a non-trivial exercise, let alone getting the OS loaded. Once you get it into memory, though, _starting_ the kernel is comparatively easy. But all the gritty details before that are how we ended up with enormous systems like UEFI. > - Devices presented to the OS as virtio devices But backed by what? > - MMU abstraction somewhat similar in idea to that in SYSV/68 [1] It's not clear to me what this would buy you; the MMU tends to be architecturally defined, in a way that e.g. the boot process, IO bus initialization, and even CPU topology discovery are not. And then there are soft-TLBs (which are a bad idea, but that's a separate discussion). I mean, most VM systems since SunOS 4 have a HAL and a portable part already. > Together this might be a usable Unix BIOS that could have worked in the early 80’s. One could also think of it as a simple hypervisor for only one client. I believe that AIX on the PC/RT did basically this. Certainly, this was true on the 370. The PALcode stuff on the Alpha was similar in terms of having a BIOS-like abstraction with specific implementations for Windows or VMS/Unix. But there's an argument that this is functionality that _belongs_ in the OS, which was the traditional Unix approach. Could it have been done differently? I guess so, but would that have been a good system design? I don't know. > The remaining BBL functionality is not all that different from the content in mch.s on 16-bit Unix (e.g. floating point emulation for CPU’s that don’t have it in hardware). A virtio device is not all that different from the interface presented by e.g. PDP-11 ethernet devices (e.g. DELUA), the MMU abstraction was contemporary. > > High end systems could have had device hardware that implemented the virtio interface directly, This is challenging with virtio because some devices basically rely on the guest trapping into the host with a particular exit code to kick off IO. I suppose you could do that with a shared semaphore, but then you're burning cycles somewhere polling. You could interrupt yourself, either synchronously or with a self-IPI, but then the interrupt handler has to run the virtio handling code. In any event, it's no longer a simple matter of writing to a device register somewhere to make the "device" actually do something. Sadly, that's pretty baked into the interface. > low end systems could use simpler hardware and use the BIOS to present this interface via software. But you've got to have some CPU run that software somewhere; either you've got a satellite processor doing it or you're stealing cycles from the OS. The latter is how a BIOS traditionally works and I suspect that if we were doing this in the 1980s, having a dedicated IO processor would have added non-trivial cost to a system, for little gain: let's remember that Unix was _very_ success on a variety of systems in that era without relying on a BIOS-type abstraction! > [1] From mmu.h in the SYSV/68 source tree: > > /* > @(#)mmu.h 2.26 > This is the header file for the UNIX V/68 generic > MMU interface. This provides the information that > is used by the various routines that call: > > mmufork () > mmuexec () > mmuexit () > mmuread () > mmuwrite () > mmuattach () > mmudetach () > mmuregs () > mmualloc () > mmuinit () > mmuint () > > The above routines and secondary routines called > by them are contained in io/mmu1.c and io/mmu2.c. > */ > > > > From crossd at gmail.com Sun Jan 1 07:52:35 2023 From: crossd at gmail.com (Dan Cross) Date: Sat, 31 Dec 2022 16:52:35 -0500 Subject: [TUHS] Porting the SysIII kernel: boot, config & device drivers In-Reply-To: References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl> Message-ID: On Sat, Dec 31, 2022 at 4:39 PM Clem Cole wrote: > On Sat, Dec 31, 2022 at 4:11 PM Dan Cross wrote: >> I'm going to push back on this slightly: UEFI+ACPI get a bad rap >> because, well, they're really pretty bad. Oh sure, some things are >> reasonable: the ACPI table formats aren't awful. But I've been inside >> a couple of these now and phew golly, they stink pretty badly. > > Fair enough. UEFI+ACPI started from BIOS and really should have been a full re-think and write by senior OS people. Agreed. > It was not. The problem for us techies, is that doing that was not going to save or make anyone $s. > > The problem for management was they wanted to keep the old BIOS around (that's what the customer wanted - cheapest path forward) and unless there was a reason to break from tradition, they were not going too. Apple could (and did) but HP/Dell et al did not want too. Yeah. We canc'd it from our product (Oxide machines boot directly from the x86 reset vector and go almost immediately into Unix; no BIOS/UEFI+ACPI at all! Of course, there's a bunch of stuff that happens before the x86 cores come out of reset, but that's a different kettle of fish). We can get away with this because we control the hardware and the host software, and the unit of compute our customers interact with is a virtual machine, not the bare metal. When you control the horizontal _and_ the vertical, you can put it all in the host OS, where it arguably belongs. But in a world where software and hardware are completely decoupled? I don't know how to make the holistic boot approach work without a lot of system-specific code. It's obvious that you need some kind of system interface, and for most vendors, UEFI+ACPI is there and supported by the chip and firmware vendors, so it's the default. No one ever got fired for using UEFI/ACPI, I guess. - Dan C. From robpike at gmail.com Sun Jan 1 08:19:44 2023 From: robpike at gmail.com (Rob Pike) Date: Sun, 1 Jan 2023 09:19:44 +1100 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: Message-ID: Sam to some extent, but the better expression is the Plan 9 window systems 8½ and rio and their embedded interactive terminal. (Plan 9 has no terminal support in the kernel beyond bootstrappability.) You just edit as you work and hit newline to commit. There is a feature called "hold mode" that disabled commit on newline. It was the way you wrote a mail message: Hold, type a multiline message, edit all you like, release. -rob On Sun, Jan 1, 2023 at 12:28 AM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > > "Originally the idea of adding command line editing to ksh was > > rejected in the hope that line editing would move into the terminal > > driver." [2] > > > I have always wondered, what such a central terminal driver driven > > history/line-editing would have felt like. > > You can get a feel for it in Rob's "sam" editor, which works that way. > > Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Sun Jan 1 08:38:09 2023 From: tytso at mit.edu (Theodore Ts'o) Date: Sat, 31 Dec 2022 17:38:09 -0500 Subject: [TUHS] Porting the SysIII kernel: boot, config & device drivers In-Reply-To: References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl> Message-ID: On Sat, Dec 31, 2022 at 04:10:47PM -0500, Dan Cross wrote: > >> But in practice, no one has come > >> up with a particularly good set of interfaces yet. Ironically, > >> BSD-style autoconfig might have been the best yet. > > > > ??Maybe because it was OS types who knew what the OS needed to discover/report/deliver back from the HW. > > Perhaps this is what it is, but I think taking a step back and looking > at the problem more generally, it's because they're mutated into > solving the wrong problem. More generally, we need to make sure we're all on the same page with respect to requirements. What are we trying to do with respect to abstraction? Do we just want to inform the OS about Port and MMIO addresses, interrupts, etc, with the device driver living in the OS? Or are are we trying to move the entire device driver plus bus configuration/attachment probing into some kind of separate firmware layer which is decoupled from the rest of the OS? How important is portability? Does this hardware abstraction layer and/or firmware need to work with major legacy OS's such as Windows 95 (still in use by the US Government)? Windows 10? NetBSD? Linux? Or just only new research OS's? How important is performance? And does it need to support OS's that might want to support interesting features, such as say, confidential computing? IOMMU's? DMA from a storage device directly into memory which is accessable over RDMA via Infiniband or iWARP or to GPU memory? Or are we just trying to solve the problem of loading the OS, or maybe just initial bootstrap portion of the OS, where performance or support for more exotic memory use cases might not be as important? If we don't agree on exactly what problem that we are trying to solve with BSD-style autoconfig, vs UEFI vs ACPI vs the x86 BIOS vs CP/M's BIOS, etc. Otherwise, the risk that we'll end up talking past one another, or delivering a solution that we're happy with, but others are not, is quite high IMHO. - Ted From marc.donner at gmail.com Sun Jan 1 08:55:32 2023 From: marc.donner at gmail.com (Marc Donner) Date: Sat, 31 Dec 2022 17:55:32 -0500 Subject: [TUHS] Porting the SysIII kernel: boot, config & device drivers In-Reply-To: References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl> Message-ID: This is not precisely what I remember, but I remember at USENIX when there was a talk about the Open Boot work, someone sang a song. I looked for the song, but only found this page which doesn't read right to me: https://everything2.com/title/The+Open+Firmware+Song ===== nygeek.net mindthegapdialogs.com/home On Sat, Dec 31, 2022 at 5:38 PM Theodore Ts'o wrote: > On Sat, Dec 31, 2022 at 04:10:47PM -0500, Dan Cross wrote: > > >> But in practice, no one has come > > >> up with a particularly good set of interfaces yet. Ironically, > > >> BSD-style autoconfig might have been the best yet. > > > > > > ??Maybe because it was OS types who knew what the OS needed to > discover/report/deliver back from the HW. > > > > Perhaps this is what it is, but I think taking a step back and looking > > at the problem more generally, it's because they're mutated into > > solving the wrong problem. > > More generally, we need to make sure we're all on the same page with > respect to requirements. What are we trying to do with respect to > abstraction? Do we just want to inform the OS about Port and MMIO > addresses, interrupts, etc, with the device driver living in the OS? > Or are are we trying to move the entire device driver plus bus > configuration/attachment probing into some kind of separate firmware > layer which is decoupled from the rest of the OS? > > How important is portability? Does this hardware abstraction layer > and/or firmware need to work with major legacy OS's such as Windows 95 > (still in use by the US Government)? Windows 10? NetBSD? Linux? > Or just only new research OS's? > > How important is performance? And does it need to support OS's that > might want to support interesting features, such as say, confidential > computing? IOMMU's? DMA from a storage device directly into memory > which is accessable over RDMA via Infiniband or iWARP or to GPU > memory? > > Or are we just trying to solve the problem of loading the OS, or maybe > just initial bootstrap portion of the OS, where performance or support > for more exotic memory use cases might not be as important? > > If we don't agree on exactly what problem that we are trying to solve > with BSD-style autoconfig, vs UEFI vs ACPI vs the x86 BIOS vs CP/M's > BIOS, etc. Otherwise, the risk that we'll end up talking past one > another, or delivering a solution that we're happy with, but others > are not, is quite high IMHO. > > - Ted > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Sun Jan 1 09:25:21 2023 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 1 Jan 2023 10:25:21 +1100 (EST) Subject: [TUHS] Porting the SysIII kernel: boot, config & device drivers In-Reply-To: References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl> Message-ID: On Sat, 31 Dec 2022, Clem Cole wrote: [...] > It was not.   The problem for us techies, is that doing that was not > going to save or make anyone $s. Unfortunately, companies are run by marketoids; now, if the engineers were in charge... [ I know; they'd go broke :-( Marketoids have their uses, after all; many a great Aussie company failed (Applix, Fairlight, etc) because the product was not marketed properly. ] -- Dave From robpike at gmail.com Sun Jan 1 11:02:12 2023 From: robpike at gmail.com (Rob Pike) Date: Sun, 1 Jan 2023 12:02:12 +1100 Subject: [TUHS] Porting the SysIII kernel: boot, config & device drivers In-Reply-To: References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl> Message-ID: A theory about organizations, inspired by OpenBoot. As a company grows, which capitalism says it must, jobs change from something someone needs to do from time to time, to something a person is hired to do, to something a whole organization does. There are countless examples, but OpenBoot serves as an illustration. Like some others on this list, I'm sure, I've written a number of boot ROMs over the years, in the service of a project for which a bootable system was a prerequisite. Not hard, a day or two's work followed by some maintenance. So when I first saw a major software project in the form of a boot ROM, which may well have been my first taste of OpenBoot (it was a Sun thing, I'm pretty sure) I was bemused. But over time I've come to understand. As Sun grew (if I have the wrong company, I apologize, but it's endemic in any industry, and if I have the details of OpenBoot wrong, ditto), for various reasons the maintenance of the boot ROM became more time consuming, until eventually it became someone's full job, and then the boot ROM department's job. But allocating people's time to tasks is an inexact process, plus once one's full focus becomes boot ROMs, one's head fills with ideas. If one works on boot ROMs, every problem one thinks about becomes one the boot ROM can solve or at least help. (This particular disease is a major infection for compiler teams.) And so the boot ROM grows and grows and grows, accumulating features that are fun for the team to work on, but in the high-altitude view not really worth it. As I said, though, it's really about allocating people's time. "I have nothing to do at the moment, why don't I put a FORTH interpreter into the boot ROM? And then I'll make it an industry standard. Anyway it's my job to do boot ROMs so what else should I do now?" But you wouldn't have done that if the boot ROM stayed at the level of the stack it should have, doing the minimum necessary to get the operating system up and running to let it do the heavy lifting. I never needed a FORTH interpreter in my boot ROM. Maybe some thought they did but did they really? And was it the right use of resources to put it there? This is what happens in organizations. Employee performance evaluation at Google followed this same arc until the need to keep the organization responsible busy generated a process that placed a staggeringly expensive tax on the rest of the company, to the point that a secondary tax was paid in trying to figure out how to deal with the primary tax. This then is my theory of capitalism: Things grow until they break into pieces that must each be fed individually, triggering more growth that eventually become tumors that sap the strength of the organization. Small companies can do well because they haven't grown big enough yet to face this problem. Not an original observation, but perhaps no one has used OpenBoot as its exemplar before. Happy New Year. -rob But -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggm at algebras.org Sun Jan 1 11:16:16 2023 From: ggm at algebras.org (George Michaelson) Date: Sun, 1 Jan 2023 11:16:16 +1000 Subject: [TUHS] Porting the SysIII kernel: boot, config & device drivers In-Reply-To: References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl> Message-ID: A counter argument which will be well understood as self-justifying if made by a boot rom specialist: Every machine I make winds up looking a bit different. The new bus has different logic. The chip initialisation differs. Blobs become more interestingly hard to handle because associated pre boot initialisation dependency keeps rising and no amount of push back from me stops it. If I make my boot ROM forth, I can reduce my marginal costs to writing forth code for most variant handling and occasional uplift of new primitives and constants into the forth for edge cases. My life gets simpler if I implement the wheel of life. I would imagine after the 10th sub variant, one would wind up thinking like this. Of course a rational alternative is to maintain a monrepo of all the variants and recompile all of them all the time to make all the boot ROMs far smaller. But making the generic anything ROM and changing only some forth would be attractive. Never owned this problem. I did work with two groups doing lsi-11 images for x.25 handling on yorkbox, and they definitely thought more like you than me on this: hand code it, code it well, they aren't general purpose devices when doing this kind of job. (I annoyed them a lot which tends to "probably they were right" in hindsight on my part) G -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sun Jan 1 11:24:53 2023 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 31 Dec 2022 17:24:53 -0800 Subject: [TUHS] Porting the SysIII kernel: boot, config & device drivers In-Reply-To: References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl> Message-ID: <20230101012453.GB5825@mcvoy.com> On Sun, Jan 01, 2023 at 12:02:12PM +1100, Rob Pike wrote: > A theory about organizations, inspired by OpenBoot. > > "I have nothing to do at the moment, why don't I put a FORTH > interpreter into the boot ROM? And then I'll make it an industry standard. Yeah, that was Mitch's baby and you have the details as right as I can remember. I barfed at Forth, I've coded in Forth and didn't care for it. I didn't like lisp either but I could sort of see why some people get all worked up for lisp, wasn't for me, but I could see the point. I never saw the point of Forth for anything. But, for whatever reason, Mitch did. Yuck. The one time it was useful in my memory, was during bringup and the kernel debugger wasn't working yet. So Mitch, or someone, coded up forth code to walk kernel data structures, a set of a dump_$whatever. Briefly useful. Over all, I agree with everything Rob said. From lm at mcvoy.com Sun Jan 1 11:40:54 2023 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 31 Dec 2022 17:40:54 -0800 Subject: [TUHS] Porting the SysIII kernel: boot, config & device drivers In-Reply-To: References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl> Message-ID: <20230101014054.GD5825@mcvoy.com> All true except for the Forth choice. It's as bad, maybe worse, as choosing Tcl for your language. I've written a ton of Tcl but I need the Tk GUI part so I put up with Tcl to get it. I'd never push Tcl as a language that other people had to use. Same thing with Forth. I dunno what I'd pick, Perl in the old days, Python now (not that I care for Python but everyone can program it). Just pick something that is trivial for someone to pick up. On Sun, Jan 01, 2023 at 11:16:16AM +1000, George Michaelson wrote: > A counter argument which will be well understood as self-justifying if made > by a boot rom specialist: > > Every machine I make winds up looking a bit different. The new bus has > different logic. The chip initialisation differs. Blobs become more > interestingly hard to handle because associated pre boot initialisation > dependency keeps rising and no amount of push back from me stops it. > > If I make my boot ROM forth, I can reduce my marginal costs to writing > forth code for most variant handling and occasional uplift of new > primitives and constants into the forth for edge cases. My life gets > simpler if I implement the wheel of life. > > I would imagine after the 10th sub variant, one would wind up thinking like > this. > > Of course a rational alternative is to maintain a monrepo of all the > variants and recompile all of them all the time to make all the boot ROMs > far smaller. But making the generic anything ROM and changing only some > forth would be attractive. > > Never owned this problem. I did work with two groups doing lsi-11 images > for x.25 handling on yorkbox, and they definitely thought more like you > than me on this: hand code it, code it well, they aren't general purpose > devices when doing this kind of job. (I annoyed them a lot which tends to > "probably they were right" in hindsight on my part) > > G -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From ron at ronnatalie.com Sun Jan 1 11:51:57 2023 From: ron at ronnatalie.com (Ron Natalie) Date: Sun, 01 Jan 2023 01:51:57 +0000 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <202212311849.2BVIntjP356028@darkstar.fourwinds.com> References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <8ca17d52-a25a-dbbf-e1f0-d743b8884cfa@in-ulm.de> <202212302048.2BUKmBBs253245@darkstar.fourwinds.com> <20221231114037.7D30921FB4@orac.inputplus.co.uk> <202212311849.2BVIntjP356028@darkstar.fourwinds.com> Message-ID: Berkeley Job Control was implemented in the kernel and originally only supported in CSH. I detested csh, so I figured out how it worked and hacked it into a 5(r0) Bourne Shell. But he time I did that, all the other BRL guys were using tcsh and so to counter, I hacked command line editing into the 5R2 Bourne shell. ------ Original Message ------ >From "Jon Steinhart" To tuhs at tuhs.org Date 12/31/2022 1:49:54 PM Subject [TUHS] Re: A few comments on porting the Bourne shell >Ralph Corderoy writes: >> Hi Jon, >> >> > > I guess in interactive use most users would only miss one thing: >> > > the history & line editing capability? >> > >> > Job control? >> >> Just as history and line editing were a possible enhancement to the TTY >> driver, didn't Pike comment that job control was cooked up in foreign >> climes because they couldn't drag out a new TTY window in pixels? >> >> Was something like screen(1)'s ‘Ctrl-A c’ considered in the TTY driver >> to spin up another pseudo-TTY rather than suspend the long job with >> Ctrl-Z and ‘bg’ it? > >My memory is really fuzzy on this. I recall that job control came along >with csh which I used until bash. At the time there were hardly any >graphics displays used as interactive devices. I'm talking Berkeley job >control here; I seem to remember that someone got wedged into System V >that was awful and unusable. > >Jon From imp at bsdimp.com Sun Jan 1 12:29:25 2023 From: imp at bsdimp.com (Warner Losh) Date: Sat, 31 Dec 2022 19:29:25 -0700 Subject: [TUHS] Porting the SysIII kernel: boot, config & device drivers In-Reply-To: <20230101014054.GD5825@mcvoy.com> References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl> <20230101014054.GD5825@mcvoy.com> Message-ID: FreeBSD's boot loader uses Forth as it's scripting language.... well, we replaced it a couple years ago with Lua... it's just big enough to be useful and small enough to fit in BIOS constrained (640k) environments. Perl and python are too big... Warner On Sat, Dec 31, 2022, 6:40 PM Larry McVoy wrote: > All true except for the Forth choice. It's as bad, maybe worse, as > choosing Tcl for your language. I've written a ton of Tcl but I > need the Tk GUI part so I put up with Tcl to get it. I'd never > push Tcl as a language that other people had to use. Same thing > with Forth. > > I dunno what I'd pick, Perl in the old days, Python now (not that > I care for Python but everyone can program it). Just pick something > that is trivial for someone to pick up. > > On Sun, Jan 01, 2023 at 11:16:16AM +1000, George Michaelson wrote: > > A counter argument which will be well understood as self-justifying if > made > > by a boot rom specialist: > > > > Every machine I make winds up looking a bit different. The new bus has > > different logic. The chip initialisation differs. Blobs become more > > interestingly hard to handle because associated pre boot initialisation > > dependency keeps rising and no amount of push back from me stops it. > > > > If I make my boot ROM forth, I can reduce my marginal costs to writing > > forth code for most variant handling and occasional uplift of new > > primitives and constants into the forth for edge cases. My life gets > > simpler if I implement the wheel of life. > > > > I would imagine after the 10th sub variant, one would wind up thinking > like > > this. > > > > Of course a rational alternative is to maintain a monrepo of all the > > variants and recompile all of them all the time to make all the boot ROMs > > far smaller. But making the generic anything ROM and changing only some > > forth would be attractive. > > > > Never owned this problem. I did work with two groups doing lsi-11 images > > for x.25 handling on yorkbox, and they definitely thought more like you > > than me on this: hand code it, code it well, they aren't general purpose > > devices when doing this kind of job. (I annoyed them a lot which tends to > > "probably they were right" in hindsight on my part) > > > > G > > -- > --- > Larry McVoy Retired to fishing > http://www.mcvoy.com/lm/boat > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sun Jan 1 12:55:28 2023 From: imp at bsdimp.com (Warner Losh) Date: Sat, 31 Dec 2022 19:55:28 -0700 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <18521483-A73C-4B5F-A76A-6098BD93E9BC@planet.nl> References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <18521483-A73C-4B5F-A76A-6098BD93E9BC@planet.nl> Message-ID: On Sat, Dec 31, 2022 at 5:55 AM Paul Ruizendaal wrote: > The "assembly code in the Bourne shell" comment is in the same > London/Reiser paper. The full quote is: > > "The (Bourne) shell is the standard user command interpreter. It required > by far the largest conversion effort of any supposedly portable program, > for the simple reason that it is not portable. Critical portions are coded > in assembly language and had to be painstakingly rewritten. The shell uses > its own sbrk which is functionally different from the standard routine in > libc. The shell wants the routine which fields a signal to be passed a > parameter giving the number of the signal being caught; signal was also a > private rou- tine. This was handled by having the operating system provide > the parameter in the first place, doing away with the private code for > signal. The code in fixargs (for constructing the argument list to an exec > system call) had to be diddled." > > The files in the V7 tree on the Tuhs website are dated January 1979, so it > would seem that the fixes for 32V were immediately taken back to Research. > As you point out, this means that the comments above do not refer to the > well known source code, but to a predecessor of that (which I don’t think > survived). > We have ample evidence that V7 was really something more akin to a rolling release. Let me explain: We know from the leaked '50 changes' tape that many of the features were set earlier rather than later. This leaked in 1978 (if my notes are right), but I found references to it from as early as November 1976 in http://www.toad.com/early-usenix-newsletters/197611-unix-news-n11.pdf. This was 18 months after V6 was released, but over 2 years before V7 was released. In addition, we know from the AUUS newsletters in the archive document that the V7 release process process took a while to get through AT&T's legal department (IIRC a year, but I've not gone back to the AUUS newsletters to refresh my recollection). A big push of V7 was to make it portable as well (with AT&T doing an Interdata 8/32 port themselves, as well as at least looking at the Wollongong Interdata 7/32 port and the Harvard VM/370 port). In talking to Kirk and others that have been around from approximately that time, 32V was widely viewed as V7 for Vaxen. We can see evidence in the surviving 32V files of evolution from the 'PDP-11-like swapping to a more sophisticated paging algorithm' since we have the slowsys directory. It's my contention, as someone that coded in the era before good source code control, that it's evidence that somebody got it working, then renamed/copied it to slowsys while they got paging working so they could build either kernel for A/B testing. Kirk has also told me that the 32V port was started well in advance of V7's release to be both a useful product inside of Bell Labs (since Vaxen were starting to appear) as well as to prove that V7 was portable enough. I'll be the first to admit this is at best conjecture that matches available facts, artifacts and old timers recollections (sorry Kirk), but that we have no direct evidence for. It also allowed the 3BSD efforts to get going before the official V7 release due to the close ties between Bell Labs and Berkeley and the DARPA project around Unix. I believe that we can conclude that the original 'hard to port' Bourne shell was produced around the time of the 50 changes tape, give or take. And that all the unix porting efforts that pre-dated the V7 release rolled what appeared in 32V into V7 to reduce the amount of pdp-11 assembler. And those efforts are what we read about in the paper. It also goes a ways to explain the 32V meme of 'it was pdp11 swapping' because originally, in a version we no longer have, it was. But many of the 32V tapes that we have represent a later version where that had been abandoned in favor of what would evolve into System III's and later paging code. > Despite all the criticism voiced above, I think it is well understood that > the original Bourne shell is an amazing piece of work that managed to fit > an enormous amount of functionality into a cramped address space. Its > longevity attests to that. That its internals became difficult to > understand is par for the course -- the 1980’s in essence needed a Lions > commentary on sh. > Totally agree with that... Warner > > > On 30 Dec 2022, at 20:57, segaloco wrote: > > > > I'll have to double check later but I'm fairly certain the remaining L/R > cheats are gone by SysV. From what I can tell much of that portability > work may have been done prior to the V7 release code base we're familiar > with, as I did some comparison and found only one significant change > between V7 and 32V code as I know it at least. Either the claims of > portability issues came between 32V and System III (meaning the shell was > accepted as "broken"? in 32V) or the code we actually see in V7 has already > been tidied up significantly and doesn't represent the "non-portable" > version lamented in the famous quote. Does this observation hold with > reality? Is there an earlier, more PDP-11 bound version of the Bourne > Shell out there? I seem to recall reading something about some bits of it > even being in assembly at one point, but can't remember the quote source. > > > > - Matt G. > > > > ------- Original Message ------- > > On Friday, December 30th, 2022 at 10:25 AM, Paul Ruizendaal < > pnr at planet.nl> wrote: > > > > > >> London and Reiser report about porting the shell that “it required by > far the largest conversion effort of any supposedly portable program, for > the simple reason that it is not portable.” By the time of SysIII this is > greatly improved, but also in porting the SysIII user land it was the most > complex of the set so far. > >> > >> There were three aspects that I found noteworthy: > >> > >> 1. London/Reiser apparently felt strongly about a property of casts. > The code argues that casting an l-value should not convert it into a > r-value: > >> > >> > >> > >> /* the following nonsense is required > >> * because casts turn an Lvalue > >> * into an Rvalue so two cheats > >> * are necessary, one for each context. > >> */ > >> union { int _cheat;}; > >> #define Lcheat(a) ((a)._cheat) > >> #define Rcheat(a) ((int)(a)) > >> > >> > >> > >> However, Lcheat is only used in two places (in service.c), to set and > to clear a flag in a pointer. Interestingly, the 32V code already replaces > one of these instances with a regular r-value cast. So far, I’d never > thought about this aspect of casts. I stumbled across it, because the Plan > 9 compiler did not accept the Lcheat expansion as valid C. > >> > >> 2. On the history of dup2 > >> > >> The shell code includes the following: > >> > >> > >> > >> rename(f1,f2) > >> REG INT f1, f2; > >> { > >> #ifdef RES /* research has different sys calls from TS */ > >> IF f1!=f2 > >> THEN dup(f1|DUPFLG, f2); > >> close(f1); > >> IF f2==0 THEN ioset|=1 FI > >> FI > >> #else > >> INT fs; > >> IF f1!=f2 > >> THEN fs = fcntl(f2,1,0); > >> close(f2); > >> fcntl(f1,0,f2); > >> close(f1); > >> IF fs==1 THEN fcntl(f2,2,1) FI > >> IF f2==0 THEN ioset|=1 FI > >> FI > >> #endif > >> } > >> > >> > >> > >> I’ve check the 8th edition source, and indeed it supports using DUPFLG > to signal to dup() that it really is dup2(). I had earlier wondered why > dup2() did not appear in research until 10th edition, but now that is > clear. It would seem that the dup of 8th edition is a direct ancestor to > dup() in Plan 9. I wonder why this way of doing things never caught on in > the other Unices. > >> > >> 3. Halfway to demand paging > >> > >> I stumbled across this one because I had a bug in my signal handling. > From early days onwards, Unix supported dynamically growing the stack > allocation, which arguably is a first step towards building the mechanisms > for demand paging. It appears that the Bourne shell made another step, > catching page faults and expanding the data/bss allocation dynamically: > >> > >> > >> > >> VOID fault(sig) > >> REG INT sig; > >> { > >> signal(sig, fault); > >> IF sig==MEMF > >> THEN IF setbrk(brkincr) == -1 > >> THEN error(nospace); > >> FI > >> ELIF ... > >> > >> > >> > >> This was already present in 7th edition, so it is by no means new in > 32V or SysIII -- it had just escaped my attention as a conceptual step in > the development of Unix memory handling. > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sun Jan 1 13:08:55 2023 From: imp at bsdimp.com (Warner Losh) Date: Sat, 31 Dec 2022 20:08:55 -0700 Subject: [TUHS] Porting the SysIII kernel: boot, config & device drivers In-Reply-To: <45C94BFE-693D-4D86-8E4A-8DCC8C88774C@planet.nl> References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl> <45C94BFE-693D-4D86-8E4A-8DCC8C88774C@planet.nl> Message-ID: On Sat, Dec 31, 2022 at 1:03 PM Paul Ruizendaal wrote: > > > > On 31 Dec 2022, at 15:59, Dan Cross wrote: > > > > On Fri, Dec 30, 2022 at 1:26 PM Paul Ruizendaal wrote: > >> [snip] > >> It would seem that the next step for Unix in the area of boot, config > and device drivers came with Sun’s OpenBoot in 1988 or so. This also > appears to be the first appearance of device trees to describe the hardware > to the bios and the kernel. Moreover, it would seem to me that OpenBoot is > a spiritual ancestor of the modern Risc-V SBI specification. Maybe by 1988 > the IO hardware had become sufficiently complex and/or diverse to warrant a > break from tradition? > >> > >> Was there any other notable Unix work on better organising the boot > process and the device drivers prior to OpenBoot? > > > > I think that BSD supported autoconfiguration on the VAX well before > > OpenBoot; the OpenBSD man page says it dates from 4.1 (1981) and was > > revamped in 4.4. > > That is interesting. Are you referring to this: > https://www.tuhs.org/cgi-bin/utree.pl?file=4.1cBSD/a/sys/conf > https://www.tuhs.org/cgi-bin/utree.pl?file=4.1cBSD/usr/man/man8/config.8 > > Or is auto configuration something else? > > > SBI was/is an attempt to define a common interface to different > > devices using RISC-V CPUs, but it's growing wildly and tending more > > towards UEFI+ACPI than something like OpenBoot, which was much > > simpler. > > > > In general, the idea of a BIOS isn't terrible: provide an interface > > that decouples the OS and hardware. But in practice, no one has come > > up with a particularly good set of interfaces yet. Ironically, > > BSD-style autoconfig might have been the best yet. > > When it comes to abstracting devices, it would seem to me that virtio has > gotten quite some traction in the last decade. > > Looking at both the systems of 40 years ago and the Risc-V SoC’s of last > year, I could imagine something like: > > - A simple SBI, like the Berkeley Boot Loader (BBL) without the proxy > kernel & host interface > - Devices presented to the OS as virtio devices > - MMU abstraction somewhat similar in idea to that in SYSV/68 [1] > Let's not forget that the diversity of systems is 1000s of times greater than it was in the early days of Unix. There were just two busses (Unibus and QBUS) in pdp-11 unix. There were a limited number of peripherals that could live at a limited number of CSRs and compatibility requirements of other DEC OSes meant that most of the 3rd party cards were compatible with DEC gear, though there were exceptions. There was no hot plug, there was no need to hierarchically assign address pools for things like PCIe hot-plug. There was no USB. There were only a very limited number of keyboard and graphics configurations. VAXen increased the number, but not by a huge amount, at least in the early days before new busses were introduced). As such, the unixes from the system III era simply didn't have any notion of this diversity. So trying to layer it in will be quite difficult. The SoC space has become huge, with memory being mapped in different locations, busses being different, etc. There's been much nasty said about FDT and ACPI, but they do solve real problems: how to enumerate this diversity to the OS in a way that's sane and might not always be as simple as returning a specific number but that requires hardware access to answer even basic questions (because, say, the CPUs were wired this way or that and you have to read those wirings). Linux, even in Linuxboot environments, still uses ACPI, FDT and UEFI to get the job done, and the code there isn't horrific. V7 unix for the PDP-11 shipped with maybe 25 drivers total for the whole system, and many of them were quite niche... > Together this might be a usable Unix BIOS that could have worked in the > early 80’s. One could also think of it as a simple hypervisor for only one > client. The remaining BBL functionality is not all that different from the > content in mch.s on 16-bit Unix (e.g. floating point emulation for CPU’s > that don’t have it in hardware). A virtio device is not all that different > from the interface presented by e.g. PDP-11 ethernet devices (e.g. DELUA), > the MMU abstraction was contemporary. > virtio solves a different problem, though: It's goal is to provide THE interface for mass storage, THE interface for networking, etc so that hypervisor clients can limit their drivers substantially and not have to deal with the thousands of drivers normally needed. ACPI/FDT just try to make the non-self-describing aspects of the hardware described. Which is a different target market (so that one can hook up the right driver of the thousands to choose from when the OS autoconfig's the devices by whatever means it does that, even Linux and System V have this concept, though with radically different code than the BSDs). > High end systems could have had device hardware that implemented the > virtio interface directly, low end systems could use simpler hardware and > use the BIOS to present this interface via software. > I'd worry that 'use the BIOS' bit here leads to the ugly UEFI/ACPI hybrid to be generic enough to describe everything. Now, I don't disagree with the org chart args for why they are so large outside of linuxboot, but they do fill a vacuum that would otherwise exist. Warner > > [1] From mmu.h in the SYSV/68 source tree: > > /* > @(#)mmu.h 2.26 > This is the header file for the UNIX V/68 generic > MMU interface. This provides the information that > is used by the various routines that call: > > mmufork () > mmuexec () > mmuexit () > mmuread () > mmuwrite () > mmuattach () > mmudetach () > mmuregs () > mmualloc () > mmuinit () > mmuint () > > The above routines and secondary routines called > by them are contained in io/mmu1.c and io/mmu2.c. > */ > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Sun Jan 1 13:55:45 2023 From: crossd at gmail.com (Dan Cross) Date: Sat, 31 Dec 2022 22:55:45 -0500 Subject: [TUHS] Porting the SysIII kernel: boot, config & device drivers In-Reply-To: References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl> Message-ID: On Sat, Dec 31, 2022 at 5:38 PM Theodore Ts'o wrote: > On Sat, Dec 31, 2022 at 04:10:47PM -0500, Dan Cross wrote: > > >> But in practice, no one has come > > >> up with a particularly good set of interfaces yet. Ironically, > > >> BSD-style autoconfig might have been the best yet. > > > > > > ??Maybe because it was OS types who knew what the OS needed to discover/report/deliver back from the HW. > > > > Perhaps this is what it is, but I think taking a step back and looking > > at the problem more generally, it's because they're mutated into > > solving the wrong problem. > > More generally, we need to make sure we're all on the same page with > respect to requirements. What are we trying to do with respect to > abstraction? Do we just want to inform the OS about Port and MMIO > addresses, interrupts, etc, with the device driver living in the OS? > Or are are we trying to move the entire device driver plus bus > configuration/attachment probing into some kind of separate firmware > layer which is decoupled from the rest of the OS? > > How important is portability? Does this hardware abstraction layer > and/or firmware need to work with major legacy OS's such as Windows 95 > (still in use by the US Government)? Windows 10? NetBSD? Linux? > Or just only new research OS's? > > How important is performance? And does it need to support OS's that > might want to support interesting features, such as say, confidential > computing? IOMMU's? DMA from a storage device directly into memory > which is accessable over RDMA via Infiniband or iWARP or to GPU > memory? > > Or are we just trying to solve the problem of loading the OS, or maybe > just initial bootstrap portion of the OS, where performance or support > for more exotic memory use cases might not be as important? > > If we don't agree on exactly what problem that we are trying to solve > with BSD-style autoconfig, vs UEFI vs ACPI vs the x86 BIOS vs CP/M's > BIOS, etc. Otherwise, the risk that we'll end up talking past one > another, or delivering a solution that we're happy with, but others > are not, is quite high IMHO. Spot on, Ted. I agree with everything here. - Dan C. From jsg at jsg.id.au Sun Jan 1 14:38:50 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Sun, 1 Jan 2023 15:38:50 +1100 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <18521483-A73C-4B5F-A76A-6098BD93E9BC@planet.nl> Message-ID: On Sat, Dec 31, 2022 at 07:55:28PM -0700, Warner Losh wrote: > On Sat, Dec 31, 2022 at 5:55 AM Paul Ruizendaal wrote: > > > The "assembly code in the Bourne shell" comment is in the same > > London/Reiser paper. The full quote is: > > > > "The (Bourne) shell is the standard user command interpreter. It required > > by far the largest conversion effort of any supposedly portable program, > > for the simple reason that it is not portable. Critical portions are coded > > in assembly language and had to be painstakingly rewritten. The shell uses > > its own sbrk which is functionally different from the standard routine in > > libc. The shell wants the routine which fields a signal to be passed a > > parameter giving the number of the signal being caught; signal was also a > > private rou- tine. This was handled by having the operating system provide > > the parameter in the first place, doing away with the private code for > > signal. The code in fixargs (for constructing the argument list to an exec > > system call) had to be diddled." > > > > The files in the V7 tree on the Tuhs website are dated January 1979, so it > > would seem that the fixes for 32V were immediately taken back to Research. > > As you point out, this means that the comments above do not refer to the > > well known source code, but to a predecessor of that (which I don’t think > > survived). > > > > We have ample evidence that V7 was really something more akin to a rolling > release. Let me explain: We know from the leaked '50 changes' tape that > many of the features were set earlier rather than later. This leaked in > 1978 (if my notes are right), but I found references to it from as early as > November 1976 in > http://www.toad.com/early-usenix-newsletters/197611-unix-news-n11.pdf. This > was 18 months after V6 was released, but over 2 years before V7 was > released. In addition, we know from the AUUS newsletters in the archive > document that the V7 release process process took a while to get through > AT&T's legal department (IIRC a year, but I've not gone back to the AUUS > newsletters to refresh my recollection). A big push of V7 was to make it > portable as well (with AT&T doing an Interdata 8/32 port themselves, as > well as at least looking at the Wollongong Interdata 7/32 port and the > Harvard VM/370 port). In talking to Kirk and others that have been around > from approximately that time, 32V was widely viewed as V7 for Vaxen. We can > see evidence in the surviving 32V files of evolution from the 'PDP-11-like > swapping to a more sophisticated paging algorithm' since we have the > slowsys directory. It's my contention, as someone that coded in the era > before good source code control, that it's evidence that somebody got it > working, then renamed/copied it to slowsys while they got paging working so > they could build either kernel for A/B testing. Kirk has also told me that > the 32V port was started well in advance of V7's release to be both a > useful product inside of Bell Labs (since Vaxen were starting to appear) as > well as to prove that V7 was portable enough. I'll be the first to admit > this is at best conjecture that matches available facts, artifacts and old > timers recollections (sorry Kirk), but that we have no direct evidence for. > It also allowed the 3BSD efforts to get going before the official V7 > release due to the close ties between Bell Labs and Berkeley and the DARPA > project around Unix. "So DEC came to us at Holmdel. We were clearly the second string. Tom London and John Reiser were interested and so was Ken Swanson, and we got the VAX in early '78. I didn't do any of the technical work. In fact, I devoted a lot of energy and time to getting the management to let us do it. It wasn't research, you see. However, they let us take the time. And in about three months my small group ported Version 7 to the VAX. We got the machine in January, they had it running in April, and by August it really worked. ... So, with the blessings of BTL Area 11 management, we sent 32V to Berkeley. It was in October or November, 1978" Charlie Roberts in Salus QCU "The operating system is Research version 7 as of April 15, 1978. .. Work on the C compiler began in mid-December 1977. The hardware arrived on March 3. We held a party on May 19 to celebrate successful multiuser operation of the system." London and Reiser A UNIX Operating System for the DEC VAX-11/780 Computer https://www.bell-labs.com/usr/dmr/www/otherports/32v.html > > I believe that we can conclude that the original 'hard to port' Bourne > shell was produced around the time of the 50 changes tape, give or take. > And that all the unix porting efforts that pre-dated the V7 release rolled > what appeared in 32V into V7 to reduce the amount of pdp-11 assembler. And > those efforts are what we read about in the paper. "The Bourne shell work started either in early 1976, or maybe late 1975. The first version was VERY different" John Mashey in net.unix-wizards, 18 Mar 86 https://groups.google.com/g/alt.folklore.computers/c/xW3ZgEnFoFs tuhs/Documentation/AUUGN/AUUGN-V06.6.pdf pg 39 "In 1976, Steve Bourne, who had recently joined 1127, wrote a new shell" Kernighan, UNIX A History and a Memoir, 5.1 pg 88 Bourne's AsiaBSDCon 2016 talk also lists 1976 and goes on to discuss sbrk() use causing problems with ports https://youtu.be/7tQ2ftt3LO8?t=715 From crossd at gmail.com Sun Jan 1 14:40:44 2023 From: crossd at gmail.com (Dan Cross) Date: Sat, 31 Dec 2022 23:40:44 -0500 Subject: [TUHS] Porting the SysIII kernel: boot, config & device drivers In-Reply-To: References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl> <45C94BFE-693D-4D86-8E4A-8DCC8C88774C@planet.nl> Message-ID: On Sat, Dec 31, 2022 at 10:09 PM Warner Losh wrote: > On Sat, Dec 31, 2022 at 1:03 PM Paul Ruizendaal wrote: >[snip] > There's been much nasty said about FDT and ACPI, but they do solve real problems: how to enumerate this diversity to the OS in a way that's sane and might not always be as simple as returning a specific number but that requires hardware access to answer even basic questions (because, say, the CPUs were wired this way or that and you have to read those wirings). Linux, even in Linuxboot environments, still uses ACPI, FDT and UEFI to get the job done, and the code there isn't horrific. This is sort of the issue I have with ACPI+UEFI et al. If we stopped at what you say (a small nucleus of primordial software that runs once at the beginning of time intended only to provide essentially static information to the OS in some relatively sane format, but then dies and is never consulted again) then either is fine: the ACPI table formats where this sort of information is encoded are well-defined and not horrible; ripping through the MADT to find all of your CPUs is fine. But that's not all that either did, and the amount of functionality being shoved into UEFI/ACPI in particular seems to show no sign of slowing down. I get that having this sort of parallel OS that exposes functionality in a manner transparent to what we normally consider the operating system coupled with CPU "features" like SMM means that vendors can write clever software to hide the fact that you've got a USB keyboard from an OS that doesn't understand USB; this touches on the thing Ted mentioned about needing to support old OSes like Windows 95 or whatever. But we're so far beyond compatibility crutches and into the land of magical black boxes running opaque blobs that do all sorts of stuff well hidden from the OS, and indeed, the OS has no control over, by design. THAT's the problem. > V7 unix for the PDP-11 shipped with maybe 25 drivers total for the whole system, and many of them were quite niche... > >> Together this might be a usable Unix BIOS that could have worked in the early 80’s. One could also think of it as a simple hypervisor for only one client. The remaining BBL functionality is not all that different from the content in mch.s on 16-bit Unix (e.g. floating point emulation for CPU’s that don’t have it in hardware). A virtio device is not all that different from the interface presented by e.g. PDP-11 ethernet devices (e.g. DELUA), the MMU abstraction was contemporary. > > virtio solves a different problem, though: It's goal is to provide THE interface for mass storage, THE interface for networking, etc so that hypervisor clients can limit their drivers substantially and not have to deal with the thousands of drivers normally needed. Generally speaking, the hypervisor won't expose hardware devices directly to the guest. Even with SR-IOV and the like, the HV necessarily synthesizes, say, PCI config space as seen by the guest and tightly controls what virtual functions the guest sees, as anything else allows the guest to usurp the host. This implies that the HV is providing the guest with virtualized devices anyway, and once you're doing that the question becomes: what devices to parameterize the guest with? The HV could emulate things it is fairly sure the guest already knows about because they're relatively common: say, an e1000 for a NIC, or AHCI for storage, a 16550 for a console UART, etc, but what's the relative cost of doing so? It turns out, most of these devices aren't super great fits for virtualization; they generate too many exits. Enter virtio, designed for the use case. That said, hypervisor bypass for virtual devices is a big deal, and not something that's easily done with virtio. Even offloading virtio handling to dedicated cores is hard, because there's no easy way for the guest to generate a doorbell interrupt in the host (kicking a virtio queue involves a guest exit, which implies some local processing on the processor running the VCPU: that may be as simple as kicking off an IPI to another CPU, but you're still exiting, which is expensive). > ACPI/FDT just try to make the non-self-describing aspects of the hardware described. If that were all they did, I think a lot of the complaints would melt away. >[snip] > Now, I don't disagree with the org chart args for why they are so large outside of linuxboot, but they do fill a vacuum that would otherwise exist. The data formats and the general concept of providing that data to the OS in semi-portable manner, yes. The real problem addressed here is the decoupling of hardware and systems software at scale; the problem was simply smaller on the PDP-11 and VAX, but is orders of magnitude larger now. You need _something_ unless you're in the downright luxurious position that, say, we're in at Oxide. UEFI+ACPI serve in that capacity, but it's important to note that that doesn't make them good. Lots of things that are very useful kind of suck. - Dan C. From imp at bsdimp.com Sun Jan 1 15:25:49 2023 From: imp at bsdimp.com (Warner Losh) Date: Sat, 31 Dec 2022 22:25:49 -0700 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <18521483-A73C-4B5F-A76A-6098BD93E9BC@planet.nl> Message-ID: On Sat, Dec 31, 2022, 9:38 PM Jonathan Gray wrote: > On Sat, Dec 31, 2022 at 07:55:28PM -0700, Warner Losh wrote: > > On Sat, Dec 31, 2022 at 5:55 AM Paul Ruizendaal wrote: > > > > > The "assembly code in the Bourne shell" comment is in the same > > > London/Reiser paper. The full quote is: > > > > > > "The (Bourne) shell is the standard user command interpreter. It > required > > > by far the largest conversion effort of any supposedly portable > program, > > > for the simple reason that it is not portable. Critical portions are > coded > > > in assembly language and had to be painstakingly rewritten. The shell > uses > > > its own sbrk which is functionally different from the standard routine > in > > > libc. The shell wants the routine which fields a signal to be passed a > > > parameter giving the number of the signal being caught; signal was > also a > > > private rou- tine. This was handled by having the operating system > provide > > > the parameter in the first place, doing away with the private code for > > > signal. The code in fixargs (for constructing the argument list to an > exec > > > system call) had to be diddled." > > > > > > The files in the V7 tree on the Tuhs website are dated January 1979, > so it > > > would seem that the fixes for 32V were immediately taken back to > Research. > > > As you point out, this means that the comments above do not refer to > the > > > well known source code, but to a predecessor of that (which I don’t > think > > > survived). > > > > > > > We have ample evidence that V7 was really something more akin to a > rolling > > release. Let me explain: We know from the leaked '50 changes' tape that > > many of the features were set earlier rather than later. This leaked in > > 1978 (if my notes are right), but I found references to it from as early > as > > November 1976 in > > http://www.toad.com/early-usenix-newsletters/197611-unix-news-n11.pdf. > This > > was 18 months after V6 was released, but over 2 years before V7 was > > released. In addition, we know from the AUUS newsletters in the archive > > document that the V7 release process process took a while to get through > > AT&T's legal department (IIRC a year, but I've not gone back to the AUUS > > newsletters to refresh my recollection). A big push of V7 was to make it > > portable as well (with AT&T doing an Interdata 8/32 port themselves, as > > well as at least looking at the Wollongong Interdata 7/32 port and the > > Harvard VM/370 port). In talking to Kirk and others that have been around > > from approximately that time, 32V was widely viewed as V7 for Vaxen. We > can > > see evidence in the surviving 32V files of evolution from the > 'PDP-11-like > > swapping to a more sophisticated paging algorithm' since we have the > > slowsys directory. It's my contention, as someone that coded in the era > > before good source code control, that it's evidence that somebody got it > > working, then renamed/copied it to slowsys while they got paging working > so > > they could build either kernel for A/B testing. Kirk has also told me > that > > the 32V port was started well in advance of V7's release to be both a > > useful product inside of Bell Labs (since Vaxen were starting to appear) > as > > well as to prove that V7 was portable enough. I'll be the first to admit > > this is at best conjecture that matches available facts, artifacts and > old > > timers recollections (sorry Kirk), but that we have no direct evidence > for. > > It also allowed the 3BSD efforts to get going before the official V7 > > release due to the close ties between Bell Labs and Berkeley and the > DARPA > > project around Unix. > > "So DEC came to us at Holmdel. We were clearly the second string. > Tom London and John Reiser were interested and so was Ken Swanson, and > we got the VAX in early '78. I didn't do any of the technical work. In > fact, I devoted a lot of energy and time to getting the management to > let us do it. It wasn't research, you see. However, they let us take > the time. And in about three months my small group ported Version 7 to > the VAX. We got the machine in January, they had it running in April, > and by August it really worked. > ... > So, with the blessings of BTL Area 11 management, we sent 32V to > Berkeley. It was in October or November, 1978" > > Charlie Roberts in Salus QCU > > "The operating system is Research version 7 as of April 15, 1978. > .. > Work on the C compiler began in mid-December 1977. The hardware arrived > on March 3. We held a party on May 19 to celebrate successful multiuser > operation of the system." > > London and Reiser > A UNIX Operating System for the DEC VAX-11/780 Computer > https://www.bell-labs.com/usr/dmr/www/otherports/32v.html > > > > > I believe that we can conclude that the original 'hard to port' Bourne > > shell was produced around the time of the 50 changes tape, give or take. > > And that all the unix porting efforts that pre-dated the V7 release > rolled > > what appeared in 32V into V7 to reduce the amount of pdp-11 assembler. > And > > those efforts are what we read about in the paper. > > "The Bourne shell work started either in early 1976, or maybe > late 1975. The first version was VERY different" > > John Mashey in net.unix-wizards, 18 Mar 86 > https://groups.google.com/g/alt.folklore.computers/c/xW3ZgEnFoFs > tuhs/Documentation/AUUGN/AUUGN-V06.6.pdf pg 39 > > "In 1976, Steve Bourne, who had recently joined 1127, wrote a new shell" > Kernighan, UNIX A History and a Memoir, 5.1 pg 88 > > Bourne's AsiaBSDCon 2016 talk also lists 1976 > and goes on to discuss sbrk() use causing problems with ports > https://youtu.be/7tQ2ftt3LO8?t=715 And at 5:18 he says he had a vax lab with three vaxen and the Lab's vax port didn't have virtual memory. Bill Joy with 3BSD which had virtual memory. They installed it on the vaxen because they were hitting physical memory limits for some of their programs.... This suggests that the 32V in the TUHS archive is a later one than this early port. 3BSD is listed as being released end of 1979... Still begs the question of when 32v started paging. :) But the time lines match up for the 32v effort to be fed back into the research code base... Warner > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Sun Jan 1 15:35:12 2023 From: crossd at gmail.com (Dan Cross) Date: Sun, 1 Jan 2023 00:35:12 -0500 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <18521483-A73C-4B5F-A76A-6098BD93E9BC@planet.nl> Message-ID: On Sun, Jan 1, 2023 at 12:27 AM Warner Losh wrote: > On Sat, Dec 31, 2022, 9:38 PM Jonathan Gray wrote: >> [snip] >> Bourne's AsiaBSDCon 2016 talk also lists 1976 >> and goes on to discuss sbrk() use causing problems with ports >> https://youtu.be/7tQ2ftt3LO8?t=715 > > And at 5:18 he says he had a vax lab with three vaxen and the Lab's vax port didn't have virtual memory. Bill Joy with 3BSD which had virtual memory. They installed it on the vaxen because they were hitting physical memory limits for some of their programs.... One wonders what is meant by "virtual memory" in this context. I contend that Unix has had "virtual memory" since moving off of the PDP-11/20, in the sense of having a virtual address space that was mapped onto a (possibly contiguous) physical address space. I think all of these references mean demand paging, possibly with page reclamation or whole-process swapping under memory pressure. - Dan C. From g.branden.robinson at gmail.com Sun Jan 1 15:52:13 2023 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Sat, 31 Dec 2022 23:52:13 -0600 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <18521483-A73C-4B5F-A76A-6098BD93E9BC@planet.nl> Message-ID: <20230101055213.va3hnzsxzeeot5an@illithid> At 2023-01-01T00:35:12-0500, Dan Cross wrote: > On Sun, Jan 1, 2023 at 12:27 AM Warner Losh wrote: > > On Sat, Dec 31, 2022, 9:38 PM Jonathan Gray wrote: > >> [snip] > >> Bourne's AsiaBSDCon 2016 talk also lists 1976 > >> and goes on to discuss sbrk() use causing problems with ports > >> https://youtu.be/7tQ2ftt3LO8?t=715 > > > > And at 5:18 he says he had a vax lab with three vaxen and the Lab's > > vax port didn't have virtual memory. Bill Joy with 3BSD which had > > virtual memory. They installed it on the vaxen because they were > > hitting physical memory limits for some of their programs.... > > One wonders what is meant by "virtual memory" in this context. I > contend that Unix has had "virtual memory" since moving off of the > PDP-11/20, in the sense of having a virtual address space that was > mapped onto a (possibly contiguous) physical address space. I think > all of these references mean demand paging, possibly with page > reclamation or whole-process swapping under memory pressure. I apologize if this point is too elementary, but I speculate that one possible source of confusion comes from a file naming convention: which of these (multiple) virtual memory or demand-paged VM systems installed the kernel under the name "vmunix" vs. "unix". Which ones did and did not? When I was first learning Unix I asked a local expert why the kernel was named "vmunix". They told me that it was because it supported virtual memory (and explained what that was, because I was even more callow then than now). Then I asked where the non-VM kernel was. I was informed that there wasn't one--it didn't even exist for modern architectures. I wondered then why, if virtual memory was a given, you wouldn't just go back to using the filename "unix". I wondered similar things when encountering the "vmlinux" file a couple of years later. Reflexive obeisance to traditions has a cost. 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 Sun Jan 1 16:27:11 2023 From: imp at bsdimp.com (Warner Losh) Date: Sat, 31 Dec 2022 23:27:11 -0700 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <18521483-A73C-4B5F-A76A-6098BD93E9BC@planet.nl> Message-ID: On Sat, Dec 31, 2022, 10:35 PM Dan Cross wrote: > On Sun, Jan 1, 2023 at 12:27 AM Warner Losh wrote: > > On Sat, Dec 31, 2022, 9:38 PM Jonathan Gray wrote: > >> [snip] > >> Bourne's AsiaBSDCon 2016 talk also lists 1976 > >> and goes on to discuss sbrk() use causing problems with ports > >> https://youtu.be/7tQ2ftt3LO8?t=715 > > > > And at 5:18 he says he had a vax lab with three vaxen and the Lab's vax > port didn't have virtual memory. Bill Joy with 3BSD which had virtual > memory. They installed it on the vaxen because they were hitting physical > memory limits for some of their programs.... > > One wonders what is meant by "virtual memory" in this context. I > contend that Unix has had "virtual memory" since moving off of the > PDP-11/20, in the sense of having a virtual address space that was > mapped onto a (possibly contiguous) physical address space. I think > all of these references mean demand paging, possibly with page > reclamation or whole-process swapping under memory pressure. > It's clear from context it's demand paging and that unlocks processes larger than physical memory. Imho. Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sun Jan 1 16:35:51 2023 From: imp at bsdimp.com (Warner Losh) Date: Sat, 31 Dec 2022 23:35:51 -0700 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <20230101055213.va3hnzsxzeeot5an@illithid> References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <18521483-A73C-4B5F-A76A-6098BD93E9BC@planet.nl> <20230101055213.va3hnzsxzeeot5an@illithid> Message-ID: On Sat, Dec 31, 2022, 10:53 PM G. Branden Robinson < g.branden.robinson at gmail.com> wrote: > At 2023-01-01T00:35:12-0500, Dan Cross wrote: > > On Sun, Jan 1, 2023 at 12:27 AM Warner Losh wrote: > > > On Sat, Dec 31, 2022, 9:38 PM Jonathan Gray wrote: > > >> [snip] > > >> Bourne's AsiaBSDCon 2016 talk also lists 1976 > > >> and goes on to discuss sbrk() use causing problems with ports > > >> https://youtu.be/7tQ2ftt3LO8?t=715 > > > > > > And at 5:18 he says he had a vax lab with three vaxen and the Lab's > > > vax port didn't have virtual memory. Bill Joy with 3BSD which had > > > virtual memory. They installed it on the vaxen because they were > > > hitting physical memory limits for some of their programs.... > > > > One wonders what is meant by "virtual memory" in this context. I > > contend that Unix has had "virtual memory" since moving off of the > > PDP-11/20, in the sense of having a virtual address space that was > > mapped onto a (possibly contiguous) physical address space. I think > > all of these references mean demand paging, possibly with page > > reclamation or whole-process swapping under memory pressure. > > I apologize if this point is too elementary, but I speculate that one > possible source of confusion comes from a file naming convention: which > of these (multiple) virtual memory or demand-paged VM systems installed > the kernel under the name "vmunix" vs. "unix". > > Which ones did and did not? > 3BSD started the vmunix name because it added virtual memory to unix (paging aspect of virtual memory). When I was first learning Unix I asked a local expert why the kernel was > named "vmunix". They told me that it was because it supported virtual > memory (and explained what that was, because I was even more callow then > than now). > > Then I asked where the non-VM kernel was. I was informed that there > wasn't one--it didn't even exist for modern architectures. I wondered > then why, if virtual memory was a given, you wouldn't just go back to > using the filename "unix". > V7 had "unix" for sure. 32V still had unix if my quick grep is right. I wondered similar things when encountering the "vmlinux" file a couple > of years later. > It was emulation of BSD and/or SunOS... Reflexive obeisance to traditions has a cost. > Yea... There was a thread in FreeBSD about what to name the kernel. Vmduck was suggested as a joke... Warner > Regards, > Branden > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Sun Jan 1 16:35:52 2023 From: robpike at gmail.com (Rob Pike) Date: Sun, 1 Jan 2023 17:35:52 +1100 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <20230101055213.va3hnzsxzeeot5an@illithid> References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <18521483-A73C-4B5F-A76A-6098BD93E9BC@planet.nl> <20230101055213.va3hnzsxzeeot5an@illithid> Message-ID: I distinctly remember I renamed to boot image on our research VAX (alice!) from "vmunix" to "unix". It had been long enough by that point that the lingering prefix was starting to sound like a brag. -rob On Sun, Jan 1, 2023 at 4:53 PM G. Branden Robinson < g.branden.robinson at gmail.com> wrote: > At 2023-01-01T00:35:12-0500, Dan Cross wrote: > > On Sun, Jan 1, 2023 at 12:27 AM Warner Losh wrote: > > > On Sat, Dec 31, 2022, 9:38 PM Jonathan Gray wrote: > > >> [snip] > > >> Bourne's AsiaBSDCon 2016 talk also lists 1976 > > >> and goes on to discuss sbrk() use causing problems with ports > > >> https://youtu.be/7tQ2ftt3LO8?t=715 > > > > > > And at 5:18 he says he had a vax lab with three vaxen and the Lab's > > > vax port didn't have virtual memory. Bill Joy with 3BSD which had > > > virtual memory. They installed it on the vaxen because they were > > > hitting physical memory limits for some of their programs.... > > > > One wonders what is meant by "virtual memory" in this context. I > > contend that Unix has had "virtual memory" since moving off of the > > PDP-11/20, in the sense of having a virtual address space that was > > mapped onto a (possibly contiguous) physical address space. I think > > all of these references mean demand paging, possibly with page > > reclamation or whole-process swapping under memory pressure. > > I apologize if this point is too elementary, but I speculate that one > possible source of confusion comes from a file naming convention: which > of these (multiple) virtual memory or demand-paged VM systems installed > the kernel under the name "vmunix" vs. "unix". > > Which ones did and did not? > > When I was first learning Unix I asked a local expert why the kernel was > named "vmunix". They told me that it was because it supported virtual > memory (and explained what that was, because I was even more callow then > than now). > > Then I asked where the non-VM kernel was. I was informed that there > wasn't one--it didn't even exist for modern architectures. I wondered > then why, if virtual memory was a given, you wouldn't just go back to > using the filename "unix". > > I wondered similar things when encountering the "vmlinux" file a couple > of years later. > > Reflexive obeisance to traditions has a cost. > > Regards, > Branden > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsg at jsg.id.au Sun Jan 1 17:11:37 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Sun, 1 Jan 2023 18:11:37 +1100 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <18521483-A73C-4B5F-A76A-6098BD93E9BC@planet.nl> Message-ID: On Sat, Dec 31, 2022 at 10:25:49PM -0700, Warner Losh wrote: > And at 5:18 he says he had a vax lab with three vaxen and the Lab's vax > port didn't have virtual memory. Bill Joy with 3BSD which had virtual > memory. They installed it on the vaxen because they were hitting physical > memory limits for some of their programs.... > > This suggests that the 32V in the TUHS archive is a later one than this > early port. 3BSD is listed as being released end of 1979... It was 4BSD and 1980 according to QCU: "In 1980 it was Bill Joy who flew to New Jersey and, together with Steve Bourne, put 4BSD up in Bell Labs. "We did it overnight," Joy told me. "We decided to do it about 9 p.m.; people showed up in the morning and a new os was running. It was pretty amazing." From imp at bsdimp.com Sun Jan 1 17:21:47 2023 From: imp at bsdimp.com (Warner Losh) Date: Sun, 1 Jan 2023 00:21:47 -0700 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <18521483-A73C-4B5F-A76A-6098BD93E9BC@planet.nl> Message-ID: On Sun, Jan 1, 2023, 12:11 AM Jonathan Gray wrote: > On Sat, Dec 31, 2022 at 10:25:49PM -0700, Warner Losh wrote: > > And at 5:18 he says he had a vax lab with three vaxen and the Lab's vax > > port didn't have virtual memory. Bill Joy with 3BSD which had virtual > > memory. They installed it on the vaxen because they were hitting physical > > memory limits for some of their programs.... > > > > This suggests that the 32V in the TUHS archive is a later one than this > > early port. 3BSD is listed as being released end of 1979... > > It was 4BSD and 1980 according to QCU: > > "In 1980 it was Bill Joy who flew to New Jersey and, together with Steve > Bourne, put 4BSD up in Bell Labs. "We did it overnight," Joy told me. > "We decided to do it about 9 p.m.; people showed up in the morning and a > new os was running. It was pretty amazing." > He said 3BSD in the video.... Interesting... Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsg at jsg.id.au Sun Jan 1 18:05:32 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Sun, 1 Jan 2023 19:05:32 +1100 Subject: [TUHS] Porting the SysIII kernel: boot, config & device drivers In-Reply-To: <45C94BFE-693D-4D86-8E4A-8DCC8C88774C@planet.nl> References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl> <45C94BFE-693D-4D86-8E4A-8DCC8C88774C@planet.nl> Message-ID: On Sat, Dec 31, 2022 at 09:02:38PM +0100, Paul Ruizendaal wrote: > > > > On 31 Dec 2022, at 15:59, Dan Cross wrote: > > > > On Fri, Dec 30, 2022 at 1:26 PM Paul Ruizendaal wrote: > >> [snip] > >> It would seem that the next step for Unix in the area of boot, config and device drivers came with Sun’s OpenBoot in 1988 or so. This also appears to be the first appearance of device trees to describe the hardware to the bios and the kernel. Moreover, it would seem to me that OpenBoot is a spiritual ancestor of the modern Risc-V SBI specification. Maybe by 1988 the IO hardware had become sufficiently complex and/or diverse to warrant a break from tradition? > >> > >> Was there any other notable Unix work on better organising the boot process and the device drivers prior to OpenBoot? > > > > I think that BSD supported autoconfiguration on the VAX well before > > OpenBoot; the OpenBSD man page says it dates from 4.1 (1981) and was > > revamped in 4.4. > > That is interesting. Are you referring to this: > https://www.tuhs.org/cgi-bin/utree.pl?file=4.1cBSD/a/sys/conf > https://www.tuhs.org/cgi-bin/utree.pl?file=4.1cBSD/usr/man/man8/config.8 "the tuned-up system, with the addition of Robert Elz's auto configuration code, was released as 4.1BSD in June, 1981" McKusick, Twenty Years of Berkeley Unix https://www.oreilly.com/openbook/opensources/book/kirkmck.html "This update to the fourth distribution of November 1980 provides support for the VAX 11/750 and for the full interconnect architecture of the VAX 11/780. Robert Elz of the University of Melbourne contributed greatly to this distribution especially in the boot-time system configuration code" http://bitsavers.org/bits/UCB_CSRG/4.1_BSD_19810710.zip 4.4 discussed in Torek's Device Configuration in 4.4BSD https://www.netbsd.org/docs/kernel/config-torek.ps https://www.netbsd.org/~mrg/config-torek-fixed.pdf which references: A New Framework for Device Support in Berkeley Unix from Proceedings of the UKUUG, London, Summer 1990. not online, though Chris sent Warner a copy in 2021 https://minnie.tuhs.org/pipermail/tuhs/2021-April/023756.html I would also like to read it. Perhaps it could be added to the archive? From pnr at planet.nl Sun Jan 1 20:25:21 2023 From: pnr at planet.nl (Paul Ruizendaal) Date: Sun, 1 Jan 2023 11:25:21 +0100 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <18521483-A73C-4B5F-A76A-6098BD93E9BC@planet.nl> Message-ID: <67F165EB-17E6-4317-AF8D-E6F20B7F3DE6@planet.nl> > On 1 Jan 2023, at 06:25, Warner Losh wrote: > > Still begs the question of when 32v started paging. :) The London/Reiser paper includes: "Work on the C compiler began in mid-December 1977. The hardware arrived on March 3. We held a party on May 19 to celebrate successful multiuser operation of the system." John Reiser had the following timeline in a mail conversation about a year ago. "Our VAX-11/780, the first one delivered to a customer, arrived Feb.12, 1978 (Lincoln's Birthday). Tom and I had been preparing using PDP-11/45 since December, and we achieved "login: " on the console DECwriter by April 15 (the deadline for US income tax filing). The rest of 1978 was "tuning", and preparing for the release of "UNIX-32/V" to UC Berkeley.” The dates don’t match to the day, but the timeline is essentially the same (moreover, delivery of VAX hardware is not the same as it being operational, achieving login: is but the first step of bringing the user land up). This sets a minimum timeline for arriving at a first version of “slowsys”. The timestamps on the surviving files of slowsys show January 1979. Joy and Babaoglu write in “Converting a Swap-Based System to do Paging in an Architecture Lacking Page-Referenced Bits”: "In the fall of 1978 the Computer Science Division of the University of California at Berkeley purchased a VAX-11/780 and arranged to run an early version of UNIX for the VAX provided by Bell Laboratories under a cooperative research agreement. [...] A subsequent version of the system was capable of loading processes into noncontiguous real memory locations, called scatter loading , and was able to swap only portions of a process, called partial swapping, as deemed necessary by the memory contention. This would become the basis for the paging system development discussed in this paper.” This places the earliest moment for scatter paging as the Fall of 1978. The timestamps of the surviving files of sys show March 1979, which is the latest moment. The for the timeline of 32V with true demand paging John Reiser recalled: "My annual performance review in early 1979 said "Well done; but don't ever do it again” because it was not regarded as "Research”. So what did I do? I did it again; this time, with demand paging. I designed and implemented mmap() based on experience with PDP-10/Tenex PMAP page mapping system call. I fretted over introducing the first UNIX system call with 6 arguments.” John recalls that it was a 6 or 7 months effort, with the last few being a "long tail" of decreasing attention. The would place this third version as completed around the Fall of 1979. This is consistent with Rob Pike’s recollection that he saw it being demonstrated early in 1980. In 1980 Research had to chose how to progress in the field of memory management. The Reiser system was cool, but not supported by management and the BSD VM system was seen as good enough to use. 3BSD is from early 1980, 4BSD from late 1980. Likely the conflicting recollections of Bill Joy are because it was a snapshot somewhere in between (plus the general issues around recollection). In any case, the 1985 snapshot of 8th edition appears to have been based on 4.1BSD (early 1981), so that is when the systems split. From arnold at skeeve.com Sun Jan 1 20:44:37 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 01 Jan 2023 03:44:37 -0700 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> Message-ID: <202301011044.301Aib7T009476@freefriends.org> Chet Ramey wrote: > On 12/30/22 1:25 PM, Paul Ruizendaal wrote: > > > > London and Reiser report about porting the shell that “it required by > > far the largest conversion effort of any supposedly portable program, > > for the simple reason that it is not portable.” By the time of SysIII > > this is greatly improved, but also in porting the SysIII user land it > > was the most complex of the set so far. > > Have you read > > http://www.collyer.net/who/geoff/sh.tour.pdf > > and looked at http://www.collyer.net/who/geoff/v7sh.tar ? > > In the limited literature on Bourne Shell porting, this is authoritative. > > Arnold Robbins built on that work and ported the v8-v10 shells to modern > Linux versions. (I am sorry, I do not have a link right now.) Sorry to say, it wasn't me. Geoff Collyer made the v9 sh portable and it's available from his web site. I did do stuff with the shell back in the 80s: - I back-ported Ron Natalie's job control into the 4.2 BSD sh, along with a history mechanism I wrote from scratch that was inspired by csh. I posted the diffs in comp.sources.unix. - A few very minor features were added to ksh at my suggestion. ISTR that one was `set -A array-name value ...' but I don't see that in current ksh93 doc. - I was a reviewer for both editions of David Korn's book on ksh. - I contributed to pdksh, although I don't remember what. The pdksh doc lists my name though. - In the early 90s I did a little banging on the vi mode in the readline librar so that bash's vi mode would be closer to what I'd been used to in ksh. In the late 80s I got interested in awk and moved almost all my personal scripting to awk, although I still do shell work at $DAYJOB or for personal use as needed. Arnold From arnold at skeeve.com Sun Jan 1 21:28:08 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 01 Jan 2023 04:28:08 -0700 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <202301011044.301Aib7T009476@freefriends.org> References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <202301011044.301Aib7T009476@freefriends.org> Message-ID: <202301011128.301BS8D2015648@freefriends.org> I wrote: > I did do stuff with the shell back in the 80s: I also recall that there was some USENET discussion in which Rob Pike described how the 8th edition shell changed the search order to have functions come before non-special built-ins, with the addition of "builtin" and "whatis" commands. Rob was kind enough to send me the sh.1 man page from the 8th edition (which I still have somewhere), and I made this change in the S5r2 shell. I don't know if I posted diffs or not. In any case, as part of implementing whatis, I wrote a pretty printer for shell functions. (Getting 'elif' right needed some extra code.) I offered it to Rob, who politely declined, indicating that he had his own. Ah, those were the days... :-) Arnold From ron at ronnatalie.com Mon Jan 2 00:50:07 2023 From: ron at ronnatalie.com (Ron Natalie) Date: Sun, 01 Jan 2023 14:50:07 +0000 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <18521483-A73C-4B5F-A76A-6098BD93E9BC@planet.nl> Message-ID: Paging was what they were referring to. The Bell releases at the time only swapped like they did on the PDP-11. BSD allowed only fragments of the program to need be resident. The joke as “It ain’t virtual unless it isn’t all there." ------ Original Message ------ >From "Dan Cross" To "Warner Losh" Cc "Jonathan Gray" ; "Paul Ruizendaal" ; "The Eunuchs Hysterical Society" ; "segaloco" Date 1/1/2023 12:35:12 AM Subject [TUHS] Re: A few comments on porting the Bourne shell >On Sun, Jan 1, 2023 at 12:27 AM Warner Losh wrote: >> On Sat, Dec 31, 2022, 9:38 PM Jonathan Gray wrote: >>> [snip] >>> Bourne's AsiaBSDCon 2016 talk also lists 1976 >>> and goes on to discuss sbrk() use causing problems with ports >>>https://youtu.be/7tQ2ftt3LO8?t=715 >> >> And at 5:18 he says he had a vax lab with three vaxen and the Lab's vax port didn't have virtual memory. Bill Joy with 3BSD which had virtual memory. They installed it on the vaxen because they were hitting physical memory limits for some of their programs.... > >One wonders what is meant by "virtual memory" in this context. I >contend that Unix has had "virtual memory" since moving off of the >PDP-11/20, in the sense of having a virtual address space that was >mapped onto a (possibly contiguous) physical address space. I think >all of these references mean demand paging, possibly with page >reclamation or whole-process swapping under memory pressure. > > - Dan C. From pnr at planet.nl Mon Jan 2 06:29:17 2023 From: pnr at planet.nl (Paul Ruizendaal) Date: Sun, 1 Jan 2023 21:29:17 +0100 Subject: [TUHS] Porting the SysIII kernel: boot, config & device drivers In-Reply-To: References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl> Message-ID: > On 31 Dec 2022, at 23:38, Theodore Ts'o wrote: > > If we don't agree on exactly what problem that we are trying to solve > with BSD-style autoconfig, vs UEFI vs ACPI vs the x86 BIOS vs CP/M's > BIOS, etc. Otherwise, the risk that we'll end up talking past one > another, or delivering a solution that we're happy with, but others > are not, is quite high IMHO. Wise words, I was indeed jumping to a conclusion without defining the question. Douglas Adams comes to mind. On the positive side, it did generate a lot of insightful posts that I hope to digest in the coming days. > On 31 Dec 2022, at 22:10, Dan Cross wrote: > > Mothy Roscoe gave a really interesting keynote at OSDI'21: > https://www.youtube.com/watch?v=36myc8wQhLo What an interesting keynote! At first he makes the case that OS research is dead (not unlike Rob’s similar observation 20 years before). However, he goes on to point out a specific challenge that he feels is in dire need of research and innovation. In short his case is that a modern SoC is nothing like a VAX, but Linux still treats all hardware like a VAX. Having watched his keynote I can better place my generic discomfort with the amount of code required outside of the classical OS on a SoC. ==== Below some clarification on the topics that were on my mind: > That makes figuring out where the host OS image is and getting it loaded > into memory a real pain in the booty; not to mention on modern systems > where you’ve got to do memory training as part of initializing DRAM > controllers and the like. That was my immediate pain point in doing the D1 SoC port. Unfortunately, the manufacturer only released the DRAM init code as compiler ‘-S’ output and the 1,400 page datasheet does not discuss its registers. Maybe this is a-typical, as I heard in the above keynote that NXP provides 8,000 page datasheets with their SoC’s. Luckily, similar code for ARM chips from this manufacturer was available as C source and I could reverse engineer the assembler file back to about 1,800 lines of C. See https://gitlab.com/pnru/xv6-d1/-/blob/master/boot0/sdram.c It does all the expected things (set voltage, switch on the main clock, set up the PLL, calculate delays in terms of clocks, train for the line delays, probe address multiplexing, etc.) by accessing a multitude of registers that appear directly connected to the controller fabric. Yet, at the same time it has only a single entry point (“init_DRAM”) that takes 24 (poorly documented) words of 32 bits to define the desired configuration (with options to specify “default” or “auto”). Why does the main processor need to run this code? Why is there not a small RV32E CPU inside this controller that runs the 1,800 lines and exposes just the 24 words as registers to the main CPU? Are the square mils really that expensive? Or is this the reason that many SoC’s (but not the D1) have a small side CPU to do this for all devices? Next, to read from the SD Card, its controller needs to be set up. Luckily here the manufacturer gives out actual C code and there is documentation. However it is another 1,400 lines of code. About half the code goes to initialising the controller hardware, the other half to negotiating with the card to find out the data width and maximum speed. Together with setting up the SoC clock distribution and the console UART I have about 3,500 lines of setup code. And this is just the 1st stage boot loader that has to run from a little bit of SRAM space on the SoC. I have not looked yet at setting up the ethernet, wifi, display, usb, etc., but undoubtedly this is between 1,000 and 2,000 lines each. This compares to about 7,000 lines for the SysIII kernel. There is also the question of what goes where. For the SD Card, does a boot level module need to decide or operate the transfer mode? Should this not be in the kernel? Maybe some of this should even be in a daemon? It may seem to be a modern problem, but conceptually these very same questions were at play when doing a compare and contrast between the organisation of networking in 4.2BSD and 8th Edition. The former has nearly everything in the kernel, the latter does a split over device drivers, stream filters and daemons. This same question also comes up for all the other devices, in particular usb. ==== I’m not quite sure I agree with Rob’s observation on boot ROM’s. While I get his point about organisational causes of bloat, it is not just about the boot ROM. On a RISC-V or ARM SoC the boot sequence is lengthy and the boot rom does little more than bring the system to a safe state and load the first stage boot loader. The full boot process is quite lengthy (e.g. https://riscv.org/wp-content/uploads/2019/12/Summit_bootflow.pdf) and several parts are SoC specific. One of the things on my mind was that SoC boards change quite quickly: the D1 was last year’s hit with hobbyists, next year it will be something else. Not nice if one has to redo 3,500-10,000 lines of code for each board. Although I am not a fan of Forth, I can see that it is useful when the controller IP blocks of a SoC (or the PCI cards of discrete systems) expose some form of re-targetable program needed to boot it up. The manufacturer BSP code is just not plug & play. Having watched Mothy Roscoe’s keynote, I realise that I was trying to create a way to make a modern SoC look like a VAX. Maybe valid for my archeology purposes, but not in the general case. On top it did not solve the crappy BSP code issue. Maybe the correct solution for my archeology is to just use the simpler FPGA SoC as a target. ==== > Virtio is solving a very, very different problem: this is limited > paravirtualization of devices for virtual machines. Yes, this is where it started, but it seems to get traction as a standardised embedded device interface, especially in automotive (Google for "automotive virtio”). Also in FPGA implementations it seems to get more popular as a device interface e.g. the RVSoc system from the Uni of Tokyo. This one has a very simple & partial HW implementation, but it is enough to support an unmodified Linux. I don’t think I agree with every observation made on direct virtio implementation (I certainly agree with some) -- but that is maybe off topic for this list. I will observe however that many device controllers of the early-mid-80’s contained some sort of embedded processor, some even on the low cost end of the market -- think of the WD-1002 hard disk controller variant used in the PC-AT. For mini’s this was not unusual either, I already mentioned the M68K on the Unibus DEULA board, the T11 on the Qbus RQDX2 board is another example. Having smart controllers was cost competitive, even in the 80’s. ==== >> - MMU abstraction somewhat similar in idea to that in SYSV/68 [1] > > It's not clear to me what this would buy you; the MMU tends to be > architecturally defined, Today, yes, but not in the early 80’s. For the M68K and the Z8000 there were both segmented and paged MMU’s and often custom designs were used (think Onyx C8000, SUN-1). However, my thinking here was driven by an entirely different thing. I have referred before to the early history of Xenix, for example this chart: http://seefigure1.com/images/xenix/xenix-timeline.jpg (the whole page http://seefigure1.com/2014/04/15/xenixtime.html makes for an interesting read). For a long time I have wondered why early Xenix did not make the jump to a product that was split between a BIOS and a BDOS part, so that they could sell BDOS-part updates to the total installed base. The BDOS part could even be in some kind of p-code. Considering that they heavily invested in their “revenue bomb” C-compiler at the time, this type of thinking was close to their hart (the Amsterdam Compiler Kit was a similar idea). I am talking ’81-’83 here, thereafter it is clear that their economic interest was to focus on DOS. There are 3 possibilities: 1. It did not make technical sense 2. It did not make economic sense 3. It did make sense, but it simply did not happen So, yes, I was conflating a lot of different thoughts into a single solution, without first thinking clearly about the question. > let's remember that Unix was _very_ success on a variety of > systems in that era without relying on a BIOS-type abstraction! For sure, that is undisputed. But could it have been even more successful? Maybe the main reason for "no BIOS attempt" was purely economic: for the companies having to port to each and every machine created customer lock-in, and for the professionals it created an industry of well paying porting & maintenance jobs. The customers were willing to pay for it. Why kill the golden goose? From g.branden.robinson at gmail.com Mon Jan 2 07:26:09 2023 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Sun, 1 Jan 2023 15:26:09 -0600 Subject: [TUHS] Porting the SysIII kernel: boot, config & device drivers In-Reply-To: References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl> Message-ID: <20230101212609.yjg2poiggil7pwat@illithid> At 2023-01-01T21:29:17+0100, Paul Ruizendaal wrote: > > Mothy Roscoe gave a really interesting keynote at OSDI'21: > > https://www.youtube.com/watch?v=36myc8wQhLo > > What an interesting keynote! At first he makes the case that OS > research is dead (not unlike Rob’s similar observation 20 years > before). > > However, he goes on to point out a specific challenge that he > feels is in dire need of research and innovation. In short his case is > that a modern SoC is nothing like a VAX, but Linux still treats all > hardware like a VAX. As do C programmers. https://queue.acm.org/detail.cfm?id=3212479 > > That makes figuring out where the host OS image is and getting it > > loaded into memory a real pain in the booty; not to mention on > > modern systems where you’ve got to do memory training as part of > > initializing DRAM controllers and the like. > > That was my immediate pain point in doing the D1 SoC port. > Unfortunately, the manufacturer only released the DRAM init code as > compiler ‘-S’ output and the 1,400 page datasheet does not discuss its > registers. Maybe this is a-typical, as I heard in the above keynote > that NXP provides 8,000 page datasheets with their SoC’s. Luckily, > similar code for ARM chips from this manufacturer was available as C > source and I could reverse engineer the assembler file back to about > 1,800 lines of C. See > https://gitlab.com/pnru/xv6-d1/-/blob/master/boot0/sdram.c I don't think it's atypical. I was pretty annoyed trying to use the data sheet to program a simple timer chip on the ODROID-C2; the sheet was simply erroneous about the address of one of the registers you needed to poke to set up a repeating timer. When I spoke to people more experienced with banging on modern devices, I was mostly met with resignation and rolled shoulders. I grew up in the hobbyist era; these days it is _only_ OS nerds who program these devices, and these OS nerds don't generally handle procurement themselves. Instead, purchasing managers do, and those people don't have to face the pain. Data sheets are only as good as they need to be to move the product, which means they don't need to be good at all, since the people who pay for them look only at the advertised feature list and the price. > It does all the expected things (set voltage, switch on the main > clock, set up the PLL, calculate delays in terms of clocks, train for > the line delays, probe address multiplexing, etc.) by accessing a > multitude of registers that appear directly connected to the > controller fabric. Yet, at the same time it has only a single entry > point (“init_DRAM”) that takes 24 (poorly documented) words of 32 bits > to define the desired configuration (with options to specify “default” > or “auto”). > > Why does the main processor need to run this code? Why is there not a > small RV32E CPU inside this controller that runs the 1,800 lines and > exposes just the 24 words as registers to the main CPU? Are the square > mils really that expensive? Or is this the reason that many SoC’s (but > not the D1) have a small side CPU to do this for all devices? I can't speak to the economic arguments but it seems wasteful to me to have an auxiliary CPU that is--or _should_--be used only to bring up the board. The other problem I have is more ominous. "Ah, BMC. Now every computer comes with an extra full-fledged computer! The main computer is for your use, and the other computer is for the use of the attacker." — Russ Allbery But the real problem is with the software these auxiliary processors run. My first encounter with auxiliary processors was with the TRS-80 Model 16 line in the early 1980s, which was also available as an upgrade option from the Model II. The II ran a Zilog Z80. The Model 16 upgrade added a 68000 board which became the main CPU, and the Z80 was relegated to I/O management. This turned out to work really well. I gather that big IBM iron was doing this sort of thing decades earlier. That at least is an honorable and useful application of the additional core, instead of smuggling your keystrokes and network packets out to interested intelligence agencies and harvesters for targeted advertising. [...] > One of the things on my mind was that SoC boards change quite quickly: > the D1 was last year’s hit with hobbyists, next year it will be > something else. Not nice if one has to redo 3,500-10,000 lines of code > for each board. Although I am not a fan of Forth, I can see that it is > useful when the controller IP blocks of a SoC (or the PCI cards of > discrete systems) expose some form of re-targetable program needed to > boot it up. The manufacturer BSP code is just not plug & play. Yes. I too think Forth is a little weird but I appreciate its power/memory footprint ratio. I really admire OpenFirmware and was intensely disappointed when the RISC-V community didn't take the opportunity to resurrect it. Forth code seems a lot more auditable to me than machine language blobs. > Maybe the correct solution for my archeology is to just use the > simpler FPGA SoC as a target. Maybe it's the correct solution for anyone who cares about a verified boot process, too. No one who sells silicon seems to. > For a long time I have wondered why early Xenix did not make the jump > to a product that was split between a BIOS and a BDOS part, so that > they could sell BDOS-part updates to the total installed base. The > BDOS part could even be in some kind of p-code. Considering that they > heavily invested in their “revenue bomb” C-compiler at the time, this > type of thinking was close to their hart You _really have_ been writing for RISC-V lately... ;-) > (the Amsterdam Compiler Kit was a similar idea). I am talking ’81-’83 > here, thereafter it is clear that their economic interest was to focus > on DOS. > > There are 3 possibilities: > 1. It did not make technical sense > 2. It did not make economic sense > 3. It did make sense, but it simply did not happen > > So, yes, I was conflating a lot of different thoughts into a single > solution, without first thinking clearly about the question. Someone is bound to suggest that p-code was, or still is, detrimental to boot times. But cores are so much faster than memory buses, and JIT compilers so far advanced over what was available in the 1980s, that I wonder if that is simply a myth today for any implementation that didn't go out of its way to be slow. > For sure, that is undisputed. But could it have been even more > successful? Maybe the main reason for "no BIOS attempt" was purely > economic: for the companies having to port to each and every machine > created customer lock-in, and for the professionals it created an > industry of well paying porting & maintenance jobs. The customers were > willing to pay for it. Why kill the golden goose? Never compete on margins when you can extract monopoly rents, leverage asymmetric information, impose negative externalities, and defraud your customer or the public generally. Everybody who stops learning economics after their first micro class is a sheep waiting your shears. 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 robpike at gmail.com Mon Jan 2 07:31:10 2023 From: robpike at gmail.com (Rob Pike) Date: Mon, 2 Jan 2023 08:31:10 +1100 Subject: [TUHS] Porting the SysIII kernel: boot, config & device drivers In-Reply-To: <20230101212609.yjg2poiggil7pwat@illithid> References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl> <20230101212609.yjg2poiggil7pwat@illithid> Message-ID: Seems like a good time to pull out the "wheel of reincarnation" paper. http://cva.stanford.edu/classes/cs99s/papers/myer-sutherland-design-of-display-processors.pdf I think about it a lot when I ponder the state of graphics these days. The wheel does seem finally to have rusted in place, although I'm not sure I'd choose this exact angle of rotation. -rob On Mon, Jan 2, 2023 at 8:27 AM G. Branden Robinson < g.branden.robinson at gmail.com> wrote: > At 2023-01-01T21:29:17+0100, Paul Ruizendaal wrote: > > > Mothy Roscoe gave a really interesting keynote at OSDI'21: > > > https://www.youtube.com/watch?v=36myc8wQhLo > > > > What an interesting keynote! At first he makes the case that OS > > research is dead (not unlike Rob’s similar observation 20 years > > before). > > > > However, he goes on to point out a specific challenge that he > > feels is in dire need of research and innovation. In short his case is > > that a modern SoC is nothing like a VAX, but Linux still treats all > > hardware like a VAX. > > As do C programmers. https://queue.acm.org/detail.cfm?id=3212479 > > > > That makes figuring out where the host OS image is and getting it > > > loaded into memory a real pain in the booty; not to mention on > > > modern systems where you’ve got to do memory training as part of > > > initializing DRAM controllers and the like. > > > > That was my immediate pain point in doing the D1 SoC port. > > Unfortunately, the manufacturer only released the DRAM init code as > > compiler ‘-S’ output and the 1,400 page datasheet does not discuss its > > registers. Maybe this is a-typical, as I heard in the above keynote > > that NXP provides 8,000 page datasheets with their SoC’s. Luckily, > > similar code for ARM chips from this manufacturer was available as C > > source and I could reverse engineer the assembler file back to about > > 1,800 lines of C. See > > https://gitlab.com/pnru/xv6-d1/-/blob/master/boot0/sdram.c > > I don't think it's atypical. I was pretty annoyed trying to use the > data sheet to program a simple timer chip on the ODROID-C2; the sheet > was simply erroneous about the address of one of the registers you > needed to poke to set up a repeating timer. When I spoke to people more > experienced with banging on modern devices, I was mostly met with > resignation and rolled shoulders. I grew up in the hobbyist era; these > days it is _only_ OS nerds who program these devices, and these OS nerds > don't generally handle procurement themselves. Instead, purchasing > managers do, and those people don't have to face the pain. > > Data sheets are only as good as they need to be to move the product, > which means they don't need to be good at all, since the people who pay > for them look only at the advertised feature list and the price. > > > It does all the expected things (set voltage, switch on the main > > clock, set up the PLL, calculate delays in terms of clocks, train for > > the line delays, probe address multiplexing, etc.) by accessing a > > multitude of registers that appear directly connected to the > > controller fabric. Yet, at the same time it has only a single entry > > point (“init_DRAM”) that takes 24 (poorly documented) words of 32 bits > > to define the desired configuration (with options to specify “default” > > or “auto”). > > > > Why does the main processor need to run this code? Why is there not a > > small RV32E CPU inside this controller that runs the 1,800 lines and > > exposes just the 24 words as registers to the main CPU? Are the square > > mils really that expensive? Or is this the reason that many SoC’s (but > > not the D1) have a small side CPU to do this for all devices? > > I can't speak to the economic arguments but it seems wasteful to me to > have an auxiliary CPU that is--or _should_--be used only to bring up the > board. The other problem I have is more ominous. > > "Ah, BMC. Now every computer comes with an extra full-fledged computer! > The main computer is for your use, and the other computer is for the use > of the attacker." — Russ Allbery > > But the real problem is with the software these auxiliary processors > run. My first encounter with auxiliary processors was with the TRS-80 > Model 16 line in the early 1980s, which was also available as an upgrade > option from the Model II. The II ran a Zilog Z80. The Model 16 upgrade > added a 68000 board which became the main CPU, and the Z80 was relegated > to I/O management. This turned out to work really well. I gather that > big IBM iron was doing this sort of thing decades earlier. That at > least is an honorable and useful application of the additional core, > instead of smuggling your keystrokes and network packets out to > interested intelligence agencies and harvesters for targeted > advertising. > > [...] > > One of the things on my mind was that SoC boards change quite quickly: > > the D1 was last year’s hit with hobbyists, next year it will be > > something else. Not nice if one has to redo 3,500-10,000 lines of code > > for each board. Although I am not a fan of Forth, I can see that it is > > useful when the controller IP blocks of a SoC (or the PCI cards of > > discrete systems) expose some form of re-targetable program needed to > > boot it up. The manufacturer BSP code is just not plug & play. > > Yes. I too think Forth is a little weird but I appreciate its > power/memory footprint ratio. I really admire OpenFirmware and was > intensely disappointed when the RISC-V community didn't take the > opportunity to resurrect it. Forth code seems a lot more auditable to > me than machine language blobs. > > > Maybe the correct solution for my archeology is to just use the > > simpler FPGA SoC as a target. > > Maybe it's the correct solution for anyone who cares about a verified > boot process, too. No one who sells silicon seems to. > > > For a long time I have wondered why early Xenix did not make the jump > > to a product that was split between a BIOS and a BDOS part, so that > > they could sell BDOS-part updates to the total installed base. The > > BDOS part could even be in some kind of p-code. Considering that they > > heavily invested in their “revenue bomb” C-compiler at the time, this > > type of thinking was close to their hart > > You _really have_ been writing for RISC-V lately... ;-) > > > (the Amsterdam Compiler Kit was a similar idea). I am talking ’81-’83 > > here, thereafter it is clear that their economic interest was to focus > > on DOS. > > > > There are 3 possibilities: > > 1. It did not make technical sense > > 2. It did not make economic sense > > 3. It did make sense, but it simply did not happen > > > > So, yes, I was conflating a lot of different thoughts into a single > > solution, without first thinking clearly about the question. > > Someone is bound to suggest that p-code was, or still is, detrimental to > boot times. But cores are so much faster than memory buses, and JIT > compilers so far advanced over what was available in the 1980s, that I > wonder if that is simply a myth today for any implementation that didn't > go out of its way to be slow. > > > For sure, that is undisputed. But could it have been even more > > successful? Maybe the main reason for "no BIOS attempt" was purely > > economic: for the companies having to port to each and every machine > > created customer lock-in, and for the professionals it created an > > industry of well paying porting & maintenance jobs. The customers were > > willing to pay for it. Why kill the golden goose? > > Never compete on margins when you can extract monopoly rents, leverage > asymmetric information, impose negative externalities, and defraud your > customer or the public generally. Everybody who stops learning > economics after their first micro class is a sheep waiting your shears. > > Regards, > Branden > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mah at mhorton.net Mon Jan 2 15:10:20 2023 From: mah at mhorton.net (Mary Ann Horton) Date: Sun, 1 Jan 2023 21:10:20 -0800 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> Message-ID: <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net> On 12/30/22 20:23, Dave Horsfall wrote: > Yep; whoever wrote CSH must've been high on something, as the syntax makes > no sense whatsoever. Bill Joy wrote csh. He based it on the V6 shell.  It made perfect sense at the time. This was before the V7 Bourne shell came out. Thanks, /Mary Ann Horton/ (she/her/ma'am) maryannhorton.com "This is a great book" - Monica Helms "Brave and Important" - Laura L. Engel       Available on Amazon and bn.com! -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Jan 3 02:25:06 2023 From: clemc at ccc.com (Clem Cole) Date: Mon, 2 Jan 2023 11:25:06 -0500 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net> References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net> Message-ID: Be careful in applying modern judgments without remembering the historical context - below On Mon, Jan 2, 2023 at 12:12 AM Mary Ann Horton wrote: > On 12/30/22 20:23, Dave Horsfall wrote: > > Yep; whoever wrote CSH must've been high on something, as the syntax makes > no sense whatsoever. > > Bill Joy wrote csh. He based it on the V6 shell. It made perfect sense at > the time. This was before the V7 Bourne shell came out. > Right -- let me add a little detail to this that might help. With the Fourth, Fifth, and Sixth Edition the default shell from Research is the Thompson shell. It's simple and un-adorn. Get the job done for typing, but as a formal scripting (programming) language is not easy to use. In fact, the command 'cd' idiom is still 'chdir' [add it was a typical local hack that many of did]. If you look at the USENIX tapes in the TUHS archives, in particular, the Harvard tape I suspect you will find a number of alternative shells that people had offered up from the different sites. With 'BSD' (the first UNIX distribution tape from the UCB Industrial Liasion Office of EECS which we often refer to on this list as 1BSD to distinguish it from the other releases - also available on TUHS], there is a new Berkeley shell, that Mary Ann points out Bill had created by modifying the Thompson shell and added some features to it. By the time of the 2BSD, the shell has been further been refined and by then renamed the csh, as the syntax had been made to approximate the C language. A big difference between the *Thompson Shell begets -> Berkeley Shell -> begets C Shell *and Bourne's work on his shell, is that Steve started from scratch. Steve had just come off many years of the Algol 68 project and was certainly extremely well-versed in the detailed subtleties of the semantics of language design. His higher bit was to create something *easier for people to write scripts using the -> small is beautiful -> Unix philosophy ideas*. Bill, on the other hand, is the quintessential hacker (My line is him in those days used to be: "He types open curly brace, close curly brace and he patches at 9600 baud.") Bill was interested in a shell that made typing easy, was not a load the system, and made it easy for >>him<< to write simple admin scripts. I would suggest both were 100% successful at what their purpose was. Like Larry, I have always been a meany and I have tried to make darned sure my folks (even to this day - we will see how long that last after I retire) use V7 syntax scripts - not bash, not even korn. As I said, the old UNIX hacker wisdom, has been "*Bourne to Program, Type with **Joy*" and you have a hard time going wrong. [FYI - while I have tcsh around, on my Mac these days I finally switched from tcsh to zsh as my default, but pretty much all of Bill's typing tricks are supported in zsh so the 'ROMs" in my fingers are happy after >40 years"] but all of my scripts are still V7 syntax - never been a reason to change that -- bigger issues usually found are GNU/Linux is not UNIX and Apple had to pee on things also. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Tue Jan 3 02:51:20 2023 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 2 Jan 2023 08:51:20 -0800 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net> Message-ID: <20230102165120.GK25547@mcvoy.com> On Mon, Jan 02, 2023 at 11:25:06AM -0500, Clem Cole wrote: > Like Larry, I have always been a meany and I have tried to make darned sure > my folks (even to this day - we will see how long that last after I retire) > use V7 syntax scripts - not bash, not even korn. I think it is less of an issue today but if I were still supporting a multi platform product, I'd still insist on it. Ya never know when a big pile of money is going to show and insist that you work on SCO based cash registers or something. Every. Single. Time. one of my engineers whined that they liked bash better, we'd hit on some supported platform where /bin/sh is not bash. And as we shipped scripts that people expected to work, you can't fix their /bin/sh. I won that argument over and over and eventually we all instinctively wrote portable scripts. From athornton at gmail.com Tue Jan 3 03:32:50 2023 From: athornton at gmail.com (Adam Thornton) Date: Mon, 2 Jan 2023 10:32:50 -0700 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <20230102165120.GK25547@mcvoy.com> References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net> <20230102165120.GK25547@mcvoy.com> Message-ID: > On Jan 2, 2023, at 9:51 AM, Larry McVoy wrote: > > On Mon, Jan 02, 2023 at 11:25:06AM -0500, Clem Cole wrote: >> Like Larry, I have always been a meany and I have tried to make darned sure >> my folks (even to this day - we will see how long that last after I retire) >> use V7 syntax scripts - not bash, not even korn. > And as we shipped > scripts that people expected to work, you can't fix their /bin/sh. > > I won that argument over and over and eventually we all instinctively > wrote portable scripts. I feel like after POSIX.2 had had a few years to settle, it was OK to use *that* as your scripting language (I particularly like $() rather than backticks, because of nestability, although you can certainly argue that if you're regularly nesting your interpolations, it's the design that's broken, not the specific syntax of the command). At least as long as you put a very visible comment right at the top saying "We're assuming POSIX shell." But of course the "after it had had a few years to settle" is doing a lot of lifting there. During the Unix Wars, yeah, clearly using v7 sh as lowest-common-denominator was the right choice. After the establishment of Linux Hegemony sometime in the early 2000s, I think I remember that you could pretty much count on everyone at least providing a POSIX shell, even if it wasn't the default. (But of course by then, "everyone" that wasn't Linux or OS X was already down to more-or-less Sun, IBM, HP, and DEC/Compaq.) These days, if you have a vendor-supplied shell script that DOESN'T work correctly under a POSIX /bin/sh, that should be treated as a defect. Adam From lm at mcvoy.com Tue Jan 3 03:43:04 2023 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 2 Jan 2023 09:43:04 -0800 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net> <20230102165120.GK25547@mcvoy.com> Message-ID: <20230102174304.GM25547@mcvoy.com> On Mon, Jan 02, 2023 at 10:32:50AM -0700, Adam Thornton wrote: > But of course the "after it had had a few years to settle" is doing > a lot of lifting there. During the Unix Wars, yeah, clearly using > v7 sh as lowest-common-denominator was the right choice. After the > establishment of Linux Hegemony sometime in the early 2000s, I think I > remember that you could pretty much count on everyone at least providing > a POSIX shell, even if it wasn't the default. (But of course by then, > "everyone" that wasn't Linux or OS X was already down to more-or-less Sun, > IBM, HP, and DEC/Compaq.) I was supporting a commercial product in the early 2000's and there were all sorts of systems then that had old shells. Yes, you could make everything a 2 level thing where the first level finds the correct shell, but that's just fuss. Just make things portable, it's not that hard and it works everywhere. When you get to the commercial world, you'd be stunned to see how long old machines last. If they are solving some problem, and they aren't broken, nobody replaces them. I'll bet you anything there are still SCO registers out there, I'll bet there are still PDP-11s out there. If it ain't broke, don't fix it. From luther at makerlisp.com Tue Jan 3 03:48:32 2023 From: luther at makerlisp.com (Luther Johnson) Date: Mon, 2 Jan 2023 10:48:32 -0700 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <20230102174304.GM25547@mcvoy.com> References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net> <20230102165120.GK25547@mcvoy.com> <20230102174304.GM25547@mcvoy.com> Message-ID: <59004a29-5119-9dd9-c248-518b8c4e7928@makerlisp.com> Arnold Schoenberg said of his 12-tone method of music composition, "in constraints I find freedom". The best thing about committing to a simple style and a small set of tools that span the problem space, is the effect it has on my program composition, imho. On 01/02/2023 10:43 AM, Larry McVoy wrote: > On Mon, Jan 02, 2023 at 10:32:50AM -0700, Adam Thornton wrote: >> But of course the "after it had had a few years to settle" is doing >> a lot of lifting there. During the Unix Wars, yeah, clearly using >> v7 sh as lowest-common-denominator was the right choice. After the >> establishment of Linux Hegemony sometime in the early 2000s, I think I >> remember that you could pretty much count on everyone at least providing >> a POSIX shell, even if it wasn't the default. (But of course by then, >> "everyone" that wasn't Linux or OS X was already down to more-or-less Sun, >> IBM, HP, and DEC/Compaq.) > I was supporting a commercial product in the early 2000's and there > were all sorts of systems then that had old shells. Yes, you could make > everything a 2 level thing where the first level finds the correct shell, > but that's just fuss. Just make things portable, it's not that hard > and it works everywhere. > > When you get to the commercial world, you'd be stunned to see how long > old machines last. If they are solving some problem, and they aren't > broken, nobody replaces them. I'll bet you anything there are still > SCO registers out there, I'll bet there are still PDP-11s out there. > > If it ain't broke, don't fix it. > From clemc at ccc.com Tue Jan 3 03:55:06 2023 From: clemc at ccc.com (Clem Cole) Date: Mon, 2 Jan 2023 12:55:06 -0500 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <20230102165120.GK25547@mcvoy.com> References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net> <20230102165120.GK25547@mcvoy.com> Message-ID: On Mon, Jan 2, 2023 at 11:51 AM Larry McVoy wrote: > I think it is less of an issue today but if I were still supporting a multi > platform product, I'd still insist on it. > Yep, and it's so easy to do. It's just a discipline. @Adam I helped create POSIX, so I get it. But Larry nailed it. It is just cheaper and easier to be disciplined and stick with Bourne for your scripts. *Teach your people the skills and you save time and money in the long run.* It's that simple. As Larry says, you never know and the problem is - when it happens, it tends to happen on a short leash. If you have been disciplined, it's a non-problem. It's really not that hard to use the V7 syntax. Everything you want/need to do is there. BTW: At Intel, a couple of years back (less than 3-5 years ago) we had a site where we needed things to work on a specific target that was, shall we say 'a bit custom' - V7 syntax was just fine for the installer - boy folks were happy a few of us had been on their case to get rid of the bashism the Millenials had tried to add (I'm not really sure POSIX.2 would have been good enough -- maybe - but Bourne was fine]. FWIW: In my start-up times, under the same rules of being disciplined, as VP of Engineering, I insisted, all C and C++ code was required to 'flex-e-lint' warning clean. I gave my folks a 3-week week slip to clean everything up. I was cursed during that time. But guess what, the outstanding bug list dropped to ⅒ of what it had been. Created quite a few true believers. And we made those 3 weeks back before we were done. Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Tue Jan 3 03:55:51 2023 From: athornton at gmail.com (Adam Thornton) Date: Mon, 2 Jan 2023 10:55:51 -0700 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <20230102174304.GM25547@mcvoy.com> References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net> <20230102165120.GK25547@mcvoy.com> <20230102174304.GM25547@mcvoy.com> Message-ID: > On Jan 2, 2023, at 10:43 AM, Larry McVoy wrote: > > When you get to the commercial world, you'd be stunned to see how long > old machines last. If they are solving some problem, and they aren't > broken, nobody replaces them. I'll bet you anything there are still > SCO registers out there, I'll bet there are still PDP-11s out there. > > If it ain't broke, don't fix it. Well, sure, but this also comes down to at what point is losing some customers because they refuse to upgrade to something from this millenium worth the cost you would incur to be able to support their environment? To be fair, stuff exactly like that was part of the bread-and-butter of Sine Nomine while I was there (for all I know, still is), and I kinda feel like that's the right answer: the places running old technology know they're doing so, and maybe they're doing so for good reasons. But finding people willing and able to keep new stuff working on those machines and OSes does get more expensive over time. So there's an aftermarket in consultancies that are willing to take over maintenance of things their vendors have abandoned. No company concerned with its long-term survival *should* do that without, in parallel, pursuing an exit strategy towards something actually-maintainable at not-exponentially-increasing cost, but of course the inability to look beyond the next quarter is a fundamental flaw of financialization-driven capitalism. And no one is saying you can't keep running your SCO cash registers forever on your own recognizance, but when they break, you get to keep both pieces, and if they break in such a way that suddenly your entire operation is being held hostage by some Russian organized crime cartel, well, you should have priced that risk appropriately. Adam From g.branden.robinson at gmail.com Tue Jan 3 04:00:20 2023 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Mon, 2 Jan 2023 12:00:20 -0600 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <59004a29-5119-9dd9-c248-518b8c4e7928@makerlisp.com> References: <20221230200246.GW5825@mcvoy.com> <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net> <20230102165120.GK25547@mcvoy.com> <20230102174304.GM25547@mcvoy.com> <59004a29-5119-9dd9-c248-518b8c4e7928@makerlisp.com> Message-ID: <20230102180020.p6gmiwhrnidfbfsc@illithid> At 2023-01-02T10:48:32-0700, Luther Johnson wrote: > Arnold Schoenberg said of his 12-tone method of music composition, "in > constraints I find freedom". The best thing about committing to a > simple style and a small set of tools that span the problem space, is > the effect it has on my program composition, imho. Schoenberg didn't have to compose for orchestras such that the Berlin Philharmonic string section tuned half of the octave meantone with the other half equal-tempered, whereas the Royal Concertgebouw had the brasses play an un-notated ascending major third gliss anytime you approached the tonic from a tritone _below_ (only). > On 01/02/2023 10:43 AM, Larry McVoy wrote: > > I was supporting a commercial product in the early 2000's and there > > were all sorts of systems then that had old shells. Yes, you could > > make everything a 2 level thing where the first level finds the > > correct shell, but that's just fuss. Just make things portable, > > it's not that hard and it works everywhere. > > > > When you get to the commercial world, you'd be stunned to see how > > long old machines last. If they are solving some problem, and they > > aren't broken, nobody replaces them. I'll bet you anything there > > are still SCO registers out there, I'll bet there are still PDP-11s > > out there. The logical consequence of this is to write in Autoconf's recommended dialect of shell, which has far too many rules to remember because every Unix vendor added exciting new bugs to their "pure" V7 shells. https://www.gnu.org/software/autoconf/manual/autoconf-2.60/html_node/Portable-Shell.html > > If it ain't broke, don't fix it. They were all broken. Badly. If your scripts worked, you got lucky at Russian Roulette. No greater claim to robustness can be made. POSIX shell conformance still proves challenging for vendors, but is an immense improvement over the status quo ante. I agree with Robert Elz though that standardizing the alias feature was nuts. I want to know who brought the crack cocaine to the conference table that day. 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 luther at makerlisp.com Tue Jan 3 04:05:10 2023 From: luther at makerlisp.com (Luther Johnson) Date: Mon, 2 Jan 2023 11:05:10 -0700 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <20230102180020.p6gmiwhrnidfbfsc@illithid> References: <20221230200246.GW5825@mcvoy.com> <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net> <20230102165120.GK25547@mcvoy.com> <20230102174304.GM25547@mcvoy.com> <59004a29-5119-9dd9-c248-518b8c4e7928@makerlisp.com> <20230102180020.p6gmiwhrnidfbfsc@illithid> Message-ID: <8d5a12bf-6eb8-bdc6-932a-ee78ff09a6b6@makerlisp.com> Point taken, if not entirely understood :) On 01/02/2023 11:00 AM, G. Branden Robinson wrote: > At 2023-01-02T10:48:32-0700, Luther Johnson wrote: >> Arnold Schoenberg said of his 12-tone method of music composition, "in >> constraints I find freedom". The best thing about committing to a >> simple style and a small set of tools that span the problem space, is >> the effect it has on my program composition, imho. > Schoenberg didn't have to compose for orchestras such that the Berlin > Philharmonic string section tuned half of the octave meantone with the > other half equal-tempered, whereas the Royal Concertgebouw had the > brasses play an un-notated ascending major third gliss anytime you > approached the tonic from a tritone _below_ (only). > >> On 01/02/2023 10:43 AM, Larry McVoy wrote: >>> I was supporting a commercial product in the early 2000's and there >>> were all sorts of systems then that had old shells. Yes, you could >>> make everything a 2 level thing where the first level finds the >>> correct shell, but that's just fuss. Just make things portable, >>> it's not that hard and it works everywhere. >>> >>> When you get to the commercial world, you'd be stunned to see how >>> long old machines last. If they are solving some problem, and they >>> aren't broken, nobody replaces them. I'll bet you anything there >>> are still SCO registers out there, I'll bet there are still PDP-11s >>> out there. > The logical consequence of this is to write in Autoconf's recommended > dialect of shell, which has far too many rules to remember because every > Unix vendor added exciting new bugs to their "pure" V7 shells. > > https://www.gnu.org/software/autoconf/manual/autoconf-2.60/html_node/Portable-Shell.html > >>> If it ain't broke, don't fix it. > They were all broken. Badly. If your scripts worked, you got lucky at > Russian Roulette. No greater claim to robustness can be made. > > POSIX shell conformance still proves challenging for vendors, but is an > immense improvement over the status quo ante. > > I agree with Robert Elz though that standardizing the alias feature was > nuts. I want to know who brought the crack cocaine to the conference > table that day. > > Regards, > Branden From lm at mcvoy.com Tue Jan 3 04:12:42 2023 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 2 Jan 2023 10:12:42 -0800 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <20230102180020.p6gmiwhrnidfbfsc@illithid> References: <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net> <20230102165120.GK25547@mcvoy.com> <20230102174304.GM25547@mcvoy.com> <59004a29-5119-9dd9-c248-518b8c4e7928@makerlisp.com> <20230102180020.p6gmiwhrnidfbfsc@illithid> Message-ID: <20230102181242.GO25547@mcvoy.com> On Mon, Jan 02, 2023 at 12:00:20PM -0600, G. Branden Robinson wrote: > > > If it ain't broke, don't fix it. > > They were all broken. Badly. If your scripts worked, you got lucky at > Russian Roulette. No greater claim to robustness can be made. > > POSIX shell conformance still proves challenging for vendors, but is an > immense improvement over the status quo ante. You are talking to a dude with 40+ years of Unix experience, supporting commercial products most of that time. I didn't get "lucky at Russian Roulette", I wrote scripts that were portable. I have 40 year old scripts that _still_ work and they work on virtually every Unix ever built. How do I know? I was a contractor for my first job, I got plopped down in front of every random unix you could imagine and each time I polished off the warts. I spent decades supporting my own products on every flavor of Unix and processors from Arm to System/360. Oh, and Windows XP and on and MacOS. My scripts worked with /bin/sh being whatever it was. It's interesting to me that other old timers, like Clem, are saying exactly the same thing as I am. Are we all wrong? From clemc at ccc.com Tue Jan 3 04:11:45 2023 From: clemc at ccc.com (Clem Cole) Date: Mon, 2 Jan 2023 13:11:45 -0500 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net> <20230102165120.GK25547@mcvoy.com> <20230102174304.GM25547@mcvoy.com> Message-ID: Maybe this should go to COFF but Adam I fear you are falling into a tap that is easy to fall into - old == unused One of my favorite stores in the computer restoration community is from 5-10 years ago and the LCM+L in Seatle was restoring their CDC-6000 that they got From Purdue. Core memory is difficult to get, so they made a card and physical module that could plug into their system that is both electrically and mechanically equivalent using modern semiconductors. A few weeks later they announced that they had the system running and had built this module. They got approached by the USAF asking if they could get a copy of the design. Seems, there was still a least one CDC-6600 running a particular critical application somewhere. This is similar to the PDP-11s and Vaxen that are supposed to be still in the hydroelectric grid [a few years ago the was an ad for an RSX and VMS programmer to go to Canada running in the Boston newspapers - I know someone that did a small amount of consulting on that one]. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Jan 3 04:16:47 2023 From: clemc at ccc.com (Clem Cole) Date: Mon, 2 Jan 2023 13:16:47 -0500 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <20230102181242.GO25547@mcvoy.com> References: <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net> <20230102165120.GK25547@mcvoy.com> <20230102174304.GM25547@mcvoy.com> <59004a29-5119-9dd9-c248-518b8c4e7928@makerlisp.com> <20230102180020.p6gmiwhrnidfbfsc@illithid> <20230102181242.GO25547@mcvoy.com> Message-ID: On Mon, Jan 2, 2023 at 1:13 PM Larry McVoy wrote: > > My scripts worked with /bin/sh being whatever it was. > > It's interesting to me that other old timers, like Clem, are saying > exactly the same thing as I am. Are we all wrong? > Exactly -- if you are disciplined -- it just works. It's not magic. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Tue Jan 3 04:18:32 2023 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 2 Jan 2023 10:18:32 -0800 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <20221230200246.GW5825@mcvoy.com> <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net> <20230102165120.GK25547@mcvoy.com> <20230102174304.GM25547@mcvoy.com> Message-ID: <20230102181832.GP25547@mcvoy.com> On Mon, Jan 02, 2023 at 10:55:51AM -0700, Adam Thornton wrote: > And no one is saying you can't keep running your SCO cash registers > forever on your own recognizance, but when they break, you get to keep > both pieces, and if they break in such a way that suddenly your entire > operation is being held hostage by some Russian organized crime cartel, > well, you should have priced that risk appropriately. Not my problem, I'm not running SCO cash registers, but the customer might be. If they have enough money to interest me, then my problem is having a product that works on their platform. You argue with me all you want, you aren't going to win. Writing stuff in a portable way is not that hard and once you have that figured out, you just do it. It's the path to more revenue. And I've fought this battle with some extremely intelligent and well meaning engineers, absolutely in the top 1% of software engineers, and they all caved. Sometimes it took me letting them off the leash long enough to make something break, but they all caved eventually. It's just more pleasant knowing that your stuff will work no matter what /bin/sh is there. All the bash-ism in the world are less valuable than "it just works". Don't get me wrong, I use bash-ism for my personal use but I wouldn't let them get anywhere near a product I needed to ship. All that said, I'm done with this topic, feel free to have the last word, I think I'm boring the smart people at this point. From crossd at gmail.com Tue Jan 3 04:36:23 2023 From: crossd at gmail.com (Dan Cross) Date: Mon, 2 Jan 2023 13:36:23 -0500 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net> <20230102165120.GK25547@mcvoy.com> <20230102174304.GM25547@mcvoy.com> Message-ID: On Mon, Jan 2, 2023 at 1:13 PM Clem Cole wrote: > Maybe this should go to COFF but Adam I fear you are falling into a tap that is easy to fall into - old == unused > > One of my favorite stores in the computer restoration community is from 5-10 years ago and the LCM+L in Seatle was restoring their CDC-6000 that they got From Purdue. Core memory is difficult to get, so they made a card and physical module that could plug into their system that is both electrically and mechanically equivalent using modern semiconductors. A few weeks later they announced that they had the system running and had built this module. They got approached by the USAF asking if they could get a copy of the design. Seems, there was still a least one CDC-6600 running a particular critical application somewhere. > > This is similar to the PDP-11s and Vaxen that are supposed to be still in the hydroelectric grid [a few years ago the was an ad for an RSX and VMS programmer to go to Canada running in the Boston newspapers - I know someone that did a small amount of consulting on that one]. One of my favorite stories along these lines is the train signalling system in Melbourne, running on a "PDP-11". I quote PDP-11 because that is now virtualized: https://www.equicon.de/images/Virtualisierung/LegacyTrainControlSystemStabilization.pdf Indeed older systems show up in surprising places. I was once on the bridge of a US Naval vessel in the late '00s and saw a SPARCstaton 20 running Solaris (with the CDE login screen). I don't recall what it was doing, but it was a tad surprising. I do worry about legacy systems in critical situations, but then, I've been in a firefight when the damned tactical computer with the satcomm link rebooted and we didn't have VHF comms with the battlespace owner. That was not particularly fun. - Dan C. From crossd at gmail.com Tue Jan 3 04:48:19 2023 From: crossd at gmail.com (Dan Cross) Date: Mon, 2 Jan 2023 13:48:19 -0500 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net> <20230102165120.GK25547@mcvoy.com> <20230102174304.GM25547@mcvoy.com> Message-ID: [Apologies for resending; I messed up and used the old Minnie address for COFF in the Cc] On Mon, Jan 2, 2023 at 1:36 PM Dan Cross wrote: > > On Mon, Jan 2, 2023 at 1:13 PM Clem Cole wrote: > > Maybe this should go to COFF but Adam I fear you are falling into a tap that is easy to fall into - old == unused > > > > One of my favorite stores in the computer restoration community is from 5-10 years ago and the LCM+L in Seatle was restoring their CDC-6000 that they got From Purdue. Core memory is difficult to get, so they made a card and physical module that could plug into their system that is both electrically and mechanically equivalent using modern semiconductors. A few weeks later they announced that they had the system running and had built this module. They got approached by the USAF asking if they could get a copy of the design. Seems, there was still a least one CDC-6600 running a particular critical application somewhere. > > > > This is similar to the PDP-11s and Vaxen that are supposed to be still in the hydroelectric grid [a few years ago the was an ad for an RSX and VMS programmer to go to Canada running in the Boston newspapers - I know someone that did a small amount of consulting on that one]. > > One of my favorite stories along these lines is the train signalling > system in Melbourne, running on a "PDP-11". I quote PDP-11 because > that is now virtualized: > https://www.equicon.de/images/Virtualisierung/LegacyTrainControlSystemStabilization.pdf > > Indeed older systems show up in surprising places. I was once on the > bridge of a US Naval vessel in the late '00s and saw a SPARCstaton 20 > running Solaris (with the CDE login screen). I don't recall what it > was doing, but it was a tad surprising. > > I do worry about legacy systems in critical situations, but then, I've > been in a firefight when the damned tactical computer with the satcomm > link rebooted and we didn't have VHF comms with the battlespace owner. > That was not particularly fun. > > - Dan C. From g.branden.robinson at gmail.com Tue Jan 3 05:21:14 2023 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Mon, 2 Jan 2023 13:21:14 -0600 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <20230102181242.GO25547@mcvoy.com> References: <20221231035931.GG5825@mcvoy.com> <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net> <20230102165120.GK25547@mcvoy.com> <20230102174304.GM25547@mcvoy.com> <59004a29-5119-9dd9-c248-518b8c4e7928@makerlisp.com> <20230102180020.p6gmiwhrnidfbfsc@illithid> <20230102181242.GO25547@mcvoy.com> Message-ID: <20230102192114.2uu7f4ap55e6xtby@illithid> At 2023-01-02T10:12:42-0800, Larry McVoy wrote: > You are talking to a dude with 40+ years of Unix experience, I'm clocking 30 this year. A babe in the woods. > supporting commercial products most of that time. I didn't get "lucky > at Russian Roulette", I wrote scripts that were portable. I have 40 > year old scripts that _still_ work and they work on virtually every > Unix ever built. How do I know? I was a contractor for my first job, > I got plopped down in front of every random unix you could imagine and > each time I polished off the warts. Yes. That's how the chapter of the GNU Autoconf manual to which I linked got written--or so I surmise, based simply on how bizarre some of the bugs are that have to be worked around. > I spent decades supporting my own products on every flavor of Unix and > processors from Arm to System/360. Oh, and Windows XP and on and > MacOS. > > My scripts worked with /bin/sh being whatever it was. > > It's interesting to me that other old timers, like Clem, are saying > exactly the same thing as I am. Are we all wrong? Over on the groff list you had the opposite advice regarding Make: pick one implementation and go with it, you said, and other implementations be damned (very loosely paraphrasing).[1] I'm not saying you're wrong--I'm saying you're inconsistent. I reckon you did what you needed to do to keep the lights on and the engineers fed. That's fine, but it's also a recipe for passivity. You don't have to tell me, but count up the number of times you flexed to accommodate a buggy implementation versus telling your client that their shell was just too crap and that they needed to either install one in which you had confidence, or you'd have to decline the contract. If their users had demanded more of their commercial Unix vendors, maybe those Unices would not be regarded as dinosaurs today. I could harp further on quality of implementation issues, but I'd probably do better to take up the lotus position on the back of a motorcycle. Preferably not while the vehicle is in motion. Regards, Branden [1] https://lists.gnu.org/archive/html/groff/2022-03/msg00084.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From rich.salz at gmail.com Tue Jan 3 05:34:22 2023 From: rich.salz at gmail.com (Rich Salz) Date: Mon, 2 Jan 2023 14:34:22 -0500 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <20230102192114.2uu7f4ap55e6xtby@illithid> References: <20221231035931.GG5825@mcvoy.com> <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net> <20230102165120.GK25547@mcvoy.com> <20230102174304.GM25547@mcvoy.com> <59004a29-5119-9dd9-c248-518b8c4e7928@makerlisp.com> <20230102180020.p6gmiwhrnidfbfsc@illithid> <20230102181242.GO25547@mcvoy.com> <20230102192114.2uu7f4ap55e6xtby@illithid> Message-ID: The difference is that "make" need only run on your build systems. Installation scripts need to run on customer systems. -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Tue Jan 3 05:50:47 2023 From: imp at bsdimp.com (Warner Losh) Date: Mon, 2 Jan 2023 12:50:47 -0700 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net> <20230102165120.GK25547@mcvoy.com> <20230102174304.GM25547@mcvoy.com> <59004a29-5119-9dd9-c248-518b8c4e7928@makerlisp.com> <20230102180020.p6gmiwhrnidfbfsc@illithid> <20230102181242.GO25547@mcvoy.com> Message-ID: On Mon, Jan 2, 2023, 11:18 AM Clem Cole wrote: > > > On Mon, Jan 2, 2023 at 1:13 PM Larry McVoy wrote: > >> >> My scripts worked with /bin/sh being whatever it was. >> >> It's interesting to me that other old timers, like Clem, are saying >> exactly the same thing as I am. Are we all wrong? >> > Exactly -- if you are disciplined -- it just works. It's not magic. > I've only got 30 years experience in writing portable shell scripts... But I have a slightly different take. There is an element of luck involved. There are a number of constructs that are valid in v7 shell that aren't completely portable due to bugs in vendor shells. The luck part comes in either you know what to avoid because you got unlucky and got burned in the past. Or you got lucky and never thought to write something like that so it just works. With experience, you know what works... I notice the old timers hedged a little bit by saying things like "virtually all" so maybe they had a bit of bad luck now and again... Also, the really aweful systems are rare enough today that most folks on this list have had the good luck not to need to run on them... :) You can get super close though, but I'll bet there's some scripts that work only because they didn't run on, say, Eunice... But luck favors the prepared... and making the effort to try to be portable will help when you have to run on dash, or one of the BSD shells that might not have $<(cmd) or some other useful but not universal feature... Warner > ᐧ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph at josephholsten.com Tue Jan 3 06:03:03 2023 From: joseph at josephholsten.com (Joseph Holsten) Date: Mon, 02 Jan 2023 12:03:03 -0800 Subject: [TUHS] Command Line Editing in the Terminal Driver (Was: A few comments on porting the Bourne shell) In-Reply-To: <8ca17d52-a25a-dbbf-e1f0-d743b8884cfa@in-ulm.de> References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <8ca17d52-a25a-dbbf-e1f0-d743b8884cfa@in-ulm.de> Message-ID: On Fri, Dec 30, 2022, at 12:42, Sven Mascheck wrote: > and in "ksh - An Extensible High Level Language" David Korn writes: > > * "Originally the idea of adding command line editing to ksh was rejected in the hope that line editing would move into the terminal driver." [2] > [2] https://www.in-ulm.de/~mascheck/bourne/korn.html This phrase has haunted me for years. It’s so clearly the “correct” separation of concerns, until you actually attempt implementing it. And Bourne’s irregular grammar certainly doesn’t help here. I’d prefer to move beyond readline, ideally something like text objects per vim/zsh/treesitter. But having one parser in the interpreter and another in the line editor becomes quite exciting if you want a true bourne or even posix sh. But the thing that brought be back to playing against this quote again this year was starting to research the QED lineage and discovering helix & kakoune. Honestly, they feels like the most coherent advancements in QED-style editors since sam & acme. (Yes, I’m irrationally excluding vim text-objects, mostly because no one removed editor features that t-o made redundant. It’s as if ed had twice as many commands, one for regexp matches and one for pre-ken-QEDist exact matches.) Anyway, the only time I’ve really seen “line editing […] move into the terminal driver” sound possible was acme’s win. For those who haven’t had the pleasure, rsc describes it at 15:25 in https://research.swtch.com/acme. “I worked for many years in a shell without history or command line editing, and I never missed it because Acme is providing this for me.” It’s hard to convey how surprisingly pleasant sh or rc can be within acme win to someone who has only used them within a mere terminal-emulator-emulator. Especially since a greenfield terminal app has more code emulating old xterm behaviors than physical vt100 behaviours. This is especially exhausting when you try to use something like NeoVim’s :term expecting it to just work and discover that buffer-line-wrapping on window-resize hasn’t been implemented. Anyone seen any other “terminal drivers” that provide a pleasant alternative to line editing? -- ~j -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Tue Jan 3 06:05:37 2023 From: athornton at gmail.com (Adam Thornton) Date: Mon, 2 Jan 2023 13:05:37 -0700 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net> <20230102165120.GK25547@mcvoy.com> <20230102174304.GM25547@mcvoy.com> <59004a29-5119-9dd9-c248-518b8c4e7928@makerlisp.com> <20230102180020.p6gmiwhrnidfbfsc@illithid> <20230102181242.GO25547@mcvoy.com> Message-ID: > On Jan 2, 2023, at 12:50 PM, Warner Losh wrote: > > > You can get super close though, but I'll bet there's some scripts that work only because they didn't run on, say, Eunice... "Congratulations!" > > But luck favors the prepared... and making the effort to try to be portable will help when you have to run on dash, or one of the BSD shells that might not have $<(cmd) or some other useful but not universal feature... Yeah and I think we're basically agreeing here. The problem isn't *really* whether you use some-odd-number-of-backslashes-and-a-backtick versus dollar-open-paren, the problem is people who put #!/bin/sh at the top of the script when the contents only run under bash. And there's a lot of that, because just as all the world was VAX once upon a time, all the world is assumed to be an x86_64 Linux where sh is bash. At least the move towards containerization has largely defeated that assumption now, although in some sense it's also just swept the problem under someone else's rug. Adam From lm at mcvoy.com Tue Jan 3 06:12:48 2023 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 2 Jan 2023 12:12:48 -0800 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net> <20230102165120.GK25547@mcvoy.com> <20230102174304.GM25547@mcvoy.com> <59004a29-5119-9dd9-c248-518b8c4e7928@makerlisp.com> <20230102180020.p6gmiwhrnidfbfsc@illithid> <20230102181242.GO25547@mcvoy.com> <20230102192114.2uu7f4ap55e6xtby@illithid> Message-ID: <20230102201248.GS25547@mcvoy.com> On Mon, Jan 02, 2023 at 02:34:22PM -0500, Rich Salz wrote: > The difference is that "make" need only run on your build systems. > Installation scripts need to run on customer systems. Exactly. I let my team, against my judgement, use GNU make for our builds. That was in house, the scripts are customer run. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From g.branden.robinson at gmail.com Tue Jan 3 06:24:22 2023 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Mon, 2 Jan 2023 14:24:22 -0600 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net> <20230102165120.GK25547@mcvoy.com> <20230102174304.GM25547@mcvoy.com> <59004a29-5119-9dd9-c248-518b8c4e7928@makerlisp.com> <20230102180020.p6gmiwhrnidfbfsc@illithid> <20230102181242.GO25547@mcvoy.com> <20230102192114.2uu7f4ap55e6xtby@illithid> Message-ID: <20230102202422.qychfa24tnjuok4p@illithid> At 2023-01-02T14:34:22-0500, Rich Salz wrote: > The difference is that "make" need only run on your build systems. > Installation scripts need to run on customer systems. Surprisingly (not really), I don't agree with this, either. make, like tsort, is a generally useful tool that people misconceive as being limited in scope to traditional compile-and-link software development. A dab of imagination and familiarity with existing tooling can save one much wheel reinvention. That said I don't doubt that some vendors happily took these tools in particular (along with the compiler, of course) and locked them up within a "pro" or "development" tier. But all that teaches us is something we should have already known: free software is better than proprietary software. Why _shouldn't_ customer systems have make(1)? 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 lars at nocrew.org Tue Jan 3 06:33:15 2023 From: lars at nocrew.org (Lars Brinkhoff) Date: Mon, 02 Jan 2023 20:33:15 +0000 Subject: [TUHS] Command Line Editing in the Terminal Driver In-Reply-To: (Joseph Holsten's message of "Mon, 02 Jan 2023 12:03:03 -0800") References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <8ca17d52-a25a-dbbf-e1f0-d743b8884cfa@in-ulm.de> Message-ID: <7w5ydohe2c.fsf@junk.nocrew.org> Joseph Holsten wrote: > Anyone seen any other “terminal drivers” that provide a pleasant > alternative to line editing? The Stanford AI lab PDP-10 operating system had line editing built in, and the E editor integrated with this. From lm at mcvoy.com Tue Jan 3 06:36:46 2023 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 2 Jan 2023 12:36:46 -0800 Subject: [TUHS] Interview question Message-ID: <20230102203646.GT25547@mcvoy.com> The /bin/sh stuff made me think of an interview question I had for engineers, that a surprisingly few could pass: "Tell me about something you wrote that was entirely you, the docs, the tests, the source, the installer, everything. It doesn't have to be a big thing, but it has to have been successfully used by at least 10 people who had no contact with you (other than to say thanks)." Most people fail this. I think the people who pass might look positively on the v7 sh stuff. But who knows? From arnold at skeeve.com Tue Jan 3 06:38:30 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 02 Jan 2023 13:38:30 -0700 Subject: [TUHS] Interview question In-Reply-To: <20230102203646.GT25547@mcvoy.com> References: <20230102203646.GT25547@mcvoy.com> Message-ID: <202301022038.302KcUrB026704@freefriends.org> Larry McVoy wrote: > The /bin/sh stuff made me think of an interview question I had for engineers, > that a surprisingly few could pass: > > "Tell me about something you wrote that was entirely you, the docs, the > tests, the source, the installer, everything. It doesn't have to be a > big thing, but it has to have been successfully used by at least 10 > people who had no contact with you (other than to say thanks)." > > Most people fail this. I think the people who pass might look > positively on the v7 sh stuff. But who knows? How many people who failed this question did you hire anyway? From lm at mcvoy.com Tue Jan 3 06:41:03 2023 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 2 Jan 2023 12:41:03 -0800 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <20230102202422.qychfa24tnjuok4p@illithid> References: <20230102165120.GK25547@mcvoy.com> <20230102174304.GM25547@mcvoy.com> <59004a29-5119-9dd9-c248-518b8c4e7928@makerlisp.com> <20230102180020.p6gmiwhrnidfbfsc@illithid> <20230102181242.GO25547@mcvoy.com> <20230102192114.2uu7f4ap55e6xtby@illithid> <20230102202422.qychfa24tnjuok4p@illithid> Message-ID: <20230102204103.GU25547@mcvoy.com> On Mon, Jan 02, 2023 at 02:24:22PM -0600, G. Branden Robinson wrote: > At 2023-01-02T14:34:22-0500, Rich Salz wrote: > > The difference is that "make" need only run on your build systems. > > Installation scripts need to run on customer systems. > > Surprisingly (not really), I don't agree with this, either. > > make, like tsort, is a generally useful tool that people misconceive as > being limited in scope to traditional compile-and-link software > development. > > A dab of imagination and familiarity with existing tooling can save one > much wheel reinvention. If we wanted to use Makefiles in our customer run product, we would have shipped it. From lm at mcvoy.com Tue Jan 3 06:51:50 2023 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 2 Jan 2023 12:51:50 -0800 Subject: [TUHS] Interview question In-Reply-To: <202301022038.302KcUrB026704@freefriends.org> References: <20230102203646.GT25547@mcvoy.com> <202301022038.302KcUrB026704@freefriends.org> Message-ID: <20230102205150.GW25547@mcvoy.com> On Mon, Jan 02, 2023 at 01:38:30PM -0700, arnold at skeeve.com wrote: > Larry McVoy wrote: > > > The /bin/sh stuff made me think of an interview question I had for engineers, > > that a surprisingly few could pass: > > > > "Tell me about something you wrote that was entirely you, the docs, the > > tests, the source, the installer, everything. It doesn't have to be a > > big thing, but it has to have been successfully used by at least 10 > > people who had no contact with you (other than to say thanks)." > > > > Most people fail this. I think the people who pass might look > > positively on the v7 sh stuff. But who knows? > > How many people who failed this question did you hire anyway? None that I kept. Miss-hired some who didn't pass and let them go eventually. Whether that question actually is that good of an indicator in general, I couldn't say. It was a pretty solid one for what we did. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From crossd at gmail.com Tue Jan 3 07:00:58 2023 From: crossd at gmail.com (Dan Cross) Date: Mon, 2 Jan 2023 16:00:58 -0500 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <20230102204103.GU25547@mcvoy.com> References: <20230102165120.GK25547@mcvoy.com> <20230102174304.GM25547@mcvoy.com> <59004a29-5119-9dd9-c248-518b8c4e7928@makerlisp.com> <20230102180020.p6gmiwhrnidfbfsc@illithid> <20230102181242.GO25547@mcvoy.com> <20230102192114.2uu7f4ap55e6xtby@illithid> <20230102202422.qychfa24tnjuok4p@illithid> <20230102204103.GU25547@mcvoy.com> Message-ID: On Mon, Jan 2, 2023 at 3:41 PM Larry McVoy wrote: > On Mon, Jan 02, 2023 at 02:24:22PM -0600, G. Branden Robinson wrote: > > At 2023-01-02T14:34:22-0500, Rich Salz wrote: > > > The difference is that "make" need only run on your build systems. > > > Installation scripts need to run on customer systems. > > > > Surprisingly (not really), I don't agree with this, either. > > > > make, like tsort, is a generally useful tool that people misconceive as > > being limited in scope to traditional compile-and-link software > > development. > > > > A dab of imagination and familiarity with existing tooling can save one > > much wheel reinvention. > > If we wanted to use Makefiles in our customer run product, we would have > shipped it. Couldn't you also ship a shell? That kinda seems like the simplest solution. I used to be pretty dogmatic about adherence to 7th Ed tools and syntax, but I think I'm like the frog in the pot where the temperature is slowly rising: I suspect I've let things creep in that are not portable to a universal intersection set, simply because I haven't noticed, because I'm no longer trying to run things on very old systems regularly. Will that script I wrote last week run on Ultrix? Beats me; I haven't powered up the DECstation in 15 years. But considering the issue raises a related question: practically speaking, what do you define as a least common denominator? For example, is `nawk` allowed, or just the traditional 7th Ed awk? How about extended regular expressions? GNU coreutils `egrep` now spits out a warning saying, "egrep is obsolescent; using grep -E" (I cannot adequately express how irritating I find this). Does `tr` need the square brackets? Etc. The shell by itself is just part of the equation, and as a programming environment, /bin/sh is not all that interesting unless complemented by a bunch of utilities, the portability of which seems less guaranteed than it once was. I actually think the shell is less of an issue; C is a bigger one for me. About a year ago, I set up some emulated systems on my local ham radio network (connected to AX.25 also!). Among them were Multics and TOPS-20, but also a VAX running 4.3BSD and 7th Ed on a PDP-11. But getting anything modern to build on either is a serious pain; speaking of shells, I was able to find what is (I think) the last version of tcsh to support 4.3 and get that to build. Then again, having 7th Ed around forces me to think about shell script portability again, so...there's that. :-) - Dan C. From clemc at ccc.com Tue Jan 3 07:06:43 2023 From: clemc at ccc.com (Clem Cole) Date: Mon, 2 Jan 2023 16:06:43 -0500 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <20230102165120.GK25547@mcvoy.com> <20230102174304.GM25547@mcvoy.com> <59004a29-5119-9dd9-c248-518b8c4e7928@makerlisp.com> <20230102180020.p6gmiwhrnidfbfsc@illithid> <20230102181242.GO25547@mcvoy.com> <20230102192114.2uu7f4ap55e6xtby@illithid> <20230102202422.qychfa24tnjuok4p@illithid> <20230102204103.GU25547@mcvoy.com> Message-ID: On Mon, Jan 2, 2023 at 4:03 PM Dan Cross wrote: > Couldn't you also ship a shell? That kinda seems like the simplest > solution. > Sure the problem is -- where do you stop? The result is the fork/mess called Gnu. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph at josephholsten.com Tue Jan 3 07:08:11 2023 From: joseph at josephholsten.com (Joseph Holsten) Date: Mon, 02 Jan 2023 13:08:11 -0800 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <20230102165120.GK25547@mcvoy.com> <20230102174304.GM25547@mcvoy.com> <59004a29-5119-9dd9-c248-518b8c4e7928@makerlisp.com> <20230102180020.p6gmiwhrnidfbfsc@illithid> <20230102181242.GO25547@mcvoy.com> <20230102192114.2uu7f4ap55e6xtby@illithid> <20230102202422.qychfa24tnjuok4p@illithid> <20230102204103.GU25547@mcvoy.com> Message-ID: On Mon, Jan 2, 2023, at 13:00, Dan Cross wrote: > On Mon, Jan 2, 2023 at 3:41 PM Larry McVoy wrote: >> >> If we wanted to use Makefiles in our customer run product, we would have >> shipped it. > > Couldn't you also ship a shell? That kinda seems like the simplest solution. Then you have to ship documentation on how to properly install the shell. Also, add guardrails to make sure that the correct shell is being loaded instead of someone getting ambitious with their exec path. cf every products trying to ship its own python, ruby, etc instead of accepting defeat and shipping a statically build tool in a docker container in an OVA virtual machine image. Obviously, that’s what should have been done with Bourne shell in the first place. From robpike at gmail.com Tue Jan 3 07:08:45 2023 From: robpike at gmail.com (Rob Pike) Date: Tue, 3 Jan 2023 08:08:45 +1100 Subject: [TUHS] Command Line Editing in the Terminal Driver (Was: A few comments on porting the Bourne shell) In-Reply-To: References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <8ca17d52-a25a-dbbf-e1f0-d743b8884cfa@in-ulm.de> Message-ID: It just seems much more natural to me to have line editing provided at some fundamental level. Putting it in the shell or some library means some tools get it but some don't. Why should sh have editing but mail not? But then there's glob. Do it once, do it well, and do it for everything, where "it" is a wildcard that refers to every important detail. -rob On Tue, Jan 3, 2023 at 7:03 AM Joseph Holsten wrote: > On Fri, Dec 30, 2022, at 12:42, Sven Mascheck wrote: > > and in "ksh - An Extensible High Level Language" David Korn writes: > > - "Originally the idea of adding command line editing to ksh was > rejected in the hope that line editing would move into the terminal > driver." [2] > > [2] https://www.in-ulm.de/~mascheck/bourne/korn.html > > > This phrase has haunted me for years. It’s so clearly the “correct” > separation of concerns, until you actually attempt implementing it. And > Bourne’s irregular grammar certainly doesn’t help here. I’d prefer to move > beyond readline, ideally something like text objects per > vim/zsh/treesitter. But having one parser in the interpreter and another in > the line editor becomes quite exciting if you want a true bourne or even > posix sh. > > But the thing that brought be back to playing against this quote again > this year was starting to research the QED lineage and discovering helix & > kakoune. Honestly, they feels like the most coherent advancements in > QED-style editors since sam & acme. (Yes, I’m irrationally excluding vim > text-objects, mostly because no one removed editor features that t-o made > redundant. It’s as if ed had twice as many commands, one for regexp matches > and one for pre-ken-QEDist exact matches.) > > Anyway, the only time I’ve really seen “line editing […] move into the > terminal driver” sound possible was acme’s win. For those who haven’t had > the pleasure, rsc describes it at 15:25 in https://research.swtch.com/acme. > “I worked for many years in a shell without history or command line > editing, and I never missed it because Acme is providing this for me.” > > It’s hard to convey how surprisingly pleasant sh or rc can be within acme > win to someone who has only used them within a mere > terminal-emulator-emulator. Especially since a greenfield terminal app > has more code emulating old xterm behaviors than physical vt100 behaviours. > This is especially exhausting when you try to use something like NeoVim’s > :term expecting it to just work and discover that buffer-line-wrapping on > window-resize hasn’t been implemented. > > Anyone seen any other “terminal drivers” that provide a pleasant > alternative to line editing? > -- > ~j > -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Tue Jan 3 07:15:35 2023 From: athornton at gmail.com (Adam Thornton) Date: Mon, 2 Jan 2023 14:15:35 -0700 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <20230102165120.GK25547@mcvoy.com> <20230102174304.GM25547@mcvoy.com> <59004a29-5119-9dd9-c248-518b8c4e7928@makerlisp.com> <20230102180020.p6gmiwhrnidfbfsc@illithid> <20230102181242.GO25547@mcvoy.com> <20230102192114.2uu7f4ap55e6xtby@illithid> <20230102202422.qychfa24tnjuok4p@illithid> <20230102204103.GU25547@mcvoy.com> Message-ID: <67D8CB20-4D19-43D0-BDA5-6B2476A706AF@gmail.com> > On Jan 2, 2023, at 2:08 PM, Joseph Holsten wrote: > > On Mon, Jan 2, 2023, at 13:00, Dan Cross wrote: >> On Mon, Jan 2, 2023 at 3:41 PM Larry McVoy wrote: >>> >>> If we wanted to use Makefiles in our customer run product, we would have >>> shipped it. >> >> Couldn't you also ship a shell? That kinda seems like the simplest solution. > > Then you have to ship documentation on how to properly install the shell. Also, add guardrails to make sure that the correct shell is being loaded instead of someone getting ambitious with their exec path. > > cf every products trying to ship its own python, ruby, etc instead of accepting defeat and shipping a statically build tool in a docker container in an OVA virtual machine image. > > Obviously, that’s what should have been done with Bourne shell in the first place. You came very close to owing me a new keyboard there. Adam From crossd at gmail.com Tue Jan 3 07:19:59 2023 From: crossd at gmail.com (Dan Cross) Date: Mon, 2 Jan 2023 16:19:59 -0500 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <20230102165120.GK25547@mcvoy.com> <20230102174304.GM25547@mcvoy.com> <59004a29-5119-9dd9-c248-518b8c4e7928@makerlisp.com> <20230102180020.p6gmiwhrnidfbfsc@illithid> <20230102181242.GO25547@mcvoy.com> <20230102192114.2uu7f4ap55e6xtby@illithid> <20230102202422.qychfa24tnjuok4p@illithid> <20230102204103.GU25547@mcvoy.com> Message-ID: On Mon, Jan 2, 2023 at 4:07 PM Clem Cole wrote: > On Mon, Jan 2, 2023 at 4:03 PM Dan Cross wrote: >> Couldn't you also ship a shell? That kinda seems like the simplest solution. > > Sure the problem is -- where do you stop? Good question. But this sort of suggests that maybe it's not the shell that's really the problem, but the entire milieu of all the tools that we use when we write "shell scripts." > The result is the fork/mess called Gnu. BUGS: Yes. - Dan C. From usotsuki at buric.co Tue Jan 3 08:43:55 2023 From: usotsuki at buric.co (Steve Nickolas) Date: Mon, 2 Jan 2023 17:43:55 -0500 (EST) Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <20230102165120.GK25547@mcvoy.com> <20230102174304.GM25547@mcvoy.com> <59004a29-5119-9dd9-c248-518b8c4e7928@makerlisp.com> <20230102180020.p6gmiwhrnidfbfsc@illithid> <20230102181242.GO25547@mcvoy.com> <20230102192114.2uu7f4ap55e6xtby@illithid> <20230102202422.qychfa24tnjuok4p@illithid> <20230102204103.GU25547@mcvoy.com> Message-ID: On Mon, 2 Jan 2023, Clem Cole wrote: > On Mon, Jan 2, 2023 at 4:03 PM Dan Cross wrote: > >> Couldn't you also ship a shell? That kinda seems like the simplest >> solution. >> > Sure the problem is -- where do you stop? > > The result is the fork/mess called Gnu. GNU is Embrace, Extend and Exterminate applied to Unix. -uso. From tuhs at tuhs.org Tue Jan 3 08:54:22 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 02 Jan 2023 22:54:22 +0000 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <20230102181242.GO25547@mcvoy.com> <20230102192114.2uu7f4ap55e6xtby@illithid> <20230102202422.qychfa24tnjuok4p@illithid> <20230102204103.GU25547@mcvoy.com> Message-ID: A shell is only as powerful as the constructs it can interact with. One can do logic all day and night but if that logic isn't being put to work, it's just an exercise in vanity. I think that's a good point that scripting problems may be a symptom of the nature of the tools being used in them. So the day job is pretty much an all Microsoft shop, from .NET code to IIS servers, not a '$' prompt in sight usually. However, being a scientific operation, we have quite a diverse crew of UNIX machines floating around out there resigned to their fates sitting in the corner running the oldest equipment at their respective labs. Any time I've had to interact with any of these I've been grateful for not taking various post-Bourne shell quirks for granted. Not that these interactions are frequent, but I find myself tapped often being "that UNIX guy" on the team. A couple examples come to mind. One facility is running two pieces of equipment the software for which runs on Digital UNIX circa mid 90s. The data transfer mechanism was some FTP thing their previous technical director had cooked up and one morning we had found it went down. The resident IT guy there knew the basics of how to get in there, but hadn't really put the process down anywhere. Luckily (security may think otherwise...) I was able to connect over rsh with the password he provided and was able to modify the script for that exporter to self-heal. I don't know what shell it was running beyond it spitting a '$' out at me, but luckily didn't have to know. The other is a lab using a data analysis system for, among others, HP-UX. I don't recall the age of the version they were running on, but the system is called Target and was eventually forked in a few directions when the original company closed up shop, our group inheriting one of the forks. It's one of those things I hope I can archive publicly someday, but not there yet. In any case, the technicians all had Windows PCs with an X11 server setup for accessing the HP-UX machine, and it was running CDE if that helps date it (unless that's still default). That system is in archive now as we've replaced it with the current version of our fork which is now .NET. I was surprised they didn't have more UNIX going on, but they had managed to get a lot of their older equipment to work with some sort of Windows based solution one way or another. Life finds a way... I'm not sure where it stands as far as the sea of shells these days, but one I've opted towards in system builds the past few years is dash. It's pretty small and seems to hit all the marks as far as basic Bourne-ish behavior and POSIX stuff. When I'm tinkering on a board and just need to toss a shell on top of a kernel, I go for dash. - Matt G. ------- Original Message ------- On Monday, January 2nd, 2023 at 1:19 PM, Dan Cross wrote: > On Mon, Jan 2, 2023 at 4:07 PM Clem Cole clemc at ccc.com wrote: > > > On Mon, Jan 2, 2023 at 4:03 PM Dan Cross crossd at gmail.com wrote: > > > > > Couldn't you also ship a shell? That kinda seems like the simplest solution. > > > > Sure the problem is -- where do you stop? > > > Good question. But this sort of suggests that maybe it's not the shell > that's really the problem, but the entire milieu of all the tools that > we use when we write "shell scripts." > > > The result is the fork/mess called Gnu. > > > BUGS: Yes. > > - Dan C. From jon at fourwinds.com Tue Jan 3 09:58:44 2023 From: jon at fourwinds.com (Jon Steinhart) Date: Mon, 02 Jan 2023 15:58:44 -0800 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <20230102181242.GO25547@mcvoy.com> <20230102192114.2uu7f4ap55e6xtby@illithid> <20230102202422.qychfa24tnjuok4p@illithid> <20230102204103.GU25547@mcvoy.com> Message-ID: <202301022358.302NwiKJ492165@darkstar.fourwinds.com> segaloco via TUHS writes: > I think that's a good point that scripting problems may be > a symptom of the nature of the tools being used in them. I think that you're hinting at something different. To the best of my recollection, scripting languages were originally intended and used for the automation of repetitive personal tasks; making it easier for users who found themselves typing the same stuff over and over again. Somewhere along the line people forgot how to use a compiler and began writing large systems in a variety of roughly equivalent but incompatible interpreted languages. Can one even boot linux without having several different incompatible versions of Python installed today? So I don't think that it's the nature of the tools; I think that it's people choosing the wrong tools for the problems that they're trying to solve. Jon From ori at heliconbooks.com Tue Jan 3 14:44:23 2023 From: ori at heliconbooks.com (Ori Idan) Date: Tue, 3 Jan 2023 06:44:23 +0200 Subject: [TUHS] Interview question In-Reply-To: <20230102203646.GT25547@mcvoy.com> References: <20230102203646.GT25547@mcvoy.com> Message-ID: Nice question, but I don't see the connection. -- Ori Idan CEO Helicon Books http://www.heliconbooks.com On Mon, Jan 2, 2023 at 10:37 PM Larry McVoy wrote: > The /bin/sh stuff made me think of an interview question I had for > engineers, > that a surprisingly few could pass: > > "Tell me about something you wrote that was entirely you, the docs, the > tests, the source, the installer, everything. It doesn't have to be a > big thing, but it has to have been successfully used by at least 10 > people who had no contact with you (other than to say thanks)." > > Most people fail this. I think the people who pass might look > positively on the v7 sh stuff. But who knows? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdm at cfcl.com Tue Jan 3 15:15:23 2023 From: rdm at cfcl.com (Rich Morin) Date: Mon, 2 Jan 2023 21:15:23 -0800 Subject: [TUHS] Interview question In-Reply-To: <20230102203646.GT25547@mcvoy.com> References: <20230102203646.GT25547@mcvoy.com> Message-ID: Sadly, I can't remember whose USENIX talk it was, but I recall a software maturity scale that went something like this: 1 - it works in your office 2 - it works in an office down the hall 3 - it works for someone you've never met 4 - you don't have to explain why you use it 5 - you have to explain why you don't use it -r > On Jan 2, 2023, at 12:36, Larry McVoy wrote: > > The /bin/sh stuff made me think of an interview question I had for engineers, > that a surprisingly few could pass: > > "Tell me about something you wrote that was entirely you, the docs, the > tests, the source, the installer, everything. It doesn't have to be a > big thing, but it has to have been successfully used by at least 10 > people who had no contact with you (other than to say thanks)." > > Most people fail this. I think the people who pass might look > positively on the v7 sh stuff. But who knows? From ajayshah at mayin.org Tue Jan 3 15:32:06 2023 From: ajayshah at mayin.org (Ajay Shah) Date: Tue, 3 Jan 2023 11:02:06 +0530 Subject: [TUHS] Interview question In-Reply-To: References: <20230102203646.GT25547@mcvoy.com> Message-ID: On Tue, 3 Jan 2023 at 10:46, Rich Morin wrote: > Sadly, I can't remember whose USENIX talk it was, but I recall a software > maturity scale that went something like this: > 1 - it works in your office > 2 - it works in an office down the hall > 3 - it works for someone you've never met > 4 - you don't have to explain why you use it > 5 - you have to explain why you don't use it > Perhaps we can introduce a #6 here: A successful software tool is one that was used to do something undreamed of by it's author. -- S. C. Johnson -- Ajay Shah ajayshah at mayin.org http://www.mayin.org/ajayshah -------------- next part -------------- An HTML attachment was scrubbed... URL: From chet.ramey at case.edu Wed Jan 4 01:06:55 2023 From: chet.ramey at case.edu (Chet Ramey) Date: Tue, 3 Jan 2023 10:06:55 -0500 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <202301011044.301Aib7T009476@freefriends.org> References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <202301011044.301Aib7T009476@freefriends.org> Message-ID: On 1/1/23 5:44 AM, arnold at skeeve.com wrote: > Chet Ramey wrote: > >> On 12/30/22 1:25 PM, Paul Ruizendaal wrote: >>> >>> London and Reiser report about porting the shell that “it required by >>> far the largest conversion effort of any supposedly portable program, >>> for the simple reason that it is not portable.” By the time of SysIII >>> this is greatly improved, but also in porting the SysIII user land it >>> was the most complex of the set so far. >> >> Have you read >> >> http://www.collyer.net/who/geoff/sh.tour.pdf >> >> and looked at http://www.collyer.net/who/geoff/v7sh.tar ? >> >> In the limited literature on Bourne Shell porting, this is authoritative. >> >> Arnold Robbins built on that work and ported the v8-v10 shells to modern >> Linux versions. (I am sorry, I do not have a link right now.) > > Sorry to say, it wasn't me. Geoff Collyer made the v9 sh portable > and it's available from his web site. My bad, credit to Geoff. -- ``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 douglas.mcilroy at dartmouth.edu Wed Jan 4 01:08:34 2023 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Tue, 3 Jan 2023 10:08:34 -0500 Subject: [TUHS] A few comments on porting the Bourne shell Message-ID: > segaloco via TUHS writes: >> I think that's a good point that scripting problems may be >> a symptom of the nature of the tools being used in them. > I think that you're hinting at something different. > To the best of my recollection, scripting languages were originally > intended and used for the automation of repetitive personal tasks; > making it easier for users who found themselves typing the same > stuff over and over again. Indeed! > Somewhere along the line people forgot > how to use a compiler and began writing large systems in a variety > of roughly equivalent but incompatible interpreted languages. Can > one even boot linux without having several different incompatible > versions of Python installed today? So I don't think that it's the > nature of the tools; I think that it's people choosing the wrong > tools for the problems that they're trying to solve. > Jon The forgotten compilers were typically used to supply glue to paste major tools together. The nature of that glue---often simple data reformatting--inspired tools like sed and awk. Each use of a tool became a process that saved many minutes of work that would in a scriptless world be guided by hand, boringly and unreliably. Yet glue processes typically did only microseconds of "real" work. In the name of efficiency, the operations began to be incorporated directly into the shell. The first inklings of this can be seen in "echo" and various forms of variable-substitution making their way into the v7 shell. The phenomenon proliferated into putting what were typically canned sed one-liners (but not sed itself) into the shell. Lots of specializations crowded out universality. A side effect was an explosion of knowledge required to write or understand code. Such is the tragedy of "forgetting compilers". Doug From alx.manpages at gmail.com Wed Jan 4 01:57:21 2023 From: alx.manpages at gmail.com (Alejandro Colomar) Date: Tue, 3 Jan 2023 16:57:21 +0100 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: Message-ID: <3a891e61-a8b1-cfe4-95ab-c60e6ac6eb42@gmail.com> Hi Doug! On 1/3/23 16:08, Douglas McIlroy wrote: >> segaloco via TUHS writes: >>> I think that's a good point that scripting problems may be >>> a symptom of the nature of the tools being used in them. > >> I think that you're hinting at something different. > >> To the best of my recollection, scripting languages were originally >> intended and used for the automation of repetitive personal tasks; >> making it easier for users who found themselves typing the same >> stuff over and over again. > > Indeed! Well, as time goes by, I'm also writing less and less programs. But only because I find that I can pipe programs together to do what I want without having to write a new one. I guess that's a fair reason to not compile :) > >> Somewhere along the line people forgot >> how to use a compiler and began writing large systems in a variety >> of roughly equivalent but incompatible interpreted languages. Can >> one even boot linux without having several different incompatible >> versions of Python installed today? So I don't think that it's the >> nature of the tools; I think that it's people choosing the wrong >> tools for the problems that they're trying to solve. > >> Jon > > The forgotten compilers were typically used to supply glue > to paste major tools together. The nature of that glue---often > simple data reformatting--inspired tools like sed and awk. > Each use of a tool became a process that saved many minutes > of work that would in a scriptless world be guided by hand, > boringly and unreliably. > > Yet glue processes typically did only microseconds of > "real" work. In the name of efficiency, the operations began > to be incorporated directly into the shell. The first > inklings of this can be seen in "echo" and various forms > of variable-substitution making their way into the v7 > shell. The phenomenon proliferated into putting what were > typically canned sed one-liners (but not sed itself) into > the shell. > > Lots of specializations crowded out universality. A side > effect was an explosion of knowledge required to write > or understand code. Such is the tragedy of "forgetting > compilers". And a funny thing: Today in the era of multi-core computers, not only the shell-only scripts are unreadable, but they also are slower than scripts with pipes and little-to-no shell features. I tend to write scripts with only pipes. No shell features. And I also avoid programs with many options (find(1)) when I can split it with xargs(1) and others. I remember some script I wrote for maintenance of the Linux man-pages, and I received a suggestion that I could "simplify" the script considerably and make it "faster" by reducing the number of pipes using some features of find(1) or sh(1) (I don't remember well). Well, I tested, and my long list of piped programs outperformed by a fair amount the suggested alternative. I didn't care enough to find out the reason, but I thought it could be because with the pipeline, I could run each small process in a different core, so they could work all at the same time. With a single program invocation, you're bottle-necked by that program, which is limited to a single core (normally). Cheers, Alex > > Doug From chet.ramey at case.edu Wed Jan 4 02:32:45 2023 From: chet.ramey at case.edu (Chet Ramey) Date: Tue, 3 Jan 2023 11:32:45 -0500 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <8ca17d52-a25a-dbbf-e1f0-d743b8884cfa@in-ulm.de> <202212302048.2BUKmBBs253245@darkstar.fourwinds.com> <20221231114037.7D30921FB4@orac.inputplus.co.uk> <202212311849.2BVIntjP356028@darkstar.fourwinds.com> Message-ID: <94acc752-5f58-9d02-0979-f5a97b2af2ef@case.edu> On 12/31/22 2:24 PM, Clem Cole wrote: > I seem to remember that someone got wedged into System V > that was awful and unusable. > > IIRC it was in SVR2 that a version of a job control system added some of > the semantics of Kulp's scheme to the kernel, but not all as you point out > and it was pretty disappointing if you had grown up on BSD systems.  Later > POSIX would pick up the Kulp/BSD Job Control definition and by SVR3/SVR4 > AT&T fleshed out all all of the semantics. There is a pretty good discussion of 4.2 BSD-style job control and ways to make it fit with System V semantics (mostly controlling terminals and, of course, process groups) at https://web.physics.ucsb.edu/~pcs/apps/bash/job.control.ps This is probably the best description of BSD-style job control, and it is the inspiration for much of the POSIX job control design (e.g., their invention of "sessions" as the replacement for System V style process groups). 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 chet.ramey at case.edu Wed Jan 4 02:34:12 2023 From: chet.ramey at case.edu (Chet Ramey) Date: Tue, 3 Jan 2023 11:34:12 -0500 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <202301011128.301BS8D2015648@freefriends.org> References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <202301011044.301Aib7T009476@freefriends.org> <202301011128.301BS8D2015648@freefriends.org> Message-ID: <8fab0787-11cc-2efe-3704-211331541f02@case.edu> On 1/1/23 6:28 AM, arnold at skeeve.com wrote: > I also recall that there was some USENET discussion in which > Rob Pike described how the 8th edition shell changed the search > order to have functions come before non-special built-ins, with > the addition of "builtin" and "whatis" commands. I have this somewhere. It's a rocking back-and-forth between Rob and David Korn about shell philosophy. Well worth the read if you can find it. -- ``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 4 02:44:04 2023 From: crossd at gmail.com (Dan Cross) Date: Tue, 3 Jan 2023 11:44:04 -0500 Subject: [TUHS] C Style and Coding Standards for SunOS Message-ID: Does anyone have the original troff of this document? It was written by Bill Shannon at Sun, documenting the C style conventions for SunOS. A PDF rendering is here: https://www.cis.upenn.edu/~lee/06cse480/data/cstyle.ms.pdf Thanks! - Dan C. From marzhall.o at gmail.com Wed Jan 4 02:53:49 2023 From: marzhall.o at gmail.com (Marshall Conover) Date: Tue, 3 Jan 2023 11:53:49 -0500 Subject: [TUHS] Command Line Editing in the Terminal Driver (Was: A few comments on porting the Bourne shell) In-Reply-To: References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <8ca17d52-a25a-dbbf-e1f0-d743b8884cfa@in-ulm.de> Message-ID: Along these lines but not quite, Jupyter Notebooks have stood out to me as another approach to this concept, with behavior I'd like to see implemented in a shell. With these notebooks, users type text into blocks, and then can have these blocks evaluated by some underlying engine, with the results of the evaluation showing up in a block underneath where they entered text. Results can be not only text, but things like rendered charts and images. There may be GUI-interactable rendered elements as well, but I'm unsure. Notably, text-entry blocks are created such that each new block holds onto the context of the previous blocks. So, a variable defined in the first eval block will be available in later blocks. Currently these are used primarily for demonstrating APIs, exploring data with python, or writing quick PoCs that can then be extracted into an application. Some companies, such as Netflix, have experimented with using them entirely as a replacement for shell scripts, which is the sort of research I'd most love to see. Fundamentally, I think it's a smell that the way we interact with our systems is tied to the long-gone hardware requirement of "be usable with a teletype." Acme was certainly a move towards recognizing the value of being able to reuse space that, in TTYs, would be 'dead' text. The ability to evaluate commands in Acme, and the further inclusion of an underlying evaluator that holds state by Jupyter were good steps forward, I think. I'd love to see experimentation with a whole system that takes the jupyter approach, with nested namespaces forming applications, combined with data being held in "blocks" as well as code - much like acme opens and edits files as well as letting you execute either them or snippets in them. I think there's a chance something could be developed that would better fit the way we interface with computers today, and the underlying engine approach would move us toward the "everything speaks one language" design we lost in the move from shells to standalone GUI applications. Mostly, I'd be bummed to see yet another shell that pretends it's behind a "glass teletype", to use the tongue-in-cheek term from "Ed Mastery", or just continuing elaboration on that design, despite the fact I use shells daily. It's the best we have now, but I feel like it's the way forward. Cheers! Marshall P.S. - Kakoune is neat and I'm going to have to poke around at that, thanks for pointing it out. On Mon, Jan 2, 2023 at 3:03 PM Joseph Holsten wrote: > On Fri, Dec 30, 2022, at 12:42, Sven Mascheck wrote: > > and in "ksh - An Extensible High Level Language" David Korn writes: > > - "Originally the idea of adding command line editing to ksh was > rejected in the hope that line editing would move into the terminal > driver." [2] > > [2] https://www.in-ulm.de/~mascheck/bourne/korn.html > > > This phrase has haunted me for years. It’s so clearly the “correct” > separation of concerns, until you actually attempt implementing it. And > Bourne’s irregular grammar certainly doesn’t help here. I’d prefer to move > beyond readline, ideally something like text objects per > vim/zsh/treesitter. But having one parser in the interpreter and another in > the line editor becomes quite exciting if you want a true bourne or even > posix sh. > > But the thing that brought be back to playing against this quote again > this year was starting to research the QED lineage and discovering helix & > kakoune. Honestly, they feels like the most coherent advancements in > QED-style editors since sam & acme. (Yes, I’m irrationally excluding vim > text-objects, mostly because no one removed editor features that t-o made > redundant. It’s as if ed had twice as many commands, one for regexp matches > and one for pre-ken-QEDist exact matches.) > > Anyway, the only time I’ve really seen “line editing […] move into the > terminal driver” sound possible was acme’s win. For those who haven’t had > the pleasure, rsc describes it at 15:25 in https://research.swtch.com/acme. > “I worked for many years in a shell without history or command line > editing, and I never missed it because Acme is providing this for me.” > > It’s hard to convey how surprisingly pleasant sh or rc can be within acme > win to someone who has only used them within a mere > terminal-emulator-emulator. Especially since a greenfield terminal app > has more code emulating old xterm behaviors than physical vt100 behaviours. > This is especially exhausting when you try to use something like NeoVim’s > :term expecting it to just work and discover that buffer-line-wrapping on > window-resize hasn’t been implemented. > > Anyone seen any other “terminal drivers” that provide a pleasant > alternative to line editing? > -- > ~j > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuz at fuz.su Wed Jan 4 02:54:40 2023 From: fuz at fuz.su (Robert Clausecker) Date: Tue, 3 Jan 2023 17:54:40 +0100 Subject: [TUHS] C Style and Coding Standards for SunOS In-Reply-To: References: Message-ID: Hi Dan, Jörg Schilling had a copy in his schilytools. You can find it here: https://codeberg.org/schilytools/schilytools/src/branch/master/cstyle/cstyle.ms With best regard, Robert Clausecker Am Tue, Jan 03, 2023 at 11:44:04AM -0500 schrieb Dan Cross: > Does anyone have the original troff of this document? It was written by Bill Shannon at Sun, > documenting the C style conventions for SunOS. A PDF rendering is here: > https://www.cis.upenn.edu/~lee/06cse480/data/cstyle.ms.pdf > > Thanks! > > - Dan C. -- () ascii ribbon campaign - for an 8-bit clean world /\ - against html email - against proprietary attachments From paul.winalski at gmail.com Wed Jan 4 03:08:18 2023 From: paul.winalski at gmail.com (Paul Winalski) Date: Tue, 3 Jan 2023 12:08:18 -0500 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net> <20230102165120.GK25547@mcvoy.com> Message-ID: On 1/2/23, Clem Cole wrote: > > FWIW: In my start-up times, under the same rules of being disciplined, as > VP of Engineering, I insisted, all C and C++ code was required to > 'flex-e-lint' warning clean. I gave my folks a 3-week week slip to clean > everything up. I was cursed during that time. But guess what, the > outstanding bug list dropped to ⅒ of what it had been. Created quite a few > true believers. And we made those 3 weeks back before we were done. This was also the policy in DEC's compiler and software development tools groups. This was mainly VMS stuff and we didn't have flex and lint, but as Clem can attest the C and C++ compilers had very extensive warning capabilities. It was group policy that all code had to compile cleanly, without triggering diagnostic messages, before check-in was allowed. Once you get through the initial cleanup of existing code, this policy pays back big time in avoidance of nasty Heisenbugs. -Paul W. From jon at fourwinds.com Wed Jan 4 03:19:52 2023 From: jon at fourwinds.com (Jon Steinhart) Date: Tue, 03 Jan 2023 09:19:52 -0800 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <3a891e61-a8b1-cfe4-95ab-c60e6ac6eb42@gmail.com> References: <3a891e61-a8b1-cfe4-95ab-c60e6ac6eb42@gmail.com> Message-ID: <202301031719.303HJq6A540885@darkstar.fourwinds.com> Alejandro Colomar writes: > Well, as time goes by, I'm also writing less and less programs. But only > because I find that I can pipe programs together to do what I want without > having to write a new one. I guess that's a fair reason to not compile :) Wow! Small programs that do one thing and do it well connected together to do more complicated things? What an awesome idea :-) Jon From crossd at gmail.com Wed Jan 4 03:26:49 2023 From: crossd at gmail.com (Dan Cross) Date: Tue, 3 Jan 2023 12:26:49 -0500 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: Message-ID: On Tue, Jan 3, 2023 at 10:09 AM Douglas McIlroy wrote: > The forgotten compilers were typically used to supply glue > to paste major tools together. The nature of that glue---often > simple data reformatting--inspired tools like sed and awk. > Each use of a tool became a process that saved many minutes > of work that would in a scriptless world be guided by hand, > boringly and unreliably. This, I think, begs the question I raised earlier: what precisely is "the shell"? The command interpreter by itself isn't that interesting without a supporting toolset. And now we get into the crux or what it means to be "portable": what is the minimum set of such tools that allow us to write portable shell scripts? Again I ask, am I allowed to use `nawk`? How about '#!' lines? xargs? cut? paste? Perhaps that's the benefit of experience: over time, one develops a sense of what works across the broadest range of systems that one will likely encounter. But as Warner pointed out, we can be thankful we're not using Eunice. A few years ago, I was having lunch with some folks from the Go team and one of them remarked, "you shouldn't write a shell script that's longer than about 10 lines. Once you do, it's time to rewrite it in a real programming language." I was a bit taken aback, but they had a point. I'll note that Go standardized on using bash everywhere. > Yet glue processes typically did only microseconds of > "real" work. In the name of efficiency, the operations began > to be incorporated directly into the shell. The first > inklings of this can be seen in "echo" and various forms > of variable-substitution making their way into the v7 > shell. The phenomenon proliferated into putting what were > typically canned sed one-liners (but not sed itself) into > the shell. Perhaps I've told this story, but 10 or 12 years ago at Google a colleague was writing a script to find the location of some resource or other. I no longer recall what, exactly, but he had written this massively over-structured thing: shell functions that ran one or two commands, heavily commented, and he was trying to `return` the exit status from those commands as the result from the function. It wasn't working because, well, that's just not how such things work. I sat down, and rewrote it into about 10 lines; the salient part was that there was a conditional that determined whether the system it was running on had a 64-bit or 32-bit userland and ran a handful of commands depending. I showed him the revised script and he was uncomfortable; after a while he kind of gave me a look and said, "yeah, I just don't think people conceptualize of problems that way anymore." Meaning, it was far more natural for him and others to just write a Python program instead of a simple script. To him, the script wasn't simple, but the Python program was. That has stuck with me for a long, long time. Anyway, we checked the script in and it worked; it's probably still running, though I suspect most, if not all, 32-bit systems are gone from Google so perhaps it was long-ago recycled. I have no idea anymore, but it really gave me pause: had everything I'd learned about Unix in the prior 20 years become obsolete? Was I an anachronism amongst my colleagues? Were they right, and I wrong about how to approach problems? > Lots of specializations crowded out universality. A side > effect was an explosion of knowledge required to write > or understand code. Such is the tragedy of "forgetting > compilers". Something I've noticed is that lots of people try to increase complexity to solve problems, and it rarely occurs to them to eliminate complexity to solve problems. Sometimes the reasons for this are good; most of the time they are not. - Dan C. From crossd at gmail.com Wed Jan 4 03:30:21 2023 From: crossd at gmail.com (Dan Cross) Date: Tue, 3 Jan 2023 12:30:21 -0500 Subject: [TUHS] C Style and Coding Standards for SunOS In-Reply-To: References: Message-ID: On Tue, Jan 3, 2023 at 11:54 AM Robert Clausecker wrote: > Jörg Schilling had a copy in his schilytools. You can find > it here: > > https://codeberg.org/schilytools/schilytools/src/branch/master/cstyle/cstyle.ms Thank you, Robert! From usotsuki at buric.co Wed Jan 4 04:07:36 2023 From: usotsuki at buric.co (Steve Nickolas) Date: Tue, 3 Jan 2023 13:07:36 -0500 (EST) Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: Message-ID: On Tue, 3 Jan 2023, Dan Cross wrote: > Something I've noticed is that lots of people try to increase > complexity to solve problems, and it rarely occurs to them to > eliminate complexity to solve problems. Sometimes the reasons for this > are good; most of the time they are not. > > - Dan C. I think of the saying: "Perfection is not when there is nothing left to add, but when there is nothing left to remove." -uso. From nikke.karlsson at gmail.com Wed Jan 4 04:19:17 2023 From: nikke.karlsson at gmail.com (Niklas Karlsson) Date: Tue, 3 Jan 2023 19:19:17 +0100 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: Message-ID: Den tis 3 jan. 2023 kl 18:28 skrev Dan Cross : > A few years ago, I was having lunch with some folks from the Go team > and one of them remarked, "you shouldn't write a shell script that's > longer than about 10 lines. Once you do, it's time to rewrite it in a > real programming language." I was a bit taken aback, but they had a > point. I'll note that Go standardized on using bash everywhere. > They wouldn't like my current project. It's a whole bunch of different shell scripts (and they use bash-isms, since it's inconceivable that anyone would use them on a non-Linux non-GNU system) calling each other as modules. The scripts aren't HUGE, but they're certainly a lot more than 10 lines. I work for an academic supercomputing facility, and we have a corporate customer using our systems to do aerodynamics calculations. They want a way to automatically submit jobs on our systems from their own environment, complete with transferring the source data files to us and the results files back to them when they're done. They're integrating that with their own set of scripts (a lot of Python, I believe) so an aerodynamics engineer can just pick an option from a menu and everything works automagically. I'd say bash works pretty well for that application. It's a lot of calling external programs (scp, sbatch (the command to submit a SLURM job, SLURM being the batch management facility a lot of large compute clusters use to manage their jobs), etc). I inherited this set of scripts from someone who quit before I joined in 2020, and have modified them extensively since then to work well with the corporate customer's scripts and be more generic. It's in a fully working state at this point, but I still have some feature requests to take care of. I am more of a sysadmin than a developer, but I certainly can write code when the situation warrants. Pure Windows sysadmins often can't write code at all (though there are certainly some who are very conversant with PowerShell) but I'd say any UNIX/Linux sysadmin worth their salt can at least write shell scripts, and often Python, or some years back, Perl. Niklas -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Wed Jan 4 05:19:42 2023 From: imp at bsdimp.com (Warner Losh) Date: Tue, 3 Jan 2023 12:19:42 -0700 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net> <20230102165120.GK25547@mcvoy.com> Message-ID: On Tue, Jan 3, 2023, 10:09 AM Paul Winalski wrote: > On 1/2/23, Clem Cole wrote: > > > > FWIW: In my start-up times, under the same rules of being disciplined, as > > VP of Engineering, I insisted, all C and C++ code was required to > > 'flex-e-lint' warning clean. I gave my folks a 3-week week slip to > clean > > everything up. I was cursed during that time. But guess what, the > > outstanding bug list dropped to ⅒ of what it had been. Created quite a > few > > true believers. And we made those 3 weeks back before we were done. > > This was also the policy in DEC's compiler and software development > tools groups. This was mainly VMS stuff and we didn't have flex and > lint, but as Clem can attest the C and C++ compilers had very > extensive warning capabilities. It was group policy that all code had > to compile cleanly, without triggering diagnostic messages, before > check-in was allowed. Once you get through the initial cleanup of > existing code, this policy pays back big time in avoidance of nasty > Heisenbugs. > Not all fixes to appease warnings fix anything. But enough do that it's worth it. The one caveat here is that people must understand the warning and that any change makes things better. There is nothing worse than just tossing a cast in to brute force it, only to later discover it's the wrong cast or you needed a different semantic change. Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From luther at makerlisp.com Wed Jan 4 05:56:41 2023 From: luther at makerlisp.com (Luther Johnson) Date: Tue, 3 Jan 2023 12:56:41 -0700 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net> <20230102165120.GK25547@mcvoy.com> Message-ID: <646bfcbc-8ae3-0fb4-0b3a-b91295fa5ced@makerlisp.com> All warnings are worthy of my consideration. I will usually learn something about my compiler, my program, and often both. The compiler's messages are valuable feedback in my quality work-style loop. On 01/03/2023 12:19 PM, Warner Losh wrote: > > > On Tue, Jan 3, 2023, 10:09 AM Paul Winalski > wrote: > > On 1/2/23, Clem Cole > wrote: > > > > FWIW: In my start-up times, under the same rules of being > disciplined, as > > VP of Engineering, I insisted, all C and C++ code was required to > > 'flex-e-lint' warning clean. I gave my folks a 3-week week > slip to clean > > everything up. I was cursed during that time. But guess > what, the > > outstanding bug list dropped to ⅒ of what it had been. Created > quite a few > > true believers. And we made those 3 weeks back before we were done. > > This was also the policy in DEC's compiler and software development > tools groups. This was mainly VMS stuff and we didn't have flex and > lint, but as Clem can attest the C and C++ compilers had very > extensive warning capabilities. It was group policy that all code had > to compile cleanly, without triggering diagnostic messages, before > check-in was allowed. Once you get through the initial cleanup of > existing code, this policy pays back big time in avoidance of nasty > Heisenbugs. > > > Not all fixes to appease warnings fix anything. But enough do that > it's worth it. > > The one caveat here is that people must understand the warning and > that any change makes things better. There is nothing worse than just > tossing a cast in to brute force it, only to later discover it's the > wrong cast or you needed a different semantic change. > > Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Wed Jan 4 06:20:25 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 03 Jan 2023 20:20:25 +0000 Subject: [TUHS] AT&T UNIX PC (7300) Teardown and Restoration Message-ID: Good day everyone, just starting a thread for yet another project I'll be tinkering on over time. Picked up a (presumably broken/untested) 7300 off eBay to at the very least tear down and get some good pictures of and, with some luck, perhaps get working again. https://imgur.com/a/CExzebl Here are some pictures of the exterior for starters. I'll update this thread when I've got pictures of the guts and also with any info I can glean regarding whether this might be salvageable. The rust on the back is pretty nasty but I've seen older/worse start up just fine. - Matt G. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Wed Jan 4 06:21:32 2023 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 4 Jan 2023 07:21:32 +1100 (EST) Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net> <20230102165120.GK25547@mcvoy.com> Message-ID: On Tue, 3 Jan 2023, Warner Losh wrote: > Not all fixes to appease warnings fix anything. But enough do that it's > worth it. I consider warnings to be potential errors, and act accordingly; one place where I worked insisted that code could not be checked in unless it passed "-Wall" (no guarantee of course, but a good start). > The one caveat here is that people must understand the warning and that > any change makes things better. There is nothing worse than just tossing > a cast in to brute force it, only to later discover it's the wrong cast > or you needed a different semantic change.  Yeah, that's just painting over the cracks; it's like replacing a fuse that keeps blowing, or rebooting a box without fixing the bug (what I call the M$ Solution). -- Dave From clemc at ccc.com Wed Jan 4 07:47:18 2023 From: clemc at ccc.com (Clem Cole) Date: Tue, 3 Jan 2023 16:47:18 -0500 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net> <20230102165120.GK25547@mcvoy.com> Message-ID: Bring this back to TUHS relevance... On Tue, Jan 3, 2023 at 2:43 PM Warner Losh wrote: > The one caveat here is that people must understand the warning and that > any change makes things better. There is nothing worse than just tossing a > cast in to brute force it, only to later discover it's the wrong cast or > you needed a different semantic change. > Most certainly -- It's why I >>loved<< Gimpel's flex-e-lint product and as Paul pointed out, Judy Ward's messages from the DEC Gem compiler - both were the two best I ever ran into in giving you real information about what was happening. I also tell a story from my DEC time. After the GEM compiler was released and before most other vendors were 64-bits, the ISVs were first starting to do their ports to Alpha. My complaining ensued. We would discover from numerous ISVs that after the Alpha port was complete, their bug count dropped - why because the ISV's code has been kinda nasty and the older compilers had been silent about it they had assumed the ILP32 model. Alphas, using LP64, could not be. Judy would find things and say -- what a minute -- you want me to do what with that and issued a fairly detailed warning (which was the key - she explained what the issue was). Often the 32 to 64-bit nature forced the programmers at the ISV's to rethink how there were actually declaring things to make the code clearer, simpler, better, *etc*. The classic rewrite never happens unless you are forced too. I remember going to a Supercomputer conference and talking with the developers at one the ISVs who I will not name. He thanks me. He said his team has been arguing with their management for years to redo the UNIX support library. The Tru64 port was what finally allowed them to do it. But it took 9 months which pissed off his boss. But when it was completed, and pass all the tests on the Alpha, it just recompiled on Solaris, AIX, and HP-UX - which had never happened before. He could not believe what a great compiler we had. I've always said the Alpha was the greatest gift to Sun and Intel in the commercial SW world because it forced the ISV to clean up their act before they ever saw those processors and Sun/Intel ports were piece of cake. It was not that porting to Alpha was difficult -- it was cleaning up your own mess. Remember we had already gone through this in the PDP-11 ILP16 to Vax ILP32 transition but it is funny how history repeated itself. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Jan 4 07:51:57 2023 From: clemc at ccc.com (Clem Cole) Date: Tue, 3 Jan 2023 16:51:57 -0500 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net> <20230102165120.GK25547@mcvoy.com> Message-ID: typo: s/My complaining/Much complaining/ sigh.. dyslex-r-me ᐧ On Tue, Jan 3, 2023 at 4:47 PM Clem Cole wrote: > > Bring this back to TUHS relevance... > > On Tue, Jan 3, 2023 at 2:43 PM Warner Losh wrote: > >> The one caveat here is that people must understand the warning and that >> any change makes things better. There is nothing worse than just tossing a >> cast in to brute force it, only to later discover it's the wrong cast or >> you needed a different semantic change. >> > Most certainly -- It's why I >>loved<< Gimpel's flex-e-lint product and > as Paul pointed out, Judy Ward's messages from the DEC Gem compiler - both > were the two best I ever ran into in giving you real information about what > was happening. > > I also tell a story from my DEC time. After the GEM compiler was > released and before most other vendors were 64-bits, the ISVs were first > starting to do their ports to Alpha. My complaining ensued. We would discover > from numerous ISVs that after the Alpha port was complete, their bug count > dropped - why because the ISV's code has been kinda nasty and the older > compilers had been silent about it they had assumed the ILP32 model. > Alphas, using LP64, could not be. Judy would find things and say -- what > a minute -- you want me to do what with that and issued a fairly detailed > warning (which was the key - she explained what the issue was). Often > the 32 to 64-bit nature forced the programmers at the ISV's to rethink > how there were actually declaring things to make the code clearer, > simpler, better, *etc*. The classic rewrite never happens unless you > are forced too. > > I remember going to a Supercomputer conference and talking with the > developers at one the ISVs who I will not name. He thanks me. He said his > team has been arguing with their management for years to redo the UNIX > support library. The Tru64 port was what finally allowed them to do it. > But it took 9 months which pissed off his boss. But when it was completed, > and pass all the tests on the Alpha, it just recompiled on Solaris, AIX, > and HP-UX - which had never happened before. He could not believe what a > great compiler we had. > > I've always said the Alpha was the greatest gift to Sun and Intel in the > commercial SW world because it forced the ISV to clean up their act before > they ever saw those processors and Sun/Intel ports were piece of cake. It > was not that porting to Alpha was difficult -- it was cleaning up your own > mess. > > Remember we had already gone through this in the PDP-11 ILP16 to Vax > ILP32 transition but it is funny how history repeated itself. > ᐧ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Wed Jan 4 06:19:00 2023 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 03 Jan 2023 21:19:00 +0100 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: Message-ID: <20230103201900.oR1Qq%steffen@sdaoden.eu> Steve Nickolas wrote in : |On Tue, 3 Jan 2023, Dan Cross wrote: |> Something I've noticed is that lots of people try to increase |> complexity to solve problems, and it rarely occurs to them to |> eliminate complexity to solve problems. Sometimes the reasons for this |> are good; most of the time they are not. |> |> - Dan C. | |I think of the saying: "Perfection is not when there is nothing left to |add, but when there is nothing left to remove." He (Exupéry) was then shot down. I always seem to response this to that. Hmm, openpgp at ietf.org (to which i have almost zero to add technically shall someone think that, nor do i want) lastly |"Perfection is achieved not when there is nothing more to add but when \ |there |is nothing left to take away" - Antoine de Saint-Exupéry. He was then shot down. But yes, he then really went missing. The topic .. I do not miss times where suddenly a shell script breaks because ": > FILE" does not work (just recently 'realized from reading code of Paul Eggert of GNU/IANA TZ, "hey, > FILE" is of course sufficient!"), i fixed it via "printf '' > FILE" by then; whatever the reason. May it be bugs or (local) miscompilations, not detected due to missing unit tests and a too small user base. Portable? If i find /usr/xpg4/bin i quickly add it to $PATH for the much better awk (but beware of documented double expansion issues) and the much much better sh(1). Some things just require that, noclobber I/O redirection (set -C) for example. (mktemp(1) is still not part of the POSIX standard.) Besides i miss(ed) the history; the author of bmake (and verieexec) just last year asked me why i would use stty for a purpose ("(<&1 >/dev/null stty -a) 2>/dev/null") instead of simply using "[ -t 1 ]", and indeed, i found that as soon as BSD 4.1 and Research V7, but it surprised me. Without an oversight of the history and the lack of many systems to test, perl(1) was omnipresent and if only for OpenSSL and so using it for almost anything seemed save. To love is not to look at one another: it is to look, together, in the same direction. Antoine de Saint-Exupéry. A happy and healthy new Year 2023 is now overdue. Even Giants have to die, but with holding hands it can wait a bit longer, i hope. I wish that from Germany to all of you, and deliberately beyond NATO readership. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From rminnich at gmail.com Wed Jan 4 09:03:15 2023 From: rminnich at gmail.com (ron minnich) Date: Tue, 3 Jan 2023 15:03:15 -0800 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <20230103201900.oR1Qq%steffen@sdaoden.eu> References: <20230103201900.oR1Qq%steffen@sdaoden.eu> Message-ID: I apologize for this too long message, but context in this case matters. tl;dr: I agree with the Go folks: past about 10 lines, write a program. But not everybody will agree, as I learned with u-root. Many people love shell programming. I never have. u-root is a set of Go programs deployed on a couple million data center systems at many companies, including Google. u-root originally used a compile-on-demand model: type a command name, if it's not in /ubin, it gets built. This was fast, in early Go, typically 250 ms or so. And, in the early days of Go, the Go toolchain, u-root, and all support source easily fit in a 16M SPI part. The original scripting language for u-root was Go. There were two commands for this: script and builtin. script would run Go fragments; builtin would take supplied commands and build a custom shell with those built in. Each took 250ms to run. script took what we called a 'Go fragment', wrapped it with boiler plate, compiled it, and ran it. e.g. script fmt.Printf("hi\n") would build the program and run that code. So you could, e.g,, do math: script fmt.Printf("%d\n", 6*7) It could get complex: to see things about interfaces: script 'ifaces, _ := net.Interfaces() for _, v := range ifaces { addrs, _ := v.Addrs() Printf("%v has %v", v, addrs) }' you'd get: ip: {1 1500 lo up|loopback} has [127.0.0.1/8 ::1/128] ip: {5 1500 eth0 fa:42:2c:d4:0e:01 up|broadcast} has [172.17.0.2/16 fe80::f842:2cff:fed4:e01/64] The second command was called builtin. It did not work as other shells do: it built a new shell for you. So, you type: bulitin hi fmt.Printf("hi") there fmt.Printf("there\n") builtin would convert the Go fragments to functions callable in the u-root shell, build a private name space (on Linux or Plan 9 anyway), rebuild the shell with those new functions, and at that point: you type hi in the shell, and it types hi back. This was built in to your private shell in your private name space. Once you left the shell, it was gone. Again, this process of creating and starting the new shell always took about 250 ms (in Go 1.2 that is). I learned a lesson: people love their shell scripting languages. Nobody wanted to script with Go. It made me sad, but that's how it Go-es. ron p.s. the 'script' command is still available as an experimental u-root command. Source mode is now independent: github.com/u-root/sourcery On Tue, Jan 3, 2023 at 2:35 PM Steffen Nurpmeso wrote: > Steve Nickolas wrote in > : > |On Tue, 3 Jan 2023, Dan Cross wrote: > |> Something I've noticed is that lots of people try to increase > |> complexity to solve problems, and it rarely occurs to them to > |> eliminate complexity to solve problems. Sometimes the reasons for this > |> are good; most of the time they are not. > |> > |> - Dan C. > | > |I think of the saying: "Perfection is not when there is nothing left to > |add, but when there is nothing left to remove." > > He (Exupéry) was then shot down. > > I always seem to response this to that. > Hmm, openpgp at ietf.org (to which i have almost zero to add > technically shall someone think that, nor do i want) lastly > > |"Perfection is achieved not when there is nothing more to add but when > \ > |there > |is nothing left to take away" - Antoine de Saint-Exupéry. > > He was then shot down. > > But yes, he then really went missing. > > The topic .. > I do not miss times where suddenly a shell script breaks because > ": > FILE" does not work (just recently 'realized from reading code > of Paul Eggert of GNU/IANA TZ, "hey, > FILE" is of course > sufficient!"), i fixed it via "printf '' > FILE" by then; whatever > the reason. May it be bugs or (local) miscompilations, not > detected due to missing unit tests and a too small user base. > > Portable? If i find /usr/xpg4/bin i quickly add it to $PATH for > the much better awk (but beware of documented double expansion > issues) and the much much better sh(1). > Some things just require that, noclobber I/O redirection (set -C) > for example. (mktemp(1) is still not part of the POSIX standard.) > > Besides i miss(ed) the history; the author of bmake (and > verieexec) just last year asked me why i would use stty for > a purpose ("(<&1 >/dev/null stty -a) 2>/dev/null") instead of > simply using "[ -t 1 ]", and indeed, i found that as soon as BSD > 4.1 and Research V7, but it surprised me. > Without an oversight of the history and the lack of many systems > to test, perl(1) was omnipresent and if only for OpenSSL and so > using it for almost anything seemed save. > > To love is not to look at one another: it is to look, > together, in the same direction. Antoine de Saint-Exupéry. > > A happy and healthy new Year 2023 is now overdue. > Even Giants have to die, but with holding hands it can wait a bit > longer, i hope. > I wish that from Germany to all of you, and deliberately beyond > NATO readership. > > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Wed Jan 4 09:27:54 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 03 Jan 2023 23:27:54 +0000 Subject: [TUHS] AT&T UNIX PC (7300) Teardown and Restoration In-Reply-To: References: Message-ID: And here are some pictures of the guts. https://imgur.com/a/E1ioxZl Various bits inside date this to late 1985. The good news is it at least turns on, but that's about as far as I've gotten with it. The display never turns on, nor do I hear any sounds indicating it tries to start the CRT. The fans kick on and there it stays until I turn it off. I plugged in a USB-TTY to pins 2, 3, and 7 (RX/TX/GND) and listened at 9600 baud 8 bit 1 stop no parity and got nothing. Swapped the RX/TX, still nothing. Of course, that's all predicated on the assumption there's something there to even interact with. I have little faith that whatever UNIX install was on this is extant. Additionally, it didn't come with a keyboard, so if there was some futzing with key combos that would trigger some sort of UART over those lines, I can't do that. I wonder if there are some contacts inside I can just poll for activity with this serial connector, not sure how safe that is... Anywho, the CPU has a bit of corrosion on the surface, not sure how that bodes for the innards, but this is in kinda rough shape either way. I hope I can salvage it but if not, I'm going to at least do some study on the CRT particulars and see if I can extract and keep the monitor from it, been wanting a smaller CRT to have around for a while. - Matt G. ------- Original Message ------- On Tuesday, January 3rd, 2023 at 12:20 PM, segaloco via TUHS wrote: > Good day everyone, just starting a thread for yet another project I'll be tinkering on over time. Picked up a (presumably broken/untested) 7300 off eBay to at the very least tear down and get some good pictures of and, with some luck, perhaps get working again. > > https://imgur.com/a/CExzebl > > Here are some pictures of the exterior for starters. I'll update this thread when I've got pictures of the guts and also with any info I can glean regarding whether this might be salvageable. The rust on the back is pretty nasty but I've seen older/worse start up just fine. > > - Matt G. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Wed Jan 4 10:30:12 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 04 Jan 2023 00:30:12 +0000 Subject: [TUHS] AT&T UNIX PC (7300) Teardown and Restoration In-Reply-To: <371F8C4D-AAAC-4CD9-9547-3A7AC0C961D0@atvetsystems.com> References: <371F8C4D-AAAC-4CD9-9547-3A7AC0C961D0@atvetsystems.com> Message-ID: I'd love to get my hands on a 3B2 someday, this'll be cool if I can get it going but that'd be a much more robust machine. I'm starting to suspect if there isn't any sort of boot ROM that spits out commentary on the UART and that doesn't get flexed until UNIX is up, I may not be able to get very far. I referred to http://bitsavers.trailing-edge.com/pdf/att/3b1/999-809-010IS_UNIX_PC_Remote_Access_1986.pdf for the serial settings and it appears: 9600 baud, 1 stop bit, no parity, 8 data bits And the relevant pins Pin 1 - GND Pin 2 - RX Pin 3 - TX Pin 4 - RTS Pin 5 - CTS Pin 6 - DSR Pin 7 - GND Pin 8 - DCD Pin 20 - DTR So I've plugged my USB-TTY GND/RX/TX into the relevant pins and setup the necessary tty settings. The manual then suggests if running null modem mode to short pin 4 to 5 and then pins 6, 8, and 20 together, presumably omitting any need for modem signalling from the remote machine, doing basic serial RX/TX. Unfortunately even with all of this bypassing I get nothing out of the RS-232 port. What I don't know is if I could even expect something or if this is unlikely to bear fruit whether the hardware works or not. In any case, if I do get this thing running I'll have a writeup for folks afterwards. If not, then hopefully I can figure out something useful to do with this thing rather than junking it. - Matt G. ------- Original Message ------- On Tuesday, January 3rd, 2023 at 3:53 PM, rob at atvetsystems.com wrote: > Hello Matt, > > I’ve got one of these in my garage. I bought it about twenty years ago as a working system but when I got it home I noticed that the hard disk wasn’t connected but at some point I’d like to get it and my 3b2/300 working. > > Regards, Rob. > >> On 3 Jan 2023, at 23:27, segaloco via TUHS wrote: >> >> And here are some pictures of the guts. >> >> https://imgur.com/a/E1ioxZl >> >> Various bits inside date this to late 1985. The good news is it at least turns on, but that's about as far as I've gotten with it. The display never turns on, nor do I hear any sounds indicating it tries to start the CRT. The fans kick on and there it stays until I turn it off. I plugged in a USB-TTY to pins 2, 3, and 7 (RX/TX/GND) and listened at 9600 baud 8 bit 1 stop no parity and got nothing. Swapped the RX/TX, still nothing. Of course, that's all predicated on the assumption there's something there to even interact with. I have little faith that whatever UNIX install was on this is extant. Additionally, it didn't come with a keyboard, so if there was some futzing with key combos that would trigger some sort of UART over those lines, I can't do that. I wonder if there are some contacts inside I can just poll for activity with this serial connector, not sure how safe that is... >> >> Anywho, the CPU has a bit of corrosion on the surface, not sure how that bodes for the innards, but this is in kinda rough shape either way. I hope I can salvage it but if not, I'm going to at least do some study on the CRT particulars and see if I can extract and keep the monitor from it, been wanting a smaller CRT to have around for a while. >> >> - Matt G. >> ------- Original Message ------- >> On Tuesday, January 3rd, 2023 at 12:20 PM, segaloco via TUHS wrote: >> >>> Good day everyone, just starting a thread for yet another project I'll be tinkering on over time. Picked up a (presumably broken/untested) 7300 off eBay to at the very least tear down and get some good pictures of and, with some luck, perhaps get working again. >>> >>> https://imgur.com/a/CExzebl >>> >>> Here are some pictures of the exterior for starters. I'll update this thread when I've got pictures of the guts and also with any info I can glean regarding whether this might be salvageable. The rust on the back is pretty nasty but I've seen older/worse start up just fine. >>> >>> - Matt G. -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Wed Jan 4 10:40:22 2023 From: imp at bsdimp.com (Warner Losh) Date: Tue, 3 Jan 2023 17:40:22 -0700 Subject: [TUHS] AT&T UNIX PC (7300) Teardown and Restoration In-Reply-To: References: <371F8C4D-AAAC-4CD9-9547-3A7AC0C961D0@atvetsystems.com> Message-ID: On Tue, Jan 3, 2023, 5:30 PM segaloco via TUHS wrote: > I'd love to get my hands on a 3B2 someday, this'll be cool if I can get it > going but that'd be a much more robust machine. > > I'm starting to suspect if there isn't any sort of boot ROM that spits out > commentary on the UART and that doesn't get flexed until UNIX is up, I may > not be able to get very far. I referred to > http://bitsavers.trailing-edge.com/pdf/att/3b1/999-809-010IS_UNIX_PC_Remote_Access_1986.pdf > for the serial settings and it appears: > > 9600 baud, 1 stop bit, no parity, 8 data bits > > And the relevant pins > > Pin 1 - GND > Pin 2 - RX > Pin 3 - TX > Pin 4 - RTS > Pin 5 - CTS > Pin 6 - DSR > Pin 7 - GND > Pin 8 - DCD > Pin 20 - DTR > > So I've plugged my USB-TTY GND/RX/TX into the relevant pins and setup the > necessary tty settings. The manual then suggests if running null modem mode > to short pin 4 to 5 and then pins 6, 8, and 20 together, presumably > omitting any need for modem signalling from the remote machine, doing basic > serial RX/TX. Unfortunately even with all of this bypassing I get nothing > out of the RS-232 port. What I don't know is if I could even expect > something or if this is unlikely to bear fruit whether the hardware works > or not. In any case, if I do get this thing running I'll have a writeup for > folks afterwards. If not, then hopefully I can figure out something useful > to do with this thing rather than junking it. > Silly question... did you level shift to RS 232 levels? You likely did... but if not... Warner - Matt G. > ------- Original Message ------- > On Tuesday, January 3rd, 2023 at 3:53 PM, rob at atvetsystems.com < > rob at atvetsystems.com> wrote: > > Hello Matt, > > I’ve got one of these in my garage. I bought it about twenty years ago as > a working system but when I got it home I noticed that the hard disk wasn’t > connected but at some point I’d like to get it and my 3b2/300 working. > > Regards, Rob. > > On 3 Jan 2023, at 23:27, segaloco via TUHS wrote: > > And here are some pictures of the guts. > > https://imgur.com/a/E1ioxZl > > Various bits inside date this to late 1985. The good news is it at least > turns on, but that's about as far as I've gotten with it. The display never > turns on, nor do I hear any sounds indicating it tries to start the CRT. > The fans kick on and there it stays until I turn it off. I plugged in a > USB-TTY to pins 2, 3, and 7 (RX/TX/GND) and listened at 9600 baud 8 bit 1 > stop no parity and got nothing. Swapped the RX/TX, still nothing. Of > course, that's all predicated on the assumption there's something there to > even interact with. I have little faith that whatever UNIX install was on > this is extant. Additionally, it didn't come with a keyboard, so if there > was some futzing with key combos that would trigger some sort of UART over > those lines, I can't do that. I wonder if there are some contacts inside I > can just poll for activity with this serial connector, not sure how safe > that is... > > Anywho, the CPU has a bit of corrosion on the surface, not sure how that > bodes for the innards, but this is in kinda rough shape either way. I hope > I can salvage it but if not, I'm going to at least do some study on the CRT > particulars and see if I can extract and keep the monitor from it, been > wanting a smaller CRT to have around for a while. > > - Matt G. > ------- Original Message ------- > On Tuesday, January 3rd, 2023 at 12:20 PM, segaloco via TUHS < > tuhs at tuhs.org> wrote: > > Good day everyone, just starting a thread for yet another project I'll be > tinkering on over time. Picked up a (presumably broken/untested) 7300 off > eBay to at the very least tear down and get some good pictures of and, with > some luck, perhaps get working again. > > https://imgur.com/a/CExzebl > > Here are some pictures of the exterior for starters. I'll update this > thread when I've got pictures of the guts and also with any info I can > glean regarding whether this might be salvageable. The rust on the back is > pretty nasty but I've seen older/worse start up just fine. > > - Matt G. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Wed Jan 4 10:46:06 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 04 Jan 2023 00:46:06 +0000 Subject: [TUHS] AT&T UNIX PC (7300) Teardown and Restoration In-Reply-To: References: <371F8C4D-AAAC-4CD9-9547-3A7AC0C961D0@atvetsystems.com> Message-ID: Nope, unfortunately I only know as much as is needed to plug into the GPIO RX/TX/GND working on single boards. I wouldn't be surprised if my assumption I just run these pins into the D-25 in the right holes is bunk...but that's how we learn sometimes. Once I move I should be able to setup a proper work bench where I can tinker on this sort of thing more intentionally rather than haphazardly. So perhaps a silly question for an expert but a valid one for me. I'll chase that angle and see if it bears fruit. - Matt G. ------- Original Message ------- On Tuesday, January 3rd, 2023 at 4:40 PM, Warner Losh wrote: > On Tue, Jan 3, 2023, 5:30 PM segaloco via TUHS wrote: > >> I'd love to get my hands on a 3B2 someday, this'll be cool if I can get it going but that'd be a much more robust machine. >> >> I'm starting to suspect if there isn't any sort of boot ROM that spits out commentary on the UART and that doesn't get flexed until UNIX is up, I may not be able to get very far. I referred to http://bitsavers.trailing-edge.com/pdf/att/3b1/999-809-010IS_UNIX_PC_Remote_Access_1986.pdf for the serial settings and it appears: >> >> 9600 baud, 1 stop bit, no parity, 8 data bits >> >> And the relevant pins >> >> Pin 1 - GND >> Pin 2 - RX >> Pin 3 - TX >> Pin 4 - RTS >> Pin 5 - CTS >> Pin 6 - DSR >> Pin 7 - GND >> Pin 8 - DCD >> Pin 20 - DTR >> >> So I've plugged my USB-TTY GND/RX/TX into the relevant pins and setup the necessary tty settings. The manual then suggests if running null modem mode to short pin 4 to 5 and then pins 6, 8, and 20 together, presumably omitting any need for modem signalling from the remote machine, doing basic serial RX/TX. Unfortunately even with all of this bypassing I get nothing out of the RS-232 port. What I don't know is if I could even expect something or if this is unlikely to bear fruit whether the hardware works or not. In any case, if I do get this thing running I'll have a writeup for folks afterwards. If not, then hopefully I can figure out something useful to do with this thing rather than junking it. > > Silly question... did you level shift to RS 232 levels? You likely did... but if not... > > Warner > >> - Matt G. >> ------- Original Message ------- >> On Tuesday, January 3rd, 2023 at 3:53 PM, rob at atvetsystems.com wrote: >> >>> Hello Matt, >>> >>> I’ve got one of these in my garage. I bought it about twenty years ago as a working system but when I got it home I noticed that the hard disk wasn’t connected but at some point I’d like to get it and my 3b2/300 working. >>> >>> Regards, Rob. >>> >>>> On 3 Jan 2023, at 23:27, segaloco via TUHS wrote: >>>> >>>> And here are some pictures of the guts. >>>> >>>> https://imgur.com/a/E1ioxZl >>>> >>>> Various bits inside date this to late 1985. The good news is it at least turns on, but that's about as far as I've gotten with it. The display never turns on, nor do I hear any sounds indicating it tries to start the CRT. The fans kick on and there it stays until I turn it off. I plugged in a USB-TTY to pins 2, 3, and 7 (RX/TX/GND) and listened at 9600 baud 8 bit 1 stop no parity and got nothing. Swapped the RX/TX, still nothing. Of course, that's all predicated on the assumption there's something there to even interact with. I have little faith that whatever UNIX install was on this is extant. Additionally, it didn't come with a keyboard, so if there was some futzing with key combos that would trigger some sort of UART over those lines, I can't do that. I wonder if there are some contacts inside I can just poll for activity with this serial connector, not sure how safe that is... >>>> >>>> Anywho, the CPU has a bit of corrosion on the surface, not sure how that bodes for the innards, but this is in kinda rough shape either way. I hope I can salvage it but if not, I'm going to at least do some study on the CRT particulars and see if I can extract and keep the monitor from it, been wanting a smaller CRT to have around for a while. >>>> >>>> - Matt G. >>>> ------- Original Message ------- >>>> On Tuesday, January 3rd, 2023 at 12:20 PM, segaloco via TUHS wrote: >>>> >>>>> Good day everyone, just starting a thread for yet another project I'll be tinkering on over time. Picked up a (presumably broken/untested) 7300 off eBay to at the very least tear down and get some good pictures of and, with some luck, perhaps get working again. >>>>> >>>>> https://imgur.com/a/CExzebl >>>>> >>>>> Here are some pictures of the exterior for starters. I'll update this thread when I've got pictures of the guts and also with any info I can glean regarding whether this might be salvageable. The rust on the back is pretty nasty but I've seen older/worse start up just fine. >>>>> >>>>> - Matt G. -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Wed Jan 4 10:57:02 2023 From: imp at bsdimp.com (Warner Losh) Date: Tue, 3 Jan 2023 17:57:02 -0700 Subject: [TUHS] AT&T UNIX PC (7300) Teardown and Restoration In-Reply-To: References: <371F8C4D-AAAC-4CD9-9547-3A7AC0C961D0@atvetsystems.com> Message-ID: https://www.amazon.com/NOYITO-Module-Conversion-Arduino-communicates/dp/B07BJJ1T5G is my go-to for when I need a simple one, though something like https://www.amazon.com/NOYITO-Module-Conversion-Arduino-communicates/dp/B07BJJ3TZR might work better for your setup if you just have more of the TTL gear than RS-232 gear (I have way too many old RS-232 cables because I never know when I'll need them again...) Warner On Tue, Jan 3, 2023 at 5:46 PM segaloco wrote: > Nope, unfortunately I only know as much as is needed to plug into the GPIO > RX/TX/GND working on single boards. I wouldn't be surprised if my > assumption I just run these pins into the D-25 in the right holes is > bunk...but that's how we learn sometimes. Once I move I should be able to > setup a proper work bench where I can tinker on this sort of thing more > intentionally rather than haphazardly. So perhaps a silly question for an > expert but a valid one for me. I'll chase that angle and see if it bears > fruit. > > - Matt G. > ------- Original Message ------- > On Tuesday, January 3rd, 2023 at 4:40 PM, Warner Losh > wrote: > > > > On Tue, Jan 3, 2023, 5:30 PM segaloco via TUHS wrote: > >> I'd love to get my hands on a 3B2 someday, this'll be cool if I can get >> it going but that'd be a much more robust machine. >> >> I'm starting to suspect if there isn't any sort of boot ROM that spits >> out commentary on the UART and that doesn't get flexed until UNIX is up, I >> may not be able to get very far. I referred to >> http://bitsavers.trailing-edge.com/pdf/att/3b1/999-809-010IS_UNIX_PC_Remote_Access_1986.pdf >> for the serial settings and it appears: >> >> 9600 baud, 1 stop bit, no parity, 8 data bits >> >> And the relevant pins >> >> Pin 1 - GND >> Pin 2 - RX >> Pin 3 - TX >> Pin 4 - RTS >> Pin 5 - CTS >> Pin 6 - DSR >> Pin 7 - GND >> Pin 8 - DCD >> Pin 20 - DTR >> >> So I've plugged my USB-TTY GND/RX/TX into the relevant pins and setup the >> necessary tty settings. The manual then suggests if running null modem mode >> to short pin 4 to 5 and then pins 6, 8, and 20 together, presumably >> omitting any need for modem signalling from the remote machine, doing basic >> serial RX/TX. Unfortunately even with all of this bypassing I get nothing >> out of the RS-232 port. What I don't know is if I could even expect >> something or if this is unlikely to bear fruit whether the hardware works >> or not. In any case, if I do get this thing running I'll have a writeup for >> folks afterwards. If not, then hopefully I can figure out something useful >> to do with this thing rather than junking it. >> > > Silly question... did you level shift to RS 232 levels? You likely did... > but if not... > > Warner > > - Matt G. >> ------- Original Message ------- >> On Tuesday, January 3rd, 2023 at 3:53 PM, rob at atvetsystems.com < >> rob at atvetsystems.com> wrote: >> >> Hello Matt, >> >> I’ve got one of these in my garage. I bought it about twenty years ago as >> a working system but when I got it home I noticed that the hard disk wasn’t >> connected but at some point I’d like to get it and my 3b2/300 working. >> >> Regards, Rob. >> >> On 3 Jan 2023, at 23:27, segaloco via TUHS wrote: >> >> And here are some pictures of the guts. >> >> https://imgur.com/a/E1ioxZl >> >> Various bits inside date this to late 1985. The good news is it at least >> turns on, but that's about as far as I've gotten with it. The display never >> turns on, nor do I hear any sounds indicating it tries to start the CRT. >> The fans kick on and there it stays until I turn it off. I plugged in a >> USB-TTY to pins 2, 3, and 7 (RX/TX/GND) and listened at 9600 baud 8 bit 1 >> stop no parity and got nothing. Swapped the RX/TX, still nothing. Of >> course, that's all predicated on the assumption there's something there to >> even interact with. I have little faith that whatever UNIX install was on >> this is extant. Additionally, it didn't come with a keyboard, so if there >> was some futzing with key combos that would trigger some sort of UART over >> those lines, I can't do that. I wonder if there are some contacts inside I >> can just poll for activity with this serial connector, not sure how safe >> that is... >> >> Anywho, the CPU has a bit of corrosion on the surface, not sure how that >> bodes for the innards, but this is in kinda rough shape either way. I hope >> I can salvage it but if not, I'm going to at least do some study on the CRT >> particulars and see if I can extract and keep the monitor from it, been >> wanting a smaller CRT to have around for a while. >> >> - Matt G. >> ------- Original Message ------- >> On Tuesday, January 3rd, 2023 at 12:20 PM, segaloco via TUHS < >> tuhs at tuhs.org> wrote: >> >> Good day everyone, just starting a thread for yet another project I'll be >> tinkering on over time. Picked up a (presumably broken/untested) 7300 off >> eBay to at the very least tear down and get some good pictures of and, with >> some luck, perhaps get working again. >> >> https://imgur.com/a/CExzebl >> >> Here are some pictures of the exterior for starters. I'll update this >> thread when I've got pictures of the guts and also with any info I can >> glean regarding whether this might be salvageable. The rust on the back is >> pretty nasty but I've seen older/worse start up just fine. >> >> - Matt G. >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Wed Jan 4 11:29:15 2023 From: athornton at gmail.com (Adam Thornton) Date: Tue, 3 Jan 2023 18:29:15 -0700 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: Message-ID: > On Jan 3, 2023, at 10:26 AM, Dan Cross wrote: > > > A few years ago, I was having lunch with some folks from the Go team > and one of them remarked, "you shouldn't write a shell script that's > longer than about 10 lines. Once you do, it's time to rewrite it in a > real programming language." I was a bit taken aback, but they had a > point. I'll note that Go standardized on using bash everywhere. My number is larger than 10, but it's smaller than 100. Lord knows I have plenty of things that started as a pipe and-or-for-loop at the command line, that became a shell script, that grew some arguments, that got beefier, and that I then rewrote in Perl or Python and cursed myself for not having done it that way from the start. The RSP Notebook I mentioned on COFF is about to have its installer--which is a hodgepodge of shell scripts and Python scripts--rewritten as reasonable Python classes with typing and test cases and everything, because it's grown enough that it's hard to understand in its current form. Adam From bakul at iitbombay.org Wed Jan 4 11:37:28 2023 From: bakul at iitbombay.org (Bakul Shah) Date: Tue, 3 Jan 2023 17:37:28 -0800 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <20230103201900.oR1Qq%steffen@sdaoden.eu> Message-ID: <325DF7E4-37BE-4432-9447-0B392B57DC69@iitbombay.org> I write shell one liners all the time[1]. Go is just too verbose for scripting. I use it for larger programs but typically these don't start out as shell scripts. [1] In fact I use find (or zsh's **/*), xargs, grep, sort, uniq, field picking often enough that I wish they were built-in a shell but I haven't figured out a simple syntax for it as yet. > On Jan 3, 2023, at 3:03 PM, ron minnich wrote: > > I apologize for this too long message, but context in this case matters. > > tl;dr: I agree with the Go folks: past about 10 lines, write a program. But not everybody will agree, as I learned with u-root. Many people love shell programming. I never have. > > u-root is a set of Go programs deployed on a couple million data center systems at many companies, including Google. > > u-root originally used a compile-on-demand model: type a command name, if it's not in /ubin, it gets built. This was fast, in early Go, typically 250 ms or so. And, in the early days of Go, the Go toolchain, u-root, and all support source easily fit in a 16M SPI part. > > The original scripting language for u-root was Go. > > There were two commands for this: script and builtin. script would run Go fragments; builtin would take supplied commands and build a custom shell with those built in. Each took 250ms to run. > > script took what we called a 'Go fragment', wrapped it with boiler plate, compiled it, and ran it. > e.g. > script fmt.Printf("hi\n") > would build the program and run that code. > So you could, e.g,, do math: > script fmt.Printf("%d\n", 6*7) > > It could get complex: to see things about interfaces: > script 'ifaces, _ := net.Interfaces() > for _, v := range ifaces { > addrs, _ := v.Addrs() > Printf("%v has %v", v, addrs) > }' > > you'd get: > ip: {1 1500 lo up|loopback} has [127.0.0.1/8 ::1/128] > ip: {5 1500 eth0 fa:42:2c:d4:0e:01 up|broadcast} has [172.17.0.2/16 fe80::f842:2cff:fed4:e01/64] > > The second command was called builtin. It did not work as other shells do: it built a new shell for you. So, you type: > bulitin hi fmt.Printf("hi") there fmt.Printf("there\n") > > builtin would convert the Go fragments to functions callable in the u-root shell, build a private name space (on Linux or Plan 9 anyway), rebuild the shell with those new functions, and at that point: > you type > hi > in the shell, and it types > hi > back. This was built in to your private shell in your private name space. Once you left the shell, it was gone. > Again, this process of creating and starting the new shell always took about 250 ms (in Go 1.2 that is). > > I learned a lesson: people love their shell scripting languages. Nobody wanted to script with Go. It made me sad, but that's how it Go-es. > > ron > p.s. the 'script' command is still available as an experimental u-root command. Source mode is now independent: github.com/u-root/sourcery > > > On Tue, Jan 3, 2023 at 2:35 PM Steffen Nurpmeso > wrote: >> Steve Nickolas wrote in >> >: >> |On Tue, 3 Jan 2023, Dan Cross wrote: >> |> Something I've noticed is that lots of people try to increase >> |> complexity to solve problems, and it rarely occurs to them to >> |> eliminate complexity to solve problems. Sometimes the reasons for this >> |> are good; most of the time they are not. >> |> >> |> - Dan C. >> | >> |I think of the saying: "Perfection is not when there is nothing left to >> |add, but when there is nothing left to remove." >> >> He (Exupéry) was then shot down. >> >> I always seem to response this to that. >> Hmm, openpgp at ietf.org (to which i have almost zero to add >> technically shall someone think that, nor do i want) lastly >> >> |"Perfection is achieved not when there is nothing more to add but when \ >> |there >> |is nothing left to take away" - Antoine de Saint-Exupéry. >> >> He was then shot down. >> >> But yes, he then really went missing. >> >> The topic .. >> I do not miss times where suddenly a shell script breaks because >> ": > FILE" does not work (just recently 'realized from reading code >> of Paul Eggert of GNU/IANA TZ, "hey, > FILE" is of course >> sufficient!"), i fixed it via "printf '' > FILE" by then; whatever >> the reason. May it be bugs or (local) miscompilations, not >> detected due to missing unit tests and a too small user base. >> >> Portable? If i find /usr/xpg4/bin i quickly add it to $PATH for >> the much better awk (but beware of documented double expansion >> issues) and the much much better sh(1). >> Some things just require that, noclobber I/O redirection (set -C) >> for example. (mktemp(1) is still not part of the POSIX standard.) >> >> Besides i miss(ed) the history; the author of bmake (and >> verieexec) just last year asked me why i would use stty for >> a purpose ("(<&1 >/dev/null stty -a) 2>/dev/null") instead of >> simply using "[ -t 1 ]", and indeed, i found that as soon as BSD >> 4.1 and Research V7, but it surprised me. >> Without an oversight of the history and the lack of many systems >> to test, perl(1) was omnipresent and if only for OpenSSL and so >> using it for almost anything seemed save. >> >> To love is not to look at one another: it is to look, >> together, in the same direction. Antoine de Saint-Exupéry. >> >> A happy and healthy new Year 2023 is now overdue. >> Even Giants have to die, but with holding hands it can wait a bit >> longer, i hope. >> I wish that from Germany to all of you, and deliberately beyond >> NATO readership. >> >> --steffen >> | >> |Der Kragenbaer, The moon bear, >> |der holt sich munter he cheerfully and one by one >> |einen nach dem anderen runter wa.ks himself off >> |(By Robert Gernhardt) -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Wed Jan 4 11:58:12 2023 From: athornton at gmail.com (Adam Thornton) Date: Tue, 3 Jan 2023 18:58:12 -0700 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <325DF7E4-37BE-4432-9447-0B392B57DC69@iitbombay.org> References: <20230103201900.oR1Qq%steffen@sdaoden.eu> <325DF7E4-37BE-4432-9447-0B392B57DC69@iitbombay.org> Message-ID: <42B6E514-D210-49D3-A103-351F94563852@gmail.com> > On Jan 3, 2023, at 6:37 PM, Bakul Shah wrote: > > I write shell one liners all the time[1]. > > Go is just too verbose for scripting. I use it for larger programs but typically these don't start out as shell scripts. > > [1] In fact I use find (or zsh's **/*), xargs, grep, sort, uniq, field picking often enough that I wish they were built-in a shell but I haven't figured out a simple syntax for it as yet. I was 50 years old before I learned that sort has a -u, so I could have saved the pipe-through-uniq step. I also keep getting told grep has a -r but my finger macros won't stop typing find . -name \*.py | xargs ... (And yes, it's GNU find just about everywhere, so I can do -print0 | xargs -0 and not have to get fancy with the -I) But also, crap, it was 25, count 'em, 25 years ago that a friend looked at my workflow and said "I've never seen anyone use a GUI just as a way to keep a dozen terminal windows open side by side before." Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Wed Jan 4 13:20:46 2023 From: cowan at ccil.org (John Cowan) Date: Tue, 3 Jan 2023 22:20:46 -0500 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <20230102174304.GM25547@mcvoy.com> References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net> <20230102165120.GK25547@mcvoy.com> <20230102174304.GM25547@mcvoy.com> Message-ID: On Mon, Jan 2, 2023 at 12:43 PM Larry McVoy wrote: > I was supporting a commercial product in the early 2000's and there > were all sorts of systems then that had old shells. Yes, you could make > everything a 2 level thing where the first level finds the correct shell, > but that's just fuss. Just make things portable, it's not that hard > and it works everywhere. > Making shell scripts portable means not using pipelines, because given "foo | bar", kshNN and zsh execute foo in a subshell and bar in the top-level shell, whereas in other shells, both foo and bar execute in subshells. (For this reason, Posix allows either behavior.) Not having pipelines is a pretty drastic limitation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Wed Jan 4 13:31:06 2023 From: crossd at gmail.com (Dan Cross) Date: Tue, 3 Jan 2023 22:31:06 -0500 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net> <20230102165120.GK25547@mcvoy.com> <20230102174304.GM25547@mcvoy.com> Message-ID: On Tue, Jan 3, 2023 at 10:22 PM John Cowan wrote: > Making shell scripts portable means not using pipelines, because given "foo | bar", kshNN and zsh execute foo in a subshell and bar in the top-level shell, whereas in other shells, both foo and bar execute in subshells. (For this reason, Posix allows either behavior.) Not having pipelines is a pretty drastic limitation. This came up at work just the other day: echo ' hi ' | sed 's/^ *//;s/ *$//' | read bummer echo $bummer The behavior varies between ksh, zsh, bash, sh. Yay. - Dan C. From bakul at iitbombay.org Wed Jan 4 14:16:03 2023 From: bakul at iitbombay.org (Bakul Shah) Date: Tue, 3 Jan 2023 20:16:03 -0800 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net> <20230102165120.GK25547@mcvoy.com> <20230102174304.GM25547@mcvoy.com> Message-ID: On Jan 3, 2023, at 7:31 PM, Dan Cross wrote: > > On Tue, Jan 3, 2023 at 10:22 PM John Cowan wrote: >> Making shell scripts portable means not using pipelines, because given "foo | bar", kshNN and zsh execute foo in a subshell and bar in the top-level shell, whereas in other shells, both foo and bar execute in subshells. (For this reason, Posix allows either behavior.) Not having pipelines is a pretty drastic limitation. > > This came up at work just the other day: > > echo ' hi ' | sed 's/^ *//;s/ *$//' | read bummer > echo $bummer > > The behavior varies between ksh, zsh, bash, sh. Yay. On this example sh, zsh, bash behave the same way on freebsd. Rather than ban |, I think the lesson is to *avoid* builtin commands in a pipeline that can affect shell's environment. I only write /bin/sh scripts in any case. It is really unfortunate that infix | is so beguiling! Except for that a Lisp or Scheme based shell would've been fine and dandy! :-)/2 From tytso at mit.edu Wed Jan 4 15:05:41 2023 From: tytso at mit.edu (Theodore Ts'o) Date: Wed, 4 Jan 2023 00:05:41 -0500 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <20230103201900.oR1Qq%steffen@sdaoden.eu> Message-ID: On Tue, Jan 03, 2023 at 03:03:15PM -0800, ron minnich wrote: > I learned a lesson: people love their shell scripting languages. Nobody > wanted to script with Go. It made me sad, but that's how it Go-es. Speaking as someone who has written and maintaining thousands of lines of bash shell script to support file system testing[1] for Linux, there's a really simple reason for it. In order to manipulate GCE VM's, it's just **way** easier to do it from a shell. [1] https://thunk.org/gce-xfstests Compare: gcloud compute instances create VM_NAME \ [--image=IMAGE | --image-family=IMAGE_FAMILY] \ --image-project=IMAGE_PROJECT --machine-type=MACHINE_TYPE with the equivalent in in other "real languages", per [2]. It's 53 lines of C++, 64 lines of Go code, or 100 lines in Java, or 242(!) lines in Python. [2] https://cloud.google.com/compute/docs/instances/create-start-instance#expandable-1 Sure, it might a few thousands lines of codes of bash script. But it would probably be tens of thousands of lines in Go or Python. Furthermore, when I'm trying to experiment with how to experiment with various GCE SDK interfaces, using gcloud and shell is way, way faster than trying to experiment with writing go code, multiple rounds of trying to compile the go code, fixing compile syntax errors, etc --- versus typing a few hundreds characters of a single gcloud command line, and adjusting CLI options untll it does what you want. For my use case, I **really** only care about it running on Linux, since it's being used to test Linux file system kernel code. I have a job I'm trying to get done, which is to write reliable ext4 file system code. Implementing kvm-xfstests[2], gce-xfstests[3], and android-xfstests[4] are just a means to an end. [2] https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-quickstart.md [3] https://github.com/tytso/xfstests-bld/blob/master/Documentation/gce-xfstests.md [4] https://github.com/tytso/xfstests-bld/blob/master/Documentation/android-xfstests.md My time is valuable, and I'm not getting paid to write a general file system test framework that could potentially work on FreeBSD or NetBSD. If my developer velocity is faster by implementing it in bash, that's what I'm going to do, since time spent rewriting gce-xfstests in go or Python is time that I can't spend doing work on the ext4 file system. If someone wants to try to reimplementing my bash scripts in go, they should feel free to send a patch. :-) - Ted From joseph at josephholsten.com Wed Jan 4 19:00:25 2023 From: joseph at josephholsten.com (Joseph Holsten) Date: Wed, 4 Jan 2023 01:00:25 -0800 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <202301022358.302NwiKJ492165@darkstar.fourwinds.com> References: <202301022358.302NwiKJ492165@darkstar.fourwinds.com> Message-ID: <2BD6F8CE-4EE3-49E1-9780-6BE299AD4BCA@josephholsten.com> > On Jan 2, 2023, at 15:59, Jon Steinhart wrote: > > segaloco via TUHS writes: >> I think that's a good point that scripting problems may be >> a symptom of the nature of the tools being used in them. > > To the best of my recollection, scripting languages were originally > intended and used for the automation of repetitive personal tasks; > making it easier for users who found themselves typing the same > stuff over and over again. Somewhere along the line people forgot > how to use a compiler and began writing large systems in a variety > of roughly equivalent but incompatible interpreted languages. I used to think this was a somewhat modern thing, at least evident by atrocities performed by tcl & perl in the 1990s. But exposure to this group of weirdos has made me realize that somewhat terrifying amounts of “infrastructure” code is built on little languages like awk or ed scripts. And that any criticism of the horrible things I use Ruby for today only really defends the place for awk and sed that those now hold and where they truly excel. But then I read https://www.bell-labs.com/usr/dmr/www/qed.html > For a brief period in the 1970s, the GECOS QED served us as a scripting language; it was in some ways analogous to the Awk or Perl of today. It was used for such tasks as submitting batch jobs, formatting files for the printer, collecting statistics on a file. A collection of macros to do various useful tasks was put in a commonly available place. I truly hope in my heart of hearts that ken had no inkling that someday QED would be used as the scripting language to power http://www.qef.com/html/quickref.html. Not that QEF is bad, just that any stones thrown at “you shouldn’t use $lang for that!” feel like they must only strike via ricochet off QEF. I can only imagine the shock and horror Larry McVoy would experience if one of his team suggested replacing make with QEF. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph at josephholsten.com Wed Jan 4 19:18:55 2023 From: joseph at josephholsten.com (Joseph Holsten) Date: Wed, 4 Jan 2023 01:18:55 -0800 Subject: [TUHS] Command Line Editing in the Terminal Driver (Was: A few comments on porting the Bourne shell) In-Reply-To: References: Message-ID: > On Jan 3, 2023, at 08:55, Marshall Conover wrote: > > Along these lines but not quite, Jupyter Notebooks have stood out to me as another approach to this concept, with behavior I'd like to see implemented in a shell. … > Currently these are used primarily for demonstrating APIs, exploring data with python, or writing quick PoCs that can then be extracted into an application. Some companies, such as Netflix, have experimented with using them entirely as a replacement for shell scripts, which is the sort of research I'd most love to see. … > I'd love to see experimentation with a whole system that takes the jupyter approach, with nested namespaces forming applications, combined with data being held in "blocks" as well as code - much like acme opens and edits files as well as letting you execute either them or snippets in them. I think there's a chance something could be developed that would better fit the way we interface with computers today, and the underlying engine approach would move us toward the "everything speaks one language" design we lost in the move from shells to standalone GUI applications. This sounds tremendously useful. It gets at that feeling I want to have from emacs and literate programming but rarely achieve, the sense of Living Text. From ori at heliconbooks.com Wed Jan 4 22:39:14 2023 From: ori at heliconbooks.com (Ori Idan) Date: Wed, 4 Jan 2023 14:39:14 +0200 Subject: [TUHS] AT&T UNIX PC (7300) Teardown and Restoration In-Reply-To: References: <371F8C4D-AAAC-4CD9-9547-3A7AC0C961D0@atvetsystems.com> Message-ID: First check using a scope that you have clock signal (on the PCB) this will show if the hardware works or not. As for the serial port, test what level do you have there, I'd expect a level of around -10V -- Ori Idan CEO Helicon Books http://www.heliconbooks.com On Wed, Jan 4, 2023 at 2:58 AM Warner Losh wrote: > > https://www.amazon.com/NOYITO-Module-Conversion-Arduino-communicates/dp/B07BJJ1T5G > > is my go-to for when I need a simple one, though something like > > > https://www.amazon.com/NOYITO-Module-Conversion-Arduino-communicates/dp/B07BJJ3TZR > > might work better for your setup if you just have more of the TTL gear > than RS-232 gear (I have way too many old RS-232 cables because I never > know when I'll need them again...) > > Warner > > On Tue, Jan 3, 2023 at 5:46 PM segaloco wrote: > >> Nope, unfortunately I only know as much as is needed to plug into the >> GPIO RX/TX/GND working on single boards. I wouldn't be surprised if my >> assumption I just run these pins into the D-25 in the right holes is >> bunk...but that's how we learn sometimes. Once I move I should be able to >> setup a proper work bench where I can tinker on this sort of thing more >> intentionally rather than haphazardly. So perhaps a silly question for an >> expert but a valid one for me. I'll chase that angle and see if it bears >> fruit. >> >> - Matt G. >> ------- Original Message ------- >> On Tuesday, January 3rd, 2023 at 4:40 PM, Warner Losh >> wrote: >> >> >> >> On Tue, Jan 3, 2023, 5:30 PM segaloco via TUHS wrote: >> >>> I'd love to get my hands on a 3B2 someday, this'll be cool if I can get >>> it going but that'd be a much more robust machine. >>> >>> I'm starting to suspect if there isn't any sort of boot ROM that spits >>> out commentary on the UART and that doesn't get flexed until UNIX is up, I >>> may not be able to get very far. I referred to >>> http://bitsavers.trailing-edge.com/pdf/att/3b1/999-809-010IS_UNIX_PC_Remote_Access_1986.pdf >>> for the serial settings and it appears: >>> >>> 9600 baud, 1 stop bit, no parity, 8 data bits >>> >>> And the relevant pins >>> >>> Pin 1 - GND >>> Pin 2 - RX >>> Pin 3 - TX >>> Pin 4 - RTS >>> Pin 5 - CTS >>> Pin 6 - DSR >>> Pin 7 - GND >>> Pin 8 - DCD >>> Pin 20 - DTR >>> >>> So I've plugged my USB-TTY GND/RX/TX into the relevant pins and setup >>> the necessary tty settings. The manual then suggests if running null modem >>> mode to short pin 4 to 5 and then pins 6, 8, and 20 together, presumably >>> omitting any need for modem signalling from the remote machine, doing basic >>> serial RX/TX. Unfortunately even with all of this bypassing I get nothing >>> out of the RS-232 port. What I don't know is if I could even expect >>> something or if this is unlikely to bear fruit whether the hardware works >>> or not. In any case, if I do get this thing running I'll have a writeup for >>> folks afterwards. If not, then hopefully I can figure out something useful >>> to do with this thing rather than junking it. >>> >> >> Silly question... did you level shift to RS 232 levels? You likely did... >> but if not... >> >> Warner >> >> - Matt G. >>> ------- Original Message ------- >>> On Tuesday, January 3rd, 2023 at 3:53 PM, rob at atvetsystems.com < >>> rob at atvetsystems.com> wrote: >>> >>> Hello Matt, >>> >>> I’ve got one of these in my garage. I bought it about twenty years ago >>> as a working system but when I got it home I noticed that the hard disk >>> wasn’t connected but at some point I’d like to get it and my 3b2/300 >>> working. >>> >>> Regards, Rob. >>> >>> On 3 Jan 2023, at 23:27, segaloco via TUHS wrote: >>> >>> And here are some pictures of the guts. >>> >>> https://imgur.com/a/E1ioxZl >>> >>> Various bits inside date this to late 1985. The good news is it at least >>> turns on, but that's about as far as I've gotten with it. The display never >>> turns on, nor do I hear any sounds indicating it tries to start the CRT. >>> The fans kick on and there it stays until I turn it off. I plugged in a >>> USB-TTY to pins 2, 3, and 7 (RX/TX/GND) and listened at 9600 baud 8 bit 1 >>> stop no parity and got nothing. Swapped the RX/TX, still nothing. Of >>> course, that's all predicated on the assumption there's something there to >>> even interact with. I have little faith that whatever UNIX install was on >>> this is extant. Additionally, it didn't come with a keyboard, so if there >>> was some futzing with key combos that would trigger some sort of UART over >>> those lines, I can't do that. I wonder if there are some contacts inside I >>> can just poll for activity with this serial connector, not sure how safe >>> that is... >>> >>> Anywho, the CPU has a bit of corrosion on the surface, not sure how that >>> bodes for the innards, but this is in kinda rough shape either way. I hope >>> I can salvage it but if not, I'm going to at least do some study on the CRT >>> particulars and see if I can extract and keep the monitor from it, been >>> wanting a smaller CRT to have around for a while. >>> >>> - Matt G. >>> ------- Original Message ------- >>> On Tuesday, January 3rd, 2023 at 12:20 PM, segaloco via TUHS < >>> tuhs at tuhs.org> wrote: >>> >>> Good day everyone, just starting a thread for yet another project I'll >>> be tinkering on over time. Picked up a (presumably broken/untested) 7300 >>> off eBay to at the very least tear down and get some good pictures of and, >>> with some luck, perhaps get working again. >>> >>> https://imgur.com/a/CExzebl >>> >>> Here are some pictures of the exterior for starters. I'll update this >>> thread when I've got pictures of the guts and also with any info I can >>> glean regarding whether this might be salvageable. The rust on the back is >>> pretty nasty but I've seen older/worse start up just fine. >>> >>> - Matt G. >>> >>> >>> >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralph at inputplus.co.uk Thu Jan 5 01:19:52 2023 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Wed, 04 Jan 2023 15:19:52 +0000 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <42B6E514-D210-49D3-A103-351F94563852@gmail.com> References: <20230103201900.oR1Qq%steffen@sdaoden.eu> <325DF7E4-37BE-4432-9447-0B392B57DC69@iitbombay.org> <42B6E514-D210-49D3-A103-351F94563852@gmail.com> Message-ID: <20230104151952.7C2542064E@orac.inputplus.co.uk> Hi Adam, > Bakul Shah wrote: > > In fact I use find (or zsh's **/*) bash(1) also has ‘**’ if ‘shopt -s globstar’. > I was 50 years old before I learned that sort has a -u, so I could > have saved the pipe-through-uniq step. Did you never have a Unix with fine man pages to read? :-) Before info(1). Or ‘The Unix Programming Environment’ mentions sort(1)'s -u on page 106. > I also keep getting told grep has a -r but my finger macros won't stop > typing find . -name \*.py | xargs ... ‘... **/*.py’ using the ‘**’ Bakul mentions above. > (And yes, it's GNU find just about everywhere, so I can do -print0 | > xargs -0 and not have to get fancy with the -I) A lot of the time, POSIX find's ‘-exec foo {} +’ suffices and runs foo with as many arguments as will just fit under argv[]s limits, like xargs by default and unlike find's one-at-a-time behaviour with ‘-exec foo {} \;’. > "I've never seen anyone use a GUI just as a way to keep a > dozen terminal windows open side by side before." Clearly, you're a trendsetter. :-) Tiling window managers are popular, e.g. https://en.wikipedia.org/wiki/I3_(window_manager) -- Cheers, Ralph. From ralph at inputplus.co.uk Thu Jan 5 01:21:02 2023 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Wed, 04 Jan 2023 15:21:02 +0000 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net> <20230102165120.GK25547@mcvoy.com> <20230102174304.GM25547@mcvoy.com> Message-ID: <20230104152102.D8ABA2064E@orac.inputplus.co.uk> Hi John, > Making shell scripts portable means not using pipelines No it doesn't... > because given "foo | bar", kshNN and zsh execute foo in a subshell and > bar in the top-level shell, whereas in other shells, both foo and bar > execute in subshells. ...because a lot of the time that doesn't matter. -- Cheers, Ralph. From ron at ronnatalie.com Thu Jan 5 01:54:37 2023 From: ron at ronnatalie.com (Ron Natalie) Date: Wed, 04 Jan 2023 15:54:37 +0000 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <20230104152102.D8ABA2064E@orac.inputplus.co.uk> References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net> <20230102165120.GK25547@mcvoy.com> <20230102174304.GM25547@mcvoy.com> <20230104152102.D8ABA2064E@orac.inputplus.co.uk> Message-ID: Indeed. MiniUnix had no hardware pipes, but the shell “simulated” it by writing to a intermediate temp file. ------ Original Message ------ >From "Ralph Corderoy" To tuhs at tuhs.org Date 1/4/2023 10:21:02 AM Subject [TUHS] Re: A few comments on porting the Bourne shell >Hi John, > >> Making shell scripts portable means not using pipelines > >No it doesn't... > >> because given "foo | bar", kshNN and zsh execute foo in a subshell and >> bar in the top-level shell, whereas in other shells, both foo and bar >> execute in subshells. > >...because a lot of the time that doesn't matter. > >-- >Cheers, Ralph. From crossd at gmail.com Thu Jan 5 02:15:17 2023 From: crossd at gmail.com (Dan Cross) Date: Wed, 4 Jan 2023 11:15:17 -0500 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net> <20230102165120.GK25547@mcvoy.com> <20230102174304.GM25547@mcvoy.com> Message-ID: On Tue, Jan 3, 2023 at 11:16 PM Bakul Shah wrote: > On Jan 3, 2023, at 7:31 PM, Dan Cross wrote: > > On Tue, Jan 3, 2023 at 10:22 PM John Cowan wrote: > >> Making shell scripts portable means not using pipelines, because given "foo | bar", kshNN and zsh execute foo in a subshell and bar in the top-level shell, whereas in other shells, both foo and bar execute in subshells. (For this reason, Posix allows either behavior.) Not having pipelines is a pretty drastic limitation. > > > > This came up at work just the other day: > > > > echo ' hi ' | sed 's/^ *//;s/ *$//' | read bummer > > echo $bummer > > > > The behavior varies between ksh, zsh, bash, sh. Yay. > > On this example sh, zsh, bash behave the same way on > freebsd. Rather than ban |, I think the lesson is to > *avoid* builtin commands in a pipeline that can affect > shell's environment. I only write /bin/sh scripts in > any case. Interesting. In my testing, `bash` was the odd man out: : doctor; zsh : doctor; echo ' hi ' | sed 's/^ *//;s/ *$//' | read bummer echo $bummer hi : doctor; : doctor; bash : doctor; echo ' hi ' | sed 's/^ *//;s/ *$//' | read bummer echo $bummer : doctor; exit : doctor; ksh : doctor; echo ' hi ' | sed 's/^ *//;s/ *$//' | read bummer : doctor; echo $bummer hi : doctor; : doctor; sh : doctor; echo ' hi ' | sed 's/^ *//;s/ *$//' | read bummer : doctor; echo $bummer hi : doctor; : doctor; That's on illumos. On OpenBSD, neither bash, ksh, or sh produce output, while zsh does. I suspect ksh is pdksh and sh is a link to ksh there, though. ksh93 gives "hi". On FreeBSD, neither bash nor sh produce "hi", but zsh and ksh93 do. Same on DragonFly, macOS and Arch Linux. On 7th edition, I only tried sh; empty output. 4.3BSD gives empty output for /bin/sh. For kicks, neither tcsh nor csh understand `read`; I don't think that *csh has a read-like builtin. This is, of course, a silly example. Most script authors would do something like: bummer=`echo ' hi ' | sed 's/^ *//;s/ *$//'` Or, perhaps even: bummer=$(echo ' hi ' | sed 's/^ *//;s/ *$//') Life's too short and at this point I prefer the latter, but more often than not my fingers are wired for the former. > It is really unfortunate that infix | is so beguiling! > Except for that a Lisp or Scheme based shell would've > been fine and dandy! :-)/2 Whatever happened to `es` ? I guess it died on the vine. It seemed like a nifty idea. I made a concerted effort to use `rc` as my shell on Unix for a little while. Without all the supporting plan9 machinery, though, I gave up. Minimalism is great in an environment that can augment it with useful functionality; outside of that environment, it can be kind of a pain for work-a-day use. - Dan C. From bakul at iitbombay.org Thu Jan 5 04:01:16 2023 From: bakul at iitbombay.org (Bakul Shah) Date: Wed, 4 Jan 2023 10:01:16 -0800 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <20230104151952.7C2542064E@orac.inputplus.co.uk> References: <20230103201900.oR1Qq%steffen@sdaoden.eu> <325DF7E4-37BE-4432-9447-0B392B57DC69@iitbombay.org> <42B6E514-D210-49D3-A103-351F94563852@gmail.com> <20230104151952.7C2542064E@orac.inputplus.co.uk> Message-ID: On Jan 4, 2023, at 7:19 AM, Ralph Corderoy wrote: > > A lot of the time, POSIX find's ‘-exec foo {} +’ suffices and runs > foo with as many arguments as will just fit under argv[]s limits, > like xargs by default and unlike find's one-at-a-time behaviour with > ‘-exec foo {} \;’. I often run further transformations before executing some command on selected files. For example find . -type f -name '*.[csh]' | grep -l foo | xargs wc -l Composability rules! From rminnich at gmail.com Thu Jan 5 04:28:52 2023 From: rminnich at gmail.com (ron minnich) Date: Wed, 4 Jan 2023 10:28:52 -0800 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net> <20230102165120.GK25547@mcvoy.com> <20230102174304.GM25547@mcvoy.com> Message-ID: What I see so far from this discussion: Ted has written a lot of useful scripts, but they are explicitly for one shell (bash) on one kernel (linux). I.e. portability is not a concern. People immediately pointed out how easy it is to write non-portable shell scripts, and others commented that it does not matter (to them). Kernel portability matters to me. So does code that works without regard to the shell someone is using. So does robust error handling. So does math. These are all things that, in my experience, rule against complex shell scripts. I still prefer Go as my scripting language, but we all have our preferences. And, yes, Go gets wordy, but it's a price I'm happy to pay for good error handling. I much prefer an error message to 100 lines of python backtrace. On Wed, Jan 4, 2023 at 8:17 AM Dan Cross wrote: > On Tue, Jan 3, 2023 at 11:16 PM Bakul Shah wrote: > > On Jan 3, 2023, at 7:31 PM, Dan Cross wrote: > > > On Tue, Jan 3, 2023 at 10:22 PM John Cowan wrote: > > >> Making shell scripts portable means not using pipelines, because > given "foo | bar", kshNN and zsh execute foo in a subshell and bar in the > top-level shell, whereas in other shells, both foo and bar execute in > subshells. (For this reason, Posix allows either behavior.) Not having > pipelines is a pretty drastic limitation. > > > > > > This came up at work just the other day: > > > > > > echo ' hi ' | sed 's/^ *//;s/ *$//' | read bummer > > > echo $bummer > > > > > > The behavior varies between ksh, zsh, bash, sh. Yay. > > > > On this example sh, zsh, bash behave the same way on > > freebsd. Rather than ban |, I think the lesson is to > > *avoid* builtin commands in a pipeline that can affect > > shell's environment. I only write /bin/sh scripts in > > any case. > > Interesting. In my testing, `bash` was the odd man out: > > : doctor; zsh > : doctor; echo ' hi ' | sed 's/^ *//;s/ *$//' | read bummer > echo $bummer > > hi > : doctor; > : doctor; bash > : doctor; echo ' hi ' | sed 's/^ *//;s/ *$//' | read bummer > echo $bummer > > : doctor; > exit > : doctor; ksh > : doctor; echo ' hi ' | sed 's/^ *//;s/ *$//' | read bummer > : doctor; echo $bummer > hi > : doctor; > : doctor; sh > : doctor; echo ' hi ' | sed 's/^ *//;s/ *$//' | read bummer > : doctor; echo $bummer > hi > : doctor; > : doctor; > > That's on illumos. > > On OpenBSD, neither bash, ksh, or sh produce output, while zsh does. I > suspect ksh is pdksh and sh is a link to ksh there, though. ksh93 > gives "hi". > > On FreeBSD, neither bash nor sh produce "hi", but zsh and ksh93 do. > Same on DragonFly, macOS and Arch Linux. On 7th edition, I only tried > sh; empty output. 4.3BSD gives empty output for /bin/sh. For kicks, > neither tcsh nor csh understand `read`; I don't think that *csh has a > read-like builtin. > > This is, of course, a silly example. Most script authors would do > something like: > > bummer=`echo ' hi ' | sed 's/^ *//;s/ *$//'` > > Or, perhaps even: > > bummer=$(echo ' hi ' | sed 's/^ *//;s/ *$//') > > Life's too short and at this point I prefer the latter, but more often > than not my fingers are wired for the former. > > > It is really unfortunate that infix | is so beguiling! > > Except for that a Lisp or Scheme based shell would've > > been fine and dandy! :-)/2 > > Whatever happened to `es` ? I guess it died on the vine. It seemed > like a nifty idea. > > I made a concerted effort to use `rc` as my shell on Unix for a little > while. Without all the supporting plan9 machinery, though, I gave up. > Minimalism is great in an environment that can augment it with useful > functionality; outside of that environment, it can be kind of a pain > for work-a-day use. > > - Dan C. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chet.ramey at case.edu Thu Jan 5 05:33:13 2023 From: chet.ramey at case.edu (Chet Ramey) Date: Wed, 4 Jan 2023 14:33:13 -0500 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net> <20230102165120.GK25547@mcvoy.com> <20230102174304.GM25547@mcvoy.com> Message-ID: <52d3239f-f9a5-02c2-1a75-e74364d0590f@case.edu> On 1/4/23 11:15 AM, Dan Cross wrote: > On Tue, Jan 3, 2023 at 11:16 PM Bakul Shah wrote: >> On Jan 3, 2023, at 7:31 PM, Dan Cross wrote: >>> On Tue, Jan 3, 2023 at 10:22 PM John Cowan wrote: >>>> Making shell scripts portable means not using pipelines, because given "foo | bar", kshNN and zsh execute foo in a subshell and bar in the top-level shell, whereas in other shells, both foo and bar execute in subshells. (For this reason, Posix allows either behavior.) Not having pipelines is a pretty drastic limitation. >>> >>> This came up at work just the other day: >>> >>> echo ' hi ' | sed 's/^ *//;s/ *$//' | read bummer >>> echo $bummer >>> >>> The behavior varies between ksh, zsh, bash, sh. Yay. >> >> On this example sh, zsh, bash behave the same way on >> freebsd. Rather than ban |, I think the lesson is to >> *avoid* builtin commands in a pipeline that can affect >> shell's environment. I only write /bin/sh scripts in >> any case. > > Interesting. In my testing, `bash` was the odd man out: > > : doctor; zsh > : doctor; echo ' hi ' | sed 's/^ *//;s/ *$//' | read bummer > echo $bummer > > hi > : doctor; > : doctor; bash > : doctor; echo ' hi ' | sed 's/^ *//;s/ *$//' | read bummer > echo $bummer > > : doctor; > exit > : doctor; ksh > : doctor; echo ' hi ' | sed 's/^ *//;s/ *$//' | read bummer > : doctor; echo $bummer > hi > : doctor; > : doctor; sh > : doctor; echo ' hi ' | sed 's/^ *//;s/ *$//' | read bummer > : doctor; echo $bummer > hi > : doctor; > : doctor; > > That's on illumos. On Illumos, /bin/sh and /usr/xpg4/bin/sh are both links to ksh93. ksh88/ksh93 and zsh are the only shells that unconditionally run the last element of a pipeline in the current shell. Bash will do it if job control is not enabled and the `lastpipe' option is enabled. It's usually not a problem, but you do have to be aware of potential side effects. -- ``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 alx.manpages at gmail.com Thu Jan 5 06:46:19 2023 From: alx.manpages at gmail.com (Alejandro Colomar) Date: Wed, 4 Jan 2023 21:46:19 +0100 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <20230103201900.oR1Qq%steffen@sdaoden.eu> <325DF7E4-37BE-4432-9447-0B392B57DC69@iitbombay.org> <42B6E514-D210-49D3-A103-351F94563852@gmail.com> <20230104151952.7C2542064E@orac.inputplus.co.uk> Message-ID: <2b630b83-11de-eff1-d458-d8d145d9f19d@gmail.com> Hello Bakul, Ralph, On 1/4/23 19:01, Bakul Shah wrote: > On Jan 4, 2023, at 7:19 AM, Ralph Corderoy wrote: >> >> A lot of the time, POSIX find's ‘-exec foo {} +’ suffices and runs >> foo with as many arguments as will just fit under argv[]s limits, >> like xargs by default and unlike find's one-at-a-time behaviour with >> ‘-exec foo {} \;’. > > I often run further transformations before executing > some command on selected files. For example > > find . -type f -name '*.[csh]' | grep -l foo | xargs wc -l I find find(1)'s options too complex. I prefer composing even more. I very often find myself writing: find . -type f | grep '\.[ch]$' | grep -l foo | xargs ... > > Composability rules! Yup it does :) For me, the only shell feature that matters is the pipe. I also like using bash(1) for it's pipefail feature (and I also usually enable lastpipe). But things like globbing and regex support, I don't like them at all. I wish shells didn't supoprt globbing, and that glob(1) would be a standalone program still today. It would simplify much of the quoting issues if most characters were just characters to the shell. Cheers, Alex From clemc at ccc.com Thu Jan 5 06:48:02 2023 From: clemc at ccc.com (Clem Cole) Date: Wed, 4 Jan 2023 15:48:02 -0500 Subject: [TUHS] AT&T UNIX PC (7300) Teardown and Restoration In-Reply-To: References: <371F8C4D-AAAC-4CD9-9547-3A7AC0C961D0@atvetsystems.com> Message-ID: Matt - send me an email offline if you need more help. Warner speaks the truth - although he left out some wizardry that has sadly been lost for ages. The first board he offers will create the interface that an IBM PC/AT created which was originally not a standard either (eventually EIA back fit it, in RS 232-E IIRC, but RS-232 C which is what the UNIX PC's interface was defined does not use it]. >From your email, it looks like AT&T out a standard Data Terminal Equipment (DTE) pinning on the back of that system (which would make sense). That means it should be a >>male<< 25 PIN (i.e. male) D style 'B-sized' connector with pins 2 (TX), 4 (RTS), 20 (DTR) being driven; and pins 3 (RX), 5 (CTS), 6 (DSR), 8( DCD), 22 (RI) as inputs. With Pin 7 being the signal reference ground and Pin 1 being the frame ground (often N/C - but do not short to 7 on your board) The signals should swing from +3 volts to up to +30 when assert as a spacing time, and -3 to -30 volts marking time. However, anything over +/- 15 volts is unusual, but the interface is required to accept it. Frankly, +/- 9 volts is most likely what you will see with the 1488/1489 driver pairs which were the preferred chips used in those days. Amazon does not seem to sell an equiv that spits out real RS-232C using the D connector, but rather this PC/AT variant, so you will need to make a cable -- the good news is they do sell: https://www.amazon.com/Kentek-Female-Serial-RS-232-Adapter/dp/B07KVFM4MS My suggestion would be to use this on you Mac/WIndows or Linux box: https://www.amazon.com/Sabrent-Converter-Prolific-Chipset-CB-DB9P/dp/B00IDSM6BW connect it to the cable I just mentioned -- at that point your Mac/Windows/Linux Box will look like a Proper 'terminal' as the being expected then if needed a 25 pin null modem between it that the 3B1 such as: https://www.amazon.com/Monoprice-DB25-Null-Modem-Adaptor/dp/B001VL8RK2 or whatever one you need M/M, M/F -- etc... On Tue, Jan 3, 2023 at 7:58 PM Warner Losh wrote: > > https://www.amazon.com/NOYITO-Module-Conversion-Arduino-communicates/dp/B07BJJ1T5G > > is my go-to for when I need a simple one, though something like > > > https://www.amazon.com/NOYITO-Module-Conversion-Arduino-communicates/dp/B07BJJ3TZR > > might work better for your setup if you just have more of the TTL gear > than RS-232 gear (I have way too many old RS-232 cables because I never > know when I'll need them again...) > > Warner > > On Tue, Jan 3, 2023 at 5:46 PM segaloco wrote: > >> Nope, unfortunately I only know as much as is needed to plug into the >> GPIO RX/TX/GND working on single boards. I wouldn't be surprised if my >> assumption I just run these pins into the D-25 in the right holes is >> bunk...but that's how we learn sometimes. Once I move I should be able to >> setup a proper work bench where I can tinker on this sort of thing more >> intentionally rather than haphazardly. So perhaps a silly question for an >> expert but a valid one for me. I'll chase that angle and see if it bears >> fruit. >> >> - Matt G. >> ------- Original Message ------- >> On Tuesday, January 3rd, 2023 at 4:40 PM, Warner Losh >> wrote: >> >> >> >> On Tue, Jan 3, 2023, 5:30 PM segaloco via TUHS wrote: >> >>> I'd love to get my hands on a 3B2 someday, this'll be cool if I can get >>> it going but that'd be a much more robust machine. >>> >>> I'm starting to suspect if there isn't any sort of boot ROM that spits >>> out commentary on the UART and that doesn't get flexed until UNIX is up, I >>> may not be able to get very far. I referred to >>> http://bitsavers.trailing-edge.com/pdf/att/3b1/999-809-010IS_UNIX_PC_Remote_Access_1986.pdf >>> for the serial settings and it appears: >>> >>> 9600 baud, 1 stop bit, no parity, 8 data bits >>> >>> And the relevant pins >>> >>> Pin 1 - GND >>> Pin 2 - RX >>> Pin 3 - TX >>> Pin 4 - RTS >>> Pin 5 - CTS >>> Pin 6 - DSR >>> Pin 7 - GND >>> Pin 8 - DCD >>> Pin 20 - DTR >>> >>> So I've plugged my USB-TTY GND/RX/TX into the relevant pins and setup >>> the necessary tty settings. The manual then suggests if running null modem >>> mode to short pin 4 to 5 and then pins 6, 8, and 20 together, presumably >>> omitting any need for modem signalling from the remote machine, doing basic >>> serial RX/TX. Unfortunately even with all of this bypassing I get nothing >>> out of the RS-232 port. What I don't know is if I could even expect >>> something or if this is unlikely to bear fruit whether the hardware works >>> or not. In any case, if I do get this thing running I'll have a writeup for >>> folks afterwards. If not, then hopefully I can figure out something useful >>> to do with this thing rather than junking it. >>> >> >> Silly question... did you level shift to RS 232 levels? You likely did... >> but if not... >> >> Warner >> >> - Matt G. >>> ------- Original Message ------- >>> On Tuesday, January 3rd, 2023 at 3:53 PM, rob at atvetsystems.com < >>> rob at atvetsystems.com> wrote: >>> >>> Hello Matt, >>> >>> I’ve got one of these in my garage. I bought it about twenty years ago >>> as a working system but when I got it home I noticed that the hard disk >>> wasn’t connected but at some point I’d like to get it and my 3b2/300 >>> working. >>> >>> Regards, Rob. >>> >>> On 3 Jan 2023, at 23:27, segaloco via TUHS wrote: >>> >>> And here are some pictures of the guts. >>> >>> https://imgur.com/a/E1ioxZl >>> >>> Various bits inside date this to late 1985. The good news is it at least >>> turns on, but that's about as far as I've gotten with it. The display never >>> turns on, nor do I hear any sounds indicating it tries to start the CRT. >>> The fans kick on and there it stays until I turn it off. I plugged in a >>> USB-TTY to pins 2, 3, and 7 (RX/TX/GND) and listened at 9600 baud 8 bit 1 >>> stop no parity and got nothing. Swapped the RX/TX, still nothing. Of >>> course, that's all predicated on the assumption there's something there to >>> even interact with. I have little faith that whatever UNIX install was on >>> this is extant. Additionally, it didn't come with a keyboard, so if there >>> was some futzing with key combos that would trigger some sort of UART over >>> those lines, I can't do that. I wonder if there are some contacts inside I >>> can just poll for activity with this serial connector, not sure how safe >>> that is... >>> >>> Anywho, the CPU has a bit of corrosion on the surface, not sure how that >>> bodes for the innards, but this is in kinda rough shape either way. I hope >>> I can salvage it but if not, I'm going to at least do some study on the CRT >>> particulars and see if I can extract and keep the monitor from it, been >>> wanting a smaller CRT to have around for a while. >>> >>> - Matt G. >>> ------- Original Message ------- >>> On Tuesday, January 3rd, 2023 at 12:20 PM, segaloco via TUHS < >>> tuhs at tuhs.org> wrote: >>> >>> Good day everyone, just starting a thread for yet another project I'll >>> be tinkering on over time. Picked up a (presumably broken/untested) 7300 >>> off eBay to at the very least tear down and get some good pictures of and, >>> with some luck, perhaps get working again. >>> >>> https://imgur.com/a/CExzebl >>> >>> Here are some pictures of the exterior for starters. I'll update this >>> thread when I've got pictures of the guts and also with any info I can >>> glean regarding whether this might be salvageable. The rust on the back is >>> pretty nasty but I've seen older/worse start up just fine. >>> >>> - Matt G. >>> >>> >>> >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Jan 5 06:53:20 2023 From: clemc at ccc.com (Clem Cole) Date: Wed, 4 Jan 2023 15:53:20 -0500 Subject: [TUHS] AT&T UNIX PC (7300) Teardown and Restoration In-Reply-To: References: <371F8C4D-AAAC-4CD9-9547-3A7AC0C961D0@atvetsystems.com> Message-ID: One more thing ... to be fair to Warner: I believe that adding the F/M version of this: https://www.amazon.com/dp/B082VM3SJG should create the traditional electro-mechanical version of a true RS-232C with the board he suggested (and like him I have a few boxes of these things in my basement). I just used Amazon for reference, they used to be sold by most computer stores. ᐧ ᐧ On Wed, Jan 4, 2023 at 3:48 PM Clem Cole wrote: > Matt - send me an email offline if you need more help. Warner speaks the > truth - although he left out some wizardry that has sadly been lost for > ages. > > The first board he offers will create the interface that an IBM PC/AT > created which was originally not a standard either (eventually EIA back fit > it, in RS 232-E IIRC, but RS-232 C which is what the UNIX PC's interface > was defined does not use it]. > > From your email, it looks like AT&T out a standard Data Terminal Equipment > (DTE) pinning on the back of that system (which would make sense). That > means it should be a >>male<< 25 PIN (i.e. male) D style 'B-sized' > connector with pins 2 (TX), 4 (RTS), 20 (DTR) being driven; and pins 3 > (RX), 5 (CTS), 6 (DSR), 8( DCD), 22 (RI) as inputs. With Pin 7 being the > signal reference ground and Pin 1 being the frame ground (often N/C - but > do not short to 7 on your board) > > The signals should swing from +3 volts to up to +30 when assert as a > spacing time, and -3 to -30 volts marking time. However, anything over +/- > 15 volts is unusual, but the interface is required to accept it. > Frankly, +/- 9 volts is most likely what you will see with the 1488/1489 > driver pairs which were the preferred chips used in those days. > > Amazon does not seem to sell an equiv that spits out real RS-232C using > the D connector, but rather this PC/AT variant, so you will need to make a > cable -- the good news is they do sell: > https://www.amazon.com/Kentek-Female-Serial-RS-232-Adapter/dp/B07KVFM4MS > > My suggestion would be to use this on you Mac/WIndows or Linux box: > > https://www.amazon.com/Sabrent-Converter-Prolific-Chipset-CB-DB9P/dp/B00IDSM6BW > connect it to the cable I just mentioned -- at that point your > Mac/Windows/Linux Box will look like a Proper 'terminal' as the being > expected then if needed > > > a 25 pin null modem between it that the 3B1 such as: > https://www.amazon.com/Monoprice-DB25-Null-Modem-Adaptor/dp/B001VL8RK2 or > whatever one you need M/M, M/F -- etc... > > > > On Tue, Jan 3, 2023 at 7:58 PM Warner Losh wrote: > >> >> https://www.amazon.com/NOYITO-Module-Conversion-Arduino-communicates/dp/B07BJJ1T5G >> >> is my go-to for when I need a simple one, though something like >> >> >> https://www.amazon.com/NOYITO-Module-Conversion-Arduino-communicates/dp/B07BJJ3TZR >> >> might work better for your setup if you just have more of the TTL gear >> than RS-232 gear (I have way too many old RS-232 cables because I never >> know when I'll need them again...) >> >> Warner >> >> On Tue, Jan 3, 2023 at 5:46 PM segaloco wrote: >> >>> Nope, unfortunately I only know as much as is needed to plug into the >>> GPIO RX/TX/GND working on single boards. I wouldn't be surprised if my >>> assumption I just run these pins into the D-25 in the right holes is >>> bunk...but that's how we learn sometimes. Once I move I should be able to >>> setup a proper work bench where I can tinker on this sort of thing more >>> intentionally rather than haphazardly. So perhaps a silly question for an >>> expert but a valid one for me. I'll chase that angle and see if it bears >>> fruit. >>> >>> - Matt G. >>> ------- Original Message ------- >>> On Tuesday, January 3rd, 2023 at 4:40 PM, Warner Losh >>> wrote: >>> >>> >>> >>> On Tue, Jan 3, 2023, 5:30 PM segaloco via TUHS wrote: >>> >>>> I'd love to get my hands on a 3B2 someday, this'll be cool if I can get >>>> it going but that'd be a much more robust machine. >>>> >>>> I'm starting to suspect if there isn't any sort of boot ROM that spits >>>> out commentary on the UART and that doesn't get flexed until UNIX is up, I >>>> may not be able to get very far. I referred to >>>> http://bitsavers.trailing-edge.com/pdf/att/3b1/999-809-010IS_UNIX_PC_Remote_Access_1986.pdf >>>> for the serial settings and it appears: >>>> >>>> 9600 baud, 1 stop bit, no parity, 8 data bits >>>> >>>> And the relevant pins >>>> >>>> Pin 1 - GND >>>> Pin 2 - RX >>>> Pin 3 - TX >>>> Pin 4 - RTS >>>> Pin 5 - CTS >>>> Pin 6 - DSR >>>> Pin 7 - GND >>>> Pin 8 - DCD >>>> Pin 20 - DTR >>>> >>>> So I've plugged my USB-TTY GND/RX/TX into the relevant pins and setup >>>> the necessary tty settings. The manual then suggests if running null modem >>>> mode to short pin 4 to 5 and then pins 6, 8, and 20 together, presumably >>>> omitting any need for modem signalling from the remote machine, doing basic >>>> serial RX/TX. Unfortunately even with all of this bypassing I get nothing >>>> out of the RS-232 port. What I don't know is if I could even expect >>>> something or if this is unlikely to bear fruit whether the hardware works >>>> or not. In any case, if I do get this thing running I'll have a writeup for >>>> folks afterwards. If not, then hopefully I can figure out something useful >>>> to do with this thing rather than junking it. >>>> >>> >>> Silly question... did you level shift to RS 232 levels? You likely >>> did... but if not... >>> >>> Warner >>> >>> - Matt G. >>>> ------- Original Message ------- >>>> On Tuesday, January 3rd, 2023 at 3:53 PM, rob at atvetsystems.com < >>>> rob at atvetsystems.com> wrote: >>>> >>>> Hello Matt, >>>> >>>> I’ve got one of these in my garage. I bought it about twenty years ago >>>> as a working system but when I got it home I noticed that the hard disk >>>> wasn’t connected but at some point I’d like to get it and my 3b2/300 >>>> working. >>>> >>>> Regards, Rob. >>>> >>>> On 3 Jan 2023, at 23:27, segaloco via TUHS wrote: >>>> >>>> And here are some pictures of the guts. >>>> >>>> https://imgur.com/a/E1ioxZl >>>> >>>> Various bits inside date this to late 1985. The good news is it at >>>> least turns on, but that's about as far as I've gotten with it. The display >>>> never turns on, nor do I hear any sounds indicating it tries to start the >>>> CRT. The fans kick on and there it stays until I turn it off. I plugged in >>>> a USB-TTY to pins 2, 3, and 7 (RX/TX/GND) and listened at 9600 baud 8 bit 1 >>>> stop no parity and got nothing. Swapped the RX/TX, still nothing. Of >>>> course, that's all predicated on the assumption there's something there to >>>> even interact with. I have little faith that whatever UNIX install was on >>>> this is extant. Additionally, it didn't come with a keyboard, so if there >>>> was some futzing with key combos that would trigger some sort of UART over >>>> those lines, I can't do that. I wonder if there are some contacts inside I >>>> can just poll for activity with this serial connector, not sure how safe >>>> that is... >>>> >>>> Anywho, the CPU has a bit of corrosion on the surface, not sure how >>>> that bodes for the innards, but this is in kinda rough shape either way. I >>>> hope I can salvage it but if not, I'm going to at least do some study on >>>> the CRT particulars and see if I can extract and keep the monitor from it, >>>> been wanting a smaller CRT to have around for a while. >>>> >>>> - Matt G. >>>> ------- Original Message ------- >>>> On Tuesday, January 3rd, 2023 at 12:20 PM, segaloco via TUHS < >>>> tuhs at tuhs.org> wrote: >>>> >>>> Good day everyone, just starting a thread for yet another project I'll >>>> be tinkering on over time. Picked up a (presumably broken/untested) 7300 >>>> off eBay to at the very least tear down and get some good pictures of and, >>>> with some luck, perhaps get working again. >>>> >>>> https://imgur.com/a/CExzebl >>>> >>>> Here are some pictures of the exterior for starters. I'll update this >>>> thread when I've got pictures of the guts and also with any info I can >>>> glean regarding whether this might be salvageable. The rust on the back is >>>> pretty nasty but I've seen older/worse start up just fine. >>>> >>>> - Matt G. >>>> >>>> >>>> >>>> >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Thu Jan 5 10:06:10 2023 From: cowan at ccil.org (John Cowan) Date: Wed, 4 Jan 2023 19:06:10 -0500 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <2b630b83-11de-eff1-d458-d8d145d9f19d@gmail.com> References: <20230103201900.oR1Qq%steffen@sdaoden.eu> <325DF7E4-37BE-4432-9447-0B392B57DC69@iitbombay.org> <42B6E514-D210-49D3-A103-351F94563852@gmail.com> <20230104151952.7C2542064E@orac.inputplus.co.uk> <2b630b83-11de-eff1-d458-d8d145d9f19d@gmail.com> Message-ID: On Wed, Jan 4, 2023 at 3:47 PM Alejandro Colomar wrote: I wish shells didn't supoprt globbing, and that glob(1) would be a > standalone > program still today. It would simplify much of the quoting issues if most > characters were just characters to the shell. > I like the way the rc shell works: globbing is done, but any word in single quotes suppresses all interpretation (double quote has no meaning) -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Thu Jan 5 10:41:29 2023 From: athornton at gmail.com (Adam Thornton) Date: Wed, 4 Jan 2023 17:41:29 -0700 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <20230103201900.oR1Qq%steffen@sdaoden.eu> <325DF7E4-37BE-4432-9447-0B392B57DC69@iitbombay.org> <42B6E514-D210-49D3-A103-351F94563852@gmail.com> <20230104151952.7C2542064E@orac.inputplus.co.uk> <2b630b83-11de-eff1-d458-d8d145d9f19d@gmail.com> Message-ID: I was today years old when I learned that GNU sort has a -h option. Which doesn't mean "help" but means "use human-friendly units." Except I sort of derived its existence from first principles. Someone wanted a way to find disk hogs (they were on a Linux box), but also wanted SI units, and I said to myself, "self, doesn't that sound like exactly the sort of baroque and vaguely nauseating option that GNU would add to sort?" Turns out it is. Well, I mean, the MacOS man page just says that -h is an extension to POSIX (yes, it's there on MacOS too), but I will eat a small hat of mine if it didn't come to sort via GNU. Adam On Wed, Jan 4, 2023 at 5:07 PM John Cowan wrote: > > > On Wed, Jan 4, 2023 at 3:47 PM Alejandro Colomar > wrote: > > I wish shells didn't supoprt globbing, and that glob(1) would be a >> standalone >> program still today. It would simplify much of the quoting issues if >> most >> characters were just characters to the shell. >> > > I like the way the rc shell works: globbing is done, but any word in > single quotes suppresses all interpretation (double quote has no meaning) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alx.manpages at gmail.com Thu Jan 5 11:51:28 2023 From: alx.manpages at gmail.com (Alejandro Colomar) Date: Thu, 5 Jan 2023 02:51:28 +0100 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: Message-ID: On 1/4/23 02:29, Adam Thornton wrote: >> On Jan 3, 2023, at 10:26 AM, Dan Cross wrote: >> >> >> A few years ago, I was having lunch with some folks from the Go team >> and one of them remarked, "you shouldn't write a shell script that's >> longer than about 10 lines. Once you do, it's time to rewrite it in a >> real programming language." I was a bit taken aback, but they had a >> point. I'll note that Go standardized on using bash everywhere. I have many counterexamples that take more than 10 lines. I'll show a couple that are very useful to me: # man_section() prints specific manual page sections (DESCRIPTION, SYNOPSIS, # ...) of all manual pages in a directory (or in a single manual page file). # Usage example: .../man-pages$ man_section man2 SYNOPSIS 'SEE ALSO'; man_section() { if [ $# -lt 2 ]; then >&2 echo "Usage: ${FUNCNAME[0]}
..."; return $EX_USAGE; fi local page="$1"; shift; local sect="$*"; find "$page" -type f \ |xargs wc -l \ |grep -v -e '\b1 ' -e '\btotal\b' \ |awk '{ print $2 }' \ |sort \ |while read -r manpage; do (sed -n '/^\.TH/,/^\.SH/{/^\.SH/!p}' <"$manpage"; for s in $sect; do <"$manpage" \ sed -n \ -e "/^\.SH $s/p" \ -e "/^\.SH $s/,/^\.SH/{/^\.SH/!p}"; done;) \ |man -P cat -l - 2>/dev/null; done; } I don't think it's unreadable by being too long, and in every other language it would take a lot more work to implement. And here's another one, which I used a lot until I wrote grepc(1)[1]: # grep_syscall() finds the prototype of a syscall in the kernel sources, # printing the filename, line number, and the prototype. # It should be run from the root of the linux kernel source tree. # Usage example: .../linux$ grep_syscall openat2; # # See also: grepc(1) grep_syscall() { if [ $# -ne 1 ]; then >&2 echo "Usage: ${FUNCNAME[0]} "; return $EX_USAGE; fi find ./* -type f \ |grep '\.c$' \ |xargs grep -l "$1" \ |sort \ |xargs pcregrep -Mn "(?s)^\w*SYSCALL_DEFINE.\($1\b.*?\)" \ |sed -E 's/^[^:]+:[0-9]+:/&\n/'; find ./* -type f \ |grep '\.[ch]$' \ |xargs grep -l "$1" \ |sort \ |xargs pcregrep -Mn "(?s)^asmlinkage\s+[\w\s]+\**sys_$1\s*\(.*?\)" \ |sed -E 's/^[^:]+:[0-9]+:/&\n/'; } Cheers, Alex [1]: > > > My number is larger than 10, but it's smaller than 100. From tuhs at tuhs.org Thu Jan 5 23:22:10 2023 From: tuhs at tuhs.org (Tom Ivar Helbekkmo via TUHS) Date: Thu, 05 Jan 2023 14:22:10 +0100 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: <202301031719.303HJq6A540885@darkstar.fourwinds.com> (Jon Steinhart's message of "Tue, 3 Jan 2023 09:19:52 -0800") References: <3a891e61-a8b1-cfe4-95ab-c60e6ac6eb42@gmail.com> <202301031719.303HJq6A540885@darkstar.fourwinds.com> Message-ID: Jon Steinhart writes: > Wow! Small programs that do one thing and do it well connected together to > do more complicated things? What an awesome idea :-) *grin* Sometimes people call it "screen scraping", and seem to think it's wrong to desire parseable output from commands. I like to point them at this: https://www.youtube.com/watch?v=tc4ROCJYbm0&t=358 -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 crossd at gmail.com Fri Jan 6 04:23:59 2023 From: crossd at gmail.com (Dan Cross) Date: Thu, 5 Jan 2023 13:23:59 -0500 Subject: [TUHS] Unix documents on github. Message-ID: Someone dumped a bunch of Unix/Plan 9/FORTRAN/FOCAL documents on github: https://github.com/kenmartin-unix/UnixDocs I haven't looked at them closely to see what may be there, but this may interest some TUHS readers. - Dan C. From robpike at gmail.com Fri Jan 6 07:11:42 2023 From: robpike at gmail.com (Rob Pike) Date: Fri, 6 Jan 2023 08:11:42 +1100 Subject: [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <3a891e61-a8b1-cfe4-95ab-c60e6ac6eb42@gmail.com> <202301031719.303HJq6A540885@darkstar.fourwinds.com> Message-ID: In the v8 shell, the "whatis" command's output is all parseable by the shell to recreate the item being identified. For instance, "whatis HOME" would print HOME=/usr/rob while "whatis cd" would print builtin cd and so on. I failed to convince POSIX or other forces to adopt this, and to this day remain puzzled why people couldn't see its value, even though of course not having an editable typescript does limit the flexibility somewhat. Plan 9 happened soon after. -rob On Fri, Jan 6, 2023 at 12:22 AM Tom Ivar Helbekkmo via TUHS wrote: > Jon Steinhart writes: > > > Wow! Small programs that do one thing and do it well connected together > to > > do more complicated things? What an awesome idea :-) > > *grin* > > Sometimes people call it "screen scraping", and seem to think it's wrong > to desire parseable output from commands. I like to point them at this: > > https://www.youtube.com/watch?v=tc4ROCJYbm0&t=358 > > -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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fjarlq at gmail.com Sun Jan 8 17:36:53 2023 From: fjarlq at gmail.com (Matt Day) Date: Sun, 8 Jan 2023 00:36:53 -0700 Subject: [TUHS] C with Classes reference manual In-Reply-To: References: Message-ID: The cppreference.com wiki says "1982: C with Classes reference manual published", but so far I haven't been able to track that down. Is that the correct title? https://en.cppreference.com/w/cpp/language/history There are at least these two papers from that time period: Stroustrup, Bjarne. "Classes: an abstract data type facility for the C language." ACM Sigplan Notices 17.1 (1982): 42-51. https://doi.org/10.1145/947886.947893 Stroustrup, Bjarne. "Adding classes to the C language: An exercise in language evolution." Software: Practice and Experience 13.2 (1983): 139-161. https://doi.org/10.1002/spe.4380130205 On Thu, Dec 8, 2022 at 11:33 AM Ron Natalie wrote: > Here’s a stretch, but does anybody have a copy of the 1982-ish C With > Classes Reference Manual kicking around. I can take it in n/troff or a > more modern format if you have it. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmhanson at eschatologist.net Wed Jan 11 12:51:07 2023 From: cmhanson at eschatologist.net (Chris Hanson) Date: Tue, 10 Jan 2023 18:51:07 -0800 Subject: [TUHS] Command Line Editing in the Terminal Driver In-Reply-To: <7w5ydohe2c.fsf@junk.nocrew.org> References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <8ca17d52-a25a-dbbf-e1f0-d743b8884cfa@in-ulm.de> <7w5ydohe2c.fsf@junk.nocrew.org> Message-ID: <9714D2FE-0737-490B-8470-323155D5B9DE@eschatologist.net> On Jan 2, 2023, at 12:33 PM, Lars Brinkhoff wrote: > > Joseph Holsten wrote: >> Anyone seen any other “terminal drivers” that provide a pleasant >> alternative to line editing? > > The Stanford AI lab PDP-10 operating system had line editing built in, > and the E editor integrated with this. Some operating systems like HP's MPE (and probably also Tandem GUARDIAN) just expected the use of block-mode terminals for purposes of I/O efficiency since interactive use was typically via forms-based applications, and got line editing somewhat as a side-effect. -- Chris From cmhanson at eschatologist.net Wed Jan 11 12:56:48 2023 From: cmhanson at eschatologist.net (Chris Hanson) Date: Tue, 10 Jan 2023 18:56:48 -0800 Subject: [TUHS] Command Line Editing in the Terminal Driver (Was: A few comments on porting the Bourne shell) In-Reply-To: References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <8ca17d52-a25a-dbbf-e1f0-d743b8884cfa@in-ulm.de> Message-ID: On Jan 3, 2023, at 8:53 AM, Marshall Conover wrote: > > With these notebooks, users type text into blocks, and then can have these blocks evaluated by some underlying engine, with the results of the evaluation showing up in a block underneath where they entered text. Results can be not only text, but things like rendered charts and images. There may be GUI-interactable rendered elements as well, but I'm unsure. This is basically the model created by Symbolics for Dynamic Windows, which was the basis for CLIM, and which I believe they also adopted in the Symbolics distribution of MACSYMA. Kalman Reti does a great job demonstrating it under OpenGenera here: https://www.youtube.com/watch?v=o4-YnLpLgtk (Jupyter notebooks are a derivative of Mathematica notebooks, which bear more than a passing resemblance to the Dynamic Windows stuff just like Mathematica bears more than a passing resemblance to McCarthy's "M-expressions" and the MACSYMA system…) -- Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From grog at lemis.com Wed Jan 11 13:53:29 2023 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Wed, 11 Jan 2023 14:53:29 +1100 Subject: [TUHS] Command Line Editing in the Terminal Driver In-Reply-To: <9714D2FE-0737-490B-8470-323155D5B9DE@eschatologist.net> References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <8ca17d52-a25a-dbbf-e1f0-d743b8884cfa@in-ulm.de> <7w5ydohe2c.fsf@junk.nocrew.org> <9714D2FE-0737-490B-8470-323155D5B9DE@eschatologist.net> Message-ID: <20230111035329.GG47241@eureka.lemis.com> On Tuesday, 10 January 2023 at 18:51:07 -0800, Chris Hanson wrote: > On Jan 2, 2023, at 12:33 PM, Lars Brinkhoff wrote: >> The Stanford AI lab PDP-10 operating system had line editing built in, >> and the E editor integrated with this. > > Some operating systems like HP's MPE (and probably also Tandem > GUARDIAN) just expected the use of block-mode terminals for purposes > of I/O efficiency since interactive use was typically via > forms-based applications, and got line editing somewhat as a > side-effect. Guardian was interesting. The normal connection (from my point of view, anyway) was via a TATM (Tandem Asynchronous Terminal Multiplexer), which buffered the characters, but it didn't interrupt the processor until one of 4 configurable characters were entered (typically CR, abort, end of input). This didn't offer line editing, and the workarounds were painful. There was also a block mode, mainly for end user applications, though the “full screen” editor also used it. 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: 163 bytes Desc: not available URL: From crossd at gmail.com Thu Jan 12 03:11:28 2023 From: crossd at gmail.com (Dan Cross) Date: Wed, 11 Jan 2023 12:11:28 -0500 Subject: [TUHS] In search of SunOS 4-era security advisory. Message-ID: The security vulnerability in question could be briefly summarized as, "Fortran divide-by-zero gives root." I think that was just a specific manifestation of the underlying problem, though. More specifically it was actually due to failure to sanitize state after handling a SIGFPE (and possibly other signals as well?). I have a distinct memory of this, but can no longer find any evidence for it. Did I just make it up from whole cloth, or was this actually a thing? - Dan C. From alec.muffett at gmail.com Thu Jan 12 03:27:53 2023 From: alec.muffett at gmail.com (Alec Muffett) Date: Wed, 11 Jan 2023 17:27:53 +0000 Subject: [TUHS] In search of SunOS 4-era security advisory. In-Reply-To: References: Message-ID: https://vuls.cert.org/confluence/plugins/servlet/mobile?contentId=97124523#content/view/97124523 On Wed, 11 Jan 2023, 17:13 Dan Cross, wrote: > The security vulnerability in question could be briefly summarized as, > "Fortran divide-by-zero gives root." I think that was just a specific > manifestation of the underlying problem, though. More specifically it > was actually due to failure to sanitize state after handling a SIGFPE > (and possibly other signals as well?). > > I have a distinct memory of this, but can no longer find any evidence > for it. Did I just make it up from whole cloth, or was this actually a > thing? > > - Dan C. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Thu Jan 12 03:30:45 2023 From: crossd at gmail.com (Dan Cross) Date: Wed, 11 Jan 2023 12:30:45 -0500 Subject: [TUHS] In search of SunOS 4-era security advisory. In-Reply-To: References: Message-ID: That's it. Thanks, Alec! On Wed, Jan 11, 2023 at 12:28 PM Alec Muffett wrote: > > https://vuls.cert.org/confluence/plugins/servlet/mobile?contentId=97124523#content/view/97124523 > > > > On Wed, 11 Jan 2023, 17:13 Dan Cross, wrote: >> >> The security vulnerability in question could be briefly summarized as, >> "Fortran divide-by-zero gives root." I think that was just a specific >> manifestation of the underlying problem, though. More specifically it >> was actually due to failure to sanitize state after handling a SIGFPE >> (and possibly other signals as well?). >> >> I have a distinct memory of this, but can no longer find any evidence >> for it. Did I just make it up from whole cloth, or was this actually a >> thing? >> >> - Dan C. From rminnich at gmail.com Mon Jan 16 05:09:59 2023 From: rminnich at gmail.com (ron minnich) Date: Sun, 15 Jan 2023 11:09:59 -0800 Subject: [TUHS] Burroughs funded $30, 000 for a port to E-mode stack machine in 1983! Message-ID: I just stumbled across an old letter, from a VP of Burroughs to me and Steve Bartels, authorizing $30,000 for a port of Unix to the E-mode stack machine. I had forgotten getting it. Burroughs was famed for its stack machines. E-mode was a kind of last gasp attempt to save the stack architecture, which failed as far as I know, see this table: http://jack.hoa.org/hoajaa/Burr126b.html I worked as a hardware engineer on the A15. I also had been a Unix user for 7 years at that point and kept pointing out how awful the Burroughs CANDE time-sharing system was, and how much better Unix was. At some point I guess they asked me to put up or shut up. I got that money, and left Burroughs a week later for grad school. Funny note: A15 was Motorola ECL (MECL), and ran at 16 Mhz., considered fast at that time. We used a technique called "stored logic" which was, believe it or not, using MECL RAM to map logic inputs to outputs, i.e. implement combinational logic with SRAM. Kind of nuts, but it worked at the time. We also used a precursor of JTAG to scan it in. Those of you who know JTAG have some idea of how fun this had to be. One side effect of working with MECL is you realized just how well designed the TI 7400 SSI/MSI parts were ... MECL always just felt like an awkward family to design with. Another funny story, pointing to what was about to happen to Burroughs. We had an app that ran for hours on the stack machine. We quick ported it to a VAX, started it up, and headed out to lunch -- "this will take a while, let's go eat." We got to the front door and: "Oh, wait, let me hop back into the office,I forgot my jacket". And, noticed, the program was done in ... about 3 minutes. Not 8 hours. That's when we knew it was game over for Burroughs. If a picture of this letter would be useful in some archive somewhere, let me know, I can send it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From luther at makerlisp.com Mon Jan 16 05:19:19 2023 From: luther at makerlisp.com (Luther Johnson) Date: Sun, 15 Jan 2023 12:19:19 -0700 Subject: [TUHS] Burroughs funded $30, 000 for a port to E-mode stack machine in 1983! In-Reply-To: References: Message-ID: <8c1a6096-bb81-7bee-081b-e4e904202369@makerlisp.com> Well, FPGAs use SRAM-based look-up tables to do their combinational logic functions - so not that crazy - if it works and gives good enough results for the task at hand, people will find ways of using the technique. But I imagine there were a host of other things that weren't done as well as possible that added up to 8 hours vs. 3 minutes. On 01/15/2023 12:09 PM, ron minnich wrote: > I just stumbled across an old letter, from a VP of Burroughs to me and > Steve Bartels, authorizing $30,000 for a port of Unix to the E-mode > stack machine. I had forgotten getting it. > > Burroughs was famed for its stack machines. E-mode was a kind of last > gasp attempt to save the stack architecture, which failed as far as I > know, see this table: > http://jack.hoa.org/hoajaa/Burr126b.html > > I worked as a hardware engineer on the A15. I also had been a Unix > user for 7 years at that point and kept pointing out how awful the > Burroughs CANDE time-sharing system was, and how much better Unix was. > At some point I guess they asked me to put up or shut up. I got that > money, and left Burroughs a week later for grad school. > > Funny note: A15 was Motorola ECL (MECL), and ran at 16 Mhz., > considered fast at that time. We used a technique called "stored > logic" which was, believe it or not, using MECL RAM to map logic > inputs to outputs, i.e. implement combinational logic with SRAM. Kind > of nuts, but it worked at the time. We also used a precursor of JTAG > to scan it in. Those of you who know JTAG have some idea of how fun > this had to be. > > One side effect of working with MECL is you realized just how well > designed the TI 7400 SSI/MSI parts were ... MECL always just felt like > an awkward family to design with. > > Another funny story, pointing to what was about to happen to > Burroughs. We had an app that ran for hours on the stack machine. We > quick ported it to a VAX, started it up, and headed out to lunch -- > "this will take a while, let's go eat." We got to the front door and: > "Oh, wait, let me hop back into the office,I forgot my jacket". And, > noticed, the program was done in ... about 3 minutes. Not 8 hours. > > That's when we knew it was game over for Burroughs. > > If a picture of this letter would be useful in some archive somewhere, > let me know, I can send it. > > From rminnich at gmail.com Mon Jan 16 10:51:47 2023 From: rminnich at gmail.com (ron minnich) Date: Sun, 15 Jan 2023 16:51:47 -0800 Subject: [TUHS] Burroughs funded $30, 000 for a port to E-mode stack machine in 1983! In-Reply-To: References: Message-ID: https://web.archive.org/web/20130521183231/http://jack.hoa.org/hoajaa/BurrMain.html has the burroughs info. On Sun, Jan 15, 2023 at 11:09 AM ron minnich wrote: > I just stumbled across an old letter, from a VP of Burroughs to me and > Steve Bartels, authorizing $30,000 for a port of Unix to the E-mode stack > machine. I had forgotten getting it. > > Burroughs was famed for its stack machines. E-mode was a kind of last gasp > attempt to save the stack architecture, which failed as far as I know, see > this table: > http://jack.hoa.org/hoajaa/Burr126b.html > > I worked as a hardware engineer on the A15. I also had been a Unix user > for 7 years at that point and kept pointing out how awful the Burroughs > CANDE time-sharing system was, and how much better Unix was. At some point > I guess they asked me to put up or shut up. I got that money, and left > Burroughs a week later for grad school. > > Funny note: A15 was Motorola ECL (MECL), and ran at 16 Mhz., considered > fast at that time. We used a technique called "stored logic" which was, > believe it or not, using MECL RAM to map logic inputs to outputs, i.e. > implement combinational logic with SRAM. Kind of nuts, but it worked at the > time. We also used a precursor of JTAG to scan it in. Those of you who know > JTAG have some idea of how fun this had to be. > > One side effect of working with MECL is you realized just how well > designed the TI 7400 SSI/MSI parts were ... MECL always just felt like an > awkward family to design with. > > Another funny story, pointing to what was about to happen to Burroughs. We > had an app that ran for hours on the stack machine. We quick ported it to a > VAX, started it up, and headed out to lunch -- "this will take a while, > let's go eat." We got to the front door and: "Oh, wait, let me hop back > into the office,I forgot my jacket". And, noticed, the program was done in > ... about 3 minutes. Not 8 hours. > > That's when we knew it was game over for Burroughs. > > If a picture of this letter would be useful in some archive somewhere, let > me know, I can send it. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stewart at serissa.com Mon Jan 16 11:59:56 2023 From: stewart at serissa.com (Lawrence Stewart) Date: Sun, 15 Jan 2023 20:59:56 -0500 Subject: [TUHS] Burroughs funded $30, 000 for a port to E-mode stack machine in 1983! In-Reply-To: References: Message-ID: <505BAA50-7298-4AC5-A433-C3D48936A133@serissa.com> I rise to defend the honor of ECL. I had designed with TTL through college and the ‘80s: network cards, graphics controllers, the Etherphone, the CPU modules for the Firefly MicroVAX multiprocessor, and so forth. My early designs were SSI and later ones PAL based mostly (Like in Soul of the New Machine). In 1990 or 1991 Digital Systems Research Center started work on the Alpha Demonstration Unit, intended for software porting. The Alpha EV-3 and EV-4 were I/O compatible with either TTL or ECL levels, so we chose ECL 100K with some of the new ECLinPS stuff and even some custom Gallium Arsenide address drivers for the DRAM arrays. This all let the system run at 100 MHz, to keep up with the 100 or 200 MHz Alphas. The short version is that if you can afford the power, ECL is . Every wire is a transmission line. Every signal is terminated. Almost every part (except the 5 NS cache rams) has complementary outputs. What’s not to like about 350 ps NOR gates? The signal integrity alone makes it worthwhile. The CACM paper is at https://dl.acm.org/doi/10.1145/151220.151225 but the Digital Technical Journal version is on Bitsavers at http://www.bitsavers.org/pdf/dec/dtj/dtj_v04-04_1992.pdf Naturally all the production systems were TTL and CMOS, but that ECL stuff was great fun. We had a local welding shop make 18” cables for the 400 Amps of -4.5v and 200 Amps of -2v terminator power. They said “what kind of a welder is this for anyway? The Unix angle, such as it is, is that the ADU ran OSF-1 and Alpha VMS on different subsets of the CPU and memory boards. Not a hypervisor, but a hard partitioning of resources. There was enough I/O stuff to run three “computers” I think. Earlier I had been a user of the Xerox Dorado, which was 16 MHz ECL (probably MECL) in the early 80’s. It made a wonderful personal computer :). Ken Pier’s retrospective at http://bitsavers.trailing-edge.com/pdf/xerox/parc/techReports/ISL-83-1_A_Retrospective_on_the_Dorado_A_High-Performance_Personal_Computer.pdf talks a bit about debugging on page 32. The Dorado had JTAG like scan logic threaded through it, which made debugging and repair of such a complex beast possible. IIRC quite a lot of work went into the control software for the scan logic, devoting an Alto to having a decent UI for it. -Larry > On 2023, Jan 15, at 7:51 PM, ron minnich wrote: > > https://web.archive.org/web/20130521183231/http://jack.hoa.org/hoajaa/BurrMain.html > > has the burroughs info. > > On Sun, Jan 15, 2023 at 11:09 AM ron minnich > wrote: > I just stumbled across an old letter, from a VP of Burroughs to me and Steve Bartels, authorizing $30,000 for a port of Unix to the E-mode stack machine. I had forgotten getting it. > > Burroughs was famed for its stack machines. E-mode was a kind of last gasp attempt to save the stack architecture, which failed as far as I know, see this table: > http://jack.hoa.org/hoajaa/Burr126b.html > > I worked as a hardware engineer on the A15. I also had been a Unix user for 7 years at that point and kept pointing out how awful the Burroughs CANDE time-sharing system was, and how much better Unix was. At some point I guess they asked me to put up or shut up. I got that money, and left Burroughs a week later for grad school. > > Funny note: A15 was Motorola ECL (MECL), and ran at 16 Mhz., considered fast at that time. We used a technique called "stored logic" which was, believe it or not, using MECL RAM to map logic inputs to outputs, i.e. implement combinational logic with SRAM. Kind of nuts, but it worked at the time. We also used a precursor of JTAG to scan it in. Those of you who know JTAG have some idea of how fun this had to be. > > One side effect of working with MECL is you realized just how well designed the TI 7400 SSI/MSI parts were ... MECL always just felt like an awkward family to design with. > > Another funny story, pointing to what was about to happen to Burroughs. We had an app that ran for hours on the stack machine. We quick ported it to a VAX, started it up, and headed out to lunch -- "this will take a while, let's go eat." We got to the front door and: "Oh, wait, let me hop back into the office,I forgot my jacket". And, noticed, the program was done in ... about 3 minutes. Not 8 hours. > > That's when we knew it was game over for Burroughs. > > If a picture of this letter would be useful in some archive somewhere, let me know, I can send it. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Wed Jan 18 19:43:53 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 18 Jan 2023 02:43:53 -0700 Subject: [TUHS] AIX moved into maintainance mode Message-ID: <202301180943.30I9hrOw030485@freefriends.org> https://www.theregister.com/2023/01/17/unix_is_dead/ FYI. Arnold From phil at ultimate.com Thu Jan 19 00:46:28 2023 From: phil at ultimate.com (Phil Budne) Date: Wed, 18 Jan 2023 09:46:28 -0500 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: <202301180943.30I9hrOw030485@freefriends.org> References: <202301180943.30I9hrOw030485@freefriends.org> Message-ID: <202301181446.30IEkSNt050612@ultimate.com> On the "Unix(TM) is dead" premise: Isn't Apple (Mac) OS still certified? https://www.opengroup.org/openbrand/register/ shows OS 13 From ralph at inputplus.co.uk Thu Jan 19 00:55:54 2023 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Wed, 18 Jan 2023 14:55:54 +0000 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: <202301181446.30IEkSNt050612@ultimate.com> References: <202301180943.30I9hrOw030485@freefriends.org> <202301181446.30IEkSNt050612@ultimate.com> Message-ID: <20230118145554.3B27F20145@orac.inputplus.co.uk> Hi Phil, > On the "Unix(TM) is dead" premise: > Isn't Apple (Mac) OS still certified? > > https://www.opengroup.org/openbrand/register/ > shows OS 13 The fine article ends with ‘Which means that the last officially trademarked commercial UNIX™ is Apple's macOS 13, which underneath the proprietary GUI layer is mostly an open source OS called Darwin anyway. The kernel, XNU, is based on Mach with an in-kernel "Unix server" derived from FreeBSD...’ — https://www.theregister.com/2023/01/17/unix_is_dead/ -- Cheers, Ralph. From arnold at skeeve.com Thu Jan 19 01:13:13 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 18 Jan 2023 08:13:13 -0700 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: <202301180943.30I9hrOw030485@freefriends.org> References: <202301180943.30I9hrOw030485@freefriends.org> Message-ID: <202301181513.30IFDDUJ015224@freefriends.org> Interestingly enough, Phil Hughes, who founded Linux Journal in the early 1990s, predicted that this would happen one day. This was in a private conversation we had. I thought he was crazy, but he was right. arnold at skeeve.com wrote: > https://www.theregister.com/2023/01/17/unix_is_dead/ > > FYI. > > Arnold From lm at mcvoy.com Thu Jan 19 01:14:46 2023 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 18 Jan 2023 07:14:46 -0800 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: <202301181513.30IFDDUJ015224@freefriends.org> References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> Message-ID: <20230118151446.GD2964@mcvoy.com> It makes perfect sense, it's a repeated story, commercial loses out to free. On Wed, Jan 18, 2023 at 08:13:13AM -0700, arnold at skeeve.com wrote: > Interestingly enough, Phil Hughes, who founded Linux Journal > in the early 1990s, predicted that this would happen one day. > This was in a private conversation we had. I thought he > was crazy, but he was right. > > arnold at skeeve.com wrote: > > > https://www.theregister.com/2023/01/17/unix_is_dead/ > > > > FYI. > > > > Arnold -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Thu Jan 19 02:10:34 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 18 Jan 2023 16:10:34 +0000 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: <20230118151446.GD2964@mcvoy.com> References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> Message-ID: I just hope we'll see some attempts at opening up these code bases as time goes on. Seeing as they're no longer going to be pushing new copies and will eventually ramp down maintenance releases, opening up the source would give their end users the ability to potentially float their own improvements if they can't immediately migrate to Linux or BSD. That said, security implications of course, don't want to just hand bad actors a code base to comb for memory unsafety in. Also this article is BSD erasure :(, no mentions of the big three save that OpenServer and Darwin have chunks of FreeBSD in them. I guess Berkeley is just chopped liver... - Matt G. ------- Original Message ------- On Wednesday, January 18th, 2023 at 7:14 AM, Larry McVoy wrote: > It makes perfect sense, it's a repeated story, commercial loses out > to free. > > On Wed, Jan 18, 2023 at 08:13:13AM -0700, arnold at skeeve.com wrote: > > > Interestingly enough, Phil Hughes, who founded Linux Journal > > in the early 1990s, predicted that this would happen one day. > > This was in a private conversation we had. I thought he > > was crazy, but he was right. > > > > arnold at skeeve.com wrote: > > > > > https://www.theregister.com/2023/01/17/unix_is_dead/ > > > > > > FYI. > > > > > > Arnold > > > -- > --- > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From stuff at riddermarkfarm.ca Thu Jan 19 02:19:16 2023 From: stuff at riddermarkfarm.ca (Stuff Received) Date: Wed, 18 Jan 2023 11:19:16 -0500 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> Message-ID: On 2023-01-18 11:10, segaloco via TUHS wrote: > Also this article is BSD erasure :(, no mentions of the big three > save that OpenServer and Darwin have chunks of FreeBSD in them. I > guess Berkeley is just chopped liver... There is a fairly lively debate in the comments section on this and other matters. N. > > - Matt G. > ------- Original Message ------- Reference to https://www.theregister.com/2023/01/17/unix_is_dead/ From lm at mcvoy.com Thu Jan 19 02:19:59 2023 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 18 Jan 2023 08:19:59 -0800 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> Message-ID: <20230118161959.GE2964@mcvoy.com> Pretty unrealistic to expect the users to suddenly have the time to do kernel dev. Solaris opened sourced itself and it's dead. It's a lot of work to maintain and evolve an OS. Windows, MacOS, and Linux seem like the future. As for BSD, they pretty much killed themselves by all the in-fighting and the lack of someone like Linus. That was obvious 30 years ago and it hasn't changed. That's why I switched from BSD to Linux. On Wed, Jan 18, 2023 at 04:10:34PM +0000, segaloco wrote: > I just hope we'll see some attempts at opening up these code bases as time goes on. Seeing as they're no longer going to be pushing new copies and will eventually ramp down maintenance releases, opening up the source would give their end users the ability to potentially float their own improvements if they can't immediately migrate to Linux or BSD. That said, security implications of course, don't want to just hand bad actors a code base to comb for memory unsafety in. > > Also this article is BSD erasure :(, no mentions of the big three save that OpenServer and Darwin have chunks of FreeBSD in them. I guess Berkeley is just chopped liver... > > - Matt G. > > ------- Original Message ------- > On Wednesday, January 18th, 2023 at 7:14 AM, Larry McVoy wrote: > > > > It makes perfect sense, it's a repeated story, commercial loses out > > to free. > > > > On Wed, Jan 18, 2023 at 08:13:13AM -0700, arnold at skeeve.com wrote: > > > > > Interestingly enough, Phil Hughes, who founded Linux Journal > > > in the early 1990s, predicted that this would happen one day. > > > This was in a private conversation we had. I thought he > > > was crazy, but he was right. > > > > > > arnold at skeeve.com wrote: > > > > > > > https://www.theregister.com/2023/01/17/unix_is_dead/ > > > > > > > > FYI. > > > > > > > > Arnold > > > > > > -- > > --- > > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From ron at ronnatalie.com Thu Jan 19 02:27:50 2023 From: ron at ronnatalie.com (Ron Natalie) Date: Wed, 18 Jan 2023 16:27:50 +0000 Subject: [TUHS] Maintenance mode on AIX In-Reply-To: <20230118161959.GE2964@mcvoy.com> References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> Message-ID: The thread with a similar name reminds me of this story. My little company did a lot of special work for IBM (Federal Sector) from putting a second network card into Secure XENIX to porting the 370/PS2 AIX to two i860 cards. Occassionally, we’d get random other IBM hardware dropped on us. One day an RS/6000 showed up. The problem was that they didn’t give us any indication what the logins were (let alone the root password). Being the long time security “investigator” that I was I started poking around at the thing while waiting for IBM to call me back. The thing had a key switch that switched you from power OFF to NORMAL ot a WRENCH icon (maintenance mode). So I powered it up in the wrench mode. The thing booted up Unix but rather than a shell gave some maintenance program. I poked around at the options hoping for something that would be useful for me without luck. One option was to view the documentation so I brought that up and it displayed some text. The neat thing (for me) was that it used ‘more’ to paginate it. Sure enough, when I got to the end of the first page, I could just hit ! at the prompt and get a root shell. It was then pretty easy to get the machine set up to our liking. -Ron From will.senn at gmail.com Thu Jan 19 02:36:48 2023 From: will.senn at gmail.com (Will Senn) Date: Wed, 18 Jan 2023 10:36:48 -0600 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: <20230118161959.GE2964@mcvoy.com> References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> Message-ID: <2f00f9a6-c57d-8490-4066-931ec6e191cd@gmail.com> Hi Larry, I disagree, but only time will tell. I don't think BSD is dead is really a fair statement, unless you're referring to the actual distribution. As a line, I think it's still viable (I run it in several flavors and it works, much more reliably than most linuxes which I also run in multiple flavors). That said, everybody :) it seems, seems to be on the Linux is the future bandwagon with seemingly only a few of us holdouts. Just a couple of days ago I spun up a TrueNAS instance and it was glorious - of course it was CORE, try that with SCALE :). It does seem like the wave favors Windows, Mac, and Linux... But, just cuz they're popular doesn't mean the less popular OSes are dead (I say this as I gaze fondly over towards my KIM-1 clone and think of Monitor. Will On 1/18/23 10:19 AM, Larry McVoy wrote: > Pretty unrealistic to expect the users to suddenly have the time to do > kernel dev. Solaris opened sourced itself and it's dead. > > It's a lot of work to maintain and evolve an OS. Windows, MacOS, and > Linux seem like the future. > > As for BSD, they pretty much killed themselves by all the in-fighting and > the lack of someone like Linus. That was obvious 30 years ago and it > hasn't changed. That's why I switched from BSD to Linux. > > On Wed, Jan 18, 2023 at 04:10:34PM +0000, segaloco wrote: >> I just hope we'll see some attempts at opening up these code bases as time goes on. Seeing as they're no longer going to be pushing new copies and will eventually ramp down maintenance releases, opening up the source would give their end users the ability to potentially float their own improvements if they can't immediately migrate to Linux or BSD. That said, security implications of course, don't want to just hand bad actors a code base to comb for memory unsafety in. >> >> Also this article is BSD erasure :(, no mentions of the big three save that OpenServer and Darwin have chunks of FreeBSD in them. I guess Berkeley is just chopped liver... >> >> - Matt G. >> >> ------- Original Message ------- >> On Wednesday, January 18th, 2023 at 7:14 AM, Larry McVoy wrote: >> >> >>> It makes perfect sense, it's a repeated story, commercial loses out >>> to free. >>> >>> On Wed, Jan 18, 2023 at 08:13:13AM -0700, arnold at skeeve.com wrote: >>> >>>> Interestingly enough, Phil Hughes, who founded Linux Journal >>>> in the early 1990s, predicted that this would happen one day. >>>> This was in a private conversation we had. I thought he >>>> was crazy, but he was right. >>>> >>>> arnold at skeeve.com wrote: >>>> >>>>> https://www.theregister.com/2023/01/17/unix_is_dead/ >>>>> >>>>> FYI. >>>>> >>>>> Arnold >>> >>> -- >>> --- >>> Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From lm at mcvoy.com Thu Jan 19 02:38:40 2023 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 18 Jan 2023 08:38:40 -0800 Subject: [TUHS] Maintenance mode on AIX In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> Message-ID: <20230118163840.GF2964@mcvoy.com> On Wed, Jan 18, 2023 at 04:27:50PM +0000, Ron Natalie wrote: > Occassionally, we???d get random other IBM hardware dropped on us. One day > an RS/6000 showed up. The problem was that they didn???t give us any > indication what the logins were (let alone the root password). Being the > long time security ???investigator??? that I was I started poking around at > the thing while waiting for IBM to call me back. The thing had a key > switch that switched you from power OFF to NORMAL ot a WRENCH icon > (maintenance mode). So I powered it up in the wrench mode. The thing > booted up Unix but rather than a shell gave some maintenance program. I > poked around at the options hoping for something that would be useful for me > without luck. One option was to view the documentation so I brought that > up and it displayed some text. The neat thing (for me) was that it used > ???more??? to paginate it. Sure enough, when I got to the end of the first > page, I could just hit ! at the prompt and get a root shell. It was then > pretty easy to get the machine set up to our liking. Someone once told me that if they had physical access to a Unix box, they would get root. That has been true forever and it's even more true today, pull the root disk, mount it on Linux, drop your ssh keys in there or add a no password root or setuid a shell, whatever, if you can put your hands on it, you can get in. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From lm at mcvoy.com Thu Jan 19 02:42:42 2023 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 18 Jan 2023 08:42:42 -0800 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: <2f00f9a6-c57d-8490-4066-931ec6e191cd@gmail.com> References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> <2f00f9a6-c57d-8490-4066-931ec6e191cd@gmail.com> Message-ID: <20230118164242.GG2964@mcvoy.com> Wishful thinking. An OS needs critical mass in terms of developers. The BSD efforts divided their devs by having multiple efforts. It was very obvious from the beginning that Linux was getting all the developers. Go look at the rate of commits to Linux vs the rate of commits to {Net,Open,Free,DragonFly,etc}BSD. They aren't dead as in nobody does anything to them but they are dead in that very few people use them. Look, Linux users are tiny compared to Windows / MacOS, I think the desktop users is around 1%. BSD users are even more tiny than Linux. On Wed, Jan 18, 2023 at 10:36:48AM -0600, Will Senn wrote: > Hi Larry, > > I disagree, but only time will tell. I don't think BSD is dead is really a > fair statement, unless you're referring to the actual distribution. As a > line, I think it's still viable (I run it in several flavors and it works, > much more reliably than most linuxes which I also run in multiple flavors). > That said, everybody :) it seems, seems to be on the Linux is the future > bandwagon with seemingly only a few of us holdouts. Just a couple of days > ago I spun up a TrueNAS instance and it was glorious - of course it was > CORE, try that with SCALE :). > > It does seem like the wave favors Windows, Mac, and Linux... But, just cuz > they're popular doesn't mean the less popular OSes are dead (I say this as I > gaze fondly over towards my KIM-1 clone and think of Monitor. > > Will > > On 1/18/23 10:19 AM, Larry McVoy wrote: > >Pretty unrealistic to expect the users to suddenly have the time to do > >kernel dev. Solaris opened sourced itself and it's dead. > > > >It's a lot of work to maintain and evolve an OS. Windows, MacOS, and > >Linux seem like the future. > > > >As for BSD, they pretty much killed themselves by all the in-fighting and > >the lack of someone like Linus. That was obvious 30 years ago and it > >hasn't changed. That's why I switched from BSD to Linux. > > > >On Wed, Jan 18, 2023 at 04:10:34PM +0000, segaloco wrote: > >>I just hope we'll see some attempts at opening up these code bases as time goes on. Seeing as they're no longer going to be pushing new copies and will eventually ramp down maintenance releases, opening up the source would give their end users the ability to potentially float their own improvements if they can't immediately migrate to Linux or BSD. That said, security implications of course, don't want to just hand bad actors a code base to comb for memory unsafety in. > >> > >>Also this article is BSD erasure :(, no mentions of the big three save that OpenServer and Darwin have chunks of FreeBSD in them. I guess Berkeley is just chopped liver... > >> > >>- Matt G. > >> > >>------- Original Message ------- > >>On Wednesday, January 18th, 2023 at 7:14 AM, Larry McVoy wrote: > >> > >> > >>>It makes perfect sense, it's a repeated story, commercial loses out > >>>to free. > >>> > >>>On Wed, Jan 18, 2023 at 08:13:13AM -0700, arnold at skeeve.com wrote: > >>> > >>>>Interestingly enough, Phil Hughes, who founded Linux Journal > >>>>in the early 1990s, predicted that this would happen one day. > >>>>This was in a private conversation we had. I thought he > >>>>was crazy, but he was right. > >>>> > >>>>arnold at skeeve.com wrote: > >>>> > >>>>>https://www.theregister.com/2023/01/17/unix_is_dead/ > >>>>> > >>>>>FYI. > >>>>> > >>>>>Arnold > >>> > >>>-- > >>>--- > >>>Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Thu Jan 19 02:48:23 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 18 Jan 2023 16:48:23 +0000 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: <20230118161959.GE2964@mcvoy.com> References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> Message-ID: <3BljvbKLLKuPP5jrdIpFuX6eaXAxDLyXUkPLDtzoAIAzBmLawp-guNKbvU1PP-nqY_qo95aqNB_19AINucW9l5xBXjWO3bWn5gS0gqyl69M=@protonmail.com> I've been waffling between Linux and FreeBSD as a main driver the past few years. While I generally find Linux to be all around more responsive and compatible with hardware, I find configuration and system maintenance much more cut and dry on BSD's in general. /etc feels a bit less like a jumbled mess and I can usually expect things to just "work" whereas Linux sometimes there's some hefty finagling to figure out where distro author X decided to put feature or file Y despite 30 other distros and other UNIXes even putting it in the same place. To be fair, BSDs only win out here due to numbers, of course more Linux distros = more entropy. This is largely the phenomenon that pushed me into building my systems up from scratch moreso then not. Then the only people deciding how my system works are myself and the package authors, not some middle layer of distro managers that all seem to have conflicting ideas of how a UNIX system should work and present itself. If I can do all sorts of fancy desktop things but can't even expect ed(1) and vi(1) to be around, how can it be called a UNIX-like? - Matt G. ------- Original Message ------- On Wednesday, January 18th, 2023 at 8:19 AM, Larry McVoy wrote: > Pretty unrealistic to expect the users to suddenly have the time to do > kernel dev. Solaris opened sourced itself and it's dead. > > It's a lot of work to maintain and evolve an OS. Windows, MacOS, and > Linux seem like the future. > > As for BSD, they pretty much killed themselves by all the in-fighting and > the lack of someone like Linus. That was obvious 30 years ago and it > hasn't changed. That's why I switched from BSD to Linux. > > On Wed, Jan 18, 2023 at 04:10:34PM +0000, segaloco wrote: > > > I just hope we'll see some attempts at opening up these code bases as time goes on. Seeing as they're no longer going to be pushing new copies and will eventually ramp down maintenance releases, opening up the source would give their end users the ability to potentially float their own improvements if they can't immediately migrate to Linux or BSD. That said, security implications of course, don't want to just hand bad actors a code base to comb for memory unsafety in. > > > > Also this article is BSD erasure :(, no mentions of the big three save that OpenServer and Darwin have chunks of FreeBSD in them. I guess Berkeley is just chopped liver... > > > > - Matt G. > > > > ------- Original Message ------- > > On Wednesday, January 18th, 2023 at 7:14 AM, Larry McVoy lm at mcvoy.com wrote: > > > > > It makes perfect sense, it's a repeated story, commercial loses out > > > to free. > > > > > > On Wed, Jan 18, 2023 at 08:13:13AM -0700, arnold at skeeve.com wrote: > > > > > > > Interestingly enough, Phil Hughes, who founded Linux Journal > > > > in the early 1990s, predicted that this would happen one day. > > > > This was in a private conversation we had. I thought he > > > > was crazy, but he was right. > > > > > > > > arnold at skeeve.com wrote: > > > > > > > > > https://www.theregister.com/2023/01/17/unix_is_dead/ > > > > > > > > > > FYI. > > > > > > > > > > Arnold > > > > > > -- > > > --- > > > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat > > > -- > --- > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From will.senn at gmail.com Thu Jan 19 02:57:17 2023 From: will.senn at gmail.com (Will Senn) Date: Wed, 18 Jan 2023 10:57:17 -0600 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: <20230118164242.GG2964@mcvoy.com> References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> <2f00f9a6-c57d-8490-4066-931ec6e191cd@gmail.com> <20230118164242.GG2964@mcvoy.com> Message-ID: <13b87744-306e-7ecc-a0d0-9305d4b7d958@gmail.com> Pretty sure Netflix CDN is still using it as are other vendors in need of stable and fast. Just cuz my neighbor doesn't use it, or joe website hoster doesn't use it doesn't relegate it to the nobody uses it pile. On 1/18/23 10:42 AM, Larry McVoy wrote: > Wishful thinking. An OS needs critical mass in terms of developers. > The BSD efforts divided their devs by having multiple efforts. It > was very obvious from the beginning that Linux was getting all the > developers. Go look at the rate of commits to Linux vs the rate > of commits to {Net,Open,Free,DragonFly,etc}BSD. > > They aren't dead as in nobody does anything to them but they are > dead in that very few people use them. > > Look, Linux users are tiny compared to Windows / MacOS, I think the > desktop users is around 1%. BSD users are even more tiny than Linux. > > On Wed, Jan 18, 2023 at 10:36:48AM -0600, Will Senn wrote: >> Hi Larry, >> >> I disagree, but only time will tell. I don't think BSD is dead is really a >> fair statement, unless you're referring to the actual distribution. As a >> line, I think it's still viable (I run it in several flavors and it works, >> much more reliably than most linuxes which I also run in multiple flavors). >> That said, everybody :) it seems, seems to be on the Linux is the future >> bandwagon with seemingly only a few of us holdouts. Just a couple of days >> ago I spun up a TrueNAS instance and it was glorious - of course it was >> CORE, try that with SCALE :). >> >> It does seem like the wave favors Windows, Mac, and Linux... But, just cuz >> they're popular doesn't mean the less popular OSes are dead (I say this as I >> gaze fondly over towards my KIM-1 clone and think of Monitor. >> >> Will >> >> On 1/18/23 10:19 AM, Larry McVoy wrote: >>> Pretty unrealistic to expect the users to suddenly have the time to do >>> kernel dev. Solaris opened sourced itself and it's dead. >>> >>> It's a lot of work to maintain and evolve an OS. Windows, MacOS, and >>> Linux seem like the future. >>> >>> As for BSD, they pretty much killed themselves by all the in-fighting and >>> the lack of someone like Linus. That was obvious 30 years ago and it >>> hasn't changed. That's why I switched from BSD to Linux. >>> >>> On Wed, Jan 18, 2023 at 04:10:34PM +0000, segaloco wrote: >>>> I just hope we'll see some attempts at opening up these code bases as time goes on. Seeing as they're no longer going to be pushing new copies and will eventually ramp down maintenance releases, opening up the source would give their end users the ability to potentially float their own improvements if they can't immediately migrate to Linux or BSD. That said, security implications of course, don't want to just hand bad actors a code base to comb for memory unsafety in. >>>> >>>> Also this article is BSD erasure :(, no mentions of the big three save that OpenServer and Darwin have chunks of FreeBSD in them. I guess Berkeley is just chopped liver... >>>> >>>> - Matt G. >>>> >>>> ------- Original Message ------- >>>> On Wednesday, January 18th, 2023 at 7:14 AM, Larry McVoy wrote: >>>> >>>> >>>>> It makes perfect sense, it's a repeated story, commercial loses out >>>>> to free. >>>>> >>>>> On Wed, Jan 18, 2023 at 08:13:13AM -0700, arnold at skeeve.com wrote: >>>>> >>>>>> Interestingly enough, Phil Hughes, who founded Linux Journal >>>>>> in the early 1990s, predicted that this would happen one day. >>>>>> This was in a private conversation we had. I thought he >>>>>> was crazy, but he was right. >>>>>> >>>>>> arnold at skeeve.com wrote: >>>>>> >>>>>>> https://www.theregister.com/2023/01/17/unix_is_dead/ >>>>>>> >>>>>>> FYI. >>>>>>> >>>>>>> Arnold >>>>> -- >>>>> --- >>>>> Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From clemc at ccc.com Thu Jan 19 02:59:33 2023 From: clemc at ccc.com (Clem Cole) Date: Wed, 18 Jan 2023 11:59:33 -0500 Subject: [TUHS] Maintenance mode on AIX In-Reply-To: <20230118163840.GF2964@mcvoy.com> References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> <20230118163840.GF2964@mcvoy.com> Message-ID: On Wed, Jan 18, 2023 at 11:39 AM Larry McVoy wrote: > Someone once told me that if they had physical access to a Unix box, they > would get root. That has been true forever and it's even more true today, > pull the root disk, mount it on Linux, drop your ssh keys in there or add > a no password root or setuid a shell, whatever, if you can put your hands > on it, you can get in. > A reasonable point, but I think it really depends on the UNIX implementation I suspect. Current mac OS is pretty well hardened from this, with their current enclaves and needing to boot home to Apple to get keys if things are not 100% right. Not saying you or I can not, but basically means the same cracking tricks you need to use for iPhones. It's not as easy as you describe. The ubiquitous Internet/WiFi changed the rules - as you can start to keep some set of keys somewhere else and then encrypt the local volumes. In fact, one of the things they do if mac OS boot detects that root has been modified (it has a crypto index stored away when it was made read-only), the boot rolls back to the last root snapshot -- since they are all read-only that works. In fact, it is a PITA to update/fix things like traditional scripts (for instance the scripts in the /etc/periodic area). Basically, they make it really unnatural to change the root files system, make a new snapshot and index (I have yet to see it documented although, with much pain, I previously created a procedure that is close -- i.e. it once worked on my pre-Ventura Mac - but currently -- fails, so I need to some more investigation when I can bring this back to the top of the importance/curiosity stack (I have a less than satisfying end around for now so I'm ignoring doing it properly). Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Thu Jan 19 03:08:00 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 18 Jan 2023 17:08:00 +0000 Subject: [TUHS] Maintenance mode on AIX In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> <20230118163840.GF2964@mcvoy.com> Message-ID: Apple's unreasonable hardening has been the latest deterent to my ever wanting to use macOS as a personal driver. I've got a Mac as my daily driver for work, it can happily stay with work until I can decide how the filesystem is laid out and what folders I, as the root user, can and can't interact with from user land. I own my machine, not Apple. - Matt G. ------- Original Message ------- On Wednesday, January 18th, 2023 at 8:59 AM, Clem Cole wrote: > On Wed, Jan 18, 2023 at 11:39 AM Larry McVoy wrote: > >> Someone once told me that if they had physical access to a Unix box, they >> would get root. That has been true forever and it's even more true today, >> pull the root disk, mount it on Linux, drop your ssh keys in there or add >> a no password root or setuid a shell, whatever, if you can put your hands >> on it, you can get in. > > A reasonable point, but I think it really depends on the UNIX implementation I suspect. Current mac OS is pretty well hardened from this, with their current enclaves and needing to boot home to Apple to get keys if things are not 100% right. Not saying you or I can not, but basically means the same cracking tricks you need to use for iPhones. It's not as easy as you describe. > > The ubiquitous Internet/WiFi changed the rules - as you can start to keep some set of keys somewhere else and then encrypt the local volumes. In fact, one of the things they do if mac OS boot detects that root has been modified (it has a crypto index stored away when it was made read-only), the boot rolls back to the last root snapshot -- since they are all read-only that works. In fact, it is a PITA to update/fix things like traditional scripts (for instance the scripts in the /etc/periodic area). Basically, they make it really unnatural to change the root files system, make a new snapshot and index (I have yet to see it documented although, with much pain, I previously created a procedure that is close -- i.e. it once worked on my pre-Ventura Mac - but currently -- fails, so I need to some more investigation when I can bring this back to the top of the importance/curiosity stack (I have a less than satisfying end around for now so I'm ignoring doing it properly). > > Clem > ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Thu Jan 19 03:16:33 2023 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 18 Jan 2023 09:16:33 -0800 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: <13b87744-306e-7ecc-a0d0-9305d4b7d958@gmail.com> References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> <2f00f9a6-c57d-8490-4066-931ec6e191cd@gmail.com> <20230118164242.GG2964@mcvoy.com> <13b87744-306e-7ecc-a0d0-9305d4b7d958@gmail.com> Message-ID: <20230118171633.GH2964@mcvoy.com> Well if you want to use your precious time working on some BSD, by all means, it's your time. I looked at where the BSDs were going 30 years ago and decided that helping Linux would be a better return on investment. I don't say that happily, SunOS was my happy place and it was the best BSD that ever existed. Turning to Linux was not easy but history has shown it to have been the right choice for me. The problem with BSD is a lack of users. Linux has so many more people using it, the chances of one of them finding the problem and getting it fixed, before I hit it, are dramatically higher than the same thing with a BSD release. On Wed, Jan 18, 2023 at 10:57:17AM -0600, Will Senn wrote: > Pretty sure Netflix CDN is still using it as are other vendors in need of > stable and fast. Just cuz my neighbor doesn't use it, or joe website hoster > doesn't use it doesn't relegate it to the nobody uses it pile. > > On 1/18/23 10:42 AM, Larry McVoy wrote: > >Wishful thinking. An OS needs critical mass in terms of developers. > >The BSD efforts divided their devs by having multiple efforts. It > >was very obvious from the beginning that Linux was getting all the > >developers. Go look at the rate of commits to Linux vs the rate > >of commits to {Net,Open,Free,DragonFly,etc}BSD. > > > >They aren't dead as in nobody does anything to them but they are > >dead in that very few people use them. > > > >Look, Linux users are tiny compared to Windows / MacOS, I think the > >desktop users is around 1%. BSD users are even more tiny than Linux. > > > >On Wed, Jan 18, 2023 at 10:36:48AM -0600, Will Senn wrote: > >>Hi Larry, > >> > >>I disagree, but only time will tell. I don't think BSD is dead is really a > >>fair statement, unless you're referring to the actual distribution. As a > >>line, I think it's still viable (I run it in several flavors and it works, > >>much more reliably than most linuxes which I also run in multiple flavors). > >>That said, everybody :) it seems, seems to be on the Linux is the future > >>bandwagon with seemingly only a few of us holdouts. Just a couple of days > >>ago I spun up a TrueNAS instance and it was glorious - of course it was > >>CORE, try that with SCALE :). > >> > >>It does seem like the wave favors Windows, Mac, and Linux... But, just cuz > >>they're popular doesn't mean the less popular OSes are dead (I say this as I > >>gaze fondly over towards my KIM-1 clone and think of Monitor. > >> > >>Will > >> > >>On 1/18/23 10:19 AM, Larry McVoy wrote: > >>>Pretty unrealistic to expect the users to suddenly have the time to do > >>>kernel dev. Solaris opened sourced itself and it's dead. > >>> > >>>It's a lot of work to maintain and evolve an OS. Windows, MacOS, and > >>>Linux seem like the future. > >>> > >>>As for BSD, they pretty much killed themselves by all the in-fighting and > >>>the lack of someone like Linus. That was obvious 30 years ago and it > >>>hasn't changed. That's why I switched from BSD to Linux. > >>> > >>>On Wed, Jan 18, 2023 at 04:10:34PM +0000, segaloco wrote: > >>>>I just hope we'll see some attempts at opening up these code bases as time goes on. Seeing as they're no longer going to be pushing new copies and will eventually ramp down maintenance releases, opening up the source would give their end users the ability to potentially float their own improvements if they can't immediately migrate to Linux or BSD. That said, security implications of course, don't want to just hand bad actors a code base to comb for memory unsafety in. > >>>> > >>>>Also this article is BSD erasure :(, no mentions of the big three save that OpenServer and Darwin have chunks of FreeBSD in them. I guess Berkeley is just chopped liver... > >>>> > >>>>- Matt G. > >>>> > >>>>------- Original Message ------- > >>>>On Wednesday, January 18th, 2023 at 7:14 AM, Larry McVoy wrote: > >>>> > >>>> > >>>>>It makes perfect sense, it's a repeated story, commercial loses out > >>>>>to free. > >>>>> > >>>>>On Wed, Jan 18, 2023 at 08:13:13AM -0700, arnold at skeeve.com wrote: > >>>>> > >>>>>>Interestingly enough, Phil Hughes, who founded Linux Journal > >>>>>>in the early 1990s, predicted that this would happen one day. > >>>>>>This was in a private conversation we had. I thought he > >>>>>>was crazy, but he was right. > >>>>>> > >>>>>>arnold at skeeve.com wrote: > >>>>>> > >>>>>>>https://www.theregister.com/2023/01/17/unix_is_dead/ > >>>>>>> > >>>>>>>FYI. > >>>>>>> > >>>>>>>Arnold > >>>>>-- > >>>>>--- > >>>>>Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From will.senn at gmail.com Thu Jan 19 03:21:16 2023 From: will.senn at gmail.com (Will Senn) Date: Wed, 18 Jan 2023 11:21:16 -0600 Subject: [TUHS] Maintenance mode on AIX In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> <20230118163840.GF2964@mcvoy.com> Message-ID: <1315c448-c8e8-1ae5-ef34-0f7ba3fbb8a7@gmail.com> Wow, we're all over the place on this thread. I stopped updating my Mac with Mojave. Occasionally, I flirt with more recent incarnations and much like with recent Windows incarnations, I scurry back pretty quickly to the stable and fast. ... and Mojave support 32 bit apps, which is nice. It's fast, responsive, and locked down the way I like it. The mutually exclusive goals represented by security/it lockdown obsession and OS phone homeitis is ridiculous. One hopes that this is not a permanent set of affairs. I would prefer my OS to be under my control and secure my information, for me. Lately, I've been doing work with SculptOS on Genode - a capabilities based OS running on a microkernel (trusted computing base). Sculpts got a ways to go, but I like the way the architects are thinking. Will On 1/18/23 11:08 AM, segaloco via TUHS wrote: > Apple's unreasonable hardening has been the latest deterent to my ever > wanting to use macOS as a personal driver.  I've got a Mac as my daily > driver for work, it can happily stay with work until I can decide how > the filesystem is laid out and what folders I, as the root user, can > and can't interact with from user land. I own my machine, not Apple. > > - Matt G. > ------- Original Message ------- > On Wednesday, January 18th, 2023 at 8:59 AM, Clem Cole > wrote: > >> >> >> On Wed, Jan 18, 2023 at 11:39 AM Larry McVoy wrote: >> >> Someone once told me that if they had physical access to a Unix >> box, they >> would get root. That has been true forever and it's even more >> true today, >> pull the root disk, mount it on Linux, drop your ssh keys in >> there or add >> a no password root or setuid a shell, whatever, if you can put >> your hands >> on it, you can get in. >> >> A reasonable point, but I think it really depends on the UNIX >> implementation I suspect. Current mac OS is pretty well hardened from >> this, with their current enclaves and needing to boot home to Apple >> to get keys if things are not 100% right. Not saying you or I can >> not, but basically means the same cracking tricks you need to use for >> iPhones. It's not as easy as you describe. >> >> The ubiquitous Internet/WiFi changed the rules - as you can start to >> keep some set of keys somewhere else and then encrypt the local >> volumes. In fact, one of the things they do if mac OS boot detects >> that root has been modified (it has a crypto index stored away when >> it was made read-only), the boot rolls back to the last root snapshot >> -- since they are all read-only that works. In fact, it is a PITA to >> update/fix things like traditional scripts (for instance the scripts >> in the /etc/periodic area). Basically, they make it really unnatural >> to change the root files system, make a new snapshot and index (I >> have yet to see it documented although, with much pain, I previously >> created a procedure that is close -- i.e. it once worked on my >> pre-Ventura Mac - but currently -- fails, so I need to some more >> investigation when I can bring this back to the top of the >> importance/curiosity stack (I have a less than satisfying end around >> for now so I'm ignoring doing it properly). >> >> Clem >> ᐧ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Thu Jan 19 03:25:32 2023 From: will.senn at gmail.com (Will Senn) Date: Wed, 18 Jan 2023 11:25:32 -0600 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: <20230118171633.GH2964@mcvoy.com> References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> <2f00f9a6-c57d-8490-4066-931ec6e191cd@gmail.com> <20230118164242.GG2964@mcvoy.com> <13b87744-306e-7ecc-a0d0-9305d4b7d958@gmail.com> <20230118171633.GH2964@mcvoy.com> Message-ID: <80641ed1-b0a1-78f8-fabe-83c13b9a9ade@gmail.com> Fair enough, but the worlds a little more forgiving than all that doom and gloom :). If an innovation happens in BSDland, it generally gets ported into Linuxland, in time, and visa versa. I heart linux, don't get me wrong. I just wish they would... On 1/18/23 11:16 AM, Larry McVoy wrote: > Well if you want to use your precious time working on some BSD, by all > means, it's your time. I looked at where the BSDs were going 30 years ago > and decided that helping Linux would be a better return on investment. > I don't say that happily, SunOS was my happy place and it was the best > BSD that ever existed. Turning to Linux was not easy but history has > shown it to have been the right choice for me. > > The problem with BSD is a lack of users. Linux has so many more people > using it, the chances of one of them finding the problem and getting it > fixed, before I hit it, are dramatically higher than the same thing with > a BSD release. > > On Wed, Jan 18, 2023 at 10:57:17AM -0600, Will Senn wrote: >> Pretty sure Netflix CDN is still using it as are other vendors in need of >> stable and fast. Just cuz my neighbor doesn't use it, or joe website hoster >> doesn't use it doesn't relegate it to the nobody uses it pile. >> >> On 1/18/23 10:42 AM, Larry McVoy wrote: >>> Wishful thinking. An OS needs critical mass in terms of developers. >>> The BSD efforts divided their devs by having multiple efforts. It >>> was very obvious from the beginning that Linux was getting all the >>> developers. Go look at the rate of commits to Linux vs the rate >>> of commits to {Net,Open,Free,DragonFly,etc}BSD. >>> >>> They aren't dead as in nobody does anything to them but they are >>> dead in that very few people use them. >>> >>> Look, Linux users are tiny compared to Windows / MacOS, I think the >>> desktop users is around 1%. BSD users are even more tiny than Linux. >>> >>> On Wed, Jan 18, 2023 at 10:36:48AM -0600, Will Senn wrote: >>>> Hi Larry, >>>> >>>> I disagree, but only time will tell. I don't think BSD is dead is really a >>>> fair statement, unless you're referring to the actual distribution. As a >>>> line, I think it's still viable (I run it in several flavors and it works, >>>> much more reliably than most linuxes which I also run in multiple flavors). >>>> That said, everybody :) it seems, seems to be on the Linux is the future >>>> bandwagon with seemingly only a few of us holdouts. Just a couple of days >>>> ago I spun up a TrueNAS instance and it was glorious - of course it was >>>> CORE, try that with SCALE :). >>>> >>>> It does seem like the wave favors Windows, Mac, and Linux... But, just cuz >>>> they're popular doesn't mean the less popular OSes are dead (I say this as I >>>> gaze fondly over towards my KIM-1 clone and think of Monitor. >>>> >>>> Will >>>> >>>> On 1/18/23 10:19 AM, Larry McVoy wrote: >>>>> Pretty unrealistic to expect the users to suddenly have the time to do >>>>> kernel dev. Solaris opened sourced itself and it's dead. >>>>> >>>>> It's a lot of work to maintain and evolve an OS. Windows, MacOS, and >>>>> Linux seem like the future. >>>>> >>>>> As for BSD, they pretty much killed themselves by all the in-fighting and >>>>> the lack of someone like Linus. That was obvious 30 years ago and it >>>>> hasn't changed. That's why I switched from BSD to Linux. >>>>> >>>>> On Wed, Jan 18, 2023 at 04:10:34PM +0000, segaloco wrote: >>>>>> I just hope we'll see some attempts at opening up these code bases as time goes on. Seeing as they're no longer going to be pushing new copies and will eventually ramp down maintenance releases, opening up the source would give their end users the ability to potentially float their own improvements if they can't immediately migrate to Linux or BSD. That said, security implications of course, don't want to just hand bad actors a code base to comb for memory unsafety in. >>>>>> >>>>>> Also this article is BSD erasure :(, no mentions of the big three save that OpenServer and Darwin have chunks of FreeBSD in them. I guess Berkeley is just chopped liver... >>>>>> >>>>>> - Matt G. >>>>>> >>>>>> ------- Original Message ------- >>>>>> On Wednesday, January 18th, 2023 at 7:14 AM, Larry McVoy wrote: >>>>>> >>>>>> >>>>>>> It makes perfect sense, it's a repeated story, commercial loses out >>>>>>> to free. >>>>>>> >>>>>>> On Wed, Jan 18, 2023 at 08:13:13AM -0700, arnold at skeeve.com wrote: >>>>>>> >>>>>>>> Interestingly enough, Phil Hughes, who founded Linux Journal >>>>>>>> in the early 1990s, predicted that this would happen one day. >>>>>>>> This was in a private conversation we had. I thought he >>>>>>>> was crazy, but he was right. >>>>>>>> >>>>>>>> arnold at skeeve.com wrote: >>>>>>>> >>>>>>>>> https://www.theregister.com/2023/01/17/unix_is_dead/ >>>>>>>>> >>>>>>>>> FYI. >>>>>>>>> >>>>>>>>> Arnold >>>>>>> -- >>>>>>> --- >>>>>>> Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From usotsuki at buric.co Thu Jan 19 04:58:40 2023 From: usotsuki at buric.co (Steve Nickolas) Date: Wed, 18 Jan 2023 13:58:40 -0500 (EST) Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> Message-ID: On Wed, 18 Jan 2023, segaloco via TUHS wrote: > I just hope we'll see some attempts at opening up these code bases as > time goes on. Seeing as they're no longer going to be pushing new > copies and will eventually ramp down maintenance releases, opening up > the source would give their end users the ability to potentially float > their own improvements if they can't immediately migrate to Linux or > BSD. That said, security implications of course, don't want to just > hand bad actors a code base to comb for memory unsafety in. Certainly the stuff I've been currently working on would be made even more irrelevant if a complete System V were made available under a license more like BSD than CDDL. -uso. From dave at horsfall.org Thu Jan 19 05:25:20 2023 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 19 Jan 2023 06:25:20 +1100 (EST) Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: <20230118164242.GG2964@mcvoy.com> References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> <2f00f9a6-c57d-8490-4066-931ec6e191cd@gmail.com> <20230118164242.GG2964@mcvoy.com> Message-ID: On Wed, 18 Jan 2023, Larry McVoy wrote: > Look, Linux users are tiny compared to Windows / MacOS, I think the > desktop users is around 1%. BSD users are even more tiny than Linux. They'll have to pry my FreeBSD server from my cold dead hands :-) -- Dave From david at kdbarto.org Thu Jan 19 05:50:16 2023 From: david at kdbarto.org (David Barto) Date: Wed, 18 Jan 2023 11:50:16 -0800 Subject: [TUHS] Maintenance mode on AIX In-Reply-To: <1315c448-c8e8-1ae5-ef34-0f7ba3fbb8a7@gmail.com> References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> <20230118163840.GF2964@mcvoy.com> <1315c448-c8e8-1ae5-ef34-0f7ba3fbb8a7@gmail.com> Message-ID: <08D6905B-E615-4347-BF33-E8C9A7A703B8@kdbarto.org> I think that the situation with MacOS is an (over) reaction to viruses, worms, and the end users themselves. In order to make sure that the normal user doesn’t do something silly to their system Apple has wound up restricting what the more advanced and knowledgeable user can do. I’m in an in-between camp. I like to install what I want and as long as I can do that, MacOS will work for me. And I like that Apple is working to stop the “bad guys” as much as possible. When installing what I want stops happening then I’ll stop upgrading. Until then I’m willing to ride the Apple train. David > On Jan 18, 2023, at 9:21 AM, Will Senn wrote: > > Wow, we're all over the place on this thread. I stopped updating my Mac with Mojave. Occasionally, I flirt with more recent incarnations and much like with recent Windows incarnations, I scurry back pretty quickly to the stable and fast. ... and Mojave support 32 bit apps, which is nice. It's fast, responsive, and locked down the way I like it. > > The mutually exclusive goals represented by security/it lockdown obsession and OS phone homeitis is ridiculous. One hopes that this is not a permanent set of affairs. I would prefer my OS to be under my control and secure my information, for me. > > Lately, I've been doing work with SculptOS on Genode - a capabilities based OS running on a microkernel (trusted computing base). Sculpts got a ways to go, but I like the way the architects are thinking. > > Will > > > On 1/18/23 11:08 AM, segaloco via TUHS wrote: >> Apple's unreasonable hardening has been the latest deterent to my ever wanting to use macOS as a personal driver. I've got a Mac as my daily driver for work, it can happily stay with work until I can decide how the filesystem is laid out and what folders I, as the root user, can and can't interact with from user land. I own my machine, not Apple. >> >> - Matt G. >> ------- Original Message ------- >> On Wednesday, January 18th, 2023 at 8:59 AM, Clem Cole wrote: >> >>> >>> >>> On Wed, Jan 18, 2023 at 11:39 AM Larry McVoy > wrote: >>> Someone once told me that if they had physical access to a Unix box, they >>> would get root. That has been true forever and it's even more true today, >>> pull the root disk, mount it on Linux, drop your ssh keys in there or add >>> a no password root or setuid a shell, whatever, if you can put your hands >>> on it, you can get in. >>> A reasonable point, but I think it really depends on the UNIX implementation I suspect. Current mac OS is pretty well hardened from this, with their current enclaves and needing to boot home to Apple to get keys if things are not 100% right. Not saying you or I can not, but basically means the same cracking tricks you need to use for iPhones. It's not as easy as you describe. >>> >>> The ubiquitous Internet/WiFi changed the rules - as you can start to keep some set of keys somewhere else and then encrypt the local volumes. In fact, one of the things they do if mac OS boot detects that root has been modified (it has a crypto index stored away when it was made read-only), the boot rolls back to the last root snapshot -- since they are all read-only that works. In fact, it is a PITA to update/fix things like traditional scripts (for instance the scripts in the /etc/periodic area). Basically, they make it really unnatural to change the root files system, make a new snapshot and index (I have yet to see it documented although, with much pain, I previously created a procedure that is close -- i.e. it once worked on my pre-Ventura Mac - but currently -- fails, so I need to some more investigation when I can bring this back to the top of the importance/curiosity stack (I have a less than satisfying end around for now so I'm ignoring doing it properly). >>> >>> Clem >>> ᐧ >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From psi at valis.com Thu Jan 19 06:04:19 2023 From: psi at valis.com (Joseph J. Mankoski ***PSI***) Date: Wed, 18 Jan 2023 12:04:19 -0800 Subject: [TUHS] Maintenance mode on AIX In-Reply-To: Message-ID: Hello -- Regarding "appliance-ization" (locking down / dumbing down) of commercially-available computer systems, and returning to the history of Unix (in the context of our current era), I am reminded of Ken Thompson's (excellent and humorous) panel presentation at the ACM Turing 100 conference I attended in 2012, imagining Alan Turing being brought to our time and given a current-generation computer system, etc. The webcast links for the "Systems Architecture" session, etc., on the main conference site, https://turing100.acm.org/, seem to be broken, however the video at this link works for me: https://dl.acm.org/doi/10.1145/2322176.2322182 (Ken's part starts at ~0:09:28.) Cheers, ***PSI*** <<>> tuhs-request at tuhs.org writes: [...] > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 18 Jan 2023 17:08:00 +0000 > From: segaloco > Subject: [TUHS] Re: Maintenance mode on AIX > To: Clem Cole > Cc: tuhs at tuhs.org > Message-ID: ASxWkDZitFw0JIopRVh7BRC2PzLFrF_Gjsb2yCi-uxJ3Yr3AtE=@protonmail.com> > Content-Type: multipart/alternative; > boundary="b1_7WKJsCnT0P2jggZLBLwbL2iRavDFXPykjXdIMPRs" > > Apple's unreasonable hardening has been the latest deterent to my ever wanting to use macOS as a personal driver. I've got a Mac as my daily driver for work, it can happily stay with work until I can decide how the filesystem is laid out and what folders I, as the root user, can and can't interact with from user land. I own my machine, not Apple. > > - Matt G. > ------- Original Message ------- > On Wednesday, January 18th, 2023 at 8:59 AM, Clem Cole wrote: > >> On Wed, Jan 18, 2023 at 11:39 AM Larry McVoy wrote: >> >>> Someone once told me that if they had physical access to a Unix box, they >>> would get root. That has been true forever and it's even more true today, >>> pull the root disk, mount it on Linux, drop your ssh keys in there or add >>> a no password root or setuid a shell, whatever, if you can put your hands >>> on it, you can get in. >> >> A reasonable point, but I think it really depends on the UNIX implementation I suspect. Current mac OS is pretty well hardened from this, with their current enclaves and needing to boot home to Apple to get keys if things are not 100% right. Not saying you or I can not, but basically means the same cracking tricks you need to use for iPhones. It's not as easy as you describe. >> >> The ubiquitous Internet/WiFi changed the rules - as you can start to keep some set of keys somewhere else and then encrypt the local volumes. In fact, one of the things they do if mac OS boot detects that root has been modified (it has a crypto index stored away when it was made read-only), the boot rolls back to the last root snapshot -- since they are all read-only that works. In fact, it is a PITA to update/fix things like traditional scripts (for instance the scripts in the /etc/periodic area). Basically, they make it really unnatural to change the root files system, make a new snapshot and index (I have yet to see it documented although, with much pain, I previously created a procedure that is close -- i.e. it once worked on my pre-Ventura Mac - but currently -- fails, so I need to some more investigation when I can bring this back to the top of the importance/curiosity stack (I have a less than satisfying end around for now so I'm ignoring doing it properly). >> >> Clem >> ᐧ-------------- next part -------------- [...] > ------------------------------ [...] From tuhs at tuhs.org Thu Jan 19 06:34:26 2023 From: tuhs at tuhs.org (Arno Griffioen via TUHS) Date: Wed, 18 Jan 2023 21:34:26 +0100 Subject: [TUHS] Maintenance mode on AIX In-Reply-To: <20230118163840.GF2964@mcvoy.com> References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> <20230118163840.GF2964@mcvoy.com> Message-ID: On Wed, Jan 18, 2023 at 08:38:40AM -0800, Larry McVoy wrote: > Someone once told me that if they had physical access to a Unix box, they > would get root. That has been true forever and it's even more true today, > pull the root disk, mount it on Linux, drop your ssh keys in there or add > a no password root or setuid a shell, whatever, if you can put your hands > on it, you can get in. Until a few years ago, I would definitely agree. Done that regularly in the past. (and worked on lots of network gear too...) However.. Nowadays with a little effort you can make a bootable Linux machine that uses either a passphrase or some external key/dongle/fingerprint/etc. to unlock an encrypted root fs and additional filesystems. If you don't have those credentials, then it's going to be pretty tricky to access as you simply can't even access any of the encrypted filesystems to start with. Yes, you could probably get the initrd booted with a root shell and then wipe the machine/disk to then do what you want, but the original install is getting pretty hard to jump into with boot tricks these days. Bye, Arno. From brad at anduin.eldar.org Thu Jan 19 06:50:46 2023 From: brad at anduin.eldar.org (Brad Spencer) Date: Wed, 18 Jan 2023 15:50:46 -0500 Subject: [TUHS] Maintenance mode on AIX In-Reply-To: (message from Arno Griffioen via TUHS on Wed, 18 Jan 2023 21:34:26 +0100) Message-ID: Arno Griffioen via TUHS writes: > On Wed, Jan 18, 2023 at 08:38:40AM -0800, Larry McVoy wrote: >> Someone once told me that if they had physical access to a Unix box, they >> would get root. That has been true forever and it's even more true today, >> pull the root disk, mount it on Linux, drop your ssh keys in there or add >> a no password root or setuid a shell, whatever, if you can put your hands >> on it, you can get in. > > Until a few years ago, I would definitely agree. Done that regularly > in the past. (and worked on lots of network gear too...) > > However.. > > Nowadays with a little effort you can make a bootable Linux machine that > uses either a passphrase or some external key/dongle/fingerprint/etc. > to unlock an encrypted root fs and additional filesystems. > > If you don't have those credentials, then it's going to be pretty tricky to > access as you simply can't even access any of the encrypted filesystems to > start with. > > Yes, you could probably get the initrd booted with a root shell and > then wipe the machine/disk to then do what you want, but the original > install is getting pretty hard to jump into with boot tricks these days. > > Bye, Arno. Yes++ ... I did something simular with NetBSD a few years ago. I booted a removable drive that asked for the passphrase to decrypt the real root filesystem.. the drive was removed and stored separately from the laptop when at rest. Today, I don't even need a removable drive any more, a ramdisk is attached to the kernel and unpacks itself upon boot and that asks for the passphrase. The root filesystem itself is more or less completely encrypted. Not quite full end to end, but very close. All you could really do is destroy the system, which may be good enough for some, but getting the information off of the encrypted filesystem would be hard. -- Brad Spencer - brad at anduin.eldar.org - KC8VKS - http://anduin.eldar.org From tuhs at tuhs.org Thu Jan 19 07:09:24 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 18 Jan 2023 21:09:24 +0000 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: <80641ed1-b0a1-78f8-fabe-83c13b9a9ade@gmail.com> References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> <2f00f9a6-c57d-8490-4066-931ec6e191cd@gmail.com> <20230118164242.GG2964@mcvoy.com> <13b87744-306e-7ecc-a0d0-9305d4b7d958@gmail.com> <20230118171633.GH2964@mcvoy.com> <80641ed1-b0a1-78f8-fabe-83c13b9a9ade@gmail.com> Message-ID: Something I think would do wonders for UNIX diversity (although I obviously haven't done a feasibility analysis) is a convergence or at least some sort of homogenization of driver interfaces. That is one of the key areas where I think faster movement would have me using BSDs exclusively, but at any given time I can't expect the same hardware support from anything other than the Linux kernel. I'm not in the know on current driver interfaces to know if its apples to apples, apples to oranges, or apples to hypercubes. But still, if *BSD supported the BCM2711 in entirety w/ graphics accel and onboard SDIO-driven wifi, Linux would serve me no advantage at present other than I know how to tune the kernel build a lot better. Granted, driver support is not only implicated here, I'd be a lot more nomadic with operating systems if I knew I could work on hobby projects across the preponderance of them efficiently. At the end of the day I just want a system with a POSIX-friendly kernel that works with all my devices and doesn't have a complicated userland. As of present, GNU/Linux w/ sysvinit is the happy medium, although one of these days I mean to research in earnest if there's a BSD/V7-ish init that actually gels well with Linux+Glibc userspace. - Matt G. ------- Original Message ------- On Wednesday, January 18th, 2023 at 9:25 AM, Will Senn wrote: > Fair enough, but the worlds a little more forgiving than all that doom > and gloom :). If an innovation happens in BSDland, it generally gets > ported into Linuxland, in time, and visa versa. I heart linux, don't get > me wrong. I just wish they would... > > > On 1/18/23 11:16 AM, Larry McVoy wrote: > > > Well if you want to use your precious time working on some BSD, by all > > means, it's your time. I looked at where the BSDs were going 30 years ago > > and decided that helping Linux would be a better return on investment. > > I don't say that happily, SunOS was my happy place and it was the best > > BSD that ever existed. Turning to Linux was not easy but history has > > shown it to have been the right choice for me. > > > > The problem with BSD is a lack of users. Linux has so many more people > > using it, the chances of one of them finding the problem and getting it > > fixed, before I hit it, are dramatically higher than the same thing with > > a BSD release. > > > > On Wed, Jan 18, 2023 at 10:57:17AM -0600, Will Senn wrote: > > > > > Pretty sure Netflix CDN is still using it as are other vendors in need of > > > stable and fast. Just cuz my neighbor doesn't use it, or joe website hoster > > > doesn't use it doesn't relegate it to the nobody uses it pile. > > > > > > On 1/18/23 10:42 AM, Larry McVoy wrote: > > > > > > > Wishful thinking. An OS needs critical mass in terms of developers. > > > > The BSD efforts divided their devs by having multiple efforts. It > > > > was very obvious from the beginning that Linux was getting all the > > > > developers. Go look at the rate of commits to Linux vs the rate > > > > of commits to {Net,Open,Free,DragonFly,etc}BSD. > > > > > > > > They aren't dead as in nobody does anything to them but they are > > > > dead in that very few people use them. > > > > > > > > Look, Linux users are tiny compared to Windows / MacOS, I think the > > > > desktop users is around 1%. BSD users are even more tiny than Linux. > > > > > > > > On Wed, Jan 18, 2023 at 10:36:48AM -0600, Will Senn wrote: > > > > > > > > > Hi Larry, > > > > > > > > > > I disagree, but only time will tell. I don't think BSD is dead is really a > > > > > fair statement, unless you're referring to the actual distribution. As a > > > > > line, I think it's still viable (I run it in several flavors and it works, > > > > > much more reliably than most linuxes which I also run in multiple flavors). > > > > > That said, everybody :) it seems, seems to be on the Linux is the future > > > > > bandwagon with seemingly only a few of us holdouts. Just a couple of days > > > > > ago I spun up a TrueNAS instance and it was glorious - of course it was > > > > > CORE, try that with SCALE :). > > > > > > > > > > It does seem like the wave favors Windows, Mac, and Linux... But, just cuz > > > > > they're popular doesn't mean the less popular OSes are dead (I say this as I > > > > > gaze fondly over towards my KIM-1 clone and think of Monitor. > > > > > > > > > > Will > > > > > > > > > > On 1/18/23 10:19 AM, Larry McVoy wrote: > > > > > > > > > > > Pretty unrealistic to expect the users to suddenly have the time to do > > > > > > kernel dev. Solaris opened sourced itself and it's dead. > > > > > > > > > > > > It's a lot of work to maintain and evolve an OS. Windows, MacOS, and > > > > > > Linux seem like the future. > > > > > > > > > > > > As for BSD, they pretty much killed themselves by all the in-fighting and > > > > > > the lack of someone like Linus. That was obvious 30 years ago and it > > > > > > hasn't changed. That's why I switched from BSD to Linux. > > > > > > > > > > > > On Wed, Jan 18, 2023 at 04:10:34PM +0000, segaloco wrote: > > > > > > > > > > > > > I just hope we'll see some attempts at opening up these code bases as time goes on. Seeing as they're no longer going to be pushing new copies and will eventually ramp down maintenance releases, opening up the source would give their end users the ability to potentially float their own improvements if they can't immediately migrate to Linux or BSD. That said, security implications of course, don't want to just hand bad actors a code base to comb for memory unsafety in. > > > > > > > > > > > > > > Also this article is BSD erasure :(, no mentions of the big three save that OpenServer and Darwin have chunks of FreeBSD in them. I guess Berkeley is just chopped liver... > > > > > > > > > > > > > > - Matt G. > > > > > > > > > > > > > > ------- Original Message ------- > > > > > > > On Wednesday, January 18th, 2023 at 7:14 AM, Larry McVoy lm at mcvoy.com wrote: > > > > > > > > > > > > > > > It makes perfect sense, it's a repeated story, commercial loses out > > > > > > > > to free. > > > > > > > > > > > > > > > > On Wed, Jan 18, 2023 at 08:13:13AM -0700, arnold at skeeve.com wrote: > > > > > > > > > > > > > > > > > Interestingly enough, Phil Hughes, who founded Linux Journal > > > > > > > > > in the early 1990s, predicted that this would happen one day. > > > > > > > > > This was in a private conversation we had. I thought he > > > > > > > > > was crazy, but he was right. > > > > > > > > > > > > > > > > > > arnold at skeeve.com wrote: > > > > > > > > > > > > > > > > > > > https://www.theregister.com/2023/01/17/unix_is_dead/ > > > > > > > > > > > > > > > > > > > > FYI. > > > > > > > > > > > > > > > > > > > > Arnold > > > > > > > > > > -- > > > > > > > > > > --- > > > > > > > > > > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From kevin.bowling at kev009.com Thu Jan 19 07:18:55 2023 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Wed, 18 Jan 2023 14:18:55 -0700 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> <2f00f9a6-c57d-8490-4066-931ec6e191cd@gmail.com> <20230118164242.GG2964@mcvoy.com> <13b87744-306e-7ecc-a0d0-9305d4b7d958@gmail.com> <20230118171633.GH2964@mcvoy.com> <80641ed1-b0a1-78f8-fabe-83c13b9a9ade@gmail.com> Message-ID: On Wed, Jan 18, 2023 at 2:10 PM segaloco via TUHS wrote: > > Something I think would do wonders for UNIX diversity (although I obviously haven't done a feasibility analysis) is a convergence or at least some sort of homogenization of driver interfaces. That is one of the key areas where I think faster movement would have me using BSDs exclusively, but at any given time I can't expect the same hardware support from anything other than the Linux kernel. I'm not in the know on current driver interfaces to know if its apples to apples, apples to oranges, or apples to hypercubes. But still, if *BSD supported the BCM2711 in entirety w/ graphics accel and onboard SDIO-driven wifi, Linux would serve me no advantage at present other than I know how to tune the kernel build a lot better. http://www.projectudi.org/ was a nod to cross-platform drivers that seemed to go nowhere fast. Linux and FreeBSD also had some limited form of NDIS (Windows network driver model) for some time. One thing you realize after doing a little driver work is most companies have no comprehension of driver quality supporting or harming revenue and reputation. Most purchasers are happy with some value of "works" and performance is hopefully within target, anything else is entropy. A lot of historic poor experiences with WinNT-based OS are driver issues, Microsoft eventually got pretty serious about this and the situation is not as bad these days. Occasionally someone gets it right by dead reckoning, Nvidia won GPU and ML because their (proprietary) drivers are less awful than everything else in the space. > Granted, driver support is not only implicated here, I'd be a lot more nomadic with operating systems if I knew I could work on hobby projects across the preponderance of them efficiently. > > At the end of the day I just want a system with a POSIX-friendly kernel that works with all my devices and doesn't have a complicated userland. As of present, GNU/Linux w/ sysvinit is the happy medium, although one of these days I mean to research in earnest if there's a BSD/V7-ish init that actually gels well with Linux+Glibc userspace. > > - Matt G. > > ------- Original Message ------- > On Wednesday, January 18th, 2023 at 9:25 AM, Will Senn wrote: > > > > Fair enough, but the worlds a little more forgiving than all that doom > > and gloom :). If an innovation happens in BSDland, it generally gets > > ported into Linuxland, in time, and visa versa. I heart linux, don't get > > me wrong. I just wish they would... > > > > > > On 1/18/23 11:16 AM, Larry McVoy wrote: > > > > > Well if you want to use your precious time working on some BSD, by all > > > means, it's your time. I looked at where the BSDs were going 30 years ago > > > and decided that helping Linux would be a better return on investment. > > > I don't say that happily, SunOS was my happy place and it was the best > > > BSD that ever existed. Turning to Linux was not easy but history has > > > shown it to have been the right choice for me. > > > > > > The problem with BSD is a lack of users. Linux has so many more people > > > using it, the chances of one of them finding the problem and getting it > > > fixed, before I hit it, are dramatically higher than the same thing with > > > a BSD release. > > > > > > On Wed, Jan 18, 2023 at 10:57:17AM -0600, Will Senn wrote: > > > > > > > Pretty sure Netflix CDN is still using it as are other vendors in need of > > > > stable and fast. Just cuz my neighbor doesn't use it, or joe website hoster > > > > doesn't use it doesn't relegate it to the nobody uses it pile. > > > > > > > > On 1/18/23 10:42 AM, Larry McVoy wrote: > > > > > > > > > Wishful thinking. An OS needs critical mass in terms of developers. > > > > > The BSD efforts divided their devs by having multiple efforts. It > > > > > was very obvious from the beginning that Linux was getting all the > > > > > developers. Go look at the rate of commits to Linux vs the rate > > > > > of commits to {Net,Open,Free,DragonFly,etc}BSD. > > > > > > > > > > They aren't dead as in nobody does anything to them but they are > > > > > dead in that very few people use them. > > > > > > > > > > Look, Linux users are tiny compared to Windows / MacOS, I think the > > > > > desktop users is around 1%. BSD users are even more tiny than Linux. > > > > > > > > > > On Wed, Jan 18, 2023 at 10:36:48AM -0600, Will Senn wrote: > > > > > > > > > > > Hi Larry, > > > > > > > > > > > > I disagree, but only time will tell. I don't think BSD is dead is really a > > > > > > fair statement, unless you're referring to the actual distribution. As a > > > > > > line, I think it's still viable (I run it in several flavors and it works, > > > > > > much more reliably than most linuxes which I also run in multiple flavors). > > > > > > That said, everybody :) it seems, seems to be on the Linux is the future > > > > > > bandwagon with seemingly only a few of us holdouts. Just a couple of days > > > > > > ago I spun up a TrueNAS instance and it was glorious - of course it was > > > > > > CORE, try that with SCALE :). > > > > > > > > > > > > It does seem like the wave favors Windows, Mac, and Linux... But, just cuz > > > > > > they're popular doesn't mean the less popular OSes are dead (I say this as I > > > > > > gaze fondly over towards my KIM-1 clone and think of Monitor. > > > > > > > > > > > > Will > > > > > > > > > > > > On 1/18/23 10:19 AM, Larry McVoy wrote: > > > > > > > > > > > > > Pretty unrealistic to expect the users to suddenly have the time to do > > > > > > > kernel dev. Solaris opened sourced itself and it's dead. > > > > > > > > > > > > > > It's a lot of work to maintain and evolve an OS. Windows, MacOS, and > > > > > > > Linux seem like the future. > > > > > > > > > > > > > > As for BSD, they pretty much killed themselves by all the in-fighting and > > > > > > > the lack of someone like Linus. That was obvious 30 years ago and it > > > > > > > hasn't changed. That's why I switched from BSD to Linux. > > > > > > > > > > > > > > On Wed, Jan 18, 2023 at 04:10:34PM +0000, segaloco wrote: > > > > > > > > > > > > > > > I just hope we'll see some attempts at opening up these code bases as time goes on. Seeing as they're no longer going to be pushing new copies and will eventually ramp down maintenance releases, opening up the source would give their end users the ability to potentially float their own improvements if they can't immediately migrate to Linux or BSD. That said, security implications of course, don't want to just hand bad actors a code base to comb for memory unsafety in. > > > > > > > > > > > > > > > > Also this article is BSD erasure :(, no mentions of the big three save that OpenServer and Darwin have chunks of FreeBSD in them. I guess Berkeley is just chopped liver... > > > > > > > > > > > > > > > > - Matt G. > > > > > > > > > > > > > > > > ------- Original Message ------- > > > > > > > > On Wednesday, January 18th, 2023 at 7:14 AM, Larry McVoy lm at mcvoy.com wrote: > > > > > > > > > > > > > > > > > It makes perfect sense, it's a repeated story, commercial loses out > > > > > > > > > to free. > > > > > > > > > > > > > > > > > > On Wed, Jan 18, 2023 at 08:13:13AM -0700, arnold at skeeve.com wrote: > > > > > > > > > > > > > > > > > > > Interestingly enough, Phil Hughes, who founded Linux Journal > > > > > > > > > > in the early 1990s, predicted that this would happen one day. > > > > > > > > > > This was in a private conversation we had. I thought he > > > > > > > > > > was crazy, but he was right. > > > > > > > > > > > > > > > > > > > > arnold at skeeve.com wrote: > > > > > > > > > > > > > > > > > > > > > https://www.theregister.com/2023/01/17/unix_is_dead/ > > > > > > > > > > > > > > > > > > > > > > FYI. > > > > > > > > > > > > > > > > > > > > > > Arnold > > > > > > > > > > > -- > > > > > > > > > > > --- > > > > > > > > > > > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tytso at mit.edu Thu Jan 19 07:20:19 2023 From: tytso at mit.edu (Theodore Ts'o) Date: Wed, 18 Jan 2023 16:20:19 -0500 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: <202301180943.30I9hrOw030485@freefriends.org> References: <202301180943.30I9hrOw030485@freefriends.org> Message-ID: On Wed, Jan 18, 2023 at 02:43:53AM -0700, arnold at skeeve.com wrote: > https://www.theregister.com/2023/01/17/unix_is_dead/ Just coincidentally, there is currently discussion in Linux kernel circles about whether it's time to drop support for JFS. JFS was originally from OS/2 and then ported to Linux and AIX, although JFS for Linux and JFS2 for AIX have diverged. JFS has been in maintenance mode in 2008, and the number of users is close to zero at this point. - Ted From kevin.bowling at kev009.com Thu Jan 19 07:27:50 2023 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Wed, 18 Jan 2023 14:27:50 -0700 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> Message-ID: On Wed, Jan 18, 2023 at 2:20 PM Theodore Ts'o wrote: > > On Wed, Jan 18, 2023 at 02:43:53AM -0700, arnold at skeeve.com wrote: > > https://www.theregister.com/2023/01/17/unix_is_dead/ > > Just coincidentally, there is currently discussion in Linux kernel > circles about whether it's time to drop support for JFS. JFS was > originally from OS/2 and then ported to Linux and AIX, although JFS > for Linux and JFS2 for AIX have diverged. JFS has been in maintenance > mode in 2008, and the number of users is close to zero at this point. > > - Ted I had really good experiences with that in the early to mid 2000s, great performance and never lost data. By the time ext4 came out it was no longer much differentiated (extents) and the upgradability and larger user base of ext4 made it obsolete. From athornton at gmail.com Thu Jan 19 10:54:00 2023 From: athornton at gmail.com (Adam Thornton) Date: Wed, 18 Jan 2023 17:54:00 -0700 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: <20230118161959.GE2964@mcvoy.com> References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> Message-ID: On Wed, Jan 18, 2023 at 9:20 AM Larry McVoy wrote: > Pretty unrealistic to expect the users to suddenly have the time to do > kernel dev. Solaris opened sourced itself and it's dead. > > That one's not entirely on the users. There's plenty of blame for Oracle as well. I was the person nominally in charge of the OpenSolaris port to z (Neale Ferguson did most of the heavy lifting) when Sine Nomine built it, having read the tea leaves and believing that IBM would buy Sun. And then IBM tightened the screws a little too far and Larry Ellison grabbed it instead. Dammit. OpenSolaris development had been pretty lively, but then Oracle made it clear they didn't have any interest in keeping it alive. Illumos did its best. Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Thu Jan 19 11:09:39 2023 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 18 Jan 2023 17:09:39 -0800 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> Message-ID: <20230119010938.GH28004@mcvoy.com> On Wed, Jan 18, 2023 at 05:54:00PM -0700, Adam Thornton wrote: > On Wed, Jan 18, 2023 at 9:20 AM Larry McVoy wrote: > > > Pretty unrealistic to expect the users to suddenly have the time to do > > kernel dev. Solaris opened sourced itself and it's dead. > > > > > That one's not entirely on the users. > > There's plenty of blame for Oracle as well. > > I was the person nominally in charge of the OpenSolaris port to z (Neale > Ferguson did most of the heavy lifting) when Sine Nomine built it, having > read the tea leaves and believing that IBM would buy Sun. And then IBM > tightened the screws a little too far and Larry Ellison grabbed it > instead. Dammit. Yeah, I'm not a Solaris fan (because SunOS) but there was some good technology in there. Would have been cool if IBM kept it going. I never really understood why Sun was up for sale. From joseph at josephholsten.com Thu Jan 19 11:13:51 2023 From: joseph at josephholsten.com (Joseph Holsten) Date: Wed, 18 Jan 2023 17:13:51 -0800 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> <2f00f9a6-c57d-8490-4066-931ec6e191cd@gmail.com> <20230118164242.GG2964@mcvoy.com> <13b87744-306e-7ecc-a0d0-9305d4b7d958@gmail.com> <20230118171633.GH2964@mcvoy.com> <80641ed1-b0a1-78f8-fabe-83c13b9a9ade@gmail.com> Message-ID: <99cb2bc7-8b71-4aee-a5c2-32c12b246eb7@app.fastmail.com> On Wed, Jan 18, 2023, at 13:09, segaloco via TUHS wrote: > […] I mean to research in earnest if there's a BSD/V7-ish > init that actually gels well with Linux+Glibc userspace. Have you attempted slackware’s distro? My current work keeps me in RHEL derivatives when I’m using Linux, but slack was lovely in the 90s. From marc.donner at gmail.com Thu Jan 19 11:17:15 2023 From: marc.donner at gmail.com (Marc Donner) Date: Wed, 18 Jan 2023 20:17:15 -0500 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> Message-ID: Back in the mid-late 1980s I was at IBM Research where I was sort of the proprietor of a bunch of Unix boxes (about 200+, about split evenly between Sun machines and RT-PCs running BSD 4.3 (the ACIS port). I was in the Mathematics department and we called it Mathnet. Rekhter developed the BGP stuff on one of our machines and Zadeck implemented the SSA stuff on one. When the RS-6000 and AIX 3 were under preparation the AIX folks asked us to help get AIX 3 ready for the real world. They gave us a bunch of RS-6000s (we looked at them and laughed - "what a whale" one of us said ... we called the lab Marineland) and we tried integrating them into our UNIX single (single-ish) system image. We maintained our (rough) image consistency by rdisting stuff, including administrative junk, from a central set of machines to all of the others. Well, the AIX systems depended on this database called the ODM (we called it the odious data mangler). The problem was that the designers of the ODM envisioned themselves as managing a mainframe. The ODM commingled information about the installation (the entire site), the instance (the box itself), and the community (users and stuff). This meant that the database included device identifiers. We tried rdist-ing the ODM from our central machine to all the rest of our machines. Oops ... lobotomies all around. I won't bore you with all of the details, but it was a struggle. At one point I threatened the head of AIX 3 development in Austin, TX that I would post the source code of some major component to rec.humor.funny. He was not my friend. Anyway, we did end up making a list of horrible things that they absolutely had to fix. And, to their credit, they got a lot of it fixed so that when the RS-6000 and AIX 3 did ship it was not humiliating. It was probably my first run-in with the pragmatics of shipping real commercial production software. Marc ===== nygeek.net mindthegapdialogs.com/home On Wed, Jan 18, 2023 at 7:55 PM Adam Thornton wrote: > > > On Wed, Jan 18, 2023 at 9:20 AM Larry McVoy wrote: > >> Pretty unrealistic to expect the users to suddenly have the time to do >> kernel dev. Solaris opened sourced itself and it's dead. >> >> > That one's not entirely on the users. > > There's plenty of blame for Oracle as well. > > I was the person nominally in charge of the OpenSolaris port to z (Neale > Ferguson did most of the heavy lifting) when Sine Nomine built it, having > read the tea leaves and believing that IBM would buy Sun. And then IBM > tightened the screws a little too far and Larry Ellison grabbed it > instead. Dammit. > > OpenSolaris development had been pretty lively, but then Oracle made it > clear they didn't have any interest in keeping it alive. Illumos did its > best. > > Adam > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph at josephholsten.com Thu Jan 19 11:26:42 2023 From: joseph at josephholsten.com (Joseph Holsten) Date: Wed, 18 Jan 2023 17:26:42 -0800 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> Message-ID: <52e4bbd7-c5cd-4142-a609-d73ad8025201@app.fastmail.com> On Wed, Jan 18, 2023, at 17:17, Marc Donner wrote: > I won't bore you with all of the details, but it was a struggle. Clearly, you mistake your audience. I would probably read a multi-volume series of these struggles. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at deitygraveyard.com Thu Jan 19 12:17:46 2023 From: jim at deitygraveyard.com (Jim Carpenter) Date: Wed, 18 Jan 2023 21:17:46 -0500 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> Message-ID: On Wed, Jan 18, 2023 at 4:20 PM Theodore Ts'o wrote: > Just coincidentally, there is currently discussion in Linux kernel > circles about whether it's time to drop support for JFS. JFS was > originally from OS/2 and then ported to Linux and AIX, although JFS > for Linux and JFS2 for AIX have diverged. JFS has been in maintenance > mode in 2008, and the number of users is close to zero at this point. Well the original JFS was introduced with AIX 3.1 in 1990. A new JFS started from that and was introduced with an OS/2 in 1999 and made its way back to AIX. >From the 12/16/2002 JFS mini-FAQ: Q1. What is the history of the source based use for the port of JFS for Linux. A1. IBM introduced its UNIX file system as the Journaled File System (JFS) with the initial release of AIX Version 3.1. This file system, now called JFS1 on AIX, has been the premier file system for AIX over the last 10 years and has been installed in millions of customer's AIX systems. In 1995, work began to enhance the file system to be more scalable and to support machines that had more than one processor. Another goal was to have a more portable file system, capable of running on multiple operating systems. Historically, the JFS1 file system is very closely tied to the memory manager of AIX. This design is typical of a closed-source operating system, or a file system supporting only one operating system. The new Journaled File System, on which the Linux port was based, was first shipped in OS/2 Warp Server for eBusiness in April, 1999, after several years of designing, coding, and testing. It also shipped with OS/2 Warp Client in October, 2000. In parallel to this effort, some of the JFS development team returned to the AIX Operating System Development Group in 1997 and started to move this new JFS source base to the AIX operating system. In May, 2001, a second journaled file system, Enhanced Journaled File System (JFS2), was made available for AIX 5L. In December of 1999, a snapshot of the original OS/2 JFS source was taken and work was begun to port JFS to Linux. Jim From sjenkin at canb.auug.org.au Thu Jan 19 13:56:47 2023 From: sjenkin at canb.auug.org.au (steve jenkin) Date: Thu, 19 Jan 2023 14:56:47 +1100 Subject: [TUHS] Maintenance mode on AIX In-Reply-To: References: Message-ID: <1FA76FBA-F729-4D91-8675-238BB6A9E699@canb.auug.org.au> To their credit, ACM have make the video available on Youtube Link includes intro to Ken for those wanting brevity. > On 19 Jan 2023, at 07:04, Joseph J. Mankoski ***PSI*** wrote: > > Hello -- > > Regarding "appliance-ization" (locking down / dumbing down) of commercially-available computer systems, and returning to the history of Unix (in the context of our current era), I am reminded of Ken Thompson's (excellent and humorous) panel presentation at the ACM Turing 100 conference I attended in 2012, imagining Alan Turing being brought to our time and given a current-generation computer system, etc. > > The webcast links for the "Systems Architecture" session, etc., on the main conference site, https://turing100.acm.org/, seem to be broken, however the video at this link works for me: > > https://dl.acm.org/doi/10.1145/2322176.2322182 > > (Ken's part starts at ~0:09:28.) > > Cheers, > ***PSI*** > <<>> -- Steve Jenkin mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin From arnold at skeeve.com Thu Jan 19 18:02:20 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 19 Jan 2023 01:02:20 -0700 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: <20230118151446.GD2964@mcvoy.com> References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> Message-ID: <202301190802.30J82KwQ025718@freefriends.org> In hindsight, I agree. But at the time, Linux was less than five years old, and it wasn't so obvious. Larry McVoy wrote: > It makes perfect sense, it's a repeated story, commercial loses out > to free. > > On Wed, Jan 18, 2023 at 08:13:13AM -0700, arnold at skeeve.com wrote: > > Interestingly enough, Phil Hughes, who founded Linux Journal > > in the early 1990s, predicted that this would happen one day. > > This was in a private conversation we had. I thought he > > was crazy, but he was right. > > > > arnold at skeeve.com wrote: > > > > > https://www.theregister.com/2023/01/17/unix_is_dead/ > > > > > > FYI. > > > > > > Arnold > > -- > --- > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From lproven at gmail.com Fri Jan 20 00:25:01 2023 From: lproven at gmail.com (Liam Proven) Date: Thu, 19 Jan 2023 15:25:01 +0100 Subject: [TUHS] Maintenance mode on AIX In-Reply-To: <1315c448-c8e8-1ae5-ef34-0f7ba3fbb8a7@gmail.com> References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> <20230118163840.GF2964@mcvoy.com> <1315c448-c8e8-1ae5-ef34-0f7ba3fbb8a7@gmail.com> Message-ID: On Wed, 18 Jan 2023 at 18:22, Will Senn wrote: > > Wow, we're all over the place on this thread. True! > I stopped updating my Mac with Mojave. Me too. I have some irreplaceable 32-bit apps. > I would prefer my OS to be under my control and secure my information, for me. I agree. *But* the thing is this, and I am theorizing here. Apple is trying to move to Arm-ISA Macs with its own very highly integrated chipset. This is imposing some issues. E.g. The M1 Macs can't boot from an external device if the internal one fails. You can't just put in a USB key and start from it. You can't just remove a failed drive, replace it, format it, reinstall the OS and keep going. https://apple.stackexchange.com/questions/437022/can-apple-silicon-based-mac-boot-from-unauthorized-external-drive They seem to lack the old 68K/PowerPC/x86 fairly clean separation between firmware and OS on a disk. They are, pretty much, the whole computer on a single SOC. The first SOC was the ARM250: CPU + GPU + memory controller. Then FPU and bus controllers and interfaces and things moved on board too. Now, the RAM is on board, and the SSD is also built in if not on the same die. It is extremely hard to replace/upgrade them, e.g. https://www.macrumors.com/2021/04/06/m1-mac-ram-and-ssd-upgrades-possible/ In a way the Arm Macs are sort of like iPads with external screens. It is also notable that there is _still_ no Arm-based Mac Pro: I don't think they've found a way to make their new architecture as modular, with external GPUs and an expansion bus. I suspect they won't be able to and eventually the Intel kit will quietly disappear with no direct replacement. So I think that Apple is trying to make the OS as *extremely* robust and tamper-proof as they can, because if that soldered-in-place disk gets scrambled or compromised, then the expensive hardware is basically toast. I don't like it either and I don't want an Arm-powered Mac for now... but I sort of understand what they are trying to do, I think. -- Liam Proven ~ Profile: https://about.me/liamproven Email: lproven at cix.co.uk ~ gMail/gTalk/FB: lproven at gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 From lproven at gmail.com Fri Jan 20 00:42:38 2023 From: lproven at gmail.com (Liam Proven) Date: Thu, 19 Jan 2023 15:42:38 +0100 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: <20230118145554.3B27F20145@orac.inputplus.co.uk> References: <202301180943.30I9hrOw030485@freefriends.org> <202301181446.30IEkSNt050612@ultimate.com> <20230118145554.3B27F20145@orac.inputplus.co.uk> Message-ID: On Wed, 18 Jan 2023 at 15:56, Ralph Corderoy wrote: > > The fine article ends with *Heh* > ‘Which means that the last officially trademarked commercial UNIX™ is > Apple's macOS 13, which underneath the proprietary GUI layer is mostly > an open source OS called Darwin anyway. The kernel, XNU, is based on > Mach with an in-kernel "Unix server" derived from FreeBSD...’ > — https://www.theregister.com/2023/01/17/unix_is_dead/ Indeed it does. I wrote it. Thanks to Arnold for posting it. I am getting some grief on Twitter too for "omitting" FreeBSD. I didn't, but the BSDs don't fit either definition of "Unix". The pre-1993 one being "based on AT&T code" -- after all, BSD (4.4 Lite r2 was it? Before my time!) -- went to a lot of effort to eliminate AT&T code. The post-'93 definition, after Novell donated the trademark to the Open Group, is "passed Open Group testing". Nobody has the time or the inclination to pay, and indeed, why should they? I hope to return to the subject of the BSDs in general on the Reg in future. -- Liam Proven ~ Profile: https://about.me/liamproven Email: lproven at cix.co.uk ~ gMail/gTalk/FB: lproven at gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 From lproven at gmail.com Fri Jan 20 00:45:02 2023 From: lproven at gmail.com (Liam Proven) Date: Thu, 19 Jan 2023 15:45:02 +0100 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: <20230118161959.GE2964@mcvoy.com> References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> Message-ID: On Wed, 18 Jan 2023 at 17:20, Larry McVoy wrote: > > Pretty unrealistic to expect the users to suddenly have the time to do > kernel dev. Solaris opened sourced itself and it's dead. I believe 0x1DE computer are working on that. :-) > As for BSD, they pretty much killed themselves by all the in-fighting and > the lack of someone like Linus. That was obvious 30 years ago and it > hasn't changed. I entirely agree. -- Liam Proven ~ Profile: https://about.me/liamproven Email: lproven at cix.co.uk ~ gMail/gTalk/FB: lproven at gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 From lproven at gmail.com Fri Jan 20 01:02:18 2023 From: lproven at gmail.com (Liam Proven) Date: Thu, 19 Jan 2023 16:02:18 +0100 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: <20230118164242.GG2964@mcvoy.com> References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> <2f00f9a6-c57d-8490-4066-931ec6e191cd@gmail.com> <20230118164242.GG2964@mcvoy.com> Message-ID: On Wed, 18 Jan 2023 at 17:43, Larry McVoy wrote: > Look, Linux users are tiny compared to Windows / MacOS, I think the > desktop users is around 1%. BSD users are even more tiny than Linux. Actually, I think that's not true any more. ChromeBooks outsold Mac in the USA in 2017, and worldwide by 2020. (Sales have fallen off a cliff since the pandemic, but that's because so many people have one and are happy with it, I think.) I think that's in the region of 250-300 million desktop Linux users. Secondly, the PRoC has a "5-3-2 programme" in place to compel all organisations to move to Linux and get rid of American OSes. Last year was the nominal completion when 98% of machines were to have been replaced or reinstalled; the assumption was that there would be at least 2% of Windows boxes that they _couldn't_ readily replace. https://www.theregister.com/2019/12/09/china_orders_ban_on_us_computers_and_software/ I've looked at OpenKylin. It's Ubuntu. Deepin is Debian underneath although they're planning to move away from it. It's hard to get any reliable figures, but frankly, Ubuntu Kylin and Deepin are good, attractive, friendly OSes. They are frankly better and friendlier than GNOME or KDE, IMHO, and they're working on things like dual root partitions with failover, like ChromeOS has. I suspect that there may be another 100 million to maybe 250M users there, too. Which means about half a billion Linux desktops and laptops out there. It's not that Linux on the desktop never happened. It did, from 2017-2020. It's over. It's history. But the Linux world, predictably, didn't notice and doesn't count these as "proper" Linuxes. ChromeOS is a 100% a Linux, based on Gentoo, but it's not aimed at Linux users. It doesn't even have a package manager. And too many of we Westerners don't bother looking at stuff with funny writing from far away, so they don't notice this stuff. I've lost count of how many Ubuntu distro roundups just dismiss Kylin as "the version for China" and don't even try it. (The few that do, like it.) I tried to give an overview: https://www.theregister.com/2022/08/30/kylin_the_multiple_semiofficial_chinese/ If I am right, and I don't have strong evidence, then I suspect that there, ballpark, as many Kylin and Deepin users as ChromeOS users, and that put together, they account for about 90% of Linux users. In other words, the estimates of western distro usage are about 1/10 of the real picture. -- Liam Proven ~ Profile: https://about.me/liamproven Email: lproven at cix.co.uk ~ gMail/gTalk/FB: lproven at gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 From lm at mcvoy.com Fri Jan 20 01:04:34 2023 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 19 Jan 2023 07:04:34 -0800 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: <202301190802.30J82KwQ025718@freefriends.org> References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <202301190802.30J82KwQ025718@freefriends.org> Message-ID: <20230119150434.GA626@mcvoy.com> I had already been using Linux for a while by then I believe. I used it before it had networking. Pretty early on I got to be friends with Linus and was really impressed with his leadership. That's what sold me on Linux, he was the thing that was missing in the BSD world. If someone like him had appeared and unified the BSD world I think we'd all be running BSD. On Thu, Jan 19, 2023 at 01:02:20AM -0700, arnold at skeeve.com wrote: > In hindsight, I agree. But at the time, Linux was less than > five years old, and it wasn't so obvious. > > Larry McVoy wrote: > > > It makes perfect sense, it's a repeated story, commercial loses out > > to free. > > > > On Wed, Jan 18, 2023 at 08:13:13AM -0700, arnold at skeeve.com wrote: > > > Interestingly enough, Phil Hughes, who founded Linux Journal > > > in the early 1990s, predicted that this would happen one day. > > > This was in a private conversation we had. I thought he > > > was crazy, but he was right. > > > > > > arnold at skeeve.com wrote: > > > > > > > https://www.theregister.com/2023/01/17/unix_is_dead/ > > > > > > > > FYI. > > > > > > > > Arnold > > > > -- > > --- > > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From imp at bsdimp.com Fri Jan 20 01:04:11 2023 From: imp at bsdimp.com (Warner Losh) Date: Thu, 19 Jan 2023 08:04:11 -0700 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181446.30IEkSNt050612@ultimate.com> <20230118145554.3B27F20145@orac.inputplus.co.uk> Message-ID: On Thu, Jan 19, 2023 at 7:44 AM Liam Proven wrote: > On Wed, 18 Jan 2023 at 15:56, Ralph Corderoy > wrote: > > > > The fine article ends with > > *Heh* > > > ‘Which means that the last officially trademarked commercial UNIX™ is > > Apple's macOS 13, which underneath the proprietary GUI layer is > mostly > > an open source OS called Darwin anyway. The kernel, XNU, is based on > > Mach with an in-kernel "Unix server" derived from FreeBSD...’ > > — https://www.theregister.com/2023/01/17/unix_is_dead/ > > Indeed it does. I wrote it. Thanks to Arnold for posting it. > > I am getting some grief on Twitter too for "omitting" FreeBSD. I > didn't, but the BSDs don't fit either definition of "Unix". The > pre-1993 one being "based on AT&T code" -- after all, BSD (4.4 Lite r2 > was it? Before my time!) -- went to a lot of effort to eliminate AT&T > code. The post-'93 definition, after Novell donated the trademark to > the Open Group, is "passed Open Group testing". Nobody has the time or > the inclination to pay, and indeed, why should they? > Yes. I think I tweeted that all the BSDs are derived from Unix. This is very true: V7 was ported to the VAX by AT&T which produced 32V (which had a lot of different versions, but Berkeley started with an early one, before V7 was officially released). Berkeley added demand paging to it to create 3BSD, 4BSD, etc. While much of the original AT&T code was re-written, it was replaced with functionally equivalent code so the system behaved the same before / after the rewrite. In many cases the rewrite was an improvement, in some it wasn't. More importantly, though, it retained much of the structure of the original AT&T code, especailly in the kernel. So if you understood the BSD code, you'd understand the System V code and vice versa at least at a gross level. Ditto all the commercial Unixes which also, btw, rewrote a substantial portion of the original AT&T code. All the BSDs is derived from Unix, but can't use the Unix trademark... There have been people that have run the compliance suite over the years against the different BSD, producing patches that fixed issues (though the last one I recall was in the early 2000s). But since nobody paid for official certification, nobody knows how close things are thees days. A similar level of rewrite and restructuring has happened to Linux over the years. Outside of drivers, very little remains even from the 2.x days of Linux, let alone the 1.x or 0.x lines. It too has been rewritten from having strong assumptions about running on a single CPU to scaling to thousands of CPUs these days. A similar evolution has happened in the BSDs, though with different paths taken in the different forks. > I hope to return to the subject of the BSDs in general on the Reg in > future. > That would be cool... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From lproven at gmail.com Fri Jan 20 01:04:58 2023 From: lproven at gmail.com (Liam Proven) Date: Thu, 19 Jan 2023 16:04:58 +0100 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> <2f00f9a6-c57d-8490-4066-931ec6e191cd@gmail.com> <20230118164242.GG2964@mcvoy.com> <13b87744-306e-7ecc-a0d0-9305d4b7d958@gmail.com> <20230118171633.GH2964@mcvoy.com> <80641ed1-b0a1-78f8-fabe-83c13b9a9ade@gmail.com> Message-ID: On Wed, 18 Jan 2023 at 22:09, segaloco via TUHS wrote: > > if there's a BSD/V7-ish init that actually gels well with Linux+Glibc userspace. This might interest you, then. https://chimera-linux.org/ I haven't tried it yet myself. -- Liam Proven ~ Profile: https://about.me/liamproven Email: lproven at cix.co.uk ~ gMail/gTalk/FB: lproven at gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 From crossd at gmail.com Fri Jan 20 01:05:13 2023 From: crossd at gmail.com (Dan Cross) Date: Thu, 19 Jan 2023 10:05:13 -0500 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> Message-ID: On Thu, Jan 19, 2023 at 9:46 AM Liam Proven wrote: > On Wed, 18 Jan 2023 at 17:20, Larry McVoy wrote: > > Pretty unrealistic to expect the users to suddenly have the time to do > > kernel dev. Solaris opened sourced itself and it's dead. > > I believe 0x1DE computer are working on that. :-) It's true we run illumos on the host. That's ideally transparent to users, though. Outside of Oxide, illumos is used in several places, but it's fair to say that it's nowhere near as popular as Linux or the BSDs. illumos is, as far as we know, the only actively-maintained open source System V derivative. Is it Unix? I don't know; there's definitely AT&T code in there. The kernel binary is called "unix", if that matters. But I don't think anyone has bothered to keep up with the UNIX(TM) trademark certification. To the extent your article was concerned with systems that do that, I think you were largely right (though macOS doesn't seem like it's going anywhere anytime soon). But to say that illumos, or the BSDs for that matter, aren't "Unix" in terms of interface or use seems incorrect. I don't think that Larry is wrong arout Solaris, but I think that Oracle re-closing the source probably also had a lot to do with it. Still, OpenSolaris never gained critical mass; maybe it was just too little too late. It is striking how Unix has repeatedly suffered through corporate shortsightedness; how much of Linux's success is due to being free of that? > > As for BSD, they pretty much killed themselves by all the in-fighting and > > the lack of someone like Linus. That was obvious 30 years ago and it > > hasn't changed. > > I entirely agree. Meh. I don't know. I'll make a prediction: at least one of the BSDs will outlive Linux. Linux right now sort of reminds me of commercial Unix in the 90s. Personally, I think something's going to come from out of left field and displace it within the next 15 years, just like Linux displaced (and yes, killed) commercial Unix. Compatibility shims for the API will continue to exist, but the implementation will be very different. - Dan C. From arnold at skeeve.com Fri Jan 20 01:12:48 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 19 Jan 2023 08:12:48 -0700 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> <2f00f9a6-c57d-8490-4066-931ec6e191cd@gmail.com> <20230118164242.GG2964@mcvoy.com> Message-ID: <202301191512.30JFCmmI017248@freefriends.org> Liam Proven wrote: > Secondly, the PRoC has a "5-3-2 programme" in place to compel all > organisations to move to Linux and get rid of American OSes. Last year > was the nominal completion when 98% of machines were to have been > replaced or reinstalled; the assumption was that there would be at > least 2% of Windows boxes that they _couldn't_ readily replace. > > https://www.theregister.com/2019/12/09/china_orders_ban_on_us_computers_and_software/ > > I've looked at OpenKylin. It's Ubuntu. Deepin is Debian underneath > although they're planning to move away from it. OK, so far so good for the numbers, but how much do those distributions let the PROC government monitor what its citizens are doing? There are political, non-technical reasons to avoid anything coming out of China. And yes, this is even way more off topic. Arnold From lproven at gmail.com Fri Jan 20 01:15:45 2023 From: lproven at gmail.com (Liam Proven) Date: Thu, 19 Jan 2023 16:15:45 +0100 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181446.30IEkSNt050612@ultimate.com> <20230118145554.3B27F20145@orac.inputplus.co.uk> Message-ID: On Thu, 19 Jan 2023 at 16:03, Warner Losh wrote: > More importantly, though, it retained much of the structure of the original AT&T code, especailly in the kernel. So if you understood the BSD code, you'd understand the System V code and vice versa at least at a gross level. I believe I was in the audience for your FOSDEM talk on this matter. :-) >> I hope to return to the subject of the BSDs in general on the Reg in future. > > That would be cool... FWIW, in the last year, I've reviewed FreeBSD, OpenBSD (twice), NetBSD and DragonflyBSD. The Dragonfly team contacted me and owned the problems I had. They don't test against VirtualBox. For the others, various admirers complained in the comments, or by email, or by social media, or combinations thereof, and nobody but nobody went "oh, you're right, that _is_ a problem, we should look at that." There's an ongoing "spirited discussion" ;-) on Twitter right now with me, Frank Leonhardt, and Eugene Markow. -- Liam Proven ~ Profile: https://about.me/liamproven Email: lproven at cix.co.uk ~ gMail/gTalk/FB: lproven at gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 From imp at bsdimp.com Fri Jan 20 01:20:16 2023 From: imp at bsdimp.com (Warner Losh) Date: Thu, 19 Jan 2023 08:20:16 -0700 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: <20230119150434.GA626@mcvoy.com> References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <202301190802.30J82KwQ025718@freefriends.org> <20230119150434.GA626@mcvoy.com> Message-ID: On Thu, Jan 19, 2023 at 8:04 AM Larry McVoy wrote: > I had already been using Linux for a while by then I believe. I used > it before it had networking. > > Pretty early on I got to be friends with Linus and was really impressed > with his leadership. That's what sold me on Linux, he was the thing > that was missing in the BSD world. If someone like him had appeared > and unified the BSD world I think we'd all be running BSD. > By the time even 4.3BSD was released, there were dozens of people that could work on the kernel at a high level of skill. There was no one person who created it who could have the gravitas to pull that off. Let alone a decade later when it was freed up, by then there were hundreds. The dynamics of the situation were quite different: Linus always was in charge because he wrote the whole thing... BSD was a victim of it's own success in the 80s and 90s in a way... Warner > On Thu, Jan 19, 2023 at 01:02:20AM -0700, arnold at skeeve.com wrote: > > In hindsight, I agree. But at the time, Linux was less than > > five years old, and it wasn't so obvious. > > > > Larry McVoy wrote: > > > > > It makes perfect sense, it's a repeated story, commercial loses out > > > to free. > > > > > > On Wed, Jan 18, 2023 at 08:13:13AM -0700, arnold at skeeve.com wrote: > > > > Interestingly enough, Phil Hughes, who founded Linux Journal > > > > in the early 1990s, predicted that this would happen one day. > > > > This was in a private conversation we had. I thought he > > > > was crazy, but he was right. > > > > > > > > arnold at skeeve.com wrote: > > > > > > > > > https://www.theregister.com/2023/01/17/unix_is_dead/ > > > > > > > > > > FYI. > > > > > > > > > > Arnold > > > > > > -- > > > --- > > > Larry McVoy Retired to fishing > http://www.mcvoy.com/lm/boat > > -- > --- > Larry McVoy Retired to fishing > http://www.mcvoy.com/lm/boat > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Fri Jan 20 01:23:57 2023 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 19 Jan 2023 07:23:57 -0800 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <202301190802.30J82KwQ025718@freefriends.org> <20230119150434.GA626@mcvoy.com> Message-ID: <20230119152357.GB626@mcvoy.com> On Thu, Jan 19, 2023 at 08:20:16AM -0700, Warner Losh wrote: > On Thu, Jan 19, 2023 at 8:04 AM Larry McVoy wrote: > > > I had already been using Linux for a while by then I believe. I used > > it before it had networking. > > > > Pretty early on I got to be friends with Linus and was really impressed > > with his leadership. That's what sold me on Linux, he was the thing > > that was missing in the BSD world. If someone like him had appeared > > and unified the BSD world I think we'd all be running BSD. > > > > By the time even 4.3BSD was released, there were dozens of people that > could work on the kernel at a high level of skill. There was no one person > who created it who could have the gravitas to pull that off. Let alone a > decade later when it was freed up, by then there were hundreds. The > dynamics of the situation were quite different: Linus always was in charge > because he wrote the whole thing... BSD was a victim of it's own success > in the 80s and 90s in a way... Linus was in charge because he started it. At least 30 years ago I said "He's good programmer, a good architect, and a good manager. I've never seen that in one person before". He most certainly did not write the whole thing but he decided what went in when. He's quite good at that. From crossd at gmail.com Fri Jan 20 02:40:50 2023 From: crossd at gmail.com (Dan Cross) Date: Thu, 19 Jan 2023 11:40:50 -0500 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <202301190802.30J82KwQ025718@freefriends.org> <20230119150434.GA626@mcvoy.com> Message-ID: On Thu, Jan 19, 2023 at 10:21 AM Warner Losh wrote: > On Thu, Jan 19, 2023 at 8:04 AM Larry McVoy wrote: >> I had already been using Linux for a while by then I believe. I used >> it before it had networking. >> >> Pretty early on I got to be friends with Linus and was really impressed >> with his leadership. That's what sold me on Linux, he was the thing >> that was missing in the BSD world. If someone like him had appeared >> and unified the BSD world I think we'd all be running BSD. > > By the time even 4.3BSD was released, there were dozens of people that could work on the kernel at a high level of skill. There were also a lot of gatekeepers. Perhaps not so much in CSRG, but certainly in the next tier out: if you weren't part of the in-crowd at USENIX and on USENET, it was hard to contribute. Ted has referred to this as kowtowing to the "Gods of BSD." He wasn't wrong, though I think the dynamic has changed substantially in recent years. > There was no one person who created it who could have the gravitas to pull that off. Let alone a decade later when it was freed up, by then there were hundreds. The dynamics of the situation were quite different: Linus always was in charge because he wrote the whole thing... BSD was a victim of it's own success in the 80s and 90s in a way... I'm struck by the thing Ken said in the video that was linked earlier, so much of "success" has to do with luck. Unix was in the right place at the right time, spread through universities, and escaped into industry. It's one of the relatively few research projects that was truly successful in that sense. But consider that it also had something like five years to incubate in a lab before that happened, and the members of that lab had a vested interest in making it useful (after all, they were using it for their own consumption!). By the time BSD came along, Unix already had a well-defined "shape" and a certain degree of polish; contributing meant there was a bar you had to hurdle. On the other hand, Torvalds published Linux when it was still a toy, but critically, at a point where the industry was at a real inflection point, due to external factors. More capable research systems had been out there before, and open source BSDs were right around the corner, but they didn't win. I think this was mostly luck and timing. He also pretty much took from everybody, which made it much more of a "big tent" sort of thing as opposed to the faculty lunchroom vibe prevalent in the Unix world (what I've previously described as, "the old-school Unix mentality"). Periodically we see how this still rankles some, even on this mailing list. But it's interesting the way the "Gods of BSD vs the rebel alliance" thing seems to have inverted itself. Getting stuff done in Linux these days is pretty hard; oh sure, I suppose if you whip off a patch fixing a typo in a comment or something, someone will just apply it. But if you want to do something substantial, you have to be willing to invest a lot of time and effort in shepherding it through the upstreaming process, which implies you've got to have resources backing that effort. And there's definitely an in-group. Meanwhile, the BSDs seem a lot more accepting; maybe that's just me. At least FreeBSD and DragonFly appear that way. Anyway, it seems fair to say that Linux seems mostly beholden to the interests of big companies these days. Linus is personally responsible for much of Linux's success, but I think he will also be the thing that causes Linux's demise, though indirectly. He's as much of a cult of personality as he is a technical leader; when he's gone (and in the limit we're all mortal) who will step into his shoes? Then again, maybe I'm wrong: I thought this would happen when Jobs died, but Cook seems to have stepped into the role nicely and Apple's doing just fine. Steve Jobs chose wisely; perhaps Linus will as well. - Dan C. >> On Thu, Jan 19, 2023 at 01:02:20AM -0700, arnold at skeeve.com wrote: >> > In hindsight, I agree. But at the time, Linux was less than >> > five years old, and it wasn't so obvious. >> > >> > Larry McVoy wrote: >> > >> > > It makes perfect sense, it's a repeated story, commercial loses out >> > > to free. >> > > >> > > On Wed, Jan 18, 2023 at 08:13:13AM -0700, arnold at skeeve.com wrote: >> > > > Interestingly enough, Phil Hughes, who founded Linux Journal >> > > > in the early 1990s, predicted that this would happen one day. >> > > > This was in a private conversation we had. I thought he >> > > > was crazy, but he was right. >> > > > >> > > > arnold at skeeve.com wrote: >> > > > >> > > > > https://www.theregister.com/2023/01/17/unix_is_dead/ >> > > > > >> > > > > FYI. >> > > > > >> > > > > Arnold >> > > >> > > -- >> > > --- >> > > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat >> >> -- >> --- >> Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From imp at bsdimp.com Fri Jan 20 02:58:48 2023 From: imp at bsdimp.com (Warner Losh) Date: Thu, 19 Jan 2023 09:58:48 -0700 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <202301190802.30J82KwQ025718@freefriends.org> <20230119150434.GA626@mcvoy.com> Message-ID: On Thu, Jan 19, 2023 at 9:41 AM Dan Cross wrote: > But it's interesting the way the "Gods of BSD vs the rebel alliance" > thing seems to have inverted itself. Getting stuff done in Linux these > days is pretty hard; oh sure, I suppose if you whip off a patch fixing > a typo in a comment or something, someone will just apply it. But if > you want to do something substantial, you have to be willing to invest > a lot of time and effort in shepherding it through the upstreaming > process, which implies you've got to have resources backing that > effort. And there's definitely an in-group. Meanwhile, the BSDs seem a > lot more accepting; maybe that's just me. At least FreeBSD and > DragonFly appear that way. Anyway, it seems fair to say that Linux > seems mostly beholden to the interests of big companies these days. > This matches my experience: Lots of gatekeepers, any one of which can take a disliking to your submission for what, at times, seems like arbitrary and capricious reasons. If you make it to the 'in crowd' it becomes more of a rubber stamp at times... I have recently been successful at submitting an obvious fix to a tiny backwater area of the kernel without undue stress though... But I submitted it to the maintainer of the area, who then submitted it to the 'greater maintainer', and then to the greater maintainer and then to the tree. So my tiny fix has more Signed-off-by: lines than lines of change and took about two weeks to make its way all the way up into the repo... For me, it took about 2x as long to prep and send the change than it does for the direct commit access I have for FreeBSD, but I've spent more than 10x on other submissions that ultimately didn't make it in. This is in contrast to the few changes I got in in the 90s: I sent an email to Ralf, who nit picked one or two things, which I fixed and it wound up in his next batch of changes to Linus and made its way in (to code that's sense been deleted, alas). The BSD are more accepting, in general, though it can be hard to find the right person to approve your change. There's too many ingest points still, too many things fall on the floor, etc. Part of that is tooling, part of it is culture, part of it is lack of clear docs, etc. It is generally easier to get a change into the BSDs. It takes less persistance, on the average, but it still takes more effort than it should. I looked into Linux's processes to improve FreeBSD's. And came to the conclusion that in large part they succeed despite their processes, not because of them. They have too much overhead, rely too much on magic bots that are hard to replicate and I'm astonished that things work as well as they do. It's a grown culture / process that relies on old tools mixed with new in weird ways you'd never think of standing up today. Things can be learned from it, but it seems to be a unique snowflake relative to all the other projects I looked at... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Fri Jan 20 02:59:03 2023 From: bakul at iitbombay.org (Bakul Shah) Date: Thu, 19 Jan 2023 08:59:03 -0800 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> Message-ID: <0882D9CA-FAC8-4EC6-BA82-CE1D457423E5@iitbombay.org> On Jan 19, 2023, at 7:05 AM, Dan Cross wrote: > > Meh. I don't know. I'll make a prediction: at least one of the BSDs > will outlive Linux. Even though I prefer *BSD to Linux I am afraid this is unlikely when people are talking about porting µClinux to a 10 cent riscv part (CH32V003)! Granted it is not a full linux but still. BSDs have no resources for this. Worse, many of these parts are insufficiently documented, the same disease that afflicts all the io device vendors who provide some windows/Linux driver but not enough detailed documentation. And we will likely see more such embedded devices in all sorts of inexpensive widgets. > Linux right now sort of reminds me of commercial Unix in the 90s. > Personally, I think something's going to come from out of left field > and displace it within the next 15 years, just like Linux displaced > (and yes, killed) commercial Unix. Compatibility shims for the API > will continue to exist, but the implementation will be very different. I wonder if the era of general purpose computers will survive. From usotsuki at buric.co Fri Jan 20 03:02:06 2023 From: usotsuki at buric.co (Steve Nickolas) Date: Thu, 19 Jan 2023 12:02:06 -0500 (EST) Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <202301190802.30J82KwQ025718@freefriends.org> <20230119150434.GA626@mcvoy.com> Message-ID: On Thu, 19 Jan 2023, Dan Cross wrote: > There were also a lot of gatekeepers. Perhaps not so much in CSRG, but > certainly in the next tier out: if you weren't part of the in-crowd at > USENIX and on USENET, it was hard to contribute. Ted has referred to > this as kowtowing to the "Gods of BSD." He wasn't wrong, though I > think the dynamic has changed substantially in recent years. I feel like Bill Jolitz was a sort of Prometheus, with Jolix bringing BSD to the masses, when those who were Above®™© didn't take the 386 and commodity hardware seriously. Jolix was a game-changer - though I feel it was like Banquo in the Scottish play®™© - "thou shalt get (beget) kings, though thou be none". Its descendants (especially FreeBSD and OpenBSD) have been more influential in the main than it was. -uso. From athornton at gmail.com Fri Jan 20 03:19:42 2023 From: athornton at gmail.com (Adam Thornton) Date: Thu, 19 Jan 2023 10:19:42 -0700 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <202301190802.30J82KwQ025718@freefriends.org> <20230119150434.GA626@mcvoy.com> Message-ID: The era of general-purpose computers won't end. The problem is that a great many single-purpose items are (and increasingly will be), for reasons of scale/developer availability/familiarity, general-purpose computers that come from the factory supposedly packaged to do only one thing. But all of them will have brains that will let them do arbitrary things. Some of these things will be done at the behest of the organizations controlling the society where the developers come from. Some of them will be done at the behest of transnational organized crime rings. Some will be done by enthusiasts. But I don't think we are too far from the world where you can't trust your toothbrush unless you carved it yourself from a stick with a knife that's been in your family for generations. But really, this is all just "Reflections on Trusting Trust," which was, what, 1984? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Fri Jan 20 03:50:12 2023 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 19 Jan 2023 12:50:12 -0500 (EST) Subject: [TUHS] Managers/architects (was: AIX moved into maintainance mode) Message-ID: <20230119175012.E7E7E18C074@mercury.lcs.mit.edu> > From: Larry McVoy > At least 30 years ago I said "He's good programmer, a good architect, > and a good manager. I've never seen that in one person before". Corby? Although he was just down the hall from me, I never saw him operating in any of those roles; maybe some of the old-time Unix people have some insight. Saltzer is about off-scale in #2; probably good as a manager (although I had a monumental blow-up with him in the hallway on the 5th floor, but I was pretty close to unmanageable when I was young ;-); he took over Athena when it was stumbling, and got it going. Dave Clark is high on all three - he could manage me! :-) Bob Taylor? PARC did some _incredibly_ important stuff in his time. Yes, I know a lot of the credit goes to those under him (Butler Lampson, Alan Kay - not sure if he was in Taylor's group, Boggs, Metcalfe, etc) but he had to manage them all. Not sure what his technical role was, though. Vint Cerf? Again, A1*** as a manager, but had some failings as a architect. I think the biggest share of the blame for the decision to remove the variable size addresses from TCP/IP3, and replace them with 32-bit addresses in TCP/IPv4, goes to him. (Alas, I was down the hall, not in the room, that day; I wasn't allowed in until the _next_ meeting. I like to think that if I'd been there, I could/would have pointed out the 'obvious' superior alternative - 'only length 4 must be supported at this time'.) Noel PS: ISTR that about a month ago someone was asking for management papers from that era (but I was too busy to reply); two good ones are: - F. J. Corbat??, C. T. Clingen, "A Managerial View of the Multics System Development" https://multicians.org/managerial.html - F. J. Corbat??, C. T. Clingen, and J. H. Saltzer, "Multics -- the first seven years" https://multicians.org/f7y.html From marc.donner at gmail.com Fri Jan 20 04:00:03 2023 From: marc.donner at gmail.com (Marc Donner) Date: Thu, 19 Jan 2023 13:00:03 -0500 Subject: [TUHS] Managers/architects (was: AIX moved into maintainance mode) In-Reply-To: <20230119175012.E7E7E18C074@mercury.lcs.mit.edu> References: <20230119175012.E7E7E18C074@mercury.lcs.mit.edu> Message-ID: I'd certainly list Bob Sproull for all three, from personal observation. My guess is that Ivan Sutherland probably qualified back when he still programmed ... I mean, after all, he invented the linked list in order to implement his thesis program (Sketchpad) in about 1960. ===== nygeek.net mindthegapdialogs.com/home On Thu, Jan 19, 2023 at 12:50 PM Noel Chiappa wrote: > > From: Larry McVoy > > > At least 30 years ago I said "He's good programmer, a good architect, > > and a good manager. I've never seen that in one person before". > > Corby? Although he was just down the hall from me, I never saw him > operating > in any of those roles; maybe some of the old-time Unix people have some > insight. Saltzer is about off-scale in #2; probably good as a manager > (although I had a monumental blow-up with him in the hallway on the 5th > floor, but I was pretty close to unmanageable when I was young ;-); he took > over Athena when it was stumbling, and got it going. Dave Clark is high on > all three - he could manage me! :-) > > Bob Taylor? PARC did some _incredibly_ important stuff in his time. Yes, I > know a lot of the credit goes to those under him (Butler Lampson, Alan Kay > - > not sure if he was in Taylor's group, Boggs, Metcalfe, etc) but he had to > manage them all. Not sure what his technical role was, though. > > Vint Cerf? Again, A1*** as a manager, but had some failings as a > architect. I > think the biggest share of the blame for the decision to remove the > variable > size addresses from TCP/IP3, and replace them with 32-bit addresses in > TCP/IPv4, goes to him. (Alas, I was down the hall, not in the room, that > day; > I wasn't allowed in until the _next_ meeting. I like to think that if I'd > been > there, I could/would have pointed out the 'obvious' superior alternative - > 'only length 4 must be supported at this time'.) > > Noel > > PS: ISTR that about a month ago someone was asking for management papers > from that era (but I was too busy to reply); two good ones are: > > - F. J. Corbat??, C. T. Clingen, "A Managerial View of the Multics > System Development" > https://multicians.org/managerial.html > - F. J. Corbat??, C. T. Clingen, and J. H. Saltzer, "Multics -- the > first seven years" > https://multicians.org/f7y.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sauer at technologists.com Fri Jan 20 04:09:09 2023 From: sauer at technologists.com (Charles H Sauer (he/him)) Date: Thu, 19 Jan 2023 12:09:09 -0600 Subject: [TUHS] Managers/architects (was: AIX moved into maintainance mode) In-Reply-To: References: <20230119175012.E7E7E18C074@mercury.lcs.mit.edu> Message-ID: <59029f83-d02c-e3a8-a82e-2eb14363a03e@technologists.com> Not trying to keep AIX in the discussion, but the 3 in 1 list should include Glenn Henry. Glenn was primarily a manager when I worked for him, but was an architect before then and is still a programmer -- see the summary at http://web.archive.org/web/20200105071617/http://www.ece.utexas.edu/events/centaur-technologys-deep-learning-coprocessor-technology and/or https://www.computerhistory.org/collections/catalog/102738382 Charlie On 1/19/2023 12:00 PM, Marc Donner wrote: > I'd certainly list Bob Sproull for all three, from personal observation. > > My guess is that Ivan Sutherland probably qualified back when he still > programmed ... I mean, after all, he invented the linked list in order > to implement his thesis program (Sketchpad) in about 1960. > ===== > nygeek.net > mindthegapdialogs.com/home > > > On Thu, Jan 19, 2023 at 12:50 PM Noel Chiappa > wrote: > >     > From: Larry McVoy > > >     > At least 30 years ago I said "He's good programmer, a good > architect, >     > and a good manager. I've never seen that in one person before". > > Corby? Although he was just down the hall from me, I never saw him > operating > in any of those roles; maybe some of the old-time Unix people have some > insight. Saltzer is about off-scale in #2; probably good as a manager > (although I had a monumental blow-up with him in the hallway on the 5th > floor, but I was pretty close to unmanageable when I was young ;-); > he took > over Athena when it was stumbling, and got it going. Dave Clark is > high on > all three - he could manage me! :-) > > Bob Taylor? PARC did some _incredibly_ important stuff in his time. > Yes, I > know a lot of the credit goes to those under him (Butler Lampson, > Alan Kay - > not sure if he was in Taylor's group, Boggs, Metcalfe, etc) but he > had to > manage them all. Not sure what his technical role was, though. > > Vint Cerf? Again, A1*** as a manager, but had some failings as a > architect. I > think the biggest share of the blame for the decision to remove the > variable > size addresses from TCP/IP3, and replace them with 32-bit addresses in > TCP/IPv4, goes to him. (Alas, I was down the hall, not in the room, > that day; > I wasn't allowed in until the _next_ meeting. I like to think that > if I'd been > there, I could/would have pointed out the 'obvious' superior > alternative - > 'only length 4 must be supported at this time'.) > >         Noel > > PS: ISTR that about a month ago someone was asking for management papers > from that era (but I was too busy to reply); two good ones are: > >   - F. J.  Corbat??, C. T. Clingen, "A Managerial View of the > Multics System Development" > https://multicians.org/managerial.html > >   - F. J. Corbat??, C. T. Clingen, and J. H. Saltzer, "Multics -- > the first seven years" > https://multicians.org/f7y.html > -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/Twitter: CharlesHSauer From tuhs at tuhs.org Fri Jan 20 04:22:40 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 19 Jan 2023 18:22:40 +0000 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <202301190802.30J82KwQ025718@freefriends.org> <20230119150434.GA626@mcvoy.com> Message-ID: Bringing it back around to AIX, this may be a bit of a leading question, but for those who are more in the know than not on how AIX works, is there any chance there are little design nuggets hidden down in there that now, not being critical to an active IBM project, may find their way out there into the world? This is kinda my latent curiosity with any of these commercial systems, if there's something absolutely amazing hiding down in one of the codebases just waiting to see the light of day in some post-commerical source release that might improve the situation out there in open source UNIX-like land. Some ideal SMP scheduler, quality drivers, etc. Of course, the usefulness of any such thing would depend on any theoretical eventual license applied to a source code release. Something restrictive would prevent proliferation of a good idea, but in any case, there are so many lineages just ripe for plundering, and as time goes on, it becomes more likely those source codes will actually be accessible and licensed to allow that. Who knows though... - Matt G. ------- Original Message ------- On Thursday, January 19th, 2023 at 9:19 AM, Adam Thornton wrote: > The era of general-purpose computers won't end. > > The problem is that a great many single-purpose items are (and increasingly will be), for reasons of scale/developer availability/familiarity, general-purpose computers that come from the factory supposedly packaged to do only one thing. > > But all of them will have brains that will let them do arbitrary things. Some of these things will be done at the behest of the organizations controlling the society where the developers come from. Some of them will be done at the behest of transnational organized crime rings. Some will be done by enthusiasts. But I don't think we are too far from the world where you can't trust your toothbrush unless you carved it yourself from a stick with a knife that's been in your family for generations. > > But really, this is all just "Reflections on Trusting Trust," which was, what, 1984? -------------- next part -------------- An HTML attachment was scrubbed... URL: From merlyn at geeks.org Fri Jan 20 04:24:34 2023 From: merlyn at geeks.org (Doug McIntyre) Date: Thu, 19 Jan 2023 12:24:34 -0600 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> <2f00f9a6-c57d-8490-4066-931ec6e191cd@gmail.com> <20230118164242.GG2964@mcvoy.com> Message-ID: On Thu, Jan 19, 2023 at 04:02:18PM +0100, Liam Proven wrote: > ChromeBooks outsold Mac in the USA in 2017, and worldwide by 2020. > (Sales have fallen off a cliff since the pandemic, but that's because > so many people have one and are happy with it, I think.) I think you need to s/people/schools/ on that statement. Education really ramped in that time frame to get every student a chromebook. I'd really like to see chromebook sales broken apart into consumer and education segments. From steffen at sdaoden.eu Fri Jan 20 03:46:53 2023 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 19 Jan 2023 18:46:53 +0100 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: <202301191512.30JFCmmI017248@freefriends.org> References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> <2f00f9a6-c57d-8490-4066-931ec6e191cd@gmail.com> <20230118164242.GG2964@mcvoy.com> <202301191512.30JFCmmI017248@freefriends.org> Message-ID: <20230119174653.-LlRf%steffen@sdaoden.eu> eh.. arnold at skeeve.com wrote in <202301191512.30JFCmmI017248 at freefriends.org>: |Liam Proven wrote: |> Secondly, the PRoC has a "5-3-2 programme" in place to compel all |> organisations to move to Linux and get rid of American OSes. Last year |> was the nominal completion when 98% of machines were to have been |> replaced or reinstalled; the assumption was that there would be at |> least 2% of Windows boxes that they _couldn't_ readily replace. |> |> https://www.theregister.com/2019/12/09/china_orders_ban_on_us_computers_\ |> and_software/ |> |> I've looked at OpenKylin. It's Ubuntu. Deepin is Debian underneath |> although they're planning to move away from it. | |OK, so far so good for the numbers, but how much do those distributions |let the PROC government monitor what its citizens are doing? There |are political, non-technical reasons to avoid anything coming out |of China. And yes, this is even way more off topic. ..here a non-movable stand for the opposite. (In fact China has always been my only hope. That is about fourty years now.) But surely very off-topic. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From kevin.bowling at kev009.com Fri Jan 20 05:07:21 2023 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Thu, 19 Jan 2023 12:07:21 -0700 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <202301190802.30J82KwQ025718@freefriends.org> <20230119150434.GA626@mcvoy.com> Message-ID: On Thu, Jan 19, 2023 at 11:23 AM segaloco via TUHS wrote: > > Bringing it back around to AIX, this may be a bit of a leading question, but for those who are more in the know than not on how AIX works, is there any chance there are little design nuggets hidden down in there that now, not being critical to an active IBM project, may find their way out there into the world? > > This is kinda my latent curiosity with any of these commercial systems, if there's something absolutely amazing hiding down in one of the codebases just waiting to see the light of day in some post-commerical source release that might improve the situation out there in open source UNIX-like land. Some ideal SMP scheduler, quality drivers, etc. There's definitely a lot of nice stuff in there, most "reviews" or recollections of AIX distill down to "OMG ODM" and completely miss the forest from the trees. I've seen some data and I think AIX scales, at least out of the box, much higher than Linux on massive CPU and NUMA systems. That may be a bit of a cause and effect, there's a likelihood of someone buying a top range POWER system to run as a single system image. However OpenSolaris provides a sober analysis of what you are after: 1) how much work is involved in open sourcing a commercial UNIX. The then CEO blogged about how he had personal involvement to get it done, and the high hurdle was lawyer work getting rights and approvals from third parties to re-license everything. AIX has, in addition to whatever vestiges of Bell/AT&T code, Bull and Motorola code and probably a lot of others (OSF, HP, Sun, etc are mentioned in the copyrights on install) whose rights may not exist in any recognizable form after 40 years. 2) how little is generally applicable outside a native environment. In terms of code, the main contribution from Solaris today outside of it is ZFS. The ports are all a bit of a side car (even in Illumos), Larry has pointed out on this list how hard they worked to get unified memory in SunOS only to have that lost again by ZFS. As some random anecdote, in FreeBSD there is a reference to Solaris prior to OpenSolaris here https://cgit.freebsd.org/src/commit/sys/kern/subr_turnstile.c?id=961a7b244dbfc467c112b7a594825da8c0a41acf and FreeBSD and macOS also use OpenBSM inspired by Sun. The BSDs occasionally share some code (usually drivers or higher level subsystems like ufs or pf) but as time goes on it seems more ideological than code since they have all drifted sufficiently from one another. So close study of any interesting AIX bits would be about as useful as code for cross pollination. On the other hand, source dumps are great for historical records and study. For instance, the heirloom tools (https://heirloom.sourceforge.net/doctools.html) came from the work done to open Solaris. If you get source control repos, it also gives you a nice whodunit. > Of course, the usefulness of any such thing would depend on any theoretical eventual license applied to a source code release. Something restrictive would prevent proliferation of a good idea, but in any case, there are so many lineages just ripe for plundering, and as time goes on, it becomes more likely those source codes will actually be accessible and licensed to allow that. Who knows though... > > - Matt G. > ------- Original Message ------- > On Thursday, January 19th, 2023 at 9:19 AM, Adam Thornton wrote: > > The era of general-purpose computers won't end. > > The problem is that a great many single-purpose items are (and increasingly will be), for reasons of scale/developer availability/familiarity, general-purpose computers that come from the factory supposedly packaged to do only one thing. > > But all of them will have brains that will let them do arbitrary things. Some of these things will be done at the behest of the organizations controlling the society where the developers come from. Some of them will be done at the behest of transnational organized crime rings. Some will be done by enthusiasts. But I don't think we are too far from the world where you can't trust your toothbrush unless you carved it yourself from a stick with a knife that's been in your family for generations. > > But really, this is all just "Reflections on Trusting Trust," which was, what, 1984? > > From will.senn at gmail.com Fri Jan 20 05:33:29 2023 From: will.senn at gmail.com (Will Senn) Date: Thu, 19 Jan 2023 13:33:29 -0600 Subject: [TUHS] The death of general purpose computers, was - AIX moved into maintainance mode In-Reply-To: <0882D9CA-FAC8-4EC6-BA82-CE1D457423E5@iitbombay.org> References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> <0882D9CA-FAC8-4EC6-BA82-CE1D457423E5@iitbombay.org> Message-ID: On 1/19/23 10:59 AM, Bakul Shah wrote: > I wonder if the era of general purpose computers will > survive. Provocative! I too wonder this and if the end of personalized computation is going the way of the dodo bird along with it. Is the future coming where I will only be allowed to run approved applications on my device (via something like an App store or somesuch)? I sure hope not, but it seems to be where we're headed. The good news being that those apps will be curated (not censored, right?) to just be good for me. From chet.ramey at case.edu Fri Jan 20 05:44:57 2023 From: chet.ramey at case.edu (Chet Ramey) Date: Thu, 19 Jan 2023 14:44:57 -0500 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> <2f00f9a6-c57d-8490-4066-931ec6e191cd@gmail.com> <20230118164242.GG2964@mcvoy.com> Message-ID: <8fc2596b-f950-831c-9de9-6927d6d4fddd@case.edu> On 1/19/23 1:24 PM, Doug McIntyre wrote: > On Thu, Jan 19, 2023 at 04:02:18PM +0100, Liam Proven wrote: >> ChromeBooks outsold Mac in the USA in 2017, and worldwide by 2020. >> (Sales have fallen off a cliff since the pandemic, but that's because >> so many people have one and are happy with it, I think.) > > I think you need to s/people/schools/ on that statement. Education really ramped > in that time frame to get every student a chromebook. I was on the school board during that period, including where we offered a hybrid learning model during covid, and I can confirm we did. But having committed to that policy, you have to keep purchasing for every incoming freshman class (or wherever you start), especially if you let the kids keep them when they graduate. 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 bakul at iitbombay.org Fri Jan 20 06:01:43 2023 From: bakul at iitbombay.org (Bakul Shah) Date: Thu, 19 Jan 2023 12:01:43 -0800 Subject: [TUHS] The era of general purpose computing (Re: AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <202301190802.30J82KwQ025718@freefriends.org> <20230119150434.GA626@mcvoy.com> Message-ID: On Jan 19, 2023, at 9:19 AM, Adam Thornton wrote: > > The era of general-purpose computers won't end. What I meant is it will likely become much more niche just like mainframe programming. What % of people running Chromebooks, Android or IOS do any real programming on it? Even for laptops and desktops that % is quite low. Most people run just a few apps. > The problem is that a great many single-purpose items are (and increasingly will be), for reasons of scale/developer availability/familiarity, general-purpose computers that come from the factory supposedly packaged to do only one thing. > > But all of them will have brains that will let them do arbitrary things. Some of these things will be done at the behest of the organizations controlling the society where the developers come from. Some of them will be done at the behest of transnational organized crime rings. Some will be done by enthusiasts. But I don't think we are too far from the world where you can't trust your toothbrush unless you carved it yourself from a stick with a knife that's been in your family for generations. > > But really, this is all just "Reflections on Trusting Trust," which was, what, 1984? What I was reflecting on is there may not be a real need for virtual memory if you are running just a few apps and memory is plentiful! We have relied on virtual memory for creating protection boundaries but that has not been enough. In Unix a child process has all the privileges a parent has. If instead the permission model for a new process is to permit only what it needs[1], including memory, you can get rid of containers (such as docker) and jails (as on FreeBSD). What is more, this can be done without virtual memory. Further, the same model can be extended to distributed computing. If this becomes reality, why wouldn't vendors go for that? So yes, the hardware will be capable of general purpose computing (Turing complete?) but will vendors allow access to it? [1] As Capability folks say, this is the Principle Of Least Authority or POLA. From usotsuki at buric.co Fri Jan 20 06:08:52 2023 From: usotsuki at buric.co (Steve Nickolas) Date: Thu, 19 Jan 2023 15:08:52 -0500 (EST) Subject: [TUHS] AIX moved into maintainance mode (fwd) Message-ID: Accidentally sent this only to the person I was replying to. > I am getting some grief on Twitter too for "omitting" FreeBSD. I > didn't, but the BSDs don't fit either definition of "Unix". The > pre-1993 one being "based on AT&T code" -- after all, BSD (4.4 Lite r2 > was it? Before my time!) -- went to a lot of effort to eliminate AT&T > code. >From what I've seen it's very much a gradual transition; 4.3-Tahoe starts to have the new code and UCB copyright notices with the predecessor of what we call the "BSD License" appearing in some of the source files. Then with Reno, a majority of the userland is open-sourced, and Net/2 is fairly complete. (Net/2 and 4.4BSD-Lite / Lite/2 were lacking a few things.) But even right up until the end things were in a state of flux. A few things weren't finished until much later by the FreeBSD, OpenBSD and NetBSD people. -uso. From tuhs at tuhs.org Fri Jan 20 06:09:43 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 19 Jan 2023 20:09:43 +0000 Subject: [TUHS] The death of general purpose computers, was - AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> <0882D9CA-FAC8-4EC6-BA82-CE1D457423E5@iitbombay.org> Message-ID: > Is the future coming where I will only be allowed to run approved applications > on my device (via something like an App store or somesuch)? This so much. I've gone full circle on smartphones by this point, begrudgingly accepted getting one at my parents behest many years ago, then ditched the thing in 2020 and never looked back. Luckily I never had the displeasure of an Apple device, so had a bit more control than they allow, but still didn't like the implications of smartphone OS norms. The idea that I can fully pay for and own a device and yet generally have to exploit some sort of security loophole or backdoor developer feature to actually use the device fully is completely asinine to me. I could see a case for not having root access on a phone that hasn't been paid off yet, but that root access isn't expressly granted on completion of a payment plan is an insult to users. It's a bummer too because I want to be excited about the idea of potentially having a powerful computer with me just about anywhere, but at the same time, if that power is significantly throttled (see Game "Optimizing" Service...), and full root access to the device is not granted easily, then it's not any more useful to me than a kiosk at Walmart. One thing that makes me particularly sad about the decrease in effective computer accessibility (effective being a loaded term here for root access, control of applications, etc.) is that having a good computer and access to the right information can make a subject-matter expert of anyone willing to put in the time. In my own experience, having relatively unimpeded access to computers since I was a kid is the key reason I've been able to learn so much. Taking that way and replacing it with stuff like Chromebooks and smart devices diminishes the likelihood of the right person having the right computer at the right time. Not to say that people won't still be inventive, but who knows what influence a bunch of Apple-ized computation will have on the next generation, vs the influence of relatively widespread and open systems in the decades preceding. - Matt G. From tuhs at tuhs.org Fri Jan 20 06:21:30 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 19 Jan 2023 20:21:30 +0000 Subject: [TUHS] AIX moved into maintainance mode (fwd) In-Reply-To: References: Message-ID: In my own internal narrative at least, my stance is BSD is UNIX moreso than not in that the code may have changed, there may not even be a lick of AT&T in there (not true, handful of files, SCO lawsuit, etc.), but it's still UNIX in design, much more than say something like Linux could be considered. It's like if some architect inherited the Empire State Building but was then told you can only do anything with it if you replace everything. In the end, it's still going to be different than taking a plot of land and deciding, hey, I want to build something like the Empire State Building. In the former sense, you can start to replace the windows, then the door, then the elevators, etc etc, over time, you see a gradual transition of A into B, which leads to unmistakable vestiges since they were actively being worked around and within in the replacement process. With the latter, you instead have an external vision of what you want to present, and may even be able to visibly present it better than the original since you are going ground up, best practices can be employed, etc. However, there is a high likelihood that you strip all the cladding and drywall away and the way the actual steel beams are arranged and the load bearing supports and such are likely radically different because they didn't have to be carefully created in a way to truss up the existing structure above them, they just had to be able to support that outward appearance everyone wants. Analogy over, that's just kinda how I think about that any time the question of BSD's "UNIX-ness" comes up. Neither building in the above scenario would be bad, they would just have different design goals informing how they work internally vs externally. BSD wanted to be UNIX compatible for folks familiar with every level, Linux just wanted to present a kernel that one could drop a UNIX-y userland on, but at least in my understanding replicating internal behaviors, structuring, and practices of UNIX was never a design goal/requirement. - Matt G. ------- Original Message ------- On Thursday, January 19th, 2023 at 12:08 PM, Steve Nickolas wrote: > Accidentally sent this only to the person I was replying to. > > > I am getting some grief on Twitter too for "omitting" FreeBSD. I > > didn't, but the BSDs don't fit either definition of "Unix". The > > pre-1993 one being "based on AT&T code" -- after all, BSD (4.4 Lite r2 > > was it? Before my time!) -- went to a lot of effort to eliminate AT&T > > code. > > > From what I've seen it's very much a gradual transition; 4.3-Tahoe starts to > have the new code and UCB copyright notices with the predecessor of what we call > the "BSD License" appearing in some of the source files. Then with Reno, a > majority of the userland is open-sourced, and Net/2 is fairly complete. (Net/2 > and 4.4BSD-Lite / Lite/2 were lacking a few things.) But even right up until > the end things were in a state of flux. > > A few things weren't finished until much later by the FreeBSD, OpenBSD and > NetBSD people. > > -uso. From g.branden.robinson at gmail.com Fri Jan 20 06:54:24 2023 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Thu, 19 Jan 2023 14:54:24 -0600 Subject: [TUHS] AIX moved into maintainance mode (fwd) In-Reply-To: References: Message-ID: <20230119205424.hjs32x2a3aq2rlzy@illithid> At 2023-01-19T20:21:30+0000, segaloco via TUHS wrote: > In my own internal narrative at least, my stance is BSD is UNIX moreso > than not in that the code may have changed, there may not even be a > lick of AT&T in there (not true, handful of files, SCO lawsuit, etc.), > but it's still UNIX in design, much more than say something like Linux > could be considered. It's like if some architect inherited the Empire > State Building but was then told you can only do anything with it if > you replace everything. > > In the end, it's still going to be different than taking a plot of > land and deciding, hey, I want to build something like the Empire > State Building. In the former sense, you can start to replace the > windows, then the door, then the elevators, etc etc, over time, you > see a gradual transition of A into B, which leads to unmistakable > vestiges since they were actively being worked around and within in > the replacement process. Engineers who (stereotypically) disdain the study of humanities seem frequently to discover the Ship of Theseus problem. ;-) Maybe TOG has the best approach after all; if your supercargo can pony up the gold and your pilot can navigate your craft between Scylla and Charybdis, you get to call it the Ship of Theseus, even if many others are afloat. :D 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 rdm at cfcl.com Fri Jan 20 06:59:05 2023 From: rdm at cfcl.com (Rich Morin) Date: Thu, 19 Jan 2023 12:59:05 -0800 Subject: [TUHS] The death of general purpose computers, was - AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> <0882D9CA-FAC8-4EC6-BA82-CE1D457423E5@iitbombay.org> Message-ID: <85349B1E-A388-4090-BB68-DD32349B18BE@cfcl.com> Several projects are attempting to target cell phones with (mostly) Linux variants (https://en.wikipedia.org/wiki/Linux_for_mobile_devices). Most of these are focused on particular (or even custom) hardware, but at least one has the explicit goal of supporting "old" hardware: > We are sick of not receiving updates shortly after buying new phones. Sick of the walled gardens deeply integrated into Android and iOS. That's why we are developing a sustainable, privacy and security focused free software mobile OS that is modeled after traditional Linux distributions. With privilege separation in mind. Let's keep our devices useful and safe until they physically break! https://postmarketos.org https://en.wikipedia.org/wiki/PostmarketOS I'm particularly interested in this project, because it might let a few billion (!) retired cell phones be used as portable computing and communication devices. Here is a current snapshot of their porting progress: https://wiki.postmarketos.org/wiki/Devices -r > On Jan 19, 2023, at 12:09, segaloco via TUHS wrote: > ... I want to be excited about the idea of potentially having a powerful computer with me just about anywhere, but at the same time, if that power is significantly throttled (see Game "Optimizing" Service...), and full root access to the device is not granted easily, then it's not any more useful to me than a kiosk at Walmart. ... From joseph at josephholsten.com Fri Jan 20 07:08:15 2023 From: joseph at josephholsten.com (Joseph Holsten) Date: Thu, 19 Jan 2023 13:08:15 -0800 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <202301190802.30J82KwQ025718@freefriends.org> <20230119150434.GA626@mcvoy.com> Message-ID: <8eca560b-ed37-4e0b-a517-88ede44e27ce@app.fastmail.com> On Thu, Jan 19, 2023, at 11:07, Kevin Bowling wrote: > However OpenSolaris provides a sober analysis of what you are after: > 1) how much work is involved in open sourcing a commercial UNIX. The > then CEO blogged about how he had personal involvement to get it done, > and the high hurdle was lawyer work getting rights and approvals from > third parties to re-license everything. AIX has, in addition to > whatever vestiges of Bell/AT&T code, Bull and Motorola code and > probably a lot of others (OSF, HP, Sun, etc are mentioned in the > copyrights on install) whose rights may not exist in any recognizable > form after 40 years. This really reminds me how much I wish there was the equivalent of a probate process for intellectual property “end of life” situations. Registered marks demand the onus be upon the registrant to actively enforce the monopoly protection or they lose the protection. But if you found a created work, you have no way of finding out who has claims upon it. And at this point, almost nothing is “sold” under a license that retains the right of first sale, but licensed. And the US hasn’t even gotten to the point where copy protected works expire their protection and we get to find out if it’s a DMCA violation to circumvent copy protection without an explicit grant from the Librarian of Congress. I mean, I know what 17USC§1201 seems to mean today, but who’s to know what those words will appear to have meant to their authors when interpreted many decades from now. From tuhs at tuhs.org Fri Jan 20 07:11:13 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 19 Jan 2023 21:11:13 +0000 Subject: [TUHS] The death of general purpose computers, was - AIX moved into maintainance mode In-Reply-To: <85349B1E-A388-4090-BB68-DD32349B18BE@cfcl.com> References: <202301180943.30I9hrOw030485@freefriends.org> <20230118161959.GE2964@mcvoy.com> <0882D9CA-FAC8-4EC6-BA82-CE1D457423E5@iitbombay.org> <85349B1E-A388-4090-BB68-DD32349B18BE@cfcl.com> Message-ID: <8fQF8C5GM3eA-3vxcwrxiUhMEFAFMOas2U5Dbtm9lxMI4jG0t_Yfoh1r1GfPBc14DgX1iJlXK_mZ1rrxiiPUDDTpiWRH4Ga9agLbBwINjRQ=@protonmail.com> Planned obsolescence is, in my opinion, one of the most disgusting concepts in the whole of engineering. The idea that anyone would, in good faith (HAH!), purposefully subvert reliability and dependability engineering solely to ensure frequent turnover of their product is mindboggling. At the very least it's my opinion that all these cell manufacturers (and lets face it, IoT manufacturers) designing their devices to be thrown away and replaced every couple of years should be 100% responsible for the environmental implications of shipping nominally temporary/destined for the scrap heap piles of heavy metals, plastics, etc, all over the globe. Instead these companies are shoveling tons and tons of resources into the market knowing they're going to be landfill material only a few years after release. Yeah there are recycling programs, but even then, it just feels like the general public being made to run on a treadmill of buy this, now donate it back for recycling, now buy the same resources again repackaged in a shiny new box. I'm willing to wager, security and protocol issues aside, most consumers would do just fine with computing technology circa the late 90's/early 00's still, but dangit that new iPhone has a couple more megapixels. - Matt G. ------- Original Message ------- On Thursday, January 19th, 2023 at 12:59 PM, Rich Morin wrote: > Several projects are attempting to target cell phones with (mostly) Linux variants (https://en.wikipedia.org/wiki/Linux_for_mobile_devices). Most of these are focused on particular (or even custom) hardware, but at least one has the explicit goal of supporting "old" hardware: > > > We are sick of not receiving updates shortly after buying new phones. Sick of the walled gardens deeply integrated into Android and iOS. That's why we are developing a sustainable, privacy and security focused free software mobile OS that is modeled after traditional Linux distributions. With privilege separation in mind. Let's keep our devices useful and safe until they physically break! > > > https://postmarketos.org > https://en.wikipedia.org/wiki/PostmarketOS > > I'm particularly interested in this project, because it might let a few billion (!) retired cell phones be used as portable computing and communication devices. Here is a current snapshot of their porting progress: > > https://wiki.postmarketos.org/wiki/Devices > > -r > > > On Jan 19, 2023, at 12:09, segaloco via TUHS tuhs at tuhs.org wrote: > > ... I want to be excited about the idea of potentially having a powerful computer with me just about anywhere, but at the same time, if that power is significantly throttled (see Game "Optimizing" Service...), and full root access to the device is not granted easily, then it's not any more useful to me than a kiosk at Walmart. ... From stewart at serissa.com Fri Jan 20 07:12:53 2023 From: stewart at serissa.com (Lawrence Stewart) Date: Thu, 19 Jan 2023 16:12:53 -0500 Subject: [TUHS] Managers/architects (was: AIX moved into maintainance mode) In-Reply-To: <20230119175012.E7E7E18C074@mercury.lcs.mit.edu> References: <20230119175012.E7E7E18C074@mercury.lcs.mit.edu> Message-ID: <75EC5F45-3AC0-49DA-9A01-9F39D45603B4@serissa.com> > > Bob Taylor? PARC did some _incredibly_ important stuff in his time. Yes, I > know a lot of the credit goes to those under him (Butler Lampson, Alan Kay - > not sure if he was in Taylor's group, Boggs, Metcalfe, etc) but he had to > manage them all. Not sure what his technical role was, though. > Taylor was an extraordinary manager, but neither a programmer nor architect. I’d certainly add Vic Vyssotsky as manager and technologist from my own experience and labs folklore, but I don’t know about programming or architecture. -Larry From will.senn at gmail.com Fri Jan 20 07:15:32 2023 From: will.senn at gmail.com (Will Senn) Date: Thu, 19 Jan 2023 15:15:32 -0600 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: <202301180943.30I9hrOw030485@freefriends.org> References: <202301180943.30I9hrOw030485@freefriends.org> Message-ID: On 1/18/23 3:43 AM, arnold at skeeve.com wrote: > https://www.theregister.com/2023/01/17/unix_is_dead/ > > FYI. > > Arnold Now that we're all off on a slew of tangents, I thought I would point out that AIX wasn't really moved into maintenance mode in recent days. It's been there a while. What happened recently was the movement of the onshore contingent, offshore. Unless somebody has some inside information beyond the register article and its sources? -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Fri Jan 20 07:30:42 2023 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Thu, 19 Jan 2023 16:30:42 -0500 Subject: [TUHS] Managers/architects (was: AIX moved into maintainance mode) Message-ID: > My guess is that Ivan Sutherland probably qualified back when he still > programmed ... I mean, after all, he invented the linked list in order to > implement his thesis program (Sketchpad) in about 1960. I don't know whether Sutherland invented the linked list, but if he did, it had to be before he worked on sketchpad. I attended a lecture about Lisp in 1959 in which McCarthy credited list-processing to IPL-V, whose roots Newell places in 1954. Sketchpad ran on TX 0, which became operational in 1956. My nomination for a triple-threat computer guy is Vic Vyssotsky. A great programmer, he invented the first stream-processing language (BLODI) and bitwise-parallel dataflow analysis. As an architect, he invented the single underlying address space for multics. As a manager, he oversaw the building of and later ran the lab that became AT&T Research. Finally he founded the DEC Cambridge Lab. He was a subtle diplomat, too, who more than once engineered reversals of policy without ruffling feathers. Relative to linked lists, I remember Vic perceptively touting the then startling usage J=NEXT(J).in Fortran. Doug From shout at drewdiver.com Fri Jan 20 07:34:19 2023 From: shout at drewdiver.com (Drew Diver) Date: Thu, 19 Jan 2023 22:34:19 +0100 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: References: Message-ID: <6AB175F8-EFFF-4FBD-9BDA-99DEB84A4201@drewdiver.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: favicon.ico Type: image/vnd.microsoft.icon Size: 198 bytes Desc: not available URL: From luther at makerlisp.com Fri Jan 20 08:23:00 2023 From: luther at makerlisp.com (Luther Johnson) Date: Thu, 19 Jan 2023 15:23:00 -0700 Subject: [TUHS] The era of general purpose computing (Re: AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <202301190802.30J82KwQ025718@freefriends.org> <20230119150434.GA626@mcvoy.com> Message-ID: <7cc2b7c5-5e98-9299-4fa8-a477fbf4ff77@makerlisp.com> Computers that are not smart phone-like are definitely on the endangered species list. You know, the kind on a desk, with a keyboard ... On 01/19/2023 01:01 PM, Bakul Shah wrote: > On Jan 19, 2023, at 9:19 AM, Adam Thornton wrote: >> The era of general-purpose computers won't end. > What I meant is it will likely become much more > niche just like mainframe programming. > > What % of people running Chromebooks, Android or IOS > do any real programming on it? Even for laptops and > desktops that % is quite low. Most people run just a > few apps. > >> The problem is that a great many single-purpose items are (and increasingly will be), for reasons of scale/developer availability/familiarity, general-purpose computers that come from the factory supposedly packaged to do only one thing. >> >> But all of them will have brains that will let them do arbitrary things. Some of these things will be done at the behest of the organizations controlling the society where the developers come from. Some of them will be done at the behest of transnational organized crime rings. Some will be done by enthusiasts. But I don't think we are too far from the world where you can't trust your toothbrush unless you carved it yourself from a stick with a knife that's been in your family for generations. >> >> But really, this is all just "Reflections on Trusting Trust," which was, what, 1984? > What I was reflecting on is there may not be a real > need for virtual memory if you are running just a few > apps and memory is plentiful! > > We have relied on virtual memory for creating protection > boundaries but that has not been enough. In Unix a child > process has all the privileges a parent has. If instead the > permission model for a new process is to permit only what > it needs[1], including memory, you can get rid of containers > (such as docker) and jails (as on FreeBSD). What is more, > this can be done without virtual memory. Further, the same > model can be extended to distributed computing. If this > becomes reality, why wouldn't vendors go for that? > > So yes, the hardware will be capable of general purpose > computing (Turing complete?) but will vendors allow access > to it? > > [1] As Capability folks say, this is the Principle Of > Least Authority or POLA. > > > From rich.salz at gmail.com Fri Jan 20 08:29:34 2023 From: rich.salz at gmail.com (Rich Salz) Date: Thu, 19 Jan 2023 17:29:34 -0500 Subject: [TUHS] The era of general purpose computing (Re: AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <202301190802.30J82KwQ025718@freefriends.org> <20230119150434.GA626@mcvoy.com> Message-ID: > What % of people running Chromebooks, Android or IOS > do any real programming on it? Even for laptops and > desktops that % is quite low. Most people run just a > few apps. > So what. How many people fix their own cars, TVs, etc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From luther at makerlisp.com Fri Jan 20 08:39:14 2023 From: luther at makerlisp.com (Luther Johnson) Date: Thu, 19 Jan 2023 15:39:14 -0700 Subject: [TUHS] The era of general purpose computing (Re: AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <202301190802.30J82KwQ025718@freefriends.org> <20230119150434.GA626@mcvoy.com> Message-ID: <4804766e-9c80-5d49-cbd0-ebea3d897df7@makerlisp.com> I think development environments will follow the people onto their preferred platforms, and will change or adapt as necessary. So the kind of computing we are used to, with a "computer", may become more and more marginalized. Business will go where the numbers are, and what we think of as mainstream will become "retro" or "vintage". Most of my acquaintances who are 20 or 30 years younger than me, or my now-grown children, already think using a "computer" is kind of a "boomer" thing. On 01/19/2023 03:29 PM, Rich Salz wrote: > > What % of people running Chromebooks, Android or IOS > do any real programming on it? Even for laptops and > desktops that % is quite low. Most people run just a > few apps. > > > So what. How many people fix their own cars, TVs, etc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Fri Jan 20 08:40:12 2023 From: jon at fourwinds.com (Jon Steinhart) Date: Thu, 19 Jan 2023 14:40:12 -0800 Subject: [TUHS] The era of general purpose computing (Re: AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <202301190802.30J82KwQ025718@freefriends.org> <20230119150434.GA626@mcvoy.com> Message-ID: <202301192240.30JMeDnC1925842@darkstar.fourwinds.com> Rich Salz writes: > > What % of people running Chromebooks, Android or IOS > > do any real programming on it? Even for laptops and > > desktops that % is quite low. Most people run just a > > few apps. > > > > So what. How many people fix their own cars, TVs, etc. Probably not a lot, but having just finished diagnosing a failing sensor in one of my heat pumps I'm one of them :-) In my opinion, the biggest threat comes from folks like Apple who are minimizing their use of off-the-shelf mass-market components. Those won't be available if demand fades. Just like with soldered-in memory chips, we're lucky that we can still buy disk drives that work with any system. While I personally want to be able to decide how to handle stuff that I own (another fading concept), my big concern is the long term effects of making it harder for people to experiment and innovate. Lack of general purpose components or needing keys and licenses to tinker means less tinkering which likely translates to less innovation which likely translates to less long-term prosperity. Jon From luther at makerlisp.com Fri Jan 20 08:41:03 2023 From: luther at makerlisp.com (Luther Johnson) Date: Thu, 19 Jan 2023 15:41:03 -0700 Subject: [TUHS] The era of general purpose computing (Re: AIX moved into maintainance mode In-Reply-To: <4804766e-9c80-5d49-cbd0-ebea3d897df7@makerlisp.com> References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <202301190802.30J82KwQ025718@freefriends.org> <20230119150434.GA626@mcvoy.com> <4804766e-9c80-5d49-cbd0-ebea3d897df7@makerlisp.com> Message-ID: <06f13d64-d864-6aaa-4b39-c2c89a55dc06@makerlisp.com> To be fair, one of my kids is an engineer, and definitely has several computers. But the others who are not, do not have personal computers, they have phones. On 01/19/2023 03:39 PM, Luther Johnson wrote: > > I think development environments will follow the people onto their > preferred platforms, and will change or adapt as necessary. So the > kind of computing we are used to, with a "computer", may become more > and more marginalized. Business will go where the numbers are, and > what we think of as mainstream will become "retro" or "vintage". Most > of my acquaintances who are 20 or 30 years younger than me, or my > now-grown children, already think using a "computer" is kind of a > "boomer" thing. > > On 01/19/2023 03:29 PM, Rich Salz wrote: >> >> What % of people running Chromebooks, Android or IOS >> do any real programming on it? Even for laptops and >> desktops that % is quite low. Most people run just a >> few apps. >> >> >> So what. How many people fix their own cars, TVs, etc. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Fri Jan 20 09:16:12 2023 From: tytso at mit.edu (Theodore Ts'o) Date: Thu, 19 Jan 2023 18:16:12 -0500 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <202301190802.30J82KwQ025718@freefriends.org> <20230119150434.GA626@mcvoy.com> Message-ID: On Thu, Jan 19, 2023 at 09:58:48AM -0700, Warner Losh wrote: > On Thu, Jan 19, 2023 at 9:41 AM Dan Cross wrote: > > > But it's interesting the way the "Gods of BSD vs the rebel alliance" > > thing seems to have inverted itself. Getting stuff done in Linux these > > days is pretty hard; oh sure, I suppose if you whip off a patch fixing > > a typo in a comment or something, someone will just apply it. But if > > you want to do something substantial, you have to be willing to invest > > a lot of time and effort in shepherding it through the upstreaming > > process, which implies you've got to have resources backing that > > effort..... > > This matches my experience: Lots of gatekeepers, any one of which can take > a disliking to your submission for what, at times, seems like arbitrary and > capricious reasons. If you make it to the 'in crowd' it becomes more of a > rubber stamp at times... I have recently been successful at submitting an > obvious fix to a tiny backwater area of the kernel without undue stress > though... But I submitted it to the maintainer of the area, who then > submitted it to the 'greater maintainer', and then to the greater > maintainer and then to the tree. So my tiny fix has more Signed-off-by: > lines than lines of change and took about two weeks to make its way all the > way up into the repo... For me, it took about 2x as long to prep and send > the change than it does for the direct commit access I have for FreeBSD, > but I've spent more than 10x on other submissions that ultimately didn't > make it in. I'll note that a lot of this is a matter of scale. There are roughly 15,000 commits added to the Linux kernel per 9 week release cycle. That translates to roughly 10 commits per hour, 7 days a week, 24 hours a day. >From an upstream maintainer's perspective, what matters is whether a commit handled in time for it to make the next release train. So whether it takes two days or two weeks to get a patch in the repo is not considered important. What *is* important is that commits that are up for review before, say, at least two weeks before the opening of the merge window, are reviewed in time for them to be pulled into Linus's tree when the merge window next opens. If it is an urgent bug fix, then it will be acted upon more expeditiously, but the reality is most users won't see it until the the fix is backported into the Long-Term Stable kernel that their distribution or product kernel is derived from. For more substantial contributions, one of the reasons why there are so many gatekeepers is mainly due to the fact that we've had far too many cases of "drive-by contributions" where a company tries to dump a whole new file system, or massive changes to a large number of systems --- and then once the code lands in the tree, the developers vanish. And now we're left with the question of whether we just drop the subsystems, and screw-over the users who have started to depend on the new functionality. This may be one of the places where the Linux culture of "thou shall never cause user-space visible regressions" has its downside --- it means that it's a lot harder to accept new functionality unless there is strong confidence that contributor is there for the long haul, and admittedly that's a lot easier if you are a member of the "in-crowd". > I looked into Linux's processes to improve FreeBSD's. And came to the > conclusion that in large part they succeed despite their processes, not > because of them. They have too much overhead, rely too much on magic bots > that are hard to replicate and I'm astonished that things work as well as > they do. I think that if you divide the total overhead by the number of commits that land in each release, the overhead isn't really that bad. Sure, a tractor-trailer truck has a lot more overhead than say, a bicycle; but you can haul an awful lot more in a semi-trailer truck than you can in a bicycle rack. Hence, the overhead of a semi is arguably much less, once you take into account how much you can fit in a tractor-trailer. Also, it's actually not *that* expensive, even in absolute terms. For example, I run about 26 hours worth of regression tests (using a dozen VM's, so the wall clock time is about 2 hours), using gce-xfstests[1], and the retail cost if I didn't have corporate sponsorship is less than $2 USD for a complete set of ext4 tests. And I made a point of making well documented and easy for others to standup so they can test their own file systems if they want. The reason why I did all of this packaging work was to try to get graduate students to understand how much work left to get a publishable file system, such as say BetrFS[3], into a production-ready state for real-world use. :-) [1] https://thunk.org/gce-xfstests [2] https://github.com/tytso/xfstests-bld/blob/master/Documentation/gce-xfstests.md [3] https://www.usenix.org/conference/fast15/technical-sessions/presentation/jannen > It's a grown culture / process that relies on old tools mixed with > new in weird ways you'd never think of standing up today. Things can be > learned from it, but it seems to be a unique snowflake relative to all the > other projects I looked at... That's fair enough. What is needed for a particular scale may be massive overkill for another. All projects will probably be needing to adopt different processes or tools as they grow. Similar statements have made about whether startups or other small projects should use Kubernetes[4]. Kubernetes was designed by Google based on their learnings from their in-house cluster management systems, borg. But if you aren't running at that scale, it may have more overhead and complexity than what really makes sense. [4] https://blog.porter.run/when-to-use-kubernetes-as-a-startup/ I'm reminded of a talk that given by an engineer from Alibaba at LinuxCon China 2017 where he was bragging about how they had finally achieved the scaling necessasry so they could support over a thousand servers in a data center, and how this was an incredible achievement. That was especially funny to me, since right about that time, Google had just finished an engineering effort to scale our cluster management software *down* to a O(thousand) servers, in order to efficiently support "mini-clusters" that could be deployed in smaller data centers various countries in Europe, Asia, etc. :-) And later, even *more* engineering work was needed to efficiently support O(hundreds) servers for Stadia. What works well at one scale, may not work well at others, either when scaling up or scaling down. Cheers, - Ted From tuhs at tuhs.org Fri Jan 20 09:24:58 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 19 Jan 2023 23:24:58 +0000 Subject: [TUHS] The era of general purpose computing (Re: AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301190802.30J82KwQ025718@freefriends.org> <20230119150434.GA626@mcvoy.com> Message-ID: In my mind there would probably be a strong correlation between engineers making products unnecessarily complicated (whether they want to or not) and end users deciding en masse not to sink the time into learning how to maintain increasingly convoluted and esoteric designs. On the flip-side, a push towards modularity and maintainability would likely result in more folks feeling some confidence they can work on things themselves. Long story short, computers aren't getting more complicated as a *result* of folks turning their nose up at maintenance, that's rather a symptom of the bigger planned obsolescence game. I highly doubt the number of people who would or wouldn't want to be able to fix something even occurs to the corporate overlords, they see dollar signs, not QoL for their customers. - Matt G. ------- Original Message ------- On Thursday, January 19th, 2023 at 2:29 PM, Rich Salz wrote: >> What % of people running Chromebooks, Android or IOS >> do any real programming on it? Even for laptops and >> desktops that % is quite low. Most people run just a >> few apps. > > So what. How many people fix their own cars, TVs, etc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Fri Jan 20 09:44:07 2023 From: rich.salz at gmail.com (Rich Salz) Date: Thu, 19 Jan 2023 18:44:07 -0500 Subject: [TUHS] The era of general purpose computing (Re: AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301190802.30J82KwQ025718@freefriends.org> <20230119150434.GA626@mcvoy.com> Message-ID: > In my mind there would probably be a strong correlation between engineers > making products unnecessarily complicated (whether they want to or not) and > end users deciding en masse not to sink the time into learning how to > maintain increasingly convoluted and esoteric designs. > To me, the biggest surprise about Unix history is that the Bell patent office secretaries were able to use ed and [nt]roff. I cannot imagine the general populace doing that. Folks on this list will be fine, there will always be programming environments for us. For the rest of the world, simpler is better and simpler isn't Unix. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Fri Jan 20 09:51:39 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 19 Jan 2023 23:51:39 +0000 Subject: [TUHS] The era of general purpose computing (Re: AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> Message-ID: To be fair I didn't necessarily just have UNIX in mind with that statement, I also mean whats happening to appliances, vehicles, etc. It's part of a bigger problem, we're just of course mostly discussing the implications of that problem vis-a-vis UNIX. Believe me, I also wish I could peer under the hood of a modern car and tell you how to actually replace something in there with just a socket and a set of pliers... - Matt G. ------- Original Message ------- On Thursday, January 19th, 2023 at 3:44 PM, Rich Salz wrote: >> In my mind there would probably be a strong correlation between engineers making products unnecessarily complicated (whether they want to or not) and end users deciding en masse not to sink the time into learning how to maintain increasingly convoluted and esoteric designs. > > To me, the biggest surprise about Unix history is that the Bell patent office secretaries were able to use ed and [nt]roff. I cannot imagine the general populace doing that. > > Folks on this list will be fine, there will always be programming environments for us. For the rest of the world, simpler is better and simpler isn't Unix. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sauer at technologists.com Fri Jan 20 10:20:20 2023 From: sauer at technologists.com (Charles H Sauer (he/him)) Date: Thu, 19 Jan 2023 18:20:20 -0600 Subject: [TUHS] owner maintenance (Re: The era of general purpose computing (Re: AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> Message-ID: <39941541-8461-20c5-8433-978c1cc59454@technologists.com> Before Lions, before the Epoch even, there was Muir's Compleat Idiot manual (https://technologists.com/photos/1960s/fullsize/1969JohnMuir.jpg) which suited me well until it didn't. Charlie On 1/19/2023 5:51 PM, segaloco via TUHS wrote: > To be fair I didn't necessarily just have UNIX in mind with that > statement, I also mean whats happening to appliances, vehicles, etc. > It's part of a bigger problem, we're just of course mostly discussing > the implications of that problem vis-a-vis UNIX. Believe me, I also wish > I could peer under the hood of a modern car and tell you how to actually > replace something in there with just a socket and a set of pliers... > > - Matt G. > > ------- Original Message ------- > On Thursday, January 19th, 2023 at 3:44 PM, Rich Salz > wrote: > >> >> In my mind there would probably be a strong correlation between >> engineers making products unnecessarily complicated (whether they >> want to or not) and end users deciding en masse not to sink the >> time into learning how to maintain increasingly convoluted and >> esoteric designs. >> >> >> To me, the biggest surprise about Unix history is that the Bell patent >> office secretaries were able to use ed and [nt]roff. I cannot imagine >> the general populace doing that. >> >> Folks on this list will be fine, there will always be programming >> environments for us. For the rest of the world, simpler is better and >> simpler isn't Unix. > -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/Twitter: CharlesHSauer From lm at mcvoy.com Fri Jan 20 10:36:38 2023 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 19 Jan 2023 16:36:38 -0800 Subject: [TUHS] owner maintenance (Re: The era of general purpose computing (Re: AIX moved into maintainance mode In-Reply-To: <39941541-8461-20c5-8433-978c1cc59454@technologists.com> References: <39941541-8461-20c5-8433-978c1cc59454@technologists.com> Message-ID: <20230120003638.GH12196@mcvoy.com> That book was AWESOME. I'm pretty sure the intro talked about warming up your VW and said "the time to roll a joint is just about long enough". More seriously, I wish all manuals were written like that, I learned a ton from that book. The Honda one wasn't as good. On Thu, Jan 19, 2023 at 06:20:20PM -0600, Charles H Sauer (he/him) wrote: > Before Lions, before the Epoch even, there was Muir's Compleat Idiot manual > (https://technologists.com/photos/1960s/fullsize/1969JohnMuir.jpg) which > suited me well until it didn't. Charlie > > On 1/19/2023 5:51 PM, segaloco via TUHS wrote: > >To be fair I didn't necessarily just have UNIX in mind with that > >statement, I also mean whats happening to appliances, vehicles, etc. It's > >part of a bigger problem, we're just of course mostly discussing the > >implications of that problem vis-a-vis UNIX. Believe me, I also wish I > >could peer under the hood of a modern car and tell you how to actually > >replace something in there with just a socket and a set of pliers... > > > >- Matt G. > > > >------- Original Message ------- > >On Thursday, January 19th, 2023 at 3:44 PM, Rich Salz > > wrote: > > > >> > >> In my mind there would probably be a strong correlation between > >> engineers making products unnecessarily complicated (whether they > >> want to or not) and end users deciding en masse not to sink the > >> time into learning how to maintain increasingly convoluted and > >> esoteric designs. > >> > >> > >>To me, the biggest surprise about Unix history is that the Bell patent > >>office secretaries were able to use ed and [nt]roff. I cannot imagine > >>the general populace doing that. > >> > >>Folks on this list will be fine, there will always be programming > >>environments for us. For the rest of the world, simpler is better and > >>simpler isn't Unix. > > > > -- > voice: +1.512.784.7526 e-mail: sauer at technologists.com > fax: +1.512.346.5240 Web: https://technologists.com/sauer/ > Facebook/Google/Twitter: CharlesHSauer -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From imp at bsdimp.com Fri Jan 20 10:37:27 2023 From: imp at bsdimp.com (Warner Losh) Date: Thu, 19 Jan 2023 17:37:27 -0700 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <202301190802.30J82KwQ025718@freefriends.org> <20230119150434.GA626@mcvoy.com> Message-ID: On Thu, Jan 19, 2023 at 4:16 PM Theodore Ts'o wrote: > On Thu, Jan 19, 2023 at 09:58:48AM -0700, Warner Losh wrote: > > On Thu, Jan 19, 2023 at 9:41 AM Dan Cross wrote: > > > > > But it's interesting the way the "Gods of BSD vs the rebel alliance" > > > thing seems to have inverted itself. Getting stuff done in Linux these > > > days is pretty hard; oh sure, I suppose if you whip off a patch fixing > > > a typo in a comment or something, someone will just apply it. But if > > > you want to do something substantial, you have to be willing to invest > > > a lot of time and effort in shepherding it through the upstreaming > > > process, which implies you've got to have resources backing that > > > effort..... > > > > This matches my experience: Lots of gatekeepers, any one of which can > take > > a disliking to your submission for what, at times, seems like arbitrary > and > > capricious reasons. If you make it to the 'in crowd' it becomes more of a > > rubber stamp at times... I have recently been successful at submitting > an > > obvious fix to a tiny backwater area of the kernel without undue stress > > though... But I submitted it to the maintainer of the area, who then > > submitted it to the 'greater maintainer', and then to the greater > > maintainer and then to the tree. So my tiny fix has more Signed-off-by: > > lines than lines of change and took about two weeks to make its way all > the > > way up into the repo... For me, it took about 2x as long to prep and > send > > the change than it does for the direct commit access I have for FreeBSD, > > but I've spent more than 10x on other submissions that ultimately didn't > > make it in. > > I'll note that a lot of this is a matter of scale. There are roughly > 15,000 commits added to the Linux kernel per 9 week release cycle. > That translates to roughly 10 commits per hour, 7 days a week, 24 > hours a day. > All of FreeBSD is right around 5-6 per hour: FreeBSD/ports is about 4 per hour, FreeBSD/src is about 1 per hour FreeBSD's kernel is 1/2 per hour. Docs is about 1/5/hr. I'm surprised the commit rate to the Linux kernel is only 20x that of FreeBSD's kernel and only about twice that of the whole FreeBSD project. > From an upstream maintainer's perspective, what matters is whether a > commit handled in time for it to make the next release train. So > whether it takes two days or two weeks to get a patch in the repo is > not considered important. What *is* important is that commits that > are up for review before, say, at least two weeks before the opening > of the merge window, are reviewed in time for them to be pulled into > Linus's tree when the merge window next opens. If it is an urgent bug > fix, then it will be acted upon more expeditiously, but the reality is > most users won't see it until the the fix is backported into the > Long-Term Stable kernel that their distribution or product kernel is > derived from. > I understand review. I have to do it on lots of other projects I contribute to. However, there's a lot of inefficiency in how this task happens. > For more substantial contributions, one of the reasons why there are > so many gatekeepers is mainly due to the fact that we've had far too > many cases of "drive-by contributions" where a company tries to dump a > whole new file system, or massive changes to a large number of systems > --- and then once the code lands in the tree, the developers vanish. > And now we're left with the question of whether we just drop the > subsystems, and screw-over the users who have started to depend on the > new functionality. This may be one of the places where the Linux > culture of "thou shall never cause user-space visible regressions" has > its downside --- it means that it's a lot harder to accept new > functionality unless there is strong confidence that contributor is > there for the long haul, and admittedly that's a lot easier if you are > a member of the "in-crowd". > I understand why things were built, but that doesn't mean they are the right solution to the problems the policies are trying to solve. > > I looked into Linux's processes to improve FreeBSD's. And came to the > > conclusion that in large part they succeed despite their processes, not > > because of them. They have too much overhead, rely too much on magic bots > > that are hard to replicate and I'm astonished that things work as well as > > they do. > > I think that if you divide the total overhead by the number of commits > that land in each release, the overhead isn't really that bad. Sure, > a tractor-trailer truck has a lot more overhead than say, a bicycle; > but you can haul an awful lot more in a semi-trailer truck than you > can in a bicycle rack. Hence, the overhead of a semi is arguably much > less, once you take into account how much you can fit in a > tractor-trailer. > I feel like I've been hit by a tractor trailer when I try to contribute to Linux sometimes... But the overhead is feels way higher than other projects that are moving at the same order of magnitude as the Linux kernel. I'd have expected the rate to be closer to 100/hr or 1000/hr given the differential usage between it and FreeBSD... > Also, it's actually not *that* expensive, even in absolute terms. For > example, I run about 26 hours worth of regression tests (using a dozen > VM's, so the wall clock time is about 2 hours), using gce-xfstests[1], > and the retail cost if I didn't have corporate sponsorship is less > than $2 USD for a complete set of ext4 tests. And I made a point of > making well documented and easy for others to standup so they can test > their own file systems if they want. The reason why I did all of this > packaging work was to try to get graduate students to understand how > much work left to get a publishable file system, such as say > BetrFS[3], into a production-ready state for real-world use. :-) > Indeed. These sorts of tests are indeed a good thing, and are quite a bit more extensive than similar projects I've contributed to. > [1] https://thunk.org/gce-xfstests > [2] > https://github.com/tytso/xfstests-bld/blob/master/Documentation/gce-xfstests.md > [3] > https://www.usenix.org/conference/fast15/technical-sessions/presentation/jannen > > > > It's a grown culture / process that relies on old tools mixed with > > new in weird ways you'd never think of standing up today. Things can be > > learned from it, but it seems to be a unique snowflake relative to all > the > > other projects I looked at... > > That's fair enough. What is needed for a particular scale may be > massive overkill for another. All projects will probably be needing > to adopt different processes or tools as they grow. > > Similar statements have made about whether startups or other small > projects should use Kubernetes[4]. Kubernetes was designed by Google > based on their learnings from their in-house cluster management > systems, borg. But if you aren't running at that scale, it may have > more overhead and complexity than what really makes sense. > > [4] https://blog.porter.run/when-to-use-kubernetes-as-a-startup/ > > I'm reminded of a talk that given by an engineer from Alibaba at > LinuxCon China 2017 where he was bragging about how they had finally > achieved the scaling necessasry so they could support over a thousand > servers in a data center, and how this was an incredible achievement. > > That was especially funny to me, since right about that time, Google > had just finished an engineering effort to scale our cluster > management software *down* to a O(thousand) servers, in order to > efficiently support "mini-clusters" that could be deployed in smaller > data centers various countries in Europe, Asia, etc. :-) > Indeed. Netflix has been operating a global video operation with thousands of servers for many years now... Thought the problem sets are different, and the non-video-serving folks use a lot more in the cloud for all the data analysis... > And later, even *more* engineering work was needed to efficiently > support O(hundreds) servers for Stadia. > > What works well at one scale, may not work well at others, either when > scaling up or scaling down. > Indeed. But one also should take a look at the overheads and inefficiencies, or you run the risk that someone else will be able to operate at a similar scale with less effort. And it seems to me, as mostly an outsider, that the overheads might become a bigger problem, especially if we have a prolonged downturn. Just my opinion, though. Warner > Cheers, > > - Ted > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ylee at columbia.edu Fri Jan 20 10:47:23 2023 From: ylee at columbia.edu (Yeechang Lee) Date: Thu, 19 Jan 2023 16:47:23 -0800 Subject: [TUHS] The era of general purpose computing (Re: AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301190802.30J82KwQ025718@freefriends.org> <20230119150434.GA626@mcvoy.com> Message-ID: <25545.58523.4766.431157@dobie-old.ylee.org> Rich Salz says: > To me, the biggest surprise about Unix history is that the Bell > patent office secretaries were able to use ed and [nt]roff. I've similarly heard that Sun secretaries were pretty adept at using Emacs. -- geo:37.783333,-122.416667 From ggm at algebras.org Fri Jan 20 10:55:37 2023 From: ggm at algebras.org (George Michaelson) Date: Fri, 20 Jan 2023 10:55:37 +1000 Subject: [TUHS] The era of general purpose computing (Re: AIX moved into maintainance mode In-Reply-To: <25545.58523.4766.431157@dobie-old.ylee.org> References: <202301180943.30I9hrOw030485@freefriends.org> <202301190802.30J82KwQ025718@freefriends.org> <20230119150434.GA626@mcvoy.com> <25545.58523.4766.431157@dobie-old.ylee.org> Message-ID: Mike Lesk is interesting on this. He said to me that if you assume people are idiots they learn to behave to your expectations and if you treat them with the respect they deserve they grow. It was in the context of library index systems and "do you want easy mode" clippy style vs terse but functional. Many specialist secretary roles in times past were simply underpaid subject matter experts even on a typing pool. Huge amounts of expert knowledge. The data entry staff at Edinburgh uni notoriously corrected student programs doing cardpunch work. There's no 'just' in women's work. As the Chinese maoist poster said: "women hold up half the sky". G On Fri, 20 Jan 2023, 10:47 Yeechang Lee, wrote: > Rich Salz says: > > To me, the biggest surprise about Unix history is that the Bell > > patent office secretaries were able to use ed and [nt]roff. > > I've similarly heard that Sun secretaries were pretty adept at using Emacs. > > -- > geo:37.783333,-122.416667 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Fri Jan 20 11:05:55 2023 From: rich.salz at gmail.com (Rich Salz) Date: Thu, 19 Jan 2023 20:05:55 -0500 Subject: [TUHS] The era of general purpose computing (Re: AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301190802.30J82KwQ025718@freefriends.org> <20230119150434.GA626@mcvoy.com> <25545.58523.4766.431157@dobie-old.ylee.org> Message-ID: : > Mike Lesk is interesting on this. He said to me that if you assume people > are idiots they learn to behave to your expectations and if you treat them > with the respect they deserve they grow. > This is well-known in the fields of management and teaching. > There's no 'just' in women's work. As the Chinese maoist poster said: > "women hold up half the sky" > I never said women, I said secretaries. Deliberately so. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggm at algebras.org Fri Jan 20 11:10:32 2023 From: ggm at algebras.org (George Michaelson) Date: Fri, 20 Jan 2023 11:10:32 +1000 Subject: [TUHS] The era of general purpose computing (Re: AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301190802.30J82KwQ025718@freefriends.org> <20230119150434.GA626@mcvoy.com> <25545.58523.4766.431157@dobie-old.ylee.org> Message-ID: >> There's no 'just' in women's work. As the Chinese maoist poster said: "women hold up half the sky" > > > I never said women, I said secretaries. Deliberately so. I apologize Rich, I brought my own cultural interpretations to the table. My fault. _G From cowan at ccil.org Fri Jan 20 11:10:47 2023 From: cowan at ccil.org (John Cowan) Date: Thu, 19 Jan 2023 20:10:47 -0500 Subject: [TUHS] The era of general purpose computing (Re: AIX moved into maintainance mode In-Reply-To: <7cc2b7c5-5e98-9299-4fa8-a477fbf4ff77@makerlisp.com> References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <202301190802.30J82KwQ025718@freefriends.org> <20230119150434.GA626@mcvoy.com> <7cc2b7c5-5e98-9299-4fa8-a477fbf4ff77@makerlisp.com> Message-ID: On Thu, Jan 19, 2023 at 5:23 PM Luther Johnson wrote: Computers that are not smart phone-like are definitely on the endangered > species list. You know, the kind on a desk, with a keyboard ... > I don't have statistics for this, but I doubt it. Consider amateur radio, which has been around for a century now. Amateur stations are an ever-shrinking *fraction* of all transmitters, to say nothing of receivers, but in absolute terms there are now more than 2 million hams in the world, which is almost certainly more than ever. -------------- next part -------------- An HTML attachment was scrubbed... URL: From luther at makerlisp.com Fri Jan 20 11:15:46 2023 From: luther at makerlisp.com (Luther Johnson) Date: Thu, 19 Jan 2023 18:15:46 -0700 Subject: [TUHS] The era of general purpose computing (Re: AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <202301190802.30J82KwQ025718@freefriends.org> <20230119150434.GA626@mcvoy.com> <7cc2b7c5-5e98-9299-4fa8-a477fbf4ff77@makerlisp.com> Message-ID: <75cfc721-a662-ddea-1188-767462d747ae@makerlisp.com> Well, that's a comforting thought, I hope it goes that way. On 01/19/2023 06:10 PM, John Cowan wrote: > > > On Thu, Jan 19, 2023 at 5:23 PM Luther Johnson > wrote: > > Computers that are not smart phone-like are definitely on the > endangered > species list. You know, the kind on a desk, with a keyboard ... > > > I don't have statistics for this, but I doubt it. Consider amateur > radio, which has been around for a century now. Amateur stations are > an ever-shrinking *fraction* of all transmitters, to say nothing of > receivers, but in absolute terms there are now more than 2 million > hams in the world, which is almost certainly more than ever. -------------- next part -------------- An HTML attachment was scrubbed... URL: From usotsuki at buric.co Fri Jan 20 11:22:57 2023 From: usotsuki at buric.co (Steve Nickolas) Date: Thu, 19 Jan 2023 20:22:57 -0500 (EST) Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <202301190802.30J82KwQ025718@freefriends.org> <20230119150434.GA626@mcvoy.com> Message-ID: I guess this is the best place to jump in: I've been working for some time on a stupid idea, and it involves both the System V code (in the form of Solaris, although I've been attempting to theseus it out) and the BSDs. One thing I've said a few times elsewhere is - if you want to do something daft, not only are you on your own, but people will actively not only dissuade but derail you from trying to do it. I felt the best way to get what I wanted was to try to isolate the kernel and libc (and perhaps bootloader) from one of the BSDs and attempt to make them buildable through a system of plain makefiles, to integrate into the rest of my concept (this also includes, fwiw but unrelated, clang). If you're familiar with Linux From Scratch - you can probably see what I'm doing, although it's not at all using the same code. A lot of the time I keep running into "we don't want mere mortals working at this level" type responses. Yeah, I know it's daft. But I still want to do it. ;p In fact, back in the Linux 2.4 days, I *had* a proof of concept. But it ran on Linux and used a lot of "ersatz because copyright" which is no longer needed (e.g., because ksh and CDE weren't available). I want my own flavor of Unix, basically... 🤪 The apparent death of System V is a double-edged sword for my idea. It means it's all the more useless - but in becoming *useless*, it also ceases to be *pointless*, in my estimation. -uso. From crossd at gmail.com Fri Jan 20 12:27:22 2023 From: crossd at gmail.com (Dan Cross) Date: Thu, 19 Jan 2023 21:27:22 -0500 Subject: [TUHS] The era of general purpose computing (Re: AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <202301190802.30J82KwQ025718@freefriends.org> <20230119150434.GA626@mcvoy.com> Message-ID: On Thu, Jan 19, 2023 at 5:30 PM Rich Salz wrote: >> What % of people running Chromebooks, Android or IOS >> do any real programming on it? Even for laptops and >> desktops that % is quite low. Most people run just a >> few apps. > > So what. How many people fix their own cars, TVs, etc. I think that was Bakul's point: almost nobody does. Most folks could be plopped down in front of a Chromebook or something and wouldn't be seriously impeded with what they do. Before my mom died, I was seriously considering setting something like that up for her. In many ways that's also true of _most_ computers these days: that desktop machine that lets you install whatever OS you want probably has a little constellation of microcontrollers embedded in it that come to life and do all sorts of stuff before the real cores ever come out of reset (power sequencing, turning on DIMMs and the IO buses, etc). What on earth are they running? Not to mention the megabytes of firmware that run before the OS ever starts to do all sorts of stuff: BAR assignment, DRAM training, all sorts of ACPI AML flows, running firmware blobs from device ROMs, etc. By the time the kernel begins execution, a lot of stuff we have no insight into whatsoever has already run, and we're mostly powerless over that. A lot of that stays resident and keeps running, even after the host OS takes over. SMM, UEFI bits, all kinds of weird goo. Who's bit-banging I2C to talk to the temperature and current meters on your DIMMs? The whole thing is built to give the OS the illusion that it's in control, but really, it isn't. Mothy Roscoe talked about this at length at OSDI'21: https://www.usenix.org/conference/osdi21/presentation/fri-keynote That said, I don't think that general-purpose computers as we know them will disappear. There will always be a need for, say, specialist workstations for development or engineering or media editing or whatever. On the other hand, when I was at Google I felt that the powers that be were trying pretty hard to get most developers using a cloud-based IDE-ish thing that was internal (and was remarkably good for what it was). So maybe at some point "workstations" really will be glorified 3270s talking to remote cloud services. At least until the next cycle of moving away from centralized computing and pushing compute out to autonomous edge devices kicks in. - Dan C. From cowan at ccil.org Fri Jan 20 13:47:32 2023 From: cowan at ccil.org (John Cowan) Date: Thu, 19 Jan 2023 22:47:32 -0500 Subject: [TUHS] Managers/architects (was: AIX moved into maintainance mode) In-Reply-To: References: <20230119175012.E7E7E18C074@mercury.lcs.mit.edu> Message-ID: On Thu, Jan 19, 2023 at 1:01 PM Marc Donner wrote: > My guess is that Ivan Sutherland probably qualified back when he still > programmed ... I mean, after all, he invented the linked list in order to > implement his thesis program (Sketchpad) in about 1960. > 1963, which makes it younger than Lisp (McCarthy 1960) and IPL (Newell, Shaw, Simon 1957), the original list-processing languages. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lproven at gmail.com Fri Jan 20 23:09:49 2023 From: lproven at gmail.com (Liam Proven) Date: Fri, 20 Jan 2023 14:09:49 +0100 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> <2f00f9a6-c57d-8490-4066-931ec6e191cd@gmail.com> <20230118164242.GG2964@mcvoy.com> Message-ID: On Thu, 19 Jan 2023 at 19:25, Doug McIntyre wrote: > > On Thu, Jan 19, 2023 at 04:02:18PM +0100, Liam Proven wrote: > > ChromeBooks outsold Mac in the USA in 2017, and worldwide by 2020. > > (Sales have fallen off a cliff since the pandemic, but that's because > > so many people have one and are happy with it, I think.) > > I think you need to s/people/schools/ on that statement. OK, so many _owners_ have one. I do not know much about the education market. My only child is just 3 so is not in one yet. I went to 9 different schools in 3 countries on 2 continents so I am not a good example myself. And I currently live in a country where I'm not fluent in the local language (I am trying but it's my 6th and I'm old) so I don't know much about its educational system, even though I have taught in it. But my vague impression is that the high penetration of Chromebooks in education is something of a North American or maybe USA peculiarity, and I don't think this can be generalised worldwide. My _impression_ is that European schools do not routinely provide students with computers, and mostly that students are not allowed to use computers in class, except possibly in computer classes. Wealthier families may of course buy them for their children but this is not a given or a universal or even all that common. Americans have a disproportionately high standard of living and are often unaware of this. For instance, in other retrocomputing groups, I find that many collectors and hobbyisyts from the USA are almost totally unaware of _the_ single most widespread, most successful, most widely-cloned family of 8-bit home computers: the Sinclair Research ZX Spectrum. In Western Europe, Apple/Commodore/Atari were too expensive for most private owners in the early 1980s, and while Apple made the first sub-$1000 home computer, that was still the price of a family car. Sinclair made the first sub-£100 one which ordinary families could buy for their children. In the late 1980s, as the West moved to 16-bit machines, instead Eastern Europe adopted hundreds of clones of the ZX Spectrum, which before the fall of Communism were affordable to build at hobbyist scale. (There were many others, including PDP-11 home computers and things, but the Spectrum dominated by far.) I never saw a single Apple II in private ownership in the 20th century. Not one, not even among wealthy friends or acquaintances. > Education really ramped > in that time frame to get every student a chromebook. I think that is a local observation and is false for the world in general. I don't _know_ this but let me put it this way: in the last decade in the computer industry, living in 3 different cities in 2 countries, and new citizenship of a third, including _making_ several Chromebooks with Cloudready or Flex and giving them away, I have seen *one* (1) in private ownership. ONE person I know personally owns one of the things. They still cost as much as a cheap used motorcycle over here, and times are hard at present. People are more likely to be limping along on old Win XP computers. They are selling well but they are very much not one-per-student or one-per-family in ROTW, no. > I'd really like to see chromebook sales broken apart into consumer and education segments. Also, regionally. I think you would be shocked by the difference between North America, Europe, the rest of the Anglosphere, and Asia. -- Liam Proven ~ Profile: https://about.me/liamproven Email: lproven at cix.co.uk ~ gMail/gTalk/FB: lproven at gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 From lproven at gmail.com Fri Jan 20 23:30:38 2023 From: lproven at gmail.com (Liam Proven) Date: Fri, 20 Jan 2023 14:30:38 +0100 Subject: [TUHS] The death of general purpose computers, was - AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> <0882D9CA-FAC8-4EC6-BA82-CE1D457423E5@iitbombay.org> Message-ID: On Thu, 19 Jan 2023 at 21:10, segaloco via TUHS wrote: > The idea that I can fully pay for and own a device and yet generally have to exploit some sort of security loophole or backdoor developer feature to actually use the device fully is completely asinine to me. I recently reviewed a Murena 1 that might tick some of your boxes: https://www.theregister.com/2022/06/02/murena_e_foundation_phone_test/ De-Googled Android, sends nothing back to anyone, but can run off the shelf Android apps. If even that is too much, then there are other options. I am considering buying a 2nd Planet Computers Gemini in order to run Jolla Sailfish on it. I would also rather like some used Google Pixel or something that I could put Ubuntu Touch on. Work continues even though Canonical cancelled it 5 or 6 years ago, and it's getting there. I've seen in the flesh demos at the Ubuntu Summit here in Prague last November, including one version of UT running a newer version inside a VM, on a JingPad tablet. Or PostmarketOS if you prefer a more DIY experience, perhaps on a FairPhone or a PinePhone. -- Liam Proven ~ Profile: https://about.me/liamproven Email: lproven at cix.co.uk ~ gMail/gTalk/FB: lproven at gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 From skogtun at gmail.com Sat Jan 21 00:37:43 2023 From: skogtun at gmail.com (Harald Arnesen) Date: Fri, 20 Jan 2023 15:37:43 +0100 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> <2f00f9a6-c57d-8490-4066-931ec6e191cd@gmail.com> <20230118164242.GG2964@mcvoy.com> Message-ID: <6056053c-7a7b-243b-8cf0-73d6bc68a6c7@gmail.com> Liam Proven [20/01/2023 14.09]: > My_impression_ is that European schools do not routinely provide > students with computers, and mostly that students are not allowed to > use computers in class, except possibly in computer classes. Wealthier > families may of course buy them for their children but this is not a > given or a universal or even all that common. In Norway, children are given either iPads or Android pads from a very young age. I don't know if they keep them when they quit school (probably, they will be outdated after a few years). -- Hilsen Harald Слава Україні! From tuhs at tuhs.org Sat Jan 21 01:51:29 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 20 Jan 2023 15:51:29 +0000 Subject: [TUHS] The death of general purpose computers, was - AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <20230118161959.GE2964@mcvoy.com> <0882D9CA-FAC8-4EC6-BA82-CE1D457423E5@iitbombay.org> Message-ID: To be completely honest, I'm considering just building myself a mobile using a single board computer with a small external display. I've got one with a connector for cell touch displays right on the board. Couple that with a USB-C power source and I've got my own mobile smart device. Would be a little bulkier than say a traditional smart phone, and wouldn't have a phone number, but I don't care about either of those, I want the pocket computer part, not the banal communication people won't just have in person part. - Matt G. ------- Original Message ------- On Friday, January 20th, 2023 at 5:30 AM, Liam Proven wrote: > On Thu, 19 Jan 2023 at 21:10, segaloco via TUHS tuhs at tuhs.org wrote: > > > The idea that I can fully pay for and own a device and yet generally have to exploit some sort of security loophole or backdoor developer feature to actually use the device fully is completely asinine to me. > > > I recently reviewed a Murena 1 that might tick some of your boxes: > > https://www.theregister.com/2022/06/02/murena_e_foundation_phone_test/ > > De-Googled Android, sends nothing back to anyone, but can run off the > shelf Android apps. > > If even that is too much, then there are other options. I am > considering buying a 2nd Planet Computers Gemini in order to run Jolla > Sailfish on it. > > I would also rather like some used Google Pixel or something that I > could put Ubuntu Touch on. Work continues even though Canonical > cancelled it 5 or 6 years ago, and it's getting there. I've seen in > the flesh demos at the Ubuntu Summit here in Prague last November, > including one version of UT running a newer version inside a VM, on a > JingPad tablet. > > Or PostmarketOS if you prefer a more DIY experience, perhaps on a > FairPhone or a PinePhone. > > -- > Liam Proven ~ Profile: https://about.me/liamproven > Email: lproven at cix.co.uk ~ gMail/gTalk/FB: lproven at gmail.com > Twitter/LinkedIn: lproven ~ Skype: liamproven > UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 From marc.donner at gmail.com Sat Jan 21 01:53:02 2023 From: marc.donner at gmail.com (Marc Donner) Date: Fri, 20 Jan 2023 10:53:02 -0500 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: <52e4bbd7-c5cd-4142-a609-d73ad8025201@app.fastmail.com> References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> <52e4bbd7-c5cd-4142-a609-d73ad8025201@app.fastmail.com> Message-ID: Well, it should probably be a separate thread, since the struggle went on for a long time. We were ultimately able to integrate the AIX 3 systems with our network, but it involved computing the inverse FFT of the ODM on our master machine(s) and then disting that information as a script to the other machines. Then we applied the updates to each machine locally. It thus became much harder to verify that each machine was essentially identical to every other. Of course, part of the problem was that with expensive licensed software it was easy to make an economic justification for the machines being configured idiosyncratically. We conceptualized them as development workstations, so we wanted them to be as identical as possible. A while later, after I got very frustrated with IBM's failure to support my distributed systems work, I left and went to Morgan Stanley where I ended up running (and evolving) the Unix environment used by the Fixed Income department. In order to avoid single-vendor lockin we decided that ten or fifteen percent of our machines would be RS-6000s. We wanted, however, to have an absolutely identical environment so that any user could sit down at any machine and have it just work. Brian Redman ended up being the technical lead on that effort. We coined the motto, "If it doesn't work on the IBMs, it doesn't work." In a few cases we had third party products that only ran on Sun machines. Fortunately the X Window System allowed us to run the binary on a Sun compute server while displaying a window on the user's machine (Sun or IBM). Brian streamlined all of that to the point where there were no visible seams. We had to standardize the user profiles, which was a bigger task than it seemed at first. Best, Marc ===== nygeek.net mindthegapdialogs.com/home On Wed, Jan 18, 2023 at 8:27 PM Joseph Holsten wrote: > On Wed, Jan 18, 2023, at 17:17, Marc Donner wrote: > > I won't bore you with all of the details, but it was a struggle. > > > Clearly, you mistake your audience. I would probably read a multi-volume > series of these struggles. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdm at cfcl.com Sat Jan 21 01:56:41 2023 From: rdm at cfcl.com (Rich Morin) Date: Fri, 20 Jan 2023 07:56:41 -0800 Subject: [TUHS] The death of general purpose computers, was - AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <20230118161959.GE2964@mcvoy.com> <0882D9CA-FAC8-4EC6-BA82-CE1D457423E5@iitbombay.org> Message-ID: <3C52C6D8-8742-4B72-8AE4-130C334EBA88@cfcl.com> One of the problems that cell phones solve is providing (relatively) instant-on capability. The RasPi processor doesn't have hardware support for this; dunno which others might... -r > On Jan 20, 2023, at 07:51, segaloco via TUHS wrote: > > To be completely honest, I'm considering just building myself a mobile using a single board computer with a small external display. ... From tuhs at tuhs.org Sat Jan 21 02:24:50 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 20 Jan 2023 16:24:50 +0000 Subject: [TUHS] The death of general purpose computers, was - AIX moved into maintainance mode In-Reply-To: <3C52C6D8-8742-4B72-8AE4-130C334EBA88@cfcl.com> References: <202301180943.30I9hrOw030485@freefriends.org> <0882D9CA-FAC8-4EC6-BA82-CE1D457423E5@iitbombay.org> <3C52C6D8-8742-4B72-8AE4-130C334EBA88@cfcl.com> Message-ID: If that means I don't have the whole jumble of other problems I'd have with owning a traditional smartphone, I can deal with actually turning it on and off with a full boot cycle. Frankly the "always on" kinda disturbs me, so just one more thing I get better control of. Not to drift the conversation too much though, towards the end of general purpose computing, I like that idea too because the particular single board I have in mind (a RISC-V one I've got) also has a traditional HDMI port and 4 USBs, and ethernet, so if I do it right, I have a mobile that I can also plug in K&M and a monitor to and use at a desk. Society can pry my desk computing from my cold, dead hands, I've never felt as productive using a computing device in any other context. - Matt G. ------- Original Message ------- On Friday, January 20th, 2023 at 7:56 AM, Rich Morin wrote: > One of the problems that cell phones solve is providing (relatively) instant-on capability. The RasPi processor doesn't have hardware support for this; dunno which others might... > > -r > > > On Jan 20, 2023, at 07:51, segaloco via TUHS tuhs at tuhs.org wrote: > > > > To be completely honest, I'm considering just building myself a mobile using a single board computer with a small external display. ... From rdm at cfcl.com Sat Jan 21 02:54:07 2023 From: rdm at cfcl.com (Rich Morin) Date: Fri, 20 Jan 2023 08:54:07 -0800 Subject: [TUHS] =?utf-8?q?FYI=3A_Apple_Lisa_=5Bsource_Pascal_code=5D_goes?= =?utf-8?b?IOKAnG9wZW4gc291cmNl4oCd?= In-Reply-To: References: <20230119175012.E7E7E18C074@mercury.lcs.mit.edu> Message-ID: Pioneering Apple Lisa goes “open source” thanks to Computer History Museum Lisa OS 3.1's 1984 source Pascal code now available under a non-commercial license. https://arstechnica.com/information-technology/2023/01/pioneering-apple-lisa-goes-open-source-thanks-to-computer-history-museum/ CHM MAKES APPLE LISA SOURCE CODE AVAILABLE TO THE PUBLIC AS A PART OF ITS ART OF CODE SERIES https://computerhistory.org/press-releases/chm-makes-apple-lisa-source-code-available-to-the-public-as-a-part-of-its-art-of-code-series/ -r From ron at ronnatalie.com Sat Jan 21 03:07:17 2023 From: ron at ronnatalie.com (Ron Natalie) Date: Fri, 20 Jan 2023 17:07:17 +0000 Subject: [TUHS] =?utf-8?q?FYI=3A_Apple_Lisa_=5Bsource_Pascal_code=5D_goes?= =?utf-8?b?IOKAnG9wZW4gc291cmNl4oCd?= In-Reply-To: References: <20230119175012.E7E7E18C074@mercury.lcs.mit.edu> Message-ID: Nothing about the LISA OS or the subsequent MAC XL (extra large? extra Lisas in inventory?) is remotely UNIXy. ------ Original Message ------ >From "Rich Morin" To "Tautological Eunuch Horticultural Scythians" Date 1/20/2023 11:54:07 AM Subject [TUHS] FYI: Apple Lisa [source Pascal code] goes “open source” >Pioneering Apple Lisa goes “open source” thanks to Computer History Museum >Lisa OS 3.1's 1984 source Pascal code now available under a non-commercial license. >https://arstechnica.com/information-technology/2023/01/pioneering-apple-lisa-goes-open-source-thanks-to-computer-history-museum/ > >CHM MAKES APPLE LISA SOURCE CODE AVAILABLE TO THE PUBLIC AS A PART OF ITS ART OF CODE SERIES >https://computerhistory.org/press-releases/chm-makes-apple-lisa-source-code-available-to-the-public-as-a-part-of-its-art-of-code-series/ > >-r > From g.branden.robinson at gmail.com Sat Jan 21 04:21:14 2023 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Fri, 20 Jan 2023 12:21:14 -0600 Subject: [TUHS] The death of general purpose computers, was - AIX moved into maintainance mode In-Reply-To: <3C52C6D8-8742-4B72-8AE4-130C334EBA88@cfcl.com> Message-ID: <20230120182114.mv3k3zkh3e32xtnj@illithid> At 2023-01-20T07:56:41-0800, Rich Morin wrote: > One of the problems that cell phones solve is providing (relatively) > instant-on capability. The RasPi processor doesn't have hardware > support for this; dunno which others might... At 2023-01-20T16:24:50+0000, segaloco via TUHS wrote: > If that means I don't have the whole jumble of other problems I'd have > with owning a traditional smartphone, I can deal with actually turning > it on and off with a full boot cycle. Frankly the "always on" kinda > disturbs me, so just one more thing I get better control of. Can someone characterize why solving this problem and having (near) instant-on for such a device would be hard? Lack of support for low-power states in the CPU or on the board? I don't see a huge gap between having to key in something to unlock my phone versus a restoring from suspend-to-disk with a LUKS passphrase. If you've suspended to disk you're pretty safe to operate in as low-power a mode as you want. > Not to drift the conversation too much though, towards the end of > general purpose computing, I like that idea too because the particular > single board I have in mind (a RISC-V one I've got) I have heard that firmware blobs are just as ubiquitous and hard to eliminate on RISC-V boards as they are everywhere else. This is a real problem for establishing a trusted computed base. It seems everybody who makes support chips is arc-welded to unverifiable code. We'll have to replace the stuff ourselves, slowly and painfully. I submit that the only way to win that battle in the long run is to copyleft it; otherwise the community's work will simply wind up re-closed, with new features to sell the board, and new backdoors thanks to sloppy bugs and friendly handshakes from friendly guys in suits. I'd love to be wrong about this. Does someone have a curated list of free firmwares for support chips (or SoC modules)? Mondo bonus points for them being written in a verifiable language like Spark/Ada. Sorry if I made you spit your coffee out there. I think I know how far we are from a better world. > also has a traditional HDMI port and 4 USBs, and ethernet, so if I do > it right, I have a mobile that I can also plug in K&M and a monitor to > and use at a desk. Society can pry my desk computing from my cold, > dead hands, I've never felt as productive using a computing device in > any other context. Yup, that is very close to what I want in a so-called "convergence" device. The _ideal_ for me personally would be to put it in a clamshell with an LCD over a Happy Hacking Keyboard. That's the perfect form factor (and key layout) for me. I'd tote that thing everywhere. 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 tuhs at tuhs.org Sat Jan 21 04:33:08 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 20 Jan 2023 18:33:08 +0000 Subject: [TUHS] The death of general purpose computers, was - AIX moved into maintainance mode In-Reply-To: <20230120182114.mv3k3zkh3e32xtnj@illithid> References: <20230120182114.mv3k3zkh3e32xtnj@illithid> Message-ID: <7dTdnEyfaNQ0Y49oagOmNC03a7ADfm3hABDQhGOfAkjcGU3ceKZKZ-LeTX3PvbSE8OeOgf4nKO_iiK03BzjXenDDqlBYcRXLzrVIcxP6F00=@protonmail.com> > I have heard that firmware blobs are just as ubiquitous and hard to > eliminate on RISC-V boards as they are everywhere else. This is a real > problem for establishing a trusted computed base. It seems everybody > who makes support chips is arc-welded to unverifiable code. We'll have > to replace the stuff ourselves, slowly and painfully. I submit that the > only way to win that battle in the long run is to copyleft it; otherwise > the community's work will simply wind up re-closed, with new features to > sell the board, and new backdoors thanks to sloppy bugs and friendly > handshakes from friendly guys in suits. So in this case specifically the board I'm tinkering with is the VisionFive running a dual U74. There is a bootrom that does DRAM training and some other aspects and then spits out into OpenSBI which loads u-boot off a secondary device. I've been tinkering with the lowest levels of startup and it sounds like I can control almost everything, there is a reset vector into the QSPI flash (XiP) that kicks off that boot, contains the thing that loads the DDR init, then OpenSBI, etc. I *think* it is the first instruction the CPU itself hits, not certain, but I think any "stuff" that happens is subsystems doing their own firmware stuff which I can't go any deeper than controlling the flash payload. There is also a button that, when held on startup, redirects to a ROM containing a dirt simple prompt allowing XMODEM-CRC (almost...) transmission of payloads and then an arbitrary branch anywhere in at least the first 32 bits of address space. Anywho, this is just more topic drift so I'll end the chain of my musings here, but if there's any spinoff discussions don't hesitate to just chat it up without the TUHS Cc :P Long story short though is I'm hopeful RISC-V is headed in the correct direction with openness and such, so I'm putting more of my eggs in that basket as time goes on. - Matt G. From tytso at mit.edu Sat Jan 21 04:38:54 2023 From: tytso at mit.edu (Theodore Ts'o) Date: Fri, 20 Jan 2023 13:38:54 -0500 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: <20230119010938.GH28004@mcvoy.com> References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> <20230119010938.GH28004@mcvoy.com> Message-ID: On Wed, Jan 18, 2023 at 05:09:39PM -0800, Larry McVoy wrote: > > I was the person nominally in charge of the OpenSolaris port to z (Neale > > Ferguson did most of the heavy lifting) when Sine Nomine built it, having > > read the tea leaves and believing that IBM would buy Sun. And then IBM > > tightened the screws a little too far and Larry Ellison grabbed it > > instead. Dammit. > > Yeah, I'm not a Solaris fan (because SunOS) but there was some good > technology in there. Would have been cool if IBM kept it going. I > never really understood why Sun was up for sale. >From my understanding, Sun was up for sale because of competitive challenges with the high-end servers (due to delays in their high-end Sparc chips, such as Rock) against products such as IBM's Power (pSeries) machines. These systems had a much better margin, and so if you're making money primarily off of hardware, this segment is super important. The x86 servers don't make as much money, which is why IBM would end up divesting their xSeries business to Lenovo. IBM was primarily interested in Sun for the Java business; it was super important for IBM Software side of the business, since all of its major products (Webshere, Tivoli, etc.) were written in Java. IBM didn't really care about Solaris or the Sparc business; after all, IBM's pSeries with AIX was doing quite well from a sales perspective in the customer segments that were most important for IBM. When I was part of the IBM Linux Technology Center, I participated in an IBM-wide study about whether or not it made sense to invest in file system technologies. What was interesting about it was that it was *purely* from a business perspective; would it drive business to IBM? Would IBM customers find it useful enough to pay $$$ for it? IBM's decision to not try to invest in some of the cool technologies like those that ZFS was pioneering was purely made as a purely cold-hearted business decision. Whether it was cool technology or not didn't enter into the evaluation and decision function. I'm not going to say that this way of making technology decisions is perfect; it definitely has downsides. But I *am* sure it reflected what IBM was willing to pay for Sun Microsystems the company --- and Sun was hoping for more $$$ for its shareholders, which is a completely fair attitude. Was Sun Microsystems worth more to Oracle? I'm not sure, especially since Oracle has mostly treated Solaris as a program loader for Oracle Enterprise Database. But at the end of the day Larrison Ellison was willing to pay more, whether or not it was a principled business decision, or just a desire to take home the Sun Microsystems trophy. And at some level, it really doesn't matter. Realistically, I'm not sure Solaris would have fared that much better under IBM's stewardship. I'm sure IBM would make Solaris available to those customers who wanted to use it, and IBM would have maintained Open Solaris as a open source project. But the decision on how much to invest into new technologies like DTrace and ZFS would have been made the same way that IBM *declined* to try to create a next generation file system for AIX or Linux. And the DTrace and ZFS technologies would have been integrated into Linux (under the GPL license) and AIX, thus adding Solaris technological distinctiveness to those OS's. And while Sun's existing customers might still want Solaris, IBM's customers would very likely stick with the AIX and Linux that they knew. So that would leave Open Solaris competing with Linux as an open source project, without necessarily IBM investing much into Open Solaris except from a hardware enablement perspective, and with the best Solaris features getting cherry-picked into Linux. So it would ultimately depend on how much external investment from other companies might make into Open Solaris versus Linux. And there, a lot of Linux investment came because its use in the embedded and mobile space. (Linux's ext4 encryption and fsverity features was for Android and ChromeOS; it was *not* developed for the data center use cases, although there are now some use cases starting to pick up the data center world.) Would Open Solaris been flexible enough to fit on wrist watches and handheld phones? It's definitely an interesting question, especially, given Linux would have a head start in those worlds. - Ted From crossd at gmail.com Sat Jan 21 04:57:19 2023 From: crossd at gmail.com (Dan Cross) Date: Fri, 20 Jan 2023 13:57:19 -0500 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> <20230119010938.GH28004@mcvoy.com> Message-ID: On Fri, Jan 20, 2023 at 1:39 PM Theodore Ts'o wrote: > [snip] > Would Open Solaris been flexible enough to fit on > wrist watches and handheld phones? It's definitely an interesting > question, especially, given Linux would have a head start in those > worlds. Given that those phones and wrist watches are orders of magnitude more powerful in just about every way than the SPARC machines Solaris had been running on at the time, I'd guess the answer to this would be "yes". Whether that would have been the right call from a commercial perspective is the more interesting question. It could certainly have cleared the technology hurdles, though. - Dan C. Last summer, still recovering from the after-effects of a bout of COVID and jetlagged from our last trip to India, we took our kids swimming. I very carefully put my keys and wallet into my bag, and jumped into the deep end of the pool with my older kid...only to almost immediately remember that my phone was in the pocket of my swim trunks. Oops. My trusty Pixel 5 (which I liked very much!) did not survive. A new Pixel 6 came a few days later. It struck me, looking at its specs, that it was more powerful in every dimension than the IBM ES/3090-600S I used briefly in the early 1990s...and that machine routinely supported 1,000 interactive timesharing users under VM/ESA! It certainly blew the few UltraSPARC machines I still have down in the basement away. I haven't benchmarked it, but I imagine even the IO performance is better. From kevin.bowling at kev009.com Sat Jan 21 05:08:50 2023 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Fri, 20 Jan 2023 12:08:50 -0700 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> <20230119010938.GH28004@mcvoy.com> Message-ID: On Fri, Jan 20, 2023 at 11:39 AM Theodore Ts'o wrote: > > On Wed, Jan 18, 2023 at 05:09:39PM -0800, Larry McVoy wrote: > > > I was the person nominally in charge of the OpenSolaris port to z (Neale > > > Ferguson did most of the heavy lifting) when Sine Nomine built it, having > > > read the tea leaves and believing that IBM would buy Sun. And then IBM > > > tightened the screws a little too far and Larry Ellison grabbed it > > > instead. Dammit. > > > > Yeah, I'm not a Solaris fan (because SunOS) but there was some good > > technology in there. Would have been cool if IBM kept it going. I > > never really understood why Sun was up for sale. > > From my understanding, Sun was up for sale because of competitive > challenges with the high-end servers (due to delays in their high-end > Sparc chips, such as Rock) against products such as IBM's Power > (pSeries) machines. These systems had a much better margin, and so if > you're making money primarily off of hardware, this segment is super > important. The x86 servers don't make as much money, which is why IBM > would end up divesting their xSeries business to Lenovo. > > IBM was primarily interested in Sun for the Java business; it was > super important for IBM Software side of the business, since all of > its major products (Webshere, Tivoli, etc.) were written in Java. IBM > didn't really care about Solaris or the Sparc business; after all, > IBM's pSeries with AIX was doing quite well from a sales perspective > in the customer segments that were most important for IBM. > > When I was part of the IBM Linux Technology Center, I participated in > an IBM-wide study about whether or not it made sense to invest in file > system technologies. What was interesting about it was that it was > *purely* from a business perspective; would it drive business to IBM? > Would IBM customers find it useful enough to pay $$$ for it? IBM's > decision to not try to invest in some of the cool technologies like > those that ZFS was pioneering was purely made as a purely cold-hearted > business decision. Whether it was cool technology or not didn't enter > into the evaluation and decision function. GPFS (now called Spectrum Scale?) is one of the most featured filesystems I can think of, I bet it met both definitions? > I'm not going to say that this way of making technology decisions is > perfect; it definitely has downsides. But I *am* sure it reflected > what IBM was willing to pay for Sun Microsystems the company --- and > Sun was hoping for more $$$ for its shareholders, which is a > completely fair attitude. Was Sun Microsystems worth more to Oracle? > I'm not sure, especially since Oracle has mostly treated Solaris as a > program loader for Oracle Enterprise Database. But at the end of the > day Larrison Ellison was willing to pay more, whether or not it was a > principled business decision, or just a desire to take home the Sun > Microsystems trophy. And at some level, it really doesn't matter. > > Realistically, I'm not sure Solaris would have fared that much better > under IBM's stewardship. I'm sure IBM would make Solaris available to > those customers who wanted to use it, and IBM would have maintained > Open Solaris as a open source project. But the decision on how much > to invest into new technologies like DTrace and ZFS would have been > made the same way that IBM *declined* to try to create a next > generation file system for AIX or Linux. And the DTrace and ZFS > technologies would have been integrated into Linux (under the GPL > license) and AIX, thus adding Solaris technological distinctiveness to > those OS's. And while Sun's existing customers might still want > Solaris, IBM's customers would very likely stick with the AIX and > Linux that they knew. One bit of anecdote, AIX does have a dynamic tracing system comprable to DTrace called ProbeVue. So I think the relative cost of new engineering on whatever Sun had to offer was never too high. And that is congruent with my understanding of the technology business, most times acquisitions are to gain customers (aka revenue) and seldom employees (aka aquihire). Business technology transfers are usually a sign of something gone wrong, with occasional flukes of success. > So that would leave Open Solaris competing with Linux as an open > source project, without necessarily IBM investing much into Open > Solaris except from a hardware enablement perspective, and with the > best Solaris features getting cherry-picked into Linux. So it would > ultimately depend on how much external investment from other companies > might make into Open Solaris versus Linux. And there, a lot of Linux > investment came because its use in the embedded and mobile space. > (Linux's ext4 encryption and fsverity features was for Android and > ChromeOS; it was *not* developed for the data center use cases, > although there are now some use cases starting to pick up the data > center world.) Would Open Solaris been flexible enough to fit on > wrist watches and handheld phones? It's definitely an interesting > question, especially, given Linux would have a head start in those > worlds. > > - Ted From cowan at ccil.org Sat Jan 21 05:48:36 2023 From: cowan at ccil.org (John Cowan) Date: Fri, 20 Jan 2023 14:48:36 -0500 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> <20230119010938.GH28004@mcvoy.com> Message-ID: On Fri, Jan 20, 2023 at 1:59 PM Dan Cross wrote: A new Pixel 6 came a few days later. It struck me, looking at > its specs, that it was more powerful in every dimension than the IBM > ES/3090-600S I used briefly in the early 1990s...and that machine > routinely supported 1,000 interactive timesharing users under VM/ESA! > Not every dimension. Specifically, the ES/3090 had static RAM and a far more performant bus than any Sun machine. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sat Jan 21 06:04:30 2023 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Sat, 21 Jan 2023 06:04:30 +1000 Subject: [TUHS] The death of general purpose computers -> COFF Message-ID: Hi all, can we move "The death of general purpose computers" to COFF now as it's not directly relevant to Unix. Thanks, Warren From crossd at gmail.com Sat Jan 21 06:04:00 2023 From: crossd at gmail.com (Dan Cross) Date: Fri, 20 Jan 2023 15:04:00 -0500 Subject: [TUHS] AIX moved into maintainance mode In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <20230118161959.GE2964@mcvoy.com> <20230119010938.GH28004@mcvoy.com> Message-ID: On Fri, Jan 20, 2023 at 2:48 PM John Cowan wrote: > On Fri, Jan 20, 2023 at 1:59 PM Dan Cross wrote: >> A new Pixel 6 came a few days later. It struck me, looking at >> its specs, that it was more powerful in every dimension than the IBM >> ES/3090-600S I used briefly in the early 1990s...and that machine >> routinely supported 1,000 interactive timesharing users under VM/ESA! > > Not every dimension. Specifically, the ES/3090 had static RAM and a far more performant bus than any Sun machine. Yes, but I was referring to my cell phone, not a Sun machine. :-) - Dan C. From rminnich at gmail.com Sat Jan 21 08:44:51 2023 From: rminnich at gmail.com (ron minnich) Date: Fri, 20 Jan 2023 14:44:51 -0800 Subject: [TUHS] FD 2 Message-ID: I am trying to remember when fd 2 (aka stderr) became a thing. I have a vague memory that it was post-v6 but that may be way off. -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.branden.robinson at gmail.com Sat Jan 21 08:54:03 2023 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Fri, 20 Jan 2023 16:54:03 -0600 Subject: [TUHS] FD 2 In-Reply-To: References: Message-ID: <20230120225403.tihz3fivr2gdq4qn@illithid> At 2023-01-20T14:44:51-0800, ron minnich wrote: > I am trying to remember when fd 2 (aka stderr) became a thing. I have > a vague memory that it was post-v6 but that may be way off. The story goes that it swiftly followed the creation of troff. https://minnie.tuhs.org/pipermail/tuhs/2013-December/006113.html 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 robpike at gmail.com Sat Jan 21 08:56:16 2023 From: robpike at gmail.com (Rob Pike) Date: Sat, 21 Jan 2023 09:56:16 +1100 Subject: [TUHS] FD 2 In-Reply-To: References: Message-ID: I will let others respond with specifics, but that was there in v5 at least. One of the many shocks I had on arrival at Google was that in production, fd2 was pretty much standard output, as all the logging went there. And since our machines were still 32-bit CPUs then, it was common to overflow the offset because the logging output was, well, not parsimonious. It felt like I'd entered bizarro world, until I realized that few anywhere really knew how Unix was supposed to be used. And they still don't, and never will. -rob On Sat, Jan 21, 2023 at 9:46 AM ron minnich wrote: > I am trying to remember when fd 2 (aka stderr) became a thing. I have a > vague memory that it was post-v6 but that may be way off. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sat Jan 21 09:11:07 2023 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 20 Jan 2023 15:11:07 -0800 Subject: [TUHS] FD 2 In-Reply-To: References: Message-ID: <20230120231107.GB12196@mcvoy.com> On Sat, Jan 21, 2023 at 09:56:16AM +1100, Rob Pike wrote: > I will let others respond with specifics, but that was there in v5 at least. > > One of the many shocks I had on arrival at Google was that in production, > fd2 was pretty much standard output, as all the logging went there. And > since our machines were still 32-bit CPUs then, it was common to overflow > the offset because the logging output was, well, not parsimonious. It felt > like I'd entered bizarro world, until I realized that few anywhere really > knew how Unix was supposed to be used. And they still don't, and never will. Isn't there a logging API complete with the ability to centralize the logs? From douglas.mcilroy at dartmouth.edu Sat Jan 21 09:13:32 2023 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Fri, 20 Jan 2023 18:13:32 -0500 Subject: [TUHS] FD 2 In-Reply-To: References: Message-ID: Yes. It is confirmed by a change in the init man page between v6 and v7. This can be seen in the TUHS archive. On Fri, Jan 20, 2023 at 5:46 PM ron minnich wrote: > > I am trying to remember when fd 2 (aka stderr) became a thing. I have a vague memory that it was post-v6 but that may be way off. > > From robpike at gmail.com Sat Jan 21 09:14:25 2023 From: robpike at gmail.com (Rob Pike) Date: Sat, 21 Jan 2023 10:14:25 +1100 Subject: [TUHS] FD 2 In-Reply-To: <20230120231107.GB12196@mcvoy.com> References: <20230120231107.GB12196@mcvoy.com> Message-ID: Yes, but everyone adds the flag --alsologtostderr -rob On Sat, Jan 21, 2023 at 10:11 AM Larry McVoy wrote: > On Sat, Jan 21, 2023 at 09:56:16AM +1100, Rob Pike wrote: > > I will let others respond with specifics, but that was there in v5 at > least. > > > > One of the many shocks I had on arrival at Google was that in production, > > fd2 was pretty much standard output, as all the logging went there. And > > since our machines were still 32-bit CPUs then, it was common to overflow > > the offset because the logging output was, well, not parsimonious. It > felt > > like I'd entered bizarro world, until I realized that few anywhere really > > knew how Unix was supposed to be used. And they still don't, and never > will. > > Isn't there a logging API complete with the ability to centralize the logs? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sat Jan 21 09:22:46 2023 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 20 Jan 2023 15:22:46 -0800 Subject: [TUHS] FD 2 In-Reply-To: References: <20230120231107.GB12196@mcvoy.com> Message-ID: <20230120232246.GC12196@mcvoy.com> That's dumb. Though I run slack like so slack > /dev/null 2>&1 & because whatever version I have spews garbage to stderr. Sigh. On Sat, Jan 21, 2023 at 10:14:25AM +1100, Rob Pike wrote: > Yes, but everyone adds the flag --alsologtostderr > > -rob > > > On Sat, Jan 21, 2023 at 10:11 AM Larry McVoy wrote: > > > On Sat, Jan 21, 2023 at 09:56:16AM +1100, Rob Pike wrote: > > > I will let others respond with specifics, but that was there in v5 at > > least. > > > > > > One of the many shocks I had on arrival at Google was that in production, > > > fd2 was pretty much standard output, as all the logging went there. And > > > since our machines were still 32-bit CPUs then, it was common to overflow > > > the offset because the logging output was, well, not parsimonious. It > > felt > > > like I'd entered bizarro world, until I realized that few anywhere really > > > knew how Unix was supposed to be used. And they still don't, and never > > will. > > > > Isn't there a logging API complete with the ability to centralize the logs? > > -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From jon at fourwinds.com Sat Jan 21 13:37:56 2023 From: jon at fourwinds.com (Jon Steinhart) Date: Fri, 20 Jan 2023 19:37:56 -0800 Subject: [TUHS] FD 2 In-Reply-To: References: Message-ID: <202301210337.30L3bvFi2041608@darkstar.fourwinds.com> ron minnich writes: > I am trying to remember when fd 2 (aka stderr) became a thing. I have a > vague memory that it was post-v6 but that may be way off. Related to this, according to Steve Johnson, stderr was not part of the original stdio library; it was added as a side effect of the development of troff for the C/A/T photoypesetter which projected images onto silver photographic paper. That became very expensive when the Hunt brothers cornered the silver market, and folks were asked to cut down on phototypesetter use. It was not uncommon to send a job to the typesetter only to get back a beautifully formatted page containing a cannot open file error message. The stderr file pointer was born so that error messages could go to the terminal instead of to the typesetter in order to save money. From clemc at ccc.com Sun Jan 22 01:42:59 2023 From: clemc at ccc.com (Clem Cole) Date: Sat, 21 Jan 2023 10:42:59 -0500 Subject: [TUHS] FD 2 In-Reply-To: References: Message-ID: Certainly fd 2 as a error output appears with Lesk's portable C library, which was included in V6 - see the last para on page 1 of his document: "Initially you are given three file descriptors by the system: 0, 1, and 2. File 0 is the standard input; it is normally the teletype in time-sharing or input data cards in batch. File 1 is the standard output; it is nor- mally the teletype in time-sharing or the line printer in batch. File 2 is the error file; it is an output file, nor- mally the same as file 1, except that when file 1 is diverted via a command line ’>’ operator, file 2 remains attached to the original destination, usually the terminal. It is used for error message output. These popular UNIX conventions are considered part of the C library specification. By closing 0 or 1, the default input or output may be re-directed; this can also be done on the command line by >file for output or wrote: > I am trying to remember when fd 2 (aka stderr) became a thing. I have a > vague memory that it was post-v6 but that may be way off. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: iolib.pdf Type: application/pdf Size: 46203 bytes Desc: not available URL: From imp at bsdimp.com Sun Jan 22 03:34:37 2023 From: imp at bsdimp.com (Warner Losh) Date: Sat, 21 Jan 2023 10:34:37 -0700 Subject: [TUHS] FD 2 In-Reply-To: References: Message-ID: On Sat, Jan 21, 2023, 8:45 AM Clem Cole wrote: > Certainly fd 2 as a error output appears with Lesk's portable C library, > which was included in V6 - see the last para on page 1 of his document: > > "Initially you are given three file descriptors by the system: 0, 1, and > 2. File 0 is the standard input; it is normally the teletype in > time-sharing or input data cards in batch. File 1 is the standard output; > it is nor- mally the teletype in time-sharing or the line printer in batch. > File 2 is the error file; it is an output file, nor- mally the same as file > 1, except that when file 1 is diverted via a command line ’>’ operator, > file 2 remains attached to the original destination, usually the terminal. > It is used for error message output. These popular UNIX conventions are > considered part of the C library specification. By closing 0 or 1, the > default input or output may be re-directed; this can also be done on the > command line by >file for output or > This document pre-dates ditroff. The idea/names of stdin/out/err (as > opposed to fd 0, 1, 2) does not come about until Dennis does "typesetter C" > which is described in K&R. > > That said, my memory is fd 2 as ana error path was there in Fourth or > Fifth Edition, before Lesk did this library -- i.e. it was a convention > that Dennis/Ken et al were all using -- when it is realized that printing > errors on in the same output flow as the standard (normal) output was > problematic in a pipe stream. > ᐧ > It looks to be a mixed bag in 5th edition. Cc, ac, comm and find all printf the errors. Diff uses writes to fd 2. I didn't catalog further, but this kinda looks like a developing convention, not yet fully realized. . Warner On Fri, Jan 20, 2023 at 5:46 PM ron minnich wrote: > >> I am trying to remember when fd 2 (aka stderr) became a thing. I have a >> vague memory that it was post-v6 but that may be way off. >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sun Jan 22 03:50:17 2023 From: imp at bsdimp.com (Warner Losh) Date: Sat, 21 Jan 2023 10:50:17 -0700 Subject: [TUHS] FD 2 In-Reply-To: References: Message-ID: On Sat, Jan 21, 2023, 10:34 AM Warner Losh wrote: > > > On Sat, Jan 21, 2023, 8:45 AM Clem Cole wrote: > >> Certainly fd 2 as a error output appears with Lesk's portable C library, >> which was included in V6 - see the last para on page 1 of his document: >> >> "Initially you are given three file descriptors by the system: 0, 1, and >> 2. File 0 is the standard input; it is normally the teletype in >> time-sharing or input data cards in batch. File 1 is the standard output; >> it is nor- mally the teletype in time-sharing or the line printer in batch. >> File 2 is the error file; it is an output file, nor- mally the same as file >> 1, except that when file 1 is diverted via a command line ’>’ operator, >> file 2 remains attached to the original destination, usually the terminal. >> It is used for error message output. These popular UNIX conventions are >> considered part of the C library specification. By closing 0 or 1, the >> default input or output may be re-directed; this can also be done on the >> command line by >file for output or > >> This document pre-dates ditroff. The idea/names of stdin/out/err (as >> opposed to fd 0, 1, 2) does not come about until Dennis does "typesetter C" >> which is described in K&R. >> >> That said, my memory is fd 2 as ana error path was there in Fourth or >> Fifth Edition, before Lesk did this library -- i.e. it was a convention >> that Dennis/Ken et al were all using -- when it is realized that printing >> errors on in the same output flow as the standard (normal) output was >> problematic in a pipe stream. >> ᐧ >> > > It looks to be a mixed bag in 5th edition. Cc, ac, comm and find all > printf the errors. Diff uses writes to fd 2. I didn't catalog further, but > this kinda looks like a developing convention, not yet fully realized. . > Further digging shows v6 is quite similar. V7 revamps everything, with printf changed to a routine that writes to stderr. Each program did this differently. Granted, this is a small sample size. There wasn't a huge uptake of stderr/fd2 in v6 it seems, but v7 looks like it had a pass over the code to at least try for all errors going to fd2. Warner > Warner > > On Fri, Jan 20, 2023 at 5:46 PM ron minnich wrote: >> >>> I am trying to remember when fd 2 (aka stderr) became a thing. I have a >>> vague memory that it was post-v6 but that may be way off. >>> >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Sun Jan 22 04:12:55 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sat, 21 Jan 2023 11:12:55 -0700 Subject: [TUHS] The era of general purpose computing (Re: AIX moved into maintainance mode In-Reply-To: <75cfc721-a662-ddea-1188-767462d747ae@makerlisp.com> References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <202301190802.30J82KwQ025718@freefriends.org> <20230119150434.GA626@mcvoy.com> <7cc2b7c5-5e98-9299-4fa8-a477fbf4ff77@makerlisp.com> <75cfc721-a662-ddea-1188-767462d747ae@makerlisp.com> Message-ID: <202301211812.30LICtSl021234@freefriends.org> Real computers with keyboards etc won't go away; think about all those servers running the backends of the apps and the databases for the cool stuff on the phones. Someone is still going to have to write those bits. Arnold Luther Johnson wrote: > Well, that's a comforting thought, I hope it goes that way. > > On 01/19/2023 06:10 PM, John Cowan wrote: > > > > > > On Thu, Jan 19, 2023 at 5:23 PM Luther Johnson > > wrote: > > > > Computers that are not smart phone-like are definitely on the > > endangered > > species list. You know, the kind on a desk, with a keyboard ... > > > > > > I don't have statistics for this, but I doubt it. Consider amateur > > radio, which has been around for a century now. Amateur stations are > > an ever-shrinking *fraction* of all transmitters, to say nothing of > > receivers, but in absolute terms there are now more than 2 million > > hams in the world, which is almost certainly more than ever. > From clemc at ccc.com Sun Jan 22 04:26:26 2023 From: clemc at ccc.com (Clem Cole) Date: Sat, 21 Jan 2023 13:26:26 -0500 Subject: [TUHS] FD 2 In-Reply-To: References: Message-ID: On Sat, Jan 21, 2023 at 12:50 PM Warner Losh wrote: > > Further digging shows v6 is quite similar. > As I said, by then they know it's an issue and the fd 2 has been introduced. The place to look is not the utilities, but the shell itself and what the kernel is doing in newproc et al for the tty handler. > V7 revamps everything, with printf changed to a routine that writes to > stderr. Each program did this differently. > IMO: Sort of two different things >>I think<<. They are related - the idea ( what the OS supplied to each process), as opposed to what/how each utility handled it. With typesetter C -- we get dmr's new stdio library (libS.a) replacing Lesk's portable C library. This was released independent of V6 as what DEC would have called a 'layered product" that ran on top of V6. As I said, this is the language that Dennis and Brian describe in K&R (version 1). With what was becoming UNIX/TS -- which don't seem to have a formal release -- we get what we all think of as the V7 kernel, Bourne's new shell and the new and updated tools suite as part of the system. So with V7, as you point out, most, but not all of the utilities have been updated to start using the new compiler (since by then Lesk library is not included), If the code were recompiled, that code would have had to used the new FILE * structure over the small integer fd, for the printf family. With V6 there were still a handful of utilities in assembler (like snoball IIRC), but by V7 I think most of them had been culled. And while your point is that you need to look at what each utility implemented, >>I believe<< that the key to Ron's question is what the shell and the kernel supplied [dates the idea], and >>then<< if the utility obeyed the new fd 2 as the error file is when it starts to be more formally enforced. So any further hunting should start there I would think. Clem > > Granted, this is a small sample size. There wasn't a huge uptake of > stderr/fd2 in v6 it seems, but v7 looks like it had a pass over the code to > at least try for all errors going to fd2. > > Warner > > >> Warner >> >> On Fri, Jan 20, 2023 at 5:46 PM ron minnich wrote: >>> >>>> I am trying to remember when fd 2 (aka stderr) became a thing. I have a >>>> vague memory that it was post-v6 but that may be way off. >>>> >>>> >>>> ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sun Jan 22 04:27:13 2023 From: clemc at ccc.com (Clem Cole) Date: Sat, 21 Jan 2023 13:27:13 -0500 Subject: [TUHS] FD 2 In-Reply-To: References: Message-ID: On Sat, Jan 21, 2023 at 12:34 PM Warner Losh wrote: > It looks to be a mixed bag in 5th edition. Cc, ac, comm and find all > printf the errors. Diff uses writes to fd 2. I didn't catalog further, but > this kinda looks like a developing convention, not yet fully realized. . > Fair enough and that makes sense... ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sun Jan 22 04:37:42 2023 From: imp at bsdimp.com (Warner Losh) Date: Sat, 21 Jan 2023 11:37:42 -0700 Subject: [TUHS] FD 2 In-Reply-To: References: Message-ID: On Sat, Jan 21, 2023, 11:26 AM Clem Cole wrote: > > > On Sat, Jan 21, 2023 at 12:50 PM Warner Losh wrote: > > >> >> Further digging shows v6 is quite similar. >> > As I said, by then they know it's an issue and the fd 2 has been > introduced. The place to look is not the utilities, but the shell itself > and what the kernel is doing in newproc et al for the tty handler. > The utilities were all using printf so even if the concept was there, it wasn't widely used. I'll take a longer look, including these places.. though I'm not sure I see the connection to the tty driver... V7 revamps everything, with printf changed to a routine that writes to >> stderr. Each program did this differently. >> > IMO: Sort of two different things >>I think<<. They are related - the idea > ( what the OS supplied to each process), as opposed to what/how each > utility handled it. > Yea. Mostly i think each program had a different wrapper around stderr to minimize changes to the program... With typesetter C -- we get dmr's new stdio library (libS.a) replacing > Lesk's portable C library. This was released independent of V6 as what DEC > would have called a 'layered product" that ran on top of V6. As I said, > this is the language that Dennis and Brian describe in K&R (version 1). > Do we have extant copies of that? So far I have see the kernel patches that were "leaked" but not the rest of it. With what was becoming UNIX/TS -- which don't seem to have a formal release > -- we get what we all think of as the V7 kernel, Bourne's new shell and the > new and updated tools suite as part of the system > Yea. So with V7, as you point out, most, but not all of the utilities have been > updated to start using the new compiler (since by then Lesk library is not > included), If the code were recompiled, that code would have had to used > the new FILE * structure over the small integer fd, for the printf family. > With V6 there were still a handful of utilities in assembler (like snoball > IIRC), but by V7 I think most of them had been culled. > > And while your point is that you need to look at what each utility > implemented, >>I believe<< that the key to Ron's question is what the shell > and the kernel supplied [dates the idea], and >>then<< if the utility > obeyed the new fd 2 as the error file is when it starts to be more formally > enforced. So any further hunting should start there I would think. > Yea. Like many things, there was a transition... the most important bit is the shell. And that was more tricky to read through with the phone at breakfast... Warner Clem > > > >> >> Granted, this is a small sample size. There wasn't a huge uptake of >> stderr/fd2 in v6 it seems, but v7 looks like it had a pass over the code to >> at least try for all errors going to fd2. >> >> Warner >> >> >>> Warner >>> >>> On Fri, Jan 20, 2023 at 5:46 PM ron minnich wrote: >>>> >>>>> I am trying to remember when fd 2 (aka stderr) became a thing. I have >>>>> a vague memory that it was post-v6 but that may be way off. >>>>> >>>>> >>>>> ᐧ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From luther at makerlisp.com Sun Jan 22 04:43:25 2023 From: luther at makerlisp.com (Luther Johnson) Date: Sat, 21 Jan 2023 11:43:25 -0700 Subject: [TUHS] The era of general purpose computing (Re: AIX moved into maintainance mode In-Reply-To: <202301211812.30LICtSl021234@freefriends.org> References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <202301190802.30J82KwQ025718@freefriends.org> <20230119150434.GA626@mcvoy.com> <7cc2b7c5-5e98-9299-4fa8-a477fbf4ff77@makerlisp.com> <75cfc721-a662-ddea-1188-767462d747ae@makerlisp.com> <202301211812.30LICtSl021234@freefriends.org> Message-ID: <396750c7-6fc8-9b15-5e68-9f569718ba2e@makerlisp.com> Yes, I know, but some of that SW development is being automated ... I'm not saying it will totally go away, but the numbers will become smaller, and the number of people who know how to do it will become smaller, and the quality will continue to deteriorate. The number of people who can detect quality problems before the failures they cause, will also get smaller. Not extinct, but endangered, and we are all endangered by the quality problems. On 01/21/2023 11:12 AM, arnold at skeeve.com wrote: > Real computers with keyboards etc won't go away; think about > all those servers running the backends of the apps and the > databases for the cool stuff on the phones. Someone is still > going to have to write those bits. > > Arnold > > Luther Johnson wrote: > >> Well, that's a comforting thought, I hope it goes that way. >> >> On 01/19/2023 06:10 PM, John Cowan wrote: >>> >>> On Thu, Jan 19, 2023 at 5:23 PM Luther Johnson >> > wrote: >>> >>> Computers that are not smart phone-like are definitely on the >>> endangered >>> species list. You know, the kind on a desk, with a keyboard ... >>> >>> >>> I don't have statistics for this, but I doubt it. Consider amateur >>> radio, which has been around for a century now. Amateur stations are >>> an ever-shrinking *fraction* of all transmitters, to say nothing of >>> receivers, but in absolute terms there are now more than 2 million >>> hams in the world, which is almost certainly more than ever. From robpike at gmail.com Sun Jan 22 17:38:03 2023 From: robpike at gmail.com (Rob Pike) Date: Sun, 22 Jan 2023 18:38:03 +1100 Subject: [TUHS] v8 shell Message-ID: Found this tweetstream, here folded together, when looking for something else (now lost) in my twitter archive: ========== Things I miss from the v8 shell. 1) All shell output was valid shell input. 2) Typing dir/cmd would find the command $PATH/dir/cmd. Subdirectories of your bin, in other words. 3) Functions were exportable. For one brief shining POSIX meeting, that was true in POSIX too but then... 4) The implementation was lovely and easy to understand. (No, it wasn't shalgol. Bourne fixed that for us.) 5) That I could learn things from it, like how to write a recursive descent parser.* 6) It ran in cooked mode. As expected, all that work making it a great shell is lost to history. https://t.co/IzApAUSmzN is silent. Well, the code is released now. ========== -rob * elegantly. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sun Jan 22 20:56:33 2023 From: tuhs at tuhs.org (Jaap Akkerhuis via TUHS) Date: Sun, 22 Jan 2023 11:56:33 +0100 Subject: [TUHS] FD 2 In-Reply-To: References: Message-ID: > On 21 Jan 2023, at 19:27, Clem Cole wrote: > > > > On Sat, Jan 21, 2023 at 12:34 PM Warner Losh > wrote: >> It looks to be a mixed bag in 5th edition. Cc, ac, comm and find all printf the errors. Diff uses writes to fd 2. I didn't catalog further, but this kinda looks like a developing convention, not yet fully realized. . > Fair enough and that makes sense... > ᐧ I do remember that pr -p actually read from FD 2. It probably still does. Very useful to align paper in the printer. jaap -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: Message signed with OpenPGP URL: From jsg at jsg.id.au Sun Jan 22 21:05:16 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Sun, 22 Jan 2023 22:05:16 +1100 Subject: [TUHS] FD 2 In-Reply-To: References: Message-ID: On Sat, Jan 21, 2023 at 11:37:42AM -0700, Warner Losh wrote: > On Sat, Jan 21, 2023, 11:26 AM Clem Cole wrote: > > With typesetter C -- we get dmr's new stdio library (libS.a) replacing > > Lesk's portable C library. This was released independent of V6 as what DEC > > would have called a 'layered product" that ran on top of V6. As I said, > > this is the language that Dennis and Brian describe in K&R (version 1). > > > > Do we have extant copies of that? So far I have see the kernel patches that > were "leaked" but not the rest of it. Of the "Phototypesetter Version 7" tape? The compiler and stdio show up in other places before v7. libp/iolib described in M. E. Lesk - The Portable C Library https://archive.org/details/ThePortableCLibrary_May75 (abbreviated in https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/doc/iolib/iolib ) libS/stdio appears in a modified form in PWB/UNIX 1.0 As does "A New Input-Output Package" https://minnie.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/source/s4/stdio/ios.r included in "Documents for the PWB/UNIX Time-Sharing System Edition 1.0" https://bitsavers.org/pdf/att/unix/PWB_UNIX/Documents_for_the_PWB_UNIX_Time-Sharing_System_Edition_1.0_197710.pdf an older? version appears in tuhs/Applications/Spencer_Tapes/unsw3.tar.gz usr/source/stdio also part of https://minnie.tuhs.org/cgi-bin/utree.pl?file=Interdata732/usr/source/stdio https://minnie.tuhs.org/cgi-bin/utree.pl?file=Interdata732/usr/doc/cdoc/ios.nr tuhs/Distributions/Research/Tim_Shoppa_v6 (libS, stdio.h, no libS source) and MERT Release 0, NEWIO(III) newio - a new IO subroutine package https://www.tuhs.org/Archive/Documentation/Manuals/MERT_Release_0/Unix%20Programmer%20Manual%20-%20UPM%20-%20White%20Tabs/Subroutines%20-%20man3/newio.3.pdf "part of the effort in moving programs to the Interdata machine was devoted to making programs use the new standard I/O library" S. C. Johnson, D. M. Ritchie - Portability of C Programs and the UNIX System https://www.bell-labs.com/usr/dmr/www/portpap.html "In the first sense, the portability of C programs have been recently enhanced by new tools developed by center 127: ... * The Standard I/O package implements efficient portable I/O. This package should be used for nearly all new C development. The bulk of existing programs should be converted, as well." B. A. Tague - C Language Portability https://archive.org/details/CLanguagePortability_Sept77 "2.2 The Standard I/O Library In the past, there were two I/O libraries available. One was documented by A New Input-Output Package (Ritchie), and was made available through the -lS loader option. The other, older one was made available whenever a C program was being compiled; it was characterized, among other things, by use of the names fin and fout to control disposition of standard input and output files. The older library has now vanished, along with the -lS option. All programs will receive the new I/O library without any explicit action. In addition, the libraries obtained by -lc and -la have been merged; this combined library is accessed (where needed) by -lc or -l." Andrew R. Koenig - The C Environment of UNIX/TS https://bitsavers.org/pdf/plexus/Sys3/98-05036.5_Plexus_Sys3_UNIX_Programmers_Manual_Vol_2A_RevA_198409.pdf "New archiver ... uses long (double-word) integers, which can only be compiled by the new C compiler which we can't distribute yet." UNIX News, May-June 1976, 6-3 https://www.tuhs.org/Archive/Documentation/Usenix/Early_Newsletters/197605-unix-news-n6.pdf "a new tape is in the process of preparation, and should be available as soon as it clears the lawyers, for the usual free license and handling fee. It contains the new nroff, the new C, the new I/O library (faster & smaller than anything to date), and a bunch of other such things. It will be available from Bell, not the Center. Ken is going to send a formal notice to the News." UNIX News, November 1976, pg 1 https://www.tuhs.org/Archive/Documentation/Usenix/Early_Newsletters/197611-unix-news-n11.pdf 'Among the items listed are mini-UNIX (previously announced) and "PHOTOTYPESETTER VERSION 7" which is new.' https://www.tuhs.org/Archive/Documentation/Usenix/Early_Newsletters/197703-unix-news-v2n3.pdf "The principal speaker at the Phototypesetting session was Joe Ossana. He announced a new phototypesetting package, typesetter V7, which is or soon will be available from Western Electric for a $3300 license fee. The new package combines NROFF and TROFF and is written in C." https://archive.org/details/login_august-1977/page/n21/mode/2up https://www.usenix.org/system/files/login/articles/login_dec15_11_history_login.pdf https://www.bell-labs.com/usr/dmr/www/licenses/pricelist84.pdf has different items for "Phototypesetter Programmer's Workbench" "Phototypesetter V7" "Independent TROFF" these are also mentioned in https://archive.org/details/login_april83_issue/page/n13/mode/2up "On November 1, 1977 Toronto received a license for Phototypesetter V7" Salus QCU pg 123 From arnold at skeeve.com Mon Jan 23 00:52:53 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 22 Jan 2023 07:52:53 -0700 Subject: [TUHS] v8 shell In-Reply-To: References: Message-ID: <202301221452.30MEqrRq025402@freefriends.org> Geoff Collyer has made the 9th edition shell available: http://www.collyer.net/who/geoff/v9sh.tar Arnold Rob Pike wrote: > Found this tweetstream, here folded together, when looking for something > else (now lost) in my twitter archive: > > ========== > > Things I miss from the v8 shell. > > 1) All shell output was valid shell input. > > 2) Typing dir/cmd would find the command $PATH/dir/cmd. Subdirectories of > your bin, in other words. > > 3) Functions were exportable. For one brief shining POSIX meeting, that was > true in POSIX too but then... > > 4) The implementation was lovely and easy to understand. (No, it wasn't > shalgol. Bourne fixed that for us.) > > 5) That I could learn things from it, like how to write a recursive descent > parser.* > > 6) It ran in cooked mode. > > As expected, all that work making it a great shell is lost to history. > https://t.co/IzApAUSmzN is silent. Well, the code is released now. > > > ========== > > -rob > > * elegantly. From imp at bsdimp.com Mon Jan 23 07:23:11 2023 From: imp at bsdimp.com (Warner Losh) Date: Sun, 22 Jan 2023 14:23:11 -0700 Subject: [TUHS] FD 2 In-Reply-To: References: Message-ID: On Sat, Jan 21, 2023 at 11:37 AM Warner Losh wrote: > > Yea. Like many things, there was a transition... the most important bit is > the shell. And that was more tricky to read through with the phone at > breakfast... > OK. I've dug a bit further and Clem and I have chatted... Here's the summary. We don't have V4's shell, alas, since all we have from that time period is the C kernel a few months before the 4th edition release. V5 /bin/sh closes fd2 and then dups fd1 to fd2. This creates fd2 as something special. V6 closes all FD's larger than 1 (2-15) and then does the dup(1) which it makes sure returns 2 or it closes the file. While there were features in V6 to allow use of fd2/stderr, few programs used then. And neither crypt nor passwd reads from fd2. crypt reads from fd0, while passwd doesn't read. It just replaces the hashed password with the new password. I've also looked at pr because >I do remember that pr -p actually read from FD 2. It probably still does. and that's not true in V7 at least... pr didn't have a 'p' arg :). Maybe later programs started to do these things, but most of what went on with V7 was a transition to most error messages on stderr, which typically went to stdout in V6. So, people remembering it coming in with V7 are right, in the sense it was the first release to do it consistently. And the people remembering V4 or V5 are also right, in a different sense because the shell was ensuring fd2 was a copy of fd1 there, which a couple of programs (diff) used for errors. And I believe that the impetus for the V7 changes was phototypesetting 'file not found' too often... But that last bit is mostly because I want to believe. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Mon Jan 23 08:10:15 2023 From: rminnich at gmail.com (ron minnich) Date: Sun, 22 Jan 2023 17:10:15 -0500 Subject: [TUHS] FD 2 In-Reply-To: References: Message-ID: Thanks very much for this interesting archaeological dig. On Sun, Jan 22, 2023, 4:23 PM Warner Losh wrote: > > > On Sat, Jan 21, 2023 at 11:37 AM Warner Losh wrote: > >> >> Yea. Like many things, there was a transition... the most important bit >> is the shell. And that was more tricky to read through with the phone at >> breakfast... >> > > OK. I've dug a bit further and Clem and I have chatted... Here's the > summary. > > We don't have V4's shell, alas, since all we have from that time period is > the C kernel a few months before the 4th edition release. V5 /bin/sh closes > fd2 and then dups fd1 to fd2. This creates fd2 as something special. V6 > closes all FD's larger than 1 (2-15) and then does the dup(1) which it > makes sure returns 2 or it closes the file. While there were features in V6 > to allow use of fd2/stderr, few programs used then. > > And neither crypt nor passwd reads from fd2. crypt reads from fd0, while > passwd doesn't read. It just replaces the hashed password with the new > password. I've also looked at pr because > > >I do remember that pr -p actually read from FD 2. It probably still does. > > and that's not true in V7 at least... pr didn't have a 'p' arg :). Maybe > later programs started to do these things, but most of what went on with V7 > was a transition to most error messages on stderr, which typically went to > stdout in V6. > > So, people remembering it coming in with V7 are right, in the sense it was > the first release to do it consistently. And the people remembering V4 or > V5 are also right, in a different sense because the shell was ensuring fd2 > was a copy of fd1 there, which a couple of programs (diff) used for errors. > And I believe that the impetus for the V7 changes was phototypesetting > 'file not found' too often... But that last bit is mostly because I want > to believe. > > Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Mon Jan 23 09:39:38 2023 From: rminnich at gmail.com (ron minnich) Date: Sun, 22 Jan 2023 15:39:38 -0800 Subject: [TUHS] interesting case of not getting the point: dc on a mac Message-ID: dc >>> it prompts with '>>> ' wonder where that came from? First time I've seen it. Seems to have a certain lack of understanding attached to it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Mon Jan 23 09:41:51 2023 From: rminnich at gmail.com (ron minnich) Date: Sun, 22 Jan 2023 15:41:51 -0800 Subject: [TUHS] interesting case of not getting the point: dc on a mac In-Reply-To: References: Message-ID: dc on linux still behaves properly. On Sun, Jan 22, 2023 at 3:39 PM ron minnich wrote: > dc > >>> > > it prompts with '>>> ' > > wonder where that came from? First time I've seen it. > > Seems to have a certain lack of understanding attached to it. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From usotsuki at buric.co Mon Jan 23 09:49:56 2023 From: usotsuki at buric.co (Steve Nickolas) Date: Sun, 22 Jan 2023 18:49:56 -0500 (EST) Subject: [TUHS] interesting case of not getting the point: dc on a mac In-Reply-To: References: Message-ID: On Sun, 22 Jan 2023, ron minnich wrote: > dc >>>> > > it prompts with '>>> ' > > wonder where that came from? First time I've seen it. > > Seems to have a certain lack of understanding attached to it. I think there was one particular dc clone...guy whose name started with a G? and his version did that. Most Linux versions use GNU's which Does The Right Thing®™©. -uso. From imp at bsdimp.com Mon Jan 23 09:50:15 2023 From: imp at bsdimp.com (Warner Losh) Date: Sun, 22 Jan 2023 16:50:15 -0700 Subject: [TUHS] interesting case of not getting the point: dc on a mac In-Reply-To: References: Message-ID: There is a BSDL DC that replaces gnu DC. The >>> is annoying, but gone in newer versions I believe. Warner On Sun, Jan 22, 2023, 4:43 PM ron minnich wrote: > dc on linux still behaves properly. > > On Sun, Jan 22, 2023 at 3:39 PM ron minnich wrote: > >> dc >> >>> >> >> it prompts with '>>> ' >> >> wonder where that came from? First time I've seen it. >> >> Seems to have a certain lack of understanding attached to it. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph at josephholsten.com Mon Jan 23 09:57:19 2023 From: joseph at josephholsten.com (Joseph Holsten) Date: Sun, 22 Jan 2023 15:57:19 -0800 Subject: [TUHS] interesting case of not getting the point: dc on a mac In-Reply-To: References: Message-ID: <600b537d-af67-43f6-b27b-f4bd26a48c33@app.fastmail.com> Is this it? https://github.com/apple-oss-distributions/bc > This bc also includes an implementation of dc in the same binary, accessible via a symbolic link, which implements all FreeBSD and GNU extensions. (If a standalone dc binary is desired, bc can be copied and renamed to dc.) The ! command is omitted; I believe this poses security concerns and that such functionality is unnecessary. On Sun, Jan 22, 2023, at 15:49, Steve Nickolas wrote: > On Sun, 22 Jan 2023, ron minnich wrote: > >> dc >>>>> >> >> it prompts with '>>> ' >> >> wonder where that came from? First time I've seen it. >> >> Seems to have a certain lack of understanding attached to it. > > I think there was one particular dc clone...guy whose name started with a > G? and his version did that. > > Most Linux versions use GNU's which Does The Right Thing®™©. > > -uso. From usotsuki at buric.co Mon Jan 23 10:07:17 2023 From: usotsuki at buric.co (Steve Nickolas) Date: Sun, 22 Jan 2023 19:07:17 -0500 (EST) Subject: [TUHS] interesting case of not getting the point: dc on a mac In-Reply-To: <600b537d-af67-43f6-b27b-f4bd26a48c33@app.fastmail.com> References: <600b537d-af67-43f6-b27b-f4bd26a48c33@app.fastmail.com> Message-ID: On Sun, 22 Jan 2023, Joseph Holsten wrote: > Is this it? https://github.com/apple-oss-distributions/bc That's the one. I knew the guy's name started with a G. How about OpenBSD's, though? That's ISC-licensed (bc.library has potential issues but you can use NetBSD's usr/src/external/bsd/bc/libmath.b instead, it serves the same purpose and doesn't have a Caldera cloud over it). -uso. From bakul at iitbombay.org Mon Jan 23 10:15:52 2023 From: bakul at iitbombay.org (Bakul Shah) Date: Sun, 22 Jan 2023 16:15:52 -0800 Subject: [TUHS] interesting case of not getting the point: dc on a mac In-Reply-To: References: Message-ID: <28A20AFF-8679-4D4F-A8CD-68965351E397@iitbombay.org> dc -V on MacOS shows 4.0.2. Repo link in the output of dc -V. The current version is 6.2.2 but it doesn't compile on Ventura. > On Jan 22, 2023, at 3:39 PM, ron minnich wrote: > > dc > >>> > > it prompts with '>>> ' > > wonder where that came from? First time I've seen it. > > Seems to have a certain lack of understanding attached to it. From rminnich at gmail.com Mon Jan 23 10:20:15 2023 From: rminnich at gmail.com (ron minnich) Date: Sun, 22 Jan 2023 19:20:15 -0500 Subject: [TUHS] interesting case of not getting the point: dc on a mac In-Reply-To: <28A20AFF-8679-4D4F-A8CD-68965351E397@iitbombay.org> References: <28A20AFF-8679-4D4F-A8CD-68965351E397@iitbombay.org> Message-ID: How do you write a dc that doesn't compile? The mind reels. On Sun, Jan 22, 2023, 7:16 PM Bakul Shah wrote: > dc -V on MacOS shows 4.0.2. Repo link in the output of dc -V. > The current version is 6.2.2 but it doesn't compile on Ventura. > > > On Jan 22, 2023, at 3:39 PM, ron minnich wrote: > > > > dc > > >>> > > > > it prompts with '>>> ' > > > > wonder where that came from? First time I've seen it. > > > > Seems to have a certain lack of understanding attached to it. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggm at algebras.org Mon Jan 23 10:23:33 2023 From: ggm at algebras.org (George Michaelson) Date: Mon, 23 Jan 2023 10:23:33 +1000 Subject: [TUHS] interesting case of not getting the point: dc on a mac In-Reply-To: References: <28A20AFF-8679-4D4F-A8CD-68965351E397@iitbombay.org> Message-ID: anything which links to libreadline... -G On Mon, Jan 23, 2023 at 10:22 AM ron minnich wrote: > > How do you write a dc that doesn't compile? > > The mind reels. > > On Sun, Jan 22, 2023, 7:16 PM Bakul Shah wrote: >> >> dc -V on MacOS shows 4.0.2. Repo link in the output of dc -V. >> The current version is 6.2.2 but it doesn't compile on Ventura. >> >> > On Jan 22, 2023, at 3:39 PM, ron minnich wrote: >> > >> > dc >> > >>> >> > >> > it prompts with '>>> ' >> > >> > wonder where that came from? First time I've seen it. >> > >> > Seems to have a certain lack of understanding attached to it. >> From joseph at josephholsten.com Mon Jan 23 10:26:23 2023 From: joseph at josephholsten.com (Joseph Holsten) Date: Sun, 22 Jan 2023 16:26:23 -0800 Subject: [TUHS] interesting case of not getting the point: dc on a mac In-Reply-To: References: <28A20AFF-8679-4D4F-A8CD-68965351E397@iitbombay.org> Message-ID: <1f8b9d71-09b7-4534-9659-8777005eb8f6@app.fastmail.com> Supposedly https://cgit.freebsd.org/src/tree/contrib/bc is kept up to date, so I’d suspect the issue lies on the macOS side. On Sun, Jan 22, 2023, at 16:20, ron minnich wrote: > How do you write a dc that doesn't compile? > > The mind reels. > > On Sun, Jan 22, 2023, 7:16 PM Bakul Shah wrote: >> dc -V on MacOS shows 4.0.2. Repo link in the output of dc -V. >> The current version is 6.2.2 but it doesn't compile on Ventura. >> >> > On Jan 22, 2023, at 3:39 PM, ron minnich wrote: >> > >> > dc >> > >>> >> > >> > it prompts with '>>> ' >> > >> > wonder where that came from? First time I've seen it. >> > >> > Seems to have a certain lack of understanding attached to it. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Mon Jan 23 10:39:45 2023 From: bakul at iitbombay.org (Bakul Shah) Date: Sun, 22 Jan 2023 16:39:45 -0800 Subject: [TUHS] interesting case of not getting the point: dc on a mac In-Reply-To: References: <28A20AFF-8679-4D4F-A8CD-68965351E397@iitbombay.org> Message-ID: Probably because MacOS moved things around or is intent on breaking things? I didn't investigate. It compiles fine on FreeBSD. > On Jan 22, 2023, at 4:20 PM, ron minnich wrote: > > How do you write a dc that doesn't compile? > > The mind reels. > > On Sun, Jan 22, 2023, 7:16 PM Bakul Shah > wrote: >> dc -V on MacOS shows 4.0.2. Repo link in the output of dc -V. >> The current version is 6.2.2 but it doesn't compile on Ventura. >> >> > On Jan 22, 2023, at 3:39 PM, ron minnich > wrote: >> > >> > dc >> > >>> >> > >> > it prompts with '>>> ' >> > >> > wonder where that came from? First time I've seen it. >> > >> > Seems to have a certain lack of understanding attached to it. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Mon Jan 23 11:32:10 2023 From: robpike at gmail.com (Rob Pike) Date: Mon, 23 Jan 2023 12:32:10 +1100 Subject: [TUHS] interesting case of not getting the point: dc on a mac In-Reply-To: References: <28A20AFF-8679-4D4F-A8CD-68965351E397@iitbombay.org> Message-ID: Pretty much everything in the dc man page on my mac raises my hackles. Not limited to changing behavior when you're on a TTY. (Also: NO ONE HAS BEEN ON A TTY FOR DECADES!) I am such an old grump. -rob On Mon, Jan 23, 2023 at 11:41 AM Bakul Shah wrote: > Probably because MacOS moved things around or is intent on breaking things? > I didn't investigate. It compiles fine on FreeBSD. > > On Jan 22, 2023, at 4:20 PM, ron minnich wrote: > > How do you write a dc that doesn't compile? > > The mind reels. > > On Sun, Jan 22, 2023, 7:16 PM Bakul Shah wrote: > >> dc -V on MacOS shows 4.0.2. Repo link in the output of dc -V. >> The current version is 6.2.2 but it doesn't compile on Ventura. >> >> > On Jan 22, 2023, at 3:39 PM, ron minnich wrote: >> > >> > dc >> > >>> >> > >> > it prompts with '>>> ' >> > >> > wonder where that came from? First time I've seen it. >> > >> > Seems to have a certain lack of understanding attached to it. >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Mon Jan 23 13:07:14 2023 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 23 Jan 2023 14:07:14 +1100 (EST) Subject: [TUHS] interesting case of not getting the point: dc on a mac In-Reply-To: References: Message-ID: On Sun, 22 Jan 2023, Steve Nickolas wrote: > I think there was one particular dc clone...guy whose name started with > a G? and his version did that. On my ancient MacBook Pro (13-inch, mid 2010, High Sierra 10.13.6): mackie:~ dave$ dc (^D) mackie:~ dave$ dc -V dc (GNU bc 1.06) 1.3 On my ancient FreeBSD server: aneurin% dc (^D) aneurin% dc -V dc (BSD bc) 1.3-FreeBSD Nil prompt in both cases. > Most Linux versions use GNU's which Does The Right Thing®™©. Perhaps so, but I try to avoid using Penguin/OS and GNU... I don't like its licence conditions ("free" it ain't), and I would rather write my own libraries than be constrained by Stallman's conditions. -- Dave From lm at mcvoy.com Mon Jan 23 13:11:11 2023 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 22 Jan 2023 19:11:11 -0800 Subject: [TUHS] interesting case of not getting the point: dc on a mac In-Reply-To: References: Message-ID: <20230123031111.GX12196@mcvoy.com> On Mon, Jan 23, 2023 at 02:07:14PM +1100, Dave Horsfall wrote: > On Sun, 22 Jan 2023, Steve Nickolas wrote: > > > I think there was one particular dc clone...guy whose name started with > > a G? and his version did that. > > On my ancient MacBook Pro (13-inch, mid 2010, High Sierra 10.13.6): > > mackie:~ dave$ dc > (^D) > mackie:~ dave$ dc -V > dc (GNU bc 1.06) 1.3 > > On my ancient FreeBSD server: > > aneurin% dc > (^D) > aneurin% dc -V > dc (BSD bc) 1.3-FreeBSD > > Nil prompt in both cases. > > > Most Linux versions use GNU's which Does The Right Thing???????. I know this is about dc (which I think is under bc or is it the other way around?) but to pick on GNU: slovax ~ 'bc' bc 1.06.95 Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc. This is free software with ABSOLUTELY NO WARRANTY. For details type `warranty'. slovax ~ alias bc alias bc='bc -ql' because, well, the same reason I run vi in terse mode. From usotsuki at buric.co Mon Jan 23 13:32:52 2023 From: usotsuki at buric.co (Steve Nickolas) Date: Sun, 22 Jan 2023 22:32:52 -0500 (EST) Subject: [TUHS] interesting case of not getting the point: dc on a mac In-Reply-To: References: Message-ID: On Mon, 23 Jan 2023, Dave Horsfall wrote: > On Sun, 22 Jan 2023, Steve Nickolas wrote: > >> I think there was one particular dc clone...guy whose name started with >> a G? and his version did that. > > On my ancient MacBook Pro (13-inch, mid 2010, High Sierra 10.13.6): > > mackie:~ dave$ dc > (^D) > mackie:~ dave$ dc -V > dc (GNU bc 1.06) 1.3 > > On my ancient FreeBSD server: > > aneurin% dc > (^D) > aneurin% dc -V > dc (BSD bc) 1.3-FreeBSD > > Nil prompt in both cases. > >> Most Linux versions use GNU's which Does The Right Thing®™©. > > Perhaps so, but I try to avoid using Penguin/OS and GNU... I don't like > its licence conditions ("free" it ain't), and I would rather write my own > libraries than be constrained by Stallman's conditions. > > -- Dave I've dealt with fanboys telling me how to do GPL on my own stuff, and it left a sore taste in my mouth. I don't care about the stuff I *use*, but it did leave me very negative about the GPL itself, and if it seems that some of the OS-building stuff I've been talking about here and elsewhere has anything to do with a grudge against GNU,...well...it does. Still, GNU does seem to have more respect for precedent than a lot of johnny-come-lately coders trying to reimplement stuff themselves. -uso. From ggm at algebras.org Mon Jan 23 13:38:52 2023 From: ggm at algebras.org (George Michaelson) Date: Mon, 23 Jan 2023 13:38:52 +1000 Subject: [TUHS] interesting case of not getting the point: dc on a mac In-Reply-To: References: Message-ID: ggm at GGM-802602 ~ % uname && dc --version |egrep git\|dc Darwin dc 4.0.2 Report bugs at: https://git.yzena.com/gavin/bc ggm at GGM-802602 ~ % finley% uname && dc --version |egrep git\|dc FreeBSD dc 5.2.2 Report bugs at: https://git.yzena.com/gavin/bc finley% On Mon, Jan 23, 2023 at 1:33 PM Steve Nickolas wrote: > > On Mon, 23 Jan 2023, Dave Horsfall wrote: > > > On Sun, 22 Jan 2023, Steve Nickolas wrote: > > > >> I think there was one particular dc clone...guy whose name started with > >> a G? and his version did that. > > > > On my ancient MacBook Pro (13-inch, mid 2010, High Sierra 10.13.6): > > > > mackie:~ dave$ dc > > (^D) > > mackie:~ dave$ dc -V > > dc (GNU bc 1.06) 1.3 > > > > On my ancient FreeBSD server: > > > > aneurin% dc > > (^D) > > aneurin% dc -V > > dc (BSD bc) 1.3-FreeBSD > > > > Nil prompt in both cases. > > > >> Most Linux versions use GNU's which Does The Right Thing®™©. > > > > Perhaps so, but I try to avoid using Penguin/OS and GNU... I don't like > > its licence conditions ("free" it ain't), and I would rather write my own > > libraries than be constrained by Stallman's conditions. > > > > -- Dave > > I've dealt with fanboys telling me how to do GPL on my own stuff, and it > left a sore taste in my mouth. I don't care about the stuff I *use*, but > it did leave me very negative about the GPL itself, and if it seems that > some of the OS-building stuff I've been talking about here and elsewhere > has anything to do with a grudge against GNU,...well...it does. > > Still, GNU does seem to have more respect for precedent than a lot of > johnny-come-lately coders trying to reimplement stuff themselves. > > -uso. From ggm at algebras.org Mon Jan 23 13:39:49 2023 From: ggm at algebras.org (George Michaelson) Date: Mon, 23 Jan 2023 13:39:49 +1000 Subject: [TUHS] interesting case of not getting the point: dc on a mac In-Reply-To: References: Message-ID: I should add both were /usr/bin/dc and I do NOT install into system owned paths on these hosts. (for me Homebrew installs in /opt and FreeBSD pkg installs in /usr/local) -G On Mon, Jan 23, 2023 at 1:38 PM George Michaelson wrote: > > ggm at GGM-802602 ~ % uname && dc --version |egrep git\|dc > Darwin > dc 4.0.2 > Report bugs at: https://git.yzena.com/gavin/bc > ggm at GGM-802602 ~ % > > finley% uname && dc --version |egrep git\|dc > FreeBSD > dc 5.2.2 > Report bugs at: https://git.yzena.com/gavin/bc > finley% > > On Mon, Jan 23, 2023 at 1:33 PM Steve Nickolas wrote: > > > > On Mon, 23 Jan 2023, Dave Horsfall wrote: > > > > > On Sun, 22 Jan 2023, Steve Nickolas wrote: > > > > > >> I think there was one particular dc clone...guy whose name started with > > >> a G? and his version did that. > > > > > > On my ancient MacBook Pro (13-inch, mid 2010, High Sierra 10.13.6): > > > > > > mackie:~ dave$ dc > > > (^D) > > > mackie:~ dave$ dc -V > > > dc (GNU bc 1.06) 1.3 > > > > > > On my ancient FreeBSD server: > > > > > > aneurin% dc > > > (^D) > > > aneurin% dc -V > > > dc (BSD bc) 1.3-FreeBSD > > > > > > Nil prompt in both cases. > > > > > >> Most Linux versions use GNU's which Does The Right Thing®™©. > > > > > > Perhaps so, but I try to avoid using Penguin/OS and GNU... I don't like > > > its licence conditions ("free" it ain't), and I would rather write my own > > > libraries than be constrained by Stallman's conditions. > > > > > > -- Dave > > > > I've dealt with fanboys telling me how to do GPL on my own stuff, and it > > left a sore taste in my mouth. I don't care about the stuff I *use*, but > > it did leave me very negative about the GPL itself, and if it seems that > > some of the OS-building stuff I've been talking about here and elsewhere > > has anything to do with a grudge against GNU,...well...it does. > > > > Still, GNU does seem to have more respect for precedent than a lot of > > johnny-come-lately coders trying to reimplement stuff themselves. > > > > -uso. From ggm at algebras.org Mon Jan 23 13:40:35 2023 From: ggm at algebras.org (George Michaelson) Date: Mon, 23 Jan 2023 13:40:35 +1000 Subject: [TUHS] interesting case of not getting the point: dc on a mac In-Reply-To: References: Message-ID: I should also also add, Mac has >>> as Rob noted. FreeBSD doesn't -G On Mon, Jan 23, 2023 at 1:39 PM George Michaelson wrote: > > I should add both were /usr/bin/dc and I do NOT install into system > owned paths on these hosts. (for me Homebrew installs in /opt and > FreeBSD pkg installs in /usr/local) > > -G > > On Mon, Jan 23, 2023 at 1:38 PM George Michaelson wrote: > > > > ggm at GGM-802602 ~ % uname && dc --version |egrep git\|dc > > Darwin > > dc 4.0.2 > > Report bugs at: https://git.yzena.com/gavin/bc > > ggm at GGM-802602 ~ % > > > > finley% uname && dc --version |egrep git\|dc > > FreeBSD > > dc 5.2.2 > > Report bugs at: https://git.yzena.com/gavin/bc > > finley% > > > > On Mon, Jan 23, 2023 at 1:33 PM Steve Nickolas wrote: > > > > > > On Mon, 23 Jan 2023, Dave Horsfall wrote: > > > > > > > On Sun, 22 Jan 2023, Steve Nickolas wrote: > > > > > > > >> I think there was one particular dc clone...guy whose name started with > > > >> a G? and his version did that. > > > > > > > > On my ancient MacBook Pro (13-inch, mid 2010, High Sierra 10.13.6): > > > > > > > > mackie:~ dave$ dc > > > > (^D) > > > > mackie:~ dave$ dc -V > > > > dc (GNU bc 1.06) 1.3 > > > > > > > > On my ancient FreeBSD server: > > > > > > > > aneurin% dc > > > > (^D) > > > > aneurin% dc -V > > > > dc (BSD bc) 1.3-FreeBSD > > > > > > > > Nil prompt in both cases. > > > > > > > >> Most Linux versions use GNU's which Does The Right Thing®™©. > > > > > > > > Perhaps so, but I try to avoid using Penguin/OS and GNU... I don't like > > > > its licence conditions ("free" it ain't), and I would rather write my own > > > > libraries than be constrained by Stallman's conditions. > > > > > > > > -- Dave > > > > > > I've dealt with fanboys telling me how to do GPL on my own stuff, and it > > > left a sore taste in my mouth. I don't care about the stuff I *use*, but > > > it did leave me very negative about the GPL itself, and if it seems that > > > some of the OS-building stuff I've been talking about here and elsewhere > > > has anything to do with a grudge against GNU,...well...it does. > > > > > > Still, GNU does seem to have more respect for precedent than a lot of > > > johnny-come-lately coders trying to reimplement stuff themselves. > > > > > > -uso. From arnold at skeeve.com Mon Jan 23 17:30:32 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 23 Jan 2023 00:30:32 -0700 Subject: [TUHS] FD 2 In-Reply-To: References: Message-ID: <202301230730.30N7UWqP018967@freefriends.org> Warner Losh wrote: > And I believe that the impetus for the V7 changes was phototypesetting > 'file not found' too often... But that last bit is mostly because I want > to believe. Doug McIlroy has told that story here, search the archives. It was indeed becase of the phototypesetter. Arnold From audioskeptic at gmail.com Mon Jan 23 18:32:53 2023 From: audioskeptic at gmail.com (James Johnston) Date: Mon, 23 Jan 2023 00:32:53 -0800 Subject: [TUHS] FD 2 In-Reply-To: <202301230730.30N7UWqP018967@freefriends.org> References: <202301230730.30N7UWqP018967@freefriends.org> Message-ID: At one point it was like $22/page. On Sun, Jan 22, 2023 at 11:30 PM wrote: > Warner Losh wrote: > > > And I believe that the impetus for the V7 changes was phototypesetting > > 'file not found' too often... But that last bit is mostly because I want > > to believe. > > Doug McIlroy has told that story here, search the archives. > It was indeed becase of the phototypesetter. > > Arnold > -- James D. (jj) Johnston Chief Scientist, Immersion Networks -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.branden.robinson at gmail.com Mon Jan 23 18:58:33 2023 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Mon, 23 Jan 2023 02:58:33 -0600 Subject: [TUHS] FD 2 In-Reply-To: References: <202301230730.30N7UWqP018967@freefriends.org> Message-ID: <20230123085833.lvxjr44d4ty2ag62@illithid> At 2023-01-23T00:32:53-0800, James Johnston wrote: > At one point it was like $22/page. > > On Sun, Jan 22, 2023 at 11:30 PM wrote: > > > Warner Losh wrote: > > > > > And I believe that the impetus for the V7 changes was > > > phototypesetting 'file not found' too often... But that last bit > > > is mostly because I want to believe. > > > > Doug McIlroy has told that story here, search the archives. > > It was indeed becase of the phototypesetter. Steve Johnson's email[0] (which I cited in my earlier reply to this thread) said it took only "a couple of days" after acquistion of the phototypesetter for this to happen. But the C/A/T was acquired by 1973[1], and the Hunt Brothers' cornering of the silver market occurred in March 1980[2], over a year _after_ the release of V7[3]. It seems both of these can't be true. I wondered if maybe only a later typesetter used a silver-based photochemical development process, but that doesn't work with troff history either, as device-independent troff wasn't ready to go until about January 1981, targetting the C/A/T and the Autologic APS-5[4], the latter with support so fresh that it wasn't in the manual yet[5]. Can someone reconcile these points? Regards, Branden [0] https://minnie.tuhs.org/pipermail/tuhs/2013-December/006113.html [1] https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/man/man1/troff.1 [2] https://en.wikipedia.org/wiki/Silver_Thursday [3] https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7 [4] https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/Volume_1/00_Annotated_Table_of_Contents.pdf (p. 2) [5] https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/Volume_1/C.1.2_NROFF_TROFF_Users_Manual.pdf (p. 34) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From brantley at coraid.com Mon Jan 23 21:49:03 2023 From: brantley at coraid.com (Brantley Coile) Date: Mon, 23 Jan 2023 06:49:03 -0500 Subject: [TUHS] FD 2 In-Reply-To: <20230123085833.lvxjr44d4ty2ag62@illithid> References: <20230123085833.lvxjr44d4ty2ag62@illithid> Message-ID: Original troff targeted only the C/A/T typesetter. bwc > On Jan 23, 2023, at 3:58 AM, G. Branden Robinson wrote: > > At 2023-01-23T00:32:53-0800, James Johnston wrote: >> At one point it was like $22/page. >> >>> On Sun, Jan 22, 2023 at 11:30 PM wrote: >>> >>> Warner Losh wrote: >>> >>>> And I believe that the impetus for the V7 changes was >>>> phototypesetting 'file not found' too often... But that last bit >>>> is mostly because I want to believe. >>> >>> Doug McIlroy has told that story here, search the archives. >>> It was indeed becase of the phototypesetter. > > Steve Johnson's email[0] (which I cited in my earlier reply to this > thread) said it took only "a couple of days" after acquistion of the > phototypesetter for this to happen. But the C/A/T was acquired by > 1973[1], and the Hunt Brothers' cornering of the silver market occurred > in March 1980[2], over a year _after_ the release of V7[3]. > > It seems both of these can't be true. I wondered if maybe only a later > typesetter used a silver-based photochemical development process, but > that doesn't work with troff history either, as device-independent troff > wasn't ready to go until about January 1981, targetting the C/A/T and > the Autologic APS-5[4], the latter with support so fresh that it wasn't > in the manual yet[5]. > > Can someone reconcile these points? > > Regards, > Branden > > [0] https://minnie.tuhs.org/pipermail/tuhs/2013-December/006113.html > [1] https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/man/man1/troff.1 > [2] https://en.wikipedia.org/wiki/Silver_Thursday > [3] https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7 > [4] https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/Volume_1/00_Annotated_Table_of_Contents.pdf > (p. 2) > [5] https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/Volume_1/C.1.2_NROFF_TROFF_Users_Manual.pdf > (p. 34) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/octet-stream Size: 833 bytes Desc: not available URL: From crossd at gmail.com Mon Jan 23 23:43:00 2023 From: crossd at gmail.com (Dan Cross) Date: Mon, 23 Jan 2023 08:43:00 -0500 Subject: [TUHS] interesting case of not getting the point: dc on a mac In-Reply-To: <20230123031111.GX12196@mcvoy.com> References: <20230123031111.GX12196@mcvoy.com> Message-ID: On Sun, Jan 22, 2023 at 10:11 PM Larry McVoy wrote: > On Mon, Jan 23, 2023 at 02:07:14PM +1100, Dave Horsfall wrote: > > On Sun, 22 Jan 2023, Steve Nickolas wrote: > > > > > I think there was one particular dc clone...guy whose name started with > > > a G? and his version did that. > > > > On my ancient MacBook Pro (13-inch, mid 2010, High Sierra 10.13.6): > > > > mackie:~ dave$ dc > > (^D) > > mackie:~ dave$ dc -V > > dc (GNU bc 1.06) 1.3 > > > > On my ancient FreeBSD server: > > > > aneurin% dc > > (^D) > > aneurin% dc -V > > dc (BSD bc) 1.3-FreeBSD > > > > Nil prompt in both cases. > > > > > Most Linux versions use GNU's which Does The Right Thing???????. > > I know this is about dc (which I think is under bc or is it the other way > around?) The other way around. `bc` is a little interpreter that accepts infix notation and has a fairly complete language built into it that generates `dc` and delegates to that to do the actual mathematics. > but to pick on GNU: > > slovax ~ 'bc' > bc 1.06.95 > Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc. > This is free software with ABSOLUTELY NO WARRANTY. > For details type `warranty'. > slovax ~ alias bc > alias bc='bc -ql' > > because, well, the same reason I run vi in terse mode. Agreed. The copyright banner every time I run `bc` is excruciating. The `-l` argument came up not too long ago elsewhere; someone asked why `bc -l` is not the default. For those that don't know, `bc -l` loads a library of math functions (sine/cosine, arctan, and a couple of transcendentals) and sets the scale to 20 decimal points. It's very useful, but I suspect the reason this wasn't the default is that loading that library cost RAM and real cycles on a PDP-11 and for most simple uses that wasn't necessary. - Dan C. From rminnich at gmail.com Mon Jan 23 23:59:40 2023 From: rminnich at gmail.com (ron minnich) Date: Mon, 23 Jan 2023 05:59:40 -0800 Subject: [TUHS] interesting case of not getting the point: dc on a mac In-Reply-To: References: <20230123031111.GX12196@mcvoy.com> Message-ID: Back in the day (mid 70s), Brian Kernighan and others from MH used to come down to udel and talk about unix. CA 1976, udel was an early licensee, or so we were told. One of the funniest talks Brian gave concerned looking up words in a dictionary, said words being all combinations of words you can spell from looking at a desk calculator upside down. It was a Thing in the 70s, along with disco balls I guess. Anyway, he showed what you got when you started up the hopelessly cumbersome look-up-a-word-at-a-time-in-webster's program that attempted to be interactive. "When you start it, it prints out its name and its version -- like we care -- " -- at the words "like we care", the room just exploded in laughter. That program was the perfect foil. Every time I see this kind of ">>>" output from reimplementations of programs such as dc, my only reaction is "like we care" :-) On Mon, Jan 23, 2023 at 5:44 AM Dan Cross wrote: > On Sun, Jan 22, 2023 at 10:11 PM Larry McVoy wrote: > > On Mon, Jan 23, 2023 at 02:07:14PM +1100, Dave Horsfall wrote: > > > On Sun, 22 Jan 2023, Steve Nickolas wrote: > > > > > > > I think there was one particular dc clone...guy whose name started > with > > > > a G? and his version did that. > > > > > > On my ancient MacBook Pro (13-inch, mid 2010, High Sierra 10.13.6): > > > > > > mackie:~ dave$ dc > > > (^D) > > > mackie:~ dave$ dc -V > > > dc (GNU bc 1.06) 1.3 > > > > > > On my ancient FreeBSD server: > > > > > > aneurin% dc > > > (^D) > > > aneurin% dc -V > > > dc (BSD bc) 1.3-FreeBSD > > > > > > Nil prompt in both cases. > > > > > > > Most Linux versions use GNU's which Does The Right Thing???????. > > > > I know this is about dc (which I think is under bc or is it the other way > > around?) > > The other way around. `bc` is a little interpreter that accepts infix > notation and has a fairly complete language built into it that > generates `dc` and delegates to that to do the actual mathematics. > > > but to pick on GNU: > > > > slovax ~ 'bc' > > bc 1.06.95 > > Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software > Foundation, Inc. > > This is free software with ABSOLUTELY NO WARRANTY. > > For details type `warranty'. > > slovax ~ alias bc > > alias bc='bc -ql' > > > > because, well, the same reason I run vi in terse mode. > > Agreed. The copyright banner every time I run `bc` is excruciating. > > The `-l` argument came up not too long ago elsewhere; someone asked > why `bc -l` is not the default. For those that don't know, `bc -l` > loads a library of math functions (sine/cosine, arctan, and a couple > of transcendentals) and sets the scale to 20 decimal points. It's very > useful, but I suspect the reason this wasn't the default is that > loading that library cost RAM and real cycles on a PDP-11 and for most > simple uses that wasn't necessary. > > - Dan C. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Tue Jan 24 00:15:55 2023 From: crossd at gmail.com (Dan Cross) Date: Mon, 23 Jan 2023 09:15:55 -0500 Subject: [TUHS] interesting case of not getting the point: dc on a mac In-Reply-To: References: Message-ID: On Sun, Jan 22, 2023 at 10:41 PM George Michaelson wrote: > I should also also add, Mac has >>> as Rob noted. FreeBSD doesn't Hmm, interesting. I wonder what version of macOS you both are running? My old trashcan Mac (soon to be replaced!) is running the next-to-most-recent version and doesn't have the `>>> ` prompt. My laptop, running the latest (Ventura?) does. I don't think I blame Apple for this, but rather something upstream of them. - Dan C. From ron at ronnatalie.com Tue Jan 24 00:25:25 2023 From: ron at ronnatalie.com (Ronald Natalie) Date: Mon, 23 Jan 2023 14:25:25 +0000 Subject: [TUHS] FD 2 In-Reply-To: References: <20230123085833.lvxjr44d4ty2ag62@illithid> Message-ID: Indeed but the output format was not too hard to decipher and we wrote drivers for other things. One of the most odd projects I helped with was a program called verset which was a C/A/T type setter emulator that output to a Versetec printer plotter. This was my friend George Toth’s baby. What he did was go down to the NRL and get a complete printout of the typefaces on their C/A/T printed on film at about 72pt. He then cut them into individual pieces. He build a flying spot scanner out of an oscilliscoe with a photomultiplier tube in a scope camera housing. Now in the building next to ours was at the time the worlds finest Scanning Transmission Electron Microscope. It was driven by a PDP-11/20. Esentially the beam scanned back and forth and there was a detected at the bottom. So George, would take the drive and sense wires off the microscope and connect them to the oscilloscope/camera combination. He’d take one letter and stick it to the face of the oscilliscope. We would then bring up the microscope software and tell it to scan a sample. It would do so loading the image into the framebuffer. We would then boot up MiniUnix and read the data out of the framebuffer and store it on an RK05 pack that we’d later take over to our main machine, the PDP-11/45 running a full up (hacked V6) UNIX. It was probably the worlds most expensive text scanner in the world. Of course, I did some favors for that department, so I got free access to that machine when it wasn’t being used by actual microscope operators. ------ Original Message ------ >From "Brantley Coile" To "G. Branden Robinson" Cc tuhs at tuhs.org Date 1/23/2023 6:49:03 AM Subject [TUHS] Re: FD 2 >Original troff targeted only the C/A/T typesetter. >bwc > From brian at zick.io Tue Jan 24 00:45:39 2023 From: brian at zick.io (Brian M Zick) Date: Mon, 23 Jan 2023 08:45:39 -0600 Subject: [TUHS] Cooked Mode (v8 shell) In-Reply-To: <202301221452.30MEqrRq025402@freefriends.org> References: <202301221452.30MEqrRq025402@freefriends.org> Message-ID: <351292a2-7800-4c00-8e33-c6cfc51dedb7@app.fastmail.com> > 6) It ran in cooked mode. Sorry if this is obvious to everyone else: What does this phrase mean? 𝖇♦︎𝖒♦︎𝖟 * From chet.ramey at case.edu Tue Jan 24 00:49:08 2023 From: chet.ramey at case.edu (Chet Ramey) Date: Mon, 23 Jan 2023 09:49:08 -0500 Subject: [TUHS] Cooked Mode (v8 shell) In-Reply-To: <351292a2-7800-4c00-8e33-c6cfc51dedb7@app.fastmail.com> References: <202301221452.30MEqrRq025402@freefriends.org> <351292a2-7800-4c00-8e33-c6cfc51dedb7@app.fastmail.com> Message-ID: <64e4b53e-04a6-5da1-334e-33dfbceb4ace@case.edu> On 1/23/23 9:45 AM, Brian M Zick wrote: >> 6) It ran in cooked mode. > > Sorry if this is obvious to everyone else: What does this phrase mean? It did not perform line editing, so it did not change the terminal modes and read one character at a time. If you only ever read a line at a time from the terminal, you can let the terminal driver do that for you. -- ``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 tytso at mit.edu Tue Jan 24 01:51:41 2023 From: tytso at mit.edu (Theodore Ts'o) Date: Mon, 23 Jan 2023 10:51:41 -0500 Subject: [TUHS] Cooked Mode (v8 shell) In-Reply-To: <64e4b53e-04a6-5da1-334e-33dfbceb4ace@case.edu> References: <202301221452.30MEqrRq025402@freefriends.org> <351292a2-7800-4c00-8e33-c6cfc51dedb7@app.fastmail.com> <64e4b53e-04a6-5da1-334e-33dfbceb4ace@case.edu> Message-ID: On Mon, Jan 23, 2023 at 09:49:08AM -0500, Chet Ramey wrote: > On 1/23/23 9:45 AM, Brian M Zick wrote: > > > 6) It ran in cooked mode. > > > > Sorry if this is obvious to everyone else: What does this phrase mean? > > It did not perform line editing, so it did not change the terminal modes > and read one character at a time. If you only ever read a line at a time > from the terminal, you can let the terminal driver do that for you. I've never been convinced by that particular argument, since if you want command-line completion, the terminal driver is way too low-level. I suppose you could have callouts from the kernel to applications that were willing to provide context-sensitive command-line completion lists, which is how Multics handled things (trivia for the day: the libss library used by Linux's e2fsprogs and MIT Kerberos v5's kadmin interface uses an API inspired by Multics' subsystem library), but the point is that you can't do it all in the terminal driver. Cheers, - Ted From chet.ramey at case.edu Tue Jan 24 01:53:46 2023 From: chet.ramey at case.edu (Chet Ramey) Date: Mon, 23 Jan 2023 10:53:46 -0500 Subject: [TUHS] Cooked Mode (v8 shell) In-Reply-To: References: <202301221452.30MEqrRq025402@freefriends.org> <351292a2-7800-4c00-8e33-c6cfc51dedb7@app.fastmail.com> <64e4b53e-04a6-5da1-334e-33dfbceb4ace@case.edu> Message-ID: On 1/23/23 10:51 AM, Theodore Ts'o wrote: > On Mon, Jan 23, 2023 at 09:49:08AM -0500, Chet Ramey wrote: >> On 1/23/23 9:45 AM, Brian M Zick wrote: >>>> 6) It ran in cooked mode. >>> >>> Sorry if this is obvious to everyone else: What does this phrase mean? >> >> It did not perform line editing, so it did not change the terminal modes >> and read one character at a time. If you only ever read a line at a time >> from the terminal, you can let the terminal driver do that for you. > > I've never been convinced by that particular argument, since if you > want command-line completion, the terminal driver is way too > low-level. But that's the point: they don't. -- ``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 douglas.mcilroy at dartmouth.edu Tue Jan 24 02:59:00 2023 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Mon, 23 Jan 2023 11:59:00 -0500 Subject: [TUHS] FD 2 In-Reply-To: References: <202301230730.30N7UWqP018967@freefriends.org> Message-ID: >> And I believe that the impetus for the V7 changes was phototypesetting >> 'file not found' too often... But that last bit is mostly because I want >> to believe. > Doug McIlroy has told that story here, search the archives. > It was indeed becase of the phototypesetter. If I ever said that I must have been smoking something at the time. The phototypesetter is a dramatic example, but a minor cause. The major cause was pipes. Downstream programs fail when they receive diagnostics rather than data. And users never see the reason why. Doug On Mon, Jan 23, 2023 at 3:34 AM James Johnston wrote: > > At one point it was like $22/page. > > On Sun, Jan 22, 2023 at 11:30 PM wrote: >> >> Warner Losh wrote: >> >> > And I believe that the impetus for the V7 changes was phototypesetting >> > 'file not found' too often... But that last bit is mostly because I want >> > to believe. >> >> Doug McIlroy has told that story here, search the archives. >> It was indeed becase of the phototypesetter. >> >> Arnold > > > > -- > James D. (jj) Johnston > > Chief Scientist, Immersion Networks From brantley at coraid.com Tue Jan 24 03:43:34 2023 From: brantley at coraid.com (Brantley Coile) Date: Mon, 23 Jan 2023 12:43:34 -0500 Subject: [TUHS] FD 2 In-Reply-To: References: <20230123085833.lvxjr44d4ty2ag62@illithid> Message-ID: What a great story! On January 23, 2023 9:25:25 AM EST, Ronald Natalie wrote: >Indeed but the output format was not too hard to decipher and we wrote drivers for other things. > >One of the most odd projects I helped with was a program called verset which was a C/A/T type setter emulator that output to a Versetec printer plotter. >This was my friend George Toth’s baby. What he did was go down to the NRL and get a complete printout of the typefaces on their C/A/T printed on film at about 72pt. >He then cut them into individual pieces. He build a flying spot scanner out of an oscilliscoe with a photomultiplier tube in a scope camera housing. > >Now in the building next to ours was at the time the worlds finest Scanning Transmission Electron Microscope. It was driven by a PDP-11/20. Esentially the beam scanned back and forth and there was a detected at the bottom. So George, would take the drive and sense wires off the microscope and connect them to the oscilloscope/camera combination. He’d take one letter and stick it to the face of the oscilliscope. We would then bring up the microscope software and tell it to scan a sample. It would do so loading the image into the framebuffer. We would then boot up MiniUnix and read the data out of the framebuffer and store it on an RK05 pack that we’d later take over to our main machine, the PDP-11/45 running a full up (hacked V6) UNIX. > >It was probably the worlds most expensive text scanner in the world. Of course, I did some favors for that department, so I got free access to that machine when it wasn’t being used by actual microscope operators. > >------ Original Message ------ >From "Brantley Coile" >To "G. Branden Robinson" >Cc tuhs at tuhs.org >Date 1/23/2023 6:49:03 AM >Subject [TUHS] Re: FD 2 > >> Original troff targeted only the C/A/T typesetter. >> bwc >> > From marc.donner at gmail.com Tue Jan 24 06:40:30 2023 From: marc.donner at gmail.com (Marc Donner) Date: Mon, 23 Jan 2023 15:40:30 -0500 Subject: [TUHS] Cooked Mode (v8 shell) In-Reply-To: References: <202301221452.30MEqrRq025402@freefriends.org> <351292a2-7800-4c00-8e33-c6cfc51dedb7@app.fastmail.com> <64e4b53e-04a6-5da1-334e-33dfbceb4ace@case.edu> Message-ID: https://en.wikipedia.org/wiki/Terminal_mode ===== nygeek.net mindthegapdialogs.com/home On Mon, Jan 23, 2023 at 10:53 AM Chet Ramey wrote: > On 1/23/23 10:51 AM, Theodore Ts'o wrote: > > On Mon, Jan 23, 2023 at 09:49:08AM -0500, Chet Ramey wrote: > >> On 1/23/23 9:45 AM, Brian M Zick wrote: > >>>> 6) It ran in cooked mode. > >>> > >>> Sorry if this is obvious to everyone else: What does this phrase mean? > >> > >> It did not perform line editing, so it did not change the terminal modes > >> and read one character at a time. If you only ever read a line at a time > >> from the terminal, you can let the terminal driver do that for you. > > > > I've never been convinced by that particular argument, since if you > > want command-line completion, the terminal driver is way too > > low-level. > > But that's the point: they don't. > > -- > ``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/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph at josephholsten.com Tue Jan 24 07:08:47 2023 From: joseph at josephholsten.com (Joseph Holsten) Date: Mon, 23 Jan 2023 13:08:47 -0800 Subject: [TUHS] interesting case of not getting the point: dc on a mac In-Reply-To: References: Message-ID: On Mon, Jan 23, 2023, at 06:15, Dan Cross wrote: > On Sun, Jan 22, 2023 at 10:41 PM George Michaelson wrote: >> I should also also add, Mac has >>> as Rob noted. FreeBSD doesn't > > Hmm, interesting. I wonder what version of macOS you both are running? > My old trashcan Mac (soon to be replaced!) is running the > next-to-most-recent version and doesn't have the `>>> ` prompt. My > laptop, running the latest (Ventura?) does. > > I don't think I blame Apple for this, but rather something upstream of them. Per https://opensource.apple.com/releases/, they switched from macOS Monterey 12 with GNU bc 1.06 https://github.com/apple-oss-distributions/bc/tree/bc-21/bc to macOS 13 with GH bc 4.0.2 https://github.com/apple-oss-distributions/bc/tree/bc-26/bc I suspect this is similar to the replacement of bash with zsh for GPL avoidance. Interesting timeline though, https://git.yzena.com/gavin/bc/src/tag/4.0.2 was released in 2021-05-01, https://git.yzena.com/gavin/bc/src/tag/5.0.0 in 2021-08-08. From tuhs at tuhs.org Tue Jan 24 10:59:10 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 24 Jan 2023 00:59:10 +0000 Subject: [TUHS] Three New Scans (Sys V User and Admin Guides, TS 4.0 Programmer's Package) Message-ID: <-k4MjoGJ0xnSNfpLni9ZqdfWl9pV1zL_ebglsL594vU51AxQstQZxJOIc_W8OlONKzz8Yw-JaZka9BkmLjaiVMnHAwathHiq0fygoRN7MAM=@protonmail.com> Good day everyone, just emailing to notify of three more documents I've uploaded to archive.org since my last slew of them: https://archive.org/details/unix-programming-starter-package - Up first is the UNIX Programming Starter Package.  This is one of a pair of manuals that saw publication in the Bell system around the time of UNIX/TS 4.0.  The documents here appear to be a subset of those which shipped with Documents for UNIX 4.0. Nothing particularly new here.  There is a companion manual, UNIX Text Editing & Phototypesetting Starter Package, which I also have but haven't hit the scan bench with yet.  Like this one, that is just a subset of papers from the Documents for UNIX collection.  Based on the TOC, this second one also shipped with one of those PWB/MM multi-fold pamphlets, but didn't receive one when I got this.  Luckily that was also scanned as part of the 4.0 collection.  So nothing really new here, save that these are 1st generation scans vs the scans of photocopies for the 4.0 release.  That said, I've seen this set with the same cover motif except with an AT&T death star logo in the upper right.  Didn't look into it too much at the time, but I'd be curious if anyone might have those and if they have the programming one, if it still refers to Release 4.0 in the documentation roadmap. https://archive.org/details/unix-system-users-guide-release-5-0 - This is the User's Guide that shipped with Release 5.0/System V.  This covers the usual suspects as well as some notes on RJE and SCCS from a user's perspective. https://archive.org/details/unix-system-administrators-guide-5-0 - And this is the Administrator's Guide likewise from SysV era.  This one contains setup and maintenance notes for both DEC (PDP & VAX) and 3B20(S) machines, as well as papers on accounting, LP printing, RJE, filesystem checking, and the System Activity Package.  Additionally, the guide includes the original Modification Request form. - Matt G. From athornton at gmail.com Tue Jan 24 10:59:05 2023 From: athornton at gmail.com (Adam Thornton) Date: Mon, 23 Jan 2023 17:59:05 -0700 Subject: [TUHS] interesting case of not getting the point: dc on a mac In-Reply-To: References: Message-ID: I was hoping for a better easter egg. I dunno about y'all but when I see ">>>" .... my mind goes a certain place. Alas, no. adam at m1-wired:~/git/phalanx/services/nublado$ dc >>> boot dqa0 Parse error: bad character 't' :1 On Mon, Jan 23, 2023 at 2:09 PM Joseph Holsten wrote: > On Mon, Jan 23, 2023, at 06:15, Dan Cross wrote: > > On Sun, Jan 22, 2023 at 10:41 PM George Michaelson > wrote: > >> I should also also add, Mac has >>> as Rob noted. FreeBSD doesn't > > > > Hmm, interesting. I wonder what version of macOS you both are running? > > My old trashcan Mac (soon to be replaced!) is running the > > next-to-most-recent version and doesn't have the `>>> ` prompt. My > > laptop, running the latest (Ventura?) does. > > > > I don't think I blame Apple for this, but rather something upstream of > them. > > Per https://opensource.apple.com/releases/, they switched from > macOS Monterey 12 with GNU bc 1.06 > https://github.com/apple-oss-distributions/bc/tree/bc-21/bc > to macOS 13 with GH bc 4.0.2 > https://github.com/apple-oss-distributions/bc/tree/bc-26/bc > > I suspect this is similar to the replacement of bash with zsh for GPL > avoidance. > > Interesting timeline though, https://git.yzena.com/gavin/bc/src/tag/4.0.2 > was released in 2021-05-01, https://git.yzena.com/gavin/bc/src/tag/5.0.0 > in 2021-08-08. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsg at jsg.id.au Tue Jan 24 13:15:42 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Tue, 24 Jan 2023 14:15:42 +1100 Subject: [TUHS] Three New Scans (Sys V User and Admin Guides, TS 4.0 Programmer's Package) In-Reply-To: <-k4MjoGJ0xnSNfpLni9ZqdfWl9pV1zL_ebglsL594vU51AxQstQZxJOIc_W8OlONKzz8Yw-JaZka9BkmLjaiVMnHAwathHiq0fygoRN7MAM=@protonmail.com> References: <-k4MjoGJ0xnSNfpLni9ZqdfWl9pV1zL_ebglsL594vU51AxQstQZxJOIc_W8OlONKzz8Yw-JaZka9BkmLjaiVMnHAwathHiq0fygoRN7MAM=@protonmail.com> Message-ID: On Tue, Jan 24, 2023 at 12:59:10AM +0000, segaloco via TUHS wrote: > Good day everyone, just emailing to notify of three more documents I've uploaded to archive.org since my last slew of them: > > https://archive.org/details/unix-programming-starter-package - Up first is the UNIX Programming Starter Package.  This is one of a pair of manuals that saw publication in the Bell system around the time of UNIX/TS 4.0.  The documents here appear to be a subset of those which shipped with Documents for UNIX 4.0. Nothing particularly new here.  There is a companion manual, UNIX Text Editing & Phototypesetting Starter Package, which I also have but haven't hit the scan bench with yet.  Like this one, that is just a subset of papers from the Documents for UNIX collection.  Based on the TOC, this second one also shipped with one of those PWB/MM multi-fold pamphlets, but didn't receive one when I got this.  Luckily that was also scanned as part of the 4.0 collection.  So nothing really new here, save that these are 1st generation scans vs the scans of photocopies for the 4.0 release.  That said, I've seen this set with the same cover motif except with an AT&T death star logo in the upper right.  Didn't look into it too much at the time, but I'd be curious if anyone might have those and if they have the programming one, if it still refers to Release 4.0 in the documentation roadmap. thanks, covers were added to wikimedia by Craig MacGregor in 2012: https://commons.wikimedia.org/wiki/File:Bell_Labs_UNIX_Guides.jpg https://upload.wikimedia.org/wikipedia/commons/8/84/Bell_Labs_UNIX_Guides.jpg https://commons.wikimedia.org/wiki/File:Bell_Labs_UNIX_Text_Editing_%26_Phototypesetting_Starter_Package_(open).jpg https://upload.wikimedia.org/wikipedia/commons/2/28/Bell_Labs_UNIX_Text_Editing_%26_Phototypesetting_Starter_Package_%28open%29.jpg https://commons.wikimedia.org/wiki/File:Bell_Labs_UNIX_Text_Editing_%26_Phototypesetting_Starter_Package_(Table_of_Contents).jpg https://upload.wikimedia.org/wikipedia/commons/f/f5/Bell_Labs_UNIX_Text_Editing_%26_Phototypesetting_Starter_Package_%28Table_of_Contents%29.jpg > > https://archive.org/details/unix-system-users-guide-release-5-0 - This is the User's Guide that shipped with Release 5.0/System V.  This covers the usual suspects as well as some notes on RJE and SCCS from a user's perspective. https://commons.wikimedia.org/wiki/File:Western_Electric_UNIX_User%27s_Guide_(open).jpg https://upload.wikimedia.org/wikipedia/commons/b/b6/Western_Electric_UNIX_User%27s_Guide_%28open%29.jpg https://commons.wikimedia.org/wiki/File:Western_Electric_UNIX_User%27s_Guide_and_Graphics_Guide.jpg https://upload.wikimedia.org/wikipedia/commons/b/b0/Western_Electric_UNIX_User%27s_Guide_and_Graphics_Guide.jpg > > > https://archive.org/details/unix-system-administrators-guide-5-0 - And this is the Administrator's Guide likewise from SysV era.  This one contains setup and maintenance notes for both DEC (PDP & VAX) and 3B20(S) machines, as well as papers on accounting, LP printing, RJE, filesystem checking, and the System Activity Package.  Additionally, the guide includes the original Modification Request form. > "Get the UNIX Programming Starter Package from your local Computer Information Service Library." https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/Volume_1/B.1.1_UNIX_Documentation_Roadmap.pdf "Documentation (available from Computing Information Library, x3514, IH 7C-102) UNIX Programming Starter Package UNIX Text Editing Phototypesetting Starter Package UNIX System User's Manual (current release) UNIX BIBLIOGRAPHY" Indian Hill Computation Center, QUICK REFERENCE GUIDE, November 1983 http://vtda.org/docs/computing/BellLabs/BTL_IHCC_QRG1183.pdf some photos of Indian Hill and org charts of Lab 534 in 1979 http://web.archive.org/web/20210505130641/http://www.ka9q.net/IH534-recruiting-propaganda.pdf via Phil Karn in https://www.linkedin.com/pulse/old-bell-labs-indian-hill-recruiting-brochure-phil-karn From arnold at skeeve.com Tue Jan 24 17:21:27 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 24 Jan 2023 00:21:27 -0700 Subject: [TUHS] FD 2 In-Reply-To: References: <202301230730.30N7UWqP018967@freefriends.org> Message-ID: <202301240721.30O7LRBb000597@freefriends.org> I stand corrected. Thanks. Arnold Douglas McIlroy wrote: > >> And I believe that the impetus for the V7 changes was phototypesetting > >> 'file not found' too often... But that last bit is mostly because I want > >> to believe. > > > Doug McIlroy has told that story here, search the archives. > > It was indeed becase of the phototypesetter. > > If I ever said that I must have been smoking something at the time. > The phototypesetter is a dramatic example, but a minor cause. > The major cause was pipes. Downstream programs fail > when they receive diagnostics rather than data. And users > never see the reason why. > > Doug > > On Mon, Jan 23, 2023 at 3:34 AM James Johnston wrote: > > > > At one point it was like $22/page. > > > > On Sun, Jan 22, 2023 at 11:30 PM wrote: > >> > >> Warner Losh wrote: > >> > >> > And I believe that the impetus for the V7 changes was phototypesetting > >> > 'file not found' too often... But that last bit is mostly because I want > >> > to believe. > >> > >> Doug McIlroy has told that story here, search the archives. > >> It was indeed becase of the phototypesetter. > >> > >> Arnold > > > > > > > > -- > > James D. (jj) Johnston > > > > Chief Scientist, Immersion Networks From jsg at jsg.id.au Wed Jan 25 00:09:08 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Wed, 25 Jan 2023 01:09:08 +1100 Subject: [TUHS] Release 5.0 Vs. System V In-Reply-To: References: Message-ID: On Fri, Sep 16, 2022 at 06:48:44PM +0000, segaloco via TUHS wrote: > Good morning all, currently trying to sort out one matter that still bewilders me with this documentation I'm working on scanning. > > So I've got two copies of the "Release 5.0" User's Manual and one copy of the "System V" User's Manual. I haven't identified the exact differences, lots of pages...but they certainly are not identical, there are at least a few commands in one and not the other. > > Given this, and past discussion, it's obvious Release 5.0 is the internal UNIX version that became System V, but what I'm curious about is if it was ever released publicly as "Release 5.0" before being branded as System V or if the name was System V from the moment the first commercial license was issued. > > The reason I wonder this is some inconsistencies in the documentation I see out there. So both of my Release 5.0 User's Manuals have the Bell logo on the front and no mention of the court order to cease using it. Likewise, all but one of the System V related documents I received recently contain a Bell logo on the cover next to Western Electric save for the Opeartor's Guide which curiously doesn't exhibit the front page divestiture message that other documents missing the Bell logo include. Furthermore, the actual cover sheet says "Operator's Guide UNIX System Release 5.0" so technically not System V. In fact, only the User's Manual, Administrator's Manual, Error Message Manual, Transition Aids, and Release Description specifically say System V, all the rest don't have a version listed but some list Release 5.0 on their title page. > > Furthering that discrepancy is this which I just purchased: https://www.ebay.com/itm/314135813726?_trkparms=amclksrc%3DITM%26aid%3D111001%26algo%3DREC.SEED%26ao%3D1%26asc%3D242152%26meid%3Dd1b5923533b045acae4f14b9dd8b4e57%26pid%3D100675%26rk%3D2%26rkt%3D14%26sd%3D284965858677%26itm%3D314135813726%26pmt%3D0%26noa%3D1%26pg%3D2380057&_trksid=p2380057.c100675.m4236&_trkparms=pageci%3A8d64fbe5-35ed-11ed-8efb-b6aa9c31d728|parentrq%3A47906e531830a0adef7482b3fffe1682|iid%3A1 > > Link lives as of this sending, but contains a closed auction for an Error Message Manual from the "Release 5.0" documentation line but no Bell logo. Until the Operator's Guide and this auction link, I haven't seen any "Release 5.0" branded stuff without a Bell logo, and before I bought the System V gold set, I hadn't seen System V branded stuff *with* the Bell logo. > > This shatters an assumption that I had made that at the same time the documentation branding shifted to System V was the same time the removal of the Bell logo happened, given that divestiture was what allowed them to aggressively market System V, but now this presents four distinct sets of System V gold documentation: > > Release 5.0 w/ Bell logo > Release 5.0 w/o Bell logo > System V w/ Bell logo > System V w/o Bell logo > > I'm curious if anyone would happen to know what the significance here is. The covers are all printed, I can't see any indication that a bunch of 5.0 manuals were retroactively painted over nor that any System V manuals got stamped with a Bell post-production. What this means is "Release 5.0" documentation was being shipped post-divestiture and "System V" was being shipped pre-divestiture. If Release 5.0 was publicly sold as System V, then what explains the post-divestiture 5.0 manuals floating around in the wild, and vice versa, if USG couldn't effectively market and support UNIX until the divestiture, how is it so many "Release 5.0" documents are floating around in well produced commercial-quality binding, both pre and post-divestiture by the time the name "System V" would've been king. Were they still maintaining an internal 5.x branch past System V that warranted its own distinct documentation set even into the commercial period? This period right around '82-'83 is incredibly fascinating and I feel very under-documented. For at least the User's Manual and Administrator's Manual there is another version. https://www.ebay.com/itm/204176652924?orig_cvip=true UNIX System User's Manual Release 5.0 Including BTL Computer Center Standard and Local Commands June 1982 different cover without mention of Western Electric (another old ebay listing) UNIX System Administrator's Manual Release 5.0 Including BTL Computer Center Standard and Local Commands June 1982 same cover as above user's manual https://books.google.com.au/books/about/UNIX_System_V_Release_2_0.html?id=Qg9bNwAACAAJ UNIX System V: Release 2.0, User Reference Manual Including BTL Computer Center Standard and Local Commands December 1983 Pirzada's thesis mentions 5.0, 5.0.1, 5.0.3, 5.0.5 System V 1.0, 1.1, 1.2, 2.0, 2.2, 3.0 "Release 5.0, announced in October 1982." "AT&T's divestiture in 1983 allowed UNIX to compete in the commercial market place and on 1st January 1983, Commercial System V was announced. As it was identical to Release 5.0, this was the first time that current version of UNIX in the Labs was licensed outside." http://www.bitsavers.org/pdf/att/unix/System_V_Release_1/301-905_UNIX_System_V_Release_1_Users_Manual_Jan83.pdf UNIX System User's Manual System V January 1983 301-905 Issue 1 'Pursuant to Judge Greene's Order of August 5, 1983, beginning on January 1, 1984, AT&T will cease to use "BELL" and the Bell symbol, with the exceptions as set forth in that Order. Pursuant thereto, any reference to "BELL" and / or the BELL symbol in this document is hereby deleted and "expunged".' AT&T Documentation Guide, 1987: http://www.bitsavers.org/pdf/att/000-111_ATT_Documentation_Guide_Nov87.pdf UNIX SYSTEM RELEASE 5.0 ADMINISTRATOR'S GUIDE 301-931 UNIX SYSTEM RELEASE 5.0 ADMINISTRATOR'S MANUAL 301-926 UNIX SYSTEM RELEASE 5.0 ERROR MESSAGE MANUAL 301-922 UNIX SYSTEM RELEASE 5.0 USER'S MANUAL 301-925 UNIX SYSTEM V RELEASE 1.0 ADMINISTRATOR'S GUIDE 301-939 UNIX SYSTEM V RELEASE 1.0 ADMINISTRATOR'S MANUAL 301-906 UNIX SYSTEM V RELEASE 1.0 ASSIST SOFTWARE DEVELOPMENT TOOLS GUIDE 307-235 UNIX SYSTEM V RELEASE 1.0 ASSIST SOFTWARE RELEASE NOTES 307-238 UNIX SYSTEM V RELEASE 1.0 ASSIST SOFTWARE SOURCE CODE RELEASE NOTES. 307-236 UNIX SYSTEM V RELEASE 1.0 ASSIST SOFTWARE USER'S GUIDE 307-234 UNIX SYSTEM V RELEASE 1.0 DOCUMENT PROCESSING GUIDE 341-920 UNIX SYSTEM V RELEASE 1.0 ERROR MESSAGE MANUAL 301-907 UNIX SYSTEM V RELEASE 1.0 GRAPHICS GUIDE 341-921 UNIX SYSTEM V RELEASE 1.0 OPERATOR'S GUIDE 301-941 UNIX SYSTEM V RELEASE 1.0 PROGRAMMING GUIDE 341-930 UNIX SYSTEM V RELEASE 1.0 REMOTE FILE SHARING UTILITIES REFERENCE CARD 307-000 UNIX SYSTEM V RELEASE 1.0 SUPPORT TOOLS GUIDE 341-940 UNIX SYSTEM V RELEASE 1.0 SYSTEM RELEASE DESCRIPTION INTERNATIONAL VERSION 307-017 UNIX SYSTEM V RELEASE 1.0 TRANSITION AIDS 301-908 UNIX SYSTEM V RELEASE 1.0 USER'S GUIDE 301-921 UNIX SYSTEM V RELEASE 1.0 USER'S MANUAL 301-905 From crossd at gmail.com Wed Jan 25 03:16:14 2023 From: crossd at gmail.com (Dan Cross) Date: Tue, 24 Jan 2023 12:16:14 -0500 Subject: [TUHS] Fwd: How did Bell Labs start to work on Project MAC? Message-ID: [Bcc: to TUHS as it's not strictly Unix related, but relevant to the pre-history] This came from USENET, specifically, alt.os.multics. Since it's unlikely anyone in a position to answer is going to see it there, I'm reposting here: >From Acceptable Name : >Did Bell Labs approach MIT or was it the other way around? >Did participating in Project MAC come from researchers requesting >management at Bell Labs/MIT or did management make the >decision due to dealing with other managers in each of the two >organizations? Did it grow out of an informal arrangement into >a format one?" These are interesting questions. Perhaps Doug may be in the know? - Dan C. From will.senn at gmail.com Wed Jan 25 11:46:54 2023 From: will.senn at gmail.com (Will Senn) Date: Tue, 24 Jan 2023 19:46:54 -0600 Subject: [TUHS] Setting up an X Development Environment for Mac OS Message-ID: <3e272d72-b77a-d347-b5c3-7ed19482e5af@gmail.com> All, If you think unix ends without x, just move along, nothing to see here. Otherwise, I thought I would share the subject of my latest post and a link with those of you interested in such things. Recently, I've been tooling around trying to wrap my head around x windows and wanted to give programming it a shot at the xlib level... on my mac, if possible. So, I bought a copy of Adrian Nye's Xlib Programming Manual for Version 11 R4/R5, aka Volume One of The Definitive Guides to the X Window System, published, get this... 30+ years ago, in 1992 :) and started reading like a madman. As usual, this was an example of great technical writing from the prior millenium, something rarely found today. Anyway, I hunted up the source code examples as published, unpacked them, did a few environmental things to my mac, and built my first xlib application from that source. A few tweaks to my XQuartz configuration and I was running the application in twm on my mac, with a root window. To read about it and see it in all of its glory, check it out here: https://decuser.github.io/operating-systems/mojave/x-windows/2023/01/24/x-windows-dev-on-mac.html The same sort of setup works with Linux, FreeBSD, or my latest environment DragonFly BSD. It's not the environment that I find interesting, but rather the X Window System itself, but this is my way of entering into that world. If you are interested in running X Windows, not as an integrated system on your mac (where x apps run in aqua windows), but with a 'regular' window manager, and you haven't figured out how, this is one way. On the provocateur front - is X part of unix? I mean this in oh so many nuanced ways, so read into it as you will. I would contend, torpedoes be damned, that it is :). Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Wed Jan 25 17:45:44 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 25 Jan 2023 07:45:44 +0000 Subject: [TUHS] Setting up an X Development Environment for Mac OS In-Reply-To: <3e272d72-b77a-d347-b5c3-7ed19482e5af@gmail.com> References: <3e272d72-b77a-d347-b5c3-7ed19482e5af@gmail.com> Message-ID: <3h5FEAegoTs6FrhHODiW-rBdB59dt_Rmr4G0PIw7flqaJLsmorgPsilm4f2aJkDud-qEljDjnCJcE1uY05Iw4HNQcyNG4W3wzVlLD0UZfLg=@protonmail.com> I suspect even what with Wayland making the rounds, there'll probably be X around for a looooong time. My guess anyway. I just recently built an X setup from scratch on Linux, it wasn't too much of a pain save that the protocol headers have merged into the xorgproto package. I didn't realize this until I had already installed older versions of all the individual packages. I was surprised to learn in the process that xterm is not distributed by XOrg, but by someone else. It even features in the default xdm session along with xconsole and xsm, so certainly considered a standard component of X, but distributed and maintained independently it seems. Aa for the questions of the UNIX-ness of X, it started in Athena, which as I understand it was supposed to be relatively OS-agnostic distributed computing? In any case, the predecessor ran on a different OS, not sure how significant that is to the genesis of what would be called X or what OS it "started" on. Aside from the ubiquitous X books (which I mean to add to my library...) USL also shipped a handful of books with SVR4 concerning both X and NeWS. I've only got the Xlib one but it seems to cover the basics pretty well. I'd be curious to compare it to the other set. One of these days I mean to round out that SVR4 documentation set. There were probably materials in the SVR4.2 era as well but I haven't focused as much on those books. Dunno what if any documentation Novell then Caldera/SCO kept up with. I'd love a fresh round of print books, I much prefer paper for reference, but nowadays new tech material is most certainly second/third-hand rather than thoughtfully crafted by the team and those adjacent to whatever is being described. I love me a good primary source.... I've played with XQuartz a bit, mainly remote X from one of my Linux boxes. Kinda slow...but I did zero tuning so not sure what the expected performance of X-over-ssh is. In any case, given the ubiquity, I doubt we'll see X going anywhere soon, and even when it does eventually start to sunset, there'll probably be shims and wrappers for compatibility for a while longer. Plus, I don't know what the prospects are regarding Wayland and SVR4 derivs, but they're all happily running X still, and aren't necessarily getting any new large-scale development love, so likely will ride out with X. - Matt G. ------- Original Message ------- On Tuesday, January 24th, 2023 at 5:46 PM, Will Senn wrote: > All, > > If you think unix ends without x, just move along, nothing to see here. Otherwise, I thought I would share the subject of my latest post and a link with those of you interested in such things. > > Recently, I've been tooling around trying to wrap my head around x windows and wanted to give programming it a shot at the xlib level... on my mac, if possible. So, I bought a copy of Adrian Nye's Xlib Programming Manual for Version 11 R4/R5, aka Volume One of The Definitive Guides to the X Window System, published, get this... 30+ years ago, in 1992 :) and started reading like a madman. As usual, this was an example of great technical writing from the prior millenium, something rarely found today. > > Anyway, I hunted up the source code examples as published, unpacked them, did a few environmental things to my mac, and built my first xlib application from that source. A few tweaks to my XQuartz configuration and I was running the application in twm on my mac, with a root window. > > To read about it and see it in all of its glory, check it out here: > > https://decuser.github.io/operating-systems/mojave/x-windows/2023/01/24/x-windows-dev-on-mac.html > > The same sort of setup works with Linux, FreeBSD, or my latest environment DragonFly BSD. It's not the environment that I find interesting, but rather the X Window System itself, but this is my way of entering into that world. If you are interested in running X Windows, not as an integrated system on your mac (where x apps run in aqua windows), but with a 'regular' window manager, and you haven't figured out how, this is one way. > > On the provocateur front - is X part of unix? I mean this in oh so many nuanced ways, so read into it as you will. I would contend, torpedoes be damned, that it is :). > > Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Wed Jan 25 18:00:00 2023 From: lars at nocrew.org (Lars Brinkhoff) Date: Wed, 25 Jan 2023 08:00:00 +0000 Subject: [TUHS] Setting up an X Development Environment for Mac OS In-Reply-To: <3h5FEAegoTs6FrhHODiW-rBdB59dt_Rmr4G0PIw7flqaJLsmorgPsilm4f2aJkDud-qEljDjnCJcE1uY05Iw4HNQcyNG4W3wzVlLD0UZfLg=@protonmail.com> (segaloco via TUHS's message of "Wed, 25 Jan 2023 07:45:44 +0000") References: <3e272d72-b77a-d347-b5c3-7ed19482e5af@gmail.com> <3h5FEAegoTs6FrhHODiW-rBdB59dt_Rmr4G0PIw7flqaJLsmorgPsilm4f2aJkDud-qEljDjnCJcE1uY05Iw4HNQcyNG4W3wzVlLD0UZfLg=@protonmail.com> Message-ID: <7wcz73cadb.fsf@junk.nocrew.org> segaloco wrote: > A[s] for the questions of the UNIX-ness of X, it started in Athena It's my understanding it was started by Bob Scheifler of the CLU group. It was soon picked up by Jim Gettys and Project Athena. From rich.salz at gmail.com Thu Jan 26 02:41:12 2023 From: rich.salz at gmail.com (Rich Salz) Date: Wed, 25 Jan 2023 11:41:12 -0500 Subject: [TUHS] Setting up an X Development Environment for Mac OS In-Reply-To: <3h5FEAegoTs6FrhHODiW-rBdB59dt_Rmr4G0PIw7flqaJLsmorgPsilm4f2aJkDud-qEljDjnCJcE1uY05Iw4HNQcyNG4W3wzVlLD0UZfLg=@protonmail.com> References: <3e272d72-b77a-d347-b5c3-7ed19482e5af@gmail.com> <3h5FEAegoTs6FrhHODiW-rBdB59dt_Rmr4G0PIw7flqaJLsmorgPsilm4f2aJkDud-qEljDjnCJcE1uY05Iw4HNQcyNG4W3wzVlLD0UZfLg=@protonmail.com> Message-ID: > Aa for the questions of the UNIX-ness of X, it started in Athena, which as > I understand it was supposed to be relatively OS-agnostic distributed > computing? In any case, the predecessor ran on a different OS, not sure how > significant that is to the genesis of what would be called X or what OS it > "started" on. > Athena was about scaling up Unix workstations. It was started with grants from IBM and Digital. It was never OS-agnostic. You can find a brief history of X at https://www.oreilly.com/library/view/x-power-tools/9780596101954/ch01.html, and the Wikipedia article on the X Window System is pretty good; reed the "History" section. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Thu Jan 26 05:53:30 2023 From: tytso at mit.edu (Theodore Ts'o) Date: Wed, 25 Jan 2023 14:53:30 -0500 Subject: [TUHS] Setting up an X Development Environment for Mac OS In-Reply-To: References: <3e272d72-b77a-d347-b5c3-7ed19482e5af@gmail.com> <3h5FEAegoTs6FrhHODiW-rBdB59dt_Rmr4G0PIw7flqaJLsmorgPsilm4f2aJkDud-qEljDjnCJcE1uY05Iw4HNQcyNG4W3wzVlLD0UZfLg=@protonmail.com> Message-ID: On Wed, Jan 25, 2023 at 11:41:12AM -0500, Rich Salz wrote: > > Aa for the questions of the UNIX-ness of X, it started in Athena, which as > > I understand it was supposed to be relatively OS-agnostic distributed > > computing? In any case, the predecessor ran on a different OS, not sure how > > significant that is to the genesis of what would be called X or what OS it > > "started" on. > > Athena was about scaling up Unix workstations. It was started with grants > from IBM and Digital. It was never OS-agnostic. Well..... technically Athena was about computing in higher ed. If you go far back enough, at the very beginning, we used VAX 750's and IBM PC/AT's running DOS. As soon as the Microvax 2's and IBM PC/RT's came in, about 2 or so years in, Project Athena switched to Unix workstations, but in the earliest days (which would have been pre-X Windows), Project Athena had not yet standardized on Unix or workstations for that matter. The VAX 750's were huge time-sharing systems that you could connect to via VT-100's and VS-100 that were hard-wired to the VAX 750's, and telnet from IBM PC/AT's. The smaller clusters used PC/AT's because they were more flexible as to which 750 you were connecting to; otherwise, undergraduates had to go to the right terminal room in the right part of campus to connect to the Vax 750 that you were assgined to based on the starting character of your last name. (And graduate students initially didn't have access to Project Athena at all; although if you were in EECS, LCS or the AI Lab you had access to dedicated systems, of course.) One of the perks for being hired as a student systems programmer back then was that you got accounts on all of the Vax 750's, so you could use any terminal room across campus. :-) We then would either rlogin to our "home" Vax 750, or we had scripts that would replicate our home directories across the various 750's. There was a brief, shining moment that we were standardized on BSD-derived Unix systems, but then IBM turned down AOS (the "academic" operating system), and we were forced to use AIX on the IBM RT's, with all that this implied: SMIT, and other horrors. "AIX: it *reminds* you of Unix...." was the saying at the time --- although we tried not to say that when the IBM engineers assigned Athena were in hearing range :-). The one saving grace of the IBM RT's was that they were three MIPS machines, while the Microvax's were but a single MIPS, and that made a huge different if you were running TeX or LaTeX. Cheers, - Ted From crossd at gmail.com Thu Jan 26 06:04:27 2023 From: crossd at gmail.com (Dan Cross) Date: Wed, 25 Jan 2023 15:04:27 -0500 Subject: [TUHS] Setting up an X Development Environment for Mac OS In-Reply-To: References: <3e272d72-b77a-d347-b5c3-7ed19482e5af@gmail.com> <3h5FEAegoTs6FrhHODiW-rBdB59dt_Rmr4G0PIw7flqaJLsmorgPsilm4f2aJkDud-qEljDjnCJcE1uY05Iw4HNQcyNG4W3wzVlLD0UZfLg=@protonmail.com> Message-ID: On Wed, Jan 25, 2023 at 2:54 PM Theodore Ts'o wrote: >[snip] > The VAX 750's were huge time-sharing systems that you could connect to > via VT-100's and VS-100 that were hard-wired to the VAX 750's, and > telnet from IBM PC/AT's. The smaller clusters used PC/AT's because > they were more flexible as to which 750 you were connecting to; > otherwise, undergraduates had to go to the right terminal room in the > right part of campus to connect to the Vax 750 that you were assgined > to based on the starting character of your last name. (And graduate > students initially didn't have access to Project Athena at all; > although if you were in EECS, LCS or the AI Lab you had access to > dedicated systems, of course.) Was this before the introduction of DECserver terminal concentrators? >[snip] > There was a brief, shining moment that we were standardized on > BSD-derived Unix systems, but then IBM turned down AOS (the "academic" > operating system), and we were forced to use AIX on the IBM RT's, with > all that this implied: SMIT, and other horrors. Huh, I thought that AOS ran on all versions of the RT? I know they dropped support for it when the power-based RS/6000s came out and replaced the RT, though. > "AIX: it *reminds* you of Unix...." was the saying at the time --- > although we tried not to say that when the IBM engineers assigned > Athena were in hearing range :-). The one saving grace of the IBM > RT's was that they were three MIPS machines, while the Microvax's were > but a single MIPS, and that made a huge different if you were running > TeX or LaTeX. The RT was a weird duck, for sure. Compared to a SPARCstation it was absurdly slow, but I guess compared to a uVAX perhaps not so much. - Dan C. From lm at mcvoy.com Thu Jan 26 06:23:38 2023 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 25 Jan 2023 12:23:38 -0800 Subject: [TUHS] Setting up an X Development Environment for Mac OS In-Reply-To: References: <3e272d72-b77a-d347-b5c3-7ed19482e5af@gmail.com> <3h5FEAegoTs6FrhHODiW-rBdB59dt_Rmr4G0PIw7flqaJLsmorgPsilm4f2aJkDud-qEljDjnCJcE1uY05Iw4HNQcyNG4W3wzVlLD0UZfLg=@protonmail.com> Message-ID: <20230125202338.GB9901@mcvoy.com> On Wed, Jan 25, 2023 at 03:04:27PM -0500, Dan Cross wrote: > The RT was a weird duck, for sure. Compared to a SPARCstation it was > absurdly slow, but I guess compared to a uVAX perhaps not so much. I think the RT predated the SPARC machines. There were RT's running BSD at UW-Madison when I was a grad student there (UW did something, maybe the BSD port to RT?) and they were pretty nice. Sun machines were still 68K, there were no SPARCs at UW-Madison at that time. Yeah, looked it up, they were released in 1987, we had RT machines early, perhaps before the release in 1986 to do the port. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From chet.ramey at case.edu Thu Jan 26 06:27:12 2023 From: chet.ramey at case.edu (Chet Ramey) Date: Wed, 25 Jan 2023 15:27:12 -0500 Subject: [TUHS] Setting up an X Development Environment for Mac OS In-Reply-To: <20230125202338.GB9901@mcvoy.com> References: <3e272d72-b77a-d347-b5c3-7ed19482e5af@gmail.com> <3h5FEAegoTs6FrhHODiW-rBdB59dt_Rmr4G0PIw7flqaJLsmorgPsilm4f2aJkDud-qEljDjnCJcE1uY05Iw4HNQcyNG4W3wzVlLD0UZfLg=@protonmail.com> <20230125202338.GB9901@mcvoy.com> Message-ID: <886bce28-71d2-a39c-f881-3131c91e6e04@case.edu> On 1/25/23 3:23 PM, Larry McVoy wrote: > On Wed, Jan 25, 2023 at 03:04:27PM -0500, Dan Cross wrote: >> The RT was a weird duck, for sure. Compared to a SPARCstation it was >> absurdly slow, but I guess compared to a uVAX perhaps not so much. > > I think the RT predated the SPARC machines. There were RT's running BSD > at UW-Madison when I was a grad student there (UW did something, maybe > the BSD port to RT?) and they were pretty nice. Didn't AOS use the UW BSD NFS port? I know it had NFS; we used them for a long time and I had one in my home for years. -- ``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 jnc at mercury.lcs.mit.edu Thu Jan 26 06:38:05 2023 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 25 Jan 2023 15:38:05 -0500 (EST) Subject: [TUHS] Setting up an X Development Environment for Mac OS Message-ID: <20230125203805.4762218C083@mercury.lcs.mit.edu> > From: Lars Brinkhoff > It's my understanding it was started by Bob Scheifler of the CLU group. Yes, that's correct. (Bob's office was right around the corner from me - although I had very little knowledge of what his group was up to; I was too busy with other things.) I have this vague memory that his version was actually written in CLU? Can that be correct? It would make sense, since that group was so focused on CLU - but maybe not, see below. X must have been done after LCS got the 750 farm (on which we ran 4.1c, to start with) - although I don't know what kind of terminals they were using to run X on - we didn't have any bit-mapped displays on them, I'm pretty sure. Although maybe it was later, once Micro-Vaxes appeared? I have this vague memory that it was based (perhaps only in design, not code re-use) on a window system done at Stanford {looks}; yes, W (hence 'X'): https://en.wikipedia.org/wiki/W_Window_System The X paper listed there: https://dl.acm.org/doi/pdf/10.1145/22949.24053 doesn't say anything about the implementation, so maybe that vague memory/assumption that I had that it was originally written in CLU is wrong. Liskov's 'History of CLU' paper, which lists things done in CLU, doesn't mention it, so I must have been confused? Do any of the really early versions of X (and W) still exist? Noel From clemc at ccc.com Thu Jan 26 07:25:32 2023 From: clemc at ccc.com (Clem Cole) Date: Wed, 25 Jan 2023 16:25:32 -0500 Subject: [TUHS] Setting up an X Development Environment for Mac OS In-Reply-To: <20230125203805.4762218C083@mercury.lcs.mit.edu> References: <20230125203805.4762218C083@mercury.lcs.mit.edu> Message-ID: On Wed, Jan 25, 2023 at 3:38 PM Noel Chiappa wrote: > > Do any of the really early versions of X (and W) still exist? > Not that I have found. I looked a couple a years ago. FWIW: I would be surprised if any of it was in CLU, because the first version of X was a redo from synchronous W protocol to the async one Bob did. If I remember it correctly ... W as for the V Kernel on the Stanford (68K based) Sun Terminal, that Paul Asente and Brian Reid did at Stanford (in C). The Paul and Chris Kent at DEC (either WRL or SRC I foirget which) took it and made it work on a VS100 and microvax. That version when to MIT via the Athena connection and Bob rewrote the back-end creating the X from W. Shortly after that Gettys brought the Microvax X version out to me in Westford where, he, Jack Burness and I got it running on a 68K based Masscomp over a weekend fairly soon after Jack his first version of his new BITBLT primitive working - which until then we lacked (it was pretty cool how quick it came up). Clem ᐧ ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph at josephholsten.com Thu Jan 26 10:31:12 2023 From: joseph at josephholsten.com (Joseph Holsten) Date: Wed, 25 Jan 2023 16:31:12 -0800 Subject: [TUHS] Earliest UNIX Workstations? Message-ID: An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Thu Jan 26 10:51:07 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 26 Jan 2023 00:51:07 +0000 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: References: Message-ID: Nothing says a PDP-11 has to be in a rack with peripherals right? If one could devise up emulated peripherals that plug into the backplane or otherwise tear them down to fit in much less space, a PDP-11 could probably be made to inhabit similar desk real-estate as a workstation, especially some of the smaller LSI models. There's also the MicroVAXen but the SUN-1 beats those to the market. All in all, I would wager workstation has never been a well regulated term and, especially once PCs and other micros got better, the delineation between a workstation and a consumer PC has just gotten blurrier and blurrier. For instance, I would use the term workstation to apply to my Raspberry Pi, someone else would probably chuckle at the thought while sitting at their modern POWER9 system. It fits all the needs of my non-day-job computing, so workstation enough for me. - Matt G. ------- Original Message ------- On Wednesday, January 25th, 2023 at 4:31 PM, Joseph Holsten wrote: > It seems like there are bountiful articles able the decline and fall of the UNIX workstation, but I’ve had a hard time finding narrative about workstations prior to the Stanford SUN workstation. > > * was the SUN-1 the first commercially successful product? What are the “it depends” edge cases? > * were there common recipes for proto-workstations within academic or industrial research? What did those look like, who was involved? > * What do I really mean by workstation? Ex.gr. If an installation had a PDP-11 with a single terminal and operator, is it not a workstation? Is it the integration of display into the system that differentiates? > > -- > Joseph Holsten > [http://josephholsten.com](http://josephholsten.com/) > > mailto:joseph at josephholsten.com > > tel:[+1-360-927-7234](tel:(360)%20927-7234) -------------- next part -------------- An HTML attachment was scrubbed... URL: From stewart at serissa.com Thu Jan 26 11:01:17 2023 From: stewart at serissa.com (Larry Stewart) Date: Wed, 25 Jan 2023 20:01:17 -0500 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: References: Message-ID: <23432965-52D6-4331-A4D8-8A6FDDB3F751@serissa.com> An HTML attachment was scrubbed... URL: From luther at makerlisp.com Thu Jan 26 11:06:36 2023 From: luther at makerlisp.com (Luther Johnson) Date: Wed, 25 Jan 2023 18:06:36 -0700 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: References: Message-ID: I think what made 'workstations' different was: 1) You had your own computer, you were not just using a terminal connected to a computer, that was time-shared with a bunch of other users 2) A very capable large bit-mapped display, hence the variation on this term, "graphic workstation" 3) Networking to shared filesystems - in time sharing, you're all on one computer, going to the same files on the same disk(s), in a network of workstations, you're all going to a network with filesystems mounted on disks on machines all over the network. Some workstations had disks and filesystems, some did not - hence another variation, "disk-less workstation", which booted from the network. "Servers" were big machines with big disks, really the same kinds of machines, basically, but configured to be effective at hosting resources and people were discouraged from logging in and camping out on them. That's how I remember it, the machines and capabilities were also accompanied by the different modes of resource use that they enabled. On 01/25/2023 05:51 PM, segaloco via TUHS wrote: > Nothing says a PDP-11 has to be in a rack with peripherals right? If > one could devise up emulated peripherals that plug into the backplane > or otherwise tear them down to fit in much less space, a PDP-11 could > probably be made to inhabit similar desk real-estate as a workstation, > especially some of the smaller LSI models. There's also the MicroVAXen > but the SUN-1 beats those to the market. > > All in all, I would wager workstation has never been a well regulated > term and, especially once PCs and other micros got better, the > delineation between a workstation and a consumer PC has just gotten > blurrier and blurrier. For instance, I would use the term workstation > to apply to my Raspberry Pi, someone else would probably chuckle at > the thought while sitting at their modern POWER9 system. It fits all > the needs of my non-day-job computing, so workstation enough for me. > > - Matt G. > ------- Original Message ------- > On Wednesday, January 25th, 2023 at 4:31 PM, Joseph Holsten > wrote: > >> It seems like there are bountiful articles able the decline and fall >> of the UNIX workstation, but I’ve had a hard time finding narrative >> about workstations prior to the Stanford SUN workstation. >> >> * was the SUN-1 the first commercially successful product? What are >> the “it depends” edge cases? >> * were there common recipes for proto-workstations within academic or >> industrial research? What did those look like, who was involved? >> * What do I really mean by workstation? Ex.gr. If an installation had >> a PDP-11 with a single terminal and operator, is it not a >> workstation? Is it the integration of display into the system that >> differentiates? >> >> -- >> Joseph Holsten >> http://josephholsten.com >> mailto:joseph at josephholsten.com >> tel:+1-360-927-7234 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pugs78 at gmail.com Thu Jan 26 11:12:27 2023 From: pugs78 at gmail.com (Tom Lyon) Date: Wed, 25 Jan 2023 20:12:27 -0500 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: References: Message-ID: I believe the term "workstation" came from the integrated interactive engineering design terminals/systems. Can't remember details, but companies like ComputerVision had had them before UNIX and 68000 were a thing, On Wed, Jan 25, 2023 at 7:31 PM Joseph Holsten wrote: > It seems like there are bountiful articles able the decline and fall of > the UNIX workstation, but I’ve had a hard time finding narrative about > workstations prior to the Stanford SUN workstation. > > * was the SUN-1 the first commercially successful product? What are the > “it depends” edge cases? > * were there common recipes for proto-workstations within academic or > industrial research? What did those look like, who was involved? > * What do I really mean by workstation? Ex.gr. If an installation had a > PDP-11 with a single terminal and operator, is it not a workstation? Is it > the integration of display into the system that differentiates? > > -- > Joseph Holsten > http://josephholsten.com > mailto:joseph at josephholsten.com > tel:+1-360-927-7234 <(360)%20927-7234> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Thu Jan 26 11:15:25 2023 From: jon at fourwinds.com (Jon Steinhart) Date: Wed, 25 Jan 2023 17:15:25 -0800 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: References: Message-ID: <202301260115.30Q1FPuS101446@darkstar.fourwinds.com> Luther Johnson writes: > I think what made 'workstations' different was: > > 1) You had your own computer, you were not just using a terminal connected to a > computer, that was time-shared with a bunch of other users While it wasn't UNIX but a stupidly lost market opportunity the Tektronix 4051 was one of the first workstations. From cmhanson at eschatologist.net Thu Jan 26 11:47:07 2023 From: cmhanson at eschatologist.net (Chris Hanson) Date: Wed, 25 Jan 2023 17:47:07 -0800 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: References: Message-ID: On Jan 25, 2023, at 4:31 PM, Joseph Holsten wrote: > > It seems like there are bountiful articles able the decline and fall of the UNIX workstation, but I’ve had a hard time finding narrative about workstations prior to the Stanford SUN workstation. > > * was the SUN-1 the first commercially successful product? What are the “it depends” edge cases? Nope, Apollo and the Three Rivers PERQ both predate Sun. And while one can certainly question PERQ's commercial success I don't think one can question Apollo's—they were done in by HP's purchase, not by market forces. Apollo Aegis wasn't actually UNIX, but was very UNIX-like since it was designed by people who had worked at Prime on PrimOS and on MULTICS before that. And later releases provided more specifically UNIX-style environments for users as an alternative to Aegis. The Three Rivers PERQ had several different environments available, including multiple UNIX implementations. > * were there common recipes for proto-workstations within academic or industrial research? What did those look like, who was involved? They mostly looked like the Xerox Alto, once it made waves in the research community. > * What do I really mean by workstation? Ex.gr. If an installation had a PDP-11 with a single terminal and operator, is it not a workstation? Is it the integration of display into the system that differentiates? I think "a graphical system intended to be used by a professional to use in their work" is a good starting point for a definition. I should check at home tonight how "A History of Personal Workstations" defines it. Note that I wouldn't necessarily require a workstation to be primarily used by a single user; lots of 1970s CAD systems supported multiple user workstations on a single computer. -- Chris From lars at nocrew.org Thu Jan 26 16:30:30 2023 From: lars at nocrew.org (Lars Brinkhoff) Date: Thu, 26 Jan 2023 06:30:30 +0000 Subject: [TUHS] Setting up an X Development Environment for Mac OS In-Reply-To: (Clem Cole's message of "Wed, 25 Jan 2023 16:25:32 -0500") References: <20230125203805.4762218C083@mercury.lcs.mit.edu> Message-ID: <7w8rhpdczd.fsf@junk.nocrew.org> Clem Cole wrote: > Noel Chiappa wrote: > > Do any of the really early versions of X (and W) still exist? > Not that I have found. Jim Gettys says he has old versions of X on tapes. As for W, no trace that I have found. From lars at nocrew.org Thu Jan 26 16:32:26 2023 From: lars at nocrew.org (Lars Brinkhoff) Date: Thu, 26 Jan 2023 06:32:26 +0000 Subject: [TUHS] Setting up an X Development Environment for Mac OS In-Reply-To: <20230125203805.4762218C083@mercury.lcs.mit.edu> (Noel Chiappa's message of "Wed, 25 Jan 2023 15:38:05 -0500 (EST)") References: <20230125203805.4762218C083@mercury.lcs.mit.edu> Message-ID: <7w4jsddcw5.fsf@junk.nocrew.org> Noel Chiappa writes: > I have this vague memory that his version was actually written in CLU? What you may remember is that X had a CLU (and Argus) interface library before it had one for C. It says so in Bob's announcement, of which there is a copy of the CLU page on Wikipedia. From cowan at ccil.org Thu Jan 26 17:20:40 2023 From: cowan at ccil.org (John Cowan) Date: Thu, 26 Jan 2023 02:20:40 -0500 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: References: Message-ID: On Wed, Jan 25, 2023 at 8:47 PM Chris Hanson wrote: > > * What do I really mean by workstation? Ex.gr. If an installation had a > PDP-11 with a single terminal and operator, is it not a workstation? Is it > the integration of display into the system that differentiates? > > I think "a graphical system intended to be used by a professional to use > in their work" is a good starting point for a definition. I should check at > home tonight how "A History of Personal Workstations" defines it. > WP says the Terak 8510/a was the first graphical workstation; it came out in 1976-77 and ran the UCSD p-System. I had never heard of it before. The first *personal* workstation (non-graphical) was probably the IBM 1620 (aka the CADET system, "Can't Add, Doesn't Even Try") from 1959. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Thu Jan 26 17:33:30 2023 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 26 Jan 2023 18:33:30 +1100 (EST) Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: References: Message-ID: On Thu, 26 Jan 2023, John Cowan wrote: > WP says the Terak 8510/a was the first graphical workstation; it came > out in 1976-77 and ran the UCSD p-System.  I had never heard of it > before. The first *personal* workstation (non-graphical) was probably > the IBM 1620 (aka the CADET system, "Can't Add, Doesn't Even Try") from > 1959. Mmm... Would a GT-40 connected to a PDP-11/40 count as a workstation? I started using that around 1975 (along with serial terminals, of course), in my first job at Uni of NSW (after graduating from there). -- Dave From tuhs at tuhs.org Thu Jan 26 19:45:46 2023 From: tuhs at tuhs.org (emanuel stiebler via TUHS) Date: Thu, 26 Jan 2023 04:45:46 -0500 Subject: [TUHS] Setting up an X Development Environment for Mac OS In-Reply-To: <20230125203805.4762218C083@mercury.lcs.mit.edu> References: <20230125203805.4762218C083@mercury.lcs.mit.edu> Message-ID: <1961d673-6c18-523b-1e7b-eb9d664ca069@e-bbes.com> On 2023-01-25 15:38, Noel Chiappa wrote: > I have this vague memory that his version was actually written in CLU? Can > that be correct? It would make sense, since that group was so focused on CLU > - but maybe not, see below. There is a copy of the email from Robert Scheifler introducing X: https://lunduke.substack.com/p/w-the-window-system-before-x-that From emu at e-bbes.com Thu Jan 26 19:52:56 2023 From: emu at e-bbes.com (emanuel stiebler) Date: Thu, 26 Jan 2023 04:52:56 -0500 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: References: Message-ID: On 2023-01-25 19:31, Joseph Holsten wrote: > * What do I really mean by workstation? Ex.gr. If an installation had a > PDP-11 with a single terminal and operator, is it not a workstation? Is > it the integration of display into the system that differentiates? I remember people calling something a workstation, if it has the four "M" at least 1 MByte memory at least 1 megapixel display at least 1 mbit/s network can't remember the fourth(was there a fourth?) From robpike at gmail.com Thu Jan 26 19:58:55 2023 From: robpike at gmail.com (Rob Pike) Date: Thu, 26 Jan 2023 20:58:55 +1100 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: References: Message-ID: at least 1 million words of marketing? -rob On Thu, Jan 26, 2023 at 8:54 PM emanuel stiebler wrote: > On 2023-01-25 19:31, Joseph Holsten wrote: > > > * What do I really mean by workstation? Ex.gr. If an installation had a > > PDP-11 with a single terminal and operator, is it not a workstation? Is > > it the integration of display into the system that differentiates? > > I remember people calling something a workstation, > if it has the four "M" > > at least 1 MByte memory > at least 1 megapixel display > at least 1 mbit/s network > can't remember the fourth(was there a fourth?) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Thu Jan 26 20:09:33 2023 From: tuhs at tuhs.org (Jaap Akkerhuis via TUHS) Date: Thu, 26 Jan 2023 11:09:33 +0100 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: References: Message-ID: > can't remember the fourth(was there a fourth?) Mips -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: Message signed with OpenPGP URL: From ralph at inputplus.co.uk Thu Jan 26 20:56:26 2023 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Thu, 26 Jan 2023 10:56:26 +0000 Subject: [TUHS] Setting up an X Development Environment for Mac OS In-Reply-To: <7w8rhpdczd.fsf@junk.nocrew.org> References: <20230125203805.4762218C083@mercury.lcs.mit.edu> <7w8rhpdczd.fsf@junk.nocrew.org> Message-ID: <20230126105626.72CD922168@orac.inputplus.co.uk> Hi Lars, > Jim Gettys says he has old versions of X on tapes. If you know Jim, you may want to prod him to shift the data to more modern media if those tapes are old. Rob Pike wrote of magnetic tapes he had which could no longer be read. The coating had failed off IIRC. I tried to find the text but failed. Perhaps it was on one of those Google+, Posterous, ... transient things. -- Cheers, Ralph. From arnold at skeeve.com Thu Jan 26 22:01:18 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 26 Jan 2023 05:01:18 -0700 Subject: [TUHS] Setting up an X Development Environment for Mac OS In-Reply-To: <20230126105626.72CD922168@orac.inputplus.co.uk> References: <20230125203805.4762218C083@mercury.lcs.mit.edu> <7w8rhpdczd.fsf@junk.nocrew.org> <20230126105626.72CD922168@orac.inputplus.co.uk> Message-ID: <202301261201.30QC1IQD003922@freefriends.org> Amen to that. There are tape recovery services; old X versions would be worth having online somewhere, for the history. Ralph Corderoy wrote: > Hi Lars, > > > Jim Gettys says he has old versions of X on tapes. > > If you know Jim, you may want to prod him to shift the data to more > modern media if those tapes are old. > > Rob Pike wrote of magnetic tapes he had which could no longer be read. > The coating had failed off IIRC. I tried to find the text but failed. > Perhaps it was on one of those Google+, Posterous, ... transient things. > > -- > Cheers, Ralph. From tuhs at tuhs.org Thu Jan 26 23:15:15 2023 From: tuhs at tuhs.org (Paul Ruizendaal via TUHS) Date: Thu, 26 Jan 2023 14:15:15 +0100 Subject: [TUHS] Earliest UNIX Workstations? Message-ID: <8D18A032-AD21-4601-852E-CC96FD438170@planet.nl> >> * What do I really mean by workstation? Ex.gr. If an installation had a >> PDP-11 with a single terminal and operator, is it not a workstation? Is >> it the integration of display into the system that differentiates? > > I remember people calling something a workstation, > if it has the four "M" > > at least 1 MByte memory > at least 1 megapixel display > at least 1 mbit/s network > can't remember the fourth(was there a fourth?) I remember it as: at least 1 MByte memory at least 1 megapixel display at least 1 MIPS cost at most 1 mega penny (10K, maybe 35K in today’s money) That matches with Wikipedia, for whatever that is worth: https://en.wikipedia.org/wiki/3M_computer but note that it talks about 3M not 4M. With hindsight, not adding in networking speed looks strange -- but maybe the world had already settled on LAN speeds above 1Mb/s by 1980 (Ethernet, ARCNet) From marc.donner at gmail.com Thu Jan 26 23:17:14 2023 From: marc.donner at gmail.com (Marc Donner) Date: Thu, 26 Jan 2023 08:17:14 -0500 Subject: [TUHS] Setting up an X Development Environment for Mac OS In-Reply-To: References: <3e272d72-b77a-d347-b5c3-7ed19482e5af@gmail.com> <3h5FEAegoTs6FrhHODiW-rBdB59dt_Rmr4G0PIw7flqaJLsmorgPsilm4f2aJkDud-qEljDjnCJcE1uY05Iw4HNQcyNG4W3wzVlLD0UZfLg=@protonmail.com> Message-ID: A couple of years after Athena got going the Andrew project at CMU got started. That project focused primarily on early Sun workstations. There was some fooling around with some sort of Unix on the PC/AT, but the lack of virtual memory support and the weakness of the networking cards for the machine meant that we never saw them. My memory of how X evolved is a bit confused, but there was a collaboration between Athena and Andrew. Each had built window systems independently. My recollection is that Gosling, Rosenthal, and Sidebotham built the core of the CMU one. It introduced the separation between the display engine (the ‘server’) and the application (the ‘client’) using an ancestor of the X Protocol. After a while a consolidated window system was agreed, using front end ideas from the MIT W system and the CMU wm system and preserving the X Protocol. This produced a flexible architecture that allowed an application to run anywhere and display in a window anywhere else. It also made networking support a must. On Wed, Jan 25, 2023 at 2:54 PM Theodore Ts'o wrote: > On Wed, Jan 25, 2023 at 11:41:12AM -0500, Rich Salz wrote: > > > Aa for the questions of the UNIX-ness of X, it started in Athena, > which as > > > I understand it was supposed to be relatively OS-agnostic distributed > > > computing? In any case, the predecessor ran on a different OS, not > sure how > > > significant that is to the genesis of what would be called X or what > OS it > > > "started" on. > > > > Athena was about scaling up Unix workstations. It was started with grants > > from IBM and Digital. It was never OS-agnostic. > > Well..... technically Athena was about computing in higher ed. If you > go far back enough, at the very beginning, we used VAX 750's and IBM > PC/AT's running DOS. As soon as the Microvax 2's and IBM PC/RT's came > in, about 2 or so years in, Project Athena switched to Unix > workstations, but in the earliest days (which would have been pre-X > Windows), Project Athena had not yet standardized on Unix or > workstations for that matter. > > The VAX 750's were huge time-sharing systems that you could connect to > via VT-100's and VS-100 that were hard-wired to the VAX 750's, and > telnet from IBM PC/AT's. The smaller clusters used PC/AT's because > they were more flexible as to which 750 you were connecting to; > otherwise, undergraduates had to go to the right terminal room in the > right part of campus to connect to the Vax 750 that you were assgined > to based on the starting character of your last name. (And graduate > students initially didn't have access to Project Athena at all; > although if you were in EECS, LCS or the AI Lab you had access to > dedicated systems, of course.) > > One of the perks for being hired as a student systems programmer back > then was that you got accounts on all of the Vax 750's, so you could > use any terminal room across campus. :-) We then would either rlogin > to our "home" Vax 750, or we had scripts that would replicate our home > directories across the various 750's. > > There was a brief, shining moment that we were standardized on > BSD-derived Unix systems, but then IBM turned down AOS (the "academic" > operating system), and we were forced to use AIX on the IBM RT's, with > all that this implied: SMIT, and other horrors. > > "AIX: it *reminds* you of Unix...." was the saying at the time --- > although we tried not to say that when the IBM engineers assigned > Athena were in hearing range :-). The one saving grace of the IBM > RT's was that they were three MIPS machines, while the Microvax's were > but a single MIPS, and that made a huge different if you were running > TeX or LaTeX. > > Cheers, > > - Ted > -- ===== nygeek.net mindthegapdialogs.com/home -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Thu Jan 26 23:25:20 2023 From: lars at nocrew.org (Lars Brinkhoff) Date: Thu, 26 Jan 2023 13:25:20 +0000 Subject: [TUHS] Setting up an X Development Environment for Mac OS In-Reply-To: <202301261201.30QC1IQD003922@freefriends.org> (arnold@skeeve.com's message of "Thu, 26 Jan 2023 05:01:18 -0700") References: <20230125203805.4762218C083@mercury.lcs.mit.edu> <7w8rhpdczd.fsf@junk.nocrew.org> <20230126105626.72CD922168@orac.inputplus.co.uk> <202301261201.30QC1IQD003922@freefriends.org> Message-ID: <7wy1ppbf7j.fsf@junk.nocrew.org> arnold at skeeve.com wrote: > Ralph Corderoy wrote: >> If you know Jim, you may want to prod him to shift the data to more >> modern media if those tapes are old. > Amen to that. There are tape recovery services; old X versions > would be worth having online somewhere, for the history. I agree, but I'm not really big on trying to pressure people to do things. But if someone in the Massachusetts area could offer to help I can put you in touch. From marc.donner at gmail.com Thu Jan 26 23:25:43 2023 From: marc.donner at gmail.com (Marc Donner) Date: Thu, 26 Jan 2023 08:25:43 -0500 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: <23432965-52D6-4331-A4D8-8A6FDDB3F751@serissa.com> References: <23432965-52D6-4331-A4D8-8A6FDDB3F751@serissa.com> Message-ID: PERQ There was some talk of making Unix run on it, but POS (PERQ-OS) was written in Pascal and there was no reasonable way to port over all of the existing stuff without rewriting it all. I had a PERQ in my office for a while … it put out so much heat and noise that my officemates lobbied to have me evicted. On Wed, Jan 25, 2023 at 8:01 PM Larry Stewart wrote: > There was quite a lot of early activity of course! > Essentially all of computer science academia was aware of the Xerox Alto, > although it wasn't a commercial product and wasn't Unix. > > Jim Morris left PARC and went off to CMU and began talking up the idea of > the "3M" workstation. One MIPs, One Megabyte of RAM, and One Million > Pixels. > > One of the early commercial attempts was the Three Rivers PERC (or PERQ?) > from the Pittsburgh startup. There were Unix adjacent systems as well, > such as Apollo Domain. > > Of course then Sun got started, and MIPS, and the IBM RT and VaxStations > so by the mid '80s it was quite crowded. > > There is a whole other arc about the graphics workstations, with SGI, > Ardent, Stellar, Stardent, and so on. > > Also, before graphics became affordable, there were various clustered > character generator based systems like Convergent Technologies. > > -L > > On Jan 25, 2023, at 7:31 PM, Joseph Holsten > wrote: > > It seems like there are bountiful articles able the decline and fall of > the UNIX workstation, but I’ve had a hard time finding narrative about > workstations prior to the Stanford SUN workstation. > > > * was the SUN-1 the first commercially successful product? What are the > “it depends” edge cases? > * were there common recipes for proto-workstations within academic or > industrial research? What did those look like, who was involved? > * What do I really mean by workstation? Ex.gr. If an installation had a > PDP-11 with a single terminal and operator, is it not a workstation? Is it > the integration of display into the system that differentiates? > > -- > Joseph Holsten > http://josephholsten.com > mailto:joseph at josephholsten.com > tel:+1-360-927-7234 <(360)%20927-7234> > > -- ===== nygeek.net mindthegapdialogs.com/home -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Thu Jan 26 23:58:02 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 26 Jan 2023 06:58:02 -0700 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: References: <23432965-52D6-4331-A4D8-8A6FDDB3F751@serissa.com> Message-ID: <202301261358.30QDw29t019680@freefriends.org> We had some at Georgia Tech when I was in grad school. The Accent OS for it from CMU (I think) had a lot of ideas and techniques that showed up later in Mach. I once referred to Mach as "Accent running on a vax". IIRC they had portrait shaped fairly large monochrome bitmapped displays. But I may be misremembering. At the time I felt like anything that wasn't Unix / written in C wasn't worth messing with. Arnold Marc Donner wrote: > PERQ > > There was some talk of making Unix run on it, but POS (PERQ-OS) was written > in Pascal and there was no reasonable way to port over all of the existing > stuff without rewriting it all. I had a PERQ in my office for a while … it > put out so much heat and noise that my officemates lobbied to have me > evicted. > > On Wed, Jan 25, 2023 at 8:01 PM Larry Stewart wrote: > > > There was quite a lot of early activity of course! > > Essentially all of computer science academia was aware of the Xerox Alto, > > although it wasn't a commercial product and wasn't Unix. > > > > Jim Morris left PARC and went off to CMU and began talking up the idea of > > the "3M" workstation. One MIPs, One Megabyte of RAM, and One Million > > Pixels. > > > > One of the early commercial attempts was the Three Rivers PERC (or PERQ?) > > from the Pittsburgh startup. There were Unix adjacent systems as well, > > such as Apollo Domain. > > > > Of course then Sun got started, and MIPS, and the IBM RT and VaxStations > > so by the mid '80s it was quite crowded. > > > > There is a whole other arc about the graphics workstations, with SGI, > > Ardent, Stellar, Stardent, and so on. > > > > Also, before graphics became affordable, there were various clustered > > character generator based systems like Convergent Technologies. > > > > -L > > > > On Jan 25, 2023, at 7:31 PM, Joseph Holsten > > wrote: > > > > It seems like there are bountiful articles able the decline and fall of > > the UNIX workstation, but I’ve had a hard time finding narrative about > > workstations prior to the Stanford SUN workstation. > > > > > > * was the SUN-1 the first commercially successful product? What are the > > “it depends” edge cases? > > * were there common recipes for proto-workstations within academic or > > industrial research? What did those look like, who was involved? > > * What do I really mean by workstation? Ex.gr. If an installation had a > > PDP-11 with a single terminal and operator, is it not a workstation? Is it > > the integration of display into the system that differentiates? > > > > -- > > Joseph Holsten > > http://josephholsten.com > > mailto:joseph at josephholsten.com > > tel:+1-360-927-7234 <(360)%20927-7234> > > > > -- > ===== > nygeek.net > mindthegapdialogs.com/home From clemc at ccc.com Fri Jan 27 01:14:47 2023 From: clemc at ccc.com (Clem Cole) Date: Thu, 26 Jan 2023 10:14:47 -0500 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: References: Message-ID: Check out: Magnolia - The Tektronix Unix Personal Computer September 1980 This redates - Sun or Apollo, but not the Perq - a.k.a. the 'Pascalto' Magonila was done in Tek Labs and it eventually birthed Tek Workstation Division which was a complete failure, although did Tek eventually commercialized the Magnolia as the Tek 4404 -- a Smalltalk system (which you can so a web search). One of the Busines Schools (HBS I think) wrote a study about it called 'Why Skunks Don't Work." ᐧ On Wed, Jan 25, 2023 at 7:32 PM Joseph Holsten wrote: > It seems like there are bountiful articles able the decline and fall of > the UNIX workstation, but I’ve had a hard time finding narrative about > workstations prior to the Stanford SUN workstation. > > * was the SUN-1 the first commercially successful product? What are the > “it depends” edge cases? > * were there common recipes for proto-workstations within academic or > industrial research? What did those look like, who was involved? > * What do I really mean by workstation? Ex.gr. If an installation had a > PDP-11 with a single terminal and operator, is it not a workstation? Is it > the integration of display into the system that differentiates? > > -- > Joseph Holsten > http://josephholsten.com > mailto:joseph at josephholsten.com > tel:+1-360-927-7234 <(360)%20927-7234> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joshnatis0 at gmail.com Fri Jan 27 01:28:19 2023 From: joshnatis0 at gmail.com (josh) Date: Thu, 26 Jan 2023 10:28:19 -0500 Subject: [TUHS] Setting up an X Development Environment for Mac OS In-Reply-To: <20230126105626.72CD922168@orac.inputplus.co.uk> References: <20230125203805.4762218C083@mercury.lcs.mit.edu> <7w8rhpdczd.fsf@junk.nocrew.org> <20230126105626.72CD922168@orac.inputplus.co.uk> Message-ID: On Thursday, January 26, 2023, Ralph Corderoy wrote: > > Rob Pike wrote of magnetic tapes he had which could no longer be read. > The coating had failed off IIRC. I tried to find the text but failed. > Perhaps it was on one of those Google+, Posterous, ... transient things. > Hi Ralph, I think you’re referring to this blog post (which I’ve also previously struggled to find): https://commandcenter.blogspot.com/2014/08/prints.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Fri Jan 27 01:58:11 2023 From: pnr at planet.nl (Paul Ruizendaal) Date: Thu, 26 Jan 2023 16:58:11 +0100 Subject: [TUHS] Earliest UNIX Workstations? Message-ID: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl> As a result of the recent discussion on this list I’m trying to understand the timeline of graphical computing on Unix, first of all in my preferred time slot ’75 -’85. When it comes to Bell Labs I’m aware of the following: - around 1975 the Labs worked on the Glance-G vector graphics terminal. This was TSS-516 based with no Unix overlap I think. - around the same time the Labs seem to have used the 1973 Dec VT11 vector graphics terminal; at least the surviving LSX Unix source has a driver for it - in 1976 there was the Terak 8510; this ran primarily USCD pascal, but it also ran LSX and/or MX (but maybe only much later) - then it seems to jump 1981 and to the Blit. - in 1984 there was MGR that was done at Bellcore Outside of the labs (but on Unix), I have: - I am not sure what graphics software ran on the SUN-1, but it must have been something - Clem just mentioned the 1981 Tektronix Magnolia system - Wikipedia says that X1 was 1984 and X11 was 1987; I’m not sure when it became Unix centered - Sun’s NeWS arrived only in 1989, I think? Outside of Unix, in the microcomputer world there was a lot of cheap(er) graphics hardware. Lot’s of stuff at 256 x 192 resolution, but up to 512 x 512 at the higher end. John Walker writes that the breakout product for Autodesk was Interact (the precursor to AutoCAD). Initially developed for S-100 bus systems it quickly moved to the PC. There was a lot of demand for CAD at a 5K price point that did not exist at a 50K price point. From lm at mcvoy.com Fri Jan 27 02:04:20 2023 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 26 Jan 2023 08:04:20 -0800 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl> References: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl> Message-ID: <20230126160420.GL9901@mcvoy.com> On Thu, Jan 26, 2023 at 04:58:11PM +0100, Paul Ruizendaal wrote: > - I am not sure what graphics software ran on the SUN-1, but it must have been something Probably SunView, that's the first one I saw. It was SunView OpenLook (SunView ported to X11) CDE NeWS I used either straight X11 or OpenLook but replacing the window manager with twm and then ctwm. Did the same thing at SGI, I hated all the fancy desktops each vendor did. In the days of 4MB or 8MB or even 32MB desktops, all that "fancy" used memory that I needed for actual real work, like building the kernel. Straight X11 with a simple window manager gave me a lot of memory back. I viewed that fancy stuff as stuff for people who didn't do real work. A bit of a snob, I was :-) From tuhs at tuhs.org Fri Jan 27 02:07:31 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 26 Jan 2023 16:07:31 +0000 Subject: [TUHS] Setting up an X Development Environment for Mac OS In-Reply-To: References: <20230125203805.4762218C083@mercury.lcs.mit.edu> <7w8rhpdczd.fsf@junk.nocrew.org> <20230126105626.72CD922168@orac.inputplus.co.uk> Message-ID: Excellent post, thanks for the share! I think about that loss of information often. Its a shame preservation hasn't been more of a theme, there are probably countless iconic video games for which the original source code doesn't exist anymore. If "digital archivist" was more in-demand in tech companies I'd love to engage with that sort of work professionally...maybe someday. - Matt G. ------- Original Message ------- On Thursday, January 26th, 2023 at 7:28 AM, josh wrote: > On Thursday, January 26, 2023, Ralph Corderoy wrote: > >> Rob Pike wrote of magnetic tapes he had which could no longer be read. >> The coating had failed off IIRC. I tried to find the text but failed. >> Perhaps it was on one of those Google+, Posterous, ... transient things. > > Hi Ralph, I think you’re referring to this blog post (which I’ve also previously struggled to find): https://commandcenter.blogspot.com/2014/08/prints.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Fri Jan 27 02:29:12 2023 From: clemc at ccc.com (Clem Cole) Date: Thu, 26 Jan 2023 11:29:12 -0500 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl> References: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl> Message-ID: On Thu, Jan 26, 2023 at 10:58 AM Paul Ruizendaal wrote: > > As a result of the recent discussion on this list I’m trying to understand > the timeline of graphical computing on Unix, first of all in my preferred > time slot ’75 -’85. > > When it comes to Bell Labs I’m aware of the following: > > - around 1975 the Labs worked on the Glance-G vector graphics terminal. > This was TSS-516 based with no Unix overlap I think. > - around the same time the Labs seem to have used the 1973 Dec VT11 vector > graphics terminal; at least the surviving LSX Unix source has a driver for > it > - in 1976 there was the Terak 8510; this ran primarily USCD pascal, but it > also ran LSX and/or MX (but maybe only much later) > In the famous picture of Ken and Dennis you see a Tek display connected to the 11/20. Simply during that time there were a number of graphics systems from the DVST (storage tubes) like Tek 4014 to Raster Systems like the GDPs we had at CMU. There really are too many to list. > - then it seems to jump 1981 and to the Blit. > - in 1984 there was MGR that was done at Bellcore > > Outside of the labs (but on Unix), I have: > > - I am not sure what graphics software ran on the SUN-1, but it must have > been something > Again - W was the windowing system for the Sun board, running on the V kernel. It was original envisioned as a very smart terminal to bigger systems. Remember it did not have an MMU to start with. Andy added and MMU and then eventually changed it to a 68010. VLSI Tech was born and eventual became Sun Micro Systems but that was a few years later. I have to believe W as moved to UNIX on the SUN Terminal and that would have been what Chris Kent and folks started with for the microVax - but I do not know for sure. > - Clem just mentioned the 1981 Tektronix Magnolia system > 1979/1980 actually -- Roger and I started that in summer of '79 and he wrote that a year later when we go Tek money. It was originall as 'g-job' we were building for ourselves. Our boss saw what were were doing and Roger got $10K to do a proposal -- that document was the result. I already had the basics of a compiler working by them (well sort of) and the beginning of a Unix port on the test board. Jon Steinhart may be remember some of this as they all visited us in the labs to see what we were doing. - Wikipedia says that X1 was 1984 and X11 was 1987; I’m not sure when it > became Unix centered > - Sun’s NeWS arrived only in 1989, I think? > > Outside of Unix, in the microcomputer world there was a lot of cheap(er) > graphics hardware. Lot’s of stuff at 256 x 192 resolution, but up to 512 x > 512 at the higher end. John Walker writes that the breakout product for > Autodesk was Interact (the precursor to AutoCAD). Initially developed for > S-100 bus systems it quickly moved to the PC. There was a lot of demand for > CAD at a 5K price point that did not exist at a 50K price point. > Not completely true... 1-4K for BW was possible (expensive) but available. I tend to believe that systems like E&S could do that. Many raster systems went to 1K -- again is was about cost. I've forgotten the resolution of the GDP2 but is was much higher -- it used a rather expensive HP display. The price of memory and price of the monitor tneded to dominate. Also the processor was not cheap -- a GDP2 had a dedicated PDP-11/20, but that was also try of things like GT40 and the similar systems of the time. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Fri Jan 27 02:35:30 2023 From: tuhs at tuhs.org (John Foust via TUHS) Date: Thu, 26 Jan 2023 10:35:30 -0600 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: References: Message-ID: <167475095589.2485728.1463406237636642205@minnie.tuhs.org> At 01:20 AM 1/26/2023, John Cowan wrote: >WP says the Terak 8510/a was the first graphical workstation; it came out in 1976-77 and ran the UCSD p-System. I had never heard of it before. I have a dozen or so Teraks (a PDP-11/03 based system) as well as many floppies and other inherited items and notebooks from one of the Terak founders. This may seem like a lot but there's another guy who might still have a larger collection. Mini-Unix is described here: http://www.tavi.co.uk/unixhistory/mini-unix.html Sixth edition, no MMU. The Bell memo there is dated January 1977. There was a Mini-Unix for the Terak described here in May 1979 but I don't think I have a copy. See page 14... https://conservancy.umn.edu/bitstream/handle/11299/159028/UCC_Special%20_Issue_May_1979.pdf?sequence=1&isAllowed=y Terak floppies are described here: http://www.60bits.net/msu/mycomp/terak/termedia.htm A memo there says they got their copy in April 1980. There's no indication that this Mini-Unix can *use* the Terak's mono bitmapped display, short of writing your own routines. Pinning "first" on computers is always a tricky process. - John From emu at e-bbes.com Fri Jan 27 02:37:18 2023 From: emu at e-bbes.com (emanuel stiebler) Date: Thu, 26 Jan 2023 11:37:18 -0500 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: <20230126160420.GL9901@mcvoy.com> References: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl> <20230126160420.GL9901@mcvoy.com> Message-ID: <933e6be8-7d19-4e4c-950d-832b84a5f186@e-bbes.com> On 2023-01-26 11:04, Larry McVoy wrote: > [..] Straight X11 with a simple window > manager gave me a lot of memory back. > > I viewed that fancy stuff as stuff for people who didn't do real work. > A bit of a snob, I was :-) Xclock & many xterms, that what was on my desktop. Just replacing all the terminals, and to have one xterm with more lines for editing. From emu at e-bbes.com Fri Jan 27 02:48:29 2023 From: emu at e-bbes.com (emanuel stiebler) Date: Thu, 26 Jan 2023 11:48:29 -0500 Subject: [TUHS] Setting up an X Development Environment for Mac OS In-Reply-To: References: <20230125203805.4762218C083@mercury.lcs.mit.edu> <7w8rhpdczd.fsf@junk.nocrew.org> <20230126105626.72CD922168@orac.inputplus.co.uk> Message-ID: <85d0ee98-3686-b305-49d7-536589b5d3db@e-bbes.com> On 2023-01-26 11:07, segaloco via TUHS wrote: > Excellent post, thanks for the share! I think about that loss of > information often.  Its a shame preservation hasn't been more of a > theme, there are probably countless iconic video games for which the > original source code doesn't exist anymore.  If "digital archivist" was > more in-demand in tech companies I'd love to engage with that sort of > work professionally...maybe someday. But isn't it, what this group is all about? Collecting all the (Unix) pieces we can find, and talk about the past. And copying the archives to newer disks, newer mail systems so it will hopefully survive ... From tuhs at tuhs.org Fri Jan 27 02:51:13 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 26 Jan 2023 16:51:13 +0000 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: <933e6be8-7d19-4e4c-950d-832b84a5f186@e-bbes.com> References: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl> <20230126160420.GL9901@mcvoy.com> <933e6be8-7d19-4e4c-950d-832b84a5f186@e-bbes.com> Message-ID: Twm gets the job done for me too. My only gripe is it doesn't support WM full screen hints that a lot of other WMs do so certain things don't full-screen properly, but others do. In either case, not a huge problem, something if it mattered enough to me I'd just try to patch in. - Matt G. ------- Original Message ------- On Thursday, January 26th, 2023 at 8:37 AM, emanuel stiebler wrote: > On 2023-01-26 11:04, Larry McVoy wrote: > > > [..] Straight X11 with a simple window > > manager gave me a lot of memory back. > > > > I viewed that fancy stuff as stuff for people who didn't do real work. > > A bit of a snob, I was :-) > > > Xclock & many xterms, that what was on my desktop. Just replacing all > the terminals, and to have one xterm with more lines for editing. From imp at bsdimp.com Fri Jan 27 02:51:59 2023 From: imp at bsdimp.com (Warner Losh) Date: Thu, 26 Jan 2023 09:51:59 -0700 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl> References: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl> Message-ID: On Thu, Jan 26, 2023 at 8:58 AM Paul Ruizendaal wrote: > > As a result of the recent discussion on this list I’m trying to understand > the timeline of graphical computing on Unix, first of all in my preferred > time slot ’75 -’85. > > When it comes to Bell Labs I’m aware of the following: > > - around 1975 the Labs worked on the Glance-G vector graphics terminal. > This was TSS-516 based with no Unix overlap I think. > - around the same time the Labs seem to have used the 1973 Dec VT11 vector > graphics terminal; at least the surviving LSX Unix source has a driver for > it > - in 1976 there was the Terak 8510; this ran primarily USCD pascal, but it > also ran LSX and/or MX (but maybe only much later) > - then it seems to jump 1981 and to the Blit. > - in 1984 there was MGR that was done at Bellcore > > Outside of the labs (but on Unix), I have: > > - I am not sure what graphics software ran on the SUN-1, but it must have > been something > If this is the sun microsystem sun-1, the leaked sources online suggest that these initially ran a V7 port by Unisoft. This switched to a 4.2BSD port maybe before it went to customers as SunOS 1.0 if other leaked sources can be believed. If this is the Standford Unix Networked (?) sun, then I don't know. > - Clem just mentioned the 1981 Tektronix Magnolia system > - Wikipedia says that X1 was 1984 and X11 was 1987; I’m not sure when it > became Unix centered > I believe very early. It ran first on the VS100, and I believe that those machines at project athena were running Unix, but I'm not sure of the cut over from Stanford V. Another thread posted the X announcement which was in June 1984. There was also a pointer to a blog about pictures of the W window system. None exist, it seems. The windowing system pictured in the glossy marketing sheets for the VS100 were for VMS and VMS Windowing System. I'd put money against the first X running on VMS. :) We had X10R3 running on Sun 3/50s in our lab, though more often they ran SunView since it was faster and more familiar to the admins that ran the machines. This was in 86 or 87 I believe. > - Sun’s NeWS arrived only in 1989, I think? > No. It had to be late 1987 or 1988 because I ran that on the Sun 3/60 that the Hydrology department that I worked for ran. I didn't run it often, mind you, and the 'generic terminal emulator for any termcap entry' terminal was cool, but it was just a notch too weird for a daily driver. Warner > Outside of Unix, in the microcomputer world there was a lot of cheap(er) > graphics hardware. Lot’s of stuff at 256 x 192 resolution, but up to 512 x > 512 at the higher end. John Walker writes that the breakout product for > Autodesk was Interact (the precursor to AutoCAD). Initially developed for > S-100 bus systems it quickly moved to the PC. There was a lot of demand for > CAD at a 5K price point that did not exist at a 50K price point. > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nobozo at gmail.com Fri Jan 27 03:58:51 2023 From: nobozo at gmail.com (Jon Forrest) Date: Thu, 26 Jan 2023 09:58:51 -0800 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: References: Message-ID: <1bedbeeb-4bf3-4555-bec9-d0f010e4c0c0@gmail.com> On 1/25/2023 11:20 PM, John Cowan wrote: > WP says the Terak 8510/a was the first graphical workstation; it came > out in 1976-77 and ran the UCSD p-System. It also ran standard RT-11. UC Santa Barbara had a room full of them that I used to (badly) teach PDP-11 assembler in the early 1980s. Each student had their own 8" floppy disk which held the OS and enough utilities to edit and debug programs. Jon From jon at fourwinds.com Fri Jan 27 04:04:53 2023 From: jon at fourwinds.com (Jon Steinhart) Date: Thu, 26 Jan 2023 10:04:53 -0800 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: References: Message-ID: <202301261804.30QI4sd9132510@darkstar.fourwinds.com> John Cowan writes: > On Wed, Jan 25, 2023 at 8:47 PM Chris Hanson > wrote: > > > > > * What do I really mean by workstation? Ex.gr. If an installation had a > > PDP-11 with a single terminal and operator, is it not a workstation? Is it > > the integration of display into the system that differentiates? > > > > I think "a graphical system intended to be used by a professional to use > > in their work" is a good starting point for a definition. I should check at > > home tonight how "A History of Personal Workstations" defines it. > > > > WP says the Terak 8510/a was the first graphical workstation; it came out > in 1976-77 and ran the UCSD p-System. I had never heard of it before. The > first *personal* workstation (non-graphical) was probably the IBM 1620 (aka > the CADET system, "Can't Add, Doesn't Even Try") from 1959. I think that WP is not correct here, the Tektronix 4051 beat it to market by a year. From jon at fourwinds.com Fri Jan 27 04:14:22 2023 From: jon at fourwinds.com (Jon Steinhart) Date: Thu, 26 Jan 2023 10:14:22 -0800 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl> References: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl> Message-ID: <202301261814.30QIEMwv133146@darkstar.fourwinds.com> Paul Ruizendaal writes: > As a result of the recent discussion on this list I’m trying to understand the timeline of graphical computing on Unix, first of all in my preferred time slot ’75 -’85. > > When it comes to Bell Labs I’m aware of the following: > > - around 1975 the Labs worked on the Glance-G vector graphics terminal. This was TSS-516 based with no Unix overlap I think. > - around the same time the Labs seem to have used the 1973 Dec VT11 vector graphics terminal; at least the surviving LSX Unix source has a driver for it > - in 1976 there was the Terak 8510; this ran primarily USCD pascal, but it also ran LSX and/or MX (but maybe only much later) > - then it seems to jump 1981 and to the Blit. > - in 1984 there was MGR that was done at Bellcore > > Outside of the labs (but on Unix), I have: > > - I am not sure what graphics software ran on the SUN-1, but it must have been something > - Clem just mentioned the 1981 Tektronix Magnolia system > - Wikipedia says that X1 was 1984 and X11 was 1987; I’m not sure when it became Unix centered > - Sun’s NeWS arrived only in 1989, I think? > > Outside of Unix, in the microcomputer world there was a lot of cheap(er) graphics hardware. Lot’s of stuff at 256 x 192 resolution, but up to 512 x 512 at the higher end. John Walker writes that the breakout product for Autodesk was Interact (the precursor to AutoCAD). Initially developed for S-100 bus systems it quickly moved to the PC. There was a lot of demand for CAD at a 5K price point that did not exist at a 50K price point. The timeline for the GLANCE-G is off by a few years. It might have been as early as 1969 but I don't remember when the transition from GLANCE-C (characters only) to GLANCE-G (graphics) occurred. I'm absolutely sure that the G existed in 1972 since I worked on it then. The only UNIX overlap was when the Ring was adapted for the PDP-11 so that Ken could have a GLANCE-G for chess. I have a vague memory of other graphics work at the labs; I remember being in someone's lab that had modified big Crown audio power amps for current feedback to drive deflection coils, but no other details. From lars at nocrew.org Fri Jan 27 04:15:32 2023 From: lars at nocrew.org (Lars Brinkhoff) Date: Thu, 26 Jan 2023 18:15:32 +0000 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: (Warner Losh's message of "Thu, 26 Jan 2023 09:51:59 -0700") References: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl> Message-ID: <7wo7qlb1rv.fsf@junk.nocrew.org> Warner Losh wrote: > If this is the Standford Unix Networked (?) sun, then I don't know. Stanford University Network workstation. I have seen some documents about it on stacks.stanford.edu, but I don't remember about the software. In some versions, it's a more of a multi-head remote graphics terminal, so maybe not Unix. > - Wikipedia says that X1 was 1984 and X11 was 1987; I’m not sure when it > became Unix centered > > I believe very early. It ran first on the VS100 Note that the VAXstation 100 is not a VAX, and not a standalone computer. It's a 68000-based graphics terminal that attaches to a VAX. The VS100 has some firmware in ROM, and the host uploads additional software. There is such a software blob in X10R3. > There was also a pointer to a blog about pictures of the W window > system. None exist, it seems. I have asked Asante, Reid, and Kent. No luck so far. From bakul at iitbombay.org Fri Jan 27 05:39:30 2023 From: bakul at iitbombay.org (Bakul Shah) Date: Thu, 26 Jan 2023 11:39:30 -0800 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: <7wo7qlb1rv.fsf@junk.nocrew.org> References: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl> <7wo7qlb1rv.fsf@junk.nocrew.org> Message-ID: <347AA7EF-C028-4C27-806D-B8549BEECD38@iitbombay.org> The V sources on bitsavers has a w command. But don't get excited! It seems to be similar to unix's w, a variation on the who command. I wonder if this mythical w is the same as V's VGTS as it seems to have pretty much the same model. From https://dl.acm.org/doi/pdf/10.1145/357332.357334 The ideal interface must take into account four fundamental principles: (1) The interface to application programs should be independent of particular physical devices or intervening networks. (2) The user should be allowed to perform multiple tasks simultaneously. (3) The command interaction discipline should be consistent and natural. (4) Response to user interaction should be fast. The first principle has led to work in virtual terminals (VTs) and deviceindependent graphics packages, the second to work in window systems, and the third to work in what has recently been called user interface management systems, the most common examples of which are command languages. Without adhering to the fourth principle, however, much of the other work is moot. In a distributed environment, in particular, the supporting network protocols cannot incur inordinate overhead. From concluding remarks: To summarize the major attributes of the VGTS: - Instead of describing how to draw a picture, the application describes what is to be drawn. The user then specifies where the picture should be displayed. - Objects have a hierarchical structure. Hence, the VGTS supports structured display files rather than segmented display files. - The VGTS is portable to a range of relatively high-performance devices. - Applications can be distributed over multiple machines. - A single user can access several different applications simultaneously. - It performs well! VGTS code is in the V system sources at bitsavers. > On Jan 26, 2023, at 10:15 AM, Lars Brinkhoff wrote: > > Warner Losh wrote: >> If this is the Standford Unix Networked (?) sun, then I don't know. > > Stanford University Network workstation. I have seen some documents > about it on stacks.stanford.edu, but I don't remember about the > software. In some versions, it's a more of a multi-head remote graphics > terminal, so maybe not Unix. > >> - Wikipedia says that X1 was 1984 and X11 was 1987; I’m not sure when it >> became Unix centered >> >> I believe very early. It ran first on the VS100 > > Note that the VAXstation 100 is not a VAX, and not a standalone > computer. It's a 68000-based graphics terminal that attaches to a VAX. > The VS100 has some firmware in ROM, and the host uploads additional > software. There is such a software blob in X10R3. > >> There was also a pointer to a blog about pictures of the W window >> system. None exist, it seems. > > I have asked Asante, Reid, and Kent. No luck so far. From robpike at gmail.com Fri Jan 27 06:44:20 2023 From: robpike at gmail.com (Rob Pike) Date: Fri, 27 Jan 2023 07:44:20 +1100 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl> References: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl> Message-ID: There was also all the work with the Three Rivers Graphic Wonder on the PDP-11/45 at the University of Toronto Dynamic Graphics Project from 1974 onwards, as well as various film plotters, Versatec, Tennenhouse's frame buffer, and so on. -rob On Fri, Jan 27, 2023 at 2:58 AM Paul Ruizendaal wrote: > > As a result of the recent discussion on this list I’m trying to understand > the timeline of graphical computing on Unix, first of all in my preferred > time slot ’75 -’85. > > When it comes to Bell Labs I’m aware of the following: > > - around 1975 the Labs worked on the Glance-G vector graphics terminal. > This was TSS-516 based with no Unix overlap I think. > - around the same time the Labs seem to have used the 1973 Dec VT11 vector > graphics terminal; at least the surviving LSX Unix source has a driver for > it > - in 1976 there was the Terak 8510; this ran primarily USCD pascal, but it > also ran LSX and/or MX (but maybe only much later) > - then it seems to jump 1981 and to the Blit. > - in 1984 there was MGR that was done at Bellcore > > Outside of the labs (but on Unix), I have: > > - I am not sure what graphics software ran on the SUN-1, but it must have > been something > - Clem just mentioned the 1981 Tektronix Magnolia system > - Wikipedia says that X1 was 1984 and X11 was 1987; I’m not sure when it > became Unix centered > - Sun’s NeWS arrived only in 1989, I think? > > Outside of Unix, in the microcomputer world there was a lot of cheap(er) > graphics hardware. Lot’s of stuff at 256 x 192 resolution, but up to 512 x > 512 at the higher end. John Walker writes that the breakout product for > Autodesk was Interact (the precursor to AutoCAD). Initially developed for > S-100 bus systems it quickly moved to the PC. There was a lot of demand for > CAD at a 5K price point that did not exist at a 50K price point. > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Fri Jan 27 07:19:44 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 26 Jan 2023 21:19:44 +0000 Subject: [TUHS] Setting up an X Development Environment for Mac OS In-Reply-To: <85d0ee98-3686-b305-49d7-536589b5d3db@e-bbes.com> References: <20230125203805.4762218C083@mercury.lcs.mit.edu> <7w8rhpdczd.fsf@junk.nocrew.org> <20230126105626.72CD922168@orac.inputplus.co.uk> <85d0ee98-3686-b305-49d7-536589b5d3db@e-bbes.com> Message-ID: We benefit from a general culture of openness surrounding UNIX these days. We see no such openness from Nintendo, Sega, Sony, nor Microsoft in their video game offerings, neither current nor former, and similar for publishers and studios for the most part. Anecdotally, when SquareEnix went to reissue Final Fantasy 8, they had to rewrite it from scratch as the original PS1 source code had been lost. Apparently this is a pretty common problem plaguing efforts to roll older titles forward to modern systems, and is one of the reasons shoddy emulation seems to win out over intentional ports of anything. UNIX experienced the rather unique phenomenon of being able to grow legs in academia for many years before some legal types tried to put the kibosh on that. Super Mario Bros. was a closed code base from day 1 with a tight deadline and little to no reason for it to be shared outside of its own development group. The circumstances are just so wildly different. UNIX is a bit of an anomaly as far as being an iconic, ubiquitous, still appreciated design that succeeds in academic *and* commercial spheres and also has ample source code and documentation history not only available but not constantly being torpedoed by lawyers. I don't know that we'll see a willingness to open up the history of video game development like that in a timeframe that sensitive source codes and documents could still be properly preserved. Plus, to the defense of these studios, some algorithm or technique developed for management of game resources may still be very much relevant to modern engine designs in ways that OS code from the 70s simply wouldn't even have a place in modern design. I wouldn't be surprised if there are scene graph and asset manager algorithms and such down in, say, the Zelda 64 engine, that the big N is *still* using in comparable engines and considers a trade secret. Hard to say. But anywho, just to draw some comparisons to the preservation state of UNIX vs other technological innovations. We have decades of quality OS code to study, research, and expand upon as hackers, but we have no such wealth of real video game source codes to educate the masses on game design, especially embedded console/bare metal approaches. This is where the crossroads lies for me between my UNIX and game development interests, I would LOVE some day for there to be as accessible and quality of resources for those studying the history of game design/development as there are for those studying OS design. After all, the way I describe old games to people in a technical sense is its just a specific type of OS. That programmer had to abstract all that hardware into concepts like button triggers movement of VDP scrollplanes and emission of commands to the FM synth chip. The thing you're using is just a Dpad instead of a mouse and you're moving a silly little character instead of a window across the screen. - Matt G. ------- Original Message ------- On Thursday, January 26th, 2023 at 8:48 AM, emanuel stiebler wrote: > On 2023-01-26 11:07, segaloco via TUHS wrote: > > > Excellent post, thanks for the share! I think about that loss of > > information often. Its a shame preservation hasn't been more of a > > theme, there are probably countless iconic video games for which the > > original source code doesn't exist anymore. If "digital archivist" was > > more in-demand in tech companies I'd love to engage with that sort of > > work professionally...maybe someday. > > > But isn't it, what this group is all about? > Collecting all the (Unix) pieces we can find, and talk about the past. > And copying the archives to newer disks, newer mail systems so it will > hopefully survive ... From joseph at josephholsten.com Fri Jan 27 07:29:26 2023 From: joseph at josephholsten.com (Joseph Holsten) Date: Thu, 26 Jan 2023 13:29:26 -0800 Subject: [TUHS] =?utf-8?q?Collecting_notes_for_future_=E2=80=9Chistorians?= =?utf-8?q?=E2=80=9D_was=3A_Earliest_UNIX_Workstations=3F?= In-Reply-To: <202301261804.30QI4sd9132510@darkstar.fourwinds.com> References: <202301261804.30QI4sd9132510@darkstar.fourwinds.com> Message-ID: I love how I can fire off a query and get so much info. But I wonder: does TUHS have any way of consolidating these threads into easily digestible documents? What would be preferred, a wiki? or a source control repo with “articles”? I’m mostly wanting summarize this kind of thread and include links to mailing list messages and other resources. But also, I’m lazy and I am not committing to editing a journal. On Thu, Jan 26, 2023, at 10:04, Jon Steinhart wrote: > John Cowan writes: >> On Wed, Jan 25, 2023 at 8:47 PM Chris Hanson >> wrote: >> >> >> > > * What do I really mean by workstation? Ex.gr. If an installation had a >> > PDP-11 with a single terminal and operator, is it not a workstation? Is it >> > the integration of display into the system that differentiates? >> > >> > I think "a graphical system intended to be used by a professional to use >> > in their work" is a good starting point for a definition. I should check at >> > home tonight how "A History of Personal Workstations" defines it. >> > >> >> WP says the Terak 8510/a was the first graphical workstation; it came out >> in 1976-77 and ran the UCSD p-System. I had never heard of it before. The >> first *personal* workstation (non-graphical) was probably the IBM 1620 (aka >> the CADET system, "Can't Add, Doesn't Even Try") from 1959. > > I think that WP is not correct here, the Tektronix 4051 beat it to market > by a year. From jon at fourwinds.com Fri Jan 27 07:38:05 2023 From: jon at fourwinds.com (Jon Steinhart) Date: Thu, 26 Jan 2023 13:38:05 -0800 Subject: [TUHS] =?utf-8?q?Collecting_notes_for_future_=E2=80=9Chistorians?= =?utf-8?q?=E2=80=9D_was=3A_Earliest_UNIX_Workstations=3F?= In-Reply-To: References: <202301261804.30QI4sd9132510@darkstar.fourwinds.com> Message-ID: <202301262138.30QLc6wY143500@darkstar.fourwinds.com> Joseph Holsten writes: > I love how I can fire off a query and get so much info. But I wonder: does > TUHS have any way of consolidating these threads into easily digestible > documents? What would be preferred, a wiki? or a source control repo with > “articles”? > > I’m mostly wanting summarize this kind of thread and include links to > mailing list messages and other resources. But also, I’m lazy and I am > not committing to editing a journal. Seems like you already know the answer and just don't like it. The only way to get coheret articles is to write the. Wikis suck for this sort of thing. An appropriate way for us to do this sort of thing would be to create a repository where we can contribute to documents written in troff. Jon From pnr at planet.nl Fri Jan 27 08:17:02 2023 From: pnr at planet.nl (Paul Ruizendaal) Date: Thu, 26 Jan 2023 23:17:02 +0100 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: References: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl> Message-ID: <0778FF74-7DF5-4072-95F3-5FF5BEB4CC33@planet.nl> > On 26 Jan 2023, at 17:29, Clem Cole wrote: > >> Outside of Unix, in the microcomputer world there was a lot of cheap(er) graphics hardware. Lot’s of stuff at 256 x 192 resolution, but up to 512 x 512 at the higher end. John Walker writes that the breakout product for Autodesk was Interact (the precursor to AutoCAD). Initially developed for S-100 bus systems it quickly moved to the PC. There was a lot of demand for CAD at a 5K price point that did not exist at a 50K price point. > Not completely true... 1-4K for BW was possible (expensive) but available. I tend to believe that systems like E&S could do that. Many raster systems went to 1K -- again is was about cost. I've forgotten the resolution of the GDP2 but is was much higher -- it used a rather expensive HP display. The price of memory and price of the monitor tneded to dominate. Also the processor was not cheap -- a GDP2 had a dedicated PDP-11/20, but that was also try of things like GT40 and the similar systems of the time. I meant early micro/home computers. I think John Walker was comparing the typical late 70’s CAD (drawing) system, i.e a mini computer, a few graphics terminals and CAD software versus Interact running on a S-100 system with a high end graphics card, a digitiser board and a terminal. See for instance here: https://www.3dcadworld.com/autocads-ancestor/ > - I am not sure what graphics software ran on the SUN-1, but it must have been something > Again - W was the windowing system for the Sun board, running on the V kernel. It was original envisioned as a very smart terminal to bigger systems. Remember it did not have an MMU to start with. Andy added and MMU and then eventually changed it to a 68010. VLSI Tech was born and eventual became Sun Micro Systems but that was a few years later. I have to believe W as moved to UNIX on the SUN Terminal and that would have been what Chris Kent and folks started with for the microVax - but I do not know for sure. > Date: Thu, 26 Jan 2023 09:51:59 -0700 > From: Warner Losh > >> - I am not sure what graphics software ran on the SUN-1, but it must have been something > > If this is the sun microsystem sun-1, the leaked sources online suggest that these initially ran a V7 port by Unisoft. This switched to a 4.2BSD port maybe before it went to customers as SunOS 1.0 if other leaked sources can be believed. I never really distinguished between the Stanford "SUN" and the Sun Microsystems "Sun-1”, oops. Taking Clem’s comment into account I could see that the SUN ran the V kernel and the W graphics system, and that the Sun-1 was using an early form of X. > Bakul Shah bakul at iitbombay.org > Fri Jan 27 05:39:30 AEST 2023 > > I wonder if this mythical w is the same as V's VGTS as it seems to have > pretty much the same model. > From https://dl.acm.org/doi/pdf/10.1145/357332.357334 That is an interesting thought and paper. The paper says: "As noted in Section 3, the VGTS is only one component of the user interface software. The other components are the view manager, the exec server, and the executives. Together, the view manager and exec server constitute the user interface management.” In this context an “executive” seems to be similar to a shell, the exec server appears to manage client connections and the view manager seems to be similar to a window manager in X. Maybe this whole was (later?) referred to as “W”? This was the post announcing X: From: rws at mit-bold (Robert W. Scheifler) To: window at athena Subject: window system X Date: 19 Jun 1984 0907-EDT (Tuesday) I've spent the last couple weeks writing a window system for the VS100. I stole a fair amount of code from W, surrounded it with an asynchronous rather than a synchronous interface, and called it X. Overall performance appears to be about twice that of W. The code seems fairly solid at this point, although there are still some deficiencies to be fixed up. We at LCS have stopped using W, and are now actively building applications on X. Anyone else using W should seriously consider switching. This is not the ultimate window system, but I believe it is a good starting point for experimentation. Right at the moment there is a CLU (and an Argus) interface to X; a C interface is in the works. The three existing applications are a text editor (TED), an Argus I/O interface, and a primitive window manager. There is no documentation yet; anyone crazy enough to volunteer? I may get around to it eventually. Anyone interested in seeing a demo can drop by NE43-531, although you may want to call 3-1945 first. Anyone who wants the code can come by with a tape. Anyone interested in hacking deficiencies, feel free to get in touch. From joseph at josephholsten.com Fri Jan 27 08:41:50 2023 From: joseph at josephholsten.com (Joseph Holsten) Date: Thu, 26 Jan 2023 14:41:50 -0800 Subject: [TUHS] =?utf-8?q?Collecting_notes_for_future_=E2=80=9Chistorians?= =?utf-8?q?=E2=80=9D_was=3A_Earliest_UNIX_Workstations=3F?= In-Reply-To: <202301262138.30QLc6wY143500@darkstar.fourwinds.com> References: <202301261804.30QI4sd9132510@darkstar.fourwinds.com> <202301262138.30QLc6wY143500@darkstar.fourwinds.com> Message-ID: <620c709c-e8bb-401c-a60d-8869457caacd@app.fastmail.com> On Thu, Jan 26, 2023, at 13:38, Jon Steinhart wrote: > Joseph Holsten writes: >> I love how I can fire off a query and get so much info. But I wonder: does >> TUHS have any way of consolidating these threads into easily digestible >> documents? What would be preferred, a wiki? or a source control repo with >> “articles”? >> >> I’m mostly wanting summarize this kind of thread and include links to >> mailing list messages and other resources. But also, I’m lazy and I am >> not committing to editing a journal. > > Seems like you already know the answer and just don't like it. > The only way to get coheret articles is to write the. Wikis > suck for this sort of thing. > > An appropriate way for us to do this sort of thing would be to create > a repository where we can contribute to documents written in troff. Ah, I meant to ask: is there an existing wiki or repository? Or am I starting one? And if I’m writing in troff, is there a preferred macro set for articles these days? A decade ago I wrote manuals in mdoc but papers in LaTeX; these days I just lean on pandoc to translate. I’ll need to knock my rust off. From bakul at iitbombay.org Fri Jan 27 08:45:06 2023 From: bakul at iitbombay.org (Bakul Shah) Date: Thu, 26 Jan 2023 14:45:06 -0800 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: <0778FF74-7DF5-4072-95F3-5FF5BEB4CC33@planet.nl> References: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl> <0778FF74-7DF5-4072-95F3-5FF5BEB4CC33@planet.nl> Message-ID: On Jan 26, 2023, at 2:17 PM, Paul Ruizendaal wrote: > >> >> Bakul Shah bakul at iitbombay.org >> Fri Jan 27 05:39:30 AEST 2023 >> >> I wonder if this mythical w is the same as V's VGTS as it seems to have >> pretty much the same model. >> From https://dl.acm.org/doi/pdf/10.1145/357332.357334 > > > That is an interesting thought and paper. > > The paper says: > > "As noted in Section 3, the VGTS is only one component of the user interface software. The other components are the view manager, the exec server, and the executives. Together, the view manager and exec server constitute the user interface management.” > > In this context an “executive” seems to be similar to a shell, the exec server appears to manage client connections and the view manager seems to be similar to a window manager in X. Maybe this whole was (later?) referred to as “W”? For the curious the sources are available at http://www.bitsavers.org/bits/Stanford/VSystem_1983.zip It just seems weird that a) for a research OS such as V there were more than one such effort but b) there are no papers about W or any mention of it in V related papers. c) there is source code for VGTS as well as at least one paper about it. d) VGTS seems to have had similar goals as X windows. e) there seemed to be multiple applications written using VGTS. I didn't spend much time searching so may have missed things. I have asked a friend who had Cheriton as research advisor in '80s but most likely it won't yield anything. From akosela at andykosela.com Fri Jan 27 08:51:28 2023 From: akosela at andykosela.com (Andy Kosela) Date: Thu, 26 Jan 2023 23:51:28 +0100 Subject: [TUHS] Setting up an X Development Environment for Mac OS In-Reply-To: References: <20230125203805.4762218C083@mercury.lcs.mit.edu> <7w8rhpdczd.fsf@junk.nocrew.org> <20230126105626.72CD922168@orac.inputplus.co.uk> <85d0ee98-3686-b305-49d7-536589b5d3db@e-bbes.com> Message-ID: On Thursday, January 26, 2023, segaloco via TUHS wrote: > We benefit from a general culture of openness surrounding UNIX these > days. We see no such openness from Nintendo, Sega, Sony, nor Microsoft in > their video game offerings, neither current nor former, and similar for > publishers and studios for the most part. Anecdotally, when SquareEnix > went to reissue Final Fantasy 8, they had to rewrite it from scratch as the > original PS1 source code had been lost. Apparently this is a pretty common > problem plaguing efforts to roll older titles forward to modern systems, > and is one of the reasons shoddy emulation seems to win out over > intentional ports of anything. > > UNIX experienced the rather unique phenomenon of being able to grow legs > in academia for many years before some legal types tried to put the kibosh > on that. Super Mario Bros. was a closed code base from day 1 with a tight > deadline and little to no reason for it to be shared outside of its own > development group. The circumstances are just so wildly different. UNIX > is a bit of an anomaly as far as being an iconic, ubiquitous, still > appreciated design that succeeds in academic *and* commercial spheres and > also has ample source code and documentation history not only available but > not constantly being torpedoed by lawyers. I don't know that we'll see a > willingness to open up the history of video game development like that in a > timeframe that sensitive source codes and documents could still be properly > preserved. > > Plus, to the defense of these studios, some algorithm or technique > developed for management of game resources may still be very much relevant > to modern engine designs in ways that OS code from the 70s simply wouldn't > even have a place in modern design. I wouldn't be surprised if there are > scene graph and asset manager algorithms and such down in, say, the Zelda > 64 engine, that the big N is *still* using in comparable engines and > considers a trade secret. Hard to say. But anywho, just to draw some > comparisons to the preservation state of UNIX vs other technological > innovations. We have decades of quality OS code to study, research, and > expand upon as hackers, but we have no such wealth of real video game > source codes to educate the masses on game design, especially embedded > console/bare metal approaches. This is where the crossroads lies for me > between my UNIX and game development interests, I would LOVE some day for > there to be as accessible and quality of resources for those studying the > history of game design/development as there are for those studying OS > design. After all, the way I describe old games to people in a technical > sense is its just a specific type of OS. That programmer had to abstract > all that hardware into concepts like button triggers movement of VDP > scrollplanes and emission of commands to the FM synth chip. The thing > you're using is just a Dpad instead of a mouse and you're moving a silly > little character instead of a window across the screen. > > The closest I can think of in the game industry to the open source community of Unix/Linux is Doom/Quake. Doom source code was opened in 1997 and Quake in 1999 and since then we have experienced a whole generation of programmers and artists playing with, porting and enhancing the codebase. I don't know of any other game development project that has as much longevity as those two; and all of it happened because John Carmack made the decision to open source it based on the popularity of open source Linux at the time. --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Fri Jan 27 10:19:58 2023 From: pnr at planet.nl (Paul Ruizendaal) Date: Fri, 27 Jan 2023 01:19:58 +0100 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: References: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl> <0778FF74-7DF5-4072-95F3-5FF5BEB4CC33@planet.nl> Message-ID: > On 26 Jan 2023, at 23:45, Bakul Shah wrote: > > On Jan 26, 2023, at 2:17 PM, Paul Ruizendaal wrote: >> >>> >>> Bakul Shah bakul at iitbombay.org >>> Fri Jan 27 05:39:30 AEST 2023 >>> >>> I wonder if this mythical w is the same as V's VGTS as it seems to have >>> pretty much the same model. >>> From https://dl.acm.org/doi/pdf/10.1145/357332.357334 And the answer is “no”: From https://apps.hci.rwth-aachen.de/borchers-old/cs377a/materials/p79-scheifler.pdf : "The name X derives from the lineage of the system. At Stanford University, Paul Asente and Brian Reid had begun work on the W window system [3] as an alternative to VGTS [13, 22] for the V system [5]. Both VGTS and W allow network-transparent access to the display, using the synchronous V communication mechanism. Both systems provide “text” windows for ASCII terminal emulation. VGTS provides graphics windows driven by fairly high-level object definitions from a structured display file; W provides graphics windows based on a simple display-list mechanism, with limited functionality. We acquired a UNIX- based version of W for the VSlOO (with synchronous communication over TCP [24] produced by Asente and Chris Kent at Digital’s Western Research Laboratory. From just a few days of experimentation, it was clear that a network- transparent hierarchical window system was desirable, but that restricting the system to any fixed set of application-specific modes was completely inadequate. It was also clear that, although synchronous communication was perhaps acceptable in the V system (owing to very fast networking primitives), it was completely inadequate in most other operating environments. X is our “reaction” to W.” The reference [3] is "ASENTE, P. W reference manual. Internal document, Dept. Computer Science, Stanford Univ., Calif., 1984.” The version of X discussed in the paper was apparently part of the 4.3BSD distribution tapes: "The use of X has grown far beyond anything we had imagined. Digital has incorporated X into a commercial product, and other manufacturers are following suit. With the appearance of such products and the release of complete X sources on the Berkeley 4.3 UNIX distribution tapes, it is no longer feasible to track all X use and development.” And I was wrong with: > I never really distinguished between the Stanford "SUN" and the Sun Microsystems "Sun-1”, oops. Taking Clem’s comment into account I could see that the SUN ran the V kernel and the W graphics system, and that the Sun-1 was using an early form of X. Whilst the part about SUN may be correct, the Sun-1 was apparently using MGR and SunWindows/SunView -- at least according to the interesting blog post here (discussed on TUHS a few months ago): https://oldvcr.blogspot.com/2022/10/if-one-guis-not-enough-for-your-sparc.html From tuhs at tuhs.org Fri Jan 27 10:34:48 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 27 Jan 2023 00:34:48 +0000 Subject: [TUHS] =?utf-8?q?Collecting_notes_for_future_=E2=80=9Chistorians?= =?utf-8?q?=E2=80=9D_was=3A_Earliest_UNIX_Workstations=3F?= In-Reply-To: <620c709c-e8bb-401c-a60d-8869457caacd@app.fastmail.com> References: <202301261804.30QI4sd9132510@darkstar.fourwinds.com> <202301262138.30QLc6wY143500@darkstar.fourwinds.com> <620c709c-e8bb-401c-a60d-8869457caacd@app.fastmail.com> Message-ID: > Ah, I meant to ask: is there an existing wiki or repository? Or am I starting one? https://wiki.tuhs.org/ I've discussed writing a few articles with Warren and it sounds like he's all for more folks producing content. Ultimately it's Warren's call on that one, but I'm very interested in starting to produce some content. > An appropriate way for us to do this sort of thing would be to create > a repository where we can contribute to documents written in troff. I've considered this exact thing save not for this project, but just as a way to approach collaborative writing. I wouldn't have the attention span to admin such a repository, but would more than happily contribute to one, I love exposition and free access to knowledge. - Matt G. From g.branden.robinson at gmail.com Fri Jan 27 10:36:12 2023 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Thu, 26 Jan 2023 18:36:12 -0600 Subject: [TUHS] =?utf-8?q?Collecting_notes_for_future_=E2=80=9Chistorians?= =?utf-8?q?=E2=80=9D_was=3A_Earliest_UNIX_Workstations=3F?= In-Reply-To: <620c709c-e8bb-401c-a60d-8869457caacd@app.fastmail.com> References: <202301261804.30QI4sd9132510@darkstar.fourwinds.com> <202301262138.30QLc6wY143500@darkstar.fourwinds.com> <620c709c-e8bb-401c-a60d-8869457caacd@app.fastmail.com> Message-ID: <20230127003612.dszdsftdjkobikx7@illithid> Hi Joseph, At 2023-01-26T14:41:50-0800, Joseph Holsten wrote: > And if I’m writing in troff, is there a preferred macro set for > articles these days? A decade ago I wrote manuals in mdoc but papers > in LaTeX; these days I just lean on pandoc to translate. I’ll need to > knock my rust off. There's always ms. It's pretty easy to acquire, and will produce authentic looking traditional Unix papers with little effort. Here's a manual that Larry Kollar and I wrote, in source and PDF forms. It's gotten positive feedback from the groff mailing list. Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: ms.ms Type: application/x-troff-ms Size: 75185 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ms.2023-01-26.pdf Type: application/pdf Size: 135713 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From tuhs at tuhs.org Fri Jan 27 10:48:30 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 27 Jan 2023 00:48:30 +0000 Subject: [TUHS] Setting up an X Development Environment for Mac OS In-Reply-To: References: <20230125203805.4762218C083@mercury.lcs.mit.edu> <7w8rhpdczd.fsf@junk.nocrew.org> <20230126105626.72CD922168@orac.inputplus.co.uk> <85d0ee98-3686-b305-49d7-536589b5d3db@e-bbes.com> Message-ID: id Software is a perfect​ example of the fact that you can open source your stuff once it has done market rounds and still be wildly successful and a household name. It helps that John Carmack himself was very principled about that sort of thing, not only contributing engines as open source projects but designing them specifically to be easy to modify and extend. The WAD is as responsible for the success of doom as source availability methinks. The saving grace of it all is that disassemblers exist, so with a little knowhow and a looooot of patience, any codebase can be opened, it just may not precisely represent what the original programmer put down. It's no secret that countless significant titles have gotten this treatment already too, heck, folks have even started producing 1:1 C decompiles of some N64 titles. So at least not all is lost, but there are of course things in source code that one will never find by disassembling a binary, and especially decompiling. There is zero guarantee you've got 1:1 procedures and code, just a 1:1 binary in the end. Who knows what tools people had in their pipeline performing optimizations and such. That said, console games of the 5th gen and back are the most likely candidates for this sort of forensic preservation as they tended to be bare metal or pretty darn close to it and ubiquitous vendor libraries have leaked for many of them, so part of the reversing would just be finding the various library blobs, labeling them, and then yanking them out to just leave the engine and in-house libraries. This is one heck of a subject drift though, trying to get better about that. Down to continue following this thread but no TUHS Cc please, at least to reply to me. - Matt G. ------- Original Message ------- On Thursday, January 26th, 2023 at 2:51 PM, Andy Kosela wrote: > On Thursday, January 26, 2023, segaloco via TUHS wrote: > >> We benefit from a general culture of openness surrounding UNIX these days. We see no such openness from Nintendo, Sega, Sony, nor Microsoft in their video game offerings, neither current nor former, and similar for publishers and studios for the most part. Anecdotally, when SquareEnix went to reissue Final Fantasy 8, they had to rewrite it from scratch as the original PS1 source code had been lost. Apparently this is a pretty common problem plaguing efforts to roll older titles forward to modern systems, and is one of the reasons shoddy emulation seems to win out over intentional ports of anything. >> >> UNIX experienced the rather unique phenomenon of being able to grow legs in academia for many years before some legal types tried to put the kibosh on that. Super Mario Bros. was a closed code base from day 1 with a tight deadline and little to no reason for it to be shared outside of its own development group. The circumstances are just so wildly different. UNIX is a bit of an anomaly as far as being an iconic, ubiquitous, still appreciated design that succeeds in academic *and* commercial spheres and also has ample source code and documentation history not only available but not constantly being torpedoed by lawyers. I don't know that we'll see a willingness to open up the history of video game development like that in a timeframe that sensitive source codes and documents could still be properly preserved. >> >> Plus, to the defense of these studios, some algorithm or technique developed for management of game resources may still be very much relevant to modern engine designs in ways that OS code from the 70s simply wouldn't even have a place in modern design. I wouldn't be surprised if there are scene graph and asset manager algorithms and such down in, say, the Zelda 64 engine, that the big N is *still* using in comparable engines and considers a trade secret. Hard to say. But anywho, just to draw some comparisons to the preservation state of UNIX vs other technological innovations. We have decades of quality OS code to study, research, and expand upon as hackers, but we have no such wealth of real video game source codes to educate the masses on game design, especially embedded console/bare metal approaches. This is where the crossroads lies for me between my UNIX and game development interests, I would LOVE some day for there to be as accessible and quality of resources for those studying the history of game design/development as there are for those studying OS design. After all, the way I describe old games to people in a technical sense is its just a specific type of OS. That programmer had to abstract all that hardware into concepts like button triggers movement of VDP scrollplanes and emission of commands to the FM synth chip. The thing you're using is just a Dpad instead of a mouse and you're moving a silly little character instead of a window across the screen. > > The closest I can think of in the game industry to the open source community of Unix/Linux is Doom/Quake. Doom source code was opened in 1997 and Quake in 1999 and since then we have experienced a whole generation of programmers and artists playing with, porting and enhancing the codebase. I don't know of any other game development project that has as much longevity as those two; and all of it happened because John Carmack made the decision to open source it based on the popularity of open source Linux at the time. > > --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Fri Jan 27 10:53:51 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 27 Jan 2023 00:53:51 +0000 Subject: [TUHS] =?utf-8?q?Collecting_notes_for_future_=E2=80=9Chistorians?= =?utf-8?q?=E2=80=9D_was=3A_Earliest_UNIX_Workstations=3F?= In-Reply-To: <20230127003612.dszdsftdjkobikx7@illithid> References: <202301261804.30QI4sd9132510@darkstar.fourwinds.com> <202301262138.30QLc6wY143500@darkstar.fourwinds.com> <620c709c-e8bb-401c-a60d-8869457caacd@app.fastmail.com> <20230127003612.dszdsftdjkobikx7@illithid> Message-ID: You just got my head all abuzz on whether a *roff<->MediaWiki transpiler would be: 1. Possible and 2. Beneficial. We use a MediaWiki at work for aggregating random tidbits from people that they think might get lost in project noise. There's times I'd love to have some way to *roff-ize the materials for white papers, the printouts from MediaWiki are uuuuugly. Benefits on the flip-side would be rapidly getting all sorts of documentation into Wiki format pretty quickly. Of course, for an actual documentation project, there would need to be a master as diverse edits in different places wouldn't track with one another. In this case, the *roff sources would probably make a better master for diff reasons. - Matt G. ------- Original Message ------- On Thursday, January 26th, 2023 at 4:36 PM, G. Branden Robinson wrote: > Hi Joseph, > > At 2023-01-26T14:41:50-0800, Joseph Holsten wrote: > > > And if I’m writing in troff, is there a preferred macro set for > > articles these days? A decade ago I wrote manuals in mdoc but papers > > in LaTeX; these days I just lean on pandoc to translate. I’ll need to > > knock my rust off. > > > There's always ms. It's pretty easy to acquire, and will produce > authentic looking traditional Unix papers with little effort. Here's a > manual that Larry Kollar and I wrote, in source and PDF forms. It's > gotten positive feedback from the groff mailing list. > > Regards, > Branden From davida at pobox.com Fri Jan 27 11:28:27 2023 From: davida at pobox.com (David Arnold) Date: Fri, 27 Jan 2023 12:28:27 +1100 Subject: [TUHS] =?utf-8?q?Collecting_notes_for_future_=E2=80=9Chistorians?= =?utf-8?q?=E2=80=9D_was=3A_Earliest_UNIX_Workstations=3F?= In-Reply-To: References: Message-ID: fwiw, Pandoc (https://pandoc.org) claims to be able to translate between MediaWiki and both man and ms roff macros. d > On 27 Jan 2023, at 11:54, segaloco via TUHS wrote: > > You just got my head all abuzz on whether a *roff<->MediaWiki transpiler would be: 1. Possible and 2. Beneficial. > > We use a MediaWiki at work for aggregating random tidbits from people that they think might get lost in project noise. There's times I'd love to have some way to *roff-ize the materials for white papers, the printouts from MediaWiki are uuuuugly. Benefits on the flip-side would be rapidly getting all sorts of documentation into Wiki format pretty quickly. > > Of course, for an actual documentation project, there would need to be a master as diverse edits in different places wouldn't track with one another. In this case, the *roff sources would probably make a better master for diff reasons. > > - Matt G. > > ------- Original Message ------- >> On Thursday, January 26th, 2023 at 4:36 PM, G. Branden Robinson wrote: >> Hi Joseph, >> At 2023-01-26T14:41:50-0800, Joseph Holsten wrote: >>> And if I’m writing in troff, is there a preferred macro set for >>> articles these days? A decade ago I wrote manuals in mdoc but papers >>> in LaTeX; these days I just lean on pandoc to translate. I’ll need to >>> knock my rust off. >> There's always ms. It's pretty easy to acquire, and will produce >> authentic looking traditional Unix papers with little effort. Here's a >> manual that Larry Kollar and I wrote, in source and PDF forms. It's >> gotten positive feedback from the groff mailing list. >> Regards, >> Branden From imp at bsdimp.com Fri Jan 27 11:35:02 2023 From: imp at bsdimp.com (Warner Losh) Date: Thu, 26 Jan 2023 18:35:02 -0700 Subject: [TUHS] =?utf-8?q?Collecting_notes_for_future_=E2=80=9Chistorians?= =?utf-8?q?=E2=80=9D_was=3A_Earliest_UNIX_Workstations=3F?= In-Reply-To: References: Message-ID: I've moved to markdown or asciidoc for things like this. So many things can import them and they are easier to write than roff or TeX. Warner On Thu, Jan 26, 2023, 6:29 PM David Arnold wrote: > fwiw, Pandoc (https://pandoc.org) claims to be able to translate between > MediaWiki and both man and ms roff macros. > > > > > d > > > > On 27 Jan 2023, at 11:54, segaloco via TUHS wrote: > > > > You just got my head all abuzz on whether a *roff<->MediaWiki > transpiler would be: 1. Possible and 2. Beneficial. > > > > We use a MediaWiki at work for aggregating random tidbits from people > that they think might get lost in project noise. There's times I'd love to > have some way to *roff-ize the materials for white papers, the printouts > from MediaWiki are uuuuugly. Benefits on the flip-side would be rapidly > getting all sorts of documentation into Wiki format pretty quickly. > > > > Of course, for an actual documentation project, there would need to be a > master as diverse edits in different places wouldn't track with one > another. In this case, the *roff sources would probably make a better > master for diff reasons. > > > > - Matt G. > > > > ------- Original Message ------- > >> On Thursday, January 26th, 2023 at 4:36 PM, G. Branden Robinson < > g.branden.robinson at gmail.com> wrote: > >> Hi Joseph, > >> At 2023-01-26T14:41:50-0800, Joseph Holsten wrote: > >>> And if I’m writing in troff, is there a preferred macro set for > >>> articles these days? A decade ago I wrote manuals in mdoc but papers > >>> in LaTeX; these days I just lean on pandoc to translate. I’ll need to > >>> knock my rust off. > >> There's always ms. It's pretty easy to acquire, and will produce > >> authentic looking traditional Unix papers with little effort. Here's a > >> manual that Larry Kollar and I wrote, in source and PDF forms. It's > >> gotten positive feedback from the groff mailing list. > >> Regards, > >> Branden > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Fri Jan 27 14:07:20 2023 From: will.senn at gmail.com (Will Senn) Date: Thu, 26 Jan 2023 22:07:20 -0600 Subject: [TUHS] Setting up an X Development Environment for Mac OS In-Reply-To: References: <20230125203805.4762218C083@mercury.lcs.mit.edu> <7w8rhpdczd.fsf@junk.nocrew.org> <20230126105626.72CD922168@orac.inputplus.co.uk> <85d0ee98-3686-b305-49d7-536589b5d3db@e-bbes.com> Message-ID: <45987281-a06d-810e-9689-5a8ae2c63a63@gmail.com> On 1/26/23 6:48 PM, segaloco via TUHS wrote: > id Software is a *perfect*​ example of the fact that you can open > source your stuff once it has done market rounds and still be wildly > successful and a household name.  It helps that John Carmack himself > was very principled about that sort of thing, not only contributing > engines as open source projects but designing them specifically to be > easy to modify and extend. The WAD is as responsible for the success > of doom as source availability methinks. I met John Romero and American McGee back in the early 1990's as they were just finished with Doom II. John Carmack had some other obligation (sad, cuz he was the main developer), but Romero was pretty smart too - had plenty of insight into the space rendering mechanics and such and both were more than happy to share what they new, what they were working on, and gab about space and time :). I also remember that they were bemoaning having to give up their NeXT boxes for racks and racks of some other machine to do equivalent work (at the time, I was completely clueless as to what they were talking about). With decades behind, I have a clue about one workstation being oh so powerful and about server farms doing rendering, but I really don't know nothing about NeXT, it's boxes, or what I'm really wondering about - its relationship with unix (although I'm pretty sure there is one). I know that Sun was working with them on OpenStep and OpenStep and the NeXT cube were predecessors to my favorite contemporary system (my Mac), but that's about it. So, how does NeXT fit into the unix world? And was it all that? I remember after talking to them that I really, really wanted one... Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Fri Jan 27 16:25:00 2023 From: lars at nocrew.org (Lars Brinkhoff) Date: Fri, 27 Jan 2023 06:25:00 +0000 Subject: [TUHS] C port of Ken Thompson's Space Travel Message-ID: <7wcz70bikj.fsf@junk.nocrew.org> If you don't want to play Space Travel on PDP-7 Unix, you can now do it more easily running this C port. The controls are--so far--just as quirky as the original. https://github.com/mohd-akram/st From arnold at skeeve.com Fri Jan 27 18:53:44 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 27 Jan 2023 01:53:44 -0700 Subject: [TUHS] [off-topic] Anyone still using USENET? Message-ID: <202301270853.30R8rif6014271@freefriends.org> Hi. I've been using trn for decades to read a very few USENET groups. Until recently I've been using aioe.org as my NNTP server but it seems to have gone dark. Before that I used eternal-september.org, but when I try that I now get: | $ NNTPSERVER=news.eternal-september.org trn | Connecting to news.eternal-september.org...Done. | | Invalid (bogus) newsgroup found: comp.sys.3b1 | | Invalid (bogus) newsgroup found: comp.sources.bugs | | Invalid (bogus) newsgroup found: comp.misc | | Invalid (bogus) newsgroup found: comp.compilers | .... And those all are (or were!) valid groups. If anyone has suggestions for a good free NNTP server, please let me know. Privately is fine. I'm at a bit of a loss otherwise. Thanks, Arnold From lars at nocrew.org Fri Jan 27 19:03:36 2023 From: lars at nocrew.org (Lars Brinkhoff) Date: Fri, 27 Jan 2023 09:03:36 +0000 Subject: [TUHS] [off-topic] Anyone still using USENET? In-Reply-To: <202301270853.30R8rif6014271@freefriends.org> (arnold@skeeve.com's message of "Fri, 27 Jan 2023 01:53:44 -0700") References: <202301270853.30R8rif6014271@freefriends.org> Message-ID: <7w8rhobb87.fsf@junk.nocrew.org> I use dotsrc.org (formerly sunsite.dk). From ron at ronnatalie.com Fri Jan 27 19:24:03 2023 From: ron at ronnatalie.com (Ron Natalie) Date: Fri, 27 Jan 2023 09:24:03 +0000 Subject: [TUHS] [off-topic] Anyone still using USENET? In-Reply-To: <7w8rhobb87.fsf@junk.nocrew.org> References: <202301270853.30R8rif6014271@freefriends.org> <7w8rhobb87.fsf@junk.nocrew.org> Message-ID: Nothing on it but spam and porn now unfortunately. Such a shame. About the closest I’ve come to the sense of the old USENET is reddit. ------ Original Message ------ >From "Lars Brinkhoff" To arnold at skeeve.com Cc tuhs at tuhs.org Date 1/27/2023 4:03:36 AM Subject [TUHS] Re: [off-topic] Anyone still using USENET? >I use dotsrc.org (formerly sunsite.dk). From cowan at ccil.org Fri Jan 27 19:34:17 2023 From: cowan at ccil.org (John Cowan) Date: Fri, 27 Jan 2023 04:34:17 -0500 Subject: [TUHS] [off-topic] Anyone still using USENET? In-Reply-To: References: <202301270853.30R8rif6014271@freefriends.org> <7w8rhobb87.fsf@junk.nocrew.org> Message-ID: It depends on the newsgroup. I read c.l.scheme and c.l.pl1 at Google, and it's fine. On Fri, Jan 27, 2023 at 4:24 AM Ron Natalie wrote: > Nothing on it but spam and porn now unfortunately. Such a shame. > About the closest I’ve come to the sense of the old USENET is reddit. > > > > ------ Original Message ------ > From "Lars Brinkhoff" > To arnold at skeeve.com > Cc tuhs at tuhs.org > Date 1/27/2023 4:03:36 AM > Subject [TUHS] Re: [off-topic] Anyone still using USENET? > > >I use dotsrc.org (formerly sunsite.dk). > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Fri Jan 27 20:36:05 2023 From: tuhs at tuhs.org (parodper via TUHS) Date: Fri, 27 Jan 2023 11:36:05 +0100 Subject: [TUHS] [off-topic] Anyone still using USENET? In-Reply-To: <202301270853.30R8rif6014271@freefriends.org> References: <202301270853.30R8rif6014271@freefriends.org> Message-ID: <3edc2100-500d-a76e-6b41-d2e815933681@disroot.org> O 27/01/23 ás 09:53, arnold at skeeve.com escribiu: > Hi. > > I've been using trn for decades to read a very few USENET groups. Until recently I've > been using aioe.org as my NNTP server but it seems to have gone dark. According to a poster on eternal-september.support AIOE's RAID failed and they're trying to get it up again. > Before that > I used eternal-september.org, but when I try that I now get: > > | $ NNTPSERVER=news.eternal-september.org trn > | Connecting to news.eternal-september.org...Done. > | > | Invalid (bogus) newsgroup found: comp.sys.3b1 > | > | Invalid (bogus) newsgroup found: comp.sources.bugs > | > | Invalid (bogus) newsgroup found: comp.misc > | > | Invalid (bogus) newsgroup found: comp.compilers > | .... > > And those all are (or were!) valid groups. I just tried, and I can access those groups from eternal-september.org. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From lars at nocrew.org Fri Jan 27 20:59:34 2023 From: lars at nocrew.org (Lars Brinkhoff) Date: Fri, 27 Jan 2023 10:59:34 +0000 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: <7wo7qlb1rv.fsf@junk.nocrew.org> (Lars Brinkhoff's message of "Thu, 26 Jan 2023 18:15:32 +0000") References: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl> <7wo7qlb1rv.fsf@junk.nocrew.org> Message-ID: <7w4jscb5ux.fsf@junk.nocrew.org> > Stanford University Network workstation. I have seen some documents > about it on stacks.stanford.edu, but I don't remember about the > software. In some versions, it's a more of a multi-head remote graphics > terminal, so maybe not Unix. In the 1980 document, it's described as a single 68000 serving up to 16 seats. "only the basic Pup Telnet protocols need be implemented on the workstation's MC68OOO processor. The SUN terminals could then be programmed to emulate currently available terminals, such as Datamedias, Telerays, Tektronix 4014 graphics terminals, or III displays." https://stacks.stanford.edu/file/druid:gg867qx3134/gg867qx3134.pdf But by 1982 it looks much like a classic workstation. "The SUN Memory Management Unit has been designed to support a multitasking operating system such as Bell Lab’s UNIX." http://i.stanford.edu/pub/cstr/reports/csl/tr/82/229/CSL-TR-82-229.pdf From ralph at inputplus.co.uk Fri Jan 27 23:56:51 2023 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Fri, 27 Jan 2023 13:56:51 +0000 Subject: [TUHS] Setting up an X Development Environment for Mac OS In-Reply-To: References: <20230125203805.4762218C083@mercury.lcs.mit.edu> <7w8rhpdczd.fsf@junk.nocrew.org> <20230126105626.72CD922168@orac.inputplus.co.uk> Message-ID: <20230127135651.A70482135B@orac.inputplus.co.uk> Hi josh, > > Rob Pike wrote of magnetic tapes he had which could no longer be > > read. The coating had failed off IIRC. > > I think you’re referring to this blog post (which I’ve also previously > struggled to find): https://commandcenter.blogspot.com/2014/08/prints.html Thanks, that's what I was thinking of. ‘NASA lost a large part of the data collected by the Viking Mars missions because the iron oxide fell off the tapes storing the data. ... The same affliction that damaged the Viking tapes also wiped out my personal backup archive; I lost the only copy of my computer work from the 1970s.’ I first tried DuckDuckGo and Google but I don't think they associate that site with Cmdr Pike. I did end up there are checking my list of RSS feeds and tediously expanded all of the right-hand indexes but I didn't recall the photography connection and so not ‘prints’ either. -- Cheers, Ralph. From chet.ramey at case.edu Sat Jan 28 00:08:13 2023 From: chet.ramey at case.edu (Chet Ramey) Date: Fri, 27 Jan 2023 09:08:13 -0500 Subject: [TUHS] Setting up an X Development Environment for Mac OS In-Reply-To: <45987281-a06d-810e-9689-5a8ae2c63a63@gmail.com> References: <20230125203805.4762218C083@mercury.lcs.mit.edu> <7w8rhpdczd.fsf@junk.nocrew.org> <20230126105626.72CD922168@orac.inputplus.co.uk> <85d0ee98-3686-b305-49d7-536589b5d3db@e-bbes.com> <45987281-a06d-810e-9689-5a8ae2c63a63@gmail.com> Message-ID: On 1/26/23 11:07 PM, Will Senn wrote: > but I really don't know nothing about NeXT, it's boxes, or what I'm really > wondering about - its relationship with unix (although I'm pretty sure > there is one). I know that Sun was working with them on OpenStep and > OpenStep and the NeXT cube were predecessors to my favorite contemporary > system (my Mac), but that's about it. So, how does NeXT fit into the unix > world? And was it all that? I remember after talking to them that I really, > really wanted one... NeXTs were really nice boxes. The environment was basically Mach + 4.3BSD + Display Postscript + Objective C + the libraries and frameworks that became macOS Carbon and Cocoa + their GUI. I had one for a while, and wish I still did for old times' sake. NeXT was Steve Jobs's company, and Apple acquired them to make the NeXT OS the basis of MacOS X. That is a very interesting story itself. -- ``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 ralph at inputplus.co.uk Sat Jan 28 00:17:40 2023 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Fri, 27 Jan 2023 14:17:40 +0000 Subject: [TUHS] Setting up an X Development Environment for Mac OS In-Reply-To: <85d0ee98-3686-b305-49d7-536589b5d3db@e-bbes.com> References: <20230125203805.4762218C083@mercury.lcs.mit.edu> <7w8rhpdczd.fsf@junk.nocrew.org> <20230126105626.72CD922168@orac.inputplus.co.uk> <85d0ee98-3686-b305-49d7-536589b5d3db@e-bbes.com> Message-ID: <20230127141740.390792135B@orac.inputplus.co.uk> Hi, emanuel wrote: > And copying the archives to newer disks, newer mail systems so it will > hopefully survive ... Diverging onto floppy disks, the Greaseweazle is handy for moving the floppy-disk controller aside and getting the flux levels from the drive for interpretation by software but sometimes that's still too high level. Given floppy drives often have test points on the board, they can be used to obtain the signal from the head before the PCB has muddied its waters. https://scarybeastsecurity.blogspot.com/2021/05/recovering-lost-treasure-filled-floppy.html tells of doing this with an oscilloscope allowing the recovery of some old assembly code where the flux signal from the drive was too corrupted. So even if the pertinent hardware has trouble with old media, perhaps there's still hope. -- Cheers, Ralph. From ralph at inputplus.co.uk Sat Jan 28 00:45:52 2023 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Fri, 27 Jan 2023 14:45:52 +0000 Subject: [TUHS] [off-topic] Anyone still using USENET? In-Reply-To: <202301270853.30R8rif6014271@freefriends.org> References: <202301270853.30R8rif6014271@freefriends.org> Message-ID: <20230127144552.7E3F12135B@orac.inputplus.co.uk> Hi Arnold, > I've been using trn for decades Very fond memories of trn(1). In comparison, I've never seen a web interface, e.g. for RSS reading, be so geared towards the user and his likely actions whilst also allowing for powerful expression. > to read a very few USENET groups. Bringing it back to heritage, I was wondering about Usenet the other day. Deja News was excellent, Google Groups is pitiful. A good search of a comprehensive, historic Usenet archive would be useful from the TUHS side, but I expect modern analysis means it would also be interesting to those wanting cultural analysis of a subset of the public in earlier decades. Henry Spencer's UTZOO archive is available. Sites like https://www.usenetarchives.com have used it in the past, but none I know of are well maintained. In part, anything popular would attract legal requests for posts to be taken down; IIRC that's why archive.org took down their official copy of UTZOO. But the data is so small by modern standards, perhaps a self-hosted searcher is a way forward. -- Cheers, Ralph. From ron at ronnatalie.com Sat Jan 28 00:49:25 2023 From: ron at ronnatalie.com (Ron Natalie) Date: Fri, 27 Jan 2023 14:49:25 +0000 Subject: [TUHS] Setting up an X Development Environment for Mac OS In-Reply-To: References: <20230125203805.4762218C083@mercury.lcs.mit.edu> <7w8rhpdczd.fsf@junk.nocrew.org> <20230126105626.72CD922168@orac.inputplus.co.uk> <85d0ee98-3686-b305-49d7-536589b5d3db@e-bbes.com> <45987281-a06d-810e-9689-5a8ae2c63a63@gmail.com> Message-ID: Having been running a University computer center we were the target environment for these. Still the “optical only” drive was problematic. By the time I actually received one (the joke was that the company was going to be renamed from “Next” to “Eventually”). It did have a hard drive in it. Oddly, the other thing it lacked was parity on the memory. A big thing was made over the fact that the thing wasn’t exaxtly a cube in shape. But it was Mach inside which meant it was fairy decent. It was one of the several dozen things we ported our software to. For some reason, the one I had came with a poorly digitized version of Janes All the World’s Aircraft. It did have the top bar menus similar to the then MacOS environment and what would become the Max OSX. From ron at ronnatalie.com Sat Jan 28 00:51:20 2023 From: ron at ronnatalie.com (Ron Natalie) Date: Fri, 27 Jan 2023 14:51:20 +0000 Subject: [TUHS] [off-topic] Anyone still using USENET? In-Reply-To: <20230127144552.7E3F12135B@orac.inputplus.co.uk> References: <202301270853.30R8rif6014271@freefriends.org> <20230127144552.7E3F12135B@orac.inputplus.co.uk> Message-ID: I also remember alt.2600. Because of my work in security I was encouraged to keep tabs on such things (also had the government buy me a subscription to the printed 2600). It was set up as a moderated group, but there was no moderator. Your right to post was derived by the fact that you knew how to forge the approved line into the header to get it distributed. From ron at ronnatalie.com Sat Jan 28 00:54:19 2023 From: ron at ronnatalie.com (Ron Natalie) Date: Fri, 27 Jan 2023 14:54:19 +0000 Subject: [TUHS] Setting up an X Development Environment for Mac OS In-Reply-To: <20230127135651.A70482135B@orac.inputplus.co.uk> References: <20230125203805.4762218C083@mercury.lcs.mit.edu> <7w8rhpdczd.fsf@junk.nocrew.org> <20230126105626.72CD922168@orac.inputplus.co.uk> <20230127135651.A70482135B@orac.inputplus.co.uk> Message-ID: When I worked in the intelligience industry, the government spent a lot of money tasking someone (I think it was Kodak) to determine the best media for archival storage. It included traditional 6250 9 track tapes and the then-popular exabyte 8mm (which was atrociously short lived). I pointed out that magnetic storage was probably always going to be problematic and things needed “digital refresh” if you really wanted to keep them. If you know the tape may be problematic when played back, there are things you can do. I was gifted the master tapes of one of the radio shows originated at WJHU in the 70’s. I had them sent out to a company who “baked” them, but then they also had to redo all the splices on them when they were played back. From tuhs at tuhs.org Sat Jan 28 00:56:08 2023 From: tuhs at tuhs.org (Ron Young via TUHS) Date: Fri, 27 Jan 2023 06:56:08 -0800 Subject: [TUHS] [off-topic] Anyone still using USENET? In-Reply-To: <20230127144552.7E3F12135B@orac.inputplus.co.uk> References: <202301270853.30R8rif6014271@freefriends.org> <20230127144552.7E3F12135B@orac.inputplus.co.uk> Message-ID: <9C33F463-0EE6-4A97-BDB5-65663805F3D2@embarqmail.com> On January 27, 2023 6:45:52 AM PST, Ralph Corderoy wrote: >Hi Arnold, > >> I've been using trn for decades > >Very fond memories of trn(1). In comparison, I've never seen a web >interface, e.g. for RSS reading, be so geared towards the user and his >likely actions whilst also allowing for powerful expression. > >> to read a very few USENET groups. > I'm still using trn4 and stunnel4 to to read news from supernews... Works great. (UN) fortunately it is only for a small number of groups. -ron From crossd at gmail.com Sat Jan 28 01:53:55 2023 From: crossd at gmail.com (Dan Cross) Date: Fri, 27 Jan 2023 10:53:55 -0500 Subject: [TUHS] Setting up an X Development Environment for Mac OS In-Reply-To: <45987281-a06d-810e-9689-5a8ae2c63a63@gmail.com> References: <20230125203805.4762218C083@mercury.lcs.mit.edu> <7w8rhpdczd.fsf@junk.nocrew.org> <20230126105626.72CD922168@orac.inputplus.co.uk> <85d0ee98-3686-b305-49d7-536589b5d3db@e-bbes.com> <45987281-a06d-810e-9689-5a8ae2c63a63@gmail.com> Message-ID: On Thu, Jan 26, 2023 at 11:08 PM Will Senn wrote: > [snip] > I also remember that they were bemoaning having to give up their NeXT > boxes for racks and racks of some other machine to do equivalent work > (at the time, I was completely clueless as to what they were talking about). > With decades behind, I have a clue about one workstation being oh so > powerful and about server farms doing rendering, but I really don't know > nothing about NeXT, it's boxes, or what I'm really wondering about - its > relationship with unix (although I'm pretty sure there is one). I know that > Sun was working with them on OpenStep and OpenStep and the NeXT > cube were predecessors to my favorite contemporary system (my Mac), > but that's about it. So, how does NeXT fit into the unix world? And was > it all that? I remember after talking to them that I really, really wanted one... As Chet mentioned, NeXTs ran NeXTStep, which was based on Mach and 4.3-ish BSD. My sense was that they were underpowered and overpriced for the time; they were 68k based in an era where RISC processors were dominant (or becoming dominant) on the high end and they cost something like twice or more that of a contemporary Macintosh while targeting roughly the same userbase. The software was really the interesting thing on NeXT machines. Oh the hardware was nice enough, don't get me wrong, but compared to a SPARC or MIPS-based workstation, I'd choose the latter every time. However, NeXTStep was not very "Unix-y" if you were used to BSD or even System V Unixes of the time. Things as basic as the directory structure were weirdly foreign (though will look familiar to users of macOS now), and it used "netinfo", which was a distributed directory service they'd built, rather than NIS or anything remotely interoperable with the rest of the world. But the NeXTStep user interface was very nice, and Display PostScript was beautiful. The Objective-C foundation classes were very powerful. But it was clear that you were meant to interact with it through the GUI, and CLI-style interaction was an almost totally separate universe (or so it seemed to me at the time). One got the sense that NeXT was targeting users who had sort of outgrown the Macintosh, but weren't ready to make the leap to a full-on workstation on the low-end, and simultaneously trying to bring users from high-end machines into a totally new ecosystem. But that was a really small market and application vendors didn't jump on board: the Unix applications weren't there, and neither were the standards from the Mac world. A few things got ported, and that was cool, but perhaps sadly, Jobs just couldn't pull off the magic twice, and NeXT failed. Much of the technology lives on in macOS, though. There's a great book about it, "Steve Jobs and the NeXT Big Thing" that's worth a read. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sat Jan 28 02:05:31 2023 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 27 Jan 2023 08:05:31 -0800 Subject: [TUHS] [off-topic] Anyone still using USENET? In-Reply-To: References: <202301270853.30R8rif6014271@freefriends.org> <7w8rhobb87.fsf@junk.nocrew.org> Message-ID: <20230127160531.GE5393@mcvoy.com> On Fri, Jan 27, 2023 at 09:24:03AM +0000, Ron Natalie wrote: > Nothing on it but spam and porn now unfortunately. Such a shame. About > the closest I???ve come to the sense of the old USENET is reddit. Reddit is sort of a centralized Usenet with voting. In the old days, centralized would have never worked but it works now. If you can live with the fact that Reddit has a lot of echo chamber stuff going on, it's quite pleasant. Reddit is my primary news source these days and I wade through a lot of random stuff there. There is a lot of noise but once in a while some cancer thing will come up, I take a look at the comments, there will be an actual oncologist / cancer researcher in there who will say "yeah, this is in the lab only, not tested on humans, not interesting for at least 10-20 years" or, rarely, "this is very promising". For the latter, you go off and read the article. From lm at mcvoy.com Sat Jan 28 02:10:16 2023 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 27 Jan 2023 08:10:16 -0800 Subject: [TUHS] Setting up an X Development Environment for Mac OS In-Reply-To: References: <20230125203805.4762218C083@mercury.lcs.mit.edu> <7w8rhpdczd.fsf@junk.nocrew.org> <20230126105626.72CD922168@orac.inputplus.co.uk> <20230127135651.A70482135B@orac.inputplus.co.uk> Message-ID: <20230127161016.GF5393@mcvoy.com> On Fri, Jan 27, 2023 at 02:54:19PM +0000, Ron Natalie wrote: > It included traditional 6250 9 track tapes and the > then-popular exabyte 8mm (which was atrociously short lived). Ah, 8mm Exabyte, how I despise thee. When I left Sun for SGI, Ken Okin graciously let me take my Sun 4/470, that had 768MB of ram (crazy big for the time, I had that because I fixed the VM system for big memory machines). It also had an 8mm Exabyte and a bunch of goodies on tape. Wheeling that machine from my VW van into building 9 at SGI was enough jiggling that *none* of my tapes were readable. I've never seen a more fragile system than those exabyte. By comparison, the old SCSI QIC 150s, while small, were industructible, I think you could have used the tapes as hammers and they'd still read. Same thing for 9 track. From sauer at technologists.com Sat Jan 28 02:12:38 2023 From: sauer at technologists.com (Charles H Sauer (he/him)) Date: Fri, 27 Jan 2023 10:12:38 -0600 Subject: [TUHS] NEXTSTEP 486 [was Re: Setting up an X Development Environment for Mac OS In-Reply-To: References: <20230125203805.4762218C083@mercury.lcs.mit.edu> <7w8rhpdczd.fsf@junk.nocrew.org> <20230126105626.72CD922168@orac.inputplus.co.uk> <85d0ee98-3686-b305-49d7-536589b5d3db@e-bbes.com> <45987281-a06d-810e-9689-5a8ae2c63a63@gmail.com> Message-ID: NEXTSTEP was (is?) interesting for many reasons IMO, especially what Berners-Lee did at CERN, and can still run today on appropriate 486 machines. I was in the thick of getting NEXTSTEP on 486. See https://notes.technologists.com/notes/2019/07/01/koko-exploring-nextstep-486/ and https://notes.technologists.com/notes/2019/07/01/koko-reviving-timbls-worldwideweb-browser/ Though our JAWS machine was Jobs' preferred demo machine for NEXTSTEP 486, NEXT supported a surprising variety of machines and peripherals by the 3.3 release. I have NEXTSTEP 486 (and other old OS) running on a couple of more popular Dell 486 machines as well as JAWS (https://notes.technologists.com/notes/2019/09/26/koko-welcome-to-eight-jurassic-o-s-on-1992-dell-486d-50/). There are probably many other early 90s 486 machines that could be made to run NEXTSTEP 486. Charlie On 1/27/2023 9:53 AM, Dan Cross wrote: > On Thu, Jan 26, 2023 at 11:08 PM Will Senn > wrote: > > [snip] > > I also remember that they were bemoaning having to give up their NeXT > > boxes for racks and racks of some other machine to do equivalent work > > (at the time, I was completely clueless as to what they were talking > about). > > With decades behind, I have a clue about one workstation being oh so > > powerful and about server farms doing rendering, but I really don't know > > nothing about NeXT, it's boxes, or what I'm really wondering about - its > > relationship with unix (although I'm pretty sure there is one). I > know that > > Sun was working with them on OpenStep and OpenStep and the NeXT > > cube were predecessors to my favorite contemporary system (my Mac), > > but that's about it. So, how does NeXT fit into the unix world? And was > > it all that? I remember after talking to them that I really, really > wanted one... > > As Chet mentioned, NeXTs ran NeXTStep, which was based on Mach and > 4.3-ish BSD. My sense was that they were underpowered and overpriced for > the time; they were 68k based in an era where RISC processors were > dominant (or becoming dominant) on the high end and they cost something > like twice or more that of a contemporary Macintosh while targeting > roughly the same userbase. > > The software was really the interesting thing on NeXT machines. Oh the > hardware was nice enough, don't get me wrong, but compared to a SPARC or > MIPS-based workstation, I'd choose the latter every time. However, > NeXTStep was not very "Unix-y" if you were used to BSD or even System V > Unixes of the time. Things as basic as the directory structure were > weirdly foreign (though will look familiar to users of macOS now), and > it used "netinfo", which was a distributed directory service they'd > built, rather than NIS or anything remotely interoperable with the rest > of the world. But the NeXTStep user interface was very nice, and Display > PostScript was beautiful. The Objective-C foundation classes were very > powerful. But it was clear that you were meant to interact with it > through the GUI, and CLI-style interaction was an almost totally > separate universe (or so it seemed to me at the time). > > One got the sense that NeXT was targeting users who had sort of outgrown > the Macintosh, but weren't ready to make the leap to a full-on > workstation on the low-end, and simultaneously trying to bring users > from high-end machines into a totally new ecosystem. But that was a > really small market and application vendors didn't jump on board: the > Unix applications weren't there, and neither were the standards from the > Mac world. A few things got ported, and that was cool, but perhaps > sadly, Jobs just couldn't pull off the magic twice, and NeXT failed. > Much of the technology lives on in macOS, though. > > There's a great book about it, "Steve Jobs and the NeXT Big Thing" > that's worth a read. > >         - Dan C. > -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/LinkedIn/Twitter: CharlesHSauer From ama at ugr.es Sat Jan 28 03:01:03 2023 From: ama at ugr.es (Angel M Alganza) Date: Fri, 27 Jan 2023 18:01:03 +0100 Subject: [TUHS] [off-topic] Anyone still using USENET? In-Reply-To: <20230127160531.GE5393@mcvoy.com> References: <202301270853.30R8rif6014271@freefriends.org> <7w8rhobb87.fsf@junk.nocrew.org> <20230127160531.GE5393@mcvoy.com> Message-ID: <35180c48b0a162da2a53d8fce1c50a81@ugr.es> My lovely Sparc SS20, in which I used to do email and USENET news, broke down a few years ago and I haven't taken the time neither to bring it back to life nor to replicate my news set up (leafnode + tinn) somewhere else, so alas I haven't been checking the news for a (far too long) while now. On 2023-01-27 17:05, Larry McVoy wrote: > Reddit is sort of a centralized Usenet with voting. > Reddit is my primary news source these days and I wade through a lot of > random stuff there. There is a lot of noise but once in a while some I find the ratio signal/noise of Reddit far too low to use it as a regular news source for me. For technical news, there is Hacker News (HN), which in place of a voting system, has a tipping system which rewards with small amounts of money the more interesting/useful posts and comments. In the same line, there is also Stacker News (SN), which uses Bitcoin on the Lightning Network for tips. Contents there are more focused about Bitcoin and economics, but more users are joining and proposing to widen the areas of focus on the site: technology, computing, etc. Both, HN and SN are centralized, but we are having discussions on SN about the possibility for SN to be converted to a Nostr client, which would keep the great spirit and maintain the interface, but replace its back-end (currently a centralized database) with Nostr relays, making it truly decentralized, much more robust, fault tolerant, and censorship resistant. I'm using Nostr more and more everyday, and I think it's soon will be my primary news source. If you have a look at SN and decide to join, please consider using my referral link: https://stacker.news/r/ama, so that when you stack your satoshi (Bitcoin tips), I get some little percentage, too, if you don't mind. :-) Hit me at Nostr at https://astral.ninja/npub1ttk90a6kkphe9h0dys9mqy38wxa7t4t7g39vys76f4cglqr49rgqh6xxpx where I'd love for notes about the unix in general and its history in particular to start accumulating. Cheers, Ángel From lm at mcvoy.com Sat Jan 28 03:08:36 2023 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 27 Jan 2023 09:08:36 -0800 Subject: [TUHS] [off-topic] Anyone still using USENET? In-Reply-To: <35180c48b0a162da2a53d8fce1c50a81@ugr.es> References: <202301270853.30R8rif6014271@freefriends.org> <7w8rhobb87.fsf@junk.nocrew.org> <20230127160531.GE5393@mcvoy.com> <35180c48b0a162da2a53d8fce1c50a81@ugr.es> Message-ID: <20230127170836.GG5393@mcvoy.com> On Fri, Jan 27, 2023 at 06:01:03PM +0100, Angel M Alganza wrote: > I find the ratio signal/noise of Reddit far too low to use it as a regular > news source for me. For technical news, there is Hacker News (HN), which in > place of a voting system, has a tipping system which rewards with small > amounts of money the more interesting/useful posts and comments. I left hacker news a few years ago for two reasons: A) the signal noise ratio, as a systems person, is awful. They talk about trivial stuff like it is a big deal. There is very little in the way of interesting stuff there. It all sounds technical until you look into it, it's 98% fluff. B) There is some paid(?) schill there who stomps on anyone saying anything bad about Roundup. Cancer got my dad, he got it from Roundup. Every time I tried point out I had personal data on the topic (and all you have to do is google Roundup and cancer and you get a bizillion law firms who want to represent you), this schill jumped on me. I complained to the admins and they did nothing, so I left. They were getting more out of me than I was getting out of that site so sucks to be them. On the signal/noise on reddit, /r/news is reasonable and not that different than Google news other than it shows up on reddit first. From tuhs at tuhs.org Sat Jan 28 03:16:14 2023 From: tuhs at tuhs.org (Paul Ruizendaal via TUHS) Date: Fri, 27 Jan 2023 18:16:14 +0100 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: References: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl> <0778FF74-7DF5-4072-95F3-5FF5BEB4CC33@planet.nl> Message-ID: > On Jan 27, 2023, at 1:19 AM, Paul Ruizendaal wrote: > > The version of X discussed in the paper was apparently part of the 4.3BSD distribution tapes: > > "The use of X has grown far beyond anything we had imagined. Digital has incorporated X into a commercial product, and other manufacturers are following suit. With the appearance of such products and the release of complete X sources on the Berkeley 4.3 UNIX distribution tapes, it is no longer feasible to track all X use and development.” > This X is not on the TUHS Unix tree website, nor on the CSRG disks. It turns out that there is a directory “src/new” that is not included there. It is here: http://www.retro11.de/ouxr/43bsd/usr/src/new/ The version of X included with 4.3BSD was X10. I assume this is the oldest surviving X Window source code. Of course the source code for the Blit has survived, as has the source code of MGR. The source code for Sunwindows and NeWS is presumably lost? -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sat Jan 28 03:36:26 2023 From: imp at bsdimp.com (Warner Losh) Date: Fri, 27 Jan 2023 10:36:26 -0700 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: References: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl> <0778FF74-7DF5-4072-95F3-5FF5BEB4CC33@planet.nl> Message-ID: On Fri, Jan 27, 2023 at 10:16 AM Paul Ruizendaal via TUHS wrote: > > On Jan 27, 2023, at 1:19 AM, Paul Ruizendaal wrote: > > The version of X discussed in the paper was apparently part of the 4.3BSD > distribution tapes: > > "The use of X has grown far beyond anything we had imagined. Digital has > incorporated X into a commercial product, and other manufacturers are > following suit. With the appearance of such products and the release of > complete X sources on the Berkeley 4.3 UNIX distribution tapes, it is no > longer feasible to track all X use and development.” > > > This X is not on the TUHS Unix tree website, nor on the CSRG disks. It > turns out that there is a directory “src/new” that is not included there. > It is here: > > http://www.retro11.de/ouxr/43bsd/usr/src/new/ > > The version of X included with 4.3BSD was X10. I assume this is the oldest > surviving X Window source code. > There's X10R3 and X10R4 at https://www.x.org/archive/X10R3/ and https://www.x.org/archive/X10R4/. On the FTP site, there's sym links for R1, R2, R3, R4, R5, R6, R6.1, R6.3, R6.4, R6.5.1, R6.6 and R6.8 in the pub directory as well, but they are dead links and correspond to the X11 releases that are also there, not X1, etc. The X10R3 is from Feb 2, 1986. X10R4 is from December 2, 1986. The retro11.de files are from June 1986, so are no later than X10R4, and most likely either X10R3 or an internal snapshot (I've not downloaded them both to run a diff to see which). Google searches for X9, X8, etc aren't at all helpful. Of course the source code for the Blit has survived, as has the source code > of MGR. The source code for Sunwindows and NeWS is presumably lost? > When I was a Solbroune, we started the OI toolkit with pdb, swm, uib, etc because Sun refused to license the source code to SunView. Although I had easy access to SunOS (which I wish I'd saved a copy of now), the SunView code was never in the building. It was relatively easy to get SunOS sources for a fee, but much harder for SunView. So I'm less than completely hopeful here. And NeWS was a fringe thing with a significantly shorter product life, so I'm even less hopeful there. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sat Jan 28 03:37:52 2023 From: imp at bsdimp.com (Warner Losh) Date: Fri, 27 Jan 2023 10:37:52 -0700 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: References: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl> <0778FF74-7DF5-4072-95F3-5FF5BEB4CC33@planet.nl> Message-ID: On Fri, Jan 27, 2023 at 10:36 AM Warner Losh wrote: > > > On Fri, Jan 27, 2023 at 10:16 AM Paul Ruizendaal via TUHS > wrote: > >> >> On Jan 27, 2023, at 1:19 AM, Paul Ruizendaal wrote: >> >> The version of X discussed in the paper was apparently part of the 4.3BSD >> distribution tapes: >> >> "The use of X has grown far beyond anything we had imagined. Digital has >> incorporated X into a commercial product, and other manufacturers are >> following suit. With the appearance of such products and the release of >> complete X sources on the Berkeley 4.3 UNIX distribution tapes, it is no >> longer feasible to track all X use and development.” >> >> >> This X is not on the TUHS Unix tree website, nor on the CSRG disks. It >> turns out that there is a directory “src/new” that is not included there. >> It is here: >> >> http://www.retro11.de/ouxr/43bsd/usr/src/new/ >> >> The version of X included with 4.3BSD was X10. I assume this is the >> oldest surviving X Window source code. >> > > There's X10R3 and X10R4 at https://www.x.org/archive/X10R3/ and > https://www.x.org/archive/X10R4/. On the FTP site, there's sym links for > R1, R2, R3, R4, R5, R6, R6.1, R6.3, R6.4, R6.5.1, R6.6 and R6.8 in the pub > directory as well, but they are dead links and correspond to the X11 > releases that are also there, not X1, etc. > > The X10R3 is from Feb 2, 1986. X10R4 is from December 2, 1986. The > retro11.de files are from June 1986, so > are no later than X10R4, and most likely either X10R3 or an internal > snapshot (I've not downloaded them both > to run a diff to see which). > > Google searches for X9, X8, etc aren't at all helpful. > Also interesting to note is that X10 had clu bindings in the CLUlib directory... > Of course the source code for the Blit has survived, as has the source >> code of MGR. The source code for Sunwindows and NeWS is presumably lost? >> > > When I was a Solbroune, we started the OI toolkit with pdb, swm, uib, etc > because Sun refused to license the source code to SunView. Although I had > easy access to SunOS (which I wish I'd saved a copy of now), the SunView > code was never in the building. It was relatively easy to get SunOS sources > for a fee, but much harder for SunView. So I'm less than completely hopeful > here. And NeWS was a fringe thing with a significantly shorter product > life, so I'm even less hopeful there. > > Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sat Jan 28 03:39:29 2023 From: tuhs at tuhs.org (Tom Ivar Helbekkmo via TUHS) Date: Fri, 27 Jan 2023 18:39:29 +0100 Subject: [TUHS] [off-topic] Anyone still using USENET? In-Reply-To: <202301270853.30R8rif6014271@freefriends.org> (arnold@skeeve.com's message of "Fri, 27 Jan 2023 01:53:44 -0700") References: <202301270853.30R8rif6014271@freefriends.org> Message-ID: arnold at skeeve.com writes: > If anyone has suggestions for a good free NNTP server, please let me > know. Not free, but very cheap: I use news.individual.net, run by the Freie Universität Berlin, where the subscription fee is a mere 10 euros/year. -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 henry at henare.com Sat Jan 28 03:42:43 2023 From: henry at henare.com (Henry Mensch) Date: Fri, 27 Jan 2023 12:42:43 -0500 Subject: [TUHS] [off-topic] Anyone still using USENET? In-Reply-To: References: <202301270853.30R8rif6014271@freefriends.org> Message-ID: <086b01d93276$c3982c80$4ac88580$@henare.com> I'd like to find solid Android and Windows clients so I could once again use USENET. The web interfaces I've seen have been pretty awful for the way I want to use it. - Henry -----Original Message----- From: Tom Ivar Helbekkmo via TUHS Sent: 27 January 2023 12:39 To: arnold at skeeve.com Cc: TUHS at tuhs.org Subject: [TUHS] Re: [off-topic] Anyone still using USENET? arnold at skeeve.com writes: > If anyone has suggestions for a good free NNTP server, please let me > know. Not free, but very cheap: I use news.individual.net, run by the Freie Universität Berlin, where the subscription fee is a mere 10 euros/year. -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 joshnatis0 at gmail.com Sat Jan 28 03:43:09 2023 From: joshnatis0 at gmail.com (josh) Date: Fri, 27 Jan 2023 12:43:09 -0500 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: References: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl> <0778FF74-7DF5-4072-95F3-5FF5BEB4CC33@planet.nl> Message-ID: On Friday, January 27, 2023, Paul Ruizendaal via TUHS wrote: > > Of course the source code for the Blit has survived, as has the source > code of MGR. The source code for Sunwindows and NeWS is presumably lost? > Arnold Robbins linked to this repository in a previous thread, it seems to have some NeWS-related source: https://github.com/IanDarwin/OpenLookCDROM -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Sat Jan 28 03:45:18 2023 From: rich.salz at gmail.com (Rich Salz) Date: Fri, 27 Jan 2023 12:45:18 -0500 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: References: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl> <0778FF74-7DF5-4072-95F3-5FF5BEB4CC33@planet.nl> Message-ID: > Also interesting to note is that X10 had clu bindings in the CLUlib directory... I'd like to know what the first versions of X were written in; the notice talks about CLU bindings exist and C coming soon. The app-side seems reasonable, but what was the display engine written in? (I took the CLU class around 1980.) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Fri Jan 27 14:49:53 2023 From: tytso at mit.edu (Theodore Ts'o) Date: Thu, 26 Jan 2023 23:49:53 -0500 Subject: [TUHS] Setting up an X Development Environment for Mac OS In-Reply-To: References: <3e272d72-b77a-d347-b5c3-7ed19482e5af@gmail.com> <3h5FEAegoTs6FrhHODiW-rBdB59dt_Rmr4G0PIw7flqaJLsmorgPsilm4f2aJkDud-qEljDjnCJcE1uY05Iw4HNQcyNG4W3wzVlLD0UZfLg=@protonmail.com> Message-ID: On Wed, Jan 25, 2023 at 03:04:27PM -0500, Dan Cross wrote: > On Wed, Jan 25, 2023 at 2:54 PM Theodore Ts'o wrote: > >[snip] > > The VAX 750's were huge time-sharing systems that you could connect to > > via VT-100's and VS-100 that were hard-wired to the VAX 750's, and > > telnet from IBM PC/AT's. The smaller clusters used PC/AT's because > > they were more flexible as to which 750 you were connecting to; > > otherwise, undergraduates had to go to the right terminal room in the > > right part of campus to connect to the Vax 750 that you were assgined > > to based on the starting character of your last name. (And graduate > > students initially didn't have access to Project Athena at all; > > although if you were in EECS, LCS or the AI Lab you had access to > > dedicated systems, of course.) > > Was this before the introduction of DECserver terminal concentrators? I'm not sure; this would have been in the 1985--1987 time frame. > >[snip] > > There was a brief, shining moment that we were standardized on > > BSD-derived Unix systems, but then IBM turned down AOS (the "academic" > > operating system), and we were forced to use AIX on the IBM RT's, with > > all that this implied: SMIT, and other horrors. > > Huh, I thought that AOS ran on all versions of the RT? I know they > dropped support for it when the power-based RS/6000s came out and > replaced the RT, though. Well, it perhaps would have been more accurate that IBM had decided to that AIX was the future, and had defunded the AOS group. While AOS may have continued to work on the IBM RT's, the Powers That Be at IBM had decided that AIX was the future, and when the company which is sending you $5 million dollars a year (half in hardware and engineers' salaries, and half in cold hard cash) wants you to switch to AIX, you salute and reinstall AIX on all of the IBM RT's.... Later on we did get the RS/6000's, but at that point, most of us who wanted something... that wasn't AIX, would try to get the VAXstation 3100 and later, the M38 variant. My first staff workstation at MIT was a VS-3100 named rt-11.mit.edu, and the VS-3100 M38 was tsx-11.mit.edu, which became the first FTP site for Linux in North America in 1991. (I'm not sure how many people realized that the primary ftp server for Linux was named after an obscure time-sharing OS built on top of RT-11 for the PDP-11. :-) > The RT was a weird duck, for sure. Well, there were the jokes that the RT was an overgrown typewriter controller with pretensions. :-) And it's floating-point performance was crap, but if you were only doing integer operations (e.g., running TeX, running compiles), it wasn't half-bad if it wasn't running AIX. > Compared to a SPARCstation it was > absurdly slow, but I guess compared to a uVAX perhaps not so much. Alas, Sun wasn't one of Project Athena's sponsors; just IBM and DEC. It also didn't help that our contemporaneous uVax's were mostly the VS II/RC's, with the the epoxyed backplane which limited the amount of amount of memory that could be put in them.... - Ted From imp at bsdimp.com Sat Jan 28 03:54:33 2023 From: imp at bsdimp.com (Warner Losh) Date: Fri, 27 Jan 2023 10:54:33 -0700 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: References: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl> <0778FF74-7DF5-4072-95F3-5FF5BEB4CC33@planet.nl> Message-ID: On Fri, Jan 27, 2023 at 10:45 AM Rich Salz wrote: > > > Also interesting to note is that X10 had clu bindings in the > CLUlib directory... > > I'd like to know what the first versions of X were written in; the notice > talks about CLU bindings exist and C coming soon. The app-side seems > reasonable, but what was the display engine written in? (I took the CLU > class around 1980.) > I wrote ~500-1000 lines of CLU in a computer language survey course in 1986... Without the earlier versions' source, it's hard to answer this question... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry at henare.com Sat Jan 28 04:05:46 2023 From: henry at henare.com (Henry Mensch) Date: Fri, 27 Jan 2023 13:05:46 -0500 Subject: [TUHS] Setting up an X Development Environment for Mac OS In-Reply-To: References: <3e272d72-b77a-d347-b5c3-7ed19482e5af@gmail.com> <3h5FEAegoTs6FrhHODiW-rBdB59dt_Rmr4G0PIw7flqaJLsmorgPsilm4f2aJkDud-qEljDjnCJcE1uY05Iw4HNQcyNG4W3wzVlLD0UZfLg=@protonmail.com> Message-ID: <08b201d93279$fbb2a200$f317e600$@henare.com> This was certainly true before 1986; I joined Project Athena in April of 1986 and this was quite well established by then. And it was no real surprise when IBM killed off AOS. AIX was already "product" and there was no commercially installed base for RT/PC systems worth mentioning ... (part of my job at the time was to identify and document the differences) -----Original Message----- From: Theodore Ts'o Sent: 26 January 2023 23:50 To: Dan Cross Cc: segaloco ; TUHS main list Subject: [TUHS] Re: Setting up an X Development Environment for Mac OS On Wed, Jan 25, 2023 at 03:04:27PM -0500, Dan Cross wrote: > On Wed, Jan 25, 2023 at 2:54 PM Theodore Ts'o wrote: > >[snip] > > otherwise, undergraduates had to go to the right terminal room > >in the right part of campus to connect to the Vax 750 that you were > >assgined to based on the starting character of your last name. I'm not sure; this would have been in the 1985--1987 time frame. -snip- Well, it perhaps would have been more accurate that IBM had decided to that AIX was the future, and had defunded the AOS group. From sauer at technologists.com Sat Jan 28 04:24:36 2023 From: sauer at technologists.com (Charles H Sauer (he/him)) Date: Fri, 27 Jan 2023 12:24:36 -0600 Subject: [TUHS] Setting up an X Development Environment for Mac OS In-Reply-To: <08b201d93279$fbb2a200$f317e600$@henare.com> References: <3e272d72-b77a-d347-b5c3-7ed19482e5af@gmail.com> <3h5FEAegoTs6FrhHODiW-rBdB59dt_Rmr4G0PIw7flqaJLsmorgPsilm4f2aJkDud-qEljDjnCJcE1uY05Iw4HNQcyNG4W3wzVlLD0UZfLg=@protonmail.com> <08b201d93279$fbb2a200$f317e600$@henare.com> Message-ID: The decision to end AOS was made sometime in 1H88 and the group of us that defined the "convergence" was formed. Our work must have been largely complete when I presented our plans at Berkeley 11/88 at a workshop that coincided with the Morris worm. I assume we submitted the Uniforum 89 paper (https://technologists.com/sauer/Convergence_of_AIX_and_4.3BSD.pdf) about then, as well. On 1/27/2023 12:05 PM, Henry Mensch wrote: > This was certainly true before 1986; I joined Project Athena in April of > 1986 and this was quite well established by then. > > And it was no real surprise when IBM killed off AOS. AIX was already > "product" and there was no commercially installed base for RT/PC systems > worth mentioning ... (part of my job at the time was to identify and > document the differences) > > -----Original Message----- > From: Theodore Ts'o > Sent: 26 January 2023 23:50 > To: Dan Cross > Cc: segaloco ; TUHS main list > Subject: [TUHS] Re: Setting up an X Development Environment for Mac OS > > On Wed, Jan 25, 2023 at 03:04:27PM -0500, Dan Cross wrote: >> On Wed, Jan 25, 2023 at 2:54 PM Theodore Ts'o wrote: >>> [snip] >>> otherwise, undergraduates had to go to the right terminal room >>> in the right part of campus to connect to the Vax 750 that you were >>> assgined to based on the starting character of your last name. > > I'm not sure; this would have been in the 1985--1987 time frame. > -snip- > Well, it perhaps would have been more accurate that IBM had decided to that > AIX was the future, and had defunded the AOS group. > > -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/Twitter: CharlesHSauer From stuff at riddermarkfarm.ca Sat Jan 28 05:23:18 2023 From: stuff at riddermarkfarm.ca (Stuff Received) Date: Fri, 27 Jan 2023 14:23:18 -0500 Subject: [TUHS] [off-topic] Anyone still using USENET? In-Reply-To: <086b01d93276$c3982c80$4ac88580$@henare.com> References: <202301270853.30R8rif6014271@freefriends.org> <086b01d93276$c3982c80$4ac88580$@henare.com> Message-ID: <2e22ed63-3817-cd91-3f1b-cf169eb83230@riddermarkfarm.ca> On 2023-01-27 12:42, Henry Mensch wrote (in part): > I'd like to find solid Android and Windows clients so I could once again use USENET. I read USENET (at Newsdemon -- USD3 monthly) with Firefox (on MacOS) but presumably will also work on Windows. N. (We seem to have strayed into COFF territory...) From tom.perrine+tuhs at gmail.com Sat Jan 28 07:42:17 2023 From: tom.perrine+tuhs at gmail.com (Tom Perrine) Date: Fri, 27 Jan 2023 13:42:17 -0800 Subject: [TUHS] Setting up an X Development Environment for Mac OS In-Reply-To: References: <20230125203805.4762218C083@mercury.lcs.mit.edu> <7w8rhpdczd.fsf@junk.nocrew.org> <20230126105626.72CD922168@orac.inputplus.co.uk> <20230127135651.A70482135B@orac.inputplus.co.uk> Message-ID: A tiny bit of a fork, but... When I was at SDSC.EDU we did a project for the National Archives. Gotta love an agency that's mission is "data for the lifetime of the Republic"... They wanted to be sure that they could still access data at least 100 years later, even assuming that no one had accessed it in that 100 year period. Anyway, we looked at all the options at the time (very early 2000s). While media lifetime was indeed understood to be critical, we specifically called out needing to retain the software and the encryption keys. AND the encryption algorithms! At that time, media encryption was still quite new, and they hadn't considered that issue. At all. Overall, the best, most practical approach (at that time) was to periodically copy the data forward, into new media, into new storage software, and decrypting with the old keys and algos, and re-encrypting with new. Only by doing this periodically, we argued, could they really be sure of being able to recover data 100+ years from now. Don't get me started on the degradation of early generation optical media that was guaranteed for 50 years, but rusted internally within 2 years. And of course now there are companies that specialize in providing mothballed obsolete tape and other readers. --tep On Fri, Jan 27, 2023 at 6:55 AM Ron Natalie wrote: > When I worked in the intelligience industry, the government spent a lot > of money tasking someone (I think it was Kodak) to determine the best > media for archival storage. It included traditional 6250 9 track > tapes and the then-popular exabyte 8mm (which was atrociously short > lived). I pointed out that magnetic storage was probably always going > to be problematic and things needed “digital refresh” if you really > wanted to keep them. > > > If you know the tape may be problematic when played back, there are > things you can do. I was gifted the master tapes of one of the radio > shows originated at WJHU in the 70’s. I had them sent out to a company > who “baked” them, but then they also had to redo all the splices on them > when they were played back. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.bowling at kev009.com Sat Jan 28 10:23:52 2023 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Fri, 27 Jan 2023 17:23:52 -0700 Subject: [TUHS] [off-topic] Anyone still using USENET? In-Reply-To: <202301270853.30R8rif6014271@freefriends.org> References: <202301270853.30R8rif6014271@freefriends.org> Message-ID: On Fri, Jan 27, 2023 at 1:54 AM wrote: > Hi. > > I've been using trn for decades to read a very few USENET groups. Until > recently I've > been using aioe.org as my NNTP server but it seems to have gone dark. > Before that > I used eternal-september.org, but when I try that I now get: > > | $ NNTPSERVER=news.eternal-september.org trn > | Connecting to news.eternal-september.org...Done. > | > | Invalid (bogus) newsgroup found: comp.sys.3b1 > | > | Invalid (bogus) newsgroup found: comp.sources.bugs > | > | Invalid (bogus) newsgroup found: comp.misc > | > | Invalid (bogus) newsgroup found: comp.compilers > | .... > > And those all are (or were!) valid groups. If anyone has suggestions for a > good > free NNTP server, please let me know. Privately is fine. I'm at a bit of > a loss otherwise. > I maintain inn and some related ports for FreeBSD. I run a public server at csiph.com and am happy to provide accounts or peering to interested parties. Read access is open. > Thanks, > > Arnold > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sat Jan 28 12:18:41 2023 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 27 Jan 2023 18:18:41 -0800 Subject: [TUHS] Setting up an X Development Environment for Mac OS In-Reply-To: References: <20230125203805.4762218C083@mercury.lcs.mit.edu> <7w8rhpdczd.fsf@junk.nocrew.org> <20230126105626.72CD922168@orac.inputplus.co.uk> <20230127135651.A70482135B@orac.inputplus.co.uk> Message-ID: <20230128021841.GG15592@mcvoy.com> Actually I like this fork. I'm curious, do you know what is best practice for keeping bits around these days? On Fri, Jan 27, 2023 at 01:42:17PM -0800, Tom Perrine wrote: > A tiny bit of a fork, but... > > When I was at SDSC.EDU we did a project for the National Archives. Gotta > love an agency that's mission is "data for the lifetime of the Republic"... > > They wanted to be sure that they could still access data at least 100 years > later, even assuming that no one had accessed it in that 100 year period. > > Anyway, we looked at all the options at the time (very early 2000s). > > While media lifetime was indeed understood to be critical, we specifically > called out needing to retain the software and the encryption keys. AND the > encryption algorithms! > At that time, media encryption was still quite new, and they hadn't > considered that issue. At all. > > Overall, the best, most practical approach (at that time) was to > periodically copy the data forward, into new media, into new > storage software, and decrypting with the old keys and algos, and > re-encrypting with new. > > Only by doing this periodically, we argued, could they really be sure of > being able to recover data 100+ years from now. > > Don't get me started on the degradation of early generation optical media > that was guaranteed for 50 years, but rusted internally within 2 years. > > And of course now there are companies that specialize in providing > mothballed obsolete tape and other readers. > > --tep > > > > On Fri, Jan 27, 2023 at 6:55 AM Ron Natalie wrote: > > > When I worked in the intelligience industry, the government spent a lot > > of money tasking someone (I think it was Kodak) to determine the best > > media for archival storage. It included traditional 6250 9 track > > tapes and the then-popular exabyte 8mm (which was atrociously short > > lived). I pointed out that magnetic storage was probably always going > > to be problematic and things needed ???digital refresh??? if you really > > wanted to keep them. > > > > > > If you know the tape may be problematic when played back, there are > > things you can do. I was gifted the master tapes of one of the radio > > shows originated at WJHU in the 70???s. I had them sent out to a company > > who ???baked??? them, but then they also had to redo all the splices on them > > when they were played back. > > -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tom.perrine+tuhs at gmail.com Sat Jan 28 12:49:43 2023 From: tom.perrine+tuhs at gmail.com (Tom Perrine) Date: Fri, 27 Jan 2023 18:49:43 -0800 Subject: [TUHS] Setting up an X Development Environment for Mac OS In-Reply-To: <20230128021841.GG15592@mcvoy.com> References: <20230125203805.4762218C083@mercury.lcs.mit.edu> <7w8rhpdczd.fsf@junk.nocrew.org> <20230126105626.72CD922168@orac.inputplus.co.uk> <20230127135651.A70482135B@orac.inputplus.co.uk> <20230128021841.GG15592@mcvoy.com> Message-ID: At that time (up to 2003), every time we upgraded the tape density, or added new archival storage, there was a "packing" job in the background. Every time a file was retrieved and used, if it wasn't on the most dense (newer) tape format, then the file was re-saved onto the newest, higher-density tape. This meant that active files were constantly copied forward onto the newer tape formats. As all the files were copied off the lower density tapes, the older tapes were marked "retired" and removed from the tape silos. Then, in the background, idle tape drive time was used by a background job that retrieved the oldest tapes, and copied the files on that tape forward. This was enable by tape-level metadata that included the batch number and the date that every physical tape was put into service. Now.... Later, at Playstation we investigated the Sony ODA. If we had needed the deep archive, we would have definitely gone with the Sony Petascale archive. This is optical, but a disc technology that is denser and a different formulation than Blu-Ray. https://pro.sony/ue_US/products/optical-disc/petasite-solutions On Fri, Jan 27, 2023 at 6:18 PM Larry McVoy wrote: > Actually I like this fork. I'm curious, do you know what is best practice > for keeping bits around these days? > > On Fri, Jan 27, 2023 at 01:42:17PM -0800, Tom Perrine wrote: > > A tiny bit of a fork, but... > > > > When I was at SDSC.EDU we did a project for the National Archives. Gotta > > love an agency that's mission is "data for the lifetime of the > Republic"... > > > > They wanted to be sure that they could still access data at least 100 > years > > later, even assuming that no one had accessed it in that 100 year period. > > > > Anyway, we looked at all the options at the time (very early 2000s). > > > > While media lifetime was indeed understood to be critical, we > specifically > > called out needing to retain the software and the encryption keys. AND > the > > encryption algorithms! > > At that time, media encryption was still quite new, and they hadn't > > considered that issue. At all. > > > > Overall, the best, most practical approach (at that time) was to > > periodically copy the data forward, into new media, into new > > storage software, and decrypting with the old keys and algos, and > > re-encrypting with new. > > > > Only by doing this periodically, we argued, could they really be sure of > > being able to recover data 100+ years from now. > > > > Don't get me started on the degradation of early generation optical media > > that was guaranteed for 50 years, but rusted internally within 2 years. > > > > And of course now there are companies that specialize in providing > > mothballed obsolete tape and other readers. > > > > --tep > > > > > > > > On Fri, Jan 27, 2023 at 6:55 AM Ron Natalie wrote: > > > > > When I worked in the intelligience industry, the government spent a lot > > > of money tasking someone (I think it was Kodak) to determine the best > > > media for archival storage. It included traditional 6250 9 track > > > tapes and the then-popular exabyte 8mm (which was atrociously short > > > lived). I pointed out that magnetic storage was probably always going > > > to be problematic and things needed ???digital refresh??? if you really > > > wanted to keep them. > > > > > > > > > If you know the tape may be problematic when played back, there are > > > things you can do. I was gifted the master tapes of one of the radio > > > shows originated at WJHU in the 70???s. I had them sent out to a > company > > > who ???baked??? them, but then they also had to redo all the splices > on them > > > when they were played back. > > > > > -- > --- > Larry McVoy Retired to fishing > http://www.mcvoy.com/lm/boat > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Sat Jan 28 19:14:06 2023 From: lars at nocrew.org (Lars Brinkhoff) Date: Sat, 28 Jan 2023 09:14:06 +0000 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: (Warner Losh's message of "Fri, 27 Jan 2023 10:54:33 -0700") References: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl> <0778FF74-7DF5-4072-95F3-5FF5BEB4CC33@planet.nl> Message-ID: <7wpmaz9g2p.fsf@junk.nocrew.org> Warner Losh wrote: > Rich Salz wrote: >> I'd like to know what the first versions of X were written in > > Without the earlier versions' source, it's hard to answer this question... V source code exists, right? It seems likely W would have been written in the same language as W. And that early X would also be the same. Another source of information would be to ask Bob Scheifler and Jim Gettys. From steve at quintile.net Sat Jan 28 20:12:15 2023 From: steve at quintile.net (Steve Simon) Date: Sat, 28 Jan 2023 10:12:15 +0000 Subject: [TUHS] reading historic magnetic tapes Message-ID: <6778F07B-DD74-4F04-A877-7D3751E96317@quintile.net> i worked for some years on video and film archive restoration. baking old, badly stored magnetic tapes prior to reading them is a common practice. my favourite was a story of a rock band (i think the stones) who wanted to play an old 24 track master tape but discovered it seemed to be stuck together. there is a nasty affliction of mag tapes called sticky vinegar syndrome, so they did the right thing and sent a section of tape for analysis. the results came back: the tape had suffered impregnation with “vodka and coke”. some things never change. -Steve From akosela at andykosela.com Sat Jan 28 20:15:12 2023 From: akosela at andykosela.com (Andy Kosela) Date: Sat, 28 Jan 2023 11:15:12 +0100 Subject: [TUHS] [off-topic] Anyone still using USENET? In-Reply-To: References: <202301270853.30R8rif6014271@freefriends.org> Message-ID: On Saturday, January 28, 2023, Kevin Bowling wrote: > > > On Fri, Jan 27, 2023 at 1:54 AM wrote: > >> Hi. >> >> I've been using trn for decades to read a very few USENET groups. Until >> recently I've >> been using aioe.org as my NNTP server but it seems to have gone dark. >> Before that >> I used eternal-september.org, but when I try that I now get: >> >> | $ NNTPSERVER=news.eternal-september.org trn >> | Connecting to news.eternal-september.org...Done. >> | >> | Invalid (bogus) newsgroup found: comp.sys.3b1 >> | >> | Invalid (bogus) newsgroup found: comp.sources.bugs >> | >> | Invalid (bogus) newsgroup found: comp.misc >> | >> | Invalid (bogus) newsgroup found: comp.compilers >> | .... >> >> And those all are (or were!) valid groups. If anyone has suggestions for >> a good >> free NNTP server, please let me know. Privately is fine. I'm at a bit of >> a loss otherwise. >> > > I maintain inn and some related ports for FreeBSD. I run a public server > at csiph.com and am happy to provide accounts or peering to interested > parties. Read access is open. > >> >> Great initiative and idea! While I am personally not interested in reading USENET that much nowadays, the concept of providing free, public access to classic Internet services (public USENET, FTP, IRC, finger, etc.) gets all my praise. What happened to free, public services these days? Everything appears to to be subscriber pay-as-you-go based. The commercialization killed the free spirit of Internet we all loved in the 90s. PS> And I also love the layout of your website. Plain HTML with no fancy css, js bloat; classic colors with white background. I miss it on the Internet. These modern color themes with dark backrounds is getting harder and harder to read and is just awful if you ask me. --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Sat Jan 28 21:05:51 2023 From: pnr at planet.nl (Paul Ruizendaal) Date: Sat, 28 Jan 2023 12:05:51 +0100 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: <7wpmaz9g2p.fsf@junk.nocrew.org> References: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl> <0778FF74-7DF5-4072-95F3-5FF5BEB4CC33@planet.nl> <7wpmaz9g2p.fsf@junk.nocrew.org> Message-ID: <697E8876-C2A9-4FE6-A2F7-B4DCEC3BA2C7@planet.nl> > On 28 Jan 2023, at 10:14, Lars Brinkhoff wrote: > > Warner Losh wrote: >> Rich Salz wrote: >>> I'd like to know what the first versions of X were written in >> >> Without the earlier versions' source, it's hard to answer this question... > > V source code exists, right? It seems likely W would have been written > in the same language as W. And that early X would also be the same. > Another source of information would be to ask Bob Scheifler and Jim > Gettys. Whilst that is a reasonable assumption, I’m not sure it is true in this case. Bob Scheifler writes in 1986: "We acquired a UNIX-based version of W for the VSlOO (with synchronous communication over TCP [24] produced by Asente and Chris Kent at Digital’s Western Research Laboratory.” It does not say “C based”, but it is quite possible that the Unix port also meant moving to C. Also, the work started in June 1984 and had gone to version 10, release 3 by February 1986. That is 12 versions in 20 months. Most likely X1-X10R2 are all snapshots done in rapid succession. The change notes for X10R3 read as describing a work still in progress: http://www.retro11.de/ouxr/43bsd/usr/src/new/X/CHANGES That “work-in-progress” feel also shows in the Xterm README: "Xterm is in a reasonably usable state. We are sick and tired of working on it, but there are clearly major areas of improvement possible. Do not look to us to do more than integration work on other people's improvement. About 50% of it is the oldest existing code in the package and needing major rewrite. Our thanks to Bob McNamara for the 50% which is solid." The README for the X server itself (written in August 1985 it seems, http://www.retro11.de/ouxr/43bsd/usr/src/new/X/X/README) says: "The server has been completely rewritten several times now, and I am reasonably happy with it. I have fine-tuned it specifically for the current (sub-optimal) VAX compiler. For other machines, faster code may be obtained in some cases by changing sizes (e.g., to avoid indexing shifts on the 68000) or register declarations. Attempts to parameterize along these lines have only been made for the byte-swapping code.” So there were several rewrites from Summer 1984 till Summer 1985. In case the first version was in CLU, it would seem that the change-over to C happened in the very first months of the code base’s lifespan. The next paragraph as to the state of the code base at this time is revealing: Unfortunately, a great many invariants are not written down. Hopefully you will spend a few weeks understanding the code before you muck with it. If something seems easy to add or change, you probably forgot something important. Almost everything depends on everything else. It is almost impossible to devise rigorous test cases. Innocuous looking changes can have large performance effects, so watch out. If you muck with fundamental window components, a good cross-check is to see how quickly you can manipulate a window with, say, 100 non-adjacent subwindows. After reading the above, Jon Steinhart’s post from 5 years ago about X is all the more interesting: https://minnie.tuhs.org/pipermail/tuhs/2017-September/012089.html From will.senn at gmail.com Sun Jan 29 01:05:38 2023 From: will.senn at gmail.com (Will Senn) Date: Sat, 28 Jan 2023 09:05:38 -0600 Subject: [TUHS] tesseract has gotten so much better Message-ID: <245759ab-c8de-f616-8942-8d7d193a960a@gmail.com> Hi All, I just wanted to let y'all know that tesseract ocr has significantly improved and is much easier to use that it used to be. I have been using it with my workflow for a bit and it's crazy how much better it is than it was back when I  tried it last (admittedly 5-6 years ago). For those of you doing your own scans, or those of you finding sad little pdfs without ocr, the process is fairly simple. Let's say you find "The Master Manual of Fortran.pdf" out there in the wild (or scan it). Here's how to turn it into a glorious ocr'd version: Export your pdf as a multi-image tiff - it'll be ginormous, but you can delete it later (on Mac, this is just export from preview and select tiff, but gs will do it to, if I remember correctly) and then: tesseract The\ Master\ Manual\ of\ Fortran.tiff out -l eng PDF et voila, I nice, if large pdf, called out.pdf or somesuch will appear with ocr text that actually matches your scan (it seems to have caught up to adobe's ocr, or is quite close in my view, ymmv). I speak English, so I installed tesseract and tesseract-eng, but it supports a bunch of other languages if you need them. Apparently google's been supporting and developing it for while now and if my results are any indicator, it's paying off (boy do I remember all the gobbledegook it used to produce). tesseract will import from different image types, multiple images, etc. I just like the simplicity of tiff->pdf. Anyhow, thought y'all might like to know as many of you live off the scans :). Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sun Jan 29 01:38:55 2023 From: imp at bsdimp.com (Warner Losh) Date: Sat, 28 Jan 2023 08:38:55 -0700 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: <697E8876-C2A9-4FE6-A2F7-B4DCEC3BA2C7@planet.nl> References: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl> <0778FF74-7DF5-4072-95F3-5FF5BEB4CC33@planet.nl> <7wpmaz9g2p.fsf@junk.nocrew.org> <697E8876-C2A9-4FE6-A2F7-B4DCEC3BA2C7@planet.nl> Message-ID: On Sat, Jan 28, 2023, 4:05 AM Paul Ruizendaal wrote: > > > On 28 Jan 2023, at 10:14, Lars Brinkhoff wrote: > > > > Warner Losh wrote: > >> Rich Salz wrote: > >>> I'd like to know what the first versions of X were written in > >> > >> Without the earlier versions' source, it's hard to answer this > question... > > > > V source code exists, right? It seems likely W would have been written > > in the same language as W. And that early X would also be the same. > > Another source of information would be to ask Bob Scheifler and Jim > > Gettys. > > Whilst that is a reasonable assumption, I’m not sure it is true in this > case. Bob Scheifler writes in 1986: > > "We acquired a UNIX-based version of W for the VSlOO (with synchronous > communication over TCP [24] produced by Asente and Chris Kent at Digital’s > Western Research Laboratory.” > > It does not say “C based”, but it is quite possible that the Unix port > also meant moving to C. > > Also, the work started in June 1984 and had gone to version 10, release 3 > by February 1986. That is 12 versions in 20 months. Most likely X1-X10R2 > are all snapshots done in rapid succession. X11 is the 11th version of the wire protocol. They bumped that number each time there was a protocol change. It's not clear that all the early versions were distributed beyond the local network. The Xlib book stated something along these lines, but I can't find my copy to quote it or refresh my recollection. The change notes for X10R3 read as describing a work still in progress: > > http://www.retro11.de/ouxr/43bsd/usr/src/new/X/CHANGES > > That “work-in-progress” feel also shows in the Xterm README: > > "Xterm is in a reasonably usable state. We are sick and tired of working > on it, but there are clearly major areas of improvement possible. Do > not look to us to do more than integration work on other people's > improvement. About 50% of it is the oldest existing code in the package > and needing major rewrite. Our thanks to Bob McNamara for the 50% which > is solid." > Rolling releases were quite common. They went out of style for a while, but are back in vouge with CI.... The README for the X server itself (written in August 1985 it seems, > http://www.retro11.de/ouxr/43bsd/usr/src/new/X/X/README) says: > > "The server has been completely rewritten several times now, and I am > reasonably > happy with it. I have fine-tuned it specifically for the current > (sub-optimal) > VAX compiler. For other machines, faster code may be obtained in some > cases > by changing sizes (e.g., to avoid indexing shifts on the 68000) or register > declarations. Attempts to parameterize along these lines have only been > made > for the byte-swapping code.” > > So there were several rewrites from Summer 1984 till Summer 1985. In case > the first version was in CLU, it would seem that the change-over to C > happened in the very first months of the code base’s lifespan. > Most likely the CLU library bindings in X10R3 are a hold over from other software other departments were still using given the fast pace here... The next paragraph as to the state of the code base at this time is > revealing: > > Unfortunately, a great many invariants are not written down. Hopefully you > will spend a few weeks understanding the code before you muck with it. If > something seems easy to add or change, you probably forgot something > important. > Almost everything depends on everything else. It is almost impossible to > devise rigorous test cases. Innocuous looking changes can have large > performance effects, so watch out. If you muck with fundamental window > components, a good cross-check is to see how quickly you can manipulate a > window with, say, 100 non-adjacent subwindows. > > After reading the above, Jon Steinhart’s post from 5 years ago about X is > all the more interesting: > https://minnie.tuhs.org/pipermail/tuhs/2017-September/012089.html I'd forgotten about that... Warner > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Sun Jan 29 03:01:19 2023 From: cowan at ccil.org (John Cowan) Date: Sat, 28 Jan 2023 12:01:19 -0500 Subject: [TUHS] [off-topic] Anyone still using USENET? In-Reply-To: References: <202301270853.30R8rif6014271@freefriends.org> Message-ID: > > >>> Great initiative and idea! While I am personally not interested in > reading USENET that much nowadays, the concept of providing free, public > access to classic Internet services (public USENET, FTP, IRC, finger, etc.) > gets all my praise. What happened to free, public services these days? > Everything appears to to be subscriber pay-as-you-go based. The > commercialization killed the free spirit of Internet we all loved in the > 90s. > See tildeverse.org. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Sun Jan 29 04:50:58 2023 From: lars at nocrew.org (Lars Brinkhoff) Date: Sat, 28 Jan 2023 18:50:58 +0000 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: <697E8876-C2A9-4FE6-A2F7-B4DCEC3BA2C7@planet.nl> (Paul Ruizendaal's message of "Sat, 28 Jan 2023 12:05:51 +0100") References: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl> <0778FF74-7DF5-4072-95F3-5FF5BEB4CC33@planet.nl> <7wpmaz9g2p.fsf@junk.nocrew.org> <697E8876-C2A9-4FE6-A2F7-B4DCEC3BA2C7@planet.nl> Message-ID: <7wlelma3xp.fsf@junk.nocrew.org> Paul Ruizendaal wrote: >> V source code exists, right? It seems likely W would have been >> written in the same language as [V]. And that early X would also be >> the same. Another source of information would be to ask Bob >> Scheifler and Jim Gettys. > > Whilst that is a reasonable assumption, I’m not sure it is true in > this case. Bob Scheifler writes in 1986: > > "We acquired a UNIX-based version of W for the [VS1OO] (with > synchronous communication over TCP [24] produced by Asente and Chris > Kent at Digital’s Western Research Laboratory.” > > It does not say “C based”, but it is quite possible that the Unix port > also meant moving to C. I checked V, and it's written in C. From frew at ucsb.edu Sun Jan 29 05:29:05 2023 From: frew at ucsb.edu (James Frew) Date: Sat, 28 Jan 2023 11:29:05 -0800 Subject: [TUHS] reading historic magnetic tapes In-Reply-To: <6778F07B-DD74-4F04-A877-7D3751E96317@quintile.net> References: <6778F07B-DD74-4F04-A877-7D3751E96317@quintile.net> Message-ID: <1595e77d-697c-b2e8-5aff-fe63c92f4747@ucsb.edu> My "favorite" magtape story: In a former life I managed a university research lab whose main activity was analyzing digital imagery from Earth satellites, back when said imagery was distributed and locally archived on 9-track magtape. Most of the OGs on this list will recall that the standard way of storing said magtapes was on floor-to-ceiling racks that held the tapes by a hook on the plastic ring (the "seal")  around the edge of the tape. The story begins with a bunch of read errors showing up on some of the tapes. We quickly pinned it down to a specific sensor and range of dates, which of course led to a back-and-forth with NASA that didn't converge (other researchers were having no problems with identical data on tapes from the same batch, etc.) As I was leaving the lab late one evening during this mini-crisis, I had to walk around a custodian who was busy giving the linoleum floor in the hallway its annual deep cleaning / polishing. This involved a dingus with a large (~18" diameter) horizontal buffing wheel, atop which sat an enormous (like, a cylinder about as big around as a soccer ball) electric motor, sparking commutator clearly visible through the vents in the metal housing. I asked the custodian if he'd done the floors in our lab recently. "Sure, they did them last week" (on the graveyard shift, apparently, since nobody noticed.) Hmm. Back into the lab, and there were the offending tapes, all occupying the bottom row of the tape rack, right next to an extra-shiny linoleum floor. Indeed, the floor *underneath* the tapes was mostly polished---the helpful custodian apparently ran the motor right up against the hanging tapes, to get the buffer as far under as possible... Filed under "threats you never ever considered." /Frew From e5655f30a07f at ewoof.net Sun Jan 29 06:12:14 2023 From: e5655f30a07f at ewoof.net (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Sat, 28 Jan 2023 20:12:14 +0000 Subject: [TUHS] reading historic magnetic tapes In-Reply-To: <1595e77d-697c-b2e8-5aff-fe63c92f4747@ucsb.edu> References: <6778F07B-DD74-4F04-A877-7D3751E96317@quintile.net> <1595e77d-697c-b2e8-5aff-fe63c92f4747@ucsb.edu> Message-ID: <2c916808-5463-44a5-a89d-cc50e685631a@home.arpa> On 28 Jan 2023 11:29 -0800, from frew at ucsb.edu (James Frew): > As I was leaving the lab late one evening during this mini-crisis, I had to > walk around a custodian who was busy giving the linoleum floor in the > hallway its annual deep cleaning / polishing. This involved a dingus with a > large (~18" diameter) horizontal buffing wheel, atop which sat an enormous > (like, a cylinder about as big around as a soccer ball) electric motor, > sparking commutator clearly visible through the vents in the metal housing. This is probably more COFF than TUHS, but I recall a story from almost certainly much later where someone (I think it was a secretary; for now, let's pretend it was) had been told to change backup tapes daily and set the freshly taken backup aside for safekeeping. Then one day the storage failed and the backups were needed, only it turned out when trying to restore the backups that _every_ _single_ _tape_ was blank. Nobody, least of all the secretary, could explain how that could have happened, and eventually, the secretary was asked to demonstrate exactly what had been done every day. Turned out that while getting the replacement tape, the secretary put the freshly taken backup tape on a UPS, which apparently generated a strong magnetic field, before setting that tape aside. So the freshly taken backup tape was dutifully well and thoroughly erased. Nobody had mentioned the little detail of not putting the tape near the UPS. Oops. -- Michael Kjörling 🏡 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?” From douglas.mcilroy at dartmouth.edu Sun Jan 29 07:16:56 2023 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sat, 28 Jan 2023 16:16:56 -0500 Subject: [TUHS] =?utf-8?q?Collecting_notes_for_future_=E2=80=9Chistorians?= =?utf-8?q?=E2=80=9D_was=3A_Earliest_UNIX_Workstations=3F?= Message-ID: > * What do I really mean by workstation? Ex.gr. If an installation had a > PDP-11 with a single terminal and operator, is it not a workstation? Is it > the integration of display into the system that differentiates? Certainly integration is critical. The display should be integral to the terminal, not simply an available device. Without that stipulation Ken's original single-user PDP-7 system would count (unless, perhaps, the system had not yet been christened "Unix"). Doug From dave at horsfall.org Sun Jan 29 08:15:55 2023 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 29 Jan 2023 09:15:55 +1100 (EST) Subject: [TUHS] Setting up an X Development Environment for Mac OS In-Reply-To: <20230127161016.GF5393@mcvoy.com> References: <20230125203805.4762218C083@mercury.lcs.mit.edu> <7w8rhpdczd.fsf@junk.nocrew.org> <20230126105626.72CD922168@orac.inputplus.co.uk> <20230127135651.A70482135B@orac.inputplus.co.uk> <20230127161016.GF5393@mcvoy.com> Message-ID: On Fri, 27 Jan 2023, Larry McVoy wrote: [...] > I've never seen a more fragile system than those exabyte. By > comparison, the old SCSI QIC 150s, while small, were industructible, I > think you could have used the tapes as hammers and they'd still read. > Same thing for 9 track. My experience with Exabytes was different; we used "data" tapes, not the cheaper "video" tapes and had no problems over many years. In fact, in https://en.wikipedia.org/wiki/Data8 we see: ``The cassettes have the same dimensions and construction as the cassettes used in 8 mm video format recorders and camcorders.'' In other words, they are not the same thing... -- Dave From kevin.bowling at kev009.com Sun Jan 29 10:31:49 2023 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Sat, 28 Jan 2023 17:31:49 -0700 Subject: [TUHS] Setting up an X Development Environment for Mac OS In-Reply-To: References: <20230125203805.4762218C083@mercury.lcs.mit.edu> <7w8rhpdczd.fsf@junk.nocrew.org> <20230126105626.72CD922168@orac.inputplus.co.uk> <20230127135651.A70482135B@orac.inputplus.co.uk> <20230127161016.GF5393@mcvoy.com> Message-ID: I'm not sure about 8mm tape specifically but the Exabyte drives that were common on 1990s UNIX systems failed a lot. There was a large proliferation of tape technology in the 1980s and 1990s, many of them not great in any dimension. DLT, LTO, and especially the "enterprise" ranges from StorageTek or IBM from any time period are all extremely reliable. On Sat, Jan 28, 2023 at 3:16 PM Dave Horsfall wrote: > > On Fri, 27 Jan 2023, Larry McVoy wrote: > > [...] > > > I've never seen a more fragile system than those exabyte. By > > comparison, the old SCSI QIC 150s, while small, were industructible, I > > think you could have used the tapes as hammers and they'd still read. > > Same thing for 9 track. > > My experience with Exabytes was different; we used "data" tapes, not the > cheaper "video" tapes and had no problems over many years. > > In fact, in https://en.wikipedia.org/wiki/Data8 we see: > > ``The cassettes have the same dimensions and construction as the > cassettes used in 8 mm video format recorders and camcorders.'' > > In other words, they are not the same thing... > > -- Dave From lars at nocrew.org Sun Jan 29 16:48:17 2023 From: lars at nocrew.org (Lars Brinkhoff) Date: Sun, 29 Jan 2023 06:48:17 +0000 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: <7wpmaz9g2p.fsf@junk.nocrew.org> (Lars Brinkhoff's message of "Sat, 28 Jan 2023 09:14:06 +0000") References: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl> <0778FF74-7DF5-4072-95F3-5FF5BEB4CC33@planet.nl> <7wpmaz9g2p.fsf@junk.nocrew.org> Message-ID: <7wh6w9alam.fsf@junk.nocrew.org> >>> I'd like to know what the first versions of X were written in >> Without the earlier versions' source, it's hard to answer this question... > > V source code exists, right? It seems likely W would have been written > in the same language as W. And that early X would also be the same. > Another source of information would be to ask Bob Scheifler and Jim > Gettys. I asked Bob, and he says W was written in C. From arnold at skeeve.com Sun Jan 29 19:00:26 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 29 Jan 2023 02:00:26 -0700 Subject: [TUHS] [off-topic] Anyone still using USENET? In-Reply-To: References: <202301270853.30R8rif6014271@freefriends.org> Message-ID: <202301290900.30T90Q9b022673@freefriends.org> Tom Ivar Helbekkmo wrote: > arnold at skeeve.com writes: > > > If anyone has suggestions for a good free NNTP server, please let me > > know. > > Not free, but very cheap: I use news.individual.net, run by the Freie > Universität Berlin, where the subscription fee is a mere 10 euros/year. > > -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 Thanks for this, and thanks to everyone else who responded. Arnold From emu at e-bbes.com Sun Jan 29 21:07:27 2023 From: emu at e-bbes.com (emanuel stiebler) Date: Sun, 29 Jan 2023 06:07:27 -0500 Subject: [TUHS] Setting up an X Development Environment for Mac OS In-Reply-To: References: <20230125203805.4762218C083@mercury.lcs.mit.edu> <7w8rhpdczd.fsf@junk.nocrew.org> <20230126105626.72CD922168@orac.inputplus.co.uk> <20230127135651.A70482135B@orac.inputplus.co.uk> <20230127161016.GF5393@mcvoy.com> Message-ID: On 2023-01-28 19:31, Kevin Bowling wrote: > I'm not sure about 8mm tape specifically but the Exabyte drives that > were common on 1990s UNIX systems failed a lot. > > There was a large proliferation of tape technology in the 1980s and > 1990s, many of them not great in any dimension. > > DLT, LTO, and especially the "enterprise" ranges from StorageTek or > IBM from any time period are all extremely reliable. The problem with the 4mm and 8mm was, they had this stupid rotating head (heli scan?), which was a pain in the neck. It was difficult to adjust, so you better read/wrote your tapes only Put a lot of mechanical stress on the tape Tape was thin, to have more capacity After all, it was consumer stuff, ported to the wrong environment 9track, DLT work differently, that why we still have a chance to read them :) From imp at bsdimp.com Mon Jan 30 04:51:43 2023 From: imp at bsdimp.com (Warner Losh) Date: Sun, 29 Jan 2023 11:51:43 -0700 Subject: [TUHS] FD 2 In-Reply-To: References: Message-ID: On Sun, Jan 22, 2023 at 2:23 PM Warner Losh wrote: > > > On Sat, Jan 21, 2023 at 11:37 AM Warner Losh wrote: > >> >> Yea. Like many things, there was a transition... the most important bit >> is the shell. And that was more tricky to read through with the phone at >> breakfast... >> > > OK. I've dug a bit further and Clem and I have chatted... Here's the > summary. > > We don't have V4's shell, alas, since all we have from that time period is > the C kernel a few months before the 4th edition release. V5 /bin/sh closes > fd2 and then dups fd1 to fd2. This creates fd2 as something special. V6 > closes all FD's larger than 1 (2-15) and then does the dup(1) which it > makes sure returns 2 or it closes the file. While there were features in V6 > to allow use of fd2/stderr, few programs used then. > > And neither crypt nor passwd reads from fd2. crypt reads from fd0, while > passwd doesn't read. It just replaces the hashed password with the new > password. I've also looked at pr because > > >I do remember that pr -p actually read from FD 2. It probably still does. > > and that's not true in V7 at least... pr didn't have a 'p' arg :). Maybe > later programs started to do these things, but most of what went on with V7 > was a transition to most error messages on stderr, which typically went to > stdout in V6. > > So, people remembering it coming in with V7 are right, in the sense it was > the first release to do it consistently. And the people remembering V4 or > V5 are also right, in a different sense because the shell was ensuring fd2 > was a copy of fd1 there, which a couple of programs (diff) used for errors. > And I believe that the impetus for the V7 changes was phototypesetting > 'file not found' too often... But that last bit is mostly because I want > to believe. > One last historical footnote. In researching a forthcoming article for the 30th anniversary of FreeBSD, I noticed the following: https://www.bell-labs.com/usr/dmr/www/hist.pdf contains Dennis Ritchie's history of the early days of Unix. It was first published in 1979 (so right around the time V7 was being finalized), and revised/reprinted in the famous AT&T Bell Laboratories Technical Journal 63 No. 6 Part 2, October 1984 issue. He talks about FD 0 and FD 1 being special in the pdp-7 implementation on page 4: "The main loop of the shell went as follows: 1) The shell closed all its open files, then opened the terminal special file for standard input and output (file descriptors 0 and 1). ..." No mention is made of when fd 2 became standard error in this paper, which does mention a lot of other unix milestones (hierarchical notation for directories, fork/exec changes, pipes, etc), but not this one. > Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Mon Jan 30 05:20:43 2023 From: ron at ronnatalie.com (Ron Natalie) Date: Sun, 29 Jan 2023 19:20:43 +0000 Subject: [TUHS] FD 2 In-Reply-To: References: Message-ID: >"The main loop of the shell went as follows: >1) The shell closed all its open files, then opened the terminal >special file for standard input and output (file descriptors 0 and 1). > Unfortunately, the source code says otherwise. None of shells V6, PWB, V7 do anything like is mentioned above. They assume 0 and 1 (and 2) are already open. The only fd redirection they do is when you do pipes or redirection on the command line. Where this is done is, as I posted earlier, in /etc/init. Init opens the tty device and dups it to 1 and then invokes either the shell (if we're in single user mode) or getty for interactive mode. This was done in V6 and PWB (1). In V7, init added a second dup for file descriptor 2. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Mon Jan 30 05:39:54 2023 From: ron at ronnatalie.com (Ron Natalie) Date: Sun, 29 Jan 2023 19:39:54 +0000 Subject: [TUHS] File descriptor fun and games (setuid) Message-ID: Another of Ron’s historical diversions that came to mind. Most of you probably know of various exploits that can happen now with setuid programs, but this was pretty loose back in the early days. I was a budding system programmer back in 1979 at Johns Hopkins. Back then hacking the UNIX system was generally considered as sport by the students. The few of us who were on the admin side spent a lot of time figuring out how it had happened and running around fixing it. The first one found was the fact that the “su” program decided that if it couldn’t open /etc/passwd for some reason, things must be really bad and the invoker should be given a root shell anyhow. The common exploit would be to open all the available file descriptors (16 I think back then) and thus there wasn’t one available. That was fixed before my time at JHU (but I used it on other systems). One day one of the guys who was shuffling stuff back and forth between MiniUnix on a PDP-11/40 and our main 11/45 UNIX came to me with his RK05 file system corrupted. I found that the superblock was corrupted. With some painstaking comparison to another RK05 superblock, I reconstituded it enough to run icheck -s etc.. and get the thing back. What I had found was that the output of the “mount” command had been written on the superblock. WTF? I said, how did this happen. Interrogating the user yielded the fact that he decided he didn’t want to see the mount output so he closed file descriptor one prior to invoking mount. Still it seemed odd. At JHU we had lots of people with removable packs, so someone had modified mount to run setuid (with the provision of only allowing certain devices to be mounted certain places). At his point we had started with the idea of putting volume labels in the superblock to identify the pack being mounted. Rather than put the stuff in the kernel right away, Mike Muuss just hacked reading it from the super block in the usermode mount program so that he could put the volume label in /etc/mtab. Now you can probably see where this is headed. It opens up the disk, seeks to the pack label in the superblock and reads it (for somereason things were opened RW). Then the output goes to file descriptor 1 which just happens to be further in the superblock. I figured this out. Fixed it and told Mike about it. I told him there were probably other setuid programs around that had the problem and asked if it was OK if I hacked on things (at the time I yet was not trusted with the root password). He told me to go ahead, knock yourself out. Well I spent the evening closing various combinations of file descriptors and invoking setuid programs. I found a few more and noted them. After a while I got tired and went home. The next day I came in and looked through our paper logbook that we filled out anytime the machine was shutdown (or crashed). There was a note from two of the other system admins saying they had shut the system down to rebuild the accounting file (this was essentially the shadow password file and some additional per-user information not stored in /etc/passwd). The first 8 bytes were corrupted. Oh, I say, I think I might know how that happened. Yeah, we thought you might. Your user name was what was written over the root entry in the file. The passwd changing program was one of the ones I tested, but I hadn’t noticed any ill-effects for it at the time. -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Mon Jan 30 06:25:37 2023 From: imp at bsdimp.com (Warner Losh) Date: Sun, 29 Jan 2023 13:25:37 -0700 Subject: [TUHS] FD 2 In-Reply-To: References: Message-ID: On Sun, Jan 29, 2023, 12:21 PM Ron Natalie wrote: > > > > "The main loop of the shell went as follows: > 1) The shell closed all its open files, then opened the terminal special > file for standard input and output (file descriptors 0 and 1). > > Unfortunately, the source code says otherwise. None of shells V6, PWB, > V7 do anything like is mentioned above. They assume 0 and 1 (and 2) are > already open. > The only fd redirection they do is when you do pipes or redirection on the > command line. > This was in reference to the pdp-7 unix implementation. I didn't check the pdp7 version though. So what you said is true about the later versions for sure, starting with v5. Where this is done is, as I posted earlier, in /etc/init. Init opens the > tty device and dups it to 1 and then invokes either the shell (if we're in > single user mode) or getty for interactive mode. > This was done in V6 and PWB (1). In V7, init added a second dup for file > descriptor 2. > Yes. I quite enjoyed that. My surprise was Dennis' paper didn't mention the innovation since it was otherwise quote detailed. Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Mon Jan 30 06:39:11 2023 From: pnr at planet.nl (Paul Ruizendaal) Date: Sun, 29 Jan 2023 21:39:11 +0100 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: <7wh6w9alam.fsf@junk.nocrew.org> References: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl> <0778FF74-7DF5-4072-95F3-5FF5BEB4CC33@planet.nl> <7wpmaz9g2p.fsf@junk.nocrew.org> <7wh6w9alam.fsf@junk.nocrew.org> Message-ID: <34B2F3A7-B2A2-4597-8181-6A291CE3BEB1@planet.nl> > On 29 Jan 2023, at 07:48, Lars Brinkhoff wrote: > >>>> I'd like to know what the first versions of X were written in >>> Without the earlier versions' source, it's hard to answer this question... >> >> V source code exists, right? It seems likely W would have been written >> in the same language as W. And that early X would also be the same. >> Another source of information would be to ask Bob Scheifler and Jim >> Gettys. > > I asked Bob, and he says W was written in C. Thank you! In the meantime I have also found the thesis of William Nowicki, the author of VGTS: https://apps.dtic.mil/sti/pdfs/ADA166935.pdf It has a timeline for VGTS in its appendix C. In short, development begins in 1982 as a carve out of the display routines of a VLSI design package. It seems to have become usable in 1983 and development continued into 1984 (Nowicki graduated in March 1985). This places the development of W in 1983 (before that VGTS did not exist, and by early ’84 a Unix version existed). This https://apps.dtic.mil/sti/pdfs/ADA231239.pdf document from 1990 claims: "The X Window System has a very alphabetical lineage. The family originated at Stanford University as the VGTS, or V system, a primitive networked graphics windowing system. Then Digital Electronic Corporation desired a more advanced version of V and worked with Stanford University to develop W. Because of the needs of a networking and windowing project sponsored by IBM at the Massachusetts Institute of Technology, MIT acquired the W system and greatly improved its networking capabilities.” The above seems not quite accurate: besides the V / VGTS mixup, Scheifer writes that W was more a simplification rather than an extension of VGTS: "VGTS provides graphics windows driven by fairly high-level object definitions from a structured display file; W provides graphics windows based on a simple display-list mechanism, with limited functionality. We acquired a UNIX-based version of W for the VSlOO (with synchronous communication over TCP produced by [Paul] Asente and Chris Kent at Digital’s Western Research Laboratory.” However, the links with DEC that these paragraphs make are interesting. There is this blog post from Bryan Lunduke (https://lunduke.substack.com/p/w-the-window-system-before-x-that) makes a link between the W window system and DEC’s 1984 "VAXstation Display System Software”. It is possible that these two pieces of software are in fact closely related. From david at kdbarto.org Mon Jan 30 07:59:04 2023 From: david at kdbarto.org (David Barto) Date: Sun, 29 Jan 2023 13:59:04 -0800 Subject: [TUHS] I've just come across some old Unix Sources Message-ID: Notably: 32v_usr.tar.gz and sys3.tar.gz. I’ve not unpacked the tar files. If someone would like more detail about the contents I’ll produce a TOC offline for them. David From bakul at iitbombay.org Mon Jan 30 08:57:56 2023 From: bakul at iitbombay.org (Bakul Shah) Date: Sun, 29 Jan 2023 14:57:56 -0800 Subject: [TUHS] File descriptor fun and games (setuid) In-Reply-To: References: Message-ID: <2D760346-E44F-4248-9122-19A5E4EDA42D@iitbombay.org> Sorry for nitpicking but I don't understand why closing fd 1 *before* calling mount result in this behavior? Shouldn't a write(1, ...) just fail? Anyway, this sounds like a classic case of "the confused deputy". http://www.cap-lore.com/CapTheory/ConfusedDeputy.html Of course, a tighter security design might've made it much more difficult to apply useful hacks like the one Mike Muus did! > On Jan 29, 2023, at 11:39 AM, Ron Natalie wrote: > > Another of Ron’s historical diversions that came to mind. > > Most of you probably know of various exploits that can happen now with setuid programs, but this was pretty loose back in the early days. I was a budding system programmer back in 1979 at Johns Hopkins. Back then hacking the UNIX system was generally considered as sport by the students. The few of us who were on the admin side spent a lot of time figuring out how it had happened and running around fixing it. > > The first one found was the fact that the “su” program decided that if it couldn’t open /etc/passwd for some reason, things must be really bad and the invoker should be given a root shell anyhow. The common exploit would be to open all the available file descriptors (16 I think back then) and thus there wasn’t one available. That was fixed before my time at JHU (but I used it on other systems). > > One day one of the guys who was shuffling stuff back and forth between MiniUnix on a PDP-11/40 and our main 11/45 UNIX came to me with his RK05 file system corrupted. I found that the superblock was corrupted. With some painstaking comparison to another RK05 superblock, I reconstituded it enough to run icheck -s etc.. and get the thing back. What I had found was that the output of the “mount” command had been written on the superblock. WTF? I said, how did this happen. Interrogating the user yielded the fact that he decided he didn’t want to see the mount output so he closed file descriptor one prior to invoking mount. Still it seemed odd. > > At JHU we had lots of people with removable packs, so someone had modified mount to run setuid (with the provision of only allowing certain devices to be mounted certain places). At his point we had started with the idea of putting volume labels in the superblock to identify the pack being mounted. Rather than put the stuff in the kernel right away, Mike Muuss just hacked reading it from the super block in the usermode mount program so that he could put the volume label in /etc/mtab. Now you can probably see where this is headed. It opens up the disk, seeks to the pack label in the superblock and reads it (for somereason things were opened RW). Then the output goes to file descriptor 1 which just happens to be further in the superblock. > > I figured this out. Fixed it and told Mike about it. I told him there were probably other setuid programs around that had the problem and asked if it was OK if I hacked on things (at the time I yet was not trusted with the root password). He told me to go ahead, knock yourself out. > > Well I spent the evening closing various combinations of file descriptors and invoking setuid programs. I found a few more and noted them. After a while I got tired and went home. > > The next day I came in and looked through our paper logbook that we filled out anytime the machine was shutdown (or crashed). There was a note from two of the other system admins saying they had shut the system down to rebuild the accounting file (this was essentially the shadow password file and some additional per-user information not stored in /etc/passwd). The first 8 bytes were corrupted. Oh, I say, I think I might know how that happened. Yeah, we thought you might. Your user name was what was written over the root entry in the file. The passwd changing program was one of the ones I tested, but I hadn’t noticed any ill-effects for it at the time. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Mon Jan 30 09:20:52 2023 From: tuhs at tuhs.org (Paul Ruizendaal via TUHS) Date: Mon, 30 Jan 2023 00:20:52 +0100 Subject: [TUHS] Earliest UNIX Workstations? Message-ID: Herewith some interesting (somewhat) contemporary papers on early windowing systems: 1. There was a conference in the UK early in 1985 discussing the state of window systems on Unix. Much interesting discussion and two talks by James Gosling, one about NeWS (then still called SunDew), and one about what seems to be SunWindows. It would seem then that these were developed almost in parallel. http://www.chilton-computing.org.uk/inf/literature/books/wm/contents.htm 2. Then there is a 1986 paper by James Gettys, discussing the 18 month journey towards X10. In particular it focuses on the constraints that Unix set on the design of the X system. https://www.tech-insider.org/unix/research/acrobat/860201-b.pdf 3. Next is the 1989 NeWS book that has a nice overview and history of windowing systems in its chapter 3: http://bitsavers.trailing-edge.com/pdf/sun/NeWS/The_NeWS_Book_1989.pdf Both the UK conference and the NeWS book mention a Unix kernel-based windowing system done at MIT in 1981 or 1982, “NU" or “NUnix”, by Jack Test. That one had not been mentioned before here and may have been the first graphical windowing work on Unix, preceding the Blit. Who remembers this one? 4. Finally, an undated paper by Stephen Uhler discussing the design of MGR is here: https://sau.homeip.net/papers/arch.pdf I’ve not included Rob Pike’s papers, as I assume they are well known on this list. Some of the above papers may be worthy of stable archiving. From jsg at jsg.id.au Mon Jan 30 10:25:05 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Mon, 30 Jan 2023 11:25:05 +1100 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: References: Message-ID: On Mon, Jan 30, 2023 at 12:20:52AM +0100, Paul Ruizendaal via TUHS wrote: > > 3. Next is the 1989 NeWS book that has a nice overview and history of windowing systems in its chapter 3: > > http://bitsavers.trailing-edge.com/pdf/sun/NeWS/The_NeWS_Book_1989.pdf > > Both the UK conference and the NeWS book mention a Unix kernel-based windowing system done at MIT in 1981 or 1982, “NU" or “NUnix”, by Jack Test. That one had not been mentioned before here and may have been the first graphical windowing work on Unix, preceding the Blit. Who remembers this one? "In April 1981, after the initial breadboard Nu Machines were constructed at M.I.T. and the UNIX operating system was ported to it, the design was licensed to Western Digital Corporation to be re-engineered and marketed as a commercial product. By late 1982, Western Digital had completed the redesign but decided not to enter the workstation business. Texas Instruments acquired the Nu Machine/NuBus technology including the original development group located in Irvine, California." pg 1 "The second category of software is the Nu Machine Operating System. This is a port of Bell Lab’s UNIX Operating System. The Nu Machine Operating System is derived from UNIX, Seventh Edition and contains, in addition to the normal UNIX commands and kernel, enhancements from the Berkeley version of UNIX and a proprietary window system for the Nu Machine video display subsystem. Of course, the Nu Machine Operating System will not run on Nu Machines that do not contain a 68010 processor board." pg 35 https://bitsavers.org/pdf/lmi/LMI_Docs/HARDWARE_1.pdf also mentioned on page 20 of http://www.bitsavers.org/pdf/perq/RD_Davis/Davis-PERQ_Workstations_Nov03.pdf " MIT Researchers were working on two systems which used the concepts of the Alto using very different technology. This first was known as the Lisp Machine project; the MIT Lisp Machine had all the features associated with a workstation, but was much more expensive. There were two spinoffs of this project which were less costly lisp machines produced by Symbolics and LMI. The other MIT project which evolved from knowlege of the Alto was the Nu machine; this was to be a workstation using a Motorolla 68000 microprocessor as its CPU. In various attempts to turn the Nu machine into a commercially viable product, MIT teamed up with Exxon Enterprises, then Heath/Schlumberger, and then Western Digital. All of these attempts failed. The only thing that resulted from this was a deal between MIT and Western Digital in which Western Digital was to make a Lisp processor board which would plug into the bus of the Nu machine. After some officials from Prime Computer took a tour of MIT and saw the Nu machine, Lisp Machine, and the Alto, it is runmored that the idea for the Apollo workstations was formed. The head of engineering at Prime Computer, William Poduska, started Apollo. Apollo had the added benefit of much more financial backing than Three Rivers had. Apollo introduced its Domain processor." From phil at ultimate.com Mon Jan 30 10:25:17 2023 From: phil at ultimate.com (Phil Budne) Date: Sun, 29 Jan 2023 19:25:17 -0500 Subject: [TUHS] FD 2 In-Reply-To: References: Message-ID: <202301300025.30U0PHEh022103@ultimate.com> Ron Natalie wrote: > Warner Losh wrote: > >"The main loop of the shell went as follows: > >1) The shell closed all its open files, then opened the terminal > >special file for standard input and output (file descriptors 0 and 1). > > > Unfortunately, the source code says otherwise. None of shells V6, PWB, > V7 do anything like is mentioned above. They assume 0 and 1 (and 2) > are already open. > The only fd redirection they do is when you do pipes or redirection on > the command line. > > Where this is done is, as I posted earlier, in /etc/init. Init opens > the tty device and dups it to 1 and then invokes either the shell (if > we're in single user mode) or getty for interactive mode. > This was done in V6 and PWB (1). In V7, init added a second dup for > file descriptor 2. I think the text Warner quoted applied to only the pre-fork version of the system, since it's preceeded by: "Processes (independently executing entities) existed very early in PDP-7 Unix. There were in fact precisely two of them, one for each of the two terminals attached to the machine. There was no fork, wait, or exec. There was an exit, but its meaning was rather different, as will be seen. and ends with: "4) The command did its work, then terminated by calling exit. The exit call caused the system to read in a fresh copy of the shell over the terminated command, then to jump to its start (and thus in effect to go to step 1)." In the (late) PDP-7 Unix we have sources for, FDs 1 & 2 are established in init at labels init1 (for the user on the console tty) and init2 (for the user on the display & display keyboard) after forking and doing the job of the login executable: https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/init.s A remaining mystery about the set of PDP-7 Unix sources we have is that cat.s (and only cat.s?) writes error messages to FD 8, but I haven't seen any place that sets FD 8: https://github.com/DoctorWkt/pdp7-unix/blob/master/scans/cat.s#L43 https://github.com/DoctorWkt/pdp7-unix/blob/master/scans/cat.s#L45 https://github.com/DoctorWkt/pdp7-unix/blob/master/scans/cat.s#L51 Listing scan at: https://www.tuhs.org/Archive/Distributions/Research/McIlroy_v0/06-5-12.pdf#page=21 From imp at bsdimp.com Mon Jan 30 10:45:43 2023 From: imp at bsdimp.com (Warner Losh) Date: Sun, 29 Jan 2023 17:45:43 -0700 Subject: [TUHS] File descriptor fun and games (setuid) In-Reply-To: <2D760346-E44F-4248-9122-19A5E4EDA42D@iitbombay.org> References: <2D760346-E44F-4248-9122-19A5E4EDA42D@iitbombay.org> Message-ID: On Sun, Jan 29, 2023, 3:59 PM Bakul Shah wrote: > Sorry for nitpicking but I don't understand why closing fd 1 *before* > calling mount result in this behavior? Shouldn't a write(1, ...) just fail? > Because if it is closed the first open will return 1. And that's also where the printf will go... Warner Anyway, this sounds like a classic case of "the confused deputy". > http://www.cap-lore.com/CapTheory/ConfusedDeputy.html > > Of course, a tighter security design might've made it much more difficult > to apply useful hacks like the one Mike Muus did! > > On Jan 29, 2023, at 11:39 AM, Ron Natalie wrote: > > Another of Ron’s historical diversions that came to mind. > > Most of you probably know of various exploits that can happen now with > setuid programs, but this was pretty loose back in the early days. I was > a budding system programmer back in 1979 at Johns Hopkins. Back then > hacking the UNIX system was generally considered as sport by the students. > The few of us who were on the admin side spent a lot of time figuring out > how it had happened and running around fixing it. > > The first one found was the fact that the “su” program decided that if it > couldn’t open /etc/passwd for some reason, things must be really bad and > the invoker should be given a root shell anyhow. The common exploit would > be to open all the available file descriptors (16 I think back then) and > thus there wasn’t one available. That was fixed before my time at JHU > (but I used it on other systems). > > One day one of the guys who was shuffling stuff back and forth between > MiniUnix on a PDP-11/40 and our main 11/45 UNIX came to me with his RK05 > file system corrupted. I found that the superblock was corrupted. With > some painstaking comparison to another RK05 superblock, I reconstituded it > enough to run icheck -s etc.. and get the thing back. What I had found > was that the output of the “mount” command had been written on the > superblock. WTF? I said, how did this happen. Interrogating the user > yielded the fact that he decided he didn’t want to see the mount output so > he closed file descriptor one prior to invoking mount. Still it seemed > odd. > > At JHU we had lots of people with removable packs, so someone had modified > mount to run setuid (with the provision of only allowing certain devices to > be mounted certain places). At his point we had started with the idea of > putting volume labels in the superblock to identify the pack being mounted. > Rather than put the stuff in the kernel right away, Mike Muuss just > hacked reading it from the super block in the usermode mount program so > that he could put the volume label in /etc/mtab. Now you can probably see > where this is headed. It opens up the disk, seeks to the pack label in > the superblock and reads it (for somereason things were opened RW). Then > the output goes to file descriptor 1 which just happens to be further in > the superblock. > > I figured this out. Fixed it and told Mike about it. I told him there > were probably other setuid programs around that had the problem and asked > if it was OK if I hacked on things (at the time I yet was not trusted with > the root password). He told me to go ahead, knock yourself out. > > Well I spent the evening closing various combinations of file descriptors > and invoking setuid programs. I found a few more and noted them. After > a while I got tired and went home. > > The next day I came in and looked through our paper logbook that we filled > out anytime the machine was shutdown (or crashed). There was a note from > two of the other system admins saying they had shut the system down to > rebuild the accounting file (this was essentially the shadow password file > and some additional per-user information not stored in /etc/passwd). The > first 8 bytes were corrupted. Oh, I say, I think I might know how that > happened. Yeah, we thought you might. Your user name was what was > written over the root entry in the file. The passwd changing program was > one of the ones I tested, but I hadn’t noticed any ill-effects for it at > the time. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Mon Jan 30 11:17:24 2023 From: bakul at iitbombay.org (Bakul Shah) Date: Sun, 29 Jan 2023 17:17:24 -0800 Subject: [TUHS] File descriptor fun and games (setuid) In-Reply-To: References: <2D760346-E44F-4248-9122-19A5E4EDA42D@iitbombay.org> Message-ID: <29FC4361-59FF-4F1B-843E-CF88D65E416C@iitbombay.org> > On Jan 29, 2023, at 4:45 PM, Warner Losh wrote: > > > > On Sun, Jan 29, 2023, 3:59 PM Bakul Shah > wrote: >> Sorry for nitpicking but I don't understand why closing fd 1 *before* calling mount result in this behavior? Shouldn't a write(1, ...) just fail? > > > Because if it is closed the first open will return 1. And that's also where the printf will go... I got that far but didn't think further (open to read the superblock will be now on fd 1). Thanks! Definitely a confused deputy problem! > Warner > >> Anyway, this sounds like a classic case of "the confused deputy". >> http://www.cap-lore.com/CapTheory/ConfusedDeputy.html >> >> Of course, a tighter security design might've made it much more difficult to apply useful hacks like the one Mike Muus did! >> >>> On Jan 29, 2023, at 11:39 AM, Ron Natalie > wrote: >>> >>> Another of Ron’s historical diversions that came to mind. >>> >>> Most of you probably know of various exploits that can happen now with setuid programs, but this was pretty loose back in the early days. I was a budding system programmer back in 1979 at Johns Hopkins. Back then hacking the UNIX system was generally considered as sport by the students. The few of us who were on the admin side spent a lot of time figuring out how it had happened and running around fixing it. >>> >>> The first one found was the fact that the “su” program decided that if it couldn’t open /etc/passwd for some reason, things must be really bad and the invoker should be given a root shell anyhow. The common exploit would be to open all the available file descriptors (16 I think back then) and thus there wasn’t one available. That was fixed before my time at JHU (but I used it on other systems). >>> >>> One day one of the guys who was shuffling stuff back and forth between MiniUnix on a PDP-11/40 and our main 11/45 UNIX came to me with his RK05 file system corrupted. I found that the superblock was corrupted. With some painstaking comparison to another RK05 superblock, I reconstituded it enough to run icheck -s etc.. and get the thing back. What I had found was that the output of the “mount” command had been written on the superblock. WTF? I said, how did this happen. Interrogating the user yielded the fact that he decided he didn’t want to see the mount output so he closed file descriptor one prior to invoking mount. Still it seemed odd. >>> >>> At JHU we had lots of people with removable packs, so someone had modified mount to run setuid (with the provision of only allowing certain devices to be mounted certain places). At his point we had started with the idea of putting volume labels in the superblock to identify the pack being mounted. Rather than put the stuff in the kernel right away, Mike Muuss just hacked reading it from the super block in the usermode mount program so that he could put the volume label in /etc/mtab. Now you can probably see where this is headed. It opens up the disk, seeks to the pack label in the superblock and reads it (for somereason things were opened RW). Then the output goes to file descriptor 1 which just happens to be further in the superblock. >>> >>> I figured this out. Fixed it and told Mike about it. I told him there were probably other setuid programs around that had the problem and asked if it was OK if I hacked on things (at the time I yet was not trusted with the root password). He told me to go ahead, knock yourself out. >>> >>> Well I spent the evening closing various combinations of file descriptors and invoking setuid programs. I found a few more and noted them. After a while I got tired and went home. >>> >>> The next day I came in and looked through our paper logbook that we filled out anytime the machine was shutdown (or crashed). There was a note from two of the other system admins saying they had shut the system down to rebuild the accounting file (this was essentially the shadow password file and some additional per-user information not stored in /etc/passwd). The first 8 bytes were corrupted. Oh, I say, I think I might know how that happened. Yeah, we thought you might. Your user name was what was written over the root entry in the file. The passwd changing program was one of the ones I tested, but I hadn’t noticed any ill-effects for it at the time. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Mon Jan 30 12:08:32 2023 From: imp at bsdimp.com (Warner Losh) Date: Sun, 29 Jan 2023 19:08:32 -0700 Subject: [TUHS] FD 2 In-Reply-To: <202301300025.30U0PHEh022103@ultimate.com> References: <202301300025.30U0PHEh022103@ultimate.com> Message-ID: On Sun, Jan 29, 2023, 5:25 PM Phil Budne wrote: > Ron Natalie wrote: > > Warner Losh wrote: > > >"The main loop of the shell went as follows: > > >1) The shell closed all its open files, then opened the terminal > > >special file for standard input and output (file descriptors 0 and 1). > > > > > Unfortunately, the source code says otherwise. None of shells V6, PWB, > > V7 do anything like is mentioned above. They assume 0 and 1 (and 2) > > are already open. > > The only fd redirection they do is when you do pipes or redirection on > > the command line. > > > > Where this is done is, as I posted earlier, in /etc/init. Init opens > > the tty device and dups it to 1 and then invokes either the shell (if > > we're in single user mode) or getty for interactive mode. > > This was done in V6 and PWB (1). In V7, init added a second dup for > > file descriptor 2. > > I think the text Warner quoted applied to only the pre-fork version of > the system, since it's preceeded by: > > "Processes (independently executing entities) existed very early in > PDP-7 Unix. There were in fact precisely two of them, one for each > of the two terminals attached to the machine. There was no fork, > wait, or exec. There was an exit, but its meaning was rather > different, as will be seen. > > and ends with: > > "4) The command did its work, then terminated by calling exit. The > exit call caused the system to read in a fresh copy of the shell > over the terminated command, then to jump to its start (and thus in > effect to go to step 1)." > > In the (late) PDP-7 Unix we have sources for, FDs 1 & 2 are > established in init at labels init1 (for the user on the console tty) > and init2 (for the user on the display & display keyboard) after forking > and doing the job of the login executable: > > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/init.s It looks like 0 & 1 to me. Am I missing something? Warner > > A remaining mystery about the set of PDP-7 Unix sources we have is > that cat.s (and only cat.s?) writes error messages to FD 8, but I > haven't seen any place that sets FD 8: > > https://github.com/DoctorWkt/pdp7-unix/blob/master/scans/cat.s#L43 > https://github.com/DoctorWkt/pdp7-unix/blob/master/scans/cat.s#L45 > https://github.com/DoctorWkt/pdp7-unix/blob/master/scans/cat.s#L51 > > Listing scan at: > > https://www.tuhs.org/Archive/Distributions/Research/McIlroy_v0/06-5-12.pdf#page=21 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsg at jsg.id.au Mon Jan 30 15:23:53 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Mon, 30 Jan 2023 16:23:53 +1100 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: References: Message-ID: On Mon, Jan 30, 2023 at 12:20:52AM +0100, Paul Ruizendaal via TUHS wrote: > > 3. Next is the 1989 NeWS book that has a nice overview and history of windowing systems in its chapter 3: > > http://bitsavers.trailing-edge.com/pdf/sun/NeWS/The_NeWS_Book_1989.pdf > > Both the UK conference and the NeWS book mention a Unix kernel-based windowing system done at MIT in 1981 or 1982, “NU" or “NUnix”, by Jack Test. That one had not been mentioned before here and may have been the first graphical windowing work on Unix, preceding the Blit. Who remembers this one? mentioned in ;login: Volume 7 Number 4, September 1982 https://archive.org/details/login_september-1982/page/24/mode/2up Notes on the Boston USENIX and /usr/group Joint Meeting July 1982 "NUnix Window System Description Jack A. Test Laboratory for Computer Science, Massachusetts Institute of Technology, Room 414, 545 Technology Square, Cambridge, Mass 02139 The NUnix Window System is a set of software that provides a user a basic window management mechanism on a high resolution display. It was developed for use with the MIT Real Time Systems Group NU Personal Computer, a 68000-based machine which uses a 820x1024 point raster-scan display, keyboard, and mouse for the user interface. The NU machines are being used for developing a multi-font editing system and drawing facility, in several circuit design projects, and in the development of new operating system concepts. The user may create multiple overlapping rectangular windows on the display. Each is associated with an independent UNIX teletype device and a display device. A window may have up to eight independent and changeable font maps. The windows are controlled with ioctl calls and special signals. These allow such actions as creating a new window, drawing on it, selecting or changing the fonts associated with it, reading the state of the mouse, obtaining and/or changing the state of the window, etc. Each window belongs to a process-group to which a signal is sent whenever there is a change to the attributes of the window. There is a window-manager program which makes use of the mouse device to allow the user to select functions from a set of displayed menus. The user also has access to the display bitmap and a special graphics routine library. The NUnix Window System is implemented in a set of device-driver routines in the UNIX V7 kernel. Most of the window driver code is machine independent with the exception of two low-level routines for driving the raster display and keyboard devices respectively. The NUnix Window System provides a basic window management mechanism that: (1) is transparent to the vast majority of user programs, (2) provides a clean user interface without the addition of any new system calls, and (3) allows user processes to manage their windows independently and with minimal kernel-imposed limitations. The code for the NUnix Window System is available from MIT if you have a UNIX V7 license. The speaker has submitted a paper for the Conference Proceedings." goes on to briefly cover: Design of an Intelligent Bitmap Terminal Rich Fortier and Tony Lake Bolt Beranek and Newman Inc., 10 Moulton St., Cambridge, Mass 02238 The SUN Workstation Andreas Bechtolsheim Sun Microsystems, 2310 Walsh Ave., Sania Clara, CA 95051 Merging Bitmap Graphics and UNIX Rob Pike Bell Labs 2C-521, Murray Hill, NJ 07974 a different writeup of these is in: https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V04.5.pdf September 1982, Vol IV No V July Usenix Abstracts From phil at ultimate.com Mon Jan 30 16:13:22 2023 From: phil at ultimate.com (Phil Budne) Date: Mon, 30 Jan 2023 01:13:22 -0500 Subject: [TUHS] =?utf-8?q?Collecting_notes_for_future_=E2=80=9Chistorians?= =?utf-8?q?=E2=80=9D_was=3A_Earliest_UNIX_Workstations=3F?= In-Reply-To: References: Message-ID: <202301300613.30U6DMe5030381@ultimate.com> Douglas McIlroy wrote: > Date: Sat, 28 Jan 2023 16:16:56 -0500 > > > * What do I really mean by workstation? Ex.gr. If an installation had a > > PDP-11 with a single terminal and operator, is it not a workstation? Is it > > the integration of display into the system that differentiates? > > Certainly integration is critical. The display should be integral to the > terminal, not simply an available device. > > Without that stipulation Ken's original single-user PDP-7 system would > count (unless, perhaps, the system had not yet been christened "Unix"). Tho perhaps the EXACT same PDP-7 (in its original use as a prototype for the PDP-9 based Graphic-2 circuit design/simulation system) would qualify as a workstation? Here's a 1965 video of the earlier (PDP-5 based?) Graphic-1 system in use: https://techchannel.att.com/playvideo/2012/09/07/AT&T-Archives-Graphic-1 Both Graphic-1 and Graphic-2 were display "workstations" that fronted for mainframes. From arnold at skeeve.com Mon Jan 30 17:50:26 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 30 Jan 2023 00:50:26 -0700 Subject: [TUHS] FD 2 In-Reply-To: References: Message-ID: <202301300750.30U7oQTh013304@freefriends.org> > > Where this is done is, as I posted earlier, in /etc/init. Init opens the > > tty device and dups it to 1 and then invokes either the shell (if we're in > > single user mode) or getty for interactive mode. > > This was done in V6 and PWB (1). In V7, init added a second dup for file > > descriptor 2. What I really like is how in V8 - V10 /dev/tty was a (sym)link to /dev/fd/3, and init simply did one more dup call. That eliminated the special tty device driver and was a lovely generalization / simplification. It's too bad this was never picked in the commercial Unixes or in Linux. Arnold From robpike at gmail.com Mon Jan 30 18:09:55 2023 From: robpike at gmail.com (Rob Pike) Date: Mon, 30 Jan 2023 19:09:55 +1100 Subject: [TUHS] FD 2 In-Reply-To: <202301300750.30U7oQTh013304@freefriends.org> References: <202301300750.30U7oQTh013304@freefriends.org> Message-ID: In Plan 9 we made /dev/tty (there called /dev/cons) fully virtual, a fiction that provided the semantics. I agree that it's a pity the /dev/tty kludge persists as a kernel hack. And then we have pttys, speaking of pitys. -rob On Mon, Jan 30, 2023 at 6:50 PM wrote: > > > Where this is done is, as I posted earlier, in /etc/init. Init > opens the > > > tty device and dups it to 1 and then invokes either the shell (if > we're in > > > single user mode) or getty for interactive mode. > > > This was done in V6 and PWB (1). In V7, init added a second dup for > file > > > descriptor 2. > > What I really like is how in V8 - V10 /dev/tty was a (sym)link to > /dev/fd/3, > and init simply did one more dup call. That eliminated the special tty > device > driver and was a lovely generalization / simplification. It's too bad this > was never picked in the commercial Unixes or in Linux. > > Arnold > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Mon Jan 30 18:45:53 2023 From: pnr at planet.nl (Paul Ruizendaal) Date: Mon, 30 Jan 2023 09:45:53 +0100 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: References: Message-ID: > On 30 Jan 2023, at 06:23, Jonathan Gray wrote: > > mentioned in ;login: Volume 7 Number 4, September 1982 > https://archive.org/details/login_september-1982/page/24/mode/2up > Notes on the Boston USENIX and /usr/group Joint Meeting July 1982 > > "NUnix Window System Description”, Jack A. Test Thank you for those finds! The Usenix bibliography gives: Author: Jack A. Test Title: NUnix Window System Description Pages: 45-50 Publisher: USENIX Proceedings: USENIX Conference Proceedings Date: Summer 1982 Location: Boston, MA Institution: MIT My google fu does not drag up those particular proceedings, or those 5 pages. Anybody got access to that? From jsg at jsg.id.au Mon Jan 30 19:22:51 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Mon, 30 Jan 2023 20:22:51 +1100 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: References: Message-ID: On Mon, Jan 30, 2023 at 04:23:53PM +1100, Jonathan Gray wrote: > mentioned in ;login: Volume 7 Number 4, September 1982 > https://archive.org/details/login_september-1982/page/24/mode/2up > Notes on the Boston USENIX and /usr/group Joint Meeting July 1982 > > "NUnix Window System Description ... > > goes on to briefly cover: > > Design of an Intelligent Bitmap Terminal > Rich Fortier and Tony Lake > Bolt Beranek and Newman Inc., 10 Moulton St., Cambridge, Mass 02238 > > The SUN Workstation > Andreas Bechtolsheim > Sun Microsystems, 2310 Walsh Ave., Sania Clara, CA 95051 > > Merging Bitmap Graphics and UNIX > Rob Pike > Bell Labs 2C-521, Murray Hill, NJ 07974 > > a different writeup of these is in: > > https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V04.5.pdf > September 1982, Vol IV No V > July Usenix Abstracts more from https://www.usenix.org/legacy/publications/bibliography/byDate.html though some of these are character based Author: Andreas Bechtolsheim Title: The SUN Workstation Pages: 61 Publisher: USENIX Proceedings: USENIX Conference Proceedings Date: Summer 1982 Location: Boston, MA Institution: Sun Microsystems Other: Abstract only Author: Richard Fortier Author: Anthony Lake Title: Design of an Intelligent Bitmap Terminal Pages: 51-60 Publisher: USENIX Proceedings: USENIX Conference Proceedings Date: Summer 1982 Location: Boston, MA Institution: Bolt Beranek and Newman Inc. Author: Rob Pike Title: Merging Bitmap Graphics and UNIX Pages: 61 Publisher: USENIX Proceedings: USENIX Conference Proceedings Date: Summer 1982 Location: Boston, MA Institution: Bell Labs, Murray Hill Other: Abstract only Author: Jack A. Test Title: NUnix Window System Description Pages: 45-50 Publisher: USENIX Proceedings: USENIX Conference Proceedings Date: Summer 1982 Location: Boston, MA Institution: MIT Author: David Mankins Author: Daniel Franklin Title: A Simple Window Management Facility for the UNIX Timesharing System Pages: 203-228 Publisher: USENIX Proceedings: USENIX Conference Proceedings Date: Summer 1983 Location: Toronto, Ont. Institution: Bolt Beranek and Newman, Inc. https://archive.org/details/login_sept83_issue/page/n23/mode/2up (abstract) Author: Michael Shantz Title: Graphics Standards for Personal Workstations Pages: 257-259 Publisher: USENIX Proceedings: USENIX Conference Proceedings Date: Winter 1983 Location: San Diego, CA Institution: Sun Microsystems, Inc. https://archive.org/details/1983-proceedings-unicom-san-diego/page/257/mode/2up Author: Steven R. Evans Title: Windows with 4.2BSD Pages: 260 Publisher: USENIX Proceedings: USENIX Conference Proceedings Date: Winter 1983 Location: San Diego, CA Institution: Sun Microsystems, Inc. Other: Abstract only https://archive.org/details/1983-proceedings-unicom-san-diego/page/259/mode/2up Author: Rex McDowell Title: A UNIX-Based Color Graphics Workstation Pages: 115-122 Publisher: USENIX Proceedings: USENIX UniForum Conference Proceedings Date: January 17-20, 1984 Location: Washington D.C. Institution: Metheus Corporation https://archive.org/details/1984-proceedings-uni-forum-dc/page/116/mode/2up Author: Robert J.K. Jacob Title: User-Level Window Manager for UNIX Pages: 123-134 Publisher: USENIX Proceedings: USENIX UniForum Conference Proceedings Date: January 17-20, 1984 Location: Washington D.C. Institution: Naval Research Laboratory https://www.cs.tufts.edu/~jacob/papers/uniforum.pdf https://archive.org/details/1984-proceedings-uni-forum-dc/page/122/mode/2up Author: Peter E. Collins Title: WINDX - Windows for the UNIX Environment Pages: 159-165 Publisher: USENIX Proceedings: USENIX Conference Proceedings Date: Summer 1984 Location: Salt Lake City, UT Institution: Ithaca Intersystems, Inc. https://archive.org/details/1984-proceedings-summer-salt-lake-city/page/158/mode/2up Author: Chris Torek Author: Mark Weiser Title: The Maryland Window System Pages: 166-172 Publisher: USENIX Proceedings: USENIX Conference Proceedings Date: Summer 1984 Location: Salt Lake City, UT Institution: University of Maryland https://archive.org/details/1984-proceedings-summer-salt-lake-city/page/166/mode/2up https://archive.org/download/CDROM_March92/CDROM_March92.cdr/UNIX_C%2FLANGUAGS%2FC%2FMW.TAR https://archive.org/details/CDROM_March92 derived in part from Gosling emacs mw.tar includes source and windows.nr -me paper From lars at nocrew.org Mon Jan 30 23:00:57 2023 From: lars at nocrew.org (Lars Brinkhoff) Date: Mon, 30 Jan 2023 13:00:57 +0000 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: (Paul Ruizendaal via TUHS's message of "Mon, 30 Jan 2023 00:20:52 +0100") References: Message-ID: <7wwn5489di.fsf@junk.nocrew.org> Paul Ruizendaal wrote: > Both the UK conference and the NeWS book mention a Unix kernel-based > windowing system done at MIT in 1981 or 1982, “NU" or “NUnix”, by Jack > Test. Sounds like Steve Ward's Nu Machine. From cowan at ccil.org Mon Jan 30 23:26:48 2023 From: cowan at ccil.org (John Cowan) Date: Mon, 30 Jan 2023 08:26:48 -0500 Subject: [TUHS] FD 2 In-Reply-To: <202301300750.30U7oQTh013304@freefriends.org> References: <202301300750.30U7oQTh013304@freefriends.org> Message-ID: On Mon, Jan 30, 2023 at 2:50 AM wrote: What I really like is how in V8 - V10 /dev/tty was a (sym)link to /dev/fd/3, and init simply did one more dup call. That eliminated the special tty device driver and was a lovely generalization / simplification. It's too bad this was never picked in the commercial Unixes or in Linux. That's problematic. I often need to redirect 2>&1 in order to get a stream of both output and error into a file or into less(1), without interfering with *input* from the terminal, as for example a password. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Tue Jan 31 00:30:31 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 30 Jan 2023 07:30:31 -0700 Subject: [TUHS] FD 2 In-Reply-To: References: <202301300750.30U7oQTh013304@freefriends.org> Message-ID: <202301301430.30UEUVTI006202@freefriends.org> John Cowan wrote: > On Mon, Jan 30, 2023 at 2:50 AM wrote: > > > What I really like is how in V8 - V10 /dev/tty was a (sym)link to /dev/fd/3, > > and init simply did one more dup call. That eliminated the special tty > > device > > driver and was a lovely generalization / simplification. It's too bad this > > was never picked in the commercial Unixes or in Linux. > > That's problematic. I often need to redirect 2>&1 in order to get a stream > of both output and error into a file or into less(1), without interfering > with *input* from the terminal, as for example a password. I don't see how. Input is from fd 0. fd 3 is open on the original terminal device by init, so even if you closed fd 0, opening /dev/tty gets you fd 3 gets you the original tty. Granted, someone could also redirect fd 3, but that's unlikely in most cases. Arnold From lm at mcvoy.com Tue Jan 31 01:02:19 2023 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 30 Jan 2023 07:02:19 -0800 Subject: [TUHS] FD 2 In-Reply-To: References: <202301300750.30U7oQTh013304@freefriends.org> Message-ID: <20230130150219.GD12306@mcvoy.com> On Mon, Jan 30, 2023 at 07:09:55PM +1100, Rob Pike wrote: > And then we have pttys, speaking of pitys. I'm not seeing how you do stuff like ssh into a remote system and have job control, etc, work without some sort of tty. From crossd at gmail.com Tue Jan 31 01:16:25 2023 From: crossd at gmail.com (Dan Cross) Date: Mon, 30 Jan 2023 10:16:25 -0500 Subject: [TUHS] FD 2 In-Reply-To: <20230130150219.GD12306@mcvoy.com> References: <202301300750.30U7oQTh013304@freefriends.org> <20230130150219.GD12306@mcvoy.com> Message-ID: On Mon, Jan 30, 2023 at 10:02 AM Larry McVoy wrote: > On Mon, Jan 30, 2023 at 07:09:55PM +1100, Rob Pike wrote: > > And then we have pttys, speaking of pitys. > > I'm not seeing how you do stuff like ssh into a remote system and have > job control, etc, work without some sort of tty. You don't. But perhaps that model isn't super great. There was no job control on plan9 and I can't say I ever missed it. If I needed another terminal, I just swept open another window. Job control, even remote access a la SSH (or telnet, or rlogin), are a bit of an historical accident. If, instead, my computing environment is the set of shared resources I've imported into my system, then I don't necessarily need something like that. The plan9 `cpu` command, for access to a remote CPU server, conceptually brought the CPU server to you, not the other way around. It was a very different model. - Dan C. From lm at mcvoy.com Tue Jan 31 01:27:03 2023 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 30 Jan 2023 07:27:03 -0800 Subject: [TUHS] FD 2 In-Reply-To: References: <202301300750.30U7oQTh013304@freefriends.org> <20230130150219.GD12306@mcvoy.com> Message-ID: <20230130152703.GE12306@mcvoy.com> On Mon, Jan 30, 2023 at 10:16:25AM -0500, Dan Cross wrote: > On Mon, Jan 30, 2023 at 10:02 AM Larry McVoy wrote: > > On Mon, Jan 30, 2023 at 07:09:55PM +1100, Rob Pike wrote: > > > And then we have pttys, speaking of pitys. > > > > I'm not seeing how you do stuff like ssh into a remote system and have > > job control, etc, work without some sort of tty. > > You don't. But perhaps that model isn't super great. > > There was no job control on plan9 and I can't say I ever missed it. If > I needed another terminal, I just swept open another window. Job > control, even remote access a la SSH (or telnet, or rlogin), are a bit > of an historical accident. If, instead, my computing environment is > the set of shared resources I've imported into my system, then I don't > necessarily need something like that. The plan9 `cpu` command, for > access to a remote CPU server, conceptually brought the CPU server to > you, not the other way around. > > It was a very different model. $ vi foo.c hack, hack ^Z $ make test test test, broken $ fg Yes, I could do that in 2 different terminals but that mode of working is extremely useful, works when I don't have a windowing system, I'm on the console. Not having that model is a deal breaker for me, and I suspect a non trivial number of other people. From crossd at gmail.com Tue Jan 31 01:35:25 2023 From: crossd at gmail.com (Dan Cross) Date: Mon, 30 Jan 2023 10:35:25 -0500 Subject: [TUHS] FD 2 In-Reply-To: <20230130152703.GE12306@mcvoy.com> References: <202301300750.30U7oQTh013304@freefriends.org> <20230130150219.GD12306@mcvoy.com> <20230130152703.GE12306@mcvoy.com> Message-ID: On Mon, Jan 30, 2023 at 10:27 AM Larry McVoy wrote: > On Mon, Jan 30, 2023 at 10:16:25AM -0500, Dan Cross wrote: > > On Mon, Jan 30, 2023 at 10:02 AM Larry McVoy wrote: > > > On Mon, Jan 30, 2023 at 07:09:55PM +1100, Rob Pike wrote: > > > > And then we have pttys, speaking of pitys. > > > > > > I'm not seeing how you do stuff like ssh into a remote system and have > > > job control, etc, work without some sort of tty. > > > > You don't. But perhaps that model isn't super great. > > > > There was no job control on plan9 and I can't say I ever missed it. If > > I needed another terminal, I just swept open another window. Job > > control, even remote access a la SSH (or telnet, or rlogin), are a bit > > of an historical accident. If, instead, my computing environment is > > the set of shared resources I've imported into my system, then I don't > > necessarily need something like that. The plan9 `cpu` command, for > > access to a remote CPU server, conceptually brought the CPU server to > > you, not the other way around. > > > > It was a very different model. > > $ vi foo.c > hack, hack > ^Z > $ make > test test test, broken > $ fg > > Yes, I could do that in 2 different terminals but that mode of working > is extremely useful, works when I don't have a windowing system, I'm > on the console. > > Not having that model is a deal breaker for me, and I suspect a non > trivial number of other people. Yup. That's a way to work, and if you work with Unix, it's a common one. Plan 9 was different, and a lot of people who were familiar with Unix didn't like that, and were not interested in trying out a different way if it meant that they couldn't bring their existing mental models and workflows into the new environment unchanged. There was no `vi` on plan9, either; well, there was, but it was a MIPS emulator, not a text editor. But with the `acme` editor, your active text editor panes and your terminal window were all part of the editor itself: https://www.youtube.com/watch?v=dP1xVpMPn8M At one point it struck me that Plan 9 didn't succeed as a widespread replacement for Unix/Linux because it was bad or incapable, but rather, because people wanted Linux, and not plan9. - Dan C. From lm at mcvoy.com Tue Jan 31 01:45:55 2023 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 30 Jan 2023 07:45:55 -0800 Subject: [TUHS] FD 2 In-Reply-To: References: <202301300750.30U7oQTh013304@freefriends.org> <20230130150219.GD12306@mcvoy.com> <20230130152703.GE12306@mcvoy.com> Message-ID: <20230130154555.GF12306@mcvoy.com> On Mon, Jan 30, 2023 at 10:35:25AM -0500, Dan Cross wrote: > Plan 9 was different, and a lot of people who were familiar with Unix > didn't like that, and were not interested in trying out a different > way if it meant that they couldn't bring their existing mental models > and workflows into the new environment unchanged. > > At one point it struck me that Plan 9 didn't succeed as a widespread > replacement for Unix/Linux because it was bad or incapable, but > rather, because people wanted Linux, and not plan9. Many people make that mistake. New stuff instead of extend old stuff. Look at programming languages for instance. We had C, it was pretty simple to understand, but people wanted more stuff. So now we have things like Rust that is pretty much completely different. Could we not have extended C to do what Rust does? Why do we need an entirely different syntax to say the same things? Seems like Plan 9 fell into that trap. When you invalidate all of the existing knowledge that people have, that creates a barrier to entry. As you said, people don't want to give up their mental model when that model works. They'll only give it up when there is at least a factor of 2 improvement that they care about. These days it feels like people are stuck enough that they want a factor of 10. From bakul at iitbombay.org Tue Jan 31 02:03:42 2023 From: bakul at iitbombay.org (Bakul Shah) Date: Mon, 30 Jan 2023 08:03:42 -0800 Subject: [TUHS] FD 2 In-Reply-To: References: Message-ID: <38B1D4CE-C239-4777-B606-FC641655DBCB@iitbombay.org> > On Jan 30, 2023, at 7:18 AM, Dan Cross wrote: > > There was no job control on plan9 and I can't say I ever missed it. Just yesterday I realized running two “make -j 8” in parallel was making them both go real slow so I stopped one of them with ^Z and continued it once the other make finished. This use case can’t be handled with more windows. From lm at mcvoy.com Tue Jan 31 02:07:05 2023 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 30 Jan 2023 08:07:05 -0800 Subject: [TUHS] FD 2 In-Reply-To: <38B1D4CE-C239-4777-B606-FC641655DBCB@iitbombay.org> References: <38B1D4CE-C239-4777-B606-FC641655DBCB@iitbombay.org> Message-ID: <20230130160705.GG12306@mcvoy.com> On Mon, Jan 30, 2023 at 08:03:42AM -0800, Bakul Shah wrote: > > > > On Jan 30, 2023, at 7:18 AM, Dan Cross wrote: > > > > There was no job control on plan9 and I can't say I ever missed it. > > Just yesterday I realized running two ???make -j 8??? in parallel was making > them both go real slow so I stopped one of them with ^Z and continued > it once the other make finished. This use case can???t be handled with more > windows. If you don't have job control, do you not have ^C to kill one of the make jobs? I guess you open another window and ps and kill it but if the machine is already thrashing that is gonna be unpleasant. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From crossd at gmail.com Tue Jan 31 02:09:03 2023 From: crossd at gmail.com (Dan Cross) Date: Mon, 30 Jan 2023 11:09:03 -0500 Subject: [TUHS] FD 2 In-Reply-To: <20230130154555.GF12306@mcvoy.com> References: <202301300750.30U7oQTh013304@freefriends.org> <20230130150219.GD12306@mcvoy.com> <20230130152703.GE12306@mcvoy.com> <20230130154555.GF12306@mcvoy.com> Message-ID: On Mon, Jan 30, 2023 at 10:45 AM Larry McVoy wrote: > On Mon, Jan 30, 2023 at 10:35:25AM -0500, Dan Cross wrote: > > Plan 9 was different, and a lot of people who were familiar with Unix > > didn't like that, and were not interested in trying out a different > > way if it meant that they couldn't bring their existing mental models > > and workflows into the new environment unchanged. > > > > At one point it struck me that Plan 9 didn't succeed as a widespread > > replacement for Unix/Linux because it was bad or incapable, but > > rather, because people wanted Linux, and not plan9. > > Many people make that mistake. New stuff instead of extend old stuff. Some would argue that's not a mistake. How else do we innovate if we're just incrementally polishing what's come before? Computing now is radically different than when I started, but if I'd listened to my betters back then, it wouldn't have changed all that much. Actually I _did_ listen to my betters, and now I'm sad that I missed out on a lot of exciting things. > Look at programming languages for instance. We had C, it was pretty > simple to understand, but people wanted more stuff. I think C is a language that people _think_ is simple to understand, and perhaps _was_ simple to understand, but is actually remarkably subtle and a _lot_ of people don't actually have a great handle on how it really works anymore. Particularly now, when the compiler people seem to be prizing optimization above all else and so even obvious behavior that's technically "undefined" results in unexpected behavior (e.g., `if (a > 0 && b > 0 && a*b) < 0) overflow(); // signed integer overflow is UB`. Maybe sadly, C hasn't been a portable macro assembler for decades now. > So now we have > things like Rust that is pretty much completely different. Could we > not have extended C to do what Rust does? Why do we need an entirely > different syntax to say the same things? People tried to extend C to do the things that Rust does and it didn't work. > Seems like Plan 9 fell into that trap. When you invalidate all of the > existing knowledge that people have, that creates a barrier to entry. Plan 9, as a research system, was an experiment in doing things differently. As a research system, it was remarkably influential: a lot of the ideas made it into e.g. Linux. Imitation is the most sincere form of flattery. As a production system, people just wanted Linux. There was a time when people wanted to try out new ideas; oh well. > As you said, people don't want to give up their mental model when that > model works. They'll only give it up when there is at least a factor > of 2 improvement that they care about. These days it feels like people > are stuck enough that they want a factor of 10. Yup, that's about right. The mainframe is still going strong, after all! - Dan C. From bakul at iitbombay.org Tue Jan 31 02:13:00 2023 From: bakul at iitbombay.org (Bakul Shah) Date: Mon, 30 Jan 2023 08:13:00 -0800 Subject: [TUHS] FD 2 In-Reply-To: <20230130160705.GG12306@mcvoy.com> References: <20230130160705.GG12306@mcvoy.com> Message-ID: <730FEF57-FD54-4433-B344-46B0F07F34AE@iitbombay.org> On Jan 30, 2023, at 8:07 AM, Larry McVoy wrote: > > On Mon, Jan 30, 2023 at 08:03:42AM -0800, Bakul Shah wrote: >> >> >>>> On Jan 30, 2023, at 7:18 AM, Dan Cross wrote: >>> >>> There was no job control on plan9 and I can't say I ever missed it. >> >> Just yesterday I realized running two ???make -j 8??? in parallel was making >> them both go real slow so I stopped one of them with ^Z and continued >> it once the other make finished. This use case can???t be handled with more >> windows. > > If you don't have job control, do you not have ^C to kill one of the > make jobs? I guess you open another window and ps and kill it but > if the machine is already thrashing that is gonna be unpleasant. Yes but then you lose a bunch of work. You don’t want to restart, you just want to delay. From lm at mcvoy.com Tue Jan 31 02:18:46 2023 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 30 Jan 2023 08:18:46 -0800 Subject: [TUHS] FD 2 In-Reply-To: References: <202301300750.30U7oQTh013304@freefriends.org> <20230130150219.GD12306@mcvoy.com> <20230130152703.GE12306@mcvoy.com> <20230130154555.GF12306@mcvoy.com> Message-ID: <20230130161846.GH12306@mcvoy.com> On Mon, Jan 30, 2023 at 11:09:03AM -0500, Dan Cross wrote: > On Mon, Jan 30, 2023 at 10:45 AM Larry McVoy wrote: > > On Mon, Jan 30, 2023 at 10:35:25AM -0500, Dan Cross wrote: > > > Plan 9 was different, and a lot of people who were familiar with Unix > > > didn't like that, and were not interested in trying out a different > > > way if it meant that they couldn't bring their existing mental models > > > and workflows into the new environment unchanged. > > > > > > At one point it struck me that Plan 9 didn't succeed as a widespread > > > replacement for Unix/Linux because it was bad or incapable, but > > > rather, because people wanted Linux, and not plan9. > > > > Many people make that mistake. New stuff instead of extend old stuff. > > Some would argue that's not a mistake. How else do we innovate if > we're just incrementally polishing what's come before? I didn't say limit yourself to polishing, I said try and not invalidate people's knowledge while innovating. Too many people go down the path of doing things very differently and they rationalize that they have to do it that way to innovate. That's fine but it means it is going to be harder to get people to try your new stuff. The point I'm trying to make is that "different" is a higher barrier, much, much higher, than "extend". People frequently ignore that and that means other people ignore their work. It is what it is, I doubt I'll convice anyone so I'll drop it. From ralph at inputplus.co.uk Tue Jan 31 02:18:57 2023 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Mon, 30 Jan 2023 16:18:57 +0000 Subject: [TUHS] FD 2 In-Reply-To: <38B1D4CE-C239-4777-B606-FC641655DBCB@iitbombay.org> References: <38B1D4CE-C239-4777-B606-FC641655DBCB@iitbombay.org> Message-ID: <20230130161857.F2F371FB2F@orac.inputplus.co.uk> Hi Bakul, > > There was no job control on plan9 and I can't say I ever missed it. > > Just yesterday I realized running two “make -j 8” in parallel was > making them both go real slow so I stopped one of them with ^Z and > continued it once the other make finished. This use case can’t be > handled with more windows. If I lacked job control in that situation, I'd either SIGSTOP one of the two with kill(1) for a later SIGCONT or renice it to hardly get a look in until its peer had finished. (The TTY's susp character for job control is SIGTSTP.) -- Cheers, Ralph. From crossd at gmail.com Tue Jan 31 02:17:59 2023 From: crossd at gmail.com (Dan Cross) Date: Mon, 30 Jan 2023 11:17:59 -0500 Subject: [TUHS] FD 2 In-Reply-To: <20230130160705.GG12306@mcvoy.com> References: <38B1D4CE-C239-4777-B606-FC641655DBCB@iitbombay.org> <20230130160705.GG12306@mcvoy.com> Message-ID: On Mon, Jan 30, 2023 at 11:07 AM Larry McVoy wrote: > On Mon, Jan 30, 2023 at 08:03:42AM -0800, Bakul Shah wrote: > > > On Jan 30, 2023, at 7:18 AM, Dan Cross wrote: > > > There was no job control on plan9 and I can't say I ever missed it. > > > > Just yesterday I realized running two ???make -j 8??? in parallel was making > > them both go real slow so I stopped one of them with ^Z and continued > > it once the other make finished. This use case can???t be handled with more > > windows. > > If you don't have job control, do you not have ^C to kill one of the > make jobs? I guess you open another window and ps and kill it but > if the machine is already thrashing that is gonna be unpleasant. You do, but it's not a kernel-level thing; there's no TTY abstraction with an attendant driver. Instead, the window system will interpret DEL as an interrupt request and send a note to the process group running in that window. Plan 9 didn't have signals; rather, there were "notes", that were little strings that could be sent between processes. It was the responsibility of the receiver to parse these and take appropriate action in a note handler; there was a "stop" note that could be used to pause a process. One could presumably use that to pause a process group that was using excessive CPU. - Dan C. From usotsuki at buric.co Tue Jan 31 02:21:45 2023 From: usotsuki at buric.co (Steve Nickolas) Date: Mon, 30 Jan 2023 11:21:45 -0500 (EST) Subject: [TUHS] FD 2 In-Reply-To: References: <202301300750.30U7oQTh013304@freefriends.org> <20230130150219.GD12306@mcvoy.com> <20230130152703.GE12306@mcvoy.com> <20230130154555.GF12306@mcvoy.com> Message-ID: On Mon, 30 Jan 2023, Dan Cross wrote: > I think C is a language that people _think_ is simple to understand, > and perhaps _was_ simple to understand, but is actually remarkably > subtle and a _lot_ of people don't actually have a great handle on how > it really works anymore. Particularly now, when the compiler people > seem to be prizing optimization above all else and so even obvious > behavior that's technically "undefined" results in unexpected behavior > (e.g., `if (a > 0 && b > 0 && a*b) < 0) overflow(); // signed integer > overflow is UB`. Maybe sadly, C hasn't been a portable macro assembler > for decades now. I always assume compiler braindeath. Always use parentheses; never assume any specific order of precedence. I've actually been bitten by compilers doing unexpectedly stupid things, so I guard around them. I'll never merge two chars into a short with c=(a<<8)|b; I will ALWAYS do this: c=a; c<<=8; c|=b; because 16-bit MS-DOS compilers will ALWAYS manage to blunder that, though 32-bit compilers get it right (the sane thing to do would be to treat it as a word bitshift, but the compiler treats it as a byteshift because a is uint8_t). I'll never do if (a==b&&c==d), always if ((a==b)&&(c==d)). I always try to assume the compiler will wreck my code in hilariously braindamaged ways and code so precisely that it cannot do so. > Imitation is the most sincere form of flattery. The actual saying continues "...that mediocrity can make to greatness", which changes the meaning a bit. ;p -uso. From usotsuki at buric.co Tue Jan 31 02:22:43 2023 From: usotsuki at buric.co (Steve Nickolas) Date: Mon, 30 Jan 2023 11:22:43 -0500 (EST) Subject: [TUHS] FD 2 In-Reply-To: <730FEF57-FD54-4433-B344-46B0F07F34AE@iitbombay.org> References: <20230130160705.GG12306@mcvoy.com> <730FEF57-FD54-4433-B344-46B0F07F34AE@iitbombay.org> Message-ID: On Mon, 30 Jan 2023, Bakul Shah wrote: > Yes but then you lose a bunch of work. You don’t want to restart, > you just want to delay. If it restarts, then there's something very wrong with your Makefile. make is designed to pick up where it left off if it dies before finishing. -uso. From lm at mcvoy.com Tue Jan 31 02:27:19 2023 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 30 Jan 2023 08:27:19 -0800 Subject: [TUHS] FD 2 In-Reply-To: References: <202301300750.30U7oQTh013304@freefriends.org> <20230130150219.GD12306@mcvoy.com> <20230130152703.GE12306@mcvoy.com> <20230130154555.GF12306@mcvoy.com> Message-ID: <20230130162719.GI12306@mcvoy.com> On Mon, Jan 30, 2023 at 11:21:45AM -0500, Steve Nickolas wrote: > I'll never do if (a==b&&c==d), always if ((a==b)&&(c==d)). I'm a if ((a == b) && (c == d)) guy but yeah, spell it out not just so the compiler doesn't mess with you, for me, it is more so my eyes run over the expression and I can parse it with less brain cells, parens let me think less. I've always had the opinion that code should be written in a way that is the most easy to read. From ron at ronnatalie.com Tue Jan 31 02:31:52 2023 From: ron at ronnatalie.com (Ron Natalie) Date: Mon, 30 Jan 2023 16:31:52 +0000 Subject: [TUHS] Job Control and other terminal fun Message-ID: A lot of this dates back from the old “tty” days (or at least crt terminals that were still alphanumeric). Even the concept of putting a job in the background with & is really a feature of trying to multiplex multiple tasks on the same dumb terminal. This is indeed less important with windowing things like the DMDs or modern windowing workstatiosn when you can just get another window. The Berkeley job control was an interesting hack. For us at BRL the problem was I absolutely detested the C shell syntax. The Korn shell hadn’t escaped from AT&T yet, so, I spent time figuring out how that really worked in the C shell (not really well documented), mostly by inspection, and then reimplemented it in the Bourne Shell (we were using the System V source code version for that). I still couldn’t get traction at BRL for using the Bourne shell because by that time, tcsh had come out with command line editing. So back to the shell sources I went. By this time, 5R2 had come out so I grabbed the shell source form that. I was very delighted to find that the macros that made C look sorta like Algol had been unwound and the thing was back to straight C. I reworked emacs-ish command line editing into the shell. Subsequently, I had a nice conversation with David Korn at USENIX, being probably at that point the two most familiar with Bourne shell job control internals. I also sat down with the guys writing either bash or the pdksh (can’t remember which) and explained all how this work. As a result my name ended up in the Linux manpages which was pretty much all I found for a while when I googled myself. Years later, I had left the BRL, spent three years as a Rutgers administrator and was working for a small startup in Virginia. There was a MIPS workstation there. I was slogging along using ed (my employees always were amazed that if there was no emacs on the system, I just used ed, having never learned vi). Not thinking about it, I attempted to retrieve a backgrounded job by typing “fg.” To my surprise the shell printed “Job control not enabled.” Hmm, I say. That sounds like my error message. “set -J” I type. “Job control enabled.” Hey! This is my shell. Turns out Doug Gwyn put my mods into his “System V on BSD” distribution tape and it had made its way into the Mach code base and so every Mach-derived system ended up with it. Certainly, I found it convenient. There have been other schemes other than job control to multiplex terminals. IBM in the AIX that ran on the 370/PS2/i860 had a device called the High Function Terminal that allowed you to swap screens on the console. When we implemented the i860 (which was an add in card for the micro channel), we called our console the Low Function Terminal. Then after spending some time on MIT’s ITS and TOPS20, I got intrigued by the fact on those systems you could have a “shell” that persisted across logins and could be detached and reattached on another device at another time. I set about making such an implementation. Not particularly efficient, it essentially grabbed one of the BSD ptys and spawned the shell there and then a small alternative login shell forwarded the real tty to that. You could then detach it leaving the shell running on the PTY and reattach it elsewhere. Much like ITS, on. login it reminded you that you had a detached shell running and offered to reattach it rather than spawning a new one (complete with the ITS-ish: space for yes, rubout for no). It never really caught on. Oh well, pardon my ramblings. -Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Tue Jan 31 02:32:54 2023 From: rminnich at gmail.com (ron minnich) Date: Mon, 30 Jan 2023 08:32:54 -0800 Subject: [TUHS] FD 2 In-Reply-To: <20230130162719.GI12306@mcvoy.com> References: <202301300750.30U7oQTh013304@freefriends.org> <20230130150219.GD12306@mcvoy.com> <20230130152703.GE12306@mcvoy.com> <20230130154555.GF12306@mcvoy.com> <20230130162719.GI12306@mcvoy.com> Message-ID: This is no longer about FD2, maybe it's time for a source quench on the thread? I keep expecting new messages on FD2 and somehow we're arguing about C and make again :-) On Mon, Jan 30, 2023 at 8:27 AM Larry McVoy wrote: > On Mon, Jan 30, 2023 at 11:21:45AM -0500, Steve Nickolas wrote: > > I'll never do if (a==b&&c==d), always if ((a==b)&&(c==d)). > > I'm a > > if ((a == b) && (c == d)) > > guy but yeah, spell it out not just so the compiler doesn't mess with > you, for me, it is more so my eyes run over the expression and I can > parse it with less brain cells, parens let me think less. > > I've always had the opinion that code should be written in a way that > is the most easy to read. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chet.ramey at case.edu Tue Jan 31 02:39:27 2023 From: chet.ramey at case.edu (Chet Ramey) Date: Mon, 30 Jan 2023 11:39:27 -0500 Subject: [TUHS] Job Control and other terminal fun In-Reply-To: References: Message-ID: On 1/30/23 11:31 AM, Ron Natalie wrote: > Years later, I had left the BRL, spent three years as a Rutgers > administrator and was working for a small startup in Virginia.   There was > a MIPS workstation there.    I was slogging along using ed (my employees > always were amazed that if there was no emacs on the system, I just used > ed, having never learned vi).   Not thinking about it, I attempted to > retrieve a backgrounded job by typing “fg.”   To my surprise the shell > printed “Job control not enabled.”   Hmm, I say.  That sounds like my error > message.   “set -J” I type.   “Job control enabled.”   Hey! This is my > shell.    Turns out Doug Gwyn put my mods into his “System V on BSD” > distribution tape and it had made its way into the Mach code base and so > every Mach-derived system ended up with it.   Certainly, I found it convenient. To tie a couple of recent threads together: Ron's shell ended up as /bin/sh on the NeXT machines. -- ``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 clemc at ccc.com Tue Jan 31 02:40:26 2023 From: clemc at ccc.com (Clem Cole) Date: Mon, 30 Jan 2023 11:40:26 -0500 Subject: [TUHS] FD 2 In-Reply-To: <20230130162719.GI12306@mcvoy.com> References: <202301300750.30U7oQTh013304@freefriends.org> <20230130150219.GD12306@mcvoy.com> <20230130152703.GE12306@mcvoy.com> <20230130154555.GF12306@mcvoy.com> <20230130162719.GI12306@mcvoy.com> Message-ID: On Mon, Jan 30, 2023 at 11:27 AM Larry McVoy wrote: > I've always had the opinion that code should be written in a way that > is the most easy to read. > Amen -- using the principle of '*least obscure*' or obtuse - being obvious is thinking about a quick and casual human reader of code, not a compiler someone taking intense notes. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Tue Jan 31 02:41:45 2023 From: bakul at iitbombay.org (Bakul Shah) Date: Mon, 30 Jan 2023 08:41:45 -0800 Subject: [TUHS] job control (Re: Re: FD 2 In-Reply-To: <20230130161857.F2F371FB2F@orac.inputplus.co.uk> References: <20230130161857.F2F371FB2F@orac.inputplus.co.uk> Message-ID: On Jan 30, 2023, at 8:19 AM, Ralph Corderoy wrote: > > Hi Bakul, > >>> There was no job control on plan9 and I can't say I ever missed it. >> >> Just yesterday I realized running two “make -j 8” in parallel was >> making them both go real slow so I stopped one of them with ^Z and >> continued it once the other make finished. This use case can’t be >> handled with more windows. > > If I lacked job control in that situation, I'd either SIGSTOP one of the > two with kill(1) for a later SIGCONT or renice it to hardly get a look > in until its peer had finished. (The TTY's susp character for job > control is SIGTSTP.) Unfortunately renice command can only be used by mere users to *increase* niceness, not decrease. Agreed that you don’t need a tty discipline for SIGSTOP but it is quite convenient! Note that even plan9 allows killing a process by hitting a single key but I suppose that is done in a different way. Steve Nickolas made a comment about how rerunning make should simply continue from where it left off. Unfortunately many do not. A typical silent error is an output file is created but the program is killed before it can finish the job. The next time around this program won’t run since the output already exists! Or you have a “make world” situation where everything is removed before building anything! From tytso at mit.edu Tue Jan 31 02:48:39 2023 From: tytso at mit.edu (Theodore Ts'o) Date: Mon, 30 Jan 2023 11:48:39 -0500 Subject: [TUHS] FD 2 In-Reply-To: References: <202301300750.30U7oQTh013304@freefriends.org> <20230130150219.GD12306@mcvoy.com> <20230130152703.GE12306@mcvoy.com> <20230130154555.GF12306@mcvoy.com> Message-ID: On Mon, Jan 30, 2023 at 11:09:03AM -0500, Dan Cross wrote: > > > At one point it struck me that Plan 9 didn't succeed as a widespread > > > replacement for Unix/Linux because it was bad or incapable, but > > > rather, because people wanted Linux, and not plan9. > > > > Many people make that mistake. New stuff instead of extend old stuff. > > Some would argue that's not a mistake. How else do we innovate if > we're just incrementally polishing what's come before? The challenge is how do you extend the most common interfaces so that you don't break the most common workflows and applications, without adding too much backwards compatibility hair, and without stiffling innovation. I think we can err in both directions --- break the world, and no one will adopt the OS, and too much backwars compaibility and it's much, much harder to innovate. The happy medium which Linux uses is that the userspace interfaces should mostly stay compatible ("thou shoult not break userspace") unless there are really, really good reasons (such as security vulnerabilities) when you can't really do that. But internal interfaces, including those that might be used by out of three kernel modules --- it's totally fair game, and if you have academics who have professors who were trained up on the 4.14 kernel, when they were in graduate school --- sorry, your knowledge is out of date, and you can either force your graduae students to use an obsolescent kernel for their research, or you're going to have to get with the times. (I remember in the early days of BSD where people considered it a feature that academic research tools wouldn't be broken; I believe I remember hearing that as excuses not to rework with networking and tty layers, whereas Linux rewrite the networking stack from scratch 2 or 3 times, and we've since completely reworked the block layer to deal with ultra-fast devices, even if that meant that all external device drivers would be broken.) Of course, there will be kvetching no matter where you draw the line, but simply saying, to *hell* with the old ways of doing things, and we can't break anything, even internal interfaces, are both recipes for failure IMHO. > > As you said, people don't want to give up their mental model when that > > model works. They'll only give it up when there is at least a factor > > of 2 improvement that they care about. These days it feels like people > > are stuck enough that they want a factor of 10. > > Yup, that's about right. The mainframe is still going strong, after all! One of the things that we can at $WORK is to be able to translate storage TCO costs (cost per byte, cost per IOPS), cost of CPU utilization, and cost of memory, etc., into SWE-equivalents. So when we propose a new initiative, we'll take the cost to implement the project, as well as the cost to change all of the downstream users in the software/storage stack, and do a cost benefit comparison. For example, we might take the cost to implement the use of some new storage technique, such as Hybrid SMR[1], dd a generous buffer because projects always take longer and cost more than you first might think, and then compare it to the 5 year storage TCO costs, using SWE-equivalents as the common unit of comparison. And the project will only get green-lighted if the benefits exceed the costs by a goodly margin. [1] https://blog.google/products/google-cloud/dynamic-hybrid-smr-ocp-proposal-improve-data-center-disk-drives/ Of course, things are different if you are working in academia, where things like getting published in a venue that will help build you or your associates' tenure case are going to be more important. In any case, if we are going to claim that programming is an engineering discpline, then engineering tradeoffs are important to remember. Companies or departments who forget this lesson are much more likely to get reminded of it when the activist investors start pushing for layoffs, or when you start wonderng why your company had to get sold off to the highest bidder... - Ted From akosela at andykosela.com Tue Jan 31 02:57:23 2023 From: akosela at andykosela.com (Andy Kosela) Date: Mon, 30 Jan 2023 17:57:23 +0100 Subject: [TUHS] FD 2 In-Reply-To: References: <202301300750.30U7oQTh013304@freefriends.org> <20230130150219.GD12306@mcvoy.com> <20230130152703.GE12306@mcvoy.com> <20230130154555.GF12306@mcvoy.com> Message-ID: On Monday, January 30, 2023, Dan Cross wrote: > On Mon, Jan 30, 2023 at 10:45 AM Larry McVoy wrote: > > On Mon, Jan 30, 2023 at 10:35:25AM -0500, Dan Cross wrote: > > > Plan 9 was different, and a lot of people who were familiar with Unix > > > didn't like that, and were not interested in trying out a different > > > way if it meant that they couldn't bring their existing mental models > > > and workflows into the new environment unchanged. > > > > > > At one point it struck me that Plan 9 didn't succeed as a widespread > > > replacement for Unix/Linux because it was bad or incapable, but > > > rather, because people wanted Linux, and not plan9. > > > > Many people make that mistake. New stuff instead of extend old stuff. > > Some would argue that's not a mistake. How else do we innovate if > we're just incrementally polishing what's come before? I would argue that Linux actually did a lot of things differently. It tried to conform to POSIX, but still there were a lof of fresh ideas that actually took off. It was not possible in the free BSD world which inherited much more from the old Unix world. > > So now we have > > things like Rust that is pretty much completely different. Could we > > not have extended C to do what Rust does? Why do we need an entirely > > different syntax to say the same things? > > People tried to extend C to do the things that Rust does and it didn't > work. Smells like C++ to me. Rust in essence is a re-implementation of C++ not C. It tries to pack as much features as it possibly can. I don't know of any other language that throughout the years remained as pure and minimal as C. (maybe Forth). > > > Seems like Plan 9 fell into that trap. When you invalidate all of the > > existing knowledge that people have, that creates a barrier to entry. > > Plan 9, as a research system, was an experiment in doing things > differently. As a research system, it was remarkably influential: a > lot of the ideas made it into e.g. Linux. Imitation is the most > sincere form of flattery. As a production system, people just wanted > Linux. There was a time when people wanted to try out new ideas; oh > well. Linux came out in the right place at the right time, right around the time when the Internet really became a cyberspace spanning the whole globe. Finland was first connected to the Internet in 1989. Linus bought his first 386DX33 in January 1991. To me Linux represented a revolution in computing. It built on the shoulders of Unix forefathers but at the same time was a breath of fresh air in the Unix space. Young people at the time wanted that. That's why it became so wildly popular. It was a completely free, idealistic worldwide movement. It brought together a diverse group of people: university Unix programmers, home computer enthusiasts and demoscene hackers who just recently replaced their 8-bit C64's and Atari's with fresh 386-based PCs, young security hackers who watched too much War Games, etc. It was a very fresh movement at the time. --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralph at inputplus.co.uk Tue Jan 31 03:00:28 2023 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Mon, 30 Jan 2023 17:00:28 +0000 Subject: [TUHS] Job Control and other terminal fun In-Reply-To: References: Message-ID: <20230130170028.AFF8C1FB2F@orac.inputplus.co.uk> Hi Ron, > IBM in the AIX that ran on the 370/PS2/i860 had a device called the > High Function Terminal that allowed you to swap screens on the > console. The HFT continued on the POWER RS/6000s. > I got intrigued by the fact on those systems you could have a “shell” > that persisted across logins and could be detached and reattached on > another device at another time. I set about making such an > implementation. Not particularly efficient, it essentially grabbed > one of the BSD ptys and spawned the shell there and then a small > alternative login shell forwarded the real tty to that. You could > then detach it leaving the shell running on the PTY and reattach it > elsewhere. Much like ITS, on. login it reminded you that you had a > detached shell running and offered to reattach it rather than spawning > a new one (complete with the ITS-ish: space for yes, rubout for no). > It never really caught on. It sounds like what screen(1), byobu(1), tmux(1), etc., do today except the user normally runs the program from the shell after logging in though I expect some of them support being chsh'd to being the log-in shell. Acorn's RISC iX, their 4.3 BSD launched in ’89 and running on their ARM2, had what they called ‘virtual terminals’ where the user could switch to one of several TTYs using the keyboard; getty would be waiting. Similar to Linux today. What early systems had this idea as a means of multiplexing terminals to a single user? -- Cheers, Ralph. From imp at bsdimp.com Tue Jan 31 03:04:46 2023 From: imp at bsdimp.com (Warner Losh) Date: Mon, 30 Jan 2023 10:04:46 -0700 Subject: [TUHS] FD 2 In-Reply-To: References: <202301300750.30U7oQTh013304@freefriends.org> <20230130150219.GD12306@mcvoy.com> <20230130152703.GE12306@mcvoy.com> <20230130154555.GF12306@mcvoy.com> Message-ID: On Mon, Jan 30, 2023 at 9:59 AM Andy Kosela wrote: > On Monday, January 30, 2023, Dan Cross wrote: > >> On Mon, Jan 30, 2023 at 10:45 AM Larry McVoy wrote: >> > On Mon, Jan 30, 2023 at 10:35:25AM -0500, Dan Cross wrote: >> > > Plan 9 was different, and a lot of people who were familiar with Unix >> > > didn't like that, and were not interested in trying out a different >> > > way if it meant that they couldn't bring their existing mental models >> > > and workflows into the new environment unchanged. >> > > >> > > At one point it struck me that Plan 9 didn't succeed as a widespread >> > > replacement for Unix/Linux because it was bad or incapable, but >> > > rather, because people wanted Linux, and not plan9. >> > >> > Many people make that mistake. New stuff instead of extend old stuff. >> >> Some would argue that's not a mistake. How else do we innovate if >> we're just incrementally polishing what's come before? > > > I would argue that Linux actually did a lot of things differently. It > tried to conform to POSIX, but still there were a lof of fresh ideas that > actually took off. > Yes, but one legacy of that was Linux tried to use the System V ABI everywhere with extensions, and that means errno values are different in linux for different platforms, signals are a bit different etc. > It was not possible in the free BSD world which inherited much more from > the old Unix world. > It's been totally possible in the BSD world. The vm systems have been redone in ways that make the original look different, the tty layers are now completely different (something bde couldn't accomplish in the early days), the autoconf / device probing/attaching is different, the fact that removable devices extend well beyond disk packs, SMP support (several different flavors), bus independent dma and device register access, etc. Now granted, in the earliest of days some things seemed too sacrosanct, but all the BSDs quickly learned being too rigid didn't generally have good outcomes (though some corners of the systems have taken longer than others to realize that). Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Tue Jan 31 03:24:47 2023 From: rminnich at gmail.com (ron minnich) Date: Mon, 30 Jan 2023 09:24:47 -0800 Subject: [TUHS] yet another C discussion (YACD) and: Rust is not C++ Message-ID: I did not want to disrupt the FD 2 discussion, but I could not really let this comment go unanswered: "Smells like C++ to me. Rust in essence is a re-implementation of C++ not C. It tries to pack as much features as it possibly can. " It's hard for me to see how you can say this if you have done any work in Rust and C++. But, short form: Rust is not C++. Full stop. I did not feel that comment should go unanswered, lest people believe it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Tue Jan 31 03:53:05 2023 From: rich.salz at gmail.com (Rich Salz) Date: Mon, 30 Jan 2023 12:53:05 -0500 Subject: [TUHS] Sun+Java article by Bradford Morgan White Message-ID: Some folks here might be interested in this. I haven't read this (not gonna subscribe), I know nothing about the author (Bradford Morgan White), but I saw Steve Sinofsky tweet good things about it. The Network is the Computer The story of Sun Microsystems and the Java programming language https://www.abortretry.fail/p/the-network-is-the-computer -------------- next part -------------- An HTML attachment was scrubbed... URL: From shout at drewdiver.com Tue Jan 31 04:30:35 2023 From: shout at drewdiver.com (Drew Diver) Date: Mon, 30 Jan 2023 19:30:35 +0100 Subject: [TUHS] Sun+Java article by Bradford Morgan White In-Reply-To: References: Message-ID: <8E22024F-A1F2-4BB9-80E6-1C46BAD28C48@drewdiver.com> If you can find a used copy, Sunburst: The Ascent of Sun Microsystems by Mark Hall was a great read. Best, Drew > On 30 Jan 2023, at 18:54, Rich Salz wrote: > >  > Some folks here might be interested in this. I haven't read this (not gonna subscribe), I know nothing about the author (Bradford Morgan White), but I saw Steve Sinofsky tweet good things about it. > > The Network is the Computer > The story of Sun Microsystems and the Java programming language > https://www.abortretry.fail/p/the-network-is-the-computer -------------- next part -------------- An HTML attachment was scrubbed... URL: From akosela at andykosela.com Tue Jan 31 04:47:19 2023 From: akosela at andykosela.com (Andy Kosela) Date: Mon, 30 Jan 2023 19:47:19 +0100 Subject: [TUHS] yet another C discussion (YACD) and: Rust is not C++ In-Reply-To: References: Message-ID: On Monday, January 30, 2023, ron minnich wrote: > I did not want to disrupt the FD 2 discussion, but I could not really let > this comment go unanswered: > > "Smells like C++ to me. Rust in essence is a re-implementation of C++ not > C. It tries to pack as much features as it possibly can. " > > It's hard for me to see how you can say this if you have done any work in > Rust and C++. > > But, short form: Rust is not C++. Full stop. > > I did not feel that comment should go unanswered, lest people believe it. > Well, I will stand by my opinion, but perhaps you misread what I meant. I meant that as a whole Rust resembles more C++ than C. Technically it might lie in between C and C++, but the amount of "features" certainly bring it closer to C++. While it might be easier to write safer code in Rust than in C++, I still think that its "weird" syntax and feature bloat make me dislike it the way I dislike C++. Just my .02. YMMV. --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Tue Jan 31 04:59:50 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 30 Jan 2023 18:59:50 +0000 Subject: [TUHS] yet another C discussion (YACD) and: Rust is not C++ In-Reply-To: References: Message-ID: My understanding is it might "look and feel" more C++-ish than C, but what it is doing under the hood for memory safety and such results in code much closer in candor to C. C++ relies on a pretty hefty stack of runtime for things that Rust takes care of much earlier through concepts like ownership. The result is that things like memory safety are handled by the compiler's analysis rather than libraries. Sure you may have more modern-looking OOP constructs, but my understanding is those constructs are closer to syntactic sugar than what most C++ environments do with constructing/destructing, passing pointers, concurrency, etc. Of course, I'm no expert so I'm just speaking from my own experiences with the two languages, but my understanding is Rust is a C-ish systems language parading around in fancy modern clothes, but it achieves most of its more sophisticated functionality at compile time rather than relying on a bunch of runtime code to keep everything rolling. I don't think Rust will "replace" C any time soon, just like C hasn't really "replaced" FORTRAN and COBOL in a lot of places, but it will continue to grow as a systems-programming language, especially what with the Linux kernel starting to greenlight Rust components. Regardless, I personally see future value in Rust and so I nabbed the book and am slowly learning it. Hopefully it isn't time wasted and we start seeing more Rust-native interfaces out there. One of the main things holding me back is a lack of native OpenGL interfacing. There are binding layers of course, but that's just another stinky layer of code I don't control doing things I may or may not agree with. As for writing my own bindings, I could do that...or I could just write in C and be done with it :P Who knows, as time goes on though, Rust may verge more and more into that territory of "best of both worlds" with familiar OOP constructs for modern programmers and​ similar performance to C where it counts. If nothing else, I can credit Rust as the first new language I've actually bought the book for in a long, long time. - Matt G. ------- Original Message ------- On Monday, January 30th, 2023 at 10:47 AM, Andy Kosela wrote: > On Monday, January 30, 2023, ron minnich wrote: > >> I did not want to disrupt the FD 2 discussion, but I could not really let this comment go unanswered: >> >> "Smells like C++ to me. Rust in essence is a re-implementation of C++ not C. It tries to pack as much features as it possibly can. " >> >> It's hard for me to see how you can say this if you have done any work in Rust and C++. >> >> But, short form: Rust is not C++. Full stop. >> >> I did not feel that comment should go unanswered, lest people believe it. > > Well, I will stand by my opinion, but perhaps you misread what I meant. I meant that as a whole Rust resembles more C++ than C. Technically it might lie in between C and C++, but the amount of "features" certainly bring it closer to C++. While it might be easier to write safer code in Rust than in C++, I still think that its "weird" syntax and feature bloat make me dislike it the way I dislike C++. > > Just my .02. YMMV. > > --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Tue Jan 31 05:03:32 2023 From: crossd at gmail.com (Dan Cross) Date: Mon, 30 Jan 2023 14:03:32 -0500 Subject: [TUHS] FD 2 In-Reply-To: <20230130161846.GH12306@mcvoy.com> References: <202301300750.30U7oQTh013304@freefriends.org> <20230130150219.GD12306@mcvoy.com> <20230130152703.GE12306@mcvoy.com> <20230130154555.GF12306@mcvoy.com> <20230130161846.GH12306@mcvoy.com> Message-ID: On Mon, Jan 30, 2023 at 11:18 AM Larry McVoy wrote: > On Mon, Jan 30, 2023 at 11:09:03AM -0500, Dan Cross wrote: > > On Mon, Jan 30, 2023 at 10:45 AM Larry McVoy wrote: > > > On Mon, Jan 30, 2023 at 10:35:25AM -0500, Dan Cross wrote: > > > > Plan 9 was different, and a lot of people who were familiar with Unix > > > > didn't like that, and were not interested in trying out a different > > > > way if it meant that they couldn't bring their existing mental models > > > > and workflows into the new environment unchanged. > > > > > > > > At one point it struck me that Plan 9 didn't succeed as a widespread > > > > replacement for Unix/Linux because it was bad or incapable, but > > > > rather, because people wanted Linux, and not plan9. > > > > > > Many people make that mistake. New stuff instead of extend old stuff. > > > > Some would argue that's not a mistake. How else do we innovate if > > we're just incrementally polishing what's come before? > > I didn't say limit yourself to polishing, I said try and not invalidate > people's knowledge while innovating. > > Too many people go down the path of doing things very differently and > they rationalize that they have to do it that way to innovate. That's > fine but it means it is going to be harder to get people to try your > new stuff. > > The point I'm trying to make is that "different" is a higher barrier, > much, much higher, than "extend". People frequently ignore that and > that means other people ignore their work. > > It is what it is, I doubt I'll convice anyone so I'll drop it. Oh, I don't know. I think it's actually kind of important to see _why_ people didn't want to look deeper into plan9 (for example). The system had a lot to offer, but you had to dig a bit to get into it; a lot of folks never got that far. If it was really lack of job control, then that's a shame. - Dan C. From crossd at gmail.com Tue Jan 31 05:07:59 2023 From: crossd at gmail.com (Dan Cross) Date: Mon, 30 Jan 2023 14:07:59 -0500 Subject: [TUHS] FD 2 In-Reply-To: <20230130161857.F2F371FB2F@orac.inputplus.co.uk> References: <38B1D4CE-C239-4777-B606-FC641655DBCB@iitbombay.org> <20230130161857.F2F371FB2F@orac.inputplus.co.uk> Message-ID: On Mon, Jan 30, 2023 at 11:19 AM Ralph Corderoy wrote: > > > There was no job control on plan9 and I can't say I ever missed it. > > > > Just yesterday I realized running two “make -j 8” in parallel was > > making them both go real slow so I stopped one of them with ^Z and > > continued it once the other make finished. This use case can’t be > > handled with more windows. > > If I lacked job control in that situation, I'd either SIGSTOP one of the > two with kill(1) for a later SIGCONT or renice it to hardly get a look > in until its peer had finished. (The TTY's susp character for job > control is SIGTSTP.) I think that Bakul's point was that there wasn't an analogue for SIGTSTP in plan 9. You _could_ drop a `stop` into a process's /proc/$pid/note, which was the Unix equivalent of sending `SIGSTOP` (and I was a bit wrong earlier; that was handled by the proc driver, not the process). I don't believe there was a binding for that in the window system, though. It's funny, as I thought about it a bit more, the existence of the window system model sort of proves that there's nothing intrinsic about how it worked that would preclude one writing, basically, a terminal-driver in user space. No one was ever motivated to do so, but I don't see why one couldn't have implemented job control as a userspace primitive building on top of the existing proc/note machinery. - Dan C. From brantley at coraid.com Tue Jan 31 05:12:37 2023 From: brantley at coraid.com (Brantley Coile) Date: Mon, 30 Jan 2023 19:12:37 +0000 Subject: [TUHS] FD 2 In-Reply-To: References: <202301300750.30U7oQTh013304@freefriends.org> <20230130150219.GD12306@mcvoy.com> <20230130152703.GE12306@mcvoy.com> <20230130154555.GF12306@mcvoy.com> <20230130161846.GH12306@mcvoy.com> Message-ID: <49876ABC-A79D-4FFB-8D62-B932C524BA53@coraid.com> I have my own theory on why Plan 9 never caught on. It was never productized. It was a modern system arriving right at the post modern age emerged so it didn't resonate with the folks who were doing things. It was too early to be recognized as a cloud operating system, which is what it really is. I say "is" because we actually use it and have done so since 1995. We still ship appliances based on it. We do all our development on it. I have dumps on our file server (Ken's) going back to Jun 22, 2004. I can't really know for sure, but I think those are the three reasons: never made a product, modern not post modern, too early for the cloud. Brantley Coile > On Jan 30, 2023, at 2:03 PM, Dan Cross wrote: > > On Mon, Jan 30, 2023 at 11:18 AM Larry McVoy wrote: >> On Mon, Jan 30, 2023 at 11:09:03AM -0500, Dan Cross wrote: >>> On Mon, Jan 30, 2023 at 10:45 AM Larry McVoy wrote: >>>> On Mon, Jan 30, 2023 at 10:35:25AM -0500, Dan Cross wrote: >>>>> Plan 9 was different, and a lot of people who were familiar with Unix >>>>> didn't like that, and were not interested in trying out a different >>>>> way if it meant that they couldn't bring their existing mental models >>>>> and workflows into the new environment unchanged. >>>>> >>>>> At one point it struck me that Plan 9 didn't succeed as a widespread >>>>> replacement for Unix/Linux because it was bad or incapable, but >>>>> rather, because people wanted Linux, and not plan9. >>>> >>>> Many people make that mistake. New stuff instead of extend old stuff. >>> >>> Some would argue that's not a mistake. How else do we innovate if >>> we're just incrementally polishing what's come before? >> >> I didn't say limit yourself to polishing, I said try and not invalidate >> people's knowledge while innovating. >> >> Too many people go down the path of doing things very differently and >> they rationalize that they have to do it that way to innovate. That's >> fine but it means it is going to be harder to get people to try your >> new stuff. >> >> The point I'm trying to make is that "different" is a higher barrier, >> much, much higher, than "extend". People frequently ignore that and >> that means other people ignore their work. >> >> It is what it is, I doubt I'll convice anyone so I'll drop it. > > Oh, I don't know. I think it's actually kind of important to see _why_ > people didn't want to look deeper into plan9 (for example). The system > had a lot to offer, but you had to dig a bit to get into it; a lot of > folks never got that far. If it was really lack of job control, then > that's a shame. > > - Dan C. From rminnich at gmail.com Tue Jan 31 05:35:42 2023 From: rminnich at gmail.com (ron minnich) Date: Mon, 30 Jan 2023 11:35:42 -0800 Subject: [TUHS] yet another C discussion (YACD) and: Rust is not C++ In-Reply-To: References: Message-ID: I don't know how many ways there are to say this, but Rust and C/C++ are fundamentally different at the lowest level. If you are just looking at Rust syntax in a superficial way, you might be excused for thinking it's "C with features / C++ with differences." But that's not how it is. It's like saying C is "just like assembly" because labels have a ':' in them; or that Unix is "just like RSX" because they have vaguely similar commands. Here's a real question that came up where I work: should the code shown below be accepted (this is abstracted from a real example that is in use ... everywhere)? We had one code analyzer that said, emphatically, NO; one person said YES, another MAYBE. One piece of code, 3 answers :-) char f() { char *y; g(&y); return *y; } A specific question: should y be initialized to NULL? The case to set y to NULL: otherwise it has an unknown value and it's unsafe. The case against setting y to NULL: it is pointless, as it slows the code down slightly and g is going to change it anyway. The case maybe: Why do you trust g() to always set it? Why don't you trust g()? convince me. You can't write this in Rust with this ambiguity. It won't compile. In fact, & doesn't mean in Rust what it does in C. Sorry to be such a pedant, but I was concerned that we not fall into the "Rust is C++ all over again" trap. As for replacing C, the velocity of Rust is just astonishing. I think folks have been waiting for something to replace C for a long time, and Rust, with all its headaches and issues, is likely to be that thing. Personally, I still prefer Go, but I can also see which way the wind is blowing, especially when I see Rust use exploding in firmware and user mode, and now even in the Linux kernel. On Mon, Jan 30, 2023 at 11:00 AM segaloco wrote: > My understanding is it might "look and feel" more C++-ish than C, but what > it is doing under the hood for memory safety and such results in code much > closer in candor to C. > > C++ relies on a pretty hefty stack of runtime for things that Rust takes > care of much earlier through concepts like ownership. The result is that > things like memory safety are handled by the compiler's analysis rather > than libraries. Sure you may have more modern-looking OOP constructs, but > my understanding is those constructs are closer to syntactic sugar than > what most C++ environments do with constructing/destructing, passing > pointers, concurrency, etc. > > Of course, I'm no expert so I'm just speaking from my own experiences with > the two languages, but my understanding is Rust is a C-ish systems language > parading around in fancy modern clothes, but it achieves most of its more > sophisticated functionality at compile time rather than relying on a bunch > of runtime code to keep everything rolling. > > I don't think Rust will "replace" C any time soon, just like C hasn't > really "replaced" FORTRAN and COBOL in a lot of places, but it will > continue to grow as a systems-programming language, especially what with > the Linux kernel starting to greenlight Rust components. Regardless, I > personally see future value in Rust and so I nabbed the book and am slowly > learning it. Hopefully it isn't time wasted and we start seeing more > Rust-native interfaces out there. One of the main things holding me back > is a lack of native OpenGL interfacing. There are binding layers of > course, but that's just another stinky layer of code I don't control doing > things I may or may not agree with. As for writing my own bindings, I > could do that...or I could just write in C and be done with it :P > > Who knows, as time goes on though, Rust may verge more and more into that > territory of "best of both worlds" with familiar OOP constructs for modern > programmers *and*​ similar performance to C where it counts. If nothing > else, I can credit Rust as the first new language I've actually bought the > book for in a long, long time. > > - Matt G. > ------- Original Message ------- > On Monday, January 30th, 2023 at 10:47 AM, Andy Kosela < > akosela at andykosela.com> wrote: > > > On Monday, January 30, 2023, ron minnich wrote: > >> I did not want to disrupt the FD 2 discussion, but I could not really let >> this comment go unanswered: >> >> "Smells like C++ to me. Rust in essence is a re-implementation of C++ not >> C. It tries to pack as much features as it possibly can. " >> >> It's hard for me to see how you can say this if you have done any work in >> Rust and C++. >> >> But, short form: Rust is not C++. Full stop. >> >> I did not feel that comment should go unanswered, lest people believe it. >> > > Well, I will stand by my opinion, but perhaps you misread what I meant. I > meant that as a whole Rust resembles more C++ than C. Technically it might > lie in between C and C++, but the amount of "features" certainly bring it > closer to C++. While it might be easier to write safer code in Rust than in > C++, I still think that its "weird" syntax and feature bloat make me > dislike it the way I dislike C++. > > Just my .02. YMMV. > > --Andy > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stewart at serissa.com Tue Jan 31 05:55:53 2023 From: stewart at serissa.com (Lawrence Stewart) Date: Mon, 30 Jan 2023 14:55:53 -0500 Subject: [TUHS] FD 2 In-Reply-To: <20230130162719.GI12306@mcvoy.com> References: <202301300750.30U7oQTh013304@freefriends.org> <20230130150219.GD12306@mcvoy.com> <20230130152703.GE12306@mcvoy.com> <20230130154555.GF12306@mcvoy.com> <20230130162719.GI12306@mcvoy.com> Message-ID: <788280D1-885C-42FE-BD38-85438E9D06D7@serissa.com> Ha, when I was doing a design verification stint, I caught a piece of verilog that depended on an incorrect view of order of operations and saved the corp a new mask, so completely agree. Infix notation is just a bad idea. > On Jan 30, 2023, at 11:27 AM, Larry McVoy wrote: > > On Mon, Jan 30, 2023 at 11:21:45AM -0500, Steve Nickolas wrote: >> I'll never do if (a==b&&c==d), always if ((a==b)&&(c==d)). > > I'm a > > if ((a == b) && (c == d)) > > guy but yeah, spell it out not just so the compiler doesn't mess with > you, for me, it is more so my eyes run over the expression and I can > parse it with less brain cells, parens let me think less. > > I've always had the opinion that code should be written in a way that > is the most easy to read. From tytso at mit.edu Tue Jan 31 06:38:59 2023 From: tytso at mit.edu (Theodore Ts'o) Date: Mon, 30 Jan 2023 15:38:59 -0500 Subject: [TUHS] FD 2 In-Reply-To: References: <202301300750.30U7oQTh013304@freefriends.org> <20230130150219.GD12306@mcvoy.com> <20230130152703.GE12306@mcvoy.com> <20230130154555.GF12306@mcvoy.com> Message-ID: On Mon, Jan 30, 2023 at 10:04:46AM -0700, Warner Losh wrote: > > Yes, but one legacy of that was Linux tried to use the System V ABI > everywhere with extensions, and that means errno values are different in > linux for different platforms, signals are a bit different etc. Linux used the *Minix* ABI for 32-bit x86, so that Minix 1.x binaries would run on Linux until recently (when a.out support was removed). For some of the first original ports (e.g., Alpha and Sparc) there was an attempt to maintain partial ABI compatibility with OSF/1 and SunOS, mainly so that proprietary binaries (mostly Netscape) could run on those Linux ports. However, for pretty much all of the newer architectures, the system call and signal numbers used are inherited from the x86 and x86_64 syscall and signal numbers. After Netscape passed, the demand for running non-native binaries rapidly declined. What you may be remembering was that Linux used to have an emulation layer for Intel Binary Compatibility Standard (iBCS2)[1]. However, this was not native support; Linux used "int 0x80" for xx86 system call with a.out (and later ELF) binaries, while iBCS2 mandated use of "lcall 7,0" syscalls and COFF binaries. So iBCS2 support was an optional thing that you had to explicitly configure the kernel to support, and while it was quite complete, it was not Linux's native userspace interface. [1] https://www.linux.co.cr/free-unix-os/review/acrobat/940612.pdf Story time: at one point in the early 90's, MIT purchased a site license for a proprietary spreadsheet product for ISC Unix, which we planned to run on Linux systems at MIT using iBCS2. When I contacted Michael Johnson[2], the engineer at that company to implement support for the site license ---- which was going to rely on checking the IP address on the system to see if it was 18.x.y.z --- I found out that Michael built and tested the spreadsheet using Linux with iBCS2 emulation, and only *later* made sure it would actually run on ISC Unix, because Linux was a much more pleasant development environment than the System V alternatives. :-) [2] Michael later was one of the founders of Red Hat. In any case, while in practice some platforms use a unique set of code points for system calls and signal numbers (thos are mostly the older architectures which exist mostly for historic interest), most platforms which run Linux today actually use a consistent set of system call and signal numbers. That being said, we did implement many of the System V extensions, mostly because there was demand from the proprietary software vendors who needed to be convinced to port their applications from Solars, HPUX, AIX, etc., to Linux. Mercifully, Linux never implemented Streams (thank $DEITY Oracle didn't make that a requirement :-) and we did have BSD job control from the earliest days. That happened because in early 1992, I considered Job Control to be a highly important feature that Linux **had** to have, and so I sat down with the POSIX.1 specification, and implemented job control from the spec. The reason why Linux's tty layer has a bit of a System V "flavor" at least from a system call perspective has nothing to do the system call ABI, and more to do with the fact that apparently representatives from System V derivatives seemed to have a dominant role on the POSIX committee. - Ted From steffen at sdaoden.eu Tue Jan 31 07:00:38 2023 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 30 Jan 2023 22:00:38 +0100 Subject: [TUHS] Job Control and other terminal fun In-Reply-To: <20230130170028.AFF8C1FB2F@orac.inputplus.co.uk> References: <20230130170028.AFF8C1FB2F@orac.inputplus.co.uk> Message-ID: <20230130210038.P_ita%steffen@sdaoden.eu> Ralph Corderoy wrote in <20230130170028.AFF8C1FB2F at orac.inputplus.co.uk>: |> IBM in the AIX that ran on the 370/PS2/i860 had a device called the |> High Function Terminal that allowed you to swap screens on the |> console. ... |> I got intrigued by the fact on those systems you could have a “shell” |> that persisted across logins and could be detached and reattached on |> another device at another time. I set about making such an |> implementation. Not particularly efficient, it essentially grabbed ... |It sounds like what screen(1), byobu(1), tmux(1), etc., do today except To mention dtach(1) which only "emulates the detach feature of screen". (I use it on the vserver to run an ip(8) netns / unshare(1) etc boxed irssi proxy that serves to the inside VPN. Flawless for many years.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From imp at bsdimp.com Tue Jan 31 07:01:35 2023 From: imp at bsdimp.com (Warner Losh) Date: Mon, 30 Jan 2023 14:01:35 -0700 Subject: [TUHS] FD 2 In-Reply-To: References: <202301300750.30U7oQTh013304@freefriends.org> <20230130150219.GD12306@mcvoy.com> <20230130152703.GE12306@mcvoy.com> <20230130154555.GF12306@mcvoy.com> Message-ID: On Mon, Jan 30, 2023 at 1:39 PM Theodore Ts'o wrote: > On Mon, Jan 30, 2023 at 10:04:46AM -0700, Warner Losh wrote: > > > > Yes, but one legacy of that was Linux tried to use the System V ABI > > everywhere with extensions, and that means errno values are different in > > linux for different platforms, signals are a bit different etc. > > Linux used the *Minix* ABI for 32-bit x86, so that Minix 1.x binaries > would run on Linux until recently (when a.out support was removed). > For some of the first original ports (e.g., Alpha and Sparc) there was > an attempt to maintain partial ABI compatibility with OSF/1 and SunOS, > mainly so that proprietary binaries (mostly Netscape) could run on > those Linux ports. However, for pretty much all of the newer > architectures, the system call and signal numbers used are inherited > from the x86 and x86_64 syscall and signal numbers. After Netscape > passed, the demand for running non-native binaries rapidly declined. > > What you may be remembering was that Linux used to have an emulation > layer for Intel Binary Compatibility Standard (iBCS2)[1]. However, > this was not native support; Linux used "int 0x80" for xx86 system > call with a.out (and later ELF) binaries, while iBCS2 mandated use of > "lcall 7,0" syscalls and COFF binaries. So iBCS2 support was an > optional thing that you had to explicitly configure the kernel to > support, and while it was quite complete, it was not Linux's native > userspace interface. > So I've written a libc-like library for Linux ABI for my kexec the FreeBSD kernel project which produces a Linux binary inside the FreeBSD build system. I target powerpc64, arm64 and aarch64 (with plans for armv7 maybe and riscv64 for sure). They all have different system call numbers, slightly different system call encodings and the ERRNOs are different > 34, with not all the errnos defined on all five of these architectures. There's also variation in how the different structures one passes to system calls are laid out such that I need to have different arch .h files to describe them (cf stat, dirent, termios). There are generic versions, but even this small selection of architectures has departures for some or all of them from the generics. All of that is from this year, using only ELF binaries and trying like heck to avoid the oldest, legacy system calls and using only the newer ones that aren't crazy to use. Of course, that's all "chump change" in this project since the evolved kexec interface on Linux is somewhat different between architectures, involves many special magic things you just have to know to use, and is rather Linux centric... And also the evolved FreeBSD per-arch boot interface, which has all those things, but with somewhat different details and somewhat FreeBSD centric... Warner > [1] https://www.linux.co.cr/free-unix-os/review/acrobat/940612.pdf > > Story time: at one point in the early 90's, MIT purchased a site > license for a proprietary spreadsheet product for ISC Unix, which we > planned to run on Linux systems at MIT using iBCS2. When I contacted > Michael Johnson[2], the engineer at that company to implement support > for the site license ---- which was going to rely on checking the IP > address on the system to see if it was 18.x.y.z --- I found out that > Michael built and tested the spreadsheet using Linux with iBCS2 > emulation, and only *later* made sure it would actually run on ISC > Unix, because Linux was a much more pleasant development environment > than the System V alternatives. :-) > > [2] Michael later was one of the founders of Red Hat. > > In any case, while in practice some platforms use a unique set of code > points for system calls and signal numbers (thos are mostly the older > architectures which exist mostly for historic interest), most > platforms which run Linux today actually use a consistent set of > system call and signal numbers. > > That being said, we did implement many of the System V extensions, > mostly because there was demand from the proprietary software vendors > who needed to be convinced to port their applications from Solars, > HPUX, AIX, etc., to Linux. > > Mercifully, Linux never implemented Streams (thank $DEITY Oracle > didn't make that a requirement :-) and we did have BSD job control > from the earliest days. That happened because in early 1992, I > considered Job Control to be a highly important feature that Linux > **had** to have, and so I sat down with the POSIX.1 specification, and > implemented job control from the spec. The reason why Linux's tty > layer has a bit of a System V "flavor" at least from a system call > perspective has nothing to do the system call ABI, and more to do with > the fact that apparently representatives from System V derivatives > seemed to have a dominant role on the POSIX committee. > > - Ted > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Jan 31 07:10:14 2023 From: clemc at ccc.com (Clem Cole) Date: Mon, 30 Jan 2023 16:10:14 -0500 Subject: [TUHS] FD 2 In-Reply-To: References: <202301300750.30U7oQTh013304@freefriends.org> <20230130150219.GD12306@mcvoy.com> <20230130152703.GE12306@mcvoy.com> <20230130154555.GF12306@mcvoy.com> Message-ID: On Mon, Jan 30, 2023 at 3:39 PM Theodore Ts'o wrote: > apparently representatives from System V derivatives > seemed to have a dominant role on the POSIX committee. > I can personally attest (having been in the room during many of that those discussions) this is a true statement. The early versions (certainly thru .1 - the original system called Interface), AT&T team, and a number of vendors particularly the European ones - tried hard to push the SVID to be POSIX, although many of us had used a lot of BSD in our systems fought back. Can not say it was a fun time. The problem was everyone in the room wanted to be the big dog and to have all the food -- no one could really admit that we were all in it together and the real competition was elsewhere. FWIW: Keith Bostic occasionally came to some of those meetings from CSRG to some of those meetings and was amazingly gracious/patient. It's why 4.4 had a number of things in that made it closer to POSIX. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Tue Jan 31 07:24:34 2023 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 30 Jan 2023 13:24:34 -0800 Subject: [TUHS] FD 2 In-Reply-To: References: <202301300750.30U7oQTh013304@freefriends.org> <20230130150219.GD12306@mcvoy.com> <20230130152703.GE12306@mcvoy.com> <20230130154555.GF12306@mcvoy.com> <20230130161846.GH12306@mcvoy.com> Message-ID: <20230130212434.GL12306@mcvoy.com> On Mon, Jan 30, 2023 at 02:03:32PM -0500, Dan Cross wrote: > On Mon, Jan 30, 2023 at 11:18 AM Larry McVoy wrote: > > On Mon, Jan 30, 2023 at 11:09:03AM -0500, Dan Cross wrote: > > > On Mon, Jan 30, 2023 at 10:45 AM Larry McVoy wrote: > > > > On Mon, Jan 30, 2023 at 10:35:25AM -0500, Dan Cross wrote: > > > > > Plan 9 was different, and a lot of people who were familiar with Unix > > > > > didn't like that, and were not interested in trying out a different > > > > > way if it meant that they couldn't bring their existing mental models > > > > > and workflows into the new environment unchanged. > > > > > > > > > > At one point it struck me that Plan 9 didn't succeed as a widespread > > > > > replacement for Unix/Linux because it was bad or incapable, but > > > > > rather, because people wanted Linux, and not plan9. > > > > > > > > Many people make that mistake. New stuff instead of extend old stuff. > > > > > > Some would argue that's not a mistake. How else do we innovate if > > > we're just incrementally polishing what's come before? > > > > I didn't say limit yourself to polishing, I said try and not invalidate > > people's knowledge while innovating. > > > > Too many people go down the path of doing things very differently and > > they rationalize that they have to do it that way to innovate. That's > > fine but it means it is going to be harder to get people to try your > > new stuff. > > > > The point I'm trying to make is that "different" is a higher barrier, > > much, much higher, than "extend". People frequently ignore that and > > that means other people ignore their work. > > > > It is what it is, I doubt I'll convice anyone so I'll drop it. > > Oh, I don't know. I think it's actually kind of important to see _why_ > people didn't want to look deeper into plan9 (for example). The system > had a lot to offer, but you had to dig a bit to get into it; a lot of > folks never got that far. If it was really lack of job control, then > that's a shame. It's certainly not just job control. I think it's a combo of being unfamiliar, no source (at first I believe) and Linux was already pretty far along. The lesson is that if there is an installed base, and you want people to move, you have to make that easy and there has to be a noticeable gain. Plan 9 sounded cool to me but Linux was easy. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From stuff at riddermarkfarm.ca Tue Jan 31 07:37:45 2023 From: stuff at riddermarkfarm.ca (Stuff Received) Date: Mon, 30 Jan 2023 16:37:45 -0500 Subject: [TUHS] yet another C discussion (YACD) and: Rust is not C++ In-Reply-To: References: Message-ID: <9f37402c-6773-deb6-651e-0287bf100bfd@riddermarkfarm.ca> On 2023-01-30 14:35, ron minnich wrote (in part): > As for replacing C, the velocity of Rust is just astonishing. I think > folks have been waiting for something to replace C for a long time, and > Rust, with all its headaches and issues, is likely to be that thing. Of possible interest: https://devclass.com/2023/01/23/rust-has-no-formal-specification-and-it-is-time-that-was-fixed-says-team-which-longs-for-formalized-type-system/ N. From tuhs at tuhs.org Tue Jan 31 07:40:41 2023 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Tue, 31 Jan 2023 07:40:41 +1000 Subject: [TUHS] Thread Drift Message-ID: All, w.r.t. FD 2, if your e-mail doesn't mention file descriptors, can you please change the subject line? And this, in general, for all TUHS discussions :-) Thanks! Warren From robpike at gmail.com Tue Jan 31 08:15:56 2023 From: robpike at gmail.com (Rob Pike) Date: Tue, 31 Jan 2023 09:15:56 +1100 Subject: [TUHS] FD 2 In-Reply-To: <20230130212434.GL12306@mcvoy.com> References: <202301300750.30U7oQTh013304@freefriends.org> <20230130150219.GD12306@mcvoy.com> <20230130152703.GE12306@mcvoy.com> <20230130154555.GF12306@mcvoy.com> <20230130161846.GH12306@mcvoy.com> <20230130212434.GL12306@mcvoy.com> Message-ID: There was Plan 9 source available, but the early releases were in the AT&T Unix mode and required some payment or academic connection. The early demo disks might not have had source - I don't remember - but if not, there was simply no room on a floppy. The CD releases had full source. Plan 9 was a research system. It was hoped that maybe one day it would become a commercial success, but that was never the prime motivation. It only "failed" as a product, and there are many contributing factors there, including existing systems that were good enough, a desire for people to have "workstations" and ignore the benefits of a completing window UI on a mainframe (Cray was an exception, earlier), and AT&T lawyers refusing to think realistically about open source (about as polite a way I can express a multiyear fight that never ended, only fizzled into stalemate). As a research system, Plan 9 was a huge success. We're still talking about its ideas 30+ years on. -rob On Tue, Jan 31, 2023 at 8:24 AM Larry McVoy wrote: > On Mon, Jan 30, 2023 at 02:03:32PM -0500, Dan Cross wrote: > > On Mon, Jan 30, 2023 at 11:18 AM Larry McVoy wrote: > > > On Mon, Jan 30, 2023 at 11:09:03AM -0500, Dan Cross wrote: > > > > On Mon, Jan 30, 2023 at 10:45 AM Larry McVoy wrote: > > > > > On Mon, Jan 30, 2023 at 10:35:25AM -0500, Dan Cross wrote: > > > > > > Plan 9 was different, and a lot of people who were familiar with > Unix > > > > > > didn't like that, and were not interested in trying out a > different > > > > > > way if it meant that they couldn't bring their existing mental > models > > > > > > and workflows into the new environment unchanged. > > > > > > > > > > > > At one point it struck me that Plan 9 didn't succeed as a > widespread > > > > > > replacement for Unix/Linux because it was bad or incapable, but > > > > > > rather, because people wanted Linux, and not plan9. > > > > > > > > > > Many people make that mistake. New stuff instead of extend old > stuff. > > > > > > > > Some would argue that's not a mistake. How else do we innovate if > > > > we're just incrementally polishing what's come before? > > > > > > I didn't say limit yourself to polishing, I said try and not invalidate > > > people's knowledge while innovating. > > > > > > Too many people go down the path of doing things very differently and > > > they rationalize that they have to do it that way to innovate. That's > > > fine but it means it is going to be harder to get people to try your > > > new stuff. > > > > > > The point I'm trying to make is that "different" is a higher barrier, > > > much, much higher, than "extend". People frequently ignore that and > > > that means other people ignore their work. > > > > > > It is what it is, I doubt I'll convice anyone so I'll drop it. > > > > Oh, I don't know. I think it's actually kind of important to see _why_ > > people didn't want to look deeper into plan9 (for example). The system > > had a lot to offer, but you had to dig a bit to get into it; a lot of > > folks never got that far. If it was really lack of job control, then > > that's a shame. > > It's certainly not just job control. I think it's a combo of being > unfamiliar, no source (at first I believe) and Linux was already > pretty far along. > > The lesson is that if there is an installed base, and you want people > to move, you have to make that easy and there has to be a noticeable > gain. Plan 9 sounded cool to me but Linux was easy. > -- > --- > Larry McVoy Retired to fishing > http://www.mcvoy.com/lm/boat > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Tue Jan 31 08:50:37 2023 From: rminnich at gmail.com (ron minnich) Date: Mon, 30 Jan 2023 14:50:37 -0800 Subject: [TUHS] FD 2 In-Reply-To: References: <202301300750.30U7oQTh013304@freefriends.org> <20230130150219.GD12306@mcvoy.com> <20230130152703.GE12306@mcvoy.com> <20230130154555.GF12306@mcvoy.com> <20230130161846.GH12306@mcvoy.com> <20230130212434.GL12306@mcvoy.com> Message-ID: It's a long list of ideas that came from Plan 9 into Unix. One of those wonderful plan 9 ideas, the cpu command, with all it implies, has new life: github.com/u-root/cpu. Several companies are using the cpu command as the basis of light weight VM and edge environments, for example. Also, rfork went into freebsd ca 1996, and it's still there. Al Viro, IIRC, put some stuff into his VFS ca 1998 that specifically came from plan 9, including private mounts. We used them at LANL to build private name spaces for cluster nodes, over 9p, as part of Clustermatic. Some core ideas of controlling subsystems via writable synthetics also made it in. And on and on. On Mon, Jan 30, 2023 at 2:17 PM Rob Pike wrote: > There was Plan 9 source available, but the early releases were in the AT&T > Unix mode and required some payment or academic connection. The early demo > disks might not have had source - I don't remember - but if not, there was > simply no room on a floppy. The CD releases had full source. > > Plan 9 was a research system. It was hoped that maybe one day it would > become a commercial success, but that was never the prime motivation. It > only "failed" as a product, and there are many contributing factors there, > including existing systems that were good enough, a desire for people to > have "workstations" and ignore the benefits of a completing window UI on a > mainframe (Cray was an exception, earlier), and AT&T lawyers refusing to > think realistically about open source (about as polite a way I can express > a multiyear fight that never ended, only fizzled into stalemate). > > As a research system, Plan 9 was a huge success. We're still talking about > its ideas 30+ years on. > > -rob > > > On Tue, Jan 31, 2023 at 8:24 AM Larry McVoy wrote: > >> On Mon, Jan 30, 2023 at 02:03:32PM -0500, Dan Cross wrote: >> > On Mon, Jan 30, 2023 at 11:18 AM Larry McVoy wrote: >> > > On Mon, Jan 30, 2023 at 11:09:03AM -0500, Dan Cross wrote: >> > > > On Mon, Jan 30, 2023 at 10:45 AM Larry McVoy wrote: >> > > > > On Mon, Jan 30, 2023 at 10:35:25AM -0500, Dan Cross wrote: >> > > > > > Plan 9 was different, and a lot of people who were familiar >> with Unix >> > > > > > didn't like that, and were not interested in trying out a >> different >> > > > > > way if it meant that they couldn't bring their existing mental >> models >> > > > > > and workflows into the new environment unchanged. >> > > > > > >> > > > > > At one point it struck me that Plan 9 didn't succeed as a >> widespread >> > > > > > replacement for Unix/Linux because it was bad or incapable, but >> > > > > > rather, because people wanted Linux, and not plan9. >> > > > > >> > > > > Many people make that mistake. New stuff instead of extend old >> stuff. >> > > > >> > > > Some would argue that's not a mistake. How else do we innovate if >> > > > we're just incrementally polishing what's come before? >> > > >> > > I didn't say limit yourself to polishing, I said try and not >> invalidate >> > > people's knowledge while innovating. >> > > >> > > Too many people go down the path of doing things very differently and >> > > they rationalize that they have to do it that way to innovate. That's >> > > fine but it means it is going to be harder to get people to try your >> > > new stuff. >> > > >> > > The point I'm trying to make is that "different" is a higher barrier, >> > > much, much higher, than "extend". People frequently ignore that and >> > > that means other people ignore their work. >> > > >> > > It is what it is, I doubt I'll convice anyone so I'll drop it. >> > >> > Oh, I don't know. I think it's actually kind of important to see _why_ >> > people didn't want to look deeper into plan9 (for example). The system >> > had a lot to offer, but you had to dig a bit to get into it; a lot of >> > folks never got that far. If it was really lack of job control, then >> > that's a shame. >> >> It's certainly not just job control. I think it's a combo of being >> unfamiliar, no source (at first I believe) and Linux was already >> pretty far along. >> >> The lesson is that if there is an installed base, and you want people >> to move, you have to make that easy and there has to be a noticeable >> gain. Plan 9 sounded cool to me but Linux was easy. >> -- >> --- >> Larry McVoy Retired to fishing >> http://www.mcvoy.com/lm/boat >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Tue Jan 31 09:05:05 2023 From: bakul at iitbombay.org (Bakul Shah) Date: Mon, 30 Jan 2023 15:05:05 -0800 Subject: [TUHS] Child of plan9? (Re: FD 2 In-Reply-To: References: <202301300750.30U7oQTh013304@freefriends.org> <20230130150219.GD12306@mcvoy.com> <20230130152703.GE12306@mcvoy.com> <20230130154555.GF12306@mcvoy.com> <20230130161846.GH12306@mcvoy.com> <20230130212434.GL12306@mcvoy.com> Message-ID: This wish is perhaps shared by no one else but I'd still love to have a system where the kernel has the clean architectural lines of plan9 + more good stuff from it, and a Unixy API for many existing programs, perhaps as a shared lib. And I don't want all the heft of BSD or Linux kernels! Now this may be quite impractical (like trying to make C as safe as Rust) but that is what I want! I just think there is a lot more here that can be explored further. > On Jan 30, 2023, at 2:15 PM, Rob Pike wrote: > > There was Plan 9 source available, but the early releases were in the AT&T Unix mode and required some payment or academic connection. The early demo disks might not have had source - I don't remember - but if not, there was simply no room on a floppy. The CD releases had full source. > > Plan 9 was a research system. It was hoped that maybe one day it would become a commercial success, but that was never the prime motivation. It only "failed" as a product, and there are many contributing factors there, including existing systems that were good enough, a desire for people to have "workstations" and ignore the benefits of a completing window UI on a mainframe (Cray was an exception, earlier), and AT&T lawyers refusing to think realistically about open source (about as polite a way I can express a multiyear fight that never ended, only fizzled into stalemate). > > As a research system, Plan 9 was a huge success. We're still talking about its ideas 30+ years on. > > -rob > > > On Tue, Jan 31, 2023 at 8:24 AM Larry McVoy wrote: > On Mon, Jan 30, 2023 at 02:03:32PM -0500, Dan Cross wrote: > > On Mon, Jan 30, 2023 at 11:18 AM Larry McVoy wrote: > > > On Mon, Jan 30, 2023 at 11:09:03AM -0500, Dan Cross wrote: > > > > On Mon, Jan 30, 2023 at 10:45 AM Larry McVoy wrote: > > > > > On Mon, Jan 30, 2023 at 10:35:25AM -0500, Dan Cross wrote: > > > > > > Plan 9 was different, and a lot of people who were familiar with Unix > > > > > > didn't like that, and were not interested in trying out a different > > > > > > way if it meant that they couldn't bring their existing mental models > > > > > > and workflows into the new environment unchanged. > > > > > > > > > > > > At one point it struck me that Plan 9 didn't succeed as a widespread > > > > > > replacement for Unix/Linux because it was bad or incapable, but > > > > > > rather, because people wanted Linux, and not plan9. > > > > > > > > > > Many people make that mistake. New stuff instead of extend old stuff. > > > > > > > > Some would argue that's not a mistake. How else do we innovate if > > > > we're just incrementally polishing what's come before? > > > > > > I didn't say limit yourself to polishing, I said try and not invalidate > > > people's knowledge while innovating. > > > > > > Too many people go down the path of doing things very differently and > > > they rationalize that they have to do it that way to innovate. That's > > > fine but it means it is going to be harder to get people to try your > > > new stuff. > > > > > > The point I'm trying to make is that "different" is a higher barrier, > > > much, much higher, than "extend". People frequently ignore that and > > > that means other people ignore their work. > > > > > > It is what it is, I doubt I'll convice anyone so I'll drop it. > > > > Oh, I don't know. I think it's actually kind of important to see _why_ > > people didn't want to look deeper into plan9 (for example). The system > > had a lot to offer, but you had to dig a bit to get into it; a lot of > > folks never got that far. If it was really lack of job control, then > > that's a shame. > > It's certainly not just job control. I think it's a combo of being > unfamiliar, no source (at first I believe) and Linux was already > pretty far along. > > The lesson is that if there is an installed base, and you want people > to move, you have to make that easy and there has to be a noticeable > gain. Plan 9 sounded cool to me but Linux was easy. > -- > --- > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From alx.manpages at gmail.com Tue Jan 31 11:47:18 2023 From: alx.manpages at gmail.com (Alejandro Colomar) Date: Tue, 31 Jan 2023 02:47:18 +0100 Subject: [TUHS] yet another C discussion (YACD) and: Rust is not C++ In-Reply-To: References: Message-ID: Hello Ron, On 1/30/23 20:35, ron minnich wrote: > I don't know how many ways there are to say this, but Rust and C/C++ are > fundamentally different at the lowest level. > > If you are just looking at Rust syntax in a superficial way, you might be > excused for thinking it's "C with features / C++ with differences." > > But that's not how it is. It's like saying C is "just like assembly" because > labels have a ':' in them; or that Unix is "just like RSX" because they have > vaguely similar commands. > > Here's a real question that came up where I work: should the code shown below be > accepted (this is abstracted from a real example that is in use ... everywhere)? > We had one code analyzer that said, emphatically, NO; one person said YES, > another MAYBE. One piece of code, 3 answers :-) > > char f() { > > char *y; > > g(&y); > > return *y; > > } > > > A specific question: should y be initialized to NULL? No. At least not if you don't want to use the value NULL in your program. Using NULL as something to avoid Undefined Behavior is wrong, and it will contribute to hide programmer errors. These days, compilers and static analyzers are smart enough to detect uninitialized variables, even across Translation Units, and throw an error, letting the programmer fix such bugs, when they occur. The practice of initializing always to NULL and 0 provides no value, and silences all of those warnings, thus creating silent bugs, that will bite some cold winter night. I know some static analyzers (e.g., clang-tidy(1)) do warn when you don't initialize variables and especially pointers (well, you need to enable the warning that does that, but it can warn). That warning is there due to some coding style or certifications that require it. I recommend disabling those bogus warnings, and forgetting about the bogus coding style or certification that requires you to write bogus code. > The case to set y to NULL: otherwise it has an unknown value and it's unsafe. Is an undefined value less safe than an unexpected one? I don't think so. At least compilers can detect the former, but not the latter. > The case against setting y to NULL: it is pointless, as it slows the code down > slightly and g is going to change it anyway. Performance is a very minor thing. But it's a nice side-effect that doing the right thing has performance advantages. Readability is a good reason (and in fact, the compiler suffers that readability too, which is the cause of the silencing of the wanted warnings. > The case maybe: Why do you trust g() to always set it? Why don't you trust g()? > convince me. Well, it depends on the contract of g(). If the contract is that it may not initialize the variable, then sure, initialize it yourself, or even better, check for g()'s errors, and react when it fails and doesn't initialize it. If the contract is that it should always initialize it, then trust it blindly. The compiler will tell you when it doesn't happen (that is, when g() has a bug). > > You can't write this in Rust with this ambiguity. It won't compile. In fact, & > doesn't mean in Rust what it does in C. I don't know Rust. Does it force NULL initialization? If so, I guess it's a bad design choice. Unless Rust is so different that it can detect such programmer errors even having defined default initialization, but I can't imagine how that is. > > Sorry to be such a pedant, but I was concerned that we not fall into the "Rust > is C++ all over again" trap. > > As for replacing C, the velocity of Rust is just astonishing. I think folks have > been waiting for something to replace C for a long time, and Rust, with all its > headaches and issues, is likely to be that thing. Modern C is receiving a lot of improvements from C++ and other languages. It's getting really good in fixing the small issues it had in the past (and GNU C provides even more good things). GNU C2x is quite safe and readable, compared to say ISO C99 versions. I don't think C will ever be replaced. And I hope it doesn't. Possibly, something like with Plan9 and Unix/Linux will happen. The good things from other languages will come back in one form or another to C. The not-so-good ones will be discarded. > > Personally, I still prefer Go, but I can also see which way the wind is blowing, > especially when I see Rust use exploding in firmware and user mode, and now even > in the Linux kernel. Cheers, Alex From mah at mhorton.net Tue Jan 31 12:03:30 2023 From: mah at mhorton.net (Mary Ann Horton) Date: Mon, 30 Jan 2023 18:03:30 -0800 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: <23432965-52D6-4331-A4D8-8A6FDDB3F751@serissa.com> References: <23432965-52D6-4331-A4D8-8A6FDDB3F751@serissa.com> Message-ID: <1be17de9-b39a-0dfe-5959-94379f93f830@mhorton.net> On 1/25/23 17:01, Larry Stewart wrote: > Jim Morris left PARC and went off to CMU and began talking up the idea > of the "3M" workstation.  One MIPs, One Megabyte of RAM, and One > Million Pixels. The way I heard it, a workstation needed to have Menus, a Mouse, and a 1 MIPS processor. It also had a megabyte of RAM, at least a megabit LAN, a megapixel of display, and cost about a megapenny. Thanks, /Mary Ann Horton/ (she/her/ma'am) maryannhorton.com "This is a great book" - Monica Helms "Brave and Important" - Laura L. Engel       Available on Amazon and bn.com! -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Tue Jan 31 12:55:58 2023 From: crossd at gmail.com (Dan Cross) Date: Mon, 30 Jan 2023 21:55:58 -0500 Subject: [TUHS] yet another C discussion (YACD) and: Rust is not C++ In-Reply-To: References: Message-ID: On Mon, Jan 30, 2023 at 8:49 PM Alejandro Colomar wrote: > Hello Ron, > > On 1/30/23 20:35, ron minnich wrote: > > I don't know how many ways there are to say this, but Rust and C/C++ are > > fundamentally different at the lowest level. > > > > If you are just looking at Rust syntax in a superficial way, you might be > > excused for thinking it's "C with features / C++ with differences." > > > > But that's not how it is. It's like saying C is "just like assembly" because > > labels have a ':' in them; or that Unix is "just like RSX" because they have > > vaguely similar commands. > > > > Here's a real question that came up where I work: should the code shown below be > > accepted (this is abstracted from a real example that is in use ... everywhere)? > > We had one code analyzer that said, emphatically, NO; one person said YES, > > another MAYBE. One piece of code, 3 answers :-) > > > > char f() { > > char *y; > > g(&y); > > return *y; > > } > > > > > > A specific question: should y be initialized to NULL? > > No. At least not if you don't want to use the value NULL in your program. > Using NULL as something to avoid Undefined Behavior is wrong, and it will > contribute to hide programmer errors. Sorry, I think this misses the point: how do you meaningfully tell that `g` did something to `y` so that it's safe to indirect in the `return`? On the other hand, one could write, char f() { char *y = NULL; g(&y); if (y == NULL) panic("g failed"); return *y; } C, of course, can't tell in the original. And while you can now tell that `g` did _something_ to `y`, you still really don't know that `y` points to something valid. > These days, compilers and static analyzers are smart enough to detect > uninitialized variables, even across Translation Units, and throw an error, > letting the programmer fix such bugs, when they occur. In many cases, yes, but not in all. That would be equivalent to solving the halting problem. > The practice of initializing always to NULL and 0 provides no value, and > silences all of those warnings, thus creating silent bugs, that will bite some > cold winter night. > > I know some static analyzers (e.g., clang-tidy(1)) do warn when you don't > initialize variables and especially pointers (well, you need to enable the > warning that does that, but it can warn). That warning is there due to some > coding style or certifications that require it. I recommend disabling those > bogus warnings, and forgetting about the bogus coding style or certification > that requires you to write bogus code. Oh my. > > The case to set y to NULL: otherwise it has an unknown value and it's unsafe. > > Is an undefined value less safe than an unexpected one? I don't think so. At > least compilers can detect the former, but not the latter. > > > The case against setting y to NULL: it is pointless, as it slows the code down > > slightly and g is going to change it anyway. > > Performance is a very minor thing. But it's a nice side-effect that doing the > right thing has performance advantages. Readability is a good reason (and in > fact, the compiler suffers that readability too, which is the cause of the > silencing of the wanted warnings. > > > The case maybe: Why do you trust g() to always set it? Why don't you trust g()? > > convince me. > > Well, it depends on the contract of g(). If the contract is that it may not > initialize the variable, then sure, initialize it yourself, or even better, > check for g()'s errors, and react when it fails and doesn't initialize it. > > If the contract is that it should always initialize it, then trust it blindly. > The compiler will tell you when it doesn't happen (that is, when g() has a bug). The number of situations where the compiler can't tell whether `g` has a bug is unbounded. > > You can't write this in Rust with this ambiguity. It won't compile. In fact, & > > doesn't mean in Rust what it does in C. > > I don't know Rust. Does it force NULL initialization? If so, I guess it's a > bad design choice. Unless Rust is so different that it can detect such > programmer errors even having defined default initialization, but I can't > imagine how that is. Rust enforces that all variables must be initialized prior to use. Whether they're initialized with a zero value or something else is up to the programmer; but not initializing is a compile-time error. For example: | fn main() { | let x; | if thing_is_true() { | x = 5; | } else { | x = 3; | } | println!("x={x}"); | } In fact, this is good; this allows us to employ a technique called, "Type-Driven Development", whereby we can create some type that encodes an invariant about the object. An object of that type is written in such a way that once it has been initialized, the mere existence of the object is sufficient to prove that the invariant holds, and need not be retested whenever the object is used. For example: | #[repr(transparent)] | struct PageFrameAddr(u64); | impl PageFrameAddr { | fn new_round_down(addr: u64) -> PageFrameAddr { | PageFrameAddr(addr & !0xFFF) | } | } Here, "PageFrameAddr" contains a 4KiB-aligned page address. Since the only way to create one of these is by the, `new_round_down` associated method that masks off the low bits, we can be sure that if we get one of these, the contained address is properly aligned. In C, we'd pretty much have to test at the site of use. This is an extremely powerful technique; cf Alexis King's blog post, "Parse Don't Validate" (https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/) and Cliff Biffle's talk on the Hubris embedded RTOS (https://talks.osfc.io/osfc2021/talk/JTWYEH/). > > Sorry to be such a pedant, but I was concerned that we not fall into the "Rust > > is C++ all over again" trap. > > > > As for replacing C, the velocity of Rust is just astonishing. I think folks have > > been waiting for something to replace C for a long time, and Rust, with all its > > headaches and issues, is likely to be that thing. > > Modern C is receiving a lot of improvements from C++ and other languages. It's > getting really good in fixing the small issues it had in the past (and GNU C > provides even more good things). GNU C2x is quite safe and readable, compared > to say ISO C99 versions. C23 looks like it will be a better language that C11, but I don't know that even JeanHeyd would suggest it's "quite safe". :-/ - Dan C. > I don't think C will ever be replaced. And I hope it doesn't. > > Possibly, something like with Plan9 and Unix/Linux will happen. The good things > from other languages will come back in one form or another to C. The > not-so-good ones will be discarded. > > > > > Personally, I still prefer Go, but I can also see which way the wind is blowing, > > especially when I see Rust use exploding in firmware and user mode, and now even > > in the Linux kernel. > > Cheers, > > Alex From andreww591 at gmail.com Tue Jan 31 13:19:00 2023 From: andreww591 at gmail.com (Andrew Warkentin) Date: Mon, 30 Jan 2023 20:19:00 -0700 Subject: [TUHS] Child of plan9? (Re: FD 2 In-Reply-To: References: <202301300750.30U7oQTh013304@freefriends.org> <20230130150219.GD12306@mcvoy.com> <20230130152703.GE12306@mcvoy.com> <20230130154555.GF12306@mcvoy.com> <20230130161846.GH12306@mcvoy.com> <20230130212434.GL12306@mcvoy.com> Message-ID: On 1/30/23, Bakul Shah wrote: > This wish is perhaps shared by no one else but I'd still love to have a > system where the kernel has the clean > architectural lines of plan9 + more good stuff from it, and a Unixy API for > many existing programs, perhaps as a shared lib. And I don't want all the > heft of BSD or Linux kernels! > > Now this may be quite impractical (like trying to make C as safe as Rust) > but that is what I want! I just think there is a lot more here that can be > explored further. > I'm writing something sort of like that. Specifically it will be a QNX-like OS in which literally everything is a file (even all process state and memory), with pretty much the only real primitives being variants of read()/write(), and everything else will be built on top of those (even other file APIs like open()/close()/stat()). The user-level API will be mostly compatible with conventional Unix, but will be split into multiple libraries rather than throwing everything in libc (there will be a base system library implementing the core file API, and libc and a few other libraries implementing a relatively standard Unix API will sit on top of this). From rminnich at gmail.com Tue Jan 31 13:59:43 2023 From: rminnich at gmail.com (ron minnich) Date: Mon, 30 Jan 2023 19:59:43 -0800 Subject: [TUHS] yet another C discussion (YACD) and: Rust is not C++ In-Reply-To: References: Message-ID: That example was a simplified bit of code from a widely used code base. All I need to do is change the function g go a pointer to function, or have it be provided by a .so, and all bets are off. In any event, the important thing here is not that y should be initialized, or should not; it's that it is not possible to get a consistent answer on the question, from people who have been writing in C for decades. ron On Mon, Jan 30, 2023 at 6:56 PM Dan Cross wrote: > On Mon, Jan 30, 2023 at 8:49 PM Alejandro Colomar > wrote: > > Hello Ron, > > > > On 1/30/23 20:35, ron minnich wrote: > > > I don't know how many ways there are to say this, but Rust and C/C++ > are > > > fundamentally different at the lowest level. > > > > > > If you are just looking at Rust syntax in a superficial way, you might > be > > > excused for thinking it's "C with features / C++ with differences." > > > > > > But that's not how it is. It's like saying C is "just like assembly" > because > > > labels have a ':' in them; or that Unix is "just like RSX" because > they have > > > vaguely similar commands. > > > > > > Here's a real question that came up where I work: should the code > shown below be > > > accepted (this is abstracted from a real example that is in use ... > everywhere)? > > > We had one code analyzer that said, emphatically, NO; one person said > YES, > > > another MAYBE. One piece of code, 3 answers :-) > > > > > > char f() { > > > char *y; > > > g(&y); > > > return *y; > > > } > > > > > > > > > A specific question: should y be initialized to NULL? > > > > No. At least not if you don't want to use the value NULL in your > program. > > Using NULL as something to avoid Undefined Behavior is wrong, and it will > > contribute to hide programmer errors. > > Sorry, I think this misses the point: how do you meaningfully tell > that `g` did something to `y` so that it's safe to indirect in the > `return`? > > On the other hand, one could write, > > char f() { > char *y = NULL; > g(&y); > if (y == NULL) > panic("g failed"); > return *y; > } > > C, of course, can't tell in the original. And while you can now tell > that `g` did _something_ to `y`, you still really don't know that `y` > points to something valid. > > > These days, compilers and static analyzers are smart enough to detect > > uninitialized variables, even across Translation Units, and throw an > error, > > letting the programmer fix such bugs, when they occur. > > In many cases, yes, but not in all. That would be equivalent to > solving the halting problem. > > > The practice of initializing always to NULL and 0 provides no value, and > > silences all of those warnings, thus creating silent bugs, that will > bite some > > cold winter night. > > > > I know some static analyzers (e.g., clang-tidy(1)) do warn when you don't > > initialize variables and especially pointers (well, you need to enable > the > > warning that does that, but it can warn). That warning is there due to > some > > coding style or certifications that require it. I recommend disabling > those > > bogus warnings, and forgetting about the bogus coding style or > certification > > that requires you to write bogus code. > > Oh my. > > > > The case to set y to NULL: otherwise it has an unknown value and it's > unsafe. > > > > Is an undefined value less safe than an unexpected one? I don't think > so. At > > least compilers can detect the former, but not the latter. > > > > > The case against setting y to NULL: it is pointless, as it slows the > code down > > > slightly and g is going to change it anyway. > > > > Performance is a very minor thing. But it's a nice side-effect that > doing the > > right thing has performance advantages. Readability is a good reason > (and in > > fact, the compiler suffers that readability too, which is the cause of > the > > silencing of the wanted warnings. > > > > > The case maybe: Why do you trust g() to always set it? Why don't you > trust g()? > > > convince me. > > > > Well, it depends on the contract of g(). If the contract is that it may > not > > initialize the variable, then sure, initialize it yourself, or even > better, > > check for g()'s errors, and react when it fails and doesn't initialize > it. > > > > If the contract is that it should always initialize it, then trust it > blindly. > > The compiler will tell you when it doesn't happen (that is, when g() has > a bug). > > The number of situations where the compiler can't tell whether `g` has > a bug is unbounded. > > > > You can't write this in Rust with this ambiguity. It won't compile. In > fact, & > > > doesn't mean in Rust what it does in C. > > > > I don't know Rust. Does it force NULL initialization? If so, I guess > it's a > > bad design choice. Unless Rust is so different that it can detect such > > programmer errors even having defined default initialization, but I can't > > imagine how that is. > > Rust enforces that all variables must be initialized prior to use. > Whether they're initialized with a zero value or something else is up > to the programmer; but not initializing is a compile-time error. > > For example: > > | fn main() { > | let x; > | if thing_is_true() { > | x = 5; > | } else { > | x = 3; > | } > | println!("x={x}"); > | } > > In fact, this is good; this allows us to employ a technique called, > "Type-Driven Development", whereby we can create some type that > encodes an invariant about the object. An object of that type is > written in such a way that once it has been initialized, the mere > existence of the object is sufficient to prove that the invariant > holds, and need not be retested whenever the object is used. For > example: > > | #[repr(transparent)] > | struct PageFrameAddr(u64); > | impl PageFrameAddr { > | fn new_round_down(addr: u64) -> PageFrameAddr { > | PageFrameAddr(addr & !0xFFF) > | } > | } > > Here, "PageFrameAddr" contains a 4KiB-aligned page address. Since the > only way to create one of these is by the, `new_round_down` associated > method that masks off the low bits, we can be sure that if we get one > of these, the contained address is properly aligned. In C, we'd > pretty much have to test at the site of use. > > This is an extremely powerful technique; cf Alexis King's blog post, > "Parse Don't Validate" > (https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/) > and Cliff Biffle's talk on the Hubris embedded RTOS > (https://talks.osfc.io/osfc2021/talk/JTWYEH/). > > > > Sorry to be such a pedant, but I was concerned that we not fall into > the "Rust > > > is C++ all over again" trap. > > > > > > As for replacing C, the velocity of Rust is just astonishing. I think > folks have > > > been waiting for something to replace C for a long time, and Rust, > with all its > > > headaches and issues, is likely to be that thing. > > > > Modern C is receiving a lot of improvements from C++ and other > languages. It's > > getting really good in fixing the small issues it had in the past (and > GNU C > > provides even more good things). GNU C2x is quite safe and readable, > compared > > to say ISO C99 versions. > > C23 looks like it will be a better language that C11, but I don't know > that even JeanHeyd would suggest it's "quite safe". :-/ > > - Dan C. > > > > I don't think C will ever be replaced. And I hope it doesn't. > > > > Possibly, something like with Plan9 and Unix/Linux will happen. The > good things > > from other languages will come back in one form or another to C. The > > not-so-good ones will be discarded. > > > > > > > > Personally, I still prefer Go, but I can also see which way the wind > is blowing, > > > especially when I see Rust use exploding in firmware and user mode, > and now even > > > in the Linux kernel. > > > > Cheers, > > > > Alex > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattislind at gmail.com Tue Jan 31 17:11:29 2023 From: mattislind at gmail.com (Mattis Lind) Date: Tue, 31 Jan 2023 08:11:29 +0100 Subject: [TUHS] Unix v6 chess source code? Message-ID: Hello! I saw someone playing chess on their pdp-11 and thought it could be an interesting project to run on my pdp-11. At this point the RK05s are not yet running so booting unix v6 is not possible. I then thought that if the source code could be found it might be possible to get it to run standalone with some modifications. After some googling I found the archive https://www.tuhs.org/Archive/Distributions/UNSW/7/record0.tar.gz which contained a chess.lib file. It appeared that this archive contained source code for some kind of chess program. I have been told that it isn't the chess written by Ken Thompson so the question is who wrote it? There are not many comments in the code. Could be interesting to know more about this chess implementation. Just looking through the source files and the mk file show that it is missing a set of files. The mk file references a set of "b"-prefixed assembly files, bgen.s, bmove.s, bheur.s and bplay.s which are present in the archive. But it also references a set of files with "w"-prefix, wgen.s, wmove.s, wheur.s and wplay.s which are missing. I also recognise that there is an include file, "old.h" that is included from all c-modules that most likely is present in the overload.lib which seems to be an overlay loader. Anyone that has an idea how this thing was built once upon a time? /Mattis -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsg at jsg.id.au Tue Jan 31 19:21:58 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Tue, 31 Jan 2023 20:21:58 +1100 Subject: [TUHS] Unix v6 chess source code? In-Reply-To: References: Message-ID: On Tue, Jan 31, 2023 at 08:11:29AM +0100, Mattis Lind wrote: > Hello! > > I saw someone playing chess on their pdp-11 and thought it could be an > interesting project to run on my pdp-11. At this point the RK05s are not > yet running so booting unix v6 is not possible. > > I then thought that if the source code could be found it might be possible > to get it to run standalone with some modifications. > > After some googling I found the archive > https://www.tuhs.org/Archive/Distributions/UNSW/7/record0.tar.gz > > which contained a chess.lib file. It appeared that this archive contained > source code for some kind of chess program. I have been told that it isn't > the chess written by Ken Thompson so the question is who wrote it? There > are not many comments in the code. Could be interesting to know more about > this chess implementation. > > Just looking through the source files and the mk file show that it is > missing a set of files. The mk file references a set of "b"-prefixed > assembly files, bgen.s, bmove.s, bheur.s and bplay.s which are present in > the archive. But it also references a set of files with "w"-prefix, wgen.s, > wmove.s, wheur.s and wplay.s which are missing. > > I also recognise that there is an include file, "old.h" that is included > from all c-modules that most likely is present in the overload.lib which > seems to be an overlay loader. > > > Anyone that has an idea how this thing was built once upon a time? > > /Mattis a pre-v7 version of those files exists in tuhs/Applications/Spencer_Tapes/unsw3.tar.gz usr/source/chess tuhs/Applications/Usenix_77/ug091377.tar.gz 3/ken/chess code is the same in the above v7 chess only has a few small changes, such as seek->lseek UNSW 107, UNIX L6 Source 2 tuhs/Distributions/UNSW/107/107.tar.gz also has gt40/chess/ch.mac.z ; ; chess display for gt40 ; ; note: not a chess program, just the display ; ; probably for use with unix chess. ; From lars at nocrew.org Tue Jan 31 19:51:25 2023 From: lars at nocrew.org (Lars Brinkhoff) Date: Tue, 31 Jan 2023 09:51:25 +0000 Subject: [TUHS] Job Control and other terminal fun In-Reply-To: (Ron Natalie's message of "Mon, 30 Jan 2023 16:31:52 +0000") References: Message-ID: <7wilgn821u.fsf@junk.nocrew.org> Ron Natalie wrote: > The Berkeley job control was an interesting hack. Just to add some historical context, Berkeley job control was added by James Kulp. He had previously used ITS and copied those features pretty much as-is: ^Z does the same thing; bg and fg are named differently but work the same. > A lot of this dates back from the old “tty” days (or at least crt > terminals that were still alphanumeric). Even the concept of putting > a job in the background with & is really a feature of trying to > multiplex multiple tasks on the same dumb terminal. Indeed ITS got started in 1967 with users interacting through teletypes. Later CRT terminals were added, but the terse user interface persisted. From mattislind at gmail.com Tue Jan 31 21:00:45 2023 From: mattislind at gmail.com (Mattis Lind) Date: Tue, 31 Jan 2023 12:00:45 +0100 Subject: [TUHS] Unix v6 chess source code? In-Reply-To: References: Message-ID: > > > > a pre-v7 version of those files exists in > > tuhs/Applications/Spencer_Tapes/unsw3.tar.gz > usr/source/chess > > tuhs/Applications/Usenix_77/ug091377.tar.gz > 3/ken/chess > > code is the same in the above > > v7 chess only has a few small changes, such as seek->lseek > Thanks! Exactly what I wanted. > > UNSW 107, UNIX L6 Source 2 > tuhs/Distributions/UNSW/107/107.tar.gz also has > gt40/chess/ch.mac.z > > ; > ; chess display for gt40 > ; > ; note: not a chess program, just the display > ; > ; probably for use with unix chess. > ; > Too bad that I don't have a GT40. Would have been interesting to see. Perhaps one could do something similar with an AR11 and a VR12 display (which I do have). /Mattis -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Tue Jan 31 21:35:45 2023 From: pnr at planet.nl (Paul Ruizendaal) Date: Tue, 31 Jan 2023 12:35:45 +0100 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: References: Message-ID: <5CE95A98-E85B-4E33-9A35-A9511CF7FCD8@planet.nl> > On 30 Jan 2023, at 06:23, Jonathan Gray wrote: > > On Mon, Jan 30, 2023 at 12:20:52AM +0100, Paul Ruizendaal via TUHS wrote: >> >> >> Both the UK conference and the NeWS book mention a Unix kernel-based windowing system done at MIT in 1981 or 1982, “NU" or “NUnix”, by Jack Test. That one had not been mentioned before here and may have been the first graphical windowing work on Unix, preceding the Blit. Who remembers this one? > > mentioned in ;login: Volume 7 Number 4, September 1982 > https://archive.org/details/login_september-1982/page/24/mode/2up > Notes on the Boston USENIX and /usr/group Joint Meeting July 1982 > > "NUnix Window System Description, Jack A. Test > Laboratory for Computer Science, Massachusetts Institute of Technology, > Room 414, 545 Technology Square, Cambridge, Mass 02139 Appendix E in this report from the University of Illinois describes a port of NUnix to similar hardware. It also contains a walkthrough of a sample workstation session with 17 screen prints: https://ntrs.nasa.gov/api/citations/19840008755/downloads/19840008755.pdf Very informative. From crossd at gmail.com Tue Jan 31 22:26:51 2023 From: crossd at gmail.com (Dan Cross) Date: Tue, 31 Jan 2023 07:26:51 -0500 Subject: [TUHS] yet another C discussion (YACD) and: Rust is not C++ In-Reply-To: References: Message-ID: On Mon, Jan 30, 2023 at 10:59 PM ron minnich wrote: > That example was a simplified bit of code from a widely used code base. All I need to do is change the function g go a pointer to function, or have it be provided by a .so, and all bets are off. > > In any event, the important thing here is not that y should be initialized, or should not; it's that it is not possible to get a consistent answer on the question, from people who have been writing in C for decades. Indeed, I was agreeing with you, Ron. :-) - Dan C. > On Mon, Jan 30, 2023 at 6:56 PM Dan Cross wrote: >> >> On Mon, Jan 30, 2023 at 8:49 PM Alejandro Colomar >> wrote: >> > Hello Ron, >> > >> > On 1/30/23 20:35, ron minnich wrote: >> > > I don't know how many ways there are to say this, but Rust and C/C++ are >> > > fundamentally different at the lowest level. >> > > >> > > If you are just looking at Rust syntax in a superficial way, you might be >> > > excused for thinking it's "C with features / C++ with differences." >> > > >> > > But that's not how it is. It's like saying C is "just like assembly" because >> > > labels have a ':' in them; or that Unix is "just like RSX" because they have >> > > vaguely similar commands. >> > > >> > > Here's a real question that came up where I work: should the code shown below be >> > > accepted (this is abstracted from a real example that is in use ... everywhere)? >> > > We had one code analyzer that said, emphatically, NO; one person said YES, >> > > another MAYBE. One piece of code, 3 answers :-) >> > > >> > > char f() { >> > > char *y; >> > > g(&y); >> > > return *y; >> > > } >> > > >> > > >> > > A specific question: should y be initialized to NULL? >> > >> > No. At least not if you don't want to use the value NULL in your program. >> > Using NULL as something to avoid Undefined Behavior is wrong, and it will >> > contribute to hide programmer errors. >> >> Sorry, I think this misses the point: how do you meaningfully tell >> that `g` did something to `y` so that it's safe to indirect in the >> `return`? >> >> On the other hand, one could write, >> >> char f() { >> char *y = NULL; >> g(&y); >> if (y == NULL) >> panic("g failed"); >> return *y; >> } >> >> C, of course, can't tell in the original. And while you can now tell >> that `g` did _something_ to `y`, you still really don't know that `y` >> points to something valid. >> >> > These days, compilers and static analyzers are smart enough to detect >> > uninitialized variables, even across Translation Units, and throw an error, >> > letting the programmer fix such bugs, when they occur. >> >> In many cases, yes, but not in all. That would be equivalent to >> solving the halting problem. >> >> > The practice of initializing always to NULL and 0 provides no value, and >> > silences all of those warnings, thus creating silent bugs, that will bite some >> > cold winter night. >> > >> > I know some static analyzers (e.g., clang-tidy(1)) do warn when you don't >> > initialize variables and especially pointers (well, you need to enable the >> > warning that does that, but it can warn). That warning is there due to some >> > coding style or certifications that require it. I recommend disabling those >> > bogus warnings, and forgetting about the bogus coding style or certification >> > that requires you to write bogus code. >> >> Oh my. >> >> > > The case to set y to NULL: otherwise it has an unknown value and it's unsafe. >> > >> > Is an undefined value less safe than an unexpected one? I don't think so. At >> > least compilers can detect the former, but not the latter. >> > >> > > The case against setting y to NULL: it is pointless, as it slows the code down >> > > slightly and g is going to change it anyway. >> > >> > Performance is a very minor thing. But it's a nice side-effect that doing the >> > right thing has performance advantages. Readability is a good reason (and in >> > fact, the compiler suffers that readability too, which is the cause of the >> > silencing of the wanted warnings. >> > >> > > The case maybe: Why do you trust g() to always set it? Why don't you trust g()? >> > > convince me. >> > >> > Well, it depends on the contract of g(). If the contract is that it may not >> > initialize the variable, then sure, initialize it yourself, or even better, >> > check for g()'s errors, and react when it fails and doesn't initialize it. >> > >> > If the contract is that it should always initialize it, then trust it blindly. >> > The compiler will tell you when it doesn't happen (that is, when g() has a bug). >> >> The number of situations where the compiler can't tell whether `g` has >> a bug is unbounded. >> >> > > You can't write this in Rust with this ambiguity. It won't compile. In fact, & >> > > doesn't mean in Rust what it does in C. >> > >> > I don't know Rust. Does it force NULL initialization? If so, I guess it's a >> > bad design choice. Unless Rust is so different that it can detect such >> > programmer errors even having defined default initialization, but I can't >> > imagine how that is. >> >> Rust enforces that all variables must be initialized prior to use. >> Whether they're initialized with a zero value or something else is up >> to the programmer; but not initializing is a compile-time error. >> >> For example: >> >> | fn main() { >> | let x; >> | if thing_is_true() { >> | x = 5; >> | } else { >> | x = 3; >> | } >> | println!("x={x}"); >> | } >> >> In fact, this is good; this allows us to employ a technique called, >> "Type-Driven Development", whereby we can create some type that >> encodes an invariant about the object. An object of that type is >> written in such a way that once it has been initialized, the mere >> existence of the object is sufficient to prove that the invariant >> holds, and need not be retested whenever the object is used. For >> example: >> >> | #[repr(transparent)] >> | struct PageFrameAddr(u64); >> | impl PageFrameAddr { >> | fn new_round_down(addr: u64) -> PageFrameAddr { >> | PageFrameAddr(addr & !0xFFF) >> | } >> | } >> >> Here, "PageFrameAddr" contains a 4KiB-aligned page address. Since the >> only way to create one of these is by the, `new_round_down` associated >> method that masks off the low bits, we can be sure that if we get one >> of these, the contained address is properly aligned. In C, we'd >> pretty much have to test at the site of use. >> >> This is an extremely powerful technique; cf Alexis King's blog post, >> "Parse Don't Validate" >> (https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/) >> and Cliff Biffle's talk on the Hubris embedded RTOS >> (https://talks.osfc.io/osfc2021/talk/JTWYEH/). >> >> > > Sorry to be such a pedant, but I was concerned that we not fall into the "Rust >> > > is C++ all over again" trap. >> > > >> > > As for replacing C, the velocity of Rust is just astonishing. I think folks have >> > > been waiting for something to replace C for a long time, and Rust, with all its >> > > headaches and issues, is likely to be that thing. >> > >> > Modern C is receiving a lot of improvements from C++ and other languages. It's >> > getting really good in fixing the small issues it had in the past (and GNU C >> > provides even more good things). GNU C2x is quite safe and readable, compared >> > to say ISO C99 versions. >> >> C23 looks like it will be a better language that C11, but I don't know >> that even JeanHeyd would suggest it's "quite safe". :-/ >> >> - Dan C. >> >> >> > I don't think C will ever be replaced. And I hope it doesn't. >> > >> > Possibly, something like with Plan9 and Unix/Linux will happen. The good things >> > from other languages will come back in one form or another to C. The >> > not-so-good ones will be discarded. >> > >> > > >> > > Personally, I still prefer Go, but I can also see which way the wind is blowing, >> > > especially when I see Rust use exploding in firmware and user mode, and now even >> > > in the Linux kernel. >> > >> > Cheers, >> > >> > Alex