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 …
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.
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.
>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™.
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).
"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.
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.
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.
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.
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.
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.
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.
>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.
"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.
"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.
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.
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.
"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.
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.
"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.
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.
"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.
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.
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.
"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.
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"
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.
> 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.
"-- [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.
"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]
"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.
"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...
"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.
"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.
"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.
"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.
"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...
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!
Would you expect the same if you buggered up a code write, a system upgrade or whatever? I expect my manager to give me all kinds of shit if I f**k-up, it comes with the well paid job that is working in IT. I don't earn minimum wage, I worked hard and I earn good money and that comes at a cost, I need to take the repsonsibility seriously. As you head up in to the higher rankings in any kind of organisation the responsibilities increase and so do the rewards. You need to act like an adult and accept praise and scorn as deserved, not act like some sort of frightened little kid everytime you screw something up. Take your "beating" but do better next time, that's how life works and how you you learn to get better at something.
That's not a good attitude. If I fuck up I expect to be told to fix it. Anything beyond that is not acceptable in a work environment. If someone repeatedly fucks up then take them off the project.
Abuse is not an appropriate response from someone in a position of authority. Any manager trying that shit with me will get very short shrift.
"Any manager trying that shit with me will get very short shrift."
You have to remember that Linus is not the manager of any of these people. He didn't hire them. He didn't interview them. He doesn't write their appraisals. All he can - and does - do is to refuse to accept their stuff with increasingly firm notes as to why he's refusing it. Sometimes this requires several increments of firmness.
I haven't forgotten that. I was replying to the OP who afaik wasn't talking about Linus.
Clearly Linux is a successful project. The question of whether Linus' personality is a help or a hindrance to the project is one that the devotees wont contemplate. The rest of us are allowed to wonder if a more mature approach to managing the project would make it better.
The fact that Linux is by far the hugest successful collaborative project in history would seem to indicate that Linus' personality _is_ a help. Without that no-compromise attitude, it would have failed long ago.
@oldcoder:
Abuse is perfectly fine when you need to get the persons attention.
No it isn't. Abuse is NEVER acceptable. If one thinks that is the only or best way to get their attention, then one needs character development oneself. It is the mark of someone with poor people skills and no regard for the reason good manners have developed since the days of cave men. I don't mean everything has to be a negotiation. I mean you respectfully inform people when they make damaging mistakes, and work with them to become better. That helps both them AND YOU, and avoids provoking resentment and antipathy, which is NEVER a desirable outcome.
> Abuse is perfectly fine when you need to get the persons attention.
I dare to disagree. If somebody consistently causes problems AND is resistant to all other approaches, then I can understand abuse. Still, keeping calm does not hurt.
That said, I am largely on Linus' side with all incidents reported on the Reg. Also I have treated people in a way that is called 'abuse' by now (each time after they have been useless dick-heads of the first order for months or even years). I have to admit that I never regretted any of that.
So, icon is not me.
> That's not a good attitude.
You haven't read the LKML discussion. Are you really trying to form an opinion on the basis of a redtop article, the purpose of which is to amuse¹ rather than to inform? In reality the discussion was quite civil and productive, with the guys freely accepting that indeed their patch was rubbish and Torvalds proposing a number of solutions to the problem at hand.
> Any manager trying that shit with me will get very short shrift.
As they say in Bavaria: Jo, jo ...
¹ For someone's definition of "amuse".
" I expect my manager to give me all kinds of shit if I f**k-up"
Not exactly contemporary management, I guess your company is not an "Investor in People" award holder.
Either way I thought the devs on Linux were not employed by Linus and we mostly volunteers (excluding of course the big name companies who send their work back upstream)
In that case it's more important to try and be civil! You don't even have the excuse that your paying someone for their effort.
What sort of person gives up their time freely to help a mouthy ingrate build something? Just how in awe of someone do you have to be to put up with this behaviour? Doesn't paint a very flattering picture of the community....
Yeah I don't get this "You're an adult, therefore you should be able to take the beating" or "You cock up, you take the beating".
That isn't how people learn. Sure, if they repeatedly make the same mistake(s) then you need to take action but all the blame/bullying culture does is to make people feel they cannot own up to mistakes and they end up trying to hide them - end result, what would have been a small mistake easily managed becomes a calamitous one that can't.
Interesting how there are these signs round place like hospitals warning that verbal or physical abuse won't be tolerated and the police will be called. The BBC, for once, did the right thing last year when they ended Jeremy Clarkson's contract for verbal (and physical abuse) and yet some of you seem to think it's ok in our world? That it's somehow "character building"? Please!
Don't be surprised if you act like an arsehole to me from the get-go that I react in the same way. Equally, start ranting at me and swearing like it's a drunken bust-up in a nightclub and be prepared to pick your teeth up. Bullies only tend to understand that kind of language.
You pay people for their skills, not the right to abuse them. And frankly it doesn't matter if you're on £15k or £150k that still stands.
The story is a bit more nuanced that the El Reg article leads you to believe.
The El Reg article implies that Linus wants the firmware supplied with the kernel module. The issue is that for some devices, the driver is generic and the firmware can be written be anyone. Hence the firmware BLOB can come from a standard filesystem which isn't available until the system has booted further than initial module initalisation.
Whether the patch author's approach for tacking this problem is correct, though, is for clever minds than mine to decide upon.
"The issue is that for some devices, the driver is generic and the firmware can be written be anyone. Hence the firmware BLOB can come from a standard filesystem which isn't available until the system has booted"
Thanks for the explanation, but why the firmware blob cannot be included in initramfs like the drivers are? That would seem to be the usual way of making things work.
Back in RSX or VMS days, we'd have had an ACP (daemon) that was signalled on the first attempt to access the device and loaded the firmware then.
I'm not terribly familiar with Linux, but it seems that udev only gets events for devices being added and removed (and power state changes), so the driver can't send a custom "load my firmware now, please" message. However, presumably you could start a demon on device discovery and have it hang around until it was signalled by the driver that it was firmware-loading time?
It would seem more logical to load the firmware when it was needed rather than when a filesystem that may or may not contain it becomes available.
However, presumably you could start a demon on device discovery and have it hang around until it was signalled by the driver that it was firmware-loading time?
Basically, this kind of thing is one of the reasons why we ended up having systemd and then udev got subsumed into systemd - soon The Blob will swallow the kernel :9
I think the way udev works is that when it starts up, it simulates a hotplug event for all devices it has discovered, as if they had been added.
At that point, firmware gets loaded if needed.
If /lib/firmware is on a device which needs firmware... you can put the blob in the kernel, or on an init ramdisk.
I think Linus is playing to the peanut gallery when he behaves like this.
It's fun, it's entertaining (if you're not on the receiving end, I suppose) and it adds a little spice to the otherwise dreary business of maintaining an operating system kernel.
It's true that in a normal business situation, this behaviour would be unacceptable (and f2f, would significantly elevate the risk of receiving a firm biff on the hooter - or at least a strongly-worded email), but kernel development ain't that.
I think he does this because he gets fed up of receiving a bad piece of code and occasionally escalates into a profanity laced but reasoned and critical post to explain why its bad and why it won't be accepted. Presumably these posts do attract attention (clearly The Register is a subscriber if it can generate a cheap story for them) and perhaps that's the point. People read the post, get the message and stop submitting stuff that way.
It's true that in a normal business situation, this behaviour would be unacceptable
Sure, which goes some of the way at explaining why businesses are so bad at dealing swiftly and appropriately with moronic stupidity so instead we end up with 16-binder Q&A documentation where every little task is spelled out in colourful UML charts.
Jesus, fucking Christ the number of times I have to explain something that even WikiPedia get right!
There are lots of bosses in the corporate world who are far worse and can do and do far worse to others than a tongue lashing.
I feel the sensibilities regarding the rather caustic line of Linus's colloqualistic technique are a little bit silly.
I quite feel the same way regarding systemd philosophy and, if anyone listened to me, I would probably use similar phrasing.
I dissagree.
Sure, he doesn't have to be touchy-feely, but he could have made exactly the same point without being offensive. There's nothing wrong with "This is a bad idea because of ..., I will not be accepting this into the kernel".
I feel it's common to confuse straight talking and being offensive in the tech sector. Hell, I've certainly been guilty of it myself. However, it's really important to remember that if we want people to be innovative then they need confidence, and so it's not helpful to knock people's confidence when one of the new ideas that they have turns out to be an awful new idea. My feeling is that there's no place for shaming in any of this.
There's nothing wrong with "This is a bad idea because of ..., I will not be accepting this into the kernel".
That approach works for the first 'n' times*. Then from n+1 it starts to get personal. Linus is probably at n^2. :)
Values of 'n' can vary wildly based on your general disposition, last time you got laid, how many kids you have etc etc..
These posts happen after a series of "bad idea because..." posts.
It's the final "Seriously, go away right now, you've pushed this way too far."
Unfortunately volunteer-run organisations have very little else they can do - if the volunteer won't accept a polite "no", then the only remaining choices are an impolite "no" or ejection.
"This is a bad idea because of ..., I will not be accepting this into the kernel".
What makes you think he didn't in the first place...?
I've said it before, but these 'Linus goes nuclear' 'news' (entertaining though they are) posts never cover the background of the incident. Usually when you look into the event, the usual polite diplomacy precedes them and the recipient has decided upon some form of brinksmanship and push the issue beyond the limits of the Linus patience threshold.
'Linus posts a reasoned and thoughtful argument against a proposed kernel submission' just wouldn't be clickbaitnews - although we might all learn something educational on a well written article on it.
There's nothing wrong with "This is a bad idea because of ..
Yes. There is. It doesn't affect stupid people who simply cannot be made to understand why something is a bad idea. Having had only a few thoughts ever, ideas have *value* to stupid people and they will just drone on and on and on about it.
For the sake of everyone else, you have to stop them, somehow, without shooting them in the face or clubbing them. Which is illegal, I think. Lacking a "Space Core Directive, Section XXXXIIVII Part B" or an ISO 9000 manual to divert them, abuse is the only way.
"For the sake of everyone else, you have to stop them, somehow, without shooting them in the face or clubbing them. Which is illegal, I think. Lacking a "Space Core Directive, Section XXXXIIVII Part B" or an ISO 9000 manual to divert them, abuse is the only way."
I feel your post was a little OTT, but I upvoted you anyway because I did laugh out loud.
"What makes me uncomfortable is the line of reasoning that when all else has failed there is no alternative but to throw an abusive shit fit."
I'm sure he'd welcome a constructive suggestion from you. But don't offer it twice if you get turned down politely the first time.
While Linus Torvalds' actions may seem childish, sometimes one must embarrass those who keep resurrecting stupid ideas. Sometimes it is the only way to get someone to stop pushing a pet idea that just doesn't work right.
Firmware defines the interface a driver must work with. They are intimately connected. If the firmware goes through a rev, it is possible that an interface that the kernel driver has to work with changes.
Figure this: A board using an FPGA as the interface controller sitting on the edge with the PCI-E bus. The firmware gets downloaded to the FPGA (sometimes flashed locally onto the card, sometimes going into video ram that loads the FPGA on a reset). If I change the code for the FPGA, I can easily change how the card interfaces with the PCI-E bus, where controller registers are located, how the card's memory is mapped to the bus, etc.. and therefore changes how the kernel driver talks to the card.
If I don't tie them together, it is possible to have a disconnect with the firmware version and the driver version that is supposed to work with it... causing hard to diagnose breakages. Who and how would the 'magic' combinations of firmware rev and driver rev be tracked?
SGI (when it was a real company) would keep the firmware drivers for the graphics cards with the OS builds (the ole Onyx and Onyx2 RE series). Several other large companies have done the same.
WTF? because separating the two is really a face-plant moment.
Firmware updates rarely add new features. There could be no driver changes but a bug fix in the firmware which fixes a bug which leads to data loss under some conditions.
1) I hope everyone's up to date with their kernel. Cutting edge, all the time.
2) It makes the data loss bug look like it's the kernel's fault, when it's nothing to do with the kernel.
3) Things like this can happen.
If the driver really doesn't like the firmware version, it always has the option of not mounting the device and letting you know with an error so that you can run the firmware update software.
People need to look up the form, fit, function rule which is considered best practice for all engineering change control. If one part of an assembly breaks its internal interfaces (i.e. between two software blobs, two mechanical parts, an electrical plug pinout), then that part needs to be given a new 'part' number, not just up-revised. As the mating part will have to fundamentally change too (the electrical socket needs to mate with the new plug pinout), and will not be backwards compatible, then that will need a new part number as well. The parent assembly (firmware + driver) will definitely need to be up-revised as its child parts have changed, but may need a new 'part' number if, due to the internal changes of the 'parts', its interface to the outside world changes. In this case, it makes absolute sense to always supply firmware and driver as a controlled 'assembly' of parts rather than independent parts.
"the form, fit, function rule which is considered best practice for all engineering change control."
That's a bit 20th century isn't it? Worse still, it requires proper understanding of engineering practices, and a willingness to implement them (and accept the associated short term impact on costs and timescales).
We're in the 21st now. Things have changed. "Shiny" rules IT, or if not shiny, maybe shouty.
Whether Linux would be better or worse if its mailing list had a different hue is hard to say.
No it isn't, it would be worse. If you want to get it right, you need an autocrat to put their foot down whenever the development process coughs up one of the usual expedient[1] workarounds. The foot also needs to be put down in such a way that those responsible for the abortion know that they'll only get away with this shit after hell's frozen over.
I shudder to think what Linux will become if and when it moves to more conventional and compromising governance.
[1] Cost or Time are invariably the root cause.
And the only way to do that is abuse? Nonsense. A clear "That's not going in, and here's why" would work better in most cases.
The choice isn't "compromise or be a dick", it's "don't pull with a simple explanation or don't pull with an abusive rant".
How many good engineers don't even think about contributing because of his childish outbursts?
"And the only way to do that is abuse?"
Only when all else fails. How would you handle the situation when someone keeps trying to get the same nonsense into your project? Remember no normal corporate procedures are available to you because it's not one of your employees or vendors or customers doing this.
Over the years, I have come to see a pattern. The people who write code are good at communicating with computers, not so good at communicating with people. In the past, somebody with some skill at writing could produce an "unofficial" manual that usually managed to be well-organised documentation. Now we told to look it up on the web, and watch YouTube videos.
I don't really expect Linus to be subtle, and he is likely dealing with too many people for who subtlety is a waste of time. What I see of this "bad language" is more about intensification than insult, driving the point home.
He doesn't know all the tricks. He doesn't use dramatic irony, metaphor, pathos, puns, parody, litotes or satire.
Just using good English should be enough, but have you seen any recent documentation?
"The people who write code are good at communicating with computers, not so good at communicating with people"
I think you're wrong. Why? because it's the RECIPIENT of the communication that's the determining factor, more often than not, as to whether the communication is effective. You can tell SOME people that "1 plus 1 is 2" and those people will simply get OFFENDED even though they AGREE with you. It doesn't matter HOW you say it, so much, as the fact you SAID it, you were CONFIDENT when you said it, you didn't "feel as if" 1 and 1 are two, nor did you ask THAT person if he "felt" as if it were two, but you simply MAKE A STATEMENT OF FACT, without sugar coating it, and the recipient [with chip not-so-firmly resting on shoulder] whines and cries and complains and calls you a bigot (that's how political correctness works, anyway).
I love it when someone is telling me some B.S. and says "are you even LISTENING to me?" and I reach deep down to a skill I learned in the military, and I summarize EVERYTHING said over the last nn minutes, and then say "and I *DISAGREE* with you for the following 'n' reasons" and then enumerate them.
I _THINK_ that people should _STOP_ being all "feely", and Linus is a good example to us all of how it SHOULD be done. There. I said it.
The mostly non-existent drivers of Linux are why you can't buy PCs at your local store with Linux.
Linux will only play nicely with about 1/10 of existing devices.
Converting any PC in the last 15 years to Linux is always a crap shoot, sure the OS loads, but then the mouse, or the screen, or the sound, or the printer, or the network card don't work.
Don't even try searching Linux forums for solutions or help as you will be met with snarky developers who will heap abuse on you for not being smart enough to write your own driver.
"Converting any PC in the last 15 years to Linux is always a crap shoot, sure the OS loads, but then the mouse, or the screen, or the sound, or the printer, or the network card don't work."
It used to be like this 15+ years ago (I remember even having to create my own script to get my dial-up modem to connect to the Internet.) However, that once-true stereotype wore out its welcome years ago.
A lot of modern distributions have bloody good compatibility with many things (e.g. sound) working automatically straight out of the box to an extent you might find surprising. I'm not claiming that everything's perfect, but you can't say that about Windows either, given the reputation of recent versions for breaking drivers. Certainly not a case where you could argue in favour of the latter against the former.
"The mostly non-existent drivers of Linux are why you can't buy PCs at your local store with Linux."
How about doing some careful thinking. If a manufacturer wants to sell a pre-loaded Linux box they can make damn sure that it has the correct drivers built in. This won't be difficult because as someone else has said, most stuff is supported these days.*
The reasons why you can't buy such items easily are
(a) there isn't a big corporation like Microsoft with a marketing budget to promote demand; in fact there's a big corporation like Microsoft with a big budget trying to suppress demand. (Remember Netbooks.)
(b) the local stores are staffed with oiks who can only recognise a handful of brands.
(c) that you haven't recognised the Linux boxes which are available at your local store. Apart from Android devices, which we can agree aren't PCs you might well find such things. But, because of (a) above they won't be labelled "Linux". Try looking for something labelled "Chromebook".
*OTOH it appears that in the future you won't be able to get Windows other than 10 to install on newer H/W because Microsoft will actively prevent you.
"Linux will only play nicely with about 1/10 of existing devices."
uh, no. I rarely have problems, and most of them were with things like winmodems pretending to be sound cards on very very very old hardware [a toshiba laptop, specifically].
these days, I find there are very few devices that don't support Linux. FreeBSD, on the other hand, I have a bit more trouble with. [but it's been good to me thus far]. NDISWrapper helps, though.
(never DID get the atheros wifi to work for FBSD in my old laptop, and now the motherboard needs replacing - yeah, and all but THAT chipset probably works fine - it's the device itself, a pre-N card from 2008-ish)
Still I've found that nearly everything ELSE works 'first time around' when I plug it into a Linux system. All of those cheap ethernets, and particularly wifi and bluetooth devices that use certain very COMMON chipsets, "just work". they even work on RPi.
Maybe the hardware makers need to cough up a proper driver for their stuff, instead, something you can build locally and then 'modprobe' into the kernel startup.
(yeah that's what should be done with those wifi drivers that Linus ranted over...)
It's not so much there aren't any drivers but device support either exists in the ever growing huge bloated mess of kernel (including the one that this article is about) and userland packages. Or it doesn't.
There is NO mechanism for plugging something in the the machine going to find drivers for it based on the IDs (USB or PCI) or the device. Like MS Windows does. Nor is there anything in the pipeline that does that but I will accept correction.
"There is NO mechanism for plugging something in the the machine going to find drivers for it based on the IDs (USB or PCI) or the device."
I'm not sure I fully understand your sentence. If you plug something like a USB drive into a Windows box Windows seems to make a big song and dance about loading drivers and all that. All that happens if I plug the same thing into this Linux laptop is that I get a popup telling me that I can open it with the file manager, Digikam if it found some image files on there and various other options if it found sound files in there (including burning them to a CD).
No, what he meant was that he's not aware of a way to pull up the Product ID or Vendor ID for USB or PCI devices in Linux. He may have been referring to devices without drivers that enumerate but then can't be worked with.
In Windows this is easily accomplished in Device Manager, and means that you can use the likes of PCIDatabase.com to look up which manufacturer and chipset you're working with, then get a driver that's close enough that it'll get your device working.
This is something that's been in Windows for decades and has saved my ass on a good few occasions.
Does such a thing exist in Linux?
Getting humiliated is a reasonable cure for "being a dick", and to get personal attention from Linus in this way means you've really been a dick.
It is probably ultimately good that Linus is passionate about what does and does not go in the kernel. Imagine what Linux would be like if he let any half assed idea become part of the code?
It actually isn't.
Not all of the code is used for a particular instance - For example, none of the ARM code, or 68000, or Power, or IBM 370, or the Z code is used when you are X86 based.
But they ARE available if you want. The kernel you get is actually smaller than Windows. The only things that get added are driver and filesystem modules for your specific use.
Thus, no bloat.
Now when it comes to distributions, you have a different source of bloat, and it isn't the kernel.
The separation if the driver and the firmware was probably driven by some guy in a suit that wanted to control everything. The poor software writer of the driver can only say "OK" and try to do it that way. Of course it makes little sense, but he was doing as he was told. With the feedback from Linux, he can tell his higher-ups that it can't be done that way. So, the suits might relent and allow the "proper" way of doing things firmware blob in the driver and all that.
If they want to update the driver, OR the firmware, a new release is in order. See, it isn't that difficult. The maintaining of a specialized program that talks to the driver is a special way to load the firmware, which needs to be done before you can do anything, is at best a difficult task. Making it work in all circumstances (now how to I get this into systemd) may well be out of the question.
Put simply: The driver should be all you need for a device. No more, no less.
Today people have a strong incentive to participate in "Open Source" projects. Recruiters look for names in such projects, and honestly this isn't the worst way to look for new talent.
However there is currently very little public incentive to make sure that code is useful or good. The prime example (because it's so clear) is the OpenSSL "keep alive" feature. There was someone writing a thesis on this feature... which is of limited use... then he writes a patch which contains a glaring error and it gets accepted.
We need people like Linus Tovalds which question new features. We would need them in projects like Debian or Gnome or xfce. Unfortunately we have to little of those people.
I wonder how much of the ire Linus attracts when he goes in to a sweary rant is down to jealously?
We've all been confronted by a colleague's terrible code (and vice versa). Very few of us are ever in a position to stop them, let alone comment on it candidly.
Being able to say that a patch is "f'ing awful" or such is simply not something we'd be able to do and keep our jobs. But we so, so wish we could.
Not because we want to belittle our colleagues, but because the code being reviewed is so, so awful it needs to be sworn at. Calling it "f'ing awful" is just a descriptive label. It's not a personal thing against the author of the code.
And on that level, is it better for the code to be "awful" or "f'ing awful" ?
And in an ideal world, the author would join in the laughter - "Yes, it is f'ing awful, I don't know what I was thinking!"
If you accept that Linux would continue to be successful if Linus were to be hit by a bus, then you must also accept that his way of doing things is not the only way. Which means that being rude to people and hiding behind technical brilliance is not, in fact, required for Linux to be good.
Linux is not a particularly elegant set of code. History, success and market pressures see to that. It's no longer the hot underdog whose adherents can fight the good fight with a purist passion. It's a fat, middle-aged lump of code alternately lovable and loathe-able. It's time for Linus to drop the Holy Keeper Of The Flame act, take a long, long sabbatical, and do something else for a few years.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
