CLARITY re: challenge: end of life for 6.2 is premature withbuggy 6.3

[Marian Hettwer]

Hi there,

some thoughts to your problem in regards to Debian administration time
needed vs. FreeBSD administration time needed.
I believe I can make a point there, since I have 600 debian boxes under my
hood but still am a FreeBSD advocate ;-)


On Wed, 11 Jun 2008 12:53:02 +0300, Anton - Valqk <lists at lozenetz.org>
wrote:
> 
> My main drama with FreeBSD is that ports don't have -SECURITY patches,
> and if I there is a bug in php
> I have to rerbuild and populate the latest version.
Thats unfortunatly true.
But there is a way around. As soon as you have several FreeBSD boxes, I'd
advise you to install your own FreeBSD box for packages building.
So if you need to update your php installations, go to your build box
(which has the very same versions of programs installed as your production
boxes), update your ports tree and do a "make package" of your new php
port.
If the new php package works fine on your build box, roll it out via
"pkg_add -r $NEWPHPTHINGY" and off you go.

> Another _very important_ thing is that there is no binary support to
> packages that has vulns,
> and you have to rebuild them from ports.
>
Well, its one time doing a make package...
Even debian has no plus point there (at least in our environment at work).
We pretty much always need our Apache 2 custom build, not the way the
Debian projects build it. Thus we have a Debian build box around and build
our own Apache 2.2 package.
This is, indeed, the same amount of effort you would have when using
FreeBSD.
IMO the overhead in Debian to build a package is higher than in FreeBSD,
but YMMV.
 
> Just a simple example:
> I have 4-5 fbsd machines and about 15-20 debian stable machines.
> To administer fbsd machines when there are ports bugs(bugs in ports I
> use) it takes me at
> least about 4times more time than update _all_ debian machines...
depends on the way you go.
Genereally speaking, you really really want a build and test machine before
you deploy a security update or even a new version of your software (in
this case: php).
Even with Debian boxes you really shouldn't just "apt-get upgrade &&
apt-get update" but test before!

> Well...I have other things to do too, too many... now guess what I will
> choose?
> I'll use debian, and that's not because I don't have will to use
> freebsd, it's simply because I do my tasks 4 times slower than when I
> choose debian.
hhmm... I really can't agree on that statement.
If you do your admin work in a clean and sane way, most of the time spend
for updating boxes is spent on testing the change before upgrading. The
difference between a "debuild" for building a new package, and then apt-get
upgrade / update them on your box vs. "make package" and pkg_add -r them on
your box is really slim...

> Someone will say "FreeBSD is not for you, then back off". That's not the
I wouldn't say that :)

> 
> Once I've told that there is no binary support (but I didn't expressed
> myself correctly). There is no ports VULNS binary support.
> If there is (and I've never heard of it), I'll be very happy someone to
> point me out this, because I'll continue running fbsd.
>
If you take a close look onto how the debian project is backporting
security fixes you would probably agree that pretty often it's more
desireable to jump to a newer version of that software than instead just
security fixing it.
Examples needed?
MySQL 4.1.11 was the "stable" MySQL 4.1 in Debian Sarge. Of course it got
security fixed, but not bugfixed. You get a secure version of MySQL 4.1 in
Debian but not a stable one, because important bugfixes are missing.
I'd rather upgrade to the latest MySQL 4.1.xx instead.
And of course, do your testing before jumping version numbers.
 
I hope that my impressions will help you in working with FreeBSD in a
server environment.

Cheerio,
Marian