Slashdot Mirror

Well, MPEG-LA right now is ignoring patent infringement by individuals, otherwise they might be suing Linus Torvalds for patent infringement. In this post, he clearly is using the unlicensed patent encumbered gstreamer ugly plugins:
https://bugzilla.redhat.com/show_bug.cgi?id=439858#c19

It is in rawhide now:

http://download.fedora.redhat.com/pub/fedora/linux/development/rawhide/x86_64/os/Packages/kernel-2.6.37-1.fc15.x86_64.rpm

Which means it will definitely be in the next release.

The future probably belongs to SPICE, which redhat (a company who do know how to develop open source code) are creating for remote access to virtualised systems.

SPICE = Simulation Program with Integrated Circuit Emphasis, come on redhat get creative.

I've gotten 20 fps for 1280x1024 3D graphics -- over a 2 Mbit connection.

On the other hand for usable browsing and general desktop sessions NX doesn't need close to 2Mbit, it works well for me at 56kbit. So it's horses for courses, I guess.

It's not the VNC protocol that gives you your good 3D performance, it's the architecture of VirtualGL. I don't think there's a good reason VirtualGL couldn't be made to work with NX as well as VNC.

The future probably belongs to SPICE, which redhat (a company who do know how to develop open source code) are creating for remote access to virtualised systems.

Here's one of the better criticisms of dropping SUID, and it's from an Openwall developer. These criticisms are echoed by almost everyone thinking about removing SUID.

There's a lot of talk lately regarding replacing the SUID bit on program
binaries in Linux distros with filesystem capabilities. Specifically,
Fedora and Ubuntu are heading in that direction.

Fedora:
http://fedoraproject.org/wiki/Features/RemoveSETUID
https://bugzilla.redhat.com/show_bug.cgi?id=646440

Ubuntu:
http://www.outflux.net/blog/archives/2010/02/09/easy-example-of-fscaps/
https://wiki.ubuntu.com/Security/FilesystemCapabilties

While in general this is a good idea, there are issues with it, in
arbitrary order:

- Some currently-SUID programs are aware of them being (potentially)
SUID, and will drop the "more privileged" euid when it is no longer
needed, but they will probably not be aware of them possessing
capabilities. This may result in larger parts of the programs
(sometimes orders of magnitude larger) running with elevated privileges
(or with allowed-to-be-elevated privileges, which is a privilege on its
own and is usable through vulnerabilities that allow for arbitrary code
execution). Let's consider ping, which appears to be the classical
example of "where filesystem capabilities will help" (or so it is
claimed). IIRC, it starts by acquiring a raw socket (NB: of a certain
somewhat-limited type), then drops root privs (if it was installed SUID
root and run by non-root), then proceeds to parse the command-line,
resolve the provided hostname, and so on. If the SUID bit is replaced
with cap_net_raw+ep, as seen in Kees' example above, will ping know to
drop this capability? Hardly. Not without a source code patch.
Besides, dropping the capability might [need to] require privileges
beyond CAP_NET_RAW itself (recall the capability-dropping attack on
sendmail from a decade ago). So does moving from SUID root to
cap_net_raw+ep improve security? Most likely not. On the contrary, it
results in hundreds of lines of ping's code and thousands of lines of
library code (DNS resolver) running with elevated privileges, as
compared to just a few lines of ping.c, which was the case with simple
SUID root. Granted, those "elevated privileges" are a lot less than
root privileges, but they're a lot more than having a single raw socket
of a specific type.

- In some cases, the capability sets being granted are (almost)
equivalent (or expandable to) full root powers. This is seen in:

http://people.fedoraproject.org/~dwalsh/policycoreutils_setuid.patch

-%attr(4755,root,root) %{_bindir}/newrole
+%attr(0755,root,root) %caps(cap_audit_write,cap_setuid) %{_bindir}/newrole

-%{_sbindir}/seunshare
+%attr(0755,root,root) %caps(cap_setuid,cap_dac_override,cap_sys_admin,cap_sys_nice) %{_sbindir}/seunshare

This mostly just sweeps the SUID root under the rug, where the sysadmin
will hopefully not see it and thus feel safer. However, it may expose
more problems in the programs if they knew to drop root, but wouldn't
know to drop the capabilities (same issue I described above for ping).

Granted, vulnerabilities of certain classes might become unexploitable
or be partially mitigated. For example, if no direct code execution is
possible (not a buffer overflow, etc.), but "only" privileged access to
an attacker-provided arbitrary pathname is possible, then "newrole"
above would be protected, but "seunshare" above would not (because of
cap_dac_override).

- Completely getting rid of SUID root pro

http://www.redhat.com/

I mean, they only have hundreds of millions of dollars in revenue each year...

Wait, how does a pro-open source tech site having majority Windows using readers prove open source is the biggest threat to Microsoft? You don't know the proportion of Windows users that are interested in Linux, you only know the proportion of tech site readers that use Windows. Are you really extrapolating tech site readership out to the general population?!

Read what I wrote. It wasn't ME making the claim. Microsoft's filings with the SEC make the claim that linux and open source are their biggest threat.

Better yet, Ballmer has been saying that linux is the #1 threat since 2001

June

Microsoft's Ballmer calls Linux the biggest threat to Microsoft.

And they also admitted it to the SEC in official filings in 2009

So, why are they so scared? Because it threatens their stack, which includes Office, their one true cash cow.

They've never turned an annual profit with servers.

They've been a complete loss in terms of revenue from HPC, and are abandoning the field.

Ditto for corporate projects like the stock exchange mess, that they totally failed at.

Windows doesn't bring in all that much money. Most people simply don't buy it retail. The real money is in the "software assurance" program, and in Office. Get rid of those, and Microsoft is a perennial money loser.

And linux has been used as a threat to dump the software assurance program, which most businesses don't need, since they can now get by with doing a cheap hardware refresh instead with the money they save. Desktops no longer cost $2k apiece.

So that leaves Office. The one solid, year-in, year-out, for 15 years #1 profit center. And people are asking "why upgrade any more? What I've got is good enough."

If you don't need to upgrade, and the vendor tries to force an upgrade on you, and you have a choice, it's time for the vendor to cut prices. Office will continue to be a cash cow for the next decade, but that's about it.

I don't come here to be enlightened. I come for a fight.

Well, at least you're up front about your pro-ms trolling ...

I assume you're talking about client-side performance? If so, then yes it should be much better in RHEL6.

FWIW, The NFS tools don't really do much once you've got the filesystem mounted. (Ok, that's not 100% true with NFSv4 or Kerberized NFS but it is for the most part). Performance problems like this are generally in the kernel. I've got a patchset queued up to try and improve NFS write performance in RHEL5, but it probably won't go in until 5.7.

See this page if you want to test out what I have queued up so far. It's still pretty rough, but the results so far are quite promising:

        http://people.redhat.com/jlayton/

If you have a support contract, you should open a support case on this. Typically, performance problems are all about numbers so if you can quantify the problems you're seeing then we should be able to help.

From the standard RHEL channel, there is a postgresql84 package available for RHEL5 that swaps the stock PostgreSQL 8.1 for 8.4, introduced during the version 5.5 update of RHEL. That's the precedent I was citing.

https://access.redhat.com/support/policy/updates/errata/

10 years these days.

https://access.redhat.com/support/policy/updates/errata/

RHEL support is good for 10 years these days.

No official link given in the OP, but here's the Red Hat blog post, titled "Red Hat Enterprise Linux 6: A Technical Look at Red Hat’s Defining New Operating Platform", which gives a good look at some of the changes.

The less-interesting press releases are here (Red Hat Enables Expanded Deployment Flexibility and Application Portability with Red Hat Enterprise Linux 6) and here (Red Hat Sets a New Standard for the Next Generation of Operating Systems).

No official link given in the OP, but here's the Red Hat blog post, titled "Red Hat Enterprise Linux 6: A Technical Look at Red Hat’s Defining New Operating Platform", which gives a good look at some of the changes.

The less-interesting press releases are here (Red Hat Enables Expanded Deployment Flexibility and Application Portability with Red Hat Enterprise Linux 6) and here (Red Hat Sets a New Standard for the Next Generation of Operating Systems).

No official link given in the OP, but here's the Red Hat blog post, titled "Red Hat Enterprise Linux 6: A Technical Look at Red Hat’s Defining New Operating Platform", which gives a good look at some of the changes.

The less-interesting press releases are here (Red Hat Enables Expanded Deployment Flexibility and Application Portability with Red Hat Enterprise Linux 6) and here (Red Hat Sets a New Standard for the Next Generation of Operating Systems).

Finally. I've been running RHEL6 Beta on my new work laptop and was about to give up hope on this and literally was going to install Fedora 14 in the next few hours.

I will be installing Fedora 14 for my personal laptops (two down last weekend, two to go. We're a family of 4 kids, 2 adults).

But, instead I will be installed RHEL6 tonight for my work laptop and Friday for my work desktop (currently on Fedora 12, which is pretty much on par for the versioning as RHEL6). We've got spare EL licenses for server not yet deployed, so I'll use those until CentOS 6 ships. Once it does, I'll side-grade and free up the EL licenses.

Interesting, I've never heard of RHEL referred to as "RELL" as they do in this promo video: RHEL6 promo video

added 1800 features

some of which can be found on the product overview page.

RHEL provides a 7 year lifecycle, which is unmatched by the other major distributions I know about (even Debian). This is crucial for the enterprise; I know of a number of systems which are still running RHEL3 after 6-7 years. Upgrading production computers is not a trivial process, and 2-3 year lifecycles just don't cut it in some situations.

According to ftp://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/os/SRPMS/ , the included version of PostgreSQL is 8.4.4. I know that PostgreSQL was released about a month ago and that this is an enterprise release subjet to more tests... but this new version has important features (Hot standby, Streaming replication) for a production environment.

Does anybody know if RH will update the PostgreSQL version as a manteinance package?

If you mean Red Hat Enterprise Linux, yes. I know that my last companies used them for their Linux machines. Red Hat has many customers some of them big names like Qualcomm and NTT Telecom.

A new major version has been under development alongside PHP 5 for several years. This version was originally planned to be released as PHP 6 as a result of its significant changes, which included plans for full Unicode support. However, Unicode support took developers much longer to implement than originally thought, an the decision was made in March 2010[13] to move the project to a branch, with features still under development moved to a trunk.

PHP currently does not have native support for Unicode or multibyte strings; Unicode support is under development for a future version of PHP and will allow strings as well as class, method, and function names to contain non-ASCII characters.

Initial support for Unicode and multiple character encodings (still buggy as of version 1.9)

Internally, Zarafa uses the windows-1252 charset just about everywhere. This means that we're storing the entire subject, to, from, etc in windows-1252. Only at the moment that the message is converted to an outgoing RTF822 message for SMTP, is the charset conversion done to follow various RFC822 standards.

I have my own bug for this on the Red Hat Bugzilla, which made it blocker for me, but I wonder how somebody could write in the 21st century a groupware server which is capable of working only with windows-1251 charset.

http://www.redhat.com/magazine/008jun05/features/schedulers/

FYI, the IO scheduler and the CPU scheduler are two completely different beasts.

The IO scheduler lives in block/cfq-iosched.c and is maintained by Jens Axboe, while the CPU scheduler lives in kernel/sched*.c and is maintained by Peter Zijlstra and myself.

The CPU scheduler decides the order of how application code is executed on CPUs (and because a CPU can run only one app at a time the scheduler switches between apps back and forth quickly, giving the grand illusion of all apps running at once) - while the IO scheduler decides how IO requests (issued by apps) reading from (or writing to) disks are ordered.

The two schedulers are very different in nature, but both can indeed cause similar looking bad symptoms on the desktop though - which is one of the reasons why people keep mixing them up.

If you see problems while copying big files then there's a fair chance that it's an IO scheduler problem (ionice might help you there, or block cgroups).

I'd like to note for the sake of completeness that the two kinds of symptoms are not always totally separate: sometimes problems during IO workloads were caused by the CPU scheduler. It's relatively rare though.

Analysing (and fixing ;-) such problems is generally a difficult task. You should mail your bug description to linux-kernel@vger.kernel.org and you will probably be asked there to perform a trace so that we can see where the delays are coming from.

On a related note i think one could make a fairly strong argument that there should be more coupling between the IO scheduler and the CPU scheduler, to help common desktop usecases.

Incidentally there is a fairly recent feature submission by Mike Galbraith that extends the (CPU) scheduler with a new feature which adds the ability to group tasks more intelligently: see Mike's auto-group scheduler patch

This feature uses cgroups for block IO requests as well.

You might want to give it a try, it might improve your large-copy workload latencies significantly. Please mail bug (or success) reports to Mike, Peter or me.

You need to apply the above patch on top of Linus's very latest tree, or on top of the scheduler development tree (which includes Linus's latest), which can be found in the -tip tree

(Continuing this discussion over email is probably more efficient.)

Thanks,

Ingo

I have been using KVM on my home workstation for a few months now and I can highly recommend it. I typically use it for testing different linux distros, files systems, server configurations, etc.

If your system supports VT-x or the AMD equivalent the performance is very impressive, almost no noticeable difference. The virt-manager produced by Red Hat makes creating and configuring virtual machines a snap with its friendly user interface.

It supports many useful things like, headless VNC mode (defaut), start on boot, cloning, virtual networks, and so on. However if you are using it for graphics you may want to use the virtualbox style display for faster mouse response, just select it from the list.

It's opensource so it costs you nothing to try it and the current Ubuntu kernels have support for it built in. For me it was a simple apt-get to get started.

Jim said the same stuff during his keynote at the recent Red Hat Summit 2010. If you want to see it, watch the video here: http://www.redhat.com/videos/summit2010/Jim_Whitehurst.html

There is a whole ecosystem of books, online material and courses created by Microsoft to facilitate people learning their product. No such infrastructure exists for open source products. It may not even be possible to create such an infrastructure.

I'd be amazed to find out it's impossible for Open Source folks to create an infrastructure with books, online material, and training.

Is it possible you were saving files with OO.o 2.x on any systems? ODF 2.x did not save some things in proper ODF format. One place I know you will see this particularly clear is saving a presentation on OO.o 2.x and then open it in 3.x; don't confuse odf versions with openoffice versions and oo.o 2.x not saving odf documents in compliant format; even the versions it was saving in were not correct and because of that 3.x would not render them correctly. https://bugzilla.redhat.com/show_bug.cgi?id=527933

Take a look at this to see what Drools can really be used for:

http://www.redhat.com/f/pdf/jbw/amollenkopf_430_applying_drools.pdf

It's quite powerful when used right..

Connect this with Red Hat's recent statement to the U.S. Patent Office telling them to stop granting software patents, although the result in the Bilski case gives them no reason to do so.

Red Hat lost. They caved and paid for their own license, and everybody else has to negotiate separately.

It was obvious that if Acacia went after them again, they would not do so in a way that would allow the same outcome as their first case.

The sad thing about this is the way Red Hat has screwed the Open Source developer community. Not with this case, but with their conduct over the past decade. They refused to stick their neck out by lobbying aggressively for an end to software patenting, both in the industry and with government. Then, there was no sentiment in favor of ending software patenting in the industry when the Bilski case came about, and the court followed the BSA's amicus curae statement extensively while paying little attention to the Free Software / Open Source side.

What Red Hat did was court the biggest patent holders extensively for their business. And they got it in part by not rocking the boat on software patenting. So, they made that money on the backs of the community.

And now it's open season on open source. Thanks, guys.

(mostly Ubuntu and Debian),

Maybe that's why? You didn't run into show-stopping bugs related to package signing like this one, and therefore encounter the recommended workarounds.

Micah Cowan 2009-04-21 16:20:01 EDT

Any hints for workarounds? Right now we (VMware)
are recommending people disable signature checks.

Ahem... keep in mind, the jailbreakme.com PDF exploit stems from FreeType.

http://www.kb.cert.org/vuls/id/275247

Blaming Apple for an exploit in FOSS code they probably didn't write, is a little unfair, yeah?

Afterall, Red Hat was kind enough to at least credit Apple with the fix in their software update:
https://rhn.redhat.com/errata/RHSA-2010-0607.html

I've been waiting on iotop for a while too... see this comment I made: https://bugzilla.redhat.com/show_bug.cgi?id=239654#c2 back in September of last year.

Argh.

CentOS 5 fixes are available - see http://bugs.centos.org/view.php?id=4518 Redhat 5 also has new kernel - see https://rhn.redhat.com/errata/RHSA-2010-0704.html GO GO GO !!!

RHEL was never affected. Red Hat BugID 630551 states:
"This issue did not affect the version of Linux kernel as shipped with Red Hat
Enterprise Linux 3, 4, and 5 as it did not include upstream commit 7034632d
that introduced the problem. It did not affect Red Hat Enterprise MRG as the /dev/sequencer device file is restricted to root access only."

Further, Red Hat states for CVE-2010-3080 that the commit upstream that brought the bug back was never allowed into Red Hat kernels:
"This issue did not affect the version of Linux kernel as shipped with Red Hat Enterprise Linux 3, 4, and 5 as it did not include upstream commit 7034632d that introduced the problem."

I guess you get what you pay for.

I'll be curious to see in the next few days if downstream from Red Hat followed Red Hat's same kernel compile options. Some prominent downstream versions would be CentOS and Oracle's OEL.

RHEL was never affected. Red Hat BugID 630551 states:
"This issue did not affect the version of Linux kernel as shipped with Red Hat
Enterprise Linux 3, 4, and 5 as it did not include upstream commit 7034632d
that introduced the problem. It did not affect Red Hat Enterprise MRG as the /dev/sequencer device file is restricted to root access only."

Further, Red Hat states for CVE-2010-3080 that the commit upstream that brought the bug back was never allowed into Red Hat kernels:
"This issue did not affect the version of Linux kernel as shipped with Red Hat Enterprise Linux 3, 4, and 5 as it did not include upstream commit 7034632d that introduced the problem."

I guess you get what you pay for.

I'll be curious to see in the next few days if downstream from Red Hat followed Red Hat's same kernel compile options. Some prominent downstream versions would be CentOS and Oracle's OEL.

Yeah, how people could think otherwise is beyond me.

So, at long last, the licence is changed, glibc is Free software

This text links to a git commit. Click any of the diffs to read the old and new licenses, as long as you aren't red-green color-blind.

You could have clicked the link in the article to the actual diffs:

http://sources.redhat.com/git/?p=glibc.git;a=commit;h=a7ab6ec83e144dafdc7c46b8943288f450f8e320

Too big even for RHEL? Help me put this into perspective, what kinds of sizes are we talking here?

Theoretically I understood RHEL Advanced Server was capable of an unlimited number of CPU's and memory ( http://www.redhat.com/rhel/compare/ ).

Perhaps you're reaching some contention at high loads or with large numbers of CPU's / storage / etc?

Thanks for any info you can provide.

https://launchpad.net/bugs/+bugs?field.searchtext=remote+code+execution&search=Search+Bug+Reports&field.scope=all&field.scope.target=
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2009-1252
http://news.softpedia.com/news/Critical-Vulnerability-Silently-Patched-in-Linux-Kernel-152678.shtml
http://projects.info-pull.com/moab/MOAB-20-01-2007.html
http://projects.info-pull.com/moab/MOAB-14-01-2007.html
http://projects.info-pull.com/moab/MOAB-01-01-2007.html
http://projects.info-pull.com/moab/MOAB-01-01-2007.html

Race?

The most popular distros already patched it days ago and others are currently in testing.

Redhat patched it 2 days ago.
Ubuntu patched it 2 days ago.
Fedora is currently testing the patches. Not sure if it's already live.
Debian Lenny has patched it.

Fedora doesn't even have Tetris

Yes, it does.

I was under the impression that Fedora was excluding Tetris clones under pressure from The Tetris Company. Havoc Pennington was of the opinion that "All Tetris clones are illegal, unfortunately."

Strictly speaking, you cannot get "piles of free stuff with any (Linux) distro." There are a number of distros that require payment for repository access; here is a well known one:

http://www.redhat.com/

You mean like Red Hat Enterprise Linux or CentOS, which is built from the exact same source?

Running Oracle on Linux isn't different from running Oracle on Solaris.

You are completely incorrect in regards to what Centos is doing and how they do it. Red Hat makes their source code to Enterprise linux versions availabel to anyone. The only things not open source are their trademarks and images. Download yourself if you like. http://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/os/ As for the GPL well version 3 has a section that clarifies this 10. Automatic Licensing of Downstream Recipients. Even under GPL 2 the hassle involved in trying to avoid making your source generally available is more hassle then it's worth as there is simply no way to prevent your source code from becoming generally available.

Firefox 3.6.4 just showed up as an update to RHEL 5 / Centos 5.

https://rhn.redhat.com/errata/RHSA-2010-0501.html

There is both a x86_64 version and a i386 version available on the update mirrors.

Up to now, the latest Firefox on Centos 5 has been 3.0.something, so this is a big update.

Yeah... Red Hat cannot exist. Unpossible!!111

I'll be the first one in line to dance on their grave.

I think Linus already shotgunned the grave dancing back when he was struggling with youtube on his wife's Fedora install.

Linus Torvalds 2008-03-31 15:37:13 EDT

Description of problem:

youtube no workee - fedora 9 not usable for wife

Version-Release number of selected component (if applicable):

swfdec.x86_64 0.6.2-1.fc9
swfdec-gtk.x86_64 0.6.2-1.fc9
swfdec-mozilla.x86_64 0.6.0-1.fc9

How reproducible:

I didn't try a lot of videos, but I couldn't find a single one that actually
worked. And what's the internet without the rick-roll?

Some just show a light gray background, some give the play buttons etc, but show
only a black screen even when the red ball at the bottom moves along..

Steps to Reproduce:
1. Install current Fedora 9
2. Rick-roll!
3. No profit!

Actual results:

Some videos just show a light gray background, some give the play buttons etc,
but in the latter case show only a black screen even when the red ball at the
bottom seems to moves along..

Expected results:

Rick Astley in all his glory! People have reported that youtube videos are
supposed to work with swfdec, so I presume they have worked at some point and
have been broken recently.

Just to test that this isn't just a anti-rick-roll security feature, I also
tested some other videos, but let's face it - we do need Rick for the "Full
Internet Experience".

Additional info:

This is "high" priority because the wife will kill me if she doesn't have her
videos. And the adobe player won't install on current rawhide due to some
library issues.

"Obi-wan Kenobi, you're our only hope"

Let's see, RHEL 4 came out in 2005-02-15 according to Wikipedia. Its still fully supported (as release 4.8) including new hardware and software enabling.

According to slide 5 on Redhat's roadmap, RHEL 3 (which came out late 2003) is still supported for security fixes.

Importantly, most Linux distros and the kernel itself have made a lot more progress in those intervening years than Windows has. I'd argue its much more impressive to support a 7 year old Linux distro than to support a 7 year old Windows release. Especially so when distros include user software, not just an OS.

So can linux in fact; EFI was always used for itanic systems. It's still retarded. x86 openfirmware would have been sweet so of course no one (not even apple, disappointingly given their use of ppc openfirmware) used it.

https://www.redhat.com/docs/manuals/enterprise/RHEL-3-Manual/x8664-multi-install-guide/s1-ia64-intro-efi-shell.html

Having a patent doesnt do anything by itself, it gives the holder of the patent specific options.

Specific options that I don't want anyone to have over me; options they won't have if I don't encode anything with H.264.

Let me ask you, how many people has the MPEG-LA sued over h264 ... there are OSS implementations ... how many of them have been sued?

I don't trust the MPEG-LA. Past performance is no guarantee. Frankly, if their US licensees have any inkling that x264 is cutting into their profits, as publicly traded corporations they are legally obligated to push the MPEG-LA to enforce those patents anywhere they are valid. Apple and Microsoft both qualify. They have a legal obligation to their stockholders to push H.264 over Theora since they get money whenever a H.264 encoder or decoder is sold.

I suppose the fact that Novell, Redhat and Canonical all are patent holders just slipped your fucking mind too right?

Redhat grants use of their patents.
http://www.redhat.com/licenses/ccmpl.html

2. GRANT OF RIGHTS

a. Subject to the terms of this Agreement, each Contributor hereby grants Recipient a non exclusive, worldwide, royalty free copyright license to reproduce, prepare derivative works of,publicly display, publicly perform and distribute and sublicense the Contribution of such Contributor, if any, and such derivative works, in source code and object code form.

b. Subject to the terms of this Agreement, each Contributor hereby grants Recipient a non exclusive, worldwide, royalty free patent license under Licensed Patents to make, use, sell, offer to sell, import and otherwise transfer the Contribution of such Contributor, if any, in source code and object code form. This patent license shall apply to the combination of the Contribution and the Program if, at the time the Contribution is added by the Contributor, such addition of the Contribution causes such combination to be covered by the Licensed Patents. The patent license shall not apply to any other combinations which include the Contribution. No hardware per se is licensed hereunder.

Novell licenses their contributions under the GPL version 2 (they are still carrying notices to this effect, not difficult to locate.) It does not permit redistribution if patent claims prevent it. Novell cannot simultaneously distribute Linux and make patent claims against it.

The Canonical contributor agreement requires that you promise that no patent claims will come from your contributions to canonical, and they make the same promise back to you. Further, Canonical submitted a letter to the European Patent Office arguing against the granting of software patents for EPO EBA referral G3-08.

Or, in short, you are using three companies which have promised not to sue over software patents in comparison to a group which exists specifically to handle licensing and lawsuits of a group of patents encumbering a supposed standard. This is so wrongheaded I just can't even begin to figure out where you're coming from.