Rate-limiting could also be applied at the federation level, but I'm less sure of what the implementation would look like. Requiring filters on a per-account basis might be resource intensive.
It seems irrelevant whether this person is using encrypted channels if they failed to maintain anonymity. If they distributed material and leaked any identifying info (e.g. IP address), then it would be trivial for investigators or CIs to track them down.
Apparently it's hard to get hired in software. Meanwhile, some of the worst software ever made is being written today. Have you tried using literally any software recently? We're in this "barely good enough to function while being heavily supplemented by tech support" phase. I guess capitalism breeds incompetence as long as it's still profitable?
Sounds like Kubuntu's fault to me. If they provide the desktop environment, shouldn't they be the ones making it play nice with the Linux scheduler? Linux is configurable enough to support real-time scheduling.
FWIW I run NixOS and I've never experienced lag while compiling Rust code.
I've been using NixOS for almost a year. The learning curve is aggressive and the learning resources are not exactly friendly to beginners. I'd even say the tooling is poorly designed or at least seemingly redundant at times. You sorta have to grind through it. It was painful for me too, but I feel like I mostly get what I'm doing now.
If you're interested in diving deep, I suggest trying to write a Nix derivation for some software you use that isn't already available on NixPkgs. That was a good learning experience for me.
+1 to the people saying to start off using flakes for everything.
And you are yet to present a single upside, if there is even one.
This is a flippant statement, honestly, as it disregards the premise of the discussion. It's memory safety. That's the upside. The author even linked to memory safety bugs in OpenSSL. They might still exist elsewhere. (I realize there is a narrow class of memory bugs that C compilers understand, but it's just that, a narrow class). We have scant way of knowing whether or not they exist without significant testing effort that is not likely to happen. And it would be fighting a losing battle anyway, because someone is writing new C code to maintain these legacy systems.
C compilers can't tell you if your code has data races. That is one of the major selling points of Rust. How can the author claim that these features already exist in C compilers when they simply don't?
Rate-limiting could also be applied at the federation level, but I'm less sure of what the implementation would look like. Requiring filters on a per-account basis might be resource intensive.