Nope. I believe people should carry more dignity than that.

Holds true for most of what this guy said, save a few things.

If you want to keep everything inside a singular Nix configuration while still using Docker, you can check out the NixOS option virtualisation.oci-containers - essentially, a declarative way of managing docker/podman containers (similar to docker-compose) but with Nix.

You could host on Gitea and mirror to GitHub. Obviously, users may be less inclined to sign up to your Gitea instance, but I hope people being unwilling to register becomes less of an issue once Forgejo (Gitea fork) implements forge federation.

I hope this changes (even if a little bit) once Forgejo (FLOSS Gitea fork) adds forge federation.

I’m not sure - conduwuit does seem to have more active development but it’s not as though conduit is dead either…I also can’t find any other reasons to use conduwuit mentioned on its repository, so I’m just going to stick to conduit.

I’ve been using Conduit within a docker container for a while now, and it’s worked pretty well aside from the mautrix-signal bridge (this was fixed in version v7.0.0, I think). Other than conduit, I tried out dendrite, but the latency in sending messages was unbearable.

I’ve previously had issues with Matrix being incredibly slow and unreliable with federation (I’m self-hosting). However, that’s pretty much in the past now and I seem to have somehow resolved that issue.

I’d just like to add that you can use a temporary phone number service to sign up to Signal as you only need a phone number to register, not to actually use Signal.

deleted by creator

Or you can use a doas implementation like OpenDoas, or maybe sudo-rs…

This is a pretty good option, though I also think something like what aseprite has done is pretty good too (compile it yourself for free, or pay for a precompiled binary available through e.g. Steam) - from what I can tell this setup is fairly profitable.

KVM runs VMs pretty much like they are native

Well, it is a type 1 hypervisor…

Well, I’m not sure how many lines of C rm is written in but I think that rm being only around 4kb (iirc) is something to consider.

But still, storage probably matters least in this day and age. Oh, and…

something I used to completely nuke my home server

If I’m reading this right, then I hope you had backups ready :)

Absolutely.

Well, in all seriousness, I don’t think so. But I do think that Rust rewrites are generally good since they usually end up producing a higher-quality program which is significantly faster (this is pretty important to me).

Of course, there’s no point rewriting everything in Rust, since Rust’s benefits obviously don’t apply to anything.

I think one of the best things about Rust is that it can be used to write basically anything (at least, this is what the extent of the Rust ecosystem leads me to believe), from web apps and CLI tools to, I don’t know, kernels. That’s probably why there are so many Rust rewrites. People actually do write a variety of programs in Rust, and from what I can tell said variety is way bigger than in most other languages.

Nah, no way. :)

This probably isn’t the answer you’re looking for, but vpr being memory-safe isn’t a benefit that it has over rm, since rm apparently doesn’t allocate any memory (as @radiant_bloom@lemm.ee wrote).

the first thing you mentioned as a benefit was memory safety.

Looks like I worded my project description poorly. As I wrote in another comment, I meant that this alternative is memory-safe (being written in safe Rust), but not that rm isn’t.

edit: I’ve updated the post’s title to clear things up

I guess vpr -x would be memory-safe that way then. ;)

I don’t know whether rm is memory-safe or not, but vpr is. By ‘memory-safe alternative’ I meant that this alternative is memory-safe, but not that rm isn’t.

Matrix/Element isn’t an alternative.

Why not?

And, what about Revolt?