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..... _______________________________________________ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
