Slashdot Mirror
Professional Linux Programming
Introduction
Large programming books have a special sort of gravitational pull to them. It's a sort of siren's song for us techie types, with lyrics promising an endless fountain of information, more than you could ever possibly hope to use, superfluous only in the same way that you don't plan on reading the Encyclopaedia Britannica cover-to-cover anytime soon, either.
Unfortunately, this branch of the publishing industry responsible for these books is well aware of this, and as such there's a veritable critical mass of crap in that corner of the bookstore, some of it reading like blood being squeezed from a stone, with any number of useless chapters thrown in there just to meet some predefined page quota. Which is why it's such a relief to get a book like Professional Linux Programming that's 1155 pages long and contains a ton of material, with very little of it page-filler. Unless you already know it all, there is something valuable in this book for just about every Linux developer out there.
The GoodThis book is loaded. Go straight to the table of contents if you need to see what I mean. The book's sheer ambition almost makes it worth picking up a copy. We need more like this -- not just for Linux, not just for programming, but for computer references in general.
If you've thought about developing for Linux, you've probably rubbed up against the impression that Linux and C go together like a wink and a smile. This book delivers on that impression, and it delivers huge. There are chapters on how to use C with PostgreSQL and MySQL databases, LDAP services, GTK+/Gnome/libglade and Qt/KDE, Flex and Bison, XML, sockets, RPC and CORBA (using ORBit). There are also sections on applied professional development theory, like design, debugging, security, deployment, and encryption.
If C isn't your bag, you might not find as much to get out of this book, but there are still sections on PHP, Python, documentation, package deployment, internationalization and shell database manipulation. Ever wondered how CVS or patching worked? It's in there. There's even material on device drivers and Beowulf clusters. By the end of this book you'll have more than just proof-of-concept familiarity with just about all the topics. For all but the more exotic subjects, you start at the simplest example, and the complexity gets increased with subsequent scenario, until the point where the chapter gets applied to the book's ongoing case study, which is the development of a hypothetical system to track a DVD store's business operations.
To give you an idea about what sort of depth to expect from this book, I'll talk about what it does with PostgreSQL. It shows you how to install it and maintain it from the command line; walks you through how to create basic databases; gets you comfortable with running SQL queries from the command line or scripts from a file; shows you how to interface with it using C (using both libpq functions and embedded techniques); shows you how to handle different kinds of transactions and cursors; talks about bringing it into PHP; and uses PostgreSQL for the core engine for the case study. Now, database work is obviously going to be getting special treatment when it comes to commerce development, but that's still only one of many subjects that this book tackles, most of which are designed to get you on the ground running before needing to resort to supplementary material.
As an aside, from a coordinating standpoint, this book is a marvel. Content was contributed from 15 separate authors and yet continuity is practically a non-issue.
The Not-So-GoodTypos. Oy vey. It's like getting a buddy to lend you his Ferrari, only to discover that there's a little bit of bird crap on the windshield that nobody can wipe off. Nice car, shame about the bird crap. Now, this book isn't horribly bad for it, but you shouldn't be surprised to find the odd error at the rate of one or two per chapter, usually in the form of an incorrect diagram symbol here or there or a formatting character that didn't quite translate into a code listing. Not too bad, but it's enough to be a mentionable problem. The Wrox people were good about putting up an errata page, but, unfortunately, it's empty. This may speak to the fact that the intended audience are hackers who can probably figure out the problem for themselves anyway.
Then there's the timeliness factor. This is a review of the first edition, which came out in September 2000, and it's unfortunate that with all the new technologies coming out (Bonobo, KParts, Mono, etc.) there isn't a second edition in the works as of yet. As such, people hoping to find useful information on programming with the more volatile APIs (specifically the GUI stuff) might want to look elsewhere. The information in this area isn't completely obsolete, just not as cutting edge as it was when the book first came out. Most of the other chapters are still current, and had this review been done near the publication date, the rating would easily be a 9 out of 10. That it still merits a review at this point, after being out for almost a year and a half, hopefully says something.
There's also the fact that even though this book contains so much, it doesn't really act as a definitive reference in any area that it describes. For instance, I was toying with the idea of making a code mangler for an XML-type language, so the chapter on Flex and Bison had me drooling. It wasn't long after reading it, though, that I found myself needing to go to GNU's Flex website just to get a better listing of all the regular expressions I'd need to use. That's symptomatic of pretty much all the chapters here -- it doesn't take long to outgrow the material when you need to apply it to your personal project. In this sense the title seems misleading; if you wanted to program in some of these areas at a professional level, this book would only be a starting point to another, deeper reference.
The huge breadth of knowledge also makes some omissions seem glaring. There is nothing on Perl or some of the other popular shell languages. Outside of two chapters, C++ is avoided like the plague. The section on deployment using automake is tiny enough that it's practically not there, which is surprising given the amount of time a reader spends churning out source code throughout the rest of the book. There's also a brief section on multimedia that, given the context of the rest of the topics, just feels out of place. Some of these shortcomings are made up in the intended predecessor to this book, Beginning Linux Programming , so you might want to give that book a whirl as well (TCL, BASH, and Perl all get treatment there).
And just to leave no superficial stone unturned, the cover is just awful -- it looks like a police lineup. Although I suspect there's a focus group somewhere that needs to answer for this, maybe it bodes well knowing that, considering the slightly expensive nature of this book, none of that money went into its outer design.
ConclusionThere are some people who aren't going to want to buy this book. Specialists, or people who want to specialize, likely won't get enough of what they want on any of the subjects here. Also, this isn't so much a learning guide that will give you exercises and quizzes, so if you're still at the stage where you need that sort of thing, this book might be a bit rich. If you're hoping for bleeding-edge stuff, wait for a second edition.
Also, it's taken for granted that the reader understands C pretty well, so if you don't, invest some time in that area first.
However, if you've got the fundamentals of Linux programming down pat but don't know where you want to go next, buy this book. If you're a seasoned developer and just need to get the basics of a new area in order to apply it to your ongoing projects, buy this book. If you're a generalist or a hobbyist, buy this book. If you need to design application prototypes for the Linux platform, buy this book. If you want to compare different APIs without having to commit to buying different textbooks, buy this book. If you get off on knowing you can do more Hello Worlds than any of your friends, buy this book. And if you like your references so big and fat that they bend light, buy this book.
Table of Contents IntroductionChapter 1: Application Design
Chapter 2: Concurrent Versions System (CVS)
Chapter 3: Databases
Chapter 4: PostgreSQL interfacing
Chapter 5: MySQL
Chapter 6: Tackling Bugs
Chapter 7: LDAP Directory Services
Chapter 8: GUI programming with GNOME/GTK+
Chapter 9: GUI Building with Glade and GTK+/GNOME
Chapter 10: Flex and Bison
Chapter 11: Testing Tools
Chapter 12: Secure Programming
Chapter 13: GUI programming with KDE/Qt
Chapter 14: Writing the dvdstore GUI using KDE/Qt
Chapter 15: Python
Chapter 16: Creating Web interfaces with PHP
Chapter 17: Embedding and extending Python with C/C++
Chapter 18: Remote Procedure Calls
Chapter 19: Multi-media and Linux
Chapter 20: CORBA.
Chapter 21: Implementing CORBA with ORBit
Chapter 22: Diskless systems
Chapter 23: XML and libxml
Chapter 24: Beowulf Clusters
Chapter 25: Documentation
Chapter 26: Device Drivers
Chapter 27: Distributing the application
Chapter 28: Internationalization
Appendix A: GTK+/GNOME Object Reference
Appendix B: DVD RPC Protocol Definition
Appendix C: Open Source Licenses
Appendix D: Support, Errata & P2P.Wrox.Com Related Links
- Wrox website
- Sample chapter from the book
- Wrox's P2P page for this book
- Linux Journal's Review of this book
- ACCU's Review of this book
You can purchase Professional Linux Programming at Fatbrain.
I own Beginning Linux Programming 2nd ed. and think it's great for reference and instruction. I really wanted to get the Professional book. But after spending about 30 minutes at Borders looking through it, I found that it covered a lot of subjects but it didn't seem to go in any significant depth in any one of them. I think maybe the scope was a bit too big and they should have covered fewer subjects in greater detail.
They call me the working man. I guess that's what I am.
I have this one, i also have the Beginning Linux programming book by the same people. i can heartily recommend both books to anyone looking to get into linux programming in general or advanced c programming with linux in mind. This book covered stuff my C programming book didnt. They also have a huge following on their website, with very good mailing lists for that little extra help if thats what u need.
The "typos" comment is very telling.
This sounds to me like a "shovelware" book, albeit too late to have any impact on anything other then the trees that died to print it. Do they pay the authors of these tomes by the pound?
The fact of the matter is anything Unix programming related or C related has been done already and done well. These attempts to cash in by vendors like WROX (and their ilk, like QUE) by slapping "Linux" on the cover are just that, attempts to cash in.
You want a decent Linux book, make sure it's in a nutshell and/or has a funky animal on the cover.
Does every review end up being a 7 or 8 lately? Where are the really great books or really bad books? Or is the Book Review going to turn into here is the latest above average book we have reviewed
I think a certain number of typos in a book that I pay for should allow me to receive a refund. Particularly in a technical manual, when you are trying to learn something, typos can really lead you down the wrong path. Especially with the number of readers that would be willing to proofread for free prior to the book being published, there is no excuse.
just so you know, comparing a linux company to a car company is ver different.
Actually, it's a much better analogy than you realize. The cost of the materials and labor that goes into producing a single car is nothing-- a few thousand dollars at the very most, and the vast majority of that in labor costs-- compared to the tens of millions of dollars spent to conceptualize and design that car model.
To my knowledge, nobody's ever done a cost-accounting for, say, Red Hat Linux 7.2. Let's say it cost a grand total of $6 million to produce Red Hat 7.2, going all the way back to Linus's spare time. Your plan for recouping those costs and eventually making a profit is called a business model, and the jury is still very much out on whether it can be made to work.
But really, who cares? After all, you can't spell analogy without anal.
The much awaited new doorstop from WROX press has arrived. It's in the traditional red to coordinate with the theme of their current line of doorstops. This latest addition is really large in case the door has a high clearance and extra heavy for those doors with large springs. It also features a fashionable "Linux" on the cover so you can be the envy of your guests, assuming you ever have any.
I used to wonder what was so holy about a silent night, now I have a child.
I've got the beginners book, and reckon it's a cut above the QUE and SAMS tomes. As an overview of many topics it's great.
Probably as good as O'Reilly, which can sometimes be a little too terse (when I want documentation that only makes sense when you understand the topic anyway, I'll read a man page).
The one thing I can't stand about Wrox is the author pictures on the covers - definitely prefer the animals...
Sigs are so 1990s. No way would I be seen dead with one.
Granted, typos are annoying. The value of these books goes beyond a compilation of information, but the wealth of information is organized in an easily digestible way. Its like reading a newspaper on a lazy afternoon. Compare to that of taking a casual interest and reading through the howtos and other documentation through the net. This book can be taken around the house or at appointments for casual reading. The Beginning Linux book was an enjoyable read and the Professional Linux book appears to be on scale with those huge electronic engineers books for reference or learning technical knowledge in spare time.
Like ants at a picnic, there are plenty of similies in this review. No doubt the work of someone who has actually read things other than programming manuals.
Remember, You are unique...just like everyone else.
Of course its going to be strictly Linux/open source oriented. After all the money you spent on that MCSE, the MSDN subscriptions, etc..., why would you be so kind as to give out tips to an anonymous fellow on the internet? Even if slashdot started out with an eclectic mix of platforms, it will soon evolve into something that slashdot is now. My guess is that soon, there will be no microsoft partisans on this site. Except for those few lost fellows who can't afford the MSDN.
Remember, Slashdot book reviews are submitted by people who read the books and jotted down their thoughts.
:) Instead, we rely mostly on self-selection; hopefully this means that people distill their good and their bad book experiences, but since people (rationally) try to minimize their bad experiences anyhow, it's natural that they instead choose to finish, enjoy and pass on ones they like.
It's true that most Slashdot book reviews fill the 7-9 range, but that shouldn't be *that* surprising -- how many people *bother* with the time and hassle of finishing a book they think is awful (or just well below par) in order to write a review of it? Paid reviewers on a contract, assigned books whether they like 'em or not, Yes -- but that's not how we do it
We may decline book review submissions that are hard to read, abusive, don't fit our book review guidelines well enough, etc, but never for a low rating. That rating is up to the reviewer.
jrnl: http://tinyurl.com/c2l8yr / foes: http://tinyurl.com/ckjno5
Exactly how is a review of a 16-month old book newsworthy?
It's not meant to be news, it's meant to be a book review. I've seen plenty of Slashdot book reviews that weren't of recently minted books. I don't see why it's a problem. As long as the book is still relevant in it's subject area, a review is beneficial.
Hell, the review may be beneficial even if the book ISN'T still relevant, if the book review brings that point out, thereby helping somebody avoid a useless purchase.
// TODO: Insert Cool Sig
Getting worse? Ha! Slashdot was started by c.o.l.a regulars, so this shouldn't be surprising. Its much, much tamer these days, but still expect your daily dose of Windows bashing. Unfortunately, slashdot attracts these pushbutton Windows users like flies since the Chips&Dips days.
I bought a different Wrox book, and found so many typos that I emailed Wrox offering to tell them all the errors I found, in exchange for a free book. I never heard back from them. Other than the typos, the book was fine. In fact, the typos caused me to stop and pay closer attention, so perhaps it's actually a good training tool?
Really though, I suspect Wrox doesn't have a proof-reader. Or, their proof-reader is drunk all the time.
"Would it kill you to put down the toilet seat?" -- Maya Angelou
Am I alone in thinking Wrox generaly sucks? Their Beginning Java 2 book was used in my Java course last year. The book is OK if you're just learning Java, but is almost useless as a referance (possibly because they want you to buy the referance as a seperate book). Don't get me started on that Ivor Horton guy (aka, "Evil Horn").
Not a typewriter
the jury is still very much out on whether it can be made to work.
What do you mean by work? If the people doing the work and happy and the people using the products are happy then it works. Who else matters?
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
Most Linux programming books deal almost exclusively with C, since a good number of programs (and the kernel) are C. However, I am looking for a high-quality book about Linux programming with C++.
I have a good C++ book that covers the fundamentals of OO programming and the language, but I would like a book that is a bit more Linux-specific. Makefiles, QT, gtk-- (perhaps), database programming would all be nice. I have seen QT books, but I am looking for something a bit more general/comprehensive. Any recommendations?
"The universe seems neither benign nor hostile, merely indifferent." --Carl Sagan
This sounds to me like a "shovelware" book, albeit too late to have any impact on anything other then the trees that died to print it. Do they pay the authors of these tomes by the pound?
I wrote some of Professional Oracle 8i Application Programming, and was paid by the page.
The fact of the matter is anything Unix programming related or C related has been done already and done well. These attempts to cash in by vendors like WROX (and their ilk, like QUE) by slapping "Linux" on the cover are just that, attempts to cash in.
Unix and C, perhaps, but there are all the layered products to consider also.
What I really want to see is a book that assumes you know how to sling code, but addresses the specifics on how to become part of the coding community.
I've seen lots of lists that say:
0. Get the latest version of the code from CVS.
1. Read and understand the code.
2. Make changes.
3. Send your patches to the maintainer.
4. Hope they get accepted.
There are a lot of programmers out there who don't have the minimum set of knowledge to perform the admin part of steps, but do have the technical know how to write solid code.
How many people have code but don't know how to set up a good makefile, but could if a decent template were explained? How many people would like to have configure scripts, but aren't sure how the magic works? How many people aren't sure how to put their code in CVS or upload it to SourceForge? How many people want to know how to build packages, whether by RPM or some other means? How many people don't know what questions users need answered in documentation, nor how to put it in a man/info page?
Simply making a breadth, but shallow, offering consisting of nicely printed man pages that are indexed hasn't helped much. It'd be nice if someone took a simple project and followed it end-to-end.
(At serious risk to my inbox, if enough contributors send me suggestions, tidbits, or the process as _they_ see it, I'll make a decent effort and putting something together.)
These books always try to cover too large fields. I guess reading the title is enough to realize that. I have bought a couple of programming books like this one, and they are always very interesting. But they never go in to the depth of any area, so it's quite impossible to acctually learn any real programming from them. So, it usually ends up with the fact that I'm finding the information I wanted where I should have looked in the first place, on the web.
"What kind of working business-model is that"
Clearly a business has to pay as much as is neccesary to hold on to their developers. In some cases though, that amount just happens to be zero and the developers are very happy with that.
The child workers you talk of are NOT happy with their level of pay. Many of the developers whose code gets used by Redhat etc earn money in other ways.
It seems (correct me if i'm wrong) that you have this idea that all useful work MUST be financially compensated else it doesn't "work"
Well, in my mind that is nonsense. Financial compensation is something that is only neccesary to provide a motive to get people to do things that otherwise nobody would do. It just happens to be the case (sadly) that this currently includes almost everything.
You don't have to "compensate" me for writing code in the same way that you don't have to for playing football with my friends. I do both for fun. It just happens that one is useful to others without any extra work from me and instead of trying to keep it all to myself and extract as much money from everyone else as possible using strict licenses etc, I chose not to be greedy.
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
What do you mean by work? If the people doing the work and happy and the people using the products are happy then it works. Who else matters?
I think a business that works can be pretty clearly defined as one that survives. A business can't lose money and survive; if it does, then it's not a business. It's a church or a dot com or something.
The socialist ideal (don't flame me yet!) of a world in which we all work for love and money isn't important is a neat idea and all, but that's not the world we live in. In order to live, I have to make money, because despite my constant protestations to the contrary my bank won't give me my car and my house for free. Can't understand it myself. I explained to them how residences and transportation should be Free (as in libre) and free (as in gratis), and I forwarded them some of Stallman's writings, but they just don't seem to get it.
So I'm stuck being a part of this whole "economy" thing. Therefore I must wedge myself into a situation in which somebody gives me a fairly substantial amount money on a regular basis. We call these situations "jobs."
Jobs are provided by companies to people based on the premise that the company will be able to take more money in than it gives out. Come to think of it, maybe that's why my house wasn't free....
Anyway, if the company that pays me (say, Red Hat, although it isn't) gives out more money than it takes in, eventually it will run out of money. The people who work for the company (say, Red Hat) will be faced with the sudden, unpleasant realization that their houses aren't Free (as in libre) or free (as in gratis). They've gotta find another one of those "job" situations so they can make their mortgage payments.
Poof. The company (say, Red Hat) disappears.
I'd say that's how I define "works." If it doesn't do what I just described (the "poof" part), then it "works."
I want nothing from you. Will e-mail my bank acount #. Or my snail-mail address, if you prefer sending a check.
nobody's ever done a cost-accounting for, say, Red Hat Linux
Linus's spare time cost nothing to Red Hat. What he does in his spare time is his own choice. Compared to other alternatives, creating software is one of the less costly ways of spending one's spare time. And the pleasure of having created one of the most famous softwares in the world surely brings as much "profit" as, for instance, surfing a "perfect wave"?
What the business model studies fail to take into account is that open source software goes both ways. A company that develops it may not be able to recover some costs directly, but, on the other hand, that same company may also use free software created by others without paying anything for it.
To my knowledge, nobody's ever done a cost-accounting for, say, Red Hat Linux 7.2.
Actually, a cost accounting like that was done, once, but I can't seem to find it anymore. It was very interesting; showing how many lines of code were produced by GNU, how many were in the kernel, how many were in X, and so on. It included an estimate of the cost to produce "Linux" (i.e., a GNU/Linux system). I'm guessing it was based on an earlier version of RedHat, like 7.0, or maybe Debian.
Secession is the right of all sentient beings.
"Do they pay the authors of these tomes by the pound? "
Almost. I wrote a few chapters for an "Unleashed" Linux book by Sams which they canned unfortunateley, and they pay by the chapter which has to be around the 20 page mark (given a standard font, ruler settings etc.). They don't pay very much either - it was about $600/chapter back in 1999 (and they never paid anyway)and it was taking me about a week to 10 days to do one - as it's not like you're just offering your $.02 in a web forum - every claim, and fact has to be checked as much as possible.
Yes indeed - C is still C when it's in a Linux environment. I think there is a place for these "lets cover everything" books but I think it's more appropriate at the "introduction" end of the market - I have a copy of Wrox's "Beggining Linux Programing" and its good - I still look in now if I need to see how to do soemthing simple in a language I don't really use that often - say like "what's the syntax of an if statement in Perl then?" a quicj flick through to an example will often provide the answers.
Yes - the funky animal books are more in line with what I want: just the facts.
I've got this book, and actually read quite a bit of it. My only complaint is that it's too big to effectively balance on your desk and work with next to a computer. Maybe I just need a bigger desk.
On the other hand, it sure would be nice to have this in a 3 or 4-volume boxed set. I'd pay a few bucks more for that format -- smaller (300-400) page books are a lot easier to handle.
"But actually trying to use m4 as a general-purpose langage would be deeply perverse" --ESR
The study was of Debian Potato (stable) and it's here.
A quote for the impatient:
It is also shown that if Debian had been developed using traditional proprietary methods, the COCOMO model estimates that its cost would be close to $1.9 billion USD to develop Debian 2.2..
Note that Debian stable is very conservative and now quite out-of-date. I hesitate to think how much unstable, or something like Mandrake, would have cost.
What the business model studies fail to take into account is that open source software goes both ways. A company that develops it may not be able to recover some costs directly, but, on the other hand, that same company may also use free software created by others without paying anything for it.
Net economic result: zero.
Which explains why lots of people believe it's impossible to make money in Free Software.
Of course it bends light, all masses do so.
:-)
As it's only a book, though, I would challenge anyone to measure the effect it has on a passing light ray
</physics nerd>
Cheers,
Tim
It's official. Most of you are morons.
Thank you! I was hoping some kind soul would post the link.
I also see a link to this, which may be the article I remembered. Both are very interesting.
The practical upshot is that Linux (the system) represents more than a billion-dollar development effort.
Secession is the right of all sentient beings.
If you'll check the articles mentioned in the post below, you'll see that six million dollars is a few orders of magnitude too small.
Secession is the right of all sentient beings.
...that's about the size of the typical introductory C++ book these days, isn't it?
There were indeed some deadline issues, which makes it difficult to generate a flawless product.
This is going to be a problem with any situation where there is urgency in getting the book pushed out. Donald Knuth may have the "clout" to get Addison Wesley to wait for him to be happy with the results; that is definitely not going to be the case for these sorts of books with garish red covers.
If you're not part of the solution, you're part of the precipitate.
I co-wrote Pro VB 6 XML for Wrox, and choose royalties. (Paid better, long term, than the flat rate!) If you're writing just one or two chapters for a book you're likely to be offered only flat rate, which is per page. But the editors don't encourage cruft.
Also, I don't think Wrox is merely trying to "cash in", though they are in business to sell books. The folks I've dealt with are sincerly interested in developing atttention to Linux and open source development.
Java is the blue pill
Choose the red pill
I have bought a couple of books o the 2" type. Judging by those, I have simply concluded that no book thicker than 1" (OK 1 1/2" if it's hardcover) is worth reading.
The best book I've (re)read recently is _The AWK Programming Language_, which I bought for 1 buck at a library sale of old books. I wonder why a library would sell such a classic, but now at least it has a loving home. This book is 220 pages including index and content listing, and quite a bit can be learned from it - and it is a joy to read. I look forward to the day I dig up a copy of _The UNIX Programming Environment_ in a heap of cheap books.
Small is beautiful!
-Lasse
All mass warps space, so it doesn't matter if the book was one page or one million pages -- it would still bend light.
:)
Of course the detectability of it spacial warp is dependent on total mass, perhaps that is what was meant by the author of the book?
--Pete
This is part of the "telephone book" trend. Because C++ is popular, there are a lot of heavy C++ books written by incompetents. I wonder if they think anyone's going to actually read all of those pages ?
FYI, if you're looking for a more concise, yet readable intro to C++, see "Accelerated C++", Koenig and Moo. The book is 300 pages long, and it covers all the essentials. Accelerated C++ has introduced iterators, exceptions, std::string, std::vector and std::list by page 100, whereas most books are still explaining if/then at that stage.