Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Programming Books Media Book Reviews IT Technology

Linux Core Kernel Commentary 56

Posted by timothy from the even-Alan-Cox-had-to-start-somewhere dept.
How would you dip your feet in the water, learning enough to start dabbling with kernel development? Scott Maxwell might end up as the guide for a fresh batch of aspiring programmers, with his Linux Core Kernel Commentary. Starting with a lesson on the history and philosophy behind free software, you can learn enough to start contributing on your own.

Linux Core Kernel Commentary
author Scott Maxwell
pages 575
publisher Coriolis Open Press
rating 9
reviewer chromatic
ISBN 1576104699
summary In the spirit of Lions' Commentary on Unix, Scott Maxwell takes readers on a tour of the basic architecture and workings of the Linux kernel.
The massive tome has nearly 40,000 lines of code from the x86/arch branches of the Linux kernel. That works out to two columns on each of over 400 pages. It's mostly free of annotations, except for small arrows referring to the commentary on that section. The commentary takes up the rest, at three columns per page. The architecture dependent functions target x86 code, and the core features (memory management, processes, scheduling, signals and threads, procfs) are covered.

*

What's to Like?

Most interesting for me was the "a-ha!" factor. The normal chapter flow describes the subsection in general terms (memory management is designed to do such and such, with these issues), moves to the important data structure, and then walks through the vital functions for that section, stopping here and there to explain peculiarities and subtleties of the code. There's rough going in a few spots, but there are occasional moments of insight where the solutions come in to clear focus. (This happened most often for me in the SMP chapter, as the discussion of locks is particularly good.)

Maxwell manages to avoid unexplained jargon for the most part, though he invents names for implied kernel idioms. Even while dealing with highly specific topics, readers won't need a background in OS design to understand the text. Good C skills will help, as well as assembly, though the latter is explained in greater detail than the former.

The author also takes pains to point out flaws and possible optimizations in the kernel, though he often concludes that the route taken is the best for various reasons. Another theme is the tradeoffs necessary between speed, clarity, compatibility and portability. Finally, as kernel 2.4 will be out shortly, Appendix B discusses the modifications in the 2.3 tree as it went to press.

What's to Consider?

As space is limited, Maxwell sometimes skips some interesting details -- especially in latter chapters. Unfortunately, phrases like "There's not room to cover this" or "that is out of the scope of this book" pop up now and then. I definitely wanted more.

Two other small nitpicks may be corrected in a future version. First, it would have been nice if the current filename was listed on each page of the source code listing, just for reference. Second, flipping back and forth between commentary and code was tricky, especially in a book of this size. Perhaps splitting things into two books would help? Serious students might find it easier to browse the code from the CD-ROM, which includes the code for kernel versions 0.01, 2.2.5, 2.2.10, 2.3.12, and the entire code of the first section, numbered as it appears.

The Summary

This could serve as a textbook in an OS design class. Supplemental material will be necessary (file systems not covered for example, nor are drivers). Perhaps paired with a more theoretical text, it could form the basis of an intermediate computer science class.

The utility is not limited to students, though. Anyone wondering where to start understanding the Linux kernel would do well to consider this book.

Buy this book at ThinkGeek.

Table of Contents

  1. Linux Core Kernel Code
  2. Linux Core Kernel Commentary
    1. Introduction to Linux
    2. A First Look at the Code
    3. Kernel Architecture Overview
    4. System Initialization
    5. System Calls
    6. Signals, Interrupts, and Time
    7. Processes and Threads
    8. Memory
    9. System V IPC
    10. Symmetric Multiprocessing (SMP)
    11. Tunable Kernel Parameters
  4. Appendices
    1. Linux 2.4
    2. GNU General Public License
This discussion has been archived. No new comments can be posted.

Linux Core Kernel Commentary More

Linux Core Kernel Commentary

Comments Filter:
  • that they sell the sourcecode to the Linux kernel in the bookstores? I saw that the other day, and was amazed.
  • Sorry to say this, but alhough a book like this is actually a good idea, the presentation seems a bit silly; why print over 40.000 lines of code, while at the same time they are included on CD (or in most people's Linux distribution for that matter). This looks like a massive waste of trees, a more interactive way would be an good initiative.
    How to make a sig
    without having an idea
  • I don't know how most people feel about computer books (and other books for that matter), but there is definately something very different about reading it in a book and on a computer screen. I, for one, seldom will look at a book and its included cd at the same time. that i believe is the answer to why print 40k lines of code. I like it when a book will present code examples and then go through them, I imagine that this is close to what the author and publisher thought.
  • because many people myself included find it much easier to read on paper than a monitor. Hopefully that nifty e-book/rocketbook stuff will eventually change that
  • I flipped through this book one day, and I must say that it seemed to be a pretty good reference. But I'm not sure if it's worth the money when there are good references online. Also, the book covers one version of the source code. As the kernel source is constantly evolving, it will only remain accurate for a short period of time. Plus, you lose the ability of quickly searching files that is available with most text editors.

  • Fight this blasphemy! (Score:1)

    by Anonymous Coward

    This is just the sort of thing that Linux doesn't need! The art of kernel hacking is one that truly marks you out as an 31337 h4X0r, and the very last thing that us gods want is for every pean with a c compiler to think that they are worthy of "contributing" to our wonderous edifice!

    In the name of Linus, I implore you to boycott this book, else the entire caste system of Linux h4X0r5 will come crumbling down. The future is in your hands.

  • I agree that reading from paper is easier, but I cannot imagine that every line of that 40K is commented on. Maybe this was a good opportunity to try a more interactive approach!
    How to make a sig
    without having an idea
  • So a book like this is a blessing.

    Though typing the kernel code in all by hand, so that I can compile the kernel and boot Linux on my CDless 486 is a bit of a bother.

    Let's see, I'm up to 137 lines, only 39863 to go!

    George
  • Is this book really a good place to start? I'm a novice C programmer, who hasn't really programmed anything since taking C and assembler for VAX/VMS in college back in '92.

    Perhaps this is covered in the historical section of the book, but one task I've thought about try is to re-invent the wheel and try to build a linux system from scratch with just the kernel. I've always been curious about how the development of an OS starts...I mean take a raw disk with no filesystem and your basic computer and how do you go about building an OS like linux? I would assume you need to understand the boot process and what it is that must be done when the machine boots.

    Over the passed couple of years I've worked with RS/6000s and I've found it quite interesting that IBM can boot any of their machines - Microchannel or PCI based - from an AIX install CD, but none of the PPC linux distros can seem to create a bootable CD Image. I'd really like to delve into the basics of the Kernel and how it boots a machine boots to help with the PPC folks in getting a bootable install image.

  • It's a good book... (Score:5)

    by ceswiedler ( 165311 ) <chris@swiedler.org> on Wednesday May 03, 2000 @05:06AM (#1095156)
    ...except for the shipping charges. I agree that the 37k lines of source may be a waste of trees, but it is easier to flip through a book sometimes.

    A good companion to this book is Advanced Programming in the Unix Environment. I found myself wondering exactly why some kernel routines were implemented the way they were, until I read up on them in APUE. It's important to understand the "user" interface to the kernel when you're reading this book.

    Knowledge of stuff like assembly language (GNU's version of course) and low-level stuff like IRQs/interrupts, memory segmentation, and device IO is important--like the review says, he doesn't go into those details. Higher-level stuff like scheduling, file-system calls, and IPC is dealt with very well.

  • Let's see, I'm up to 137 lines, only 39863 to go!

    You have chosen the true path, my friend. Only those who type in the entire program, like those of us Antic subscribers who did not own an Atari tape drive and therefore had to type in everything we wanted to run, can appreciate what a program truly does.

    May I suggest that you use EMACS rather than vi? That way, you can compile in a second window and watch for faults. On the other hand, you could always go the true 1337 route and use ed!

  • The commentary doesn't try to comment on every line, simply to give a feel for the areas it touches on. The rest of the code is really to offer the surrounding structure for people who want to investigate around the specific example given.

    The book is very good, but I think it would have been easier to navigate if they'd thrown in a half dozen ribbon bookmarks in the spine so that the commentary could be marked whilst looking at the actual code.

    As for interactive approaches, I would want to wait for something better than current displays.
  • then don't buy the book. look through your technical book collection, and count the number of scribbles. If your books are like mine there's probably a comment i wrote to myself every few pages. While yes, I could just comment the code, and keep it in a source tree, I can't do that while I'm sitting in a park, enjoying not being near a computer.
    ----------------------------
  • It's not about understanding the absolute latest kernel source. The book doesn't get rendered obsolete because we went from 2.2.12 to 2.2.15 or even to 2.4.0pre5000. It's a book for understanding the basics of how the kernel works, why things are structured as they are, and to learn about this design, thus making it so that you may be able to understand the latest version of the kernel.

    And those of us who know what in the kernel we want to quickly search a file for, in order to learn about Linux's memory management for example, have quite probably already read and understood the source code, so therefore have no use for the book anyway.
    ----------------------------
  • I studied under John Lions and used his commentary of the level six UNIX. He included 9600 lines of code and every single one of them had a commentary to go along with it. It also had a functional cross reference for jumping around the code. This book went back the next day. It's not useful for the majority of people.
  • You mean kfirstpostd? It's in 2.3.99pre147-3-2-almostready-ac32

    or maybe kslashdotd? It's a more general solution, but it won't be included until 2.4 is fully out, and the 2.5 tree starts.
  • I was going to buy this book, until I realized that it was priced based on the size of the book and not the original content within. I hear you.

    ---
    script-fu: hash bang slash bin bash
  • Truly elite programmers would just use:
    # cat > /boot/vmlinuz
    (type compressed object code here)
    ^D
    # lilo
    Added linux *
    # reboot
  • At my university, there are several professors that require this book for the advanced operating system design class.

    The class has been taught using linux since about version 1.something, before that it was MINIX I believe.

    All of the students that have taken that class, (and read this book) have been very pleased with it, but I've heard many times that you shouldn't even bother looking at it unless you feel fairly comfortable with your C.

  • I am wondering if this book is really necessary. Since Alan Cox [linux.org.uk] and other core kernel developers are working on commenting the kernel themselves I don't really see the usefulness of this book.

    Personally I would much rather learn how the kernel works from the actual kernel developers than anyone else. ( I don't know if Mr. Maxwell contributes to the kernel, but I have never heard of him.)

    If you want a paper version (which is sometimes better then a computer screen) just write a little script that recursively descends the kernel directory hierarchy and prints each *.h and *.c file.

  • Even if some of those "peans" are "Euro-peans"? Or did you mean "peons"?
  • May I suggest that you use EMACS rather than vi? That way, you can compile in a second window and watch for faults. On the other hand, you could always go the true 1337 route and use ed!

    Who is ed?

    vi, EMACS, what are those? I'm typing it in notepad, and plan to use QuickC to compile it.

    George
  • IMHO this is not the place to start. I don't know you, so I don't know how comfortable you are with C, but I don't think this is the book to polish your C with.

    Lots of people are familiar with C on one level, but not on others. Lots of people can write functions to do things like print to the screen, manipulate numbers, deal with dynamically allocated memory and such, but there are also other levels of C since it's so low level.

    For example, do you know how to do bit manipulation? Do you know the difference between & and &&, between | and ||, and between ! and ^? I haven't looked into the kernel source too much, but if you don't know how to do that stuff, you may not enjoy the book. Also, there are other "conventions" in C that it helps to be familiar with, that don't make any sense until you get some experience under your belt. (Example there would be in C some functions rather than taking 20 boolean arguments, take 1 argument that is just a bunch of packed bits, and then checks that argument to see if a particular bit is set instead of taking an argument in that spot - X11 does this a lot, and when I first saw it, I thought it was pretty stupid. (Turns out its not)

    I think in order to bone up on C again it probably wouldn't be a bad idea to first read some generic source code to something easy until you understand it all, and then tackle the kernel instead of starting back into C with kernel code.

    I've also heard that certain parts of the kernel are extremely cryptic because they've been hand-optimized for speed, but I don't know how true that is. (It would make sense though) in cases like that, it may be difficult even for people who know C really well to grok that code.

  • I haven't read this book yet, although the review makes me want to pick up a copy.

    OTOH, if you're not familiar with how operating systems work, I think you'd do better to start with John Lions's Lions' Commentary on Unix: With Source Code, (Peer to Peer Communications 1996), ISBN 1573980137.

    This book, usually called "The Lions Book," has the full source code for an early version of Unix, followed by Professor Lions's annotations. The source and commentary are comparatively short (about 300 pages, compared to 400 pages for the Linux source alone), largely because the kernel it describes is a good deal smaller than the current linux kernel. This means it's also a lot simpler than the linux kernel.

    If you're already comfortable with reading complex sources, and you know a lot about operating systems, then give Maxwell's book a try. But I suspect a lot of people would be overwhelmed by it, and the Lions Book is a better place for them to start.

  • I don't understand why you feel like you have to type in all the code instead of just upgrading your machine with a new peripheral?

    Obviously, you could save lots of typing time by installing a flatbed scanner and some simple OCR software. Scan in the pages. The compiler should catch most OCR errors.

    Technology is about making things easy, right? Heck, I bet you can find other uses for that scanner, too.
  • Ha!
    Your comment gave me a laugh. I'm hoping that you were just sticking that out there for flame bait.

    If not, vi, ed, emacs all in the editor family of application. vi is a favorite of many folks I know.

    As for the QuickC compile, you'd probably do better to download one of the free distros of gcc out on the net. I'm sure many folks could point out their favorites.

    Tojo
  • Truly elite programmers would write a Linus simulator, feed it parameters corresponding to Finland in 1990, and let it start coding.

  • Bah! I'm inscribing it on punch cards. Cards rock!

  • It's a book for understanding the basics of how the kernel works, why things are structured as they are, and to learn about this design, thus making it so that you may be able to understand the latest version of the kernel.

    _VERY_ good point. It seems to be about learning the CONCEPTS of kernel development that apply to Linux.

    When a new version of GCC gets released, you don't need to re-learn to code, do you?

    It's these concepts that can be used to further the development of future innovative (sorry to use that word) projects. Same as, if you already know 5 programming languages, it's not THAT hard to pick up a sixth, quickly.
  • Notice that the User has a period in the front.

    Hal Duston
    hald@sound.net
    Boring is good. A conformist in a nonconformist world
  • "Plus, you lose the ability of quickly searching files that is available with most text editors."

    Well, maybe, maybe not. The book comes with a CD that has (among other things) all the text from the book, along with line numbers. There's also a nice little emacs script to search the text...

  • Lousy formatting kills the effect (Score:3)

    by Mechanist ( 10536 ) on Wednesday May 03, 2000 @08:22AM (#1095179)
    Or so I expect. I don't have this book, but I do have "Apache Server Commentary", from the same series, which uses the same layout as this book.

    While the commentary might be good, the book's half-assed ripoff of the format of the old Lions commentary kills the usefulness of the book:

    • Dividing the source code from the commentary makes for an awkward experience, since you must constantly flip back and forth to get any sense of what's going on.
    • Despite the book's gargantuan size, it's not even close to complete. The main portion of the Apache source contained 17 source files when this book was written-- but only 3 are covered in the book.
    • The commentary often goes hundreds of lines without a hint as to what's going on
    • There's no cross-reference, and the index is useless. Meaning that if you want to find out about a specific function-- say, you saw a call to it, and want to see its code-- there's no easy way to find it.


    I always thought that Lions' commentary used that format due to AT&T licensing restrictions on the source code, or some other AT&T policy. But Coriolis had no such excuse in writing these books. With open source projects, this layout stinks.

    On the whole the book was only marginally more convenient than printing my own copy of the source code. I would not recommend it. Better to get cscope (free now!) and a different reference. [For Apache, try O'Reilly's "Writing Apache Modules", with decent API docs.]

  • Truly elite programmers would just use:

    # cat > /boot/vmlinuz
    (type compressed object code here)
    ^D
    # lilo
    Added linux *
    # reboot

    Nah. The above only works for a kernel upgrade (how else could you be using cat?).

    And two other points:

    1. the truly elite would never use cat; they'd use dd.
    2. lilo??? Only a wimp would issue a lilo command. Everyone who's anyone at all uses:

      dd of=/dev/hda

      to modify their boot sectors.

    Geez. These commercial Linux distibutions are making it just too darned easy.

    --

  • "The Linux Kernel": excellent and free (Score:3)

    by AxelBoldt ( 1490 ) on Wednesday May 03, 2000 @09:48AM (#1095181) Homepage
    Linux is free and so is its documentation. If you want to understand the basic algorithms and data structures of the Linux kernel, start with David A Rusling's excellent free book "The Linux Kernel" [linuxdoc.org], put out by the Linux Documentation Project.

    --

  • While I agree with both of these comments, from what I read of this book, I don't think this would be the way I would want to learn these concepts. A good book covering generalized OS concepts can be purchased for a little more. A book such as Operating Systems Concepts by Abraham Silberschatz and Peter Baer Galvin teaches them in more depth, and uses examples taken from a variety of OSes (ie. Linux, BSD, Windows NT). One could easily review the source code for Linux (or one of the BSDes) while reading to help understand the actual code. My impression of Linux Core Kernel Commentary was that it was a step-by-step explanation of code. I could see how this could be helpful under certain circumstances, but not in understanding general OS concepts. If the reader does not understand the general concepts, they are less likely to be able to adapt to changes. Also, using the argument that learning one version of the kernel will make a person understand all following versions is an even stronger argument for the online guides. Most of these guides are based on 2.0, but they fulfill a similar role to this book.
  • A good companion to this book is Advanced Programming in the Unix Environment.

    You might be interested to know that the author of that book recently passed away (Sept 1, 1999). Which is a damn shame in my opionion. I have his book "UNIX network programming - volume 1" which is probably the best textbook I have ever had. Very well written and terribly useful. He also wrote TCP/IP illustrated volume 1,2,& 3. Which are supposed to be fairly definitive references for TCP/IP.

  • ... where I hung out, there were these nice shiny new m68k Sun whelkstations -- someone lusted after the then new 386-based Roadrunners, but we'll forget him -- and there was a persistent rumour that one amongst us, his identity a dark secret, could hack his way to root status in under 90sec starting from % in a vanilla account.

    It is also true that among us was one Alan Cox, an Amiga aficionado, who liked its OS, and used to do stuff to it so he could make the sound ASICs perform, as he put it, "chickens in minor sevenths". And Amigas were m68k-based.

    I suspect that having the source code to look at, commented or not, is not enough for most of us, and having a fat commentary to advise us what we should be looking at, and whereabouts, will be a great boon to newbie kernelistas.

    After all, I was an Atari ST aficionado, and they were m68k based, yet I never quite managed to perform an illegal su. The likes of Cox seem to be special, but let's not let that stop us from aspiring to bug-free kernels of our very own.


  • The whole thing reminded me on that linux-source-navigator [unc.edu] I found on the web.

    But it didn't get changed since 1996 it seems.
    Something like that would be very useful,
    with some more basic theory explained.

    -- chrisse


  • I found Andy Tanenbaum's Operating System Design and Implementation useful for learning the basics. It describes things in a Minix context (as he wrote Minix for a practical example) and has a strong microkernel bias, but it is an effective presentation of the important concepts.

    Someone else mentioned the dinosaur book -- I think it's Operating System Concepts -- with case studies of NT and Linux 2.0. That's also good.

    When I mentioned that LCKC could be a college text, I had the aforementioned books in mind as possible companions.

    --

  • I think you've just coded youself an infinite loop. Anyway, my first program ever was copied from a book using Apple IIe BASIC :). I remember being so suprised upon seeing the output.

    -EJ
  • Yes, EDLIN is still supplied with Windows 2000 Professional :-)

    The more things change, the more they stay the same ...

    Zed
  • I'm running a clean install of Win2K (don't worry, I'm not totally hopeless, I dualboot slackware), and YES! EDLIN still comes with it. I couldn't believe it.
  • Another excellent reference to learn about Operating Systems in general is Tannenbaum's 'Modern Operating Systems'. It's a well written text which covers operating system concepts thoroughly without making things unneccessarily complex.

    In my initial comment I had assumed that anybody who would attempt to work on the kernel would have already made themselves familiar with general operating concepts through a book such as the ones mentioned by each of us. I'm not familiar with the text you suggested, however.
    ----------------------------
  • I'm familiar with OS basics, and have even written a couple of executives for embedded systems. Right now I'm in the middle of my first project actually working on the Linux kernel.

    I tried reading through the source code, there are a lot of things that while obvious once you know what they are, aren't documented in an obvious place in the source code. The kernel does need better documentation. I would love to have time to go through and add manpage style headers to at least the important functions. Headers that detail the gozintas and gozoutas, as well as what the function basically does.

    In the meantime I've used several books to help figure out what was going on. Each one has various strengths and weaknesses. This one is good for the functions that are actually documented in this book. The separated code and comments make it a nuisance to flip back and forth, but it does make the code more readable. It also makes the footnoting a little more versatile. Unfortunately for me, some of the areas that I needed the most help on were new to 2.2 and this book documents the 2.0 kernel.

    Rubini's book on Linux Device Drivers is excellent. It is a "must have".

    Coriolis also publishes the Linux Programming White Papers which collects several Open Source documents in one handy deadtree collection. Being a big fan of documentation that I can leaf through, I've found it quite usefull.

    The Linux Kernel Book by Card, Dumas, and Mevel has good documentation on all of the various structs in the Kernel. It is also a decent high level overview.

    I did not get the Wrox book on Beginnin Linux programming, so I can't accurately comment on it's usefullness.
  • Thinkgeek selling the books slashdot is featuring just doesn't feel right to me. It's a great idea, but, I guess anytime people I trust (like slashdot) have multiple reasons for helping me (even if it is just by providing information) it bothers me.

    Slashdot's authors, even before they started working for Andover, made it completely apparent they were looking for sponsers, and monetary support. Just because they make a blatant promotion on thier site for ThinkGeek doesn't mean they aren't to be trusted, that's how this site stays up dude.

    No offense but if you are looking for a completely non-promotional news site, you've come to the wrong place.
  • Sorry. :-)
    --
    -Rich (OS/2, Linux, BeOS, Mac, NT, Win95, Solaris, FreeBSD, and OS2200 user in Bloomington MN)
  • wow. Okay, YOU win ;)
  • such is the reason for WordPad... lame and MS, but if one insists on a win text editor, this one at least has the large file support without the st00pid overhead and formatting of full on Word
  • I've seen a lot of complaints like a) the source is printed in it, and I already run that on my Java keychain b) it doesn't cover XYZZY module (for instance, the file system) or c) it's out of date. These are all valid assessments, but I think there is another target audience this book suits perfectly.

    This is the ideal book for someone who's studied operating systems in school but has never seen real source code. This seems to be the case for most folks I see that are new holders of a B.S. (or sometimes M.S.).

    Theoretical descriptions in texts frequently skip the messy parts (otherwise, they might as well print the source code!). Once you've seen an example of how it's done with a few helpful annotations, you're better able to deal with other systems that are implemented differently.

    I've seen a lot of online kernel documentation, but there isn't any of it that I'd point a new team member at in preference to this book, unless the thirty bucks was an issue. On the other hand, if said new team member is already a BSD kernel hacker, there will be much less benefit to reading it.

    I did find a few clangers while I was browsing through it. For example, the author seems to think that the top half of a driver is the same as the hardware interrupt handler. Even so, it's a lot better than Inside Windows NT 2nd Edition, and several of the Linux kernel books I've read.

  • Actually, this is what I'm doing right now, finishing up "Operating Systems Design and Implementation" after finishing the dino book (I find it funny that tanebaum critisizes the dino cover...). And I have found it to be an _extremely_ good way to get a footing in the way operating systems work. However, heavily theoretical and squeaky clean code is not going to help in reality. If you're going to do any real work in OS dev, you're going to see a lot of wierd crap, and getting your hands dirty with this book seemed to me to be a good idea. Oh well.
  • There was alot of random discussion on this exact point in the last few weeks on the kernel dev list. I'm not much of a kernel hacker, but it's good to check up on at least. Here are a few of the links -
    www.samba.org/~netfilter/kernel-hacking-HOWTO/ke rnel-hacking-HOWTO.html
    humbolt.geo.uu.nl/Linux-MM/kernel-links.html
    http://linux-mag.com/depts/gear.html
    http://kt.linuxcare.com/
    http://www.atnf.csiro.au/~rgooch/linux/docs/port ing-to-2.2.html
    http://www.tux.org/lkml/
    http://www.atnf.csiro.au/~rgooch/linux/docs/port ing-to-2.3.html
    http://www.atnf.csiro.au/~rgooch/linux/docs/inde x.html
    http://www.surriel.com/kernelnewbies.shtml
    http://jungla.dit.upm.es/~jmseyas/linux/kernel/h ackers-docs.html
    http://members.aa.net/~swear/pedia/kernel.html
    http://plg.uwaterloo.ca/~itbowman/CS746G/a1/
    http://linuxdoc.org/LDP/tlk/tlk.html
    and others too... I felt the same way until I started looking around.
  • Wow, a book I wrote got reviewed on Slashdot! What's the Slashdot purity test say about that?

    Y'all might be interested in LCKC's home page [scottmaxwell.org], which includes links to other reviews, an errata list, and an improved index donated by a generous reader. You can also email me [mailto] about the book.

    --

  • dd? vi? emacs? what kind of 'leet hacker uses userland tools?

    Plain old magnet for me, although dragging inodes manually around a hard disk after a few cups of coffee can be tricky, quite hard to keep your hand steady :)

  • I don't remember Alan being special, but he was certainly different.

    I remember one dark evening in the Junior Common Room at Swansea University (later, JC's) supping beer and discussing the merits of C file locking in developing a MUD for Pyramid.

    When he spoke about the language, he really knew what he was talking about. Alan filled me with a passion for C, although I doubt he knows it.

    Cheers Alan...

  • I agree on the one hand, but having flipped through this book and read through some sections of someone else's, I can see the merit of it. While laptops and other "e-reading" devices are becoming more and more ubiquitous, books are still very portable and less prone to power issues.

    I personally like to read techie stuff away from the office/home sometimes. It allows me to approach it with a clear head.

    Besides, you ever try to annotate a CD... brings its lifespan way down due to all the scratches and ink. = )

Slashdot Top Deals

To be awake is to be alive. -- Henry David Thoreau, in "Walden"

Close