Slashdot Mirror
Professional Apache 2.0
Although Apache changed a great deal in its version 2.0, it is a credit to the Apache folk that the config files and command line options have basically remained the same for sys admins. For this reason, the book seems to include a lot of material (CGI security, building, core modules) from the original book. However, a closer look reveals many changes. Almost every chapter includes a discussion about how features differ in both versions of Apache. The book does a good job of giving an overview of Apache's architectural changes and how the use of multi-processing modules (MPM) allow the admin to choose an optimal implementation of apache. This edition, noticeably bigger than the previous one, contains many more examples of how one can extend apache functionality (configuring for binary distribution, setting up virtual interfaces, load sharing). Many sections have been expanded. The discussion of security and SSL is more detailed, yet more succinct; so is the section on content negotiation, (which is twice as long as the previous book), doing proxy server configurations, rsync and benchmarking performance. The discussion on hardening the server was great and up-to-date, although I wish the book spent more time discussing on patching and upgrading.
What is new to the book? We find a longer discussion of graphic administration tools for Windows and Unix, including webmin (which actually I wanted more of). We also have discussions of newer modules such as mod_ruby, mod_python, mod_dav as well as a brief description on how to install tomcat alongside apache. The discussion of mod_dav was especially helpful and interesting to me (and I was especially glad that the author acknowledged the Subversion DAV module, something which is bound to become more important). The php stuff hasn't changed much (although at the time the book was published, 2.0 compatibility with PHP was still an iffy proposition). The book's discussion of mod_perl isn't significantly different, although it does point out migration issues and some additional features.
Generally, the book is clearly written and contains enough examples to find any configuration you want. A few parts required rereading (especially the part about proxies and proxypasses), and occasionally I needed a better explanation of what the example code was supposed to do.
No book can be everything for everybody, and nobody can accuse the book of not having enough content (it is after all more than 700 pages!). I found myself wishing for other things. The book briefly discussed 2.0's support for ipv6, but I longed for a fuller explanation and a more detailed example (Fortunately, I had seen a good ipv6 tutorial on Linux Journal ). Also, I would have liked more information about other web application servers (like zope that Apache sometimes coexists with, content frameworks (such as cocoon) and other goodies produced by the Apache Foundation. The author might legitimately feel that such subjects lie outside the book's scope, but such topics are becoming more important.
In summary: for newbies who are looking for a guide to start with: this is the definitive book to read. It's definitive and a little imposing, but it is well written and logically arranged.
For people already familiar with Apache 1.3 but looking for more depth about ipv6, php, content frameworks or Tomcat, it might be better to read books on those specific subjects instead of this one. Indeed, Wrox will soon be coming out with a book specifically on Apache and Tomcat.
For experienced system administrators, the material in this book may not be terribly new, but they will still appreciate the variety of configuration examples for managing large numbers of virtual hosts and the convenience of having documentation of the 1.3/2.0 differences at their fingertips.
You can purchase Professional Apache 2.0 from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
The font of the main text was difficult to read after a long day's VDU-gazing. More importantly, some explanations are not expressed clearly enough to allow the meaning to sink in without the occasional paragraph re-read, and some sections could benefit from diagrams to illustrate the points.
Whats the situation with regard to mod_perl with Apache 2.0? Is it ready yet?
Check out MKDoc a mod_perl CMS
1) MAN ;) LOL
2) Many O'Reilly's book... Great tools to the learn/test/crash/repeat approach.
You know, it's an amazing myth perpetuated by O'Reilly's publishing strategy that only people who create products are qualified to write about them.
Someone who administers Apache servers for a living might actually be in a better position to tell admins what they need to know than the person who implemented some cool feature and wants everyone to know about it.
ApacheWeek also has a review of this book found here, link
Just because they are Apache devs, doesn't mean they are expert admins. An admin book should be written by admins and not programmers. Big names do not always make the best authors, especially if they've never stepped out of academia and into the real world.
Here is the Amazon link.
This space for rent
OK, I'll use Comanche instead.
Transcript show: self sigs atRandom.
No way until then.
Yeah, you can "get it" to work, but when it's good and production stable then I'll consider it...
I have no problem with your religion until you decide it's reason to deprive others of the truth.
a book / reference that is more tuned to writing apache 2 modules? (rather than installation / administration which the ones mentioned so far have been)
thanks
andy
Seems this isn't the first time either... See this
Perhaps, perhaps not. I don't see the moderator point, though.
Anyway, I'd say the Professional Apache is Stronghold.
Not because of any feature because it *is* Apache but because of its support.
Many geeks won't need this but mostcorporations includign the one I work for actually require such software to be properly marketed and supported.
"Properly" stands here for "using a proper contract".
Trolling using another account since 2005.
A couple of years ago I get an interesting e-mail from an "author agent" from Wrox. They were looking to publish a book about Perl and asked if I was interested.
No, not in writing the book -- in writing a chapter. Apparently they go out and find programmers off the Internet to each write a chapter of the book. Well, I thought that was a strange way to run a railroad, but what the hell. I asked her about the compensation package.
$1000. Plus $1000 as an "on-time" bonus. No royalties.
Well, that totally sucked. And on top of that, the deadline was like two weeks away! So I was supposed to write a quality chapter (presumably with lots of tested examples) in two weeks. For $2,000. Yeah right. That's going to produce a quality product.
Ever since then, I've never gone near Wrox books. This one might be different, but screw them. I don't trust them at all.
Sometimes it's best to just let stupid people be stupid.
Okay, I tried to resist, but I've got to answer this ...
I really, really hate the "academia vs. real world" dichotomy that a lot of techies try to set up. Yes, business programming problems are different from classroom programming problems. Yes, academics develop a lot of ideas about programming that seem brilliant in a theoretical context but prove pretty much impossible to implement in production shops. Yes, there are shitty CS profs out there who don't keep up on the latest developments in the field and fill their students' heads with ideas that are outdated, impractical, or just plain wrong.
But. There is at least as much of a problem with "real-world" programmers and admins, many of whom are mostly self-taught and therefore have no idea where the gaps in their knowledge are, who really ought to pay more attention to academic computer science. A lot of the code I have to work with as a DBA and Web developer is, frankly, astonishingly bad. Yeah, it gets the job done, but the fact is that it would get it done a lot better if it were written by people who had some exposure to the theoretical underpinnings of CS like set theory and algorithm analysis -- and, just as importantly, to the people who develop those underpinnings.
The vast majority of the whiz-bang technologies that make computers as useful as they are came out of university labs -- not corporate R&D shops that are all "D" and no "R," not teenage genius hackers in their basements, and sure as hell not people who think that academia and the real world are somehow two separate domains, never the twain shall meet.
The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
it was a joke dude, just laugh and move on...
http://search.barnesandnoble.com/booksearch/isbnIn quiry.asp?userid=0ECFT32QIF&isbn=0672317842
But after you get into using PHP/Apache etc more, just use the web:
www.php.net is a prime example of a very, very well executed site that usually gives you all the answers you need.
That and www.devshed.com (no, I'm not affiliated with either so I'm not a pill pusher!) That site should keep you cranking for a month or so.
I thought JSP, Servlets and MySQL had some good JSP and MySQL content in it.
If you're looking to learn PHP, you should check out the documentation on PHP.net.
If you want to learn ASP, try Planet Source Code.
Step one is to decide on the platform and language you want to learn first. They all have their advantages and disadvantages.
And here I thought Microsoft Windows was the primary application that drives people to Linux and open source...
I've met quite a few people who have written OReilly books (the **whole** book) so this doesn't seem to be the case. YMMV.
Thanks for the heads up on Wrox -- I never bought them anyway, but now at least I have a reason not to...
I am not a number! I am a man! And don't you
You may not like the process, but I have several Wrox books, including the first edition of the Apache book reviewed here, and all of them are excellent. When they use the marketing phrase "programmer-to-programmer", they really mean it. Wrox Rocks.
---scott
Uh huh, sure... Watch out on the "most" label. I know of two Fortune 20 corps that use the apache.org version of Apache, and are really annoyed by the fact that Covalent has shifted their focus to supporting only Covalent-supplied versions of Apache.
:)
Although I totally understand Covalent's point of view - they were killing themselves trying to provide support for any weirdly compiled/strangely hacked version of the apache.org source.
Covalent's Raven smokes StrongHold for a pre-built and "properly marketed" Apache distro. Most of the Apache developers are employed by Covalent, and Covalent funds a LOT of the ongoing Apache development.
No, I'm not employed by, or have any financial interested in Covalent, just have been massively impressed with their service and support. We ask for on-site Apache training, they send Ryan Bloom. We look at their Raven package, and they send Dirk-Willem Van Gulik. It's like asking for Linux training and getting Linus fucking Torvalds!
I can comment on this having written material for two of WROX's books (never you mind which ones)...
You are correct in that they prefer "multi-author" books. This achieves a couple of things. First, the book is turned out in a much shorter amount of time. This is a legitimate business model, one that adheres to time-to-market and competitiveness. Of course, it takes a very good editor to manage multiple authors and to coordinate their activities. I wish that I could say that my editor was one of them. Sadly, s/he was not. There was *zero* communication between the authors and, in fact, we didn't even know who the other authors were until we got close to publication time. As a result, we also did not know what was being included in the book. This was unfortunate since it would have resulted in a better product overall. In spite of that, however, the book was very well received and sold quite a bit.
The advantage of the multi-author approach is that it provides us as authors with more time to focus on a particular topic. Furthermore, each author can be picked for their relative area of expertise and right on that. So, for example, with a book on J2EE, the person writing on JMS should be more knowledgeable than the person writing on EJB. Similarly, a person writing about Servlets may not know as much about LDAP. Having each author focus on one or a few topics will (hopefully) provide a better treatment of each topic.
From the perspective of royalties, Wrox isn't all that bad. If you write a single chapter, you get paid $1,000. That might not sound like much but no one writes technical books with the hope of getting rich. Not on royalties, at least. You make it up on the "bragging rights" when you go on a job interview. Although, be warned that in the current economy, this can backfire on you. Many authors, myself included, have had a difficult time finding work because many recruiters assume that our rates will be to high since we are published. So, they don't even bother to ask. Once I removed the book credits (and articles and lectures and....) I started getting a lot of offers.
If you write more than one chapter, you get a cut of the royalties. Wrox pays 10% of the sale price (less returns) as a royaly. This 10% gets split among all of the authors who are participating in royalties (this list does not include those who got paid a set fee). Thus, if a book has 10 authors splitting the royalties, you will get 1% of the sale price. If a book sales at $35, that means that you're getting a whopping 35 cents per book. Less taxes. Like I said, no one writes these things to get rich.
The sad reality of all of this is that you don't end up seeing much money as a result of your efforts. I have received pretty much zilch for my contributions. The only saving grace is that royalty-based authors get a (small) advance.
One major complaint that I have against Wrox is that they treat your work as a "Right-to-hire." Work that I did for one book has since been used in others, with nothing paid to me save a small credit inside. This is akin to musicians not being paid for when their music appears on one of those compilation CD's.
I love the idea of writing a book. I very much would like to do it again. However, I would not do it again with Wrox. If you are an aspiring author, I would strongly suggest O'Reilly or A!Press, both of whom have very solid track records with their author-relationships.
Wrox, my love....you helped me realize a life-long dream and for that I am ever thankful. But like my first real girlfriend, you may have popped my cherry, but you're not the one that I'm going to be spending the rest of my life with.
To the moderator: do not jump to moderate as flamebait until you have read it till the end please. As a person who have worked both in Academia (in more than one country) and in Corp (once again in more than one country) I have to say that you are deeply mistaken.
Excuse me for the engineering language but current academic CS is mostly full of shit. It is mostly a collection of people who excel in vendor and sponsor nasoanal relationships. Especially the latter.
What you describe is not CS. It is good old MATH. And what makes most programmers write shitty code is lack of solid background in mathematics. The subjects you have mentioned like set theory are just a scratch on surface. Game theory, optimisation, numerical methods, to be continued ad naseum.
I will also disagree with some of your conclusions on selftaught as synonimous with lacking. A selftaught programmer coming from a mathematical, physical or even chemical background is often a better programmer then the surrogate CS engineers printed in some countries which have cut down their math requirements for CS to almost nothing. And which do not have any of the subjects mentioned in their BSc programmes for most colleges.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
If you want to write fast perl on apache, or write Apache modules in C, get "Writing Apache Modules with Perl and C" by Lincoln Stein, Doug MacEachern.
However, wait for version 2 unless you can beg, borrow or steal it, 'cos despite the review above, I reckon quite a few things might change.
Also check out perl.apache.org, especially the mod_perl guide.
Note to ACs: I won't mod you up, even if you are being funny or insightful. So take a chance! It's not real life!
Did you try installing some physical RAM into your machine? I personally use only 32-pin SIMMs with all my production servers.
Wearing pants should always be optional.
Ahem, that should read "drive people towards BSD and open source." linux is an evil copycat OS which is nothing new and has set back the state of computing by 10 years with its still unstable vm, non-standard networking, and lossy filesystem.
Well, I do consider CS a branch of applied mathematics, actually. And so do most of the decent CS academics I know. I'm sorry if you've had experience with a bunch of bad ones. I certainly agree with you that more programmers need more math. (Having been a math major and a CS minor, I could scarcely argue otherwise.)
I don't think self-teaching is a bad thing. But -- and this is an important but -- one thing most of the self-taught people in any field don't know is, well, what they don't know. They may no just as much or more than people with formal training, but almost invariably there are huge gaps in their knowledge and they simply don't know those gaps are there. If they come from a (decent) academic background, they'll know where the gaps are and how, if necessary, to go about filling them.
The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
I'm not disputing that most of the best software comes out of university labs, but the point is that these university labs aren't using them to the extent that admins are. Admins use the software in environments that often aren't anticipated by the devs and as such are in a better position to tell us about their experiences. A good admin book should be about life in the trenches. The UNIX System Administration Handbook is a great example of this: the authors have been there and seen it all.
I just objected to the "he's not a big name author so let's not listen to what he has to say" sentiment. Pick the best tools for the job and if a book by someone you've never heard of is the best tool, then use it.
Reality Master's financial analysis is not that far off, and AC you are right that a typical discount into the sales channel is 60%, which increases the break even point by that sort of magnitude, yes it does [bites tongue]
I have a lot of information in front of me about how many copies a computer book sells, across various publishers and technologies. I need to keep it quite general, but in today's book market, for most publishers (unless they really crack a book from the furnace that just all of us feel we must have [one book to bind us? apols]) then it just isn't that easy to go significantly beyond your discount-reajusted break-even point at the moment. Especially when there are so many books out there on some of the recent technologies - it is one tough market for publishers, although more books create a wider choice for programmers - in the short term at least.
The Y2000 period was a little bit different, and Wrox for sure was able to pay higher rates to its author and reviewer colleagues during that time. As an independent company, we adapt to the market conditions as best we can: that's why we do review our author rates.
But I tell what you already know indeed: Wrox rates and general publisher rates in the programming sector won't usually let anyone quit their day job. But Wrox isn't about quiting our day jobs ... if you're an author/programmer then you like what you do and I really trust that there's some good things that happen when you work with Wrox as an author or reviewer.
And for sure :) you've gotta really WANT to work with Wrox to publish your ideas to other programmers - more than once we've received a complaint from spouses about how involved their partner has become with a Wrox project. I have myself worked as an editor through a long day, slept on the floor by my computer, and picked myself up to start again a few hours later for the next day. NOT that this is how you have to do it at Wrox!! - but sometimes, when the spirit is with you, the book can mean that much. It felt great to see that book become what we all wanted it be when it was published - but then I took some time off!! No regrets. This is our lives, and imo we should sometimes do things that just feel good. I continue to hope that working with Wrox as an author and reviewer can supply some of life's rich stuff (if not enough cash to exactly retire.)
OK you've got me ready to go and read some of our recent author dedications again now ... see you later!
xd