Slashdot Mirror
Think Unix
In a world full of volumes like Linux: The Complete Reference, Debian GNU/Linux 2.1 Unleashed, Corel Linux for Dummies and so forth, Lasser's Think Unix is a breath of fresh air. Rather than trying to be a detailed guide to a particular system, a comprehensive reference work, or a source of answers to particular problems, Lasser tries to teach the fundamental concepts of Unix and the Unix way of thinking. He also captures something of the way in which Unix is a way of life and a culture, not just an operating system, with a good leavening of humour, history, and hackish lore. One consequence of this approach is that Think Unix will date far less quickly than most operating system books. I recommend it to computer science students, techies coming from non-Unix backgrounds, or anyone more interested in understanding the underlying ideas of Unix than solving particular problems.
Lasser starts with a chapter on documentation, explaining how to use "man" to read manual entries and touching on other forms of documentation. He then introduces the building blocks of Unix - files and processes and redirection and pipes. A brief look at TCP/IP networking, showing how to interact directly with some common network services using telnet, is followed by an introduction to vi and sed and basic regular expressions. Four chapters then deal with shell scripting in more detail, touching on differences between shells, variables and quoting, control structures, and aliases, functions, and scripts. A quick look at X explains its general design, something of the variety of window managers and desktops available, and basic configuration of startup, resources, and fonts.
Obviously a lot is left out of this (there is nothing about system administration, for example), but it provides solid foundations for further learning. And a number of topics sneak in "in passing": a mention of ssh (and associated legal issues) and a little bit about termcap and terminfo, among other things. Some practice problems are included, simple exercises to test understanding and help learning; answers to these are provided in the appendices, along with a short glossary (which includes pointers to other resources).
Think Unix has an unfortunate number of typos, including a few in code examples. And there are a few things I might have done differently (I'd have ditched most of the grainy greyscale half-page screenshots of different window managers and desktop environments, for example). Overall, however, it's a great book and the biggest problem it poses me is working out which of my "clueful but not Unix-literate" friends to pass my review copy on to.
Purchase this book at ThinkGeek.
A book review by Danny Yee <editor@dannyreviews.com>
Reviews of more than five hundred other books:
Subjects |
Titles |
Authors |
Latest
The other approach is the Unix one, which says that it's the user's responsibility to learn the system, warts and all. This is exactly the mentality that created the "Unix wizard" syndrome in the first place (people have to work hard to learn how to use the system effectively, and then they don't want it simplified for others, which would only devalue their accomplishment), and sadly, there seems to be little going on in the Linux world to counteract that.
In the short run, books like the one reviewed here are probably a good thing, but I would love to see more serious work being done to make them less needed.
It's just particular about its friends.
- Tony "Yes, it's paraphrased" Taylor
Microsoft is to software what Budweiser is to beer.
You luserish stupid! /proc. The reason thereof is left as an exercise for the reader.
That command will, on a Linux system, only erase every file/directory in the root beginning wiuth a character ASCIIbeticaly prior to 'p'. After doing so, it will get stuck into an endless loop in
Next time you try to educate users, please write commands that at least _terminates_, that is, either returns or core-dumps.
--The knowledge that you are an idiot, is what distinguishes you from one.
Well, I'm a professional Unix sysadmin (And the author of the book. :-)). We're a Solaris/IRIX/Linux shop. Linux is the same. Or at least as much as either Solaris or Irix is.
We've moved many of our central AFS servers to Linux from Irix because Linux is much more stable. (Solaris does well too as an AFS fileserver, but why pay more when you don't get more?)
We've moved most of our labs from Irix boxes to Linux boxes. We're down to two labs with Irix boxes, which will probably be replaced in the next year or so with Linux boxes and decent 3D cards.
About one-third to one-quarter of our central servers (for around 20,000 active accounts) are Linux boxes.
Linux is Unix.
The book has eleven chapter. The last two chapters are about X. X is a major Unix subsystem that most people have significant problems with, so it needed to be covered.
Put another way, the book is has 242 pages of main text. Pages 1 through 196 don't have a damned thing to do with X; pages 197-242 are about X. Nothing before page 197 cares whether or not you have X, so not having X shouldn't stop anyone from getting through the majority of the book..
Hey, I'm the author of the book. This is a fair criticism, but...:
- There's an errata for the book. It is, as far as I'm aware, entirely complete and up-to-date. It's over here (the address is listed in the book, yes). You can determine how many of these have any impact whatsoever on the content.
- There are two typos I know of (one of which Danny Yee reported, and both of which are in the errata) in 'code examples' (that is, anything that looks like a transcript of a session). One of those is in the output of a command (the wrong quotes are displayed as output), and the other is a case where the point is that a certain thing doesn't work. (In talking about $0-$9, I show that $10 doesn't work. Only it was shown as 10 rather than $10 in the example.) This one should be clear from the context, but the point is that it doesn't work anyway.
- I am anal-retentive. But things get messed up in the editing phase, as documents are passed back and forth among half a dozen people and file formats change, etc.
- It's also a first printing. Some stuff will be fixed in the second printing. Everything will be fixed in the third printing. The second edition of the Llama book's first printing was horrendous. Especially the code examples.
Correctness is important to me. But I'd have to say that it's pretty darned good. Check the errata and decide for yourself before making a comment like this, please.I've been playing with Linux/Unix/BSD since 1994, and am mostly self taught. Most of my friends think I'm a guru, but I have to tell you, I haven't even earned my benie yet - much less a wizards hat. The system can be so complex, and user hostile at times, that it defy's description. While I'm sure it will never be as easy to use as say DOS 4.0 was, I'm hopeful that one day, it won't be so needlessly complex! That, and we need to loose the attitude "It was hard for me to learn, so bend over and take it like a man!" that we get from the veterens.
Fawking Trolls!
"Going to war without France is like going deer hunting without your accordion." - Jed Babbin
Yes, sorry. I should have made that clear. I have no real use for X, as most of the games I like to play (when I have time) don't run yet on X. If StarCraft and Diablo II would run under wine, I'd be alright - but they don't. Also, I've noticed that the distributed.net client doesn't work as well in the GUI as it does in CLI mode on Linux. My old system (Athlon 500 128M ram) which was Slackware 4.0.0 got 1.2Mkeys/sec CLI but only 350~Kkeys/Sec under X. The performance hit was totally unacceptable. Maybe X 4.0.0 will be loads better, but somehow I doubt this. I don't need a GUI to get work done - I'm a lan/wan specialist for DaimlerChrysler. I use PING more than anything else these days, mainly to find IP addresses that contractors steal without permission. One quick DOS on that IP and suddenly I get a call for support. "Hey, I can't see the file server anymore!" "Really? What's your IP address, and who asigned it to you?" He he he.
From the intuitive standpoint, I don't think X is anywhere near up to being as good as it's competition, HOWEVER I think it's strength lies in it's flexability. I was showing the PFS guy at work all the different GUI's that come with Mandrake 7.1 and he was astonished. Too bad it slows the system down so bad. But again, perhaps this is my fault - if it wasn't so hard to learn how to configure things, maybe I could get X to run better. I dunno. I'm going to buy this book (I'm such a sucker for books) and see if it teaches me anything I don't already know.
Fawking Trolls!
"Going to war without France is like going deer hunting without your accordion." - Jed Babbin
Sigh. The point in a way is that most things from M$ work about the same - not so in Linux. I've found TAR to be user hostile at times. Now that I understand TAR, it isn't anymore - you lack the perspective of struggling to learn something that is initially difficult. You're "There" You have "Arrived" and you "Grok" it. As a result, you don't understand why others have a hard time with it. It's no different than when I was studying medicine in the service - AFTER I had been to school, I always wondered why people had a hard time "getting it" so to speak. I've had good friends and close realitives give me that "deer in the headlights" stare when I talk computers with them - It's all about the level you're at, and how much the person or people you're trying to learn from are willing to share information in a way that you will understand. Case in point: DOS 5 had an EXCELLENT help system. Unix has MAN. I am JUST NOW starting to get useful information from MAN pages - they were TOTALLY incomprehensible to me at first. This is why sites like Linuxnewbie make NHF's (Newbieized Help Files) for people like me - MAN pages don't cut it if you don't already speak the language.
Fawking Trolls!
"Going to war without France is like going deer hunting without your accordion." - Jed Babbin
I think Mike Gancarz' book:
The unix philosophy
is better, from the "Think UNIX" title perspective
The Unix Programming Environment, by Brian Kernighan and Rob Pike? It was first published in 1983 but is still very relevant.
The Unix Philosophy is a good book for examining some of the underlying concepts in what makes a good program. It cuts to the heart of why so many people love Unix. It distills what makes shells and pipes and I/O redirection such powerful concepts and warns against many of the things that happen in creeping featurism.
The net will not be what we demand, but what we make it. Build it well.
"Linux Companion: For Users and system Administrators". Mostly about converting MS-DOS concepts (hey, it was 1995ish) into UNIX-speak. Unfortunately, it was my first book and wasn't quite as clearly written as some of my later works. Also, Linux wasn't quite as popular in 1995 as it is now. Might even be in print still....I should check..
-- Ever notice that fast-burning fuse looks exactly the same as slow-burning fuse? I didn't... (Edgar Montrose)
Got Rhinos?
When you get right down to it - a core set of UNIX skills would be good for any linux enthusiast... They're portable between distributions - and heck you never know when you are going to be in front of a "linux-like" (that's a "Maddog" quote) operating system like AIX, HP/UX, Solaris or some BSD deriviative...
BlackNova Traders
It bothers me when the reviewer gives a book a positive rating, but then goes on to say, "but there are a lot of typos, and some of the code examples don't work." Imagine that you're a Unix/Linux newbie, and you copy a shell command from a book, and get some obscure syntax error. Unless you have the shell background to figure out what's wrong (and of course you don't, you're a newbiew) you're stuck. You'll probably put the book down and never pick it up again.
Good technical communication is written by the anal-retentive. Sad, but true.