I’m not the biggest distrohopper but I have tried a few, both on my laptop and desktop. I still keep windows around on a dual-boot but I’m basically only using it for the odd game or two and also onenote (obsidian + excalidraw comes close but nothing really has a seamless transition between pen and typing text like OneNote)

Early 2018 and before:

Windows only

2018-19:

• Ubuntu 18.04 (desktop),
• Ubuntu 18.04/18.10/19.04 (laptop)

2019-2022:

• Manjaro w/ KDE (desktop),
• Arch Linux w/ GNOME (laptop)

2022-2023:

• NixOS (laptop, for literally a day because it didn’t have a package I needed to make my laptop work correctly)
• EndeavourOS (kde on laptop, qtile on desktop)

2024:

• No changes to the desktop setup,
• NixOS w/ KDE and also a half-functioning hyprland setup on the laptop now that the package got added.

Future?

Maybe if I can get my NixOS config to a point where I’m happy with it I’ll switch my desktop setup to that as well, in theory it should be pretty painless since i’m already using a flake setup split across multiple modules. I do really like that I can experiment with my setup without the risk of actually breaking anything since NixOS is semi-immutable.

If I don’t stick with NixOS I’ve also been thinking about trying fedora, opensuse, or an immutable distro, or otherwise just moving my laptop back to either Arch or EndeavourOS since that’s what I’m familiar with.

It’s also worth noting I’ve recently been seeing a lot of Linux posts from people who just switched, this was somewhat of a trend on Reddit as well but imo the Linux posting has gotten noticeably less toxic toward newer users and a lot more understanding of the “using Linux without wanting to spend hours configuring everything” perspective.

Side point that’s somewhat related to that: I wonder how the growth of other platforms FOSS platforms like Lemmy, Mastodon, Matrix, etc. has impacted Linux project development. Not sure if it’s just me but it seems like it’s helped a lot with making Linux communities more accessible.

If the fediverse is so cool how come there’s no fediverse 2 huh???

I don’t think anyone’s against the idea of it getting delayed, rather they’re making fun of the fact that Boeing has a pretty bad history with safety (and the whole “multiple whistleblowers dying” part) and every time they are about to launch some other critical problem shows up.

Personally I’d love to see Boeing have a safe, successful launch but as things are right now it looks increasingly like NASA’s contract with them won’t show expected results. I’m not going to pretend to be a safety expert so I obviously trust the people doing launch inspections over my own judgement, but I’m not exaggerating when I trust Boeing’s rocket to be safe about as much as I would trust the next OceanGate submarine.

How long some company like Nintendo uses this to justify taking mods down?

If you’re worried about using the terminal you could always install one of the frontends for pacman like the one Manjaro uses. Manjaro might be a pain if you’re using AUR packages (really depends on what packages you use, some niche ones like specific game modloaders or the professional JetBrains IDEs are only on the AUR) because Manjaro’s repos are delayed by around 2 weeks, but the AUR isn’t delayed at all. Depending on the packages you’re using that could break updates sometimes.

Depending on how familiar with programming you are you could also try NixOS which has an absurd number of packages in their official repo but NixOS’s config files can be kind of a pain sometimes.

Edit:

It’s also worth noting that you could start off with Manjaro and then jump over to something like EndeavourOS/Arch once you get more familiarized with using the terminal down the line. That way you wouldn’t have to relearn commands/setups when you switch, since they’re ultimately all arch-based and have the same underlying structure.

Pretty sure that’s a joke, Mali’s TLD is .ml

A lot of android apps are built using Java/Kotlin, so you don’t actually need to care about architecture since the JVM supports both x86_64 and arm64.

There are exceptions to this though, since some apps need to run native code. Those apps would need some sort of emulation/translation layer for the arm instructions.

They’re all tone indicators, since you can’t communicate voice tone over text.

/s stands for sarcasm, sometimes /srs is used for serious, I’m not too sure what the others stand for but those are the most frequently used from what I’ve seen

I agree with this mostly, but at the same time more powerful hardware lets the devs experiment with more advanced mechanics. For example, ToTK runs pretty hard into switch limitations with its impressive physics. If Nintendo wanted to take that engine even further, they’d likely need a hardware upgrade.

Additionally, more powerful hardware starts putting more demanding mechanics into the realm of possibility for an indie dev team that has neither the time nor the resources to optimize their games at the same level as a big studio.

If anything to me gnome always seemed like some weird mix between macos, android, and chrome OS. That might be the material style theming though.

Not really sure how archinstall factors in since it wasn’t around yet when I first installed, but I love EndeavourOS. I’ve installed arch before, but I really can’t be bothered if I’m just going to end up installing all of the same packages the GUI could give me in less time anyway. Yeah, EndeavourOS is just arch with some small extra packages and a GUI installer, but that’s exactly why I like it.

What makes you think so?

The devs said so. Check r/Suyu, that seems to be where a majority of the updates are being posted. I think there was a link to a pastebin post somewhere there as well.

The SDK mentioned was first party, presumably leaked but I’m not completely sure. And yes, that means it would be present in every other fork as well.

Edit: here are some of the links I’m talking about:

https://www.reddit.com/r/suyu/s/TqSWDlnsGs

https://pastebin.com/6FYdz9Sr

Edit 2: worth noting that the “founder” (as they call themself) still wants to continue on the project but I believe a majority of the devs left.

Edit 3: I found the archive link from someone on the Yuzu team showing they had access to a leaked switch SDK: https://web.archive.org/web/20210114104638/https://twitter.com/Slashiee_/status/1349557173970341890

I don’t know how much of this evidence is real but if any of it is they’re going to have a much harder time finding devs willing to contribute to Suyu, even if development does continue.

Suyu died though. Right now the only actively maintained Yuzu fork is Sudachi, which is only maintained by a single person.

Apparently there was some drama about the Yuzu devs using code which came from a switch SDK as a basis for emulator code, which kind of poisons the whole codebase.

I don’t have any Citra successors installed yet because I still have my modded 3ds (I was only ever using it for specific game mods that don’t work on native consoles).

That being said, I doubt It’s still pretty early and developers have to get familiarized with a complex multi-thousand-line codebase they’ve never worked on before, so actual progress is going to be minimal.

That’s the thing though, because it’s kind of a paradox. If you had a single team working on it, then sure, it might be easier to just learn Rust. However, on an open source project, especially a volunteer driven one, that isn’t necessarylily the case. Your average enterprise dev probably isn’t even considering rust as an option yet, because it’s still in early stages in terms of tooling and support infrastructure.

I made another comment in this post, but as it is right now languages like Java and C# make up significantly more projects/job positions than rust. If you want to get more contribution from volunteer devs, it needs to be in a language that devs are comfortable with. Most people won’t want to learn a whole new programming language for a volunteer project when they’re already working a full-time job in a different language. I explained this in the other post, but that’s why I think having both projects is still beneficial. Sublinks and Lemmy can (hopefully) continue to exist at the same time and benefit from each other’s development, especially if they stay API compatible. Sublinks will have a lower barrier to entry (thus maybe a quicker development cycle with more people involved), while Lemmy will help contribute to the validation of rust as a language for production code.

Also “rust is the future” implies that’s the only programming language that is worth learning, which is simply not the case. Different languages are better at different things. There will never be a single language that’s best at everything. Even for a specific task, multiple languages are good at doing the same thing. For example, Go, Rust, C#/any .NET, and Java/any JRE can all do REST services like Lemmy pretty well. Of those, I wouldn’t even say Rust is the best choice, because its frameworks are all still pretty new.

Other languages are growing and evolving as well. Even old languages like Java and C++ have had significant improvements in their modern standards (Java records, C++ smart pointers, etc.). Hell, even COBOL got a new standard version as of 2023 (if I had to guess, this didn’t do much for it though). Just because certain languages are bad right now doesn’t mean they will stay bad forever.

There’s also lemonade, which is prioritizing android compatibility but also looking to get desktop working at some point.

Lime3ds seemed a bit off-putting to me since the owner of the repo didn’t actually have any experience with software/emulation development (I think they were a Linux/FOSS YouTuber), but idk how that has changed/if there are other people maintaining it now

Thanks for the explanation! I didn’t realize it was mostly a maintenance limitation, I thought maybe 32-bit instructions could be an extra attack vector on a physical CPU instruction level or something like that.

Isn’t supporting 32-bit apps on a 64-bit OS a security concern though? I thought that’s why some linux distros were disabling 32-bit repositories by default on their 64-bit versions

Sorry for being unclear, I wasn’t trying to say language doesn’t make a difference (e.g. static vs. dynamic typing would make a big difference). I also personally like the error handling of rust a lot more, even if it does take a bit getting used to when my education has mostly been in languages with Java-style exception handling.

I mostly meant that the language-level performance and features aren’t necessarily holding the codebase back in a debate between Java and Rust for a lemmy-like REST API. As long as the developers are aware of the pitfalls of Java (null, mutation, error-handling, etc.), it’s possible to have good code.

I just think that from a maintainability standpoint, a Java-style codebase is much easier for most people to read, understand, and maintain because that’s what most people are familiar with. Especially when many of the developers are volunteer contributors, that type of thing could make a big difference.

The main problem with Rust is that it’s only starting to get adoption now, it isn’t taught in most education curriculums, and it’s industry use is pretty small at the moment. It’s kind of a catch-22, because rust adoption won’t increase unless large projects like lemmy exist. But that’s also why I think having more options is also fine. Sublinks might get more developers short term because of its language, but that also doesn’t mean it’ll completely replace Lemmy. Both projects can exist at the same time, and hopefully benefit from each other’s development.