Welcome to Singularity :-) [LWN.net]

Welcome to Singularity :-)

Posted Mar 7, 2011 15:31 UTC (Mon) by khim (subscriber, #9252)
In reply to: Commitment to Open (Red Hat News) by boniek
Parent article: Commitment to Open (Red Hat News)

I thought the whole idea of GPL was so that no anyone could provide support to the same code.

Well, yes. The idea was that anyone can hack on the same code but author naturally will know it better then anyone and so can charge extra. But as we are moving closer and closer singularitywe find out that author does not keep the knowleadge in his head - it's delegated more and more to the computers (RedHat does not provide customers with just series of raw patches - there are bugs history, discussions, etc; all kept on RedHat's servers). The question about "how much of this precious and valuable knowleadge should be given to competitors?" is an interesting one. Certainly sources must be given for GPL requires that. But what about patch sequences? What about engineer's notes? The question is not as simple as it looks on first glance.

If you don't agree with GPL and its effets maybe you should not use it to licence your code.

But RedHat does agree with GPL. It provides all things GPL requests (source code used to compile binary) but if you want extra - there are price and conditions.

(Log in to post comments)

Welcome to Singularity :-)

Posted Mar 7, 2011 16:27 UTC (Mon) by lmb (subscriber, #39048) [Link]

But little of this is relevant for competitors. (SUSE at least maintains their own tree, anyway.)

The fact that a patch is present might be (saves the effort to identify the upstream commit for a relevant issue) - but that could be deduced by matching the (inter)diff of RHEL kernels against upstream commits with a heuristic matching algorithm. It is certainly not infeasible to do, should anyone's business really depend on it.

So I'm not quite sure what the real goal is, and I don't like the trend (because, you know, humans are herd animals and pick up on each other's ideas ;-), but I don't think it has much impact for anyone who really cares in practice. The message that it sends may or may not be desirable, though. (What, again, was the downfall of the old Unices?)

Well, it's always about $$

Posted Mar 8, 2011 8:01 UTC (Tue) by khim (subscriber, #9252) [Link]

The message that it sends may or may not be desirable, though. (What, again, was the downfall of the old Unices?)

They were expensive. Fragmentation didn't help, that's true, but Windows won because Intel systems were cheaper, not because they were better. And on Intel Windows was cheaper because "full-blown Unixes" needed more expensive PCs.

The fact that a patch is present might be (saves the effort to identify the upstream commit for a relevant issue) - but that could be deduced by matching the (inter)diff of RHEL kernels against upstream commits with a heuristic matching algorithm. It is certainly not infeasible to do, should anyone's business really depend on it.

You can easily identify large patches, but it's much harder to spot small patches which were created to accomodate 2.6.37 patches in 2.6.32. And this is exactly the patches which are interesting for support: they are less discussed and less tested then upstream patches, so they are more likely to contain bugs. They, too, can be identified, but it becomes closer and closer to "real" kernel work... Easier to ask customer to switch to some other kernel... but then RedHat can righfully point out that all problems are related to the switch and not to RHEL.

This is risky game: RedHat bet is that their kernel is better then what Oracle or Novell can offer for RHEL-compatible (==years old) distribution. This may be so, but I'm not sure Oracle and Novell can not do better. If they'll do RedHat's plan may backfire.