Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Red Hat Stops Shipping Kernel Changes as Patches

Unknown Lamer posted more than 3 years ago | from the clearly-the-best-solution dept.

Red Hat Software 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."

cancel ×

184 comments

Sorry! There are no comments related to the filter you selected.

Oh (-1)

Anonymous Coward | more than 3 years ago | (#35380644)

Snap

I don't see the problem (2, Insightful)

Anonymous Coward | more than 3 years ago | (#35380650)

Did they stop shipping diff too?

Re:I don't see the problem (2, Informative)

Josh Triplett (874994) | more than 3 years ago | (#35380842)

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 (1)

FunkyELF (609131) | more than 3 years ago | (#35381118)

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 (1)

Tubal-Cain (1289912) | more than 3 years ago | (#35381308)

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.

Re:I don't see the problem (1)

prograde (1425683) | more than 3 years ago | (#35381620)

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.

There are logos in the kernel? Really?

Re:I don't see the problem (1)

Tubal-Cain (1289912) | more than 3 years ago | (#35381840)

Yes, actually. [linuxtracker.org] Although I don't know whether Red Hat replaces the Tux image with something of their own.

Re:I don't see the problem (-1, Troll)

Hylandr (813770) | more than 3 years ago | (#35381968)

Since when has Centos been relevant?

They haven't released in so long, updates have to be hacks. I removed it from any production server I have any dominion over.

- Dan.

Re:I don't see the problem (0)

Anonymous Coward | more than 3 years ago | (#35382296)

And replaced with?

Re:I don't see the problem (1)

SaDan (81097) | more than 3 years ago | (#35382340)

I did the same thing recently, and went to Ubuntu Server. It's nice dealing with somewhat up-to-date versions of software again.

Re:I don't see the problem (1)

Guspaz (556486) | more than 3 years ago | (#35382406)

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 (1)

dowdle (199162) | more than 3 years ago | (#35381806)

I don't think Red Hat puts logos or branding in the kernel. This was talked about earlier in the week on LWN.net and the patches ARE still available but for RHN (Red Hat Network) subscribers... and they modified the RHN service agreement to include a clause that makes it a violation to share the individual patches. 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.

Re:I don't see the problem (0)

Anonymous Coward | more than 3 years ago | (#35381896)

Isn't that what they already likely do with the rest of the distribution? Search and remove trademarks? And how is searching a large piece of code (full tree) any more difficult than a small piece (like a patch)? It might take a little longer for grep (or whatever tools they use to help) to run and/or for people to look through code, but it should be exactly the same process.

Doesn't seem like a very big deal for CentOS, really.

Re:I don't see the problem (2)

Tubal-Cain (1289912) | more than 3 years ago | (#35381924)

Meh, you're probably right. I think someone here posted something from CentOS saying it wasn't a big deal for them.

No, just search the diff (1)

gr8_phk (621180) | more than 3 years ago | (#35381954)

And since they'll be searching a single diff instead of a lot of patches, it may actually be easier ;-)

Re:I don't see the problem (1)

burnin1965 (535071) | more than 3 years ago | (#35382012)

Now instead of searching the patches for those, they need to search the entire patched source.

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 (1)

Tubal-Cain (1289912) | more than 3 years ago | (#35382094)

When they were separate, the kernel source was vanilla Linux, with all Red Hat modifications contained in the patches.

Re:I don't see the problem (1)

burnin1965 (535071) | more than 3 years ago | (#35382212)

Ah, okay, that makes sense.

Re:I don't see the problem (1)

JackieBrown (987087) | more than 3 years ago | (#35381576)

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 (1)

burnin1965 (535071) | more than 3 years ago | (#35382058)

It effects the kernel devs and other distros that may want to incorporate some of Red Hats changes.

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 (1)

Josh Triplett (874994) | more than 3 years ago | (#35381586)

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.

diff (0)

Anonymous Coward | more than 3 years ago | (#35380670)

Um. So...

Use diff and get your own patches?

Or am I missing something?

Re:diff (2)

FunkyELF (609131) | more than 3 years ago | (#35381134)

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 (3, Funny)

repetty (260322) | more than 3 years ago | (#35381350)

Maybe they could use a computer to speed that process up.

Re:diff (3)

zill (1690130) | more than 3 years ago | (#35381426)

Question 6.

A + B + C + D = F

You are given the values of A and F. Find B, C, and D.

Re:diff (1)

jgagnon (1663075) | more than 3 years ago | (#35382256)

P = NP

Re:diff (1)

Hognoxious (631665) | more than 3 years ago | (#35382250)

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 (1)

gr8_phk (621180) | more than 3 years ago | (#35381994)

Duh. Or is Redhat going to dump all the source files into a single dir too? Somehow I think that would be more trouble than it's worth for them.

Re:diff (2)

robthebloke (1308483) | more than 3 years ago | (#35381342)

Nope, you summarised the problem very succinctly. You can't get patches from a diff, you can only get a patch....

Incorrect news is incorrect. (5, Informative)

Anonymous Coward | more than 3 years ago | (#35380674)

"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 (3, Interesting)

Anonymous Coward | more than 3 years ago | (#35380748)

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 (0)

Anonymous Coward | more than 3 years ago | (#35380928)

Screw those asshats at oracle who have the nerve to package up rhel and call it their own.

Yes, screw those asshats for doing something that was one of the reasons the GPL was created! If you don't want someone to be able to do this, put it under a more restrictive license otherwise you reap what you sow.

Orachole is run by idiots (0)

Anonymous Coward | more than 3 years ago | (#35381230)

There's a big difference between allowing companies to not honor the spirit of the GPL and actively helping them to do so. I think in this case Red Hat is justified and Orachole will just have to deal with the consequences of not playing nice.

Re:Orachole is run by idiots (2)

judeancodersfront (1760122) | more than 3 years ago | (#35381318)

So it's ok to not honor the spirit on the basis that one of your competitors is doing the same thing? I think following the GPL is the important part and all this spirit talk is just bitterness at Oracle.

Re:Good for them (1)

KiloByte (825081) | more than 3 years ago | (#35381254)

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 (3, Funny)

Lumpy (12016) | more than 3 years ago | (#35381310)

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 (1)

rubycodez (864176) | more than 3 years ago | (#35381264)

if Oracle's products (for which Oracle Linux exists to run) were GPL, you stupid statement would have made some sense.

Re:Good for them (0)

Anonymous Coward | more than 3 years ago | (#35382232)

Maybe you find Oracle morally repugnant, but the GPL does not address apps that run on Oracle Linux.

Re:Good for them (1)

afabbro (33948) | more than 3 years ago | (#35381390)

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 (2)

rubycodez (864176) | more than 3 years ago | (#35381676)

but Oracle implies their products run *well* only on Oracle Linux. (from oracle.com) Oracle Linux combined with Oracle's Unbreakable Enterprise Kernel brings the latest Linux innovations to market, delivering extreme performance, advanced scalability, and reliability for enterprise applications. The combination is: * Fast—Delivers more than 75 percent performance gain in OLTP performance tests over a Red Hat 5 Compatible Kernel; 200 percent speedup of Infiniband messaging; 137 percent faster solid state disk access * Modern—Optimized for large servers; improved power management and energy efficiency; fine grained CPU and memory resource control; derived from the stable 2.6.32 mainline Linux kernel * Reliable—Supports the Data Integrity Extensions and T10 Protection Information Model, improves application uptime * Optimized for Oracle—Built and tested to run Oracle hardware, databases, and middleware. Recommended for all enterprise applications

Re:Good for them (0)

Anonymous Coward | more than 3 years ago | (#35381882)

Right, you clearly have never met an Oracle rep telling Enterprise customers that their stuff won't run on anything but OEL. That is their MO. They do it every day. What their web site says and what their reps say every single day is a different story. In fact it won't be long before they officially announce it will only run on "their" Linux. You heard it hear first.

CentOS (0, Troll)

theshowmecanuck (703852) | more than 3 years ago | (#35380756)

Good. CentOS embodies the problem with GNU open source. People just take whatever work you have done and put their own name on it. The pinnacle of the leech-ness. No thought to adding or improving, just taking your work because they don't want to pay you for the work YOU did. So good, if it makes it a pain in their ass. 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. Granted Redhat leverages the open source stack; but it adds value (installer/packaging, configuration tools, updates, etc.). That is what they charge for. What does CentOS do other than take the work Redhat does and give it away for free? Seriously. That is taking money away from Redhat. And yes, I do pay for distributions or support periodically because I believe the distros need revenue to keep Linux viable. How many of those about to flame me actually pay for any of the distros they use? Some maybe. Most I am certain, no.

Re:CentOS (2)

del_diablo (1747634) | more than 3 years ago | (#35380780)

Considering that RedHat sells premium support, I don't see the problem.

Re:CentOS (1)

pak9rabid (1011935) | more than 3 years ago | (#35380828)

Maybe if RedHat offered a free version of RHEL (one in which you can use their repositories without buying a support contract), then projects like CentOS wouldn't need to exist. Christ, even Oracle offers free repos to use even if you're not a paying customer (you just aren't entitled to get updates...it's just the same packages you could get off the install discs).

Re:CentOS (1)

peragrin (659227) | more than 3 years ago | (#35380936)

you need to add a sarcasm tag.

Cent OS has been around a lot longer than the Fedora project.

Re:CentOS (2)

bsDaemon (87307) | more than 3 years ago | (#35381072)

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 (1)

scruffy (29773) | more than 3 years ago | (#35382362)

My memory is that the RedHat boxes seemed just as likely to create problems as any Fedora update.

Re:CentOS (5, Informative)

Linker3000 (626634) | more than 3 years ago | (#35380890)

I have put on my 'not sure if serious' face as I am not sure if you are trolling or just ignorant of the situation, but rather than give my perspective, have a read from an earlier Slashdot thread on the subject titled "Is CentOS hurting Red Hat?":

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 (1)

blivit42 (980582) | more than 3 years ago | (#35381518)

3. Here's a question: why is there no CentOS equivalent based on SuSE products? Think about it.

Um, wouldn't that be openSUSE [opensuse.org] ?

Re:CentOS (1)

h4rr4r (612664) | more than 3 years ago | (#35382502)

Nope, openSUSE is their version of fedora.

Both are used to test the latest and greatest. Centos is not for that purpose.

Re:CentOS (1)

Tubal-Cain (1289912) | more than 3 years ago | (#35381696)

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 (1)

Anonymous Coward | more than 3 years ago | (#35380892)

Yeah, I'm sick of CentOS people *taking money* from Red Hat.

Just like those damn pirates *take money* from RIAA.

Troll harder.

Re:CentOS (1)

garaged (579941) | more than 3 years ago | (#35380906)

as if Redhat weren't doing exactly the same, yes they employ people, but they wouldn't if they didn't needed them for the business, that's the beuty of GPL, not so easy to abuse the system

Re:CentOS (1)

Anonymous Coward | more than 3 years ago | (#35381066)

No thought to adding or improving, just taking your work because they don't want to pay you for the work YOU did.

If you're so worried about that, then you probably wouldn't be RELEASING IT TO THE WORLD UNDER A FREE AND OPEN LICENSE now would you? There are plenty of proprietary licenses if you want to be able to stop people from doing this. Instead of bitching about how other people release their work, how about releasing YOUR work under any license you like? Douchebag.

Yes I can see it now. 1) Programmer writes code. 2) Programmer decides to release code under a license that specifically allows this kind of use. 3) Some asshat on Slashdot pretends like there is a victim in this scenario.

What does CentOS do other than take the work Redhat does and give it away for free? Seriously. That is taking money away from Redhat.

Redhat knew that this was SPECIFICALLY ALLOWED BY THE GPL when they CHOSE to work with GPL code. Don't worry. They are all grown up now and can be responsible for the decisions they make.

How many of those about to flame me actually pay for any of the distros they use? Some maybe. Most I am certain, no.

Paying money or not paying money doesn't suddenly make you right. It doesn't fix your faulty reasoning. News at 11.

You know why politics is so fucked up and government is so out of touch and is becoming like a cancer to the nation? Because politics is full of people who think like you.

Re:CentOS (1)

Framboise (521772) | more than 3 years ago | (#35381070)

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 (3, Insightful)

ePhil_One (634771) | more than 3 years ago | (#35382330)

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 (1)

pavon (30274) | more than 3 years ago | (#35381472)

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.

CentOS Impact? (4, Insightful)

burnin1965 (535071) | more than 3 years ago | (#35380758)

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? (4, Insightful)

thatseattleguy (897282) | more than 3 years ago | (#35380850)

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? (4, Informative)

nettdata (88196) | more than 3 years ago | (#35381174)

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? (1)

JustinOpinion (1246824) | more than 3 years ago | (#35381598)

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? (1)

Anonymous Coward | more than 3 years ago | (#35381914)

I'm guessing you're not a developer? What you are saying makes no sense. keeping changes in a single lump is worse for everyone: it is absolutely certain that they still have a git tree with patches in it internally, and producing the diffs would be dead simple . Talk to a RH kernel engineer, you'll find out they are very pissed off about this decision -- they just can't comment publicly.

As usual the comments on LWN.net give the full story [lwn.net] .

Re:CentOS Impact? (3, Informative)

bill_mcgonigle (4333) | more than 3 years ago | (#35381140)

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? (2)

burnin1965 (535071) | more than 3 years ago | (#35381858)

The CentOS team does awesome work, but it's a tricky situation they're in.

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.

diff(1) (4, Informative)

LizardKing (5245) | more than 3 years ago | (#35380770)

$ 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) (1)

Andy Dodd (701) | more than 3 years ago | (#35380894)

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) (1)

steveb3210 (962811) | more than 3 years ago | (#35381414)

You can get less of a megapatch.

Download last version with all patches:
Download version since they stopped this practice.
Diff
Write notes what this patch did.
Download next version
Diff
Write notes what this patch did.


You wouldn't have a patch down to the individual features but you'd have a patch set thats alot smaller and enumerable.

Re:diff(1) (2)

GooberToo (74388) | more than 3 years ago | (#35382050)

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) (2)

Kjella (173770) | more than 3 years ago | (#35380912)

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) (2)

idontgno (624372) | more than 3 years ago | (#35381004)

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) (1)

Desler (1608317) | more than 3 years ago | (#35381092)

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.

It's not irrelevant at all. To know what patch goes to which fix is highly important if you don't necessarily want to consume all of those fixes.

Re:diff(1) (0)

idontgno (624372) | more than 3 years ago | (#35381152)

You may want to change your terminology, then. Publicly admitting you like to leave some stuff broke isn't doing your reputation any favors.

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

So, yeah, if you're saying you want to selectively leave some stuff broken, more power to you. You'll just have to work a bit harder to sustain your... brokenness.

But most system owners just want the bugs fixed. For that majority, RH's change means either no change at all, or minimal change if their build and checkout processes require diffs.

Re:diff(1) (1)

Desler (1608317) | more than 3 years ago | (#35381226)

You may want to change your terminology, then. Publicly admitting you like to leave some stuff broke isn't doing your reputation any favors.

Nice strawman. You assume that all these patches are security fixes or something of the like. What if a patch is something that does nothing but break an interface which you would like to maintain? If you are like Red Hat and things like API and ABI stability are important you aren't going to want to consume such a patch.

Re:diff(1) (1)

Desler (1608317) | more than 3 years ago | (#35381248)

What if a patch is something that does nothing but break an interface which you would like to maintain?

Sorry, that was worded wrong as it's parts of two different thoughts. It's really just meant to be "what if it is something that breaks an interface that you want to maintain". To claim that Red Hat never patches things that change interfaces is asinine.

Re:diff(1) (0)

Anonymous Coward | more than 3 years ago | (#35381756)

If you are like Red Hat and things like API and ABI stability are important you aren't going to want to consume such a patch.

Yeah, maybe Red Hat should go tell that to Red Hat before shit hits the fan.

Re:diff(1) (1)

wonkavader (605434) | more than 3 years ago | (#35381148)

'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) (1)

idontgno (624372) | more than 3 years ago | (#35381180)

No sane human being gives a metric rat's ass about what Oracle wants, except possible for the purposes of impeding it more efficiently. Frankly, if this is RH's goal, more power to 'em.

Re:diff(1) (1)

youn (1516637) | more than 3 years ago | (#35381774)

Well among others Larry Ellison might be interested in what oracle wants... but whether he is sane or not is a long debate which probably will get different answers from different people (sometimes from the same person) :)... a couple of DB admins/ ex sun clients stuck with oracle products might be very carefully studying oracle next moves.

Re:diff(1) (0)

Anonymous Coward | more than 3 years ago | (#35382264)

RedHat's not done till Oracle won't run.

Re:diff(1) (1)

Hognoxious (631665) | more than 3 years ago | (#35382484)

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?

Bad (3, Insightful)

Anonymous Coward | more than 3 years ago | (#35380836)

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"

GIT and branches can easily handle it (1)

trelony (825975) | more than 3 years ago | (#35380840)

It is like we are back in the last century. GIT and branches can easily handle parallel changes from different vendors. Sometimes merges can be tricky, but it is not different if normal patches. So the only benefit for RedHat is that they now generate a much simpler package and that it is.

Why Harder? (1)

Verunks (1000826) | more than 3 years ago | (#35380884)

I don't see why it would make anything harder for centos or oracle, I doubt they check the code of every redhat patches before applying them. Redhat sells a product so the patches must be good and if they are good for them they are fine for centos and oracle too
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? (1)

idontgno (624372) | more than 3 years ago | (#35381064)

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

Re:Why Harder? (0)

Anonymous Coward | more than 3 years ago | (#35381156)

Oracle doesn't accept every single RH patch... Plus they probably like to investigate each new "feature" or "fix" to see if it's worth including.

Smart move by Red Hat (0)

Anonymous Coward | more than 3 years ago | (#35380908)

Red Hat spends over $100 million dollars a year on R&D, and they give all of that work away for free through the Fedora Project. They've bought numerous companies and made previously closed source code Open. They're the #1 commercial contributor to many of the most critical upstream projects like the kernel, glibc/gcc, X.org, GNOME, the list goes on and on. Red Hat does more for the Linux and other Open Source communities than any other company on the planet.

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. Red Hat has asked to be fairly compensated for their work. How unreasonable is that? Who doesn't want to make a fair wage for hard work? Red Hat is still giving everything away through Fedora. All they seem to be doing is protecting their paid Linux business. That same business which funds more development and engineering than anyone else out there. How is that unreasonable?

The GPL only requires that they give source code to entities which have gotten their binaries. Instead, they give it to the whole world. They are absolutely meeting the requirements of the GPL. To claim otherwise is just sensationalist drivel. Great headline for getting page hits and selling advertising, but pretty irresponsible reporting.

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." That's a losing game. In the long term, it hurts everybody. If Red Hat doesn't get compensated, they can't put as many engineers on projects. The community loses. Let's say that this leeching strategy is totally successful, and no one pays Red Hat any more. Red Hat fails, and Oracle and CentOS get their sources from... where, exactly? Again, everyone loses.

I hear the cry already - "but that's within the letter of the Open Source rules!" Correct. Obviously it is. But is that the spirit of Open Source? Does anyone claim that Open Source was intended to deprive a developer of fair compensation? I don't think so. So why are sensationalistic articles making Red Hat out to be some sort of villain for doing what is legal, prudent and ultimately, better for the community - protecting their work and staying in business?

Re:Smart move by Red Hat (5, Insightful)

Desler (1608317) | more than 3 years ago | (#35381202)

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?

Huh ? What? (0)

Anonymous Coward | more than 3 years ago | (#35381220)

But is that the spirit of Open Source? Does anyone claim that Open Source was intended to deprive a developer of fair compensation? I don't think so.

The spirit of Open Source is to promote the sharing of ideas and knowledge (thus code). It has nothing to do with developer compensation. In fact.. developers feeling entitled and expecting compensation is against the spirit of open source. You don't get to say "I gave away my labor for free so now pay me". Tough shit. You should have used a different license buddy...

Re:Smart move by Red Hat (1)

blair1q (305137) | more than 3 years ago | (#35381298)

So you're advocating for un-free software?

Good.

Re:Smart move by Red Hat (1)

nurb432 (527695) | more than 3 years ago | (#35381358)

CentOS is playing by the rules. Oracle is not.

Karma (2)

mounthood (993037) | more than 3 years ago | (#35381034)

Oracle wants to obey the GPL license for Java, but not the spirit of the GPL. As you sow, so shall you reap.

Re:Karma (1)

Desler (1608317) | more than 3 years ago | (#35381286)

And how is it not within the spirit of the license to take someone else work, fork it and rebrand it? That happens all the times. Many times with just as little change as probably happens between what is RHEL and what Oracle brands as Unbreakable Linux but no one complains unless it's someone like Oracle doing it. Hell the was an entirely new version of Pidgin whose only change was over a check box option.

Re:Karma (1)

mounthood (993037) | more than 3 years ago | (#35381544)

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.

Re:Karma (0)

Anonymous Coward | more than 3 years ago | (#35381630)

It will go just fine if you fork off OpenJDK. Apache Harmony is not a fork from OpenJDK which caused the patent issues in Oracle vs Google. OpenJDK comes with a patent grant (via GPL) which is the reason behind the IcedRobot fork of android using OpenJDK as a basis.

Re:Karma (0)

Anonymous Coward | more than 3 years ago | (#35381762)

Debian and other open source developers aren't continuously sending representatives to other companies to spew FUD. I've yet to see a Debian representative come to my workplace to spew FUD and bribe my superiors.

Without RedHat's contributions over the years Linux would be irrelevant. Without Oracle we'd just have a lot less FUD and marketing trash around.

The problematic issues arise if... (2)

gwolf (26339) | more than 3 years ago | (#35381166)

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... (1)

burnin1965 (535071) | more than 3 years ago | (#35382176)

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.

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.

Took them long enough... (0)

Anonymous Coward | more than 3 years ago | (#35381388)

Given that 6 years ago Oracle had an 80,000 sqft datacenter full of thousands of RHEL 3 and 4 servers, I'm actually surprised it took RedHat this long to do something about them. They were cut out of some significant revenue by Oracle Enterprise Linux as Oracle standardized on RHEL both internally and for their hosted customers years ago. They had three main datacenters at the time, and I have no idea how many actual RHEL licenses they paid for, but it had to be at least 15,000 back in 2006 or 2007.

I worked at the Texas facility and fixed lots of RHEL boxes. This was before OEL. The facility was meant to support 20,000 servers. At the time, it was supposed to be the largest "Redhat on Dell" deployment in the world.

So what? (1)

fgaliegue (1137441) | more than 3 years ago | (#35382022)

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.

That's the spirit! (0)

Anonymous Coward | more than 3 years ago | (#35382062)

I don't know if it's in the spirit of the GPL or not, but it's definitely in the spirit of being a dick.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>