Debian flamewar

[Jason Stephenson]

Heh..... I find this discussion mildly interesting from where I sit, a 
mostly xBSD user.

It's funny, too, 'cause I didn't start using FreeBSD for my workstations 
and personal servers until I worked in a data center environment with 
mixed UNIX systems. At the University of Kentucky's College of 
Engineering Computing Center, we had multiple systems running HP-UX, 
Solaris, IRIX, Red Hat GNU/Linux, Debian GNU/Linux, FreeBSD, and even 1 
web server with OpenBSD for a certain network/clustering research group 
that some on this list have probably heard of. Also, the two of us in 
the "UNIX Support Group" were responsible for several dozen other UNIX 
and Linux workstations spread throughout the college and not just the 
servers in the back room.

It was largely the issues of "package management" that made me decide to 
go with FreeBSD and OpenBSD for my computers at home, instead of various 
flavors of GNU/Linux. I found the ports collections to be the solution 
to deb and rpm hells. In almost every case, I cd into the program's 
ports directory, type 'make install' and the software builds, installs, 
and then runs with no hitches. There's very little to package manage and 
that's how it should be, IMHO.

I experienced all kinds of problems on the Linux machines, mainly 
because we were a research institution and the profs would need some 
bizarre hardware combination that wouldn't quite work with the default 
packages from the various releases. It became a nightmare trying to 
maintain a machine loading packages from 2 different Debian releases, or 
trying to install binary RPMs on some of the RedHat machines with 
different kernels, etc.

It soon became routine for my colleague and I to install nearly 
everything from source code on certain machines because we knew that the 
packages would not work.

I have found that installing from source, and knowing what different gcc 
and make errors mean, is the only way to get software that will run on 
your machine 100% with no faults other than their own bugs or bugs in 
the libraries they link to. It can be time consuming to maintain a 
machine with source-compiled binaries, but I haven't found any update 
routine that's simpler or more sure-fire than:

cvsup -g -L2 /home/root/sup/FreeBSD-ports-supfile
pkg-delete -a

cd /usr/ports/[pkg-cat]/[pkg-name]
make install clean

The last two lines need to be repeated for each package you wish to install.

I can't count the number of times I've had

apt-get update
apt-get install

fail and for what reasons when.

I've also dealt with RPM-hell of having to install RPM after RPM, just 
to get the one thing that I want to use installed. I've also had 
installs fail on some machine, again because of custom packages needed 
for one reason or another.

I can tell you that I've only ever had two package fail make install in 
FreeBSD ports because one time I updated right after a change to one 
package, and the second time because the package maintainer had written 
his makefile to check for the headers from a specific version of the 
mysql libs and I'd installed a more recent one. In both cases, the fixes 
were simple changes to the makefile that I sent off to the package 
maintainers. One was incorporated into the makefile, and the other 
maintainer wrote back thanking me, but that he'd already updated the 
repository with a "better" change.

I've not ever had a problem with ports on OpenBSD, but I've used it much 
less.

Oh, and don't get me started on the "package management" in IRIX, HP-UX, 
and Solaris. They have varying degrees of success and failure, and you 
often have to go to third party sources on the Internet or resort to 
installing things from source for the useful stuff.

Anyway, to me, it isn't software without source code, and I do prefer to 
install from source because then you know it works with the libraries 
installed on your system because it was compiled against those very 
libraries. You don't need to worry about binary compatibility issues 
between different library and kernel versions busting your binary 
packages. Yeah, you could end up with something that doesn't compile, 
but at least then, you can see what the problem is and fix it yourself.

Well, gee, that was longer than I anticipated.....