On Sat, 26 Aug 2006, Peter Jeremy wrote: > IMHO, FreeBSD should move towards a more modular system - a minimal base > with most of the functionality in optional packages (or ports). Removing > uucp, games and perl are steps in this direction. I believe there should be > a very high bar on the import of functionality that is already available in > ports. One of the strongest historical arguments for using *BSD as the base for development of an embedded/appliance-style system has been that this is precisely what FreeBSD is not: by keeping a useful base set of applications in revision control, tested together, and integrated together, we provide an excellent starting point for building network appliances, storage appliances, ISP systems, etc. It's when you start having to deal with big piles of applications that aren't tested together, managed in a single revision control tree, and so on, that maintainability and complexity become problems for these users. I can tell you that if we ripped out BIND, sendmail, and a dozen other highly useful base system components out into ports, I would be using another system, because it is precisely this integration that makes FreeBSD most useful as a starting point :-). This isn't an argument for endless growth (or even significant growth) of the base system, rather, an argument for not abandoning integrated revision control and building of the current system. Sure, we can make the build-time construction of the system modular in a cleaner and more comprehensive way, and provide better binary delivery mechanisms that offer more of the build-time flexibility we already have to the end-user. But an argument to dismember the current system is a non-starter. If I wanted to try to build a complete and integrated system from scratch, without any guarantees that the versions of the components had been tested together, without an integrated build system, etc, I could always use one of a thousand Linux distributions. A self-standing buildworld out of a single CVS checkout is one of our greatest strengths. (I realize that you weren't arguing for that end goal exactly, but I want to make sure that if we embark on the further modularization approach, we do so with an understanding that it needs to be an improvement on what we have, not an elimination of one of our most important features!) Robert N M Watson Computer Laboratory University of CambridgeReceived on Sat Aug 26 2006 - 03:00:04 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:59 UTC