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: > 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: 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: <202012310810.0BV8ADZ3027195@freefriends.org> Message-ID: On Thu, Dec 31, 2020, 1:10 AM 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 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 : > > > > > 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: 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: References: <202012310810.0BV8ADZ3027195@freefriends.org> 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: <202012310810.0BV8ADZ3027195@freefriends.org> <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: References: 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 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: <202012310810.0BV8ADZ3027195@freefriends.org> <950DAE25-BCAD-47EF-8FCE-A716271A3C25@gmail.com> Message-ID: 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 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 : >>> 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: References: <202012310810.0BV8ADZ3027195@freefriends.org> <950DAE25-BCAD-47EF-8FCE-A716271A3C25@gmail.com> Message-ID: On Thu, Dec 31, 2020 at 11:37 AM Theodore Ts'o 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: 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: <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 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: 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: 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: 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: > 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: 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: References: Message-ID: On 2020-Dec-31 18:19:39 +1100, 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? 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: 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: References: Message-ID: 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: 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: References: Message-ID: 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 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: 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: References: Message-ID: 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 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: 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: References: 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 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: References: Message-ID: Ah, he of the infamous Device? Interesting. Niklas Den mån 4 jan. 2021 kl 10:08 skrev Rob Pike : > 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 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: 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: References: Message-ID: 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 wrote: > On 2020-Dec-31 18:19:39 +1100, 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? > > 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: 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: References: Message-ID: 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 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 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: 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: References: Message-ID: 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 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 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 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: 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: References: Message-ID: 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: References: Message-ID: On Mon, Jan 4, 2021 at 2:50 PM Dave Horsfall 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: 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: 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 (or just press ) 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: References: Message-ID: On Mon, Jan 4, 2021 at 4:57 PM Warner Losh wrote: > On Mon, Jan 4, 2021 at 2:50 PM Dave Horsfall 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: 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: References: Message-ID: On Tue, Jan 5, 2021 at 11:06 AM Dan Cross wrote: > On Mon, Jan 4, 2021 at 4:57 PM Warner Losh wrote: > >> On Mon, Jan 4, 2021 at 2:50 PM Dave Horsfall 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: 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: References: <202012310810.0BV8ADZ3027195@freefriends.org> 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 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: 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: <202012310810.0BV8ADZ3027195@freefriends.org> <20210106163225.GC2973@darioniedermann.it> Message-ID: On Wed, 6 Jan 2021 at 11:40, Dario Niedermann wrote: > Il 31/12/2020 alle 16:30, Warner Losh ha scritto: > > >On Thu, Dec 31, 2020, 1:10 AM 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: 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: References: <202012310810.0BV8ADZ3027195@freefriends.org> <20210106163225.GC2973@darioniedermann.it> 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 >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: -- Dario Niedermann -:- finger my email address for PGP key, etc. Also on the Internet at: 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: References: <202012310810.0BV8ADZ3027195@freefriends.org> <20210106163225.GC2973@darioniedermann.it> Message-ID: 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: <202012310810.0BV8ADZ3027195@freefriends.org> <20210106163225.GC2973@darioniedermann.it> Message-ID: 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: References: Message-ID: 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, 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: 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: References: Message-ID: > 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, 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: 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: References: Message-ID: 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: Ah cithep, I remember you well! -rob On Sat, Jan 9, 2021 at 7:46 PM Norman Wilson 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: 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: >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 >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: References: Message-ID: 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, 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: 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: References: Message-ID: 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: 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: References: Message-ID: I'll be 41 next month. Den sön 10 jan. 2021 kl 08:23 skrev Valdimar Sigurdsson : > 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: 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: References: Message-ID: 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, 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: 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: References: Message-ID: 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: <202012310810.0BV8ADZ3027195@freefriends.org> <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: <202012310810.0BV8ADZ3027195@freefriends.org> <950DAE25-BCAD-47EF-8FCE-A716271A3C25@gmail.com> <20201231161228.GG28420@mcvoy.com> <32aeb853e5c56bc04dd2e9e2310f96a7@alanlee.org> Message-ID: > 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 , 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: 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: 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: 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: References: Message-ID: 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: 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: References: Message-ID: 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: References: Message-ID: 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: References: Message-ID: <06ac5d52f3105219f56cad709f931675@firemail.de> An HTML attachment was scrubbed... URL: 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: 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" To: "The Eunuchs Hysterical Society" 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: 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: References: Message-ID: Congratulations, Ken! Well deserved. Best regards, Niklas Den tors 14 jan. 2021 kl 00:43 skrev Royce Williams : > 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: 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: thank you. On Thu, Jan 14, 2021 at 7:20 AM Steffen Nurpmeso 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: 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: References: Message-ID: On Thu, Jan 14, 2021 at 12:00 AM Dave Horsfall 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: 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: References: Message-ID: 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: References: <8225455.9789.1610630513672.JavaMail.root@zimbraanteil> <20210114151927.wgPhi%steffen@sdaoden.eu> Message-ID: <20210114225724.WycQC%steffen@sdaoden.eu> Ken Thompson wrote in : |On Thu, Jan 14, 2021 at 7:20 AM Steffen Nurpmeso \ |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: References: Message-ID: 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 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: 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: References: Message-ID: 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: References: Message-ID: On Fri, Jan 15, 2021 at 3:14 PM Dave Horsfall 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: 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: References: Message-ID: On Fri, Jan 15, 2021 at 3:18 PM John Cowan wrote: > > > On Fri, Jan 15, 2021 at 3:14 PM Dave Horsfall 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: 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 again, thanks to those who replied. > On Jan 15, 2021, at 5:54 PM, Andrew Hume 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: 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 > On Jan 15, 2021, at 5:54 PM, Andrew Hume 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: 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: 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: References: Message-ID: 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 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: 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 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 > > > > On Jan 15, 2021, at 5:54 PM, Andrew Hume 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: 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: References: 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 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 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 bEGREGb (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: References: Message-ID: 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: 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 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: 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: 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: 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: 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 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 wrote: > > Andrew Hume (dammit andrew): > > i have probed recently about the origins of the bEGREGb (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: On Sun, Jan 17, 2021 at 5:35 PM Norman Wilson 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: 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: References: <1610922832.12835.for-standards-violators@oclsc.org> Message-ID: 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: References: <1610922832.12835.for-standards-violators@oclsc.org> Message-ID: <202101190807.10J87Gh5009801@freefriends.org> Steve Nickolas 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> <202101190807.10J87Gh5009801@freefriends.org> Message-ID: <20210119184554.uCRQ_%steffen@sdaoden.eu> arnold at skeeve.com wrote in <202101190807.10J87Gh5009801 at freefriends.org>: |Steve Nickolas 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> <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: References: 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 > wrote: > > > > On Fri, Jan 15, 2021 at 3:14 PM Dave Horsfall > 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: 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: <66d2d6e9-921c-8039-1d84-0461f9192a28@osta.com> Message-ID: On Tue, Jan 19, 2021 at 3:30 PM Heinz Lycklama 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 wrote: > >> >> >> On Fri, Jan 15, 2021 at 3:14 PM Dave Horsfall 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: 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: 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: References: <66d2d6e9-921c-8039-1d84-0461f9192a28@osta.com> Message-ID: 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 > 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 > > wrote: >> >> >> >> On Fri, Jan 15, 2021 at 3:14 PM Dave Horsfall >> > 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: 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: 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: References: Message-ID: On Wednesday, January 20, 2021, Dave Plonka 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: 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: 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: References: Message-ID: 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: References: 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: <1611184288.26419.9.camel@mni.thm.de> Message-ID: 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: 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: 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: 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: References: 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: <20210124045233.335C79C669@minnie.tuhs.org> Message-ID: John Foust 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: References: <20210124045233.335C79C669@minnie.tuhs.org> 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: <20210124045233.335C79C669@minnie.tuhs.org> <76f0ffc9-a5d7-471c-9bac-84d5427892b3@localhost> Message-ID: 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: 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: Noel Chiappa 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: References: 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: References: Message-ID: On Sun, Jan 24, 2021 at 11:15 AM ron minnich 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: 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: References: Message-ID: On Sun, Jan 24, 2021 at 11:16 AM ron minnich 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: 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: References: 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: References: 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 > 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: References: Message-ID: <202101241842.10OIgrhP008354@freefriends.org> Dan Cross wrote: > On Sun, Jan 24, 2021 at 11:16 AM ron minnich 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: <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 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: <20210124183653.GD21030@mcvoy.com> Message-ID: 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: References: <20210124183653.GD21030@mcvoy.com> 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: <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: <20210124183653.GD21030@mcvoy.com> <20210124205451.GH21030@mcvoy.com> Message-ID: 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" To: "Ronald Natalie" Cc: "Larry McVoy" ; "Clem Cole" ; "TUHS main list" 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: References: Message-ID: 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: References: Message-ID: >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: <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: <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: References: 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: <20210124183653.GD21030@mcvoy.com> <202101242045.10OKjDvA964774@darkstar.fourwinds.com> <20210124211100.GI21030@mcvoy.com> <202101242114.10OLEYGk966708@darkstar.fourwinds.com> Message-ID: >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: <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: <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: <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: References: Message-ID: 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 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: <20210124183653.GD21030@mcvoy.com> <202101242045.10OKjDvA964774@darkstar.fourwinds.com> <20210124211100.GI21030@mcvoy.com> <202101242114.10OLEYGk966708@darkstar.fourwinds.com> <20210124212525.GJ21030@mcvoy.com> Message-ID: On Sun, Jan 24, 2021 at 4:25 PM Larry McVoy 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: 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: References: <20210124183653.GD21030@mcvoy.com> <202101242045.10OKjDvA964774@darkstar.fourwinds.com> <20210124211100.GI21030@mcvoy.com> <202101242114.10OLEYGk966708@darkstar.fourwinds.com> <20210124212525.GJ21030@mcvoy.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: <20210124183653.GD21030@mcvoy.com> <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: 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: On 1/24/21, 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. 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: <20210124183653.GD21030@mcvoy.com> <202101242045.10OKjDvA964774@darkstar.fourwinds.com> <20210124211100.GI21030@mcvoy.com> <202101242114.10OLEYGk966708@darkstar.fourwinds.com> <20210124212525.GJ21030@mcvoy.com> Message-ID: On 1/24/21, Larry McVoy 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: <20210124183653.GD21030@mcvoy.com> <202101242045.10OKjDvA964774@darkstar.fourwinds.com> <20210124211100.GI21030@mcvoy.com> <202101242114.10OLEYGk966708@darkstar.fourwinds.com> <20210124212525.GJ21030@mcvoy.com> <202101242333.10ONXjcI974038@darkstar.fourwinds.com> Message-ID: 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: <20210124183653.GD21030@mcvoy.com> <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: References: <20210124183653.GD21030@mcvoy.com> <202101242045.10OKjDvA964774@darkstar.fourwinds.com> <20210124211100.GI21030@mcvoy.com> <202101242114.10OLEYGk966708@darkstar.fourwinds.com> <20210124212525.GJ21030@mcvoy.com> <202101242333.10ONXjcI974038@darkstar.fourwinds.com> 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: <20210124183653.GD21030@mcvoy.com> <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: 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: <20210124183653.GD21030@mcvoy.com> <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: References: <20200919152835.4E73A18C0DD@mercury.lcs.mit.edu> Message-ID: 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 wrote: > > Noel Chiappa 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: (Gregg Levine's message of "Sun, 24 Jan 2021 23:58:36 -0500") References: <20200919152835.4E73A18C0DD@mercury.lcs.mit.edu> Message-ID: Gregg Levine 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: 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 ) - Let the Machine Do the Dirty Work (from Elements of Programming Style) - Rule of Silence (from TAOUP ) - Data Dominates (Rob Pike #5) - The SPOT (Single Point of Truth) Rule (from TAOUP ) Tyler -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: Message-ID: 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 > ) > - Let the Machine Do the Dirty Work (from Elements of Programming Style) > - Rule of Silence (from TAOUP ) > - Data Dominates (Rob Pike #5) > - The SPOT (Single Point of Truth) Rule (from TAOUP > ) > > 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: References: <20210124183653.GD21030@mcvoy.com> <202101242045.10OKjDvA964774@darkstar.fourwinds.com> <20210124211100.GI21030@mcvoy.com> <202101242114.10OLEYGk966708@darkstar.fourwinds.com> <20210124212525.GJ21030@mcvoy.com> <202101242333.10ONXjcI974038@darkstar.fourwinds.com> Message-ID: On Sun, Jan 24, 2021 at 7:11 PM Al Kossow 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: 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: <20210124183653.GD21030@mcvoy.com> <202101242045.10OKjDvA964774@darkstar.fourwinds.com> <20210124211100.GI21030@mcvoy.com> <202101242114.10OLEYGk966708@darkstar.fourwinds.com> <20210124212525.GJ21030@mcvoy.com> <202101242333.10ONXjcI974038@darkstar.fourwinds.com> <202101250021.10P0L3Z2976588@darkstar.fourwinds.com> Message-ID: On Sun, Jan 24, 2021 at 7:21 PM Jon Steinhart 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: 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: References: <20210124183653.GD21030@mcvoy.com> <202101242045.10OKjDvA964774@darkstar.fourwinds.com> <20210124211100.GI21030@mcvoy.com> <202101242114.10OLEYGk966708@darkstar.fourwinds.com> <20210124212525.GJ21030@mcvoy.com> <202101242333.10ONXjcI974038@darkstar.fourwinds.com> <202101250021.10P0L3Z2976588@darkstar.fourwinds.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: References: <20210124183653.GD21030@mcvoy.com> <202101242045.10OKjDvA964774@darkstar.fourwinds.com> <20210124211100.GI21030@mcvoy.com> <202101242114.10OLEYGk966708@darkstar.fourwinds.com> <20210124212525.GJ21030@mcvoy.com> <202101242333.10ONXjcI974038@darkstar.fourwinds.com> <202101250021.10P0L3Z2976588@darkstar.fourwinds.com> Message-ID: On Mon, 25 Jan 2021 at 09:39, Clem Cole wrote: > > > On Sun, Jan 24, 2021 at 7:21 PM Jon Steinhart 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 workstation, judged X the only windowing system likely to become available in time. DEC engineers ported X6 to DEC's QVSS display on 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: 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: <20210124183653.GD21030@mcvoy.com> <202101242045.10OKjDvA964774@darkstar.fourwinds.com> <20210124211100.GI21030@mcvoy.com> <202101242114.10OLEYGk966708@darkstar.fourwinds.com> <20210124212525.GJ21030@mcvoy.com> <202101242333.10ONXjcI974038@darkstar.fourwinds.com> <202101250021.10P0L3Z2976588@darkstar.fourwinds.com> <6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org> Message-ID: 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: 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: 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: References: <20210124211100.GI21030@mcvoy.com> <202101242114.10OLEYGk966708@darkstar.fourwinds.com> <20210124212525.GJ21030@mcvoy.com> <202101242333.10ONXjcI974038@darkstar.fourwinds.com> <202101250021.10P0L3Z2976588@darkstar.fourwinds.com> <6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org> 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> <202101242333.10ONXjcI974038@darkstar.fourwinds.com> <202101250021.10P0L3Z2976588@darkstar.fourwinds.com> <6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org> <20210125160430.GR21030@mcvoy.com> Message-ID: On Mon, Jan 25, 2021 at 11:05 AM Larry McVoy 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: 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: References: <20210124211100.GI21030@mcvoy.com> <202101242114.10OLEYGk966708@darkstar.fourwinds.com> <20210124212525.GJ21030@mcvoy.com> <202101242333.10ONXjcI974038@darkstar.fourwinds.com> <202101250021.10P0L3Z2976588@darkstar.fourwinds.com> <6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org> <20210125160430.GR21030@mcvoy.com> Message-ID: > 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: 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: References: Message-ID: 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 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: 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: References: <20210124212525.GJ21030@mcvoy.com> <202101242333.10ONXjcI974038@darkstar.fourwinds.com> <202101250021.10P0L3Z2976588@darkstar.fourwinds.com> <6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org> <20210125160430.GR21030@mcvoy.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 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: References: <20210124183653.GD21030@mcvoy.com> <202101242045.10OKjDvA964774@darkstar.fourwinds.com> <20210124211100.GI21030@mcvoy.com> <202101242114.10OLEYGk966708@darkstar.fourwinds.com> <20210124212525.GJ21030@mcvoy.com> <202101242333.10ONXjcI974038@darkstar.fourwinds.com> <202101250021.10P0L3Z2976588@darkstar.fourwinds.com> <6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org> 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: References: <20210124211100.GI21030@mcvoy.com> <202101242114.10OLEYGk966708@darkstar.fourwinds.com> <20210124212525.GJ21030@mcvoy.com> <202101242333.10ONXjcI974038@darkstar.fourwinds.com> <202101250021.10P0L3Z2976588@darkstar.fourwinds.com> <6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org> <20210125160430.GR21030@mcvoy.com> Message-ID: <9727.1611618394@hop.toad.com> Dan Cross 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: References: <20210124183653.GD21030@mcvoy.com> <202101242045.10OKjDvA964774@darkstar.fourwinds.com> <20210124211100.GI21030@mcvoy.com> <202101242114.10OLEYGk966708@darkstar.fourwinds.com> <20210124212525.GJ21030@mcvoy.com> <202101242333.10ONXjcI974038@darkstar.fourwinds.com> <202101250021.10P0L3Z2976588@darkstar.fourwinds.com> <6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org> 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: References: Message-ID: 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 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 >) > > - Data Dominates (Rob Pike #5) > > - The SPOT (Single Point of Truth) Rule (from TAOUP > > ) > > > > 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: 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: References: <20210124183653.GD21030@mcvoy.com> <202101242045.10OKjDvA964774@darkstar.fourwinds.com> <20210124211100.GI21030@mcvoy.com> <202101242114.10OLEYGk966708@darkstar.fourwinds.com> <20210124212525.GJ21030@mcvoy.com> <202101242333.10ONXjcI974038@darkstar.fourwinds.com> <202101250021.10P0L3Z2976588@darkstar.fourwinds.com> <6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org> Message-ID: On Mon, Jan 25, 2021 at 10:56 AM Richard Salz 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: 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: References: Message-ID: 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: References: Message-ID: 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 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 >> > ) >> > >> > 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: 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: References: Message-ID: On Tue, Jan 26, 2021 at 5:24 AM Tyler Adams 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: 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: References: Message-ID: On Tue, Jan 26, 2021 at 5:23 AM Tyler Adams 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: 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: References: Message-ID: Den tis 26 jan. 2021 kl 16:24 skrev Clem Cole : > > > On Tue, Jan 26, 2021 at 5:23 AM Tyler Adams 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: 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: References: Message-ID: On Mon, 25 Jan 2021 at 11:02, Arnold Robbins 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: 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: References: Message-ID: 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 wrote: > > > Den tis 26 jan. 2021 kl 16:24 skrev Clem Cole : > >> >> >> On Tue, Jan 26, 2021 at 5:23 AM Tyler Adams >> 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: 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: References: 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 > 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 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: References: Message-ID: <202101261833.10QIXVkq022332@freefriends.org> Hi. Henry Bent wrote: > On Mon, 25 Jan 2021 at 11:02, Arnold Robbins 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: <8a17ae54-1b00-e9f7-ea44-763c29c4023f@technologists.com> Message-ID: <202101261843.10QIhW6A023727@freefriends.org> "Charles H. Sauer" 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: References: <20210124045233.335C79C669@minnie.tuhs.org> 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: 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: <20210124045233.335C79C669@minnie.tuhs.org> <20210126151751.GF2973@darioniedermann.it> Message-ID: Looks like `rc` to me. On Tue, Jan 26, 2021 at 5:32 PM Dario Niedermann 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: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: <20210124045233.335C79C669@minnie.tuhs.org> <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: <20210124045233.335C79C669@minnie.tuhs.org> <20210126151751.GF2973@darioniedermann.it> <20210126224300.HQ1NP%steffen@sdaoden.eu> Message-ID: > 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: 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: References: <20210124045233.335C79C669@minnie.tuhs.org> <20210126151751.GF2973@darioniedermann.it> <20210126224300.HQ1NP%steffen@sdaoden.eu> Message-ID: On Tue, Jan 26, 2021 at 3:19 PM Richard Salz 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 -----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 > 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 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: References: Message-ID: 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, 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: 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: <20210124183653.GD21030@mcvoy.com> <202101242045.10OKjDvA964774@darkstar.fourwinds.com> <20210124211100.GI21030@mcvoy.com> <202101242114.10OLEYGk966708@darkstar.fourwinds.com> <20210124212525.GJ21030@mcvoy.com> <202101242333.10ONXjcI974038@darkstar.fourwinds.com> <202101250021.10P0L3Z2976588@darkstar.fourwinds.com> <6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org> <202101260138.10Q1ceo21049597@darkstar.fourwinds.com> Message-ID: 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: References: <20210124183653.GD21030@mcvoy.com> <202101242045.10OKjDvA964774@darkstar.fourwinds.com> <20210124211100.GI21030@mcvoy.com> <202101242114.10OLEYGk966708@darkstar.fourwinds.com> <20210124212525.GJ21030@mcvoy.com> <202101242333.10ONXjcI974038@darkstar.fourwinds.com> <202101250021.10P0L3Z2976588@darkstar.fourwinds.com> <6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org> <202101260138.10Q1ceo21049597@darkstar.fourwinds.com> 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: <20210124183653.GD21030@mcvoy.com> <202101242045.10OKjDvA964774@darkstar.fourwinds.com> <20210124211100.GI21030@mcvoy.com> <202101242114.10OLEYGk966708@darkstar.fourwinds.com> <20210124212525.GJ21030@mcvoy.com> <202101242333.10ONXjcI974038@darkstar.fourwinds.com> <202101250021.10P0L3Z2976588@darkstar.fourwinds.com> <6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org> <202101260138.10Q1ceo21049597@darkstar.fourwinds.com> <202101270354.10R3s8Z01128207@darkstar.fourwinds.com> Message-ID: >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: References: <202007261531.06QFVqZb027062@freefriends.org> <202007261535.06QFZvLg027250@freefriends.org> <202007261711.06QHB07i032409@freefriends.org> Message-ID: [[ 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 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 Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: 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: <20210124183653.GD21030@mcvoy.com> <202101242045.10OKjDvA964774@darkstar.fourwinds.com> <20210124211100.GI21030@mcvoy.com> <202101242114.10OLEYGk966708@darkstar.fourwinds.com> <20210124212525.GJ21030@mcvoy.com> <202101242333.10ONXjcI974038@darkstar.fourwinds.com> <202101250021.10P0L3Z2976588@darkstar.fourwinds.com> <6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org> <202101260138.10Q1ceo21049597@darkstar.fourwinds.com> <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: 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: References: <20210124183653.GD21030@mcvoy.com> <202101242045.10OKjDvA964774@darkstar.fourwinds.com> <20210124211100.GI21030@mcvoy.com> <202101242114.10OLEYGk966708@darkstar.fourwinds.com> <20210124212525.GJ21030@mcvoy.com> <202101242333.10ONXjcI974038@darkstar.fourwinds.com> <202101250021.10P0L3Z2976588@darkstar.fourwinds.com> <6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org> <202101260138.10Q1ceo21049597@darkstar.fourwinds.com> <202101270354.10R3s8Z01128207@darkstar.fourwinds.com> Message-ID: 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: References: <862d8a34-456d-33c1-7ef0-58c6e8089de9@tnetconsulting.net> <202007211822.06LIMBJ4018831@freefriends.org> <20200722011603.GA1536749@mit.edu> Message-ID: [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 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 Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: 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: References: Message-ID: At Mon, 27 Jul 2020 12:57:59 -0600, Warner Losh 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 Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: 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: <20210124183653.GD21030@mcvoy.com> <202101242045.10OKjDvA964774@darkstar.fourwinds.com> <20210124211100.GI21030@mcvoy.com> <202101242114.10OLEYGk966708@darkstar.fourwinds.com> <20210124212525.GJ21030@mcvoy.com> <202101242333.10ONXjcI974038@darkstar.fourwinds.com> <202101250021.10P0L3Z2976588@darkstar.fourwinds.com> <6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org> <202101260138.10Q1ceo21049597@darkstar.fourwinds.com> <202101270354.10R3s8Z01128207@darkstar.fourwinds.com> <0a112927-2b0e-12cd-d4cc-a2cb79f58aac@spamtrap.tnetconsulting.net> Message-ID: On Wed, 27 Jan 2021 at 00:49, Grant Taylor via TUHS 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: 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: <20210124183653.GD21030@mcvoy.com> <202101242045.10OKjDvA964774@darkstar.fourwinds.com> <20210124211100.GI21030@mcvoy.com> <202101242114.10OLEYGk966708@darkstar.fourwinds.com> <20210124212525.GJ21030@mcvoy.com> <202101242333.10ONXjcI974038@darkstar.fourwinds.com> <202101250021.10P0L3Z2976588@darkstar.fourwinds.com> <6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org> <202101260138.10Q1ceo21049597@darkstar.fourwinds.com> <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: <20210124183653.GD21030@mcvoy.com> <202101242045.10OKjDvA964774@darkstar.fourwinds.com> <20210124211100.GI21030@mcvoy.com> <202101242114.10OLEYGk966708@darkstar.fourwinds.com> <20210124212525.GJ21030@mcvoy.com> <202101242333.10ONXjcI974038@darkstar.fourwinds.com> <202101250021.10P0L3Z2976588@darkstar.fourwinds.com> <6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org> <202101260138.10Q1ceo21049597@darkstar.fourwinds.com> <202101270354.10R3s8Z01128207@darkstar.fourwinds.com> <0a112927-2b0e-12cd-d4cc-a2cb79f58aac@spamtrap.tnetconsulting.net> Message-ID: 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: References: <20210124212525.GJ21030@mcvoy.com> <202101242333.10ONXjcI974038@darkstar.fourwinds.com> <202101250021.10P0L3Z2976588@darkstar.fourwinds.com> <6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org> <202101260138.10Q1ceo21049597@darkstar.fourwinds.com> 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: <20210124183653.GD21030@mcvoy.com> <202101242045.10OKjDvA964774@darkstar.fourwinds.com> <20210124211100.GI21030@mcvoy.com> <202101242114.10OLEYGk966708@darkstar.fourwinds.com> <20210124212525.GJ21030@mcvoy.com> <202101242333.10ONXjcI974038@darkstar.fourwinds.com> <202101250021.10P0L3Z2976588@darkstar.fourwinds.com> <6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org> <202101260138.10Q1ceo21049597@darkstar.fourwinds.com> <202101270354.10R3s8Z01128207@darkstar.fourwinds.com> <0a112927-2b0e-12cd-d4cc-a2cb79f58aac@spamtrap.tnetconsulting.net> Message-ID: 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: 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: References: <862d8a34-456d-33c1-7ef0-58c6e8089de9@tnetconsulting.net> <202007211822.06LIMBJ4018831@freefriends.org> <20200722011603.GA1536749@mit.edu> 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, > 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. 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: 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: References: <202101242045.10OKjDvA964774@darkstar.fourwinds.com> <20210124211100.GI21030@mcvoy.com> <202101242114.10OLEYGk966708@darkstar.fourwinds.com> <20210124212525.GJ21030@mcvoy.com> <202101242333.10ONXjcI974038@darkstar.fourwinds.com> <202101250021.10P0L3Z2976588@darkstar.fourwinds.com> <6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org> <202101260138.10Q1ceo21049597@darkstar.fourwinds.com> <202101270354.10R3s8Z01128207@darkstar.fourwinds.com> <0a112927-2b0e-12cd-d4cc-a2cb79f58aac@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: References: <20210124183653.GD21030@mcvoy.com> <202101242045.10OKjDvA964774@darkstar.fourwinds.com> <20210124211100.GI21030@mcvoy.com> <202101242114.10OLEYGk966708@darkstar.fourwinds.com> <20210124212525.GJ21030@mcvoy.com> <202101242333.10ONXjcI974038@darkstar.fourwinds.com> <202101250021.10P0L3Z2976588@darkstar.fourwinds.com> <6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org> Message-ID: 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: 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> <202101242333.10ONXjcI974038@darkstar.fourwinds.com> <202101250021.10P0L3Z2976588@darkstar.fourwinds.com> <6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org> <202101260138.10Q1ceo21049597@darkstar.fourwinds.com> <20210127154742.GB4227@mcvoy.com> Message-ID: 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: 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 Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: 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: References: Message-ID: 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 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 > > Kelowna, BC +1 250 762-7675 RoboHack > Planix, Inc. Avoncote Farms > -------------- next part -------------- An HTML attachment was scrubbed... URL: 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> <20200722011603.GA1536749@mit.edu> <64f487fb-6fed-e741-4e7b-daed1f646e37@spamtrap.tnetconsulting.net> Message-ID: On Wed, Jan 27, 2021 at 12:06 PM Grant Taylor via TUHS 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, > > > > > 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. > > > > 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: 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> <20200722011603.GA1536749@mit.edu> <64f487fb-6fed-e741-4e7b-daed1f646e37@spamtrap.tnetconsulting.net> Message-ID: At Wed, 27 Jan 2021 12:06:26 -0700, Grant Taylor via TUHS 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 Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: 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: References: <202007261531.06QFVqZb027062@freefriends.org> <202007261535.06QFZvLg027250@freefriends.org> <202007261711.06QHB07i032409@freefriends.org> Message-ID: <17854.1611793153@hop.toad.com> Greg A. Woods 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: <202007261531.06QFVqZb027062@freefriends.org> <202007261535.06QFZvLg027250@freefriends.org> <202007261711.06QHB07i032409@freefriends.org> <17854.1611793153@hop.toad.com> Message-ID: 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 wrote: > Greg A. Woods 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: 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: References: <202007261531.06QFVqZb027062@freefriends.org> <202007261535.06QFZvLg027250@freefriends.org> <202007261711.06QHB07i032409@freefriends.org> <17854.1611793153@hop.toad.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 wrote: > > > Greg A. Woods 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: References: <202007261531.06QFVqZb027062@freefriends.org> <202007261535.06QFZvLg027250@freefriends.org> <202007261711.06QHB07i032409@freefriends.org> <17854.1611793153@hop.toad.com> Message-ID: <30778.1611803999@hop.toad.com> Clem Cole 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: References: <862d8a34-456d-33c1-7ef0-58c6e8089de9@tnetconsulting.net> <202007211822.06LIMBJ4018831@freefriends.org> <20200722011603.GA1536749@mit.edu> <64f487fb-6fed-e741-4e7b-daed1f646e37@spamtrap.tnetconsulting.net> 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: 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: References: <202007261531.06QFVqZb027062@freefriends.org> <202007261535.06QFZvLg027250@freefriends.org> <202007261711.06QHB07i032409@freefriends.org> <17854.1611793153@hop.toad.com> Message-ID: 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 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 wrote: > >> Greg A. Woods 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: 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: <1611184288.26419.9.camel@mni.thm.de> Message-ID: 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: 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 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: 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 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: References: <20210128214551.GA27614@minnie.tuhs.org> Message-ID: 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 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 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: References: <20210128214551.GA27614@minnie.tuhs.org> Message-ID: 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 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 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 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: References: <20210128214551.GA27614@minnie.tuhs.org> 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 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: 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: References: Message-ID: 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: References: Message-ID: 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: References: Message-ID: On Fri, Jan 29, 2021 at 9:00 AM Ronald Natalie 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: 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: References: <20210124211100.GI21030@mcvoy.com> <202101242114.10OLEYGk966708@darkstar.fourwinds.com> <20210124212525.GJ21030@mcvoy.com> <202101242333.10ONXjcI974038@darkstar.fourwinds.com> <202101250021.10P0L3Z2976588@darkstar.fourwinds.com> <6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org> <20210125160430.GR21030@mcvoy.com> Message-ID: 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> <202101242333.10ONXjcI974038@darkstar.fourwinds.com> <202101250021.10P0L3Z2976588@darkstar.fourwinds.com> <6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org> <20210125160430.GR21030@mcvoy.com> <20210125172531.GP32503@mcvoy.com> Message-ID: 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: References: <202101242333.10ONXjcI974038@darkstar.fourwinds.com> <202101250021.10P0L3Z2976588@darkstar.fourwinds.com> <6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org> <20210125160430.GR21030@mcvoy.com> <20210125172531.GP32503@mcvoy.com> 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: References: <20210124183653.GD21030@mcvoy.com> <202101242045.10OKjDvA964774@darkstar.fourwinds.com> <20210124211100.GI21030@mcvoy.com> <202101242114.10OLEYGk966708@darkstar.fourwinds.com> <20210124212525.GJ21030@mcvoy.com> <202101242333.10ONXjcI974038@darkstar.fourwinds.com> <202101250021.10P0L3Z2976588@darkstar.fourwinds.com> <6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org> Message-ID: 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: References: <20200817192715.22D9518C09E@mercury.lcs.mit.edu> Message-ID: At Mon, 17 Aug 2020 17:52:08 -0700, Rob Gingell 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 Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: 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: References: <20210124183653.GD21030@mcvoy.com> <202101242045.10OKjDvA964774@darkstar.fourwinds.com> <20210124211100.GI21030@mcvoy.com> <202101242114.10OLEYGk966708@darkstar.fourwinds.com> <20210124212525.GJ21030@mcvoy.com> <202101242333.10ONXjcI974038@darkstar.fourwinds.com> <202101250021.10P0L3Z2976588@darkstar.fourwinds.com> <6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.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: References: <20210124183653.GD21030@mcvoy.com> <202101242045.10OKjDvA964774@darkstar.fourwinds.com> <20210124211100.GI21030@mcvoy.com> <202101242114.10OLEYGk966708@darkstar.fourwinds.com> <20210124212525.GJ21030@mcvoy.com> <202101242333.10ONXjcI974038@darkstar.fourwinds.com> <202101250021.10P0L3Z2976588@darkstar.fourwinds.com> <6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org> Message-ID: 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: 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> <202101282305.10SN5wxt164484@darkstar.fourwinds.com> Message-ID: On Thu, Jan 28, 2021 at 6:06 PM Jon Steinhart 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: 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: References: <20210128214551.GA27614@minnie.tuhs.org> Message-ID: 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: 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: References: Message-ID: 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 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 >>> 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 >>>> > ) >>>> > >>>> > 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: 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: References: 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: <202101301950.10UJoWeA456408@darkstar.fourwinds.com> Message-ID: 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 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: 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: References: <202101301950.10UJoWeA456408@darkstar.fourwinds.com> Message-ID: 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 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 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: 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: References: <202101301950.10UJoWeA456408@darkstar.fourwinds.com> Message-ID: 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: References: <202101301950.10UJoWeA456408@darkstar.fourwinds.com> Message-ID: 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 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 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 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: 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: References: Message-ID: 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: References: <202101301950.10UJoWeA456408@darkstar.fourwinds.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: References: <202101301950.10UJoWeA456408@darkstar.fourwinds.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: References: 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: <20210130223154.GP4227@mcvoy.com> Message-ID: On Sat, Jan 30, 2021 at 3:32 PM Larry McVoy 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: 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: References: <202101301950.10UJoWeA456408@darkstar.fourwinds.com> Message-ID: On Sat, Jan 30, 2021 at 4:29 PM Clem Cole 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 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: 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: <202101301950.10UJoWeA456408@darkstar.fourwinds.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: 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: <202101301950.10UJoWeA456408@darkstar.fourwinds.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: References: <20210124183653.GD21030@mcvoy.com> <202101242045.10OKjDvA964774@darkstar.fourwinds.com> <20210124211100.GI21030@mcvoy.com> <202101242114.10OLEYGk966708@darkstar.fourwinds.com> <20210124212525.GJ21030@mcvoy.com> <202101242333.10ONXjcI974038@darkstar.fourwinds.com> <202101250021.10P0L3Z2976588@darkstar.fourwinds.com> <6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org> Message-ID: 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 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: 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: <202101301950.10UJoWeA456408@darkstar.fourwinds.com> <20210130222854.GN4227@mcvoy.com> <20210130231119.GA33905@eureka.lemis.com> <20210130231750.GQ4227@mcvoy.com> Message-ID: On Sat, Jan 30, 2021 at 4:19 PM Larry McVoy 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: 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: References: <202101301950.10UJoWeA456408@darkstar.fourwinds.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: References: <202101301950.10UJoWeA456408@darkstar.fourwinds.com> <20210130222854.GN4227@mcvoy.com> <20210130231119.GA33905@eureka.lemis.com> <20210130231750.GQ4227@mcvoy.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 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: <202101301950.10UJoWeA456408@darkstar.fourwinds.com> <20210130222854.GN4227@mcvoy.com> <20210130231119.GA33905@eureka.lemis.com> <20210130231750.GQ4227@mcvoy.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: <202101301950.10UJoWeA456408@darkstar.fourwinds.com> <20210130222854.GN4227@mcvoy.com> <20210130231119.GA33905@eureka.lemis.com> <20210130231750.GQ4227@mcvoy.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: <202101301950.10UJoWeA456408@darkstar.fourwinds.com> <20210130222854.GN4227@mcvoy.com> <20210130231119.GA33905@eureka.lemis.com> <20210130231750.GQ4227@mcvoy.com> <20210130233117.GR4568@mcvoy.com> <202101302337.10UNbTMU465941@darkstar.fourwinds.com> Message-ID: On Jan 30, 2021, at 3:37 PM, 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 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: <202101301950.10UJoWeA456408@darkstar.fourwinds.com> <20210130222854.GN4227@mcvoy.com> <20210130231119.GA33905@eureka.lemis.com> Message-ID: 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: <202101301950.10UJoWeA456408@darkstar.fourwinds.com> <20210130222854.GN4227@mcvoy.com> <20210130231119.GA33905@eureka.lemis.com> Message-ID: 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 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: References: <202101301950.10UJoWeA456408@darkstar.fourwinds.com> <20210130222854.GN4227@mcvoy.com> <20210130231119.GA33905@eureka.lemis.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 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: <20210124183653.GD21030@mcvoy.com> <202101242045.10OKjDvA964774@darkstar.fourwinds.com> <20210124211100.GI21030@mcvoy.com> <202101242114.10OLEYGk966708@darkstar.fourwinds.com> <20210124212525.GJ21030@mcvoy.com> <202101242333.10ONXjcI974038@darkstar.fourwinds.com> <202101250021.10P0L3Z2976588@darkstar.fourwinds.com> <6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org> <6014BB72.204@gmail.com> Message-ID: 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: <202101301950.10UJoWeA456408@darkstar.fourwinds.com> <20210130222854.GN4227@mcvoy.com> <20210130231119.GA33905@eureka.lemis.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 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 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: <202101301950.10UJoWeA456408@darkstar.fourwinds.com> <20210130222854.GN4227@mcvoy.com> <20210130231119.GA33905@eureka.lemis.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 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 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: <202101301950.10UJoWeA456408@darkstar.fourwinds.com> <20210130222854.GN4227@mcvoy.com> <20210130231119.GA33905@eureka.lemis.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 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 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 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: 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: <202101301950.10UJoWeA456408@darkstar.fourwinds.com> <20210130222854.GN4227@mcvoy.com> <20210130231119.GA33905@eureka.lemis.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: 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 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 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 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 > 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: 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: References: Message-ID: 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: 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: References: 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: 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: References: 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: <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: References: Message-ID: <202101310757.10V7v3Tv004164@freefriends.org> "Ronald Natalie" 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: <316d3fab-cf62-2d2e-f721-f4398acffc06@bitsavers.org> <7wh7mxpp4q.fsf@junk.nocrew.org> Message-ID: 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 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: 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: <202101310757.10V7v3Tv004164@freefriends.org> Message-ID: > 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: References: <316d3fab-cf62-2d2e-f721-f4398acffc06@bitsavers.org> <7wh7mxpp4q.fsf@junk.nocrew.org> Message-ID: <00F0758C-2E99-43C9-A989-1BD977248839@xs4all.nl> > On Jan 31, 2021, at 9:29, Rob Pike 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: Message signed with OpenPGP URL: From 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: <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 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: <202101301950.10UJoWeA456408@darkstar.fourwinds.com> <20210130222854.GN4227@mcvoy.com> <20210130231119.GA33905@eureka.lemis.com> <20210130231750.GQ4227@mcvoy.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