Red Hat: 'Yes, we undercut Oracle with hidden Linux patches' Red Hat has changed the way it distributes Enterprise Linux kernel code in an effort to prevent Oracle and Novell from stealing its customers, making it more difficult for these competitors to understand which patches have been applied where. Some have speculated that the change is designed to make it harder for Oracle as well …
It's easy to argue that overall Redhat are good for future of linux. But I am sorry to say they are suffering because of a potential folly in GPL: It's very easy for a big giant to eat into a niche created by a smart but small innovator whose entire product is open source, whether the smaller guy is a willing partner or not. Redhat's patches and products are well understood by competition and they can easily eat into red hat's accounts. Also, redhat can't easily do direct-to-customer patch delivery because of GPL's terms.
OTOH, even if redhat had money, could they do that to Oracle customers ? Most likely no, because redhat wouldn't have the same level of expertise with the Oracle's software or understand the patches in the same great detail. Most 3rd party service providers depend on a revenue share agreement with the original product vendor to deliver patches. (Eg: if IBM services arm is installing patches on customer's Sun/Oracle box, it's because their agreement with Sun/Oracle covers it).
Lot of Linux distros are simple re-branded redhats. They make money by investing on 3 unbilled engineers worth of money where as redhat has a 300-400 engineer staff which is part of R&D and not billed to any customers.
I think original purpose of GPL - **why I like it**- it that it allowed a customer to tweak the product they bought as per their whims and fancy. Things are a lot different 30 years down the line.
"Also, redhat can't easily do direct-to-customer patch delivery because of GPL's terms."
Wrong. GPL allows that. By GPL, you only need to provide source to customers (while customers might chose to pass along). Red Hat does this. Red hat in fact provide full source to everyone, except now they only provide knowledge about patches (documentation) to customers.
Before this move, all was up for grabs to Oracle and every patch was marked with number and it came with corresponding explanation and documentation that is easy to understand even to non-programers. Oracle just hired bunch of monkeys and they were offering support just based on this documentation, without any real expertise. They didn't write their own documentation, and they "unbreakable kernel" is just stuffed with crap from staging tree (which is called "crap" by Linux devs; low quality code goes there until it is cleaned up enough to be good for mainline).
But now, Red Hat's knowledge base exists only for RH customers (and I see they added some stuff that are very convenient). Oracle will not get it anymore, they will get full sources like everyone else which is off course readable and clean but Oracle will need experts to see what is new and what it does. In effect Oracle will need to hire real devs and understand what they are supporting. They will need to write their own documentation. They will need to maintain their own bug database. And they will need to really *support* customers and not just claim they are cheaper than Red Hat while blindly using Red Hat's instruction manual when someone calls them for support.
And when they do all this and really put some investment behind their OEL, they will either not be so cheap, or they'll kiss goodbye to profits and say hello to loses.
No more free lunch for Larry. Smart move by Red Hat.
And "crap" being 99% stability patches that will pop up in RHEL a year later after "QA".
RHEL6 / OEL6 will seem fresh for 1-2 years now, and after that their users will again go from bug report to bug report looking at things that were patched years ago in mainline, while their RHEL boxes still crash from it.
This exactly the reason I am sticking with Windows Servers, they work and they work very well. Red had and the rest of the Linux crowd are trying to make money by dishonesty it seems, is that by making something wrong on purpose so you need their support. Reading this it won't surprise me. And I don't quite get it, I never had to ask for any support with Windows software from Microsoft directly, windows forums are great. Why do people need support directly from Redhat or Oracle for that matter. I can only think there is something wrong with their software.
It doesn't seem a very appetising place to eat basically.
I think you might have to go back to your Quick and Easy Free and Open Source for Microsoft Engineers book. It doesn't say "Free software is about hacking together a mess of code in order to extract ever greater amounts of money from support". It says something along the lines of "The economics of code distribution, like most other creative works, has fallen to zero. If you still would like to earn money you can do a couple of things: a) lock your product up and milk your customers like cattle (Microsoft, Oracle, Apple), b) Get paid for performing code creation (Independent SMEs) or c) Get paid for supporting the software in an business context, with a note that you should probably push a bit of that money into development in order to keep your customers."
Sometimes I think Microsoft people learn about FOSS on the back of cornflake packets.
> Windows Servers, they work and they work very well
If that were true, my bank manager would be very upset.
Windows servers need much more coddling. Linux Just Works.
> Red had and the rest of the Linux crowd are trying to make money by dishonesty
That is entirely untrue. They are extremely honest.
> by making something wrong on purpose so you need their support.
This is not happening. No-one is making anything "wrong on purpose". You appear to have read a different article to everyone else.
What RH are doing is ceasing to lay out in enormous detail every single patch to the sources that they make, rolling them up into is single source tarball instead. If you think you'll get something like that out of Microsoft, you're in cloud cuckoo land.
The difficulty is that RH are now offering less than they previously did, not that what they're offering now isn't still rather wonderful.
> I never had to ask for any support with Windows software from Microsoft directly
Big deal. If you don't want support - don't buy it. But others *do* want it - and the market is there for exactly that. It's not a compulsory charge, it's an offer.
> Why do people need support directly from Redhat
They don't. But if they want it, it's there.
> I can only think there is something wrong with their software.
You have clearly never worked in a commercial environment. How are the GCSEs going?
Vic.
@Vic
Red Hat makes around 800 million in revenues per year. How much of this is not support then? Thinking as an IT customer why do I need support (unless I am stupid to throw my money away). Maybe because I don't feel very confident with the software, or there isn't enough documentation, either directly from the company or from web forums or I am charitable!. I would never get support if I know I can fix it myself in the unlikely case something is wrong. Any explanations why a company would need support if they are looking after their money?
> How much of this is not support then?
It's all support.
> Thinking as an IT customer why do I need support
You don't *need* support. You could decide to use community knowledge on the web and do it yourself - just like you intimated you would with Windows.
But as a commercial entity, that might not make any sense. You might decide it is cheaper and less risky to buy support from a specialist vendor than to try to cover everything in-house.
> (unless I am stupid to throw my money away).
See, it's comments like that that convince me you've never seen a commercial environment.
Users want support. That might be in-house, or it might be bought in. But leaving a bunch of users alone to support themselves is a recipe for disaster except in an environment where all users are sufficiently skilled to be support people if they so chose[1].
So support is a fact of life, whatever OS you're on. I have *far* more Windows support customers than I do Linux support customers, despite the fact that I am targeting the latter.
> Maybe because I don't feel very confident with the software, or there isn't enough
> documentation, either directly from the company or from web forums or I am charitable!.
No. It's because management want to make sure that, should anything tricky come along, the entire company won't be stuck twiddling its thumbs while someone investigates the problem.
A huge number of support contracts are never actually used...
> I would never get support if I know I can fix it myself in the unlikely case something is wrong.
Good for you. But you won't be managing any significant IT resources in the near future. When hundreds of engineers require the IT to work so that they can do anything, every hour of downtime costs you a *lot* of money. Having to trawl through the link-farms on Google to find an obscure fix to a gnarly problem is not a cost-effective way of providing that support function. So you either train up your in-house support staff to be experts in every package they have to see, or you train them to be good enough to deal with the bulk of the workload, and you have a specialist support company on contract to pick up the phone. Guess which of these makes commercial sense once the application count starts to rise...
You'll notice that the above argument doesn't discriminate between OSes, and doesn't mention the quality of the code or its documentation; it's a simple business case that says you mitigate risk by buying support.
> Any explanations why a company would need support if they are looking after their money?
Plenty. You'll see it in action once you start seeing IT in industry.
Vic.
[1] Even then, it will often go horribly wrong because you get competing policies.
Quoteth: Windows servers need much more coddling. Linux Just Works.
Er, not exactly. Windows and Linux have been neck and neck as far as OS stability for years. The main issue you run into when it comes to stability is the application running on top of it.
Now sure, you can make the case that developing on windows is faster and looser than on linux, hence there are more flaws. But after the decade I've been in this industry, I'd say both OSes suffer from proprietary vendor oddness. Both are susceptible to stability issues due to application level glitches.
I run Windows and Open SuSE servers. Both just work, but I find the SuSE ones need a lot less attention than the Windows ones and take up a lot less of my time. They probably need a bit more knowledge to get started, but once you know what you are doing, you can ssh in and administer things much more quickly using the command line than you can with the nice easy-to-use graphical tools that Microsoft provides over rdp. Of course SuSE provides the nice easy-to-use graphical tools as well and you can use them over nx.
So all this talk means they don't tell you which patches they have added to the stock Linux kernel? You'll have to try and figure out yourself from the mangled up source code?
I think this is bad for everyone, not just the leeches. I like knowing what extra bits goes in. If this is true I'll make sure we really reconsider continuing our two support licences when they come near expiration date. Never actually used much support from Redhat apart from updates anyway so I think we'll survive with CentOS.
I can understand they need the cash but this is not what I expect from a Linux distribution. Maybe they regret not taking BSD, at least they could be going closed source with it.
Whilst we're a RH customer and I'm a big RH fanboi, I'm still left a bit unhappy about this new approach. We've already discussed it with RH and they have assured us - as customers - we can look at the source any time we like, that they will explain any and all patches and help us determine whether a patch is good for us or not. All this we have come to expect from the excellent RH support staff and is the reason we chose RH in the first place - the support. By trying to edge out Oracle and Novell, RH is basically trying to tie up the support market, which is their buisness model. I can understand why they would want to do this, it makes commercial sense, but it still feels like it goes against the whole spirit of Linux (not a very good business argument, I know), and I also worry that it reduces the ability of the experienced people in the community to look at a RH patch and spot an error before it gets compiled into the kernel. Whilst I'm sure RH are so good at their job that's unlikley to happen much, it still worries me.
I dont' read all the kernel patches that's why this is bad news for me.
Previously the individual patch files had a reasoning behind each one, which is what I saw. Now all I get is a long list of diff output with no context at all.
Sure it's still open source, but much less so and if you don't have the resources of a large company to go through then it might as well be closed.
So yeah downvote me, I've been using Linux since kernel 0.98.1 and I'm disgusted, although not surprised, by this "new way". Whatever's next really, redhat exclusive binary blobs? All seems fair in the "fight" against Oracle...
Oracle would no longer be able to freeload that's all.
However the investment not to freeload is so marginal that it is not even worth discussing. We are talking what? half an M per annum or so? And that half an M will be paying back because it will now have a kernel development and support team of its own. It can in turn use that to improve its own patches and its own distro's tree as well. Which in tun is not in RedHat's favour. Forcing your competitor to commit resources to something that actually improves their offering in the long run is not a good idea.
"""Forcing your competitor to commit resources to something that actually improves their offering in the long run is not a good idea."""
But then Oracle's kernel development team would also be pushing some stuff back upstream, which should in turn benefit Red Hat, as well as the rest of us. The point is that investment in Linux (theoretically) benefits everyone who uses it, so fair play to Red Hat for trying to force a bit more of it?
> You trust them to do that, do you?
They don't have a whole lot of choice. The licence requires them to release their changes under GPL.
Whether they submit any such patches upstream is irrelevant; they *have* to release them downstream (or lose their ability to ship the code at all), and anyone downstream has the right to redistribute under the GPL (e.g. by submitting the patches back to the mainstream development).
The exact definition of "downstream" depends slightly on the method by which source distribution is achieved, but since the code is freely distributable under the GPL, it tends towards being "everyone who wants it".
Vic.
[Waiting for more downvotes to pour in because I've said something that makes FOSS look reasonable again]
We use some other Oracle products which have been acquired by the giant... We usually find ourselves sorting out production support issues days or weeks before Oracle support get back to us with their useless mumbo-jumbo. Oracle is starting to look like some kind of monger willing to sell just about anything. For those contemplating Oracle support, don't... Stick to the REAL support from Redhat.
I am a self-employed tech in the "support business", I do this to support my family. I quite legitimately paid for a Red Hat Linux Engineers course, studied my ass off, and passed the exam. I was then able to support linux in the field, which finally enabled me to start paying off my credit cards and house and car loans.
Now that Red Hat has decided to covertly introduce flaws in their system that prevents anybody else from supporting Red Hat, not only is my RHCE useless, but I will no longer be able to support my family.
I think Red Hat should be forced to compensate every RHCE for the invalidation of the certificate as well as loss of income.
Thanks Dead Rat.
Spare us the defenseless widow with children spiel!
How are Red Hat Sharp Practices [tm] going to impede your income?
Maybe you are confused about what a RHCE is all about. It means you can handle a Red Hat System. It doesn't mean you can do all the support that comes with a Red Hat license yourself. If in doubt, ask for Red Hat support, which is presumably being paid for by your customer.
Ta!
> Now that Red Hat has decided to covertly introduce flaws in their system
It has done no such thing.
This change merely wraps up all the individual patches into one super-patch, and they no longer put all the info into the changelog. It's the same code as it ever was - just without all the explanation RH have historically put into their releases.
It's a shame RH has done this, but I can see their point.
Vic.
You can still support and maintain just about any other distribution with ease and to transfer your
family to another distribution should be a doddle. In fact maintaining paid for RH installations will still be really easy.
Now consider if you'd done the same thing with MS - you'd have had to do 5 or 6 courses every couple of years just to work out where they'd hidden your particular subset of experience in the menu this time.
I happen to be an RHCE, and I don't see how this move could possibly hurt me. If anything, it will make more demand for RHCEs.
I think you don't even know what RHCE is and what it means, and this is lame attempt to throw dirt on RH. Stop embarrassing yourself. Go debug your BSoDs instead.
"....I think Red Hat should be forced to compensate every RHCE for the invalidation of the certificate...." I thought the RHCE was aimed at certifying you to install and configure standard RH releases and then working as a sysadmin in conjunction with RH support, not a certification in how to undercut RH's support. Try reading the small print, maybe?
I support this decision of Red Hat and I won't insult it by calling it pragmatism. It is smart move. Not pragmatism.
Pragmatism is worst dogma ever. These days, pragmatism means being a an idiot and a jerk ,and backstabbing everyone. And doing what Oracle does. Pragmatism is evil. Pragmatic decision for Red Hat would be to let Oracle acquire them. Or go closed source.
Maybe pragmatism before had some other meaning, but idiots disfigured the meaning through common usage of the word. They used it to justify every evil they do. Now it is pretty much same as quislingism.
So down with pragmatism.
RHEL distributions are long-lived, and the kernel shape is the same at the end of life as it was at launch - so anything RHEL4-based started with a kernel that looked like 2.6.9, and still does to this day. But they are very far from obsolete - RH back-ports much new kernel development into these old frames to give something that is updated and fresh, whilst maintaining compatibility with what went before. That's a Good Thing(tm).
However, if you want to find out if a certain kernel incorporates a certain feature, you have to go through the patchset. The availability of the changelog, with patch documentation, is a boon here. Red Hat's removing it will be a royal pain in the arse to those of us who use their code.
I can't blame them. They are operating well within the GPL, and give what Oracle (in particular) has been doing, I can't say I'd have done anything differently. But it is properly annoying...
Vic.
I think I'll just buy red hat's corporate spin for once. Not because I like them, or their product (the memory of 2.95.4 still smarts, yes, I know that's a long time ago). More because the CentOs guys don't seem to care, who're pretty much the closest to the red hat product you can get without working for, or being red hat. The fact I had a couple beers with them and think they're cool even if I care nothing for either product has nothing to do with it, honest. *cough*
Anyway. Red Hat is a corporate player and found themselves getting undercut by bigger guns with less brains (as in, quality support) parasiting on their efforts, so they pretty much had to do something. This something is about as elegant as it gets, given the circumstances. I really can't blame them for, you know, making sure they don't get sucked dry by a cheapskate competitor.
For Linux virus writers - and other "security professionals" (well, they are, in a way) - who can make a good living exploring and exploiting unpatched vulnerabilities in corporate Linux installations.
"He insists that the change does not violate either the letter or the spirit of RHEL's GPL open source license."
Like hell it does! If you aren't releasing source code in useable form, then you aren't releasing source code.
Maybe I should just stick to using the GParted Live CD from now on...
> If you aren't releasing source code in useable form, then you aren't releasing source code.
They *are* releasing source in a usable form.
What they are no longer doing is breaking it down into a bazillion tiny patches, with explanation for each and every one of them.
But I suspect someone will.
Vic.
"Like hell it does! If you aren't releasing source code in useable form, then you aren't releasing source code."
They still release the source code.
All of the source code they releases compiles and runs.
Anyone with the relevant programming capabilities can read it and work with it.
AFAIK, nowhere in either the text or the mission of the GPL does it require that patches be maintaned separately from major release code.
So exactly what are your criteria for "useable" code that RH is now failing to meet? Where in the GPL are your criteria espoused?
"If you aren't releasing source code in useable form, then you aren't releasing source code"
As a long time developer and occasional contributor to a few FOSS projects, none of them in the kernel, I have to ask this question once and for all: why releasing a simple source code file is not usable?
Last time I contributed code to a FOSS project, I just downloaded the sources, examined them, changed whatever I wanted, created the patch and submitted to the maintainers.
I've a very hard time believing that you need the individual patch history to the code to be usable for development. Perhaps Linus or some other genius is capable of directly creating patches instead of working on the source files. Even if you're a developer of such caliber, you are going to test by applying the patch to the source and recompiling. So by no means a list of patches is usable for software development.
The history with support is different. There is this common practice called "bisecting", that takes a source code tree and applies patches one by one, testing for the existence of a bug after applying each. It is a faster way of finding where the problem is.
So Red Hat is removing the ability to bisect individual changes to the kernel. So your support becomes more difficult, but by no means kernel development is more difficult. Guess what? Red Hat lives and pays all the kernel, x, Gnome, etc, developers by selling.... support.
It's not nice for others to piggyback on the work created by Red Hat and make customers pay for what they've got for free. Bad, Oracle.
It's not nice, it's nasty, to brand and sell something "Unbreakable" simply by taking the works of others and package it under a new name. Bad, Oracle.
The free lunch is over, Larry, now it's time to explain to your "Unbreakable" customers that you were simply using other people work without paying for it.
is to enable someone other than the source code author to compile, debug, maintain the software - subject to legalities such as copyright. I maean, I could publish an entire program of my own and forbid it being used by anyone. (Diifficult to enforce, of course.)
And the absolute entire point of the GPLs is that your contributions and additions to a GPL work are not your exclusive property. They are surrendered to the community of users and potential users. It's what the GPL is for.
Let's have independent security researchers publish information about Red Hat vulnerabilities the same way that Red Hat are publishing patches, and see how Red Hat likes it then. All right, this is dangerously close to treating hacking as legitimate, and I don't want to do that. But I think that, while wrong, it wouldn't be unfair.
is what, exactly?
1. Red Hat is still releasing their source code in compileable, debuggable, maintainable form. They're still giving the code back to the community. The only difference with this policy change is that they're rolling patches into the main code tree rather than applying them separately.
2. Actually, independent security researchers publish information about vulnerabilities in different forms depending on the audience. They generally provide the vendor with an overview of the issue and a tool and/or the source code for a tool that will exploit the vulnerability. This is similar in scope to what Red Hat is doing.
I ask again: what EXACTLY are YOUR criteria for useability which you believe Red Hat are violating with this policy change? How will this impinge on your ability to use their patches? How do you use their patches, anyway?
> is to enable someone other than the source code author to compile, debug, maintain the software
Yes. And you can still do that. The source code is published in its entirety.
> subject to legalities such as copyright
Well, that's the real point of Free Software - while the copyright stays with the author, a licence to use and redistribute comes with the code - and such redistribution will leave the recipient with an identical licence to use and redistribute. So al song as you stick to the licence conditions - which is really easy - you can pass the code around to your heart's content.
> the absolute entire point of the GPLs is that your contributions and additions to
> a GPL work are not your exclusive property.
That is incorrect.
Any code you write *is* your property. That's how copyright works.
What the GPL does is to ensure that anyone distributing variants of your code has to pass on the same rights as he got - so others (including the original authors) can get their hands on the source and re-use it.
> They are surrendered to the community
No they are not. This is critical; the GPL does *not* require you to surrender any copyrights.
> Let's have independent security researchers publish information about Red Hat vulnerabilities
Errr - they already do.
> see how Red Hat likes it then
Red Hat would like it very much, I should imagine. They already publish the bugs they know about in public. It's called Bugzilla...
Vic.
If you are into self-patched kernels, then shouldn't you be running Fedora not RHEL as your base? (Or a non-Red-Hat distro such as Ubuntu).
RHEL (and Centos) are about long-term stability. If it works today, you can be pretty sure it'll work in five years time, with little maintenance other than applying the security updates. People who want RHEL to be more like Ubuntu don't get this. They'd be better off switching to a distribution more to their taste, rather than complaining. Linux is NOT a Windoze monoculture!
CentOS converts = potential 100B Market cap.
Why???
8M CentOS systems.
Avg price per RHEL subscription/system $600 - just a guess.
20% of current CentOS systems converted to a RHEL Sub =1,600,000
1,600,000 x $600 = $960,000,000 /yr
Oracle is a problem but not to the same extent of CentOS, IMO
This decision creates huge upside for Red Hat shareholders but goes against the spirit of the GPL....
> CentOS converts = potential 100B Market cap.
No. CentOS users are not, in the main, candidates for conversion to RHEL. The vast majority of them are well aware of the RHEL offering, and have chosen to take a route that provides them with similar software but no support contract.
So the market cap is closer to being a few tens of thousands than the 100B you guesstimate.
> 20% of current CentOS systems converted to a RHEL Sub =1,600,000
That assumption is your mistake; you dramatically over-estimate the potential.
> Oracle is a problem but not to the same extent of CentOS, IMO
That's because you don't understand Free Software. RH are not selling code, they're selling support. CentOS is not their competitor - it is what gets people used to using RH-style systems. It is a feeder. The existence of CentOS - and other rebuilds - generates revenue for Red Hat, rather than taking it away.
Red Hat know this. That's why RH employees regularly help out anyone who is trying to rebuild their code. RH effectively sponsors all such rebuilds to a small extent. They appear happy to do so - and they are making a vast amount of money whilst following that policy.
> This decision creates huge upside for Red Hat shareholders
This decision makes no difference to RH shareholders. It's a small tweak to the way they ship code. It won't affect CentOS or any other clone-type rebuilders. It will only affect people who want to build something based on RHEL, but differing in some important fashion - which is the sort of thing I tend to do. It makes more work for me, but RH's shareholders have no reason to care about that - it really won't affect them in any way.
> but goes against the spirit of the GPL....
No, it doesn't.
RH are releasing all their source just as the GPL requires them to. What they are *not* releasing is all the annotation they've built up in their VC repository. That is unfortunate from my perspective - and I hope they change their minds when they see this having no real impact on Oracle - but it's absolutely fine as far as the GPL goes. The GPL entitles users to the source used to build their binaries, not to every thought that has gone through the developers' heads.
Vic.
Yes- we're one of the Centos users. If CentOS went away we'd not go Red Hat Enterprise. We can't afford it, and we don't require support.
We'd probably move to Ubuntu. (Fedora not long-term stable, Scientific Linux would be likely to follow in Centos's footsteps). All hypothetical at present. CentOS don't seem to be about to give up, and CentOS 5 has a few years left in it yet.
I see a number of complaints that RH is not acting in the spirit of the GPL, maybe that's true. I feel, however, that people are forgetting just what Red Hat means to FOSS and Linux.
RH has gone out of their way for years to be a great contributer and promoter of open source and linux. They have gone above and beyond all that is required by the GPL to contribute their developments to the community at large. They built a great business on this, through licensing and support costs, and even with their licensing model, they've still gone out of their way to make RH fully available to anyone who wants it. Now, they seen a trend where their efforts are being taken advantage of, and it's hurting their business. RH took appropriate actions to counter this. There is nothing in the GPL that says you have to provide a detailed change log, and documentation. I think you'll find that most FOSS projects are severely lacking in documentation. RH took action to try and stop competitors from hurting their business through some shady means. RH has acted very much in the spirit of the GPL, but they are hurting because of others who are not, and who are instead trying to take advantage of RH's openness and good participation. They have been put in a position where they are forced to stop being so open for the good of their company, and the action they've taken falls in line with just about every other FOSS project out there.
How are they being so terrible? The criticism is akin to complaining because your neighbor stopped mowing your lawn and shoveling your sidewalks for you.
@pan2008, you've got to be kidding me. Regrading this specific issue, Microsoft provides you with Windows kernel source code, source code for each patch and a patch-by-patch description? Oh, you mean they don't? How about that. If you'd RTFA that's all that's changing here, Redhat is now apparently releasing the full source for each kernel release, instead of a "stock" kernel and a seperate item-by-item set of patches with description of exactly what each patch does. And regarding support, a lot of people *don't* need support, they use CentOS. But I'm sure for a lot who do use Redhat or Oracle support, it's the same reason for a lot of support contracts -- some companies want everything they use to have a support contract attached to it.
Regrading Redhat's move. Well, I wouldn't sweat it. The full source is still there, there really is no obligation to keep a full patch history by either letter or spirit of the GPL. It seems to me Oracle really forced their hand. Finally, if some RHEL user relies on some kernel behavior odd enough they are afraid it'll be patched out, I'm sure Redhat still has patch info within the company and RHEL support can tell.
Guess ho-hum response to RH's move explains why Larry spent $7B on Sun rather than $2B on RH. Partly, anyway. I do wonder what Larry really wants from Google. Seems keen to thump them with the Java stick. Surely not as crude as chasing "Android tax", or... a favor for Steve.
RH haven't much to worry about the next few years really, there are enough SAPs to go around to keep them in business, but many of the juicier support-paying drones running Larry's software on RH - they'll go away once he starts 'squeezing'. Business software buyers and their attending court fools the DBAs will run to Larry - faster than they ran to Bill back when they gifted the office desktop to him a generation ago, back when they were mere junior accountants and snotty little PC admins respectively getting all worked up about popping a spreadsheet into a Word doc.
Big Brother, coz the pic looks a bit like Larry, and there isn't a "asteroid impact required" icon :(
I seem to remember lots of tut tutting about this sort of behaviour when the aledged chant in the corridors of MS was "DOS isn't done 'til Lotus wont run"
Once again we see ideology (Software should be Free!!!) coming up against cold hard reality (cash).
You have to sell the OS and hope that you get to support it as well, not give it away free but hobble it so that others can't offer support.
This is just ridiculous.
> I seem to remember lots of tut tutting about this sort of behaviour
No you didn't.
> when the aledged chant in the corridors of MS was "DOS isn't done 'til Lotus wont run"
That isn't even close to what is happening here.
Red Hat are *not* breaking any code. They are *not* preventing anything from running on top of the OS. They are *not* trying to influence a customer's choice of applications.
All they are doing is releasing their source code - as much of it as you want - in a single tarball. This is a step down from the previous situation, where they released a "vanilla" tarball from upstream together with a multitude of patches, with full documentation for every one of those patches.
So Red Hat is not quite as good as it used to be - but trying to claim that they are somehow deliberately breaking their code is simply not true.
> Once again we see ideology (Software should be Free!!!) coming up against cold hard reality
> (cash).
And the ideology wins. The software remains Free - as it must do under the licence. All that has changed is that Red Hat is giving away slightly less of the documentation of the source code that it has accrued.
> You have to sell the OS and hope that you get to support it as well, not give it away free but
> hobble it so that others can't offer support.
No. Red Hat demonstrates that to be incorrect - they *are* giving it away and making their money from support. They *are not* hobbling it. You or I could offer support for RH's products, if we chose to do so. Indeed, if we don't change the OS in any meaningful way, it is no harder to do that now than it ever was.
What is a little harder - and, IMO, not so much harder that this will actually make much difference - is to derive something from RHEL that is different in some important fashion. The annotations of which code has been back-ported to older kernels, for example, is no longer there - so we've got to go and look at the code to find out. This is a minor annoyance, not a significant issue.
> This is just ridiculous.
What you're alleging is certainly ridiculous - but then no-one has done it, so I don't really see your problem.
Vic.
Contrary to your article, a big proportion of Red Hat's staff don't see CentOS as an economic threat at all. Rather CentOS is something they want to encourage --- a hassle-free way to get educators hobbyists and enterprise skunkworks projects to experience RHEL without causing support issues for Red Hat Inc. The benefit of the wide availability of Red Hat skills pays off in increased support contracts. Sure there's some revenue leakage from small business -- but Red Hat Inc are a support business and the profits from those customers from selling support are not large. That's probably more than compensated by enterprise skunkworks projects moving into widespread production and seeking support contracts.
We're one organisation that is looking to abandon Oracle (Sun) for Red Hat when the next hardware is due for renewal.
This attitude is a very black mark in the book against Red Hat.
After a long time spent rebelling against closed markets and locked in solutions, this isn't going to win them any kudos in my book.
We've got equipment from one manufacturer and, to be honest, their support sucks, big time. They're an international player and what they did to their engineering force and contracts a few years ago really wrecked the support angle. What was in the can certainly wasn't written on the tin.
So we built a relationship with another company; a company which we have relied on for a good while and we're happy with their service and value for money. Any solution which threatens that long term support relationship is automatically going to get marked down as a significant step in to the unknown.
Deliberately handicapping such a relationship in order to keep business flowing in the direction of Red Hat is a massive no-no.
We run RHEL at work and I have a personal license of my own for home, even though I actually run CentOS on all my test machines there. For me this isn't a really big deal, because I'm using the centosplus kernel anyway. It *will* make things harder on the CentOS guys, and that's regrettable because they really do provide a tremendous service to the FOSS community. But if this change helps Red Hat survive, then I'm going to have to support it -- because as someone else mentioned *Red Hat* is the one who has invested in paying the salaries of hundreds of engineers who contribute back to FOSS every damn day. They're a resource I don't think we can afford to lose.
Of course I'll have to eat those words if RHAT winds up selling out to ORCL or another big player that then leeches off open source until there's nothing left to save.
It's definitely in Redhat's medium and long term interests to contribute code back upstream and encourage its adoption. The alternative is the risk of divergence in kernel development, which would be a disaster. As I see it this is only, and precisely, about screwing Oracle in the short term. It would only take a couple of months of patch lag to make them look inferior. If the Oracle parasites are slightly behind then they're less able to leech off the development and knowhow Redhat continually pushes into their product.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
