Slashdot Mirror

Most distros work on newer, UEFI-capable systems when in legacy/BIOS mode, though that's not always the case when trying to use native capabilities. UEFI has created some problems recently on x86 hardware, but they appear to be getting addressed. They were first really addressed with kernel 3.0 and have gotten better in 3.1. Matt Garrett was the developer to start figuring out what was going on, leading to a patch with an amusing description and a few bits of sarcasm in in-line comments. It's improved since then.

There are also some gaps in coverage stemming from grub not yet reaching a release state. Fedora was going to go grub2 across the board with F16, but some issues have stalled that for UEFI systems, which will have to wait until F17. Fortunately, grub-efi still works well enough to get it loaded, though I've not been able to get it to recognize the Windows partition on my work notebook and have to rely on the firmware's boot menu to handle that part. It means I have to pay attention when booting for the couple of seconds to hit F12, but it works.

I believe Ubuntu 11.10 also works well enough, as my last experiments were using a beta and I imagine that it's improved since then. I also tinkered with Arch, but couldn't get it to work properly. No idea how far they've gone in the last couple of months.

Educate yourself, stupid. Or at least try to unplug your head from your asshole.

It's a problem with the BIOS manufacturers, and the BIOS incorrectly reporting its ASPM capability. When an OEM installs Windows on a laptop, it can correctly tune these settings. But for a fresh install of Linux that YOU performed, a database of every motherboard + BIOS combination needs to be maintained in the open to set the force PCIE ASPM flag. If set wrongly, when the BIOS doesn't support it, it could lead to locking which is far more serious.

There are other solutions to effectively manage power in Linux, like Jupiter.

For more (and better) information, see the following links: About the Kernel 3.0 "Power Regression" Myth and PCIe, power management, and problematic BIOSes

If its a BIOS problem, why does it not affect Windows OS running on the same PC (with the same BIOS)?

It's a problem with the BIOS manufacturers, and the BIOS incorrectly reporting its ASPM capability. When an OEM installs Windows on a laptop, it can correctly tune these settings. But for a fresh install of Linux that YOU performed, a database of every motherboard + BIOS combination needs to be maintained in the open to set the force PCIE ASPM flag. If set wrongly, when the BIOS doesn't support it, it could lead to locking which is far more serious.

There are other solutions to effectively manage power in Linux, like Jupiter.

For more (and better) information, see the following links: About the Kernel 3.0 "Power Regression" Myth and PCIe, power management, and problematic BIOSes

Moreover, the problem does not lie completely with *nix developers themselves. Case in point, it takes them months to fix their broken calls to memcpy which were:

traced to Adobe Flash by maintainers of glibc at Red Hat, Linus Torvalds and others.

Full story here.

Relevant part of the conversation:

> Subject: Re: FP-5739 "Strange sound on mp3 flash website with Fedora 14 x86_64"
>
> Hi Shu,
>
> That's is great to hear. Would you guess it's a matter of days, weeks or
> months before this can get fixed?
> If it will take a long time for you to fix this, Fedora may need to look
> at some way to work around this bug.
>
> Best regards,
> Magnus
>

> Hi Magnus,
>
> Maybe months. Thanks.
>
> Best regards.

what are you talking about? that patent has been effectively nullified. http://lwn.net/Articles/338981/

I'm not quite sure what you mean when you say "None of what Intel did to Linux with Moblin has any repercussions for anyone not using an x86-compatible Intel processor." For now I will interpret that as "they did nothing of interest for machines with CPUs from AMD/ARM etc.

Arjan van de van's work on asynchronous initialization of kernel subsystems means you will spend less time waiting for the kernel to finishon all sorts of CPUs - not just x86s. Powertop works on CPUs other than Intel's and has been used to help monitor power consumption of various program running on Linux.

Surely the fact that much of this work has gone upstream/mainline is a positive thing rather than a negative one? It's hard to tell which way you view this from your comment...

Linux is not unusual in seeing developers call gettimeofday/gethrtime with wild abandon, thus slowing the programs they're trying to measure the time of (;-)) For this reason, Solaris time calls are register/location reads, and ethe code sequences are so short that they fit into the the syscall dispatch table. Therefor the caller never really enters the OS at all to get the time.

The interesting new work on locks is "transactional memory", and there's a series of articles about it and Linux memory in general at LWN. See Memory part 8: Future technologies by Ulrich Drepper. The hardware they describe as the testbeds are SPARCs.

--dave

If you look at the kind of work Microsoft has put into the Linux kernel recently relating to Hyper-V...

https://lwn.net/Articles/451243/

One might gather that it's not worth the trouble for NT to ape Unix anymore. Chances are pretty good Linux is the new SUA and virtualization will be the new supported solution to this problem. I mean, why should Microsoft bother maintaining its own Unix tools when they're actively maintained elsewhere? Given the work they've done on both virtualization and linux integration I would say that there's no great conspiracy here.

Secure boot is bad. What is mysterious about that? If you want to understand more, related to booting Linux, read these. UEFI secure booting x86 EFI boot stub

From one of TFAs

While it would be possible for various [Linux] distributions to get their keys added, that wouldn't help anyone who wanted to run a tweaked version of the "approved" bootloader or kernel. Distributors would not be able to release their private keys to allow folks to sign their own binaries either. Each key is just as valid as any other, so malware authors would just pick up those keys to sign their wares. Exposed keys would also find their way onto the forbidden list rather quickly one suspects.

This reminds me of the way keys are used to protect DVDs and we all remember what happened.

EFI is just as big a mess as the legacy BIOS:

http://lwn.net/Articles/451690/
http://lwn.net/Articles/453003/

And would you like Microsoft with their Windows 8 (App) Store and Intel to control your PC like it is an Apple iDevice ?:
http://lwn.net/Articles/459569/

EFI is just as big a mess as the legacy BIOS:

http://lwn.net/Articles/451690/
http://lwn.net/Articles/453003/

And would you like Microsoft with their Windows 8 (App) Store and Intel to control your PC like it is an Apple iDevice ?:
http://lwn.net/Articles/459569/

EFI is just as big a mess as the legacy BIOS:

http://lwn.net/Articles/451690/
http://lwn.net/Articles/453003/

And would you like Microsoft with their Windows 8 (App) Store and Intel to control your PC like it is an Apple iDevice ?:
http://lwn.net/Articles/459569/

Unfortunately, we weren't given the whole story here. Over on lwn, Perens was similarly taken to task over the terms, and here's his response:

When you are working with a company as large as that (LN is a big division of huge Elsevier) with as many separate stake-holders in legal, management, etc., it's always a negotiation. That's what I could get.

There are plenty of posts pointing out how one-sided and/or vague this "covenant" is, and how hard it will be to actually enforce. He also admits in one reply that their lawyer, not him, wrote the license, which explains a lot.

I can understand his position - after all, it creates a job for him, so he has to advocate for it. But the terms suck.

Interesting thread - do there also seems to be some support for his position.

As with any contract negotiation (and I've done a few although IANAL) you carve out a set of terms that is agreeable to all sides - no one generally gets everything they want. In this case, L-N has made an offer to the OOS community - which each individual developer can accept or reject.

No one really loses under that model - if they don't like the terms simply don't submit any code modifications. I'd say they'v even gained - they can modify the code for their own use without having to give up the copyright - something not available before.

As I said, an unlimited, non-exclusive irrevocable license to any code they submit allows them the freedom to do what they want to with their own code as well.

So let's get this straight - you don't even know what your own license means?

Oh, that's right - their lawyer wrote it, not you.

When you are working with a company as large as that (LN is a big division of huge Elsevier) with as many separate stake-holders in legal, management, etc., it's always a negotiation. That's what I could get.

...

The lawyer involved wrote the license to be as brief as possible and understandable by non-attorneys. Perhaps this is what bothers you about clause 2?

BTW: The license doesn't change any of your rights - the separate copyright assignment to your masters does.

And as you pointed out elsewhere here, they want to be able to list the copyrights as an asset, so this goes far beyond them just wanting to "protect their commercial code" and why they won't just accept the individual authors giving them a non-exclusive right to use the code in commercial products.

This whole thing is ridiculous. If you're going to push a license on people, don't you think you should understand it first?

When you are working with a company as large as that (LN is a big division of huge Elsevier) with as many separate stake-holders in legal, management, etc., it's always a negotiation. That's what I could get.

There are plenty of posts pointing out how one-sided and/or vague this "covenant" is, and how hard it will be to actually enforce. He also admits in one reply that their lawyer, not him, wrote the license, which explains a lot.

I can understand his position - after all, it creates a job for him, so he has to advocate for it. But the terms suck.

Also, there's this

When you are working with a company as large as that (LN is a big division of huge Elsevier) with as many separate stake-holders in legal, management, etc., it's always a negotiation. That's what I could get.

In other words, he got p0wned, as many of the commenters over on LWN pointed out. When you can't negotiate a good deal, get up and leave. Don't settle for a bad deal and then try to sell it to everyone - we're not stupid.

He also admitted here that he forgot to ask their lawyer about license-back provisions to people who assign their copyrights. Sloppy, sloppy work, and since this was "all he could get", don't hold your breath.

If this is your idea of the work of a "licensing professional", here's a news flash - the real world works differently. This is already a fiasco and a joke, except nobody's laughing. Such a lop-sided "covenant" is a betrayal of the ideals of open source. But don't let me keep you from drinking the kook-aid.

We raised serious concerns - he dissimulated. We proposed alternatives - he made excuses for why they wouldn't work that were facile at best, and often better characterized as disingenuous.

Before today, I had no reason not to take everything Mr. Perens says at face value. That is gone - probably forever - at this point.

Since you've bailed on answering the hard questions here let's see how you're misleading people on LWN.

A poster asked you about the implications of assigning copyrights for their code.

More specifically

Posted Sep 12, 2011 15:51 UTC (Mon) by iabervon (subscriber, #722) [Link]
It seems to me that this is missing an important motivation for developers: many developers want to implement a particular feature so they themselves can use that feature. Consider, for example, a developer who has added a redundancy feature to a database so that the web site they run has better availability; their primary goal is to run the site with a database with this feature. To the extent that these developers expect to get a benefit from contributing the code to the upstream project, it is to reduce the maintenance burden (ultimately by developers considering that to be normal functionality and simply not introducing conflicts). In this situation, the covenant would ensure the worst of all possibilities in the situation where the company took the project proprietary: not only would the developer not have access to the source of future versions, but these future versions would not work for the developer, since the feature would have to be removed. Furthermore, there is a danger in the company then owning the copyright on the implementation of this feature, if the developer decides to add the feature to a different project (particularly if the other projects that it would make sense to add the feature to require copyright assignment, so simply having a license to the original implementation is not sufficient). (emphasis added)

And your reply:

Posted Sep 12, 2011 16:11 UTC (Mon) by BrucePerens (subscriber, #2510) [Link]
Actually, this isn't a problem because of a key feature of copyright law: A developer is always free to grant their own work to others under his/her own terms. The covenant doesn't make you promise not to do so.

Of course the covenant doesn't "make you promise not to" - because it doesn't need to. Copyright law "makes you promise not to do so" because doing so would be against the law once you've assigned copyright to someone else (doh!).

Remember, here you've been arguing that they will only accept contributions if the copyright is assigned to them. And worse, you've admitted that you forgot to ask about the author getting a grant-back for other uses. You negotiated with their lawyer, and their lawyer got the better of you. Not much of a surprise there, I guess, after seeing the rest of your responses here and at LWN.

And you're surprised that you're getting raked over the coals for it on both sites? Really? So much so that you have to run away?

Sloppy, half-baked, uninspiring. You come up with all sorts of "excuses" for why LexisNexis and their owner, Reed-Elsevier, the paywall people (you know, the poor poor $9 billion market cap business needs your code to list as a business asset or they'll have big problems!!!OMG!!!), should be trusted, and *need* copyright assignment, such as "they want to be able to list the copyrights as assets" .... gee, maybe we should be as generous to Rupert Murdoch, ya think?

Since you've bailed on answering the hard questions here let's see how you're misleading people on LWN.

A poster asked you about the implications of assigning copyrights for their code.

More specifically

Posted Sep 12, 2011 15:51 UTC (Mon) by iabervon (subscriber, #722) [Link]
It seems to me that this is missing an important motivation for developers: many developers want to implement a particular feature so they themselves can use that feature. Consider, for example, a developer who has added a redundancy feature to a database so that the web site they run has better availability; their primary goal is to run the site with a database with this feature. To the extent that these developers expect to get a benefit from contributing the code to the upstream project, it is to reduce the maintenance burden (ultimately by developers considering that to be normal functionality and simply not introducing conflicts). In this situation, the covenant would ensure the worst of all possibilities in the situation where the company took the project proprietary: not only would the developer not have access to the source of future versions, but these future versions would not work for the developer, since the feature would have to be removed. Furthermore, there is a danger in the company then owning the copyright on the implementation of this feature, if the developer decides to add the feature to a different project (particularly if the other projects that it would make sense to add the feature to require copyright assignment, so simply having a license to the original implementation is not sufficient). (emphasis added)

And your reply:

Posted Sep 12, 2011 16:11 UTC (Mon) by BrucePerens (subscriber, #2510) [Link]
Actually, this isn't a problem because of a key feature of copyright law: A developer is always free to grant their own work to others under his/her own terms. The covenant doesn't make you promise not to do so.

Of course the covenant doesn't "make you promise not to" - because it doesn't need to. Copyright law "makes you promise not to do so" because doing so would be against the law once you've assigned copyright to someone else (doh!).

Remember, here you've been arguing that they will only accept contributions if the copyright is assigned to them. And worse, you've admitted that you forgot to ask about the author getting a grant-back for other uses. You negotiated with their lawyer, and their lawyer got the better of you. Not much of a surprise there, I guess, after seeing the rest of your responses here and at LWN.

And you're surprised that you're getting raked over the coals for it on both sites? Really? So much so that you have to run away?

Sloppy, half-baked, uninspiring. You come up with all sorts of "excuses" for why LexisNexis and their owner, Reed-Elsevier, the paywall people (you know, the poor poor $9 billion market cap business needs your code to list as a business asset or they'll have big problems!!!OMG!!!), should be trusted, and *need* copyright assignment, such as "they want to be able to list the copyrights as assets" .... gee, maybe we should be as generous to Rupert Murdoch, ya think?

Since you've bailed on answering the hard questions here let's see how you're misleading people on LWN.

A poster asked you about the implications of assigning copyrights for their code.

More specifically

Posted Sep 12, 2011 15:51 UTC (Mon) by iabervon (subscriber, #722) [Link]
It seems to me that this is missing an important motivation for developers: many developers want to implement a particular feature so they themselves can use that feature. Consider, for example, a developer who has added a redundancy feature to a database so that the web site they run has better availability; their primary goal is to run the site with a database with this feature. To the extent that these developers expect to get a benefit from contributing the code to the upstream project, it is to reduce the maintenance burden (ultimately by developers considering that to be normal functionality and simply not introducing conflicts). In this situation, the covenant would ensure the worst of all possibilities in the situation where the company took the project proprietary: not only would the developer not have access to the source of future versions, but these future versions would not work for the developer, since the feature would have to be removed. Furthermore, there is a danger in the company then owning the copyright on the implementation of this feature, if the developer decides to add the feature to a different project (particularly if the other projects that it would make sense to add the feature to require copyright assignment, so simply having a license to the original implementation is not sufficient). (emphasis added)

And your reply:

Posted Sep 12, 2011 16:11 UTC (Mon) by BrucePerens (subscriber, #2510) [Link]
Actually, this isn't a problem because of a key feature of copyright law: A developer is always free to grant their own work to others under his/her own terms. The covenant doesn't make you promise not to do so.

Of course the covenant doesn't "make you promise not to" - because it doesn't need to. Copyright law "makes you promise not to do so" because doing so would be against the law once you've assigned copyright to someone else (doh!).

Remember, here you've been arguing that they will only accept contributions if the copyright is assigned to them. And worse, you've admitted that you forgot to ask about the author getting a grant-back for other uses. You negotiated with their lawyer, and their lawyer got the better of you. Not much of a surprise there, I guess, after seeing the rest of your responses here and at LWN.

And you're surprised that you're getting raked over the coals for it on both sites? Really? So much so that you have to run away?

Sloppy, half-baked, uninspiring. You come up with all sorts of "excuses" for why LexisNexis and their owner, Reed-Elsevier, the paywall people (you know, the poor poor $9 billion market cap business needs your code to list as a business asset or they'll have big problems!!!OMG!!!), should be trusted, and *need* copyright assignment, such as "they want to be able to list the copyrights as assets" .... gee, maybe we should be as generous to Rupert Murdoch, ya think?

"Actually, this isn't a problem because of a key feature of copyright law: A developer is always free to grant their own work to others under his/her own terms."

Copyright law doesn't work that way. Once you assign it to someone else, you don't have the right to make other grants w/o their permission.

So which is it - you "forgot to ask your masters", or "it's not a problem"?

Quoted further down in the thread, for those too lazy to go to lwn, along with a few choice comments as Perens tries to avoid giving a real response to the many legitimate questions that were raised here and on LWN.

Troll much, Perens? Because you really need more practice if you're not going to be caught out so easily.

Guess who can't stand the heat and wants to leave the kitchen?

It doesn't work that way, Bruce. You're telling one story here, and I just checked on lwn.com, and you're saying something completely different there there.

http://lwn.net/Articles/458515/

More specifically

Posted Sep 12, 2011 15:51 UTC (Mon) by iabervon (subscriber, #722)[Link]
It seems to me that this is missing an important motivation for developers: many developers want to implement a particular feature so they themselves can use that feature. Consider, for example, a developer who has added a redundancy feature to a database so that the web site they run has better availability; their primary goal is to run the site with a database with this feature. To the extent that these developers expect to get a benefit from contributing the code to the upstream project, it is to reduce the maintenance burden (ultimately by developers considering that to be normal functionality and simply not introducing conflicts). In this situation, the covenant would ensure the worst of all possibilities in the situation where the company took the project proprietary: not only would the developer not have access to the source of future versions, but these future versions would not work for the developer, since the feature would have to be removed. Furthermore, there is a danger in the company then owning the copyright on the implementation of this feature, if the developer decides to add the feature to a different project (particularly if the other projects that it would make sense to add the feature to require copyright assignment, so simply having a license to the original implementation is not sufficient).

And your reply:

Posted Sep 12, 2011 16:11 UTC (Mon) by BrucePerens (subscriber, #2510) [Link] [Link]
Actually, this isn't a problem because of a key feature of copyright law: A developer is always free to grant their own work to others under his/her own terms. The covenant doesn't make you promise not to do so.

Here, you've been arguing that they will only accept contributions if the copyright is assigned to them. On LWN, you gloss over the implications of that, expressed by the poster on LWN, by saying that the developer is free to grant their own work to others. They cannot if they have assigned the copyright to someone else, and you d*** well know that.

This is pretty disgusting behavior on your part.

Guess who can't stand the heat and wants to leave the kitchen?

It doesn't work that way, Bruce. You're telling one story here, and I just checked on lwn.com, and you're saying something completely different there there.

http://lwn.net/Articles/458515/

More specifically

Posted Sep 12, 2011 15:51 UTC (Mon) by iabervon (subscriber, #722)[Link]
It seems to me that this is missing an important motivation for developers: many developers want to implement a particular feature so they themselves can use that feature. Consider, for example, a developer who has added a redundancy feature to a database so that the web site they run has better availability; their primary goal is to run the site with a database with this feature. To the extent that these developers expect to get a benefit from contributing the code to the upstream project, it is to reduce the maintenance burden (ultimately by developers considering that to be normal functionality and simply not introducing conflicts). In this situation, the covenant would ensure the worst of all possibilities in the situation where the company took the project proprietary: not only would the developer not have access to the source of future versions, but these future versions would not work for the developer, since the feature would have to be removed. Furthermore, there is a danger in the company then owning the copyright on the implementation of this feature, if the developer decides to add the feature to a different project (particularly if the other projects that it would make sense to add the feature to require copyright assignment, so simply having a license to the original implementation is not sufficient).

And your reply:

Posted Sep 12, 2011 16:11 UTC (Mon) by BrucePerens (subscriber, #2510) [Link] [Link]
Actually, this isn't a problem because of a key feature of copyright law: A developer is always free to grant their own work to others under his/her own terms. The covenant doesn't make you promise not to do so.

Here, you've been arguing that they will only accept contributions if the copyright is assigned to them. On LWN, you gloss over the implications of that, expressed by the poster on LWN, by saying that the developer is free to grant their own work to others. They cannot if they have assigned the copyright to someone else, and you d*** well know that.

This is pretty disgusting behavior on your part.

Has Linus changed his mind in the last week?

http://article.gmane.org/gmane.comp.file-systems.ext4/27628

No. The github address and bad grammar made Linus suspicious about the sender's identity. It had nothing to do with github itself.
See the comments here.

I hate to point this out to you, but 80% of the kernel is written by programmers acting in a professional capacity (source: http://lwn.net/Articles/450891/) The admins of kernel.org deserve exactly as much bashing as the admins of microsoft.com would do if it had happened to them.

If we look at cia.vc and follows the news on who leaved mandriva ( Paulo Zanoni, Xorg maintainer, some months ago, glibc maintainer, some kde team guy ( see http://lwn.net/Articles/441940/ for the details, quite insightful despites being from one of the Mageia founders ), that doesn't look very good. The last one to leave is Eugeni Donodov, the head of the team after mandriva fired Anne Nicolas, and he left 1 month before the release, which doesn't sound very good. So if there is 45 persons in Brasil, why does all commits look like done by volunteers of RosaLabs ( http://lists.mandriva.com/cooker/2011-02/msg00000.php ) ?

Maybe you mean "there is 45 persons in Brasil, and they are all working on something else than the distribution" ?

Personnaly, I migrated my servers to Opensuse. The community is as goos as the one of Mandriva, and there is lots of nice nugget, such as zypper, yast, that doesn't make me regret the change. And there is the Evergreen project that is starting to take shape, so no need to wait for Mandriva to have some LTS based on non existant planning.

Well, Ericsson seems to be either helfull or bowed to some pressure but they offer to unlock the bootloader for some (newest I presume) phones: Unlocking the bootlader. Thus, unlocked bootloader does not seems to prevent the adoption of Linux/Android. Locking migt be simply seens as a needed step from childhoot to maturity. :)

And quoting LWN's Android, forking, and control:

The Android developers, beyond forking the kernel, also took the position that the GPL is bad for business. The project's original goal was to avoid GPL-licensed code altogether; the plan was to write a new kernel as well. In the end, a certain amount of reason prevailed, and the (GPL-licensed) Linux kernel was adopted; there are a few other GPL-licensed components as well. So, James said, we can thank Andy Rubin - from whom the dislike of the GPL originates - for conclusively demonstrating that a handset containing GPL-licensed code can be successful in the market. It turns out that downstream vendors really don't care about the licensing of the code in their devices; they only care that it's clear and compliant.

it seems that also the GPL is not that great block to the Linux/Android adoption either. Again, companies simply needs some time to understand it properly, get comfortable and than move along to doing the actual business instead of fighting petty wars.

IMHO

We've already seen claims from Edward Naughton and Florian Mueller that most Android distributors are in violation of the GPL - claims that the open source community has, for the most part, rejected.

I don't know how someone can speak for that demographic. I followed the link to find out who this spokesperson is and was brought to this in the linked article on that Slashdot article:

Textbook FUD.

And this is why people avoid GPL code. Whether Mueller is right or wrong (and he's pretty much always wrong) there is so much FUD spread over potential GPL violations all over the place that most corporations just don't want to even get within miles of the GPL for fear that some loser like Florian will try to peg crap on them.

A Slashdot Anonymous Coward

So the open source community is represented by an anonymous coward here on Slashdot?

Have I ever bought a $10 piece of trash from China and found out that I could really use the source in order to make it work with my computer? Yes. Could I foresee some BS tablet maker producing a piece of trash tablet, hacking Android and releasing it sans source code only to have consumers wonder how in the hell Android is running on that device? Definitely. I wouldn't put that past anybody given there's supposedly one GPL violation a day and the fact of the matter is that licenses don't seem to mean jack shit in China (and that's their right as a sovereign nation).

So the allegations here are that Edward Naughton and Florian Mueller (neither of whom I am defending, by the way) have spread FUD to strong arm people into migrating to GPLv3 so that device makers won't fear the repercussion of violating GPLv2 and then having to do impossible legwork to get back in good standing and regain a license?

Regardless of how effective that is (I'm not a handset manufacturer nor do I know any straying from Android because of this) that is some pretty crazy thin ridiculous sorry FUD if I may say so myself. I worked for a Fortune 500 company for seven years and all I ever saw was a slow gradual movement toward GPL code until I think the only licenses we had were unfortunate contractual agreements from the past. Oh, and Windows. No one really cowered in fear and ran screaming when presented with the above "FUD" as the Anonymous Coward quote seems to imply.

I don't get it, we pick apart any huge company's license here on Slashdot in the name of protecting the consumer but when someone does it to the GPL and finds some hilariously minute case -- then it's FUD?

The FSF's press release on the subject emphasizes 'worries' without bringing up a specific concrete case of infringement — a classic FUD technique.

I think it's worth pointing out that in order for this to be "proven" in a court of law, I think that would mean a GPLv2 license holder would have to sue a company that used Android,

It doesn't matter that you didn't modify the source you still have to distribute source yourself if you distribute the binaries. This has come up before in the context of Linux distribution - it is not sufficient to point to someone else's source when distributing GPL licensed binaries.

Fine. They can offer you a link to the google source and we are done or they can wait for you to send a $10 or so check, wait for it to clear, and then burn and mail a CD-R to you. The later fully complies with the GPL. Your choice. Keep in mind that if you want to get letter of the law so can they.

It doesn't matter that you didn't modify the source you still have to distribute source yourself if you distribute the binaries. This has come up before in the context of Linux distribution - it is not sufficient to point to someone else's source when distributing GPL licensed binaries.

For what it's worth, most Android companies seem to be taking releasing the kernel source seriously but only after delaying for as long as possible (coupled with the kernel binary driver gray area).

I also forgot to mention that conventional rasterization and ray-casting is also just as parallel in nature as ray-tracing. In fact, more so because it has much better memory access patterns as I mentioned in a previous post. Memory-access is the biggest limiting factor in building scalable, parallel systems. If you don't have good memory-access patterns, you might as well being doing sequential work, because it's getting serialized by the hardware memory controller anyway.

And this situation isn't improving, it's actually getting worse on each subsequent hardware generation... memory access is increasingly becoming a bigger and bigger bottleneck. I suggest you educate yourself on how memory works on modern cache-coherent hardware.

https://lwn.net/Articles/250967/

I'm don't know much about Florian Muller, but I do know that he's the founder of the NoSoftwarePatents. That, to me, a sw developer, is quite enough to convince that he is not really troll

Nevertheless, he is one in this case. He is a plain PR consultant with a simple policy: he works for whoever pays his cheque. Back in the days that was a consortium led by MySQL. He refuses to disclose who his current employer is.

If you want some information about his trolling since the software patents stint that made him famous, there are several examples, even to the point that Linus felt compelled to tell him to stop whining (see last paragraph of the article).

Hmm, interesting; thanks for the link. I hadn't realized that the X.org people are moving in the same direction. Doing a bit of googling, this LWN article summarizes a Packard talk from last year that seems to be hitting some similar points.

I had a small role in getting the PostgreSQL project to convert from CVS to git. There's a good summary of what happened at Lessons from PostgreSQL's Git transition. With a pretty conservative development community, the bar for converting from CVS to git was set pretty high: the entire CVS repository had to come through, such that every single release ever tagged could be checked out and get exactly the same files as checking it out of CVS (a little binary diff tool was used to confirm). With around 15 years of history in there, that took some upstream fixes to the cvs2git tool to finally accomplish; it took just over a year to work out all the details to everyone's satisfaction. My checked out copy of the current repo is 272MB right now, so neither small nor giant.

I would say that everyone who works regularly on the code is at least a little bit more productive than they used to be, with the older CVS experts having seen the least such improvement. But some people are a whole lot more productive. I'd put myself in that category--my patch contribution rate is way up now that it's so much easier to pop out a branch to hack on some small thing and then submit the result for review.

And the conversion seems to have improved the uptake of new developers getting involved in working on the code. Having to deal with CVS was a major drag for younger developers in particular, and Subversion is equally foreign to most of them now. As suggested in the article, anyone under 25 will only touch a corporate style CVS or Subversion repo if dragged kicking and screaming into it. As more of that generation rises through IT, old style repos will continue to get shredded at a good rate every year. It could have been any of the DVCS systems that ended up in this position, but git was the one that got the right balance of feature, innovation rate, and publicity. Now that it's got such a wide user base, too, I don't see any of the other VCS software options competing with it successfully in the near future.

And in yet more exciting Linux 3.0 news, the RT tree has been rewritten, allowing them to finally move forward of the 2.6.33 kernel. The re-write better leverages SMP (per traditional kernel implementation), is dramatically smaller, easier to read and maintain, and leverages more stock kernel facilities rather than poorly implementing its own.

Is your argument really "well, *I* haven't heard of it, so it can't be that good"?

clang, the LLVM-based compiler for C/C++/Obj-C that Apple and others built (and, yes, actually keep open source and updated, no hidden bogeyman saving-the-good-bits forks) builds all of Mac OS X, all of FreeBSD kernel and world, several other OS kernels and probably most C and C++ code in the world. The Linux kernel and all drivers in the tree are almost working (see http://lwn.net/Articles/441018/ ) but needs some deep and/or rare GCC functionality to compile correctly.

clang is better structured than GCC, compiles the same code faster and optimizes it heavier, assuming it's in the 99% of the code that it will support. It's also built around a library approach that lets you use its innards and ASTs for related projects (like translators and deep code analysis) along with a more stable long-term API for syntax highlighting and symbol/type lookup.

I am not up to date with GCC, but when clang was started a few years back, it was started because the compiler team at Apple wanted all these things -- none of which involve making Apple masters of the universe or forcing everyone to port to Objective-C -- but couldn't do them with the GCC codebase. From what I've heard, GCC has now started to move in this direction. I still want GCC around and I hope it keeps improving, but I'm happy I didn't wait.

There is a similair article on Chrome as well, I think it is this one: http://lwn.net/Articles/404050/

LWN has a good article talking about the policies some Linux distros are taking on Firefox updates.

I'm going to parrot what ds2horner said on LWN - there needs to be evidence that the prefetching is still a benefit to somebody. If not enough people come forward with this then it's a maintenance burden for an uncertain benefit (for what it's worth it is apparently a win to keep PREFETCH on K7s).

According to LWN article about removing prefetch, the linux kernel 3.0.0 will have a bunch of prefetch() calls removed from the kernel.

Apparently they were supposed to provide hints to the CPU to prefetch the next item in linked lists, but the hardware does a superior job of it without the hints. Especially in the case of the next item being NULL, which was the majority of the cases.

A very small speedup to be sure, but it's not like there are many low hanging huge wins left.

Debian's emphasis on being emphatically free software has made several parts of it more difficult than their Ubuntu counterparts. The first thing I have to do after bringing up a new Debian install (or during installation itself in really bad cases) is go turn on the "non-free" repositories. Then I can find things like the absolutely necessary firmware blobs for my hardware, without which nothing functions.

In the same situation, Ubuntu includes most of that in the default installation. And in the cases where there is something really objectionable from an open source standpoint--such as the Nvidia driver--there is a handy "Install hardware drivers" wizard that makes the "give me easy and fast and I don't care about free" a few clicks away.

Some of the other things done in the name of freedom are less annoying, but even harder to resolve. The renaming of Iceweasel and Icedove are ridiculous. And some very hardcore and questionable decisions made by Debian about the legality of building software that links to multiple libraries has broken some packages in very tricky to resolve ways. See PostgreSQL, OpenSSL, and the GPL as the one I've been stuck trying to get resolved. I wrote a summary of the root problem that documents some history about how Debian has wandered into the position of making life harder for end users by enforcing license trivia. It's not really their fault--the OpenSSL developers are really to blame--but Ubuntu just doesn't care about how free their software is, and in many cases that makes life easier for the end user.

Debian's emphasis on being emphatically free software has made several parts of it more difficult than their Ubuntu counterparts. The first thing I have to do after bringing up a new Debian install (or during installation itself in really bad cases) is go turn on the "non-free" repositories. Then I can find things like the absolutely necessary firmware blobs for my hardware, without which nothing functions.

In the same situation, Ubuntu includes most of that in the default installation. And in the cases where there is something really objectionable from an open source standpoint--such as the Nvidia driver--there is a handy "Install hardware drivers" wizard that makes the "give me easy and fast and I don't care about free" a few clicks away.

Some of the other things done in the name of freedom are less annoying, but even harder to resolve. The renaming of Iceweasel and Icedove are ridiculous. And some very hardcore and questionable decisions made by Debian about the legality of building software that links to multiple libraries has broken some packages in very tricky to resolve ways. See PostgreSQL, OpenSSL, and the GPL as the one I've been stuck trying to get resolved. I wrote a summary of the root problem that documents some history about how Debian has wandered into the position of making life harder for end users by enforcing license trivia. It's not really their fault--the OpenSSL developers are really to blame--but Ubuntu just doesn't care about how free their software is, and in many cases that makes life easier for the end user.

I suggest reading of

http://lwn.net/Articles/232379/

http://lwn.net/Articles/445417/

http://lwn.net/Articles/443510/

I suggest reading of

http://lwn.net/Articles/232379/

http://lwn.net/Articles/445417/

http://lwn.net/Articles/443510/

I suggest reading of

http://lwn.net/Articles/232379/

http://lwn.net/Articles/445417/

http://lwn.net/Articles/443510/

Linux IMA at LWN: https://lwn.net/Articles/227937/, https://lwn.net/Articles/326747/
IBM (involved in Trusted Computing Group) link: http://domino.research.ibm.com/comm/research_people.nsf/pages/sailer.ima.html

Bullet-point summary of EVM:
EVM Mailing-list announce: https://lwn.net/Articles/393673/

Linux IMA at LWN: https://lwn.net/Articles/227937/, https://lwn.net/Articles/326747/
IBM (involved in Trusted Computing Group) link: http://domino.research.ibm.com/comm/research_people.nsf/pages/sailer.ima.html

Bullet-point summary of EVM:
EVM Mailing-list announce: https://lwn.net/Articles/393673/

Linux IMA at LWN: https://lwn.net/Articles/227937/, https://lwn.net/Articles/326747/
IBM (involved in Trusted Computing Group) link: http://domino.research.ibm.com/comm/research_people.nsf/pages/sailer.ima.html

Bullet-point summary of EVM:
EVM Mailing-list announce: https://lwn.net/Articles/393673/

You will probably get your wish, as there are people working on a secure boot using UEFI (modern replacement for BIOS) and the sort of cryptographic integrity validation you are talking about: https://lwn.net/Articles/447381/ (subscription required, but free from 23 Jun 2011)

This can be used for good (if you own your own keys, you can compile and install your own kernel etc) or bad (if the hardware vendor or OS vendor owns the keys, you have no way to install anything else, i.e. you have a Tivoized system).

Be careful what you wish for... There's a good chance that in a few years' time, new PCs that come with Windows will make it cryptographically impossible to install a new OS. Only if the UEFI allows you to disable this secure boot feature will you be able to do anything beyond Windows.

Linux IMA (Integrity Measurement Architecture) is a separate project, in kernel 2.6.30+, that does similar things within Linux based on TPM: http://linux-ima.sourceforge.net/ - again, the ownership of the keys is critical.