Nvidia should stop fooling around and support Nouveau. Their dinosaur blob driver approach is not something anyone needs.
Netgpu and the hazards of proprietary kernel modules
31–40 of 104 posts
Re: Netgpu and the hazards of proprietary kernel modules
#32NVIDIA is a source of the most kernel problems related to the proprietary drivers. Pure evil. They manage to intoxicate the ecosystem without even doing anything.
Re: Netgpu and the hazards of proprietary kernel modules
#33It 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…
How is that comment toxic? The code this guy was trying to get merged in was toxic, and the kernel developer rightly told them to stop trying to push this harmful code.
Re: Netgpu and the hazards of proprietary kernel modules
#34It 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 Christmas list.
Re: Netgpu and the hazards of proprietary kernel modules
#35> The sad part is that, by all appearances, the goal of this work was not to add functionality for NVIDIA GPUs in particular. I don't see how that can be true given that it is designed to speed up ML, and only nVidia graphics cards are used for ML. Approximately nobody uses Intel or AMD. Maybe they meant it wasn't written by an nVidia employee? But it's clearly intended to be used with nVidia GPUs in particular.
It uses an NVIDIA apis, its made for NVIDIA tasks (CUDA) and it was only ever designed to work on NVIDIA cards. Apparently being a Facebook employee means you can't have pro-NVIDIA anti-anything else intentions... even when that's clearly the case.
Re: Netgpu and the hazards of proprietary kernel modules
#36It 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…
As a user and downstream developer, I'm glad that the Linux maintainers are committed to maintaining a sound architecture. The idea that they need to be more polite about rejecting low quality work is puzzling to me.
>need to be more polite about rejecting low quality work is puzzling to me.
First, it's not low quality
Second, for sure you have to be polite if you don't pay him (but even when you do, you should)
Third, imagine a 16yo get smashed like that (not that i say he is) and what a devastating and demotivating thing that could be...welcome to the linux world
Overall, those Superstar Linux dev's are mostly ignorant borderline autistic assholes who can't develop a good Filesystem like XFS or ZFS from scratch, then moan about Nvidia, but work on a computer with around ~100 proprietary systems called firmware. One accusing the OpenBSD peoples for being masturbating security Monkeys just to say (4-6 years later) that they where right (a super rare occasion for a linux super star). You know what i like to say? FUCK YOU LINUX, FUCK YOU GNU (but not grep...gnu grep is nice)
Re: Netgpu and the hazards of proprietary kernel modules
#37Make BSD great again.
it's always been great
Re: Netgpu and the hazards of proprietary kernel modules
#38Make BSD great again.
Fortunately the BSD systems are largely free of this kind of NIH.
Re: Netgpu and the hazards of proprietary kernel modules
#39I feel like all this needless bureaucracy could've been avoided completely if Linux hadn't turned into a target for everyone to (try to) put code in. The GPL allows modification and redistribution, after all. With this patch applied, any module that imports symbols from a proprietary module is itself marked as being proprietary, denying it access to GPL-only symbols. That's starting to sound like DRM.
> That's starting to sound like DRM. It's close, but the key difference is it doesn't actually restrict the user, since you're both legally allowed and technically able to build and use a kernel without that code.
Not being able to use functionality because it never got implemented due to some licensing shenanigans does not restrict the user?
Re: Netgpu and the hazards of proprietary kernel modules
#40I wonder if it’s somewhat similar to Linux developers refusing to support TCP Offload Engine functionality, inventing various excuses easily proven false by experiences with TOE support for other systems.