Re: how to make Debian less fragile (long and philosophical)
Raul Miller <raul@usatoday.com> writes:
> On Tue, Aug 17, 1999 at 11:57:48AM +0200, goswin.brederlow@student.uni-tuebingen.de wrote:
> > The chance that you destroy your base system during an upgrade of
> > stable is so low, that a rescuedisk is good enough, no need to waste
> > the space on disk and memory and to slow down the system by having
> > only static bins on /. Also whats the point of it? As soon as a broken
> > libc is released, all bins would be statically linked against that.
> > If the lib is broken, all the bins will be broken as well. And fixing
> > that would be much more work than just copying the libc from the
> > rescuedisk.
>
> No.
>
> As has been said in several other messages (and not just by me), rescue
> disk doesn't work where high uptime is a requirement. [I've decided that
> remote administration is just one example of this kind of requirement.]
If you want to update an remote system, you should test the update
localy first. As a further precaution, you can create a small
changeroot system on the remote maschine and update that too. If that
works as well, you update the main maschine and off you go.
There are enough possibilities to check whether an update works first
without rebooting. The rescuedisk is there for cases of you own
stupidity, like "dpkg --force-remove-essential --purge bash". Static
linking doesn´t help you there.
> Linux has the capability of supporting upgrade without reboot. Why require
> reboot for all rescue operations? [I grant that there are cases where the
> system must be rebooted, but most cases don't require this.]
You don´t have too, its your own choise. But whats the point of
updating something essential like libc, if nobody is going to use
it. And if you restart all services by hand, you could just as well
reboot.
> > 30 years of hard won knowledge state "Never change a runing system"
> > and "Allways make backups". People allways do the same errors
> > again. :)
>
> And, "Never put yourself in a situation where you must rely on backups,"
> and "never design a system so that you must reboot it".
>
> It's a perfectly valid sysadmin decision to reboot a system -- perhaps
> every week or month. But you shouldn't design a system so that it has
> to be rebooted as an optimization tactic. [Which is what every argument
> against statically linked system binaries comes down to.]
Why would you reboot less with static binaries? Any reason to reboot a
dynamicaly linked system works for a staticaly linked system just as well.
> However, it's probably true that most people don't have a need for
> system routines to be statically linked -- so such packages should
> be optional in some sense of the word.
>
> > As I said above, one fsck is enough to waste 128 MB ram.
>
> This makes the memory footprint of static linking rather trivial,
> wouldn't you say?
Statically linked binaries would waste 10-20 MB ram during boot on my
maschine here I would think (libc-2.1.2 is 1.4 MB on Alpha). So on a
64 MB maschine thats 15-30% ram. Thats not acceptable.
> > Installing something on a production system without a on the fly
> > backup/restore is stupidity. If you don't have the five minutes time
> > to restore a libc from the rescue disks, use a second system or a
> > chroot system to check if the update works first.
>
> Yes.
>
> But that's not a guarantee that mistakes will never be made.
But static linking doesn´t prevent mistakes eigther, sad but true.
Actually the chroot enviroment is the safest way to check an
update. You can run everything run normaly in the chroot with the
updated libs and if something breaks an "exit" and "/etc/init.d/xxx
restart" is enough to revert back to the old version.
> > > The system should strive to guarantee the availablity of anything
> > > that you might need in single user mode, and you are much more able
> > > to guarantee that when it's statically linked.
> >
> > Thats not true. If something like the libc is broken, all statically
> > linked bins will also be broken and then its much more work.
>
> Only if new statically linked bins which were compiled against the broken
> libc get installed.
The autobuild demons and apt-get update would see to that. Or do you
install packages one by one and check out the result after each? If
you do, you could just as well check out the dynamic lib in a
changeroot enviroment.
If you say that stuff like mount or bash won´t be broken when
statically linked, the same hold for the dynamic versions and the
libs. Within hours the autobuild demons would update any staticaly
linked packages to the new libc version.
> > If something gets deinstalled by mistake, its gone, no matter if its
> > dynamic or static.
>
> True.
>
> Then again, would you argue that it's not worth wearing a seatbelt in
> a car because you'd still be dead if someone chops your head off?
I would argue against two seatbelts, that are fastened at the same
knob, because you fear that the knob might break.
May the Source be with you.
Goswin
Reply to: