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: <CAEoi9W4Np=Z80NdO60x4rEPY6qKaRKYq81aCZxLXX2LAD-9iCA@mail.gmail.com>

On Fri, Dec 30, 2022 at 1:26 PM Paul Ruizendaal <pnr at planet.nl> 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: <CAEoi9W4Np=Z80NdO60x4rEPY6qKaRKYq81aCZxLXX2LAD-9iCA@mail.gmail.com>
References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl>
 <CAEoi9W4Np=Z80NdO60x4rEPY6qKaRKYq81aCZxLXX2LAD-9iCA@mail.gmail.com>
Message-ID: <CAC20D2O-fUbrCuvvzEj2Z4b2kV+J6TApYdBeMcWvPEADN-nL7w@mail.gmail.com>

On Sat, Dec 31, 2022 at 10:02 AM Dan Cross <crossd at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221231/4a533d2e/attachment.htm>

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: <CAC20D2Mv_y1038zxjT5FSxpx-WjKsJK5TfMY8ZWUiAr2JXx=RA@mail.gmail.com>

below

On Sat, Dec 31, 2022 at 1:50 PM Jon Steinhart <jon at fourwinds.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221231/cd955fb5/attachment.htm>

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: <CAEoi9W4Np=Z80NdO60x4rEPY6qKaRKYq81aCZxLXX2LAD-9iCA@mail.gmail.com>
References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl>
 <CAEoi9W4Np=Z80NdO60x4rEPY6qKaRKYq81aCZxLXX2LAD-9iCA@mail.gmail.com>
Message-ID: <45C94BFE-693D-4D86-8E4A-8DCC8C88774C@planet.nl>



> On 31 Dec 2022, at 15:59, Dan Cross <crossd at gmail.com> wrote:
> 
> On Fri, Dec 30, 2022 at 1:26 PM Paul Ruizendaal <pnr at planet.nl> 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>
 <CAEoi9W4Np=Z80NdO60x4rEPY6qKaRKYq81aCZxLXX2LAD-9iCA@mail.gmail.com>
 <45C94BFE-693D-4D86-8E4A-8DCC8C88774C@planet.nl>
Message-ID: <CANCZdfrpMmCV6wfN+3ZQ9G7bOe8sN4un_nt6UXJFvj-dq-m4+w@mail.gmail.com>

On Sat, Dec 31, 2022, 1:03 PM Paul Ruizendaal <pnr at planet.nl> wrote:

>
>
> > On 31 Dec 2022, at 15:59, Dan Cross <crossd at gmail.com> wrote:
> >
> > On Fri, Dec 30, 2022 at 1:26 PM Paul Ruizendaal <pnr at planet.nl> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221231/58dec009/attachment.htm>

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: <CAC20D2O-fUbrCuvvzEj2Z4b2kV+J6TApYdBeMcWvPEADN-nL7w@mail.gmail.com>
References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl>
 <CAEoi9W4Np=Z80NdO60x4rEPY6qKaRKYq81aCZxLXX2LAD-9iCA@mail.gmail.com>
 <CAC20D2O-fUbrCuvvzEj2Z4b2kV+J6TApYdBeMcWvPEADN-nL7w@mail.gmail.com>
Message-ID: <FF27CE2D-3499-4B06-A249-EF9FC9721BA7@planet.nl>


> On 31 Dec 2022, at 20:08, Clem Cole <clemc at ccc.com> 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: <CAC20D2O-fUbrCuvvzEj2Z4b2kV+J6TApYdBeMcWvPEADN-nL7w@mail.gmail.com>
References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl>
 <CAEoi9W4Np=Z80NdO60x4rEPY6qKaRKYq81aCZxLXX2LAD-9iCA@mail.gmail.com>
 <CAC20D2O-fUbrCuvvzEj2Z4b2kV+J6TApYdBeMcWvPEADN-nL7w@mail.gmail.com>
Message-ID: <CAEoi9W4_ZwOst9yo2GiM4qO4EwapEFia9X7kDZjwQUuhxaEVVw@mail.gmail.com>

On Sat, Dec 31, 2022 at 2:08 PM Clem Cole <clemc at ccc.com> wrote:
> On Sat, Dec 31, 2022 at 10:02 AM Dan Cross <crossd at gmail.com> 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: <CAEoi9W4_ZwOst9yo2GiM4qO4EwapEFia9X7kDZjwQUuhxaEVVw@mail.gmail.com>
References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl>
 <CAEoi9W4Np=Z80NdO60x4rEPY6qKaRKYq81aCZxLXX2LAD-9iCA@mail.gmail.com>
 <CAC20D2O-fUbrCuvvzEj2Z4b2kV+J6TApYdBeMcWvPEADN-nL7w@mail.gmail.com>
 <CAEoi9W4_ZwOst9yo2GiM4qO4EwapEFia9X7kDZjwQUuhxaEVVw@mail.gmail.com>
Message-ID: <CAC20D2NpQdY+oRj-qK45=LR6GuLR3w7ZVmu9SWBd4s6v_Mvepw@mail.gmail.com>

On Sat, Dec 31, 2022 at 4:11 PM Dan Cross <crossd at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221231/47271878/attachment.htm>

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>
 <CAEoi9W4Np=Z80NdO60x4rEPY6qKaRKYq81aCZxLXX2LAD-9iCA@mail.gmail.com>
 <45C94BFE-693D-4D86-8E4A-8DCC8C88774C@planet.nl>
Message-ID: <CAEoi9W46HyCU8RZD9Vf_jggojMD-65=5bOMkcdgHedGNoUbSzQ@mail.gmail.com>

On Sat, Dec 31, 2022 at 3:02 PM Paul Ruizendaal <pnr at planet.nl> wrote:
> > On 31 Dec 2022, at 15:59, Dan Cross <crossd at gmail.com> 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: <CAC20D2NpQdY+oRj-qK45=LR6GuLR3w7ZVmu9SWBd4s6v_Mvepw@mail.gmail.com>
References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl>
 <CAEoi9W4Np=Z80NdO60x4rEPY6qKaRKYq81aCZxLXX2LAD-9iCA@mail.gmail.com>
 <CAC20D2O-fUbrCuvvzEj2Z4b2kV+J6TApYdBeMcWvPEADN-nL7w@mail.gmail.com>
 <CAEoi9W4_ZwOst9yo2GiM4qO4EwapEFia9X7kDZjwQUuhxaEVVw@mail.gmail.com>
 <CAC20D2NpQdY+oRj-qK45=LR6GuLR3w7ZVmu9SWBd4s6v_Mvepw@mail.gmail.com>
Message-ID: <CAEoi9W7=RmJPexkKrUZO6+oVMON+kAoJ3OX0SaC+Cgw+BV_rOQ@mail.gmail.com>

On Sat, Dec 31, 2022 at 4:39 PM Clem Cole <clemc at ccc.com> wrote:
> On Sat, Dec 31, 2022 at 4:11 PM Dan Cross <crossd at gmail.com> 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: <CAKH6PiXHNLH_ys7nV64=a6AgQSKZcJ58K9+fxeyWZsn6zUvT0w@mail.gmail.com>
References: <CAKH6PiXHNLH_ys7nV64=a6AgQSKZcJ58K9+fxeyWZsn6zUvT0w@mail.gmail.com>
Message-ID: <CAKzdPgz08+3RPJZE=zDnkj33+vFhqT4GUF3mBRf44XT5Y4ghMw@mail.gmail.com>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230101/b2c49337/attachment.htm>

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: <CAEoi9W4_ZwOst9yo2GiM4qO4EwapEFia9X7kDZjwQUuhxaEVVw@mail.gmail.com>
References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl>
 <CAEoi9W4Np=Z80NdO60x4rEPY6qKaRKYq81aCZxLXX2LAD-9iCA@mail.gmail.com>
 <CAC20D2O-fUbrCuvvzEj2Z4b2kV+J6TApYdBeMcWvPEADN-nL7w@mail.gmail.com>
 <CAEoi9W4_ZwOst9yo2GiM4qO4EwapEFia9X7kDZjwQUuhxaEVVw@mail.gmail.com>
Message-ID: <Y7C50dGWZ6yFDX74@mit.edu>

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: <Y7C50dGWZ6yFDX74@mit.edu>
References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl>
 <CAEoi9W4Np=Z80NdO60x4rEPY6qKaRKYq81aCZxLXX2LAD-9iCA@mail.gmail.com>
 <CAC20D2O-fUbrCuvvzEj2Z4b2kV+J6TApYdBeMcWvPEADN-nL7w@mail.gmail.com>
 <CAEoi9W4_ZwOst9yo2GiM4qO4EwapEFia9X7kDZjwQUuhxaEVVw@mail.gmail.com>
 <Y7C50dGWZ6yFDX74@mit.edu>
Message-ID: <CALQ0xCBb8Jp4K8YDYhYysrgtqH_w_iCrLz_snox_2DUbZ9XbMQ@mail.gmail.com>

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 <https://www.mindthegapdialogs.com/home>


On Sat, Dec 31, 2022 at 5:38 PM Theodore Ts'o <tytso at mit.edu> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221231/954c606a/attachment.htm>

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: <CAC20D2NpQdY+oRj-qK45=LR6GuLR3w7ZVmu9SWBd4s6v_Mvepw@mail.gmail.com>
References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl>
 <CAEoi9W4Np=Z80NdO60x4rEPY6qKaRKYq81aCZxLXX2LAD-9iCA@mail.gmail.com>
 <CAC20D2O-fUbrCuvvzEj2Z4b2kV+J6TApYdBeMcWvPEADN-nL7w@mail.gmail.com>
 <CAEoi9W4_ZwOst9yo2GiM4qO4EwapEFia9X7kDZjwQUuhxaEVVw@mail.gmail.com>
 <CAC20D2NpQdY+oRj-qK45=LR6GuLR3w7ZVmu9SWBd4s6v_Mvepw@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.2301011017150.95173@aneurin.horsfall.org>

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: <alpine.BSF.2.21.9999.2301011017150.95173@aneurin.horsfall.org>
References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl>
 <CAEoi9W4Np=Z80NdO60x4rEPY6qKaRKYq81aCZxLXX2LAD-9iCA@mail.gmail.com>
 <CAC20D2O-fUbrCuvvzEj2Z4b2kV+J6TApYdBeMcWvPEADN-nL7w@mail.gmail.com>
 <CAEoi9W4_ZwOst9yo2GiM4qO4EwapEFia9X7kDZjwQUuhxaEVVw@mail.gmail.com>
 <CAC20D2NpQdY+oRj-qK45=LR6GuLR3w7ZVmu9SWBd4s6v_Mvepw@mail.gmail.com>
 <alpine.BSF.2.21.9999.2301011017150.95173@aneurin.horsfall.org>
Message-ID: <CAKzdPgzcPVdm_x+WxG7VpssNY7fbr-c2S1ax4S9UOgPPDapOrQ@mail.gmail.com>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230101/e8ca1bfc/attachment.htm>

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: <CAKzdPgzcPVdm_x+WxG7VpssNY7fbr-c2S1ax4S9UOgPPDapOrQ@mail.gmail.com>
References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl>
 <CAEoi9W4Np=Z80NdO60x4rEPY6qKaRKYq81aCZxLXX2LAD-9iCA@mail.gmail.com>
 <CAC20D2O-fUbrCuvvzEj2Z4b2kV+J6TApYdBeMcWvPEADN-nL7w@mail.gmail.com>
 <CAEoi9W4_ZwOst9yo2GiM4qO4EwapEFia9X7kDZjwQUuhxaEVVw@mail.gmail.com>
 <CAC20D2NpQdY+oRj-qK45=LR6GuLR3w7ZVmu9SWBd4s6v_Mvepw@mail.gmail.com>
 <alpine.BSF.2.21.9999.2301011017150.95173@aneurin.horsfall.org>
 <CAKzdPgzcPVdm_x+WxG7VpssNY7fbr-c2S1ax4S9UOgPPDapOrQ@mail.gmail.com>
Message-ID: <CAKr6gn1b=JoNm-9a3iPrHr4QeOzLGFD=Zy6E47YXi6fX4ZGoaA@mail.gmail.com>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230101/cfade51b/attachment.htm>

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: <CAKzdPgzcPVdm_x+WxG7VpssNY7fbr-c2S1ax4S9UOgPPDapOrQ@mail.gmail.com>
References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl>
 <CAEoi9W4Np=Z80NdO60x4rEPY6qKaRKYq81aCZxLXX2LAD-9iCA@mail.gmail.com>
 <CAC20D2O-fUbrCuvvzEj2Z4b2kV+J6TApYdBeMcWvPEADN-nL7w@mail.gmail.com>
 <CAEoi9W4_ZwOst9yo2GiM4qO4EwapEFia9X7kDZjwQUuhxaEVVw@mail.gmail.com>
 <CAC20D2NpQdY+oRj-qK45=LR6GuLR3w7ZVmu9SWBd4s6v_Mvepw@mail.gmail.com>
 <alpine.BSF.2.21.9999.2301011017150.95173@aneurin.horsfall.org>
 <CAKzdPgzcPVdm_x+WxG7VpssNY7fbr-c2S1ax4S9UOgPPDapOrQ@mail.gmail.com>
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: <CAKr6gn1b=JoNm-9a3iPrHr4QeOzLGFD=Zy6E47YXi6fX4ZGoaA@mail.gmail.com>
References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl>
 <CAEoi9W4Np=Z80NdO60x4rEPY6qKaRKYq81aCZxLXX2LAD-9iCA@mail.gmail.com>
 <CAC20D2O-fUbrCuvvzEj2Z4b2kV+J6TApYdBeMcWvPEADN-nL7w@mail.gmail.com>
 <CAEoi9W4_ZwOst9yo2GiM4qO4EwapEFia9X7kDZjwQUuhxaEVVw@mail.gmail.com>
 <CAC20D2NpQdY+oRj-qK45=LR6GuLR3w7ZVmu9SWBd4s6v_Mvepw@mail.gmail.com>
 <alpine.BSF.2.21.9999.2301011017150.95173@aneurin.horsfall.org>
 <CAKzdPgzcPVdm_x+WxG7VpssNY7fbr-c2S1ax4S9UOgPPDapOrQ@mail.gmail.com>
 <CAKr6gn1b=JoNm-9a3iPrHr4QeOzLGFD=Zy6E47YXi6fX4ZGoaA@mail.gmail.com>
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: <emc568d7da-5557-45f1-a086-cf4f6a0b066e@9a0c19f5.com>

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" <jon at fourwinds.com>
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>
 <CAEoi9W4Np=Z80NdO60x4rEPY6qKaRKYq81aCZxLXX2LAD-9iCA@mail.gmail.com>
 <CAC20D2O-fUbrCuvvzEj2Z4b2kV+J6TApYdBeMcWvPEADN-nL7w@mail.gmail.com>
 <CAEoi9W4_ZwOst9yo2GiM4qO4EwapEFia9X7kDZjwQUuhxaEVVw@mail.gmail.com>
 <CAC20D2NpQdY+oRj-qK45=LR6GuLR3w7ZVmu9SWBd4s6v_Mvepw@mail.gmail.com>
 <alpine.BSF.2.21.9999.2301011017150.95173@aneurin.horsfall.org>
 <CAKzdPgzcPVdm_x+WxG7VpssNY7fbr-c2S1ax4S9UOgPPDapOrQ@mail.gmail.com>
 <CAKr6gn1b=JoNm-9a3iPrHr4QeOzLGFD=Zy6E47YXi6fX4ZGoaA@mail.gmail.com>
 <20230101014054.GD5825@mcvoy.com>
Message-ID: <CANCZdfpEZeMszU3FjEQqPDYyE-ev0jkVh7dscMfUJHKgDSyzyg@mail.gmail.com>

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 <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221231/7b096f84/attachment.htm>

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>
 <CqDJahHNUWy9Cx835tZrgXaqZZKafcJSGlRk9Fb43IP_NzYgSiP1t1HCnS_34h11oiwj6FRl4TesmhPeFvYDBCkiK0__bXPENOwVC04qSQc=@protonmail.com>
 <18521483-A73C-4B5F-A76A-6098BD93E9BC@planet.nl>
Message-ID: <CANCZdfpixgN1ZRwph2Cg3nAAsUZSY-O5zXUSe7_mzK1HMm2Rew@mail.gmail.com>

On Sat, Dec 31, 2022 at 5:55 AM Paul Ruizendaal <pnr at planet.nl> 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 <segaloco at protonmail.com> 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:
> >>
> >> <quote from "mode.h">
> >>
> >> /* 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))
> >> <endquote>
> >>
> >>
> >> 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:
> >>
> >> <quote from “io.c”>
> >>
> >> 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
> >> }
> >> <endquote>
> >>
> >>
> >> 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:
> >>
> >> <quote from “fault.c”>
> >>
> >> VOID fault(sig)
> >> REG INT sig;
> >> {
> >> signal(sig, fault);
> >> IF sig==MEMF
> >> THEN IF setbrk(brkincr) == -1
> >> THEN error(nospace);
> >> FI
> >> ELIF ...
> >> <endquote>
> >>
> >>
> >> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221231/f6183720/attachment.htm>

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>
 <CAEoi9W4Np=Z80NdO60x4rEPY6qKaRKYq81aCZxLXX2LAD-9iCA@mail.gmail.com>
 <45C94BFE-693D-4D86-8E4A-8DCC8C88774C@planet.nl>
Message-ID: <CANCZdfriOT4AJZfaL5YDY+J2tOdttthLTozp5Z-VbPK0tPbAtQ@mail.gmail.com>

On Sat, Dec 31, 2022 at 1:03 PM Paul Ruizendaal <pnr at planet.nl> wrote:

>
>
> > On 31 Dec 2022, at 15:59, Dan Cross <crossd at gmail.com> wrote:
> >
> > On Fri, Dec 30, 2022 at 1:26 PM Paul Ruizendaal <pnr at planet.nl> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221231/4a774017/attachment-0001.htm>

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: <Y7C50dGWZ6yFDX74@mit.edu>
References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl>
 <CAEoi9W4Np=Z80NdO60x4rEPY6qKaRKYq81aCZxLXX2LAD-9iCA@mail.gmail.com>
 <CAC20D2O-fUbrCuvvzEj2Z4b2kV+J6TApYdBeMcWvPEADN-nL7w@mail.gmail.com>
 <CAEoi9W4_ZwOst9yo2GiM4qO4EwapEFia9X7kDZjwQUuhxaEVVw@mail.gmail.com>
 <Y7C50dGWZ6yFDX74@mit.edu>
Message-ID: <CAEoi9W6eji4+BWDkp7JhpBt31uA_s68P4S9hKokbLx+-uSa8yA@mail.gmail.com>

On Sat, Dec 31, 2022 at 5:38 PM Theodore Ts'o <tytso at mit.edu> 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: <CANCZdfpixgN1ZRwph2Cg3nAAsUZSY-O5zXUSe7_mzK1HMm2Rew@mail.gmail.com>
References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl>
 <CqDJahHNUWy9Cx835tZrgXaqZZKafcJSGlRk9Fb43IP_NzYgSiP1t1HCnS_34h11oiwj6FRl4TesmhPeFvYDBCkiK0__bXPENOwVC04qSQc=@protonmail.com>
 <18521483-A73C-4B5F-A76A-6098BD93E9BC@planet.nl>
 <CANCZdfpixgN1ZRwph2Cg3nAAsUZSY-O5zXUSe7_mzK1HMm2Rew@mail.gmail.com>
Message-ID: <Y7EOWnbRLOBecVD9@largo.jsg.id.au>

On Sat, Dec 31, 2022 at 07:55:28PM -0700, Warner Losh wrote:
> On Sat, Dec 31, 2022 at 5:55 AM Paul Ruizendaal <pnr at planet.nl> 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: <CANCZdfriOT4AJZfaL5YDY+J2tOdttthLTozp5Z-VbPK0tPbAtQ@mail.gmail.com>
References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl>
 <CAEoi9W4Np=Z80NdO60x4rEPY6qKaRKYq81aCZxLXX2LAD-9iCA@mail.gmail.com>
 <45C94BFE-693D-4D86-8E4A-8DCC8C88774C@planet.nl>
 <CANCZdfriOT4AJZfaL5YDY+J2tOdttthLTozp5Z-VbPK0tPbAtQ@mail.gmail.com>
Message-ID: <CAEoi9W7cpBN2vHaHUFdenayNduU=Gd2UnWyjkLdmA=brXz=5+w@mail.gmail.com>

On Sat, Dec 31, 2022 at 10:09 PM Warner Losh <imp at bsdimp.com> wrote:
> On Sat, Dec 31, 2022 at 1:03 PM Paul Ruizendaal <pnr at planet.nl> 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: <Y7EOWnbRLOBecVD9@largo.jsg.id.au>
References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl>
 <CqDJahHNUWy9Cx835tZrgXaqZZKafcJSGlRk9Fb43IP_NzYgSiP1t1HCnS_34h11oiwj6FRl4TesmhPeFvYDBCkiK0__bXPENOwVC04qSQc=@protonmail.com>
 <18521483-A73C-4B5F-A76A-6098BD93E9BC@planet.nl>
 <CANCZdfpixgN1ZRwph2Cg3nAAsUZSY-O5zXUSe7_mzK1HMm2Rew@mail.gmail.com>
 <Y7EOWnbRLOBecVD9@largo.jsg.id.au>
Message-ID: <CANCZdfr57kJvxgK7HvgVr2YrOC51SG=qEyqn9nzMtsTKLBA0Yw@mail.gmail.com>

On Sat, Dec 31, 2022, 9:38 PM Jonathan Gray <jsg at jsg.id.au> 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 <pnr at planet.nl> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221231/0ad8380f/attachment.htm>

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: <CANCZdfr57kJvxgK7HvgVr2YrOC51SG=qEyqn9nzMtsTKLBA0Yw@mail.gmail.com>
References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl>
 <CqDJahHNUWy9Cx835tZrgXaqZZKafcJSGlRk9Fb43IP_NzYgSiP1t1HCnS_34h11oiwj6FRl4TesmhPeFvYDBCkiK0__bXPENOwVC04qSQc=@protonmail.com>
 <18521483-A73C-4B5F-A76A-6098BD93E9BC@planet.nl>
 <CANCZdfpixgN1ZRwph2Cg3nAAsUZSY-O5zXUSe7_mzK1HMm2Rew@mail.gmail.com>
 <Y7EOWnbRLOBecVD9@largo.jsg.id.au>
 <CANCZdfr57kJvxgK7HvgVr2YrOC51SG=qEyqn9nzMtsTKLBA0Yw@mail.gmail.com>
Message-ID: <CAEoi9W5SZHNvMbiniu4uQmM6n8qGPsQoePQTEQnxAnZRT8ZUXA@mail.gmail.com>

On Sun, Jan 1, 2023 at 12:27 AM Warner Losh <imp at bsdimp.com> wrote:
> On Sat, Dec 31, 2022, 9:38 PM Jonathan Gray <jsg at jsg.id.au> 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: <CAEoi9W5SZHNvMbiniu4uQmM6n8qGPsQoePQTEQnxAnZRT8ZUXA@mail.gmail.com>
References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl>
 <CqDJahHNUWy9Cx835tZrgXaqZZKafcJSGlRk9Fb43IP_NzYgSiP1t1HCnS_34h11oiwj6FRl4TesmhPeFvYDBCkiK0__bXPENOwVC04qSQc=@protonmail.com>
 <18521483-A73C-4B5F-A76A-6098BD93E9BC@planet.nl>
 <CANCZdfpixgN1ZRwph2Cg3nAAsUZSY-O5zXUSe7_mzK1HMm2Rew@mail.gmail.com>
 <Y7EOWnbRLOBecVD9@largo.jsg.id.au>
 <CANCZdfr57kJvxgK7HvgVr2YrOC51SG=qEyqn9nzMtsTKLBA0Yw@mail.gmail.com>
 <CAEoi9W5SZHNvMbiniu4uQmM6n8qGPsQoePQTEQnxAnZRT8ZUXA@mail.gmail.com>
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 <imp at bsdimp.com> wrote:
> > On Sat, Dec 31, 2022, 9:38 PM Jonathan Gray <jsg at jsg.id.au> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221231/6e283af0/attachment.sig>

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: <CAEoi9W5SZHNvMbiniu4uQmM6n8qGPsQoePQTEQnxAnZRT8ZUXA@mail.gmail.com>
References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl>
 <CqDJahHNUWy9Cx835tZrgXaqZZKafcJSGlRk9Fb43IP_NzYgSiP1t1HCnS_34h11oiwj6FRl4TesmhPeFvYDBCkiK0__bXPENOwVC04qSQc=@protonmail.com>
 <18521483-A73C-4B5F-A76A-6098BD93E9BC@planet.nl>
 <CANCZdfpixgN1ZRwph2Cg3nAAsUZSY-O5zXUSe7_mzK1HMm2Rew@mail.gmail.com>
 <Y7EOWnbRLOBecVD9@largo.jsg.id.au>
 <CANCZdfr57kJvxgK7HvgVr2YrOC51SG=qEyqn9nzMtsTKLBA0Yw@mail.gmail.com>
 <CAEoi9W5SZHNvMbiniu4uQmM6n8qGPsQoePQTEQnxAnZRT8ZUXA@mail.gmail.com>
Message-ID: <CANCZdfprR=x5YU7d=uKygnNo2ZTSbHeWT77wvvvQMkC3vzNVVA@mail.gmail.com>

On Sat, Dec 31, 2022, 10:35 PM Dan Cross <crossd at gmail.com> wrote:

> On Sun, Jan 1, 2023 at 12:27 AM Warner Losh <imp at bsdimp.com> wrote:
> > On Sat, Dec 31, 2022, 9:38 PM Jonathan Gray <jsg at jsg.id.au> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221231/45aaa160/attachment.htm>

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>
 <CqDJahHNUWy9Cx835tZrgXaqZZKafcJSGlRk9Fb43IP_NzYgSiP1t1HCnS_34h11oiwj6FRl4TesmhPeFvYDBCkiK0__bXPENOwVC04qSQc=@protonmail.com>
 <18521483-A73C-4B5F-A76A-6098BD93E9BC@planet.nl>
 <CANCZdfpixgN1ZRwph2Cg3nAAsUZSY-O5zXUSe7_mzK1HMm2Rew@mail.gmail.com>
 <Y7EOWnbRLOBecVD9@largo.jsg.id.au>
 <CANCZdfr57kJvxgK7HvgVr2YrOC51SG=qEyqn9nzMtsTKLBA0Yw@mail.gmail.com>
 <CAEoi9W5SZHNvMbiniu4uQmM6n8qGPsQoePQTEQnxAnZRT8ZUXA@mail.gmail.com>
 <20230101055213.va3hnzsxzeeot5an@illithid>
Message-ID: <CANCZdfquCj3yXQLfCA+FQSdPaONOj+gOZcAjPBpsNkXZUZ931Q@mail.gmail.com>

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 <imp at bsdimp.com> wrote:
> > > On Sat, Dec 31, 2022, 9:38 PM Jonathan Gray <jsg at jsg.id.au> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221231/b01788b1/attachment.htm>

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>
 <CqDJahHNUWy9Cx835tZrgXaqZZKafcJSGlRk9Fb43IP_NzYgSiP1t1HCnS_34h11oiwj6FRl4TesmhPeFvYDBCkiK0__bXPENOwVC04qSQc=@protonmail.com>
 <18521483-A73C-4B5F-A76A-6098BD93E9BC@planet.nl>
 <CANCZdfpixgN1ZRwph2Cg3nAAsUZSY-O5zXUSe7_mzK1HMm2Rew@mail.gmail.com>
 <Y7EOWnbRLOBecVD9@largo.jsg.id.au>
 <CANCZdfr57kJvxgK7HvgVr2YrOC51SG=qEyqn9nzMtsTKLBA0Yw@mail.gmail.com>
 <CAEoi9W5SZHNvMbiniu4uQmM6n8qGPsQoePQTEQnxAnZRT8ZUXA@mail.gmail.com>
 <20230101055213.va3hnzsxzeeot5an@illithid>
Message-ID: <CAKzdPgyd8zn=be4EmpR3wPYpZmqr5NZbzLj57WNZ9MQtxA9FXA@mail.gmail.com>

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 <imp at bsdimp.com> wrote:
> > > On Sat, Dec 31, 2022, 9:38 PM Jonathan Gray <jsg at jsg.id.au> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230101/da2f50c7/attachment.htm>

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: <CANCZdfr57kJvxgK7HvgVr2YrOC51SG=qEyqn9nzMtsTKLBA0Yw@mail.gmail.com>
References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl>
 <CqDJahHNUWy9Cx835tZrgXaqZZKafcJSGlRk9Fb43IP_NzYgSiP1t1HCnS_34h11oiwj6FRl4TesmhPeFvYDBCkiK0__bXPENOwVC04qSQc=@protonmail.com>
 <18521483-A73C-4B5F-A76A-6098BD93E9BC@planet.nl>
 <CANCZdfpixgN1ZRwph2Cg3nAAsUZSY-O5zXUSe7_mzK1HMm2Rew@mail.gmail.com>
 <Y7EOWnbRLOBecVD9@largo.jsg.id.au>
 <CANCZdfr57kJvxgK7HvgVr2YrOC51SG=qEyqn9nzMtsTKLBA0Yw@mail.gmail.com>
Message-ID: <Y7EyKSHraDAIQDHD@largo.jsg.id.au>

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: <Y7EyKSHraDAIQDHD@largo.jsg.id.au>
References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl>
 <CqDJahHNUWy9Cx835tZrgXaqZZKafcJSGlRk9Fb43IP_NzYgSiP1t1HCnS_34h11oiwj6FRl4TesmhPeFvYDBCkiK0__bXPENOwVC04qSQc=@protonmail.com>
 <18521483-A73C-4B5F-A76A-6098BD93E9BC@planet.nl>
 <CANCZdfpixgN1ZRwph2Cg3nAAsUZSY-O5zXUSe7_mzK1HMm2Rew@mail.gmail.com>
 <Y7EOWnbRLOBecVD9@largo.jsg.id.au>
 <CANCZdfr57kJvxgK7HvgVr2YrOC51SG=qEyqn9nzMtsTKLBA0Yw@mail.gmail.com>
 <Y7EyKSHraDAIQDHD@largo.jsg.id.au>
Message-ID: <CANCZdfoCLrQJ8WsVT6NvZZhRwMc50FcHPruX+d0Lx3UAUd3U8g@mail.gmail.com>

On Sun, Jan 1, 2023, 12:11 AM Jonathan Gray <jsg at jsg.id.au> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230101/8a0dfaa1/attachment.htm>

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>
 <CAEoi9W4Np=Z80NdO60x4rEPY6qKaRKYq81aCZxLXX2LAD-9iCA@mail.gmail.com>
 <45C94BFE-693D-4D86-8E4A-8DCC8C88774C@planet.nl>
Message-ID: <Y7E+zBDzD/YIt2So@largo.jsg.id.au>

On Sat, Dec 31, 2022 at 09:02:38PM +0100, Paul Ruizendaal wrote:
> 
> 
> > On 31 Dec 2022, at 15:59, Dan Cross <crossd at gmail.com> wrote:
> > 
> > On Fri, Dec 30, 2022 at 1:26 PM Paul Ruizendaal <pnr at planet.nl> 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: <CANCZdfr57kJvxgK7HvgVr2YrOC51SG=qEyqn9nzMtsTKLBA0Yw@mail.gmail.com>
References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl>
 <CqDJahHNUWy9Cx835tZrgXaqZZKafcJSGlRk9Fb43IP_NzYgSiP1t1HCnS_34h11oiwj6FRl4TesmhPeFvYDBCkiK0__bXPENOwVC04qSQc=@protonmail.com>
 <18521483-A73C-4B5F-A76A-6098BD93E9BC@planet.nl>
 <CANCZdfpixgN1ZRwph2Cg3nAAsUZSY-O5zXUSe7_mzK1HMm2Rew@mail.gmail.com>
 <Y7EOWnbRLOBecVD9@largo.jsg.id.au>
 <CANCZdfr57kJvxgK7HvgVr2YrOC51SG=qEyqn9nzMtsTKLBA0Yw@mail.gmail.com>
Message-ID: <67F165EB-17E6-4317-AF8D-E6F20B7F3DE6@planet.nl>


> On 1 Jan 2023, at 06:25, Warner Losh <imp at bsdimp.com> 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 <chet.ramey at case.edu> 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: <CAEoi9W5SZHNvMbiniu4uQmM6n8qGPsQoePQTEQnxAnZRT8ZUXA@mail.gmail.com>
References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl>
 <CqDJahHNUWy9Cx835tZrgXaqZZKafcJSGlRk9Fb43IP_NzYgSiP1t1HCnS_34h11oiwj6FRl4TesmhPeFvYDBCkiK0__bXPENOwVC04qSQc=@protonmail.com>
 <18521483-A73C-4B5F-A76A-6098BD93E9BC@planet.nl>
 <CANCZdfpixgN1ZRwph2Cg3nAAsUZSY-O5zXUSe7_mzK1HMm2Rew@mail.gmail.com>
 <Y7EOWnbRLOBecVD9@largo.jsg.id.au>
 <CANCZdfr57kJvxgK7HvgVr2YrOC51SG=qEyqn9nzMtsTKLBA0Yw@mail.gmail.com>
 <CAEoi9W5SZHNvMbiniu4uQmM6n8qGPsQoePQTEQnxAnZRT8ZUXA@mail.gmail.com>
Message-ID: <embd8f6950-14c1-4149-9780-e691e49c4222@9a0c19f5.com>

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" <crossd at gmail.com>
To "Warner Losh" <imp at bsdimp.com>
Cc "Jonathan Gray" <jsg at jsg.id.au>; "Paul Ruizendaal" <pnr at planet.nl>; 
"The Eunuchs Hysterical Society" <tuhs at tuhs.org>; "segaloco" 
<segaloco at protonmail.com>
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 <imp at bsdimp.com> wrote:
>>  On Sat, Dec 31, 2022, 9:38 PM Jonathan Gray <jsg at jsg.id.au> 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: <Y7C50dGWZ6yFDX74@mit.edu>
References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl>
 <CAEoi9W4Np=Z80NdO60x4rEPY6qKaRKYq81aCZxLXX2LAD-9iCA@mail.gmail.com>
 <CAC20D2O-fUbrCuvvzEj2Z4b2kV+J6TApYdBeMcWvPEADN-nL7w@mail.gmail.com>
 <CAEoi9W4_ZwOst9yo2GiM4qO4EwapEFia9X7kDZjwQUuhxaEVVw@mail.gmail.com>
 <Y7C50dGWZ6yFDX74@mit.edu>
Message-ID: <DBC89F53-9A0A-4B34-A627-A9CFF5013EC3@planet.nl>


> On 31 Dec 2022, at 23:38, Theodore Ts'o <tytso at mit.edu> 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 <crossd at gmail.com> 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: <DBC89F53-9A0A-4B34-A627-A9CFF5013EC3@planet.nl>
References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl>
 <CAEoi9W4Np=Z80NdO60x4rEPY6qKaRKYq81aCZxLXX2LAD-9iCA@mail.gmail.com>
 <CAC20D2O-fUbrCuvvzEj2Z4b2kV+J6TApYdBeMcWvPEADN-nL7w@mail.gmail.com>
 <CAEoi9W4_ZwOst9yo2GiM4qO4EwapEFia9X7kDZjwQUuhxaEVVw@mail.gmail.com>
 <Y7C50dGWZ6yFDX74@mit.edu>
 <DBC89F53-9A0A-4B34-A627-A9CFF5013EC3@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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230101/99d8b91b/attachment.sig>

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>
 <CAEoi9W4Np=Z80NdO60x4rEPY6qKaRKYq81aCZxLXX2LAD-9iCA@mail.gmail.com>
 <CAC20D2O-fUbrCuvvzEj2Z4b2kV+J6TApYdBeMcWvPEADN-nL7w@mail.gmail.com>
 <CAEoi9W4_ZwOst9yo2GiM4qO4EwapEFia9X7kDZjwQUuhxaEVVw@mail.gmail.com>
 <Y7C50dGWZ6yFDX74@mit.edu> <DBC89F53-9A0A-4B34-A627-A9CFF5013EC3@planet.nl>
 <20230101212609.yjg2poiggil7pwat@illithid>
Message-ID: <CAKzdPgx1i7y92K893A19TpWobpoXW+ooq_97qbsY8-R4V+0i4Q@mail.gmail.com>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230102/c47f7363/attachment.htm>

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: <alpine.BSF.2.21.9999.2212311516330.69068@aneurin.horsfall.org>
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>
 <alpine.BSF.2.21.9999.2212311516330.69068@aneurin.horsfall.org>
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 <https://maryannhorton.com>

"This is a great book" - Monica Helms

"Brave and Important" - Laura L. Engel

       Available on Amazon and bn.com!

	<https://www.amazon.com/Trailblazer-Lighting-Transgender-Equality-Corporate-ebook/dp/B0B8F2BR9B>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230101/43f1796d/attachment.htm>

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>
 <alpine.BSF.2.21.9999.2212311516330.69068@aneurin.horsfall.org>
 <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net>
Message-ID: <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>

Be careful in applying modern judgments without remembering
the historical context - below
On Mon, Jan 2, 2023 at 12:12 AM Mary Ann Horton <mah at mhorton.net> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230102/e10a0c65/attachment.htm>

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: <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.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>
 <alpine.BSF.2.21.9999.2212311516330.69068@aneurin.horsfall.org>
 <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net>
 <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
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>
 <alpine.BSF.2.21.9999.2212311516330.69068@aneurin.horsfall.org>
 <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net>
 <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102165120.GK25547@mcvoy.com>
Message-ID: <E977D385-604F-49A9-83FD-8C5270623066@gmail.com>



> On Jan 2, 2023, at 9:51 AM, Larry McVoy <lm at mcvoy.com> 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: <E977D385-604F-49A9-83FD-8C5270623066@gmail.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>
 <alpine.BSF.2.21.9999.2212311516330.69068@aneurin.horsfall.org>
 <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net>
 <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102165120.GK25547@mcvoy.com>
 <E977D385-604F-49A9-83FD-8C5270623066@gmail.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>
 <alpine.BSF.2.21.9999.2212311516330.69068@aneurin.horsfall.org>
 <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net>
 <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102165120.GK25547@mcvoy.com>
 <E977D385-604F-49A9-83FD-8C5270623066@gmail.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>
 <alpine.BSF.2.21.9999.2212311516330.69068@aneurin.horsfall.org>
 <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net>
 <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102165120.GK25547@mcvoy.com>
Message-ID: <CAC20D2OGi-Wq6K15vVXWp36kuB8Bd1NenE_K9jA_SJXYAaA1VA@mail.gmail.com>

On Mon, Jan 2, 2023 at 11:51 AM Larry McVoy <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230102/467feda5/attachment.htm>

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>
 <alpine.BSF.2.21.9999.2212311516330.69068@aneurin.horsfall.org>
 <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net>
 <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102165120.GK25547@mcvoy.com>
 <E977D385-604F-49A9-83FD-8C5270623066@gmail.com>
 <20230102174304.GM25547@mcvoy.com>
Message-ID: <E4339ED1-73F4-4BBB-92EF-B9D5A92C5096@gmail.com>



> On Jan 2, 2023, at 10:43 AM, Larry McVoy <lm at mcvoy.com> 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>
 <alpine.BSF.2.21.9999.2212311516330.69068@aneurin.horsfall.org>
 <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net>
 <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102165120.GK25547@mcvoy.com>
 <E977D385-604F-49A9-83FD-8C5270623066@gmail.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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230102/154c0bac/attachment.sig>

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>
 <alpine.BSF.2.21.9999.2212311516330.69068@aneurin.horsfall.org>
 <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net>
 <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102165120.GK25547@mcvoy.com>
 <E977D385-604F-49A9-83FD-8C5270623066@gmail.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>
 <alpine.BSF.2.21.9999.2212311516330.69068@aneurin.horsfall.org>
 <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net>
 <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102165120.GK25547@mcvoy.com>
 <E977D385-604F-49A9-83FD-8C5270623066@gmail.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: <E4339ED1-73F4-4BBB-92EF-B9D5A92C5096@gmail.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>
 <alpine.BSF.2.21.9999.2212311516330.69068@aneurin.horsfall.org>
 <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net>
 <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102165120.GK25547@mcvoy.com>
 <E977D385-604F-49A9-83FD-8C5270623066@gmail.com>
 <20230102174304.GM25547@mcvoy.com>
 <E4339ED1-73F4-4BBB-92EF-B9D5A92C5096@gmail.com>
Message-ID: <CAC20D2Pf-rLL8NqoJ7RcXHjrq4crQKC=K25218fuM0yd0rQNDA@mail.gmail.com>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230102/39094e07/attachment.htm>

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>
 <alpine.BSF.2.21.9999.2212311516330.69068@aneurin.horsfall.org>
 <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net>
 <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102165120.GK25547@mcvoy.com>
 <E977D385-604F-49A9-83FD-8C5270623066@gmail.com>
 <20230102174304.GM25547@mcvoy.com>
 <59004a29-5119-9dd9-c248-518b8c4e7928@makerlisp.com>
 <20230102180020.p6gmiwhrnidfbfsc@illithid> <20230102181242.GO25547@mcvoy.com>
Message-ID: <CAC20D2NcJAHYdGMBzfCgwCBeTZa=d7TBMWo-ZVN+hLXnh9usaQ@mail.gmail.com>

On Mon, Jan 2, 2023 at 1:13 PM Larry McVoy <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230102/4607d67c/attachment.htm>

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: <E4339ED1-73F4-4BBB-92EF-B9D5A92C5096@gmail.com>
References: <20221230200246.GW5825@mcvoy.com>
 <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com>
 <20221231035931.GG5825@mcvoy.com>
 <alpine.BSF.2.21.9999.2212311516330.69068@aneurin.horsfall.org>
 <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net>
 <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102165120.GK25547@mcvoy.com>
 <E977D385-604F-49A9-83FD-8C5270623066@gmail.com>
 <20230102174304.GM25547@mcvoy.com>
 <E4339ED1-73F4-4BBB-92EF-B9D5A92C5096@gmail.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: <CAC20D2Pf-rLL8NqoJ7RcXHjrq4crQKC=K25218fuM0yd0rQNDA@mail.gmail.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>
 <alpine.BSF.2.21.9999.2212311516330.69068@aneurin.horsfall.org>
 <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net>
 <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102165120.GK25547@mcvoy.com>
 <E977D385-604F-49A9-83FD-8C5270623066@gmail.com>
 <20230102174304.GM25547@mcvoy.com>
 <E4339ED1-73F4-4BBB-92EF-B9D5A92C5096@gmail.com>
 <CAC20D2Pf-rLL8NqoJ7RcXHjrq4crQKC=K25218fuM0yd0rQNDA@mail.gmail.com>
Message-ID: <CAEoi9W7A==NC+W+H+kZbUZ6AK2O-cUjwjUz_Gx_HY_BKfeeBqA@mail.gmail.com>

On Mon, Jan 2, 2023 at 1:13 PM Clem Cole <clemc at ccc.com> 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: <CAEoi9W7A==NC+W+H+kZbUZ6AK2O-cUjwjUz_Gx_HY_BKfeeBqA@mail.gmail.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>
 <alpine.BSF.2.21.9999.2212311516330.69068@aneurin.horsfall.org>
 <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net>
 <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102165120.GK25547@mcvoy.com>
 <E977D385-604F-49A9-83FD-8C5270623066@gmail.com>
 <20230102174304.GM25547@mcvoy.com>
 <E4339ED1-73F4-4BBB-92EF-B9D5A92C5096@gmail.com>
 <CAC20D2Pf-rLL8NqoJ7RcXHjrq4crQKC=K25218fuM0yd0rQNDA@mail.gmail.com>
 <CAEoi9W7A==NC+W+H+kZbUZ6AK2O-cUjwjUz_Gx_HY_BKfeeBqA@mail.gmail.com>
Message-ID: <CAEoi9W7a-qWv5=9zA6bTx+54R95LoaBV-LEDjrh0XgzeYif-xw@mail.gmail.com>

[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 <crossd at gmail.com> wrote:
>
> On Mon, Jan 2, 2023 at 1:13 PM Clem Cole <clemc at ccc.com> 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>
 <alpine.BSF.2.21.9999.2212311516330.69068@aneurin.horsfall.org>
 <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net>
 <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102165120.GK25547@mcvoy.com>
 <E977D385-604F-49A9-83FD-8C5270623066@gmail.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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230102/1cda79f6/attachment.sig>

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>
 <alpine.BSF.2.21.9999.2212311516330.69068@aneurin.horsfall.org>
 <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net>
 <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102165120.GK25547@mcvoy.com>
 <E977D385-604F-49A9-83FD-8C5270623066@gmail.com>
 <20230102174304.GM25547@mcvoy.com>
 <59004a29-5119-9dd9-c248-518b8c4e7928@makerlisp.com>
 <20230102180020.p6gmiwhrnidfbfsc@illithid> <20230102181242.GO25547@mcvoy.com>
 <20230102192114.2uu7f4ap55e6xtby@illithid>
Message-ID: <CAFH29tod5VUsP-cFhsEPaFmXAD7AUQQoY6D6w-DSekSGVZebXw@mail.gmail.com>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230102/55fa8ac4/attachment.htm>

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: <CAC20D2NcJAHYdGMBzfCgwCBeTZa=d7TBMWo-ZVN+hLXnh9usaQ@mail.gmail.com>
References: <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com>
 <20221231035931.GG5825@mcvoy.com>
 <alpine.BSF.2.21.9999.2212311516330.69068@aneurin.horsfall.org>
 <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net>
 <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102165120.GK25547@mcvoy.com>
 <E977D385-604F-49A9-83FD-8C5270623066@gmail.com>
 <20230102174304.GM25547@mcvoy.com>
 <59004a29-5119-9dd9-c248-518b8c4e7928@makerlisp.com>
 <20230102180020.p6gmiwhrnidfbfsc@illithid> <20230102181242.GO25547@mcvoy.com>
 <CAC20D2NcJAHYdGMBzfCgwCBeTZa=d7TBMWo-ZVN+hLXnh9usaQ@mail.gmail.com>
Message-ID: <CANCZdfocywPU4NDGr1YwXG_zbHGvYZwa4AaExXovCccAaEKzsA@mail.gmail.com>

On Mon, Jan 2, 2023, 11:18 AM Clem Cole <clemc at ccc.com> wrote:

>
>
> On Mon, Jan 2, 2023 at 1:13 PM Larry McVoy <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230102/b1e19324/attachment.htm>

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: <b689c244-3ea9-4fd6-bb45-a59d131071d6@app.fastmail.com>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230102/02eaff68/attachment-0001.htm>

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: <CANCZdfocywPU4NDGr1YwXG_zbHGvYZwa4AaExXovCccAaEKzsA@mail.gmail.com>
References: <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com>
 <20221231035931.GG5825@mcvoy.com>
 <alpine.BSF.2.21.9999.2212311516330.69068@aneurin.horsfall.org>
 <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net>
 <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102165120.GK25547@mcvoy.com>
 <E977D385-604F-49A9-83FD-8C5270623066@gmail.com>
 <20230102174304.GM25547@mcvoy.com>
 <59004a29-5119-9dd9-c248-518b8c4e7928@makerlisp.com>
 <20230102180020.p6gmiwhrnidfbfsc@illithid> <20230102181242.GO25547@mcvoy.com>
 <CAC20D2NcJAHYdGMBzfCgwCBeTZa=d7TBMWo-ZVN+hLXnh9usaQ@mail.gmail.com>
 <CANCZdfocywPU4NDGr1YwXG_zbHGvYZwa4AaExXovCccAaEKzsA@mail.gmail.com>
Message-ID: <E3F59DFF-406E-44F4-9747-722BA88EA3E8@gmail.com>



> On Jan 2, 2023, at 12:50 PM, Warner Losh <imp at bsdimp.com> 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: <CAFH29tod5VUsP-cFhsEPaFmXAD7AUQQoY6D6w-DSekSGVZebXw@mail.gmail.com>
References: <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net>
 <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102165120.GK25547@mcvoy.com>
 <E977D385-604F-49A9-83FD-8C5270623066@gmail.com>
 <20230102174304.GM25547@mcvoy.com>
 <59004a29-5119-9dd9-c248-518b8c4e7928@makerlisp.com>
 <20230102180020.p6gmiwhrnidfbfsc@illithid>
 <20230102181242.GO25547@mcvoy.com>
 <20230102192114.2uu7f4ap55e6xtby@illithid>
 <CAFH29tod5VUsP-cFhsEPaFmXAD7AUQQoY6D6w-DSekSGVZebXw@mail.gmail.com>
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: <CAFH29tod5VUsP-cFhsEPaFmXAD7AUQQoY6D6w-DSekSGVZebXw@mail.gmail.com>
References: <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net>
 <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102165120.GK25547@mcvoy.com>
 <E977D385-604F-49A9-83FD-8C5270623066@gmail.com>
 <20230102174304.GM25547@mcvoy.com>
 <59004a29-5119-9dd9-c248-518b8c4e7928@makerlisp.com>
 <20230102180020.p6gmiwhrnidfbfsc@illithid>
 <20230102181242.GO25547@mcvoy.com>
 <20230102192114.2uu7f4ap55e6xtby@illithid>
 <CAFH29tod5VUsP-cFhsEPaFmXAD7AUQQoY6D6w-DSekSGVZebXw@mail.gmail.com>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230102/11cc9af4/attachment.sig>

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: <b689c244-3ea9-4fd6-bb45-a59d131071d6@app.fastmail.com> (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>
 <b689c244-3ea9-4fd6-bb45-a59d131071d6@app.fastmail.com>
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 <lm at mcvoy.com> 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: <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102165120.GK25547@mcvoy.com>
 <E977D385-604F-49A9-83FD-8C5270623066@gmail.com>
 <20230102174304.GM25547@mcvoy.com>
 <59004a29-5119-9dd9-c248-518b8c4e7928@makerlisp.com>
 <20230102180020.p6gmiwhrnidfbfsc@illithid>
 <20230102181242.GO25547@mcvoy.com>
 <20230102192114.2uu7f4ap55e6xtby@illithid>
 <CAFH29tod5VUsP-cFhsEPaFmXAD7AUQQoY6D6w-DSekSGVZebXw@mail.gmail.com>
 <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 <lm at mcvoy.com> 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: <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102165120.GK25547@mcvoy.com>
 <E977D385-604F-49A9-83FD-8C5270623066@gmail.com>
 <20230102174304.GM25547@mcvoy.com>
 <59004a29-5119-9dd9-c248-518b8c4e7928@makerlisp.com>
 <20230102180020.p6gmiwhrnidfbfsc@illithid> <20230102181242.GO25547@mcvoy.com>
 <20230102192114.2uu7f4ap55e6xtby@illithid>
 <CAFH29tod5VUsP-cFhsEPaFmXAD7AUQQoY6D6w-DSekSGVZebXw@mail.gmail.com>
 <20230102202422.qychfa24tnjuok4p@illithid> <20230102204103.GU25547@mcvoy.com>
Message-ID: <CAEoi9W4svE13AyRnD8v=Be_JppNtMH+OQOipGXzvxSZDuxRzpw@mail.gmail.com>

On Mon, Jan 2, 2023 at 3:41 PM Larry McVoy <lm at mcvoy.com> 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: <CAEoi9W4svE13AyRnD8v=Be_JppNtMH+OQOipGXzvxSZDuxRzpw@mail.gmail.com>
References: <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102165120.GK25547@mcvoy.com>
 <E977D385-604F-49A9-83FD-8C5270623066@gmail.com>
 <20230102174304.GM25547@mcvoy.com>
 <59004a29-5119-9dd9-c248-518b8c4e7928@makerlisp.com>
 <20230102180020.p6gmiwhrnidfbfsc@illithid> <20230102181242.GO25547@mcvoy.com>
 <20230102192114.2uu7f4ap55e6xtby@illithid>
 <CAFH29tod5VUsP-cFhsEPaFmXAD7AUQQoY6D6w-DSekSGVZebXw@mail.gmail.com>
 <20230102202422.qychfa24tnjuok4p@illithid> <20230102204103.GU25547@mcvoy.com>
 <CAEoi9W4svE13AyRnD8v=Be_JppNtMH+OQOipGXzvxSZDuxRzpw@mail.gmail.com>
Message-ID: <CAC20D2PJGk_9VVNtbAwMX7obyzkQ4QyUkAFsm2HpLk0TtRTRow@mail.gmail.com>

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?

The result is the fork/mess called Gnu.
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230102/040e6ba7/attachment.htm>

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: <CAEoi9W4svE13AyRnD8v=Be_JppNtMH+OQOipGXzvxSZDuxRzpw@mail.gmail.com>
References: <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102165120.GK25547@mcvoy.com>
 <E977D385-604F-49A9-83FD-8C5270623066@gmail.com>
 <20230102174304.GM25547@mcvoy.com>
 <59004a29-5119-9dd9-c248-518b8c4e7928@makerlisp.com>
 <20230102180020.p6gmiwhrnidfbfsc@illithid> <20230102181242.GO25547@mcvoy.com>
 <20230102192114.2uu7f4ap55e6xtby@illithid>
 <CAFH29tod5VUsP-cFhsEPaFmXAD7AUQQoY6D6w-DSekSGVZebXw@mail.gmail.com>
 <20230102202422.qychfa24tnjuok4p@illithid> <20230102204103.GU25547@mcvoy.com>
 <CAEoi9W4svE13AyRnD8v=Be_JppNtMH+OQOipGXzvxSZDuxRzpw@mail.gmail.com>
Message-ID: <cbdf76dc-c250-4e8d-af58-f17d7041b65f@app.fastmail.com>

On Mon, Jan 2, 2023, at 13:00, Dan Cross wrote:
> On Mon, Jan 2, 2023 at 3:41 PM Larry McVoy <lm at mcvoy.com> 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: <b689c244-3ea9-4fd6-bb45-a59d131071d6@app.fastmail.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>
 <b689c244-3ea9-4fd6-bb45-a59d131071d6@app.fastmail.com>
Message-ID: <CAKzdPgwnsdqp68wAk2DtuHg1vNYxT5FNN6GQnooX9C8phPcPiw@mail.gmail.com>

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 <joseph at josephholsten.com>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230103/97214477/attachment.htm>

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: <cbdf76dc-c250-4e8d-af58-f17d7041b65f@app.fastmail.com>
References: <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102165120.GK25547@mcvoy.com>
 <E977D385-604F-49A9-83FD-8C5270623066@gmail.com>
 <20230102174304.GM25547@mcvoy.com>
 <59004a29-5119-9dd9-c248-518b8c4e7928@makerlisp.com>
 <20230102180020.p6gmiwhrnidfbfsc@illithid> <20230102181242.GO25547@mcvoy.com>
 <20230102192114.2uu7f4ap55e6xtby@illithid>
 <CAFH29tod5VUsP-cFhsEPaFmXAD7AUQQoY6D6w-DSekSGVZebXw@mail.gmail.com>
 <20230102202422.qychfa24tnjuok4p@illithid> <20230102204103.GU25547@mcvoy.com>
 <CAEoi9W4svE13AyRnD8v=Be_JppNtMH+OQOipGXzvxSZDuxRzpw@mail.gmail.com>
 <cbdf76dc-c250-4e8d-af58-f17d7041b65f@app.fastmail.com>
Message-ID: <67D8CB20-4D19-43D0-BDA5-6B2476A706AF@gmail.com>



> On Jan 2, 2023, at 2:08 PM, Joseph Holsten <joseph at josephholsten.com> wrote:
> 
> On Mon, Jan 2, 2023, at 13:00, Dan Cross wrote:
>> On Mon, Jan 2, 2023 at 3:41 PM Larry McVoy <lm at mcvoy.com> 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: <CAC20D2PJGk_9VVNtbAwMX7obyzkQ4QyUkAFsm2HpLk0TtRTRow@mail.gmail.com>
References: <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102165120.GK25547@mcvoy.com>
 <E977D385-604F-49A9-83FD-8C5270623066@gmail.com>
 <20230102174304.GM25547@mcvoy.com>
 <59004a29-5119-9dd9-c248-518b8c4e7928@makerlisp.com>
 <20230102180020.p6gmiwhrnidfbfsc@illithid> <20230102181242.GO25547@mcvoy.com>
 <20230102192114.2uu7f4ap55e6xtby@illithid>
 <CAFH29tod5VUsP-cFhsEPaFmXAD7AUQQoY6D6w-DSekSGVZebXw@mail.gmail.com>
 <20230102202422.qychfa24tnjuok4p@illithid> <20230102204103.GU25547@mcvoy.com>
 <CAEoi9W4svE13AyRnD8v=Be_JppNtMH+OQOipGXzvxSZDuxRzpw@mail.gmail.com>
 <CAC20D2PJGk_9VVNtbAwMX7obyzkQ4QyUkAFsm2HpLk0TtRTRow@mail.gmail.com>
Message-ID: <CAEoi9W5zwBxckGPT-2BK=eCg-tSDz43SQP_bRXEuUwMVodMnnA@mail.gmail.com>

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 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: <CAC20D2PJGk_9VVNtbAwMX7obyzkQ4QyUkAFsm2HpLk0TtRTRow@mail.gmail.com>
References: <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102165120.GK25547@mcvoy.com>
 <E977D385-604F-49A9-83FD-8C5270623066@gmail.com>
 <20230102174304.GM25547@mcvoy.com>
 <59004a29-5119-9dd9-c248-518b8c4e7928@makerlisp.com>
 <20230102180020.p6gmiwhrnidfbfsc@illithid> <20230102181242.GO25547@mcvoy.com>
 <20230102192114.2uu7f4ap55e6xtby@illithid>
 <CAFH29tod5VUsP-cFhsEPaFmXAD7AUQQoY6D6w-DSekSGVZebXw@mail.gmail.com>
 <20230102202422.qychfa24tnjuok4p@illithid> <20230102204103.GU25547@mcvoy.com>
 <CAEoi9W4svE13AyRnD8v=Be_JppNtMH+OQOipGXzvxSZDuxRzpw@mail.gmail.com>
 <CAC20D2PJGk_9VVNtbAwMX7obyzkQ4QyUkAFsm2HpLk0TtRTRow@mail.gmail.com>
Message-ID: <alpine.DEB.2.21.2301021742510.30372@sd-119843.dedibox.fr>

On Mon, 2 Jan 2023, Clem Cole 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?
>
> 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: <CAEoi9W5zwBxckGPT-2BK=eCg-tSDz43SQP_bRXEuUwMVodMnnA@mail.gmail.com>
References: <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102181242.GO25547@mcvoy.com> <20230102192114.2uu7f4ap55e6xtby@illithid>
 <CAFH29tod5VUsP-cFhsEPaFmXAD7AUQQoY6D6w-DSekSGVZebXw@mail.gmail.com>
 <20230102202422.qychfa24tnjuok4p@illithid> <20230102204103.GU25547@mcvoy.com>
 <CAEoi9W4svE13AyRnD8v=Be_JppNtMH+OQOipGXzvxSZDuxRzpw@mail.gmail.com>
 <CAC20D2PJGk_9VVNtbAwMX7obyzkQ4QyUkAFsm2HpLk0TtRTRow@mail.gmail.com>
 <CAEoi9W5zwBxckGPT-2BK=eCg-tSDz43SQP_bRXEuUwMVodMnnA@mail.gmail.com>
Message-ID: <HMuvFxQaiVhWgILhlXtU03J5BE_cTb22x2cjmY1txNj9JagUP3xY0lODKxbK2nyv-t4mQet93hVTPMCLpVcO6Rom56n6VuPRuApARP4Ar4w=@protonmail.com>

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 <crossd at gmail.com> 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: <HMuvFxQaiVhWgILhlXtU03J5BE_cTb22x2cjmY1txNj9JagUP3xY0lODKxbK2nyv-t4mQet93hVTPMCLpVcO6Rom56n6VuPRuApARP4Ar4w=@protonmail.com>
References: <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102181242.GO25547@mcvoy.com> <20230102192114.2uu7f4ap55e6xtby@illithid>
 <CAFH29tod5VUsP-cFhsEPaFmXAD7AUQQoY6D6w-DSekSGVZebXw@mail.gmail.com>
 <20230102202422.qychfa24tnjuok4p@illithid> <20230102204103.GU25547@mcvoy.com>
 <CAEoi9W4svE13AyRnD8v=Be_JppNtMH+OQOipGXzvxSZDuxRzpw@mail.gmail.com>
 <CAC20D2PJGk_9VVNtbAwMX7obyzkQ4QyUkAFsm2HpLk0TtRTRow@mail.gmail.com>
 <CAEoi9W5zwBxckGPT-2BK=eCg-tSDz43SQP_bRXEuUwMVodMnnA@mail.gmail.com>
 <HMuvFxQaiVhWgILhlXtU03J5BE_cTb22x2cjmY1txNj9JagUP3xY0lODKxbK2nyv-t4mQet93hVTPMCLpVcO6Rom56n6VuPRuApARP4Ar4w=@protonmail.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: <CACyhTRFr30kF2W=GgQJsG0-dT61xWJyNkZrsmN-9c7W_VQSoAg@mail.gmail.com>

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 <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230103/3acc5dae/attachment.htm>

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: <DCF5069E-988D-4A3C-B517-1C9FA7B0C8B8@cfcl.com>

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 <lm at mcvoy.com> 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: <DCF5069E-988D-4A3C-B517-1C9FA7B0C8B8@cfcl.com>
References: <20230102203646.GT25547@mcvoy.com>
 <DCF5069E-988D-4A3C-B517-1C9FA7B0C8B8@cfcl.com>
Message-ID: <CA++P4r35t0wb9nEdkdbme-VszoP4mZOFcMrLsSsovuTTdra=4Q@mail.gmail.com>

On Tue, 3 Jan 2023 at 10:46, Rich Morin <rdm at cfcl.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230103/27808ecb/attachment-0001.htm>

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: <dafb2d95-d7bf-9980-4e9d-58db49c682da@case.edu>

On 1/1/23 5:44 AM, arnold at skeeve.com wrote:
> Chet Ramey <chet.ramey at case.edu> 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: <CAKH6PiWkt_PzES-RQ4YtmmsUFrgzgabfUaSW5eQpce4uC3-Amw@mail.gmail.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.

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: <CAKH6PiWkt_PzES-RQ4YtmmsUFrgzgabfUaSW5eQpce4uC3-Amw@mail.gmail.com>
References: <CAKH6PiWkt_PzES-RQ4YtmmsUFrgzgabfUaSW5eQpce4uC3-Amw@mail.gmail.com>
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: <CAC20D2Mv_y1038zxjT5FSxpx-WjKsJK5TfMY8ZWUiAr2JXx=RA@mail.gmail.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>
 <CAC20D2Mv_y1038zxjT5FSxpx-WjKsJK5TfMY8ZWUiAr2JXx=RA@mail.gmail.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: <CAEoi9W6rsmo_sWVTwQyy_=ic_cbYHR_RPOz0av4HUR=_Fi2jmA@mail.gmail.com>

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: <b689c244-3ea9-4fd6-bb45-a59d131071d6@app.fastmail.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>
 <b689c244-3ea9-4fd6-bb45-a59d131071d6@app.fastmail.com>
Message-ID: <CAK0pxsH6bWTLVApE_vDhATmMgaF+nwc5D3pSz4srtwGS-8Ux_A@mail.gmail.com>

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 <joseph at josephholsten.com>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230103/bcd4d0ed/attachment.htm>

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: <CAEoi9W6rsmo_sWVTwQyy_=ic_cbYHR_RPOz0av4HUR=_Fi2jmA@mail.gmail.com>
References: <CAEoi9W6rsmo_sWVTwQyy_=ic_cbYHR_RPOz0av4HUR=_Fi2jmA@mail.gmail.com>
Message-ID: <Y7Rd0MRxVgndo4Ey@fuz.su>

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: <CAC20D2OGi-Wq6K15vVXWp36kuB8Bd1NenE_K9jA_SJXYAaA1VA@mail.gmail.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>
 <alpine.BSF.2.21.9999.2212311516330.69068@aneurin.horsfall.org>
 <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net>
 <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102165120.GK25547@mcvoy.com>
 <CAC20D2OGi-Wq6K15vVXWp36kuB8Bd1NenE_K9jA_SJXYAaA1VA@mail.gmail.com>
Message-ID: <CABH=_VQdxU8q98fGwzXViTQQPLhY6QaTR3yVoBAwrP_5bH0fTA@mail.gmail.com>

On 1/2/23, Clem Cole <clemc at ccc.com> 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: <CAKH6PiWkt_PzES-RQ4YtmmsUFrgzgabfUaSW5eQpce4uC3-Amw@mail.gmail.com>
 <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: <CAKH6PiWkt_PzES-RQ4YtmmsUFrgzgabfUaSW5eQpce4uC3-Amw@mail.gmail.com>
References: <CAKH6PiWkt_PzES-RQ4YtmmsUFrgzgabfUaSW5eQpce4uC3-Amw@mail.gmail.com>
Message-ID: <CAEoi9W7_1eoKVbwyx8dLt1Cd9i+jR+Mg0L99yc+NK4sn7bOk5w@mail.gmail.com>

On Tue, Jan 3, 2023 at 10:09 AM Douglas McIlroy
<douglas.mcilroy at dartmouth.edu> 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: <Y7Rd0MRxVgndo4Ey@fuz.su>
References: <CAEoi9W6rsmo_sWVTwQyy_=ic_cbYHR_RPOz0av4HUR=_Fi2jmA@mail.gmail.com>
 <Y7Rd0MRxVgndo4Ey@fuz.su>
Message-ID: <CAEoi9W6nCxwEV=RGWDGstOSpMonVr-y7ULvH_7do+CTZMGu7KA@mail.gmail.com>

On Tue, Jan 3, 2023 at 11:54 AM Robert Clausecker <fuz at fuz.su> 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: <CAEoi9W7_1eoKVbwyx8dLt1Cd9i+jR+Mg0L99yc+NK4sn7bOk5w@mail.gmail.com>
References: <CAKH6PiWkt_PzES-RQ4YtmmsUFrgzgabfUaSW5eQpce4uC3-Amw@mail.gmail.com>
 <CAEoi9W7_1eoKVbwyx8dLt1Cd9i+jR+Mg0L99yc+NK4sn7bOk5w@mail.gmail.com>
Message-ID: <alpine.DEB.2.21.2301031307001.9988@sd-119843.dedibox.fr>

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: <CAEoi9W7_1eoKVbwyx8dLt1Cd9i+jR+Mg0L99yc+NK4sn7bOk5w@mail.gmail.com>
References: <CAKH6PiWkt_PzES-RQ4YtmmsUFrgzgabfUaSW5eQpce4uC3-Amw@mail.gmail.com>
 <CAEoi9W7_1eoKVbwyx8dLt1Cd9i+jR+Mg0L99yc+NK4sn7bOk5w@mail.gmail.com>
Message-ID: <CAK6BEgeQD7qjmhVC1B_h2umR8LS79r1NGjeGw3YVkC4X6Vpn4A@mail.gmail.com>

Den tis 3 jan. 2023 kl 18:28 skrev Dan Cross <crossd at gmail.com>:

> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230103/9b677158/attachment.htm>

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: <CABH=_VQdxU8q98fGwzXViTQQPLhY6QaTR3yVoBAwrP_5bH0fTA@mail.gmail.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>
 <alpine.BSF.2.21.9999.2212311516330.69068@aneurin.horsfall.org>
 <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net>
 <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102165120.GK25547@mcvoy.com>
 <CAC20D2OGi-Wq6K15vVXWp36kuB8Bd1NenE_K9jA_SJXYAaA1VA@mail.gmail.com>
 <CABH=_VQdxU8q98fGwzXViTQQPLhY6QaTR3yVoBAwrP_5bH0fTA@mail.gmail.com>
Message-ID: <CANCZdfqD6LF3tyuHxnxfAUqkD+fb6PN=dKcEa2ayAZ04EOtN2A@mail.gmail.com>

On Tue, Jan 3, 2023, 10:09 AM Paul Winalski <paul.winalski at gmail.com> wrote:

> On 1/2/23, Clem Cole <clemc at ccc.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230103/13d52da6/attachment-0001.htm>

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: <CANCZdfqD6LF3tyuHxnxfAUqkD+fb6PN=dKcEa2ayAZ04EOtN2A@mail.gmail.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>
 <alpine.BSF.2.21.9999.2212311516330.69068@aneurin.horsfall.org>
 <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net>
 <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102165120.GK25547@mcvoy.com>
 <CAC20D2OGi-Wq6K15vVXWp36kuB8Bd1NenE_K9jA_SJXYAaA1VA@mail.gmail.com>
 <CABH=_VQdxU8q98fGwzXViTQQPLhY6QaTR3yVoBAwrP_5bH0fTA@mail.gmail.com>
 <CANCZdfqD6LF3tyuHxnxfAUqkD+fb6PN=dKcEa2ayAZ04EOtN2A@mail.gmail.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 <paul.winalski at gmail.com 
> <mailto:paul.winalski at gmail.com>> wrote:
>
>     On 1/2/23, Clem Cole <clemc at ccc.com <mailto:clemc at ccc.com>> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230103/56b87a08/attachment.htm>

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: <T7O9_L4H1-SUKr8y-6Yukj-Gk8ydcnh3l2YyF9v8GlQ2_rdSqRX--NKPSnnedLGaAJc3LvXKU0t2OuzOWFRM4Llz-ztWG-G7LUrQN7c7SSg=@protonmail.com>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230103/5f968e8f/attachment.htm>

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: <CANCZdfqD6LF3tyuHxnxfAUqkD+fb6PN=dKcEa2ayAZ04EOtN2A@mail.gmail.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>
 <alpine.BSF.2.21.9999.2212311516330.69068@aneurin.horsfall.org>
 <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net>
 <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102165120.GK25547@mcvoy.com>
 <CAC20D2OGi-Wq6K15vVXWp36kuB8Bd1NenE_K9jA_SJXYAaA1VA@mail.gmail.com>
 <CABH=_VQdxU8q98fGwzXViTQQPLhY6QaTR3yVoBAwrP_5bH0fTA@mail.gmail.com>
 <CANCZdfqD6LF3tyuHxnxfAUqkD+fb6PN=dKcEa2ayAZ04EOtN2A@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.2301040714160.95173@aneurin.horsfall.org>

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: <CANCZdfqD6LF3tyuHxnxfAUqkD+fb6PN=dKcEa2ayAZ04EOtN2A@mail.gmail.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>
 <alpine.BSF.2.21.9999.2212311516330.69068@aneurin.horsfall.org>
 <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net>
 <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102165120.GK25547@mcvoy.com>
 <CAC20D2OGi-Wq6K15vVXWp36kuB8Bd1NenE_K9jA_SJXYAaA1VA@mail.gmail.com>
 <CABH=_VQdxU8q98fGwzXViTQQPLhY6QaTR3yVoBAwrP_5bH0fTA@mail.gmail.com>
 <CANCZdfqD6LF3tyuHxnxfAUqkD+fb6PN=dKcEa2ayAZ04EOtN2A@mail.gmail.com>
Message-ID: <CAC20D2Om9TPz_X-BkT3ODEYNRebBc2-J8ZeT2w4rEdLa8VzSqw@mail.gmail.com>

Bring this back to TUHS relevance...

On Tue, Jan 3, 2023 at 2:43 PM Warner Losh <imp at bsdimp.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230103/9a7b3198/attachment.htm>

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: <CAC20D2Om9TPz_X-BkT3ODEYNRebBc2-J8ZeT2w4rEdLa8VzSqw@mail.gmail.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>
 <alpine.BSF.2.21.9999.2212311516330.69068@aneurin.horsfall.org>
 <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net>
 <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102165120.GK25547@mcvoy.com>
 <CAC20D2OGi-Wq6K15vVXWp36kuB8Bd1NenE_K9jA_SJXYAaA1VA@mail.gmail.com>
 <CABH=_VQdxU8q98fGwzXViTQQPLhY6QaTR3yVoBAwrP_5bH0fTA@mail.gmail.com>
 <CANCZdfqD6LF3tyuHxnxfAUqkD+fb6PN=dKcEa2ayAZ04EOtN2A@mail.gmail.com>
 <CAC20D2Om9TPz_X-BkT3ODEYNRebBc2-J8ZeT2w4rEdLa8VzSqw@mail.gmail.com>
Message-ID: <CAC20D2MFWoJAuoBENQaykrVdu3HzwXEiKww21_2xyA0JaWDO9A@mail.gmail.com>

typo: s/My complaining/Much complaining/
sigh.. dyslex-r-me
ᐧ

On Tue, Jan 3, 2023 at 4:47 PM Clem Cole <clemc at ccc.com> wrote:

>
> Bring this back to TUHS relevance...
>
> On Tue, Jan 3, 2023 at 2:43 PM Warner Losh <imp at bsdimp.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230103/7bdaa2cd/attachment.htm>

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: <alpine.DEB.2.21.2301031307001.9988@sd-119843.dedibox.fr>
References: <CAKH6PiWkt_PzES-RQ4YtmmsUFrgzgabfUaSW5eQpce4uC3-Amw@mail.gmail.com>
 <CAEoi9W7_1eoKVbwyx8dLt1Cd9i+jR+Mg0L99yc+NK4sn7bOk5w@mail.gmail.com>
 <alpine.DEB.2.21.2301031307001.9988@sd-119843.dedibox.fr>
Message-ID: <20230103201900.oR1Qq%steffen@sdaoden.eu>

Steve Nickolas wrote in
 <alpine.DEB.2.21.2301031307001.9988 at sd-119843.dedibox.fr>:
 |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: <CAKH6PiWkt_PzES-RQ4YtmmsUFrgzgabfUaSW5eQpce4uC3-Amw@mail.gmail.com>
 <CAEoi9W7_1eoKVbwyx8dLt1Cd9i+jR+Mg0L99yc+NK4sn7bOk5w@mail.gmail.com>
 <alpine.DEB.2.21.2301031307001.9988@sd-119843.dedibox.fr>
 <20230103201900.oR1Qq%steffen@sdaoden.eu>
Message-ID: <CAP6exYKCEyycFM4CiaW=7fzk_-8uXdLJ=Xq6UP+sHTjtc=+hmw@mail.gmail.com>

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 <steffen at sdaoden.eu> wrote:

> Steve Nickolas wrote in
>  <alpine.DEB.2.21.2301031307001.9988 at sd-119843.dedibox.fr>:
>  |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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230103/7d25b0c0/attachment.htm>

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: <T7O9_L4H1-SUKr8y-6Yukj-Gk8ydcnh3l2YyF9v8GlQ2_rdSqRX--NKPSnnedLGaAJc3LvXKU0t2OuzOWFRM4Llz-ztWG-G7LUrQN7c7SSg=@protonmail.com>
References: <T7O9_L4H1-SUKr8y-6Yukj-Gk8ydcnh3l2YyF9v8GlQ2_rdSqRX--NKPSnnedLGaAJc3LvXKU0t2OuzOWFRM4Llz-ztWG-G7LUrQN7c7SSg=@protonmail.com>
Message-ID: <hDAT9jRCXycXK5hW3qJn9tB4N_FuI7ZgNxhIgs_6rfNhNmkz6SvnkpQX7vVNf6z6Vtxml-rYoBEv0IYXA1RD7kFqs-4psHsrW3FMsX8JopA=@protonmail.com>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230103/8829bfc9/attachment.htm>

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: <T7O9_L4H1-SUKr8y-6Yukj-Gk8ydcnh3l2YyF9v8GlQ2_rdSqRX--NKPSnnedLGaAJc3LvXKU0t2OuzOWFRM4Llz-ztWG-G7LUrQN7c7SSg=@protonmail.com>
 <hDAT9jRCXycXK5hW3qJn9tB4N_FuI7ZgNxhIgs_6rfNhNmkz6SvnkpQX7vVNf6z6Vtxml-rYoBEv0IYXA1RD7kFqs-4psHsrW3FMsX8JopA=@protonmail.com>
 <371F8C4D-AAAC-4CD9-9547-3A7AC0C961D0@atvetsystems.com>
Message-ID: <j-oAfrzxNPYVV1dsBfnZvdwkNmm8sxkCuhL7d8i45WtV8PWYv84w6OrPyUCjdqtuHdiOLZmSSABDjfwabxbetCddOWhN0g1laxp9fSJZ6TE=@protonmail.com>

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 <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 <tuhs at tuhs.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230104/bd3cdd21/attachment-0001.htm>

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: <j-oAfrzxNPYVV1dsBfnZvdwkNmm8sxkCuhL7d8i45WtV8PWYv84w6OrPyUCjdqtuHdiOLZmSSABDjfwabxbetCddOWhN0g1laxp9fSJZ6TE=@protonmail.com>
References: <T7O9_L4H1-SUKr8y-6Yukj-Gk8ydcnh3l2YyF9v8GlQ2_rdSqRX--NKPSnnedLGaAJc3LvXKU0t2OuzOWFRM4Llz-ztWG-G7LUrQN7c7SSg=@protonmail.com>
 <hDAT9jRCXycXK5hW3qJn9tB4N_FuI7ZgNxhIgs_6rfNhNmkz6SvnkpQX7vVNf6z6Vtxml-rYoBEv0IYXA1RD7kFqs-4psHsrW3FMsX8JopA=@protonmail.com>
 <371F8C4D-AAAC-4CD9-9547-3A7AC0C961D0@atvetsystems.com>
 <j-oAfrzxNPYVV1dsBfnZvdwkNmm8sxkCuhL7d8i45WtV8PWYv84w6OrPyUCjdqtuHdiOLZmSSABDjfwabxbetCddOWhN0g1laxp9fSJZ6TE=@protonmail.com>
Message-ID: <CANCZdfpRNXWW-_Su1tOW8LbqwmQA259qb_ewmW8wBkGw4maY3A@mail.gmail.com>

On Tue, Jan 3, 2023, 5:30 PM segaloco via TUHS <tuhs at tuhs.org> 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 <tuhs at tuhs.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230103/6fb77121/attachment.htm>

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: <CANCZdfpRNXWW-_Su1tOW8LbqwmQA259qb_ewmW8wBkGw4maY3A@mail.gmail.com>
References: <T7O9_L4H1-SUKr8y-6Yukj-Gk8ydcnh3l2YyF9v8GlQ2_rdSqRX--NKPSnnedLGaAJc3LvXKU0t2OuzOWFRM4Llz-ztWG-G7LUrQN7c7SSg=@protonmail.com>
 <hDAT9jRCXycXK5hW3qJn9tB4N_FuI7ZgNxhIgs_6rfNhNmkz6SvnkpQX7vVNf6z6Vtxml-rYoBEv0IYXA1RD7kFqs-4psHsrW3FMsX8JopA=@protonmail.com>
 <371F8C4D-AAAC-4CD9-9547-3A7AC0C961D0@atvetsystems.com>
 <j-oAfrzxNPYVV1dsBfnZvdwkNmm8sxkCuhL7d8i45WtV8PWYv84w6OrPyUCjdqtuHdiOLZmSSABDjfwabxbetCddOWhN0g1laxp9fSJZ6TE=@protonmail.com>
 <CANCZdfpRNXWW-_Su1tOW8LbqwmQA259qb_ewmW8wBkGw4maY3A@mail.gmail.com>
Message-ID: <ACavnuDMzRJlFABC_P-tXhTGuLoD_lMfpoMAnmTSBB31yvLnOwZrjJwOa07pDkAkjfB0FDfzgCcZ7jryd9R2tpJtURh_y18zK11vPu90EL0=@protonmail.com>

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 <imp at bsdimp.com> wrote:

> On Tue, Jan 3, 2023, 5:30 PM segaloco via TUHS <tuhs at tuhs.org> 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 <tuhs at tuhs.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230104/d8b3545f/attachment.htm>

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: <ACavnuDMzRJlFABC_P-tXhTGuLoD_lMfpoMAnmTSBB31yvLnOwZrjJwOa07pDkAkjfB0FDfzgCcZ7jryd9R2tpJtURh_y18zK11vPu90EL0=@protonmail.com>
References: <T7O9_L4H1-SUKr8y-6Yukj-Gk8ydcnh3l2YyF9v8GlQ2_rdSqRX--NKPSnnedLGaAJc3LvXKU0t2OuzOWFRM4Llz-ztWG-G7LUrQN7c7SSg=@protonmail.com>
 <hDAT9jRCXycXK5hW3qJn9tB4N_FuI7ZgNxhIgs_6rfNhNmkz6SvnkpQX7vVNf6z6Vtxml-rYoBEv0IYXA1RD7kFqs-4psHsrW3FMsX8JopA=@protonmail.com>
 <371F8C4D-AAAC-4CD9-9547-3A7AC0C961D0@atvetsystems.com>
 <j-oAfrzxNPYVV1dsBfnZvdwkNmm8sxkCuhL7d8i45WtV8PWYv84w6OrPyUCjdqtuHdiOLZmSSABDjfwabxbetCddOWhN0g1laxp9fSJZ6TE=@protonmail.com>
 <CANCZdfpRNXWW-_Su1tOW8LbqwmQA259qb_ewmW8wBkGw4maY3A@mail.gmail.com>
 <ACavnuDMzRJlFABC_P-tXhTGuLoD_lMfpoMAnmTSBB31yvLnOwZrjJwOa07pDkAkjfB0FDfzgCcZ7jryd9R2tpJtURh_y18zK11vPu90EL0=@protonmail.com>
Message-ID: <CANCZdfqFtFo+W-T+3MKovsdx7OJXo8yYH_-bu7hjo0j-qviwsQ@mail.gmail.com>

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 <segaloco at protonmail.com> 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 <imp at bsdimp.com>
> wrote:
>
>
>
> On Tue, Jan 3, 2023, 5:30 PM segaloco via TUHS <tuhs at tuhs.org> 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 <tuhs at tuhs.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230103/df0179b3/attachment.htm>

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: <CAEoi9W7_1eoKVbwyx8dLt1Cd9i+jR+Mg0L99yc+NK4sn7bOk5w@mail.gmail.com>
References: <CAKH6PiWkt_PzES-RQ4YtmmsUFrgzgabfUaSW5eQpce4uC3-Amw@mail.gmail.com>
 <CAEoi9W7_1eoKVbwyx8dLt1Cd9i+jR+Mg0L99yc+NK4sn7bOk5w@mail.gmail.com>
Message-ID: <C7C6136E-BA3F-48B9-9E8B-FA90BDC10DFB@gmail.com>



> On Jan 3, 2023, at 10:26 AM, Dan Cross <crossd at gmail.com> 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: <CAP6exYKCEyycFM4CiaW=7fzk_-8uXdLJ=Xq6UP+sHTjtc=+hmw@mail.gmail.com>
References: <CAKH6PiWkt_PzES-RQ4YtmmsUFrgzgabfUaSW5eQpce4uC3-Amw@mail.gmail.com>
 <CAEoi9W7_1eoKVbwyx8dLt1Cd9i+jR+Mg0L99yc+NK4sn7bOk5w@mail.gmail.com>
 <alpine.DEB.2.21.2301031307001.9988@sd-119843.dedibox.fr>
 <20230103201900.oR1Qq%steffen@sdaoden.eu>
 <CAP6exYKCEyycFM4CiaW=7fzk_-8uXdLJ=Xq6UP+sHTjtc=+hmw@mail.gmail.com>
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 <rminnich at gmail.com> 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 <http://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 <http://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 <http://github.com/u-root/sourcery>
> 
> 
> On Tue, Jan 3, 2023 at 2:35 PM Steffen Nurpmeso <steffen at sdaoden.eu <mailto:steffen at sdaoden.eu>> wrote:
>> Steve Nickolas wrote in
>>  <alpine.DEB.2.21.2301031307001.9988 at sd-119843.dedibox.fr <mailto:alpine.DEB.2.21.2301031307001.9988 at sd-119843.dedibox.fr>>:
>>  |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 <mailto: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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230103/3edf19ef/attachment.htm>

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: <CAKH6PiWkt_PzES-RQ4YtmmsUFrgzgabfUaSW5eQpce4uC3-Amw@mail.gmail.com>
 <CAEoi9W7_1eoKVbwyx8dLt1Cd9i+jR+Mg0L99yc+NK4sn7bOk5w@mail.gmail.com>
 <alpine.DEB.2.21.2301031307001.9988@sd-119843.dedibox.fr>
 <20230103201900.oR1Qq%steffen@sdaoden.eu>
 <CAP6exYKCEyycFM4CiaW=7fzk_-8uXdLJ=Xq6UP+sHTjtc=+hmw@mail.gmail.com>
 <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 <bakul at iitbombay.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230103/c8e4aa79/attachment.htm>

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>
 <alpine.BSF.2.21.9999.2212311516330.69068@aneurin.horsfall.org>
 <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net>
 <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102165120.GK25547@mcvoy.com>
 <E977D385-604F-49A9-83FD-8C5270623066@gmail.com>
 <20230102174304.GM25547@mcvoy.com>
Message-ID: <CAD2gp_TCk5AOGVVx1Dd8u_++ttDQgd7jB+UUgj62c6Z1ZR+X+g@mail.gmail.com>

On Mon, Jan 2, 2023 at 12:43 PM Larry McVoy <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230103/bc27c54e/attachment.htm>

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: <CAD2gp_TCk5AOGVVx1Dd8u_++ttDQgd7jB+UUgj62c6Z1ZR+X+g@mail.gmail.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>
 <alpine.BSF.2.21.9999.2212311516330.69068@aneurin.horsfall.org>
 <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net>
 <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102165120.GK25547@mcvoy.com>
 <E977D385-604F-49A9-83FD-8C5270623066@gmail.com>
 <20230102174304.GM25547@mcvoy.com>
 <CAD2gp_TCk5AOGVVx1Dd8u_++ttDQgd7jB+UUgj62c6Z1ZR+X+g@mail.gmail.com>
Message-ID: <CAEoi9W7O1-JohHg1eQqib=GzCecUK8wNvEzij0ph4SMbhsoxng@mail.gmail.com>

On Tue, Jan 3, 2023 at 10:22 PM John Cowan <cowan at ccil.org> 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: <CAEoi9W7O1-JohHg1eQqib=GzCecUK8wNvEzij0ph4SMbhsoxng@mail.gmail.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>
 <alpine.BSF.2.21.9999.2212311516330.69068@aneurin.horsfall.org>
 <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net>
 <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102165120.GK25547@mcvoy.com>
 <E977D385-604F-49A9-83FD-8C5270623066@gmail.com>
 <20230102174304.GM25547@mcvoy.com>
 <CAD2gp_TCk5AOGVVx1Dd8u_++ttDQgd7jB+UUgj62c6Z1ZR+X+g@mail.gmail.com>
 <CAEoi9W7O1-JohHg1eQqib=GzCecUK8wNvEzij0ph4SMbhsoxng@mail.gmail.com>
Message-ID: <FF6C0C34-1E8E-4D5A-96BC-2BD326E2D1EB@iitbombay.org>

On Jan 3, 2023, at 7:31 PM, Dan Cross <crossd at gmail.com> wrote:
> 
> On Tue, Jan 3, 2023 at 10:22 PM John Cowan <cowan at ccil.org> 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: <CAP6exYKCEyycFM4CiaW=7fzk_-8uXdLJ=Xq6UP+sHTjtc=+hmw@mail.gmail.com>
References: <CAKH6PiWkt_PzES-RQ4YtmmsUFrgzgabfUaSW5eQpce4uC3-Amw@mail.gmail.com>
 <CAEoi9W7_1eoKVbwyx8dLt1Cd9i+jR+Mg0L99yc+NK4sn7bOk5w@mail.gmail.com>
 <alpine.DEB.2.21.2301031307001.9988@sd-119843.dedibox.fr>
 <20230103201900.oR1Qq%steffen@sdaoden.eu>
 <CAP6exYKCEyycFM4CiaW=7fzk_-8uXdLJ=Xq6UP+sHTjtc=+hmw@mail.gmail.com>
Message-ID: <Y7UJJbUOihdtV5Hw@mit.edu>

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 <jon at fourwinds.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230104/8bddbbbf/attachment.htm>

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: <CAK0pxsH6bWTLVApE_vDhATmMgaF+nwc5D3pSz4srtwGS-8Ux_A@mail.gmail.com>
References: <CAK0pxsH6bWTLVApE_vDhATmMgaF+nwc5D3pSz4srtwGS-8Ux_A@mail.gmail.com>
Message-ID: <B931A059-5E99-4DBE-B30C-74D8E9D2F637@josephholsten.com>


> On Jan 3, 2023, at 08:55, Marshall Conover <marzhall.o at gmail.com> 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: <CANCZdfqFtFo+W-T+3MKovsdx7OJXo8yYH_-bu7hjo0j-qviwsQ@mail.gmail.com>
References: <T7O9_L4H1-SUKr8y-6Yukj-Gk8ydcnh3l2YyF9v8GlQ2_rdSqRX--NKPSnnedLGaAJc3LvXKU0t2OuzOWFRM4Llz-ztWG-G7LUrQN7c7SSg=@protonmail.com>
 <hDAT9jRCXycXK5hW3qJn9tB4N_FuI7ZgNxhIgs_6rfNhNmkz6SvnkpQX7vVNf6z6Vtxml-rYoBEv0IYXA1RD7kFqs-4psHsrW3FMsX8JopA=@protonmail.com>
 <371F8C4D-AAAC-4CD9-9547-3A7AC0C961D0@atvetsystems.com>
 <j-oAfrzxNPYVV1dsBfnZvdwkNmm8sxkCuhL7d8i45WtV8PWYv84w6OrPyUCjdqtuHdiOLZmSSABDjfwabxbetCddOWhN0g1laxp9fSJZ6TE=@protonmail.com>
 <CANCZdfpRNXWW-_Su1tOW8LbqwmQA259qb_ewmW8wBkGw4maY3A@mail.gmail.com>
 <ACavnuDMzRJlFABC_P-tXhTGuLoD_lMfpoMAnmTSBB31yvLnOwZrjJwOa07pDkAkjfB0FDfzgCcZ7jryd9R2tpJtURh_y18zK11vPu90EL0=@protonmail.com>
 <CANCZdfqFtFo+W-T+3MKovsdx7OJXo8yYH_-bu7hjo0j-qviwsQ@mail.gmail.com>
Message-ID: <CACyhTRF2uLjpsMT3wCSA7Sk9NgfANLA5LDS2o4soVcRD7MZnKg@mail.gmail.com>

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 <imp at bsdimp.com> 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 <segaloco at protonmail.com> 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 <imp at bsdimp.com>
>> wrote:
>>
>>
>>
>> On Tue, Jan 3, 2023, 5:30 PM segaloco via TUHS <tuhs at tuhs.org> 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 <tuhs at tuhs.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230104/d2073d0d/attachment.htm>

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: <CAKH6PiWkt_PzES-RQ4YtmmsUFrgzgabfUaSW5eQpce4uC3-Amw@mail.gmail.com>
 <CAEoi9W7_1eoKVbwyx8dLt1Cd9i+jR+Mg0L99yc+NK4sn7bOk5w@mail.gmail.com>
 <alpine.DEB.2.21.2301031307001.9988@sd-119843.dedibox.fr>
 <20230103201900.oR1Qq%steffen@sdaoden.eu>
 <CAP6exYKCEyycFM4CiaW=7fzk_-8uXdLJ=Xq6UP+sHTjtc=+hmw@mail.gmail.com>
 <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: <CAD2gp_TCk5AOGVVx1Dd8u_++ttDQgd7jB+UUgj62c6Z1ZR+X+g@mail.gmail.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>
 <alpine.BSF.2.21.9999.2212311516330.69068@aneurin.horsfall.org>
 <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net>
 <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102165120.GK25547@mcvoy.com>
 <E977D385-604F-49A9-83FD-8C5270623066@gmail.com>
 <20230102174304.GM25547@mcvoy.com>
 <CAD2gp_TCk5AOGVVx1Dd8u_++ttDQgd7jB+UUgj62c6Z1ZR+X+g@mail.gmail.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>
 <alpine.BSF.2.21.9999.2212311516330.69068@aneurin.horsfall.org>
 <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net>
 <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102165120.GK25547@mcvoy.com>
 <E977D385-604F-49A9-83FD-8C5270623066@gmail.com>
 <20230102174304.GM25547@mcvoy.com>
 <CAD2gp_TCk5AOGVVx1Dd8u_++ttDQgd7jB+UUgj62c6Z1ZR+X+g@mail.gmail.com>
 <20230104152102.D8ABA2064E@orac.inputplus.co.uk>
Message-ID: <em6e8291f0-1866-4558-ae70-47670519ece3@e41218a5.com>


Indeed.    MiniUnix had no hardware pipes, but the shell “simulated” it 
by writing to a intermediate temp file.


------ Original Message ------
>From "Ralph Corderoy" <ralph at inputplus.co.uk>
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: <FF6C0C34-1E8E-4D5A-96BC-2BD326E2D1EB@iitbombay.org>
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>
 <alpine.BSF.2.21.9999.2212311516330.69068@aneurin.horsfall.org>
 <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net>
 <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102165120.GK25547@mcvoy.com>
 <E977D385-604F-49A9-83FD-8C5270623066@gmail.com>
 <20230102174304.GM25547@mcvoy.com>
 <CAD2gp_TCk5AOGVVx1Dd8u_++ttDQgd7jB+UUgj62c6Z1ZR+X+g@mail.gmail.com>
 <CAEoi9W7O1-JohHg1eQqib=GzCecUK8wNvEzij0ph4SMbhsoxng@mail.gmail.com>
 <FF6C0C34-1E8E-4D5A-96BC-2BD326E2D1EB@iitbombay.org>
Message-ID: <CAEoi9W6cXfkcnmDGY+AAgeqYQXAetwN0r_STigQiNqcZ+WKgDg@mail.gmail.com>

On Tue, Jan 3, 2023 at 11:16 PM Bakul Shah <bakul at iitbombay.org> wrote:
> On Jan 3, 2023, at 7:31 PM, Dan Cross <crossd at gmail.com> wrote:
> > On Tue, Jan 3, 2023 at 10:22 PM John Cowan <cowan at ccil.org> 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: <CAKH6PiWkt_PzES-RQ4YtmmsUFrgzgabfUaSW5eQpce4uC3-Amw@mail.gmail.com>
 <CAEoi9W7_1eoKVbwyx8dLt1Cd9i+jR+Mg0L99yc+NK4sn7bOk5w@mail.gmail.com>
 <alpine.DEB.2.21.2301031307001.9988@sd-119843.dedibox.fr>
 <20230103201900.oR1Qq%steffen@sdaoden.eu>
 <CAP6exYKCEyycFM4CiaW=7fzk_-8uXdLJ=Xq6UP+sHTjtc=+hmw@mail.gmail.com>
 <325DF7E4-37BE-4432-9447-0B392B57DC69@iitbombay.org>
 <42B6E514-D210-49D3-A103-351F94563852@gmail.com>
 <20230104151952.7C2542064E@orac.inputplus.co.uk>
Message-ID: <D00371A8-DD80-43AB-93A5-FA1D1E19BC04@iitbombay.org>

On Jan 4, 2023, at 7:19 AM, Ralph Corderoy <ralph at inputplus.co.uk> 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: <CAEoi9W6cXfkcnmDGY+AAgeqYQXAetwN0r_STigQiNqcZ+WKgDg@mail.gmail.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>
 <alpine.BSF.2.21.9999.2212311516330.69068@aneurin.horsfall.org>
 <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net>
 <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102165120.GK25547@mcvoy.com>
 <E977D385-604F-49A9-83FD-8C5270623066@gmail.com>
 <20230102174304.GM25547@mcvoy.com>
 <CAD2gp_TCk5AOGVVx1Dd8u_++ttDQgd7jB+UUgj62c6Z1ZR+X+g@mail.gmail.com>
 <CAEoi9W7O1-JohHg1eQqib=GzCecUK8wNvEzij0ph4SMbhsoxng@mail.gmail.com>
 <FF6C0C34-1E8E-4D5A-96BC-2BD326E2D1EB@iitbombay.org>
 <CAEoi9W6cXfkcnmDGY+AAgeqYQXAetwN0r_STigQiNqcZ+WKgDg@mail.gmail.com>
Message-ID: <CAP6exYJwSMNvn1E-JW1q+rar5UKNx0eVzyiTX20NLuAPkBmCoA@mail.gmail.com>

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 <crossd at gmail.com> wrote:

> On Tue, Jan 3, 2023 at 11:16 PM Bakul Shah <bakul at iitbombay.org> wrote:
> > On Jan 3, 2023, at 7:31 PM, Dan Cross <crossd at gmail.com> wrote:
> > > On Tue, Jan 3, 2023 at 10:22 PM John Cowan <cowan at ccil.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230104/3f51644c/attachment.htm>

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: <CAEoi9W6cXfkcnmDGY+AAgeqYQXAetwN0r_STigQiNqcZ+WKgDg@mail.gmail.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>
 <alpine.BSF.2.21.9999.2212311516330.69068@aneurin.horsfall.org>
 <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net>
 <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
 <20230102165120.GK25547@mcvoy.com>
 <E977D385-604F-49A9-83FD-8C5270623066@gmail.com>
 <20230102174304.GM25547@mcvoy.com>
 <CAD2gp_TCk5AOGVVx1Dd8u_++ttDQgd7jB+UUgj62c6Z1ZR+X+g@mail.gmail.com>
 <CAEoi9W7O1-JohHg1eQqib=GzCecUK8wNvEzij0ph4SMbhsoxng@mail.gmail.com>
 <FF6C0C34-1E8E-4D5A-96BC-2BD326E2D1EB@iitbombay.org>
 <CAEoi9W6cXfkcnmDGY+AAgeqYQXAetwN0r_STigQiNqcZ+WKgDg@mail.gmail.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 <bakul at iitbombay.org> wrote:
>> On Jan 3, 2023, at 7:31 PM, Dan Cross <crossd at gmail.com> wrote:
>>> On Tue, Jan 3, 2023 at 10:22 PM John Cowan <cowan at ccil.org> 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: <D00371A8-DD80-43AB-93A5-FA1D1E19BC04@iitbombay.org>
References: <CAKH6PiWkt_PzES-RQ4YtmmsUFrgzgabfUaSW5eQpce4uC3-Amw@mail.gmail.com>
 <CAEoi9W7_1eoKVbwyx8dLt1Cd9i+jR+Mg0L99yc+NK4sn7bOk5w@mail.gmail.com>
 <alpine.DEB.2.21.2301031307001.9988@sd-119843.dedibox.fr>
 <20230103201900.oR1Qq%steffen@sdaoden.eu>
 <CAP6exYKCEyycFM4CiaW=7fzk_-8uXdLJ=Xq6UP+sHTjtc=+hmw@mail.gmail.com>
 <325DF7E4-37BE-4432-9447-0B392B57DC69@iitbombay.org>
 <42B6E514-D210-49D3-A103-351F94563852@gmail.com>
 <20230104151952.7C2542064E@orac.inputplus.co.uk>
 <D00371A8-DD80-43AB-93A5-FA1D1E19BC04@iitbombay.org>
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 <ralph at inputplus.co.uk> 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: <CANCZdfqFtFo+W-T+3MKovsdx7OJXo8yYH_-bu7hjo0j-qviwsQ@mail.gmail.com>
References: <T7O9_L4H1-SUKr8y-6Yukj-Gk8ydcnh3l2YyF9v8GlQ2_rdSqRX--NKPSnnedLGaAJc3LvXKU0t2OuzOWFRM4Llz-ztWG-G7LUrQN7c7SSg=@protonmail.com>
 <hDAT9jRCXycXK5hW3qJn9tB4N_FuI7ZgNxhIgs_6rfNhNmkz6SvnkpQX7vVNf6z6Vtxml-rYoBEv0IYXA1RD7kFqs-4psHsrW3FMsX8JopA=@protonmail.com>
 <371F8C4D-AAAC-4CD9-9547-3A7AC0C961D0@atvetsystems.com>
 <j-oAfrzxNPYVV1dsBfnZvdwkNmm8sxkCuhL7d8i45WtV8PWYv84w6OrPyUCjdqtuHdiOLZmSSABDjfwabxbetCddOWhN0g1laxp9fSJZ6TE=@protonmail.com>
 <CANCZdfpRNXWW-_Su1tOW8LbqwmQA259qb_ewmW8wBkGw4maY3A@mail.gmail.com>
 <ACavnuDMzRJlFABC_P-tXhTGuLoD_lMfpoMAnmTSBB31yvLnOwZrjJwOa07pDkAkjfB0FDfzgCcZ7jryd9R2tpJtURh_y18zK11vPu90EL0=@protonmail.com>
 <CANCZdfqFtFo+W-T+3MKovsdx7OJXo8yYH_-bu7hjo0j-qviwsQ@mail.gmail.com>
Message-ID: <CAC20D2OFRn-0bPga+RP1r8vN7oUD2t_7tNAi=Q5_LKzAGu_JzQ@mail.gmail.com>

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 <imp at bsdimp.com> 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 <segaloco at protonmail.com> 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 <imp at bsdimp.com>
>> wrote:
>>
>>
>>
>> On Tue, Jan 3, 2023, 5:30 PM segaloco via TUHS <tuhs at tuhs.org> 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 <tuhs at tuhs.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230104/4d1026e1/attachment.htm>

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: <CAC20D2OFRn-0bPga+RP1r8vN7oUD2t_7tNAi=Q5_LKzAGu_JzQ@mail.gmail.com>
References: <T7O9_L4H1-SUKr8y-6Yukj-Gk8ydcnh3l2YyF9v8GlQ2_rdSqRX--NKPSnnedLGaAJc3LvXKU0t2OuzOWFRM4Llz-ztWG-G7LUrQN7c7SSg=@protonmail.com>
 <hDAT9jRCXycXK5hW3qJn9tB4N_FuI7ZgNxhIgs_6rfNhNmkz6SvnkpQX7vVNf6z6Vtxml-rYoBEv0IYXA1RD7kFqs-4psHsrW3FMsX8JopA=@protonmail.com>
 <371F8C4D-AAAC-4CD9-9547-3A7AC0C961D0@atvetsystems.com>
 <j-oAfrzxNPYVV1dsBfnZvdwkNmm8sxkCuhL7d8i45WtV8PWYv84w6OrPyUCjdqtuHdiOLZmSSABDjfwabxbetCddOWhN0g1laxp9fSJZ6TE=@protonmail.com>
 <CANCZdfpRNXWW-_Su1tOW8LbqwmQA259qb_ewmW8wBkGw4maY3A@mail.gmail.com>
 <ACavnuDMzRJlFABC_P-tXhTGuLoD_lMfpoMAnmTSBB31yvLnOwZrjJwOa07pDkAkjfB0FDfzgCcZ7jryd9R2tpJtURh_y18zK11vPu90EL0=@protonmail.com>
 <CANCZdfqFtFo+W-T+3MKovsdx7OJXo8yYH_-bu7hjo0j-qviwsQ@mail.gmail.com>
 <CAC20D2OFRn-0bPga+RP1r8vN7oUD2t_7tNAi=Q5_LKzAGu_JzQ@mail.gmail.com>
Message-ID: <CAC20D2PFKic0bKvwR8E+M7TkB3B=tsbsQphP1i+oP46qiRd0wA@mail.gmail.com>

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 <clemc at ccc.com> 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 <imp at bsdimp.com> 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 <segaloco at protonmail.com> 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 <imp at bsdimp.com>
>>> wrote:
>>>
>>>
>>>
>>> On Tue, Jan 3, 2023, 5:30 PM segaloco via TUHS <tuhs at tuhs.org> 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 <tuhs at tuhs.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230104/4bcfc636/attachment.htm>

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: <CAKH6PiWkt_PzES-RQ4YtmmsUFrgzgabfUaSW5eQpce4uC3-Amw@mail.gmail.com>
 <CAEoi9W7_1eoKVbwyx8dLt1Cd9i+jR+Mg0L99yc+NK4sn7bOk5w@mail.gmail.com>
 <alpine.DEB.2.21.2301031307001.9988@sd-119843.dedibox.fr>
 <20230103201900.oR1Qq%steffen@sdaoden.eu>
 <CAP6exYKCEyycFM4CiaW=7fzk_-8uXdLJ=Xq6UP+sHTjtc=+hmw@mail.gmail.com>
 <325DF7E4-37BE-4432-9447-0B392B57DC69@iitbombay.org>
 <42B6E514-D210-49D3-A103-351F94563852@gmail.com>
 <20230104151952.7C2542064E@orac.inputplus.co.uk>
 <D00371A8-DD80-43AB-93A5-FA1D1E19BC04@iitbombay.org>
 <2b630b83-11de-eff1-d458-d8d145d9f19d@gmail.com>
Message-ID: <CAD2gp_R-F2UoXxRGmD_KkpQmVqbEL8-o6Hn+Snfq6n=dHJQB7A@mail.gmail.com>

On Wed, Jan 4, 2023 at 3:47 PM Alejandro Colomar <alx.manpages at gmail.com>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230104/0b8fe664/attachment.htm>

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: <CAD2gp_R-F2UoXxRGmD_KkpQmVqbEL8-o6Hn+Snfq6n=dHJQB7A@mail.gmail.com>
References: <CAKH6PiWkt_PzES-RQ4YtmmsUFrgzgabfUaSW5eQpce4uC3-Amw@mail.gmail.com>
 <CAEoi9W7_1eoKVbwyx8dLt1Cd9i+jR+Mg0L99yc+NK4sn7bOk5w@mail.gmail.com>
 <alpine.DEB.2.21.2301031307001.9988@sd-119843.dedibox.fr>
 <20230103201900.oR1Qq%steffen@sdaoden.eu>
 <CAP6exYKCEyycFM4CiaW=7fzk_-8uXdLJ=Xq6UP+sHTjtc=+hmw@mail.gmail.com>
 <325DF7E4-37BE-4432-9447-0B392B57DC69@iitbombay.org>
 <42B6E514-D210-49D3-A103-351F94563852@gmail.com>
 <20230104151952.7C2542064E@orac.inputplus.co.uk>
 <D00371A8-DD80-43AB-93A5-FA1D1E19BC04@iitbombay.org>
 <2b630b83-11de-eff1-d458-d8d145d9f19d@gmail.com>
 <CAD2gp_R-F2UoXxRGmD_KkpQmVqbEL8-o6Hn+Snfq6n=dHJQB7A@mail.gmail.com>
Message-ID: <CAP2nic3Pug4RMpMuG2MuJ96eTDNJvRYTqTif_L_o+1MZV8WXdw@mail.gmail.com>

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 <cowan at ccil.org> wrote:

>
>
> On Wed, Jan 4, 2023 at 3:47 PM Alejandro Colomar <alx.manpages at gmail.com>
> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230104/d0dfa1b3/attachment.htm>

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: <C7C6136E-BA3F-48B9-9E8B-FA90BDC10DFB@gmail.com>
References: <CAKH6PiWkt_PzES-RQ4YtmmsUFrgzgabfUaSW5eQpce4uC3-Amw@mail.gmail.com>
 <CAEoi9W7_1eoKVbwyx8dLt1Cd9i+jR+Mg0L99yc+NK4sn7bOk5w@mail.gmail.com>
 <C7C6136E-BA3F-48B9-9E8B-FA90BDC10DFB@gmail.com>
Message-ID: <bf914d26-8746-7cf3-1e3d-eb3b3c07c37e@gmail.com>

On 1/4/23 02:29, Adam Thornton wrote:
>> On Jan 3, 2023, at 10:26 AM, Dan Cross <crossd at gmail.com> 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]} <dir> <section>...";
		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]} <syscall>";
		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]:  <http://www.alejandro-colomar.es/src/alx/alx/grepc.git/>


> 
> 
> 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: <CAKH6PiWkt_PzES-RQ4YtmmsUFrgzgabfUaSW5eQpce4uC3-Amw@mail.gmail.com>
 <3a891e61-a8b1-cfe4-95ab-c60e6ac6eb42@gmail.com>
 <202301031719.303HJq6A540885@darkstar.fourwinds.com>
Message-ID: <m28rih5d6l.fsf@thuvia.hamartun.priv.no>

Jon Steinhart <jon at fourwinds.com> 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: <CAEoi9W5Sg5O+1uzJ5rLLSNFCJgm5MivM31WEWk=vTUVnJ-hkuw@mail.gmail.com>

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: <m28rih5d6l.fsf@thuvia.hamartun.priv.no>
References: <CAKH6PiWkt_PzES-RQ4YtmmsUFrgzgabfUaSW5eQpce4uC3-Amw@mail.gmail.com>
 <3a891e61-a8b1-cfe4-95ab-c60e6ac6eb42@gmail.com>
 <202301031719.303HJq6A540885@darkstar.fourwinds.com>
 <m28rih5d6l.fsf@thuvia.hamartun.priv.no>
Message-ID: <CAKzdPgwbLOs+7yHSv5hUL-uPwKAsSyne4C3M8GT1mBka2qRdbg@mail.gmail.com>

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 <tuhs at tuhs.org>
wrote:

> Jon Steinhart <jon at fourwinds.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230106/f70dfa6e/attachment.htm>

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: <em36631459-635d-42f6-9ba2-9314535a4849@7621bee2.com>
References: <em36631459-635d-42f6-9ba2-9314535a4849@7621bee2.com>
Message-ID: <CAHrGxA1hr47VFLiw5=CmUGQDzw9V2j3f2nmvhUp-EKt7bKUSFQ@mail.gmail.com>

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 <ron at ronnatalie.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230108/280b5f7e/attachment-0001.htm>

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>
 <b689c244-3ea9-4fd6-bb45-a59d131071d6@app.fastmail.com>
 <7w5ydohe2c.fsf@junk.nocrew.org>
Message-ID: <9714D2FE-0737-490B-8470-323155D5B9DE@eschatologist.net>

On Jan 2, 2023, at 12:33 PM, Lars Brinkhoff <lars at nocrew.org> 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: <CAK0pxsH6bWTLVApE_vDhATmMgaF+nwc5D3pSz4srtwGS-8Ux_A@mail.gmail.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>
 <b689c244-3ea9-4fd6-bb45-a59d131071d6@app.fastmail.com>
 <CAK0pxsH6bWTLVApE_vDhATmMgaF+nwc5D3pSz4srtwGS-8Ux_A@mail.gmail.com>
Message-ID: <D6D82F2D-06D4-40D1-8417-8A673CB66CC2@eschatologist.net>

On Jan 3, 2023, at 8:53 AM, Marshall Conover <marzhall.o at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230110/052383f5/attachment.htm>

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>
 <b689c244-3ea9-4fd6-bb45-a59d131071d6@app.fastmail.com>
 <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 <lars at nocrew.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230111/c55e36d6/attachment.sig>

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: <CAEoi9W5rnakOGAOh0ChnGi7RvjYbBwM=pGP9BF_EmVMY2Bv7Sg@mail.gmail.com>

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: <CAEoi9W5rnakOGAOh0ChnGi7RvjYbBwM=pGP9BF_EmVMY2Bv7Sg@mail.gmail.com>
References: <CAEoi9W5rnakOGAOh0ChnGi7RvjYbBwM=pGP9BF_EmVMY2Bv7Sg@mail.gmail.com>
Message-ID: <CAFWeb9KGYBtFeAkJVye83egP=UfJosY31PRFdN3v0VHTx++LSw@mail.gmail.com>

https://vuls.cert.org/confluence/plugins/servlet/mobile?contentId=97124523#content/view/97124523



On Wed, 11 Jan 2023, 17:13 Dan Cross, <crossd at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230111/f4d9aae5/attachment.htm>

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: <CAFWeb9KGYBtFeAkJVye83egP=UfJosY31PRFdN3v0VHTx++LSw@mail.gmail.com>
References: <CAEoi9W5rnakOGAOh0ChnGi7RvjYbBwM=pGP9BF_EmVMY2Bv7Sg@mail.gmail.com>
 <CAFWeb9KGYBtFeAkJVye83egP=UfJosY31PRFdN3v0VHTx++LSw@mail.gmail.com>
Message-ID: <CAEoi9W7RsX3dzk3cPmi08ReA5FKgNGoZYHn2Qs+9gOAEr4ksJw@mail.gmail.com>

That's it. Thanks, Alec!

On Wed, Jan 11, 2023 at 12:28 PM Alec Muffett <alec.muffett at gmail.com> wrote:
>
> https://vuls.cert.org/confluence/plugins/servlet/mobile?contentId=97124523#content/view/97124523
>
>
>
> On Wed, 11 Jan 2023, 17:13 Dan Cross, <crossd at gmail.com> 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: <CAP6exYKNw-_x_XYa4Z3iPi8urhyJ+0YuLMLYm4DjgomjjnL2yA@mail.gmail.com>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230115/fa5ac274/attachment.htm>

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: <CAP6exYKNw-_x_XYa4Z3iPi8urhyJ+0YuLMLYm4DjgomjjnL2yA@mail.gmail.com>
References: <CAP6exYKNw-_x_XYa4Z3iPi8urhyJ+0YuLMLYm4DjgomjjnL2yA@mail.gmail.com>
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: <CAP6exYKNw-_x_XYa4Z3iPi8urhyJ+0YuLMLYm4DjgomjjnL2yA@mail.gmail.com>
References: <CAP6exYKNw-_x_XYa4Z3iPi8urhyJ+0YuLMLYm4DjgomjjnL2yA@mail.gmail.com>
Message-ID: <CAP6exY+-pH9zUSfKvq5JjfjvM6Z4w9Ob=nm4-LQ_-jcXQ1gzUw@mail.gmail.com>

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 <rminnich at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230115/17d6880a/attachment.htm>

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: <CAP6exY+-pH9zUSfKvq5JjfjvM6Z4w9Ob=nm4-LQ_-jcXQ1gzUw@mail.gmail.com>
References: <CAP6exYKNw-_x_XYa4Z3iPi8urhyJ+0YuLMLYm4DjgomjjnL2yA@mail.gmail.com>
 <CAP6exY+-pH9zUSfKvq5JjfjvM6Z4w9Ob=nm4-LQ_-jcXQ1gzUw@mail.gmail.com>
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 <awesome>.  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 <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 <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 <at the same time> 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 <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 <rminnich at gmail.com> wrote:
> 
> https://web.archive.org/web/20130521183231/http://jack.hoa.org/hoajaa/BurrMain.html <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 <rminnich at gmail.com <mailto:rminnich at gmail.com>> 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 <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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230115/1122b8ef/attachment.htm>

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: <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>

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 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: <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
Message-ID: <d54f6726-8a61-13c1-6a38-a4a06c69bada@riddermarkfarm.ca>

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: <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.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 <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 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>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
 <20230118161959.GE2964@mcvoy.com>
Message-ID: <emcedf209d-d22b-43f9-b062-4cf3a5ce022c@e41218a5.com>

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>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.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 <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 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: <emcedf209d-d22b-43f9-b062-4cf3a5ce022c@e41218a5.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
 <20230118161959.GE2964@mcvoy.com>
 <emcedf209d-d22b-43f9-b062-4cf3a5ce022c@e41218a5.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>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.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 <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 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>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.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 <lm at mcvoy.com> 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>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.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 <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 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>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
 <20230118161959.GE2964@mcvoy.com>
 <emcedf209d-d22b-43f9-b062-4cf3a5ce022c@e41218a5.com>
 <20230118163840.GF2964@mcvoy.com>
Message-ID: <CAC20D2MWiWUqjAF8ikiF3dYeF9sD7Tsa=YP5=GyGf2rrgj81pg@mail.gmail.com>

On Wed, Jan 18, 2023 at 11:39 AM Larry McVoy <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230118/b68da141/attachment.htm>

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: <CAC20D2MWiWUqjAF8ikiF3dYeF9sD7Tsa=YP5=GyGf2rrgj81pg@mail.gmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
 <20230118161959.GE2964@mcvoy.com>
 <emcedf209d-d22b-43f9-b062-4cf3a5ce022c@e41218a5.com>
 <20230118163840.GF2964@mcvoy.com>
 <CAC20D2MWiWUqjAF8ikiF3dYeF9sD7Tsa=YP5=GyGf2rrgj81pg@mail.gmail.com>
Message-ID: <zpdIicuX7AbN-y6hYho0eLOnHgzRs4iHa1UD6bxUyiTZhqZkg3Ha8TKWVASxWkDZitFw0JIopRVh7BRC2PzLFrF_Gjsb2yCi-uxJ3Yr3AtE=@protonmail.com>

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 <clemc at ccc.com> wrote:

> On Wed, Jan 18, 2023 at 11:39 AM Larry McVoy <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230118/598c47b2/attachment.htm>

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>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.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 <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 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: <zpdIicuX7AbN-y6hYho0eLOnHgzRs4iHa1UD6bxUyiTZhqZkg3Ha8TKWVASxWkDZitFw0JIopRVh7BRC2PzLFrF_Gjsb2yCi-uxJ3Yr3AtE=@protonmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
 <20230118161959.GE2964@mcvoy.com>
 <emcedf209d-d22b-43f9-b062-4cf3a5ce022c@e41218a5.com>
 <20230118163840.GF2964@mcvoy.com>
 <CAC20D2MWiWUqjAF8ikiF3dYeF9sD7Tsa=YP5=GyGf2rrgj81pg@mail.gmail.com>
 <zpdIicuX7AbN-y6hYho0eLOnHgzRs4iHa1UD6bxUyiTZhqZkg3Ha8TKWVASxWkDZitFw0JIopRVh7BRC2PzLFrF_Gjsb2yCi-uxJ3Yr3AtE=@protonmail.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 <clemc at ccc.com> 
> wrote:
>
>>
>>
>> On Wed, Jan 18, 2023 at 11:39 AM Larry McVoy <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230118/fced3d5a/attachment.htm>

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>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.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 <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 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: <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
Message-ID: <alpine.DEB.2.21.2301181356440.16371@sd-119843.dedibox.fr>

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.

<snip>

-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>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
 <20230118161959.GE2964@mcvoy.com>
 <2f00f9a6-c57d-8490-4066-931ec6e191cd@gmail.com>
 <20230118164242.GG2964@mcvoy.com>
Message-ID: <alpine.BSF.2.21.9999.2301190624070.20756@aneurin.horsfall.org>

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>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
 <20230118161959.GE2964@mcvoy.com>
 <emcedf209d-d22b-43f9-b062-4cf3a5ce022c@e41218a5.com>
 <20230118163840.GF2964@mcvoy.com>
 <CAC20D2MWiWUqjAF8ikiF3dYeF9sD7Tsa=YP5=GyGf2rrgj81pg@mail.gmail.com>
 <zpdIicuX7AbN-y6hYho0eLOnHgzRs4iHa1UD6bxUyiTZhqZkg3Ha8TKWVASxWkDZitFw0JIopRVh7BRC2PzLFrF_Gjsb2yCi-uxJ3Yr3AtE=@protonmail.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 <will.senn at gmail.com> 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 <clemc at ccc.com> <mailto:clemc at ccc.com> wrote:
>> 
>>> 
>>> 
>>> On Wed, Jan 18, 2023 at 11:39 AM Larry McVoy <lm at mcvoy.com <mailto:lm at mcvoy.com>> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230118/c38a549e/attachment.htm>

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: <zpdIicuX7AbN-y6hYho0eLOnHgzRs4iHa1UD6bxUyiTZhqZkg3Ha8TKWV
 ASxWkDZitFw0JIopRVh7BRC2PzLFrF_Gjsb2yCi-uxJ3Yr3AtE=@protonmail.com>
Message-ID: <uutu0nwqws.fsf@valis.com>

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***
                                <<<psi at valis.com>>>

tuhs-request at tuhs.org writes:
[...]
>  ----------------------------------------------------------------------
>
>  Message: 1
>  Date: Wed, 18 Jan 2023 17:08:00 +0000
>  From: segaloco <segaloco at protonmail.com>
>  Subject: [TUHS] Re: Maintenance mode on AIX
>  To: Clem Cole <clemc at ccc.com>
>  Cc: tuhs at tuhs.org
>  Message-ID: <zpdIicuX7AbN-y6hYho0eLOnHgzRs4iHa1UD6bxUyiTZhqZkg3Ha8TKWV
>  	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 <clemc at ccc.com> wrote:
>
>> On Wed, Jan 18, 2023 at 11:39 AM Larry McVoy <lm at mcvoy.com> 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>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
 <20230118161959.GE2964@mcvoy.com>
 <emcedf209d-d22b-43f9-b062-4cf3a5ce022c@e41218a5.com>
 <20230118163840.GF2964@mcvoy.com>
Message-ID: <Y8hX0jHBNrPVje4j@ancienthardware.org>

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: <Y8hX0jHBNrPVje4j@ancienthardware.org> (message from Arno
 Griffioen via TUHS on Wed, 18 Jan 2023 21:34:26 +0100)
Message-ID: <xon3587tvmh.fsf@anduin.eldar.org>

Arno Griffioen via TUHS <tuhs at tuhs.org> 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>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.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: <fd1uScBxgdLRY7dazzUxeM6vz1NsIGrj1X_5RBof5aRTBfFZ3xzTXMLi7_7QeXAj2kgd5EhSXLOytt8AFm2gYcyMayoVKAgCp3j7HZXRe8s=@protonmail.com>

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 <will.senn at gmail.com> 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: <fd1uScBxgdLRY7dazzUxeM6vz1NsIGrj1X_5RBof5aRTBfFZ3xzTXMLi7_7QeXAj2kgd5EhSXLOytt8AFm2gYcyMayoVKAgCp3j7HZXRe8s=@protonmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.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>
 <fd1uScBxgdLRY7dazzUxeM6vz1NsIGrj1X_5RBof5aRTBfFZ3xzTXMLi7_7QeXAj2kgd5EhSXLOytt8AFm2gYcyMayoVKAgCp3j7HZXRe8s=@protonmail.com>
Message-ID: <CAK7dMtCQaQo=c54wj3eMa2YDs9dW9rFKgoeWOKGRN4+fumDC_w@mail.gmail.com>

On Wed, Jan 18, 2023 at 2:10 PM segaloco via TUHS <tuhs at tuhs.org> 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 <will.senn at gmail.com> 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: <Y8hik/FKCXGPJyC0@mit.edu>

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: <Y8hik/FKCXGPJyC0@mit.edu>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <Y8hik/FKCXGPJyC0@mit.edu>
Message-ID: <CAK7dMtCb4AZhBRQt0MSaRFv-tWf7kSZUX-pgvz2WjEogxaKyRA@mail.gmail.com>

On Wed, Jan 18, 2023 at 2:20 PM Theodore Ts'o <tytso at mit.edu> 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>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
 <20230118161959.GE2964@mcvoy.com>
Message-ID: <CAP2nic1+a3NX9yqKXA3W2Li=uWpTYS-FOhtvRLNpUNHcPFV32Q@mail.gmail.com>

On Wed, Jan 18, 2023 at 9:20 AM Larry McVoy <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230118/1cfb81bb/attachment.htm>

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: <CAP2nic1+a3NX9yqKXA3W2Li=uWpTYS-FOhtvRLNpUNHcPFV32Q@mail.gmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
 <20230118161959.GE2964@mcvoy.com>
 <CAP2nic1+a3NX9yqKXA3W2Li=uWpTYS-FOhtvRLNpUNHcPFV32Q@mail.gmail.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 <lm at mcvoy.com> 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: <fd1uScBxgdLRY7dazzUxeM6vz1NsIGrj1X_5RBof5aRTBfFZ3xzTXMLi7_7QeXAj2kgd5EhSXLOytt8AFm2gYcyMayoVKAgCp3j7HZXRe8s=@protonmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.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>
 <fd1uScBxgdLRY7dazzUxeM6vz1NsIGrj1X_5RBof5aRTBfFZ3xzTXMLi7_7QeXAj2kgd5EhSXLOytt8AFm2gYcyMayoVKAgCp3j7HZXRe8s=@protonmail.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: <CAP2nic1+a3NX9yqKXA3W2Li=uWpTYS-FOhtvRLNpUNHcPFV32Q@mail.gmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
 <20230118161959.GE2964@mcvoy.com>
 <CAP2nic1+a3NX9yqKXA3W2Li=uWpTYS-FOhtvRLNpUNHcPFV32Q@mail.gmail.com>
Message-ID: <CALQ0xCA7AfiW6i4PRB9kDKkeMSuGAT1PqkAWbzRgL-JeZJrRiQ@mail.gmail.com>

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 <https://www.mindthegapdialogs.com/home>


On Wed, Jan 18, 2023 at 7:55 PM Adam Thornton <athornton at gmail.com> wrote:

>
>
> On Wed, Jan 18, 2023 at 9:20 AM Larry McVoy <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230118/2b52af11/attachment.htm>

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: <CALQ0xCA7AfiW6i4PRB9kDKkeMSuGAT1PqkAWbzRgL-JeZJrRiQ@mail.gmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
 <20230118161959.GE2964@mcvoy.com>
 <CAP2nic1+a3NX9yqKXA3W2Li=uWpTYS-FOhtvRLNpUNHcPFV32Q@mail.gmail.com>
 <CALQ0xCA7AfiW6i4PRB9kDKkeMSuGAT1PqkAWbzRgL-JeZJrRiQ@mail.gmail.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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230118/dda765e5/attachment.htm>

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: <Y8hik/FKCXGPJyC0@mit.edu>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <Y8hik/FKCXGPJyC0@mit.edu>
Message-ID: <CA+oaVqzp_tVwiReibDM5kseVoBo9sF4Yt-E5fVoFf2tdKbe9_w@mail.gmail.com>

On Wed, Jan 18, 2023 at 4:20 PM Theodore Ts'o <tytso at mit.edu> 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: <uutu0nwqws.fsf@valis.com>
References: <uutu0nwqws.fsf@valis.com>
Message-ID: <1FA76FBA-F729-4D91-8675-238BB6A9E699@canb.auug.org.au>

To their credit, ACM have make the video available on Youtube

	<https://youtu.be/dsMKJKTOte0?t=551>

Link includes intro to Ken for those wanting brevity.

> On 19 Jan 2023, at 07:04, Joseph J. Mankoski ***PSI*** <psi at valis.com> 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***
>                                <<<psi at valis.com>>>

--
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 <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 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>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
 <20230118161959.GE2964@mcvoy.com>
 <emcedf209d-d22b-43f9-b062-4cf3a5ce022c@e41218a5.com>
 <20230118163840.GF2964@mcvoy.com>
 <CAC20D2MWiWUqjAF8ikiF3dYeF9sD7Tsa=YP5=GyGf2rrgj81pg@mail.gmail.com>
 <zpdIicuX7AbN-y6hYho0eLOnHgzRs4iHa1UD6bxUyiTZhqZkg3Ha8TKWVASxWkDZitFw0JIopRVh7BRC2PzLFrF_Gjsb2yCi-uxJ3Yr3AtE=@protonmail.com>
 <1315c448-c8e8-1ae5-ef34-0f7ba3fbb8a7@gmail.com>
Message-ID: <CAMTenCGy=zr3HTQbUUEd-wCePvc8XyZc2=O-4yOEA2u6JOjA8Q@mail.gmail.com>

On Wed, 18 Jan 2023 at 18:22, Will Senn <will.senn at gmail.com> 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: <CAMTenCEVfD=HcK92VANbfx-irwJxOp4qVgmLwUbrNPbZhhAJyg@mail.gmail.com>

On Wed, 18 Jan 2023 at 15:56, Ralph Corderoy <ralph at inputplus.co.uk> 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>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
 <20230118161959.GE2964@mcvoy.com>
Message-ID: <CAMTenCGWeoGzJP53kjekjHPZEh=NvwQvBkA8_7c=_KAMhXRNmQ@mail.gmail.com>

On Wed, 18 Jan 2023 at 17:20, Larry McVoy <lm at mcvoy.com> 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>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
 <20230118161959.GE2964@mcvoy.com>
 <2f00f9a6-c57d-8490-4066-931ec6e191cd@gmail.com>
 <20230118164242.GG2964@mcvoy.com>
Message-ID: <CAMTenCE4Djq2auF0L5b=YvomyASOQtedVTHUspTt_H++=+VGoQ@mail.gmail.com>

On Wed, 18 Jan 2023 at 17:43, Larry McVoy <lm at mcvoy.com> 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 <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 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: <CAMTenCEVfD=HcK92VANbfx-irwJxOp4qVgmLwUbrNPbZhhAJyg@mail.gmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181446.30IEkSNt050612@ultimate.com>
 <20230118145554.3B27F20145@orac.inputplus.co.uk>
 <CAMTenCEVfD=HcK92VANbfx-irwJxOp4qVgmLwUbrNPbZhhAJyg@mail.gmail.com>
Message-ID: <CANCZdfqnx75mfqbUaHFywY_CwLiup8D1RRNRkNOtth6dCbJGJQ@mail.gmail.com>

On Thu, Jan 19, 2023 at 7:44 AM Liam Proven <lproven at gmail.com> wrote:

> On Wed, 18 Jan 2023 at 15:56, Ralph Corderoy <ralph at inputplus.co.uk>
> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230119/754d6fbc/attachment.htm>

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: <fd1uScBxgdLRY7dazzUxeM6vz1NsIGrj1X_5RBof5aRTBfFZ3xzTXMLi7_7QeXAj2kgd5EhSXLOytt8AFm2gYcyMayoVKAgCp3j7HZXRe8s=@protonmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.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>
 <fd1uScBxgdLRY7dazzUxeM6vz1NsIGrj1X_5RBof5aRTBfFZ3xzTXMLi7_7QeXAj2kgd5EhSXLOytt8AFm2gYcyMayoVKAgCp3j7HZXRe8s=@protonmail.com>
Message-ID: <CAMTenCFh1ddmk5WTj4uPMykJ_VSPQi3UYtaTd40bb-=UyCSTCw@mail.gmail.com>

On Wed, 18 Jan 2023 at 22:09, segaloco via TUHS <tuhs at tuhs.org> 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: <CAMTenCGWeoGzJP53kjekjHPZEh=NvwQvBkA8_7c=_KAMhXRNmQ@mail.gmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
 <20230118161959.GE2964@mcvoy.com>
 <CAMTenCGWeoGzJP53kjekjHPZEh=NvwQvBkA8_7c=_KAMhXRNmQ@mail.gmail.com>
Message-ID: <CAEoi9W4HzTrat+ENBDX0dGhQKv=pj_d2j9UJPiFF52Y-58=95A@mail.gmail.com>

On Thu, Jan 19, 2023 at 9:46 AM Liam Proven <lproven at gmail.com> wrote:
> On Wed, 18 Jan 2023 at 17:20, Larry McVoy <lm at mcvoy.com> 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: <CAMTenCE4Djq2auF0L5b=YvomyASOQtedVTHUspTt_H++=+VGoQ@mail.gmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
 <20230118161959.GE2964@mcvoy.com>
 <2f00f9a6-c57d-8490-4066-931ec6e191cd@gmail.com>
 <20230118164242.GG2964@mcvoy.com>
 <CAMTenCE4Djq2auF0L5b=YvomyASOQtedVTHUspTt_H++=+VGoQ@mail.gmail.com>
Message-ID: <202301191512.30JFCmmI017248@freefriends.org>

Liam Proven <lproven at gmail.com> 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: <CANCZdfqnx75mfqbUaHFywY_CwLiup8D1RRNRkNOtth6dCbJGJQ@mail.gmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181446.30IEkSNt050612@ultimate.com>
 <20230118145554.3B27F20145@orac.inputplus.co.uk>
 <CAMTenCEVfD=HcK92VANbfx-irwJxOp4qVgmLwUbrNPbZhhAJyg@mail.gmail.com>
 <CANCZdfqnx75mfqbUaHFywY_CwLiup8D1RRNRkNOtth6dCbJGJQ@mail.gmail.com>
Message-ID: <CAMTenCHf7NabHqZGUYL1qYx8E_Bx8J47gwddikc0PVMjK5B_bw@mail.gmail.com>

On Thu, 19 Jan 2023 at 16:03, Warner Losh <imp at bsdimp.com> 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: <CANCZdfqwEaKtfAyjE+2eQtEsKOjn0xtXgx-6KT_V0WgGC3YDGg@mail.gmail.com>

On Thu, Jan 19, 2023 at 8:04 AM Larry McVoy <lm at mcvoy.com> 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 <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230119/24f7c849/attachment.htm>

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: <CANCZdfqwEaKtfAyjE+2eQtEsKOjn0xtXgx-6KT_V0WgGC3YDGg@mail.gmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <202301190802.30J82KwQ025718@freefriends.org>
 <20230119150434.GA626@mcvoy.com>
 <CANCZdfqwEaKtfAyjE+2eQtEsKOjn0xtXgx-6KT_V0WgGC3YDGg@mail.gmail.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 <lm at mcvoy.com> 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: <CANCZdfqwEaKtfAyjE+2eQtEsKOjn0xtXgx-6KT_V0WgGC3YDGg@mail.gmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <202301190802.30J82KwQ025718@freefriends.org>
 <20230119150434.GA626@mcvoy.com>
 <CANCZdfqwEaKtfAyjE+2eQtEsKOjn0xtXgx-6KT_V0WgGC3YDGg@mail.gmail.com>
Message-ID: <CAEoi9W7EsKMSFSFciHsc9UKGtRnuJ-NgiBN8ZnvBLC=dO8H7FQ@mail.gmail.com>

On Thu, Jan 19, 2023 at 10:21 AM Warner Losh <imp at bsdimp.com> wrote:
> On Thu, Jan 19, 2023 at 8:04 AM Larry McVoy <lm at mcvoy.com> 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 <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 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: <CAEoi9W7EsKMSFSFciHsc9UKGtRnuJ-NgiBN8ZnvBLC=dO8H7FQ@mail.gmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <202301190802.30J82KwQ025718@freefriends.org>
 <20230119150434.GA626@mcvoy.com>
 <CANCZdfqwEaKtfAyjE+2eQtEsKOjn0xtXgx-6KT_V0WgGC3YDGg@mail.gmail.com>
 <CAEoi9W7EsKMSFSFciHsc9UKGtRnuJ-NgiBN8ZnvBLC=dO8H7FQ@mail.gmail.com>
Message-ID: <CANCZdfpiAi9k5Nkxc0p=OUSXZ8T02NLksgYGPoXn+40wdRr+HQ@mail.gmail.com>

On Thu, Jan 19, 2023 at 9:41 AM Dan Cross <crossd at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230119/8d33af8e/attachment.htm>

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: <CAEoi9W4HzTrat+ENBDX0dGhQKv=pj_d2j9UJPiFF52Y-58=95A@mail.gmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
 <20230118161959.GE2964@mcvoy.com>
 <CAMTenCGWeoGzJP53kjekjHPZEh=NvwQvBkA8_7c=_KAMhXRNmQ@mail.gmail.com>
 <CAEoi9W4HzTrat+ENBDX0dGhQKv=pj_d2j9UJPiFF52Y-58=95A@mail.gmail.com>
Message-ID: <0882D9CA-FAC8-4EC6-BA82-CE1D457423E5@iitbombay.org>

On Jan 19, 2023, at 7:05 AM, Dan Cross <crossd at gmail.com> 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: <CAEoi9W7EsKMSFSFciHsc9UKGtRnuJ-NgiBN8ZnvBLC=dO8H7FQ@mail.gmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <202301190802.30J82KwQ025718@freefriends.org>
 <20230119150434.GA626@mcvoy.com>
 <CANCZdfqwEaKtfAyjE+2eQtEsKOjn0xtXgx-6KT_V0WgGC3YDGg@mail.gmail.com>
 <CAEoi9W7EsKMSFSFciHsc9UKGtRnuJ-NgiBN8ZnvBLC=dO8H7FQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.21.2301191157040.522@sd-119843.dedibox.fr>

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: <alpine.DEB.2.21.2301191157040.522@sd-119843.dedibox.fr>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <202301190802.30J82KwQ025718@freefriends.org>
 <20230119150434.GA626@mcvoy.com>
 <CANCZdfqwEaKtfAyjE+2eQtEsKOjn0xtXgx-6KT_V0WgGC3YDGg@mail.gmail.com>
 <CAEoi9W7EsKMSFSFciHsc9UKGtRnuJ-NgiBN8ZnvBLC=dO8H7FQ@mail.gmail.com>
 <alpine.DEB.2.21.2301191157040.522@sd-119843.dedibox.fr>
Message-ID: <CAP2nic2h1cxi-iXDty8mZ+oXs89wGRDuHOmD=nxjWAPRvU1teA@mail.gmail.com>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230119/d51628f1/attachment.htm>

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 <lm at mcvoy.com>

    > 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: <CALQ0xCAw187PFq-RA0TqFkOKaZ9G5DUmnA=edB=DtFdUq8d5Hw@mail.gmail.com>

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 <https://www.mindthegapdialogs.com/home>


On Thu, Jan 19, 2023 at 12:50 PM Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Larry McVoy <lm at mcvoy.com>
>
>     > 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230119/8f445be6/attachment.htm>

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: <CALQ0xCAw187PFq-RA0TqFkOKaZ9G5DUmnA=edB=DtFdUq8d5Hw@mail.gmail.com>
References: <20230119175012.E7E7E18C074@mercury.lcs.mit.edu>
 <CALQ0xCAw187PFq-RA0TqFkOKaZ9G5DUmnA=edB=DtFdUq8d5Hw@mail.gmail.com>
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 <http://nygeek.net>
> mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home>
> 
> 
> On Thu, Jan 19, 2023 at 12:50 PM Noel Chiappa <jnc at mercury.lcs.mit.edu 
> <mailto:jnc at mercury.lcs.mit.edu>> wrote:
> 
>          > From: Larry McVoy <lm at mcvoy.com <mailto:lm at mcvoy.com>>
> 
>          > 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
>     <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 <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: <CAP2nic2h1cxi-iXDty8mZ+oXs89wGRDuHOmD=nxjWAPRvU1teA@mail.gmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <202301190802.30J82KwQ025718@freefriends.org>
 <20230119150434.GA626@mcvoy.com>
 <CANCZdfqwEaKtfAyjE+2eQtEsKOjn0xtXgx-6KT_V0WgGC3YDGg@mail.gmail.com>
 <CAEoi9W7EsKMSFSFciHsc9UKGtRnuJ-NgiBN8ZnvBLC=dO8H7FQ@mail.gmail.com>
 <alpine.DEB.2.21.2301191157040.522@sd-119843.dedibox.fr>
 <CAP2nic2h1cxi-iXDty8mZ+oXs89wGRDuHOmD=nxjWAPRvU1teA@mail.gmail.com>
Message-ID: <EUvFl6ry510mVXVmTd85LoFhASH_70g9sXylvgsVvKh6tNfxqSz2dVnyYmbjosspX9JuI65UdTVS9A09YaVVC21nRLl5YCMOuuDVxzU40Jk=@protonmail.com>

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 <athornton at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230119/402e16c2/attachment.htm>

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: <CAMTenCE4Djq2auF0L5b=YvomyASOQtedVTHUspTt_H++=+VGoQ@mail.gmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
 <20230118161959.GE2964@mcvoy.com>
 <2f00f9a6-c57d-8490-4066-931ec6e191cd@gmail.com>
 <20230118164242.GG2964@mcvoy.com>
 <CAMTenCE4Djq2auF0L5b=YvomyASOQtedVTHUspTt_H++=+VGoQ@mail.gmail.com>
Message-ID: <Y8mK4oI4kete+R5R@geeks.org>

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>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
 <20230118161959.GE2964@mcvoy.com>
 <2f00f9a6-c57d-8490-4066-931ec6e191cd@gmail.com>
 <20230118164242.GG2964@mcvoy.com>
 <CAMTenCE4Djq2auF0L5b=YvomyASOQtedVTHUspTt_H++=+VGoQ@mail.gmail.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 <lproven at gmail.com> 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: <EUvFl6ry510mVXVmTd85LoFhASH_70g9sXylvgsVvKh6tNfxqSz2dVnyYmbjosspX9JuI65UdTVS9A09YaVVC21nRLl5YCMOuuDVxzU40Jk=@protonmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <202301190802.30J82KwQ025718@freefriends.org>
 <20230119150434.GA626@mcvoy.com>
 <CANCZdfqwEaKtfAyjE+2eQtEsKOjn0xtXgx-6KT_V0WgGC3YDGg@mail.gmail.com>
 <CAEoi9W7EsKMSFSFciHsc9UKGtRnuJ-NgiBN8ZnvBLC=dO8H7FQ@mail.gmail.com>
 <alpine.DEB.2.21.2301191157040.522@sd-119843.dedibox.fr>
 <CAP2nic2h1cxi-iXDty8mZ+oXs89wGRDuHOmD=nxjWAPRvU1teA@mail.gmail.com>
 <EUvFl6ry510mVXVmTd85LoFhASH_70g9sXylvgsVvKh6tNfxqSz2dVnyYmbjosspX9JuI65UdTVS9A09YaVVC21nRLl5YCMOuuDVxzU40Jk=@protonmail.com>
Message-ID: <CAK7dMtC1FXB+-Z7V+Q4FoA+LgtfH1hvmG3SWvZeCKGODFDPDuQ@mail.gmail.com>

On Thu, Jan 19, 2023 at 11:23 AM segaloco via TUHS <tuhs at tuhs.org> 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 <athornton at gmail.com> 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>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
 <20230118161959.GE2964@mcvoy.com>
 <CAMTenCGWeoGzJP53kjekjHPZEh=NvwQvBkA8_7c=_KAMhXRNmQ@mail.gmail.com>
 <CAEoi9W4HzTrat+ENBDX0dGhQKv=pj_d2j9UJPiFF52Y-58=95A@mail.gmail.com>
 <0882D9CA-FAC8-4EC6-BA82-CE1D457423E5@iitbombay.org>
Message-ID: <c46cfb60-621f-5563-1531-d9365c044811@gmail.com>

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: <Y8mK4oI4kete+R5R@geeks.org>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
 <20230118161959.GE2964@mcvoy.com>
 <2f00f9a6-c57d-8490-4066-931ec6e191cd@gmail.com>
 <20230118164242.GG2964@mcvoy.com>
 <CAMTenCE4Djq2auF0L5b=YvomyASOQtedVTHUspTt_H++=+VGoQ@mail.gmail.com>
 <Y8mK4oI4kete+R5R@geeks.org>
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: <CAP2nic2h1cxi-iXDty8mZ+oXs89wGRDuHOmD=nxjWAPRvU1teA@mail.gmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <202301190802.30J82KwQ025718@freefriends.org>
 <20230119150434.GA626@mcvoy.com>
 <CANCZdfqwEaKtfAyjE+2eQtEsKOjn0xtXgx-6KT_V0WgGC3YDGg@mail.gmail.com>
 <CAEoi9W7EsKMSFSFciHsc9UKGtRnuJ-NgiBN8ZnvBLC=dO8H7FQ@mail.gmail.com>
 <alpine.DEB.2.21.2301191157040.522@sd-119843.dedibox.fr>
 <CAP2nic2h1cxi-iXDty8mZ+oXs89wGRDuHOmD=nxjWAPRvU1teA@mail.gmail.com>
Message-ID: <BDDE0D7F-E886-4E38-83AE-F7542976060A@iitbombay.org>

On Jan 19, 2023, at 9:19 AM, Adam Thornton <athornton at gmail.com> 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: <alpine.DEB.2.21.2301191508180.2622@sd-119843.dedibox.fr>

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: <c46cfb60-621f-5563-1531-d9365c044811@gmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
 <20230118161959.GE2964@mcvoy.com>
 <CAMTenCGWeoGzJP53kjekjHPZEh=NvwQvBkA8_7c=_KAMhXRNmQ@mail.gmail.com>
 <CAEoi9W4HzTrat+ENBDX0dGhQKv=pj_d2j9UJPiFF52Y-58=95A@mail.gmail.com>
 <0882D9CA-FAC8-4EC6-BA82-CE1D457423E5@iitbombay.org>
 <c46cfb60-621f-5563-1531-d9365c044811@gmail.com>
Message-ID: <exZxq0YN8pg0Co-IrM_d7K7MqTvcdrVA7a6FywQil59JZMEvNaO-4LLZtxgmKEebXdHgSSDWtxHOOSeOstGX27LJM9w8PJZXmXfuPY_v8BU=@protonmail.com>

> 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: <alpine.DEB.2.21.2301191508180.2622@sd-119843.dedibox.fr>
References: <alpine.DEB.2.21.2301191508180.2622@sd-119843.dedibox.fr>
Message-ID: <QbfyOLHPHFUOU39SUEhps-bCSqkj3eYLdVjmsjPahc1VeyT9CTiy-yV0M2O6crIhvX2ffBtQFWQ2i8eohIsVoqQ_eH_LuAc-BsMdq3Mia-Q=@protonmail.com>

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 <usotsuki at buric.co> 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: <QbfyOLHPHFUOU39SUEhps-bCSqkj3eYLdVjmsjPahc1VeyT9CTiy-yV0M2O6crIhvX2ffBtQFWQ2i8eohIsVoqQ_eH_LuAc-BsMdq3Mia-Q=@protonmail.com>
References: <alpine.DEB.2.21.2301191508180.2622@sd-119843.dedibox.fr>
 <QbfyOLHPHFUOU39SUEhps-bCSqkj3eYLdVjmsjPahc1VeyT9CTiy-yV0M2O6crIhvX2ffBtQFWQ2i8eohIsVoqQ_eH_LuAc-BsMdq3Mia-Q=@protonmail.com>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230119/e8d3f420/attachment-0001.sig>

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: <exZxq0YN8pg0Co-IrM_d7K7MqTvcdrVA7a6FywQil59JZMEvNaO-4LLZtxgmKEebXdHgSSDWtxHOOSeOstGX27LJM9w8PJZXmXfuPY_v8BU=@protonmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
 <20230118161959.GE2964@mcvoy.com>
 <CAMTenCGWeoGzJP53kjekjHPZEh=NvwQvBkA8_7c=_KAMhXRNmQ@mail.gmail.com>
 <CAEoi9W4HzTrat+ENBDX0dGhQKv=pj_d2j9UJPiFF52Y-58=95A@mail.gmail.com>
 <0882D9CA-FAC8-4EC6-BA82-CE1D457423E5@iitbombay.org>
 <c46cfb60-621f-5563-1531-d9365c044811@gmail.com>
 <exZxq0YN8pg0Co-IrM_d7K7MqTvcdrVA7a6FywQil59JZMEvNaO-4LLZtxgmKEebXdHgSSDWtxHOOSeOstGX27LJM9w8PJZXmXfuPY_v8BU=@protonmail.com>
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 <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 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: <CAK7dMtC1FXB+-Z7V+Q4FoA+LgtfH1hvmG3SWvZeCKGODFDPDuQ@mail.gmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <202301190802.30J82KwQ025718@freefriends.org>
 <20230119150434.GA626@mcvoy.com>
 <CANCZdfqwEaKtfAyjE+2eQtEsKOjn0xtXgx-6KT_V0WgGC3YDGg@mail.gmail.com>
 <CAEoi9W7EsKMSFSFciHsc9UKGtRnuJ-NgiBN8ZnvBLC=dO8H7FQ@mail.gmail.com>
 <alpine.DEB.2.21.2301191157040.522@sd-119843.dedibox.fr>
 <CAP2nic2h1cxi-iXDty8mZ+oXs89wGRDuHOmD=nxjWAPRvU1teA@mail.gmail.com>
 <EUvFl6ry510mVXVmTd85LoFhASH_70g9sXylvgsVvKh6tNfxqSz2dVnyYmbjosspX9JuI65UdTVS9A09YaVVC21nRLl5YCMOuuDVxzU40Jk=@protonmail.com>
 <CAK7dMtC1FXB+-Z7V+Q4FoA+LgtfH1hvmG3SWvZeCKGODFDPDuQ@mail.gmail.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>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
 <20230118161959.GE2964@mcvoy.com>
 <CAMTenCGWeoGzJP53kjekjHPZEh=NvwQvBkA8_7c=_KAMhXRNmQ@mail.gmail.com>
 <CAEoi9W4HzTrat+ENBDX0dGhQKv=pj_d2j9UJPiFF52Y-58=95A@mail.gmail.com>
 <0882D9CA-FAC8-4EC6-BA82-CE1D457423E5@iitbombay.org>
 <c46cfb60-621f-5563-1531-d9365c044811@gmail.com>
 <exZxq0YN8pg0Co-IrM_d7K7MqTvcdrVA7a6FywQil59JZMEvNaO-4LLZtxgmKEebXdHgSSDWtxHOOSeOstGX27LJM9w8PJZXmXfuPY_v8BU=@protonmail.com>
 <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 <rdm at cfcl.com> 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: <aca2130e-858e-4bc7-7e1c-94ed686cac86@gmail.com>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230119/3e1453bd/attachment.htm>

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: <CAKH6PiVB3mLE-Wi3yYigrbrvSDmrGhuKLxtujAEPh_D9ELmAQg@mail.gmail.com>

> 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: <aca2130e-858e-4bc7-7e1c-94ed686cac86@gmail.com>
References: <aca2130e-858e-4bc7-7e1c-94ed686cac86@gmail.com>
Message-ID: <6AB175F8-EFFF-4FBD-9BDA-99DEB84A4201@drewdiver.com>

An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230119/16f08c7f/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: favicon.ico
Type: image/vnd.microsoft.icon
Size: 198 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230119/16f08c7f/attachment.ico>

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: <BDDE0D7F-E886-4E38-83AE-F7542976060A@iitbombay.org>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <202301190802.30J82KwQ025718@freefriends.org>
 <20230119150434.GA626@mcvoy.com>
 <CANCZdfqwEaKtfAyjE+2eQtEsKOjn0xtXgx-6KT_V0WgGC3YDGg@mail.gmail.com>
 <CAEoi9W7EsKMSFSFciHsc9UKGtRnuJ-NgiBN8ZnvBLC=dO8H7FQ@mail.gmail.com>
 <alpine.DEB.2.21.2301191157040.522@sd-119843.dedibox.fr>
 <CAP2nic2h1cxi-iXDty8mZ+oXs89wGRDuHOmD=nxjWAPRvU1teA@mail.gmail.com>
 <BDDE0D7F-E886-4E38-83AE-F7542976060A@iitbombay.org>
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 <athornton at gmail.com> 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: <BDDE0D7F-E886-4E38-83AE-F7542976060A@iitbombay.org>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <202301190802.30J82KwQ025718@freefriends.org>
 <20230119150434.GA626@mcvoy.com>
 <CANCZdfqwEaKtfAyjE+2eQtEsKOjn0xtXgx-6KT_V0WgGC3YDGg@mail.gmail.com>
 <CAEoi9W7EsKMSFSFciHsc9UKGtRnuJ-NgiBN8ZnvBLC=dO8H7FQ@mail.gmail.com>
 <alpine.DEB.2.21.2301191157040.522@sd-119843.dedibox.fr>
 <CAP2nic2h1cxi-iXDty8mZ+oXs89wGRDuHOmD=nxjWAPRvU1teA@mail.gmail.com>
 <BDDE0D7F-E886-4E38-83AE-F7542976060A@iitbombay.org>
Message-ID: <CAFH29tqHxwfUKwbi3erdwB+ne1euzdVHVao1N3xy2sbr-nR6xw@mail.gmail.com>

> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230119/a527d190/attachment.htm>

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: <CAFH29tqHxwfUKwbi3erdwB+ne1euzdVHVao1N3xy2sbr-nR6xw@mail.gmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <202301190802.30J82KwQ025718@freefriends.org>
 <20230119150434.GA626@mcvoy.com>
 <CANCZdfqwEaKtfAyjE+2eQtEsKOjn0xtXgx-6KT_V0WgGC3YDGg@mail.gmail.com>
 <CAEoi9W7EsKMSFSFciHsc9UKGtRnuJ-NgiBN8ZnvBLC=dO8H7FQ@mail.gmail.com>
 <alpine.DEB.2.21.2301191157040.522@sd-119843.dedibox.fr>
 <CAP2nic2h1cxi-iXDty8mZ+oXs89wGRDuHOmD=nxjWAPRvU1teA@mail.gmail.com>
 <BDDE0D7F-E886-4E38-83AE-F7542976060A@iitbombay.org>
 <CAFH29tqHxwfUKwbi3erdwB+ne1euzdVHVao1N3xy2sbr-nR6xw@mail.gmail.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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230119/b9ae32c0/attachment.htm>

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: <CAFH29tqHxwfUKwbi3erdwB+ne1euzdVHVao1N3xy2sbr-nR6xw@mail.gmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <202301190802.30J82KwQ025718@freefriends.org>
 <20230119150434.GA626@mcvoy.com>
 <CANCZdfqwEaKtfAyjE+2eQtEsKOjn0xtXgx-6KT_V0WgGC3YDGg@mail.gmail.com>
 <CAEoi9W7EsKMSFSFciHsc9UKGtRnuJ-NgiBN8ZnvBLC=dO8H7FQ@mail.gmail.com>
 <alpine.DEB.2.21.2301191157040.522@sd-119843.dedibox.fr>
 <CAP2nic2h1cxi-iXDty8mZ+oXs89wGRDuHOmD=nxjWAPRvU1teA@mail.gmail.com>
 <BDDE0D7F-E886-4E38-83AE-F7542976060A@iitbombay.org>
 <CAFH29tqHxwfUKwbi3erdwB+ne1euzdVHVao1N3xy2sbr-nR6xw@mail.gmail.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>
 <CANCZdfqwEaKtfAyjE+2eQtEsKOjn0xtXgx-6KT_V0WgGC3YDGg@mail.gmail.com>
 <CAEoi9W7EsKMSFSFciHsc9UKGtRnuJ-NgiBN8ZnvBLC=dO8H7FQ@mail.gmail.com>
 <alpine.DEB.2.21.2301191157040.522@sd-119843.dedibox.fr>
 <CAP2nic2h1cxi-iXDty8mZ+oXs89wGRDuHOmD=nxjWAPRvU1teA@mail.gmail.com>
 <BDDE0D7F-E886-4E38-83AE-F7542976060A@iitbombay.org>
 <CAFH29tqHxwfUKwbi3erdwB+ne1euzdVHVao1N3xy2sbr-nR6xw@mail.gmail.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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230119/2eda3842/attachment.htm>

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: <CANCZdfpiAi9k5Nkxc0p=OUSXZ8T02NLksgYGPoXn+40wdRr+HQ@mail.gmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <202301190802.30J82KwQ025718@freefriends.org>
 <20230119150434.GA626@mcvoy.com>
 <CANCZdfqwEaKtfAyjE+2eQtEsKOjn0xtXgx-6KT_V0WgGC3YDGg@mail.gmail.com>
 <CAEoi9W7EsKMSFSFciHsc9UKGtRnuJ-NgiBN8ZnvBLC=dO8H7FQ@mail.gmail.com>
 <CANCZdfpiAi9k5Nkxc0p=OUSXZ8T02NLksgYGPoXn+40wdRr+HQ@mail.gmail.com>
Message-ID: <Y8nPPOhH1D4H0M0C@mit.edu>

On Thu, Jan 19, 2023 at 09:58:48AM -0700, Warner Losh wrote:
> On Thu, Jan 19, 2023 at 9:41 AM Dan Cross <crossd at gmail.com> 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: <CAFH29tqHxwfUKwbi3erdwB+ne1euzdVHVao1N3xy2sbr-nR6xw@mail.gmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301190802.30J82KwQ025718@freefriends.org>
 <20230119150434.GA626@mcvoy.com>
 <CANCZdfqwEaKtfAyjE+2eQtEsKOjn0xtXgx-6KT_V0WgGC3YDGg@mail.gmail.com>
 <CAEoi9W7EsKMSFSFciHsc9UKGtRnuJ-NgiBN8ZnvBLC=dO8H7FQ@mail.gmail.com>
 <alpine.DEB.2.21.2301191157040.522@sd-119843.dedibox.fr>
 <CAP2nic2h1cxi-iXDty8mZ+oXs89wGRDuHOmD=nxjWAPRvU1teA@mail.gmail.com>
 <BDDE0D7F-E886-4E38-83AE-F7542976060A@iitbombay.org>
 <CAFH29tqHxwfUKwbi3erdwB+ne1euzdVHVao1N3xy2sbr-nR6xw@mail.gmail.com>
Message-ID: <BlnrOTjFz5s4jkx1Kz_pEfrFn4n8nZ3lfdDp63SZkBbgRfxZoflPUe4l-5htwR7vUUQupPXT6mIKkRIrghuJOdKHNSX-Z1HklAXMpNY4IU4=@protonmail.com>

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 <rich.salz at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230119/d0419877/attachment.htm>

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: <BlnrOTjFz5s4jkx1Kz_pEfrFn4n8nZ3lfdDp63SZkBbgRfxZoflPUe4l-5htwR7vUUQupPXT6mIKkRIrghuJOdKHNSX-Z1HklAXMpNY4IU4=@protonmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301190802.30J82KwQ025718@freefriends.org>
 <20230119150434.GA626@mcvoy.com>
 <CANCZdfqwEaKtfAyjE+2eQtEsKOjn0xtXgx-6KT_V0WgGC3YDGg@mail.gmail.com>
 <CAEoi9W7EsKMSFSFciHsc9UKGtRnuJ-NgiBN8ZnvBLC=dO8H7FQ@mail.gmail.com>
 <alpine.DEB.2.21.2301191157040.522@sd-119843.dedibox.fr>
 <CAP2nic2h1cxi-iXDty8mZ+oXs89wGRDuHOmD=nxjWAPRvU1teA@mail.gmail.com>
 <BDDE0D7F-E886-4E38-83AE-F7542976060A@iitbombay.org>
 <CAFH29tqHxwfUKwbi3erdwB+ne1euzdVHVao1N3xy2sbr-nR6xw@mail.gmail.com>
 <BlnrOTjFz5s4jkx1Kz_pEfrFn4n8nZ3lfdDp63SZkBbgRfxZoflPUe4l-5htwR7vUUQupPXT6mIKkRIrghuJOdKHNSX-Z1HklAXMpNY4IU4=@protonmail.com>
Message-ID: <CAFH29tosMbPnRBsZY-i8vf493G_CaVYBt+nw1GJZu3QpSVnvEg@mail.gmail.com>

> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230119/d3826cc8/attachment-0001.htm>

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: <CAFH29tosMbPnRBsZY-i8vf493G_CaVYBt+nw1GJZu3QpSVnvEg@mail.gmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <CANCZdfqwEaKtfAyjE+2eQtEsKOjn0xtXgx-6KT_V0WgGC3YDGg@mail.gmail.com>
 <CAEoi9W7EsKMSFSFciHsc9UKGtRnuJ-NgiBN8ZnvBLC=dO8H7FQ@mail.gmail.com>
 <alpine.DEB.2.21.2301191157040.522@sd-119843.dedibox.fr>
 <CAP2nic2h1cxi-iXDty8mZ+oXs89wGRDuHOmD=nxjWAPRvU1teA@mail.gmail.com>
 <BDDE0D7F-E886-4E38-83AE-F7542976060A@iitbombay.org>
 <CAFH29tqHxwfUKwbi3erdwB+ne1euzdVHVao1N3xy2sbr-nR6xw@mail.gmail.com>
 <BlnrOTjFz5s4jkx1Kz_pEfrFn4n8nZ3lfdDp63SZkBbgRfxZoflPUe4l-5htwR7vUUQupPXT6mIKkRIrghuJOdKHNSX-Z1HklAXMpNY4IU4=@protonmail.com>
 <CAFH29tosMbPnRBsZY-i8vf493G_CaVYBt+nw1GJZu3QpSVnvEg@mail.gmail.com>
Message-ID: <mrGbwp0uMteoogOiTeSyPHRwazFFp0y2anCVye5yGJXow9yFONPqkmFopHC5yCB7IEZ2p1FtOpmdQIu_9dsoo_qCJU5UpGcysoBJ7R_x6Ks=@protonmail.com>

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 <rich.salz at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230119/6e4e5a5d/attachment.htm>

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: <mrGbwp0uMteoogOiTeSyPHRwazFFp0y2anCVye5yGJXow9yFONPqkmFopHC5yCB7IEZ2p1FtOpmdQIu_9dsoo_qCJU5UpGcysoBJ7R_x6Ks=@protonmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <CANCZdfqwEaKtfAyjE+2eQtEsKOjn0xtXgx-6KT_V0WgGC3YDGg@mail.gmail.com>
 <CAEoi9W7EsKMSFSFciHsc9UKGtRnuJ-NgiBN8ZnvBLC=dO8H7FQ@mail.gmail.com>
 <alpine.DEB.2.21.2301191157040.522@sd-119843.dedibox.fr>
 <CAP2nic2h1cxi-iXDty8mZ+oXs89wGRDuHOmD=nxjWAPRvU1teA@mail.gmail.com>
 <BDDE0D7F-E886-4E38-83AE-F7542976060A@iitbombay.org>
 <CAFH29tqHxwfUKwbi3erdwB+ne1euzdVHVao1N3xy2sbr-nR6xw@mail.gmail.com>
 <BlnrOTjFz5s4jkx1Kz_pEfrFn4n8nZ3lfdDp63SZkBbgRfxZoflPUe4l-5htwR7vUUQupPXT6mIKkRIrghuJOdKHNSX-Z1HklAXMpNY4IU4=@protonmail.com>
 <CAFH29tosMbPnRBsZY-i8vf493G_CaVYBt+nw1GJZu3QpSVnvEg@mail.gmail.com>
 <mrGbwp0uMteoogOiTeSyPHRwazFFp0y2anCVye5yGJXow9yFONPqkmFopHC5yCB7IEZ2p1FtOpmdQIu_9dsoo_qCJU5UpGcysoBJ7R_x6Ks=@protonmail.com>
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 
> <rich.salz at gmail.com> 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: <CANCZdfqwEaKtfAyjE+2eQtEsKOjn0xtXgx-6KT_V0WgGC3YDGg@mail.gmail.com>
 <CAEoi9W7EsKMSFSFciHsc9UKGtRnuJ-NgiBN8ZnvBLC=dO8H7FQ@mail.gmail.com>
 <alpine.DEB.2.21.2301191157040.522@sd-119843.dedibox.fr>
 <CAP2nic2h1cxi-iXDty8mZ+oXs89wGRDuHOmD=nxjWAPRvU1teA@mail.gmail.com>
 <BDDE0D7F-E886-4E38-83AE-F7542976060A@iitbombay.org>
 <CAFH29tqHxwfUKwbi3erdwB+ne1euzdVHVao1N3xy2sbr-nR6xw@mail.gmail.com>
 <BlnrOTjFz5s4jkx1Kz_pEfrFn4n8nZ3lfdDp63SZkBbgRfxZoflPUe4l-5htwR7vUUQupPXT6mIKkRIrghuJOdKHNSX-Z1HklAXMpNY4IU4=@protonmail.com>
 <CAFH29tosMbPnRBsZY-i8vf493G_CaVYBt+nw1GJZu3QpSVnvEg@mail.gmail.com>
 <mrGbwp0uMteoogOiTeSyPHRwazFFp0y2anCVye5yGJXow9yFONPqkmFopHC5yCB7IEZ2p1FtOpmdQIu_9dsoo_qCJU5UpGcysoBJ7R_x6Ks=@protonmail.com>
 <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
> ><rich.salz at gmail.com> 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: <Y8nPPOhH1D4H0M0C@mit.edu>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <202301190802.30J82KwQ025718@freefriends.org>
 <20230119150434.GA626@mcvoy.com>
 <CANCZdfqwEaKtfAyjE+2eQtEsKOjn0xtXgx-6KT_V0WgGC3YDGg@mail.gmail.com>
 <CAEoi9W7EsKMSFSFciHsc9UKGtRnuJ-NgiBN8ZnvBLC=dO8H7FQ@mail.gmail.com>
 <CANCZdfpiAi9k5Nkxc0p=OUSXZ8T02NLksgYGPoXn+40wdRr+HQ@mail.gmail.com>
 <Y8nPPOhH1D4H0M0C@mit.edu>
Message-ID: <CANCZdfr6=EBvN=+EtL0_L5oC=sixQ9e4zsuhgtVUPbgPm2+cNA@mail.gmail.com>

On Thu, Jan 19, 2023 at 4:16 PM Theodore Ts'o <tytso at mit.edu> 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 <crossd at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230119/dfeb7564/attachment.htm>

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: <CAFH29tosMbPnRBsZY-i8vf493G_CaVYBt+nw1GJZu3QpSVnvEg@mail.gmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301190802.30J82KwQ025718@freefriends.org>
 <20230119150434.GA626@mcvoy.com>
 <CANCZdfqwEaKtfAyjE+2eQtEsKOjn0xtXgx-6KT_V0WgGC3YDGg@mail.gmail.com>
 <CAEoi9W7EsKMSFSFciHsc9UKGtRnuJ-NgiBN8ZnvBLC=dO8H7FQ@mail.gmail.com>
 <alpine.DEB.2.21.2301191157040.522@sd-119843.dedibox.fr>
 <CAP2nic2h1cxi-iXDty8mZ+oXs89wGRDuHOmD=nxjWAPRvU1teA@mail.gmail.com>
 <BDDE0D7F-E886-4E38-83AE-F7542976060A@iitbombay.org>
 <CAFH29tqHxwfUKwbi3erdwB+ne1euzdVHVao1N3xy2sbr-nR6xw@mail.gmail.com>
 <BlnrOTjFz5s4jkx1Kz_pEfrFn4n8nZ3lfdDp63SZkBbgRfxZoflPUe4l-5htwR7vUUQupPXT6mIKkRIrghuJOdKHNSX-Z1HklAXMpNY4IU4=@protonmail.com>
 <CAFH29tosMbPnRBsZY-i8vf493G_CaVYBt+nw1GJZu3QpSVnvEg@mail.gmail.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>
 <CANCZdfqwEaKtfAyjE+2eQtEsKOjn0xtXgx-6KT_V0WgGC3YDGg@mail.gmail.com>
 <CAEoi9W7EsKMSFSFciHsc9UKGtRnuJ-NgiBN8ZnvBLC=dO8H7FQ@mail.gmail.com>
 <alpine.DEB.2.21.2301191157040.522@sd-119843.dedibox.fr>
 <CAP2nic2h1cxi-iXDty8mZ+oXs89wGRDuHOmD=nxjWAPRvU1teA@mail.gmail.com>
 <BDDE0D7F-E886-4E38-83AE-F7542976060A@iitbombay.org>
 <CAFH29tqHxwfUKwbi3erdwB+ne1euzdVHVao1N3xy2sbr-nR6xw@mail.gmail.com>
 <BlnrOTjFz5s4jkx1Kz_pEfrFn4n8nZ3lfdDp63SZkBbgRfxZoflPUe4l-5htwR7vUUQupPXT6mIKkRIrghuJOdKHNSX-Z1HklAXMpNY4IU4=@protonmail.com>
 <CAFH29tosMbPnRBsZY-i8vf493G_CaVYBt+nw1GJZu3QpSVnvEg@mail.gmail.com>
 <25545.58523.4766.431157@dobie-old.ylee.org>
Message-ID: <CAKr6gn0vBH1-ygTGJhhkhwCoADB+GLhx0UEfp2+G59uvK55zMA@mail.gmail.com>

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, <ylee at columbia.edu> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230120/4402bf64/attachment.htm>

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: <CAKr6gn0vBH1-ygTGJhhkhwCoADB+GLhx0UEfp2+G59uvK55zMA@mail.gmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301190802.30J82KwQ025718@freefriends.org>
 <20230119150434.GA626@mcvoy.com>
 <CANCZdfqwEaKtfAyjE+2eQtEsKOjn0xtXgx-6KT_V0WgGC3YDGg@mail.gmail.com>
 <CAEoi9W7EsKMSFSFciHsc9UKGtRnuJ-NgiBN8ZnvBLC=dO8H7FQ@mail.gmail.com>
 <alpine.DEB.2.21.2301191157040.522@sd-119843.dedibox.fr>
 <CAP2nic2h1cxi-iXDty8mZ+oXs89wGRDuHOmD=nxjWAPRvU1teA@mail.gmail.com>
 <BDDE0D7F-E886-4E38-83AE-F7542976060A@iitbombay.org>
 <CAFH29tqHxwfUKwbi3erdwB+ne1euzdVHVao1N3xy2sbr-nR6xw@mail.gmail.com>
 <BlnrOTjFz5s4jkx1Kz_pEfrFn4n8nZ3lfdDp63SZkBbgRfxZoflPUe4l-5htwR7vUUQupPXT6mIKkRIrghuJOdKHNSX-Z1HklAXMpNY4IU4=@protonmail.com>
 <CAFH29tosMbPnRBsZY-i8vf493G_CaVYBt+nw1GJZu3QpSVnvEg@mail.gmail.com>
 <25545.58523.4766.431157@dobie-old.ylee.org>
 <CAKr6gn0vBH1-ygTGJhhkhwCoADB+GLhx0UEfp2+G59uvK55zMA@mail.gmail.com>
Message-ID: <CAFH29to8UDdN150NpxZoi9pgYQMTM7pZH38sOsgdBp5f80o8XQ@mail.gmail.com>

:

> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230119/0c276e2b/attachment.htm>

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: <CAFH29to8UDdN150NpxZoi9pgYQMTM7pZH38sOsgdBp5f80o8XQ@mail.gmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301190802.30J82KwQ025718@freefriends.org>
 <20230119150434.GA626@mcvoy.com>
 <CANCZdfqwEaKtfAyjE+2eQtEsKOjn0xtXgx-6KT_V0WgGC3YDGg@mail.gmail.com>
 <CAEoi9W7EsKMSFSFciHsc9UKGtRnuJ-NgiBN8ZnvBLC=dO8H7FQ@mail.gmail.com>
 <alpine.DEB.2.21.2301191157040.522@sd-119843.dedibox.fr>
 <CAP2nic2h1cxi-iXDty8mZ+oXs89wGRDuHOmD=nxjWAPRvU1teA@mail.gmail.com>
 <BDDE0D7F-E886-4E38-83AE-F7542976060A@iitbombay.org>
 <CAFH29tqHxwfUKwbi3erdwB+ne1euzdVHVao1N3xy2sbr-nR6xw@mail.gmail.com>
 <BlnrOTjFz5s4jkx1Kz_pEfrFn4n8nZ3lfdDp63SZkBbgRfxZoflPUe4l-5htwR7vUUQupPXT6mIKkRIrghuJOdKHNSX-Z1HklAXMpNY4IU4=@protonmail.com>
 <CAFH29tosMbPnRBsZY-i8vf493G_CaVYBt+nw1GJZu3QpSVnvEg@mail.gmail.com>
 <25545.58523.4766.431157@dobie-old.ylee.org>
 <CAKr6gn0vBH1-ygTGJhhkhwCoADB+GLhx0UEfp2+G59uvK55zMA@mail.gmail.com>
 <CAFH29to8UDdN150NpxZoi9pgYQMTM7pZH38sOsgdBp5f80o8XQ@mail.gmail.com>
Message-ID: <CAKr6gn2yFknvVACoB1v+eO49Yt=E9aVYAzDwfOEax5+hZhJC0A@mail.gmail.com>

>> 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>
 <CANCZdfqwEaKtfAyjE+2eQtEsKOjn0xtXgx-6KT_V0WgGC3YDGg@mail.gmail.com>
 <CAEoi9W7EsKMSFSFciHsc9UKGtRnuJ-NgiBN8ZnvBLC=dO8H7FQ@mail.gmail.com>
 <alpine.DEB.2.21.2301191157040.522@sd-119843.dedibox.fr>
 <CAP2nic2h1cxi-iXDty8mZ+oXs89wGRDuHOmD=nxjWAPRvU1teA@mail.gmail.com>
 <BDDE0D7F-E886-4E38-83AE-F7542976060A@iitbombay.org>
 <7cc2b7c5-5e98-9299-4fa8-a477fbf4ff77@makerlisp.com>
Message-ID: <CAD2gp_QXbtVZHb=VN1QL7bJAVqRj4S5C-y5uMSQh704-4GH3wQ@mail.gmail.com>

On Thu, Jan 19, 2023 at 5:23 PM Luther Johnson <luther at makerlisp.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230119/7090ddb9/attachment.htm>

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: <CAD2gp_QXbtVZHb=VN1QL7bJAVqRj4S5C-y5uMSQh704-4GH3wQ@mail.gmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <202301190802.30J82KwQ025718@freefriends.org>
 <20230119150434.GA626@mcvoy.com>
 <CANCZdfqwEaKtfAyjE+2eQtEsKOjn0xtXgx-6KT_V0WgGC3YDGg@mail.gmail.com>
 <CAEoi9W7EsKMSFSFciHsc9UKGtRnuJ-NgiBN8ZnvBLC=dO8H7FQ@mail.gmail.com>
 <alpine.DEB.2.21.2301191157040.522@sd-119843.dedibox.fr>
 <CAP2nic2h1cxi-iXDty8mZ+oXs89wGRDuHOmD=nxjWAPRvU1teA@mail.gmail.com>
 <BDDE0D7F-E886-4E38-83AE-F7542976060A@iitbombay.org>
 <7cc2b7c5-5e98-9299-4fa8-a477fbf4ff77@makerlisp.com>
 <CAD2gp_QXbtVZHb=VN1QL7bJAVqRj4S5C-y5uMSQh704-4GH3wQ@mail.gmail.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 <luther at makerlisp.com 
> <mailto:luther at makerlisp.com>> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230119/a1dd3ee1/attachment.htm>

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: <CANCZdfr6=EBvN=+EtL0_L5oC=sixQ9e4zsuhgtVUPbgPm2+cNA@mail.gmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <202301190802.30J82KwQ025718@freefriends.org>
 <20230119150434.GA626@mcvoy.com>
 <CANCZdfqwEaKtfAyjE+2eQtEsKOjn0xtXgx-6KT_V0WgGC3YDGg@mail.gmail.com>
 <CAEoi9W7EsKMSFSFciHsc9UKGtRnuJ-NgiBN8ZnvBLC=dO8H7FQ@mail.gmail.com>
 <CANCZdfpiAi9k5Nkxc0p=OUSXZ8T02NLksgYGPoXn+40wdRr+HQ@mail.gmail.com>
 <Y8nPPOhH1D4H0M0C@mit.edu>
 <CANCZdfr6=EBvN=+EtL0_L5oC=sixQ9e4zsuhgtVUPbgPm2+cNA@mail.gmail.com>
Message-ID: <alpine.DEB.2.21.2301192015070.7329@sd-119843.dedibox.fr>

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: <CAFH29tqHxwfUKwbi3erdwB+ne1euzdVHVao1N3xy2sbr-nR6xw@mail.gmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <202301190802.30J82KwQ025718@freefriends.org>
 <20230119150434.GA626@mcvoy.com>
 <CANCZdfqwEaKtfAyjE+2eQtEsKOjn0xtXgx-6KT_V0WgGC3YDGg@mail.gmail.com>
 <CAEoi9W7EsKMSFSFciHsc9UKGtRnuJ-NgiBN8ZnvBLC=dO8H7FQ@mail.gmail.com>
 <alpine.DEB.2.21.2301191157040.522@sd-119843.dedibox.fr>
 <CAP2nic2h1cxi-iXDty8mZ+oXs89wGRDuHOmD=nxjWAPRvU1teA@mail.gmail.com>
 <BDDE0D7F-E886-4E38-83AE-F7542976060A@iitbombay.org>
 <CAFH29tqHxwfUKwbi3erdwB+ne1euzdVHVao1N3xy2sbr-nR6xw@mail.gmail.com>
Message-ID: <CAEoi9W6hkBxZUu3ugAwHBiC_Ufvtn_b2T+Mpu6AYCiPbT2=vfw@mail.gmail.com>

On Thu, Jan 19, 2023 at 5:30 PM Rich Salz <rich.salz at gmail.com> 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: <CALQ0xCAw187PFq-RA0TqFkOKaZ9G5DUmnA=edB=DtFdUq8d5Hw@mail.gmail.com>
References: <20230119175012.E7E7E18C074@mercury.lcs.mit.edu>
 <CALQ0xCAw187PFq-RA0TqFkOKaZ9G5DUmnA=edB=DtFdUq8d5Hw@mail.gmail.com>
Message-ID: <CAD2gp_REuBPpBKvAZMsQOYdx4UWGgUtWTE1sqy54FebthhfFhw@mail.gmail.com>

On Thu, Jan 19, 2023 at 1:01 PM Marc Donner <marc.donner at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230119/6c0c95f8/attachment.htm>

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: <Y8mK4oI4kete+R5R@geeks.org>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
 <20230118161959.GE2964@mcvoy.com>
 <2f00f9a6-c57d-8490-4066-931ec6e191cd@gmail.com>
 <20230118164242.GG2964@mcvoy.com>
 <CAMTenCE4Djq2auF0L5b=YvomyASOQtedVTHUspTt_H++=+VGoQ@mail.gmail.com>
 <Y8mK4oI4kete+R5R@geeks.org>
Message-ID: <CAMTenCFtS2sn9H-MwbatmA_WZGRd1mX8xQ6bOqf-FSMPq_V+ig@mail.gmail.com>

On Thu, 19 Jan 2023 at 19:25, Doug McIntyre <merlyn at geeks.org> 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: <exZxq0YN8pg0Co-IrM_d7K7MqTvcdrVA7a6FywQil59JZMEvNaO-4LLZtxgmKEebXdHgSSDWtxHOOSeOstGX27LJM9w8PJZXmXfuPY_v8BU=@protonmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
 <20230118161959.GE2964@mcvoy.com>
 <CAMTenCGWeoGzJP53kjekjHPZEh=NvwQvBkA8_7c=_KAMhXRNmQ@mail.gmail.com>
 <CAEoi9W4HzTrat+ENBDX0dGhQKv=pj_d2j9UJPiFF52Y-58=95A@mail.gmail.com>
 <0882D9CA-FAC8-4EC6-BA82-CE1D457423E5@iitbombay.org>
 <c46cfb60-621f-5563-1531-d9365c044811@gmail.com>
 <exZxq0YN8pg0Co-IrM_d7K7MqTvcdrVA7a6FywQil59JZMEvNaO-4LLZtxgmKEebXdHgSSDWtxHOOSeOstGX27LJM9w8PJZXmXfuPY_v8BU=@protonmail.com>
Message-ID: <CAMTenCG2aPtu-+hQqnEqm6bR0iN3vtrRWehBjriqzP5qYuC+jQ@mail.gmail.com>

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 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: <CAMTenCFtS2sn9H-MwbatmA_WZGRd1mX8xQ6bOqf-FSMPq_V+ig@mail.gmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
 <20230118161959.GE2964@mcvoy.com>
 <2f00f9a6-c57d-8490-4066-931ec6e191cd@gmail.com>
 <20230118164242.GG2964@mcvoy.com>
 <CAMTenCE4Djq2auF0L5b=YvomyASOQtedVTHUspTt_H++=+VGoQ@mail.gmail.com>
 <Y8mK4oI4kete+R5R@geeks.org>
 <CAMTenCFtS2sn9H-MwbatmA_WZGRd1mX8xQ6bOqf-FSMPq_V+ig@mail.gmail.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: <CAMTenCG2aPtu-+hQqnEqm6bR0iN3vtrRWehBjriqzP5qYuC+jQ@mail.gmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
 <20230118161959.GE2964@mcvoy.com>
 <CAMTenCGWeoGzJP53kjekjHPZEh=NvwQvBkA8_7c=_KAMhXRNmQ@mail.gmail.com>
 <CAEoi9W4HzTrat+ENBDX0dGhQKv=pj_d2j9UJPiFF52Y-58=95A@mail.gmail.com>
 <0882D9CA-FAC8-4EC6-BA82-CE1D457423E5@iitbombay.org>
 <c46cfb60-621f-5563-1531-d9365c044811@gmail.com>
 <exZxq0YN8pg0Co-IrM_d7K7MqTvcdrVA7a6FywQil59JZMEvNaO-4LLZtxgmKEebXdHgSSDWtxHOOSeOstGX27LJM9w8PJZXmXfuPY_v8BU=@protonmail.com>
 <CAMTenCG2aPtu-+hQqnEqm6bR0iN3vtrRWehBjriqzP5qYuC+jQ@mail.gmail.com>
Message-ID: <BWmxh3kYrOP2VXqfLWjXDELRW7mQDLM1CXUCLex-VyDQUZS6z3KEbxoVJGgVkD-bLCGlQPUr70KssJx0zxoUQs8XIDNFr-HPNo1arc2yLNI=@protonmail.com>

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 <lproven at gmail.com> 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>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
 <20230118161959.GE2964@mcvoy.com>
 <CAP2nic1+a3NX9yqKXA3W2Li=uWpTYS-FOhtvRLNpUNHcPFV32Q@mail.gmail.com>
 <CALQ0xCA7AfiW6i4PRB9kDKkeMSuGAT1PqkAWbzRgL-JeZJrRiQ@mail.gmail.com>
 <52e4bbd7-c5cd-4142-a609-d73ad8025201@app.fastmail.com>
Message-ID: <CALQ0xCCzuC6aaDnSxgXn-8kNs=jZE22_rLr4Lfjgic2O1pThNQ@mail.gmail.com>

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 <https://www.mindthegapdialogs.com/home>

On Wed, Jan 18, 2023 at 8:27 PM Joseph Holsten <joseph at josephholsten.com>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230120/e56b4bab/attachment.htm>

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: <BWmxh3kYrOP2VXqfLWjXDELRW7mQDLM1CXUCLex-VyDQUZS6z3KEbxoVJGgVkD-bLCGlQPUr70KssJx0zxoUQs8XIDNFr-HPNo1arc2yLNI=@protonmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
 <20230118161959.GE2964@mcvoy.com>
 <CAMTenCGWeoGzJP53kjekjHPZEh=NvwQvBkA8_7c=_KAMhXRNmQ@mail.gmail.com>
 <CAEoi9W4HzTrat+ENBDX0dGhQKv=pj_d2j9UJPiFF52Y-58=95A@mail.gmail.com>
 <0882D9CA-FAC8-4EC6-BA82-CE1D457423E5@iitbombay.org>
 <c46cfb60-621f-5563-1531-d9365c044811@gmail.com>
 <exZxq0YN8pg0Co-IrM_d7K7MqTvcdrVA7a6FywQil59JZMEvNaO-4LLZtxgmKEebXdHgSSDWtxHOOSeOstGX27LJM9w8PJZXmXfuPY_v8BU=@protonmail.com>
 <CAMTenCG2aPtu-+hQqnEqm6bR0iN3vtrRWehBjriqzP5qYuC+jQ@mail.gmail.com>
 <BWmxh3kYrOP2VXqfLWjXDELRW7mQDLM1CXUCLex-VyDQUZS6z3KEbxoVJGgVkD-bLCGlQPUr70KssJx0zxoUQs8XIDNFr-HPNo1arc2yLNI=@protonmail.com>
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 <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 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>
 <CAMTenCGWeoGzJP53kjekjHPZEh=NvwQvBkA8_7c=_KAMhXRNmQ@mail.gmail.com>
 <CAEoi9W4HzTrat+ENBDX0dGhQKv=pj_d2j9UJPiFF52Y-58=95A@mail.gmail.com>
 <0882D9CA-FAC8-4EC6-BA82-CE1D457423E5@iitbombay.org>
 <c46cfb60-621f-5563-1531-d9365c044811@gmail.com>
 <exZxq0YN8pg0Co-IrM_d7K7MqTvcdrVA7a6FywQil59JZMEvNaO-4LLZtxgmKEebXdHgSSDWtxHOOSeOstGX27LJM9w8PJZXmXfuPY_v8BU=@protonmail.com>
 <CAMTenCG2aPtu-+hQqnEqm6bR0iN3vtrRWehBjriqzP5qYuC+jQ@mail.gmail.com>
 <BWmxh3kYrOP2VXqfLWjXDELRW7mQDLM1CXUCLex-VyDQUZS6z3KEbxoVJGgVkD-bLCGlQPUr70KssJx0zxoUQs8XIDNFr-HPNo1arc2yLNI=@protonmail.com>
 <3C52C6D8-8742-4B72-8AE4-130C334EBA88@cfcl.com>
Message-ID: <b1MyadjG-fQhxwS5Bf-cCI9sO-C18JyRwem369st_TKDojMxmWB-gTEw65GqwaTC-35JBxDazGN6wfFpCv4xTPujKuy5CEbSyWeJ9X7qLhk=@protonmail.com>

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 <rdm at cfcl.com> 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: <CAD2gp_REuBPpBKvAZMsQOYdx4UWGgUtWTE1sqy54FebthhfFhw@mail.gmail.com>
References: <20230119175012.E7E7E18C074@mercury.lcs.mit.edu>
 <CALQ0xCAw187PFq-RA0TqFkOKaZ9G5DUmnA=edB=DtFdUq8d5Hw@mail.gmail.com>
 <CAD2gp_REuBPpBKvAZMsQOYdx4UWGgUtWTE1sqy54FebthhfFhw@mail.gmail.com>
Message-ID: <B78462CC-1C58-4A20-8753-351E1923495B@cfcl.com>

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: <B78462CC-1C58-4A20-8753-351E1923495B@cfcl.com>
References: <20230119175012.E7E7E18C074@mercury.lcs.mit.edu>
 <CALQ0xCAw187PFq-RA0TqFkOKaZ9G5DUmnA=edB=DtFdUq8d5Hw@mail.gmail.com>
 <CAD2gp_REuBPpBKvAZMsQOYdx4UWGgUtWTE1sqy54FebthhfFhw@mail.gmail.com>
 <B78462CC-1C58-4A20-8753-351E1923495B@cfcl.com>
Message-ID: <eme23c9bd0-8815-4147-8237-61be2f5000ba@e41218a5.com>

Nothing about the LISA OS or the subsequent MAC XL (extra large?  extra 
Lisas in inventory?) is remotely UNIXy.



------ Original Message ------
>From "Rich Morin" <rdm at cfcl.com>
To "Tautological Eunuch Horticultural Scythians" <tuhs at tuhs.org>
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>
 <b1MyadjG-fQhxwS5Bf-cCI9sO-C18JyRwem369st_TKDojMxmWB-gTEw65GqwaTC-35JBxDazGN6wfFpCv4xTPujKuy5CEbSyWeJ9X7qLhk=@protonmail.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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230120/edce8aca/attachment.sig>

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>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
 <20230118161959.GE2964@mcvoy.com>
 <CAP2nic1+a3NX9yqKXA3W2Li=uWpTYS-FOhtvRLNpUNHcPFV32Q@mail.gmail.com>
 <20230119010938.GH28004@mcvoy.com>
Message-ID: <Y8rfvugHf1Sm4R07@mit.edu>

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: <Y8rfvugHf1Sm4R07@mit.edu>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
 <20230118161959.GE2964@mcvoy.com>
 <CAP2nic1+a3NX9yqKXA3W2Li=uWpTYS-FOhtvRLNpUNHcPFV32Q@mail.gmail.com>
 <20230119010938.GH28004@mcvoy.com> <Y8rfvugHf1Sm4R07@mit.edu>
Message-ID: <CAEoi9W61kE7H-agrr1rdn+pAHfOrup3hOEnitNPddfdc6Pr+YA@mail.gmail.com>

On Fri, Jan 20, 2023 at 1:39 PM Theodore Ts'o <tytso at mit.edu> 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: <Y8rfvugHf1Sm4R07@mit.edu>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
 <20230118161959.GE2964@mcvoy.com>
 <CAP2nic1+a3NX9yqKXA3W2Li=uWpTYS-FOhtvRLNpUNHcPFV32Q@mail.gmail.com>
 <20230119010938.GH28004@mcvoy.com> <Y8rfvugHf1Sm4R07@mit.edu>
Message-ID: <CAK7dMtDrr8=MhRcpXCY8=DDJ7uDwvJhn4yvNOwE1vdUMyP2=Nw@mail.gmail.com>

On Fri, Jan 20, 2023 at 11:39 AM Theodore Ts'o <tytso at mit.edu> 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: <CAEoi9W61kE7H-agrr1rdn+pAHfOrup3hOEnitNPddfdc6Pr+YA@mail.gmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
 <20230118161959.GE2964@mcvoy.com>
 <CAP2nic1+a3NX9yqKXA3W2Li=uWpTYS-FOhtvRLNpUNHcPFV32Q@mail.gmail.com>
 <20230119010938.GH28004@mcvoy.com> <Y8rfvugHf1Sm4R07@mit.edu>
 <CAEoi9W61kE7H-agrr1rdn+pAHfOrup3hOEnitNPddfdc6Pr+YA@mail.gmail.com>
Message-ID: <CAD2gp_Su_DkFCPpcby11PiVAWCeQR-y-8Z1kRErFKWzB_F1R8w@mail.gmail.com>

On Fri, Jan 20, 2023 at 1:59 PM Dan Cross <crossd at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230120/487bdc30/attachment.htm>

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: <Y8rzzkcO7g8SomQ6@minnie.tuhs.org>

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: <CAD2gp_Su_DkFCPpcby11PiVAWCeQR-y-8Z1kRErFKWzB_F1R8w@mail.gmail.com>
References: <202301180943.30I9hrOw030485@freefriends.org>
 <202301181513.30IFDDUJ015224@freefriends.org>
 <20230118151446.GD2964@mcvoy.com>
 <nHupqk5Bnw9757lTM7uTq7y-jf9o5ADFmIJnFiJe-nlgn25L8d39B0ik1D_cOSEwRhbVwbalnbN33MEryHi0bLTORHfcONCCdYLjIQMkJg4=@protonmail.com>
 <20230118161959.GE2964@mcvoy.com>
 <CAP2nic1+a3NX9yqKXA3W2Li=uWpTYS-FOhtvRLNpUNHcPFV32Q@mail.gmail.com>
 <20230119010938.GH28004@mcvoy.com> <Y8rfvugHf1Sm4R07@mit.edu>
 <CAEoi9W61kE7H-agrr1rdn+pAHfOrup3hOEnitNPddfdc6Pr+YA@mail.gmail.com>
 <CAD2gp_Su_DkFCPpcby11PiVAWCeQR-y-8Z1kRErFKWzB_F1R8w@mail.gmail.com>
Message-ID: <CAEoi9W5gRO2uRbMTwJtoDVwVDbboDiOZbwQ4aDLTbjEMYNENEg@mail.gmail.com>

On Fri, Jan 20, 2023 at 2:48 PM John Cowan <cowan at ccil.org> wrote:
> On Fri, Jan 20, 2023 at 1:59 PM Dan Cross <crossd at gmail.com> 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: <CAP6exYK021bpG1epDf+6YBvXUKpN4PoCLYwK1CE1OJ16Pcskgg@mail.gmail.com>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230120/575bd1ac/attachment.htm>

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: <CAP6exYK021bpG1epDf+6YBvXUKpN4PoCLYwK1CE1OJ16Pcskgg@mail.gmail.com>
References: <CAP6exYK021bpG1epDf+6YBvXUKpN4PoCLYwK1CE1OJ16Pcskgg@mail.gmail.com>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230120/4197ef43/attachment.sig>

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: <CAP6exYK021bpG1epDf+6YBvXUKpN4PoCLYwK1CE1OJ16Pcskgg@mail.gmail.com>
References: <CAP6exYK021bpG1epDf+6YBvXUKpN4PoCLYwK1CE1OJ16Pcskgg@mail.gmail.com>
Message-ID: <CAKzdPgwBquCLbJ-aVhr7uLoAbLQ9+htGK9H47bD1uUVNAJXJyQ@mail.gmail.com>

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 <rminnich at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230121/8ed86eb4/attachment.htm>

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: <CAKzdPgwBquCLbJ-aVhr7uLoAbLQ9+htGK9H47bD1uUVNAJXJyQ@mail.gmail.com>
References: <CAP6exYK021bpG1epDf+6YBvXUKpN4PoCLYwK1CE1OJ16Pcskgg@mail.gmail.com>
 <CAKzdPgwBquCLbJ-aVhr7uLoAbLQ9+htGK9H47bD1uUVNAJXJyQ@mail.gmail.com>
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: <CAP6exYK021bpG1epDf+6YBvXUKpN4PoCLYwK1CE1OJ16Pcskgg@mail.gmail.com>
References: <CAP6exYK021bpG1epDf+6YBvXUKpN4PoCLYwK1CE1OJ16Pcskgg@mail.gmail.com>
Message-ID: <CAKH6PiWbjF4nOA2+rS5Fs7dDQyyt9UFG21YVwehgghRCAcb8NA@mail.gmail.com>

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 <rminnich at gmail.com> 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: <CAP6exYK021bpG1epDf+6YBvXUKpN4PoCLYwK1CE1OJ16Pcskgg@mail.gmail.com>
 <CAKzdPgwBquCLbJ-aVhr7uLoAbLQ9+htGK9H47bD1uUVNAJXJyQ@mail.gmail.com>
 <20230120231107.GB12196@mcvoy.com>
Message-ID: <CAKzdPgzxjQyZ6+9EGesaKM8zqqs5Ma8eQfpN95q6=PRY2dCYYA@mail.gmail.com>

Yes, but everyone adds the flag --alsologtostderr

-rob


On Sat, Jan 21, 2023 at 10:11 AM Larry McVoy <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230121/f837ced3/attachment.htm>

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: <CAKzdPgzxjQyZ6+9EGesaKM8zqqs5Ma8eQfpN95q6=PRY2dCYYA@mail.gmail.com>
References: <CAP6exYK021bpG1epDf+6YBvXUKpN4PoCLYwK1CE1OJ16Pcskgg@mail.gmail.com>
 <CAKzdPgwBquCLbJ-aVhr7uLoAbLQ9+htGK9H47bD1uUVNAJXJyQ@mail.gmail.com>
 <20230120231107.GB12196@mcvoy.com>
 <CAKzdPgzxjQyZ6+9EGesaKM8zqqs5Ma8eQfpN95q6=PRY2dCYYA@mail.gmail.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 <lm at mcvoy.com> 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: <CAP6exYK021bpG1epDf+6YBvXUKpN4PoCLYwK1CE1OJ16Pcskgg@mail.gmail.com>
References: <CAP6exYK021bpG1epDf+6YBvXUKpN4PoCLYwK1CE1OJ16Pcskgg@mail.gmail.com>
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: <CAP6exYK021bpG1epDf+6YBvXUKpN4PoCLYwK1CE1OJ16Pcskgg@mail.gmail.com>
References: <CAP6exYK021bpG1epDf+6YBvXUKpN4PoCLYwK1CE1OJ16Pcskgg@mail.gmail.com>
Message-ID: <CAC20D2ODxrRGZ6sYyMedNdR8wphvkVW3H4j_Dnce-axELdX_Mg@mail.gmail.com>

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 <file for input."

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

On Fri, Jan 20, 2023 at 5:46 PM ron minnich <rminnich at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230121/5d08ee1f/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: iolib.pdf
Type: application/pdf
Size: 46203 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230121/5d08ee1f/attachment-0001.pdf>

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: <CAC20D2ODxrRGZ6sYyMedNdR8wphvkVW3H4j_Dnce-axELdX_Mg@mail.gmail.com>
References: <CAP6exYK021bpG1epDf+6YBvXUKpN4PoCLYwK1CE1OJ16Pcskgg@mail.gmail.com>
 <CAC20D2ODxrRGZ6sYyMedNdR8wphvkVW3H4j_Dnce-axELdX_Mg@mail.gmail.com>
Message-ID: <CANCZdfpjrJUDPv2g7-10SrdkgjiacAvp95PVvJ=Ob2h8m8R=FQ@mail.gmail.com>

On Sat, Jan 21, 2023, 8:45 AM Clem Cole <clemc at ccc.com> 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 <file for input."
>
> 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 <rminnich at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230121/8ec6ae1b/attachment.htm>

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: <CANCZdfpjrJUDPv2g7-10SrdkgjiacAvp95PVvJ=Ob2h8m8R=FQ@mail.gmail.com>
References: <CAP6exYK021bpG1epDf+6YBvXUKpN4PoCLYwK1CE1OJ16Pcskgg@mail.gmail.com>
 <CAC20D2ODxrRGZ6sYyMedNdR8wphvkVW3H4j_Dnce-axELdX_Mg@mail.gmail.com>
 <CANCZdfpjrJUDPv2g7-10SrdkgjiacAvp95PVvJ=Ob2h8m8R=FQ@mail.gmail.com>
Message-ID: <CANCZdfr4zkmFKgqBZKrOL9z5FbFsWSjHpU3vYu-2T3Y+xNat2g@mail.gmail.com>

On Sat, Jan 21, 2023, 10:34 AM Warner Losh <imp at bsdimp.com> wrote:

>
>
> On Sat, Jan 21, 2023, 8:45 AM Clem Cole <clemc at ccc.com> 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 <file for input."
>>
>> 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 <rminnich at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230121/de722aa1/attachment.htm>

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>
 <CANCZdfqwEaKtfAyjE+2eQtEsKOjn0xtXgx-6KT_V0WgGC3YDGg@mail.gmail.com>
 <CAEoi9W7EsKMSFSFciHsc9UKGtRnuJ-NgiBN8ZnvBLC=dO8H7FQ@mail.gmail.com>
 <alpine.DEB.2.21.2301191157040.522@sd-119843.dedibox.fr>
 <CAP2nic2h1cxi-iXDty8mZ+oXs89wGRDuHOmD=nxjWAPRvU1teA@mail.gmail.com>
 <BDDE0D7F-E886-4E38-83AE-F7542976060A@iitbombay.org>
 <7cc2b7c5-5e98-9299-4fa8-a477fbf4ff77@makerlisp.com>
 <CAD2gp_QXbtVZHb=VN1QL7bJAVqRj4S5C-y5uMSQh704-4GH3wQ@mail.gmail.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 <luther at makerlisp.com> 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 <luther at makerlisp.com 
> > <mailto:luther at makerlisp.com>> 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: <CANCZdfr4zkmFKgqBZKrOL9z5FbFsWSjHpU3vYu-2T3Y+xNat2g@mail.gmail.com>
References: <CAP6exYK021bpG1epDf+6YBvXUKpN4PoCLYwK1CE1OJ16Pcskgg@mail.gmail.com>
 <CAC20D2ODxrRGZ6sYyMedNdR8wphvkVW3H4j_Dnce-axELdX_Mg@mail.gmail.com>
 <CANCZdfpjrJUDPv2g7-10SrdkgjiacAvp95PVvJ=Ob2h8m8R=FQ@mail.gmail.com>
 <CANCZdfr4zkmFKgqBZKrOL9z5FbFsWSjHpU3vYu-2T3Y+xNat2g@mail.gmail.com>
Message-ID: <CAC20D2MUWZjQw1O=OGgtf_g8VYoE4ZN8cPyH8FFXaToPuYuZUQ@mail.gmail.com>

On Sat, Jan 21, 2023 at 12:50 PM Warner Losh <imp at bsdimp.com> 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 <rminnich at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230121/a49085e1/attachment.htm>

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: <CANCZdfpjrJUDPv2g7-10SrdkgjiacAvp95PVvJ=Ob2h8m8R=FQ@mail.gmail.com>
References: <CAP6exYK021bpG1epDf+6YBvXUKpN4PoCLYwK1CE1OJ16Pcskgg@mail.gmail.com>
 <CAC20D2ODxrRGZ6sYyMedNdR8wphvkVW3H4j_Dnce-axELdX_Mg@mail.gmail.com>
 <CANCZdfpjrJUDPv2g7-10SrdkgjiacAvp95PVvJ=Ob2h8m8R=FQ@mail.gmail.com>
Message-ID: <CAC20D2OfyiNuxtvQGb9wN7a8X4ay_c3aHWBwEdP1MmyVzYi5jA@mail.gmail.com>

On Sat, Jan 21, 2023 at 12:34 PM Warner Losh <imp at bsdimp.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230121/700372f6/attachment.htm>

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: <CAC20D2MUWZjQw1O=OGgtf_g8VYoE4ZN8cPyH8FFXaToPuYuZUQ@mail.gmail.com>
References: <CAP6exYK021bpG1epDf+6YBvXUKpN4PoCLYwK1CE1OJ16Pcskgg@mail.gmail.com>
 <CAC20D2ODxrRGZ6sYyMedNdR8wphvkVW3H4j_Dnce-axELdX_Mg@mail.gmail.com>
 <CANCZdfpjrJUDPv2g7-10SrdkgjiacAvp95PVvJ=Ob2h8m8R=FQ@mail.gmail.com>
 <CANCZdfr4zkmFKgqBZKrOL9z5FbFsWSjHpU3vYu-2T3Y+xNat2g@mail.gmail.com>
 <CAC20D2MUWZjQw1O=OGgtf_g8VYoE4ZN8cPyH8FFXaToPuYuZUQ@mail.gmail.com>
Message-ID: <CANCZdfp2SK+gHNgoybVd3asYfLkNiwt539zdNrgwPSKzK=j38Q@mail.gmail.com>

On Sat, Jan 21, 2023, 11:26 AM Clem Cole <clemc at ccc.com> wrote:

>
>
> On Sat, Jan 21, 2023 at 12:50 PM Warner Losh <imp at bsdimp.com> 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 <rminnich at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230121/0c1bc424/attachment.htm>

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>
 <CANCZdfqwEaKtfAyjE+2eQtEsKOjn0xtXgx-6KT_V0WgGC3YDGg@mail.gmail.com>
 <CAEoi9W7EsKMSFSFciHsc9UKGtRnuJ-NgiBN8ZnvBLC=dO8H7FQ@mail.gmail.com>
 <alpine.DEB.2.21.2301191157040.522@sd-119843.dedibox.fr>
 <CAP2nic2h1cxi-iXDty8mZ+oXs89wGRDuHOmD=nxjWAPRvU1teA@mail.gmail.com>
 <BDDE0D7F-E886-4E38-83AE-F7542976060A@iitbombay.org>
 <7cc2b7c5-5e98-9299-4fa8-a477fbf4ff77@makerlisp.com>
 <CAD2gp_QXbtVZHb=VN1QL7bJAVqRj4S5C-y5uMSQh704-4GH3wQ@mail.gmail.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 <luther at makerlisp.com> 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 <luther at makerlisp.com
>>> <mailto:luther at makerlisp.com>> 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: <CAKzdPgyEysMDym0HnqAiG_2--YrMHg671B9CQq6=KuQZQC2u_w@mail.gmail.com>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230122/c4d570d6/attachment.htm>

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: <CAC20D2OfyiNuxtvQGb9wN7a8X4ay_c3aHWBwEdP1MmyVzYi5jA@mail.gmail.com>
References: <CAP6exYK021bpG1epDf+6YBvXUKpN4PoCLYwK1CE1OJ16Pcskgg@mail.gmail.com>
 <CAC20D2ODxrRGZ6sYyMedNdR8wphvkVW3H4j_Dnce-axELdX_Mg@mail.gmail.com>
 <CANCZdfpjrJUDPv2g7-10SrdkgjiacAvp95PVvJ=Ob2h8m8R=FQ@mail.gmail.com>
 <CAC20D2OfyiNuxtvQGb9wN7a8X4ay_c3aHWBwEdP1MmyVzYi5jA@mail.gmail.com>
Message-ID: <ADBDDDAA-1830-46EB-B21C-280EF2A4BEFE@xs4all.nl>



> On 21 Jan 2023, at 19:27, Clem Cole <clemc at ccc.com> wrote:
> 
> 
> 
> On Sat, Jan 21, 2023 at 12:34 PM Warner Losh <imp at bsdimp.com <mailto:imp at bsdimp.com>> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230122/89099f85/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 267 bytes
Desc: Message signed with OpenPGP
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230122/89099f85/attachment.sig>

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: <CANCZdfp2SK+gHNgoybVd3asYfLkNiwt539zdNrgwPSKzK=j38Q@mail.gmail.com>
References: <CAP6exYK021bpG1epDf+6YBvXUKpN4PoCLYwK1CE1OJ16Pcskgg@mail.gmail.com>
 <CAC20D2ODxrRGZ6sYyMedNdR8wphvkVW3H4j_Dnce-axELdX_Mg@mail.gmail.com>
 <CANCZdfpjrJUDPv2g7-10SrdkgjiacAvp95PVvJ=Ob2h8m8R=FQ@mail.gmail.com>
 <CANCZdfr4zkmFKgqBZKrOL9z5FbFsWSjHpU3vYu-2T3Y+xNat2g@mail.gmail.com>
 <CAC20D2MUWZjQw1O=OGgtf_g8VYoE4ZN8cPyH8FFXaToPuYuZUQ@mail.gmail.com>
 <CANCZdfp2SK+gHNgoybVd3asYfLkNiwt539zdNrgwPSKzK=j38Q@mail.gmail.com>
Message-ID: <Y80YbOCslm517LNc@largo.jsg.id.au>

On Sat, Jan 21, 2023 at 11:37:42AM -0700, Warner Losh wrote:
> On Sat, Jan 21, 2023, 11:26 AM Clem Cole <clemc at ccc.com> 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: <CAKzdPgyEysMDym0HnqAiG_2--YrMHg671B9CQq6=KuQZQC2u_w@mail.gmail.com>
References: <CAKzdPgyEysMDym0HnqAiG_2--YrMHg671B9CQq6=KuQZQC2u_w@mail.gmail.com>
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 <robpike at gmail.com> 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: <CANCZdfp2SK+gHNgoybVd3asYfLkNiwt539zdNrgwPSKzK=j38Q@mail.gmail.com>
References: <CAP6exYK021bpG1epDf+6YBvXUKpN4PoCLYwK1CE1OJ16Pcskgg@mail.gmail.com>
 <CAC20D2ODxrRGZ6sYyMedNdR8wphvkVW3H4j_Dnce-axELdX_Mg@mail.gmail.com>
 <CANCZdfpjrJUDPv2g7-10SrdkgjiacAvp95PVvJ=Ob2h8m8R=FQ@mail.gmail.com>
 <CANCZdfr4zkmFKgqBZKrOL9z5FbFsWSjHpU3vYu-2T3Y+xNat2g@mail.gmail.com>
 <CAC20D2MUWZjQw1O=OGgtf_g8VYoE4ZN8cPyH8FFXaToPuYuZUQ@mail.gmail.com>
 <CANCZdfp2SK+gHNgoybVd3asYfLkNiwt539zdNrgwPSKzK=j38Q@mail.gmail.com>
Message-ID: <CANCZdfrnO-a7bUGRVHtGLdkGFYeaNCyTzwdR1tO+keKkmKf9cA@mail.gmail.com>

On Sat, Jan 21, 2023 at 11:37 AM Warner Losh <imp at bsdimp.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230122/9432f3f0/attachment-0001.htm>

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: <CANCZdfrnO-a7bUGRVHtGLdkGFYeaNCyTzwdR1tO+keKkmKf9cA@mail.gmail.com>
References: <CAP6exYK021bpG1epDf+6YBvXUKpN4PoCLYwK1CE1OJ16Pcskgg@mail.gmail.com>
 <CAC20D2ODxrRGZ6sYyMedNdR8wphvkVW3H4j_Dnce-axELdX_Mg@mail.gmail.com>
 <CANCZdfpjrJUDPv2g7-10SrdkgjiacAvp95PVvJ=Ob2h8m8R=FQ@mail.gmail.com>
 <CANCZdfr4zkmFKgqBZKrOL9z5FbFsWSjHpU3vYu-2T3Y+xNat2g@mail.gmail.com>
 <CAC20D2MUWZjQw1O=OGgtf_g8VYoE4ZN8cPyH8FFXaToPuYuZUQ@mail.gmail.com>
 <CANCZdfp2SK+gHNgoybVd3asYfLkNiwt539zdNrgwPSKzK=j38Q@mail.gmail.com>
 <CANCZdfrnO-a7bUGRVHtGLdkGFYeaNCyTzwdR1tO+keKkmKf9cA@mail.gmail.com>
Message-ID: <CAP6exY+e7+YBsFG3PuoNV6Wm6RkxW=8pX5czKudki1Vy0EEDcw@mail.gmail.com>

Thanks very much for this interesting archaeological dig.

On Sun, Jan 22, 2023, 4:23 PM Warner Losh <imp at bsdimp.com> wrote:

>
>
> On Sat, Jan 21, 2023 at 11:37 AM Warner Losh <imp at bsdimp.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230122/f54199fd/attachment.htm>

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: <CAP6exY+4Qzc_YEkffvaor_Uo0PFg4AUxQRRygdM5Ki4qTKzrvQ@mail.gmail.com>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230122/95fb4f87/attachment.htm>

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: <CAP6exY+4Qzc_YEkffvaor_Uo0PFg4AUxQRRygdM5Ki4qTKzrvQ@mail.gmail.com>
References: <CAP6exY+4Qzc_YEkffvaor_Uo0PFg4AUxQRRygdM5Ki4qTKzrvQ@mail.gmail.com>
Message-ID: <CAP6exY+PnUVK1ZrNB2=8XzfTY2vyz_BWQ+ZfT--ohwtPX4NO8A@mail.gmail.com>

dc on linux still behaves properly.

On Sun, Jan 22, 2023 at 3:39 PM ron minnich <rminnich at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230122/e5ee511f/attachment.htm>

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: <CAP6exY+4Qzc_YEkffvaor_Uo0PFg4AUxQRRygdM5Ki4qTKzrvQ@mail.gmail.com>
References: <CAP6exY+4Qzc_YEkffvaor_Uo0PFg4AUxQRRygdM5Ki4qTKzrvQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.21.2301221848560.29332@sd-119843.dedibox.fr>

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: <CAP6exY+PnUVK1ZrNB2=8XzfTY2vyz_BWQ+ZfT--ohwtPX4NO8A@mail.gmail.com>
References: <CAP6exY+4Qzc_YEkffvaor_Uo0PFg4AUxQRRygdM5Ki4qTKzrvQ@mail.gmail.com>
 <CAP6exY+PnUVK1ZrNB2=8XzfTY2vyz_BWQ+ZfT--ohwtPX4NO8A@mail.gmail.com>
Message-ID: <CANCZdfp94y9-H8J+3S-NWUsfbDp28vKRuCBHnv4FseWchhSoEQ@mail.gmail.com>

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 <rminnich at gmail.com> wrote:

> dc on linux still behaves properly.
>
> On Sun, Jan 22, 2023 at 3:39 PM ron minnich <rminnich at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230122/c3e53fc6/attachment.htm>

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: <alpine.DEB.2.21.2301221848560.29332@sd-119843.dedibox.fr>
References: <CAP6exY+4Qzc_YEkffvaor_Uo0PFg4AUxQRRygdM5Ki4qTKzrvQ@mail.gmail.com>
 <alpine.DEB.2.21.2301221848560.29332@sd-119843.dedibox.fr>
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: <CAP6exY+4Qzc_YEkffvaor_Uo0PFg4AUxQRRygdM5Ki4qTKzrvQ@mail.gmail.com>
 <alpine.DEB.2.21.2301221848560.29332@sd-119843.dedibox.fr>
 <600b537d-af67-43f6-b27b-f4bd26a48c33@app.fastmail.com>
Message-ID: <alpine.DEB.2.21.2301221904120.29435@sd-119843.dedibox.fr>

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: <CAP6exY+4Qzc_YEkffvaor_Uo0PFg4AUxQRRygdM5Ki4qTKzrvQ@mail.gmail.com>
References: <CAP6exY+4Qzc_YEkffvaor_Uo0PFg4AUxQRRygdM5Ki4qTKzrvQ@mail.gmail.com>
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 <rminnich at gmail.com> 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: <CAP6exY+4Qzc_YEkffvaor_Uo0PFg4AUxQRRygdM5Ki4qTKzrvQ@mail.gmail.com>
 <28A20AFF-8679-4D4F-A8CD-68965351E397@iitbombay.org>
Message-ID: <CAP6exYLpT-bnSb-=HD9hHSpZ5w9kkzCfsavARfzfw-v9t5bp3g@mail.gmail.com>

How do you write a dc that doesn't compile?

The mind reels.

On Sun, Jan 22, 2023, 7:16 PM Bakul Shah <bakul at iitbombay.org> 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 <rminnich at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230122/d80b527d/attachment.htm>

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: <CAP6exYLpT-bnSb-=HD9hHSpZ5w9kkzCfsavARfzfw-v9t5bp3g@mail.gmail.com>
References: <CAP6exY+4Qzc_YEkffvaor_Uo0PFg4AUxQRRygdM5Ki4qTKzrvQ@mail.gmail.com>
 <28A20AFF-8679-4D4F-A8CD-68965351E397@iitbombay.org>
 <CAP6exYLpT-bnSb-=HD9hHSpZ5w9kkzCfsavARfzfw-v9t5bp3g@mail.gmail.com>
Message-ID: <CAKr6gn1p-iH_DPWwZF+CQiZXgyZO+mWUjvVRyhsn_USfwhLsTg@mail.gmail.com>

anything which links to libreadline...

-G

On Mon, Jan 23, 2023 at 10:22 AM ron minnich <rminnich at gmail.com> wrote:
>
> How do you write a dc that doesn't compile?
>
> The mind reels.
>
> On Sun, Jan 22, 2023, 7:16 PM Bakul Shah <bakul at iitbombay.org> 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 <rminnich at gmail.com> 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: <CAP6exYLpT-bnSb-=HD9hHSpZ5w9kkzCfsavARfzfw-v9t5bp3g@mail.gmail.com>
References: <CAP6exY+4Qzc_YEkffvaor_Uo0PFg4AUxQRRygdM5Ki4qTKzrvQ@mail.gmail.com>
 <28A20AFF-8679-4D4F-A8CD-68965351E397@iitbombay.org>
 <CAP6exYLpT-bnSb-=HD9hHSpZ5w9kkzCfsavARfzfw-v9t5bp3g@mail.gmail.com>
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 <bakul at iitbombay.org> 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 <rminnich at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230122/d394480c/attachment.htm>

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: <CAP6exYLpT-bnSb-=HD9hHSpZ5w9kkzCfsavARfzfw-v9t5bp3g@mail.gmail.com>
References: <CAP6exY+4Qzc_YEkffvaor_Uo0PFg4AUxQRRygdM5Ki4qTKzrvQ@mail.gmail.com>
 <28A20AFF-8679-4D4F-A8CD-68965351E397@iitbombay.org>
 <CAP6exYLpT-bnSb-=HD9hHSpZ5w9kkzCfsavARfzfw-v9t5bp3g@mail.gmail.com>
Message-ID: <F810CF74-9EDC-40CB-872A-23D28531CBB1@iitbombay.org>

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 <rminnich at gmail.com> wrote:
> 
> How do you write a dc that doesn't compile?
> 
> The mind reels.
> 
> On Sun, Jan 22, 2023, 7:16 PM Bakul Shah <bakul at iitbombay.org <mailto:bakul at iitbombay.org>> 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 <rminnich at gmail.com <mailto:rminnich at gmail.com>> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230122/2edcd55c/attachment.htm>

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: <F810CF74-9EDC-40CB-872A-23D28531CBB1@iitbombay.org>
References: <CAP6exY+4Qzc_YEkffvaor_Uo0PFg4AUxQRRygdM5Ki4qTKzrvQ@mail.gmail.com>
 <28A20AFF-8679-4D4F-A8CD-68965351E397@iitbombay.org>
 <CAP6exYLpT-bnSb-=HD9hHSpZ5w9kkzCfsavARfzfw-v9t5bp3g@mail.gmail.com>
 <F810CF74-9EDC-40CB-872A-23D28531CBB1@iitbombay.org>
Message-ID: <CAKzdPgzD5bhfLiSix=G6QuxCTgqaVMEU3_Y9wZMfaftzdxOaBw@mail.gmail.com>

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 <bakul at iitbombay.org> 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 <rminnich at gmail.com> wrote:
>
> How do you write a dc that doesn't compile?
>
> The mind reels.
>
> On Sun, Jan 22, 2023, 7:16 PM Bakul Shah <bakul at iitbombay.org> 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 <rminnich at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230123/13aafea7/attachment.htm>

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: <alpine.DEB.2.21.2301221848560.29332@sd-119843.dedibox.fr>
References: <CAP6exY+4Qzc_YEkffvaor_Uo0PFg4AUxQRRygdM5Ki4qTKzrvQ@mail.gmail.com>
 <alpine.DEB.2.21.2301221848560.29332@sd-119843.dedibox.fr>
Message-ID: <alpine.BSF.2.21.9999.2301231345270.35099@aneurin.horsfall.org>

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: <alpine.BSF.2.21.9999.2301231345270.35099@aneurin.horsfall.org>
References: <CAP6exY+4Qzc_YEkffvaor_Uo0PFg4AUxQRRygdM5Ki4qTKzrvQ@mail.gmail.com>
 <alpine.DEB.2.21.2301221848560.29332@sd-119843.dedibox.fr>
 <alpine.BSF.2.21.9999.2301231345270.35099@aneurin.horsfall.org>
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: <alpine.BSF.2.21.9999.2301231345270.35099@aneurin.horsfall.org>
References: <CAP6exY+4Qzc_YEkffvaor_Uo0PFg4AUxQRRygdM5Ki4qTKzrvQ@mail.gmail.com>
 <alpine.DEB.2.21.2301221848560.29332@sd-119843.dedibox.fr>
 <alpine.BSF.2.21.9999.2301231345270.35099@aneurin.horsfall.org>
Message-ID: <alpine.DEB.2.21.2301222230010.31399@sd-119843.dedibox.fr>

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: <alpine.DEB.2.21.2301222230010.31399@sd-119843.dedibox.fr>
References: <CAP6exY+4Qzc_YEkffvaor_Uo0PFg4AUxQRRygdM5Ki4qTKzrvQ@mail.gmail.com>
 <alpine.DEB.2.21.2301221848560.29332@sd-119843.dedibox.fr>
 <alpine.BSF.2.21.9999.2301231345270.35099@aneurin.horsfall.org>
 <alpine.DEB.2.21.2301222230010.31399@sd-119843.dedibox.fr>
Message-ID: <CAKr6gn0=Mc5gcqwExzv8NpCpZqcXCni9MhbVVey=EmjBQRSWJw@mail.gmail.com>

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 <usotsuki at buric.co> 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: <CAKr6gn0=Mc5gcqwExzv8NpCpZqcXCni9MhbVVey=EmjBQRSWJw@mail.gmail.com>
References: <CAP6exY+4Qzc_YEkffvaor_Uo0PFg4AUxQRRygdM5Ki4qTKzrvQ@mail.gmail.com>
 <alpine.DEB.2.21.2301221848560.29332@sd-119843.dedibox.fr>
 <alpine.BSF.2.21.9999.2301231345270.35099@aneurin.horsfall.org>
 <alpine.DEB.2.21.2301222230010.31399@sd-119843.dedibox.fr>
 <CAKr6gn0=Mc5gcqwExzv8NpCpZqcXCni9MhbVVey=EmjBQRSWJw@mail.gmail.com>
Message-ID: <CAKr6gn2uXd0em5=W5Q8GSnbCyGCC_enRcvQnBk5Xv8o2gHvEHg@mail.gmail.com>

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 <ggm at algebras.org> 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 <usotsuki at buric.co> 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: <CAKr6gn2uXd0em5=W5Q8GSnbCyGCC_enRcvQnBk5Xv8o2gHvEHg@mail.gmail.com>
References: <CAP6exY+4Qzc_YEkffvaor_Uo0PFg4AUxQRRygdM5Ki4qTKzrvQ@mail.gmail.com>
 <alpine.DEB.2.21.2301221848560.29332@sd-119843.dedibox.fr>
 <alpine.BSF.2.21.9999.2301231345270.35099@aneurin.horsfall.org>
 <alpine.DEB.2.21.2301222230010.31399@sd-119843.dedibox.fr>
 <CAKr6gn0=Mc5gcqwExzv8NpCpZqcXCni9MhbVVey=EmjBQRSWJw@mail.gmail.com>
 <CAKr6gn2uXd0em5=W5Q8GSnbCyGCC_enRcvQnBk5Xv8o2gHvEHg@mail.gmail.com>
Message-ID: <CAKr6gn0B1O7BS8o51_e4En9taGDY9rxPSkx8HGfHSL2TFw9ZbQ@mail.gmail.com>

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 <ggm at algebras.org> 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 <ggm at algebras.org> 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 <usotsuki at buric.co> 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: <CANCZdfrnO-a7bUGRVHtGLdkGFYeaNCyTzwdR1tO+keKkmKf9cA@mail.gmail.com>
References: <CAP6exYK021bpG1epDf+6YBvXUKpN4PoCLYwK1CE1OJ16Pcskgg@mail.gmail.com>
 <CAC20D2ODxrRGZ6sYyMedNdR8wphvkVW3H4j_Dnce-axELdX_Mg@mail.gmail.com>
 <CANCZdfpjrJUDPv2g7-10SrdkgjiacAvp95PVvJ=Ob2h8m8R=FQ@mail.gmail.com>
 <CANCZdfr4zkmFKgqBZKrOL9z5FbFsWSjHpU3vYu-2T3Y+xNat2g@mail.gmail.com>
 <CAC20D2MUWZjQw1O=OGgtf_g8VYoE4ZN8cPyH8FFXaToPuYuZUQ@mail.gmail.com>
 <CANCZdfp2SK+gHNgoybVd3asYfLkNiwt539zdNrgwPSKzK=j38Q@mail.gmail.com>
 <CANCZdfrnO-a7bUGRVHtGLdkGFYeaNCyTzwdR1tO+keKkmKf9cA@mail.gmail.com>
Message-ID: <202301230730.30N7UWqP018967@freefriends.org>

Warner Losh <imp at bsdimp.com> 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: <CAP6exYK021bpG1epDf+6YBvXUKpN4PoCLYwK1CE1OJ16Pcskgg@mail.gmail.com>
 <CAC20D2ODxrRGZ6sYyMedNdR8wphvkVW3H4j_Dnce-axELdX_Mg@mail.gmail.com>
 <CANCZdfpjrJUDPv2g7-10SrdkgjiacAvp95PVvJ=Ob2h8m8R=FQ@mail.gmail.com>
 <CANCZdfr4zkmFKgqBZKrOL9z5FbFsWSjHpU3vYu-2T3Y+xNat2g@mail.gmail.com>
 <CAC20D2MUWZjQw1O=OGgtf_g8VYoE4ZN8cPyH8FFXaToPuYuZUQ@mail.gmail.com>
 <CANCZdfp2SK+gHNgoybVd3asYfLkNiwt539zdNrgwPSKzK=j38Q@mail.gmail.com>
 <CANCZdfrnO-a7bUGRVHtGLdkGFYeaNCyTzwdR1tO+keKkmKf9cA@mail.gmail.com>
 <202301230730.30N7UWqP018967@freefriends.org>
Message-ID: <CAO2qRdOvgNny3L50icK8xmwswu3M429-KqzhVoe09bRMXJBVVg@mail.gmail.com>

At one point it was like $22/page.

On Sun, Jan 22, 2023 at 11:30 PM <arnold at skeeve.com> wrote:

> Warner Losh <imp at bsdimp.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230123/ddfb9cff/attachment.htm>

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: <CAO2qRdOvgNny3L50icK8xmwswu3M429-KqzhVoe09bRMXJBVVg@mail.gmail.com>
References: <CAP6exYK021bpG1epDf+6YBvXUKpN4PoCLYwK1CE1OJ16Pcskgg@mail.gmail.com>
 <CAC20D2ODxrRGZ6sYyMedNdR8wphvkVW3H4j_Dnce-axELdX_Mg@mail.gmail.com>
 <CANCZdfpjrJUDPv2g7-10SrdkgjiacAvp95PVvJ=Ob2h8m8R=FQ@mail.gmail.com>
 <CANCZdfr4zkmFKgqBZKrOL9z5FbFsWSjHpU3vYu-2T3Y+xNat2g@mail.gmail.com>
 <CAC20D2MUWZjQw1O=OGgtf_g8VYoE4ZN8cPyH8FFXaToPuYuZUQ@mail.gmail.com>
 <CANCZdfp2SK+gHNgoybVd3asYfLkNiwt539zdNrgwPSKzK=j38Q@mail.gmail.com>
 <CANCZdfrnO-a7bUGRVHtGLdkGFYeaNCyTzwdR1tO+keKkmKf9cA@mail.gmail.com>
 <202301230730.30N7UWqP018967@freefriends.org>
 <CAO2qRdOvgNny3L50icK8xmwswu3M429-KqzhVoe09bRMXJBVVg@mail.gmail.com>
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 <arnold at skeeve.com> wrote:
> 
> > Warner Losh <imp at bsdimp.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230123/9add4b0a/attachment.sig>

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: <A342E2B0-EC28-420B-963F-87F26580406A@coraid.com>

Original troff targeted only the C/A/T typesetter. 

bwc

> On Jan 23, 2023, at 3:58 AM, G. Branden Robinson <g.branden.robinson at gmail.com> 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 <arnold at skeeve.com> wrote:
>>> 
>>> Warner Losh <imp at bsdimp.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230123/107aefa8/attachment.obj>

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: <CAP6exY+4Qzc_YEkffvaor_Uo0PFg4AUxQRRygdM5Ki4qTKzrvQ@mail.gmail.com>
 <alpine.DEB.2.21.2301221848560.29332@sd-119843.dedibox.fr>
 <alpine.BSF.2.21.9999.2301231345270.35099@aneurin.horsfall.org>
 <20230123031111.GX12196@mcvoy.com>
Message-ID: <CAEoi9W6Ax6je6BuxBgAR2BX6u80WiVQo_Tk4k7ep7ednQHTMfQ@mail.gmail.com>

On Sun, Jan 22, 2023 at 10:11 PM Larry McVoy <lm at mcvoy.com> 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: <CAEoi9W6Ax6je6BuxBgAR2BX6u80WiVQo_Tk4k7ep7ednQHTMfQ@mail.gmail.com>
References: <CAP6exY+4Qzc_YEkffvaor_Uo0PFg4AUxQRRygdM5Ki4qTKzrvQ@mail.gmail.com>
 <alpine.DEB.2.21.2301221848560.29332@sd-119843.dedibox.fr>
 <alpine.BSF.2.21.9999.2301231345270.35099@aneurin.horsfall.org>
 <20230123031111.GX12196@mcvoy.com>
 <CAEoi9W6Ax6je6BuxBgAR2BX6u80WiVQo_Tk4k7ep7ednQHTMfQ@mail.gmail.com>
Message-ID: <CAP6exYJxzAA8FVyW3fNK5kmyEaohr=EW6rHwDP4YaLTcSYDURg@mail.gmail.com>

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 <crossd at gmail.com> wrote:

> On Sun, Jan 22, 2023 at 10:11 PM Larry McVoy <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230123/a2e353b9/attachment.htm>

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: <CAKr6gn0B1O7BS8o51_e4En9taGDY9rxPSkx8HGfHSL2TFw9ZbQ@mail.gmail.com>
References: <CAP6exY+4Qzc_YEkffvaor_Uo0PFg4AUxQRRygdM5Ki4qTKzrvQ@mail.gmail.com>
 <alpine.DEB.2.21.2301221848560.29332@sd-119843.dedibox.fr>
 <alpine.BSF.2.21.9999.2301231345270.35099@aneurin.horsfall.org>
 <alpine.DEB.2.21.2301222230010.31399@sd-119843.dedibox.fr>
 <CAKr6gn0=Mc5gcqwExzv8NpCpZqcXCni9MhbVVey=EmjBQRSWJw@mail.gmail.com>
 <CAKr6gn2uXd0em5=W5Q8GSnbCyGCC_enRcvQnBk5Xv8o2gHvEHg@mail.gmail.com>
 <CAKr6gn0B1O7BS8o51_e4En9taGDY9rxPSkx8HGfHSL2TFw9ZbQ@mail.gmail.com>
Message-ID: <CAEoi9W7O3MJH6QfYT8fEQvfMFmi5+eUKytHuRC+T0Ler0ePuxA@mail.gmail.com>

On Sun, Jan 22, 2023 at 10:41 PM George Michaelson <ggm at algebras.org> 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: <A342E2B0-EC28-420B-963F-87F26580406A@coraid.com>
References: <20230123085833.lvxjr44d4ty2ag62@illithid>
 <A342E2B0-EC28-420B-963F-87F26580406A@coraid.com>
Message-ID: <em47babb6a-6bee-4c76-8ea5-ac26a451621e@a42f0ac3.com>

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" <brantley at coraid.com>
To "G. Branden Robinson" <g.branden.robinson at gmail.com>
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: <CAKzdPgyEysMDym0HnqAiG_2--YrMHg671B9CQq6=KuQZQC2u_w@mail.gmail.com>
 <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: <CAKzdPgyEysMDym0HnqAiG_2--YrMHg671B9CQq6=KuQZQC2u_w@mail.gmail.com>
 <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: <CAKzdPgyEysMDym0HnqAiG_2--YrMHg671B9CQq6=KuQZQC2u_w@mail.gmail.com>
 <202301221452.30MEqrRq025402@freefriends.org>
 <351292a2-7800-4c00-8e33-c6cfc51dedb7@app.fastmail.com>
 <64e4b53e-04a6-5da1-334e-33dfbceb4ace@case.edu>
Message-ID: <Y86tDf+ztYdGxUe3@mit.edu>

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: <Y86tDf+ztYdGxUe3@mit.edu>
References: <CAKzdPgyEysMDym0HnqAiG_2--YrMHg671B9CQq6=KuQZQC2u_w@mail.gmail.com>
 <202301221452.30MEqrRq025402@freefriends.org>
 <351292a2-7800-4c00-8e33-c6cfc51dedb7@app.fastmail.com>
 <64e4b53e-04a6-5da1-334e-33dfbceb4ace@case.edu> <Y86tDf+ztYdGxUe3@mit.edu>
Message-ID: <a31c330c-5761-954d-d9ed-9a49b9c1f7b6@case.edu>

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: <CAO2qRdOvgNny3L50icK8xmwswu3M429-KqzhVoe09bRMXJBVVg@mail.gmail.com>
References: <CAP6exYK021bpG1epDf+6YBvXUKpN4PoCLYwK1CE1OJ16Pcskgg@mail.gmail.com>
 <CAC20D2ODxrRGZ6sYyMedNdR8wphvkVW3H4j_Dnce-axELdX_Mg@mail.gmail.com>
 <CANCZdfpjrJUDPv2g7-10SrdkgjiacAvp95PVvJ=Ob2h8m8R=FQ@mail.gmail.com>
 <CANCZdfr4zkmFKgqBZKrOL9z5FbFsWSjHpU3vYu-2T3Y+xNat2g@mail.gmail.com>
 <CAC20D2MUWZjQw1O=OGgtf_g8VYoE4ZN8cPyH8FFXaToPuYuZUQ@mail.gmail.com>
 <CANCZdfp2SK+gHNgoybVd3asYfLkNiwt539zdNrgwPSKzK=j38Q@mail.gmail.com>
 <CANCZdfrnO-a7bUGRVHtGLdkGFYeaNCyTzwdR1tO+keKkmKf9cA@mail.gmail.com>
 <202301230730.30N7UWqP018967@freefriends.org>
 <CAO2qRdOvgNny3L50icK8xmwswu3M429-KqzhVoe09bRMXJBVVg@mail.gmail.com>
Message-ID: <CAKH6PiW36VJXNTivkyRBadDr=r4DsGG1D+0qZ2rsgzSJ1wM0zw@mail.gmail.com>

>> 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 <audioskeptic at gmail.com> wrote:
>
> At one point it was like $22/page.
>
> On Sun, Jan 22, 2023 at 11:30 PM <arnold at skeeve.com> wrote:
>>
>> Warner Losh <imp at bsdimp.com> 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: <em47babb6a-6bee-4c76-8ea5-ac26a451621e@a42f0ac3.com>
References: <20230123085833.lvxjr44d4ty2ag62@illithid>
 <A342E2B0-EC28-420B-963F-87F26580406A@coraid.com>
 <em47babb6a-6bee-4c76-8ea5-ac26a451621e@a42f0ac3.com>
Message-ID: <D2B10561-276F-49D7-AD5D-C527D5C20B96@coraid.com>

What a great story!

On January 23, 2023 9:25:25 AM EST, Ronald Natalie <ron at ronnatalie.com> 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" <brantley at coraid.com>
>To "G. Branden Robinson" <g.branden.robinson at gmail.com>
>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: <a31c330c-5761-954d-d9ed-9a49b9c1f7b6@case.edu>
References: <CAKzdPgyEysMDym0HnqAiG_2--YrMHg671B9CQq6=KuQZQC2u_w@mail.gmail.com>
 <202301221452.30MEqrRq025402@freefriends.org>
 <351292a2-7800-4c00-8e33-c6cfc51dedb7@app.fastmail.com>
 <64e4b53e-04a6-5da1-334e-33dfbceb4ace@case.edu> <Y86tDf+ztYdGxUe3@mit.edu>
 <a31c330c-5761-954d-d9ed-9a49b9c1f7b6@case.edu>
Message-ID: <CALQ0xCAVVigXS_wnVuyrMP_Vz6q_AU7pKfjAFdMo_q4gQ9meQQ@mail.gmail.com>

https://en.wikipedia.org/wiki/Terminal_mode
=====
nygeek.net
mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home>


On Mon, Jan 23, 2023 at 10:53 AM Chet Ramey <chet.ramey at case.edu> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230123/56872cc6/attachment-0001.htm>

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: <CAEoi9W7O3MJH6QfYT8fEQvfMFmi5+eUKytHuRC+T0Ler0ePuxA@mail.gmail.com>
References: <CAP6exY+4Qzc_YEkffvaor_Uo0PFg4AUxQRRygdM5Ki4qTKzrvQ@mail.gmail.com>
 <alpine.DEB.2.21.2301221848560.29332@sd-119843.dedibox.fr>
 <alpine.BSF.2.21.9999.2301231345270.35099@aneurin.horsfall.org>
 <alpine.DEB.2.21.2301222230010.31399@sd-119843.dedibox.fr>
 <CAKr6gn0=Mc5gcqwExzv8NpCpZqcXCni9MhbVVey=EmjBQRSWJw@mail.gmail.com>
 <CAKr6gn2uXd0em5=W5Q8GSnbCyGCC_enRcvQnBk5Xv8o2gHvEHg@mail.gmail.com>
 <CAKr6gn0B1O7BS8o51_e4En9taGDY9rxPSkx8HGfHSL2TFw9ZbQ@mail.gmail.com>
 <CAEoi9W7O3MJH6QfYT8fEQvfMFmi5+eUKytHuRC+T0Ler0ePuxA@mail.gmail.com>
Message-ID: <f1548416-6d17-41c1-af89-5d9768943d66@app.fastmail.com>

On Mon, Jan 23, 2023, at 06:15, Dan Cross wrote:
> On Sun, Jan 22, 2023 at 10:41 PM George Michaelson <ggm at algebras.org> 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: <f1548416-6d17-41c1-af89-5d9768943d66@app.fastmail.com>
References: <CAP6exY+4Qzc_YEkffvaor_Uo0PFg4AUxQRRygdM5Ki4qTKzrvQ@mail.gmail.com>
 <alpine.DEB.2.21.2301221848560.29332@sd-119843.dedibox.fr>
 <alpine.BSF.2.21.9999.2301231345270.35099@aneurin.horsfall.org>
 <alpine.DEB.2.21.2301222230010.31399@sd-119843.dedibox.fr>
 <CAKr6gn0=Mc5gcqwExzv8NpCpZqcXCni9MhbVVey=EmjBQRSWJw@mail.gmail.com>
 <CAKr6gn2uXd0em5=W5Q8GSnbCyGCC_enRcvQnBk5Xv8o2gHvEHg@mail.gmail.com>
 <CAKr6gn0B1O7BS8o51_e4En9taGDY9rxPSkx8HGfHSL2TFw9ZbQ@mail.gmail.com>
 <CAEoi9W7O3MJH6QfYT8fEQvfMFmi5+eUKytHuRC+T0Ler0ePuxA@mail.gmail.com>
 <f1548416-6d17-41c1-af89-5d9768943d66@app.fastmail.com>
Message-ID: <CAP2nic1R4yx5EkZ+zAxaZKo4m47kvJgs5bC5L0gULN0oaSTv5A@mail.gmail.com>

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'
    <stdin>:1

On Mon, Jan 23, 2023 at 2:09 PM Joseph Holsten <joseph at josephholsten.com>
wrote:

> On Mon, Jan 23, 2023, at 06:15, Dan Cross wrote:
> > On Sun, Jan 22, 2023 at 10:41 PM George Michaelson <ggm at algebras.org>
> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230123/85eb150e/attachment.htm>

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: <Y89NXveHlC4Jd7s9@largo.jsg.id.au>

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: <CAKH6PiW36VJXNTivkyRBadDr=r4DsGG1D+0qZ2rsgzSJ1wM0zw@mail.gmail.com>
References: <CAP6exYK021bpG1epDf+6YBvXUKpN4PoCLYwK1CE1OJ16Pcskgg@mail.gmail.com>
 <CAC20D2ODxrRGZ6sYyMedNdR8wphvkVW3H4j_Dnce-axELdX_Mg@mail.gmail.com>
 <CANCZdfpjrJUDPv2g7-10SrdkgjiacAvp95PVvJ=Ob2h8m8R=FQ@mail.gmail.com>
 <CANCZdfr4zkmFKgqBZKrOL9z5FbFsWSjHpU3vYu-2T3Y+xNat2g@mail.gmail.com>
 <CAC20D2MUWZjQw1O=OGgtf_g8VYoE4ZN8cPyH8FFXaToPuYuZUQ@mail.gmail.com>
 <CANCZdfp2SK+gHNgoybVd3asYfLkNiwt539zdNrgwPSKzK=j38Q@mail.gmail.com>
 <CANCZdfrnO-a7bUGRVHtGLdkGFYeaNCyTzwdR1tO+keKkmKf9cA@mail.gmail.com>
 <202301230730.30N7UWqP018967@freefriends.org>
 <CAO2qRdOvgNny3L50icK8xmwswu3M429-KqzhVoe09bRMXJBVVg@mail.gmail.com>
 <CAKH6PiW36VJXNTivkyRBadDr=r4DsGG1D+0qZ2rsgzSJ1wM0zw@mail.gmail.com>
Message-ID: <202301240721.30O7LRBb000597@freefriends.org>

I stand corrected. Thanks.

Arnold

Douglas McIlroy <douglas.mcilroy at dartmouth.edu> 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 <audioskeptic at gmail.com> wrote:
> >
> > At one point it was like $22/page.
> >
> > On Sun, Jan 22, 2023 at 11:30 PM <arnold at skeeve.com> wrote:
> >>
> >> Warner Losh <imp at bsdimp.com> 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: <hfkEzQVdLoIV-lFdZA4e9t9x4SU-CeMW8wiZVJUc17Coh1IxHmxsiSEgjWtH7i3k7U6BU5lKk1sg2WbmEciXKvO-RlgmNg8-DsqOlJxzbUs=@protonmail.com>
References: <hfkEzQVdLoIV-lFdZA4e9t9x4SU-CeMW8wiZVJUc17Coh1IxHmxsiSEgjWtH7i3k7U6BU5lKk1sg2WbmEciXKvO-RlgmNg8-DsqOlJxzbUs=@protonmail.com>
Message-ID: <Y8/mhD6IiXeUnaiB@largo.jsg.id.au>

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: <CAEoi9W7HBXxTbt+unKU53toTbXx7fr2nNuOAMPwqcyng-DCFEg@mail.gmail.com>

[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 <metta.crawler at gmail.com>:
>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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230124/1fd9dc33/attachment.htm>

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 <will.senn at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230125/a087e3f2/attachment.htm>

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: <CAFH29trXu_SGp-7xv6xqMc49tTeEuyJdKwP-Fyfe6BCrpGZ9nQ@mail.gmail.com>

> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230125/9fdee46d/attachment.htm>

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: <CAFH29trXu_SGp-7xv6xqMc49tTeEuyJdKwP-Fyfe6BCrpGZ9nQ@mail.gmail.com>
References: <3e272d72-b77a-d347-b5c3-7ed19482e5af@gmail.com>
 <3h5FEAegoTs6FrhHODiW-rBdB59dt_Rmr4G0PIw7flqaJLsmorgPsilm4f2aJkDud-qEljDjnCJcE1uY05Iw4HNQcyNG4W3wzVlLD0UZfLg=@protonmail.com>
 <CAFH29trXu_SGp-7xv6xqMc49tTeEuyJdKwP-Fyfe6BCrpGZ9nQ@mail.gmail.com>
Message-ID: <Y9GIus/Iw21uvkFb@mit.edu>

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: <Y9GIus/Iw21uvkFb@mit.edu>
References: <3e272d72-b77a-d347-b5c3-7ed19482e5af@gmail.com>
 <3h5FEAegoTs6FrhHODiW-rBdB59dt_Rmr4G0PIw7flqaJLsmorgPsilm4f2aJkDud-qEljDjnCJcE1uY05Iw4HNQcyNG4W3wzVlLD0UZfLg=@protonmail.com>
 <CAFH29trXu_SGp-7xv6xqMc49tTeEuyJdKwP-Fyfe6BCrpGZ9nQ@mail.gmail.com>
 <Y9GIus/Iw21uvkFb@mit.edu>
Message-ID: <CAEoi9W5jU+EBo33DYG-jQ3z+qVabzxOfK7G+VZE_a6igkfDWEw@mail.gmail.com>

On Wed, Jan 25, 2023 at 2:54 PM Theodore Ts'o <tytso at mit.edu> 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: <CAEoi9W5jU+EBo33DYG-jQ3z+qVabzxOfK7G+VZE_a6igkfDWEw@mail.gmail.com>
References: <3e272d72-b77a-d347-b5c3-7ed19482e5af@gmail.com>
 <3h5FEAegoTs6FrhHODiW-rBdB59dt_Rmr4G0PIw7flqaJLsmorgPsilm4f2aJkDud-qEljDjnCJcE1uY05Iw4HNQcyNG4W3wzVlLD0UZfLg=@protonmail.com>
 <CAFH29trXu_SGp-7xv6xqMc49tTeEuyJdKwP-Fyfe6BCrpGZ9nQ@mail.gmail.com>
 <Y9GIus/Iw21uvkFb@mit.edu>
 <CAEoi9W5jU+EBo33DYG-jQ3z+qVabzxOfK7G+VZE_a6igkfDWEw@mail.gmail.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>
 <CAFH29trXu_SGp-7xv6xqMc49tTeEuyJdKwP-Fyfe6BCrpGZ9nQ@mail.gmail.com>
 <Y9GIus/Iw21uvkFb@mit.edu>
 <CAEoi9W5jU+EBo33DYG-jQ3z+qVabzxOfK7G+VZE_a6igkfDWEw@mail.gmail.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: <CAC20D2NgrjJF-yGOBYFwr=rbRog+YFHF7tL_qozY=AZOf19-XA@mail.gmail.com>

On Wed, Jan 25, 2023 at 3:38 PM Noel Chiappa <jnc at mercury.lcs.mit.edu>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230125/0b712c8f/attachment.htm>

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: <E05C637A-6237-4000-9759-A73F267A94EC@josephholsten.com>

An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230125/cb67e437/attachment.htm>

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: <E05C637A-6237-4000-9759-A73F267A94EC@josephholsten.com>
References: <E05C637A-6237-4000-9759-A73F267A94EC@josephholsten.com>
Message-ID: <BMsRLs2wvKH0iixW0Eo49huSqZ4zAi_vnew1uMpaw1pFKBQNyXPztO46Z03iKSgJ2USkeTDcioaYrsH9k1Yf-u6ztc_sOSeDyUFlItm19aM=@protonmail.com>

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 <joseph at josephholsten.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230126/7fcd113d/attachment.htm>

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: <E05C637A-6237-4000-9759-A73F267A94EC@josephholsten.com>
References: <E05C637A-6237-4000-9759-A73F267A94EC@josephholsten.com>
Message-ID: <23432965-52D6-4331-A4D8-8A6FDDB3F751@serissa.com>

An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230125/48c29610/attachment.htm>

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: <BMsRLs2wvKH0iixW0Eo49huSqZ4zAi_vnew1uMpaw1pFKBQNyXPztO46Z03iKSgJ2USkeTDcioaYrsH9k1Yf-u6ztc_sOSeDyUFlItm19aM=@protonmail.com>
References: <E05C637A-6237-4000-9759-A73F267A94EC@josephholsten.com>
 <BMsRLs2wvKH0iixW0Eo49huSqZ4zAi_vnew1uMpaw1pFKBQNyXPztO46Z03iKSgJ2USkeTDcioaYrsH9k1Yf-u6ztc_sOSeDyUFlItm19aM=@protonmail.com>
Message-ID: <eda11939-09a5-2dd1-2b5a-dcbdb2feb82c@makerlisp.com>

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 
> <joseph at josephholsten.com> 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 <mailto:joseph at josephholsten.com>
>> tel:+1-360-927-7234 <tel:%28360%29%20927-7234>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230125/dda4c0c9/attachment.htm>

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: <E05C637A-6237-4000-9759-A73F267A94EC@josephholsten.com>
References: <E05C637A-6237-4000-9759-A73F267A94EC@josephholsten.com>
Message-ID: <CANxB0bQokunUUP_YnChHguv4VtWN_j=BRu6q9CCQxT+Qu_QUng@mail.gmail.com>

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 <joseph at josephholsten.com>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230125/aef09793/attachment.htm>

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: <eda11939-09a5-2dd1-2b5a-dcbdb2feb82c@makerlisp.com>
References: <E05C637A-6237-4000-9759-A73F267A94EC@josephholsten.com>
 <BMsRLs2wvKH0iixW0Eo49huSqZ4zAi_vnew1uMpaw1pFKBQNyXPztO46Z03iKSgJ2USkeTDcioaYrsH9k1Yf-u6ztc_sOSeDyUFlItm19aM=@protonmail.com>
 <eda11939-09a5-2dd1-2b5a-dcbdb2feb82c@makerlisp.com>
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: <E05C637A-6237-4000-9759-A73F267A94EC@josephholsten.com>
References: <E05C637A-6237-4000-9759-A73F267A94EC@josephholsten.com>
Message-ID: <EB3088E9-8B90-4800-B094-F22B81A92029@eschatologist.net>

On Jan 25, 2023, at 4:31 PM, Joseph Holsten <joseph at josephholsten.com> 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: <CAC20D2NgrjJF-yGOBYFwr=rbRog+YFHF7tL_qozY=AZOf19-XA@mail.gmail.com>
 (Clem Cole's message of "Wed, 25 Jan 2023 16:25:32 -0500")
References: <20230125203805.4762218C083@mercury.lcs.mit.edu>
 <CAC20D2NgrjJF-yGOBYFwr=rbRog+YFHF7tL_qozY=AZOf19-XA@mail.gmail.com>
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: <EB3088E9-8B90-4800-B094-F22B81A92029@eschatologist.net>
References: <E05C637A-6237-4000-9759-A73F267A94EC@josephholsten.com>
 <EB3088E9-8B90-4800-B094-F22B81A92029@eschatologist.net>
Message-ID: <CAD2gp_QtUPmd78yAixvKK1wzPX67HKZXzU5cJnVUbcWtMounGQ@mail.gmail.com>

On Wed, Jan 25, 2023 at 8:47 PM Chris Hanson <cmhanson at eschatologist.net>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230126/9ae91636/attachment.htm>

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: <CAD2gp_QtUPmd78yAixvKK1wzPX67HKZXzU5cJnVUbcWtMounGQ@mail.gmail.com>
References: <E05C637A-6237-4000-9759-A73F267A94EC@josephholsten.com>
 <EB3088E9-8B90-4800-B094-F22B81A92029@eschatologist.net>
 <CAD2gp_QtUPmd78yAixvKK1wzPX67HKZXzU5cJnVUbcWtMounGQ@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.2301261830050.58710@aneurin.horsfall.org>

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: <E05C637A-6237-4000-9759-A73F267A94EC@josephholsten.com>
References: <E05C637A-6237-4000-9759-A73F267A94EC@josephholsten.com>
Message-ID: <a477e7fe-f73b-e590-985f-eface5a62140@e-bbes.com>

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: <a477e7fe-f73b-e590-985f-eface5a62140@e-bbes.com>
References: <E05C637A-6237-4000-9759-A73F267A94EC@josephholsten.com>
 <a477e7fe-f73b-e590-985f-eface5a62140@e-bbes.com>
Message-ID: <CAKzdPgw3MVLqMHCXRWE7qY8JzfjRdjen549uVbHEmKwTzZ0EDQ@mail.gmail.com>

at least 1 million words of marketing?

-rob


On Thu, Jan 26, 2023 at 8:54 PM emanuel stiebler <emu at e-bbes.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230126/ed5c0fce/attachment-0001.htm>

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: <a477e7fe-f73b-e590-985f-eface5a62140@e-bbes.com>
References: <E05C637A-6237-4000-9759-A73F267A94EC@josephholsten.com>
 <a477e7fe-f73b-e590-985f-eface5a62140@e-bbes.com>
Message-ID: <DC02FAF6-F414-426B-AA93-4EEB4672AEB3@xs4all.nl>



> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230126/837d391c/attachment.sig>

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>
 <CAC20D2NgrjJF-yGOBYFwr=rbRog+YFHF7tL_qozY=AZOf19-XA@mail.gmail.com>
 <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>
 <CAC20D2NgrjJF-yGOBYFwr=rbRog+YFHF7tL_qozY=AZOf19-XA@mail.gmail.com>
 <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 <ralph at inputplus.co.uk> 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: <Y9GIus/Iw21uvkFb@mit.edu>
References: <3e272d72-b77a-d347-b5c3-7ed19482e5af@gmail.com>
 <3h5FEAegoTs6FrhHODiW-rBdB59dt_Rmr4G0PIw7flqaJLsmorgPsilm4f2aJkDud-qEljDjnCJcE1uY05Iw4HNQcyNG4W3wzVlLD0UZfLg=@protonmail.com>
 <CAFH29trXu_SGp-7xv6xqMc49tTeEuyJdKwP-Fyfe6BCrpGZ9nQ@mail.gmail.com>
 <Y9GIus/Iw21uvkFb@mit.edu>
Message-ID: <CALQ0xCBM7reNn1tgZvV_61zAFoC9hMXEqAFy+LFP9VDHanVSpQ@mail.gmail.com>

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 <tytso at mit.edu> 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 <https://www.mindthegapdialogs.com/home>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230126/deee0c61/attachment.htm>

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>
 <CAC20D2NgrjJF-yGOBYFwr=rbRog+YFHF7tL_qozY=AZOf19-XA@mail.gmail.com>
 <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: <E05C637A-6237-4000-9759-A73F267A94EC@josephholsten.com>
 <23432965-52D6-4331-A4D8-8A6FDDB3F751@serissa.com>
Message-ID: <CALQ0xCBcbsfTuaUGyY8+1L4ADMupqRMANjLXQSWDiG3hFd02dg@mail.gmail.com>

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 <stewart at serissa.com> 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 <joseph at josephholsten.com>
> 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 <https://www.mindthegapdialogs.com/home>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230126/ff39f406/attachment.htm>

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: <CALQ0xCBcbsfTuaUGyY8+1L4ADMupqRMANjLXQSWDiG3hFd02dg@mail.gmail.com>
References: <E05C637A-6237-4000-9759-A73F267A94EC@josephholsten.com>
 <23432965-52D6-4331-A4D8-8A6FDDB3F751@serissa.com>
 <CALQ0xCBcbsfTuaUGyY8+1L4ADMupqRMANjLXQSWDiG3hFd02dg@mail.gmail.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 <marc.donner at gmail.com> 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 <stewart at serissa.com> 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 <joseph at josephholsten.com>
> > 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 <https://www.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: <E05C637A-6237-4000-9759-A73F267A94EC@josephholsten.com>
References: <E05C637A-6237-4000-9759-A73F267A94EC@josephholsten.com>
Message-ID: <CAC20D2Oc9y25-uN1PJAdGRBCq=WocB-vm5=feH5MLQ=1RGBXVw@mail.gmail.com>

Check out: Magnolia - The Tektronix Unix Personal Computer September 1980
<https://streaklinks.com/BXrcuEsysvYb2V7QEQCkESzw/https%3A%2F%2Farchive.org%2Fdetails%2Fbitsavers_tektronixmliaplan_4739361>
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 <joseph at josephholsten.com>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230126/26d33914/attachment.htm>

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>
 <CAC20D2NgrjJF-yGOBYFwr=rbRog+YFHF7tL_qozY=AZOf19-XA@mail.gmail.com>
 <7w8rhpdczd.fsf@junk.nocrew.org>
 <20230126105626.72CD922168@orac.inputplus.co.uk>
Message-ID: <CAFZukdRGG6xWCyLsF_wiPsf5JsPFwRm7Hty=BbK2a4UjxaAyYQ@mail.gmail.com>

On Thursday, January 26, 2023, Ralph Corderoy <ralph at inputplus.co.uk> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230126/0b69a56f/attachment.htm>

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: <CAFZukdRGG6xWCyLsF_wiPsf5JsPFwRm7Hty=BbK2a4UjxaAyYQ@mail.gmail.com>
References: <20230125203805.4762218C083@mercury.lcs.mit.edu>
 <CAC20D2NgrjJF-yGOBYFwr=rbRog+YFHF7tL_qozY=AZOf19-XA@mail.gmail.com>
 <7w8rhpdczd.fsf@junk.nocrew.org>
 <20230126105626.72CD922168@orac.inputplus.co.uk>
 <CAFZukdRGG6xWCyLsF_wiPsf5JsPFwRm7Hty=BbK2a4UjxaAyYQ@mail.gmail.com>
Message-ID: <R5wOXkWssqxYtpNAmdT90jQP2qCwEv2mH-jCH6NHeIHzamFBCq7h63fwNQP1wEVfWBD56jJ19sO3PtMNxBFE3IzP68H4JxEffZWy2IqPoQk=@protonmail.com>

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 <joshnatis0 at gmail.com> wrote:

> On Thursday, January 26, 2023, Ralph Corderoy <ralph at inputplus.co.uk> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230126/76c3a7e8/attachment.htm>

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: <CAC20D2MAdyfD8Xv3RYL4xgt99OG2RpOrtbjvLP3hfpx8iutfBw@mail.gmail.com>

On Thu, Jan 26, 2023 at 10:58 AM Paul Ruizendaal <pnr at planet.nl> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230126/83e018b2/attachment.htm>

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: <CAD2gp_QtUPmd78yAixvKK1wzPX67HKZXzU5cJnVUbcWtMounGQ@mail.g
 mail.com>
References: <E05C637A-6237-4000-9759-A73F267A94EC@josephholsten.com>
 <EB3088E9-8B90-4800-B094-F22B81A92029@eschatologist.net>
 <CAD2gp_QtUPmd78yAixvKK1wzPX67HKZXzU5cJnVUbcWtMounGQ@mail.gmail.com>
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: <R5wOXkWssqxYtpNAmdT90jQP2qCwEv2mH-jCH6NHeIHzamFBCq7h63fwNQP1wEVfWBD56jJ19sO3PtMNxBFE3IzP68H4JxEffZWy2IqPoQk=@protonmail.com>
References: <20230125203805.4762218C083@mercury.lcs.mit.edu>
 <CAC20D2NgrjJF-yGOBYFwr=rbRog+YFHF7tL_qozY=AZOf19-XA@mail.gmail.com>
 <7w8rhpdczd.fsf@junk.nocrew.org>
 <20230126105626.72CD922168@orac.inputplus.co.uk>
 <CAFZukdRGG6xWCyLsF_wiPsf5JsPFwRm7Hty=BbK2a4UjxaAyYQ@mail.gmail.com>
 <R5wOXkWssqxYtpNAmdT90jQP2qCwEv2mH-jCH6NHeIHzamFBCq7h63fwNQP1wEVfWBD56jJ19sO3PtMNxBFE3IzP68H4JxEffZWy2IqPoQk=@protonmail.com>
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: <bk4cLXqBNV2q74fVuNZC7Z8K3dMQpI0Zk6c8YX6q7zZ9BOvDaNt3ItkQwPzkt03v32Vt4TSR6so024BvnISec0p1fNBxzhLgQBIqF9rLTes=@protonmail.com>

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 <emu at e-bbes.com> 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: <CANCZdfq6O0U12=eM+Ox+U7qNwwPV2B4PLX7d=rWDmFgvNeODQQ@mail.gmail.com>

On Thu, Jan 26, 2023 at 8:58 AM Paul Ruizendaal <pnr at planet.nl> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230126/062d6d5b/attachment.htm>

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: <CAD2gp_QtUPmd78yAixvKK1wzPX67HKZXzU5cJnVUbcWtMounGQ@mail.gmail.com>
References: <E05C637A-6237-4000-9759-A73F267A94EC@josephholsten.com>
 <EB3088E9-8B90-4800-B094-F22B81A92029@eschatologist.net>
 <CAD2gp_QtUPmd78yAixvKK1wzPX67HKZXzU5cJnVUbcWtMounGQ@mail.gmail.com>
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: <CAD2gp_QtUPmd78yAixvKK1wzPX67HKZXzU5cJnVUbcWtMounGQ@mail.gmail.com>
References: <E05C637A-6237-4000-9759-A73F267A94EC@josephholsten.com>
 <EB3088E9-8B90-4800-B094-F22B81A92029@eschatologist.net>
 <CAD2gp_QtUPmd78yAixvKK1wzPX67HKZXzU5cJnVUbcWtMounGQ@mail.gmail.com>
Message-ID: <202301261804.30QI4sd9132510@darkstar.fourwinds.com>

John Cowan writes:
> On Wed, Jan 25, 2023 at 8:47 PM Chris Hanson <cmhanson at eschatologist.net>
> 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: <CANCZdfq6O0U12=eM+Ox+U7qNwwPV2B4PLX7d=rWDmFgvNeODQQ@mail.gmail.com>
 (Warner Losh's message of "Thu, 26 Jan 2023 09:51:59 -0700")
References: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl>
 <CANCZdfq6O0U12=eM+Ox+U7qNwwPV2B4PLX7d=rWDmFgvNeODQQ@mail.gmail.com>
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>
 <CANCZdfq6O0U12=eM+Ox+U7qNwwPV2B4PLX7d=rWDmFgvNeODQQ@mail.gmail.com>
 <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 <lars at nocrew.org> 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: <CAKzdPgyohSuw8w_QT_KTdKC=0L++3OLT_1ZkCcm8AXCqattoeQ@mail.gmail.com>

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 <pnr at planet.nl> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230127/d58303be/attachment.htm>

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>
 <CAC20D2NgrjJF-yGOBYFwr=rbRog+YFHF7tL_qozY=AZOf19-XA@mail.gmail.com>
 <7w8rhpdczd.fsf@junk.nocrew.org>
 <20230126105626.72CD922168@orac.inputplus.co.uk>
 <CAFZukdRGG6xWCyLsF_wiPsf5JsPFwRm7Hty=BbK2a4UjxaAyYQ@mail.gmail.com>
 <R5wOXkWssqxYtpNAmdT90jQP2qCwEv2mH-jCH6NHeIHzamFBCq7h63fwNQP1wEVfWBD56jJ19sO3PtMNxBFE3IzP68H4JxEffZWy2IqPoQk=@protonmail.com>
 <85d0ee98-3686-b305-49d7-536589b5d3db@e-bbes.com>
Message-ID: <sgJhkmXbAnD_3JLUj0_MUbBGzA_ia3QRfjDAKK-bDIMeDr4Eyuykiio-CbQlFu-kmJrcNIYOomHnVmV92Ggs0R58ZoU07p1aMmyBiVh-4Hs=@protonmail.com>

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 <emu at e-bbes.com> 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: <E05C637A-6237-4000-9759-A73F267A94EC@josephholsten.com>
 <EB3088E9-8B90-4800-B094-F22B81A92029@eschatologist.net>
 <CAD2gp_QtUPmd78yAixvKK1wzPX67HKZXzU5cJnVUbcWtMounGQ@mail.gmail.com>
 <202301261804.30QI4sd9132510@darkstar.fourwinds.com>
Message-ID: <c4b08a9d-a0eb-45f7-98c6-1e715cb58908@app.fastmail.com>

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 <cmhanson at eschatologist.net>
>> 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: <c4b08a9d-a0eb-45f7-98c6-1e715cb58908@app.fastmail.com>
References: <E05C637A-6237-4000-9759-A73F267A94EC@josephholsten.com>
 <EB3088E9-8B90-4800-B094-F22B81A92029@eschatologist.net>
 <CAD2gp_QtUPmd78yAixvKK1wzPX67HKZXzU5cJnVUbcWtMounGQ@mail.gmail.com>
 <202301261804.30QI4sd9132510@darkstar.fourwinds.com>
 <c4b08a9d-a0eb-45f7-98c6-1e715cb58908@app.fastmail.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: <CAC20D2MAdyfD8Xv3RYL4xgt99OG2RpOrtbjvLP3hfpx8iutfBw@mail.gmail.com>
References: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl>
 <CAC20D2MAdyfD8Xv3RYL4xgt99OG2RpOrtbjvLP3hfpx8iutfBw@mail.gmail.com>
Message-ID: <0778FF74-7DF5-4072-95F3-5FF5BEB4CC33@planet.nl>


> On 26 Jan 2023, at 17:29, Clem Cole <clemc at ccc.com> 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 <imp at bsdimp.com>

> 
>> - 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: <E05C637A-6237-4000-9759-A73F267A94EC@josephholsten.com>
 <EB3088E9-8B90-4800-B094-F22B81A92029@eschatologist.net>
 <CAD2gp_QtUPmd78yAixvKK1wzPX67HKZXzU5cJnVUbcWtMounGQ@mail.gmail.com>
 <202301261804.30QI4sd9132510@darkstar.fourwinds.com>
 <c4b08a9d-a0eb-45f7-98c6-1e715cb58908@app.fastmail.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>
 <CAC20D2MAdyfD8Xv3RYL4xgt99OG2RpOrtbjvLP3hfpx8iutfBw@mail.gmail.com>
 <0778FF74-7DF5-4072-95F3-5FF5BEB4CC33@planet.nl>
Message-ID: <BD0E1656-F491-40B9-B017-1205EB1CF1A2@iitbombay.org>

On Jan 26, 2023, at 2:17 PM, Paul Ruizendaal <pnr at planet.nl> 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: <sgJhkmXbAnD_3JLUj0_MUbBGzA_ia3QRfjDAKK-bDIMeDr4Eyuykiio-CbQlFu-kmJrcNIYOomHnVmV92Ggs0R58ZoU07p1aMmyBiVh-4Hs=@protonmail.com>
References: <20230125203805.4762218C083@mercury.lcs.mit.edu>
 <CAC20D2NgrjJF-yGOBYFwr=rbRog+YFHF7tL_qozY=AZOf19-XA@mail.gmail.com>
 <7w8rhpdczd.fsf@junk.nocrew.org>
 <20230126105626.72CD922168@orac.inputplus.co.uk>
 <CAFZukdRGG6xWCyLsF_wiPsf5JsPFwRm7Hty=BbK2a4UjxaAyYQ@mail.gmail.com>
 <R5wOXkWssqxYtpNAmdT90jQP2qCwEv2mH-jCH6NHeIHzamFBCq7h63fwNQP1wEVfWBD56jJ19sO3PtMNxBFE3IzP68H4JxEffZWy2IqPoQk=@protonmail.com>
 <85d0ee98-3686-b305-49d7-536589b5d3db@e-bbes.com>
 <sgJhkmXbAnD_3JLUj0_MUbBGzA_ia3QRfjDAKK-bDIMeDr4Eyuykiio-CbQlFu-kmJrcNIYOomHnVmV92Ggs0R58ZoU07p1aMmyBiVh-4Hs=@protonmail.com>
Message-ID: <CALMnNGjiz=UdEESuhueunE7F2tAr-5vo0415kqCq0HHww=Sw8A@mail.gmail.com>

On Thursday, January 26, 2023, segaloco via TUHS <tuhs at tuhs.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230126/b2d47bd1/attachment-0001.htm>

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: <BD0E1656-F491-40B9-B017-1205EB1CF1A2@iitbombay.org>
References: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl>
 <CAC20D2MAdyfD8Xv3RYL4xgt99OG2RpOrtbjvLP3hfpx8iutfBw@mail.gmail.com>
 <0778FF74-7DF5-4072-95F3-5FF5BEB4CC33@planet.nl>
 <BD0E1656-F491-40B9-B017-1205EB1CF1A2@iitbombay.org>
Message-ID: <F9B7616E-F8A6-434D-BF9D-453BF6974727@planet.nl>


> On 26 Jan 2023, at 23:45, Bakul Shah <bakul at iitbombay.org> wrote:
> 
> On Jan 26, 2023, at 2:17 PM, Paul Ruizendaal <pnr at planet.nl> 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: <E05C637A-6237-4000-9759-A73F267A94EC@josephholsten.com>
 <EB3088E9-8B90-4800-B094-F22B81A92029@eschatologist.net>
 <CAD2gp_QtUPmd78yAixvKK1wzPX67HKZXzU5cJnVUbcWtMounGQ@mail.gmail.com>
 <202301261804.30QI4sd9132510@darkstar.fourwinds.com>
 <c4b08a9d-a0eb-45f7-98c6-1e715cb58908@app.fastmail.com>
 <202301262138.30QLc6wY143500@darkstar.fourwinds.com>
 <620c709c-e8bb-401c-a60d-8869457caacd@app.fastmail.com>
Message-ID: <wzLILyoOAS7e8Tp7ahmcvzTM4lmxeOTgkIFxngKLgEuuYXCgwgd3cY4iGVVShrXaHPFu3aJtl_tPlJmzJggwBTQkwYruJNULuzwTxxUG9Do=@protonmail.com>

> 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: <E05C637A-6237-4000-9759-A73F267A94EC@josephholsten.com>
 <EB3088E9-8B90-4800-B094-F22B81A92029@eschatologist.net>
 <CAD2gp_QtUPmd78yAixvKK1wzPX67HKZXzU5cJnVUbcWtMounGQ@mail.gmail.com>
 <202301261804.30QI4sd9132510@darkstar.fourwinds.com>
 <c4b08a9d-a0eb-45f7-98c6-1e715cb58908@app.fastmail.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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230126/b0b53698/attachment-0001.ms>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ms.2023-01-26.pdf
Type: application/pdf
Size: 135713 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230126/b0b53698/attachment-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230126/b0b53698/attachment-0001.sig>

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: <CALMnNGjiz=UdEESuhueunE7F2tAr-5vo0415kqCq0HHww=Sw8A@mail.gmail.com>
References: <20230125203805.4762218C083@mercury.lcs.mit.edu>
 <CAC20D2NgrjJF-yGOBYFwr=rbRog+YFHF7tL_qozY=AZOf19-XA@mail.gmail.com>
 <7w8rhpdczd.fsf@junk.nocrew.org>
 <20230126105626.72CD922168@orac.inputplus.co.uk>
 <CAFZukdRGG6xWCyLsF_wiPsf5JsPFwRm7Hty=BbK2a4UjxaAyYQ@mail.gmail.com>
 <R5wOXkWssqxYtpNAmdT90jQP2qCwEv2mH-jCH6NHeIHzamFBCq7h63fwNQP1wEVfWBD56jJ19sO3PtMNxBFE3IzP68H4JxEffZWy2IqPoQk=@protonmail.com>
 <85d0ee98-3686-b305-49d7-536589b5d3db@e-bbes.com>
 <sgJhkmXbAnD_3JLUj0_MUbBGzA_ia3QRfjDAKK-bDIMeDr4Eyuykiio-CbQlFu-kmJrcNIYOomHnVmV92Ggs0R58ZoU07p1aMmyBiVh-4Hs=@protonmail.com>
 <CALMnNGjiz=UdEESuhueunE7F2tAr-5vo0415kqCq0HHww=Sw8A@mail.gmail.com>
Message-ID: <trps6IkQNk6NHdj3jGKWAs5ULO1mICiK8Vq683H7hvPy18oYsK2VS95YZW8rtk3Df7b5HicZA2wGRTaInv3Gi8ECffjIcJ4jD1WEvgopYnQ=@protonmail.com>

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 <akosela at andykosela.com> wrote:

> On Thursday, January 26, 2023, segaloco via TUHS <tuhs at tuhs.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230127/0f5dd59b/attachment.htm>

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: <E05C637A-6237-4000-9759-A73F267A94EC@josephholsten.com>
 <EB3088E9-8B90-4800-B094-F22B81A92029@eschatologist.net>
 <CAD2gp_QtUPmd78yAixvKK1wzPX67HKZXzU5cJnVUbcWtMounGQ@mail.gmail.com>
 <202301261804.30QI4sd9132510@darkstar.fourwinds.com>
 <c4b08a9d-a0eb-45f7-98c6-1e715cb58908@app.fastmail.com>
 <202301262138.30QLc6wY143500@darkstar.fourwinds.com>
 <620c709c-e8bb-401c-a60d-8869457caacd@app.fastmail.com>
 <20230127003612.dszdsftdjkobikx7@illithid>
Message-ID: <XET6lgWghxCKoMLPTp1nmIbCawOA0jydSuTJitrjE8yqnOlQVNEKjx141kFlu7QWmH8INTj7zz6kd_tBRKFo4T7l03kWa_udG464X7znBFE=@protonmail.com>

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

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: <XET6lgWghxCKoMLPTp1nmIbCawOA0jydSuTJitrjE8yqnOlQVNEKjx141kFlu7QWmH8INTj7zz6kd_tBRKFo4T7l03kWa_udG464X7znBFE=@protonmail.com>
References: <XET6lgWghxCKoMLPTp1nmIbCawOA0jydSuTJitrjE8yqnOlQVNEKjx141kFlu7QWmH8INTj7zz6kd_tBRKFo4T7l03kWa_udG464X7znBFE=@protonmail.com>
Message-ID: <F0C9F9F3-B9B2-41E4-8C0F-E291496AA263@pobox.com>

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 <tuhs at tuhs.org> 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


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: <F0C9F9F3-B9B2-41E4-8C0F-E291496AA263@pobox.com>
References: <XET6lgWghxCKoMLPTp1nmIbCawOA0jydSuTJitrjE8yqnOlQVNEKjx141kFlu7QWmH8INTj7zz6kd_tBRKFo4T7l03kWa_udG464X7znBFE=@protonmail.com>
 <F0C9F9F3-B9B2-41E4-8C0F-E291496AA263@pobox.com>
Message-ID: <CANCZdfrKN457+HL8pffE66LX_JME6Z5j045z=0yfTDERt9BiHA@mail.gmail.com>

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 <davida at pobox.com> 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 <tuhs at tuhs.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230126/1b023734/attachment.htm>

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: <trps6IkQNk6NHdj3jGKWAs5ULO1mICiK8Vq683H7hvPy18oYsK2VS95YZW8rtk3Df7b5HicZA2wGRTaInv3Gi8ECffjIcJ4jD1WEvgopYnQ=@protonmail.com>
References: <20230125203805.4762218C083@mercury.lcs.mit.edu>
 <CAC20D2NgrjJF-yGOBYFwr=rbRog+YFHF7tL_qozY=AZOf19-XA@mail.gmail.com>
 <7w8rhpdczd.fsf@junk.nocrew.org>
 <20230126105626.72CD922168@orac.inputplus.co.uk>
 <CAFZukdRGG6xWCyLsF_wiPsf5JsPFwRm7Hty=BbK2a4UjxaAyYQ@mail.gmail.com>
 <R5wOXkWssqxYtpNAmdT90jQP2qCwEv2mH-jCH6NHeIHzamFBCq7h63fwNQP1wEVfWBD56jJ19sO3PtMNxBFE3IzP68H4JxEffZWy2IqPoQk=@protonmail.com>
 <85d0ee98-3686-b305-49d7-536589b5d3db@e-bbes.com>
 <sgJhkmXbAnD_3JLUj0_MUbBGzA_ia3QRfjDAKK-bDIMeDr4Eyuykiio-CbQlFu-kmJrcNIYOomHnVmV92Ggs0R58ZoU07p1aMmyBiVh-4Hs=@protonmail.com>
 <CALMnNGjiz=UdEESuhueunE7F2tAr-5vo0415kqCq0HHww=Sw8A@mail.gmail.com>
 <trps6IkQNk6NHdj3jGKWAs5ULO1mICiK8Vq683H7hvPy18oYsK2VS95YZW8rtk3Df7b5HicZA2wGRTaInv3Gi8ECffjIcJ4jD1WEvgopYnQ=@protonmail.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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230126/4e3b36bb/attachment.htm>

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: <emad68cbf6-057e-4f49-8a43-2f8e2cd07490@e41218a5.com>

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" <lars at nocrew.org>
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: <emad68cbf6-057e-4f49-8a43-2f8e2cd07490@e41218a5.com>
References: <202301270853.30R8rif6014271@freefriends.org>
 <7w8rhobb87.fsf@junk.nocrew.org>
 <emad68cbf6-057e-4f49-8a43-2f8e2cd07490@e41218a5.com>
Message-ID: <CAD2gp_R5e_3UOjt46dZ-99_4s5=rpuGhJYbYNxSkWc-JWN_VyA@mail.gmail.com>

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 <ron at ronnatalie.com> 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" <lars at nocrew.org>
> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230127/4886cb67/attachment.htm>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230127/90ecf8ab/attachment.sig>

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>
 <CANCZdfq6O0U12=eM+Ox+U7qNwwPV2B4PLX7d=rWDmFgvNeODQQ@mail.gmail.com>
 <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: <CAFZukdRGG6xWCyLsF_wiPsf5JsPFwRm7Hty=BbK2a4UjxaAyYQ@mail.gmail.com>
References: <20230125203805.4762218C083@mercury.lcs.mit.edu>
 <CAC20D2NgrjJF-yGOBYFwr=rbRog+YFHF7tL_qozY=AZOf19-XA@mail.gmail.com>
 <7w8rhpdczd.fsf@junk.nocrew.org>
 <20230126105626.72CD922168@orac.inputplus.co.uk>
 <CAFZukdRGG6xWCyLsF_wiPsf5JsPFwRm7Hty=BbK2a4UjxaAyYQ@mail.gmail.com>
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>
 <CAC20D2NgrjJF-yGOBYFwr=rbRog+YFHF7tL_qozY=AZOf19-XA@mail.gmail.com>
 <7w8rhpdczd.fsf@junk.nocrew.org>
 <20230126105626.72CD922168@orac.inputplus.co.uk>
 <CAFZukdRGG6xWCyLsF_wiPsf5JsPFwRm7Hty=BbK2a4UjxaAyYQ@mail.gmail.com>
 <R5wOXkWssqxYtpNAmdT90jQP2qCwEv2mH-jCH6NHeIHzamFBCq7h63fwNQP1wEVfWBD56jJ19sO3PtMNxBFE3IzP68H4JxEffZWy2IqPoQk=@protonmail.com>
 <85d0ee98-3686-b305-49d7-536589b5d3db@e-bbes.com>
 <sgJhkmXbAnD_3JLUj0_MUbBGzA_ia3QRfjDAKK-bDIMeDr4Eyuykiio-CbQlFu-kmJrcNIYOomHnVmV92Ggs0R58ZoU07p1aMmyBiVh-4Hs=@protonmail.com>
 <CALMnNGjiz=UdEESuhueunE7F2tAr-5vo0415kqCq0HHww=Sw8A@mail.gmail.com>
 <trps6IkQNk6NHdj3jGKWAs5ULO1mICiK8Vq683H7hvPy18oYsK2VS95YZW8rtk3Df7b5HicZA2wGRTaInv3Gi8ECffjIcJ4jD1WEvgopYnQ=@protonmail.com>
 <45987281-a06d-810e-9689-5a8ae2c63a63@gmail.com>
Message-ID: <b5860440-6be7-662b-95f1-184a13b0bd74@case.edu>

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>
 <CAC20D2NgrjJF-yGOBYFwr=rbRog+YFHF7tL_qozY=AZOf19-XA@mail.gmail.com>
 <7w8rhpdczd.fsf@junk.nocrew.org>
 <20230126105626.72CD922168@orac.inputplus.co.uk>
 <CAFZukdRGG6xWCyLsF_wiPsf5JsPFwRm7Hty=BbK2a4UjxaAyYQ@mail.gmail.com>
 <R5wOXkWssqxYtpNAmdT90jQP2qCwEv2mH-jCH6NHeIHzamFBCq7h63fwNQP1wEVfWBD56jJ19sO3PtMNxBFE3IzP68H4JxEffZWy2IqPoQk=@protonmail.com>
 <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: <b5860440-6be7-662b-95f1-184a13b0bd74@case.edu>
References: <20230125203805.4762218C083@mercury.lcs.mit.edu>
 <CAC20D2NgrjJF-yGOBYFwr=rbRog+YFHF7tL_qozY=AZOf19-XA@mail.gmail.com>
 <7w8rhpdczd.fsf@junk.nocrew.org>
 <20230126105626.72CD922168@orac.inputplus.co.uk>
 <CAFZukdRGG6xWCyLsF_wiPsf5JsPFwRm7Hty=BbK2a4UjxaAyYQ@mail.gmail.com>
 <R5wOXkWssqxYtpNAmdT90jQP2qCwEv2mH-jCH6NHeIHzamFBCq7h63fwNQP1wEVfWBD56jJ19sO3PtMNxBFE3IzP68H4JxEffZWy2IqPoQk=@protonmail.com>
 <85d0ee98-3686-b305-49d7-536589b5d3db@e-bbes.com>
 <sgJhkmXbAnD_3JLUj0_MUbBGzA_ia3QRfjDAKK-bDIMeDr4Eyuykiio-CbQlFu-kmJrcNIYOomHnVmV92Ggs0R58ZoU07p1aMmyBiVh-4Hs=@protonmail.com>
 <CALMnNGjiz=UdEESuhueunE7F2tAr-5vo0415kqCq0HHww=Sw8A@mail.gmail.com>
 <trps6IkQNk6NHdj3jGKWAs5ULO1mICiK8Vq683H7hvPy18oYsK2VS95YZW8rtk3Df7b5HicZA2wGRTaInv3Gi8ECffjIcJ4jD1WEvgopYnQ=@protonmail.com>
 <45987281-a06d-810e-9689-5a8ae2c63a63@gmail.com>
 <b5860440-6be7-662b-95f1-184a13b0bd74@case.edu>
Message-ID: <em8b4c727d-b0d3-4fab-b179-0f2adc534684@e41218a5.com>


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: <em51b28e39-fc52-4413-bf90-90714aa71aa1@e41218a5.com>

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>
 <CAC20D2NgrjJF-yGOBYFwr=rbRog+YFHF7tL_qozY=AZOf19-XA@mail.gmail.com>
 <7w8rhpdczd.fsf@junk.nocrew.org>
 <20230126105626.72CD922168@orac.inputplus.co.uk>
 <CAFZukdRGG6xWCyLsF_wiPsf5JsPFwRm7Hty=BbK2a4UjxaAyYQ@mail.gmail.com>
 <20230127135651.A70482135B@orac.inputplus.co.uk>
Message-ID: <em6af30c94-79af-4384-ac32-6c7258d1cd77@e41218a5.com>

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 <ralph at inputplus.co.uk> 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>
 <CAC20D2NgrjJF-yGOBYFwr=rbRog+YFHF7tL_qozY=AZOf19-XA@mail.gmail.com>
 <7w8rhpdczd.fsf@junk.nocrew.org>
 <20230126105626.72CD922168@orac.inputplus.co.uk>
 <CAFZukdRGG6xWCyLsF_wiPsf5JsPFwRm7Hty=BbK2a4UjxaAyYQ@mail.gmail.com>
 <R5wOXkWssqxYtpNAmdT90jQP2qCwEv2mH-jCH6NHeIHzamFBCq7h63fwNQP1wEVfWBD56jJ19sO3PtMNxBFE3IzP68H4JxEffZWy2IqPoQk=@protonmail.com>
 <85d0ee98-3686-b305-49d7-536589b5d3db@e-bbes.com>
 <sgJhkmXbAnD_3JLUj0_MUbBGzA_ia3QRfjDAKK-bDIMeDr4Eyuykiio-CbQlFu-kmJrcNIYOomHnVmV92Ggs0R58ZoU07p1aMmyBiVh-4Hs=@protonmail.com>
 <CALMnNGjiz=UdEESuhueunE7F2tAr-5vo0415kqCq0HHww=Sw8A@mail.gmail.com>
 <trps6IkQNk6NHdj3jGKWAs5ULO1mICiK8Vq683H7hvPy18oYsK2VS95YZW8rtk3Df7b5HicZA2wGRTaInv3Gi8ECffjIcJ4jD1WEvgopYnQ=@protonmail.com>
 <45987281-a06d-810e-9689-5a8ae2c63a63@gmail.com>
Message-ID: <CAEoi9W7WyNDHLmr5BqLxyK3sQSX0VTU6FZG32z5n20O6iAzx8Q@mail.gmail.com>

On Thu, Jan 26, 2023 at 11:08 PM Will Senn <will.senn at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230127/9485b6a8/attachment.htm>

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: <emad68cbf6-057e-4f49-8a43-2f8e2cd07490@e41218a5.com>
References: <202301270853.30R8rif6014271@freefriends.org>
 <7w8rhobb87.fsf@junk.nocrew.org>
 <emad68cbf6-057e-4f49-8a43-2f8e2cd07490@e41218a5.com>
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: <em6af30c94-79af-4384-ac32-6c7258d1cd77@e41218a5.com>
References: <20230125203805.4762218C083@mercury.lcs.mit.edu>
 <CAC20D2NgrjJF-yGOBYFwr=rbRog+YFHF7tL_qozY=AZOf19-XA@mail.gmail.com>
 <7w8rhpdczd.fsf@junk.nocrew.org>
 <20230126105626.72CD922168@orac.inputplus.co.uk>
 <CAFZukdRGG6xWCyLsF_wiPsf5JsPFwRm7Hty=BbK2a4UjxaAyYQ@mail.gmail.com>
 <20230127135651.A70482135B@orac.inputplus.co.uk>
 <em6af30c94-79af-4384-ac32-6c7258d1cd77@e41218a5.com>
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: <CAEoi9W7WyNDHLmr5BqLxyK3sQSX0VTU6FZG32z5n20O6iAzx8Q@mail.gmail.com>
References: <20230125203805.4762218C083@mercury.lcs.mit.edu>
 <CAC20D2NgrjJF-yGOBYFwr=rbRog+YFHF7tL_qozY=AZOf19-XA@mail.gmail.com>
 <7w8rhpdczd.fsf@junk.nocrew.org>
 <20230126105626.72CD922168@orac.inputplus.co.uk>
 <CAFZukdRGG6xWCyLsF_wiPsf5JsPFwRm7Hty=BbK2a4UjxaAyYQ@mail.gmail.com>
 <R5wOXkWssqxYtpNAmdT90jQP2qCwEv2mH-jCH6NHeIHzamFBCq7h63fwNQP1wEVfWBD56jJ19sO3PtMNxBFE3IzP68H4JxEffZWy2IqPoQk=@protonmail.com>
 <85d0ee98-3686-b305-49d7-536589b5d3db@e-bbes.com>
 <sgJhkmXbAnD_3JLUj0_MUbBGzA_ia3QRfjDAKK-bDIMeDr4Eyuykiio-CbQlFu-kmJrcNIYOomHnVmV92Ggs0R58ZoU07p1aMmyBiVh-4Hs=@protonmail.com>
 <CALMnNGjiz=UdEESuhueunE7F2tAr-5vo0415kqCq0HHww=Sw8A@mail.gmail.com>
 <trps6IkQNk6NHdj3jGKWAs5ULO1mICiK8Vq683H7hvPy18oYsK2VS95YZW8rtk3Df7b5HicZA2wGRTaInv3Gi8ECffjIcJ4jD1WEvgopYnQ=@protonmail.com>
 <45987281-a06d-810e-9689-5a8ae2c63a63@gmail.com>
 <CAEoi9W7WyNDHLmr5BqLxyK3sQSX0VTU6FZG32z5n20O6iAzx8Q@mail.gmail.com>
Message-ID: <d9517190-265c-99ca-75bc-20087a3fa6d4@technologists.com>

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 <will.senn at gmail.com 
> <mailto:will.senn at gmail.com>> 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>
 <emad68cbf6-057e-4f49-8a43-2f8e2cd07490@e41218a5.com>
 <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>
 <emad68cbf6-057e-4f49-8a43-2f8e2cd07490@e41218a5.com>
 <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: <F9B7616E-F8A6-434D-BF9D-453BF6974727@planet.nl>
References: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl>
 <CAC20D2MAdyfD8Xv3RYL4xgt99OG2RpOrtbjvLP3hfpx8iutfBw@mail.gmail.com>
 <0778FF74-7DF5-4072-95F3-5FF5BEB4CC33@planet.nl>
 <BD0E1656-F491-40B9-B017-1205EB1CF1A2@iitbombay.org>
 <F9B7616E-F8A6-434D-BF9D-453BF6974727@planet.nl>
Message-ID: <E03D5C67-58A9-4F7F-927C-29060B6EAA32@planet.nl>


> On Jan 27, 2023, at 1:19 AM, Paul Ruizendaal <pnr at planet.nl> 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/ <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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230127/779ac46f/attachment.htm>

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: <E03D5C67-58A9-4F7F-927C-29060B6EAA32@planet.nl>
References: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl>
 <CAC20D2MAdyfD8Xv3RYL4xgt99OG2RpOrtbjvLP3hfpx8iutfBw@mail.gmail.com>
 <0778FF74-7DF5-4072-95F3-5FF5BEB4CC33@planet.nl>
 <BD0E1656-F491-40B9-B017-1205EB1CF1A2@iitbombay.org>
 <F9B7616E-F8A6-434D-BF9D-453BF6974727@planet.nl>
 <E03D5C67-58A9-4F7F-927C-29060B6EAA32@planet.nl>
Message-ID: <CANCZdfrB9dW82ngt45_rf5=yM0=QEPwCL8F44GiVV6wxu+hSbg@mail.gmail.com>

On Fri, Jan 27, 2023 at 10:16 AM Paul Ruizendaal via TUHS <tuhs at tuhs.org>
wrote:

>
> On Jan 27, 2023, at 1:19 AM, Paul Ruizendaal <pnr at planet.nl> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230127/248e350f/attachment.htm>

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: <CANCZdfrB9dW82ngt45_rf5=yM0=QEPwCL8F44GiVV6wxu+hSbg@mail.gmail.com>
References: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl>
 <CAC20D2MAdyfD8Xv3RYL4xgt99OG2RpOrtbjvLP3hfpx8iutfBw@mail.gmail.com>
 <0778FF74-7DF5-4072-95F3-5FF5BEB4CC33@planet.nl>
 <BD0E1656-F491-40B9-B017-1205EB1CF1A2@iitbombay.org>
 <F9B7616E-F8A6-434D-BF9D-453BF6974727@planet.nl>
 <E03D5C67-58A9-4F7F-927C-29060B6EAA32@planet.nl>
 <CANCZdfrB9dW82ngt45_rf5=yM0=QEPwCL8F44GiVV6wxu+hSbg@mail.gmail.com>
Message-ID: <CANCZdfoGULUtvTOi7caKPFtg_v25PyZL1PvYkkoT1AoPys=X4Q@mail.gmail.com>

On Fri, Jan 27, 2023 at 10:36 AM Warner Losh <imp at bsdimp.com> wrote:

>
>
> On Fri, Jan 27, 2023 at 10:16 AM Paul Ruizendaal via TUHS <tuhs at tuhs.org>
> wrote:
>
>>
>> On Jan 27, 2023, at 1:19 AM, Paul Ruizendaal <pnr at planet.nl> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230127/65c9cb91/attachment.htm>

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: <m24jsbkhbi.fsf@thuvia.hamartun.priv.no>

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: <m24jsbkhbi.fsf@thuvia.hamartun.priv.no>
References: <202301270853.30R8rif6014271@freefriends.org>
 <m24jsbkhbi.fsf@thuvia.hamartun.priv.no>
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 <tuhs at tuhs.org> 
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: <E03D5C67-58A9-4F7F-927C-29060B6EAA32@planet.nl>
References: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl>
 <CAC20D2MAdyfD8Xv3RYL4xgt99OG2RpOrtbjvLP3hfpx8iutfBw@mail.gmail.com>
 <0778FF74-7DF5-4072-95F3-5FF5BEB4CC33@planet.nl>
 <BD0E1656-F491-40B9-B017-1205EB1CF1A2@iitbombay.org>
 <F9B7616E-F8A6-434D-BF9D-453BF6974727@planet.nl>
 <E03D5C67-58A9-4F7F-927C-29060B6EAA32@planet.nl>
Message-ID: <CAFZukdSnQ4OSwNJSMEUW42zYJMQTR_-4ZKQ6v4P6u+3W+2290A@mail.gmail.com>

On Friday, January 27, 2023, Paul Ruizendaal via TUHS <tuhs at tuhs.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230127/f1187554/attachment-0001.htm>

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: <CANCZdfoGULUtvTOi7caKPFtg_v25PyZL1PvYkkoT1AoPys=X4Q@mail.gmail.com>
References: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl>
 <CAC20D2MAdyfD8Xv3RYL4xgt99OG2RpOrtbjvLP3hfpx8iutfBw@mail.gmail.com>
 <0778FF74-7DF5-4072-95F3-5FF5BEB4CC33@planet.nl>
 <BD0E1656-F491-40B9-B017-1205EB1CF1A2@iitbombay.org>
 <F9B7616E-F8A6-434D-BF9D-453BF6974727@planet.nl>
 <E03D5C67-58A9-4F7F-927C-29060B6EAA32@planet.nl>
 <CANCZdfrB9dW82ngt45_rf5=yM0=QEPwCL8F44GiVV6wxu+hSbg@mail.gmail.com>
 <CANCZdfoGULUtvTOi7caKPFtg_v25PyZL1PvYkkoT1AoPys=X4Q@mail.gmail.com>
Message-ID: <CAFH29tp_KugJtwaBVJjWE829sbW4Nka7_4dPNwtQ-AiOvt1OoQ@mail.gmail.com>

> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230127/7fca1219/attachment.htm>

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: <CAEoi9W5jU+EBo33DYG-jQ3z+qVabzxOfK7G+VZE_a6igkfDWEw@mail.gmail.com>
References: <3e272d72-b77a-d347-b5c3-7ed19482e5af@gmail.com>
 <3h5FEAegoTs6FrhHODiW-rBdB59dt_Rmr4G0PIw7flqaJLsmorgPsilm4f2aJkDud-qEljDjnCJcE1uY05Iw4HNQcyNG4W3wzVlLD0UZfLg=@protonmail.com>
 <CAFH29trXu_SGp-7xv6xqMc49tTeEuyJdKwP-Fyfe6BCrpGZ9nQ@mail.gmail.com>
 <Y9GIus/Iw21uvkFb@mit.edu>
 <CAEoi9W5jU+EBo33DYG-jQ3z+qVabzxOfK7G+VZE_a6igkfDWEw@mail.gmail.com>
Message-ID: <Y9NX8ZifVMsOkSFq@mit.edu>

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 <tytso at mit.edu> 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: <CAFH29tp_KugJtwaBVJjWE829sbW4Nka7_4dPNwtQ-AiOvt1OoQ@mail.gmail.com>
References: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl>
 <CAC20D2MAdyfD8Xv3RYL4xgt99OG2RpOrtbjvLP3hfpx8iutfBw@mail.gmail.com>
 <0778FF74-7DF5-4072-95F3-5FF5BEB4CC33@planet.nl>
 <BD0E1656-F491-40B9-B017-1205EB1CF1A2@iitbombay.org>
 <F9B7616E-F8A6-434D-BF9D-453BF6974727@planet.nl>
 <E03D5C67-58A9-4F7F-927C-29060B6EAA32@planet.nl>
 <CANCZdfrB9dW82ngt45_rf5=yM0=QEPwCL8F44GiVV6wxu+hSbg@mail.gmail.com>
 <CANCZdfoGULUtvTOi7caKPFtg_v25PyZL1PvYkkoT1AoPys=X4Q@mail.gmail.com>
 <CAFH29tp_KugJtwaBVJjWE829sbW4Nka7_4dPNwtQ-AiOvt1OoQ@mail.gmail.com>
Message-ID: <CANCZdfrgxehRUB-pdd4BaZdVf23s9sk1sNMwQ2MJ1GOmQb7jOA@mail.gmail.com>

On Fri, Jan 27, 2023 at 10:45 AM Rich Salz <rich.salz at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230127/dae6b662/attachment.htm>

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: <Y9NX8ZifVMsOkSFq@mit.edu>
References: <3e272d72-b77a-d347-b5c3-7ed19482e5af@gmail.com>
 <3h5FEAegoTs6FrhHODiW-rBdB59dt_Rmr4G0PIw7flqaJLsmorgPsilm4f2aJkDud-qEljDjnCJcE1uY05Iw4HNQcyNG4W3wzVlLD0UZfLg=@protonmail.com>
 <CAFH29trXu_SGp-7xv6xqMc49tTeEuyJdKwP-Fyfe6BCrpGZ9nQ@mail.gmail.com>
 <Y9GIus/Iw21uvkFb@mit.edu>
 <CAEoi9W5jU+EBo33DYG-jQ3z+qVabzxOfK7G+VZE_a6igkfDWEw@mail.gmail.com>
 <Y9NX8ZifVMsOkSFq@mit.edu>
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 <tytso at mit.edu> 
Sent: 26 January 2023 23:50
To: Dan Cross <crossd at gmail.com>
Cc: segaloco <segaloco at protonmail.com>; TUHS main list <tuhs at tuhs.org>
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 <tytso at mit.edu> 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>
 <CAFH29trXu_SGp-7xv6xqMc49tTeEuyJdKwP-Fyfe6BCrpGZ9nQ@mail.gmail.com>
 <Y9GIus/Iw21uvkFb@mit.edu>
 <CAEoi9W5jU+EBo33DYG-jQ3z+qVabzxOfK7G+VZE_a6igkfDWEw@mail.gmail.com>
 <Y9NX8ZifVMsOkSFq@mit.edu> <08b201d93279$fbb2a200$f317e600$@henare.com>
Message-ID: <df5f5110-a682-bd9f-c5b0-123463dbf419@technologists.com>

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 <tytso at mit.edu>
> Sent: 26 January 2023 23:50
> To: Dan Cross <crossd at gmail.com>
> Cc: segaloco <segaloco at protonmail.com>; TUHS main list <tuhs at tuhs.org>
> 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 <tytso at mit.edu> 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>
 <m24jsbkhbi.fsf@thuvia.hamartun.priv.no>
 <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: <em6af30c94-79af-4384-ac32-6c7258d1cd77@e41218a5.com>
References: <20230125203805.4762218C083@mercury.lcs.mit.edu>
 <CAC20D2NgrjJF-yGOBYFwr=rbRog+YFHF7tL_qozY=AZOf19-XA@mail.gmail.com>
 <7w8rhpdczd.fsf@junk.nocrew.org>
 <20230126105626.72CD922168@orac.inputplus.co.uk>
 <CAFZukdRGG6xWCyLsF_wiPsf5JsPFwRm7Hty=BbK2a4UjxaAyYQ@mail.gmail.com>
 <20230127135651.A70482135B@orac.inputplus.co.uk>
 <em6af30c94-79af-4384-ac32-6c7258d1cd77@e41218a5.com>
Message-ID: <CAJq=PCUbBT0GRoc4_QAGxy1x8d59V-QsirOze6fz=9dUv3gaPw@mail.gmail.com>

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 <ron at ronnatalie.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230127/096f1b0b/attachment.htm>

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: <CAK7dMtB8ZWT6_WSaY12Ti_Qo3Z=_fUNHT07+1kY795X+6REjYQ@mail.gmail.com>

On Fri, Jan 27, 2023 at 1:54 AM <arnold at skeeve.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230127/1fcf3fc7/attachment.htm>

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: <CAJq=PCUbBT0GRoc4_QAGxy1x8d59V-QsirOze6fz=9dUv3gaPw@mail.gmail.com>
References: <20230125203805.4762218C083@mercury.lcs.mit.edu>
 <CAC20D2NgrjJF-yGOBYFwr=rbRog+YFHF7tL_qozY=AZOf19-XA@mail.gmail.com>
 <7w8rhpdczd.fsf@junk.nocrew.org>
 <20230126105626.72CD922168@orac.inputplus.co.uk>
 <CAFZukdRGG6xWCyLsF_wiPsf5JsPFwRm7Hty=BbK2a4UjxaAyYQ@mail.gmail.com>
 <20230127135651.A70482135B@orac.inputplus.co.uk>
 <em6af30c94-79af-4384-ac32-6c7258d1cd77@e41218a5.com>
 <CAJq=PCUbBT0GRoc4_QAGxy1x8d59V-QsirOze6fz=9dUv3gaPw@mail.gmail.com>
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 <ron at ronnatalie.com> 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>
 <CAC20D2NgrjJF-yGOBYFwr=rbRog+YFHF7tL_qozY=AZOf19-XA@mail.gmail.com>
 <7w8rhpdczd.fsf@junk.nocrew.org>
 <20230126105626.72CD922168@orac.inputplus.co.uk>
 <CAFZukdRGG6xWCyLsF_wiPsf5JsPFwRm7Hty=BbK2a4UjxaAyYQ@mail.gmail.com>
 <20230127135651.A70482135B@orac.inputplus.co.uk>
 <em6af30c94-79af-4384-ac32-6c7258d1cd77@e41218a5.com>
 <CAJq=PCUbBT0GRoc4_QAGxy1x8d59V-QsirOze6fz=9dUv3gaPw@mail.gmail.com>
 <20230128021841.GG15592@mcvoy.com>
Message-ID: <CAJq=PCU3MQ3WKi+XaW-cXeaiUR2Sa4nYdXrcp3CjcmCA81mPUQ@mail.gmail.com>

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 <lm at mcvoy.com> 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 <ron at ronnatalie.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230127/ffc93b85/attachment.htm>

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: <CANCZdfrgxehRUB-pdd4BaZdVf23s9sk1sNMwQ2MJ1GOmQb7jOA@mail.gmail.com>
 (Warner Losh's message of "Fri, 27 Jan 2023 10:54:33 -0700")
References: <0C5D8AF8-BAB2-48B5-854B-34E3A949DE50@planet.nl>
 <CAC20D2MAdyfD8Xv3RYL4xgt99OG2RpOrtbjvLP3hfpx8iutfBw@mail.gmail.com>
 <0778FF74-7DF5-4072-95F3-5FF5BEB4CC33@planet.nl>
 <BD0E1656-F491-40B9-B017-1205EB1CF1A2@iitbombay.org>
 <F9B7616E-F8A6-434D-BF9D-453BF6974727@planet.nl>
 <E03D5C67-58A9-4F7F-927C-29060B6EAA32@planet.nl>
 <CANCZdfrB9dW82ngt45_rf5=yM0=QEPwCL8F44GiVV6wxu+hSbg@mail.gmail.com>
 <CANCZdfoGULUtvTOi7caKPFtg_v25PyZL1PvYkkoT1AoPys=X4Q@mail.gmail.com>
 <CAFH29tp_KugJtwaBVJjWE829sbW4Nka7_4dPNwtQ-AiOvt1OoQ@mail.gmail.com>
 <CANCZdfrgxehRUB-pdd4BaZdVf23s9sk1sNMwQ2MJ1GOmQb7jOA@mail.gmail.com>
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: <CAK7dMtB8ZWT6_WSaY12Ti_Qo3Z=_fUNHT07+1kY795X+6REjYQ@mail.gmail.com>
References: <202301270853.30R8rif6014271@freefriends.org>
 <CAK7dMtB8ZWT6_WSaY12Ti_Qo3Z=_fUNHT07+1kY795X+6REjYQ@mail.gmail.com>
Message-ID: <CALMnNGgBGW=jw65SX6hprkiej4_svquopCf3uwdHk=Z7Baxp=w@mail.gmail.com>

On Saturday, January 28, 2023, Kevin Bowling <kevin.bowling at kev009.com>
wrote:

>
>
> On Fri, Jan 27, 2023 at 1:54 AM <arnold at skeeve.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230128/bdd736ad/attachment.htm>

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>
 <CAC20D2MAdyfD8Xv3RYL4xgt99OG2RpOrtbjvLP3hfpx8iutfBw@mail.gmail.com>
 <0778FF74-7DF5-4072-95F3-5FF5BEB4CC33@planet.nl>
 <BD0E1656-F491-40B9-B017-1205EB1CF1A2@iitbombay.org>
 <F9B7616E-F8A6-434D-BF9D-453BF6974727@planet.nl>
 <E03D5C67-58A9-4F7F-927C-29060B6EAA32@planet.nl>
 <CANCZdfrB9dW82ngt45_rf5=yM0=QEPwCL8F44GiVV6wxu+hSbg@mail.gmail.com>
 <CANCZdfoGULUtvTOi7caKPFtg_v25PyZL1PvYkkoT1AoPys=X4Q@mail.gmail.com>
 <CAFH29tp_KugJtwaBVJjWE829sbW4Nka7_4dPNwtQ-AiOvt1OoQ@mail.gmail.com>
 <CANCZdfrgxehRUB-pdd4BaZdVf23s9sk1sNMwQ2MJ1GOmQb7jOA@mail.gmail.com>
 <7wpmaz9g2p.fsf@junk.nocrew.org>
Message-ID: <697E8876-C2A9-4FE6-A2F7-B4DCEC3BA2C7@planet.nl>


> On 28 Jan 2023, at 10:14, Lars Brinkhoff <lars at nocrew.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230128/0778bcda/attachment.htm>

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>
 <CAC20D2MAdyfD8Xv3RYL4xgt99OG2RpOrtbjvLP3hfpx8iutfBw@mail.gmail.com>
 <0778FF74-7DF5-4072-95F3-5FF5BEB4CC33@planet.nl>
 <BD0E1656-F491-40B9-B017-1205EB1CF1A2@iitbombay.org>
 <F9B7616E-F8A6-434D-BF9D-453BF6974727@planet.nl>
 <E03D5C67-58A9-4F7F-927C-29060B6EAA32@planet.nl>
 <CANCZdfrB9dW82ngt45_rf5=yM0=QEPwCL8F44GiVV6wxu+hSbg@mail.gmail.com>
 <CANCZdfoGULUtvTOi7caKPFtg_v25PyZL1PvYkkoT1AoPys=X4Q@mail.gmail.com>
 <CAFH29tp_KugJtwaBVJjWE829sbW4Nka7_4dPNwtQ-AiOvt1OoQ@mail.gmail.com>
 <CANCZdfrgxehRUB-pdd4BaZdVf23s9sk1sNMwQ2MJ1GOmQb7jOA@mail.gmail.com>
 <7wpmaz9g2p.fsf@junk.nocrew.org>
 <697E8876-C2A9-4FE6-A2F7-B4DCEC3BA2C7@planet.nl>
Message-ID: <CANCZdfq-g3Tj5YnRcyD7pdHpYEaBL0gohfShuSAQ0+i_i-eURg@mail.gmail.com>

On Sat, Jan 28, 2023, 4:05 AM Paul Ruizendaal <pnr at planet.nl> wrote:

>
> > On 28 Jan 2023, at 10:14, Lars Brinkhoff <lars at nocrew.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230128/4653a8c3/attachment-0001.htm>

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: <CALMnNGgBGW=jw65SX6hprkiej4_svquopCf3uwdHk=Z7Baxp=w@mail.gmail.com>
References: <202301270853.30R8rif6014271@freefriends.org>
 <CAK7dMtB8ZWT6_WSaY12Ti_Qo3Z=_fUNHT07+1kY795X+6REjYQ@mail.gmail.com>
 <CALMnNGgBGW=jw65SX6hprkiej4_svquopCf3uwdHk=Z7Baxp=w@mail.gmail.com>
Message-ID: <CAD2gp_Tr2bXnFNEJ1xtSCg-Hv1wWLTS2=C_FJ8De_QasPXtG9g@mail.gmail.com>

>
>
>>> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230128/302708ef/attachment.htm>

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>
 <CAC20D2MAdyfD8Xv3RYL4xgt99OG2RpOrtbjvLP3hfpx8iutfBw@mail.gmail.com>
 <0778FF74-7DF5-4072-95F3-5FF5BEB4CC33@planet.nl>
 <BD0E1656-F491-40B9-B017-1205EB1CF1A2@iitbombay.org>
 <F9B7616E-F8A6-434D-BF9D-453BF6974727@planet.nl>
 <E03D5C67-58A9-4F7F-927C-29060B6EAA32@planet.nl>
 <CANCZdfrB9dW82ngt45_rf5=yM0=QEPwCL8F44GiVV6wxu+hSbg@mail.gmail.com>
 <CANCZdfoGULUtvTOi7caKPFtg_v25PyZL1PvYkkoT1AoPys=X4Q@mail.gmail.com>
 <CAFH29tp_KugJtwaBVJjWE829sbW4Nka7_4dPNwtQ-AiOvt1OoQ@mail.gmail.com>
 <CANCZdfrgxehRUB-pdd4BaZdVf23s9sk1sNMwQ2MJ1GOmQb7jOA@mail.gmail.com>
 <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: <CAKH6PiVARZufGGa5CgvxiFreLOZO7TY-vht8KDVqtdOUmA-PPQ@mail.gmail.com>

> * 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>
 <CAC20D2NgrjJF-yGOBYFwr=rbRog+YFHF7tL_qozY=AZOf19-XA@mail.gmail.com>
 <7w8rhpdczd.fsf@junk.nocrew.org>
 <20230126105626.72CD922168@orac.inputplus.co.uk>
 <CAFZukdRGG6xWCyLsF_wiPsf5JsPFwRm7Hty=BbK2a4UjxaAyYQ@mail.gmail.com>
 <20230127135651.A70482135B@orac.inputplus.co.uk>
 <em6af30c94-79af-4384-ac32-6c7258d1cd77@e41218a5.com>
 <20230127161016.GF5393@mcvoy.com>
Message-ID: <alpine.BSF.2.21.9999.2301290902050.61978@aneurin.horsfall.org>

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: <alpine.BSF.2.21.9999.2301290902050.61978@aneurin.horsfall.org>
References: <20230125203805.4762218C083@mercury.lcs.mit.edu>
 <CAC20D2NgrjJF-yGOBYFwr=rbRog+YFHF7tL_qozY=AZOf19-XA@mail.gmail.com>
 <7w8rhpdczd.fsf@junk.nocrew.org>
 <20230126105626.72CD922168@orac.inputplus.co.uk>
 <CAFZukdRGG6xWCyLsF_wiPsf5JsPFwRm7Hty=BbK2a4UjxaAyYQ@mail.gmail.com>
 <20230127135651.A70482135B@orac.inputplus.co.uk>
 <em6af30c94-79af-4384-ac32-6c7258d1cd77@e41218a5.com>
 <20230127161016.GF5393@mcvoy.com>
 <alpine.BSF.2.21.9999.2301290902050.61978@aneurin.horsfall.org>
Message-ID: <CAK7dMtCGLg47RdZ5n028t9OA=A_=K+twRpZYnRcsocLm9PdQMg@mail.gmail.com>

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 <dave at horsfall.org> 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>
 <CAC20D2MAdyfD8Xv3RYL4xgt99OG2RpOrtbjvLP3hfpx8iutfBw@mail.gmail.com>
 <0778FF74-7DF5-4072-95F3-5FF5BEB4CC33@planet.nl>
 <BD0E1656-F491-40B9-B017-1205EB1CF1A2@iitbombay.org>
 <F9B7616E-F8A6-434D-BF9D-453BF6974727@planet.nl>
 <E03D5C67-58A9-4F7F-927C-29060B6EAA32@planet.nl>
 <CANCZdfrB9dW82ngt45_rf5=yM0=QEPwCL8F44GiVV6wxu+hSbg@mail.gmail.com>
 <CANCZdfoGULUtvTOi7caKPFtg_v25PyZL1PvYkkoT1AoPys=X4Q@mail.gmail.com>
 <CAFH29tp_KugJtwaBVJjWE829sbW4Nka7_4dPNwtQ-AiOvt1OoQ@mail.gmail.com>
 <CANCZdfrgxehRUB-pdd4BaZdVf23s9sk1sNMwQ2MJ1GOmQb7jOA@mail.gmail.com>
 <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: <m24jsbkhbi.fsf@thuvia.hamartun.priv.no>
References: <202301270853.30R8rif6014271@freefriends.org>
 <m24jsbkhbi.fsf@thuvia.hamartun.priv.no>
Message-ID: <202301290900.30T90Q9b022673@freefriends.org>

Tom Ivar Helbekkmo <tih at hamartun.priv.no> 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: <CAK7dMtCGLg47RdZ5n028t9OA=A_=K+twRpZYnRcsocLm9PdQMg@mail.gmail.com>
References: <20230125203805.4762218C083@mercury.lcs.mit.edu>
 <CAC20D2NgrjJF-yGOBYFwr=rbRog+YFHF7tL_qozY=AZOf19-XA@mail.gmail.com>
 <7w8rhpdczd.fsf@junk.nocrew.org>
 <20230126105626.72CD922168@orac.inputplus.co.uk>
 <CAFZukdRGG6xWCyLsF_wiPsf5JsPFwRm7Hty=BbK2a4UjxaAyYQ@mail.gmail.com>
 <20230127135651.A70482135B@orac.inputplus.co.uk>
 <em6af30c94-79af-4384-ac32-6c7258d1cd77@e41218a5.com>
 <20230127161016.GF5393@mcvoy.com>
 <alpine.BSF.2.21.9999.2301290902050.61978@aneurin.horsfall.org>
 <CAK7dMtCGLg47RdZ5n028t9OA=A_=K+twRpZYnRcsocLm9PdQMg@mail.gmail.com>
Message-ID: <b6a29a15-c9ba-40e7-0778-786d03c0814b@e-bbes.com>

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: <CANCZdfrnO-a7bUGRVHtGLdkGFYeaNCyTzwdR1tO+keKkmKf9cA@mail.gmail.com>
References: <CAP6exYK021bpG1epDf+6YBvXUKpN4PoCLYwK1CE1OJ16Pcskgg@mail.gmail.com>
 <CAC20D2ODxrRGZ6sYyMedNdR8wphvkVW3H4j_Dnce-axELdX_Mg@mail.gmail.com>
 <CANCZdfpjrJUDPv2g7-10SrdkgjiacAvp95PVvJ=Ob2h8m8R=FQ@mail.gmail.com>
 <CANCZdfr4zkmFKgqBZKrOL9z5FbFsWSjHpU3vYu-2T3Y+xNat2g@mail.gmail.com>
 <CAC20D2MUWZjQw1O=OGgtf_g8VYoE4ZN8cPyH8FFXaToPuYuZUQ@mail.gmail.com>
 <CANCZdfp2SK+gHNgoybVd3asYfLkNiwt539zdNrgwPSKzK=j38Q@mail.gmail.com>
 <CANCZdfrnO-a7bUGRVHtGLdkGFYeaNCyTzwdR1tO+keKkmKf9cA@mail.gmail.com>
Message-ID: <CANCZdfqxAZRt-KUEeqqmpg4Q-D39cDQmqjQVSoQoJVYszSUa-A@mail.gmail.com>

On Sun, Jan 22, 2023 at 2:23 PM Warner Losh <imp at bsdimp.com> wrote:

>
>
> On Sat, Jan 21, 2023 at 11:37 AM Warner Losh <imp at bsdimp.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230129/aed1b3ef/attachment.htm>

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: <CANCZdfqxAZRt-KUEeqqmpg4Q-D39cDQmqjQVSoQoJVYszSUa-A@mail.gmail.com>
References: <CAP6exYK021bpG1epDf+6YBvXUKpN4PoCLYwK1CE1OJ16Pcskgg@mail.gmail.com>
 <CAC20D2ODxrRGZ6sYyMedNdR8wphvkVW3H4j_Dnce-axELdX_Mg@mail.gmail.com>
 <CANCZdfpjrJUDPv2g7-10SrdkgjiacAvp95PVvJ=Ob2h8m8R=FQ@mail.gmail.com>
 <CANCZdfr4zkmFKgqBZKrOL9z5FbFsWSjHpU3vYu-2T3Y+xNat2g@mail.gmail.com>
 <CAC20D2MUWZjQw1O=OGgtf_g8VYoE4ZN8cPyH8FFXaToPuYuZUQ@mail.gmail.com>
 <CANCZdfp2SK+gHNgoybVd3asYfLkNiwt539zdNrgwPSKzK=j38Q@mail.gmail.com>
 <CANCZdfrnO-a7bUGRVHtGLdkGFYeaNCyTzwdR1tO+keKkmKf9cA@mail.gmail.com>
 <CANCZdfqxAZRt-KUEeqqmpg4Q-D39cDQmqjQVSoQoJVYszSUa-A@mail.gmail.com>
Message-ID: <emfc4c1646-a458-4e3c-9e39-ca09e9935f74@e41218a5.com>



>"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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230129/b8600b80/attachment.htm>

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: <em2c3601ce-e65f-4a94-bd0b-2c4ddbb681fd@e41218a5.com>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230129/1a4d72b9/attachment.htm>

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: <emfc4c1646-a458-4e3c-9e39-ca09e9935f74@e41218a5.com>
References: <CAP6exYK021bpG1epDf+6YBvXUKpN4PoCLYwK1CE1OJ16Pcskgg@mail.gmail.com>
 <CAC20D2ODxrRGZ6sYyMedNdR8wphvkVW3H4j_Dnce-axELdX_Mg@mail.gmail.com>
 <CANCZdfpjrJUDPv2g7-10SrdkgjiacAvp95PVvJ=Ob2h8m8R=FQ@mail.gmail.com>
 <CANCZdfr4zkmFKgqBZKrOL9z5FbFsWSjHpU3vYu-2T3Y+xNat2g@mail.gmail.com>
 <CAC20D2MUWZjQw1O=OGgtf_g8VYoE4ZN8cPyH8FFXaToPuYuZUQ@mail.gmail.com>
 <CANCZdfp2SK+gHNgoybVd3asYfLkNiwt539zdNrgwPSKzK=j38Q@mail.gmail.com>
 <CANCZdfrnO-a7bUGRVHtGLdkGFYeaNCyTzwdR1tO+keKkmKf9cA@mail.gmail.com>
 <CANCZdfqxAZRt-KUEeqqmpg4Q-D39cDQmqjQVSoQoJVYszSUa-A@mail.gmail.com>
 <emfc4c1646-a458-4e3c-9e39-ca09e9935f74@e41218a5.com>
Message-ID: <CANCZdfp5PpSjbALMtC39=pZcfWxVrGpAfN8OnD7bYLt-WS3-zA@mail.gmail.com>

On Sun, Jan 29, 2023, 12:21 PM Ron Natalie <ron at ronnatalie.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230129/ee0367a1/attachment.htm>

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>
 <CAC20D2MAdyfD8Xv3RYL4xgt99OG2RpOrtbjvLP3hfpx8iutfBw@mail.gmail.com>
 <0778FF74-7DF5-4072-95F3-5FF5BEB4CC33@planet.nl>
 <BD0E1656-F491-40B9-B017-1205EB1CF1A2@iitbombay.org>
 <F9B7616E-F8A6-434D-BF9D-453BF6974727@planet.nl>
 <E03D5C67-58A9-4F7F-927C-29060B6EAA32@planet.nl>
 <CANCZdfrB9dW82ngt45_rf5=yM0=QEPwCL8F44GiVV6wxu+hSbg@mail.gmail.com>
 <CANCZdfoGULUtvTOi7caKPFtg_v25PyZL1PvYkkoT1AoPys=X4Q@mail.gmail.com>
 <CAFH29tp_KugJtwaBVJjWE829sbW4Nka7_4dPNwtQ-AiOvt1OoQ@mail.gmail.com>
 <CANCZdfrgxehRUB-pdd4BaZdVf23s9sk1sNMwQ2MJ1GOmQb7jOA@mail.gmail.com>
 <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 <lars at nocrew.org> 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: <F9AE1B6F-5760-481E-BF5D-69504709A6AE@kdbarto.org>

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: <em2c3601ce-e65f-4a94-bd0b-2c4ddbb681fd@e41218a5.com>
References: <em2c3601ce-e65f-4a94-bd0b-2c4ddbb681fd@e41218a5.com>
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 <ron at ronnatalie.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230129/6cbc8907/attachment.htm>

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: <B5198799-9629-4CB4-9EE5-39FABEFF35D7@planet.nl>


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: <B5198799-9629-4CB4-9EE5-39FABEFF35D7@planet.nl>
References: <B5198799-9629-4CB4-9EE5-39FABEFF35D7@planet.nl>
Message-ID: <Y9cOYXxwQ+nr2LwN@largo.jsg.id.au>

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: <emfc4c1646-a458-4e3c-9e39-ca09e9935f74@e41218a5.com>
References: <CAP6exYK021bpG1epDf+6YBvXUKpN4PoCLYwK1CE1OJ16Pcskgg@mail.gmail.com>
 <CAC20D2ODxrRGZ6sYyMedNdR8wphvkVW3H4j_Dnce-axELdX_Mg@mail.gmail.com>
 <CANCZdfpjrJUDPv2g7-10SrdkgjiacAvp95PVvJ=Ob2h8m8R=FQ@mail.gmail.com>
 <CANCZdfr4zkmFKgqBZKrOL9z5FbFsWSjHpU3vYu-2T3Y+xNat2g@mail.gmail.com>
 <CAC20D2MUWZjQw1O=OGgtf_g8VYoE4ZN8cPyH8FFXaToPuYuZUQ@mail.gmail.com>
 <CANCZdfp2SK+gHNgoybVd3asYfLkNiwt539zdNrgwPSKzK=j38Q@mail.gmail.com>
 <CANCZdfrnO-a7bUGRVHtGLdkGFYeaNCyTzwdR1tO+keKkmKf9cA@mail.gmail.com>
 <CANCZdfqxAZRt-KUEeqqmpg4Q-D39cDQmqjQVSoQoJVYszSUa-A@mail.gmail.com>
 <emfc4c1646-a458-4e3c-9e39-ca09e9935f74@e41218a5.com>
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: <em2c3601ce-e65f-4a94-bd0b-2c4ddbb681fd@e41218a5.com>
 <2D760346-E44F-4248-9122-19A5E4EDA42D@iitbombay.org>
Message-ID: <CANCZdfo0++qzrv+zQXLurXbwedh2+_zVrjpNGd+Vy5PSxpugDA@mail.gmail.com>

On Sun, Jan 29, 2023, 3:59 PM Bakul Shah <bakul at iitbombay.org> 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 <ron at ronnatalie.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230129/a99f4980/attachment.htm>

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: <CANCZdfo0++qzrv+zQXLurXbwedh2+_zVrjpNGd+Vy5PSxpugDA@mail.gmail.com>
References: <em2c3601ce-e65f-4a94-bd0b-2c4ddbb681fd@e41218a5.com>
 <2D760346-E44F-4248-9122-19A5E4EDA42D@iitbombay.org>
 <CANCZdfo0++qzrv+zQXLurXbwedh2+_zVrjpNGd+Vy5PSxpugDA@mail.gmail.com>
Message-ID: <29FC4361-59FF-4F1B-843E-CF88D65E416C@iitbombay.org>



> On Jan 29, 2023, at 4:45 PM, Warner Losh <imp at bsdimp.com> wrote:
> 
> 
> 
> On Sun, Jan 29, 2023, 3:59 PM Bakul Shah <bakul at iitbombay.org <mailto:bakul at iitbombay.org>> 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 <ron at ronnatalie.com <mailto:ron at ronnatalie.com>> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230129/f7ddf361/attachment.htm>

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: <CAP6exYK021bpG1epDf+6YBvXUKpN4PoCLYwK1CE1OJ16Pcskgg@mail.gmail.com>
 <CAC20D2ODxrRGZ6sYyMedNdR8wphvkVW3H4j_Dnce-axELdX_Mg@mail.gmail.com>
 <CANCZdfpjrJUDPv2g7-10SrdkgjiacAvp95PVvJ=Ob2h8m8R=FQ@mail.gmail.com>
 <CANCZdfr4zkmFKgqBZKrOL9z5FbFsWSjHpU3vYu-2T3Y+xNat2g@mail.gmail.com>
 <CAC20D2MUWZjQw1O=OGgtf_g8VYoE4ZN8cPyH8FFXaToPuYuZUQ@mail.gmail.com>
 <CANCZdfp2SK+gHNgoybVd3asYfLkNiwt539zdNrgwPSKzK=j38Q@mail.gmail.com>
 <CANCZdfrnO-a7bUGRVHtGLdkGFYeaNCyTzwdR1tO+keKkmKf9cA@mail.gmail.com>
 <CANCZdfqxAZRt-KUEeqqmpg4Q-D39cDQmqjQVSoQoJVYszSUa-A@mail.gmail.com>
 <emfc4c1646-a458-4e3c-9e39-ca09e9935f74@e41218a5.com>
 <202301300025.30U0PHEh022103@ultimate.com>
Message-ID: <CANCZdfoW5ZnGHFkKjuaLFc6_i1WUN9nin84VQ22CP3oN5k2UAw@mail.gmail.com>

On Sun, Jan 29, 2023, 5:25 PM Phil Budne <phil at ultimate.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230129/f44e00a0/attachment.htm>

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: <B5198799-9629-4CB4-9EE5-39FABEFF35D7@planet.nl>
References: <B5198799-9629-4CB4-9EE5-39FABEFF35D7@planet.nl>
Message-ID: <Y9dUaQf+btXgTttl@largo.jsg.id.au>

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: <CAKH6PiVARZufGGa5CgvxiFreLOZO7TY-vht8KDVqtdOUmA-PPQ@mail.gmail.com>
References: <CAKH6PiVARZufGGa5CgvxiFreLOZO7TY-vht8KDVqtdOUmA-PPQ@mail.gmail.com>
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: <CANCZdfp5PpSjbALMtC39=pZcfWxVrGpAfN8OnD7bYLt-WS3-zA@mail.gmail.com>
References: <CAP6exYK021bpG1epDf+6YBvXUKpN4PoCLYwK1CE1OJ16Pcskgg@mail.gmail.com>
 <CAC20D2ODxrRGZ6sYyMedNdR8wphvkVW3H4j_Dnce-axELdX_Mg@mail.gmail.com>
 <CANCZdfpjrJUDPv2g7-10SrdkgjiacAvp95PVvJ=Ob2h8m8R=FQ@mail.gmail.com>
 <CANCZdfr4zkmFKgqBZKrOL9z5FbFsWSjHpU3vYu-2T3Y+xNat2g@mail.gmail.com>
 <CAC20D2MUWZjQw1O=OGgtf_g8VYoE4ZN8cPyH8FFXaToPuYuZUQ@mail.gmail.com>
 <CANCZdfp2SK+gHNgoybVd3asYfLkNiwt539zdNrgwPSKzK=j38Q@mail.gmail.com>
 <CANCZdfrnO-a7bUGRVHtGLdkGFYeaNCyTzwdR1tO+keKkmKf9cA@mail.gmail.com>
 <CANCZdfqxAZRt-KUEeqqmpg4Q-D39cDQmqjQVSoQoJVYszSUa-A@mail.gmail.com>
 <emfc4c1646-a458-4e3c-9e39-ca09e9935f74@e41218a5.com>
 <CANCZdfp5PpSjbALMtC39=pZcfWxVrGpAfN8OnD7bYLt-WS3-zA@mail.gmail.com>
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: <CAP6exYK021bpG1epDf+6YBvXUKpN4PoCLYwK1CE1OJ16Pcskgg@mail.gmail.com>
 <CAC20D2ODxrRGZ6sYyMedNdR8wphvkVW3H4j_Dnce-axELdX_Mg@mail.gmail.com>
 <CANCZdfpjrJUDPv2g7-10SrdkgjiacAvp95PVvJ=Ob2h8m8R=FQ@mail.gmail.com>
 <CANCZdfr4zkmFKgqBZKrOL9z5FbFsWSjHpU3vYu-2T3Y+xNat2g@mail.gmail.com>
 <CAC20D2MUWZjQw1O=OGgtf_g8VYoE4ZN8cPyH8FFXaToPuYuZUQ@mail.gmail.com>
 <CANCZdfp2SK+gHNgoybVd3asYfLkNiwt539zdNrgwPSKzK=j38Q@mail.gmail.com>
 <CANCZdfrnO-a7bUGRVHtGLdkGFYeaNCyTzwdR1tO+keKkmKf9cA@mail.gmail.com>
 <CANCZdfqxAZRt-KUEeqqmpg4Q-D39cDQmqjQVSoQoJVYszSUa-A@mail.gmail.com>
 <emfc4c1646-a458-4e3c-9e39-ca09e9935f74@e41218a5.com>
 <CANCZdfp5PpSjbALMtC39=pZcfWxVrGpAfN8OnD7bYLt-WS3-zA@mail.gmail.com>
 <202301300750.30U7oQTh013304@freefriends.org>
Message-ID: <CAKzdPgzUCv5yAyeUQAB36-ar_PEpTkgiVb1JqAmJ285kcKNh4A@mail.gmail.com>

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 <arnold at skeeve.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230130/1b5a16ed/attachment-0001.htm>

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: <Y9dUaQf+btXgTttl@largo.jsg.id.au>
References: <B5198799-9629-4CB4-9EE5-39FABEFF35D7@planet.nl>
 <Y9dUaQf+btXgTttl@largo.jsg.id.au>
Message-ID: <AC2D61E9-1DDF-4992-9F9C-B90CEA97DFDB@planet.nl>



> On 30 Jan 2023, at 06:23, Jonathan Gray <jsg at jsg.id.au> 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: <Y9dUaQf+btXgTttl@largo.jsg.id.au>
References: <B5198799-9629-4CB4-9EE5-39FABEFF35D7@planet.nl>
 <Y9dUaQf+btXgTttl@largo.jsg.id.au>
Message-ID: <Y9eMa2pMRvJ6w678@largo.jsg.id.au>

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: <B5198799-9629-4CB4-9EE5-39FABEFF35D7@planet.nl> (Paul Ruizendaal
 via TUHS's message of "Mon, 30 Jan 2023 00:20:52 +0100")
References: <B5198799-9629-4CB4-9EE5-39FABEFF35D7@planet.nl>
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: <CAP6exYK021bpG1epDf+6YBvXUKpN4PoCLYwK1CE1OJ16Pcskgg@mail.gmail.com>
 <CAC20D2ODxrRGZ6sYyMedNdR8wphvkVW3H4j_Dnce-axELdX_Mg@mail.gmail.com>
 <CANCZdfpjrJUDPv2g7-10SrdkgjiacAvp95PVvJ=Ob2h8m8R=FQ@mail.gmail.com>
 <CANCZdfr4zkmFKgqBZKrOL9z5FbFsWSjHpU3vYu-2T3Y+xNat2g@mail.gmail.com>
 <CAC20D2MUWZjQw1O=OGgtf_g8VYoE4ZN8cPyH8FFXaToPuYuZUQ@mail.gmail.com>
 <CANCZdfp2SK+gHNgoybVd3asYfLkNiwt539zdNrgwPSKzK=j38Q@mail.gmail.com>
 <CANCZdfrnO-a7bUGRVHtGLdkGFYeaNCyTzwdR1tO+keKkmKf9cA@mail.gmail.com>
 <CANCZdfqxAZRt-KUEeqqmpg4Q-D39cDQmqjQVSoQoJVYszSUa-A@mail.gmail.com>
 <emfc4c1646-a458-4e3c-9e39-ca09e9935f74@e41218a5.com>
 <CANCZdfp5PpSjbALMtC39=pZcfWxVrGpAfN8OnD7bYLt-WS3-zA@mail.gmail.com>
 <202301300750.30U7oQTh013304@freefriends.org>
Message-ID: <CAD2gp_S99qfXhfMO4hkK7rK7jD2ryY6KCTjc3OAd5Tgf8EmMBQ@mail.gmail.com>

On Mon, Jan 30, 2023 at 2:50 AM <arnold at skeeve.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230130/988e30f5/attachment.htm>

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: <CAD2gp_S99qfXhfMO4hkK7rK7jD2ryY6KCTjc3OAd5Tgf8EmMBQ@mail.gmail.com>
References: <CAP6exYK021bpG1epDf+6YBvXUKpN4PoCLYwK1CE1OJ16Pcskgg@mail.gmail.com>
 <CAC20D2ODxrRGZ6sYyMedNdR8wphvkVW3H4j_Dnce-axELdX_Mg@mail.gmail.com>
 <CANCZdfpjrJUDPv2g7-10SrdkgjiacAvp95PVvJ=Ob2h8m8R=FQ@mail.gmail.com>
 <CANCZdfr4zkmFKgqBZKrOL9z5FbFsWSjHpU3vYu-2T3Y+xNat2g@mail.gmail.com>
 <CAC20D2MUWZjQw1O=OGgtf_g8VYoE4ZN8cPyH8FFXaToPuYuZUQ@mail.gmail.com>
 <CANCZdfp2SK+gHNgoybVd3asYfLkNiwt539zdNrgwPSKzK=j38Q@mail.gmail.com>
 <CANCZdfrnO-a7bUGRVHtGLdkGFYeaNCyTzwdR1tO+keKkmKf9cA@mail.gmail.com>
 <CANCZdfqxAZRt-KUEeqqmpg4Q-D39cDQmqjQVSoQoJVYszSUa-A@mail.gmail.com>
 <emfc4c1646-a458-4e3c-9e39-ca09e9935f74@e41218a5.com>
 <CANCZdfp5PpSjbALMtC39=pZcfWxVrGpAfN8OnD7bYLt-WS3-zA@mail.gmail.com>
 <202301300750.30U7oQTh013304@freefriends.org>
 <CAD2gp_S99qfXhfMO4hkK7rK7jD2ryY6KCTjc3OAd5Tgf8EmMBQ@mail.gmail.com>
Message-ID: <202301301430.30UEUVTI006202@freefriends.org>

John Cowan <cowan at ccil.org> wrote:

> On Mon, Jan 30, 2023 at 2:50 AM <arnold at skeeve.com> 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: <CAKzdPgzUCv5yAyeUQAB36-ar_PEpTkgiVb1JqAmJ285kcKNh4A@mail.gmail.com>
References: <CANCZdfpjrJUDPv2g7-10SrdkgjiacAvp95PVvJ=Ob2h8m8R=FQ@mail.gmail.com>
 <CANCZdfr4zkmFKgqBZKrOL9z5FbFsWSjHpU3vYu-2T3Y+xNat2g@mail.gmail.com>
 <CAC20D2MUWZjQw1O=OGgtf_g8VYoE4ZN8cPyH8FFXaToPuYuZUQ@mail.gmail.com>
 <CANCZdfp2SK+gHNgoybVd3asYfLkNiwt539zdNrgwPSKzK=j38Q@mail.gmail.com>
 <CANCZdfrnO-a7bUGRVHtGLdkGFYeaNCyTzwdR1tO+keKkmKf9cA@mail.gmail.com>
 <CANCZdfqxAZRt-KUEeqqmpg4Q-D39cDQmqjQVSoQoJVYszSUa-A@mail.gmail.com>
 <emfc4c1646-a458-4e3c-9e39-ca09e9935f74@e41218a5.com>
 <CANCZdfp5PpSjbALMtC39=pZcfWxVrGpAfN8OnD7bYLt-WS3-zA@mail.gmail.com>
 <202301300750.30U7oQTh013304@freefriends.org>
 <CAKzdPgzUCv5yAyeUQAB36-ar_PEpTkgiVb1JqAmJ285kcKNh4A@mail.gmail.com>
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: <CANCZdfpjrJUDPv2g7-10SrdkgjiacAvp95PVvJ=Ob2h8m8R=FQ@mail.gmail.com>
 <CANCZdfr4zkmFKgqBZKrOL9z5FbFsWSjHpU3vYu-2T3Y+xNat2g@mail.gmail.com>
 <CAC20D2MUWZjQw1O=OGgtf_g8VYoE4ZN8cPyH8FFXaToPuYuZUQ@mail.gmail.com>
 <CANCZdfp2SK+gHNgoybVd3asYfLkNiwt539zdNrgwPSKzK=j38Q@mail.gmail.com>
 <CANCZdfrnO-a7bUGRVHtGLdkGFYeaNCyTzwdR1tO+keKkmKf9cA@mail.gmail.com>
 <CANCZdfqxAZRt-KUEeqqmpg4Q-D39cDQmqjQVSoQoJVYszSUa-A@mail.gmail.com>
 <emfc4c1646-a458-4e3c-9e39-ca09e9935f74@e41218a5.com>
 <CANCZdfp5PpSjbALMtC39=pZcfWxVrGpAfN8OnD7bYLt-WS3-zA@mail.gmail.com>
 <202301300750.30U7oQTh013304@freefriends.org>
 <CAKzdPgzUCv5yAyeUQAB36-ar_PEpTkgiVb1JqAmJ285kcKNh4A@mail.gmail.com>
 <20230130150219.GD12306@mcvoy.com>
Message-ID: <CAEoi9W4Y=hK9CmCS5jTKRn++VRQ0oCq6JVQD+LeDqfG6yse9Rg@mail.gmail.com>

On Mon, Jan 30, 2023 at 10:02 AM Larry McVoy <lm at mcvoy.com> 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: <CAEoi9W4Y=hK9CmCS5jTKRn++VRQ0oCq6JVQD+LeDqfG6yse9Rg@mail.gmail.com>
References: <CAC20D2MUWZjQw1O=OGgtf_g8VYoE4ZN8cPyH8FFXaToPuYuZUQ@mail.gmail.com>
 <CANCZdfp2SK+gHNgoybVd3asYfLkNiwt539zdNrgwPSKzK=j38Q@mail.gmail.com>
 <CANCZdfrnO-a7bUGRVHtGLdkGFYeaNCyTzwdR1tO+keKkmKf9cA@mail.gmail.com>
 <CANCZdfqxAZRt-KUEeqqmpg4Q-D39cDQmqjQVSoQoJVYszSUa-A@mail.gmail.com>
 <emfc4c1646-a458-4e3c-9e39-ca09e9935f74@e41218a5.com>
 <CANCZdfp5PpSjbALMtC39=pZcfWxVrGpAfN8OnD7bYLt-WS3-zA@mail.gmail.com>
 <202301300750.30U7oQTh013304@freefriends.org>
 <CAKzdPgzUCv5yAyeUQAB36-ar_PEpTkgiVb1JqAmJ285kcKNh4A@mail.gmail.com>
 <20230130150219.GD12306@mcvoy.com>
 <CAEoi9W4Y=hK9CmCS5jTKRn++VRQ0oCq6JVQD+LeDqfG6yse9Rg@mail.gmail.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 <lm at mcvoy.com> 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: <CAC20D2MUWZjQw1O=OGgtf_g8VYoE4ZN8cPyH8FFXaToPuYuZUQ@mail.gmail.com>
 <CANCZdfp2SK+gHNgoybVd3asYfLkNiwt539zdNrgwPSKzK=j38Q@mail.gmail.com>
 <CANCZdfrnO-a7bUGRVHtGLdkGFYeaNCyTzwdR1tO+keKkmKf9cA@mail.gmail.com>
 <CANCZdfqxAZRt-KUEeqqmpg4Q-D39cDQmqjQVSoQoJVYszSUa-A@mail.gmail.com>
 <emfc4c1646-a458-4e3c-9e39-ca09e9935f74@e41218a5.com>
 <CANCZdfp5PpSjbALMtC39=pZcfWxVrGpAfN8OnD7bYLt-WS3-zA@mail.gmail.com>
 <202301300750.30U7oQTh013304@freefriends.org>
 <CAKzdPgzUCv5yAyeUQAB36-ar_PEpTkgiVb1JqAmJ285kcKNh4A@mail.gmail.com>
 <20230130150219.GD12306@mcvoy.com>
 <CAEoi9W4Y=hK9CmCS5jTKRn++VRQ0oCq6JVQD+LeDqfG6yse9Rg@mail.gmail.com>
 <20230130152703.GE12306@mcvoy.com>
Message-ID: <CAEoi9W5LGcJrWAueKQES0H2L=EG+BkzZ83KmZMxQE=AtE1pn7w@mail.gmail.com>

On Mon, Jan 30, 2023 at 10:27 AM Larry McVoy <lm at mcvoy.com> 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 <lm at mcvoy.com> 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: <CAEoi9W5LGcJrWAueKQES0H2L=EG+BkzZ83KmZMxQE=AtE1pn7w@mail.gmail.com>
References: <CANCZdfrnO-a7bUGRVHtGLdkGFYeaNCyTzwdR1tO+keKkmKf9cA@mail.gmail.com>
 <CANCZdfqxAZRt-KUEeqqmpg4Q-D39cDQmqjQVSoQoJVYszSUa-A@mail.gmail.com>
 <emfc4c1646-a458-4e3c-9e39-ca09e9935f74@e41218a5.com>
 <CANCZdfp5PpSjbALMtC39=pZcfWxVrGpAfN8OnD7bYLt-WS3-zA@mail.gmail.com>
 <202301300750.30U7oQTh013304@freefriends.org>
 <CAKzdPgzUCv5yAyeUQAB36-ar_PEpTkgiVb1JqAmJ285kcKNh4A@mail.gmail.com>
 <20230130150219.GD12306@mcvoy.com>
 <CAEoi9W4Y=hK9CmCS5jTKRn++VRQ0oCq6JVQD+LeDqfG6yse9Rg@mail.gmail.com>
 <20230130152703.GE12306@mcvoy.com>
 <CAEoi9W5LGcJrWAueKQES0H2L=EG+BkzZ83KmZMxQE=AtE1pn7w@mail.gmail.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: <CAEoi9W4Y=hK9CmCS5jTKRn++VRQ0oCq6JVQD+LeDqfG6yse9Rg@mail.gmail.com>
References: <CAEoi9W4Y=hK9CmCS5jTKRn++VRQ0oCq6JVQD+LeDqfG6yse9Rg@mail.gmail.com>
Message-ID: <38B1D4CE-C239-4777-B606-FC641655DBCB@iitbombay.org>



> On Jan 30, 2023, at 7:18 AM, Dan Cross <crossd at gmail.com> 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: <CAEoi9W4Y=hK9CmCS5jTKRn++VRQ0oCq6JVQD+LeDqfG6yse9Rg@mail.gmail.com>
 <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 <crossd at gmail.com> 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: <CANCZdfrnO-a7bUGRVHtGLdkGFYeaNCyTzwdR1tO+keKkmKf9cA@mail.gmail.com>
 <CANCZdfqxAZRt-KUEeqqmpg4Q-D39cDQmqjQVSoQoJVYszSUa-A@mail.gmail.com>
 <emfc4c1646-a458-4e3c-9e39-ca09e9935f74@e41218a5.com>
 <CANCZdfp5PpSjbALMtC39=pZcfWxVrGpAfN8OnD7bYLt-WS3-zA@mail.gmail.com>
 <202301300750.30U7oQTh013304@freefriends.org>
 <CAKzdPgzUCv5yAyeUQAB36-ar_PEpTkgiVb1JqAmJ285kcKNh4A@mail.gmail.com>
 <20230130150219.GD12306@mcvoy.com>
 <CAEoi9W4Y=hK9CmCS5jTKRn++VRQ0oCq6JVQD+LeDqfG6yse9Rg@mail.gmail.com>
 <20230130152703.GE12306@mcvoy.com>
 <CAEoi9W5LGcJrWAueKQES0H2L=EG+BkzZ83KmZMxQE=AtE1pn7w@mail.gmail.com>
 <20230130154555.GF12306@mcvoy.com>
Message-ID: <CAEoi9W60rwcUwOS4wZooZtnRg3cUPbQFR5vDjXnVO0vxRtSMhw@mail.gmail.com>

On Mon, Jan 30, 2023 at 10:45 AM Larry McVoy <lm at mcvoy.com> 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 <lm at mcvoy.com> wrote:
> 
> On Mon, Jan 30, 2023 at 08:03:42AM -0800, Bakul Shah wrote:
>> 
>> 
>>>> On Jan 30, 2023, at 7:18 AM, Dan Cross <crossd at gmail.com> 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: <CAEoi9W60rwcUwOS4wZooZtnRg3cUPbQFR5vDjXnVO0vxRtSMhw@mail.gmail.com>
References: <emfc4c1646-a458-4e3c-9e39-ca09e9935f74@e41218a5.com>
 <CANCZdfp5PpSjbALMtC39=pZcfWxVrGpAfN8OnD7bYLt-WS3-zA@mail.gmail.com>
 <202301300750.30U7oQTh013304@freefriends.org>
 <CAKzdPgzUCv5yAyeUQAB36-ar_PEpTkgiVb1JqAmJ285kcKNh4A@mail.gmail.com>
 <20230130150219.GD12306@mcvoy.com>
 <CAEoi9W4Y=hK9CmCS5jTKRn++VRQ0oCq6JVQD+LeDqfG6yse9Rg@mail.gmail.com>
 <20230130152703.GE12306@mcvoy.com>
 <CAEoi9W5LGcJrWAueKQES0H2L=EG+BkzZ83KmZMxQE=AtE1pn7w@mail.gmail.com>
 <20230130154555.GF12306@mcvoy.com>
 <CAEoi9W60rwcUwOS4wZooZtnRg3cUPbQFR5vDjXnVO0vxRtSMhw@mail.gmail.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 <lm at mcvoy.com> 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: <CAEoi9W4Y=hK9CmCS5jTKRn++VRQ0oCq6JVQD+LeDqfG6yse9Rg@mail.gmail.com>
 <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: <CAEoi9W4Y=hK9CmCS5jTKRn++VRQ0oCq6JVQD+LeDqfG6yse9Rg@mail.gmail.com>
 <38B1D4CE-C239-4777-B606-FC641655DBCB@iitbombay.org>
 <20230130160705.GG12306@mcvoy.com>
Message-ID: <CAEoi9W5o05NBHb5wxyAsiotOR+wXUQwBsUAzv3d-+MH92UnZ2w@mail.gmail.com>

On Mon, Jan 30, 2023 at 11:07 AM Larry McVoy <lm at mcvoy.com> wrote:
> On Mon, Jan 30, 2023 at 08:03:42AM -0800, Bakul Shah wrote:
> > > On Jan 30, 2023, at 7:18 AM, Dan Cross <crossd at gmail.com> 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: <CAEoi9W60rwcUwOS4wZooZtnRg3cUPbQFR5vDjXnVO0vxRtSMhw@mail.gmail.com>
References: <CANCZdfrnO-a7bUGRVHtGLdkGFYeaNCyTzwdR1tO+keKkmKf9cA@mail.gmail.com>
 <CANCZdfqxAZRt-KUEeqqmpg4Q-D39cDQmqjQVSoQoJVYszSUa-A@mail.gmail.com>
 <emfc4c1646-a458-4e3c-9e39-ca09e9935f74@e41218a5.com>
 <CANCZdfp5PpSjbALMtC39=pZcfWxVrGpAfN8OnD7bYLt-WS3-zA@mail.gmail.com>
 <202301300750.30U7oQTh013304@freefriends.org>
 <CAKzdPgzUCv5yAyeUQAB36-ar_PEpTkgiVb1JqAmJ285kcKNh4A@mail.gmail.com>
 <20230130150219.GD12306@mcvoy.com>
 <CAEoi9W4Y=hK9CmCS5jTKRn++VRQ0oCq6JVQD+LeDqfG6yse9Rg@mail.gmail.com>
 <20230130152703.GE12306@mcvoy.com>
 <CAEoi9W5LGcJrWAueKQES0H2L=EG+BkzZ83KmZMxQE=AtE1pn7w@mail.gmail.com>
 <20230130154555.GF12306@mcvoy.com>
 <CAEoi9W60rwcUwOS4wZooZtnRg3cUPbQFR5vDjXnVO0vxRtSMhw@mail.gmail.com>
Message-ID: <alpine.DEB.2.21.2301301115080.5005@sd-119843.dedibox.fr>

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.

<snip>

> 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: <alpine.DEB.2.21.2301301121590.5005@sd-119843.dedibox.fr>

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: <alpine.DEB.2.21.2301301115080.5005@sd-119843.dedibox.fr>
References: <CANCZdfp5PpSjbALMtC39=pZcfWxVrGpAfN8OnD7bYLt-WS3-zA@mail.gmail.com>
 <202301300750.30U7oQTh013304@freefriends.org>
 <CAKzdPgzUCv5yAyeUQAB36-ar_PEpTkgiVb1JqAmJ285kcKNh4A@mail.gmail.com>
 <20230130150219.GD12306@mcvoy.com>
 <CAEoi9W4Y=hK9CmCS5jTKRn++VRQ0oCq6JVQD+LeDqfG6yse9Rg@mail.gmail.com>
 <20230130152703.GE12306@mcvoy.com>
 <CAEoi9W5LGcJrWAueKQES0H2L=EG+BkzZ83KmZMxQE=AtE1pn7w@mail.gmail.com>
 <20230130154555.GF12306@mcvoy.com>
 <CAEoi9W60rwcUwOS4wZooZtnRg3cUPbQFR5vDjXnVO0vxRtSMhw@mail.gmail.com>
 <alpine.DEB.2.21.2301301115080.5005@sd-119843.dedibox.fr>
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: <em1f78b3ec-49c7-401e-a757-4accda19f4fb@e41218a5.com>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230130/1d9f24dc/attachment-0001.htm>

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: <CANCZdfp5PpSjbALMtC39=pZcfWxVrGpAfN8OnD7bYLt-WS3-zA@mail.gmail.com>
 <202301300750.30U7oQTh013304@freefriends.org>
 <CAKzdPgzUCv5yAyeUQAB36-ar_PEpTkgiVb1JqAmJ285kcKNh4A@mail.gmail.com>
 <20230130150219.GD12306@mcvoy.com>
 <CAEoi9W4Y=hK9CmCS5jTKRn++VRQ0oCq6JVQD+LeDqfG6yse9Rg@mail.gmail.com>
 <20230130152703.GE12306@mcvoy.com>
 <CAEoi9W5LGcJrWAueKQES0H2L=EG+BkzZ83KmZMxQE=AtE1pn7w@mail.gmail.com>
 <20230130154555.GF12306@mcvoy.com>
 <CAEoi9W60rwcUwOS4wZooZtnRg3cUPbQFR5vDjXnVO0vxRtSMhw@mail.gmail.com>
 <alpine.DEB.2.21.2301301115080.5005@sd-119843.dedibox.fr>
 <20230130162719.GI12306@mcvoy.com>
Message-ID: <CAP6exYJcqgJM=MXFfhehRjfZFNJF_BBhq=pKkfHhPVVVorXLAg@mail.gmail.com>

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 <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230130/aa7ecab4/attachment.htm>

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: <em1f78b3ec-49c7-401e-a757-4accda19f4fb@e41218a5.com>
References: <em1f78b3ec-49c7-401e-a757-4accda19f4fb@e41218a5.com>
Message-ID: <d0923050-ee4e-d42b-f71e-90d2cde3d70c@case.edu>

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: <CANCZdfp5PpSjbALMtC39=pZcfWxVrGpAfN8OnD7bYLt-WS3-zA@mail.gmail.com>
 <202301300750.30U7oQTh013304@freefriends.org>
 <CAKzdPgzUCv5yAyeUQAB36-ar_PEpTkgiVb1JqAmJ285kcKNh4A@mail.gmail.com>
 <20230130150219.GD12306@mcvoy.com>
 <CAEoi9W4Y=hK9CmCS5jTKRn++VRQ0oCq6JVQD+LeDqfG6yse9Rg@mail.gmail.com>
 <20230130152703.GE12306@mcvoy.com>
 <CAEoi9W5LGcJrWAueKQES0H2L=EG+BkzZ83KmZMxQE=AtE1pn7w@mail.gmail.com>
 <20230130154555.GF12306@mcvoy.com>
 <CAEoi9W60rwcUwOS4wZooZtnRg3cUPbQFR5vDjXnVO0vxRtSMhw@mail.gmail.com>
 <alpine.DEB.2.21.2301301115080.5005@sd-119843.dedibox.fr>
 <20230130162719.GI12306@mcvoy.com>
Message-ID: <CAC20D2MKrNrob1g=XTZue3JbcgsSR_bqgBZVuYjvdDXHAFTbfA@mail.gmail.com>

On Mon, Jan 30, 2023 at 11:27 AM Larry McVoy <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230130/78a7c5f4/attachment.htm>

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: <D39D9964-D939-4F5F-B117-A819E291FB9A@iitbombay.org>

On Jan 30, 2023, at 8:19 AM, Ralph Corderoy <ralph at inputplus.co.uk> 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: <CAEoi9W60rwcUwOS4wZooZtnRg3cUPbQFR5vDjXnVO0vxRtSMhw@mail.gmail.com>
References: <emfc4c1646-a458-4e3c-9e39-ca09e9935f74@e41218a5.com>
 <CANCZdfp5PpSjbALMtC39=pZcfWxVrGpAfN8OnD7bYLt-WS3-zA@mail.gmail.com>
 <202301300750.30U7oQTh013304@freefriends.org>
 <CAKzdPgzUCv5yAyeUQAB36-ar_PEpTkgiVb1JqAmJ285kcKNh4A@mail.gmail.com>
 <20230130150219.GD12306@mcvoy.com>
 <CAEoi9W4Y=hK9CmCS5jTKRn++VRQ0oCq6JVQD+LeDqfG6yse9Rg@mail.gmail.com>
 <20230130152703.GE12306@mcvoy.com>
 <CAEoi9W5LGcJrWAueKQES0H2L=EG+BkzZ83KmZMxQE=AtE1pn7w@mail.gmail.com>
 <20230130154555.GF12306@mcvoy.com>
 <CAEoi9W60rwcUwOS4wZooZtnRg3cUPbQFR5vDjXnVO0vxRtSMhw@mail.gmail.com>
Message-ID: <Y9f05342q0ghgjuF@mit.edu>

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: <CAEoi9W60rwcUwOS4wZooZtnRg3cUPbQFR5vDjXnVO0vxRtSMhw@mail.gmail.com>
References: <CANCZdfrnO-a7bUGRVHtGLdkGFYeaNCyTzwdR1tO+keKkmKf9cA@mail.gmail.com>
 <CANCZdfqxAZRt-KUEeqqmpg4Q-D39cDQmqjQVSoQoJVYszSUa-A@mail.gmail.com>
 <emfc4c1646-a458-4e3c-9e39-ca09e9935f74@e41218a5.com>
 <CANCZdfp5PpSjbALMtC39=pZcfWxVrGpAfN8OnD7bYLt-WS3-zA@mail.gmail.com>
 <202301300750.30U7oQTh013304@freefriends.org>
 <CAKzdPgzUCv5yAyeUQAB36-ar_PEpTkgiVb1JqAmJ285kcKNh4A@mail.gmail.com>
 <20230130150219.GD12306@mcvoy.com>
 <CAEoi9W4Y=hK9CmCS5jTKRn++VRQ0oCq6JVQD+LeDqfG6yse9Rg@mail.gmail.com>
 <20230130152703.GE12306@mcvoy.com>
 <CAEoi9W5LGcJrWAueKQES0H2L=EG+BkzZ83KmZMxQE=AtE1pn7w@mail.gmail.com>
 <20230130154555.GF12306@mcvoy.com>
 <CAEoi9W60rwcUwOS4wZooZtnRg3cUPbQFR5vDjXnVO0vxRtSMhw@mail.gmail.com>
Message-ID: <CALMnNGjG7LmRVYvZdHK8mzv4xmRQkc_nAroFU=PxLZw+_vS79A@mail.gmail.com>

On Monday, January 30, 2023, Dan Cross <crossd at gmail.com> wrote:

> On Mon, Jan 30, 2023 at 10:45 AM Larry McVoy <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230130/ac3dc1da/attachment.htm>

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: <em1f78b3ec-49c7-401e-a757-4accda19f4fb@e41218a5.com>
References: <em1f78b3ec-49c7-401e-a757-4accda19f4fb@e41218a5.com>
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: <CALMnNGjG7LmRVYvZdHK8mzv4xmRQkc_nAroFU=PxLZw+_vS79A@mail.gmail.com>
References: <CANCZdfrnO-a7bUGRVHtGLdkGFYeaNCyTzwdR1tO+keKkmKf9cA@mail.gmail.com>
 <CANCZdfqxAZRt-KUEeqqmpg4Q-D39cDQmqjQVSoQoJVYszSUa-A@mail.gmail.com>
 <emfc4c1646-a458-4e3c-9e39-ca09e9935f74@e41218a5.com>
 <CANCZdfp5PpSjbALMtC39=pZcfWxVrGpAfN8OnD7bYLt-WS3-zA@mail.gmail.com>
 <202301300750.30U7oQTh013304@freefriends.org>
 <CAKzdPgzUCv5yAyeUQAB36-ar_PEpTkgiVb1JqAmJ285kcKNh4A@mail.gmail.com>
 <20230130150219.GD12306@mcvoy.com>
 <CAEoi9W4Y=hK9CmCS5jTKRn++VRQ0oCq6JVQD+LeDqfG6yse9Rg@mail.gmail.com>
 <20230130152703.GE12306@mcvoy.com>
 <CAEoi9W5LGcJrWAueKQES0H2L=EG+BkzZ83KmZMxQE=AtE1pn7w@mail.gmail.com>
 <20230130154555.GF12306@mcvoy.com>
 <CAEoi9W60rwcUwOS4wZooZtnRg3cUPbQFR5vDjXnVO0vxRtSMhw@mail.gmail.com>
 <CALMnNGjG7LmRVYvZdHK8mzv4xmRQkc_nAroFU=PxLZw+_vS79A@mail.gmail.com>
Message-ID: <CANCZdfqGr6+VFFVqn2vZQ5y5BiZHduTGJjPuOPbesXDLHL=aug@mail.gmail.com>

On Mon, Jan 30, 2023 at 9:59 AM Andy Kosela <akosela at andykosela.com> wrote:

> On Monday, January 30, 2023, Dan Cross <crossd at gmail.com> wrote:
>
>> On Mon, Jan 30, 2023 at 10:45 AM Larry McVoy <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230130/98d5cbe9/attachment.htm>

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: <CAP6exY+_YKkJ2vHpz2sk-yjoDCnyx8g4jW_Lk3qynGV1cCuEOg@mail.gmail.com>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230130/4788cd8c/attachment.htm>

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: <CAFH29toutE3ZiDkjUK+PebQ77tdhfKCk2YMvaQ+ao3arOxt9dA@mail.gmail.com>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230130/84679cea/attachment.htm>

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: <CAFH29toutE3ZiDkjUK+PebQ77tdhfKCk2YMvaQ+ao3arOxt9dA@mail.gmail.com>
References: <CAFH29toutE3ZiDkjUK+PebQ77tdhfKCk2YMvaQ+ao3arOxt9dA@mail.gmail.com>
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 <rich.salz at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230130/65648b23/attachment.htm>

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: <CAP6exY+_YKkJ2vHpz2sk-yjoDCnyx8g4jW_Lk3qynGV1cCuEOg@mail.gmail.com>
References: <CAP6exY+_YKkJ2vHpz2sk-yjoDCnyx8g4jW_Lk3qynGV1cCuEOg@mail.gmail.com>
Message-ID: <CALMnNGiXVeqBznYwhPmwR-jUtq2OMO64HHc2A4F0o+PFJMu3Fw@mail.gmail.com>

On Monday, January 30, 2023, ron minnich <rminnich at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230130/f6f8fb06/attachment.htm>

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: <CALMnNGiXVeqBznYwhPmwR-jUtq2OMO64HHc2A4F0o+PFJMu3Fw@mail.gmail.com>
References: <CAP6exY+_YKkJ2vHpz2sk-yjoDCnyx8g4jW_Lk3qynGV1cCuEOg@mail.gmail.com>
 <CALMnNGiXVeqBznYwhPmwR-jUtq2OMO64HHc2A4F0o+PFJMu3Fw@mail.gmail.com>
Message-ID: <RHhaWnWrWHJ6A5gopXMwP3kldg6f7uUUNFlrrJOKh_mTUzzdRTC-2SrEFcKcuI5WjX-1QXP_1YMRox50YRGzCqCze8PB3dvi5DR6cIiKE-o=@protonmail.com>

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 <rminnich at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230130/dd666dc5/attachment.htm>

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: <emfc4c1646-a458-4e3c-9e39-ca09e9935f74@e41218a5.com>
 <CANCZdfp5PpSjbALMtC39=pZcfWxVrGpAfN8OnD7bYLt-WS3-zA@mail.gmail.com>
 <202301300750.30U7oQTh013304@freefriends.org>
 <CAKzdPgzUCv5yAyeUQAB36-ar_PEpTkgiVb1JqAmJ285kcKNh4A@mail.gmail.com>
 <20230130150219.GD12306@mcvoy.com>
 <CAEoi9W4Y=hK9CmCS5jTKRn++VRQ0oCq6JVQD+LeDqfG6yse9Rg@mail.gmail.com>
 <20230130152703.GE12306@mcvoy.com>
 <CAEoi9W5LGcJrWAueKQES0H2L=EG+BkzZ83KmZMxQE=AtE1pn7w@mail.gmail.com>
 <20230130154555.GF12306@mcvoy.com>
 <CAEoi9W60rwcUwOS4wZooZtnRg3cUPbQFR5vDjXnVO0vxRtSMhw@mail.gmail.com>
 <20230130161846.GH12306@mcvoy.com>
Message-ID: <CAEoi9W7b3gu4=CYN5fnU8LvVt6uUepVEt-EdEYgsoA9HKeFJAQ@mail.gmail.com>

On Mon, Jan 30, 2023 at 11:18 AM Larry McVoy <lm at mcvoy.com> 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 <lm at mcvoy.com> 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: <CAEoi9W4Y=hK9CmCS5jTKRn++VRQ0oCq6JVQD+LeDqfG6yse9Rg@mail.gmail.com>
 <38B1D4CE-C239-4777-B606-FC641655DBCB@iitbombay.org>
 <20230130161857.F2F371FB2F@orac.inputplus.co.uk>
Message-ID: <CAEoi9W52N9RZthX_DcdSkHisn--VbL2Lt-jjh7Ga-Vf++N1afg@mail.gmail.com>

On Mon, Jan 30, 2023 at 11:19 AM Ralph Corderoy <ralph at inputplus.co.uk> 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: <CAEoi9W7b3gu4=CYN5fnU8LvVt6uUepVEt-EdEYgsoA9HKeFJAQ@mail.gmail.com>
References: <emfc4c1646-a458-4e3c-9e39-ca09e9935f74@e41218a5.com>
 <CANCZdfp5PpSjbALMtC39=pZcfWxVrGpAfN8OnD7bYLt-WS3-zA@mail.gmail.com>
 <202301300750.30U7oQTh013304@freefriends.org>
 <CAKzdPgzUCv5yAyeUQAB36-ar_PEpTkgiVb1JqAmJ285kcKNh4A@mail.gmail.com>
 <20230130150219.GD12306@mcvoy.com>
 <CAEoi9W4Y=hK9CmCS5jTKRn++VRQ0oCq6JVQD+LeDqfG6yse9Rg@mail.gmail.com>
 <20230130152703.GE12306@mcvoy.com>
 <CAEoi9W5LGcJrWAueKQES0H2L=EG+BkzZ83KmZMxQE=AtE1pn7w@mail.gmail.com>
 <20230130154555.GF12306@mcvoy.com>
 <CAEoi9W60rwcUwOS4wZooZtnRg3cUPbQFR5vDjXnVO0vxRtSMhw@mail.gmail.com>
 <20230130161846.GH12306@mcvoy.com>
 <CAEoi9W7b3gu4=CYN5fnU8LvVt6uUepVEt-EdEYgsoA9HKeFJAQ@mail.gmail.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 <crossd at gmail.com> wrote:
> 
> On Mon, Jan 30, 2023 at 11:18 AM Larry McVoy <lm at mcvoy.com> 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 <lm at mcvoy.com> 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: <RHhaWnWrWHJ6A5gopXMwP3kldg6f7uUUNFlrrJOKh_mTUzzdRTC-2SrEFcKcuI5WjX-1QXP_1YMRox50YRGzCqCze8PB3dvi5DR6cIiKE-o=@protonmail.com>
References: <CAP6exY+_YKkJ2vHpz2sk-yjoDCnyx8g4jW_Lk3qynGV1cCuEOg@mail.gmail.com>
 <CALMnNGiXVeqBznYwhPmwR-jUtq2OMO64HHc2A4F0o+PFJMu3Fw@mail.gmail.com>
 <RHhaWnWrWHJ6A5gopXMwP3kldg6f7uUUNFlrrJOKh_mTUzzdRTC-2SrEFcKcuI5WjX-1QXP_1YMRox50YRGzCqCze8PB3dvi5DR6cIiKE-o=@protonmail.com>
Message-ID: <CAP6exYJ8S--bhw6wm88JMeJKYiTW0tx_JD-au8NACaoAkQjiOA@mail.gmail.com>

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 <segaloco at protonmail.com> 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 <rminnich at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230130/a2eda463/attachment.htm>

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: <CANCZdfp5PpSjbALMtC39=pZcfWxVrGpAfN8OnD7bYLt-WS3-zA@mail.gmail.com>
 <202301300750.30U7oQTh013304@freefriends.org>
 <CAKzdPgzUCv5yAyeUQAB36-ar_PEpTkgiVb1JqAmJ285kcKNh4A@mail.gmail.com>
 <20230130150219.GD12306@mcvoy.com>
 <CAEoi9W4Y=hK9CmCS5jTKRn++VRQ0oCq6JVQD+LeDqfG6yse9Rg@mail.gmail.com>
 <20230130152703.GE12306@mcvoy.com>
 <CAEoi9W5LGcJrWAueKQES0H2L=EG+BkzZ83KmZMxQE=AtE1pn7w@mail.gmail.com>
 <20230130154555.GF12306@mcvoy.com>
 <CAEoi9W60rwcUwOS4wZooZtnRg3cUPbQFR5vDjXnVO0vxRtSMhw@mail.gmail.com>
 <alpine.DEB.2.21.2301301115080.5005@sd-119843.dedibox.fr>
 <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 <lm at mcvoy.com> 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: <CANCZdfqGr6+VFFVqn2vZQ5y5BiZHduTGJjPuOPbesXDLHL=aug@mail.gmail.com>
References: <202301300750.30U7oQTh013304@freefriends.org>
 <CAKzdPgzUCv5yAyeUQAB36-ar_PEpTkgiVb1JqAmJ285kcKNh4A@mail.gmail.com>
 <20230130150219.GD12306@mcvoy.com>
 <CAEoi9W4Y=hK9CmCS5jTKRn++VRQ0oCq6JVQD+LeDqfG6yse9Rg@mail.gmail.com>
 <20230130152703.GE12306@mcvoy.com>
 <CAEoi9W5LGcJrWAueKQES0H2L=EG+BkzZ83KmZMxQE=AtE1pn7w@mail.gmail.com>
 <20230130154555.GF12306@mcvoy.com>
 <CAEoi9W60rwcUwOS4wZooZtnRg3cUPbQFR5vDjXnVO0vxRtSMhw@mail.gmail.com>
 <CALMnNGjG7LmRVYvZdHK8mzv4xmRQkc_nAroFU=PxLZw+_vS79A@mail.gmail.com>
 <CANCZdfqGr6+VFFVqn2vZQ5y5BiZHduTGJjPuOPbesXDLHL=aug@mail.gmail.com>
Message-ID: <Y9gq4wl1bIB3yTYL@mit.edu>

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: <em1f78b3ec-49c7-401e-a757-4accda19f4fb@e41218a5.com>
 <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: <Y9gq4wl1bIB3yTYL@mit.edu>
References: <202301300750.30U7oQTh013304@freefriends.org>
 <CAKzdPgzUCv5yAyeUQAB36-ar_PEpTkgiVb1JqAmJ285kcKNh4A@mail.gmail.com>
 <20230130150219.GD12306@mcvoy.com>
 <CAEoi9W4Y=hK9CmCS5jTKRn++VRQ0oCq6JVQD+LeDqfG6yse9Rg@mail.gmail.com>
 <20230130152703.GE12306@mcvoy.com>
 <CAEoi9W5LGcJrWAueKQES0H2L=EG+BkzZ83KmZMxQE=AtE1pn7w@mail.gmail.com>
 <20230130154555.GF12306@mcvoy.com>
 <CAEoi9W60rwcUwOS4wZooZtnRg3cUPbQFR5vDjXnVO0vxRtSMhw@mail.gmail.com>
 <CALMnNGjG7LmRVYvZdHK8mzv4xmRQkc_nAroFU=PxLZw+_vS79A@mail.gmail.com>
 <CANCZdfqGr6+VFFVqn2vZQ5y5BiZHduTGJjPuOPbesXDLHL=aug@mail.gmail.com>
 <Y9gq4wl1bIB3yTYL@mit.edu>
Message-ID: <CANCZdfr8uQaW4ZeQRWfa1kbrk0HdDNRtd4DMe7UCmODDPkA9Ag@mail.gmail.com>

On Mon, Jan 30, 2023 at 1:39 PM Theodore Ts'o <tytso at mit.edu> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230130/b1481d26/attachment.htm>

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: <Y9gq4wl1bIB3yTYL@mit.edu>
References: <202301300750.30U7oQTh013304@freefriends.org>
 <CAKzdPgzUCv5yAyeUQAB36-ar_PEpTkgiVb1JqAmJ285kcKNh4A@mail.gmail.com>
 <20230130150219.GD12306@mcvoy.com>
 <CAEoi9W4Y=hK9CmCS5jTKRn++VRQ0oCq6JVQD+LeDqfG6yse9Rg@mail.gmail.com>
 <20230130152703.GE12306@mcvoy.com>
 <CAEoi9W5LGcJrWAueKQES0H2L=EG+BkzZ83KmZMxQE=AtE1pn7w@mail.gmail.com>
 <20230130154555.GF12306@mcvoy.com>
 <CAEoi9W60rwcUwOS4wZooZtnRg3cUPbQFR5vDjXnVO0vxRtSMhw@mail.gmail.com>
 <CALMnNGjG7LmRVYvZdHK8mzv4xmRQkc_nAroFU=PxLZw+_vS79A@mail.gmail.com>
 <CANCZdfqGr6+VFFVqn2vZQ5y5BiZHduTGJjPuOPbesXDLHL=aug@mail.gmail.com>
 <Y9gq4wl1bIB3yTYL@mit.edu>
Message-ID: <CAC20D2PtE0Gz+fdDGmEgkJeScvdBLT5uM5aNSJ3AehsQe9AKLg@mail.gmail.com>

On Mon, Jan 30, 2023 at 3:39 PM Theodore Ts'o <tytso at mit.edu> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230130/077cdf5f/attachment.htm>

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: <CAEoi9W7b3gu4=CYN5fnU8LvVt6uUepVEt-EdEYgsoA9HKeFJAQ@mail.gmail.com>
References: <202301300750.30U7oQTh013304@freefriends.org>
 <CAKzdPgzUCv5yAyeUQAB36-ar_PEpTkgiVb1JqAmJ285kcKNh4A@mail.gmail.com>
 <20230130150219.GD12306@mcvoy.com>
 <CAEoi9W4Y=hK9CmCS5jTKRn++VRQ0oCq6JVQD+LeDqfG6yse9Rg@mail.gmail.com>
 <20230130152703.GE12306@mcvoy.com>
 <CAEoi9W5LGcJrWAueKQES0H2L=EG+BkzZ83KmZMxQE=AtE1pn7w@mail.gmail.com>
 <20230130154555.GF12306@mcvoy.com>
 <CAEoi9W60rwcUwOS4wZooZtnRg3cUPbQFR5vDjXnVO0vxRtSMhw@mail.gmail.com>
 <20230130161846.GH12306@mcvoy.com>
 <CAEoi9W7b3gu4=CYN5fnU8LvVt6uUepVEt-EdEYgsoA9HKeFJAQ@mail.gmail.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 <lm at mcvoy.com> 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 <lm at mcvoy.com> 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: <CAP6exYJ8S--bhw6wm88JMeJKYiTW0tx_JD-au8NACaoAkQjiOA@mail.gmail.com>
References: <CAP6exY+_YKkJ2vHpz2sk-yjoDCnyx8g4jW_Lk3qynGV1cCuEOg@mail.gmail.com>
 <CALMnNGiXVeqBznYwhPmwR-jUtq2OMO64HHc2A4F0o+PFJMu3Fw@mail.gmail.com>
 <RHhaWnWrWHJ6A5gopXMwP3kldg6f7uUUNFlrrJOKh_mTUzzdRTC-2SrEFcKcuI5WjX-1QXP_1YMRox50YRGzCqCze8PB3dvi5DR6cIiKE-o=@protonmail.com>
 <CAP6exYJ8S--bhw6wm88JMeJKYiTW0tx_JD-au8NACaoAkQjiOA@mail.gmail.com>
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: <Y9g5WbgHLgA0QqXA@minnie.tuhs.org>

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>
 <CAKzdPgzUCv5yAyeUQAB36-ar_PEpTkgiVb1JqAmJ285kcKNh4A@mail.gmail.com>
 <20230130150219.GD12306@mcvoy.com>
 <CAEoi9W4Y=hK9CmCS5jTKRn++VRQ0oCq6JVQD+LeDqfG6yse9Rg@mail.gmail.com>
 <20230130152703.GE12306@mcvoy.com>
 <CAEoi9W5LGcJrWAueKQES0H2L=EG+BkzZ83KmZMxQE=AtE1pn7w@mail.gmail.com>
 <20230130154555.GF12306@mcvoy.com>
 <CAEoi9W60rwcUwOS4wZooZtnRg3cUPbQFR5vDjXnVO0vxRtSMhw@mail.gmail.com>
 <20230130161846.GH12306@mcvoy.com>
 <CAEoi9W7b3gu4=CYN5fnU8LvVt6uUepVEt-EdEYgsoA9HKeFJAQ@mail.gmail.com>
 <20230130212434.GL12306@mcvoy.com>
Message-ID: <CAKzdPgyeCDbteSfcroubjGE_L7YO_MNZL2QxY=oZhUTG4xqhjg@mail.gmail.com>

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 <lm at mcvoy.com> 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 <lm at mcvoy.com> 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 <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230131/85c8384e/attachment.htm>

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: <CAKzdPgyeCDbteSfcroubjGE_L7YO_MNZL2QxY=oZhUTG4xqhjg@mail.gmail.com>
References: <202301300750.30U7oQTh013304@freefriends.org>
 <CAKzdPgzUCv5yAyeUQAB36-ar_PEpTkgiVb1JqAmJ285kcKNh4A@mail.gmail.com>
 <20230130150219.GD12306@mcvoy.com>
 <CAEoi9W4Y=hK9CmCS5jTKRn++VRQ0oCq6JVQD+LeDqfG6yse9Rg@mail.gmail.com>
 <20230130152703.GE12306@mcvoy.com>
 <CAEoi9W5LGcJrWAueKQES0H2L=EG+BkzZ83KmZMxQE=AtE1pn7w@mail.gmail.com>
 <20230130154555.GF12306@mcvoy.com>
 <CAEoi9W60rwcUwOS4wZooZtnRg3cUPbQFR5vDjXnVO0vxRtSMhw@mail.gmail.com>
 <20230130161846.GH12306@mcvoy.com>
 <CAEoi9W7b3gu4=CYN5fnU8LvVt6uUepVEt-EdEYgsoA9HKeFJAQ@mail.gmail.com>
 <20230130212434.GL12306@mcvoy.com>
 <CAKzdPgyeCDbteSfcroubjGE_L7YO_MNZL2QxY=oZhUTG4xqhjg@mail.gmail.com>
Message-ID: <CAP6exYKwwGLH_d79iHj=Wg3psT0tn4d35xM6j9ZQUS23bUYJ3g@mail.gmail.com>

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 <robpike at gmail.com> 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 <lm at mcvoy.com> 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 <lm at mcvoy.com> 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 <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230130/99b98036/attachment-0001.htm>

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: <CAKzdPgyeCDbteSfcroubjGE_L7YO_MNZL2QxY=oZhUTG4xqhjg@mail.gmail.com>
References: <202301300750.30U7oQTh013304@freefriends.org>
 <CAKzdPgzUCv5yAyeUQAB36-ar_PEpTkgiVb1JqAmJ285kcKNh4A@mail.gmail.com>
 <20230130150219.GD12306@mcvoy.com>
 <CAEoi9W4Y=hK9CmCS5jTKRn++VRQ0oCq6JVQD+LeDqfG6yse9Rg@mail.gmail.com>
 <20230130152703.GE12306@mcvoy.com>
 <CAEoi9W5LGcJrWAueKQES0H2L=EG+BkzZ83KmZMxQE=AtE1pn7w@mail.gmail.com>
 <20230130154555.GF12306@mcvoy.com>
 <CAEoi9W60rwcUwOS4wZooZtnRg3cUPbQFR5vDjXnVO0vxRtSMhw@mail.gmail.com>
 <20230130161846.GH12306@mcvoy.com>
 <CAEoi9W7b3gu4=CYN5fnU8LvVt6uUepVEt-EdEYgsoA9HKeFJAQ@mail.gmail.com>
 <20230130212434.GL12306@mcvoy.com>
 <CAKzdPgyeCDbteSfcroubjGE_L7YO_MNZL2QxY=oZhUTG4xqhjg@mail.gmail.com>
Message-ID: <F84CB053-DE9A-4B46-A928-927DADA522A0@iitbombay.org>

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 <robpike at gmail.com> 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 <lm at mcvoy.com> 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 <lm at mcvoy.com> 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 <lm at mcvoy.com> 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: <CAP6exYJ8S--bhw6wm88JMeJKYiTW0tx_JD-au8NACaoAkQjiOA@mail.gmail.com>
References: <CAP6exY+_YKkJ2vHpz2sk-yjoDCnyx8g4jW_Lk3qynGV1cCuEOg@mail.gmail.com>
 <CALMnNGiXVeqBznYwhPmwR-jUtq2OMO64HHc2A4F0o+PFJMu3Fw@mail.gmail.com>
 <RHhaWnWrWHJ6A5gopXMwP3kldg6f7uUUNFlrrJOKh_mTUzzdRTC-2SrEFcKcuI5WjX-1QXP_1YMRox50YRGzCqCze8PB3dvi5DR6cIiKE-o=@protonmail.com>
 <CAP6exYJ8S--bhw6wm88JMeJKYiTW0tx_JD-au8NACaoAkQjiOA@mail.gmail.com>
Message-ID: <e90436d2-f730-bee6-f229-3cc75b1c06a8@gmail.com>

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: <E05C637A-6237-4000-9759-A73F267A94EC@josephholsten.com>
 <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 <https://maryannhorton.com>

"This is a great book" - Monica Helms

"Brave and Important" - Laura L. Engel

       Available on Amazon and bn.com!

	<https://www.amazon.com/Trailblazer-Lighting-Transgender-Equality-Corporate-ebook/dp/B0B8F2BR9B>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230130/040e8e89/attachment.htm>

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: <e90436d2-f730-bee6-f229-3cc75b1c06a8@gmail.com>
References: <CAP6exY+_YKkJ2vHpz2sk-yjoDCnyx8g4jW_Lk3qynGV1cCuEOg@mail.gmail.com>
 <CALMnNGiXVeqBznYwhPmwR-jUtq2OMO64HHc2A4F0o+PFJMu3Fw@mail.gmail.com>
 <RHhaWnWrWHJ6A5gopXMwP3kldg6f7uUUNFlrrJOKh_mTUzzdRTC-2SrEFcKcuI5WjX-1QXP_1YMRox50YRGzCqCze8PB3dvi5DR6cIiKE-o=@protonmail.com>
 <CAP6exYJ8S--bhw6wm88JMeJKYiTW0tx_JD-au8NACaoAkQjiOA@mail.gmail.com>
 <e90436d2-f730-bee6-f229-3cc75b1c06a8@gmail.com>
Message-ID: <CAEoi9W4nT-cwe2GJreO_xTt=YGfrgTDa5bHfiGf1Fo4bYocziw@mail.gmail.com>

On Mon, Jan 30, 2023 at 8:49 PM Alejandro Colomar
<alx.manpages at gmail.com> 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: <F84CB053-DE9A-4B46-A928-927DADA522A0@iitbombay.org>
References: <202301300750.30U7oQTh013304@freefriends.org>
 <CAKzdPgzUCv5yAyeUQAB36-ar_PEpTkgiVb1JqAmJ285kcKNh4A@mail.gmail.com>
 <20230130150219.GD12306@mcvoy.com>
 <CAEoi9W4Y=hK9CmCS5jTKRn++VRQ0oCq6JVQD+LeDqfG6yse9Rg@mail.gmail.com>
 <20230130152703.GE12306@mcvoy.com>
 <CAEoi9W5LGcJrWAueKQES0H2L=EG+BkzZ83KmZMxQE=AtE1pn7w@mail.gmail.com>
 <20230130154555.GF12306@mcvoy.com>
 <CAEoi9W60rwcUwOS4wZooZtnRg3cUPbQFR5vDjXnVO0vxRtSMhw@mail.gmail.com>
 <20230130161846.GH12306@mcvoy.com>
 <CAEoi9W7b3gu4=CYN5fnU8LvVt6uUepVEt-EdEYgsoA9HKeFJAQ@mail.gmail.com>
 <20230130212434.GL12306@mcvoy.com>
 <CAKzdPgyeCDbteSfcroubjGE_L7YO_MNZL2QxY=oZhUTG4xqhjg@mail.gmail.com>
 <F84CB053-DE9A-4B46-A928-927DADA522A0@iitbombay.org>
Message-ID: <CAD-qYGom0wVu-9fn=_Dusn179Sj1x1CicNO=8+KG+x8d89vKjA@mail.gmail.com>

On 1/30/23, Bakul Shah <bakul at iitbombay.org> 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: <CAEoi9W4nT-cwe2GJreO_xTt=YGfrgTDa5bHfiGf1Fo4bYocziw@mail.gmail.com>
References: <CAP6exY+_YKkJ2vHpz2sk-yjoDCnyx8g4jW_Lk3qynGV1cCuEOg@mail.gmail.com>
 <CALMnNGiXVeqBznYwhPmwR-jUtq2OMO64HHc2A4F0o+PFJMu3Fw@mail.gmail.com>
 <RHhaWnWrWHJ6A5gopXMwP3kldg6f7uUUNFlrrJOKh_mTUzzdRTC-2SrEFcKcuI5WjX-1QXP_1YMRox50YRGzCqCze8PB3dvi5DR6cIiKE-o=@protonmail.com>
 <CAP6exYJ8S--bhw6wm88JMeJKYiTW0tx_JD-au8NACaoAkQjiOA@mail.gmail.com>
 <e90436d2-f730-bee6-f229-3cc75b1c06a8@gmail.com>
 <CAEoi9W4nT-cwe2GJreO_xTt=YGfrgTDa5bHfiGf1Fo4bYocziw@mail.gmail.com>
Message-ID: <CAP6exY+Qz2Oe4gC4D1Fqy22JKKDaanTOYpc0gxugBv485JUknQ@mail.gmail.com>

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 <crossd at gmail.com> wrote:

> On Mon, Jan 30, 2023 at 8:49 PM Alejandro Colomar
> <alx.manpages at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230130/f564baa7/attachment.htm>

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: <CABr82SLxU5jm_Vv9Wx0VgRBH=+q+aRfsGfCjUbHW3y3_CWOr3w@mail.gmail.com>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230131/9f8d51dc/attachment.htm>

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: <CABr82SLxU5jm_Vv9Wx0VgRBH=+q+aRfsGfCjUbHW3y3_CWOr3w@mail.gmail.com>
References: <CABr82SLxU5jm_Vv9Wx0VgRBH=+q+aRfsGfCjUbHW3y3_CWOr3w@mail.gmail.com>
Message-ID: <Y9jdtnCOgrIOIN8O@largo.jsg.id.au>

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: <em1f78b3ec-49c7-401e-a757-4accda19f4fb@e41218a5.com> (Ron
 Natalie's message of "Mon, 30 Jan 2023 16:31:52 +0000")
References: <em1f78b3ec-49c7-401e-a757-4accda19f4fb@e41218a5.com>
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: <Y9jdtnCOgrIOIN8O@largo.jsg.id.au>
References: <CABr82SLxU5jm_Vv9Wx0VgRBH=+q+aRfsGfCjUbHW3y3_CWOr3w@mail.gmail.com>
 <Y9jdtnCOgrIOIN8O@largo.jsg.id.au>
Message-ID: <CABr82SKFEOcuuPNA9W0rcr-HCKe7p3PSRpKgs5FiD5+aohp_nA@mail.gmail.com>

>
>
>
> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230131/81ce01dc/attachment.htm>

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: <Y9dUaQf+btXgTttl@largo.jsg.id.au>
References: <B5198799-9629-4CB4-9EE5-39FABEFF35D7@planet.nl>
 <Y9dUaQf+btXgTttl@largo.jsg.id.au>
Message-ID: <5CE95A98-E85B-4E33-9A35-A9511CF7FCD8@planet.nl>


> On 30 Jan 2023, at 06:23, Jonathan Gray <jsg at jsg.id.au> 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: <CAP6exY+Qz2Oe4gC4D1Fqy22JKKDaanTOYpc0gxugBv485JUknQ@mail.gmail.com>
References: <CAP6exY+_YKkJ2vHpz2sk-yjoDCnyx8g4jW_Lk3qynGV1cCuEOg@mail.gmail.com>
 <CALMnNGiXVeqBznYwhPmwR-jUtq2OMO64HHc2A4F0o+PFJMu3Fw@mail.gmail.com>
 <RHhaWnWrWHJ6A5gopXMwP3kldg6f7uUUNFlrrJOKh_mTUzzdRTC-2SrEFcKcuI5WjX-1QXP_1YMRox50YRGzCqCze8PB3dvi5DR6cIiKE-o=@protonmail.com>
 <CAP6exYJ8S--bhw6wm88JMeJKYiTW0tx_JD-au8NACaoAkQjiOA@mail.gmail.com>
 <e90436d2-f730-bee6-f229-3cc75b1c06a8@gmail.com>
 <CAEoi9W4nT-cwe2GJreO_xTt=YGfrgTDa5bHfiGf1Fo4bYocziw@mail.gmail.com>
 <CAP6exY+Qz2Oe4gC4D1Fqy22JKKDaanTOYpc0gxugBv485JUknQ@mail.gmail.com>
Message-ID: <CAEoi9W5S-eZium_bQrdLH0VJUjPx_3J+vtb1TCyAiU+-WCU-JQ@mail.gmail.com>

On Mon, Jan 30, 2023 at 10:59 PM ron minnich <rminnich at gmail.com> 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 <crossd at gmail.com> wrote:
>>
>> On Mon, Jan 30, 2023 at 8:49 PM Alejandro Colomar
>> <alx.manpages at gmail.com> 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