Slashdot Mirror
Linux Programming by Example
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 ConsiderNothing 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.
Cutting and pasting makes things really easy.
Now all we need is a "Linux Documentation Writing by Example" Then we could tell people WTFM instead of RTFM. =)
Lagito ergo expectabo
This particular book is currently out of stock there, but I just thought I'd mention one of my favorite sites, bookpool.com. This particular book costs 15% of the list ($6) less than Barnes and Noble. They have great service and fast shipping (often free if you purchase enough).
No affiliation whatsoever, just thought I'd share.
The common meta build tools can be a nightmare to learn all at once.
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.
[
I agree. I tried to import the 2.6 kernel into a VB project and couldnt get it to compile despites hours of trying to tweak the code.
.NET runtime.
I did manage to get it to compile with C# but I got some weird errors when running it with the
I thought the appropriate google bomb was litigious bastards.
-no broken link
This is Darth McBide here - I don't often make it a habit of stopping by Slashdot and I have promised myself to take a shower wafter posting this message.
To the point, I would like to bring it to your attention that any "Linux Programming by Example" would unavoidably be a violation of our broad reaching IP. For reasons that are quite beyond anyone here we cannot tell you the exact contents of our IP so how the heck are you going to know when your examples are going to tread on our property? So please take my advice and refrain from publishing anything that could trigger another lawsuit...
Can we mod the original article as +1, Funny?
I can see the following "problems" with some of them (if I am wrong, someone please correct me):
ch02-printenv.c:
Shouldn't there be a #include <unistd.h> after the #include <stdio.h>? The extern variable environ is available only if unistd.h has been included. While I am talking about this example, it could have used int main(void) instead of ...(int argc, char **argv) (like he does in ch03-getline.c).
ch03-getline.c:
size is declared size_t, so it should be printed with %z (C99 only, IIRC), or it sould be cast (unsigned long) size.
ch03-memaddr.c:
uses global variables, when simply adding two parameters to afunc will do the job. I know it's a trivial example, but global variables are bad in general, and certainly avoidable in this case.
casts the result of alloca when there is no need for it. In fact, the cast will remove the warning the compiler might give if someone forgot to #include <alloca.h>.
I haven't checked other examples.
DOS-heads gloating to each other in front of an Amiga calendar.
I find that so incredibly weird, my head might implode...
Someone set us up the bomb, so shine we are!
In short, I am *still* learning, and there are areas I've not even scratched. And I'm having a ball! Ten years? Heck, it may take me fifty!
Generally, bash is superior to python in those environments where python is not installed.
It would explain how to work nicely with KDE and GNOME and what the differences would be. Also, how to make a robust applicaiton that is easily integrated into both environments. It would explain QT v. GDK. It would explain what I, as a programmer should do to make my application work well with others. It would explain how to make a nice installer. How to detect required packages, What command-line options are standard, what API and hook functions should be available.
Instead of "Learning to Program using LINUX", it would be "Learning to Program FOR LINUX". I would like to know what conventions exist so I would not try to reinvent the wheel.
Most of this is freely available information that is easy enough to find already. But, I would be willing to pay for a one stop shop that would get me started in the right direction.
I have yet to see a book that would be a good getting started guide, and then, a good reference. For now, most projects I start by tinkering and prodding, (which is good too), but I would love to create more powerful applications.
Go grab a "Linux" program at random. Any "Linux" program. Cervisia, GIMP, Emacs, bash, Xmms, etc. Funny thing, they all build and run flawlessly on Solaris, FreeBSD, IRIX, etc. Why? Because they're NOT "Linux" programs!
Unless you're writing stuff that depends upon a Linux kernel, you're not doing Linux programming, you're doing standard Unix programming. glibc is nothing more than GNU's libc. And libc is pretty damned standard.
Don't blame me, I didn't vote for either of them!
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...
Nobody masters a language anymore. You master _techniques_. Languages are just syntaxes to implement those techniques.
To put your analogy to use, there's really only so many ways (techniques) to build a cabinet. The different programming languages would be the different tools you use to apply those techniques to build a cabinet.
The nice thing about learning different languages is it often reveals to you new ways of doing things, which you can then apply to languages you already know.
You'd do well to learn Perl or PHP, btw.