On Tue, Aug 24, 1999 at 10:16:39AM -0400, Justin Wells wrote:
> 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).
Erm, no, we just don't have libc fail on us in the first place.
This is in much the same way as you don't have both libc and your static
binaries fail at the same time.
Why this is is questionable. Obvious answers are "You're an incompetent
sysadmin" and "We obviously don't do anything with our servers". They're
both probably wrong. It's probably more related to being in the know
when things are likely to break, and not running stuff from unstable on
systems that can't be rebooted/reinstalled.
High availability is a spectrum. Some systems can stay up while you
upgrade your base libraries and all your programs that use them, some
systems can survive /lib being rm'ed, some can survive /bin being rm'ed,
some can survive both. Naturally it gets harder and harder the more
things you want to cope with. It's a tradeoff.
It's weird when you keep saying that Debian does or doesn't cope with
high availability because of this. It may not cope with it *well enough
for you*, and that's something to be fixed if possible, but claiming
that it doesn't cope with it at all when it already does for most of us
is just, well, weird.
> 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.
"their need for them is enormous". Weirdly, most people on this list, who
presumably use Debian fairly heavily, *don't* need them.
> The rest of the population wouldn't notice a difference whether they
> had them or not.
To clarify: we're not talking about statically linked versions of existing
binaries here, we're talking about sash. At least at the moment.
sash is a bit under 300kB. At worst, root can choose to make her life more
painful by setting it as its login shell, but that's optional and asked in
the postinst anyway. And at the very least we seem to have consensus that
it should be at least standard priority if not important.
I'm not convinced that it should default to being root's shell, but I'm
happy to leave that up to the maintainer's judgement.
> > 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.
Oh. Well. That's different.
What happened to having static versions of /bin/su to help get a root
shell, or /usr/bin/ar to help unpack .debs and such?
> It may need
> a few modifications as well, a .deb has already been posted illustrating
> the changes.
URL?
> 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.
Again, you're obsessing over "default" too much. There are lots of good
things that could be done that just aren't suitable for "default" installs.
I quite liked the `backup root' idea. A package that maintains that would
be interesting, IMO.
> 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.
In fact, it'd be a damn sight better for your situation (ie, you could
survive even your entire root partition dying), assuming whoever installs
your systems have enough of a clue (or get told) to install/activate it.
> > > Proposition #3-- Debian should, by default, support servers where
> > > downtime is unacceptable or difficult.
> > > 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."
English has a problem here, in that the "contrary" to your statement
could be either:
Debian will be useless by default in continuous uptime situations
(if you just add a "not"), or:
Debian's default may or may not be useful in continuous uptime
situations.
(if you think of it more as "We'll make <doing such and such as default>
a priority", and adding "not" to that.) I presumed the latter.
(Note also that "Debian should be able to be configured to be useful in
continuous uptime situations" should also be added, and isn't in dispute)
In any case, it doesn't really matter. I'm not trying to prove or disprove
what you're saying, I'm trying to work out what Debian should actually do.
In this case, we ought to make the default install as useful as possible
for high availability type people, without impacting everyone else, and
make it possible, and ideally easy, for people who know they want high
uptime to make the appropriate trade offs and get it.
> The current lack of statics violates the policy you quote above as
> well.
"will support" is a lot different to "will support by default".
> > 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.
Sure. We already go to a lot of effort to support you people: you're the
reason we go through all the angst of stable releases and everything.
Which isn't to say we couldn't do more, naturally.
> > 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.
Sure. The quoted comment of mine is completely irrelevent to making sash
important/standard.
> > > 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.
YM between bash and libreadline, then?
> > > 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.
It's also entirely unlikely that subtle bugs with libraries and essential
programs would make it into the stable release. Seriously.
Sure, dynamically linking all the bins in /sbin/static would be even
less likely, and death-by-meteorite even less, but speculation about
how plausible these things are is just that: speculation. None of them
are at all likely.
Which again doesn't mean we shouldn't do whatever we can to avoid them.
> 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?
A bug in a stable release that causes you to lose libc when upgrading to
in following the Release Notes is in the same realm of probability, yes.
Or at least, that's MHO.
Upgrading to a release classified as unstable, though, means all bets
are off. Which sucks, and static binaries would help here.
> >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.
The bug only hit people upgrading to unstable. And we're very up front
about it being, well, unstable. And likely to die horribly. And maybe
wreck systems. And such like.
> > YM, like: dpkg --force-depends --remove libc6 #?
> [...]--who cares if the C library is busted
> anyway? You can always just fix it, right?
Surreal. This is probably the real explanation for why you've had problems
while most Debian-ites don't. I fear messing with libc greatly.
On the upside, though, I've never actually needed to.
> > 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.
Actually the postinst question would probably make them notice. Whether it'd
make them care or not's another matter...
> 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]
"set to bash" -> "left untouched". It'd probably be polite to also mention
that sash is horribly suckful as an interactive shell when you're not
trying to recover.
> > > 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!!!!!"
> 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.
How many systems have you seen sash on? We've got /bin/sh, just like
everyone else. Sure, it's bash and other people have something different,
sure, it's dynamically linked and other people have it static, but hey,
it's just different. We have all the programs an experienced admin would
expect, they just don't behave in quite the same way.
I'm probably just over-reacting from other instances where people obsess
about what policy says rather than what actually matters. Nevermind.
> > > 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?
Or standard. We have a consensus on this, afaict. What's yours?
> > 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.
So you'd never run a system with duplicate-root.deb (or whatever)
installed?
Why not? I don't get this.
I mean, I could understand being wary of installing random things from
sunsite, say, or poking around in RedHat's contrib directory. Things
that aren't supported, aren't maintained, and have a 50/50 chance of
not fitting in with the rest of your system aren't nice.
But duplicate-root.deb would definitely be maintained, it'd be in use by
a reasonable number of people all of whom have access to the bug tracking
system, and the maintainer would almost certainly be regularly using it
in an environment that's fairly similar to yours and everything.
So why wouldn't you use it, just because some newbie who only uses Linux
so he can write bitter articles about how its spirit's dead now that RH
have IPOed and we'll all go rushing back to Microsoft, doesn't need it
and couldn't cope with it?
> > > 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).
> > 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.
If someone gets around to fixing the "bash overwrites /bin/sh" bug, it'd
be entirely possible to (optionally) have it as /bin/sh.
> FreeBSD uses a static as as /bin/sh. Making it /bin/sh would break
> far too many scripts with bash-isms on Debian,
Bash-isms are already considered bugs, and are even considered release
critical by some (albeit not by He Who Matters [0]). So I wouldn't
consider bashisms to be a major sticking point.
> My gripe with sash is that it does not look even a little bit
> like an ordinary Unix shell.
I actually find myself liking this for the reasons others mentioned.
Having root's shell be painful to use serves me right, the way I see it.
Cheers,
aj
[0] Hrm. dark matters? "Richard Braakman. Debian Release Manager. He who
holds the universe together." Mr Duct-tape. Err. Bygones.
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.
``The thing is: trying to be too generic is EVIL. It's stupid, it
results in slower code, and it results in more bugs.''
-- Linus Torvalds
Attachment:
pgprkdNWvO94K.pgp
Description: PGP signature