Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Software Apache

Apache Comes With Too Much Community Overhead? 161

Posted by Zonk from the many-hands-make-light-work dept.
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."
This discussion has been archived. No new comments can be posted.

Apache Comes With Too Much Community Overhead? More

Apache Comes With Too Much Community Overhead?

Comments Filter:

  • Tell me about it (Score:5, Funny)

    by Anonymous Coward on Saturday November 19, 2005 @05:40PM (#14072478)
    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!

  • They must be doing something wrong (Score:5, Funny)

    by winkydink ( 650484 ) * <sv.dude@gmail.com> on Saturday November 19, 2005 @05:51PM (#14072517) Homepage Journal
    After all, it's not like they created one of the most popular open source apps of all time or anything like that.
    • And not many webservers actually run it either, especially compared to Microsoft's server...

    • Re:They must be doing something wrong (Score:4, Insightful)

      by fermion ( 181285 ) on Saturday November 19, 2005 @06:02PM (#14072559) Homepage Journal
      By this logic, MS makes the best microcomputer operating system in the world, and we all jsut better start using it.

      There is always room for self reflection and improvement.

      • Re:They must be doing something wrong (Score:4, Insightful)

        by mithras the prophet ( 579978 ) on Saturday November 19, 2005 @06:17PM (#14072623) Homepage Journal
        No, I think the analogous observation is that Microsoft must be doing something right, because they've created the most popular operating system software (and probably software, period) ever. Which is true: they are doing something right. That something might be nefarious business practices and ruthless leveraging of a monopoly, but they're obviously doing a good job of it.
        • > Which is true: they are doing something right.

          They are or they have been? Microsoft monopoly is largely a result of the cheap cost of the PC, they saw that by selling their OS cheap on cheap PCs they would own the market, and then the 'net effect' will ensure that they would stay dominant.
          What they are doing right is compatibility: as they understood that the 'net effect' is their strong point, they ensure compatibility with software installed basis so that they keep their advantage.
          This advantage for

    • But what have they done recently? (Score:5, Interesting)

      by penguin-collective ( 932038 ) on Saturday November 19, 2005 @07:12PM (#14072834)
      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?

      • Re:But what have they done recently? (Score:4, Interesting)

        by winkydink ( 650484 ) * <sv.dude@gmail.com> on Saturday November 19, 2005 @07:36PM (#14072925) Homepage Journal
        Actually, yes. I am part of the Spamassassin development effort.
      • (I agree with many of the chap's comments about Mammoth skiing- I worked as a ski instructor there once... but Courchevel/les 3 Vallees in France is still so much better!)

        Apache-group software is excellent, but can indeed be confusing. There is so much there of merit, which just isn't understood.

        I use Apache 2 and don't get too concerned about the accompanying fluff; so long as I can configure it, it doesn't concern me. But woe betide the person who can't and has to go to apache.org and fight to get throu
        • I suspect 99.9% of Apache software used is the web server. Perhaps the Apache group has grown too far.

          I suspect you're wrong. At work, we're using tons of products made by Apache, in addition to the webserver itself. Ant, Tomcat, Struts, and plenty of XML-related and Struts-related libraries, off the top of my head. All these projects are high-quality software, and used as such by many companies working with Java around the world.

          Apache is as bright a beacon in the Java world as it is in the webserver world
      • Apache 2.x seems to be considered solid but sluggish, compared to the 1.x series, so I suspect there are people who held off the 2.0 series in the hopes that 2.1 will improve performance. And. yes, whilst I fully understand the natural desire to maintain high standards in coding, I do think that the Apache group cold-shouldering SGI's Apache Acceleration Project was probably not the greatest of responses. The fact that these were performance patches, given that 2.x has proved to be slower, has probably sour

  • BSDs? (Score:5, Interesting)

    by RT Alec ( 608475 ) <alec@nOsPaM.slashdot.chuckle.com> on Saturday November 19, 2005 @05:55PM (#14072534) Homepage Journal

    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 [netcraft.com].

    • Re:BSDs? (Score:4, Insightful)

      by slavemowgli ( 585321 ) on Saturday November 19, 2005 @06:32PM (#14072678) Homepage
      It may be just me, but I think you're reading too much into a Netcraft report here. Outside of the fact that FreeBSD and Linux seem to be about equally present here, the platform on which the projects's *website* is hosted doesn't say anything about the platform the project itself is developed on.

      Case in point: openbsd.org is hosted on Solaris [netcraft.com]. Does that mean that OpenBSD is primarily developed on Solaris? Of course not. And the same thing goes for Apache, too. It's still possible that Apache is primarily developed on FreeBSD, of course, but a Netcraft report doesn't say anything about whether it is.
      • Interestingly enough, FreeBSD is in fact extremely popular with most of the httpd developers I know.

      • Re:BSDs? (Score:3, Informative)

        by RT Alec ( 608475 )
        According to Apache's web site [apache.org], quite a bit of Apache is actualy developed on FreeBSD servers. As far as the individual developers go, I believe Brian Behlendorf [apache.org] makes a good representative of senior Apache developers.
    • Wow, I don't know whether to call you a fanboy, a PR flack, or the BSD reality distortion field.

  • Uh, what? (Score:4, Insightful)

    by Anonymous Coward on Saturday November 19, 2005 @05:57PM (#14072541)
    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.

    • Re:Uh, what? (Score:2, Insightful)

      by Anonymous Coward
      I was considering contributing to the Geronimo project. I signed up. Before I saw a single line of code - I had more than 1000 mails in my inbox, emails that were dealing with purely administrative detail and discussions on organisational matters. I grew so fed up with it that my interest drifted elsewhere.
      Admin overhead? you betcha!
  • 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."

    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

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

    • Dunno .. (Score:3, Insightful)

      by RedLaggedTeut ( 216304 )
      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?

      • Re:Dunno .. (Score:3, Insightful)

        by The Spoonman ( 634311 )
        How about the simple fact that unless you read, memorize and completely digest the entirety of the Apache documentation, there's no way to know exactly what the bare minimum is necessary in an httpd.conf to just serve static webpages on a particular port. Is a "MaxKeepAliveRequests" an absolute essential? "StartServers"? Which modules? Is dir_module an absolute minimum requirement?

        "Oh, but httpd comes with a default configuration file", you say? The default configuration file is almost 1100 lines lon
        • Well sounds like you wanted to have fun, and you had fun, sort of, reducing the config file to its minimum.

          Okay, the options are a mess, but you could find out which one you need by google.

        • Re:Dunno .. (Score:4, Informative)

          by fimbulvetr ( 598306 ) on Saturday November 19, 2005 @07:20PM (#14072873)
          fimbulvetr@media:/etc/apache2$ grep MaxKeepAliveRequests apache2.conf
          # MaxKeepAliveRequests: The maximum number of requests to allow
          MaxKeepAliveRequests 100
          fimbulvetr@media:/etc/apache2$ grep StartServers apache2.conf
          # StartServers ......... number of server processes to start
          StartServers 5

          Seems that they're documented enough to figure out a barebones configuration. I realize you're pointing out it's complexity and these examples are nothing but trees in the forest, and there are plenty more, but the point is that they _are_ documented. Apache is an extremely powerful and flexible webserver. For light servers, it's easy to get it up and running right away (by keeping the defaults) - and the reverse is true - it takes very little work to get a default httpd.conf to run in a highload environment (assuming you're running in a pretty standard one).

          Now, if you need a super custom setup - it's not such a huge leap for the developers (and even the guy at apache who is the boss of what gets put in the default conf) to presume that the person needing it in a custom environment knows apache pretty well and knows what they need to use in the configuration file.

          Finally, I do think it is reasonable to say that people who setup a website should take the responsibility of knowing, at least the basics, of running websites. Even if this means gathering more than a cursory understanding of the workings of apache or any other webserver, it is certainly going to be more beneficial for them than sitting around bitching about the complexities he doesn't want to learn.
        • be very carefull when trying to minimise the config file for apache like that, you absoloutely MUST take account of the fact that it applies security after mapping to the filesystem or people will be able to use .. in the path to access stuff outside your document root.
    • Why don't they just make the configuration file XML, release the specs, and someone comes out with a GUI configuration editor. Problem solved.

      • Re:configuring apache #1 complaint, still unaddres (Score:5, Insightful)

        by fimbulvetr ( 598306 ) on Saturday November 19, 2005 @06:58PM (#14072783)
        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.
        • 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.
        • ...I've been left with a disgustingly horrible taste in my mouth afterwords. MUST...RESIST... That's what she said.
        • 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!
      • 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 co

    • Re:configuring apache #1 complaint, still unaddres (Score:5, Informative)

      by david.given ( 6740 ) <dg@cowlark.com> on Saturday November 19, 2005 @06:13PM (#14072604) Homepage Journal
      If you want simple, static content, thttpd [acme.com] 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.

      • Re:configuring apache #1 complaint, still unaddres (Score:5, Informative)

        by Vario ( 120611 ) on Saturday November 19, 2005 @06:38PM (#14072704)
        Or if you want something smaller than Apache and a little more than just static pages try http://www.lighttpd.net/ [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.
        • Lighttp also supports FastCGI, so it can pre-fork a process to handle CGI requests and re-use the same process for every request to that script.

          I hope OpenBSD will eventually drop their Apache 1 fork (they didn't import Apache 2 because of the license) and move to Lighttp.

          • 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.
            • The package for PHP does not support FastCGI, and it does not appear to be an option in the port. Building PHP with support for FastCGI requires either modifying the port's Makefile, in which case you'll need to remember to do that every time you upgrade or building it manually and losing integration with the packages system. If the default web server were not Apache then I doubt that the default for things like PHP would remain 'works with Apache but nothing else.'

              Actually, I'd rather see them make the

              • Actually, building PHP with fastcgi support requires neither of those things. Just set CONFIGURE_ARGS to whatever you want it to be before building the port. Its not that big a deal is it?

                Also, have you asked the maintainer to include a fastcgi FLAVOR?
                • No, it's not that big a deal, but it is mildly irritating. As for asking the maintainer to include a fastcgi flavour - it was my intention to create this myself, and then submit it as a patch, rather than saying 'I want this feature, make it happen for me,' since I've found that attitude not to go down well with developers unless it is acompanied by a cash injection (or, at least, a beer or pizza injection).

        • 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 [lighttpd.net]. As a web server author I can only say "Like, Duh!" ... and after taking a 10 minute gr

          • 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:
            http://paul.querna.org/journal/articles/2005/06/24 /debunking-lighttpd?postid=82 [querna.org]

            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

            • 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 [... snip ...]

              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 situa

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

                You are just plain uninformed. "certain situations" inclu
      • 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 [lighttpd.net], 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.

    • Configuration complexity (Score:5, Insightful)

      by Elrac ( 314784 ) <carl@@@smotricz...com> on Saturday November 19, 2005 @06:20PM (#14072631) Homepage Journal
      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?

      • Re:Configuration complexity (Score:5, Insightful)

        by zerocool^ ( 112121 ) on Saturday November 19, 2005 @07:51PM (#14072973) Homepage Journal


        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.

        You're exactly right, and your parent poster is exactly wrong. Attention, Please, Everyone:

        EASE OF USE DOES NOT INDICATE A BETTER PRODUCT.

        Apache is incredibly powerful. There's a reason it's the most popular webserver in use today, by far. And, with most linux distros, it's relatively easy to configure given the default configuration file.

        The grandparent poster seems to suffer from the "I can't figure out how to do it in 5 minutes, therefore it's too hard" syndrome. Well, guess what? Work harder, or find a webserver that's easier to configure. For starters, there are any number of graphical (and ironically, web based) configuration utilities for apache. See ApacheGUI, Apacheconf, and Webmin. Aside from that, if the big bad config file scares you, maybe IIS is for you - you know, checkboxes and dropdown menus and insecurities.

        But, seriously, the ratio of (Size and complexity of apache config file) to (complexity of the program) is very reasonable. I worked at a linux / solaris based webhosting company for almost 3 years. It took me about 2 or 3 months before I was completely comfortable working with almost all facets of httpd.conf. I understood the general idea in about a week, and there are still some parts that I'm fuzzy on, or don't get, or would need to google, but a couple of years ago, I could have almost written a config file by hand. They're seriously not that long, if you take out the commented sections (which are, of course, there to hold your hand). By contrast, I only scratched the surface of the sendmail config file.

        Basically, my post boils down to: You can understand the basics of the apache webserver in an hour with a tutorial, google, and a test box to play with. Most of the time, the default options will work for you. There is almost no end to the amount of apache documentation available for you. And there's no need to understand the intensely complex aspects of the webserver outside of specific instances. For basic usage (as with most programs), stick close to the defaults, and google for answers to any questions you have.

        Just because You, grandparent-poster, can't understand the apache config file in 5 minutes doesn't mean that the whole project should be scrapped. Every part of the config file serves a purpose. Any new project you create will need to have all the variables in the current project defined, or it will be less capable than apache. Please, take the time to learn what you're doing, and come up with real problems that need real solutions.

        Just as an aside: vi versus Notepad.exe - Which is better?
        vi is more cryptic, by far.
        vi takes longer to learn
        vi doesn't look as nice
        Notepad is very easy to use
        Notepad is graphical

        However, once you take the time to learn vi, you'll see that it's difficulty in learning, once surmounted, leads to a much more powerful, capable text editor.

        ~Will
        • You're exactly right, and your parent poster is exactly wrong. Attention, Please, Everyone: EASE OF USE DOES NOT INDICATE A BETTER PRODUCT.

          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*

          • PS: I didn't say Apache would be a better product. I said a long-standing complaint from USERS of Apache is that configuration is a royal pain in the ass. And that the Apache project has done absolutely NOTHING to address it.

            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 downr


            • Sigh.

              1.) The Apache foundation hasn't "fixed" the config file issue because they (like most other serious web admins) don't consider it a problem - they consider it a strength.

              2.) If you "understand it just fine", why are you still confused by it.

              3.) Your user id indicates that you've not been around slashdot long enough to see one of my now hundred or more replies to people who tell me it was dumb to pick a username from the guy from hackers. I'm tempted not to even bother, but just for the sake of arguem
          • 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.
        • The original poster does have a point. A very powerful piece of software can still be easy to configure and not lose its power.

          One way to do this is to have 3 different levels of configuration. Novice that exposes only a few options, medium, and finally advanced which gives you the entire gamut.

          If 75% of the people just want to get something up and running then tailor the configuration to show them only the options those people will need. If an administrator needs more power then they can go into more ad

          • Right, but if I understand you correctly, what you're suggesting is to hide the more complex stuff from the casual user, and I think that's not a bad idea. The target of my aggression, the grandparent poster, wouldn't have wanted that - if you read his posts, he was looking for a way to "configure the minimum amount of stuff for security reasons". Giving him a simple config file, and telling him there were more advanced options somewhere else, wouldn't have helped him, because he wanted to go through and
        • You are correct in many ways, however the usefullness of a product is *entirely* on the documentation *if* it's a complex project.

          Example 1: Microsoft Windows API isn't documented well. Does this mean it sucks? No. I've seen some *really* cool stuff out there.

          Example 2: Apache is flexible and has allot of documentation. Does this mean Apache is good? No. Their documentation is too complex. But this doesn't mean Apache sucks. It just means that using the more complex parts of it gets difficult.

          Example 3: PHP
        • On the other hand, there's no need for apache to be quite so hard to configure, or to have such inconsistent configuration syntax, etc etc. As others have noticed in this thread, go back to Why I Hate The Apache Web Server [slashdot.org] for a nice list of many of the precise stupidities.
      • I really wish that there were a programmatic interface to Apache configuration.

        I think we could really use some tools to help with Apache configuration.
        • Something where, in any directory, you could ask: "Apache, tell me what you think about this directory. Talk to me, Mother Goose." You know- it could say, "Options ExecCGI, blah, blah, and blah." It would tell you if Apache had permission to go to that directory, it could tell you what rights Apache had in that directory, it could tell you what things it wo
    • 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.
    • 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 [netcraft.com] 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
    • 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.

  • Everyone missed the boat... (Score:5, Insightful)

    by }InFuZeD{ ( 52430 ) on Saturday November 19, 2005 @06:38PM (#14072708) Homepage
    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".

  • Tough Call. (Score:4, Insightful)

    by Anonymous Coward on Saturday November 19, 2005 @07:04PM (#14072805)
    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.
    • 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 mean minimalist myself. The prosepect of a major distro upgrade do not always thrill me because it means I have to go though and see what exactly the "bare bones" install installed that I have to now remove.
      • ever considered switching to a distro where using the package management tool on the system is the supported way to upgrade?

        • I use a lot of flavors of Linux that offer what your talking about. However that is not the issue that I am actually refering to.

          What I'm talking about is fresh installs for servers that I may be setting up. When setting up a server for a new client I tell them I'm comfortable with setting it up with whatever distro they might want. Often times that question alone is enough that I get the deer in the headlights look from them so I quickly then give them a list of the standard "big name" distros that they

  • Seriously, other than httpd (Score:4, Interesting)

    by smittyoneeach ( 243267 ) * on Saturday November 19, 2005 @09:31PM (#14073293) Homepage Journal
    ...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?

  • There's a problem? (Score:5, Informative)

    by lseltzer ( 311306 ) on Saturday November 19, 2005 @10:23PM (#14073481)
    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.

  • Roller Weblogger's Transition to Apache (Score:3, Interesting)

    by GuruThrill ( 110402 ) on Saturday November 19, 2005 @10:54PM (#14073572) Homepage
    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:

    http://mail-archives.apache.org/mod_mbox/incubator -roller-dev/200511.mbox/thread [apache.org]

  • mod_jk (Score:2, Informative)

    by Anonymous Coward
    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.

  • One complaint I've often heard is how Apache is difficult to install for beginners. I came across a great answer to this question recently. Check out the Apache Friends XAMPP [apachefriends.org] package, which combines Apache, MySQL, PHP & PEAR, Perl, ProFTPD, phpMyAdmin, OpenSSL, GD, Freetype2, libjpeg, libpng, gdbm, zlib, expat, Sablotron, libxml, Ming, Webalizer, pdf class, ncurses, mod_perl, FreeTDS, gettext, mcrypt, mhash, eAccelerator, SQLite and IMAP C-Client.

    It's very easy to install, and is set up to be easily a


  • 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?

Slashdot Top Deals

"Say yur prayers, yuh flea-pickin' varmint!" -- Yosemite Sam

Close