Pkg-based base system.
Chuck Swiger
cswiger at mac.com
Wed Mar 17 08:59:34 PST 2004
Scott Long wrote:
> Colin Percival wrote:
>> Nor, I think, do many users want a kernel with interchangeable
>> userland pieces. What I hear from many users, however, is that
>> they would like an operating system with optional pieces -- so
>> that they could sysinstall FreeBSD without sendmail, named, or
>> doscmd (to take a random example).
>
> The trick here is to know when you start sliding too far down the
> slope. It's hard to argue about sendmail, named, gcc, etc, but where do
> you stop?
Can I suggest a better method for answering this question, even if I don't
have a strong opinion as the subject? :-)
The process you've suggested above is akin to one possible method for
performing common-subexpression elimination optimization-- it's known as
computing the fixed-point of expressions used. You start with all of the
expressions computed by a piece of code, and you try one by one to remove each
expression and see whether by doing so you cause the program to be unable to
compute an expression the program "needs". In the case of a program, "needs"
means ["expression value gets stored to memory", "expression is the return
value of a function"]. You repeat computing the fixed point by removing
expressions until the set of expressions left no longer changes in size, and
then you stop.
It's a lot of work, and the process of figuring out whether an expression is
needed is hard to do: your question above, asking how does one determine when
to stop removing components of FreeBSD, is also hard to answer, especially so
when people do not agree as to what "needs" to be part of FreeBSD.
However, there's another approach to doing CSE via fixed points. You start
with the null set, and you add expressions (or FreeBSD components) that you
decide you need, and then you iterate by adding any expressions/components
required by the components in the set until you've got everything the system
"needs" and all of their dependencies, at which point you stop.
This approach tends to be a lot easier (because it's almost always easier to
answer "what do I depend on?" than to answer "what depends on me?") and it
tends to stop at smaller-- more optimized-- set of components (because you
only add components you know you need, rather than usually not being able to
remove components you're not sure you do not need). (*)
If one can answer the questions above perfectly, then the two approaches to
computing the fixed point of required components will iterate to the same
result. However, it's much more common that one cannot answer the questions
perfectly, and often the former approach will stop with a much larger set of
stuff than the latter approach, which is probably why the tactic of setting
NO_FOO=yes in /etc/make.conf for everything still gives one a much larger
system than PicoBSD or NanoBSD, where I bet someone started with "nothing" and
added components until they got a minimal system capable of serving as a
router/bridge/firewall/etc.
For me, it's interesting to consider what "needs" to be in FreeBSD as ["things
required to boot into single user mode and fix problems", "programs in
userland which need to be recompiled if the kernel options or internal
structures change"]...
--
-Chuck
(*): One additional detail to note is that fixed points are only guaranteed to
converge if the process you use is unidirectional; that is, if you start with
everything and remove pieces, you *must* continue removing pieces until you
stop: one cannot add something in the middle of the process.
I suspect that the issue of whether Perl should be in the base system
constituted a case where some people were adding things which depended on Perl
while other people were working to seperate Perl from the base system; the
system simply won't converge to a stable condition that way.
More information about the freebsd-current
mailing list