* [TUHS] Re: Unix Systems Administration Texts
2023-03-01 2:34 ` [TUHS] " Dan Cross
@ 2023-03-01 3:24 ` Larry McVoy
2023-03-01 9:03 ` steve jenkin
` (2 subsequent siblings)
3 siblings, 0 replies; 10+ messages in thread
From: Larry McVoy @ 2023-03-01 3:24 UTC (permalink / raw)
To: Dan Cross; +Cc: The Eunuchs Hysterical Society
On Tue, Feb 28, 2023 at 09:34:33PM -0500, Dan Cross wrote:
> On Tue, Feb 28, 2023 at 8:38???PM Will Senn <will.senn@gmail.com> wrote:
> > I'm curious about the experience of those of y'all who actually used them. Were there any early standouts and why did they stand out?
>
> This is not going to be popular, but...
>
> > Nemeth, E., Synder, G., & Seebass, S. (1989). UNIX System Administration Handbook (5th edition is another fatty)
>
> This book gave me some terrible advice when I was very young and impressionable.
Yet another reason I'm not a Evi Nemeth fan. I could go on but I won't.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [TUHS] Re: Unix Systems Administration Texts
2023-03-01 2:34 ` [TUHS] " Dan Cross
2023-03-01 3:24 ` Larry McVoy
@ 2023-03-01 9:03 ` steve jenkin
2023-03-01 18:34 ` Pete Wright via TUHS
2023-03-01 22:57 ` Alan D. Salewski
3 siblings, 0 replies; 10+ messages in thread
From: steve jenkin @ 2023-03-01 9:03 UTC (permalink / raw)
To: TUHS
Dan,
I used the Nemeth book when I didn’t know how to do the odd thing or finding a tool,
but the book was predicated on a very specific Academic environment.
You can see why she’d suggest making tools reliable, robust and ‘complete’ (done ‘properly’)
in their environment with a large, constantly changing workforce, kids all too prone to ‘exploring’ things
or breaking something and then not knowing what to do…
From 1995, I spent around a decade doing contract SysAdmin.
The well run, well staffed and “no drama” sites never needed me :)
I got “parachuted behind enemy lines”, having to fight my way out,
so many times that I discovered I had a process for “Digging myself Out”
<https://stevej-on-it.blogspot.com/2007/06/digging-out-turning-around-challenged.html>
The key is to gain time by automating tasks, starting with what gains the most time for you,
not business or managerial priorities.
There’s at least three levels of script / tool,
I thought were all covered in that Bill Plauger PDF recently but aren’t:
<https://indico.cern.ch/event/318305/attachments/612388/842557/PJPlauger-ITSeminar-Fifty_years.pdf>
1. Stuff for yourself.
2. A "Program Product" for a small, competent group.
3. A hardened product / Application that the unwashed masses will use and test to destruction.
As a lone Sys Admin it’s incumbent on you to leverage the Automation under your control, not drown in entropy.
If you do Admin in seriously large sites, eg AWS or GOOG, practices have to be adapted to avoid outages - any outage will have massive impact.
At Internet Scale, the only methodology that can work is:
"systems are cattle not pets”- create tools that easily scale to the entire fleet & are particularly robust & reliable.
Admins can’t be allowed to ever type at a production console - much more controlled than the old Boulder Uni environment.
HTH
sj
> On 1 Mar 2023, at 13:34, Dan Cross <crossd@gmail.com> wrote:
>
>> Nemeth, E., Synder, G., & Seebass, S. (1989). UNIX System Administration Handbook (5th edition is another fatty)
>
> This book gave me some terrible advice when I was very young and impressionable.
>
> In there somewhere it says something about not doing something unless
> you're prepared to do it right lest one spend more time working around
> a work-around than one would have spent just doing it well in the
> first place.
>
> The conclusion is, of course, true, but the admonition ignores all
> sorts of externalities, like waiting users. And in some cases it could
> really lead to paralysis ("omg _everything_ is broken and I can't do X
> until I do Y, but to do Y I have to do this other thing and if I
> really want to do it right I need to start by traveling to Nepal and
> shaving this Yak, but I need to get my passport renewed and damn I
> really oughta lose 20 pounds before I get my passport photo taken for
> the next ten years, so I guess I oughta join a gym...but I can't even
> find one because the network is down and I can't get to Google, but
> how can I fix the network if I have not shaved the Nepalese yak?!").
> Talk about letting the perfect be the enemy of the good.
>
> Hopefully nowadays we have a better appreciation of the power of
> incrementalism; those grand plans for the perfect system rarely come
> to fruition. It's better to be flexible and make small, impactful
> changes along the way towards a better system, always being mindful of
> and tamping down encroaching entropy.
>
> - Dan C.
--
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* [TUHS] Re: Unix Systems Administration Texts
2023-03-01 2:34 ` [TUHS] " Dan Cross
2023-03-01 3:24 ` Larry McVoy
2023-03-01 9:03 ` steve jenkin
@ 2023-03-01 18:34 ` Pete Wright via TUHS
2023-03-01 22:57 ` Alan D. Salewski
3 siblings, 0 replies; 10+ messages in thread
From: Pete Wright via TUHS @ 2023-03-01 18:34 UTC (permalink / raw)
To: Dan Cross; +Cc: The Eunuchs Hysterical Society
On Tue, Feb 28, 2023 at 09:34:33PM -0500, Dan Cross wrote:
> On Tue, Feb 28, 2023 at 8:38 PM Will Senn <will.senn@gmail.com> wrote:
> > I'm curious about the experience of those of y'all who actually used them. Were there any early standouts and why did they stand out?
>
> This is not going to be popular, but...
>
> > Nemeth, E., Synder, G., & Seebass, S. (1989). UNIX System Administration Handbook (5th edition is another fatty)
>
> This book gave me some terrible advice when I was very young and impressionable.
>
>
> In there somewhere it says something about not doing something unless
> you're prepared to do it right lest one spend more time working around
> a work-around than one would have spent just doing it well in the
> first place.
>
i'll agree here with you on that, but i will say that as a front line sysadmin
at the time it was one of the few resources i had that covered how to do basic
tasks correctly across many unix systems. it helped me alot as a sysadmin for
hire early in my career - esp when i had to fix something at a site with a poorly
maintained unix i may not have had much experience with at the time - "sure i can
fix your print spooler running hpux".
-pete
--
Pete Wright
pete@nomadlogic.org
^ permalink raw reply [flat|nested] 10+ messages in thread
* [TUHS] Re: Unix Systems Administration Texts
2023-03-01 2:34 ` [TUHS] " Dan Cross
` (2 preceding siblings ...)
2023-03-01 18:34 ` Pete Wright via TUHS
@ 2023-03-01 22:57 ` Alan D. Salewski
2023-03-02 0:41 ` Adam Thornton
3 siblings, 1 reply; 10+ messages in thread
From: Alan D. Salewski @ 2023-03-01 22:57 UTC (permalink / raw)
To: TUHS (The Unix Heritage Society)
On Tue, Feb 28, 2023, at 21:34, Dan Cross wrote:
> On Tue, Feb 28, 2023 at 8:38 PM Will Senn <will.senn@gmail.com> wrote:
>> I'm curious about the experience of those of y'all who actually used them. Were there any early standouts and why did they stand out?
>
> This is not going to be popular, but...
>
>> Nemeth, E., Synder, G., & Seebass, S. (1989). UNIX System Administration Handbook (5th edition is another fatty)
>
> This book gave me some terrible advice when I was very young and impressionable.
>
> In there somewhere it says something about not doing something unless
> you're prepared to do it right lest one spend more time working around
> a work-around than one would have spent just doing it well in the
> first place.
>
> The conclusion is, of course, true, but the admonition ignores all
> sorts of externalities, like waiting users. And in some cases it could
> really lead to paralysis
[...]
> Hopefully nowadays we have a better appreciation of the power of
> incrementalism; those grand plans for the perfect system rarely come
> to fruition. It's better to be flexible and make small, impactful
> changes along the way towards a better system, always being mindful of
> and tamping down encroaching entropy.
>
> - Dan C.
Yeah, good or bad advice at just the right time can have quite an
impact.
In the under-celebrated "Minimal Perl"[0], Tim Maher notes in the
last paragraph of section 5.8:
<quote>
In your own career, I'd advise you to develop an appreciation an
appreciation and an aptitude for both the /quick-and-dirty/ and
/elegant-and-formal/ styles of programming, and to cultivate the
ability to produce either kind on demand, as circumstances
warrant.
</quote>
Seems obvious, in retrospect -- but of course many things do with
the benefit of hindsight. For me, that articulated something that I
sensed was the right way to approach things, but was contrary to
much of the one-dimensional advice I had received up to that
point. It pairs well with one of the "lesser tenets" noted by
Gancarz: "Look for the 90 percent solution"[1].
In my own career, I've found I can often use the quick-and-dirty
approach to buy myself time to afford the "detour to build the
tools"[2] that could not be justified (to others) up-front. And
nothing gets it done faster than a shell script. Five or ten scrappy
N-line shell scripts that get the job done sub-optimally, and
lacking any real thought toward usability or generality buy time to
build better tools (usually more, better-written shell scripts). And
sometimes a scrappy script is "good enough" (for years, even).
-Al
[0] Minimal Perl for Unix People and Linux People
by Tim Maher
Forward by Damian Conway
Manning 2007
p. 175
ISBN-10: 1-932394-50-8
[1] The Unix Philosophy
by Mike Gancarz
Digital Press 1995
p. 117
ISBN-10: 1-55558-123-4
[2] [McIlroy78] The Bell System Technical Journal. Bell Laboratories.
M. D. McIlroy, E. N. Pinson, and B. A. Tague.
"Unix Time-Sharing System Forward". 1978. 57 (6, part 2). p. 1902.
https://archive.org/details/bstj57-6-1899/page/n3/mode/2up
Also quoted in ESR's "The Art of Unix Programming"
Addison-Wesley 2004
p. 12
ISBN-13: 9-780131-429017
https://www.catb.org/~esr/writings/taoup/html/ch01s06.html
--
a l a n d. s a l e w s k i
ads@salewski.email
salewski@att.net
https://github.com/salewski
^ permalink raw reply [flat|nested] 10+ messages in thread
* [TUHS] Re: Unix Systems Administration Texts
2023-03-01 22:57 ` Alan D. Salewski
@ 2023-03-02 0:41 ` Adam Thornton
2023-03-02 2:02 ` Jan Schaumann via TUHS
0 siblings, 1 reply; 10+ messages in thread
From: Adam Thornton @ 2023-03-02 0:41 UTC (permalink / raw)
To: Alan D. Salewski; +Cc: TUHS (The Unix Heritage Society)
[-- Attachment #1: Type: text/plain, Size: 3852 bytes --]
I liked the Frisch and Limoncelli/Hogan books. Nemeth less so.
Adam
On Wed, Mar 1, 2023 at 3:59 PM Alan D. Salewski <ads@salewski.email> wrote:
>
>
> On Tue, Feb 28, 2023, at 21:34, Dan Cross wrote:
> > On Tue, Feb 28, 2023 at 8:38 PM Will Senn <will.senn@gmail.com> wrote:
> >> I'm curious about the experience of those of y'all who actually used
> them. Were there any early standouts and why did they stand out?
> >
> > This is not going to be popular, but...
> >
> >> Nemeth, E., Synder, G., & Seebass, S. (1989). UNIX System
> Administration Handbook (5th edition is another fatty)
> >
> > This book gave me some terrible advice when I was very young and
> impressionable.
> >
> > In there somewhere it says something about not doing something unless
> > you're prepared to do it right lest one spend more time working around
> > a work-around than one would have spent just doing it well in the
> > first place.
> >
> > The conclusion is, of course, true, but the admonition ignores all
> > sorts of externalities, like waiting users. And in some cases it could
> > really lead to paralysis
> [...]
>
> > Hopefully nowadays we have a better appreciation of the power of
> > incrementalism; those grand plans for the perfect system rarely come
> > to fruition. It's better to be flexible and make small, impactful
> > changes along the way towards a better system, always being mindful of
> > and tamping down encroaching entropy.
> >
> > - Dan C.
>
> Yeah, good or bad advice at just the right time can have quite an
> impact.
>
> In the under-celebrated "Minimal Perl"[0], Tim Maher notes in the
> last paragraph of section 5.8:
> <quote>
> In your own career, I'd advise you to develop an appreciation an
> appreciation and an aptitude for both the /quick-and-dirty/ and
> /elegant-and-formal/ styles of programming, and to cultivate the
> ability to produce either kind on demand, as circumstances
> warrant.
> </quote>
>
> Seems obvious, in retrospect -- but of course many things do with
> the benefit of hindsight. For me, that articulated something that I
> sensed was the right way to approach things, but was contrary to
> much of the one-dimensional advice I had received up to that
> point. It pairs well with one of the "lesser tenets" noted by
> Gancarz: "Look for the 90 percent solution"[1].
>
> In my own career, I've found I can often use the quick-and-dirty
> approach to buy myself time to afford the "detour to build the
> tools"[2] that could not be justified (to others) up-front. And
> nothing gets it done faster than a shell script. Five or ten scrappy
> N-line shell scripts that get the job done sub-optimally, and
> lacking any real thought toward usability or generality buy time to
> build better tools (usually more, better-written shell scripts). And
> sometimes a scrappy script is "good enough" (for years, even).
>
> -Al
>
>
> [0] Minimal Perl for Unix People and Linux People
> by Tim Maher
> Forward by Damian Conway
> Manning 2007
> p. 175
> ISBN-10: 1-932394-50-8
>
> [1] The Unix Philosophy
> by Mike Gancarz
> Digital Press 1995
> p. 117
> ISBN-10: 1-55558-123-4
>
> [2] [McIlroy78] The Bell System Technical Journal. Bell Laboratories.
> M. D. McIlroy, E. N. Pinson, and B. A. Tague.
> "Unix Time-Sharing System Forward". 1978. 57 (6, part 2). p. 1902.
> https://archive.org/details/bstj57-6-1899/page/n3/mode/2up
>
> Also quoted in ESR's "The Art of Unix Programming"
> Addison-Wesley 2004
> p. 12
> ISBN-13: 9-780131-429017
> https://www.catb.org/~esr/writings/taoup/html/ch01s06.html
>
> --
> a l a n d. s a l e w s k i
> ads@salewski.email
> salewski@att.net
> https://github.com/salewski
>
[-- Attachment #2: Type: text/html, Size: 4958 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* [TUHS] Re: Unix Systems Administration Texts
2023-03-02 0:41 ` Adam Thornton
@ 2023-03-02 2:02 ` Jan Schaumann via TUHS
0 siblings, 0 replies; 10+ messages in thread
From: Jan Schaumann via TUHS @ 2023-03-02 2:02 UTC (permalink / raw)
To: tuhs
Adam Thornton <athornton@gmail.com> wrote:
> I liked the Frisch and Limoncelli/Hogan books. Nemeth less so.
Having taught a system administration grad level class
for many years now, I think there's an evolution of
the profession whereby books that were previously
practically useful are less so now.
Nemeth et al was useful in a very practical sense
(e.g., Pete's example of "fix printer spooler on
HP-UX"), but Limoncelli's books were always stronger
in principles.
Taking it further up the layer of abstractions, I then
found Mark Burgess's works more valuable, but that
very much leaves the realm of vocation (which I
maintain is hard to capture in books anyway) and
goes towards the more theoretical side.
The profession has evolved (or even splintered)
dramatically, with DevOps, SRE, and cloud computing
covering overlapping but different sets of work in
this area. All that is very different from the early
days of administering Unix systems.
I still struggle with the balance of teaching students
basic Unix skills, conveying (true) Unix multiuser
system concepts, translating administrative principles
into containerized, ephemeral environments, especially
at large scale...
-Jan
^ permalink raw reply [flat|nested] 10+ messages in thread