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

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"

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

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

There’s also https://noailist.org/, which is based on projects (not just OSS) committing to not using AI. That’s probably also the only viable approach, if you want a list of projects without AI stuff, since projects can easily be using AI without it being visible to third parties inspecting the output of the projects

Having an public policy that permits the use of LLMs feels like the opposite of “hiding it”. If a project has such a policy, then you can be pretty sure that LLMs are being used, even if you cannot tell exactly what commits involved the use of LLMs. It’s probably also a lot more discoverable than disclosures in commits or PRs, which most users wouldn’t know how to look for

Thanks, fixed the typo, lol

Zellic did not write uutils/coreutils, they audited them. That is to say that they reviewed the existing source code and reported the issues they found.

Besides that, the first release of uutils/coreutils was back in April, 2020: https://github.com/uutils/coreutils/releases/tag/0.0.1

I am not familiar with Zellic, but given the popularity of Rust in the crypto space, I am also not surprised that a company that audits Rust code has ties to crypto

They released 3.2.6 on the 10th per the blog post.

Which, given the size and complexity of GIMP, likely means that they were already in the process of wapping it up by the time OP made this post

I meant that OP was quoting themself. I’d be rather surprised if they have anything to do with the GIMP project

I think they are quoting themselves. I’m fairly sure they’ve posted this exact thing before, for other versions of GIMP

When did Anthropic make Claude Code a separate subscription? I ask because it is still listed as part of the Pro subscription tier on their website. And because I haven’t seen the shit-storm that would no doubt ensue if they did that

The two last code examples are identical, which would seem to be a mistake

I’ve been using “oldoldstable” as my cutoff for backwards compatibility in several pieces of software I’ve released. I guess I gotta decide if I start bumping dependencies now or if I wait for the Bookworm to become “oldoldstable” in 2027

None of the proposals would have banned AI usage in upstream projects, but banning AI usage in the context of the Debian project was on the table

None of the proposals would have banned AI usage in upstream projects:

https://www.debian.org/vote/2026/vote_002

Looks like Bun 1.4 is out now: https://bun.com/blog/bun-v1.4

This breaks down when there are more than one SOURCE file, since each DESTINATION file depends on all source files. This means that $< will always be the first file in SOURCE. For example, if source contains the files 0001-01-01-some-file-name.md and 0002-02-02-some-file-name.md:

$ make -n
mkdir -p destination/0001/01/01/  
/bin/bash ./myscript.sh source/0001-01-01-some-file-name.md > destination/0001/01/01/some-file-name.md  
mkdir -p destination/0002/02/02/  
/bin/bash ./myscript.sh source/0001-01-01-some-file-name.md > destination/0002/02/02/some-file-name.md  

OP is probably better off using a scripting language to automate this kind of thing

EDIT: Fixed example filenames

If you mean the “Sign in” button on the top right, then yeah, I’ve just been staunchly ignoring that. But it turns out that there’s also toggle to remove it, so now it’s gone!