Linus Torvalds won't apply 'sh*t-for-brains stupid patch'

Re: He's right. Again.

Microsoft's problem is that - historically - they've CREATED undocumented internal API's that only they can use which provide things that people want and can't get any other way.

From DR DOS to Windows 3.1, Office to Exchange, they have relied on only THEMSELVES knowing when it's safe to call an internal API that gives them a speed boost or a capability that otherwise wouldn't exist.

They don't document them, but their own software uses it, and uses it to get a performance boost.

Thus when others do use them, and use them slightly unusually, and Microsoft update they break their own software and other people's too.

They're still doing such things, and still have a legacy of everything from undocumented API calls to hidden registry entries, all of them undocumented, necessary to achieve certain things not documented, and all of them needing to be carried forward to future OS and backwards compatibility layers (16-bit, 32-bit, 64-bit so for, not to count platform ports, etc.).

Microsoft cause the mess 9 times out of 10. That people then use it is not surprising if there's no other way of doing things.

Brought to you by the company that STILL does not offer a programmatic, or group-policy, method of changing a user's account picture that doesn't involve creating dozens of PNG files in different sizes and overwriting ones with special names inside local user folders that don't propagate back to the network. Yet though they have exactly that functionality in AD (jpegPhoto pulls down automatically) to fulfill their need in Exchange, it doesn't translate to Windows 8 and above account images that appear on their own login screens (which need a local, resized, specifically-named PNG/JPG put into a special location only created on the local hard disk after a user has logged in).

Re: He's right. Again.

"why should they keep undocumented internal feature x just because ONE 3rdparty program uses it, they are gonna say, please patch your poor excuse for a win32 application."

Quite right too. Do it right in the first place...

Re: He's right. Again.

Drivers should be shipped as source code and built with a compiler at install time.

Yes, but even this would not work in Linux (given current policies), because the driver API is not so stable even at the source level. This is justified by the need to preserve the freedom to change the kernel implementation.

Re: He's right. Again.

"the downside, of course, is that you get to endure Linus' outrages when you are wrong"

The other downside is that it exposes the internal workings of the driver which might then open the vendor to patent trolling,

Re: He's right. Again.

"You must have a short memory. What generally happened was that the unstable branch got dragged out too long and distros/maintainers would then try to backport required changes to the stable kernel resulting in TWO unstable branches. "

It may be short, perhaps people just tend to remember bad experiences more than good ones. I have fond memories of the 2.2.x kernel, for some reason 2.2.19 sticks out as a kernel I ran for a looooong time, and 2.0.36 as well. I remember some special security patch I would apply to my kernels back then as well(forgot the name of it).

But what sticks out more is the memories from about a decade ago(or more) of having to hack together kickstart disks with newer hardware (that CAME WITH DRIVER DISKS FOR REDHAT), but those drivers were not compatible with whatever kernel breed was in the kickstart kernel (the kernels were almost identical, not talking 2.2 to 2.4). Spend so many hours doing that, especially for Intel (or was it Broadcom, or both? I do specifically recall e1000e driver as problematic at the time) network cards (these were HP DL3x0 G3, G4, G5 and G6 servers). Also for one or more SATA controllers. So, it sort of came down to extracting the kickstart disks to find what kernel they are using, find the source for it, and the configuration. Build the kernel so I know it builds, and then compile the drivers against that kernel, re-insert the drivers back into the kickstart data files and try to boot the box(we booted over PXE at the time), and hope it works. I think it was the only time in my life I had to work with CPIO was with those driver modules/disks/files.

That stuck out so much that two years ago when I deployed the first bare metal servers in my data center in 6 years I really feared facing that situation again. Almost all my physical servers run Vmware and the drivers there have been solid as a rock for me at least for the past decade.

I much prefer back ported stuff myself. Most recently on my brand new laptop (Lenovo P50) I installed Linux Mint 17, ran for about a month or so and it was working great. Then I went to travel and that was the first time I tried to use wifi. The kernel with mint originally is 3.13 (or at least that is what my other Laptop with mint has on it right now, in any case a 3.x kernel).

It did not support the intel wifi chip in my laptop. OK so I go around hunting for a driver, totally ready and willing to compile the driver for my kernel. I come across Intel's open source website with their drivers that specifically says something like kernel 4.2 required. WTF ?

ok so I go hunting for a 4.2 kernel, and find that FORTUNATELY at this point the Mint people have included "unofficial" 4.2 kernel as an optional package in their repos (yay). So I install that and wireless starts working (along with the SD card slot which didn't work before). After about a day or so the system freezes and perhaps the caps lock light is flashing (kernel panic). I reboot, and it freezes again maybe a week or so later (not happy that I am on a 3 month trip and this starts happening).

Fortunately even more again Mint folks have a 4.4 kernel in their package repos as well and that resolved the issue, whatever it was that was causing the panics or lockups with 4.2.

Though now (I think even with 4.2) I ran into a problem where the system would just go nuts, so I put in a cron that runs every minute that runs

echo 0 > /sys/kernel/mm/transparent_hugepage/khugepaged/defrag

echo never > /sys/kernel/mm/transparent_hugepage/defrag

echo never > /sys/kernel/mm/transparent_hugepage/enabled

I forgot the background on the issue but that has since resolved it. Just running it once after bootup did not seem to be enough.

I have run across driver issues in linux for a long time of course, but this was my first experience where the driver wouldn't actually work (or so was advertised) unless you were on (what I would consider) a very bleeding edge kernel. This coming from Intel which is a really big company. I would not entirely expect a driver developed on 4.x to work on say 2.6 (though it would be nice), it should of worked on 3.x at the very least if compiled from source.

Now that things seem to be working again hopefully i don't have to touch the kernel for another 3-5 years.

Re: He's right. Again.

I'm one of the people that directly work with Linus. And it's a lie when he says he's "not a nice guy". Because really, he's one of the nicest people I know. The problem is, like many other people I know, when he gets upset, he can act like a jerk. The reason most people tolerate that, is because when he gets upset, you probably did something really stupid. I've only been on his bad side once, and at the end of that conversation, I realized that I was in the wrong.

It makes Linus look much worse that the only times he is in the headlines is when he's giving one of his rants. But that's really 1% of the time. Want to know how the community really is? Back in 1998, I had a thinkpad that Linux wasn't recognizing the floppy for. I posted to the Linux Kernel Mailing List with what I found with my own sloppy debugging, and Linus himself replied back to me. He worked with me for several hours to help me get my floppy drive working. And I wasn't a one off. Linus and other top kernel developers have spent lots of time helping people get their kernels working. That is what got me hooked to kernel development.

Re: He's right. Again.

"And Linux is MORE stable than Windows "

That's not my experience. Especially where drivers are concerned...Can't remember the last time I saw a Windows server actually crash or hang. Whereas having to reboot Linux boxes with frozen consoles, memory leaks or because of hung / crashed / ghost processes is commonplace.

@hans

". I know, sounds "normal" to you, maybe because you use Windows and are fine with using other computers to download ethernet/wifi drivers "

Don't think I've done that since early XP.

Updated ones, yes, but working ones? Nope.

Re: He's right. Again.

"Oh this is hilarious. But not in a good way"

Exactly what I thought when I realised you didn't understand what you are talking about.

"So over time Gates forced changes towards the monolithic approach, e.g. moving assorted drivers and subsystems into the kernel"

No, they never did that. The Windows microkernel remains micro. Microsoft made design decisions to RUN certain drivers in kernel space rather than user space, but that's very different from actually building them into the kernel at compile time...Windows has the flexibility to offer both driver user space and kernel space driver options whilst remaining fully modular...

Linux by the way also implements many drivers in kernel mode...