Slashdot Mirror
Red Hat Nears $1 Billion In Revenues, Closing Door On Clones
darthcamaro writes "Red Hat is almost at its goal of being the first pure-play open source vendor to hit $1 billion in Revenues. Red Hat reported its fiscal 2011 revenues this week which hit $909 million. Going forward, Red Hat has already taken steps to protect its business by changing the way it packages the Red Hat Enterprise Linux 6 kernel, making it harder for Oracle to clone. 'We are the top commercial contributor to most of the components of the Linux kernel and we think we have a lot of value and we want to make sure that, that value is recognized,' Red Hat CEO Jim Whitehurst said. 'In terms of competition, I don't think we necessarily saw anything different from before but I'd say better to close the barn door before the horses leave than afterwards.'"
CentOS and Scientific Linux are still workable, it's the "enhanced clones" like Oracle and Novell that are cherrypicking RHEL's best customers and not giving back to the open source community with development in open source filesystems, X, authentication, and genuine hardware support that are messing up the business.
It's just too bad CentOS has lost its way with one of its developers, Johnny Hughes, telling people to not let the door hit them in the ass on the way out if they don't like how late everything is and then ignoring attempts to help. I just switched to Scientific Linux and and am quite happy.
Will I still be able to get the clone in the form of CentOS? I use CentOS a lot in our development environment and less critical infrastructure, just to make sure that I'll be able to upgrade it to RHEL if the system requires more professional support.
CentOS is fine, because they're a 100% clone of Red Hat. Red Hat is putting their kernel patches together instead of separate. If you wanted to pick and choose which ones you used and make something different, it would be *slightly* more difficult. But considerate the last release was broken out. You know what they were starting with. Take a diff of the new patchset against the old one, and you should have an idea of what they've changed or added.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
Goatse, again.
Man, you are hilarious. No one in history has ever done that before. And you've created a couple accounts today just for that. When you look back on your life, I'm sure you'll feel content and fulfilled.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
Had you clicked on the link, you would know the GP is a troll who has been posting goatse links on throwaway accounts.
UID over 2 million + link to blog.com = troll.
Do what thou wilt shall be the whole of the Law
TFA doesn't specify what this actually means, so let me speculate. They're not going to go closed-source; they'd be lynched. I think this is a reference to the fact that they're distributing their source prepatched now, to make it harder to just take their patches and apply them to other distros.
IMO that's kind of sleazy. They got where they are standing on the shoulders of giants. The deal was: here, have this free stuff, build on it, make money with it, but you have to keep giving back. And they got their value out of it, but now they're trying to give back only the minimum they're contractually obligated to do. It's legal and not purely evil, but still moderately scummy.
I don't really see it being that good for them, either. Oracle isn't going to have much trouble reverse-engineering the patches back out, but RedHat now ends up in a more difficult position: fewer of their patches will be incorporated upstream, so they have to spend more work porting them into each new release; they'll have less community review and bugfixes in their patches; and they're going to alienate the community.
On the other hand RH users won't end up in the worst scenario: stuck using RH's buggy crap and unable to do anything about it. The source will still be there; they can still dive in to figure out what's wrong and fix it instead of dealing with a black box. I know I had to more than a few times when supporting RHEL systems.
Well, that would give you one very large diff and not several specific ones that you could pick and choose between.
"just the patches" would be nice. But a diff doesn't give you that. It gives you a monolithic patch with no history or context.
I believe they have no beef against CentOS, actually I've seen at least one Red Hat employee encouraging the use of CentOS, since Red Had is the "de facto upgrade path" (not the exact words, but something along this way). So you freely enlarge the customer base, which will go to Red Hat when they need higher level commercial support. And for the free ones, even Microsoft has recognized they cannot sell to students, and are giving away the software anyways.
However Oracle is another deal. They just slap Oracle logo on Red Hat, do not acknowledge the source, and sell is as "unbreakable Linux". This would make a regular person ashamed of himself. They benefit a lot from open source but not giving back much in return. Do not start me with what they're doing to Solaris, Java, and OpenOffice...
So I'm with Red Hat on this one, at least until they do something directly bad to CentOS.
I'm confused. How on earth do you think Novell is cloning RHEL? They are a significant contributer to linux, 3rd from the top, and non-trivial user ecosystem (they supplied the devs who got alot of the new AMD graphics stuff going, as I recall.) Big contributers to KDE and libre office. If they contribute less then redhat, that would only be because they have less staff (I think... at least the suse part of them does, for sure).
Suse is as different from RHEL as debian is. Yes, they both use rpms. That's about it.
GOATSE LINK.
By the way kiddo, find something new to shock us with. Slashdotters are pretty much immune to that one.
Links to goatse, don't click
Our culture doesn't get smarter, it just finds new ways of being retarded.
Okay, wait, goatse link threads are not something I would normally post in, but I have to ask.
By "or something" do you mean that you didn't look at it long enough to really be sure what it was (and I pray for your sake that this is the case), or are you just giving voice to that little, terrified piece in the back of your brain that insists that cannot be human?
The enemies of Democracy are
That only gives you the patch broken up in space, not in time.
The idea is that Red Hat has patches for specific issues that are developed at different points in time. These patches may modify the same files as previous ones, or even the same blocks of code. By having all patches applied at once, the singular diff does not tell you which component of the patch fixed which issue.
This is really only relevant for providing commercial support. Previously, by having patches associated with known issues applied sequentially, it was much easier for another company to say "Oh you're having Issue X? Well Patch Y will fix it." Now their options are to reverse-engineer the monolithic .diff to find the part that fixes a specific issue, or tell their customers they have to apply the entire patch. Again, that's not something you'd care about if you're a desktop end-user, but in a corporate IT environment it makes a difference.
The enemies of Democracy are
Why don't you last 3 linux users just swallow your pride and buy a mac like everyone else with more than 2 brain cells has done in the last few years?
I know you're just a troll but I can't resist. First of all, Linux and RHEL in particular, runs on actual servers. You know, those computers Apple slowly are phasing out? Xserve is gone, and Mac Pro server is soon to follow. And, Linux pisses on Mac OS X when it comes to market share on servers. Lastly, it's Mac users that are used to swallow other guys 'pride', so just stick to what you're best at: Sucking cock.
-- Linux user #369862
Scientific Linux 6 is already out. See http://ftp1.scientificlinux.org/linux/scientific/6.0/x86_64/os/sl-release-notes-6.0.html for their detailed release notes. If there was any doubt in your mind that the direct rebuild projects are unaffected by this move, there shouldn't be any longer.
It's pretty clear they're trying very hard this time around to stay in lock-step with upstream (what they call TUV and what CentOS calls PNAELV) and add fewer packages into the mix directly. They're also funded to do this work full-time by the US government, and since many universities and national labs rely on SL, it's not going away any time soon.
If you've never tried it before, I encourage you to do so. To quote the old tagline, it's already ready already.
Michael Jennings | HPC Systems Engineer, Lawrence Berkeley National Lab | Author, Eterm (eterm.org)
If you want scummy, look to companies like Oracle which just take, repackage, and rarely give back. They're the real problem, not RedHat.
RedHat's patches still get submitted upstream for inclusion in the main kernel, which very often does happen.
I have no sympathy whatsoever for leeches that were taking RedHat patches and rolling their own distributions without contributing enough back on their own.
I fail to see how this affects seperate distros like Debian, which aren't based on RedHat-patched source in the first place.
I do not fail; I succeed at finding out what does not work.
http://lwn.net/Articles/222773/. Red Hat plays very well with others. Part of the problem is the logistics, with Git and new Kernel development you're looking at literally thousands of source code patches (which would make for a completely unwieldy SPEC file) because Red Hat back ports stuff to keep a stable Kernel in the Enterprise Linux..
Take a look at Novell's "RHEL support" offering. It's turned out to be complete crap, repackaging RHEL packages and alleging to offer one-stop support for SuSE customers, and blaming any problems on RHEL to convince customers to switch to SuSE.
http://www.novell.com/promo/suse/free-30days-expanded-support.html
It's complete bait and switch.
oracle is funding btrfs development.
Do you even lift?
These aren't the 'roids you're looking for.
I'm really surprised that this comment was modded up. Oracle is responsible for btrfs (negating the "filesystems" argument), Novell was the catalyst for the modern linux composited desktop with compiz/Xgl (negating the X argument), and if I thought about it for more than 10 seconds, I'm sure I could come up with a shitload of other examples where these two companies that you've "cherrypicked" have been a driving force for good in the linux world. I do agree with your sentiment but, you sound bitter for these companies not having contributed to technologies that you don't realise you are using. But, most likely, the have. And in a big way. I'm all for hating companies like Oracle but, hate them for the right reasons.
If every distro is doing the same thing, this is not going to be very good for the future of Linux. Engineers at every distro are going to waste a lot time trying to figure what other distros had been patching, which part of the code had been changed while a specific issue was fixed, etc. Everyone is going to end up wasting a lot of time, and creating a lot of confusion.
Even though Linux distros are quite fragmented, but the current kernel development has been working quite well, because every distro is playing by the rule (more or less), which is quite transparent. Now, with this kind of one time big change by RH, even though you can still diff on all the source codes, it's not going to be easy to figure what has bee done (and why). And I think it's going to trigger other distros to behave similarly.
And it will be even harder for the users. As a user, if we have in-house-built applications that rely on specific version of a library or module, we might not want to have a giant patch on basically everything, we probably want only small, concise, specific patch for some critical security problems. I'm starting to wonder how are we going to manage that.
I somewhat agree. RHEL's pre-patched kernel doesn't affect upstream. If you want upstream patches broken up by time, checkout the kernel from its git repository & browse away... Hint: The commit messages describe what each group of changes addresses.
Of course, I still think its a shitty thing to do. What if Red Hat's upstream (Linux) made it harder for RHEL devs to support their custom selected kernel code... If it Red Hat suddenly couldn't pick and choose which Linux mainline patches to apply to their long-term-support releases because the commit logs were obliterated via rebase, I'm sure everyone would be singing a different toon -- You put the shoe on the other foot and suddenly it's bizzaro land?
It's not like RHEL writes the whole damn distro itself. The least they could do is make it as easy for downstream devs as their upstream makes it for them. To do otherwise, while not illegal, is a major dickhead move which I'll no longer be supporting with my hard earned dollars (or recommending others do either).
Again, that's not something you'd care about if you're a desktop end-user, but in a corporate IT environment it makes a difference.
Way to go RHEL team... Keep pissing people off for the sake of the almighty dollar -- It may come back to bite you in the ass someday...
That only gives you the patch broken up in space, not in time.
The idea is that Red Hat has patches for specific issues that are developed at different points in time. These patches may modify the same files as previous ones, or even the same blocks of code. By having all patches applied at once, the singular diff does not tell you which component of the patch fixed which issue.
This is really only relevant for providing commercial support.
The only "downstream" of RHEL that is significantly affected is Oracle, a company that rebuilds RHEL, sells it as their own "Unbreakable Linux", and then tells database customers that they really shouldn't run RHEL, they should run Unbreakable instead. A bunch of those customers run Oracle DB on RHEL from when Oracle was a Red Hat partner (before they started trying to poach the big DB customers). Oracle does much less for Linux (and Open Source in general) than Red Hat. Oracle throws a little bit of code over the wall when they have to, while Red Hat has bought other companies closed-source software and Open Sourced it.
I haven't looked yet (because I rarely need to see individual patches; I mostly just care about the end result), but Red Hat has said that customers will have access to the patch information, so cutting Red Hat out because they restrict that would be dumb (since as a customer you'd get it anyway). A lot of work in making the Linux kernel "enterprise-ready" has been (and continues to be) done by Red Hat.
Basically, Red Hat forks the kernel for each major RHEL release and then maintains it on their own. They backport patches from upstream as well as develop patches for their kernel (which they submit upstream). Do you think LibreOffice should be required to distribute every individual patch they've made to OpenOffice, or X.org vs. XFree86?
No jokes about "Begun, the Clone War has"? I'm so disappointed.
Fandroids hate facts.
The one that interests me the most (because it impacts me most directly) is XenServer. It's supposedly based on RedHat as well, and they do a degree of kernel hackery to get all their Xenery to work. I'd be curious to see where that will go, given that XenServer development isn't exactly what you'd call cutting-edge in many regards: Citrix seems to just cut and release, with little regard for many important things like documentation being up to date or full hardware support.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
I installed Oracle Linux 6 this week to test. Besides the blinding red color of everything, I was a bit annoyed to see how many times I saw the word "RedHat" in the installer and the boot process.. I mean, if your going to rebrand it, then freaking re-brand it!
What are we going to do tonight Brain?
If you round off their 2010 income numbers, subscription income totals to $639 million (85.3%), and training service income totals to $110 million (14.6%). That is all on page 40 of their 2010 Annual SEC (10-K) filing. The subscriptions had a 93% profit margin, and the training had a 36% profit margin this year. Which makes sense, I imagine training services cost quite a bit, you would probably have equipment and training material costs, as well as trainer's salaries. Then, at least some of the time, there would be travel and hotel costs incurred for the trainers themselves, anytime they are training groups.
According to page 48 of the same report, they spent $272 on sales and marketing, which the fancy training mailer pamphlets would fall under. However, that would also include expenses from sponsoring Open Source conferences under the same line item (its not all wasted on those fancy pamphlets).
Research and Development I imagine covers salaries for Kernel and subsystem developers. R&D costs total $148 million. Administrative costs were $104 million. According to the 10-K report, they have 3,000 employees globally.
Total operating expense for 2010 was $534 million, once you have tacked on taxes the Net income comes to $87 million.
There is a lot of boring stuff in SEC filings, most always something interesting to learn from them though. If you really want to find out what a company is all about, there are some interesting details, a lot of it is in there. It explains in brief detail what each line item in the Balance Sheets and Income Statements actually mean in mostly plain English. Plus, the executive summary gives you some insight into their management's frame of mind, business model, and strategies.
/^([Ss]ame [Bb]at (time, |channel.)){2}$/
Red Hat has said that customers will have access to the patch information
So what's to stop Oracle from becoming a customer? :)
shhhhhhh you'll mess with slashdot group think
I think the bit of Oracle Linux which bemused me was the fact that installing Oracle 11g on it is is still non-trivial; it requires you to install a bunch of packages and tweak kernel settings. If you're going to distribute your own brand of Linux, you could at least have an installer option for "This is going to be an Oracle RDBMS server, please install everything I need and configure the kernel as needed". Giving you a script to run as root part way through the RDBMS install process doesn't really cut it.
Yeah, I had a sig once; I got bored of it.
Redhat is allowed to do exactly what they are doing. Nothing in the GPL requires them to make their changes available upstream (although they usually do), it requires them to make any changes available to their customers. They still release their changes to the kernel source code, but they changed the way those changes are distributed to their customers.
They used to make these changes available as a patch set that could be applied to the vanilla source from kernel.org. "Enhancers" like Oracle and others would take the vanilla source, cherry pick the patches that they wanted to apply out of Redhat's patch set, and compile the kernel, possibly adding in their own patches. Now Redhat is making the changes available in a single large pre-patched tarball, which means that if Oracle doesn't want to apply all of the patches, then they have to hunt down the changes themselves which is more time consuming and error-prone.
Say Redhat comes up with a patch that tweaks the filesystem code in a way that in some cases makes an Oracle DB 10% slower. In the past, Oracle would just apply all RH patches except that one. Now they have to take the vanilla source, diff it against Redhat's patched source, hunt down all the changes related to that filesystem patch, back those changes out manually, and hope that they got it right.
If only "common" sense was actually that common...
To the other guy who responded to this comment: If your DBA has to call Oracle support to figure out how to install it on Linux then you need a new DBA. It takes 10 minutes to prep a RedHat OS to install Oracle, its not complicated.
As for Oracle Linux, there is a package you can download which will install the pre-reqs called oracle-validated. From the links below:
Named after, and derived from Validated Configurations, oracle-validated also creates an oracle OS user and an oinstall and dba group. Kernel parameters are also set properly, ensuring that the Oracle Universal Installer will proceed without complaints. Very nice!
http://blogs.oracle.com/sergio/2008/08/revisiting_the_oraclevalidated_1.html
http://blogs.oracle.com/AlejandroVargas/2008/10/the_oraclevalidated_rpm_is_ava.html
Pretty simple.
"Thanks to the remote control I have the attention span of a gerbil."
The Linux kernel doesn't belong to you or me or "the community", it belongs to the copyright holders, with Linus as the arbiter of their rights. Redhat isn't closing the source or keeping anything secret, you've misunderstood both how Redhat works and also how the GPL works.
Nothing in the GPL says that you can't make money directly from GPL'ed software. You're free to take any GPL'ed software, compile it, put it on a CD, and sell it as-is. In fact, that is how Redhat and a lot of others got started. What you can't do is take credit yourself for all of this software (you must attribute the copyright holders) and you can't provide binaries without providing the source as well, including your changes. You also pass along the same rights you have when selling GPL'ed software, which is why CentOS and Scientific Linux can download the source RPM's for RHEL from Redhat and run them through a build script that changes the Redhat logo to something else, builds all of the free bits (about 99% of the distro).
Actually, Redhat could go one step further, and instead of providing the source RPM's to everyone, they could just put them on the DVD with the OS and not make them freely downloadable. They only have to provide source to their customers, not the general public. They know the anyone could buy a DVD and repost the source RPM's, so they just go ahead and make them available to everyone.
If only "common" sense was actually that common...