Slashdot Mirror
Apache Comes With Too Much Community Overhead?
drizzle writes "There's an interesting story on the Apache Marketing blog about whether or not Apache projects come with too much overhead, especially compared with other services or a roll-your-own approach. The article states, 'It's true that compared with SourceForge, Apache has a more rigorous management structure. The ASF has formalized processes and procedures that we believe represent best practices governance. All new projects must pass through an incubation period to ensure that all of the project's members have internalized these processes. However, each project's leadership has a tremendous amount of discretion in managing within this framework.' There is also a follow up article written by one of the httpd developers about 'What Apache brings to the table.' The article cites community, experience, legal framework, diversity, brand strength, and networking as reasons why developers and companies should consider bringing their projects over to Apache."
I just setup an Apache web server for use at home, and now I've got 4 Apache developers living in my basement. When they showed up, they said they were my Apache community overhead and I had to let them stay there. Oh, and I apparently have to feed them too!
After all, it's not like they created one of the most popular open source apps of all time or anything like that.
"I'd rather be a lightning rod than a seismometer." -Ken Kesey
Don't build your business on open source, unless you want to rely on the good will of others.
Did you ever stop to think, that as a business owner, OSS could be scarey on the desktop?
You are making your company dependent on the GOOD WILL of others.
If you buy from a business, at least you know the greedy bastards will want to make money, and keep updating and have a growing concern.
Sure, you know that linux works. BUT a business owner does not. IT IS NOT IN HIS/HER BELIEF system to think people just do stuff for free.
After all, they sure as hell are going to charge others, to make a profit.
So, after several months of trying to dual-boot Linux (Ubuntu 5.10) I finally give up. I think that it's a fine project, but there are a few areas where it fails to deliver.
Specifically:
- why is it so darn hard to install anything ? I have to use Alien on most of the downloaded packages, and even then it's anybody's guess whether the software would install at all.
- why is GRUB losing my Windows XP from menu.lst after each update ? Every damn time I have to manually edit menu.lst and hope that it would
work.
- why is multimedia (esp. DVD) so goddamn unreliable ?
- why is the file manager (at least the one that comes preinstalled) so darn useless ? Why can't I do basic file operations without invoking two different programs and a terminal window ?
Don't get me wrong, I _do_ think that Linux is a great project, but it
does have its share of problems. So does Windows, of course, but it's
at least user friendly, intuitive and consistent. The "Public" OS like
Linux should be more intuitive, not less.
THIS, is LINUX.
THIS is YOUR support structure when you have troubles with Linux, and you
will.
See the try XYZ distribution?
See the accusations of being stupid?
See the sour grapes (this mouse sucks, when every review of this mouse is +)
See anything factual?
I don't......
In fact I see a collection of rabid zealots trying to defend their
miserable OS.
Look, the point is the mouse does not, cannot and will not work with Linux
and if it can be MADE to function with Linux most people will give up LONG
before they get it working and this goes for MOST new hardware and Linux.
Most hardware is obsolete by the time Linux supports it.
However it all functions perfectly under Windows and Mac OSX.
Maybe that is why they are professional operating systems and Linux is a
wanabee clone of Unix?
My advice?
If you want to use advanced hardware to it's fullest, don't look at Linux
because it is terrible at this.
How about the "overhead" of the various BSDs? FreeBSD, OpenBSD, and NetBSD all have what could be described as "too much overhead" in their development model. Yet all three are considered among the shining stars of FOSS operating systems. Stable, robust, and "you know what you're getting".
BTW- Apache is developed primarily on FreeBSD.
You want to do a project? Okay, well nobody is forcing you to work with Apache. The Apache community keeps consistently turning out good products. This tells me they're doing something right.
Yeah, so with sourceforge you don't have to spend as much time on organizational matters. And also on sourceforge 98% of the projects are stalled out in the planning stage. I don't see an improvement there.
Two words why you shouldn't use Apache unless you absolutely need to (and most apache users don't NEED apache): configuration complexity.
Apache's configuration file hasn't changed dramatically since the days of v1.3, and it's still an absolute train wreck. It is seconded in nightmarish complexity and eccentricities by Sendmail- and barely at that. See the old slashdot story Why I hate The Apache Webserver.
I have an idea. Let's see replies here, suggesting Apache alternatives that are a)lightweight b)easy to configure c)open source with BSD or GPL (or similar) licensing. Why? IMHO, the Apache group has gotten a little too comfy with their market dominance and years of blind faith from unix users. Sounds like it's time to remind them that especially if you're already on an open-source platform, you have a lot of choices.
Let's see lots of people trying out different webservers, helping improve them if they come across problems, and helping integrate these different webservers into distributions better, and so on. (That debian package for "joeserve" out of date? Help update it! Init scripts a mess? Spend 15 minutes coding up some improvements and email in a diff to the maintainer. Etc.)
Please help metamoderate.
I'm inclined to agree, much as I like Apache. It is not very nice to set up, especially if you want to do something odd.
If you miss the love train, I won't feel sorry for you.
For most distributions Apache is configured to work pretty easily. I do agree that a very simple webserver (single user, single threaded, no virtual servers...) should be the default desktop webserver. Anyway here is a comparison chart.
I have this feeling that most of the stuff that you complain is hard to configure with Apache, that you couldn't do this with the lightweight stuff at all.
For simple stuff, what is so difficult about setting a port and a base directory?
I'm still trying to figure out what people mean by 'social skills' here.
Why don't they just make the configuration file XML, release the specs, and someone comes out with a GUI configuration editor. Problem solved.
If you want simple, static content, thttpd is stupidly tiny, stupidly scalable, and way faster than Apache. Unfortunately it uses the old fork model for dealing with CGI scripts which make it quite slow as doing that (but no worse than the old NCSA httpd). It has a number of interesting features, such as per-filetype bandwidth throttling (so you can specify that MP3 files only get transferred at 10kB/sec), but also has some suprising omissions --- the MIME type database is hard-coded, and it only handles HTTP 1.1. But if you have a simple site based mainly around static pages, thttpd is probably ideal for your purposes.
Ok. maybe there is something wrong with the apache development process. I don't care.
Apache works great, and I have never had any difficulties using it or any of its modules. As a web server, it has done a great job, and been consistently secure and effective, so I will continue to use it, even given the mysterious flaws in its dev process that may or may not exist.
Yes, Apache (Web server) is somewhat hard to configure. There's a large file with a lot of (documented) features and settings, and a lot of ways to go wrong there.
On the other hand, Apache is incredibly flexible: You can use it as a proxy, it does ssl, it fronts for Java Web servers, it rewrites URLs, it authenticates, it slices, it dices and I'm probably just scratching the surface.
Someone who knows his way around the config file - and that's really the only crucial thing to know about Apache - is able to get it to sing and dance. The header in the file warns people to read in-depth documentation rather than relying on comments in the file. There is documentation, there are books. If you're going to play at being a 'professional' Web admin, then you need some of this stuff.
For the less seriously inclined Web maker, programs like Webmin let you fiddle with a subset of Apache settings through a HTML front end. On an even broader front, many Web site hosters provide a dumbed-down interface that allows only a small subset of configuration options and keeps the user from doing anything really stupid.
And for anyone not covered above, yes, I'd recommend getting a simpler Web server. Personally, I find Tomcat a little easier to configure than Apache, but that's just me. I'm sure there are dramatically simpler products. Hell, lots of people have written their own!
The discussion in this topic is not about the complexity of using the Apache Web server, but the complexity of managing an Apache project. I'm not sure if I'd be perfectly happy "doing" an OS project under Apache, but... that's what choice is about, right?
When one person suffers from a delusion, it is called insanity. When many people suffer from a delusion it is called Rel
An old-timer with old-timey ideas.
And on that note, there is absolutely nothing stopping someone from writing a GUI configuration editor that reads the current configuration files.
Or if you want something smaller than Apache and a little more than just static pages try http://www.lighttpd.net/. It is secure and beats Apache 2 performance wise and the configuration takes only a few minutes. It runs on my small server for months now and is certainly worth a look.
Out of curiousity, did any of the above posters actually read the article? Or even the Slashdot post?
This isn't about Apache's Web Server at all. It's about the Apache foundation, and running projects with them. Apache's web server is just an example of a project that is run under the Apache Foundation... and any bloat / hard configuration in httpd has little to do with Apache Foundation's "overhead".
First, If you actually read through the blurb (not even the article) you'd see that they're not talking about web servers - they're talking about Apache, the organization behind the web server.
Second, I would recommend the up-and-coming lighttpd, which I have used for both static and dynamic content. I have never used thttpd so I am not sure how it compares on the static end.
The space unintentionally left unblank.
Now that folks, is pure comedy
"Apache Comes With Too Much of a Color Overdose?"
Hoowwllleeeeeyyyy crap. I thought Rob didn't have an 'eye' for color _before_ I saw the Apache page.
Seriously. Purple. Purple AND Yellow. Eugh!!
No self-respecting geek wants easy to use/configure crap...
Go to the lightweight brainpower girlieman section if you want easy to use, its next to the barbell, home-gym area of the store.
When one person suffers from a delusion, it is called insanity. When many people suffer from a delusion it is called Rel
apache = 0x617061636865 = 0x5 * 0xD * 0x1D * 0xD3BABFCA9
APACHE = 0x415041434845 = 0xD * 0x14B * 0x3E2BE92AB
So... What were you saying?
...until they get thirsty and start asking for beer. And not just any mass-produced US supermarket swill beer will do either. These fellows will demand the $8/sixpack good stuff.
You have to be kidding me? XML? Are you out of your mind? Apparently you've drank the XML koolaid and you're parroting it's usefulness for everything but ending world hunger. Almost every OSS project I use relies on the ease and simplicity of text configuration files. Of the few XML configuration files I've ever used, I've been left with a disgustingly horrible taste in my mouth afterwords.
Some of use don't want some GUI to do our configurations, and we certainly don't want to be at the mercy of one. When the GUI breaks or doesn't work (It's KDE only, it's gnome only, Xorg isn't installed, one doesn't exist yet, the ones available don't support these new options yet, ad infinium), we don't want to have to construct super perl scripts with XML capabilities to do mass changes in configuration files. Some of you might be fine with your tomcat's server.xml file being 1500 lines and the accompanying bloat, but I for one choose less complexity, even if the only advantage is controlling configurations more efficiently.
I'm not going to bash the Apache Foundation or Apache Developers, or even Apache itself. It's all good work, and lots of it, while I sit around doing SFA...so who am I to bitch?
However I believe that any bloat, be it at the Foundation, or developers, development, or Apache is all part-and-parcel of the Kitchen Sink mentality of computing.
I was going to blame the Linux community's Kitchen Sink mentality, but then I remembered Microsoft and their products (and just about everybody else) and realised that it's a computing thing, not platform specific.
Ever asked somebody to do an install for you, either because you don't have time, or it's new to you, or whatever? They will always install every last little thing, "Because you may need it someday".
I'm a minimalist when it comes to systems, and I mean minimalist: unless the system won't function without something, it's not installed. Yet I have never met anybody else with the same approach.
Humans and bloat go together I guess.
Yes, Apache 1.x is enormously popular. But that's not where the work in the Apache project has gone recently; recently, they have been working on Apache 2.x, XML-related projects, and lots of other projects. Are you using any of those more recent projects? How much impact have those projects actually had? And is the amount of effort that has gone into them justified by their impact?
Really.
Ok, whilst on free OS logo fetishes.
The Red Hat model.
http://www.madyiordache.com/TheRedHat.htm
Geez, any professional sys admin can configure apache. If they can't they should be fired. If you are not a sys admin maybe you should be running IIS on Microsoft. If so you will still have nightmares because sooner or later you get 'owned' and it will be sooner rather than later because by default IIS the OS is wide open.
/.
You're a weenie, quit reading
JUST KIDDING!
The config file is fine, how about learning how to use something before actual using it?
It's not that there are no manuals and info.
...except in this case, most Slashdotters probably have more time than money... All of the people who complain about the Apache config files should make the changes they'd like to see, and contribute their work back to the community. That's the whole point of open source: stop bitching and start fixing.
In that Digg.com article on Slashdot last week, all the readers posted that they come here "for the comments" and not the news. Kind of worthless, then, if nobody reads the article and just comes here to mouth off about whatever pops into their minds that's vaguely related to what's in the article headline...there's a reason Linus Torvalds said in the LKML that Slashdot is one big "public wanking session" where people who don't know what they're talking about get together.
IMHO, the Apache group has gotten a little too comfy with their market dominance and years of blind faith from unix users. Sounds like it's time to remind them that especially if you're already on an open-source platform, you have a lot of choices.
Yeah, they need a message. Look at that beautiful graph now - Apache's hit 70% this month!
Obviously, they're hitting that percentage because, like, people don't have a choice in the matter. It must be dirty pool playing on the part of the ASF... right?
I find the Apache config file fairly easy to set up. It works reliably and without complaint every day, with now just shy of 5 years of perfect uptime...
Of course, you might consider this option... Pick your poison.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Apache has become rather bloated , and its
community is a part of that bloat.
A smaller, simpler server is in order, such as Scrinchy.
http://scrinchy.org/
Or, look at the numerous other small servers, here:
http://en.wikipedia.org/wiki/Tiny_web_servers
...I thought apache.org was primarily about Java projects.
I won't go into a troll about how challenging it was, trying to set up Tomcat to work with a database.
Poring over the source code, what I gathered was that they were using XML files and the admittedly interesting reflection features of the JVM to more or less script the JVM and quite a bit of the app server, especially the security stuff.
The documentation was less than illuminating, and the source code little help. So I took a failing grade in the software engineering class, quit school, and got on with life.
Anyway, a survey of apache.org would reveal an overwhelming Java bias in their projects, no?
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
I know this is sort of off-topic, but has anyone tried the Cherokee web server? I've heard some good things about it, but not enough to try it out yet. We were using apache 2, switched to lighttpd, and now we're back at apache 2 again (switched back because lighttpd wasn't handling heavy loads very well which could have just been mis-configuration I guess).
Actually, Java projects are a minority of the Apache projects, they just happen to get a lot of press because of Tomcat and the IBM acquisition of Gluecode (and some Geronimo team members).
Apache recently has gotten a lot of new committers in XML and web services development. Like with Axis2 and Synapse.
They also have a project called Maven, which is a development environment framework.
There is also SpamAssassin, which is a product I use quite a bit. They claim to be the #1 open sourec spam filter. I don't know if this is true, but I know a lot of people who use it.
afaict there are three main reasons for using apache
1: your already familiar with its configuration format (which i never had too much trouble with myself but some seem to hate)
2: you wan't to use software thats primerally designed to run under an apache module (think most php stuff).
3: you actually wan't the ability to do things like arbitary matches on urls and proxying some dirs to other servers and name based virtual hosting all at the same time.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Where would you host it? Apache, Source Forge, or somewhere else?
How important do you think the Apache brand is to attracting new developers to your project?
I'd think at least twice before criticizing Apache's basic structure. There aren't many open source projects that are as successful as Apache and dominate their space as thoroughly.
You have to be kidding me? XML? Are you out of your mind? Apparently you've drank the XML koolaid and you're parroting it's usefulness for everything but ending world hunger.
He's not out of his mind, and you aren't proving your own sanity by being rude. There's nothing wrong with XML for configuration files, and plenty to gain. If you have config in XML, developers can write config integration or front-ends in any language that has an XML parser. PHP, Java, Perl, Javascript, Python, Mono/.NET, etc., etc. With normal text config files, you have to do ugly string manipulation, and you have no way to adjust from version to version without custom hacking for every setting in the config. This is why front-ends rarely exist for most text config files, and why front-ends do exist for many XML config files.
Further, with XML the configuration option and it's set value can be validated. Right now, we don't know if any setting in a text configuration is actually doing something or doing what we want. From version to version settings change, go away, gain new options, etc., and we have no way of knowing if our setting is valid until we view documentation - and even then we have to hope the documentation is up to date.
Some of use don't want some GUI to do our configurations, and we certainly don't want to be at the mercy of one.
No one is forcing you to use a GUI front-end for XML config files. But thanks for thinking that you are the center of the universe, and all those who want a front-end be damned.
When the GUI breaks or doesn't work (It's KDE only, it's gnome only, Xorg isn't installed, one doesn't exist yet, the ones available don't support these new options yet, ad infinium), we don't want to have to construct super perl scripts with XML capabilities to do mass changes in configuration files.
Editing an XML config file in a text editor isn't harder than a non-XML config file. The same "stuff" is there. Yes, it has tags around it that take up space, but big deal.
I've been monitoring Roller's transition through Apache's incubator process. You can get a glimpse of all the legal licensing issues a project has to go through to become compliant. Definitely an interesting read:
r -roller-dev/200511.mbox/thread
http://mail-archives.apache.org/mod_mbox/incubato
Learn more about Steorn at Free Energy Tracker
I, for one welcome our new apache community overhead overlords!
...I've been left with a disgustingly horrible taste in my mouth afterwords. MUST...RESIST... That's what she said.
Is that why Postfix is miles easier to configure than Sendmail- and is faster, more secure, and just as flexible if not moreso?
*crickets chirping*
Please help metamoderate.
I've used Apache for years and I understand it just fine. It doesn't make working with it any less confusing, and I resent the character assassination attempt.
See the presentation I linked to. The format, organization, directives, and parsing of Apache config files are all downright STRANGE sometimes.
PPS: I don't take seriously the words of a man who picks as his username, a character from the worst movie ever made (Hackers.) Furthermore- maybe you should make sure your website is up and running (it isn't) before you go lecturing us about how easy webservers are to configure.
Please help metamoderate.
They are focusing too much on java for my liking. They need to go into rails project or python. Thats the future .. none of this java shit
If there were a GUI XML tool you could a) use remote login and do it on the server in X11 or b) configure it on your computer, save the XML, upload it to your remote server then swap the files. Being headless is no excuse for being GUI-less.
They don't seem to apply their rigorous procedures to mod_jk, the plugin that JBoss.org has taken over development of. The quality of numerous releases over the past year has been very disappointing. The 1.2.15 release looks decent, but its predecessors were very buggy to the point of being what I'd consider beta software not ready for running in the enterprise environment.
Actually, Java projects are a minority of the Apache projects, [...] Apache recently has gotten a lot of new committers in XML and web services development. Like with Axis2 and Synapse. They also have a project called Maven, [...]
Axis2, Synapse and Maven are Java projects.
because configuring things like amount of connection threads alive requires to think about expected load of the system and capabilities of the system. Because there is a difference if you want to configure apache to have php/python_mod built in or you want to handle anything thru cgi, because there is a requirement to understand how http security domains work if you want to use http authentication, because good installation includes setting apropriate mod-masks on servable content. And then, there is, of course html vs. htm debate.
In short - GUI frontend wouldn't take care of thinking about your apache install as a system, dare I say, _service_ that fits your needs and infrastructure. On the other hand - there is a lot of people who took care to learn what it all means, took care to think about their needs and took care to configure their apache as they see it fit - and they did good.
If someone isn't capable to understand options in text file, he won't be capable to understand them when presented in a shiny GUI no matter what.
P.S. Apache config file really is _simple_. Really! Once you know why the hell those options are there. And if you don't - take the default one and you'll probably be ok.
I hope OpenBSD will eventually drop their Apache 1 fork (they didn't import Apache 2 because of the license) and move to Lighttp.
I am TheRaven on Soylent News
It's very easy to install, and is set up to be easily administered. I now recommend it to users of my recently released DMO software, which provides a kind of Object-based DB layer on top of MySQL.
Paul Gillingwater
MBA, CISSP, CISM
Prosecution rests.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
I'd Keep her in my freezer...
I don't know, but I get tired of the endless half-baked FOSS projects out there.
For example, how many FOSS CMS projects are there? At least several dozen, maybe a few hundred. If half the effort went into about six CMS projects, those projects would be awsome.
When every FOSS developer decides to go his/her own way, you get an endless series of cr@p.
Fact is: Apache is way more successful than 99% of FOSS projects out there. So maybe everybody else is out of step?
There are many projects out there. I have tried several. I forget exactly what they are called: PHPTrio, or Apache2Trio? Again there are several.
But XAMPP actually works. It is up-to-date, installs easily, and works well.
That is my experience anyway.
On the webserver in my basement, of course!
Saying that web server performance is better than Apache-httpd is like saying fish can swim better than dogs, it's true ... but pretty meaningless. Apache-httpd developers have publicly stated that they don't consider performance a design goal, and their email server is actually Apache-httpd in disguise.
As for lighttpd being "secure" it had a problem this year where you could bypass checks by using the NIL byte encoded. As a web server author I can only say "Like, Duh!" ... and after taking a 10 minute grep[1] of 1.4.7 I can see a buffer overflow already, I'm not sure how easy it is for a normal user to do (and it's only a couple of bytes) but I don't care too much either. The obvious DOS is there for the Range header, and the symlink "protection" is smoke and mirrors (stat check followed by a non-checked open()).
It also doesn't seem to support Accept/Accept-Language negotiation, which I thought was pretty weird (feel free to disagree).
Obviously I'm somewhat biased, given that I've writen my own, but then I do have a "security guarantee" with it.
[1] For anyone who does care do a strncpy grep in http_auth.c (I looked at version 1.4.7)
ustr: Managed string API with ave. 44% overhead over strdup(), for 0-20B
To get management to seriously consider Open Source, it's nice for them to be able to see some management processes in place. It's one of their concerns over Open Source - is it all just "wild and wooly" development, or is there a plan, is there change management, etcetera. So, to that end, this so-called "overhead" helps get Open Source adopted in places where PHBs have to be convinced.
"...developers can write config integration or front-ends in any language that has an XML parser. PHP, Java, Perl, Javascript, Python, Mono/.NET, etc., etc. With normal text config files, you have to do ugly string manipulation..."
So what? Developers have to work harder, so that USERS can enjoy clean plain-text config files? What's wrong with that? Or you'd rather make developers' lives easier and users' harder?
It's that approach that has led to comically bloated and overengineered software such as RPM and gconfd.
Work hard, and make things better for end users.
Psst....XML *is* text! And even better, it can be *validated*!
And I realize that XML is an incredibly complex technology, but it is actually possible to edit XML directly using a text editor. No "super perl scripts" needed!
On the other projects on the Apache site - Ant seems to be almost universally accepted as a build tool, and Tomcat seems to be one of the more significant servlet engines out there. Struts gets a lot of press, too. Never knew SpamAssassin was part of Apache, but there's no doubt it is also very popular. Beehive - not at this time, at least. The best-known Maven was a videoconferencing tool for the Apple Mac. The other tools listed also don't seem to have much publicity - yet. I'm not sure all of them are that useful, either. Tcl/Tk is used a lot for scripted GUIs, but is not suitable for web work, really. There WAS a Tcl/Tk plugin for Netscape - wonder what happened to that.
Some projects I'm surprised are NOT there:
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Lubricants are absolutely essential for any form of anal exploration because the anus does not produce any lubrication of its own. You need to be more than generous - too much won't be enough. Use lots of silicon or water based lube on your hand, wrist, anus, and condom and re-apply it regularly. Lubrication assists anal play and penetration and reduces the possibility of internal damage, grazing and bleeding. Lube also reduces the chance of a condom or or other barriers tearing.
It doesn't matter what OpenBSD includes in the base system, if you want to use another webserver, install it. That's what the ports/packages are for. And keep in mind, lighttpd is missing tons of functionality, and the author is outright hostile to suggestions to fix this.
Postfix is none of the above. Sendmail is incredibly simple to configure. You aren't trying to edit sendmail.cf are you? You are supposed to edit the mc file, which is very simple and easy to configure.
Sendmail has certainly had a bad history with regards to security, back in 1992 before postfix even existed. But its been hugely improved, with large parts rewritten even. Its track record in recent history has been fine, and the sendmail developers are at least responsive and proactive about security. When OpenBSD developers send them patches, they actually accept them!
I've never seen any benchmarks that put postfix significantly ahead of sendmail, even qmail is only faster when dealing with a mailing list type load, its local delivery is still around the same speed as sendmail and postfix.
And postfix is most definately less flexible than sendmail, I can't imagine how anyone could say something this obviously crazy. Learn sendmail before you make statements about how flexible it is.
First of all, it doesn't perform better than apache. It uses less memory than apache to serve many static files. Apache performs very well if configured correctly:4 /debunking-lighttpd?postid=82
http://paul.querna.org/journal/articles/2005/06/2
Second, yes it did have a stupid error that less you use NULL to see a file's source instead of interpreting it. Of course, you shouldn't have your source in a web accessable directory anyhow, that's one of the major benefits of fastcgi. It would be nice if people would stop writing things and calling them "secure" when they aren't actually trying very hard to write secure code, but there's definately alot worse out there than lighttpd. Its no worse than apache, which is what most people are running anyways.
Third, does your webserver support any of the stuff lighttpd does, or is it just like thttpd (not terribly useful)?
And finally, where is this buffer overflow exactly? I certainly don't consider myself a C expert, but although the code is "wrong", I don't see any way to overflow salt.
Riiight. That's very misleading, if not outright misinformation. Yes, in certain situations Apache-httpd can happily flood the LAN connection ... but it can have huge problems with non-instant connections due to the one process per. connection model, it is also esp. bad when the number of connections goes high. And in more situations Apache-httpd being slow isn't your major bottleneck. But you can't say "it performs very well" with a straight face.
My reaction was mainly based on the fact that it gets old fast when people start saying "My HTTPD is super fast, see this perf. comparison against Apache-httpd" ... it's basically the exact same stuff from at least the 1999 paper (I'm sure there were referneces before, but 6 years old is enough for /.) "Performance Issues in WWW Servers".
As, I believe, I said before though multiple apache-httpd developers have said that speed/scalability/etc. isn't a driving force ... so it not being good isn't really a failure.
I don't disagree with any of that ... but the above implies that having defense in depth means you get a free pass to have one of the layers be bad. That's like saying because A-random-webserver is behind a firewall that understands HTTP and rejects bad requests it's now OK that it's a security nightmare. But we might just be agreeing vemenantly here.
Useful is in the eye of the beholder, a significant number of people are fine with what thttpd provides ... personally I find that it's horrible to do things in apache-httpd that are easy in And-httpd. But then the developer staff are very open to my needs in the later :).
To possibly answer your question, And-httpd doesn't support CGIs or FastCGI yet ... so you might well think of it as "not terribly useful".
One of the lighttpd developers emailed me within a few hours of posting, so it's fixed in the latest CVS anyway.
ustr: Managed string API with ave. 44% overhead over strdup(), for 0-20B
...to pump LightTPD as a lightweight and simpler web server solution alternative to Apache. LightTPD has a smaller memory footprint then Apache does as well. Apache processes had greater than 10% of my system memory used while running a personal web server. Running the same setup with lighttpd showed around 0.3% CPU used. Configuration is still a little confusing to the average newb, but IMHO setup was easier with LightTPD.
"Riiight. That's very misleading, if not outright misinformation. Yes, in certain situations Apache-httpd can happily flood the LAN connection ... but it can have huge problems with non-instant connections due to the one process per. connection model, it is also esp. bad when the number of connections goes high. And in more situations Apache-httpd being slow isn't your major bottleneck. But you can't say "it performs very well" with a straight face."
... personally I find that it's horrible to do things in apache-httpd that are easy in And-httpd. But then the developer staff are very open to my needs in the later :)."
You are just plain uninformed. "certain situations" include almost all real world situations. Name a situation where apache can't serve files fast enough, but something else can. People have "preformance" problems with apache because they do things like write horrible slow PHP, and then complain that apache is slow. If you have slow shitty PHP code, then it will be slow. But that's not apache. And obviously apache is not tied to a single connection per process, I'm not sure why you think that.
"Useful is in the eye of the beholder, a significant number of people are fine with what thttpd provides
My comment was that its not a fair comparison for you to sit there and talk about how perfect your webserver is, when all it can do is move files from disk to network. When you approach the functionality of lighttpd, then you can compare your respective security track records.