Robert Day zarin at
Sat Jan 3 09:26:41 PST 2004

On Sat, 2004-01-03 at 11:54, Archaic wrote:
> On Sat, Jan 03, 2004 at 10:35:16AM -0500, Robert Day wrote:
> > 
> > I think it will be generally agreed upon that the VERY vast majority
> > of our target audience will have some sort of high-speed, always-on
> > connection.
> I wouldn't be so presumptuous. What basis of proof do you have for that
> statement?
personal experience only I am afraid.  I know quite a few linux users on
normal home connections (dialup, DSL and Cable) and very few of them
give a rats ass about security..  They care about toys, fun and games,
or coding, or power, or stability.  Hardening and Securing the box is of
very little concern...  For the most part (ie. I know one person who
cares more than a second look, and runs his distro's update tool once a
month) people install a distro, play with it, get games in it, tweak
their UI, etc. etc.  Get the people who are more interested in the
computer and the security, and they are running gateway boxen that are
up to date.. they remove their distro packages and install from source
(ie. apache and bind) and monirot mailing lists. These are usually the
code-warrior and administrator type folks, who are using an always-on
connection, and often have either a static IP or a dynamic DNS for their
There will always be exceptions, but the people I have met all fit into
that classification (or those classifications I guess I should say)

> > We should not say "let's find a way to patch foo-2.4 to make it work
> > just like bar-1.6.
> First of all, most differences between HJL and FSF do get backported
> anyway. They really aren't different projects. They are the same project
> at 2 different levels functionality. FSF takes the slow road and
> incorporates much of HJL after HJL has been extensively tested.
I was referring more to your syslog comment. HJL and FSF, I agree, use
what is tested and accepted. But for more common applications, like
syslog, patching might not be as logical..  And I agree, we should
evaluate each method.

> Again, though, on the generic, it would be wise to default to keeping
> the same packages _unless_ they just can't do what we need them to. We
> shouldn't be gung-ho to change packages just because of personal
> preference. Like I said before, it's not just a matter of saying "package
> X is great, let's use it". That just gets everyone hollering for their
> favorite packages. We need cohesion as far as the book goes. Some
> packages will undoubtedly be changed. Some will be patched. Haste is the
> only thing I caution.

Agreed.  I would be so bold as to say the HLFS project is actually
moving faster than I would like to see (actually, not really faster,
just in the wrong areas)  I still hold firm that a Roadmap should have
been agreed upon before going out and trying all these hardening methods
and what not.

Oh well, progress in any direction is better than stagnation ;)

  Rob Day (BOFH)

More information about the hlfs-dev mailing list