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.
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 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.
> Other people who would like to have this bug fixed can't commit it from their name or reuse the code present in the mail list from assumingly sanctioned entity
> 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?
Suppose the issue was an incorrect constant used, e.g. a change from a 0 to a 1.
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".
So here’s the thing. The author thinks that Greg K-H is under some sort of obligation to respond to the patch they submitted. But that’s just not how free software works.
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.
FTA: "The code can't be merged into Linux kernel unless the contributor can verify they're not working in a sanctioned company of said country (guilty until proven innocent)"
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.
Can't you change the domain? If you want to work within any project, enterprise or open source, you have to obey their rules. If you do not like to do that, you do not have to work with them.
> Think about that.
I thought and I do not think this article is anything else but a rant.
24 comments
[ 2.8 ms ] story [ 44.6 ms ] threadAfter 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
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.
> 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?
> 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".
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'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?
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.
> Think about that.
I thought and I do not think this article is anything else but a rant.