Subject: /rescue, crunchgen'ed?
To: None <email@example.com>
From: Richard Rauch <firstname.lastname@example.org>
Date: 08/30/2002 02:24:22
I've tried to read much of the debate about moving to a dynamic based
system. I'm not going to try to debate the merits of it. I do have one
To my mind, the "stability" of a static linked base system came from not
having a single point of catastrophic failure. (Even if the kernel image
were damaged, you probably have at least one spare lying around if you
built a custom kernel.)
Dynamic linking the rest of the system puts our eggs more or less in one
basket (lose the shared clib and you might as well forget running
anything). "echo *" will tend, for example, to serve in lieu of "ls",
"cat" with redirection may serve in place of "cp", etc.
Using a *single* crunchgen'ed binary for all old /bin and /sbin programs
creates a similar weakpoint: The (single) crunchgen'ed binary itself.
What exactly is the merit of crunchgen'ed binaries? Why not do one of the
a) Just leave it all dynamic and hope crucial libraries don't die.
b) Keep "/rescue" as *distinct*, *statc* binaries, as is presently
The former seems about like the dependancy on crunchgen, and elimites the
complexity of having two sets of binaries.
The latter would mean a slight swelling of our / partition. But, really,
/var goes there anyway (IN THE DEFAULT CONFIGURATION). So does /home.
If people want to take the default config, then they've got tons of stuff
with a high turnover rate on their root partition, and the du of the df of
the disk will approach 100% capacity over time anyway. As long as the
default configuration puts /var and /home on /, I am not sure why people
worry about crunchgen'ing /rescue.
The latter also makes it simpler to "kick back" to the old style for those
that want it: Just don't build the dynamic linked binaries and mv/cp/ln
the static ones over there.
A second, slightly related suggestion:
Perhaps, as well (if this isn't already part of the plan), /rescue (if
provided) should be a distinct parttion, while /usr can be merged with /
in the default config. /rescue should be realtively constant in size,
hence it *can* be safely made small (unlike present /). By merging / and
/usr, more space can be given for trees that by default end up on the
(presently-cramped-by-default) / partition. (I.e., in particular, user
home directories and /var.)
IMHO, this would increase the utlity of the default partitioning scheme.
Sorry if these two points have been raised and debated already. A URL to
the head of the subthreads (or even a "both have been stated in about as
many words, and we aren't doing them, but thanks for trying") would be
appreciated, if I missed the discussion.
Sorry, also, if I'm simply being inept in these suggestions. (^& Feel
free to point that out, as well.
``I probably don't know what I'm talking about.'' --email@example.com