I think you'd be surprised to learn how little RAM we're talking about here. Especially if the statics used old libc rather than glibc (sh, ls and dd certainly don't need to be multi-threaded, and don't require any advanced support from the C library).
First, none of the system install, upgrade, and maintenance commands are an issue at all--you likely never run multiple copies of fdisk, fsck, mke2fs, mknod, restore, ifconfig, route, and so forth. A lot of these you might even drop to single user mode before running (assuming there were multiple people logging into your box, and you wanted them off your box before doing maintenance). Second, all the users logged into your system will likely choose the dynamic /bin/bash as their shell, rather than the small and static /bin/sh (-->/bin/ash) that has been proposed. Third, even if all the common unix commands such as ls, dd, cp, mkdir, rm, kill, sleep, ps, ln, mv, df, and chmod were statically linked, the truth is you just don't run them that often. You might run one of these commands once every minute or so, if you are busily doing shell stuff. 'ls' in particular might get run once every twenty or thirty seconds--but nothing more than that, and it would take a LOT of users on your machine doing this before it would add up to more than 500-600k at any given time. If you actually analyze it, we're talking about very small amounts of memory here, in excange for a large increase in the reliability of the system. Also it's worth mentioning that these core unix tools do not need to be multi-threaded, or take advantages of the latest glibc features. It would probably be OK to link them, statically, against the old libc, which would result in a big reduction in size. But if finally you still somehow insist that you cannot afford the extra 300k of RAM that static linking would cost you, then yes they could be put in /sbin or somewhere like /stand instead, and you could ignore them most of the time... until your system failed. And the package manager could live in /sbin too and not rely on dynamic linking. Justin On Tue, Aug 17, 1999 at 01:24:08PM -0700, Chris Waters wrote: > > Here's a suggestion: what if we make statically linked versions of > some of these basic tools *available*, but *don't* make them > standard. Let people choose for themselves how to manage their > systems, and which risks are worth what costs. > > Personally, I am very much opposed to the idea of making statically > linked versions standard. My motherboard is already at its limit for > RAM -- I can't add any more. So a proposal to make the system use a > lot more RAM *by default* is not something I can support. > > But as an *option*, I think it would be fine. I agree that it may > have advantages in certain cases (cases that don't apply to me at this > point, but still...). > > The only question then becomes, should the statically linked packages > conflict or co-exist with the dynamically linked ones? I think > co-existence is better, but obviously more work. But co-existence > probably increases the chance that the statically linked binaries will > survive a hostile break-in. > > -- > Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the > or [EMAIL PROTECTED] | above, but it is too long to fit into > http://www.dsp.net/xtifr | this .signature file. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
