Date: Wed, 17 Mar 2004 11:57:16 -0500 From: Chuck Swiger <cswiger@mac.com> To: freebsd-current@freebsd.org Subject: Re: Pkg-based base system. Message-ID: <4058836C.7070801@mac.com> In-Reply-To: <4057F887.1010709@freebsd.org> References: <20040315134745.1eb201f4.manlix@demonized.net> <20040315125710.GK797@camelot.theinternet.com.au> <20040315140153.30348b1e.manlix@demonized.net> <nt1xntb68t.xnt@mail.comcast.net> <4057D767.2090107@freebsd.org> <6.0.1.1.1.20040317065013.03b765a0@imap.sfu.ca> <4057F887.1010709@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4058836C.7070801>