On Wed, Mar 14, 2001 at 03:52:56AM +0000, Jacob Meuser wrote:
>
>> >
>> > However, the debian package management is so slick, freebsd's doesn't compare
>(although it is good). To me it's worth it to use debian over any benefits of
>freebsd, just for the packagemanegment.
>
>Debian's apt/dpkg system is truly amazing. Definitely worth checking out to
>see how easy it *could* be. Of course, for the system to work properly, the
>packages are more complex and have to be *more* correct. This could explain
>the sometimes *old* packages in "stable" Debian releases (perl-5.005 in
>"testing"?). IMHO, this is a problem with binary distribtions. (Although
>it IS fast and easy.)
see more below
>By contrast, (Free|Open)BSD uses a "ports" system to add to the system. The
>"ports" system is implemented as a directory tree (usually /usr/ports) which
>contains Makefiles and OS specific patches. The Makefiles contain more than
>compile time info, they also contain dependency info, who maintains the port,
>where the original source can be downloaded, etc. This would seem to be easier
>to maintain than several binary package like mysql-client, mysql-server,
>mysql-doc, libmysql, libmysql-dev, etc.
>That having been said, the BSDs also have the pkg_[add|delete|info] functions
>to install binary packages. In fact, after a port is built, the files are
>archived into a .tgz "package", and installed from that "package".
The ports system is certainly k3w1, and i find it quite useful for installing
stuff, but it has a few shortcomings; on a low-powered machine, builds can
be dreadfully slow (of course, on a low-bandwidth connection, binary package
installation can be dreadfully slow), and interdependencies are not well
handled; if i need foo to build or install bar, then (cd /usr/ports/baz/bar ;
make && make install) gives me foo, but if i need arglebargle to run bar,
then a later (cd /usr/ports/baz/arglebargle ; make uninstall) will not
let me know that i'm about to break bar.
>And Debian also has methods for creating packages from source. It's a bit
>more trouble than with the BSDs, but you can get the relevent Makefiles
>(actually debian/rules) and patches for up-to-date code from the Debian web
>site. It would be nice if Debian had a public CVS interface.
I gather that the apt and dpkg development targets include better support
for downloading and building source packages; we may soon be able to do
apt-get make-world or some similar...if this could be integrated with CVSup
or something like it, that would be especially k3w1.
>What would be really nice, would be a cd with base installers for Debain and
>[Open|Free]BSD, and some of the more common third party source packages.
There is a movement afoot, with some degree of momentum, to spawn a
Debian GNU/FreeBSD port, analogous to the Debian GNU/HURD port; it would
use a FreeBSD kernel with glibc and the Debian package system.
>
>PS What I find interesting about BSD vs Linux is that Linux distros are GPL
>liscensed, which requires availability of the source, but most distros* only
>have the kernel source as an optional package. OTOH BSDs are under the BSD
>liscense scheme, which does NOT require publishing of source, but the BSDs*
>come with source for the entire OS.
>
>*On the first cd.
I've been struck by that as well; is this Open Source or Open Binary? But
to some extent it's more a matter of packaging than anything else. An
interesting experiment might be an installer - perhaps written in perl -
that loaded only a kernel and an interpreter into memory, used a perl-based
compiler to build a C compiler from source, and then built the rest of the
installation from source.
(actually, after reading kt's paper "Reflections on Trusting Trust", i wondered
how one could go about installing an OS that one *knew* was "clean". I
speculated along these lines:
1. Create a ROM image for a system with ROM programming-language interpreters
(maybe BASIC for an older PC, or forth for a Sun) from scratch and flash
it into your starting host
(alternatively, you might be able to audit your existing interpreter and
determine if it's trapdoored somehow)
2. use the interpreter's language to build some primitive development tools
(ed, yacc etc.)
3. use the primitive tools to build some next-generation-up tools
4. recurse this until you have a toolset that can compile an audited OS... )
--
"...the Jedi learned early on what language the universe was programmed
in. Then they took advantage of an accident of language to obscure this
fact from the unwashed. They all affected an inverted lisp.
So, a jedi to be, you the Forth must use." Peter Da Silva in ASR
