public inbox for overseers@sourceware.org
 help / color / mirror / Atom feed
From: Jason Molenda <jason@molenda.com>
To: Jim Kingdon <kingdon@redhat.com>
Cc: overseers@sourceware.cygnus.com
Subject: Re: A cvsup account..
Date: Sat, 30 Dec 2000 06:08:00 -0000	[thread overview]
Message-ID: <20000321144959.C15297@shell17.ba.best.com> (raw)
In-Reply-To: <200003212213.RAA16571@devserv.devel.redhat.com>

On Tue, Mar 21, 2000 at 05:13:24PM -0500, Jim Kingdon wrote:

> From my point of view it is pretty silly to be building things like
> Apache, wu-ftpd, or Kerberos from source when people elsewhere in Red
> Hat are already doing the exact same thing for the Linux product.

I always liked building it myself because I could specifically enable
anything I needed, disable anything I wasn't using, and have complete
control over the program.

It'd take more work to familiarize myself with the program, but in
my humble experience, the RH builds weren't any better than what
I did on my own.

As sourceware has less active maintainership (surely the next
generation of sourceware is just down the road :-), using prebuilt
RPMs is not unreasonable.  

Actually, apache is a bad example because we use an unofficial
module, mod_gzip IIRC, which is not a part of the main distribution.
When a user's client supports compression, and the user requests
foo.html, if foo.html.gz exists, that is sent instead.  Huge
bandwidth savings for big files like on-line docs which can be
100-200k apiece.  I also generate .gz versions of the mailing list
indexes after a time period (month, quarter, year) has finished.
Try looking at some old archives -- notice how the date index loads
an awful lot faster than it should.  One big gotcha is that mod_gzip
does not check whether the foo.html timestamp is newer than
foo.html.gz, and if you have any server side include directives in
foo.html, they will not be expanded when the foo.html.gz is sent.

In addition, I use a hack written by DJ Delorie to Apache.  If you
have Apache set to treat files ending in ".html" as SSI files, then
Apache will not send a Last-Modified header for that file.  The
idea is that in foo.html, you might include bar.html.  Which one
should the L-M date list? What about dynamic content?  Does a L-M
header have any meaning if most of the page is generated on the
fly via SSI's?  Apache has some lameoid XBit (I forget the exact
term) mode where it will send a Last-Modified header for files if
their execute bit is set (some bit, I forget which).  DJ's hack
makes it so that the Last-Modified date for the source foo.html is
sent.

If you run a web server with SSI's ending in ".html" without this
(and without using the XBitHack thing), none of your documents will
ever have a Last-Modified header, and no client on the web will
ever cache your pages -- each time someone looks at a page, they
get to reload it.  If a page is long, and they keep coming back to
it, you're going to piss off slow-link users, and you're going to
waste a lot of your bandwidth.  It's important to fix, and the
Apache guys obviously know about the problem (XBitHack or whatever
has a short discussion of it in its docs), and it is doubtful that
they'd want DJ's hack.  A better fix might have a configuration
option in the httpd.conf which allows the administrator to specify
how last-modified headers should be generated for SSI files.


As for cvsup, sources are pretty useless for this, so might as well
go with prebuilt binaries.  For things installed on sourceware, I
always put the distribution files (source in most cases) in
/usr/local/src/<name> with a pointer to the master distribution
site in /usr/local/src/WHENCE.  I would often leave the build trees
in place, .o's and all, so that someone rebuilding something in
the future could see exactly how something was configured and built.
(read:  I often forgot how I built something, so I used it as a
crib sheet when I had to rebuild.)  We have so few things installed
on sourceware that the disk space usage is not significant.

Jason

WARNING: multiple messages have this Message-ID
From: Jason Molenda <jason@molenda.com>
To: Jim Kingdon <kingdon@redhat.com>
Cc: overseers@sourceware.cygnus.com
Subject: Re: A cvsup account..
Date: Tue, 21 Mar 2000 14:50:00 -0000	[thread overview]
Message-ID: <20000321144959.C15297@shell17.ba.best.com> (raw)
Message-ID: <20000321145000.lHBEUE2OFT321ciQc4lWIQjIqAIndobfvEb3lQTcUBc@z> (raw)
In-Reply-To: <200003212213.RAA16571@devserv.devel.redhat.com>

On Tue, Mar 21, 2000 at 05:13:24PM -0500, Jim Kingdon wrote:

> From my point of view it is pretty silly to be building things like
> Apache, wu-ftpd, or Kerberos from source when people elsewhere in Red
> Hat are already doing the exact same thing for the Linux product.

I always liked building it myself because I could specifically enable
anything I needed, disable anything I wasn't using, and have complete
control over the program.

It'd take more work to familiarize myself with the program, but in
my humble experience, the RH builds weren't any better than what
I did on my own.

As sourceware has less active maintainership (surely the next
generation of sourceware is just down the road :-), using prebuilt
RPMs is not unreasonable.  

Actually, apache is a bad example because we use an unofficial
module, mod_gzip IIRC, which is not a part of the main distribution.
When a user's client supports compression, and the user requests
foo.html, if foo.html.gz exists, that is sent instead.  Huge
bandwidth savings for big files like on-line docs which can be
100-200k apiece.  I also generate .gz versions of the mailing list
indexes after a time period (month, quarter, year) has finished.
Try looking at some old archives -- notice how the date index loads
an awful lot faster than it should.  One big gotcha is that mod_gzip
does not check whether the foo.html timestamp is newer than
foo.html.gz, and if you have any server side include directives in
foo.html, they will not be expanded when the foo.html.gz is sent.

In addition, I use a hack written by DJ Delorie to Apache.  If you
have Apache set to treat files ending in ".html" as SSI files, then
Apache will not send a Last-Modified header for that file.  The
idea is that in foo.html, you might include bar.html.  Which one
should the L-M date list? What about dynamic content?  Does a L-M
header have any meaning if most of the page is generated on the
fly via SSI's?  Apache has some lameoid XBit (I forget the exact
term) mode where it will send a Last-Modified header for files if
their execute bit is set (some bit, I forget which).  DJ's hack
makes it so that the Last-Modified date for the source foo.html is
sent.

If you run a web server with SSI's ending in ".html" without this
(and without using the XBitHack thing), none of your documents will
ever have a Last-Modified header, and no client on the web will
ever cache your pages -- each time someone looks at a page, they
get to reload it.  If a page is long, and they keep coming back to
it, you're going to piss off slow-link users, and you're going to
waste a lot of your bandwidth.  It's important to fix, and the
Apache guys obviously know about the problem (XBitHack or whatever
has a short discussion of it in its docs), and it is doubtful that
they'd want DJ's hack.  A better fix might have a configuration
option in the httpd.conf which allows the administrator to specify
how last-modified headers should be generated for SSI files.


As for cvsup, sources are pretty useless for this, so might as well
go with prebuilt binaries.  For things installed on sourceware, I
always put the distribution files (source in most cases) in
/usr/local/src/<name> with a pointer to the master distribution
site in /usr/local/src/WHENCE.  I would often leave the build trees
in place, .o's and all, so that someone rebuilding something in
the future could see exactly how something was configured and built.
(read:  I often forgot how I built something, so I used it as a
crib sheet when I had to rebuild.)  We have so few things installed
on sourceware that the disk space usage is not significant.

Jason

  parent reply	other threads:[~2000-12-30  6:08 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-12-30  6:08 Andrew Cagney
2000-03-20 21:01 ` Andrew Cagney
2000-12-30  6:08 ` Tom Tromey
2000-03-21  8:10   ` Tom Tromey
2000-12-30  6:08   ` Andrew Cagney
2000-03-21 13:58     ` Andrew Cagney
2000-12-30  6:08     ` Jim Kingdon
2000-03-21 14:13       ` Jim Kingdon
2000-12-30  6:08       ` Jason Molenda [this message]
2000-03-21 14:50         ` Jason Molenda
2000-12-30  6:08         ` Jim Kingdon
2000-03-22  9:29           ` Jim Kingdon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20000321144959.C15297@shell17.ba.best.com \
    --to=jason@molenda.com \
    --cc=kingdon@redhat.com \
    --cc=overseers@sourceware.cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).