cvs commit: src/sys/i386/conf GENERIC src/sys/alpha/confGENERIC src/sys/sparc64/conf GENERIC src/sys/amd64/conf GENERIC src/sys/pc98/conf GENERIC

[Scott Long]

On Tue, 9 Dec 2003, Sean Chittenden wrote:
> > >On Mon, Dec 08, 2003 at 11:00:20PM -0800, Sean Chittenden wrote:
> > >
> > >>... Moving from gzip to bzip2 for the base files reduces the
> > >>current size of the base files by about 13-22%.
> > >
> > >I've been trying to move us to bzip2 for the base distribution files
> > >since 4.6 (2 years now).  RE has blocked it before ...
> >
> > Two observations:
> >  1) bunzip2 requires almost 4MB of memory,
> >     compared to gunzip's 600KB.
>
> You must be talking about RAM and not disk space.
>
> % du -h /usr/bin/bzip2 /usr/lib/libbz2.so.1
>  26K    /usr/bin/bzip2
>  62K    /usr/lib/libbz2.so.1
>
> A few notes on RAM consumption:
>
> *) Kiss the notion of getting stock FreeBSD to run on your tipped out
>    8086 w/ 4MB of RAM.  :) Last I heard, base FreeBSD required 8MB of
>    RAM.  With a 128MB stick costing ~$20, I'm hard pressed to scrounge
>    up any sympathy for those trying to run the latest and greatest on
>    the oldest and most skanky.  For the 8MB machines out there,
>    however, there's the -s switch to bzip2 that reduces the runtime
>    size by about 50% down to ~2300K.  man bzip2

I think that in all respects, x86 machines that predate the Pentium-MMX
series are much better suited by FreeBSD 4.x.  The compelling features
of 5.x (PAE, NSS, SMPng, ACPI, etc) just don't have much value on these
ancient machines.  If you have sentimental attachment to some old machine,
you'll just plain be happier in all respects to run 4.x on it.

>
> *) For those folks, myself included, who use FreeBSD on
>    devices... we're not using bzip2 on them and aren't about to use a
>    CD to install an OS onto an EPROM.  :)
>
> >  2) bunzip2 is about 10x slower than gunzip on my system.
> >  (Decompressing the openoffice tarball: 42s vs. 4s)
>
> 10% speed vs. 20% disk on install CDs.  *shrug* With CPUs getting
> faster and the standard ISO image still being a CD (no gripes from the
> DVD users in the crowd!) that's confined to ~660MB, I'd say space
> requirements win out.  I think speed of install only matters on TV
> spots when we're watching Mark Murray install a complete FreeBSD

I think that you man 'Murray Stokely' here.

> server in 3min (note, 120% of 3min is about 3.5min... not catastrophic
> loss of performance for what is essentially a one time operation).
> For the extra space (potentially up to ~85MB-145MB), I think the 30sec
> is worth it.  Oh, and aren't we already using bzip2 for the packages?
> Given that's the bulk of the time that would be spent on installations
> for desktops, doesn't that make this a rather mute point?

We've bought a little breathing room by creating the gnome-lite and
kde-lite packages.  My guess is that this will only get us through the
5.x life at best.  Having another 20% would give 50-60MB more space,
which will last us a few more years.

The other thing to consider is that the default configuration of
FreeBSD is to have UDMA disabled on the IDE CD drives.  This is
unbearably slow on modern hardware, so it's unclear whether the overhead
of bzip2 would add onto this, or just be absorbed.  If we found a way
to be more intelligent about enabling UDMA, the overhead of bzip2 would
probably be totally absorbed. Either way, the recent RedHat and Suse
installers seem glacially slow too, so it might all just be academic =-)

Scott