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
Suse has more packages in their repo. But, I prefer Mageia's control center to yast.
The globalised, hyper-centralised world is a bit boring, tbh.
Greg K-H is a fully autonomous human being and he doesn’t work for the author of tfa. It sucks that we live in a world where nation states try to put exploits into the linux kernel and other foss projects but we very much do live in that world. It sucks that that means the author doesn’t get to contribute to the Linux kernel because their government (who they presumably have little control over) are very active in doing that, but that too is a fact of life.
Either way Greg K-H doesn’t owe you or me or the author anything and people need to stop being so entitled about free software.
That was very much not the thing. He's raising an interesting point, if true. Namely that sanctioned countries could severely damage the progress of Linux by supplying good patches.
This is not the first case anyway.
>author doesn’t get to contribute to the Linux kernel because their government
I guess you're missing the point: nobody has asked me anything. The whole assumption that I'm Russian, from Russia, and a possibly designated, comes from using my .ru email.
I used to have .cn and .be domains as well during my life, should have been Chinese or Belgian to send kernel patches :D
That's explicitly not true, according to the Linux foundation. OFAC sanctions restrict providing a service, so here the violation would be two-way collaboration, not the receipt of information.
The kernel could review & merge the patch without running afoul of sanctions. What they cannot do is have dialogue with the sanctioned contributor.
Logic is not subject to sanctions, and anyone also may look at the submission and implement a matching fix.
https://www.linuxfoundation.org/blog/navigating-global-regul...
How does one prove a negative?
... and vice versa.
> The bug is forced to be fixed in some other way, not in a way it has been fixed by the bug fix contributor
I'm not quite following, why is this the case? If another non-Russian contributor submits the same fix, why wouldn't it be merged? If the project is GPL-licensed, surely that means the author of the fix doesn't retain any "patent" rights as the author describes it?
As long as somebody verifies that is the correct thing to do and submits a patch, I can't see anybody would complain about that. How else would you fix it?
But that's not what the article is complaining about. From their description, they removed a simple workaround, introduced a whole different approach to sending a message, relying instead on a watchdog timer. That's not a trivial refactor, and there could easily be a bug hidden in the change, intentional or not. That is the real issue.
Aside from anything else, the author was complaining about something going from no delay to having a 1ms delay, which broke his device. His solution was to rewrite it such that there was a variable delay, from 0ms to 275ms. That sounds even less desirable. A quarter of a second delay could easily be enough to cause data corruption on a drive after unmounting and before unplugging, if its logic on how to ensure data was flushed relied on that feature.
Such a major change needs extensive testing on basically most USB devices before it's randomly integrated into the kernel, especially when the fix it's undoing is over 20 years old, so the hardware it affects must be even older than that (and nobody else has used it in the last 20 years) and so most of the maintainers won't even be able to test whether the fix works anyway. It's just a big change explained away by a "trust me bro".
There’s literally nothing stopping them from fixing the bug in either this case or the hypothetical. The maintainer just doesn’t respond to email from .ru domains. He could still choose to take the patch. He may just have decided not to accept this patch because changing something quite obscure to fix a weird printer used by one guy is likely to cause more problems than it solves. We don’t know because he didn’t respond.
That certainly doesn’t mean he wouldn’t fix a serious bug just because he heard about it from a .ru address.
I haven't verified if what he's saying is true though.
> 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?
> Think about that.
I thought and I do not think this article is anything else but a rant.
What is this: does not ring, and does not fit in the ass..? Soviet device for ringing in the ass.
Infinitely more funny if you lived on the east side of the iron curtain.
