Why Should Red Hat Support Competitors' Software? 111
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."
Re:It's a business (Score:4, Insightful)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Mirantis sell hats?
Re: (Score:2)
Re: (Score:2)
This is like dinging RedHat for not supporting Ubuntu or SuSE. More specifically, for not supporting Apache on each of these distros.
You forgot Oracle taking RED Hat's linux software, rebranding it and selling it as their own.
Re: (Score:1)
Huh? (Score:5, Insightful)
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.
Re: (Score:2)
When you put up a line for your support staff and say 'support x but not y' you open up a situation where if it's not CLEAR that X is really the problem, they dont want to do anything b
Re: (Score:2)
What about just supporting basic old Red Hat Linux? The article isn't clear here, are the refusing to support the basic kernel and distribution merely because some competing cloud service is used, or just refusing to support one particular service?
Arker: Red Hat OpenStack support .. (Score:1)
Since when has any Open Source outfit offered 'free' support. The license specifically state that the software is distributed free of charge, not free of support charges
Apache License, Version 2.0 [apache.org]
"If you are looking for enterprise-level support [redhat.com], or information on partner certification, Red Hat also offers Red
Re: (Score:1)
Re: (Score:2)
What? (Score:2)
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. It's just the flip side of the manufacturer who won't fix a hardware fault because you ran Linux on your computer. Or with a car analogy, if you install a radio, the car manufacturer isn't responsible if the radio goes bad, but they are if the rest of the car does.
Re:What? (Score:5, Informative)
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.
Re: (Score:2)
Disclaimer: I work for RH, but I have nothing at all to do with any of this stuff (I work on Fedora).
AFAICS, the WSJ alleges #2, but we are very clearly stating that WSJ is wrong and it's just #1 (we'll support your RHEL install no matter what you have running on top of it, just like we always have, we just won't support the OpenStack bit if it's not RH OpenStack, or whatever the hell we call it, I don't know.)
Re: (Score:2)
Then it is not news. "Company refuses to support software they didn't sell" shouldn't really be making headlines - even on Slashdot.
Re: (Score:1)
Why is this bad (Score:3)
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 - b
Re:What? (Score:5, Insightful)
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.
Re: What? (Score:1)
I worked in Red Hat support for half a decade and I can say this for sure - we would strive to support whatever we ship and a lot of us even try and help out even when there is some easy to find and fix problem in bits we don't ship (provided we have the time of course), like a third party open source program or custom app. Of course, there are no support SLAs associated with the latter. For cases where it is unclear whether our bits are to blame or the third party bits, we usually take it upon ourselves to
Comment removed (Score:4, Insightful)
Re: (Score:2)
Which in no way means they should be expending their resources to support whatever random bit of code you've chosen to install.
They can 'support' the project, be in favor of its adoption, but when the the call comes in of "it is broken, make it go", they really have to draw the line and say "we can't help you resolve problems in the stuff we didn't write" -- other
Huh? (Score:2)
Re: (Score:1)
redhat supports the open stack in their distribution. If you *run* openstack and use that version you get support.
If you run a different open stack version, on RHEL, they offer no support for that open stack version.
If you run RHEL on *any* openstack deployment, you get RHEL support, but not support for *that* open stack deployment.
Re: (Score:1)
You mean ... (Score:2)
I'm so confused.
What the fuck is pureleads? (Score:5, Interesting)
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/ [pureleads.com], and it seems to me that beta still hasn't fully died.
Dice and Dice Holdings: go fuck yourself.
Re: (Score:3)
I recommend blacklisting it, along with slashdot.org and fsdn as well. It wont let you metamoderate but the more people that complain about it the more chance someone might finally fix that bug, after more than a decade. The rest of the site is still functional, as long as you are a logged in user, disable all scripting and over-ride the fugly fonts at least.
Re: (Score:2)
It won't even let me post if I don't whitelist it. Then again, I do have slashdot whitelisted, soooo.... I might have to look into a custom set of script enablements for Slashdot now, because this is just ridiculous.
Re: (Score:1)
If you are on windows 2) is almost certainly correct.
LMGTFY:
http://malwaretips.com/blogs/pureleads-virus-removal/
Re: (Score:2)
Thanks - I didn't think it was actually malware since I didn't get any ads or anything similar, but turns out that I did install PureLeads. Looks like either Foxit, Handbrake or CDex had it bundled. Gah, and I thought I was pretty good at reading malware install prompts.
um (Score:2)
Support is Redhats only real product... (ok, they probably do development work to if you pay them to)
I'm sure they would support competitors products if you put it in your support contract. This is more like them clarifying "Our cheapest support contracts doesn't cover 3rd party stuff" but I guarantee if you're a top tier customer they're going to bend over backwards to help you. It's not like their Oracle and you're stuck with them. Their competitors OS's are compatible and just as free as theirs.
How shocking... bolt on spoilers voids warrenty... (Score:3)
Support contracts is how Red Hat makes money (Score:1)
Red Hat essentially provides all of their software offering for free. They make the money off the service contracts. Supporting a couple of additional third party applications is just one more thing they can charge for. I like free money.
Simple... (Score:3)
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.
Re: (Score:3, Insightful)
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 o
Re: (Score:1, Insightful)
because Linux servers need to be rebooted so often? systemd serves no purpose for any sys admin with a brain. trying to make windows "admins" happy is just pandering to idiots.
Re: (Score:2)
you are funny, talking about a system with 50,000+ lines of code and requiring dbus. the systemd inventor didn't have a handle on something, that's for sure
Re: (Score:3)
I'd say he DOES have a handle on something; There's something masturbatory about his attitude towards breaking other code.
Re:Matters not... (Score:4, Informative)
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.
Re:Matters not... (Score:5, Interesting)
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
Re: (Score:2)
Absolutely. This specific case is mitigation while we're trying to narrow down a bug.
Re: (Score:2)
Systemd had over 500 contributors last time I checked.
Re: (Score:1)
Since systemd may cause strange failures in Apache if you do it this way, it would be much better if you just used Apache's own configuration to do the same thing. Not only is adjusting Apache's limits easier (it is just editing a few easy-to-read variables in a configuration file), it is less likely to cause a service failure and the solution is cross-platform in nature. Using systemd, while it may work, is not the right tool for the job in the example given.
Re: (Score:1)
What happens when Apache is malfunctioning and not honoring the limits? Let it eat the rest of the systems's resources?
And what difference would it have from simply running it on a system with less RAM?
Re: (Score:2)
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.
Re: (Score:2)
at work the windoze guys are rebooting all the time; true maybe its just the barrier to entry to be windows developer is low so the apps suck and its not directly the fault of the OS....
Re: (Score:2)
.Net for the masses... anyone can slap together an application in a very short period of time and make it look pretty... to bad it will have more bugs than there are words in the nearly nonexistent help menu that appears to be written in gibberish.
Re: (Score:3)
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
Re: (Score:2)
I have had to set reboots on more windows boxes than linux but considering linux makes up about 10-15% of our servers that should be the case.
Some of those I can boil down to hardware and application implementations not being scaled properly because of cost.
Re: (Score:2)
Re: (Score:3)
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 wh
Re: (Score:2)
I wasn't apposing SystemD. I was attempting to refute the idea that linux boxes never get rebooted with an anecdote about getting emergency calls from panicking helpdesk people while in the shower and telling them just to reboot it.
The last time I got one of those panicked calls I was laying on the floorboard of my car in the parking lot of an autozone trying to get the blinker relay out.
Re: (Score:2)
because Linux servers need to be rebooted so often? systemd serves no purpose for any sys admin with a brain. trying to make windows "admins" happy is just pandering to idiots.
First of all, employers don't want sysadmins with brains, they want untrained monkeys who will work for peanuts.
Secondly, systemd is designed to ensure that complex networks of services are started and stopped with all dependencies automatically handled. Even if you are a sysadmin with a brain, at the end of a week's worth of 14-hour unpaid overtime shifts (a/k/a normal 21st-Century work week), when a major component just blew out and you're scrambling to get everything back together while also serving as t
Re: (Score:2)
Re: (Score:3)
s/pandering to idiots/responding to market incentives/
Re: (Score:2)
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.
If you ignore things like timing issues on NFS mounts (systemd often starts services that need the mount before the mount is really 100% ready), and just stick with local dependencies, systemd might save you 3-5 seconds on boot over upstart or plain old SysV init. If you don't ignore those things, it's possible that systemd will cost you time not only every boot, but admin time as you try to debug why the services aren't functioning correctly.
This is absolute unimportant compared to the sometimes nearly 5
Re: (Score:2)
Red Hat supports a LOT of "competitors" and always has. After all, most of Linux comes from outside and they're big at contributing back to it. It's not unreasonable for them to want to draw the line at something that comes in flavors that are all over the map in order to focus on the one flavor that they prefer. I cannot find it in me to hate them considering how they've dealt with CentOS and other similar products which not only steal customers from them, but give the product away for free. And for all th
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
The fast windows boot time is because it essentially does a partial hibernate when you shut it down, so when it boots back up it is not a full boot. If you force a full boot it is indeed slightly faster than it used to be.
You don't need systemd to have a faster boot time, just need to be smarter about doing more in parallel which is perfectly doable with old fashioned and reliable rc scripts. Ya it's nice that systemd makes this easier, but it comes bundled with a lot of extra stuff as well that would be
Re: (Score:2)
it is compatible with legacy init.d scripts.
Not quite. Formerly an init.d script 'should' do a few things, but if it had some other verbs, that's ok. Now, systemd will complain loudly about 'reload', a fairly common 'non-standard' verb.
Re: (Score:1)