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

Neovim does not mandate disclosure of AI usage, so it'll have to be hard fork if the developers intend to have no AI in viq. Otherwise it'll just be Neovim with a bit less AI in it

Yes. I'd argue that this is similar in spirit to the linked proposal, which for example requires that

Nobody in KDE should know if you use an LLM — not because you're concealing it, but because your usage of it produces output indistinguishable from what you could produce yourself. Contributions with obvious and lazy LLM usage may be ignored or closed.

That person seems to be mistaken. I could only find policies for GNOME Circle and extensions, and those seem similar in spirit to the one proposed here:

• https://gitlab.gnome.org/Teams/Releng/AppOrganization/-/blob/main/AppCriteria.md#circle-app-criteria
• https://gjs.guide/extensions/review-guidelines/review-guidelines.html?ref=itsfoss.com#extensions-must-not-be-ai-generated

Starting a fork is easy, but who is gonna maintain it? KDE is huge, at 8 million lines of code for the core software, so you'll need a large amount of people who are willing to work on the fork to keep parity with KDE