|[Home] [Credit Search] [Category Browser] [Staff Roll Call]||The LINUX.COM Article Archive|
|Originally Published: Tuesday, 8 February 2000||Author: Matt Michie|
|Published to: featured_articles/Featured Articles||Page: 1/1 - [Std View]|
Buddying Up to BSD: Part Five - FreeBSD Continued
After last week's review, I have spent the past week getting better acquainted with FreeBSD. Perhaps ironically, every time I jump into a new BSD I immediately install the GNU tools that I've become familiar with. Although I don't feel Linux should always be prefaced with GNU/, this does lend credence to some of Richard Stallman's arguments. Luckily, the FreeBSD ports are well populated with FSF software which makes it easy to mix and match to suit each individual's preferences....
For those who have never experienced the delight of the ports tree, let me briefly explain. In the Linux world to install a program, you either download a binary packaged for your particular distribution or you hunt down and compile source code. Unfortunately, because each Linux distribution is subtly different you can run into weird dependency or compilation problems. Debian works around this problem by putting together its own packages and including a tool to automatically track down and install dependencies for you. Red Hat will also track dependencies, but won't auto-fetch the dependencies like Debian's apt-get. With Slackware, you are mostly expected to sort through all this on your own.
The BSD ports tree is an elegant solution to the problem of installing and compiling Free Software. Instead of distributing packaged binaries, the FreeBSD team maintains a hierarchy of programs sorted into directories. To minimize wasted disk space on unnecessary source code, each program's directory has a Makefile and a patch. To install a program, one changes into the directory, becomes root and does a "make install". At this point, the source code is downloaded, patched, compiled, and installed. This process will also take care of needed dependencies.
Having used most of the various schemes in the Linux world, the only one that comes close to ports is Debian. Red Hat is beginning to catch up with RPM Find, but it still feels clunky and even among RPM-based distributions there are incompatibilities.
Part of the reason the ports tree is such a quality solution is because of the development model inherent in FreeBSD. FreeBSD uses what Eric Raymond calls the Cathedral Style of open source software development where "the overriding objective was for users to see as few bugs as possible, ... you'd only release ... every six months (or less often), and work like a dog on debugging between releases."
Many people came away from reading the Cathedral and the Bazaar thinking that Cathedral development only applied to closed source software, even though many of the large and most popular open source programs have used this method. For my personal machine I prefer the Bazaar release cycles, but for a business or server environment, a strong case could be made for Cathedral releases. Linux distributions targeting this market would do well to use more of this methodology. Because of this, FreeBSD userland and kernel are better integrated versus some of the Linux distributions I've used that have felt thrown together.
Through my limited testing, most of the differences between FreeBSD and Linux were really minimal. I had no trouble getting the average closed source Linux binary to run on my FreeBSD system. The only areas I had to consult documentation on was where to find the system start up files, the different device naming structure, and how to compile the kernel. The man pages were usable, up to date and well written.
It is quite easy to transition between FreeBSD and Linux. I now look at them as regional dialects of the same language. Ultimately, my fondest hope is to see more cross fertilization between our two communities. The FreeBSD license certainly allows code reuse with Linux license, and the Linux community should not hesitate to use it where it is appropriate. It is all too easy to adopt the "Not Invented Here" syndrome.