Slashdot Mirror

Get the real announcement on LKML: http://lkml.org/lkml/2011/7/21/455

https://lkml.org/lkml/2011/7/17/103

[Posted by Theovon earlier, but I prefer a clickable link.]

'VMWare lobby', WTF? The real problem were things like this and this:

The fact is (and this is a _fact_): Xen is a total mess from a development
standpoint. I talked about this in private with Jeremy. Xen pollutes the
architecture code in ways that NO OTHER subsystem does. And I have never
EVER seen the Xen developers really acknowledge that and try to fix it.

Thomas pointed to patches that add _explicitly_ Xen-related special cases
that aren't even trying to make sense. See the local apic thing.

So quite frankly, I wish some of the Xen people looked themselves in the
mirror, and then asked themselves "would _I_ merge something ugly like
that, if it was filling my subsystem with totally unrelated hacks for some
other crap"?

Seriously.

If it was just the local APIC, fine. But it may be just the local APIC
code this time around, next time it will be something else. It's been TLB,
it's been entry_*.S, it's been all over. Some of them are performance
issues.

I dunno. I just do know that I pointed out the statistics for how
mindlessly incestuous the Xen patches have historically been to Jeremy. He
admitted it. I've not seen _anybody_ say that things will improve.

Xen has been painful. If you give maintainers pain, don't expect them to
love you or respect you.

So I would really suggest that Xen people should look at _why_ they are
giving maintainers so much pain.

                Linus

BTW, I have absolutely no doubt that NetBSD and Solaris merged Xen faster than anyone else.

'VMWare lobby', WTF? The real problem were things like this and this:

The fact is (and this is a _fact_): Xen is a total mess from a development
standpoint. I talked about this in private with Jeremy. Xen pollutes the
architecture code in ways that NO OTHER subsystem does. And I have never
EVER seen the Xen developers really acknowledge that and try to fix it.

Thomas pointed to patches that add _explicitly_ Xen-related special cases
that aren't even trying to make sense. See the local apic thing.

So quite frankly, I wish some of the Xen people looked themselves in the
mirror, and then asked themselves "would _I_ merge something ugly like
that, if it was filling my subsystem with totally unrelated hacks for some
other crap"?

Seriously.

If it was just the local APIC, fine. But it may be just the local APIC
code this time around, next time it will be something else. It's been TLB,
it's been entry_*.S, it's been all over. Some of them are performance
issues.

I dunno. I just do know that I pointed out the statistics for how
mindlessly incestuous the Xen patches have historically been to Jeremy. He
admitted it. I've not seen _anybody_ say that things will improve.

Xen has been painful. If you give maintainers pain, don't expect them to
love you or respect you.

So I would really suggest that Xen people should look at _why_ they are
giving maintainers so much pain.

                Linus

BTW, I have absolutely no doubt that NetBSD and Solaris merged Xen faster than anyone else.

This has been in the pipeline for a while now and it kinda makes sense. Currently the 2.6.xxx has so many versions, it is no longer clear which is from when. His reasoning for the 3.0 as Linus says is that 2 decades have passed in the linux kernel development (Sounds like he's trying to avoid a conflict by giving a reason which cannot be argued against). But it also feels like the 3rd generation in linux kernels too with all the new hardware nowadays.

I feel somewhat relieved by this move.. its like i have been holding my breath for decades and can let it go now!

"I decided to just bite the bullet, and call the next version 3.0. It will get released close enough to the 20-year mark, which is excuse enough for me, although honestly, the real reason is just that I can no longe rcomfortably count as high as 40," said Linus.

He wrote on the lkml: "the real reason is just that I can
no longer comfortably count as high as 40."

I do not care about the version but his reasoning does not make any sense. He could as well have changed it to 2.8.0.

He wrote on the lkml: "the real reason is just that I can no longer comfortably count as high as 40."

It's just time to make a change...

There's also the timing issue - since we no longer do version numbers
based on features, but based on time, just saying "we're about to
start the third decade" works as well as any other excuse.

I like his 3.0 commit message
"Version numbers? We can increment them!"

Thankfully, Linus hasn't rewritten the kernel in VB.

Also this version has codename "Sneaky Weasel"

--- a/Makefile
+++ b/Makefile
@@ -1,8 +1,8 @@
-VERSION = 2
-PATCHLEVEL = 6
-SUBLEVEL = 39
-EXTRAVERSION =
-NAME = Flesh-Eating Bats with Fangs
+VERSION = 3
+PATCHLEVEL = 0
+SUBLEVEL = 0
+EXTRAVERSION = -rc1
+NAME = Sneaky Weasel
 

http://lkml.org/lkml/2005/3/2/247

It was the original intent at the beginning of 2.6.x anyway. Don't know how much it's still stuck to.

Visual basic actually.

http://lkml.org/lkml/2005/3/2/247

Yeah but can it run in IE6?

Visual basic actually.

http://lkml.org/lkml/2005/3/2/247

"In 2008 the principal developer of the ext3 and ext4 file systems, Theodore Ts'o, stated that ext4 is a stop-gap and that Btrfs is the way forward,[10] having "a number of the same design ideas that reiser3/4 had". http://en.wikipedia.org/wiki/Btrfs & http://lkml.org/lkml/2008/8/1/217

Having a single primary rule (with a small set of rules designed to support that rule) does not make you a dictator.

I seem to recall that the #1 Open Source project (Linux) chafes against what most so-called "F/OSS" devs.CALL "Open". Sir Linus doesn't like GPLv3, either, and in fact, thinks the whole FSF GPLv3 licensing bit is a sham.

Now what? This is a bit like the "Unlimited" internet service that Comcast OVERsold to everyone in their markets, then, when people actually started trying to exercise that condition of the agreement, suddenly, "Unlimited" became more and more of a bad joke (called breach-of-contract in any normal contractual agreement).

There may be no specific complains yet, but Linus has been quite explicit and unambiguous in the past about how he thinks the GPL applies to Linux kernel headers:

In short: you do _NOT_ have the right to use a kernel header file (or any other part of the kernel sources), unless that use results in a GPL'd program. ... BUT YOU CAN NOT USE THE KERNEL HEADER FILES TO CREATE NON-GPL'D BINARIES.

Of course, Linus is not a lawyer, and his interpretation of GPL may not be correct. But the gist of the original story was that it was legal analysis made by an IP lawyer, and he essentially agreed with Linus.

Oh, I know, I know! Linus is a paid Microsoft shill! Right?

Okay, now you're definitely trolling, seeing as we've dealt with that question numerous times, and the COPYING file makes it clear that you CAN use kernel headers to make user-land binaries without triggering the "distribution" clause.

What you can't do is make a closed kernel.

NOTE! 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".
Also note that the GPL below is copyrighted by the Free Software
Foundation, but the instance of code that it refers to (the Linux
kernel) is copyrighted by me and others who actually wrote it.

Also note that the only valid version of the GPL as far as the kernel
is concerned is _this_ particular version of the license (ie v2, not
v2.2 or v3.x or whatever), unless explicitly otherwise stated.

Linus Torvalds

GNU GENERAL PUBLIC LICENSE
Version 2, June 1991

So, since the limitations of the GPL (distribution of source) have been expressly waived for userland programs that only call kernel services, there is NO copyright violation for using the header files in such a fashion, ever.

But keep shilling. It gives more opportunity to refute your arguments.

There may be no specific complains yet, but Linus has been quite explicit and unambiguous in the past about how he thinks the GPL applies to Linux kernel headers:

In short: you do _NOT_ have the right to use a kernel header file (or any other part of the kernel sources), unless that use results in a GPL'd program. ...
BUT YOU CAN NOT USE THE KERNEL HEADER FILES TO CREATE NON-GPL'D BINARIES.

Of course, Linus is not a lawyer, and his interpretation of GPL may not be correct. But the gist of the original story was that it was legal analysis made by an IP lawyer, and he essentially agreed with Linus.

Oh, I know, I know! Linus is a paid Microsoft shill! Right?

Linus back in 2003 seems to disagree in this post, cited by one of TFA's:

"In short: you do _NOT_ have the right to use a kernel header file (or any other part of the kernel sources), unless that use results in a GPL'd program."

"So you can run the kernel and create non-GPL'd programs [...]
BUT YOU CAN NOT USE THE KERNEL HEADER FILES TO CREATE NON-GPL'D BINARIES.
Comprende?" -- http://lkml.org/lkml/2003/12/5/13

Most of the closed-source Linux apps link against LGPL'ed libraries and headers, NOT GPL like you say. If you link against a GPL'ed library, your program has to be GPL'ed.

See Linus' take on the GPL'ed kernel headers below. He's absolutely against your point:

http://lkml.org/lkml/2003/12/5/13

How much do you think such a proposal would cost, say, Bruce Schneier when he sends out his Crypto-Gram newsletter to people that have requested it?

Or how about the Linux Kernel Mailing List?

Or the messages Slashdot can send you when someone replies to or moderates your comment? [See the Account link at the top of the screen.]

($0.001 per email) * (many many emails to which the recipient has opted-in) = a lot of money for list owners to pay.

I don't want to see the mailing lists I like all go behind paywalls or stop sending out messages entirely.

Here is the actual article that the submitter should have linked to. It's Linus's post. Instead, the submitter linked to his or her advert site, which is a blog that has ads which hawk their own, non-git source control system, all of which you get to read before you are given the link to Linus's actual post.

If I compare the things Linus has done with what Poettering has done I think I know whose ideas I trust more.

Poettering seems to find things which are a mess and say "THIS looks like a job for SUPERMAN!!!!!!11" Since he's so brilliant and all, his design (done without consulting much with lesser mortals ) must be right, and if it breaks everything in the world and brings lots of design criticisms, well, the rest of the world and the critics (i.e. the morons) are what need fixing. Pulse was a disaster for years.

Favorite Poettering quote from this discussion: "Well, that nightmare already exists. It's systemd." Nightmare indeed.

Two things:

1) There isn't a difference between the kernel patch and the command line hack. They are equivalent. The command line bit was known beforehand because that was the method used to figure out if this kernel hack would be a good idea. The kernel hack just makes the process transparent.

Linus says: Right. And that's basically how this "patch" was actually tested originally - by doing this by hand, without actually having a patch in hand. I told people: this seems to work really well.

2) Linus recommends the kernel patch:

Linus also says:Put another way: if we find a better way to do something, we should _not_ say "well, if users want it, they can do this *technical thing here*". If it really is a better way to do something, we should just do it. Requiring user setup is _not_ a feature.

Source.

I dislike Phoronix, and if you do too, you might be interested in reading the original lkml thread.

Also, I wonder why LTTng is not mainline yet

Well, a bit of searching would have answered your question

The LTTng maintainer has been working for months (years?) to get the kernel tracing into a decent shape. These days the Linux tracing support is wonderful, and not just for LTT - perf, ftrace and systemtap are awesome tools (and more powerful than LTTng in some ways). In fact perf can do all what the web page says and it seems to be more simple for my taste

Some people stress out and perform poorly, some people write their own tools, some people just brake and drop out.

Email cannot do this. You end up with a clusterfuck of email messages from people that can be unrelated to your specific task and multiple versions of documentation that you need to track down in 200 attachments.

I wonder how the Linux Kernel Team manages this?

Maybe they don't use exchange?

Just kidding, they viciously flame those who waste their time. Ranting until someone's ears fall off is the only real way to respond.

There's also the VM fix from Wu Fengguang, included in v2.6.36, which addresses similar "slowdown while copying large amounts of data" bugs.

There were about a dozen kernel bugs causing similar symptoms, which we fixed over the course of several kernel releases. They were almost evenly spread out between filesystem code, the VM and the IO scheduler. And yes, i agree that it took too long to acknowledge and address them - these problems have been going on for several years. It's a serious kernel development process failure.

If anyone here still experiences bad desktop stalls while handling big files with v2.6.36 too then we'd appreciate a quick bug report sent to linux-kernel@vger.kernel.org.

Thanks,

Ingo

Well it would be easier to agree with him had Linus actually trolled about anything in the release announcement.

The only thing that comes close to trolling was his mater-of-fact accounting of the status of fanotify. It's not much of a troll considering that fanotify was set to be a one of the bigger bullet points of the release and got yanked at the last moment. It was worth mentioning. Also considering that it was yanked because of an oh shit late in the cycle he certainly could have been more pointed if he wanted to be.

If he were trolling it certainly was some of the weakest trolling to be had. He certainly wasn't the one using the "shit" word to describe the situation.

I've used incron on production boxen heavily over the past couple years and haven't noticed any problems with it, personally.

fanotify looks pretty sweet, though. Eric Paris made a sort of introductory post about it last year, which is a good read:

http://lkml.org/lkml/2009/7/24/242

Particularly interesting is his idea of adding 'rename' events. This would mean you could implement something like 'updatedb' in realtime, and always have current results for 'locate'. Not sure if the rename events made it in or not, still digging around.

http://lkml.org/lkml/2010/7/22/252 is a fun post on the Linux-Kernel list about missing caching of ACPI tables leading to 20 minute boot times. I get that problem every day! (I wish :P)

It is a pretty safe bet that you don't have to worry about Linux and more than 48 cores, as it is the OS of choice for a lot of the top supercomputers and OS research in general. Of course, applications which can take advantage of such systems is another problem, but that is hardly a Linux problem.

Excuse my nitpicking, your post sparked some new questions for me:

The problem stems when legitimate applications attempt to use that memory. How long does it take to page (read/wirte) 16GB, 4KB at a time?

Are you sure that's it's only reading/writing 4KB at a time? It seems pretty braindead to me.

The old 1:1+x and 2:1 memory to disk ratios are based on notions of swapping rather than paging (yes, those are two different virtual memory techniques), plus allowing room for kernel dumps, etc. Paging is far more efficient than swapping ever was.

Could you elaborate on the difference between swapping and paging? I have always thought of it (adopting the term "paging") as an effort to disconnect modern Virtual Memory implementations from the awful VM performance of Windows 3.1/9x. Wikipedia mentions them as interchangeable terms and other sources on the web seem to agree.

You might come back and say, one day I might need it. Well, one day you can create a file (dd if=/dev/zero of=/pagefile bs=1024 count=xxxx), initialize it as page (mkswap /pagefile), and add it as a low priority paging device (swapon -p0 /pagefile). Problem solved.

Just mentioning here that Swapspace (Debian package) takes care of that, with configurable thresholds.

You may say the performance will be horrible with paging on top of a file system - but if you're overflowing several GB to a page file on top of a file system, the performance impact won't be noticeable as you already have far, far greater performance problems. And if the page activity isn't noticeable, the fact its on a file system won't matter.

Quoting Andrew Morton:
"[On 2.6 kernels the difference is] None at all. The kernel generates a map of swap offset -> disk blocks at swapon time and from then on uses that map to perform swap I/O directly against the underlying disk queue, bypassing all caching, metadata and filesystem code."

Continuing a discussion...

Seems to be that this bheap just reduces the number of pages probably needed from log(n) to log(n)/C where C is the number of levels that are stored in the same page. And for removing a node it may need to access log(n)/C random pages. So this is just a constant factor improvement... it's just that the constant is number of pages so has a large real world cost.

I'd like to get people's thoughts on using timer wheels instead, like the linux kernel uses for timers. Say you take say 8 wheels of increasing spans of time where each wheel is just an unordered list:

insert: one of the 8 wheel list-ending pages must be resident (certainly will be)
delete: just zero out the list entry (probably 1 page-in).
remove min: 1 page to pop the list head at wheel 0, or a bunch of sequential accesses to cascade the expire timers down.

Could some data structure expert please comment on the relative merits of bheap vs timer wheels? Seems to me that a small fixed set of pages and sequential access should be far better in terms of swapping. The OS should be designed to recognize in-order access, especially if each list is a mmap'd file, and the thread blocked does not need to have any locks (you can replace the list with a new one while it is being processed).

You will have ex-BIOS programmers writing crap from the ground up to match a comitee-designed interface that is a LOT more complex than the BIOS.

Now read this: http://lkml.org/lkml/2010/5/13/270, and consider that it is the traditional Linus voice of experience (i.e. completely correct, if very nasty).

You can BET it will cause a massive amount of trouble, and just whatever subset is needed to run whatever current MS Windows versions that can deal with UEFI will work partially, anything else will cause your computer to corrupt its running state and die, probably erasing lots of its flash and trying to kill your dog while at it.

UEFI is too complex for firware writers to get even semi-right. It *will* be a disaster. And of course we will have UEFI rootkits thrown in the mix as well, to make matters worse.

Yes and there's a linux kernel patch that should cleverly circumvent that patent
http://www.linuxfordevices.com/c/a/News/FAT-patch/
http://lkml.org/lkml/2009/6/26/313
It hasn't apparently been tested in court so far though.

On U.S. soil, one wouldn't probably want to acid-test the above patch in court, somewhere was mentioned that it may cost up to $5M to defend yourself in court for a single patent infringiment, even if you would not turn out to be infringing a patent at all.

Cleancache was just recently posted to LKML: Cleancache [PATCH 0/7] (was Transcendent Memory): overview.

http://lkml.org/lkml/2010/4/5/41

I'm a little surprised at the lack of response on linux-kernel.

Solaris and DragonFly have already implemented this feature; I'm surprised that Linux is so far behind.

Some bugs are so deep the open source process can't fix them.

Some bugs are so deep that they are very difficult to fix. FTFY

Search Google for "prune_one_dentry oops". [...] nobody wants to take that on.

FUD. The fix is in the work for a long time. Christoph Lameter recently (01/29/2010) submitted the 15th iteration of the patch set. Hopefuly this time no unforeseen consequences will prevent it to be merged into the official kernel. You can read about it here: http://lkml.org/lkml/2010/1/29/332

How is this insightful? I read the lkml thread here and no one said anyone was stupid. In fact there wasn't a single insult delivered unless you consider someone saying your idea isn't very good to be insulting.

You're right, my terminology was incorrect, confused and confusing. I apologise for inducing such sleepiness and appreciate that you overcame your boredom and torpor to the degree that you were able to reply. I'm not sure what *boogle* means though.

The BSD USL lawsuit was indeed about copyrighted works. So is the SCO action, so while I made a stupid and careless error the broad analogy is still good.

As for successful legal actions against the Linux kernel, here's one (perhaps it's unique, I don't know).

Microsoft recently pursued TomTom over a patent related to using both long and short filenames in FAT filesystems, a technique implemented in the Linux kernel (TomTom devices use the Linux kernel). TomTom caved in before it came to judgement. I'd call that a successful legal action by Microsoft (because the defendant conceded) and I also recall that a patch was forthcoming to replace this technique with another that is not covered by any (known) MS patent. See http://lkml.org/lkml/2009/6/26/313

It does happen. The Linux kernel is no more impervious to legal issues than any other piece of collection of code. The SCO case is ongoing and because I lack prescience I'm reluctant to state that SCO definitely will lose (though I hope they do lose, and lose because their case cannot be substantiated).

The argument "if *BSD ever becomes as popular as Linux is now, it'll have *exactly* the same problem that Linux has now." sounds oddly familiar. My impression is that outside of the consumer/desktop arena the BSDs are widely used and well known. They compete with the same proprietary UNIX systems as do Linux based systems, so this 'below the radar/parapet/insert_car_analogy_here' contention seems invalid.

How much of this is about nudging Linus... pushing him, really... into applying GPL 3 to the Linux kernel?

That can't happen without a rewrite. Too much of Linux is composed of patches written by unreachable authors and whose copyrights haven't been assigned to Mr. Torvalds or the Linux Foundation.

And even then, Mr. Torvalds has stated that he prefers the spirit of GPLv2 to that of GPLv3. I'm pretty sure that the spirit of GPLv2 can be expressed in the GPLv3 framework by adding a set of exceptions, much like the Classpath license and the LGPLv3 are sets of exceptions to GPLv3.

It took you 5 minutes to come up with only 4 examples. And you were specifically LOOKING for such examples.

Here's the Linux Kernel Mailing List. http://lkml.org/ That's a few thousand comments without any sexism at all. It's all about the statistics.

Your post was a perfect example of the problems with this "discussion".

You aren't concerned with the statistics. And with the Internet, it is very easy for a single example of a sexist comment (whether it was intended to be sexist or not) to be shared between the people LOOKING for sexist comments.

Again, if 1.5% of the FOSS developers are women, and only 0.1% of the comments are sexist, what is the REAL problem that you're trying to "solve"?

All this effort is put into chrome polishing the kernel for faster SMP with 64 CPU systems and the dang box can't even play music without having some sort of brain failure.

Check list of Linux kernel contributors to understand why.

Do not know how it is now, but in past one could see lots of ignored/rejected patches on lkml with desktop relevant changes.

Linus Torvalds has, for once, made pretty clear arguments against it. Various philosophical ones etc. but also several solid technical ones

1. it's better to have one tested scheduler
2. since the scheduler can be parametrised there's nothing to stop it scaling
3. "nobody has come close" to providing a pluggable implementation which efficient enough

See this email and this one.

The grandparent's statement that "here are no definitive arguments against having pluggable schedulers" glosses over the fact that Linus' arguments have to be proven wrong. I can believe that in this, like most things, Linus is wrong; however it's experimental science not philosophy. Someone has to write the code.

The scheduler is probably the piece of kernel code which actually does something which gets called most (many times a second even if only user activity is ongoing). A level of inefficiency which would be okay in an IO scheduler which will normally have to wait for a slow disk access just can't be accepted in a process scheduler and even a single level of indirection might really be a killer. Possibly it would be better to have separate kernel builds for small and large installs than having pluggability in which case even CK's new scheduler may not prove the need for pluggable schedulers. Alternatively, maybe pluggability would have to be done with self modifying code which left no indirection in place?

Linus Torvalds has, for once, made pretty clear arguments against it. Various philosophical ones etc. but also several solid technical ones

1. it's better to have one tested scheduler
2. since the scheduler can be parametrised there's nothing to stop it scaling
3. "nobody has come close" to providing a pluggable implementation which efficient enough

See this email and this one.

The grandparent's statement that "here are no definitive arguments against having pluggable schedulers" glosses over the fact that Linus' arguments have to be proven wrong. I can believe that in this, like most things, Linus is wrong; however it's experimental science not philosophy. Someone has to write the code.

The scheduler is probably the piece of kernel code which actually does something which gets called most (many times a second even if only user activity is ongoing). A level of inefficiency which would be okay in an IO scheduler which will normally have to wait for a slow disk access just can't be accepted in a process scheduler and even a single level of indirection might really be a killer. Possibly it would be better to have separate kernel builds for small and large installs than having pluggability in which case even CK's new scheduler may not prove the need for pluggable schedulers. Alternatively, maybe pluggability would have to be done with self modifying code which left no indirection in place?

Yeah, that makes sense, but he seems to have taken it personally. It sounds like part of it stems from his feeling that Molnar unnecessarily wrote a replacement using his ideas and got credit for it, instead of helping out to turn one of Kolivas's fair-scheduling proposals into something that could be merged. Though from what I can tell Molnar's replies are all pretty friendly, and he seemed keen to provide appropriate credit.

The kernel developers enjoy breaking modules that aren't part of the kernel tree just to punish developers who write them; that fact is so obvious that regular contributor Alan Cox dubbed it the war on binary modules and Theodore Tso commented on how they even target open-source solutions with that tactic. I lose a virtualization software package or two quite regularly when trying to upgrade kernels, even when said packages are open-source like Virtualbox (example). The only solution that will work is to push the kernel developers to accept the modules everyone is working on.

I went to read the thread from around the message pointed by the article.

What I saw was a nervous breakdown from Mr. Cox because he had too much pressure on him and wasn't able to accept that his proposal was less optimal than that from others. See: http://lkml.org/lkml/2009/7/28/612

Mr. Cox finally comes to reason: http://lkml.org/lkml/2009/7/29/108

Considering the discussion going on from http://lkml.org/lkml/2009/7/29/276 , maybe Mr. Cox will reconsider.

I don't know about other issues, but I wouldn't be too fast to point the finger at Mr. Torvalds in this case.

I went to read the thread from around the message pointed by the article.

What I saw was a nervous breakdown from Mr. Cox because he had too much pressure on him and wasn't able to accept that his proposal was less optimal than that from others. See: http://lkml.org/lkml/2009/7/28/612

Mr. Cox finally comes to reason: http://lkml.org/lkml/2009/7/29/108

Considering the discussion going on from http://lkml.org/lkml/2009/7/29/276 , maybe Mr. Cox will reconsider.

I don't know about other issues, but I wouldn't be too fast to point the finger at Mr. Torvalds in this case.

I went to read the thread from around the message pointed by the article.

What I saw was a nervous breakdown from Mr. Cox because he had too much pressure on him and wasn't able to accept that his proposal was less optimal than that from others. See: http://lkml.org/lkml/2009/7/28/612

Mr. Cox finally comes to reason: http://lkml.org/lkml/2009/7/29/108

Considering the discussion going on from http://lkml.org/lkml/2009/7/29/276 , maybe Mr. Cox will reconsider.

I don't know about other issues, but I wouldn't be too fast to point the finger at Mr. Torvalds in this case.

After those 2 emails mentioned in the post he has posted various messages today (29th July) . I'm not so sure he has quit just yet,,,

http://lkml.org/lkml/2009/7/29/272
http://lkml.org/lkml/2009/7/29/290