[olug] Reccomended Reads

[Sam Flint]

I have the K&R got it for $.50 at a a goodwill, they still sell it,
and it's $70 at Barnes and noble.  and thanks, i was just wondering
what you all recommended

On Sun, Aug 5, 2012 at 6:08 PM, Christopher Cashell <topher-olug at zyp.org> wrote:
> On Fri, Jul 13, 2012 at 10:52 PM, Sam Flint <harmonicnm7h at gmail.com> wrote:
>> Does anyone have any favorited in relation to linux/software
>> development? Adam's book doesn't count, sorry.
>
> *Note: Sorry for the delay in sending this.  It grew a little beyond my
> initial intention, and took a while before I could get around to finishing
> it.*
>
> I read, well, a **lot**.  Reviewing my technical library, here's the ones
> that I think are the cream of the crop.  This might be a bit of a firehose
> suggestion list, but I like to be thorough.
>
> I'm going to break them into handful of different categories: Linux/Unix,
> Networking, DevOps, Programming/Development, etc.  I'm also listing them in
> roughly the order I would recommend reading them for each group, assuming
> you were going to read them all through (in order).  Obviously, you can
> pick and choose which ones appeal to you.  Those that really should be read
> in a certain sequence, I'll try to note.  I'll include a short summary or
> explanation of why each book is worth reading, too.
>
> If there's any questions on any of the books here, let me know.  I'd be
> happy to go into greater depth or discuss further details on them.
>
> System Administration (focus on Linux/Unix):
>
> *Linux in a Nutshell; by Ellen Siever, Stephen Figgins, Robert Love and
> Arnold Robbins*
>
> This book will be a bit of a chore to get through, as the majority of the
> book is a list of commands, common usage, and a little information about
> their most common options.  However, it's worth reading.  Working through
> the whole thing will inform you about the hundreds of Unix commands that
> have been around for decades.  That knowledge is gold.  When you're at a
> command line, trying to get something done, half the battle is knowing that
> a command exists that will do what you need, and the other half is
> remembering what it's called.  The man pages will take care of the rest.
>  Note: older editions of this book will give you 90% of the use at cheaper
> price, and "Unix in a Nutshell" will get you about 75% of the value, too.
>
> *Essential System Administration; by Aeleen Frisch*
>
> This book has been a classic for years.  Well written, great cross-platform
> coverage, and a ton of great information.  The one downside is that the
> latest edition is now a decade old, so some of the information is a little
> dated.  Luckily, the "unix design" has proved itself remarkably stable, so
> this is still a great book.
> *
> *
> *UNIX and Linux System Administration Handbook; by Evi Nemeth, Garth
> Snyder, Trent R. Hein, Ben Whaley*
>
> This is one of the "must have" books on Unix/Linux System Administration.
>  It is encyclopedic in its coverage, and very well written.  It is clear
> enough to read through and learn from, while also being thorough enough to
> make a great reference.  It does a great job with cross-platform (Unix)
> coverage, too.
>
> *Unix System Management Primer Plus; by Jeffrey S. Horwitz*
>
> This book is a criminally unknown gem.  First thing to note, about 75% of
> the book is not Unix (or Linux) specific, it's about general system
> administration.  Secondly, this book is a little higher level than most in
> this section.  It spends a little bit of time on command line and low level
> details, but the majority of the book is bigger picture stuff.  This
> shouldn't be your first System Admin/management book, but anyone who's
> responsible for more than a few dozen machines, or for anyone who wants to
> work up from Junior Engineer to Senior Engineer, this book should be a Must
> Read.
>
> *The Practice of System and Network Administration; by Tomas A. Lioncelli, *
> *Christina J. Hogan, and Strata R. Chalup*
>
> This book follows in the same style as Horowitz's *Unix System Management
> Primer Plus*.  It covers system administration at a level above the command
> line.  Things like planning, policies and procedures, upgrades, change
> management, etc.  If your goal is to be a Senior System
> Administrator/Engineer, or a manager in a Systems department, this is a
> book you need to read.
>
> *Windows Server 2008 Administrators Pocket Consultant; by William R. Staneck
> *
> *
> *
> Like it or not, we frequently have to deal with Windows.  Stanek's *Pocket
> Consultant* books are incredibly handy for those times.  They take most of
> the common admin tasks you might need to deal with and condense them down
> to nice practical chunks. Excellent for a practical reference.
>
> DevOps (SysAdmin/Programming crossover):
>
> *Minimal Perl for Unix/Linux People; by Tim Maher*
>
> This book is an interesting one.  First of all, it's written in a friendly,
> "fun", easy to read style.  It approaches Perl from the perspective of a
> system administrator, and introduces Perl by showing how it can replace
> other command line tools and simpler scripting systems (awk, sed, etc).
>  It's a different way of presenting a programming language, but for someone
> with a decent Unix/Linux background, it'll ease you into Perl in a very
> comfortable way.
>
> *Automating System Administration with Perl: Tools to Make You More
> Efficient; by David N. Blank-Edelman*
>
> This book assumes a basic familiarity with Perl.  It then takes you on a
> tour of possibilities in automation.  This is an area that a lot of people
> overlook, but is a hallmark of great system administrators.  Every time you
> repeat a task, you should ask yourself a few questions: *Am I going to have
> to do this again? How frequently? How long does it take each time? How long
> would it take to automate it?* The answer to these will help you decide
> whether it's worth automating the task.  As you get into larger
> environments, your ability to automate will be a huge factor in your
> ability to scale.  This book will show you examples in numerous areas of
> system administration and how to automate them.
>
> *sed & awk; by Dale Dougherty and Arnold Robbins*
>
> For many system administrators, sed is that tool you use to do simple text
> substitutions (does it do anything else?) in a series of piped commands,
> and awk is that weird old scripting tool that grumpy old beared unix guys
> talk about.  In actuality, these are two of the most powerful tools in your
> Unix/Linux toolbox.  They have an incredible amount of flexibility, and
> you'll use them in one-liners and in shell scripts.  For simple text
> processing (ad hoc log reports, etc), there is no tool better than awk.  If
> I'm writing a script that I know will be more than 100 lines, I'll usually
> grab Perl.  But for a first pass, awk is hard to beat.  I would bet that
> 3/4 of the Perl programs I've written that process logs are rewrites of
> earlier awk scripts.
>
> *Mastering Regular Expressions; by Jeffrey E. F. Friedl*
>
> If you're working at a command line or working with any text processing
> (including log processing), Regular Expressions will be very important for
> you.  This book is the bible for Regular Expressions.  Now, most people
> won't read this book in it's entirety, and that's ok.  Half of this book is
> on generally using regular expressions, and half of it goes into the guts
> of regular expressions, how they work, how they're implemented, and how to
> do things with regular expressions that can only be described as insane.
>  Great reference, though.
>
> Programming/Development:
>
> *How to Design Programs, 2nd Ed.; by Mathhias Felleisen, Robert Bruce
> Findler, Matthew Flatt, and Shirriam Krishnamurthi*
>
> This is a great book, although not quite what a lot of people expect.  This
> book is an introduction to computer science.  It really is about designing
> programs, and this is not a *How to Program in Language Foo* type of book.
>  Note, the style of writing is a little different for this one (the authors
> are MIT professors). Available online, free:
> http://www.ccs.neu.edu/home/matthias/HtDP2e/
>
> *The C Programming Langauge, 2nd Ed.; by Brian W. Kernighan and Dennis M.
> Ritchie *
>
> This book is *the* book you need if you're going to learn or use C.  The
> first time I saw it, I almost laughed at it.  It's a slim volume, roughly
> 200 pages, and I couldn't believe they wanted $40 for such a meager volume.
>  Luckily, I got past my initial reaction and bought the book.  I soon
> realized its value far outreaches the price.  This is not only the best
> book on C programming, it's one of the better books written on programming.
> It is a model of clear and concise writing.
>
> *The Practice of Programming; by Brian W. Kernighan, Rob Pike*
>
> This book is kind of like taking years of experience and condensing it into
> a slim, easy to read book.  This language agnostic book (examples cross
> nearly half a dozen languages) isn't about algorithms, or language
> features.  It's like having an experienced software engineering mentor
> standing over your shoulder telling you some of the best lessons he's
> learned in his years on the job.
>
> *Unix Programming Environment; Brian W. Kernighan, Rob Pike*
>
> This book was written in 1984.  As it nears its 30th birthday, it's
> obviously an outdated relic that serves no purpose outside of a quaint
> picture of ancient history.  Except, it's still relevant.  Yes, there are
> some details and specifics that are a little dated, but the book is still
> very useful, and most of the information it is still fully applies today.
>  This book is about programming with C in the Unix world, and it
> illustrates the design philosophy and idea behind both Unix and C.
>
> *The Art of Unix Programming; by Eric S. Raymond*
>
> In many ways, this book is an expanded and updated take on *The Unix
> Programming Environment*.  It covers more ground, and it isn't as focused,
> but ESR does a great job of distilling the "unix philosophy", expounding
> the benefits behind the philosophy, and explains how to develop software in
> the unix style.  ESR's style does come off as a touch biased towards
> Unix/Linux being the greatest thing in the history of computing, but it's
> hard to fault the information.  The writing style is fun, and he includes
> plenty of anecdotes/case studies and observations on "unix culture".
>  Available online, free: http://catb.org/esr/writings/taoup/html/
>
> *Modern Perl; by chromatic*
>
> This book provides a nice introduction to "modern" Perl programming.  The
> Perl language has evolved significantly over the years, and in the last 3-4
> years, there's been a renewed interest in Perl.  Part of that interest
> comes from updating the best practice and recommendations for Perl to take
> advantage of modern OO techniques, improving code readability and project
> scalability.  Today's Perl is not the Perl of 20 years ago, and this book
> shows you how you *should* be writing Perl.  Available online, free:
> http://modernperlbooks.com/books/modern_perl/chapter_00.html
>
> *Effective Perl Programming, Second Edition: How to write Better, more
> Idiomatic Perl; by Joseph N. Hall, Joshua A. McAdams, brian d foy*
>
> This book won't teach you Perl.  But, it will make you a better Perl
> Programmer.  This book is like a compendium of Perl experience, idioms,
> best practices, and information.  It shouldn't be the first book you read
> on Perl, and possibly not the second, but if you are writing Perl programs
> that are larger than 100 lines of code, you should absolutely read this
> book.
>
> *Advanced Programming in the UNIX Environment; W. Richard Stevens, Stephen
> A. Rago*
>
> This is a classic programming reference book.  If you're writing serious C
> and you're doing it in Unix/Linux, this book is for you.  It has extensive
> and in-depth coverage of the Unix API's covering IO (file, network,
> terminal, etc), process handling, threads and threading, IPC, etc.  If you
> need to talk directly to the OS, you need this book.
>
> *Advanced Unix Programming; Marc J. Rochkind*
>
> This book is similar in style and coverage to *Advanced Programming in the
> Unix Environment*.  Depending on personal preference, this book could be a
> reasonable alternative.  This one is a little bit easier read, while
> Stevens goes a little more in-depth in certain areas.
>
> *The Linux Programming Interface: A Linux and Unix System Programming
> Handbook; by Michael Kerrisk*
>
> Another in the same vein of Stevens and Rochnkind, but with a stronger
> Linux focus.  Kerrisk is best known for maintaining the Linux Kernel and
> glibc man pages for nearly 10 years.  If you need a more thorough
> reference, specifically for Linux APIs, this is your book.
>
> *Structure and Interpretation of Computer Programs; by Harold Abelson and
> Gerald Jay Sussman with Julie Sussman*
>
> This is kind of the spiritual successor to *How to Design Programs**.*  It
> was used as an introductory Computer Science textbook at MIT for years, and
> was written by MIT professors.  This is not a book you skim through in a
> few evenings and then put to practical use.  This book is about thinking,
> logic, and computer science, not just programming.  Available online,
> free:  http://mitpress.mit.edu/sicp/
>
> Networking:
>
> *Internet Core Protocols: The Definitive Guide; by Eric Hall*
> *
> *
> This book covers TCP/IP at the protocol level (IP, TCP, UDP, ICMP, etc),
> along with a some coverage of common application protocols (HTTP, FTP, DNS,
> etc).  In the modern world of computing, networks are a way of life.  Every
> machine we touch is going to be on a network, so system administrators and
> programmers need to have a solid grounding in network basics. Note: This
> book does assume a basic knowledge of TCP/IP.  If you don't know what
> TCP/IP stands for, or you've never heard of the OSI model, you shouldn't
> make this your first networking book.
>
> *TCP/IP Illustrated, Volume 1: The Protocols; by Kevin R. Fall, W. Richard
> Stevens*
>
> This is the TCP/IP bible.  If you want a truly excellent understanding of
> TCP/IP at the packet level, this is the book to read.
>
> *Network Warrior; by Gary A. Donahue*
> *
> *
> If you find yourself responsible for managing network devices (switches,
> routers, etc), this will be a great resource to have.  It doesn't go deep
> on theory, but it is high on practical advice and examples.
>
> Databases:
>
> This section is missing some entries because I have yet to find books that
> I thought were good enough that I could wholeheartedly recommend them.  If
> anyone has recommendations, I'd love to hear them.
>
> Databases are a bit of a tricky topic.  There are at least 4 distinct
> subtopics that have to be considered, and most books tend to cover only
> one, or maybe two, of them.  Additionally, depending on your role, you may
> not need to have in-depth knowledge of all of them.
>
> *[Book on SQL Queries]*
>
> I think the best book on writing SQL queries that I've personally read so
> far is *SQL Queries for Mere Mortals*, by John L. Viescas and Michael J.
> Hernandez.  It was a solid book, but I didn't think it was great.
>
> I've heard that *The Langauge of SQL: How to Access Data in Relational
> Databases*, by Larry Rockoff is a good *introductory* book on writing SQL,
> but I haven't read it yet.  I expect that you'd need a more advanced book
> on SQL to complement it, from what I know of it.  Something like *Joe
> Celko's SQL for Smarties: Advanced SQL Programming* by Joe Celko might make
> a good companion.
>
> *Head First SQL*, by Lynn Beighley is another one that's on my list to
> check out, and might be a good book for introducing SQL.
>
> *[Book on Database Design]*
>
> There are tons of books on writing SQL queries, but not nearly as many on
> good database design.  Database design is a topic that frequently gets
> neglected.  Developers think that if they can write SQL queries, they can
> design a DB schema.  Some SQL query books will even touch on DB design, and
> may have a chapter on DB normalization.  DBAs are often stuck spending most
> of their time managing the RDBMS software and may be lacking the domain
> knowledge of the application, and not be in a good position to aid in
> schema design.  Unfortunately, poor DB design will bite you in the ass
> later.  If you don't understand database normalization, you shouldn't be
> designing databases.
>
> *[Book on Data Modeling]*
>
> Data Modeling is a topic that gets ignored even more frequently than
> Database Design.  Data Modeling is how you go from your data sources to
> your database schema.  For example, figuring out how to properly transform
> your product ordering process into a database falls under data modeling.
>
> *SQL Cookbook, by Anthony Molinaro*
> *
> *
> Like other books in O'Reilly's excellent "Cookbook" series, this book is a
> specialized reference.  It won't explain SQL, but it might save your butt.
>  The quantity and quality of SQL examples here is great.  If you are
> working with SQL databases and you know what kind of query you need, but
> don't know how to write it, there's an excellent chance this book will have
> a "recipe" that can get you started.
>
> *The Art of SQL; by Stephane Faroult, Peter Robson*
>
> Like a few others on this list, this book is a bit of an oddball.  It won't
> teach you SQL.  It won't teach you DB design.  It definitely shouldn't be
> your first or second book on databases.  It will take you through advanced
> database concepts and techniques and make you a better DBA.  It will show
> you new ways of thinking about databases and why it's important to do so.
>  This is one of the absolute best advanced database books I've read.
>
> Other:
>
> *Time Management for System Administrators; by Tom Limmoncelli*
>
> I've got friends that work in other industries who will occasionally
> comment on how they were bored at work, and had nothing to do that day or
> even that week.  It's a bit of a foreign concept for me, because I usually
> have a "to do" list that will keep me busy for the next 7 years.  In the
> field of System Administration, there are always systems that could use
> cleanup, updating, reworking, etc.  There's always processes that need to
> be documented and after being documented, are candidates for being
> automated.  This book can help us take advantage of the time we have and
> maximize our efficiency.
>
> *The Mythical Man-Month; by Frederick Brooks, Jr.*
>
> An IT classic.  This is less a technical book, but should be a must read
> for anyone who works in the IT industry.
>
>
> Hopefully some of the suggestions will be useful.  I know I'm forgetting a
> few, but I've got half of my IT books at work, and half of them at home
> (spread across a couple of bookshelves).  If I think of any more, I'll send
> an update.  Or maybe I'll post the whole list online somewhere, in case
> anyone else wants suggestions on IT books.
>
>> Sam
>
> --
> Christopher
> _______________________________________________
> OLUG mailing list
> OLUG at olug.org
> https://lists.olug.org/mailman/listinfo/olug



-- 
Sam Flint
flintfam.org/~swflint