Re: how to make Debian less fragile (long and philosophical)
Anything that is hit frequently will be cached, so you likely won't
take much of an IO hit.
I just don't think shell scripts call mv, ln, cp, rm[dir], and cat
all that often. What I mean by that is not that they don't use it
extensively, or that they aren't extremely important, but that if
you instrumented your system you wouldn't find it was a big deal.
My main reason for believing this is that I have a bunch of *BSD
systems that have cron jobs running all kinds of shell scripts
every minute or two, everything in /bin is statically linked, and
I have never noticed even the least impact on my system as a
result of it.
It's true that BSD systems have much smaller binaries than Linux
systems do. However that's mostly because of the choice of libc.
If the static binaries were ONLY available as statics, you could
compile them with the old libc and they would be reasonably small.
This wouldn't require having extra packages and stuff, since these
would be the only copies.
If you are going to have static and non-static versions of them, then
it doesn't much matter if the rarely used static versions in /sbin
are big or not, so you could just compile them with glibc and not
care about the extra space.
Justin
On Tue, Aug 17, 1999 at 06:11:57PM -0400, Daniel Burrows wrote:
> On Tue, Aug 17, 1999 at 05:41:44PM -0400, Justin Wells was heard to say:
> >
> > I dispute that statically linked binaries impose a large overhead for
> > shell scripts.
> >
> > The ash shell that has been proposed for /bin/sh has echo and test
> > built in for efficiency. Most of the other commands a shell runs
> > are also builtins: cd, eval, exec, exit, export, for, while, do,
> > pwd, read, set, shift, trap, case, and wait.
>
> I'm more concerned about mv, ln, cp, rm[dir], and cat for starters..tar, ar,
> and gzip might be problematic as well. (I didn't realize test was a builtin in
> ash, that helps a lot) Assuming that these are used fairly often in shell
> scripts, you're going to either take a memory hit for having all those images
> loaded or have to perform extra I/O. A quick grep of lastcomm shows that while
> these aren't called on a regular basis on my machine, they're often called in
> quick succession within seconds or less of one another. Currently this isn't
> too much of a problem; depending on how much static binaries are bloated it
> might very well be (I already am chronically short on memory and I don't want to
> waste any gratuitously, and yes RAM is cheap and no I can't afford it even if my
> motherboard took more than an additional 16MB).
>
> That's not to say that it isn't a good idea, but *please* make it an optional
> package or put the binaries in a location where they won't be used for
> normal tasks.
>
> Daniel
>
> --
> Believe in the Great God Om or be stricken with thunderbolts?
> Is that the way it always has to be?
>
> -- Terry Pratchett, _Small Gods_
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Reply to: