Red Hat Stops Shipping Kernel Changes as Patches 184
mvar writes to point out a report from h-online about the Red Hat
kernel source controversy. From the article: "Red Hat has changed
the way it ships the source code for the Linux kernel. Previously, it
was released as a standard kernel with a collection of patches which
could be applied to create the source code of the kernel Red Hat
used. Now though, the company ships
a tarball of the source code with the patches already
applied. This change, noted by Maxillian Attems and
LWN.net, appears to be aimed at Oracle, who like others, repackage
Red Hat's source as the basis for its Unbreakable Linux. Although
targeted at Oracle, the changes will make work harder for
distributions such as CentOS."
I don't see the problem (Score:2, Insightful)
Did they stop shipping diff too?
Re:I don't see the problem (Score:3, Informative)
You can obviously find out the overall difference, but now Red Hat no longer provides either a git tree or split-out patches for each change, which makes it harder to figure out what individual changes they've made to the kernel.
Re:I don't see the problem (Score:2)
How does this matter for CentOS who wants to be exactly like Red Hat minus the trademarks? Wouldn't they want to use the same exact source and not pick and choose patches?
Re:I don't see the problem (Score:2)
Wouldn't they want to use the same exact source and not pick and choose patches?
Except where Red Hat put their logos and trademarks. Now instead of searching the patches for those, they need to search the entire patched source.
No, just search the diff (Score:2)
Re:I don't see the problem (Score:2)
If there are trademarks in the kernel that need to be removed then this is a good change for CentOS. They would need to search BOTH the kernel source AND the patches when they were separate, now they only need to search the kernel source.
Re:I don't see the problem (Score:2)
Re:I don't see the problem (Score:2)
Ah, okay, that makes sense.
Re:I don't see the problem (Score:2)
Re:I don't see the problem (Score:2)
Okay so if a distributor writes a tool to incorporate their trademark into every source file, doing it so that the trademark could not be easily identified or removed, would they have created a propitiatory source tree?
Re:I don't see the problem (Score:2)
Their most recent release (4.9) was two days ago (and the previous major release of 5.5 was 9 months before that), and it's used on 30% of all Linux webservers. I'd say that makes it pretty relevant. Sure, they're a bit late on the release of 6.0, but with more than a few other enterprise Linux distros working on two year release cycles, I don't think that a four month wait for the latest bleeding edge is really such a big deal; users of the 4.x and 5.x releases are still getting the latest releases on time.
Re:I don't see the problem (Score:5, Insightful)
Redhat repackages projects from all over the community to make its OS, adding in their own contributions and doing QA. It's not entirely theirs. They know that lone geeks and smaller shops are not their revenue source; they'll get most of their funds from larger businesses that in another world would be Solaris or HP-UX users.
It's not a "cheap knockoff" or "hacked" when all that's changed is to swap out some logos and stuff. Redhat's efforts only work because they coexist with the community that writes the software. If this is "slowly killing the company", it's been dying from its birth. It has survived so far in this environment, in symbiosis with everyone else. Sure, it's different than how things work in other parts of the industry, but that doesn't make it broken.
Linux companies are not a baseball team, and they're not individually meant to grow into huge empires. They're based, in the end, on broad efforts of the community. When they can make a moderate profit and push Linux, great! However, it's in our interest that should they ever misbehave, they can be shunned and will feel pain or die. They should be wearing our leash, not the other way around. If you like wearing the leash of some commercial software company, go for it.
Re:I don't see the problem (Score:5, Insightful)
30% of all webservers? Sheesh, and folks wonder why Linux never gets anywhere. I mean here you have a company that sinks serious money into R&D and improvements to the ENTIRE Linux ecosystem, yet because there are so many Linux users that are "free as in beer!" you'd rather run your network on a hacked copy and risk getting screwed, like when CentOS nearly went tits up, than to actually spend a buck and help pay for your own OSes improvements by supporting the company making those improvements.
I'm sure I'll be modded down for daring to point out this sad little bit of reality, but you want to know why Linux is a blip on the map? Here you go. Companies rightfully see there is no money in Linux because FOSSies will go to great lengths not to pay even when it ultimately hurts themselves. Think RH did this change for fun? Nope, it is because you and so many others are slowly killing the company by refusing to buy the product but you want the fruits of their labor anyway.
Say what you want but THIS, this right here, is why the proprietary model wins out over the FOSS model. It is because companies that make good popular products actually get increased capital they can use to grow and expand, whereas with FOSS three minutes after it comes out someone is copying the code to make a cheap knockoff just to get out of paying. Kinda sad actually.
What a pointless, and trollish diatribe, the whole point of the Red Hat business model is that you don't really buy RHEL, you buy a RHEL support contract. People using CentOS are no different from people using debian, or any other "free as in beer" distro.
Whether Red Hat's business model is sustainable is up for debate, but at least they don't depend on statist copyright policies and software patents.
It isn't the sources, its the effort... (Score:2)
F5 Networks scratches off the serial numbers of Red Hat enterprise and produces CentOS so that they don't have to license Enterprise from Red Hat. They started this (CentOS) because every one of their Big-IP boxes was running Red Hat and they needed a stripped version to avoid paying the license fees for Red Hat's work. They explained this to me and then gave me the in-house extension to call if I found any Red Hat branding back when I worked there. (Yes, I have first-hand knowledge of these facts.) It's wrong at a moral level, but so what.
Most people who get Red Hat kernels end up applying all the patches anyway. Why is it more efficient or reasonable to release the kernel to all those people as straight-source plus patches, when they all want patched source in the first place. From an efficiency standpoint releasing the patches source is good for everybody but the leaches.
If F5/CentOS was going through the trouble to bundle and test all the packages form the same sources as Red Hat is getting them, then this wouldn't be a issue. It isn't about the sources of the sources, its about the testing and integration that Red Hat does that F5/CentOS has chosen to use with less than a nod.
So F5 is too cheap to pay for Red Hat's work, and they are too cheap to _duplicate_ Red Hat's work, and they are too cheap to build a distribution that _only_ contained what they actually needed, so where _exactly_ is Red Hat wrong for the very human response of saying "blow off, you freeloaders..."?
Besides, I bet if you pay support, or ask nice, you can get the patches anyway. The fact that the default distribution is fully patched instead of making you spend the time to patch it yourself is actually a _win_ for the paying customers.
And all of these actions from both companies are fully GPL compliant.
So where is the "problem" really?
Comment removed (Score:2)
Re:I don't see the problem (Score:3)
Re:I don't see the problem (Score:2)
Re:I don't see the problem (Score:2)
While that might seem like a violation of the GPL, it isn't because they do make the entire thing publicly available (no RHN subscription required) in the new (no separate patches) kernel package release.
Isn't it even simpler than that: The GPL only requires you to make source code available to people you give the binaries to. Since their customers can get it via the RHN, releasing the complete patch for everyone to use isn't strictly necessary.
Specifically:
For example, if you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received. You must make sure that they, too, receive or can get the source code.
Note that it only refers to "the recipients" (of the program), not "everyone".
Re:I don't see the problem (Score:2)
"Isn't it even simpler than that: The GPL only requires you to make source code available to people you give the binaries to"
The GPL doesn't "only" requires that. It explicitly requires you don't add any other limits appart from those of the GPL itself to those you distribute your source too.
Even if it's not literally against the GPL (I don't know) it is certainly against its spirit if Red Hat disallow further redistribution of the sources.
Re:I don't see the problem (Score:2)
It effects the kernel devs and other distros that may want to incorporate some of Red Hats changes.
It also effects red hat users that want to recompile the kernel with only some of the patches from red hat.
Re:I don't see the problem (Score:2)
I doubt this is true, they are only changing how they package the Red Hat kernel source, I am sure they are still submitting changes to the community. It seems the difference here is if you want to use the Red Hat kernel but don't want certain patches, but if you just want to use Red Hat changes in a vanilla kernel I am sure the Red Hat developed patches will still be available.
Re:I don't see the problem (Score:2)
Specifically:
"Many thanks again to Maximilian Attems who dug around in a lot of different distro kernels and forwarded to me the original git commit ids that should be applied to this tree. Red Hat didn't make this very easy due to their "one giant patch" format, and his skill is helping everyone out here. It's much appreciated."
Re:I don't see the problem (Score:2)
It doesn't matter at all for CentOS. It matters for other Linux distributions that want to collaborate with Red Hat and with upstream. Digging a fix out of the Red Hat kernel becomes a lot harder with only a monolithic patch. And without fine-grained patches, any kind of conflict between the megapatch and other kernel patches becomes incredibly difficult to troubleshoot.
Comment removed (Score:2)
Incorrect news is incorrect. (Score:5, Informative)
"Although targeted at Oracle, the changes will make work harder for distributions such as CentOS."
That's not what CENTOS says.
"This description is accurate. However, as pointed out multiple times by now, it does not affect rebuilding of the kernel itself. The CentOS kernel is just a rebuild, so there is no problem there. In the case of the centosplus kernel, because it may add patches, some extra steps might be needed. But again, that is not a major issue."
https://www.centos.org/modules/newbb/viewtopic.php?topic_id=29147&start=280
Good for them (Score:3, Interesting)
Screw those asshats at oracle who have the nerve to package up rhel and call it their own. Even worse their idiot sales reps go around promoting it as the only thing that will run their db. All they contribute to open source is FUD.
Re:Good for them (Score:2)
Screw those asshats at oracle who have the nerve to package up rhel and call it their own. Even worse their idiot sales reps go around promoting it as the only thing that will run their db. All they contribute to open source is FUD.
They don't say that. You can run Oacle on RHEL or SUSE just fine and it's supported.
So screw those asshats who post FUD as AC on Slashdot...
Re:Good for them (Score:3)
Re:Good for them (Score:2)
Sounds like Microsoft VS IBM in regards to SO/2.
Re:Good for them (Score:2)
Re:Good for them (Score:2)
GPL clearly says "preferred form of modification". A huge tarball with large undocumented changes is not one if a git repository with everything well-organized is known to exist. There's no way to bisect it to find where a regression is, to find which of Red Hat's modifications caused a breakage, what they modified, and so on.
Re:Good for them (Score:4, Funny)
And it makes it easier to put in code that detects if it's an oracle repackage and spew out "ORACLE SUCKS" on the text console and in the logs.
Re:Good for them (Score:2)
And it makes it easier to put in code that detects if it's an oracle repackage and spew out "ORACLE SUCKS" on the text console and in the logs.
So it's not done until Oracle won't run?
Sounds familiar.
Re:Good for them (Score:2)
And it makes it easier to put in code that detects if it's an oracle repackage and spew out "ORACLE SUCKS" on the text console and in the logs.
So it's not done until Oracle won't run?
Sounds familiar.
Possibly, but I think until you have inserted the Oracle approved contractor it won't boot.
Re:Good for them (Score:2)
Re:Good for them (Score:2)
They have to release the code but they do not have to make it easy for people to use it.
Re:Good for them (Score:2)
"They have to release the code but they do not have to make it easy for people to use it."
Well, in fact they *do* have to make it as easy for other people as it's for them (remember the "preferred form" GPL clause?).
Re:Orachole is run by idiots (Score:2)
Re:Orachole is run by idiots (Score:2)
To be fair, Red Hat has been known not to honor the spirit of the GPL in some cases. But in an asshattery contest, Oracle is the clear and uncontested champion.
CentOS Impact? (Score:5, Insightful)
Since CentOS is basically removing trademarks and recompiling how exactly does this make their work more difficult? Does CentOS not ship the same kernel as Red Hat by using Red Hat source? Wont CentOS simply compile the pre-patched source from the tarball and be good to go?
Re:CentOS Impact? (Score:5, Insightful)
Mod parent up - it's correct.
The article is completely wrong in relation to CentOS (which aims for 100% binary compatibility to RH). AFAIK, they don't care which patches were applied by RH because they're duplicating the kernel down to the last byte. As you say, they'll just compile the tarball and off she goes.
The article is correct as far as an entity like Oracle is concerned, which aims to put in its own additions and "improvements".
I'm of two minds about whether RH is evil or prudent to do this, but on balance I've got no lost love for Larry Ellison, so I give RH the benefit of the doubt on this one.
Re:CentOS Impact? (Score:5, Informative)
The Oracle improvements, for the most part, are actually kernel level modules and services that provide the required functionality to facilitate their database clusters. They basically provide the inter-node communication and shared block access management services among other things.
I'm a long-time Oracle DBA, and could care less about this little war. I just know that it pays the bills.
Re:CentOS Impact? (Score:2)
fair enough - but they should either pay RedHat for the product they reuse, or submit their DB modules etc as open source so they can be added to the upstream repository.
Then everyone can run Oracle on RH (like they do anyway) and Oracle can just drop their own distro and reuse Redhats, directing customers to RH which I'm sure would be cheaper for Oracle and more profitable for RH.
Re:CentOS Impact? (Score:2)
Are those modules available in any OSS repository? They can optimize all they wish, but I would like them to be good sports about piggybacking on OSS's braintrust and commit their optimizations back to the community. It's only fair since they're leveraging these mods off a great deal of RH's work.
Re:CentOS Impact? (Score:2)
I'm of two minds about whether RH is evil or prudent to do this
I'm no kernel hacker, but it's at least conceivable that RH's reasons for doing this are not to screw with Oracle or others, but rather because it's most convenient for them. Yes, having changes shipped separately is nice for a lot of people, but maybe RH decided to optimize their workflow, merging code and whatnot, and the end result of this optimization was that it was easier to distribute the merged code rather than distributing their internal toolchain, scripts, etc.
As others have pointed out, you can still compile their code, and diff against other branches of the kernel if you really want to see what the RH-specific changes are. So it's not like they are trying to end-run around the principles of Free Software. So, I think an 'evil' label would be premature.
Re:CentOS Impact? (Score:2)
I use both CentOS and RHEL and still rebuild kernels quite often. This actually makes it easier for me to rebuild the *stock* RH kernel. It makes it somewhat more difficult to take those patches and apply them to the vanilla kernel.
Re:CentOS Impact? (Score:2)
It's against the spirit of the GPL, isn't it? To take from the community but to put stumbling blocks in the form of that the community can't see the history of changes or to reapply certain patches. Since Oracle is developing on the Linux kernel they are a part of the community (I didn't read about a case were Oracle is making parts of the kernel propriety).
If you want to see who is on the evil site, just swap out the names. For Oracle put "Debian" and for Red Hat put "Canonical". So Canonical is developing patches but they are now making only the complete Kernel as a tar ball available, so Debian can't see the history and reapply some patches anymore. This change appears to be aimed at Debian, Mint, Lubuntu, and like others, repackage Ubuntu's source as the basis for its Linux.
Re:CentOS Impact? (Score:2)
I think there is some confusion here. Red Hat is no longer providing separate patches in the Red Hat kernel package. I am pretty sure Red Hat will continue to provide patches back to the kernel development community. I don't think the kernel developer community are downloading the Red Hat source RPM for the kernel and extracting the patches to include in the tree.
Re:CentOS Impact? (Score:4, Informative)
Wont CentOS simply compile the pre-patched source from the tarball and be good to go?
Yes, CentOS will be fine. There's been some interesting discussion on the CentOS-devel list lately about how CentOS is positioning itself w/r/t Redhat. They're reluctant to share an automated build process with the community (so the process can be independently verified) because that would help Redhat's competition (seemingly Oracle). The trouble is, it also slows progress (no CentOS 6 builds yet) and makes forks difficult (something that ought to be encouraged, if needed, in the Open Source ethos).
The CentOS team does awesome work, but it's a tricky situation they're in.
Re:CentOS Impact? (Score:3)
Agreed, and I hope my comment did not make it sound like the CentOS team has an easy job. I am not in a position right now to pay for a full blown Red Hat Network license for home use so I've been using Fedora and CentOS since Red Hat dropped the $60 / year RHN subscriptions. I am very appreciative of the work the CentOS team does.
But I also think it is a big mis-representation to put what Oracle is doing into the same realm as what CentOS does. Ellison has publicly stated that he believes the value of the open source community is to be plundered but you don't put your own good work in the open source arena because your competitors will get it. CentOS on the other hand is part of the open source community.
I think it is also important to point out the tricky position that Red Hat is in. CentOS and other rely on Red Hat and Red Hat is a business that needs to profit from their operations to remain viable. I know for a fact, in speaking with sysadmins I know, that there are many companies who utilize Red Hat's software but do not pay the required Red Hat Network licensing but at the same time spend millions on Microsoft and Oracle licensing. I like to think that Red Hat can remain as open and giving as possible and people will reward them with honest business, unfortunately that is not the case and the intentions of companies like Oracle have been stated bluntly by their CEO.
So yes, tricky situations for Red Hat and CentOS and a lot of outstanding work by both that is valuable to many individuals, corporate organizations, and governments.
Re:CentOS Impact? (Score:2)
Doesn't matter much. CentOs would benefit from having its own build system.
RHs build system is very old and based on CVS (ya rly)
Re:CentOS Impact? (Score:2)
CentOs would benefit from having its own build system.
It does have its own build system, it's just that you (as the end user, auditor, or forker) can't download a ready-to-run copy of it from CentOS.
Re:CentOS Impact? (Score:2)
Yes, interesting
Some distributions allow their build system to be downloaded as part of the distribution. Of course CentOS can't have it as part of the distribution because it's not from the 'preeminent Linux vendor'
Re:CentOS Impact? (Score:2)
CentOS may be slogging away slowly to bring out CentOS 6, but Scientific Linux 6 went live yesterday, and their pre-releases have been easily accessible to anyone since December.
diff(1) (Score:5, Informative)
$ tar xzvf linux-2.6.nn.tar.gz
$ tar xzvf linux-redhat-2.6.nn-02.tar.gz
$ diff -Naur linux-2.6.nn linux-2.6.nn-02 > redhat-02.patch
$ diff -U redhat-01.patch redhat-02.patch | more
Re:diff(1) (Score:2)
I think the issue is that previously, RedHat shipped a bunch of independent patch files, split by "issue fixed/function added"
Your method generates a single "megapatch" file.
Re:diff(1) (Score:3)
You wouldn't have a patch down to the individual features but you'd have a patch set thats alot smaller and enumerable.
Smaller yes - but not really enumerable. Five changed lines may represent eight different bugs and fixes. And as the patch holder, now all you now is that one or more bugs have been addressed by those five changes. You have no idea those fives changes actually address eight different bugs because all you have is the aggregate of all those changes.
You're trivializing the issue by a lot. The issue is manageable but without a doubt, granularity has been lost. The exact effect on all other consumers of Red Hat's work likely isn't completely understood at this point.
Re:diff(1) (Score:3)
That'll give you one giant patch of everything Red Hat has done. Now, what changes in what files go together and implement a patch? The point would be to look at the patches one by one to see they've been applied, and now if you want to do this you must break it down yourself.
Re:diff(1) (Score:3)
All the changes go together and implement one big patch. What "patch identifiers" RH used in their own patching process are is irrelevant as it gets.
Since the objective is a kernel identical to RH's, there's no need to obsessively worry about which of RH's patches were applied or not, because the correct answer is "all of them".
This approach has absolutely no downside as long as RH continues to honor their GPL obligations and actually releases all code changes, whether by diff or full source.
Re:diff(1) (Score:2)
'Since the objective is a kernel identical to RH's, there's no need to obsessively worry about which of RH's patches were applied or not, because the correct answer is "all of them".'
Ah, but for Oracle, that's not necessarily the aim. They may want to apply some patches and not others. That makes them able to say that their version is different from Red Hat's, and thus the right one to run for Oracle. Now they either have to do their own patching or rework their own patches on top of every new Red Hat patch, which is a bit more of a pain that just not applying some of Red Hat's. Either that, or simply stay exactly the same as RHEL, in which case why run their Linux at all?
Re:diff(1) (Score:2)
Re:diff(1) (Score:2)
What about the CentOS plus [centos.org] kernels? Wouldn't It make it trickier to create those as it's necessary to avoid munging stuff that's already there but the devs don't know what or where it is?
Re:diff(1) (Score:3)
Selective patching for reasons other than "you don't necessarily want to consume all of those fixes" I could understand, if I were to stipulate the hypothetical that some of the "fixes" aren't really "bug fixes" but optional enhancements. But really, in RH's kernel history, I can't remember very many of those (actually, I can't remember any).
Sometimes things aren't as simple as broken/not broken. Sometimes its fixed for some edge cases at a cost of slowdowns on all systems. Sometimes its removed functionality to prevent a security issue that may be irrelevant to me. You need to be very careful extending the particular "I've never had a problem" to the universal "No one has ever had a problem"
I long ago forgot the original issue, but I definitely recall having to build a custom kernel RPM package every time we decided to adopt the latest kernel fixes for our server farm to undo some "fix" Red Hat had installed that worked great in the majority of cases but broke badly in our environment; it was also obvious from the Bugzilla reports that we weren't the only ones and that Red Hat knew of the issue and were choosing not to undo it because they felt their fix helped more people than it hurt
Bad (Score:3, Insightful)
It also makes life much harder for us downstream engineers who actually have to troubleshoot problems in the Redhat kernel. More often than not, it's a vendor-applied patch responsible for creating the problem in the first place. Now I guess it's up to Redhat Support to come up with a solution, which often reads "in 3 major versions time, if ever"
Why Harder? (Score:2)
On the contrary it might be harder for other distro not based on rh to get a single patch out of the kernel
Re:Why Harder? (Score:2)
Well, if they're not based on RH, they're going to have their own pipeline to the kernel patches. If nothing else, those patches should find their way back into the primary kernel repository. (Maybe. I dunno. Do Linus and company routinely freeze out distro-provided kernel changes?)
The only "risk" is if there's some earthshakingly novel patch that RH comes up with and releases in-channel, but other distro mainainers (and the keepers of All Kernel Goodness) choose not to accept even after RH releases it to the broader community (in keeping with their GPL obligations). Only then would RH's approach be a minor pain, because you'll have to back it out of a full-kernel source diff and figure out which parts matter (and haven't shown up yet in your own distro's upstream).
Karma (Score:3)
Re:Karma (Score:2)
And how is it not within the spirit of the license to take someone else work, fork it and rebrand it?
Why don't you try that with Java, and let us know how it goes. Red Hat isn't playing nice but they're giving Oracle a (small) part of what it deserves.
The problematic issues arise if... (Score:3)
Precisely CENTOS is not going to be bit by this. The problems arise if you try to take RedHat's patches and apply them in other distributions (Attems is in the Debian kernel team, so he is among the most affected people), or if you are among the breed of people still patching and rolling their own kernels.
So far, off-the-mainlain Linux kernel development has been a collaborative effort with people from different backgrounds joining in. Of course, RedHat –as a business– has to keep a competitive advantage. And that advantage can stem from saying here is a megapatch with all of our improvements, with no distinction between feature lines, with no documentation on what does what besides the code itself".
I understand their point, but am deeply saddened by it. And yes, it is legal and sound, although goes against _collective_ Linux state-of-the-art advancement, beyond each company's interests.
Re:The problematic issues arise if... (Score:2)
Is this factual? From what I've read this change is distribution affects Red Hat's kernel source used in the Red Hat distro, this does not mean that Red Hat's kernel patches are not fed back into the kernel development process as individual patches.
I'm not a kernel dev so I don't know the exact process but it sounds like your saying the only way Red Hat contributions make it back into the kernel is by somebody outside of Red Hat extracting patches from the Red Hat distribution kernel source and putting them into the vanilla kernel development tree. Perhaps this is the way it works but I'm skeptical.
So what? (Score:2)
I don't see how this affects anyone, even Oracle.
To be honest, I wonder why it took them that long. I have been doing RPM packages for quite some time and have always hated 1000+-patches source RPMs such as Red Hat's kernel source package. This is a welcome change.
I guess they use git internally, so that would just be a git archive --prefix=linux/ | gzip >linux-src.tar.gz. I haven't looked at the package yet, but the really good stuff would be if they provided a link to the git repos and the SHA1 for the commit ID used to generate the archive: this way, RH derived kernels would have quite an easy time rolling their own if needed.
So what? (Score:4, Insightful)
Red Hat's job isn't to make things easier for CentOS, or Oracle for that matter - how is that even relevant? Red Hat isn't doing anything that's disallowed by the GPL. They're not even doing anything that could be reasonably interpreted as "contrary to the spirit of the GPL".
They're still releasing the source. They're still paying their coders to do substantial work on the kernel. How big of a twit do you have to be to complain about how they release their kernel updates?
Re:So what? (Score:2)
And how big of a twit do you have to be completely misinterpret the observations and make completely off topic charges?
What happened to 'upstream upstream upstream'? (Score:2)
Coincidentally enough, this state of affairs has been in place for 6 months, but this slashdot/lwn note comes the morning after I discovered the fact myself while trying (still as yet unsuccessfully) to rebuild the kernel with support for one odd driver enabled instead of disabled.
What strikes me as missing from the current set of comments, is how this move by RH seems at odds with their laudable history of 'upstream upstream upstream'. I.e., it seems to me that each of those hundred(s) of patches will now be significantly less likely to be adopted upstream, because of the added complexity of not knowing the details of - the mother of all deployments - of those patches. Details meaning, what other changes does it depend on, and happen to be shipped with in its stable and vast commercial deployment.
The other tinfoil-hat/security consideration is- if RH is as in bed with the NSA/CIA as it seems to me to have been for a very long time, and if the NSA/CIA did want to hide backdoors or backdoor enabling faults in the kernel, this is precisely the kind of move that would make those sorts of things orders of magnitudes more difficult for the traditional 'many eyes' effect to detect.
But of course, the bottom line is that what they are doing is quite legal, and from traditional business perspectives, quite ethical, and probably practical as well. But to the commenter who said there are 'no downsides' to this- No, there are downsides.
Re:CentOS (Score:2)
Considering that RedHat sells premium support, I don't see the problem.
Re:CentOS (Score:2)
Re:CentOS (Score:2)
you need to add a sarcasm tag.
Cent OS has been around a lot longer than the Fedora project.
Re:CentOS (Score:3)
But Fedora isn't a free version of RHEL. It's a test bed for things which may or may not feed into RHEL at a later date. I miss the days of the RedHat box sets. Those were pretty quality. Fedora always seems broken in some way to me.
Re:CentOS (Score:2)
Re:CentOS (Score:5, Informative)
http://linux.slashdot.org/story/07/11/04/1331247/Is-CentOS-Hurting-Red-Hat [slashdot.org]
""I'm pretty sure RedHat hate CentOS."
1. No, we don't. At least, not most of us -- because most of us actually *understand* the business we're in. That's why we're making all this nice money. If we did hate CentOS, we could make it awfully difficult for them in any number of ways -- delaying updates, hiding marks and making them play "where's Waldo" every release, that sort of thing.
2. The "coy mumbo jumbo" about the upstream vendor has to do with trademark protection, not hate. We don't want "Red Hat" to turn into "Kleenex".
3. Here's a question: why is there no CentOS equivalent based on SuSE products? Think about it.
4. A lot of the significant people in the CentOS community are actually important and respected members of the Fedora community as well. That way, Red Hat benefits from the work of the more savvy CentOS users. That's how open source works, you see.
"
Re:CentOS (Score:2)
3. Here's a question: why is there no CentOS equivalent based on SuSE products? Think about it.
I don't hear people say openSUSE is a SUSE testbed as much as they say that of Fedora and Red Hat. Maybe openSUSE is "good enough" for people that want a free SUSE?
Re:CentOS (Score:2)
Nope, openSUSE is their version of fedora.
Both are used to test the latest and greatest. Centos is not for that purpose.
Re:CentOS (Score:2)
RedHat exercises the GNU freedom by selling for money a distribution consisting mostly of free programs made by others. CentOS provides a distribution gratis (and doing this is certainly costing them something in term of work and servers) based on this huge work mostly made by others than RedHat. What is the problem exactly?
Re:CentOS (Score:4, Insightful)
RedHat exercises the GNU freedom by selling for money a distribution consisting mostly of free programs made by others.
For the record, RedHat is selling support for a distribution they have engineered. They aren't selling the distribution, except possibly a "media charge", year 1 to obtain the support and year 2 to maintain the support are the same price.
CentOS does not offer any support beyond the standard Open Source model of chat boards, bugzilla, etc. As a general rule, when I introduce Linux to a company with a small unsupported project, I bring in CentOS, not Fedora, because I know if it takes off we'll be bringing in RHEL 9 times out of 10 when the company decides they want/need support. That way, there is pretty much zero retraining of the staff that needs to happen.
You don't like Open Source (Score:2)
I like open source. I don't like people taking money from you because they just don't want to pay for the work you did.
If you don't like the idea of people being able to freely use and redistribute your work, then you neither understand nor like open source software, because that is the the entire point.
Re:You don't like Open Source (Score:2)
Well, if the people making it aren't opposed to it, how is it leeching? It sounds more like taking something freely given.
The whole point of open source and the GNU license is that other people get to benefit from the work applied to it.
Seriously, why is it leeching if it's done with the knowledge and permission of Red Hat? I'm sure they take enhancements that happen against the rest of the user-land and kernel stuff -- it's a two-way street.
Re:CentOS (Score:2, Troll)
Comment removed (Score:2, Flamebait)
Re:CentOS (Score:3)
Haven't made serious inroads against Apple and Microsoft? We're kicking their tukkas. With any luck, in the long run we're going to make mainstream commercial software a thing of the past.
Redhat's developers are skilled, fine people, but Redhat gets most of the code it ships from the opensource community, not their own people. Linux (and the BSDs) is a community, and the relationship between the vendors, the developers, and the users is not as simple as you'd think.
Comment removed (Score:2)
Re:diff (Score:3)
Yeah.... a lot
You could use diff and get a single patch.... no way to then divide it into the many patches that make up the whole
Re:diff (Score:4, Funny)
Maybe they could use a computer to speed that process up.
Re:diff (Score:4)
A + B + C + D = F
You are given the values of A and F. Find B, C, and D.
Re:diff (Score:2)
P = NP
Re:diff (Score:2)
Fine if you want to apply all fixes. But what if you don't? One file might contain several fixes, and one fix might affect several files. How do you work out what's what in that situation?
Diff the subdirectories (Score:2)
Re:diff (Score:3)
Re:Smart move by Red Hat (Score:5, Insightful)
Red Hat is doing more heavy lifting than anyone else, but organizations like Oracle and CentOS are leeching off of Red Hat's hard work.
Boohoo? If you don't want people to leech your work then why would you release it under a license that specifically allows that?
They are absolutely meeting the requirements of the GPL.
And so are the people you claim are "leeching" off of Red Hat.
If these other organizations like Oracle and CentOS were saying "we're going to fork what Red Hat has done and come up with something different because we think we can do it better," like Mandrake did, that would be one thing. But Oracle and CentOS both pretty much have the same message: "we're going to take all the hard work that Red Hat has paid for, claim that ours is just like theirs, but make sure that Red Hat doesn't get paid for it."
But if they aren't violating the GPL, so what? You've basically constructed a double standard where it's okay for one party to use GPLed code however they want within the bounds of the license but yet you come back and whine about others who are doing the exact same thing. Once again, if you don't want people to use your code this way, why would you release it under a license that was specifically worded in order to allow this?
Re:Smart move by Red Hat (Score:2)
So you're advocating for un-free software?
Good.
Re:Smart move by Red Hat (Score:2)
CentOS is playing by the rules. Oracle is not.