DragonFly BSD
DragonFly kernel List (threaded) for 2003-07
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Remove BIND, Sendmail, Perl and etc from base?


From: Richard Coleman <richardcoleman@xxxxxxxxxxxxxx>
Date: Thu, 24 Jul 2003 23:33:03 -0400

Chris Pressey wrote:

My argument would be something like:

- The 'base' should be the set of packages required to build and run the
OS, period.  If you want to do anything more than that, just bite the
bullet and install more packages.
- From a security standpoint, the fewer languages installed, the better;
and from a correctness standpoint, the fewer of those that can send
themselves into an infinite loop (i.e. Turing-complete,) the better.
- You certainly don't need floating point variables and closures to
install software and add users to the system.
- Taking a powerful scripting language and crippling it would only
result in a crippled scripting language.  We already have that - it's
called 'sh'.
- If you consider gcc+sh+make to be too cryptic and/or not flexible
enough to develop in directly, use them as back-end languages: write
Perlthonbycl scripts that write gcc/sh/make files, and include only
those files in the 'base'.  They won't (directly) depend on the
Perlthonbycl scripts, and won't require that the end user have
Perlthonbycl installed on their system.
- This approach avoids altogether the otherwise-inevitable religious war
over which language to bless - thus alienating the fewest people.

We basically have an "embarrassment of riches" here. There are so many good scripting languages, you can never get anyone to agree on which one to use. So, we all end up with them all on our systems (cvsup needs Modula2/3, portupgrade needs ruby, lots of ports need Perl or Python). Disk space is cheap these days, so it doesn't really hurt anything.


Maybe the Linux guys have it right ... just use bash. I doubt this would ever happen on the BSD system, but at least I understand a little better why several projects have settled on it.

Richard Coleman




[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]