This is to follow up on ideas for discuss engaging the conceptual side of understanding servers and what servers do.
What does that mean? Are there sysadmin-ish books analogous to Martin Davis’s Engines of Logic (math) or Jeff Potter’s Cooking for Geeks (cooking) that folks have enjoyed?
I hasten to add this is not a request for professional training resources.
It’s more like asking attorneys to learn about divorce law by reading Susan Moller Okin’s Is Multiculturalism Bad For Women?
That is, necessary but not sufficient — and some would argue not necessary.
Some suggest skipping the book search and pursuing a mostly exclusive wax on, wax off approach instead.
This is kind of like “I’d like to read about the theory of driving a car.” There might be a book on it, but I don’t know of one. It might make you a bit better of a driver, but if you’re trading off time behind the wheel for reading about driving it’ll make you a worse driver. There’s basics and in-depth details that are covered by the docs for any common service you’ll run, and from there you gotta get behind the wheel, have a clear goal, start small, get advice from a community that’s familiar with the services you’re running, and be as risk-averse as you can.
I’m not a professional sysadmin, I’ve only done it as part of jobs when we ran our own boxes, for lab setup for dealing with that hell, and for fun. There are best practices, and important considerations, which the docs for services will cover and you’ll pick up if you’re doing it, but they aren’t grounded in a theoretical framework, AFAICT, and there are no universal axioms that apply to each component that are worth taking the time to learn. There are too many ways to do too many things for a universal theory to apply well. You could study computer science, theories of computation, understand the hardware architecture, learn operating systems in depth, and be better grounded in principles, and that can help for depth, but it’s not that important to most tasks unless you’re doing something really cutting edge or esoteric, and it’s a life-long slog. If you want a high-level work that gives you a nice theoretical framework of the big picture from logic gates down to the OS, Petzold’s “Code: The Hidden Language of Computer Hardware and Software” is good (and fun), but reading it won’t make you any better as a sysadmin.
Thank you! I love Charles Petzold’s book on Code and have even dipped into Annotated Turing. I almost mentioned Code as an example.
And, as in studying law, he, Martin Davis and similar writers have been helpful to me at least as often as the compilations of rules and recipes in the “programming” shelves in places like Barnes & Noble.
I don’t know of a book akin to Martin Davis’s Engines of Logic re: systems administration. You’re dealing with what amounts to configuring a collection of diverse pieces of software on what could be a diversity of platforms that haven’t necessarily got much in common, to accomplish a goal that can often be accomplished in many ways (depending), and aren’t unified by much other than how you choose to set it up. There’s no unifying principles that could make sense that I can think of, other than OS/service-specific ones.
There are some things like knowing the UNIX philosophy, though, assuming you’re just interested in UNIX. Kernaghan and Pike’s The UNIX Programming Environment is old and often out of date but goes into that. There’s ESR’s writings, which are not bad when he’s stealing things from other people, though usually bad when he’s not. You can mostly sum it up without a book, but with a one page pamphlet, though: write/use programs that do one thing well, work together, and handle text streams which are the universal interface for UNIX.
Double thank yous for helping me. I will look around for Kernaghan and Pike’s The UNIX Programming Environment. It sounds like you’re drawn to it for its readability and interest.
I want to say again that of course you’re right that a book is not a substitute for practice. We can’t learn to cook an egg, ride a bike or hit a baseball from a book. Sometimes love for doing those things can be discovered in a book, and that’s not the same as practicing to do those things well.
At one point, @tropo used vocabulary like low level network protocol. That sounded like the part of the layer cake I was hoping to . . . erm . . . eat, I guess. I read Tim Berners-Lee’s book Weaving the Web and thought it was interesting. I’m hoping to learn more in the server-ish zones without resorting to a lot of man pages.
And I get the idea I should know the answer but . . . ESR?
Thank you again for responding patiently and kindly.
man pages are written in a kind of formal structure, but they’re often pretty detailed and will usually be telling you what you should know, even if it’s not what you think you want to know.
Maybe you’re more interested in networking/systems things than administration of a server per se? That’s its own ball of wax, and alas, while IP networking and network communication protocols are valuable to understand in as much detail as you can manage, I have no resources since I learned it piecemeal over years. That is another life-learning exercise, since it goes very deep.
Eric. S Raymond. I retract that. You’re probably better off just ignoring him if you aren’t familiar. He collected/stole a lot of bits and pieces from the MIT people, Kernighan/Ritchie/Pike/etc. that are otherwise scattered all over - but it’s not cohesive, and it’s so polluted with his own horrible injections that I’d prefer not to be a person suggesting it.
Yep. I’d deleted a rather long paragraph of slagging ESR’s many faults before posting that since I realized there was only venting with nothing constructive.
Ah! I should’ve guessed by the initials. I read about him in a fun book by Glyn Moody called Rebel Code: Linux and the Open Source Revolution and I have opened Cathedral and the Bazaar without getting into it though I’m very interested in ideas I associate with the metaphor.
And I see that you and @codinghorror both think that ESR isn’t the right way to go. The commentary I’ve skimmed in the tutorial that @codinghorror posted looks good. (Thank you!) I’ve actually learned a fairsmall amount of CLI syntax over the years which I tend to mostly forget almost as soon as I learn it since it does not plug into a regular professional daily practice for me — mostly.
I guess I’m conceding your (everyone’s?) point again about a project-based approach and practice.
ETA for @codinghorror’s post and link . . . bookmarked!! So fun!
In your linux post, I like how you identified the familiar practical tasks you want performed. An article about why and how those questions interest you could also be fun to read.
DON’T buy a parrot figuring that it will be a fun surprise for me. To acquire a parrot is a major decision: it is likely to outlive you. If you don’t know how to treat the parrot, it could be emotionally scarred and spend many decades feeling frightened and unhappy. If you buy a captured wild parrot, you will promote a cruel and devastating practice, and the parrot will be emotionally scarred before you get it. Meeting that sad animal is not an agreeable surprise.
Doing is the only way any of the technical stuff will stick for any duration. If you go that route, you will be spending a good deal of time with man pages.
Be happy they’re not RFCs. If you get down to a low enough level with network protocols, at some point you’ll find yourself reading RFCs and cursing vendors for their (sometimes loose) interpretation of them.
Like @nemomen, my sysadmin experience came out of necessity, and I never really spent any time with books on the subject.
Most of the books I can recommend in networking are “nuts and bolts” sort of works. TCP/IP Illustrated (Vol 1-3) are excellent. It is networking at a deep level though, and I hesitate to recommend them unless you find yourself seriously dealing with the topic. The inside front cover of vol I has (among other things) this handy diagram of the structure of a TCP packet, which you will find yourself repeatedly referencing as you work through the chapters.:
Many pages consist entirely of networking sequence diagrams, like this:
I suppose this speaks to the way I’ve approached learning about computer related topics over the years. I rarely buy a book unless I’m really down in the weeds on a given topic and / or am considering purchasing a reference I will continually revisit.
This is super cool. Thank you. What sort things happened that caused you to need to study and practice these tasks? A memoir about having those problems could be right on target also.
I guess it really depends on what your goal is. Do you just want to have a high level understanding of what a sysadmin does? Or are you looking to actually do sysadmin work?
My experience has been that getting to a conceptual understanding of servers, operating systems and applications takes a lot of doing menial tasks until, hopefully, you start putting the pieces together for yourself.
For most sysadmin’s I know, their career path starts out in the trenches of the helpdesk, doing boring repetitive tasks that no one wants really wants to do.Hopefully you learn the basics of maintaining the health of an OS, the actual server part, and if you’re good, you develop a proper understanding of troubleshooting. Then and only then are you ready to move on to the next level, which is likely going to be maintaining a service or an application which seems to be where you’re headed.
If you’re just starting out with Linux then I would suggest something like this
Start by doing.
Move on to learning about administrating whatever application you’re interested in and slowly build your knowledge from there. I don’t know about a single source that can give you an overview like what you’re looking for but I do know that you can learn a lot if you narrow your focus to reaching a specific goal like setting up your own webserver.
of a person.
So fun!
