UMTS to the rescue, Red Hat only seconds behind

Submitted by dag on Tue, 2008/12/30 - 12:50

When I installed CentOS 5.2 on my Thinkpad X200s only to discover that neither my onboard ethernet (e1000e), nor my onboard wireless (iwlagn) was supported by CentOS 5.2's 2.6.18 kernel, I managed to manually configure my Bluetooth UMTS connection to my cellphone to fix my connectivity problems and get back in business in no time.

Funny how the newest technology (UMTS) apparently is better supported by older kernels than ethernet or wireless (ieee 802.11) technologies.

I was also pleasantly surprised that the newer RHEL 5.3 Beta kernels (also 2.6.18) had no issues with those very recent e1000e and iwlagn drivers. Red Hat spent the effort to backport those drivers from 2.6.25+ kernels to a 2-year old kernel they will support for the next 5 years ! Only tens of seconds and a reboot later I was running the newer kernel (2.6.18-128.el5).

When I wrote my Ubuntu's need to catch a wave article, this was exactly what I had in mind. Red Hat actively backports functionality and drivers to stable kernels. They have done this the past 6 years in increasing volumes. And that is a huge effort which requires considerable resources, resources that Canonical simply does not employ (yet) and has not proven to be capable of doing for Ubuntu LTS. As an Ubuntu LTS user with newer hardware, you are forced to use a bleeding-edge Ubuntu release and upgrade every 6 months until the next LTS release that works. So Mark does have the advantage if the Enterprise kernels and software stacks would be aligned between distributions.

And this also proofs that Red Hat is very much interested in the Linux desktop, despite what is often stated to the contrary. The iwlagn driver is not something you find in datacenters, still the whole shiny mac80211 infrastructure was backported to support this device (together with a whole bunch of others) to the 2 year old kernel.

Even though Red Hat is not targeting the consumer desktop market with RHEL directly (a good way to burn through your money quickly!), they are focusing on the Enterprise desktop and Enterprise workstation functionality, and that is where those drivers come into play. A very recent Gnome may not be that important to businesses (hey, I manage to do fine with Gnome 2.16 for my day to day work) but not being able to run RHEL5 on current Enterprise hardware is a very big concern.

So yes, Red Hat has its own motives for Linux on the (Enterprise) desktop and CentOS users benefit from that equally. CentOS 5.3 will have a whole slew of newly supported hardware together with the trusted and stable environment you are already using: Thanks to RHEL 5.3 and Red Hat's effort!

A happy new year, indeed :-D


that's lovely machine you bought... i can't help but wish...

I'm a new CentOS user that shared your sentiments about Thinkpads... finally plucked the courage to get one (pre-loved T41) to run and learn Nux from (I'm a visual arts guy and have been on Mac since the dawn of my life)

Networking's a pain (I'm still wading through getting the wireless to work) but oh well.

Please share your pain on the

Please share your pain on the CentOS mailinglist, or on the CentOS forums. I am sure there are people with a good medicine.

And since you couldn't find it using Google/CentOS wiki, this is something we could then also add to the CentOS wiki for others to enjoy.

On the other hand... I've

On the other hand... I've always been wondering why you get wpa_supplicant and a lot of other completely useless tools (bluetooth, anyone?) in a default RHEL 5 server installation.

And indeed, you should not use default installations, but a lot of people seem to forget...

I think that the reason for

I think that the reason for this is that Enterprises usually don't install systems manually and therefor are not installing services they don't need in the first place. I know all the companies I did consultancy for already had the policy, or adopted that policy. Installations always were automated and unattended using kickstart. This is the first thing a RHEL sysadmin learns.

Whereas most people installing RHEL or CentOS manually are doing it either for a desktop system or to check out the product. (That is what I did, for my laptop I wanted a Gnome desktop environment). And in those cases a default (full) install contains bits they may need. Though during installation you can disable the things you don't need, even when you install manually.

For example, wpa_supplicant is pulled in with NetworkManager. And NetworkManager is pulled in when you select a desktop environment. To me that makes a lot of sense, even when strictly speaking you may not need wpa_supplicant having the 600Kb package installed should not make a big difference. (It certainly is not a good idea to require knowledge about NetworkManager or wpa_supplicant to get wireless working)

I think the keyword here is pragmatism as a default rather than strictness or minimalism.

Well, at one of my previous

Well, at one of my previous jobs I made a very nice kickstart installation which removed all the unused software for a new serverfarm (for an "enterprise CMS"). A colleague had to reinstall them with a default install while I was on vacation because apparently a few vendors stated that if you don't have a default installation of your RHEL, you're on your own for support. Funny, isn't it...

The e1000e-driver is already in RHEL-5.2

Just note that the e1000e-driver is already available in RHEL-5.2 (and therefor CentOS-5.2).

It might be that your new ThinkPad contains a newer version of the Intel-NIC and the e1000e-driver required an update.

Even though, Red Hat does the backporting of the driver and seems to track changes too. Great work!