What you just spoke to is a systemic problem in the newer insta-media culture. It’s not just a technical laypress problem but you see it in more established topical areas like politics. Misinformation can spread like wildfire. You can argue that a certain amount of inaccuracy actually drives readership and the bloggers and journalists are just meeting expectations set by the readership of the new culture. So in a lot of ways the problem stems from how we choose our media sources as readers. We get the quality we deserve and nothing more.

But while the problem is generally applicable across topic boundaries…technology journalism suffers more acutely because technology journalism has grown up in this insta-media culture and there isn’t really a standard bearer for journalistic excellence in the area. Who do you really point to for factual, timely, sober analysis of technology developments and more particularly open source developments? I’ve started to keep a score card for accuracy. Maybe I should start calling people out and driving readership to the people who are consistently better at providing factually correct information.

I will say that at least this site wears its bias openly on its sleeve for everyone to see. The factual inaccuracies are problematic for sure, but having the slant out there as the premise for the site helps as you know exactly why the writers try very hard to paint the picture a certain way. That’s not as clear on some sites.

-jef

I feel the true purpose of the article was to create non-existing controversy in the attempt to get this article indexed by as many sites as possible. “It worked, I read it.” And ultimately get some folks to click on the affiliate links on this site.

You are either being clueless or deliberately spreading FUD. Red Hat is by far the #1 linux distribution for the enterprise and they are by far the largest commercial contributor to the Linux kernel. They backport patches and that is the model copied by Novell, Canonical etc.

“The Red Hat call center even declines their ‘enterprise grade’ support if you upgraded the stone-aged RHEL kernel to the latest vanilla on”

This is definitely a lie. Red Hat does not support the “vanilla kernel” on EL at all. It only supports the kernel that it actually ships.

Microsoft is right when they compare their prices with those from Red Hat; that sucks!

The Red Hat call center even declines their ‘enterprise grade’ support if you upgraded the stone-aged RHEL kernel to the latest vanilla one. Unbelievable for an open source provider; these kind of policies will make them irrelevant; and it’s a pity for those developers with good intentions working for them. Upgrading to the latest vanilla kernel is however necessary a lot of times to deal with new SATA chipsets (so to get the darn thing installed).

But hey, they surely like to backport things… instead of acknowledging that their old reasoning of a linux kernel to needing to be ‘proven by time’ is an outdated reasoning. Which might have been valid in the pre-2.6 days. Or when we tried to look at Sun Microsystems for a valid business model. As Sun has complete control over their own SPARCbased hardware, it doesn’t really matter.

By alienating the community years ago, Red Hat is left with Fedora as an unstable testbed with a very small rpm package base, with a doubtable quality of packages, especially when compared to those in the Debian/Ubuntu world.
yum works much slower than apt-get, isn’t configured by default and compare for example the result of an: apt-get install tomcat5 with a yum install tomcat5, or any more or less non-super-standard yet much used package… the users know why they’re choosing for Ubuntu.

And it makes Debian more popular as ever on the server side. With even Ubuntu server popping up here and there, next to the ubuntu-powered workstations/laptops, in small-to-medium businesses, or even as a pre-configurable choice of distro at large colocation facilities.
RHEL? Oracle is the last reason to deploy RHEL, and as much as we can, we suggest people who run Oracle to use CentOS instead; we feel betrayed by Red Hat and their business model based upon their worthless support and trademark.

RHEL is currently the worst to maintain and support Linux distribution of them all, and hopefully their switch Xen -> KVM is a sign that they’re ‘getting it’.
But I don’t think so…

They also should stop patching the linux kernel. That’s only arrogant behavior in which they claim to know it better than the LKML. How do you sell to a customer that the last version of RHEL doesn’t run on his brand new machine and you need to fiddle a few hours extra with it before getting it to boot?

We charge half a day extra if new server setups include RHEL, with ubuntu not. And that’s not purely thanks to ubuntu, but thanks to the people on the LKML who do such a great job of providing us with a great kernel. Ubuntu merely follows the kernel releases more frequently, but that’s all what we ask as users from a distribution provider.

Half a day extra, at our consultancy price; that buys you a cheap last minute ticket to India or the Middle East. Not everybody counts, and some people just like to stick to what they know. But most Linux users change distributions every 3 years or so – I guess that’s the only certainty…

Reality: Red Hat created the enterprise linux market and is by far the leader there. Ubuntu is practically non existent in this market and has almost no ISV support at all.

Reality: Red Hat was the largest contributor to KVM even before it bought Qumranet, the developers of KVM.

Reality: Red Hat was the first to include KVM by default in Fedora 7, long before Ubuntu

Reality: Red Hat wrote libvirt, virt-manager and a wide range of virtualization tools

Reality: Ubuntu has zero KVM patches or good virtualization tools on its own. It includes tools that Red Hat developed originally.

“1) if Xen’s design and development context made it inferior from the start, why didn’t Red Hat push KVM from an earlier date rather than focusing on Xen? True, Red Hat shipped KVM along with Xen (it would have been strange not to, since KVM has been in the kernel for a while), but it promoted Xen above all else to customers. It only recently decided to start pushing KVM.”

RHEL 5 shipped 2 months after KVM was merged into the kernel, KVM had been written 3 months before that, that certainly doesn’t qualify as “ready for prime time”. The upstream kernel community (including Red Hat) were all over KVM at this point working it to make it enterprise worthy.
The whole reason for developing tools like libvirt was to abstract the hypervisor to make a transition from Xen to KVM more straightforward

“2) it’s true that Red Hat has been a significant contributor to projects like libvirt, virsh and virt-manager (none of which is KVM-specific)”
Not just a significant contributor – you’re downplaying it – they wrote and maintain it – Canonical are just shipping those tools

“2. …. and KVM itself, more than Canonical (which isn’t surprising, since Red Hat is much larger).”

Canonical aren’t exactly part of KVM – do they even contribute to project? If you scan the kvm patches (and the kernel patches, even X, Gnome, etc) you’ll find that Canonical’s contributions are extremely low – even considering their size, in most cases we’re talking about 0.0x %

“2 …But that doesn’t negate the value of Ubuntu’s early adoption of KVM as its chief virtualization technology, while Red Hat remained focused on Xen”

Red Hat and the rest of the community were supporting Xen while developing KVM. If Red Hat wasn’t contributing to KVM then Ubuntu couldn’t ship it – this applies even before the acquisition

“2 … Ubuntu’s infrastructure has been oriented towards KVM from an early date, and that counts for something when it comes to delivering support, packages, etc.”

Infrastructure? KVM is in the kernel there is no extra infrastructure. The only supporting packages you need are the management packages – which are of course Red Hat packages (libvirt, virt-manager, virt viewer etc)

Raising support is an interesting point to make – do you think Canonical is better equipped to support KVM then anyone else? Considering that Canonical doesn’t (or barely) contributes to the KVM project or libvirt/other tools there ability to support it and fix bugs is limited

“It’s not my intention to downplay Red Hat’s relevance or the importance of its contributions; I just think there’s some value in Ubuntu’s being ahead of the game in regards to KVM.”

But that’s exactly what you did say.

I don’t been to belittle Canonical/Ubuntu here, they play a vital role in the community in terms of user adoption, bug reports, widescale desktop deployments etc. Canonical have/are playing a hugely important role in the community. This does help to balance out the areas where they don’t contribute – eg. core Linux development.

The issue here is that when “fan-boys” blindly criticise other Linux contributors and vendors and disproportionately promote Ubuntu then you’re going to get some factually challenges here.