Re: itp: static bins / resolving static debian issues
Hi Marco!
When I say that things like 'su' and, for that matter, 'ls' are
rarely used commands I am primarily thinking about the percentage
of your uptime for which they're running. It's almost negligible, and
therefore so will be the impact of the memory they use.
If you ran 'su' 500 times a day, and each execution took two seconds
(including the amount of time it takes for you to type your password),
then that's 1000 seconds out of an 86400 second day, or just over 1%
of your machines uptime. And running su 500 times a day is pretty
excessive, for most people.
With something like ls, which doesn't wait for input from you, it's even
more lopsided. On my machine 'ls' takes about 0.006s to execute, so you
would have to run it around 14000 times a day just to manage to keep it
loaded 1% of the time. Actually if you were running it that much it
would always be at the top of the LRU cache and it would run much
quicker, so you'd have to use it even more.
It's much more important for a long running process like an interactive
user shell or a getty to be dynamically linked. If those consume more
memory than was necessary then that memory gets used permanently; even
then if the process is idle it'll be swap that's used rather than core.
It's also not as simple as all of this because two copies of the same
static binary WILL share their memory footprint. You only lose versus
dynamic linking when you have two different binaries sharing the
same code.
In short, estimating the actual impact of small, short-run, static
executables versus small, short-run dynamics isn't as simple as
you might think. Statics unix utilities use up a lot less resources
than you might at first think, for reasons like the above.
- -
As for using sash as a root shell: I am not stuck on that. I only
insist that for the static package to be useful, there has to be
a way for root to get a static shell going after a failure. I'll
leave the engineering decision of whether to manage two accounts,
whether to provide a static /bin/ash for root's shell, whether to
use sash, and how much of this should be determined by asking
the user during the install, up to other people.
Several people have raised some definate issues with having two
different root accounts, which are very valid and would need
solutions for this to be the way to go. The alternative is to
give root /sbin/ash or /sbin/sash as a shell and make that static.
So long as I can get nto my static root shell, the requirements I'm
looking to satisfy are met, so there is lots of room for implementation
discussion over that point.
Justin
On Thu, Aug 19, 1999 at 11:16:08AM +0200, Marco d'Itri wrote:
> On Aug 19, Justin Wells <jread@semiotek.com> wrote:
>
> >OK, is there anyone who disagrees with this:
> Me.
>
> > as well as ensuring that you can get to sash as root: su,
> > and sulogin will have to have static versions as well. In fact
> > these are run so rarely I don't see why they can't be static
> > by default--but if people yell, we can have separate static
> I don't even want to look at your packages if you think su is a rarely
> used command.
> And you need many more static commands if you want to login to a broken
> system, at least getty and login too.
>
> > -- root's shell be set to sash by default, if sash is installed
> Very, very bad. Instead add to /etc/passwd something like:
>
> toor:x:0:0:Emergency root account:/root:/bin/sash
>
> If the system uses shadow password the account will have root password.
> If not the admin will change the password, if he cares about sash.
>
> --
> ciao,
> Marco
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Reply to: