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.
FYI: The llama book is indeed an O'Reilly book (Learning Perl)
As far as I know, it is one of only a handful of O'Reilly books more commonly referred to by their colophonic companion animal than by their official title. The others being the Camel book (Programming Perl) and the bat book (Sendmail). There may be a couple of others, but those three are the only ones I know of that fit that description
Ahh - My eye!
The doctor said I'm not supposed to get Slashdot in it!
Like in most arguements, there is a mid point and see both points. I think the *nixes in general could be easier to learn. Could someone please re-write my damn man pages please? I understand they all sound like they were written by pissed off programmers venting their hatred for the end-user as they pretended to explain the functionality. Man pages are good for simple commands but try figuring out how to do something complex with awk and sed from the man page. No way! That is why O'Reilly has a whole book on awk and sed.
Anyway, I can also see the other side of the point though. Once you know one *nix you really are able to adjust quickly. Honestly, I kind of like working from my Sparc Ultra 5. Solaris is damn stable and helixcode runs really smooth on it. The terminology is a little different and really the only thing else that would freak newbie out about my Sparc is the placement of directories. The different *nixes are not that different. People seem to be very frightened about moving between them. I think that is rather odd.
ACK
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.
These are all fixed. Thank you for reporting the problems.
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.Actually, I was never slapped. Just modded into oblivion. :-)
I could never get StarCraft to function under WINE. I couldn't even get it to load, even if I pointed it at my existing windows directory. I could never get the fake registry to work. WINE really needs to be able to create all the things it needs to work on it's own, if it doesn't find them. That, or we need a good configuration tool that will do this.... Hmm.... Think I've found my next project...
Fawking Trolls!
"Going to war without France is like going deer hunting without your accordion." - Jed Babbin
Perhaps you could mail me your registry? I'm at the address above, or wsl3@stlnet.com - I'd sure appriciate the help. If I can get StarCraft running, I'm 1/2 way to getting rid of windows.
Fawking Trolls!
"Going to war without France is like going deer hunting without your accordion." - Jed Babbin
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
At the moment, I think that most of my colleagues only try to learn Unix from the surface: instead of learning how the system is built up and WHY it is built up that way, they just keep memorizing commands and their parameters. :)
This book could be helpful to them, I think. I'll propose that it will be bought next time
I think Mike Gancarz' book:
The unix philosophy
is better, from the "Think UNIX" title perspective
"huh?" yerself! Sit down and configure a Solaris box when all you know is Linux and see where you end up.
I agree, this book sounds good to me. I'd like to see the underlying similarities in the *nixes.
"Dude", the point is, if the only *nix you've ever had the opportunity to use before is Linux, and your forced to mess with a Solaris box...uh, it's a little alien.
Bully for you for all your *nix experience, may it stand you in good stead. Meanwhile, I don't have that background. I need to know how the different *nices are similiar.
And...my mind is made up, I don't know how they're similar.
Yeah, I can copy files, list directories, edit files, etc. In that way, yes, they're similar, but until you mentioned "slice instead of partition..." I had no idea what "slice" was referring to.
I think you've illustrated the point that other people have made. That gurus have gotten to the point of obtuseness in their knowledge.
I'm as guilty of it as anyone though. I can't understand why the user can't figure out how to copy a file to a floppy disk, and I treat them as if they're an idiot, when the truth is, I'm an idiot for assuming everyone else in the world "should" know as much about "insert knowledge specialty here" as I do.
Just a note: Starcraft has run well under WINE for over a year, at least... Works For Me(TM).
By the way, I see your bitchslap has ended... visible posting again, must be fun.
--
"It's tough to be bilingual when you get hit in the head."
Hmmm, the only problems I had with it (once loaded) was that saving games would freeze up now and again... the fake registry is... well, the original registry is a hack, so emulate that, and... ugh... VMWare provides a cleaner solution, but (of course) life would be better for everyone if games were ported to linux/BSD . Then again, a reworked windowing system might not hurt...
--
"It's tough to be bilingual when you get hit in the head."
See the last comment where I mentioned VMWare... that's my current solution, since I found it a lot easier than WINE (and although it does run all of Windows) it tends to be more stable than wine, and I can run a broader set of apps with less fussing... I'll have to check through some old backups to see if I have that registry...
--
"It's tough to be bilingual when you get hit in the head."
The Unix Programming Environment, by Brian Kernighan and Rob Pike? It was first published in 1983 but is still very relevant.
Great shit, you might be on to something, Holmes! This 'Linux' OS is sold by Redhat and Linux-Mandrake, put on hardware from VA... and what OS does Slashdot talk about? You guessed it -- Linux!
Schmuck.
-grendel drago
Laws do not persuade just because they threaten. --Seneca
Sit down and configure a Solaris box when all you know is AIX / HP-UX / IRIX / Ultrix / *BSD and see where you end up.
(You can shuffle any of the others into the 'Solaris' position there with much the same effect.)
That's exactly *why* a book that tries to teach the *concepts* behind Unix is a great idea, rather than learning the right magic for just the box you happen to be using now.
Regards,
Tim.
More books with this perspective are needed.
This is why I always recommend the Frisch book from O'Reilly over the Nemeth Sysadmin book. It actually starts with files & processes and works its way up. I find that it gives a MUCH better grounding in WHY you do something a particular way as opposed to just explaining HOW you do it.
IMHO,
Michael
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?
I really don't see your point. I've been using Linux for about 2 years, and I feel pretty competent by now. Certainly not a "guru" or "wizard" (I don't know C well and have done but one trivial change to the kernel source), but I pretty much understand the system from a user and administrator point of view. Unix, from my experience, is hardly ever "user hostile" - it was just written by and for people who're really knowledgeable about computers and can appreciate a utility like sed - difficult to learn, but astonishingly powerful when used properly. And the comparison with DOS 4.0 is ridiculous - any ease of use that had was simply a result of its lack of features.
The illegal we do immediately. The unconstitutional takes a little longer.
--Henry Kissinger
I know where your coming from. I started with slackware in 94' and sometimes for the first couple of years i felt exactly like you. Now however I administer 3 flavors of Unix and 4 flavors of Linux for IBM. I can tell you the only difference between me now and then is hours of practice and reading (and a deep inner questioning of how things work). The reason "guru's" get tired of newbies is because we suffered and RTFM and asked how things worked. MSDOS has very little features so of course it didn't take you long to learn. If you don't have time to sit down and figure it out your not going to hurt my feelings. The less people who know how Unix works the more money sys admins will make ;).
- 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.
How about some errata for the errata?p.31 - I assume that should be "Socrates", not "Soctrates"
p.46 - "user", not "uger"
p.123 - "last", not "lasgt"
p.128 - "digits", not "difits"
BTW, p.154 - æ is æ :)
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
I'm assuming that you refer to the CLI since X is neither any less or more 'intuitive' than other GUI's (I'm sure there are those who would differ). The complexity you refer to allows efficiencies flexibility that just doesn't exist in the GUI realm. I run X on my Linux box, but I still find myself going to a term window to do many things that are actually easier from the command line or are nigh on to impossible in the GUI.
--
As a matter of fact, I am a lawyer. But I play an actor on TV.
As far as being less intuitive, I don't think any GUI lives up to the 'intuitive' hype. I remember when the Apple Lisa came out and I watched all kinds of people move the mouse and click on icons and get frustrated when nothing happened. Not intuitive. We only think GUI's are intuitive because we've used them for such a long time.
--
As a matter of fact, I am a lawyer. But I play an actor on TV.
This is part of the reason why it is important the OS doesn't get out of the hands of the people.
isomerica.net | Foonetic IRC
Danny's review left me with the impression that there were more than two code errors. I suppose that's a low enough rate to make me actually want to see the book, but I'm still bothered. Here are some general comments which may not apply to your book:
Errata, revised printings, etc., can mitigate some errors, but there are absolutely things you must get right the first time. One early publisher had to recall an entire printing of the Bible because of one typo (a "shalt" instead of "shalt not"). Funny to us, but less humorous in an era when Religious Incorrectness was a capital offense. Or consider a similar error in a medical textbook...
If your book is getting "messed up" by your editors, then your publisher has some basic problems. Why on earth do you need to do a lot of format conversions? If a publisher is serious about producing technical books in a computer era, they should be standardizing on one or two well-structured formats.
You can argue that this kind of problem is not the author's fault. Perhaps, but I'm not particularly interested in assigning blame. I just want to know what authors and publishers produce work I can use.
You mention "the Llama book". I assume this is something from O'Reilly -- I haven't memorized all their cute colophons. This is one publisher I have strongly mixed feelings about. On the one hand, they have some first-rate authors, are the only publishers of authoritative works on many topics, and have some carefully thought-out procedures for writing, editing, and production. On the other hand, they manage to produce a lot of badly edited books -- and even a fair number of paper doorstops. Not a gold standard, I'm afraid.
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.
why not recommend the book?
You can still run X on BSD, right? You can still run X on Mac OSX too...
I completely and tottaly agree. Linux isn't user friendly, like it or not... it's guru friendly yes, but that's besides the point. I'm no guru, I can barely shell script, but I can recompile my kernel, add perhiphrels, install programs, etc. but if X refuses to load, I'm really screwed. Most newbs don't have the patience to "bend over and take it like a man" this is perfect for my unix illiterate friend
When all freedom is outlawed only the outlaws have freedom
rm -rf /
And if you don't need a help system before typing that, you sure will afterwards. Oops, I forgot Linux hard-deletes files with no recovery.
If you're a jock, inflict some pain / If you're a nerd then use your brain - DAPHNE AND CELESTE
i learned UNIX/Linux by surfing the net,reading LDP, and crashing my PC! Newbies certainly doesnt need books to master UNIX althought getting one would help to a certain degree. There is no substitute for self-learning and determination.
I thought the goal was to get MORE people using Unix / Linux. Giving newbies harmful advice is only going to send them running back to momma Microsoft. Do you just take some kind of sick pleasure in screwing other people up? I supose if you were teaching someone DOS you'd tell them the online help system is called "fdisk." Jerk. Kasreyn
Kasreyn: Cheerfully playing the part of Devil's Advocate to hairtrigger
No Shit, I couldn't have stated it better myself. Linux/Unix/BSD are wonderful once you know what the hell your doing. The problem is for the most part Unix Admin's/GURU's are assholes and fell threated when you ask the questions on advanced topics. It's the GOD Complex..