I think they’re lawful evil, more devils than demons.

I use Alpine Linux quite a bit, which is a Linux distro that doesn’t use the GNU coreutils or glibc.

Also even giving GNU such a high level in the name on a distro like Arch makes little sense imo because other components like systemd are arguably much more important than one of many libc libraries you can optionally use and a bunch of coreutils you can also optionally use.

In my experience I haven’t had an issue because usually the refactorings are small. If they’re not I just hop on a call with the person who wrote the MR and ask them to walk me through it.

In theory I’d like to have time to dedicate solely to code health, but that’s not quite the situation in basically any team I’ve been in.

You should refactor as needed as you go because refactoring cases are never gonna be prioritised.

There’s a markdown entry thing in the drop down menu that’ll convert your MD to their formatting.

I attempted to boot Mandrake/Mandrivia on an old laptop once and failed, then I mucked around in Slackware’s live CD for an afternoon. The first thing I actually installed and used daily was Ubuntu 10.04.

Rust is roughly similar to C in most of these benchmarks and beats it in a few: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust.html

Arguably when LLVM gets a bit better, Rust can be even faster than C because rust can be optimised in more places safely than C code can. The issue is that LLVM wasn’t written with that in mind, so some performance is left on the table.

Go, Java, and Nim (in most cases) are all memory safe but are generally slower than C or C++ due to the ways they achieve memory safety.

Rust’s memory safety approach is zero-cost performance wise, which makes it practical for low level, high throughput, and low latency applications.

That flag exists, it’s called unsafe for if you need to tell the borrow checker to trust you or unwrap if you don’t want to deal with handling errors on most ADTs.

You can always cast anything to an unmanaged pointer type and use it in unsafe code.

A crash is different to a SEGFAULT. I’d be very surprised to see a safe rust program segfault unless it was actively exploiting a compiler bug.

Gotta be honest, as a dev I tried to make a Flatpack of my app and gave up. Making a snap was much easier. Of course, I also offer it as a .deb, .rpm, Pacman package, etc. too

True, you’re correct. I’m just not sure how you did it without corrupting the sled db. Maybe I’m just unlucky

Interesting, when I tried a while back it broke all images (not visible on the website due to service worker caching but visible if you put any pictrs url into postman or something)

I wrote a patch for Lemmy a week or so ago if you want to skip the caching: https://github.com/LemmyNet/lemmy/pull/3897

I think deleting images from the pictrs storage can corrupt the pictrs sled db so I would not advise it, you should go via the purge endpoint on the pictrs API.

Just a note that my PR there doesn’t disable pictrs for your own instance’s users. It just disables the caching of remote content.

The Lemmy instance I’m speaking from right now is running in my k8s cluster.

I ran this query:

select distinct thumbnail_url as url from post where not local and thumbnail_url like 'https://campfyre.nickwebster.dev/pictrs%'

(replace with your instance’s url)

I then sent delete requests to /internal/purge on pictrs to delete all of those old thumbnails, which cleared out a lot of space. After deleting the thumbnails I ran an UPDATE query to set all of those old thumbnail URLs to null in the DB. I also patched the version of lemmy that I run to stop caching thumbnails in the future. Hope this helps!

Oh wow, this is tragic

I have a few but my main one is https://nick.geek.nz followed by https://nickwebster.dev which currently just had a redirect, some email stuff, and this Lemmy instance.