The link I posted is to the Curl maintainer's own blog, in which he wrote a follow-up to his earlier post about shutting down their bug bounty program. See also this more recent blog post by the maintainer of Curl, in which he writes that
I personally don’t refer to [vulnerability reports created with the help of AIs] as AI slop because the reports are typically accurate and correct, even if much too wordy. I think “slop” implies that it is wrong, misleading or otherwise bad content.
According to the lead Curl developer, the quality of LLM generated reports has gone up quite a lot, to the point where the number of high quality reports is the problem, rather than the number of slop reports: https://daniel.haxx.se/blog/2026/04/22/high-quality-chaos/
However, I doubt that their bug bounty program is ever coming back. As you say, that'll just attract the people looking for a quick buck, and those are unlikely to care about the quality of their reports
Thank you for the answer!
I have not previously heard Meson described as a reinvention of Cmake or a CMake clone, nor that it was meant to be. I would think that Meson being as opinionated as it is, including for example the fact that it does not and will not support user-defined functions, precludes it from being a CMake clone. It seems instead to be a build-system with a rather different philosophy and feature-set compared to Cmake. But if that philosophy or that feature-set does not match your needs, then there's obviously no reason to pick it over CMake
Out of curiosity, why do you consider CMake to be the better choice compared to Meson?
Personally I landed on Meson a few years ago, from what I remember chiefly due to simply not liking CMake's DSL and finding Meson easier to work with, despite needing to target a pretty old version for the sake of compatibility. Though Meson is definitely not perfect either; it's highly opinionated, and for example only recently got support for custom build targets putting stuff in sub-directories (as I discovered while writing this comment), so I'll personally be stuck with my workarounds for a good while longer
If you have a couple of hours, and can stomach the AI art, then this video covers a lot of the niceties of C++:
As soon as uv provides an alternative implementation so you can just run
uv run --but-fastI think it will become popular.
You can already do uv run -p pypy and uv run -p graalpy to automatically download and use those versions of Python.
For anyone curious about the number of bugs introduced in each kernel release, LWN.net has a plot of Bugs fixed and introduced in each kernel release.
However, it has the obvious limitation that recent releases will appear to have fewer commits introducing bugs, simply because kernel developers haven't had as much time to find and fix the bugs introduced in those releases. So it'll be a while before we can actually see the consequences (positive or negative) of more widespread LLM usage by kernel developers
I'm just doing my part to reduce global climate change. You're welcome
Recently had to develop a Python project, the tests took at least ten seconds to start each single time. This is while I made over a hundred tests for my module and re-ran them after every change.
Python is dog slow, but if each of your tests are taking 10 seconds to start (not even run!), then something is catastrophically wrong with your setup. For comparison, for one of my projects, it takes a total of 12 seconds to run nox on a clean slate, which involves setting up venvs for five major versions of Python, installing the package and its dependencies in each, and finally running the 1500 test test-suite five times
What about the fact that runtime startup alone auto-disqualifies python for all short-lived process use-cases?
While Python's start-up time is a lot slower than a corresponding compiled program, in most cases it's not slow enough to matter even if the process itself is short-lived:
$ hyperfine 'python3 -c "pass"'
Benchmark 1: python3 -c "pass" (412 runs)
mean ± σ min … max
Wall Time 7.1 ms ± 0.2 ms 6.7 ms … 8.4 ms
Memory 9.4 MiB ± 0.1 MiB 9.1 MiB … 9.5 MiB
If you are running a small program so often that this kind of start-up time matters, then the loop should probably already be implemented in the program itself. In line with the article's thesis
But you really should be writing those tests regardless of whether or not you or an LLM ends up writing the actual code. That helps ensure that the code actually does what you think it does, and prevents bugs or unintended changes in behavior from sneaking in later when something changes
Granted, I’ve seen one or two articles saying that AI helped find real software bugs, but what’s the ratio there, 1:500 for useful/useless AI bug reports?
It's worth distinguishing between LLM generated bug-reports submitted by randos, and developers themselves using LLMs to look for bugs in their software.
My own experience, with my own code-bases, is that the LLM I use is extremely good at finding real flaws in my code. It'll also nitpick a lot, but it has has become better at triaging issues than it used to be, so that kind of thing is easy to ignore.
Because of that, having an LLM take a look at my code before I push it has become another QC step, along with running tests, linters, and formatters. The end result is higher quality software
It was announced back in February, with the reason being that they spend a lot of time simply preparing releases, rather than actually working on improvements to Mint:
Releasing often is important because it means we get a lot of feedback and bug reports when we introduce changes. We follow the same process over and over again. It’s a process that works very well and it produces these incremental improvements release after release. But it takes a lot of time, and it caps our ambition when it comes to development. With a release every six months plus LMDE, we spend more time testing, fixing, and releasing than developing. https://blog.linuxmint.com/?p=4991
The latest blog-post suggests that their new schedule is already paying off:
Going from a 6-month release schedule to a yearly one was a tough decision to make, but we’re really starting to see it pay off. We’re taking on projects and implementing changes which would previously have been considered too large or ambitious. We’ve got time. We don’t feel rushed. Development feels solid and the OS keeps getting better. https://blog.linuxmint.com/?p=5086
I haven't read the paper in dept, but these are deeply unserious reasons for disparaging it.
Bad research is still bad. The main paper is 9 pages with wide margins, outside of references. This was a few college students publishing their CS research assignment
The length of this paper entirely within the norm for scientific publications. In fact, depending on the type of paper, they can be much shorter. For example, Nature expects submissions at around 2500 words or around 4300 words, depending on the format, while this paper is around 4800 words long (excluding references and SI).
The authors also obviously not "a few college students publishing their CS research assignment": Gloaguen, Mündler, Raychev, Müller, and Vechev.
The “Limitations” section is rather telling:
Another interesting avenue opened by this work is how to improve the automatic generation of useful context files.
Okay, so they already admitted that they started with useless context files, which sabotages their own test.
You know how you fix useless context files? You iterate until they are useful context files!
The entire point of the study was to see what kind of context files were useful and which were useless, which according to the authors was not something that had been done before:
A widespread practice in software development is to tailor coding agents to repositories using context files, such as AGENTS.md. Although this practice is strongly encouraged by agent developers, there is currently no rigorous investigation into whether such context files are actually effective for real-world tasks. In this work, we study this question and evaluate coding agents’ task completion performance in two complementary settings
They found that,
while instructions in the context files are well followed by coding agents, repository overviews, although popular and recommended by model providers, are not helpful.
So when you say that they "admitted that they started with useless context files", you are referring to the results of the study. Complaining that they didn't base their study on the conclusions of that very study is just absurd
Always take these stories with a grain of salt.
For example, while the article claims that "we saw Denmark's government move from Windows to Linux back in 2025", the reality is that it was just one department and they didn't even move to Linux. They merely started a pilot project to see if they could move from Office 365 to Collabora: https://www.digmin.dk/digitalisering/nyheder/nyhedsarkiv/2025/jun/digitaliseringsministeriet-saetter-gang-i-pilotprojekt-om-digital-suveraenitet
To add to the last comment, I'd also suggest not mixing logging and business code.
That is to say that you should put the system call on its own line, so that it is clear that it's not just a logging call:
if (!strcmp(platform, "windows") && !isSpecificPlatform) {
debugLog("Falling back to rm -rf", 2);
int result = system(strfmt("rm -rf %s", path));
debugLog(strfmt("rm -rf exited with code %d", result), 3);
}
It may just be a me problem, but I have a tendency to skim over the logging lines unless I'm intentionally reading code carefully, in which case the system call may get overlooked
Without knowing the exact values you entered, I'm guessing that you calculated the number of samples needed to estimate proportion of bisexuals in the population +/- 5%. In other words, your survey with 25 random British individuals would net you an estimate of bisexual Britons in the range 0 to 6%.
In the context of this survey, you need a sample size of about 400 to get a 5% margin of error for the answers from the surveyed bisexual Britons, meaning that if 20% of those 400 British bisexuals answer "yes" to a survey questions, then the actual percentage (i.e. if you literally asked every British bisexual) is expected to be in the range 15% to 25%. YouGov has an article that it explains it better than I can: https://yougov.com/articles/2497-understanding-margin-error
You can call rm safer manner, but you'll need to fork and use one of the execl functions directly. That way you don't have to worry about escaping the path. The old implement would potentially delete unrelated data if the path contained whitespace, and could even execute arbitrary commands, since it essentially runs bash -c "rm -rf $path"
Having uneven sample sizes between populations is not a problem, provided that you have a reasonable number of samples from each population, and provided that you don't do something silly like comparing raw counts. Regardless of sample size you of course also need your samples to be representative of the populations they are drawn from, but that's a basic prerequisite for any meaningful statistics.
The results of this particular survey is presented in percentages, so unless the samples are highly unrepresentative the numbers are not going to change much by increasing the number of gay, lesbian, and bisexual individuals to match the number of straight individuals. You'd just be narrowing the margin of error a bit, but those should already be decent for these sample sizes: https://www.calculator.net/sample-size-calculator.html
This looks like a colossally bad idea:
if (!strcmp(platform, "windows") && !isSpecificPlatform) {
debugLog("Falling back to rm -rf", 2);
debugLog(strfmt("rm -rf exited with code %d",system(strfmt("rm -rf %s", path))), 3);
}
In addition,
However, their even though their client doesn’t allow vibe coding, it is still written in Python, which itself takes ai contributions.
Per the Makefile, this project is built using GCC. GCC itself accepts AI contributions, provided that the code is "legally insignificant" (meaning less than around 15 lines of code) or is part of test cases: https://gcc.gnu.org/ai-policy.html