Kees Cook: yay for barriers
Kees Cook: yay for barriers
Posted May 18, 2010 8:15 UTC (Tue) by AlexHudson (guest, #41828)In reply to: Kees Cook: yay for barriers by lkundrak
Parent article: Kees Cook: yay for barriers
What's really happening here is that the undercurrent of dissatisfaction with Canonical's contribution to the community has bubbled to the surface, and this was just a convenient place to vent it. Fundamentally, T'so various (snide) comments are essentially right: if Canonical purport to be an enterprise Linux vendor, they should be able to fix stuff like this themselves.
Posted May 18, 2010 9:30 UTC (Tue)
by hppnq (guest, #14462)
[Link] (6 responses)
I disagree, they are essentially utterly wrong. What the distributor should be able to do is communicate in a normal way with the developer, so that issues get solved appropriately. It seems the Fedora, Ubuntu and kernel people all agree on that. The rest is politics.
Of course there is nothing wrong with a patch that originates downstream.
Posted May 18, 2010 11:54 UTC (Tue)
by AlexHudson (guest, #41828)
[Link] (3 responses)
As for the rest being politics - I disagree, but I understand where you're coming from. A distributor could just play middle-man to resolve bugs, sure - but I don't think that's good enough for an enterprise vendor. At that level you get paid for being able to solve any problem a customer has, and that's exactly what the likes of Red Hat, Novell, and to a large extent Oracle (to name a few) are able to do.
If you're reliant on the engineering expertise of some other people, be they in another business or just in the community, it's difficult to claim that you're an enterprise vendor. It's pretty much a statement of fact.
Posted May 18, 2010 14:04 UTC (Tue)
by hppnq (guest, #14462)
[Link] (2 responses)
That is not how it works in practice. In general enterprises simply maximize profits using limited resources, which means that some problems really won't be solved, not even if you are a really Important Customer who pays an incredible amount of money.
But also in theory it is not true. If there are reasons to duplicate the effort to solve bugs in libredhat, they must be even slightly worse than having to choose between libgoogle and libcanonical. Optimally, and this is actually the whole idea behind Free Software, everyone helps a bit to solve the omnipresent problems in libwonderful, whether it is testing for bugs, reporting and tracking them, or fixing them.
Posted May 18, 2010 15:17 UTC (Tue)
by AlexHudson (guest, #41828)
[Link] (1 responses)
The whole reason big customers will pay big bucks for enterprise support is not to have some go-between who knows the relevant bug trackers to file their bugs for them. That's a totally valid model, but it's not enterprise support.
Posted May 19, 2010 7:24 UTC (Wed)
by hppnq (guest, #14462)
[Link]
You can easily verify this by just looking up on the websites of the companies you mention what exactly they mean by "enterprise support". Look at the partner programs, the training, the certifications and don't forget the small print.
Posted May 18, 2010 15:21 UTC (Tue)
by blitzkrieg3 (guest, #57873)
[Link] (1 responses)
But lets look at another "enterprise Linux" vendor. Let's assume that Kees never found the bug and no one identified the patch that caused the regression, and that the patch was merged into RHEL 6. I know from my experience at Red Hat that if some Enterprise Linux customers hit this issue later on, the first that the community (and probably Ted Tso) would ever hear of it would be on lkml, where someone (probably Sandeen) would have explained the reproducer, RCA, and patch. Then there would probably be a little discussion, followed by an ack or possibly a small rewrite.
What is striking about this bit of drama isn't the Fedora bugzilla, which wasn't wrong by any means. What is striking is Kees did the virtual equivalent of standing up and looking around the Ubuntu HQ, and couldn't find *anyone* that would be able to fix this problem. Instead, his first inclination was to ask the maintainer out of band, who was good enough to look into the issue for him and find a workaround. If you're an Enterprise Linux salesperson in the process of converting an LTS customer, you now have a pretty good sales pitch. "What if Ted isn't so gracious next time?"
Posted May 18, 2010 16:53 UTC (Tue)
by jspaleta (subscriber, #50639)
[Link]
My reading of the original ticket is that an attempted fix was committed in April... but it hasn't completely solved the issue. My understanding is that LTS was still being impacted in some situations and that is what prompted Kees to open up the upstream ticket in May.
-jef
Kees Cook: yay for barriers
Fundamentally, T'so various (snide) comments are essentially right: if Canonical purport to be an enterprise Linux vendor, they should be able to fix stuff like this themselves.
Kees Cook: yay for barriers
Kees Cook: yay for barriers
At that level you get paid for being able to solve any problem a customer has, and that's exactly what the likes of Red Hat, Novell, and to a large extent Oracle (to name a few) are able to do.
Kees Cook: yay for barriers
The whole reason why customers pay for enterprise support is that they get appropriate support. Somewhere down the line, bug fixing is obviously a part of this, but there is not a single company I know that prefers the ability to be able to fix bugs in production over not running into them in the first place. Enterprises whose core business is to unmount ext4 filesystems will have their own expert, and they will get the training from IBM, who may not even be able to correctly spell "ext4".
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Kees Cook: yay for barriers