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

Add another Linus Torvalds swearing incident to his long list of linguistic indiscretions. The Linux lord has unloaded on proposed new code in typically robust language. “I call BS”, Torvalds' post opens. “Let me be very clear. I'm not applying that shit-for-brains stupid patch, and will not be pulling it unless somebody …

Silver badge

He's right. Again.

Some people will be offended by his bluntness, but stop for a moment to consider how offended he is by a developer trying to push a bad idea in to the kernel.

He is doing what Microsoft should've done with Windows years ago and prevent hack jobs from entering in to the code, which are then built upon in later updates, which then can't be removed without massive re-writes to all of the code that relies on it.

104
4

Re: He's right. Again.

It's easy to say, but Microsoft gets blamed if a popular application doesn't work on a new version of Windows, even if the fault is that dev hooked into and relied on a non-documented internal feature that no longer exists in the new OS. Microsoft can either let the application or driver crash for users and invariably take blame and media reports of the new OS being unstable, or they can write a hack specific to that application or driver to make it work.

21
20
Silver badge

Re: He's right. Again.

As a linux user since 1996(desktop and server), I can say drivers on linux have been almost nothing but hack jobs the whole time. Linux driver ABI is always changing and breaking shit.

I gave up on hoping they would stablize to some degree about 10 or 11 years ago but is still sad to see. Just have to look at how many dozens if not hundreds of kernel combinations for example that vmware tools distributes drivers to see how bad it is. Looking myself I see two hundred and ninety three different kernel drivers. (And yes of course there is source code too).

I think the issue has hurt android as well making it more difficult for manufacturers to upgrade drivers for newer kernels.

Linus won't fix it. I got over it a long time ago. But kind of funny to see him complain about that kind of thing when drivers on linux have been broken forever.

The linux kernel devs like to say just release the source. Yeah like that magically solves all problems.

I stopped paying close attention to the kernel when they abandoned the "stable" and "testing" branches, what was it the 2.4 days ? Before that it was say 2.0.x for stable, and 2.1.x for testing/dev, then 2.2 was stable, etc..

bring on the downvotes, totally expected that from the fan boys.

43
36
Silver badge
Flame

Re: drivers on linux have been almost nothing but hack jobs the whole time

BURN THE HERETIC!!!!!

26
2
Silver badge
Windows

Re: He's right. Again.

>Microsoft can either let the application or driver crash for users and invariably take blame and media reports of the new OS being unstable, or they can write a hack specific to that application or driver to make it work.

Are you nuts, they do not give a rats a$$ and MS are right on this one, 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.

The problem they do have is that they have been relying on a monolithic system since day 1 and now that it has become a behemoth, they have many kinds of problems. Pulling out the ui, for example, has taken several years, and if you look at server nano, for example, with its 9Gb hd footprint, you can tell that they did not "really" remove the ui, they have simply hidden it ... Windows Me and MS DOS anyone ? Ok, this time better than before, still, a lot of ui-centric DLL's are still there ... just saying.

Windows Update is a disaster, when you install an OS, say Windows 7 SP1, for example, it will pull ALL patches ever released post SP1 from the interwebs... so it will patch iexplore.exe ~96+ times, instead of simply downloading and installing the latest. Why, are you gonna ask ? I am not quite sure ... they are Microsoft for a reason™.

18
12
Silver badge

Re: He's right. Again.

He's right, again? Perhaps only because he's stopped Linux drivers getting a little bit worse than they already are. But by making a version of a device's firmware get compiled in with the device driver in the kernel you're linking firmware version to the kernel version. Not too clever.

He's got to make an effort to make Linux drivers more modular and bring driver and associated firmware out of the kernel. Linus said once he wanted to kill all ARM engineers or something similar, I suppose the feeling is mutual with the huge ever-growing list of compiled-in kernel drivers that Linux has.

22
9

Re: He's right. Again.

The Linux driver ABI have never been stable and never will be stable. That is just how it is intended to work. If some companies want to be proprietary, hide stuff and have secrets, it's their choice and their problem.

Drivers should be shipped as source code and built with a compiler at install time. That's how UNIX always have worked. From the beginning it was all source code shipped on tape reels and installing a new system was equal to building everything, the kernel, all binaries and libraries from source code.

26
9
Silver badge

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).

42
7
Silver badge

Re: He's right. Again.

>I gave up on hoping they would stablize to some degree about 10 or 11 years ago but is still sad to see. Just have to look at how many dozens if not hundreds of kernel combinations for example that vmware tools distributes drivers to see how bad it is. Looking myself I see two hundred and ninety three different kernel drivers. (And yes of course there is source code too).

There is a reason why they change the ABI ever so often, don't worry, I used to think just as you do now.

>The linux kernel devs like to say just release the source. Yeah like that magically solves all problems.

Exactly, this is one of the reasons they are doing it, it's because of the GPL. Ideally, vmware should just send their drivers to the Linux kernel dev team and maintain them there, that way, it would be available everywhere - it would also be cheaper on dev costs, because more eyes for free ... the downside, of course, is that you get to endure Linus' outrages when you are wrong, stubborn, and the issue takes common sense to comprehend. In short, vmware are, once again, being a bunch of d*cks which might also have to do with the issues discussed in the court case (alleged Linux code-lifting).

No downvote from me, although I am a fanboy ... actually, I am more of a HateAnyThingMSBoy and I have valid reasons to be, imho.

23
6
Silver badge

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.

3
8
Silver badge

Re: He's right. Again.

> But by making a version of a device's firmware get compiled in with the device driver in the kernel

What ? Well, actually, these are usually modules, which drivers end up in the kernel is the distribution's/manufactuers choice. If hardware driver requires firmware, the firmware files are placed into /lib/firmware where one can update them.

Now, you have this (what Linus is saying) with some wifi cards, where you have to download the firmware for your chip from the internet - maybe I should put this differently: To be able to use the device that connects to the internet, you are requested to download the firmware FROM the internet. I know, sounds "normal" to you, maybe because you use Windows and are fine with using other computers to download ethernet/wifi drivers ... In general, you don't have to download files from the open internet to install them ... on Linux. These are rare exceptions that Linus is handling perfectly. All because Broadcom are too @#$%@#$ silly and don't understand IT IS IN THEIR INTERESTS to provide ALL firmware images to the kernel dev team, actually, it would in in everybody's best interest if they released the source code to the firmware, that way you could have fully free drivers for their devices ... but that is just a dream with suckerz like that around.

16
3

Re: He's right. Again.

"I stopped paying close attention to the kernel when they abandoned the "stable" and "testing" branches, what was it the 2.4 days ? Before that it was say 2.0.x for stable, and 2.1.x for testing/dev, then 2.2 was stable, etc.."

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. My all time favourite event during that time was a brand new IBM server where the "stable" (2.2) crashed on boot, and the unstable kernel crashed sometime after boot. I ended up having to install a kernel with custom patches just to get the project going.

The new way of having shorter (get your feature working before the final RC or we pull it) system has been much more stable for me and the thought of ever going back to the old way terrifies me.

12
1
Silver badge

Re: He's right. Again.

"the company that STILL does not offer a programmatic, or group-policy, method of changing a user's account picture"

Glad to see someone's concentrating on the issues that matter.

No rest until the domain admin account has a picture of my cat on every machine!

14
2
Silver badge

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,

3
5
Silver badge

@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.

5
3

Re: He's right. Again.

Daring to speak the slightest ill of St. Linus or the Holy Linux Way will of course earn you downvotes (or in /. -speak "how does Satya's cock taste you M$-shilling douchemonkey?!?!?"), but that doesn't make you wrong. The whole approach to driver handling in Linux has never made sense to me to be honest and while I've seen musings from people much, much smarter than me on both sides of the fence I think it's safe to say that such discussions are all academic anyway since Linus will never change his approach (which it totally his prerogative since it's his train set).

As for Linus' "communication style", and the environment of the kernel development itself it's no secret that Linus isn't a "nice" guy to work with (something he freely admits) and it's always baffled me that people don't just tell him to shove his "hobby" up his arse and walk away (I know I would) but clearly there are enough people who enjoy/tolerate that sort of working environment because the project continues to thrive, which is a good thing since the computing world is almost certainly better off with Linux in it.

Would it be better if it was a friendlier community? Personally I think it would, while I'm nowhere near good enough to be writing code for a project like the Linux kernel I'm sure there are plenty of very talented devs who are but wouldn't touch that pit of toxic waste with a ten-foot barge pole. But as I said earlier the project is by-and-large thriving and no-one has a gun to their head forcing them to keep working on it.

9
8
Silver badge

Re: @hans, "Don't think I've done that --"

"-- [had to download and install a com-card driver] since early XP."

While Windows has evolved, I did have to fire up a separate machine and download a com-card driver last time I installed Win 7. (Oddly enough, Win 7 was going on a dirt-common desktop from a big-box store.)

No big deal, just saying.

5
1
Bronze badge
Joke

Re: He's right. Again.

"He's got to make an effort to make Linux drivers more modular"

It might be time to upgrade to at least a 1.2 kernel...

6
2
Anonymous Coward

Re: He's right. Again.

"He is doing what Microsoft should've done with Windows years ago and prevent hack jobs from entering in to the code, which are then built upon in later updates, which then can't be removed without massive re-writes to all of the code that relies on it."

Windows is already fully modular including most kernel side code, unlike Linux which largely isn't. So you can easily replace code modules in Windows by simply retaining the same API interfaces. This is one of the advantages of Windows more modern hybrid microkernel design...

3
8
Anonymous Coward

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...

0
1
Silver badge

Re: He's right. Again.

It is Microsoft that claims "backward compatibility" for all devices... and all software.

Never mind that Microsoft is lying in both cases.

9
4
Silver badge

Re: He's right. Again.

It is just as stable as Windows - as shown by Windows 10 not working with a rather widespread number of devices.

And Linux is MORE stable than Windows - drivers for existing devices get updated when the interface changes, at least for the drivers included in the kernel.

5
5
Silver badge

Re: He's right. Again.

They are ALREADY open to patent trolling.

Drivers have nothing to do with it.

2
1
Silver badge

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.

4
3
Linux

Userspace drivers

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

Drivers should be in userspace, not in kernelspace. Why in hell should the driver for a user-pluggable USB joystick run in the kernel ? Why shouldn't it be possible to make drivers for industry-standard devices have a stable ABI ? If it's that eternal context-switching argument, give the choice:

- do you want to compile this driver

<k> in the kernel

<m> as a loadable module

<u> as a user-space driver.

Linus has become too comfortable, someone else with new energy should step in.

That's how UNIX always have worked.

yeah, and thinks never ever change, that's it ? We shouldn't have come down of those trees in the first place.

5
6

Re: He's right. Again.

1000 times yes.

When Linux was young it was great to know that a stable ABI would not be maintained at the expense of a broken design just for the sake of compatibility. Now that Linux is 25 years old its well past the time it should have provided a stable driver interface. The notion that VMWare has to rebuild its drivers from source whenever I update the kernel is an abomination.

5
0
Bronze badge

Re: He's right. Again.

"No rest until the domain admin account has a picture of my cat on every machine!"

You would have a point if Windows didn't work this way in general. Linux has had good support for some classes of hardware for years. USB thumb drives are an example, in contrast with Windows where each and every drive has its own little bit of software on the drive and Windows still announces it is "looking" for a driver. Trying to access the more useful capacities of a USB digital microscope on the other hand, or of Canon printers or scanners in linux has always been a painful process. But that is simply because they won't properly document the HW interface for fear that someone will start making hardware knock-offs that work nearly as well or better.

1
0
Anonymous Coward

Re: He's right. Again.

"one of the advantages of Windows more modern hybrid microkernel design..."

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

Back in the days of NT3.x, when the evidence of NT's origins in Cutler's VAXELN distributed RT kernel were still visible to those who knew VAXELN (and for those who didn't know, it was briefly written about in Custer's Inside Windows NT), there was some plausibility in the modular kernel talk.

Various classes of process ran in separate address spaces and communicated via procedure calls, The amount of shared data was strictly limited, and for good reason (robustness and security, for example).

But this robustness came at the price of performance. Run the same app on a Win16 box and the same box running NT and the Win16 box would be a performance winner.

So over time Gates forced changes towards the monolithic approach, e.g. moving assorted drivers and subsystems into the kernel for performance reasons that for security and robustness reasons should have been isolated from each other.

The Win16 box wouldn't be a productivity winner, because it would keep running out of memory or locking up or falling over. Things that the NT user didn't have to put up with, But productivity is a lot harder to measure than performance.

And as far as I can see, the "more modern hybrid microkernel design", if it ever really existed, was sacrificed with the modular design, when performance won over productivity.

There *may* have been some return to the modular design during the "trusted computing" era, where it became important for PCs not to leak high value media content on the copy-protected way between content provider and HD display. But that wasn't about generic robustness and security, just about providing a trustable path (whatever that might mean) for end to end content delivery.

5
1

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.

9
1
Silver badge
Trollface

Re: He's right. Again.

"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."

If he turns out to be wrong on sómething, does he back off and apologize and can you call him publicly a cockface idiot?

If that's the case then he probably IS a nice guy.

2
0
Roo
Silver badge
Windows

Re: He's right. Again.

"But this robustness came at the price of performance. Run the same app on a Win16 box and the same box running NT and the Win16 box would be a performance winner."

I found that *most* Win32 binaries ran a lot quicker on a 166MHz Alpha with FX!32 than on Windows 95 or NT on a 200MHz PPro (stuff like PKZIP, Monotype RIP, even the 3D pipe screensaver). DEC did Wintel better than Microsoft & Intel on a tiny fraction of the budget, go figure.

1
0
Anonymous Coward

Re: He's right. Again.

"Monotype RIP, even the 3D pipe screensaver"

You were there, weren't you.

NT/Alpha RIPs (Raster Image Processing, i.e. PostScript to device-specific bitmap, sort of) were one of the areas where Alphas went from zero to hero in a few months, because of a focused and competent program where a few DEC people with clue working with a few RIP vendors (and others in similar trades, e.g. high end scanner/printer machines) with clue.

There were some low-level hardware-related issues, such as the inability of PLX's generic configurable PCI interface chip to cope with the PCI-compliant speed of IO from an Alpha->PCI interface, but once identified they were rapidly worked around. Most x86-based RIP builders had never been able to test their hardware to the limits of the PCI spec.

The software needed for RIPs was rather specialist; they could easily be built to run well on Alpha and the lack of native support for routine office apps on Alpha didn't matter on a machine dedicated to RIPping, especially as most of them just worked anyway.

The performance of 3D Pipes was largely down to the state of the art (but affordable) 3D graphics starting to ship with the NT/Alpha systems.

Then Gates decided NT was going back to x86 only and that was the end of that.

2
0
Silver badge
Devil

Re: He's right. Again.

"But by making a version of a device's firmware get compiled in with the device driver in the kernel you're linking firmware version to the kernel version. Not too clever."

why not? get the latest kernel to get the latest driver. either that, or insmod the driver after the pre-compiled part of the kernel boots up, during the 'init' process. [I think you can do this with systemd, and you could definitely do it with system V]

ok a little LESS convenient, I get it. but it's better than the alternative.

0
0
Anonymous Coward

Re: Userspace drivers

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

Drivers should be in userspace, not in kernelspace.

I have one word for you: Minix.

0
1
Silver badge
Devil

Re: He's right. Again.

"it would in in everybody's best interest if they released the source code to the firmware"

you'll have to change the way the FCC certifies WiFi to make THAT happen. BCM does a lot in FIRMWARE rather than on silicon, and so you end up with things as they are. Regulations prevent them from open-sourcing it, because that would let people modify the driver to violate FCC's requirements.

But yeah, provide the BLOB along with the driver "wrapper" to the kernel dev team, or make them sign NDAs to compile the BLOB and ship the compiled binary with the kernel. [incidentally I've worked with Broadcom's WiFi driver code in the past, so I understand what/why on this, though it's been a few years]

0
0
Silver badge
Devil

Re: He's right. Again.

"The notion that VMWare has to rebuild its drivers from source whenever I update the kernel is an abomination."

FYI - some internal structures may change size as the result of changes made in 'make menuconfig'.

As a result, the driver must be compiled using the configuration and header files for THAT kernel. That is because the structures and ABI won't match, even from simply making a change via 'make menuconfig'. Some of the network stuff was definitely like that about 10 years ago, when I was doing a lot of embedded Linux for wifi access points, and wrestling with getting the kernel config 'just right' and making sure the driver would still compile/run ok.

1
0
Anonymous Coward

Re: He's right. Again.

> As a linux user since 1996(desktop and server), I can say drivers on linux have been almost nothing but hack jobs the whole time.

You've had 20 years to fix it, champ. How much longer is it going to take you?

3
0
Silver badge
Facepalm

Re: He's right. Again.

You've obviously not met the CxO's I've met, including more than a few CIO's over the years.

0
0

Re: He's right. Again.

I don't know. I haven't seen him wrong yet ;-) Although, he has said in the past something like, "if I'm wrong, I'm just an idiot". But he doesn't go into a rant unless he's confident that he's right.

And I read the thread where this article came from, and I see nothing personally offending from Linus. Yeah, he swears and calls patches crap. But he's managing 10,000 changes a release, and needs to be efficient in letting people understand what he'll accept or not. And this is his way of saying "what you are doing is a show stopper, now stop that". I see people argue that he could be "nicer" and accomplish the same thing. Honestly, I don't buy that. I've seen Linus be "nice" and people don't "get it" until he starts swearing. The whole arm mess didn't change after Linus asked nicely several times, but one he went into his swearing tirade, the entire Arm community fixed their crap.

3
0

Re: He's right. Again.

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.

The API doesn't change that often. There is only four kernel releases in one year. A vendor should be able to output a new driver version within a few weeks after 4.8 is out of Linus hands. As soon as the first Release Candidate is out the API is available for vendors to start working on their driver.

0
1
Anonymous Coward

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.

0
3
Anonymous Coward

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...

1
0

Re: He's right. Again.

My wifi rtl8188cus relies on a hack of Realtek code to get around never fixed failings of the kernel driver rtl8192cu.

I see the fix is with the hardware manufacturers, who have to accept the importance of Linux and work with Linus to develop drivers which work properly.

The world should have moved past "we only develop drivers for Microsoft"

0
0
Mushroom

Re: drivers on linux have been almost nothing but hack jobs the whole time

He said he started in 1996 with LInux. I started in 1993 and for several years, they were literally and figuratively (the sites that hosted them were usually called Linux Driver Hacks) hack jobs. There has been some improvement since that time.

0
0
Roo
Silver badge
Windows

Re: He's right. Again.

"You were there, weren't you."

Briefly, they were interesting (and frustrating) times. Thanks for the PLX info - I must have seen the fixed product. The Intel OEM PPro box running Linux had the speed record - with NT the same box became an I/O bound dog - no amount of tweaking could hide how much x86 NT sucked at talking to disks.

1
0

Re: He's right. Again.

"If he turns out to be wrong on sómething, does he back off and apologize and can you call him publicly a "cockface idiot?"

Yes, and I can tell you what kernel devs can (and have) called him out and gotten away with it. Al Viro, as an example won many of his arguments with Linus back in the days when I had the time to track the kernel list more closely.

0
0

Re: He's right. Again.

WHAT? I have had linux boxes running for years. Moving from exchange server to a Postfix/Dovecot/Davical has meant that I haven't touched the groupware server for around 12 months. It is rock solid running Debian on an IBM powerpc. Ok, I don't think linux is so great in the desktop environment but as a server it p!55es all over Windows.

0
0

This again?

Grumpy dev is grumpy? Old news, move on.

Linux is a fantastic achievement, Linus has dealt with a lot of shit to help make it so. Sounding off at clueless devs is something probably more people wish they could do. And, er, are probably glad that their bosses can't!

33
4
Silver badge
Thumb Up

Re: This again?

Exactly and I am pretty sure he starts off being nice, pointing out the issue, when he sees the other stick his fingers in his ears he blows a fuse.

Looking at this specific case, Linus could not have been clearer:

> Nobody has actually answered the "why don't we just tie the firmware and module together" question.

>

>Really. If the driver doesn't work without the firmware, then why the hell is it separated from it in the first place?

>

>The hack is a hack, and it just sounds *stupid*.

Linus

https://lkml.org/lkml/2016/9/6/720

El'Reg, it would be greatly appreciated if you could put his outrages into more of a "context", thanks. And actually, I think Linus was very polite, for a change ...I'd call that numpty names you cannot find in dictionaries ... I also remember one of his other rants about a loony who wanted to store metadata first on drive so that, in case of failure, say sudden power-off, you could at least have the metadata ... Linus explained that metadata is "useless" without the actual data, d'oh! And the guy came back at it ... you're wrong, Linus tells you your logic is flawed, you still come back, Linus tells you to @#$%, sounds like fair play.

Go, Linus, go ... tell 'em!

18
4
Anonymous Coward

Re: This again?

> I also remember one of his other rants about a loony who wanted to store metadata first on drive so that, in case of failure, say sudden power-off, you could at least have the metadata

Brilliant that one!

0
0

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Forums

Biting the hand that feeds IT © 1998–2017