Slashdot Mirror

Con Kolivas is still actively working on BFS, it's not unsupported. He's even got a patch for 2.6.36, which was only released on the 20th.
http://ck.kolivas.org/patches/bfs/

He's also got a patchset out that I use on all my desktops which includes a bunch of tweaks for desktop use.
http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/

No kidding. Talk about misinformation. An editor should really fix the summary.

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

Con Kolivas is still actively working on BFS, it's not unsupported. He's even got a patch for 2.6.36, which was only released on the 20th. http://ck.kolivas.org/patches/bfs/ He's also got a patchset out that I use on all my desktops which includes a bunch of tweaks for desktop use. http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/

Well, wikipedia says that it is an OS. refers to the family of Unix-like computer operating systems using the Linux kernel

Hell, even kernel.org says "Linux is a clone of the operating system Unix". Which implies that Linux is an operating system. Sure there are different distros of it that change it a little bit, but its still considered to be in the "top 3" for desktop OSs. You don't say that Windows, OS X and Ubuntu are the top 3, you would most likely say that Windows, OS X and Linux are the top 3.

Seems like Python would be the obvious second language to be compiled to Dalvik bytecode.

See this thread from back in 2008 before Android even shipped.

Linked at the bottom of that thread are the Dalkvik VM docs (link updated to head).

Also is a Stack Overflow post that links to many methods for Python and scripting languages to create Android apps. (Though some methods like Jython are still using Java.)

Here's your bug I think: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/268502

This is maybe an upstream bug, https://bugzilla.kernel.org/show_bug.cgi?id=12045

so it's not Ubuntu's fault. Debian has probably the same issue (hint: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=525220)

If you want to get it fixed, go on LKML and bluetooth userspace developer list, reproduce the issue and find the maintainer(s).

Ext4 doesn't have online defrag yet, it is planned. Btrfs has an fsck tool but it is not capable of fixing any problems on the disk, it can apparently only let you know there are problems (I say apparently because while I've used btrfs I haven't before had to fsck it thanks to lots of luck with not running into any hiccups during my usage). They say as much on the front page of the Btrfs wiki. To quote the main page of this wiki:

Btrfs is under heavy development, but every effort is being made to keep the filesystem stable and fast. As of 2.6.31, we only plan to make forward compatible disk format changes, and many users have been experimenting with Btrfs on their systems with good results. Please email the Btrfs mailing list if you have any problems or questions while using Btrfs.

Note that Btrfs does not yet have a fsck tool that can fix errors. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably if your machine crashes or loses power on disks that don't handle flush requests correctly. This will be fixed when the fsck tool is ready.

So not only are you railing against ext4 for a fsck operation which should take a long time (5TB? Come on, most people don't have 1TB in their box, and we're talking about desktop users), but you are unawares of the features and capabilities of both filesystems you are discussing. Btrfs is great, but it's not something Average Joe should be using just yet either in production or on their desktop. I have used it before and I will use it again in the future, but it is not complete yet.

If I had any mod points I probably just would have modded up ratboy666's reply because he did a fantastic job of explaining the whole situation.

> 1 directory extract locally... my SVN repo is 12Gb. [..]

I meant one extract instead of multiple checkouts. When I was working with subversion, I always had to play with multiple checkouts when working on several things at a time (not nice, but sometimes you're forced to). With SVN, no ability to stash the changes, need to be online to make a checkout or new branch, etc. And it's slow!

> That's a lot of network traffic and disc space for a lot of stuff I do not need to see of manage.

For the do not see. It's pretty educative to have the ability to understand why things are one way or another.
For the space, I don't know. I have a 320 G disk on my laptop, 12 G isn't much. And even:
* You don't need to clone all history
* if you decide to get the 12 G, then fine, it's a *one time* operation. That's less than one hour to write this on your disk (40 min at 40MB/s). Once.

> I suppose the git solution would be to have many
> repositories.. but then you're losing the
> benefit you've claimed.

I was talking of having one checkout per tree, instead of multiple checkouts per tree. Never claimed to have a single git tree.
And if you had multiple trees, you would probably not need them all.

E.g. http://android.git.kernel.org/ You can pick all trees, or just one.

> full local history: fair enough, but its not
> that big a deal, on the relatively few occasions
> I want history (that isn't just the previous
> version), a hit on the server isn't a problem.

* I use history more often than before now that it's quickly available (blame, find changes, etc)
* yes you can hit the server for history but it's damn slow, and _sometimes_ you don't have a server (server upgrade, server crash, network down, offsite, etc...)

> but ultimately you're going to send your commits to the server

I never said using git locally would remove the need for sane data handling procedure. It's the same if you work without committing to SVN.
With a DVCS, it's just faster to be able to commit anytime, and push every so often. You end up doing it more often and you make your code changes smaller, easier to review by your co-workers. YMMV

> I think git has its place, but for a business,
> the DVCS advantages are not so much of an
> advantage, and the disadvantages usually
> outweigh them

I probably didn't do a fine job selling git out.
I know many businesses that use git (or mercurial) with great pleasure and they wouldn't go back for anything.

I won't spend more time trying to convince you. I agree that for some people, especially with git, DVCS can seem a bit too complicated.

For me it's a paradigm shift.

Given your comments, I am not sure you really tried one. I advice you to try one DVCS for yourself for a full week. And start with bridging SVN with git or mercurial.

The risk for Android is that it puts Linux's chaos and complexity front and center in the mobile phone market and ends up burning out customers because people are overwhelmed with choices and malware.

What? Linux?

OH NOS, THERE IS A BUNCH OF VERSIONS ON KERNEL.ORG, TOO MUCH CHOICE!!!

What does this have to do anything?

Hmm... 2.6.32. Did they fix this bug:

https://bugzilla.kernel.org/show_bug.cgi?id=16991

The Kernel is the only thing in there that ISN'T from RedHat

This is wildly misleading. Almost everything Red Hat ships in Enterprise Linux is not from Red Hat. Projects like GCC, RPM package manager, Gnome, Glibc, KDE are all too big for Red Hat to develop on its own. The only things I can think of that are completely from Red Hat are layered products like Directory Server or projects where Red Hat has maintainership and majority contributions, like NetworkManager.

Having said that, I can't think of a kernel contribution report in recent years where Red Hat was not #1.

Apparently to call it a "new" kernel TFA feels they should have started entirely from scratch.

To call it a "new" kernel it has to be something less than nine months old.

Just to clarify I understand that there are two zero day root-providing bugs. (Everyone talks about THE bug.)

CVE-2010-3301 patched by http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=36d001c70d8a0144ac1d038f6876c484849a74de and http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=eefdca043e8391dcd719711716492063030b55ac

CVE-2010-3081 patched by http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c41d68a513c71e35a14f66d71782d27a79a81ea6

Just to clarify I understand that there are two zero day root-providing bugs. (Everyone talks about THE bug.)

CVE-2010-3301 patched by http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=36d001c70d8a0144ac1d038f6876c484849a74de and http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=eefdca043e8391dcd719711716492063030b55ac

CVE-2010-3081 patched by http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c41d68a513c71e35a14f66d71782d27a79a81ea6

Just to clarify I understand that there are two zero day root-providing bugs. (Everyone talks about THE bug.)

CVE-2010-3301 patched by http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=36d001c70d8a0144ac1d038f6876c484849a74de and http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=eefdca043e8391dcd719711716492063030b55ac

CVE-2010-3081 patched by http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c41d68a513c71e35a14f66d71782d27a79a81ea6

Actually, I think it's a code quality issue.

Look at http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.35.y.git;a=commitdiff;h=d4d67150165df8bf1cc05e532f6efca96f907cab

It seems to me that the critical line of code reloading EAX was deleted because the committer couldn't see why it was necessary, and there was no comment in the code to explain its purpose. With no comment, and no unit test to guard against regressions (and I recognise that isn't always practical), this was an accident waiting to happen.

Actually, the changed code is commented in the offending patch
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.35.y.git;a=commit;h=d4d67150165df8bf1cc05e532f6efca96f907cab

Thanks Redhat dude.

BTW, is it the norm for kernel developers to sign-off commits for their own patches? Maybe if someone else was responsible for reviewing and signing-off on the patch, this could have been caught ahead of time? Another person could have missed it too, but then again, maybe not.

Well yes it does require a firmware still however now one is free to distribute said firmware
provided by the kernel under this firmware license
(provided in git commit: 8ce599d7e75d7e998a325408ae9507bf9e3388c0)

So it would be in the linux-firmware package or something, usually already installed for with your
distrobution of choice.

so they've released the firmware too but only in binary form under thier license

Well yes it does require a firmware still however now one is free to distribute said firmware
provided by the kernel under this firmware license
(provided in git commit: 8ce599d7e75d7e998a325408ae9507bf9e3388c0)

So it would be in the linux-firmware package or something, usually already installed for with your
distrobution of choice.

so they've released the firmware too but only in binary form under thier license

well yes it does require a firmware still however now one is free to distribute said firmware
provided by the kernel under this firmware license

so it would be in the linux-firmware package or something usually already installed for with your
distrobution of choice.

so they've released the firmware too but only in binary form under thier license

How is this news? Driver source is available in android git from a long time.

Is this a bug in phy/wlc_phy_cmn.c? Channel 216 doesn't follow the pattern set forth above it -- or is channel 216 really at presumably 50.8GHz instead of 5.08GHz?

A lot (but not all) of wireless cards are usually embedded ARM processors with a radio glued on. The operating system driver just talks to the firmware, and the firmware does most of the heavy lifting. Some cards store firmware in flash, but some store it in RAM and it has to be uploaded from the host computer every time the device is reset.

Does anyone know whether these chipsets do require firmware, and if so whether it's included in the source release?

I found it here:

http://git.kernel.org/?p=linux/kernel/git/gregkh/staging-next-2.6.git;a=commit;h=a9533e7ea3c410fed2f4cd8b3e1e213e48529b75

Looks like MIT/BSD style license.

It shouldn't be a program's fault.

I'd check for things like filesystem corruption, disk problems and other hardware issues or network problems if over the network. Try "dmesg" and see if there's anything unusual in the log when the problem happens. If it's none of that, it may be that the program is indeed running into a kernel bug somewhere. Trying a newer/older kernel to see if it makes any difference could clarify something in such a case. And if it looks like a kernel issue, report it to the kernel developers.

Btrfs is under heavy development, but every effort is being made to keep the filesystem stable and fast. As of 2.6.31, we only plan to make forward compatible disk format changes, and many users have been experimenting with Btrfs on their systems with good results. Please email the Btrfs mailing list if you have any problems or questions while using Btrfs.

OK, I guess the word "finalized" was a bit premature. It's "forwards-compatible", lol. I run 2.6.32 btw.

Note that Btrfs does not yet have a fsck tool that can fix errors. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably if your machine crashes or loses power on disks that don't handle flush requests correctly. This will be fixed when the fsck tool is ready.

https://btrfs.wiki.kernel.org/index.php/Main_Page

Its easy to DOS the BTRFS and kill the system. A normal user can do it. Just create a couple of big files. Then, copy a large number of small files. You will get ENOSPC at around 90%. Then, delete the large files. Even with most of the space being free, it won't allow you to create new files. All new requests will get ENOSPC. Bug is at: https://bugzilla.kernel.org/show_bug.cgi?id=16508 BTRFS is a mess. Go read their mailing lists.

You aren't supposed to read the GPL, only its preamble. The rest of meant for lawyers and is as long as it takes to be bulletproof.

Wow, bulletproof? I'm a lawyer, I've worked with very smart lawyers, and no one I know of would call the GPL "bulletproof." Or even all that comprehensible. For instance, the lack of a definition of "derived works," which the Apache license at least gets right. The ambiguity created (leading to the LGPL and Linus having to include his interpretation to the Linux copyright: This copyright does *not* cover user programs that use kernel
  services by normal system calls - this is merely considered normal use
  of the kernel, and does *not* fall under the heading of "derived work" (http://www.kernel.org/pub/linux/kernel/COPYING)... It's a massive headache waiting to happen.

"I've seen many similar statements, so there may be some truth to this, but my experience is that they give you a short-as-possible only-most-relevant question such as "Can you bisect?" or reply like "Patch rejected: missing signoff". It appears their time is very valuable or they have to pay $5 pr. typed letter"

Behold the phenomenal power off Open Source! The time of each and every kernel developer is in fact a highly valuable commodity, yet I get the benefit of the fruits of their labor without shelling out a sixpence! And the best part? This was fixed last week.

Also if you read linus's patch notes they're the exact same problem.

From the RedHat bug report: Eugene Teo (Security Response) 2010-08-12 21:44:06 EDT Linus has committed a fix for this issue: http://git.kernel.org/linus/320b2b8de12698082609ebbc1a17165727f4c893

They patched it, I don't know what you expect them to do beyond that. "Silently" just means that slashdot didn't pick up on it or something.

Also,

Do you honestly think that Microsoft would do nothing if there was a non-patched privilege escalation exploit in Windows?

Are you kidding?

The nouveau NVidia drivers are now way mature enough to deploy on a consumer OS. If you want it to move faster and become stable, contribute to the development at http://nouveau.freedesktop.org/wiki/. The RT2700 drivers seem to be a Kernel issue. See http://kernel.org/ for information on how to contribute. Ubuntu usually ships with recent kernels.

I don't really know what your problem is, but Canonical is not your nanny. They are a distribution company. Their main focus is to merge Linux based software into a nice, somewhat polished consumer distribution, and I think they do very nice work with that. Especially considering that they only employ 350 people altogether.

Now if they get profitable some time in the next years (with their business/cloud support, music store and upcoming appstore), they can hire more employees, and focus on other things too. So if you don't feel like contributing with development time, you can also buy products in their stores and support them so they get more resources and do other stuff too.

Finally: stop bitching around without moving a finger / dollar. You won't change anything with that.

Of course, Oracle controls btrfs as well, and its future doesn't exactly look so great at this point, either

Oracle doesn't control btrfs. It's part of the Linux kernel. Oracle pays the one who's currently in charge of btrfs development, Chris Mason, but a) someone else could take over if he left (look at how many developers there are); and b) plenty of other companies would be willing to hire him if Oracle didn't want to pay him to work on btrfs anymore. Oracle has influence over btrfs, but not control.

Of course, Oracle controls btrfs as well, and its future doesn't exactly look so great at this point, either

Oracle doesn't control btrfs. It's part of the Linux kernel. Oracle pays the one who's currently in charge of btrfs development, Chris Mason, but a) someone else could take over if he left (look at how many developers there are); and b) plenty of other companies would be willing to hire him if Oracle didn't want to pay him to work on btrfs anymore. Oracle has influence over btrfs, but not control.

Oracle also owns BTRFS. Anyone that develops IP whilst an employee gives Oracle full ownership of the that IP.

Oracle could change the license of BTRFS from GPL to closed source tomorrow if they wanted to.

Lots of people have contributed to btrfs. It's part of the Linus' tree, not a separate thing that Oracle controls. Oracle only holds the copyright on what its employees (like Chris Mason) have written. It couldn't release a closed-source version of the filesystem without getting licenses from all the non-Oracle people who contributed, or rewriting all their code. You only need to look over the commit history to see how many people that is. Most of the commits don't look like they come from Oracle employees, judging by the e-mail addresses.

Oracle also owns BTRFS. Anyone that develops IP whilst an employee gives Oracle full ownership of the that IP.

Oracle could change the license of BTRFS from GPL to closed source tomorrow if they wanted to.

Lots of people have contributed to btrfs. It's part of the Linus' tree, not a separate thing that Oracle controls. Oracle only holds the copyright on what its employees (like Chris Mason) have written. It couldn't release a closed-source version of the filesystem without getting licenses from all the non-Oracle people who contributed, or rewriting all their code. You only need to look over the commit history to see how many people that is. Most of the commits don't look like they come from Oracle employees, judging by the e-mail addresses.

So does this mean that Android is not truly open source, i.e. available to anyone without right holder approval?

You can browse the source right here. All of that code should be Apache 2.0 license. I think the issue at stake is that they took a module of code that connects to Google's Market place for Android and they're not supposed to be doing that unless they are a member of the Open Handset Alliance. It's not like Google's launching a lawsuit against them but I'd imagine Google doesn't really appreciate that. Hosting that sort of thing can't be cheap (look at how much Apple claims it loses distributing apps) and maybe that's why your membership is needed -- to support that and keep it going.

I never realized that one had to a member of fruity club to develop Android hardware. I thought that was the point, anyone could innovate without corporate approval. It is just a gimmick to sell phones with promise of multi vendor support 'open apps', like MS?

You can get the source yourself and do whatever the hell you want with it. Carriers and phone vendors are demonstrating that they can even lock down Android so "open" doesn't mean f-ckall to the end consumer. You want to get down and dirty and hose up your own version of Android? Go ahead and pull it from that git repository linked above and do something fancy with the sqlite phonebook tree or whatever you want.

It's open source as can be but how do you "open source" a centralized app store with tons of traffic? I guess you're free to make your own app store and as far as I know, more are emerging. With sideloading you could make it as simple as a file download as long as the user's Android supports sideloading.

So does this mean that Android is not truly open source, i.e. available to anyone without right holder approval?

You can browse the source right here. All of that code should be Apache 2.0 license. I think the issue at stake is that they took a module of code that connects to Google's Market place for Android and they're not supposed to be doing that unless they are a member of the Open Handset Alliance. It's not like Google's launching a lawsuit against them but I'd imagine Google doesn't really appreciate that. Hosting that sort of thing can't be cheap (look at how much Apple claims it loses distributing apps) and maybe that's why your membership is needed -- to support that and keep it going.

I never realized that one had to a member of fruity club to develop Android hardware. I thought that was the point, anyone could innovate without corporate approval. It is just a gimmick to sell phones with promise of multi vendor support 'open apps', like MS?

You can get the source yourself and do whatever the hell you want with it. Carriers and phone vendors are demonstrating that they can even lock down Android so "open" doesn't mean f-ckall to the end consumer. You want to get down and dirty and hose up your own version of Android? Go ahead and pull it from that git repository linked above and do something fancy with the sqlite phonebook tree or whatever you want.

It's open source as can be but how do you "open source" a centralized app store with tons of traffic? I guess you're free to make your own app store and as far as I know, more are emerging. With sideloading you could make it as simple as a file download as long as the user's Android supports sideloading.

Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3.

The "newer" standard is using spaces because the newer generation of developers are used to IDEs that does not handle vi and emacs style mode line well. Mozilla's code style guidelines is a prime example of this:

Indentation
Two spaces per logic level.

I, for one, would really rather the Firefox developers not be shot.

The fix for World of Warcraft under WINE made it into 2.6.35, though it is not mentioned in the changelist above. WoW 3.3.5 crashed under recent Linux kernels because it apparently made use of the "icebp" instruction, whatever that is; the kernel stopped sending SIGTRAP for icebp instructions in an earlier 2.6 build for whatever reason.

Diff of fix
Source code of file, showing the icebp fix merged in (search for "icebp")
WINE compat page

He seems to function well enough, but do not pretend he is perfect.

He may not be perfect, but he is by far the best "leader" (whether project or corporate) that I've *ever* seen. He may be insulting, but he does it to everyone to scare off the timid and to make people reconsider their ideas. He is extremely technically competent and humble, two traits which are invaluable in a technical manager. Something you may want to read: Linux Kernel Management Style.

As for taking ideas and giving them to "favored" developers: 1) at least he admits when he is wrong and 2) why do you think those developers are favored? Ideas are a dime a dozen; implementing them well (and in a way that fits in with the Linux kernel) is the hard part.

I'm sorry, this is utterly ridiculous - you claim the N1 is not more "open" than the iPhone? When the entire kernel and 95% of userspace is open source (as in, Here Is The Source, Check it Out with Git), installing non-approved apps involves merely checking a box, rooting the device is barely more difficult than that, and even if you stick to approved apps Google exerts almost no restrictions on what you can develop (and yes, tethering apps are included, without root, in contradiction to your assertion). When there are developers out there like Cyanogen checking out the source themselves and recompiling it into ROMs you can flash onto the device with the full blessing and approval of Google? The N1 is not more open than an iPhone?

Please, make whatever arguments you like about the quality of Android and iPhone ecosystems, but if you care at all about what "open" means in the software world, do not pretend that there is no difference between Android and the iPhone on this point. It may not be very meaningful or useful to you in particular (though as a software developer developer it should be), but some of us care about it a lot.

The whole community is misunderstanding the argument about Linux kernel modules. First off, Mark Jaquith's assertion that Linux doesn't allow non-GPL kernel modules is just plain wrong. In Linus' own emails, he presents several lines of reasoning why he feels binary-only kernel modules don't violate the GPL.

Essentially, the kernel module interface is a "library" interface to the kernel, and kernel modules are considered to be under the GNU Library license. In fact, due to the way kernel modules work, you automatically do it according to the LGPL, so this isn't explicitly stated anywhere, but that's the way you should think about this.

and (what appears to be a separate justification)

The reason I accept binary-only modules at all is that, in many cases, you have, for example, a device driver that is not written for Linux at all, but, for example, works on SCO Unix or other operating systems, and the manufacturer suddenly wakes up and notices that Linux has a larger audience than the other groups. And as a result he wants to port that driver to Linux.

But because that driver was obviously not derived from Linux (it had a life of its own regardless of any Linux development), I didn't feel that I had the moral right to require that it be put under the GPL, so the binary-only module interface allows those kinds of modules to exist and work with Linux.

(though in 2001, he says these modules are mainly historical.)

The kernel tainting feature has partially to do with licensing and partially not.

To clarify the ambiguous legal ground on which non-GPL (particularly proprietary) modules lie. A strict reading of the GPL prohibits loading proprietary modules into the kernel. While Linus has consistently stated that proprietary modules are allowed (i.e. he has granted an explicit exemption), it is not clear that he is able to speak for all developers who have contributed to the Linux kernel. While many think Linus' edict means that all contributed code falls under this exemption granted by Linus, not everyone agrees that this is a legally sound argument. The new EXPORT_SYMBOL_GPL directive makes the licence conditions explicit, and thus removes the legal ambiguity.

But moreover, many kernel developers feel it's a waste of time to support code that interacts in such close quarters with binary-only modules that the kernel devs can't debug. Therefore, tainting serves a technical purpose as well as a legal purpose: letting developers refuse to support strange bugs caused by binary-only modules.

Linus does leave us with a final note, however:

Final note: the Linux interpretation is not a "normal" case. I wouldn't use it as a guide-line to anything else, especially not in user mode.

The final upshot really is that Linus's interpretation is what assures you he won't sue you. You'd need to look at relevant copyright case law to understand what would happen if you were sued about a derivative work such as a WordPress theme. That's a different ballgame entirely, and Linus' interpretations don't apply to that.

I agree fully that Android as it's being distributed isn't as open as it ought to be. However, it's still more open than iPhone in at least one non-trivial way:

http://android.git.kernel.org/

This is something a lot of people get confused. ("If it's open, why do you have to root it?")

What it is, is the AOSP (Android Open Source Project) is completely open. The source code to the Android tree is right here. You can do whatever you want with your own build of Android, nobody is stopping you. When it comes to phones, this is where the "openness" ends, other than the manufacturers having to contribute changes back to the source (which they do). However, the build of Android you buy on your phone certainly does not have to be open. The telcos usually want the bootloaders locked so you can't run an "unapproved" build of Android, and the provided builds of Android may include this crap, or even go as far as AT&T does and disable loading applications from anywhere but the Marketplace.

If you want to avoid the sort of problem like this shovelware/bloatware, make sure to get a phone running stock Android, like the Droid or the Nexus One (for example) that hasn't had the OS itself modified by the manufacturer (like with HTC Sense or Motoblur) or by the carrier (like with the EVO).

we'll be getting the source for the first version of iOS around 2035!

Or we could just look at the latest Android source around now.

Those big long hex numbers are revision id's in the GIT version control system used for the kernel. Perusing any instance of said repository (such as the one here will let you look at that commit, what files changed, what log messages were included, who made it, etc.

The disclosures aren't in a pretty clicky-clicky-box but the kernel devs *do* strive to maintain formats which cater to the major users:

for shell ninjas:
    wget www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.33 -O - | less

for geezers/people with lawns:
    telnet ftp.kernel.org 21

for the lamer++:
    http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.33

The should use ATA7 secure delete command instead, to flash the entire SSD (physicaly) to the initial value https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase