[mythtv-users] Most stable compatible Linux distribution

[Jarod Wilson]

On Dec 27, 2010, at 7:15 PM, Jean-Yves Avenard wrote:

> On Tuesday, 28 December 2010, Jarod Wilson <jarod at wilsonet.com> wrote:
>> 
>> Latest software support is much more of an issue than latest hardware
>> support. Red Hat adds new hardware support every 6 months or so. Granted,
>> you may have to wait 5+ months if you go with brand new shiny hardware,
>> but for example, I'm not aware of any mainstream x86 hardware that isn't
>> at all supported by the kernel in the soon-to-be-released RHEL5.6 update.
>> Its been run on all the latest and greatest Intel and AMD processors and
>> chipsets, anyway (including some that aren't yet released). Less common
>> hardware, and/or things that were never supported on RHEL5 (like lirc and
>> a myriad of v4l/dvb devices) are another story, of course... But there's
>> work underway to get the v4l/dvb/rc media_build stuff working as far back
>> as 2.6.18 again to remedy that. Note that RHEL6 has most of the v4l/dvb
>> drivers enabled though, unlike RHEL5, and someone (we won't name names) is
>> working on a current latest upstream backport patchset for RHEL6
> 
> All those years I had been running CentOS4 then 5.
> 
> Not once did my dvb-t card nor audio worked out of the box. I always
> had to play with repositories or compiling from source.

RHEL4 and RHEL5 never had the full v4l/dvb stack enabled, the story is
different with RHEL6.


> It also
> usually required to manually compile the realtek network drivers as
> the kernel kept thinking it was another chip

Hm, did you by chance file a bug report I could point someone at? :)


> Until one day I was fed
> up booted ubuntu and everything worked, and that was in the liveCD!

Hardly surprising that a newer distro with a newer kernel worked better
than an older one... You'd find the same with a Fedora live CD. Or even
with a RHEL6 CD, I'd imagine.


> I still have my centos partition on my backend(centos 5), I rebooted
> on centos last week, upgraded everything, and sure enough no audio and
> no network, once again I had to blacklist the realtek module.

Definitely want to see a bug report on that then, and I'll see that
someone remedies that. Granted, we *are* talking Realtek here, and
they tend to make fairly low-end stuff, which quite honestly, gets
a lot less priority/attention/testing than stuff like e1000, tg3,
bnx2, etc., which are far more common on server platforms, and for
which Red Hat has direct and cooperative relationships with hardware
vendors.


> CentOS/RHEL may receive better support in the long run, but my direct
> experience is that as a user you're on for a long struggle to get
> things going.

Your experience is quite different from mine, but then, the bulk of the
hardware that I run on anymore comes from hardware partners, and we
make absolutely sure those work. Now that I think about it though, I do
have one box where the onboard SATA doesn't work worth a damn with RHEL5,
spewing all sorts of junk about exception errors, iirc. Its a fairly
cheap motherboard though, with a relatively crappy chipset. And I don't
think I've filed a bug report myself on that one, since it works just
fine with newer kernels... :)


> And since I've played with the debian way of packaging things, no way
> I could go back , it is sooooo much better.

My only real experience with debian style packaging was with some 'make
dpkg' target in the kernel, iirc, which was ugly, since I swear all it
did was bundle up locally built bits. You could have a patched kernel,
and no way to know, and no way to reproduce it. But I don't know that
it is the norm (I really hope not).


> And when I install a
> kernel update, I *never* have to install a new package for alsa, v4l
> or nvidia (or any modules for that matter). Dpkg automatically rebuild
> all custom kernel modules.

RPM Fusion has that too -- akmods.


> Sure with atrpms, there are ways to have it install kernel modules
> packages automatically, but more often than not I found that a
> particular version didn't exist for the new kernel.

Axel mentioned he was going to do some sort of dkms-alike thing for
ATrpms, not sure if that has materialized. But it certainly has for
RPM Fusion, and I make good use of it.

Of course, I should point out that with RHEL, if your driver is using
only whitelisted kernel symbols, you *never* actually need to rebuild
the driver, a driver built w/the GA kernel should work with any newer
RHEL kernel as well (assuming within the same major release stream).

-- 
Jarod Wilson
jarod at wilsonet.com