Slashdot Mirror

← Back to Stories (view on slashdot.org)

Linux System Programming

Posted by samzenpus on from the read-all-about-it dept.

Jon Mitchell writes "As a Perl programmer recently thrown in to the world of C development on Linux, I have been looking for something that would take my K&R level of experience and bring it up to date with modern methods, hopefully letting me write more efficient and reliable programs. Linux System Programming is a volume that targets this need. Robert Love, former "Chief Architect, Linux Desktop" at Novell, kernel hacker of many years, and Gnome developer of well known features such as Beagle and NetworkManager, attempts in this book to document the Linux system call and C API to common systems programming tasks. Given that he developed the pre-emptive kernel and inotify he has the knowledge." Read below for the rest of Jon's review. Linux System Programming author Robert Love pages 388 publisher O'Reilly Media rating 8/10 reviewer Jon Mitchell ISBN 9780596009588 summary The Linux system call and C API explored in depth. Getting this book out of the box, I had wrongly been expecting a cookbook style that I would get instant gratification from. Although structured around common programming tasks, it doesn't lend itself to just dipping in. The section on time lists a handful of ways that "time" is available to the programmer; jump into the middle of the section and you might miss the most suitable one for the job in hand. The book rewards reading it in larger chunks.

This doesn't mean it is necessary to read it from cover to cover. Logically organized into chapters around "things you want to do", such as file access, memory management and process management it will lead you in with a survey of techniques you might be familiar with, before drilling down with advanced methods.

Knowing advanced methods for performance is great, but not at all costs. One of the most useful and practical lessons this book gives is to encourage you to think about error conditions that may occur during a system call. Early on, in the section on reading files, a detailed example is given on reading from a file. Every possible case of return code from the read call is described together with what it means and how you should handle it — it can be surprising that 7 possible outcomes are listed, with good descriptions of what to do with each of them.

This good practice by example continues throughout the book. Every system call described also lists the errors that may occur. This does show up a slight weakness: many system calls share a common set of errors which are repeated many times in the text. If you are not paying attention it may feel like you are just flipping through man pages. However you are soon halted by the easy introduction of an advanced concept to get your teeth into.

These are done in a nicely graded level for each topic. In "file access" to give an example, you are lead from simple read/write calls, through to what the C library can provide in buffering, to improved performance using mmap. The techniques continue with descriptions of I/O schedulers and how the kernel will order hardware disk access, scatter/gather, and ends up with how it is possible to order block reads/writes yourself bypassing any scheduler.

You are hardly aware of the progression, as the pacing is very well done. New concepts clearly fit into what you have seen so far — current sections signpost the practical use of what is being explained and at what cost, allowing clear consideration of the use of advanced features against any consequences.

For process management discussion starts with fork and exec, before moving onto user ids and groups, covers daemonification and goes onto process scheduling, including real time scheduling. Throughout the book each new call is illustrated with a short code snippet showing the call being used in a practical situation.

Not everything is present and correct. The author immediately states that networking is not covered at all. This is a shame as this subject would benefit from the depth of coverage given to the topics in this book — although no doubt would increase the number of pages considerably. Perhaps scope for a second volume. The length of some sections seems odd — Asynchronous file I/O is whizzed through in a page with no code example, whereas I/O schedulers gets a luxurious 12.

On the other hand there are some unexpected and useful extras, such as a discussion in the appendix of gcc C language extensions and how they might be used to fine tune your code.

The books stated target is for modern Linux development, a 2.6.22 kernel, gcc 4.2 and glibc 2.5. Many calls have been standardized by POSIX, and where this is so it are noted in the text, so a large portion of the content is useful on other systems. There is even the occasional mention of non-Linux system calls, the use of which is not encouraged, but shown so you know how they function if you come across them in older code.

I recommend this book to anyone who has a need to developing Linux applications. The book is not a primer in C on Unix, so you are expected to be familiar at least to the level of K&R. From this level though the journey into getting the best from the kernel and C library into your programs is easy going and enjoyable.

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

98 comments

  1. What about a C++ coder? by Dareth · · Score: 2, Interesting

    I to..err... know this poor bastard who took all his compsci courses in C++. How hard would it be for a C++ coder to dig into this book?

    --

    I only look human.
    My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
    1. Re:What about a C++ coder? by morgan_greywolf · · Score: 2, Funny

      Bah. C++. Go talk to the KDE people. ;)

      --
      My blog
    2. Re:What about a C++ coder? by Chandon+Seldon · · Score: 4, Funny

      How hard would it be for a C++ coder to dig into this book?

      Should be pretty easy. All the code examples are valid C++. All you need to do is remember that "class" is called "struct" and that you have to mangle your own names.

      --
      -- The act of censorship is always worse than whatever is being censored. Always.
    3. Re:What about a C++ coder? by MightyMartian · · Score: 1

      Easy, just -- some of your knowledge.

      --
      The world's burning. Moped Jesus spotted on I50. Details at 11.
    4. Re:What about a C++ coder? by fm6 · · Score: 2, Insightful

      OK, maybe I'm just showing my age, since I learned C++ when it was still considered to be a kind of preprocessor for C. But I find it very hard to understand how you can be an effective C programmer without knowing K&R-level C and how C++'s object architecture is built on C fundamental data types. C++ is a notoriously complex language, full of gotchas. These are hard enough to avoid even if you happen to know that (for example) that a C "string" is not a fundamental data type, though syntactically it looks like one.

    5. Re:What about a C++ coder? by blitzkrieg3 · · Score: 2, Informative

      Though I haven't read the book, I think it is safe to say that you should familiarize yourself with C a little better before reading this. You should pick up K&R, or at the very least familiarize yourself with the way common data structures look in C.

      Having said that, if you have no problems understanding man pages for system calls, you should be good to go.

    6. Re:What about a C++ coder? by zakeria · · Score: 1

      and do a lot more casting!

    7. Re:What about a C++ coder? by Peaker · · Score: 4, Informative

      How hard would it be for a C++ coder to dig into this book?

      Should be pretty easy. All the code examples are valid C++. All you need to do is remember that "class" is called "struct" and that you have to mangle your own names.

      C++ is not a superset of C, and is definitely not supposed to be written like C.

      For example variable-length arrays (added by C99) are not supported by C++ (which has vector objects instead).
    8. Re:What about a C++ coder? by Chandon+Seldon · · Score: 4, Informative

      C++ is not a superset of C, and is definitely not supposed to be written like C.

      C++ is damn close to being a superset of C. Any C code examples given in this book are almost sure to be valid C++. Further, the fact that C code makes for awkward and ugly C++ code doesn't mean that it isn't *valid* C++ code.

      C and C++ are very different languages in programming style, but anyone who knows C++ already knows the C syntax and semantics - at most they'll need to learn the modern C programming style to actually use it.

      --
      -- The act of censorship is always worse than whatever is being censored. Always.
    9. Re:What about a C++ coder? by Anonymous Coward · · Score: 2, Insightful

      Error handling in C is considerably different than the "right" way to do it in C++ (namely, with exceptions). You've been driving an automatic; now you'd be driving a manual --- but with real gauges instead of idiot lights.

    10. Re:What about a C++ coder? by I+Like+Pudding · · Score: 2, Funny

      How hard would it be for a C++ coder to dig into this book?

      Should be pretty easy. All the code examples are valid C++. All you need to do is remember that "class" is called "struct" and that you have to mangle your own names.

      I'm perfectly fine with you using C++ to shoot yourself in the foot, but don't you dare draw a bead on his.
    11. Re:What about a C++ coder? by Anonymous Coward · · Score: 0

      who cares!!!! there is a HUGE PROBLEM with negroes not being able to get jobs making computer games cause the white man kept them down for so long cause we all crackers is oppressin the dark man.

      Then again why would they want to design computer games, unless you are able to bust a cap in yo` bosses ass for dissin yer homies.

      MALT LICK-HER FTW

    12. Re:What about a C++ coder? by Bluesman · · Score: 1

      I think you made a mistake in your post. Here's the correct syntax:

      for (i = 0; i < 42; i++)
      {
          cerr >> "know this poor bastard who took all his compsci courses in C++." >> endl;
      }


      --
      If moderation could change anything, it would be illegal.
    13. Re:What about a C++ coder? by Anonymous Coward · · Score: 0

      I am having a hard time believing that so many people are having so many issues with C and C++ programming. I'm hoping that means the majority of you were business major not computer science majors in college.

      Or is this a sign of just how bad computer science programs have been watered down?

    14. Re:What about a C++ coder? by Anonymous Coward · · Score: 0

      You're trying to input from cerr into a const char*. You lose.

    15. Re:What about a C++ coder? by Bluesman · · Score: 2, Funny

      What you don't realize is that I overloaded the input operator earlier in the program, so it's not doing what you think.

      You lose too.

      See? When you use C++, everyone loses!

      --
      If moderation could change anything, it would be illegal.
    16. Re:What about a C++ coder? by Evil+Pete · · Score: 3, Informative

      C++ was originally a superset of C. But later changes to C / C++ have drifted considerably from that. However, that means that generally C shouldn't be a problem for C++ programmers. There are large differences in the philosophy though that will affect the quality of your C code.

      --
      Bitter and proud of it.
    17. Re:What about a C++ coder? by Daniel+Phillips · · Score: 1

      For example variable-length arrays (added by C99) are not supported by C++ (which has vector objects instead). Vector objects are not a replacement for C99 variable length arrays. In the test application I wrote I found them to be quite expensive, to the point where the relatively trivial bookkeeping I had them doing was eating as much time as the (many) syscalls. C99 VLA's on the other hand seem to generate impressively efficient code (gcc, which is traditionally not noted for its great code generator). A rather natural extension involving no new syntax, just allowing a dynamic expression for the array dimension where a constant expression used to be required. C++ should add VLA's, and while I'm making my asks, let's finally have designated initializers in C++ please, this is a serious language deficiency as it stands. As I understand it, the only obstacle is sorting out the object initialization/destruction order, as if "in the order writen" would not do. Feh.

      C++ language overseers should take the job of keeping up with good improvements from the C side more seriously. NIH?
      --
      Have you got your LWN subscription yet?
    18. Re:What about a C++ coder? by Curien · · Score: 2, Informative

      C++ was never a superset of C, and it was never intended to be such. Trivially,

      int main(void) {
          int class = 0;
          return 0;
          }

      was never a valid C++ or Cfront program, but it has always been (and probably will always be) a valid C program.

      I'm not an expert on Cfront, but I do know that there are quite a few major differences between C and ARM C++ (sizeof character literals, meaning of empty argument list, type conversions), so your characterization of C++ as having diverged from a superset of C recently is off the mark.

      --
      It's always a long day... 86400 doesn't fit into a short.
    19. Re:What about a C++ coder? by Pseudonym · · Score: 1

      So many errors, so little code...

      1. You didn't declare i.
      2. You post-incremented i instead of pre-incrementing it. (Because i isn't declared, I don't know if it's a basic type or an iterator. If it's an iterator, pre-incrementing is more efficient.)
      3. You right-shifted instead of left-shifting.
      4. You used endl on cerr, which is redundant and inefficient. (Standard error has auto-flushing on newline, and endl is almost never what you want.)
      --
      sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
    20. Re:What about a C++ coder? by Kymermosst · · Score: 1
      No, when you use C++ to shoot yourself in the foot:

      You accidently create a dozen instances of yourself and shoot them all in the foot. Providing emergency medical care is impossible since you can't tell which are bitwise copies and which are just pointing at others and saying, "that's me, over there."


      http://www.fullduplex.org/humor/2006/10/how-to-shoot-yourself-in-the-foot-in-any-programming-language/
      --
      "Alcohol, Tobacco, Firearms, and Explosives" should be a convenience store, not a government agency.
    21. Re:What about a C++ coder? by Curien · · Score: 2, Informative

      Both of those features were added to C after C++ was standardized. In particular, C99 VLAs were invented after C++ vectors (which were mostly solidified as part of the STL by the time of the C95 library update). As for your comparison, it would be interesting to know the specifics of your measurements (code, etc).

      The current C++ folks are more interested in fixing the mess they made with templates. Designated initializers would be mostly unnecessary if the language supported named argument mapping a la Ada and ColdFusion. I believe the general feeling is that C++ doesn't need more support for PODs.

      --
      It's always a long day... 86400 doesn't fit into a short.
    22. Re:What about a C++ coder? by Raenex · · Score: 1

      C++ was never a superset of C, and it was never intended to be such. Just to clarify, though, that it was intended to be largely compatible:
      http://www.research.att.com/~bs/bs_faq.html#C-is-subset
    23. Re:What about a C++ coder? by Evil+Pete · · Score: 3, Informative

      I didn't say 'recently'. I remember it was stated that C++ WAS a superset. Though it was probably moer accurate to say a superset of ANSI C. In fact there were early C++ compilers that actually preprocessed the C++ code into C first. Of course I am talking 15-20 years ago.

      So I stick to my remarks.

      Bloody young whippersnappers.

      A comment that follows has a link to Stroustrop's page about this. Yes it is not a mathematical superset. But it is practically one:

      Thus, C++ is as much a superset of ANSI C as ANSI C is a superset of K&R C and much as ISO C++ is a superset of C++ as it existed in 1985.

      Well written C tends to be legal C++ also. For example, every example in Kernighan & Ritchie: "The C Programming Language (2nd Edition)" is also a C++ program.


      --
      Bitter and proud of it.
  2. What I like about it. by bytesex · · Score: 4, Interesting

    I like UNIX systems programming when it's complete; even when that surprises me. Recently, for example, I had to find a way to know how many processes had open file descriptors to a certain file. You know, the old shared database thing; so that I can make sure that I'm the only one in at a certain point (inside a file lock), to do some checks an'all. To no avail; UNIX basically said: 'if you can't do it with file locks, don't bother'. Then I discovered the good old sys/ipc.h and the associated sys/sem.h and sys/shm.h. Turns out that my issue *has* been thought about, and in a good way too. Sure, the APIs aren't all 'modern' feeling; lots of things are done with extremely short function-names, ellipsis and setting bits inside special structs, but it works. And it's fast too.

    Now if they only had a good standard API to a versioned, networked filesystem. Then I would be in heaven. But a guy can dream...

    --
    Religion is what happens when nature strikes and groupthink goes wrong.
    1. Re:What I like about it. by morgan_greywolf · · Score: 3, Funny

      Now if they only had a good standard API to a versioned, networked filesystem. Then I would be in heaven. But a guy can dream...
      If you want VMS, you know where to find it. ;)
      --
      My blog
    2. Re:What I like about it. by bytesex · · Score: 1

      I think you and I both know that that's not exactly what I had in mind ;-) And even if I don't get it on API level, such a thing could still be a standard UNIX subsystem. But it isn't. The farthest we got was NFS. And that's a joke. Well, it's a very useful joke in certain circumstances, but still, you wouldn't build your scaled database on top of it.

      --
      Religion is what happens when nature strikes and groupthink goes wrong.
    3. Re:What I like about it. by debatem1 · · Score: 1

      PVFS http://www.pvfs.org/

    4. Re:What I like about it. by tinkertim · · Score: 1

      Now if they only had a good standard API to a versioned, networked filesystem. Then I would be in heaven. But a guy can dream...


      Try ext3cow and NFS.
    5. Re:What I like about it. by mehemiah · · Score: 1

      webdavfs

  3. All accessible from Perl! by Anonymous Coward · · Score: 1, Informative

    On most UNIX systems, the POSIX API is fully available to Perl scripts. One of the great things about Perl is that you get all sorts of high level features that aren't available in C, but then you also get all of the low level features that you often need when writing hardcore UNIX software. Best of all, Perl is damn fast, usually on par with C for most tasks. And it's often a lot faster when doing regular expressions work, for instance.

    1. Re:All accessible from Perl! by moderatorrater · · Score: 3, Insightful

      Best of all, Perl is damn fast, usually on par with C for most tasks Any way you could back that up with some numbers? I don't mean to say that you're wrong, but I'm skeptical about any claim that says an interpreted language can beat a compiled one. I would even be surprised if compiled perl could beat compiled C since C's been worked on so much longer and compiling perl into a binary isn't really its focus anyway.
    2. Re:All accessible from Perl! by smcdow · · Score: 1

      ... interpreted language ... Ahem. When did perl beomce an interpreted language?

      --
      In the course of every project, it will become necessary to shoot the scientists and begin production.
    3. Re:All accessible from Perl! by mr_mischief · · Score: 3, Informative

      Perl is compiled into an AST, goes through code improvements, and then is executed.

      Since it typically goes through this every time you use a program from the command line, the startup time tends to be pretty heavy.

      If you're using something like mod_perl or FastCGI or some other caching dispatch mechanism, your program gets dispatched without recompilation if it hasn't been changed.

      If your program is long-running, then the startup cost can become negligible.

      Perl's common routines are written in optimized C and with good algorithmic design in mind. If someone writes an equivalent from scratch in C instead of using a good library, then the Perl version will have been designed and refined by far more people.

      It's true that in many cases C comes out well faster than Perl, but those cases are not as common as people tend to think.

    4. Re:All accessible from Perl! by Anonymous Coward · · Score: 0

      *Ahem*

      http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=gcc&lang2=perl

      Perl is only fast when it is used to glue components written in C together. Try to implement something actually CPU intensive in actual perl and it will be much, much slower than any C implementation.

      Note, this is not to bash perl, i love it and use it almost every day, but it is by no means a speed devil.

      Even java 6 beats perl most of the time:

      http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=java&lang2=perl

      But at a serious memory cost.

    5. Re:All accessible from Perl! by pimpimpim · · Score: 2, Insightful
      If you're going towards purely number crunching applications, perl will actually end up being a lot slower, think of a factor 100. I noticed this with some programs that run for at least a day, so the startup won't be much of a difference there. Searching the net for benchmarks, I found similar ratios for simple addition calculations. More important than the algorithm optimization: Perl takes the memory allocation out of your hands, which is extremely good for stable programs, but the peformance price is immense. If I remember well, Perl 6 will have the ability to have variables of predefined size, exactly for that reason. Still I'm not sure if I would want that, the dynamic allocation was there for a reason!

      Still I use perl for my numerical calculations. There is a nice data language for matrix operations: PDL, which might be able to compete with matlab speeds. And my main reason to use perl: the short time needed to get a perl program that can reformat your input data in a nice way is without comparison. The same counts for adapting your program to a changed data format, added variables, etc. String handling and memory handling in C is a big big pain. Currently, I try to solve my problems with perl first, and for anything that is likely to frequently require runtimes longer than a day I rewrite my perl program into C.

      --
      molmod.com - computing tips from a molecular modeling
    6. Re:All accessible from Perl! by Anonymous Coward · · Score: 0

      Perl didn't become and interpreted language, it has always been an interpreted language.

    7. Re:All accessible from Perl! by skeeto · · Score: 2, Informative

      Any way you could back that up with some numbers?

      Unless your program only crunches a lot of numbers during its entire runtime (for example the ImageMagick tools) your program will spend most of its time waiting on some kind of I/O. This encompasses pretty much all software you will find on a normal desktop computer. Perl and C both spend the same amount of time waiting on I/O operations. It comes down to spinning disks or waiting on the slow, clumsy fingers of users.

      On the other hand, Perl is faster when it comes to development time. The Perl programmer will write the same program as the C programmer, but in a fraction of the time. If we are generating fractals or something, the C programmer's version will me smaller and run much faster, but, in the same amount of development time, the Perl programmer can write his program and be out to dinner and a movie. Or trolling Slashdot or whatever.

    8. Re:All accessible from Perl! by moderatorrater · · Score: 1

      *checks difference between time of GP and parent*

      Program in C, eh?

  4. inotify, eh? by Anonymous Coward · · Score: 0

    Too bad inotify doesn't monitor recursively. If you think it does, go look.

  5. K&R by christurkel · · Score: 4, Interesting

    You can probably tell I can't program, but what is "K&R level of experience" ?

    --

    CDE open sourced! https://sourceforge.net/projects/cdesktopenv/
    1. Re:K&R by stoolpigeon · · Score: 2, Informative

      http://en.wikipedia.org/wiki/The_C_Programming_Language_(book)

      --
      It's hard to believe that's how Micronians are made. Why don't we see it right now by having you both kiss one another?
    2. Re:K&R by Otter · · Score: 1
      A basic familiarity with C syntax and simple code examples.

      (In general, the beard-and-suspenders set's insistence upon K&R specifically as an introductory programming text does students a disservice. It's a beloved historical artifact, but it's hardly the best current text for new programmers to start with. I doubt if K&R themselves would argue otherwise.)

      --
      What I'm listening to now on Pandora...
    3. Re:K&R by youthoftoday · · Score: 1

      K and R wrote THE text on C, informally defining a standard.

      http://en.wikipedia.org/wiki/K_and_R_C

      He probably means he's read the book. It doesn't contain things like systems programming.

      --
      -1 not first post
    4. Re:K&R by Anonymous Coward · · Score: 0

      K&R refers to the ISBN: 0131103628
      C Programming Language (2nd Edition)by Brian W. Kernighan and Dennis M. Ritchie

      "The Bible" when it comes to C programming (not updated for C99...err sorry - C programming language, 1999 specification.... at least yet).

    5. Re:K&R by shrykk · · Score: 1

      A basic familiarity with C syntax and simple code examples.

      (In general, the beard-and-suspenders set's insistence upon K&R specifically as an introductory programming text does students a disservice. It's a beloved historical artifact, but it's hardly the best current text for new programmers to start with. I doubt if K&R themselves would argue otherwise.)

      If you think K&R only exposes you to simple code examples, you haven't really read it.

      It's beloved because of its thoroughness despite its brevity, and the excellent exercises. I would venture to say that anyone who had worked through and thought all the exercises in K&R would be thoroughly versed in C and ready to take on fairly advanced projects without the language being a hindrance.

      There are modern texts which provide a better introduction to programming in general, and of course most beginners nowadays will be exposed to OO languages, but some of the classic books are great at teaching you to write short, self-contained programs that do exactly what they should and handle errors in the correct fashion.

      --
      #define struct union /* Reduce memory usage */
    6. Re:K&R by mr_mischief · · Score: 1

      What's specifically better for someone looking to learn C than the second edition of K&R, which covers ANSI C?

      There are certainly better books for first-time programmers, but that's largely because there are better languages for first-time programmers.

      As an introduction to the C language, I think the book is a good tool. As an introduction to programming, perhaps SICP, something on ocaml, or something teaching a modern C descendant like D, Objective C, or even C#.

  6. It are noted? by pestie · · Score: 1

    "...and where this is so it are noted in the text..."

    Well, I hope it aren't noted using grammar like that.

    1. Re:It are noted? by Anonymous Coward · · Score: 0

      Too much caturday.

    2. Re:It are noted? by somersault · · Score: 2, Funny

      oh hai, I ated your lexical parser ._.

      --
      which is totally what she said
  7. advanced programming in the unix environment? by Anonymous Coward · · Score: 1

    how does it compare with Stevens (RIP)?

    1. Re:advanced programming in the unix environment? by mr_mischief · · Score: 1

      Well, for one, it doesn't have what Stevens wrote in that entire other two-volume set, Unix Network Programming. This had Volume 1 (originally Sockets and XTI, but I think later just Sockets), and Volume 2: Inter-Process Communications.

      The great thing about sticking to Advanced Programming in the Unix Environment for what it covers is that the same guy wrote the networking stuff in those others. He also wrote 3 volumes of TCP/IP Illustrated in case you really want to dig deeply into networking.

      If you want to know everything about writing networked applications for a Unix platform without a lot of overlap, or if you're the type of reader who keeps track of connections among topics better when reading one writer's style (I know a couple people like this, but I'm not sure how common a concern it is) then reading it all from Stevens will be a big help.

      Stevens was, however, not writing specifically about the Linux kernel and the GNU libc. There are likely very useful tidbits to be gained from someone who is. If the book is written well, it might be better to read that than to read Stevens and the Linux man pages side by side to get up to speed.

  8. Looks cool, but I'll wait and see... by sticks_us · · Score: 2, Interesting

    ...if the amazon reviews are accurate.

    O'Reilly is great, but I do think you gotta be careful; a lot of their books can, at times, seem to be mostly printouts of man pages (and other freely available documentation), as this reviewer notes:


    If you expect the quality of the author's other books from this book, you'll be disappointed. It just lists system calls and their descriptions that you can find from man pages without any serious examples. It doesn't provide any insight or thorough coverage you can find from other books such as Steven's book.


    Richard Stevens was definitely "the man" when it came to writing books like this; I'd recommend them to anyone. Anyone who attempts to cover the same ground (even years later) has a tough act to follow.

    I've bought a lot of computer books over the years, and for my money, none have been as well-written and valuable as Stevens'.

    RIP, Richard.

    --
    "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth
    1. Re:Looks cool, but I'll wait and see... by sclaughl · · Score: 1

      Anyone who attempts to cover the same ground (even years later) has a tough act to follow. I think Mr. Love would agree whole-heartedly. I believe it was the lackluster APUE 2e (Rago's revision of Stevens's work) which motivated Robert to produce this work. Robert's book is much more concise and useful to a linux developer when compared to APUE 2e, where much attention is devoted to unix implementations other than linux.
    2. Re:Looks cool, but I'll wait and see... by jgrahn · · Score: 1

      Richard Stevens was definitely "the man" when it came to writing books like this; I'd recommend them to anyone. Anyone who attempts to cover the same ground (even years later) has a tough act to follow.

      IIRC, someone came with a revised APUE two years ago or so.

      But yeah -- there are a few interesting questions. What does this book offer which isn't in Advanced Programming in the UNIX Environment, the man pages and the relevant standards? Is the reviewer familiar with Stevens' work? And why is the reviewed book Linux-specific, when all good code is portable across all modern Unixes?

      (The Perl/Python programmer in me also wonders why you have to code in C to be a systems programmer.)

  9. Robert didn't develop the preemptive Linux kernel by Daniel+Phillips · · Score: 2, Informative

    Robert has done plenty of useful work, but it was George AnzigerAnzinger who developed the Linux preemption patch. Robert picked it up, maintained it and got it merged. The credits to George seemed to have gotten lost somewhere in that process.

    Credit where credit is due please.

    --
    Have you got your LWN subscription yet?
  10. Re:life is immoral by Anonymous Coward · · Score: 0

    Leave Britney alone!

  11. Thou shalt not ignore warnings by mi · · Score: 5, Informative

    Build your code with -Wall -Werror (or your compiler's equivalent). Once you clean up all the crud, that pops up, crank it up with -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith. Once there — add -Wreturn-type -Wcast-qual -Wswitch -Wshadow -Wcast-align and tighten up by removing the no in -Wno-unused-parameter. The -Wwrite-strings is essential, if you wish your code to be compiled with a C++ compiler some day (hint: the correct type for static strings is " const char *").

    For truly clean code, add -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls.

    The people, who wrote and maintain the compiler, are, most likely, several levels above you in understanding programming in general and C-programming in particular. Ignoring the advice their code generates is foolish on your part...

    As a minimum, solved warnings will make your code more readable by reducing/eliminating the "Why is he doing this?" questions. More often than not, they point out bugs you would otherwise spend hours chasing with a debugger later.

    And they make your code more portable. But if you don't understand, why a warning is generated — ask around. Don't just "shut it up". For example, initializing a variable at declaration is usually a no-no. If the compiler thinks, the variable may be used before being initialized, scrutinize your program's flow. If you can't figure out, it may some times be better to disable this one warning temporarily with -Wno-uninitialized to move on, instead of shutting it up for ever by a bogus "= 0" or some such...

    The book may well say something about respecting warnings, but the review does not, which is a shame.

    --
    In Soviet Washington the swamp drains you.
    1. Re:Thou shalt not ignore warnings by david.emery · · Score: 4, Informative

      Many studies (e.g. the Bell Labs 5-ESS fault analysis) and anecdotal stories indicate that failing to check the error return on a system call (or any other function, for that matter) is all-too-common. Adding to this problem, when a system call fails, often the manifestation/error/seg fault is not at that point of call, but further down, when a pointer/variable you expect to have meaningful data is null/garbage...

      That's why, when we did the Ada Binding to POSIX (IEEE 1003.5/ ISO 9945), we decided to accept the overhead of imposing exceptions for system call error returns (in most cases). You can't ignore the exception!

      This raised two interesting concerns that we discussed when developing the standard:

      1. What about tasking/threads/concurrency? The requirement on the implementation was to set up per-task errno values. From an implementation perspective, this meant that you needed to go outside of the standard interface to correctly implement POSIX/Ada, as you needed to grab the errno value and load it into task-specific storage, or require that your underlying POSIX threads implementation (if that's how you built the Ada runtime) do that for you. In practice, this is not too onerous, and it's proven to be a real boon for ensuring proper behavior (including debugging) in a multithreaded/multitasking environment.

      2. We also needed to think about the situation (usually representing really poor programming) where an unhandled exception (from a system call, an application call, or a language predefined exception) rips up the callstack and terminates the process. We wanted a return value from the process exit that would be 'close to 1 but not collide with commonly used values.' The number we chose: 42 (with the appropriate citation in the bibliography:-)

      So sure, a C++ program can use the C binding, but I think defining and using C++ exceptions in a better C++ interface would be preferred.

      dave (Tech Editor for the original IEEE P1003.5 project...)

    2. Re:Thou shalt not ignore warnings by Anonymous Coward · · Score: 1, Insightful

      Quit, using, so, many, commas. It will, make, you easier, to understand. And people, may actually, finish, reading, what you write. If in, doubt, don't use a, comma.

    3. Re:Thou shalt not ignore warnings by jd · · Score: 1

      For most purposes, -Wall will suffice on GCC. However, they should add a more comprehensive warning option and call it -Wall-to-wall.

      --
      It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
    4. Re:Thou shalt not ignore warnings by debatem1 · · Score: 1

      Let me preface this by saying that I've been accused of having terrible C style before, but I don't understand why initializing a variable at declaration is a bad thing. Would you mind explaining?

    5. Re:Thou shalt not ignore warnings by osm0diar · · Score: 1

      And they make your code more portable. But if you don't understand, why a warning is generated — ask around. Don't just "shut it up". For example, initializing a variable at declaration is usually a no-no. If the compiler thinks, the variable may be used before being initialized, scrutinize your program's flow. If you can't figure out, it may some times be better to disable this one warning temporarily with -Wno-uninitialized to move on, instead of shutting it up for ever by a bogus "= 0" or some such...

      So, what you are saying is that you'd rather see the program fail with a completely bogus value you have no idea where it is coming from (which is whatever was on the stack at the time the variable was pushed) than a known invalid initialization value (e.g. -1) you pick and you set your variable to ?

      This has long debugging session written all over it...

      --
      A little green man from space only Homer can see.
    6. Re:Thou shalt not ignore warnings by tyrotyro · · Score: 2, Funny

      Thank you, Mr Shatner.

      --
      Here's a guy who enjoys his job: The UPS Man
    7. Re:Thou shalt not ignore warnings by mi · · Score: 1

      However, they should add a more comprehensive warning option and call it -Wall-to-wall.

      That's what -W is :-)

      For more — add the flags by hand. I listed quite a few — borrowed from FreeBSD's BDECFLAGS (collected by Bruce Evans).

      --
      In Soviet Washington the swamp drains you.
    8. Re:Thou shalt not ignore warnings by mi · · Score: 1

      First of all because it is (slightly) inefficient. Second is because in most cases, the variable will get some other value later on in the function — and you'd like the compiler to tell you, if in some cases it may not get it.

      --
      In Soviet Washington the swamp drains you.
    9. Re:Thou shalt not ignore warnings by debatem1 · · Score: 1

      Huh. I always thought it was safer to give it some kind of flag value and catch for it later. Live and learn- and thanks for the explanation.

    10. Re:Thou shalt not ignore warnings by mi · · Score: 2, Informative

      So, what you are saying is that you'd rather see the program fail with a completely bogus value you have no idea where it is coming from (which is whatever was on the stack at the time the variable was pushed) than a known invalid initialization value (e.g. -1) you pick and you set your variable to ?

      This sort of error is easily caught with something like Purify or valgrind.

      Also, if the warning was generated, you disabled it, and your program failed with a random result, that's a very good indicator, that you need to re-enable the warning and study the compiler's output and your program's flow once more.

      But invalid initialization value is another way, but these are slightly inefficient and thus bad style. If you can't figure it out, or if the compiler is incorrectly warning you in one file, go ahead and use this method so as not to disable the warning for all other files in your project... Just put a comment next to the bogus initializer, explaining, why it is there — someone (possibly you) will be able to remove it eventually, when the code changes or compiler improves.

      --
      In Soviet Washington the swamp drains you.
    11. Re:Thou shalt not ignore warnings by Anonymous Coward · · Score: 0

      You can safely ignore the caution to avoid initializing variables. Actually, I claim that you should always initialize your variables.

      As someone who has written a compiler from scratch, I can assure you that any decent modern compiler will do the following regardless of language used:

      • Remove any unused assignments through SSA-style reduction techniques: x = 1; x = 2; x = 3; is the same as x = 3;, so there is no inefficiency except during compilation. Even then it's just one linear pass that is usually combined with output. In my humble opinion, having a well-defined fall-back value makes code more legible.
      • Generate a warning that a variable is not used and will be eliminated from non-debug versions if you fail to read a variable that has only been assigned; it does not matter how many times you assign the variable -- and it will still warn if you assign after the last read. This is just like how you would get a warning for code after a return statement.
      • Generate an error for undefined access if you fail to assign a variable before its value is referenced (note: this is actually an error, because it would cause a runtime exception or introduce undefined behavior, which according to the clc folks will cause demons to fly out of your nose).

      p.s. Something's fishy with the <ul> and <li> tags in my preview; I hope the tags work correctly.

    12. Re:Thou shalt not ignore warnings by The_reformant · · Score: 1

      i prefer to push my luck! :D

      --
      I have discovered a truly remarkable sig which this post is too small to contain.
    13. Re:Thou shalt not ignore warnings by jeremyp · · Score: 1

      The point is that the compiler is supposed to catch the error before you even run the program once.

      --
      All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
    14. Re:Thou shalt not ignore warnings by jgrahn · · Score: 2, Informative

      Build your code with ...

      I always use -W -Wall -pedantic -std=c89 plus any glibc #defines to enable POSIX/BSD/whatever functions I need.

      Seeing people respect and use the gcc warning flags makes me happy, but I don't know why you chose to leave out -pedantic and (more importantly!) the option to select which bloody language you are feeding the compiler.

      But if you don't understand, why a warning is generated ask around. Don't just "shut it up". For example, initializing a variable at declaration is usually a no-no. If the compiler thinks, the variable may be used before being initialized, scrutinize your program's flow.

      I think I understand what you mean: that it's wrong to write int foo=0; if you never intend to use the fact that foo starts out as zero. If so, I agree. That's just a way of making your bugs harder to find, and your code harder to read by obscuring its purpose. But in general, initializing variables is a good idea. In C99 and C++, I usually have something suitable to initialize them with, because I am allowed to declare them where I have the need for them, rather than at the top of the block.

    15. Re:Thou shalt not ignore warnings by Anonymous Coward · · Score: 0

      For example, initializing a variable at declaration is usually a no-no. Interesting. I'd like to know why :-)
  12. Re:life is immoral by DoofusOfDeath · · Score: 1

    Am I the only person who thinks that nature is unfair, and thus inherently immoral; moreover, that no higher authority has the right to define fairness, thus existence itself is immoral? Any human's continued existence is a contribution toward nature, thus the only moral path for every human is to commit suicide ASAP.
    Yes.
  13. When was it not? by moderatorrater · · Score: 2, Informative

    Their about page calls it the "perl interpreter" multiple times. How is it not an interpreted language?

    1. Re:When was it not? by Neil+Hodges · · Score: 1

      It is not an interpreted language because it's compiled at runtime. Why do you think there isn't an interactive Perl interpreter (at least that I know of)?

      It's called an interpreter for the lack of a better name. It's usually used to run a script; I haven't seen it used too often to compile the scripts. The closest I can think of is perlcc.

    2. Re:When was it not? by Mornedhel · · Score: 2, Informative

      Why do you think there isn't an interactive Perl interpreter (at least that I know of)?

      Actually, you can start a debugger session with perl -de 1 (that's the number 1 ; any other empty script will do). That acts like an interactive Perl interpreter would (but really is a loop of "user entry/eval(user entry)/start again").

      Still, you're right in that Perl is a compiled-then-interpreted language (like Python and others).

      --
      This /.-related sig is a stub. You can help Mornedhel by expanding it.
    3. Re:When was it not? by Bill+Dog · · Score: 2, Insightful

      It is not an interpreted language because it's compiled at runtime.

      Ultimately all source code has to get translated into machine code to be able to "run" the program. It's just a matter of when this happens (and how often). Once, on the developer's time. Or every time, on *my* fucking time. The former is compiled, the latter is interpreted.

      --
      Attention zealots and haters: 00100 00100
    4. Re:When was it not? by Random+Walk · · Score: 1
      It's interpreted, because you need read access to the script. If it were compiled, you wouldn't need read access, execute would suffice.

      (I know that's not what you hinted at, but it's an interesting distinction for some purposes - think about access password for your database).

  14. Re:Robert didn't develop the preemptive Linux kern by dnwq · · Score: 1

    Poor Anziger. You even had to copy+paste his name in ;)

  15. Re:life is immoral by Toonol · · Score: 1

    -- Am I the only person who thinks that nature is unfair, and thus inherently immoral; moreover, that no higher authority has the right to define fairness, thus existence itself is immoral? Any human's continued existence is a contribution toward nature, thus the only moral path for every human is to commit suicide ASAP. Yes. At least the only one still alive. Why aren't you following through on your convictions?

  16. Ada's approach to syscall-failures by mi · · Score: 1

    Dave, this is fascinating, but rather unrelated to my post. I don't know, why you chose to post a follow-up, rather than start a thread of your own.

    The number we chose: 42 (with the appropriate citation in the bibliography:-)

    Interestingly, 42 is not listed in /usr/include/sysexits.h on neither Solaris, nor FreeBSD, nor Linux...

    --
    In Soviet Washington the swamp drains you.
    1. Re:Ada's approach to syscall-failures by david.emery · · Score: 3, Informative

      That's not surprising, since the use of '42' is an artifact of the Ada binding, and those systems do not by default contain an implementation of 1003.5/9945. They should, but that's another story. Ada actually meshes very nicely with Unix, and is a good choice for system-level programming above the kernel level. Strong Typing -is your friend-! (I've been doing library level system programming on Unix systems, starting with Ultrix in 1984...)

      The standard Linux/Solaris Ada compiler is the GNU Ada Compiler, http://www.gnat.com

      But at least it's good to know there isn't a conflict.

            dave

    2. Re:Ada's approach to syscall-failures by T.E.D. · · Score: 2, Funny

      Interestingly, 42 is not listed in /usr/include/sysexits.h on neither Solaris, nor FreeBSD, nor Linux...


      Well of course you wouldn't want to *list* 42 as a possible exit code. If you did that, we'd be continually getting our Ada programs interrupted by Vogon destructor fleets.
  17. So you want programs like NetworkManager? by Anonymous Coward · · Score: 0

    Wow, not only from someone knowing gnome, which is famous for breaking all of Unix philisophy wherever it meets it (I personaly especially hate glib for ignoring my setting of $HOME), but even from NetworkManager, the tool you use when you want a non-working network configurable by graphic means between not-working, currently non-working and permanently non-working.

    1. Re:So you want programs like NetworkManager? by statusbar · · Score: 1

      Wow, not only from someone knowing gnome, which is famous for breaking all of Unix philisophy wherever it meets it (I personaly especially hate glib for ignoring my setting of $HOME), but even from NetworkManager, the tool you use when you want a non-working network configurable by graphic means between not-working, currently non-working and permanently non-working.


      Well, I must agree with you there. Perhaps he has good internal knowledge but in my opinion the NetworkManager tool user interface is poorly thought out. What does the check box mean? Why does it change settings repeatedly? Why doesn't network-manager-vpnc not accept my existing conf file? Why is Location blank on my system, I click on the combobox and it changes to the one location that I do have defined and doesn't change back to blank. How can I export settings? Where are the settings stored? Why doesn't it show the dhcp progress?


      --jeffk++
      --
      ipv6 is my vpn
    2. Re:So you want programs like NetworkManager? by xenocide2 · · Score: 1

      Perhaps you're confusing the older GNOME networking tool for NetworkManager? NetworkManager is implemented as a backend daemon and a Notification Area applet. As far as I know, NetworkManager has no Locations setting.

      --
      I Browse at +4 Flamebait

      Open Source Sysadmin

  18. One of my favourite books ever by Anonymous Coward · · Score: 1, Informative

    As soon as I heard that Robert Love had written this book about userspace programming, I rushed to buy it.

    I had really enjoyed both "Linux Kernel Development" (Developer's Library, 2003) and "Linux Kernel Development 2nd ed." (Novell, 2005). I like how clearly and brightly the author describes linux internals, from the major architectural components to the key code chunks.

    This book was a great surprise. It's the best you may desire when you have to quickly design and develop complex solutions with glibc&gcc, and you want to take full advantage of your powerful linux kernel. The most complete guide through system and library calls, with elegant code examples.

    It is going to stay on my office desk for a quite while.

  19. Robert Love .... by NullProg · · Score: 2, Informative

    Is a great kernel developer/programmer (He also does columns for Linux Journal). He is not a general purpose Linux programming author.

    Getting this book out of the box, I had wrongly been expecting a cookbook style that I would get instant gratification from. Although structured around common programming tasks, it doesn't lend itself to just dipping in.

    For getting your feet wet with Linux programming I recommend GNU/LINUX Application Programming by M. Tim Jones or Linux Application Development by Michael K. Johnson and Erik W. Troan.

    The Linux Unleashed series is also good (1000+ pages with hundreds dedicated to perl, python, and Gtk programming).

    Enjoy,

    --
    It's just the normal noises in here.
  20. Not for C beginners by weazzle · · Score: 1

    If this is anything like Linux Kernel Development by the same author, it is not aimed at those new to C. I suggest getting at very least a C pocket book, and reading up (thoroughly) on pointers before diving into this.

    1. Re:Not for C beginners by boyter · · Score: 1

      I really don't get why people talk about pointers being a difficult concept. The only slightly obtuse thing about them is the syntax, and as anyone who can code in more then one language will tell you learning syntax is easy.

    2. Re:Not for C beginners by weazzle · · Score: 1

      I don't think pointers are difficult, I just know enough developers who don't bother checking them. Memory leaks, segmentation faults and stack corruption are symptoms of programmers who use pointers flippantly.

  21. Tour de France Riding. by cabazorro · · Score: 1

    Ride the Tour de France like the pro's. This book encourage you to think about the possible technical and physical hurdles you may encounter when riding the longest, toughest bicycle race known to men. The book covers some basic subjects like wheel tunning, seat height and handlebars using real life examples. Other chapters cover more advance subjects such as sprinting, time trials and team-riding. Mountain stages are not included in this book. I recommend this book to anyone who has a need to ride bicycles either professionally or in amateur circuits.

    --
    - these are not the droids you are looking for -
  22. Re:Robert didn't develop the preemptive Linux kern by YourExperiment · · Score: 1

    George AnzigerAnzinger So good, they named him twice.