The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: steve jenkin <sjenkin@canb.auug.org.au>
To: Dan Cross <crossd@gmail.com>
Cc: Marc Donner <marc.donner@gmail.com>, TUHS <tuhs@tuhs.org>
Subject: [TUHS] Re: LOC [was Re: Re: Re.: Princeton's "Unix: An Oral History": who was in the team in "The Attic"?
Date: Wed, 9 Nov 2022 20:01:25 +1100	[thread overview]
Message-ID: <29942374-F162-43EE-9F65-D51C79B4D7B4@canb.auug.org.au> (raw)
In-Reply-To: <CAEoi9W4dz7vvjyaXu26Zv5KXXujQzbh18=9wTrrW24qRS3zxig@mail.gmail.com>


> On 9 Nov 2022, at 19:41, Dan Cross <crossd@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… 

Machines were smaller, programs simpler and we were closer to the hardware.
Literally, like the “Unix Room”, in the Attic at Bell Labs.

Admin & Operations weren’t too onerous and “Maintenance” was done by the people doing the kernel & systems software, at a guess.
And maybe hardware was fixed by the Vendor, or super-programmers did the plug and play themselves.

As sites got bigger, work became multi-person project ’teams’ and admin problems got tricker, while ‘certain people’ did the work.

When Unix became properly commercial - multiple vendors, big manuals, support contracts, and a plethora of Unix variants - some Bright People created “Unix Training” courses, in many topiocs.

Somewhere around this time, courses and job titles for “System Admin” appeared.

Sadly, all this happened without any distinctions in capability & ‘levels’, or actual problem solving testing (cf CISCO’s CCIE: 2 days of testing, 1st day quizzes on a PC, 2nd day is by invitation. Lab session: “fix the broken network in the allotted time”)

SAGE - System Admin Guild, part of USENIX - put together a bunch of small books on (Unix) System Admin Topics and tried to guide the development of the field.
After 10 years, I was out of the loop and hadn’t seen anything positive in the workplace.

SRE roles & as a discipline has developed, alongside DevOps, into managing & fault finding in large clusters of physical and virtual machines.

Never done it myself, but it’d seem the potential for screw-ups is now infinite and unlimited in time :)

--
Steve Jenkin, IT Systems and Design 
0412 786 915 (+61 412 786 915)
PO Box 38, Kippax ACT 2615, AUSTRALIA

mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin


  parent reply	other threads:[~2022-11-09  9:03 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-11 11:15 [TUHS] " Paul Ruizendaal via TUHS
2022-10-11 13:48 ` [TUHS] " Larry McVoy
2022-10-11 13:59   ` Warner Losh
2022-10-11 19:43     ` Marc Donner
2022-10-11 19:54       ` Larry McVoy
2022-10-11 20:02         ` Michael Kjörling
2022-10-11 20:08           ` Rob Pike
2022-10-11 21:07             ` Dan Cross
2022-10-11 21:41               ` Rob Pike
2022-10-12  6:59             ` arnold
2022-10-12  7:03               ` Michael Kjörling
2022-10-12  7:18                 ` Rich Morin
2022-11-29  7:31               ` Joseph Holsten
2022-10-11 20:10           ` Larry McVoy
2022-10-11 20:14             ` Michael Kjörling
2022-10-11 20:33               ` [TUHS] LOC [was " Charles H Sauer (he/him)
2022-11-07 17:50                 ` [TUHS] " Warner Losh
2022-11-07 19:57                   ` Bakul Shah
2022-11-07 20:11                   ` Dan Cross
2022-11-08 18:55                   ` Marc Donner
2022-11-09  8:41                     ` Dan Cross
2022-11-09  8:49                       ` arnold
2022-11-09 20:17                         ` Dave Horsfall
2022-11-09  9:01                       ` steve jenkin [this message]
2022-11-09 10:55                         ` Brad Spencer
2022-11-09 11:56                         ` Stuart Remphrey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=29942374-F162-43EE-9F65-D51C79B4D7B4@canb.auug.org.au \
    --to=sjenkin@canb.auug.org.au \
    --cc=crossd@gmail.com \
    --cc=marc.donner@gmail.com \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).