On Fri, Aug 20, 1999 at 02:46:07PM -0400, Justin Wells wrote: > On Fri, Aug 20, 1999 at 07:34:06AM -0400, Michael Stone wrote: > > Open getty. Open network connection. Change root's shell to sash. (The > > latter is a local configuration issue--some people might not want remote > > root logins, others might not want sash as their shell.) > > OK, if roots shell gets switched to sash then yes, this works. I thought > you were opposed to that, hence my comment above. I guess just a > misunderstanding here. Nope. I've never been opposed to a local admin making /bin/sash his default root shell--that's the way I do things here. But that's another local configuration issue and shouldn't be a general default. > > Except that you still haven't answered the question of what the current > > toolkit prevents you from doing, other than arguing issues of personal > > preference. That's why I call you a troll. (Because you refuse to answer > > a basic technical question and instead cloud the issue with unrelated > > discussions.) > > OK, I've posted this before, but here is what you can do with static > binaries that you cannot do without them: And I've answered them all before. You just don't like the answers and insist that debian make a rather unique set of requirements the default for all users. If this was the justinwellsian distribution it would make sense to tailor things to your needs. But it isn't... > -- recover from an administrator error, such as someone mis-using > dpkg or "rm -rf *" in a way that leaves the dynamics broken, and > doing so without disturbing your clients who are connecting to > servers on your box (servers are linked and loaded already) And I said to squirrel a backup root partition on a seperate disk. You've already argued that a couple of dozen megs are negligable, so the space is well worth protection against library corruption, user error, hardware failure, etc. How do your static bins help if your hard disk dies completely? The backup root'll still be there... Your solution solves a _strict subset_ of the problems that a redundant solution will solve, and the only argument you've provided against it is the (false) argument that you need to reboot and the (personal problem) that you prefer static binaries. If you want a package of optional static binaries and you can convince someone to do the work, fine--I don't care. But until you can demonstrate how you _can't_ recover without that package, don't expect a lot of support for making it the default. > -- recover from a bug in dpkg or apt that results in broken dynamics, [snip further useless detail] The above fix works for this, as well. > -- keep a system limping longer if / and /usr goes away (I > have actually done this) providing a few bins are in the > disk cache. I kept a system live for about 30min once, > after the IDE cable fell out. Dynamics fail. The fact that a fluke once helped you out is irrelevant in trying to come up with a solid, well-balanced distribution. If I told you that I once had a system with dynamic libs that worked for a little while after it burst into flames would you consider that a good reason to use dynamic libraries? > -- fix a system for someone who isn't as aware of these issues as > i am, and didn't know to install sash Uh huh. The inexperienced beginner is going to whip out his static binaries, wave his magic wand, and fix a system that he doesn't understand in the first place. Pull the other one... > -- someone can fix a system after it fails, if they never knew about > sash and never thought about statics or live recovery, because it [snip] So the person never gave a thought to reliability, didn't take the time to set up a redundant environment (that backup root's still going to do wonders here) and is running a server that _can't possibly be rebooted_? > -- bring a failed system down gracefully after a failure, closing down > daemons by sending them kill signals, and umounting drives > manually if necessary (remember the shutdown is going to fail > since it is reliant on dynamics) sash does all that. Mike Stone
Attachment:
pgp1Fi_XlQiHW.pgp
Description: PGP signature