From will.senn at gmail.com Fri Mar 5 02:52:30 2021 From: will.senn at gmail.com (Will Senn) Date: Thu, 4 Mar 2021 10:52:30 -0600 Subject: [TUHS] tabs vs spaces - entab, detab Message-ID: OK. So, I've been trying to decide (for the last time, I swear) whether to use tabs or spaces in my code... I did a quick pulse-check on the state of argument and it appears to be alive and well in 2021. My question for y'all is, was there a preference in the very early days or not? I saw an article talking about the 20 year feud, but that's not my recollection. In 1994, nobody agreed on this, but I'm sure it predates my entree into the field. I'm thinking the history of entab and detab are somehow related, but I've been wrong on these sorts of thoughts before. What say you? Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Fri Mar 5 02:59:56 2021 From: clemc at ccc.com (Clem Cole) Date: Thu, 4 Mar 2021 11:59:56 -0500 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: Message-ID: Oh boy, you do want to pour muddy water on the table. I generally believed in tabs set every 4 spaces. That's Steven's used in all his UNIX books. Have to ask Rob what and bwk used but I sort of think it was pretty similar. A problem is a lot of people had tabs set at 8 spaces. Clem ᐧ On Thu, Mar 4, 2021 at 11:53 AM Will Senn wrote: > OK. So, I've been trying to decide (for the last time, I swear) whether to > use tabs or spaces in my code... I did a quick pulse-check on the state of > argument and it appears to be alive and well in 2021. My question for y'all > is, was there a preference in the very early days or not? I saw an article > talking about the 20 year feud, but that's not my recollection. In 1994, > nobody agreed on this, but I'm sure it predates my entree into the field. > I'm thinking the history of entab and detab are somehow related, but I've > been wrong on these sorts of thoughts before. What say you? > > Will > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Fri Mar 5 04:31:35 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 04 Mar 2021 11:31:35 -0700 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: Message-ID: <202103041831.124IVZTj018003@freefriends.org> First, no discussion of this issue would be complete without this video: https://www.youtube.com/watch?v=SsoOG6ZeyUI Secondly, there are two issues, only partially related. 1. Do I use real tab characters in my code, or just spaces? 2. How many spaces do I want my editor/IDE to use to (a) display tab characters or (b) expand tabs into, depending upon my answer to (1) above? All *nix systems use a "tab stop" of eight characters when printing tab characters on a terminal or a line printer. That is pretty hard to change. Traditionalists (or at least, I, speaking for myself) use tabs in their C, C++, and shell code and *must* use tabs in their Makefiles. Doing so "saved bytes" on the small machines of yesteryear; that argument is irrelevant today. I got used to a tab stop of 8 characters for most code and that's still my personal preference for the C, C++, awk and shell that I write. The Python world is different; there the use of spaces and a tab stop of 4 characters is common. Fortunately, modern editors / IDEs let you choose the settings to use based on the language you're editing. I've used a tab stop of 4 spaces for C++ as well and I find that readable and pleasant. I find anything less than that to be cramped and unpleasant. I don't remember the details of entab and detab programs on Unix (other than the expand command) but "Software Tools" from 1976 had programs to do those exact two jobs, so the issue of going back and forth between spaces and tabs has been around for a long time. The short answer is that what you should do boils down to your preference(s) and the tools you use to edit code. HTH, Arnold Clem Cole wrote: > Oh boy, you do want to pour muddy water on the table. I generally > believed in tabs set every 4 spaces. That's Steven's used in all his UNIX > books. Have to ask Rob what and bwk used but I sort of think it was pretty > similar. A problem is a lot of people had tabs set at 8 spaces. > > Clem > ᐧ > > On Thu, Mar 4, 2021 at 11:53 AM Will Senn wrote: > > > OK. So, I've been trying to decide (for the last time, I swear) whether to > > use tabs or spaces in my code... I did a quick pulse-check on the state of > > argument and it appears to be alive and well in 2021. My question for y'all > > is, was there a preference in the very early days or not? I saw an article > > talking about the 20 year feud, but that's not my recollection. In 1994, > > nobody agreed on this, but I'm sure it predates my entree into the field. > > I'm thinking the history of entab and detab are somehow related, but I've > > been wrong on these sorts of thoughts before. What say you? > > > > Will > > From jpl.jpl at gmail.com Fri Mar 5 04:33:25 2021 From: jpl.jpl at gmail.com (John P. Linderman) Date: Thu, 4 Mar 2021 13:33:25 -0500 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: Message-ID: In my first days as a UNIX user (mid 70's), operating at 110 baud, mechanical tabs were much faster than multiple spaces. And with now-laughably small disks, saving space in files was a consideration, too. Neither should matter now, but early training can be difficult to overcome. I find it easier to read code when statements aren't split across multiple lines (and therefore sometimes across pages). So I'm now inclined to favor smaller tab-stops. On Thu, Mar 4, 2021 at 11:53 AM Will Senn wrote: > OK. So, I've been trying to decide (for the last time, I swear) whether to > use tabs or spaces in my code... I did a quick pulse-check on the state of > argument and it appears to be alive and well in 2021. My question for y'all > is, was there a preference in the very early days or not? I saw an article > talking about the 20 year feud, but that's not my recollection. In 1994, > nobody agreed on this, but I'm sure it predates my entree into the field. > I'm thinking the history of entab and detab are somehow related, but I've > been wrong on these sorts of thoughts before. What say you? > > Will > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emu at e-bbes.com Fri Mar 5 04:48:08 2021 From: emu at e-bbes.com (emanuel stiebler) Date: Thu, 4 Mar 2021 13:48:08 -0500 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: Message-ID: On 2021-03-04 11:59, Clem Cole wrote: > Oh boy, you do want to pour muddy water on the table.   I generally > believed in tabs set every 4 spaces.  That's Steven's used in all his > UNIX books.  Have to ask Rob what and bwk used but I sort of think it > was pretty similar.  A problem is a lot of people had tabs set at 8 > spaces.   Does it help, if we differentiate with the type of text ? Assembler : Tabs = 8 spaces (c, c++, pascal, java, etc.) : tabs = 4 spaces ;-) From cym224 at gmail.com Fri Mar 5 05:23:18 2021 From: cym224 at gmail.com (Nemo Nusquam) Date: Thu, 04 Mar 2021 14:23:18 -0500 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: <202103041831.124IVZTj018003@freefriends.org> References: <202103041831.124IVZTj018003@freefriends.org> Message-ID: <604133A6.8070101@gmail.com> On 04/03/2021 13:31, arnold at skeeve.com wrote (in part): > Traditionalists (or at least, I, speaking for myself) use tabs in > their C, C++, and shell code and *must* use tabs in their Makefiles. Yes in Makefiles, otherwise I prefer 4 spaces per stop. > The Python world is different; there the use of spaces and a tab stop > of 4 characters is common. I recall two colleagues working on the same Python-based project. One used a 3-column tab; the other used 8-column spaces. Few fireworks as the other simply filtered. > I don't remember the details of entab and detab programs on Unix > (other than the expand command) This begs a question from me. My Solaris boxes have expand/unexpand but no entab/detab. What is the history there? N. From usotsuki at buric.co Fri Mar 5 05:37:14 2021 From: usotsuki at buric.co (Steve Nickolas) Date: Thu, 4 Mar 2021 14:37:14 -0500 (EST) Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: <604133A6.8070101@gmail.com> References: <202103041831.124IVZTj018003@freefriends.org> <604133A6.8070101@gmail.com> Message-ID: On Thu, 4 Mar 2021, Nemo Nusquam wrote: > On 04/03/2021 13:31, arnold at skeeve.com wrote (in part): >> Traditionalists (or at least, I, speaking for myself) use tabs in >> their C, C++, and shell code and *must* use tabs in their Makefiles. > Yes in Makefiles, otherwise I prefer 4 spaces per stop. > >> The Python world is different; there the use of spaces and a tab stop >> of 4 characters is common. > I recall two colleagues working on the same Python-based project. One used a > 3-column tab; the other used 8-column spaces. Few fireworks as the other > simply filtered. For what it's worth, I tend to use space-tabbing, indent of 1 for C, indent of 10 for assembler (I do some stuff in 65C02 assembler). -uso. From robpike at gmail.com Fri Mar 5 05:50:08 2021 From: robpike at gmail.com (Rob Pike) Date: Fri, 5 Mar 2021 06:50:08 +1100 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: <202103041831.124IVZTj018003@freefriends.org> <604133A6.8070101@gmail.com> Message-ID: https://www.youtube.com/watch?v=sln-gJaURzk&feature=player_detailpage#t=1734s&utm_source=buffer&buffer_share=c7676 -------------- next part -------------- An HTML attachment was scrubbed... URL: From grog at lemis.com Fri Mar 5 07:24:59 2021 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Fri, 5 Mar 2021 08:24:59 +1100 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: Message-ID: <20210304212459.GA6303@eureka.lemis.com> On Thursday, 4 March 2021 at 10:52:30 -0600, Will Senn wrote: > OK. So, I've been trying to decide (for the last time, I swear) whether > to use tabs or spaces in my code... I did a quick pulse-check on the > state of argument and it appears to be alive and well in 2021. FWIW, FreeBSD's style(9) man page (https://www.freebsd.org/cgi/man.cgi?query=style&apropos=0&sektion=9&manpath=FreeBSD+12.2-RELEASE+and+Ports&arch=default&format=html) includes: Indentation is an 8 character tab. Second level indents are four spaces. I've always used 8 character tabs (though in my own code I don't stick to style(9)). As others have commented, it's the Unix standard, and the confusion between tabs and spaces is bad enough without changing the relationship. 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 will.senn at gmail.com Fri Mar 5 07:25:35 2021 From: will.senn at gmail.com (Will Senn) Date: Thu, 4 Mar 2021 15:25:35 -0600 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: <202103041831.124IVZTj018003@freefriends.org> <604133A6.8070101@gmail.com> Message-ID: On 3/4/21 1:50 PM, Rob Pike wrote: > https://www.youtube.com/watch?v=sln-gJaURzk&feature=player_detailpage#t=1734s&utm_source=buffer&buffer_share=c7676 > > > > Thanks for the link into the video. If only every language were as helpful on the formatting code front :). I work with random folks who have differing opinions on the subject - this becomes apparent as soon as we try to integrate, with the notorious "inconsistent use of tabs and spaces in indentation" error. Python drives me nuts with it's finickiness on this, all without providing a helpful way to resolve the issue. It's left up to the developer to fix. Go addresses this by normalizing the format. It's not just Python, I'm currently reading a C17 C++ book, at the moment, and the authors spend several pages on coding style. They eventually boil it down to "whatever you do, be consistent" - but the amount of time spent on this shows us why go's approach is vastly superior. No raging debate about braces on the same line or even tabs and spaces - just code it, let go sort out the style issues. Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Fri Mar 5 07:27:27 2021 From: will.senn at gmail.com (Will Senn) Date: Thu, 4 Mar 2021 15:27:27 -0600 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: <20210304212459.GA6303@eureka.lemis.com> References: <20210304212459.GA6303@eureka.lemis.com> Message-ID: On 3/4/21 3:24 PM, Greg 'groggy' Lehey wrote: > FWIW, FreeBSD's style(9) man page > (https://www.freebsd.org/cgi/man.cgi?query=style&apropos=0&sektion=9&manpath=FreeBSD+12.2-RELEASE+and+Ports&arch=default&format=html) > includes: > > Indentation is an 8 character tab. Second level indents are four > spaces. > > I've always used 8 character tabs (though in my own code I don't stick > to style(9)). As others have commented, it's the Unix standard, and > the confusion between tabs and spaces is bad enough without changing > the relationship. > > Greg Wow, mixed tabs and spaces? On purpose? That's nuts :). From grog at lemis.com Fri Mar 5 07:29:17 2021 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Fri, 5 Mar 2021 08:29:17 +1100 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: <20210304212459.GA6303@eureka.lemis.com> Message-ID: <20210304212917.GB6303@eureka.lemis.com> On Thursday, 4 March 2021 at 15:27:27 -0600, Will Senn wrote: > On 3/4/21 3:24 PM, Greg 'groggy' Lehey wrote: >> FWIW, FreeBSD's style(9) man page >> (https://www.freebsd.org/cgi/man.cgi?query=style&apropos=0&sektion=9&manpath=FreeBSD+12.2-RELEASE+and+Ports&arch=default&format=html) >> includes: >> >> Indentation is an 8 character tab. Second level indents are four >> spaces. >> >> I've always used 8 character tabs (though in my own code I don't stick >> to style(9)). As others have commented, it's the Unix standard, and >> the confusion between tabs and spaces is bad enough without changing >> the relationship. > > Wow, mixed tabs and spaces? On purpose? That's nuts :). FWIW, I do this in my own code too. Once you know about it, it's not an issue. It helps to have an editor that highlights tab characters. 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 will.senn at gmail.com Fri Mar 5 07:42:38 2021 From: will.senn at gmail.com (Will Senn) Date: Thu, 4 Mar 2021 15:42:38 -0600 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: <20210304212917.GB6303@eureka.lemis.com> References: <20210304212459.GA6303@eureka.lemis.com> <20210304212917.GB6303@eureka.lemis.com> Message-ID: <1B118B2A-F22E-4A0E-9982-EDCCA74C33CF@gmail.com> Sent from my iPhone > On Mar 4, 2021, at 3:29 PM, Greg 'groggy' Lehey wrote: > >> On Thursday, 4 March 2021 at 15:27:27 -0600, Will Senn wrote: >>> On 3/4/21 3:24 PM, Greg 'groggy' Lehey wrote: >>> FWIW, FreeBSD's style(9) man page >>> (https://www.freebsd.org/cgi/man.cgi?query=style&apropos=0&sektion=9&manpath=FreeBSD+12.2-RELEASE+and+Ports&arch=default&format=html) >>> includes: >>> >>> Indentation is an 8 character tab. Second level indents are four >>> spaces. >>> >>> I've always used 8 character tabs (though in my own code I don't stick >>> to style(9)). As others have commented, it's the Unix standard, and >>> the confusion between tabs and spaces is bad enough without changing >>> the relationship. >> >> Wow, mixed tabs and spaces? On purpose? That's nuts :). > > FWIW, I do this in my own code too. Once you know about it, it's not > an issue. It helps to have an editor that highlights tab characters. > > Greg > -- > There’s a thought, highlight the pesky things. I usually hunt for them after they become an issue, but turning on a highlight is way better than my editor’s “show invisibles” function that puts a funky dash where tabs are... not invisible, just obfuscated. From fuz at fuz.su Fri Mar 5 07:20:13 2021 From: fuz at fuz.su (Robert Clausecker) Date: Thu, 4 Mar 2021 22:20:13 +0100 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: <202103041831.124IVZTj018003@freefriends.org> <604133A6.8070101@gmail.com> Message-ID: Am Fri, Mar 05, 2021 at 06:50:08AM +1100 schrieb Rob Pike: > https://www.youtube.com/watch?v=sln-gJaURzk&feature=player_detailpage#t=1734s&utm_source=buffer&buffer_share=c7676 Is it true that you started the Go project so you would be allowed to indent your code with tabs at Google? Yours, Robert Clausecker -- () ascii ribbon campaign - for an 8-bit clean world /\ - against html email - against proprietary attachments From jpl.jpl at gmail.com Fri Mar 5 07:48:36 2021 From: jpl.jpl at gmail.com (John P. Linderman) Date: Thu, 4 Mar 2021 16:48:36 -0500 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: <20210304212917.GB6303@eureka.lemis.com> References: <20210304212459.GA6303@eureka.lemis.com> <20210304212917.GB6303@eureka.lemis.com> Message-ID: Appropos my "laughably small" disk space comment, here's a snippet from mkfs.ext4: -m reserved-blocks-percentage Specify the percentage of the filesystem blocks reserved for the super-user. This avoids fragmentation, and allows root-owned daemons, such as syslogd(8), to continue to function correctly after non-privileged processes are prevented from writing to the filesystem. The default percentage is 5%. I have several 12 TB disks scattered about my house. 5% of 12TB is 600GB. I'm pretty confident that all the spinning (no, tapes aren't spinning) storage at all of Bell Labs in 1975 was less than the reserved space for one of my disks. FWIW, I set "-m 0" for honker disks. -- jpl -------------- next part -------------- An HTML attachment was scrubbed... URL: From akosela at andykosela.com Fri Mar 5 08:08:53 2021 From: akosela at andykosela.com (Andy Kosela) Date: Thu, 4 Mar 2021 23:08:53 +0100 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: <20210304212459.GA6303@eureka.lemis.com> <20210304212917.GB6303@eureka.lemis.com> Message-ID: I am still computing in full screen text mode on CRT monitors, so it's 80 columns and 8 character tab as indentation for me. It is a golden standard. >From Linux kernel coding style doc: "Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3." --Andy From woods at robohack.ca Fri Mar 5 08:10:20 2021 From: woods at robohack.ca (Greg A. Woods) Date: Thu, 04 Mar 2021 14:10:20 -0800 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: <20210304212459.GA6303@eureka.lemis.com> Message-ID: At Thu, 4 Mar 2021 15:27:27 -0600, Will Senn wrote: Subject: Re: [TUHS] tabs vs spaces - entab, detab > > Wow, mixed tabs and spaces? On purpose? That's nuts :). In code tabs are for indentation -- one tab per level of indentation. In code spaces are for alignment -- e.g. to align comments at the end of the line use spaces between the end of the code and the beginning of the comment. (for those of us who use emacs there's smart-tabs-mode -- it's not perfect, but it helps get these things right the first time around, i.e. when you don't have "go fmt") -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms From grog at lemis.com Fri Mar 5 08:12:50 2021 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Fri, 5 Mar 2021 09:12:50 +1100 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: <20210304212459.GA6303@eureka.lemis.com> <20210304212917.GB6303@eureka.lemis.com> Message-ID: <20210304221250.GD6303@eureka.lemis.com> On Thursday, 4 March 2021 at 23:08:53 +0100, Andy Kosela wrote: > > From Linux kernel coding style doc: > "Tabs are 8 characters, and thus indentations are also 8 characters. > There are heretic movements that try to make indentations 4 (or even > 2!) characters deep, and that is akin to trying to define the value of > PI to be 3." :-) 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 jon at fourwinds.com Fri Mar 5 10:15:16 2021 From: jon at fourwinds.com (Jon Steinhart) Date: Thu, 04 Mar 2021 16:15:16 -0800 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: <20210304212459.GA6303@eureka.lemis.com> <20210304212917.GB6303@eureka.lemis.com> Message-ID: <202103050015.1250FG1d053755@darkstar.fourwinds.com> Andy Kosela writes: > I am still computing in full screen text mode on CRT monitors, so it's > 80 columns and 8 character tab as indentation for me. It is a golden > standard. > > >From Linux kernel coding style doc: > "Tabs are 8 characters, and thus indentations are also 8 characters. > There are heretic movements that try to make indentations 4 (or even > 2!) characters deep, and that is akin to trying to define the value of > PI to be 3." > > --Andy Well, I suppose that I have to weigh in here before this discussion gets shut down. First of all, it's a shame that there isn't a nice global way to set system tab stops. I have a lot of aliases that pipe through "expand -t 4". Second, while I agree with about 90% of the linux kernel coding style the indent and line length parts are in the other 10%. And from looking at kernel code, while many may agree with the style doc they don't actually follow it so I'm not sure what agreement means. I always thought that the 80 character line length limit (now an amazing 100) was silly; nobody was using VT-100s by the time that linux was developed. Most developers were born after the last one was relegated to a museum somewhere. In that timeframe I had changed to using 132 column; I would have gone to 160 but not everybody that I worked with thought that it was worth whatever it took to have a great monitor. I have UHD on both my desktop and laptop which allows a pair of nicely readable 132 column windows with room left over. No longer much of a cost barrier. The big problem that I have with the linux style is that in addition to the tab stop and line length restrictions, there is the weird belief that one is doing something wrong if more than three levels of indent are needed. From what I have seen, this is followed by unnecessarily breaking up functions combined with zillions of macros and static inline functions in header files to give the appearance of only three levels of indent. Bottom line to me is that it makes the code unreadable, and if I have to choose an ideology it's making the code easy to read for someone who didn't write it, not some slavish adherence to a rule that doesn't make a lot of sense to me. I think that line breaks hurt readability as they make it harder to mentally process the block structure of code in pre-attentive mode. I used to have 8 character tab stops and short (traditional one character) variable names; now I've moved to 4 character tab stops and more readable variable names. When I do need to break a long line, I indent the continuation line(s) one character from the starting line to preserve the block structure appearance as much as possible. No additional indent makes it hard to distinguish separate statements, two character indent makes it hard to tell which level the line belongs to since it's halfway between two levels. I do use tabs, not spaces. Main reason, going back decades, is that I can find a statement by searching for "^Ifor" which is distinct from any other use of for. For the same reason, I put function definitions in column 1 with the type on the line above, so that I can easily search for "^foo" which is distinct from any invocations. Anyway, whether or not you agree with this it works for me; my goal is to make my code comprehensible by people who aren't as smart as I am because I want to move on, not maintain stuff. Jon From cowan at ccil.org Fri Mar 5 10:44:12 2021 From: cowan at ccil.org (John Cowan) Date: Thu, 4 Mar 2021 19:44:12 -0500 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: Message-ID: On Thu, Mar 4, 2021 at 2:10 PM emanuel stiebler wrote: Does it help, if we differentiate with the type of text ? > > Assembler : Tabs = 8 spaces > (c, c++, pascal, java, etc.) : tabs = 4 spaces > The Lisp community long ago standardized on 2-space indentation. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org Income tax, if I may be pardoned for saying so, is a tax on income. --Lord Macnaghten (1901) -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Fri Mar 5 10:55:31 2021 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 4 Mar 2021 16:55:31 -0800 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: Message-ID: <20210305005531.GA30608@mcvoy.com> On Thu, Mar 04, 2021 at 07:44:12PM -0500, John Cowan wrote: > On Thu, Mar 4, 2021 at 2:10 PM emanuel stiebler wrote: > > Does it help, if we differentiate with the type of text ? > > > > Assembler : Tabs = 8 spaces > > (c, c++, pascal, java, etc.) : tabs = 4 spaces > > > > The Lisp community long ago standardized on 2-space indentation. I used to be a 4 spaces are tabs guy but Sun beat that out of me. Tabs are tabs and they are for a reason, though that reason is pretty dead. The reason was pretty printing listings, anything but tabs got all screwed up. But it has probably been a decade or more since I've pretty printed anything, maybe two. Old habits... I developed my own use of 4 spaces, those are "continuation lines" if (some_stupidly_long_expression_that_goes_on_forever >= this_never_happens_but_it_does_happen_when_deeply_nested) { statement; statement2; etc; } But I'm weird, I hate if (expr) statement; I do if (expr) statement; Curly braces are for more than one statement or I do do if (expr) { statement; } else { statement2; } I also like perl so I do #define unless(x) if (!(x)) because I think this reads better: FILE *f; unless (f = fopen(argv[1], "r")) { perror(argv[1]); exit(1); } From ggm at algebras.org Fri Mar 5 11:09:16 2021 From: ggm at algebras.org (George Michaelson) Date: Fri, 5 Mar 2021 11:09:16 +1000 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: <20210305005531.GA30608@mcvoy.com> References: <20210305005531.GA30608@mcvoy.com> Message-ID: I use them incoherently, depending on context, time, and adherence to something approximating to xNF for some X, normal-form. Other peoples rules. What I found interesting, is the divergence in strategy in managing. strategy a: I shall show these as if they were 8 space indents. You maybe can change this. Its columns on the screen. strategy b: I shall, in a fit of lunacy, actually change these to align to the 8 space indent column implications. your source is now different strategy c: You ran some tool like tr over these, and now, Its your fault not mine. Good luck. I usually wound up in strategy c but some editors of the day did strategy b. I harbour a belief, this amongst other things, is why patch -l was invented. I know its heresy to contradict wiser people, but I think the number of circumstances where space/tab actually did affect baud- or data- rate was minimal. It was an effect more apparent and believed than real. Sure, if you used an ASR33 the head positioning was better. That experience set against being in a Vt52 or ADM5 world, by the time you were in a vdu display of 80x24 I think it was gone. I never consciously thought about it and I used both. It wasn't very material for the circumstances but I wasn't trying to cram source into a 2k memory to put into a rocket or a telephone switch or anything. It's a bit like steam-engine enthusiasts arguing about boiler tube design: most shunters don't care. People mostly hated me mucking around with their code. I can't blame them. It would be horrid to live in a really nicely laid out world in either tab or space-land and have a hooligan come and scribble over your art with a texta. Aside from simply coding bad answers to problems, I do note that sending people who demanded KNF non-KNF formatted code usually led to rapid rejection. The US is a place where people still use fixed-width fonts and specific spacing to file paper on the law courts, although I note Sydney Powell didn't bother spell checking before she sent in the incredibly weird conforming style of text. I should complain: the IETF idnit checker is feral. -G On Fri, Mar 5, 2021 at 10:55 AM Larry McVoy wrote: > > On Thu, Mar 04, 2021 at 07:44:12PM -0500, John Cowan wrote: > > On Thu, Mar 4, 2021 at 2:10 PM emanuel stiebler wrote: > > > > Does it help, if we differentiate with the type of text ? > > > > > > Assembler : Tabs = 8 spaces > > > (c, c++, pascal, java, etc.) : tabs = 4 spaces > > > > > > > The Lisp community long ago standardized on 2-space indentation. > > I used to be a 4 spaces are tabs guy but Sun beat that out of me. > Tabs are tabs and they are for a reason, though that reason is pretty > dead. The reason was pretty printing listings, anything but tabs got > all screwed up. But it has probably been a decade or more since I've > pretty printed anything, maybe two. Old habits... > > I developed my own use of 4 spaces, those are "continuation lines" > > if (some_stupidly_long_expression_that_goes_on_forever >= > this_never_happens_but_it_does_happen_when_deeply_nested) { > statement; > statement2; > etc; > } > > But I'm weird, I hate > > if (expr) > statement; > > I do > > if (expr) statement; > > Curly braces are for more than one statement or I do do > > if (expr) { > statement; > } else { > statement2; > } > > I also like perl so I do > > #define unless(x) if (!(x)) > > because I think this reads better: > > FILE *f; > > unless (f = fopen(argv[1], "r")) { > perror(argv[1]); > exit(1); > } From lm at mcvoy.com Fri Mar 5 11:21:07 2021 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 4 Mar 2021 17:21:07 -0800 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: <20210305005531.GA30608@mcvoy.com> Message-ID: <20210305012107.GB30608@mcvoy.com> On Fri, Mar 05, 2021 at 11:09:16AM +1000, George Michaelson wrote: > People mostly hated me mucking around with their code. I can't blame > them. It would be horrid to live in a really nicely laid out world in > either tab or space-land and have a hooligan come and scribble over > your art with a texta. I'm with ya there. I *hate* GNU coding style, just hate it. But when I submit a patch, it is in whatever style the code had. I've run into people that don't do that, and in 95% or more of the cases, their patches don't get in. If they are important, the maintainer applys the patch, fixes the style, and then commits. My opinion does not trump the source base. Source base wins. It's just being polite. From rich.salz at gmail.com Fri Mar 5 11:29:35 2021 From: rich.salz at gmail.com (Richard Salz) Date: Thu, 4 Mar 2021 20:29:35 -0500 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: <20210305012107.GB30608@mcvoy.com> References: <20210305005531.GA30608@mcvoy.com> <20210305012107.GB30608@mcvoy.com> Message-ID: > > My opinion does not trump the source base. Source base wins. It's just > being polite. > Preach! -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan at alanlee.org Fri Mar 5 11:41:45 2021 From: alan at alanlee.org (alan at alanlee.org) Date: Thu, 04 Mar 2021 20:41:45 -0500 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: Message-ID: Easy. Tabs for scope, spaces for everything else - with the later kept to a minimum. That eliminates the spaces per tab part of the discussion. For example if a printf is nested in scope, all lines of the same scope should have the same number of tabs per line. The continuation of text for printf arguments on a second line should have the same number of leading tabs as the printf - then spaces to align the second line where you want it. There should never be any tabs past the initial run at the start of the line. No exceptions! Anyone using spaces to align anything else in the code should be drug in front of a firing line and shot. Anyone using ****** ###### /////// or any other runs of characters in code should be drug in front of a firing line and shot. My $.02 -A On 2021-03-04 11:52, Will Senn wrote: > OK. So, I've been trying to decide (for the last time, I swear) whether to use tabs or spaces in my code... I did a quick pulse-check on the state of argument and it appears to be alive and well in 2021. My question for y'all is, was there a preference in the very early days or not? I saw an article talking about the 20 year feud, but that's not my recollection. In 1994, nobody agreed on this, but I'm sure it predates my entree into the field. I'm thinking the history of entab and detab are somehow related, but I've been wrong on these sorts of thoughts before. What say you? > > Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan at alanlee.org Fri Mar 5 11:55:15 2021 From: alan at alanlee.org (alan at alanlee.org) Date: Thu, 04 Mar 2021 20:55:15 -0500 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: Message-ID: Of course the sequel to this thread will be to camelCase or not to camel_case. Or maybe whether to prefix functions and variable with a type abbreviation like siCounter for a signed integer counter as if 99% of people in 2021 are not using an editor that allows quick inspection of variables and functions. Maybe we can get to the third act of how to align braces and parens! brb, getting some peanuts, popcorn, and a comfortable seat! -A P.S. In all seriousness, keep it civil! :) On 2021-03-04 11:52, Will Senn wrote: > OK. So, I've been trying to decide (for the last time, I swear) whether to use tabs or spaces in my code... I did a quick pulse-check on the state of argument and it appears to be alive and well in 2021. My question for y'all is, was there a preference in the very early days or not? I saw an article talking about the 20 year feud, but that's not my recollection. In 1994, nobody agreed on this, but I'm sure it predates my entree into the field. I'm thinking the history of entab and detab are somehow related, but I've been wrong on these sorts of thoughts before. What say you? > > Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Fri Mar 5 12:06:40 2021 From: will.senn at gmail.com (Will Senn) Date: Thu, 4 Mar 2021 20:06:40 -0600 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: Message-ID: <57A1A023-7E73-4233-8FF2-CED5EB1CDB7C@gmail.com> Ha. I didn’t intend to reignite a flamewar. I was asking about the history. I got that and more :). But, i’m still curious about entab/detab abd expand, etc. Were they oor some of them created to help with this or what? Will Sent from my iPhone > On Mar 4, 2021, at 7:55 PM, alan at alanlee.org wrote: > > Of course the sequel to this thread will be to camelCase or not to camel_case. Or maybe whether to prefix functions and variable with a type abbreviation like siCounter for a signed integer counter as if 99% of people in 2021 are not using an editor that allows quick inspection of variables and functions. Maybe we can get to the third act of how to align braces and parens! > > brb, getting some peanuts, popcorn, and a comfortable seat! > > -A > > P.S. In all seriousness, keep it civil! :) > >> On 2021-03-04 11:52, Will Senn wrote: >> >> OK. So, I've been trying to decide (for the last time, I swear) whether to use tabs or spaces in my code... I did a quick pulse-check on the state of argument and it appears to be alive and well in 2021. My question for y'all is, was there a preference in the very early days or not? I saw an article talking about the 20 year feud, but that's not my recollection. In 1994, nobody agreed on this, but I'm sure it predates my entree into the field. I'm thinking the history of entab and detab are somehow related, but I've been wrong on these sorts of thoughts before. What say you? >> >> Will > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnu at toad.com Fri Mar 5 19:50:32 2021 From: gnu at toad.com (John Gilmore) Date: Fri, 05 Mar 2021 01:50:32 -0800 Subject: [TUHS] tunefs -m 5% In-Reply-To: References: <20210304212459.GA6303@eureka.lemis.com> <20210304212917.GB6303@eureka.lemis.com> Message-ID: <25189.1614937832@hop.toad.com> John P. Linderman wrote: > I have several 12 TB disks scattered about my house. 5% of 12TB is 600GB. At one point in hystery, ext2 performance was reported to suffer badly if there was less than 5% of disk space available in an active filesystem. My naive belief, probably informed by older and wiser heads around Sun, was that when the file system was >95% full, ext2 spent a lot of time seeking around in free lists finding single allocatable blocks. And there were no built-in "defragmentation" programs that could easily fix that. Is that still a performance constraint in ext4, which has had a few decades to work out those edge performance issues? And if it's fixed, then to handle the "root needs lebensraum" argument, perhaps the default reserved percentage should be set to 1% (or 0.1%, which I think the tools do not currently support)? Or perhaps it should be min(1%,10GB) reserved for root, so the calculation works better on both large or small filesystems? And on file systems that aren't expected to have root logfiles and such in them, should the right default now be -m 0? How many zettabytes of storage could we make available to users in 2030, by improving this default from the 1980s now? John From gnu at toad.com Fri Mar 5 19:58:14 2021 From: gnu at toad.com (John Gilmore) Date: Fri, 05 Mar 2021 01:58:14 -0800 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: <202103041831.124IVZTj018003@freefriends.org> <604133A6.8070101@gmail.com> Message-ID: <25705.1614938294@hop.toad.com> Will Senn wrote: > the notorious "inconsistent use of tabs and > spaces in indentation" error. Python drives me nuts with it's > finickiness on this... The one that got me was make(1). Being used to text editors that used "tab" as a command rather than a literal character, I proposed a fix early on at Sun that would allow leading spaces as well as tabs in Makefiles. (I think this was in the Unisoft Unix days, pre-BSD.) Bill Shannon actually put it into their source tree. But in a few days or weeks, he took it back out, because he realized that Makefiles built on Suns using leading spaces wouldn't work anywhere else. Compatibility with the rest of the UNIX(tm) world was more important than eliminating the software's foolish distinction between two characters you can't see. John From steffen at sdaoden.eu Sat Mar 6 00:13:48 2021 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 05 Mar 2021 15:13:48 +0100 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: <20210304221250.GD6303@eureka.lemis.com> References: <20210304212459.GA6303@eureka.lemis.com> <20210304212917.GB6303@eureka.lemis.com> <20210304221250.GD6303@eureka.lemis.com> Message-ID: <20210305141348.DIpGG%steffen@sdaoden.eu> Greg 'groggy' Lehey wrote in <20210304221250.GD6303 at eureka.lemis.com>: |On Thursday, 4 March 2021 at 23:08:53 +0100, Andy Kosela wrote: |> |> From Linux kernel coding style doc: |> "Tabs are 8 characters, and thus indentations are also 8 characters. |> There are heretic movements that try to make indentations 4 (or even |> 2!) characters deep, and that is akin to trying to define the value of |> PI to be 3." | |:-) I for one happily left tabulators behind. But for make files. The reason to use tab was file size for one, and that each editor could be used interchangeably to work easily (backspace stepping a real level, for example), and the reason for tab/8 was that the files looked the same everywhere, on the printer, on the terminal via cat(1), less(1), etc., so playing with vim(1)s tabstop etc. setting was a fruitless dead-end. On the 80 columns that i use, that i happily use, i just read wireguard-tools source code (i am in the process of becoming a hundred percent Wireguard fan, someone sat down and did something really great i think) and even though it fits my screen, it is just terrible to see lines that long (the kernel code fits 80, yay, not that i understand where all the work happens), tabulators just cause crowding on the right, and then .. that cannot be right. Even though my coding style is easy not like that Linux kernel code where function call arguments are then aligned under the ( +1, which ... no! Well. I switched to spaces when working for free. :) But, not important. A real change to my coding style came when i looked around Plan9 source code, the pragmatism to simply not use spaces in language constructs aka statements at all, for example "if(a){" instead of "if(a) {" or "if (a) {", and let alone "if (a)\nALIGN{\nALIGN" and whatever else. I like that. You know, FreeBSD is thinking about using that clang format thing in commit hooks (and maybe many even use the clangd "live" ctags), and that was written in Acme or even Sam. And the manuals were great and the C dialect was, too. --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 gtaylor at tnetconsulting.net Sat Mar 6 01:01:19 2021 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Fri, 5 Mar 2021 08:01:19 -0700 Subject: [TUHS] tunefs -m 5% In-Reply-To: <25189.1614937832@hop.toad.com> References: <20210304212459.GA6303@eureka.lemis.com> <20210304212917.GB6303@eureka.lemis.com> <25189.1614937832@hop.toad.com> Message-ID: <692ad732-6abb-2035-430b-038b728f37f6@spamtrap.tnetconsulting.net> On 3/5/21 2:50 AM, John Gilmore wrote: > And there were no built-in "defragmentation" programs that could > easily fix that. Sure there are! Depending on how you look at things and if you have the file systems to do it.... The venerable trick of temporarily moving everything to another file system, thereby vacating the source file system as much as possible, before moving files back. }:-) Is it pretty? No. Is it fast? No. Does it work? It's better than nothing. -- 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 tytso at mit.edu Sat Mar 6 01:32:15 2021 From: tytso at mit.edu (Theodore Ts'o) Date: Fri, 5 Mar 2021 10:32:15 -0500 Subject: [TUHS] tunefs -m 5% In-Reply-To: <25189.1614937832@hop.toad.com> References: <20210304212459.GA6303@eureka.lemis.com> <20210304212917.GB6303@eureka.lemis.com> <25189.1614937832@hop.toad.com> Message-ID: On Fri, Mar 05, 2021 at 01:50:32AM -0800, John Gilmore wrote: > John P. Linderman wrote: > > I have several 12 TB disks scattered about my house. 5% of 12TB is 600GB. > > At one point in hystery, ext2 performance was reported to suffer badly > if there was less than 5% of disk space available in an active > filesystem. My naive belief, probably informed by older and wiser heads > around Sun, was that when the file system was >95% full, ext2 spent a > lot of time seeking around in free lists finding single allocatable > blocks. And there were no built-in "defragmentation" programs that > could easily fix that. I'll point out that BSD FFS, at least in BSD 4.3, reserves 10% of the file system for reserved blocks. The reasoning gave was the same as with ext2, which is performance suffers when the file system gets really fully. It really depends on the workload, but for the worst case workloads, I've seen performance degradations happen earlier than 90% or 95% full. Defragmentation is a hard problem, and it takes a *long* time, and or chews up a lot of write cycles on flash, persistent memory, etc. This is especially true when the file system is very full, since there is very little "swing space" available to copy data around, especially if one is striving for the perfect state (e.g., a files are contiguous, and the free space is contiguous). Defragmentation utilities was something that was only really popular on Windows systems, and in the last, oh, ten years or so, even in the Windows world defrag is not something you'll see in their disk utilities. Ext4 has a defrag program, but it's really primitive, and it only works by attempting to defrag *files*. It doesn't try to defrag *free space*, which is what you really need if you want to try to keep performance up (and have space so as to keep files defragmented). The main reason why is that no one has sponsored work in this space --- probably because it's way cheaper just to over-provision disk space. If someone wants to try to implement it, I have a rough design about how it might be done for ext4 --- but someone has to volunteer $$$ or their own personal time in order to implement it. And if it's only for yourself, it's probably cheaper just to spend a extra few bucks to buy a bigger disk. I suspect it's for similar reasons that none of the legacy Unix systems have defragmentation implemented either. It's not something which makes business case. But hey, if someone is interested in working on it, I'll give the standard open source answer --- patches gratefully accepted. I'll even give you a rough design as a starting point. (And there's no guarantee it will be a good idea for flash, given that seeks are mostly free for flash, and write cycles are a consideration, and how many people are still using HDD's today; newer operating systems, such as Fuschia, have started designing for a world where they only need to care about file systems for flash.) Cheers, - Ted From m.douglas.mcilroy at dartmouth.edu Sat Mar 6 02:44:49 2021 From: m.douglas.mcilroy at dartmouth.edu (M Douglas McIlroy) Date: Fri, 5 Mar 2021 11:44:49 -0500 Subject: [TUHS] tabs vs spaces - entab, detab Message-ID: > The reason to use tab was file size for one This is urban legend. The percentage of 512-byte blocks that tabs would save was never significant. (I agree that tabs and--especially--newlines can significantly compress fixed-field formats from punched-card tradition, but on the tiny Unix systems where tab conventions were established, big tabular files were very rare.) Tabs were a convenience for typists. Of course the tty driver could have replaced them with spaces, but that would have foreclosed important usage such as tab-separated fields and run-time-adjustable tab stops tab-separated fields. (I have run into latter-day trouble with selecting a space-substituted tab from a screen, only to discover that I was copying or searching for spaces instead of the tab.. That's not an intrinsic problem, though. Editors like sam handle it without fuss.) Doug From sj at sdf.org Sat Mar 6 02:43:41 2021 From: sj at sdf.org (Scot Jenkins) Date: Fri, 05 Mar 2021 11:43:41 -0500 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: Message-ID: <202103051643.125Ghfqr014924@sdf.org> Will Senn wrote: > OK. So, I've been trying to decide (for the last time, I swear) whether > to use tabs or spaces in my code... Personally, I prefer: * hard tabs, which display as 8 spaces * 80 column wide text windows * "if your code is marching off the right side of the screen, your logic is probably too complex". The beauty of hard tabs is that the person viewing the code can choose how to display them in their editor. If everyone indents with the Tab character, the problem goes away. SVR4 vi, BSD nvi, and vim all support the tabstop option: tabstop (ts) 8 Defines number of spaces that a [TAB] indents during editing session. (Printer still uses system tab of 8.) If you prefer 2 space indentation, in vi(1) do ":set ts=2". If you prefer 4 space indentation, in vi(1) do ":set ts=4". ... Set your preferred default in ~/.exrc, ~/.nexrc, ~/.vimrc ... set ts=N to do this automatically. I'm sure other editors have a similar setting. Using the Tab key also eliminates the issues in makefiles. scot From clemc at ccc.com Sat Mar 6 03:08:24 2021 From: clemc at ccc.com (Clem Cole) Date: Fri, 5 Mar 2021 12:08:24 -0500 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: <57A1A023-7E73-4233-8FF2-CED5EB1CDB7C@gmail.com> References: <57A1A023-7E73-4233-8FF2-CED5EB1CDB7C@gmail.com> Message-ID: On Thu, Mar 4, 2021 at 9:07 PM Will Senn wrote: > Ha. I didn’t intend to reignite a flamewar. > I warned ya ... 🤔 But, i’m still curious about entab/detab abd expand, etc. Were they oor > some of them created to help with this or what? > That's probably best for bwk, Ken, or Doug that go back to pre-UNIX times at BTL. As was pointed out, bwk had them the SW tools book, so the need/use go back pretty far. As someone else pointed out, in the days of printing terminals like the 10 cps horizontal tabs *sometimes* printed faster if they were a mechanical scheme built into the HW. On the other hand (and I don't feel like finding/looking up at an ASR 33 manual), my memory is that it did not have tabs stops and the UNIX TTY hander expanded them to spaces so even that was not going to help. Also as someone else said, in those days we had 132/133 column line printer listing - which again printed >>much<< faster than the 10 cps terminal. So the 8-space = 1 tab scheme certainly >>might<< make sense since it was enforced by the HW. Space was always an issue in the old days, but frankly; again I have no memory of thinking -- "better use tabs as it will save space in my file" or that it would process faster since few characters had to be read/written. I do remember the programs existing, but don't have any memories of ever using them. In my own case, I had been taught the golden rule of "use the style that is already in use" - which I admit, was a hard lesson when I was young I admit. But since I was working in those says supporting (assembler) code that existed, and I was very much the padawan to many great masters, I was trying to learn. At some point, I started to work with HLLS on the PDP-10, as opposed to IBM BAL and I started to But when I started to learn C, it was strange, since it forced me to accept 'one true bracing style' of the kernel/K&R even if it was different from what we had been using with BLISS/SAIL/Algol/Pascal from whence I just come. But like many people that have finished re-education camps, came to prefer and anything else ugly and difficult to read. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Sat Mar 6 03:19:59 2021 From: rich.salz at gmail.com (Richard Salz) Date: Fri, 5 Mar 2021 12:19:59 -0500 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: <57A1A023-7E73-4233-8FF2-CED5EB1CDB7C@gmail.com> Message-ID: > In my own case, I had been taught the golden rule of "use the style that > is already in use" - which I admit, was a hard lesson when I was young I > admit. > In my first Unix job (roughly 40 years ago), I read the vi reference manual and memorized the keystroke commands. And then did % cd /user/include % vi *.h to fix up all the indents and comments. Later on I graduated to learning not to do control-p on a Vax console a second time. What were your mistakes? ("Always mount a scratch monkey") In -------------- next part -------------- An HTML attachment was scrubbed... URL: From woods at robohack.ca Sat Mar 6 05:29:15 2021 From: woods at robohack.ca (Greg A. Woods) Date: Fri, 05 Mar 2021 11:29:15 -0800 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: Message-ID: At Fri, 5 Mar 2021 11:44:49 -0500, M Douglas McIlroy wrote: Subject: [TUHS] tabs vs spaces - entab, detab > > > The reason to use tab was file size for one > > This is urban legend. The percentage of 512-byte blocks that > tabs would save was never significant. Using tabs to save space was definitely more than an urban legend for some of us! (but there is a caveat below) When I started at UofCalgary we had a PDP-11/60 running 7th Edition (with about 16 terminals). It had an RX-02 mounted into the terminal room wall (the computer room was of course on the other side of the wall, with a nice big window so we could see the blinken lights (which are of course very few on an 11/60, but enough to tell when it was most busy churning the disks). Students were strongly encouraged to buy 8-1/2" disks at the books store and off-load anything they were not directly working on at any given time. (And when we upgraded to a VAX 11/780 with BSD, disk quotas were implemented as soon as possible.) Some of us found that we could fit considerably more data on those disks if we made sure we used tabs everywhere possible. We also obviously learned to have a "clean" target in our makefiles and to be sure to use it before we archived anything! However I think we were probably using tar, not a filesystem, on the floppies so that would of course have been what allowed for greater savings. I don't remember many of the details, though I do remember there was a program to reserve and "lock" the drive, and I think it changed the ownership of the device file(s) to the user requesting the reservation. As for the size of tabs, well I seem to recall students also traded tabstop setup files for various kinds of terminals so that each could see code indentations at their own preferred size. (Maybe this was done more on the Multics system though, and/or it was in the pre-Vi days when we used a custom full-screen editor called Fred.) -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms From stewart at serissa.com Sat Mar 6 05:39:21 2021 From: stewart at serissa.com (Lawrence Stewart) Date: Fri, 5 Mar 2021 14:39:21 -0500 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: <57A1A023-7E73-4233-8FF2-CED5EB1CDB7C@gmail.com> Message-ID: <8AD335D5-A948-47A7-A7D4-CF6C2AA8A20C@serissa.com> I saw the light when my team presented me with a “Larry Stewart, Code Meddler” plaque. I stopped editing other coders’ style on the spot. I might have missed the discussion, but when did indent(1) come along? The interwebs say it was in 4.1BSD. I went through a period thinking that indent with the project standard rules on checkin was a reasonable idea, but git at least doesn’t seem very friendly towards that sort of thing. Left to myself I use no tabs (except in Makefiles) and 2-space per level. I think the most important thing is to maximize the code visible per screenful. Lower indents permit longer identifiers before the dreaded line-wrapping. > On 2021, Mar 5, at 12:19 PM, Richard Salz wrote: > > > In my own case, I had been taught the golden rule of "use the style that is already in use" - which I admit, was a hard lesson when I was young I admit. > > In my first Unix job (roughly 40 years ago), I read the vi reference manual and memorized the keystroke commands. And then did > % cd /user/include > % vi *.h > to fix up all the indents and comments. > > Later on I graduated to learning not to do control-p on a Vax console a second time. > > What were your mistakes? ("Always mount a scratch monkey") > > > In -------------- next part -------------- An HTML attachment was scrubbed... URL: From halbert at halwitz.org Sat Mar 6 05:51:33 2021 From: halbert at halwitz.org (Dan Halbert) Date: Fri, 5 Mar 2021 14:51:33 -0500 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: <8AD335D5-A948-47A7-A7D4-CF6C2AA8A20C@serissa.com> References: <57A1A023-7E73-4233-8FF2-CED5EB1CDB7C@gmail.com> <8AD335D5-A948-47A7-A7D4-CF6C2AA8A20C@serissa.com> Message-ID: <8b95b1bc-0077-b99f-e764-fe9fb7057e6c@halwitz.org> On 3/5/21 2:39 PM, Lawrence Stewart wrote > I went through a period thinking that indent with the project standard > rules on checkin was a > reasonable idea, but git at least doesn’t seem very friendly towards > that sort of thing. > Check out https://pre-commit.com/, which you can use just to check to to force a transformation before commit. Dan H. From cowan at ccil.org Sat Mar 6 06:24:40 2021 From: cowan at ccil.org (John Cowan) Date: Fri, 5 Mar 2021 15:24:40 -0500 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: <20210305141348.DIpGG%steffen@sdaoden.eu> References: <20210304212459.GA6303@eureka.lemis.com> <20210304212917.GB6303@eureka.lemis.com> <20210304221250.GD6303@eureka.lemis.com> <20210305141348.DIpGG%steffen@sdaoden.eu> Message-ID: On Fri, Mar 5, 2021 at 9:14 AM Steffen Nurpmeso wrote: > But, not important. A real change to my coding style came when > i looked around Plan9 source code, the pragmatism to simply not > use spaces in language constructs aka statements at all, for > example "if(a){" instead of "if(a) {" or "if (a) {", and let alone > "if (a)\nALIGN{\nALIGN" and whatever else. > That way lies APL madness. To exemplify, Kona is an open-source interpreter for Arthur Whitney's K version 3 language, which is closely related to APL, but crams almost all of the APL operators onto single ASCII characters with massive overloading. For example, monadic ! is APL "iota", but dyadic ! is "modulo" if both arguments are numbers and "rotate" if the right argument is a number and the left argument is a vector. What any of these has to do with the rest is beyond me: I had to create a set of flash cards to help me learn them all. Well, here's a procedure definition from the Kona source, in a file helpfully named kc.c (almost all of the source files have 1-2 character names): I wds_(K*a,FILE*f,I l) { S s=0,t=0; I b=0,c=0,m=0,n=0,v=0; K z=0; PDA p=0; I o=isatty(STDIN)&&f==stdin; if(-1==(c=getline_(&s,&n,f)))GC; appender(&t,&m,s,n); while(1==(v=complete(t,m,&p,0))) { b=parsedepth(p); if(o)prompt(b+l); if(-1==(c=getline_(&s,&n,f)))GC; appender(&t,&m,s,n); } SW(v){CS(2,show(kerr("unmatched"));GC) CS(3,show(kerr("nest")); GC)} z=newK(-3,m-1); strncpy(kC(z),t,m-1); cleanup: free(s); free(t); if(p)pdafree(p); if((v||c==-1)&&z){cd(z); *a=0;} else *a=z; R v?-v:c; } // -1 EOF, -2 unmatched, -3 nest If you want that sort of thing, you can certainly have it. Note the single-space ident and the cuddled right braces. Note also the label "cleanup:"; presumably a "goto cleanup;" is hidden somewhere in the single-letter (of course) macros. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org The peculiar excellence of comedy is its excellent fooling, and Aristophanes's claim to immortality is based upon one title only: he was a master maker of comedy, he could fool excellently. Here Gilbert stands side by side with him. He, too, could write the most admirable nonsense. There has never been better fooling than his, and a comparison with him carries nothing derogatory to the great Athenian. --Edith Hamilton, The Greek Way -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Sat Mar 6 07:51:09 2021 From: bakul at iitbombay.org (Bakul Shah) Date: Fri, 5 Mar 2021 13:51:09 -0800 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: <20210304212459.GA6303@eureka.lemis.com> <20210304212917.GB6303@eureka.lemis.com> <20210304221250.GD6303@eureka.lemis.com> <20210305141348.DIpGG%steffen@sdaoden.eu> Message-ID: > On Mar 5, 2021, at 12:24 PM, John Cowan wrote: > > On Fri, Mar 5, 2021 at 9:14 AM Steffen Nurpmeso > wrote: > > But, not important. A real change to my coding style came when > i looked around Plan9 source code, the pragmatism to simply not > use spaces in language constructs aka statements at all, for > example "if(a){" instead of "if(a) {" or "if (a) {", and let alone > "if (a)\nALIGN{\nALIGN" and whatever else. > > That way lies APL madness. To exemplify, Kona is an open-source interpreter for Arthur Whitney's K version 3 language, which is closely related to APL, but crams almost all of the APL operators onto single ASCII characters with massive overloading. For example, monadic ! is APL "iota", but dyadic ! is "modulo" if both arguments are numbers and "rotate" if the right argument is a number and the left argument is a vector. What any of these has to do with the rest is beyond me: I had to create a set of flash cards to help me learn them all. Not sure what this has to do with tabs but note that APL itself did a lot of punning in that unary and binary functions of the same name were related. K does something similar but perhaps not as consistently. > Well, here's a procedure definition from the Kona source, in a file helpfully named kc.c (almost all of the source files have 1-2 character names): People should perhaps look at Whitney's original C code[1] that started all this (see below). I can no longer compile this but it is worth studying. This was the genesis of both K & J languages. There is method to Whitney's madness but it takes a while to grok his style. Given that he has produced 6 or so versions of K, a specialized C compiler, as well as an OS prototype (kOS), clearly it has worked extremely well for him! Whiney once explained "It is a lot easier to find your errors in four lines of code than in four hundred." [2] Though his style is not for most people! typedef char C;typedef long I; typedef struct a{I t,r,d[3],p[2];}*A; #define P printf #define R return #define V1(f) A f(w)A w; #define V2(f) A f(a,w)A a,w; #define DO(n,x) {I i=0,_n=(n);for(;i<_n;++i){x;}} I *ma(n){R(I*)malloc(n*4);}mv(d,s,n)I *d,*s;{DO(n,d[i]=s[i]);} tr(r,d)I *d;{I z=1;DO(r,z=z*d[i]);R z;} A ga(t,r,d)I *d;{A z=(A)ma(5+tr(r,d));z->t=t,z->r=r,mv(z->d,d,r); R z;} V1(iota){I n=*w->p;A z=ga(0,1,&n);DO(n,z->p[i]=i);R z;} V2(plus){I r=w->r,*d=w->d,n=tr(r,d);A z=ga(0,r,d); DO(n,z->p[i]=a->p[i]+w->p[i]);R z;} V2(from){I r=w->r-1,*d=w->d+1,n=tr(r,d); A z=ga(w->t,r,d);mv(z->p,w->p+(n**a->p),n);R z;} V1(box){A z=ga(1,0,0);*z->p=(I)w;R z;} V2(cat){I an=tr(a->r,a->d),wn=tr(w->r,w->d),n=an+wn; A z=ga(w->t,1,&n);mv(z->p,a->p,an);mv(z->p+an,w->p,wn);R z;} V2(find){} V2(rsh){I r=a->r?*a->d:1,n=tr(r,a->p),wn=tr(w->r,w->d); A z=ga(w->t,r,a->p);mv(z->p,w->p,wn=n>wn?wn:n); if(n-=wn)mv(z->p+wn,z->p,n);R z;} V1(sha){A z=ga(0,1,&w->r);mv(z->p,w->d,w->r);R z;} V1(id){R w;}V1(size){A z=ga(0,0,0);*z->p=w->r?*w->d:1;R z;} pi(i){P("%d ",i);}nl(){P("\n");} pr(w)A w;{I r=w->r,*d=w->d,n=tr(r,d);DO(r,pi(d[i]));nl(); if(w->t)DO(n,P("< ");pr(w->p[i]))else DO(n,pi(w->p[i]));nl();} C vt[]="+{~<#,"; A(*vd[])()={0,plus,from,find,0,rsh,cat}, (*vm[])()={0,id,size,iota,box,sha,0}; I st[26]; qp(a){R a>='a'&&a<='z';}qv(a){R a<'a';} A ex(e)I *e;{I a=*e; if(qp(a)){if(e[1]=='=')R st[a-'a']=ex(e+2);a= st[ a-'a'];} R qv(a)?(*vm[a])(ex(e+1)):e[1]?(*vd[e[1]])(a,ex(e+2)):(A)a;} noun(c){A z;if(c<'0'||c>'9')R 0;z=ga(0,0,0);*z->p=c-'0';R z;} verb(c){I i=0;for(;vt[i];)if(vt[i++]==c)R i;R 0;} I *wd(s)C *s;{I a,n=strlen(s),*e=ma(n+1);C c; DO(n,e[i]=(a=noun(c=s[i]))?a:(a=verb(c))?a:c);e[n]=0;R e;} main(){C s[99];while(gets(s))pr(ex(wd(s)));} [1] https://code.jsoftware.com/wiki/Essays/Incunabulum One summer weekend in 1989, Arthur Whitney visited Ken Iverson at Kiln Farm and produced—on one page and in one afternoon—an interpreter fragment on the AT&T 3B1 computer. I (Roger Hui) studied this interpreter for about a week for its organization and programming style; and on Sunday, August 27, 1989, at about four o'clock in the afternoon, wrote the first line of code that became the implementation described in this document. [2] http://archive.vector.org.uk/art10501320 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Sat Mar 6 08:23:11 2021 From: bakul at iitbombay.org (Bakul Shah) Date: Fri, 5 Mar 2021 14:23:11 -0800 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: <202103051643.125Ghfqr014924@sdf.org> References: <202103051643.125Ghfqr014924@sdf.org> Message-ID: On Mar 5, 2021, at 8:43 AM, Scot Jenkins via TUHS wrote: > > The beauty of hard tabs is that the person viewing the code can > choose how to display them in their editor. If everyone indents > with the Tab character, the problem goes away. Also works well with variable width fonts. For some strange reason this is not a popular choice! From john at jfloren.net Sat Mar 6 08:51:40 2021 From: john at jfloren.net (John Floren) Date: Fri, 5 Mar 2021 14:51:40 -0800 Subject: [TUHS] A stack of PDP-11 field maintenance print sets Message-ID: I've been hauling around a pile of DEC Field Maintenance Print Sets for PDP-11 components for over a decade now, intending to see if they're worth having scanned or if there are digital versions out there already. Can anyone on the list point me to either an existing archive where these exist, or an archivist who would be interested in scanning them? They're full of exploded diagrams, schematics, and assembly listings. Here's the list of what I have: Field Maintenance Print Set (17" wide, 11" high): RLV11 disk controller RL01-AK disk drive ADV-11A (??) Field Maintenance Print Set (14" wide, 8.5" high): RL01 disk drive DLV11-J serial line controller RLV11 disk controller KFD11-A cpu KEF11-A floating point processor PDP11/23 PDP11/03-L Thanks, John Floren From norman at oclsc.org Sat Mar 6 08:50:47 2021 From: norman at oclsc.org (Norman Wilson) Date: Fri, 05 Mar 2021 17:50:47 -0500 Subject: [TUHS] tabs vs spaces - entab, detab Message-ID: <1614984654.6041.for-standards-violators@oclsc.org> I could chip in with my own strong opinions about code formatting, but I think others have already posted plenty of such boring off-topic fluff. A straight answer to Will's original question might be interesting, though: The oldest extant UNIX code samples I know are those the TUHS archive, in Distributions/Research/Dennis_v3/nsys.tar.gz; they're a very old kernel source tree. There are plenty of tabs there. This matches my memories of the V7-era source code, and of what I saw people like ken and dmr and rob and bwk and pjw typing in the not- so-early days of the 1980s when I worked with them. Tabs were generally eight spaces apart. In code, nobody worried about the effects on long lines, because the coding style was spare and didn't run to many deeply-nested constructs, so lines didn't get that long. (Maybe it was considered a feature rather than a bug that deep nesting and deep indentation looked messy, because it wasn't usually a good idea anyway.) I can't speak to original motivations, but I suspect my own reasons for using tabs aren't too different: -- It's quicker and faster to type than multiple spaces -- When not at the start of the line, tabs more often preserve alignment when earlier part of the line are edited -- Back when terminals were connected at speeds like 110 or 300 bps (I am old enough to have experienced that, especially when working from home), letting the system send a tab and the local terminal expand it was a lot faster, especially when reading code (more likely to have lots of indentation than prose). Not every device supported tabs, but enough did that it made a real difference. UNIX didn't originate any of this. I used tabs when writing in FORTRAN and ALGOL/SIMULA and MACRO-10 on the TOPS-10 system I used before I encountered UNIX. So did all the other hackers I knew in the terminal room where we all hung out. I don't know the history of entab/detab. Neither appears to have been around in the Research systems; they're not in V7 and they're not in V10. V7 does. As an aside, the V10 manual has a single manual page for col, [23456], mc, fold, and expand. It's a wonderful example of how gracefully Doug assembled collections of related small programs onto a single page to keep the manual size down. Also of his gift for concise prose: the first sentence is These programs rearrange files for appearance's sake. which is a spot-on but non-stodgy summary. I wish I could write half as well as Doug can. And as an almost-joke, it's a wonder those programs haven't all been made into options to cat in modern systems. Norman Wilson Toronto ON From kennethgoodwin56 at gmail.com Sat Mar 6 10:25:25 2021 From: kennethgoodwin56 at gmail.com (Kenneth Goodwin) Date: Fri, 5 Mar 2021 19:25:25 -0500 Subject: [TUHS] A stack of PDP-11 field maintenance print sets In-Reply-To: References: Message-ID: There are several computer museums that might be interested in them So don't toss them at this point. On Fri, Mar 5, 2021, 5:52 PM John Floren wrote: > I've been hauling around a pile of DEC Field Maintenance Print Sets > for PDP-11 components for over a decade now, intending to see if > they're worth having scanned or if there are digital versions out > there already. Can anyone on the list point me to either an existing > archive where these exist, or an archivist who would be interested in > scanning them? They're full of exploded diagrams, schematics, and > assembly listings. > > Here's the list of what I have: > > Field Maintenance Print Set (17" wide, 11" high): > RLV11 disk controller > RL01-AK disk drive > ADV-11A (??) > > Field Maintenance Print Set (14" wide, 8.5" high): > RL01 disk drive > DLV11-J serial line controller > RLV11 disk controller > KFD11-A cpu > KEF11-A floating point processor > PDP11/23 > PDP11/03-L > > Thanks, > > John Floren > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at jfloren.net Sat Mar 6 10:29:16 2021 From: john at jfloren.net (John Floren) Date: Fri, 5 Mar 2021 16:29:16 -0800 Subject: [TUHS] A stack of PDP-11 field maintenance print sets In-Reply-To: References: Message-ID: Absolutely not tossing them, just wondering if there are already scanned copies available somewhere, if I should send them off to be scanned and put online, or if I should just check in with computer museums (I'm near the CHM, for instance) john On Fri, Mar 5, 2021 at 4:25 PM Kenneth Goodwin wrote: > > There are several computer museums that might be interested in them > So don't toss them at this point. > > On Fri, Mar 5, 2021, 5:52 PM John Floren wrote: >> >> I've been hauling around a pile of DEC Field Maintenance Print Sets >> for PDP-11 components for over a decade now, intending to see if >> they're worth having scanned or if there are digital versions out >> there already. Can anyone on the list point me to either an existing >> archive where these exist, or an archivist who would be interested in >> scanning them? They're full of exploded diagrams, schematics, and >> assembly listings. >> >> Here's the list of what I have: >> >> Field Maintenance Print Set (17" wide, 11" high): >> RLV11 disk controller >> RL01-AK disk drive >> ADV-11A (??) >> >> Field Maintenance Print Set (14" wide, 8.5" high): >> RL01 disk drive >> DLV11-J serial line controller >> RLV11 disk controller >> KFD11-A cpu >> KEF11-A floating point processor >> PDP11/23 >> PDP11/03-L >> >> Thanks, >> >> John Floren From grog at lemis.com Sat Mar 6 11:16:48 2021 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Sat, 6 Mar 2021 12:16:48 +1100 Subject: [TUHS] tunefs -m 5% In-Reply-To: <25189.1614937832@hop.toad.com> References: <20210304212459.GA6303@eureka.lemis.com> <20210304212917.GB6303@eureka.lemis.com> <25189.1614937832@hop.toad.com> Message-ID: <20210306011648.GA80491@eureka.lemis.com> I haven't redirected this reply to COFF, though I was considering doing so: it On Friday, 5 March 2021 at 1:50:32 -0800, John Gilmore wrote: > John P. Linderman wrote: >> I have several 12 TB disks scattered about my house. 5% of 12TB is 600GB. > > At one point in hystery, ext2 performance was reported to suffer badly > if there was less than 5% of disk space available in an active > filesystem. My naive belief, probably informed by older and wiser heads > around Sun, was that when the file system was >95% full, ext2 spent a > lot of time seeking around in free lists finding single allocatable > blocks. And there were no built-in "defragmentation" programs that > could easily fix that. This appears to have been inherited from UFS. My recollection is pretty much the same for UFS, and even the man page entry for EXT4 is closely related to UFS newfs(8): Linux: -m reserved-blocks-percentage Specify the percentage of the filesystem blocks reserved for the super-user. This avoids fragmentation, and allows root-owned daemons, such as syslogd(8), to continue to function correctly after non-privileged processes are prevented from writing to the filesystem. The default percentage is 5%. FreBSD: -m free-space The percentage of space reserved from normal users; the minimum free space threshold. The default value used is defined by MINFREE from , currently 8%. See tunefs(8) for more details on how to set this option. And I can confirm that file systems slow down significantly after the last 1% of free space has been used. > Is that still a performance constraint in ext4, which has had a few > decades to work out those edge performance issues? Hopefully Ted will comment. But UFS has had even more decades. And arguably 600 GB on a modern disk is less of a concern than 15 MB on a 300 MB disk 40 years ago. 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 grog at lemis.com Sat Mar 6 11:18:25 2021 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Sat, 6 Mar 2021 12:18:25 +1100 Subject: [TUHS] tunefs -m 5% In-Reply-To: References: <20210304212459.GA6303@eureka.lemis.com> <20210304212917.GB6303@eureka.lemis.com> <25189.1614937832@hop.toad.com> Message-ID: <20210306011824.GB80491@eureka.lemis.com> On Friday, 5 March 2021 at 10:32:15 -0500, Theodore Ts'o wrote: > On Fri, Mar 05, 2021 at 01:50:32AM -0800, John Gilmore wrote: >> John P. Linderman wrote: >>> I have several 12 TB disks scattered about my house. 5% of 12TB is 600GB. >> >> At one point in hystery, ext2 performance was reported to suffer badly >> if there was less than 5% of disk space available in an active >> filesystem. My naive belief, probably informed by older and wiser heads >> around Sun, was that when the file system was >95% full, ext2 spent a >> lot of time seeking around in free lists finding single allocatable >> blocks. And there were no built-in "defragmentation" programs that >> could easily fix that. > > I'll point out that BSD FFS, at least in BSD 4.3, reserves 10% of the > file system for reserved blocks. Oops, that's what I get for reading messages sequentially :-( But in this case it's for small values of 10. 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 imp at bsdimp.com Sat Mar 6 11:52:02 2021 From: imp at bsdimp.com (Warner Losh) Date: Fri, 5 Mar 2021 18:52:02 -0700 Subject: [TUHS] tunefs -m 5% In-Reply-To: <20210306011824.GB80491@eureka.lemis.com> References: <20210304212459.GA6303@eureka.lemis.com> <20210304212917.GB6303@eureka.lemis.com> <25189.1614937832@hop.toad.com> <20210306011824.GB80491@eureka.lemis.com> Message-ID: On Fri, Mar 5, 2021, 6:18 PM Greg 'groggy' Lehey wrote: > On Friday, 5 March 2021 at 10:32:15 -0500, Theodore Ts'o wrote: > > On Fri, Mar 05, 2021 at 01:50:32AM -0800, John Gilmore wrote: > >> John P. Linderman wrote: > >>> I have several 12 TB disks scattered about my house. 5% of 12TB is > 600GB. > >> > >> At one point in hystery, ext2 performance was reported to suffer badly > >> if there was less than 5% of disk space available in an active > >> filesystem. My naive belief, probably informed by older and wiser heads > >> around Sun, was that when the file system was >95% full, ext2 spent a > >> lot of time seeking around in free lists finding single allocatable > >> blocks. And there were no built-in "defragmentation" programs that > >> could easily fix that. > > > > I'll point out that BSD FFS, at least in BSD 4.3, reserves 10% of the > > file system for reserved blocks. > > Oops, that's what I get for reading messages sequentially :-( But in > this case it's for small values of 10. > We set this to 1% at Netflix and fill to about ~98-99% full over UFS. This works well as we don't have small files. SATA Flash we keep a bit more empty, but that's due to its crappy FLT liking more free space... Warner 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 -------------- An HTML attachment was scrubbed... URL: From mochid at netside.co.jp Sat Mar 6 12:42:01 2021 From: mochid at netside.co.jp (MOCHIDA Shuji) Date: Sat, 06 Mar 2021 11:42:01 +0900 (JST) Subject: [TUHS] 4.4BSD sparc, pmax binary recently compiled Message-ID: <20210306.114201.619231632323334129.mochid@netside.co.jp> I compiled 4.4BSD to get pmax and sparc binary, from CSRG Archive CD-ROM #4 source code. http://www.netside.co.jp/~mochid/comp/bsd44-build/ pmax: - Works on GXemul DECstaion(PMAX) emulation. - I used binutils 2.6 and gcc 2.7.2.3 taken from Gnu ftp site, as 4.4BSD src does not contain pmax support part in as, ld, gcc and gdb. - Lack of GDB. I got rid of compile errors of gdb 4.16, but that does not work yet. - gcc included can not deal c++ static constructor. So, contrib/groff can not be compiled. Instead, it uses old/{nroff,troff,eqn,tbl..}. sparc: - Works on sun4c. I use on SPARCstation 2, real hardware. TME sun4c emulation can boot to single user, but it locks up in middle of /etc/rc. CSRG Archive CD-ROM #4's source code (just after Lite2 release) seems have differences from CSRG's binary distributions before (2 times), e.g. mount systemcall is not compatible. I used NetBSD 1.0/sparc, NetBSD 1.1/pmax for 1st (slightly) cross compiling. NetBSD 1.0/sparc boots and works well on TME emulator. SunOS 4.1.4, Solaris7 works too, but this 4.4BSD binary doesn't.. -mochid From rp at servium.ch Sat Mar 6 17:35:05 2021 From: rp at servium.ch (Rico Pajarola) Date: Fri, 5 Mar 2021 23:35:05 -0800 Subject: [TUHS] 4.4BSD sparc, pmax binary recently compiled In-Reply-To: <20210306.114201.619231632323334129.mochid@netside.co.jp> References: <20210306.114201.619231632323334129.mochid@netside.co.jp> Message-ID: great work, this is really cool! I'll give this a try on a real DECstation when I get a chance On Fri, Mar 5, 2021 at 6:43 PM MOCHIDA Shuji wrote: > > I compiled 4.4BSD to get pmax and sparc binary, from CSRG Archive CD-ROM > #4 > source code. > > http://www.netside.co.jp/~mochid/comp/bsd44-build/ > > pmax: > - Works on GXemul DECstaion(PMAX) emulation. > - I used binutils 2.6 and gcc 2.7.2.3 taken from Gnu ftp site, > as 4.4BSD src does not contain pmax support part in as, ld, > gcc and gdb. > - Lack of GDB. I got rid of compile errors of gdb 4.16, but that > does not work yet. > - gcc included can not deal c++ static constructor. So, contrib/groff > can not be compiled. Instead, it uses old/{nroff,troff,eqn,tbl..}. > > sparc: > - Works on sun4c. I use on SPARCstation 2, real hardware. > TME sun4c emulation can boot to single user, but it locks up in > middle of /etc/rc. > > CSRG Archive CD-ROM #4's source code (just after Lite2 release) seems > have differences from CSRG's binary distributions before (2 times), > e.g. mount systemcall is not compatible. > > I used NetBSD 1.0/sparc, NetBSD 1.1/pmax for 1st (slightly) cross > compiling. NetBSD 1.0/sparc boots and works well on TME emulator. > SunOS 4.1.4, Solaris7 works too, but this 4.4BSD binary doesn't.. > > -mochid > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mphuff at gmail.com Sat Mar 6 18:00:44 2021 From: mphuff at gmail.com (Michael Huff) Date: Fri, 5 Mar 2021 23:00:44 -0900 Subject: [TUHS] 4.4BSD sparc, pmax binary recently compiled In-Reply-To: <20210306.114201.619231632323334129.mochid@netside.co.jp> References: <20210306.114201.619231632323334129.mochid@netside.co.jp> Message-ID: Truly wonderful stuff -thank you for putting it together! It took me a bit to puzzle out what to type, mostly because I'm unfamiliar with gxemul. What finally did the trick for me (on NetBSD 9.1) was:  gxemul -X -e 3max -db:./bsd44f-pmax-self-20210224.dkimg -j vmunix Now I just need to figure out how to get things in and out of there! Thank you so, so much! On 3/5/2021 5:42 PM, MOCHIDA Shuji wrote: > I compiled 4.4BSD to get pmax and sparc binary, from CSRG Archive CD-ROM #4 > source code. > > http://www.netside.co.jp/~mochid/comp/bsd44-build/ > > pmax: > - Works on GXemul DECstaion(PMAX) emulation. > - I used binutils 2.6 and gcc 2.7.2.3 taken from Gnu ftp site, > as 4.4BSD src does not contain pmax support part in as, ld, > gcc and gdb. > - Lack of GDB. I got rid of compile errors of gdb 4.16, but that > does not work yet. > - gcc included can not deal c++ static constructor. So, contrib/groff > can not be compiled. Instead, it uses old/{nroff,troff,eqn,tbl..}. > > sparc: > - Works on sun4c. I use on SPARCstation 2, real hardware. > TME sun4c emulation can boot to single user, but it locks up in > middle of /etc/rc. > > CSRG Archive CD-ROM #4's source code (just after Lite2 release) seems > have differences from CSRG's binary distributions before (2 times), > e.g. mount systemcall is not compatible. > > I used NetBSD 1.0/sparc, NetBSD 1.1/pmax for 1st (slightly) cross > compiling. NetBSD 1.0/sparc boots and works well on TME emulator. > SunOS 4.1.4, Solaris7 works too, but this 4.4BSD binary doesn't.. > > -mochid From jnc at mercury.lcs.mit.edu Sun Mar 7 00:15:25 2021 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 6 Mar 2021 09:15:25 -0500 (EST) Subject: [TUHS] A stack of PDP-11 field maintenance print sets Message-ID: <20210306141525.A4C0F18C082@mercury.lcs.mit.edu> > From: John Floren > Can anyone on the list point me to either an existing archive where > these exist The canonical repository for historic documentation online is BitSavers. It has an almost-complete set of DEC stuff (both manuals and prints. QBUS devices are at: http://www.bitsavers.org/pdf/dec/qbus/ QBUS CPU's will be in the relevant model directory, e.g.: http://www.bitsavers.org/pdf/dec/pdp11/1123/ and disk drives are in: http://www.bitsavers.org/pdf/dec/disc/ I haven't checked your list, but I suspect most of them are there; I think the ADV11-A prints are missing, though. You can either send the originals to Al Kossow, or scan them for him; but check with him first, to make sure he doen't already have them, just hasn't got around to posting them yet. There's another site which indexes DEC online documentation: https://manx-docs.org/ There are a very few things which aren't in Bitsavers, and can be found there. > KFD11-A cpu I assume that's a typo for 'KDF11-A'? Noel From mochid at netside.co.jp Sun Mar 7 02:01:10 2021 From: mochid at netside.co.jp (MOCHIDA Shuji) Date: Sun, 07 Mar 2021 01:01:10 +0900 (JST) Subject: [TUHS] 4.4BSD sparc, pmax binary recently compiled In-Reply-To: References: <20210306.114201.619231632323334129.mochid@netside.co.jp> Message-ID: <20210307.010110.2129264166997997578.mochid@netside.co.jp> > gxemul -X -e 3max -db:./bsd44f-pmax-self-20210224.dkimg -j vmunix You may add -o '-s' to boot single user, for setting time. # TZ=Japan date Sat Mar 6 20:11:12 JST 1994 # TZ=Japan date 2103062012 Sat Mar 6 20:12:00 JST 2021 # fsck -p # ^D That is same as NetBSD 1.1/pmax. Emulator GXemul returns fixed year value 72 in gxemul-0.6.2/src/devices/dev_mc146818.cc mc146818_update_time():244, 4.4BSD's src/sys/pmax/pmax/clock.c inittodr() do year + YR_OFFSET -> 94, evry time you boot. > Now I just need to figure out how to get things in and out of there! gxemul support NAPT networking by default, router 10.0.0.254 prepared. You can add same network address to le0. # ifconfig le0 10.0.0.3 # route add default 10.0.0.254 If your gxemul is by pkgsrc, and above 0.6.2nb1, tap(4) support exists. I can use NFS (mount_nfs -P), and amd (use mount:=, unmount:=), though low speed and unstable. -mochid From dave at horsfall.org Sun Mar 7 06:51:44 2021 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 7 Mar 2021 07:51:44 +1100 (EST) Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: Message-ID: One place I worked even had their Xterms set to 4 spaces; it caused a lot of grief when I imported some software from a previous employer which had tabs every 8 spaces (don't ask). However, I'm now a 4-space person, but with hard tabs set where they are supposed to be so I use a mixture of ^T/^D etc. That said, I also have the view that if your code needs to be indented so much then it probably ought to be split out into functions; there's that old aphorism about a single page of code... -- Dave From jon at fourwinds.com Sun Mar 7 07:01:14 2021 From: jon at fourwinds.com (Jon Steinhart) Date: Sat, 06 Mar 2021 13:01:14 -0800 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: Message-ID: <202103062101.126L1E2T2673856@darkstar.fourwinds.com> Dave Horsfall writes: > That said, I also have the view that if your code needs to be indented so > much then it probably ought to be split out into functions; there's that > old aphorism about a single page of code... I prefer the aphorism of splitting code out into functions if and only if it improves readability for people who didn't write the code. The trouble that I have with many coding ideologies is that it seems like the goal is some slavish adherence to a rule set instead of improving readability. I've coined (at least I think I did) the phrase "meatspace locality of reference" for talking about this sort of thing. People go through great pains to keep executing code "on the same page", for efficiency but take the opposite approach when making code for people instead of machines. Doesn't make sense to me. Jon From lm at mcvoy.com Sun Mar 7 07:19:44 2021 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 6 Mar 2021 13:19:44 -0800 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: <202103062101.126L1E2T2673856@darkstar.fourwinds.com> References: <202103062101.126L1E2T2673856@darkstar.fourwinds.com> Message-ID: <20210306211944.GE1054@mcvoy.com> On Sat, Mar 06, 2021 at 01:01:14PM -0800, Jon Steinhart wrote: > The trouble that I have with many coding ideologies is that it seems > like the goal is some slavish adherence to a rule set instead of > improving readability. Amen. I told my team "Optimize for reading, it's write once (or few) and read many". Anything that makes the code easier to read is a win even if it is more work for the writer. From dave at horsfall.org Sun Mar 7 07:22:21 2021 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 7 Mar 2021 08:22:21 +1100 (EST) Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: <20210304212459.GA6303@eureka.lemis.com> <20210304212917.GB6303@eureka.lemis.com> Message-ID: On Thu, 4 Mar 2021, Andy Kosela wrote: > [...] and that is akin to trying to define the value of PI to be 3." Urban myth. -- Dave From dave at horsfall.org Sun Mar 7 07:31:57 2021 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 7 Mar 2021 08:31:57 +1100 (EST) Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: <25705.1614938294@hop.toad.com> References: <202103041831.124IVZTj018003@freefriends.org> <604133A6.8070101@gmail.com> <25705.1614938294@hop.toad.com> Message-ID: (Straying into COFF territory here) On Fri, 5 Mar 2021, John Gilmore wrote: > The one that got me was make(1). Being used to text editors that used > "tab" as a command rather than a literal character, I proposed a fix > early on at Sun that would allow leading spaces as well as tabs in > Makefiles. (I think this was in the Unisoft Unix days, pre-BSD.) Bill > Shannon actually put it into their source tree. But in a few days or > weeks, he took it back out, because he realized that Makefiles built on > Suns using leading spaces wouldn't work anywhere else. I loathe make's distinguishment between tabs and spaces; they look the same on the screen, and last I looked computers are supposed to serve humans and not the other way around. -- Dave From lm at mcvoy.com Sun Mar 7 07:38:11 2021 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 6 Mar 2021 13:38:11 -0800 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: <202103041831.124IVZTj018003@freefriends.org> <604133A6.8070101@gmail.com> <25705.1614938294@hop.toad.com> Message-ID: <20210306213811.GF1054@mcvoy.com> On Sun, Mar 07, 2021 at 08:31:57AM +1100, Dave Horsfall wrote: > (Straying into COFF territory here) > > On Fri, 5 Mar 2021, John Gilmore wrote: > > >The one that got me was make(1). Being used to text editors that used > >"tab" as a command rather than a literal character, I proposed a fix early > >on at Sun that would allow leading spaces as well as tabs in Makefiles. > >(I think this was in the Unisoft Unix days, pre-BSD.) Bill Shannon > >actually put it into their source tree. But in a few days or weeks, he > >took it back out, because he realized that Makefiles built on Suns using > >leading spaces wouldn't work anywhere else. > > I loathe make's distinguishment between tabs and spaces; they look the same > on the screen, and last I looked computers are supposed to serve humans and > not the other way around. Has anyone asked Stu Feldman why make wanted a tab? Or does anyone know? I have to believe there was a better reason than it was one tab vs 8 spaces. From usotsuki at buric.co Sun Mar 7 07:40:07 2021 From: usotsuki at buric.co (Steve Nickolas) Date: Sat, 6 Mar 2021 16:40:07 -0500 (EST) Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: <202103041831.124IVZTj018003@freefriends.org> <604133A6.8070101@gmail.com> <25705.1614938294@hop.toad.com> Message-ID: On Sun, 7 Mar 2021, Dave Horsfall wrote: > (Straying into COFF territory here) > > On Fri, 5 Mar 2021, John Gilmore wrote: > >> The one that got me was make(1). Being used to text editors that used >> "tab" as a command rather than a literal character, I proposed a fix early >> on at Sun that would allow leading spaces as well as tabs in Makefiles. (I >> think this was in the Unisoft Unix days, pre-BSD.) Bill Shannon actually >> put it into their source tree. But in a few days or weeks, he took it back >> out, because he realized that Makefiles built on Suns using leading spaces >> wouldn't work anywhere else. > > I loathe make's distinguishment between tabs and spaces; they look the same > on the screen, and last I looked computers are supposed to serve humans and > not the other way around. > > -- Dave > I used to have my own system for doing "make"-like builds which was a lot more primitive and just relied on a tool that returned an errorlevel based on whether a file needed to be rebuilt. Of course, that was because I used an editor that destroyed tabs. :/ Damn it, M$... -uso. From dave at horsfall.org Sun Mar 7 07:45:03 2021 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 7 Mar 2021 08:45:03 +1100 (EST) Subject: [TUHS] tunefs -m 5% In-Reply-To: References: <20210304212459.GA6303@eureka.lemis.com> <20210304212917.GB6303@eureka.lemis.com> <25189.1614937832@hop.toad.com> <20210306011824.GB80491@eureka.lemis.com> Message-ID: And that comment from FreeBSD's "tunefs" is still there: You can tune a file system, but you cannot tune a fish. Funny; I could've sworn that it used to be "cannot tuna fish". -- Dave From clemc at ccc.com Sun Mar 7 08:01:09 2021 From: clemc at ccc.com (Clem Cole) Date: Sat, 6 Mar 2021 17:01:09 -0500 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: <20210306211944.GE1054@mcvoy.com> References: <202103062101.126L1E2T2673856@darkstar.fourwinds.com> <20210306211944.GE1054@mcvoy.com> Message-ID: On Sat, Mar 6, 2021 at 4:20 PM Larry McVoy wrote: > On Sat, Mar 06, 2021 at 01:01:14PM -0800, Jon Steinhart wrote: > > The trouble that I have with many coding ideologies is that it seems > > like the goal is some slavish adherence to a rule set instead of > > improving readability. > > Amen. I told my team "Optimize for reading, it's write once (or few) and > read many". Anything that makes the code easier to read is a win even if > it is more work for the writer. > +1 ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sun Mar 7 08:03:02 2021 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 6 Mar 2021 14:03:02 -0800 Subject: [TUHS] tunefs -m 5% In-Reply-To: References: <20210304212459.GA6303@eureka.lemis.com> <20210304212917.GB6303@eureka.lemis.com> <25189.1614937832@hop.toad.com> <20210306011824.GB80491@eureka.lemis.com> Message-ID: <20210306220302.GG1054@mcvoy.com> On Sun, Mar 07, 2021 at 08:45:03AM +1100, Dave Horsfall wrote: > And that comment from FreeBSD's "tunefs" is still there: > > You can tune a file system, but you cannot tune a fish. > > Funny; I could've sworn that it used to be "cannot tuna fish". I did a checkin at Sun that added .\" Take this out and a Unix Daemon will dog your steps from now until .\" the time_t's wrap around. .LP You can tune a file system, but you cannot tune a fish. And of course, the numbnuts that ran Solaris took it back out. Unless I'm mistaken, I'm the dude that came up with the comment. I believe I spelled daemon wrong but whatever, I found that snippet in the FreeBSD sources so someone has a sense of humor and kept my comment. From clemc at ccc.com Sun Mar 7 08:05:37 2021 From: clemc at ccc.com (Clem Cole) Date: Sat, 6 Mar 2021 17:05:37 -0500 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: <20210306213811.GF1054@mcvoy.com> References: <202103041831.124IVZTj018003@freefriends.org> <604133A6.8070101@gmail.com> <25705.1614938294@hop.toad.com> <20210306213811.GF1054@mcvoy.com> Message-ID: On Sat, Mar 6, 2021 at 4:38 PM Larry McVoy wrote: > On Sun, Mar 07, 2021 at 08:31:57AM +1100, Dave Horsfall wrote: > > (Straying into COFF territory here) > > > > On Fri, 5 Mar 2021, John Gilmore wrote: > > > > >The one that got me was make(1). Being used to text editors that used > > >"tab" as a command rather than a literal character, I proposed a fix > early > > >on at Sun that would allow leading spaces as well as tabs in Makefiles. > > >(I think this was in the Unisoft Unix days, pre-BSD.) Bill Shannon > > >actually put it into their source tree. But in a few days or weeks, he > > >took it back out, because he realized that Makefiles built on Suns using > > >leading spaces wouldn't work anywhere else. > > > > I loathe make's distinguishment between tabs and spaces; they look the > same > > on the screen, and last I looked computers are supposed to serve humans > and > > not the other way around. > > Has anyone asked Stu Feldman why make wanted a tab? Or does anyone know? > I have to believe there was a better reason than it was one tab vs > 8 spaces. > According to Eric Raymond in Chapter 15. Tools: make: Automating Your Recipes", *The Art of Unix Programming* *Why the tab in column 1? Yacc was new, Lex was brand new. I hadn't tried either, so I figured this would be a good excuse to learn. After getting myself snarled up with my first stab at Lex, I just did something simple with the pattern newline-tab. It worked, it stayed. And then a few weeks later I had a user population of about a dozen, most of them friends, and I didn't want to screw up my embedded base. The rest, sadly, is history.* *— Stuart Feldman* ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Sun Mar 7 09:21:37 2021 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Sun, 07 Mar 2021 00:21:37 +0100 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: Message-ID: <20210306232137.RzjuT%steffen@sdaoden.eu> Greg A. Woods wrote in : |At Fri, 5 Mar 2021 11:44:49 -0500, M Douglas McIlroy wrote: |Subject: [TUHS] tabs vs spaces - entab, detab |> |>> The reason to use tab was file size for one |> |> This is urban legend. The percentage of 512-byte blocks that |> tabs would save was never significant. | |Using tabs to save space was definitely more than an urban legend for |some of us! (but there is a caveat below) That, for example if you have to use 1.44MB floppies for incremental backups and the project is larger. But i admit it became fashion of the day at some time. I had times where functions were separated by two newlines, modules ((anonymous) namespaces) by three, i had long separators like ^#+$ for shell/perl and '// -+ //' for C++ etc etc, where the number backing "+" was dependent upon what it separated. What a tremendous waste of space, and was it any clearer. I am not such a pragmatic person when doing creative work, especially not when starting from a white paper, well i know it is hopeless, and did so for a long time indeed, but over and over again you find yourself longing for the absolute clarity and perfection (well, surely in a frisky and at the same time blinkered way), and having a style pigeon-hole belongs to this. It just grew like that. There are more important things however, and i learned (but do not adhere to the conclusion) that what is really needed is a comment here and there, because if you have to touch code, then you need to read and at best understand it anyhow, and then all the above is just noise that is skipped over. --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 steffen at sdaoden.eu Sun Mar 7 09:43:20 2021 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Sun, 07 Mar 2021 00:43:20 +0100 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: <20210304212459.GA6303@eureka.lemis.com> <20210304212917.GB6303@eureka.lemis.com> <20210304221250.GD6303@eureka.lemis.com> <20210305141348.DIpGG%steffen@sdaoden.eu> Message-ID: <20210306234320.92r5x%steffen@sdaoden.eu> John Cowan wrote in : |On Fri, Mar 5, 2021 at 9:14 AM Steffen Nurpmeso wrote: |> But, not important. A real change to my coding style came when |> i looked around Plan9 source code, the pragmatism to simply not |> use spaces in language constructs aka statements at all, for |> example "if(a){" instead of "if(a) {" or "if (a) {", and let alone |> "if (a)\nALIGN{\nALIGN" and whatever else. | |That way lies APL madness. To exemplify, Kona is an open-source |interpreter for Arthur Whitney's K version 3 language, which is closely |related to APL, but crams almost all of the APL operators onto single ASCII |characters with massive overloading. For example, monadic ! is APL "iota", |but dyadic ! is "modulo" if both arguments are numbers and "rotate" if the |right argument is a number and the left argument is a vector. What any of |these has to do with the rest is beyond me: I had to create a set of flash |cards to help me learn them all. | |Well, here's a procedure definition from the Kona source, in a file |helpfully named kc.c (almost all of the source files have 1-2 character |names): | |I wds_(K*a,FILE*f,I l) |{ S s=0,t=0; I b=0,c=0,m=0,n=0,v=0; K z=0; PDA p=0; | I o=isatty(STDIN)&&f==stdin; | if(-1==(c=getline_(&s,&n,f)))GC; | appender(&t,&m,s,n); | while(1==(v=complete(t,m,&p,0))) | { b=parsedepth(p); | if(o)prompt(b+l); | if(-1==(c=getline_(&s,&n,f)))GC; | appender(&t,&m,s,n); } | SW(v){CS(2,show(kerr("unmatched"));GC) CS(3,show(kerr("nest")); GC)} | z=newK(-3,m-1); | strncpy(kC(z),t,m-1); | cleanup: | free(s); free(t); | if(p)pdafree(p); | if((v||c==-1)&&z){cd(z); *a=0;} | else *a=z; | R v?-v:c; } // -1 EOF, -2 unmatched, -3 nest | |If you want that sort of thing, you can certainly have it. Note the |single-space ident and the cuddled right braces. Note also the label |"cleanup:"; presumably a "goto cleanup;" is hidden somewhere in the |single-letter (of course) macros. I do not, no. The above has maybe the advantage that you really really have to sit down and understand it as a whole before you change anything, or apply patches. This is very different to the style that sometimes can be seen in projects with many people and many patches, where code is packed in what-the-writer-thinks-is-a- logical-block. I (unfortunately) do it like that too, very unfortunately with diverging positions of what a logical block is. Just from a single pick, take Linux 5.10 ipc/sem.c. You see sma = sem_alloc(nsems); if (!sma) return -ENOMEM; sma->sem_perm.mode = (semflg & S_IRWXUGO); sma->sem_perm.key = key; 1 sma->sem_perm.security = NULL; 2 retval = security_sem_alloc(&sma->sem_perm); if (retval) { kvfree(sma); return retval; } and i know that i would sometimes remove the newline 1 to finish init of sem_perm, and instead introduce a newline before 2 instead. I have no idea of kernel of course, here .security depends on a special config and security_sem_alloc() just does nothing without it (returning 0), not even setting .security to NULL, whereas otherwise .security is definetely set by lsm_ipc_alloc(), so maybe i understand 1, .. sometimes. But i would think about it. And all of this just cannot happen with the code above, i could use this style to fool myself into just not thinking about just useless thoughts! --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 david at kdbarto.org Sun Mar 7 09:52:43 2021 From: david at kdbarto.org (David Barto) Date: Sat, 6 Mar 2021 15:52:43 -0800 Subject: [TUHS] tunefs -m 5% In-Reply-To: References: <20210304212459.GA6303@eureka.lemis.com> <20210304212917.GB6303@eureka.lemis.com> <25189.1614937832@hop.toad.com> <20210306011824.GB80491@eureka.lemis.com> Message-ID: <68C45101-9E6B-48D1-8EE0-87815171CC6F@kdbarto.org> > On Mar 6, 2021, at 1:45 PM, Dave Horsfall wrote: > > And that comment from FreeBSD's "tunefs" is still there: > > You can tune a file system, but you cannot tune a fish. > > Funny; I could've sworn that it used to be "cannot tuna fish". > > — Dave In my copy of the BSD documentation (Unix System Manager’s Manual, with the red ring binder) the TUNEFS(8) page dated 20 February 1983 has “You can tune a file system, but you can’t tune a fish” as the last line. Noted as the 4th Berkeley Distribution Inside the cover it says: Printed by the USENIX Association as a service to the UNIX Community. Second Printing December 1984 From bakul at iitbombay.org Sun Mar 7 09:58:21 2021 From: bakul at iitbombay.org (Bakul Shah) Date: Sat, 6 Mar 2021 15:58:21 -0800 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: Message-ID: On Mar 6, 2021, at 1:22 PM, Dave Horsfall wrote: > > On Thu, 4 Mar 2021, Andy Kosela wrote: > >> [...] and that is akin to trying to define the value of PI to be 3." > > Urban myth. From the Kings James Bible https://quod.lib.umich.edu/cgi/k/kjv/kjv-idx?type=DIV1&byte=1392613 1 Kings 7:23 > And he made a molten sea, ten cubits from the one brim to the other: it was round all about, and his height was five cubits: and a line of thirty cubits did compass it round about. There seem to be various explanations for the above but perhaps it is the genesis of the common “define the value of pi to be 3” idea? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Sun Mar 7 10:03:12 2021 From: jon at fourwinds.com (Jon Steinhart) Date: Sat, 06 Mar 2021 16:03:12 -0800 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: Message-ID: <202103070003.12703Crs2866116@darkstar.fourwinds.com> Bakul Shah writes: > From the Kings James Bible > https://quod.lib.umich.edu/cgi/k/kjv/kjv-idx?type=DIV1&byte=1392613 > 1 Kings 7:23 > > And he made a molten sea, ten cubits from the one brim to the other: it was > round all about, and his height was five cubits: and a line of thirty > cubits did compass it round about. > > > There seem to be various explanations for the above but perhaps it is the > genesis of the common “define the value of pi to be 3” idea? It could just be a translation problem - maybe it was 30 qubits and wasn't properly observed. From usotsuki at buric.co Sun Mar 7 10:25:01 2021 From: usotsuki at buric.co (Steve Nickolas) Date: Sat, 6 Mar 2021 19:25:01 -0500 (EST) Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: Message-ID: On Sat, 6 Mar 2021, Bakul Shah wrote: > On Mar 6, 2021, at 1:22 PM, Dave Horsfall wrote: >> >> On Thu, 4 Mar 2021, Andy Kosela wrote: >> >>> [...] and that is akin to trying to define the value of PI to be 3." >> >> Urban myth. > > From the Kings James Bible > https://quod.lib.umich.edu/cgi/k/kjv/kjv-idx?type=DIV1&byte=1392613 > 1 Kings 7:23 >> And he made a molten sea, ten cubits from the one brim to the other: it >> was round all about, and his height was five cubits: and a line of >> thirty cubits did compass it round about. > > There seem to be various explanations for the above but perhaps it is > the genesis of the common “define the value of pi to be 3” idea? I believe it was - I've heard of it before. And I run in the kind of circles that would be likely to say "π=3.0 because JEBUS!" or "geocentricity because JEBUS!" :/ (In fact, it took a second to realize I was reading a TUHS post.) I worry for humanity. -uso. From beebe at math.utah.edu Sun Mar 7 12:53:16 2021 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Sat, 6 Mar 2021 19:53:16 -0700 Subject: [TUHS] tabs vs spaces - entab, detab Message-ID: Here is a link to the 1897 bill of the Indiana State Legislature that legislated a new value for $\pi$: https://journals.iupui.edu/index.php/ias/article/view/4753/4589 ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From brantley at coraid.com Sun Mar 7 19:16:33 2021 From: brantley at coraid.com (Brantley Coile) Date: Sun, 7 Mar 2021 09:16:33 +0000 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: Message-ID: <0D971D52-6751-41A1-90FE-44EB8FF0C4BE@coraid.com> I'm pretty sure people knew the value of PI before 1611, when the Authorized Version was published, and that people had a pretty good idea when the event described in 1 Kings 7 happened, a bit before 900 BC. They used 3.1605 for the ratio in that time, I believe. The values in the Bible are as one would explain to someone in conversation about something else. If I said something was 10 feet across and 30 feet around in normal conversation, an error of a foot and a half would be close enough. When buying material, I use 4 as PI and trim to fit. Brantley. > On Mar 6, 2021, at 6:58 PM, Bakul Shah wrote: > > On Mar 6, 2021, at 1:22 PM, Dave Horsfall wrote: >> >> On Thu, 4 Mar 2021, Andy Kosela wrote: >> >>> [...] and that is akin to trying to define the value of PI to be 3." >> >> Urban myth. > > From the Kings James Bible > https://quod.lib.umich.edu/cgi/k/kjv/kjv-idx?type=DIV1&byte=1392613 > 1 Kings 7:23 >> And he made a molten sea, ten cubits from the one brim to the other: it was round all about, and his height was five cubits: and a line of thirty cubits did compass it round about. > > There seem to be various explanations for the above but perhaps it is the genesis of the common “define the value of pi to be 3” idea? From will.senn at gmail.com Mon Mar 8 11:52:08 2021 From: will.senn at gmail.com (Will Senn) Date: Sun, 7 Mar 2021 19:52:08 -0600 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: <57A1A023-7E73-4233-8FF2-CED5EB1CDB7C@gmail.com> Message-ID: On 3/5/21 11:08 AM, Clem Cole wrote: > > > On Thu, Mar 4, 2021 at 9:07 PM Will Senn > wrote: > > Ha. I didn’t intend to reignite a flamewar. > > I warned ya ... 🤔 > >  But, i’m still curious about entab/detab abd expand, etc. Were > they oor some of them created to help with this or what? > > That's probably best for bwk, Ken, or Doug that go back to pre-UNIX > times at BTL. As was pointed out, bwk had them the SW tools book, so > the need/use go back pretty far. > > As someone else pointed out, in the days of printing terminals like > the 10 cps horizontal tabs _sometimes_ printed faster if they were a > mechanical scheme built into the HW.  On the other hand (and I don't > feel like finding/looking up at an ASR 33 manual), my memory is that > it did not have tabs stops and the UNIX TTY hander expanded them to > spaces so even that was not going to help.  Also as someone else said, > in those days we had 132/133 column line printer listing - which again > printed >>much<< faster than the 10 cps terminal.   So the 8-space = 1 > tab scheme certainly >>might<< make sense since it was enforced by the > HW. > Interesting. I continually forget the hardware that existed back in the day. I vaguely remember using line printers, but then it was laser not too long after that, so it's pretty fuzzy. My coding days came in the dot matrix days, but again laser was not too long after that :). I definitely heart 72 character lines - but prolly cuz of email more than anything else except maybe the adage of, if it won't fit on screen (in a terminal window), it's probably too complicated, which I still think is reasonable. After this thread, I think I'll probably stick to tabs because they seem to work better across environments. Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From wojciech at koszek.com Mon Mar 8 12:05:16 2021 From: wojciech at koszek.com (wojciech at koszek.com) Date: Sun, 7 Mar 2021 18:05:16 -0800 Subject: [TUHS] Richard Stevens Message-ID: Hello everyone, I'm Wojciech Adam Koszek and I'm a new member here. After a short stint with Red Hat 6.0 and Slackware Linux around 2000-2001 (I think it was Slackware 7.0 or 7.1) my journey with UNIX started with FreeBSD 4.5. I fell in love with BSD and through Warner Losh, Robert Watson, and folks from a Polish UNIX scene, I became hooked. I ended up working with FreeBSD for the following 15 years or so. Anyway: the volume of the UNIX literature back then in Poland was scarce, yet through a small bookstore and a friendly salesman I got myself a "UNIX Network Programming Volume 1" at a huge discount, and read it back-to-back. Looking back, his books had a huge impact on my life (I had all his books, and read everything line by line, with a slight exception of TCP/IP illustrated vol 2, which I used as a reference), and while Stevens's website sheds some light on what he did, I often wonder what is the story behind how his books came to be. It doesn't help he appeared a very private person--never have I seen a photo of him anywhere. What was the reception of his books in the US? Did you know him? Do you know any more details about what he did after 1990? Thanks and take care, Wojciech Adam Koszek From athornton at gmail.com Mon Mar 8 12:23:55 2021 From: athornton at gmail.com (Adam Thornton) Date: Sun, 7 Mar 2021 19:23:55 -0700 Subject: [TUHS] Richard Stevens In-Reply-To: References: Message-ID: The Richard Stevens books were huge here. I did not know him well but emailed with him a few times in the year before he died. I never met him in person but he was very kind to a much younger and more ignorant me. On Sun, Mar 7, 2021 at 7:21 PM wojciech at koszek.com wrote: > Hello everyone, > > I'm Wojciech Adam Koszek and I'm a new member here. After a short stint > with Red Hat 6.0 and Slackware Linux around 2000-2001 (I think it was > Slackware 7.0 or 7.1) my journey with UNIX started with FreeBSD 4.5. I fell > in love with BSD and through Warner Losh, Robert Watson, and folks from a > Polish UNIX scene, I became hooked. I ended up working with FreeBSD for the > following 15 years or so. > > Anyway: the volume of the UNIX literature back then in Poland was scarce, > yet through a small bookstore and a friendly salesman I got myself a "UNIX > Network Programming Volume 1" at a huge discount, and read it back-to-back. > > Looking back, his books had a huge impact on my life (I had all his books, > and read everything line by line, with a slight exception of TCP/IP > illustrated vol 2, which I used as a reference), and while Stevens's > website sheds some light on what he did, I often wonder what is the story > behind how his books came to be. It doesn't help he appeared a very private > person--never have I seen a photo of him anywhere. > > What was the reception of his books in the US? > > Did you know him? Do you know any more details about what he did after > 1990? > > Thanks and take care, > > Wojciech Adam Koszek -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Mon Mar 8 12:37:27 2021 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 7 Mar 2021 18:37:27 -0800 Subject: [TUHS] Richard Stevens In-Reply-To: References: Message-ID: <20210308023727.GB17304@mcvoy.com> I became troff buddies with him. I love troff and all the other tools, pic especially because you can read pic code and see the picture in your head. Richard and I shared that love for pic. He and I talked quite a bit about how to do stuff in troff. Troff buddies is the best way to describe what we had, we bonded over that but I wasn't close to him otherwise. Still miss him and our troff exchanges, he was a great guy, those books were the best in their day. He was a lot like Dennis, willing to talk to you and educate you if you had a clue. On Sun, Mar 07, 2021 at 07:23:55PM -0700, Adam Thornton wrote: > The Richard Stevens books were huge here. I did not know him well but > emailed with him a few times in the year before he died. I never met him > in person but he was very kind to a much younger and more ignorant me. > > On Sun, Mar 7, 2021 at 7:21 PM wojciech at koszek.com > wrote: > > > Hello everyone, > > > > I'm Wojciech Adam Koszek and I'm a new member here. After a short stint > > with Red Hat 6.0 and Slackware Linux around 2000-2001 (I think it was > > Slackware 7.0 or 7.1) my journey with UNIX started with FreeBSD 4.5. I fell > > in love with BSD and through Warner Losh, Robert Watson, and folks from a > > Polish UNIX scene, I became hooked. I ended up working with FreeBSD for the > > following 15 years or so. > > > > Anyway: the volume of the UNIX literature back then in Poland was scarce, > > yet through a small bookstore and a friendly salesman I got myself a "UNIX > > Network Programming Volume 1" at a huge discount, and read it back-to-back. > > > > Looking back, his books had a huge impact on my life (I had all his books, > > and read everything line by line, with a slight exception of TCP/IP > > illustrated vol 2, which I used as a reference), and while Stevens's > > website sheds some light on what he did, I often wonder what is the story > > behind how his books came to be. It doesn't help he appeared a very private > > person--never have I seen a photo of him anywhere. > > > > What was the reception of his books in the US? > > > > Did you know him? Do you know any more details about what he did after > > 1990? > > > > Thanks and take care, > > > > Wojciech Adam Koszek -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From tih at hamartun.priv.no Tue Mar 9 01:45:17 2021 From: tih at hamartun.priv.no (Tom Ivar Helbekkmo) Date: Mon, 08 Mar 2021 16:45:17 +0100 Subject: [TUHS] PWB/UNIX 1.0 on the PDP-11/23+ Message-ID: Following my success in getting 6th Edition UNIX running on a KDF11-B, with support for the MSCP disk controller, I was looking for ways to get as new a tool chain as possible onto it, with full source code (as I'd been using the tool chain from UNSW, for which the source is missing). Well, it turns out that there's an even newer one in PWB, and there are complete source and binary PWB distributions in the TUHS archive! I now have PWB/UNIX 1.0 running, and completely rebuilt from its own sources, on one of my physical /23+ boxes (and, of course, in simh). It's connected to my main (NetBSD) system using UUCP over a serial line. Oh, and it runs the University Ingres RDBMS. :) The write-up (and download) is at https://www.hamartun.priv.no/pwb.html -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 joe at via.net Tue Mar 9 06:46:31 2021 From: joe at via.net (joe mcguckin) Date: Mon, 8 Mar 2021 12:46:31 -0800 Subject: [TUHS] Richard Stevens In-Reply-To: <20210308023727.GB17304@mcvoy.com> References: <20210308023727.GB17304@mcvoy.com> Message-ID: Speaking of PIC: What’s the worst example of PIC abuse you know of? The one that immediately comes to mind is an example I saw at Tolerant (an 80’s era multi-processor computer company). The board diagrams, e.g the outline diagram of the printed circuit card with the outlines of each IC and it’s label, AND the artwork of the board edge connectors and switches (DB25, pushbuttone, etc). It looked like it was created by an artist in Ink. But of course, it was done in PIC! Joe McGuckin ViaNet Communications joe at via.net 650-207-0372 cell 650-213-1302 office 650-969-2124 fax > On Mar 7, 2021, at 6:37 PM, Larry McVoy wrote: > > I became troff buddies with him. I love troff and all the other tools, > pic especially because you can read pic code and see the picture in your > head. Richard and I shared that love for pic. He and I talked quite a > bit about how to do stuff in troff. Troff buddies is the best way to > describe what we had, we bonded over that but I wasn't close to him > otherwise. Still miss him and our troff exchanges, he was a great > guy, those books were the best in their day. > > He was a lot like Dennis, willing to talk to you and educate you if you > had a clue. > > On Sun, Mar 07, 2021 at 07:23:55PM -0700, Adam Thornton wrote: >> The Richard Stevens books were huge here. I did not know him well but >> emailed with him a few times in the year before he died. I never met him >> in person but he was very kind to a much younger and more ignorant me. >> >> On Sun, Mar 7, 2021 at 7:21 PM wojciech at koszek.com >> wrote: >> >>> Hello everyone, >>> >>> I'm Wojciech Adam Koszek and I'm a new member here. After a short stint >>> with Red Hat 6.0 and Slackware Linux around 2000-2001 (I think it was >>> Slackware 7.0 or 7.1) my journey with UNIX started with FreeBSD 4.5. I fell >>> in love with BSD and through Warner Losh, Robert Watson, and folks from a >>> Polish UNIX scene, I became hooked. I ended up working with FreeBSD for the >>> following 15 years or so. >>> >>> Anyway: the volume of the UNIX literature back then in Poland was scarce, >>> yet through a small bookstore and a friendly salesman I got myself a "UNIX >>> Network Programming Volume 1" at a huge discount, and read it back-to-back. >>> >>> Looking back, his books had a huge impact on my life (I had all his books, >>> and read everything line by line, with a slight exception of TCP/IP >>> illustrated vol 2, which I used as a reference), and while Stevens's >>> website sheds some light on what he did, I often wonder what is the story >>> behind how his books came to be. It doesn't help he appeared a very private >>> person--never have I seen a photo of him anywhere. >>> >>> What was the reception of his books in the US? >>> >>> Did you know him? Do you know any more details about what he did after >>> 1990? >>> >>> Thanks and take care, >>> >>> Wojciech Adam Koszek > > -- > --- > Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm -------------- next part -------------- An HTML attachment was scrubbed... URL: From grog at lemis.com Tue Mar 9 14:59:47 2021 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Tue, 9 Mar 2021 15:59:47 +1100 Subject: [TUHS] tunefs -m 5% In-Reply-To: <20210306220302.GG1054@mcvoy.com> References: <20210304212459.GA6303@eureka.lemis.com> <20210304212917.GB6303@eureka.lemis.com> <25189.1614937832@hop.toad.com> <20210306011824.GB80491@eureka.lemis.com> <20210306220302.GG1054@mcvoy.com> Message-ID: <20210309045947.GC73112@eureka.lemis.com> On Saturday, 6 March 2021 at 14:03:02 -0800, Larry McVoy wrote: > On Sun, Mar 07, 2021 at 08:45:03AM +1100, Dave Horsfall wrote: >> And that comment from FreeBSD's "tunefs" is still there: >> >> You can tune a file system, but you cannot tune a fish. >> >> Funny; I could've sworn that it used to be "cannot tuna fish". I checked the CSRG archive CDs. The line was added, as shown, in 4.2BSD: --- ./4.1c.2/usr/man/man8/tunefs.8 1983-03-04 02:43:21.000000000 +1100 +++ ./4.2/usr/man/man8/tunefs.8 1983-07-27 18:21:46.000000000 +1000 @@ -4,7 +4,8 @@ @@ -66,3 +67,5 @@ Because the super-block is not kept in the buffer cache, the program will only take effect if it is run on dismounted file systems. (if run on the root file system, the system must be rebooted) +.PP +You can tune a file system, but you can't tune a fish. > I did a checkin at Sun that added > > .\" Take this out and a Unix Daemon will dog your steps from now until > .\" the time_t's wrap around. > .LP > You can tune a file system, but you cannot tune a fish. > > And of course, the numbnuts that ran Solaris took it back out. Unless I'm > mistaken, I'm the dude that came up with the comment. I believe I spelled > daemon wrong but whatever, I found that snippet in the FreeBSD sources so > someone has a sense of humor and kept my comment. Sadly, humour is no longer modern. A while back I updated the documentation to gdb(4) in FreeBSD, and added under BUGS: The debugging macros .Dq "just growed" . In general, the person who wrote them did so while looking for a specific problem, so they may not be general enough, and they may behave badly when used in ways for which they were not intended, even if those ways make sense. And people took exception to "just growed" and converted it to "just grown"! Not just a lack of humour, but also a lack of understanding of literature and grammar. Somehow people take things too seriously nowadays. 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 norman at oclsc.org Wed Mar 10 02:21:28 2021 From: norman at oclsc.org (Norman Wilson) Date: Tue, 9 Mar 2021 11:21:28 -0500 (EST) Subject: [TUHS] manual humour (was tunefs -m 5%) Message-ID: <20210309162128.692CF640CB6@lignose.oclsc.org> In the Seventh Edition manual, a joke was added to the entry for kill(1). It appears in every following Research manual, but seems to have been discarded by all modern descendants. I guess the prejudice against humour in the manual is extreme these days. Norman Wilson Toronto ON From henry.r.bent at gmail.com Wed Mar 10 06:11:32 2021 From: henry.r.bent at gmail.com (Henry Bent) Date: Tue, 9 Mar 2021 15:11:32 -0500 Subject: [TUHS] manual humour (was tunefs -m 5%) In-Reply-To: <20210309162128.692CF640CB6@lignose.oclsc.org> References: <20210309162128.692CF640CB6@lignose.oclsc.org> Message-ID: -.TH KILL 1 -.SH NAME -kill \- terminate a process with extreme prejudice One of my favorite references. At least the offensive fortunes still survive in some form? -Henry On Tue, 9 Mar 2021 at 11:24, Norman Wilson wrote: > In the Seventh Edition manual, a joke was added to > the entry for kill(1). It appears in every following > Research manual, but seems to have been discarded > by all modern descendants. > > I guess the prejudice against humour in the manual > is extreme these days. > > Norman Wilson > Toronto ON > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Wed Mar 10 06:22:55 2021 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 09 Mar 2021 21:22:55 +0100 Subject: [TUHS] manual humour (was tunefs -m 5%) In-Reply-To: References: <20210309162128.692CF640CB6@lignose.oclsc.org> Message-ID: <20210309202255.3doIj%steffen@sdaoden.eu> Henry Bent wrote in : |-.TH KILL 1 |-.SH NAME |-kill \- terminate a process with extreme prejudice | |One of my favorite references. | |At least the offensive fortunes still survive in some form? People do not have time to read such offensive terms, they bath in blood while playing Counter Strike (or another first person shooter), having their double quarter pounder at hand. --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 henry.r.bent at gmail.com Wed Mar 10 06:36:50 2021 From: henry.r.bent at gmail.com (Henry Bent) Date: Tue, 9 Mar 2021 15:36:50 -0500 Subject: [TUHS] manual humour (was tunefs -m 5%) In-Reply-To: <20210309202255.3doIj%steffen@sdaoden.eu> References: <20210309162128.692CF640CB6@lignose.oclsc.org> <20210309202255.3doIj%steffen@sdaoden.eu> Message-ID: On Tue, 9 Mar 2021 at 15:22, Steffen Nurpmeso wrote: > Henry Bent wrote in > : > |-.TH KILL 1 > |-.SH NAME > |-kill \- terminate a process with extreme prejudice > | > |One of my favorite references. > | > |At least the offensive fortunes still survive in some form? > > People do not have time to read such offensive terms, they bath in > blood while playing Counter Strike (or another first person > shooter), having their double quarter pounder at hand. > Indeed. I think many people have been teenagers and been that person in some form or another, but outgrowing a phase of life doesn't mean forgetting or ignoring it. A quick grep through the CSRG CDs revealed that the phrase survived in 32v, as well as in some form of BSDs up to 4.3-Tahoe. mh also had a variant of it (wow, the irony...). -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Wed Mar 10 08:30:46 2021 From: robpike at gmail.com (Rob Pike) Date: Wed, 10 Mar 2021 09:30:46 +1100 Subject: [TUHS] manual humour (was tunefs -m 5%) In-Reply-To: References: <20210309162128.692CF640CB6@lignose.oclsc.org> <20210309202255.3doIj%steffen@sdaoden.eu> Message-ID: I'm curious when people (other than me) erred and stopped saying that ed was the standard editor. -rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Wed Mar 10 08:46:36 2021 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 9 Mar 2021 14:46:36 -0800 Subject: [TUHS] manual humour (was tunefs -m 5%) In-Reply-To: References: <20210309162128.692CF640CB6@lignose.oclsc.org> <20210309202255.3doIj%steffen@sdaoden.eu> Message-ID: <20210309224636.GY17304@mcvoy.com> ed was my goto over any modem, it's very undemanding in terms of characters transferred. Can't tell you how many times I've done ed foo.c /^some_function 20p goto the line c whatever . w q So a lot of use so long as I was using dial up, some continued use when I was doing bring up and the tty driver was all screwed up so you are typing at some slow console. Once performance wasn't an issue, it was vi all the time. I did a year in emacs, never warmed up to it, I know some people love it, I MUCH preferred the way vi works. So back to vi, some time spent in xvi because I was on 4MB main memory Sun machines so I made a version of libc that treated \n like normal libc treats \0, then changed xvi so it used mmap(2) to map the file instead of reading it in and strdup()ing every line. I did that because I was looking at performance logs and the very most I could fit into memory was 1/2 of what I could fit into memory with mmap(). That 2x bigger was a big deal to me, I was in out of those logs all the time. xvi also had buffers, like emacs, you could be looking at 2 files at once or 2 different regions of the same file. Then vim came along and it had everything I wanted and I didn't have to support it so I have been in vim since 1996 (that's the last time the xvi source that I have was touched). If things get wonky, ed still works, which is pleasant. But 99.9% of the time I'm in vim, I'm in it right now, typing this. I still use mutt(1) as my mail reader and I wacked it to drop me into vim. On Wed, Mar 10, 2021 at 09:30:46AM +1100, Rob Pike wrote: > I'm curious when people (other than me) erred and stopped saying that ed > was the standard editor. > > -rob -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From usotsuki at buric.co Wed Mar 10 09:51:56 2021 From: usotsuki at buric.co (Steve Nickolas) Date: Tue, 9 Mar 2021 18:51:56 -0500 (EST) Subject: [TUHS] manual humour (was tunefs -m 5%) In-Reply-To: References: <20210309162128.692CF640CB6@lignose.oclsc.org> <20210309202255.3doIj%steffen@sdaoden.eu> Message-ID: On Wed, 10 Mar 2021, Rob Pike wrote: > I'm curious when people (other than me) erred and stopped saying that ed > was the standard editor. > > -rob > I actually use that expression in somewhat unorthodox ways. ;) Like "CDE is the standard desktop environment like ed is the standard text editor." (I still consider both to be true even though about no one uses either anymore.) -uso. From robpike at gmail.com Wed Mar 10 10:01:43 2021 From: robpike at gmail.com (Rob Pike) Date: Wed, 10 Mar 2021 11:01:43 +1100 Subject: [TUHS] manual humour (was tunefs -m 5%) In-Reply-To: References: <20210309162128.692CF640CB6@lignose.oclsc.org> <20210309202255.3doIj%steffen@sdaoden.eu> Message-ID: The phrase disappeared from the manuals at some point. I might have committed the offense myself: The Research Unix manuals all continue the phrase, but the Plan 9 ones say: ED(1) ED(1) NAME ed - text editor SYNOPSIS ed [ - ] [ -o ] [ file ] DESCRIPTION Ed is a venerable text editor. I likely made the "venerable" substitution. I regret that now. Ed is the standard editor. -rob On Wed, Mar 10, 2021 at 10:53 AM Steve Nickolas wrote: > On Wed, 10 Mar 2021, Rob Pike wrote: > > > I'm curious when people (other than me) erred and stopped saying that ed > > was the standard editor. > > > > -rob > > > > I actually use that expression in somewhat unorthodox ways. ;) > > Like "CDE is the standard desktop environment like ed is the standard text > editor." (I still consider both to be true even though about no one uses > either anymore.) > > -uso. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ality at pbrane.org Wed Mar 10 10:13:14 2021 From: ality at pbrane.org (Anthony Martin) Date: Tue, 9 Mar 2021 16:13:14 -0800 Subject: [TUHS] manual humour (was tunefs -m 5%) In-Reply-To: References: <20210309162128.692CF640CB6@lignose.oclsc.org> <20210309202255.3doIj%steffen@sdaoden.eu> Message-ID: Rob Pike once said: > I likely made the "venerable" substitution. I regret that now. 9front is carrying the torch. changeset: 4289:e62c2add78cd parent: 4287:cc0dd57e33f1 user: khm date: Fri Feb 20 15:09:25 2015 -0500 files: sys/man/1/ed description: restore balance to reality diff --git a/sys/man/1/ed b/sys/man/1/ed --- a/sys/man/1/ed +++ b/sys/man/1/ed @@ -14,7 +14,7 @@ ] .SH DESCRIPTION .I Ed -is a venerable text editor. +is the standard text editor. .PP If a .I file From cym224 at gmail.com Wed Mar 10 12:34:34 2021 From: cym224 at gmail.com (Nemo Nusquam) Date: Tue, 9 Mar 2021 21:34:34 -0500 Subject: [TUHS] manual humour (was tunefs -m 5%) In-Reply-To: References: <20210309162128.692CF640CB6@lignose.oclsc.org> <20210309202255.3doIj%steffen@sdaoden.eu> Message-ID: On 2021-03-09 17:30, Rob Pike wrote: > I'm curious when people (other than me) erred and stopped saying that > ed was the standard editor. > > -rob > Ed, man! !man, ed. ( Sorry -- I could not resist. N. ) From andreas.kahari at abc.se Thu Mar 11 04:37:33 2021 From: andreas.kahari at abc.se (Andreas Kusalananda =?utf-8?B?S8OkaMOkcmk=?=) Date: Wed, 10 Mar 2021 19:37:33 +0100 Subject: [TUHS] manual humour (was tunefs -m 5%) In-Reply-To: References: <20210309162128.692CF640CB6@lignose.oclsc.org> <20210309202255.3doIj%steffen@sdaoden.eu> Message-ID: <20210310183733.GA14019@box.prefix.duckdns.org> On Tue, Mar 09, 2021 at 06:51:56PM -0500, Steve Nickolas wrote: > On Wed, 10 Mar 2021, Rob Pike wrote: > > > I'm curious when people (other than me) erred and stopped saying that ed > > was the standard editor. > > > > -rob > > > > I actually use that expression in somewhat unorthodox ways. ;) > > Like "CDE is the standard desktop environment like ed is the standard text > editor." (I still consider both to be true even though about no one uses > either anymore.) > > -uso. Hi, I'm "about no one". I use ed(1) every once in a while, both the way it was supposed to be used, i.e. interactively, and occasionally scripted on smaller documents. I'm soon 50. Having grown up with computers, and having spent most of my money as a student buying the next bigger and/or faster PC, I find that I nowadays enjoy smaller, slower systems and simpler editors more and more. Getting distracted by syntax highligting, confused by too complicated configurations... There is a certain beauty in the editing language of ed(1). It's minimalistic and restrictive, and therefore forces you to think, to remember, and to be creative. One of my big sorrows is not *having* to deal with ed(1) as a youngster or student, over slow modem links. I think I would appreciate Unix even more now if I had. I was born one or two decades too late. ed(1) is still the standard editor though, and so is ex(1) and vi(1), at least if POSIX is to be believed :-) -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden . From akosela at andykosela.com Thu Mar 11 05:49:23 2021 From: akosela at andykosela.com (Andy Kosela) Date: Wed, 10 Mar 2021 20:49:23 +0100 Subject: [TUHS] manual humour (was tunefs -m 5%) In-Reply-To: <20210310183733.GA14019@box.prefix.duckdns.org> References: <20210309162128.692CF640CB6@lignose.oclsc.org> <20210309202255.3doIj%steffen@sdaoden.eu> <20210310183733.GA14019@box.prefix.duckdns.org> Message-ID: On 3/10/21, Andreas Kusalananda Kähäri wrote: > On Tue, Mar 09, 2021 at 06:51:56PM -0500, Steve Nickolas wrote: >> On Wed, 10 Mar 2021, Rob Pike wrote: >> >> > I'm curious when people (other than me) erred and stopped saying that >> > ed >> > was the standard editor. >> > >> > -rob >> > >> >> I actually use that expression in somewhat unorthodox ways. ;) >> >> Like "CDE is the standard desktop environment like ed is the standard >> text >> editor." (I still consider both to be true even though about no one uses >> either anymore.) >> >> -uso. > > Hi, I'm "about no one". I use ed(1) every once in a while, both the > way it was supposed to be used, i.e. interactively, and occasionally > scripted on smaller documents. > > I'm soon 50. Having grown up with computers, and having spent most of > my money as a student buying the next bigger and/or faster PC, I find > that I nowadays enjoy smaller, slower systems and simpler editors more > and more. Getting distracted by syntax highligting, confused by too > complicated configurations... There is a certain beauty in the editing > language of ed(1). It's minimalistic and restrictive, and therefore > forces you to think, to remember, and to be creative. This comment resonates with me so much. I am enjoying these days mostly retro systems too -- computers I grew up with. There is a certain beauty in the term "less is more". And nothing is more satisfying than sitting in front of a CRT terminal (either some real terminal or PC) and working in a full screen text mode. No GUIs, no distractions -- just pure conversation with a machine using only text. That's UNIX for me. These days there have been a huge resurgence of various retro communities around the world. There are still tons of new programs and games being published for 8-bit micro's or Amiga's. Still it appears the Unix community in general is not part of that movement. I think TUHS is an exception and a haven for people who just prefer the old ways. I find Unix these days too bloated and moved away from its main core values: simplicity and minimalism. The hardware was much simpler too back in the days. Long live the ed(1) and vi(1). --Andy From kenbob at gmail.com Thu Mar 11 06:17:35 2021 From: kenbob at gmail.com (Ken Thompson) Date: Wed, 10 Mar 2021 12:17:35 -0800 Subject: [TUHS] manual humour (was tunefs -m 5%) In-Reply-To: References: <20210309162128.692CF640CB6@lignose.oclsc.org> <20210309202255.3doIj%steffen@sdaoden.eu> <20210310183733.GA14019@box.prefix.duckdns.org> Message-ID: back to original title - manual humour. my favorite was in the "form" command. -- credit to mcilroy. "If one of the special characters [{]}\ is preceded by a \, it loses its special character." On Wed, Mar 10, 2021 at 11:50 AM Andy Kosela wrote: > On 3/10/21, Andreas Kusalananda Kähäri wrote: > > On Tue, Mar 09, 2021 at 06:51:56PM -0500, Steve Nickolas wrote: > >> On Wed, 10 Mar 2021, Rob Pike wrote: > >> > >> > I'm curious when people (other than me) erred and stopped saying that > >> > ed > >> > was the standard editor. > >> > > >> > -rob > >> > > >> > >> I actually use that expression in somewhat unorthodox ways. ;) > >> > >> Like "CDE is the standard desktop environment like ed is the standard > >> text > >> editor." (I still consider both to be true even though about no one uses > >> either anymore.) > >> > >> -uso. > > > > Hi, I'm "about no one". I use ed(1) every once in a while, both the > > way it was supposed to be used, i.e. interactively, and occasionally > > scripted on smaller documents. > > > > I'm soon 50. Having grown up with computers, and having spent most of > > my money as a student buying the next bigger and/or faster PC, I find > > that I nowadays enjoy smaller, slower systems and simpler editors more > > and more. Getting distracted by syntax highligting, confused by too > > complicated configurations... There is a certain beauty in the editing > > language of ed(1). It's minimalistic and restrictive, and therefore > > forces you to think, to remember, and to be creative. > > This comment resonates with me so much. I am enjoying these days > mostly retro systems too -- computers I grew up with. There is a > certain beauty in the term "less is more". And nothing is more > satisfying than sitting in front of a CRT terminal (either some real > terminal or PC) and working in a full screen text mode. No GUIs, no > distractions -- just pure conversation with a machine using only text. > That's UNIX for me. > > These days there have been a huge resurgence of various retro > communities around the world. There are still tons of new programs > and games being published for 8-bit micro's or Amiga's. Still it > appears the Unix community in general is not part of that movement. I > think TUHS is an exception and a haven for people who just prefer the > old ways. I find Unix these days too bloated and moved away from its > main core values: simplicity and minimalism. The hardware was much > simpler too back in the days. > > Long live the ed(1) and vi(1). > > --Andy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Thu Mar 11 06:30:18 2021 From: robpike at gmail.com (Rob Pike) Date: Thu, 11 Mar 2021 07:30:18 +1100 Subject: [TUHS] manual humour (was tunefs -m 5%) In-Reply-To: References: <20210309162128.692CF640CB6@lignose.oclsc.org> <20210309202255.3doIj%steffen@sdaoden.eu> <20210310183733.GA14019@box.prefix.duckdns.org> Message-ID: For the kids on my lawn, ed(1) is a whole man page of humor. I thought that "special character" trope was written by dmr. He certainly loved it. Also didn't it originate in something about regular expressions, like the ed or grep page? Doug can confirm. -rob On Thu, Mar 11, 2021 at 7:18 AM Ken Thompson wrote: > > back to original title - manual humour. > my favorite was in the "form" command. > -- credit to mcilroy. > > "If one of the special characters [{]}\ is preceded > by a \, it loses its special character." > > > On Wed, Mar 10, 2021 at 11:50 AM Andy Kosela > wrote: > >> On 3/10/21, Andreas Kusalananda Kähäri wrote: >> > On Tue, Mar 09, 2021 at 06:51:56PM -0500, Steve Nickolas wrote: >> >> On Wed, 10 Mar 2021, Rob Pike wrote: >> >> >> >> > I'm curious when people (other than me) erred and stopped saying that >> >> > ed >> >> > was the standard editor. >> >> > >> >> > -rob >> >> > >> >> >> >> I actually use that expression in somewhat unorthodox ways. ;) >> >> >> >> Like "CDE is the standard desktop environment like ed is the standard >> >> text >> >> editor." (I still consider both to be true even though about no one >> uses >> >> either anymore.) >> >> >> >> -uso. >> > >> > Hi, I'm "about no one". I use ed(1) every once in a while, both the >> > way it was supposed to be used, i.e. interactively, and occasionally >> > scripted on smaller documents. >> > >> > I'm soon 50. Having grown up with computers, and having spent most of >> > my money as a student buying the next bigger and/or faster PC, I find >> > that I nowadays enjoy smaller, slower systems and simpler editors more >> > and more. Getting distracted by syntax highligting, confused by too >> > complicated configurations... There is a certain beauty in the editing >> > language of ed(1). It's minimalistic and restrictive, and therefore >> > forces you to think, to remember, and to be creative. >> >> This comment resonates with me so much. I am enjoying these days >> mostly retro systems too -- computers I grew up with. There is a >> certain beauty in the term "less is more". And nothing is more >> satisfying than sitting in front of a CRT terminal (either some real >> terminal or PC) and working in a full screen text mode. No GUIs, no >> distractions -- just pure conversation with a machine using only text. >> That's UNIX for me. >> >> These days there have been a huge resurgence of various retro >> communities around the world. There are still tons of new programs >> and games being published for 8-bit micro's or Amiga's. Still it >> appears the Unix community in general is not part of that movement. I >> think TUHS is an exception and a haven for people who just prefer the >> old ways. I find Unix these days too bloated and moved away from its >> main core values: simplicity and minimalism. The hardware was much >> simpler too back in the days. >> >> Long live the ed(1) and vi(1). >> >> --Andy >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggm at algebras.org Thu Mar 11 13:54:39 2021 From: ggm at algebras.org (George Michaelson) Date: Thu, 11 Mar 2021 13:54:39 +1000 Subject: [TUHS] manual humour (was tunefs -m 5%) In-Reply-To: References: <20210309162128.692CF640CB6@lignose.oclsc.org> <20210309202255.3doIj%steffen@sdaoden.eu> <20210310183733.GA14019@box.prefix.duckdns.org> Message-ID: I Still use ed periodically. Less often, but sometimes. Sometimes, its for nostalgia. It never lasts. The past isn't as rosy as we like to think it was. You have to be very confident you know what your doing, to not wind up saying p a lot, to "see" it. It demands you think. Sometimes, it's for functionality. You kind of know you could do this in sed, but, you aren't 100% sure, ed means you can "look" at some /match lines and then craft the s/pat/repl/ and wq and go home. Thats kind of using p too. Sometimes, it's for expediency. You stuffed up. Nothing else seems to work. This editor works. Hammer, screw.. good enough. Ed can cope with very large data better than some alternatives. Less litter. I hate finding .swp files and vi -r is frankly disgusting. Its indeterminite what it is r(ecovering) from. don't get me started on #file or file~ trash either. I loved ed, and I lived in ed far more than ex/vi until about 1985/6 when something flipped. I think its possible, that vi muscle memory took over, and jove/gosmacs/emacs became too confusing (I had flirted with this but not coding LISP made it silly, I was really only using the keystroke-recording macro to do dirty edits by "yea, same as the last time" tricks) Mike Lesk showed me MGR. I actually got really depressed at that point. I felt like I'd been working under a rock, not understanding what was possible. Sunview kind of also sucked me in, with an emphasis on Sucked because it did. Not really about the editor, but the whole "ok THIS is what efficient looks like" combined with tiling and other things, it just made ed sort-of walk into the background a bit. Hard to focus when you're being offered a vision of 4D hypercube projected onto a 2D surface. I didn't stick on MGR. It was too off-beam of what other people around me were doing. I was asked if I could fix some minor nits in it, thats when I realised I lacked fundamental clue (it is also why I seem to be the only person I know who doesn't totally hate the idea of the google 'be this smart to enter' testing: It obviously DOES work to weed some people out) Socialised aspects of "what editor do you use" can't be under-estimated, for anyone who is essentially using tools not writing them. If you wrote an editor, you probably got to the right place faster. If you use one, you wind up being 10 years in before you ask yourself "how does infinite undo work really" and learn about things like Merkle trees or whatever. Editors do a lot. -G From will.senn at gmail.com Thu Mar 11 14:57:55 2021 From: will.senn at gmail.com (Will Senn) Date: Wed, 10 Mar 2021 22:57:55 -0600 Subject: [TUHS] manual humour (was tunefs -m 5%) In-Reply-To: References: <20210309162128.692CF640CB6@lignose.oclsc.org> <20210309202255.3doIj%steffen@sdaoden.eu> <20210310183733.GA14019@box.prefix.duckdns.org> Message-ID: On 3/10/21 9:54 PM, George Michaelson wrote: > I Still use ed periodically. Less often, but sometimes. > > Thanks for reflecting on ed. It was interesting to hear your perspective. I love ed. I was only introduced to it a little over 6 years or so ago, but it's a beautiful thing. Of course, I use vi as my command line editor of choice :), but that doesn't diminish my enjoyment of using ed. I'm just way more comfortable in vi/vim. Interestingly, when I first learned there was such a thing as ed, I just figured it was unix's version of edlin, thankfully this wasn't even close to reality. Ed's regex support seems to be very straightforward yet quite powerful, and the small command set makes it simple to remember. - will From m.douglas.mcilroy at dartmouth.edu Fri Mar 12 01:06:32 2021 From: m.douglas.mcilroy at dartmouth.edu (M Douglas McIlroy) Date: Thu, 11 Mar 2021 10:06:32 -0500 Subject: [TUHS] Fred Grampp Message-ID: In all that's been written about the Research Unix players, Fred Grampp has gotten far less coverage than he deserves. I hope to rectify that with this post, most of which was written soon after his death. Doug During Fred's long career at Bell Laboratories, his coworkers were delighted to work with him, primarily because of his innovative and often surprising ways of attacking problems. Fred's unique approach was by no means limited to work-related matters. Fred arranged an annual canoe-camping trip on the Delaware River replete with nearly professional grade fireworks. He also arranged a number of trips to New York City (referred to as culture nights) which included, among other things, trips to the planetarium and visits to various tea rooms. To his friends at Bell Labs, Fred Grampp was a true original. He knew the urban community of small, scrabbling business as well as the pampered life of industrial research in the country's greatest industrial research lab. And he brought the best of each to his approach to work. In his father's hardware store, Fred learned on the front line what "customer-oriented" meant--a far cry from the hypothetical nonsense on the subject put forth by flacks in a modern PR department, or by CEO Bob Allen thinking big thoughts on the golf course. Fred ran the computing facilities for the Computer Science Research Center. He had his finger on the pulse of the machinery at all hours of day and night. He and his colleague Ed Sitar rose early to pat the hardware and assure that everything was in order just as had been done at the hardware store. The rest of us, who kept more nerdish hours, could count on everything running. Packed with equipment, the machine room depended on air conditioning. Fred saw this as a threat to dependable service. As a backup, he had big galvanized barn fans installed in several windows--incongruous, but utterly practical. And they saw actual use on at least one occasion. Fred cooked up ingenious software to sniff the computers' health and sound alarms in his office and even by his bed when something was amiss. When a user found something wrong and popped into Fred's office to report the trouble, more often than not he'd find Fred already working on it. With his street smarts, Fred was ahead of the game when computer intrusion began to become a problem in the 1970s. He was a real white-hat marshall, who could read the the bad guys' minds and head them off at the pass. With Bob Morris, Fred wrote a paper to alert system administrators to the kinds of lapse of vigilance that leave them open to attack; the paper is still read as a classic. Other sage advice was put forth by Fred in collaboration with G. R. Emlin, who would become an important adjunct member of the lab, as several TUHS posts attest. Quietly he developed a suite of programs that probed a computer's defenses--fortunately before the bad guys really got geared up to do the same. That work led to the creation of a whole department that used Fred's methods to assess and repair the security of thousands of computers around Bell Labs. Fred's avocations of flying and lock-picking lent spice to life in the Labs. He was a central figure of the "computer science airforce" that organized forays to see fall colors, or to witness an eclipse. He joined Ken Thompson, who also flew in the department air force, on a trip to Russia to fly a MIG-29. Ken tells the story at cs.bell-labs.com/ken/mig.html. Fred's passion for opera was communicated to many. It was he who put the Met schedule on line for us colleagues long before the Met discovered the World Wide Web. He'd press new recordings on us to whet our appetites. He'd recount, or take us to, rehearsals and backstage visits, and furnish us with librettos. When CDs appeared on the scene, Fred undertook to build a systematic collection of opera recordings, which grew to over two hundred works. They regularly played quietly in the background of his office. To Fred the opera was an essential part of life, not just an expensive night on the town. Fred's down-to-earth approach lightened life at Bell Labs. When workmen were boarding up windows to protect them from some major construction--and incidentally to prevent us from enjoying the spectacle of ironworkers outside. Fred posted a little sign in his window to the effect that if the plywood happened to get left off, a case of Bud might appear on the sill. For the next year, we had a close-up view of the action. Fred, a graduate of Stevens Institute, began his career in the computer center, under the leadership of George Baldwin, perhaps the most affable and civic-minded mathematician I have ever met. At the end of one trying day, George wandered into Fred's office, leaned back in the visitor chair, and said, "I sure could use a cold one about now." Fred opened his window and retrieved a Bud that was cooling on the sill. Fred lived his whole life in Elizabeth, New Jersey. At one point he decided that for exercise he could get to the Labs by train to Scotch Plains and bike from there up to Bell Labs--no mean feat, for the labs sat atop the second range of the Watchung Mountains, two steep climbs away from Scotch Plains. He invested in a folding bike for the purpose. Some days into the new routine a conductor called him out for bringing a bicycle onto the train. Fred had looked forward to this moment. He reached into his pocket, pulled out a timetable and pointed to the fine print: bicycles were prohibited with the exception of folding bikes. Originally dated October 25, 2000. Lightly edited and three paragraphs added February 22, 2021. -------------- next part -------------- An HTML attachment was scrubbed... URL: From halbert at halwitz.org Fri Mar 12 01:26:11 2021 From: halbert at halwitz.org (Dan Halbert) Date: Thu, 11 Mar 2021 10:26:11 -0500 Subject: [TUHS] non-UNIX timesharing at Bell Labs ca 1972? Message-ID: <29c33f36-96f5-b1b8-7c24-7198ca309052@halwitz.org> In 1972, while in high school, I went to an Intel seminar on the 8008. There I met a Bell Labs scientist who gave me a sample 8008 and invited me for a visit at some NJ Bell Labs facility. That group had a timesharing system of some kind, but it was not Unix. I was also given a Bell Labs speech synthesis kit after meeting one of the speech scientists who happened to be in on the same Saturday. I have searched my attic but can't find further details. Would any of you alumni recall what this other timesharing system might have been? Dan From andrew at humeweb.com Fri Mar 12 01:31:47 2021 From: andrew at humeweb.com (Andrew Hume) Date: Thu, 11 Mar 2021 07:31:47 -0800 Subject: [TUHS] Fred Grampp In-Reply-To: References: Message-ID: <121E36A0-4D3D-42AD-A89A-E72FBDD32E39@humeweb.com> fred was certainly a character. perhaps ken or rob might confirm this, but i recall at least one of the canoe trips demonstrated the effects of dropping flour sacks onto canoes from a small airplane. (i was not present on any of these trips, but heard this from grampp.) he was also responsible for occasionally buying bulk bags of barely digestible cheese crackers (we called them cheese awfuls) and leaving them in the Unix Room to be eaten. > On Mar 11, 2021, at 7:06 AM, M Douglas McIlroy wrote: > > In all that's been written about the Research Unix players, > Fred Grampp has gotten far less coverage than he deserves. > I hope to rectify that with this post, most of which was > written soon after his death. > From m.douglas.mcilroy at dartmouth.edu Fri Mar 12 02:13:07 2021 From: m.douglas.mcilroy at dartmouth.edu (M Douglas McIlroy) Date: Thu, 11 Mar 2021 11:13:07 -0500 Subject: [TUHS] Fred Grampp In-Reply-To: <121E36A0-4D3D-42AD-A89A-E72FBDD32E39@humeweb.com> References: <121E36A0-4D3D-42AD-A89A-E72FBDD32E39@humeweb.com> Message-ID: Ah, yes. Fred would pick things up at the Keebler Baking factory outlet on his way to work. We called it the "used cookie store". On Thu, Mar 11, 2021 at 10:31 AM Andrew Hume wrote: > fred was certainly a character. > > perhaps ken or rob might confirm this, but i recall at least one of the > canoe trips demonstrated > the effects of dropping flour sacks onto canoes from a small airplane. (i > was not present on any > of these trips, but heard this from grampp.) > > he was also responsible for occasionally buying bulk bags of barely > digestible cheese crackers > (we called them cheese awfuls) and leaving them in the Unix Room to be > eaten. > > > On Mar 11, 2021, at 7:06 AM, M Douglas McIlroy < > m.douglas.mcilroy at dartmouth.edu> wrote: > > > > In all that's been written about the Research Unix players, > > Fred Grampp has gotten far less coverage than he deserves. > > I hope to rectify that with this post, most of which was > > written soon after his death. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From m at blat.at Fri Mar 12 03:00:20 2021 From: m at blat.at (Mike Knell) Date: Thu, 11 Mar 2021 18:00:20 +0100 Subject: [TUHS] non-UNIX timesharing at Bell Labs ca 1972? In-Reply-To: <29c33f36-96f5-b1b8-7c24-7198ca309052@halwitz.org> References: <29c33f36-96f5-b1b8-7c24-7198ca309052@halwitz.org> Message-ID: <32AC3AC9-1C57-49A0-8F94-742E9D06FAD9@blat.at> > On 11.03.2021, at 16:26, Dan Halbert wrote: > > In 1972, while in high school, I went to an Intel seminar on the 8008. There I met a Bell Labs scientist who gave me a sample 8008 and invited me for a visit at some NJ Bell Labs facility. That group had a timesharing system of some kind, but it was not Unix. I was also given a Bell Labs speech synthesis kit after meeting one of the speech scientists who happened to be in on the same Saturday. I have searched my attic but can't find further details. Would any of you alumni recall what this other timesharing system might have been? Not an alumnus of anything (alas, I am far too young and not clever enough), but maybe this was GECOS? (Origin of the name of the pw_gecos field in UNIX..) Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From gtaylor at tnetconsulting.net Fri Mar 12 03:13:50 2021 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Thu, 11 Mar 2021 10:13:50 -0700 Subject: [TUHS] Pondering the hosts file Message-ID: <02d10a8e-2f39-4f88-f4c9-ecb295e0f01e@spamtrap.tnetconsulting.net> Hi, I'm not sure where this message best fits; TUHS, COFF, or Internet History, so please forgive me if this list is not the best location. I'm discussing the hosts file with someone and was wondering if there's any historical documentation around it's format and what should and should not be entered in the file. I've read the current man page on Gentoo Linux, but suspect that it's far from authoritative. I'm hoping that someone can point me to something more authoritative to the hosts file's format, guidelines around entering data, and how it's supposed to function. A couple of sticking points in the other discussion revolve around how many entries a host is supposed to have in the hosts file and any ramifications for having a host appear as an alias on multiple lines / entries. To whit, how correct / incorrect is the following: 192.0.2.1 host.example.net host 127.0.0.1 localhost host.example.net host -- 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 steffen at sdaoden.eu Fri Mar 12 03:29:23 2021 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 11 Mar 2021 18:29:23 +0100 Subject: [TUHS] [COFF] Pondering the hosts file In-Reply-To: <02d10a8e-2f39-4f88-f4c9-ecb295e0f01e@spamtrap.tnetconsulting.net> References: <02d10a8e-2f39-4f88-f4c9-ecb295e0f01e@spamtrap.tnetconsulting.net> Message-ID: <20210311172923.3f-gd%steffen@sdaoden.eu> Grant Taylor wrote in <02d10a8e-2f39-4f88-f4c9-ecb295e0f01e at spamtrap.tnetconsulting.net>: |Hi, | |I'm not sure where this message best fits; TUHS, COFF, or Internet |History, so please forgive me if this list is not the best location. | |I'm discussing the hosts file with someone and was wondering if there's |any historical documentation around it's format and what should and |should not be entered in the file. | |I've read the current man page on Gentoo Linux, but suspect that it's |far from authoritative. I'm hoping that someone can point me to |something more authoritative to the hosts file's format, guidelines |around entering data, and how it's supposed to function. | |A couple of sticking points in the other discussion revolve around how |many entries a host is supposed to have in the hosts file and any |ramifications for having a host appear as an alias on multiple lines / |entries. To whit, how correct / incorrect is the following: | |192.0.2.1 host.example.net host |127.0.0.1 localhost host.example.net host Address, "official name", aliases. And as many as you want i'd say. It is just that an alias might be hidden and never be found (if actually hidden). This is at least how i interpreted it. --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 bakul at iitbombay.org Fri Mar 12 03:40:02 2021 From: bakul at iitbombay.org (Bakul Shah) Date: Thu, 11 Mar 2021 09:40:02 -0800 Subject: [TUHS] Pondering the hosts file In-Reply-To: <02d10a8e-2f39-4f88-f4c9-ecb295e0f01e@spamtrap.tnetconsulting.net> References: <02d10a8e-2f39-4f88-f4c9-ecb295e0f01e@spamtrap.tnetconsulting.net> Message-ID: <120EC052-FB1F-438F-985F-64E9CD82A9C1@iitbombay.org> From https://www.freebsd.org/cgi/man.cgi?hosts(5) For each host a single line should be present with the following information: Internet address official host name aliases HISTORY The hosts file format appeared in 4.2BSD. > On Mar 11, 2021, at 9:14 AM, Grant Taylor via TUHS wrote: > Hi, > > I'm not sure where this message best fits; TUHS, COFF, or Internet History, so please forgive me if this list is not the best location. > > I'm discussing the hosts file with someone and was wondering if there's any historical documentation around it's format and what should and should not be entered in the file. > > I've read the current man page on Gentoo Linux, but suspect that it's far from authoritative. I'm hoping that someone can point me to something more authoritative to the hosts file's format, guidelines around entering data, and how it's supposed to function. > > A couple of sticking points in the other discussion revolve around how many entries a host is supposed to have in the hosts file and any ramifications for having a host appear as an alias on multiple lines / entries. To whit, how correct / incorrect is the following: > > 192.0.2.1 host.example.net host > 127.0.0.1 localhost host.example.net host > > > > -- > Grant. . . . > unix || die -------------- next part -------------- An HTML attachment was scrubbed... URL: From halbert at halwitz.org Fri Mar 12 03:45:55 2021 From: halbert at halwitz.org (Dan Halbert) Date: Thu, 11 Mar 2021 12:45:55 -0500 Subject: [TUHS] non-UNIX timesharing at Bell Labs ca 1972? In-Reply-To: <32AC3AC9-1C57-49A0-8F94-742E9D06FAD9@blat.at> References: <29c33f36-96f5-b1b8-7c24-7198ca309052@halwitz.org> <32AC3AC9-1C57-49A0-8F94-742E9D06FAD9@blat.at> Message-ID: <24f208ce-0050-884d-0799-d23b7f34704a@halwitz.org> On 3/11/21 12:00 PM, Mike Knell wrote: >> On 11.03.2021, at 16:26, Dan Halbert wrote: >> >> In 1972, while in high school, I went to an Intel seminar on the 8008. There I met a Bell Labs scientist who gave me a sample 8008 and invited me for a visit at some NJ Bell Labs facility. That group had a timesharing system of some kind, but it was not Unix. I was also given a Bell Labs speech synthesis kit after meeting one of the speech scientists who happened to be in on the same Saturday. I have searched my attic but can't find further details. Would any of you alumni recall what this other timesharing system might have been? > Not an alumnus of anything (alas, I am far too young and not clever enough), but maybe this was GECOS? (Origin of the name of the pw_gecos field in UNIX..) > > Mike I do not think it was GECOS. I have a memory of him demonstrating a FOCAL- or BASIC-esque language running on some commercial minicomputer, but it was not one of those and I don't think it was a DEC machine. Perhaps it was not timesharing, but he showed it to me from his office terminal, I think, not in a lab. From clemc at ccc.com Fri Mar 12 04:02:22 2021 From: clemc at ccc.com (Clem Cole) Date: Thu, 11 Mar 2021 13:02:22 -0500 Subject: [TUHS] [COFF] Pondering the hosts file In-Reply-To: <02d10a8e-2f39-4f88-f4c9-ecb295e0f01e@spamtrap.tnetconsulting.net> References: <02d10a8e-2f39-4f88-f4c9-ecb295e0f01e@spamtrap.tnetconsulting.net> Message-ID: Grant, are you asking about a multi-homed host? IIRC the original BSD code did the first hit and stop, when looking something up. What we sometimes did was give the host an alias : host-en for the ethernet and host-pro proteon HW. Host would be on both lines, so you wanted to make the first 'host' to be the default. ᐧ On Thu, Mar 11, 2021 at 12:13 PM Grant Taylor via COFF wrote: > Hi, > > I'm not sure where this message best fits; TUHS, COFF, or Internet > History, so please forgive me if this list is not the best location. > > I'm discussing the hosts file with someone and was wondering if there's > any historical documentation around it's format and what should and > should not be entered in the file. > > I've read the current man page on Gentoo Linux, but suspect that it's > far from authoritative. I'm hoping that someone can point me to > something more authoritative to the hosts file's format, guidelines > around entering data, and how it's supposed to function. > > A couple of sticking points in the other discussion revolve around how > many entries a host is supposed to have in the hosts file and any > ramifications for having a host appear as an alias on multiple lines / > entries. To whit, how correct / incorrect is the following: > > 192.0.2.1 host.example.net host > 127.0.0.1 localhost host.example.net host > > > > -- > Grant. . . . > unix || die > > _______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Fri Mar 12 04:08:03 2021 From: imp at bsdimp.com (Warner Losh) Date: Thu, 11 Mar 2021 11:08:03 -0700 Subject: [TUHS] [COFF] Pondering the hosts file In-Reply-To: <120EC052-FB1F-438F-985F-64E9CD82A9C1@iitbombay.org> References: <02d10a8e-2f39-4f88-f4c9-ecb295e0f01e@spamtrap.tnetconsulting.net> <120EC052-FB1F-438F-985F-64E9CD82A9C1@iitbombay.org> Message-ID: On Thu, Mar 11, 2021 at 10:40 AM Bakul Shah wrote: > From https://www.freebsd.org/cgi/man.cgi?hosts(5) > > For each host a single line should be present with the following information: > > Internet address > official host name > aliases > > *HISTORY* > The *hosts* file format appeared in 4.2BSD. > > While this is true wrt the history of FreeBSD/Unix, I'm almost positive that BSD didn't invent it. I'm pretty sure it was picked up from the existing host file that was published by sri-nic.arpa before DNS. Warner > On Mar 11, 2021, at 9:14 AM, Grant Taylor via TUHS > wrote: > > Hi, > > I'm not sure where this message best fits; TUHS, COFF, or Internet > History, so please forgive me if this list is not the best location. > > I'm discussing the hosts file with someone and was wondering if there's > any historical documentation around it's format and what should and should > not be entered in the file. > > I've read the current man page on Gentoo Linux, but suspect that it's far > from authoritative. I'm hoping that someone can point me to something more > authoritative to the hosts file's format, guidelines around entering data, > and how it's supposed to function. > > A couple of sticking points in the other discussion revolve around how > many entries a host is supposed to have in the hosts file and any > ramifications for having a host appear as an alias on multiple lines / > entries. To whit, how correct / incorrect is the following: > > 192.0.2.1 host.example.net host > 127.0.0.1 localhost host.example.net host > > > > -- > Grant. . . . > unix || die > > _______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Fri Mar 12 04:12:55 2021 From: clemc at ccc.com (Clem Cole) Date: Thu, 11 Mar 2021 13:12:55 -0500 Subject: [TUHS] [COFF] Pondering the hosts file In-Reply-To: References: <02d10a8e-2f39-4f88-f4c9-ecb295e0f01e@spamtrap.tnetconsulting.net> <120EC052-FB1F-438F-985F-64E9CD82A9C1@iitbombay.org> Message-ID: The SRI file was different format. There was a tool that fetched and converted from the PDP-10 scheme to the UNIX scheme - gethtable(8) or something like that. ᐧ ᐧ On Thu, Mar 11, 2021 at 1:08 PM Warner Losh wrote: > > > On Thu, Mar 11, 2021 at 10:40 AM Bakul Shah wrote: > >> From https://www.freebsd.org/cgi/man.cgi?hosts(5) >> >> For each host a single line should be present with the following information: >> >> Internet address >> official host name >> aliases >> >> *HISTORY* >> The *hosts* file format appeared in 4.2BSD. >> >> > While this is true wrt the history of FreeBSD/Unix, I'm almost positive > that BSD didn't invent it. I'm pretty sure it was picked up from the > existing host file that was published by sri-nic.arpa before DNS. > > Warner > > >> On Mar 11, 2021, at 9:14 AM, Grant Taylor via TUHS >> wrote: >> >> Hi, >> >> I'm not sure where this message best fits; TUHS, COFF, or Internet >> History, so please forgive me if this list is not the best location. >> >> I'm discussing the hosts file with someone and was wondering if there's >> any historical documentation around it's format and what should and should >> not be entered in the file. >> >> I've read the current man page on Gentoo Linux, but suspect that it's far >> from authoritative. I'm hoping that someone can point me to something more >> authoritative to the hosts file's format, guidelines around entering data, >> and how it's supposed to function. >> >> A couple of sticking points in the other discussion revolve around how >> many entries a host is supposed to have in the hosts file and any >> ramifications for having a host appear as an alias on multiple lines / >> entries. To whit, how correct / incorrect is the following: >> >> 192.0.2.1 host.example.net host >> 127.0.0.1 localhost host.example.net host >> >> >> >> -- >> Grant. . . . >> unix || die >> >> _______________________________________________ >> COFF mailing list >> COFF at minnie.tuhs.org >> https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Fri Mar 12 04:18:20 2021 From: henry.r.bent at gmail.com (Henry Bent) Date: Thu, 11 Mar 2021 13:18:20 -0500 Subject: [TUHS] [COFF] Pondering the hosts file In-Reply-To: References: <02d10a8e-2f39-4f88-f4c9-ecb295e0f01e@spamtrap.tnetconsulting.net> <120EC052-FB1F-438F-985F-64E9CD82A9C1@iitbombay.org> Message-ID: While this is true wrt the history of FreeBSD/Unix, I'm almost positive > that BSD didn't invent it. I'm pretty sure it was picked up from the > existing host file that was published by sri-nic.arpa before DNS. > > Warner > The CSRG history doesn't seem to have saved the full SCCS history of the hosts manpage, but it must have appeared sometime around the addition of ARP support to 4.1BSD - it's not in the 4.1C sources without ARP, but it is in the sources with it. That version does indeed mention its origins: HOSTS(5) File Formats Manual HOSTS(5) NAME hosts - host name data base DESCRIPTION The hosts file contains information regarding the known hosts on the DARPA Internet. For each host a single line should be present with the following information: official host name Internet address aliases Items are separated by any number of blanks and/or tab characters. A ``#'' indicates the beginning of a comment; characters up to the end of the line are not interpreted by routines which search the file. This file is normally created from the official host data base maintained at the Network Information Control Center (NIC), though local changes may be required to bring it up to date regarding unofficial aliases and/or unknown hosts. Network addresses are specified in the conventional ``.'' notation us- ing the inet_addr() routine from the Internet address manipulation li- brary, inet(3). Host names may contain any printable character other than a field delimiter, newline, or comment character. FILES /etc/hosts SEE ALSO gethostent(3N) BUGS A name server should be used instead of a static file. A binary in- dexed file format should be available for fast access. 15 January 1983 HOSTS(5) -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaapna at xs4all.nl Fri Mar 12 04:21:18 2021 From: jaapna at xs4all.nl (Jaap Akkerhuis) Date: Thu, 11 Mar 2021 19:21:18 +0100 Subject: [TUHS] [COFF] Pondering the hosts file In-Reply-To: References: <02d10a8e-2f39-4f88-f4c9-ecb295e0f01e@spamtrap.tnetconsulting.net> <120EC052-FB1F-438F-985F-64E9CD82A9C1@iitbombay.org> Message-ID: <33B7C007-DFD4-42E9-94A6-534246F3F38F@xs4all.nl> The "new" host table format is described in RFC 810 (mentions UNIX) but it goes back to RFC 608 (1974) or so. jaap > On Mar 11, 2021, at 19:12, Clem Cole wrote: > > The SRI file was different format. There was a tool that fetched and converted from the PDP-10 scheme to the UNIX scheme - gethtable(8) or something like that. > ᐧ > ᐧ > > On Thu, Mar 11, 2021 at 1:08 PM Warner Losh > wrote: > > > On Thu, Mar 11, 2021 at 10:40 AM Bakul Shah > wrote: > From https://www.freebsd.org/cgi/man.cgi?hosts(5) > For each host a single line should be present with the following information: > Internet address > official host name > aliases > HISTORY > The hosts file format appeared in 4.2BSD. > > While this is true wrt the history of FreeBSD/Unix, I'm almost positive that BSD didn't invent it. I'm pretty sure it was picked up from the existing host file that was published by sri-nic.arpa before DNS. > > Warner > >> On Mar 11, 2021, at 9:14 AM, Grant Taylor via TUHS > wrote: >> >> Hi, >> >> I'm not sure where this message best fits; TUHS, COFF, or Internet History, so please forgive me if this list is not the best location. >> >> I'm discussing the hosts file with someone and was wondering if there's any historical documentation around it's format and what should and should not be entered in the file. >> >> I've read the current man page on Gentoo Linux, but suspect that it's far from authoritative. I'm hoping that someone can point me to something more authoritative to the hosts file's format, guidelines around entering data, and how it's supposed to function. >> >> A couple of sticking points in the other discussion revolve around how many entries a host is supposed to have in the hosts file and any ramifications for having a host appear as an alias on multiple lines / entries. To whit, how correct / incorrect is the following: >> >> 192.0.2.1 host.example.net host >> 127.0.0.1 localhost host.example.net host >> >> >> >> -- >> Grant. . . . >> unix || die >> > _______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff -------------- 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 beebe at math.utah.edu Fri Mar 12 04:21:38 2021 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Thu, 11 Mar 2021 11:21:38 -0700 Subject: [TUHS] [COFF] Pondering the hosts file In-Reply-To: Message-ID: The hosts file format definition appears in RFC 752: Universal host table RFC 810: DoD Internet host table specification RFC 952: DoD Internet host table specification A 1986 hosts.txt file in my PDP-10 archives notes: ; The format for entries is: ; ; NET : NET-ADDR : NETNAME : ; GATEWAY : ADDR, ADDR : NAME : CPUTYPE : OPSYS : PROTOCOLS : ; HOST : ADDR, ALTERNATE-ADDR (if any): HOSTNAME,NICKNAME : CPUTYPE : ; OPSYS : PROTOCOLS : ; ; Where: ;; ADDR = internet address in decimal, e.g., 26.0.0.73 ;; CPUTYPE = machine type (PDP-11/70, VAX-11/780, FOONLY-F3, C/30, etc.) ;; OPSYS = operating system (UNIX, TOPS20, TENEX, ITS, etc.) ;; PROTOCOLS = transport/service (TCP/TELNET,TCP/FTP, etc.) ;; : (colon) = field delimiter ;; :: (2 colons) = null field ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From henry.r.bent at gmail.com Fri Mar 12 04:27:48 2021 From: henry.r.bent at gmail.com (Henry Bent) Date: Thu, 11 Mar 2021 13:27:48 -0500 Subject: [TUHS] [COFF] Pondering the hosts file In-Reply-To: References: <02d10a8e-2f39-4f88-f4c9-ecb295e0f01e@spamtrap.tnetconsulting.net> <120EC052-FB1F-438F-985F-64E9CD82A9C1@iitbombay.org> Message-ID: On Thu, 11 Mar 2021 at 13:14, Clem Cole wrote: > The SRI file was different format. There was a tool that fetched and > converted from the PDP-10 scheme to the UNIX scheme - gethtable(8) or > something like that. > ᐧ > ᐧ > gettable(8) and htable(8): GETTABLE(8C) GETTABLE(8C) NAME gettable - get NIC format host tables from a host SYNOPSIS /etc/gettable host DESCRIPTION Gettable is a simple program used to obtain the NIC standard host tables from a ``nicname'' server. The indicated host is queried for the tables. The tables, if retrieved, are placed in the file hosts.txt. Gettable operates by opening a TCP connection to the port indicated in the service specification for ``nicname''. A request is then made for ``ALL'' names and the resultant information is placed in the output file. Gettable is best used in conjunction with the htable(8) program which converts the NIC standard file format to that used by the network library lookup routines. SEE ALSO intro(3N), htable(8) BUGS Should allow requests for only part of the database. 4th Berkeley Distribution 4 March 1983 GETTABLE(8C) HTABLE(8) System Manager's Manual HTABLE(8) NAME htable - convert NIC standard format host tables SYNOPSIS /etc/htable file DESCRIPTION Htable is used to convert host files in the format specified in Inter- net RFC 810 to the format used by the network library routines. Three files are created as a result of running htable: hosts, networks, and gateways. The hosts file is used by the gethostent(3N) routines in mapping host names to addresses. The networks file is used by the get- netent(3N) routines in mapping network names to numbers. The gateways file is used by the routing daemon in identifying ``passive'' Internet gateways; see routed(8C) for an explanation. If any of the files localhosts, localnetworks, or localgateways are present in the current directory, the file's contents is prepended to the output file without interpretation. This allows sites to maintain local aliases and entries which are not normally present in the master database. Htable is best used in conjunction with the gettable(8C) program which retrieves the NIC database from a host. SEE ALSO intro(3N), gettable(8C) BUGS Does not properly calculate the gateways file. 4th Berkeley Distribution 4 March 1983 HTABLE(8) -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Fri Mar 12 04:30:40 2021 From: bakul at iitbombay.org (Bakul Shah) Date: Thu, 11 Mar 2021 10:30:40 -0800 Subject: [TUHS] [COFF] Pondering the hosts file Message-ID: On Mar 11, 2021, at 10:08 AM, Warner Losh wrote: > > On Thu, Mar 11, 2021 at 10:40 AM Bakul Shah wrote: >> From https://www.freebsd.org/cgi/man.cgi?hosts(5) >> For each host a single line should be present with the following information: >> Internet address >> official host name >> aliases >> HISTORY >> The hosts file format appeared in 4.2BSD. > > While this is true wrt the history of FreeBSD/Unix, I'm almost positive that BSD didn't invent it. I'm pretty sure it was picked up from the existing host file that was published by sri-nic.arpa before DNS. A different and more verbose format. See RFCs 810 & 952. Possibly because it had to serve more purposes? > Warner > >>> On Mar 11, 2021, at 9:14 AM, Grant Taylor via TUHS wrote: >>> Hi, >>> >>> I'm not sure where this message best fits; TUHS, COFF, or Internet History, so please forgive me if this list is not the best location. >>> >>> I'm discussing the hosts file with someone and was wondering if there's any historical documentation around it's format and what should and should not be entered in the file. >>> >>> I've read the current man page on Gentoo Linux, but suspect that it's far from authoritative. I'm hoping that someone can point me to something more authoritative to the hosts file's format, guidelines around entering data, and how it's supposed to function. >>> >>> A couple of sticking points in the other discussion revolve around how many entries a host is supposed to have in the hosts file and any ramifications for having a host appear as an alias on multiple lines / entries. To whit, how correct / incorrect is the following: >>> >>> 192.0.2.1 host.example.net host >>> 127.0.0.1 localhost host.example.net host >>> >>> >>> >>> -- >>> Grant. . . . >>> unix || die >> _______________________________________________ >> COFF mailing list >> COFF at minnie.tuhs.org >> https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenbob at gmail.com Fri Mar 12 05:50:31 2021 From: kenbob at gmail.com (Ken Thompson) Date: Thu, 11 Mar 2021 11:50:31 -0800 Subject: [TUHS] Fred Grampp In-Reply-To: References: <121E36A0-4D3D-42AD-A89A-E72FBDD32E39@humeweb.com> Message-ID: fred dumpster dove on the way to the labs. his prize, beside the cheese awfuls, was the bowling pins for the 6th floor bowling alley. fred was after a german ww2 enigma. he left requests at two european shops that were known to occasionally have one. when one came to light, fred and i split the price. after years of dwindling hope for another one showing up, fred an i flipped a coin to see who owned it. fred won. before his death he gave it to me. and lastly, and secret until now, fred painted the peter face on the water tower. On Thu, Mar 11, 2021 at 8:14 AM M Douglas McIlroy < m.douglas.mcilroy at dartmouth.edu> wrote: > Ah, yes. Fred would pick things up at the Keebler Baking factory outlet on > his way to work. > We called it the "used cookie store". > > On Thu, Mar 11, 2021 at 10:31 AM Andrew Hume wrote: > >> fred was certainly a character. >> >> perhaps ken or rob might confirm this, but i recall at least one of the >> canoe trips demonstrated >> the effects of dropping flour sacks onto canoes from a small airplane. (i >> was not present on any >> of these trips, but heard this from grampp.) >> >> he was also responsible for occasionally buying bulk bags of barely >> digestible cheese crackers >> (we called them cheese awfuls) and leaving them in the Unix Room to be >> eaten. >> >> > On Mar 11, 2021, at 7:06 AM, M Douglas McIlroy < >> m.douglas.mcilroy at dartmouth.edu> wrote: >> > >> > In all that's been written about the Research Unix players, >> > Fred Grampp has gotten far less coverage than he deserves. >> > I hope to rectify that with this post, most of which was >> > written soon after his death. >> > >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ality at pbrane.org Fri Mar 12 06:06:56 2021 From: ality at pbrane.org (Anthony Martin) Date: Thu, 11 Mar 2021 12:06:56 -0800 Subject: [TUHS] Fred Grampp In-Reply-To: References: <121E36A0-4D3D-42AD-A89A-E72FBDD32E39@humeweb.com> Message-ID: Ken Thompson once said: > and lastly, and secret until now, fred > painted the peter face on the water tower. At long last! Earlier hints from research!gerard: "We do know that the paint itself was vouchered a few days later as a business expense by Fred Grampp, on behalf of a pseudo-employee G.R. (Grace) Emlin (login: gremlin), who had at that time already been entered successfully into most official databases at Bell Labs, and regularly received mail at her mailbox at 2C-501 (the Unix room)." https://spinroot.com/pico/pjw.html Anthony From jschauma at netmeister.org Fri Mar 12 06:05:59 2021 From: jschauma at netmeister.org (Jan Schaumann) Date: Thu, 11 Mar 2021 15:05:59 -0500 Subject: [TUHS] [COFF] Pondering the hosts file In-Reply-To: References: Message-ID: <20210311200558.GW3990@netmeister.org> "Nelson H. F. Beebe" wrote: > The hosts file format definition appears in > > RFC 752: Universal host table > RFC 810: DoD Internet host table specification > RFC 952: DoD Internet host table specification > > A 1986 hosts.txt file in my PDP-10 archives notes: The earliest copy of the hosts file I could find was http://pdp-10.trailing-edge.com/tops20_v6_1_tcpip_installation_tp_ft6/06/new-system/hosts.txt ;GIDNEY::HOSTS.TXT.5, 27-Mar-85 13:11:54, Edit by PAETZOLD ;GIDNEY::HOSTS.TXT.4, 25-Mar-85 13:56:55, Edit by PAETZOLD ;local stuff ; DoD Internet Host Table ; 22-Mar-85 ; Version number 436 Does anybody have an earlier copy? -Jan From henry.r.bent at gmail.com Fri Mar 12 06:30:00 2021 From: henry.r.bent at gmail.com (Henry Bent) Date: Thu, 11 Mar 2021 15:30:00 -0500 Subject: [TUHS] [COFF] Pondering the hosts file In-Reply-To: <20210311200558.GW3990@netmeister.org> References: <20210311200558.GW3990@netmeister.org> Message-ID: On Thu, Mar 11, 2021, 15:12 Jan Schaumann wrote: > "Nelson H. F. Beebe" wrote: > > The hosts file format definition appears in > > > > RFC 752: Universal host table > > RFC 810: DoD Internet host table specification > > RFC 952: DoD Internet host table specification > > > > A 1986 hosts.txt file in my PDP-10 archives notes: > > The earliest copy of the hosts file I could find was > > http://pdp-10.trailing-edge.com/tops20_v6_1_tcpip_installation_tp_ft6/06/new-system/hosts.txt > > ;GIDNEY::HOSTS.TXT.5, 27-Mar-85 13:11:54, Edit by > PAETZOLD > ;GIDNEY::HOSTS.TXT.4, 25-Mar-85 13:56:55, Edit by > PAETZOLD > ;local stuff > > ; DoD Internet Host Table > ; 22-Mar-85 > ; Version number 436 > > Does anybody have an earlier copy? > > -Jan This was in the first page of Google search results for "DoD Internet Host Table"; I bet with a little more research I could come up with something much older. Or one of the PDP-10 folks will find the original... https://emaillab.jp/dns/hosts/ -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Fri Mar 12 06:30:39 2021 From: robpike at gmail.com (Rob Pike) Date: Fri, 12 Mar 2021 07:30:39 +1100 Subject: [TUHS] Fred Grampp In-Reply-To: References: <121E36A0-4D3D-42AD-A89A-E72FBDD32E39@humeweb.com> Message-ID: I don't believe the water tower was a one-person job. Fortunately I have a perfect alibi, being on the other side of the country that day. -rob On Fri, Mar 12, 2021 at 6:51 AM Ken Thompson wrote: > fred dumpster dove on the way to the labs. > his prize, beside the cheese awfuls, was > the bowling pins for the 6th floor bowling > alley. > > fred was after a german ww2 enigma. he > left requests at two european shops that > were known to occasionally have one. > when one came to light, fred and i split > the price. after years of dwindling hope > for another one showing up, fred an i > flipped a coin to see who owned it. fred > won. before his death he gave it to me. > > and lastly, and secret until now, fred > painted the peter face on the water tower. > > > > On Thu, Mar 11, 2021 at 8:14 AM M Douglas McIlroy < > m.douglas.mcilroy at dartmouth.edu> wrote: > >> Ah, yes. Fred would pick things up at the Keebler Baking factory outlet >> on his way to work. >> We called it the "used cookie store". >> >> On Thu, Mar 11, 2021 at 10:31 AM Andrew Hume wrote: >> >>> fred was certainly a character. >>> >>> perhaps ken or rob might confirm this, but i recall at least one of the >>> canoe trips demonstrated >>> the effects of dropping flour sacks onto canoes from a small airplane. >>> (i was not present on any >>> of these trips, but heard this from grampp.) >>> >>> he was also responsible for occasionally buying bulk bags of barely >>> digestible cheese crackers >>> (we called them cheese awfuls) and leaving them in the Unix Room to be >>> eaten. >>> >>> > On Mar 11, 2021, at 7:06 AM, M Douglas McIlroy < >>> m.douglas.mcilroy at dartmouth.edu> wrote: >>> > >>> > In all that's been written about the Research Unix players, >>> > Fred Grampp has gotten far less coverage than he deserves. >>> > I hope to rectify that with this post, most of which was >>> > written soon after his death. >>> > >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Fri Mar 12 06:32:52 2021 From: ron at ronnatalie.com (Ron Natalie) Date: Thu, 11 Mar 2021 20:32:52 +0000 Subject: [TUHS] [COFF] Pondering the hosts file In-Reply-To: References: <02d10a8e-2f39-4f88-f4c9-ecb295e0f01e@spamtrap.tnetconsulting.net> Message-ID: Which hosts table? The Berkeley one or the REAL internet one? The Berkeley one (which I think may predate the IP implementation) is the one that we know as /etc/hosts that has the address then the namees of the hosts. The "real" one is the one the NIC put out in the pre-domain days. It's defined in RFC 952, looks like HOST : 10.0.0.29 : BRL.ARPA, BRL : PDP-11/70 : UNIX : TCP : There was also a simple TCP service that would serve up the file. I detested the Berkeley one and we always downloaded and used the NIC table on our machines. I rewrote "rhost" and it's successors (gethostbyname, etc...) to read directly from the NIC format. Amusingly one day we got an Imagen ethernet-connected laser printer. Mike Muuss decided the thing should be named BRL-ZAP and since I didn't know what to put down as the machine type, and it did have a 68000 in it, I had Jake put 68000 in the entry in the host table. The next day I got all kinds of hate mail from other BSD sites who assumed I had intentionally sabotaged the host table. Apparently, the BSD systems used a YACC grammar to parse the NIC table into the Berkeley one. The only problem is they got the grammar wrong and assumed the CPU type always began with a letter. There parse blew up on my "ZAP" host and they assumed that was the desired effect. I countered back that using a YACC grammar for this was rediculous. There was already a real popular file on UNIX that had a bunch of fields separated by colons and commas (/etc/passwd anybody) that it was never necessary to use YACC to parse. -Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Fri Mar 12 06:42:37 2021 From: henry.r.bent at gmail.com (Henry Bent) Date: Thu, 11 Mar 2021 15:42:37 -0500 Subject: [TUHS] [COFF] Pondering the hosts file In-Reply-To: References: <20210311200558.GW3990@netmeister.org> Message-ID: On Thu, 11 Mar 2021 at 15:30, Henry Bent wrote: > On Thu, Mar 11, 2021, 15:12 Jan Schaumann wrote: > >> "Nelson H. F. Beebe" wrote: >> > The hosts file format definition appears in >> > >> > RFC 752: Universal host table >> > RFC 810: DoD Internet host table specification >> > RFC 952: DoD Internet host table specification >> > >> > A 1986 hosts.txt file in my PDP-10 archives notes: >> >> The earliest copy of the hosts file I could find was >> >> http://pdp-10.trailing-edge.com/tops20_v6_1_tcpip_installation_tp_ft6/06/new-system/hosts.txt >> >> ;GIDNEY::HOSTS.TXT.5, 27-Mar-85 13:11:54, Edit by >> PAETZOLD >> ;GIDNEY::HOSTS.TXT.4, 25-Mar-85 13:56:55, Edit by >> PAETZOLD >> ;local stuff >> >> ; DoD Internet Host Table >> ; 22-Mar-85 >> ; Version number 436 >> >> Does anybody have an earlier copy? >> >> -Jan > > > This was in the first page of Google search results for "DoD Internet Host > Table"; I bet with a little more research I could come up with something > much older. Or one of the PDP-10 folks will find the original... > > https://emaillab.jp/dns/hosts/ > > -Henry > Perhaps a more interesting question, and one which I cannot quickly answer (nor am I going to go pinging huge swaths of the public internet), is are there any hosts in any version of HOSTS.TXT that are still on the public internet in the same location? Or - and perhaps there is an easy answer to this that I do not know - is there a repository of old WHOIS databases? I remember being stymied ~20 years ago that Ultrix had SRI-NIC.ARPA hardcoded in the whois binary and I couldn't find a hostname of the correct length with which to replace it... -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Fri Mar 12 06:44:12 2021 From: lars at nocrew.org (Lars Brinkhoff) Date: Thu, 11 Mar 2021 20:44:12 +0000 Subject: [TUHS] [COFF] Pondering the hosts file In-Reply-To: <20210311200558.GW3990@netmeister.org> (Jan Schaumann's message of "Thu, 11 Mar 2021 15:05:59 -0500") References: <20210311200558.GW3990@netmeister.org> Message-ID: <7wim5x5skj.fsf@junk.nocrew.org> Jan Schaumann wrote: > The earliest copy of the hosts file I could find was > http://pdp-10.trailing-edge.com/tops20_v6_1_tcpip_installation_tp_ft6/06/new-system/hosts.txt > ; 22-Mar-85 > Does anybody have an earlier copy? MIT and Stanford PDP-10 archives have various HOSTS files going back to the mid 1970s. From bakul at iitbombay.org Fri Mar 12 07:02:50 2021 From: bakul at iitbombay.org (Bakul Shah) Date: Thu, 11 Mar 2021 13:02:50 -0800 Subject: [TUHS] [COFF] Pondering the hosts file In-Reply-To: References: <02d10a8e-2f39-4f88-f4c9-ecb295e0f01e@spamtrap.tnetconsulting.net> Message-ID: <555F9514-DD67-41F1-8151-480F0D9D0EAC@iitbombay.org> On Mar 11, 2021, at 12:32 PM, Ron Natalie wrote: > > Amusingly one day we got an Imagen ethernet-connected laser printer. Mike Muuss decided the thing should be named BRL-ZAP and since I didn't know what to put down as the machine type, and it did have a 68000 in it, I had Jake put 68000 in the entry in the host table. > > The next day I got all kinds of hate mail from other BSD sites who assumed I had intentionally sabotaged the host table. Apparently, the BSD systems used a YACC grammar to parse the NIC table into the Berkeley one. The only problem is they got the grammar wrong and assumed the CPU type always began with a letter. There parse blew up on my "ZAP" host and they assumed that was the desired effect. This is understandable as a) All the "official machine names" in various assigned numbers RFCs start with a letter. b) the BNF syntax for the "host table specification" entries in RFC 952 or 810 are not precise enough. ::= PDP-11/70 | DEC-1080 | C/30 | CDC-6400...etc. NOTE: See "Assigned Numbers" for specific options and acronyms for machine types, operating systems, and protocol/services. for machine types, operating systems, and protocol/services. c) 68000 was not an official name! :-) :-) :-) > I countered back that using a YACC grammar for this was rediculous. There was already a real popular file on UNIX that had a bunch of fields separated by colons and commas (/etc/passwd anybody) that it was never necessary to use YACC to parse. Can't argue with that! Though that doesn't mean a handwritten parser wouldn't have complained about 68000. -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Fri Mar 12 07:05:38 2021 From: henry.r.bent at gmail.com (Henry Bent) Date: Thu, 11 Mar 2021 16:05:38 -0500 Subject: [TUHS] [COFF] Pondering the hosts file In-Reply-To: <7wim5x5skj.fsf@junk.nocrew.org> References: <20210311200558.GW3990@netmeister.org> <7wim5x5skj.fsf@junk.nocrew.org> Message-ID: On Thu, 11 Mar 2021 at 16:02, Lars Brinkhoff wrote: > Jan Schaumann wrote: > > The earliest copy of the hosts file I could find was > > > http://pdp-10.trailing-edge.com/tops20_v6_1_tcpip_installation_tp_ft6/06/new-system/hosts.txt > > ; 22-Mar-85 > > Does anybody have an earlier copy? > > MIT and Stanford PDP-10 archives have various HOSTS files going back to > the mid 1970s. > Links? I have not the slightest idea where to start looking for those archives, nor would I know where to look on the filesystem even if I did find them. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Fri Mar 12 07:08:15 2021 From: ron at ronnatalie.com (Ron Natalie) Date: Thu, 11 Mar 2021 21:08:15 +0000 Subject: [TUHS] [COFF] Pondering the hosts file In-Reply-To: <555F9514-DD67-41F1-8151-480F0D9D0EAC@iitbombay.org> References: <02d10a8e-2f39-4f88-f4c9-ecb295e0f01e@spamtrap.tnetconsulting.net> <555F9514-DD67-41F1-8151-480F0D9D0EAC@iitbombay.org> Message-ID: The "name" in this context the host/network/gateway name such as SRI-NIC.ARPA. 3COM.COM would not have been legal back then. Nowhere does it imply that any of the other fields are so restricted. ------ Original Message ------ From: "Bakul Shah" To: "Ron Natalie" Cc: "The Unix Heritage Society" ; "Internet History" Sent: 3/11/2021 4:02:50 PM Subject: Re: [TUHS] [COFF] Pondering the hosts file >On Mar 11, 2021, at 12:32 PM, Ron Natalie wrote: >> >>Amusingly one day we got an Imagen ethernet-connected laser printer. >> Mike Muuss decided the thing should be named BRL-ZAP and since I >>didn't know what to put down as the machine type, and it did have a >>68000 in it, I had Jake put 68000 in the entry in the host table. >> >>The next day I got all kinds of hate mail from other BSD sites who >>assumed I had intentionally sabotaged the host table. Apparently, >>the BSD systems used a YACC grammar to parse the NIC table into the >>Berkeley one. The only problem is they got the grammar wrong and >>assumed the CPU type always began with a letter. There parse blew >>up on my "ZAP" host and they assumed that was the desired effect. > >This is understandable as >a) All the "official machine names" in various assigned numbers RFCs >start with a letter. >b) the BNF syntax for the "host table specification" entries in RFC 952 >or 810 are not precise enough. >> ::= PDP-11/70 | DEC-1080 | C/30 | CDC-6400...etc. >> >>NOTE: See "Assigned Numbers" for specific options and acronyms >> for machine types, operating systems, and protocol/services. >> >> for machine types, operating systems, and protocol/services. >> >c) 68000 was not an official name! >:-) :-) :-) > >>I countered back that using a YACC grammar for this was rediculous. >>There was already a real popular file on UNIX that had a bunch of >>fields separated by colons and commas (/etc/passwd anybody) that it >>was never necessary to use YACC to parse. > >Can't argue with that! Though that doesn't mean a handwritten parser >wouldn't have complained about 68000. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Fri Mar 12 07:12:38 2021 From: ron at ronnatalie.com (Ron Natalie) Date: Thu, 11 Mar 2021 21:12:38 +0000 Subject: [TUHS] [COFF] Pondering the hosts file In-Reply-To: <7wim5x5skj.fsf@junk.nocrew.org> References: <20210311200558.GW3990@netmeister.org> <7wim5x5skj.fsf@junk.nocrew.org> Message-ID: Ah, that brings back memories. It was after we got our own "private" imps at BRL. The BRL hosts of the day had the name BRL-XNNN where the X was the name of the division V - Vulnerability/Lethality Division S - Systems Engineering and Concepts Analysis Division T - Terminal Ballistics Division I - Interior Ballistics Division L - Launch and Flight Division. B appears becvaues SECAD was the Ballistic Modelling Division earlier. Mike wanted to callel BRL-SEM (the SECAD Experimental Machine) BRL-SEX originally. Jake Fienler at the NIC refused to accept it. From bakul at iitbombay.org Fri Mar 12 07:15:54 2021 From: bakul at iitbombay.org (Bakul Shah) Date: Thu, 11 Mar 2021 13:15:54 -0800 Subject: [TUHS] [COFF] Pondering the hosts file In-Reply-To: References: <02d10a8e-2f39-4f88-f4c9-ecb295e0f01e@spamtrap.tnetconsulting.net> <555F9514-DD67-41F1-8151-480F0D9D0EAC@iitbombay.org> Message-ID: <0690CD07-BFA1-4C65-9C6F-493C3340D559@iitbombay.org> As I quoted, the RFC says to refer to the assigned numbers RFC for specific options and acronyms for machine types, operating systems, and protocol/services. A host/network/gateway name has no such restriction. > On Mar 11, 2021, at 1:08 PM, Ron Natalie wrote: > > The "name" in this context the host/network/gateway name such as SRI-NIC.ARPA. 3COM.COM would not have been legal back then. > Nowhere does it imply that any of the other fields are so restricted. > > ------ Original Message ------ > From: "Bakul Shah" > > To: "Ron Natalie" > > Cc: "The Unix Heritage Society" >; "Internet History" > > Sent: 3/11/2021 4:02:50 PM > Subject: Re: [TUHS] [COFF] Pondering the hosts file > >> On Mar 11, 2021, at 12:32 PM, Ron Natalie > wrote: >>> >>> Amusingly one day we got an Imagen ethernet-connected laser printer. Mike Muuss decided the thing should be named BRL-ZAP and since I didn't know what to put down as the machine type, and it did have a 68000 in it, I had Jake put 68000 in the entry in the host table. >>> >>> The next day I got all kinds of hate mail from other BSD sites who assumed I had intentionally sabotaged the host table. Apparently, the BSD systems used a YACC grammar to parse the NIC table into the Berkeley one. The only problem is they got the grammar wrong and assumed the CPU type always began with a letter. There parse blew up on my "ZAP" host and they assumed that was the desired effect. >> >> This is understandable as >> a) All the "official machine names" in various assigned numbers RFCs start with a letter. >> b) the BNF syntax for the "host table specification" entries in RFC 952 or 810 are not precise enough. >> ::= PDP-11/70 | DEC-1080 | C/30 | CDC-6400...etc. >> >> NOTE: See "Assigned Numbers" for specific options and acronyms >> for machine types, operating systems, and protocol/services. >> for machine types, operating systems, and protocol/services. >> c) 68000 was not an official name! >> :-) :-) :-) >> >>> I countered back that using a YACC grammar for this was rediculous. There was already a real popular file on UNIX that had a bunch of fields separated by colons and commas (/etc/passwd anybody) that it was never necessary to use YACC to parse. >> >> Can't argue with that! Though that doesn't mean a handwritten parser wouldn't have complained about 68000. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Fri Mar 12 07:20:30 2021 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Thu, 11 Mar 2021 14:20:30 -0700 Subject: [TUHS] [COFF] Pondering the hosts file In-Reply-To: References: <02d10a8e-2f39-4f88-f4c9-ecb295e0f01e@spamtrap.tnetconsulting.net> Message-ID: Cross-posting to TUHS my original response to COFF. On 3/11/21 11:02 AM, Clem Cole wrote: > Grant, are you asking about a multi-homed host? I had specifically elided multi-homing for simplicity. > IIRC the original BSD code did the first hit and stop, when looking > something up. *nod* That's my understanding. > What we sometimes did was give the host an alias : host-en for the > ethernet and host-pro proteon HW. If I understand what you're saying: 192.0.2.1 host.example.net host-en 198.51.100.1 host.example.net host-pro > Host would be on both lines, so you wanted to make the first 'host' > to be the default. I guess I shouldn't elide multi-homing and instead address it directly. Or at least clarify the paradigm. Should a given host name appear on more than one entry / line in the hosts file if it's only got one IP (other than 127.0.0.1 / ::1)? -- 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 henry.r.bent at gmail.com Fri Mar 12 07:20:45 2021 From: henry.r.bent at gmail.com (Henry Bent) Date: Thu, 11 Mar 2021 16:20:45 -0500 Subject: [TUHS] [COFF] Pondering the hosts file In-Reply-To: References: <20210311200558.GW3990@netmeister.org> Message-ID: > Perhaps a more interesting question, and one which I cannot quickly answer > (nor am I going to go pinging huge swaths of the public internet), is are > there any hosts in any version of HOSTS.TXT that are still on the public > internet in the same location? Or - and perhaps there is an easy answer to > this that I do not know - is there a repository of old WHOIS databases? I > remember being stymied ~20 years ago that Ultrix had SRI-NIC.ARPA hardcoded > in the whois binary and I couldn't find a hostname of the correct length > with which to replace it... > > -Henry > A quick flash of inspiration revealed a partial answer to this. tick.usno.navy.mil and tock.usno.navy.mil have been 192.5.41.40 and 192.5.41.41 since 1994: https://groups.google.com/g/news.test/c/VGw06jeo2Zk/m/1oi8rsKVxrQJ . I've been relying on these for almost as long as they've been online. Unfortunately they do not show up in the 1995 HOSTS.TXT file. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman at oclsc.org Fri Mar 12 07:23:51 2021 From: norman at oclsc.org (Norman Wilson) Date: Thu, 11 Mar 2021 16:23:51 -0500 Subject: [TUHS] Fred Grampp Message-ID: <1615497835.11174.for-standards-violators@oclsc.org> Rob Pike: I don't believe the water tower was a one-person job. ==== I agree. Even if GR Emlin helped, I bet two live people were involved in painting. I'm quite sure more than that participated in making the stencil. Norman Wilson Toronto ON PS: I have never been on a water tower. From ches at cheswick.com Fri Mar 12 07:39:51 2021 From: ches at cheswick.com (William Cheswick) Date: Thu, 11 Mar 2021 16:39:51 -0500 Subject: [TUHS] Fred Grampp In-Reply-To: <1615497835.11174.for-standards-violators@oclsc.org> References: <1615497835.11174.for-standards-violators@oclsc.org> Message-ID: <4781D8B4-DECB-4B8B-A81C-B3A28F4C8658@cheswick.com> > I agree. Even if GR Emlin helped, I bet two live people > were involved in painting. It may just be a coincidence, but I have some code from Tom Duff that generates an image with AT&T logo-style stripes. > > PS: I have never been on a water tower. I have. Dropped parachutes off it with John Venutolo. ches From brantley at coraid.com Fri Mar 12 07:48:18 2021 From: brantley at coraid.com (Brantley Coile) Date: Thu, 11 Mar 2021 21:48:18 +0000 Subject: [TUHS] Fred Grampp In-Reply-To: References: Message-ID: <1E0DA413-6416-4D0A-8021-5FF12BC664D1@coraid.com> In the "15 minutes" that I worked in Center 1127, I reported to Fred. When he interviewed me for the job in his office the conversation wandered around to the German Enigma machine. "What a great thing to actually see one some day." I said. "Oh?" asked Fred, reaching down pulling open the bottom drawer of his metal desk. A tug at a fabric covered wooden box, making a sliding, banging noise on the metal draw as he withdrew it, and plopped it on the disk in front of me. Popping open the catches he lifted the lid and there was the enigmatic enigma in front of me, open for me to touch. We spent the rest of the interview with him explaining the the workings of the device. What a pleasure it was. Brantley > On Mar 11, 2021, at 10:06 AM, M Douglas McIlroy wrote: > > In all that's been written about the Research Unix players, > Fred Grampp has gotten far less coverage than he deserves. > I hope to rectify that with this post, most of which was > written soon after his death. > > Doug > > During Fred's long career at Bell Laboratories, his coworkers > were delighted to work with him, primarily because of his > innovative and often surprising ways of attacking problems. > > Fred's unique approach was by no means limited to work-related > matters. Fred arranged an annual canoe-camping trip on the > Delaware River replete with nearly professional grade fireworks. > > He also arranged a number of trips to New York City (referred > to as culture nights) which included, among other things, > trips to the planetarium and visits to various tea rooms. > > To his friends at Bell Labs, Fred Grampp was a true original. He > knew the urban community of small, scrabbling business > as well as the pampered life of industrial research in the > country's greatest industrial research lab. And he brought > the best of each to his approach to work. > > In his father's hardware store, Fred learned on the front line > what "customer-oriented" meant--a far cry from the hypothetical > nonsense on the subject put forth by flacks in a modern PR > department, or by CEO Bob Allen thinking big thoughts on the > golf course. > > Fred ran the computing facilities for the Computer Science > Research Center. He had his finger on the pulse of the machinery > at all hours of day and night. He and his colleague Ed Sitar > rose early to pat the hardware and assure that everything was > in order just as had been done at the hardware store. The rest > of us, who kept more nerdish hours, could count on everything > running. > > Packed with equipment, the machine room depended on > air conditioning. Fred saw this as a threat to dependable > service. As a backup, he had big galvanized barn fans installed > in several windows--incongruous, but utterly practical. And > they saw actual use on at least one occasion. > > Fred cooked up ingenious software to sniff the computers' > health and sound alarms in his office and even by his bed when > something was amiss. When a user found something wrong and > popped into Fred's office to report the trouble, more often > than not he'd find Fred already working on it. > > With his street smarts, Fred was ahead of the game when > computer intrusion began to become a problem in the 1970s. > He was a real white-hat marshall, who could read the the bad > guys' minds and head them off at the pass. With Bob Morris, > Fred wrote a paper to alert system administrators to the kinds > of lapse of vigilance that leave them open to attack; the paper > is still read as a classic. Other sage advice was put forth > by Fred in collaboration with G. R. Emlin, who would become an > important adjunct member of the lab, as several TUHS posts attest. > > Quietly he developed a suite of programs that probed a > computer's defenses--fortunately before the bad guys really > got geared up to do the same. That work led to the creation > of a whole department that used Fred's methods to assess and > repair the security of thousands of computers around Bell Labs. > > Fred's avocations of flying and lock-picking lent spice to > life in the Labs. He was a central figure of the "computer > science airforce" that organized forays to see fall colors, > or to witness an eclipse. He joined Ken Thompson, who also > flew in the department air force, on a trip to Russia to fly > a MIG-29. Ken tells the story at cs.bell-labs.com/ken/mig.html. > > Fred's passion for opera was communicated to many. It was > he who put the Met schedule on line for us colleagues long > before the Met discovered the World Wide Web. He'd press new > recordings on us to whet our appetites. He'd recount, or take > us to, rehearsals and backstage visits, and furnish us with > librettos. When CDs appeared on the scene, Fred undertook to > build a systematic collection of opera recordings, which grew > to over two hundred works. They regularly played quietly in the > background of his office. To Fred the opera was an essential > part of life, not just an expensive night on the town. > > Fred's down-to-earth approach lightened life at Bell Labs. When > workmen were boarding up windows to protect them from some major > construction--and incidentally to prevent us from enjoying the > spectacle of ironworkers outside. Fred posted a little sign > in his window to the effect that if the plywood happened to > get left off, a case of Bud might appear on the sill. For the > next year, we had a close-up view of the action. > > Fred, a graduate of Stevens Institute, began his career in > the computer center, under the leadership of George Baldwin, > perhaps the most affable and civic-minded mathematician I have > ever met. At the end of one trying day, George wandered into > Fred's office, leaned back in the visitor chair, and said, > "I sure could use a cold one about now." Fred opened his window > and retrieved a Bud that was cooling on the sill. > > Fred lived his whole life in Elizabeth, New Jersey. At one > point he decided that for exercise he could get to the Labs by > train to Scotch Plains and bike from there up to Bell Labs--no > mean feat, for the labs sat atop the second range of the > Watchung Mountains, two steep climbs away from Scotch Plains. > He invested in a folding bike for the purpose. Some days > into the new routine a conductor called him out for bringing > a bicycle onto the train. Fred had looked forward to this > moment. He reached into his pocket, pulled out a timetable > and pointed to the fine print: bicycles were prohibited with > the exception of folding bikes. > > Originally dated October 25, 2000. Lightly edited and three > paragraphs added February 22, 2021. > From m.douglas.mcilroy at dartmouth.edu Fri Mar 12 08:00:18 2021 From: m.douglas.mcilroy at dartmouth.edu (M Douglas McIlroy) Date: Thu, 11 Mar 2021 17:00:18 -0500 Subject: [TUHS] Fred Grampp In-Reply-To: References: <121E36A0-4D3D-42AD-A89A-E72FBDD32E39@humeweb.com> Message-ID: A few days later, GR's receipt for paint arrived on my desk for approval. That was certainly above my pay grade, so upon weighing personalities, I decided to pass it two levels up the chain of command to Vic Vyssotsky, who famously returned it with a formal note that he was not authorized to approve plant improvements. The fact that Ken was in my department and GR wasn't (nor was Fred) stoked certain suspicions about the makeup of the water-tower team. Doug On Thu, Mar 11, 2021 at 3:30 PM Rob Pike wrote: > I don't believe the water tower was a one-person job. > > Fortunately I have a perfect alibi, being on the other side of the country > that day. > > -rob > > > On Fri, Mar 12, 2021 at 6:51 AM Ken Thompson wrote: > >> fred dumpster dove on the way to the labs. >> his prize, beside the cheese awfuls, was >> the bowling pins for the 6th floor bowling >> alley. >> >> fred was after a german ww2 enigma. he >> left requests at two european shops that >> were known to occasionally have one. >> when one came to light, fred and i split >> the price. after years of dwindling hope >> for another one showing up, fred an i >> flipped a coin to see who owned it. fred >> won. before his death he gave it to me. >> >> and lastly, and secret until now, fred >> painted the peter face on the water tower. >> >> >> >> On Thu, Mar 11, 2021 at 8:14 AM M Douglas McIlroy < >> m.douglas.mcilroy at dartmouth.edu> wrote: >> >>> Ah, yes. Fred would pick things up at the Keebler Baking factory outlet >>> on his way to work. >>> We called it the "used cookie store". >>> >>> On Thu, Mar 11, 2021 at 10:31 AM Andrew Hume wrote: >>> >>>> fred was certainly a character. >>>> >>>> perhaps ken or rob might confirm this, but i recall at least one of the >>>> canoe trips demonstrated >>>> the effects of dropping flour sacks onto canoes from a small airplane. >>>> (i was not present on any >>>> of these trips, but heard this from grampp.) >>>> >>>> he was also responsible for occasionally buying bulk bags of barely >>>> digestible cheese crackers >>>> (we called them cheese awfuls) and leaving them in the Unix Room to be >>>> eaten. >>>> >>>> > On Mar 11, 2021, at 7:06 AM, M Douglas McIlroy < >>>> m.douglas.mcilroy at dartmouth.edu> wrote: >>>> > >>>> > In all that's been written about the Research Unix players, >>>> > Fred Grampp has gotten far less coverage than he deserves. >>>> > I hope to rectify that with this post, most of which was >>>> > written soon after his death. >>>> > >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From reed at reedmedia.net Fri Mar 12 08:33:38 2021 From: reed at reedmedia.net (Jeremy C. Reed) Date: Thu, 11 Mar 2021 16:33:38 -0600 (CST) Subject: [TUHS] [COFF] Pondering the hosts file In-Reply-To: <20210311200558.GW3990@netmeister.org> References: <20210311200558.GW3990@netmeister.org> Message-ID: On Thu, 11 Mar 2021, Jan Schaumann wrote: > ; DoD Internet Host Table > ; 22-Mar-85 > ; Version number 436 > > Does anybody have an earlier copy? See the collection at https://github.com/ttkzw/hosts.txt/ (but not all are in the same format) From norman at oclsc.org Fri Mar 12 09:35:52 2021 From: norman at oclsc.org (Norman Wilson) Date: Thu, 11 Mar 2021 18:35:52 -0500 Subject: [TUHS] Fred Grampp Message-ID: <1615505755.13174.for-standards-violators@oclsc.org> As I remember it, the Facilities folks were so upset about someone painting stuff on Their Water Tower that a complaint went to Vic Vyssotsky, then Executive Director of Division 112 (one step up from Sandy Fraser, who was Director of 1127). The story was that Vic and/or Sandy told them that there were 60 people in the research centre and no way to tell who did it. Word was then quietly passed to certain people--Vic and Sandy in fact knew exactly who--that things were getting out of hand, please lay off the Peter-face pranking for a while. I tried to start a rumour that Vic did the painting, but it never took off. I hope Vic at least heard it. He'd have enjoyed the rumour, surely laughed at the prank while knowing he'd have to calm things down, and 20 years earlier might well have been involved in something like that. It was Vic who, on learning I was a cyclist, urged me to try cycling on the newly-constructed but not yet open segment of interstate highway that ran behind the Labs. He apparently had done so and found it lots of fun. Alas, I never did. Norman Wilson Toronto ON From clemc at ccc.com Fri Mar 12 09:42:54 2021 From: clemc at ccc.com (Clem Cole) Date: Thu, 11 Mar 2021 18:42:54 -0500 Subject: [TUHS] Fred Grampp In-Reply-To: <1615505755.13174.for-standards-violators@oclsc.org> References: <1615505755.13174.for-standards-violators@oclsc.org> Message-ID: https://starkraving.medium.com/what-is-male-idiot-theory-2efa91d69fd4 ᐧ On Thu, Mar 11, 2021 at 6:36 PM Norman Wilson wrote: > As I remember it, the Facilities folks were so upset about > someone painting stuff on Their Water Tower that a complaint > went to Vic Vyssotsky, then Executive Director of Division > 112 (one step up from Sandy Fraser, who was Director of 1127). > > The story was that Vic and/or Sandy told them that there were > 60 people in the research centre and no way to tell who did it. > > Word was then quietly passed to certain people--Vic and Sandy > in fact knew exactly who--that things were getting out of hand, > please lay off the Peter-face pranking for a while. > > I tried to start a rumour that Vic did the painting, but it > never took off. I hope Vic at least heard it. He'd have > enjoyed the rumour, surely laughed at the prank while knowing > he'd have to calm things down, and 20 years earlier might well > have been involved in something like that. > > It was Vic who, on learning I was a cyclist, urged me to try > cycling on the newly-constructed but not yet open segment of > interstate highway that ran behind the Labs. He apparently > had done so and found it lots of fun. Alas, I never did. > > Norman Wilson > Toronto ON > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Fri Mar 12 09:46:28 2021 From: rich.salz at gmail.com (Richard Salz) Date: Thu, 11 Mar 2021 18:46:28 -0500 Subject: [TUHS] [COFF] Pondering the hosts file In-Reply-To: References: <20210311200558.GW3990@netmeister.org> Message-ID: > Perhaps a more interesting question, and one which I cannot quickly answer > (nor am I going to go pinging huge swaths of the public internet), is are > there any hosts in any version of HOSTS.TXT that are still on the public > internet in the same location? > Hard to answer the question. Same physical location? Same hardware? mit-prep.arpa is prep.ai.mit.edu which is a CNAME to ftp.gnu.org Theseus's ship? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mah at mhorton.net Fri Mar 12 11:14:16 2021 From: mah at mhorton.net (Mary Ann Horton) Date: Thu, 11 Mar 2021 17:14:16 -0800 Subject: [TUHS] [COFF] Pondering the hosts file In-Reply-To: References: <02d10a8e-2f39-4f88-f4c9-ecb295e0f01e@spamtrap.tnetconsulting.net> <555F9514-DD67-41F1-8151-480F0D9D0EAC@iitbombay.org> Message-ID: <446e7c8d-01d6-6f86-3078-02e795b85ee8@mhorton.net> 3com.com was indeed illegal initially. We (the UUCP Zone) went to register it with the NIC and were told leading zeros weren't allowed, because some code might think a leading digit meant an IP address. I pushed back, they relented, and it was registered without a problem. On 3/11/21 1:08 PM, Ron Natalie wrote: > The "name" in this context the host/network/gateway name such as > SRI-NIC.ARPA.    3COM.COM would not have been legal back then. > Nowhere does it imply that any of the other fields are so restricted. > > ------ Original Message ------ > From: "Bakul Shah" > > To: "Ron Natalie" > > Cc: "The Unix Heritage Society" >; "Internet History" > > > Sent: 3/11/2021 4:02:50 PM > Subject: Re: [TUHS] [COFF] Pondering the hosts file > >> On Mar 11, 2021, at 12:32 PM, Ron Natalie > > wrote: >>> >>> Amusingly one day we got an Imagen ethernet-connected laser >>> printer.    Mike Muuss decided the thing should be named BRL-ZAP and >>> since I didn't know what to put down as the machine type, and it did >>> have a 68000 in it, I had Jake put 68000 in the entry in the host table. >>> >>> The next day I got all kinds of hate mail from other BSD sites who >>> assumed I had intentionally sabotaged the host table.  Apparently, >>> the BSD systems used a YACC grammar to parse the NIC table into the >>> Berkeley one.   The only problem is they got the grammar wrong and >>> assumed the CPU type always began with a letter.    There parse blew >>> up on my "ZAP" host and they assumed that was the desired effect. >> >> This is understandable as >> a) All the "official machine names" in various assigned numbers RFCs >> start with a letter. >> b) the BNF syntax for the "host table specification" entries in RFC >> 952 or 810 are not precise enough. >> >> ::= PDP-11/70 | DEC-1080 | C/30 | CDC-6400...etc. >> >> NOTE: See "Assigned Numbers" for specific options and acronyms >> for machine types, operating systems, and protocol/services. >> >> for machine types, operating systems, and protocol/services. >> >> c) 68000 was not an official name! >> :-) :-) :-) >> >>> I countered back that using a YACC grammar for this was rediculous. >>>  There was already a real popular file on UNIX that had a bunch of >>> fields separated by colons and commas (/etc/passwd anybody) that it >>> was never necessary to use YACC to parse. >> >> Can't argue with that! Though that doesn't mean a handwritten parser >> wouldn't have complained about 68000. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From reed at reedmedia.net Fri Mar 12 11:15:03 2021 From: reed at reedmedia.net (Jeremy C. Reed) Date: Thu, 11 Mar 2021 19:15:03 -0600 (CST) Subject: [TUHS] [COFF] Pondering the hosts file In-Reply-To: References: <20210311200558.GW3990@netmeister.org> Message-ID: (I re-added Internet History list to my response here ...) On Thu, 11 Mar 2021, Henry Bent wrote: > Perhaps a more interesting question, and one which I cannot quickly answer > (nor am I going to go pinging huge swaths of the public internet), is are > there any hosts in any version of HOSTS.TXT that are still on the public > internet in the same location?  Or - and perhaps there is an easy answer to > this that I do not know - is there a repository of old WHOIS databases?  I > remember being stymied ~20 years ago that Ultrix had SRI-NIC.ARPA hardcoded > in the whois binary and I couldn't find a hostname of the correct length > with which to replace it... Using 1988 SRI-NIC host table https://github.com/ttkzw/hosts.txt/blob/master/pub/hosts/19881208/HOSTS.TXT I don't know if at same location, but some relationship and even some same or close names: CS.WISC.EDU 128.105.2.6 128.135.0.0 u-chicago.uchicago.edu. uvaarpa.virginia.edu. uvaarpa-old.virginia.edu. 128.143.2.7 jellicoe.cs.ucl.ac.uk. 128.16.3.1 honda.cs.columbia.edu. 128.59.16.16 cesd-gw.ai.sri.com. 192.12.33.1 ns0.llnl.gov. 192.12.17.1 umbc-net.umbc.edu. 130.85.0.0 net.queensu.ca. 130.15.0.0 ns.indiana.edu. 129.79.1.1 oswego-net.oswego.edu. 129.3.0.0 dorm-net0.stanford.edu. 128.12.0.0 nas-net.nas.nasa.gov. 129.99.0.0 Several others at same organizations or descendants. A lot are under xip.io. From cowan at ccil.org Fri Mar 12 12:48:17 2021 From: cowan at ccil.org (John Cowan) Date: Thu, 11 Mar 2021 21:48:17 -0500 Subject: [TUHS] manual humour (was tunefs -m 5%) In-Reply-To: References: <20210309162128.692CF640CB6@lignose.oclsc.org> <20210309202255.3doIj%steffen@sdaoden.eu> Message-ID: On Tue, Mar 9, 2021 at 5:31 PM Rob Pike wrote: I'm curious when people (other than me) erred and stopped saying that ed > was the standard editor. > They haven't. When a vi vs. Emacs (vel sim.) argument is swirling around me, I explain that ex(1) is the editor I use. People say "But ed(1) is the standard editor!" To which I reply, "Yes, but I'm willing to trade a little standardosity for a little convenience." John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org I Hope, Sir, that we are not mutually Un-friended by this Difference which hath happened betwixt us. --Thomas Fuller, Appeal of Injured Innocence (1659) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggm at algebras.org Fri Mar 12 13:27:12 2021 From: ggm at algebras.org (George Michaelson) Date: Fri, 12 Mar 2021 13:27:12 +1000 Subject: [TUHS] [COFF] Pondering the hosts file In-Reply-To: References: <20210311200558.GW3990@netmeister.org> Message-ID: Funny story about /etc/hosts. and HOSTS.TXT. It was SRI NIC or NIC DDN/MIL's job to maintain and distribute. Centrex model to keep the numbers up, and hostnames aligned. We did shell ftp fetches and local distribution. Yellow pages was a godsend in mant ways, the operations duty cycle to keep this stuff up to date was a bit of a PITA. Enter yourself in HOSTS.TXT. It was sorted. Often, Alpha. So people like BBN were up top. People like MIT were midway. UCL-CS was down low. Oh well. Good thing we don't do linear lookup.. Or it was sorted by IP. But, somehow no matter what sort, we were down the back. Some things basically seemed to to linear. And, as the host count rose, be it sorted by IP or sorted by name, hosts in UCL-CS seemed to be "bottom" for finding. Bottom in time sense. So: you try to telnet to a US node, (or FTP) -and it dies. BBN butterfly has LRUd you out. You get that fixed. That takes time too. Hopefully less often. Shame BBN was on a fixed price fixed term contract and the EGP (pre BGP) was not patchable. Things come back eventually. You try to telnet to a node again. You get connected. Long pause. you get login: prompt. Long pause. You start typing login.. it drops link. Getty/login had a 30 second timer. We were sitting on 29-31 seconds lookup delay to resolve the client IP, to assert the login prompt. Sucked to be us. -G From lars at nocrew.org Fri Mar 12 15:53:59 2021 From: lars at nocrew.org (Lars Brinkhoff) Date: Fri, 12 Mar 2021 05:53:59 +0000 Subject: [TUHS] [COFF] Pondering the hosts file In-Reply-To: (Henry Bent's message of "Thu, 11 Mar 2021 16:05:38 -0500") References: <20210311200558.GW3990@netmeister.org> <7wim5x5skj.fsf@junk.nocrew.org> Message-ID: <7w35x06hoo.fsf@junk.nocrew.org> Henry Bent wrote: > MIT and Stanford PDP-10 archives have various HOSTS files going back > to the mid 1970s. > > Links? I have not the slightest idea where to start looking for those > archives Hopefully they will be more accessible in the future. For now, here's a link to the oldest 1977 copy of HOSTS.TXT in Mark Cripin's directory on the SAIL PDP-10: https://www.saildart.org/HOSTS.TXT[NET,MRC]1 From pnr at planet.nl Fri Mar 12 20:53:05 2021 From: pnr at planet.nl (Paul Ruizendaal) Date: Fri, 12 Mar 2021 11:53:05 +0100 Subject: [TUHS] [COFF] Pondering the hosts file Message-ID: <1CD8545D-4D5C-4360-A5A1-3B931433C711@planet.nl> BBN’s TCP implementation contained something akin to the hosts file, called hostmap there: https://www.tuhs.org/cgi-bin/utree.pl?file=BBN-Vax-TCP/doc I have not looked at the code for a while, but if I remember correctly the BBN kernel code also read in this file (pre-processed into a binary form) to build its internal routing table. I do not recall having seen an equivalent file with UoI's NCP Unix in any of the surviving docs or sources - but that does not exclude a library having existed to do lookups in a local copy the SRI-NIC host file. In fact there is some evidence for that in the 2.9 BSD source. The only surviving copy of the 4.1a (network) source code that I know is in the back-port of this code to 2.8/2.9 BSD. This code includes #ifdef’ed code for accessing the SRI-NIC online host table via NCP: https://www.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/net/local This source also contains tools to convert the SRI-NIC data into - inter alia - a hosts file: https://www.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/net/man/man8/htable.8 https://www.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/net/man/man8/gettable.8c It would seem that the modern host.txt on Unix evolved late ’81 (BBN code) to early ’82 (4.1a BSD). Possibly NCP Unix has prior work. Paul From ches at cheswick.com Fri Mar 12 23:30:29 2021 From: ches at cheswick.com (William Cheswick) Date: Fri, 12 Mar 2021 08:30:29 -0500 Subject: [TUHS] Fred Grampp In-Reply-To: <1615505755.13174.for-standards-violators@oclsc.org> References: <1615505755.13174.for-standards-violators@oclsc.org> Message-ID: <430268C9-FF11-4F62-A8E7-0FC3CBA84D77@cheswick.com> > On Mar 11, 2021, at 6:35 PM, Norman Wilson wrote: > > please lay off the Peter-face pranking for a while. The pjw icon at the top of stair 8 (made from round magnets from the stockroom) was still there when last I checked. From ches at cheswick.com Fri Mar 12 23:34:32 2021 From: ches at cheswick.com (William Cheswick) Date: Fri, 12 Mar 2021 08:34:32 -0500 Subject: [TUHS] Fred Grampp In-Reply-To: References: <1615505755.13174.for-standards-violators@oclsc.org> Message-ID: <9FE83288-51FB-415B-B325-9628DB8B065F@cheswick.com> Fred once told me a brief story about the installation of the new raised-floor computer room for the alice machine. He had requested that the floor be wet-mopped before the tiles were installed. When the installer informed Fred that they weren’t going to bother, Fred obtained a small bottle of elemental mercury from his office and showed it to the installer. The installer had the choice of wet-mapping the floor, or cleaning up a mercury spill in moon suits. He relented. From jsteve at superglobalmegacorp.com Sun Mar 14 12:31:18 2021 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Sun, 14 Mar 2021 10:31:18 +0800 Subject: [TUHS] 4.4BSD sparc, pmax binary recently compiled Message-ID: <0F0B9BFC06289346B88512B91E55670D3010@EXCHANGE> Wow this is nothing short of GREAT! I always wanted to tackle this but it was out of my reach as I barely got anything from this lineage to build to anything. Most excellent! -----Original Message----- From: MOCHIDA Shuji To: tuhs at minnie.tuhs.org Sent: 3/6/21 10:42 AM Subject: [TUHS] 4.4BSD sparc, pmax binary recently compiled I compiled 4.4BSD to get pmax and sparc binary, from CSRG Archive CD-ROM #4 source code. http://www.netside.co.jp/~mochid/comp/bsd44-build/ pmax: - Works on GXemul DECstaion(PMAX) emulation. - I used binutils 2.6 and gcc 2.7.2.3 taken from Gnu ftp site, as 4.4BSD src does not contain pmax support part in as, ld, gcc and gdb. - Lack of GDB. I got rid of compile errors of gdb 4.16, but that does not work yet. - gcc included can not deal c++ static constructor. So, contrib/groff can not be compiled. Instead, it uses old/{nroff,troff,eqn,tbl..}. sparc: - Works on sun4c. I use on SPARCstation 2, real hardware. TME sun4c emulation can boot to single user, but it locks up in middle of /etc/rc. CSRG Archive CD-ROM #4's source code (just after Lite2 release) seems have differences from CSRG's binary distributions before (2 times), e.g. mount systemcall is not compatible. I used NetBSD 1.0/sparc, NetBSD 1.1/pmax for 1st (slightly) cross compiling. NetBSD 1.0/sparc boots and works well on TME emulator. SunOS 4.1.4, Solaris7 works too, but this 4.4BSD binary doesn't.. -mochid From cowan at ccil.org Mon Mar 15 13:02:58 2021 From: cowan at ccil.org (John Cowan) Date: Sun, 14 Mar 2021 23:02:58 -0400 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: <202103041831.124IVZTj018003@freefriends.org> <604133A6.8070101@gmail.com> <25705.1614938294@hop.toad.com> <20210306213811.GF1054@mcvoy.com> Message-ID: On Sat, Mar 6, 2021 at 5:06 PM Clem Cole wrote: > *And then a few weeks later I had a user population of about a dozen, most > of them friends, and I didn't want to screw up my embedded base. The rest, > sadly, is history.* > *— Stuart Feldman* > > Consequently, when he arrived at Google for his new job there, he was initially supplied with a keyboard from which the Tab key had been removed (at least according to various Googlers while I was there). John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org The experiences of the past show that there has always been a discrepancy between plans and performance. --Emperor Hirohito, August 1945 ᐧ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Tue Mar 16 04:15:45 2021 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 15 Mar 2021 19:15:45 +0100 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: <202103041831.124IVZTj018003@freefriends.org> <604133A6.8070101@gmail.com> <25705.1614938294@hop.toad.com> <20210306213811.GF1054@mcvoy.com> Message-ID: <20210315181545.CtIcN%steffen@sdaoden.eu> John Cowan wrote in : |On Sat, Mar 6, 2021 at 5:06 PM Clem Cole wrote: |> *And then a few weeks later I had a user population of about a dozen, \ |> most |> of them friends, and I didn't want to screw up my embedded base. \ |> The rest, |> sadly, is history.* |> *— Stuart Feldman* |> |Consequently, when he arrived at Google for his new job there, he was |initially supplied with a keyboard from which the Tab key had been removed |(at least according to various Googlers while I was there). Reminds me of members of the outgoing Clinton administration removing the "W" key from white house keyboards. Leads to nothing good, such... --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 dave at horsfall.org Tue Mar 16 07:08:11 2021 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 16 Mar 2021 08:08:11 +1100 (EST) Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: <202103041831.124IVZTj018003@freefriends.org> <604133A6.8070101@gmail.com> <25705.1614938294@hop.toad.com> <20210306213811.GF1054@mcvoy.com> Message-ID: On Sun, 14 Mar 2021, John Cowan wrote: > Consequently, when he arrived at Google for his new job there, he was > initially supplied with a keyboard from which the Tab key had been > removed (at least according to various Googlers while I was there). That's a bit extreme... Although I confess to removing the CAPS LOCK and the Windoze keys on all of mine, as I can't think of a use for them and I tend to hit them by mistake. -- Dave, a hopeless typist From usotsuki at buric.co Tue Mar 16 07:12:57 2021 From: usotsuki at buric.co (Steve Nickolas) Date: Mon, 15 Mar 2021 17:12:57 -0400 (EDT) Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: <202103041831.124IVZTj018003@freefriends.org> <604133A6.8070101@gmail.com> <25705.1614938294@hop.toad.com> <20210306213811.GF1054@mcvoy.com> Message-ID: On Tue, 16 Mar 2021, Dave Horsfall wrote: > On Sun, 14 Mar 2021, John Cowan wrote: > >> Consequently, when he arrived at Google for his new job there, he was >> initially supplied with a keyboard from which the Tab key had been removed >> (at least according to various Googlers while I was there). > > That's a bit extreme... Although I confess to removing the CAPS LOCK and the > Windoze keys on all of mine, as I can't think of a use for them and I tend to > hit them by mistake. I repurpose the Windows keys as something actually useful to me: compose keys. -uso. From bakul at iitbombay.org Tue Mar 16 07:19:33 2021 From: bakul at iitbombay.org (Bakul Shah) Date: Mon, 15 Mar 2021 14:19:33 -0700 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: <20210315181545.CtIcN%steffen@sdaoden.eu> References: <20210315181545.CtIcN%steffen@sdaoden.eu> Message-ID: <01BE1B3F-8745-4465-93EF-95AA83EFD494@iitbombay.org> > On Mar 15, 2021, at 11:16 AM, Steffen Nurpmeso wrote: > > Reminds me of members of the outgoing Clinton administration > removing the "W" key from white house keyboards. > Leads to nothing good, such... From https://www.govexec.com/management/2016/02/must-presidential-transitions-end-sabotaged-white-house-keyboards/126061/ Several veterans of tense transitions weighed in on the oft-told tale of the 2000-01 transition during which departing Clinton staffers were reported to have removed the “W” keys from the White House keyboards being inherited by employees of George W. Bush. When she moved in on Jan. 20, McBride said, she recalled no sabotaged keyboards but did encounter some messy offices and the empty hallways filled with trash and boxes from the departing employees. Sharon Fawcett, the retired assistant archivist for presidential libraries at the National Archives, told later investigators she said couldn’t account for any missing W keys, but could account for missing hard drives—which were taken by her agency according to records law. Kumar said the keyboard story appeared to be “overblown,” with a Government Accountability Office probe having found some problems but “nothing organized.” Problems included a few broken pieces of furniture and strewn pizza boxes that a janitor failed to remove. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Tue Mar 16 07:24:23 2021 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 16 Mar 2021 08:24:23 +1100 (EST) Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: <202103041831.124IVZTj018003@freefriends.org> <604133A6.8070101@gmail.com> <25705.1614938294@hop.toad.com> <20210306213811.GF1054@mcvoy.com> Message-ID: On Mon, 15 Mar 2021, Steve Nickolas wrote: > I repurpose the Windows keys as something actually useful to me: compose > keys. I thought about remapping them, but couldn't think of anything useful to me. Anyway, my current keyboard is a MacBook, and the last time I prised out the CAPS LOCK I damaged the keyboard so I merely ignore it in Keyboard Preferences. I still can't think of a use for it these days, but I guess it's for compatibility with those mechanical things. At least there's no damned Windoze key to get in the way... -- Dave From athornton at gmail.com Tue Mar 16 08:06:51 2021 From: athornton at gmail.com (Adam Thornton) Date: Mon, 15 Mar 2021 15:06:51 -0700 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: <202103041831.124IVZTj018003@freefriends.org> <604133A6.8070101@gmail.com> <25705.1614938294@hop.toad.com> <20210306213811.GF1054@mcvoy.com> Message-ID: I use Karabiner to remap Caps Lock to Control globally. Since my daily driver is a 1989 Model M, I also use it to remap Left Alt to Command and Right Ctrl to Fn (but I run with function keys as function keys, with held-down Fn to access the media and screen controls). Adam On Mon, Mar 15, 2021 at 2:24 PM Dave Horsfall wrote: > On Mon, 15 Mar 2021, Steve Nickolas wrote: > > > I repurpose the Windows keys as something actually useful to me: compose > > keys. > > I thought about remapping them, but couldn't think of anything useful to > me. > > Anyway, my current keyboard is a MacBook, and the last time I prised out > the CAPS LOCK I damaged the keyboard so I merely ignore it in Keyboard > Preferences. I still can't think of a use for it these days, but I guess > it's for compatibility with those mechanical things. > > At least there's no damned Windoze key to get in the way... > > -- Dave > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at cuzuco.com Tue Mar 16 08:46:42 2021 From: tuhs at cuzuco.com (Brian Walden) Date: Mon, 15 Mar 2021 18:46:42 -0400 (EDT) Subject: [TUHS] Fred Grampp Message-ID: <202103152246.12FMkgg1001552@cuzuco.com> Amazing coincidences. A week prior I was researching Topper Toys looking for their old factory ("largest toy factory in the world") As there was litte on it's location and it lead me to find out in 1961 it took over the old Singer Factory in Elizabeth, NJ. So looking up the Singer factory led me to "Elizabeth, New Jersey, Then and Now" by Robert J. Baptista https://ia801304.us.archive.org/11/items/ElizabethNewJerseyThenAndNowSecondEdition2015/ElizabethNewJerseyThenNowThirdEditionApril102018607Pages.pdf Which had no information on Topper, but had had this paragraph in it's Singer section on page 28 -- Boys earned money "rushing the growler" at lunchtime at the Singer plant. German workers lowered their covered beer pails, called growlers, on ropes to the boys waiting below. They earned a nickel by filling them with beer at Grampp's saloon on Trumbull St. One of these boys was Thomas Dunn who later became a long term Mayor. In the early 1920s Frederick Grampp went into the hardware business at the corner of Elizabeth Ave. and Reid St. When I read it I thought funny, as I know the name Fred Grampp. But beleived just a coincidenental same name. After reading the biography post, I went back to the book as it turns out that Fred Grampp is your Fred Grampps's grandfather. You can find more his family and the hardware store and Grampp himself on pages 163-164, and 212. -Brian From steffen at sdaoden.eu Tue Mar 16 09:47:49 2021 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 16 Mar 2021 00:47:49 +0100 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: <01BE1B3F-8745-4465-93EF-95AA83EFD494@iitbombay.org> References: <20210315181545.CtIcN%steffen@sdaoden.eu> <01BE1B3F-8745-4465-93EF-95AA83EFD494@iitbombay.org> Message-ID: <20210315234749.-J3mz%steffen@sdaoden.eu> Bakul Shah wrote in <01BE1B3F-8745-4465-93EF-95AA83EFD494 at iitbombay.org>: Wonderful, i can re-answer in public, too, leaving something off. --- Forwarded from Bakul Shah --- Maybe because alternate processing rips myself off. Sigh. ... |Oh. Hm. I heard this on American Forces |Network, told by Tony Scott, to which i listened from at least |Monday to Thursday 00am to 04am (German Time). When such things |were still possible, and thus in the first days, maybe the day it |happened. (Before "Max" was taken offline after Tony Scott issued |several "You can't say that on the radio", for sure.) He surely did for years before that. But i mean, hey, just an observation, i have no idea of american sensitivities. |But thanks for the pointer. Haven't we had this already in the |past? The above sounds dark and ugly to my ears, hmmmm. Yeah i mean, this arose by the beginning of the 90s, right. If the first examination does not reveal the desired result (but maybe the truth even, heh), then just perform a second .. a third one, until the result is absolutely what was wanted. Gulf war illness, Barschel's death, W keys on the keyboard .. you name it. --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 m.douglas.mcilroy at dartmouth.edu Tue Mar 16 11:12:56 2021 From: m.douglas.mcilroy at dartmouth.edu (M Douglas McIlroy) Date: Mon, 15 Mar 2021 21:12:56 -0400 Subject: [TUHS] Fred Grampp In-Reply-To: <202103152246.12FMkgg1001552@cuzuco.com> References: <202103152246.12FMkgg1001552@cuzuco.com> Message-ID: Serendipitous find! I hadn't realized that Fred had been the third generation in the hardware store. His father ("Pops") retired to Drayton Island in the St Johns River about 60 miles south of Jacksonville. Fred often visited him, driving the 19-hour trip in one stint. Doug On Mon, Mar 15, 2021 at 6:47 PM Brian Walden wrote: > > Amazing coincidences. A week prior I was researching Topper Toys > looking for their old factory ("largest toy factory in the world") > As there was litte on it's location and it lead me to find out > in 1961 it took over the old Singer Factory in Elizabeth, NJ. > So looking up the Singer factory led me to "Elizabeth, > New Jersey, Then and Now" by Robert J. Baptista > > https://ia801304.us.archive.org/11/items/ElizabethNewJerseyThenAndNowSecondEdition2015/ElizabethNewJerseyThenNowThirdEditionApril102018607Pages.pdf > > Which had no information on Topper, but had had this paragraph in it's Singer > section on page 28 -- > > Boys earned money "rushing the growler" at lunchtime at the Singer plant. > German workers lowered their covered beer pails, called growlers, on ropes > to the boys waiting below. They earned a nickel by filling them with beer > at Grampp's saloon on Trumbull St. One of these boys was Thomas Dunn who > later became a long term Mayor. In the early 1920s Frederick Grampp went > into the hardware business at the corner of Elizabeth Ave. and Reid St. > > > When I read it I thought funny, as I know the name Fred Grampp. But beleived > just a coincidenental same name. After reading the biography post, I went back > to the book as it turns out that Fred Grampp is your Fred Grampps's > grandfather. You can find more his family and the hardware store and > Grampp himself on pages 163-164, and 212. > > -Brian > From earl.baugh at gmail.com Tue Mar 16 13:10:42 2021 From: earl.baugh at gmail.com (Earl Baugh) Date: Mon, 15 Mar 2021 23:10:42 -0400 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: <20210315234749.-J3mz%steffen@sdaoden.eu> References: <20210315234749.-J3mz%steffen@sdaoden.eu> Message-ID: <55D2C36A-9503-42F1-80B2-BBB1D9638449@gmail.com> One of the times I was lucky enough to be able to hire and set up what I thought would be the place I’d want to work ( design and code ), at the beginning I did the best I could to solve the “religious” code issues, tool issues, etc. Code Formatting wise — we came up with a “checked-in-standard”. All code went thru a code formatter when checking in. When it came out, we build a couple templates that translated to formats for things that different folks wanted ( and gave folks the option of tweaking their own ). They could use the default ( I did ). Any thing was fair game, as long as it got checked in “in the checked in standard”. We also came up with a set of rules for complexity, nesting. The entire team actually was able to come to agreement — if your code didn’t violated the limit of minor or misc things ( critical and major things had to be addressed ) it was fine. We set a limit of 1000 for minor and I think 5000 for misc. I was surprised how far from the standard stuff looked on various folks workstations but during code reviews we had a “common language format” we all could read without much fuss. We did go with a line length of <132 so if necessary we could print stuff out landscape. Tool wise, if it got in the way more than 50% it was gone and we’d find a new one. Preference was for every editor, etc. to have at least two users on the team. ( so you’d have someone to ask questions of ) And you could use an IDE as long as code had standard makefiles when checked in. Surprisingly this worked out quite well with a team of around 20... Earl Sent from my iPhone > On Mar 15, 2021, at 7:48 PM, Steffen Nurpmeso wrote: > > Bakul Shah wrote in > <01BE1B3F-8745-4465-93EF-95AA83EFD494 at iitbombay.org>: > > Wonderful, i can re-answer in public, too, leaving something off. > > --- Forwarded from Bakul Shah --- > > Maybe because alternate processing rips myself off. Sigh. > > ... > |Oh. Hm. I heard this on American Forces > |Network, told by Tony Scott, to which i listened from at least > |Monday to Thursday 00am to 04am (German Time). When such things > |were still possible, and thus in the first days, maybe the day it > |happened. (Before "Max" was taken offline after Tony Scott issued > |several "You can't say that on the radio", for sure.) > > He surely did for years before that. But i mean, hey, just an > observation, i have no idea of american sensitivities. > > |But thanks for the pointer. Haven't we had this already in the > |past? The above sounds dark and ugly to my ears, hmmmm. > > Yeah i mean, this arose by the beginning of the 90s, right. > If the first examination does not reveal the desired result (but > maybe the truth even, heh), then just perform a second .. a third > one, until the result is absolutely what was wanted. Gulf war > illness, Barschel's death, W keys on the keyboard .. you name it. > > --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 ches at cheswick.com Tue Mar 16 22:47:39 2021 From: ches at cheswick.com (William Cheswick) Date: Tue, 16 Mar 2021 08:47:39 -0400 Subject: [TUHS] Fred Grampp In-Reply-To: References: <202103152246.12FMkgg1001552@cuzuco.com> Message-ID: > On Mar 15, 2021, at 9:12 PM, M Douglas McIlroy wrote: > > His father ("Pops") retired to Drayton Island in the St Johns River > about 60 miles south of Jacksonville. > Fred often visited him, driving the 19-hour trip in one stint. Fred was a big fan of opera. He’d play the Ring going to see his parents. Said he get there in 2.5 operas. That’s 400 miles/opera, or maybe 100 MPH. This is certainly faster than Doug’s number. I think Fred said he went 90 MPH, which is totally consistent with his personality. ches From arnold at skeeve.com Tue Mar 16 23:25:59 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 16 Mar 2021 07:25:59 -0600 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: <202103041831.124IVZTj018003@freefriends.org> <604133A6.8070101@gmail.com> <25705.1614938294@hop.toad.com> <20210306213811.GF1054@mcvoy.com> Message-ID: <202103161325.12GDPxpL016730@freefriends.org> Dave Horsfall wrote: > On Mon, 15 Mar 2021, Steve Nickolas wrote: > > > I repurpose the Windows keys as something actually useful to me: compose > > keys. > > I thought about remapping them, but couldn't think of anything useful to > me. > > Anyway, my current keyboard is a MacBook, and the last time I prised out > the CAPS LOCK I damaged the keyboard so I merely ignore it in Keyboard > Preferences. I still can't think of a use for it these days, but I guess > it's for compatibility with those mechanical things. > > At least there's no damned Windoze key to get in the way... > > -- Dave Come now people. Caps-lock keys are a requirement for your AOL account! ;-) Arnold From rtomek at ceti.pl Wed Mar 17 13:46:31 2021 From: rtomek at ceti.pl (Tomasz Rola) Date: Wed, 17 Mar 2021 04:46:31 +0100 Subject: [TUHS] Fred Grampp In-Reply-To: <202103152246.12FMkgg1001552@cuzuco.com> References: <202103152246.12FMkgg1001552@cuzuco.com> Message-ID: <20210317034631.GA1385@tau1.ceti.pl> On Mon, Mar 15, 2021 at 06:46:42PM -0400, Brian Walden wrote: [...] > Which had no information on Topper, but had had this paragraph in it's Singer > section on page 28 -- > > Boys earned money "rushing the growler" at lunchtime at the Singer plant. > German workers lowered their covered beer pails, called growlers, on ropes > to the boys waiting below. They earned a nickel by filling them with beer > at Grampp's saloon on Trumbull St. One of these boys was Thomas Dunn who > later became a long term Mayor. In the early 1920s Frederick Grampp went > into the hardware business at the corner of Elizabeth Ave. and Reid St. Wow, what a find, really. I suppose the move from saloon business onto the hardware business was caused by Prohibition? Interesting side-effect. "Prohibition in the United States was a nationwide constitutional ban on the production, importation, transportation, and sale of alcoholic beverages from 1920 to 1933." [ https://en.wikipedia.org/wiki/Prohibition_in_the_United_States ] -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola at bigfoot.com ** From grog at lemis.com Wed Mar 17 15:10:19 2021 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Wed, 17 Mar 2021 16:10:19 +1100 Subject: [TUHS] tabs vs spaces - entab, detab In-Reply-To: References: <202103041831.124IVZTj018003@freefriends.org> <604133A6.8070101@gmail.com> <25705.1614938294@hop.toad.com> <20210306213811.GF1054@mcvoy.com> Message-ID: <20210317051019.GC4025@eureka.lemis.com> On Sunday, 14 March 2021 at 23:02:58 -0400, John Cowan wrote: > On Sat, Mar 6, 2021 at 5:06 PM Clem Cole wrote: > > >> *And then a few weeks later I had a user population of about a dozen, most >> of them friends, and I didn't want to screw up my embedded base. The rest, >> sadly, is history.* >> *??? Stuart Feldman* >> > Consequently, when he arrived at Google for his new job there, he was > initially supplied with a keyboard from which the Tab key had been removed > (at least according to various Googlers while I was there). But he had a Ctrl key, right? So he had c-i. I have used that on keyboards where the TAB key is inconveniently placed. 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 pepe at naleco.com Thu Mar 18 06:33:37 2021 From: pepe at naleco.com (Josh Good) Date: Wed, 17 Mar 2021 21:33:37 +0100 Subject: [TUHS] Surprised about Unix System V in the 80's - so sparse! Message-ID: <20210317203335.GA5249@naleco.com> Hello UNIX veterans. So I stumbled online upon a copy of the book "SCO Xenix System V Operating System User's Guide", from 1988, advertised as having 395 pages, and the asked for price was 2.50 EUROs. I bought it, expecting --well, I don't know exactly what I was expecting, something quaint and interesting, I suppose. I've received the book, and it is not a treasure trobe, to say the least. I am in fact surprised at how sparse was UNIX System V of this age, almost spartan. The chapter titles are: 1. Introduction 2. vi: A Text Editor 3. ed 4. mail 5. Communicating with Other Sites 6. bc: A Calculator 7. The Shell 8. The C-Shell 9. Using the Visual Shell And that's it. The communications part only deals the Micnet (a serial-port based local networking scheme), and UUCP. No mention at all of the words "Internet" or "TCP/IP", no even in the Index. Granted, this Xenix version is derived from System V Release 2, and I think it was for the Intel 286 (not yet ported to the i386), but hey it's 1988 already and the Internet is supposed to be thriving on UNIX in the Pacific Coast, or so the lore says. I see now that it probably was only in the Berkely family that the Internet was going on... In truth, I fail to see what was the appeal of such a system, for mere users, when in the same PC you could run rich DOS-based applications like WordPerfect, Lotus 1-2-3, Ventura Publisher and all the PC software from those years. I mean, mail without Internet is pretty useless, althouhg I understand it could be useful for inter-company communications. And yes, it had vi and the Bourne Shell. But still, it feels very very limited, this Xenix version, from a user's point of view. I'm probably spoiled from Linux having repositories full of packaged free software, where the user just has to worry about "which is the best of": email program, text editor, browser, image manipulation program, video player, etc. I understand this now pretty well, how spoiled are we these days. -- Josh Good From athornton at gmail.com Thu Mar 18 06:57:31 2021 From: athornton at gmail.com (Adam Thornton) Date: Wed, 17 Mar 2021 13:57:31 -0700 Subject: [TUHS] Surprised about Unix System V in the 80's - so sparse! In-Reply-To: <20210317203335.GA5249@naleco.com> References: <20210317203335.GA5249@naleco.com> Message-ID: Just because it didn't have TCP/IP doesn't mean it couldn't send mail to other sites. UUCP was used for batched file transfer over serial lines, such as dialup modems. There was not generally _real-time interactive_ network stuff done with other sites, but there was plenty of store-and-forward goodness. Which is probably what Chapter 5 is about. Adam On Wed, Mar 17, 2021 at 1:51 PM Josh Good wrote: > Hello UNIX veterans. > > So I stumbled online upon a copy of the book "SCO Xenix System V Operating > System User's Guide", from 1988, advertised as having 395 pages, and the > asked for price was 2.50 EUROs. I bought it, expecting --well, I don't know > exactly what I was expecting, something quaint and interesting, I suppose. > > I've received the book, and it is not a treasure trobe, to say the least. I > am in fact surprised at how sparse was UNIX System V of this age, almost > spartan. > > The chapter titles are: > > 1. Introduction > 2. vi: A Text Editor > 3. ed > 4. mail > 5. Communicating with Other Sites > 6. bc: A Calculator > 7. The Shell > 8. The C-Shell > 9. Using the Visual Shell > > And that's it. The communications part only deals the Micnet (a serial-port > based local networking scheme), and UUCP. No mention at all of the words > "Internet" or "TCP/IP", no even in the Index. > > Granted, this Xenix version is derived from System V Release 2, and I think > it was for the Intel 286 (not yet ported to the i386), but hey it's 1988 > already and the Internet is supposed to be thriving on UNIX in the Pacific > Coast, or so the lore says. I see now that it probably was only in the > Berkely family that the Internet was going on... > > In truth, I fail to see what was the appeal of such a system, for mere > users, when in the same PC you could run rich DOS-based applications like > WordPerfect, Lotus 1-2-3, Ventura Publisher and all the PC software from > those years. > > I mean, mail without Internet is pretty useless, althouhg I understand it > could be useful for inter-company communications. And yes, it had vi and > the > Bourne Shell. But still, it feels very very limited, this Xenix version, > from a user's point of view. > > I'm probably spoiled from Linux having repositories full of packaged free > software, where the user just has to worry about "which is the best of": > email program, text editor, browser, image manipulation program, video > player, etc. I understand this now pretty well, how spoiled are we these > days. > > -- > Josh Good > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcapp at anteil.com Thu Mar 18 07:08:57 2021 From: jcapp at anteil.com (Jim Capp) Date: Wed, 17 Mar 2021 16:08:57 -0500 (EST) Subject: [TUHS] Surprised about Unix System V in the 80's - so sparse! In-Reply-To: <20210317203335.GA5249@naleco.com> Message-ID: <17719473.3631.1616015337052.JavaMail.root@zimbraanteil> Josh, The appeal was that SCO Xenix would turn a PC into a multi-user machine. For me, that meant shared databases and shared applications. We would run anywhere from 3 to a dozen or more "dumb" terminals. Unlike a DOS PC, SCO Xenix included most of the UNIX tools. At one time, it even included PWB. Just like a DOS based PC, applications like Word Perfect and Lotus 123 were available (for a price). My $.02 Jim From: "Josh Good" To: tuhs at tuhs.org Sent: Wednesday, March 17, 2021 4:33:37 PM Subject: [TUHS] Surprised about Unix System V in the 80's - so sparse! Hello UNIX veterans. So I stumbled online upon a copy of the book "SCO Xenix System V Operating System User's Guide", from 1988, advertised as having 395 pages, and the asked for price was 2.50 EUROs. I bought it, expecting --well, I don't know exactly what I was expecting, something quaint and interesting, I suppose. I've received the book, and it is not a treasure trobe, to say the least. I am in fact surprised at how sparse was UNIX System V of this age, almost spartan. The chapter titles are: 1. Introduction 2. vi: A Text Editor 3. ed 4. mail 5. Communicating with Other Sites 6. bc: A Calculator 7. The Shell 8. The C-Shell 9. Using the Visual Shell And that's it. The communications part only deals the Micnet (a serial-port based local networking scheme), and UUCP. No mention at all of the words "Internet" or "TCP/IP", no even in the Index. Granted, this Xenix version is derived from System V Release 2, and I think it was for the Intel 286 (not yet ported to the i386), but hey it's 1988 already and the Internet is supposed to be thriving on UNIX in the Pacific Coast, or so the lore says. I see now that it probably was only in the Berkely family that the Internet was going on... In truth, I fail to see what was the appeal of such a system, for mere users, when in the same PC you could run rich DOS-based applications like WordPerfect, Lotus 1-2-3, Ventura Publisher and all the PC software from those years. I mean, mail without Internet is pretty useless, althouhg I understand it could be useful for inter-company communications. And yes, it had vi and the Bourne Shell. But still, it feels very very limited, this Xenix version, from a user's point of view. I'm probably spoiled from Linux having repositories full of packaged free software, where the user just has to worry about "which is the best of": email program, text editor, browser, image manipulation program, video player, etc. I understand this now pretty well, how spoiled are we these days. -- Josh Good -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Thu Mar 18 07:26:18 2021 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 17 Mar 2021 14:26:18 -0700 Subject: [TUHS] Surprised about Unix System V in the 80's - so sparse! In-Reply-To: <20210317203335.GA5249@naleco.com> References: <20210317203335.GA5249@naleco.com> Message-ID: <20210317212618.GA24642@mcvoy.com> On Wed, Mar 17, 2021 at 09:33:37PM +0100, Josh Good wrote: > And that's it. The communications part only deals the Micnet (a serial-port > based local networking scheme), and UUCP. No mention at all of the words > "Internet" or "TCP/IP", no even in the Index. SCO got Lachman's TCP/IP stack (that they bought from Convergent) just after this timeframe. I know because I did the port. Also open sourced a sw (STREAMS watch) program I wrote so you could tune the kernel (kernel defaults yielded horrible performance). I still have that code if anyone cares, can't imagine it is interesting. From aek at bitsavers.org Thu Mar 18 07:04:36 2021 From: aek at bitsavers.org (Al Kossow) Date: Wed, 17 Mar 2021 14:04:36 -0700 Subject: [TUHS] Surprised about Unix System V in the 80's - so sparse! In-Reply-To: <20210317203335.GA5249@naleco.com> References: <20210317203335.GA5249@naleco.com> Message-ID: > hey it's 1988 already > mail without Internet is pretty useless And Usenet was tin cans and a string. --al (feeling very old) From henry.r.bent at gmail.com Thu Mar 18 07:29:40 2021 From: henry.r.bent at gmail.com (Henry Bent) Date: Wed, 17 Mar 2021 17:29:40 -0400 Subject: [TUHS] Surprised about Unix System V in the 80's - so sparse! In-Reply-To: <20210317203335.GA5249@naleco.com> References: <20210317203335.GA5249@naleco.com> Message-ID: On Wed, 17 Mar 2021 at 16:52, Josh Good wrote: > > And that's it. The communications part only deals the Micnet (a serial-port > based local networking scheme), and UUCP. No mention at all of the words > "Internet" or "TCP/IP", no even in the Index. > Not a total surprise. In 1988, the average home user had probably barely even heard of the internet. Even business users were only concerned with on-site networking, and that was a fairly expensive proposition. > In truth, I fail to see what was the appeal of such a system, for mere > users, when in the same PC you could run rich DOS-based applications like > WordPerfect, Lotus 1-2-3, Ventura Publisher and all the PC software from > those years. > Indeed, from the perspective of a home user you didn't really need an expensive UNIX box to do normal household chores. I was more than happy with a Visual 1050 running CP/M (and Wordstar, Multiplan, etc.) well into the late '80s. > I mean, mail without Internet is pretty useless, althouhg I understand it > could be useful for inter-company communications. And yes, it had vi and > the > Bourne Shell. But still, it feels very very limited, this Xenix version, > from a user's point of view. > Which might well explain why Xenix failed to gain much ground with normal folks at home. If you used a UNIX at work, sure, you might want to pay the money to have it at home. But why spend the $ for an operating system that didn't have widespread application development? > > I'm probably spoiled from Linux having repositories full of packaged free > software, where the user just has to worry about "which is the best of": > email program, text editor, browser, image manipulation program, video > player, etc. I understand this now pretty well, how spoiled are we these > days. > The proliferation of free software is practically unthinkable from the standpoint of a home user 30 years ago. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Thu Mar 18 07:38:46 2021 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 17 Mar 2021 14:38:46 -0700 Subject: [TUHS] Surprised about Unix System V in the 80's - so sparse! In-Reply-To: References: <20210317203335.GA5249@naleco.com> Message-ID: <20210317213846.GC24642@mcvoy.com> On Wed, Mar 17, 2021 at 02:04:36PM -0700, Al Kossow wrote: > > hey it's 1988 already > >mail without Internet is pretty useless > > And Usenet was tin cans and a string. Usenet was awesome when it was really small. Almost everyone connected was an academic or some sort of scientist. I could post a question in pretty much any discipline and wake up to an answer from someone smart. I tried to get my dad to see it and uttered the fatal words: "Usenet is so cool, I wish everyone was on it." Yep, I'm the guy that ruined Usenet :-) I'm not, but I got my wish and learned quantity is not the same as quality. I was pretty dumb back in the day. --lm From lm at mcvoy.com Thu Mar 18 07:40:59 2021 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 17 Mar 2021 14:40:59 -0700 Subject: [TUHS] Surprised about Unix System V in the 80's - so sparse! In-Reply-To: References: <20210317203335.GA5249@naleco.com> Message-ID: <20210317214059.GD24642@mcvoy.com> On Wed, Mar 17, 2021 at 05:29:40PM -0400, Henry Bent wrote: > > I mean, mail without Internet is pretty useless, althouhg I understand it > > could be useful for inter-company communications. And yes, it had vi and > > the > > Bourne Shell. But still, it feels very very limited, this Xenix version, > > from a user's point of view. > > Which might well explain why Xenix failed to gain much ground with normal > folks at home. If you used a UNIX at work, sure, you might want to pay the > money to have it at home. But why spend the $ for an operating system that > didn't have widespread application development? My first home Unix machine was a 3B1. It was great. There is just something so bloody limiting about DOS when you compare it to Unix. Unix was for developers, DOS was for end users. Entirely different beasts. That said, System V was very limited compared to BSD. BSD was much closer to what we have today, it felt friendly, System V felt sort of corporate. To me at least. --lm From henry.r.bent at gmail.com Thu Mar 18 07:42:41 2021 From: henry.r.bent at gmail.com (Henry Bent) Date: Wed, 17 Mar 2021 17:42:41 -0400 Subject: [TUHS] Surprised about Unix System V in the 80's - so sparse! In-Reply-To: References: <20210317203335.GA5249@naleco.com> Message-ID: Just for a little perspective here: my father worked for Bell Labs as a sysadmin, so we had much more computer exposure and internet access than your average person, and it wasn't until I believe 1992 that we actually got an internet connection at home as opposed to using a terminal with a modem to connect to the labs. Things moved fairly quickly around this time, and there was a huge difference in internet penetration in say 1996 vs. 1992 amongst the general populace. In 1992 you probably would have gotten blank stares asking the average person on the street about the internet, and in 1996 in the next town over there was an internet cafe. Even then, this was the east coast of the US - I'm sure the interior of the country with its much more vast physical distances was a few steps behind. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.douglas.mcilroy at dartmouth.edu Thu Mar 18 09:18:47 2021 From: m.douglas.mcilroy at dartmouth.edu (M Douglas McIlroy) Date: Wed, 17 Mar 2021 19:18:47 -0400 Subject: [TUHS] Surprised about Unix System V in the 80's - so sparse! Message-ID: Connectivity evolved rapidly in the early 1980s. In 1980 I served on the board of CSNet, which connected have-not CS departments (including Bell Labs) via dialup and X.25 links onto the periphery of the magic circle of Arpanet. By 1982 it was not extraordinary that I could via international email arrange all aspects of a trip to visit lively universities of the AUUG. From ggm at algebras.org Thu Mar 18 09:22:42 2021 From: ggm at algebras.org (George Michaelson) Date: Thu, 18 Mar 2021 09:22:42 +1000 Subject: [TUHS] Surprised about Unix System V in the 80's - so sparse! In-Reply-To: References: Message-ID: I often think about Quartermains book "the matrix" and also Carl Malamud's time couch-surfing his contact list. Both of them were very much "of their time" -you wouldn't need to write "the matrix" now, because convergence has taken care of many of the meta-net issues Quartermain talked about. Carls problem on the other hand, just got monetised into AirBNB On Thu, Mar 18, 2021 at 9:19 AM M Douglas McIlroy wrote: > > Connectivity evolved rapidly in the early 1980s. In 1980 I served on the > board of CSNet, which connected have-not CS departments (including Bell > Labs) via dialup and X.25 links onto the periphery of the magic circle > of Arpanet. > By 1982 it was not extraordinary that I could via international email arrange > all aspects of a trip to visit lively universities of the AUUG. From grog at lemis.com Thu Mar 18 11:15:28 2021 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Thu, 18 Mar 2021 12:15:28 +1100 Subject: [TUHS] XENIX or UNIX? (was: Surprised about Unix System V in the 80's - so sparse!) In-Reply-To: <20210317203335.GA5249@naleco.com> References: <20210317203335.GA5249@naleco.com> Message-ID: <20210318011528.GA53947@eureka.lemis.com> On Wednesday, 17 March 2021 at 21:33:37 +0100, Josh Good wrote: > Hello UNIX veterans. > > So I stumbled online upon a copy of the book "SCO Xenix System V Operating > System User's Guide", from 1988, advertised as having 395 pages, and the > asked for price was 2.50 EUROs. I bought it, expecting --well, I don't know > exactly what I was expecting, something quaint and interesting, I suppose. > > I've received the book, and it is not a treasure trobe, to say the least. I > am in fact surprised at how sparse was UNIX System V of this age, almost > spartan. I'm surprised that nobody else mentioned this, but XENIX System V and UNIX System V were two very different beasts. I've used both, and XENIX is considerably worse. > And that's it. The communications part only deals the Micnet (a > serial-port based local networking scheme), and UUCP. No mention at > all of the words "Internet" or "TCP/IP", no even in the Index. It was available, and I had it installed. In fact, somewhere I still have the media, though it's unlikely that they're still readable. But like Interactive UNIX System V/386 (if I have the names, it was commercially oriented and sold each individual component separately, separate media, separate documentation, and these bloody license keys. > I'm probably spoiled from Linux having repositories full of packaged > free software, where the user just has to worry about "which is the > best of": email program, text editor, browser, image manipulation > program, video player, etc. I understand this now pretty well, how > spoiled are we these days. Yes, I had BSD/386 at the same time I actually had to use XENIX, and the difference was like night and day. I moved as much of my development environment to BSD as possible, not helped by XENIX's lack of NFS. I'm not sure it even had X. 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 ggm at algebras.org Thu Mar 18 11:21:26 2021 From: ggm at algebras.org (George Michaelson) Date: Thu, 18 Mar 2021 11:21:26 +1000 Subject: [TUHS] XENIX or UNIX? (was: Surprised about Unix System V in the 80's - so sparse!) In-Reply-To: <20210318011528.GA53947@eureka.lemis.com> References: <20210317203335.GA5249@naleco.com> <20210318011528.GA53947@eureka.lemis.com> Message-ID: System V and Xenix both came out of System III and it had X25 networks, JANET. Albeit indirectly, via something like an RT-11 frontend. System III had real limittions on the compiler. It was a nightmare using code which came from systems which had larger address space, a larger "heap" for CPP #defines (ok heap maybe isn't the word, but you know what I mean) -even down to split I/D stuff, it was just nasty. I think Xenix was a bit of a half-way bet. They didn't invest. No reason it couldn't have become something bigger, HP-UX did. Shame, I think that should have died at birth. On Thu, Mar 18, 2021 at 11:16 AM Greg 'groggy' Lehey wrote: > > On Wednesday, 17 March 2021 at 21:33:37 +0100, Josh Good wrote: > > Hello UNIX veterans. > > > > So I stumbled online upon a copy of the book "SCO Xenix System V Operating > > System User's Guide", from 1988, advertised as having 395 pages, and the > > asked for price was 2.50 EUROs. I bought it, expecting --well, I don't know > > exactly what I was expecting, something quaint and interesting, I suppose. > > > > I've received the book, and it is not a treasure trobe, to say the least. I > > am in fact surprised at how sparse was UNIX System V of this age, almost > > spartan. > > I'm surprised that nobody else mentioned this, but XENIX System V and > UNIX System V were two very different beasts. I've used both, and > XENIX is considerably worse. > > > And that's it. The communications part only deals the Micnet (a > > serial-port based local networking scheme), and UUCP. No mention at > > all of the words "Internet" or "TCP/IP", no even in the Index. > > It was available, and I had it installed. In fact, somewhere I still > have the media, though it's unlikely that they're still readable. But > like Interactive UNIX System V/386 (if I have the names, it was > commercially oriented and sold each individual component separately, > separate media, separate documentation, and these bloody license keys. > > > I'm probably spoiled from Linux having repositories full of packaged > > free software, where the user just has to worry about "which is the > > best of": email program, text editor, browser, image manipulation > > program, video player, etc. I understand this now pretty well, how > > spoiled are we these days. > > Yes, I had BSD/386 at the same time I actually had to use XENIX, and > the difference was like night and day. I moved as much of my > development environment to BSD as possible, not helped by XENIX's lack > of NFS. I'm not sure it even had X. > > 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 rich.salz at gmail.com Thu Mar 18 11:23:08 2021 From: rich.salz at gmail.com (Richard Salz) Date: Wed, 17 Mar 2021 21:23:08 -0400 Subject: [TUHS] Surprised about Unix System V in the 80's - so sparse! In-Reply-To: References: Message-ID: On Wed, Mar 17, 2021, 7:20 PM M Douglas McIlroy < m.douglas.mcilroy at dartmouth.edu> wrote: > Connectivity evolved rapidly in the early 1980s. In 1980 I served on the > board of CSNet, which connected have-not CS departments (including Bell > Labs) via dialup and X.25 links onto the periphery of the magic circle > of Arpanet. I think Steve Bellovin said something about CSNET being what you got with grants and Usenet being what grad students could afford. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wobblygong at gmail.com Thu Mar 18 15:10:22 2021 From: wobblygong at gmail.com (Wesley Parish) Date: Thu, 18 Mar 2021 18:10:22 +1300 Subject: [TUHS] Surprised about Unix System V in the 80's - so sparse! In-Reply-To: References: <20210317203335.GA5249@naleco.com> Message-ID: On 3/18/21, Henry Bent wrote: > On Wed, 17 Mar 2021 at 16:52, Josh Good wrote: > >> >> And that's it. The communications part only deals the Micnet (a >> serial-port >> based local networking scheme), and UUCP. No mention at all of the words >> "Internet" or "TCP/IP", no even in the Index. >> > > Not a total surprise. In 1988, the average home user had probably barely > even heard of the internet. Even business users were only concerned with > on-site networking, and that was a fairly expensive proposition. FWVVLIW, I was not a computer user in 1989, and I had heard of the Internet, such as it was back then, through the pages of a little paperback highly critical of the SDI (or as Arthur C. Clarke retitled it, the BDI - Budgetary Defense Initiative). The author of that book the title of which I can't recall, talked about a computer network that was designed to stay up and working in spite of having bits and pieces shot out of it ... obviously not the Interwebs we today are blessed with, where a half-hearted DDoS can make the experience ... interesting ... if you happen to be on an ISP that's even remotely connected to the site undergoing the DDoS ... at the time I was envious and wished that the Pentagon and the US university system would make it more widely available. Be careful what you wish for (he growls to himself) you just might get it. Wesley Parish > > >> In truth, I fail to see what was the appeal of such a system, for mere >> users, when in the same PC you could run rich DOS-based applications like >> WordPerfect, Lotus 1-2-3, Ventura Publisher and all the PC software from >> those years. >> > > Indeed, from the perspective of a home user you didn't really need an > expensive UNIX box to do normal household chores. I was more than happy > with a Visual 1050 running CP/M (and Wordstar, Multiplan, etc.) well into > the late '80s. > > >> I mean, mail without Internet is pretty useless, althouhg I understand it >> could be useful for inter-company communications. And yes, it had vi and >> the >> Bourne Shell. But still, it feels very very limited, this Xenix version, >> from a user's point of view. >> > > Which might well explain why Xenix failed to gain much ground with normal > folks at home. If you used a UNIX at work, sure, you might want to pay the > money to have it at home. But why spend the $ for an operating system that > didn't have widespread application development? > > >> >> I'm probably spoiled from Linux having repositories full of packaged free >> software, where the user just has to worry about "which is the best of": >> email program, text editor, browser, image manipulation program, video >> player, etc. I understand this now pretty well, how spoiled are we these >> days. >> > > The proliferation of free software is practically unthinkable from the > standpoint of a home user 30 years ago. Shareware was a big concept a few decades ago, and PC/MS/DR DOS was very well supplied with useful programs. Even the Mac had its share, though significantly less than the *DOS family of OSes. It's amusing that Lotus' heavy-handed approach to its 1-2-3 spreadsheet interface succeeded in driving its direct competitors AsEasyAs and some others, into shareware distribution. Nobody as far as I know, ever tried to compete with WordPerfect by copying its interface - the shareware DOS word processors I tried, had their own approach. That small one-man shareware businesses could compete with big multinational companies for market share with products often as good or better, should've given Microsoft pause when it came out swinging against Linux in the late 90s and early 2000s. None so blind as those who will not see. Wesley Parish > > -Henry > From pnr at planet.nl Thu Mar 18 19:44:04 2021 From: pnr at planet.nl (Paul Ruizendaal) Date: Thu, 18 Mar 2021 10:44:04 +0100 Subject: [TUHS] Micnet Was: Re: Surprised about Unix System V in the 80's - so sparse! Message-ID: Micnet would seem to fall within my interest scope of Unix networking 1975-1985. I’ve seen it mentioned before, but I don’t have a clear picture of what it was. There is some sysadmin material on bitsavers about it, but no info on how it worked on the inside or how it relates to other early networking. At first glance it seems to be conceptually related to Berknet. Does anybody here know the backstory to Micnet and/or how it worked? Paul From m at blat.at Thu Mar 18 21:27:26 2021 From: m at blat.at (Mike Knell) Date: Thu, 18 Mar 2021 12:27:26 +0100 Subject: [TUHS] Micnet Was: Re: Surprised about Unix System V in the 80's - so sparse! In-Reply-To: References: Message-ID: > On 18 Mar 2021, at 10:44, Paul Ruizendaal via TUHS wrote: > > Does anybody here know the backstory to Micnet and/or how it worked? The Xenix communications manual has plenty of detail on how to set it up: http://www.nj7p.org/Manuals/PDFs/Intel/174461-001.pdf Looks as if it built a routed network among a set of Xenix machines using conventional serial lines, including remote login / file transfer / mail ervices. Would have been quite a big selling point for software development shops in the days before TCP/IP and ubiquitous connectivity, especially as it looks as if it was decentralised and didn’t require any extra server hardware. MMDF could route mail between Micnet and UUCP. Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From jcapp at anteil.com Thu Mar 18 22:04:48 2021 From: jcapp at anteil.com (Jim Capp) Date: Thu, 18 Mar 2021 07:04:48 -0500 (EST) Subject: [TUHS] Micnet Was: Re: Surprised about Unix System V in the 80's - so sparse! In-Reply-To: Message-ID: <22485620.13.1616069088201.JavaMail.root@zimbraanteil> Yes, we used MMDF quite extensively until TCP/IP. I remember paying $800 for a network card for a PC in the mid 90's. Just this week, I discarded a box filled with old 10/100 cards. From: "Mike Knell via TUHS" To: "Paul Ruizendaal" Cc: "TUHS main list" Sent: Thursday, March 18, 2021 7:27:26 AM Subject: Re: [TUHS] Micnet Was: Re: Surprised about Unix System V in the 80's - so sparse! > On 18 Mar 2021, at 10:44, Paul Ruizendaal via TUHS wrote: > > Does anybody here know the backstory to Micnet and/or how it worked? The Xenix communications manual has plenty of detail on how to set it up: http://www.nj7p.org/Manuals/PDFs/Intel/174461-001.pdf Looks as if it built a routed network among a set of Xenix machines using conventional serial lines, including remote login / file transfer / mail ervices. Would have been quite a big selling point for software development shops in the days before TCP/IP and ubiquitous connectivity, especially as it looks as if it was decentralised and didn’t require any extra server hardware. MMDF could route mail between Micnet and UUCP. Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From lyndon at orthanc.ca Fri Mar 19 09:05:41 2021 From: lyndon at orthanc.ca (Lyndon Nerenberg (VE7TFX/VE6BBM)) Date: Thu, 18 Mar 2021 16:05:41 -0700 Subject: [TUHS] Surprised about Unix System V in the 80's - so sparse! In-Reply-To: <20210317203335.GA5249@naleco.com> References: <20210317203335.GA5249@naleco.com> Message-ID: <1706b9aa2a527423@orthanc.ca> Josh Good writes: > I mean, mail without Internet is pretty useless, In the mid-late-1980s, half the world's email went through 'ihnp4' (google it) via UUCP. That was a cluster of machines running SVRx. We don't need no steenking Internet ... --lyndon From rich.salz at gmail.com Fri Mar 19 11:45:53 2021 From: rich.salz at gmail.com (Richard Salz) Date: Thu, 18 Mar 2021 21:45:53 -0400 Subject: [TUHS] Surprised about Unix System V in the 80's - so sparse! In-Reply-To: <1706b9aa2a527423@orthanc.ca> References: <20210317203335.GA5249@naleco.com> <1706b9aa2a527423@orthanc.ca> Message-ID: > In the mid-late-1980s, half the world's email went through 'ihnp4' (google > it) via UUCP. That was a cluster of machines running SVRx. > When you're the phone company, calls are free. :) This is the best article I saw: www.nobell.org/~gjm/about/ihnp4.html Let's also remember seismo and decvax which had phone bills in the tens of thousands per month. And they weren't free. I was the moderator of mod.sources, everyone wanted to call me. mirror!rs :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Fri Mar 19 12:01:29 2021 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 18 Mar 2021 19:01:29 -0700 Subject: [TUHS] Surprised about Unix System V in the 80's - so sparse! In-Reply-To: References: <20210317203335.GA5249@naleco.com> <1706b9aa2a527423@orthanc.ca> Message-ID: <20210319020129.GO24642@mcvoy.com> On Thu, Mar 18, 2021 at 09:45:53PM -0400, Richard Salz wrote: > > In the mid-late-1980s, half the world's email went through 'ihnp4' (google > > it) via UUCP. That was a cluster of machines running SVRx. > > > > When you're the phone company, calls are free. :) This is the best article > I saw: www.nobell.org/~gjm/about/ihnp4.html Let's also remember seismo and > decvax which had phone bills in the tens of thousands per month. And they > weren't free. > > I was the moderator of mod.sources, everyone wanted to call me. mirror!rs > :) seismo had the connection to Europe. decvax was a thing. A shout out to my Alma Mater, uwvax, it was not ihnp4 but it sent a bunch through. I was ..!uwvax!geophysics!geowhiz!lm for a long time. I used to have all those paths memorized, I'm old. ..!lm From torek at elf.torek.net Fri Mar 19 12:06:04 2021 From: torek at elf.torek.net (Chris Torek) Date: Thu, 18 Mar 2021 19:06:04 -0700 (PDT) Subject: [TUHS] Surprised about Unix System V in the 80's - so sparse! In-Reply-To: <20210319020129.GO24642@mcvoy.com> Message-ID: <202103190206.12J264Af020523@elf.torek.net> We used to say: "Seismo bangs everybody" (then they became uunet, then Worldcom bought them) From earl.baugh at gmail.com Fri Mar 19 12:59:36 2021 From: earl.baugh at gmail.com (Earl Baugh) Date: Thu, 18 Mar 2021 22:59:36 -0400 Subject: [TUHS] Surprised about Unix System V in the 80's - so sparse! In-Reply-To: <202103190206.12J264Af020523@elf.torek.net> References: <202103190206.12J264Af020523@elf.torek.net> Message-ID: <0C0895E9-0C26-44C9-93D0-DBFCE673A023@gmail.com> My first job out of college was at a company (1986ish) that did seismic and meteorological modeling and monitoring. At college we were on csnet ( on our Vax, running BSD 4.2 ). At work, I was deliriously happy to have my own Sun 3/110 to work on, vs having to fight to share the Vax. However, I was having email and Usenet withdrawal... so after completing a 6 month scheduled task In about a month ( thank you lex and yacc :-) ) I was looking for things to fill the time and asked my boss about email. He said, well there is this dedicated line up to Virginia that he used every once in a month and checked his email.. and sometimes helped the seismologists pull some data. He thought the folks on the other end might be able to help. He gave me the name and phone number - it was Rick Adams. ( and yes, this was a dedicated circuit into seismo... well the Annex box physically right next to it :-) ). Shall we say, I called fairly quickly, and was working with David Comay who helped support things there ( the center for seismic studies - css ) and got an early version of CSLIP... Then excitedly ( though a tad nervously) learned how to rebuild a Sun 3/110 kernel and get it installed. The newsfeed and email speed, shall we say, didn’t suck 🙂 Oh, and btw, seismo wasn’t uunet. The original uunet was a sequent 8 processor box ( I believe ). One of my trips to DC I got to visit with David and saw the box as it was there at css with seismo. ( if memory serves me, it was in Ricks office ). Rick had gotten permission to host it there to “see if there was a business model for providing internet access”, which now I think we can definitely answer yes :-) There still is a seismo, but obviously the box isn’t the sun 3/2xx series machine it was then. Earl Sent from my iPhone > On Mar 18, 2021, at 10:27 PM, Chris Torek wrote: > > We used to say: "Seismo bangs everybody" > > (then they became uunet, then Worldcom bought them) From m.douglas.mcilroy at dartmouth.edu Sat Mar 20 02:10:47 2021 From: m.douglas.mcilroy at dartmouth.edu (M Douglas McIlroy) Date: Fri, 19 Mar 2021 12:10:47 -0400 Subject: [TUHS] Surprised about Unix System V in the 80's - so sparse Message-ID: > When you're the phone company, calls are free Not so. But the culture prioritized phone use in a way that's been completely forgotten. High execs would answer their own phones when they were at their desks. "Your call is very important to us. Please wait for the first available representative" would have been anathema. One of my few managerial decrees in the Unix lab was to give a year's notice that "research" would stop forwarding Usenet traffic, not because of phones, but because uucp was becoming a burden on our computer. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From torek at elf.torek.net Sat Mar 20 03:27:23 2021 From: torek at elf.torek.net (Chris Torek) Date: Fri, 19 Mar 2021 10:27:23 -0700 (PDT) Subject: [TUHS] Surprised about Unix System V in the 80's - so sparse! In-Reply-To: <0C0895E9-0C26-44C9-93D0-DBFCE673A023@gmail.com> Message-ID: <202103191727.12JHRNW3025393@elf.torek.net> >Oh, and btw, seismo wasn’t uunet. Yes, I was being deliberately vague with "they" here. :-) >The original uunet was a sequent 8 processor box ( I believe ). I'm not sure what was *original* but they definitely had a Sequent. > On Mar 18, 2021, at 10:27 PM, Chris Torek wrote: > > We used to say: "Seismo bangs everybody" Okay, who stuck a BOM into my email? Chris From dot at dotat.at Sat Mar 20 10:12:23 2021 From: dot at dotat.at (Tony Finch) Date: Sat, 20 Mar 2021 00:12:23 +0000 Subject: [TUHS] XENIX or UNIX? (was: Surprised about Unix System V in the 80's - so sparse!) In-Reply-To: References: <20210317203335.GA5249@naleco.com> <20210318011528.GA53947@eureka.lemis.com> Message-ID: George Michaelson wrote: > > I think Xenix was a bit of a half-way bet. They didn't invest. No > reason it couldn't have become something bigger, HP-UX did. Shame, I > think that should have died at birth. My first job after university was at Demon Internet, which (before becoming an ISP) had been Demon Systems, a Xenix consulting shop. There wasn't much sign of Xenix by the time I worked there (lots of BSD and Solaris) but the mail system still used MMDF (aka "mail munching destruction facility"). Later on (1999ish) we acquired a number of technical staff from SCO around the time it was losing the plot. Tony. -- f.anthony.n.finch https://dotat.at/ Gibraltar Point to North Foreland: Northeasterly 3 to 5, becoming variable, then westerly or northwesterly later, 3 or 4. Smooth or slight. Occasional drizzle, fog patches for a time in north. Moderate or good, occasionally very poor in north. From pepe at naleco.com Sat Mar 20 21:50:19 2021 From: pepe at naleco.com (Josh Good) Date: Sat, 20 Mar 2021 12:50:19 +0100 Subject: [TUHS] Micnet Was: Re: Surprised about Unix System V in the 80's - so sparse! In-Reply-To: References: Message-ID: <20210320115018.GA9713@naleco.com> On 2021 Mar 18, 12:27, Mike Knell via TUHS wrote: > > > On 18 Mar 2021, at 10:44, Paul Ruizendaal via TUHS wrote: > > > > Does anybody here know the backstory to Micnet and/or how it worked? > > The Xenix communications manual has plenty of detail on how to set it up: > http://www.nj7p.org/Manuals/PDFs/Intel/174461-001.pdf > > Looks as if it built a routed network among a set of Xenix machines using > conventional serial lines, including remote login / file transfer / mail > ervices. This SCO technical article explains in detail how to set up Micnet networking on SCO Unix. https://www.scosales.com/ta/kb/103649.htmlOB Amusingly, the article says "The System Administrator's Guide for older versions of SCO UNIX System V/386 contained a section on the Micnet network, but this is not present in the SCO UNIX System V Release 3.2 Version 4.0 documentation. The documentation for this network is provided here. Users who wish to use this network system will require this documentation." So it seems by the early 90's SCO was indeed phasing out the old Xenix Micnet networking scheme. Reading that article is interesting, and Micnet seems to have been a fragile concoction. The article even says at the end: "You can only use mail to transfer small files. Large files are randomly truncated by mail." Not the most reassuring thing to read about the computer system you are using... -- Josh Good From lm at mcvoy.com Sun Mar 21 01:16:32 2021 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 20 Mar 2021 08:16:32 -0700 Subject: [TUHS] Micnet Was: Re: Surprised about Unix System V in the 80's - so sparse! In-Reply-To: <20210320115018.GA9713@naleco.com> References: <20210320115018.GA9713@naleco.com> Message-ID: <20210320151632.GM2912@mcvoy.com> On Sat, Mar 20, 2021 at 12:50:19PM +0100, Josh Good wrote: > https://www.scosales.com/ta/kb/103649.htmlOB I thought SCO had long since died. Did they open source it and is this company providing support? As fun as ancient Unix is, SCO was pretty sparse and not in a good way. From wobblygong at gmail.com Sun Mar 21 10:08:55 2021 From: wobblygong at gmail.com (Wesley Parish) Date: Sun, 21 Mar 2021 13:08:55 +1300 Subject: [TUHS] Micnet Was: Re: Surprised about Unix System V in the 80's - so sparse! In-Reply-To: <20210320151632.GM2912@mcvoy.com> References: <20210320115018.GA9713@naleco.com> <20210320151632.GM2912@mcvoy.com> Message-ID: It reads as if this company was a support company for SCO sites from way back, and quietly carried on supporting SCO Unix sites when Caldera blew a fuse and became The SCO Group and started some unfathomably stupid lawsuits. Wesley Parish On 3/21/21, Larry McVoy wrote: > On Sat, Mar 20, 2021 at 12:50:19PM +0100, Josh Good wrote: >> https://www.scosales.com/ta/kb/103649.htmlOB > > I thought SCO had long since died. Did they open source it and is this > company providing support? > > As fun as ancient Unix is, SCO was pretty sparse and not in a good way. > From lm at mcvoy.com Sun Mar 21 10:18:43 2021 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 20 Mar 2021 17:18:43 -0700 Subject: [TUHS] Micnet Was: Re: Surprised about Unix System V in the 80's - so sparse! In-Reply-To: References: <20210320115018.GA9713@naleco.com> <20210320151632.GM2912@mcvoy.com> Message-ID: <20210321001843.GX2912@mcvoy.com> Yeah, but wouldn't that mean that SCO Unix had to be open sourced? Or did they buy the rights? While I mostly can't believe anyone would want SCO Unix, I do know that they ran a lot of cash registers, or maybe they were the server, I dunno, somehow point of sale and SCO was a thing a long time ago. So maybe it is a legacy thing? On Sun, Mar 21, 2021 at 01:08:55PM +1300, Wesley Parish wrote: > It reads as if this company was a support company for SCO sites from > way back, and quietly carried on supporting SCO Unix sites when > Caldera blew a fuse and became The SCO Group and started some > unfathomably stupid lawsuits. > > Wesley Parish > > On 3/21/21, Larry McVoy wrote: > > On Sat, Mar 20, 2021 at 12:50:19PM +0100, Josh Good wrote: > >> https://www.scosales.com/ta/kb/103649.htmlOB > > > > I thought SCO had long since died. Did they open source it and is this > > company providing support? > > > > As fun as ancient Unix is, SCO was pretty sparse and not in a good way. > > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From grog at lemis.com Sun Mar 21 11:12:17 2021 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Sun, 21 Mar 2021 12:12:17 +1100 Subject: [TUHS] Micnet Was: Re: Surprised about Unix System V in the 80's - so sparse! In-Reply-To: <20210321001843.GX2912@mcvoy.com> References: <20210320115018.GA9713@naleco.com> <20210320151632.GM2912@mcvoy.com> <20210321001843.GX2912@mcvoy.com> Message-ID: <20210321011217.GA60525@eureka.lemis.com> On Saturday, 20 March 2021 at 17:18:43 -0700, Larry McVoy wrote: > Yeah, but wouldn't that mean that SCO Unix had to be open sourced? > Or did they buy the rights? They didn't "open source" SCO, but in January 2002 they released "ancient Unix" under a "BSD-style" license. See http://www.lemis.com/grog/UNIX/ But I'm sure everybody knows that. > While I mostly can't believe anyone would want SCO Unix, I do know that > they ran a lot of cash registers, or maybe they were the server, I dunno, > somehow point of sale and SCO was a thing a long time ago. So maybe it > is a legacy thing? I haven't been following SCO recently, but at some point they had taken UnixWare from Novell. I'm sure that, too, is common knowledge. 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 Mar 21 11:31:26 2021 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 20 Mar 2021 18:31:26 -0700 Subject: [TUHS] Micnet Was: Re: Surprised about Unix System V in the 80's - so sparse! In-Reply-To: <20210321011217.GA60525@eureka.lemis.com> References: <20210320115018.GA9713@naleco.com> <20210320151632.GM2912@mcvoy.com> <20210321001843.GX2912@mcvoy.com> <20210321011217.GA60525@eureka.lemis.com> Message-ID: <20210321013126.GY2912@mcvoy.com> So this is just me, I'm not a fan of SCO even though I was the guy that added TCP/IP to that OS. SCO just felt like it was the back burner. Sun felt like it was the front burner that was pushing things forward. SCO was the team that said they had this and did nothing with it. On Sun, Mar 21, 2021 at 12:12:17PM +1100, Greg 'groggy' Lehey wrote: > On Saturday, 20 March 2021 at 17:18:43 -0700, Larry McVoy wrote: > > Yeah, but wouldn't that mean that SCO Unix had to be open sourced? > > Or did they buy the rights? > > They didn't "open source" SCO, but in January 2002 they released > "ancient Unix" under a "BSD-style" license. See > http://www.lemis.com/grog/UNIX/ > But I'm sure everybody knows that. > > > While I mostly can't believe anyone would want SCO Unix, I do know that > > they ran a lot of cash registers, or maybe they were the server, I dunno, > > somehow point of sale and SCO was a thing a long time ago. So maybe it > > is a legacy thing? > > I haven't been following SCO recently, but at some point they had > taken UnixWare from Novell. I'm sure that, too, is common knowledge. > > 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 kevin.bowling at kev009.com Sun Mar 21 11:42:50 2021 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Sat, 20 Mar 2021 18:42:50 -0700 Subject: [TUHS] Micnet Was: Re: Surprised about Unix System V in the 80's - so sparse! In-Reply-To: <20210321013126.GY2912@mcvoy.com> References: <20210320115018.GA9713@naleco.com> <20210320151632.GM2912@mcvoy.com> <20210321001843.GX2912@mcvoy.com> <20210321011217.GA60525@eureka.lemis.com> <20210321013126.GY2912@mcvoy.com> Message-ID: SCO is still around in some form. I believe it’s mostly just a support offering. They converged on two products in the ‘90s: OpenServer (SVR3) and UnixWare (SVR4). It seems like most people preferred or were stuck on OpenServer while UnixWare would have eventually been a nicer system but I don’t know first hand. They also shipped a version of FreeBSD 10 commercially a handful of years ago. On Sat, Mar 20, 2021 at 6:32 PM Larry McVoy wrote: > So this is just me, I'm not a fan of SCO even though I was the guy that > added TCP/IP to that OS. > > SCO just felt like it was the back burner. Sun felt like it was the > front burner that was pushing things forward. SCO was the team that > said they had this and did nothing with it. > > On Sun, Mar 21, 2021 at 12:12:17PM +1100, Greg 'groggy' Lehey wrote: > > On Saturday, 20 March 2021 at 17:18:43 -0700, Larry McVoy wrote: > > > Yeah, but wouldn't that mean that SCO Unix had to be open sourced? > > > Or did they buy the rights? > > > > They didn't "open source" SCO, but in January 2002 they released > > "ancient Unix" under a "BSD-style" license. See > > http://www.lemis.com/grog/UNIX/ > > But I'm sure everybody knows that. > > > > > While I mostly can't believe anyone would want SCO Unix, I do know that > > > they ran a lot of cash registers, or maybe they were the server, I > dunno, > > > somehow point of sale and SCO was a thing a long time ago. So maybe it > > > is a legacy thing? > > > > I haven't been following SCO recently, but at some point they had > > taken UnixWare from Novell. I'm sure that, too, is common knowledge. > > > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From grog at lemis.com Sun Mar 21 12:38:09 2021 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Sun, 21 Mar 2021 13:38:09 +1100 Subject: [TUHS] SCO marketing FreeBSD (was: Micnet, Was: Surprised about Unix System V in the 80's - so sparse!) In-Reply-To: References: <20210320115018.GA9713@naleco.com> <20210320151632.GM2912@mcvoy.com> <20210321001843.GX2912@mcvoy.com> <20210321011217.GA60525@eureka.lemis.com> <20210321013126.GY2912@mcvoy.com> Message-ID: <20210321023809.GB60525@eureka.lemis.com> On Saturday, 20 March 2021 at 18:42:50 -0700, Kevin Bowling wrote: > SCO is still around in some form. ... They also shipped a version > of FreeBSD 10 commercially a handful of years ago. They did? Do you have details? From the version number it sounds as if it must have been at a time when most people already thought they were dead. 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 kevin.bowling at kev009.com Sun Mar 21 12:43:17 2021 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Sat, 20 Mar 2021 19:43:17 -0700 Subject: [TUHS] SCO marketing FreeBSD (was: Micnet, Was: Surprised about Unix System V in the 80's - so sparse!) In-Reply-To: <20210321023809.GB60525@eureka.lemis.com> References: <20210320115018.GA9713@naleco.com> <20210320151632.GM2912@mcvoy.com> <20210321001843.GX2912@mcvoy.com> <20210321011217.GA60525@eureka.lemis.com> <20210321013126.GY2912@mcvoy.com> <20210321023809.GB60525@eureka.lemis.com> Message-ID: The Wikipedia article isn’t bad: https://en.wikipedia.org/wiki/OpenServer The only first hand info I can add is the money guy passed away a couple years ago, which probably put things into limbo and I’m not sure who is at the helm of Xinuos now. When I last talked to their engineering director they had non-trivial revenue supporting the old products, enough to run several product development engineers apart from whatever else it took to keep the lights on. On Sat, Mar 20, 2021 at 7:38 PM Greg 'groggy' Lehey wrote: > On Saturday, 20 March 2021 at 18:42:50 -0700, Kevin Bowling wrote: > > SCO is still around in some form. ... They also shipped a version > > of FreeBSD 10 commercially a handful of years ago. > > They did? Do you have details? From the version number it sounds as > if it must have been at a time when most people already thought they > were dead. > > 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 -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sun Mar 21 13:02:35 2021 From: imp at bsdimp.com (Warner Losh) Date: Sat, 20 Mar 2021 21:02:35 -0600 Subject: [TUHS] SCO marketing FreeBSD (was: Micnet, Was: Surprised about Unix System V in the 80's - so sparse!) In-Reply-To: References: <20210320115018.GA9713@naleco.com> <20210320151632.GM2912@mcvoy.com> <20210321001843.GX2912@mcvoy.com> <20210321011217.GA60525@eureka.lemis.com> <20210321013126.GY2912@mcvoy.com> <20210321023809.GB60525@eureka.lemis.com> Message-ID: On Sat, Mar 20, 2021, 8:44 PM Kevin Bowling wrote: > The Wikipedia article isn’t bad: > https://en.wikipedia.org/wiki/OpenServer > > The only first hand info I can add is the money guy passed away a couple > years ago, which probably put things into limbo and I’m not sure who is at > the helm of Xinuos now. When I last talked to their engineering director > they had non-trivial revenue supporting the old products, enough to run > several product development engineers apart from whatever else it took to > keep the lights on. > I'd love to hear more recent news... Warner Ps I sent off a message to the FreeBSD developer list to see any one there knows. Hope I'm not stepping on any toes... On Sat, Mar 20, 2021 at 7:38 PM Greg 'groggy' Lehey wrote: > >> On Saturday, 20 March 2021 at 18:42:50 -0700, Kevin Bowling wrote: >> > SCO is still around in some form. ... They also shipped a version >> > of FreeBSD 10 commercially a handful of years ago. >> >> They did? Do you have details? From the version number it sounds as >> if it must have been at a time when most people already thought they >> were dead. >> >> 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 -------------- An HTML attachment was scrubbed... URL: From grog at lemis.com Sun Mar 21 13:04:25 2021 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Sun, 21 Mar 2021 14:04:25 +1100 Subject: [TUHS] SCO marketing FreeBSD (was: Micnet, Was: Surprised about Unix System V in the 80's - so sparse!) In-Reply-To: References: <20210320115018.GA9713@naleco.com> <20210320151632.GM2912@mcvoy.com> <20210321001843.GX2912@mcvoy.com> <20210321011217.GA60525@eureka.lemis.com> <20210321013126.GY2912@mcvoy.com> <20210321023809.GB60525@eureka.lemis.com> Message-ID: <20210321030425.GD60525@eureka.lemis.com> On Saturday, 20 March 2021 at 21:02:35 -0600, Warner Losh wrote: > On Sat, Mar 20, 2021, 8:44 PM Kevin Bowling > wrote: > >> The Wikipedia article isn???t bad: >> https://en.wikipedia.org/wiki/OpenServer >> >> The only first hand info I can add is the money guy passed away a couple >> years ago, which probably put things into limbo and I???m not sure who is at >> the helm of Xinuos now. When I last talked to their engineering director >> they had non-trivial revenue supporting the old products, enough to run >> several product development engineers apart from whatever else it took to >> keep the lights on. > > I'd love to hear more recent news... So would I. I wonder if they're still basing on FreeBSD 10. > Ps I sent off a message to the FreeBSD developer list to see any one > there knows. Hope I'm not stepping on any toes... You didn't exactly mention your sources. Looks fine to me. 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 imp at bsdimp.com Sun Mar 21 13:09:10 2021 From: imp at bsdimp.com (Warner Losh) Date: Sat, 20 Mar 2021 21:09:10 -0600 Subject: [TUHS] SCO marketing FreeBSD (was: Micnet, Was: Surprised about Unix System V in the 80's - so sparse!) In-Reply-To: <20210321030425.GD60525@eureka.lemis.com> References: <20210320115018.GA9713@naleco.com> <20210320151632.GM2912@mcvoy.com> <20210321001843.GX2912@mcvoy.com> <20210321011217.GA60525@eureka.lemis.com> <20210321013126.GY2912@mcvoy.com> <20210321023809.GB60525@eureka.lemis.com> <20210321030425.GD60525@eureka.lemis.com> Message-ID: On Sat, Mar 20, 2021, 9:04 PM Greg 'groggy' Lehey wrote: > On Saturday, 20 March 2021 at 21:02:35 -0600, Warner Losh wrote: > > On Sat, Mar 20, 2021, 8:44 PM Kevin Bowling > > wrote: > > > >> The Wikipedia article isn???t bad: > >> https://en.wikipedia.org/wiki/OpenServer > >> > >> The only first hand info I can add is the money guy passed away a couple > >> years ago, which probably put things into limbo and I???m not sure who > is at > >> the helm of Xinuos now. When I last talked to their engineering > director > >> they had non-trivial revenue supporting the old products, enough to run > >> several product development engineers apart from whatever else it took > to > >> keep the lights on. > > > > I'd love to hear more recent news... > > So would I. I wonder if they're still basing on FreeBSD 10. > > > Ps I sent off a message to the FreeBSD developer list to see any one > > there knows. Hope I'm not stepping on any toes... > > You didn't exactly mention your sources. Looks fine to me. > True. I couldn't recall if Kevin has a commit bit still or not.... if need be, I'll send a follow up... Warner 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 -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Sun Mar 21 16:53:12 2021 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 21 Mar 2021 17:53:12 +1100 (EST) Subject: [TUHS] SCO marketing FreeBSD (was: Micnet, Was: Surprised about Unix System V in the 80's - so sparse!) In-Reply-To: <20210321030425.GD60525@eureka.lemis.com> References: <20210320115018.GA9713@naleco.com> <20210320151632.GM2912@mcvoy.com> <20210321001843.GX2912@mcvoy.com> <20210321011217.GA60525@eureka.lemis.com> <20210321013126.GY2912@mcvoy.com> <20210321023809.GB60525@eureka.lemis.com> <20210321030425.GD60525@eureka.lemis.com> Message-ID: On Sun, 21 Mar 2021, Greg 'groggy' Lehey wrote: >> I'd love to hear more recent news... > > So would I. I wonder if they're still basing on FreeBSD 10. Well, I'm still on 10: FreeBSD aneurin.horsfall.org 10.4-RELEASE-p13 FreeBSD 10.4-RELEASE-p13 #0: Thu Sep 27 09:21:23 UTC 2018 root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 Just not enough hours in the day when one is retired... I have a spare (and faster) box waiting for RELEASE once I get a round tuit, based upon my experiences with partition sizes[*] with the old box (I refuse to sling everything under "/"). [*] Dreadful things happen if /tmp is "tmpfs", /tmp fills up with a massive compilation, and swap was too small... -- Dave From skogtun at gmail.com Sun Mar 21 21:01:55 2021 From: skogtun at gmail.com (Harald Arnesen) Date: Sun, 21 Mar 2021 12:01:55 +0100 Subject: [TUHS] SCO marketing FreeBSD (was: Micnet, Was: Surprised about Unix System V in the 80's - so sparse!) In-Reply-To: <20210321023809.GB60525@eureka.lemis.com> References: <20210320115018.GA9713@naleco.com> <20210320151632.GM2912@mcvoy.com> <20210321001843.GX2912@mcvoy.com> <20210321011217.GA60525@eureka.lemis.com> <20210321013126.GY2912@mcvoy.com> <20210321023809.GB60525@eureka.lemis.com> Message-ID: <4d21f4d1-1c1b-53c3-b55f-45549602b30b@gmail.com> Greg 'groggy' Lehey [21.03.2021 03:38]: > On Saturday, 20 March 2021 at 18:42:50 -0700, Kevin Bowling wrote: >> SCO is still around in some form. ... They also shipped a version >> of FreeBSD 10 commercially a handful of years ago. > > They did? Do you have details? From the version number it sounds as > if it must have been at a time when most people already thought they > were dead. > > Greg The time here is B.C. (Before Coffee), so I had shaky fingers and sent it only to Greg, not the list. Anyway: -- Hilsen Harald From arnold at skeeve.com Tue Mar 23 23:17:04 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 23 Mar 2021 07:17:04 -0600 Subject: [TUHS] Transfer of Plan 9 to the Plan 9 Foundation Message-ID: <202103231317.12NDH434004068@freefriends.org> FYI, folks. Arnold > Date: Tue, 23 Mar 2021 06:06:49 -0700 > From: a at 9srv.net > To: 9fans at 9fans.net > Subject: [9fans] Transfer of Plan 9 to the Plan 9 Foundation > > We are thrilled to announce that Nokia has transferred the copyright of > Plan 9 to the Plan 9 Foundation. This transfer applies to all of the > Plan 9 from Bell Labs code, from the earliest days through their final > release. > > The most exciting immediate effect of this is that the Plan 9 Foundation > is making the historical 1st through 4th editions of Plan 9 available > under the terms of the MIT license. These are the releases as they > existed at the time, with minimal changes to reflect the above. > > 1st and 2nd edition were never released as open source software, and > both (but especially 1st edition) were only available to a very small > number of people. 3rd and 4th were previously available as open source, > but under a license which was problematic for some people (especially > the 3rd edition). We think making these available under the MIT license > is something that's going to be a significant benefit for all projects > using Plan 9 code. While this doesn't automatically change the license > on any downstream projects, and you're welcome to keep using the LPL if > you like, you now have the option of switching to MIT, which we think > most everyone will find preferable. > > Obviously, for folks in the Plan 9 community, there isn't a way to say > "thank you" to Bell Labs, and its various parent organizations, that's > really adequate. None of us would be talking about any of this if it > weren't for the work done there for decades. All of us here at the Plan > 9 Foundation express our sincerest thanks to the team at Nokia who made > this possible, the Plan 9 alumni who supported the effort, and the Plan > 9 community who have kept kernels booting and the userland useful. > > The historical releases are available right now at: > https://p9f.org/dl/ > > You can read Nokia's press release on the transfer here: > https://www.bell-labs.com/institute/blog/plan-9-bell-labs-cyberspace/ > > Thank you for your time, > Anthony Sorace > Plan 9 Foundation > > ------------------------------------------ > 9fans: 9fans > Permalink: https://9fans.topicbox.com/groups/9fans/Tf20bce89ef96d4b6-M63f81768e4ffdfa4df402ec5 > Delivery options: https://9fans.topicbox.com/groups/9fans/subscription From m.douglas.mcilroy at dartmouth.edu Thu Mar 25 07:03:16 2021 From: m.douglas.mcilroy at dartmouth.edu (M Douglas McIlroy) Date: Wed, 24 Mar 2021 17:03:16 -0400 Subject: [TUHS] [TUHS} .ss paragraph-style-footnote example, then and now Message-ID: As the example came through in my mail reader--in a different, proportionally spaced font, the effect of .ll in the examples was hard to figure out. Which of the two line lengths in the new case is actually operative? Why are the inch lengths in the old and new examples so different? The new example is ticklish, since it depends on the peculiar AI that identifies sentence endings. Suppose reference 1 is naively broken after "Soc." I prefer the old example because it's clean to read, isn't mixed up with AI, and incidentally illustrates a nontrivial use for .nop. Doug > The example itself originally read: > > .ll 4.5i > 1.\ This is the first footnote.\c > .ss 48 > .nop > .ss 12 > 2.\ This is the second footnote. > > RESULT: > > 1. This is the first footnote. 2. This > is the second footnote. > > The new version of this example is: > > .ie n .ll 50n > .el .ll 2.75i > .ss 12 48 > 1. J. Fict. Ch. Soc. 6 (2020), 3\[en]14. > 2. Better known for other work. > > RESULT: > > 1. J. Fict. Ch. Soc. 6 (2020), 3-14. 2. Better > known for other work. From scj at yaccman.com Sun Mar 28 16:29:49 2021 From: scj at yaccman.com (scj at yaccman.com) Date: Sat, 27 Mar 2021 23:29:49 -0700 Subject: [TUHS] ching in Unix In-Reply-To: <20210128214551.GA27614@minnie.tuhs.org> References: <20210128214551.GA27614@minnie.tuhs.org> Message-ID: <3419319f084c8149953ab6eefcc44fb4@yaccman.com> I probably wrote the first version of Ching. You could type a question as an argument and it would hash the question and use it to simulate yarrow sticks. I used a small book for the "prophecies", and at some point realized that it was probably some kind of copyright violation so I dropped it. It's quite possible that others tinkered with it as well, that being the way the world worked then. --- On 2021-01-28 13:45, Warren Toomey wrote: > https://ewe2.ninja/stuff/computers/ching/ > > Interesting story! > > Cheers, Warren From noel.hunt at gmail.com Mon Mar 29 07:56:16 2021 From: noel.hunt at gmail.com (Noel Hunt) Date: Mon, 29 Mar 2021 08:56:16 +1100 Subject: [TUHS] ching in Unix In-Reply-To: <3419319f084c8149953ab6eefcc44fb4@yaccman.com> References: <20210128214551.GA27614@minnie.tuhs.org> <3419319f084c8149953ab6eefcc44fb4@yaccman.com> Message-ID: >From the manual entry: Using an algorithm suggested by S. C. Johnson, the Unix ora- cle simply reads a question from the standard input (up to an EOF) and hashes the individual characters in combination with other indicia which happen to be lying around the sys- tem. The resulting value is used as the seed of a random number generator which drives a simulated coin-toss divina- tion. The answer appears on the standard output. I was always convinced that the presence of the word 'indicia' indicated (pun intended) that Dennis Ritchie had his hand in it. Who in the Unix world today writes, would even be able to write, a manual entry like that. On Sun, Mar 28, 2021 at 5:37 PM wrote: > I probably wrote the first version of Ching. You could type a question > as an argument and it would hash the question and use it to simulate > yarrow sticks. I used a small book for the "prophecies", and at some > point realized that it was probably some kind of copyright violation so > I dropped it. It's quite possible that others tinkered with it as well, > that being the way the world worked then. > > > --- > > > On 2021-01-28 13:45, Warren Toomey wrote: > > https://ewe2.ninja/stuff/computers/ching/ > > > > Interesting story! > > > > Cheers, Warren > -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman at oclsc.org Mon Mar 29 08:31:57 2021 From: norman at oclsc.org (Norman Wilson) Date: Sun, 28 Mar 2021 18:31:57 -0400 Subject: [TUHS] ching in Unix Message-ID: <1616970721.23881.for-standards-violators@oclsc.org> Noel Hunt: Who in the Unix world today writes, would even be able to write, a manual entry like that. ==== Doug McIlroy is still around, though (alas) he doesn't write many manual entries these days. Norman Wilson Toronto ON From noel.hunt at gmail.com Mon Mar 29 12:06:53 2021 From: noel.hunt at gmail.com (Noel Hunt) Date: Mon, 29 Mar 2021 13:06:53 +1100 Subject: [TUHS] ching in Unix In-Reply-To: <1616970721.23881.for-standards-violators@oclsc.org> References: <1616970721.23881.for-standards-violators@oclsc.org> Message-ID: An unconscionable oversight on my part; yes Doug McIlroy is also a fine writer of prose. On Mon, Mar 29, 2021 at 9:33 AM Norman Wilson wrote: > Noel Hunt: > > Who in the Unix world today > writes, would even be able to write, a manual entry like that. > > ==== > > Doug McIlroy is still around, though (alas) he doesn't write > many manual entries these days. > > Norman Wilson > Toronto ON > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Tue Mar 30 00:34:49 2021 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 29 Mar 2021 07:34:49 -0700 Subject: [TUHS] Remember the ed thread? Message-ID: <20210329143449.GA28080@mcvoy.com> I had *.clients.your-server.de crawling mcvoy.com in violation of my robots.txt. For whatever reason, the tty settings (or something) made vi not work, I dunno what the deal is, stty -tabs didn't help. So I had to resort to ed to write and debug the little program below. It was surprisingly pleasant, it's probably the first time I've used ed for anything real in at least a decade. My fingers still know it. +1 for ed. It's how many decades old and still useful? #!/usr/libexec/bitkeeper/bk tclsh int main(void) { FILE log = popen("/var/log/apache2/dns.l", "r"); string buf, ip; string dropped{string}; fconfigure(log, buffering: "line"); while (buf = ) { unless (buf =~ /([^ ]+\.your-server\.de\.) /) continue; ip = $1; if (defined(dropped{ip})) continue; dropped{ip} = "yes"; warn("DROP ${ip}\n"); system("/sbin/iptables -I INPUT -s ${ip} -j DROP"); } } From anders at adamsgaard.dk Tue Mar 30 01:09:18 2021 From: anders at adamsgaard.dk (Anders Damsgaard) Date: Mon, 29 Mar 2021 17:09:18 +0200 Subject: [TUHS] Remember the ed thread? In-Reply-To: <20210329143449.GA28080@mcvoy.com> References: <20210329143449.GA28080@mcvoy.com> Message-ID: * Larry McVoy [2021-03-29 07:34:49 -0700]: >I had *.clients.your-server.de crawling mcvoy.com in violation of my >robots.txt. For whatever reason, the tty settings (or something) >made vi not work, I dunno what the deal is, stty -tabs didn't help. > >So I had to resort to ed to write and debug the little program below. >It was surprisingly pleasant, it's probably the first time I've used ed >for anything real in at least a decade. My fingers still know it. > >+1 for ed. It's how many decades old and still useful? I recently learned ed(1) for the first time (I have a unix beard, but it's not grey yet). I found ed to be very efficient and useful for small fixes, even on slow connections. This beginner's tutorial was very helpful for me: gopher://katolaz.net/0/ed_tutorial.txt (https mirror for non-gopher clients: https://adamsgaard.dk/npub/ed_tutorial.txt ) From brantley at coraid.com Tue Mar 30 01:26:51 2021 From: brantley at coraid.com (Brantley Coile) Date: Mon, 29 Mar 2021 15:26:51 +0000 Subject: [TUHS] Remember the ed thread? In-Reply-To: References: <20210329143449.GA28080@mcvoy.com> Message-ID: >From 1984, when I stopped using vi (vee eye), until the early 1990's, when I could use Sam, I used a slightly hacked version of ed. I added what the Labs called the "b" command. I had use some other character. Dennis Ritchie sent me a 8th Edition Unix manual, and I saw they had added almost the same thing and called the command by the second letter. Vi called it the last letter, "z." I've never found ed slows me down. Some things I would have used awk/sed for that I now use Sam's command window for, but that's a bad thing. I still use ed a lot along side Sam. > On Mar 29, 2021, at 11:09 AM, Anders Damsgaard wrote: > > * Larry McVoy [2021-03-29 07:34:49 -0700]: > >> I had *.clients.your-server.de crawling mcvoy.com in violation of my >> robots.txt. For whatever reason, the tty settings (or something) >> made vi not work, I dunno what the deal is, stty -tabs didn't help. >> >> So I had to resort to ed to write and debug the little program below. >> It was surprisingly pleasant, it's probably the first time I've used ed >> for anything real in at least a decade. My fingers still know it. >> >> +1 for ed. It's how many decades old and still useful? > > I recently learned ed(1) for the first time (I have a unix beard, but it's > not grey yet). I found ed to be very efficient and useful for small fixes, > even on slow connections. This beginner's tutorial was very helpful > for me: gopher://katolaz.net/0/ed_tutorial.txt > > (https mirror for non-gopher clients: > https://adamsgaard.dk/npub/ed_tutorial.txt ) From vanattenmark at gmail.com Tue Mar 30 01:36:38 2021 From: vanattenmark at gmail.com (Mark van Atten) Date: Mon, 29 Mar 2021 17:36:38 +0200 Subject: [TUHS] Remember the ed thread? In-Reply-To: References: <20210329143449.GA28080@mcvoy.com> Message-ID: On Mon, 29 Mar 2021 at 17:27, Brantley Coile wrote: >Some things I would have used awk/sed > for that I now use Sam's command window for, but that's a bad thing. Why is that a bad thing? (Informative question.) Mark. From clemc at ccc.com Tue Mar 30 01:37:57 2021 From: clemc at ccc.com (Clem Cole) Date: Mon, 29 Mar 2021 11:37:57 -0400 Subject: [TUHS] Remember the ed thread? In-Reply-To: References: <20210329143449.GA28080@mcvoy.com> Message-ID: Anders -- good for you. That said, as one of those 'grey beards,' can I recommend that you stop, and go to a technical library or bookstore and find yourself a copy of Rob and Brian's wonderful book: "*The Unix Programming Environment*" (*a.k.a* "UPE" or ISBN 0-13-937699-2) *then do the exercises*. That book is still relevant today - a little secret, I give a copy of it and "*Advanced Programming in the Unix Environment*" (*a.k.a.* "APUE") to all my new engineers - even though they are all using 'Linux' for their work. To those that object at first, I remind them, Linux is just the current and most popular implementation of the ideas from Ken, Dennis, Doug, and friends and I'm sure they will learn something from the time invested[1]. FWIW: Besides learning ed (which will help you unlock some of the mysteries of other UNIX tools like grep and sed), take a shot at looking at the introduction to nroff/troff (as has been discussed here - not to restart a war). Learning to use a 'document compiler' like the troff family is never a bad investment. Have fun, Clem 1.] BTW I have yet had a young engineer that actually did try the exercises not come back and say something like "Wow, I never knew ...." I don't gloat, but I smile inside, know that I just made them a more effective for our team. If they ask, I point out I had been using UNIX and hacking on the kernel most every day for at least 10 years when it first appeared in the early 80's (84/85 I think), and I learned a few tricks when I read it. ᐧ ᐧ On Mon, Mar 29, 2021 at 11:16 AM Anders Damsgaard wrote: > * Larry McVoy [2021-03-29 07:34:49 -0700]: > > >I had *.clients.your-server.de crawling mcvoy.com in violation of my > >robots.txt. For whatever reason, the tty settings (or something) > >made vi not work, I dunno what the deal is, stty -tabs didn't help. > > > >So I had to resort to ed to write and debug the little program below. > >It was surprisingly pleasant, it's probably the first time I've used ed > >for anything real in at least a decade. My fingers still know it. > > > >+1 for ed. It's how many decades old and still useful? > > I recently learned ed(1) for the first time (I have a unix beard, but it's > not grey yet). I found ed to be very efficient and useful for small fixes, > even on slow connections. This beginner's tutorial was very helpful > for me: gopher://katolaz.net/0/ed_tutorial.txt > > (https mirror for non-gopher clients: > https://adamsgaard.dk/npub/ed_tutorial.txt ) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anders at adamsgaard.dk Tue Mar 30 01:42:00 2021 From: anders at adamsgaard.dk (Anders Damsgaard) Date: Mon, 29 Mar 2021 17:42:00 +0200 Subject: [TUHS] Remember the ed thread? In-Reply-To: References: <20210329143449.GA28080@mcvoy.com> Message-ID: * Clem Cole [2021-03-29 11:37:57 -0400]: >Anders -- good for you. > >That said, as one of those 'grey beards,' can I recommend that you stop, >and go to a technical library or bookstore and find yourself a copy of Rob >and Brian's wonderful book: "*The Unix Programming Environment*" (*a.k.a* >"UPE" or ISBN 0-13-937699-2) *then do the exercises*. That book is still >relevant today - a little secret, I give a copy of it and "*Advanced >Programming in the Unix Environment*" (*a.k.a.* "APUE") to all my new >engineers - even though they are all using 'Linux' for their work. To >those that object at first, I remind them, Linux is just the current and >most popular implementation of the ideas from Ken, Dennis, Doug, and >friends and I'm sure they will learn something from the time invested[1]. > >FWIW: Besides learning ed (which will help you unlock some of the mysteries >of other UNIX tools like grep and sed), take a shot at looking at the >introduction to nroff/troff (as has been discussed here - not to restart a >war). Learning to use a 'document compiler' like the troff family is never >a bad investment. > >Have fun, >Clem > > >1.] BTW I have yet had a young engineer that actually did try the >exercises not come back and say something like "Wow, I never knew ...." I >don't gloat, but I smile inside, know that I just made them a more >effective for our team. If they ask, I point out I had been using UNIX and >hacking on the kernel most every day for at least 10 years when it first >appeared in the early 80's (84/85 I think), and I learned a few tricks when >I read it. I appreciate the kind advice Clem! I'm dipping my toes into heirloom doctools these days, and am delightened by the simplicity, modularity, and speed compared to latex. However, much to learn still so thanks for the nudge. Anders From brantley at coraid.com Tue Mar 30 01:43:32 2021 From: brantley at coraid.com (Brantley Coile) Date: Mon, 29 Mar 2021 15:43:32 +0000 Subject: [TUHS] Remember the ed thread? In-Reply-To: References: <20210329143449.GA28080@mcvoy.com> Message-ID: Typo. Worry. Not a bad thing. > On Mar 29, 2021, at 11:36 AM, Mark van Atten wrote: > > On Mon, 29 Mar 2021 at 17:27, Brantley Coile wrote: >> Some things I would have used awk/sed >> for that I now use Sam's command window for, but that's a bad thing. > > Why is that a bad thing? (Informative question.) > > Mark. From akosela at andykosela.com Tue Mar 30 01:45:50 2021 From: akosela at andykosela.com (Andy Kosela) Date: Mon, 29 Mar 2021 17:45:50 +0200 Subject: [TUHS] Remember the ed thread? In-Reply-To: References: <20210329143449.GA28080@mcvoy.com> Message-ID: On Monday, March 29, 2021, Brantley Coile wrote: > > From 1984, when I stopped using vi (vee eye), until the early 1990's, when > I could use Sam, I used a slightly hacked version of ed. I added > what the Labs called the "b" command. I had use some other character. Dennis > Ritchie sent me a 8th Edition Unix manual, and I saw they had added almost > the same thing and called the command by the second letter. Vi called > it the last letter, "z." > > I've never found ed slows me down. Some things I would have used awk/sed > for that I now use Sam's command window for, but that's a bad thing. I still > use ed a lot along side Sam. > If ed(1) had cursor positioning and full screen capabilities along with line oriented editing (similar to Atari 8-bit default editor) it would be perfect. I still love it though and use it pretty often. --Andy From lm at mcvoy.com Tue Mar 30 01:49:45 2021 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 29 Mar 2021 08:49:45 -0700 Subject: [TUHS] Remember the ed thread? In-Reply-To: References: <20210329143449.GA28080@mcvoy.com> Message-ID: <20210329154945.GE4209@mcvoy.com> That's an excellent book. After that, try this one: https://www.amazon.com/Advanced-UNIX-Programming-Marc-Rochkind/dp/0131411543 On Mon, Mar 29, 2021 at 11:37:57AM -0400, Clem Cole wrote: > Anders -- good for you. > > That said, as one of those 'grey beards,' can I recommend that you stop, > and go to a technical library or bookstore and find yourself a copy of Rob > and Brian's wonderful book: "*The Unix Programming Environment*" (*a.k.a* > "UPE" or ISBN 0-13-937699-2) *then do the exercises*. That book is still > relevant today - a little secret, I give a copy of it and "*Advanced > Programming in the Unix Environment*" (*a.k.a.* "APUE") to all my new > engineers - even though they are all using 'Linux' for their work. To > those that object at first, I remind them, Linux is just the current and > most popular implementation of the ideas from Ken, Dennis, Doug, and > friends and I'm sure they will learn something from the time invested[1]. > > FWIW: Besides learning ed (which will help you unlock some of the mysteries > of other UNIX tools like grep and sed), take a shot at looking at the > introduction to nroff/troff (as has been discussed here - not to restart a > war). Learning to use a 'document compiler' like the troff family is never > a bad investment. > > Have fun, > Clem > > > 1.] BTW I have yet had a young engineer that actually did try the > exercises not come back and say something like "Wow, I never knew ...." I > don't gloat, but I smile inside, know that I just made them a more > effective for our team. If they ask, I point out I had been using UNIX and > hacking on the kernel most every day for at least 10 years when it first > appeared in the early 80's (84/85 I think), and I learned a few tricks when > I read it. > ??? > ??? > > On Mon, Mar 29, 2021 at 11:16 AM Anders Damsgaard > wrote: > > > * Larry McVoy [2021-03-29 07:34:49 -0700]: > > > > >I had *.clients.your-server.de crawling mcvoy.com in violation of my > > >robots.txt. For whatever reason, the tty settings (or something) > > >made vi not work, I dunno what the deal is, stty -tabs didn't help. > > > > > >So I had to resort to ed to write and debug the little program below. > > >It was surprisingly pleasant, it's probably the first time I've used ed > > >for anything real in at least a decade. My fingers still know it. > > > > > >+1 for ed. It's how many decades old and still useful? > > > > I recently learned ed(1) for the first time (I have a unix beard, but it's > > not grey yet). I found ed to be very efficient and useful for small fixes, > > even on slow connections. This beginner's tutorial was very helpful > > for me: gopher://katolaz.net/0/ed_tutorial.txt > > > > (https mirror for non-gopher clients: > > https://adamsgaard.dk/npub/ed_tutorial.txt ) > > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From clemc at ccc.com Tue Mar 30 01:51:08 2021 From: clemc at ccc.com (Clem Cole) Date: Mon, 29 Mar 2021 11:51:08 -0400 Subject: [TUHS] Remember the ed thread? In-Reply-To: References: <20210329143449.GA28080@mcvoy.com> Message-ID: Consider: Webb Miller's 's' - It been on my 'todo' list to get it running on 6th edition, but I admit that is low on my priority list. But I have run it on a couple of other 8-bit systems -- from the readme --- # s A tiny vi like screen editor Original sources were published in this book: Author: Webb Miller Title: A software tools sampler Publisher: Prentice-Hall, Inc. Upper Saddle River, NJ, USA ©1987 ISBN: 0-13-822305-X Martin, a guy from one of my hangouts named , located the sources from this book. The repository starts from these original sources. Martin also provided the initial CP/M patches for compiling with HI-TECH C. Then the sources were overworked, to get it compiled without warnings on old systems with K&R C compiler, as well as modern systems with ANSI C compiler. This version of s is known to compile on: HI-TECH C for the Z80 under CP/M clang under OSX clang and gcc under Linux Mark Williams K&R C compiler under COHERENT ᐧ On Mon, Mar 29, 2021 at 11:46 AM Andy Kosela wrote: > On Monday, March 29, 2021, Brantley Coile wrote: > > > > From 1984, when I stopped using vi (vee eye), until the early 1990's, > when > > I could use Sam, I used a slightly hacked version of ed. I added > > what the Labs called the "b" command. I had use some other character. > Dennis > > Ritchie sent me a 8th Edition Unix manual, and I saw they had added > almost > > the same thing and called the command by the second letter. Vi called > > it the last letter, "z." > > > > I've never found ed slows me down. Some things I would have used awk/sed > > for that I now use Sam's command window for, but that's a bad thing. I > still > > use ed a lot along side Sam. > > > > If ed(1) had cursor positioning and full screen capabilities along > with line oriented editing (similar to Atari 8-bit default editor) it > would be perfect. I still love it though and use it pretty often. > > --Andy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vanattenmark at gmail.com Tue Mar 30 01:52:39 2021 From: vanattenmark at gmail.com (Mark van Atten) Date: Mon, 29 Mar 2021 17:52:39 +0200 Subject: [TUHS] Remember the ed thread? In-Reply-To: References: <20210329143449.GA28080@mcvoy.com> Message-ID: On Mon, 29 Mar 2021, 5:43 pm Brantley Coile, wrote: > Typo. > > Worry. Not a bad thing. > That's an informative answer ;) Thanks! Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman at oclsc.org Tue Mar 30 01:58:12 2021 From: norman at oclsc.org (Norman Wilson) Date: Mon, 29 Mar 2021 11:58:12 -0400 (EDT) Subject: [TUHS] Remember the ed thread? Message-ID: <20210329155812.C66DF640CB6@lignose.oclsc.org> ed is the standard editor, they say. The b command (stands for browse) came from late-1970s U of T; rob probably brought it to 1127. There were a handful of other syntactic conveniences, like being allowed to leave off the final delimeter of an s command, and declaring that a missing address means 1 before the comma or semicolon and $ after, so 3,s/fish/&head works over all lines from 3 to the last, and , standing alone addresses the whole buffer. Also the idea that s followed by a digit N means start with the Nth instance of the pattern: s3/fish/&head/ affects only the third fish, and s3/fish/&head/g every fish after the second. I have all those tweaks, plus a few others, embedded in my fingers from the qed produced by the same Toronto hacks. I contracted it from the copy rob left behind at Caltech, which means it has been my editor of choice for 40 years now (with sam as an alternate favourite since its inception 35 years or so ago). That qed has a lot of cryptic programming stuff that I have mostly forgotten because it was never that useful, but what really hooked me was a. Multiple buffers, with the ability to move and copy text between them reasonably smoothly (both with the m and t commands and with an interpolate-into-input magic character); b. The > < | commands, which respectively send the addressed lines to a shell command (default ,), replace the addressed lines or append after the single addressed line the standard output of the shell command (default .), and replaced addressed lines with what you get by sending them (default ,) to the shell command, replacing them with its standard output. The last operators make qed into a kind of workbench, both for massaging data and for constructing a list of commands to send to the shell. I gather current Linux/BSD eds have > and <, spelled r ! and w !, but without | it just ain't the same, rather like the way | revolutionized the shell. I believe the credit for U of T ed and qed go mainly to Rob Pike, Tom Duff, Hugh Redelmeier, and the (alas now late) David Tillbrook. David remained an avid user of qed, continuing to add stuff to it. Norman Wilson Toronto ON PS: this message, as most of my e-mail, composed by typing it into qed, editing as needed, then running >mail tuhs at tuhs.org From akosela at andykosela.com Tue Mar 30 02:01:01 2021 From: akosela at andykosela.com (Andy Kosela) Date: Mon, 29 Mar 2021 18:01:01 +0200 Subject: [TUHS] Remember the ed thread? In-Reply-To: References: <20210329143449.GA28080@mcvoy.com> Message-ID: On 3/29/21, Clem Cole wrote: > Anders -- good for you. > > That said, as one of those 'grey beards,' can I recommend that you stop, > and go to a technical library or bookstore and find yourself a copy of Rob > and Brian's wonderful book: "*The Unix Programming Environment*" (*a.k.a* > "UPE" or ISBN 0-13-937699-2) *then do the exercises*. That book is still > relevant today - a little secret, I give a copy of it and "*Advanced > Programming in the Unix Environment*" (*a.k.a.* "APUE") to all my new > engineers - even though they are all using 'Linux' for their work. To > those that object at first, I remind them, Linux is just the current and > most popular implementation of the ideas from Ken, Dennis, Doug, and > friends and I'm sure they will learn something from the time invested[1]. +1. It is still my all time favorite Unix book, but the best ed(1) tutorial I read has to be UNIX Programmer's Manual for Version 7. Still highly recommended. --Andy From usotsuki at buric.co Tue Mar 30 02:20:44 2021 From: usotsuki at buric.co (Steve Nickolas) Date: Mon, 29 Mar 2021 12:20:44 -0400 (EDT) Subject: [TUHS] Remember the ed thread? In-Reply-To: <20210329143449.GA28080@mcvoy.com> References: <20210329143449.GA28080@mcvoy.com> Message-ID: On Mon, 29 Mar 2021, Larry McVoy wrote: > I had *.clients.your-server.de crawling mcvoy.com in violation of my > robots.txt. For whatever reason, the tty settings (or something) > made vi not work, I dunno what the deal is, stty -tabs didn't help. Hetzner. They're one of those cheap hosting providers (one of my servers is hosted with them), and those types of providers are magnets for scum because they're so cheap (OVH, which is the provider that hosted my mail server for years, is particularly infamous). -uso. From arnold at skeeve.com Tue Mar 30 03:22:26 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 29 Mar 2021 11:22:26 -0600 Subject: [TUHS] Remember the ed thread? In-Reply-To: References: <20210329143449.GA28080@mcvoy.com> Message-ID: <202103291722.12THMQhq028681@freefriends.org> Andy Kosela wrote: > If ed(1) had cursor positioning and full screen capabilities along > with line oriented editing (similar to Atari 8-bit default editor) it > would be perfect. I still love it though and use it pretty often. Try out the 'se' editor, see www.se-editor.org. Arnold From tih at hamartun.priv.no Tue Mar 30 04:12:37 2021 From: tih at hamartun.priv.no (Tom Ivar Helbekkmo) Date: Mon, 29 Mar 2021 20:12:37 +0200 Subject: [TUHS] Remember the ed thread? In-Reply-To: (Clem Cole's message of "Mon, 29 Mar 2021 11:37:57 -0400") References: <20210329143449.GA28080@mcvoy.com> Message-ID: Clem Cole writes: > That said, as one of those 'grey beards,' can I recommend that you > stop, and go to a technical library or bookstore and find yourself a > copy of Rob and Brian's wonderful book: "*The Unix Programming > Environment*" (*a.k.a* "UPE" or ISBN 0-13-937699-2) *then do the > exercises*. That is a great book - I'd been a Unix sysadmin for more than a decade when I got it, and I learned a lot of new stuff from it. Twenty years later, that book is still among my favorites, along with their newer joint effort, "The Practice of Programming". Then there's the AWK book, of course, and just about anything else with Brian Kernighan's name on it. It's like with Date on database systems, or Stevens on networking; you just know it's going to be good. -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 robpike at gmail.com Tue Mar 30 05:50:10 2021 From: robpike at gmail.com (Rob Pike) Date: Tue, 30 Mar 2021 06:50:10 +1100 Subject: [TUHS] Remember the ed thread? In-Reply-To: <20210329143449.GA28080@mcvoy.com> References: <20210329143449.GA28080@mcvoy.com> Message-ID: Ed is the standard editor. -rob On Tue, Mar 30, 2021 at 1:36 AM Larry McVoy wrote: > I had *.clients.your-server.de crawling mcvoy.com in violation of my > robots.txt. For whatever reason, the tty settings (or something) > made vi not work, I dunno what the deal is, stty -tabs didn't help. > > So I had to resort to ed to write and debug the little program below. > It was surprisingly pleasant, it's probably the first time I've used ed > for anything real in at least a decade. My fingers still know it. > > +1 for ed. It's how many decades old and still useful? > > > #!/usr/libexec/bitkeeper/bk tclsh > > int > main(void) > { > FILE log = popen("/var/log/apache2/dns.l", "r"); > string buf, ip; > string dropped{string}; > > fconfigure(log, buffering: "line"); > while (buf = ) { > unless (buf =~ /([^ ]+\.your-server\.de\.) /) continue; > ip = $1; > if (defined(dropped{ip})) continue; > dropped{ip} = "yes"; > warn("DROP ${ip}\n"); > system("/sbin/iptables -I INPUT -s ${ip} -j DROP"); > } > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.douglas.mcilroy at dartmouth.edu Tue Mar 30 06:28:34 2021 From: m.douglas.mcilroy at dartmouth.edu (M Douglas McIlroy) Date: Mon, 29 Mar 2021 16:28:34 -0400 Subject: [TUHS] Soft hyphens Message-ID: > When hyphenation is disabled, soft (discretionary) hyphens are > interpreted. In pre-Unix roff hyphenation mode 0 turned off all breaking of words. The original troff, however, behaved as described above, and alsowant broke genuinely hyphenated words in mode 0. If you t really wants to break words one day, you may use From m.douglas.mcilroy at dartmouth.edu Tue Mar 30 06:40:48 2021 From: m.douglas.mcilroy at dartmouth.edu (M Douglas McIlroy) Date: Mon, 29 Mar 2021 16:40:48 -0400 Subject: [TUHS] Soft hyphens In-Reply-To: References: Message-ID: Sorry, I hit send by mistake. I intended to conclude with: If you really want to hyphenate one day and not the next, you can pick a character c and use ".hc c" to turn it on and .char c \& to turn it off. Doug On Mon, Mar 29, 2021 at 4:28 PM M Douglas McIlroy wrote: > > > When hyphenation is disabled, soft (discretionary) hyphens are > > interpreted. > > In pre-Unix roff hyphenation mode 0 turned off all breaking of words. > The original troff, however, behaved as described above, and alsowant > broke genuinely hyphenated words in mode 0. If you t really wants > to break words one day, you may use From musher at ucsc.edu Tue Mar 30 06:50:55 2021 From: musher at ucsc.edu (Michael Usher) Date: Mon, 29 Mar 2021 13:50:55 -0700 Subject: [TUHS] Remember the ed thread? In-Reply-To: References: <20210329143449.GA28080@mcvoy.com> Message-ID: <4B1F03CA-6387-4FE1-8116-0CB7B5175DE7@ucsc.edu> I think you can only truly appreciate ed when you were forced to use a DECwriter as your terminal because all the VT100s were in use. (Undergrad student lab) — Michael Usher Network Operations Manager University of California, Santa Cruz musher at ucsc.edu 831-459-3697 > On Mar 29, 2021, at 12:50 PM, Rob Pike wrote: > > Ed is the standard editor. > > -rob > > > On Tue, Mar 30, 2021 at 1:36 AM Larry McVoy > wrote: > I had *.clients.your-server.de crawling mcvoy.com in violation of my > robots.txt. For whatever reason, the tty settings (or something) > made vi not work, I dunno what the deal is, stty -tabs didn't help. > > So I had to resort to ed to write and debug the little program below. > It was surprisingly pleasant, it's probably the first time I've used ed > for anything real in at least a decade. My fingers still know it. > > +1 for ed. It's how many decades old and still useful? > > > #!/usr/libexec/bitkeeper/bk tclsh > > int > main(void) > { > FILE log = popen("/var/log/apache2/dns.l", "r"); > string buf, ip; > string dropped{string}; > > fconfigure(log, buffering: "line"); > while (buf = ) { > unless (buf =~ /([^ ]+\.your-server\.de\.) /) continue; > ip = $1; > if (defined(dropped{ip})) continue; > dropped{ip} = "yes"; > warn("DROP ${ip}\n"); > system("/sbin/iptables -I INPUT -s ${ip} -j DROP"); > } > } -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Tue Mar 30 06:55:59 2021 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 29 Mar 2021 13:55:59 -0700 Subject: [TUHS] Remember the ed thread? In-Reply-To: <4B1F03CA-6387-4FE1-8116-0CB7B5175DE7@ucsc.edu> References: <20210329143449.GA28080@mcvoy.com> <4B1F03CA-6387-4FE1-8116-0CB7B5175DE7@ucsc.edu> Message-ID: <20210329205559.GI4209@mcvoy.com> My high school had some computer, don't remember what, may have been a PDP 11. The *only* terminal was a line printer, probably a DECwriter, don't remember. I do remember it being about 130 columns. I don't remember if it was the real ed or a clone, but the editor was very similar to ed(1). And yes, it's the only way to go with a printer console. On Mon, Mar 29, 2021 at 01:50:55PM -0700, Michael Usher wrote: > I think you can only truly appreciate ed when you were forced to use a DECwriter as your terminal because all the VT100s were in use. (Undergrad student lab) > > > ??? > Michael Usher > Network Operations Manager > University of California, Santa Cruz > musher at ucsc.edu 831-459-3697 > > > On Mar 29, 2021, at 12:50 PM, Rob Pike wrote: > > > > Ed is the standard editor. > > > > -rob > > > > > > On Tue, Mar 30, 2021 at 1:36 AM Larry McVoy > wrote: > > I had *.clients.your-server.de crawling mcvoy.com in violation of my > > robots.txt. For whatever reason, the tty settings (or something) > > made vi not work, I dunno what the deal is, stty -tabs didn't help. > > > > So I had to resort to ed to write and debug the little program below. > > It was surprisingly pleasant, it's probably the first time I've used ed > > for anything real in at least a decade. My fingers still know it. > > > > +1 for ed. It's how many decades old and still useful? > > > > > > #!/usr/libexec/bitkeeper/bk tclsh > > > > int > > main(void) > > { > > FILE log = popen("/var/log/apache2/dns.l", "r"); > > string buf, ip; > > string dropped{string}; > > > > fconfigure(log, buffering: "line"); > > while (buf = ) { > > unless (buf =~ /([^ ]+\.your-server\.de\.) /) continue; > > ip = $1; > > if (defined(dropped{ip})) continue; > > dropped{ip} = "yes"; > > warn("DROP ${ip}\n"); > > system("/sbin/iptables -I INPUT -s ${ip} -j DROP"); > > } > > } > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From lm at mcvoy.com Tue Mar 30 07:14:18 2021 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 29 Mar 2021 14:14:18 -0700 Subject: [TUHS] Remember the ed thread? In-Reply-To: <20718.1617052215@cesium.clock.org> References: <4B1F03CA-6387-4FE1-8116-0CB7B5175DE7@ucsc.edu> <20718.1617052215@cesium.clock.org> Message-ID: <20210329211418.GK4209@mcvoy.com> Whatever we had, it was slow. Printed one char at a time. So you got good and memorizing the code and only asking to see it rarely. Be funny trying to explain this to my kids. I think they'd get it at some level but really have no idea how much we worked to not let the printer do anything. On Mon, Mar 29, 2021 at 02:10:15PM -0700, Erik E. Fair wrote: > Technically, the DEC DECwriter series were dot-matrix printers, not line printers. They differed from their Teletype predecessors only in print-head technology, but both printed a single character at a time. Daisywheel printers were similar. > > Line printers are distinguished not by the width of the paper but by the printer having enough print heads to print an entire line of output at a time. That speed advantage made them the preferred output device for many-page program listings, as opposed to a teleprinter terminals which were more suitable for interactive computing. > > There were dot-matrix line printers of the late 1970s made by Printronix, which is apparently still around. > > Erik Fair -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From fair-tuhs at netbsd.org Tue Mar 30 07:10:15 2021 From: fair-tuhs at netbsd.org (Erik E. Fair) Date: Mon, 29 Mar 2021 14:10:15 -0700 Subject: [TUHS] Remember the ed thread? In-Reply-To: <20210329205559.GI4209@mcvoy.com> References: <4B1F03CA-6387-4FE1-8116-0CB7B5175DE7@ucsc.edu> Message-ID: <20718.1617052215@cesium.clock.org> Technically, the DEC DECwriter series were dot-matrix printers, not line printers. They differed from their Teletype predecessors only in print-head technology, but both printed a single character at a time. Daisywheel printers were similar. Line printers are distinguished not by the width of the paper but by the printer having enough print heads to print an entire line of output at a time. That speed advantage made them the preferred output device for many-page program listings, as opposed to a teleprinter terminals which were more suitable for interactive computing. There were dot-matrix line printers of the late 1970s made by Printronix, which is apparently still around. Erik Fair From clemc at ccc.com Tue Mar 30 07:53:03 2021 From: clemc at ccc.com (Clem Cole) Date: Mon, 29 Mar 2021 17:53:03 -0400 Subject: [TUHS] Remember the ed thread? In-Reply-To: <20718.1617052215@cesium.clock.org> References: <4B1F03CA-6387-4FE1-8116-0CB7B5175DE7@ucsc.edu> <20210329205559.GI4209@mcvoy.com> <20718.1617052215@cesium.clock.org> Message-ID: On Mon, Mar 29, 2021 at 5:16 PM Erik E. Fair wrote: > Technically, the DEC DECwriter series were dot-matrix printers, not line > printers. They differed from their Teletype predecessors only in print-head > technology, but both printed a single character at a time. Daisywheel > printers were similar. > Right.... > Line printers are distinguished not by the width of the paper but by the > printer having enough print heads to print an entire line of output at a > time. That speed advantage made them the preferred output device for > many-page program listings, as opposed to a teleprinter terminals which > were more suitable for interactive computing. > There were originally two styles, the drum printers which DEC sold(e.g. LP20) and the chain printers that IBM offered (e.g. 1401). The drum had all the characters in each of the 132 columns (the upper case only printers were faster because the alphabet was on the drum in two places). The IBM ones has slugs on a rapidly spinning chain that was horizontal (and parallel) to the line being printed. The chain was easily replaceable by the operator - which was one of the duties we would have. When a user queued a printer a set of symbols (*i.e.* the chain of the needed output characters) was specified and the system queued it until the printer had been properly provisioned. For instance, CMU printed checks with a special chain and film ink, so once a night the operator would configure the printer, and tell the queue to print them). Some chains were faster than others, the standard one had N copies of each character. In common to both schemes is that each both styles had 132 hammers and when the proper character was in the position needed, the hammer fired to make an impression the ribbon on the paper, which was caused the noise people associated with computer printers. The high-end IBM 1401 had a hydraulic cover that came down over it and was controlled by the channel processor (it would auto-open when it needed to be serviced - like a new box of paper). But even with the cover down it still loud. The original DEC ones were OEM'ed from Centronix and were noted for always being a little random on the hammer timing and thus the print on the paper often looked like the characters bounced on the line. I remember the ones we had on the PDP-10s were awful and the issue with BLISS is that the dot operator is extremely important to your code and the dots were sometimes notoriously missing. Cabling could be difficult too. They were parallel devices and were supposed to have shorter cables (*i.e.* in the machine room). IBM used its own interface, but by the mid-1970s the Centronix printers were pretty standard on the mini-computers and their parallel interface became the standard (in fact the IBM PC supplied a Centronix parallel interface). > > There were dot-matrix line printers of the late 1970s made by Printronix, > which is apparently still around. > IIRC, in 1979 the Printronix cost about $5K, plus another $300-$500 for an Arduino sized parallel to serial converter that they sold so the printer could be remote on a 9600 baud serial line. Until the cheaper lasers came about, these were often the standard printers that UNIX sites had [I was told once that the original Lion's book was printed on one]. They were about ½ the cost of the DEC printers and since it will all pins, did not have the bounce issue the drums had. When the UNIX boxes started to appear at CMU we used them, and IIRC @ UC Berkeley, we had a number of them around Cory Hall also. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpl.jpl at gmail.com Tue Mar 30 08:29:37 2021 From: jpl.jpl at gmail.com (John P. Linderman) Date: Mon, 29 Mar 2021 18:29:37 -0400 Subject: [TUHS] Remember the ed thread? In-Reply-To: References: <4B1F03CA-6387-4FE1-8116-0CB7B5175DE7@ucsc.edu> <20210329205559.GI4209@mcvoy.com> <20718.1617052215@cesium.clock.org> Message-ID: > > > On Mon, Mar 29, 2021 at 5:16 PM Erik E. Fair wrote: > > Line printers are distinguished not by the width of the paper but by the >> printer having enough print heads to print an entire line of output at a >> time. That speed advantage made them the preferred output device for >> many-page program listings, as opposed to a teleprinter terminals which >> were more suitable for interactive computing. >> > There were originally two styles, the drum printers which DEC sold(e.g. > LP20) and the chain printers that IBM offered (e.g. 1401). The drum had > all the characters in each of the 132 columns (the upper case only printers > were faster because the alphabet was on the drum in two places). The IBM ones > has slugs on a rapidly spinning chain that was horizontal (and parallel) > to the line being printed. The chain was easily replaceable by the > operator - which was one of the duties we would have. When a user queued a > printer a set of symbols (*i.e.* the chain of the needed output > characters) was specified and the system queued it until the printer had > been properly provisioned. For instance, CMU printed checks with a > special chain and film ink, so once a night the operator would configure > the printer, and tell the queue to print them). Some chains were faster > than others, the standard one had N copies of each character. > > In common to both schemes is that each both styles had 132 hammers and > when the proper character was in the position needed, the hammer fired to > make an impression the ribbon on the paper, which was caused the noise > people associated with computer printers. The high-end IBM 1401 had a > hydraulic cover that came down over it and was controlled by the channel > processor (it would auto-open when it needed to be serviced - like a new > box of paper). > > This led to the "first commandment of fancy printers": Thou shalt not leave thine coffee on top of the printer. -- jpl -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.douglas.mcilroy at dartmouth.edu Tue Mar 30 09:21:34 2021 From: m.douglas.mcilroy at dartmouth.edu (M Douglas McIlroy) Date: Mon, 29 Mar 2021 19:21:34 -0400 Subject: [TUHS] Remember the ed thread? Message-ID: > the hammer fired to make an impression the ribbon on the paper, which was > caused the noise people associated with computer printers. GE outdid the printer with a fantastically fast pneumatic card reader. The make and break of the suction on each card repeated at aural frequency and so loud that I hied off to the instrument stockroom to borrow a noise meter. It was 90db at the operator's position. From cowan at ccil.org Tue Mar 30 10:11:21 2021 From: cowan at ccil.org (John Cowan) Date: Mon, 29 Mar 2021 20:11:21 -0400 Subject: [TUHS] Remember the ed thread? In-Reply-To: <20210329155812.C66DF640CB6@lignose.oclsc.org> References: <20210329155812.C66DF640CB6@lignose.oclsc.org> Message-ID: On Mon, Mar 29, 2021 at 11:59 AM Norman Wilson wrote: > The b command (stands for browse) came from late-1970s > U of T; rob probably brought it to 1127. It's little things like this that make me use ex rather than ed, though it is spelled z there. Linux ed has z as an extension. > There were a > handful of other syntactic conveniences, like being > allowed to leave off the final delimeter of an s command, > and declaring that a missing address means 1 before the > comma or semicolon and $ after, so > 3,s/fish/&head > works over all lines from 3 to the last, and , standing > alone addresses the whole buffer. > Those things are in Posix now. Linux ed is a superset of Posix; *BSD ed is rather lacking, being based on an old SVID. > Also the idea that s followed by a digit N means start > with the Nth instance of the pattern: > s3/fish/&head/ > affects only the third fish, and > s3/fish/&head/g > every fish after the second. > That's neither Posix ed nor ex, and very annoying it is to lack it. > b. The > < | commands, [...] make qed into a kind of workbench, > both for massaging data and for constructing a list > of commands to send to the shell. > > I gather current Linux/BSD eds have > and <, spelled > r ! and w !, but without | it just ain't the same, > rather like the way | revolutionized the shell. > Ex extends the ! command to accept numeric arguments and has the same semantics. Unfortunately, although "r !" and "w !" are in both Posix ed and ex, in ex "w !foo" means "output to the foo command" whereas "w! foo" means "write to foo, ignoring the internal 'don't overwrite' bit that you can set." I wrote two specs that may be of interest to someone: was my attempt to describe "ex extended" that could still be a lightweight editor by not needing the vi bag on the side. is a list of things that make me not want to use sam -d editing until they are provided in some form. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org On the Semantic Web, it's too hard to prove you're not a dog. --Bill de hOra -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdm at cfcl.com Tue Mar 30 13:39:04 2021 From: rdm at cfcl.com (Rich Morin) Date: Mon, 29 Mar 2021 20:39:04 -0700 Subject: [TUHS] Remember the ed thread? In-Reply-To: References: Message-ID: <5D422E7C-F9E8-407F-8F86-E38893AAE78E@cfcl.com> I spent a few years working with a CDC 3800, which also had a pneumatic card reader, along with several other noisy peripherals. Although I have no way to prove this, I suspect that my current hearing issues stem from the noise in that machine room. -r > On Mar 29, 2021, at 16:21, M Douglas McIlroy wrote: > > GE outdid the printer with a fantastically fast pneumatic card reader. The make and break of the suction on each card repeated at aural frequency and so loud that I hied off to the instrument stockroom to borrow a noise meter. It was 90db at the operator's position. From robpike at gmail.com Tue Mar 30 14:30:56 2021 From: robpike at gmail.com (Rob Pike) Date: Tue, 30 Mar 2021 15:30:56 +1100 Subject: [TUHS] Remember the ed thread? In-Reply-To: References: <4B1F03CA-6387-4FE1-8116-0CB7B5175DE7@ucsc.edu> <20210329205559.GI4209@mcvoy.com> <20718.1617052215@cesium.clock.org> Message-ID: Night operators were known to nap on top of the 1401s. When there was a need for more paper, they would be gently awakened. -rob On Tue, Mar 30, 2021 at 9:30 AM John P. Linderman wrote: > >> On Mon, Mar 29, 2021 at 5:16 PM Erik E. Fair >> wrote: >> > > >> Line printers are distinguished not by the width of the paper but by the >>> printer having enough print heads to print an entire line of output at a >>> time. That speed advantage made them the preferred output device for >>> many-page program listings, as opposed to a teleprinter terminals which >>> were more suitable for interactive computing. >>> >> There were originally two styles, the drum printers which DEC sold(e.g. >> LP20) and the chain printers that IBM offered (e.g. 1401). The drum had >> all the characters in each of the 132 columns (the upper case only printers >> were faster because the alphabet was on the drum in two places). The >> IBM ones has slugs on a rapidly spinning chain that was horizontal (and parallel) >> to the line being printed. The chain was easily replaceable by the >> operator - which was one of the duties we would have. When a user queued a >> printer a set of symbols (*i.e.* the chain of the needed output >> characters) was specified and the system queued it until the printer had >> been properly provisioned. For instance, CMU printed checks with a >> special chain and film ink, so once a night the operator would configure >> the printer, and tell the queue to print them). Some chains were faster >> than others, the standard one had N copies of each character. >> >> In common to both schemes is that each both styles had 132 hammers and >> when the proper character was in the position needed, the hammer fired to >> make an impression the ribbon on the paper, which was caused the noise >> people associated with computer printers. The high-end IBM 1401 had a >> hydraulic cover that came down over it and was controlled by the channel >> processor (it would auto-open when it needed to be serviced - like a new >> box of paper). >> >> This led to the "first commandment of fancy printers": Thou shalt not > leave thine coffee on top of the printer. -- jpl > -------------- next part -------------- An HTML attachment was scrubbed... URL: From skogtun at gmail.com Tue Mar 30 17:37:30 2021 From: skogtun at gmail.com (Harald Arnesen) Date: Tue, 30 Mar 2021 09:37:30 +0200 Subject: [TUHS] Remember the ed thread? In-Reply-To: References: <4B1F03CA-6387-4FE1-8116-0CB7B5175DE7@ucsc.edu> <20210329205559.GI4209@mcvoy.com> <20718.1617052215@cesium.clock.org> Message-ID: <17ec6521-6ac3-402d-6a0d-c11b13082a4f@gmail.com> John P. Linderman [30.03.2021 00:29]: > In common to both schemes is that each both styles had 132 hammers > and when the proper character was in the position needed, the hammer > fired to make an impression the ribbon on the paper, which was > caused the noise people associated with computer printers.  The > high-end IBM 1401 had a hydraulic cover that came down over it and > was controlled by the channel processor (it would auto-open when it > needed to be serviced - like a new box of paper). > > This led to the "first commandment of fancy printers": Thou shalt not > leave thine coffee on top of the printer. -- jpl A former co-worker told me he had once placed a deck of punched cards on top of such a printer...he didn't do it a second time. -- Hilsen Harald From arnold at skeeve.com Tue Mar 30 18:53:40 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 30 Mar 2021 02:53:40 -0600 Subject: [TUHS] Remember the ed thread? In-Reply-To: References: <20210329143449.GA28080@mcvoy.com> <202103291722.12THMQhq028681@freefriends.org> Message-ID: <202103300853.12U8reBo018841@freefriends.org> Andy Kosela wrote: > On 3/29/21, arnold at skeeve.com wrote: > > Andy Kosela wrote: > > > >> If ed(1) had cursor positioning and full screen capabilities along > >> with line oriented editing (similar to Atari 8-bit default editor) it > >> would be perfect. I still love it though and use it pretty often. > > > > Try out the 'se' editor, see www.se-editor.org. > > Thanks. It is a nice editor, but it actually resembles ex(1) when > using visual mode. Maybe I am missing something but it appears you > cannot actually use cursor keys to visually edit lines in the upper > area of the screen in se -- you can only edit cmd line. > > As far as I know there is no editor in the Unix land which gives you > the ability to work in the ed(1) line oriented mode BUT also allowing > to freely move cursor keys in all directions. I gave example of the > Atari editor[1] which does exactly that. I believe to accomplish it > on Unix one would need to hack ed(1) and add ncurses(3) cursor > positioning. > > --Andy > > [1] https://youtu.be/c9o92l5gupI From kennethgoodwin56 at gmail.com Wed Mar 31 01:00:53 2021 From: kennethgoodwin56 at gmail.com (Kenneth Goodwin) Date: Tue, 30 Mar 2021 11:00:53 -0400 Subject: [TUHS] Remember the ed thread? In-Reply-To: <20718.1617052215@cesium.clock.org> References: <4B1F03CA-6387-4FE1-8116-0CB7B5175DE7@ucsc.edu> <20210329205559.GI4209@mcvoy.com> <20718.1617052215@cesium.clock.org> Message-ID: As I recall, the Dataproducts band printers BP1000, BP2000 only had a single hammer per column. But the band containing the full character set moved so quickly into position for each column that the print speed was incredible. We had both models at one point and the 2000 was an absolute screamer. Paper just flew over the paper guides to the collection basket in the rear. It was impressive and incredible to watch in action. The bands were easily replaceable via a release lever. So you could change fonts, replace damaged bands, etc. Sharp as heck as I recall on the edges. You also had to make sure it lined up just right before engaging the tension lever. With cover down, they were remarkably quiet in comparison to other "high speed" printers I had been around. Real good at multipart forms at making clean clear impressions on the backmost layer. On Mon, Mar 29, 2021, 5:16 PM Erik E. Fair wrote: > Technically, the DEC DECwriter series were dot-matrix printers, not line > printers. They differed from their Teletype predecessors only in print-head > technology, but both printed a single character at a time. Daisywheel > printers were similar. > > Line printers are distinguished not by the width of the paper but by the > printer having enough print heads to print an entire line of output at a > time. That speed advantage made them the preferred output device for > many-page program listings, as opposed to a teleprinter terminals which > were more suitable for interactive computing. > > There were dot-matrix line printers of the late 1970s made by Printronix, > which is apparently still around. > > Erik Fair > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Wed Mar 31 09:38:19 2021 From: cowan at ccil.org (John Cowan) Date: Tue, 30 Mar 2021 19:38:19 -0400 Subject: [TUHS] Remember the ed thread? In-Reply-To: References: Message-ID: I missed the fact that Posix and Linux ed support s/foo/bar/3 (as opposed to s3/foo/bar); ex does not, unfortunately. We need a Great Unification of Line Editors. -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman at oclsc.org Wed Mar 31 10:54:50 2021 From: norman at oclsc.org (Norman Wilson) Date: Tue, 30 Mar 2021 20:54:50 -0400 (EDT) Subject: [TUHS] Remember the ed thread? Message-ID: <20210331005450.86F0A640CB6@lignose.oclsc.org> John Cowan: We need a Great Unification of Line Editors. ==== A standard for the standard editor? I thought the nice thing about standards was that there were so many of them. Norman Wilson Toronto ON From cowan at ccil.org Wed Mar 31 11:29:59 2021 From: cowan at ccil.org (John Cowan) Date: Tue, 30 Mar 2021 21:29:59 -0400 Subject: [TUHS] Remember the ed thread? In-Reply-To: <20210331005450.86F0A640CB6@lignose.oclsc.org> References: <20210331005450.86F0A640CB6@lignose.oclsc.org> Message-ID: On Tue, Mar 30, 2021 at 9:03 PM Norman Wilson wrote: A standard for the standard editor? > No, I mean an implementation that provides the union of features (and preferably though not necessarily of syntaxes) in Posix ed and ex, GNU ed, the ex mode of vim, and BSD ed. I thought the nice thing about standards was that there > were so many of them. > ... and if you don't like any of them, wait till next year, yes. But (to use examples of local significance) who would have foreseen that a character encoding standard put forward in 1992 for an obscure OS in 1992 would so completely take over the world, or for that matter another obscure OS written by the same people in 1969? It's fine to complain that there is no more research in such-and-such an area; however, while many projects are worked on forever and the great majority are abandoned, there is a third kind of project that is simply *finished*. Cal, for example, provides the same output in both Linux and BSD versions as the Seventh Edition when given the original arguments (except for titlecasing the weekday names), though both have additional bells and whistles such as being able to set the date of the Gregorian reform. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org Gules six bars argent on a canton azure 50 mullets argent six five six five six five six five and six --blazoning the U.S. flag -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Wed Mar 31 12:34:10 2021 From: bakul at iitbombay.org (Bakul Shah) Date: Tue, 30 Mar 2021 19:34:10 -0700 Subject: [TUHS] Remember the ed thread? In-Reply-To: References: Message-ID: <105E2543-5C8D-4AE3-ABB1-6C3CE46474C2@iitbombay.org> On Mar 30, 2021, at 4:38 PM, John Cowan wrote: > > I missed the fact that Posix and Linux ed support s/foo/bar/3 (as opposed to s3/foo/bar); ex does not, unfortunately. By analogy with s/RE/replacement/g, it would have made more sense to allow sN/foo/bar/M to mean replace M instances of foo with bar, starting the Nth instance of foo. N & M default to 1. M can also be g. > We need a Great Unification of Line Editors. Add in sam's command language as well! Alternately I'd want k style array language built in, enhanced with regexps.