Re: Sets, subsets, syspkgs, and MK*

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Thu, 17 Dec 2009 00:42:09 +0900
    From:        Masao Uebayashi <uebayasi%tombi.co.jp@localhost>
    Message-ID:  <20091216154209.GE19136%x300.tombi.co.jp@localhost>

  | There's a big difference between:
  | - Who want to build different releases (e.g. different compiler 
optimisation)
  | - Who want to use partial functionality (no YP, no KERBEROS, ...)

I'm not sure the difference is all that big...   But yes, you can
characterise those differently,

  | You're most paranoia. :)

paranoid - yes...

  | I'm not familar with such security techniques.  I thought binary updates
  | (binary patches or partial binary updates == syspkgs) helped in security
  | context too.

They both help, in different ways.   My technique is useless against
someone attacking me, it only protects against me being collateral
damage in a general attack on everyone.   Binary patches can make it
quicker for people to be able to install security fixes, but only after
the patch is releases, which in many cases means only after someone has
already been attacked (sometimes bugs are found by audits, other times
they're found when they're exploited).  That is, both help, differently,
Which is better for any particular user will vary (I can keep a full
set of .o files around, so a source patch and relink is really very fast,
and the cross-build setup means that it can be fast, even for the slowest
target architectures.)

  | I think YP is worth being a module, because it's context is limited compared
  | to printf(3), malloc(3), ...

Unlike printf(), malloc() etc, I think YP is worth being trashed.
Its usefulness is zero, which really is limited.  But never mind...

  | libc locale already uses dynamic modules.

Sure, that's a good starting point (doesn't nss do that too?)

As i said in my previous reply to you later message, make a simple
clean proposal for a single, simple change, and don't confuse the issue
by trying to over produce the case, or add in too many other peripheral
changes.   Then move one step at a time.

kre