Date: Tue, 17 Mar 1998 10:51:53 -0800 (PST)
From: Dean Gaudet <dgaudet@arctic.org>
To: new-httpd@apache.org
Subject: Re: cvs commit: apache-2.0 STATUS
In-Reply-To: <199803171524.KAA09567@devsys.jaguNET.com>
Message-ID: <Pine.LNX.3.96dg4.980317103423.23713B-100000@twinlark.arctic.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org


On Tue, 17 Mar 1998, Jim Jagielski wrote:

> rasmus@bellglobal.com wrote:
> > 
> > > Configure is always being derided as crappy, but it is restricted,
> > > by long tradition and common sense, to only use those capabilities
> > > that existed in the System 7 'sh' (eg: no function, etc...). One
> > > possible key to Apache's success is that it does not require any
> > > more than basic UNIX tools (and an ANSI C compiler) to build, compile
> > > and run. Many of the ideas floating around for 2.0 would, by default,
> > > (drastically) change this. Is this a good idea?
> > 
> > Oh boy, campaigning to keep Configure in 2.0?  Shoot me now!  
> 
> Nope... Not really. Just bringing up a point. And it _is_ a valid
> point, whether we are talking about Configure using sh or perl or
> perl5 or whether we are talking about C vs C++ vs Java or whether
> we are talking about zero-write IO. Apache's "generalness" is
> an asset, IMO, and one major reason why we run on over 50% of the Net.
> If we decided that, instead of doing that, we would focus on those
> OSs with, for example, a solid mmap(), then we would no doubt have
> a better performing Apache, but at a decrease in "market share" since
> not all OSs have mmap and not all that do have one that isn't totally
> bogus.

I think you've mistaken a lot of these features as being requirements. 
zero-copy I/O isn't even possible on many modern systems (including linux
and freebsd).  The proposals are just to make it POSSIBLE to do that
stuff, not necessary... but also make it possible on all systems to do
zero-copy within Apache -- maybe there's still a copy into user space and
a copy out of user space in the kernel, but that's not anything we can do
something about.

Any my threading proposal was carefully constructed to maintain the
current process model.  Not just for legacy systems, but also because
folks just won't be able to use threads if they, for example, link with a
database library.  Last I checked ndbm/db/gdbm aren't thread safe.  Kind
of limits what you can do with a threaded apache.  It'll make a hot proxy,
and a hot static content server.  And it'll do some dynamic content,
presumably mod_perl eventually.  But it's not going to talk well with
databases... 

But the way I would prefer we approach this stuff is that as long as it's
possible, and someone is supporting it, that's fine with me.  But I'm
personally not interested in maintaining all the corner-case systems --
I'm quite content maintaining linux, and trying not to break freebsd and
solaris.  There are others here who maintain freebsd, solaris, sunos, hpux
(occasionally), aix, win32, and a few more I'm sure. 

But how many of us, for example, maintain unixware?  None as far as I
know.  It's my opinion that if unixware folks want Apache to work on it
then they can do the minimal amount of work required to keep apache up to
date on unixware.  That means either unixware users, *OR* SCO themselves. 
It's a free ride a lot of these corner cases get now. 

When Ben Hyde's automated builds show a config/compile bug, I'm happy to
fix it when I can do so without access to the machine.  But I am
absolutely tired of trying to support every platform under the sun when it
comes to bug reports.  It's only minorly annoying to get "it won't compile
on blargix/2.34".  It's a MAJOR ANNOYANCE to get "it compiles and runs and
then hangs/crashes/fills the error_log".  Those are things which are very
hard to fix correctly without access to the machine.

That's where I would like to say "Joebob, you're the blargix maintainer,
this is yours".  And if there's no maintainer... well... tough.  The user
is going to have to figure it out for themselves or ask questions in
newsgroups or whatever.

> > An autoconf-generated configure script is also just a shell script, and
> > it doesn't use functions or any non System 7 sh features as far as I can
> > tell.  It is even less demanding on the system than the current Apache
> > Configure script because it doesn't use awk, sed, grep, egrep or any of
> > those.
> > 
> 
> It also dies on many older '/bin/sh's and require instead that it
> be run by bash or ksh :)

So you want us to waste our time maintaining a hodge podge piece of crap
configuration system.  Jim you keep saying that we can improve our
configuration, and we can keep up with the ports... and you've volunteered
to do it.  But I hate to point out that this just isn't happening -- there
are probably a dozen compilation bug reports in the bugdb which haven't
been dealt with as far as I know.  I figure you're too busy to do it,
which is totally fine.  But if that's the case then you should tone down
your claims that we can improve Configure.

You pointed out that perl uses its own in-house configuration.  I would
bet that perl-porters has folks who use the various platforms and maintain
the related ports.  Unlike us where we have to make guesses as to what
Configure changes to make to some platforms.  But I don't read
perl-porters any longer so I've no idea. 

Dean