Slashdot Mirror
Linux Programming By Example
There are plenty of books on this topic as any trip to the bookstore will show. Where this book excels compared with other Linux programming books is its consistent focus throughout. Other books tend to explain a multitude of concepts without relating them back to a real-world example. In Linux Programming By Example, the author introduces a concept, and explains it with an example. In the last chapter, the author integrates the knowledge he's presented, utilizing many of the book's concepts in building a simple CD-Database program. Of course, not all of the concepts relate to the final CD database (The chapters TCP/IP Programming, The Sound API and Using the Mouse are not referred to in the final program), but it's helpful for beginning programmers unsure how all of these pieces fit in the bigger picture of a working program.
Begin at the beginning
Linux Programming By Example begins with topics that don't get covered until the end of many books. The book starts by discussing how to use GCC and make on a Linux machine, and how to create a Makefile. It's always puzzled me why some books don't cover the compiler or the make process until the end of the book. What's the point in that? Granted, chapters in debugging and RCS are left to the end of the book, but presenting key concepts in the development process early in the book helps the reader to get a better feel for how all of these concepts interrelate in a Linux/UNIX environment.
Moving forward
From the basics of compilation and making programs, the book moves to the basics of a Linux system in Part II: System Programming. This is where the book truly shines. In the section on processes, Wall discusses the elements that make up a process, how to manipulate a process, and why you would want to do this anyway. The book assumes no prior UNIX knowledge, but doesn't plod along like most introductory texts. In the section on signals, the book defines what signals are, early signal APIs and their issues, POSIX and Linux signal APIs, and how to use signals and signal sets. In this chapter, the author not only lists the signals supported by the Linux system, but also other signals supported by POSIX and other UNIX systems. While this might sound confusing, the author takes time out to explain which signals are really important in a Linux environment. This is a key reason why this book retains its readability without losing depth. Each chapter in the System Programming portion of the book retains this format -- not only demonstrating what the topic is, but also where this fits in a Linux/UNIX system and why you would even bother to know this in the first place.
What's good?
Linux Programming By Example is clearly aimed at getting programmers up to speed on not only programming Linux systems, but also POSIX based systems. Wherever possible, the author makes a point of pointing out the POSIX way. This book could have been easily called POSIX Programming by Example. The author also makes no bones about implementation issues with Linux and the POSIX or System V way of implementation. The book clearly states where Linux falls short of the full POSIX standard, and where pitfalls with porting code from other systems may occur. It's a refreshing change from other beginner texts which assume the reader will discover these pitfalls on their own.
So what's in it for me?
If you're looking for a quick, effective way to get up to speed in Linux and UNIX programming without breaking the bank, Linux Programming by Example is the book to take you there. This book is designed for programmers who are familiar with programming on other systems but haven't dealt with Linux before.
You might have trouble locating this book, since QUE let it lapse for a while, but there should be another batch hitting stores soon. You won't be disappointed.
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.
But where is the 'Reading By Example' that tells you how to read this book?
-- Ed Avis ed@membled.com
I've always liked the the red books.
B&N
The current Linux programming wisdom comes from Richard Stevens, a know-nothing hack who spends more time talking about the out-dated concept of filesystem permissions and socket programming than he spends on GUI design! I mean, for crying out loud, Dick, this is the Aughts! We "aught" to be optimizing for the user experience, not ivory tower "engineering principles"!
Anyway, throw away your copy of Linux Kernel Internals because this book replaces it...and then some!
This Book Was published in 1999.
It might be a little outdated. This review seems to be a couple of years late
Advanced Linux Programming, from CodeSourcery/New Riders. It wasn't a "beginning/intro" book but still very easy to read and quite informative. Lots of great code samples too. The finale of the book is actually coding a bare-bones http server.
Easy guys, I put my pants on one leg at a time. The difference is after I put on my pants I make gold records!
I've used two Linux programming books, and would recommend both: 1. "Linux Application Development" by Johnson and Troan. A bit more advanced than "Linux Prog by Example," but I was able to use it effectively coming from NO linux/UNIX programming experience. 2. "Advanced Programming in the UNIX Environment" by Stevens. An excellent reference.
Probably the most evil and wonderful thing of programming in *nix environments.
I am going to get this book because it covers make in the begining. I have always had trouble getting my makefiles to work properly in the few instances of linux programming that I have done. And even then I copied an existing one and adjusted it to my needs.
I suppose the "there is only 1 makefile" saying exists for a reason...
"The large print giveth, and the small print taketh away" -Tom Waits
I have this book, and I definetly would not give it a 9/10. The text is plagued with errors. Most of them are corrected easily enough, but it is still a hassle to type in some sample code and not even be able to compile it without debugging first. To make matters worse, the url in the book given to download the sample code (and the errata) doesn't work. Take a look at some of the amazon reviews to gauge popular opinion on the book. I picked up my copy on sale for $10 at frys, but I would wait for a second edition or look at another book if you're planning to pay full price.
I've been looking for good working examples of source code for Linux programs.
Karma: Good (despite my invention of the Karma: sig)
The Wrox P2P title Beginning Linux Programming, by Richard Stones and Neil Matthew, covers some similar ground: makefiles, shell scripts, some basic C, Perl and TCL (not really basic - they show you how to use these languages to do some typical linux-y things, rather than explain about structs and scalars), an introduction to GTK and a chapter at the end on writing device drivers. If you're an intermediate-level programmer unfamiliar with Linux as a programming environment, this book offers a good way in; recommended for VB weenies with a conscience.
Experience is a hard school, but fools will learn no other.
You, Confused, wonder who Example is. I am Enlightened. Pleased to meet you.
Infuriate left and right
Man, did everyone just go to Amazon and order this? Read BN was out, now Amazon - I was lucky enough to get one for ~$14; seems like every time I added to my cart a book was gone a few seconds later. Damn, this is the first time I've seen inventory slashdotted. :)
If your getting modded down it's because you bring nothing to the table. Take for example your post here:
subject: who would want to program for linux?
you don't get paid..
First, that's a troll if we ever saw one. Because 1) there are millions upon millions who program for linux now. 2) they do it for fun, not money. 3) some do it for money too. 4) some do it just for the money. 5) who ever wrote a program they got rich off of? Careful here, remember that Bill Gates bought his first program to sell, and stole many others (or built on the work of others) after that. Microsoft makes money by SELLING software. Not writing it. There is a significant and subtle difference.
Moving on:
Welcome to America, land of capitalism..Is Microsoft hiring?
If I'm not mistaken, America is the land of the free, not the land of capitalism. Capitalism (in it's purest form) has nothing to do with money. A capitalist form of finance stops being capitalism as soon as any one person or company has the ability to create an artificial barrier to competition (and that's whether or not they do actually create the barrier - it just has to be possible). In short - Capitalism depends on a free market, which you don't have if there are barriers to competition in an industry. So much for America being the land of Capitalism. Indeed, you misunderstand capitalism entirely. Capitalism centers around the individual. The individual has the final say and right in _any_ situation - Microsoft on the other hand is anti-capitalist in that whatever the programmer makes belongs to the company he works for. This is a violation of the programmers right to do what they want their own ideas. For example, if you helped write Microsoft's media-player, and had an ingenious idea on how to do it better, you could not leave the company and create this new player based on the knowledge you gained at Microsoft. You'd get sued into oblivion, even if you didn't use Microsofts IP to do it.
The GPL on the other hand entitles the original author some degree of control over his work - if you wrote the original you (the individual) have the right to use the GPL or not (you can even re-licence _your own_ code to companies who don't want the restrictions of the GPL... just make sure it's ALL your code that your re-licencing), and entitles you (the individual) to place restrictions on how your work is used. Get it? Capitalism depends on the individual having rights that supercede the greater interest. Corporations supercede the right of the individual for the good of the company.
And finally, if Microsoft is hiring, what difference does that make to you? Even Microsoft has standards.
My cube. My friend. My solace. My prison.
I have to write C/C++ code daily for Tru64 and Linux. Unix Systems Programming and Programming with POSIX Threads are two very good books. They aren't Linux-specific books, but I've used these books on a weekly (or daily) basis for a couple of years despite the USP book being written in '96.