I get it that the project isn't getting work done on features, but it bothers me how the author tried to criticize basic code quality improvements such as fixing typos. I don't know if the author is an active contributor to the project, but I think he shouldn't really be criticizing the ones that actually contribute, wether their contributions are big or small.
I think it is common knowledge by now that the kernel community is a rather toxic space where abuse and elitism are the norm rather than the exception.
Even in the blog post's very one-sided account of the issue, there isn't even a hint of elitism or toxic behavior. There was a bug report, the reporter submitted a patch, the patch was faulty and unusable, and the maintainer stepped in to put together a working fix. That's it.
I don’t think it’s a stupid thing to want to have code in the kernel, especially after spending all my time debugging this issue.
The way that you jumped straight onto broadcasting drama when your very first Linux kernel patch stumbled on the code review stage is a major red flag.
I would hate to work with you because I would feel that I would be risking being subjected to a very public character attack each time I had to review one of your patches.
But the help and credit he got for days or weeks of unpaid work was basically nothing.
We should keep in mind that this is a one-sided account on how a mundane bugfix issue was handled. Grain of salt required.
Nevertheless, the blog author said he received feedback from members of the Linux kernel security mailing list. Even though I think he could have received more credit than reporting the issue, that was basically his contribution: he pinpointed where the bug was. He also contributed a couple of patches that were faulty and unusable, and the maintainer had to step in and roll out his own fix.
I understand that fixing a nontrivial bug is a badge of honor, and getting credit for critical contributions might have more implications than a warm feeling. However, if the submitted patches were unusable then what would be the desirable outcome? I mean, should Linux users be deprived of a bug fix because a first-timr contributor is struggling with putting together a working patch?
Whew, here I was thinking it might be cool to try to contribute to some project, maybe even Linux! This thread shall serve as my reminder to never do that because that’s for god-tier emotionless techbros only.
I've stumbled upon this blog post first in HackerNews, and the comments there make it quite clear that, even though it wouldn't hurt to give more credit than merely reporting a bug, the author's submission was flawed and subpar, and the rewrite that went in was undoubtedly better in every way.
I don't think all this drama is waranted or justifiable. Also, if the first whiff of adversity bothers you and any feedback in a PR other than enthusiastic praise leaves you with a sour taste then collaborative work might not be for you, both as a participant and as someoje that everyone else has to endure.
I was expecting a huge CICD pipeline with delivery steps automatically publishing packages for Debian Unstable and Debian Testing, but it turns out it's a relatively simple pipeline with straight-forward build and testing stages.
Less is definitely more, and targeting Debian alone does greatly simplify a pipeline, but somehow I was expecting more automation taking care of the whole workflow.
A more apt description would be "Fossil Versus Git, according to Fossil."
Which is what putting most of this stuff on the background accomplishes.
The part you're missing entirely is the complexity that's hidden behind the weasel word "most".
The majority of event handlers from a GUI app do not do anything complex, computationally expensive, or blocking. They do things like setting flags, trigger changes in the UI state (i.e., show/hide/update widgets) bump counters, etc.
No one in their right mind would ever consider going through the trouble of doing this stuff in separate threads/processes. "Most" handlers run perfectly fine on the main thread.
Nevertheless software changes, and today's onClick handler that sets a flag to true/false tomorrow is required to emit a metric event or switch a different treatment depending on the state of a feature flag or A/B test, or is required to write a setting to disk or something like that.
How do you draw the line in the sand that tells whether this handler should run on the main thread, should trigger a fire-and-forget background task, or should be covered by a dedicated userflow with a complete story board?
That's the stuff that's hand-waved away with weasel words like "most".
This blog post delivers a crisp mental model to tell which approach is suitable: follow the real time computing rulebook, acknowledge that each and every handler has a time budget, and if a handler overspends it's budget them it needs to be refactored.
The article is not talking about async processing. It’s talking about the process scheduler and thread blocking.
No, not really.
The article doesn't even cover process scheduling at all. The whole point of the article, which is immediately obvious to anyone who ever worked on a GUI, is what code runs on event handlers and how doing too much in them has a noticeable detrimental impact on user experience (i.e., blocks the main thread).
It's also obvious to anyone who ever worked on a GUI that you free the main thread of these problems by refactoring the application to run some or all code in a problematic handler asynchronously.
The problem with the article is that it’s confusing hard realtime and low latency requirements. Most UIs do not require hard realtime, even soft realtime is a nice to have and users will tolerate some latency.
I don't think that's a valid take from the article.
The whole point of the article is that if a handler from a GUI application runs for too long then the application will noticeably block and degrade the user experience.
The real time mindset is critical to be mindful of this failure mode: handlers should have a time budget (compute, waiting dor IO, etc), beyond which the user experience degrades.
The whole point is that GUI applications, just like real-time applications, must be designed with these execution budgets in mind, and once they are not met them the application needs to be redesigned avoid these issues.
Interesting viewpoint, but I think the applications aren’t at fault: The operating system should ensure that the user has control of the computer at all times.
The whole point us that the OS does ensure that the user has control of the computer, at least as far as a time-sharing system goes. The problem is that the user (or the software they run) often runs code on the main thread that blocks it.
The real-time mentality towards constraints on how much can be executed by a handler is critical to avoid these issues, and it should drive the decision on whether to keep running a handler on the main thread or get it to trigger an async call.
The shit storm he brew up in response to getting feedback on his very first pull request is way more concerning than churning out low-quality code.
Coding skills can be improved, specially from the first pull request onward. Toxic behavior such as putting up very public smear campaigns in response to getting feedback on his very first patch submission is a major red flag, and is as toxic as it gets.