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."
I'm not even sure what this means.
Why would a "commercial customer of Red Hat" use "a rival version of OpenStack"?
This is a business whose customers pay it for support. Why would you pay, if you're using someone else's software?
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.
If I buy RHEL and pay RHEL for RHEL support, who cares what else I use with RHEL, I'm still owed RHEL support.
I don't care if they don't support the "rest of the stack", but they damned well better support what they've been paid to support, or it's breach of contract, lawsuit time.
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.
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.
the roses are never free, but debian always is... if you are competent enough...
As with any OpenStandards Protocol, the issue is not moot. Theoretically, MicroSoft and RedHat can both dwell peacefully on this planet. Just ask Skippy who works for South Plains Cycles in Lubbock, TX (34Th St.) [http://southplainscycles.com/storelocator/]. He is available by phone all day.
Even after reading the article I can't tell what's going on here. Is Red Hat refusing to give any support for RHEL installations when used with non-RH OpenStack implementations? Or is Red Hat supporting RHEL but for problems involving non-RH OpenStack they're saying, "Hey, not our software, not our problem"? The former would be a dick move. The latter is perfectly reasonable.
Chelloveck
I give up on debugging. From now on, SIGSEGV is a feature.
I'm so confused.
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.
It's total crap!
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.
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.
I imagine that right now, you're feeling a bit like Alice. Hm? Tumbling down the rabbit hole?
Says the person too stupid to get a handle on systemd...
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.
Let me guess, your system fits on one motherboard ?
Dude, this is Slashdot. We can think of MILLIONS of reasons why Bill Gates should suck our dicks.
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.
systemd and it's binary logs. really? the entire notion of being a *nix sysadmin is I can control the *entire* system with easily and readily configurable conf files. Such is not the case with systemd. Why, oh why do we let MS and RH dictate the playing field. the BSDs better stay far from this crap
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.
Actually, systemd is a counterexample to the WSJ article. RedHat leaves you out in the cold if you want some other init system: don't even bother asking for them to support a different init. Though the marketing does not arise explicitly from RedHat itself, there is certainly an aggressive sales effort for the product.
I had not read that it was in an attempt to compete with a commercial product that provided the big impetus to systemd. There is a big takeaway, from this, though. Among the biggest reasons we use Linux is its openness, configurability, flexibility, stability, safety and--for most distributions--reduced interference from corporate overlords. RedHat is too much like Microsoft that way for my tastes.
I would assume that Windows Server 2012, like the related desktop products, is not all booted up and fully available to run without any startup latency in that 5 seconds. At least with a traditional init system (or a souped-up SysV init like Gentoo's OpenRC), when your server finishes booting, it is *ready*.
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 minutes required for the hardware to go through all its tests. Saving a few seconds from the time grub starts until the system is fully usable really only impacts VMs. And, I really don't care about saving 5 seconds every few months.
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
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
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 those who've chosen to pay for Red Hat products anyway (and the accompanying support), as a shareholder, I say "Thank you!"
The current state of systemd annoys me, too. But I do have hopes for it. Which is more than I can say for Gnome3 or journalctl.
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....
Windows Server 2012 can go from UEFI screen to a login screen in 3-5 seconds.
The problem isn't the bootup speed after the UEFI BIOS screen the problem is that it takes 10 Fucking Minutes to go through the UEFI BIOS screen.
As someone who has been working on servers for years, As soon as UEFI came out the BIOS post itself has been painfully slow. Used to the only thing I had to do was wait 30 secs. for the RAID controller's BIOS, now I have to wait at "Configuring Memory" before the UEFI BIOS even starts to run, then the RAID controller, then some damn scanning of all the peripheral cards, then the on-board Lifecycle management system (and others) This whole process takes about 5-15 Minutes after that Windows or Linux boots in seconds.
UEFI is a bloated replacement for the Old type BIOS, The menus are slow, bloated with gradient graphics, have to save/apply on each sub-screen (which take a few seconds), They just suck.
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 the DBA and network administrator (a/k/a normal 21st-Century work responsibilities), it's nice to know that the system has your back.
Actually, I don't recall Windows Service Manager directly supporting automatic activation of dependent services the way that systemd does. So while it's true that Windows Rot is a constant danger these days (for example, journalctl), I don't think systemd is really deserving of such contempt.
I don't know, I have had to listen to a lot of bitching and moaning when a server takes 'too long' to reboot, at least from the people trying to use the service on it. This can esp be an issue when you have to do a rolling reboot of a bunch of servers with interconnected services.
no doubt, but an invasive architecture-forcing blob becoming a dependency of everything is a disaster not worth the benefit when it's written by an arrogant jerk who doesn't listen and manipulatively tries to increase his power and the number of people he gets to not listen to.
Yes, it's personal. Open source means we have to work together. Saying "we want to be apolitical" just means people who are good at politics are the only ones allowed to be political and actually makes things worse. Saying "no jerks in core dependencies, and no balancing of jerkyness against jerk-provided benefit. no jerks, period," makes things better.
So tired of the reboot myth. No admin dicks around restarting 30 + services. You take it out of the load balancer, apply patches, reboot.
Nobody cares what you do with your toy "server". Most of us want to get off the patching roster and get back to the heat game.
Linux has to stay competitive, and in the real world, if MS has a whiz-bang new feature, Linux has to have some answer to it. For example, being able to boot a server in several seconds from a SSD is one advantage Windows has had until systemd came along.
Change on a fundamental is annoying, but without things like systemd, linux will slowly fall behind. LVM2 is decent, but the industry is moving/has moved to ZFS or Storage Spaces + ReFS, due to bit rot issues. Linux has the edge in cluster filesystems, but Windows can leapfrog it as soon as ReFS supports it without the CFS add-ons.
As for what it does, systemd is decent. It definitely is better than launchd or init. It works with existing applications fairly decently.
Yes, change sucks. For example, having two different network management systems, one using the old sysconfig files, the other using Bog knows what... but works well with dynamic stuff. However, in the enterprise, it is evolve or die.
.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.
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.
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.
I'd say he DOES have a handle on something; There's something masturbatory about his attitude towards breaking other code.
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.
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.
How about if big open source projects started blacklisting Red Hat distributions?
s/pandering to idiots/responding to market incentives/
My Heart Is A Flower
"Its not ours so we aren't touching it" is one way to go, and the WSJ could take that attitude, but commercial companies looking for business opportunities (expanding their own market) don't do this. They offer to at least manage the all of their customers software. Whoever they are working for is a customer. You can mutter crap about 'smart business plan' but offering service (and of course, charging plenty for it) is a better way to keep a customer. You can say "its not ours and we aren't touching it", but that does open the door for competitors. Just sayin'.
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.
"you should be using apache's configuration variables"
Apache was just an example. You might be restricting a set of processes that don't have a built-in means of handling this.
"You can cause application failure doing memory limitation with systemd"
Yes, but the point is to limit the damage to that one misbehaving or misconfigured app instead of having it affect other apps on the system which may cause even greater problems.
-2 seconds, jeesh that is fast (it must be very heavy to warp time like that, f-ing wormhole).
nosig today
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.
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/
Not to mention you can do what systemd claims, if you really wanted to, using already existing software and without polluting the linux ecosystem and introducing unnecessary obscurity and complexity. systemd is there because redhat wants it for their container thing, and thus has forced everyone to suffer it. And also has the nice side effect of them controlling a vital piece in everyone's distribution. Microsoft couldn't have planned it better.
systemd. because binary logfiles and segfaulting services are best restarted automatically.
That was an en dash, not a minus sign.
RedHat even supports their main competition, CentOS. No, RedHat isn't perfect, but they tend to do the right thing.
RedHat brought CentOS into the fold some months ago and hired the maintainers. CentOS is officially RedHat these days.
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 better off as separate packages.
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.
Did I open a can of worms here?
nosig today
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.
Absolutely. This specific case is mitigation while we're trying to narrow down a bug.
Systemd had over 500 contributors last time I checked.
Windows Service Manager directly supporting automatic activation of dependent services
It does at least in newer versions, if you register your service properly, but Windows software is easier to write so you end up with a lot of slapasses that don't do it properly.
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?
Arker: "In this case, because OpenStack is something RedHat is pushing hard .. it might be a reasonable expectation that they would at least be somewhat less than totally rigid about it."
..
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
"If you are looking for enterprise-level support, or information on partner certification, Red Hat also offers Red Hat Enterprise Linux OpenStack Platform."
When you have 10-100 servers running depending on what time of day it is you develop everything around getting stuff right during boot and stop fooling around with state changes.
Natalie Portman yes, Gates not so much.
Yeah, because Apache can also permit to limit cpu and I/O like systemd ? Or maybe it doesn't, and then you focus just on one signle things, missing the big picture ?
( not to mention that everybody love to have 100 different way to do the same type of configuration all over the place )
Some people do have a lot of VMs, especially since servers with 72G of ram are most of the time quite wasteful for the smaller workload. You may even have heard about this stuff called "the cloud", it seems to be a bit hype but maybe thereis people using it out there ?
Um, it's easy to do this on Linux with the prlimit syscall and command, which let's you set the limit on running processes. Or just call the POSIX ulimit command from the startup script, or from the environment you start Apache from.
systemd is becoming a dumping ground for features.
The reason systemd has so many features is because most of them _already_ exist and are trivial to use in Linux. Why is why systemd can never be ported to another operating systems; it's entirely reliant on Linux features that you can freely use yourself.
Now, you might say, if systemd does this for me already, why bother learning all these other commands? Answer: because in many cases, once systemd gets involved, you _can't_ use those other features, because you shouldn't (or can't) change the state of the system behind systemd's back. So in that sense it _limits_ you, especially in the future when software comes out that can use these features in novel ways, which might make them incompatible with systemd, leading to difficult to reproduce bugs in behavior.
Why? I don't know, maybe because Red Had depends on a product whose entire philosophy is contradicted by even asking that question?
RedHat leaves you out in the cold if you want some other init system: don't even bother asking for them to support a different init.
Well yes, that is pretty much it. You are at the mercy of bowing down to
$wherever_RedHat_happens_to_want_go_this_week
which will always be
$whatever_makes_the_most_money
which ends up being
$whatever_the_biggest_customers_will_pay_for
so there is really not much difference between them and Microsoft, the small guy will get shafted either way.
Among the biggest reasons we use Linux is its openness, configurability, flexibility, stability, safety and--for most distributions--reduced interference from corporate overlords. RedHat is too much like Microsoft that way for my tastes.
Well, be wary of those who want reduced interference from corporate overlords. Many times, that is just a disguise for "wants to do the intefering and overlording ourselves"
I won't say RedHat is exactly like Microsoft...but yes, money is all that matters, for sure.
The question then is, if you have deep pockets 1) is it easier to pay Microsoft to work in your best interest 2) is it easier to pay RedHat to work in your best interest 3) is it easier to tell them both to take a hike
I would lean towards 3) .
And nearly all of them were contributors on projects that systemd absorbed.
Newer versions as in NT 3.1? SCM has always started service dependencies since its inception
I only reboot for kernels upgrades and nothing else. I have a couple of really old servers with I only reboot on our yearly weekend electric maintenance day, and even day just for precaution.
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.
XML is like violence. If it doesn't solve the problem, use more.
EXACTLY my point. We can sit here and discuss millions of reasons why Red Hat should support competitors' software, but no amount of discussion on Slashdot is going to force them to do it.
Not sure why I was modded down for my original statement.