Re: itp: static bins / resolving static debian issues
On Tue, Aug 24, 1999 at 09:19:47PM +1000, Anthony Towns wrote:
> When heaps of other people are able to run Debian in a stable server
> environment without statically linked binaries, and even recover from
> catastrophic crashes successfully; then clearly they're not a necessity.
Except that you recover by rebooting. I've argued the case that there
is a small but significant group of people for whom rebooting is just
not an option (for one of two reasons: logistics, or critical server).
I have suggested that many of those people may not realize that they
need static binaries, even though their need for them is enormous. This
is owing to lack of experience either with Debian or with Unix.
The rest of the population wouldn't notice a difference whether they
had them or not.
So we have a situation where the lack of statics is devestating to
a significant number of people (not a majority), and the precense
of statics has virtually no impact on anyone else.
> That's not to say they're not desirable or anything, but when you
> continually say things to the effect of, "You're all a bunch of idiots
> who obviously don't know what stability even means!!!!!", it's easy to
> get annoyed.
I never said any such thing. I just got a bit frustrated with people
who simply posted opinions, without backing them up with substantial
points. I have never expressed any such frustration toward people
who take credible runs at my proposal. On the contrary, I value that.
> > You will all find it very familiar, since I've said it all before,
>
> At this point, I'd like to say that if we're obviously not all being
> convinced by your arguments there's not much point just repeating them.
> There's been a million and one messages on the topic, everything's
> already been said in enough different ways.
On the contrary, several people have raised objections, which have
been met, the proposal has changed a few times, and real progress
has been made.
> Fortunately, this being free software and all, talking isn't your only
> option.
>
> Instead, you can just say "to heck with everyone" and just do it.
The package already exists, it is called "sash", and really all that
has to be done is that it needs to become the default. It may need
a few modifications as well, a .deb has already been posted illustrating
the changes.
> "Free software is necessary for stable servers."
>
> It's not. Sure, most people here agree with the sentiment, but it's
> far from a fact. Ditto "Statically linked binaries are necessary for
> stable servers."
I actually said that statically linked binaries are necessary for
servers which cannot be rebooted. Many stable servers exist that
can be rebooted, and thus do not need statics.
Alternately, you could provide me with some other proposal for
live recovery, not involving statics, and I would accept that, if
it were made the default.
Of all the options, statics seem to be the only one that could be
made the default while having negligible impact on people who
don't need them. Installing a backup root by default would solve
my problem, but would hugely inconvenience people who don't need it.
Installing statics also solves my problems, and 99.9% of Debian users
who don't need it would never notice it had been done--it would have
so little impact on them.
I used the word "my" above, you can consider the word "my" to mean
anyone in the class of people who are administering servers which
cannot be rebooted.
> > Proposition #3-- Debian should, by default, support servers where
> > downtime is unacceptable or difficult.
> >
> > Proof: Much of this portion is opinion;
>
> How quotable.
>
> > but I challenge you to try
> > adding a policy statement to the contrary.
>
> ``Debian will support the needs of our users in many different types of
> computing environment.'' (from the social contract)
>
> ie, we won't go out of our way to support high-availability people to the
> detriment of everyone else.
That isn't the contrary to my statement. The contrary would be to add
to the policy something like, "Debian will not be useful BY DEFAULT
as a server for which continuous uptime is important, or which must
be administered remotely, even if the cost of doing so is negligible."
When you state the opposing view outright like that, it becomes a
lot less pallatable.
The current lack of statics violates the policy you quote above as
well. In order to support many different types of computing environment,
Debian must, at a minimum, provide the things which are essential and
critical for each of those environments--I would think by default,
unless the cost of doing so where too high.
Statics are definately critical if you cannot reboot your server; and
the cost of adding them is absolutely negligible.
> Please remember that you're not the only Debian user, nor the only type
> of Debian user.
Please remember that I am not the only person who needs to keep an NFS
server up and running, or who has a critical database up, or who has
a remotely administered server of some importance.
> In particular, doing things "by default" is a lot more likely to be
> detrimental to everyone else than allowing them to be done optionally.
Since I argued that there was no detriment, and that the cost was
negligible, I don't see how the above is a sensible point. At least,
not unless you show that there is a detriment after all, or that
the cost is actually not negligible.
>
> > Proposition #4-- Failure of the C library can occur under Debian
> > Proof: The package manager can delete it as the result of a bug, as
> > has already happened in the unstable release.
>
> What? When?
Two weeks ago. It was a suble bug, and didn't affect people who already
had working potato systems. It only got you if you tried an upgrade
from slink. It was in the tree for about a week.
That's what caused me to take a close look at the reliability
guarantees that Debian fails to provide, and start this discussion.
> > that is possible in the unstable release is also
> > possible in the stable release, just less likely due
> > to (imperfect) bug fixing.
>
> And all the static binaries could accidently be linked dynamically too. And
> a meteorite might fall from the sky and kill us all.
And it's entirely unlikely that dynamically linked statics would make it
into the stable release; but it's entirely likely that subtle bugs would.
Are you claiming that the probability of a bug in Debian's package
manager is about the same as the probability that a meteor will fall
on my head?
If not, then what exactly is your point?
> Don't overextend your argument. We're not trying to show how completely
> wrong the other guy is, we're trying to build a good operating system
> distribution.
>From the looks of the above, it is you who have overstretched your
arguments. You've abused notions of probability, stretching things so
far as to claim that a meteor is about as likely to hit me on the
head, as the bug I saw last week making it into stable.
I guess you have more confidence in Debian's ability to debug stuff
than even I do.
> > Proof: It is trivial to show how an administrator can cause this
> > by accident, such as with the rm or dpkg commands.
>
> With the dpkg command?
Sure. Some time when some install fails, you might get clever and
think you can force something through. I tried it once, thinking that
I could manually install a dependency once I'd forced through an
install--I was wrong, the package manager was right. When it was
over, it was too late--I'd lost my C library.
Admittedly this was back when I was first trying out Debian, and I
was being a bit reckless precisely because I wanted to test the limits.
But I think it demonstrates that an administrator can mistakenly
remove their C library using dpkg.
> YM, like: dpkg --force-depends --remove libc6 #?
>
> You really think someone can type that by accident?
Sure, if you thought it was broken, and wanted to re-install it, and
you forgot that after you issue this command your ability to continue
will be terminated. On BSD systems I do things like that all the
time--since all my root tools and binaries are all static, I don't
really think twice about it--who cares if the C library is busted
anyway? You can always just fix it, right?
It's easy to move to Debian and forget that you're on thin ice when
it comes to messing with libc.
> > Proposition #12-- The presence of static recovery tools will
> > not pose any difficulties to ordinary use of the system
> >
> > Proof: We have proposed a mechanism by which roots shell could
> > include a fallback static shell while transparently
> > providing access to dynamic bash for ordinary use.
>
> Again, instead of proposing mechanisms, how about implementing them? With
> actual working .debs instead of hastily constructed code fragments?
As I said, it's already implemented. It's called sash. Make it important.
Many people already run it, it's useful, and it works well. The problem
is many people who need it (like me) find out that they need it by
realizing they don't have it when they need it.
> > The truth is I still don't know whether reliability and stability
> > are important issues here, since several people have bluntly told
> > me that live recovery is not what 99% of Debian users need and
> > therefore I should go away.
>
> No: therefore, instead of just using the default install, you should
> recognize that as a member of a minority you have to go out of your way,
> and choose some optional packages.
Why should it be this way? It's catastrophic to me if I don't have it,
and to all the other people running servers like me. It's not any matter
at all to you whether or not the statics are installed. So, why should
we suffer a catastrophic failure in order to save you from a non-existant
cost?
> I wouldn't go so far as to recommend anyone concerned with stability
> and reliability just stick a $5 Debian CD in their computer, and just
> stick with a default installation and hope, though.
Why not? This is what I do with FreeBSD, for example. Why shouldn't
Debian be just as reliable, out of the box?
> That said, I'd be interested in seeing statically linked stuff be more
> obvious and easy to find (and it's worth somewhat better explained,
> perhaps). And honestly, I don't think these changes have to be at the
> expense of the "99%" of Debian users who don't care.
I don't think they're at the expense of 99% of Debian users who don't
care either. I think you could mark sash important and 99% of Debian
users would never really notice.
My preference would be to compile ash static and make that root's
shell rather than sash, because it's a more familiar looking shell
for most people. But anyway.
> Seriously. Show us some implemented .debs that aren't likely to cause
> problems for 99% of people who use Debian, and there shouldn't be any
> problem.
Well, start out by making sash important. It asks whether you want it
to be your root shell or not--say no if you don't. The only modification
required to minimally meet my requirements would be that the sash
question provide a bit more background:
Do your root shell to be sash, the static recovery shell? If
you say yes you will be able to log in as root and fix some
kinds of problems without requiring a reboot; if you say no
sash will still be installed, but your root shell will be set
to bash. [Y, n]
With 'Y' as the default, since that's the safer and more reliable
option, and since it has negligible cost.
That would make me happy. There are a few other things I'd like to
have lying around, but then it would become a question of getting
them into the sash package; and at least 95% of what I need is
provided by sash already.
> > Second, your position is in violation of debian policy.
>
> "Hey, Debian! I know your policy better than you do, and you're all stupid
> and wrong, so nyeah!!!!!"
>
> Please.
Debian policy does in fact state that anything an experienced unix
administrator would expect a unix system to have should be included
in "important", providing it is not large.
Static utils meet that requirement; the position that Debian should
not include them by default is in fact a violation of that policy.
Insulting me is not a response.
> > I think that I have done that. Obviously not the testing part, but we
> > are only in the proposal stage.
>
> Proposals without code are next to worthless.
Sash exists. It needs to be marked important. What's your point?
> > So, exactly what is that core technically meritous argument? I am
> > dying to hear about it. Several people have raised legitimate
> > concerns, and we've gone off to contemplate them and come back
> > with proposals that satisfy those concerns.
>
> (which have probably been lost in the flamage)
No, significant progress has been made. Go look.
> > Step #3: We stop asking the above question, and just install it
> > by default. There would be an optional package that
> > could be installed to revert to the old behavior, for
> > people who liked that better
>
> More likely:
>
> Step #3: We lower the priority of the question in the admintool
> that's finally been developed, and make the default to
> have sash as root's shell. We warn loudly about this in
> the Release Notes. If people uninstall sash, then its
> pre/postrm takes care of ensuring root's shell is /bin/sh.
Sure, sounds good to me.
> > Maybe the problem is that I didn't make this clear enough--I think
> > that a static root shell is extremely important, and will not run
> > Debian as a production server until it's available by default (or
> > someone convinces me why I don't need it).
>
> Why do you need it by default? When you're installing, just go "apt-get
> install sash", and say "yes" when it asks if you want root's shell
> changed.
Because experienced Unix people expect it to be there already, and so
they don't go looking for sash. Secondly, inexperienced Unix people
still need it, but don't even know to go looking for it until they
need it, by which point it's too late. Obviously in both cases I'm
talking about people running servers which cannot be rebooted, either
because of what they're running, or because of where they are.
> In the general case, yeah --- people shouldn't have to create huge
> flamewars in -devel to know about this, and it's nice that you're willing
> to donate your time to help all these people out, but I don't get what
> your personal issue is here: you can set up a server how you like it no
> sweat, at least now that you know how. What's still stopping you?
I am far more conservative than you imagine when it comes to reliable
servers. I won't run an OS as a reliable server until the behavior
on which I rely is considered to be core.
The honest answer as to why it's my personal issue is that I've been
using Linux forever. All my systems used to be Linux systems--back when
I had nothing important to do with them (a long time ago, back when
the easiest way of installing Linux was still to borrow someone else's
harddrive and copy all the files over).
At some point my use of Unix switched from "gee this is fun" to
"gee I need to get my work done", and finally, "gee I need to keep
this server up". I was eventually forced to stop using Linux for
servers because of reliability and maintenance issues. I've always
figured that eventually Linux would catch up in reliability and I
would be able to switch back.
Debian now appears to be getting close, so here I am hammering away
on all the things that, in my view, keep me from using it. RedHat
has the static issues solved, but fails the reliability test in
MANY other ways. Slackware is not even in the game. It's possible
some of the other distributions are doing better but I haven't
really looked into them.
At any rate, obviously the reason why it is my personal issue is
a personal opinion--but you asked :-)
> > ps: Though we ("my side") seem to have decided that "sash" should
> > be the root shell, I personally have some reservations about
> > that and wonder if it shouldn't be "ash" (with sash also provided
> > due to its many builtins and thus economical use of disk space).
> > There would then be no '-c' issue, and less need to have a
> > second UID 0. I am satisfied with having sash as root, though
> > it wouldn't be my personal first choice. A small, static version
> > of bash is another option--if there is such a thing as a small
> > version of bash (I doubt it).
>
> ash isn't statically linked. Do you mean, /bin/ash-static, or
> /sbin/static/ash, or something similar?
Yes, compiling ash as static and using it as /sbin/sh or something.
FreeBSD uses a static as as /bin/sh. Making it /bin/sh would break
far too many scripts with bash-isms on Debian, but ash has proven
to be a good and reliable shell for scripting and administrative
use, and the static version of it is small enough. It's also
proven itself through years of use as /bin/sh on BSD systems,
so I have quite a bit of faith in its reliability.
My gripe with sash is that it does not look even a little bit
like an ordinary Unix shell.
Justin
Reply to: