[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: how to make Debian less fragile (long and philosophical)



* Craig Sanders said:
> On Mon, Aug 16, 1999 at 07:56:14PM +0200, Marek Habersack wrote:
> 
> > (yes, I can hear you saying "you can always pass the 'init=/bin/sash'
> > parameter to the kernel - and it is IMPOSSIBLE to do when you use a
> > standard LILO installation - it doesn't allow the user to provide
> > kernel params, it's not interactive).
> 
> if you mean the standard lilo.conf created by a debian install then
> you are mistaken. press ? or TAB as soon as you see the LILO prompt
> (actually you have about 2 seconds) and the boot will be delayed until
> you select a kernel image, optionally enter args, and hit enter.
> 
> it's been like that for as long as i can remember, and i've been using
> debian since around 0.93r5
My apologies, then. For my excuse I can only say that I don't use lilo and
haven't been using it for years :)). Now I RTFM :)) and the lilo.conf man
page indeed says that LILO shall wait 4 seconds for the user to press ? or
TAB. Anyway, most users don't read lilo manpage and even if they do, many of
them will find it cumbersome to do such "sourcery" with their fingers why
they would only type 'recover' or 'emergency' should they boot in a single
mode and with a static shell.

[snip]
> i can't recall even one time where dynamic libs failed and broke the
> system. the closest we came to that was the libc5 to libc6 migration and
> we came up with an automated upgrade script which avoided any problems
> by upgrading certain packages in the right order.
Well, remember that fun with broken readline and bash not working anymore?
Sure, it was on unstable, but it happened anyway. If bash wasn't linked
against readline, db, libc, ncurses (!!) it couldn't fail in such a case.
I'm merely saying that the more runtime dependencies (I'm not talking about
package deps, but binary ones) a vital application the more chance it will
break - accidents happen and people, esp. those with no unix experience, can
erase or break this or that library and, in effect, ruin their system. Yes,
it can happen whether shell is static or not, of course, but there should be
a way to log into a system even if the standard USER shell is fubar, and
there should be a way to use some utilities to repair the damage. And with
bash as a standard shell for anyone, well, there may be trouble when, eg,
ncurses break - and I remember there was a time ncurses were seriously
damaged on Debian. To summarize - I don't vote for all utilities be
statically linked for daily use, no - it would be a waste of disk space,
memory and time. I just feel there's a need to provide a set of EMERGENCY
utilities to repair all kinds of damages resulting from dynamic linking
failure - and that includes admin or user mistakes, malicious manipulation
of the system, upgrade problems. Also, there should be a simple and easy way
to enter a mode where the static utilities are used by default. SASH has a
provision of creating aliases - when used it should alias all the standard
command names to use the static versions.

> i have nothing against the idea of having some statically linked
> binaries in /bin or /sbin or wherever - but i don't think it will do
> much (if anything) to increase debian's robustness. in my experience, it
> is not necessary.
Well, you were lucky then and you are probably working on your own. I had
accidents of people erasing some "unnecessary and bloating" stuff from /lib
- and these things HAPPEN, believe me. So, I think such utilities are really
useful. 

> also BTW, this whole thread seems to have come about because you (or was
> it someone else who started this thread?? i've lost track) decided to
> upgrade from stable 'slink' to unstable 'potato' and got yourself bitten
> by a temporary instability. tough. that's the way unstable is.
No, it wasn't me who started the thread, nor I never complained about potato
ruining my systems. I'm using potato almost from the very beginning and,
with an exception of the infamous bash-readline case and the latest perl
upgrade, I had no major problems with it. True, recently I was installing a
new Debian box and (as you yourself do) I was first installing SLink only
then upgrading to potato. bash upgrade failed and so the entire process of
upgrade went out of the way. Fortunately I was logged as root on another
console BEFORE the upgrade (I always do that while upgrading) and was able
to fix things by hand - the "old" bash was still in memory, so I could use
it. I fetched ash, made /bin/sh point to it, unpacked the bash .deb by hand
and then simply ran dpkg to install said bash package. Re-running dselect
was a matter of a second and everything went just fine. Well, you, and many
of us here can do such trickery and help themselves, but the times when
Debian was considered a distribution only for unix professionals are over -
there are many rookies out there using Debian and, yes, also unstable
releases. Nobody can stop them from doing it, ruining their systems and then
complaining about it and spreading bad words about Debian. Why not to
provide them with a clean and fast way out of such trouble?

> if you decide to use unstable, that is entirely at your own risk. if
> it does happen to work on one day (or even 99% of days) then consider
> yourself lucky, but don't whinge if you're unlucky enough to use it on
> one of the days when it doesn't work.
I use it all the time on production systems - and I cannot complain :)), it
works just fine :).

> broken - any of these actions will be respected. whinging and demanding
> that others do work that only you consider to be important will do
> nothing but annoy people.
I'm not whining nor I'm the only one who considers this thread's subject
important. I hope I explained my point of view above. If nobody steps up and
volunteers to modify the relevant packages to support what was discussed in
this thread - then I'll be glad to do it.

regards,
  marek
  

Attachment: pgpSYXMt66Ndc.pgp
Description: PGP signature


Reply to: