[TUHS] Unix Systems Administration Texts

[Alan D. Salewski]

On Tue, Feb 28, 2023, at 21:34, Dan Cross wrote:
> On Tue, Feb 28, 2023 at 8:38 PM Will Senn <will.senn at 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 at salewski.email
salewski at att.net
https://github.com/salewski