Slashdot Mirror
Why Should Red Hat Support Competitors' Software?
colinneagle (2544914) writes "The Wall Street Journal recently reported that, based on documents it reviewed, Red Hat "has chosen not to provide support to its commercial Linux customers if they use rival versions of OpenStack." But the big question is: Why would customers have expected that in the first place? Gartner analyst Lydia Leong told Network World that Red Hat isn't really doing anything wrong here. Customers shouldn't have an expectation that Red Hat would support competitors' software. "The norm would be to expect that non-Red Hat software is treated like any other third-party software," Leong says. If Red Hat has done anything wrong, it's that it has not clearly articulated its positioning and support for non-Red Hat OpenStack distros. Red Hat did not immediately respond to a question asking for a clarification on its support policy. The complication in all this comes from the fact that OpenStack is an open source project and there are misconceived notions that all OpenStack clouds are interoperable with one another. But Leong says just because OpenStack is open source doesn't change the expectations around vendors supporting competitors' products."
Why should the Wall Street Journal assume that any company would support anything, of any sort, provided by a competitor? How is any company expected to know the details about someone else's product, and why should should they have any responsibility, at all, to help people fix problems with some one else's product?
I think the problem, here, is with the Wall Street Journal. Not Red Hat.
This is like dinging RedHat for not supporting Ubuntu or SuSE. More specifically, for not supporting Apache on each of these distros.
"Flyin' in just a sweet place,
Never been known to fail..."
Because Redhat is a platinum level director of the OpenStack project and have a vested interest in its general success as an open source project.
on an offtopic note: the WallStreet Journal has gone seriously downhill since Murdoch took it over.
Good people go to bed earlier.
systemd is an answer to supply and demand. Windows Server 2012 can go from UEFI screen to a login screen in 3-5 seconds. rc.d has had a very good run, but there is a demand for faster, asynchronous booting, so systemd can get a system from the kernel to services started in just a few seconds, as well as down the machine in the same time.
No, it isn't perfect, but it is compatible with legacy init.d scripts.
All and all, of all the big companies, RedHat seems to do very little evil. No, they won't support other vendors, but that only makes sense. One doesn't expect Sears to support an alto chainsaw bought from Harbor Freight, even if the Sears model comes from the same OEM/ODM.
RedHat even supports their main competition, CentOS. No, RedHat isn't perfect, but they tend to do the right thing.
Are they refusing to support the third party application itself, or are they refusing to support Red Hat Linux when it is used to run a third party application?
The article is badly written, but it sounds like #2, which is indeed bad.
The article does not seem that badly written to me, and it says quite clearly that it is #1. They quote Red Hat's spokesman: "Users are free to deploy Red Hat Enterprise Linux with any OpenStack offering, and there is no requirement to use our OpenStack technologies to get a Red Hat Enterprise Linux subscription." So if you buy support for RHEL, they will support it, but they will NOT support third party OpenStacks. Which seems reasonable to me, as long as the terms of the deal are clear.
And why do I need to whitelist it to load full comments, reply to large comments, and to moderate? The only thing I can find is this shit: http://pureleads.com/, and it seems to me that beta still hasn't fully died.
Dice and Dice Holdings: go fuck yourself.
Those who can, do. Those who can't, sue.
Say there was a bug in VMWare that caused Windows 8 to crash when running inside it (this actually happened). Do you expect Microsoft to provide support for this issue and fix this bug? No of course not - VMWare should fix it.
I don't see why this is any different with OpenStack. RedHat has no idea what you have done to your custom home-grown OpenStack build, how can they possibly support you running their software inside it. If you can prove that the issue is in their software, then they will look at it - but until that point bugger off.
Well, it sounds like:
My guess would be "since you're not running our version of OpenStack, we can't support you if you have issues with that version of OpenStack.
I suspect RH is still giving you support for core functionality they know about.
This sounds more like you've bought a car, replaced the transmission with a 3rd party one, and are coming back to the car maker for warranty on your transmission.
They can't deny you coverage on your engine (unless they can show your transmission broke it), but you're completely on your own with the transmission.
In other words, Red Hat will support the pieces they gave you, but if you swap out pieces, you are entirely on your own for the care and feeding of those.
And, really, that sounds entirely reasonable to me.
We once had a piece of software which shipped as being tested against a specific set of Java/application server combinations. We made it clear there were some combinations we had never tried, tested, certified, or even seen and definitely would not support. The client spent several weeks jamming it into IBMs Websphere, against our advice and warnings we couldn't (and wouldn't) support it. They made all sorts of config changes, shoe horned in settings in the IBM stuff, and generally bashed it into place.
When they had issues and we said "you need to reproduce this using the stuff we support", they started to get irate and threaten legal action. When our team of lawyers spelled out that they'd essentially Frankensteined together something which we told them we can't support, and that we had explicitly told them this before they started having problems someone higher up their food chain swatted down their own people.
If you insist on changing some of the parts, don't expect your vendor to support the parts you have now taken ownership of. That is your damned problem.
Why anybody would expect Red Hat to support components they didn't ship is beyond me.
Lost at C:>. Found at C.
There are many other benefits to systemd. Just a quick example that helped me recently; limit the amount of memory used by all apache processes and its descendants. Yes you can do this on your own but systemd makes it quick and easy.
better not to be using a giant knob without narrowing down what the issue is, you should be using apache's configuration variables. You can cause application failure doing memory limitation with systemd
Windows machines more than anything else I've seen.
Hell, I've heard of rebooting referred to as the "universal Microsoft patch". I have seen endless things where the first words out of some support guy are "have you rebooted?". I've seen Windows admins say "acting flaky, nothing in the logs, reboot it and see if it helps".
Sadly, I've noticed that a high percentage of things actually do get resolved with a reboot.
My wife once spent several days trying to help a client debug something in a production environment. She suggested "maybe we just reboot it" on day one and was shouted down. By about day 4 even the vendor was saying "we don't know, maybe just reboot it". When they did, the problem went away.
And, they could have had it "fixed" on day 1, because nobody had any more information after the reboot than before, other than "wow, it seems to be working now".
(In fairness, this is not unique to Microsoft, and they've gotten much better -- but there are still many mysterious faults which seem to go away with a reboot. So much so we've actually scheduled machines for a weekly reboot, just so it never got into whatever borked state it would get into after 2+ weeks.)
Lost at C:>. Found at C.
I'd say he DOES have a handle on something; There's something masturbatory about his attitude towards breaking other code.
So RedHat fully certifies a stack as something that they'll support... Yeah, I don't see the problem here. If you go doing things to it that RedHat hasn't tested, don't be surprise when they won't want to support it. Considering that RedHat only makes money off of support doing anything that takes them away from that core mission is money out the window. Now if you want a blanket support contract or a per diem situation where when you get stuck with your wack ass solution they'll drop engineers on the problem... I'm sure RH would be up for that... provided they're getting paid. Otherwise you'll just taking engineers away from supporting supported configurations and sending them down support rabbit holes.
Yes Francis, the world has gone crazy.
s/pandering to idiots/responding to market incentives/
My Heart Is A Flower
There is no need to reboot windows servers all the time either... but let's be honest I'd rather just have some helpdesk flunky reboot it when they call me at a restaurant, in the shower, or at the grocery store than try to explain which services to restart and possibly how to restart them.
Besides looking for reasons to oppose systemd with rationalization like well we do not reboot often, why don't you look into the benefits and why it is replacing init?
SystemD is event based which adds A TON more flexibility than what you can do with init. Also event driver async http software like ngix is multitudes faster than Apache and more flexible based on scenarios. The system can respond to events and if you have a laptop can sleep in one network and wake up in another.
Another problem with init is what designed in 1984 (SysV implementation) where you had maybe 50 programs and shell commands at the most. Things were simple then. Gnome requires how many dependencies? It just is a mess to deal with on a modern system where an event driven and async model would be more appropriate.
http://saveie6.com/
Mirantis sell hats?
Watch this Heartland Institute video
RH shouldn't be expected to provide commercial support for infrastructure management by non-RH Openstack, even if other RH components are 'nearby'.
RH should provide support for RHEL instances run inside whatever virtualization solution (openstack or whatever)
RH should provide os level support for RHEL servers running openstack components, but openstack components then become 'just another app that isn't RH' responsibility.
This isn't that hard to understand.
XML is like violence. If it doesn't solve the problem, use more.