stripping secure servers (was Re: releases and stuff)

Bennett Todd bet at rahul.net
Wed Nov 17 17:21:25 PST 2004


2004-11-18T00:08:10 Robert Connolly:
> So putting gcc in /opt wouldn't be very usefull then?

Different folks have different perspectives. From my point of view,
the job that /opt was designed to solve (like the role of
/usr/local) is obsoleted when software packaging is used for the
entire system. [I'll be delighted to discuss that point at further
length, but will invite offline discussions as it feels off-topic
for hlfs. Perhaps lfs-chat?]

> Because if someone were going to start doing stuff like that
> (having minimal applications installed) then they would be best
> off using packages, or a whole new build (busybox in chapter 6
> with hlfs host); both of which are a whole place beyond hlfs.

Agree and disagree, all at once.

mjr-style rabidly hardened systems don't seem to me to be the
first-stop focus for any *LFS, even hlfs. As you say, the techniques
involved are advanced, and more than somewhat decoupled from the
bootstrapping that's the From Scratch part.

On the other hand, having the thought of such systems somewhere in
mind, as a possible advanced topic that might possibly be of
interest, might be a slight motivator.

It wouldn't say that HLFS should use exclusively static linking and
eschew all support for dynamic linking --- but it might suggest that
thinking about what things are easy to statically link, and how to
set that up, might possibly be in scope. And if static linking is of
any interest at all, then perhaps so is uClibc, as an option.

It wouldn't argue that an HLFS system shouldn't have the full build
toolchain, coreutils and bash and grep and gcc and bison and perl
and .... But it might argue for thinking about how build and prod
systems could, at some more advanced stage, be decoupled.

It wouldn't mandate basing HLFS on software packaging, but it might,
if your prejudices for how to do these kinds of things run on the
same lines that mine do, argue for trying to structure the HLFS
build data so that it's easy to extract into an ALFS-style
automation system, with a view to perhaps introducing one that uses
software packing at some point to help in advanced systems admin and
config management.

I know what _I_ want --- but I already pretty much have it, I'm not
begging it from you, and I understand that it's at best tangential
to HLFS's project goals. But perhaps it might be a suggestive
waypoint, to help weigh in on design decisions that are in the
balance.

-Bennett
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20041118/4173a5f4/attachment.sig>


More information about the hlfs-dev mailing list