On Tue, Aug 24, 1999 at 03:48:50AM -0400, Justin Wells wrote:
> On Mon, Aug 23, 1999 at 10:51:07PM -0500, Steve Greenland wrote:
> > No, Craig continues to point out that statements like "Such-and-so is
> > required to use Debian as a stable server system" are opinions, not
> > technical arguments, without technical merit.
> It is certainly not just an opinion.
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.
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.
> 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.
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.
(Or, at least, you could if you were a developer. Seeing as you're not,
at least afaik, you still have a few options. At the very least you can
make the .deb's and publish the source and binaries on your homepage.
You can also probably get someone to sponsor you to get them into Debian
properly, until you are a developer. Alternatively, if you're not willing
to back up your ideas with some work, you might have some success by
bribin^H^H^H^H^H^Hhiring a developer to do the work, a la the Free Software
Bazaar, or CoSource, or whatever.)
In any case, once you've got working .deb's which can be installed and
removed and handle root's shell appropriately, you can say "Hi. This
.deb is really cool. It should work happily for everyone (and there's
a whole bunch of users who've already tried it from my homepage) -- it
doesn't get in your way, except when you want it to, if you don't want
it at all you can remove it, and while some of the things it does may
not work on Solaris, it definitely works on Debian, I've even checked
the source of all the other packages that are concerned."
> but restating it here this way will contrast it with the nonsense
> above that claims I haven't done more than state my opinions.
Erm. No one claimed that (at least, not that I've read, and certainly
not what you quoted above). There's a big difference between "Your keep
presenting such-n-such as fact, when it's really just an opinion" and
"You never present any facts".
> You
> may find that you want to agree or disagree with some points, and
> we may debate them--but for so long as I am able to defend them,
> you cannot claim that I am just stating my opinion.
"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."
> 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.
Please remember that you're not the only Debian user, nor the only type
of Debian user.
In particular, doing things "by default" is a lot more likely to be
detrimental to everyone else than allowing them to be done optionally.
> 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?
> 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.
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.
> 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?
YM, like: dpkg --force-depends --remove libc6 #?
You really think someone can type that by accident?
But yes, you can wreck a Debian system.
> Proposition #11-- Static Recovery binaries do not use a lot of
> system resources, such as memory, disk, or CPU
>
> Proof: Recovery programs are not run very often, and therefore
> have negligable impact on CPU or memory overall.
>
> Proof: Recovery programs are relatively small (~300k), and for
> example both the memory and disk footprint for sash
> is less than bash
>
> Proof: Very few recovery programs are required, given that so
> many commands are built in to sash, so they don't
> add up to much disk space
And the traditional way to do this, btw, is to make the package, and
run "du" over it, or similar. Why are you hand waving when you can write
a program and give definite, reproducable, facts?
> 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?
> 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.
Stability and reliablity are important to Debian.
At the very least, stability and reliability are important to *me*.
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.
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.
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.
> 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.
> 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.
Seriously.
It's too easy for a discussion to degenerate into "I'm right, you're
wrong" "No you're not! I'm right, and you're mother was an echidna!". At
the very worst, "Here. This code does what I want." "No, it doesn't. In
this case it fails." is more likely to lead to a productive "Oh, so it
does, here's a patch. It works now."
> 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)
> I am certainly open to doing that again, and iterating through this
> process for a year if necessary, until everyones legitimate concerns
> are dealt with.
(Dear MFFG, please don't let this thread last that long.)
> We will either show that the described shortcoming is not in fact
> a shortcoming at all, or else go away and work out a resolution. By
> doing this many times already in this discussion, we've moved
> forward significantly, and now have a much stronger and better
> proposal than what we started with.
FWIW, I do agree with this. I'm not convinced that what you've currently
got is good enough, but then, I'm not entirely sure what "what you've
currently got" is.
> 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.
> 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.
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?
> 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?
Anyway. I for one would like to see a .debmuch more than I'd like to
see this debate continue.
Should I be feeling lucky, punk?
Cheers,
aj
--
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:
pgpCuVbqJRu7Y.pgp
Description: PGP signature