zygo_histo_morpheus

If you're contributing to a larger project, it might not be trivial to modify the .gitignore file, because you might have to go through a review process and so on. It might be easier to just ignore something locally.

If you want to break out of the windows mold, tiling windows managers are where its at. You've already explored that route with i3, and there are other alternatives, but they all have a bit of a learning curve unfortunately. hyprland might be worth a try. I've only dabbled but I did remember it being a bit more beginner friendly than i3. But be prepared to be confused, read a bunch of forum posts and edit config files for a bit.

Sure, but my point is that you'll end up with one "main" remote where you have all git forge stuff even if you push to multiple remotes. By all means, don't make github the main one!

For git itself sure, but all the other things that come with a git forge, like issue management, are probably things that you don't want spread out over multiple websites

There's a lot here that I could comment on, but I'm particularly fascinated that you make a big deal about const by default.

First of all, it's not particularly good evidence that rust is functional, you could just as easily have a const-by-default java or c. Rust still has mutable data structures which is decidedly non-functional. I do actually think that rust is more inspired by fp than a lot of other languages so it's not even that you're completely wrong here, it's just an odd example.

Secondly, do you actually think that const variables is a bad default? Personally I find that it makes it code easier to read when the author is explicit that a variable is going to be mutated down the line because it makes the intention clearer. It also makes it easier for the compiler to make certain optimizations which is significant in a low-level language.

Caring about the syntax of a programming language is a sign that you haven't properly engaged with it. While not completely unimportant, what matters at the end of the day is the languages semantics. If you program in rust for more than 'a few hours' you will stop thinking about the syntax directly. Trust me, I do a fair bit of work in the cmake language, you can learn to work with any syntax.

Is the decompiled code guaranteed to be equivalent to the compiled code? While this might be cool it doesn't seem that useful if you can't reason about the correctness of the output. I skimmed the README and didn't manage to figure it out

Comments can become outdated, but so can variable and function names. "Self-documenting" code often relies on appropriate naming, yet this is also subject to rot as the code develops.

Actually this is trivial to circumvent if you self-host: you can run your own PDS (personal data storage) and just say that you're over 18

While jellyfin itself is very simple, you might run in to problems if you want to use it while not on your home network. For this you're either wanna use a VPN (or tailscale) or use something like nginx to give your server a web address, while you get this for free if you use plex.

Giving yourself a public address might be easier for the person trying to access jellyfin, but it it comes with a bunch of security considerations and you probably (definetly) want to do some research on the inns and outs of that. I would recommend tailscale but either way it's gonna be some extra fiddling, unless you already have something like that set up.

You can tailor the rust standard library to be more embedded friendly in several way, like if you don't have dynamic memory allocation or a filesystem, you can get the standard library sans those features.

Rust also gives you a very fine grained level of control of memory, I think equivalent to C (maybe there's some gotcha that I'm not aware of but if not equivalent very close).

It really doesn't sound like you know that much about Rust here and are just making things up, you certainly don't need "gigabytes of storage and memory"