Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The Linux Programming Interface

samzenpus posted more than 3 years ago | from the read-all-about-it dept.

Books 73

Muad writes "Michael Kerrisk has been the maintainer of the Linux Man Pages collection (man 7) for more than five years now, and it is safe to say that he has contributed to the Linux documentation available in the online manual more than any other author before. For this reason he has been the recipient a few years back of a Linux Foundation fellowship meant to allow him to devote his full time to the furthering this endeavor. His book is entirely focused on the system interface and environment Linux (and, to some extent, any *NIX system) provides to a programmer. My most obvious choice for a comparison of the same caliber is Michael K. Johnson and Eric W. Troan's venerable Linux Application Development, the second edition of which was released in 2004 and is somewhat in need of a refresh, lamentably because it is an awesome book that belongs on any programmer's shelf. While Johnson and Troan have introduced a whole lot of programmers to the pleasure of coding to Linux's APIs, their approach is that of a nicely flowing tutorial, not necessarily complete, but unusually captivating and very suitable to academic use. Michael's book is a different kind of beast: while the older tome selects exquisite material, it is nowhere as complete as his — everything relating to the subject that I could reasonably think of is in the book, in a very thorough and maniacally complete yet enjoyably readable way — I did find one humorous exception, more on that later. Keep reading for the rest of Federico's review.This book is an unusual, if not altogether unique, entry into the Linux programming library: for one, it is a work of encyclopedic breadth and depth, spanning in great detail concepts usually spread in a multitude of medium-sized books, but by this yardstick the book is actually rather concise, as it is neatly segmented in 64 nearly self-contained chapters that work very nicely as short, deep-dive technical guides. I have collected an extremely complete technical library over the years, and pretty much any book of significance that came out of the Linux and Bell Labs communities is in it — it is about 4 shelves, and it is far from portable. It is very nice to be able to reach out and pick the definitive work on IPC, POSIX threads, or one of several socket programming guides — not least because having read them, I know what and where to pick from them. But for those out there who have not invested so much time, money, and sweat moving so many books around, Kerrisk's work is priceless: any subject be it timers, UNIX signals, memory allocation or the most classical of topics (file I/O) gets its deserved 15-30 page treatment, and you can pick just what you need, in any order.

Weighing in at 1552 pages, this book is second only to Charles Kozierok's mighty TCP/IP Guide in length in the No Starch Press catalog. Anyone who has heard me comment about books knows I usually look askance at anything beyond the 500-page mark, regarding it as something defective in structure that fails the "I have no time to read all that" test. In the case of Kerrisk's work, however, just as in the case of Kozierok's, actually, I am happy to waive my own rule, as these heavyweights in the publisher's catalog are really encyclopedias, and despite my bigger library I will like to keep this single tome within easy reach of my desk to avoid having to fetch the other tomes for quick lookups — yes, I still have lazy programmer blood in my veins.

There is another perspective to this: while writing, I took a break and while wandering around I found myself in Miguel's office (don't tell him ;-), and there spotted a Bell Labs book lying on his shelf that (incredibly) I have never heard of. After a quick visit to AbeBooks to take care of this embarrassing matter, I am back here writing to use this incident as a valuable example: the classic system programming books, albeit timeless in their own way, show their rust when it comes to newer and more esoteric Linux system calls (mmap and inotify are fair examples) and even entire subsystems in some cases — and that's another place where this book shines: it is not only very complete, it is really up to date, a combination I cannot think of a credible alternative to in today's available book offerings.

One more specialized but particularly unique property of this book is that it can be quite helpful in navigating what belongs to what standard, be it POSIX, X/Open, SUS, LSB, FHS, and what not. Perhaps it is not entirely complete in this, but it is more helpful than anything else I have seen released since Donald Lewine's ancient POSIX Programmers Guide (O'Reilly). Standards conformance is a painful topic, but one you inevitably stumble into when writing code meant to compile and run not only on Linux but to cross over to the BSDs or farther yet to other *NIX variants. If you have to deal with that kind of divine punishment, this book, together with the Glibc documentation, is a helpful palliative as it will let you know what is not available on other platforms, and sometimes even what alternatives you may have, for example, on the BSDs.

If you are considering the purchase, head over to Amazon and check out the table of contents, you will be impressed. The Linux Programming Encyclopedia would have been a perfectly adequate title for it in my opinion. In closing, I mentioned that after thinking for a good while I found one thing to be missing in this book: next to the appendixes on tracing, casting the null pointer, parsing command-line options, and building a kernel configuration, a tutorial on writing man pages was sorely and direly missing! Michael, what were you thinking?

Federico Lucifredi is the maintainer of man (1) and a Product Manager for the SUSE Linux Enterprise and openSUSE distributions.

You can purchase The Linux Programming Interface from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×

73 comments

Sorry! There are no comments related to the filter you selected.

man FP (0)

Anonymous Coward | more than 3 years ago | (#34164004)

no entry found.

"a tutorial on writing man pages was...missing!" (4, Interesting)

windcask (1795642) | more than 3 years ago | (#34164070)

I think anyone who has the overwhelming dedication to create a 1500+ page tome about every nook and cranny of the Linux API can be spared the task of explaining how to write text files. But that's just me.

Re:"a tutorial on writing man pages was...missing! (1, Informative)

Anonymous Coward | more than 3 years ago | (#34164266)

Man pages are written in [ng]roff format, so no, they're not just text files.

Re:"a tutorial on writing man pages was...missing! (1)

noidentity (188756) | more than 3 years ago | (#34164458)

I think anyone who has the overwhelming dedication to create a 1500+ page tome about every nook and cranny of the Linux API can be spared the task of explaining how to write text files. But that's just me.

Man pages are written in [ng]roff format, so no, they're not just text files.

It's even worse than that. They're all just strings of zeroes and ones, even Linux programs. I think the author can be spared the task of explaining how to write a string of zeroes and ones, don't you think?

Re:"a tutorial on writing man pages was...missing! (3, Funny)

afabbro (33948) | more than 3 years ago | (#34164642)

I think anyone who has the overwhelming dedication to create a 1500+ page tome about every nook and cranny of the Linux API can be spared the task of explaining how to write text files. But that's just me.

Man pages are written in [ng]roff format, so no, they're not just text files.

It's even worse than that. They're all just strings of zeroes and ones, even Linux programs.

They're actually bits, not strings. I will spare myself the task of explaining further.

Re:"a tutorial on writing man pages was...missing! (2, Informative)

noidentity (188756) | more than 3 years ago | (#34164932)

They're actually bits, not strings. I will spare myself the task of explaining further.

Good, because it wouldn't be necessary. On the other hand, in an informal sense, a string is "A linear sequence of characters, words, or other data" (from Google dictionary). In this case, it's a linear sequence of bits. The bits aren't characters (unless your machine's characters are a single bit wide), but I think string was appropriate. I could have called them a one-dimensional vector, or a linear sequence of bits, but I guess I didn't think of you when writing the post.

Re:"a tutorial on writing man pages was...missing! (0)

Anonymous Coward | more than 3 years ago | (#34168136)

I could have called them a one-dimensional vector, or a linear sequence of bits, but I guess I didn't think of you when writing the post.

Won't somebody please think of the pedants?

Re:"a tutorial on writing man pages was...missing! (1)

Tetsujin (103070) | more than 3 years ago | (#34164844)

Man pages are written in [ng]roff format, so no, they're not just text files.

It's even worse than that. They're all just strings of zeroes and ones

I think I saw a two in there!

Re:"a tutorial on writing man pages was...missing! (4, Informative)

trb (8509) | more than 3 years ago | (#34164730)

Man pages are plain text files, but not just text files. They are also not just ?roff files. They are written using the "man page macros" for [gnt]roff. These man page macros were written for UNIX in the 1970's, and survive pretty much unchanged. You can find doc for them on your Linux system by typing: man 7 man or http://www.unix.com/man-page/Linux/7/MAN/ [unix.com]

If Kerrisk is the keeper of man 7, and he was supposed to cover man 7 in his book, then yes, this would be an oversight.

The ?roff language was pretty much "assembler language" for typesetting - you weren't supposed to write your documents in raw ?roff. In those days, before word processors like msword and oo, and before TeX and LaTeX, anyone who wrote docs for UNIX systems was well versed in the different macro packages, including some of man, ms, mm, me, and others.

Re:"a tutorial on writing man pages was...missing! (2, Funny)

sconeu (64226) | more than 3 years ago | (#34164998)

Ah... memories...

The mm and me packages. Used me at UCSC in '84, and mm for about 10 years at my first job (before MSWord became ubiquitous).

And of course, it's part of one of the unix puns...

A Unix software pirate says, "Argv! nroff -me timbers!"

Re:"a tutorial on writing man pages was...missing! (1)

mehemiah (971799) | more than 3 years ago | (#34179892)

not to mention there's a guide to writing Techinfo pages also. While I get the humor, man page writing isn't programming so I don't think it would fit in a book Named "The Linux Programming Interface"

Re:"a tutorial on writing man pages was...missing! (1)

ByOhTek (1181381) | more than 3 years ago | (#34164500)

I'm guessing this is a joke, given that programming code files are also "just text files"?

Re:"a tutorial on writing man pages was...missing! (1)

blair1q (305137) | more than 3 years ago | (#34167906)

You saved me posting that.

Re:"a tutorial on writing man pages was...missing! (1)

mr_mischief (456295) | more than 3 years ago | (#34169092)

In good, human-readable languages the sources are "just text files". Some languages use binary source files that only a specific IDE can make useful. Others are "just text files" with significant white space which you need a good editor or an IDE to use reliably, but you can muddle through with a lesser editor.

Re:"a tutorial on writing man pages was...missing! (1)

ByOhTek (1181381) | more than 3 years ago | (#34172424)

funny, I find the ones without significant whitespace (or that let it be omitted) to be the problem...

Then again, I've never programmed in whitespace. [wikipedia.org]

Re:"a tutorial on writing man pages was...missing! (1)

mr_mischief (456295) | more than 3 years ago | (#34181672)

Well, I'm glad you enjoy programming in ABC and Python. That lets you maintain code I'd rather not. :-)

Actually, many more languages have some significance to whitespace. In most languages, though, it's a matter of presence or absence around some non-whitespace syntax.

ABC and Python with their level of indentation determining scope are really difficult to edit correctly if you're stuck without the proper editor some time, though.

Re:"a tutorial on writing man pages was...missing! (1)

ByOhTek (1181381) | more than 3 years ago | (#34188974)

Not familiar with ABC, don't mind python.

I hate certain code practices of reducing whitespace in C-likes, since they make it harder for me to find blocks of code (such as putting the block-opener at the end of the line, instead of on it's own line).

I usually use Eclipse, Emacs or, when in Windows doing a quick script, Notepad, when I use Python, so I guess I've never had a "the wrong editor" problem.

Re:"a tutorial on writing man pages was...missing! (1)

mr_mischief (456295) | more than 3 years ago | (#34220522)

Are you sure? I've always considered Notepad the wrong editor for just about anything. Even Microsoft's DOS edit.com was a better editor as far as I'm concerned.

I'm more of a vi/vim/cream (in a pinch elvis or vile), geany, or Kate person. Eclipse or Emacs aren't bad and I'm not here to start an editor flame fest. I just prefer modal commands to a lot of meta keys. I understand others prefer the opposite. Graphical is okay most of the time, but having something that's curses based or even line based to fall back when editing on a server is nice.

Whichever editor and language you prefer, though, I just hope you never end up having to edit Python across the wire with your termcap messed up.

OTOH, although I'm not fond of a few of the particular decisions Guido made, Python's a very useful language. On the bright side, making the indentation style part of the language spec saves a lot of paint on the bike sheds.

Re:"a tutorial on writing man pages was...missing! (1)

windcask (1795642) | more than 3 years ago | (#34175922)

Sure they are. The executables they generate are not, however. And neither are the man pages, generated by the macros trb spoke of. And let's leave out binary-level includes such as bitmaps, drivers, codecs, and the like...it doesn't change the fact that the core elements of man pages are just plain text output with a minimal amount of formatting.

yay! (1)

whitehaint (1883260) | more than 3 years ago | (#34164210)

sudo apt-get install first_post.deb

Re:yay! (4, Funny)

jpate (1356395) | more than 3 years ago | (#34164248)

wow, apt-get just keeps getting slower!

Re:yay! (3, Funny)

Anonymous Coward | more than 3 years ago | (#34164426)

Yea, but the frist_post.rpm is still stuck in dependency hell.

Re:yay! (1)

blair1q (305137) | more than 3 years ago | (#34164964)

Is there an app for that?

Re:yay! (1)

mr_mischief (456295) | more than 3 years ago | (#34169094)

urpmi
yum
yast

*ducks*

Re:yay! (0)

Anonymous Coward | more than 3 years ago | (#34168108)

But he got his post out while my yum was still slowly loading plugins. Then it had to wait two hours for PackageKit to let go of the lock. Just checked back and it's downloading all the repository listings again. I'm sure I'll get to post some time this year.

Anyone got a summary of the summary? (2, Funny)

noidentity (188756) | more than 3 years ago | (#34164278)

tl; dr. Anyone got a summary of the summary?

Re:Anyone got a summary of the summary? (5, Funny)

Anonymous Coward | more than 3 years ago | (#34164294)

It's a book.

Re:Anyone got a summary of the summary? (0)

Anonymous Coward | more than 3 years ago | (#34164424)

ts;nm

Re:Anyone got a summary of the summary? (2, Funny)

martin-boundary (547041) | more than 3 years ago | (#34166442)

It's a book.

NOO! It's ... It's a Linux COOKBOOK!

Re:Anyone got a summary of the summary? (1, Insightful)

Profane MuthaFucka (574406) | more than 3 years ago | (#34164428)

Summary - If you need to know about the Linux, then buy this book using the link provided. We're not going to tell you that Slashdot gets a kickback if you use the link, but fuck it. Pudge is gone now and he was the only real journalist around the place, so we don't consider ourselves obligated to reveal conflicts of interest. Oh wait, Pudge wouldn't have given a shit about that either. Carry on, then.

Re:Anyone got a summary of the summary? (3, Insightful)

DrSkwid (118965) | more than 3 years ago | (#34167376)

If you're not sophisticated enough to realise that a link to Amazon is going to have a referal perhaps it's time to hand in your badge and gun.

Re:Anyone got a summary of the summary? (1)

gstoddart (321705) | more than 3 years ago | (#34188730)

If you're not sophisticated enough to realise that a link to Amazon is going to have a referal perhaps it's time to hand in your badge and gun.

Wait ... we get guns?

Re:Anyone got a summary of the summary? (1)

blair1q (305137) | more than 3 years ago | (#34164980)

I could write one, but probably not while imparting as little information about the summary as the summary imparted about the book...

Where is the SDK? (1)

Burz (138833) | more than 3 years ago | (#34164312)

curious minds...

This justifies the Kindle (1)

dustin_0099 (877013) | more than 3 years ago | (#34164352)

Won't anybody think of the trees? My aching back trying to lug this around?

Maybe (0)

Anonymous Coward | more than 3 years ago | (#34164380)

Maybe he can tell us why the same data structure is defined in different ways in various headers supplied with the OS.

Re:Maybe (1)

Mikkeles (698461) | more than 3 years ago | (#34166328)

Because there's more than one way to do it!

Re:Maybe (1)

mr_mischief (456295) | more than 3 years ago | (#34169108)

No, that would explain why the same structures are defined different ways in the parser for Perl. ;-)

Fiddleheads (3, Insightful)

blair1q (305137) | more than 3 years ago | (#34164422)

Michael, what were you thinking?

He was thinking he's the only person writing man pages for Linux so why does anyone else need to know how to do that?

Just as long as (2, Insightful)

Rasputin (5106) | more than 3 years ago | (#34164442)

I don't have to use Info to read it I'll be happy...

Re:Just as long as (5, Insightful)

sconeu (64226) | more than 3 years ago | (#34164954)

Yeah. I hate info. Actually, what I hate are man pages that say "use info $APP for the man page".

Re:Just as long as (0)

Anonymous Coward | more than 3 years ago | (#34167198)

That's RMS for you. I'm surprised GNU-based systems don't say "Use emacs to edit $FILE" when you try to use vi....

Re:Sentence fragment as the (2, Insightful)

Tetsujin (103070) | more than 3 years ago | (#34168208)

That's RMS for you. I'm surprised GNU-based systems don't say "Use emacs to edit $FILE" when you try to use vi....

Well, there's actually a functional reason for info's existence. It's a hypertext system, it's got hyperlinks and table of contents and hierarchical organization for documents... This makes it much more useful for relatively large documentation than a man page would be.

But I never liked actually using the info reader, I never took the time to learn all its key bindings. These days I think HTML documentation is a much better choice... Man pages still do well in their own little niche - brief summary-style documentation with a consistent, convenient interface... But I don't think info has a valid niche any more.

Re:Sentence fragment as the (0)

Anonymous Coward | more than 3 years ago | (#34169858)

I don't think info ever had a valid niche to begin with... maybe as an add-on to man pages, but never as a replacement for them. "use info $APP for the man page" is a sad indictment to that poor design judgment.

Re:Sentence fragment as the (2, Insightful)

Tetsujin (103070) | more than 3 years ago | (#34170246)

I don't think info ever had a valid niche to begin with... maybe as an add-on to man pages, but never as a replacement for them. "use info $APP for the man page" is a sad indictment to that poor design judgment.

Oh, agreed. I hate those stub man pages. Especially when (due to some documentation package not being installed, no doubt) calling up the suggested info page just leads me straight back to the same stub man page, except in the info viewer instead of the man page viewer.

But my point about info was that it's actually more of a full-featured help system, and much better suited to presenting large amounts of information than man is, because it can organize and cross-reference it better. In the face of HTML it seems largely superfluous, so it loses out 'cause it's neither as convenient as man nor as fully-featured as HTML. But info first appeared... what, early 1980s? Late 70s? A help file browser with hypertext functionality was a pretty substantial merit at that point.

Re:Sentence fragment as the (1)

sentientbrendan (316150) | more than 3 years ago | (#34176544)

I use info all the time. It's very geared towards emacs programmers like me. The best info viewer is built into emacs, and it lets me read documentation without leaving emacs and opening up a web browser. In emacs: C-h i

The thing to remember about info pages if you are *not* an emacs user is that they generate html documentation. In fact, all the gnu html docs are actually generated from info docs. For example, the glibc manual mentioned in the review:

http://www.gnu.org/software/libc/manual/html_node/index.html [gnu.org]

So in a sense info is the best of both worlds in that it can be read from a web browser, or from a terminal based application like emacs, and it supports hyperlinks in both.

Re:Sentence fragment as the (0)

Anonymous Coward | more than 3 years ago | (#34170750)

Of course, info pages can be easily converted to HTML, and often are. Though I suspect the reason distributors don't get rid of the info reader and replace it with elinks and/or firefox is that the info reader's search function automatically searches over multiple files.

Re:Sentence fragment as the (0)

Anonymous Coward | more than 3 years ago | (#34177148)

Yes, info is great because of its hypertext properties, but the interface provided by the info command is one of the worst interfaces I've ever encountered. pinfo makes it usable because it provides an interface similar to lynx

Re:Just as long as (0)

Anonymous Coward | more than 3 years ago | (#34169248)

This is beside the point of your comment but I thought you'd benefit from knowing that I think it's main not man. LOL

Re:Just as long as (1)

Short Circuit (52384) | more than 3 years ago | (#34203892)

And then it happens you don't have the 'programname-doc' package installed, so 'info' loads up the man page.

Help! I'm stuck iterating through a self-referential linked-list!

Want to learn Unix/Linux core API? One name ... (1)

Viol8 (599362) | more than 3 years ago | (#34164766)

Stevens.

Sorry , but no other book comes close to Advanced Programming in the Unix Enviroment.

Re:Want to learn Unix/Linux core API? One name ... (0)

Anonymous Coward | more than 3 years ago | (#34164958)

True, Stevens is still the gold standard. However, since he died over a decade ago you're never going to get a description of newer APIs (epoll, dnotify, ...)

Re:Want to learn Unix/Linux core API? One name ... (1)

Viol8 (599362) | more than 3 years ago | (#34164982)

Stephen Rago updated it about 5 years back. I assume he will again when it needs it if they ask him.

Re:Want to learn Unix/Linux core API? One name ... (2, Informative)

jgrahn (181062) | more than 3 years ago | (#34166574)

True, Stevens is still the gold standard. However, since he died over a decade ago you're never going to get a description of newer APIs (epoll, dnotify, ...)

For epoll, it would be enough with a "see also: epoll(7)" in select(2). And now I see there *is* such a reference.

epoll is nice: one of the few Linux-specific system interfaces which is clearly better than the standard Unix counterpart (select/poll).

Re:Want to learn Unix/Linux core API? One name ... (1)

sentientbrendan (316150) | more than 3 years ago | (#34176634)

epoll is nice: one of the few Linux-specific system interfaces which is clearly better than the standard Unix counterpart (select/poll).

Not necessarily. epoll is better than select, definitely. However, see this article on how it compares to poll:

http://sheddingbikes.com/posts/1280829388.html [sheddingbikes.com]

The answer seems to be either poll or epoll can be better depending on the situation.

Re:Want to learn Unix/Linux core API? One name ... (1)

Profane MuthaFucka (574406) | more than 3 years ago | (#34166654)

I'm holding out for zombie Stevens

APUE: essential reading for absolutely everyone (2, Informative)

Tetsujin (103070) | more than 3 years ago | (#34164992)

Stevens.

Sorry , but no other book comes close to Advanced Programming in the Unix Enviroment.

You know, I was thinking more or less the same thing when I read this story. How can a review like this not make the obvious comparison with the glorious APUE? I love that book. I have to admit, I didn't even know you could pass file descriptors from one process to another before I read it... And its descriptions of job control, TTYs, process hierarchies and so on have been very valuable to me.

It seems like this book covers a lot of the same ground, though presumably without the same level of cross-platform coverage. Though I don't think APUE covered xattrs (can't remember offhand)... I had hoped that this book, being more Linux-specific, would cover more of the stuff that's more current and fairly specific to current Linux distros: FUSE, dbus, the current state and direction of kernel drivers for graphics and sound, any Linux-specific process jail or virtual machine mechanisms, and so on...

Still, I'd really like to browse through this book. If there's enough useful information that doesn't overlap APUE it might be worth getting. Maybe my local bookstore will get a copy sometime...

Other than manuals, there were 3.5 key Unix books (4, Insightful)

hey! (33014) | more than 3 years ago | (#34164888)

back in the day:

(1) The Unix Programming Environment (K&P)
(2) The C Programming Language (K&R)
(3) Software Tools (K&P)
(4) The Elements of Programming Style (K&P) [optional]

In those days, I was always amazed that so many people tried to program on Unix without having read these books forward and back. After you read those, all that was left was to read the manuals cover to cover, which took a few months but was worth doing. That was a good spare time activity back in the days when compiling and linking took a long, long time.

It's an entirely different kind of world today. I doubt many people know even the standard Java libraries as well as we knew Version 7 and System III of Unix, not only the details but the design philosophy as well.

Ralph Waldo Emerson, in his essay "Self-Reliance", claims that society does not progress; it simply changes. We gain some things but lose others. I suppose that depends on your definition of "progress"; I certainly wouldn't want to go back to those days. We have unquestionably gained, but we've lost something too as programmers, a sense of mastery and control over our destiny. So much of our time today is spent dealing with the fallibility of others, in wrestling with frameworks that are powerful but so complex they're inevitably full of excruciating design flaws. We don't think it extraordinary at all for a good fraction of our time on a project to be working around flaws in other layers of the solution.

Re:Other than manuals, there were 3.5 key Unix (2, Interesting)

Tyler Durden (136036) | more than 3 years ago | (#34165488)

What, no Advanced Programming in the UNIX Environment (Stevens)?

I know what you mean about the differences in programming between then and now. Then it was about learning a relatively small set of simple, fundamental tools and knowing how to build with them in creative ways. Now it's more about learning a bunch of complex, ever-changing, flavor-of-the-month frameworks. Demands memorizing trivia more than creativity really.

Re:Other than manuals, there were 3.5 key Unix (4, Funny)

hey! (33014) | more than 3 years ago | (#34165872)

People my age can't be expected to remember more than 3.5 things.

Re:Other than manuals, there were 3.5 key Unix boo (0)

Anonymous Coward | more than 3 years ago | (#34165730)

Thank you for this post, man. Sincerely.

Re:Other than manuals, there were 3.5 key Unix boo (1)

excelsior_gr (969383) | more than 3 years ago | (#34166800)

society does not progress; it simply changes. We gain some things but lose others.

And THAT is why documentation is so important. I agree fully with you, but I would like to add that if know-how is well documented, then we can always fall back to it in case of emergency or if we take a wrong turn. GPS is a nice example: very few people know how to navigate using the stars, but GPS enables anyone to steer a boat. However, the old method is still there, in the books.

Re:Other than [...], It beat DEC documentation (1)

Strange Attractor (18957) | more than 3 years ago | (#34182814)

Unix was so much easier to comprehend and had such nice tools compared to the DEC RSX OS and documentation that it replaced on PDP-11s. Just to know where to find something in the DEC documentation, you had to have read it before. I finally simply read all four feet of that stuff. (I think it was in orange 3 ring binders.)

Re:Other than manuals, there were 3.5 key Unix boo (1)

quarkscat (697644) | more than 3 years ago | (#34215246)

Yes, well thank goodness that FORTH is still dead, just like BSD, eh?

Usually ships in *2-6 months*?! (1)

Short Circuit (52384) | more than 3 years ago | (#34165016)

Quoth the Amazon page:

Usually ships within 2 to 6 months.
Ships from and sold by Amazon.com. Gift-wrap available.

Also, Slashdot's referral code is broken. I believe they now require the URL to be signed using a private key. "/ref=nosim/?tag=slashdot0c-20" is insufficient.

Re:Usually ships in *2-6 months*?! (2, Informative)

StuartHankins (1020819) | more than 3 years ago | (#34167022)

I went to Amazon earlier and found the same thing. I was pretty sure it was a typo since the book just came out in October 2010, so I clicked their "call me". An automated system called me, but in the process of transferring me to a rep it hung up on me. So I tried their "chat" feature. The rep took about 10 minutes and finally came back and said the same thing as the website, 2 to 6 months.

The publisher supposedly has the book in stock, as well as other stores such as ecampus.com, but it ranges from slightly more expensive to 33% more expensive ($100 vs $63 is a big difference to me).

Re:Usually ships in *2-6 months*?! (0)

Anonymous Coward | more than 3 years ago | (#34167410)

The publisher supposedly has the book in stock, as well as other stores such as ecampus.com, but it ranges from slightly more expensive to 33% more expensive ($100 vs $63 is a big difference to me).

Damn. I thought the whole "information wants to be free" ethic would apply here.

Re:Usually ships in *2-6 months*?! (1)

Tetsujin (103070) | more than 3 years ago | (#34168244)

The publisher supposedly has the book in stock, as well as other stores such as ecampus.com, but it ranges from slightly more expensive to 33% more expensive ($100 vs $63 is a big difference to me).

Damn. I thought the whole "information wants to be free" ethic would apply here.

As usual: that phrase does not mean what you think it means.

And $100 is over 50% more expensive (not 33% more expensive) than $63.

What was the book from Bell Labs? (2, Interesting)

Karl J. Smith (184) | more than 3 years ago | (#34168630)

What was the book that you didn't already have?

Re:What was the book from Bell Labs? (1)

Muad (11989) | more than 3 years ago | (#34181074)

A fairly obscure one... but you will have to ask me that in person and over a beer ;)

Not machine-readable? (1)

hendrikboom (1001110) | more than 3 years ago | (#34169272)

And it's not available in an easily indexable machine-readable form? Anything more than a thousand pages needs to be machine-readable to save on weight alone.

More info about the book (2, Informative)

mkerrisk (1937026) | more than 3 years ago | (#34170630)

For more information about the book, including a detailed table of contents, index, preface, and sample chapters, see my website for the book at http://man7.org/tlpi/ [man7.org] .

subject (-1)

Anonymous Coward | more than 3 years ago | (#34172024)

He's the main man man man!

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>