Red Hat Stops Shipping Kernel Changes as Patches

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

Comments

I don't see the problem

[Anonymous Coward]

Did they stop shipping diff too?

Re:I don't see the problem

[Josh Triplett]

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

[FunkyELF]

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

[Tubal-Cain]

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

[JackieBrown]

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

[Josh Triplett]

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.

Re:I don't see the problem

[prograde]

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

[dowdle]

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

[Tubal-Cain]

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

Re:I don't see the problem

[Anonymous Coward]

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

[Tubal-Cain]

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

Re:I don't see the problem

[burnin1965]

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

[burnin1965]

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

[Tubal-Cain]

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

[burnin1965]

Ah, okay, that makes sense.

Re:I don't see the problem

[Anonymous Coward]

And replaced with?

Re:I don't see the problem

[SaDan]

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

[Guspaz]

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

[Belial6]

So, does that mean that a RHN subscriber needs to diff the code to make a release that is everything that hasn't been changed, and then a clean room group needs to diff everything that isn't a patch with the full source released by Redhat to get the patches without them being distributed by the RHN user?

Re:I don't see the problem

[Korin43]

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

[hairyfeet]

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.

Re:I don't see the problem

[BeerHat]

"30% of all Linux webservers"... I'd wager to bet that it's a higher number than that. Remember, it's free, and "enterprise grade". But, agreed... Centos is a very, very relevant OS.

Re:I don't see the problem

[Improv]

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

[internettoughguy]

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.

Re:I don't see the problem

[turbidostato]

"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

[Stupendoussteve]

Apparently Red Hat is not making this easy, see the release announcement for 2.6.32.30. Not sure if it's related, but it appears it might be.

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

[MichaelSmith]

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

[guruevi]

All that is necessary to do then is upload the new RH tree to your own git/svn and see what changed compared to either the last RH kernel or the original. This guy: http://en.wikipedia.org/wiki/File:Larry_Wall_YAPC_2007.jpg can probably quote you a Perl script to walk through and diff the whole tree in his sleep.

Re:I don't see the problem

[Josh Triplett]

Still not the same thing; that just gives you the overall diff between RH kernel versions or between the RH kernel and upstream. Other Linux distributions provide full split-out patches and/or git trees of every individual patch they've applied to their kernel, to which many individual changes occur between package revisions.

Re:I don't see the problem

[stoborrobots]

That's interesting. Red Hat claims that they still submit their patches upstream first, but maybe it doesn't all go smoothly...

From that article:

Other distros will not be affected, Red Hat's Stevens says, because the company distributes its kernel changes upstream as well. "The work that we've done should not impede companies from building their own versions of Linux and supporting those for their customers," he says. "All the code we deliver through RHEL is out there. In most cases, the changes that go into RHEL. We already distribute into the upstream kernel. We have an upstream-first policy, where we're developing openly and then later integrating into our tree and then delivering it. So it shouldn't at all impede the community or anybody that's in the business of competing on that."

Re:I don't see the problem

[Guspaz]

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

Where did I say that I run CentOS? I don't, nor do I run RHEL. I've got Windows on my desktop and laptop, Solaris on my file server, and Ubuntu on my VPS. I was simply pointing out that you were incorrect in saying that it's not relevant; your own post here only underscores the relevance, since you're arguing that CentOS has various ill effects on the ecosystem. Something doesn't have to be a positive benefit to be relevant.

Re:I don't see the problem

[makomk]

That's interesting. Red Hat claims that they still submit their patches upstream first, but maybe it doesn't all go smoothly...

I'm guessing they're only submitting their patches to the latest bleeding-edge Linux kernel and not to any of the older kernels that distros are using - so every distro has to figure out what to backport and do their own backports. This means that technically Red Hat aren't lying - all their patches go to an upstream.

Of course, the entire reason that the upstream kernel maintainers are maintaining older kernel versions is to avoid this duplication of effort, and Red Hat are basically doing an end-run around this process.

diff

[Anonymous Coward]

Um. So...

Use diff and get your own patches?

Or am I missing something?

Re:diff

[FunkyELF]

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

[robthebloke]

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

Re:diff

[repetty]

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

Re:diff

[zill]

Question 6.

A + B + C + D = F

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

Re:diff

[Hognoxious]

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?

Re:diff

[jgagnon]

P = NP

Re:diff

[Anonymous Coward]

N=1. duh

Re:diff

[niftymitch]

Question 6.

A + B + C + D = F

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

Too simple... folk that keep up with Linus have A, B, C, D, E+e', F,....
and only miss the RedHat patches and preferences.

      K = RH(L(....),R)
      L(....) is the linux patch stream
      RH() is the RedHat patch process that applies RedHat patches.

Since many patches can be seen upstream a lot can be
done to disambiguate the bits.

To some degree it is only the down stream freeloaders like Oracle that are impacted.
Others live on a live tree branch and will be fine. End users will also not be
badly impacted.

What will be interesting is what Oracle will do to cope.
They do have customers that want patches in the old way...
And they do have customers and perhaps contracts associated with
the patches that discloses the what, when and why... of the change.
i.e. patch 12345 addresses bugz: 67889 that they care about.
i.e. patch 54321 addresses bugz: 98765 in a feature unused.

Outside the kernel is a much larger pile of stuff.
This stuff is often more important than the kernel.
For example how is Oracle going to communicate that SSH
was re-based to 5.8p1 or is SSH patched on top of openssh-2.1.1p4
and does it mater.

The kernel is only a small part of what the important stuff.

But hey this may reset the industry expectations to match
that other OS from the NW part of a continent.

Incorrect news is incorrect.

[Anonymous Coward]

"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

Re:Incorrect news is incorrect.

[makomk]

It doesn't affect CentOS as long as none of Red Hat's patches break anything. Which, in practice, means that it has more of an impact on CentOS users than on CentOS itself, since they're the ones that are going to have to try and diagnose the breakage. (For example, a lot of VPSes run on the CentOS equivalent of RHEL5 and use the same CentOS kernel for every VPS regardless of what distro it is. Originally, the RHEL5 kernel had a patch that changed the kernel ABI in a silly Red Hat-specific way that broke newer glibc versions, causing problems with running newer distros on these VPSes unless the patch was reverted.)

Re:Incorrect news is incorrect.

[Anonymous Coward]

For example, a lot of VPSes run on the CentOS equivalent of RHEL5 and use the same CentOS kernel for every VPS regardless of what distro it is.

That's just stupid. While I do understand that problems can arise from such use of the kernel in question, I find it (very) difficult to care about it.

Good for them

[Anonymous Coward]

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

[Anonymous Coward]

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.

Re:Good for them

[KiloByte]

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

[rubycodez]

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

[Lumpy]

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

[afabbro]

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

[rubycodez]

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

[Anonymous Coward]

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.

Re:Good for them

[Anonymous Coward]

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

Re:Good for them

[hitmark]

Sounds like Microsoft VS IBM in regards to SO/2.

Re:Good for them

[hduff]

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

[alewar]

The Lustre file system used to support RedHat, SUSE and vanilla kernels. After the acquisition by Oracle, only RedHat and OEL are supported. I'd say fuck Oracle.

Re:Good for them

[Lord of Hyphens]

Oracle's fix going forward is probably to say "Everything will only run on Oracle Solaris, now piss off."

Re:Good for them

[mrnick]

They have to release the code but they do not have to make it easy for people to use it.

Re:Good for them

[Midnight Thunder]

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

[TangoMargarine]

You heard it hear first.

Heh, unintended irony :-)

Re:Good for them

[turbidostato]

"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:Good for them

[quickOnTheUptake]

May I suggest that the source is what you feed the compiler. What must be distributed is the source, not all relevant information about the program--including the history of that source. So you aren't required to distribute your internal documentation of the source, even though that might be preferred for the person modifying it.
"Preferred form"--as I have always understood it-- just means, "not a dot matrix printout or punch cards"

Re:Good for them

[KiloByte]

Wrong, there are cases where the preferred form for modification is assembly or even raw binary (think shellcode).

Also, if you go outside languages like C, there is no clear-cut compiler anymore.

Javascript? Would you call the output of minify "source"? It is syntactically correct program text that you can feed to a compiler, yet it's unfit for modification by humans.
PostScript? Unless hand-made (ie, never), it is completely unreadable. Yet it is text and a correct program.
AutoConf? Here the output is a shell script. Does your definition include them?

And what about images? There the "preferred form" is usually not what you'd want to have but the best you can have. Even the author often wishes he kept them in xcf format rather than just flattened files.

Re:Good for them

[rubycodez]

their list of supported platforms for the DBMS is getting smaller and smaller from 10g R2 to 11g

dropped platforms: MacOSX,Windows Itanium, Linux Itanium, Linux PowerPC, Z Linux, Z/os, Fujitsu Siemens BS2000/OSD, HP True64, HP OpenVMS, 32 bit Solaris on Sparc, 32 bit x86 solaris,

What's left is x86 and x64 Windows, x86 and x64 Linux, Solaris on UltraSparc, HP/UX on Itanium, HP/UX on PA-RISC, AIX on PowerPC

CentOS

[theshowmecanuck]

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

[del_diablo]

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

Re:CentOS

[pak9rabid]

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

[Linker3000]

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

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

[Anonymous Coward]

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

[garaged]

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

[peragrin]

you need to add a sarcasm tag.

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

Re:CentOS

[Anonymous Coward]

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

[Framboise]

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

[bsDaemon]

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

[blivit42]

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

Um, wouldn't that be openSUSE?

Re:CentOS

[Tubal-Cain]

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

[ePhil_One]

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.

Re:CentOS

[scruffy]

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

Re:CentOS

[h4rr4r]

Nope, openSUSE is their version of fedora.

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

Re:CentOS

[theshowmecanuck]

Even if they are not pocketing money they are still taking money. Start using critical thinking. It is the equivalent of a big corporation who I am sure you would jump all over if they started giving away a product for cheaper than it cost them to build, harming a company you really like by driving them out of business. Granted CentOS hasn't driven Redhat out of business, but it is still giving away Redhat's product for far cheaper than it costs to create, and taking business away from Redhat. But I am sure you selfish spoiled fanboy sentiments won't allow you to realize that. For profit distros are the only reason that Linux is available to you today, unless of course you are one of only a handful of people who like to build every single piece of software from scratch from all the different project's repositories. Which I sincerely doubt. Even Ubuntu is a for profit company. So go back to your mother's basement in a huff and whine about people like me who are concerned when the people who actually create the work are cut off at the knees by people who make it less worthwhile to fight create the distros, fight off asshats like SCO and Oracle, and sponsor so many projects. You probably use CentOS and never paid for shite. At least my conscience is clear on that regard. I pay for my software. Keep on leeching asshole.

Re:CentOS

[hairyfeet]

Hi MR AC! How EXACTLY is he trolling? Whether you like it or not R&D costs money and whether you like it or not developers need to get paid and without that R&D and those developers the entire community is in worse shape get the picture?

What nobody here in the FOSS community is willing to accept is the tragedy of the commons works JUST AS WELL in software as it does anywhere else. It is the classic "free rider" problem where too many free riders and the bus line shuts down. According to an earlier poster 30% of webservers are running CentOS. Now just imagine how much farther along RHEL would be if those 30% paid which would give them 30% more for R&D and hiring developers. NOW do you get it?

You want to know why you haven't made serious inroads against Apple and MSFT here you go, it is because by having most of the customers pay they are able to leverage several times more developers and R&D than you can muster. Or are you gonna sit here and argue some guy coding in his basement is equal to several $100k+ developers with years of experience?

If you just want to take without giving that is your business but don't act like RH will magically just make up the money, they won't. Less money means less developers and less R&D and that means less improvements for Linux as a whole. it really isn't rocket science folks.

Re:CentOS

[Improv]

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.

Re:CentOS

[Anonymous Coward]

>>30% of webservers are running CentOS. Now just imagine how much farther along RHEL would be if those 30% paid

And there is your fallacy. Which is the same fallacy RIAA has with piracy. "X billion people pirate; imagine if they paid instead!"

What you fail to realize is that chances are that if CentOS didn't exist, those same people probably wouldn't turn around and pay Red Hat. Instead, they would probably find another free linux distro to use.

You also fail to realize that there are likely people who used CentOS, and said, "gee, I like this, I should use Red Hat and get the support".

IF you were correct, THEN Red Hat would be failing. Just like IF RIAA was correct, THEN the music industry would be dead. But since your model of reality fails at that basic level of prediction, it shows how your model is FAILED.

Like I said, troll harder.

Re:CentOS

[hairyfeet]

Nice straw man you built there, don't mind the match...WHOOSH! The reason your straw man just went up (although he did make such a lovely flame) is that A.-The RIAA are the leeches in the middle kinda like CentOS, and B.-Unlike the RIAA RH actually gives back to the community and with HUGE amounts of code at that.

So is your argument that there is no such thing as the "tragedy of the commons" or is it that "RH can afford free riders"? Look it is simple, okay? RH sells product and gives back to the community, the more product it sells the more it is able to give back to the community in the form of developers, bug fixing, and R&D.

And if your argument worked, why is RH doing this, hmmm? Shouldn't your argument apply equally to Oracle? A free rider is a free rider, right? After all BOTH cost RH money in lost sales and ability to compete thanks to less dollars for R&D.

While you may like to pretend that FOSS is nothing but guys in their basements coding for fun nothing could be further from the truth. FOSS is supported by large corporations like RH that frankly are making maybe 1/10th what a proprietary company would make thanks to so many in FOSS caring about nothing but "free as in beer!"

But don't take my word for it, watch Canonical. After bleeding millions without ever seeing a dime trying to make Linux more user friendly I bet as a last resort they will start charging for Ubuntu. It'll be cheap, but that won't matter because the "free as in beer!" brigade will HOWL with rage and get everyone to switch to anything other than Ubuntu and Canonical WILL die. Then you can go back to having the same upstream caca repackaged 80 ways to Sunday with ZERO R&D going to UI.

But hey, getting stuff for free never hurts anyone, right? I wonder how many out of work developers would be on the RH payroll if just 10% of those servers paid.

Re:CentOS

[quickOnTheUptake]

Okay, I'll bite:

but it is still giving away Redhat's product for far cheaper than it costs to create

Two issues here. First, what does it cost RH to create RHEL? Per copy I mean, not total. Copies cost nothing, per se. There is only a cost of sorts if the person opting for the free version was willing and able to pay for the pay version. (This btw, is precisely the reason that piracy is different from theft: The creator isn't deprived of what he had, and he isn't even deprived of a lost sale unless the pirate would have paid had he not been able to get it free.)
This brings us to the second point: RH's real product (in the sense of what they are selling) is a professionally supported distribution. The reason people pay for RHEL is so they have someone to call when they need it fixed. If you want someone else's ass on the line if things go south, CentOS is not competition.

For profit distros are the only reason that Linux is available to you today, unless of course you are one of only a handful of people who like to build every single piece of software from scratch from all the different project's repositories.

Guess you haven't heard of Debian (and before you write Debian stable off as not being practical for desktop users, there are plenty of not-for-profit polished desktop distros based on testing or unstable: crunchbang, atopsid, and mint-debian jump to mind, to say nothing of those of us who just run sid), or Arch, or slackware, or Gentoo.

So go back to your mother's basement in a huff and whine about people like me who are concerned when the people who actually create the work are cut off at the knees by people who make it less worthwhile to fight create the distros, fight off asshats like SCO and Oracle, and sponsor so many projects. You probably use CentOS and never paid for shite. At least my conscience is clear on that regard. I pay for my software. Keep on leeching asshole.

Just fuck off.

Re:CentOS

[quickOnTheUptake]

The difference between Oracle and CentOS is that CentOS isn't selling the same product as RH: RH is selling a professionally supported OS.
CentOS isn't.
Oracle is.
The people using CentOS are the people willing to take the risk of administering their own systems without vendor support.

Re:CentOS

[theshowmecanuck]

First, what does it cost RH to create RHEL? Per copy I mean, not total.

OK, if it is cheap, roll your own distro of the quality Redhat produces. If you are doing that by yourself, I expect to hear back in about ten years. Assuming that you aren't thrown out on the street because you haven't been able to pay your rent or mortgage or starve to death because you haven't earned any money and can't buy food. Yes that's right. Doing work with no income is impossible. And if Debian were good enough to worthy of being called a usable desktop environment Ubuntu would never have taken off. What gets more downloads? Debian or Ubuntu. One is based on the other. But one is usable and the other isn't. That is why one can make money off of the services they sell for the version that has had a ton of improvements made to it. And if they could sell services for that, no one would be using it because the company would not be able to produce it. Get it. Only by making money can a Linux distribution exist. That is because it is expending money producing the distro with all the value added tools and packaging that they do. Tools and packaging that make it usable by more than just hard core geeks. So get your head out of your ass, you've developed brain damage from the lack of oxygen. But it sounds like perhaps it is too late. You are a fucking leeching retard already. Go suck on Stallman's cock some more.

Re:CentOS

[quickOnTheUptake]

OK, if it is cheap, roll your own distro of the quality Redhat produces. If you are doing that by yourself, I expect to hear back in about ten years. Assuming that you aren't thrown out on the street because you haven't been able to pay your rent or mortgage or starve to death because you haven't earned any money and can't buy food. Yes that's right. Doing work with no income is impossible.

You completely ignored my question--and instead have insisted on repeating the same naive point you made originally. If CentOS is distributing RH's work for free to people who aren't willing to pay RH for support RH is not losing anything; The people using CentOS aren't lost sales.
Think of a webhosting company with hundreds of linux servers, who are ready to handle it all in house. And they are not willing to pay a per copy annual cost for outside support. So they were never considering RHEL. If CentOS didn't exist they would use debian or another free linux. Again, this does not constitute 100's of lost sales for RH. What it does constitute is free testing.

And if Debian were good enough to worthy of being called a usable desktop environment Ubuntu would never have taken off. What gets more downloads? Debian or Ubuntu. One is based on the other. But one is usable and the other isn't.

You don't know what you are talking about. There are plenty of quite polished, not-for-profit distos based on Debian testing. I listed some. Yeah, they might not have the marketing that Ubuntu has had, but they are quite good, and have not a few users. If you have found that none of them is usable then you really shouldn't be allowed near a computer. But I suspect you probably haven't used any of them. Frankly I find Ubuntu painful: crazy memory bloat and updates that periodically break random things.

So get your head out of your ass, you've developed brain damage from the lack of oxygen. But it sounds like perhaps it is too late. You are a fucking leeching retard already. . . .

Actually I'm not. I don't use, nor have I ever used, CentOS; I use Debian. You know, the non-commercial distro that's "not usable on the desktop".
Out of curiosity, can you show me one place where RH has made this attack on CentOS and accused them of leaching?

Re:CentOS

[petermgreen]

According to wikipedia the first fedora release was in 2003 while the first centos release was in 2004.

I remember the various RHEL rebuilds (and centos wasn't the first) being a reaction to the fact that red hat linux (not enterprise) had been dropped and that fedora was an unstable bleeding edge distro (note: I was only watching from the sidelines at the time).

Re:CentOS

[theshowmecanuck]

You are naive. The reason they are not paying Redhat is because they are leeches and are taking CentOS for free. If they only had the choice of Redhat or nothing then they would pay. i.e. If CentOS would stop leeching and stop distributing something for free that someone else put a lot of money in to create. Get a fucking grip. Yeah Redhat isn't losing revenue because someone is giving their product away for free. That was sarcasm. And I don't have to point out where Redhat is making an attack on CentOS. I am making the attack on CentOS. I don't like the business model of taking something that someone has spent money on developing and giving it away for free. Just because you can doesn't mean it is right or moral. GNU was created originally because Stallman didn't like the fact that he couldn't customize his closed source drivers. It wasn't meant as a way to not have to pay for stuff. Or as a way to take others work and give it away for free. As for operating systems, I have programmed on Unix (HP-UX, AIX, Solaris) for more than ten years. I have used Linux for a dozen years but mostly use Windows now since I don't have the patience required to continually configure things and that programs I use (like Cubase) don't run on Linux and Linux has no equivalent. And I do agree with you, Ubuntu is not exactly the most effecient, but it is easier for the average user than just about any other distro. But I believe Suse to be about the best. Especially if you get the paid for version. As far as servers go, I'd rather get a Unix server. If I have to use open source for a server I'd rather take BSD or PAY for Redhat.

Re:CentOS

[Anonymous Coward]

Maybe openSUSE is "good enough" for people that want a free SUSE?

Indeed it may very well be, but it's not the equivalent of CentOS (et al) relative to RHEL, which was the point.

CentOS Impact?

[burnin1965]

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?

[thatseattleguy]

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?

[bill_mcgonigle]

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?

[nettdata]

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?

[JustinOpinion]

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?

[burnin1965]

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.

Re:CentOS Impact?

[Anonymous Coward]

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.

Re:CentOS Impact?

[digitalhermit]

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?

[devent]

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?

[gbjbaanb]

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?

[Doctor_Jest]

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?

[JamesP]

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?

[burnin1965]

Canonical is developing patches but they are now making only the complete Kernel as a tar ball available

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?

[Anonymous Coward]

http://oss.oracle.com/

Re:CentOS Impact?

[bill_mcgonigle]

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?

[Anonymous Coward]

I'm a long-time Oracle DBA, and could care less about this little war.

So why don't you?

Re:CentOS Impact?

[JamesP]

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?

[Anonymous Coward]

spoken like a true oracle dba

Re:CentOS Impact?

[fnj]

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.

Re:CentOS Impact?

[bill_mcgonigle]

Slightly different goals between the projects, but they sure could share a bunch of common effort. CentOS has a slightly harder job in that they're going for bug-for-bug compatibility with RHEL and so they have to spend time hunting down obscure dependency problems. SL will grab a package from Fedora if needed to build something, and that works fine for the end user, but the binary won't have the same hash as the RHEL binary. CentOS will have to track down exactly the right version of the dependency that generates that identical build.

Re:CentOS Impact?

[stoborrobots]

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.

I'm confused too. Red Hat says they still submit their patches upstream first, but then some kernel developers suggest that they poke around in the release kernel instead. I'm not sure which is which, whether RH is playing dirty, or whether there are specific incidents which are causing problems in an otherwise supportive relationship...

Re:CentOS Impact?

[nobodie]

I am something of a RH fan boy, so my two cents is not balanced. Still, they have made mistakes in the past, admitted them, corrected them and moved on. I have trust that if this turns out to be wrong, or even not completely straight up, they will admit a mistake and repair the damage as best they can.

I don't have a lot of stock in the market, but i trust what I have with red hat, they try to be honest at least.

Re:CentOS Impact?

[makomk]

They're fed back into the bleeding-edge kernel that isn't of much immediate use to distros. What Red Hat doesn't seem to be doing is consistently feeding them in the upstream long-term support kernels that all the distros use. Basically, the Linux kernel developers are maintaining specific older versions of the kernel with fixes in order to allow distros to use them without having to manually find and backport the patches themselves. This saves duplication of effort. Red Hat is alone in not co-operating with this effort, and in fact this change in policy is actively sabotaging it by making it harder for the 2.6.32.x maintainers to stop it drifting out of sync with the distro kernels that are nominally also 2.6.32-based.

Re:CentOS Impact?

[Anonymous Coward]

SL will grab a package from Fedora if needed to build something, and that works fine for the end user, but the binary won't have the same hash as the RHEL binary.

The kernels will (and do), as far as I know. Whether it matters, I don't know, but it's at least somewhat related to the main topic of the thread.

diff(1)

[LizardKing]

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

[Andy Dodd]

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)

[Kjella]

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)

[idontgno]

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)

[Desler]

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)

[wonkavader]

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

[idontgno]

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)

[idontgno]

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)

[Desler]

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)

[Desler]

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)

[steveb3210]

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)

[Anonymous Coward]

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)

[youn]

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)

[GooberToo]

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)

[Anonymous Coward]

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

Re:diff(1)

[Hognoxious]

What about the CentOS plus 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)

[ePhil_One]

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

[Anonymous Coward]

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"

Re:Bad

[jthill]

If you're troubleshooting problems in Red Hat kernels, call Red Hat and they'll show you how to access the individual patches. I'm guessing there's some reason you can't do that, though.

Re:Bad

[Anonymous Coward]

What the TFA or any article fails to mention is that those with actual support licenses get full access to the un"obfuscated" patch list. So, as long as you're a downstream engineer with a support license, hey, have fun.

GIT and branches can easily handle it

[trelony]

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?

[Verunks]

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?

[idontgno]

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?

[Anonymous Coward]

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.

Re:Why Harder?

[Anonymous Coward]

Everyone thinks that Red Hat is hoarding patches. They actually get the changes accepted upstream first and then backport to RHEL.

Smart move by Red Hat

[Anonymous Coward]

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

[Desler]

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

[blair1q]

So you're advocating for un-free software?

Good.

Re:Smart move by Red Hat

[nurb432]

CentOS is playing by the rules. Oracle is not.

Re:Smart move by Red Hat

[Anonymous Coward]

Strawmen. Lots of them. In your post.

It's about the services, you blithering moron. Until you at least can pretend to argue about what the whole things is actually about (hint: It's got nothing to do with GPL or the sales of software.) you're very much not contributing anything to the discussion.

Karma

[mounthood]

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

[Desler]

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

[mounthood]

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

[Anonymous Coward]

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

[Anonymous Coward]

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.

Re:Karma

[Anonymous Coward]

Then GPL-V66 shall add the karma:

This source can't be used by:
            - companies who have open patent litigation with open source projects.
            - patent trolls

The problematic issues arise if...

[gwolf]

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

[burnin1965]

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.

Huh ? What?

[Anonymous Coward]

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

Orachole is run by idiots

[Anonymous Coward]

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

[judeancodersfront]

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:Orachole is run by idiots

[Daniel Phillips]

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.

Took them long enough...

[Anonymous Coward]

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.

You don't like Open Source

[pavon]

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

[theshowmecanuck]

Blah blah blah... keep leeching.

Re:You don't like Open Source

[gstoddart]

Blah blah blah... keep leeching.

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:You don't like Open Source

[Vegemeister]

Cower some more, feeb.

No, just search the diff

[gr8_phk]

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

Diff the subdirectories

[gr8_phk]

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.

So what?

[fgaliegue]

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.

Re:So what?

[Anonymous Coward]

How big a twit you have to be to play "so what" as if you actually knew anything about the matter, when a large part of RedHat kernel engineers themselves are quite angry with this policy (which has been dictated by their CEO)?

Re:So what?

[fnj]

And how big of a twit do you have to be completely misinterpret the observations and make completely off topic charges?

That's the spirit!

[Anonymous Coward]

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.

So what?

[93 Escort Wagon]

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?

Didn't Apple do something like this ?

[Celarent Darii]

Not long ago Apple released the source for Safari as one big repository. The Konqueror people complained that they couldn't apply the changes. Apple seen as an enemy of opensource, yet the source is still available on the net.

How is this situation different? Can someone enlighten me?

Re:Didn't Apple do something like this ?

[DataDiddler]

The difference is no one cares about Safari or Konqueror.

What happened to 'upstream upstream upstream'?

[jdogalt]

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.

CentOS is F5 Networks (Go Red Hat)

[IBitOBear]

I briefly worked at F5 Networks. They are "the community" behind CentOS. They had an in-house extension to call whenever you found any RedHat Branding in CentOS. The entire "distribution" was created so that they could put Red Hat into their enterprise load balancers without having to do that pesky licensing and fair dealing thing.

I am all for Red Hat doing whatever they want in this respect to CentOS, as CentOS is an unfair deal in the first place (IMHO of course).

Nohting in the GPL requires the source to be delivered as base plus patches. Red Hat was bing a good citizen. Others were being less so. Red Hat decided to play the field provided.

It is a loss to the honest people, but dishonesty is always a loss to the honest people eventually. If CentOS et al were engaged in something more than just scraping the serial numbers off of other people's work, then I would be more upset.

Stealing other peoples earned reputation by re-marking it as your own with little-or-no attribution is bound to invoke human nature against you eventually. It was only a matter of time. I bet Red Hat will _also_ make the patches available to those who ask. That is, just because their default distribution is a pre-patched blob, and lets face it, everyone was applying the whole patch set by default anyway, doesn't mean that the patches are going to be kept in a vault somewhere. Maybe "asking for it" will require a support contract. Maybe it will just require asking. Who knows.

But if Red Hat manages to make F5 pay what they should have paid in the first place instead of spending a like amount on "running a distribution" chop-shop maybe the fair dealing would have never caused this sort of thing in the first place.

(And yes, I have a problem with F5.)

Re:CentOS is F5 Networks (Go Red Hat)

[sourcerror]

"The entire "distribution" was created so that they could put Red Hat into their enterprise load balancers without having to do that pesky licensing and fair dealing thing."

If that were the case, they weren't sharing it with the world.

"It is a loss to the honest people, but dishonesty is always a loss to the honest people eventually. If CentOS et al were engaged in something more than just scraping the serial numbers off of other people's work, then I would be more upset."

Centos is prohibited to advertise the fact that it's based on RHEL. Look up Red Hat's policy on trademarks.
By the way, Red Hat isn't the only contributor to FOSS (although the biggest one), so they also take other people's work as well.
Also, Red Hat doesn't have a problem with Centos (said by Red Hat seniors), if they wanted, they could make things much harder for them.

It isn't the sources, its the effort...

[IBitOBear]

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?

Re:It isn't the sources, its the effort...

[Anonymous Coward]

They have a somewhat okay web interface for looking at the individual patches for paying customers here: https://access.redhat.com/knowledge/sources/

captcha: desolate

Re:It isn't the sources, its the effort...

[hairyfeet]

And you notice how I went from Insightful to Flamebait the second the FOSSies found out someone was pointing out one of their sacred cows was bullshit? Surprise surprise FOSSies can't face reality. That is why I point out the difference between a FOSS advocate and a FOSSie, who like a Moonie is all about dogma and bullshit instead of doing what is best for the community.

And the fact that CentOS was cooked up by those too damned cheap to simply pay a license (even though I'm sure RH is happy to work with a vendor and provide bulk rates) while at the same time wanting the fruits of their labors surprises me not one bit. Why is it so hard for FOSSies to understand that everything has a cost and the tragedy of the commons is all too real?

For all the FOSSies out there, it is just simple math. Red Hat uses the money they get from RHEL to make Linux a better OS by providing developers to the community, fixing bugs, and providing much needed R&D. Do you think the shit jobs will get done if nobody pays for them? The more leeches like CentOS you have that take what others create while giving nothing in return the less the ENTIRE community has because RH loses money they would have otherwise gotten, which leads to less employees, which leads to less code for you to enjoy. See how it works?

If CentOS were to blow away tomorrow while I'm sure there are some that would rather go through an entire server OS migration rather than spend a dollar I bet many would go with RH thanks to their excellent management tools. That money in turn would flow back into the community thanks to the increased output by RH which has been beyond generous when it comes to sharing.

Is that really so hard to understand? Or are so many just so damned greedy that the thought of giving back to the company that makes so much happen really so disgusting to you you'd rather run more than 30% of the world's webservers on a cheap knockoff rather than give back? Is this REALLY the sharing spirit that we hear so much of with FOSS? Just a variation of "I got mine so fuck you"? How sad is that,, or the fact that nobody can even point out how in the long run you are slitting your own throats by hurting the very company who does so much to advance Linux without getting attacked. How sad indeed.

This is why I'm just gonna block Linux articles from my /. as the hypocrisy and bullshit is getting a little too thick for my tastes. At least Apple and MSFT never pretend to be anything other than what they are, but while FOSSies love to talk about share and share alike they certainly don't want to share a dime with the company working their ass off to make Linux better. How sad.

Re:It isn't the sources, its the effort...

[Improv]

I imagine you were marked as flamebaiting because you pepper your posts with insults rather than just saying what you're trying to say.

oh boohoo

[johncandale]

oh boohoo. opensource != redhat works for you.

An awful lot of baby in that bathwater

[IBitOBear]

There are always leachers, big and small. There are always griefers, big and small. The system works inclusive of the leaching and whatnot.

Progress and cash are not inextricably linked in open source. Not even close.

Measuring things by the outliers is never correct.

So you just soak up the dumb while you soak up the smart.

But if you hide from the extremists of any ilk you give them a chance to sneak up on you.

Re:An awful lot of baby in that bathwater

[hairyfeet]

Well considering Linux has been sitting at 1% for quite awhile and even Ubuntu is losing share (Gasp! He told the truth again! Smite him!) I kinda doubt Linux is gonna be "sneaking up" on anything which was kinda my point.

And whether you or the "community" want to admit it or not well written code and world class server and desktop OSes don't come from magical RMS pixies they come from top notch developers working their asses off and in this economy I doubt VERY seriously you are gonna be seeing many of the top talent working "for the good of the community".

Why does Apple and MSFT have desktop usability light years ahead of Linux? Because they have the money to pay people to do the shit works, which there is a hell of a lot of. Bug fixing, QA, regression testing, nobody LIKES these jobs but they simply have to be done, except by and large in the FOSS model they don't.

The ONLY reason FOSS has gotten as far as it has on the server is companies paying millions to make it happen, full stop. Look at any LOC count and you'll see RH nearly always number one or two. What happens when fewer and fewer people pay? It is simple math, less money for R&D, less money for QA and regression testing, less money for developers and less code for the community as a whole it is a classic tragedy of the commons case.

Look at how many major FOSS companies have been bought out or are barely alive, if the FOSS model worked, why is this so? It is because the FOSS model was born in a time of abundance and now that we are in another depression the well is running dry. More and more free riders and less and less paying customers and what do you get? Less for all.

Seriously is it any wonder so few companies want to offer a native FOSS version of their programs? The "free as in beer!" brigade grows ever larger while simultaneously the amount of paying customers stagnates or even falls. It is simple math folks, the less RH gets the less it can share, period. In any other model the developers have legal repercussions that can at least keep free riders to a manageable level, not so in FOSS. That is why I believe as the economy grows ever more sour so too will the free riders simply cause too much drain on FOSS and cause it to fall behind while companies like Apple and MSFT are able to make gains and get farther and farther ahead. It is just simple math and all the shouts of "free as in beer!" won't change the figures.