From m.douglas.mcilroy at dartmouth.edu Fri Jan 1 01:05:30 2021
From: m.douglas.mcilroy at dartmouth.edu (M Douglas McIlroy)
Date: Thu, 31 Dec 2020 10:05:30 -0500
Subject: [TUHS] The 2038 bug...
Message-ID: <CAKH6PiVcXqV_ZObx7Hon8eax021_PDnym8BbZinjyfuFotNQHQ@mail.gmail.com>
> I'll be (G-d willing) 79 then; I hope around, but I also hope not
> overly involved with computers.
>From the vantage point of 88, I can attest to the permanence of
computing's grip. I guess the key word is "overly". The only code
I've written in the last couple of weeks is a few lines of PostScript
to touch up my seasonal map/greeting card, the creative part of
which is at www.cs.dartmouth.edu/~doug/2020map.pdf.
Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20201231/1c86137c/attachment.htm>
From imp at bsdimp.com Fri Jan 1 01:30:55 2021
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 31 Dec 2020 08:30:55 -0700
Subject: [TUHS] The 2038 bug...
In-Reply-To: <202012310810.0BV8ADZ3027195@freefriends.org>
References: <alpine.BSF.2.21.9999.2012311806460.82237@aneurin.horsfall.org>
<CAK6BEgdH7OOsw3p3d_bLsjhR+bv_ZrG9mvVSLa3hgJKhjLVK6w@mail.gmail.com>
<202012310810.0BV8ADZ3027195@freefriends.org>
Message-ID: <CANCZdfoKV7A46ho3ORghFZEddROty3A-y2bn1VY0m=ipBxFF6w@mail.gmail.com>
On Thu, Dec 31, 2020, 1:10 AM <arnold at skeeve.com> wrote:
> Will there be that many 32 bit systems left by then?
FreeBSD has 64bit time_t everywhere except i386. We looked at compat shims
and found like 200 system calls would need compat shims to keep a stable
ABI. Creating a new ABI is mostly a matter of fixing the places that know
time_t is 32 bit on i386.
Most likely, though, it will just be retired 15 years or so before the
deadline.
time_t these
> days tends to be 64 bits, and I think at least the Linux file systems
> store them that way.
Time_t was still 32 bits last I checked on i386 and a few others...
Microsoft counts time from January 1, 1980, so
> that buys them until 2048. :-)
>
> I'll be (G-d willing) 79 then; I hope around, but I also hope not
> overly involved with computers. :-)
>
I'll only be 72... with LORAN-C retired in the US the last of the
potentially problematic[*] code I've deployed is gone.
Warner
[*] Purely from a 32 bit time_t perspective.
Arnold
>
> Niklas Karlsson <nikke.karlsson at gmail.com> wrote:
>
> > I'll be a mere 58, so not even retired yet. I fear it will be a very
> > interesting time, in the "May you live in interesting times" sense.
> >
> > Niklas
> >
> > Den tors 31 dec. 2020 kl 08:21 skrev Dave Horsfall <dave at horsfall.org>:
> >
> > > As the new year is about to kick in (down-under anyway), it got me to
> > > thinking (always dangerous): how many here will be around for it to
> pick
> > > up the pieces that are no doubt still lying around?
> > >
> > > I'll be about the ripe old age of 85, so I may be around to see the
> > > Imminent Death of the Internet (Film at 11).
> > >
> > > 2100? Forget it... Too bad, as "Revolt in 2100 (?)" is one of my
> > > favourite Heinlein books.
> > >
> > > Others?
> > >
> > > -- Dave
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20201231/2080eace/attachment.htm>
From athornton at gmail.com Fri Jan 1 02:09:33 2021
From: athornton at gmail.com (Adam Thornton)
Date: Thu, 31 Dec 2020 09:09:33 -0700
Subject: [TUHS] The 2038 bug...
In-Reply-To: <CANCZdfoKV7A46ho3ORghFZEddROty3A-y2bn1VY0m=ipBxFF6w@mail.gmail.com>
References: <alpine.BSF.2.21.9999.2012311806460.82237@aneurin.horsfall.org>
<CAK6BEgdH7OOsw3p3d_bLsjhR+bv_ZrG9mvVSLa3hgJKhjLVK6w@mail.gmail.com>
<202012310810.0BV8ADZ3027195@freefriends.org>
<CANCZdfoKV7A46ho3ORghFZEddROty3A-y2bn1VY0m=ipBxFF6w@mail.gmail.com>
Message-ID: <950DAE25-BCAD-47EF-8FCE-A716271A3C25@gmail.com>
I’ll be 67 for the 2038 bug. Plenty of time to charge ridiculous hourly rates for being the old curmudgeon who still keeps a bunch of these systems running in his house for some combination of fun, nostalgia, and challenge.
My gut tells me that this is going to be far less of a big deal than 2000.
To (somewhat inaccurately) summarize: the problem with 2000 is that there was (and is, and will be in 2038) a whole bunch of COBOL doing the Really Important Stuff with two-digit year fields.
Whereas, time_t is basically internal, right?
Software is forever, but hardware, even with the best of intentions, after about 40 years or so, starts getting difficult to keep running (/pats Atari 2600 affectionately).
So if you *can* rebuild the software for a newer architecture…then suddenly there’s a wider time_t and the 33d bit is suddenly 1 but nothing breaks. And if you can’t, you’re probably by that point running it in emulation anyway, at which point your emulation environment can know that 1/1/1970 is really whatever/2038, and your software is partying like it was just 1969. If you have need to maintain linearly incrementing time in your application, you do the sliding window thing that we did with COBOL and Y2K.
Aside: the COBOL problem was made worse by IBM’s (IMHO very good) decision to provide problem-state instruction compatibility all the way from the (1964, IIRC) 360 to the present day, so for more than half a decade, you can just drop your Big Important COBOL onto the current incarnation of the 3x0/z and it’ll be perfectly happy.
Adam
From lm at mcvoy.com Fri Jan 1 02:12:28 2021
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 31 Dec 2020 08:12:28 -0800
Subject: [TUHS] The 2038 bug...
In-Reply-To: <950DAE25-BCAD-47EF-8FCE-A716271A3C25@gmail.com>
References: <alpine.BSF.2.21.9999.2012311806460.82237@aneurin.horsfall.org>
<CAK6BEgdH7OOsw3p3d_bLsjhR+bv_ZrG9mvVSLa3hgJKhjLVK6w@mail.gmail.com>
<202012310810.0BV8ADZ3027195@freefriends.org>
<CANCZdfoKV7A46ho3ORghFZEddROty3A-y2bn1VY0m=ipBxFF6w@mail.gmail.com>
<950DAE25-BCAD-47EF-8FCE-A716271A3C25@gmail.com>
Message-ID: <20201231161228.GG28420@mcvoy.com>
On Thu, Dec 31, 2020 at 09:09:33AM -0700, Adam Thornton wrote:
> Whereas, time_t is basically internal, right?
time_t is used in syscalls, see Warner's email about i386. It's a
mess for 32 bit kernels.
From arnold at skeeve.com Fri Jan 1 02:51:34 2021
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 31 Dec 2020 09:51:34 -0700
Subject: [TUHS] The 2038 bug...
In-Reply-To: <CAKH6PiVcXqV_ZObx7Hon8eax021_PDnym8BbZinjyfuFotNQHQ@mail.gmail.com>
References: <CAKH6PiVcXqV_ZObx7Hon8eax021_PDnym8BbZinjyfuFotNQHQ@mail.gmail.com>
Message-ID: <202012311651.0BVGpY4Y016626@freefriends.org>
I wrote:
> > I'll be (G-d willing) 79 then; I hope around, but I also hope not
> > overly involved with computers.
M Douglas McIlroy <m.douglas.mcilroy at dartmouth.edu> wrote:
> From the vantage point of 88, I can attest to the permanence of
> computing's grip.
I admire and am continually amazed at how acive you are; I hope
I will still have all my faculties at 88 as you do.
Best wishes to you and all the list for a Happy New Year!
Arnold
From tytso at mit.edu Fri Jan 1 04:36:25 2021
From: tytso at mit.edu (Theodore Ts'o)
Date: Thu, 31 Dec 2020 13:36:25 -0500
Subject: [TUHS] The 2038 bug...
In-Reply-To: <950DAE25-BCAD-47EF-8FCE-A716271A3C25@gmail.com>
References: <alpine.BSF.2.21.9999.2012311806460.82237@aneurin.horsfall.org>
<CAK6BEgdH7OOsw3p3d_bLsjhR+bv_ZrG9mvVSLa3hgJKhjLVK6w@mail.gmail.com>
<202012310810.0BV8ADZ3027195@freefriends.org>
<CANCZdfoKV7A46ho3ORghFZEddROty3A-y2bn1VY0m=ipBxFF6w@mail.gmail.com>
<950DAE25-BCAD-47EF-8FCE-A716271A3C25@gmail.com>
Message-ID: <X+4aKbZWyHHOf4aZ@mit.edu>
On Thu, Dec 31, 2020 at 09:09:33AM -0700, Adam Thornton wrote:
>
> So if you *can* rebuild the software for a newer architecture…then
> suddenly there’s a wider time_t and the 33d bit is suddenly 1 but
> nothing breaks. And if you can’t, you’re probably by that point
> running it in emulation anyway, at which point your emulation
> environment can know that 1/1/1970 is really whatever/2038, and your
> software is partying like it was just 1969.
Emulation is the key problem. I still have a production server
running on a Linode VM which was installed using Debian 6.0 using i386
binaries sometime in 2011. I kept it on 32-bits because it's more RAM
efficient, and it would have been a pain to reconfigure all of its
services if I were to reinstall it to use a 64-bit OS --- and Debian
has had silky-smooth upgrades from Debian 6.0 all the way up to Debian
10.0 in 2019. There is some discussion of dropping i386 support in
Debian, which may force the issue, but up until now, it's just been
easier for me to do major updates every 2-3 years to the latest Debian
stable, and rely on security updates in between major updates.
Twenty years ago, one of larger customers for the company I was
working for at the time (VA Linux Systems) was one of the new
electronic stock exchanges, and they were using Linux boxes with
PDP-11 emulators because their stock trading software was written in
Macro-11 and running on RSTS/E. They had tried three times to rewrite
it so it could run on something more modern, but each time, the
rewrite had ended in failure. So they simply sharded the problem, so
one x86 server running RSTS/E in emulation would service stocks
symbols AAAA--ADZZ, and the next would service stocks AEAA--AFZZ, and
so on. Given that this was back in 1999, I assume they had solved the
Y2K problem one way or another, but even if they hadn't yet, I suspect
it would have been easier for them to fix the problem by asking their
dedicated Macro-11 Software Engineering team to fix it, than to ask
that same team to help the other team put themselves out of a job
(which for some reason, never seemed to happen successfully...)
- Ted
From bakul at iitbombay.org Fri Jan 1 05:18:02 2021
From: bakul at iitbombay.org (Bakul Shah)
Date: Thu, 31 Dec 2020 11:18:02 -0800
Subject: [TUHS] The 2038 bug...
In-Reply-To: <202012310810.0BV8ADZ3027195@freefriends.org>
References: <202012310810.0BV8ADZ3027195@freefriends.org>
Message-ID: <2DDA5216-77F9-4E62-A557-4EAE917724F2@iitbombay.org>
2038 is closer than 2000 was to the present time and will be upon us
before we are ready for it! I suspect people will still be running 32 bit
systems in all sorts of places and running the Unix equivalent of “dusty
decks†for critical systems. May be even in emulation mode! Who’d
want to fund rewrites of large software monoliths?
I imagine I will still be playing with this ultimate toy of computing in 2038,
if I am able! Still writing new programs for fun along with everything else!
People will still be writing “make†replacements, inventing new programming
languages that won’t be much of an improvement over the present lot, and
arguing over the same old things. Assuming we haven’t crossed the AI singularity.
Which I doubt.
> On Dec 31, 2020, at 12:10 AM, arnold at skeeve.com wrote:
>
> Will there be that many 32 bit systems left by then? time_t these
> days tends to be 64 bits, and I think at least the Linux file systems
> store them that way. Microsoft counts time from January 1, 1980, so
> that buys them until 2048. :-)
>
> I'll be (G-d willing) 79 then; I hope around, but I also hope not
> overly involved with computers. :-)
>
> Arnold
>
> Niklas Karlsson <nikke.karlsson at gmail.com> wrote:
>
>> I'll be a mere 58, so not even retired yet. I fear it will be a very
>> interesting time, in the "May you live in interesting times" sense.
>> Niklas
>> Den tors 31 dec. 2020 kl 08:21 skrev Dave Horsfall <dave at horsfall.org>:
>>> As the new year is about to kick in (down-under anyway), it got me to
>>> thinking (always dangerous): how many here will be around for it to pick
>>> up the pieces that are no doubt still lying around?
>>> I'll be about the ripe old age of 85, so I may be around to see the
>>> Imminent Death of the Internet (Film at 11).
>>> 2100? Forget it... Too bad, as "Revolt in 2100 (?)" is one of my
>>> favourite Heinlein books.
>>> Others?
>>> -- Dave
From imp at bsdimp.com Fri Jan 1 07:34:30 2021
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 31 Dec 2020 14:34:30 -0700
Subject: [TUHS] The 2038 bug...
In-Reply-To: <X+4aKbZWyHHOf4aZ@mit.edu>
References: <alpine.BSF.2.21.9999.2012311806460.82237@aneurin.horsfall.org>
<CAK6BEgdH7OOsw3p3d_bLsjhR+bv_ZrG9mvVSLa3hgJKhjLVK6w@mail.gmail.com>
<202012310810.0BV8ADZ3027195@freefriends.org>
<CANCZdfoKV7A46ho3ORghFZEddROty3A-y2bn1VY0m=ipBxFF6w@mail.gmail.com>
<950DAE25-BCAD-47EF-8FCE-A716271A3C25@gmail.com> <X+4aKbZWyHHOf4aZ@mit.edu>
Message-ID: <CANCZdfqL2ETntycytFLOQOJuvG=kjayoeZukGCpQRE95+X26aA@mail.gmail.com>
On Thu, Dec 31, 2020 at 11:37 AM Theodore Ts'o <tytso at mit.edu> wrote:
> Twenty years ago, one of larger customers for the company I was
> working for at the time (VA Linux Systems) was one of the new
> electronic stock exchanges, and they were using Linux boxes with
> PDP-11 emulators because their stock trading software was written in
> Macro-11 and running on RSTS/E. They had tried three times to rewrite
> it so it could run on something more modern, but each time, the
> rewrite had ended in failure. So they simply sharded the problem, so
> one x86 server running RSTS/E in emulation would service stocks
> symbols AAAA--ADZZ, and the next would service stocks AEAA--AFZZ, and
> so on. Given that this was back in 1999, I assume they had solved the
> Y2K problem one way or another, but even if they hadn't yet, I suspect
> it would have been easier for them to fix the problem by asking their
> dedicated Macro-11 Software Engineering team to fix it, than to ask
> that same team to help the other team put themselves out of a job
> (which for some reason, never seemed to happen successfully...)
>
This is the sort of reason why QBUS x86 machines exist... Not cheap, or
easy to come by these days, but they filled a niche of emulation but with
access to real hardware... Nor easy to find with a web search, it seems :(.
There's a number of nuclear power plants that employ MACRO-11 programmers
because they can't swap out the old gear w/o going through a prohibitively
expensive recertification process... It's cheaper to hire and train good
programmers than it is to go through that process :(.
Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20201231/01128c8a/attachment.htm>
From steffen at sdaoden.eu Fri Jan 1 09:31:45 2021
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Fri, 01 Jan 2021 00:31:45 +0100
Subject: [TUHS] The 2038 bug...
In-Reply-To: <202012311651.0BVGpY4Y016626@freefriends.org>
References: <CAKH6PiVcXqV_ZObx7Hon8eax021_PDnym8BbZinjyfuFotNQHQ@mail.gmail.com>
<202012311651.0BVGpY4Y016626@freefriends.org>
Message-ID: <20201231233145.66uyd%steffen@sdaoden.eu>
arnold at skeeve.com wrote in
<202012311651.0BVGpY4Y016626 at freefriends.org>:
|>> I'll be (G-d willing) 79 then; I hope around, but I also hope not
|>> overly involved with computers.
|
|M Douglas McIlroy <m.douglas.mcilroy at dartmouth.edu> wrote:
|
|> From the vantage point of 88, I can attest to the permanence of
|> computing's grip.
|
|I admire and am continually amazed at how acive you are; I hope
|I will still have all my faculties at 88 as you do.
I became a bit frightened by the sheer size of the icy ground.
|Best wishes to you and all the list for a Happy New Year!
A happy and healthy 2021 everybody!
Greetings and Ciao from Germany,
--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 pnr at planet.nl Sat Jan 2 05:35:10 2021
From: pnr at planet.nl (Paul Ruizendaal)
Date: Fri, 1 Jan 2021 20:35:10 +0100
Subject: [TUHS] G.W.R. Luderer
Message-ID: <D5F4FFE3-CAEA-4BC0-9E65-193D1792FF94@planet.nl>
I am looking for some more background on the 1980/81 "S/F-Unix" system.
Gottfried W. R. Luderer, H. Che, J. P. Haggerty, Peter A. Kirslis, W. T. Marshall:
A Distributed UNIX System Based on a Virtual Circuit Switch. SOSP 1981: 160-168
I have that paper, and Bill Marshall was kind enough to provide a lot of info. I think that Gottfried Luderer may have some further background, in particular on how this work relates to earlier distributed file system projects at Bell Labs.
Would anybody have a current e-mail address for him?
Paul
From tuhs at cuzuco.com Sat Jan 2 13:06:35 2021
From: tuhs at cuzuco.com (Brian Walden)
Date: Fri, 1 Jan 2021 22:06:35 -0500 (EST)
Subject: [TUHS] G.W.R. Luderer
Message-ID: <202101020306.10236ZN2009644@cuzuco.com>
His autobiography, Go West, Young German! states it is luderer at asu.edu -- but that was published a decade ago.
Paul Ruizendaal (pnr at planet.nl) wrote:
>
> I am looking for some more background on the 1980/81 "S/F-Unix" system.
>
> Gottfried W. R. Luderer, H. Che, J. P. Haggerty, Peter A. Kirslis, W. T. Marshall:
> A Distributed UNIX System Based on a Virtual Circuit Switch. SOSP 1981: 160-168
> I have that paper, and Bill Marshall was kind enough to provide a lot of info. I think that Gottfried Luderer may have some further background, in particular on how this work relates to earlier distributed file system projects at Bell Labs.
>
> Would anybody have a current e-mail address for him?
>
> Paul
From dds at aueb.gr Sun Jan 3 01:44:48 2021
From: dds at aueb.gr (Diomidis Spinellis)
Date: Sat, 2 Jan 2021 17:44:48 +0200
Subject: [TUHS] Reviving the Research Unix speak(6) program
Message-ID: <4b3f4251-bdff-16ad-9c1f-8f16989401fd@aueb.gr>
Happy new year to all!
Over the holidays I found some time to port the recovered version of
speak(6) to modern Unix systems and make its output compatible with the
espeak system. The resulting sound is barely intelligible. I assume
this is due to the imperfect matching between the speak and espeak
phonemes. The process's details are available at
https://www.spinellis.gr/blog/20210102#tu and the code at
https://github.com/dspinellis/speak.
Diomidis
From egbegb2 at gmail.com Sun Jan 3 20:13:56 2021
From: egbegb2 at gmail.com (Ed Bradford)
Date: Sun, 3 Jan 2021 04:13:56 -0600
Subject: [TUHS] Question
Message-ID: <CAHTagfFxd+BA-qHt=g+-VbWbHzr_rT1HfP6VVExnbcqxQGvkkg@mail.gmail.com>
I was a BTL person for 8 years between 1976 and 1984. During that time
there was a spelling corrector that was better than anything I see today.
There was a concept of "spelling distance" that corrected a whole bunch of
stuff that even today cannot be corrected.
Who in that era worked on spelling correction at BTL. I was at Columbus BTL
(1976-1979) and Whippany BTL (1979-1984).
Who ever did that stuff should patent it and sell it. Today there is
nothing like it.
--
Advice is judged by results, not by intentions.
Cicero
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210103/009370fd/attachment.htm>
From m.douglas.mcilroy at dartmouth.edu Mon Jan 4 06:23:15 2021
From: m.douglas.mcilroy at dartmouth.edu (M Douglas McIlroy)
Date: Sun, 3 Jan 2021 15:23:15 -0500
Subject: [TUHS] Question
Message-ID: <CAKH6PiW9ikWD6j4qYmsF_+Z4YcnApKJwO=if0W4ssHo6JUW+QA@mail.gmail.com>
> I was a BTL person for 8 years between 1976 and 1984. During
> that time there was a spelling corrector that was better than
> anything I see today. There was a concept of "spelling distance"
> that corrected a whole bunch of stuff that even today cannot be >
corrected.
> Who in that era worked on spelling correction at BTL. I was at
> Columbus BTL (1976-1979) and Whippany BTL (1979-1984).
Peter Nelson made an interface to spell(1) that showed putative errors in
context. I believe it could suggest corrections. I remember the project; I
installed hooks for it in spell(1). I don't remember the date, but it would
probably not have been early enough for you to have used it in Columbus.
If there's a chance that Peter's program is the one you remember
and you'd like to get in touch with him, I can give you his
email address.
Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210103/8c561848/attachment.htm>
From pnr at planet.nl Mon Jan 4 06:50:38 2021
From: pnr at planet.nl (Paul Ruizendaal)
Date: Sun, 3 Jan 2021 21:50:38 +0100
Subject: [TUHS] The "File Store" at mid 1970's Murray Hill
Message-ID: <3917C548-A152-460D-A566-D72EEB8DF5B0@planet.nl>
Sandy Fraser was kind enough to share some papers from his archive that give further background to early networking at Bell Labs. One of these is about the “File Storeâ€.
For context I refer to an article that Sandy wrote back in 1975 and describes the network setup at Murray Hill at that time:
https://drive.google.com/file/d/1_kg4CEsbGucsU8-jxi0ptfUdsznWcKWm/view?usp=sharing
In the figure and legenda at the bottom of page 52/53, the "File Store" is item 10.
The File Store paper itself is (temporarily) here:
https://drive.google.com/file/d/1AhLmjJcHXFtfoIUlfvl0bzbB0zSPzpSq/view?usp=sharing
The paper has a very interesting introduction: “Five machines currently use the file store. Three of them use it as if were a peripheral device not part of their main backing store. In these cases there exists programs to transmit complete files between the user’s machine and the file store."
This was known and Noel Chiappa found the source for the main transfer program “nfs†(this program is also mentioned in Doug McIllroy’s manual compendium):
https://chiselapp.com/user/pnr/repository/Spider/tree?ci=tip
The introduction continues: “In the other two cases the file store is treated as an extension of the user machine’s backing store. Once a user has opened a file his program does reads, writes, and seeks without being aware of the file’s actual location.â€
This -- to me at least -- is a new fact and as such it would predate various other projects for a distributed Unix file system (the paper is dated December 1974). Unfortunately, the paper is short on how the integration was achieved.
On one hand the work may have been related to "Peripheral Unix†as developed by Heinz Lycklama (https://www.tuhs.org/Archive/Documentation/TechReports/Heinz_Tech_Memos/TM-75-1352-2_Emulation_of_UNIX_on_Peripheral_Processors_19750109.pdf) at the same time -- the memos are dated just a month apart. In essence the approach is to forward system calls over the network 1).
Another possibility is that it worked much like the 1979 “RIDE†system (https://www.computer.org/csdl/proceedings-article/cmpsac/1979/00762533/12OmNzd7c1v). Here there is a modified C library that recognises certain path names and maps these to file server calls.
A third possibility is that it was a precursor to the work on distributed Unix by Luderer et al. in 1980/81 (https://dl.acm.org/doi/abs/10.1145/1067627.806604). Here file system calls are redirected at the kernel level using the concept of a remote/forwarding inode.
The File Store paper mentions that the server is a modified Unix. At first glance it would seem that the modifications are modest, with the file system partly rewritten to account for storage usage, and an automatic backup feature added.
I am much interested in any recollections, insights and materials about these topics.
Many thanks in advance,
Paul
Note 1)
The tech report on the “high speed serial loop†(the Weller loop) has not surfaced yet, but the document for the Glance terminal gives a quick, high level overview on page 3/4:
https://www.tuhs.org/Archive/Documentation/TechReports/Heinz_Tech_Memos/TM-75-1352-3_GLANCE_Terminals_on_UNIX_Time-Sharing_19750303.pdf
The recent 516 documents include a detailed description of how it worked:
https://www.tuhs.org/Archive/Documentation/Other/516-TSS/516-10-11-12-Ring-Formats.pdf
From peter at rulingia.com Mon Jan 4 18:22:00 2021
From: peter at rulingia.com (Peter Jeremy)
Date: Mon, 4 Jan 2021 19:22:00 +1100
Subject: [TUHS] The 2038 bug...
In-Reply-To: <alpine.BSF.2.21.9999.2012311806460.82237@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.2012311806460.82237@aneurin.horsfall.org>
Message-ID: <X/LQKPMbiMF45KMJ@server.rulingia.com>
On 2020-Dec-31 18:19:39 +1100, Dave Horsfall <dave at horsfall.org> wrote:
>As the new year is about to kick in (down-under anyway), it got me to
>thinking (always dangerous): how many here will be around for it to pick
>up the pieces that are no doubt still lying around?
Alternatively, my understanding is that the Unix epoch changed on
several occasions in the early days. Presumably the knowledge of
how to achieve this hasn't been lost. (Though actually performing
an epoch rollover may be more difficult today).
I suspect that 2038 may actually wind up being more serious than Y2K
because there are now far more embedded systems than there were then
but it's not clear that the designers of those systems learnt the
lesson from Y2K. A few weeks ago I tried to count the number of
CPUs in my bedroom, bathroom and study - my best guess is around 2
dozen. Admittedly, I think relatively few of those will be concerned
about epoch rollover.
Plus 2038 is merely one epoch. Someone mentioned the Microsoft epoch
rolling over in 2048. Between those two, the IBM S/360 epoch rolls
over in 2042 - the Z-series appears to have glued another 8 bits onto
the MSB end of the TOD clock but that won't help all those S/360 and
S/370 binaries that are still being run. And they are just the well-
known ones. I expect that there are lots of embedded systems running
custom epochs with weird rollover dates.
--
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210104/6182bc6e/attachment.sig>
From egbegb2 at gmail.com Mon Jan 4 18:58:58 2021
From: egbegb2 at gmail.com (Ed Bradford)
Date: Mon, 4 Jan 2021 02:58:58 -0600
Subject: [TUHS] Question
In-Reply-To: <CAKH6PiW9ikWD6j4qYmsF_+Z4YcnApKJwO=if0W4ssHo6JUW+QA@mail.gmail.com>
References: <CAKH6PiW9ikWD6j4qYmsF_+Z4YcnApKJwO=if0W4ssHo6JUW+QA@mail.gmail.com>
Message-ID: <CAHTagfFgpoM29QncKruu6QO2z75H7fwHCEhJtP-v7Y=bAoJeOw@mail.gmail.com>
Thank you for responding. My recollection is that one of your
folks put the spelling corrector into the shell so when I typed
the wrong letters for a directory or file, the spelling correct
would help. It was particularly noticible in the "chdir - cd" shell
command. Do you recall any such person and if so, did he (and it
was a he) use Peter's work?
There was a distance algorithm that was far better than anything I've seen
since. Yes, please send me Peter's contact information.
I am
Ed Bradford, Ph.D. Physics, retired from IBM
Pflugerville,TX
egbegb2 at gmail.com
PS: We chatted sometime in 1980 or so about
adding database capabilities to the interactive
environment. I was interested in adding it to
the Bourne Shell at the time.
On Sun, Jan 3, 2021 at 2:23 PM M Douglas McIlroy <
m.douglas.mcilroy at dartmouth.edu> wrote:
> > I was a BTL person for 8 years between 1976 and 1984. During
> > that time there was a spelling corrector that was better than
> > anything I see today. There was a concept of "spelling distance"
> > that corrected a whole bunch of stuff that even today cannot be >
> corrected.
>
> > Who in that era worked on spelling correction at BTL. I was at
> > Columbus BTL (1976-1979) and Whippany BTL (1979-1984).
>
> Peter Nelson made an interface to spell(1) that showed putative errors in
> context. I believe it could suggest corrections. I remember the project; I
> installed hooks for it in spell(1). I don't remember the date, but it would
> probably not have been early enough for you to have used it in Columbus.
>
> If there's a chance that Peter's program is the one you remember
> and you'd like to get in touch with him, I can give you his
> email address.
>
> Doug
>
--
Advice is judged by results, not by intentions.
Cicero
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210104/0783496e/attachment.htm>
From spedraja at gmail.com Mon Jan 4 18:59:21 2021
From: spedraja at gmail.com (Sergio Pedraja)
Date: Mon, 4 Jan 2021 09:59:21 +0100
Subject: [TUHS] The 2038 bug...
In-Reply-To: <alpine.BSF.2.21.9999.2012311806460.82237@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.2012311806460.82237@aneurin.horsfall.org>
Message-ID: <CACytpF8TM2WsZ-8a+FWVXs5CM+y+uf5uF2=nU0s0PPbiMGCsxQ@mail.gmail.com>
Great choice, talking as Sci-fi fan (from my childhood). It was published
in Spain (my country) by 1968.
El jue., 31 dic. 2020 8:21, Dave Horsfall <dave at horsfall.org> escribió:
>
> 2100? Forget it... Too bad, as "Revolt in 2100 (?)" is one of my
> favourite Heinlein books.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210104/3994ff99/attachment.htm>
From robpike at gmail.com Mon Jan 4 19:07:43 2021
From: robpike at gmail.com (Rob Pike)
Date: Mon, 4 Jan 2021 20:07:43 +1100
Subject: [TUHS] Question
In-Reply-To: <CAHTagfFgpoM29QncKruu6QO2z75H7fwHCEhJtP-v7Y=bAoJeOw@mail.gmail.com>
References: <CAKH6PiW9ikWD6j4qYmsF_+Z4YcnApKJwO=if0W4ssHo6JUW+QA@mail.gmail.com>
<CAHTagfFgpoM29QncKruu6QO2z75H7fwHCEhJtP-v7Y=bAoJeOw@mail.gmail.com>
Message-ID: <CAKzdPgxZusPhf_WRPBrR0kwn9ah31izHseKj4KBKVxbOunkj2w@mail.gmail.com>
That was done by Tom Duff, I believe before he came to Bell Labs. I might
have brought the idea with me from Toronto. The code, or at least a simple
version of it, is in The Unix Programming Environment starting around page
208. We credit Tom in the endnotes for the chapter.
-rob
On Mon, Jan 4, 2021 at 8:00 PM Ed Bradford <egbegb2 at gmail.com> wrote:
> Thank you for responding. My recollection is that one of your
> folks put the spelling corrector into the shell so when I typed
> the wrong letters for a directory or file, the spelling correct
> would help. It was particularly noticible in the "chdir - cd" shell
> command. Do you recall any such person and if so, did he (and it
> was a he) use Peter's work?
>
> There was a distance algorithm that was far better than anything I've seen
> since. Yes, please send me Peter's contact information.
>
> I am
>
> Ed Bradford, Ph.D. Physics, retired from IBM
> Pflugerville,TX
> egbegb2 at gmail.com
>
> PS: We chatted sometime in 1980 or so about
> adding database capabilities to the interactive
> environment. I was interested in adding it to
> the Bourne Shell at the time.
>
> On Sun, Jan 3, 2021 at 2:23 PM M Douglas McIlroy <
> m.douglas.mcilroy at dartmouth.edu> wrote:
>
>> > I was a BTL person for 8 years between 1976 and 1984. During
>> > that time there was a spelling corrector that was better than
>> > anything I see today. There was a concept of "spelling distance"
>> > that corrected a whole bunch of stuff that even today cannot be >
>> corrected.
>>
>> > Who in that era worked on spelling correction at BTL. I was at
>> > Columbus BTL (1976-1979) and Whippany BTL (1979-1984).
>>
>> Peter Nelson made an interface to spell(1) that showed putative errors in
>> context. I believe it could suggest corrections. I remember the project; I
>> installed hooks for it in spell(1). I don't remember the date, but it would
>> probably not have been early enough for you to have used it in Columbus.
>>
>> If there's a chance that Peter's program is the one you remember
>> and you'd like to get in touch with him, I can give you his
>> email address.
>>
>> Doug
>>
>
>
> --
> Advice is judged by results, not by intentions.
> Cicero
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210104/ef2bd72d/attachment.htm>
From arnold at skeeve.com Mon Jan 4 19:08:09 2021
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Mon, 04 Jan 2021 02:08:09 -0700
Subject: [TUHS] Question
In-Reply-To: <CAHTagfFgpoM29QncKruu6QO2z75H7fwHCEhJtP-v7Y=bAoJeOw@mail.gmail.com>
References: <CAKH6PiW9ikWD6j4qYmsF_+Z4YcnApKJwO=if0W4ssHo6JUW+QA@mail.gmail.com>
<CAHTagfFgpoM29QncKruu6QO2z75H7fwHCEhJtP-v7Y=bAoJeOw@mail.gmail.com>
Message-ID: <202101040908.104989TF022830@freefriends.org>
The spelling corrector in the shell rings vague bell. I think
it's in the 8th or 9th edition Bourne shell. You should be able to
find those in the archives.
Geoff Collyer has a modern port of the V9 shell at
http://www.collyer.net/who/geoff/v9sh.tar.
HTH,
Arnold
Ed Bradford <egbegb2 at gmail.com> wrote:
> Thank you for responding. My recollection is that one of your
> folks put the spelling corrector into the shell so when I typed
> the wrong letters for a directory or file, the spelling correct
> would help. It was particularly noticible in the "chdir - cd" shell
> command. Do you recall any such person and if so, did he (and it
> was a he) use Peter's work?
>
> There was a distance algorithm that was far better than anything I've seen
> since. Yes, please send me Peter's contact information.
>
> I am
>
> Ed Bradford, Ph.D. Physics, retired from IBM
> Pflugerville,TX
> egbegb2 at gmail.com
>
> PS: We chatted sometime in 1980 or so about
> adding database capabilities to the interactive
> environment. I was interested in adding it to
> the Bourne Shell at the time.
>
> On Sun, Jan 3, 2021 at 2:23 PM M Douglas McIlroy <
> m.douglas.mcilroy at dartmouth.edu> wrote:
>
> > > I was a BTL person for 8 years between 1976 and 1984. During
> > > that time there was a spelling corrector that was better than
> > > anything I see today. There was a concept of "spelling distance"
> > > that corrected a whole bunch of stuff that even today cannot be >
> > corrected.
> >
> > > Who in that era worked on spelling correction at BTL. I was at
> > > Columbus BTL (1976-1979) and Whippany BTL (1979-1984).
> >
> > Peter Nelson made an interface to spell(1) that showed putative errors in
> > context. I believe it could suggest corrections. I remember the project; I
> > installed hooks for it in spell(1). I don't remember the date, but it would
> > probably not have been early enough for you to have used it in Columbus.
> >
> > If there's a chance that Peter's program is the one you remember
> > and you'd like to get in touch with him, I can give you his
> > email address.
> >
> > Doug
> >
>
>
> --
> Advice is judged by results, not by intentions.
> Cicero
From nikke.karlsson at gmail.com Mon Jan 4 19:12:51 2021
From: nikke.karlsson at gmail.com (Niklas Karlsson)
Date: Mon, 4 Jan 2021 10:12:51 +0100
Subject: [TUHS] Question
In-Reply-To: <CAKzdPgxZusPhf_WRPBrR0kwn9ah31izHseKj4KBKVxbOunkj2w@mail.gmail.com>
References: <CAKH6PiW9ikWD6j4qYmsF_+Z4YcnApKJwO=if0W4ssHo6JUW+QA@mail.gmail.com>
<CAHTagfFgpoM29QncKruu6QO2z75H7fwHCEhJtP-v7Y=bAoJeOw@mail.gmail.com>
<CAKzdPgxZusPhf_WRPBrR0kwn9ah31izHseKj4KBKVxbOunkj2w@mail.gmail.com>
Message-ID: <CAK6BEgfe=0_RvxVvXPCS-aBdjxac6sEw6SnPub4duwXMKzsyDg@mail.gmail.com>
Ah, he of the infamous Device? Interesting.
Niklas
Den mån 4 jan. 2021 kl 10:08 skrev Rob Pike <robpike at gmail.com>:
> That was done by Tom Duff, I believe before he came to Bell Labs. I might
> have brought the idea with me from Toronto. The code, or at least a simple
> version of it, is in The Unix Programming Environment starting around page
> 208. We credit Tom in the endnotes for the chapter.
>
> -rob
>
>
> On Mon, Jan 4, 2021 at 8:00 PM Ed Bradford <egbegb2 at gmail.com> wrote:
>
>> Thank you for responding. My recollection is that one of your
>> folks put the spelling corrector into the shell so when I typed
>> the wrong letters for a directory or file, the spelling correct
>> would help. It was particularly noticible in the "chdir - cd" shell
>> command. Do you recall any such person and if so, did he (and it
>> was a he) use Peter's work?
>>
>> There was a distance algorithm that was far better than anything I've seen
>> since. Yes, please send me Peter's contact information.
>>
>> I am
>>
>> Ed Bradford, Ph.D. Physics, retired from IBM
>> Pflugerville,TX
>> egbegb2 at gmail.com
>>
>> PS: We chatted sometime in 1980 or so about
>> adding database capabilities to the interactive
>> environment. I was interested in adding it to
>> the Bourne Shell at the time.
>>
>> On Sun, Jan 3, 2021 at 2:23 PM M Douglas McIlroy <
>> m.douglas.mcilroy at dartmouth.edu> wrote:
>>
>>> > I was a BTL person for 8 years between 1976 and 1984. During
>>> > that time there was a spelling corrector that was better than
>>> > anything I see today. There was a concept of "spelling distance"
>>> > that corrected a whole bunch of stuff that even today cannot be >
>>> corrected.
>>>
>>> > Who in that era worked on spelling correction at BTL. I was at
>>> > Columbus BTL (1976-1979) and Whippany BTL (1979-1984).
>>>
>>> Peter Nelson made an interface to spell(1) that showed putative errors
>>> in context. I believe it could suggest corrections. I remember the project;
>>> I installed hooks for it in spell(1). I don't remember the date, but it
>>> would probably not have been early enough for you to have used it in
>>> Columbus.
>>>
>>> If there's a chance that Peter's program is the one you remember
>>> and you'd like to get in touch with him, I can give you his
>>> email address.
>>>
>>> Doug
>>>
>>
>>
>> --
>> Advice is judged by results, not by intentions.
>> Cicero
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210104/c590f3f2/attachment.htm>
From angus at fairhaven.za.net Mon Jan 4 19:13:40 2021
From: angus at fairhaven.za.net (Angus Robinson)
Date: Mon, 4 Jan 2021 11:13:40 +0200
Subject: [TUHS] The 2038 bug...
In-Reply-To: <X/LQKPMbiMF45KMJ@server.rulingia.com>
References: <alpine.BSF.2.21.9999.2012311806460.82237@aneurin.horsfall.org>
<X/LQKPMbiMF45KMJ@server.rulingia.com>
Message-ID: <CAE49LGmHVnwEeC7y9tNAN5qYJ2NpjBy5=Gzy7_fC8HcmHoD_MA@mail.gmail.com>
One wonders if pacemakers or any other devices that are inserted into the
human body by then would be susceptible to the 2038 bug as well.
Kind Regards,
Angus Robinson
On Mon, Jan 4, 2021 at 10:46 AM Peter Jeremy via TUHS <tuhs at minnie.tuhs.org>
wrote:
> On 2020-Dec-31 18:19:39 +1100, Dave Horsfall <dave at horsfall.org> wrote:
> >As the new year is about to kick in (down-under anyway), it got me to
> >thinking (always dangerous): how many here will be around for it to pick
> >up the pieces that are no doubt still lying around?
>
> Alternatively, my understanding is that the Unix epoch changed on
> several occasions in the early days. Presumably the knowledge of
> how to achieve this hasn't been lost. (Though actually performing
> an epoch rollover may be more difficult today).
>
> I suspect that 2038 may actually wind up being more serious than Y2K
> because there are now far more embedded systems than there were then
> but it's not clear that the designers of those systems learnt the
> lesson from Y2K. A few weeks ago I tried to count the number of
> CPUs in my bedroom, bathroom and study - my best guess is around 2
> dozen. Admittedly, I think relatively few of those will be concerned
> about epoch rollover.
>
> Plus 2038 is merely one epoch. Someone mentioned the Microsoft epoch
> rolling over in 2048. Between those two, the IBM S/360 epoch rolls
> over in 2042 - the Z-series appears to have glued another 8 bits onto
> the MSB end of the TOD clock but that won't help all those S/360 and
> S/370 binaries that are still being run. And they are just the well-
> known ones. I expect that there are lots of embedded systems running
> custom epochs with weird rollover dates.
>
> --
> Peter Jeremy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210104/1807316e/attachment.htm>
From clemc at ccc.com Tue Jan 5 00:11:26 2021
From: clemc at ccc.com (Clem Cole)
Date: Mon, 4 Jan 2021 09:11:26 -0500
Subject: [TUHS] Question
In-Reply-To: <CAKzdPgxZusPhf_WRPBrR0kwn9ah31izHseKj4KBKVxbOunkj2w@mail.gmail.com>
References: <CAKH6PiW9ikWD6j4qYmsF_+Z4YcnApKJwO=if0W4ssHo6JUW+QA@mail.gmail.com>
<CAHTagfFgpoM29QncKruu6QO2z75H7fwHCEhJtP-v7Y=bAoJeOw@mail.gmail.com>
<CAKzdPgxZusPhf_WRPBrR0kwn9ah31izHseKj4KBKVxbOunkj2w@mail.gmail.com>
Message-ID: <CAC20D2PPNAn_NQSFaZ+mpMT9YeN5OVvoGB-SdJA_UFV=sQC25g@mail.gmail.com>
I also remember a program that was kicking around WH and MH called grope(1)
that IIRC used the algorithms in the code for the 411 operators. Was that
related? I do remember is that had a separate dictionary from spell and
ispell that was stored in /usr/lib/grope/[a-z]/mumble
á§
On Mon, Jan 4, 2021 at 4:08 AM Rob Pike <robpike at gmail.com> wrote:
> That was done by Tom Duff, I believe before he came to Bell Labs. I might
> have brought the idea with me from Toronto. The code, or at least a simple
> version of it, is in The Unix Programming Environment starting around page
> 208. We credit Tom in the endnotes for the chapter.
>
> -rob
>
>
> On Mon, Jan 4, 2021 at 8:00 PM Ed Bradford <egbegb2 at gmail.com> wrote:
>
>> Thank you for responding. My recollection is that one of your
>> folks put the spelling corrector into the shell so when I typed
>> the wrong letters for a directory or file, the spelling correct
>> would help. It was particularly noticible in the "chdir - cd" shell
>> command. Do you recall any such person and if so, did he (and it
>> was a he) use Peter's work?
>>
>> There was a distance algorithm that was far better than anything I've seen
>> since. Yes, please send me Peter's contact information.
>>
>> I am
>>
>> Ed Bradford, Ph.D. Physics, retired from IBM
>> Pflugerville,TX
>> egbegb2 at gmail.com
>>
>> PS: We chatted sometime in 1980 or so about
>> adding database capabilities to the interactive
>> environment. I was interested in adding it to
>> the Bourne Shell at the time.
>>
>> On Sun, Jan 3, 2021 at 2:23 PM M Douglas McIlroy <
>> m.douglas.mcilroy at dartmouth.edu> wrote:
>>
>>> > I was a BTL person for 8 years between 1976 and 1984. During
>>> > that time there was a spelling corrector that was better than
>>> > anything I see today. There was a concept of "spelling distance"
>>> > that corrected a whole bunch of stuff that even today cannot be >
>>> corrected.
>>>
>>> > Who in that era worked on spelling correction at BTL. I was at
>>> > Columbus BTL (1976-1979) and Whippany BTL (1979-1984).
>>>
>>> Peter Nelson made an interface to spell(1) that showed putative errors
>>> in context. I believe it could suggest corrections. I remember the project;
>>> I installed hooks for it in spell(1). I don't remember the date, but it
>>> would probably not have been early enough for you to have used it in
>>> Columbus.
>>>
>>> If there's a chance that Peter's program is the one you remember
>>> and you'd like to get in touch with him, I can give you his
>>> email address.
>>>
>>> Doug
>>>
>>
>>
>> --
>> Advice is judged by results, not by intentions.
>> Cicero
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210104/0f8e3e5b/attachment.htm>
From jpl.jpl at gmail.com Tue Jan 5 01:39:24 2021
From: jpl.jpl at gmail.com (John P. Linderman)
Date: Mon, 4 Jan 2021 10:39:24 -0500
Subject: [TUHS] Question
In-Reply-To: <CAC20D2PPNAn_NQSFaZ+mpMT9YeN5OVvoGB-SdJA_UFV=sQC25g@mail.gmail.com>
References: <CAKH6PiW9ikWD6j4qYmsF_+Z4YcnApKJwO=if0W4ssHo6JUW+QA@mail.gmail.com>
<CAHTagfFgpoM29QncKruu6QO2z75H7fwHCEhJtP-v7Y=bAoJeOw@mail.gmail.com>
<CAKzdPgxZusPhf_WRPBrR0kwn9ah31izHseKj4KBKVxbOunkj2w@mail.gmail.com>
<CAC20D2PPNAn_NQSFaZ+mpMT9YeN5OVvoGB-SdJA_UFV=sQC25g@mail.gmail.com>
Message-ID: <CAC0cEp8R3CvTCg+sv5v48si06hYYcEGQtW-FAjnHeYe+siH_hw@mail.gmail.com>
I still have the grope source. It starts with
/**************************************************
* GROPE - spelling correction - Bill Taylor - Dept 43231
*
* The information contained herein is for the use of BELL LABORATORIES
* and is not for publication. (See GEI 13.9-3)
***************************************************/
but I have been told by people I trust that the algorithm is really due to
Tom Szymanski. I have used the algorithm for matching city and street names
from the US Postal Service, and it did very well, quite a bit better than
the Levenshtein algorithm, for that application. It worked well for
"ordinary" dictionary matching, but would have been ghastly for things like
approximate matching of DNA base pairs.
Don't get me started about automating directory lookup. That was my first
BTL project in the Business Information System division in the early 70s.
It was obviously superior to paper records, and we had no trouble pitching
up the corporate ladder until we got to the executive director level. In a
blaze of insight, he asserted that microfilm had stolen the market,
whereupon our director executed a light-speed 180 about supporting the
project, and it died. The executive director later became Vice President of
Electronic Information Systems at Western Electric.
On Mon, Jan 4, 2021 at 9:13 AM Clem Cole <clemc at ccc.com> wrote:
> I also remember a program that was kicking around WH and MH called
> grope(1) that IIRC used the algorithms in the code for the 411 operators.
> Was that related? I do remember is that had a separate dictionary from
> spell and ispell that was stored in /usr/lib/grope/[a-z]/mumble
> á§
>
> On Mon, Jan 4, 2021 at 4:08 AM Rob Pike <robpike at gmail.com> wrote:
>
>> That was done by Tom Duff, I believe before he came to Bell Labs. I might
>> have brought the idea with me from Toronto. The code, or at least a simple
>> version of it, is in The Unix Programming Environment starting around page
>> 208. We credit Tom in the endnotes for the chapter.
>>
>> -rob
>>
>>
>> On Mon, Jan 4, 2021 at 8:00 PM Ed Bradford <egbegb2 at gmail.com> wrote:
>>
>>> Thank you for responding. My recollection is that one of your
>>> folks put the spelling corrector into the shell so when I typed
>>> the wrong letters for a directory or file, the spelling correct
>>> would help. It was particularly noticible in the "chdir - cd" shell
>>> command. Do you recall any such person and if so, did he (and it
>>> was a he) use Peter's work?
>>>
>>> There was a distance algorithm that was far better than anything I've
>>> seen
>>> since. Yes, please send me Peter's contact information.
>>>
>>> I am
>>>
>>> Ed Bradford, Ph.D. Physics, retired from IBM
>>> Pflugerville,TX
>>> egbegb2 at gmail.com
>>>
>>> PS: We chatted sometime in 1980 or so about
>>> adding database capabilities to the interactive
>>> environment. I was interested in adding it to
>>> the Bourne Shell at the time.
>>>
>>> On Sun, Jan 3, 2021 at 2:23 PM M Douglas McIlroy <
>>> m.douglas.mcilroy at dartmouth.edu> wrote:
>>>
>>>> > I was a BTL person for 8 years between 1976 and 1984. During
>>>> > that time there was a spelling corrector that was better than
>>>> > anything I see today. There was a concept of "spelling distance"
>>>> > that corrected a whole bunch of stuff that even today cannot be >
>>>> corrected.
>>>>
>>>> > Who in that era worked on spelling correction at BTL. I was at
>>>> > Columbus BTL (1976-1979) and Whippany BTL (1979-1984).
>>>>
>>>> Peter Nelson made an interface to spell(1) that showed putative errors
>>>> in context. I believe it could suggest corrections. I remember the project;
>>>> I installed hooks for it in spell(1). I don't remember the date, but it
>>>> would probably not have been early enough for you to have used it in
>>>> Columbus.
>>>>
>>>> If there's a chance that Peter's program is the one you remember
>>>> and you'd like to get in touch with him, I can give you his
>>>> email address.
>>>>
>>>> Doug
>>>>
>>>
>>>
>>> --
>>> Advice is judged by results, not by intentions.
>>> Cicero
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210104/b5e00857/attachment.htm>
From dave at horsfall.org Tue Jan 5 07:49:32 2021
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 5 Jan 2021 08:49:32 +1100 (EST)
Subject: [TUHS] The 2038 bug...
In-Reply-To: <X/LQKPMbiMF45KMJ@server.rulingia.com>
References: <alpine.BSF.2.21.9999.2012311806460.82237@aneurin.horsfall.org>
<X/LQKPMbiMF45KMJ@server.rulingia.com>
Message-ID: <alpine.BSF.2.21.9999.2101050822330.26789@aneurin.horsfall.org>
On Mon, 4 Jan 2021, Peter Jeremy wrote:
> Alternatively, my understanding is that the Unix epoch changed on
> several occasions in the early days. Presumably the knowledge of how to
> achieve this hasn't been lost. (Though actually performing an epoch
> rollover may be more difficult today).
My understanding is that it's been 1st Jan 1970 since at least Ed5, if not
Ed6.
> I suspect that 2038 may actually wind up being more serious than Y2K
> because there are now far more embedded systems than there were then but
> it's not clear that the designers of those systems learnt the lesson
> from Y2K. A few weeks ago I tried to count the number of CPUs in my
> bedroom, bathroom and study - my best guess is around 2 dozen.
> Admittedly, I think relatively few of those will be concerned about
> epoch rollover.
The only systems I have that would care would be the various computers,
and they are all NTP-synced (except the NBN modem/router takes its time
from T$).
> Plus 2038 is merely one epoch. Someone mentioned the Microsoft epoch
> rolling over in 2048. Between those two, the IBM S/360 epoch rolls over
> in 2042 - the Z-series appears to have glued another 8 bits onto the MSB
> end of the TOD clock but that won't help all those S/360 and S/370
> binaries that are still being run. And they are just the well- known
> ones. I expect that there are lots of embedded systems running custom
> epochs with weird rollover dates.
Well, I don't care about the M$ epoch, and at 86 I might even get to see
the world come to a grinding halt :-) Of course, I may be reliant upon M$
systems in hospitals etc...
Interesting story about the S/360 though. As a side-issue I wonder how
many COBOL programmers will still be around to maintain all that payroll
software etc?
-- Dave, who's kept his COBOL knowledge a secret in every job
From imp at bsdimp.com Tue Jan 5 07:56:46 2021
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 4 Jan 2021 14:56:46 -0700
Subject: [TUHS] The 2038 bug...
In-Reply-To: <alpine.BSF.2.21.9999.2101050822330.26789@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.2012311806460.82237@aneurin.horsfall.org>
<X/LQKPMbiMF45KMJ@server.rulingia.com>
<alpine.BSF.2.21.9999.2101050822330.26789@aneurin.horsfall.org>
Message-ID: <CANCZdfqHgLXLccOAyzJPkMyqtpZGd1TyEof_w_8LgYo=De=T0g@mail.gmail.com>
On Mon, Jan 4, 2021 at 2:50 PM Dave Horsfall <dave at horsfall.org> wrote:
> On Mon, 4 Jan 2021, Peter Jeremy wrote:
>
> > Alternatively, my understanding is that the Unix epoch changed on
> > several occasions in the early days. Presumably the knowledge of how to
> > achieve this hasn't been lost. (Though actually performing an epoch
> > rollover may be more difficult today).
>
> My understanding is that it's been 1st Jan 1970 since at least Ed5, if not
> Ed6.
>
It's been that way since the 4th edition.
In the 3rd edition it was the number of 60Hz ticks since 1972, along with
this note: "This guarantees a crisis every 2.26 years."
Rebasing the epoch would be... tricky... lots of math is done assuming an
origin of 1970, and not all of it is obvious to even concerted analysis.
Less ugly would be to declare time_t to be unsigned instead of signed...
It would break less code... Making time_t 64 bits also breaks code, even if
you declare you don't care about binary compat since many older apps know
time_t is 32-bits.
Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210104/8eecce78/attachment-0001.htm>
From rudi.j.blom at gmail.com Tue Jan 5 14:36:01 2021
From: rudi.j.blom at gmail.com (Rudi Blom)
Date: Tue, 5 Jan 2021 11:36:01 +0700
Subject: [TUHS] Question
Message-ID: <CAMYpm86DWAxCLZbtLY2=bNu+ca4Kut0WVsVJ9FVAeFbDQuwjPg@mail.gmail.com>
The spell check in 'cd' commands I remember from SCO UNIX 3.2
The 'sh' manual page has
Spelling checker
When using cd(C) the shell checks spelling. For example, if you change to
a different directory using cd and misspell the directory name, the shell
responds with an alternative spelling of an existing directory. Enter
``y'' and press <Return> (or just press <Return>) to change to the
offered directory. If the offered spelling is incorrect, enter ``n'',
then retype the command line. In this example the sh(C) response is
boldfaced:
$ cd /usr/spol/uucp
cd /usr/spool/uucp?y
ok
Cheers,
uncle rubl
>Date: Mon, 04 Jan 2021 02:08:09 -0700
>From: arnold at skeeve.com
>To: m.douglas.mcilroy at dartmouth.edu, egbegb2 at gmail.com
>Cc: tuhs at tuhs.org
>Subject: Re: [TUHS] Question
>Message-ID: <202101040908.104989TF022830 at freefriends.org>
>Content-Type: text/plain; charset=us-ascii
>
>The spelling corrector in the shell rings vague bell. I think
>it's in the 8th or 9th edition Bourne shell. You should be able to
>find those in the archives.
>
>Geoff Collyer has a modern port of the V9 shell at
>http://www.collyer.net/who/geoff/v9sh.tar.
>
>HTH,
.>
>Arnold
From crossd at gmail.com Wed Jan 6 04:05:58 2021
From: crossd at gmail.com (Dan Cross)
Date: Tue, 5 Jan 2021 13:05:58 -0500
Subject: [TUHS] The 2038 bug...
In-Reply-To: <CANCZdfqHgLXLccOAyzJPkMyqtpZGd1TyEof_w_8LgYo=De=T0g@mail.gmail.com>
References: <alpine.BSF.2.21.9999.2012311806460.82237@aneurin.horsfall.org>
<X/LQKPMbiMF45KMJ@server.rulingia.com>
<alpine.BSF.2.21.9999.2101050822330.26789@aneurin.horsfall.org>
<CANCZdfqHgLXLccOAyzJPkMyqtpZGd1TyEof_w_8LgYo=De=T0g@mail.gmail.com>
Message-ID: <CAEoi9W45JKsAkeRFbPvYXF6298dJY6EoPeB6rFs6u8k+PuvM7Q@mail.gmail.com>
On Mon, Jan 4, 2021 at 4:57 PM Warner Losh <imp at bsdimp.com> wrote:
> On Mon, Jan 4, 2021 at 2:50 PM Dave Horsfall <dave at horsfall.org> wrote:
>
>> On Mon, 4 Jan 2021, Peter Jeremy wrote:
>>
>> > Alternatively, my understanding is that the Unix epoch changed on
>> > several occasions in the early days. Presumably the knowledge of how
>> to
>> > achieve this hasn't been lost. (Though actually performing an epoch
>> > rollover may be more difficult today).
>>
>> My understanding is that it's been 1st Jan 1970 since at least Ed5, if
>> not
>> Ed6.
>>
>
> It's been that way since the 4th edition.
>
> In the 3rd edition it was the number of 60Hz ticks since 1972, along with
> this note: "This guarantees a crisis every 2.26 years."
>
> Rebasing the epoch would be... tricky... lots of math is done assuming an
> origin of 1970, and not all of it is obvious to even concerted analysis.
>
> Less ugly would be to declare time_t to be unsigned instead of signed...
> It would break less code... Making time_t 64 bits also breaks code, even if
> you declare you don't care about binary compat since many older apps know
> time_t is 32-bits.
>
Lots of older code also knew that pointers were 32 bits and could fit into
an int, that the signal bitmask fit into 32 bits, etc. I feel like we have
these crises every few years and we work around them. The issues here are
perfectly familiar.
A saving grace is that the timestamp fields in Unixy filesystems are almost
invariably 64 bits and have been for a few decades now. Unlike y2k, the
persistence issue is largely fixed except for ersatz binary formats, and
most decently-maintained software hides the width of time behind a typedef.
As for Ted's vignette about hand-coded systems in PDP-11 assembler running
under emulation, I think the issue here is somewhat different: in this
case, by and large, the software doesn't need rewriting, but rather
recompilation on a new hardware and/or OS platform, possibly with some
modifications to fix assumptions about type width. That's qualitatively
different from rewriting from scratch in a different language on a
radically different platform. Note I'm talking about Unix and Linux here,
as opposed to other systems with similar epoch issues.
Certainly there will be some breakage in 2038. But I suspect that we'll
pull a y2k and the critical stuff will be mostly fixed by the time the
epoch rolls over. The long tail will be annoying, as it was with y2k, but
not necessarily critical.
- Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210105/964a8eed/attachment.htm>
From imp at bsdimp.com Wed Jan 6 17:21:51 2021
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 6 Jan 2021 00:21:51 -0700
Subject: [TUHS] The 2038 bug...
In-Reply-To: <CAEoi9W45JKsAkeRFbPvYXF6298dJY6EoPeB6rFs6u8k+PuvM7Q@mail.gmail.com>
References: <alpine.BSF.2.21.9999.2012311806460.82237@aneurin.horsfall.org>
<X/LQKPMbiMF45KMJ@server.rulingia.com>
<alpine.BSF.2.21.9999.2101050822330.26789@aneurin.horsfall.org>
<CANCZdfqHgLXLccOAyzJPkMyqtpZGd1TyEof_w_8LgYo=De=T0g@mail.gmail.com>
<CAEoi9W45JKsAkeRFbPvYXF6298dJY6EoPeB6rFs6u8k+PuvM7Q@mail.gmail.com>
Message-ID: <CANCZdfrQr4yYbev2ngk7o2VWahW7=GGfuDENGreepkk=CJizAg@mail.gmail.com>
On Tue, Jan 5, 2021 at 11:06 AM Dan Cross <crossd at gmail.com> wrote:
> On Mon, Jan 4, 2021 at 4:57 PM Warner Losh <imp at bsdimp.com> wrote:
>
>> On Mon, Jan 4, 2021 at 2:50 PM Dave Horsfall <dave at horsfall.org> wrote:
>>
>>> On Mon, 4 Jan 2021, Peter Jeremy wrote:
>>>
>>> > Alternatively, my understanding is that the Unix epoch changed on
>>> > several occasions in the early days. Presumably the knowledge of how
>>> to
>>> > achieve this hasn't been lost. (Though actually performing an epoch
>>> > rollover may be more difficult today).
>>>
>>> My understanding is that it's been 1st Jan 1970 since at least Ed5, if
>>> not
>>> Ed6.
>>>
>>
>> It's been that way since the 4th edition.
>>
>> In the 3rd edition it was the number of 60Hz ticks since 1972, along with
>> this note: "This guarantees a crisis every 2.26 years."
>>
>> Rebasing the epoch would be... tricky... lots of math is done assuming
>> an origin of 1970, and not all of it is obvious to even concerted analysis.
>>
>> Less ugly would be to declare time_t to be unsigned instead of signed...
>> It would break less code... Making time_t 64 bits also breaks code, even if
>> you declare you don't care about binary compat since many older apps know
>> time_t is 32-bits.
>>
>
> Lots of older code also knew that pointers were 32 bits and could fit into
> an int, that the signal bitmask fit into 32 bits, etc. I feel like we have
> these crises every few years and we work around them. The issues here are
> perfectly familiar.
>
True. The issues were understood for years before compilers started warning
about the issue on a wide-scale basis. There's currently no warnings for
many of the common time_t type handling mistakes since they aren't
considered errors in other contexts. So it makes the problem less visible.
> A saving grace is that the timestamp fields in Unixy filesystems are
> almost invariably 64 bits and have been for a few decades now. Unlike y2k,
> the persistence issue is largely fixed except for ersatz binary formats,
> and most decently-maintained software hides the width of time behind a
> typedef. As for Ted's vignette about hand-coded systems in PDP-11 assembler
> running under emulation, I think the issue here is somewhat different: in
> this case, by and large, the software doesn't need rewriting, but rather
> recompilation on a new hardware and/or OS platform, possibly with some
> modifications to fix assumptions about type width. That's qualitatively
> different from rewriting from scratch in a different language on a
> radically different platform. Note I'm talking about Unix and Linux here,
> as opposed to other systems with similar epoch issues.
>
A larger problem, though, is where time_t is 64 bits, but on-disk format is
32-bits... And often times recompiling old software on new systems with
different sized types can be a crap shoot. For software that's well
understood, sure, an analysis can be undertaken, and it will likely work.
For older code, that uses tricks to compute different types of dates, it's
also likely more prone to overflow even with the recompile...
> Certainly there will be some breakage in 2038. But I suspect that we'll
> pull a y2k and the critical stuff will be mostly fixed by the time the
> epoch rolls over. The long tail will be annoying, as it was with y2k, but
> not necessarily critical.
>
I suspect that many of the issues can be fixed between now and then, but
w/o some effort, they will persist... Though it doesn't take too many
errors in a critical system for there to be a catastrophic failure. Without
publicity like y2k got, it's unclear the outcome.
I'll note with pride that my state replaced its unemployment system today
with a new one. The old one was only 44 years old and not even the oldest
in the nation... The long hand of the past appears in unexpected locations
that are resource constrained.
Warner
> - Dan C.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210106/1dd6091b/attachment.htm>
From dario at darioniedermann.it Thu Jan 7 02:32:25 2021
From: dario at darioniedermann.it (Dario Niedermann)
Date: Wed, 6 Jan 2021 17:32:25 +0100
Subject: [TUHS] The 2038 bug...
In-Reply-To: <CANCZdfoKV7A46ho3ORghFZEddROty3A-y2bn1VY0m=ipBxFF6w@mail.gmail.com>
References: <alpine.BSF.2.21.9999.2012311806460.82237@aneurin.horsfall.org>
<CAK6BEgdH7OOsw3p3d_bLsjhR+bv_ZrG9mvVSLa3hgJKhjLVK6w@mail.gmail.com>
<202012310810.0BV8ADZ3027195@freefriends.org>
<CANCZdfoKV7A46ho3ORghFZEddROty3A-y2bn1VY0m=ipBxFF6w@mail.gmail.com>
Message-ID: <20210106163225.GC2973@darioniedermann.it>
Il 31/12/2020 alle 16:30, Warner Losh ha scritto:
>On Thu, Dec 31, 2020, 1:10 AM <arnold at skeeve.com> wrote:
[...]
>>time_t these days tends to be 64 bits, and I think at least the Linux
>>file systems store them that way.
>
>Time_t was still 32 bits last I checked on i386 and a few others...
On recent Linux/i386 kernels it's actually 64 bits. In practice, only
users who are stuck with old i386 Linux versions will have a problem.
--
Dario Niedermann -:- finger my email address for PGP key, etc.
Also on the Internet at: <gopher://darioniedermann.it/>
<https://www.darioniedermann.it/>
From henry.r.bent at gmail.com Thu Jan 7 03:08:50 2021
From: henry.r.bent at gmail.com (Henry Bent)
Date: Wed, 6 Jan 2021 12:08:50 -0500
Subject: [TUHS] The 2038 bug...
In-Reply-To: <20210106163225.GC2973@darioniedermann.it>
References: <alpine.BSF.2.21.9999.2012311806460.82237@aneurin.horsfall.org>
<CAK6BEgdH7OOsw3p3d_bLsjhR+bv_ZrG9mvVSLa3hgJKhjLVK6w@mail.gmail.com>
<202012310810.0BV8ADZ3027195@freefriends.org>
<CANCZdfoKV7A46ho3ORghFZEddROty3A-y2bn1VY0m=ipBxFF6w@mail.gmail.com>
<20210106163225.GC2973@darioniedermann.it>
Message-ID: <CAEdTPBeiKfSau8SD9Y1ru427Z3XErSNzCtwaF7CwFcKQGvcftg@mail.gmail.com>
On Wed, 6 Jan 2021 at 11:40, Dario Niedermann <dario at darioniedermann.it>
wrote:
> Il 31/12/2020 alle 16:30, Warner Losh ha scritto:
>
> >On Thu, Dec 31, 2020, 1:10 AM <arnold at skeeve.com> wrote:
> [...]
> >>time_t these days tends to be 64 bits, and I think at least the Linux
> >>file systems store them that way.
> >
> >Time_t was still 32 bits last I checked on i386 and a few others...
>
> On recent Linux/i386 kernels it's actually 64 bits. In practice, only
> users who are stuck with old i386 Linux versions will have a problem.
>
Do you happen to know what the cutoff is? Are 2.6 kernels (still very
common) safe? 3.x? 4.x?
-Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210106/30ec6fc2/attachment.htm>
From dario at darioniedermann.it Thu Jan 7 04:05:13 2021
From: dario at darioniedermann.it (Dario Niedermann)
Date: Wed, 6 Jan 2021 19:05:13 +0100
Subject: [TUHS] The 2038 bug...
In-Reply-To: <CAEdTPBeiKfSau8SD9Y1ru427Z3XErSNzCtwaF7CwFcKQGvcftg@mail.gmail.com>
References: <alpine.BSF.2.21.9999.2012311806460.82237@aneurin.horsfall.org>
<CAK6BEgdH7OOsw3p3d_bLsjhR+bv_ZrG9mvVSLa3hgJKhjLVK6w@mail.gmail.com>
<202012310810.0BV8ADZ3027195@freefriends.org>
<CANCZdfoKV7A46ho3ORghFZEddROty3A-y2bn1VY0m=ipBxFF6w@mail.gmail.com>
<20210106163225.GC2973@darioniedermann.it>
<CAEdTPBeiKfSau8SD9Y1ru427Z3XErSNzCtwaF7CwFcKQGvcftg@mail.gmail.com>
Message-ID: <20210106180513.GD2973@darioniedermann.it>
Il 06/01/2021 alle 18:08, Henry Bent ha scritto:
>On Wed, 6 Jan 2021 at 11:40, Dario Niedermann <dario at darioniedermann.it>
>wrote:
>
>>Il 31/12/2020 alle 16:30, Warner Losh ha scritto:
>>[...]
>>>Time_t was still 32 bits last I checked on i386 and a few others...
>>
>> On recent Linux/i386 kernels it's actually 64 bits. In practice, only
>> users who are stuck with old i386 Linux versions will have a problem.
>
>Do you happen to know what the cutoff is? Are 2.6 kernels (still very
>common) safe? 3.x? 4.x?
5.6 is the first 32-bit kernel with 64-bit time_t, according to:
<https://lkml.org/lkml/2020/1/29/355?anz=web>
--
Dario Niedermann -:- finger my email address for PGP key, etc.
Also on the Internet at: <gopher://darioniedermann.it/>
<https://www.darioniedermann.it/>
From michael at kjorling.se Thu Jan 7 04:20:42 2021
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Wed, 6 Jan 2021 18:20:42 +0000
Subject: [TUHS] The 2038 bug...
In-Reply-To: <CAEdTPBeiKfSau8SD9Y1ru427Z3XErSNzCtwaF7CwFcKQGvcftg@mail.gmail.com>
References: <alpine.BSF.2.21.9999.2012311806460.82237@aneurin.horsfall.org>
<CAK6BEgdH7OOsw3p3d_bLsjhR+bv_ZrG9mvVSLa3hgJKhjLVK6w@mail.gmail.com>
<202012310810.0BV8ADZ3027195@freefriends.org>
<CANCZdfoKV7A46ho3ORghFZEddROty3A-y2bn1VY0m=ipBxFF6w@mail.gmail.com>
<20210106163225.GC2973@darioniedermann.it>
<CAEdTPBeiKfSau8SD9Y1ru427Z3XErSNzCtwaF7CwFcKQGvcftg@mail.gmail.com>
Message-ID: <d0935488-ddd6-4d99-a034-c14305e62995@localhost>
On 6 Jan 2021 12:08 -0500, from henry.r.bent at gmail.com (Henry Bent):
>> On recent Linux/i386 kernels it's actually 64 bits. In practice, only
>> users who are stuck with old i386 Linux versions will have a problem.
>
> Do you happen to know what the cutoff is? Are 2.6 kernels (still very
> common) safe? 3.x? 4.x?
I haven't dug particularly deeply, but unless I am missing something,
Debian Buster's 4.19 kernel seems to map `time_t` to plain `long`
regardless of architecture. I don't have an i386 architecture system
handy, but wouldn't that make it 32 bits wide on i386 & Co?
linux/time.h:
struct timespec {
__kernel_time_t tv_sec; /* seconds */
long tv_nsec; /* nanoseconds */
};
asm-generic/posix_types.h:
#ifndef __kernel_long_t
typedef long __kernel_long_t;
typedef unsigned long __kernel_ulong_t;
#endif
/* ... */
typedef __kernel_long_t __kernel_time_t;
Both from Debian's linux-libc-dev package, version 4.19.160-2, amd64
architecture.
If that's right, then I'd definitely expect anything 2.x and 3.x to be
unsafe, and 4.x to at best be suspect; so Dario's mention of 5.6
doesn't sound unreasonable as a first guess.
We've got maybe fifteen years before this starts to become a real
issue. Time to start working on those upgrade plans...
--
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?â€
From dave at horsfall.org Thu Jan 7 07:09:00 2021
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 7 Jan 2021 08:09:00 +1100 (EST)
Subject: [TUHS] The 2038 bug...
In-Reply-To: <20210106163225.GC2973@darioniedermann.it>
References: <alpine.BSF.2.21.9999.2012311806460.82237@aneurin.horsfall.org>
<CAK6BEgdH7OOsw3p3d_bLsjhR+bv_ZrG9mvVSLa3hgJKhjLVK6w@mail.gmail.com>
<202012310810.0BV8ADZ3027195@freefriends.org>
<CANCZdfoKV7A46ho3ORghFZEddROty3A-y2bn1VY0m=ipBxFF6w@mail.gmail.com>
<20210106163225.GC2973@darioniedermann.it>
Message-ID: <alpine.BSF.2.21.9999.2101070759280.26789@aneurin.horsfall.org>
On Wed, 6 Jan 2021, Dario Niedermann wrote:
> On recent Linux/i386 kernels it's actually 64 bits. In practice, only
> users who are stuck with old i386 Linux versions will have a problem.
64 bits on my old-ish MacBook Pro and FreeBSD 10; don't know about
Penguin/OS as one of them is dead forever and the other is still in
mid-upgrade (Debian).
I still reckon that 2038 will be "interesting", and who knows what epoch
your smart kettle etc will be using (you know, the one that will switch
itself on at your usual wake-up time, and make your coffee for you)?
-- Dave
From stu at remphrey.net Fri Jan 8 08:50:10 2021
From: stu at remphrey.net (Stuart Remphrey)
Date: Fri, 8 Jan 2021 06:50:10 +0800
Subject: [TUHS] The 2038 bug...
In-Reply-To: <alpine.BSF.2.21.9999.2012311806460.82237@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.2012311806460.82237@aneurin.horsfall.org>
Message-ID: <CAD0_1ckE22y8Kr6icgxEL846V34YxXxmqMxdynx-o+hO=3-WSw@mail.gmail.com>
Hmm, 76 (hopefully), retired (hopefully), so won't care (hopefully).
Unless retired & broke & can still concentrate (*somewhat doubtful, even
now?!*) -- in which case a good opportunity for truly excessive
overcharging to find & fix all those 32-bit time_t syscalls & re-retire
rich, happy, and braindead...
(*Hi Dave, from PTA/PTC days, btw; reminds me of SFA forms, ptcburp at Bond
Uni Research Park*)
On Thu, 31 Dec 2020, 15:20 Dave Horsfall, <dave at horsfall.org> wrote:
> As the new year is about to kick in (down-under anyway), it got me to
> thinking (always dangerous): how many here will be around for it to pick
> up the pieces that are no doubt still lying around?
>
> I'll be about the ripe old age of 85, so I may be around to see the
> Imminent Death of the Internet (Film at 11).
>
> 2100? Forget it... Too bad, as "Revolt in 2100 (?)" is one of my
> favourite Heinlein books.
>
> Others?
>
> -- Dave
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210108/5c3b1d31/attachment.htm>
From stu at remphrey.net Fri Jan 8 08:56:15 2021
From: stu at remphrey.net (Stuart Remphrey)
Date: Fri, 8 Jan 2021 06:56:15 +0800
Subject: [TUHS] The 2038 bug...
In-Reply-To: <alpine.BSF.2.21.9999.2101050822330.26789@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.2012311806460.82237@aneurin.horsfall.org>
<X/LQKPMbiMF45KMJ@server.rulingia.com>
<alpine.BSF.2.21.9999.2101050822330.26789@aneurin.horsfall.org>
Message-ID: <CAD0_1cmaGq6UFuFrufd06pKrcxho7WtbdSb5vahuX8a3Ssxt3w@mail.gmail.com>
> Dave, who's kept his COBOL knowledge a secret in every job
Indeed! Also FORTRAN/RATFOR and BASIC, in my case; but especially COBOL:
apart from everything else, too much like writing a novel to get anything
done.
On Tue, 5 Jan 2021, 05:50 Dave Horsfall, <dave at horsfall.org> wrote:
> On Mon, 4 Jan 2021, Peter Jeremy wrote:
>
> > Alternatively, my understanding is that the Unix epoch changed on
> > several occasions in the early days. Presumably the knowledge of how to
> > achieve this hasn't been lost. (Though actually performing an epoch
> > rollover may be more difficult today).
>
> My understanding is that it's been 1st Jan 1970 since at least Ed5, if not
> Ed6.
>
> > I suspect that 2038 may actually wind up being more serious than Y2K
> > because there are now far more embedded systems than there were then but
> > it's not clear that the designers of those systems learnt the lesson
> > from Y2K. A few weeks ago I tried to count the number of CPUs in my
> > bedroom, bathroom and study - my best guess is around 2 dozen.
> > Admittedly, I think relatively few of those will be concerned about
> > epoch rollover.
>
> The only systems I have that would care would be the various computers,
> and they are all NTP-synced (except the NBN modem/router takes its time
> from T$).
>
> > Plus 2038 is merely one epoch. Someone mentioned the Microsoft epoch
> > rolling over in 2048. Between those two, the IBM S/360 epoch rolls over
> > in 2042 - the Z-series appears to have glued another 8 bits onto the MSB
> > end of the TOD clock but that won't help all those S/360 and S/370
> > binaries that are still being run. And they are just the well- known
> > ones. I expect that there are lots of embedded systems running custom
> > epochs with weird rollover dates.
>
> Well, I don't care about the M$ epoch, and at 86 I might even get to see
> the world come to a grinding halt :-) Of course, I may be reliant upon M$
> systems in hospitals etc...
>
> Interesting story about the S/360 though. As a side-issue I wonder how
> many COBOL programmers will still be around to maintain all that payroll
> software etc?
>
> -- Dave, who's kept his COBOL knowledge a secret in every job
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210108/62830fdf/attachment.htm>
From cym224 at gmail.com Fri Jan 8 11:25:56 2021
From: cym224 at gmail.com (Nemo Nusquam)
Date: Thu, 7 Jan 2021 20:25:56 -0500
Subject: [TUHS] The 2038 bug...
In-Reply-To: <CAD0_1cmaGq6UFuFrufd06pKrcxho7WtbdSb5vahuX8a3Ssxt3w@mail.gmail.com>
References: <alpine.BSF.2.21.9999.2012311806460.82237@aneurin.horsfall.org>
<X/LQKPMbiMF45KMJ@server.rulingia.com>
<alpine.BSF.2.21.9999.2101050822330.26789@aneurin.horsfall.org>
<CAD0_1cmaGq6UFuFrufd06pKrcxho7WtbdSb5vahuX8a3Ssxt3w@mail.gmail.com>
Message-ID: <d39f9cb6-eaab-6d50-9b63-a1c4583e9d40@gmail.com>
On 01/07/21 17:56, Stuart Remphrey wrote (in part):
> > Dave, who's kept his COBOL knowledge a secret in every job
>
> Indeed! [...]; but especially COBOL: apart from everything else, too
> much like writing a novel to get anything done.
As long as we are bashing COBOL, I recall that someone -- name forgotten
-- wrote a parody that contained statements such as "Verily, let the
noble variable N be assigned the value known as one".
N.
From norman at oclsc.org Sat Jan 9 18:39:16 2021
From: norman at oclsc.org (Norman Wilson)
Date: Sat, 09 Jan 2021 03:39:16 -0500
Subject: [TUHS] Question
Message-ID: <1610181560.23999.for-standards-violators@oclsc.org>
Rob Pike, re the spelling corrector in V8 and later Research
versions of sh:
> That was done by Tom Duff, I believe before he came to Bell Labs. I might
> have brought the idea with me from Toronto.
Very likely, since you left it behind at Caltech as well; it was
in sh on cithep (a hostname meaningless to many but rob will remember)
when I arrived in 1980.
It was in the version of p you left behind there as well.
I can confirm that spname remained in the shell through V10
(it's still in my copy), but it seems to have disappeared from p.
Norman Wilson
Toronto ON
From norman at oclsc.org Sat Jan 9 18:44:28 2021
From: norman at oclsc.org (Norman Wilson)
Date: Sat, 09 Jan 2021 03:44:28 -0500
Subject: [TUHS] The 2038 bug...
Message-ID: <1610181871.24117.for-standards-violators@oclsc.org>
Warner Losh:
Less ugly would be to declare time_t to be unsigned instead of signed...
It would break less code... Making time_t 64 bits also breaks code, even if
you declare you don't care about binary compat since many older apps know
time_t is 32-bits.
===
I remember chatting in 1998 with a consultant who worked with
clients in the financial industry. They still used 32-bit systems
at the time, and had already converted critical programs (I don't
know whether that included parts of libc or they had their own
conversion routines) to make time_t unsigned.
It mattered early to those folks because of 40-year bonds.
That suggests to me that the financial-services world may have
a head start on the 2038 problem, but I fear many others are
still lagging behind. 64 bits will help but not as much for
embedded systems and legacy stuff.
Us hobbyists will doubtless have fun too, as we already do
(ask Warren) when running the earliest existing UNIX images,
in which times are stored in sixtieths of a second.
Norman Wilson
Toronto ON
From robpike at gmail.com Sat Jan 9 18:50:26 2021
From: robpike at gmail.com (Rob Pike)
Date: Sat, 9 Jan 2021 19:50:26 +1100
Subject: [TUHS] Question
In-Reply-To: <1610181560.23999.for-standards-violators@oclsc.org>
References: <1610181560.23999.for-standards-violators@oclsc.org>
Message-ID: <CAKzdPgwQ0r=eXMTYszXw+7ewqZ3ED5b69W9bbQ_G0EFScAfw2g@mail.gmail.com>
Ah cithep, I remember you well!
-rob
On Sat, Jan 9, 2021 at 7:46 PM Norman Wilson <norman at oclsc.org> wrote:
> Rob Pike, re the spelling corrector in V8 and later Research
> versions of sh:
>
> > That was done by Tom Duff, I believe before he came to Bell Labs. I might
> > have brought the idea with me from Toronto.
>
> Very likely, since you left it behind at Caltech as well; it was
> in sh on cithep (a hostname meaningless to many but rob will remember)
> when I arrived in 1980.
>
> It was in the version of p you left behind there as well.
>
> I can confirm that spname remained in the shell through V10
> (it's still in my copy), but it seems to have disappeared from p.
>
> Norman Wilson
> Toronto ON
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210109/a5faee63/attachment.htm>
From rudi.j.blom at gmail.com Sun Jan 10 12:43:37 2021
From: rudi.j.blom at gmail.com (Rudi Blom)
Date: Sun, 10 Jan 2021 09:43:37 +0700
Subject: [TUHS] Question
Message-ID: <CAMYpm86pHCH3F-n_oKkafPosmTXYGooYQyEBGfmbwWKuOaOAAQ@mail.gmail.com>
>From output of 'what' on /bin/sh in SCO UNIX 3.2V4.2
- spname.c 23.2 91/02/21
Cheers,
uncle rubl
>Date: Sat, 09 Jan 2021 03:39:16 -05
>From: Norman Wilson <norman at oclsc.org>
>To: tuhs at tuhs.org
>Subject: Re: [TUHS] Question
>Message-ID: <1610181560.23999.for-standards-violators at oclsc.org>
>
>Rob Pike, re the spelling corrector in V8 and later Research
>versions of sh:
>
> That was done by Tom Duff, I believe before he came to Bell Labs. I might
> have brought the idea with me from Toronto.
>
>Very likely, since you left it behind at Caltech as well; it was
>in sh on cithep (a hostname meaningless to many but rob will remember)
>when I arrived in 1980.
>
>It was in the version of p you left behind there as well.
>
>I can confirm that spname remained in the shell through V10
>(it's still in my copy), but it seems to have disappeared from p.
>
>Norman Wilson
>Toronto ON
From stu at remphrey.net Sun Jan 10 16:56:55 2021
From: stu at remphrey.net (Stuart Remphrey)
Date: Sun, 10 Jan 2021 14:56:55 +0800
Subject: [TUHS] The 2038 bug...
In-Reply-To: <d39f9cb6-eaab-6d50-9b63-a1c4583e9d40@gmail.com>
References: <alpine.BSF.2.21.9999.2012311806460.82237@aneurin.horsfall.org>
<X/LQKPMbiMF45KMJ@server.rulingia.com>
<alpine.BSF.2.21.9999.2101050822330.26789@aneurin.horsfall.org>
<CAD0_1cmaGq6UFuFrufd06pKrcxho7WtbdSb5vahuX8a3Ssxt3w@mail.gmail.com>
<d39f9cb6-eaab-6d50-9b63-a1c4583e9d40@gmail.com>
Message-ID: <CAD0_1c=zE0x4dbZGAfud1QWYwEO6O0VktEcaMATFNMC6Sto3+A@mail.gmail.com>
That's not too far wrong!
(btw, Dave H., I seem to be trapped in your greylist)
On Fri, 8 Jan 2021, 09:26 Nemo Nusquam, <cym224 at gmail.com> wrote:
> On 01/07/21 17:56, Stuart Remphrey wrote (in part):
> > > Dave, who's kept his COBOL knowledge a secret in every job
> >
> > Indeed! [...]; but especially COBOL: apart from everything else, too
> > much like writing a novel to get anything done.
> As long as we are bashing COBOL, I recall that someone -- name forgotten
> -- wrote a parody that contained statements such as "Verily, let the
> noble variable N be assigned the value known as one".
>
> N.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210110/c3656a5d/attachment.htm>
From ricercar at lycos.com Sun Jan 10 17:16:19 2021
From: ricercar at lycos.com (Valdimar Sigurdsson)
Date: Sun, 10 Jan 2021 01:16:19 -0600
Subject: [TUHS] The 2038 bug...
In-Reply-To: <alpine.BSF.2.21.9999.2012311806460.82237@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.2012311806460.82237@aneurin.horsfall.org>
Message-ID: <a2794918-0d0b-e10e-3c4c-dd2e684ba52c@lycos.com>
I for one will be 42.
On 12/31/20 1:19 AM, Dave Horsfall wrote:
> As the new year is about to kick in (down-under anyway), it got me to
> thinking (always dangerous): how many here will be around for it to pick
> up the pieces that are no doubt still lying around?
> I'll be about the ripe old age of 85, so I may be around to see the
> Imminent Death of the Internet (Film at 11).
> 2100? Forget it... Too bad, as "Revolt in 2100 (?)" is one of my
> favourite Heinlein books.
> Others?
> -- Dave
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210110/0e3dfe86/attachment.htm>
From nikke.karlsson at gmail.com Sun Jan 10 17:24:45 2021
From: nikke.karlsson at gmail.com (Niklas Karlsson)
Date: Sun, 10 Jan 2021 08:24:45 +0100
Subject: [TUHS] The 2038 bug...
In-Reply-To: <a2794918-0d0b-e10e-3c4c-dd2e684ba52c@lycos.com>
References: <alpine.BSF.2.21.9999.2012311806460.82237@aneurin.horsfall.org>
<a2794918-0d0b-e10e-3c4c-dd2e684ba52c@lycos.com>
Message-ID: <CAK6BEgeYxqu1-qT3Oug6eP29-qEFCt00n0xiBzC4ebNvCb-m4w@mail.gmail.com>
I'll be 41 next month.
Den sön 10 jan. 2021 kl 08:23 skrev Valdimar Sigurdsson <ricercar at lycos.com
>:
> I for one will be 42.
>
>
> On 12/31/20 1:19 AM, Dave Horsfall wrote:
>
> As the new year is about to kick in (down-under anyway), it got me to
> thinking (always dangerous): how many here will be around for it to pick
> up the pieces that are no doubt still lying around?
>
> I'll be about the ripe old age of 85, so I may be around to see the
> Imminent Death of the Internet (Film at 11).
>
> 2100? Forget it... Too bad, as "Revolt in 2100 (?)" is one of my
> favourite Heinlein books.
>
> Others?
>
> -- Dave
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210110/e01a7356/attachment.htm>
From stu at remphrey.net Sun Jan 10 20:15:06 2021
From: stu at remphrey.net (Stuart Remphrey)
Date: Sun, 10 Jan 2021 18:15:06 +0800
Subject: [TUHS] The 2038 bug...
In-Reply-To: <a2794918-0d0b-e10e-3c4c-dd2e684ba52c@lycos.com>
References: <alpine.BSF.2.21.9999.2012311806460.82237@aneurin.horsfall.org>
<a2794918-0d0b-e10e-3c4c-dd2e684ba52c@lycos.com>
Message-ID: <CAD0_1ckfuBWrvBEnz6X2BJkO4U3pWCXTB+QznS+3NCXWfOf8mA@mail.gmail.com>
By which time you may well find yourself managing a system through 2038
transition -- whilst your own age is the ultimate answer, but to what
question?
(getting a little off-topic, unless Sirius Cybernetics Corp developed their
systems on Unix?)
On Sun, 10 Jan 2021, 15:23 Valdimar Sigurdsson, <ricercar at lycos.com> wrote:
> I for one will be 42.
>
>
> On 12/31/20 1:19 AM, Dave Horsfall wrote:
>
> As the new year is about to kick in (down-under anyway), it got me to
> thinking (always dangerous): how many here will be around for it to pick
> up the pieces that are no doubt still lying around?
>
> I'll be about the ripe old age of 85, so I may be around to see the
> Imminent Death of the Internet (Film at 11).
>
> 2100? Forget it... Too bad, as "Revolt in 2100 (?)" is one of my
> favourite Heinlein books.
>
> Others?
>
> -- Dave
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210110/ff080112/attachment.htm>
From dave at horsfall.org Mon Jan 11 06:31:40 2021
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 11 Jan 2021 07:31:40 +1100 (EST)
Subject: [TUHS] History of the UNIX Beard
In-Reply-To: <f10f47cd4a1206f23a33e6ab5ce79baa@firemail.de>
References: <CAEuQd1Deg7sTDomSe+osqPT9OozV11BK=AthOucwirnfASbsCQ@mail.gmail.com>
<f10f47cd4a1206f23a33e6ab5ce79baa@firemail.de>
Message-ID: <alpine.BSF.2.21.9999.2101110730290.26789@aneurin.horsfall.org>
On Sat, 19 Dec 2020, Thomas Paulsen wrote:
> please check out: http://www.usenix.org.uk/content/unix_beards.html
Real Unix bods [tm] don't have the time to waste five minutes every
morning :-)
-- Dave
From alan at alanlee.org Mon Jan 11 17:18:40 2021
From: alan at alanlee.org (alan at alanlee.org)
Date: Mon, 11 Jan 2021 02:18:40 -0500
Subject: [TUHS] The 2038 bug...
In-Reply-To: <20201231161228.GG28420@mcvoy.com>
References: <alpine.BSF.2.21.9999.2012311806460.82237@aneurin.horsfall.org>
<CAK6BEgdH7OOsw3p3d_bLsjhR+bv_ZrG9mvVSLa3hgJKhjLVK6w@mail.gmail.com>
<202012310810.0BV8ADZ3027195@freefriends.org>
<CANCZdfoKV7A46ho3ORghFZEddROty3A-y2bn1VY0m=ipBxFF6w@mail.gmail.com>
<950DAE25-BCAD-47EF-8FCE-A716271A3C25@gmail.com>
<20201231161228.GG28420@mcvoy.com>
Message-ID: <32aeb853e5c56bc04dd2e9e2310f96a7@alanlee.org>
64-bit migration is the ideal solution. However there is a band-aid
that can be applied to extend the life of 32-bit only systems. One
could reclaim part of the previous epoch window going forward. That is,
once 32-bit time_t rolls over, assume any value from -2 billion to some
additional arbitrary positive time offset had indeed just rolled over.
Add a whole 0x100000000 to it in a 64-bit context and evaluate (or
evaluate against the old epoch ~+136 years). It means a 32-bit time_t
in this context would instead mis-represent dates from 1902 forward to
some arbitrary threshold as modern >2038 dates. But time_t was never
meant to track dates outside of 'near term' relative to 'modern day' -
eg +/- 68 years from 1970 when it was conceived. It's reasonable to
assume as the use of such software has moved forward in time, its time
reference should as well.
-Alan H.
On 2020-12-31 11:12, Larry McVoy wrote:
> On Thu, Dec 31, 2020 at 09:09:33AM -0700, Adam Thornton wrote:
>> Whereas, time_t is basically internal, right?
>
> time_t is used in syscalls, see Warner's email about i386. It's a
> mess for 32 bit kernels.
From stu at remphrey.net Tue Jan 12 00:01:37 2021
From: stu at remphrey.net (Stuart Remphrey)
Date: Mon, 11 Jan 2021 22:01:37 +0800
Subject: [TUHS] The 2038 bug...
In-Reply-To: <32aeb853e5c56bc04dd2e9e2310f96a7@alanlee.org>
References: <alpine.BSF.2.21.9999.2012311806460.82237@aneurin.horsfall.org>
<CAK6BEgdH7OOsw3p3d_bLsjhR+bv_ZrG9mvVSLa3hgJKhjLVK6w@mail.gmail.com>
<202012310810.0BV8ADZ3027195@freefriends.org>
<CANCZdfoKV7A46ho3ORghFZEddROty3A-y2bn1VY0m=ipBxFF6w@mail.gmail.com>
<950DAE25-BCAD-47EF-8FCE-A716271A3C25@gmail.com>
<20201231161228.GG28420@mcvoy.com>
<32aeb853e5c56bc04dd2e9e2310f96a7@alanlee.org>
Message-ID: <CAD0_1cmAxhxrwCMc6xs5eVj948x6OazLtkdEw_U2Wx-zZhi4gw@mail.gmail.com>
> once 32-bit time_t rolls over,
> assume any value from -2 billion
> to some additional arbitrary positive
> time offset had indeed just rolled over.
That seems a reasonable 2038 bandaid: analogous to Y2K reinterpreting
2-digit decimal dates as a different/higher year range than 1900-1990;
similar in effect to making 32-bit time_t unsigned.
On Mon, 11 Jan 2021, 15:28 , <alan at alanlee.org> wrote:
>
> 64-bit migration is the ideal solution. However there is a band-aid
> that can be applied to extend the life of 32-bit only systems. One
> could reclaim part of the previous epoch window going forward. That is,
> once 32-bit time_t rolls over, assume any value from -2 billion to some
> additional arbitrary positive time offset had indeed just rolled over.
> Add a whole 0x100000000 to it in a 64-bit context and evaluate (or
> evaluate against the old epoch ~+136 years). It means a 32-bit time_t
> in this context would instead mis-represent dates from 1902 forward to
> some arbitrary threshold as modern >2038 dates. But time_t was never
> meant to track dates outside of 'near term' relative to 'modern day' -
> eg +/- 68 years from 1970 when it was conceived. It's reasonable to
> assume as the use of such software has moved forward in time, its time
> reference should as well.
>
> -Alan H.
>
> On 2020-12-31 11:12, Larry McVoy wrote:
> > On Thu, Dec 31, 2020 at 09:09:33AM -0700, Adam Thornton wrote:
> >> Whereas, time_t is basically internal, right?
> >
> > time_t is used in syscalls, see Warner's email about i386. It's a
> > mess for 32 bit kernels.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210111/64a4e308/attachment.htm>
From sl at stanleylieber.com Thu Jan 14 08:15:13 2021
From: sl at stanleylieber.com (Stanley Lieber)
Date: Wed, 13 Jan 2021 17:15:13 -0500
Subject: [TUHS] Fwd: Writer's Workbench on Plan 9/9front
In-Reply-To: <12DBBA7F05B2CD6CC86BB30EC598B641@sirjofri.de>
References: <12DBBA7F05B2CD6CC86BB30EC598B641@sirjofri.de>
Message-ID: <411F7BC7-2D98-48A1-9448-740969D3AE8F@stanleylieber.com>
fyi
-------- Original Message --------
From: joel at sirjofri.de
Sent: January 13, 2021 11:30:31 AM EST
To: sl at stanleylieber.com
Subject: Writer's Workbench on Plan 9/9front
Hello TUHS,
I don't know if that mail arrives since I'm not subscribed to the tuhs
mailing list. I just thought this might be interesting to some of
you, especially since I noticed there are some threads about the
writer's workbench.
Some weeks ago I started porting V10 wwb tools to 9front (which is a
fork of Plan 9). I have still many things to do and currently only
limited time, but the greater tools (style, diction and suggest) work.
Most code worked fine, btw, only minor changes needed. Especially
implicit C declarations and missing #includes. Comparison with the
original code in the archive is possible.
I also tried porting (or rewriting) the shell scripts in rc, and made
mkfiles that better fit the Plan 9 build systems. I also included
acme commands, they also translate the locations into the plumber
format for the files (filename:line).
Here's a link to the git repository (yes, we have a native git
implementation now): https://git.sr.ht/~sirjofri/wwb9
sirjofri
From royce at techsolvency.com Thu Jan 14 09:41:47 2021
From: royce at techsolvency.com (Royce Williams)
Date: Wed, 13 Jan 2021 14:41:47 -0900
Subject: [TUHS] ACM Fellow, Ken Thompson
Message-ID: <CA+E3k92c+M5tH2ht+ZUpd6BE9OS_ZW_-QsZrrBCcEJQ+X4bmQg@mail.gmail.com>
Congratulations to Ken Thompson, the newly-minted ACM Fellow:
https://awards.acm.org/award_winners/thompson_4588371
(It seemed of historical interest, and therefore on-topic. :) )
--
Royce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210113/484334ed/attachment.htm>
From dscherrer at solar.stanford.edu Thu Jan 14 09:44:51 2021
From: dscherrer at solar.stanford.edu (Deborah K Scherrer)
Date: Wed, 13 Jan 2021 15:44:51 -0800
Subject: [TUHS] ACM Fellow, Ken Thompson
In-Reply-To: <CA+E3k92c+M5tH2ht+ZUpd6BE9OS_ZW_-QsZrrBCcEJQ+X4bmQg@mail.gmail.com>
References: <CA+E3k92c+M5tH2ht+ZUpd6BE9OS_ZW_-QsZrrBCcEJQ+X4bmQg@mail.gmail.com>
Message-ID: <c8dbb9d9-a506-64c2-1a1a-7afc6df3f8d4@solar.stanford.edu>
Congratulations, Ken. Well deserved!
Deborah
On 1/13/21 3:41 PM, Royce Williams wrote:
> Congratulations to Ken Thompson, the newly-minted ACM Fellow:
>
> https://awards.acm.org/award_winners/thompson_4588371
>
> (It seemed of historical interest, and therefore on-topic. :) )
>
> --
> Royce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210113/599f069c/attachment.htm>
From dave at horsfall.org Thu Jan 14 14:59:25 2021
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 14 Jan 2021 15:59:25 +1100 (EST)
Subject: [TUHS] ACM Fellow, Ken Thompson
In-Reply-To: <CA+E3k92c+M5tH2ht+ZUpd6BE9OS_ZW_-QsZrrBCcEJQ+X4bmQg@mail.gmail.com>
References: <CA+E3k92c+M5tH2ht+ZUpd6BE9OS_ZW_-QsZrrBCcEJQ+X4bmQg@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.2101141549020.26789@aneurin.horsfall.org>
On Wed, 13 Jan 2021, Royce Williams wrote:
> Congratulations to Ken Thompson, the newly-minted ACM Fellow:
>
> https://awards.acm.org/award_winners/thompson_4588371
> (It seemed of historical interest, and therefore on-topic. :) )
Congratubloodylations, as we say down-under; it is well-deserved.
Without Unix I'd probably still be supporting RSX-11 and VMS etc; their
foray into Unix (Eunice) was doomed.
An exchange with my then boss:
Me: "Eunice makes VMS look civilised".
He: "You mean it looks like Unix".
Me: "That's what I said".
As you can imagine the conversation went downhill from there :-)
-- Dave
From robert at timetraveller.org Thu Jan 14 17:12:27 2021
From: robert at timetraveller.org (Robert Brockway)
Date: Thu, 14 Jan 2021 17:12:27 +1000 (AEST)
Subject: [TUHS] ACM Fellow, Ken Thompson
In-Reply-To: <alpine.BSF.2.21.9999.2101141549020.26789@aneurin.horsfall.org>
References: <CA+E3k92c+M5tH2ht+ZUpd6BE9OS_ZW_-QsZrrBCcEJQ+X4bmQg@mail.gmail.com>
<alpine.BSF.2.21.9999.2101141549020.26789@aneurin.horsfall.org>
Message-ID: <alpine.DEB.2.21.2101141710110.26483@mira.opentrend.net>
On Thu, 14 Jan 2021, Dave Horsfall wrote:
> As you can imagine the conversation went downhill from there :-)
I'm sure it's been seen before but I think it's timely...
https://dilbert.com/strip/1993-11-09
And congratulations Ken. If only everyone knew how Unix has changed the
world...
Rob
From thomas.paulsen at firemail.de Thu Jan 14 19:50:58 2021
From: thomas.paulsen at firemail.de (Thomas Paulsen)
Date: Thu, 14 Jan 2021 10:50:58 +0100
Subject: [TUHS] ACM Fellow, Ken Thompson
In-Reply-To: <CA+E3k92c+M5tH2ht+ZUpd6BE9OS_ZW_-QsZrrBCcEJQ+X4bmQg@mail.gmail.com>
References: <CA+E3k92c+M5tH2ht+ZUpd6BE9OS_ZW_-QsZrrBCcEJQ+X4bmQg@mail.gmail.com>
Message-ID: <06ac5d52f3105219f56cad709f931675@firemail.de>
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210114/c4807ee2/attachment.htm>
From jcapp at anteil.com Thu Jan 14 23:21:53 2021
From: jcapp at anteil.com (Jim Capp)
Date: Thu, 14 Jan 2021 08:21:53 -0500 (EST)
Subject: [TUHS] ACM Fellow, Ken Thompson
In-Reply-To: <CA+E3k92c+M5tH2ht+ZUpd6BE9OS_ZW_-QsZrrBCcEJQ+X4bmQg@mail.gmail.com>
Message-ID: <8225455.9789.1610630513672.JavaMail.root@zimbraanteil>
Ken,
Congratulations on becoming an ACM Fellow! It gives me a little more respect for ACM :-)
Cheers,
Jim
From: "Royce Williams" <royce at techsolvency.com>
To: "The Eunuchs Hysterical Society" <tuhs at tuhs.org>
Sent: Wednesday, January 13, 2021 6:41:47 PM
Subject: [TUHS] ACM Fellow, Ken Thompson
Congratulations to Ken Thompson, the newly-minted ACM Fellow:
https://awards.acm.org/award_winners/thompson_4588371
(It seemed of historical interest, and therefore on-topic. :) )
--
Royce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210114/9c923421/attachment.htm>
From nikke.karlsson at gmail.com Fri Jan 15 00:20:35 2021
From: nikke.karlsson at gmail.com (Niklas Karlsson)
Date: Thu, 14 Jan 2021 15:20:35 +0100
Subject: [TUHS] ACM Fellow, Ken Thompson
In-Reply-To: <CA+E3k92c+M5tH2ht+ZUpd6BE9OS_ZW_-QsZrrBCcEJQ+X4bmQg@mail.gmail.com>
References: <CA+E3k92c+M5tH2ht+ZUpd6BE9OS_ZW_-QsZrrBCcEJQ+X4bmQg@mail.gmail.com>
Message-ID: <CAK6BEgddN6_VKY5pszDh6pt48jtjXJ++7q+9sKOnSCKsuFdOvQ@mail.gmail.com>
Congratulations, Ken! Well deserved.
Best regards,
Niklas
Den tors 14 jan. 2021 kl 00:43 skrev Royce Williams <royce at techsolvency.com
>:
> Congratulations to Ken Thompson, the newly-minted ACM Fellow:
>
> https://awards.acm.org/award_winners/thompson_4588371
>
> (It seemed of historical interest, and therefore on-topic. :) )
>
> --
> Royce
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210114/342abe4e/attachment.htm>
From steffen at sdaoden.eu Fri Jan 15 01:19:27 2021
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Thu, 14 Jan 2021 16:19:27 +0100
Subject: [TUHS] ACM Fellow, Ken Thompson
In-Reply-To: <8225455.9789.1610630513672.JavaMail.root@zimbraanteil>
References: <8225455.9789.1610630513672.JavaMail.root@zimbraanteil>
Message-ID: <20210114151927.wgPhi%steffen@sdaoden.eu>
Jim Capp wrote in
<8225455.9789.1610630513672.JavaMail.root at zimbraanteil>:
...
|Congratulations on becoming an ACM Fellow! It gives me a little more \
|respect for ACM :-)
Wonderful. Laughter.
--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 kenbob at gmail.com Fri Jan 15 07:27:46 2021
From: kenbob at gmail.com (Ken Thompson)
Date: Thu, 14 Jan 2021 13:27:46 -0800
Subject: [TUHS] ACM Fellow, Ken Thompson
In-Reply-To: <20210114151927.wgPhi%steffen@sdaoden.eu>
References: <8225455.9789.1610630513672.JavaMail.root@zimbraanteil>
<20210114151927.wgPhi%steffen@sdaoden.eu>
Message-ID: <CAMP=X_m09p6yhoqFJg7rxf_7ydkZNyVB3HJ6so=4Z6yNO_1rsA@mail.gmail.com>
thank you.
On Thu, Jan 14, 2021 at 7:20 AM Steffen Nurpmeso <steffen at sdaoden.eu> wrote:
> Jim Capp wrote in
> <8225455.9789.1610630513672.JavaMail.root at zimbraanteil>:
> ...
> |Congratulations on becoming an ACM Fellow! It gives me a little more \
> |respect for ACM :-)
>
> Wonderful. Laughter.
>
> --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/20210114/a14f3f96/attachment.htm>
From cowan at ccil.org Fri Jan 15 08:22:26 2021
From: cowan at ccil.org (John Cowan)
Date: Thu, 14 Jan 2021 17:22:26 -0500
Subject: [TUHS] ACM Fellow, Ken Thompson
In-Reply-To: <alpine.BSF.2.21.9999.2101141549020.26789@aneurin.horsfall.org>
References: <CA+E3k92c+M5tH2ht+ZUpd6BE9OS_ZW_-QsZrrBCcEJQ+X4bmQg@mail.gmail.com>
<alpine.BSF.2.21.9999.2101141549020.26789@aneurin.horsfall.org>
Message-ID: <CAD2gp_Tt+S760WF79y914cC9tB6vAYJEG=rq4JP7axptqhVxDg@mail.gmail.com>
On Thu, Jan 14, 2021 at 12:00 AM Dave Horsfall <dave at horsfall.org> wrote:
> Congratubloodylations, as we say down-under; it is well-deserved.
> Without Unix I'd probably still be supporting RSX-11 and VMS etc; their
> foray into Unix (Eunice) was doomed.
>
Whose foray? Not DEC's. Eunice was built at SRI and sold by the
Wollongong Group, who must have had Downundrian connections. I was always
very happy with it, as I am with Cygwin today. Ultrix, on the other hand,
was DEC's: a BSD with SysV hacks, as opposed to Solaris which was the other
way around.
The Dilbert strip probably explains why everyone who could, wore beards in
those days. Just to prevent that mistake.
John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org
Being understandable rather than obscurantist poses certain
risks, in that one's opinions are clear and therefore falsifiable
in the light of new data, but it has the advantage of encouraging
feedback from others. --James A. Matisoff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210114/fce8efc4/attachment.htm>
From dave at horsfall.org Fri Jan 15 08:35:02 2021
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 15 Jan 2021 09:35:02 +1100 (EST)
Subject: [TUHS] ACM Fellow, Ken Thompson
In-Reply-To: <alpine.DEB.2.21.2101141710110.26483@mira.opentrend.net>
References: <CA+E3k92c+M5tH2ht+ZUpd6BE9OS_ZW_-QsZrrBCcEJQ+X4bmQg@mail.gmail.com>
<alpine.BSF.2.21.9999.2101141549020.26789@aneurin.horsfall.org>
<alpine.DEB.2.21.2101141710110.26483@mira.opentrend.net>
Message-ID: <alpine.BSF.2.21.9999.2101150932090.26789@aneurin.horsfall.org>
On Thu, 14 Jan 2021, Robert Brockway wrote:
> I'm sure it's been seen before but I think it's timely...
>
> https://dilbert.com/strip/1993-11-09
Oh dear...
> And congratulations Ken. If only everyone knew how Unix has changed the
> world...
Indeed!
-- Dave
From steffen at sdaoden.eu Fri Jan 15 08:57:24 2021
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Thu, 14 Jan 2021 23:57:24 +0100
Subject: [TUHS] ACM Fellow, Ken Thompson
In-Reply-To: <CAMP=X_m09p6yhoqFJg7rxf_7ydkZNyVB3HJ6so=4Z6yNO_1rsA@mail.gmail.com>
References: <8225455.9789.1610630513672.JavaMail.root@zimbraanteil>
<20210114151927.wgPhi%steffen@sdaoden.eu>
<CAMP=X_m09p6yhoqFJg7rxf_7ydkZNyVB3HJ6so=4Z6yNO_1rsA@mail.gmail.com>
Message-ID: <20210114225724.WycQC%steffen@sdaoden.eu>
Ken Thompson wrote in
<CAMP=X_m09p6yhoqFJg7rxf_7ydkZNyVB3HJ6so=4Z6yNO_1rsA at mail.gmail.com>:
|On Thu, Jan 14, 2021 at 7:20 AM Steffen Nurpmeso <steffen at sdaoden.eu> \
|wrote:
|> Jim Capp wrote in
|> <8225455.9789.1610630513672.JavaMail.root at zimbraanteil>:
|> ...
|>|Congratulations on becoming an ACM Fellow! It gives me a little more \
|>|respect for ACM :-)
|>
|> Wonderful. Laughter.
|thank you.
This surely is a mountainful of all in return (Mr. Ken Thompson).
--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 egbegb2 at gmail.com Fri Jan 15 14:26:48 2021
From: egbegb2 at gmail.com (Ed Bradford)
Date: Thu, 14 Jan 2021 22:26:48 -0600
Subject: [TUHS] ACM Fellow, Ken Thompson
In-Reply-To: <CA+E3k92c+M5tH2ht+ZUpd6BE9OS_ZW_-QsZrrBCcEJQ+X4bmQg@mail.gmail.com>
References: <CA+E3k92c+M5tH2ht+ZUpd6BE9OS_ZW_-QsZrrBCcEJQ+X4bmQg@mail.gmail.com>
Message-ID: <CAHTagfFPGJLSP8bEM_ZSgjfsySbrSkKbTfZkG3qPjx+PcbxTbg@mail.gmail.com>
Congratulations Ken Thompson. 127 was an inspiration to all us
old time BTL folks. In my view this award is long overdue.
Go well and stay well.
Ed
On Wed, Jan 13, 2021 at 5:43 PM Royce Williams <royce at techsolvency.com>
wrote:
> Congratulations to Ken Thompson, the newly-minted ACM Fellow:
>
> https://awards.acm.org/award_winners/thompson_4588371
>
> (It seemed of historical interest, and therefore on-topic. :) )
>
> --
> Royce
>
--
Advice is judged by results, not by intentions.
Cicero
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210114/3641b7db/attachment.htm>
From dave at horsfall.org Sat Jan 16 06:14:01 2021
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 16 Jan 2021 07:14:01 +1100 (EST)
Subject: [TUHS] ACM Fellow, Ken Thompson
In-Reply-To: <CAD2gp_Tt+S760WF79y914cC9tB6vAYJEG=rq4JP7axptqhVxDg@mail.gmail.com>
References: <CA+E3k92c+M5tH2ht+ZUpd6BE9OS_ZW_-QsZrrBCcEJQ+X4bmQg@mail.gmail.com>
<alpine.BSF.2.21.9999.2101141549020.26789@aneurin.horsfall.org>
<CAD2gp_Tt+S760WF79y914cC9tB6vAYJEG=rq4JP7axptqhVxDg@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.2101160705190.95135@aneurin.horsfall.org>
On Thu, 14 Jan 2021, John Cowan wrote:
> > Congratubloodylations, as we say down-under; it is well-deserved.
> >
> > Without Unix I'd probably still be supporting RSX-11 and VMS etc;
> > their foray into Unix (Eunice) was doomed.
>
> Whose foray? Not DEC's. Eunice was built at SRI and sold by the
> Wollongong Group, who must have had Downundrian connections. I was
> always very happy with it, as I am with Cygwin today. Ultrix, on the
> other hand, was DEC's: a BSD with SysV hacks, as opposed to Solaris
> which was the other way around.
I have alternative facts :-)
https://en.wikipedia.org/wiki/Eunice_(software)
``Eunice was a Unix-like working environment for VAX computers
running DEC's VAX/VMS, based on the BSD version of Unix. It was
originally developed ca. 1981 by David Kashtan at SRI[1] and later
maintained and marketed by The Wollongong Group.''
> The Dilbert strip probably explains why everyone who could, wore beards
> in those days. Just to prevent that mistake.
At one place I worked, every Unix bod sported facial fungus; it must be a
Unix thing...
-- Dave
From cowan at ccil.org Sat Jan 16 08:17:44 2021
From: cowan at ccil.org (John Cowan)
Date: Fri, 15 Jan 2021 17:17:44 -0500
Subject: [TUHS] ACM Fellow, Ken Thompson
In-Reply-To: <alpine.BSF.2.21.9999.2101160705190.95135@aneurin.horsfall.org>
References: <CA+E3k92c+M5tH2ht+ZUpd6BE9OS_ZW_-QsZrrBCcEJQ+X4bmQg@mail.gmail.com>
<alpine.BSF.2.21.9999.2101141549020.26789@aneurin.horsfall.org>
<CAD2gp_Tt+S760WF79y914cC9tB6vAYJEG=rq4JP7axptqhVxDg@mail.gmail.com>
<alpine.BSF.2.21.9999.2101160705190.95135@aneurin.horsfall.org>
Message-ID: <CAD2gp_Qmf2QLT98Zk-D5MT0ph3gkQowfS3318KhN2OaiMdq7FQ@mail.gmail.com>
On Fri, Jan 15, 2021 at 3:14 PM Dave Horsfall <dave at horsfall.org> wrote:
> > Whose foray? Not DEC's. Eunice was built at SRI and sold by the
> > Wollongong Group, who must have had Downundrian connections.
>
> It was
> originally developed ca. 1981 by David Kashtan at SRI[1] and later
> maintained and marketed by The Wollongong Group.''
>
Where's the disagreement?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210115/d8834a14/attachment.htm>
From imp at bsdimp.com Sat Jan 16 12:29:55 2021
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 15 Jan 2021 19:29:55 -0700
Subject: [TUHS] ACM Fellow, Ken Thompson
In-Reply-To: <CAD2gp_Qmf2QLT98Zk-D5MT0ph3gkQowfS3318KhN2OaiMdq7FQ@mail.gmail.com>
References: <CA+E3k92c+M5tH2ht+ZUpd6BE9OS_ZW_-QsZrrBCcEJQ+X4bmQg@mail.gmail.com>
<alpine.BSF.2.21.9999.2101141549020.26789@aneurin.horsfall.org>
<CAD2gp_Tt+S760WF79y914cC9tB6vAYJEG=rq4JP7axptqhVxDg@mail.gmail.com>
<alpine.BSF.2.21.9999.2101160705190.95135@aneurin.horsfall.org>
<CAD2gp_Qmf2QLT98Zk-D5MT0ph3gkQowfS3318KhN2OaiMdq7FQ@mail.gmail.com>
Message-ID: <CANCZdfqNQC3TXMKuppiVybmYTXEz0h+HvE8QXEeh8sWeONPqnA@mail.gmail.com>
On Fri, Jan 15, 2021 at 3:18 PM John Cowan <cowan at ccil.org> wrote:
>
>
> On Fri, Jan 15, 2021 at 3:14 PM Dave Horsfall <dave at horsfall.org> wrote:
>
>
>> > Whose foray? Not DEC's. Eunice was built at SRI and sold by the
>> > Wollongong Group, who must have had Downundrian connections.
>>
>
>
>> It was
>> originally developed ca. 1981 by David Kashtan at SRI[1] and later
>> maintained and marketed by The Wollongong Group.''
>>
>
> Where's the disagreement?
>
Eunice post-dated DEC's first Unix offering by several years. They sold V7
and later V7M before rebranding it to Ultrix. Eunice was 4.1BSD (later 4.2
and 4.3) that Dr Kashtan grafted into VMS in ways that... provoke strong
feelings among reviewers... The TCP/IP stack that was inside of Eunice
would form the basis for Wollongong's TCP/IP offerings on VMS... A more
refined version, also done I think by Kashtan, was marketed by TGV and
there was always much rivalry between the two companies...
Wollongong got its license because they were the marketing company formed
to market Dr. Miller's port to Interdata, and they later branched out
significantly because their license was so special... Or at least that's
the story they told customers and internally... I never saw the original
license to know...
Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210115/2730363a/attachment.htm>
From andrew at humeweb.com Sat Jan 16 11:54:38 2021
From: andrew at humeweb.com (Andrew Hume)
Date: Fri, 15 Jan 2021 17:54:38 -0800
Subject: [TUHS] sam leffler, rob pike
Message-ID: <09B601EA-DA27-4A5D-B373-E914760F05CF@humeweb.com>
an urgent request: can someone please send me sam leaflet’s email address?
its needed for a funeral (dave tilbrook just died).
also, rob pike, can you send me your email please?
(these are for tilbrook’s son.)
From andrew at humeweb.com Sat Jan 16 19:10:18 2021
From: andrew at humeweb.com (Andrew Hume)
Date: Sat, 16 Jan 2021 01:10:18 -0800
Subject: [TUHS] sam leffler, rob pike
In-Reply-To: <09B601EA-DA27-4A5D-B373-E914760F05CF@humeweb.com>
References: <09B601EA-DA27-4A5D-B373-E914760F05CF@humeweb.com>
Message-ID: <51272BAA-D622-4D8C-9468-4592429E1422@humeweb.com>
thanks for the emails.
for those who care, this is part of an email from dave’s son (joe):
My Dad has had health problems the last few years and was in long term care facilities for the past few years. He was living in the Kensington one, one of the best ones, and was safe from COVID the first time it hit. But even though they were trying to be as safe as possible and protected, it some how came back and he got affected after Christmas, which he had to spend away from everyone. Anyway, he did get infected, and for the first week it didn't seem too bad, and that he was recovering, but this week he got worse and he died after Midnight Friday (today).
Just thought you should know and if you would like to attend the funeral, it's at 11am on Sunday on YouTube because of COVID restrictions.
Benjamin's Park Memorial Chapel - Memorial Book <https://www.benjaminsparkmemorialchapel.ca/MemorialBook.aspx?snum=127607&sid=205595>
again, thanks to those who replied.
> On Jan 15, 2021, at 5:54 PM, Andrew Hume <andrew at humeweb.com> wrote:
>
> an urgent request: can someone please send me sam leaflet’s email address?
> its needed for a funeral (dave tilbrook just died).
> also, rob pike, can you send me your email please?
> (these are for tilbrook’s son.)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210116/23bad76f/attachment.htm>
From andrew at humeweb.com Sat Jan 16 19:13:01 2021
From: andrew at humeweb.com (Andrew Hume)
Date: Sat, 16 Jan 2021 01:13:01 -0800
Subject: [TUHS] sam leffler, rob pike
In-Reply-To: <09B601EA-DA27-4A5D-B373-E914760F05CF@humeweb.com>
References: <09B601EA-DA27-4A5D-B373-E914760F05CF@humeweb.com>
Message-ID: <7436C8FC-63DB-442B-9510-857CEDEE24BA@humeweb.com>
umm, a correction; joe sent me another link for the funeral:
Also I sent the wrong link, typical of me. Benjamin's Park Memorial Chapel - Service Details <https://www.benjaminsparkmemorialchapel.ca/ServiceDetails.aspx?snum=127607&fg=0>
> On Jan 15, 2021, at 5:54 PM, Andrew Hume <andrew at humeweb.com> wrote:
>
> an urgent request: can someone please send me sam leaflet’s email address?
> its needed for a funeral (dave tilbrook just died).
> also, rob pike, can you send me your email please?
> (these are for tilbrook’s son.)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210116/f36db0df/attachment.htm>
From andrew at humeweb.com Mon Jan 18 00:57:20 2021
From: andrew at humeweb.com (Andrew Hume)
Date: Sun, 17 Jan 2021 06:57:20 -0800
Subject: [TUHS] EGREG
Message-ID: <A958535E-7F0D-48F5-A248-438479BEC421@humeweb.com>
i have probed recently about the origins of the “EGREG†(its all greg cession’s fault) error in Research Unix.
alas, i recall nothing about this, and can’t recall ever getting the message.
however, courtesy of Dave Presotto (i am fairly sure), there was an equivalent error
in Plan 9, where more or less randomly, if your user id was ‘andrew’, system calls would fail.
and yes, i did feel special; this was one of my lesser contributions to Plan 9.
this stopped after a while (several to many months, maybe).
andrew hume
From rminnich at gmail.com Mon Jan 18 02:37:38 2021
From: rminnich at gmail.com (ron minnich)
Date: Sun, 17 Jan 2021 08:37:38 -0800
Subject: [TUHS] EGREG
In-Reply-To: <A958535E-7F0D-48F5-A248-438479BEC421@humeweb.com>
References: <A958535E-7F0D-48F5-A248-438479BEC421@humeweb.com>
Message-ID: <CAP6exYKu8hOr7Opu1vRVKWsF-GB5=tVxTjkQ6-_gB4aOdeVu3Q@mail.gmail.com>
But this is you, right?
"sys/games/lib/fortunes:I'm just andrew. -andrew"
On Sun, Jan 17, 2021 at 7:19 AM Andrew Hume <andrew at humeweb.com> wrote:
>
> i have probed recently about the origins of the “EGREG†(its all greg cession’s fault) error in Research Unix.
> alas, i recall nothing about this, and can’t recall ever getting the message.
>
> however, courtesy of Dave Presotto (i am fairly sure), there was an equivalent error
> in Plan 9, where more or less randomly, if your user id was ‘andrew’, system calls would fail.
> and yes, i did feel special; this was one of my lesser contributions to Plan 9.
> this stopped after a while (several to many months, maybe).
>
> andrew hume
>
From clemc at ccc.com Mon Jan 18 03:00:36 2021
From: clemc at ccc.com (Clem Cole)
Date: Sun, 17 Jan 2021 12:00:36 -0500
Subject: [TUHS] sam leffler, rob pike
In-Reply-To: <7436C8FC-63DB-442B-9510-857CEDEE24BA@humeweb.com>
References: <09B601EA-DA27-4A5D-B373-E914760F05CF@humeweb.com>
<7436C8FC-63DB-442B-9510-857CEDEE24BA@humeweb.com>
Message-ID: <CAC20D2OKMzUizb_Ox_ct4cCrrADhUxtBB9q2PoxJTiWjb+5+Vw@mail.gmail.com>
Andrew,
Thanks for letting us know. CCing TUHS as you did and BCCing a few others
that may not monitor the list.
FWIW: the graveside service was wonderful. His daughter Devin did a super
job in her eulogy.
That said, I am passing on a message from the family. For those of us
that knew him and worked with him over the years, the family is asking for
memories to be added here:
Benjamin's Park Memorial Chapel - Memorial Book
On Sat, Jan 16, 2021 at 4:36 AM Andrew Hume <andrew at humeweb.com> wrote:
> umm, a correction; joe sent me another link for the funeral:
>
> Also I sent the wrong link, typical of me. Benjamin's Park Memorial
> Chapel - Service Details
> <https://www.benjaminsparkmemorialchapel.ca/ServiceDetails.aspx?snum=127607&fg=0>
>
>
> On Jan 15, 2021, at 5:54 PM, Andrew Hume <andrew at humeweb.com> wrote:
>
> an urgent request: can someone please send me sam leaflet’s email address?
> its needed for a funeral (dave tilbrook just died).
> also, rob pike, can you send me your email please?
> (these are for tilbrook’s son.)
>
>
> á§
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210117/8324943b/attachment.htm>
From andrew at humeweb.com Mon Jan 18 02:39:08 2021
From: andrew at humeweb.com (Andrew Hume)
Date: Sun, 17 Jan 2021 08:39:08 -0800
Subject: [TUHS] EGREG
In-Reply-To: <CAP6exYKu8hOr7Opu1vRVKWsF-GB5=tVxTjkQ6-_gB4aOdeVu3Q@mail.gmail.com>
References: <A958535E-7F0D-48F5-A248-438479BEC421@humeweb.com>
<CAP6exYKu8hOr7Opu1vRVKWsF-GB5=tVxTjkQ6-_gB4aOdeVu3Q@mail.gmail.com>
Message-ID: <80FFBC07-6DA2-4F7B-A717-7393E308B6EE@humeweb.com>
yes. but that stems from another tale.
> On Jan 17, 2021, at 8:37 AM, ron minnich <rminnich at gmail.com> wrote:
>
> But this is you, right?
> "sys/games/lib/fortunes:I'm just andrew. -andrew"
>
> On Sun, Jan 17, 2021 at 7:19 AM Andrew Hume <andrew at humeweb.com> wrote:
>>
>> i have probed recently about the origins of the “EGREG†(its all greg cession’s fault) error in Research Unix.
>> alas, i recall nothing about this, and can’t recall ever getting the message.
>>
>> however, courtesy of Dave Presotto (i am fairly sure), there was an equivalent error
>> in Plan 9, where more or less randomly, if your user id was ‘andrew’, system calls would fail.
>> and yes, i did feel special; this was one of my lesser contributions to Plan 9.
>> this stopped after a while (several to many months, maybe).
>>
>> andrew hume
>>
From norman at oclsc.org Mon Jan 18 06:52:43 2021
From: norman at oclsc.org (Norman Wilson)
Date: Sun, 17 Jan 2021 15:52:43 -0500 (EST)
Subject: [TUHS] EGREG
Message-ID: <20210117205243.739CB43F88@lignose.oclsc.org>
Andrew Hume (dammit andrew):
i have probed recently about the origins of the b EGREGb (its all greg cession's fault) error in Research Unix.
alas, i recall nothing about this, and can't recall ever getting the message.
===
Your memory fails you, which is not unreasonable for stuff you
probably haven't thought about in more than 30 years:
/*
SCSI Pass-Thru driver for the TD Systems UD? -- Andrew Hume
Ninth Edition Unix
*/
[...]
scsiwrite(dev)
dev_t dev;
{
register count;
register struct scsi *p = &scsi[minor(dev)];
register struct mscmd *cmd = &p->junk->cmd.msg;
unsigned char flag, bus_id;
if(p->flag&NEXTWR)
p->flag &= ~NEXTWR;
else {
u.u_error = EGREG;
return;
}
As I remember it, EGREG went into errno.h and libc out
of a desire to have some never-normally-used error to
be returned when debugging. I forget just who was in
the UNIX Room conversation that created it; almost certainly
I was. I thought andrew was as well; very likely one or
more of andrew td presotto.
I do remember being a bit annoyed at Andrew for putting it
in permanent use in the raw-SCSI driver (which was at the
time of interest mainly to Andrew for controlling an
early optical-disc jukebox, used by the original File
Motel backup system).
As to the origin of `It's all Greg's fault' as a meme,
that was already around and established when I arrived at
the Labs in mid-1984, though Greg himself had already
moved west. Maybe Doug or Ken remembers how that started.
Andrew himself was responsible for or blamed by more than
one meme of the days. The scsi driver spawned one, in fact:
the first attempt used a SCSI interface from Emulex, which
never worked quite right, and despite repeated phone calls
to Emulex Andrew could never get it figured out. He tried
and tried, though, and his attempts spawned the catch
phrase `Time to call Emulex again!'
Norman Wilson
Toronto ON
From lm at mcvoy.com Mon Jan 18 07:14:32 2021
From: lm at mcvoy.com (Larry McVoy)
Date: Sun, 17 Jan 2021 13:14:32 -0800
Subject: [TUHS] EGREG
In-Reply-To: <20210117205243.739CB43F88@lignose.oclsc.org>
References: <20210117205243.739CB43F88@lignose.oclsc.org>
Message-ID: <20210117211432.GM27899@mcvoy.com>
On Sun, Jan 17, 2021 at 03:52:43PM -0500, Norman Wilson wrote:
> As to the origin of `It's all Greg's fault' as a meme,
> that was already around and established when I arrived at
> the Labs in mid-1984, though Greg himself had already
> moved west. Maybe Doug or Ken remembers how that started.
I worked for Greg at SGI and loved that I got to do so. This whole
EGREG thing is news to me and amusing, Greg was the sort to laugh
at himself.
I'm sure I've told this story but just in case. Not long before he
died, the cancer came back, he called me up and wanted to come up
and hang out with me on my place in the Santa Cruz mountains. I
asked what was up and he was all "Kids these days with their shiney
frameworks and Javascript and $JUNK_HE_DIDNT_LIKE, I just want to
talk to someone who likes C and kernels." I said fine, but you
have to run the excavator. I had bought a used 12,000 pound Kubota
excavator, it's useful where I live, I have 15 acres, trust me, it
gets used a lot.
So he came up. He was not in great shape, the only thing that he
could "eat" was tiny chips of ice. Actual food was baby formula,
or something a lot like it, that went into a tube that when to his
stomach.
While his was body failing, his mind was 100% there, Greg was the
same Greg that I had met more than 20 years earlier. I met him right
as he got cancer the first time, got hired and Greg went away for
6 months and came back looking a lot older.
So we talked, it was pretty much what you might imagine, talked about
kernels and problems we had hit and solved, it was pretty basic,
nothing fancy. It was pleasant.
He is getting ready to leave and I said you have to run the excavator.
"I don't want to run the excavator."
"I don't care, you promised."
The excavator tends to live next to a pile of logs and I put all sorts
of people in it, Greg was perfect because he was sick and weak. The
machine doesn't care, if you can move a joystick, you can run it.
Greg being Greg, he refused to let me show him how it works. It has
two forward/reverse joysticks that run the tracks, a 4 way joystick
that runs the dozer blade, and 2 4 way joysticks that run the two booms,
control rotation, and curl the bucket. And there is a rocker switch on
the right hand joystick that controls the hydraulic thumb. Greg wouldn't
let me show him anything, he just got on it and started playing. If you
go through the pictures, I definitely got the concentration, I'm not sure
I captured how grumpy he was. He was trying to pick up a heavy wet log
and it kept slipping out. But at picture 7 and 8, big old Greg grin,
he figured out how to curl the bucket under the log and that held.
http://www.mcvoy.com/lm/xtp+excavator/
That's the last time I saw Greg alive, sadly. He was a gentle soul and
I miss him.
BTW, I told that story, and brought those pics, at his funeral. That
story is so typical Greg all the way through.
From dave at horsfall.org Mon Jan 18 08:19:25 2021
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 18 Jan 2021 09:19:25 +1100 (EST)
Subject: [TUHS] ACM Fellow, Ken Thompson
In-Reply-To: <CAD2gp_Qmf2QLT98Zk-D5MT0ph3gkQowfS3318KhN2OaiMdq7FQ@mail.gmail.com>
References: <CA+E3k92c+M5tH2ht+ZUpd6BE9OS_ZW_-QsZrrBCcEJQ+X4bmQg@mail.gmail.com>
<alpine.BSF.2.21.9999.2101141549020.26789@aneurin.horsfall.org>
<CAD2gp_Tt+S760WF79y914cC9tB6vAYJEG=rq4JP7axptqhVxDg@mail.gmail.com>
<alpine.BSF.2.21.9999.2101160705190.95135@aneurin.horsfall.org>
<CAD2gp_Qmf2QLT98Zk-D5MT0ph3gkQowfS3318KhN2OaiMdq7FQ@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.2101180911290.95135@aneurin.horsfall.org>
On Fri, 15 Jan 2021, John Cowan wrote (and somehow mangled the formatting)::
> > > Whose foray? Not DEC's. Eunice was built at SRI and sold by
> > the
> > > Wollongong Group, who must have had Downundrian connections. Â
>
> >
> > Â It was
> > originally developed ca. 1981 by David Kashtan at SRI[1] and
> > later
> > maintained and marketed by The Wollongong Group.''
>
> Where's the disagreement?
You appeared to disagree with my (joking) observation that Eunice made VMS
look civilised, as though Eunice was never designed for it (I have the
thread archived somewhere).
-- Dave
From norman at oclsc.org Mon Jan 18 08:33:46 2021
From: norman at oclsc.org (Norman Wilson)
Date: Sun, 17 Jan 2021 17:33:46 -0500
Subject: [TUHS] Bearded Fellow, Ken Thompson
Message-ID: <1610922832.12835.for-standards-violators@oclsc.org>
Dave Horsfall:
At one place I worked, every Unix bod sported facial fungus; it must be a
Unix thing...
====
Not really. I've seen bare faces and beards and operating systems
over the decades that would scare the bugs out of any of the above
beards and operating systems. There really isn't a lot of consistency.
I've known plenty of bare-faced UNIX hacks, and plenty of RSX and
VMS and Windows and IBM programmers who hide their embarrassment
behind beards.
The ultimate reference is, of course, the inhabitants of the UNIX
Room. During my time there in mid-to-late 1980s, some people wore
beards, some didn't. I have never seen Ken or Dennis or Brian
clean-shaven, but I have never seen Doug or Rob or Tom Duff or
Lorinda with a beard.
And despite a certain remark attributed to the late Vic Vyssotsky
(who I've never seen with a beard either), I am quite sure that
my appearance had nothing to do with my being recruited by the group.
Norman `too lazy to shave' Wilson
Toronto ON
From robpike at gmail.com Mon Jan 18 09:20:18 2021
From: robpike at gmail.com (Rob Pike)
Date: Mon, 18 Jan 2021 10:20:18 +1100
Subject: [TUHS] EGREG
In-Reply-To: <20210117211432.GM27899@mcvoy.com>
References: <20210117205243.739CB43F88@lignose.oclsc.org>
<20210117211432.GM27899@mcvoy.com>
Message-ID: <CAKzdPgygerLP3ZHKtZ9zzRc84VD6Kn8LE2pG6GnLTuNGHOPxeQ@mail.gmail.com>
I too miss Greg acutely.
The error message arose because of bugs blamed on Greg, arising from the
combination of Datakit code and mpx, both of which were responsible for
innumerable kernel crashes. So one day, needing a new error code for
debugging, EGREG was born. I remember Ken being the creator, but it might
have been Dennis. Ken's sense of humor is a better match, though. (Or mine,
but I'm not taking credit without corroboration.)
-rob
On Mon, Jan 18, 2021 at 8:15 AM Larry McVoy <lm at mcvoy.com> wrote:
> On Sun, Jan 17, 2021 at 03:52:43PM -0500, Norman Wilson wrote:
> > As to the origin of `It's all Greg's fault' as a meme,
> > that was already around and established when I arrived at
> > the Labs in mid-1984, though Greg himself had already
> > moved west. Maybe Doug or Ken remembers how that started.
>
> I worked for Greg at SGI and loved that I got to do so. This whole
> EGREG thing is news to me and amusing, Greg was the sort to laugh
> at himself.
>
> I'm sure I've told this story but just in case. Not long before he
> died, the cancer came back, he called me up and wanted to come up
> and hang out with me on my place in the Santa Cruz mountains. I
> asked what was up and he was all "Kids these days with their shiney
> frameworks and Javascript and $JUNK_HE_DIDNT_LIKE, I just want to
> talk to someone who likes C and kernels." I said fine, but you
> have to run the excavator. I had bought a used 12,000 pound Kubota
> excavator, it's useful where I live, I have 15 acres, trust me, it
> gets used a lot.
>
> So he came up. He was not in great shape, the only thing that he
> could "eat" was tiny chips of ice. Actual food was baby formula,
> or something a lot like it, that went into a tube that when to his
> stomach.
>
> While his was body failing, his mind was 100% there, Greg was the
> same Greg that I had met more than 20 years earlier. I met him right
> as he got cancer the first time, got hired and Greg went away for
> 6 months and came back looking a lot older.
>
> So we talked, it was pretty much what you might imagine, talked about
> kernels and problems we had hit and solved, it was pretty basic,
> nothing fancy. It was pleasant.
>
> He is getting ready to leave and I said you have to run the excavator.
> "I don't want to run the excavator."
> "I don't care, you promised."
>
> The excavator tends to live next to a pile of logs and I put all sorts
> of people in it, Greg was perfect because he was sick and weak. The
> machine doesn't care, if you can move a joystick, you can run it.
>
> Greg being Greg, he refused to let me show him how it works. It has
> two forward/reverse joysticks that run the tracks, a 4 way joystick
> that runs the dozer blade, and 2 4 way joysticks that run the two booms,
> control rotation, and curl the bucket. And there is a rocker switch on
> the right hand joystick that controls the hydraulic thumb. Greg wouldn't
> let me show him anything, he just got on it and started playing. If you
> go through the pictures, I definitely got the concentration, I'm not sure
> I captured how grumpy he was. He was trying to pick up a heavy wet log
> and it kept slipping out. But at picture 7 and 8, big old Greg grin,
> he figured out how to curl the bucket under the log and that held.
>
> http://www.mcvoy.com/lm/xtp+excavator/
>
> That's the last time I saw Greg alive, sadly. He was a gentle soul and
> I miss him.
>
> BTW, I told that story, and brought those pics, at his funeral. That
> story is so typical Greg all the way through.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210118/775e98c4/attachment.htm>
From athornton at gmail.com Mon Jan 18 13:39:39 2021
From: athornton at gmail.com (Adam Thornton)
Date: Sun, 17 Jan 2021 20:39:39 -0700
Subject: [TUHS] Bearded Fellow, Ken Thompson
In-Reply-To: <1610922832.12835.for-standards-violators@oclsc.org>
References: <1610922832.12835.for-standards-violators@oclsc.org>
Message-ID: <CAP2nic3rMqRFkH82d0dQARZWGsDF1pTi3m0g0yXdbzHgg4yPfg@mail.gmail.com>
For what it's worth, at a certain point in my life I had a SERIOUS beard,
and I appeared in a friend of mine's text-with-static-graphics adventure
game ("Cryptozookeeper") with a comment like "The UNIX beard swallows all
other facial features."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210117/f349f32b/attachment.htm>
From andrew at humeweb.com Mon Jan 18 15:29:22 2021
From: andrew at humeweb.com (Andrew Hume)
Date: Sun, 17 Jan 2021 21:29:22 -0800
Subject: [TUHS] Bearded Fellow, Ken Thompson
In-Reply-To: <1610922832.12835.for-standards-violators@oclsc.org>
References: <1610922832.12835.for-standards-violators@oclsc.org>
Message-ID: <EF54EAE0-7D33-4421-9D4D-2A3BC61F9663@humeweb.com>
not so fast, there, young pup.
i distinctly remember vic saying something to the effect of
“we have to hire that guy; he will increase our varianceâ€
as you wandered out of an interview with fred grampp.
> On Jan 17, 2021, at 2:33 PM, Norman Wilson <norman at oclsc.org> wrote:
>
> And despite a certain remark attributed to the late Vic Vyssotsky
> (who I've never seen with a beard either), I am quite sure that
> my appearance had nothing to do with my being recruited by the group.
>
> Norman `too lazy to shave' Wilson
> Toronto ON
From andrew at humeweb.com Mon Jan 18 15:39:04 2021
From: andrew at humeweb.com (Andrew Hume)
Date: Sun, 17 Jan 2021 21:39:04 -0800
Subject: [TUHS] EGREG
In-Reply-To: <20210117205243.739CB43F88@lignose.oclsc.org>
References: <20210117205243.739CB43F88@lignose.oclsc.org>
Message-ID: <135414D4-7982-4015-BEE7-39EBFC930B36@humeweb.com>
the evidence looks damning, but i still can’t recall.
i will, however, admit to this driver incorporating some code
my cat typed. i had left my (sam) editor open on the driver
and the cat trampled on the keyboard. unfortunately, it was centered
on a octal constant (setting some bits in a control register) and so went
undetected for a few days. darn kitty!
andrew
> On Jan 17, 2021, at 12:52 PM, Norman Wilson <norman at oclsc.org> wrote:
>
> Andrew Hume (dammit andrew):
>
> i have probed recently about the origins of the b EGREGb (its all greg cession's fault) error in Research Unix.
> alas, i recall nothing about this, and can't recall ever getting the message.
>
> ===
>
> Your memory fails you, which is not unreasonable for stuff you
> probably haven't thought about in more than 30 years:
>
> /*
> SCSI Pass-Thru driver for the TD Systems UD? -- Andrew Hume
> Ninth Edition Unix
> */
>
> [...]
>
> scsiwrite(dev)
> dev_t dev;
> {
> register count;
> register struct scsi *p = &scsi[minor(dev)];
> register struct mscmd *cmd = &p->junk->cmd.msg;
> unsigned char flag, bus_id;
>
> if(p->flag&NEXTWR)
> p->flag &= ~NEXTWR;
> else {
> u.u_error = EGREG;
> return;
> }
>
>
> Norman Wilson
> Toronto ON
From cowan at ccil.org Tue Jan 19 05:58:36 2021
From: cowan at ccil.org (John Cowan)
Date: Mon, 18 Jan 2021 14:58:36 -0500
Subject: [TUHS] Bearded Fellow, Ken Thompson
In-Reply-To: <1610922832.12835.for-standards-violators@oclsc.org>
References: <1610922832.12835.for-standards-violators@oclsc.org>
Message-ID: <CAD2gp_QLoz76QR0JCh=mGrv85dmn2K6SzFU7Vqa6Wrjad4L8pQ@mail.gmail.com>
On Sun, Jan 17, 2021 at 5:35 PM Norman Wilson <norman at oclsc.org> wrote:
> Not really. I've seen bare faces and beards and operating systems
> over the decades that would scare the bugs out of any of the above
> beards and operating systems. There really isn't a lot of consistency.
> I've known plenty of bare-faced UNIX hacks, and plenty of RSX and
> VMS and Windows and IBM programmers who hide their embarrassment
> behind beards.
>
I don't think it's so much a matter of wearing a beard, but being allowed
to wear one. For seven grim decades no American man could get away with a
beard, after the end of the post-Civil War era, in which a beard was the
sign of a veteran (try shaving in the field!) Mustaches (often handlebars
or toothbrushes until WWII) were the limit of tolerable facial hair among
respectable company employees.
That began to change in the 1960s, when many things did. Still, hippies
and musicians and poets wore beards but few others did; facial hair didn't
really take off among the gen. pop. until the 70s.
But somehow, programmer beards were tolerated, first at universities, then
at research labs, and then throughout the industry, then throughout every
industry, though I myself was one of only two beards at the Wall Street
brokerage I worked for in the early 80s, the other being my boss. Even
today, $EMPLOYER, which is an ex-startup, has a mixture of beards and
no-beards among the male engineers, but all the sales and marketing males
are clean-shaven.
(When I met my future wife I was 21, and she wanted me to grow a beard, so
I did. Since then I have occasionally asked cow orkers who have complained
about shaving why *they* don't grow beards: the most common answer is "My
wife doesn't want me to." *My* wife doesn't believe this story.)
John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org
And through this revolting graveyard of the universe the muffled,
maddening beating of drums, and thin, monotonous whine of blasphemous
flutes from inconceivable, unlighted chambers beyond Time; the
detestable pounding and piping whereunto dance slowly, awkwardly, and
absurdly the gigantic tenebrous ultimate gods --the blind, voiceless,
mindless gargoyles whose soul is Nyarlathotep. (Lovecraft)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210118/0a355d52/attachment.htm>
From usotsuki at buric.co Tue Jan 19 06:47:48 2021
From: usotsuki at buric.co (Steve Nickolas)
Date: Mon, 18 Jan 2021 15:47:48 -0500 (EST)
Subject: [TUHS] Bearded Fellow, Ken Thompson
In-Reply-To: <CAD2gp_QLoz76QR0JCh=mGrv85dmn2K6SzFU7Vqa6Wrjad4L8pQ@mail.gmail.com>
References: <1610922832.12835.for-standards-violators@oclsc.org>
<CAD2gp_QLoz76QR0JCh=mGrv85dmn2K6SzFU7Vqa6Wrjad4L8pQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.21.2101181547020.7448@sd-119843.dedibox.fr>
On Mon, 18 Jan 2021, John Cowan wrote:
> (When I met my future wife I was 21, and she wanted me to grow a beard, so
> I did. Since then I have occasionally asked cow orkers who have complained
> about shaving why *they* don't grow beards: the most common answer is "My
> wife doesn't want me to." *My* wife doesn't believe this story.)
I actually had to shave for a while specifically because of my
then-girlfriend, so... ;p I can see that.
-uso.
From arnold at skeeve.com Tue Jan 19 18:07:16 2021
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Tue, 19 Jan 2021 01:07:16 -0700
Subject: [TUHS] Bearded Fellow, Ken Thompson
In-Reply-To: <alpine.DEB.2.21.2101181547020.7448@sd-119843.dedibox.fr>
References: <1610922832.12835.for-standards-violators@oclsc.org>
<CAD2gp_QLoz76QR0JCh=mGrv85dmn2K6SzFU7Vqa6Wrjad4L8pQ@mail.gmail.com>
<alpine.DEB.2.21.2101181547020.7448@sd-119843.dedibox.fr>
Message-ID: <202101190807.10J87Gh5009801@freefriends.org>
Steve Nickolas <usotsuki at buric.co> wrote:
> On Mon, 18 Jan 2021, John Cowan wrote:
>
> > (When I met my future wife I was 21, and she wanted me to grow a beard, so
> > I did. Since then I have occasionally asked cow orkers who have complained
> > about shaving why *they* don't grow beards: the most common answer is "My
> > wife doesn't want me to." *My* wife doesn't believe this story.)
>
> I actually had to shave for a while specifically because of my
> then-girlfriend, so... ;p I can see that.
>
> -uso.
Since we've wondered off-topic...
There are two periods of time in the spring and late summer when many
Orthodox Jews don't shave (5 and 3 weeks long, respectively). The deal
I reached with my wife is that I have a beard from the start of the
first one to the end of the second one. It's worked now for just over
30 years... :-)
Arnold
From steffen at sdaoden.eu Wed Jan 20 04:45:54 2021
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Tue, 19 Jan 2021 19:45:54 +0100
Subject: [TUHS] Bearded Fellow, Ken Thompson
In-Reply-To: <202101190807.10J87Gh5009801@freefriends.org>
References: <1610922832.12835.for-standards-violators@oclsc.org>
<CAD2gp_QLoz76QR0JCh=mGrv85dmn2K6SzFU7Vqa6Wrjad4L8pQ@mail.gmail.com>
<alpine.DEB.2.21.2101181547020.7448@sd-119843.dedibox.fr>
<202101190807.10J87Gh5009801@freefriends.org>
Message-ID: <20210119184554.uCRQ_%steffen@sdaoden.eu>
arnold at skeeve.com wrote in
<202101190807.10J87Gh5009801 at freefriends.org>:
|Steve Nickolas <usotsuki at buric.co> wrote:
|
|> On Mon, 18 Jan 2021, John Cowan wrote:
|>
|>> (When I met my future wife I was 21, and she wanted me to grow a \
|>> beard, so
|>> I did. Since then I have occasionally asked cow orkers who have \
|>> complained
|>> about shaving why *they* don't grow beards: the most common answer \
|>> is "My
|>> wife doesn't want me to." *My* wife doesn't believe this story.)
|>
|> I actually had to shave for a while specifically because of my
|> then-girlfriend, so... ;p I can see that.
|>
|> -uso.
|
|Since we've wondered off-topic...
|
|There are two periods of time in the spring and late summer when many
|Orthodox Jews don't shave (5 and 3 weeks long, respectively). The deal
|I reached with my wife is that I have a beard from the start of the
|first one to the end of the second one. It's worked now for just over
|30 years... :-)
This discussion reminds me of the Jiddish joke (as heard from
Jews, and badly translated from German, not to mention Jiddish)
Two jewish men meet and greet each other
Says the elder "ah, you had sardines for lunch"
says the younger "no, sardines we had three days ago"
--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 wkt at tuhs.org Wed Jan 20 08:15:10 2021
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 20 Jan 2021 08:15:10 +1000
Subject: [TUHS] Bearded Fellow, Ken Thompson
In-Reply-To: <202101190807.10J87Gh5009801@freefriends.org>
References: <1610922832.12835.for-standards-violators@oclsc.org>
<CAD2gp_QLoz76QR0JCh=mGrv85dmn2K6SzFU7Vqa6Wrjad4L8pQ@mail.gmail.com>
<alpine.DEB.2.21.2101181547020.7448@sd-119843.dedibox.fr>
<202101190807.10J87Gh5009801@freefriends.org>
Message-ID: <20210119221510.GA30919@minnie.tuhs.org>
Hi all,
$ mv beards /var/mail/COFF
Many thanks!
Warren
P.S Yes, I know, >>
From heinz at osta.com Wed Jan 20 08:29:57 2021
From: heinz at osta.com (Heinz Lycklama)
Date: Tue, 19 Jan 2021 14:29:57 -0800
Subject: [TUHS] ACM Fellow, Ken Thompson
In-Reply-To: <CANCZdfqNQC3TXMKuppiVybmYTXEz0h+HvE8QXEeh8sWeONPqnA@mail.gmail.com>
References: <CA+E3k92c+M5tH2ht+ZUpd6BE9OS_ZW_-QsZrrBCcEJQ+X4bmQg@mail.gmail.com>
<alpine.BSF.2.21.9999.2101141549020.26789@aneurin.horsfall.org>
<CAD2gp_Tt+S760WF79y914cC9tB6vAYJEG=rq4JP7axptqhVxDg@mail.gmail.com>
<alpine.BSF.2.21.9999.2101160705190.95135@aneurin.horsfall.org>
<CAD2gp_Qmf2QLT98Zk-D5MT0ph3gkQowfS3318KhN2OaiMdq7FQ@mail.gmail.com>
<CANCZdfqNQC3TXMKuppiVybmYTXEz0h+HvE8QXEeh8sWeONPqnA@mail.gmail.com>
Message-ID: <66d2d6e9-921c-8039-1d84-0461f9192a28@osta.com>
INTERACTIVE Systems Corp. (ISC) also ported a UNIX system to an
early VAX 750 computer running DEC's VMS operating system
starting in mid- 1978. ISC was in the business of porting the
UNIX operating system to many different computer hardware
architectures, mini-computers to mainframes, but the first
complete UNIX system port was actually done to the DEC VMS
system. We delivered the first UNIX on VMS system to a customer
in the Fall of 1979. Many of these systems were delivered to
customers in North America as well as in Europe well into
the mid-1980's.
Heinz
On 1/15/2021 6:29 PM, Warner Losh wrote:
>
>
> On Fri, Jan 15, 2021 at 3:18 PM John Cowan <cowan at ccil.org
> <mailto:cowan at ccil.org>> wrote:
>
>
>
> On Fri, Jan 15, 2021 at 3:14 PM Dave Horsfall <dave at horsfall.org
> <mailto:dave at horsfall.org>> wrote:
>
> > Whose foray? Not DEC's. Eunice was built at SRI and sold by
> the
> > Wollongong Group, who must have had Downundrian connections.
>
> Â It was
> originally developed ca. 1981 by David Kashtan at SRI[1] and later
> maintained and marketed by The Wollongong Group.''
>
>
> Where's the disagreement?
>
>
> Eunice post-dated DEC's first Unix offering by several years. They
> sold V7 and later V7M before rebranding it to Ultrix. Eunice was
> 4.1BSD (later 4.2 and 4.3) that Dr Kashtan grafted into VMS in ways
> that... provoke strong feelings among reviewers... The TCP/IP stack
> that was inside of Eunice would form the basis for Wollongong's TCP/IP
> offerings on VMS... A more refined version, also done I think by
> Kashtan, was marketed by TGV and there was always much rivalry between
> the two companies...
>
> Wollongong got its license because they were the marketing company
> formed to market Dr. Miller's port to Interdata, and they later
> branched out significantly because their license was so special... Or
> at least that's the story they told customers and internally... I
> never saw the original license to know...
>
> Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210119/c0e72f4f/attachment.htm>
From imp at bsdimp.com Wed Jan 20 08:33:14 2021
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 19 Jan 2021 15:33:14 -0700
Subject: [TUHS] ACM Fellow, Ken Thompson
In-Reply-To: <66d2d6e9-921c-8039-1d84-0461f9192a28@osta.com>
References: <CA+E3k92c+M5tH2ht+ZUpd6BE9OS_ZW_-QsZrrBCcEJQ+X4bmQg@mail.gmail.com>
<alpine.BSF.2.21.9999.2101141549020.26789@aneurin.horsfall.org>
<CAD2gp_Tt+S760WF79y914cC9tB6vAYJEG=rq4JP7axptqhVxDg@mail.gmail.com>
<alpine.BSF.2.21.9999.2101160705190.95135@aneurin.horsfall.org>
<CAD2gp_Qmf2QLT98Zk-D5MT0ph3gkQowfS3318KhN2OaiMdq7FQ@mail.gmail.com>
<CANCZdfqNQC3TXMKuppiVybmYTXEz0h+HvE8QXEeh8sWeONPqnA@mail.gmail.com>
<66d2d6e9-921c-8039-1d84-0461f9192a28@osta.com>
Message-ID: <CANCZdfoPfsjzDXaFVNxMgfNd=-sH6tvnrWcVWmSgQ+Ai6+1g=A@mail.gmail.com>
On Tue, Jan 19, 2021 at 3:30 PM Heinz Lycklama <heinz at osta.com> wrote:
> INTERACTIVE Systems Corp. (ISC) also ported a UNIX system to an
> early VAX 750 computer running DEC's VMS operating system
> starting in mid- 1978. ISC was in the business of porting the
> UNIX operating system to many different computer hardware
> architectures, mini-computers to mainframes, but the first
> complete UNIX system port was actually done to the DEC VMS
> system. We delivered the first UNIX on VMS system to a customer
> in the Fall of 1979. Many of these systems were delivered to
> customers in North America as well as in Europe well into
> the mid-1980's.
>
What relationship, if any, does this have to V32? Or maybe "Was that based
on V7 or V32?" is the right question...
Also, this wasn't something that I had on my list... Any chance there's a
paper / article / etc on this?
And thank you for your remembrance...
Warner
> Heinz
>
> On 1/15/2021 6:29 PM, Warner Losh wrote:
>
>
>
> On Fri, Jan 15, 2021 at 3:18 PM John Cowan <cowan at ccil.org> wrote:
>
>>
>>
>> On Fri, Jan 15, 2021 at 3:14 PM Dave Horsfall <dave at horsfall.org> wrote:
>>
>>
>>> > Whose foray? Not DEC's. Eunice was built at SRI and sold by the
>>> > Wollongong Group, who must have had Downundrian connections.
>>>
>>
>>
>>> It was
>>> originally developed ca. 1981 by David Kashtan at SRI[1] and later
>>> maintained and marketed by The Wollongong Group.''
>>>
>>
>> Where's the disagreement?
>>
>
> Eunice post-dated DEC's first Unix offering by several years. They sold V7
> and later V7M before rebranding it to Ultrix. Eunice was 4.1BSD (later 4.2
> and 4.3) that Dr Kashtan grafted into VMS in ways that... provoke strong
> feelings among reviewers... The TCP/IP stack that was inside of Eunice
> would form the basis for Wollongong's TCP/IP offerings on VMS... A more
> refined version, also done I think by Kashtan, was marketed by TGV and
> there was always much rivalry between the two companies...
>
> Wollongong got its license because they were the marketing company formed
> to market Dr. Miller's port to Interdata, and they later branched out
> significantly because their license was so special... Or at least that's
> the story they told customers and internally... I never saw the original
> license to know...
>
> Warner
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210119/d8620bfb/attachment.htm>
From Caipenghui_c at 163.com Wed Jan 20 13:26:09 2021
From: Caipenghui_c at 163.com (Caipenghui)
Date: Wed, 20 Jan 2021 11:26:09 +0800
Subject: [TUHS] Happy Birthday to Marshall Kirk McKusick
Message-ID: <18D48457-A377-4877-B8B8-BE7F359531F0@163.com>
Thank you for your work to make the world a better, happy birthday to you.
God bless us.
#define FS_UFS2_MAGIC 0x19540119
Caipenghui
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210120/f5d10844/attachment.htm>
From heinz at osta.com Wed Jan 20 15:21:19 2021
From: heinz at osta.com (Heinz Lycklama)
Date: Tue, 19 Jan 2021 21:21:19 -0800
Subject: [TUHS] ACM Fellow, Ken Thompson
In-Reply-To: <CANCZdfoPfsjzDXaFVNxMgfNd=-sH6tvnrWcVWmSgQ+Ai6+1g=A@mail.gmail.com>
References: <CA+E3k92c+M5tH2ht+ZUpd6BE9OS_ZW_-QsZrrBCcEJQ+X4bmQg@mail.gmail.com>
<alpine.BSF.2.21.9999.2101141549020.26789@aneurin.horsfall.org>
<CAD2gp_Tt+S760WF79y914cC9tB6vAYJEG=rq4JP7axptqhVxDg@mail.gmail.com>
<alpine.BSF.2.21.9999.2101160705190.95135@aneurin.horsfall.org>
<CAD2gp_Qmf2QLT98Zk-D5MT0ph3gkQowfS3318KhN2OaiMdq7FQ@mail.gmail.com>
<CANCZdfqNQC3TXMKuppiVybmYTXEz0h+HvE8QXEeh8sWeONPqnA@mail.gmail.com>
<66d2d6e9-921c-8039-1d84-0461f9192a28@osta.com>
<CANCZdfoPfsjzDXaFVNxMgfNd=-sH6tvnrWcVWmSgQ+Ai6+1g=A@mail.gmail.com>
Message-ID: <b0eadec6-32ce-f2c5-0efa-62f2e7e97c53@osta.com>
No relation to either V32 or V7. When we started the project
we used the existing version of UNIX that we were selling on
the PDP 11/45 and PDP 11/70 computers. I believe it was V6.
I wrote a lot of documentation and gave a lot of talks and
presentations on the system, but never kept any of the
documentation myself. There may be some documentation
in someone's archives but I did not keep any.
Heinz
On 1/19/2021 2:33 PM, Warner Losh wrote:
>
>
> On Tue, Jan 19, 2021 at 3:30 PM Heinz Lycklama <heinz at osta.com
> <mailto:heinz at osta.com>> wrote:
>
> INTERACTIVE Systems Corp. (ISC) also ported a UNIX system to an
> early VAX 11/750 computer running DEC's VMS operating system
> starting in mid- 1978. ISC was in the business of porting the
> UNIX operating system to many different computer hardware
> architectures, mini-computers to mainframes, but the first
> complete UNIX system port was actually done to the DEC VMS
> system. We delivered the first UNIX on VMS system to a customer
> in the Fall of 1979. Many of these systems were delivered to
> customers in North America as well as in Europe well into
> the mid-1980's.
>
>
> What relationship, if any, does this have to V32? Or maybe "Was that
> based on V7 or V32?" is the right question...
>
> Also, this wasn't something that I had on my list... Any chance
> there's a paper / article / etc on this?
>
> And thank you for your remembrance...
>
> Warner
>
> Heinz
>
> On 1/15/2021 6:29 PM, Warner Losh wrote:
>>
>>
>> On Fri, Jan 15, 2021 at 3:18 PM John Cowan <cowan at ccil.org
>> <mailto:cowan at ccil.org>> wrote:
>>
>>
>>
>> On Fri, Jan 15, 2021 at 3:14 PM Dave Horsfall
>> <dave at horsfall.org <mailto:dave at horsfall.org>> wrote:
>>
>> > Whose foray? Not DEC's. Eunice was built at SRI and
>> sold by the
>> > Wollongong Group, who must have had Downundrian
>> connections.
>>
>> Â It was
>> originally developed ca. 1981 by David Kashtan at SRI[1]
>> and later
>> maintained and marketed by The Wollongong Group.''
>>
>>
>> Where's the disagreement?
>>
>>
>> Eunice post-dated DEC's first Unix offering by several years.
>> They sold V7 and later V7M before rebranding it to Ultrix. Eunice
>> was 4.1BSD (later 4.2 and 4.3) that Dr Kashtan grafted into VMS
>> in ways that... provoke strong feelings among reviewers... The
>> TCP/IP stack that was inside of Eunice would form the basis for
>> Wollongong's TCP/IP offerings on VMS... A more refined version,
>> also done I think by Kashtan, was marketed by TGV and there was
>> always much rivalry between the two companies...
>>
>> Wollongong got its license because they were the marketing
>> company formed to market Dr. Miller's port to Interdata, and they
>> later branched out significantly because their license was so
>> special... Or at least that's the story they told customers and
>> internally... I never saw the original license to know...
>>
>> Warner
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210119/f491f58e/attachment.htm>
From dave at plonka.us Thu Jan 21 00:05:10 2021
From: dave at plonka.us (Dave Plonka)
Date: Wed, 20 Jan 2021 08:05:10 -0600
Subject: [TUHS] bas(1) and bs(1) videos including features and use
Message-ID: <CANPwAQa9PuWcqTHkx=8stS32xR5tzjXFXkA2qyR4OWQMMFNj2g@mail.gmail.com>
Hi folks,
In case you're interested:
I've published a couple videos on these ancient Unix tools, sharing
including some language details and showing them in action on v7 and
System III, respectively:
Ken Thompson's bas(1): https://youtu.be/LZUMNZTUJos
Dick Haight's bs(1): https://youtu.be/ELICIa3L22o
Thanks much for the help from TUHS, Mashey, Kernighan, McIlroy, and
others cited therein.
Peace,
Dave
--
dave at plonka.us http://www.cs.wisc.edu/~plonka/
From akosela at andykosela.com Thu Jan 21 00:17:59 2021
From: akosela at andykosela.com (Andy Kosela)
Date: Wed, 20 Jan 2021 15:17:59 +0100
Subject: [TUHS] bas(1) and bs(1) videos including features and use
In-Reply-To: <CANPwAQa9PuWcqTHkx=8stS32xR5tzjXFXkA2qyR4OWQMMFNj2g@mail.gmail.com>
References: <CANPwAQa9PuWcqTHkx=8stS32xR5tzjXFXkA2qyR4OWQMMFNj2g@mail.gmail.com>
Message-ID: <CALMnNGiyawn7p+5zv0VJFOOFSLjqUOoJPZRzdAdgn7BmwJTjkg@mail.gmail.com>
On Wednesday, January 20, 2021, Dave Plonka <dave at plonka.us> wrote:
>
> Hi folks,
>
> In case you're interested:
>
> I've published a couple videos on these ancient Unix tools, sharing
> including some language details and showing them in action on v7 and
> System III, respectively:
>
> Ken Thompson's bas(1): https://youtu.be/LZUMNZTUJos
>
> Dick Haight's bs(1): https://youtu.be/ELICIa3L22o
>
> Thanks much for the help from TUHS, Mashey, Kernighan, McIlroy, and
> others cited therein.
Great content! I love YouTube channels about retrocomputing. You've
just earned a new subscriber.
Thanks!
--Andy
From m.douglas.mcilroy at dartmouth.edu Thu Jan 21 02:56:41 2021
From: m.douglas.mcilroy at dartmouth.edu (M Douglas McIlroy)
Date: Wed, 20 Jan 2021 11:56:41 -0500
Subject: [TUHS] bas(1) and bs(1) videos including features and use
Message-ID: <CAKH6PiX6aQ1cDOteK-An81NrMfVbJCQZ=5bOr2CUoTvQ_mKRTA@mail.gmail.com>
Nice archaeology. Blinded by my distaste for Basic , I never bothered to
try bs--and should have. Dave has highlighted features that deserve respect.
One telling example suggests this should be legalized in C:
printf("%s\n", {"true", "false"}[1]);
Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210120/7653d62d/attachment.htm>
From dave at horsfall.org Thu Jan 21 08:17:30 2021
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 21 Jan 2021 09:17:30 +1100 (EST)
Subject: [TUHS] bas(1) and bs(1) videos including features and use
In-Reply-To: <CAKH6PiX6aQ1cDOteK-An81NrMfVbJCQZ=5bOr2CUoTvQ_mKRTA@mail.gmail.com>
References: <CAKH6PiX6aQ1cDOteK-An81NrMfVbJCQZ=5bOr2CUoTvQ_mKRTA@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.2101210915320.95135@aneurin.horsfall.org>
On Wed, 20 Jan 2021, M Douglas McIlroy wrote:
> Nice archaeology. Blinded by my distaste for Basic , I never bothered to try
> bs--and should have. Dave has highlighted features that deserve respect.One
> telling example suggests this should be legalized in C:
> Â Â Â Â printf("%s\n", {"true", "false"}[1]);
That would evaluate to a constant being printed (it's a direct array
reference). Did you mean something like "...[i]" instead? That would
indeed be neat...
-- Dave
From hellwig.geisse at mni.thm.de Thu Jan 21 09:11:28 2021
From: hellwig.geisse at mni.thm.de (Hellwig Geisse)
Date: Thu, 21 Jan 2021 00:11:28 +0100
Subject: [TUHS] bas(1) and bs(1) videos including features and use
In-Reply-To: <alpine.BSF.2.21.9999.2101210915320.95135@aneurin.horsfall.org>
References: <CAKH6PiX6aQ1cDOteK-An81NrMfVbJCQZ=5bOr2CUoTvQ_mKRTA@mail.gmail.com>
<alpine.BSF.2.21.9999.2101210915320.95135@aneurin.horsfall.org>
Message-ID: <1611184288.26419.9.camel@mni.thm.de>
On Do, 2021-01-21 at 09:17 +1100, Dave Horsfall wrote:
> Â Â Â Â printf("%s\n", {"true", "false"}[1]);
> That would evaluate to a constant being printed (it's a direct arrayÂ
> reference).  Did you mean something like "...[i]" instead?  That wouldÂ
> indeed be neat...
>
I think it doesn't matter if the index expression is
a constant expression or not. The point here, as I
understood, is the definition of an unnamed (and not
explicitly typed) array "on the fly".
Hellwig
From smallick.dev at gmail.com Thu Jan 21 17:30:21 2021
From: smallick.dev at gmail.com (Sudipto Mallick)
Date: Thu, 21 Jan 2021 13:00:21 +0530
Subject: [TUHS] bas(1) and bs(1) videos including features and use
In-Reply-To: <1611184288.26419.9.camel@mni.thm.de>
References: <CAKH6PiX6aQ1cDOteK-An81NrMfVbJCQZ=5bOr2CUoTvQ_mKRTA@mail.gmail.com>
<alpine.BSF.2.21.9999.2101210915320.95135@aneurin.horsfall.org>
<1611184288.26419.9.camel@mni.thm.de>
Message-ID: <CAFaUHvLWu6k0cHrva0viav0=O0df=pUeAO_e2fHAbnnsSKvXfA@mail.gmail.com>
Then what about the following? :D
union huh { uint64_t l; double d; };
uint64_t a = ((union huh){ .d = foo }).l;
--Sudipto Mallick
From dave at horsfall.org Sun Jan 24 07:46:39 2021
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 24 Jan 2021 08:46:39 +1100 (EST)
Subject: [TUHS] Three-quarters to the next Epoch
Message-ID: <alpine.BSF.2.21.9999.2101240837350.36435@aneurin.horsfall.org>
Sent to me from a fellow weirdo...
At 19:25:36 AEDT (00:25:36 UTC), Unix time reached 0x60000000. We're
three quarters of the way to 2038...
Stock up on food, load dem guns, and batten down the hatches :-)
-- Dave
From will.senn at gmail.com Sun Jan 24 11:28:01 2021
From: will.senn at gmail.com (Will Senn)
Date: Sat, 23 Jan 2021 19:28:01 -0600
Subject: [TUHS] The terminal, the console, and the shell - what are they?
Message-ID: <b5007092-a0a7-7358-9e35-6df84742367a@gmail.com>
All,
I came across this note on vermaden's valuable news blog and thought
y'all might enjoy it - it's not pure unix, but it's got a lot of
crossover. The history is interesting and to us relative newbs,
informative. I can't confirm its accuracy on the history side of things,
but I'm sure you can :).
http://unixsheikh.com/articles/the-terminal-the-console-and-the-shell-what-are-they.html
Later,
Will
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210123/488012c3/attachment.htm>
From jfoust at threedee.com Sun Jan 24 13:57:37 2021
From: jfoust at threedee.com (John Foust)
Date: Sat, 23 Jan 2021 21:57:37 -0600
Subject: [TUHS] Three-quarters to the next Epoch
In-Reply-To: <alpine.BSF.2.21.9999.2101240837350.36435@aneurin.horsfall. org>
References: <alpine.BSF.2.21.9999.2101240837350.36435@aneurin.horsfall.org>
Message-ID: <20210124045233.335C79C669@minnie.tuhs.org>
At 03:46 PM 1/23/2021, Dave Horsfall wrote:
>Sent to me from a fellow weirdo...
>
>At 19:25:36 AEDT (00:25:36 UTC), Unix time reached 0x60000000. We're three quarters of the way to 2038...
That was January 14, 2021, right?
https://www.epochconverter.com/hex
- John
From ality at pbrane.org Sun Jan 24 15:44:46 2021
From: ality at pbrane.org (Anthony Martin)
Date: Sat, 23 Jan 2021 21:44:46 -0800
Subject: [TUHS] Three-quarters to the next Epoch
In-Reply-To: <20210124045233.335C79C669@minnie.tuhs.org>
References: <alpine.BSF.2.21.9999.2101240837350.36435@aneurin.horsfall.org>
<20210124045233.335C79C669@minnie.tuhs.org>
Message-ID: <YA0JThfLwsOetEie@alice>
John Foust <jfoust at threedee.com> once said:
> That was January 14, 2021, right?
>
> https://www.epochconverter.com/hex
% for(i in `{seq 0 2 8}) date -u 0x$i^0000000
Thu Jan 1 00:00:00 GMT 1970
Mon Jan 5 18:48:32 GMT 1987
Sat Jan 10 13:37:04 GMT 2004
Thu Jan 14 08:25:36 GMT 2021
Tue Jan 19 03:14:08 GMT 2038
%
Cheers,
Anthony
From michael at kjorling.se Sun Jan 24 21:28:05 2021
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Sun, 24 Jan 2021 11:28:05 +0000
Subject: [TUHS] Three-quarters to the next Epoch
In-Reply-To: <YA0JThfLwsOetEie@alice>
References: <alpine.BSF.2.21.9999.2101240837350.36435@aneurin.horsfall.org>
<20210124045233.335C79C669@minnie.tuhs.org>
<YA0JThfLwsOetEie@alice>
Message-ID: <76f0ffc9-a5d7-471c-9bac-84d5427892b3@localhost>
On 23 Jan 2021 21:44 -0800, from ality at pbrane.org (Anthony Martin):
>> That was January 14, 2021, right?
>
> % for(i in `{seq 0 2 8}) date -u 0x$i^0000000
> Thu Jan 1 00:00:00 GMT 1970
> Mon Jan 5 18:48:32 GMT 1987
> Sat Jan 10 13:37:04 GMT 2004
> Thu Jan 14 08:25:36 GMT 2021
> Tue Jan 19 03:14:08 GMT 2038
> %
GNU date would appear to agree:
$ date --utc --date=@$(printf '%d' 0x60000000)
Thu 14 Jan 2021 08:25:36 UTC
$
(At least the version I've got handy doesn't seem to like a hex
seconds-since-epoch timestamp, so a separate conversion to decimal is
required in that case.)
--
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?â€
From usotsuki at buric.co Sun Jan 24 22:21:14 2021
From: usotsuki at buric.co (Steve Nickolas)
Date: Sun, 24 Jan 2021 07:21:14 -0500 (EST)
Subject: [TUHS] Three-quarters to the next Epoch
In-Reply-To: <76f0ffc9-a5d7-471c-9bac-84d5427892b3@localhost>
References: <alpine.BSF.2.21.9999.2101240837350.36435@aneurin.horsfall.org>
<20210124045233.335C79C669@minnie.tuhs.org> <YA0JThfLwsOetEie@alice>
<76f0ffc9-a5d7-471c-9bac-84d5427892b3@localhost>
Message-ID: <alpine.DEB.2.21.2101240717260.28627@sd-119843.dedibox.fr>
On Sun, 24 Jan 2021, Michael Kjörling wrote:
> On 23 Jan 2021 21:44 -0800, from ality at pbrane.org (Anthony Martin):
>>> That was January 14, 2021, right?
>>
>> % for(i in `{seq 0 2 8}) date -u 0x$i^0000000
>> Thu Jan 1 00:00:00 GMT 1970
>> Mon Jan 5 18:48:32 GMT 1987
>> Sat Jan 10 13:37:04 GMT 2004
>> Thu Jan 14 08:25:36 GMT 2021
>> Tue Jan 19 03:14:08 GMT 2038
>> %
>
> GNU date would appear to agree:
>
> $ date --utc --date=@$(printf '%d' 0x60000000)
> Thu 14 Jan 2021 08:25:36 UTC
> $
>
> (At least the version I've got handy doesn't seem to like a hex
> seconds-since-epoch timestamp, so a separate conversion to decimal is
> required in that case.)
I have a non-GNU one (as part of an unfinished *x I was developing) that
also doesn't like that, so it required this:
$ date -ur $(echo "ibase=16;60000000" | bc)
Thu Jan 14 08:25:36 UTC 2021
Says it was pulled from a 2019 commit to OpenBSD.
-uso.
From rminnich at gmail.com Mon Jan 25 02:14:51 2021
From: rminnich at gmail.com (ron minnich)
Date: Sun, 24 Jan 2021 08:14:51 -0800
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
Message-ID: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
At some point I thought NeWS source was released. Is it just another
Lost Source or it is out there somewhere?
Do I remember right that it was a Gosling effort?
From tih at hamartun.priv.no Mon Jan 25 02:07:33 2021
From: tih at hamartun.priv.no (Tom Ivar Helbekkmo)
Date: Sun, 24 Jan 2021 17:07:33 +0100
Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
In-Reply-To: <20200919152835.4E73A18C0DD@mercury.lcs.mit.edu> (Noel Chiappa's
message of "Sat, 19 Sep 2020 11:28:35 -0400 (EDT)")
References: <20200919152835.4E73A18C0DD@mercury.lcs.mit.edu>
Message-ID: <m2lfcie2t6.fsf@thuvia.hamartun.priv.no>
Noel Chiappa <jnc at mercury.lcs.mit.edu> writes:
> V6 can be run on an -11/23 (I've done it), but not straight out of the box;
> it requires a few minor tweaks first:
>
> http://gunkies.org/wiki/Running_UNIX_V6_on_an_-11/23
Noel,
here's a huge THANK YOU! from me - I've had a couple of uPDP-11/23+
systems stowed away for over twenty years, with an eye to one day
porting V6 to them, and this comment from you finally made me pull out
one of them and do it. I now have V6 running on the physical hardware,
booting from an RD52 on an RQDX3 MSCP controller, and announcing 488KW
of available RAM at boot.
Here's the write-up: https://www.hamartun.priv.no/v6unix.html
I am *so* looking forward to continuing work on this system (it's just
barely running, since a couple of days ago), and your web page about
improving V6 will certainly be my launch pad for the next rounds.
-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 michael at kjorling.se Mon Jan 25 02:24:15 2021
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Sun, 24 Jan 2021 16:24:15 +0000
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
Message-ID: <10f7fb27-c192-45da-8522-9ca34129490b@localhost>
On 24 Jan 2021 08:14 -0800, from rminnich at gmail.com (ron minnich):
> At some point I thought NeWS source was released. Is it just another
> Lost Source or it is out there somewhere?
If it turns up, consider updating the Wikipedia article; all it seems
to say about general source code access is that "Sun charged a fee to
license the NeWS source code, while the MIT X11 code was free of
cost".
https://en.wikipedia.org/wiki/NeWS
--
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?â€
From clemc at ccc.com Mon Jan 25 03:04:09 2021
From: clemc at ccc.com (Clem Cole)
Date: Sun, 24 Jan 2021 12:04:09 -0500
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
Message-ID: <CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
On Sun, Jan 24, 2021 at 11:15 AM ron minnich <rminnich at gmail.com> wrote:
> At some point I thought NeWS source was released. Is it just another
> Lost Source or it is out there somewhere?
>
As I have said in other replies: "simple economics always beats
sophisticated architecture."
I personally never saw the code, although I did play with the result at one
point. I believe they licensed Adobe Display PostScript which was one of
the issues. IIRC was also a trigger for creating Ghostscript. We toyed
with using it for Stellar. IIRC, Andy Van Dam was a big fan.
> Do I remember right that it was a Gosling effort?
>
Yep.
Like BLISS vs. C - NeWS did way more than X11 did when it first appeared
and it might have had a chance if Sun had not locked it up the same way DEC
did with BLISS. Funny, they gave away NFS and basically set a standard
that they controlled. I have to believe they made way more money selling
systems because NFS was ubiquitous than they would have with license
revenue for NFS.
I suspect NeWS was justified internally differently and the marketing types
saw it as a revenue stream. Larry, can you enlighten us at all?
á§
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210124/26f089ce/attachment.htm>
From crossd at gmail.com Mon Jan 25 04:24:48 2021
From: crossd at gmail.com (Dan Cross)
Date: Sun, 24 Jan 2021 13:24:48 -0500
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
Message-ID: <CAEoi9W6fMQ=Jw+Y2TKctH4Yn9uLLm3mq27oamKr8diurR-TgRw@mail.gmail.com>
On Sun, Jan 24, 2021 at 11:16 AM ron minnich <rminnich at gmail.com> wrote:
> At some point I thought NeWS source was released. Is it just another
> Lost Source or it is out there somewhere?
>
I think they open sourced the OpenLook toolkit at some point, though I
don't recall seeing the source code for the NeWS server itself. If I'm
misremembering and Sun didn't open the OLTK, then maybe there was an open
source clone. I am sure there was an alternate window manager that had
virtual desktops.
Starting with, I believe, NeWS 3.0 and later they provided X11 integration.
X had clearly won in the larger world. For that matter, so had Motif, but
you had to pay money for it.
Do I remember right that it was a Gosling effort?
>
Yes, he was the driving force behind NeWS. Display PostScript! A cool
concept.
- Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210124/418ab82c/attachment.htm>
From lm at mcvoy.com Mon Jan 25 04:36:53 2021
From: lm at mcvoy.com (Larry McVoy)
Date: Sun, 24 Jan 2021 10:36:53 -0800
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
Message-ID: <20210124183653.GD21030@mcvoy.com>
On Sun, Jan 24, 2021 at 12:04:09PM -0500, Clem Cole wrote:
> I suspect NeWS was justified internally differently and the marketing types
> saw it as a revenue stream. Larry, can you enlighten us at all?
NeWS was too much, too soon. This was back in the days of Mhz rather than
Ghz and NeWS was slow and clunky whereas X11 was good enough.
I don't know what the deal was with locking it up. I don't even know if
they got any revenue out of it, the only people that I remember liking
it were sort of "zealots" for lack of a better word. They felt like it
was better answer and just had mumble, mumble when performance was
brought up.
But I'm a weird person to ask because I started my career as a contractor
at Lachman and the first thing I did on any project was bring up X10,
later X11, and use that. I'm still carrying around my startx stuff.
To me, having the same UI on every platform dramatically out weighed
any "advantage" $VENDORS window system had. And in reality, if you had
decent frame buffer drivers, X11 was usually faster than the VENDOR stuff.
So I have little insight into VENDOR UI, I rarely used it for longer than
it took me to build X11.
The only UI stuff I've ever seen that I liked better that X11 was:
Sunview (the X version) because of the clever UI, every interface was
widget(key, value, key, value) and all keys (if I remember correctly)
had defaults that were reasonable. Super pleasant.
Ousterhout's Tk (but not the tcl stuff, jesus that was horrible).
He approached GUIs from a much higher level and you can throw together
working tools in very few lines of code. I've still never seen anything
as well thought out though I haven't looked in the last ~5 years.
It wouldn't surprise me at all if his stuff is still the best.
From toby at telegraphics.com.au Mon Jan 25 04:41:51 2021
From: toby at telegraphics.com.au (Toby Thain)
Date: Sun, 24 Jan 2021 13:41:51 -0500
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
Message-ID: <41336697-be92-8796-04d7-9b9b89bee180@telegraphics.com.au>
On 2021-01-24 12:04 p.m., Clem Cole wrote:
>
>
> On Sun, Jan 24, 2021 at 11:15 AM ron minnich <rminnich at gmail.com
> <mailto:rminnich at gmail.com>> wrote:
>
> At some point I thought NeWS source was released. Is it just another
> Lost Source or it is out there somewhere?
>
>
> As I have said in other replies: "simple economics always beats
> sophisticated architecture."
>
> I personally never saw the code, although I did play with the result at
> one point. I believe they licensed Adobe Display PostScript which was
As far as I know, they didn't. It was a different implementation.
They did develop the F3 font rasterising engine as part of the project,
iirc.
--Toby
> one of the issues. IIRC was also a trigger for creating Ghostscript. Â
> We toyed with using it for Stellar.  IIRC, Andy Van Dam was a big fan.
>
> ...
From arnold at skeeve.com Mon Jan 25 04:42:53 2021
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sun, 24 Jan 2021 11:42:53 -0700
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <CAEoi9W6fMQ=Jw+Y2TKctH4Yn9uLLm3mq27oamKr8diurR-TgRw@mail.gmail.com>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAEoi9W6fMQ=Jw+Y2TKctH4Yn9uLLm3mq27oamKr8diurR-TgRw@mail.gmail.com>
Message-ID: <202101241842.10OIgrhP008354@freefriends.org>
Dan Cross <crossd at gmail.com> wrote:
> On Sun, Jan 24, 2021 at 11:16 AM ron minnich <rminnich at gmail.com> wrote:
>
> > At some point I thought NeWS source was released. Is it just another
> > Lost Source or it is out there somewhere?
> >
>
> I think they open sourced the OpenLook toolkit at some point,
Indeed they did. I think I have a CD with it somewhere in my
basement.... I am pretty sure it was the X11 version, not
sunview.
I don't think NeWS ever got released.
Arnold
From lm at mcvoy.com Mon Jan 25 05:11:34 2021
From: lm at mcvoy.com (Larry McVoy)
Date: Sun, 24 Jan 2021 11:11:34 -0800
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <202101241842.10OIgrhP008354@freefriends.org>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAEoi9W6fMQ=Jw+Y2TKctH4Yn9uLLm3mq27oamKr8diurR-TgRw@mail.gmail.com>
<202101241842.10OIgrhP008354@freefriends.org>
Message-ID: <20210124191134.GF21030@mcvoy.com>
On Sun, Jan 24, 2021 at 11:42:53AM -0700, arnold at skeeve.com wrote:
> > On Sun, Jan 24, 2021 at 11:16 AM ron minnich <rminnich at gmail.com> wrote:
> > I think they open sourced the OpenLook toolkit at some point,
>
> Indeed they did. I think I have a CD with it somewhere in my
> basement.... I am pretty sure it was the X11 version, not
> sunview.
As much as I loved Sun, I never got happy with Openlook, I just ctwm on
X11 and I was happy. I liked the Sunview toolkit though, that was better
than average.
From ron at ronnatalie.com Mon Jan 25 06:39:13 2021
From: ron at ronnatalie.com (Ronald Natalie)
Date: Sun, 24 Jan 2021 20:39:13 +0000
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <20210124183653.GD21030@mcvoy.com>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
Message-ID: <em6c238722-2515-4ad4-839e-0010ff1f9f9a@alien>
NeWS had a number of problems. Oddly, James Gosling who designed NeWS
(along with Owen Dunsmore who made the PostScript class mechanism) went
on to do Java which got around the simple fact that as far as a
programming language for human programmers, PostScript is absolutely
abysmal. It also suffered from other goofy mistakes like the
"terminal" window when resized just made the 24x80 bigger by scaling up
the fonts (most people expect to keep the font size but get more rows
and columns).
Don Hopkins (is he here?) had done his pi menus (round menus) which were
a pretty neat concept that never caught on elswehere on NeWS.
From lm at mcvoy.com Mon Jan 25 06:54:51 2021
From: lm at mcvoy.com (Larry McVoy)
Date: Sun, 24 Jan 2021 12:54:51 -0800
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <em6c238722-2515-4ad4-839e-0010ff1f9f9a@alien>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
<em6c238722-2515-4ad4-839e-0010ff1f9f9a@alien>
Message-ID: <20210124205451.GH21030@mcvoy.com>
On Sun, Jan 24, 2021 at 08:39:13PM +0000, Ronald Natalie wrote:
> to do Java which got around the simple fact that as far as a programming
> language for human programmers, PostScript is absolutely abysmal.
Abysmal? Perhaps a bit harsh. The Sun logo was hand written
postscript and I did the first SPARC Cluster and made a logo that was
4 interconnected Sun logos in the same shape, I can probably dig it up.
I think it was more weird, reminded me of Forth (also weird). But you
could make stuff work in it.
From jon at fourwinds.com Mon Jan 25 06:45:13 2021
From: jon at fourwinds.com (Jon Steinhart)
Date: Sun, 24 Jan 2021 12:45:13 -0800
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <20210124183653.GD21030@mcvoy.com>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
Message-ID: <202101242045.10OKjDvA964774@darkstar.fourwinds.com>
Larry McVoy writes:
> On Sun, Jan 24, 2021 at 12:04:09PM -0500, Clem Cole wrote:
> > I suspect NeWS was justified internally differently and the marketing types
> > saw it as a revenue stream. Larry, can you enlighten us at all?
>
> NeWS was too much, too soon. This was back in the days of Mhz rather than
> Ghz and NeWS was slow and clunky whereas X11 was good enough.
>
> I don't know what the deal was with locking it up. I don't even know if
> they got any revenue out of it, the only people that I remember liking
> it were sort of "zealots" for lack of a better word. They felt like it
> was better answer and just had mumble, mumble when performance was
> brought up.
>
> But I'm a weird person to ask because I started my career as a contractor
> at Lachman and the first thing I did on any project was bring up X10,
> later X11, and use that. I'm still carrying around my startx stuff.
> To me, having the same UI on every platform dramatically out weighed
> any "advantage" $VENDORS window system had. And in reality, if you had
> decent frame buffer drivers, X11 was usually faster than the VENDOR stuff.
>
> So I have little insight into VENDOR UI, I rarely used it for longer than
> it took me to build X11.
>
> The only UI stuff I've ever seen that I liked better that X11 was:
>
> Sunview (the X version) because of the clever UI, every interface was
> widget(key, value, key, value) and all keys (if I remember correctly)
> had defaults that were reasonable. Super pleasant.
>
> Ousterhout's Tk (but not the tcl stuff, jesus that was horrible).
> He approached GUIs from a much higher level and you can throw together
> working tools in very few lines of code. I've still never seen anything
> as well thought out though I haven't looked in the last ~5 years.
> It wouldn't surprise me at all if his stuff is still the best.
Ugh, another flashback. Reload the brain from back-up tapes time.
Yes, NeWS was primarily Gosling but Rosenthal was also a contributor.
Remember that they did Andrew at CMU. Historical note on them versus the
X-Men is that when they did Andrew, one of the first things that they
addressed was that UNIX was asynchronous networking; they designed the
protocol to avoid round-trips. Even though their work pre-dated a lot of
the X work, X through V10 was stuck on the synchronous networking model
since X was really just the W code developed for the V operating system.
SunWindows/SunView was Sun's original window system that was kernel-based.
There were a bazillion ioctls to get things done. But, it was fast
and reliable. Ugly inside.
A quick note is that the X-Men sold their stuff as "network-transparent"
which I thought was really idiotic. Before X, lots of people did network
transparent graphics with Tektronix 4014 terminal emulators. The main
thing that X did for you was to have your whole UI run on a remote
machine making the performance even worse than what the synchronous
protocol provided.
To the best of my knowledge, NeWS was the first window system to provide
device-independent graphics. You could just do things without having
to mess around with counting pixels and figuring out what sort of color
system was behind things.
As an aside, I found something when doing my basement archeology that
pre-dated the X11/NeWS tee shirts; there was a color printer at Sun and I
got Dave Lavalle to help me make a Christmas card for Gosling - it read
"Wish you a merry X-Mess and a happy NeWS year". Could scan it in if
anyone cares.
To me, the biggest problem with NeWS was the "e" part; it was so extensible
that nobody could stop playing around and finish something. I recall
that they kept on redoing UI toolkits because they got into building an
object-oriented system using PostScript dictionaries and kept changing
things because they were learning as they went. The name Owen Densmore
is connected to this in my mind.
While there are many different views of what happened, mine is that the
X-Men colluded to form the "Hamilton Group" in an attempt to used monopoly
power to kill NeWS. One of the leaders of this was Apollo, and according
to folks that I knew there, they felt that their networking was better
than Sun's, but they lost because Sun "gave away" NFS. Folks were worried
that Sun would do something similar with NeWS, and at the time there was
little industry expertise, especially in the graphics department. I seem
to recall that Sun bought some company that had figured out font-hinting
along the line.
Moving on, because of the Hamilton Group, Sun was forced into supporting X.
They created X/NeWS on the assumption that X would just be a layer on
top of NeWS and use much of the same code. Robin Schaufler was project
lead. Problem was, the X graphics model of knowing exactly where each
pixel was placed was not compatible with the NeWS model of not caring.
Partly in reaction to this, the X-Men worked with Adobe on the Display
PostScript extension. My recollection was that the original PostScript
for Apple printers was pretty much written in assembler, and so it took
a lot of work and time to get Display PostScript up and running. It was
not a great fit for X as compared to NeWS as X with Display PostScript
provided a different drawing model as a wart that wasn't well integrated
with the rest of X. Display PostScript got a temporarily new lease on
life with Next.
XView was a project at Sun that converted SunView programs into X programs.
I remember doing a late night panic consulting project because it came
along around the same time as SPARC, and there was a lot of weird code
in there doing unaligned memory accesses that needed fixing.
In my opinion, the whole NeWS and X/NeWS thing failed because it was done
in a market-insensitive manner. Among other things, I was doing some
consulting for AED at the time; they were making X accelerator boards
that plugged into Suns. I convinced them that there wasn't going to be
much of a market. Instead, I noticed that many large companies were using
SunView applications (think FrameMaker et. al.) for serious work, and were
not just going to ditch it for X just so they could watch the maze program
(there were no real X applications at the time). AED funded me to do the
XTool (Safe X for Suns) project which made X run in a SunView window.
That allowed customers who depended on SunView to also watch maze
when they were bored. It had two modes; run an X server in a window,
or use the Sun UI and run each X application in its own SunView window.
Unfortunately, AED had a management change who forced us to ship before
we were ready which made it fail. Were I smarter I would have tried to
get Sun to buy it. I think that I have a box of XTool tee shirts around
if anybody wants one.
I don't know if the NeWS source was ever released. I have a QIC-150 tape
labeled NeWS which I believe has the source. Have no idea what version
or anything else, and I would have to haul my old SparcStation 20 out of
the basement to try reading it as I don't have SCSI on any modern machine.
John Gilmore might have a copy as I recall that he and Hugh Daniel were
doing some sort of NeWS thing, Grasshopper Group if I remember right.
Jon
From ron at ronnatalie.com Mon Jan 25 07:01:30 2021
From: ron at ronnatalie.com (Ronald Natalie)
Date: Sun, 24 Jan 2021 21:01:30 +0000
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <20210124205451.GH21030@mcvoy.com>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
<em6c238722-2515-4ad4-839e-0010ff1f9f9a@alien>
<20210124205451.GH21030@mcvoy.com>
Message-ID: <em841a1dde-01ed-47ed-ad21-4dd211f81d6a@alien>
Writing simple renderings isn't too bad. Trying to implement program
logic in it is horrid. Believe me, I spent years dealing with a system
that was sort of a NeWS spin-off. Shoot me before I ever have to use
a language without local variables again.
------ Original Message ------
From: "Larry McVoy" <lm at mcvoy.com>
To: "Ronald Natalie" <ron at ronnatalie.com>
Cc: "Larry McVoy" <lm at mcvoy.com>; "Clem Cole" <clemc at ccc.com>; "TUHS
main list" <tuhs at minnie.tuhs.org>
Sent: 1/24/2021 3:54:51 PM
Subject: Re: Re[2]: [TUHS] tangential unix question: whatever happened
to NeWS?
>On Sun, Jan 24, 2021 at 08:39:13PM +0000, Ronald Natalie wrote:
>> to do Java which got around the simple fact that as far as a programming
>> language for human programmers, PostScript is absolutely abysmal.
>
>Abysmal? Perhaps a bit harsh. The Sun logo was hand written
>postscript and I did the first SPARC Cluster and made a logo that was
>4 interconnected Sun logos in the same shape, I can probably dig it up.
>
>I think it was more weird, reminded me of Forth (also weird). But you
>could make stuff work in it.
From rdm at cfcl.com Mon Jan 25 07:07:27 2021
From: rdm at cfcl.com (Rich Morin)
Date: Sun, 24 Jan 2021 13:07:27 -0800
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
Message-ID: <A53D7EA5-614C-454F-AB59-107DAAACE1BF@cfcl.com>
John Gilmore probably has some interesting stories to tell regarding NeWS; his Grasshopper Group project ported it to A/UX on the Mac. Don Hopkins and Hugh Daniel (https://en.wikipedia.org/wiki/Hugh_Daniel) did the heavy lifting, IIRC.
I recall hearing that Gosling had to use GCC to compile NeWS. It seems that the code had an enormous switch statement which spanned more than 64 KB. The Sun C compiler used SPARC's location-independent conditional branches, which couldn't reach that far; GCC used a combination of branches and jumps, so it had no problem.
Aside from the use of PostScript and the enormous (for the time) resource demands, NeWS also suffered from economic and political issues. It wasn't free (in any sense), so other vendors would have had to pay a substantial amount of money to use it. Also, some other vendors were reportedly unwilling to give Sun yet another standards victory.
Too bad. X won (at least in Unixish systems) and, as Rob Pike put it: Sometimes when you fill a vacuum, it still sucks. Curiously, JavaScript (another Gosling effort) is in some ways the modern version of NeWS...
-r
From ron at ronnatalie.com Mon Jan 25 07:10:19 2021
From: ron at ronnatalie.com (Ronald Natalie)
Date: Sun, 24 Jan 2021 21:10:19 +0000
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <A53D7EA5-614C-454F-AB59-107DAAACE1BF@cfcl.com>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<A53D7EA5-614C-454F-AB59-107DAAACE1BF@cfcl.com>
Message-ID: <em04b0f343-6d42-413e-a676-568f770fbc0d@alien>
>Too bad. X won (at least in Unixish systems) and, as Rob Pike put it: Sometimes when you fill a vacuum, it still sucks. Curiously, JavaScript (another Gosling effort) is in some ways the modern version of NeWS...
>
>
You mean Java. JavaScript is a different language that Brendan Eich at
Netscape wrote for their browser.
>
From lm at mcvoy.com Mon Jan 25 07:11:00 2021
From: lm at mcvoy.com (Larry McVoy)
Date: Sun, 24 Jan 2021 13:11:00 -0800
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <202101242045.10OKjDvA964774@darkstar.fourwinds.com>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
<202101242045.10OKjDvA964774@darkstar.fourwinds.com>
Message-ID: <20210124211100.GI21030@mcvoy.com>
On Sun, Jan 24, 2021 at 12:45:13PM -0800, Jon Steinhart wrote:
> power to kill NeWS. One of the leaders of this was Apollo, and according
> to folks that I knew there, they felt that their networking was better
> than Sun's, but they lost because Sun "gave away" NFS.
Small hijack because I couldn't help it :)
As someone who has used Apollos side by side with Suns (this was before
I went to work at Sun, around 1987), to say Apollos were better at
anything than a Sun was a joke in bad taste. If I remember correctly,
they were both based on 68020s, so same baseline. Apollos just sucked,
their networked file system was slow as molasses. In spite of having
dozens of Apollos available to me, and just one Sun file server, the first
thing I did at that job was to port the cross compiler from Apollo to Sun,
that one machine was faster than anything I could get done on a pile of
Apollos. I hated them.
--lm
From jon at fourwinds.com Mon Jan 25 07:14:34 2021
From: jon at fourwinds.com (Jon Steinhart)
Date: Sun, 24 Jan 2021 13:14:34 -0800
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <20210124211100.GI21030@mcvoy.com>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
<202101242045.10OKjDvA964774@darkstar.fourwinds.com>
<20210124211100.GI21030@mcvoy.com>
Message-ID: <202101242114.10OLEYGk966708@darkstar.fourwinds.com>
Larry McVoy writes:
> On Sun, Jan 24, 2021 at 12:45:13PM -0800, Jon Steinhart wrote:
> > power to kill NeWS. One of the leaders of this was Apollo, and according
> > to folks that I knew there, they felt that their networking was better
> > than Sun's, but they lost because Sun "gave away" NFS.
>
> Small hijack because I couldn't help it :)
>
> As someone who has used Apollos side by side with Suns (this was before
> I went to work at Sun, around 1987), to say Apollos were better at
> anything than a Sun was a joke in bad taste. If I remember correctly,
> they were both based on 68020s, so same baseline. Apollos just sucked,
> their networked file system was slow as molasses. In spite of having
> dozens of Apollos available to me, and just one Sun file server, the first
> thing I did at that job was to port the cross compiler from Apollo to Sun,
> that one machine was faster than anything I could get done on a pile of
> Apollos. I hated them.
>
> --lm
So I never liked Apollos much. What I was referring to was Apollo's claim
that their token-ring network performed better for large numbers of nodes.
And they were correct. However, they didn't consider the eventually
invention of switches that solved the problem.
Jon
From jon at fourwinds.com Mon Jan 25 07:16:29 2021
From: jon at fourwinds.com (Jon Steinhart)
Date: Sun, 24 Jan 2021 13:16:29 -0800
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <A53D7EA5-614C-454F-AB59-107DAAACE1BF@cfcl.com>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<A53D7EA5-614C-454F-AB59-107DAAACE1BF@cfcl.com>
Message-ID: <202101242116.10OLGTtE966812@darkstar.fourwinds.com>
Rich Morin writes:
> John Gilmore probably has some interesting stories to tell regarding NeWS;
> his Grasshopper Group project ported it to A/UX on the Mac. Don Hopkins
> and Hugh Daniel (https://en.wikipedia.org/wiki/Hugh_Daniel) did the heavy
> lifting, IIRC.
One of my favorite Don Hopkins quotes was something he said when we were
wandering the floor at XHibition '90. Something like "Wow! with the
power of X and Motif I can use a modern processor to get all of the
performance that I used to get on an Intel 8080."
From ron at ronnatalie.com Mon Jan 25 07:22:16 2021
From: ron at ronnatalie.com (Ronald Natalie)
Date: Sun, 24 Jan 2021 21:22:16 +0000
Subject: [TUHS] Apollo (was NeWS)
In-Reply-To: <202101242114.10OLEYGk966708@darkstar.fourwinds.com>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
<202101242045.10OKjDvA964774@darkstar.fourwinds.com>
<20210124211100.GI21030@mcvoy.com>
<202101242114.10OLEYGk966708@darkstar.fourwinds.com>
Message-ID: <emd493e97b-9b57-4c4c-95c9-bf4e9d1a3e58@alien>
>So I never liked Apollos much. What I was referring to was Apollo's claim
>that their token-ring network performed better for large numbers of nodes.
>And they were correct. However, they didn't consider the eventually
>invention of switches that solved the problem.
>
>
We worked with Apollo for a few years before they got absorbed into HP.
I had a DN10000 wthat we used to use. Amusingly, the window system
was some X variant with the Apollo's idea of a GUI wrapped around it.
When I fired up the Motif Window Manager I found that the three little
windows at the bottom of the screen got their own Motif border.
The DN10000 came with a great set of documentation in five volumes to
describe all aspects of the hardware. I really needed volume 3 which
covered the graphics system. After much hunting around (even by some
senior Apollo engineers) everybody came to the conclusion that Volume 3
never got written. The other cute thing is that when you opened the
latchless gull wing doors on the thing it powered off. I had to tape
signs on the thing warning people not to open the thing casually.
A few years after HP shutdown the whole Apollo domain thing, I was
visiting an FAA facility and they showed me this "brand new system they
just got in." It was essentially the system that eventually powered
things like flightaware.com. It was running on the new obsolete DN300.
The other humerous (to me at least) was when we visited the factory,
they listed my bosses title as "Present" on the agenda. We're not sure
what Steve did, but he was always there.
From lm at mcvoy.com Mon Jan 25 07:25:25 2021
From: lm at mcvoy.com (Larry McVoy)
Date: Sun, 24 Jan 2021 13:25:25 -0800
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <202101242114.10OLEYGk966708@darkstar.fourwinds.com>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
<202101242045.10OKjDvA964774@darkstar.fourwinds.com>
<20210124211100.GI21030@mcvoy.com>
<202101242114.10OLEYGk966708@darkstar.fourwinds.com>
Message-ID: <20210124212525.GJ21030@mcvoy.com>
On Sun, Jan 24, 2021 at 01:14:34PM -0800, Jon Steinhart wrote:
> So I never liked Apollos much. What I was referring to was Apollo's claim
> that their token-ring network performed better for large numbers of nodes.
> And they were correct. However, they didn't consider the eventually
> invention of switches that solved the problem.
The network performance of the cluster of Apollos we had was awful.
I don't know anything about how you set that up, never liked token rings,
maybe it is possible to set it up wrong, I dunno. All I know was network
performance was awful on the Apollos.
It's a statistically valid sampling of one case :-)
From aek at bitsavers.org Mon Jan 25 07:29:59 2021
From: aek at bitsavers.org (Al Kossow)
Date: Sun, 24 Jan 2021 13:29:59 -0800
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <202101242045.10OKjDvA964774@darkstar.fourwinds.com>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
<202101242045.10OKjDvA964774@darkstar.fourwinds.com>
Message-ID: <59188f58-2e53-c300-b42e-4591b0274083@bitsavers.org>
On 1/24/21 12:45 PM, Jon Steinhart wrote:
> Larry McVoy writes:
>>I was doing some
> consulting for AED at the time; they were making X accelerator boards
> that plugged into Suns. I convinced them that there wasn't going to be
> much of a market. Instead, I noticed that many large companies were using
> SunView applications (think FrameMaker et. al.) for serious work, and were
> not just going to ditch it for X just so they could watch the maze program
> (there were no real X applications at the time). AED funded me to do the
> XTool (Safe X for Suns) project which made X run in a SunView window.
> That allowed customers who depended on SunView to also watch maze
> when they were bored. It had two modes; run an X server in a window,
> or use the Sun UI and run each X application in its own SunView window.
> Unfortunately, AED had a management change who forced us to ship before
> we were ready which made it fail. Were I smarter I would have tried to
> get Sun to buy it. I think that I have a box of XTool tee shirts around
> if anybody wants one.
That was my project before I left for Apple.
Two versions, QBus and VME.
Big mistake was trusting AMD's QPDM.
http://bitsavers.org/pdf/aed/colorware_cards/
Do you still have any of the code for it?
From lars at nocrew.org Mon Jan 25 07:53:02 2021
From: lars at nocrew.org (Lars Brinkhoff)
Date: Sun, 24 Jan 2021 21:53:02 +0000
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <202101242045.10OKjDvA964774@darkstar.fourwinds.com> (Jon
Steinhart's message of "Sun, 24 Jan 2021 12:45:13 -0800")
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
<202101242045.10OKjDvA964774@darkstar.fourwinds.com>
Message-ID: <7wft2qypc1.fsf@junk.nocrew.org>
Jon Steinhart wrote:
> Instead, I noticed that many large companies were using SunView
> applications (think FrameMaker et. al.) for serious work, and were not
> just going to ditch it for X just so they could watch the maze program
> (there were no real X applications at the time).
Maybe this? I pulled it out of comp.sources.sun postings.
https://github.com/larsbrinkhoff/sunview-x-mazewar
From rdm at cfcl.com Mon Jan 25 08:30:41 2021
From: rdm at cfcl.com (Rich Morin)
Date: Sun, 24 Jan 2021 14:30:41 -0800
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <em04b0f343-6d42-413e-a676-568f770fbc0d@alien>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<A53D7EA5-614C-454F-AB59-107DAAACE1BF@cfcl.com>
<em04b0f343-6d42-413e-a676-568f770fbc0d@alien>
Message-ID: <DF605614-3B66-430B-9542-908252A69E35@cfcl.com>
Yes and no. I actually had JavaScript (which I _knew_ that Brendan Eich wrote; sigh) in mind. JavaScript, like NeWS, handles a wide range of display and interaction issues. Of course, it sits on top of HTTP, but that's just a detail (:-).
-r
> On Jan 24, 2021, at 13:10, Ronald Natalie <ron at ronnatalie.com> wrote:
>
>> Too bad. X won (at least in Unixish systems) and, as Rob Pike put it: Sometimes when you fill a vacuum, it still sucks. Curiously, JavaScript (another Gosling effort) is in some ways the modern version of NeWS...
>>
>>
> You mean Java. JavaScript is a different language that Brendan Eich at Netscape wrote for their browser.
From crossd at gmail.com Mon Jan 25 08:53:16 2021
From: crossd at gmail.com (Dan Cross)
Date: Sun, 24 Jan 2021 17:53:16 -0500
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <20210124212525.GJ21030@mcvoy.com>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
<202101242045.10OKjDvA964774@darkstar.fourwinds.com>
<20210124211100.GI21030@mcvoy.com>
<202101242114.10OLEYGk966708@darkstar.fourwinds.com>
<20210124212525.GJ21030@mcvoy.com>
Message-ID: <CAEoi9W5=toe-bb+6-zC0odkx4_C4X4FZpK4+ZJTAqCKGOCXP7w@mail.gmail.com>
On Sun, Jan 24, 2021 at 4:25 PM Larry McVoy <lm at mcvoy.com> wrote:
> On Sun, Jan 24, 2021 at 01:14:34PM -0800, Jon Steinhart wrote:
> > So I never liked Apollos much. What I was referring to was Apollo's
> claim
> > that their token-ring network performed better for large numbers of
> nodes.
> > And they were correct. However, they didn't consider the eventually
> > invention of switches that solved the problem.
>
> The network performance of the cluster of Apollos we had was awful.
> I don't know anything about how you set that up, never liked token rings,
> maybe it is possible to set it up wrong, I dunno. All I know was network
> performance was awful on the Apollos.
>
Interestingly, descendents of the Apollo RPC system live on in windows, and
if I recall correctly, got there via the DCE/RPC library, largely
contributed by Apollo. Some good judges have said that, on technical
merits, the RPC layer was superior to ONC RPC, though I never used an
Apollo machine to really know.
I remember working at a startup in late 1999/early 2000 that had built some
hokey network daemon to track people logged into their website; this thing
crashed all the time, was slow, and generally not well implemented. It
occurred to me that much of the complexity of dealing with it was in the
level of abstraction for the network being too low: it ran on a Sun, so
reimplemented it on top of ONC/RPC with XDR for architecture independence
(most of the web servers were Intel machines). The new code was a sixth of
the size of what I started with, it was simpler and easier to reason about,
used less memory, was significantly faster, etc. The lesson is that the
right abstractions matter.
I further remember when I got to Google and saw protobuf for the first time
being a little confused. "Why didn't you just use XDR? It's an Internet
standard and there's an RFC defining it, and it's implemented essentially
everywhere. Why do something new?" The response was very much along the
lines of, "ho ho; this is Google, kid. We know what we're doing."
Apparently, the variable-length encoding for integers was considered
particularly important at the time, an argument I never really bought into.
*shrug*
It's a statistically valid sampling of one case :-)
>
I can totally believe that their workstations were slow and the software
environment was a bummer.
The interesting thing about all of this graphics stuff (and to tie it back
to TUHS) is that none of these things ever struck me as particularly Unix-y
in nature. X in particular doesn't seem like it composes nicely with
anything else, and in many ways, Unix from the perspective of a user is all
about composition from smaller parts. But X is this big, monolithic thing
that you kind of bolted on the side. For example, it certainly doesn't
integrate with, say, the permissions model.
I wonder if these seeming impedance mismatches are because pretty much
being all of this stuff invented as folks went along.
- Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210124/00e3f416/attachment.htm>
From jon at fourwinds.com Mon Jan 25 09:33:44 2021
From: jon at fourwinds.com (Jon Steinhart)
Date: Sun, 24 Jan 2021 15:33:44 -0800
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <CAEoi9W5=toe-bb+6-zC0odkx4_C4X4FZpK4+ZJTAqCKGOCXP7w@mail.gmail.com>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
<202101242045.10OKjDvA964774@darkstar.fourwinds.com>
<20210124211100.GI21030@mcvoy.com>
<202101242114.10OLEYGk966708@darkstar.fourwinds.com>
<20210124212525.GJ21030@mcvoy.com>
<CAEoi9W5=toe-bb+6-zC0odkx4_C4X4FZpK4+ZJTAqCKGOCXP7w@mail.gmail.com>
Message-ID: <202101242333.10ONXjcI974038@darkstar.fourwinds.com>
Dan Cross writes:
>
> The interesting thing about all of this graphics stuff (and to tie it back
> to TUHS) is that none of these things ever struck me as particularly Unix-y
> in nature. X in particular doesn't seem like it composes nicely with
> anything else, and in many ways, Unix from the perspective of a user is all
> about composition from smaller parts. But X is this big, monolithic thing
> that you kind of bolted on the side. For example, it certainly doesn't
> integrate with, say, the permissions model.
>
> I wonder if these seeming impedance mismatches are because pretty much
> being all of this stuff invented as folks went along.
>
> - Dan C.
This wasn't UNIX-y at all, it didn't come from UNIX despite having
its origin in the original Stanford University Network machine.
The problem isn't unique and is one of those things that I'm trying
to help with via mentoring and such. The big question that few seem
to consider is "Am I adding value with what I'm doing?" Even if
people think about it, few are learning much about history despite
our attempts here. I try to point out that learning the history is
important so that instead of repeating mistakes that others have made
one can come up with new and interesting mistakes.
I remember trying to talk to Bob Scheifler about this and was stunned
to hear him say "I don't believe in models because they predispose
your implementation." As near as I could tell, he didn't look at
anything anyone else had done (with the exception of the W code from
Stanford) which is why he made all sorts of beginner mistakes. For
example, had he been looking at other projects in the window space
he would have seen how Gosling and Rosenthal designed the Andrew
protocol to minimize network round trips. But it never seemed to
cross his mind until others pushed for it in response to NeWS.
These mismatches are everywhere today. Programming is more about
learning secret incantations to make poorly designed stuff sort of
work than it is about actual good design. At least in my opinion.
BTW, one of my part time projects here which is currently low on the
priority list is to fix this. I've done some prototyping of a "real
UNIX philosophy" window system which looks a lot like some of the Plan
9 stuff. I map my desktop into a filesystem and use inotify to monitor
changes. My goal, which so far seems achievable is to make a system
that requires no new commands and works with all of the existing ones.
Create a directory and fill it with some stuff to make a window.
Delete it to get rid of it. Write the size and position into files in
the directory to move and resize. And so on. Doing this, the window
manager was only a couple of hundred lines of bash script.
Going back to X versus NeWS in a way, one of the stumbling blocks is
how things have gone back to device-dependent graphics. As near as I
can tell (haven't done too much work here), it takes about a thousand
lines of code using Vulcan to draw a simple straight line these days.
Jon
From gtaylor at tnetconsulting.net Mon Jan 25 09:38:30 2021
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Sun, 24 Jan 2021 16:38:30 -0700
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <20210124205451.GH21030@mcvoy.com>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
<em6c238722-2515-4ad4-839e-0010ff1f9f9a@alien>
<20210124205451.GH21030@mcvoy.com>
Message-ID: <2e148195-9751-b362-87f8-41deed60ed5c@spamtrap.tnetconsulting.net>
On 1/24/21 1:54 PM, Larry McVoy wrote:
> I did the first SPARC Cluster and made a logo that was 4 interconnected
> Sun logos in the same shape, I can probably dig it up.
I would be curious to see the clustered SUN logo if you could find it
without much digging.
--
Grant. . . .
unix || die
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210124/1767615f/attachment.bin>
From erc at pobox.com Mon Jan 25 09:49:05 2021
From: erc at pobox.com (Ed Carp)
Date: Sun, 24 Jan 2021 16:49:05 -0700
Subject: [TUHS] Apollo/token-ring networks
Message-ID: <CACYmRNBJi+DY6jG1qCUfasT_fGJzVt_0aJ+H591x5G1sD3kqZA@mail.gmail.com>
On 1/24/21, Jon Steinhart <jon at fourwinds.com> wrote:
> So I never liked Apollos much. What I was referring to was Apollo's claim
> that their token-ring network performed better for large numbers of nodes.
> And they were correct. However, they didn't consider the eventually
> invention of switches that solved the problem.
A problem that shouldn't have ever been there in the first place. When
I was at EDS, we did a lot of benchmarks against token-ring vs.
CSMA-CD. Token-ring was slower than CSMA-CD until the traffic got to
be more than about 10% of capacity - then the collision detection
exponential backoff algorithm would clobber the network. The argument
that "well, we will never get above that anyway, so we want the
fastest we can get" sort of short-sightedness won the day. It wasn't
until switches and virtual LANs came into existence that (as you said)
solved the problem.
From erc at pobox.com Mon Jan 25 09:50:59 2021
From: erc at pobox.com (Ed Carp)
Date: Sun, 24 Jan 2021 16:50:59 -0700
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <20210124212525.GJ21030@mcvoy.com>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
<202101242045.10OKjDvA964774@darkstar.fourwinds.com>
<20210124211100.GI21030@mcvoy.com>
<202101242114.10OLEYGk966708@darkstar.fourwinds.com>
<20210124212525.GJ21030@mcvoy.com>
Message-ID: <CACYmRNATqpt+V_yjDD2C85GfdueZ6qGSt7fqiW7fYGPEttogcg@mail.gmail.com>
On 1/24/21, Larry McVoy <lm at mcvoy.com> wrote:
> On Sun, Jan 24, 2021 at 01:14:34PM -0800, Jon Steinhart wrote:
>> So I never liked Apollos much. What I was referring to was Apollo's
>> claim
>> that their token-ring network performed better for large numbers of
>> nodes.
>> And they were correct. However, they didn't consider the eventually
>> invention of switches that solved the problem.
>
> The network performance of the cluster of Apollos we had was awful.
> I don't know anything about how you set that up, never liked token rings,
> maybe it is possible to set it up wrong, I dunno. All I know was network
> performance was awful on the Apollos.
Until you got over 10% utilization or so, then token-ring would blow
the doors off anything else. At least that was our benchmarking
results.
From aek at bitsavers.org Mon Jan 25 10:11:03 2021
From: aek at bitsavers.org (Al Kossow)
Date: Sun, 24 Jan 2021 16:11:03 -0800
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <202101242333.10ONXjcI974038@darkstar.fourwinds.com>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
<202101242045.10OKjDvA964774@darkstar.fourwinds.com>
<20210124211100.GI21030@mcvoy.com>
<202101242114.10OLEYGk966708@darkstar.fourwinds.com>
<20210124212525.GJ21030@mcvoy.com>
<CAEoi9W5=toe-bb+6-zC0odkx4_C4X4FZpK4+ZJTAqCKGOCXP7w@mail.gmail.com>
<202101242333.10ONXjcI974038@darkstar.fourwinds.com>
Message-ID: <fc52a1a1-2136-ae39-110c-93a38e73ff94@bitsavers.org>
On 1/24/21 3:33 PM, Jon Steinhart wrote:
> As near as I could tell, he didn't look at
> anything anyone else had done (with the exception of the W code from
> Stanford)
And today it's impossible to find the original W code. At least I've not
been able to find it in decades of looking.
I don't beleive at the time SUN at Stanford was about Unix at all. It
was very much Cheriton and the V Kernel.
In that timeframe, wasn't CMU still into Spice and PERQs ?
From lm at mcvoy.com Mon Jan 25 10:18:53 2021
From: lm at mcvoy.com (Larry McVoy)
Date: Sun, 24 Jan 2021 16:18:53 -0800
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <2e148195-9751-b362-87f8-41deed60ed5c@spamtrap.tnetconsulting.net>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
<em6c238722-2515-4ad4-839e-0010ff1f9f9a@alien>
<20210124205451.GH21030@mcvoy.com>
<2e148195-9751-b362-87f8-41deed60ed5c@spamtrap.tnetconsulting.net>
Message-ID: <20210125001853.GA27947@mcvoy.com>
On Sun, Jan 24, 2021 at 04:38:30PM -0700, Grant Taylor via TUHS wrote:
> On 1/24/21 1:54 PM, Larry McVoy wrote:
> >I did the first SPARC Cluster and made a logo that was 4 interconnected
> >Sun logos in the same shape, I can probably dig it up.
>
> I would be curious to see the clustered SUN logo if you could find it
> without much digging.
Pretty simple:
%!PS
/inch { 72 mul } def
/offset { .20 inch } def
% Draws a cluster logo slight smaller than a postit note, about 2.5" square
% Drawn with the center at the current point.
/clusters {
gsave
newpath
0 setlinecap
100 dup dup dup % XXX - this has to be 100
4 {
gsave
dup 0 translate
45 rotate
gsave
3 44 dup dup scale div setlinewidth
-1 -1 moveto -1 1 lineto
1 1 lineto 1 -1 lineto closepath stroke
0 1 moveto 0 2 lineto stroke
-1 0 moveto -2 0 lineto stroke
-1 1 moveto -2 2 lineto stroke
grestore
6 setlinewidth
4 { 90 180
2 {
5 38 moveto
10 10 5 180 0 arc 15 38 lineto stroke
40 40 translate rotate
} repeat
} repeat
grestore
90 rotate
} repeat
grestore
} bind def
4 inch 8 inch translate
1 dup scale
clusters
showpage
From jon at fourwinds.com Mon Jan 25 10:21:03 2021
From: jon at fourwinds.com (Jon Steinhart)
Date: Sun, 24 Jan 2021 16:21:03 -0800
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <fc52a1a1-2136-ae39-110c-93a38e73ff94@bitsavers.org>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
<202101242045.10OKjDvA964774@darkstar.fourwinds.com>
<20210124211100.GI21030@mcvoy.com>
<202101242114.10OLEYGk966708@darkstar.fourwinds.com>
<20210124212525.GJ21030@mcvoy.com>
<CAEoi9W5=toe-bb+6-zC0odkx4_C4X4FZpK4+ZJTAqCKGOCXP7w@mail.gmail.com>
<202101242333.10ONXjcI974038@darkstar.fourwinds.com>
<fc52a1a1-2136-ae39-110c-93a38e73ff94@bitsavers.org>
Message-ID: <202101250021.10P0L3Z2976588@darkstar.fourwinds.com>
Al Kossow writes:
> On 1/24/21 3:33 PM, Jon Steinhart wrote:
> > As near as I could tell, he didn't look at
> > anything anyone else had done (with the exception of the W code from
> > Stanford)
>
> And today it's impossible to find the original W code. At least I've not
> been able to find it in decades of looking.
>
> I don't beleive at the time SUN at Stanford was about Unix at all. It
> was very much Cheriton and the V Kernel.
>
> In that timeframe, wasn't CMU still into Spice and PERQs ?
I think that X1 was W. But I was doing other stuff at the time and don't
know for sure.
From gtaylor at tnetconsulting.net Mon Jan 25 10:36:59 2021
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Sun, 24 Jan 2021 17:36:59 -0700
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <20210125001853.GA27947@mcvoy.com>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
<em6c238722-2515-4ad4-839e-0010ff1f9f9a@alien>
<20210124205451.GH21030@mcvoy.com>
<2e148195-9751-b362-87f8-41deed60ed5c@spamtrap.tnetconsulting.net>
<20210125001853.GA27947@mcvoy.com>
Message-ID: <6f68d72c-e829-795d-55ea-d24488b267c5@spamtrap.tnetconsulting.net>
On 1/24/21 5:18 PM, Larry McVoy wrote:
> Pretty simple:
Thank you Larry.
I put that into a sun-sun-sun-sun.ps file and opened it with gv /
Ghostscript perfectly fine.
Very nice! I like it.
Do you mind if I share this with some friends, obviously giving you credit.
--
Grant. . . .
unix || die
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210124/74f0428a/attachment.bin>
From lm at mcvoy.com Mon Jan 25 10:41:26 2021
From: lm at mcvoy.com (Larry McVoy)
Date: Sun, 24 Jan 2021 16:41:26 -0800
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <6f68d72c-e829-795d-55ea-d24488b267c5@spamtrap.tnetconsulting.net>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
<em6c238722-2515-4ad4-839e-0010ff1f9f9a@alien>
<20210124205451.GH21030@mcvoy.com>
<2e148195-9751-b362-87f8-41deed60ed5c@spamtrap.tnetconsulting.net>
<20210125001853.GA27947@mcvoy.com>
<6f68d72c-e829-795d-55ea-d24488b267c5@spamtrap.tnetconsulting.net>
Message-ID: <20210125004126.GO21030@mcvoy.com>
On Sun, Jan 24, 2021 at 05:36:59PM -0700, Grant Taylor via TUHS wrote:
> On 1/24/21 5:18 PM, Larry McVoy wrote:
> >Pretty simple:
>
> Thank you Larry.
>
> I put that into a sun-sun-sun-sun.ps file and opened it with gv /
> Ghostscript perfectly fine.
>
> Very nice! I like it.
>
> Do you mind if I share this with some friends, obviously giving you credit.
It was part of sunbox which became SPARCluster I so I'm sure it is public.
I'll take credit, it was my design and implementation. It's not much but
I look at that file and kind glaze over, I'd have to go get a Postscript
cheat sheet to tell you how it works.
A rambling way of saying "go for it" :-)
From gregg.drwho8 at gmail.com Mon Jan 25 14:58:36 2021
From: gregg.drwho8 at gmail.com (Gregg Levine)
Date: Sun, 24 Jan 2021 23:58:36 -0500
Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
In-Reply-To: <m2lfcie2t6.fsf@thuvia.hamartun.priv.no>
References: <20200919152835.4E73A18C0DD@mercury.lcs.mit.edu>
<m2lfcie2t6.fsf@thuvia.hamartun.priv.no>
Message-ID: <CAC5iaNG9AYpi+C=rGrJ-487jaMiO2h_vzi188Zuniy=CqNssFw@mail.gmail.com>
Hello!
You mention having gotten the Shoppe collection of images up on Simh.
Now I worked out how to bring up the boot disk that way without any
problem. But, ah, never did figure out how to bring up the user disks
in the collection. When you have the time, can you provide me with
some information on how you did all of that?
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On Sun, Jan 24, 2021 at 11:17 AM Tom Ivar Helbekkmo via TUHS
<tuhs at minnie.tuhs.org> wrote:
>
> Noel Chiappa <jnc at mercury.lcs.mit.edu> writes:
>
> > V6 can be run on an -11/23 (I've done it), but not straight out of the box;
> > it requires a few minor tweaks first:
> >
> > http://gunkies.org/wiki/Running_UNIX_V6_on_an_-11/23
>
> Noel,
>
> here's a huge THANK YOU! from me - I've had a couple of uPDP-11/23+
> systems stowed away for over twenty years, with an eye to one day
> porting V6 to them, and this comment from you finally made me pull out
> one of them and do it. I now have V6 running on the physical hardware,
> booting from an RD52 on an RQDX3 MSCP controller, and announcing 488KW
> of available RAM at boot.
>
> Here's the write-up: https://www.hamartun.priv.no/v6unix.html
>
> I am *so* looking forward to continuing work on this system (it's just
> barely running, since a couple of days ago), and your web page about
> improving V6 will certainly be my launch pad for the next rounds.
>
> -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 tih at hamartun.priv.no Mon Jan 25 18:21:06 2021
From: tih at hamartun.priv.no (Tom Ivar Helbekkmo)
Date: Mon, 25 Jan 2021 09:21:06 +0100
Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
In-Reply-To: <CAC5iaNG9AYpi+C=rGrJ-487jaMiO2h_vzi188Zuniy=CqNssFw@mail.gmail.com>
(Gregg Levine's message of "Sun, 24 Jan 2021 23:58:36 -0500")
References: <20200919152835.4E73A18C0DD@mercury.lcs.mit.edu>
<m2lfcie2t6.fsf@thuvia.hamartun.priv.no>
<CAC5iaNG9AYpi+C=rGrJ-487jaMiO2h_vzi188Zuniy=CqNssFw@mail.gmail.com>
Message-ID: <m2v9bl5swd.fsf@thuvia.hamartun.priv.no>
Gregg Levine <gregg.drwho8 at gmail.com> writes:
> But, ah, never did figure out how to bring up the user disks in the
> collection. When you have the time, can you provide me with some
> information on how you did all of that?
To mount additional disks, just attach them (in simh) and mount them (in
the OS). Sort of like this (from memory, hopefully right):
$ pdp11
simh> set cpu 11/23+
simh> set rl0 rl02
simh> attach rl0 unix_v6.rl02
simh> deposit system sr 173030
simh> boot rl0
!unix
# STTY -LCASE
# ^E
simh> set rl1 rl02
simh> attach rl1 user01.rl02
simh> continue
# mount /dev/rl1 /mnt
-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 coppero1237 at gmail.com Mon Jan 25 21:10:11 2021
From: coppero1237 at gmail.com (Tyler Adams)
Date: Mon, 25 Jan 2021 13:10:11 +0200
Subject: [TUHS] Favorite unix design principles?
Message-ID: <CAEuQd1D00TvjQWfSYvawS45qMnG_cThdHig2rFco+emzxEYsQA@mail.gmail.com>
I'm writing about my 5 favorite unix design principles on my blog this
week, and it got me wondering what others' favorite unix design principles
are? For reference, mine are:
- Rule of Separation (from TAOUP <http://catb.org/~esr/writings/taoup/html/>
)
- Let the Machine Do the Dirty Work (from Elements of Programming Style)
- Rule of Silence (from TAOUP <http://catb.org/~esr/writings/taoup/html/>)
- Data Dominates (Rob Pike #5)
- The SPOT (Single Point of Truth) Rule (from TAOUP
<http://catb.org/~esr/writings/taoup/html/>)
Tyler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210125/d823c444/attachment.htm>
From usotsuki at buric.co Mon Jan 25 22:32:33 2021
From: usotsuki at buric.co (Steve Nickolas)
Date: Mon, 25 Jan 2021 07:32:33 -0500 (EST)
Subject: [TUHS] Favorite unix design principles?
In-Reply-To: <CAEuQd1D00TvjQWfSYvawS45qMnG_cThdHig2rFco+emzxEYsQA@mail.gmail.com>
References: <CAEuQd1D00TvjQWfSYvawS45qMnG_cThdHig2rFco+emzxEYsQA@mail.gmail.com>
Message-ID: <alpine.DEB.2.21.2101250729510.22271@sd-119843.dedibox.fr>
On Mon, 25 Jan 2021, Tyler Adams wrote:
> I'm writing about my 5 favorite unix design principles on my blog this
> week, and it got me wondering what others' favorite unix design principles
> are? For reference, mine are:
>
> - Rule of Separation (from TAOUP <http://catb.org/~esr/writings/taoup/html/>
> )
> - Let the Machine Do the Dirty Work (from Elements of Programming Style)
> - Rule of Silence (from TAOUP <http://catb.org/~esr/writings/taoup/html/>)
> - Data Dominates (Rob Pike #5)
> - The SPOT (Single Point of Truth) Rule (from TAOUP
> <http://catb.org/~esr/writings/taoup/html/>)
>
> Tyler
>
1. Pipes
2. Text as the preferred format for input and output
3. 'Most everything as a file
4. The idea of simple tools that are optimized for a single task
5. A powerful scripting language built into the system that, combined with
1-4, makes writing new tools heaps easier.
-uso.
From clemc at ccc.com Tue Jan 26 00:33:03 2021
From: clemc at ccc.com (Clem Cole)
Date: Mon, 25 Jan 2021 09:33:03 -0500
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <fc52a1a1-2136-ae39-110c-93a38e73ff94@bitsavers.org>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
<202101242045.10OKjDvA964774@darkstar.fourwinds.com>
<20210124211100.GI21030@mcvoy.com>
<202101242114.10OLEYGk966708@darkstar.fourwinds.com>
<20210124212525.GJ21030@mcvoy.com>
<CAEoi9W5=toe-bb+6-zC0odkx4_C4X4FZpK4+ZJTAqCKGOCXP7w@mail.gmail.com>
<202101242333.10ONXjcI974038@darkstar.fourwinds.com>
<fc52a1a1-2136-ae39-110c-93a38e73ff94@bitsavers.org>
Message-ID: <CAC20D2N0mENhiZo88yBnGYBytv9rp4uMyO3X1TvRZ8e7_PJeqg@mail.gmail.com>
On Sun, Jan 24, 2021 at 7:11 PM Al Kossow <aek at bitsavers.org> wrote:
> And today it's impossible to find the original W code. At least I've not
> been able to find it in decades of looking.
>
> I don't beleive at the time SUN at Stanford was about Unix at all. It
> was very much Cheriton and the V Kernel.
>
> In that timeframe, wasn't CMU still into Spice and PERQs ?
>
Yes, to both.
á§
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210125/0c01ea69/attachment.htm>
From clemc at ccc.com Tue Jan 26 00:38:00 2021
From: clemc at ccc.com (Clem Cole)
Date: Mon, 25 Jan 2021 09:38:00 -0500
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <202101250021.10P0L3Z2976588@darkstar.fourwinds.com>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
<202101242045.10OKjDvA964774@darkstar.fourwinds.com>
<20210124211100.GI21030@mcvoy.com>
<202101242114.10OLEYGk966708@darkstar.fourwinds.com>
<20210124212525.GJ21030@mcvoy.com>
<CAEoi9W5=toe-bb+6-zC0odkx4_C4X4FZpK4+ZJTAqCKGOCXP7w@mail.gmail.com>
<202101242333.10ONXjcI974038@darkstar.fourwinds.com>
<fc52a1a1-2136-ae39-110c-93a38e73ff94@bitsavers.org>
<202101250021.10P0L3Z2976588@darkstar.fourwinds.com>
Message-ID: <CAC20D2OhTW+eebyub7dVMBGZy1zoOja=ojGB_=TOjgB0wEJdHQ@mail.gmail.com>
On Sun, Jan 24, 2021 at 7:21 PM Jon Steinhart <jon at fourwinds.com> wrote:
> I think that X1 was W. But I was doing other stuff at the time and don't
> know for sure.
>
Gettys or Keith might know = but I think that is close. My memory was X1
was a port of W to the Vaxstation under Ultrix. Like you I was not paying
a lot of attention.
Al - is W in with Cheriton's V kernel archives?
á§
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210125/5623893c/attachment.htm>
From aek at bitsavers.org Tue Jan 26 01:31:01 2021
From: aek at bitsavers.org (Al Kossow)
Date: Mon, 25 Jan 2021 07:31:01 -0800
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <CAC20D2OhTW+eebyub7dVMBGZy1zoOja=ojGB_=TOjgB0wEJdHQ@mail.gmail.com>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
<202101242045.10OKjDvA964774@darkstar.fourwinds.com>
<20210124211100.GI21030@mcvoy.com>
<202101242114.10OLEYGk966708@darkstar.fourwinds.com>
<20210124212525.GJ21030@mcvoy.com>
<CAEoi9W5=toe-bb+6-zC0odkx4_C4X4FZpK4+ZJTAqCKGOCXP7w@mail.gmail.com>
<202101242333.10ONXjcI974038@darkstar.fourwinds.com>
<fc52a1a1-2136-ae39-110c-93a38e73ff94@bitsavers.org>
<202101250021.10P0L3Z2976588@darkstar.fourwinds.com>
<CAC20D2OhTW+eebyub7dVMBGZy1zoOja=ojGB_=TOjgB0wEJdHQ@mail.gmail.com>
Message-ID: <6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org>
On 1/25/21 6:38 AM, Clem Cole wrote:
> Gettys or Keith might know = but I think that is close. My memory was X1 was a port of W to the Vaxstation under Ultrix. Like you I was
> not paying a lot of attention.
>
> Al - is W in with Cheriton's V kernel archives?
> á§
If it is the stuff I have up on bitsavers, no it isn't.
I wonder if Jim ever found a home for his archives. He talked
to me/CHM about it years ago.
From henry.r.bent at gmail.com Tue Jan 26 01:48:22 2021
From: henry.r.bent at gmail.com (Henry Bent)
Date: Mon, 25 Jan 2021 10:48:22 -0500
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <CAC20D2OhTW+eebyub7dVMBGZy1zoOja=ojGB_=TOjgB0wEJdHQ@mail.gmail.com>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
<202101242045.10OKjDvA964774@darkstar.fourwinds.com>
<20210124211100.GI21030@mcvoy.com>
<202101242114.10OLEYGk966708@darkstar.fourwinds.com>
<20210124212525.GJ21030@mcvoy.com>
<CAEoi9W5=toe-bb+6-zC0odkx4_C4X4FZpK4+ZJTAqCKGOCXP7w@mail.gmail.com>
<202101242333.10ONXjcI974038@darkstar.fourwinds.com>
<fc52a1a1-2136-ae39-110c-93a38e73ff94@bitsavers.org>
<202101250021.10P0L3Z2976588@darkstar.fourwinds.com>
<CAC20D2OhTW+eebyub7dVMBGZy1zoOja=ojGB_=TOjgB0wEJdHQ@mail.gmail.com>
Message-ID: <CAEdTPBes+LMj6RQKbktOnOEL=C3FuHcFK2-sB8OYG_TOdozOgg@mail.gmail.com>
On Mon, 25 Jan 2021 at 09:39, Clem Cole <clemc at ccc.com> wrote:
>
>
> On Sun, Jan 24, 2021 at 7:21 PM Jon Steinhart <jon at fourwinds.com> wrote:
>
>> I think that X1 was W. But I was doing other stuff at the time and don't
>> know for sure.
>>
> Gettys or Keith might know = but I think that is close. My memory was X1
> was a port of W to the Vaxstation under Ultrix. Like you I was not paying
> a lot of attention.
>
The reference port for X10 was certainly a VAXstation (I/II/GPX). I've
compiled and run X10 and X11R1 on SIMH's microVAX II emulation running
Ultrix 2.3; my recollection is that it all works right out of the box.
Wikipedia says "DEC, then preparing to release its first Ultrix
<https://en.wikipedia.org/wiki/Ultrix> workstation, judged X the only
windowing system likely to become available in time. DEC engineers ported
X6 to DEC's QVSS display on MicroVAX
<https://en.wikipedia.org/wiki/MicroVAX>." To me that's unclear if there
already was an Ultrix / uVAX port of some other nature or if that was the
first iteration.
https://www.talisman.org/x-debut.shtml states that the original X was for
the VAXstation 100. I have no idea what OS it would have been running; a
release date of 1983 for the VS100 would predate Ultrix 1.0.
-Henry
> á§
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210125/de946606/attachment.htm>
From rich.salz at gmail.com Tue Jan 26 01:55:34 2021
From: rich.salz at gmail.com (Richard Salz)
Date: Mon, 25 Jan 2021 10:55:34 -0500
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
<202101242045.10OKjDvA964774@darkstar.fourwinds.com>
<20210124211100.GI21030@mcvoy.com>
<202101242114.10OLEYGk966708@darkstar.fourwinds.com>
<20210124212525.GJ21030@mcvoy.com>
<CAEoi9W5=toe-bb+6-zC0odkx4_C4X4FZpK4+ZJTAqCKGOCXP7w@mail.gmail.com>
<202101242333.10ONXjcI974038@darkstar.fourwinds.com>
<fc52a1a1-2136-ae39-110c-93a38e73ff94@bitsavers.org>
<202101250021.10P0L3Z2976588@darkstar.fourwinds.com>
<CAC20D2OhTW+eebyub7dVMBGZy1zoOja=ojGB_=TOjgB0wEJdHQ@mail.gmail.com>
<6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org>
Message-ID: <CAFH29to9GaKVxUXw8uwbeMAcF6izD=8gqhqROzCOSEA5xOA5aQ@mail.gmail.com>
A couple of updates.
At a Usenix (Portland?) dmr had a keynote and he interviewed himself.Q:
"What do you think of X?" A: "Sometimes when you fill a vacuum it still
sucks." Maybe Rob said it earlier, but that was the first time I heard it
publically.
Osterhout's Tk was beyond amazing. I was at OSF and gave several demo's
(the "windowing ksh" was also available). The idea that you could "send"
to another GUI program and add buttons, etc., instantaneously! John had
already implemented the Motif look and feel (from the spec), mostly, and
was willing to do anything if OSF would take it and call it Motif. The
Motif leads (I was in DCE) weren't interested, although maybe they'd put it
on the "extra's" tape at the end. This was circa 1992. I once told this
story to some Microsoft PM's, and they agreed it would have completely
killed Visual Basic. Ah well.
Apollo's had two 68K processors, the second one watched for page faults and
patched things up since it wasn't until 68020 that the faulting stuff
worked properly. The Apollo source control team left after HP and formed
Clearcase.
DCE RPC was based on Apollo NCS which was a very elegant RPC system built
on UDP. It had no XDR because it was "reader makes it right" and datatypes
were tagged. I don't recall details of the tagging. Digital added TCP
transport. Microsoft took the DCE RPC spec (we had a name for them, I
forget what it was) and used it to implement DCOM's RPC. There's an IETF
draft, https://tools.ietf.org/html/draft-brown-dcom-v1-spec-01, but it
never progressed beyond that.
Hope this is interesting to some.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210125/1254a745/attachment.htm>
From arnold at skeeve.com Tue Jan 26 01:46:40 2021
From: arnold at skeeve.com (Arnold Robbins)
Date: Mon, 25 Jan 2021 17:46:40 +0200
Subject: [TUHS] System V Release 2, adding swap?
Message-ID: <E1l444e-0002Mj-N4@tanda>
Hi.
Does anyone know how to add swap space on a System V Release 2 system?
In particular, on an emulated AT&T 3B1. The kernel is S5R1 or S5R2
vintage.
I don't see any commands with 'swap' in their names.
Thanks,
Arnold
From lm at mcvoy.com Tue Jan 26 02:04:30 2021
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 25 Jan 2021 08:04:30 -0800
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <CAFH29to9GaKVxUXw8uwbeMAcF6izD=8gqhqROzCOSEA5xOA5aQ@mail.gmail.com>
References: <20210124211100.GI21030@mcvoy.com>
<202101242114.10OLEYGk966708@darkstar.fourwinds.com>
<20210124212525.GJ21030@mcvoy.com>
<CAEoi9W5=toe-bb+6-zC0odkx4_C4X4FZpK4+ZJTAqCKGOCXP7w@mail.gmail.com>
<202101242333.10ONXjcI974038@darkstar.fourwinds.com>
<fc52a1a1-2136-ae39-110c-93a38e73ff94@bitsavers.org>
<202101250021.10P0L3Z2976588@darkstar.fourwinds.com>
<CAC20D2OhTW+eebyub7dVMBGZy1zoOja=ojGB_=TOjgB0wEJdHQ@mail.gmail.com>
<6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org>
<CAFH29to9GaKVxUXw8uwbeMAcF6izD=8gqhqROzCOSEA5xOA5aQ@mail.gmail.com>
Message-ID: <20210125160430.GR21030@mcvoy.com>
On Mon, Jan 25, 2021 at 10:55:34AM -0500, Richard Salz wrote:
> Osterhout's Tk was beyond amazing.
Still is, really. So far as I know, nobody has come up with anything better.
> It had no XDR because it was "reader makes it right" and datatypes
> were tagged.
That's the first I've heard of that and I really like it. Most of the
time, you are on a network of machines that are the same, so why have
a network byte order, reader makes it right will just work. Neat.
--lm
From crossd at gmail.com Tue Jan 26 02:37:25 2021
From: crossd at gmail.com (Dan Cross)
Date: Mon, 25 Jan 2021 11:37:25 -0500
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <20210125160430.GR21030@mcvoy.com>
References: <20210124211100.GI21030@mcvoy.com>
<202101242114.10OLEYGk966708@darkstar.fourwinds.com>
<20210124212525.GJ21030@mcvoy.com>
<CAEoi9W5=toe-bb+6-zC0odkx4_C4X4FZpK4+ZJTAqCKGOCXP7w@mail.gmail.com>
<202101242333.10ONXjcI974038@darkstar.fourwinds.com>
<fc52a1a1-2136-ae39-110c-93a38e73ff94@bitsavers.org>
<202101250021.10P0L3Z2976588@darkstar.fourwinds.com>
<CAC20D2OhTW+eebyub7dVMBGZy1zoOja=ojGB_=TOjgB0wEJdHQ@mail.gmail.com>
<6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org>
<CAFH29to9GaKVxUXw8uwbeMAcF6izD=8gqhqROzCOSEA5xOA5aQ@mail.gmail.com>
<20210125160430.GR21030@mcvoy.com>
Message-ID: <CAEoi9W4TMh=SSrk=pqprark7+ctvZLsbW8h00pf31KbtUAy_CQ@mail.gmail.com>
On Mon, Jan 25, 2021 at 11:05 AM Larry McVoy <lm at mcvoy.com> wrote:
> On Mon, Jan 25, 2021 at 10:55:34AM -0500, Richard Salz wrote:
> > Osterhout's Tk was beyond amazing.
>
> Still is, really. So far as I know, nobody has come up with anything
> better.
>
I think one of the innovations that kept it alive was that people took Tk
itself and separated it from Tcl, so one saw bindings from any number of
languages.
The Inferno operating system that was essentially a commercialization of
plan9, implemented Tk with the Limbo programming language (which in many
ways is perhaps the most direct ancestor of Go). That was neat to play
with. Too bad it didn't have a lot of success.
> It had no XDR because it was "reader makes it right" and datatypes
> > were tagged.
>
> That's the first I've heard of that and I really like it. Most of the
> time, you are on a network of machines that are the same, so why have
> a network byte order, reader makes it right will just work. Neat.
>
I guess I don't quite understand that. I can get how it works for simple
data types (integers, floating point numbers, perhaps strings) but it seems
like it breaks down pretty quickly for anything with a more complex
representation (structures with multiple members, for instance; how does
one deal with padding, etc?). "Reader makes right" makes some sense for any
pair of sender/receiver architectures, but once you have more than a
handful of machine types with potentially different
ABIs/representations/alignment requirements, etc, then it seems like you're
an n^2 mutual ABI understanding issue. Perhaps I'm being naive in assuming
that multi-data structures are just written out in host format, but if you,
say, write element by element to avoid that, then it seems like you're
already nearly at an architecture independent data representation anyway,
so what does NOT having that buy you? I guess it's potentially faster if
you don't have to swab bytes between similar architectures?
- Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210125/a48f5008/attachment.htm>
From rich.salz at gmail.com Tue Jan 26 02:49:01 2021
From: rich.salz at gmail.com (Richard Salz)
Date: Mon, 25 Jan 2021 11:49:01 -0500
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <CAEoi9W4TMh=SSrk=pqprark7+ctvZLsbW8h00pf31KbtUAy_CQ@mail.gmail.com>
References: <20210124211100.GI21030@mcvoy.com>
<202101242114.10OLEYGk966708@darkstar.fourwinds.com>
<20210124212525.GJ21030@mcvoy.com>
<CAEoi9W5=toe-bb+6-zC0odkx4_C4X4FZpK4+ZJTAqCKGOCXP7w@mail.gmail.com>
<202101242333.10ONXjcI974038@darkstar.fourwinds.com>
<fc52a1a1-2136-ae39-110c-93a38e73ff94@bitsavers.org>
<202101250021.10P0L3Z2976588@darkstar.fourwinds.com>
<CAC20D2OhTW+eebyub7dVMBGZy1zoOja=ojGB_=TOjgB0wEJdHQ@mail.gmail.com>
<6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org>
<CAFH29to9GaKVxUXw8uwbeMAcF6izD=8gqhqROzCOSEA5xOA5aQ@mail.gmail.com>
<20210125160430.GR21030@mcvoy.com>
<CAEoi9W4TMh=SSrk=pqprark7+ctvZLsbW8h00pf31KbtUAy_CQ@mail.gmail.com>
Message-ID: <CAFH29trS2x_hD3roQV9-CAHYN41dgMcs+QXhWJm4z5Zr6+_kPQ@mail.gmail.com>
> It had no XDR because it was "reader makes it right" and datatypes
> > were tagged.
>>
>> That's the first I've heard of that and I really like it. Most of the
>> time, you are on a network of machines that are the same, so why have
>> a network byte order, reader makes it right will just work. Neat.
>>
>
> I guess I don't quite understand that. I can get how it works for simple
> data types (integers, floating point numbers, perhaps strings) but it seems
> like it breaks
>
It was only for native types
https://pubs.opengroup.org/onlinepubs/9629399/chap14.htm The other things
-- struct, array, pointers, etc -- have rules. See the link if you care
for nitty-gritty details.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210125/95e882f2/attachment.htm>
From bakul at iitbombay.org Tue Jan 26 03:11:58 2021
From: bakul at iitbombay.org (Bakul Shah)
Date: Mon, 25 Jan 2021 09:11:58 -0800
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <CAEoi9W4TMh=SSrk=pqprark7+ctvZLsbW8h00pf31KbtUAy_CQ@mail.gmail.com>
References: <CAEoi9W4TMh=SSrk=pqprark7+ctvZLsbW8h00pf31KbtUAy_CQ@mail.gmail.com>
Message-ID: <F02E2017-C165-4C32-98F7-6A71D298AA68@iitbombay.org>
see Ron Rivest’s s-expression serialization:
http://people.csail.mit.edu/rivest/Sexp.txt
of course, now we have json....
> On Jan 25, 2021, at 8:38 AM, Dan Cross <crossd at gmail.com> wrote:
> I guess I don't quite understand that. I can get how it works for simple data types (integers, floating point numbers, perhaps strings) but it seems like it breaks down pretty quickly for anything with a more complex representation (structures with multiple members, for instance; how does one deal with padding, etc?). "Reader makes right" makes some sense for any pair of sender/receiver architectures, but once you have more than a handful of machine types with potentially different ABIs/representations/alignment requirements, etc, then it seems like you're an n^2 mutual ABI understanding issue. Perhaps I'm being naive in assuming that multi-data structures are just written out in host format, but if you, say, write element by element to avoid that, then it seems like you're already nearly at an architecture independent data representation anyway, so what does NOT having that buy you? I guess it's potentially faster if you don't have to swab bytes between similar architectures?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210125/6e8febe4/attachment.htm>
From lm at mcvoy.com Tue Jan 26 03:25:31 2021
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 25 Jan 2021 09:25:31 -0800
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <CAEoi9W4TMh=SSrk=pqprark7+ctvZLsbW8h00pf31KbtUAy_CQ@mail.gmail.com>
References: <20210124212525.GJ21030@mcvoy.com>
<CAEoi9W5=toe-bb+6-zC0odkx4_C4X4FZpK4+ZJTAqCKGOCXP7w@mail.gmail.com>
<202101242333.10ONXjcI974038@darkstar.fourwinds.com>
<fc52a1a1-2136-ae39-110c-93a38e73ff94@bitsavers.org>
<202101250021.10P0L3Z2976588@darkstar.fourwinds.com>
<CAC20D2OhTW+eebyub7dVMBGZy1zoOja=ojGB_=TOjgB0wEJdHQ@mail.gmail.com>
<6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org>
<CAFH29to9GaKVxUXw8uwbeMAcF6izD=8gqhqROzCOSEA5xOA5aQ@mail.gmail.com>
<20210125160430.GR21030@mcvoy.com>
<CAEoi9W4TMh=SSrk=pqprark7+ctvZLsbW8h00pf31KbtUAy_CQ@mail.gmail.com>
Message-ID: <20210125172531.GP32503@mcvoy.com>
On Mon, Jan 25, 2021 at 11:37:25AM -0500, Dan Cross wrote:
> On Mon, Jan 25, 2021 at 11:05 AM Larry McVoy <lm at mcvoy.com> wrote:
> > On Mon, Jan 25, 2021 at 10:55:34AM -0500, Richard Salz wrote:
> > > Osterhout's Tk was beyond amazing.
> >
> > Still is, really. So far as I know, nobody has come up with anything
> > better.
>
> The Inferno operating system that was essentially a commercialization of
> plan9, implemented Tk with the Limbo programming language (which in many
> ways is perhaps the most direct ancestor of Go). That was neat to play
> with. Too bad it didn't have a lot of success.
We did something similar, I hated Tcl so much I paid a friend to make
a compiler for a very C like language that compiled to Tcl byte codes.
It's really what I'd like to see C evolve to:
http://little-lang.org
> > It had no XDR because it was "reader makes it right" and datatypes
> > > were tagged.
> >
> > That's the first I've heard of that and I really like it. Most of the
> > time, you are on a network of machines that are the same, so why have
> > a network byte order, reader makes it right will just work. Neat.
>
> I guess I don't quite understand that. I can get how it works for simple
> data types (integers, floating point numbers, perhaps strings) but it seems
> like it breaks down pretty quickly for anything with a more complex
> representation (structures with multiple members, for instance; how does
> one deal with padding, etc?).
Yeah, good points and I suppose that is why Sun did network byte order.
It's still appealing to have reader make right if you can do it, though
with todays out of order CPUs providing a pretty high instructions
per cycle maybe it just doesn't matter. There is a paper waiting to
be written.
--lm
From gingell at computer.org Tue Jan 26 08:25:53 2021
From: gingell at computer.org (Rob Gingell)
Date: Mon, 25 Jan 2021 14:25:53 -0800
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <CAFH29to9GaKVxUXw8uwbeMAcF6izD=8gqhqROzCOSEA5xOA5aQ@mail.gmail.com>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
<202101242045.10OKjDvA964774@darkstar.fourwinds.com>
<20210124211100.GI21030@mcvoy.com>
<202101242114.10OLEYGk966708@darkstar.fourwinds.com>
<20210124212525.GJ21030@mcvoy.com>
<CAEoi9W5=toe-bb+6-zC0odkx4_C4X4FZpK4+ZJTAqCKGOCXP7w@mail.gmail.com>
<202101242333.10ONXjcI974038@darkstar.fourwinds.com>
<fc52a1a1-2136-ae39-110c-93a38e73ff94@bitsavers.org>
<202101250021.10P0L3Z2976588@darkstar.fourwinds.com>
<CAC20D2OhTW+eebyub7dVMBGZy1zoOja=ojGB_=TOjgB0wEJdHQ@mail.gmail.com>
<6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org>
<CAFH29to9GaKVxUXw8uwbeMAcF6izD=8gqhqROzCOSEA5xOA5aQ@mail.gmail.com>
Message-ID: <999925ac-e9a5-d858-482b-1c60733a601b@computer.org>
On 1/25/2021 7:55 AM, Richard Salz wrote:
> ... It had no XDR because it was "reader makes it right" ...
Who made it wrong?
The issues addressed by a presentation layer are there whether you
explicitly make one (XDR) or embed it as a conditional (itself an
overhead.) But it's a tomayto tomahto thing in the end, just as it was
30 years ago, the same only different -- and both distinctions opaque to
who really mattered, the people spending money.
ONC and DCE RPC are both charmingly clear in comparison with the vogue
of protobufs and grpc. They're also both pervasive today well beyond the
platforms that birthed them.
A factor in the arc of NeWS' trajectory not thus far mentioned was its
acceptance by ISVs, though Clem's comment applies:
On Mon Jan 25 03:04:09 AEST 2021, Clem Cole wrote:
> As I have said in other replies: "simple economics always beats
> sophisticated architecture."
In these forums there is a lot of discussions about the technical merits
of this or that technology. It's perhaps unsatisfying to those of us
invested in those technologies but often those merits (or their lack)
don't determine what thrives and what doesn't.
I was a distant observer of, and occasional experimenter with, NeWS as a
technology. My recollections are of impressive capability and
performance (for the time) and elegance. (But then, my TECO skills were
still pretty high at the time so PostScript wasn't confronting in
comparison -- I'm sure I'd think differently coming at it cold now.)
But I was a much closer observer/participant with ISVs. The measure
which most highly correlated with Sun's ascent and success was the "thud
factor" of its applications catalog. When it was actually a printed
thing, at its height the Catalyst catalog had the throw weight of a
large metropolitan area phone book (hopefully not too dated an analogy.)
Few of Sun's customers bought Sun to have Sun, they were bought to run
applications that happened to run on Sun. We sold more Suns if we had
more ISVs on board. If you sold more you got more ISVs. And so it goes
-- the applications "virtuous cycle". When the feedback loop is
positive, it turns "selling" into "order taking" which is a pretty clear
indicator of marketing dollars having been well-spent.
In this relationship there is a tension between platform differentiation
attempts and keeping the flywheel effect of the virtuous cycle going. An
ISV is going to look at platform differentiation as either lubrication
or friction. They're going to resist friction and pursue lubrication. In
the end, NeWS caused too much friction. (A corollary is that an ISV
initially views any differentiation as friction, you need to prove it
can be lubrication, and the ISV's importance to the market determines
how much energy you put into that.)
There was attraction to NeWS because it was provocatively capable. A
number of ISVs, important ones, chose to adopt. But each release of
NeWS, while objectively better, was also sufficiently different that
what initially appeared to be an attractor was unsustainable for the
ISVs to keep up with, even in service of Sun as the then market leader.
Sun's volumes would allow us to get away with imposing a certain amount
of friction of variation with ISVs but there were always limits to it --
the ISVs are trying to run their own businesses with their own
differentiations and agendas to pursue.
For the ISVs, variations of any sort were not a one-time cost. They
repeated as qualification events when new software versions or new
systems were introduced. Just staying still on a platform and with a
vendor costs them. Making them re-do any portion of the initial effort
as well is a significant disincentive. You may not be able to introduce
your new product if they don't come along, they may not come along until
they're sure your new product will sell enough to make it worthwhile. So
successfully lubricating those costs as much as possible was for a lot
of us a primary reason for the Sun's growth. Differentiation "behind
interfaces" as we did in the operating system space helped lower that
cost. Binary compatibility was super important. Gratuitous improvements
that lacked opacity were avoided and we often made vanilla choices. Not
perfect certainly, but good enough.
NeWS stood out for not doing that, and that fact I think had far more to
do with its status today than whether or not the source was available.
Arguably NeWS never got far enough to have the availability conversation
but now I'm back to being too distant from it to really know.
The tensions being maintained in these market dynamics have multiple
factors. It's tempting but hard to pick the one true reason for any
outcome. But the virtuous cycle explains a lot of phenomena. It
certainly doesn't hurt to be excellent in what you do, but sadly, it's
not as determinative as we as practitioners might wish it to be. There's
a reason we can all find examples of technologically superior failures.
That said, I do think the NeWS experience was at least part of what
later informed Java's compatibility especially at the binary level, the
separation of the JVM from the language(s) hosted on it. Not the "one
true reason", but among the mix of considerations.
From gnu at toad.com Tue Jan 26 09:46:34 2021
From: gnu at toad.com (John Gilmore)
Date: Mon, 25 Jan 2021 15:46:34 -0800
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <CAEoi9W4TMh=SSrk=pqprark7+ctvZLsbW8h00pf31KbtUAy_CQ@mail.gmail.com>
References: <20210124211100.GI21030@mcvoy.com>
<202101242114.10OLEYGk966708@darkstar.fourwinds.com>
<20210124212525.GJ21030@mcvoy.com>
<CAEoi9W5=toe-bb+6-zC0odkx4_C4X4FZpK4+ZJTAqCKGOCXP7w@mail.gmail.com>
<202101242333.10ONXjcI974038@darkstar.fourwinds.com>
<fc52a1a1-2136-ae39-110c-93a38e73ff94@bitsavers.org>
<202101250021.10P0L3Z2976588@darkstar.fourwinds.com>
<CAC20D2OhTW+eebyub7dVMBGZy1zoOja=ojGB_=TOjgB0wEJdHQ@mail.gmail.com>
<6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org>
<CAFH29to9GaKVxUXw8uwbeMAcF6izD=8gqhqROzCOSEA5xOA5aQ@mail.gmail.com>
<20210125160430.GR21030@mcvoy.com>
<CAEoi9W4TMh=SSrk=pqprark7+ctvZLsbW8h00pf31KbtUAy_CQ@mail.gmail.com>
Message-ID: <9727.1611618394@hop.toad.com>
Dan Cross <crossd at gmail.com> wrote:
> I guess it's potentially faster if you don't have to swab
> bytes between similar architectures?
The "potential" speedup is completely superficial, and the N^2
complexities make the code hard to test and hard to maintain. It's
better to do something simple and correct, and then you can leave it
untouched for a decade.
I implemented the byte-order handling code in the GNU BFD library back
in the early '90s. We picked up every integer as a series of unsigned
byte accesses and shifted them and added them, even when the byte order
of the data matched the byte order of the machine. Some machines can do
unaligned 4- or 8-byte fetches and some can't. The people who design
object file formats (or packet formats) don't always align things on the
boundaries that your hardware prefers. We wrote simple, easy to test
code that would and did run on ANY machine. We did the same for stores
as well as loads.
Every data structure had two representations: The external one, defined
by a struct full of unsigned char arrays; and the internal one, in
native data formats. For each data format, we wrote a trivial routine
to convert the external format to the internal; and its inverse. These
called a series of the lower level pick-up-bytes-in-particular-order
routines, one call per struct member. None of this was even inlined at
the time.
I never measured the overhead of these get- or put- routines as being
above 1% or 2% in the execution of the whole program (e.g. the GNU
linker).
We had enough complexity to deal with already, because every vendor made
their own slightly different version of COFF or ELF or a.out object file
formats. Some of these were in different byte orders. Some truly
insane vendors had the object file HEADERS in one byte order and the
actual binaries in a different byte order! We made a library that could
read and write them all -- and manage their symbol tables -- and even
link them together from a variety of formats and write the resulting
binary in a different format. This was all part of making the GNU
compilers into cross-compilers, in which your "host" byte order and
object file format are completely orthogonal to your "target" byte order
and object file format. We then built test suites that built the same
test code on a dozen host systems and made sure that all the resulting
binaries for target system "X" were bit-for-bit identical. Building in
those capabilities, and that level of reliability, was much more
important than any 2% speedup.
Premature optimization is the root of much evil.
John
From jon at fourwinds.com Tue Jan 26 11:38:40 2021
From: jon at fourwinds.com (Jon Steinhart)
Date: Mon, 25 Jan 2021 17:38:40 -0800
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <CAFH29to9GaKVxUXw8uwbeMAcF6izD=8gqhqROzCOSEA5xOA5aQ@mail.gmail.com>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
<202101242045.10OKjDvA964774@darkstar.fourwinds.com>
<20210124211100.GI21030@mcvoy.com>
<202101242114.10OLEYGk966708@darkstar.fourwinds.com>
<20210124212525.GJ21030@mcvoy.com>
<CAEoi9W5=toe-bb+6-zC0odkx4_C4X4FZpK4+ZJTAqCKGOCXP7w@mail.gmail.com>
<202101242333.10ONXjcI974038@darkstar.fourwinds.com>
<fc52a1a1-2136-ae39-110c-93a38e73ff94@bitsavers.org>
<202101250021.10P0L3Z2976588@darkstar.fourwinds.com>
<CAC20D2OhTW+eebyub7dVMBGZy1zoOja=ojGB_=TOjgB0wEJdHQ@mail.gmail.com>
<6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org>
<CAFH29to9GaKVxUXw8uwbeMAcF6izD=8gqhqROzCOSEA5xOA5aQ@mail.gmail.com>
Message-ID: <202101260138.10Q1ceo21049597@darkstar.fourwinds.com>
Richard Salz writes:
>
> A couple of updates.
>
> At a Usenix (Portland?) dmr had a keynote and he interviewed himself.Q:
> "What do you think of X?" A: "Sometimes when you fill a vacuum it still
> sucks." Maybe Rob said it earlier, but that was the first time I heard it
> publically.
Just in case someone has been living under a rock and hasn't heard this one...
We're lucky that Don Knuth had nothing to do with X?
Why?
He would have called it ecccchhhhh.
From m.douglas.mcilroy at dartmouth.edu Tue Jan 26 12:06:02 2021
From: m.douglas.mcilroy at dartmouth.edu (M Douglas McIlroy)
Date: Mon, 25 Jan 2021 21:06:02 -0500
Subject: [TUHS] Favorite unix design principles?
In-Reply-To: <alpine.DEB.2.21.2101250729510.22271@sd-119843.dedibox.fr>
References: <CAEuQd1D00TvjQWfSYvawS45qMnG_cThdHig2rFco+emzxEYsQA@mail.gmail.com>
<alpine.DEB.2.21.2101250729510.22271@sd-119843.dedibox.fr>
Message-ID: <CAKH6PiWY3ggz7Rv6Y0mNr_MH5+z7duHhFH9xf-rKgsvhQvCWgA@mail.gmail.com>
It might be interesting to compare your final list with the two lists in
the 1978 special issue of the BSTJ--one in the Foreword, the other in the
revised version of the Ritchi/Thompson article from the CACM. How have
perceptions or values changed over time?
Doug
On Mon, Jan 25, 2021 at 7:32 AM Steve Nickolas <usotsuki at buric.co> wrote:
> On Mon, 25 Jan 2021, Tyler Adams wrote:
>
> > I'm writing about my 5 favorite unix design principles on my blog this
> > week, and it got me wondering what others' favorite unix design
> principles
> > are? For reference, mine are:
> >
> > - Rule of Separation (from TAOUP <
> http://catb.org/~esr/writings/taoup/html/>
> > )
> > - Let the Machine Do the Dirty Work (from Elements of Programming Style)
> > - Rule of Silence (from TAOUP <http://catb.org/~esr/writings/taoup/html/
> >)
> > - Data Dominates (Rob Pike #5)
> > - The SPOT (Single Point of Truth) Rule (from TAOUP
> > <http://catb.org/~esr/writings/taoup/html/>)
> >
> > Tyler
> >
>
> 1. Pipes
> 2. Text as the preferred format for input and output
> 3. 'Most everything as a file
> 4. The idea of simple tools that are optimized for a single task
> 5. A powerful scripting language built into the system that, combined with
> 1-4, makes writing new tools heaps easier.
>
> -uso.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210125/ffd1b6f9/attachment.htm>
From cowan at ccil.org Tue Jan 26 12:45:06 2021
From: cowan at ccil.org (John Cowan)
Date: Mon, 25 Jan 2021 21:45:06 -0500
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <CAFH29to9GaKVxUXw8uwbeMAcF6izD=8gqhqROzCOSEA5xOA5aQ@mail.gmail.com>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
<202101242045.10OKjDvA964774@darkstar.fourwinds.com>
<20210124211100.GI21030@mcvoy.com>
<202101242114.10OLEYGk966708@darkstar.fourwinds.com>
<20210124212525.GJ21030@mcvoy.com>
<CAEoi9W5=toe-bb+6-zC0odkx4_C4X4FZpK4+ZJTAqCKGOCXP7w@mail.gmail.com>
<202101242333.10ONXjcI974038@darkstar.fourwinds.com>
<fc52a1a1-2136-ae39-110c-93a38e73ff94@bitsavers.org>
<202101250021.10P0L3Z2976588@darkstar.fourwinds.com>
<CAC20D2OhTW+eebyub7dVMBGZy1zoOja=ojGB_=TOjgB0wEJdHQ@mail.gmail.com>
<6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org>
<CAFH29to9GaKVxUXw8uwbeMAcF6izD=8gqhqROzCOSEA5xOA5aQ@mail.gmail.com>
Message-ID: <CAD2gp_RsiayPg+xyEYK7AwrkuO0NS7f4o4pZ6JwVPuaoBWDdTA@mail.gmail.com>
On Mon, Jan 25, 2021 at 10:56 AM Richard Salz <rich.salz at gmail.com> wrote:
> DCE RPC was based on Apollo NCS which was a very elegant RPC system built
> on UDP. It had no XDR because it was "reader makes it right" and datatypes
> were tagged.
>
I've been messing around with X.680, aka ASN/1. Its reputation for
horrible evilness, I find, primarily comes from the Packed Encoding Rules
and the interface with statically typed languages, both of which require
dealing with the schema language programmatically. But if you want to
drive it from a dynamically typed language, it's dirt simple: to write, see
what data type you have, output a type and length and value (or type and
value and terminator), and there you are.
I've got a little back burner project called Twinjo that provides two
equivalent serialization formats: X.680 and an extensible S-expression
format. If anyone's interested, you can read about it at <
https://github.com/johnwcowan/r7rs-work/edit/master/Twinjo.md>.
John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org
He who would do good to another must do it in Minute Particulars;
General Good is the plea of the scoundrel, hypocrite and flatterer:
For Art and Science cannot exist but in minutely organized Particulars.
--William Blake, il miglior fabbro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210125/3b18ee16/attachment.htm>
From usotsuki at buric.co Tue Jan 26 12:53:44 2021
From: usotsuki at buric.co (Steve Nickolas)
Date: Mon, 25 Jan 2021 21:53:44 -0500 (EST)
Subject: [TUHS] Favorite unix design principles?
In-Reply-To: <CAKH6PiWY3ggz7Rv6Y0mNr_MH5+z7duHhFH9xf-rKgsvhQvCWgA@mail.gmail.com>
References: <CAEuQd1D00TvjQWfSYvawS45qMnG_cThdHig2rFco+emzxEYsQA@mail.gmail.com>
<alpine.DEB.2.21.2101250729510.22271@sd-119843.dedibox.fr>
<CAKH6PiWY3ggz7Rv6Y0mNr_MH5+z7duHhFH9xf-rKgsvhQvCWgA@mail.gmail.com>
Message-ID: <alpine.DEB.2.21.2101252151210.23533@sd-119843.dedibox.fr>
On Mon, 25 Jan 2021, M Douglas McIlroy wrote:
> It might be interesting to compare your final list with the two lists in
> the 1978 special issue of the BSTJ--one in the Foreword, the other in the
> revised version of the Ritchi/Thompson article from the CACM. How have
> perceptions or values changed over time?
>
> Doug
Funny thing is I came into *x (Solaris, and then Linux) relatively late -
ca. 1997, after I had been using MS-DOS and ProDOS for years, which were
the operating systems I compared it to.
It was because MS-DOS had adopted ideas from Xenix that *x was easier to
acclimate to than other OSes I'd used.
-uso.
From coppero1237 at gmail.com Tue Jan 26 20:22:45 2021
From: coppero1237 at gmail.com (Tyler Adams)
Date: Tue, 26 Jan 2021 12:22:45 +0200
Subject: [TUHS] Favorite unix design principles?
In-Reply-To: <CAKH6PiWY3ggz7Rv6Y0mNr_MH5+z7duHhFH9xf-rKgsvhQvCWgA@mail.gmail.com>
References: <CAEuQd1D00TvjQWfSYvawS45qMnG_cThdHig2rFco+emzxEYsQA@mail.gmail.com>
<alpine.DEB.2.21.2101250729510.22271@sd-119843.dedibox.fr>
<CAKH6PiWY3ggz7Rv6Y0mNr_MH5+z7duHhFH9xf-rKgsvhQvCWgA@mail.gmail.com>
Message-ID: <CAEuQd1DO1_gv-ByrM91DLQ3kqm7pap9bK+4JsQKJoNqD1Z-GZw@mail.gmail.com>
Looking at the 1978 list, the last one really stands out:
"Use tools in preference to unskilled help to lighten a programming task"
-- The concept of unskilled help for a programming task...doesn't really
exist in 2020. The only special case is doing unskilled labor yourself.
What unskilled tasks did people used to do back in the day?
Tyler
On Tue, Jan 26, 2021 at 4:07 AM M Douglas McIlroy <
m.douglas.mcilroy at dartmouth.edu> wrote:
> It might be interesting to compare your final list with the two lists in
> the 1978 special issue of the BSTJ--one in the Foreword, the other in the
> revised version of the Ritchi/Thompson article from the CACM. How have
> perceptions or values changed over time?
>
> Doug
>
>
> On Mon, Jan 25, 2021 at 7:32 AM Steve Nickolas <usotsuki at buric.co> wrote:
>
>> On Mon, 25 Jan 2021, Tyler Adams wrote:
>>
>> > I'm writing about my 5 favorite unix design principles on my blog this
>> > week, and it got me wondering what others' favorite unix design
>> principles
>> > are? For reference, mine are:
>> >
>> > - Rule of Separation (from TAOUP <
>> http://catb.org/~esr/writings/taoup/html/>
>> > )
>> > - Let the Machine Do the Dirty Work (from Elements of Programming Style)
>> > - Rule of Silence (from TAOUP <
>> http://catb.org/~esr/writings/taoup/html/>)
>> > - Data Dominates (Rob Pike #5)
>> > - The SPOT (Single Point of Truth) Rule (from TAOUP
>> > <http://catb.org/~esr/writings/taoup/html/>)
>> >
>> > Tyler
>> >
>>
>> 1. Pipes
>> 2. Text as the preferred format for input and output
>> 3. 'Most everything as a file
>> 4. The idea of simple tools that are optimized for a single task
>> 5. A powerful scripting language built into the system that, combined
>> with
>> 1-4, makes writing new tools heaps easier.
>>
>> -uso.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210126/4b86c1d5/attachment.htm>
From jpl.jpl at gmail.com Tue Jan 26 22:26:41 2021
From: jpl.jpl at gmail.com (John P. Linderman)
Date: Tue, 26 Jan 2021 07:26:41 -0500
Subject: [TUHS] Favorite unix design principles?
In-Reply-To: <CAEuQd1DO1_gv-ByrM91DLQ3kqm7pap9bK+4JsQKJoNqD1Z-GZw@mail.gmail.com>
References: <CAEuQd1D00TvjQWfSYvawS45qMnG_cThdHig2rFco+emzxEYsQA@mail.gmail.com>
<alpine.DEB.2.21.2101250729510.22271@sd-119843.dedibox.fr>
<CAKH6PiWY3ggz7Rv6Y0mNr_MH5+z7duHhFH9xf-rKgsvhQvCWgA@mail.gmail.com>
<CAEuQd1DO1_gv-ByrM91DLQ3kqm7pap9bK+4JsQKJoNqD1Z-GZw@mail.gmail.com>
Message-ID: <CAC0cEp_U1n5PzWi6ny-zAZS63Cwc4Bbx5wBXX-va+SOPboULXQ@mail.gmail.com>
On Tue, Jan 26, 2021 at 5:24 AM Tyler Adams <coppero1237 at gmail.com> wrote:
> Looking at the 1978 list, the last one really stands out:
>
> "Use tools in preference to unskilled help to lighten a programming task"
> -- The concept of unskilled help for a programming task...doesn't really
> exist in 2020. The only special case is doing unskilled labor yourself.
> What unskilled tasks did people used to do back in the day?
>
> Tyler
>
>>
>>>
Drifting far off topic, but when I was programming part time for the MIT
administration in the late 60's, we wrote a small language for generating
reports from tape input. It did things like reading a record ahead, so it
could detect the last and first records having some (presumably sorted)
value, making it easy to do headers and summaries. Many report requests
from assorted administrative offices could be handled by our operators, who
had no formal programming experience. Occasionally they'd get bitten by a
request like "Give me a count of freshman and sophomores in course 18" and
they'd do the equivalent of "class == freshmen && class == sophomore",
paralleling the spoken request, and then wonder why nothing got selected.
All in all, though, it took a huge load off the skilled programmers, and
reduced the time to respond to simple requests. When I joined the Labs in
1973, we had no operators, no administrative report requests, and most
co-workers were proficient programmers. But the administrative work
environment at MIT was more representative of "the real world" than the
Labs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210126/0a9e8d59/attachment.htm>
From clemc at ccc.com Wed Jan 27 01:23:01 2021
From: clemc at ccc.com (Clem Cole)
Date: Tue, 26 Jan 2021 10:23:01 -0500
Subject: [TUHS] Favorite unix design principles?
In-Reply-To: <CAEuQd1DO1_gv-ByrM91DLQ3kqm7pap9bK+4JsQKJoNqD1Z-GZw@mail.gmail.com>
References: <CAEuQd1D00TvjQWfSYvawS45qMnG_cThdHig2rFco+emzxEYsQA@mail.gmail.com>
<alpine.DEB.2.21.2101250729510.22271@sd-119843.dedibox.fr>
<CAKH6PiWY3ggz7Rv6Y0mNr_MH5+z7duHhFH9xf-rKgsvhQvCWgA@mail.gmail.com>
<CAEuQd1DO1_gv-ByrM91DLQ3kqm7pap9bK+4JsQKJoNqD1Z-GZw@mail.gmail.com>
Message-ID: <CAC20D2NkE0aNWeVUayYXhR2vEhY-0D4g=-N2PmUx+HhptrccGA@mail.gmail.com>
On Tue, Jan 26, 2021 at 5:23 AM Tyler Adams <coppero1237 at gmail.com> wrote:
> Looking at the 1978 list, the last one really stands out:
>
> "Use tools in preference to unskilled help to lighten a programming task"
> -- The concept of unskilled help for a programming task...doesn't really
> exist in 2020. The only special case is doing unskilled labor yourself.
> What unskilled tasks did people used to do back in the day?
>
> Tyler
>
I've often wondered if this is the source of the infamous putdown: When you
operate in such or such manner,* "you could/should be replaced with a shell
script."*
á§
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210126/b40f88c3/attachment.htm>
From nikke.karlsson at gmail.com Wed Jan 27 02:00:15 2021
From: nikke.karlsson at gmail.com (Niklas Karlsson)
Date: Tue, 26 Jan 2021 17:00:15 +0100
Subject: [TUHS] Favorite unix design principles?
In-Reply-To: <CAC20D2NkE0aNWeVUayYXhR2vEhY-0D4g=-N2PmUx+HhptrccGA@mail.gmail.com>
References: <CAEuQd1D00TvjQWfSYvawS45qMnG_cThdHig2rFco+emzxEYsQA@mail.gmail.com>
<alpine.DEB.2.21.2101250729510.22271@sd-119843.dedibox.fr>
<CAKH6PiWY3ggz7Rv6Y0mNr_MH5+z7duHhFH9xf-rKgsvhQvCWgA@mail.gmail.com>
<CAEuQd1DO1_gv-ByrM91DLQ3kqm7pap9bK+4JsQKJoNqD1Z-GZw@mail.gmail.com>
<CAC20D2NkE0aNWeVUayYXhR2vEhY-0D4g=-N2PmUx+HhptrccGA@mail.gmail.com>
Message-ID: <CAK6BEgenb62mOzB8YmexvpdQqC0t2+Mar56=Gj5n8R16E-tPaA@mail.gmail.com>
Den tis 26 jan. 2021 kl 16:24 skrev Clem Cole <clemc at ccc.com>:
>
>
> On Tue, Jan 26, 2021 at 5:23 AM Tyler Adams <coppero1237 at gmail.com> wrote:
>
>> Looking at the 1978 list, the last one really stands out:
>>
>> "Use tools in preference to unskilled help to lighten a programming task"
>> -- The concept of unskilled help for a programming task...doesn't really
>> exist in 2020. The only special case is doing unskilled labor yourself.
>> What unskilled tasks did people used to do back in the day?
>>
>> Tyler
>>
> I've often wondered if this is the source of the infamous putdown: When
> you operate in such or such manner,* "you could/should be replaced with a
> shell script."*
>
The version I've heard is even "... a very small shell script".
Niklas
> á§
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210126/1245edbb/attachment.htm>
From henry.r.bent at gmail.com Wed Jan 27 02:05:19 2021
From: henry.r.bent at gmail.com (Henry Bent)
Date: Tue, 26 Jan 2021 11:05:19 -0500
Subject: [TUHS] System V Release 2, adding swap?
In-Reply-To: <E1l444e-0002Mj-N4@tanda>
References: <E1l444e-0002Mj-N4@tanda>
Message-ID: <CAEdTPBfZRVVQzmT28MoLsGpz1z-kNea5n3zpupvzn5Ts=Dg6Qw@mail.gmail.com>
On Mon, 25 Jan 2021 at 11:02, Arnold Robbins <arnold at skeeve.com> wrote:
> Hi.
>
> Does anyone know how to add swap space on a System V Release 2 system?
> In particular, on an emulated AT&T 3B1. The kernel is S5R1 or S5R2
> vintage.
>
> I don't see any commands with 'swap' in their names.
A little bit of Google Groups trawling turned up this:
https://groups.google.com/g/comp.sys.att/c/8XLILI3K8-Y/m/VxVMJNdt9NQJ
But I don't have one of those systems, so I have no way to verify.
-Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210126/d43592dd/attachment.htm>
From athornton at gmail.com Wed Jan 27 02:13:53 2021
From: athornton at gmail.com (Adam Thornton)
Date: Tue, 26 Jan 2021 09:13:53 -0700
Subject: [TUHS] Favorite unix design principles?
In-Reply-To: <CAK6BEgenb62mOzB8YmexvpdQqC0t2+Mar56=Gj5n8R16E-tPaA@mail.gmail.com>
References: <CAEuQd1D00TvjQWfSYvawS45qMnG_cThdHig2rFco+emzxEYsQA@mail.gmail.com>
<alpine.DEB.2.21.2101250729510.22271@sd-119843.dedibox.fr>
<CAKH6PiWY3ggz7Rv6Y0mNr_MH5+z7duHhFH9xf-rKgsvhQvCWgA@mail.gmail.com>
<CAEuQd1DO1_gv-ByrM91DLQ3kqm7pap9bK+4JsQKJoNqD1Z-GZw@mail.gmail.com>
<CAC20D2NkE0aNWeVUayYXhR2vEhY-0D4g=-N2PmUx+HhptrccGA@mail.gmail.com>
<CAK6BEgenb62mOzB8YmexvpdQqC0t2+Mar56=Gj5n8R16E-tPaA@mail.gmail.com>
Message-ID: <CAP2nic0ksEa1otscMru4Hymqm+ji6GijtgNeGAsOL+TLM6N67g@mail.gmail.com>
To be fair I've made a decent career spanning five calendar decades so far
out of replacing the thing I started out doing with a shell script (in
recent decades, more often Perl, then Python), so it's not the _worst_ job
advice....
On Tue, Jan 26, 2021 at 9:01 AM Niklas Karlsson <nikke.karlsson at gmail.com>
wrote:
>
>
> Den tis 26 jan. 2021 kl 16:24 skrev Clem Cole <clemc at ccc.com>:
>
>>
>>
>> On Tue, Jan 26, 2021 at 5:23 AM Tyler Adams <coppero1237 at gmail.com>
>> wrote:
>>
>>> Looking at the 1978 list, the last one really stands out:
>>>
>>> "Use tools in preference to unskilled help to lighten a programming
>>> task" -- The concept of unskilled help for a programming task...doesn't
>>> really exist in 2020. The only special case is doing unskilled labor
>>> yourself. What unskilled tasks did people used to do back in the day?
>>>
>>> Tyler
>>>
>> I've often wondered if this is the source of the infamous putdown: When
>> you operate in such or such manner,* "you could/should be replaced with
>> a shell script."*
>>
>
> The version I've heard is even "... a very small shell script".
>
> Niklas
>
>> á§
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210126/dee201ef/attachment.htm>
From sauer at technologists.com Wed Jan 27 02:46:56 2021
From: sauer at technologists.com (Charles H. Sauer)
Date: Tue, 26 Jan 2021 10:46:56 -0600
Subject: [TUHS] System V Release 2, adding swap?
In-Reply-To: <CAEdTPBfZRVVQzmT28MoLsGpz1z-kNea5n3zpupvzn5Ts=Dg6Qw@mail.gmail.com>
References: <E1l444e-0002Mj-N4@tanda>
<CAEdTPBfZRVVQzmT28MoLsGpz1z-kNea5n3zpupvzn5Ts=Dg6Qw@mail.gmail.com>
Message-ID: <8a17ae54-1b00-e9f7-ea44-763c29c4023f@technologists.com>
On 1/26/2021 10:05 AM, Henry Bent wrote:
> On Mon, 25 Jan 2021 at 11:02, Arnold Robbins <arnold at skeeve.com
> <mailto:arnold at skeeve.com>> wrote:
>
> Hi.
>
> Does anyone know how to add swap space on a System V Release 2 system?
> In particular, on an emulated AT&T 3B1. The kernel is S5R1 or S5R2
> vintage.
>
> I don't see any commands with 'swap' in their names.
>
> A little bit of Google Groups trawling turned up this:
> https://groups.google.com/g/comp.sys.att/c/8XLILI3K8-Y/m/VxVMJNdt9NQJ
> <https://groups.google.com/g/comp.sys.att/c/8XLILI3K8-Y/m/VxVMJNdt9NQJ>
>
> But I don't have one of those systems, so I have no way to verify.
>
> -Henry
I don't know about 3B versions, but on Dell SVR4 on 86Box
(https://notes.technologists.com/notes/2021/01/19/koko-dell-unix-sustainable/)
I see
/ # apropos swap
swap(1m): swap - swap administrative interface
swapctl(2): swapctl - manage swap space
...
I've never tried to adjust swap, just trust that our install did the
right thing. On this system, freshly booted, with 32M memory and 5G
"disk", I see
/ # swap -l
path dev swaplo blocks free
/dev/swap 0,2 0 98784 90960
Here's the beginning of man swap:
NAME
swap - swap administrative interface
SYNOPSIS
/usr/sbin/swap -a swapname swaplow swaplen
/usr/sbin/swap -d swapname swaplow
/usr/sbin/swap -l [ -s ]
/usr/sbin/swap -s
DESCRIPTION
swap provides a method of adding, deleting, and monitoring the system
swap areas used by the memory manager. The following options are
recognized:
-a Add the specified swap area. swapname is the name of the block
special partition, e.g., /dev/dsk/0s2 or a regular file. swaplow
is the offset in 512-byte blocks into the partition where the
swap area should begin. swaplen is the length of the swap area
in 512-byte blocks. This option can only be used by the super-
user. If additional swap areas are added, it is normally done
during the system start up routine /etc/rc2.d when going into
multi-user mode.
...
Charlie
--
voice: +1.512.784.7526 e-mail: sauer at technologists.com
fax: +1.512.346.5240 Web: https://technologists.com/sauer/
Facebook/Google/Skype/Twitter: CharlesHSauer
From arnold at skeeve.com Wed Jan 27 04:33:31 2021
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Tue, 26 Jan 2021 11:33:31 -0700
Subject: [TUHS] System V Release 2, adding swap?
In-Reply-To: <CAEdTPBfZRVVQzmT28MoLsGpz1z-kNea5n3zpupvzn5Ts=Dg6Qw@mail.gmail.com>
References: <E1l444e-0002Mj-N4@tanda>
<CAEdTPBfZRVVQzmT28MoLsGpz1z-kNea5n3zpupvzn5Ts=Dg6Qw@mail.gmail.com>
Message-ID: <202101261833.10QIXVkq022332@freefriends.org>
Hi.
Henry Bent <henry.r.bent at gmail.com> wrote:
> On Mon, 25 Jan 2021 at 11:02, Arnold Robbins <arnold at skeeve.com> wrote:
>
> > Hi.
> >
> > Does anyone know how to add swap space on a System V Release 2 system?
> > In particular, on an emulated AT&T 3B1. The kernel is S5R1 or S5R2
> > vintage.
> >
> > I don't see any commands with 'swap' in their names.
>
>
> A little bit of Google Groups trawling turned up this:
> https://groups.google.com/g/comp.sys.att/c/8XLILI3K8-Y/m/VxVMJNdt9NQJ
That's very helpful!
> But I don't have one of those systems, so I have no way to verify.
But I do - in emulation. I will try this out shortly.
Thanks!
Arnold
From arnold at skeeve.com Wed Jan 27 04:43:32 2021
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Tue, 26 Jan 2021 11:43:32 -0700
Subject: [TUHS] System V Release 2, adding swap?
In-Reply-To: <8a17ae54-1b00-e9f7-ea44-763c29c4023f@technologists.com>
References: <E1l444e-0002Mj-N4@tanda>
<CAEdTPBfZRVVQzmT28MoLsGpz1z-kNea5n3zpupvzn5Ts=Dg6Qw@mail.gmail.com>
<8a17ae54-1b00-e9f7-ea44-763c29c4023f@technologists.com>
Message-ID: <202101261843.10QIhW6A023727@freefriends.org>
"Charles H. Sauer" <sauer at technologists.com> wrote:
> I don't know about 3B versions, but on Dell SVR4 on 86Box
> (https://notes.technologists.com/notes/2021/01/19/koko-dell-unix-sustainable/)
> I see
> / # apropos swap
> swap(1m): swap - swap administrative interface
> swapctl(2): swapctl - manage swap space
> ...
Yes - I was looking for something like that. SVR4 is after a lot of
additional kernel technology from Sun. The S5R2 vintage system seems to
have had the swap device configured in at kernel compile time. :-(
Thanks,
Arnold
From dario at darioniedermann.it Wed Jan 27 01:17:51 2021
From: dario at darioniedermann.it (Dario Niedermann)
Date: Tue, 26 Jan 2021 16:17:51 +0100
Subject: [TUHS] Three-quarters to the next Epoch
In-Reply-To: <YA0JThfLwsOetEie@alice>
References: <alpine.BSF.2.21.9999.2101240837350.36435@aneurin.horsfall.org>
<20210124045233.335C79C669@minnie.tuhs.org>
<YA0JThfLwsOetEie@alice>
Message-ID: <20210126151751.GF2973@darioniedermann.it>
Il 24/01/2021 alle 06:44, Anthony Martin ha scritto:
>% for(i in `{seq 0 2 8}) date -u 0x$i^0000000
I give up... what interpreter is this?
--
Dario Niedermann -:- finger my email address for PGP key, etc.
Also on the Internet at: <gopher://darioniedermann.it/>
<https://www.darioniedermann.it/>
From crossd at gmail.com Wed Jan 27 08:40:17 2021
From: crossd at gmail.com (Dan Cross)
Date: Tue, 26 Jan 2021 17:40:17 -0500
Subject: [TUHS] Three-quarters to the next Epoch
In-Reply-To: <20210126151751.GF2973@darioniedermann.it>
References: <alpine.BSF.2.21.9999.2101240837350.36435@aneurin.horsfall.org>
<20210124045233.335C79C669@minnie.tuhs.org> <YA0JThfLwsOetEie@alice>
<20210126151751.GF2973@darioniedermann.it>
Message-ID: <CAEoi9W67vCO0pEQptF-1zmFjCwOCRe-vDZuJxGSCsE51-nTFEw@mail.gmail.com>
Looks like `rc` to me.
On Tue, Jan 26, 2021 at 5:32 PM Dario Niedermann <dario at darioniedermann.it>
wrote:
> Il 24/01/2021 alle 06:44, Anthony Martin ha scritto:
>
> >% for(i in `{seq 0 2 8}) date -u 0x$i^0000000
>
> I give up... what interpreter is this?
>
> --
> Dario Niedermann -:- finger my email address for PGP key, etc.
>
> Also on the Internet at: <gopher://darioniedermann.it/>
> <https://www.darioniedermann.it/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210126/224c8234/attachment.htm>
From steffen at sdaoden.eu Wed Jan 27 08:43:00 2021
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Tue, 26 Jan 2021 23:43:00 +0100
Subject: [TUHS] Three-quarters to the next Epoch
In-Reply-To: <20210126151751.GF2973@darioniedermann.it>
References: <alpine.BSF.2.21.9999.2101240837350.36435@aneurin.horsfall.org>
<20210124045233.335C79C669@minnie.tuhs.org> <YA0JThfLwsOetEie@alice>
<20210126151751.GF2973@darioniedermann.it>
Message-ID: <20210126224300.HQ1NP%steffen@sdaoden.eu>
Dario Niedermann wrote in
<20210126151751.GF2973 at darioniedermann.it>:
|Il 24/01/2021 alle 06:44, Anthony Martin ha scritto:
|
|>% for(i in `{seq 0 2 8}) date -u 0x$i^0000000
|
|I give up... what interpreter is this?
rc as of Plan9 / 9front.
Also available as a Unix port, somewhere on github.
--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 rich.salz at gmail.com Wed Jan 27 09:18:53 2021
From: rich.salz at gmail.com (Richard Salz)
Date: Tue, 26 Jan 2021 18:18:53 -0500
Subject: [TUHS] Three-quarters to the next Epoch
In-Reply-To: <20210126224300.HQ1NP%steffen@sdaoden.eu>
References: <alpine.BSF.2.21.9999.2101240837350.36435@aneurin.horsfall.org>
<20210124045233.335C79C669@minnie.tuhs.org> <YA0JThfLwsOetEie@alice>
<20210126151751.GF2973@darioniedermann.it>
<20210126224300.HQ1NP%steffen@sdaoden.eu>
Message-ID: <CAFH29try_PaVuq-rVFGXj5-O8VOXAVxzB80XAe7sQWxqErgenA@mail.gmail.com>
> rc as of Plan9 / 9front.
> Also available as a Unix port, somewhere on github.
https://github.com/rakitzis/rc; GitHub search for "Byron rc" finds a few
forks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210126/2e816686/attachment.htm>
From john at jfloren.net Wed Jan 27 09:49:00 2021
From: john at jfloren.net (John Floren)
Date: Tue, 26 Jan 2021 15:49:00 -0800
Subject: [TUHS] Three-quarters to the next Epoch
In-Reply-To: <CAFH29try_PaVuq-rVFGXj5-O8VOXAVxzB80XAe7sQWxqErgenA@mail.gmail.com>
References: <alpine.BSF.2.21.9999.2101240837350.36435@aneurin.horsfall.org>
<20210124045233.335C79C669@minnie.tuhs.org> <YA0JThfLwsOetEie@alice>
<20210126151751.GF2973@darioniedermann.it>
<20210126224300.HQ1NP%steffen@sdaoden.eu>
<CAFH29try_PaVuq-rVFGXj5-O8VOXAVxzB80XAe7sQWxqErgenA@mail.gmail.com>
Message-ID: <CAL4LZyhEY1_vqYan9ExcnPhCOFAY7fzf-j-Nt-8AYfyjOO7NCA@mail.gmail.com>
On Tue, Jan 26, 2021 at 3:19 PM Richard Salz <rich.salz at gmail.com> wrote:
>
> > rc as of Plan9 / 9front.
> > Also available as a Unix port, somewhere on github.
>
> https://github.com/rakitzis/rc; GitHub search for "Byron rc" finds a few forks.
>
Plan9port also ships a pretty good-sized userspace of Plan 9 tools,
including rc. https://github.com/9fans/plan9port
From jsteve at superglobalmegacorp.com Wed Jan 27 10:50:52 2021
From: jsteve at superglobalmegacorp.com (Jason Stevens)
Date: Wed, 27 Jan 2021 08:50:52 +0800
Subject: [TUHS] System V Release 2, adding swap?
Message-ID: <0F0B9BFC06289346B88512B91E55670D300C@EXCHANGE>
SIMH has 3b2 emulation...
Much of the work was documented here:
https://loomcom.com/3b2/emulator.html
<https://loomcom.com/3b2/emulator.html>
-----Original Message-----
From: Henry Bent [SMTP:henry.r.bent at gmail.com]
Sent: Wednesday, January 27, 2021 12:05 AM
To: Arnold Robbins
Cc: The Eunuchs Hysterical Society
Subject: Re: [TUHS] System V Release 2, adding swap?
On Mon, 25 Jan 2021 at 11:02, Arnold Robbins < arnold at skeeve.com
<mailto:arnold at skeeve.com> > wrote:
Hi.
Does anyone know how to add swap space on a System V Release
2 system?
In particular, on an emulated AT&T 3B1. The kernel is S5R1
or S5R2
vintage.
I don't see any commands with 'swap' in their names.
A little bit of Google Groups trawling turned up this:
https://groups.google.com/g/comp.sys.att/c/8XLILI3K8-Y/m/VxVMJNdt9NQJ
<https://groups.google.com/g/comp.sys.att/c/8XLILI3K8-Y/m/VxVMJNdt9NQJ>
But I don't have one of those systems, so I have no way to verify.
-Henry
From lm at mcvoy.com Wed Jan 27 10:40:36 2021
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 26 Jan 2021 16:40:36 -0800
Subject: [TUHS] System V Release 2, adding swap?
In-Reply-To: <0F0B9BFC06289346B88512B91E55670D300C@EXCHANGE>
References: <0F0B9BFC06289346B88512B91E55670D300C@EXCHANGE>
Message-ID: <20210127004036.GE17488@mcvoy.com>
On Wed, Jan 27, 2021 at 08:50:52AM +0800, Jason Stevens wrote:
> SIMH has 3b2 emulation...
I think he was looking for 3b1 which was a 68K of some sort. The 3b2
was some weird processor out of labs. Found it:
https://en.wikipedia.org/wiki/Bellmac_32
From stu at remphrey.net Wed Jan 27 13:04:33 2021
From: stu at remphrey.net (Stuart Remphrey)
Date: Wed, 27 Jan 2021 11:04:33 +0800
Subject: [TUHS] The terminal, the console, and the shell - what are they?
In-Reply-To: <b5007092-a0a7-7358-9e35-6df84742367a@gmail.com>
References: <b5007092-a0a7-7358-9e35-6df84742367a@gmail.com>
Message-ID: <CAD0_1c=26S1L9gSNCHSQAaR1u+O33QLNho26eNzVOC6B32TJkw@mail.gmail.com>
Some of the references are interesting, too, like Terminal Latency:
https://danluu.com/term-latency/
*(though more like terminal emulator latency, and perhaps not so historic
as-in the H in TUHS; but still some interesting results.)*
On Sun, 24 Jan 2021, 09:28 Will Senn, <will.senn at gmail.com> wrote:
> All,
>
> I came across this note on vermaden's valuable news blog and thought y'all
> might enjoy it - it's not pure unix, but it's got a lot of crossover. The
> history is interesting and to us relative newbs, informative. I can't
> confirm its accuracy on the history side of things, but I'm sure you can :).
>
>
> http://unixsheikh.com/articles/the-terminal-the-console-and-the-shell-what-are-they.html
>
> Later,
>
> Will
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210127/2b4592cf/attachment.htm>
From dave at horsfall.org Wed Jan 27 13:11:26 2021
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 27 Jan 2021 14:11:26 +1100 (EST)
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <202101260138.10Q1ceo21049597@darkstar.fourwinds.com>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
<202101242045.10OKjDvA964774@darkstar.fourwinds.com>
<20210124211100.GI21030@mcvoy.com>
<202101242114.10OLEYGk966708@darkstar.fourwinds.com>
<20210124212525.GJ21030@mcvoy.com>
<CAEoi9W5=toe-bb+6-zC0odkx4_C4X4FZpK4+ZJTAqCKGOCXP7w@mail.gmail.com>
<202101242333.10ONXjcI974038@darkstar.fourwinds.com>
<fc52a1a1-2136-ae39-110c-93a38e73ff94@bitsavers.org>
<202101250021.10P0L3Z2976588@darkstar.fourwinds.com>
<CAC20D2OhTW+eebyub7dVMBGZy1zoOja=ojGB_=TOjgB0wEJdHQ@mail.gmail.com>
<6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org>
<CAFH29to9GaKVxUXw8uwbeMAcF6izD=8gqhqROzCOSEA5xOA5aQ@mail.gmail.com>
<202101260138.10Q1ceo21049597@darkstar.fourwinds.com>
Message-ID: <alpine.BSF.2.21.9999.2101271354580.36435@aneurin.horsfall.org>
On Mon, 25 Jan 2021, Jon Steinhart wrote:
> We're lucky that Don Knuth had nothing to do with X?
>
> Why?
>
> He would have called it ecccchhhhh.
An oldie but a goodie :-)
Heh; at one job I was asked whether I knew X; I answered that I could
spell it... $PHB not impressed, but I quickly learned it.
Ugh! I've seen some ugly windowing systems in my time, but X... Heck,
even CP/M had a better system, IIRC. Talk about heavyweight; how many
lines of code were required to write "Hello, world"?
That, BTW, is my benchmark for usability etc. And yes, I've seen all the
jokes; my favourite is manager to worker bee: "I need a program to print
'Hello World' by this afternoon".
-- Dave, who might even tell the OS/360 "EI" story from an old boss
From jon at fourwinds.com Wed Jan 27 13:54:08 2021
From: jon at fourwinds.com (Jon Steinhart)
Date: Tue, 26 Jan 2021 19:54:08 -0800
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <alpine.BSF.2.21.9999.2101271354580.36435@aneurin.horsfall.org>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
<202101242045.10OKjDvA964774@darkstar.fourwinds.com>
<20210124211100.GI21030@mcvoy.com>
<202101242114.10OLEYGk966708@darkstar.fourwinds.com>
<20210124212525.GJ21030@mcvoy.com>
<CAEoi9W5=toe-bb+6-zC0odkx4_C4X4FZpK4+ZJTAqCKGOCXP7w@mail.gmail.com>
<202101242333.10ONXjcI974038@darkstar.fourwinds.com>
<fc52a1a1-2136-ae39-110c-93a38e73ff94@bitsavers.org>
<202101250021.10P0L3Z2976588@darkstar.fourwinds.com>
<CAC20D2OhTW+eebyub7dVMBGZy1zoOja=ojGB_=TOjgB0wEJdHQ@mail.gmail.com>
<6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org>
<CAFH29to9GaKVxUXw8uwbeMAcF6izD=8gqhqROzCOSEA5xOA5aQ@mail.gmail.com>
<202101260138.10Q1ceo21049597@darkstar.fourwinds.com>
<alpine.BSF.2.21.9999.2101271354580.36435@aneurin.horsfall.org>
Message-ID: <202101270354.10R3s8Z01128207@darkstar.fourwinds.com>
Dave Horsfall writes:
>
> Ugh! I've seen some ugly windowing systems in my time, but X... Heck,
> even CP/M had a better system, IIRC. Talk about heavyweight; how many
> lines of code were required to write "Hello, world"?
Well, as I've said before, I think that it's our job as geezers in the
field to help younger folks learn to design and build things in a better
way. Hard to figure out how to do this effectively given the huge push
to turn out lots of low-quality coders so that they don't have to be paid
much above minimum wage.
Found a listing on actual prehistoric line printer paper that seems to
indicate that my copy of the NeWS source, if readable, dates back to 1985.
Don't know what the provenance of this code is; it's not something that I
had around from doing some work on X/NeWS so I'm not sure why I have it.
One of the things that I'll hopefully find during basement archeology is
a paper by Gosling about a tool that we wrote to go along with NeWS. Don't
remember what it was called, but it was a preprocessor that allowed one to
specify things about the (graphics) hardware, and would, for example,
automatically unroll certain loops where there would be a benefit. This
allowed different hardware to be driven efficently from a single hunk of
source code without #ifdefs all over the place.
Also, I do have a couple of notebooks of stuff from V and W that I can scan
in if it's not available elsewhere. Oh, wow, and an original IRIS-4D paper
from Silicon Graphics, and the programming manual for Imagen laser printers.
Jon
From ggm at algebras.org Wed Jan 27 15:15:15 2021
From: ggm at algebras.org (George Michaelson)
Date: Wed, 27 Jan 2021 15:15:15 +1000
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <202101270354.10R3s8Z01128207@darkstar.fourwinds.com>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
<202101242045.10OKjDvA964774@darkstar.fourwinds.com>
<20210124211100.GI21030@mcvoy.com>
<202101242114.10OLEYGk966708@darkstar.fourwinds.com>
<20210124212525.GJ21030@mcvoy.com>
<CAEoi9W5=toe-bb+6-zC0odkx4_C4X4FZpK4+ZJTAqCKGOCXP7w@mail.gmail.com>
<202101242333.10ONXjcI974038@darkstar.fourwinds.com>
<fc52a1a1-2136-ae39-110c-93a38e73ff94@bitsavers.org>
<202101250021.10P0L3Z2976588@darkstar.fourwinds.com>
<CAC20D2OhTW+eebyub7dVMBGZy1zoOja=ojGB_=TOjgB0wEJdHQ@mail.gmail.com>
<6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org>
<CAFH29to9GaKVxUXw8uwbeMAcF6izD=8gqhqROzCOSEA5xOA5aQ@mail.gmail.com>
<202101260138.10Q1ceo21049597@darkstar.fourwinds.com>
<alpine.BSF.2.21.9999.2101271354580.36435@aneurin.horsfall.org>
<202101270354.10R3s8Z01128207@darkstar.fourwinds.com>
Message-ID: <CAKr6gn1K2JfaCV0CtUKALwgqGwDnj7Q8dzbhPWGuPLyp9+DzMA@mail.gmail.com>
>From the side, I remember when X10R4 hit the Decstations we had at
UCL, and how deeply confusing it was having "server" and "client"
inverted for what we all thought we were doing, using the local
workstation as a client to connect to a more distant (across the
machineroom) server like a Pyramid or a bigger Vax.
One of those "ok I see why you did that, but Maaaaan this is inverted
to what I expected" moments.
We'd been coding in SunView quite happily. SunView might have been
proprietary, but we knew what we were doing. Kinda.
NeWS, had this wonderful quality of being code, expressed inside other
code. So, if the two code(s) had been syntactically the same, I
suspect the confusion would have been even worserer. But, as it was
you were reading C, and suddenly, wrapped in what I will morally call
printf() you have "machine(stack) reverse polish notation here because
reasons pop pop pop") sentences. It was .. confusing.
It is not unlike being totally glued to N/Roff, introduced to T/Roff,
then introduced to family (a) of macros, then learn to cope with
family (b), and then have EQN and TBL thrown at you.. meantime..
somebody else passes you {relax} a {relax} TeX book {relax}
I couldn't {relax}
-G
From woods at robohack.ca Wed Jan 27 15:24:30 2021
From: woods at robohack.ca (Greg A. Woods)
Date: Tue, 26 Jan 2021 21:24:30 -0800
Subject: [TUHS] Troff to ps
In-Reply-To: <CAC20D2N9vMnuA9sYK2Bn_sbPySa3bpGfh93JGiQH1_iZn62P9g@mail.gmail.com>
References: <f90685ec-29fa-d7b6-5b4d-a71aaf19476b@gmail.com>
<202007261531.06QFVqZb027062@freefriends.org>
<202007261535.06QFZvLg027250@freefriends.org>
<CAC20D2P-6U7ruF4P1HyeZ=6xcgYYKFjOLXKquzgnMFONGxgC-g@mail.gmail.com>
<202007261711.06QHB07i032409@freefriends.org>
<CAC20D2N9vMnuA9sYK2Bn_sbPySa3bpGfh93JGiQH1_iZn62P9g@mail.gmail.com>
Message-ID: <m1l4dJe-0036xBC@more.local>
[[ sorry for the late reply -- I'm still catching up from a rather
tumultuous summer, fall, and first part of winter ]]
At Sun, 26 Jul 2020 14:03:49 -0400, Clem Cole <clemc at ccc.com> wrote:
Subject: Re: [TUHS] Troff to ps
>
> I wonder if it used troff or ditroff and then what it used for the ps
> engine (probably Ghostscript) and if ditroff, from where the font metric
> tables came?
The "psroff" Arnold referred to was written by Chris Lewis and
translated the C/A/T codes from the original v7 troff into PostScript.
It has nothing to do with the "psroff" that was in the tpscript or
Transcript PostScript add-on packages for ditroff, though it was sort of
created in parallel with what was happening with ditroff, aka DWB,
i.e. the Documenter's Workbench.
Psroff is/was kind of like "thack" and orthogonal to "cat2desk".
Once upon a time there were FAQs published regularly on Usenet where one
could learn all these kinds of things, e.g. the FAQ for comp.text.
Psroff was still very necessary at the time because there were a
plethora of "unix" vendors who were still basically using very early
System V, Xenix, or even 7th Edition licenses, and so there was no hope
of thier users ever getting something so modern and cool as ditroff.
And there was no Groff (though it appeared shortly thereafter).
On example of such a vendor was Spectrix, for whom Chris worked for at
the time he initially created psroff. Spectrix was using Xenix, and I
think even upgraded as far as Xenix V, but it and its customers were far
too cheap for, and more or less going out of business by the time of,
ditroff et al.
Psroff 2.0 was released when I was working with Chris at Elegant
Communications. We were still doing a bit of minor support for the few
remaining Spectrix customers, and had a Spectrix machine to do it with,
but by then it was pretty old and crusty and not of much interest. I
seem to remember we didn't even keep it powered up for most of the time.
As I recall even some of the bigger vendors such as Sun and IBM didn't
offer ditroff in their base OS, but they did offer old troff. Those
were the days of insane AT&T licensing and all the games competitors
played around it.
For what it's worth, back at that time I had a 3B2 at home and I was
running much a more modern version of Unix, complete with ditroff, than
anything we had at work at ECI at the time.
--
Greg A. Woods <gwoods at acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <woods at robohack.ca>
Planix, Inc. <woods at planix.com> Avoncote Farms <woods at avoncote.ca>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP Digital Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210126/2eed2014/attachment.sig>
From gtaylor at tnetconsulting.net Wed Jan 27 15:48:56 2021
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 26 Jan 2021 22:48:56 -0700
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <202101270354.10R3s8Z01128207@darkstar.fourwinds.com>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
<202101242045.10OKjDvA964774@darkstar.fourwinds.com>
<20210124211100.GI21030@mcvoy.com>
<202101242114.10OLEYGk966708@darkstar.fourwinds.com>
<20210124212525.GJ21030@mcvoy.com>
<CAEoi9W5=toe-bb+6-zC0odkx4_C4X4FZpK4+ZJTAqCKGOCXP7w@mail.gmail.com>
<202101242333.10ONXjcI974038@darkstar.fourwinds.com>
<fc52a1a1-2136-ae39-110c-93a38e73ff94@bitsavers.org>
<202101250021.10P0L3Z2976588@darkstar.fourwinds.com>
<CAC20D2OhTW+eebyub7dVMBGZy1zoOja=ojGB_=TOjgB0wEJdHQ@mail.gmail.com>
<6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org>
<CAFH29to9GaKVxUXw8uwbeMAcF6izD=8gqhqROzCOSEA5xOA5aQ@mail.gmail.com>
<202101260138.10Q1ceo21049597@darkstar.fourwinds.com>
<alpine.BSF.2.21.9999.2101271354580.36435@aneurin.horsfall.org>
<202101270354.10R3s8Z01128207@darkstar.fourwinds.com>
Message-ID: <0a112927-2b0e-12cd-d4cc-a2cb79f58aac@spamtrap.tnetconsulting.net>
On 1/26/21 8:54 PM, Jon Steinhart wrote:
> stuff from V and W
Um ... I'm showing my (lack of) age and my ignorance here.
I assume that W is the window system that preceded X.
But "V"? I've never heard of that.
Would someone please educate and enlighten this youngin?
--
Grant. . . .
unix || die
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210126/08c861d2/attachment.bin>
From ggm at algebras.org Wed Jan 27 15:52:29 2021
From: ggm at algebras.org (George Michaelson)
Date: Wed, 27 Jan 2021 15:52:29 +1000
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <CAKr6gn1K2JfaCV0CtUKALwgqGwDnj7Q8dzbhPWGuPLyp9+DzMA@mail.gmail.com>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
<202101242045.10OKjDvA964774@darkstar.fourwinds.com>
<20210124211100.GI21030@mcvoy.com>
<202101242114.10OLEYGk966708@darkstar.fourwinds.com>
<20210124212525.GJ21030@mcvoy.com>
<CAEoi9W5=toe-bb+6-zC0odkx4_C4X4FZpK4+ZJTAqCKGOCXP7w@mail.gmail.com>
<202101242333.10ONXjcI974038@darkstar.fourwinds.com>
<fc52a1a1-2136-ae39-110c-93a38e73ff94@bitsavers.org>
<202101250021.10P0L3Z2976588@darkstar.fourwinds.com>
<CAC20D2OhTW+eebyub7dVMBGZy1zoOja=ojGB_=TOjgB0wEJdHQ@mail.gmail.com>
<6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org>
<CAFH29to9GaKVxUXw8uwbeMAcF6izD=8gqhqROzCOSEA5xOA5aQ@mail.gmail.com>
<202101260138.10Q1ceo21049597@darkstar.fourwinds.com>
<alpine.BSF.2.21.9999.2101271354580.36435@aneurin.horsfall.org>
<202101270354.10R3s8Z01128207@darkstar.fourwinds.com>
<CAKr6gn1K2JfaCV0CtUKALwgqGwDnj7Q8dzbhPWGuPLyp9+DzMA@mail.gmail.com>
Message-ID: <CAKr6gn0x2U_okcGOvUHG+nPha236_rO9pTH4RoSqy-RJ9Yx7UQ@mail.gmail.com>
Also to this, I think much was lost, when the Andrews X system lost
impetus. The filesystem lived on (they always do) but somehow, people
lost interest in WYSIWYG built around the X fonts, and Troff. I rather
liked it, used it heavily. I produced the university Phonebook for a
while in it, and adjunct scripts. (EQN for some things)
There was a rather nice animation tool, somebody obviously either was,
or was dating a ballet major at the uni, and decided to code something
pretty: the worked example was very dance-oriented.
(I know this is a layer "up" from X itself, but it goes to what might
have been, if the critical mass had been there)
From woods at robohack.ca Wed Jan 27 15:56:18 2021
From: woods at robohack.ca (Greg A. Woods)
Date: Tue, 26 Jan 2021 21:56:18 -0800
Subject: [TUHS] /bin vs /sbin
In-Reply-To: <b5ba60e5-c602-602b-db83-1bc64bba3db8@spamtrap.tnetconsulting.net>
References: <862d8a34-456d-33c1-7ef0-58c6e8089de9@tnetconsulting.net>
<202007211822.06LIMBJ4018831@freefriends.org>
<CANCZdfpMORPnd1A3ZvRuP_isATpRCB8eBse3ucQYCDxMgwZ7kA@mail.gmail.com>
<20200722011603.GA1536749@mit.edu>
<b5ba60e5-c602-602b-db83-1bc64bba3db8@spamtrap.tnetconsulting.net>
Message-ID: <m1l4doQ-0036xBC@more.local>
[not replying privately even though this is an old thread from back in
the time when I was still enjoying a care-free summer vacation, and even
though Grant and/or his mailer set "reply-to" to be his own address, not
the list address, but because I'm still having rDNS issues and Grant's
mailer won't let mine deliver to him...]
At Tue, 21 Jul 2020 21:27:59 -0600, Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:
Subject: Re: [TUHS] /bin vs /sbin
>
> Did Solaris follow in SunOS's foot steps? Or did Solaris do something
> different?
Note that "Solaris" is a marketing name for a whole OS package including
the kernel, base system, user interface, and even some applications.
On the other hand "SunOS" the name of the base system OS (i.e. kernel
and userland). The name "SunOS" pre-dated the name "Solaris" but
continues on as the name of the base OS within the Solaris package.
E.g. from the Wikipedia Solaris article:
"For example, Solaris 2.4 incorporates SunOS 5.4. After Solaris 2.6,
the 2. was dropped from the release name, so Solaris 7 incorporates
SunOS 5.7, and the latest release SunOS 5.11 forms the core of
Solaris 11.4."
and from the Wikipedia SunOS article:
"Today, SunOS 5 is universally known as Solaris, although the SunOS
name is still visible within the OS itself – in the startup banner,
the output of the uname command, and man page footers, among other
places.
Matching a SunOS 5.x release to its corresponding Solaris marketing
name is simple: each Solaris release name includes its corresponding
SunOS 5 minor version number. For example, Solaris 2.4 incorporated
SunOS 5.4. There is one small twist: after Solaris 2.6, the "2." was
dropped from the Solaris name and the SunOS minor number appears by
itself. The latest Solaris release is named Solaris 11 and
incorporates SunOS 5.11."
Sun even back-pedaled and re-branded SunSO 4 as Solaris 1.0 before the
switch from BSD to something Sun liked to think was akin to SVR4.
--
Greg A. Woods <gwoods at acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <woods at robohack.ca>
Planix, Inc. <woods at planix.com> Avoncote Farms <woods at avoncote.ca>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP Digital Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210126/ec465fa0/attachment.sig>
From woods at robohack.ca Wed Jan 27 16:01:12 2021
From: woods at robohack.ca (Greg A. Woods)
Date: Tue, 26 Jan 2021 22:01:12 -0800
Subject: [TUHS] reboot(2) system call
In-Reply-To: <CANCZdfosFGpBKw0wOx9nYgAWpeVNuRd-h6Nu5PLgZyyCuezZKA@mail.gmail.com>
References: <CANCZdfosFGpBKw0wOx9nYgAWpeVNuRd-h6Nu5PLgZyyCuezZKA@mail.gmail.com>
Message-ID: <m1l4dtA-0036xBC@more.local>
At Mon, 27 Jul 2020 12:57:59 -0600, Warner Losh <imp at bsdimp.com> wrote:
Subject: [TUHS] reboot(2) system call
>
> I've done some research for a friend about when the reboot() system call
> was added, and how it related to the sync, sync, sync dance.
>
> https://bsdimp.blogspot.com/2020/07/when-unix-learned-to-reboot2.html
>
> may be of interest. Please do let me know if I've gotten something wrong...
I've definitely experienced the second "sync" blocking until the first
was done. Once upon a time I remembered exactly why that happened, but
I no longer do.
The lore I was told at the time was that you alwasy ran three and that
it didn't matter if they were all on the same line with semicolons or
not because of the very fact that the second one would block.
The third one was just for superstitious good luck, and just in case
there was a process still running and writing to a filesystem.
--
Greg A. Woods <gwoods at acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <woods at robohack.ca>
Planix, Inc. <woods at planix.com> Avoncote Farms <woods at avoncote.ca>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP Digital Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210126/a01fe512/attachment.sig>
From henry.r.bent at gmail.com Wed Jan 27 16:19:58 2021
From: henry.r.bent at gmail.com (Henry Bent)
Date: Wed, 27 Jan 2021 01:19:58 -0500
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <0a112927-2b0e-12cd-d4cc-a2cb79f58aac@spamtrap.tnetconsulting.net>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
<202101242045.10OKjDvA964774@darkstar.fourwinds.com>
<20210124211100.GI21030@mcvoy.com>
<202101242114.10OLEYGk966708@darkstar.fourwinds.com>
<20210124212525.GJ21030@mcvoy.com>
<CAEoi9W5=toe-bb+6-zC0odkx4_C4X4FZpK4+ZJTAqCKGOCXP7w@mail.gmail.com>
<202101242333.10ONXjcI974038@darkstar.fourwinds.com>
<fc52a1a1-2136-ae39-110c-93a38e73ff94@bitsavers.org>
<202101250021.10P0L3Z2976588@darkstar.fourwinds.com>
<CAC20D2OhTW+eebyub7dVMBGZy1zoOja=ojGB_=TOjgB0wEJdHQ@mail.gmail.com>
<6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org>
<CAFH29to9GaKVxUXw8uwbeMAcF6izD=8gqhqROzCOSEA5xOA5aQ@mail.gmail.com>
<202101260138.10Q1ceo21049597@darkstar.fourwinds.com>
<alpine.BSF.2.21.9999.2101271354580.36435@aneurin.horsfall.org>
<202101270354.10R3s8Z01128207@darkstar.fourwinds.com>
<0a112927-2b0e-12cd-d4cc-a2cb79f58aac@spamtrap.tnetconsulting.net>
Message-ID: <CAEdTPBd0WizGYs1Xniv-Ge+J=O=5Znmgtny9ano_dhw1i-5XFw@mail.gmail.com>
On Wed, 27 Jan 2021 at 00:49, Grant Taylor via TUHS <tuhs at minnie.tuhs.org>
wrote:
> On 1/26/21 8:54 PM, Jon Steinhart wrote:
> > stuff from V and W
>
> Um ... I'm showing my (lack of) age and my ignorance here.
>
> I assume that W is the window system that preceded X.
>
> But "V"? I've never heard of that.
>
> Would someone please educate and enlighten this youngin?
>
> https://en.wikipedia.org/wiki/V_(operating_system)
-Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210127/2e013448/attachment.htm>
From jon at fourwinds.com Wed Jan 27 17:28:48 2021
From: jon at fourwinds.com (Jon Steinhart)
Date: Tue, 26 Jan 2021 23:28:48 -0800
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <0a112927-2b0e-12cd-d4cc-a2cb79f58aac@spamtrap.tnetconsulting.net>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
<202101242045.10OKjDvA964774@darkstar.fourwinds.com>
<20210124211100.GI21030@mcvoy.com>
<202101242114.10OLEYGk966708@darkstar.fourwinds.com>
<20210124212525.GJ21030@mcvoy.com>
<CAEoi9W5=toe-bb+6-zC0odkx4_C4X4FZpK4+ZJTAqCKGOCXP7w@mail.gmail.com>
<202101242333.10ONXjcI974038@darkstar.fourwinds.com>
<fc52a1a1-2136-ae39-110c-93a38e73ff94@bitsavers.org>
<202101250021.10P0L3Z2976588@darkstar.fourwinds.com>
<CAC20D2OhTW+eebyub7dVMBGZy1zoOja=ojGB_=TOjgB0wEJdHQ@mail.gmail.com>
<6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org>
<CAFH29to9GaKVxUXw8uwbeMAcF6izD=8gqhqROzCOSEA5xOA5aQ@mail.gmail.com>
<202101260138.10Q1ceo21049597@darkstar.fourwinds.com>
<alpine.BSF.2.21.9999.2101271354580.36435@aneurin.horsfall.org>
<202101270354.10R3s8Z01128207@darkstar.fourwinds.com>
<0a112927-2b0e-12cd-d4cc-a2cb79f58aac!
@spamtrap.tnetconsulting.net>
Message-ID: <202101270728.10R7SmLO1141589@darkstar.fourwinds.com>
Grant Taylor via TUHS writes:
>
> On 1/26/21 8:54 PM, Jon Steinhart wrote:
> > stuff from V and W
>
> Um ... I'm showing my (lack of) age and my ignorance here.
>
> I assume that W is the window system that preceded X.
>
> But "V"? I've never heard of that.
>
> Would someone please educate and enlighten this youngin?
V is an operating system written at Stanford for the original
Stanford University Network Board. It featured very fast
synchronous IPC. W is the window system that ran on V. It
was porting to UNIX and renamed X, but performed terribly
because of the lack of fast synchronous IPC. That got somewhat
changed in X11 which was done to try to outcompete NeWS.
Jon
From dave at horsfall.org Wed Jan 27 20:02:51 2021
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 27 Jan 2021 21:02:51 +1100 (EST)
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <0a112927-2b0e-12cd-d4cc-a2cb79f58aac@spamtrap.tnetconsulting.net>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
<202101242045.10OKjDvA964774@darkstar.fourwinds.com>
<20210124211100.GI21030@mcvoy.com>
<202101242114.10OLEYGk966708@darkstar.fourwinds.com>
<20210124212525.GJ21030@mcvoy.com>
<CAEoi9W5=toe-bb+6-zC0odkx4_C4X4FZpK4+ZJTAqCKGOCXP7w@mail.gmail.com>
<202101242333.10ONXjcI974038@darkstar.fourwinds.com>
<fc52a1a1-2136-ae39-110c-93a38e73ff94@bitsavers.org>
<202101250021.10P0L3Z2976588@darkstar.fourwinds.com>
<CAC20D2OhTW+eebyub7dVMBGZy1zoOja=ojGB_=TOjgB0wEJdHQ@mail.gmail.com>
<6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org>
<CAFH29to9GaKVxUXw8uwbeMAcF6izD=8gqhqROzCOSEA5xOA5aQ@mail.gmail.com>
<202101260138.10Q1ceo21049597@darkstar.fourwinds.com>
<alpine.BSF.2.21.9999.2101271354580.36435@aneurin.horsfall.org>
<202101270354.10R3s8Z01128207@darkstar.fourwinds.com>
<0a112927-2b0e-12cd-d4cc-a2cb79f58aac@spamtrap.tnetconsulting.net>
Message-ID: <alpine.BSF.2.21.9999.2101272052020.36435@aneurin.horsfall.org>
On Tue, 26 Jan 2021, Grant Taylor via TUHS wrote:
> Um ... I'm showing my (lack of) age and my ignorance here.
>
> I assume that W is the window system that preceded X.
>
> But "V"? I've never heard of that.
W, X, Y, Z ("Zee" for Yanks :-)
-- Dave
From lm at mcvoy.com Thu Jan 28 01:47:42 2021
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 27 Jan 2021 07:47:42 -0800
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <alpine.BSF.2.21.9999.2101271354580.36435@aneurin.horsfall.org>
References: <20210124212525.GJ21030@mcvoy.com>
<CAEoi9W5=toe-bb+6-zC0odkx4_C4X4FZpK4+ZJTAqCKGOCXP7w@mail.gmail.com>
<202101242333.10ONXjcI974038@darkstar.fourwinds.com>
<fc52a1a1-2136-ae39-110c-93a38e73ff94@bitsavers.org>
<202101250021.10P0L3Z2976588@darkstar.fourwinds.com>
<CAC20D2OhTW+eebyub7dVMBGZy1zoOja=ojGB_=TOjgB0wEJdHQ@mail.gmail.com>
<6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org>
<CAFH29to9GaKVxUXw8uwbeMAcF6izD=8gqhqROzCOSEA5xOA5aQ@mail.gmail.com>
<202101260138.10Q1ceo21049597@darkstar.fourwinds.com>
<alpine.BSF.2.21.9999.2101271354580.36435@aneurin.horsfall.org>
Message-ID: <20210127154742.GB4227@mcvoy.com>
On Wed, Jan 27, 2021 at 02:11:26PM +1100, Dave Horsfall wrote:
> Ugh! I've seen some ugly windowing systems in my time, but X... Heck, even
> CP/M had a better system, IIRC.
CP/M didn't have a window system, at least mine didn't. Hard to do that
in 64K (I had 128K banked with the crt mapped into the 2nd bank).
From gtaylor at tnetconsulting.net Thu Jan 28 04:32:41 2021
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Wed, 27 Jan 2021 11:32:41 -0700
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <0a112927-2b0e-12cd-d4cc-a2cb79f58aac@spamtrap.tnetconsulting.net>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
<202101242045.10OKjDvA964774@darkstar.fourwinds.com>
<20210124211100.GI21030@mcvoy.com>
<202101242114.10OLEYGk966708@darkstar.fourwinds.com>
<20210124212525.GJ21030@mcvoy.com>
<CAEoi9W5=toe-bb+6-zC0odkx4_C4X4FZpK4+ZJTAqCKGOCXP7w@mail.gmail.com>
<202101242333.10ONXjcI974038@darkstar.fourwinds.com>
<fc52a1a1-2136-ae39-110c-93a38e73ff94@bitsavers.org>
<202101250021.10P0L3Z2976588@darkstar.fourwinds.com>
<CAC20D2OhTW+eebyub7dVMBGZy1zoOja=ojGB_=TOjgB0wEJdHQ@mail.gmail.com>
<6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org>
<CAFH29to9GaKVxUXw8uwbeMAcF6izD=8gqhqROzCOSEA5xOA5aQ@mail.gmail.com>
<202101260138.10Q1ceo21049597@darkstar.fourwinds.com>
<alpine.BSF.2.21.9999.2101271354580.36435@aneurin.horsfall.org>
<202101270354.10R3s8Z01128207@darkstar.fourwinds.com>
<0a112927-2b0e-12cd-d4cc-a2cb79f58aac@spamtrap.tnetconsulting.net>
Message-ID: <eaef08c9-b004-0a1e-c1f0-a6cfe6686580@spamtrap.tnetconsulting.net>
On 1/26/21 10:48 PM, Grant Taylor via TUHS wrote:
> Would someone please educate and enlighten this youngin?
Thank you Henry, Dave, and Jon for enlightening me.
Now I have yet another thing to learn about.
--
Grant. . . .
unix || die
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210127/562c05fc/attachment.bin>
From gtaylor at tnetconsulting.net Thu Jan 28 05:06:26 2021
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Wed, 27 Jan 2021 12:06:26 -0700
Subject: [TUHS] /bin vs /sbin
In-Reply-To: <m1l4doQ-0036xBC@more.local>
References: <862d8a34-456d-33c1-7ef0-58c6e8089de9@tnetconsulting.net>
<202007211822.06LIMBJ4018831@freefriends.org>
<CANCZdfpMORPnd1A3ZvRuP_isATpRCB8eBse3ucQYCDxMgwZ7kA@mail.gmail.com>
<20200722011603.GA1536749@mit.edu>
<b5ba60e5-c602-602b-db83-1bc64bba3db8@spamtrap.tnetconsulting.net>
<m1l4doQ-0036xBC@more.local>
Message-ID: <64f487fb-6fed-e741-4e7b-daed1f646e37@spamtrap.tnetconsulting.net>
On 1/26/21 10:56 PM, Greg A. Woods wrote:
> [not replying privately even though this is an old thread from back
> in the time when I was still enjoying a care-free summer vacation,
<thumbs up>
> and even though Grant and/or his mailer set "reply-to" to be his
> own address, not the list address,
It's not me or my mailer setting the Reply-To:. It seems as if the
mailing list is setting that on senders who's domain uses DMARC, which
mine does.
> but because I'm still having rDNS issues and Grant's mailer won't
> let mine deliver to him...]
I've added central... to my hosts file, so hopefully you can email me
directly if you want to.
> Note that "Solaris" is a marketing name for a whole OS package
> including the kernel, base system, user interface, and even some
> applications.
<head tilt>
That's ... a different explanation than I've heard before.
I'm not saying I disagree with it, just that it's completely new to me.
> On the other hand "SunOS" the name of the base system OS (i.e. kernel
> and userland).
Please elaborate. Including using the same terms for both names. How
does "userland" compare to "base system" and / or "user interface"?
I'm also curious what differentiates between SunOS and a minimal install
of Solaris.
> The name "SunOS" pre-dated the name "Solaris" but continues on as
> the name of the base OS within the Solaris package.
I thought the "SunOS" vs "Solaris" was a marketing change around the
time SunOS / Solaris transitioned from being more BSD to more Sys V.
I also thought that the retention of "SunOS" in the kernel name and
versioning was for backward compatibility.
> Sun even back-pedaled and re-branded SunSO 4 as Solaris 1.0 before
> the switch from BSD to something Sun liked to think was akin to SVR4.
I was not aware that some of -- what I'll call -- the naming shenanigans
happened to SunOS 4. I was only aware of things at SunOS 5.
--
Grant. . . .
unix || die
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210127/ef4dcac2/attachment.bin>
From cym224 at gmail.com Thu Jan 28 05:26:35 2021
From: cym224 at gmail.com (Nemo Nusquam)
Date: Wed, 27 Jan 2021 14:26:35 -0500
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <eaef08c9-b004-0a1e-c1f0-a6cfe6686580@spamtrap.tnetconsulting.net>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<202101242045.10OKjDvA964774@darkstar.fourwinds.com>
<20210124211100.GI21030@mcvoy.com>
<202101242114.10OLEYGk966708@darkstar.fourwinds.com>
<20210124212525.GJ21030@mcvoy.com>
<CAEoi9W5=toe-bb+6-zC0odkx4_C4X4FZpK4+ZJTAqCKGOCXP7w@mail.gmail.com>
<202101242333.10ONXjcI974038@darkstar.fourwinds.com>
<fc52a1a1-2136-ae39-110c-93a38e73ff94@bitsavers.org>
<202101250021.10P0L3Z2976588@darkstar.fourwinds.com>
<CAC20D2OhTW+eebyub7dVMBGZy1zoOja=ojGB_=TOjgB0wEJdHQ@mail.gmail.com>
<6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org>
<CAFH29to9GaKVxUXw8uwbeMAcF6izD=8gqhqROzCOSEA5xOA5aQ@mail.gmail.com>
<202101260138.10Q1ceo21049597@darkstar.fourwinds.com>
<alpine.BSF.2.21.9999.2101271354580.36435@aneurin.horsfall.org>
<202101270354.10R3s8Z01128207@darkstar.fourwinds.com>
<0a112927-2b0e-12cd-d4cc-a2cb79f58aac@spamtrap.tnetconsulting.net>
<eaef08c9-b004-0a1e-c1f0-a6cfe6686580@spamtrap.tnetconsulting.net>
Message-ID: <8c1e0a98-0e17-7f1d-c345-9d28b8507ef9@gmail.com>
On 01/27/21 13:32, Grant Taylor via TUHS wrote:
> On 1/26/21 10:48 PM, Grant Taylor via TUHS wrote:
>> Would someone please educate and enlighten this youngin?
>
> Thank you Henry, Dave, and Jon for enlightening me.
>
> Now I have yet another thing to learn about.
Borenstein wrote a book ("Programming as if people mattered: Friendly
Programs, Software Engineering, and Other Noble Delusions") in which he
mused about W and X and Andrew. (A very nice read but horribly
expensive -- fortunately I bought it when PUP had reasonably priced
paperbacks.)
N.
From cym224 at gmail.com Thu Jan 28 05:34:34 2021
From: cym224 at gmail.com (Nemo Nusquam)
Date: Wed, 27 Jan 2021 14:34:34 -0500
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <CAD2gp_RsiayPg+xyEYK7AwrkuO0NS7f4o4pZ6JwVPuaoBWDdTA@mail.gmail.com>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
<202101242045.10OKjDvA964774@darkstar.fourwinds.com>
<20210124211100.GI21030@mcvoy.com>
<202101242114.10OLEYGk966708@darkstar.fourwinds.com>
<20210124212525.GJ21030@mcvoy.com>
<CAEoi9W5=toe-bb+6-zC0odkx4_C4X4FZpK4+ZJTAqCKGOCXP7w@mail.gmail.com>
<202101242333.10ONXjcI974038@darkstar.fourwinds.com>
<fc52a1a1-2136-ae39-110c-93a38e73ff94@bitsavers.org>
<202101250021.10P0L3Z2976588@darkstar.fourwinds.com>
<CAC20D2OhTW+eebyub7dVMBGZy1zoOja=ojGB_=TOjgB0wEJdHQ@mail.gmail.com>
<6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org>
<CAFH29to9GaKVxUXw8uwbeMAcF6izD=8gqhqROzCOSEA5xOA5aQ@mail.gmail.com>
<CAD2gp_RsiayPg+xyEYK7AwrkuO0NS7f4o4pZ6JwVPuaoBWDdTA@mail.gmail.com>
Message-ID: <ce9d63e4-db8a-8cdc-a620-cdf17673d9cc@gmail.com>
On 01/25/21 21:45, John Conan wrote (in part):
> I've been messing around with X.680, aka ASN/1. Its reputation for
> horrible evilness, I find, primarily comes from the Packed Encoding
> Rules and the interface with statically typed languages, both of which
> require dealing with the schema language programmatically.
I would beg to differ. Have you ever seen the ASN.1 in the various
crypto standards? (This mess is independent of PER.)
N.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210127/6144def1/attachment-0001.htm>
From sclark46 at earthlink.net Thu Jan 28 02:40:46 2021
From: sclark46 at earthlink.net (Stephen Clark)
Date: Wed, 27 Jan 2021 11:40:46 -0500
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <20210127154742.GB4227@mcvoy.com>
References: <20210124212525.GJ21030@mcvoy.com>
<CAEoi9W5=toe-bb+6-zC0odkx4_C4X4FZpK4+ZJTAqCKGOCXP7w@mail.gmail.com>
<202101242333.10ONXjcI974038@darkstar.fourwinds.com>
<fc52a1a1-2136-ae39-110c-93a38e73ff94@bitsavers.org>
<202101250021.10P0L3Z2976588@darkstar.fourwinds.com>
<CAC20D2OhTW+eebyub7dVMBGZy1zoOja=ojGB_=TOjgB0wEJdHQ@mail.gmail.com>
<6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org>
<CAFH29to9GaKVxUXw8uwbeMAcF6izD=8gqhqROzCOSEA5xOA5aQ@mail.gmail.com>
<202101260138.10Q1ceo21049597@darkstar.fourwinds.com>
<alpine.BSF.2.21.9999.2101271354580.36435@aneurin.horsfall.org>
<20210127154742.GB4227@mcvoy.com>
Message-ID: <a570df52-c0fd-3e29-dec4-294aa1b32dc0@earthlink.net>
On 1/27/21 10:47 AM, Larry McVoy wrote:
> On Wed, Jan 27, 2021 at 02:11:26PM +1100, Dave Horsfall wrote:
>> Ugh! I've seen some ugly windowing systems in my time, but X... Heck, even
>> CP/M had a better system, IIRC.
> CP/M didn't have a window system, at least mine didn't. Hard to do that
> in 64K (I had 128K banked with the crt mapped into the 2nd bank).
Neither did mine I had an original Altair 8800 I had built and started with CP/M
2.2 then upgraded to 3.0 and wrote my
own bios and flashed into a prom board I had built from kit. Computers were sure
a lot simpler in those days.
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
"Beer is proof God loves us and wants us to be happy!" (Ben Franklin)
From woods at robohack.ca Thu Jan 28 07:30:00 2021
From: woods at robohack.ca (Greg A. Woods)
Date: Wed, 27 Jan 2021 13:30:00 -0800
Subject: [TUHS] David Tilbrook, RIP 2021-01-15
Message-ID: <m1l4sO0-0036xBC@more.local>
Since nobody seems to have mentioned his passing yet, I thought I might.
David Tilbrook died (from complications of COVID-19) in the early hours
of January 15, 2021.
He had been in long term care in Toronto for just over a year.
His web site remains up and running for now at http://qef.com/ though I
don't know for how long that may last.
--
Greg A. Woods <gwoods at acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <woods at robohack.ca>
Planix, Inc. <woods at planix.com> Avoncote Farms <woods at avoncote.ca>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP Digital Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210127/aa1521a7/attachment.sig>
From clemc at ccc.com Thu Jan 28 08:00:06 2021
From: clemc at ccc.com (Clem Cole)
Date: Wed, 27 Jan 2021 17:00:06 -0500
Subject: [TUHS] David Tilbrook, RIP 2021-01-15
In-Reply-To: <m1l4sO0-0036xBC@more.local>
References: <m1l4sO0-0036xBC@more.local>
Message-ID: <CAC20D2OKKf-k0V4tQYvzWJvZA37wFHrZDCRfr+8XZAujDDBJqw@mail.gmail.com>
Greg,
Andrew Hume mentioned it to the list on Jan 15 (Message-Id: <
09B601EA-DA27-4A5D-B373-E914760F05CF at humeweb.com>), as he was looking for
a couple of email addresses for some of us that worked with David in past
lives.
That said, the family is asking any of us to add remembrances here: Benjamin's
Park Memorial Chapel - Memorial Book
FWIW: I participated in the live stream of the Graveside ceremony. His
daughter did a super eulogy. I'm not sure if there is a replay available.
Many of us that knew him, will miss him.
Clem
á§
On Wed, Jan 27, 2021 at 4:30 PM Greg A. Woods <woods at robohack.ca> wrote:
> Since nobody seems to have mentioned his passing yet, I thought I might.
>
> David Tilbrook died (from complications of COVID-19) in the early hours
> of January 15, 2021.
>
> He had been in long term care in Toronto for just over a year.
>
> His web site remains up and running for now at http://qef.com/ though I
> don't know for how long that may last.
>
> --
> Greg A. Woods <gwoods at acm.org>
>
> Kelowna, BC +1 250 762-7675 RoboHack <woods at robohack.ca>
> Planix, Inc. <woods at planix.com> Avoncote Farms <woods at avoncote.ca>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210127/373df4d5/attachment.htm>
From imp at bsdimp.com Thu Jan 28 08:22:55 2021
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 27 Jan 2021 15:22:55 -0700
Subject: [TUHS] /bin vs /sbin
In-Reply-To: <64f487fb-6fed-e741-4e7b-daed1f646e37@spamtrap.tnetconsulting.net>
References: <862d8a34-456d-33c1-7ef0-58c6e8089de9@tnetconsulting.net>
<202007211822.06LIMBJ4018831@freefriends.org>
<CANCZdfpMORPnd1A3ZvRuP_isATpRCB8eBse3ucQYCDxMgwZ7kA@mail.gmail.com>
<20200722011603.GA1536749@mit.edu>
<b5ba60e5-c602-602b-db83-1bc64bba3db8@spamtrap.tnetconsulting.net>
<m1l4doQ-0036xBC@more.local>
<64f487fb-6fed-e741-4e7b-daed1f646e37@spamtrap.tnetconsulting.net>
Message-ID: <CANCZdfqyVS++qdo6=2qym4mpi=sRFxrsiwW8hAR445-dVOoFSg@mail.gmail.com>
On Wed, Jan 27, 2021 at 12:06 PM Grant Taylor via TUHS <tuhs at minnie.tuhs.org>
wrote:
> On 1/26/21 10:56 PM, Greg A. Woods wrote:
> > [not replying privately even though this is an old thread from back
> > in the time when I was still enjoying a care-free summer vacation,
>
> <thumbs up>
>
> > and even though Grant and/or his mailer set "reply-to" to be his
> > own address, not the list address,
>
> It's not me or my mailer setting the Reply-To:. It seems as if the
> mailing list is setting that on senders who's domain uses DMARC, which
> mine does.
>
> > but because I'm still having rDNS issues and Grant's mailer won't
> > let mine deliver to him...]
>
> I've added central... to my hosts file, so hopefully you can email me
> directly if you want to.
>
> > Note that "Solaris" is a marketing name for a whole OS package
> > including the kernel, base system, user interface, and even some
> > applications.
>
> <head tilt>
>
> That's ... a different explanation than I've heard before.
>
> I'm not saying I disagree with it, just that it's completely new to me.
>
> > On the other hand "SunOS" the name of the base system OS (i.e. kernel
> > and userland).
>
> Please elaborate. Including using the same terms for both names. How
> does "userland" compare to "base system" and / or "user interface"?
>
> I'm also curious what differentiates between SunOS and a minimal install
> of Solaris.
>
Solaris 2.x == SunOS 5.x + OpenWindows
Solaris 1.x == SunOS 4.x + OpenWindows
Solaris, back in the day, was SunOS + OpenWindows.
> > The name "SunOS" pre-dated the name "Solaris" but continues on as
> > the name of the base OS within the Solaris package.
>
> I thought the "SunOS" vs "Solaris" was a marketing change around the
> time SunOS / Solaris transitioned from being more BSD to more Sys V.
>
No. Solaris 2 was System V. Solaris 1 was BSD. Though it did pop up around
SunOS 4.1 time frame when it became clear that SunOS 5 would be System V
based and a big rewrite.
When Solbourne chose their name, Sun told them they could pick anything
they wanted, except Solaris because they were going to use that to market
SunOS.
> I also thought that the retention of "SunOS" in the kernel name and
> versioning was for backward compatibility.
>
Not entirely... It was very explicit in the marketing literature that SunOS
5 was the kernel for Solaris 2, but that Solaris 2 also included other
components like OpenWindows. The status of the base userland tools (eg
/bin/ls) wasn't ever talked about, but was generally understood to be in
the SunOS side of the world...
> > Sun even back-pedaled and re-branded SunSO 4 as Solaris 1.0 before
> > the switch from BSD to something Sun liked to think was akin to SVR4.
>
> I was not aware that some of -- what I'll call -- the naming shenanigans
> happened to SunOS 4. I was only aware of things at SunOS 5.
>
Yes. I had (but no longer have) a Solaris 1.1 Sparc CD that had SunOS 4.1.4
and OpenWindows 1.1 on it. I think Solaris 1.0 had 4.1.3 on it.
I worked for Solbourne Computers in Longmont CO in the early 1990s and
this distinction was what drove our group to create OI (Object Interface)
set of tools that implemented the OpenWindows and Motif look and feel since
it wasn't clear that Sun would license OpenWindows when Solbourne started
and we needed a desktop story...
Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210127/04e94e04/attachment.htm>
From woods at robohack.ca Thu Jan 28 08:35:50 2021
From: woods at robohack.ca (Greg A. Woods)
Date: Wed, 27 Jan 2021 14:35:50 -0800
Subject: [TUHS] /bin vs /sbin
In-Reply-To: <64f487fb-6fed-e741-4e7b-daed1f646e37@spamtrap.tnetconsulting.net>
References: <862d8a34-456d-33c1-7ef0-58c6e8089de9@tnetconsulting.net>
<202007211822.06LIMBJ4018831@freefriends.org>
<CANCZdfpMORPnd1A3ZvRuP_isATpRCB8eBse3ucQYCDxMgwZ7kA@mail.gmail.com>
<20200722011603.GA1536749@mit.edu>
<b5ba60e5-c602-602b-db83-1bc64bba3db8@spamtrap.tnetconsulting.net>
<m1l4doQ-0036xBC@more.local>
<64f487fb-6fed-e741-4e7b-daed1f646e37@spamtrap.tnetconsulting.net>
Message-ID: <m1l4tPi-0036xBC@more.local>
At Wed, 27 Jan 2021 12:06:26 -0700, Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:
Subject: Re: [TUHS] /bin vs /sbin
>
> I've added central... to my hosts file, so hopefully you can email me
> directly if you want to.
Thanks! (but I still need to pester my service provider for rDNS!)
> > On the other hand "SunOS" the name of the base system OS
> > (i.e. kernel and userland).
>
> Please elaborate. Including using the same terms for both names. How
> does "userland" compare to "base system" and / or "user interface"?
>
> I'm also curious what differentiates between SunOS and a minimal
> install of Solaris.
Sorry, I should have been a tiny bit more specific: the "user
interface" here refers to a Graphical UI. Unix of course didn't start
out with a GUI of any kind, and workstation vendors like Sun and many
others at the time made a big deal out of how they were offering a
better user interface for their systems.
I separate "kernel" and "userland" (here meaning all the command-line
programs, etc.) only because that's become a more common way to define
the "base OS" in unixy, i.e. linuxy, circles.
This distinction between the traditional Unix layer and the GUI is quite
important in the history of SunOS, since there have been a number of
different offerings from Sun for their GUI (Sun Windowing System,
SunView, NeWS, SunWindows); and also in how Sun promoted their various
GUI offerings as the solutions for wider use.
Even with the advent of a common choice of The X Window System as the
basis for most workstation vendor's GUIs, there were still battles over
which toolkit and window manager and "look and feel" would prevail
(Athena vs. Motif vs. OpenLook), with Sun even evolving their offerings
(SunWindows, OpenLook) over time.
--
Greg A. Woods <gwoods at acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <woods at robohack.ca>
Planix, Inc. <woods at planix.com> Avoncote Farms <woods at avoncote.ca>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP Digital Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210127/e9968227/attachment.sig>
From gnu at toad.com Thu Jan 28 10:19:13 2021
From: gnu at toad.com (John Gilmore)
Date: Wed, 27 Jan 2021 16:19:13 -0800
Subject: [TUHS] Troff to ps
In-Reply-To: <m1l4dJe-0036xBC@more.local>
References: <f90685ec-29fa-d7b6-5b4d-a71aaf19476b@gmail.com>
<202007261531.06QFVqZb027062@freefriends.org>
<202007261535.06QFZvLg027250@freefriends.org>
<CAC20D2P-6U7ruF4P1HyeZ=6xcgYYKFjOLXKquzgnMFONGxgC-g@mail.gmail.com>
<202007261711.06QHB07i032409@freefriends.org>
<CAC20D2N9vMnuA9sYK2Bn_sbPySa3bpGfh93JGiQH1_iZn62P9g@mail.gmail.com>
<m1l4dJe-0036xBC@more.local>
Message-ID: <17854.1611793153@hop.toad.com>
Greg A. Woods <woods at robohack.ca> wrote:
> As I recall even some of the bigger vendors such as Sun and IBM didn't
> offer ditroff in their base OS, but they did offer old troff. Those
> were the days of insane AT&T licensing and all the games competitors
> played around it.
As I recall, AT&T wanted about the same amount of money for ditroff as
for the entire UNIX release. So, of course no UNIX vendor was going to
double the royalty they paid to AT&T for every customer, for a small
improvement in a utility that most customers didn't even use (troff).
John
From clemc at ccc.com Thu Jan 28 11:25:33 2021
From: clemc at ccc.com (Clem Cole)
Date: Wed, 27 Jan 2021 20:25:33 -0500
Subject: [TUHS] Troff to ps
In-Reply-To: <17854.1611793153@hop.toad.com>
References: <f90685ec-29fa-d7b6-5b4d-a71aaf19476b@gmail.com>
<202007261531.06QFVqZb027062@freefriends.org>
<202007261535.06QFZvLg027250@freefriends.org>
<CAC20D2P-6U7ruF4P1HyeZ=6xcgYYKFjOLXKquzgnMFONGxgC-g@mail.gmail.com>
<202007261711.06QHB07i032409@freefriends.org>
<CAC20D2N9vMnuA9sYK2Bn_sbPySa3bpGfh93JGiQH1_iZn62P9g@mail.gmail.com>
<m1l4dJe-0036xBC@more.local> <17854.1611793153@hop.toad.com>
Message-ID: <CAC20D2NCJEhfB5NgaigE8URTKuCqjUtr4nxtrnm4P9Fg3YQ2fA@mail.gmail.com>
Actually It was very cheap. $5 a copy if I remember correctly Masscomp
and Stellar just ate the cost. The adobe transcript license was also
nominal. In both cases we realized it was cheaper than trying to keep two
separate streams and figure out which systems we shipped it too.
On Wed, Jan 27, 2021 at 7:26 PM John Gilmore <gnu at toad.com> wrote:
> Greg A. Woods <woods at robohack.ca> wrote:
> > As I recall even some of the bigger vendors such as Sun and IBM didn't
> > offer ditroff in their base OS, but they did offer old troff. Those
> > were the days of insane AT&T licensing and all the games competitors
> > played around it.
>
> As I recall, AT&T wanted about the same amount of money for ditroff as
> for the entire UNIX release. So, of course no UNIX vendor was going to
> double the royalty they paid to AT&T for every customer, for a small
> improvement in a utility that most customers didn't even use (troff).
>
> John
>
> --
Sent from a handheld expect more typos than usual
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210127/b8a4660e/attachment.htm>
From lm at mcvoy.com Thu Jan 28 11:59:03 2021
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 27 Jan 2021 17:59:03 -0800
Subject: [TUHS] Troff to ps
In-Reply-To: <CAC20D2NCJEhfB5NgaigE8URTKuCqjUtr4nxtrnm4P9Fg3YQ2fA@mail.gmail.com>
References: <f90685ec-29fa-d7b6-5b4d-a71aaf19476b@gmail.com>
<202007261531.06QFVqZb027062@freefriends.org>
<202007261535.06QFZvLg027250@freefriends.org>
<CAC20D2P-6U7ruF4P1HyeZ=6xcgYYKFjOLXKquzgnMFONGxgC-g@mail.gmail.com>
<202007261711.06QHB07i032409@freefriends.org>
<CAC20D2N9vMnuA9sYK2Bn_sbPySa3bpGfh93JGiQH1_iZn62P9g@mail.gmail.com>
<m1l4dJe-0036xBC@more.local> <17854.1611793153@hop.toad.com>
<CAC20D2NCJEhfB5NgaigE8URTKuCqjUtr4nxtrnm4P9Fg3YQ2fA@mail.gmail.com>
Message-ID: <20210128015903.GK4227@mcvoy.com>
I was just an engineer but what John said sort of is what I thought. There
was some money weirdness around anything above nroff/troff. I don't think
it was $5 but as I said, I was an engineer, nobody directly told me this
stuff.
On Wed, Jan 27, 2021 at 08:25:33PM -0500, Clem Cole wrote:
> Actually It was very cheap. $5 a copy if I remember correctly Masscomp
> and Stellar just ate the cost. The adobe transcript license was also
> nominal. In both cases we realized it was cheaper than trying to keep two
> separate streams and figure out which systems we shipped it too.
>
> On Wed, Jan 27, 2021 at 7:26 PM John Gilmore <gnu at toad.com> wrote:
>
> > Greg A. Woods <woods at robohack.ca> wrote:
> > > As I recall even some of the bigger vendors such as Sun and IBM didn't
> > > offer ditroff in their base OS, but they did offer old troff. Those
> > > were the days of insane AT&T licensing and all the games competitors
> > > played around it.
> >
> > As I recall, AT&T wanted about the same amount of money for ditroff as
> > for the entire UNIX release. So, of course no UNIX vendor was going to
> > double the royalty they paid to AT&T for every customer, for a small
> > improvement in a utility that most customers didn't even use (troff).
> >
> > John
> >
> > --
> Sent from a handheld expect more typos than usual
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
From norman at oclsc.org Thu Jan 28 12:48:23 2021
From: norman at oclsc.org (Norman Wilson)
Date: Wed, 27 Jan 2021 21:48:23 -0500
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
Message-ID: <1611802107.23148.for-standards-violators@oclsc.org>
Nemo Nusquam:
Borenstein wrote a book ("Programming as if people mattered: Friendly
Programs, Software Engineering, and Other Noble Delusions") in which he
mused about W and X and Andrew. (A very nice read but horribly
expensive -- fortunately I bought it when PUP had reasonably priced
paperbacks.)
======
abebooks.com is your friend here. I just bought a used paperback copy
for about USD 15 including shipping to Canada. There are others of
similar price. Shipping to the US is probably a little cheaper.
There's at least one copy available from a seller in the UK as
well (and doubtless some from other countries if you dig further
in the listings).
For those who don't know, ABE is a central place for independent
booksellers, including used-book shops, to sell online. You get
a good deal and support a worthwhile small business (not just ABE
but the individual selling shop) at the same time.
Norman Wilson
Toronto ON
From gnu at toad.com Thu Jan 28 13:19:59 2021
From: gnu at toad.com (John Gilmore)
Date: Wed, 27 Jan 2021 19:19:59 -0800
Subject: [TUHS] Troff to ps
In-Reply-To: <CAC20D2NCJEhfB5NgaigE8URTKuCqjUtr4nxtrnm4P9Fg3YQ2fA@mail.gmail.com>
References: <f90685ec-29fa-d7b6-5b4d-a71aaf19476b@gmail.com>
<202007261531.06QFVqZb027062@freefriends.org>
<202007261535.06QFZvLg027250@freefriends.org>
<CAC20D2P-6U7ruF4P1HyeZ=6xcgYYKFjOLXKquzgnMFONGxgC-g@mail.gmail.com>
<202007261711.06QHB07i032409@freefriends.org>
<CAC20D2N9vMnuA9sYK2Bn_sbPySa3bpGfh93JGiQH1_iZn62P9g@mail.gmail.com>
<m1l4dJe-0036xBC@more.local> <17854.1611793153@hop.toad.com>
<CAC20D2NCJEhfB5NgaigE8URTKuCqjUtr4nxtrnm4P9Fg3YQ2fA@mail.gmail.com>
Message-ID: <30778.1611803999@hop.toad.com>
Clem Cole <clemc at ccc.com> wrote:
> Actually It was very cheap. $5 a copy if I remember correctly
We may both be right. The AT&T license to sell binary copies of UNIX
might have cost Sun only $5 per copy. Microsoft's Xenix license was
similar; it probably got down to $1 or 50c per copy. The price per copy
went steeply down as you sold more copies; the licenses soaked the small
sellers and catered to the large volume sellers. After all, it cost
AT&T *nothing* for a company to sell twice or ten times as many copies;
they weren't supporting the software anyway.
As I recall, when Microsoft supplied the OS for the TRS-80 Model 16,
they blew the doors off all the tiers in their UNIX license. The 16B
sold 40,000 copies in 1984 (according to Wikipedia), making it the
highest volume UNIX computer of the year. Clueless monopolist business
people at AT&T had never anticipated that ANYBODY would sell 40,000
copies of UNIX. Remember when IBM estimated in 1943, "I think there is
a world market for maybe five computers" and DEC in 1977 said "There is
no reason anyone would want a computer in their home"? See:
https://www.pcworld.com/article/155984/worst_tech_predictions.html
After the first few years, Sun was shipping high volumes of UNIX systems
(tens or hundreds of thousands per year). For many years they didn't
need any of the later USL licenses, because they shipped a BSD UNIX that
they were maintaining themselves, and that was (in many peoples'
opinions) higher quality software than anything that USL was offering.
The licensing for the ancient 32V license they needed was written back
in the days when shipping 100 copies was a big deal, so the prices at
the 1,000 or 10,000 or 100,000 copy tiers were very cheap. Adding 1c to
ship ditroff rather than troff might have been reasonable, but not $5!
John
From gtaylor at tnetconsulting.net Thu Jan 28 15:24:07 2021
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Wed, 27 Jan 2021 22:24:07 -0700
Subject: [TUHS] /bin vs /sbin
In-Reply-To: <m1l4tPi-0036xBC@more.local>
References: <862d8a34-456d-33c1-7ef0-58c6e8089de9@tnetconsulting.net>
<202007211822.06LIMBJ4018831@freefriends.org>
<CANCZdfpMORPnd1A3ZvRuP_isATpRCB8eBse3ucQYCDxMgwZ7kA@mail.gmail.com>
<20200722011603.GA1536749@mit.edu>
<b5ba60e5-c602-602b-db83-1bc64bba3db8@spamtrap.tnetconsulting.net>
<m1l4doQ-0036xBC@more.local>
<64f487fb-6fed-e741-4e7b-daed1f646e37@spamtrap.tnetconsulting.net>
<m1l4tPi-0036xBC@more.local>
Message-ID: <6c5ee770-99e0-acaf-18d1-d392a0ccaa84@spamtrap.tnetconsulting.net>
On 1/27/21 3:35 PM, Greg A. Woods wrote:
> Thanks! (but I still need to pester my service provider for rDNS!)
You're welcome.
> Sorry, I should have been a tiny bit more specific: the "user
> interface" here refers to a Graphical UI. Unix of course didn't start
> out with a GUI of any kind, and workstation vendors like Sun and many
> others at the time made a big deal out of how they were offering a
> better user interface for their systems.
Hum ...
> I separate "kernel" and "userland" (here meaning all the command-line
> programs, etc.) only because that's become a more common way to define
> the "base OS" in unixy, i.e. linuxy, circles.
When I think of Base OS, I think of AIX, because it's the first place I
saw Base OS, referred to as BOS, explicitly called out. But, I know
that Solaris and HP-UX also have a very minimal install. Even Linux has
very minimal installs (debootstrap, Slackware boot+root, and DSL come to
mind).
I think of development applications / compilers, fancy text processing,
networking, X11, office applications as all being add on products.
Sure, Linux tends to come with a LOT of them installed by default.
I guess the base OS to me is what's required to boot, maintain, and
install a system. Anything else is ancillary as far as -- what I
consider to be -- the base OS is concerned.
> This distinction between the traditional Unix layer and the GUI is
> quite important in the history of SunOS, since there have been a number
> of different offerings from Sun for their GUI (Sun Windowing System,
> SunView, NeWS, SunWindows); and also in how Sun promoted their various
> GUI offerings as the solutions for wider use.
Hum. I guess my exposure to Solaris installations has tainted my view.
I helped support some DB servers with the full GUI developers
workstation installed, just in case it was needed. The people that
installed them didn't want to ever go back and pull something else in.
Which is why we had to patch Firefox, Thunderbird, and Pidgen /
libpurple on Solaris database servers. At least until I ripped those
things, along with the kitchen sink, out. It made patching so much
faster and smaller.
> Even with the advent of a common choice of The X Window System as the
> basis for most workstation vendor's GUIs, there were still battles
> over which toolkit and window manager and "look and feel" would prevail
> (Athena vs. Motif vs. OpenLook), with Sun even evolving their offerings
> (SunWindows, OpenLook) over time.
I'm vaguely aware of CDE and that there were others before / around
that. But my personal experience is largely after that. As such, I
wasn't aware of some of the things that you are talking about. Thank
you for enlightening me.
--
Grant. . . .
unix || die
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210127/228d97f4/attachment.bin>
From jnc at mercury.lcs.mit.edu Thu Jan 28 19:24:27 2021
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu, 28 Jan 2021 04:24:27 -0500 (EST)
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
Message-ID: <20210128092427.0BA6518C08F@mercury.lcs.mit.edu>
> From: Norman Wilson
> You get a good deal and support a worthwhile small business (not just
> ABE but the individual selling shop) at the same time.
ABE isn't a small business (any more); Amazon bought them a couple of years
ago. Biblio (https://www.biblio.com/) is the same basic thing ("more than 6500
independent book stores"), but independent. There's also Alibris
(https://www.alibris.com/), but I like Biblio's site better; YMMV.
Noel
From clemc at ccc.com Thu Jan 28 22:58:56 2021
From: clemc at ccc.com (Clem Cole)
Date: Thu, 28 Jan 2021 07:58:56 -0500
Subject: [TUHS] Troff to ps
In-Reply-To: <CAC20D2NCJEhfB5NgaigE8URTKuCqjUtr4nxtrnm4P9Fg3YQ2fA@mail.gmail.com>
References: <f90685ec-29fa-d7b6-5b4d-a71aaf19476b@gmail.com>
<202007261531.06QFVqZb027062@freefriends.org>
<202007261535.06QFZvLg027250@freefriends.org>
<CAC20D2P-6U7ruF4P1HyeZ=6xcgYYKFjOLXKquzgnMFONGxgC-g@mail.gmail.com>
<202007261711.06QHB07i032409@freefriends.org>
<CAC20D2N9vMnuA9sYK2Bn_sbPySa3bpGfh93JGiQH1_iZn62P9g@mail.gmail.com>
<m1l4dJe-0036xBC@more.local> <17854.1611793153@hop.toad.com>
<CAC20D2NCJEhfB5NgaigE8URTKuCqjUtr4nxtrnm4P9Fg3YQ2fA@mail.gmail.com>
Message-ID: <CAC20D2M0ieG1_U7W5tMS3Rjd7SoTQV-SO8Rr04pOuJ08X0zU9Q@mail.gmail.com>
Ditroff per cpu was cheap. I was part of all those negotiation. There
was a buy in that way high and John points out. Actually there were two -
one to get the sources for your first internal cpu and another for the
redistribution rights.
My memory of the first license for the original ditroff 1.0 typesetter was
5k (which included the new C compiler) although it did drop later when it
went into the toolchest. But There was also redistribution fee also which
iirc you worked off / creditted against like license fees.
The entire v7 OS redistribution fee was on the 50-100k range (I've
forgotten but am likely to have that in my att files somewhete) - which was
after the 25k single cpu source license. The original binary per cpu
redistribution license started at 1.5k. Which when a minicomputer was
selling at 150k was not terrible. The problem was a PC at 5k.
I was in the room at Riki's Hyatt in Palo Alti when that was all
negotiated. This would lead to the Sys III license. It was at that MTG
Gates famous looked at the rest of us and said "you guys don't get it. The
only thing that matters is volume". He wanted to pay $50/copy max.
Anyway troff was much cheaper than the whole OS license. The per cpu
charge was very small as I said my memory is it was $5 over the base OS
license.
On Wed, Jan 27, 2021 at 8:25 PM Clem Cole <clemc at ccc.com> wrote:
> Actually It was very cheap. $5 a copy if I remember correctly Masscomp
> and Stellar just ate the cost. The adobe transcript license was also
> nominal. In both cases we realized it was cheaper than trying to keep two
> separate streams and figure out which systems we shipped it too.
>
> On Wed, Jan 27, 2021 at 7:26 PM John Gilmore <gnu at toad.com> wrote:
>
>> Greg A. Woods <woods at robohack.ca> wrote:
>> > As I recall even some of the bigger vendors such as Sun and IBM didn't
>> > offer ditroff in their base OS, but they did offer old troff. Those
>> > were the days of insane AT&T licensing and all the games competitors
>> > played around it.
>>
>> As I recall, AT&T wanted about the same amount of money for ditroff as
>> for the entire UNIX release. So, of course no UNIX vendor was going to
>> double the royalty they paid to AT&T for every customer, for a small
>> improvement in a utility that most customers didn't even use (troff).
>>
>> John
>>
>> --
> Sent from a handheld expect more typos than usual
>
--
Sent from a handheld expect more typos than usual
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210128/8f9653f7/attachment.htm>
From jon at fourwinds.com Fri Jan 29 05:51:58 2021
From: jon at fourwinds.com (Jon Steinhart)
Date: Thu, 28 Jan 2021 11:51:58 -0800
Subject: [TUHS] More archeology
Message-ID: <202101281951.10SJpw9Y138529@darkstar.fourwinds.com>
Another stack of old notebooks. I can scan these in if anyone is interested
and if they're not available elsewhere. In addition to what's below, I have
a fat notebook with the BRL CAD package docs.
These are V/W papers from Stanford - Lantz/Cheriton et. al.
Multi-process Structuring of User Interface Software
Refernce Models, Window Systems, and Concurrency
An Experiment in Integrated Multimedia Conferencing
An Architecture for Configurable User Interfaces
An Empirical Study of Distributed Application Performance
Third Generation Graphics for Distributed Systems
Virtual Terminal Management In A Multiple Process environment
Distributed Process Groups in the V Kernel
The Distributed V Kernel and its Performance for Diskless Workstations
Effective Use of Large RAM Memories on Diskless Workstations with the V Virtual Memory System
Evaluating Hardware Support for Superconcurrency with the V Kernel
Fault-tolerant Transaction Management in a Workstation Cluster
File Access Performance of Diskless Workstations
An Introduction to the V System
The Multi-Satellite Star: Structuring Parallel Computations for a Workstation Cluster
UIO: A Uniform I/O System Interface for Distributed Systems
The V Kernel: A Software Base for Distributed Systems
Other random stuff
Bitmap Graphics (SIGGRAPH '84 Course Notes, Pike et. al.)
A Window Manager with a Moduler User Interface (Whitechapel?)
IRIS-4D Superworkstation and Visual Computing
IRIS GT Graphics Architecture
Position Paper on the Importance and Application of Video Mixing Display Architectures (Jack Grimes)
A Data-Flow Manager for an Interactive Programming Environment (Paul Haeberli)
Multiple Programs in One UNIX Process (Don Libes - from ;login:)
Lightweight Processes for UNIX Implementation and Applications (Jonathan Kepecs)
A Capability Based Hierarchic Architecture for UNIX Window Management (R. D. Trammell)
MEX - A Window Manager for the IRIS (Rocky Rhodes et. al.)
Windows for UNIX at Lucasfilm (Hawley, Leffler)
Next-Generation Hardware for Windowed Displays (McGeady)
Problems Implementing Window Systems in UNIX (Gettys)
Mach: A New Kernel Foundation For UNIX Development (Accetta et. al.)
Uwm: A User Interface for X Windows (Ganearz)
Programming with Windows on the Major Workstations or Through a Glass Darkly (Daniel, Rogers)
PIX, the latest NeWS (Leler)
Ace: a syntax-driven C preprocessor Overview (Gosling)
Attribute Considerations in Raster Graphics (Bresenham)
Ten Years of Window Systems - A Retrospective View (Teitelman)
W User's Manual (Asente)
The WA Beyond Traditional Window Systems (An Overviw of The Workstation Agent (Lantz et. al., draft, marked not to to be redistributed)
Performance Measurements of the WA (Islam)
STDWIN: A Standard Window System Interface (Rossum)
Summary of Current Research (Lantz et. al. at Olivetti)
User Interfaces in Window Systems: Architechure and Implementation (Farrell, Schwartz; SIGCHI)
Introduction to the GMW Window System (Hagiya)
UNIX Window Management Systems Client-Server Interface Specification (Williams et. al., Rutherford Apleton Laboaratory)
Curves Made Trivial (Gosling)
Smart Code, Stupid Memory: A Fast X Server for a Dumb Color Frame Buffer (McCormack)
Jon
From dave at horsfall.org Fri Jan 29 07:15:17 2021
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 29 Jan 2021 08:15:17 +1100 (EST)
Subject: [TUHS] bas(1) and bs(1) videos including features and use
In-Reply-To: <1611184288.26419.9.camel@mni.thm.de>
References: <CAKH6PiX6aQ1cDOteK-An81NrMfVbJCQZ=5bOr2CUoTvQ_mKRTA@mail.gmail.com>
<alpine.BSF.2.21.9999.2101210915320.95135@aneurin.horsfall.org>
<1611184288.26419.9.camel@mni.thm.de>
Message-ID: <alpine.BSF.2.21.9999.2101290814000.36435@aneurin.horsfall.org>
On Thu, 21 Jan 2021, Hellwig Geisse wrote:
>> That would evaluate to a constant being printed (it's a direct arrayÂ
>> reference).  Did you mean something like "...[i]" instead?  That wouldÂ
>> indeed be neat...
>
> I think it doesn't matter if the index expression is a constant
> expression or not. The point here, as I understood, is the definition of
> an unnamed (and not explicitly typed) array "on the fly".
Ah, I see; thanks. Sometimes I'm too pedantic for my own good :-)
-- Dave
From wkt at tuhs.org Fri Jan 29 07:45:51 2021
From: wkt at tuhs.org (Warren Toomey)
Date: Fri, 29 Jan 2021 07:45:51 +1000
Subject: [TUHS] ching in Unix
Message-ID: <20210128214551.GA27614@minnie.tuhs.org>
https://ewe2.ninja/stuff/computers/ching/
Interesting story!
Cheers, Warren
From john at jfloren.net Fri Jan 29 08:01:04 2021
From: john at jfloren.net (John Floren)
Date: Thu, 28 Jan 2021 14:01:04 -0800
Subject: [TUHS] ching in Unix
In-Reply-To: <20210128214551.GA27614@minnie.tuhs.org>
References: <20210128214551.GA27614@minnie.tuhs.org>
Message-ID: <CAL4LZyi1D-4kaxHYViX4SqsP8gPOyynzy4zogA+1nhm2U0ZRXA@mail.gmail.com>
A few years back I remembered that 'ching' was available on the Linux
distros I played with circa 2001/2002, but not in modern systems. I
found some source and did a little tweaking to make it build/install
better on Linux: https://github.com/floren/ching
On Thu, Jan 28, 2021 at 1:46 PM Warren Toomey <wkt at tuhs.org> wrote:
>
> https://ewe2.ninja/stuff/computers/ching/
>
> Interesting story!
>
> Cheers, Warren
From ggm at algebras.org Fri Jan 29 08:10:38 2021
From: ggm at algebras.org (George Michaelson)
Date: Fri, 29 Jan 2021 08:10:38 +1000
Subject: [TUHS] ching in Unix
In-Reply-To: <20210128214551.GA27614@minnie.tuhs.org>
References: <20210128214551.GA27614@minnie.tuhs.org>
Message-ID: <CAKr6gn1i-Abt4+Ev1+K9F-3fPCYc0sP_NwdB44q3Qc7pRaWTFg@mail.gmail.com>
Ching had the best man page
Bugs: "It Furthers one to seek the great man"
On Fri, Jan 29, 2021 at 7:46 AM Warren Toomey <wkt at tuhs.org> wrote:
>
> https://ewe2.ninja/stuff/computers/ching/
>
> Interesting story!
>
> Cheers, Warren
From john at jfloren.net Fri Jan 29 08:12:05 2021
From: john at jfloren.net (John Floren)
Date: Thu, 28 Jan 2021 14:12:05 -0800
Subject: [TUHS] ching in Unix
In-Reply-To: <CAKr6gn1i-Abt4+Ev1+K9F-3fPCYc0sP_NwdB44q3Qc7pRaWTFg@mail.gmail.com>
References: <20210128214551.GA27614@minnie.tuhs.org>
<CAKr6gn1i-Abt4+Ev1+K9F-3fPCYc0sP_NwdB44q3Qc7pRaWTFg@mail.gmail.com>
Message-ID: <CAL4LZyi+ZLwcsrUHwOLE3bCeD+T9t8zPyJy9_a3nuueWwnGR-w@mail.gmail.com>
The version I have reads:
SEE ALSO
It furthers one to see the great man.
DIAGNOSTICS
The great prince issues commands,
Founds states, vests families with fiefs.
Inferior people should not be employed.
BUGS
Waiting in the mud
Brings about the arrival of the enemy.
If one is not extremely careful,
Somebody may come up from behind and strike him.
Misfortune.
On Thu, Jan 28, 2021 at 2:11 PM George Michaelson <ggm at algebras.org> wrote:
>
> Ching had the best man page
>
> Bugs: "It Furthers one to seek the great man"
>
> On Fri, Jan 29, 2021 at 7:46 AM Warren Toomey <wkt at tuhs.org> wrote:
> >
> > https://ewe2.ninja/stuff/computers/ching/
> >
> > Interesting story!
> >
> > Cheers, Warren
From ggm at algebras.org Fri Jan 29 08:32:18 2021
From: ggm at algebras.org (George Michaelson)
Date: Fri, 29 Jan 2021 08:32:18 +1000
Subject: [TUHS] ching in Unix
In-Reply-To: <CAL4LZyi+ZLwcsrUHwOLE3bCeD+T9t8zPyJy9_a3nuueWwnGR-w@mail.gmail.com>
References: <20210128214551.GA27614@minnie.tuhs.org>
<CAKr6gn1i-Abt4+Ev1+K9F-3fPCYc0sP_NwdB44q3Qc7pRaWTFg@mail.gmail.com>
<CAL4LZyi+ZLwcsrUHwOLE3bCeD+T9t8zPyJy9_a3nuueWwnGR-w@mail.gmail.com>
Message-ID: <CAKr6gn2d1uJh4CRpwjZc5J_Gcy4rNq30EHQ7A-dwPwnzNReGDw@mail.gmail.com>
The great thing about (wetware) memory is how badly it degrades under
UV. Write words, wrong context! I'm pleased after 40 years I got the
sentence right, if I gave it the wrong tag in the Manpage
On Fri, Jan 29, 2021 at 8:12 AM John Floren <john at jfloren.net> wrote:
>
> The version I have reads:
>
> SEE ALSO
> It furthers one to see the great man.
>
> DIAGNOSTICS
> The great prince issues commands,
> Founds states, vests families with fiefs.
> Inferior people should not be employed.
>
> BUGS
> Waiting in the mud
> Brings about the arrival of the enemy.
>
> If one is not extremely careful,
> Somebody may come up from behind and strike him.
> Misfortune.
>
> On Thu, Jan 28, 2021 at 2:11 PM George Michaelson <ggm at algebras.org> wrote:
> >
> > Ching had the best man page
> >
> > Bugs: "It Furthers one to seek the great man"
> >
> > On Fri, Jan 29, 2021 at 7:46 AM Warren Toomey <wkt at tuhs.org> wrote:
> > >
> > > https://ewe2.ninja/stuff/computers/ching/
> > >
> > > Interesting story!
> > >
> > > Cheers, Warren
From jon at fourwinds.com Fri Jan 29 09:05:58 2021
From: jon at fourwinds.com (Jon Steinhart)
Date: Thu, 28 Jan 2021 15:05:58 -0800
Subject: [TUHS] ching in Unix
In-Reply-To: <CAKr6gn2d1uJh4CRpwjZc5J_Gcy4rNq30EHQ7A-dwPwnzNReGDw@mail.gmail.com>
References: <20210128214551.GA27614@minnie.tuhs.org>
<CAKr6gn1i-Abt4+Ev1+K9F-3fPCYc0sP_NwdB44q3Qc7pRaWTFg@mail.gmail.com>
<CAL4LZyi+ZLwcsrUHwOLE3bCeD+T9t8zPyJy9_a3nuueWwnGR-w@mail.gmail.com>
<CAKr6gn2d1uJh4CRpwjZc5J_Gcy4rNq30EHQ7A-dwPwnzNReGDw@mail.gmail.com>
Message-ID: <202101282305.10SN5wxt164484@darkstar.fourwinds.com>
George Michaelson writes:
> The great thing about (wetware) memory is how badly it degrades under
> UV. Write words, wrong context! I'm pleased after 40 years I got the
> sentence right, if I gave it the wrong tag in the Manpage
>
> On Fri, Jan 29, 2021 at 8:12 AM John Floren <john at jfloren.net> wrote:
> >
> > The version I have reads:
> >
> > SEE ALSO
> > It furthers one to see the great man.
> >
> > DIAGNOSTICS
> > The great prince issues commands,
> > Founds states, vests families with fiefs.
> > Inferior people should not be employed.
> >
> > BUGS
> > Waiting in the mud
> > Brings about the arrival of the enemy.
> >
> > If one is not extremely careful,
> > Somebody may come up from behind and strike him.
> > Misfortune.
I have always found the I Ching to be an invaluable tool for
making difficult management decisions.
From arnold at skeeve.com Fri Jan 29 20:49:17 2021
From: arnold at skeeve.com (Arnold Robbins)
Date: Fri, 29 Jan 2021 12:49:17 +0200
Subject: [TUHS] AT&T 3B1 - Emulation available
Message-ID: <E1l5RL3-0002iv-Qv@tanda>
Hello All.
Many of you may remember the AT&T UNIX PC and 3B1. These systems
were built by Convergent Technologies and sold by AT&T. They had an
MC 68010 processor, up to 4 Meg Ram and up to 67 Meg disk. The OS
was System V Release 2 vintage. There was a built-in 1200 baud modem,
and a primitive windowing system with mouse.
I had a 3B1 as my first personal system and spent many happy hours writing
code and documentation on it.
There is an emulator for it that recently became pretty stable. The original
software floppy images are available as well. You can bring up a fairly
functional system without much difficulty.
The emulator is at https://github.com/philpem/freebee. You can install up
to two 175 Meg hard drives - a lot of space for the time.
The emulator's README.md there has links to lots of other interesting
3B1 bits, both installable software and Linux tools for exporting the
file system from disk image so it can be mounted under Linux and
importing it back. Included is an updated 'sysv' Linux kernel module
that can handle the byte-swapped file system.
I have made a pre-installed disk image available with a fair amount
of software, see https://www.skeeve.com/3b1/.
The emulator runs great under Linux; not so sure about MacOS or Windows. :-)
So, anyone wishing to journey back to 1987, have fun!
Arnold
From ron at ronnatalie.com Fri Jan 29 23:49:56 2021
From: ron at ronnatalie.com (Ronald Natalie)
Date: Fri, 29 Jan 2021 13:49:56 +0000
Subject: [TUHS] AT&T 3B1 - Emulation available
In-Reply-To: <E1l5RL3-0002iv-Qv@tanda>
References: <E1l5RL3-0002iv-Qv@tanda>
Message-ID: <em175b176f-e15d-40cc-bca0-23d0804827eb@alien>
Probably faster than the 3B1 was in real life. Being an educational
institution in NJ (Rutgers) we had all sorts of AT&T stuff donated to
us, 3B2's, 3B5's, and 3B20's.
The 3B2 was the first machine that I came across I think with a soft
power switch. Amusingly, the thing would not let you shut it down
unless you were root (apparently, you don't have power switch privs as a
normal user).
Of course, this was in contrast with the 3B20 which you powered off by
turning a knob and then holding a button down for three seconds. Yep,
phone equipment. Those who ever dealt with things like real Western
Electric 303 "broadband" modems recognized that behavior. You commanded
loopback on them the same way.
From ron at ronnatalie.com Fri Jan 29 23:49:56 2021
From: ron at ronnatalie.com (Ronald Natalie)
Date: Fri, 29 Jan 2021 13:49:56 +0000
Subject: [TUHS] AT&T 3B1 - Emulation available
In-Reply-To: <E1l5RL3-0002iv-Qv@tanda>
References: <E1l5RL3-0002iv-Qv@tanda>
Message-ID: <em175b176f-e15d-40cc-bca0-23d0804827eb@alien>
Probably faster than the 3B1 was in real life. Being an educational
institution in NJ (Rutgers) we had all sorts of AT&T stuff donated to
us, 3B2's, 3B5's, and 3B20's.
The 3B2 was the first machine that I came across I think with a soft
power switch. Amusingly, the thing would not let you shut it down
unless you were root (apparently, you don't have power switch privs as a
normal user).
Of course, this was in contrast with the 3B20 which you powered off by
turning a knob and then holding a button down for three seconds. Yep,
phone equipment. Those who ever dealt with things like real Western
Electric 303 "broadband" modems recognized that behavior. You commanded
loopback on them the same way.
From clemc at ccc.com Sat Jan 30 00:37:19 2021
From: clemc at ccc.com (Clem Cole)
Date: Fri, 29 Jan 2021 09:37:19 -0500
Subject: [TUHS] AT&T 3B1 - Emulation available
In-Reply-To: <em175b176f-e15d-40cc-bca0-23d0804827eb@alien>
References: <E1l5RL3-0002iv-Qv@tanda>
<em175b176f-e15d-40cc-bca0-23d0804827eb@alien>
Message-ID: <CAC20D2NfRSgWeMzS7qr=PJ1ubmcNnG-XDokWp=OG=xDrs9A41g@mail.gmail.com>
On Fri, Jan 29, 2021 at 9:00 AM Ronald Natalie <ron at ronnatalie.com> wrote:
> Of course, this was in contrast with the 3B20 which you powered off by
> turning a knob and then holding a button down for three seconds. Yep,
> phone equipment. Those who ever dealt with things like real Western
> Electric 303 "broadband" modems recognized that behavior. You commanded
> loopback on them the same way.
>
Ron, pls don't forget the best 3B20 power-up feature, the pull starter in
the middle (power) cabinet. Seriously there was a cable that pulled out of
the middle power box (that looked like a small engine pull starter) that
used to by-pass the batteries on a true cold boot because if it was not
there the battery power up would surge the incoming load and trip the mains.
IIRC the off button Ron describes does not completely power it off, it
just shuts it down and you can take out cards safely, but the batteries and
some subsystems are still active. True 'cold' power down is extremely
difficult. It is designed to stay powered.
As he said -- standard telco gear, 48V supplies, rack of truck batteries,
*etc*.
BTW: In the same vein, I once had a movie we all called the 'burning Alpha'
when the 'telco special packaged' DEC 4300 from DEC CSS went through its
fire testing in NJ. All equipment that was going to be in a CO or wiring
center has to be tested to see how it burns in a fire (plastic/nylon parts
in a computer rack can be nasty - and there are very tight specs). As I
understand the spec, all flames have to stay inside the cabinets.
One of the cute parts of the video is a sidebar, which is displaying the
syslog messages during the fire. There was a desire, but I don't know if
it was ever acted upon, to match the syslog messages to different
activities in the fire. During the time when it is burning, there is a
timer in the corner so they can note afterward at exactly which time,
different things were incinerated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210129/53105304/attachment.htm>
From dave at horsfall.org Sat Jan 30 05:53:26 2021
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 30 Jan 2021 06:53:26 +1100 (EST)
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <CAEoi9W4TMh=SSrk=pqprark7+ctvZLsbW8h00pf31KbtUAy_CQ@mail.gmail.com>
References: <20210124211100.GI21030@mcvoy.com>
<202101242114.10OLEYGk966708@darkstar.fourwinds.com>
<20210124212525.GJ21030@mcvoy.com>
<CAEoi9W5=toe-bb+6-zC0odkx4_C4X4FZpK4+ZJTAqCKGOCXP7w@mail.gmail.com>
<202101242333.10ONXjcI974038@darkstar.fourwinds.com>
<fc52a1a1-2136-ae39-110c-93a38e73ff94@bitsavers.org>
<202101250021.10P0L3Z2976588@darkstar.fourwinds.com>
<CAC20D2OhTW+eebyub7dVMBGZy1zoOja=ojGB_=TOjgB0wEJdHQ@mail.gmail.com>
<6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org>
<CAFH29to9GaKVxUXw8uwbeMAcF6izD=8gqhqROzCOSEA5xOA5aQ@mail.gmail.com>
<20210125160430.GR21030@mcvoy.com>
<CAEoi9W4TMh=SSrk=pqprark7+ctvZLsbW8h00pf31KbtUAy_CQ@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.2101300650230.36435@aneurin.horsfall.org>
On Mon, 25 Jan 2021, Dan Cross wrote:
> I think one of the innovations that kept it alive was that people took Tk
> itself and separated it from Tcl, so one saw bindings from any number of
> languages.
Tcl is a perfect example of how *not* to design a language; Tk is wonderful
(and I'm starting to use Perl/Tk; it's a great combinaion for GUI tools).
-- Dave
From dave at horsfall.org Sat Jan 30 06:24:53 2021
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 30 Jan 2021 07:24:53 +1100 (EST)
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <20210125172531.GP32503@mcvoy.com>
References: <20210124212525.GJ21030@mcvoy.com>
<CAEoi9W5=toe-bb+6-zC0odkx4_C4X4FZpK4+ZJTAqCKGOCXP7w@mail.gmail.com>
<202101242333.10ONXjcI974038@darkstar.fourwinds.com>
<fc52a1a1-2136-ae39-110c-93a38e73ff94@bitsavers.org>
<202101250021.10P0L3Z2976588@darkstar.fourwinds.com>
<CAC20D2OhTW+eebyub7dVMBGZy1zoOja=ojGB_=TOjgB0wEJdHQ@mail.gmail.com>
<6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org>
<CAFH29to9GaKVxUXw8uwbeMAcF6izD=8gqhqROzCOSEA5xOA5aQ@mail.gmail.com>
<20210125160430.GR21030@mcvoy.com>
<CAEoi9W4TMh=SSrk=pqprark7+ctvZLsbW8h00pf31KbtUAy_CQ@mail.gmail.com>
<20210125172531.GP32503@mcvoy.com>
Message-ID: <alpine.BSF.2.21.9999.2101300722310.36435@aneurin.horsfall.org>
On Mon, 25 Jan 2021, Larry McVoy wrote:
> We did something similar, I hated Tcl so much I paid a friend to make a
> compiler for a very C like language that compiled to Tcl byte codes.
> It's really what I'd like to see C evolve to:
>
> http://little-lang.org
Wow - another language for my collection :-) Looks neat.
-- Dave
From lm at mcvoy.com Sat Jan 30 06:31:33 2021
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 29 Jan 2021 12:31:33 -0800
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <alpine.BSF.2.21.9999.2101300722310.36435@aneurin.horsfall.org>
References: <202101242333.10ONXjcI974038@darkstar.fourwinds.com>
<fc52a1a1-2136-ae39-110c-93a38e73ff94@bitsavers.org>
<202101250021.10P0L3Z2976588@darkstar.fourwinds.com>
<CAC20D2OhTW+eebyub7dVMBGZy1zoOja=ojGB_=TOjgB0wEJdHQ@mail.gmail.com>
<6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org>
<CAFH29to9GaKVxUXw8uwbeMAcF6izD=8gqhqROzCOSEA5xOA5aQ@mail.gmail.com>
<20210125160430.GR21030@mcvoy.com>
<CAEoi9W4TMh=SSrk=pqprark7+ctvZLsbW8h00pf31KbtUAy_CQ@mail.gmail.com>
<20210125172531.GP32503@mcvoy.com>
<alpine.BSF.2.21.9999.2101300722310.36435@aneurin.horsfall.org>
Message-ID: <20210129203133.GB4227@mcvoy.com>
On Sat, Jan 30, 2021 at 07:24:53AM +1100, Dave Horsfall wrote:
> On Mon, 25 Jan 2021, Larry McVoy wrote:
>
> >We did something similar, I hated Tcl so much I paid a friend to make a
> >compiler for a very C like language that compiled to Tcl byte codes. It's
> >really what I'd like to see C evolve to:
> >
> >http://little-lang.org
>
> Wow - another language for my collection :-) Looks neat.
It is if you like C syntax and you like perl usefulness. It's sort of a
blend of those. Has some short comings but I like it.
From dave at horsfall.org Sat Jan 30 08:02:18 2021
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 30 Jan 2021 09:02:18 +1100 (EST)
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <CAD2gp_RsiayPg+xyEYK7AwrkuO0NS7f4o4pZ6JwVPuaoBWDdTA@mail.gmail.com>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
<202101242045.10OKjDvA964774@darkstar.fourwinds.com>
<20210124211100.GI21030@mcvoy.com>
<202101242114.10OLEYGk966708@darkstar.fourwinds.com>
<20210124212525.GJ21030@mcvoy.com>
<CAEoi9W5=toe-bb+6-zC0odkx4_C4X4FZpK4+ZJTAqCKGOCXP7w@mail.gmail.com>
<202101242333.10ONXjcI974038@darkstar.fourwinds.com>
<fc52a1a1-2136-ae39-110c-93a38e73ff94@bitsavers.org>
<202101250021.10P0L3Z2976588@darkstar.fourwinds.com>
<CAC20D2OhTW+eebyub7dVMBGZy1zoOja=ojGB_=TOjgB0wEJdHQ@mail.gmail.com>
<6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org>
<CAFH29to9GaKVxUXw8uwbeMAcF6izD=8gqhqROzCOSEA5xOA5aQ@mail.gmail.com>
<CAD2gp_RsiayPg+xyEYK7AwrkuO0NS7f4o4pZ6JwVPuaoBWDdTA@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.2101300853400.36435@aneurin.horsfall.org>
On Mon, 25 Jan 2021, John Cowan wrote:
> I've been messing around with X.680, aka ASN/1. Its reputation for
> horrible evilness, I find, primarily comes from the Packed Encoding
> Rules and the interface with statically typed languages, both of which
> require dealing with the schema language programmatically. But if you
> want to drive it from a dynamically typed language, it's dirt simple: to
> write, see what data type you have, output a type and length and value
> (or type and value and terminator), and there you are.
I was never quite sure what to make of ASN.1 and BER; it seemed to solve
the problem of OpenLDAP applications talking to each other (and I got
quite good at reading wire traces), but it somehow seemed wrong when every
box was running FreeBSD on Intel/AMD.
-- Dave
From woods at robohack.ca Sat Jan 30 09:52:44 2021
From: woods at robohack.ca (Greg A. Woods)
Date: Fri, 29 Jan 2021 15:52:44 -0800
Subject: [TUHS] mmap() (was: Memory management in Dennis Ritchie's C
Compiler)
In-Reply-To: <b25c1d11-871c-21b1-2f45-9d171d45bc3e@computer.org>
References: <20200817192715.22D9518C09E@mercury.lcs.mit.edu>
<b25c1d11-871c-21b1-2f45-9d171d45bc3e@computer.org>
Message-ID: <m1l5dZE-0036xBC@more.local>
At Mon, 17 Aug 2020 17:52:08 -0700, Rob Gingell <gingell at computer.org> wrote:
Subject: Re: [TUHS] Memory management in Dennis Ritchie's C Compiler
>
> mmap() is descended from TENEX's PMAP, which is a simplified
> descendant of the file/process memory integration provided by
> Multics. (Other antecedents I leave to more informed genealogists than
> I.)
Indeed. I see mmap() as just a poor-man's version of Multics segments,
and with it being bolted on after the fact, and without integrated
language and compiler support, that makes it far less useful.
> Multics was most definitely not portable due to its unique hardware
> constraints (Intel's 432 being an exception).
Well the basic design of Multics would/does fit reasonably well onto the
iAPX-386 / IA-32 architecture, though a lone x86 CPU would have been a
bit more limited in some capabilities than the Multics hardware was.
I think that if more than just OS/2 had made good use of all of the
segmentation features of iAPX-386 then possibly CPU designers (including
beyond Intel) would have had some incentive to continue to improve it
and make it more efficient and effective and indeed to carry it on in
full-fledged manner to the x86-64 architecture as well.
I think the failure of the iAPX-432 to meet performance expectations,
especially with silicon limitations of the day (along with the i960MX
never really getting full public exposure), put OS people in general off
the idea of building anything better than Unix, which of course only
needs a single flat address space and thus ran just fine on the much
better performing silicon already available at the same time.
I personally also think another problem that limited the porting and
evolution of Multics, and the creation of new systems using much more of
its design (and thus which favoured the growth of Unix in many ways) was
that a lot of commercial OS people were put off by the idea of going
with an object oriented model all the way from the languages on top and
down through the OS and into the hardware. Too many users were (are)
still running applications written in FORTRAN and Cobol and similar, and
these were already implemented to use more direct read/write I/O models
for data access that Unix supports well.
--
Greg A. Woods <gwoods at acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <woods at robohack.ca>
Planix, Inc. <woods at planix.com> Avoncote Farms <woods at avoncote.ca>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP Digital Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210129/87f2eec7/attachment.sig>
From cmhanson at eschatologist.net Sat Jan 30 09:50:23 2021
From: cmhanson at eschatologist.net (Chris Hanson)
Date: Fri, 29 Jan 2021 15:50:23 -0800
Subject: [TUHS] /bin vs /sbin
In-Reply-To: <202007211822.06LIMBJ4018831@freefriends.org>
References: <862d8a34-456d-33c1-7ef0-58c6e8089de9@tnetconsulting.net>
<202007211822.06LIMBJ4018831@freefriends.org>
Message-ID: <40DAE471-0FDF-4891-8E66-817E1B7059C7@eschatologist.net>
On Jul 21, 2020, at 11:22 AM, arnold at skeeve.com wrote:
>
> This is also when /var came into being for log files and such;
> again - it was per machine space, so it lived either on a small disk
> in the workstation or on a per-client chunk of space on the server
> if the client was totally diskless.
And then NeXT went a little further, making /etc, /var, and /tmp symlinks to entries in /private, so each netbooted system only needed two main mount points:
/ could be read-only, served from any number of servers for load-balancing, and shared among all systems running NEXTSTEP (even across architectures, thanks to multi-arch binaries).
/private could be per-machine and could come from a server near that machine to manage load.
It meant your admins just needed the MAC address of a new system (to create the NetInfo /machines entry for it) and it would be immediately usable on the network.
All of our NeXT-derived operating systems still follow this filesystem layout, though only a tiny number (relatively speaking) are netbooted these days. (I don't even remember whether netboot is supported any more…)
-- Chris
From cym224 at gmail.com Sat Jan 30 11:50:42 2021
From: cym224 at gmail.com (Nemo Nusquam)
Date: Fri, 29 Jan 2021 20:50:42 -0500
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <alpine.BSF.2.21.9999.2101300853400.36435@aneurin.horsfall.org>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
<202101242045.10OKjDvA964774@darkstar.fourwinds.com>
<20210124211100.GI21030@mcvoy.com>
<202101242114.10OLEYGk966708@darkstar.fourwinds.com>
<20210124212525.GJ21030@mcvoy.com>
<CAEoi9W5=toe-bb+6-zC0odkx4_C4X4FZpK4+ZJTAqCKGOCXP7w@mail.gmail.com>
<202101242333.10ONXjcI974038@darkstar.fourwinds.com>
<fc52a1a1-2136-ae39-110c-93a38e73ff94@bitsavers.org>
<202101250021.10P0L3Z2976588@darkstar.fourwinds.com>
<CAC20D2OhTW+eebyub7dVMBGZy1zoOja=ojGB_=TOjgB0wEJdHQ@mail.gmail.com>
<6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org>
<CAFH29to9GaKVxUXw8uwbeMAcF6izD=8gqhqROzCOSEA5xOA5aQ@mail.gmail.com>
<CAD2gp_RsiayPg+xyEYK7AwrkuO0NS7f4o4pZ6JwVPuaoBWDdTA@mail.gmail.com>
<alpine.BSF.2.21.9999.2101300853400.36435@aneurin.horsfall.org>
Message-ID: <6014BB72.204@gmail.com>
On 29/01/2021 17:02, Dave Horsfall wrote:
> On Mon, 25 Jan 2021, John Cowan wrote:
>
>> I've been messing around with X.680, aka ASN/1. Its reputation for
>> horrible evilness, I find, primarily comes from the Packed Encoding
>> Rules and the interface with statically typed languages, both of
>> which require dealing with the schema language programmatically. But
>> if you want to drive it from a dynamically typed language, it's dirt
>> simple: to write, see what data type you have, output a type and
>> length and value (or type and value and terminator), and there you are.
>
> I was never quite sure what to make of ASN.1 and BER; it seemed to
> solve the problem of OpenLDAP applications talking to each other (and
> I got quite good at reading wire traces), but it somehow seemed wrong
> when every box was running FreeBSD on Intel/AMD.
>
> -- Dave
BER does not work for digital signatures (because encodings are not
unique), hence DER.
N.
From rich.salz at gmail.com Sat Jan 30 13:51:46 2021
From: rich.salz at gmail.com (Richard Salz)
Date: Fri, 29 Jan 2021 22:51:46 -0500
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <alpine.BSF.2.21.9999.2101300853400.36435@aneurin.horsfall.org>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
<202101242045.10OKjDvA964774@darkstar.fourwinds.com>
<20210124211100.GI21030@mcvoy.com>
<202101242114.10OLEYGk966708@darkstar.fourwinds.com>
<20210124212525.GJ21030@mcvoy.com>
<CAEoi9W5=toe-bb+6-zC0odkx4_C4X4FZpK4+ZJTAqCKGOCXP7w@mail.gmail.com>
<202101242333.10ONXjcI974038@darkstar.fourwinds.com>
<fc52a1a1-2136-ae39-110c-93a38e73ff94@bitsavers.org>
<202101250021.10P0L3Z2976588@darkstar.fourwinds.com>
<CAC20D2OhTW+eebyub7dVMBGZy1zoOja=ojGB_=TOjgB0wEJdHQ@mail.gmail.com>
<6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org>
<CAFH29to9GaKVxUXw8uwbeMAcF6izD=8gqhqROzCOSEA5xOA5aQ@mail.gmail.com>
<CAD2gp_RsiayPg+xyEYK7AwrkuO0NS7f4o4pZ6JwVPuaoBWDdTA@mail.gmail.com>
<alpine.BSF.2.21.9999.2101300853400.36435@aneurin.horsfall.org>
Message-ID: <CAFH29tqx00nGYE4DaUfDroav-qprqCszEz2O=wDmMAG6UKJNmg@mail.gmail.com>
PER is not the reason for the hatred of ASN.1, it's more that the specs
were created by a pay-to-play organization that fought against TCP/IP, the
specs were not freely available for long years, BER was too flexible, and
the DER rules were almost too hard to get right. Just a terse summary
because this is probably off-topic for TUHS.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210129/709acd4d/attachment.htm>
From cowan at ccil.org Sat Jan 30 17:28:41 2021
From: cowan at ccil.org (John Cowan)
Date: Sat, 30 Jan 2021 02:28:41 -0500
Subject: [TUHS] ching in Unix
In-Reply-To: <202101282305.10SN5wxt164484@darkstar.fourwinds.com>
References: <20210128214551.GA27614@minnie.tuhs.org>
<CAKr6gn1i-Abt4+Ev1+K9F-3fPCYc0sP_NwdB44q3Qc7pRaWTFg@mail.gmail.com>
<CAL4LZyi+ZLwcsrUHwOLE3bCeD+T9t8zPyJy9_a3nuueWwnGR-w@mail.gmail.com>
<CAKr6gn2d1uJh4CRpwjZc5J_Gcy4rNq30EHQ7A-dwPwnzNReGDw@mail.gmail.com>
<202101282305.10SN5wxt164484@darkstar.fourwinds.com>
Message-ID: <CAD2gp_Re7gmF-93_LchNY77V=5v5crCyNUHAyGs79ASLnQLzeQ@mail.gmail.com>
On Thu, Jan 28, 2021 at 6:06 PM Jon Steinhart <jon at fourwinds.com> wrote:
> I have always found the I Ching to be an invaluable tool for
> making difficult management decisions.
>
Or any other kind of decisions.
Some of you may find amusing my (regrettably incomplete) "The Unix Power
Classic: A book about the Unix Way and its power" at <
http://vrici.lojban.org/~cowan/upc/>. Section 41 seems to be the most
popular:
Thoughtful hackers hear about Unix
and try to use it.
Ordinary hackers hear about Unix
and mess about with it a little.
Thoughtless hackers hear about Unix
and crack wise about it.
It wouldn't be Unix
if there weren't wisecracks about it.
So we establish the following rules:
The most brilliant Unix seems the most obscure.
Advanced Unix seems like retrocomputing.
The most powerful code seems like just loops and conditionals.
The clearest code seems to be opaque.
The sharpest tools seem inadequate.
Solid code seems flaky.
Stable code seems to change.
Great methodologies don't have boundaries.
Great talent doesn't code fast.
Great music makes no sound.
The ideal elephant has no shape.
The Unix Way has no name.
Yet for just this reason
it brings things to perfection.
John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org
The native charset of SMS messages supports English, French, mainland
Scandinavian languages, German, Italian, Spanish with no accents, and
GREEK SHOUTING. Everything else has to be Unicode, which means you get
only 70 16-bit characters in a text instead of 160 7-bit characters.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210130/7f5a4324/attachment.htm>
From athornton at gmail.com Sat Jan 30 17:31:37 2021
From: athornton at gmail.com (Adam Thornton)
Date: Sat, 30 Jan 2021 00:31:37 -0700
Subject: [TUHS] ching in Unix
In-Reply-To: <CAL4LZyi+ZLwcsrUHwOLE3bCeD+T9t8zPyJy9_a3nuueWwnGR-w@mail.gmail.com>
References: <20210128214551.GA27614@minnie.tuhs.org>
<CAKr6gn1i-Abt4+Ev1+K9F-3fPCYc0sP_NwdB44q3Qc7pRaWTFg@mail.gmail.com>
<CAL4LZyi+ZLwcsrUHwOLE3bCeD+T9t8zPyJy9_a3nuueWwnGR-w@mail.gmail.com>
Message-ID: <CAP2nic0fzXnbYbu_WAhGHrXTNHkpeBWpxxz270BmW9aJoHXHVg@mail.gmail.com>
Those of us who listened to the Firesign Theatre may recognize this one.
DIAGNOSTICS
> The great prince issues commands,
> Founds states, vests families with fiefs.
> Inferior people should not be employed.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210130/599a47b8/attachment.htm>
From coppero1237 at gmail.com Sun Jan 31 05:01:32 2021
From: coppero1237 at gmail.com (Tyler Adams)
Date: Sat, 30 Jan 2021 21:01:32 +0200
Subject: [TUHS] Favorite unix design principles?
In-Reply-To: <CAKH6PiXKjksEpQOMMMQTbcsMvX2thz3WzqjoRWJAsXnZ4Eq_iQ@mail.gmail.com>
References: <CAEuQd1D00TvjQWfSYvawS45qMnG_cThdHig2rFco+emzxEYsQA@mail.gmail.com>
<alpine.DEB.2.21.2101250729510.22271@sd-119843.dedibox.fr>
<CAKH6PiWY3ggz7Rv6Y0mNr_MH5+z7duHhFH9xf-rKgsvhQvCWgA@mail.gmail.com>
<CAEuQd1DO1_gv-ByrM91DLQ3kqm7pap9bK+4JsQKJoNqD1Z-GZw@mail.gmail.com>
<CAKH6PiXKjksEpQOMMMQTbcsMvX2thz3WzqjoRWJAsXnZ4Eq_iQ@mail.gmail.com>
Message-ID: <CAEuQd1C91GOZ7eJ6U+_hUz31AEDB-rfR=0tH6fdbkz8RCESBkA@mail.gmail.com>
For sure, I've seen at least two interesting changes:
- market forces have pushed fast iteration and fast prototyping into the
mainstream in the form of Silicon valley "fail fast" culture and the
"agile" culture. This, over the disastrous "waterfall" style, has led to a
momentous improvement in overall productivity improvements.
- As coders get pulled away from the machine and performance is less and
less in coders hands, engineers aren't sucked into (premature) optimization
as much.
Tyler
On Sat, Jan 30, 2021 at 6:10 AM M Douglas McIlroy <
m.douglas.mcilroy at dartmouth.edu> wrote:
> Have you spotted an evolutionary trend toward better, more productive
> programmers? Or has programmer productivity risen across the board due to
> better tools? Arguably what's happened is that principle has been
> self-obsoleting, for we have cut back on the demand for unskilled (i.e.
> less capable) programmers. A broad moral principle may be in play:
> programmers should work to put themselves out of business, i.e. it is wrong
> to be doing the same kind of work (or working in the same way) tomorrowas
> yesterday.
>
> Doug
>
>
> On Tue, Jan 26, 2021 at 5:23 AM Tyler Adams <coppero1237 at gmail.com> wrote:
>
>> Looking at the 1978 list, the last one really stands out:
>>
>> "Use tools in preference to unskilled help to lighten a programming task"
>> -- The concept of unskilled help for a programming task...doesn't really
>> exist in 2020. The only special case is doing unskilled labor yourself.
>> What unskilled tasks did people used to do back in the day?
>>
>> Tyler
>>
>>
>> On Tue, Jan 26, 2021 at 4:07 AM M Douglas McIlroy <
>> m.douglas.mcilroy at dartmouth.edu> wrote:
>>
>>> It might be interesting to compare your final list with the two lists in
>>> the 1978 special issue of the BSTJ--one in the Foreword, the other in the
>>> revised version of the Ritchi/Thompson article from the CACM. How have
>>> perceptions or values changed over time?
>>>
>>> Doug
>>>
>>>
>>> On Mon, Jan 25, 2021 at 7:32 AM Steve Nickolas <usotsuki at buric.co>
>>> wrote:
>>>
>>>> On Mon, 25 Jan 2021, Tyler Adams wrote:
>>>>
>>>> > I'm writing about my 5 favorite unix design principles on my blog this
>>>> > week, and it got me wondering what others' favorite unix design
>>>> principles
>>>> > are? For reference, mine are:
>>>> >
>>>> > - Rule of Separation (from TAOUP <
>>>> http://catb.org/~esr/writings/taoup/html/>
>>>> > )
>>>> > - Let the Machine Do the Dirty Work (from Elements of Programming
>>>> Style)
>>>> > - Rule of Silence (from TAOUP <
>>>> http://catb.org/~esr/writings/taoup/html/>)
>>>> > - Data Dominates (Rob Pike #5)
>>>> > - The SPOT (Single Point of Truth) Rule (from TAOUP
>>>> > <http://catb.org/~esr/writings/taoup/html/>)
>>>> >
>>>> > Tyler
>>>> >
>>>>
>>>> 1. Pipes
>>>> 2. Text as the preferred format for input and output
>>>> 3. 'Most everything as a file
>>>> 4. The idea of simple tools that are optimized for a single task
>>>> 5. A powerful scripting language built into the system that, combined
>>>> with
>>>> 1-4, makes writing new tools heaps easier.
>>>>
>>>> -uso.
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210130/0e04bbe1/attachment.htm>
From jon at fourwinds.com Sun Jan 31 05:50:32 2021
From: jon at fourwinds.com (Jon Steinhart)
Date: Sat, 30 Jan 2021 11:50:32 -0800
Subject: [TUHS] Favorite unix design principles?
In-Reply-To: <CAEuQd1C91GOZ7eJ6U+_hUz31AEDB-rfR=0tH6fdbkz8RCESBkA@mail.gmail.com>
References: <CAEuQd1D00TvjQWfSYvawS45qMnG_cThdHig2rFco+emzxEYsQA@mail.gmail.com>
<alpine.DEB.2.21.2101250729510.22271@sd-119843.dedibox.fr>
<CAKH6PiWY3ggz7Rv6Y0mNr_MH5+z7duHhFH9xf-rKgsvhQvCWgA@mail.gmail.com>
<CAEuQd1DO1_gv-ByrM91DLQ3kqm7pap9bK+4JsQKJoNqD1Z-GZw@mail.gmail.com>
<CAKH6PiXKjksEpQOMMMQTbcsMvX2thz3WzqjoRWJAsXnZ4Eq_iQ@mail.gmail.com>
<CAEuQd1C91GOZ7eJ6U+_hUz31AEDB-rfR=0tH6fdbkz8RCESBkA@mail.gmail.com>
Message-ID: <202101301950.10UJoWeA456408@darkstar.fourwinds.com>
Tyler Adams writes:
>
> For sure, I've seen at least two interesting changes:
> - market forces have pushed fast iteration and fast prototyping into the
> mainstream in the form of Silicon valley "fail fast" culture and the
> "agile" culture. This, over the disastrous "waterfall" style, has led to a
> momentous improvement in overall productivity improvements.
> - As coders get pulled away from the machine and performance is less and
> less in coders hands, engineers aren't sucked into (premature) optimization
> as much.
It's interesting in more than one way.
The "fail fast" culture seems to result in a lot more failure than I find
acceptable.
As performance is less in coders hands, performance is getting worse. I
haven't seen less premature optimization, I've just seen more premature
optimization that didn't optimize anything.
My take is that the above changes have resulted in less reliable products
with poor performance being delivered more quickly. I'm just kind of weird
in that I'd prefer better products delivered more slowly. Especially since
much of what counts as a product these days is just churn to keep people
buying, not to provide things that are actually useful.
From coppero1237 at gmail.com Sun Jan 31 06:06:45 2021
From: coppero1237 at gmail.com (Tyler Adams)
Date: Sat, 30 Jan 2021 22:06:45 +0200
Subject: [TUHS] Favorite unix design principles?
In-Reply-To: <202101301950.10UJoWeA456408@darkstar.fourwinds.com>
References: <CAEuQd1D00TvjQWfSYvawS45qMnG_cThdHig2rFco+emzxEYsQA@mail.gmail.com>
<alpine.DEB.2.21.2101250729510.22271@sd-119843.dedibox.fr>
<CAKH6PiWY3ggz7Rv6Y0mNr_MH5+z7duHhFH9xf-rKgsvhQvCWgA@mail.gmail.com>
<CAEuQd1DO1_gv-ByrM91DLQ3kqm7pap9bK+4JsQKJoNqD1Z-GZw@mail.gmail.com>
<CAKH6PiXKjksEpQOMMMQTbcsMvX2thz3WzqjoRWJAsXnZ4Eq_iQ@mail.gmail.com>
<CAEuQd1C91GOZ7eJ6U+_hUz31AEDB-rfR=0tH6fdbkz8RCESBkA@mail.gmail.com>
<202101301950.10UJoWeA456408@darkstar.fourwinds.com>
Message-ID: <CAEuQd1Dpbcs=kd0XynnwUkYoL_UgRfd355ttZcsLiB8Hf4gEXQ@mail.gmail.com>
Really? Except for one particularly incompetent team, I cannot recall
working with nor reviewing code that sacrificed clarity for performance.
Tyler
On Sat, Jan 30, 2021 at 9:51 PM Jon Steinhart <jon at fourwinds.com> wrote:
> Tyler Adams writes:
> >
> > For sure, I've seen at least two interesting changes:
> > - market forces have pushed fast iteration and fast prototyping into the
> > mainstream in the form of Silicon valley "fail fast" culture and the
> > "agile" culture. This, over the disastrous "waterfall" style, has led to
> a
> > momentous improvement in overall productivity improvements.
> > - As coders get pulled away from the machine and performance is less and
> > less in coders hands, engineers aren't sucked into (premature)
> optimization
> > as much.
>
> It's interesting in more than one way.
>
> The "fail fast" culture seems to result in a lot more failure than I find
> acceptable.
>
> As performance is less in coders hands, performance is getting worse. I
> haven't seen less premature optimization, I've just seen more premature
> optimization that didn't optimize anything.
>
> My take is that the above changes have resulted in less reliable products
> with poor performance being delivered more quickly. I'm just kind of weird
> in that I'd prefer better products delivered more slowly. Especially since
> much of what counts as a product these days is just churn to keep people
> buying, not to provide things that are actually useful.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210130/7dd9998f/attachment.htm>
From clemc at ccc.com Sun Jan 31 07:28:26 2021
From: clemc at ccc.com (Clem Cole)
Date: Sat, 30 Jan 2021 16:28:26 -0500
Subject: [TUHS] Favorite unix design principles?
In-Reply-To: <CAEuQd1Dpbcs=kd0XynnwUkYoL_UgRfd355ttZcsLiB8Hf4gEXQ@mail.gmail.com>
References: <CAEuQd1D00TvjQWfSYvawS45qMnG_cThdHig2rFco+emzxEYsQA@mail.gmail.com>
<alpine.DEB.2.21.2101250729510.22271@sd-119843.dedibox.fr>
<CAKH6PiWY3ggz7Rv6Y0mNr_MH5+z7duHhFH9xf-rKgsvhQvCWgA@mail.gmail.com>
<CAEuQd1DO1_gv-ByrM91DLQ3kqm7pap9bK+4JsQKJoNqD1Z-GZw@mail.gmail.com>
<CAKH6PiXKjksEpQOMMMQTbcsMvX2thz3WzqjoRWJAsXnZ4Eq_iQ@mail.gmail.com>
<CAEuQd1C91GOZ7eJ6U+_hUz31AEDB-rfR=0tH6fdbkz8RCESBkA@mail.gmail.com>
<202101301950.10UJoWeA456408@darkstar.fourwinds.com>
<CAEuQd1Dpbcs=kd0XynnwUkYoL_UgRfd355ttZcsLiB8Hf4gEXQ@mail.gmail.com>
Message-ID: <CAC20D2M0_X3Tw7371jnrMvUiDBOFDRW1Y6Cycmu_QKnWhotU4A@mail.gmail.com>
Tyler - I'm with Jon on this. I'll pick on Apple here. It used to be a
huge difference between MSFT SW and MacOS was that the systems folks at
Apple really tested the system and the result was that Mac OS with way
really stable. My system never panic'ed except when I ran Windows under
parallels. After 3-4 years ago, that stopped being true. Crashes occur,
just like Windows BSD. It's not unusual for my Mac to panic just letting
it run overnight - which is just backups and the like. Yes, I have a
multiple monitors, a zillion windows open etc..
I come downstairs and the screen is blank (it should be, I have it turn off
after no activity), but I move the mouse or try to type something --
nothing wakes the system up again. I've chased it to Mac OS running out of
memory and not gracefully handling the lowe memory situation. Sad, I have
16G of RAM a 1T SSD and many TB of memory on Thunderbolt 3 connectivity.
Look I grew up with a 256K byte RAM Unix V6 system on an 11/34, 3 RK05s and
an RK07 for storage. We swapped. Yeah, I never ran a window manager, but
he had a number of 9600K terminals on DH11's and we were happy. You could
see it swapping like mad, but that system never crashed. It just ran and
ran and ran.
IMO, this is what I think Jon is referring. Those systems were stable
because we tested them and found and fixed the issue. These days, Apple
no longer cares about Mac OS because iOS is where they now put their
effort, although I'm not super impressed there either, but I also don't
push it like I do Mac OS. Sad really. If I could get the day-2-day
applications that I need to work on FreeBSD, I suspect I would be there in
a heartbeat.
Clem
á§
On Sat, Jan 30, 2021 at 3:07 PM Tyler Adams <coppero1237 at gmail.com> wrote:
> Really? Except for one particularly incompetent team, I cannot recall
> working with nor reviewing code that sacrificed clarity for performance.
>
> Tyler
>
>
> On Sat, Jan 30, 2021 at 9:51 PM Jon Steinhart <jon at fourwinds.com> wrote:
>
>> Tyler Adams writes:
>> >
>> > For sure, I've seen at least two interesting changes:
>> > - market forces have pushed fast iteration and fast prototyping into the
>> > mainstream in the form of Silicon valley "fail fast" culture and the
>> > "agile" culture. This, over the disastrous "waterfall" style, has led
>> to a
>> > momentous improvement in overall productivity improvements.
>> > - As coders get pulled away from the machine and performance is less and
>> > less in coders hands, engineers aren't sucked into (premature)
>> optimization
>> > as much.
>>
>> It's interesting in more than one way.
>>
>> The "fail fast" culture seems to result in a lot more failure than I find
>> acceptable.
>>
>> As performance is less in coders hands, performance is getting worse. I
>> haven't seen less premature optimization, I've just seen more premature
>> optimization that didn't optimize anything.
>>
>> My take is that the above changes have resulted in less reliable products
>> with poor performance being delivered more quickly. I'm just kind of
>> weird
>> in that I'd prefer better products delivered more slowly. Especially
>> since
>> much of what counts as a product these days is just churn to keep people
>> buying, not to provide things that are actually useful.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210130/5b72a527/attachment.htm>
From dave at horsfall.org Sun Jan 31 07:42:56 2021
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 31 Jan 2021 08:42:56 +1100 (EST)
Subject: [TUHS] Favorite unix design principles?
In-Reply-To: <CAC20D2M0_X3Tw7371jnrMvUiDBOFDRW1Y6Cycmu_QKnWhotU4A@mail.gmail.com>
References: <CAEuQd1D00TvjQWfSYvawS45qMnG_cThdHig2rFco+emzxEYsQA@mail.gmail.com>
<alpine.DEB.2.21.2101250729510.22271@sd-119843.dedibox.fr>
<CAKH6PiWY3ggz7Rv6Y0mNr_MH5+z7duHhFH9xf-rKgsvhQvCWgA@mail.gmail.com>
<CAEuQd1DO1_gv-ByrM91DLQ3kqm7pap9bK+4JsQKJoNqD1Z-GZw@mail.gmail.com>
<CAKH6PiXKjksEpQOMMMQTbcsMvX2thz3WzqjoRWJAsXnZ4Eq_iQ@mail.gmail.com>
<CAEuQd1C91GOZ7eJ6U+_hUz31AEDB-rfR=0tH6fdbkz8RCESBkA@mail.gmail.com>
<202101301950.10UJoWeA456408@darkstar.fourwinds.com>
<CAEuQd1Dpbcs=kd0XynnwUkYoL_UgRfd355ttZcsLiB8Hf4gEXQ@mail.gmail.com>
<CAC20D2M0_X3Tw7371jnrMvUiDBOFDRW1Y6Cycmu_QKnWhotU4A@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.2101310838270.36435@aneurin.horsfall.org>
On Sat, 30 Jan 2021, Clem Cole wrote:
> Look I grew up with a 256K byte RAM Unix V6 system on an 11/34, 3 RK05s
> and an RK07 for storage. We swapped. Yeah, I never ran a window
> manager, but he had a number of 9600K terminals on DH11's and we were
> happy. You could see it swapping like mad, but that system never
> crashed. It just ran and ran and ran.
You had *three* RK05s, an RK07, *and* a DH11? We had just two, and a
crappy DJ-11 on our /40s. Pretty much stable; any bugs were fixed on the
spot because we had the source code after all.
(They were configured that way to run RSX-11D, then that issue of the BSTJ
appeared; the rest is history.)
-- Dave
From coppero1237 at gmail.com Sun Jan 31 07:45:38 2021
From: coppero1237 at gmail.com (Tyler Adams)
Date: Sat, 30 Jan 2021 23:45:38 +0200
Subject: [TUHS] Favorite unix design principles?
In-Reply-To: <CAC20D2M0_X3Tw7371jnrMvUiDBOFDRW1Y6Cycmu_QKnWhotU4A@mail.gmail.com>
References: <CAEuQd1D00TvjQWfSYvawS45qMnG_cThdHig2rFco+emzxEYsQA@mail.gmail.com>
<alpine.DEB.2.21.2101250729510.22271@sd-119843.dedibox.fr>
<CAKH6PiWY3ggz7Rv6Y0mNr_MH5+z7duHhFH9xf-rKgsvhQvCWgA@mail.gmail.com>
<CAEuQd1DO1_gv-ByrM91DLQ3kqm7pap9bK+4JsQKJoNqD1Z-GZw@mail.gmail.com>
<CAKH6PiXKjksEpQOMMMQTbcsMvX2thz3WzqjoRWJAsXnZ4Eq_iQ@mail.gmail.com>
<CAEuQd1C91GOZ7eJ6U+_hUz31AEDB-rfR=0tH6fdbkz8RCESBkA@mail.gmail.com>
<202101301950.10UJoWeA456408@darkstar.fourwinds.com>
<CAEuQd1Dpbcs=kd0XynnwUkYoL_UgRfd355ttZcsLiB8Hf4gEXQ@mail.gmail.com>
<CAC20D2M0_X3Tw7371jnrMvUiDBOFDRW1Y6Cycmu_QKnWhotU4A@mail.gmail.com>
Message-ID: <CAEuQd1B+gGMnDtU59ooFzYHnK2cfOxj5FhufE-GTNjkKU4_TYA@mail.gmail.com>
Fair points about macOS, I hated using my mac in 2018 (thankfully I've
lived in linux bliss since), but I wouldn't say macOS is representative of
the software industry as a whole. Especially as you said iOS is Apple's
real cash cow and apple's been focusing on better *mac hardware *and from
what I hear that M1 delivers*.*
The modern software industry is mostly over the browser (or an app), and
honestly almost every site I use these days is pretty fast and stable.
Unless it has too many ads.
Tyler
On Sat, Jan 30, 2021 at 11:28 PM Clem Cole <clemc at ccc.com> wrote:
> Tyler - I'm with Jon on this. I'll pick on Apple here. It used to be a
> huge difference between MSFT SW and MacOS was that the systems folks at
> Apple really tested the system and the result was that Mac OS with way
> really stable. My system never panic'ed except when I ran Windows under
> parallels. After 3-4 years ago, that stopped being true. Crashes occur,
> just like Windows BSD. It's not unusual for my Mac to panic just letting
> it run overnight - which is just backups and the like. Yes, I have a
> multiple monitors, a zillion windows open etc..
>
>
> I come downstairs and the screen is blank (it should be, I have it turn
> off after no activity), but I move the mouse or try to type something --
> nothing wakes the system up again. I've chased it to Mac OS running out of
> memory and not gracefully handling the lowe memory situation. Sad, I have
> 16G of RAM a 1T SSD and many TB of memory on Thunderbolt 3 connectivity.
>
> Look I grew up with a 256K byte RAM Unix V6 system on an 11/34, 3 RK05s
> and an RK07 for storage. We swapped. Yeah, I never ran a window manager,
> but he had a number of 9600K terminals on DH11's and we were happy. You
> could see it swapping like mad, but that system never crashed. It just ran
> and ran and ran.
>
> IMO, this is what I think Jon is referring. Those systems were stable
> because we tested them and found and fixed the issue. These days, Apple
> no longer cares about Mac OS because iOS is where they now put their
> effort, although I'm not super impressed there either, but I also don't
> push it like I do Mac OS. Sad really. If I could get the day-2-day
> applications that I need to work on FreeBSD, I suspect I would be there in
> a heartbeat.
>
> Clem
> á§
>
> On Sat, Jan 30, 2021 at 3:07 PM Tyler Adams <coppero1237 at gmail.com> wrote:
>
>> Really? Except for one particularly incompetent team, I cannot recall
>> working with nor reviewing code that sacrificed clarity for performance.
>>
>> Tyler
>>
>>
>> On Sat, Jan 30, 2021 at 9:51 PM Jon Steinhart <jon at fourwinds.com> wrote:
>>
>>> Tyler Adams writes:
>>> >
>>> > For sure, I've seen at least two interesting changes:
>>> > - market forces have pushed fast iteration and fast prototyping into
>>> the
>>> > mainstream in the form of Silicon valley "fail fast" culture and the
>>> > "agile" culture. This, over the disastrous "waterfall" style, has led
>>> to a
>>> > momentous improvement in overall productivity improvements.
>>> > - As coders get pulled away from the machine and performance is less
>>> and
>>> > less in coders hands, engineers aren't sucked into (premature)
>>> optimization
>>> > as much.
>>>
>>> It's interesting in more than one way.
>>>
>>> The "fail fast" culture seems to result in a lot more failure than I find
>>> acceptable.
>>>
>>> As performance is less in coders hands, performance is getting worse. I
>>> haven't seen less premature optimization, I've just seen more premature
>>> optimization that didn't optimize anything.
>>>
>>> My take is that the above changes have resulted in less reliable products
>>> with poor performance being delivered more quickly. I'm just kind of
>>> weird
>>> in that I'd prefer better products delivered more slowly. Especially
>>> since
>>> much of what counts as a product these days is just churn to keep people
>>> buying, not to provide things that are actually useful.
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210130/ac87303c/attachment.htm>
From dave at horsfall.org Sun Jan 31 08:27:10 2021
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 31 Jan 2021 09:27:10 +1100 (EST)
Subject: [TUHS] reboot(2) system call
In-Reply-To: <m1l4dtA-0036xBC@more.local>
References: <CANCZdfosFGpBKw0wOx9nYgAWpeVNuRd-h6Nu5PLgZyyCuezZKA@mail.gmail.com>
<m1l4dtA-0036xBC@more.local>
Message-ID: <alpine.BSF.2.21.9999.2101310922250.36435@aneurin.horsfall.org>
On Tue, 26 Jan 2021, Greg A. Woods wrote:
> The lore I was told at the time was that you alwasy ran three and that
> it didn't matter if they were all on the same line with semicolons or
> not because of the very fact that the second one would block.
What I was taught was:
% sync
% sync
% sync
and never:
% sync; sync; sync
The theory was that by waiting for the shell prompt each time, it gave the
buffer pool enough time to be flushed.
> The third one was just for superstitious good luck, and just in case
> there was a process still running and writing to a filesystem.
Never heard that theory, but naturally you did a "ps ax" first, didn't
you?
-- Dave
From lm at mcvoy.com Sun Jan 31 08:28:54 2021
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 30 Jan 2021 14:28:54 -0800
Subject: [TUHS] Favorite unix design principles?
In-Reply-To: <CAC20D2M0_X3Tw7371jnrMvUiDBOFDRW1Y6Cycmu_QKnWhotU4A@mail.gmail.com>
References: <CAEuQd1D00TvjQWfSYvawS45qMnG_cThdHig2rFco+emzxEYsQA@mail.gmail.com>
<alpine.DEB.2.21.2101250729510.22271@sd-119843.dedibox.fr>
<CAKH6PiWY3ggz7Rv6Y0mNr_MH5+z7duHhFH9xf-rKgsvhQvCWgA@mail.gmail.com>
<CAEuQd1DO1_gv-ByrM91DLQ3kqm7pap9bK+4JsQKJoNqD1Z-GZw@mail.gmail.com>
<CAKH6PiXKjksEpQOMMMQTbcsMvX2thz3WzqjoRWJAsXnZ4Eq_iQ@mail.gmail.com>
<CAEuQd1C91GOZ7eJ6U+_hUz31AEDB-rfR=0tH6fdbkz8RCESBkA@mail.gmail.com>
<202101301950.10UJoWeA456408@darkstar.fourwinds.com>
<CAEuQd1Dpbcs=kd0XynnwUkYoL_UgRfd355ttZcsLiB8Hf4gEXQ@mail.gmail.com>
<CAC20D2M0_X3Tw7371jnrMvUiDBOFDRW1Y6Cycmu_QKnWhotU4A@mail.gmail.com>
Message-ID: <20210130222854.GN4227@mcvoy.com>
On Sat, Jan 30, 2021 at 04:28:26PM -0500, Clem Cole wrote:
> If I could get the day-2-day
> applications that I need to work on FreeBSD, I suspect I would be there in
> a heartbeat.
I dunno about that. I tried out FreeBSD a couple of years ago when
Netflix was flirting with me. The installer hasn't seen any loving in
30 years it would seem. The disk setup tool sucks just as bad as it
did back in 1988.
I remember when Linux was this bad in the .90ish releases. A long time
ago. Now their install is painless, it's every bit as good as Windows
and maybe better. And it got that way fast, I remember doing an install
on some machine around 1998 or 1999, I didn't have a mouse plugged in,
no worries, you could just move around with the keyboard. X11 came up
as part of the install, the entire install was graphical and seamless.
FreeBSD is stuck in the 1990's in terms of user interface. They've done
some good stuff in the kernel but it's not an end user system, I'd argue
that the install is much worse than any of the Sun installers and I
started with BSD.
From lm at mcvoy.com Sun Jan 31 08:31:09 2021
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 30 Jan 2021 14:31:09 -0800
Subject: [TUHS] Favorite unix design principles?
In-Reply-To: <CAEuQd1B+gGMnDtU59ooFzYHnK2cfOxj5FhufE-GTNjkKU4_TYA@mail.gmail.com>
References: <CAEuQd1D00TvjQWfSYvawS45qMnG_cThdHig2rFco+emzxEYsQA@mail.gmail.com>
<alpine.DEB.2.21.2101250729510.22271@sd-119843.dedibox.fr>
<CAKH6PiWY3ggz7Rv6Y0mNr_MH5+z7duHhFH9xf-rKgsvhQvCWgA@mail.gmail.com>
<CAEuQd1DO1_gv-ByrM91DLQ3kqm7pap9bK+4JsQKJoNqD1Z-GZw@mail.gmail.com>
<CAKH6PiXKjksEpQOMMMQTbcsMvX2thz3WzqjoRWJAsXnZ4Eq_iQ@mail.gmail.com>
<CAEuQd1C91GOZ7eJ6U+_hUz31AEDB-rfR=0tH6fdbkz8RCESBkA@mail.gmail.com>
<202101301950.10UJoWeA456408@darkstar.fourwinds.com>
<CAEuQd1Dpbcs=kd0XynnwUkYoL_UgRfd355ttZcsLiB8Hf4gEXQ@mail.gmail.com>
<CAC20D2M0_X3Tw7371jnrMvUiDBOFDRW1Y6Cycmu_QKnWhotU4A@mail.gmail.com>
<CAEuQd1B+gGMnDtU59ooFzYHnK2cfOxj5FhufE-GTNjkKU4_TYA@mail.gmail.com>
Message-ID: <20210130223109.GO4227@mcvoy.com>
On Sat, Jan 30, 2021 at 11:45:38PM +0200, Tyler Adams wrote:
> Fair points about macOS, I hated using my mac in 2018 (thankfully I've
> lived in linux bliss since), but I wouldn't say macOS is representative of
> the software industry as a whole. Especially as you said iOS is Apple's
> real cash cow and apple's been focusing on better *mac hardware *and from
> what I hear that M1 delivers*.*
M1 is a stunning pile of systems work. Warms my heart. Seems to be
faster, uses less power, and cheaper than Intel's best. Kudos to Apple
for that.
> The modern software industry is mostly over the browser (or an app), and
> honestly almost every site I use these days is pretty fast and stable.
> Unless it has too many ads.
Ad blocker to the rescue, I use ublock origin and it works great.
--lm
From lm at mcvoy.com Sun Jan 31 08:31:54 2021
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 30 Jan 2021 14:31:54 -0800
Subject: [TUHS] reboot(2) system call
In-Reply-To: <alpine.BSF.2.21.9999.2101310922250.36435@aneurin.horsfall.org>
References: <CANCZdfosFGpBKw0wOx9nYgAWpeVNuRd-h6Nu5PLgZyyCuezZKA@mail.gmail.com>
<m1l4dtA-0036xBC@more.local>
<alpine.BSF.2.21.9999.2101310922250.36435@aneurin.horsfall.org>
Message-ID: <20210130223154.GP4227@mcvoy.com>
On Sun, Jan 31, 2021 at 09:27:10AM +1100, Dave Horsfall wrote:
> On Tue, 26 Jan 2021, Greg A. Woods wrote:
>
> >The lore I was told at the time was that you alwasy ran three and that it
> >didn't matter if they were all on the same line with semicolons or not
> >because of the very fact that the second one would block.
>
> What I was taught was:
>
> % sync
> % sync
> % sync
>
> and never:
>
> % sync; sync; sync
>
> The theory was that by waiting for the shell prompt each time, it gave the
> buffer pool enough time to be flushed.
I was taught the exact same thing and for the same reasons.
From imp at bsdimp.com Sun Jan 31 08:37:02 2021
From: imp at bsdimp.com (Warner Losh)
Date: Sat, 30 Jan 2021 15:37:02 -0700
Subject: [TUHS] reboot(2) system call
In-Reply-To: <20210130223154.GP4227@mcvoy.com>
References: <CANCZdfosFGpBKw0wOx9nYgAWpeVNuRd-h6Nu5PLgZyyCuezZKA@mail.gmail.com>
<m1l4dtA-0036xBC@more.local>
<alpine.BSF.2.21.9999.2101310922250.36435@aneurin.horsfall.org>
<20210130223154.GP4227@mcvoy.com>
Message-ID: <CANCZdfqQZdrDSH40dDfr5A6cSb75Pg-JAb6u-2FzpPTQWdSn+w@mail.gmail.com>
On Sat, Jan 30, 2021 at 3:32 PM Larry McVoy <lm at mcvoy.com> wrote:
> On Sun, Jan 31, 2021 at 09:27:10AM +1100, Dave Horsfall wrote:
> > On Tue, 26 Jan 2021, Greg A. Woods wrote:
> >
> > >The lore I was told at the time was that you alwasy ran three and that
> it
> > >didn't matter if they were all on the same line with semicolons or not
> > >because of the very fact that the second one would block.
> >
> > What I was taught was:
> >
> > % sync
> > % sync
> > % sync
> >
> > and never:
> >
> > % sync; sync; sync
> >
> > The theory was that by waiting for the shell prompt each time, it gave
> the
> > buffer pool enough time to be flushed.
>
> I was taught the exact same thing and for the same reasons.
>
Yes. There's no actual code in the System V or earlier kernels to block any
of the sync calls. At least none I could find in examining all the 'leaked
sources' I could find on the internet.
sync just schedules I/O. There's nothing in the system call that waits for
anything: it just goes through the list of all non-busy buffers calling the
driver's strategy routine and marking the buffer as busy.
Later systems, like SunOS did have a wait, but that was a later addition,
done a half a dozen different ways. BSD had one that waited for a while,
but gave up after some tens of seconds...
Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210130/65e1554e/attachment.htm>
From cowan at ccil.org Sun Jan 31 09:09:27 2021
From: cowan at ccil.org (John Cowan)
Date: Sat, 30 Jan 2021 18:09:27 -0500
Subject: [TUHS] Favorite unix design principles?
In-Reply-To: <CAC20D2M0_X3Tw7371jnrMvUiDBOFDRW1Y6Cycmu_QKnWhotU4A@mail.gmail.com>
References: <CAEuQd1D00TvjQWfSYvawS45qMnG_cThdHig2rFco+emzxEYsQA@mail.gmail.com>
<alpine.DEB.2.21.2101250729510.22271@sd-119843.dedibox.fr>
<CAKH6PiWY3ggz7Rv6Y0mNr_MH5+z7duHhFH9xf-rKgsvhQvCWgA@mail.gmail.com>
<CAEuQd1DO1_gv-ByrM91DLQ3kqm7pap9bK+4JsQKJoNqD1Z-GZw@mail.gmail.com>
<CAKH6PiXKjksEpQOMMMQTbcsMvX2thz3WzqjoRWJAsXnZ4Eq_iQ@mail.gmail.com>
<CAEuQd1C91GOZ7eJ6U+_hUz31AEDB-rfR=0tH6fdbkz8RCESBkA@mail.gmail.com>
<202101301950.10UJoWeA456408@darkstar.fourwinds.com>
<CAEuQd1Dpbcs=kd0XynnwUkYoL_UgRfd355ttZcsLiB8Hf4gEXQ@mail.gmail.com>
<CAC20D2M0_X3Tw7371jnrMvUiDBOFDRW1Y6Cycmu_QKnWhotU4A@mail.gmail.com>
Message-ID: <CAD2gp_T4ECxt_x6OZ1RkTymiV4w6fcVD8fb91aVeqhNVWHifkw@mail.gmail.com>
On Sat, Jan 30, 2021 at 4:29 PM Clem Cole <clemc at ccc.com> wrote:
> These days, Apple no longer cares about Mac OS because iOS is where they
> now put their effort, although I'm not super impressed there either, but I
> also don't push it like I do Mac OS. Sad really. If I could get the
> day-2-day applications that I need to work on FreeBSD, I suspect I would be
> there in a heartbeat.
>
Decades ago I worked out the lifecycle of tech companies:
1) Engineering-driven: the goal is to make and sell high-quality products.
DEC and HP were like this for a long time.
2) Sales-driven: the goal is to sell products, high-quality or not. Too
many examples to specify.
3) Finance-driven: the goal is to make money, whether you sell products or
not. The classic case here is Carnegie Steel. When Carnegie told his
direct reports they were going into the railroad business and they
protested that the company knew nothing about it, he said "Carnegie Steel
isn't about making steel, it's about making money, and anyone who forgets
that is fired."
4) Survival-driven: the goal is to keep the company going whether you make
money or not. Auto companies just after bailouts are in this step. In
particular, Chrysler was bailed out in 1979 and again in 2009: see Tom
Paxton's song "I'm Changing My Name To Chrysler" (covered by Arlo and Pete
on _Precious Friends_).
On Sat, Jan 30, 2021 at 4:43 PM Dave Horsfall <dave at horsfall.org> wrote:
You had *three* RK05s, an RK07, *and* a DH11? We had just two, and a
> crappy DJ-11 on our /40s. Pretty much stable; any bugs were fixed on the
> spot because we had the source code after all.
>
I cut my teeth on a PDP-8 with a single TU58 DECtape and a TD8/E controller
(no interrupts, no data break cycles; I/O was more or less analogous to
terminal I/O). Uphill both ways in the snow.
John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org
So they play that [tune] on their fascist banjos, eh?
--Great-Souled Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210130/d717dd20/attachment-0001.htm>
From grog at lemis.com Sun Jan 31 09:11:19 2021
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Sun, 31 Jan 2021 10:11:19 +1100
Subject: [TUHS] FreeBSD behind the times? (was: Favorite unix design
principles?)
In-Reply-To: <20210130222854.GN4227@mcvoy.com>
References: <CAEuQd1D00TvjQWfSYvawS45qMnG_cThdHig2rFco+emzxEYsQA@mail.gmail.com>
<alpine.DEB.2.21.2101250729510.22271@sd-119843.dedibox.fr>
<CAKH6PiWY3ggz7Rv6Y0mNr_MH5+z7duHhFH9xf-rKgsvhQvCWgA@mail.gmail.com>
<CAEuQd1DO1_gv-ByrM91DLQ3kqm7pap9bK+4JsQKJoNqD1Z-GZw@mail.gmail.com>
<CAKH6PiXKjksEpQOMMMQTbcsMvX2thz3WzqjoRWJAsXnZ4Eq_iQ@mail.gmail.com>
<CAEuQd1C91GOZ7eJ6U+_hUz31AEDB-rfR=0tH6fdbkz8RCESBkA@mail.gmail.com>
<202101301950.10UJoWeA456408@darkstar.fourwinds.com>
<CAEuQd1Dpbcs=kd0XynnwUkYoL_UgRfd355ttZcsLiB8Hf4gEXQ@mail.gmail.com>
<CAC20D2M0_X3Tw7371jnrMvUiDBOFDRW1Y6Cycmu_QKnWhotU4A@mail.gmail.com>
<20210130222854.GN4227@mcvoy.com>
Message-ID: <20210130231119.GA33905@eureka.lemis.com>
On Saturday, 30 January 2021 at 14:28:54 -0800, Larry McVoy wrote:
> On Sat, Jan 30, 2021 at 04:28:26PM -0500, Clem Cole wrote:
>> If I could get the day-2-day
>> applications that I need to work on FreeBSD, I suspect I would be there in
>> a heartbeat.
>
> I dunno about that. I tried out FreeBSD a couple of years ago when
> Netflix was flirting with me. The installer hasn't seen any loving in
> 30 years it would seem. The disk setup tool sucks just as bad as it
> did back in 1988.
You could be right there, for some value of 1988 (FreeBSD came into
being in 1992). The tools work without being good. But how often do
you use them? I've been using FreeBSD since the beginning, and I
can't recall when I last used the disk partitioning tool, though I'm
sure that when I did I overrode a lot of (all?) the suggestions.
> I remember when Linux was this bad in the .90ish releases. A long
> time ago. Now their install is painless, it's every bit as good as
> Windows and maybe better.
FWIW, I find Microsoft "Windows" installation terminally confusing
(that's what you were talking about, right?). And I've run into
serious problems with various Linux installations too. That doesn't
make the FreeBSD tools better, but maybe it relativizes it.
> And it got that way fast, I remember doing an install on some
> machine around 1998 or 1999, I didn't have a mouse plugged in, no
> worries, you could just move around with the keyboard. X11 came up
> as part of the install, the entire install was graphical and
> seamless.
The FreeBSD installer *does* install X if you select it.
> FreeBSD is stuck in the 1990's in terms of user interface.
You're still talking about the installer, aren't you? The normal user
interface is via the shell, which hasn't changed, and for a good
reason.
> They've done some good stuff in the kernel but it's not an end user
> system,
There I have to agree with you. A little TLC would go a long way.
But I hope that you're not advocating the "change your GUI with your
underwear" attitude that Microsoft, Apple and many Linux distros
have. One of the reasons I don't use Linux is because every time I
try, the interface has changed.
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
-------------- 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/20210131/41166829/attachment.sig>
From lm at mcvoy.com Sun Jan 31 09:17:50 2021
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 30 Jan 2021 15:17:50 -0800
Subject: [TUHS] FreeBSD behind the times? (was: Favorite unix design
principles?)
In-Reply-To: <20210130231119.GA33905@eureka.lemis.com>
References: <alpine.DEB.2.21.2101250729510.22271@sd-119843.dedibox.fr>
<CAKH6PiWY3ggz7Rv6Y0mNr_MH5+z7duHhFH9xf-rKgsvhQvCWgA@mail.gmail.com>
<CAEuQd1DO1_gv-ByrM91DLQ3kqm7pap9bK+4JsQKJoNqD1Z-GZw@mail.gmail.com>
<CAKH6PiXKjksEpQOMMMQTbcsMvX2thz3WzqjoRWJAsXnZ4Eq_iQ@mail.gmail.com>
<CAEuQd1C91GOZ7eJ6U+_hUz31AEDB-rfR=0tH6fdbkz8RCESBkA@mail.gmail.com>
<202101301950.10UJoWeA456408@darkstar.fourwinds.com>
<CAEuQd1Dpbcs=kd0XynnwUkYoL_UgRfd355ttZcsLiB8Hf4gEXQ@mail.gmail.com>
<CAC20D2M0_X3Tw7371jnrMvUiDBOFDRW1Y6Cycmu_QKnWhotU4A@mail.gmail.com>
<20210130222854.GN4227@mcvoy.com>
<20210130231119.GA33905@eureka.lemis.com>
Message-ID: <20210130231750.GQ4227@mcvoy.com>
On Sun, Jan 31, 2021 at 10:11:19AM +1100, Greg 'groggy' Lehey wrote:
> > I remember when Linux was this bad in the .90ish releases. A long
> > time ago. Now their install is painless, it's every bit as good as
> > Windows and maybe better.
>
> FWIW, I find Microsoft "Windows" installation terminally confusing
> (that's what you were talking about, right?). And I've run into
> serious problems with various Linux installations too. That doesn't
> make the FreeBSD tools better, but maybe it relativizes it.
Um, my mother could install any Linux system today and 10-20 years ago.
There is not the slightest chance that she could install FreeBSD.
> The FreeBSD installer *does* install X if you select it.
Linux installers start in X. No "select it" required.
> > FreeBSD is stuck in the 1990's in terms of user interface.
>
> You're still talking about the installer, aren't you?
Yup. If FreeBSD wants anyone to use it, fix that installer. 99.99%
of people would give up after seeing that, you'd never get them to
userland.
> > They've done some good stuff in the kernel but it's not an end user
> > system,
>
> There I have to agree with you. A little TLC would go a long way.
> But I hope that you're not advocating the "change your GUI with your
> underwear" attitude that Microsoft, Apple and many Linux distros
> have. One of the reasons I don't use Linux is because every time I
> try, the interface has changed.
Try xubuntu, that's what I use. Pretty light weight UI but all the
parts are there and it doesn't change much.
From cowan at ccil.org Sun Jan 31 09:20:53 2021
From: cowan at ccil.org (John Cowan)
Date: Sat, 30 Jan 2021 18:20:53 -0500
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <CAFH29tqx00nGYE4DaUfDroav-qprqCszEz2O=wDmMAG6UKJNmg@mail.gmail.com>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
<202101242045.10OKjDvA964774@darkstar.fourwinds.com>
<20210124211100.GI21030@mcvoy.com>
<202101242114.10OLEYGk966708@darkstar.fourwinds.com>
<20210124212525.GJ21030@mcvoy.com>
<CAEoi9W5=toe-bb+6-zC0odkx4_C4X4FZpK4+ZJTAqCKGOCXP7w@mail.gmail.com>
<202101242333.10ONXjcI974038@darkstar.fourwinds.com>
<fc52a1a1-2136-ae39-110c-93a38e73ff94@bitsavers.org>
<202101250021.10P0L3Z2976588@darkstar.fourwinds.com>
<CAC20D2OhTW+eebyub7dVMBGZy1zoOja=ojGB_=TOjgB0wEJdHQ@mail.gmail.com>
<6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org>
<CAFH29to9GaKVxUXw8uwbeMAcF6izD=8gqhqROzCOSEA5xOA5aQ@mail.gmail.com>
<CAD2gp_RsiayPg+xyEYK7AwrkuO0NS7f4o4pZ6JwVPuaoBWDdTA@mail.gmail.com>
<alpine.BSF.2.21.9999.2101300853400.36435@aneurin.horsfall.org>
<CAFH29tqx00nGYE4DaUfDroav-qprqCszEz2O=wDmMAG6UKJNmg@mail.gmail.com>
Message-ID: <CAD2gp_T95Bt6VAF8M=Q4uc4mwgp1jzjqa6dOh2JKiwiQbpR+HQ@mail.gmail.com>
Those were just examples. The hard part is parsing schemas, especially if
you're writing in C and don't know about yacc and lex. That code tends to
be horribly buggy.
But unless you need to support PER (which outright requires the schema) or
unless you are trying to map ASN.1 compound objects to C structs or the
equivalent, you can just process the whole thing in the same way you would
JSON, except that it's binary and there are more types. Easy-peasy,
especially in a dynamically typed language.
Once there was a person on the xml-dev mailing list who kept repeating
himself, insisting on the superiority of ASN.1 to XML. Finally I told him
privately that his emails could be encoded in PER by using 0x01 to
represent him (as the value of the author field) and allowing the
recipients to reconstruct the message from that! He took it in good part.
John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org
Don't be so humble. You're not that great.
--Golda Meir
On Fri, Jan 29, 2021 at 10:52 PM Richard Salz <rich.salz at gmail.com> wrote:
> PER is not the reason for the hatred of ASN.1, it's more that the specs
> were created by a pay-to-play organization that fought against TCP/IP, the
> specs were not freely available for long years, BER was too flexible, and
> the DER rules were almost too hard to get right. Just a terse summary
> because this is probably off-topic for TUHS.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210130/cfed99b6/attachment.htm>
From imp at bsdimp.com Sun Jan 31 09:22:49 2021
From: imp at bsdimp.com (Warner Losh)
Date: Sat, 30 Jan 2021 16:22:49 -0700
Subject: [TUHS] FreeBSD behind the times? (was: Favorite unix design
principles?)
In-Reply-To: <20210130231750.GQ4227@mcvoy.com>
References: <alpine.DEB.2.21.2101250729510.22271@sd-119843.dedibox.fr>
<CAKH6PiWY3ggz7Rv6Y0mNr_MH5+z7duHhFH9xf-rKgsvhQvCWgA@mail.gmail.com>
<CAEuQd1DO1_gv-ByrM91DLQ3kqm7pap9bK+4JsQKJoNqD1Z-GZw@mail.gmail.com>
<CAKH6PiXKjksEpQOMMMQTbcsMvX2thz3WzqjoRWJAsXnZ4Eq_iQ@mail.gmail.com>
<CAEuQd1C91GOZ7eJ6U+_hUz31AEDB-rfR=0tH6fdbkz8RCESBkA@mail.gmail.com>
<202101301950.10UJoWeA456408@darkstar.fourwinds.com>
<CAEuQd1Dpbcs=kd0XynnwUkYoL_UgRfd355ttZcsLiB8Hf4gEXQ@mail.gmail.com>
<CAC20D2M0_X3Tw7371jnrMvUiDBOFDRW1Y6Cycmu_QKnWhotU4A@mail.gmail.com>
<20210130222854.GN4227@mcvoy.com> <20210130231119.GA33905@eureka.lemis.com>
<20210130231750.GQ4227@mcvoy.com>
Message-ID: <CANCZdfrzZrHeyuGFevGCaeHk7QfiBj7+jZGrB2MQ+N6tYW0vYw@mail.gmail.com>
On Sat, Jan 30, 2021 at 4:19 PM Larry McVoy <lm at mcvoy.com> wrote:
> On Sun, Jan 31, 2021 at 10:11:19AM +1100, Greg 'groggy' Lehey wrote:
> > > I remember when Linux was this bad in the .90ish releases. A long
> > > time ago. Now their install is painless, it's every bit as good as
> > > Windows and maybe better.
> >
> > FWIW, I find Microsoft "Windows" installation terminally confusing
> > (that's what you were talking about, right?). And I've run into
> > serious problems with various Linux installations too. That doesn't
> > make the FreeBSD tools better, but maybe it relativizes it.
>
> Um, my mother could install any Linux system today and 10-20 years ago.
> There is not the slightest chance that she could install FreeBSD.
>
I find that hard to believe. The defaults just work on the vast majority of
systems, even if the interface is text-based and not a fancy GUI...
> > The FreeBSD installer *does* install X if you select it.
>
> Linux installers start in X. No "select it" required.
>
Yea. Once upon a time, this was super dangerous. These days it's kinda
required.
> > > FreeBSD is stuck in the 1990's in terms of user interface.
> >
> > You're still talking about the installer, aren't you?
>
> Yup. If FreeBSD wants anyone to use it, fix that installer. 99.99%
> of people would give up after seeing that, you'd never get them to
> userland.
>
No argument there... Part of the problem is that, up until relatively
lately, the whole X experience sucked really badly on FreeBSD. Now that it
doesn't suck, it's time for a re-evaluation...
> > > They've done some good stuff in the kernel but it's not an end user
> > > system,
> >
> > There I have to agree with you. A little TLC would go a long way.
> > But I hope that you're not advocating the "change your GUI with your
> > underwear" attitude that Microsoft, Apple and many Linux distros
> > have. One of the reasons I don't use Linux is because every time I
> > try, the interface has changed.
>
> Try xubuntu, that's what I use. Pretty light weight UI but all the
> parts are there and it doesn't change much.
>
But yet it's not stuck?
Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210130/2d7fa7d0/attachment.htm>
From jon at fourwinds.com Sun Jan 31 09:22:56 2021
From: jon at fourwinds.com (Jon Steinhart)
Date: Sat, 30 Jan 2021 15:22:56 -0800
Subject: [TUHS] Favorite unix design principles?
In-Reply-To: <CAD2gp_T4ECxt_x6OZ1RkTymiV4w6fcVD8fb91aVeqhNVWHifkw@mail.gmail.com>
References: <CAEuQd1D00TvjQWfSYvawS45qMnG_cThdHig2rFco+emzxEYsQA@mail.gmail.com>
<alpine.DEB.2.21.2101250729510.22271@sd-119843.dedibox.fr>
<CAKH6PiWY3ggz7Rv6Y0mNr_MH5+z7duHhFH9xf-rKgsvhQvCWgA@mail.gmail.com>
<CAEuQd1DO1_gv-ByrM91DLQ3kqm7pap9bK+4JsQKJoNqD1Z-GZw@mail.gmail.com>
<CAKH6PiXKjksEpQOMMMQTbcsMvX2thz3WzqjoRWJAsXnZ4Eq_iQ@mail.gmail.com>
<CAEuQd1C91GOZ7eJ6U+_hUz31AEDB-rfR=0tH6fdbkz8RCESBkA@mail.gmail.com>
<202101301950.10UJoWeA456408@darkstar.fourwinds.com>
<CAEuQd1Dpbcs=kd0XynnwUkYoL_UgRfd355ttZcsLiB8Hf4gEXQ@mail.gmail.com>
<CAC20D2M0_X3Tw7371jnrMvUiDBOFDRW1Y6Cycmu_QKnWhotU4A@mail.gmail.com>
<CAD2gp_T4ECxt_x6OZ1RkTymiV4w6fcVD8fb91aVeqhNVWHifkw@mail.gmail.com>
Message-ID: <202101302322.10UNMuoB465188@darkstar.fourwinds.com>
John Cowan writes:
>
> Decades ago I worked out the lifecycle of tech companies:
>
> 1) Engineering-driven: the goal is to make and sell high-quality products.
> DEC and HP were like this for a long time.
>
> 2) Sales-driven: the goal is to sell products, high-quality or not. Too
> many examples to specify.
>
> 3) Finance-driven: the goal is to make money, whether you sell products or
> not. The classic case here is Carnegie Steel. When Carnegie told his
> direct reports they were going into the railroad business and they
> protested that the company knew nothing about it, he said "Carnegie Steel
> isn't about making steel, it's about making money, and anyone who forgets
> that is fired."
>
> 4) Survival-driven: the goal is to keep the company going whether you make
> money or not. Auto companies just after bailouts are in this step. In
> particular, Chrysler was bailed out in 1979 and again in 2009: see Tom
> Paxton's song "I'm Changing My Name To Chrysler" (covered by Arlo and Pete
> on _Precious Friends_).
Don't want to get too off topic here, but I consider myself fortunate
to have spent the prime of my career working on #1. I always believed
that if one made high quality-products that met a customer's need that
the rest would take care of itself. Yeah, I'm naive. I see 2-4 as
indicative of Silicon Valley today where I don't think that I could work.
It's no longer about making great things, it's about making money, if if
absolutely necessary, making something to support that goal. If you took
the trouble to read the Microsoft antitrust trial depositions, you'd see
that this was exactly Bill Gate's MO. He would try to tank competition
through any means necessary except making a better product; that only
happened when everything else failed.
I've probably ranted about this before, but to me this is emblematic of
how America has lost its way. My big evil villians are Jack Welch and
Bill Gates. When I was growing up and kids were asked "What do you want
to be when you grow up?", the answer was always astronaut first, then
doctor, lawyer, engineer, and so on. Post Microsoft, the answer was "I
want to be as rich as Bill Gates." People just want the outcome without
having to do any of the work, and just want the results without the joy
of actual accomplishment. I find it sad.
Jon
From lm at mcvoy.com Sun Jan 31 09:31:18 2021
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 30 Jan 2021 15:31:18 -0800
Subject: [TUHS] [SPAM] Re: FreeBSD behind the times? (was: Favorite unix
design principles?)
In-Reply-To: <CANCZdfrzZrHeyuGFevGCaeHk7QfiBj7+jZGrB2MQ+N6tYW0vYw@mail.gmail.com>
References: <CAEuQd1DO1_gv-ByrM91DLQ3kqm7pap9bK+4JsQKJoNqD1Z-GZw@mail.gmail.com>
<CAKH6PiXKjksEpQOMMMQTbcsMvX2thz3WzqjoRWJAsXnZ4Eq_iQ@mail.gmail.com>
<CAEuQd1C91GOZ7eJ6U+_hUz31AEDB-rfR=0tH6fdbkz8RCESBkA@mail.gmail.com>
<202101301950.10UJoWeA456408@darkstar.fourwinds.com>
<CAEuQd1Dpbcs=kd0XynnwUkYoL_UgRfd355ttZcsLiB8Hf4gEXQ@mail.gmail.com>
<CAC20D2M0_X3Tw7371jnrMvUiDBOFDRW1Y6Cycmu_QKnWhotU4A@mail.gmail.com>
<20210130222854.GN4227@mcvoy.com>
<20210130231119.GA33905@eureka.lemis.com>
<20210130231750.GQ4227@mcvoy.com>
<CANCZdfrzZrHeyuGFevGCaeHk7QfiBj7+jZGrB2MQ+N6tYW0vYw@mail.gmail.com>
Message-ID: <20210130233117.GR4568@mcvoy.com>
On Sat, Jan 30, 2021 at 04:22:49PM -0700, Warner Losh wrote:
> On Sat, Jan 30, 2021 at 4:19 PM Larry McVoy <lm at mcvoy.com> wrote:
>
> > On Sun, Jan 31, 2021 at 10:11:19AM +1100, Greg 'groggy' Lehey wrote:
> > > > I remember when Linux was this bad in the .90ish releases. A long
> > > > time ago. Now their install is painless, it's every bit as good as
> > > > Windows and maybe better.
> > >
> > > FWIW, I find Microsoft "Windows" installation terminally confusing
> > > (that's what you were talking about, right?). And I've run into
> > > serious problems with various Linux installations too. That doesn't
> > > make the FreeBSD tools better, but maybe it relativizes it.
> >
> > Um, my mother could install any Linux system today and 10-20 years ago.
> > There is not the slightest chance that she could install FreeBSD.
>
> I find that hard to believe. The defaults just work on the vast majority of
> systems, even if the interface is text-based and not a fancy GUI...
I speak from experience of trying to install FreeBSD on a netflix server
a couple of years back. It wasn't pleasant and it seems pretty identical
to the installer I used decades ago.
> > > > FreeBSD is stuck in the 1990's in terms of user interface.
> > >
> > > You're still talking about the installer, aren't you?
> >
> > Yup. If FreeBSD wants anyone to use it, fix that installer. 99.99%
> > of people would give up after seeing that, you'd never get them to
> > userland.
>
> No argument there... Part of the problem is that, up until relatively
> lately, the whole X experience sucked really badly on FreeBSD. Now that it
> doesn't suck, it's time for a re-evaluation...
It's 20 years past the time for that re-evaluation. Seriously, Linux
distros have been installing in X for at least 20 years, I think maybe
more. If they can do it....
> > > > They've done some good stuff in the kernel but it's not an end user
> > > > system,
> > >
> > > There I have to agree with you. A little TLC would go a long way.
> > > But I hope that you're not advocating the "change your GUI with your
> > > underwear" attitude that Microsoft, Apple and many Linux distros
> > > have. One of the reasons I don't use Linux is because every time I
> > > try, the interface has changed.
> >
> > Try xubuntu, that's what I use. Pretty light weight UI but all the
> > parts are there and it doesn't change much.
>
> But yet it's not stuck?
Nope, it's not remotely stuck. I get it, you like FreeBSD. That's fine
but be honest about where it is. How many of the developers with a commit
bit actually run FreeBSD on their desktop and laptops? As their daily
platform?
From jon at fourwinds.com Sun Jan 31 09:37:29 2021
From: jon at fourwinds.com (Jon Steinhart)
Date: Sat, 30 Jan 2021 15:37:29 -0800
Subject: [TUHS] [SPAM] Re: FreeBSD behind the times? (was: Favorite unix
design principles?)
In-Reply-To: <20210130233117.GR4568@mcvoy.com>
References: <CAEuQd1DO1_gv-ByrM91DLQ3kqm7pap9bK+4JsQKJoNqD1Z-GZw@mail.gmail.com>
<CAKH6PiXKjksEpQOMMMQTbcsMvX2thz3WzqjoRWJAsXnZ4Eq_iQ@mail.gmail.com>
<CAEuQd1C91GOZ7eJ6U+_hUz31AEDB-rfR=0tH6fdbkz8RCESBkA@mail.gmail.com>
<202101301950.10UJoWeA456408@darkstar.fourwinds.com>
<CAEuQd1Dpbcs=kd0XynnwUkYoL_UgRfd355ttZcsLiB8Hf4gEXQ@mail.gmail.com>
<CAC20D2M0_X3Tw7371jnrMvUiDBOFDRW1Y6Cycmu_QKnWhotU4A@mail.gmail.com>
<20210130222854.GN4227@mcvoy.com> <20210130231119.GA33905@eureka.lemis.com>
<20210130231750.GQ4227@mcvoy.com>
<CANCZdfrzZrHeyuGFevGCaeHk7QfiBj7+jZGrB2MQ+N6tYW0vYw@mail.gmail.com>
<20210130233117.GR4568@mcvoy.com>
Message-ID: <202101302337.10UNbTMU465941@darkstar.fourwinds.com>
Larry McVoy writes:
> It's 20 years past the time for that re-evaluation. Seriously, Linux
> distros have been installing in X for at least 20 years, I think maybe
> more. If they can do it....
That doesn't mean that it's great. It's only easy to use once one learns
the quirks, like it appearing to hang with no feedback when you hit buttons,
and the way one has to click "done" when you're not actually done. The
number of options is so small that I think that it would be better to just
have the whole configuration on a single screen so that newbies wouldn't
have to wonder where things were done and whether or not they'd be able to
"go back" without trying it.
> Nope, it's not remotely stuck. I get it, you like FreeBSD. That's fine
> but be honest about where it is. How many of the developers with a commit
> bit actually run FreeBSD on their desktop and laptops? As their daily
> platform?
Huh, I thought that most of the linux developers these days ran on Macs.
From lm at mcvoy.com Sun Jan 31 09:54:59 2021
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 30 Jan 2021 15:54:59 -0800
Subject: [TUHS] [SPAM] Re: FreeBSD behind the times? (was: Favorite unix
design principles?)
In-Reply-To: <202101302337.10UNbTMU465941@darkstar.fourwinds.com>
References: <CAEuQd1C91GOZ7eJ6U+_hUz31AEDB-rfR=0tH6fdbkz8RCESBkA@mail.gmail.com>
<202101301950.10UJoWeA456408@darkstar.fourwinds.com>
<CAEuQd1Dpbcs=kd0XynnwUkYoL_UgRfd355ttZcsLiB8Hf4gEXQ@mail.gmail.com>
<CAC20D2M0_X3Tw7371jnrMvUiDBOFDRW1Y6Cycmu_QKnWhotU4A@mail.gmail.com>
<20210130222854.GN4227@mcvoy.com>
<20210130231119.GA33905@eureka.lemis.com>
<20210130231750.GQ4227@mcvoy.com>
<CANCZdfrzZrHeyuGFevGCaeHk7QfiBj7+jZGrB2MQ+N6tYW0vYw@mail.gmail.com>
<20210130233117.GR4568@mcvoy.com>
<202101302337.10UNbTMU465941@darkstar.fourwinds.com>
Message-ID: <20210130235459.GR4227@mcvoy.com>
On Sat, Jan 30, 2021 at 03:37:29PM -0800, Jon Steinhart wrote:
> Larry McVoy writes:
> > It's 20 years past the time for that re-evaluation. Seriously, Linux
> > distros have been installing in X for at least 20 years, I think maybe
> > more. If they can do it....
>
> That doesn't mean that it's great.
It's on the same level as Windows and has been for a long time. In fact,
it has been better than Windows for at least 10 years and probably longer.
It takes me way longer to install Windows and then go get this driver,
and then go get that one, whoops, that's the wrong one, they wanted
32 bit emulation mode blah blah blah, go get that one.
Linux, other than closed source drivers and even that is pretty pleasant
these days, just works.
> Huh, I thought that most of the linux developers these days ran on Macs.
I can imagine that, Macs have nice screens. But they run Linux on their
Macs.
Look, this is turning into a Linux vs BSD pissing contest. You do
realize that I started in the best BSD ever, SunOS, right? I was a BSD
guy long before I was a Linux guy, UW-Madison was all BSD on the vaxen
and I loved it. But I didn't have to install it. So it wasn't until
later I got to see the hell that is the FreeBSD installer.
You like FreeBSD, cool, it's fine. Nobody will ever know because nobody
is going to put up with a 1990's era installer. Nobody. It's 2020, shit
is just supposed to work, it's supposed do so in a graphical environment
let works with or without a mouse. Anyone who doesn't see that isn't
going to get any market share.
From bakul at iitbombay.org Sun Jan 31 10:00:49 2021
From: bakul at iitbombay.org (Bakul Shah)
Date: Sat, 30 Jan 2021 16:00:49 -0800
Subject: [TUHS] [SPAM] Re: FreeBSD behind the times? (was: Favorite unix
design principles?)
In-Reply-To: <202101302337.10UNbTMU465941@darkstar.fourwinds.com>
References: <CAEuQd1DO1_gv-ByrM91DLQ3kqm7pap9bK+4JsQKJoNqD1Z-GZw@mail.gmail.com>
<CAKH6PiXKjksEpQOMMMQTbcsMvX2thz3WzqjoRWJAsXnZ4Eq_iQ@mail.gmail.com>
<CAEuQd1C91GOZ7eJ6U+_hUz31AEDB-rfR=0tH6fdbkz8RCESBkA@mail.gmail.com>
<202101301950.10UJoWeA456408@darkstar.fourwinds.com>
<CAEuQd1Dpbcs=kd0XynnwUkYoL_UgRfd355ttZcsLiB8Hf4gEXQ@mail.gmail.com>
<CAC20D2M0_X3Tw7371jnrMvUiDBOFDRW1Y6Cycmu_QKnWhotU4A@mail.gmail.com>
<20210130222854.GN4227@mcvoy.com> <20210130231119.GA33905@eureka.lemis.com>
<20210130231750.GQ4227@mcvoy.com>
<CANCZdfrzZrHeyuGFevGCaeHk7QfiBj7+jZGrB2MQ+N6tYW0vYw@mail.gmail.com>
<20210130233117.GR4568@mcvoy.com>
<202101302337.10UNbTMU465941@darkstar.fourwinds.com>
Message-ID: <D1C0B6F2-8A73-49CF-A2FB-CF1EFACDEE66@iitbombay.org>
On Jan 30, 2021, at 3:37 PM, Jon Steinhart <jon at fourwinds.com> wrote:
>
> Larry McVoy writes:
>> It's 20 years past the time for that re-evaluation. Seriously, Linux
>> distros have been installing in X for at least 20 years, I think maybe
>> more. If they can do it....
>
> That doesn't mean that it's great. It's only easy to use once one learns
> the quirks, like it appearing to hang with no feedback when you hit buttons,
> and the way one has to click "done" when you're not actually done. The
> number of options is so small that I think that it would be better to just
> have the whole configuration on a single screen so that newbies wouldn't
> have to wonder where things were done and whether or not they'd be able to
> "go back" without trying it.
I vastly prefer FreeBSD over Linux but Larry has a point. Presenting *any*
configuration choice to a newbie can be confusing as they often lack the
knowledge to make an "informed choice". I do think your idea of a single
screen config is great, but with defaults chosen! The installer should
proceed after a time if the user doesn't change anything. Perhaps this can
be a useful GSOC project?
But we should bring this back to design principles! Ease of use should
certainly be one of them.
From usotsuki at buric.co Sun Jan 31 10:39:10 2021
From: usotsuki at buric.co (Steve Nickolas)
Date: Sat, 30 Jan 2021 19:39:10 -0500 (EST)
Subject: [TUHS] FreeBSD behind the times? (was: Favorite unix design
principles?)
In-Reply-To: <20210130231119.GA33905@eureka.lemis.com>
References: <CAEuQd1D00TvjQWfSYvawS45qMnG_cThdHig2rFco+emzxEYsQA@mail.gmail.com>
<alpine.DEB.2.21.2101250729510.22271@sd-119843.dedibox.fr>
<CAKH6PiWY3ggz7Rv6Y0mNr_MH5+z7duHhFH9xf-rKgsvhQvCWgA@mail.gmail.com>
<CAEuQd1DO1_gv-ByrM91DLQ3kqm7pap9bK+4JsQKJoNqD1Z-GZw@mail.gmail.com>
<CAKH6PiXKjksEpQOMMMQTbcsMvX2thz3WzqjoRWJAsXnZ4Eq_iQ@mail.gmail.com>
<CAEuQd1C91GOZ7eJ6U+_hUz31AEDB-rfR=0tH6fdbkz8RCESBkA@mail.gmail.com>
<202101301950.10UJoWeA456408@darkstar.fourwinds.com>
<CAEuQd1Dpbcs=kd0XynnwUkYoL_UgRfd355ttZcsLiB8Hf4gEXQ@mail.gmail.com>
<CAC20D2M0_X3Tw7371jnrMvUiDBOFDRW1Y6Cycmu_QKnWhotU4A@mail.gmail.com>
<20210130222854.GN4227@mcvoy.com> <20210130231119.GA33905@eureka.lemis.com>
Message-ID: <alpine.DEB.2.21.2101301934130.7902@sd-119843.dedibox.fr>
On Sun, 31 Jan 2021, Greg 'groggy' Lehey wrote:
> But I hope that you're not advocating the "change your GUI with your
> underwear" attitude that Microsoft, Apple and many Linux distros
> have. One of the reasons I don't use Linux is because every time I
> try, the interface has changed.
I'm still using the same GUI I've used for the last decade, although its
name changed.
Personally, I think a lot of Linux people who haven't come from a Unix
background don't understand Linux, because they don't understand Unix. And
because they don't understand Linux, they're trying to mutilate it into
being something other than what it was meant to be.
I thought of creating a system built on top of Linux that represented the
system as I visualized it. And I've come a fair way, but I don't yet have
the important parts (the ability to self-host, including a working kernel,
C compiler and libc) up and running, but there's pretty much your basic
stuff in /bin, /usr/bin etc., and there's a curses library, and there's ed
and vi (more or less)...so once those are available there'll be enough to
get the rest of it functional. Of course, as I visualized it will seem
remarkably antiquated to most people!
-uso.
From will.senn at gmail.com Sun Jan 31 11:47:41 2021
From: will.senn at gmail.com (Will Senn)
Date: Sat, 30 Jan 2021 19:47:41 -0600
Subject: [TUHS] FreeBSD behind the times? (was: Favorite unix design
principles?)
In-Reply-To: <20210130231119.GA33905@eureka.lemis.com>
References: <CAEuQd1D00TvjQWfSYvawS45qMnG_cThdHig2rFco+emzxEYsQA@mail.gmail.com>
<alpine.DEB.2.21.2101250729510.22271@sd-119843.dedibox.fr>
<CAKH6PiWY3ggz7Rv6Y0mNr_MH5+z7duHhFH9xf-rKgsvhQvCWgA@mail.gmail.com>
<CAEuQd1DO1_gv-ByrM91DLQ3kqm7pap9bK+4JsQKJoNqD1Z-GZw@mail.gmail.com>
<CAKH6PiXKjksEpQOMMMQTbcsMvX2thz3WzqjoRWJAsXnZ4Eq_iQ@mail.gmail.com>
<CAEuQd1C91GOZ7eJ6U+_hUz31AEDB-rfR=0tH6fdbkz8RCESBkA@mail.gmail.com>
<202101301950.10UJoWeA456408@darkstar.fourwinds.com>
<CAEuQd1Dpbcs=kd0XynnwUkYoL_UgRfd355ttZcsLiB8Hf4gEXQ@mail.gmail.com>
<CAC20D2M0_X3Tw7371jnrMvUiDBOFDRW1Y6Cycmu_QKnWhotU4A@mail.gmail.com>
<20210130222854.GN4227@mcvoy.com> <20210130231119.GA33905@eureka.lemis.com>
Message-ID: <E15A5CDB-9A26-4437-ADEC-BCC51DA0F770@gmail.com>
Oh brother. I use FreeBSD all the time. I prefer it for its stability and ZFS which has NEVER let me down and I’ve done my share of stupid user error. Now that Linux has ZFS, it doesn’t seem as stuck in the dark ages, but uptime on my fbsd instance is 10x any of my Linux instances. We are soooo off topic, I think :). But, I’m always up for talking up FBSD. I use it in my classes, too and the system is much more coherent for my systems programming classes than linux.
Will
Sent from my iPhone
> On Jan 30, 2021, at 5:11 PM, Greg 'groggy' Lehey <grog at lemis.com> wrote:
>
>> On Saturday, 30 January 2021 at 14:28:54 -0800, Larry McVoy wrote:
>>> On Sat, Jan 30, 2021 at 04:28:26PM -0500, Clem Cole wrote:
>>> If I could get the day-2-day
>>> applications that I need to work on FreeBSD, I suspect I would be there in
>>> a heartbeat.
>>
>> I dunno about that. I tried out FreeBSD a couple of years ago when
>> Netflix was flirting with me. The installer hasn't seen any loving in
>> 30 years it would seem. The disk setup tool sucks just as bad as it
>> did back in 1988.
>
> You could be right there, for some value of 1988 (FreeBSD came into
> being in 1992). The tools work without being good. But how often do
> you use them? I've been using FreeBSD since the beginning, and I
> can't recall when I last used the disk partitioning tool, though I'm
> sure that when I did I overrode a lot of (all?) the suggestions.
>
>> I remember when Linux was this bad in the .90ish releases. A long
>> time ago. Now their install is painless, it's every bit as good as
>> Windows and maybe better.
>
> FWIW, I find Microsoft "Windows" installation terminally confusing
> (that's what you were talking about, right?). And I've run into
> serious problems with various Linux installations too. That doesn't
> make the FreeBSD tools better, but maybe it relativizes it.
>
>> And it got that way fast, I remember doing an install on some
>> machine around 1998 or 1999, I didn't have a mouse plugged in, no
>> worries, you could just move around with the keyboard. X11 came up
>> as part of the install, the entire install was graphical and
>> seamless.
>
> The FreeBSD installer *does* install X if you select it.
>
>> FreeBSD is stuck in the 1990's in terms of user interface.
>
> You're still talking about the installer, aren't you? The normal user
> interface is via the shell, which hasn't changed, and for a good
> reason.
>
>> They've done some good stuff in the kernel but it's not an end user
>> system,
>
> There I have to agree with you. A little TLC would go a long way.
> But I hope that you're not advocating the "change your GUI with your
> underwear" attitude that Microsoft, Apple and many Linux distros
> have. One of the reasons I don't use Linux is because every time I
> try, the interface has changed.
>
> 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
From lm at mcvoy.com Sun Jan 31 12:25:00 2021
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 30 Jan 2021 18:25:00 -0800
Subject: [TUHS] FreeBSD behind the times? (was: Favorite unix design
principles?)
In-Reply-To: <E15A5CDB-9A26-4437-ADEC-BCC51DA0F770@gmail.com>
References: <CAKH6PiWY3ggz7Rv6Y0mNr_MH5+z7duHhFH9xf-rKgsvhQvCWgA@mail.gmail.com>
<CAEuQd1DO1_gv-ByrM91DLQ3kqm7pap9bK+4JsQKJoNqD1Z-GZw@mail.gmail.com>
<CAKH6PiXKjksEpQOMMMQTbcsMvX2thz3WzqjoRWJAsXnZ4Eq_iQ@mail.gmail.com>
<CAEuQd1C91GOZ7eJ6U+_hUz31AEDB-rfR=0tH6fdbkz8RCESBkA@mail.gmail.com>
<202101301950.10UJoWeA456408@darkstar.fourwinds.com>
<CAEuQd1Dpbcs=kd0XynnwUkYoL_UgRfd355ttZcsLiB8Hf4gEXQ@mail.gmail.com>
<CAC20D2M0_X3Tw7371jnrMvUiDBOFDRW1Y6Cycmu_QKnWhotU4A@mail.gmail.com>
<20210130222854.GN4227@mcvoy.com>
<20210130231119.GA33905@eureka.lemis.com>
<E15A5CDB-9A26-4437-ADEC-BCC51DA0F770@gmail.com>
Message-ID: <20210131022500.GU4227@mcvoy.com>
If you like ZFS you don't understand operating systems design. I do.
Jeff Bonwick was a stats student at Stanford when he took my OS class,
I convinced him to come to Sun. Bill Moore worked for me. That's the two
main ZFS guys and I thought I had taught them well but they let me down.
ZFS doesn't use the page cache, they said it was too hard because ZFS
is compressed. A typical file system just has block numbers, a compressed
one needs another int per block, it's the int that says these many bytes
are a block uncompressed. It's not that hard, it is 2 ints instead of 1.
In case I'm not being clear, the page cache is what everyone else uses
but ZFS has its own cache. So if you want to mmap() a ZFS file, ZFS
has to bcopy() the data into the page cache and then spend a shit ton
of code to make sure that the page cache data is in sync with the ZFS
cache data.
SunOS came from BSD but SunOS added mmap. Which had the same problem,
the BSD buffer cache was exactly the same as the ZFS cache, Sun spent
years of effort to get rid of the buffer cache, everything is in the
page cache. So ZFS was a HUGE step backwards in systems design. Might
be the best file system ever (it is not) but it was not a good player
in the OS world.
Those guys said that it was too hard to make a compressed file fit in
the page cache. BitKeeper has that code and proves that it can be done.
Be happy to walk anyone who cares through that code, I didn't write that,
Wayne Scott did, but it's some of the best written code I've ever seen.
Up there with Mojo's work on the SunOS VM system. (I'll bet that noone
takes me up on this offer, people love to argue but most don't want to
learn. Prove me wrong, please).
So good on you that you like ZFS and FreeBSD. I don't and I don't for
really good reasons.
Let's try it this way. Get back to me when you can show me 40 people
who have installed FreeBSD on their own, with no help. In the same
time, I can show you 40,000 people who have installed Linux on their
own, with no help. Probably 400,000.
Technology is great, ease of use is what gets you users. ZFS is
great but doesn't play nice with the OS.
That's my oh brother.
On Sat, Jan 30, 2021 at 07:47:41PM -0600, Will Senn wrote:
> Oh brother. I use FreeBSD all the time. I prefer it for its stability and ZFS which has NEVER let me down and I???ve done my share of stupid user error. Now that Linux has ZFS, it doesn???t seem as stuck in the dark ages, but uptime on my fbsd instance is 10x any of my Linux instances. We are soooo off topic, I think :). But, I???m always up for talking up FBSD. I use it in my classes, too and the system is much more coherent for my systems programming classes than linux.
>
> Will
>
> Sent from my iPhone
>
> > On Jan 30, 2021, at 5:11 PM, Greg 'groggy' Lehey <grog at lemis.com> wrote:
> >
> >> On Saturday, 30 January 2021 at 14:28:54 -0800, Larry McVoy wrote:
> >>> On Sat, Jan 30, 2021 at 04:28:26PM -0500, Clem Cole wrote:
> >>> If I could get the day-2-day
> >>> applications that I need to work on FreeBSD, I suspect I would be there in
> >>> a heartbeat.
> >>
> >> I dunno about that. I tried out FreeBSD a couple of years ago when
> >> Netflix was flirting with me. The installer hasn't seen any loving in
> >> 30 years it would seem. The disk setup tool sucks just as bad as it
> >> did back in 1988.
> >
> > You could be right there, for some value of 1988 (FreeBSD came into
> > being in 1992). The tools work without being good. But how often do
> > you use them? I've been using FreeBSD since the beginning, and I
> > can't recall when I last used the disk partitioning tool, though I'm
> > sure that when I did I overrode a lot of (all?) the suggestions.
> >
> >> I remember when Linux was this bad in the .90ish releases. A long
> >> time ago. Now their install is painless, it's every bit as good as
> >> Windows and maybe better.
> >
> > FWIW, I find Microsoft "Windows" installation terminally confusing
> > (that's what you were talking about, right?). And I've run into
> > serious problems with various Linux installations too. That doesn't
> > make the FreeBSD tools better, but maybe it relativizes it.
> >
> >> And it got that way fast, I remember doing an install on some
> >> machine around 1998 or 1999, I didn't have a mouse plugged in, no
> >> worries, you could just move around with the keyboard. X11 came up
> >> as part of the install, the entire install was graphical and
> >> seamless.
> >
> > The FreeBSD installer *does* install X if you select it.
> >
> >> FreeBSD is stuck in the 1990's in terms of user interface.
> >
> > You're still talking about the installer, aren't you? The normal user
> > interface is via the shell, which hasn't changed, and for a good
> > reason.
> >
> >> They've done some good stuff in the kernel but it's not an end user
> >> system,
> >
> > There I have to agree with you. A little TLC would go a long way.
> > But I hope that you're not advocating the "change your GUI with your
> > underwear" attitude that Microsoft, Apple and many Linux distros
> > have. One of the reasons I don't use Linux is because every time I
> > try, the interface has changed.
> >
> > 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
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
From dave at horsfall.org Sun Jan 31 12:42:12 2021
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 31 Jan 2021 13:42:12 +1100 (EST)
Subject: [TUHS] tangential unix question: whatever happened to NeWS?
In-Reply-To: <6014BB72.204@gmail.com>
References: <CAP6exYJi7nhy-DJQv1c=JiiTV=FrQZdzhqMRSm-zz3PrF1fgOA@mail.gmail.com>
<CAC20D2M7708R-pxaaGZ8F4e+tjSB2TaHEVt=-m=DDa5RCkPfMA@mail.gmail.com>
<20210124183653.GD21030@mcvoy.com>
<202101242045.10OKjDvA964774@darkstar.fourwinds.com>
<20210124211100.GI21030@mcvoy.com>
<202101242114.10OLEYGk966708@darkstar.fourwinds.com>
<20210124212525.GJ21030@mcvoy.com>
<CAEoi9W5=toe-bb+6-zC0odkx4_C4X4FZpK4+ZJTAqCKGOCXP7w@mail.gmail.com>
<202101242333.10ONXjcI974038@darkstar.fourwinds.com>
<fc52a1a1-2136-ae39-110c-93a38e73ff94@bitsavers.org>
<202101250021.10P0L3Z2976588@darkstar.fourwinds.com>
<CAC20D2OhTW+eebyub7dVMBGZy1zoOja=ojGB_=TOjgB0wEJdHQ@mail.gmail.com>
<6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org>
<CAFH29to9GaKVxUXw8uwbeMAcF6izD=8gqhqROzCOSEA5xOA5aQ@mail.gmail.com>
<CAD2gp_RsiayPg+xyEYK7AwrkuO0NS7f4o4pZ6JwVPuaoBWDdTA@mail.gmail.com>
<alpine.BSF.2.21.9999.2101300853400.36435@aneurin.horsfall.org>
<6014BB72.204@gmail.com>
Message-ID: <alpine.BSF.2.21.9999.2101311339440.36435@aneurin.horsfall.org>
On Fri, 29 Jan 2021, Nemo Nusquam wrote:
>> I was never quite sure what to make of ASN.1 and BER; it seemed to
>> solve the problem of OpenLDAP applications talking to each other (and I
>> got quite good at reading wire traces), but it somehow seemed wrong
>> when every box was running FreeBSD on Intel/AMD.
>
> BER does not work for digital signatures (because encodings are not
> unique), hence DER.
Oops, my fault; I read DER as BER.
-- Dave, needing new glasses
From will.senn at gmail.com Sun Jan 31 12:52:09 2021
From: will.senn at gmail.com (Will Senn)
Date: Sat, 30 Jan 2021 20:52:09 -0600
Subject: [TUHS] FreeBSD behind the times? (was: Favorite unix design
principles?)
In-Reply-To: <20210131022500.GU4227@mcvoy.com>
References: <CAKH6PiWY3ggz7Rv6Y0mNr_MH5+z7duHhFH9xf-rKgsvhQvCWgA@mail.gmail.com>
<CAEuQd1DO1_gv-ByrM91DLQ3kqm7pap9bK+4JsQKJoNqD1Z-GZw@mail.gmail.com>
<CAKH6PiXKjksEpQOMMMQTbcsMvX2thz3WzqjoRWJAsXnZ4Eq_iQ@mail.gmail.com>
<CAEuQd1C91GOZ7eJ6U+_hUz31AEDB-rfR=0tH6fdbkz8RCESBkA@mail.gmail.com>
<202101301950.10UJoWeA456408@darkstar.fourwinds.com>
<CAEuQd1Dpbcs=kd0XynnwUkYoL_UgRfd355ttZcsLiB8Hf4gEXQ@mail.gmail.com>
<CAC20D2M0_X3Tw7371jnrMvUiDBOFDRW1Y6Cycmu_QKnWhotU4A@mail.gmail.com>
<20210130222854.GN4227@mcvoy.com> <20210130231119.GA33905@eureka.lemis.com>
<E15A5CDB-9A26-4437-ADEC-BCC51DA0F770@gmail.com>
<20210131022500.GU4227@mcvoy.com>
Message-ID: <4B3239A9-A165-4F00-8EF1-A674CBCFC7FF@gmail.com>
Ha. Zfs may not be the be all and end all, but like I said, it’s never failed me. Whereas extX and btrfs, and, and, and have many times. Please don’t denigrate my knowledge, as so far as I know, we’ve never met, and nothing I said warrants such. The installer reminds me of Redhat’s old anaconda installer, I’ll grant you it’s dated. However, I typically install a new linux distro every week and there are many, many installers that are far more confusing - Open Suse and Fedora are two that come to mind, Debian as well. I would hazard to guess your favorite Linux is based on a distro that lacks a decent installer (Ubuntu and Mint are Debian based).
Will
Sent from my iPhone
> On Jan 30, 2021, at 8:25 PM, Larry McVoy <lm at mcvoy.com> wrote:
>
> If you like ZFS you don't understand operating systems design. I do.
> Jeff Bonwick was a stats student at Stanford when he took my OS class,
> I convinced him to come to Sun. Bill Moore worked for me. That's the two
> main ZFS guys and I thought I had taught them well but they let me down.
>
> ZFS doesn't use the page cache, they said it was too hard because ZFS
> is compressed. A typical file system just has block numbers, a compressed
> one needs another int per block, it's the int that says these many bytes
> are a block uncompressed. It's not that hard, it is 2 ints instead of 1.
>
> In case I'm not being clear, the page cache is what everyone else uses
> but ZFS has its own cache. So if you want to mmap() a ZFS file, ZFS
> has to bcopy() the data into the page cache and then spend a shit ton
> of code to make sure that the page cache data is in sync with the ZFS
> cache data.
>
> SunOS came from BSD but SunOS added mmap. Which had the same problem,
> the BSD buffer cache was exactly the same as the ZFS cache, Sun spent
> years of effort to get rid of the buffer cache, everything is in the
> page cache. So ZFS was a HUGE step backwards in systems design. Might
> be the best file system ever (it is not) but it was not a good player
> in the OS world.
>
> Those guys said that it was too hard to make a compressed file fit in
> the page cache. BitKeeper has that code and proves that it can be done.
> Be happy to walk anyone who cares through that code, I didn't write that,
> Wayne Scott did, but it's some of the best written code I've ever seen.
> Up there with Mojo's work on the SunOS VM system. (I'll bet that noone
> takes me up on this offer, people love to argue but most don't want to
> learn. Prove me wrong, please).
>
> So good on you that you like ZFS and FreeBSD. I don't and I don't for
> really good reasons.
>
> Let's try it this way. Get back to me when you can show me 40 people
> who have installed FreeBSD on their own, with no help. In the same
> time, I can show you 40,000 people who have installed Linux on their
> own, with no help. Probably 400,000.
>
> Technology is great, ease of use is what gets you users. ZFS is
> great but doesn't play nice with the OS.
>
> That's my oh brother.
>
>> On Sat, Jan 30, 2021 at 07:47:41PM -0600, Will Senn wrote:
>> Oh brother. I use FreeBSD all the time. I prefer it for its stability and ZFS which has NEVER let me down and I???ve done my share of stupid user error. Now that Linux has ZFS, it doesn???t seem as stuck in the dark ages, but uptime on my fbsd instance is 10x any of my Linux instances. We are soooo off topic, I think :). But, I???m always up for talking up FBSD. I use it in my classes, too and the system is much more coherent for my systems programming classes than linux.
>>
>> Will
>>
>> Sent from my iPhone
>>
>>>> On Jan 30, 2021, at 5:11 PM, Greg 'groggy' Lehey <grog at lemis.com> wrote:
>>>>
>>>>> On Saturday, 30 January 2021 at 14:28:54 -0800, Larry McVoy wrote:
>>>>> On Sat, Jan 30, 2021 at 04:28:26PM -0500, Clem Cole wrote:
>>>>> If I could get the day-2-day
>>>>> applications that I need to work on FreeBSD, I suspect I would be there in
>>>>> a heartbeat.
>>>>
>>>> I dunno about that. I tried out FreeBSD a couple of years ago when
>>>> Netflix was flirting with me. The installer hasn't seen any loving in
>>>> 30 years it would seem. The disk setup tool sucks just as bad as it
>>>> did back in 1988.
>>>
>>> You could be right there, for some value of 1988 (FreeBSD came into
>>> being in 1992). The tools work without being good. But how often do
>>> you use them? I've been using FreeBSD since the beginning, and I
>>> can't recall when I last used the disk partitioning tool, though I'm
>>> sure that when I did I overrode a lot of (all?) the suggestions.
>>>
>>>> I remember when Linux was this bad in the .90ish releases. A long
>>>> time ago. Now their install is painless, it's every bit as good as
>>>> Windows and maybe better.
>>>
>>> FWIW, I find Microsoft "Windows" installation terminally confusing
>>> (that's what you were talking about, right?). And I've run into
>>> serious problems with various Linux installations too. That doesn't
>>> make the FreeBSD tools better, but maybe it relativizes it.
>>>
>>>> And it got that way fast, I remember doing an install on some
>>>> machine around 1998 or 1999, I didn't have a mouse plugged in, no
>>>> worries, you could just move around with the keyboard. X11 came up
>>>> as part of the install, the entire install was graphical and
>>>> seamless.
>>>
>>> The FreeBSD installer *does* install X if you select it.
>>>
>>>> FreeBSD is stuck in the 1990's in terms of user interface.
>>>
>>> You're still talking about the installer, aren't you? The normal user
>>> interface is via the shell, which hasn't changed, and for a good
>>> reason.
>>>
>>>> They've done some good stuff in the kernel but it's not an end user
>>>> system,
>>>
>>> There I have to agree with you. A little TLC would go a long way.
>>> But I hope that you're not advocating the "change your GUI with your
>>> underwear" attitude that Microsoft, Apple and many Linux distros
>>> have. One of the reasons I don't use Linux is because every time I
>>> try, the interface has changed.
>>>
>>> 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
>
> --
> ---
> Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
From lm at mcvoy.com Sun Jan 31 13:00:19 2021
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 30 Jan 2021 19:00:19 -0800
Subject: [TUHS] FreeBSD behind the times? (was: Favorite unix design
principles?)
In-Reply-To: <4B3239A9-A165-4F00-8EF1-A674CBCFC7FF@gmail.com>
References: <CAKH6PiXKjksEpQOMMMQTbcsMvX2thz3WzqjoRWJAsXnZ4Eq_iQ@mail.gmail.com>
<CAEuQd1C91GOZ7eJ6U+_hUz31AEDB-rfR=0tH6fdbkz8RCESBkA@mail.gmail.com>
<202101301950.10UJoWeA456408@darkstar.fourwinds.com>
<CAEuQd1Dpbcs=kd0XynnwUkYoL_UgRfd355ttZcsLiB8Hf4gEXQ@mail.gmail.com>
<CAC20D2M0_X3Tw7371jnrMvUiDBOFDRW1Y6Cycmu_QKnWhotU4A@mail.gmail.com>
<20210130222854.GN4227@mcvoy.com>
<20210130231119.GA33905@eureka.lemis.com>
<E15A5CDB-9A26-4437-ADEC-BCC51DA0F770@gmail.com>
<20210131022500.GU4227@mcvoy.com>
<4B3239A9-A165-4F00-8EF1-A674CBCFC7FF@gmail.com>
Message-ID: <20210131030019.GW4227@mcvoy.com>
I think this has gone on along enough. Don't want it to be personal, not
my intent.
Like I said it seems like a Linux vs FreeBSD thing. Don't want that.
You can search the archives about Ted talking about how ext was not
all that (I'm a fan).
On Sat, Jan 30, 2021 at 08:52:09PM -0600, Will Senn wrote:
> Ha. Zfs may not be the be all and end all, but like I said, it???s never failed me. Whereas extX and btrfs, and, and, and have many times. Please don???t denigrate my knowledge, as so far as I know, we???ve never met, and nothing I said warrants such. The installer reminds me of Redhat???s old anaconda installer, I???ll grant you it???s dated. However, I typically install a new linux distro every week and there are many, many installers that are far more confusing - Open Suse and Fedora are two that come to mind, Debian as well. I would hazard to guess your favorite Linux is based on a distro that lacks a decent installer (Ubuntu and Mint are Debian based).
>
> Will
>
> Sent from my iPhone
>
> > On Jan 30, 2021, at 8:25 PM, Larry McVoy <lm at mcvoy.com> wrote:
> >
> > If you like ZFS you don't understand operating systems design. I do.
> > Jeff Bonwick was a stats student at Stanford when he took my OS class,
> > I convinced him to come to Sun. Bill Moore worked for me. That's the two
> > main ZFS guys and I thought I had taught them well but they let me down.
> >
> > ZFS doesn't use the page cache, they said it was too hard because ZFS
> > is compressed. A typical file system just has block numbers, a compressed
> > one needs another int per block, it's the int that says these many bytes
> > are a block uncompressed. It's not that hard, it is 2 ints instead of 1.
> >
> > In case I'm not being clear, the page cache is what everyone else uses
> > but ZFS has its own cache. So if you want to mmap() a ZFS file, ZFS
> > has to bcopy() the data into the page cache and then spend a shit ton
> > of code to make sure that the page cache data is in sync with the ZFS
> > cache data.
> >
> > SunOS came from BSD but SunOS added mmap. Which had the same problem,
> > the BSD buffer cache was exactly the same as the ZFS cache, Sun spent
> > years of effort to get rid of the buffer cache, everything is in the
> > page cache. So ZFS was a HUGE step backwards in systems design. Might
> > be the best file system ever (it is not) but it was not a good player
> > in the OS world.
> >
> > Those guys said that it was too hard to make a compressed file fit in
> > the page cache. BitKeeper has that code and proves that it can be done.
> > Be happy to walk anyone who cares through that code, I didn't write that,
> > Wayne Scott did, but it's some of the best written code I've ever seen.
> > Up there with Mojo's work on the SunOS VM system. (I'll bet that noone
> > takes me up on this offer, people love to argue but most don't want to
> > learn. Prove me wrong, please).
> >
> > So good on you that you like ZFS and FreeBSD. I don't and I don't for
> > really good reasons.
> >
> > Let's try it this way. Get back to me when you can show me 40 people
> > who have installed FreeBSD on their own, with no help. In the same
> > time, I can show you 40,000 people who have installed Linux on their
> > own, with no help. Probably 400,000.
> >
> > Technology is great, ease of use is what gets you users. ZFS is
> > great but doesn't play nice with the OS.
> >
> > That's my oh brother.
> >
> >> On Sat, Jan 30, 2021 at 07:47:41PM -0600, Will Senn wrote:
> >> Oh brother. I use FreeBSD all the time. I prefer it for its stability and ZFS which has NEVER let me down and I???ve done my share of stupid user error. Now that Linux has ZFS, it doesn???t seem as stuck in the dark ages, but uptime on my fbsd instance is 10x any of my Linux instances. We are soooo off topic, I think :). But, I???m always up for talking up FBSD. I use it in my classes, too and the system is much more coherent for my systems programming classes than linux.
> >>
> >> Will
> >>
> >> Sent from my iPhone
> >>
> >>>> On Jan 30, 2021, at 5:11 PM, Greg 'groggy' Lehey <grog at lemis.com> wrote:
> >>>>
> >>>>> On Saturday, 30 January 2021 at 14:28:54 -0800, Larry McVoy wrote:
> >>>>> On Sat, Jan 30, 2021 at 04:28:26PM -0500, Clem Cole wrote:
> >>>>> If I could get the day-2-day
> >>>>> applications that I need to work on FreeBSD, I suspect I would be there in
> >>>>> a heartbeat.
> >>>>
> >>>> I dunno about that. I tried out FreeBSD a couple of years ago when
> >>>> Netflix was flirting with me. The installer hasn't seen any loving in
> >>>> 30 years it would seem. The disk setup tool sucks just as bad as it
> >>>> did back in 1988.
> >>>
> >>> You could be right there, for some value of 1988 (FreeBSD came into
> >>> being in 1992). The tools work without being good. But how often do
> >>> you use them? I've been using FreeBSD since the beginning, and I
> >>> can't recall when I last used the disk partitioning tool, though I'm
> >>> sure that when I did I overrode a lot of (all?) the suggestions.
> >>>
> >>>> I remember when Linux was this bad in the .90ish releases. A long
> >>>> time ago. Now their install is painless, it's every bit as good as
> >>>> Windows and maybe better.
> >>>
> >>> FWIW, I find Microsoft "Windows" installation terminally confusing
> >>> (that's what you were talking about, right?). And I've run into
> >>> serious problems with various Linux installations too. That doesn't
> >>> make the FreeBSD tools better, but maybe it relativizes it.
> >>>
> >>>> And it got that way fast, I remember doing an install on some
> >>>> machine around 1998 or 1999, I didn't have a mouse plugged in, no
> >>>> worries, you could just move around with the keyboard. X11 came up
> >>>> as part of the install, the entire install was graphical and
> >>>> seamless.
> >>>
> >>> The FreeBSD installer *does* install X if you select it.
> >>>
> >>>> FreeBSD is stuck in the 1990's in terms of user interface.
> >>>
> >>> You're still talking about the installer, aren't you? The normal user
> >>> interface is via the shell, which hasn't changed, and for a good
> >>> reason.
> >>>
> >>>> They've done some good stuff in the kernel but it's not an end user
> >>>> system,
> >>>
> >>> There I have to agree with you. A little TLC would go a long way.
> >>> But I hope that you're not advocating the "change your GUI with your
> >>> underwear" attitude that Microsoft, Apple and many Linux distros
> >>> have. One of the reasons I don't use Linux is because every time I
> >>> try, the interface has changed.
> >>>
> >>> 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
> >
> > --
> > ---
> > Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
From will.senn at gmail.com Sun Jan 31 13:06:15 2021
From: will.senn at gmail.com (Will Senn)
Date: Sat, 30 Jan 2021 21:06:15 -0600
Subject: [TUHS] FreeBSD behind the times? (was: Favorite unix design
principles?)
In-Reply-To: <20210131030019.GW4227@mcvoy.com>
References: <CAKH6PiXKjksEpQOMMMQTbcsMvX2thz3WzqjoRWJAsXnZ4Eq_iQ@mail.gmail.com>
<CAEuQd1C91GOZ7eJ6U+_hUz31AEDB-rfR=0tH6fdbkz8RCESBkA@mail.gmail.com>
<202101301950.10UJoWeA456408@darkstar.fourwinds.com>
<CAEuQd1Dpbcs=kd0XynnwUkYoL_UgRfd355ttZcsLiB8Hf4gEXQ@mail.gmail.com>
<CAC20D2M0_X3Tw7371jnrMvUiDBOFDRW1Y6Cycmu_QKnWhotU4A@mail.gmail.com>
<20210130222854.GN4227@mcvoy.com> <20210130231119.GA33905@eureka.lemis.com>
<E15A5CDB-9A26-4437-ADEC-BCC51DA0F770@gmail.com>
<20210131022500.GU4227@mcvoy.com>
<4B3239A9-A165-4F00-8EF1-A674CBCFC7FF@gmail.com>
<20210131030019.GW4227@mcvoy.com>
Message-ID: <3797E07F-7BC8-4EE5-B317-2A51D7C3E671@gmail.com>
No worries. Maybe it’s time for a vi emacs discussion... totally kidding :)
Sent from my iPhone
> On Jan 30, 2021, at 9:00 PM, Larry McVoy <lm at mcvoy.com> wrote:
>
> I think this has gone on along enough. Don't want it to be personal, not
> my intent.
>
> Like I said it seems like a Linux vs FreeBSD thing. Don't want that.
> You can search the archives about Ted talking about how ext was not
> all that (I'm a fan).
>
>> On Sat, Jan 30, 2021 at 08:52:09PM -0600, Will Senn wrote:
>> Ha. Zfs may not be the be all and end all, but like I said, it???s never failed me. Whereas extX and btrfs, and, and, and have many times. Please don???t denigrate my knowledge, as so far as I know, we???ve never met, and nothing I said warrants such. The installer reminds me of Redhat???s old anaconda installer, I???ll grant you it???s dated. However, I typically install a new linux distro every week and there are many, many installers that are far more confusing - Open Suse and Fedora are two that come to mind, Debian as well. I would hazard to guess your favorite Linux is based on a distro that lacks a decent installer (Ubuntu and Mint are Debian based).
>>
>> Will
>>
>> Sent from my iPhone
>>
>>> On Jan 30, 2021, at 8:25 PM, Larry McVoy <lm at mcvoy.com> wrote:
>>>
>>> If you like ZFS you don't understand operating systems design. I do.
>>> Jeff Bonwick was a stats student at Stanford when he took my OS class,
>>> I convinced him to come to Sun. Bill Moore worked for me. That's the two
>>> main ZFS guys and I thought I had taught them well but they let me down.
>>>
>>> ZFS doesn't use the page cache, they said it was too hard because ZFS
>>> is compressed. A typical file system just has block numbers, a compressed
>>> one needs another int per block, it's the int that says these many bytes
>>> are a block uncompressed. It's not that hard, it is 2 ints instead of 1.
>>>
>>> In case I'm not being clear, the page cache is what everyone else uses
>>> but ZFS has its own cache. So if you want to mmap() a ZFS file, ZFS
>>> has to bcopy() the data into the page cache and then spend a shit ton
>>> of code to make sure that the page cache data is in sync with the ZFS
>>> cache data.
>>>
>>> SunOS came from BSD but SunOS added mmap. Which had the same problem,
>>> the BSD buffer cache was exactly the same as the ZFS cache, Sun spent
>>> years of effort to get rid of the buffer cache, everything is in the
>>> page cache. So ZFS was a HUGE step backwards in systems design. Might
>>> be the best file system ever (it is not) but it was not a good player
>>> in the OS world.
>>>
>>> Those guys said that it was too hard to make a compressed file fit in
>>> the page cache. BitKeeper has that code and proves that it can be done.
>>> Be happy to walk anyone who cares through that code, I didn't write that,
>>> Wayne Scott did, but it's some of the best written code I've ever seen.
>>> Up there with Mojo's work on the SunOS VM system. (I'll bet that noone
>>> takes me up on this offer, people love to argue but most don't want to
>>> learn. Prove me wrong, please).
>>>
>>> So good on you that you like ZFS and FreeBSD. I don't and I don't for
>>> really good reasons.
>>>
>>> Let's try it this way. Get back to me when you can show me 40 people
>>> who have installed FreeBSD on their own, with no help. In the same
>>> time, I can show you 40,000 people who have installed Linux on their
>>> own, with no help. Probably 400,000.
>>>
>>> Technology is great, ease of use is what gets you users. ZFS is
>>> great but doesn't play nice with the OS.
>>>
>>> That's my oh brother.
>>>
>>>> On Sat, Jan 30, 2021 at 07:47:41PM -0600, Will Senn wrote:
>>>> Oh brother. I use FreeBSD all the time. I prefer it for its stability and ZFS which has NEVER let me down and I???ve done my share of stupid user error. Now that Linux has ZFS, it doesn???t seem as stuck in the dark ages, but uptime on my fbsd instance is 10x any of my Linux instances. We are soooo off topic, I think :). But, I???m always up for talking up FBSD. I use it in my classes, too and the system is much more coherent for my systems programming classes than linux.
>>>>
>>>> Will
>>>>
>>>> Sent from my iPhone
>>>>
>>>>>>> On Jan 30, 2021, at 5:11 PM, Greg 'groggy' Lehey <grog at lemis.com> wrote:
>>>>>>>
>>>>>>> On Saturday, 30 January 2021 at 14:28:54 -0800, Larry McVoy wrote:
>>>>>>> On Sat, Jan 30, 2021 at 04:28:26PM -0500, Clem Cole wrote:
>>>>>>> If I could get the day-2-day
>>>>>>> applications that I need to work on FreeBSD, I suspect I would be there in
>>>>>>> a heartbeat.
>>>>>>
>>>>>> I dunno about that. I tried out FreeBSD a couple of years ago when
>>>>>> Netflix was flirting with me. The installer hasn't seen any loving in
>>>>>> 30 years it would seem. The disk setup tool sucks just as bad as it
>>>>>> did back in 1988.
>>>>>
>>>>> You could be right there, for some value of 1988 (FreeBSD came into
>>>>> being in 1992). The tools work without being good. But how often do
>>>>> you use them? I've been using FreeBSD since the beginning, and I
>>>>> can't recall when I last used the disk partitioning tool, though I'm
>>>>> sure that when I did I overrode a lot of (all?) the suggestions.
>>>>>
>>>>>> I remember when Linux was this bad in the .90ish releases. A long
>>>>>> time ago. Now their install is painless, it's every bit as good as
>>>>>> Windows and maybe better.
>>>>>
>>>>> FWIW, I find Microsoft "Windows" installation terminally confusing
>>>>> (that's what you were talking about, right?). And I've run into
>>>>> serious problems with various Linux installations too. That doesn't
>>>>> make the FreeBSD tools better, but maybe it relativizes it.
>>>>>
>>>>>> And it got that way fast, I remember doing an install on some
>>>>>> machine around 1998 or 1999, I didn't have a mouse plugged in, no
>>>>>> worries, you could just move around with the keyboard. X11 came up
>>>>>> as part of the install, the entire install was graphical and
>>>>>> seamless.
>>>>>
>>>>> The FreeBSD installer *does* install X if you select it.
>>>>>
>>>>>> FreeBSD is stuck in the 1990's in terms of user interface.
>>>>>
>>>>> You're still talking about the installer, aren't you? The normal user
>>>>> interface is via the shell, which hasn't changed, and for a good
>>>>> reason.
>>>>>
>>>>>> They've done some good stuff in the kernel but it's not an end user
>>>>>> system,
>>>>>
>>>>> There I have to agree with you. A little TLC would go a long way.
>>>>> But I hope that you're not advocating the "change your GUI with your
>>>>> underwear" attitude that Microsoft, Apple and many Linux distros
>>>>> have. One of the reasons I don't use Linux is because every time I
>>>>> try, the interface has changed.
>>>>>
>>>>> 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
>>>
>>> --
>>> ---
>>> Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
>
> --
> ---
> Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
From will.senn at gmail.com Sun Jan 31 13:16:07 2021
From: will.senn at gmail.com (Will Senn)
Date: Sat, 30 Jan 2021 21:16:07 -0600
Subject: [TUHS] Qed vs ed
Message-ID: <BCB902EF-06BD-4855-804E-9D7607D00847@gmail.com>
Hi all,
So. On a lighter note. I was tooling around the web and came across a discussion of QED, the editor. It’s been resurrected in no small part based on discussions on this list (and members like Rob Pike). Anyhow, there’s a version that compiles in modern systems and that handles wide characters. My question for the group is this how different is QED from ed? I’ve read Dennis’ paper on the history of QED and it’s fascinating, but all I really got out of the discussion related to ed, was that QED was a precursor. I’m curious about functional parity or lack thereof, more than technical differences. In full disclosure, and at the risk of drawing fire from lovers of other editors, I have to confess a love of the original ed (and it’s decendent ed’s and vi).
Cheers,
Will
Sent from my iPhone
From cowan at ccil.org Sun Jan 31 13:32:08 2021
From: cowan at ccil.org (John Cowan)
Date: Sat, 30 Jan 2021 22:32:08 -0500
Subject: [TUHS] FreeBSD behind the times? (was: Favorite unix design
principles?)
In-Reply-To: <3797E07F-7BC8-4EE5-B317-2A51D7C3E671@gmail.com>
References: <CAKH6PiXKjksEpQOMMMQTbcsMvX2thz3WzqjoRWJAsXnZ4Eq_iQ@mail.gmail.com>
<CAEuQd1C91GOZ7eJ6U+_hUz31AEDB-rfR=0tH6fdbkz8RCESBkA@mail.gmail.com>
<202101301950.10UJoWeA456408@darkstar.fourwinds.com>
<CAEuQd1Dpbcs=kd0XynnwUkYoL_UgRfd355ttZcsLiB8Hf4gEXQ@mail.gmail.com>
<CAC20D2M0_X3Tw7371jnrMvUiDBOFDRW1Y6Cycmu_QKnWhotU4A@mail.gmail.com>
<20210130222854.GN4227@mcvoy.com> <20210130231119.GA33905@eureka.lemis.com>
<E15A5CDB-9A26-4437-ADEC-BCC51DA0F770@gmail.com>
<20210131022500.GU4227@mcvoy.com>
<4B3239A9-A165-4F00-8EF1-A674CBCFC7FF@gmail.com>
<20210131030019.GW4227@mcvoy.com>
<3797E07F-7BC8-4EE5-B317-2A51D7C3E671@gmail.com>
Message-ID: <CAD2gp_TryfLkk2_0EUWhh_Khi-Nh5JdBMxoXe+Gtx4E4chjnJA@mail.gmail.com>
Since, I am an ex(1) troglodyte, I'll be happy to umpire. (I know ed(1) is
the standard editor, but I'm willing to trade a little standardosity for
more convenience.)
On Sat, Jan 30, 2021 at 10:06 PM Will Senn <will.senn at gmail.com> wrote:
> No worries. Maybe it’s time for a vi emacs discussion... totally kidding :)
>
> Sent from my iPhone
>
> > On Jan 30, 2021, at 9:00 PM, Larry McVoy <lm at mcvoy.com> wrote:
> >
> > I think this has gone on along enough. Don't want it to be personal, not
> > my intent.
> >
> > Like I said it seems like a Linux vs FreeBSD thing. Don't want that.
> > You can search the archives about Ted talking about how ext was not
> > all that (I'm a fan).
> >
> >> On Sat, Jan 30, 2021 at 08:52:09PM -0600, Will Senn wrote:
> >> Ha. Zfs may not be the be all and end all, but like I said, it???s
> never failed me. Whereas extX and btrfs, and, and, and have many times.
> Please don???t denigrate my knowledge, as so far as I know, we???ve never
> met, and nothing I said warrants such. The installer reminds me of
> Redhat???s old anaconda installer, I???ll grant you it???s dated. However,
> I typically install a new linux distro every week and there are many, many
> installers that are far more confusing - Open Suse and Fedora are two that
> come to mind, Debian as well. I would hazard to guess your favorite Linux
> is based on a distro that lacks a decent installer (Ubuntu and Mint are
> Debian based).
> >>
> >> Will
> >>
> >> Sent from my iPhone
> >>
> >>> On Jan 30, 2021, at 8:25 PM, Larry McVoy <lm at mcvoy.com> wrote:
> >>>
> >>> If you like ZFS you don't understand operating systems design. I do.
> >>> Jeff Bonwick was a stats student at Stanford when he took my OS class,
> >>> I convinced him to come to Sun. Bill Moore worked for me. That's the
> two
> >>> main ZFS guys and I thought I had taught them well but they let me
> down.
> >>>
> >>> ZFS doesn't use the page cache, they said it was too hard because ZFS
> >>> is compressed. A typical file system just has block numbers, a
> compressed
> >>> one needs another int per block, it's the int that says these many
> bytes
> >>> are a block uncompressed. It's not that hard, it is 2 ints instead of
> 1.
> >>>
> >>> In case I'm not being clear, the page cache is what everyone else uses
> >>> but ZFS has its own cache. So if you want to mmap() a ZFS file, ZFS
> >>> has to bcopy() the data into the page cache and then spend a shit ton
> >>> of code to make sure that the page cache data is in sync with the ZFS
> >>> cache data.
> >>>
> >>> SunOS came from BSD but SunOS added mmap. Which had the same problem,
> >>> the BSD buffer cache was exactly the same as the ZFS cache, Sun spent
> >>> years of effort to get rid of the buffer cache, everything is in the
> >>> page cache. So ZFS was a HUGE step backwards in systems design. Might
> >>> be the best file system ever (it is not) but it was not a good player
> >>> in the OS world.
> >>>
> >>> Those guys said that it was too hard to make a compressed file fit in
> >>> the page cache. BitKeeper has that code and proves that it can be
> done.
> >>> Be happy to walk anyone who cares through that code, I didn't write
> that,
> >>> Wayne Scott did, but it's some of the best written code I've ever seen.
> >>> Up there with Mojo's work on the SunOS VM system. (I'll bet that noone
> >>> takes me up on this offer, people love to argue but most don't want to
> >>> learn. Prove me wrong, please).
> >>>
> >>> So good on you that you like ZFS and FreeBSD. I don't and I don't for
> >>> really good reasons.
> >>>
> >>> Let's try it this way. Get back to me when you can show me 40 people
> >>> who have installed FreeBSD on their own, with no help. In the same
> >>> time, I can show you 40,000 people who have installed Linux on their
> >>> own, with no help. Probably 400,000.
> >>>
> >>> Technology is great, ease of use is what gets you users. ZFS is
> >>> great but doesn't play nice with the OS.
> >>>
> >>> That's my oh brother.
> >>>
> >>>> On Sat, Jan 30, 2021 at 07:47:41PM -0600, Will Senn wrote:
> >>>> Oh brother. I use FreeBSD all the time. I prefer it for its stability
> and ZFS which has NEVER let me down and I???ve done my share of stupid user
> error. Now that Linux has ZFS, it doesn???t seem as stuck in the dark ages,
> but uptime on my fbsd instance is 10x any of my Linux instances. We are
> soooo off topic, I think :). But, I???m always up for talking up FBSD. I
> use it in my classes, too and the system is much more coherent for my
> systems programming classes than linux.
> >>>>
> >>>> Will
> >>>>
> >>>> Sent from my iPhone
> >>>>
> >>>>>>> On Jan 30, 2021, at 5:11 PM, Greg 'groggy' Lehey <grog at lemis.com>
> wrote:
> >>>>>>>
> >>>>>>> On Saturday, 30 January 2021 at 14:28:54 -0800, Larry McVoy wrote:
> >>>>>>> On Sat, Jan 30, 2021 at 04:28:26PM -0500, Clem Cole wrote:
> >>>>>>> If I could get the day-2-day
> >>>>>>> applications that I need to work on FreeBSD, I suspect I would be
> there in
> >>>>>>> a heartbeat.
> >>>>>>
> >>>>>> I dunno about that. I tried out FreeBSD a couple of years ago when
> >>>>>> Netflix was flirting with me. The installer hasn't seen any loving
> in
> >>>>>> 30 years it would seem. The disk setup tool sucks just as bad as it
> >>>>>> did back in 1988.
> >>>>>
> >>>>> You could be right there, for some value of 1988 (FreeBSD came into
> >>>>> being in 1992). The tools work without being good. But how often do
> >>>>> you use them? I've been using FreeBSD since the beginning, and I
> >>>>> can't recall when I last used the disk partitioning tool, though I'm
> >>>>> sure that when I did I overrode a lot of (all?) the suggestions.
> >>>>>
> >>>>>> I remember when Linux was this bad in the .90ish releases. A long
> >>>>>> time ago. Now their install is painless, it's every bit as good as
> >>>>>> Windows and maybe better.
> >>>>>
> >>>>> FWIW, I find Microsoft "Windows" installation terminally confusing
> >>>>> (that's what you were talking about, right?). And I've run into
> >>>>> serious problems with various Linux installations too. That doesn't
> >>>>> make the FreeBSD tools better, but maybe it relativizes it.
> >>>>>
> >>>>>> And it got that way fast, I remember doing an install on some
> >>>>>> machine around 1998 or 1999, I didn't have a mouse plugged in, no
> >>>>>> worries, you could just move around with the keyboard. X11 came up
> >>>>>> as part of the install, the entire install was graphical and
> >>>>>> seamless.
> >>>>>
> >>>>> The FreeBSD installer *does* install X if you select it.
> >>>>>
> >>>>>> FreeBSD is stuck in the 1990's in terms of user interface.
> >>>>>
> >>>>> You're still talking about the installer, aren't you? The normal
> user
> >>>>> interface is via the shell, which hasn't changed, and for a good
> >>>>> reason.
> >>>>>
> >>>>>> They've done some good stuff in the kernel but it's not an end user
> >>>>>> system,
> >>>>>
> >>>>> There I have to agree with you. A little TLC would go a long way.
> >>>>> But I hope that you're not advocating the "change your GUI with your
> >>>>> underwear" attitude that Microsoft, Apple and many Linux distros
> >>>>> have. One of the reasons I don't use Linux is because every time I
> >>>>> try, the interface has changed.
> >>>>>
> >>>>> 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
> >>>
> >>> --
> >>> ---
> >>> Larry McVoy lm at mcvoy.com
> http://www.mcvoy.com/lm
> >
> > --
> > ---
> > Larry McVoy lm at mcvoy.com
> http://www.mcvoy.com/lm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210130/cd5f3bf2/attachment.htm>
From will.senn at gmail.com Sun Jan 31 13:48:53 2021
From: will.senn at gmail.com (Will Senn)
Date: Sat, 30 Jan 2021 21:48:53 -0600
Subject: [TUHS] Qed vs ed
In-Reply-To: <BCB902EF-06BD-4855-804E-9D7607D00847@gmail.com>
References: <BCB902EF-06BD-4855-804E-9D7607D00847@gmail.com>
Message-ID: <f2330b8f-6273-e2dc-526b-901298fff5ee@gmail.com>
On 1/30/21 9:16 PM, Will Senn wrote:
> Hi all,
>
> So. On a lighter note. I was tooling around the web and came across a discussion of QED, the editor. It’s been resurrected in no small part based on discussions on this list (and members like Rob Pike). Anyhow, there’s a version that compiles in modern systems and that handles wide characters. My question for the group is this how different is QED from ed? I’ve read Dennis’ paper on the history of QED and it’s fascinating, but all I really got out of the discussion related to ed, was that QED was a precursor. I’m curious about functional parity or lack thereof, more than technical differences. In full disclosure, and at the risk of drawing fire from lovers of other editors, I have to confess a love of the original ed (and it’s decendent ed’s and vi).
>
> Cheers,
>
> Will
>
>
>
> Sent from my iPhone
Here's the link to the article that kicked off this line of inquiry:
https://leahneukirchen.org/blog/archive/2021/01/remembering-the-work-of-david-m-tilbrook-and-the-qed-editor.html
Does anyone know of any effort to show the family tree of editors,
similar to what we have for unix and linux?
Will
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210130/7a03b26b/attachment.htm>
From will.senn at gmail.com Sun Jan 31 13:58:29 2021
From: will.senn at gmail.com (Will Senn)
Date: Sat, 30 Jan 2021 21:58:29 -0600
Subject: [TUHS] Qed vs ed
In-Reply-To: <f2330b8f-6273-e2dc-526b-901298fff5ee@gmail.com>
References: <BCB902EF-06BD-4855-804E-9D7607D00847@gmail.com>
<f2330b8f-6273-e2dc-526b-901298fff5ee@gmail.com>
Message-ID: <51d043be-4905-f4b2-c46e-34427c43a61d@gmail.com>
On 1/30/21 9:48 PM, Will Senn wrote:
> On 1/30/21 9:16 PM, Will Senn wrote:
>> Hi all,
>>
>> So. On a lighter note. I was tooling around the web and came across a discussion of QED, the editor. It’s been resurrected in no small part based on discussions on this list (and members like Rob Pike). Anyhow, there’s a version that compiles in modern systems and that handles wide characters. My question for the group is this how different is QED from ed? I’ve read Dennis’ paper on the history of QED and it’s fascinating, but all I really got out of the discussion related to ed, was that QED was a precursor. I’m curious about functional parity or lack thereof, more than technical differences. In full disclosure, and at the risk of drawing fire from lovers of other editors, I have to confess a love of the original ed (and it’s decendent ed’s and vi).
>>
>> Cheers,
>>
>> Will
>>
>>
>>
>> Sent from my iPhone
> Here's the link to the article that kicked off this line of inquiry:
>
> https://leahneukirchen.org/blog/archive/2021/01/remembering-the-work-of-david-m-tilbrook-and-the-qed-editor.html
>
> Does anyone know of any effort to show the family tree of editors,
> similar to what we have for unix and linux?
>
> Will
Ah, heck - Dennis says QED influenced ed, but the first line of the
description in QED (1) (Mar/82) is:
Qed is a multiple-file programmable text editor based on ed.
Which is it?
Will
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210130/7c623502/attachment.htm>
From aek at bitsavers.org Sun Jan 31 14:07:29 2021
From: aek at bitsavers.org (Al Kossow)
Date: Sat, 30 Jan 2021 20:07:29 -0800
Subject: [TUHS] Qed vs ed
In-Reply-To: <f2330b8f-6273-e2dc-526b-901298fff5ee@gmail.com>
References: <BCB902EF-06BD-4855-804E-9D7607D00847@gmail.com>
<f2330b8f-6273-e2dc-526b-901298fff5ee@gmail.com>
Message-ID: <316d3fab-cf62-2d2e-f721-f4398acffc06@bitsavers.org>
> https://leahneukirchen.org/blog/archive/2021/01/remembering-the-work-of-david-m-tilbrook-and-the-qed-editor.html
references
https://github.com/arnoldrobbins/qed-archive/tree/master/sds-940
SDS 940 QED
"These files were supplied to me by Lars Brinkhoff (lars AT nocrew.org). I have no idea where he got them."
Me, assuming he pulled them from the SDS940 tapes I recovered and are on bitsavers
The .pdf scans are from me, so I assume the code came from bitsavers as well.
Shit like this pisses me off.
From lars at nocrew.org Sun Jan 31 17:00:21 2021
From: lars at nocrew.org (Lars Brinkhoff)
Date: Sun, 31 Jan 2021 07:00:21 +0000
Subject: [TUHS] Qed vs ed
In-Reply-To: <316d3fab-cf62-2d2e-f721-f4398acffc06@bitsavers.org> (Al Kossow's
message of "Sat, 30 Jan 2021 20:07:29 -0800")
References: <BCB902EF-06BD-4855-804E-9D7607D00847@gmail.com>
<f2330b8f-6273-e2dc-526b-901298fff5ee@gmail.com>
<316d3fab-cf62-2d2e-f721-f4398acffc06@bitsavers.org>
Message-ID: <7wh7mxpp4q.fsf@junk.nocrew.org>
Al Kossow wrote:
> https://github.com/arnoldrobbins/qed-archive/tree/master/sds-940
>
> SDS 940 QED
>
> "These files were supplied to me by Lars Brinkhoff (lars AT
> nocrew.org). I have no idea where he got them."
>
> Me, assuming he pulled them from the SDS940 tapes I recovered and are
> on bitsavers
>
> The .pdf scans are from me, so I assume the code came from bitsavers as well.
I got everything in a zip file from Mark Emmer when I asked him about QED.
From arnold at skeeve.com Sun Jan 31 17:57:03 2021
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sun, 31 Jan 2021 00:57:03 -0700
Subject: [TUHS] AT&T 3B1 - Emulation available
In-Reply-To: <em175b176f-e15d-40cc-bca0-23d0804827eb@alien>
References: <E1l5RL3-0002iv-Qv@tanda>
<em175b176f-e15d-40cc-bca0-23d0804827eb@alien>
Message-ID: <202101310757.10V7v3Tv004164@freefriends.org>
"Ronald Natalie" <ron at ronnatalie.com> wrote:
> Probably faster than the 3B1 was in real life.
Seems about as fast as I remember the hardware being, but that was
well over 25 years ago, so I don't know for sure.
> Being an educational institution in NJ (Rutgers) we had all sorts of
> AT&T stuff donated to us, 3B2's, 3B5's, and 3B20's.
Yes, Georgia Tech got 3B2s and 3B20s. An instructor there referred to the
3B20s as white elephants, and explained it to me (since I didn't know):
A white elephant is something obviously rare and valuable, but what
exactly do you do with it? :-)
Ours had a bunch of the CDC 300 Meg washing machine disk drives. A huge
amount of storage for the time. We (the lab staff) wanted to port BSD
Unix to them, but that never went anywhere.
> The 3B2 was the first machine that I came across I think with a soft
> power switch. Amusingly, the thing would not let you shut it down
> unless you were root (apparently, you don't have power switch privs as a
> normal user).
I remember occasionally just pulling the plug...
The 3B1 was a pleasure in comparison. Afforadable on a personal level
and eminently usable.
Arnold
From robpike at gmail.com Sun Jan 31 18:29:46 2021
From: robpike at gmail.com (Rob Pike)
Date: Sun, 31 Jan 2021 19:29:46 +1100
Subject: [TUHS] Qed vs ed
In-Reply-To: <7wh7mxpp4q.fsf@junk.nocrew.org>
References: <BCB902EF-06BD-4855-804E-9D7607D00847@gmail.com>
<f2330b8f-6273-e2dc-526b-901298fff5ee@gmail.com>
<316d3fab-cf62-2d2e-f721-f4398acffc06@bitsavers.org>
<7wh7mxpp4q.fsf@junk.nocrew.org>
Message-ID: <CAKzdPgxMiFVt5ejZm4-AHKEmqnimpZvqZXKy2afCsvkTOw0NXA@mail.gmail.com>
The version of qed Leah refers to is not pure. It was created in the late
1970s by Tom Duff, Hugh Redelmeier, David Tilbrook and myself by hacking
the (already hacked) v6 ed we had at the University of Toronto, to restore
some of the programmability that had been removed when ed was created, and
to have fun. Mostly to have fun.
Tom Duff used a real QED (sic) on the GCOS at Waterloo and was a bit
conflicted about all this. For me the programmability was fun, and I wrote
the tutorial, but what ended up sticking with me was the ability to edit
multiple files simultaneously, something no other editor I had available
could do. I don't mean switching between files, I mean making things like
global substitutions across *.c. I'd start a session by typing qed *.[ch]
and go from there.
Our qed traveled with me from Caltech to Bell Labs, where I used it to
write jim, which I used to write sam, which I used to write Acme. I tried
vi when starting jim, but again the one file thing was too much to bear. I
also tried emacs, which could in principle handle multiple files but the
interface was cumbersome - it was much too hard to open a new file in a
subwindow - and without regular expressions I gave up after a day or two.
Also with a 2-d screen and a 1-d input device (no mouse), vi and emacs were
too remote, like giving directions to someone holding a map without being
able to point at the map. Describing where you want to point rather than
just pointing.
Anyway that was 40 or so years ago, and it's clear from the screens on
others' desks at work that my opinion on those matters is not widely shared.
I had a lot of fun hacking qed, mostly side-by-side with Tilbrook, who was
its biggest fan. He taught me a lot and I loved working with him.
-rob
On Sun, Jan 31, 2021 at 6:01 PM Lars Brinkhoff <lars at nocrew.org> wrote:
> Al Kossow wrote:
> > https://github.com/arnoldrobbins/qed-archive/tree/master/sds-940
> >
> > SDS 940 QED
> >
> > "These files were supplied to me by Lars Brinkhoff (lars AT
> > nocrew.org). I have no idea where he got them."
> >
> > Me, assuming he pulled them from the SDS940 tapes I recovered and are
> > on bitsavers
> >
> > The .pdf scans are from me, so I assume the code came from bitsavers as
> well.
>
> I got everything in a zip file from Mark Emmer when I asked him about QED.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210131/4b965ab9/attachment-0001.htm>
From rdm at cfcl.com Sun Jan 31 18:41:55 2021
From: rdm at cfcl.com (Rich Morin)
Date: Sun, 31 Jan 2021 00:41:55 -0800
Subject: [TUHS] AT&T 3B1 - Emulation available
In-Reply-To: <202101310757.10V7v3Tv004164@freefriends.org>
References: <E1l5RL3-0002iv-Qv@tanda>
<em175b176f-e15d-40cc-bca0-23d0804827eb@alien>
<202101310757.10V7v3Tv004164@freefriends.org>
Message-ID: <CABF9FF5-5FB7-417F-8F33-D0B822EC5994@cfcl.com>
> On Jan 30, 2021, at 23:57, arnold at skeeve.com wrote:
>
> ... An instructor there referred to the 3B20s as white elephants,
> and explained it to me (since I didn't know):
> A white elephant is something obviously rare and valuable,
> but what exactly do you do with it? :-)
Actually, it's a bit worse than that:
> The term white elephant refers to an extravagant, impractical gift that cannot be easily disposed of. The phrase is said to come from the historic practice of the King of Siam (now Thailand) giving rare albino elephants to courtiers who had displeased him, so that they might be ruined by the animals' upkeep costs.
> -- https://en.wikipedia.org/wiki/White_elephant_gift_exchange
On a related note, I recall that Dick Karpinski won an IBM (?) minicomputer at a Usenix conference. Problem was, if he accepted it the taxes would be far more than any value it might have for him. So, he ended up doing some sort of dance that allowed the machine to go to someone else...
-r
From jaapna at xs4all.nl Sun Jan 31 19:28:09 2021
From: jaapna at xs4all.nl (Jaap Akkerhuis)
Date: Sun, 31 Jan 2021 10:28:09 +0100
Subject: [TUHS] Qed vs ed
In-Reply-To: <CAKzdPgxMiFVt5ejZm4-AHKEmqnimpZvqZXKy2afCsvkTOw0NXA@mail.gmail.com>
References: <BCB902EF-06BD-4855-804E-9D7607D00847@gmail.com>
<f2330b8f-6273-e2dc-526b-901298fff5ee@gmail.com>
<316d3fab-cf62-2d2e-f721-f4398acffc06@bitsavers.org>
<7wh7mxpp4q.fsf@junk.nocrew.org>
<CAKzdPgxMiFVt5ejZm4-AHKEmqnimpZvqZXKy2afCsvkTOw0NXA@mail.gmail.com>
Message-ID: <00F0758C-2E99-43C9-A989-1BD977248839@xs4all.nl>
> On Jan 31, 2021, at 9:29, Rob Pike <robpike at gmail.com> wrote:
>
> I had a lot of fun hacking qed, mostly side-by-side with Tilbrook, who was its biggest fan. He taught me a lot and I loved working with him.
Woking with David was great and always inspiring. I used to have an early version of his QEF system which did QED on it. He never stopped tinkeing with that. Alas, the tape got lost in one of my relocations.
jaap
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210131/bb5da0bc/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/20210131/bb5da0bc/attachment.sig>
From arnold at skeeve.com Sun Jan 31 20:04:25 2021
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sun, 31 Jan 2021 03:04:25 -0700
Subject: [TUHS] Qed vs ed
In-Reply-To: <316d3fab-cf62-2d2e-f721-f4398acffc06@bitsavers.org>
References: <BCB902EF-06BD-4855-804E-9D7607D00847@gmail.com>
<f2330b8f-6273-e2dc-526b-901298fff5ee@gmail.com>
<316d3fab-cf62-2d2e-f721-f4398acffc06@bitsavers.org>
Message-ID: <202101311004.10VA4P4N031865@freefriends.org>
Al,
I'm sorry you're pissed off. I was simply being honest about the
provenance of what's in the archive.
Now that I know more, I will update the README files to give
you credit.
Arnold
Al Kossow <aek at bitsavers.org> wrote:
>
> > https://leahneukirchen.org/blog/archive/2021/01/remembering-the-work-of-david-m-tilbrook-and-the-qed-editor.html
>
> references
>
> https://github.com/arnoldrobbins/qed-archive/tree/master/sds-940
>
> SDS 940 QED
>
> "These files were supplied to me by Lars Brinkhoff (lars AT nocrew.org). I have no idea where he got them."
>
> Me, assuming he pulled them from the SDS940 tapes I recovered and are on bitsavers
>
> The .pdf scans are from me, so I assume the code came from bitsavers as well.
>
> Shit like this pisses me off.
From dtynan at kalopa.com Sun Jan 31 22:23:13 2021
From: dtynan at kalopa.com (Dermot Tynan)
Date: Sun, 31 Jan 2021 12:23:13 +0000
Subject: [TUHS] [SPAM] Re: FreeBSD behind the times?
In-Reply-To: <20210130235459.GR4227@mcvoy.com>
References: <CAEuQd1C91GOZ7eJ6U+_hUz31AEDB-rfR=0tH6fdbkz8RCESBkA@mail.gmail.com>
<202101301950.10UJoWeA456408@darkstar.fourwinds.com>
<CAEuQd1Dpbcs=kd0XynnwUkYoL_UgRfd355ttZcsLiB8Hf4gEXQ@mail.gmail.com>
<CAC20D2M0_X3Tw7371jnrMvUiDBOFDRW1Y6Cycmu_QKnWhotU4A@mail.gmail.com>
<20210130222854.GN4227@mcvoy.com> <20210130231119.GA33905@eureka.lemis.com>
<20210130231750.GQ4227@mcvoy.com>
<CANCZdfrzZrHeyuGFevGCaeHk7QfiBj7+jZGrB2MQ+N6tYW0vYw@mail.gmail.com>
<20210130233117.GR4568@mcvoy.com>
<202101302337.10UNbTMU465941@darkstar.fourwinds.com>
<20210130235459.GR4227@mcvoy.com>
Message-ID: <7a74fe75-6063-2c4c-cabb-d9dacf7e271f@kalopa.com>
On 30/01/2021 23:54, Larry McVoy wrote:
> You like FreeBSD, cool, it's fine. Nobody will ever know because nobody
> is going to put up with a 1990's era installer. Nobody. It's 2020, shit
> is just supposed to work, it's supposed do so in a graphical environment
> let works with or without a mouse. Anyone who doesn't see that isn't
> going to get any market share.
It's "horses for courses". I run a mix of FreeBSD and Linux servers. As
they're headless, the last thing I want is X on there. Ideally, I'd
strip out the automount crap as well, to say nothing of the horror that
is systemd. But yeah, those people with desktops want a simple GUI
install and they want their USB stick to appear as a "folder". I run
Ubuntu on my desktop for vaguely those reasons (and Dropbox!).
I think the biggest threat to FreeBSD is docker/k8s and things like
libvirt. Unfortunately, most open source (and closed source) software
runs de facto on Linux (if it runs on Unix-esque systems), and the ports
to FreeBSD are slow in coming. Last time I looked, there was no native
Dropbox client.
As a server though, if you don't need to use it as a hypervisor or a
container system, it gets my vote. But again it's down to preference.
Linux has the breeze now, and is streaking ahead of the *BSDs. Sad, but
true.
                  - Der
--
Dermot Tynan
dtynan at kalopa.com