Subject: Knock it off. (Was Re: static linking for NetBSD)
To: NetBSD Security Technical Discussion List <tech-security@NetBSD.org>
From: Greywolf <greywolf@starwolf.com>
List: tech-userlevel
Date: 09/15/2003 17:10:04
Thus spake Greg A. Woods ("GAW> ") sometime Today...

GAW> Well, since I do build static-linked systems, and since the resulting
GAW> performance boost is often enough just as significant as the one Jason
GAW> achieved by re-instating an infamous and very poorly designed hack into
GAW> the system, I think you're being very hypocritical.  Do you really
GAW> expect anyone to fall for this?  Do you really think all NetBSD users
GAW> are so naive that you can pull this wool over their eyes?

...whoa, Whoa, WHOA!

CAN we please stop the insultfest?  It's counterproductive to the original
ideals.

Is there ANY WAY we can look at this and say that both sides have merit?

I *still* think making everything dynamically loaded was non-optimal,
/rescue notwithstanding, but that's my opinion, and I've thus far been
given the option of not building my system that way.  Thank you again
for making that possible.

I commented on the mixing of static and dynamic linking because it was
listed as a major hurdle for the PAM stuff.  I didn't *care for* PAM
because it will ultimately be forcing a particular paradigm down my throat
-- I feel it throws down the gauntlet and states that if I wish to proceed
along the path, I must throw away everything to which I have become
accustomed, and I must accept PAM as my saviour, regardless of whether or
not I choose to use it.  That said, please see the words "I feel".  I
am aware that I may be quite misguided; if this is the case, then some
words of reassurance to the contrary of my misguided hunch will be
gratefully accepted.

Other than that I am trying to remain neutral and offer some contributions
for thought in order to get the mortar-set brains of the staunch of each
side to crack loose and at least look at the other side of the coin.
Both sides will benefit from that exercise.

As far as vfork() goes, if we're going to crack THAT old nut again,
while it might appear to be a "hack", it *does* buy significant
improvements on execution in "specific situations" (which happen to
occur rather frequently!).  As well, even if it was a hack for certain
hardware, *to me*, that kind of innovation is the sort of thing which
_can_ lead to great things!

I liked the proposition of the rfork() call, by the way.  We could take
that somewhere, I think.

For what it's worth, to sum up (my opinion):

- vfork was a *cool* hack.

- Performance-wise, I don't perceive a huge gain on dynamic linking vs.
  static linking.  I had a problem with there being a broader point of
  failure in the dynamic libs and the linker.  It still rubs me the wrong
  way.  But I have the option to rebuild The Old Way.  Please don't lose
  that.  In fact, I had to help someone semi-recently with their system
  during an upgrade because it wasn't very forgiving with the wrong
  order/incompletion of the upgrade.  They didn't have /rescue, and they
  got the repeated dreaded "Bad exec format" message with all the new
  binaries.  A reboot caused a "panic: init died" because something went
  wrong.  Nothing totally tragic, mind you, but it was kind of annoying.

- I see pros and cons to BSD Auth and PAM; my issue with PAM is enforced
  dynamic linking of everything to the point that I won't be able to
  rebuild as I need to.

- Policy decisions sometimes need to be made, but it's really a lot nicer
  not to have them forced upon one.

If all I've done with my comments is to incite flame after flame, then
my intentions have been misinterpreted.  I'm no grand hacker, no prodigious
programmer, certainly not on the scale of many of you.  But I'm always
learning, always hungry to see what I can glean from what's happening.

I'd hope that those of you who are so dead-set in your mindset haven't
decided that you know so much that you feel you cannot possibly learn
any more.

				--*greywolf;
--
NetBSD: true inheritors of the UNIX(tm) legacy.