Why Should Red Hat Support Competitors' Software?

← Back to Stories (view on slashdot.org)

Why Should Red Hat Support Competitors' Software?

Posted by timothy on Thursday May 15, 2014 @03:40AM from the just-for-fun-vs-bottom-line-reality dept.

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."

111 comments

Min score:

Reason:

Sort:

It's a business by Anonymous Coward · 2014-05-15 03:46 · Score: 0

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?
1. Re:It's a business by Jeremiah+Cornelius · 2014-05-15 03:56 · Score: 3, Insightful
  
  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..."
2. Re:It's a business by thaylin · 2014-05-15 04:54 · Score: 1
  
  Unless they are not doing OS level support on RHEL contracts if the company is using the competitors open stack implementation. Then that would be a major issue.
  
  --
  When you cant win, ad hominem.
3. Re:It's a business by Anonymous Coward · 2014-05-15 05:15 · Score: 0
  
  Where's my god damn Microsoft Ubuntu support!
  and my MIcrosoft Mysql support, dammit!
4. Re:It's a business by thaylin · 2014-05-15 05:24 · Score: 1
  
  That has nothing to do with what I said. It is like refusing to support windows boot issues because I am running openoffice instead of MS word on my machine.
  
  --
  When you cant win, ad hominem.
5. Re:It's a business by Anonymous Coward · 2014-05-15 05:30 · Score: 0
  
  Nope! This is because of ISV's like Mirantis which claim to provide a distribution agnostic implementation of OpenStack (poor in design if you ask me). This means that you can actually implement Mirantis stuff on RHEL or Ubuntu or whatever... If the case comes when people deploy Mirantis OpenStack on RHEL, Red Hat will support RHEL OS as long as it is compliant, but not OpenStack. Even if they wanted to do so, it would be complicated as for example 'Fuel' is something from Mirantis.
  Not a Mirantis supporter/hatter, just use the case of Mirantis as an example.
6. Re:It's a business by BButlerNWW9564 · 2014-05-15 06:16 · Score: 1
  
  Example would be if you want to use RHEL OS and Mirantis distro of OpenStack. Red Hat doesn't want that - they want you to use RHEL OpenStack.
7. Re:It's a business by Anonymous Coward · 2014-05-15 06:41 · Score: 0
  
  I don't know any of the specifics here, but this seems stupid.
  If Mirantis doesn't support their distro and you need support, why would you use it?
  If Mirantis does support their distro, why would you pay Red Hat?
8. Re:It's a business by Eunuchswear · 2014-05-15 06:48 · Score: 2
  
  Mirantis sell hats?
  
  --
  Watch this Heartland Institute video
9. Re: It's a business by Anonymous Coward · 2014-05-15 07:34 · Score: 0
  
  I think is more like only supporting RHEL version of Apache and not the one directly from Apache or one provided by another ISV like Oracle bundled with their software suite.
  Sounds like everybody's OpenStack is just a little different.. Which causes problems if your customers are not going to use just one vendor version.
10. Re:It's a business by Bill_the_Engineer · 2014-05-15 11:27 · Score: 1
  
  It's more like dinging RedHat for not supporting people who use CentOS or Scientific Linux.
  
  --
  These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
11. Re:It's a business by lsatenstein · 2014-05-16 04:27 · Score: 1
  
  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.
  
  --
  Leslie Satenstein Montreal Quebec Canada
12. Re:It's a business by Anonymous Coward · 2014-05-16 08:15 · Score: 0
  
  No, it isn't. It's like not supporting OpenOffice because OpenOffice is not a Microsoft product. If you're going to be a troll and vomit FUD all over the place, you could at least attempt to make it sensible.
13. Re:It's a business by Anonymous Coward · 2014-05-20 12:20 · Score: 0
  
  Most of "red hat's software" does not belong to red hat.
  They are simply using it following the licensing terms.
14. Re:It's a business by Anonymous Coward · 2014-05-20 12:24 · Score: 0
  
  Lots of companies use third party support for MS shit, Cisco feces, etc, etc, etc
15. Re:It's a business by Anonymous Coward · 2014-05-20 15:07 · Score: 0
  
  I build a home, I get the land from one source, the excavation is next, the utility (water, sewers) go in before the footing, and then the foundation.
  Different suppliers provided the material, but I build the home. It is mine. I decided on the layouts, the orientation of the building on the land, and the optional features.
  Well, Red Hat did that, and they paid for most of the carpenters, the draftsmen for the plans, the testing, and the marketing and distribution. The RH Linux is a composite of many products, all carefully integrated in a way that Red-Hat felt it should be, to serve a market place. Red Hat paid developers, for enhancement and customer support.
  Now, Oracle comes along, takes Red Hats work, forks it as their own, and markets support below RH rates, and furthermore uses Red Hat for support, in a one to many situation.. When you steal a persons or companies earnings, you are a thief without ethics and morals. When you make a product yourself, that is competitive, that is business. Even in business, there must be ethics and honesty.
Matters not... by Anonymous Coward · 2014-05-15 03:46 · Score: -1, Offtopic

I'm not happy with some Red Hat developers for basically foisting systemd on the Linux world. It's only a matter of time now before systemd becomes a requirement. Precious few Linux distros of any use are now not using it. Gentoo is holding out, but for how long. BSD looks better and better all the time.
1. Re:Matters not... by Anonymous Coward · 2014-05-15 04:00 · 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 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.
2. Re:Matters not... by iggymanz · 2014-05-15 04:23 · 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.
3. Re:Matters not... by Anonymous Coward · 2014-05-15 04:32 · Score: 0
  
  Says the person too stupid to get a handle on systemd...
4. Re:Matters not... by kthreadd · 2014-05-15 04:34 · Score: 3, 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.
5. Re:Matters not... by Anonymous Coward · 2014-05-15 04:35 · Score: 0
  
  Let me guess, your system fits on one motherboard ?
6. Re:Matters not... by pr0fessor · 2014-05-15 04:42 · Score: 1
  
  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.
7. Re:Matters not... by Anonymous Coward · 2014-05-15 04:42 · Score: 0
  
  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
8. Re:Matters not... by Anonymous Coward · 2014-05-15 04:43 · Score: 0
  
  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*.
9. Re:Matters not... by nabsltd · 2014-05-15 04:45 · Score: 1
  
  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.
10. Re:Matters not... by iggymanz · 2014-05-15 04:46 · Score: 4, 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
11. Re:Matters not... by iggymanz · 2014-05-15 04:48 · Score: 1
  
  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
12. Re:Matters not... by RabidReindeer · 2014-05-15 04:50 · Score: 1
  
  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.
13. Re:Matters not... by iggymanz · 2014-05-15 04:53 · Score: 1
  
  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....
14. Re:Matters not... by Anonymous Coward · 2014-05-15 04:54 · Score: 0
  
  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.
15. Re:Matters not... by RabidReindeer · 2014-05-15 04:57 · Score: 1
  
  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.
16. Re:Matters not... by jythie · 2014-05-15 04:58 · Score: 1
  
  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.
17. Re:Matters not... by Anonymous Coward · 2014-05-15 05:00 · Score: 0
  
  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.
18. Re:Matters not... by Anonymous Coward · 2014-05-15 05:06 · Score: 0
  
  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.
19. Re:Matters not... by Anonymous Coward · 2014-05-15 05:06 · Score: 0
  
  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.
20. Re:Matters not... by pr0fessor · 2014-05-15 05:08 · Score: 1
  
  .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.
21. Re:Matters not... by gstoddart · 2014-05-15 05:12 · Score: 2
  
  There is no need to reboot windows servers all the time either
  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.
22. Re:Matters not... by geminidomino · 2014-05-15 05:27 · Score: 2
  
  I'd say he DOES have a handle on something; There's something masturbatory about his attitude towards breaking other code.
23. Re:Matters not... by Anonymous Coward · 2014-05-15 05:28 · 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.
24. Re:Matters not... by FacePlant · 2014-05-15 05:41 · Score: 2
  
  s/pandering to idiots/responding to market incentives/
  
  --
  My Heart Is A Flower
25. Re:Matters not... by pr0fessor · 2014-05-15 05:58 · Score: 1
  
  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.
26. Re:Matters not... by Anonymous Coward · 2014-05-15 06:20 · Score: 0
  
  "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.
27. Re:Matters not... by CBravo · 2014-05-15 06:23 · Score: 1
  
  -2 seconds, jeesh that is fast (it must be very heavy to warp time like that, f-ing wormhole).
  
  --
  nosig today
28. Re:Matters not... by Billly+Gates · 2014-05-15 06:41 · 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.
  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/
29. Re:Matters not... by Anonymous Coward · 2014-05-15 06:42 · Score: 0
  
  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.
30. Re:Matters not... by Anonymous Coward · 2014-05-15 07:03 · Score: 0
  
  That was an en dash, not a minus sign.
31. Re:Matters not... by Anonymous Coward · 2014-05-15 07:10 · Score: 0
  
  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.
32. Re:Matters not... by Darinbob · 2014-05-15 07:40 · Score: 1
  
  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.
33. Re:Matters not... by CBravo · 2014-05-15 07:49 · Score: 1
  
  Did I open a can of worms here?
  
  --
  nosig today
34. Re:Matters not... by pr0fessor · 2014-05-15 07:51 · Score: 1
  
  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.
35. Re:Matters not... by kthreadd · 2014-05-15 08:08 · Score: 1
  
  Absolutely. This specific case is mitigation while we're trying to narrow down a bug.
36. Re:Matters not... by kthreadd · 2014-05-15 08:09 · Score: 1
  
  Systemd had over 500 contributors last time I checked.
37. Re:Matters not... by Anonymous Coward · 2014-05-15 08:12 · Score: 0
  
  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.
38. Re:Matters not... by Anonymous Coward · 2014-05-15 08:13 · 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?
39. Re:Matters not... by Anonymous Coward · 2014-05-15 09:10 · Score: 0
  
  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.
40. Re:Matters not... by Anonymous Coward · 2014-05-15 10:58 · Score: 0
  
  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 )
41. Re:Matters not... by Anonymous Coward · 2014-05-15 11:02 · Score: 0
  
  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 ?
42. Re:Matters not... by Anonymous Coward · 2014-05-15 13:19 · Score: 0
  
  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.
43. Re:Matters not... by Anonymous Coward · 2014-05-15 14:45 · Score: 0
  
  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) .
44. Re:Matters not... by Anonymous Coward · 2014-05-15 14:47 · Score: 0
  
  And nearly all of them were contributors on projects that systemd absorbed.
45. Re: Matters not... by Anonymous Coward · 2014-05-15 17:06 · Score: 0
  
  Newer versions as in NT 3.1? SCM has always started service dependencies since its inception
46. Re:Matters not... by ruir · 2014-05-15 18:34 · Score: 1
  
  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.
47. Re:Matters not... by Junta · 2014-05-16 00:20 · Score: 1
  
  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.
What's the point? by Anonymous Coward · 2014-05-15 03:47 · Score: -1

It's kind of like asking "Why should Bill Gates suck my dick?"
If it ain't gonna happen, then no amount of discussion on Slashdot is going to change that.
1. Re:What's the point? by Anonymous Coward · 2014-05-15 04:42 · Score: 1
  
  Dude, this is Slashdot. We can think of MILLIONS of reasons why Bill Gates should suck our dicks.
2. Re: What's the point? by Anonymous Coward · 2014-05-15 10:53 · Score: 0
  
  Natalie Portman yes, Gates not so much.
3. Re:What's the point? by Anonymous Coward · 2014-05-16 03:59 · Score: 0
  
  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.
Huh? by Anonymous Coward · 2014-05-15 03:53 · 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.
1. Re:Huh? by Anonymous Coward · 2014-05-15 04:38 · 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.
2. Re:Huh? by BButlerNWW9564 · 2014-05-15 06:21 · Score: 1
  
  Red Hat is being very coy in all this, so even the reporter and analyst don't know exactly what's going on.
3. Re:Huh? by Arker · 2014-05-15 06:39 · Score: 1
  
  In this case, because OpenStack is something RedHat is pushing hard and encouraging multiple companies to jump in on. That does not in and of itself mean they will support other companies implementations, of course, but it might be a reasonable expectation that they would at least be somewhat less than totally rigid about it. 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 but push you to another service. So I can envisage some very angry customers shuttling back and forth between HP and RH with the vendors just pointing their fingers at each other and no progress being made on a resolution for the customer. Probably not something that will encourage broader OpenStack adoption, fair or not.
  
  --
  =-=-=-=-=-=-=-=-=-=-=-=-=-=-
  Friends don't let friends enable ecmascript.
4. Re:Huh? by Darinbob · 2014-05-15 07:43 · Score: 1
  
  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?
5. Re:Huh? by Anonymous Coward · 2014-05-15 07:58 · Score: 0
  
  Last time I called VMWare for support, they weren't interested in fixing my HP servers RAID issue - damn them to hell!
6. Re:Huh? by Anonymous Coward · 2014-05-15 11:33 · Score: 0
  
  Sadly I called HP for help with my HP server RAID issue and they gave me the same answer as VMWare.
7. Re:Huh? by helix2301 · 2014-05-16 05:00 · Score: 1
  
  I agree I mean if your running Novell (god help you) and you ask Novell to help you with a Red Hat issue. They won't why because they own suse. Same situation why would they support a product that they do not design. Someone at the Wall Street Journal needed something to write about on a slow news day.
  
  --
  http://www.thetechnologygeek.org
Why wouldn't Red Hat support their OS? by Anonymous Coward · 2014-05-15 03:56 · Score: 0

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.
What? by Jiro · 2014-05-15 03:57 · Score: 1

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.
1. Re:What? by ShanghaiBill · 2014-05-15 04:10 · Score: 4, 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.
2. Re:What? by gstoddart · 2014-05-15 04:14 · Score: 4, Insightful
  
  or are they refusing to support Red Hat Linux when it is used to run a third party application?
  Well, it sounds like:
  
  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."
  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.
3. Re: What? by Anonymous Coward · 2014-05-15 05:35 · 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 isolate the problem whenever possible, so that article is definitely unfair in characterizing us in the manner that it does.
4. Re:What? by Anonymous Coward · 2014-05-15 08:08 · Score: 0
  
  I agree, RedHat has no other thing to offer besides support to make their money.
  If I use CentOS, I wouldn't expect them to support it, even though CentOS is basically RHEL. Why? Because I specifically avoided buying a support contract from RH for RHEL by using CentOS instead. I don't see why OpenStack should be any different.
  If RH is to be expected to supply support to those that specifically use competing variations to avoid paying for support, what then, is RH going to offer that it can get paid for? When you buy RH, you are really buying the support contract, since their stuff is all GPL and freely available, they wont make any money if they are forced to support competitors.
  Or is this just a weak attempt at killing RH by attacking them for their sole revenue stream?
5. Re:What? by AdamWill · 2014-05-15 11:30 · Score: 1
  
  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.)
6. Re:What? by jrumney · 2014-05-15 13:10 · Score: 1
  
  The article does not seem that badly written to me, and it says quite clearly that it is #1.
  Then it is not news. "Company refuses to support software they didn't sell" shouldn't really be making headlines - even on Slashdot.
7. Re:What? by cthulhu11 · 2014-05-16 05:36 · Score: 1
  
  The way I've heard it, independent of this article, is that RH won't support RHEL running as a *guest* on non-RH Openstack. They will support multiple other hypervisors, though, including but not limited to RHOS, so this is in fact clearly aimed at non-RHOS OpenStack.
simple, because they can. by nimbius · 2014-05-15 03:57 · Score: 3, Insightful

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.
1. Re:simple, because they can. by gstoddart · 2014-05-15 04:21 · Score: 1
  
  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.
  
  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" -- otherwise they'd endlessly be debugging someone else's code.
  If you sold software, would you support a client who has swapped out some of the components and now has a broken system? If you did, you'd be losing money hand over fist.
  Hell, I've seen lots of vendors who more or less say "we don't support Citrix, if you have an issue, it needs to be repeatable outside of Citrix" -- because supporting the rest of your infrastructure isn't something they want to be doing.
  
  --
  Lost at C:>. Found at C.
dont believe the florist... by CheshireFerk-o · 2014-05-15 04:00 · Score: 0

the roses are never free, but debian always is... if you are competent enough...
1. Re: dont believe the florist... by Anonymous Coward · 2014-05-15 04:15 · Score: 0
  
  ... And your time is worthless.
OpenStandards by Anonymous Coward · 2014-05-15 04:00 · Score: 0

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.
Huh? by Chelloveck · 2014-05-15 04:04 · Score: 1

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.
You mean ... by jamesl · 2014-05-15 04:07 · Score: 1

... "open source" isn't "open source" isn't "open source?" My gosh, Windows is Windows. Apple is Apple.
I'm so confused.
What the fuck is pureleads? by NeutronCowboy · 2014-05-15 04:10 · Score: 4, 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/, 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.
1. Re:What the fuck is pureleads? by Arker · 2014-05-15 06:29 · Score: 2
  
  Pureleads is adware/malware. Whitelisting it will just get you worse. 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.
  
  --
  =-=-=-=-=-=-=-=-=-=-=-=-=-=-
  Friends don't let friends enable ecmascript.
2. Re:What the fuck is pureleads? by NeutronCowboy · 2014-05-15 08:59 · Score: 1
  
  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.
  
  --
  Those who can, do. Those who can't, sue.
3. Re:What the fuck is pureleads? by Arker · 2014-05-15 09:20 · Score: 1
  
  I dont see any references to pureleads on slashdot currently, so either 1) you are getting a different page than I am or 2) it's not on slashdot, it's a local infection of your machine. If you are on windows 2) is almost certainly correct. LMGTFY: http://malwaretips.com/blogs/pureleads-virus-removal/
  
  --
  =-=-=-=-=-=-=-=-=-=-=-=-=-=-
  Friends don't let friends enable ecmascript.
4. Re:What the fuck is pureleads? by NeutronCowboy · 2014-05-15 10:20 · Score: 1
  
  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.
  
  --
  Those who can, do. Those who can't, sue.
Should Slashdotters support Beta? by Anonymous Coward · 2014-05-15 04:10 · Score: 0

It's total crap!
1. Re:Should Slashdotters support Beta? by Anonymous Coward · 2014-05-15 04:29 · Score: 0
  
  Your wrong. Crap at least makes useful fertilizer etc. Calling Beta crap is elevating it far beyond its level of usefulness. Beta has created a demand for sites similar to the old Slashdot and some have arose here and there. Slashdot so far has left an option for the time being: http://slashdot.org/?nobeta=1 but if Beta goes live then who knows if any will actually stay for it. Dice really should reconsider their efforts at destroying Slashdot if they want any remaining userbase.
  Unfortunately the option listed above does not always keep you from falling into that disgusting thing that is Beta, so I close the disgusting tab and better spend my time.
  Normally I would prefer not to get offtopic, but what the heck, seems that some are turning this thread into a propagandizing moderation war in relation to the article anyhow.
Why is this bad by brunes69 · 2014-05-15 04:13 · Score: 2

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.
It's a riddle wrapped in an enigma wrapped in spam by Anonymous Coward · 2014-05-15 04:30 · Score: 0

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.
....THE MATRIX HAS YOU....
I imagine that right now, you're feeling a bit like Alice. Hm? Tumbling down the rabbit hole?
um by Charliemopps · 2014-05-15 05:20 · Score: 1

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... by Mysticalfruit · 2014-05-15 05:31 · Score: 2

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.
Maybe projects should not support Red Hat? by Anonymous Coward · 2014-05-15 05:40 · Score: 0

How about if big open source projects started blacklisting Red Hat distributions?
1. Re:Maybe projects should not support Red Hat? by Anonymous Coward · 2014-05-15 08:13 · Score: 0
  
  Humorist.
Service by Anonymous Coward · 2014-05-15 05:43 · Score: 0

"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'.
Support contracts is how Red Hat makes money by cryingpoet · 2014-05-15 06:23 · 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... by Junta · 2014-05-15 07:40 · Score: 2

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.
Arker: Red Hat OpenStack support .. by lippydude · 2014-05-15 09:10 · Score: 1

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."
1. Re:Arker: Red Hat OpenStack support .. by Arker · 2014-05-15 09:31 · Score: 0
  
  And again, it's perfectly fair at one level, but (depending on how rigidly they enforce it) it could also be a disaster where customers wind up with HP and RH pointing fingers at each other. Only time will tell.
  
  --
  =-=-=-=-=-=-=-=-=-=-=-=-=-=-
  Friends don't let friends enable ecmascript.
Um... by Anonymous Coward · 2014-05-15 13:35 · Score: 0

Why? I don't know, maybe because Red Had depends on a product whose entire philosophy is contradicted by even asking that question?