- COFF - www.tuhs.org

Re: DevOps/SRE [was Re: [TUHS] Re: LOC [was Re: Re: Re.: Princeton's "Unix: An Oral History": who was in the team in "The Attic"?]

by Michael Parson

(Moving to COFF, probably drifted enough from UNIX history) On 2022-11-09 03:01, steve jenkin wrote: >> On 9 Nov 2022, at 19:41, Dan Cross <crossd(a)gmail.com> wrote: >> >> To tie this back to TUHS a little bit...when did being a "sysadmin" >> become a thing unto itself? And is it just me, or has that largely >> been superceded by SRE (which I think of as what one used to, >> perhaps, call a "system programmer") and DevOps, which feels like a >> more traditional Unix-y kind of thing? >> >> - Dan C. > > In The Beginning, We were All Programmers… <snip> I got started in this field in the mid '90s, just as the Internet started moving from mostly EDU & military to the start of dial-up ISPs. My first job was at a small community college/satellite campus of UTexas where me and my co-worker set up the first website for a UTexas satellite campus. I'd played with VMS and SunOS, Linux was brand new and was something we could install on a system we built out of spare parts from the closet. At the time, my job title was "Assistant Systems Manager," where my main job was to add/remove users from the VMS system, reset stuck terminal lines, clean out the print queue, etc. Linux was very much a toy and the Linux system we installed was a playground. It was mostly myself, a few others on the team, and a few CS students that wanted to use something that looked more like Unix than VMS. > SRE roles & as a discipline has developed, alongside DevOps, into > managing & fault finding in large clusters of physical and virtual > machines. My next several years were spent dot-com hopping, as a sysadmin. Mostly in IT shops where we kept the systems that company used online and working. The mail server(s), web-servers, ftp sites, database servers, NFS/CIFS, etc. My job-title for most of my jobs through the mid '00s was (senior) sysadmin. I then spent 8 years as a senior product support "engineer" at IBM (I was CAG/SWAT, for anyone that's familiar with IBM/Rational's job roles), during which time I started seeing the rise of what they eventually started calling DevOps in the early 2010s. As the web grew bigger and bigger, and the concept of Software as a Service and so-called "Cloud" services (AWS, Azure, etc.) became more and more of a thing, the job of keeping the systems that ran those services started splitting off of IT and into their own teams. They took what they learned in IT, tried to codify some "best practices" around monitoring, automation and tooling, started using more shrink-wrapped stuff like ansible/chef/saltstack instead of home-grown stuff we (re)wrote with each job, etc, started forcing ourselves to be part of the dev/test/deploy cycle of the products we were supporting, etc, and someone branded the new work-flow as 'DevOps'. I've glossed over the dev side of that a bit, as they also got more and better build tools, IDEs, and for better or worse, all things git. My current day-job is being a DevOps manager. I started here 8 years ago on the DevOps team and was promoted to manager 4 years ago. > Never done it myself, but it’d seem the potential for screw-ups is > now infinite and unlimited in time :) Yup, the potential for pushing a bad config or big of code to dozens, hundreds, or even thousands of systems with the click of mouse or a single command line has never been higher, but only if the dev/test cycle failed to find the error (or wasn't properly followed) before someone decided to deploy. The guys on my team are supposed to have tested their stuff in their environments before even committing it to the repo, then it spends some time in the QA/test lab before it gets pushed to production. They're not even supposed to commit directly to the main repo, it should be done as a pull-request and someone else at least does an eye-ball review to look for obvious mistakes, which should have been caught by the originator, if they were doing proper testing in their dev environment first. Our basic tooling is github enterprise for source and saltstack is our config management/automation framework. Their work-flow is supposed to basically be: 1 pull latest copy of main repo 2 branch a working set 3 make their changes 4 use something like vagrant to spin up test VMs to test their changes (some people use docker instead of vagrant/virtualbox) 5 loop over 3-4 until it works 6 commit their changes to their branch 7 pull-request to main a. someone else on the team does an eyeball code-review b. other team member performs the merge 8 cherry-pick changes to the next release branch if changes need to go in the next release, PR those picks to the release branches, same process as above for merges. 9 push changes to the test env (test env is running on the next release branch) 10 when QA clears the release, we push to prod on release day. The developers that actually write the software offering have similar workflows for their stuff, except they have a build-system involved to compile & pkg stuff up & put the packages into the package repo which get deployed to test (and eventually prod) with saltstack rules. Our SRE is mostly concerned with making sure the monitoring of everything is up to snuff and the playbooks for acting on alerts is up-to-date and the on-call person can follow it. We have a meeting every other week to go over the alerts & playbooks to make sure that we're keeping things up to date there. He doesn't manage the systems at all, he just makes sure all the moving pieces are properly monitored and we know how to deal with the problems as they come up. -- Michael Parson Pflugerville, TX KF5LGQ

2 years, 5 months

1
0
0 0

How 26 Lines of Code Changed the World?

by Stuff Received

New book from PUP (that I have not read): "You Are Not Expected to Understand This": How 26 Lines of Code Changed the World Torie Bosch, Ed. https://press.princeton.edu/books/paperback/9780691208480/you-are-not-expec… Anyone here know anything about it? N.

2 years, 6 months

2
1
0 0

Will someone update the 386BSD Wikipedia page for me?

by Grant Taylor

Hi, Will someone update the 386BSD Wikipedia page for me? Wikipedia doesn't like my IPv6 address at home nor my VPS and I've given up trying to find a way to make the edit myself without breaking IPv6 on my network. The second paragraph of the history page states the following: "The porting process with code was extensively documented in an 18-part series written by Lynne Jolitz and William Jolitz in Dr. Dobb's Journal beginning in January 1991." There are only 17 parts to the series. My authoritative source is the DDJ DVD available on The Internet Archive. There are 17 articles, month's listed below. In case my ability to find the article sis called into question, the Tracing BSD System Calls article from DDJ March 1998 states the following in the fourth paragraph. "(see the DDJ series "Porting UNIX to the 386," by William and Lynne Jolitz, January-November 1991 and February-July 1992)" 01 - 91-Jan - PORTING UNIX TO THE 386: A PRACTICAL APPROACH - Designing the software specification 02 - 91-Feb - PORTING UNIX TO THE 386: THREE INITIAL PC UTILITIES - Getting to the hardware 03 - 91-Mar - PORTING UNIX TO THE 386: THE STANDALONE SYSTEM - Creating a protected-mode standalone C programming environment 04 - 91-Apr - PORTING UNIX TO THE 386 LANGUAGE TOOLS CROSS SUPPORT - Developing the initial utilities 05 - 91-May - PORTING UNIX TO THE 386 THE INITIAL ROOT FILESYSTEM - Completing the toolset 06 - 91-Jun - PORTING UNIX TO THE 386 RESEARCH & THE COMMERCIAL SECTOR - Where does BSD fit in? 07 - 91-Jul - PORTING UNIX TO THE 386: A STRIPPED-DOWN KERNEL - Onto the initial utilities 08 - 91-Aug - PORTING UNIX TO THE 386: THE BASIC KERNEL - Overview and initialization 09 - 91-Sep - PORTING UNIX TO THE 386: THE BASIC KERNEL - Multiprogramming and Multitasking, Part One 10 - 91-Oct - PORTING UNIX TO THE 386: THE BASIC KERNEL - Multiprogramming and Multitasking, Part II 11 - 91-Nov - PORTING UNIX TO THE 386: THE BASIC KERNEL - Device autoconfiguration 12 - 92-Feb - PORTING UNIX TO THE 386: DEVICE DRIVERS - Drivers for the basic kernel 13 - 92-Mar - PORTING UNIX TO THE 386 DEVICE DRIVERS - Entering, exiting, and masking processor interrupts 14 - 92-Apr - PORTING UNIX TO THE 386 DEVICE DRIVERS - Getting into and out of interrupt routines 15 - 92-May - PORTING UNIX TO THE 386: MISSING PIECES, PART 1 - Completing the 386BSD kernel 16 - 92-Jun - PORTING UNIX TO THE 386 MISSING PIECES II - Completing the 386BSD kernel 17 - 92-Jul - PORTING UNIX TO THE 386 THE FINAL STEP - Running light with 386BSD -- Grant. . . . unix || die

2 years, 7 months

2
2
0 0

Re: [TUHS] Re: The MGR window system and the Macintosh

by Dave Horsfall

[ Moved to COFF ] On Thu, 4 Aug 2022, Dan Cross wrote: [...] > It wasn't particularly notable, or at least didn't leave much of an > impression; it presented a pretty "standard" (and primitive!) > graphical experience. I believe it was monochrome, with amber > on black. It also ran on the Applix 1616, an Aussie designed and built 68000 system; it was pretty much ahead of its time. https://en.wikipedia.org/wiki/Applix_1616 -- Dave

2 years, 8 months

1
1
0 0

Re: [TUHS] Re: The MGR window system and the Macintosh

by Clem Cole

This thread needs to move to COFF to continue - although my own story is 1/2 about BSD and the VAX. On Thu, Aug 4, 2022 at 10:15 PM Al Kossow <aek(a)bitsavers.org> wrote: > On 8/4/22 5:37 PM, Andrew Newman wrote: > > > There's a bunch of AED documentation online, including this... > > > > http://www.bitsavers.org/pdf/aed/brochures/AED_767_Brochure_Jun82.pdf < > http://www.bitsavers.org/pdf/aed/brochures/AED_767_Brochure_Jun82.pdf> > > I worked at AED before going to Apple, to stay sort of window related, the > last project I worked on at AED was > a VME and Qbus board set that was a complete color X terminal. > I had to chuckle when I read that. In the fall of '82 (I think), we got a Smalltalk VM from PARC at UCB. Dave Unger, Ken Keller, and I - plus some other folks in Patterson's systems seminar who's names I have since forgotten, wrote a VM in C for the VAX/BSD. We used an AED512 and Keller's graphics library from his thesis running over a 19.2 serial link as the output. About a month after we had it running, a couple of us got to visit PARC, and Peter Deutch showed us Smalltalk running on a Dorado. He ran his hand with the mouse across the screen opening and closing a bunch of windows randomly. We started laughing and Peter asked us what was so funny. We told him what he did would have taken at least 5 minutes to redisplay on BSD/VAX version. Clem ᐧ

2 years, 8 months

3
2
0 0

Re: [TUHS] SNOBOL and RATSNO

by Dave Horsfall

I did get SPITBOL to work past its expiry date on OS/360 :-) It was dubbed as the "Superzap of the year" by one of my CompSci lecturers (Dr. G.McMahon, UNSW). The first couple of time-bombs were easy to find, but not so the rest (long story). Probably belongs over on COFF now... -- Dave

2 years, 9 months

2
1
0 0

Awk, not Kaw?

by Stuff Received

As I was (re)reading Bentley's "More Programming Pearls", I saw the following in Sect. 2.6, Further Reading: "Aho, Kernighan, and Weinberger designed and built the original Awk language in 1977. (Whatever you do, don't permute the initials of their last names!)" The exclamation mark seems to indicate a background story. Anyone know it? N.

2 years, 9 months

4
3
0 0

Systemd Creator Lands At Microsoft

by Tomasz Rola

Well, what the title says. Some folks here wandered what the future may be. I suppose destroying Linux, or making it irrelevant. What would happened, if systemd development went in two ways, one gnu-licenced and the other commercial? https://www.phoronix.com/scan.php?page=news_item&px=Systemd-Creator-Microso… -- 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@bigfoot.com **

2 years, 9 months

9
16
0 0

Safelights (was: "9 skills our grandkids won't have")

by Greg 'groggy' Lehey

On Friday, 1 July 2022 at 17:57:35 -0700, Adam Thornton wrote: > On Jul 1, 2022, at 5:08 PM, Greg 'groggy' Lehey <grog(a)lemis.com> wrote: >> On Friday, 1 July 2022 at 20:12:44 +0200, Harald Arnesen wrote: >>> Except that we didn't use red light in our darkrooms at all, at least >>> not from the 1970s and on. ... >> >> Correct. I started darkroom work in 1964, and from the beginning we >> used amber safelights. I don't think red safelights have been used >> since long before that. > > When I learned film photography in the mid 1980s the darkroom had > red lights. Of course it was a very old darkroom in a middle school, > so I'm sure that _adequate_ darkrooms had better equipment. Hmm. Any idea how old the equipment is? I suppose you wouldn't expect people to replace existing, functional equipment without good reason. Greg -- Sent from my desktop computer. Finger grog(a)lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php

2 years, 9 months

7
8
0 0

Re: Safelights (was: "9 skills our grandkids won't have")

by Dennis Boone

> The youngsters these days wouldn't know what we're talking about, of > course... Not about most of it. Bet they do get dodging and burning, though. The terms are used in image editing programs. De

2 years, 10 months

3
2
0 0

Re: "9 skills our grandkids won't have" - Is this a TUHS topic

by Dennis Boone

> > Except that we didn't use red light in our darkrooms at all, at > > least not from the 1970s and on. ... > Correct. I started darkroom work in 1964, and from the beginning we > used amber safelights. I don't think red safelights have been used > since long before that. Another thing that the film industry > continually gets wrong. It really isn't true that red filters quit being used. Some materials are not sensitive to the broader spectrum of an amber light, making it feasible to use one. The broader spectrum is probably easier for many people to work under. Some manufacturers recommend amber safelights on the strength of improved working conditions even for materials where an amber safelight is marginal. But some materials _are_ sensitive to parts of the amber, or even to the whole visible spectrum, and other types of filter (or even no light at all) must be used. A quick perusal of B&H stock indicates that lots of red safelights are still offered. De

2 years, 10 months

1
0
0 0

Re: "9 skills our grandkids won't have" - Is this a TUHS topic?

by Greg 'groggy' Lehey

[Redirecting to COFF] On Friday, 1 July 2022 at 16:05:30 +0300, Ori Idan wrote: > On Thu, Jun 30, 2022 at 7:38 PM Paul Winalski <paul.winalski(a)gmail.com> > wrote: > >> >> o why a memory access violation is reported as "segmentation fault" or >> "bus error", and the difference between the two >> >> o why CTRL/D is used to end a shell command line session > > I am not sure I know that, I'd be happy to know. It's the ASCII control character EOT (end of transmission). >> o why CTRL/S and CTRL/Q are used for flow control in a shell command >> line session >> > Also would be happy to know. Also ASCII control characters: XON (^S) and XOFF (^Q). https://en.wikipedia.org/wiki/C0_and_C1_control_codes#Device_control tells me: DC1 and DC3 (known also as XON and XOFF respectively in this usage) originated as the "start and stop remote paper-tape-reader" functions in ASCII Telex networks. This teleprinter usage became the de facto standard for software flow control.[13] Greg -- Sent from my desktop computer. Finger grog(a)lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php

2 years, 10 months

1
0
0 0

Re: "9 skills our grandkids won't have" - Is this a TUHS topic?

by Greg 'groggy' Lehey

[Redirected to COFF] On Friday, 1 July 2022 at 20:12:44 +0200, Harald Arnesen wrote: > Tomasz Rola [01/07/2022 02.41]: > > I recall reading about some movie, whose fans >> were unable to understand why a protagonist took film (celuloid) to >> some "red room". They suggested it was for making photos sharper. > > Except that we didn't use red light in our darkrooms at all, at least > not from the 1970s and on. ... Correct. I started darkroom work in 1964, and from the beginning we used amber safelights. I don't think red safelights have been used since long before that. Another thing that the film industry continually gets wrong. Greg -- Sent from my desktop computer. Finger grog(a)lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php

2 years, 10 months

1
0
0 0

Re: "9 skills our grandkids won't have" - Is this a TUHS topic?

by Greg 'groggy' Lehey

[Redirected to COFF] On Thursday, 30 June 2022 at 15:18:50 -0700, Rik Schneider wrote: > Using a cheap pocket AM radio as an improvised signal probe. Heh. It's only been 5 years since I bought a "transistor" radio for almost exactly that purpose, to track down damage to an electric fence. It didn't work :-( Greg -- Sent from my desktop computer. Finger grog(a)lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php

2 years, 10 months

1
0
0 0

Re: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic?

by Michael Kjörling

On 30 Jun 2022 23:14 +1000, from sjenkin(a)canb.auug.org.au (steve jenkin): > What are the 1970’s & 1980’s Computing / IT skills “our grandkids won’t have”? Tediously typing computer programs into their (or others') systems from listings in printed magazines bought in and brought home from a store (by which I mean the physical, brick-and-mortar kind), only to spend anywhere from minutes to days figuring out why the program doesn't do what the magazine says it will, if it even works at all. This thread should probably be on COFF, not TUHS. -- Michael Kjörling • https://michael.kjorling.se • michael(a)kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”

2 years, 10 months

2
1
0 0

Ken Knowlton has died.

by Dan Cross

Sad news: https://www.nytimes.com/2022/06/24/technology/ken-knowlton-dead.html

2 years, 10 months

1
0
0 0

Status of classiccmp.org - take two

by Tomasz Rola

Alas, it seems like classiccmp.org is no good again. This time, when I open it, some dialog box pops up asking for a word. In the background below it, there seems to be something like a web panel... -- 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@bigfoot.com **

2 years, 10 months

1
1
0 0

Status of classiccmp.org?

by Warren Toomey

All, does anybody know the status of classiccmp.org? It's been down for a few days and I'm already missing the cctalk list. If it's a issue of hosting, and someone has Jay West's e-mail address, then I could host the list on minnie. I've just done the mailman3 upgrade with mailman2 running concurrently to provide old-school list archives. I'd be happy to give Jay access to the system. Cheers, Warren

2 years, 10 months

4
6
0 0

A talk on the origin of Colossus

by David Barto

https://www.youtube.com/watch?v=WCeLTWPCEFI At about 45 minutes it is interesting history about early computing. The Computer History Museum has released 21 videos from a 1976 conference. https://computerhistory.org/playlists/international-research-conference-on-… I’ve only watched the one, and I’m sure the others are interesting as well. David

2 years, 10 months

1
0
0 0

Grep has gone overboard

by Dave Horsfall

I remember when the documentation was easy to read, but now... I'm trying to find a regex i.e. as used by GREP to find all words in "badugly" with each letter used only once and all are 7-letter words i.e. they are all anagrams; perhaps it's my age (I hit 70 soon, after decades in Unix) but I cannot seem to find a way to restrict the count i.e. each letter used only once, but in any order. I'll guess that it involves some obscure use of "{}*\" etc, which I've never really grokked... Ta muchly. -- Dave

2 years, 11 months

4
10
0 0

Another COFF test e-mail

by Warren Toomey

All, I had someone ask if they had fallen off the COFF mailing list. So this is a test e-mail to ensure the COFF list is working OK. Cheers, Warren

2 years, 11 months

3
2
0 0

Archives of the COFF mailing list

by Warren Toomey

All, now that the COFF list has migrated over to the new mailman3 system, I should point out where the list archives are now available. They are: https://minnie.tuhs.org/mailman3/hyperkitty/list/coff@tuhs.org/ - new mailman3 format https://minnie.tuhs.org/pipermail/coff/ - old mailman2 format https://www.tuhs.org/Archive/Documentation/COFF/Mail_list/ - same as above, but in a format that makes it easier to download All mail to the COFF list should, eventually, end up in all three places. Cheers, Warren

2 years, 11 months

1
0
0 0

Oops, re hello to COFF

by Warren Toomey

All, if you got a strange 'hello' message on the COFF mailing list, my apologies. I have mailman3 set up on the new "minnie" machine, and I am going to also set up a mailman2 instance. The idea is that mailman3 will do the normal list processing and have its own archive using the Hyperkitty software. But mailman2 will be subscribed to the list, so mail can be also archived using the old pipermail software. That way, I can import the existing TUHS and COFF mailing list archives and augment them, rather than lose them entirely. I thought I'd deleted all the COFF subscribers on the new "minnie" system, but I can see in the logs that some test e-mail might have escaped. Cheers, Warren

2 years, 11 months

3
4
0 0

Re: [COFF] [TUHS] conventions around zero padding in ip4

by jnc＠mercury.lcs.mit.edu

> [the TIU] was definitely one of the first 4 TCP implementations done There may have been some other early ones; see e.g. IEN-3 Jon Postel "Meeting Notes 15 August 1977". I was thinking of the TCP's which showed up for the first TCP Bakeoff, on 27 January, 1979. > From: Lars Brinkhoff > Any idea when the TENEX implementation was made? > These files seem to be from 1982: 1982? That's almost up to Linux time, in early internet time! :-) It's like 'dog years'; a year back then was an aeon! OK, to start with, a few 'definitions': TCP 2 - the earliest version that was really implemented much; no separate IP layer TCP 2.5 - basically the same as TCP 2 (packet formats, algorithms), but with things re-labelled into 'TCP' and 'IP' TCP 3 - variable length addresses (later discarded, sadly) (The archaeology in the IENs is a little complicated, because meeting notes aren't in temporal order, IEN-number-wise. E.g. the notes for the meeting on 2-4 August 1978 (the first one I went to, BTW) are IEN-53, which came out on 21-Aug-78; but the notes for the 14-15 July 1977 meeting are IEN-65, which came out on 5-Aug-78.) Anyway, about the first details about the TENEX TCP implementation (done by Bill Pluumer, whom we have now sadly lost) I could find are in IEN-67 ("Meeting Notes - 30 & 31 January 1978"): https://www.rfc-editor.org/ien/ien67.pdf where he reports that an implementation of TCP-2 (in the OS, not in a user process, as an early version was). In IEN-53 ("Meeting Notes - 2,3&4 August 1978"): https://www.rfc-editor.org/ien/ien53.pdf Action Items 6 and 7 refer to 6) the installation of presumably somewhat working TCP 2.5's at SRI, BBN and SRI, and 7) the installation of test version of TCP 4 at BBN. Finally, IEN-57: https://www.rfc-editor.org/ien/ien57.pdf by Bill Plummer, "Provisional TCP Development Plan" (for TENEX/TOPS-20 TCP) gives sime interesting details. Noel

2 years, 11 months

2
1
0 0

Re: [COFF] [TUHS] conventions around zero padding in ip4

by Lars Brinkhoff

Noel Chiappa writes: > [The Terminal Interface Unit TCP/IP] is an interesting implementation, > because it was definitely one of the first 4 TCP implementations done > (before any UNIX ones); likely one of the first two, along with the > TENEX one. Any idea when the TENEX implementation was made? These files seem to be from 1982: https://github.com/PDP-10/tenex/blob/master/135-tenex/tcpip.mac

2 years, 11 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

COFF