Re: consider reopening 1.3
On Sat, 2003-11-29 at 03:00, Sami Tikka wrote: > [EMAIL PROTECTED] wrote: > About re-opening 1.3 tree: I'm not sure I understand what is the big > deal. This is open source. You want to work on 1.3, go do it. Your > patches are not getting into ASF repository? Create your own. There are > other open source projects that have started ignoring patches and it has > caused a competing code fork to emerge. I don't see it necessarily as an > evil thing. It is called evolution. If patches were streaming on for 1.3 it would be a no-brainer to 're-open' the 1.3 tree. Re-opening is a misnomer IMHO. The tree was declared in maintenance mode, meaning no new features, only bugfixes. We could lift that restriction if there was real development effort instead of just talk. > (I guess if you start your own repository, you can no longer call it > Apache, but any other name of an american indian tribe should be ok. :) Careful there. American Indian tribes take pride in their name, which should be taken into consideration. Don't just go picking any name. As for calling a fork 'Apache', indeed you can't. I personally wonder about the market for a fork. If people aren't showing up here with feature requests and patches, then why would you think they will show up elsewhere? Sander > -- Sami Tikka >
Re: consider reopening 1.3
[EMAIL PROTECTED] wrote: I popped off and looked at 2.0 code again just now and I can tell you right now it's (still) the filtering that's killing it. I am a novice (written 2 modules for apache 1.3 and 1 for 2.0) but I have examined the apache 2.0 code quite a lot during the last year and I believe this is what happens in 2.0 with static pages: 1. Some core handler creates a bucket-brigade, creates a file bucket referring to the static file and inserts the bucket into the brigade. (Well, it also appends an EOS bucket). The handler passes the brigade to the first output filter. 2. In the basic setup the first filter is probably the CONTENT_LENGTH, which asks the file bucket how long it is and sets Content-Length header in r->headers_out table. Brigade is passed to next filter. 3. ...which is probably HTTP_HEADER filter, which reads r->headers_out and generates the response header. This probably means allocating a couple of memory buckets for the it. The buckets are prepended to the brigade. Pass to next filter. 4. ... which will be CORE output filter, which pumps out the buckets containing the header using writev() and does a single sendfile() call for transmitting the file bucket. As I see it, this is as efficient as it can be. Nothing is copied needlessly. The buckets containing the header might be allocated from a heap (= "allocator"), even though stack would be more efficient. (Oh, they might come from the stack, I'm too tired to see what goes on under the hood.) I never had to learn the BUFF API in 1.3 but it is hard to imagine it being more efficient than this. This design is, I think, similar to the mbufs in *BSD kernel and skbuffs in the Linux kernel and it seems to work well for them. About re-opening 1.3 tree: I'm not sure I understand what is the big deal. This is open source. You want to work on 1.3, go do it. Your patches are not getting into ASF repository? Create your own. There are other open source projects that have started ignoring patches and it has caused a competing code fork to emerge. I don't see it necessarily as an evil thing. It is called evolution. (I guess if you start your own repository, you can no longer call it Apache, but any other name of an american indian tribe should be ok. :) -- Sami Tikka
Re: consider reopening 1.3
Igor Kovalenko wrote: I am just lurking here really... but a while back I did try to post some patches dealing with QNX support to both Apache and PHP. In my humble opinion, there was a world of difference in attitude that I have encountered in those two projects. The attitude of PHP folks was 'you can commit patches so long as you stand by to fix anything you break right away' (hey Rasmus :). The very atmosphere was rather welcoming. Hell, they even put me onto the credits page at the time and I did not even think myself that I did that much. You'll see some movement in the right direction. You can look in CHANGES for the names of non-core developers (people with e-mail addresses listed) and see that we have the general willingness to accept contributions; but we have had big problems losing sight of ones that weren't highly interesting to a core developer.
Re: consider reopening 1.3
On Sun, 2003-11-16 at 01:12, Glenn wrote: > Ok, so Apache2 uptake is slower than desired for some (not all) on this > list. That's only logical given the success and therefore inertia to stay > with Apache 1.3. But there are more than a few other factors mentioned in > recent threads that are contributing to Apache2 development stagnation. > Ignore for a moment that vendors have only recently begun shipping Apache2 > as the default web server instead of Apache 1.3. Stas pointed out some > serious problems. I reformulate them slightly differently here. > > - lack of clear leadership That is a property of our development model. > and even basic direction scratch-an-itch development is fine and good, but > not in total chaos The product is pretty mature. The scratch-an-itch is mostly due to bugreports, or own bug discovery. > - cathedral development > it appears that more than a few serious discussions have not happened > on-list and instead happen on IRC or elsewhere (board rooms?) without > apprising the list of what transpired. (Or have there been absolutely > no recent design discussions?) This keeps comming back and back. Yes, there are some loose discussions on IRC sometimes. But nothing is being hashed out there. Most of it is brought back to the list. And at ApacheCon there are bound to be more discussions, given there will be a large chunk of developers present. [...] > - insufficient (developer) documentation > sure, there's the source, but it takes a lot longer to wrap ones head > around the Apache2 paradigms than it did for Apache 1.3 BUFFs and such. > The barrier to entry is much higher; solid design documents would be > infinitely helpful This is being worked on. Also, documentation patches are always more than welcome... > - dwindling community > The apache-dev list focus on 2.0 /to the detriment of 1.3/ is at odds > with the rest of the world that relies on the venerable Apache 1.3 For a group of developers, whose time can be only spent once, it seems no more than logical that they move on to the newest project. Further, the 1.3 tree is still in maintenance mode, and releases _do_ go out. > - ... > > Whether or not you take issue with any of the above and can provide > (quite reasonable) defenses, I think you'll agree that the problems > above exist to some degree or another. My driving point is that > action needs to be taken to keep this community fresh and vibrant. Sometimes taking some time off is considered a good action aswell. It may even be the case that some of us are taking time off, just to return fresh. > Since there is not enough time for the project leaders to address these > issues by themselves, the obvious answer is that there needs to be more > people involved to help shoulder these tasks. The pool of resources in the Open Source world is smaller as one thinks. For instance, do a cross-reference between projects and notice names coming back, over and over again. If you really think that there are people interested in this project, and even have the required skillset to make a difference, why aren't they here, knocking down our doors? > So where do we go from here? > > *** We need better patch management > > Some suggestions were made in recent threads; I won't relist them here, > but they have my full +1 support. I hope those at ApacheCon hash > something great out. > > *** We need to get back many of the disenfranchised Apache 1.3 developers > > Killing Apache 1.3 is not a good option. There is a strong "business" > need in many places to stay with Apache 1.3. Who said anything about killing? The 1.3 tree is maintenance mode. That means, bug fixes only, no new features. > The better option is reopening the 1.3 tree. > Release 1.4 and open a 1.5 dev tree, with the specific intent on > having the 1.4 release eventually map _directly_ into a _seamless_ > upgrade to Apache 2.x, with very easy and clear directions for using > a reverse proxy for those legacy 1.3 third-pary modules.) While > upgrading is not hard for developers, Apache is not a simple product. > We need an even-better (tm) way to get users from There (Apache 1.3) > to Here (Apache 2.x). Yes, more trees are extra work, but this > community is rapidly deteriorating without them. Ahum, let me understand this correctly... You are suggesting that we spread out our scarce resources over even more trees? What do you think will happen if we do that? If there is more work to be done, in basically the same time, by the same people, won't progress slow down even more? > *** We need to get more people using Apache 2.x Now that seems like a wise remark. This is happening step by step, we're nicely ramping up. > Apache 2.x is not going to get any better than it is now until more > people start using it in the real world (outside the lab). Welcoming > back the 1.3 developers and aiding the transition is one piece. > Making this forum more responsive (e.g. with
distcache (was RE: consider reopening 1.3)
On November 17, 2003 02:22 pm, Bill Stoddard wrote: > application environments. Being able to eliminate 1 machine in 3 due to > scalability improvements in 2.0 probably won't be a sufficient return > on investment for most folks. A really kick-ass load balancing/active > fail-over feature in mod_proxy might generate some interest in 2.0 > deployed in the DMZ (features like this are significantly easier to > implement in threaded webservers). Which reminds me, I must find someone who would be prepared to discuss our distributed session caching stuff (ww.distcache.org) for use with apache2/mod_ssl. Any takers? There are companies out there flogging pretty lame and expensive SSL load-balancers and if you're running more than one machine for https, you're almost obliged to go down that route even if it hurts all your rational sense. If scalability and architectural flexibility are part of the argument for 2.0, would it be advantageous to get distcache support included into apache? Mandrake and Redhat already have (optional) support in their SRPMS, FWIW. The apache glue to the distcache API is a pretty small patch - an autoconf check plus an additional caching module/syntax in modules/ssl/. Use of the alternative session cache mode is via an alternative syntax to the SSLSessionCache configuration parameter. We upgraded the httpd patch to 2.0.48 recently, but on the distcache side we are in the midst of trying to move the "development" branch to "stable" before chasing down integration too hard. Last time I looked into getting our patch into the upstream code, there were one or two fairly important unresolved bugs in distcache and apache's autoconf support for openssl/ssl-c needed quite a bit of reorganisation. I helped with the latter at that time, and we sorted out the remaining issues in distcache shortly after. So ... if there's anyone on the apache side who'd be prepared to look deeper into this and discuss integration with apache, please make contact with me off the list. Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/
Re: consider reopening 1.3
+1 My only concern is that some scarce resource might be further dissipated by having multiple forks in progress. I had some sympathy when 2.0 was trying to get started that 1.3 was a competitor for attention; I don't think that's a problem any more. How audacious to be on 1.3? Time will tell. I see no need for a plan.
Re: consider reopening 1.3
At 07:32 PM 11/16/2003, Martin Kraemer wrote: >...only that tomorrow's apr might not be 100% compatible with today's. >Think of mod_ssl's and mod_dav's problem (the apache_1.3 version). They >must always add the apache_1.3 version number to their own version number >to describe the API they require. I would not like a > apache-1.3.30-mod_ssl-2.8-20-apr-1.0.14 kind of delivery scheme. Of course not. mod_ssl's legacy goes to apache's legacy of breaking compatibility early and often when it made things better/easier/simpler. Apache 2.0 and APR 0.9 (soon 1.0) have avoided that approach as best as possible (the poll API being the big exception.) If you need apache 2.0 you need apr 0.9. The API should be stable. If you need apache 2.2 you will need apr 1.0 (or 1.1 if changes happen to make 2.2 a possibility). And within a given point release, apache 2.2 or apr 1.1, nothing will be broken. That's the contract we are aiming for to avoid the very headache you describe above. Bill
RE: Antw: RE: consider reopening 1.3
>> then *what* is the driver for 1.4 over 2.x?? Right now I think it's unknown - but with some reasoned debate I think a path will emerge. One other thought - Apache needs an enemy - and I mean this in the nicest possible terms. Having been on the receiving end of the forums venom before I know how everybody responds to a threat. With 66% market share and IIS the only real threat, why does everyone come to work in the morning. Larry Ellison said it best in "Softwars" - "we pick our enemies very carefully." I think this is an important point because it gives you focus and reason for being. 2.x is adrift because there is no threat to it apart from apathy - so what do you do to get the focus back on Apache? Personally I think the driver for 1.4 over 2.x is 64-bit because that's what people are going to be buying next. 64-bit offers you three things: 1. Performance 1-4 IPC (instructions per cycle 2. Memory >4GB RAM 3. Security Sun, AMD, PowerPC all offer 1 & 2, Itanium offers you 6-8 IPC and some very sophisticated security capabilities not found in any other chip architecture. The downside of Itanium is it's perception in the market place. Intel has done a terrible job of marketing it - however they do have to protect the Pentium cash cow. This will all change sometime next year with the btrans software which will give you Xeon performance for x86 programs running under the EPIC architecture. Regards, Peter -Original Message- From: Jim Jagielski [mailto:[EMAIL PROTECTED] Sent: Monday, November 17, 2003 12:05 PM To: [EMAIL PROTECTED] Subject: Re: Antw: RE: consider reopening 1.3 Glenn wrote: > > On Mon, Nov 17, 2003 at 01:31:55PM -0500, Bill Stoddard wrote: > > Apache 1.4, an APR'ized version of Apache 1.3 (to pick up IPV6 and 64 bit > > support) with all the Windows specific code stripped out and source > > compatability (to the extent possible) with Apache 1.3 modules would > > probably see rapid uptake. I can't say that thrills me but it's probably > > true... > > +1 > Again, unless there is 100% binary compatibility, which I do NOT see with 1.4, then *what* is the driver for 1.4 over 2.x?? -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
Re: Antw: RE: consider reopening 1.3
Jim Jagielski wrote: Look at the impact of not having 2.0 modules severely limited the acceptance of 2.0. Not having 1.4 modules will most certainly do the same*. If 1.4 == 1.3, binary-wise, then it's a non-issue; if not, it's a *major* issue. * Yes, part of the delay was due to porting, which may not be one with 1.4. But we are *still* talking about distribution, support, etc.. of a load of modules. In my experience, there are a lot of people out there who are running older versions of application servers, and upgrading to Apache v2.0 would also mean upgrading to a newer application server release that supports Apache v2.0. The questions asked were invariably "our app server (and associated dependancy on v1.3) works now, so why upgrade?". Regards, Graham --
Re: Antw: RE: consider reopening 1.3
On Nov 17, 2003, at 3:17 PM, Rasmus Lerdorf wrote: As someone working in a company like that, I can tell you definitively that this is not true. At least not here at the biggest web company in the world. -Rasmus Well, I can certainly say that with respect to many, many of the clients I've worked with, it most certainly *is* the case. Not having a WebLogic or WebSphere DSO, for example, puts 'em in a world of hurt. Big time. Look at the impact of not having 2.0 modules severely limited the acceptance of 2.0. Not having 1.4 modules will most certainly do the same*. If 1.4 == 1.3, binary-wise, then it's a non-issue; if not, it's a *major* issue. * Yes, part of the delay was due to porting, which may not be one with 1.4. But we are *still* talking about distribution, support, etc.. of a load of modules.
Re: Antw: RE: consider reopening 1.3
* Rasmus Lerdorf <[EMAIL PROTECTED]> wrote: > As someone working in a company like that, I can tell you definitively > that this is not true. At least not here at the biggest web company in > the world. *shrug* Big or not, if it's the only one, it can develop the stuff it needs itself. I personally don't see the need to do the dirty work for the biggest web company in the world. nd
Re: Antw: RE: consider reopening 1.3
On Mon, 17 Nov 2003, Jim Jagielski wrote: > On Nov 17, 2003, at 2:22 PM, Bill Stoddard wrote: > > > > In this economic environment (and perhaps this will turn out to be > > generally true from now on), companies are not making investments in > > IT unless they can get a proven and almost immediate return on that > > investment. Making the jump to Apache 2.0 -can- be a big investment > > (depending on how many custom/third party modules you use) > > Most people with those big investments are using at least *some* 3rd > party > modules. Having a 1.4 that is not binary compatible with 1.3 > means that those 3rd party modules will need to be (at least) > re-compiled for 1.4. So they will need to worry about 1.3, > 1.4 and 2.0 (and potentially 2.2)... That's an *awful* lot > to have people keep track of. I don't see companies out > there wanting to do that... they will maintain their 1.3 > modules for awhile, and their 2.x ones, because it *is* > the next gen, but I think they would avoid 1.4 almost > totally. > > Having 1.4 not be binary compatible with 1.3 severely limits its > usefulness to those exact people that it's supposed to be > helping. As someone working in a company like that, I can tell you definitively that this is not true. At least not here at the biggest web company in the world. -Rasmus
Re: Antw: RE: consider reopening 1.3
On Nov 17, 2003, at 2:22 PM, Bill Stoddard wrote: In this economic environment (and perhaps this will turn out to be generally true from now on), companies are not making investments in IT unless they can get a proven and almost immediate return on that investment. Making the jump to Apache 2.0 -can- be a big investment (depending on how many custom/third party modules you use) Most people with those big investments are using at least *some* 3rd party modules. Having a 1.4 that is not binary compatible with 1.3 means that those 3rd party modules will need to be (at least) re-compiled for 1.4. So they will need to worry about 1.3, 1.4 and 2.0 (and potentially 2.2)... That's an *awful* lot to have people keep track of. I don't see companies out there wanting to do that... they will maintain their 1.3 modules for awhile, and their 2.x ones, because it *is* the next gen, but I think they would avoid 1.4 almost totally. Having 1.4 not be binary compatible with 1.3 severely limits its usefulness to those exact people that it's supposed to be helping.
Re: Antw: RE: consider reopening 1.3
Rasmus Lerdorf wrote: On Mon, 17 Nov 2003, Bill Stoddard wrote: Apache 1.4, an APR'ized version of Apache 1.3 (to pick up IPV6 and 64 bit support) with all the Windows specific code stripped out and source compatability (to the extent possible) with Apache 1.3 modules would probably see rapid uptake. I can't say that thrills me but it's probably true... Not sure why providing useful software wouldn't thrill you. Don't read too much into that comment. 1.3 is just so damn crufty in many respects as compared to 2.0 that it offends my senses. But 1.3 has some significant strengths in its favor. 2.0.recent is pretty darn stable (at least with the threaded MPM) and is backward compatable with binaries compiled with releases as early as 2.0.42. But the filter API in 2.0 is just horribly complex (IMHO) and takes a -lot- of effort to master. Speculation. In this economic environment (and perhaps this will turn out to be generally true from now on), companies are not making investments in IT unless they can get a proven and almost immediate return on that investment. Making the jump to Apache 2.0 -can- be a big investment (depending on how many custom/third party modules you use) and that investment will not be made unless 2.0 enables some fundamental new business processes not possible with 1.3. I would venture that most of those kinds of investments are being made in Java, .Net or PHP application environments. Being able to eliminate 1 machine in 3 due to scalability improvements in 2.0 probably won't be a sufficient return on investment for most folks. A really kick-ass load balancing/active fail-over feature in mod_proxy might generate some interest in 2.0 deployed in the DMZ (features like this are significantly easier to implement in threaded webservers). I think the point here is that someone is eventually going to do this. Would be nicer to have it under our control than have it leave the ASF. You probably have a much better read on this than most of the folks here. I'd like to believe that ipv6, threading and 64 bit support is the catalyst that will get many folks over to 2.0. Dunno tho... -Rasmus Bill
Re: Antw: RE: consider reopening 1.3
On Mon, 17 Nov 2003, Jim Jagielski wrote: > Glenn wrote: > > > > On Mon, Nov 17, 2003 at 01:31:55PM -0500, Bill Stoddard wrote: > > > Apache 1.4, an APR'ized version of Apache 1.3 (to pick up IPV6 and 64 bit > > > support) with all the Windows specific code stripped out and source > > > compatability (to the extent possible) with Apache 1.3 modules would > > > probably see rapid uptake. I can't say that thrills me but it's probably > > > true... > > > > +1 > > > > Again, unless there is 100% binary compatibility, which I do NOT > see with 1.4, then *what* is the driver for 1.4 over 2.x?? Why binary compatibility? Recompiling a module is a hell of a lot easier than rewriting it. -Rasmus
Re: Antw: RE: consider reopening 1.3
On Nov 17, 2003, at 1:31 PM, Bill Stoddard wrote: Colm MacCarthaigh wrote: On Mon, Nov 17, 2003 at 11:01:46AM -0700, Peter J. Cranstone wrote: Oh yes - forgot about v6... that's a must have for Apache. Is it available for 1.x? If not that would be the first feature to add. The KAME project has IPv6 patches for 1.3.* at ftp://ftp.kame.net/pub/kame/misc/ they work on KAME (ie *BSD) stacks but have issues on platforms without INET6_V6ONLY support (but just about work). linux.or.jp used to maintain an alternative patch with v6 support, but that's since gone. The patches are all truly horrendous. APR has a much better model for all of this. Apache 1.4, an APR'ized version of Apache 1.3 (to pick up IPV6 and 64 bit support) with all the Windows specific code stripped out and source compatability (to the extent possible) with Apache 1.3 modules would probably see rapid uptake. I can't say that thrills me but it's probably true... Once we break binary compatibility, and with the above definition of 1.4 I think that's a certainty, then I don't see the big "reason" for a 1.4 over 2.0. There's a big diff, IMO, between opening up development on 1.3 and trying to make 1.3 a 2.0-lite.
Re: Antw: RE: consider reopening 1.3
Glenn wrote: > > On Mon, Nov 17, 2003 at 01:31:55PM -0500, Bill Stoddard wrote: > > Apache 1.4, an APR'ized version of Apache 1.3 (to pick up IPV6 and 64 bit > > support) with all the Windows specific code stripped out and source > > compatability (to the extent possible) with Apache 1.3 modules would > > probably see rapid uptake. I can't say that thrills me but it's probably > > true... > > +1 > Again, unless there is 100% binary compatibility, which I do NOT see with 1.4, then *what* is the driver for 1.4 over 2.x?? -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
Re: Antw: RE: consider reopening 1.3
On Mon, Nov 17, 2003 at 01:31:55PM -0500, Bill Stoddard wrote: > Apache 1.4, an APR'ized version of Apache 1.3 (to pick up IPV6 and 64 bit > support) with all the Windows specific code stripped out and source > compatability (to the extent possible) with Apache 1.3 modules would > probably see rapid uptake. I can't say that thrills me but it's probably > true... +1 How can I help? Break it into bite-sited tasks and I'll do some munching. Thanks! Glenn
Re: Antw: RE: consider reopening 1.3
On Mon, 17 Nov 2003, Bill Stoddard wrote: > Apache 1.4, an APR'ized version of Apache 1.3 (to pick up IPV6 and 64 bit support) > with all the Windows > specific code stripped out and source compatability (to the extent possible) with > Apache 1.3 modules would > probably see rapid uptake. I can't say that thrills me but it's probably true... Not sure why providing useful software wouldn't thrill you. I think the point here is that someone is eventually going to do this. Would be nicer to have it under our control than have it leave the ASF. -Rasmus
Re: Antw: RE: consider reopening 1.3
Colm MacCarthaigh wrote: On Mon, Nov 17, 2003 at 11:01:46AM -0700, Peter J. Cranstone wrote: Oh yes - forgot about v6... that's a must have for Apache. Is it available for 1.x? If not that would be the first feature to add. The KAME project has IPv6 patches for 1.3.* at ftp://ftp.kame.net/pub/kame/misc/ they work on KAME (ie *BSD) stacks but have issues on platforms without INET6_V6ONLY support (but just about work). linux.or.jp used to maintain an alternative patch with v6 support, but that's since gone. The patches are all truly horrendous. APR has a much better model for all of this. Apache 1.4, an APR'ized version of Apache 1.3 (to pick up IPV6 and 64 bit support) with all the Windows specific code stripped out and source compatability (to the extent possible) with Apache 1.3 modules would probably see rapid uptake. I can't say that thrills me but it's probably true... Bill
Re: Antw: RE: consider reopening 1.3
On Mon, Nov 17, 2003 at 11:01:46AM -0700, Peter J. Cranstone wrote: > Oh yes - forgot about v6... that's a must have for Apache. Is it available > for 1.x? If not that would be the first feature to add. The KAME project has IPv6 patches for 1.3.* at ftp://ftp.kame.net/pub/kame/misc/ they work on KAME (ie *BSD) stacks but have issues on platforms without INET6_V6ONLY support (but just about work). linux.or.jp used to maintain an alternative patch with v6 support, but that's since gone. The patches are all truly horrendous. APR has a much better model for all of this. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
RE: Antw: RE: consider reopening 1.3
Oh yes - forgot about v6... that's a must have for Apache. Is it available for 1.x? If not that would be the first feature to add. Peter -Original Message- From: Andre Schild [mailto:[EMAIL PROTECTED] Sent: Monday, November 17, 2003 10:07 AM To: [EMAIL PROTECTED] Subject: Antw: RE: consider reopening 1.3 >People will move Apache 1.x to this platform because there is virtually NO >migration cost (i.e. recoding modules etc) and they get a performance boost >and while replacing an aging infrastructure. >12 million user on the move - make it easy for them, buy a cheap AMD Opteron >and optimize and improve Apache 1.4 on that box. Today perhaps, but tomorrow with IPv6 ? André aarboard ag internet - networks - screen&print design - multimedia Egliweg 10 - Postfach 214 - CH-2560 Nidau (Switzerland) Phone +41 32 332 9714 - Fax +41 32 332 9715 www.aarboard.ch - [EMAIL PROTECTED]
Antw: RE: consider reopening 1.3
>People will move Apache 1.x to this platform because there is virtually NO >migration cost (i.e. recoding modules etc) and they get a performance boost >and while replacing an aging infrastructure. >12 million user on the move - make it easy for them, buy a cheap AMD Opteron >and optimize and improve Apache 1.4 on that box. Today perhaps, but tomorrow with IPv6 ? André aarboard ag internet - networks - screen&print design - multimedia Egliweg 10 - Postfach 214 - CH-2560 Nidau (Switzerland) Phone +41 32 332 9714 - Fax +41 32 332 9715 www.aarboard.ch - [EMAIL PROTECTED]
Re: consider reopening 1.3
> On Sun, 16 Nov 2003, Jeff Trawick wrote: > > Too bad all these supposedly-disenfranchised people aren't around to review 1.3 > > fixes. 1.3 would be healthier if they were. > > And it is the reason for why they are not around that is in question here. > Why wouldn't there be plenty of hackers around for a piece of software > used to widely? Blaming the hackers seems a bit shortsighted. Have a > look at the environment we have given them to operate in and at some of > the responses over the years people have gotten when they suggested new > features for 1.3. > I am just lurking here really... but a while back I did try to post some patches dealing with QNX support to both Apache and PHP. In my humble opinion, there was a world of difference in attitude that I have encountered in those two projects. The attitude of PHP folks was 'you can commit patches so long as you stand by to fix anything you break right away' (hey Rasmus :). The very atmosphere was rather welcoming. Hell, they even put me onto the credits page at the time and I did not even think myself that I did that much. With the Apache, you don't get to commit. Which is fine too, so long as someone is managing patch submissions. I got one initial reply that objected the patch on the grounds that were arguable. Then I followed up with a refined patch, but never got any more replies, even after posting it 3 times. So, perhaps that patch was not that interesting to the core developers. Understandable, but then almost every minor patch is not so interesting to the majority. If you cut them all for that reason, you get the situation that you have now. Then I should note, situation was not always the same. Years before (that is, before 2.0 branch) I did another patch of that sort and it went in just fine. Again, I can quite understand the desire of core developers to concentrate on the new branch, rather than do gruesome work on that old-hopelessly-obsolete-code-that-you-do-not-like-anymore. The only trouble really is that 2.0 branch has failed to interest that many users. Why is a big question, but I think from end-user perspective one major reason is that it simply does not add much that's really worth moving. Architectural elegance is important to developers (and there is nothing I personally like more) but end users tend to treat it like their cars. Most of them don't ever look under the hood. Feel free to laugh, but if you want users 'pay' (that is take pain of moving) for that new wonderful engine in the 2.0, you need to show them a carrot in form of those heated memory seats, self-dimming mirrors, rainsensitive wipers, et cetera. Or at least it should drive faster, which (last time I checked) it did not. Regards, -- igor
RE: consider reopening 1.3
To support my comments on cheap 64-bit computing see this link: http://www.siliconvalley.com/mld/siliconvalley/7281990.htm Sun, AMD announce plans for line of low-cost servers - 64-bit! People will move Apache 1.x to this platform because there is virtually NO migration cost (i.e. recoding modules etc) and they get a performance boost and while replacing an aging infrastructure. 12 million user on the move - make it easy for them, buy a cheap AMD Opteron and optimize and improve Apache 1.4 on that box. Regards, Peter -Original Message- From: Peter J. Cranstone [mailto:[EMAIL PROTECTED] Sent: Monday, November 17, 2003 7:18 AM To: [EMAIL PROTECTED] Subject: RE: consider reopening 1.3 Bill, I've done some thinking about this - price/performance is only "part" of the equation. Someone needs to take a step back and see where Apache wants to *be* in two years time. I agree with Jim that 1.x probably is just about done, it works, people understand it and have ported their modules to it, and performance is good enough. So that leaves you with 2.x The debate will rage on whether it's faster than 1.x, but the benchmarking is a slippery slope and we've all been down it at some time. Personally I think you have to focus on the customer via market segment. The super user who wants to play with Apache 2.x work out the kinks, port his modules and really fine tune it. That's about 1/10 of 1% of your addressable market. He is not going to pull this product into the mainstream market. Therefore who is your classic Apache user and what does he want that he can't get right now? Probably not much. Let me use mod_gzip as an example. When we released it we were busy for about 4 months fixing it for the real world i.e. with a ton of feedback. Since then (over 2 years) we haven't touched it, why? Because it does all it needs to do and people are happy with the status quo. How do we improve on that? While I'm sure we can come up with a few ideas will people buy into it? I can't justify the resources in this economy to find out. Right now the status quo is prevailing with 1.x and 2.x is not a "must have". To prove my point look no further than Covalent. When money is on the table the rules change. Covalent have not been able to monetize 2.x in the way everyone thought it could be done. Therefore what has the current management team done - change direction to the new focus of web application management and security. Sure there's still a web server in their somewhere but now there's a different agenda i.e. make money for the shareholders. So what would I do... Apache 1.x - mass market - status quo prevails - boring but stable Apache 2.x - tiny market - **risk takers only** - not stable enough, tough to understand So what's the differentiator that drives the next wave? Personally (my opinion only guys) it's hardware. 64-bit is now here. There are only going to be a few choices. Either Sun, AMD, PowerPC or Itanium. Sun has had 64-bit for a long time and is already entrenched at the web edge. AMD adds CISC compatibility with a hint of RISC. Upside is that it runs x86 code about 10% faster than Pentium PC's. PowerPC is a different beast but runs Apache just fine. AMD, Sun, PowerPC handle between 1-4 instructions per cycle, Itanium (which is a whole new architecture) handles 6-8 instructions per cycle. Bottom line if you code it correctly Itanium is going to be the flat out winner in a drag race. It also happens to run Apache fine and as you've seen from our benchmarks you can really tune this box to do some real magic. That's a differentiator. Up until now there has been one big problem with Itanium - it costs too much. That's going to change. We're coming up to a new hardware cycle (technology adoption life cycle TALC). Machines purchased in 1999 are going to be replaced and people will move to 64-bit. Why because we all like new toys especially if they are cheap. What we don't want is lots of hard work to port our apps. AMD has made this easy and next year Intel will do the same thing for Itanium by releasing btrans (binary translator) which will allow you to run all your x86 apps at Xeon speeds on an Itanium. So what are we going to see - lots of cheap web edge processors and people will start moving their apps etc over. So what's the opportunity for Apache. My opinion only - optimize it for 64-bit. Focus 80% of your available resources on Apache 1.x because it has such a HUGE user base. The remaining 20% of your resources should focus on 2.x Why? Because it's still too darn difficult to move people's apps to the 2.x architecture. They will continue to take the path of least resistance which means hardware. If you want to drop 1.3 and focus on 1.4 then make it for 64-bit, because it gives you a hardware performance boost. It's all about focus and market segme
RE: consider reopening 1.3
Bill, I've done some thinking about this - price/performance is only "part" of the equation. Someone needs to take a step back and see where Apache wants to *be* in two years time. I agree with Jim that 1.x probably is just about done, it works, people understand it and have ported their modules to it, and performance is good enough. So that leaves you with 2.x The debate will rage on whether it's faster than 1.x, but the benchmarking is a slippery slope and we've all been down it at some time. Personally I think you have to focus on the customer via market segment. The super user who wants to play with Apache 2.x work out the kinks, port his modules and really fine tune it. That's about 1/10 of 1% of your addressable market. He is not going to pull this product into the mainstream market. Therefore who is your classic Apache user and what does he want that he can't get right now? Probably not much. Let me use mod_gzip as an example. When we released it we were busy for about 4 months fixing it for the real world i.e. with a ton of feedback. Since then (over 2 years) we haven't touched it, why? Because it does all it needs to do and people are happy with the status quo. How do we improve on that? While I'm sure we can come up with a few ideas will people buy into it? I can't justify the resources in this economy to find out. Right now the status quo is prevailing with 1.x and 2.x is not a "must have". To prove my point look no further than Covalent. When money is on the table the rules change. Covalent have not been able to monetize 2.x in the way everyone thought it could be done. Therefore what has the current management team done - change direction to the new focus of web application management and security. Sure there's still a web server in their somewhere but now there's a different agenda i.e. make money for the shareholders. So what would I do... Apache 1.x - mass market - status quo prevails - boring but stable Apache 2.x - tiny market - **risk takers only** - not stable enough, tough to understand So what's the differentiator that drives the next wave? Personally (my opinion only guys) it's hardware. 64-bit is now here. There are only going to be a few choices. Either Sun, AMD, PowerPC or Itanium. Sun has had 64-bit for a long time and is already entrenched at the web edge. AMD adds CISC compatibility with a hint of RISC. Upside is that it runs x86 code about 10% faster than Pentium PC's. PowerPC is a different beast but runs Apache just fine. AMD, Sun, PowerPC handle between 1-4 instructions per cycle, Itanium (which is a whole new architecture) handles 6-8 instructions per cycle. Bottom line if you code it correctly Itanium is going to be the flat out winner in a drag race. It also happens to run Apache fine and as you've seen from our benchmarks you can really tune this box to do some real magic. That's a differentiator. Up until now there has been one big problem with Itanium - it costs too much. That's going to change. We're coming up to a new hardware cycle (technology adoption life cycle TALC). Machines purchased in 1999 are going to be replaced and people will move to 64-bit. Why because we all like new toys especially if they are cheap. What we don't want is lots of hard work to port our apps. AMD has made this easy and next year Intel will do the same thing for Itanium by releasing btrans (binary translator) which will allow you to run all your x86 apps at Xeon speeds on an Itanium. So what are we going to see - lots of cheap web edge processors and people will start moving their apps etc over. So what's the opportunity for Apache. My opinion only - optimize it for 64-bit. Focus 80% of your available resources on Apache 1.x because it has such a HUGE user base. The remaining 20% of your resources should focus on 2.x Why? Because it's still too darn difficult to move people's apps to the 2.x architecture. They will continue to take the path of least resistance which means hardware. If you want to drop 1.3 and focus on 1.4 then make it for 64-bit, because it gives you a hardware performance boost. It's all about focus and market segmentation - Covalent just learned the hard way, even with mod_compat to make your 1.x modules run in a 2.x environment they couldn't sell something with a delta of over a 1,000 dollars over something that is free. So they switched gears and went in a different direction. Learn from what they did - you don't need to do the same but don't continue doing what your doing, the message is too confusing. So for Jim J... 1.3 Done12 million happy customers 1.4 64-bit 12 million potential customers 2.x Work in progressnot sure how many customers? I know where I would go. Regards, Peter -----Original Message----- From: Bill Stoddard [mailto:[EMA
Re: consider reopening 1.3
[EMAIL PROTECTED] wrote: > > > Geez... it's nice to discover everybody hasn't just dropped dead! > > I see a lot of healthy 'things to do' coming out of this > thread that could inject a lot of life back into the > development... which is what the various threads the past > few days have all been about. > > Action items?... > > Facts to face?... > Still waiting to see what, exactly, people want to see in 1.3 that isn't there... So far, we've had a small handful of suggestions. It will be curious to see how many of those are "handled" by 2.0... But recall that it is the truth of things that everything has a time to end. I'm not saying that it is the time for 1.3 to be put to bed (and I'm not saying that it's not) but it will be one day. It happened with Apache 1.2. It happened with PHP3. It'll happen soon with PHP4. It happened with RH7. It happened with bind4 and bind8 and sendmail8.9, etc... -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
Re: consider reopening 1.3
[EMAIL PROTECTED] wrote: -- FACT?: Apache 2.0 pre-fork ( which is the only thing still available on some of the best platforms ) is SLOWER than Apache 1.3 pre-fork. -- This gives someone who might be stuck with one of those pre-fork only platforms, or anyone who just WANTS to stick with pre-fork, absolutely NO INCENTIVE to upgrade at all ( ever! ). That statement is just ridiculous. There are many reasons why a person might upgrade to v2.0 - the new functionality offered by the filtering API (mod_cache, mod_deflate and friends), etc etc. And from a performance perspective, I personally would not run a webserver on hardware that was too close to 100% utilised, so the performance problem is normally not a huge one in most cases. Regards, Graham --
Re: 1.3 Wishlist: (Was: Re: consider reopening 1.3)
On Sun, 16 Nov 2003, Rasmus Lerdorf wrote: > On Sun, 16 Nov 2003, Jim Jagielski wrote: > > So a useful topic is: What is *missing* in 1.3 that needs to be > > addressed. > > What are the features/additions that the disenfranchised 1.3 developers > > want to add to 1.3... > > How about support for chunked compressed responses right in > src/main/buff.c where it belongs (given we don't have filters in Apache1) There's mod_deflate module for Apache 1.3.x that patches buff.c and compesses a response on the fly. It's available at http://sysoev.ru/en/ Igor Sysoev http://sysoev.ru/en/
Re: consider reopening 1.3
On Mon, Nov 17, 2003 at 06:00:09AM -0500, [EMAIL PROTECTED] wrote: > Hi Colm... > > Slainte!... > Cead mile failte romhat! > Go raibh maith agat! Agus tú féin a cháirde, chaitfidh mé rá b'éidir gurb seo on t-aon deis a bhéis gam cumarsáid le Gaeilgeoir so comh-théacs seo, ach mar a deartaí áfach - Is annamh is íontach. Actually I must get round to tranlating the errordocs ;) > Wow... I believe everything you are saying... and > please don't take this the wrong way... but I'm not > sure a test that only runs for 1.1 second and 1000 > requests with 100 clients being launched ( on the > same machine? ) is a good way to get accurate results > especially in the TPS ( Transactions Per Second ) > numbers. The rounding errors alone could be huge > with so little time on the clock. Saves me time though ;) It's a quick way to get numbers - and I was trying to be fairer to 1.3, but with 100,000 - Apache 2 prefork: Concurrency Level: 100 Time taken for tests: 100.192136 seconds Complete requests: 10 Failed requests:0 Write errors: 0 Total transferred: 190466640 bytes HTML transferred: 145650960 bytes Requests per second:998.08 [#/sec] (mean) Time per request: 100.192 [ms] (mean) Time per request: 1.002 [ms] (mean, across all concurrent requests) Transfer rate: 1856.45 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect:0 44 12.8 47 134 Processing:22 54 15.7 51 305 Waiting:2 49 15.2 47 304 Total: 29 99 6.6 98 314 Percentage of the requests served within a certain time (ms) 50% 98 66% 99 75%100 80%100 90%104 95%110 98%117 99%126 100%314 (longest request) Apache 1.3: same hardware First try: lasaire:/usr/local/apache# ../apache2/bin/ab -c 100 -n 10 http://samhain:8080/ This is ApacheBench, Version 2.0.40-dev <$Revision: 1.131 $> apache-2.0 Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/ Benchmarking samhain (be patient) apr_poll: The timeout specified has expired (70007) Total of 4060 requests completed Second attempt: Concurrency Level: 100 Time taken for tests: 188.725417 seconds Complete requests: 10 Failed requests:0 Write errors: 0 Total transferred: 187087890 bytes HTML transferred: 145668432 bytes Requests per second:529.87 [#/sec] (mean) Time per request: 188.725 [ms] (mean) Time per request: 1.887 [ms] (mean, across all concurrent requests) Transfer rate: 968.09 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect:0 87 23.0 90 178 Processing: 4 99 25.3 97 751 Waiting:1 93 24.0 91 690 Total: 10 187 8.9186 847 Percentage of the requests served within a certain time (ms) 50%186 66%188 75%189 80%190 90%194 95%201 98%206 99%209 100%847 (longest request) And this benchmark is light compared to what we see as production load. I could run the benchmarks into the many millions, but it's not going to make a difference. > Rasmus recent benchmark shows the EXACT > OPPOSITE and I think you have certainly just proved > that something is seriously wrong with THAT test... > but I'm not sure yours is the end-all be-all proof either. They're different tests, it's not uncommon for different tests to have different results. The atomics around dynamic content are very different from static, Apache 2.0 kicks 1.3 ass when it comes to static content. When I migrate dynamic content to 2.0 I don't see the same improvment, but I do see some. Then again, I'm a heavy user of suexec stype dymanic content rather than modules. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: consider reopening 1.3
Hi Colm... Slainte!... Cead mile failte romhat! Go raibh maith agat! Wow... I believe everything you are saying... and please don't take this the wrong way... but I'm not sure a test that only runs for 1.1 second and 1000 requests with 100 clients being launched ( on the same machine? ) is a good way to get accurate results especially in the TPS ( Transactions Per Second ) numbers. The rounding errors alone could be huge with so little time on the clock. Try same test for a reasonable amount of TIME and see if it's any different. Rasmus recent benchmark shows the EXACT OPPOSITE and I think you have certainly just proved that something is seriously wrong with THAT test... but I'm not sure yours is the end-all be-all proof either. When I get the chance... I'll run the same ( 6 hour ) benchmark against 2.0.47 that I did sometime back for 2.0.40 and see what that says. At that time... I did the same 'out of the box' thing you just did and got the EXACT OPPOSITE results. Apache 2.0 prefork was about twice as SLOW as 1.3 prefork... not twice as fast. Man, this is confusing. ( Pionta Guiness le do thoil... fer sure ) Later... ( Slainte )... Kevin In a message dated 11/17/2003 4:17:57 AM Central Standard Time, [EMAIL PROTECTED] writes: On Mon, Nov 17, 2003 at 04:40:02AM -0500, [EMAIL PROTECTED] wrote: > Got any real numbers? Completely unconfigured, out of the box configs; Apache 1.3.29; Concurrency Level: 100 Time taken for tests: 2.54841 seconds Complete requests: 1000 Failed requests: 0 Write errors: 0 Total transferred: 1883090 bytes HTML transferred: 1466192 bytes Requests per second: 486.66 [#/sec] (mean) Time per request: 205.484 [ms] (mean) Time per request: 2.055 [ms] (mean, across all concurrent requests) Transfer rate: 894.47 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 1.8 0 13 Processing: 17 193 38.7 196 297 Waiting: 17 192 38.7 196 296 Total: 23 194 37.8 196 297 Percentage of the requests served within a certain time (ms) 50% 196 66% 201 75% 206 80% 209 90% 223 95% 252 98% 272 99% 280 100% 297 (longest request) Apache 2.0.48 (using prefork): Concurrency Level: 100 Time taken for tests: 1.110512 seconds Complete requests: 1000 Failed requests: 0 Write errors: 0 Total transferred: 1909712 bytes HTML transferred: 1460368 bytes Requests per second: 900.49 [#/sec] (mean) Time per request: 111.051 [ms] (mean) Time per request: 1.111 [ms] (mean, across all concurrent requests) Transfer rate: 1678.51 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 3 3.2 3 13 Processing: 21 100 14.1 103 142 Waiting: 3 96 14.2 100 142 Total: 32 103 11.9 106 143 Percentage of the requests served within a certain time (ms) 50% 106 66% 107 75% 107 80% 108 90% 109 95% 110 98% 114 99% 123 100% 143 (longest request) That's completely unconfigured. Apache 2 is *much* more configurable, and it's possible to make things much faster. It's not just faster, it's capable of scaling much better. Two weeks ago I was sustaining 8,000 simultaneous connections and throughing out a about 300 Meg of traffic. On the same hardware, 1.3 would never get close to that. I used to get problems when dealing with a few hundred connections. And before you ask; pre-fork. Btw, it's not as if you can just disregard the other mpm's. They exist, and they are much faster again than prefork. You can't just ignore progress because it doesn't work on every platform. There are other ways in which 2.0 is much better, mod_*_cache are good examples of how it's possible for admins to serve requests a lot faster, especially if they have slow disks and so on. > Last time I checked... 'sendfile' was not available on all platforms. > What would the numbers look like on those platforms? Much much much better. I turn off sendfile on purpose, because TCP checksum offloading problems with my Gigabit NIC's means I can't use it for IPv6. The friday before last, I was shipping 440Megabit's of traffic from one machine using httpd. That was using pre-fork, without sendfile. The notion that 2.0 does not outperform 1.3 is laughable, it does. Now it may underperform it in some configurations, and a lot of people report that they see slowdown with dynamic content, especially php, but that's not the same thing as saying 2.0 is slower. I'm telling you, it's certainly not in my configuration. -- Colm MacCárthaigh Public Key: [EMAIL PROTECTED]
Re: consider reopening 1.3
On Sun, Nov 16, 2003 at 05:02:12PM -0800, Rasmus Lerdorf wrote: > And a threaded mpm is just not an option. Most humans > are simply not smart enough to write threadsafe code. this is an interesting point. I believe the moving towards threading is wrong. I also find apache2 strongly suspective for the simple size. 1.3 is already bad, but the code size of 2.0 scares me. and honestly, I don't care for windows or netware support. what remains is a IMHO overcomplicated architecture with much too much code, which makes it hard to audit, and gives no benefit to our users. I don't see me importing apache2 into the OpenBSD tree anytime soon. honestly, I don't see that at all. -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: consider reopening 1.3
> You are right, apache 2.0 pre fork is < apache 1.3 prefork... Maybe. Maybe not. My 'FACT?:' header had a QUESTION MARK there. Just in the last 4 or 5 messages on this thread the actual reality has become even more obfuscated. Rasmus seems to be saying it's a pig... but maybe he's simply uncovered a serious I/O problem in mod_perl or something other than the core itself. Colm says the opposite. I DON'T KNOW what the REAL story is. Maybe nobody does. Nobody's bothered to find out for sure. But wouldn't it be nice to know.. since this product has more of a monopoly in it's target market than even Microsoft does in any of theirs? To this day ( almost 2 years after the relase of 2.0 ) no one has done any serious benchmarking... not even Covalent. If they have... I've never seen it. URI? All I know is that last time I (personally) tested Apache 2.0 pre-fork against Apache 1.3 pre-fork the 'new' version was losing hands-down as compared to the 'old' version. 'sendfile' doesn't do jack-squat for you if have a platform that doesn't even fully support it and/or when the responses are dynamic and not static 'files'... which is more and more the reality these days. Your other points are WELL TAKEN. I don't think anyone would say that there should NOT be an MPM for Apache. If you have Natvie threads ( Windows ) or 3rd party threads ( UNIX ) then at least you have options. If you have FreeBSD you are still kinda screwed but I'm sure SOMEONE is going to fix that. In the meantime... while all this is getting hashed out... the subject of the thread is 'consider reopening 1.3'. Whatever else is going on with 2.0... I say +1 to that. Personally... I've always wondered how fast 1.3 could be with full 'sendfile'. Later... Kevin In a message dated 11/17/2003 4:09:37 AM Central Standard Time, [EMAIL PROTECTED] writes: You are right, apache 2.0 pre fork is < apache 1.3 prefork... But one nice feature of apache 2.0 is to provide other mpm more powerfull. worker mpm is > apache 1.3. If you look all benchmark of web server, you will see that all are now providing threaded architectures because it's more stable and faster. Did you see all speed benchmark ? for example IIS 6 is really faster than apache 1.3 and a bit than threaded mpm of apache 2.0. Apache 2.0 is able to run on old plateform not using threaded mpm and also to run "faster" on the lastest plateform using threads... I also read here that companies prefer buy load balancer than take a faster web server... it's right in 50% of them, but not for the 50% of the others who want load balancer + webserver performance. And what about companies not able to buy load balancer, running a webserver for many services, (i think to all these companies selling packaged and hosted webserver) and using a basic linux distribution, or a BSD distrib ? i think they could be happy to use the real power of threads than stay on Apache 1.3. (which one of them not want to announce more power, and more security ?). Apache is fighting against webserver now providing powerfull features _ONLY_ based on threaded architectures. And i think in the future it will be based more and more on this, if not, why all unix kernel are working and now providing thread lib and function more and more powerfull ??? What about all this new features in Apache 2.0 which is oriented (IMHO) for web application, what about the security of them ? the entire and easy control of input and output data due to filters ? Apache 1.3 is working fine yes... but did you see all new features provided by others webserver, based on apps, apps security, and apps speed ? Apache 2.0 is designed to give a solid answer to this, on all actual and future needs. it's just asking to become more and more stable. For me, Apache 1.3 will become more and more stopped to give place to a more powerfull solution, able to run latest applications and features. (I am benchmarking the speed of Apache 2.0 for 1 years and an half now, with a special and dedicated request injector architecture able to simulate connexions, hits, auth etc... And yes, worker mpm is faster than apache 1.3. ) In Apache 2.0 I trust :p regards, Matthieu [EMAIL PROTECTED] wrote: > > Last benchmarks I have currently are quite old. > > I think the last time I ( just a USER of Apache ) did > any serious benchmarking was 2.0.40 or something... > but the results were right inline with what Rasmus > just posted. > > Apache 2.0 pre-fork was a pig compared to Apache 1.3 prefork. > > If I get some time off from my 'real' job in the next little while > I will try and get you some benchmarks... but if you read my > last message you will see that it says... > > > FACT?: <- That's a QUESTION MARK there. > > > - Verify that's it's true. ( seems to be ). You have to > > KNOW, yourselves, where you are on the stopwatch and not > > wait for usrs to tell you. > > - If it's not (true)... do some marketing and make sure people KNOW IT. > >
Re: consider reopening 1.3
On Mon, Nov 17, 2003 at 04:40:02AM -0500, [EMAIL PROTECTED] wrote: > Got any real numbers? Completely unconfigured, out of the box configs; Apache 1.3.29; Concurrency Level: 100 Time taken for tests: 2.54841 seconds Complete requests: 1000 Failed requests:0 Write errors: 0 Total transferred: 1883090 bytes HTML transferred: 1466192 bytes Requests per second:486.66 [#/sec] (mean) Time per request: 205.484 [ms] (mean) Time per request: 2.055 [ms] (mean, across all concurrent requests) Transfer rate: 894.47 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect:00 1.8 0 13 Processing:17 193 38.7196 297 Waiting: 17 192 38.7196 296 Total: 23 194 37.8196 297 Percentage of the requests served within a certain time (ms) 50%196 66%201 75%206 80%209 90%223 95%252 98%272 99%280 100%297 (longest request) Apache 2.0.48 (using prefork): Concurrency Level: 100 Time taken for tests: 1.110512 seconds Complete requests: 1000 Failed requests:0 Write errors: 0 Total transferred: 1909712 bytes HTML transferred: 1460368 bytes Requests per second:900.49 [#/sec] (mean) Time per request: 111.051 [ms] (mean) Time per request: 1.111 [ms] (mean, across all concurrent requests) Transfer rate: 1678.51 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect:03 3.2 3 13 Processing:21 100 14.1103 142 Waiting:3 96 14.2100 142 Total: 32 103 11.9106 143 Percentage of the requests served within a certain time (ms) 50%106 66%107 75%107 80%108 90%109 95%110 98%114 99%123 100%143 (longest request) That's completely unconfigured. Apache 2 is *much* more configurable, and it's possible to make things much faster. It's not just faster, it's capable of scaling much better. Two weeks ago I was sustaining 8,000 simultaneous connections and throughing out a about 300 Meg of traffic. On the same hardware, 1.3 would never get close to that. I used to get problems when dealing with a few hundred connections. And before you ask; pre-fork. Btw, it's not as if you can just disregard the other mpm's. They exist, and they are much faster again than prefork. You can't just ignore progress because it doesn't work on every platform. There are other ways in which 2.0 is much better, mod_*_cache are good examples of how it's possible for admins to serve requests a lot faster, especially if they have slow disks and so on. > Last time I checked... 'sendfile' was not available on all platforms. > What would the numbers look like on those platforms? Much much much better. I turn off sendfile on purpose, because TCP checksum offloading problems with my Gigabit NIC's means I can't use it for IPv6. The friday before last, I was shipping 440Megabit's of traffic from one machine using httpd. That was using pre-fork, without sendfile. The notion that 2.0 does not outperform 1.3 is laughable, it does. Now it may underperform it in some configurations, and a lot of people report that they see slowdown with dynamic content, especially php, but that's not the same thing as saying 2.0 is slower. I'm telling you, it's certainly not in my configuration. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: consider reopening 1.3
You are right, apache 2.0 pre fork is < apache 1.3 prefork... But one nice feature of apache 2.0 is to provide other mpm more powerfull. worker mpm is > apache 1.3. If you look all benchmark of web server, you will see that all are now providing threaded architectures because it's more stable and faster. Did you see all speed benchmark ? for example IIS 6 is really faster than apache 1.3 and a bit than threaded mpm of apache 2.0. Apache 2.0 is able to run on old plateform not using threaded mpm and also to run "faster" on the lastest plateform using threads... I also read here that companies prefer buy load balancer than take a faster web server... it's right in 50% of them, but not for the 50% of the others who want load balancer + webserver performance. And what about companies not able to buy load balancer, running a webserver for many services, (i think to all these companies selling packaged and hosted webserver) and using a basic linux distribution, or a BSD distrib ? i think they could be happy to use the real power of threads than stay on Apache 1.3. (which one of them not want to announce more power, and more security ?). Apache is fighting against webserver now providing powerfull features _ONLY_ based on threaded architectures. And i think in the future it will be based more and more on this, if not, why all unix kernel are working and now providing thread lib and function more and more powerfull ??? What about all this new features in Apache 2.0 which is oriented (IMHO) for web application, what about the security of them ? the entire and easy control of input and output data due to filters ? Apache 1.3 is working fine yes... but did you see all new features provided by others webserver, based on apps, apps security, and apps speed ? Apache 2.0 is designed to give a solid answer to this, on all actual and future needs. it's just asking to become more and more stable. For me, Apache 1.3 will become more and more stopped to give place to a more powerfull solution, able to run latest applications and features. (I am benchmarking the speed of Apache 2.0 for 1 years and an half now, with a special and dedicated request injector architecture able to simulate connexions, hits, auth etc... And yes, worker mpm is faster than apache 1.3. ) In Apache 2.0 I trust :p regards, Matthieu [EMAIL PROTECTED] wrote: Last benchmarks I have currently are quite old. I think the last time I ( just a USER of Apache ) did any serious benchmarking was 2.0.40 or something... but the results were right inline with what Rasmus just posted. Apache 2.0 pre-fork was a pig compared to Apache 1.3 prefork. If I get some time off from my 'real' job in the next little while I will try and get you some benchmarks... but if you read my last message you will see that it says... > FACT?: <- That's a QUESTION MARK there. > - Verify that's it's true. ( seems to be ). You have to > KNOW, yourselves, where you are on the stopwatch and not > wait for usrs to tell you. > - If it's not (true)... do some marketing and make sure people KNOW IT. > - If it is... fix it. Make it NOT TRUE. That's kinda parta the problem right at the moment, isn't it? Apache 2.0 has been out for almost 2 years and nobody seems to be sure WHAT the real performance numbers are??? That's just an indication of how bad the lethargy has become and/or how piss-poor the rollout follow-up on 2.0 has been. Later... Kevin In a message dated 11/17/2003 2:01:13 AM Central Standard Time, [EMAIL PROTECTED] writes: * [EMAIL PROTECTED] wrote: > -- > FACT?: Apache 2.0 pre-fork ( which is the only thing still available on > some of the best platforms ) is SLOWER than Apache 1.3 pre-fork. > -- Do you have a supporting benchmark available? Benchmarking a PHP script as Rasmus did does not express anything about the httpd. Please don't continue to distribute misleading information again and again you know nothing about. nd
Re: consider reopening 1.3
Fantastic! So Rasmus has just uncovered some 'other' problem then which means (only) mod_perl is a pig on 2.0 or something? I guess that's better than the core being the problem. I'd like to see this get put to bed once and for all and eliminate it from the 2.0 migration discussion(s). Got any real numbers? What if sendfile was added to 1.3? I wonder how it would all stack up then? Last time I checked... 'sendfile' was not available on all platforms. What would the numbers look like on those platforms? Later... Kevin In a message dated 11/17/2003 3:02:24 AM Central Standard Time, [EMAIL PROTECTED] writes: On Mon, Nov 17, 2003 at 02:05:33AM -0500, [EMAIL PROTECTED] wrote: > FACT?: Apache 2.0 pre-fork ( which is the only thing still available on > some of the best platforms ) is SLOWER than Apache 1.3 pre-fork. Not for me it's not. Especially with sendfile. -- Colm MacCárthaigh Public Key: [EMAIL PROTECTED]
Re: consider reopening 1.3
Last benchmarks I have currently are quite old. I think the last time I ( just a USER of Apache ) did any serious benchmarking was 2.0.40 or something... but the results were right inline with what Rasmus just posted. Apache 2.0 pre-fork was a pig compared to Apache 1.3 prefork. If I get some time off from my 'real' job in the next little while I will try and get you some benchmarks... but if you read my last message you will see that it says... > FACT?: <- That's a QUESTION MARK there. > - Verify that's it's true. ( seems to be ). You have to > KNOW, yourselves, where you are on the stopwatch and not > wait for usrs to tell you. > - If it's not (true)... do some marketing and make sure people KNOW IT. > - If it is... fix it. Make it NOT TRUE. That's kinda parta the problem right at the moment, isn't it? Apache 2.0 has been out for almost 2 years and nobody seems to be sure WHAT the real performance numbers are??? That's just an indication of how bad the lethargy has become and/or how piss-poor the rollout follow-up on 2.0 has been. Later... Kevin In a message dated 11/17/2003 2:01:13 AM Central Standard Time, [EMAIL PROTECTED] writes: * [EMAIL PROTECTED] wrote: > -- > FACT?: Apache 2.0 pre-fork ( which is the only thing still available on > some of the best platforms ) is SLOWER than Apache 1.3 pre-fork. > -- Do you have a supporting benchmark available? Benchmarking a PHP script as Rasmus did does not express anything about the httpd. Please don't continue to distribute misleading information again and again you know nothing about. nd
Re: consider reopening 1.3
On Mon, Nov 17, 2003 at 02:05:33AM -0500, [EMAIL PROTECTED] wrote: > FACT?: Apache 2.0 pre-fork ( which is the only thing still available on > some of the best platforms ) is SLOWER than Apache 1.3 pre-fork. Not for me it's not. Especially with sendfile. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: consider reopening 1.3
* [EMAIL PROTECTED] wrote: > -- > FACT?: Apache 2.0 pre-fork ( which is the only thing still available on > some of the best platforms ) is SLOWER than Apache 1.3 pre-fork. > -- Do you have a supporting benchmark available? Benchmarking a PHP script as Rasmus did does not express anything about the httpd. Please don't continue to distribute misleading information again and again you know nothing about. nd
Re: consider reopening 1.3
bravo! - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Sunday, November 16, 2003 11:05 PM Subject: Re: consider reopening 1.3 > > Geez... it's nice to discover everybody hasn't just dropped dead! > > I see a lot of healthy 'things to do' coming out of this > thread that could inject a lot of life back into the > development... which is what the various threads the past > few days have all been about. > > Action items?... > > Facts to face?... > > -- > FACT?: Apache 2.0 pre-fork ( which is the only thing still available on > some of the best platforms ) is SLOWER than Apache 1.3 pre-fork. > -- > > This gives someone who might be stuck with one of those pre-fork > only platforms, or anyone who just WANTS to stick with pre-fork, > absolutely NO INCENTIVE to upgrade at all ( ever! ). > > The whole module-rewrite thing is another issue but as long as > the same process model is SLOWER in the 'new' version than the > 'old' version you have a serious migration roadblock that > isn't going to go away. > > Okay... problem identified... what to do? > > - Verify that's it's true. ( seems to be ). You have to > KNOW, yourselves, where you are on the stopwatch and not > wait for usrs to tell you. > - If it's not (true)... do some marketing and make sure people KNOW IT. > - If it is... fix it. Make it NOT TRUE. > > I popped off and looked at 2.0 code again just now and I can tell > you right now it's (still) the filtering that's killing it. > > The core filters are going to need to be totally optimized > and kick-ass if there's any chance of 2.0 matching 1.3 speed... > and that's before anybody loads any 'extra' (optional) > filters ( other than core ). > > I don't think this is something any one person can do considering > no one seems to really have the 'whole picture' of the filtering > at this point and the orignal (primary) author is gone. > > I have a few suggestions but I'm not even sure I have > the 'whole picture' on how to improve things. > > One idea, of course, is to code in some BYPASSES ( on a config > switch? Dunno ) that would allow 2.0 pre-fork core filters to not > actually use the filtering (scheme) at all and put it right back > into 1.3 performance range. > > I am by no means suggesting you bring back BUFF for the core > filters... but I AM suggesting there might be ways to > BYPASS all the BUCKET_BRIGADE stuff at the core level, if > that's the way someone wants to run it. > > The moment someone starts loading a lot of 'optional' modules > you'd probably have to re-engage the filtering but I'll bet > you a dollar to a donut there are a LOT of people running Apache > with nothing but out-of-the-box options and CORE filters only. > > You might even be suprised how MANY people just run it that way. > > I think you would see a MAJOR bump in 2.0 usage numbers > if there was any way 2.0 pre-fork could be FASTER than 1.3 > in a same-box same-environment scenario. > > You can't really fix the module-migration roadblock nearly > as easily as you could FIX THIS. > > - > FACT?: There are still some non-maintenance mode things that > people have already expressed they would like to see added > to 1.3.x and probably more 'ideas' lurking nearby. > - > > I say... let it happen. > > Whether it was 'officially' closed or not... when someone > can't get a 2 line logging patch added to 1.3 after 6 > months of trying then that is CLOSURE no matter how you > look at it. Make it not so. > > Just let it be known that 'worthy' additions to 1.3 > are still WELCOME and maybe some fresh air will blow > in the window. > > - > FACT?: One of the biggest roadblocks to 2.0 migration is > ( and will remain ) module migration. > - > > No one even knows how many freakin' 'in-house' modules there > are out there ( security, auditing, billing, etc. ) that people > depend on for their 'business' needs but you can be sure those > 'in-house' modules are what bring home their bacon and are > MORE important to them than Apache itself. > > In a lot of cases these people are using (private) modules > written FOR them by someone who is long... long gone and > they really don't have the faintest idea how to get it > 'migrated' to some 'new version'. > > It's too late to talk about total forward-backward compatibility > for 1.3 and 2.0 modules
Re: consider reopening 1.3
Geez... it's nice to discover everybody hasn't just dropped dead! I see a lot of healthy 'things to do' coming out of this thread that could inject a lot of life back into the development... which is what the various threads the past few days have all been about. Action items?... Facts to face?... -- FACT?: Apache 2.0 pre-fork ( which is the only thing still available on some of the best platforms ) is SLOWER than Apache 1.3 pre-fork. -- This gives someone who might be stuck with one of those pre-fork only platforms, or anyone who just WANTS to stick with pre-fork, absolutely NO INCENTIVE to upgrade at all ( ever! ). The whole module-rewrite thing is another issue but as long as the same process model is SLOWER in the 'new' version than the 'old' version you have a serious migration roadblock that isn't going to go away. Okay... problem identified... what to do? - Verify that's it's true. ( seems to be ). You have to KNOW, yourselves, where you are on the stopwatch and not wait for usrs to tell you. - If it's not (true)... do some marketing and make sure people KNOW IT. - If it is... fix it. Make it NOT TRUE. I popped off and looked at 2.0 code again just now and I can tell you right now it's (still) the filtering that's killing it. The core filters are going to need to be totally optimized and kick-ass if there's any chance of 2.0 matching 1.3 speed... and that's before anybody loads any 'extra' (optional) filters ( other than core ). I don't think this is something any one person can do considering no one seems to really have the 'whole picture' of the filtering at this point and the orignal (primary) author is gone. I have a few suggestions but I'm not even sure I have the 'whole picture' on how to improve things. One idea, of course, is to code in some BYPASSES ( on a config switch? Dunno ) that would allow 2.0 pre-fork core filters to not actually use the filtering (scheme) at all and put it right back into 1.3 performance range. I am by no means suggesting you bring back BUFF for the core filters... but I AM suggesting there might be ways to BYPASS all the BUCKET_BRIGADE stuff at the core level, if that's the way someone wants to run it. The moment someone starts loading a lot of 'optional' modules you'd probably have to re-engage the filtering but I'll bet you a dollar to a donut there are a LOT of people running Apache with nothing but out-of-the-box options and CORE filters only. You might even be suprised how MANY people just run it that way. I think you would see a MAJOR bump in 2.0 usage numbers if there was any way 2.0 pre-fork could be FASTER than 1.3 in a same-box same-environment scenario. You can't really fix the module-migration roadblock nearly as easily as you could FIX THIS. - FACT?: There are still some non-maintenance mode things that people have already expressed they would like to see added to 1.3.x and probably more 'ideas' lurking nearby. - I say... let it happen. Whether it was 'officially' closed or not... when someone can't get a 2 line logging patch added to 1.3 after 6 months of trying then that is CLOSURE no matter how you look at it. Make it not so. Just let it be known that 'worthy' additions to 1.3 are still WELCOME and maybe some fresh air will blow in the window. - FACT?: One of the biggest roadblocks to 2.0 migration is ( and will remain ) module migration. - No one even knows how many freakin' 'in-house' modules there are out there ( security, auditing, billing, etc. ) that people depend on for their 'business' needs but you can be sure those 'in-house' modules are what bring home their bacon and are MORE important to them than Apache itself. In a lot of cases these people are using (private) modules written FOR them by someone who is long... long gone and they really don't have the faintest idea how to get it 'migrated' to some 'new version'. It's too late to talk about total forward-backward compatibility for 1.3 and 2.0 modules ( that opportunity was already blown at the design stage ) but it IS POSSIBLE to start a discussion about providing better 'compatibility' between modules. Example: If a simple Apache 1.3 module is already NOT using APR but simply relies on the old BUFF API wrappers... it's perfectly possible to just 'load' that module and run it under Apache 2.0. No kidding. All you have to do is have some way for 2.0 to 'fake' the old BUFF calls with a 'filter wrapper' around that (simple) module. You might even be able to do it by 'ifdef'ing the old BUFF calls with new MACRO calls but that would require a re-compile. This would require some ( a lot? ) of code in the core module loader/runner that isn't there right now but IT COULD BE DONE. If Microsoft can carry their DLLs forward through 3 major architecture changes... you can do the same. It just takes adding the right 'smarts' to the Server itself. FACT?: Whatever the target codebase... it's become nearly impossible to get patches revie
Re: FreeBSD threads was RE: consider reopening 1.3
On Sun, Nov 16, 2003 at 09:43:03PM -0400, Marc G. Fournier wrote: > > Yup, this is what I tend to see ... > > One question, what does 'ps auxwl' show, primarily the WCHAN column? I don't have access to the machine right now, but I can check later. -aaron
Re: FreeBSD threads was RE: consider reopening 1.3
Yup, this is what I tend to see ... One question, what does 'ps auxwl' show, primarily the WCHAN column? On Sun, 16 Nov 2003, Aaron Bannert wrote: > On Sun, Nov 16, 2003 at 02:34:47PM -0800, Justin Erenkrantz wrote: > > --On Sunday, November 16, 2003 5:20 PM -0400 "Marc G. Fournier" > > > > > >'k, maybe expand the comment in the INSTALL file to address this? > > > > Well, we've asked for confirmation of FreeBSD threading 'working' on the > > [EMAIL PROTECTED] - which as a platform-specific issue is the 'right' > > mailing list for this topic - not [EMAIL PROTECTED] > > > > FWIW, the FreeBSD port maintainer has asked us to enable threads on all > > versions, but we've (so far) yet to receive a reply that indicates that the > > FreeBSD's threading works properly. The only reply we received so far was > > that it isn't fixed with FreeBSD - even 5.1. So, if you have something to > > add, please contribute on the right list. > > I compiled it on a 4.9-CURRENT machine two days ago and it failed > (even after working around some problems with atomics) by deadlocking. > Connections were established but no responses ever returned. I wasn't > even able to knock a request out of the blocked state by hitting it > from another client. > > -aaron >
Re: consider reopening 1.3
Ian Holsman <[EMAIL PROTECTED]> wrote: >> >>Right now, most people do something like rpm -Uvh apache-1.3.29rpm >>and things work. If APR were distributed with apache-1.3.30, then I >>could say "requires apache-1.3.30" and it would not be much of a stretch >>to have them install it. >> >huh??? >you can get APR rpm's now. >and you can build the APR independant of httpd (and have it sit in >/usr/local ) >and thanks to apr-config/apr-util-config it's pretty dang easy to build >with them. ...only that tomorrow's apr might not be 100% compatible with today's. Think of mod_ssl's and mod_dav's problem (the apache_1.3 version). They must always add the apache_1.3 version number to their own version number to describe the API they require. I would not like a apache-1.3.30-mod_ssl-2.8-20-apr-1.0.14 kind of delivery scheme. Martin
Re: FreeBSD threads was RE: consider reopening 1.3
On Sun, Nov 16, 2003 at 02:34:47PM -0800, Justin Erenkrantz wrote: > --On Sunday, November 16, 2003 5:20 PM -0400 "Marc G. Fournier" > > > >'k, maybe expand the comment in the INSTALL file to address this? > > Well, we've asked for confirmation of FreeBSD threading 'working' on the > [EMAIL PROTECTED] - which as a platform-specific issue is the 'right' > mailing list for this topic - not [EMAIL PROTECTED] > > FWIW, the FreeBSD port maintainer has asked us to enable threads on all > versions, but we've (so far) yet to receive a reply that indicates that the > FreeBSD's threading works properly. The only reply we received so far was > that it isn't fixed with FreeBSD - even 5.1. So, if you have something to > add, please contribute on the right list. I compiled it on a 4.9-CURRENT machine two days ago and it failed (even after working around some problems with atomics) by deadlocking. Connections were established but no responses ever returned. I wasn't even able to knock a request out of the blocked state by hitting it from another client. -aaron
Re: consider reopening 1.3
Marc Slemko <[EMAIL PROTECTED]> wrote: > >3. Threading issues. This is a red herring; threading issues can be a >reason why moving to 2.0 wouldn't give someone enough of a reason to make >it worthwhile, but they do not block anyone moving to 2.0. if they >don't want to use threads, they don't have to use threads. There are platforms (still) which don't offer you threads, at least I am building for such a system. Without Thread support, some of the Apache2 features are simply unavailable (e.g., some caching stuff). What remains of the new Apache features is often not interesting enough for users to make the transition, given the fact that still too few 2.x modules exist. Which in turn is caused by the unstable API (API of the week) which was a major drawback for 3rd party module developers until 2.0.42 IIRC. Martin
Re: consider reopening 1.3
Peter J. Cranstone wrote: In today's environment it's all about 2 words - price/performance. Show me that Apache 2.x can outperform 1.x by a factor 10 on the same box. Dig around... I posted a benchmark to this list early in 2.0 development showing a 10x improvement of threaded 2.0 over 1.3 on AIX. The test was rather unfair to 1.3 as I had the machine swapping like crazy. So my question to you is price/performance doing what? It would not be too difficult to show a large performance improvement with 2.0 configured as a DMZ tier caching load balancing server frontending a farm of backend application servers. 'Smart' load balancing (pick your algorithm) and active fail-over support is not built in but would not be too difficult to add (I even posted a proof of concept to the proxy dev list a couple of months back). Tux is about the ultimate solution for serving static pages, but I doubt it has much traction either. One other thing worth noting... most Apache installations run on Linux. One of the big features of Apache 2, the threaded MPM, is completely worthless on Linux. The threaded MPM runs pretty well on the new thread library but the new thread library will not become mainstream until the 2.6 kernel (yea. I know some distros have it in 2.4, but that is somewhat controversial). Once the thread library on Linux is stable, we may begin to see more thread safe packages available for things like mod_php. Bill
Re: consider reopening 1.3
On Mon, 17 Nov 2003, Ian Holsman wrote: > I belive 2.0 beats 1.3 on these metrics, but like everyone here, Ihave > no more energy proving/disproving which is faster.. 2.0 works for me, > and thats all I really care about, not who else is using it. Do you really believe this to be true for Apache2-prefork as well? It may be, I just have never seen any evidence of that in my own tests. Obviously both servers can easily fill a 100M connection when just serving up static files at which point it comes down to what sort of cpu load doing so puts on the server. I really don't see any compelling advantage of Apache2-prefork over Apache1 to justify the development costs involved in porting hundreds of modules. And I am not speaking with my PHP hat on here, by the way. And a threaded mpm is just not an option. Most humans are simply not smart enough to write threadsafe code. -Rasmus
Re: consider reopening 1.3
hehe postal fees why dont we do something like what openoffice does and have people registar there copys just so we can figure out demographics and such kind of like what netcraft does -Kyle - Original Message - From: "Jim Jagielski" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, November 16, 2003 4:15 PM Subject: Re: consider reopening 1.3 > Peter J. Cranstone wrote: > > > > >> What would 1.4 have or be for that to happen? > > > > You have 12 million users - shouldn't be hard to simply ask them what they > > would like to see. > > > > Postal fees will be hell... > -- > === >Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ > "A society that will trade a little liberty for a little order > will lose both and deserve neither" - T.Jefferson
Re: consider reopening 1.3
Peter J. Cranstone wrote: > > >> What would 1.4 have or be for that to happen? > > You have 12 million users - shouldn't be hard to simply ask them what they > would like to see. > Postal fees will be hell... -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
RE: consider reopening 1.3
>> What would 1.4 have or be for that to happen? You have 12 million users - shouldn't be hard to simply ask them what they would like to see. Give the customer what he wants and he will be back for more. HTTP ain't finished yet, plenty of room for some serious improvement. And I'd also be seriously thinking about 64-bit and getting Apache around the 4GB memory limitation. Regards, Peter -Original Message- From: Jim Jagielski [mailto:[EMAIL PROTECTED] Sent: Sunday, November 16, 2003 1:37 PM To: [EMAIL PROTECTED] Subject: Re: consider reopening 1.3 On Nov 16, 2003, at 4:12 AM, Glenn wrote: > > - lack of clear leadership and even basic direction > scratch-an-itch development is fine and good, but not in total chaos Umm... this *is* the ASF. It's *developer* driven. The direction is defined by the developers. > - cathedral development > it appears that more than a few serious discussions have not happened > on-list and instead happen on IRC or elsewhere (board rooms?) without > apprising the list of what transpired. (Or have there been > absolutely > no recent design discussions?) I agree that in some cases, irc is "replacing" dev@, which is Not Good. Thank God we haven't started using stupid wikis. > - patch management > many patches posted to this list or the bug db languish in limbo. > Very little happens until a core contributor decides to take over a > patch > (more often than not it is more than simply shepherding it) > Little feedback; it often feels like nobody's home to answer the > phone... > - insufficient (developer) documentation > sure, there's the source, but it takes a lot longer to wrap ones head > around the Apache2 paradigms than it did for Apache 1.3 BUFFs and > such. > The barrier to entry is much higher; solid design documents would be > infinitely helpful > - many new contributors are frustrated and discouraged > see all of the above > The voluble Kevin Kiley said it well: > "Make it EASY to contribute... not a nightmare." The above are *not* 1.3 issues, per se, but httpd ones. > *** We need to get back many of the disenfranchised Apache 1.3 > developers > > Killing Apache 1.3 is not a good option. There is a strong "business" > need in many places to stay with Apache 1.3. > > The better option is reopening the 1.3 tree. > Release 1.4 and open a 1.5 dev tree, with the specific intent on > having the 1.4 release eventually map _directly_ into a _seamless_ > upgrade to Apache 2.x, with very easy and clear directions for using > a reverse proxy for those legacy 1.3 third-pary modules.) While > upgrading is not hard for developers, Apache is not a simple product. > We need an even-better (tm) way to get users from There (Apache 1.3) > to Here (Apache 2.x). Yes, more trees are extra work, but this > community is rapidly deteriorating without them. > > As noted many times, 1.3 is actively maintained but not actively developed. To be honest, I've not seen that many people saying "I *really* want to add this to 1.3!". If they had, chances are good that I'd +1 (not that what goes into 1.3 is my decision...). I'm curious how a 1.4 or whatever would make it "easier" for people to make that transition. What would 1.4 have or be for that to happen?
Re: consider reopening 1.3
Rasmus Lerdorf wrote: I have always had the feeling that Apache2+prefork was a bit of a second-class citizen. I have tested it periodically over the past 2 years and it has never gotten anywhere close to Apache1 in performance. I ran another test of 1.3.29 vs 2.0.48-prefork just now just to make sure I wasn't blowing pure smoke here and here is what I got: Apache-1.3.29 Document Path: /bench_main.php The benchmark itself is a standard little PHP thing I use to test stuff, so it may be that our Apache2Handler for PHP is crap and we aren't smart enough to write a decent Apache2 module. I don't think it is due to you guys not having smart people rasmus, more a question of priorities, your focused on 5.0 right now, and most people are doing that. as the general impression I've seen on the php lists is that no one is using 2, no one is interested in spending the time in getting it to run faster. maybe a better test would be to re-write your benchmark program in 'c' and to the 1.3/2.0 module interface directly so you can then do remove factors like this out of the equation. I've never seen what use req/sec is on benchmarks. most people have thier testing machine sitting on the other end of a switched 100mbs/1G network and just bang away. what I see more interesting is: - #reqs/sec @ 30% cpu utilization, where the testing machines are on medium-low bandwidth rate limiting - possibly where the meltdown point is. ie.. how many concurrent requests can this server takes before it gets unusable (say >1sec response time) - cost of a server farm using server X to serve my business. I belive 2.0 beats 1.3 on these metrics, but like everyone here, Ihave no more energy proving/disproving which is faster.. 2.0 works for me, and thats all I really care about, not who else is using it. -Rasmus
Re: consider reopening 1.3
Glenn wrote: On Mon, Nov 17, 2003 at 09:35:20AM +1100, Ian Holsman wrote: Glenn wrote: I have some different ideas. One is to distribute APR with 1.3 so that modules developers could incrementally move their modules to APR. why can't you just link APR into your 1.3 module? I don't think there would be any technical reason not to. Because then I would have to require that APR be installed, which is a lot harder than just requiring say apache-1.3.30. Right now, most people do something like rpm -Uvh apache-1.3.29rpm and things work. If APR were distributed with apache-1.3.30, then I could say "requires apache-1.3.30" and it would not be much of a stretch to have them install it. huh??? you can get APR rpm's now. and you can build the APR independant of httpd (and have it sit in /usr/local ) and thanks to apr-config/apr-util-config it's pretty dang easy to build with them. It should be possible for many modules to keep a single codebase for both Apache 1.3 and Apache 2.x, with minimal #defines around areas that manipulate BUFF vs filters and brigades. Right now, it is not. these minimal changes is where the bugs come in. if people aren't willing to move from their apache 1.3.26, they aren't doing to upgrade to this. FWIW.. I'm -0.5 in opening up the 1.3 tree, as I see it as dead, the same as I see redhat 7.x is. I'm not saying that people don't run production systems on it, or don't rely on it, but that they are in *maintenance mode*. I don't think anyone proposes to run new sites with redhat 7.x now do they? having 2 seperate active code bases is just going to mean that 2.x is going to have less people working on it, as they are going to have to spend time fixing/maintaining all the new stuff being added/breaking in 1.3 does anyone have any stats on how long it took to migrate from 1.2.x to 1.3.x? from what I can see three reasons why people don't move * things are running fine * too hard to migrate the modules * Freebsd threading as for migrating the modules, you'll just have to bite the bullet one day, as you will when you migrate off platform X when it is EOL'd. Cheers, Glenn
RE: consider reopening 1.3
On Sun, 16 Nov 2003, Marc Slemko wrote: > 3. Threading issues. This is a red herring; threading issues can be a > reason why moving to 2.0 wouldn't give someone enough of a reason to make > it worthwhile, but they do not block anyone moving to 2.0. if they > don't want to use threads, they don't have to use threads. I have always had the feeling that Apache2+prefork was a bit of a second-class citizen. I have tested it periodically over the past 2 years and it has never gotten anywhere close to Apache1 in performance. I ran another test of 1.3.29 vs 2.0.48-prefork just now just to make sure I wasn't blowing pure smoke here and here is what I got: Apache-1.3.29 Document Path: /bench_main.php Document Length:7832 bytes Concurrency Level: 5 Time taken for tests: 2.038 seconds Complete requests: 500 Failed requests:0 Broken pipe errors: 0 Total transferred: 4071500 bytes HTML transferred: 3916000 bytes Requests per second:245.34 [#/sec] (mean) Time per request: 20.38 [ms] (mean) Time per request: 4.08 [ms] (mean, across all concurrent requests) Transfer rate: 1997.79 [Kbytes/sec] received Apache-2.0.48 Concurrency Level: 5 Time taken for tests: 3.367 seconds Complete requests: 500 Failed requests:0 Broken pipe errors: 0 Total transferred: 4028508 bytes HTML transferred: 3931622 bytes Requests per second:148.50 [#/sec] (mean) Time per request: 33.67 [ms] (mean) Time per request: 6.73 [ms] (mean, across all concurrent requests) Transfer rate: 1196.47 [Kbytes/sec] received I did try more requests, different concurrency levels and I tweaked the config of both to be as close as I could make them. Looking at the total bytes tranferred, Apache2 is sending less mostly because I forgot to remove the p3p module from my Apache1 setup which adds a big long nasty p3p header to every response, but even with that Apache1 was way faster. The benchmark itself is a standard little PHP thing I use to test stuff, so it may be that our Apache2Handler for PHP is crap and we aren't smart enough to write a decent Apache2 module. -Rasmus
Re: consider reopening 1.3
On Mon, Nov 17, 2003 at 09:35:20AM +1100, Ian Holsman wrote: > Glenn wrote: > >I have some different ideas. One is to distribute APR with 1.3 so > >that modules developers could incrementally move their modules to APR. > > why can't you just link APR into your 1.3 module? I don't think there > would be any technical reason not to. Because then I would have to require that APR be installed, which is a lot harder than just requiring say apache-1.3.30. Right now, most people do something like rpm -Uvh apache-1.3.29rpm and things work. If APR were distributed with apache-1.3.30, then I could say "requires apache-1.3.30" and it would not be much of a stretch to have them install it. It should be possible for many modules to keep a single codebase for both Apache 1.3 and Apache 2.x, with minimal #defines around areas that manipulate BUFF vs filters and brigades. Right now, it is not. Cheers, Glenn
Re: 1.3 Wishlist: (Was: Re: consider reopening 1.3)
On Sun, Nov 16, 2003 at 03:54:59PM -0500, Jim Jagielski wrote: > I'm also curious about what a 1.4/1.5 would do that the current 1.3 > does not which would provide a "seamless" upgrade. Are you talking > API or what? As someone who's preformed numerous such migrations, > the actual mechanics of doing so are meager, especially if > you stay prefork. sendfile? -aaron
Re: consider reopening 1.3
Glenn wrote: On Sun, Nov 16, 2003 at 03:37:19PM -0500, Jim Jagielski wrote: Oh, how about my (effectively) 2-line patch which adds vhost to the error log, which I have posted to this list NO LESS THAN 6 TIMES and spaced out over the past 6 MONTHS in three different formats, using a global, expanding server_rec, and with #defines. this is not a 1.3 thing, this is a dev@ thing. your patch could have been posted for 2.0 and got the same response. (and I'm not saying you should not be pissed off, just that this is not a 1.3 thing) I have some different ideas. One is to distribute APR with 1.3 so that modules developers could incrementally move their modules to APR. why can't you just link APR into your 1.3 module? I don't think there would be any technical reason not to. Please note: I'm not in favor of implementing major changes to 1.3 that are not in-line with Apache 2.x, but am in favor of continuing bug fixes and making the eventual transition to 2.x easier. Cheers, Glenn
FreeBSD threads was RE: consider reopening 1.3
--On Sunday, November 16, 2003 5:20 PM -0400 "Marc G. Fournier" <[EMAIL PROTECTED]> wrote: On FreeBSD 4.X it is broken(and will be forever?). On FreeBSD 5.X, use KSE threading (which may become the default in the future 5.2 release anyways?) and it works great. man libmap.conf on a FreeBSD box for information on todo this.(see also: freebsd-threads mailing list) 'k, maybe expand the comment in the INSTALL file to address this? Well, we've asked for confirmation of FreeBSD threading 'working' on the [EMAIL PROTECTED] - which as a platform-specific issue is the 'right' mailing list for this topic - not [EMAIL PROTECTED] FWIW, the FreeBSD port maintainer has asked us to enable threads on all versions, but we've (so far) yet to receive a reply that indicates that the FreeBSD's threading works properly. The only reply we received so far was that it isn't fixed with FreeBSD - even 5.1. So, if you have something to add, please contribute on the right list. Thanks! -- justin
Re: consider reopening 1.3
--On Sunday, November 16, 2003 4:04 PM -0500 Glenn <[EMAIL PROTECTED]> wrote: On Sun, Nov 16, 2003 at 03:46:26PM -0500, Jim Jagielski wrote: Why 1.4? What will 1.4 have that 1.3 does not? Or do you mean reopening 1.3 implies that it becomes 1.4? Only semantics. .4 is even, so stable; .5 is development and less stable Our versioning policy only applies to 2.x series, not 1.x. -- justin
Re: consider reopening 1.3
> Ok, so Apache2 uptake is slower than desired for some (not all) on this > list. That's only logical given the success and therefore inertia to stay > with Apache 1.3. But there are more than a few other factors mentioned in > recent threads that are contributing to Apache2 development stagnation. > Ignore for a moment that vendors have only recently begun shipping Apache2 > as the default web server instead of Apache 1.3. Stas pointed out some > serious problems. I reformulate them slightly differently here. Forgive my lack of english, but how can we reopen something that has never been closed? david
Re: consider reopening 1.3
I agree with Matt that Apache2 needs to be rdy for IIS but we need to make a choice here between 1.3-1.4 and 2 -Kyle Hamilton www.kylehamilton.net www.kylehamilton.com 559-593-1210 - Original Message - From: "Matthieu Estrade" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, November 16, 2003 12:02 PM Subject: Re: consider reopening 1.3 > Hi, > > I understand many people still are with 1.3 and don't want to change because > it's stable. > But Coding modules with 1.3 is definitively not easy and require many time > core patch. > > Apache 2.0 was design to give many really good features like threaded mpm, > filters etc... > When you look others web server, you can see Apache 2.0 is a good response > to IIS 6, but is still unstable. > Did you see all performances the others web server give ? did you see all > new features provided by all new web server ? > Only Apache 2.0 is able to offer the same services. No mem_cache in apache > 1.3, No filters, noway to change output data without patching the core. > When you compare actual fashion which is to offer webserver with a coding > api to make dynamic website etc, i think Apache 2.0 is the solution, and > more, maybe include directly into it mod_php and mod_perl. > > Apache 1.3 is still used and really stable, yes, but needs are changing more > and more and i think it's time to do more and more effort on Apache 2.0 to > make it stable, powerfull, and easy to use. It's my humble option :) > > Regards, > Matthieu > > > - Original Message - > From: "Graham Leggett" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Sunday, November 16, 2003 8:39 PM > Subject: Re: consider reopening 1.3 > > > > Rasmus Lerdorf wrote: > > > > > I also work for a large company with plenty of talented developers and > > > thousands of production Apache-1.3 servers along with hundreds of custom > > > Apache-1.3 modules. It will be years before I can even consider > Apache2, > > > given the architecture and API differences between the two. If > something > > > could be done in an Apache-1.4 and 2.1/2.2 to help bridge the gap > perhaps > > > one day Apache2 will be an option, but today it is simply too big a gap > to > > > jump and I am pretty sure the bulk of the Apache community is in the > same > > > boat. > > > > I think the key thing is "bugfixes" compared to "features" and > > "architecture changes". > > > > I am +1 on seeing bugfixes go into v1.3 - people are using it, and if it > > can work better, so be it. But to actively encourage people to add > > features or architecture changes to v1.3, that simply turns v1.3 into > > "something else no longer compatible with v1.3", which we already have: > > v2.0. > > > > Regards, > > Graham > > -- > >
Re: consider reopening 1.3
On Sun, 2003-11-16 at 11:11, Jeff Trawick wrote: > > - patch management > > many patches posted to this list or the bug db languish in limbo. > > Very little happens until a core contributor decides to take over a patch > > (more often than not it is more than simply shepherding it) > > Little feedback; it often feels like nobody's home to answer the phone... > > This is a big hole which will be addressed, even if I have to quit my job, > abandon my family, find shelter from the wind and rain somewhere that has WiFi > access, etc. (No, not really. But this isn't a simple situation that can be > solved by proclamation. We already have the will, we just need to have some > procedures to help us focus that will.) FWIW: in the Subversion project, we've assigned the hat of "patch manager" to a volunteer in the community. He watches patches come in. If any patch goes unanswered for a week or more, the patch manager files it in the issuetracker. No more lost patches. If anything, it makes the patches even more prominent -- when developers are scanning the bug database for a "quickie" to fix, the small patches stand out.
RE: consider reopening 1.3
What exactly do people want in a 1.4 and why is making that fit into 2.0 not an option? So far I can recall seeing a few reasons why people aren't moving to 2.0. 1. they have no need to change, so they don't. Why would having a 1.4 then 2.0 will make them have a need to make two changes? If people don't need to change, then thats great. Most Apache installations are more or less install and forget. I'm not worried about these people, they are happily using Apache, if they don't want to upgrade that is just fine. 2. New module API making it hard to migrate. This is certainly a problem for a certain set of users. I'm not sure how typical that set is. Rasmus is not a typical user of Apache. Since this set of users tends to be more technically adept than others, however, it certainly may be a big enough set that there is enough support from them to put in the hours on a more evolutionary successor to 1.3. However, I don't see how a 1.4 would be a migration path to 2.0. It would be a completely separate path that would just be an approach to delay, possibly indefinitely, migration to 2.0. That isn't necessarily a bad thing in and of itself, but it is different from having a 1.4 be some sort of migration path to 2.0. 3. Threading issues. This is a red herring; threading issues can be a reason why moving to 2.0 wouldn't give someone enough of a reason to make it worthwhile, but they do not block anyone moving to 2.0. if they don't want to use threads, they don't have to use threads. 4. they wouldn't mind changing, but the upgrade hassles are too great. 5. stability, or perceived stability. Apache is developer driven. That results in it going where the more technically capable user wants it to go, which includes companies funding Apache development for their own reasons. I'd like to encourage those people who are interested in contributing to some version of Apache to consider if there is any way that instead of starting with 1.3 and modifying it to have more features and more bugfixes, some of which are already in 2.0 or are being worked on in 2.0 or people want for 2.0, they could work on making it easier to migrate from 1.3 to 2.0. I am not concerned that people are not upgrading to 2.0 unless they want to upgrade to something but 2.0 will not work for them.
Re: 1.3 Wishlist: (Was: Re: consider reopening 1.3)
On Sun, 16 Nov 2003, Jim Jagielski wrote: > So a useful topic is: What is *missing* in 1.3 that needs to be > addressed. > What are the features/additions that the disenfranchised 1.3 developers > want to add to 1.3... How about support for chunked compressed responses right in src/main/buff.c where it belongs (given we don't have filters in Apache1) That alone would probably warrant a bump to 1.4. I think people are thinking 1.4 because adding any significant features between 1.3.29 and 1.3.30 would seem pretty odd. -Rasmus
Re: consider reopening 1.3
On Sun, 16 Nov 2003 16:21:04 -0500 Glenn <[EMAIL PROTECTED]> wrote: On Sun, Nov 16, 2003 at 04:12:20PM -0500, Jim Jagielski wrote: I may be misunderstanding you... or do you mean just have Apache 1.3 "APR aware" and not for 1.3 to *use* it per se, but allow for modules to call APR... That would be useful, but anything deeper than that would scare people I think... APR is just as "new" as Apache 2.0. The latter. Only that it be available so that I can spend my time developing with Apache2 paradigms and have most of them translate to usefullness on Apache 1.3. Sort of a like a forward-compatibility to 2.0 in the same way that ap_compat.h is a backward-compatibility from 2.0 to 1.3. I believe that there has been some discussion on this list in the past about people using APR with 1.3 modules. There should be no requirement that httpd use APR for a module to use it.
RE: consider reopening 1.3
On Sun, 16 Nov 2003, Paul Querna wrote: > > just to pop my 2 cents worth in here ... I have some clients that > > have deployed under Apache2 ... the major headache(s) that I've had > > to date is that the FreeBSD thread support is still listed as unusable: > > > > * If you are building on FreeBSD, be aware that threads will > > be disabled and the prefork MPM will be used by > > default, as threads do not work well with Apache on > > FreeBSD. If you wish to try a threaded Apache on > > FreeBSD anyway, use "./configure --enable-threads". > > On FreeBSD 4.X it is broken(and will be forever?). On FreeBSD 5.X, use KSE > threading (which may become the default in the future 5.2 release anyways?) > and it works great. man libmap.conf on a FreeBSD box for information on todo > this.(see also: freebsd-threads mailing list) 'k, maybe expand the comment in the INSTALL file to address this? > > and mod_* support ... last I checked, mod_gzip is still Apache1-only, > > mod_gzip? Try mod_deflate, it is included with apache 2: > http://httpd.apache.org/docs-2.0/mod/mod_deflate.html Didn't know about this ... will look at it, thanks ...
Re: consider reopening 1.3
On Sun, Nov 16, 2003 at 04:12:20PM -0500, Jim Jagielski wrote: > On Nov 16, 2003, at 3:57 PM, Glenn wrote: > > > >Oh, how about my (effectively) 2-line patch which adds vhost > >to the error log, which I have posted to this list NO LESS THAN 6 TIMES > >and spaced out over the past 6 MONTHS in three different formats, using > >a global, expanding server_rec, and with #defines. > > > > Ok, that's true, but that *really* does not translate to > a downpour of disenfranchised 1.3 developers begging for 1.3 > to be re-opened :) Well, you asked for an example. :) The patch is required in my environment. [snip] > Interesting, but if the usage of APR was that deep within 1.3, then > wouldn't backwards compatibility with 1.3 go out the window. > I'm guessing this is your 1.4/1.5 branch. But that doesn't help > the 1.3 people at all, since (if I'm understanding you correctly) > all this does is create another Apache version... > > I may be misunderstanding you... or do you mean just have > Apache 1.3 "APR aware" and not for 1.3 to *use* it per se, > but allow for modules to call APR... That would be useful, > but anything deeper than that would scare people I think... > APR is just as "new" as Apache 2.0. The latter. Only that it be available so that I can spend my time developing with Apache2 paradigms and have most of them translate to usefullness on Apache 1.3. Sort of a like a forward-compatibility to 2.0 in the same way that ap_compat.h is a backward-compatibility from 2.0 to 1.3. I think both Rasmus and I have voiced that there needs to be a better migration path for third-party developers to port modules to 2.x. Migrating a stock Apache 1.3 to Apache 2.0 is trivial, but this is not the case when legacy third-party modules are involved. Cheers, Glenn
Re: consider reopening 1.3
Glenn wrote: > > On Sun, Nov 16, 2003 at 03:46:26PM -0500, Jim Jagielski wrote: > > Why 1.4? What will 1.4 have that 1.3 does not? Or do you mean > > reopening 1.3 implies that it becomes 1.4? > > Only semantics. .4 is even, so stable; .5 is development and less stable > Personally, I've never liked that methodology Unless *really* controlled, I think it almost restricts development, since the 1.5 tree kind of gets "super developed" and only occasionally are "safe things" brought down to 1.4. Other development teams do this much better than we do, IMO. With our development scenario, and they way we are structured (no benevolent dictator), having one tree, which is developed and polished, seems almost healthier. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
RE: consider reopening 1.3
> just to pop my 2 cents worth in here ... I have some clients that > have deployed under Apache2 ... the major headache(s) that I've had > to date is that the FreeBSD thread support is still listed as unusable: > > * If you are building on FreeBSD, be aware that threads will > be disabled and the prefork MPM will be used by > default, as threads do not work well with Apache on > FreeBSD. If you wish to try a threaded Apache on > FreeBSD anyway, use "./configure --enable-threads". On FreeBSD 4.X it is broken(and will be forever?). On FreeBSD 5.X, use KSE threading (which may become the default in the future 5.2 release anyways?) and it works great. man libmap.conf on a FreeBSD box for information on todo this.(see also: freebsd-threads mailing list) > and mod_* support ... last I checked, mod_gzip is still Apache1-only, mod_gzip? Try mod_deflate, it is included with apache 2: http://httpd.apache.org/docs-2.0/mod/mod_deflate.html > everytime someone asks about Apache2 on the PHP mailing lists, the general > answer seems to be "we're waiting for the API to settle down" ... Well, I think that excuse is BS. Apache 2.0.X is keeping binary compatibility now. Not too many major API changes that I am aware of. > For me, the big benefit to Apache2 is/will be going to threaded, so until > either the FreeBSD/threaded issue is resolved, I'm "stuck" with > Apache1 :( I use FreeBSD 5.1/current with the worker MPM with libkse. 'works for me' -Paul Querna
Re: consider reopening 1.3
On Nov 16, 2003, at 3:57 PM, Glenn wrote: Oh, how about my (effectively) 2-line patch which adds vhost to the error log, which I have posted to this list NO LESS THAN 6 TIMES and spaced out over the past 6 MONTHS in three different formats, using a global, expanding server_rec, and with #defines. Ok, that's true, but that *really* does not translate to a downpour of disenfranchised 1.3 developers begging for 1.3 to be re-opened :) I'm curious how a 1.4 or whatever would make it "easier" for people to make that transition. What would 1.4 have or be for that to happen? I have some different ideas. One is to distribute APR with 1.3 so that modules developers could incrementally move their modules to APR. Personal experience: I am writing a module for 1.3 and 2.0 and the only code reuse I manage to achieve is where I said 'screw both the Apache 1.3 and Apache 2.0 models' and decided that my module would only work on POSIX compliant systems, and wrote my own POSIX compliant socket routines. If I had access to APR in 1.3, I could maintaining my module with 2.0 paradigms and would be able to keep my module working with 1.3 with much less additional effort. Please note: I'm not in favor of implementing major changes to 1.3 that are not in-line with Apache 2.x, but am in favor of continuing bug fixes and making the eventual transition to 2.x easier. Interesting, but if the usage of APR was that deep within 1.3, then wouldn't backwards compatibility with 1.3 go out the window. I'm guessing this is your 1.4/1.5 branch. But that doesn't help the 1.3 people at all, since (if I'm understanding you correctly) all this does is create another Apache version... I may be misunderstanding you... or do you mean just have Apache 1.3 "APR aware" and not for 1.3 to *use* it per se, but allow for modules to call APR... That would be useful, but anything deeper than that would scare people I think... APR is just as "new" as Apache 2.0.
Re: consider reopening 1.3
On Sun, Nov 16, 2003 at 03:46:26PM -0500, Jim Jagielski wrote: > Why 1.4? What will 1.4 have that 1.3 does not? Or do you mean > reopening 1.3 implies that it becomes 1.4? Only semantics. .4 is even, so stable; .5 is development and less stable >+1 for "officially" allowing active development on 1.3 >-1 for 1.4/1.5 "just because" +1 for more active development on 1.x no matter what it's called. We're on the same page. Cheers, Glenn
Re: consider reopening 1.3
On Sun, Nov 16, 2003 at 03:37:19PM -0500, Jim Jagielski wrote: > As noted many times, 1.3 is actively maintained but not > actively developed. To be honest, I've not seen that > many people saying "I *really* want to add this to 1.3!". > If they had, chances are good that I'd +1 (not that what > goes into 1.3 is my decision...). Oh, how about my (effectively) 2-line patch which adds vhost to the error log, which I have posted to this list NO LESS THAN 6 TIMES and spaced out over the past 6 MONTHS in three different formats, using a global, expanding server_rec, and with #defines. Pardon me for being PO'd and thinking that there is NO DEVELOPMENT (besides critical security fixes) happening on 1.3. > I'm curious how a 1.4 or whatever would make it "easier" for > people to make that transition. What would 1.4 have or be > for that to happen? I have some different ideas. One is to distribute APR with 1.3 so that modules developers could incrementally move their modules to APR. Personal experience: I am writing a module for 1.3 and 2.0 and the only code reuse I manage to achieve is where I said 'screw both the Apache 1.3 and Apache 2.0 models' and decided that my module would only work on POSIX compliant systems, and wrote my own POSIX compliant socket routines. If I had access to APR in 1.3, I could maintaining my module with 2.0 paradigms and would be able to keep my module working with 1.3 with much less additional effort. Please note: I'm not in favor of implementing major changes to 1.3 that are not in-line with Apache 2.x, but am in favor of continuing bug fixes and making the eventual transition to 2.x easier. Cheers, Glenn
1.3 Wishlist: (Was: Re: consider reopening 1.3)
On Nov 16, 2003, at 4:12 AM, Glenn wrote: *** We need to get back many of the disenfranchised Apache 1.3 developers Killing Apache 1.3 is not a good option. There is a strong "business" need in many places to stay with Apache 1.3. The better option is reopening the 1.3 tree. Release 1.4 and open a 1.5 dev tree, with the specific intent on having the 1.4 release eventually map _directly_ into a _seamless_ upgrade to Apache 2.x, with very easy and clear directions for using a reverse proxy for those legacy 1.3 third-pary modules.) While upgrading is not hard for developers, Apache is not a simple product. We need an even-better (tm) way to get users from There (Apache 1.3) to Here (Apache 2.x). Yes, more trees are extra work, but this community is rapidly deteriorating without them. Again, "opening" 1.3 and then having 1.4/1.5 are 2 distinct issues and I think you make things harder by lumping them together. I'm also curious about what a 1.4/1.5 would do that the current 1.3 does not which would provide a "seamless" upgrade. Are you talking API or what? As someone who's preformed numerous such migrations, the actual mechanics of doing so are meager, especially if you stay prefork. This doesn't mean I'm not +1 for making 1.3 more actively developed (the reverse in fact), but if we're going to do it, having real concrete reasons why makes sense. So a useful topic is: What is *missing* in 1.3 that needs to be addressed. What are the features/additions that the disenfranchised 1.3 developers want to add to 1.3...
Re: consider reopening 1.3
On Sun, 16 Nov 2003, Jim Jagielski wrote: > I'm curious how a 1.4 or whatever would make it "easier" for people to > make that transition. What would 1.4 have or be for that to happen? I was kind of wondering this one too ... I thought the biggest headache of moving from 1 -> 2 was that the APIs had changed?
Re: consider reopening 1.3
On Nov 16, 2003, at 2:23 PM, Glenn wrote: I don't expect any of the current Apache developers would be interested in this. But plenty of people join the development community over time (see previous comments) and theoretically the opinions could change. Well, I am interested. And some others on this list are interested. What must we do to have the opportunity to scratch this itch? I suggested releasing 1.4 and opening 1.5 dev, along with better patch management, to which you also agree a better job need be done. I do not think that the _current_ Apache is and _will forever be_ the right tool for a web server. The size of the bug database and feature requests should be sufficient evidence to support this point. I also believe that there needs to be an even easier migration path from 1.3 to 2.x, despite how good it is already. So what will it take to convince the core developers to reopen 1.3? I'm less interested in opinions and more interested in getting something done. Why 1.4? What will 1.4 have that 1.3 does not? Or do you mean reopening 1.3 implies that it becomes 1.4? But as the RM for the last X 1.3 releases, I think (hope) that it's obvious that I think the 1.3 tree still has a lot of life and a lot of interest in it. The less-than-expected migration from 1.x to 2.x has not happened, and the reasons why are many and few. It's for that reason, and others, that I try to keep 1.3 going. I've never considered 1.3 "closed" so I see no need to "re-open" it. Maybe "open it up more", that is, by allowing new features to be added, etc... I'm certainly ++1 about that. But I think confusing things with a 1.4/1.5 branch doesn't make sense, unless people can *actually* specify what would require a bump like that... So: +1 for "officially" allowing active development on 1.3 -1 for 1.4/1.5 "just because"
RE: consider reopening 1.3
On Sun, 16 Nov 2003, Peter J. Cranstone wrote: > You know Rasmus you just hit the nail on the head... > > >> It will be years before I can even consider Apache2, > >> given the architecture and API differences between the two > > Everybody on this list should take a moment and re-read those two sentences. > It's why 2.x isn't moving. Not only is it complicated to move, the net > result is "not much different than they have now". just to pop my 2 cents worth in here ... I have some clients that have deployed under Apache2 ... the major headache(s) that I've had to date is that the FreeBSD thread support is still listed as unusable: * If you are building on FreeBSD, be aware that threads will be disabled and the prefork MPM will be used by default, as threads do not work well with Apache on FreeBSD. If you wish to try a threaded Apache on FreeBSD anyway, use "./configure --enable-threads". and mod_* support ... last I checked, mod_gzip is still Apache1-only, everytime someone asks about Apache2 on the PHP mailing lists, the general answer seems to be "we're waiting for the API to settle down" ... For me, the big benefit to Apache2 is/will be going to threaded, so until either the FreeBSD/threaded issue is resolved, I'm "stuck" with Apache1 :(
Re: consider reopening 1.3
On Nov 16, 2003, at 4:12 AM, Glenn wrote: - lack of clear leadership and even basic direction scratch-an-itch development is fine and good, but not in total chaos Umm... this *is* the ASF. It's *developer* driven. The direction is defined by the developers. - cathedral development it appears that more than a few serious discussions have not happened on-list and instead happen on IRC or elsewhere (board rooms?) without apprising the list of what transpired. (Or have there been absolutely no recent design discussions?) I agree that in some cases, irc is "replacing" dev@, which is Not Good. Thank God we haven't started using stupid wikis. - patch management many patches posted to this list or the bug db languish in limbo. Very little happens until a core contributor decides to take over a patch (more often than not it is more than simply shepherding it) Little feedback; it often feels like nobody's home to answer the phone... - insufficient (developer) documentation sure, there's the source, but it takes a lot longer to wrap ones head around the Apache2 paradigms than it did for Apache 1.3 BUFFs and such. The barrier to entry is much higher; solid design documents would be infinitely helpful - many new contributors are frustrated and discouraged see all of the above The voluble Kevin Kiley said it well: "Make it EASY to contribute... not a nightmare." The above are *not* 1.3 issues, per se, but httpd ones. *** We need to get back many of the disenfranchised Apache 1.3 developers Killing Apache 1.3 is not a good option. There is a strong "business" need in many places to stay with Apache 1.3. The better option is reopening the 1.3 tree. Release 1.4 and open a 1.5 dev tree, with the specific intent on having the 1.4 release eventually map _directly_ into a _seamless_ upgrade to Apache 2.x, with very easy and clear directions for using a reverse proxy for those legacy 1.3 third-pary modules.) While upgrading is not hard for developers, Apache is not a simple product. We need an even-better (tm) way to get users from There (Apache 1.3) to Here (Apache 2.x). Yes, more trees are extra work, but this community is rapidly deteriorating without them. As noted many times, 1.3 is actively maintained but not actively developed. To be honest, I've not seen that many people saying "I *really* want to add this to 1.3!". If they had, chances are good that I'd +1 (not that what goes into 1.3 is my decision...). I'm curious how a 1.4 or whatever would make it "easier" for people to make that transition. What would 1.4 have or be for that to happen?
Re: consider reopening 1.3
On Sun, Nov 16, 2003 at 12:04:28PM -0800, Rasmus Lerdorf wrote: > Basically I see us back in the NCSA days right now. The ASF has mostly > abandoned Apache1 and we are in that transition phase where people are > looking at each other waiting for someone to step up and continue > development on the code that everyone is using. That is how Apache was > born to begin with. +1 Telling point. Ignore history at your peril. -Glenn
RE: consider reopening 1.3
You know Rasmus you just hit the nail on the head... >> It will be years before I can even consider Apache2, >> given the architecture and API differences between the two Everybody on this list should take a moment and re-read those two sentences. It's why 2.x isn't moving. Not only is it complicated to move, the net result is "not much different than they have now". N tier architecture problems have been solved. Apache 1.x is "good enough" and managers don't have the budgets to move to an untested buggy version which still requires significant resources to make it work. Here's something else to consider... I went to the Covalent web site the other day for the first time in a year. You know what surprised me most? I don't think they are in the web server business any more. I think they are in the application management business with a focus on integration and security. You know what this means don't you. Covalent has had over $40 million dollars pumped into it by VC's and Apache 2.x the commercial version never did what Zeus managed to do, sell over 200,000 copies. I've talked to VC's and the general feeling is that the N tier architecture problems have been solved and there's no money to be made in a web server which is free, running on cheap PC's. I've spoken to people at Zeus and while they still sell a web server the move now is to load balancing running either on AMD64 or Itanium. It's cheaper than an F5 switch and the margins are better. The choice everyone on this lists faces becomes clearer everyday. If the premier Web server funded company in the US has shifted it's focus from Apache 2.x to application management then whose going to build a better web server that anyone cares to use. If you want some traction the smart step is re-open 1.3 get it to 1.4 and then provide migration steps and documentation to 2.x With 2.x you have to show a clear differentiator as to why people like Rasmus whose been there and written that should move thousands of 1.x boxes to 2.x In today's environment it's all about 2 words - price/performance. Show me that Apache 2.x can outperform 1.x by a factor 10 on the same box. If you can do that and the box is cheap then Rasmus has a reason to do some porting work - why? Because he can cut his equipment management costs by probably a factor 8 and that's something a manager will buy into. There's probably 12 million or so 1.x users - that's a big, big addressable market place. Give them something they want and make it easy. Regards, Peter Cranstone -Original Message- From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED] Sent: Sunday, November 16, 2003 12:24 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: consider reopening 1.3 On Sun, 16 Nov 2003, Jeff Trawick wrote: > > *** We need to get back many of the disenfranchised Apache 1.3 developers > > Who are these people? /me raises a hand People have suggested that we have fewer developers today because Apache 2 is too complex. That the crappy economy has reduced the time people have to work on it. Or that Apache-1.3 is simply good enough for most people. I don't think it is any of that. Hackers love to hack, but hackers are also practical creatures. They hack on things that they need and use. They need and use Apache1 but we have taken our ball away and gone off to play another game. Just compare the list of contributors today to 4 years ago if you want a list. > I don't expect any of the current Apache developers would be interested in > this. But plenty of people join the development community over time (see > previous comments) and theoretically the opinions could change. I think the key word there is "current" I also work for a large company with plenty of talented developers and thousands of production Apache-1.3 servers along with hundreds of custom Apache-1.3 modules. It will be years before I can even consider Apache2, given the architecture and API differences between the two. If something could be done in an Apache-1.4 and 2.1/2.2 to help bridge the gap perhaps one day Apache2 will be an option, but today it is simply too big a gap to jump and I am pretty sure the bulk of the Apache community is in the same boat. -Rasmus
Re: consider reopening 1.3
On Sun, 16 Nov 2003, Jeff Trawick wrote: > The point was not to blame anybody. Instead, I don't believe there are so many > people as you imply. Many of the people who are no longer developing have > moved on to other interests/work/etc. and have dropped out of httpd dev because > of that. > > If somebody is no longer working on [EMAIL PROTECTED] because they feel > disenfranchised, it is fair to point out that their skills are still very > useful even if they don't want to mess with 2.x. But the message they have gotten is that they are useful as bug fixers and documenters only. All the fun stuff is reserved for people working on Apache2. If that is an incorrect impression then we need to shout this from the rooftops and put up a big sign inviting people to submit any outstanding cool patches for 1.3 along with ideas for things they would like to see added. Basically I see us back in the NCSA days right now. The ASF has mostly abandoned Apache1 and we are in that transition phase where people are looking at each other waiting for someone to step up and continue development on the code that everyone is using. That is how Apache was born to begin with. -Rasmus
Re: consider reopening 1.3
Hi, I understand many people still are with 1.3 and don't want to change because it's stable. But Coding modules with 1.3 is definitively not easy and require many time core patch. Apache 2.0 was design to give many really good features like threaded mpm, filters etc... When you look others web server, you can see Apache 2.0 is a good response to IIS 6, but is still unstable. Did you see all performances the others web server give ? did you see all new features provided by all new web server ? Only Apache 2.0 is able to offer the same services. No mem_cache in apache 1.3, No filters, noway to change output data without patching the core. When you compare actual fashion which is to offer webserver with a coding api to make dynamic website etc, i think Apache 2.0 is the solution, and more, maybe include directly into it mod_php and mod_perl. Apache 1.3 is still used and really stable, yes, but needs are changing more and more and i think it's time to do more and more effort on Apache 2.0 to make it stable, powerfull, and easy to use. It's my humble option :) Regards, Matthieu - Original Message - From: "Graham Leggett" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Sunday, November 16, 2003 8:39 PM Subject: Re: consider reopening 1.3 > Rasmus Lerdorf wrote: > > > I also work for a large company with plenty of talented developers and > > thousands of production Apache-1.3 servers along with hundreds of custom > > Apache-1.3 modules. It will be years before I can even consider Apache2, > > given the architecture and API differences between the two. If something > > could be done in an Apache-1.4 and 2.1/2.2 to help bridge the gap perhaps > > one day Apache2 will be an option, but today it is simply too big a gap to > > jump and I am pretty sure the bulk of the Apache community is in the same > > boat. > > I think the key thing is "bugfixes" compared to "features" and > "architecture changes". > > I am +1 on seeing bugfixes go into v1.3 - people are using it, and if it > can work better, so be it. But to actively encourage people to add > features or architecture changes to v1.3, that simply turns v1.3 into > "something else no longer compatible with v1.3", which we already have: > v2.0. > > Regards, > Graham > --
Re: consider reopening 1.3
Rasmus Lerdorf wrote: On Sun, 16 Nov 2003, Jeff Trawick wrote: Too bad all these supposedly-disenfranchised people aren't around to review 1.3 fixes. 1.3 would be healthier if they were. And it is the reason for why they are not around that is in question here. Why wouldn't there be plenty of hackers around for a piece of software used to widely? Blaming the hackers seems a bit shortsighted. Have a look at the environment we have given them to operate in and at some of the responses over the years people have gotten when they suggested new features for 1.3. The point was not to blame anybody. Instead, I don't believe there are so many people as you imply. Many of the people who are no longer developing have moved on to other interests/work/etc. and have dropped out of httpd dev because of that. If somebody is no longer working on [EMAIL PROTECTED] because they feel disenfranchised, it is fair to point out that their skills are still very useful even if they don't want to mess with 2.x.
Re: consider reopening 1.3
On Sun, 16 Nov 2003, Graham Leggett wrote: > I think the key thing is "bugfixes" compared to "features" and > "architecture changes". > > I am +1 on seeing bugfixes go into v1.3 - people are using it, and if it > can work better, so be it. But to actively encourage people to add > features or architecture changes to v1.3, that simply turns v1.3 into > "something else no longer compatible with v1.3", which we already have: > v2.0. We have two completely different pieces of software. The fact that they are both called Apache is just marketing. By saying bug fixes only in 1.3 you are effectively telling people who want to work on it to get lost. There are plenty of evolutionary things that could be done in it short of the revolutionary jump to Apache2. We know the jump is too big for a big chunk of the market but nobody seems to want to address that. -Rasmus
Re: consider reopening 1.3
On Sun, 16 Nov 2003, Jeff Trawick wrote: > Too bad all these supposedly-disenfranchised people aren't around to review 1.3 > fixes. 1.3 would be healthier if they were. And it is the reason for why they are not around that is in question here. Why wouldn't there be plenty of hackers around for a piece of software used to widely? Blaming the hackers seems a bit shortsighted. Have a look at the environment we have given them to operate in and at some of the responses over the years people have gotten when they suggested new features for 1.3. -Rasmus
Re: consider reopening 1.3
Rasmus Lerdorf wrote: I also work for a large company with plenty of talented developers and thousands of production Apache-1.3 servers along with hundreds of custom Apache-1.3 modules. It will be years before I can even consider Apache2, given the architecture and API differences between the two. If something could be done in an Apache-1.4 and 2.1/2.2 to help bridge the gap perhaps one day Apache2 will be an option, but today it is simply too big a gap to jump and I am pretty sure the bulk of the Apache community is in the same boat. I think the key thing is "bugfixes" compared to "features" and "architecture changes". I am +1 on seeing bugfixes go into v1.3 - people are using it, and if it can work better, so be it. But to actively encourage people to add features or architecture changes to v1.3, that simply turns v1.3 into "something else no longer compatible with v1.3", which we already have: v2.0. Regards, Graham --
Re: consider reopening 1.3
Rasmus Lerdorf wrote: *** We need to get back many of the disenfranchised Apache 1.3 developers Who are these people? /me raises a hand Just compare the list of contributors today to 4 years ago if you want a list. diff knows no reasons. Too bad all these supposedly-disenfranchised people aren't around to review 1.3 fixes. 1.3 would be healthier if they were.
Re: consider reopening 1.3
On Sun, 16 Nov 2003, Jeff Trawick wrote: > > *** We need to get back many of the disenfranchised Apache 1.3 developers > > Who are these people? /me raises a hand People have suggested that we have fewer developers today because Apache 2 is too complex. That the crappy economy has reduced the time people have to work on it. Or that Apache-1.3 is simply good enough for most people. I don't think it is any of that. Hackers love to hack, but hackers are also practical creatures. They hack on things that they need and use. They need and use Apache1 but we have taken our ball away and gone off to play another game. Just compare the list of contributors today to 4 years ago if you want a list. > I don't expect any of the current Apache developers would be interested in > this. But plenty of people join the development community over time (see > previous comments) and theoretically the opinions could change. I think the key word there is "current" I also work for a large company with plenty of talented developers and thousands of production Apache-1.3 servers along with hundreds of custom Apache-1.3 modules. It will be years before I can even consider Apache2, given the architecture and API differences between the two. If something could be done in an Apache-1.4 and 2.1/2.2 to help bridge the gap perhaps one day Apache2 will be an option, but today it is simply too big a gap to jump and I am pretty sure the bulk of the Apache community is in the same boat. -Rasmus
Re: consider reopening 1.3
Thanks for your response, Jeff. You present some excellent points and defenses and present worthy opinions. I agree that there are lots of thankless, non-sexy tasks that would help, but the core developers need more manpower. I am hoping to create new avenues for participation. My goal is to get Apache 1.3 reopened. To that end, you responded: > I don't expect any of the current Apache developers would be interested in > this. But plenty of people join the development community over time (see > previous comments) and theoretically the opinions could change. Well, I am interested. And some others on this list are interested. What must we do to have the opportunity to scratch this itch? I suggested releasing 1.4 and opening 1.5 dev, along with better patch management, to which you also agree a better job need be done. I do not think that the _current_ Apache is and _will forever be_ the right tool for a web server. The size of the bug database and feature requests should be sufficient evidence to support this point. I also believe that there needs to be an even easier migration path from 1.3 to 2.x, despite how good it is already. So what will it take to convince the core developers to reopen 1.3? I'm less interested in opinions and more interested in getting something done. Thanks! Glenn
Re: consider reopening 1.3
I would not use this as an argument to re-open 1.3, but: The LDAP authentication module has a number of issues which have been languishing. I really cannot gripe as I haven't fixed any -- just found some, but for some of us this module has become critical. Apache 2 has incorporated LDAP authentication, but it is not yet getting mainstream attention. How does that related to 2.0 vs. 1.3, etc? As I see it, we're still somewhat in limbo in that Apache has incorporated LDAP authentication but not enough of the community has taken an interest in the module to see it to full stability quickly. I for one am thus left torn between a fairly well understood bug set on Apache 1.3 LDAP authentication modules and Apache 2's. [This is certainly not intended as a slight to those putting in serious effort on Apache 2's LDAP authentication modules.] -- Jess Holle
Re: consider reopening 1.3
Glenn wrote: - lack of clear leadership and even basic direction At present I see most of the time volunteered by developers to be spent communicating with users on the bug db and trying to fix bugs. That sounds all well and good to me. If somebody wants something big implemented that they cannot do themselves, let them compel ("lead") the others to want to work on it. If not, so be it. scratch-an-itch development is fine and good, but not in total chaos What is this total chaos? That everybody doesn't get in a room and map out what everybody is going to be doing? This is volunteer work. Some of us are spending quite a few personal funds this week flying somewhere to get in a room together and hash through some issues. Sure, if everybody running their web site on Apache httpd would pay ASF a few dollars a month, things could change, and maybe some of us could spend our long working hours working just on Apache httpd. But that isn't the situation. And I am not interested in this turning into a big business. And for many of us, our day jobs are good influences on our httpd endeavors anyway, even while they take away time that could theoretically be spent making httpd the way you want it to work. - cathedral development it appears that more than a few serious discussions have not happened on-list and instead happen on IRC or elsewhere (board rooms?) without apprising the list of what transpired. (Or have there been absolutely no recent design discussions?) As someone who 1) follows development pretty closely 2) works for a company that has multiple skilled httpd developers and could conceivably host these "board room" discussions 3) hardly ever logs on to IRC, much less sees much discussed there when I happen to be logged on (ooh ooh new conspiracy theory) I don't see this being a problem. YMMV. - patch management many patches posted to this list or the bug db languish in limbo. Very little happens until a core contributor decides to take over a patch (more often than not it is more than simply shepherding it) Little feedback; it often feels like nobody's home to answer the phone... This is a big hole which will be addressed, even if I have to quit my job, abandon my family, find shelter from the wind and rain somewhere that has WiFi access, etc. (No, not really. But this isn't a simple situation that can be solved by proclamation. We already have the will, we just need to have some procedures to help us focus that will.) - insufficient (developer) documentation sure, there's the source, but it takes a lot longer to wrap ones head around the Apache2 paradigms than it did for Apache 1.3 BUFFs and such. The barrier to entry is much higher; solid design documents would be infinitely helpful Documentation is a lot of work and largely thankless. If somebody wants better docs, they should be ready to post patches to what is there already. Or if they actually pay somebody for an Apache-based server, submit doc issues as defects to your vendor. Or pay somebody to do it. Or wait silently for somebody to do it for them. - many new contributors are frustrated and discouraged Hopefully keeping focus on patches will be a big help. But I can't gloss over the fact that this is how new contributers become developers and then able to lead themselves to solutions for problems that they wish to see resolved: Post patches for bugs that are central enough to core operations that existing developers will be compelled (and skilled enough) to review and shepherd them in. Keep doing it for a while. You'll get commit access. You'll be a "developer" and be able to fix other non-core issues pretty much as you choose. Posting patches for something relatively obscure or not generally applicable is not the way to become part of the developer community. Some of these patches may find shepherds, but the surer path is to attack problems that affect everybody and/or are in areas that more people have the skills to review. - dwindling community The apache-dev list focus on 2.0 /to the detriment of 1.3/ is at odds with the rest of the world that relies on the venerable Apache 1.3 - ... 1.3 works well enough for most everybody. That explains the situation well enough for me. So where do we go from here? *** We need better patch management certainly!! *** We need to get back many of the disenfranchised Apache 1.3 developers Who are these people? The better option is reopening the 1.3 tree. Release 1.4 and open a 1.5 dev tree, with the specific intent on having the 1.4 release eventually map _directly_ into a _seamless_ upgrade to Apache 2.x, with very easy and clear directions for using a reverse proxy for those legacy 1.3 third-pary modules.) While upgrading is not hard for developers, Apache is not a simple product. We need an even-better (tm) way to get users from There (Apache 1.3) to Here (Apache 2.x). Yes, more trees are extra w
Re: consider reopening 1.3
Good Point I have noticed that there is still a large number of people that use 1.3 and are upset cause they don't like whats going on with 2. I like you idea we need to make it easyer for people to add to apache I find it hard to even get people to do or help with little things. We have to many indians and no chiefs we need to elect or maybe have some senior member sort of take charge. Linux has torvlus so who will be our hero ;-) -Kyle Hamilton www.kylehamilton.net *blog* www.kylehamilton.com *site in the works* 559-593-1210 - Original Message - From: "Glenn" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, November 16, 2003 1:12 AM Subject: consider reopening 1.3 > Ok, so Apache2 uptake is slower than desired for some (not all) on this > list. That's only logical given the success and therefore inertia to stay > with Apache 1.3. But there are more than a few other factors mentioned in > recent threads that are contributing to Apache2 development stagnation. > Ignore for a moment that vendors have only recently begun shipping Apache2 > as the default web server instead of Apache 1.3. Stas pointed out some > serious problems. I reformulate them slightly differently here. > > - lack of clear leadership and even basic direction > scratch-an-itch development is fine and good, but not in total chaos > - cathedral development > it appears that more than a few serious discussions have not happened > on-list and instead happen on IRC or elsewhere (board rooms?) without > apprising the list of what transpired. (Or have there been absolutely > no recent design discussions?) > - patch management > many patches posted to this list or the bug db languish in limbo. > Very little happens until a core contributor decides to take over a patch > (more often than not it is more than simply shepherding it) > Little feedback; it often feels like nobody's home to answer the phone... > - insufficient (developer) documentation > sure, there's the source, but it takes a lot longer to wrap ones head > around the Apache2 paradigms than it did for Apache 1.3 BUFFs and such. > The barrier to entry is much higher; solid design documents would be > infinitely helpful > - many new contributors are frustrated and discouraged > see all of the above > The voluble Kevin Kiley said it well: > "Make it EASY to contribute... not a nightmare." > - dwindling community > The apache-dev list focus on 2.0 /to the detriment of 1.3/ is at odds > with the rest of the world that relies on the venerable Apache 1.3 > - ... > > Whether or not you take issue with any of the above and can provide > (quite reasonable) defenses, I think you'll agree that the problems > above exist to some degree or another. My driving point is that > action needs to be taken to keep this community fresh and vibrant. > > Since there is not enough time for the project leaders to address these > issues by themselves, the obvious answer is that there needs to be more > people involved to help shoulder these tasks. > > So where do we go from here? > > *** We need better patch management > > Some suggestions were made in recent threads; I won't relist them here, > but they have my full +1 support. I hope those at ApacheCon hash > something great out. > > *** We need to get back many of the disenfranchised Apache 1.3 developers > > Killing Apache 1.3 is not a good option. There is a strong "business" > need in many places to stay with Apache 1.3. > > The better option is reopening the 1.3 tree. > Release 1.4 and open a 1.5 dev tree, with the specific intent on > having the 1.4 release eventually map _directly_ into a _seamless_ > upgrade to Apache 2.x, with very easy and clear directions for using > a reverse proxy for those legacy 1.3 third-pary modules.) While > upgrading is not hard for developers, Apache is not a simple product. > We need an even-better (tm) way to get users from There (Apache 1.3) > to Here (Apache 2.x). Yes, more trees are extra work, but this > community is rapidly deteriorating without them. > > *** We need to get more people using Apache 2.x > > Apache 2.x is not going to get any better than it is now until more > people start using it in the real world (outside the lab). Welcoming > back the 1.3 developers and aiding the transition is one piece. > Making this forum more responsive (e.g. with better patch management) > is another. Project leadership is the biggest key. > > If the Apache project leaders put their heads together, give some > direction to development and patch management, and ask for help, > I'm sure there will be a groundswell of supporters, me among them. > > Cheers, > Glenn