Slashdot Mirror

There's rumours that iptables might be going away eventually for this instead.

Now I'll admit I've never used *BSD, but even I can see iptables is *fucking awful* for anything more than the most basic IP/port matching. Hopefully this'll happen sooner rather than later.

this was on LWN a long time ago: http://lwn.net/Articles/350390/

So, the USA is clear. The other must be Germany? http://lwn.net/Articles/384556/

There's a whole slew of feature that increase the reliability and performance of these filesystems on large disks. Basically, they're more modern than what we have now. Do some reading: http://lwn.net/Articles/342892/

But btrfs may actually have a better foundation than ZFS. When ZFS was first conceived they didn't believe a file system could do btree's and COW. btrfs has proven that it can be done. See the section "btrfs: Pre-history" at: A short history of btrfs

And ZFS incorporates volume management, so no more pvcreate/vgcreate/lvcreate rigamarole; and LVM doesn't even give you mirroring/RAID--you have you have to use a completely different software stack for that.

You can have your b-trees, I'll take my "zpool create <mirror|raidz[1-3]> <devs>", thanks. "zfs send/recv" is also awesome.

Just waiting for built-in crypto and "bp rewrite" now, but otherwise I've been happily using ZFS in production for a few years.

many answers to your questions are here -> http://lwn.net/Articles/342892/ , benchmarking is probably still premature though

I think you don't give quite enough credit to btrfs; it isn't merely a johnny-come-lately, but rather another step forward in filesystem evolution. Try here for a good article on btrfs, by one of the zfs developers, Valerie Aurora. If you like, just skip to the section entitled "btrfs: A brief comparison with ZFS", one flamebait bit of which is this: "In my opinion, the basic architecture of btrfs is more suitable to storage than that of ZFS."

With that said, no one thinks it's ready for critical data storage yet.

But btrfs may actually have a better foundation than ZFS. When ZFS was first conceived they didn't believe a file system could do btree's and COW. btrfs has proven that it can be done. See the section "btrfs: Pre-history" at:

A short history of btrfs

That may not be on purpose.

I, too, was at that conference; my LWN article about it has been up for a week now.

What about RMS? He mails a daemon that fetches the page with wget and mails it back to him. I bet he's safe.

They claimed copyright, and that reverse engineering the codes was a violation of the DMCA. They lost.

Personally, I find memory compression more interesting than just deduplication, which could be considered a subset of compression. The idea has been around for years. There used to be a commercial product for Windows 95 that claimed to compress the contents of RAM, but which had many serious problems, such as that the software didn't work, didn't even attempt compression, and was basically "fraudware". The main problem with the idea was it proved extremely difficult for a compression algorithm to beat the speed of just doing everything without compression. Gave the idea of memory compression a bad reputation.

Now we have LZO, an algorithm that has relatively poor compression, but which is very, very fast-- fast enough to beat the speed of a straight memcopy. 15 years ago, there wasn't any compression algorithm fast enough for this application. Also, I'm thinking memory is slower relative to processors than 15 years ago, as that would provide incentive to increase the size and sophistication of CPU caches, which has happened. (100 MHz, 32bit Pentium with 33 MHz RAM then, vs 3 GHz, 64 bit multi core CPUs with 800 MHz DDR2 RAM today) Now CPU caches are plenty large enough to handle many 4K pages.

Still, deduplication could have many other cool uses. Friend of mine once hacked up some disk deduplication software for the Apple II. All it did was crosslink identical sectors it found on a disk, and then mark the duplicates as free. There was no provision for counting the number of links or anything like that, in case you wanted to change the contents of the disk. Just had to be aware this had been done to the disk. Ultimately proved more trouble than it was worth, but it was a nice thought for teenagers desperate for more disk space.

you might appreciate this:
http://lwn.net/Articles/359070/

SCO Group copyright claims:
9th June 2003 What evidence of origin,ownership,copyright + GPL
And soon SCO Group Vs IBM:
12th June 2003 The Trillian Project : Proof of SCO's actions

"Now there is one element of OpenServer that is not coming over, we don't the IP, we just own all the right to distribution, ongoing development for the open server, and that has to tax and other considerations"

Random Love, CEO Caldera, keynote address,LINUXWORLD 2000 conference, August

Java programmers who are to stupid to experience more advanced technologies doesn't understand it either. Hold on there for a sec. PHP is an advanced technology? Really??? Crap like this http://lwn.net/Articles/379909/ [lwn.net] is what 'advanced' technology is about? PHP is basically JSP with plain Java SE on it, and a rather poor version of that approach that this. It's perfectly suited for Joe's Burgers 4 page website, but when something more 'advanced' is needed, PHP just doesn't cut it.

Right, the "Java is needed for advanced stuff" argument. Fact: If your web application is "too advanced for PHP" you are doing it wrong and should simplify your design.

For instance, the platform offers zero provisions for any form of concurrency. There is not even something like the basic threading support that Java has had since 1.0, let alone that there is any support for simple asynchronous execution (e.g. the @Asynchronous annotation) or highly efficient parallel computing paradigms like a fork/join framework. And what about an O/R mapper that comes with Java by default? How about dependency injection? What about declarative transactions? What about transactions that automatically span multiple method calls and multiple transactional resources?

Who the fuck gives a shit? Any web app will be IO bound anyway. Dependency injection is a kludge you only need because Java is static and not dynamic. Transactions should be handled by the framework. In those JEE apps I've worked on, the transaction decorators always been misused by overzealous developers creating huge transactions slowing the application down to a crawl.

And I can produce results a hundred times as fast by using Java EE/Java/JBoss AS than with Django/Python and surely PHP. I'm not sure what this proves though...

It proves that you are one of those Java only developers too stupid to learn new languages. Sorry but it is true. Do yourself a favor and take a week to learn a dynamic language. You will thank me for the advice. You will also realize all talk about Java being "enterprise grade," more robust, scalable, yadda yadda is just bullshit.

Java is the shovel and "cutting-edge" languages such as Python, Ruby and even PHP are the digging machines.

[...]

Java programmers who are to stupid to experience more advanced technologies doesn't understand it either.

Hold on there for a sec. PHP is an advanced technology? Really??? Crap like this http://lwn.net/Articles/379909/ is what 'advanced' technology is about?

PHP is basically JSP with plain Java SE on it, and a rather poor version of that approach that this. It's perfectly suited for Joe's Burgers 4 page website, but when something more 'advanced' is needed, PHP just doesn't cut it.

For instance, the platform offers zero provisions for any form of concurrency. There is not even something like the basic threading support that Java has had since 1.0, let alone that there is any support for simple asynchronous execution (e.g. the @Asynchronous annotation) or highly efficient parallel computing paradigms like a fork/join framework. And what about an O/R mapper that comes with Java by default? How about dependency injection? What about declarative transactions? What about transactions that automatically span multiple method calls and multiple transactional resources?

Does PHP offers anything like that? Does the standard PHP library already comes with an MVC framework? Is unicode already natively supported? Is there any name spacing support? Is there ...

I can produce results ten times as fast by using Django/Python/nginx than with J2EE/Java/Glassfish

And I can produce results a hundred times as fast by using Java EE/Java/JBoss AS than with Django/Python and surely PHP. I'm not sure what this proves though... Also, don't forget that hacking together stuff and throwing it out is nice when you're 16 and in high school, but in the real world maintainability, correctness, stability, scalability, etc etc all count and in the end are way more important than just the ability to get some prototype like code out of the door, that 'usually-works-but-breaks-down-every-tuesday-when-it-rains'.

This is no time to bring up the linux kernel response to out of memory situations.

No. That's not sufficient.

Disallowing USB drives helped the military cut down on infections, though.

How about: users run restricted. Using GPO's: mandatory win updates daily with reboot. Automate patching of commonly-used helpers like flash, shockwave, adobereader, firefox, java. And MS security essentials.

Some rigorous port filters on EVERY machine and iptables rules on routers and l3 switches...a whitelist approach.

Regional government of the autonomous community of Valencia (Spain) also switched to free software, last year they released a detailed report (english) of the problems they found and how they fixed it. It took a lot of time to complete it (4 years) and they still depend on propietary software for some systems. These migrations need a lot of work...

good Free implementations of h264 exist

If you're referring to ffmpeg, it's infringing on several patents held by MPEG-LA

whether you are safe or not depends on where you live and how judges interpret the law in your jurisdiction.

Theora? Don't hold your breath. Apple, (one of the members of the MPEG-LA patent pool) won't use it no matter what.

What's new here is that Apple is possibly thinking of making this a standard while owning critical patents on it, then after this is widespread (if it ever happens) crackdown on competition using its patents.

Apple is becoming more evil lately, see the recent attempt to shut down competition on smartphones from HTC using completely trivial software patents (the original article is from LWN, I highly suggest getting a subscription there).

Sounds familiar? Remember GIF? MP3? h.264? Yeah, I know, this last reference will get me modded as troll.

In all honesty, while I have the utmost respect for Andrew Tridgell, bitkeeper was not the most difficult reverse engineering he's ever done. The protocol was basically in English, and had a help menu. Quite friendly of it.

I'm going to once again say that the difficulty here, with Toyota, is going to be collecting the data and correlating it with real events. Figuring out the basic packet structure, and maybe the timestamps, will be easy, but beyond that, even if you manage to figure out that a certain data field is X bytes long, you still have to figure out the human meaning of that field. And that is essentially impossible unless you can correlate it with real events that happened in the real world. Some events will be easy to figure out, like 'pressing the break,' but other events will be significantly harder to figure out, like 'airbag expands.'

It's not impossible, but it is significantly harder than cracking the Ubisoft DRM.

Novell really needs to ramp up their marketing, a la the Goldfish/David Bowie "Change" commercial. SuSE is a solid product with a much more mature configuration interface than RedHat, at much lower support contract fees. It is used in quite a few large organizations which I am not at liberty to discuss (non-disclosure agreements and what-not.) They are in the best position for Active Directory/Linux integration products, and would do very well to very broadly advertise their companies new direction.

I have used SuSE for years, it did indeed take a hit in usability when Novell bought it. It has since been developed and become a very stable and refined platform.

Novell is one of the top contributors to the Linux kernel. The OSS community, as much as they dislike Novell's interactions with Microsoft, would see less development with it's break up and the distribution of its parts.

AFAIK, the problem with Microsoft-TomTom was not that they used FAT32 per sé, but that they dared to use long filenames (oh noes!). THAT's still patented.
This has apparently been remedied since: LWN article on 2009-06-27. I don't know in which versions of the kernel it is patched, though.

Google's own approach is to fork everything they use... Sure, they make their changes available, but, apparently, don't try very hard to just stick to the original versions of whatever they pick.

The more famous of recent examples are the forks in Chrome. The changes, that Google made to their own versions, are substantial enough for their forks to be incompatible with the stock versions in too many cases. Was that really necessary?.. Google thinks, it was, but I am not convinced by their argument. At all...

Hard to blame the device-makers for taking a particular snapshot of Android OS, forking it, and not wanting to retest everything for an upgrade six months later...

I always liked Sun's position, prohibiting forks of Java by the very license — for this exact reason. You may think, you need to fix this burning bug with "the fierce urgency of now", but, by creating your own slightly-incompatible fork, you are doing more harm than good. (Such local forks are only excusable, when the upstream project is dead or almost dead...)

Too many programmers, too few software engineers...

Linux never uses a bit of VM unless you need it.

Actually it does. But they're fixing that too.

Linux uses available memory for cache, and rather aggressively. All available memory can be filled with cached file blocks. This happens routinely on systems which have big randomly-accessed files open, like databases.

There's nothing wrong with this, except that, once in a while, Linux hits a race condition in prune_one_dentry, causing an "oops" crash, when there's an unblockable need for a memory page and something is locking the file block cache.

This is one of the Great Unsolved Mysteries of Linux. Linus wrote about it in 2001 ("I'll try to think about it some more, but I'd love to have more reports to go on to try to find a pattern.. "). As of 2009, this area is still giving trouble. The locking in this area is very complex.

clearly your post was a joke, but a serious answer to your question would be Linux Device Drivers: http://lwn.net/Kernel/LDD3/ Understanding the linux kernel: http://oreilly.com/catalog/9780596000028 I found both books fantastic and well worth a read, they will take you from knowing C to developing drivers for the linux kernel.

Linux Weekly News perhaps? http://lwn.net/

When I try to do it here, it creates a new list with a new name (the current date and time)

I can only presume that Kubuntu uses a much modified version of Amarok - I don't even know if it uses the same mysql backend as Debian. I can understand your frustation with the Kubuntu forum. Web page in squintovision(tm), many of the posters badly post their problem description - then re-post shortly afterwards to say that they will use something else... Posts with problems appear in "Help the new guy" and "Software support" which doesn't help locating an answer to a problem.

When

it creates a new list with a new name

can you change the name to the original playlist name? I did find one useful link there (though I only searched for about 10 minutes).

No I'm truly lost... From left to right on the default Amarok menubar: Amarok, View, Playlist, Tools, Setting, Help.(letter in bold is the hotkey)

I only have Amarok, Playlist, Tools, Settings, Help. No View :-(

Correction: I meant "Now I'm truly lost

Tried that already. Most of the time I get "this is the wrong place for reporting 'pet peeve' type bugs.

How sad/pathetic (of them). I tried searching for "pet peeves" flamebait - those posts must of been deleted - perhaps if I check cached copies...

We have no choice, they dropped support for KDE 3 upstream, so we had to go along and have no choice in this"

Another lame (Kubuntu) response... It's fairly simple to replace Amarok2 with Amarok. Kubuntu is repackaged Ubuntu - I've recently replaced Amarok2 with Amarok on a clients Ubuntu laptop.

I'm not sure how I can assist you further. I don't use Kubuntu (or Ubuntu). As a business I don't support Kubuntu either (we are currently debating dropping support for Ubuntu) 'cause supporting SLAs for unstable is like nailing snot to the wall.

This link gives the developers reasons for Amarok2 (an restates the "we warned you KDE4 wasn't for production" line).

As a final suggestion - have you tried juk, minirok, kaffeine or songbird? Cheers

That's a patent application, not a patent. It was denied.

Stallman uses something different to browse:

To look at page I
send mail to a demon which runs wget and mails the page back to me.
It is very efficient use of my time, but it is slow in real time.

Source.

Very strange.

This isn't obvious to LKML because most of the redesign would be in non-kernel code, but the scope of work really is that large. Google is not rejecting a better design simply out of spite; Google is rejecting the better design because the amount of effort to implement it is something that LKML would balk at doing to their own codebase.

Citation needed. Kernel people are not oblivious to userland needs. I can't say how much work it would be for Google to fix Android, but at least according to one LWN comment, Android could be made mainline-palatable without breaking userland interfaces: http://lwn.net/Articles/372631/

Some drivers would need to be modified as well, of course, but I think it's better to do the work early than late when you realise you really should've listened to the mainline developers.

Here's an interesting report from one of the realtime tree developers: http://lwn.net/Articles/372877/

This isn't obvious to LKML because most of the redesign would be in non-kernel code, but the scope of work really is that large. Google is not rejecting a better design simply out of spite; Google is rejecting the better design because the amount of effort to implement it is something that LKML would balk at doing to their own codebase.

Citation needed. Kernel people are not oblivious to userland needs. I can't say how much work it would be for Google to fix Android, but at least according to one LWN comment, Android could be made mainline-palatable without breaking userland interfaces: http://lwn.net/Articles/372631/

Some drivers would need to be modified as well, of course, but I think it's better to do the work early than late when you realise you really should've listened to the mainline developers.

Here's an interesting report from one of the realtime tree developers: http://lwn.net/Articles/372877/

"OMG fork!" and other political issues aside, I think it's interesting to look at the technical side of the problem. What is the exact nature of Google's changes to the kernel, why did they feel they need them, and are they actually a good idea or not? Can someone with kernel hacking experience enlighten us?

I'm particularly curious after reading the comments on LWN, and specifically this:

Kernel developers (including other embedded developers who have achieved good power savings modes) don't believe that the Android way of doing things is good.

and this:

The code could be mainlined if Google were willing to consider that their wakelock approach was suboptimal and adapt to a more reasonable one. ...

The wakelock patches were first posted to the linux-pm list on the 13th of January 2009, which is just over a year ago. http://lwn.net/Articles/318611/ gives a good overview of how they were received - there's basically no buy in, even from other developers in the embedded Linux field. ...

the major sticking point (ie, wakelocks) were posted for public review a year ago and most of the substantive issues people had with them weren't addressed at all in the four months of intermittent discussion that followed. If the entire world suggests that you do something in some other way and you refuse to, that doesn't constitute a genuine effort to work with them. Nokia have managed to obtain the same level of power management without such invasive changes, so any assertion that wakelocks are required for Android to achieve its goals seem pretty baseless.

So apparently the issue at the heart of this is a questionable design decision by Google.

"OMG fork!" and other political issues aside, I think it's interesting to look at the technical side of the problem. What is the exact nature of Google's changes to the kernel, why did they feel they need them, and are they actually a good idea or not? Can someone with kernel hacking experience enlighten us?

I'm particularly curious after reading the comments on LWN, and specifically this:

Kernel developers (including other embedded developers who have achieved good power savings modes) don't believe that the Android way of doing things is good.

and this:

The code could be mainlined if Google were willing to consider that their wakelock approach was suboptimal and adapt to a more reasonable one. ...

The wakelock patches were first posted to the linux-pm list on the 13th of January 2009, which is just over a year ago. http://lwn.net/Articles/318611/ gives a good overview of how they were received - there's basically no buy in, even from other developers in the embedded Linux field. ...

the major sticking point (ie, wakelocks) were posted for public review a year ago and most of the substantive issues people had with them weren't addressed at all in the four months of intermittent discussion that followed. If the entire world suggests that you do something in some other way and you refuse to, that doesn't constitute a genuine effort to work with them. Nokia have managed to obtain the same level of power management without such invasive changes, so any assertion that wakelocks are required for Android to achieve its goals seem pretty baseless.

So apparently the issue at the heart of this is a questionable design decision by Google.

"OMG fork!" and other political issues aside, I think it's interesting to look at the technical side of the problem. What is the exact nature of Google's changes to the kernel, why did they feel they need them, and are they actually a good idea or not? Can someone with kernel hacking experience enlighten us?

I'm particularly curious after reading the comments on LWN, and specifically this:

Kernel developers (including other embedded developers who have achieved good power savings modes) don't believe that the Android way of doing things is good.

and this:

The code could be mainlined if Google were willing to consider that their wakelock approach was suboptimal and adapt to a more reasonable one. ...

The wakelock patches were first posted to the linux-pm list on the 13th of January 2009, which is just over a year ago. http://lwn.net/Articles/318611/ gives a good overview of how they were received - there's basically no buy in, even from other developers in the embedded Linux field. ...

the major sticking point (ie, wakelocks) were posted for public review a year ago and most of the substantive issues people had with them weren't addressed at all in the four months of intermittent discussion that followed. If the entire world suggests that you do something in some other way and you refuse to, that doesn't constitute a genuine effort to work with them. Nokia have managed to obtain the same level of power management without such invasive changes, so any assertion that wakelocks are required for Android to achieve its goals seem pretty baseless.

So apparently the issue at the heart of this is a questionable design decision by Google.

"OMG fork!" and other political issues aside, I think it's interesting to look at the technical side of the problem. What is the exact nature of Google's changes to the kernel, why did they feel they need them, and are they actually a good idea or not? Can someone with kernel hacking experience enlighten us?

I'm particularly curious after reading the comments on LWN, and specifically this:

Kernel developers (including other embedded developers who have achieved good power savings modes) don't believe that the Android way of doing things is good.

and this:

The code could be mainlined if Google were willing to consider that their wakelock approach was suboptimal and adapt to a more reasonable one. ...

The wakelock patches were first posted to the linux-pm list on the 13th of January 2009, which is just over a year ago. http://lwn.net/Articles/318611/ gives a good overview of how they were received - there's basically no buy in, even from other developers in the embedded Linux field. ...

the major sticking point (ie, wakelocks) were posted for public review a year ago and most of the substantive issues people had with them weren't addressed at all in the four months of intermittent discussion that followed. If the entire world suggests that you do something in some other way and you refuse to, that doesn't constitute a genuine effort to work with them. Nokia have managed to obtain the same level of power management without such invasive changes, so any assertion that wakelocks are required for Android to achieve its goals seem pretty baseless.

So apparently the issue at the heart of this is a questionable design decision by Google.

If you head over to LWN, we've already gone back and forth on this a bit. http://lwn.net/Articles/372419/. The short form is that if they don't like how we use the kernel, we're unlikely to be accepted upstream. It's all still released as source code to the world, but the mainline is not interested in most of what we've with to the kernel.

I copy pasted this info from here: http://lwn.net/Articles/372416/

These three Nokia patents look like they could be enforced against Theora:

http://www.google.com/patents/about?id=Ic0CAAAAEBAJ
http://www.google.com/patents/about?id=ieIVAAAAEBAJ
http://www.google.com/patents/about?id=zGWBAAAAEBAJ

Your post is either erroneous or misleading - ATI has closed source Catalyst drivers that support Evergreen cards with 2D and 3D acceleration. What the Evergreen cards haven't had up until now is the open source driver support. However, the open source driver support for NVidia cards is much worse because the developers are having to reverse engineer functionality from NVidia's closed source drivers because NVidia hasn't made any open hardware specs available. When it comes to open source driver support for 2D and 3D acceleration, NVidia lags far behind AMD/ATI and Intel. As a post in the above link indicates, in the long run the shared open source code base eventually will be a significant competitive advantage for Intel and AMD and a disadvantage for NVidia.

I have switched over to the open source AMD R600 drivers because, even though the 3D support is not yet quite as good as the closed source drivers, it should catch up and it's already good enough for what I do. In the meantime I won't have to worry about waiting a number of months for the closed source drivers to become available when a new distro/kernel release requires new binary blobs from the vendor. That also means that my graphics hardware investment is protected and not dependent on the continued support of the hardware vendor if I want to continue to upgrade the O/S in the future.

Even pure Javascript extensions aren't "secure". They can access all the usual XPCOM interfaces to do nasty things like overwrite all your files, and in later versions, they can use the Javascript foreign function interface to call any code C++ could.

It is essential to look at Javascript extensions as having the same security properties as native code ones.

However, plugins can be safer because their more clearly delineated NPAPI interface allows them to be run out of process, where in principle, they can be sandboxed.

In November Greg K-H said "We change something like 5,000 lines a day, which is just scary. Fifty percent of that change will be in the drivers, and five percent will be in the core kernel."

According to LWN "2.6.32 is the result of 10,767 non-merge changesets sent in by 1,229 developers. This changes added a total of 1.17 million lines, while removing 611,000 lines, for a net growth of 559,000 lines of code." This isn't out of the ordinary, either (e.g. " 2.6.31 development cycle had seen the incorporation of 10,663 non-merge changesets from 1,146 individual developers. These patches added almost 903,000 lines of code and removed just over 494,000 lines, for a net growth of just over 408,000 lines.").

As for this stuff all being minor, read LWN, or the Kernel Newbies changelog, and see how long you keep that illusion.

Since the 2.4 -> 2.6 transition was so bad, Linus is unlikely to ever again do a "break the world" change, either with or without a long lived dev branch like 2.5. And really there is no need, short of switching to a microkernel or a managed language, everything can be done as a series of gradual changes (see: the ongoing TTY rework, KMS/DRI2, the relatively recent power-saving/suspend work, the gradual removal of the big kernel lock, the /x86_64/ -> /x86/ merge, the addition of mutexes (~2006Q1), someday the realtime stuff will probably be merged without a major version bump, etc)

Are we ever going to see major new features (along the lines of the USB implementation, or SMP), or a major re-think? Or is this basically as good as it will ever get?

USB and SMP are things the kernel implemented, but weren't created inside it. The kernel can't add implementation for a bus that doesn't exist, so it's not going to get more things like that, unless new standards get created.

But, new things get added all the time, just watch the kernel reports at LWN.

May I point you to: The Thin Line Between 'Victim' and 'Idiot' and The isolate utility

And also a shoutout to lwn.net from whom I've been stealing much information for my Slashdot submissions and not giving them appropriate credit.

There's a dude here: http://lwn.net/Articles/366266/
who suggests that the blob Nouveau currently downloads to the card is reasonably well understood and should get rewritten at some stage.

Another dude: http://lwn.net/Articles/366257/
Suggests that older GeForce cards don't need the blob.

I'm not wanting to contradict you, by the way, just wanted to note what the options are for people wanting to use Nvidia / Nouveau but who are wary of the blobs.

There's a dude here: http://lwn.net/Articles/366266/
who suggests that the blob Nouveau currently downloads to the card is reasonably well understood and should get rewritten at some stage.

Another dude: http://lwn.net/Articles/366257/
Suggests that older GeForce cards don't need the blob.

I'm not wanting to contradict you, by the way, just wanted to note what the options are for people wanting to use Nvidia / Nouveau but who are wary of the blobs.

That can't be Stallman... That particular troglodyte doesn't have a web browser or Internet connection.

most GPL code, including most of Linux, was simply taken from BSD sources and relicensed GPL. What you would do better to look at are clean GPL implementations

Conjecture

Er no, experience rather, from having worked with both GPL and BSD code for many years.

I am not aware of wholesale re-licensing just for the sake of it.

You're not aware of the Atheros relicensing then?

    http://kerneltrap.org/OpenBSD/Atheros_Driver_Developments

Where BSD code HAS been incorporated into GPL it has been done to comply with the BSD license, exactly as intended by the author

That's a novel way of looking at it, but it doesn't really hold water. The Atheros developers certainly did not want their work published under the more restrictive GPL. They, like myself, want all developers to benefit from our code, not only those who agree to publish deltas under the GPL exclusively. But then the GPL never has been about giving.

    http://lwn.net/Articles/247872/

I don't get where the resentment comes from

Conjecture! ;-) The resentment is in your assumption, it was neither intended in nor implied by the original message. So go ahead and downmod (again) anything critical of the GPL, just be aware that when you do you move Slashdot further from the facts and closer to a popularity contest.