Slashdot Mirror


Linux Programming by Example

Simon P. Chappell writes "Linux programming is the C Programming Language. Elaborating a little, Linux programming is C, with the GLIBC library and the POSIX standard API. Even a language as powerful as C needs libraries and to get the Holy Grail of cross-platform portability, it's necessary to have them standardised. The POSIX API is that standardisation and Linux adheres to it very well (opinions from those litigious folks in Utah aside). For those of us who already know C, Linux Programming by Example sets out to teach you the rest in a step by step, helpful, relaxed and incremental manner." Linux Programming by Example author Arnold Robbins pages 687 (21 page index) publisher Prentice Hall rating 10 reviewer Simon P. Chappell ISBN 0131429647 summary An exellent tutorial for real-world Linux software development

What's To Like There are many things to like about this book (over and above the fact that page 118 has my all-time favourite UserFriendly cartoon on it :-). Linux Programming by Example (LinuxPbE hereafter) takes a steady, incremental path through the concepts required to write software that can effectively interact with the Linux environment.

It is a truism many of us have proven multiple times in our lives that one of the finest learning tools available to programmers is to read and grok good, working code, written in the language that we are learning. LinuxPbE takes this philosophy and walks you through actual example code from various Unixes and Linux. The first part of the book, specifically chapters one through six, covers all of the aspects of Linux programming necessary to understand the Unix V7 ls program in its full glory in chapter seven. I feel that this approach works very well.

Part two dives into processes, walking us through creating them, managing them, communicating with them by using pipes and sending them signals. A few other general topics are included for completeness. Part three then covers the art and tools of debugging in fairly substantial detail.

All the code in the book is very well laid out, with line numbers provided to the left, and comments (in a small sans-serif font) on the right-hand side of the code. This is a very readable combination that is enhanced further by the fact that at each logical division, an explanation is given of the design and implementation used by that section.

I can't resist admiring the addition of the essay "Teach Yourself Programming in Ten Years" by Peter Norvig. This is a classic exploration of the effort needed to attain mastery of any skill, concluding that the minimum length of time required is ten years. The inclusion of this article, to me, speaks well of the author and his understanding of the learning process. One can only hope that those learning from this book will come to the same understanding and realise that the book is the start of their journey to mastering Linux programming.

What's To Consider

Nothing notable.

Summary If you want to learn how to do this stuff for real, then this book will get you started. As "Teach Yourself Programming in Ten Years" explains, no book is going to cause you to become an expert in 24 hours, 24 days or even, perhaps, 24 months. That said, this book will be useful for many of those ten years, so run or surf to your favourite bookstore and purchase it now.

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

4 of 119 comments (clear)

  1. automake, autoconf, .src.rpm, ... by Speare · · Score: 5, Interesting

    The common meta build tools can be a nightmare to learn all at once.

    • autoconf
    • automake
    • patch files
    • .spec and .src.rpm
    • .deb
    • -devel packages vs user packages

    While these are not essential to the beginning developer, having a chapter which covers the background, the problem, the solution and the practice of each of these "meta" tools would be really useful to get new developers going. They don't have to be covered in detail, but really honestly understanding WHY a project might be using a given meta build tool can help more people get involved.

    --
    [ .sig file not found ]
    1. Re:automake, autoconf, .src.rpm, ... by ron_ivi · · Score: 5, Interesting
      Indeed. Did you guys ever check out the GNU/HelloWorld program?

      It's A 380K Tar file! with over 2000 lines of C code.

      The first time I thought it was a parody, but it's really an insightful look at Internationalization, cross-platform build environments, and other things important to free software. I didn't RTFB that was reviewed, but I hope it goes into these important topics as well. I think this emphasis on coding standards that value the less visible aspects of software such as build environments, internationalization, etc is one of the big advantages of open source.

    2. Re:automake, autoconf, .src.rpm, ... by Anonymous Coward · · Score: 1, Interesting
      The common meta build tools can be a nightmare to learn all at once.

      This is exactly why my philosophy is that if you cannot simply type "make" and have the damned thing build on all systems you are interested in supporting, you are just a lazy bastard.

      The need for a configuration script should be giving you a hint that you've done something wrong. The packages that actually require this level of complexity are extremely few and far between. Most configure scripts I've seen are completely superfluous, and I laugh at the poor schmuck who wasted hours or days of his time getting the stupid thing working when all he really had to tell the user was "Just type 'make'".

      My girlfriend did some grading of undergrad projects last term. One guy submitted his project, which amounted to somewhere under 1000 lines of C code, with over 10000 lines of configuration retardedness surrounding it. On top of that, the damned configuration script didn't even work.

      Without a working Makefile (autoconf based packages generate it on the fly, except this one was broken) the project couldn't be compiled and the student received a very well-deserved 'F' for his moronic attempt at impressing her with his super-leet GNU autoconf skills. What a buffoon.

      (No, it is not the grader's responsibility to fix your stupid syntax errors and Makefile flaws. If it doesn't compile, you fail. How hard is it to test your fucking build system?)

  2. Re:re "Teach Yourself Programming in Ten Years" by adamofgreyskull · · Score: 2, Interesting

    Do you think this is linked to the state of the industry? I mean, does anyone have enough time to truly *master* a language anymore? Using the analogue of a master craftsman e.g. a cabinet maker, they would spend all their life working with tools which only very very very rarely change.

    In the 4 years I've been programming *properly, I've used Delphi, Java, C, C++ , Qt and SQL. I am nowhere near knowing all there is to know about any of them. I'm sort of worried that I'll never really be able to _master_ a language...

    *at university,on placement and varying from trivial to decidedly non-trivial...