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
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.
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.
"So, after several months of trying to dual-boot Linux (Ubuntu 5.10)"
Ubuntu 5.10 was relesed one month ago. I still think that was the closest to a true statement in that post.
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.
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".
I'm just going to focus on the sensical parts of your post because I can't understand what you're talking about most of the time.
Not really. You can just update every once in a while, but you also have the option to modify the source code yourself or hire someone to add the features you need. If you'd rather wait for some software company to add a feature to their product, you have to wait till they feel like adding it. If they ever do.
I've only tried Ubuntu on a live cd, so I can't comment on Ubuntu specifically, but setting up dual boot isn't that hard. With no previous experience, I was able to setup my desktop to dual boot SUSE and Windows XP Pro in one evening. If it's not working, you're probably doing something wrong.
You make it sound like this is the fault of Linux. You don't seem to realize that the only reason you can use "advanced hardware" on Windows is because hardware manufacturers release working Windows drivers. If they distributed Linux drivers on their install CDs this wouldn't be a problem.
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!!
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.
You are making your company dependent on the GOOD WILL of others.
Quite to the contrary: with OSS, you are not dependent on anybody.
The real thing you should worry about is that with closed source software, you are at the mercy of your vendor.
However it all functions perfectly under Windows and Mac OSX.
I'm typing this from a Mac OS X laptop--which I just had to reinstall because it was dying with a kernel panic during boot. Before that, it failed to read the xD cards from my new consumer digital camera. And among many problems, file associations are inconsistent under OS X, the green resize window button is unintuitive, and the Finder views switch haphazardly. The point is that even the best desktop operating systems have problems--Linux, OS X, and Windows are comparable in that respect. If you claim otherwise, you're simply trolling.
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.
"So, after several months of trying to dual-boot Linux (Ubuntu 5.10) I finally give up."
You're absolutely right. Linux is too damned hard and I'd much rather pay the ultra professional computer wizards at Dell to give me Windows on a silver platter. I, like you, have more money than brains, and enjoy being bent over at every available opportunity.
Grow up, learn to read, and BTW, Ubuntu has an excellent wiki that can help you solve most of your issues without alot of searching. There is a tradeoff for having something you can use free of charge. You have to be willing to actually LEARN about what you are using. Pathetic!!!!!
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.
You are making your company dependent on the GOOD WILL of others.
.. we bought an archiving software that was full of bugs that acted inconsistently and the company itself dint know how to deal with. in the end i believe we were a major reason the software company discontinued the product. problem is .. we are still stuck with the lousy piece of software and no support nor source code
Quite to the contrary: with OSS, you are not dependent on anybody.
The real thing you should worry about is that with closed source software, you are at the mercy of your vendor.
tell me about it
_ In Egypt Networks: Network Solutions with a Twist
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.
You know, it's not mandatory that you reply to every troll here.
Just to let you know.
"...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!
Who is the wiseguy that uncommented this guy's mod_idiot line in his httpd.conf?
It's not offtopic, dumbass. It's orthogonal.
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.
>>So, after several months of trying to dual-boot Linux (Ubuntu 5.10)<<
I notice you list Ubuntu as one of the dual boot tryouts but not the other? I'm guessing XP because you mentioned it earlier in the post.... could be NT,98,ME,SE ??? Anyhow I think the problem arises from the nonstandard way microsoft grabs/tags partitions. Why don't you tyr using microsofts boot manager after all it should work excellent since it is from a trusted tried and true software manufacturer that you can trust your business with !!!
FragHARD or don't frag at all