Those can all be separate partitions on any Linux system. But defaults matter, and if the defaults are insecure then you can expect most systems to be insecure

XFS is the default filesystem for RHE, and while I believe that /tmp is a tmpfs on RHE and should therefore be safe, it is my understanding that /var/tmp needs to be accessible on boot and is therefore typically on the root FS. EDIT: Can confirm for the RHE server I have access to, that this is the case

Those root privileges being able to edit a root-owned file if it’s in a directory that allows writes by all users. How common is that?

The file doesn't need to be in a world-writable directory, there just needs to be a (world-)writable directory on the same partition, such as /tmp on the root partition. The attacker then uses a XFS specific feature (reflink) to create a clone of the target file (e.g. /etc/passwd) in the writable directory, and then they can modify the content of the target file via their clone due to the race-condition

The advisory has a more detailed description: https://cdn2.qualys.com/advisory/2026/07/22/RefluXFS.txt

Other git hosts are also getting scraped, and have had to implement counters because of it. For example, this is the kind of thing Codeberg shows crawlers. I've even seen people who self-host complaining about getting overloaded because of bots scraping their forge

For me, and a few other projects I checked, it only has non-GPL repos. But it also does not have everything that isn't GPL, despite the repos being much older than the cut-off date. But it does have repos without a license, which they are simply not allowed to copy.

I wonder if those repos have been deduplicated, and one of the forks (on some other person's account) is included instead. Unfortunately you can only search the first 5M records via the website, and I don't have time to play around with the API at the moment, so I could neither confirm nor deny that possibility

If nobody owns the code, then then nobody can enforce the terms of the license it was released under, and free software under the FSF definition becomes impossible. All you have is public domain.

For example, a company could take the Linux kernel, modify it and distribute it with their gadgets. And they could simply not release the modifications they've made, as is required by the GNU Public License. But nobody would be able to do anything about it. Currently, copyright laws allow the people who wrote the Linux kernel to sue the company for breaking the license and violating the authors' copyrights

That really ought to have been the default behavior. Opting out only takes one or two extra characters. Well, three or four if you don't habitually bracket your variable names, which you should probably be doing anyways

Neither of those terms seem problematic to me; a plain reading would be "mostly" means more than half of the code, and "tolerated" would mean that the ban is not enforced on such projects. Of course, if you are already operating under the assumption that Codeberg is acting in bad faith, then it doesn't matter what the terms of service says nor how they they might say that they interpret them.

It is, however, not surprising that their terms of service are subject to interpretation. That was already the case before they added these particular terms. For example, the Codeberg TOS already included a prohibition against "content that harms the reputation of Codeberg" before the recent changes. Codeberg simply added projects related to cryptocurrency as an example, when the ban was voted through. It is furthermore the case that most, if not all, terms of service are subject to interpretation. We are talking about documents describing human behavior, not machine code.

If this kind of thing is not acceptable to you, then your only real solution is to self-host

Banning "AI" is too broad and too shortsighted.

They haven't done that. The actual terms are

You must not share projects that mostly consist of code written by "generative AI"-tools (including services such as Claude, OpenAI Codex). Such projects having an unclear copyright status (see requirements § 2 (1) 1 and § 2 (1) 3) and furthermore have little safeguards to ensure that they do not include harmful code (c.f. § 2 (1) 5).

See also their blog post, where they specifically mentions experiments as "tolerated":

Side projects and experiments with little resource usage

Rust has no Undefined Behaviour.

That is simply not true. See here for a list of behavior that is considered undefined in Rust: https://doc.rust-lang.org/reference/behavior-considered-undefined.html

However, most (all?) of these require the use of unsafe, which helps narrow down where the problem might be, if you trigger any of this behavior

I'm well aware how short 100ms really is and it is very obvious if your inputs are off by 100ms or more; rhythm games are rarely that strict, but I've also played games where some inputs had to be timed to within 1/60th of a second (~16.7ms)

But the results… calling something “bad” for 3ms of latency is a bit ridiculous. That’s only significant to a cat, to us larger meat sacks 100ms would be blazing fast reaction speed, making 3ms negligible. For an average person it means even less.

You are conflating reaction time and response time. They are very different things.

Yes, your reaction time is in the 100s of miliseconds, but it doesn't take much of a delay in the response to your reaction before it becomes perceivable, and the response time is what was measured here.

If you have ever played rhythm games, then you may be aware that some of them have settings that allow you to offset the delay, such that your pressing a button at the exact same time as the note plays is also registered as happening at that time, even though it took some additional time for the input to reach the game. Without such a setting, you intentionally have to press buttons early (how much depends on your setup) to ensure that your input registers at the right time. A delay of 100ms would be extremely obvious