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.
Sheesh, with X you can cut and paste between machines
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.
"Linux programming is the C Programming Language. Elaborating a little, Linux programming is C, with the GLIBC library and the POSIX standard API."
For Linux kernel programming the logical choice might be C, but the article makes it sound like that's the only way to program on Linux.
If you're a commercial programmer, chances are that C++ is more useful to you (shock, horror - C++ is not C). And I would recommend Python for higher level programming (and also for beginners to the programming world).
I think you are confusing "powerful" with "high level". C is an extremely powerful language, second only to assembly, in that you can write programs in C to do anything within the capabilities of the underlying hardware. The tradeoff you make when using a relatively low-level language is that many common tasks are a pain in the ass, memory management being one of the obvious examples. But the other side of that tradeoff is that higher level languages make common tasks trivial at the expense of rendering certain less-common tasks difficult or even impossible. The designers of high-level languages are quite conscious of this as is demonstrated by the near-universal provision for interfacing with code written in C.
Power and ease-of-use are not the same thing. Many people use different text editors for programming (vi, emacs) than they do for editing email (pico, joe). Languages are no different.
Proud member of the Weirdo-American community.
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!
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.
C is for people who understand how computers work, and how they work best, and who can't or won't accept "easier" or "faster" (to develop in) programming languages just because they won't always generate the best code. There will always be that edge case where that nice object oriented language (including C++) or functional language will absolutely butcher an algorithm and be suboptimal, and with C all the edge cases can be patched up. C is also excellent for any system programming because of its correlation to the physical memory of the system. C can almost always generate the fastest possible code, because any other construct another language uses can be implemented as close to the physical hardware as necessary, and sometimes faster. C is thus a very general purpose tool in which any kind of programming can be done, despite the obtuseness of doing it that way. Ultimately, machine language and assembly language alone offer more power than C. It is likely that the quality of power is what attracts the majority of C programmers. Sure, all (real) languages are turing complete, and thus equivalent, but you don't see people eating nutrient gruel all day because it's packed with all the things better tasting foods have. C is most pleasing to the palate.
I program in C mostly for portability reasons, not performance. One of the first things any good programmer should learn is that performance is the last thing you should ever design for (although it's good to keep it in mind, so you don't make life harder for yourself, you generally end up scrapping your first few attempts anyway).
:)
A lot of the open source projects you read about have portability to multiple platforms as a goal, or are system-level software/utilities that really needs to be coded closer to the metal (my application, for example, is a network server which needs to be able to fiddle around with lots of bits on a grand scale).
Sure, C may be glorified assembler, but it's portable glorified assembler. C remains the one language you can count on to run on just about any platform; the first piece of application software for any new general purpose computing architecture is generally the C compiler.
I don't think it's a silent majority, though. Most programs are not the sort of things people do as labors of love, but are most likely applications (Web or otherwise), where domain knowledge is more important than the programming. That's why you have so many people touting the benefits of Perl, PHP, Python, or whatever; they're much better languages for writing such programs quickly and efficiently.
I would say the general mentality in these cases, though, is that such programs should not be designed to last forever. Easy to code, easy to throw away. C culture takes a more monumental approach to programming. I notice programs that are written in C are designed more for other programs to use (libraries, frameworks, servers, etc.), rather than doing something in and of themselves. Often the first thing you end up doing in any major C programming project is accumulating a library of functions so you can get down to your real business.
That said, I've noticed a lot more interesting and useful stuff seems to be written in Java these days than anything else. I've actually found it hard these days to find decent libraries with C bindings for a number of common tasks. And I wouldn't mind a better C than C, which had support for a few more modern concepts in a way that wouldn't overtax the portable assembly idea to the point where it's no longer useful (aka, no VMs and unstable ABIs please).