Re: Stop shipping static libraries for NetBSD

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> I object to such a change, because that would make it impossible to
>> build static binaries.

> I guess that begs the question... "So?"

> What is so inherently good about static binaries?

I started to answer this, but, after coming up with a few things, I
realized they're all really aspects of the same thing: they're
simpler.  This has various effects, each of which is good in at least
some environments.  Here are some that occur to me.

- There are fewer things to break accidentally (this is why they're
   used for /rescue).

- There are fewer things to break deliberately - they have a smaller
   security exposure surface.  Every piece of code they don't include
   is one more piece of code they can't be exploited via; consider how
   much paranoia dynamic linkers have to make sure they can't be
   exploited.

- Moving binaries between different systems is more likely to work,
   since they depend on nothing but the user/kernel ABI.

- They usually start faster, in the sense that time from exec to first
   application code execution is lower.

- Their timing behaviour at run time is more predictable (the first
   call to a dynamically linked routine is substantially more expensive
   than subsequent calls).

- There are fewer pieces to integrity-check for something like
   veriexec.

- They don't demand the visibility of generalized support code, code
   providing capabilities you may not want available, eg when chrooted.

Of course, it's not difficult to come up with a similar list of
advantages for dynamic linking, too, but that's not the point; nobody
here is arguing for doing away with support for linking dynamically.
Not even gwoods or me.

/~\ The ASCII                           der Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B