Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Netgpu and the hazards of proprietary kernel modules

lwn.net

Post reply on HN
Print view View original

91–100 of 104 posts

Re: Netgpu and the hazards of proprietary kernel modules

#91

Post by spoopyskelly »

kabdib wrote: post #34
microcow wrote: post #23

It seems reasonable to reject the patch for technical and legal reasons, but it's pretty disappointing to see toxic comments from prominent kernel developers like: > "Seriously? If you only even considered this is something reasonable to do you should not be anywhere near Linux kernel development. Just go away!" https://lwn.net/ml/netdev/20200727073509.GB3917@lst.de/ https://lwn.net/ml/netdev/20200728064706.GA21377@l…

> "Seriously? If you only even considered this is something reasonable to do > you should not be anywhere near Linux kernel development. Just go away!" A response like this would get you a serious talkin' to at just about any place I've worked. Possibly fired, if it was consistent behavior. I don't care if you're Donald Knuth, Dennis Ritchie and Edgar Djikstra all rolled into one, act like a jerk and you're off of my…

They should put participation awards in the Code of Conduct.

Re: Netgpu and the hazards of proprietary kernel modules

#93

Post by pritambaral »

userbinator wrote: post #60
pritambaral wrote: post #53

Earlier quoted context omitted.

> What you should really be asking yourself is why such code even exists I think TFA makes that abundantly clear. Repeating here for your benefit: "Symbols exported as GPL-only by the kernel are made unavailable to proprietary modules, but there has always been a bit of a loophole in how this is enforced. "Hellwig's patch does not entirely close this loophole, but it makes exploiting it a bit harder. "This episode, w…

I fail to see how this is even remotely the case. Or do you consider copyleft licenses to be "against the spirit of free software"? Actively making it harder for people to modify software for their own use is definitely against the spirit of free software! Copyleft has nothing to do with that, and is only about distribution of your modifications. The point of the patch is, literally, to help enforce the GPL. Once aga…

> ... for people to modify software for their own use

> ... private use/modification/etc

> It's my computer, I get to run whatever code I want to.

The patch changes none of that. The patch doesn't prevent you from disabling this restriction on your private builds.

It seems you still don't get the purpose of the patch. It is not designed to make _your_ private use difficult. It is designed to make _public_ contribution attempts like TFA that waste everyone's time again and again easy to push back against. TFA is not the first time something like this has happened. The kernel devs have repeatedly had to tell people off from trying to add proprietary-dependent or for-proprietary modules into the kernel. Adding a switch for GPL-and-non-GPL mixing makes that explicit and easy to catch.

> If they had their way I'm sure we wouldn't even be allowed to talk to them if we had ever used proprietary software at all.

I don't know where this antagonism comes from, but it seems like you're missing the point. Try to look at the posting from their point-of-view. It wasn't that the poster used some proprietary software on their own, but that they forced said proprietary software on every reviewer on the mailing list. Surely, you understand the distinction?

Re: Netgpu and the hazards of proprietary kernel modules

#94

Post by pritambaral »

q3k wrote: post #56
pritambaral wrote: post #52

Earlier quoted context omitted.

1. They're not a contributor. Not yet, anyway. 2. How degrading do you consider the submission? As can be seen from the patchset, there's no conceivable way it could be built into the kernel without having the kernel build depend on proprietary headers, effectively disqualifying it entirely. This all-important fact is revealed in the very last patch of a 21-patch patchset, wasting everyone's time, and a lot of it. It…

> As can be seen from the patchset, there's no conceivable way it could be built into the kernel without having the kernel build depend on proprietary headers, effectively disqualifying it entirely. Then just disqualify it, cite the reasons for why, and move on. No need for attacks, no need to tell the other person to fuck off. There's enough badness in the patch that you don't need to resort to criticizing the submi…

As I have said already, which you seem to be ignoring:

"This all-important fact is revealed in the very last patch of a 21-patch patchset, wasting everyone's time, and a lot of it. It's either utter carelessness, stupidity, or outright malice to ask for something like this to be included into a loudly-and-clearly GPL-licensed kernel.

----

In the end, all I have to say to you is:

If I walk up to you in the street and slap you in the face, unprovoked, surely the noble thing for you to do is to politely tell me off; but I will not hold it against you if you were to lose your cool and retaliate.

Re: Netgpu and the hazards of proprietary kernel modules

#95

Post by microtherion »

kabdib wrote: post #34
microcow wrote: post #23

It seems reasonable to reject the patch for technical and legal reasons, but it's pretty disappointing to see toxic comments from prominent kernel developers like: > "Seriously? If you only even considered this is something reasonable to do you should not be anywhere near Linux kernel development. Just go away!" https://lwn.net/ml/netdev/20200727073509.GB3917@lst.de/ https://lwn.net/ml/netdev/20200728064706.GA21377@l…

> "Seriously? If you only even considered this is something reasonable to do > you should not be anywhere near Linux kernel development. Just go away!" A response like this would get you a serious talkin' to at just about any place I've worked. Possibly fired, if it was consistent behavior. I don't care if you're Donald Knuth, Dennis Ritchie and Edgar Djikstra all rolled into one, act like a jerk and you're off of my…

Besides, I'm confident that Knuth would never say something like that, and Ritchie was not known for such antics, either, to my knowledge.

Dijkstra would probably have said something like that, though he'd have crafted a pithier way of saying it.

Re: Netgpu and the hazards of proprietary kernel modules

#96

Post by q3k »

pritambaral wrote: post #94
q3k wrote: post #56

Earlier quoted context omitted.

> As can be seen from the patchset, there's no conceivable way it could be built into the kernel without having the kernel build depend on proprietary headers, effectively disqualifying it entirely. Then just disqualify it, cite the reasons for why, and move on. No need for attacks, no need to tell the other person to fuck off. There's enough badness in the patch that you don't need to resort to criticizing the submi…

As I have said already, which you seem to be ignoring: "This all-important fact is revealed in the very last patch of a 21-patch patchset, wasting everyone's time, and a lot of it. It's either utter carelessness, stupidity, or outright malice to ask for something like this to be included into a loudly-and-clearly GPL-licensed kernel. ---- In the end, all I have to say to you is: If I walk up to you in the street and…

Neither carelessness, stupidity, or malice (over a patch!) warrants personal attacks. I wouldn't ever compare these to being slapped in the face, unprovoked, on the street.

A code maintainer's job is to curate, coordinate, help, and sometimes (in this case, notably) also gatekeep. If you can't stand the occasional terrible code and have to resort to personal attacks in order to vent off, or to feel better (or because you feel personally insulted) - then that seems to me that you're bad at your job.

If we're going with parallels - seeing this sort of behavior and excuses reminds me of people excusing police abuse. If you can't be cool and deescalate the occasional problem - maybe this job's not for you.

Re: Netgpu and the hazards of proprietary kernel modules

#97

Post by pritambaral »

microcow wrote: post #65
Corazoor wrote: post #50

Earlier quoted context omitted.

While I agree that these responses are rude, patches like this are the lkml equivalent of taking a dump in someones backyard... It might very well be that the submitter didn't know that, the documentation on what will be flat out rejected is not very explicit. But a compile-time dependency on a non-gpl module should be very self-evident, and the documentation explicitly asks people to go and learn about how the GPL w…

No! A flawed patch is not the equivalent of "taking a dump" in someone's yard. Proposing a flawed patch is not a contemptuous act, it's not insulting, and it is not injurious. Treating it as such is the problem. Telling someone they "should not be anywhere near Linux kernel development" and to "just go away" is degrading and contemptuous.

I feel like the difference of opinion you and us are having here are ultimately over the difference in perspective here. You label it as merely a "flawed patch". The original comment by the kernel dev that incited this whole debate isn't even directed at the flaw in the patch, so it kinda feels like you're arguing at cross purposes here.

Re: Netgpu and the hazards of proprietary kernel modules

#98

Post by pritambaral »

q3k wrote: post #96
pritambaral wrote: post #94

Earlier quoted context omitted.

As I have said already, which you seem to be ignoring: "This all-important fact is revealed in the very last patch of a 21-patch patchset, wasting everyone's time, and a lot of it. It's either utter carelessness, stupidity, or outright malice to ask for something like this to be included into a loudly-and-clearly GPL-licensed kernel. ---- In the end, all I have to say to you is: If I walk up to you in the street and…

Neither carelessness, stupidity, or malice (over a patch!) warrants personal attacks. I wouldn't ever compare these to being slapped in the face, unprovoked, on the street. A code maintainer's job is to curate, coordinate, help, and sometimes (in this case, notably) also gatekeep. If you can't stand the occasional terrible code and have to resort to personal attacks in order to vent off, or to feel better (or because…

> Neither carelessness, stupidity, or malice (over a patch!) warrants personal attacks.

1. We both know it wasn't just "a patch". Downplaying what happened doesn't serve the discussion.

2. I do not see "If you only even considered this is something reasonable to do you should not be anywhere near Linux kernel development. Just go away!" as a personal attack, but as an attack against _the behaviour_ that _deliberately_ wastes a lot of one's time. Note the _"if you ... considered this ..."_.

----

> I wouldn't ever compare these to being slapped in the face, unprovoked, on the street.

This is not the comparison I made. I compared the reactions of the offended and your comments on said reactions. Let me try again, in clear terms: I find it understandable when someone doesn't react calmly and politely to having a lot of their time _deliberately_ wasted and their principles attacked.

> ... the occasional terrible code ...

See, again, I think you're severely downplaying what happened. The LKML regularly sees "the occasional terrible code". This is not one of them. Not even close.

> ... this sort of behavior and excuses reminds me of people excusing police abuse.

That is a ridiculous comparison to make. The LKML does not exist to "protect and serve" the public, is not funded by the public, or even remotely responsible for law & order & safety & peace of the public.

It is a private group of like-minded people that happen to be open to public participation. If you go and take a dump on their lawn, don't be surprised at some harsh words thrown back at you.

And definitely don't compare a handful of harsh words that are easily brushed aside for gruesome physical brutality and blatant wilful murder.

> ... the occasional problem ...

Again, you are severely downplaying what happened. What was posted is not an example of "the occasional problem" — there's plenty of those in the lists. What was returned wasn't nearly as toxic.

Re: Netgpu and the hazards of proprietary kernel modules

#99

Post by shmerl »

Arnavion wrote: post #59
shmerl wrote: post #55

Earlier quoted context omitted.

> Unfortunately it's something that all their customers who use it today need, and are quite satisfied with using. Doesn't look like it: https://www.gamingonlinux.com/index.php?module=statistics&vi... Nvidia usage among gamers on Linux at least is gradually dropping. Blob is causing all kind of problems (especially in Wayland session use cases), while not offering any advantages over open drivers from AMD. And with I…

Their gamer customers are mostly on Windows. Their Linux customers use their cards for ML and CUDA.

But we were discussing Linux users. Windows market is irrelevant for that.

Industrial Linux users are not using their gaming cards.

Re: Netgpu and the hazards of proprietary kernel modules

#100

Post by Arnavion »

shmerl wrote: post #99
Arnavion wrote: post #59

Earlier quoted context omitted.

Their gamer customers are mostly on Windows. Their Linux customers use their cards for ML and CUDA.

But we were discussing Linux users. Windows market is irrelevant for that. Industrial Linux users are not using their gaming cards.

>But we were discussing Linux users. Windows market is irrelevant for that.

You brought up Linux gamers, so I pointed out the Linux gamer market is miniscule because most gamers are on Windows.

>Industrial Linux users are not using their gaming cards.

Okay? The thread never said anything about gaming cards. Again, you're the one who brought up gamers in the first place.

Post reply on HN