Professional Linux Programming

WrinkledShirt contributed this review of a Professional Linux Programming, a tome he says can "bend light" by its sheer size -- 1155 pages of multi-author, multi-language instruction and examples. Read on for his thoughts on the book's shortcomings as well as its strengths, and remember, lift with your knees, not with your back. Professional Linux Programming author Neil Matthew, Richard Stones, et. al. pages 1155 publisher Wrox rating 8 reviewer WrinkledShirt ISBN 1-861003-01-3 summary A brilliant book for anyone wanting to gain new Linux programming skills.

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 Good

This 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-Good

Typos. 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.

Conclusion

There 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 Introduction
Chapter 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.

Comments

Want a brand new car for free?

[Anonymous Coward]

Our car-manufacturing company has developed a new revolutionary business model for making cars.

We give away the cars for free and then we sell services for those cars! If you want to we can clean your car, wax it or you can use some of our other services.

We get cash from a couple of VC's, the rest of them simple don't "get it". If we need more we just call "the suits".

Re:Want a brand new car for free?

[rapid prototype]

yes, the parent is a troll, but hey, if i've seen this troll once, i've seen it a thousand times.

just so you know, comparing a linux company to a car company is ver different. it takes very marginal resources to produce another copy of linux (cost of a CD), whereas building a car takes an investment of thousands of dollars. giving away 50 cents of plastic and selling services is a lot different that giving away $10K of plastic and steel.

not that i think that a linux company business model works, but hey, i'm tired of seeing this same tired troll.

-rp

Re:Want a brand new car for free?

[foobar104]

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.

Re:Want a brand new car for free?

[Anonymous Coward]

I think Redhat more than anything shows that the model really doesn't work, it includes a massive amount of uncompensated work.

The only thing that stops them from going bancrupt right away is that their "businessmodel" includes lots and lots of free labour that aren't compensated.

If the thousands of people was compensated you would see a massive minus in their accounting and they would be out of business tomorrow.

This shows that the gnu ranting about that peogrammers will get paid in the end anyway is just bullshit. If it's income produced from something you can pay people to do that, if it isn't you can't. They aren't paid and can never be if Redhat wants to survive, plain and simple.

Re:Want a brand new car for free?

[MartinG]

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?

Re:Want a brand new car for free?

[Anonymous Coward]

I think what he ment is that income-costs must be greater than zero. This makes up a working businessmodel. If it's lower than zero they will die.

A working business-model should also include paying everyone involved fair. Redhat includes lots of free labour. What kind of working business-model is that? "We barly make it but just thanks to the fact that we don't pay thousands of people", thats not a very nice development. Similuar to Nike and their use of childworkers in Pakistan but worse.

Re:Want a brand new car for free?

[Anonymous Coward]

"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. "

Actually I beleive that making a expensive luxury car in the $50 000 range costs about $3 000 - $4 000 so it sure isn't much. A $25 000 car costs about two grand to make. The usual costs for making a car is a bit below 10% of the sale price.

Intels top-of-the-line processors costs $20 or so to make but you buy them for $500 or so. Your typical stereo or freezer or whatever costs just a fraction of what you buy them for to make.

Despite that this may seem like a huge overprice those companies sure hasn't profit margins like 99%. Intel has negative cashflow (right? I'm not 100% sure) right now. It DO costs lots and lots of money to develop new products, test them for safety and so on.

Software isn't really any different. Just like everything else the value is mostly in the research&development (and marketing) of the products.

People just don't seem to realize that "intellectual property" is the major costs of ANY product these days. But hey, this isn't bad! Thats whats make the people valuable and if you ask your gandfather I can bet that he will tell you how the workers situation was then the valuable wasn't in the worker but mostly in material and machines. It was a good bit worse than today. The worker has never been to valuable as today.

Re:Want a brand new car for free?

[Anonymous Coward]

"tens of millions of dollars spent to conceptualize and design that car model. "

The money spent before a single example of a car is sold is typically easily a good bit above $100 Million. The huge amount of people engineering&designing each part, testing for security and so on, not cheap at all.

This applies to basically all products, not just cars and software.

Re:Want a brand new car for free?

[Anonymous Coward]

The worker has never been to valuable as today.

Except for the 99% or so of the workforce that doesn't produce any intellectual property and who have generally seen their standard of living decline since old grandpa's time. I guess you forgot about those people.

Re:Want a brand new car for free?

[MartinG]

"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.

Re:Want a brand new car for free?

[foobar104]

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."

Re:Want a brand new car for free?

[foobar104]

MODERATORS: Please spend a point on the parent of this comment. It was written by an AC and probably won't get read by many people. That's too bad.

Stupid "can't comment and moderate in the same topic" rule....

Re:Want a brand new car for free?

[mangu]

The cost of the materials and labor that goes into producing a single car is nothing

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 ... going all the way back to Linus's spare time.

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.

Re:Want a brand new car for free?

[jdavidb]

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.

Re:Want a brand new car for free?

[Anonymous Coward]

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.

Re:Want a brand new car for free?

[Anonymous Coward]

It's here.

Re:Want a brand new car for free?

[foobar104]

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.

Re:Want a brand new car for free?

[Coz]

A difference in the analogy - regulation.

Nobody has to crash a Linux distro to prove that it passes Federal standards for front, side, and rear collisions (although the SSCA would be similar on the software side). Very few software companies will be threatened with class-action lawsuits because their software design exploded in a rear impact (the Pinto distro, anyone?). There's no Corporate Average Software Efficiency requirement that the operating system be able to perform 25.5 MFLOPs across a variety of loads, applications, and system configurations.

So the relative scale of procuding a single additional instance of a car may be comparable to the scale of producing a single additional copy of a Linux distribution, or other free software - but the cost basis is very, very different.

Re:Want a brand new car for free?

[ClosedSource]

"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."

What about all the money that AT&T invested to develop Unix?

Re:Want a brand new car for free?

[jdavidb]

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.

Re:Want a brand new car for free?

[jdavidb]

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.

Re:Want a brand new car for free?

[Anonymous Coward]

You are describing something very important, and thats the third world situation. You are right, most people in the world are not valuable, and thats bad.

But what solution do you suggest? That we destroy our evolved business (where the individual is important) and go back to the time when the capitalists where the only ones important or that we try to lift up the rest of the world and let machines take over work that people should not be forced to do?

Re:Want a brand new car for free?

[King of the World]

and who have generally seen their standard of living decline since old grandpa's time

Back in my day, sonny, we didn't make it out of our crib without some disease, spitting and following us. You don't know how good you have it.

Re:Want a brand new car for free?

[Anonymous Coward]

According to RMS the developers will get paid to develop open source software.

So I guess we means that those developers have been paid 1.9 Billion dollars?

is it me...

[Anonymous Coward]

... or has Slashdot recently turned almost strickly a Linux, Mac and anti-microsoft news source? Is this all that's being submitted? Or all that's being approved?

Re:is it me...

[Anonymous Coward]

... or has Slashdot recently turned almost strickly a Linux, Mac and anti-microsoft news source?

That's about what it's always been. Slashdot is run by Linux users and a large part of the reader base uses Linux. Lots of Linux users use it because they don't like what microsoft has to offer. It's always been this way. If you don't like it, find another source for your news.

If you just want news, try http://www.cnn.com/, or http://dailynews.yahoo.com/. If you want another "weblog" type thing, you can check out http://www.kuro5hin.org/, although their main reason for existence seems to be patting themselves on the back for not being Slashdot and for long winded posts that try to sound educated.

Re:is it me...

[Anonymous Coward]

Or if looking for Microsoft news, try MSDN. Gee, it looks like you can even discuss stuff with your fellow Microsoft fans, just like on Slashdot! Enjoy.

Re:is it me...

[yeOldeSkeptic]

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.

Re:is it me...

[ergo98]

Slashdot is run by Linux users and a large part of the reader base uses Linux.

And an ENORMOUS percentage of the user based DOESN'T use Linux, but rather uses *BSD, or egads, Windows. Some people who've done link tracking from links referenced on Slashdot have noticed >75% of referred users running IE on Windows.

Lots of Linux users use it because they don't like what microsoft has to offer. It's always been this way. If you don't like it, find another source for your news.

Funny to see this after another story not long ago about how the Internet brings people of all types together so that we can debate and share knowledge, when the reality is, as you pointed out, that people usually want to get together with people with the same extremist views and perspective to bitch about how dumb everyone else is and how they need to be enlightened, and how the USPO is evil for letting Microsoft pay them money to advertise. Blah.

Re:is it me...

[Anonymous Coward]

It's "News for Nerds. Stuff that matters"

Not "News for Linux Dorks. Stuff that matters only to fuckwits."

A bit of balance is in order.

Re:is it me...

[xg0blin]

Or is slashdot owned by VA linux. Do you expect them to advertise for Microsoft?

Re:is it me...

[Jonathan C. Patschke]

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?

Perhaps not in this forum, but if anyone really wants a good Microsoft tech forum, take a look-see on Microsoft's public news server: msnews.microsoft.com. Every Windows-oriented weblog that I've seen is utter crap (Including the MSDN comments forums, which are usually strewn with comments like "D000D! I d0wnl0aded the lat3st DirectX SDK, and why aren't my games any faster?").

The really ironic (or perhaps intentional?) thing is that most Windows-weenies don't even know what USENET is, yet MSCE volunteers are giving the absolute best tech advice on newsgroups sponsored by Microsoft. The signal-to-noise ratio is probably about equivalent (or better) to any random c.o.l group.

Blank Errata Page, eh?

[IIOIOOIOO]

Well, I'm sure the reviewer sent in a nicely documented list of all the errors he found while doing his review. I mean, that IS how they build those errata pages up. Or perhaps he, like most other elitist developers, simply sneered at the error and continued on his merry way?

Obviously a great book!

[danro]

This is obviously a great improvement over most computer related books on the market.
Java In A Nutshell never really cut it as a paperweight, and my dead tree in-pile has grown a lot lately.
This book will be a great fix, since all those pages (and the spaces inbetween) will keep an almost infinite number of cheets of paper, scraps of paper, postIt notes and the like in place.

A elegant solution to a complex problem.

Re:The title is an oxymoron

[Anonymous Coward]

ever become professional if we don't succeed

Which "we" are you talking about?

Linux already is "professional" if by that you mean "suitable for use by professionals"

View from 30,000 feet

[McSnickered]

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.

Re:View from 30,000 feet

[sketerpot]

I think maybe the scope was a bit too big and they should have covered fewer subjects in greater detail.

There are plenty of books and web sites that go into specific topics in as much detail as you could want, and often more. These books are good for giving a very broad overview of lots of things, and teaching you a little about everything and making it easy for you to get into more detail if you like from other sources.

In other words, I like this series. :-)=-

Re:View from 30,000 feet

[McSnickered]

Your point is well taken - I like the series too. But the strength of Beginning Linux Programming is that it doesn't try to cover the world of programming. It covers fewer topics but gives more than just a cursory glance at what xyz can do, and subsequently gives you enough to get you started and also keep you going for quite a while.

Re:View from 30,000 feet

[Anonymous Coward]

If you really are beginning Linux programming, you could do a lot worse than Stones' Beginning Linux Programming, the book which got me started with all the things you need to get started with, like shell script programming and using GNU make.

"Proof-of-concept-level" familiarity is often all you need as a programmer to get you over the wall of unfamiliar terminology and concepts into the enchanted garden of whatever technology it was you were thinking of embracing. After that, you can pretty much teach yourself (with the help of the odd O'Reilly production), up to the point where it makes sense to go and find something seriously black-belt and in-depth to help you consolidate what you know you know and point out the things you didn't know you didn't.

This book is definitely on my list of titles to check out...

Its a damn fine book.

[Richard_at_work]

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.

Re:Its a damn fine book.

[joyrider]

I heartily agree - I definitely recommend visiting the Wrox forums if you're interested in any of the subject areas their books cover. They do have a slight Microsoft bias in terms of available forums, but there's a fair few Linux-related ones too.

Undocumented Linux in 21 Days Unleashed Black Book

[mintoman]

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.

Is it me or?

[funkman]

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

Re:Is it me or?

[Masem]

If /. was, say, a professional computing site/magazine, I would simply chalk it up to that... I've yet to see such a site given anything less than 'average or above' reviews, save for once in a while when they really slam a product.

Here, I think because we have readers submitting book reviews, the reviewers are buying and reviewing books that would be of interest to them, and because of that, most of these books would already rank somewhat average-like because of the content. In addition, the reviewers have the ability to pre-review books at a store...if they're considering a book based on title alone, and open it up to see crap, they're not going to buy it nor review it. Thus, because these non-professional reviewers are only buying books that will already have some interest to /. reading in content and quality, I would expect very very few "less than average" books to be reviewed.

Maybe /. ought to solicate some of these reviewers with $40-50 and ask them to go out and review a book that most here would expect to be crap, just so that we see what those reviewers say about the opposite end of the spectrum. Or maybe the reviewers should consider that a 0-10 scale on /. is not the same as a 0-10 for any book review, as our bottom rung would probably fall around a 3 or 4 on a normal scale, with our average expection (our 5) being a 6 or 7 on the unadjusted scale.

Re:Is it me or?

[ec_hack]

Or is the Book Review going to turn into here is the latest above average book we have reviewed

Some periodicals don't want to print negative reviews. One editor at a local paper said she had limited space and more reviews (and books to review) than she could fit, so she just printed the positive reviews. Her attitude is that it is better to promote the good authors than warn against the bad.

I think she may be right. Remember Sturgeon's law: 95% of anything is crap. Finding the pearls is a more difficult task and more valuable service.

Re:Is it me or?

[wrinkledshirt]

I gave "Teach Yourself UML in 24 Hours" a 5.5 rating. That was only two book reviews ago.

To be honest, the rating is a bit of an afterthought. The first book review I did for Slashdot had a rating assigned for me.

It's easy to say whether or not a piece of work is good or bad. It's much harder to evaluate it in terms of who it would be helpful for, since all but the crappiest of the crappy books are helpful to somebody. Not speaking for other reviewers, but I try to read the book and review it in terms of what the book is trying to be, who it is geared for, and how close to success it gets.

Re:Is it me or?

[God_Retired]

I've yet to see such a site given anything less than 'average or above' reviews

Not about books, but The Filthy Critic does call movies the way he sees them.

Re:Is it me or?

[Doctor Memory]

Just flipping through the book in the store before I buy it generally weeds out the bad books, so I would assume most of the 1- or 2-rated books never get purchased (at least not by savvy Slashdotters).

Now if they had magazine reviews, I'd drop a dime on the new XML Journal. That's definitely a 2.

Re:Is it me or?

[Anonymous Coward]

This is not the first time this complaint has been made. I will say the same thing now that I said then. There are very few books that truly deserve an unqualified excellent review. They tend to inspire reviewers to say so. I don't need to encourage people to review those. However, if you have read a bad book lately, scream about it here. Review it. Give it the 2 it deserves as an exercise in damning with faint praise.

Also, if you have read a book that would be worthy of an 8 or better but is marred by some horrible, disfiguring flaw, give it a 5 and say why. For example, an excellent book with sample code that is just too full of typos to be used at all would be a good candidate for this kind of treatment.

Re:Is it me or?

[kubrick]

Thus, because these non-professional reviewers are only buying books that will already have some interest to /. reading in content and quality, I would expect very very few "less than average" books to be reviewed.

And those ones that are reviewed and given low marks are more likely to be a public safety warning than anything else.

e.g. "I bought this book, please don't make the same mistake..."

true but,

[Anonymous Coward]

it's gotten a lot worse lately. Sure the all the DOJ stuff going on with Microsoft has created news on both the Linux and Microsoft sides but come on, it's not the only news going on out there.

Re:true but,

[dattaway]

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.

Typos

[jargoone]

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.

Re:Typos

[foobar104]

I think a certain number of typos in a book that I pay for should allow me to receive a refund.

Knuth still offers a bounty for every error-- typographical, factual, logical, whatever-- found in any of his books. If I recall, the bounty for errors in TAOCP is up to $2.56 per item.

The result? Pretty damn near error-free books. Go, capitalism.

Re:Typos

[(H)elix1]

A close friend of mine wrote a Perl book that was published by one of the biggies. He figures he made well under minimum wage for the time spent - not one of those template style books for sure.

Anyhow, there were a few fubars on his part, but the editors(?) introduced a lot of bugs in the code when they horked around with the format. Deadlines prevented a solid review of the changes. A second revision fixed it, but just like us in the field - some times you have to hit a deadline.

It was a hoot hearing him sigh that while the second revision was "patched", he liked the artwork on the first revision....

Re:Typos

[gorilla]

It's mainly symbolic though, since very few people who actually get a check from Knuth cash it.

Re:Typos

[Mignon]

A close friend of mine wrote a Perl book... but the editors(?) introduced a lot of bugs in the code when they horked around with the format.

They would have done even more damage if it had been a Python book.

Re:Typos

[ADRA]

What industry are you in?? Nobody assumes a flawless product anymore. I know that it can be frustrating being mislead by what a book or document is saying, but if you are reading this particular book, you should have the empirical insight by this point to figure out what is wrong.

Re:Typos

[Brummund]

Maybe they saw some Perl code, thought the author had fell asleep on the keyboard and corrected it. :)

Re:Typos

[haruharaharu]

since very few people who actually get a check from Knuth cash it

Yeah. I'd frame mine.

Another slunk of dead tree for the shelf

[CDWert]

I love paper, the kind you can dog ear, fall asleep with over your eyes when the light gets too bright, and if trapped in a snowstorm use as kindling.

I have had acouple of the MONSTER programming volumes for years, there are great for refrence, altohug admittedly Ive never read a monster like this cover to cover.

Looking at my bookshelf, well, I can honestly say I am single handedly responsible for the deforestation of the Amazon, oh well, call me a collector of things paper......

Re:Another slunk of dead tree for the shelf

[Chan]

One of the problems with the monster references is you probably shouldn't fall asleep with it over your eyes... A paperback novel, okay. A QUE or SAMS dictionary-sized book could be dangerous.

Re:Another slunk of dead tree for the shelf

[motorcrash]

I guess I hadn't thought of it before I read your post, but perhaps Amazon is responsible for the deforestation of the Amazon.

Oh, the irony.

Oh, the obvious joke...

This book was published 16 months ago

[Anonymous Coward]

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.

Exactly how is a review of a 16-month old book newsworthy?

<Grumble><Moan>

Re:This book was published 16 months ago

[psykocrime]

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.

am I the only one

[Syre]

Am I the only one who thinks this is rather transparent marketing on the part of slashdot?

Notice the link to Fatbrain.com... it has a "from" parameter, which almost certainly gives slashdot a kickback for any purchases.

Without that link, I still might suspect product placement, but with it this article counts mainly as an advertisement, it seems.

Re:am I the only one

[Syre]

or maybe it's just a book review.

nevermind. I need to go to sleep.

Re:am I the only one

[Eric Gibson]

Am I the only one who thinks this is rather transparent marketing on the part of slashdot?

No, and I applaud Slashdot for taking on the entrepreneurial spirit and helping our capitalist society move along smoothly by using sound, honest business practices. This was a well thought out review, with good points and bad points for people that might be interested in buying something. This is nowhere akin to some obviously biased ZDNET review of some Microsoft product. What's more, it's written by a Slashdot member who thought he could share his thoughts on this subject. Anyhow he explicitly states whom he believes this product would help, and sent his review to slashdot because it would reach the largest target audience. What, so you don't believe slashdot should be trying to make money? Do you think Slashdot should host this site for your amusement and live in boxes to make sure you're false idealism is satisfied? Welcome to the real world you communist, hippie-dumbfuck.

Re:am I the only one

[Anonymous Coward]

It's $8 cheaper at amazon.com....

The NEW DOORSTOP IS HERE!!!!

[CyberGarp]

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.

Re:Undocumented Linux in 21 Days Unleashed Black B

[Geeky]

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...

Re:Undocumented Linux in 21 Days Unleashed Black B

[dattaway]

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.

A plethora of similies

[saider]

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.

feel free to submit your rated-2 and -3 reviews :)

[timothy]

Remember, Slashdot book reviews are submitted by people who read the books and jotted down their thoughts.

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 :) 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.

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.

typos = training tool?

[simetra]

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.

Re:typos = training tool?

[Anonymous Coward]

The comments from simetra entitled typos = training tool? are total bollocks...... everyone who writes in to us gets a response. He/She was probably told we don't give out free books to everyone who writes in with errata - if we did that we'd have no inventory left!! :)

Re:typos = training tool?

[The Biker]

I'm not sure where you sent your email about errata to Wrox, but everyone writing to support@wrox.com gets a reply. Wrox do not provide free books to readers submitting errata. If you find an error in one of our books like a spelling mistake or a faulty piece of code, we are very grateful for this sort of advice and feedback. By sending in errata you may save another reader hours of frustration, and of course, you will be helping us provide even higher quality information.

Re:typos = training tool?

[jrockway]

Great. So you can make more money at my expense? Thanks. I'll be sure to help you, your highness.

Re:typos = training tool?

[simetra]

That would be a LOT of work... without any compensation? No thanks.

Oh, I did get a reply, saying something like it'll be forwarded to someone concerned, blah blah blah, but I never heard back after that. Oh well.

Re:typos = training tool?

[mugnyte]

But in the payment for the book is supposed to be the money for this effort. You are assuming once it's published that no more work should be paid for its correction?

Publishing errors, then not rewarding those (IMHO really helpful) readers who submit corrections are the 2 best ways to drop a book review from a 8 to a 7.

Re:typos = training tool?

[Anonymous Coward]

I was contacted on a Linux programming book by Wrox to do technical editing. They wanted it done over a single weekend! In addition, they were sending me the galley as an MSWord document and I had to make corrections with the comment feature of MSWord. Needless to say I turned them down.

Re:First "First Post" discovered!

[rednuhter]

login so I can be-foe you !!!

I never did like Wrox

[hardburn]

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").

Re:I never did like Wrox

[Anonymous Coward]

ummm, not so much anonymous coward as lazy basta*d (i work for wrox)

firstly let me say that i guess 250,000 people disagree with you about beginning java - i learned java that way and it was way better than any other bookstop.

i guess to reply to some other criticisms - the proof reader is not drunk - typos are the editors fault so blame the editors. you should be seeing improvements in that area in later books.

what else? tomes, i have some bad news for you guys propping up your tables with our books, we are going slimline. A lot of the newer books are going to be slimmer, though hopefully with the same code intensive material that you see C&P into code here there and everywhere. For me thats what made WROX books the best, the ability to use the code straight out the books (althoug albeit with error checking introduced) and is why I applied for a job here

Re:I never did like Wrox

[lelitsch]

I wouldn't say generally. Some of their Java tomes are horrible, and I didn't especially like their first edition of Beginning Linux Programming as a beginners book. Mainly because a lot of the topics, techniques etc were at least five years out of date. And because they made odd choices what to cover like TCL instead of Perl/Python.

But their Professional series, especially Professional Linux Deployment, are pretty good if you just need to look something up and actually would like to see worked examples. For example, PLD is as far as I know the only book that actually takes you line by line throuh setting up Samba, or installing and configuring a ftp demon from scratch. While we are gerneralizing shamelessly, I like O'Reily or AW, but the first often decribes things in the same amount of detail as the help pages and AW usually turn the description of minor tasks into a 100 page CS class.

Re:I never did like Wrox

[Anonymous Coward]

The Beginning Java 2 book is pretty good in my opinion - if not for the content, then for the community support site at p2p.wrox.com. Remember, don't judge a book by it's cover, especially a Wrox book ;)

Re:I never did like Wrox

[ADRA]

Basically all companies make you buy a seperate book for references, hey some companies have two books just to cover the core API's. Usually how-to's are set for the total newbie in a given area, and the references for the day-to-day coder. You can maybe get by with the reference if you have the right mindset to learn that way, and there is usually a decent bit of how-to in references anyway.

I think you are too hard on wrox. I thought they really sucked to, until I actually started using them. The vast array of topics ina given field make it totally worth the money, IF you need the information. I have good eye sight, so the small print is actually more comfortable for me to read than other books.

Re:I never did like Wrox

[diddyland]

nope, I really liked Wrox books and I think the layout style is really clear

I esp. like
Beginning Linux Programming,
Beginning Visual C++
and a delphi book I had

Re:I never did like Wrox

[skribble]

I think they are generally inconsistant. (But who's not these days)

Re:I never did like Wrox

[boster]

When their books were just starting to hit the local shelves, I bought Assembly Language MasterClass. I was very impressed -- quite a reasonable book.

I was quite disappointed when I browsed through later books they published. They certainly didn't live up to the one I bought.

C is great..but looking for good C++ Linux book

[proxima]

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?

Re:C is great..but looking for good C++ Linux book

[Anonymous Coward]

Yeah, try reading the man pages and other associated tooldocs. Every one of the things you mentioned has extensive documentation online.

Re:C is great..but looking for good C++ Linux book

[Dominic]

You could do worse than Jesse Liberty and David Hovarth's "Teach yourself C++ for Linux in 21 days", published by Sams. There is also Tom Swans "Tom Swan's GNU C++ for Linux", published by Que (I think).

Re:C is great..but looking for good C++ Linux book

[proxima]

There is something to be said for a well-written dead-tree version in a comprehensive, tutorial form. If a tutorial online is longer than about 8 pages, I end up printing it anyway. I might as well have it been in a cohesive fashion and save myself the paper.

Re:C is great..but looking for good C++ Linux book

[obobo]

I don't know of a good Linux C++ book... C++ really isn't the default language for Linux, and it shows, especially in gcc and the standard library. It's gotten alot better in the past few years, but it still has a ways to go. Not to say that Windows is any better... VC++ is even worse (although the APIs are all there).

My advice:

Use the STLPort, not the GNU Standard C++ Library. It actually conforms to the spec, and has fewer bugs. This is huge if you're going to be doing multithreaded programming.

Use the Boost libraries. They're gonna be put into the next generation standard, and it is good stuff.

Databases: check out the OTL (Oracle Template Library) for interfacing with Oracle. I haven't done too much with other DBs. The OTL web page makes it look like a "make money fast" scheme, but it works, and the mainainer apparently has no life, and has nothing better to do than patch it whenever a user whines or Oracle changes versions :)

Makefiles: look at the man/info pages for "make", or look at the (old but still good) O'Reilly book on Make. There's really no difference between C and C++ there.

I haven't done much with GUI dev, so I don't know of a good ref for QT or gtk--. I can say that FLTK has good online docs, and is quite easy to use.

As many others have said elsewhere: the best documentation is usually on the project page for the tool you're interested in. Finding the right tool, though, can be hard.

Re:C is great..but looking for good C++ Linux book

[elflord]

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++.

You'll have a hard time finding such a book, and there's a good reason for this -- Linux books tend to document the POSIX and X/Open APIs. Basically, the traditional APIs are all C based. There are books for C++ libraries like Qt and KDE, but the Qt documentation is so good that you're better off just using the online version. If you're fond of dead trees, I suggest you print out the tutorials.

Regarding learning C++ on Linux, I'd suggest you focus on mastering C++ (BTW, one book is NOT enough. Not even close), and try to learn some of the C APIs. It's also interesting to try things like wrapping things in classes (eg Sockets)

Cheers,

Re:C is great..but looking for good C++ Linux book

[psykocrime]

There is also Tom Swans "Tom Swan's GNU C++ for Linux", published by Que (I think).


Yes, it is by Que. And it's a pretty good "Linux/C++ book", IMHO. I'd recommend it to anyone who wants a book that's specifically about C++ on Linux.

What no PERL ?

[hs81]

How can a book like this ignore Perl the "swiss army pen knife" for most linux programmers and admin people?
I'm always tempted when books like this come along but no perl = no buy. Though I suppose you could argue that there are so many online resources for Perl that this would be redundant.

Re:What no PERL ?

[McSnickered]

The Beginning Linux Programming book has a nice section covering Perl. But as far as I can tell, the Professional book covers mostly topics that weren't covered in the Beginning book. Such as MySQL, PHP, Qt, etc.

The Beginning book has great chapters on Shell script, C, Terminals, Curses, Semaphores, Pipes, GTK, Tk, Perl, and some other goodies.

Re:What no PERL ?

[Yokomon]

How can a book like this ignore Perl the "swiss army pen knife"

I thought that was "Swiss Army chain saw"...

Re:What no PERL ?

[dbremner]

Well, there's always the Camel and Llama books.

Re:What no PERL ?

[sketerpot]

Apparently this goes hand in hand with Beginning Linux Programming, which does give some basic coverage of Perl.

Or perhaps they assumed everyone already knows Perl....

Re:What no PERL ?

[Anonymous Coward]

We put Perl in the Beginning book, and people wrote to us saying "what's perl got to do with Linux"?

Re:What no PERL ?

[Anonymous Coward]

PERL is for FAGS. Go suck a cock you lameass wannabe coder.

Re:What no PERL ?

[Gurft]

One thing I've noticed as a professional Perl programmer is that most books that are compilations of skills only really touch on the absolute basics of Perl. The O'Rielly books have become the definitive guide, with a few other's floating around that have good resources. With perl you have CPAN, copious documentation online, perldoc, and perlfaq. Do you really need another chapter in some random book when there's huge resources already available?

Re:Undocumented Linux in 21 Days Unleashed Black B

[sql*kitten]

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...

[wls]

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.)

Re:What I really want to see...

[squant0]

I am only in Comp Sci 1 right now in college, but am starting to really get into Linux and once I DO know how to program would like to make a contribution to the "cause". But I haven't the faintest idea of how to. I would buy a book like this. I think you should go for it if you get more people to support you and publish something like this. As long as it doesn't weight more than me, I will go down to the local bookstore and buy it. A good manual that can be read from cover to cover and executed and then used as a reference would be great, especiall if it was under 200 pages, and in an easy to read format and well priced.

Re:What I really want to see...

[Black Parrot]

> 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.

Is there a companion volume for getting your stories accepted by Slashdot?

Re:What I really want to see...

[Anonymous Coward]

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.

I very much doubt that. The former is generally easier than the latter. If you think otherwise then you probably don't understand what solid code is. Knowing how to write "hello world", or even completing CS1, is not the same as knowing how to write solid code.

Re:What I really want to see...

[dylan_-]

Is there a companion volume for getting your stories accepted by Slashdot?

0. Read the front page of Slashdot
1. Wait till a story if posted by Timothy or Michael
2. Submit the exact same story, but with a different title.
3. Celebrate.

Re:What I really want to see...

[aziraphale]

Well, I'm flicking through my copy of PLiP now, (although you could of course find this out by reading the Table of contents given above) - and I find that chapter 2 (that's chapter TWO) covers using CVS. The reason it's covered so early? This is a book about developing open source software. It talks about using make, and even covers issues like documentation and distribution builds. It's all about becoming an effective member of the development community.

Re:What I really want to see...

[wls]

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.

> I very much doubt that. The former is generally easier than the latter.

I've written a number of various utilities and applications for the public domain. Some shareware was successful enough it still results in checks in the mail, some applications I personally witnessed in use by over 300 people each day over the course of four years, and many others have just faded away with time and platform changes. On the commercial front, I've written a lot of flagship products, directed development efforts, and been highly involved in QA and SCM. I like to think I can code my way out of a paper bag.

Naturally to do all those things, I've needed to know various languages, compilers, bug tracking tools, version control systems, build automation, and documentation. I like to think I've successfully been involved with much of the software lifecycle.

But, when I first dipped my foot in the Linux pool, I was trying desperately to map my prior experience from PC to Linux.

I knew Microsoft and Borland's C++, but couldn't get certain parts of the STL to work with gcc. Oh, that part was broken (it's hence been fixed).

I knew SourceSafe and PVCS inside and out and had been the CM manager of 70 people. Just mapping the terminology from those products to RCS/SCCS/CVS was a small barrier of its own when I first started. Things didn't help when the some standard CM tasks required implementation knowledge of CVS and tweaking the repository directly.

In corporate environments, we had access to the version control system directly; we were immediately responsible for the code. There was no need to generate patches for submission, or apply them.

In cases where the software wasn't designed to be portable, people never took that into account. The general philosophy had to change for Linux.

Tired of Microsoft's or Borland's make? Use OpusMake. Want to build an installation package? Use InstallSheild or another varient. Hard core debugging? Soft/ICE. Powerful tracing? Any NuMega product. Documentation? Word. PageMaker. FrameMaker.

But assuming I've got GNU Make, autoconf, RPM, gdb, LaTex, and a number other things under my belt -- everything has to be done in a way that's acceptable and receptive to the community.

The point I'm going with is this: there's a lot of untapped talent out there, because of the transitional Rosetta stone is kept too close to our chest.

We share our code, but not our process and techniques. We assume that just because people haven't cut their teeth on Linux, know GNU utilities inside and out, and know how to do things the way we do that they are neophytes. That needs to change.

If the Linux and OpenSource community wants to tap the knowledge and talent of the commercial world, we need to not just provide software tools and grass movement marketing, but we need to provide the intellectual resources as well.

Re:What I really want to see...

[Anonymous Coward]

Right on... and the problems you describe are the same problems regular people have when trying to get into the OSS community, etc.

There's an established way of doing things, which is efficient and makes sense. Everyone will tell you what it is, but no one will tell you *how*. Nice barrier to entry... This stuff isn't that hard, but there are *way* too many places to look to get either (a) useless overviews, e.g. "do procedure Q", or (b) far too much depth, e.g. "the problem with step iix.7634 in module phoenicia of tweakyFoo (part of procedure Q) is...".

Very few people seem willing to answer from this view: If you were an intelligent person without a background in subject X, what would you want to know? Perhaps... general procedures? Structure? How to search for help, and where?

Re:What I really want to see...

[wls]

My problem is that books that act like do-it-all toaster ovens are usually very incomplete in their depth. I have a number of printed resources that fall into this category on my reference shelves.

Let's use your CVS example and assume that I've been using PVCS successfully for a decade.

I want to make the switch from PVCS to CVS. So, I bought the reference card, the reference book, the O'Reily book, and an OpenSource book that covers CVS.

First thing these things tell me to do is seek out "the Cederqvist." Let's furthermore assume I get past this and realize it's the bible of CVS. I may run into another problem... how do I read a TeX file, a PS file, or such. So, let's assume I get past _that_ and have HTML, Text, or PDF. (There is implicit knowledge needed to perform a primitive level of fundamental tasks.)

Going straight to CVS's Cederqvist v1.11.1p1 -- section 1.1 tells us it's a version control system and it can record the history of our source files. This statement assumes we already know what we're looking at, have an idea of what the software does, and we're trying to learn the commands to it.

Back out a level... why would I want version control? What real world reason would make me want to use it? Many colleges don't address that, as many students don't work in teams for credit. They tend to encounter version control the moment they get assigned to a development team, and never having to do it before, they view it as overhead.

A good manual should show parallels to real world problems and solutions, in addition to documenting every featured option.

It's not until you get bitten in the butt by your own actions or those of your co-workers, that you start to see value in it. It's not until you use version control to identify and resolve a really hideous bug that you get an awe and sense of appreciation of it. It's not until you have to produce a production level patch that you get a sincere respect for it. And it's not until you start doing parallel development that you realize how much you should have had this back at day one.

By section 1.3.2 we see some examples -- we're shown the solution without knowing the problem it's designed to solve.

By section 2, on page 7, we're instantly in the guts of how the repository works. Details that never need be known -- unless CVS has limitations that we have to compensate for manually. Much later we learn this is the case. This goes on for pages and pages.

I'm glad the information is covered, but is this was a _user_ is looking for when he picks up a all-text 166 page manual and hits page 7?

As life goes on, we learn about tags and stickiness. We still are left to extrapolate why we need them. Life would come together in a snap if someone said "users of PVCS and SourceSafe may recognize sticky tags as static labels; the reason we use _these_ terms instead are...."

But just because you know what a tool does, or how to invoke commands doesn't mean you're using it right. There are at least five different kinds of branching I can come up with off the top of my head, depending on what goal you're trying to accomplish.

Anyone who's inherited a version control system and seen a branch of a branch of a branch of a branch of a branch and no one could justify why knows what I'm talking about.

Just as the argument is made that "because you learned the language doesn't mean you know how to program" extends to configuration management, too. "Just cause you know how to do CVS doesn't mean you know how to do CM." And this equally applied to using autoconf, make, rpm, LaTeX documentation, etc.

There are right ways, wrong ways, and the effective way. Let's be honest here, our admired gurus are gurus because they know not just how to play by the unwritten rules, but also when and how to break them.

What I really want to see is a book that doesn't discuss the tool, but discusses the real world best OpenSource practices, and uses the real tools we use as examples to teach it.

Re:What I really want to see...

[chromatic]

Karl Fogel's Open Source Development with CVS covers some of that. It's well worth reading.

Re:What I really want to see...

[Gummbah]

It's available online aswell.

A.

Re:What I really want to see...

[wls]

Actually, that was the book I was refering to. :)

It's got a fairly good CVS overview, then goes into a bit about OpenSource, and then hops to advanced CVS stuff.

Still, there's a gap -- what's the RIGHT way to use a tool. Or, assuming I now know CVS, how could this apply to SourceForge?

Show me a project, show me how you made a patch, show me how you submitted it.

Re:What I really want to see...

[p3d0]

This is a great idea. Here's two cents' worth of encouragement from me.

Re:What I really want to see...

[Arandir]

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.

I remember the first patch someone sent me. I was overjoyed that someone was actually using my program! Then I realized I didn't know how to apply a patch. So I patched it manually through cut-n-paste. Never again.

(at least I knew how to write a makefile rather than letting some IDE do it for me)

Re:What I really want to see...

[seanadams.com]

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?

I doubt if you've actually tried doing this stuff, and failed for lack of documenation. Yes, make, autoconf, etc are difficult programs, but there are many books and web sites on the topic. I'm sure if you allocated 8 hours and a 6-pick of Dew to the task, you'd get the basic idea.

CVs and sourceforge are *much* easier than they appear. There is a book called "open source development using CVS" which covers CVS in excruciating detail. If you want to learn CVS I'd suggest just diving in with the basic functions, and don't worry about learning how to use a more difficult feature (like branching) until you feel the need for it.

These issues:

1. Read and understand the code.
2. Make changes.
4. Hope they get accepted.

Are all specific to the project and the development community you want to join. I think that as you get into open development, you will most likely find that projects always want help, and they don't expect (or even want) everyone to be a seasoned hacker. If you're a beginner, lurk on the mailing list for a while, read the code, then introduce yourself. Read the bug tracker on sourceforge and see if there's any housekeeping you can do there, or any small bugs that need fixing. Send a diff against the current source. Or send a big diff. Get involved. Answer people's questions. Ask for CVS write access.

You're asking how to join a community. The answer is listen & learn, introduce yourself, make some friends, find something to do. It's no different than real life.

Re:What I really want to see...

[Anonymous Coward]

All this stuff is documented somewhere, you just have to know where to find it :) But I don't know exactly what you're expecting here -- all this is obviously not going to be found in one book. I mean, this story is talking about a book review for a book that's 1,000 pages, and one of the complaints is that it's "too sketchy". How long would a book be that covers all the stuff you're talking about, from basic user-level stuff (reading a PostScript file) to basic software engineering theory (CASE, revision control systems) to advanced programming stuff (making branches in CVS)? 10,000 pages? 100,000 pages?

For general programmer-level stuff, a good place to start would be Eric Raymond's Software Release Practice HOWTO. The GNU coding standards and maintainer information provide guidance for practices on the GNU project; although other open source projects will not follow all of these practices, they give you a good idea of how things are generally organized. Sourceforge itself has pretty good documentation. There are various guides to sending patches (the diff manual is also good reading for this). There is a book on autoconf. There are several documents on CVS; an interesting one is the CVS best practices HOWTO. It's fairly new (November 20, 2001) and still pretty sketchy, but perhaps it will evolve into a more complete best practices guide (the author is soliciting input, so this is a chance to contribute).

And, of course, nearly every Open Source software package comes with some sort of manual. (This contrasts with proprietary Windows applications, which seem to expect you to buy some sort of proprietary book on the side, in addition to the proprietary application you have already bought.) E.g., the the GCC manual, the GNU Make manual, the Perl manual, the Python tutorial, and so on. Although these are not always ideal for the beginner they will certainly be a useful reference to keep handy.

Re:What I really want to see...

[Anonymous Coward]

I'd buy that book. (As long ad it's less than 50 bux)

My view of this book

[Anonymous Coward]

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.

Typographical errors

[Anonymous Coward]

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.

Confusing tutle!

[Pooh22]

Twice I fell for the same mistake, $quot;Beginning/Prof. Linux Programming"

Linux is of course more than just the kernel, but the subjects covered in these books are mostly not Linux specific.
On the other hand, good books about beginning/advanced Linux Kernel Programming are hard to find or don't exist at all.

Or can someone recommend some good books on how to program (modules/networking/drivers) for the Linux Kernel?

Re:Confusing tutle!

[Anonymous Coward]

Rubini's book on drivers, pub by O-reilly, IIRC its got a horse on the cover.

Re:Confusing tutle!

[philkerr]

Have a look at:

'Index of Documentation for People Interested in Writing and/or Understanding the Linux Kernel'

http://jungla.dit.upm.es/~jmseyas/linux/kernel/hac kers-docs.html

This should keep you going for a few day's :)

Just another overview

[Joohn]

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.

Re:Just another overview

[elflord]

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.

The books are intended as a primer to get you up to speed, so that you'll be able to work with the reference docs once you're done with their tutorial. You won't find this much in the way of good tutorial material on the web. And in my experience, it works. I don't know why you're going to the web all the time, most of the stuff in this book has reasonable reference documentation.

when a rating is assigned ...

[timothy]

it's because the reviewer didn't include one ;) -- and it's (intended) to be based on what the reviewer seems to think about the book.

However, it's an oversight to have not mailed you on that one -- usually, this has happened only when reviewers submit a review lacking a valid email address. Many reviewers send in reviews that lack (nearly) all of the information in the table at the top of the review. (Not Wrinkled, though! :))

Admittedly, the numbers are somewhat subjective (even though they're *numbers* and people therefore try to assign them sometimes a great deal of objectivity), and obviously different reviewers have different takes on what a "5" means, or a "9" ... very few reviewers give "10" ratings, for instance. That's probably because it's like calling a restaurant "perfect" and thereby inviting greater scrutiny than if you'd simply callled it "very good" or even "superb."

If anyone would like to come up with a perfectly fair way to assign ratings, I'd add it to the book review guidelines, too ;)

Kernel programming books

[hardpress]

"Understanding the Linux kernel" and "Linux device drivers", both from oreilly, are very good references.

Heartily recommended

Professional Linux...

[TrollBridge]

These are two words that have no business being in the same sentence, let alone side-by-side. Shame on you, authors!

Size of book bends light?

[dzym]

No. Mass bends light.

Large size does not equate to super-massiveness. A nebula is not a black hole.

Size * density, on the other hand ...

Re:Undocumented Linux in 21 Days Unleashed Black B

[Scooter]

"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.

Too big, but otherwise good

[smoon]

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.

Re:Bend light, eh?

[Anonymous Coward]

Funny thing is though, that the books worth reading are ususally the thin ones. I'm thinking of things like The Pragmatic Programmer or Programming Pearls, computer books you can sit down with and learn something from. The best place for encyclopaedic refereces is the web, not on paper. Huge doorstops like this are physically uncomfortable to read (with my skinny geek arms, anyway), and never seem to contain as much real information as they do redundant code listings and repetition.

Oh, and 'Linux Programming' is meaningless, unless you mean stuff like device drivers and other kernel internals. How much of this stuff wouldn't work on *BSD? Most of it would probably work on any unix, and about half of it probably works on windows, too, these days.

Bends Light?

[Tim C]

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

Re:Bends Light?

[wuzzeb]

Well, the equation for the bending of light is
alpha = 2 * G * M / (c^2 * R)

R in this case is the distance of closest approach of the light, measured from the center of mass. G is the gravitational constant, c is the speed of light, and M is the mass of the object. Of course, this only holds if the object bending the light is a sphere, but approx. the book is a sphere. It will not affect the result that much :)

(g / c^2) is a constant = approx. 10^-27 m/kg

So the only thing we need to measure is the ratio of the mass to the radius...assume thats about .5 kg/m... that makes the angle the light is bent to be approx. 10^-27 radiens, which is really, really small.

To compare, the Sun has a mass to radius ratio of about 2.86x10^21 kg/m and thus bends light by about 4.2x10^-6 radiens, which is measerable. For the earth, m/r equals approx. 10^18 kg/m

Re:Nice, but.....

[Anonymous Coward]

How is that offtopic? It's Chapter 24 dumbass! Do the moderators even READ the articles?

1155 pages? Not that big a deal...

[jejones]

...that's about the size of the typical introductory C++ book these days, isn't it?

I'm gonna wait for the Computer Book BLOWOUT!!!

[ashitaka]

London Drugs (local discount pharmacy, housewares, computer store) is currently having another of their computer book sales where they sell off overstock they grabbed from somewhere.

Although a lot of the stuff is outdated (Win95 Resource Kit?, please.) much is suprisingly up-to-date and a valuable reference.

The fun part is paying C$9.95 for a book that has a list price of C$79.99 on the back.

Re:I'm gonna wait for the Computer Book BLOWOUT!!!

[Anonymous Coward]

"The fun part is paying C$9.95 for a book that has a list price of C$79.99 on the back"

Which simply tells you how overpriced books really are.

I have a couple of wrox books

[xg0blin]

I have the Beginning Linux Programming, and the one that came with visual C++. They all seem to be rather well written books. My only complaint about Beginning Linux Programming, was that some of the chapters didn't totally pertain to "Linux Programming". The chapters on TCL, perl, ncurses, bash programming, and these chapters were great and very informative (also gnome, gtk, etc. etc.), but chpaters like HTML. Come on, that's total filler. If the professional book is anything like the first one, it'll probably be a really good and informative book, all except a few chapters

This seems to be a familial weakness

[Anonymous Coward]

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.
This is exactly the reason I have, over the years, picked up a number of these Professional series books in the store, looked them over... and left them sitting on the shelf. They may all be as good in their own way as Our Reviewer says this one is, but they're too shallow to please me. Calling something with that sort of superficial coverage Professional bothers me, too.

Certainly the case with PLP

[Christopher B. Brown]

I wrote the chapters in PLP on CORBA, and found, when I went through it, there were some tpyos that I was pretty sure I had not introduced. (There was one place where it looks like someone rewrote some material; didn't read like something I'd write...)

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.

Slashdot author, complain about typos, really!!!??

[essiescreet]

anyone else think its (sic) ironic that a /. author would complain about a typo...

Re:Undocumented Linux in 21 Days Unleashed Black B

[JamesOfTheDesert]

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 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.

Re:Fool

[sdprenzl]

Why get anywhere near hatred of the Jew? Why not simply say, "I'm not Jewish. I therefore have no affinity to things Jewish."....and let it go at that? I think I know the reason why not. You are still preoccupied with the Jewish cult Christianity. Trying to be a Christian and distance yourself from Jews is like trying to breed a hairless dog: If you ever actually achieve such a "wonderous" thing, hey, it's all yours! You can keep it! But I like wolves....

Re:1155 pages? Not that big a deal...

[jjeff]

..that's about the size of the typical introductory C++ book these days, isn't it?

i dont know about a C++ book, but my "Perl - The Complete Reference" book is 1179 and thats not exactly huge.

Re:Undocumented Linux in 21 Days Unleashed Black B

[lahi]

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

Looking for Advice

[bedouin]

I've been playing around with Linux for a few years now, getting to understand networking and things of that nature. But I've reached the point where I'd actually like to create, specifically for Linux, since it's where I spend the majority of my time.

What would be a good book that would help me learn the basics of programming in Linux (this one seems to assume you already *know* a programming language or two). Should I begin with C? What about PHP and others? I'm looking for some specific titles.

Check out

[greygent]

Beginning Linux Programming by the same folks who wrote this book, Wrox Press.

Beginning Linux Programming could be considered Vol. I, and it covers all sorts of nifty little items, such as Makefiles, libs, headers, etc.

BTW, it's useful for UNIX in general, not just linux. I figure they used the word "Linux" in the title in the hopes of selling more copies.

Any mass bends light

[pmancini]

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

Re:Fool

[Anonymous Coward]

Yes, these matters are important to programming in Linux with its world-wide, multi-ethnic user base. One must take care in programming to take a stand on the Jewish question without seeming irrational, or worse, unclear. I for one find that being a Christian does indeed infect my programs with a Jewish bent that I cannot erradicate without denying my religious roots. However, I then wake up from my weird dreams and realise that I have been a dork all night.

Re:Undocumented Linux in 21 Days Unleashed Black B

[Arandir]

Unfortunately, the funky animal covered books on C and C++ leave a lot to be desired. They offer the world's best Perl books, but for compiled languages they are little more than beginners tutorials.

It's a shame because an O'Reilly "Programming C/C++" with the same comprehensiveness and quality of "Programming Perl" would rock.

Re:Undocumented Linux in 21 Days Unleashed Black B

[LatJoor]

I haven't read this book, but I have read Beginning Linux Programming, and heartily reccomend it, especially for those who are looking for a good bridge between reading books on ANSI C and reading online API documentation. However, I do agree with the "slapping 'Linux'" on the cover comment. In fact, the book frequently refers to the system you're using as 'UNIX' rather than 'Linux.' It seems like a UNIX programming book with Linux and the GNU tools used as the special case for all examples. This is actually a strength, though, because the book keeps you conscious of the X/Open and POSIX standards, reminding you that although your code might run on any Linux it's still better if it's portable to other UNIX implementations.

Lift with your LEGS, not your back

[MMHere]

In spite of the way this picture is drawn, I believe the correct saying is "Lift with your legs, not your back."

Sure, your knees are a sub-part of your legs, but if you lifted with your knees alone, I don't think you'd get very far.

Re:Another slunk of dead tree for the shelf-Weight

[Anonymous Coward]

With all the above being said. Are there any technical books out there on CDROM or DVD?

All the content without the weight.

Re:is it me...It's you.

[Anonymous Coward]

" Some people who've done link tracking from links referenced on Slashdot have noticed >75% of referred users running IE on Windows."

From work, no doubt.

Re:1155 pages? Not that big a deal...

[elflord]

..that's about the size of the typical introductory C++ book these days, isn't it?

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.

Release date : september 2000

[javaDragon]

It's nearly 1 1/2 years old. Is this a new edition ?

Re:1155 pages? Not that big a deal...

[ealar dlanvuli]

I normally read the entire book if I am intending to impliment (several) something(s) in that language (os, whatever). If the book was worth reading I'll re-read it with a hi-lighter and set it on my current refrences shelf.

I can normally read a well-writen 800-1000 page book for decent understanding in about 15 hours, and if its wroth re-checking it normally takes about 4 more.

I don't really find it a waste of time, I've found once I've read a well writen (notice, alot of long books aern't) I can start reading any source and have enough understanding to figure out what it means even if I have no prior experience with a similar language.

OTOH. 300 page concise books are much better if I'm just looking to 'get it done' and maintainability(I totally mutilated that spelling, haha) and elegance take a back seat to development lifecycle.

A WROX mole?

[Anonymous Coward]

Simile.

Re:Slashdot author, complain about typos, really!!

[Anonymous Coward]

We are not paid to post...or are we?