Cent OS migration

[Brian K. White]

On 5/10/2011 9:36 AM, Jay Ashworth wrote:
> ----- Original Message -----
>> From: "Fairlight"<fairlite at fairlite.com>
>> To: filepro-list at lists.celestial.com
>> Sent: Tuesday, May 10, 2011 5:34:15 AM
>> Subject: Re: Fwd: Cent OS migration
>> This public service announcement was brought to you by Jay Ashworth:
>>> I inadvertantly sent this to NANOG, instead of here, which caused
>>> the
>>> firestorm Brian and Mark will expect it did. :-)
>>
>> Oh $diety. I pity you. :)
>
> It wasn't actually too bad.  And I used it as a riff to prospect there
> to see if anyone had any leads on the Menu* source code.  :-)
>
>>>> *Any* of the BSDs are so much less well supported that they'll
>>>> drive
>>>> you straight up a wall.
>>
>> It's the shallowness of the talent pool on the user/admin side, not a fault
>> of the technical specs or implementation. Technically, FreeBSD is possibly
>> even superior to Linux. But the ones that can admin it worth a damn are
>> hardcore, and generally have better things to do than hold the hands of
>> lusers, at least in their opinions.
>
> Precisely.
>
>> Let's put it this way...the people most likely to successfully -admin-
>> BSD boxes would be equivalent in talent and expertise to linux kernel
>> devs. There are just plain fewer of them.
>
> This was my theory; yes.

Smaller pool of users means smaller pool of tested hardware, less-tested 
hardware that IS tested, smaller pool of tested software combinations 
and less tested software in general.

Just less tested everything.

I have no problem reading and understanding the documentation to run 
freebsd, but the documentation doesn't describe real life a lot. The 
docs describe the intended theory and the actual results a very few 
people got in real life on their particular hardware and their 
particular usage patterns.

Unless you're going to call up the guy who writes the ata driver and ask 
him what hardware he's using and go buy exactly that same hardware, 
right down to the board and firmware revision numbers, you need a 
testing pool larger than the freebsd community to establish what 
hardware and software combinations actually work ok and which have problems.

Otherwise you'll be doing it all the hard way yourself. Every time you 
set up a new box, and every time you try new software or even merely a 
new configuration, you will be finding out if it works well only by 
trying it and hoping. And if it fails, maybe there is something you 
could adjust to make it reliable, or maybe it's a bug you can't work 
around, but you'll never figure it out because that takes numbers you 
physically don't have. You can't do 2000 installs using 2000 slightly 
different choices to find the pattern that oh, certain revisions of this 
motherboard with certain revisions of it's bios cause a problem with 
certain hard drive firmwares only when used in ahci mode...

It's crazy. You can't find things like that except by plain brute force 
massive numbers of testers, or by being one of the few people who could 
actually fix it.

I was on a big freebsd kick for a while and had it running on a bunch of 
boxes and my laptops.. Got tired of fighting to make things work that 
worked automatically in linux, avoiding the landmines of untested 
hardware, fighting to get new software ported and running that was 
written on & for linux, and living without the conveniences of all the 
fancy linux live cd's and the hardware magic in the linux kernel and 
udev. It was a great accomplishment to get the built-in wifi card 
working under freebsd on one of my laptops, It took a full day and it 
proved how smart I was (read that how you will ;), meanwhile it was 
completely automatic under linux. And there was _no_ software at the 
time to make using wireless even slightly convenient, nothing like a 
connection manager that stores wpa keys and remembers access point 
ssid's or mac addresses etc.. but there was several options in linux at 
the same time. After a while I couldn't answer the question when people 
asked why I was running that. I couldn't say it was faster or better in 
any way that mattered.

I had originally thought it might be a better platform to base our 
software-as-a-service on. A more stable and predictable environment that 
would be easier to maintain. A learning curve up front wouldn't matter 
as long as the end result was better. In some ways that's true but the 
lack of others testing things always burns you.

Witness the few people here on the fp list running on Sun and AIX.

Those machines and those OS's certainly cost those people a lot, and 
surely they are more reliable than _any_ linux in and of themselves.

But, simply because hardly anyone else is running filepro on those OS's 
they are plagued with bugs that never get fixed because fp doesn't get 
enough testing and feedback to allow them to identify and fix 
platform-specific bugs. Every problem is an obscure problem that is 
unlikely to get fixed.

-- 
bkw