Re: Pkg-based base system.

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.