Why Are You Using FreeBSD?

[Damien Fleuriot]

On 5/31/12 5:13 PM, Jim Ohlstein wrote:
> On 5/31/12 10:22 AM, Damien Fleuriot wrote:
>> On 5/31/12 4:01 PM, Jim Ohlstein wrote:
>>> To add others, in no particular order:
>>>
>>> Ease of upgrade. While some have noted that binary upgrades are easier
>>> on Debian, it's far and away superior, IMMHO, to have a locally compiled
>>> system. Many Linux distros have no upgrade path short of a wipe and
>>> re-install.
>>>
>>
>> Far superior, check, FAR MORE TIME CONSUMING, check as well !
> 
> No need to yell. Good things take time. That's life. The thing that
> takes the most time is building world. My boxes stay online during that
> time, and I am usually doing other things, so who cares if it takes an
> hour or so? I only take the system offline after I've installed the new
> kernel. I boot into single user mode, install world and reboot. Cleaning
> up configuration files takes a few minutes, then I'm good to go.
> 
> While I do rebuild all ports, I have only had *one* occasion where a
> binary built on an older system croaked on a new kernel. I have about
> 500 ports installed so maybe that's not that many.
> 
> I upgrade my systems once or twice a year. It's not really a lot of time
> for me.
> 

We upgrade them when vulnerabilities and bug fixes show up, which is
certainly more than 2/year.



> Linux distros all certainly require a reboot for a new kernel and some
> likely require editing of config files. So where is the "far more time
> consuming"? In the compiling? Sorry, but I'm not one to sit and watch
> the lines go by on the terminal. I have better things to do and I do
> them. If the compilation hits a snag I'd find out why, fix it, and run
> it again.
> 

You missed the bit about 3 reboots, while these don't take 15 mins each,
they're still time consuming and disruptive.
1/ reboot after installing new kernel
2/ reboot after installing new world
3/ reboot after rebuilding ports


Either you don't have that many fbsd boxes to manage, or you're doing it
much better than we are.



Let me lay it out for you:
We use these boxes as firewalls for our company's projects.
Between dev, pre-production, QA and production environments we have
roughly 40 of these.

They rarely share the same installed ports, nor the same hardware and
thus kernel files.

Furthermore, when upgrading the CARP Master firewall, we need to plan
with the Project Manager a failover to the CARP Backup firewall.
Yes, I know about pfsync, yes, we use it, no, it doesn't *instantly*
sync sessions for PF.

This, is actually quite a pain as well because the Project Managers are
loath to swap between firewalls, and we need to do it nightly.



These factors + source upgrade = major pain