Spoiling Linux Kernel with "sanctioned" code
66 points
1 day ago
| 7 comments
| printserver.ink
| HN
flashmozzg
16 hours ago
[-]
Is there a CVE for this?
reply
mike_hock
22 hours ago
[-]
Obvious attack vector for Russia: Submit fixes to severe bugs that can't realistically be fixed any other way.
reply
thefounder
1 day ago
[-]
I guess the Russians will have to learn the Chinese way and perhaps the Chinese language as well?
reply
1attice
23 hours ago
[-]
I've been thinking lately that what underpinned the FOSS golden age was not actually decentralized VCS and high-quality forges, nor even ZIRP, but rather peacetime.

After a period of branches and patchsets, full national hard forks are going to become de rigeur, and linux-derived OSes across the world are going to bloom necessarily, as we no longer have the kind of ambient trust required to collaborate across borders.

Look forward to Euro-linux, Sino-BSD, and I guess probably some sort of GCC-area build as well.

Patches will be accepted across national boundaries with only the highest scrutiny, which itself will likely be provided by nationalized AI platforms.

Gods I hate this era

reply
gaiagraphia
5 hours ago
[-]
This is a great thing for innovation though? Nations/blocs protecting their tech interests will result in more jobs to go round in the industry, more unique ideas, and less centalisation, surely?

The globalised, hyper-centralised world is a bit boring, tbh.

reply
1attice
2 hours ago
[-]
I forecast that you will not be bored, and may have other, stronger feelings. Ask Ukrainians
reply
gmerc
1 hour ago
[-]
Perfect usecase for AI, by US legal doctrine, copyright is gone after you feed it through and so should sanctions /s
reply
robobully
1 day ago
[-]
This post is apparently not publicly shown on the main page for some reason.
reply
ValdikSS
1 day ago
[-]
Why should it be? It has low rating (yet).
reply
_user_account
20 hours ago
[-]
Yeah, it sucks.

> This adds ~1ms latency per transfer cycle for rapid bidirectional communication which leads to half the USB 1.1 speed for smaller packets at best.

Still, I don't think this patch should be applied /for everyone/. Maybe compile out-of-tree and load as a kernel module, if possible?

reply
M95D
23 minutes ago
[-]
I still have a MB with just a USB 1.1 controller. I would hate it if the USB stopped working after this fix. I think a config option for the delay would be best.
reply
ValdikSS
17 hours ago
[-]
The patch removes this latency and improves transfer speed, without any drawbacks.
reply