Slashdot Mirror

FTDI tried to also get the "brick-patch" to Linux, but Greg Kroah-Hartman blocked it with this response:

Funny patch, you should have saved it for April 1, otherwise people might have actually taken this seriously :)

Patches as performance art, now I've seen everything...

greg k-h

Don't worry, similar driver modification was proposed for inclusion – https://lkml.org/lkml/2014/10/... . But Linux maintainers didn't took it. Instead, original driver was adjusted to work with FTDIs ”bricked” by Windows driver: http://marc.info/?l=linux-usb&...

Linux is not fun anymore.

They tried to get it into the linux kernel today:

https://lkml.org/lkml/2014/10/...

I was looking to improve some I/O performance by using aligned buffers and O_DIRECT and ran across this tirade from Torvalds:

https://lkml.org/lkml/2002/5/1...

"The thing that has always disturbed me about O_DIRECT is that the whole
interface is just stupid, and was probably designed by a deranged monkey
on some serious mind-controlling substances"

> http://www.phoronix.com/

Please don't link to Phoronix garbage -- all they care about is linking to themselves instead of actually linking to the source
i.e.

* https://lkml.org/lkml/2010/9/1... Linux 2.6.36-rc4
* https://lkml.org/lkml/2010/9/2... Linux 2.6.36-rc5 <-- alpha: fix a 14 years old bug in sigreturn tracing

> http://www.phoronix.com/

Please don't link to Phoronix garbage -- all they care about is linking to themselves instead of actually linking to the source
i.e.

* https://lkml.org/lkml/2010/9/1... Linux 2.6.36-rc4
* https://lkml.org/lkml/2010/9/2... Linux 2.6.36-rc5 <-- alpha: fix a 14 years old bug in sigreturn tracing

Who is "Debian leadership"? The DLP? The FTP-masters? the Release team? the individual maintainers? the Pope? You are quoting (or are you Gregory Smith or whatever alias?) https://lkml.org/lkml/2014/10/... which in is complete non-sense. Nobody has decided anything, systemd-shim is still in the archive at this point.

People in charge of naming picked "Linux 3.16" as you can see in official announcement.

Shuffling Zombie Juror is internal codename, which is only public because the source code is public - it's not in the announcement, it's not on the boot screen, it won't be on any product box. It's only there in the source.

If you'd google for this codename (which doesn't work as a name, as it can refer to either 3.14, 3.15 and 3.16) you'd see it's only used in rare instances on geek sites. Most instances are actually copies of this article snarfed by various blogspamish aggregators. Headlines and most sites properly refer to them as "Linux 3.14" etc.

I also like your image of "people in technology" who accidentally discover that the kernel they knew as Linux 3.14 is codenamed SZJ in the source and run away - because who cares about features, stability and track record, omg that (code)name is sooo dumb!

PS: "Children". Keeping it classy, eh? Your bias isn't showing at all.

GPLv2 is purely about code openness and code contribution but not about FSF ideals.

Not according to the people who actually WROTE the GPLv2. You made a good point about *some* of the people who chose to use it, but that is not what the GPLv2 was written FOR.

No I said that in this context the use of the GPLv2 is purely about code openness and code contribution but not about FSF ideals, obviously by "this context" I mean Tivo and who used Linux and thus the one using the GPLv2 is Linus. What the authors of the GPL intended is irrelevant, the only thing that matters is what they actually wrote.

Moreover on your request for specific examples of Linus endorsing Tivoization:
"I think Tivoization is *good*."
"What Tivo did is *good* in my opinion!"

It doesn't get much more unequivocal than that, he does actively approve of Tivoization.

This is about the 99.99% of people who use Tivo code, use it on a Tivo, and as a result they are denied the particular freedoms the original authors of the code it is licensed under intended for them to have.

Wrong, you simply do not understand the license and are implying things that are not there. It has been made very clear multiple times, here is just one example, that the use of the GPLv2 is purely about code openness and code contribution but not about FSF ideals.

If you believe otherwise then demonstrate where the original Linux kernel author actively intended the recipients of the code to have the freedoms that are not granted by the GPLv2, but you won't because Linus never intended that, it's yet another false inference you are making.

Absolutlely not an outcome the authors of the license wanted.

The authors of code that use it.

i mean if you want that, then use the BSD or something.

So not only do you not understand the GPL license but you also don't understand the BSD license. The BSD license does not require code contributions back, it does not require you to release your modifications like the GPL does. That is why the GPL was chosen over the BSD for the Linux kernel.

What realistic scenario can you put forth where the developer actively wants to license their code under the GPL and simultaneously doesn't want people to be able to modify the code they received to run on on the equipment the code is installed on?

The Linux kernel! Explicitly does not care about FSF freedom ideals and only cares about the code, that's why they use the GPLv2 and why the GPLv3 is incompatible with the ideals of the kernel developers.

By "Linux" I assume you mean Linus? And while its clear he disagrees with the FSF on some key points, you'd be hard pressed to demonstrate that he actively approves of Tivoization.

Tivoization is fine according to Linus because it is about source code and not anything else:
I personally have always been very clear about this: Linux is "Open Source". It was never a FSF project, and it was always about giving source code back and keeping it open, not about anything else.

https://lkml.org/lkml/1998/9/3... [lkml.org] I don't know what else to tell you. They really do suck. Trap-gates are faster and safer. Call-gates are... prettier, more elegant.

Have a look at Linux 2.0 implementation. You'lll see an interrupt handler copying registers to the stack, and *then* invoking the call gate. So basically, doubling the work. And no, interrupts are not safer, as they don't provide stack isolation. This is done *manually* in the Linux implementation.

It's probably much a much narrower/null lead these days with massive caches, but back in 98, it was serious business.

I seriously doubt that. I was working extensively with x86 assembly in 98, and actually implemented call-gate systems in some of my pet projects. Granted, they were pet projects, not a mainstream piece of OSS, but I don't share that experience.

he various kernel mailing lists are abound with discussions on people wanting to try out call-gates, and finding out that *they suck*.

AFAIK, the implementation 2.0/2.2 still uses a call gate. Not directly, but inside the IV.

Also, SYSENTER wasn't switched to until we ran into the P4's massive pipeline stall on trap-gates, which the AMD K6 did *not* exhibit. It wasn't a fundamental problem with the trap-gate itself, but a quirk of the Netburst architecture.

It is a fundamental problem with the trap gate. The pipeline size and the agressive branch prediction mechanism only made it worse. Shorter pipelines don't suffer as much, as they are faster to clean and less prone to stupid execution stalls. Also, there was a huge amount of optimization done on silicon for this since 32 bit operating systems using interrupts became mainstream, and the same can't be said for the architecturally complex call-gate solution. SYSENTER simplifies a lot, but performs basically the same task as a call gate.

The fact that the unices/dos used entry 0x80 in the IDT, and NT used 0x2e, and 95 used 0x30, with call-gates to VxD code (eventually gotten rid of) doesn't mean the methodology of the trap was what was inherited

Actually, the fact that many other architectures do not provide any other user-defined global entry point besides the interrupt table has a huge weight in it; I don't see any problem with the metodology, if you're implementing a portable system. I see problems with a specific implementation of it on an operating system designed from the ground up for x86, and one of those problems is that whoever implemented it clearly had no clue about how it worked.

Sigh.

https://lkml.org/lkml/1998/9/3...

I don't know what else to tell you. They really do suck. Trap-gates are faster and safer. Call-gates are... prettier, more elegant. It's probably much a much narrower/null lead these days with massive caches, but back in 98, it was serious business. The various kernel mailing lists are abound with discussions on people wanting to try out call-gates, and finding out that *they suck*. It had nothing to do with portability.

Hell, today's SYSENTER mechanism isn't remotely portable.

Also, SYSENTER wasn't switched to until we ran into the P4's massive pipeline stall on trap-gates, which the AMD K6 did *not* exhibit. It wasn't a fundamental problem with the trap-gate itself, but a quirk of the Netburst architecture.

Whether you're grabbing privilege descriptors on from the IDT or the GDT/LDT, it's the same amount of work. One has smaller instructions and less bouncing around in memory. That's it. The fact that the unices/dos used entry 0x80 in the IDT, and NT used 0x2e, and 95 used 0x30, with call-gates to VxD code (eventually gotten rid of) doesn't mean the methodology of the trap was what was inherited. Just the number. The methodology was used because it was sound, and the sanest.

I was not confusing the two. AFAIK we do have truly "random" sources, and thats what I was referring to.

I was also referring to the fact that the linux RNG uses multiple entropy sources-- including intel RdRand-- in order to address issues in any one of them. Theres a write-up here which indicates you CAN mix sources without losing entropy:
https://lkml.org/lkml/2013/9/1...

More simply, if you XOR truly random source A with compromised source B to get seed C, an attacker could know all of the output of B, but he would have no way of determining A or C-- he literally has no additional information. This is pretty trivially proveable, and if it were not true stream ciphers simply would not work (One of the values is known, but the other two cannot be determined).

I think you are confused; just because a couple of pages are dual mapped doesn't make the virtual address spaces *not* disjoint.

https://lkml.org/lkml/2003/7/1...

"Or any later version".

No, this was addressed years ago when the GPLv3 draft was first released:

The "version 2 of the License, or (at your option) any later version" language in the GPL copying file is not - and has never been - part of the actual License itself. It's part of the _explanatory_ text that talks about how to apply the license to your program, and it says that _if_ you want to accept any later versions of the GPL, you can state so in your source code.

The Linux kernel has never stated that in general. Some authors have chosen to use the suggested FSF boilerplate (including the "any later version" language), but the kernel in general never has.
http://lkml.org/lkml/2006/1/25/273

Torvalds has said in the past something about that he doesn't want to associate with "free software" (or at least FSF) types because they're so "extreme" or such (can't find a link sorry).

This probably isn't the link that you were referring to but in the discussion around GPLv3 he does mention that Linux has always been Open Source as opposed to Free Software and the FSF evangelizing Linux as a free software project is not something he advocates.

Has the "(2 < 2) is true" bug been fixed ?

The Linux kernel is stuck on the GNU v2 license for exactly this reason, and can never change. That's the fate of any such non-CLA'd Open Source project (other than something using Public Domain or the BSD license).

Actually no, the Linux kernel is stuck on the GNU GPL v2 because Linus made that decision on purpose. The default GNU license allows for relicencing under any later version, but Linux removed that clause on purpose.

Here's his rant against GPLv3: https://lkml.org/lkml/2006/9/2...

You can try a google search on site:lkml.org sha collision.

The GP might be talking about this.

I'm sure Linus also knows at least some Finnish, and particularly Finnish curses. The phrase in question is taken directly from a (by-now famous) LKML posting he made, in which he used it because "[t]here aren't enough swear-words in the English language" to express his "disgust and frustration" with a particular patch.

I don't claim to be as much an expert on Windows 7 as I am on Linux and perhaps XP, but the only additional security that I understand Windows 7 has but XP doesn't is the UAC stuff - and that's primarily there to stop idiots who are logged in with administrator privileges not allowing everything to run that asks to run.

TO some degree, thats right, but it does a lot more than "stopping idiots". I tried running as non-admin, and I tried setting it up for many users, but the reality was that many programs simply would not work without admin privileges, and it was a nightmare to configure and work with. Runas only worked some of the time, some programs inexplicably refused to run if they failed the admin check, there was no real capability of modifying protected files while logged in as a normal user (as you cannot easily / without hacks do a "runas" on explorer.exe), etc etc etc.

UAC allowed non-admin logins to actually be feasible for 99% of users. It also introduced the idea of truly gaining and dropping privileges on the fly, rather than the binary "either you are or arent an admin".

And please define what you mean by "EOL'd" when applied to Linux 2.4?

I simply went to the Linux Kernel wikipedia page, which noted that 2.4.37.11 was released in 2010, and it stopped being maintained in December 2011. The official announcement is here:
https://lkml.org/lkml/2010/12/18/73

and any vulnerabilities in it can be mitigated through backporting of existing patches or other external mitigation

The term EOL refers to when it no longer has support. Attempting to backport patches to a kernel that hasnt been supported in 2 years sounds rather daunting and ill-advised. Running 2.4 in production on anything that is not heavily resource constrained boggles the mind, honestly. Even newer DD-WRT builds are using 2.6, and they generally have under 64MB of RAM and processors clocked under 500mHz.

not least to fix the vulnerability yourself.

Are you aware of how time-intensive a job like that would be for something as simple as Firefox, let alone the monstrosity that is Linux? How many lines of code are we dealing with here? Ever heard the term "regression"?

If you want to be the one to explain to your boss how your backported patch caused all sorts of unexpected fun, and there are no companies who can provide anything resembling support because of that backport, go ahead. EOL is EOL, and theres a reason people stay away from it.

Signed binaries running from a signed kernel, booted on UEFI Secure Boot hardware you can't legally compromise.

Alan Cox explained this 12 years ago.

That is the dream these people have.

It's true. Linus has been quite vocal about whose fault it is when a kernel change breaks an application...

I'm very familiar with the disagreement between Linus and Mauro. Mauro messed up. When Linus called him out on it, Mauro claimed that it was the userspace application's fault (!!!). A livid Linus told him to shut up and follow the rules (don't break userspace!). Then this exchange continued a little more. Mauro is an example of a developer who pushes back against the rules even though he's been in the game long enough to know not to. Swearing at Mauro is one thing, I think Linus should have considered ignoring Mauro's contributions as he has demonstrated a clear lack of judgment.

If Linus wouldn't have been very clear with his frustration, how much longer would that exchange have been?

Here's the exchange: https://lkml.org/lkml/2012/12/23/48

Unless you are involved with the kernel, I would suggest that you would hold your judgment.

Linus does not blow up without good reason. I challenge anyone to find example where Linus starts to really attack people when they are not doing something clearly stupid, that would result for not accepting patches if not solved (like breaking userspace and refusing to admit that it's error to do so). https://lkml.org/lkml/2013/7/16/565 I have been reading and contributing to the kernel and I think Linus uses cursing people as very effective way to emphasize the urgency and his seriousness of how badly some maintainer is fucking things up (hurting feelings really helps to save time when people don't get the message). He makes misjudgments and there are sometimes miscommunication, but he acknowledges them openly.

One thing that separates Linux kernel development from other software projects I have worked with is that there are no grudges. When there is serious disagreement with Linus, there is one huge flame and the issue is settled in one way or another. After that he continues with that person just like before. There are some really difficult persons to work with, like glibc maintainer Ulrich Drepper and I would say that Richard Stallman is also much harder to work with than Linus.

I don't advocate cursing people as general way to handle things, but I think that Linus has personality that makes it work. The problem is that if people just think there is some general lesson to be learned from his behavior that can be applied to others.

I think he makes very good point at justifying himself:

"I really fundamentally believe that being honest and open about your emotions about core/process is good. And because it's damn hard to read people over email, I think you need to be *more* honest and *more* open over email. I'm generally nicer in person. Not always."

1. https://lkml.org/lkml/2013/7/15/407
2. https://lkml.org/lkml/2013/7/15/446
3. https://lkml.org/lkml/2013/7/15/547
4. https://lkml.org/lkml/2013/7/15/547

Unless you are involved with the kernel, I would suggest that you would hold your judgment.

Linus does not blow up without good reason. I challenge anyone to find example where Linus starts to really attack people when they are not doing something clearly stupid, that would result for not accepting patches if not solved (like breaking userspace and refusing to admit that it's error to do so). https://lkml.org/lkml/2013/7/16/565 I have been reading and contributing to the kernel and I think Linus uses cursing people as very effective way to emphasize the urgency and his seriousness of how badly some maintainer is fucking things up (hurting feelings really helps to save time when people don't get the message). He makes misjudgments and there are sometimes miscommunication, but he acknowledges them openly.

One thing that separates Linux kernel development from other software projects I have worked with is that there are no grudges. When there is serious disagreement with Linus, there is one huge flame and the issue is settled in one way or another. After that he continues with that person just like before. There are some really difficult persons to work with, like glibc maintainer Ulrich Drepper and I would say that Richard Stallman is also much harder to work with than Linus.

I don't advocate cursing people as general way to handle things, but I think that Linus has personality that makes it work. The problem is that if people just think there is some general lesson to be learned from his behavior that can be applied to others.

I think he makes very good point at justifying himself:

"I really fundamentally believe that being honest and open about your emotions about core/process is good. And because it's damn hard to read people over email, I think you need to be *more* honest and *more* open over email. I'm generally nicer in person. Not always."

1. https://lkml.org/lkml/2013/7/15/407
2. https://lkml.org/lkml/2013/7/15/446
3. https://lkml.org/lkml/2013/7/15/547
4. https://lkml.org/lkml/2013/7/15/547

Unless you are involved with the kernel, I would suggest that you would hold your judgment.

Linus does not blow up without good reason. I challenge anyone to find example where Linus starts to really attack people when they are not doing something clearly stupid, that would result for not accepting patches if not solved (like breaking userspace and refusing to admit that it's error to do so). https://lkml.org/lkml/2013/7/16/565 I have been reading and contributing to the kernel and I think Linus uses cursing people as very effective way to emphasize the urgency and his seriousness of how badly some maintainer is fucking things up (hurting feelings really helps to save time when people don't get the message). He makes misjudgments and there are sometimes miscommunication, but he acknowledges them openly.

One thing that separates Linux kernel development from other software projects I have worked with is that there are no grudges. When there is serious disagreement with Linus, there is one huge flame and the issue is settled in one way or another. After that he continues with that person just like before. There are some really difficult persons to work with, like glibc maintainer Ulrich Drepper and I would say that Richard Stallman is also much harder to work with than Linus.

I don't advocate cursing people as general way to handle things, but I think that Linus has personality that makes it work. The problem is that if people just think there is some general lesson to be learned from his behavior that can be applied to others.

I think he makes very good point at justifying himself:

"I really fundamentally believe that being honest and open about your emotions about core/process is good. And because it's damn hard to read people over email, I think you need to be *more* honest and *more* open over email. I'm generally nicer in person. Not always."

1. https://lkml.org/lkml/2013/7/15/407
2. https://lkml.org/lkml/2013/7/15/446
3. https://lkml.org/lkml/2013/7/15/547
4. https://lkml.org/lkml/2013/7/15/547

Unless you are involved with the kernel, I would suggest that you would hold your judgment.

Linus does not blow up without good reason. I challenge anyone to find example where Linus starts to really attack people when they are not doing something clearly stupid, that would result for not accepting patches if not solved (like breaking userspace and refusing to admit that it's error to do so). https://lkml.org/lkml/2013/7/16/565 I have been reading and contributing to the kernel and I think Linus uses cursing people as very effective way to emphasize the urgency and his seriousness of how badly some maintainer is fucking things up (hurting feelings really helps to save time when people don't get the message). He makes misjudgments and there are sometimes miscommunication, but he acknowledges them openly.

One thing that separates Linux kernel development from other software projects I have worked with is that there are no grudges. When there is serious disagreement with Linus, there is one huge flame and the issue is settled in one way or another. After that he continues with that person just like before. There are some really difficult persons to work with, like glibc maintainer Ulrich Drepper and I would say that Richard Stallman is also much harder to work with than Linus.

I don't advocate cursing people as general way to handle things, but I think that Linus has personality that makes it work. The problem is that if people just think there is some general lesson to be learned from his behavior that can be applied to others.

I think he makes very good point at justifying himself:

"I really fundamentally believe that being honest and open about your emotions about core/process is good. And because it's damn hard to read people over email, I think you need to be *more* honest and *more* open over email. I'm generally nicer in person. Not always."

1. https://lkml.org/lkml/2013/7/15/407
2. https://lkml.org/lkml/2013/7/15/446
3. https://lkml.org/lkml/2013/7/15/547
4. https://lkml.org/lkml/2013/7/15/547

Unless you are involved with the kernel, I would suggest that you would hold your judgment.

Linus does not blow up without good reason. I challenge anyone to find example where Linus starts to really attack people when they are not doing something clearly stupid, that would result for not accepting patches if not solved (like breaking userspace and refusing to admit that it's error to do so). https://lkml.org/lkml/2013/7/16/565 I have been reading and contributing to the kernel and I think Linus uses cursing people as very effective way to emphasize the urgency and his seriousness of how badly some maintainer is fucking things up (hurting feelings really helps to save time when people don't get the message). He makes misjudgments and there are sometimes miscommunication, but he acknowledges them openly.

One thing that separates Linux kernel development from other software projects I have worked with is that there are no grudges. When there is serious disagreement with Linus, there is one huge flame and the issue is settled in one way or another. After that he continues with that person just like before. There are some really difficult persons to work with, like glibc maintainer Ulrich Drepper and I would say that Richard Stallman is also much harder to work with than Linus.

I don't advocate cursing people as general way to handle things, but I think that Linus has personality that makes it work. The problem is that if people just think there is some general lesson to be learned from his behavior that can be applied to others.

I think he makes very good point at justifying himself:

"I really fundamentally believe that being honest and open about your emotions about core/process is good. And because it's damn hard to read people over email, I think you need to be *more* honest and *more* open over email. I'm generally nicer in person. Not always."

1. https://lkml.org/lkml/2013/7/15/407
2. https://lkml.org/lkml/2013/7/15/446
3. https://lkml.org/lkml/2013/7/15/547
4. https://lkml.org/lkml/2013/7/15/547

Speaking of the swearing capabilities of the English language, this particular porcelain-contained weather anomaly actually originated with Linus having to revert to Finnish when trying to find a powerful enough curse to suit the particular level of stupidity in the transgression being addressed at the time:

https://lkml.org/lkml/2013/7/13/132

And because you were about to ask, "perkeleen vittupää" as an idiom translates to "you fucking idiot", while a more literal translation would be: "In the name of the overgod, you are a cunthead". Finnish is kind of expressive in that particular area :-)

There's a difference between being blunt and being abusive. "This is bad, change it" is not abusive. This, however, is: https://lkml.org/lkml/2013/7/13/132

Actually. I posted a support-style stupid question on LKML once, and got nothing but polite replies. Stupid question, but still: https://lkml.org/lkml/2005/8/17/108

Here is the mailing list thread: https://lkml.org/lkml/2003/1/12/126 Good reading

Maybe this article will clarify some of the difficulties with ARM SoC's:

https://lkml.org/lkml/2013/5/5/35

Now, keep in mind that with every kernel update, some internals change which can lead to the need to completely change the way a driver works. Added to that, many of the SoC drivers are maintained by the particular project using the SoC, not the mainstream kernel for a variety of reasons (some including not being allowed to distribute source). As you can imagine, it's a lot of work keeping up with a moving target like the Linux kernel...

Now, that said, having the latest kernel is very often not needed for a device like this. This is why we very often see that a project stabilizes around an 'older' kernel, but this has very little impact on the user space. In fact, going with a newer kernel often means losing capabilities that were present in older versions.

Heck, in this circumstance Linux is worse than Microsoft - we all know what response you get from the OpenSource community if your app gets broken by some upgrade - "Just recompile it".

I have no idea what you're talking about. I'm used to a different response when it comes to usermode/userspace applications breaking due to Linux changes.

Since the creator has declared his willingness to break things in a backwards incompatible way, that's enough for me to stay away from the language. Check here for further perspective.

Another example is the Berkeley socket API: it's an ugly, miserable thing to use, but I feel confident that code I write for it will still work in ten years. So I encapsulate the ugliness into some functions, and use it.

Maybe not "idiot", but certainly not anything nice: https://lkml.org/lkml/2012/10/2/303

I'm just wondering why you think Red Hat wants to kill open source?

Two words. Lennart Poettering.

See also systemd and pulseaudio. Or better yet, ask Linus himself.

I think Lennart Poettering's work on PulseAudio and Systemd is superb. PulsAudio just plain works; sound has never been so easy and flexible in Linux.
Sys V /init can't die fast enough in my opinion. Fedora, Ubuntu, OpenSuse, Arch Linux and many lesser distroes, have all ditched it in favour of modern solutions.

Claiming that Red Hat want to kill Open Source is just plain pathetic. RH is _THE_ major contributor to Linux, both with their own projects and up stream contributions. They have always been unwavering staunch in their belief and support of Open Source.

I'm just wondering why you think Red Hat wants to kill open source?

Two words. Lennart Poettering.

See also systemd and pulseaudio. Or better yet, ask Linus himself.

Didn't Alan Cox quit once before after Linus flamed him on the mailing list?

https://lkml.org/lkml/2009/7/28/375

Why and when did he come back?

A vuln that apparently was first reported in August 2012 is finally fixed (maybe) in January 2013.

.

Why can't the larger companies, e.g. Microsoft and Oracle, respond to and fix the sucrity issues more quickly than on a timeline expressed in months?

Because they need this guy in charge.

"With respect, where is there an production example of a microkernel that "won"?"

http://www.qnx.com/developers/docs/6.3.2/neutrino/sys_arch/kernel.html
http://en.wikipedia.org/wiki/QNX
http://www.qnx.com/company/customer_stories/

QNX was initially released around 1982 and so existed about the IBM PC PC-DOS was released. QNX was far superior and ran on PC hardware. The only reason it did not win "hearts and minds" was marketing and business relationships. Back then in the 1980s, with QNX, you could easily network a bunch of IBM PCs and run arbitrary processes anywhere on the network.

In general, the message passing idea is much deeper than a "kernel" though. Smalltalk is a great example of it. So is Erlang:
http://en.wikipedia.org/wiki/Erlang_(programming_language)#Distribution

"Linus is being critical but there's no threat of kicking someone off the development team."

Well, I guess different people can read Linus' strong language in different ways:
https://lkml.org/lkml/2012/12/23/75
"Mauro, SHUT THE FUCK UP!"

You can swat a mule on the butt with a two-by-four-inch board and maybe that will get it moving (though the mule might kick you in the head first), but if you do the same thing to a cat you might kill it. So, people can argue for strong invective as being appropriate sometimes, but clearly it is also inappropriate sometimes. Was it appropriate here? Is a kernel software developer more like a mule or a cat? Well, whether the language was appropriate or not, if you believe the kernel maintainers and patch submitters replies, there seems to have been more going on there than Linus seemed to have understood when Linus started using strong language. That seems problematical -- especially, if one could read Linus' strong language as not only saying this kernel maintainers role was in jeopardy but that, likely by extension, his entire career could be in jeopardy? There is a lot more potential stuff going on here when Linus flames someone to such a degree. The kernel is not just a typical FOSS project, and I'd guess this maintainer is likely a paid employee somewhere. I also tend to agree with other posters who suggest that such language, in response to a maintainer asking a question, is not going to cultivate a question asking culture, and ultimately that is going to pose a greater difficulty to the Linux kernel then a bad patch in an experimental kernel that was quickly reverted.

Again, whether using a 2X4 to get someone's attention was appropriate or not in this case, the deeper issue may also be that the strong emotions expressed by Linus may reflect a fundamental problematical issue in the Linux kernel architecture and development processes. Why does Linus have to be so afraid of so many continually needed patches breaking the system in a hard-to-understand and test way? At some point, it may be reasonable to say that what *most* users need is not a 20% or whatever performance improvement by a monolithic kernel but instead maybe what they would be better off with is a microkernel that supports easier upgrades, improved reliability, easier portability, and thus helps software developers to do new things with less effort and higher quality. And as QNX demonstrated in the 1980s, being able to do easy parallel processing across a network of thousands or millions of processors exchanging messages may be ultimately a much bigger performance boost than, say, a few percent greater performance on one processor. That is the promise of "message passing" whether implemented in a microkernel or not.

See this talk by Alan Kay for more on message passing:
htt

After reading Mauro's grovelling post Linus extremely nasty email, my respect for Alan Cox has increased - https://lkml.org/lkml/2009/7/28/375

From what I can tell, the patch was intended to change the behavior userspace sees from the driver, so it wasn't immediately clear whether this was an intentional change or not. More importantly, it also wasn't clear whether other drivers which Mauro was also responsible for maintaining also behaved in the same way. Mauro provides some context here - basically there are a whole bunch of different webcam drivers which each implement the V4L2 API slightly differently, which means that often applications only work properly with certain webcams. The patch was part of an attempt to clean this up. Linus seems to think that any change to userspace APIs that might break existing applications is wrong and fixing up compatibility is no excuse, so it looks like webcams will remain a mess on Linux for a while...

https://lkml.org/lkml/2012/12/21/430

Linus

(*) And by "us" I mean mainly people in the same timezone and hemisphere as I am. Because I'm too self-centered to care about anybody else.

But more importantly ... I always thought that patches to the Linux kernel have to be signed-off and approved before they can be committed. And I always thought that for the latest kernel that person is ... the benevolent dictator. Linus himself.

So how come this slipped by him? Why wasn't this caught before it even became an issue?

AC, thanks for the link. This post by Laurent Pinchart explains further: https://lkml.org/lkml/2012/12/23/89
"The patch uses the -ENOENT error code internally in the uvcvideo driver to inform the caller function (internal to the driver) that the requested control doesn't exist. It was never meant to be returned out of the driver, and definitely not to userspace. This is clearly a bug."

From reading that, it does seem like, as you suggest, Linus may have jumped to an incorrect conclusion about that error code (intended to indicate a bad path) and why it was in the code. However, he or someone else might have instead, with a more complete understanding of the history of the patch, then reasonably questioned the design choice of reusing that error to mean something a bit different internally, precisely because this sort of problem could (and did) arise.

Of course, if one starts asking questions, then issues like having cryptic error codes is another deeper issue.

Although then one could take that all the way back to even deeper design issues, like how a message passing approach like Smalltalk, Actor, and Erlang pioneered may be better for the kernel of software for the 21st century?

So, "crap" is perhaps relative to your frame of reference? :-)

Anyway, it looks to me like there were mistakes made all around -- the patch developer, the kernel maintainer, and Linus. And that does not include all the other decisions by many other people who lead up to this. See also: http://books.google.com/books/about/The_Berenstain_Bears_and_the_Blame_Game.html?id=p8oMWMMdU2gC

Ultimately, a big piece of software is more a community than anything else. I don't know enough about the norms of the Linux kernel community to know what was appropriate in that context.

At first, anyways. If you check:

https://lkml.org/lkml/2012/12/24/125

He basically goes on to agree with most of Linus' points after a few back-and-forths. He was apparently trying to make certain error messages more uniform, which certain higher level pieces of software didn't appreciate.

Those idiots are still giving us all grief. Can't we just kick these guys and they're half-assed project to the curb? Systemd was a good idea, but shit implementation and zero admin love. Hell, they are actively admin hostile! Now they plan to Fuck up udev? great.

They didn't just plan it, they DID it.

Linus was on a roll. Read the whole thread:

Stop this crazy. FIX UDEV ALREADY, DAMMIT.

Who maintains udev these days? Is it Lennart/Kai, as part of systemd?

Lennart/Kai, fix the udev regression already. Lennart was the one who
brought up kernel ABI regressions at some conference, and if you now
you have the *gall* to break udev in an incompatible manner that
requires basically impossible kernel changes for the kernel to "fix"
the udev interface, I don't know what to say.

"Two-faced lying weasel" would be the most polite thing I could say.
But it almost certainly will involve a lot of cursing.

...

The fact is, udev made new - and insane - rules that are simply
*invalid*. Modern udev is broken, and needs to be fixed.

Stop this idiocy.

The kernel doesn't have a lockup problem. udev does.

Yeah, that bugzilla shows the problem with Kay as a maintainer too,
not willing to own up to problems he caused.

and

So now, after you've dismissed the patch that did the equivalent fix
in udev (Ming Lei's patch basically disabled your idiotic and wrong
sequence number test for firmware loading), you say it's ok to bypass
udev entirely, because that is "more robust".

Kay, you are so full of sh*t that it's not funny. You're refusing to
acknowledge your bugs, you refuse to fix them even when a patch is
sent to you, and then you make excuses for the fact that we have to
work around *your* bugs, and say that we should have done so from the
very beginning.

Is Kay Sievers really that dumb?

This is a very different case than Oracle v Google. Google was distributing their own implementation of the Java API, without using Oracle's code. Here, however, RTS is shipping a copy of the Linux kernel. Their defense seems to be that they are somehow exempt from the requirements under GPLv2 because they ship their modifications as a module, but I'm a bit skeptical whether this would actually hold up in court.

Seems like not all the code is theirs afterall..

https://lkml.org/lkml/2012/11/8/456

Second, you claim you hold exclusive copyright for the code. Not true. One example: on http://www.risingtidesystems.com/storage.html you claim
support for FCoE. You didn't build tcm_fc, Intel did. Under the GPLv2. Furthermore, SRP support came from SCST, iirc. None of these contributors gave RTS any right to use their copyrighted code except under the conditions of the GPLv2.