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.

I know I’m late to this but here’s my (probably insane?) take. We use Subject-Verb-Object in English right? So, hear me out:

dialog_create_tab(...)
dialog_open_file(...)
dialog_close_file(...)

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

The least expensive MacBook is still $1000, closer to $1500 if you spec it with reasonable storage/ram. It really isn’t that much of a stretch to add $100-300 for a 1080/1440p monitor or two at a desk.

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 think blocking downvotes is an option built into Lemmy servers that can be communicated through the API. I know there are a decent amount of instances that don’t federate downvotes because of toxicity concerns.

In the grand scheme of things the difference between C, C++, and Python isn’t meaningful when operating over a network (edit: for a single-user system). It’s very likely that the difference for thread OP is just caused by weaker connections to specific repos.

We’re talking about a package manager, not a game, network server, etc. On a basic level the package manager only needs to download files from a network and install them (OS syscalls for reading/writing files, these are exposed C functions or assembly routines), or delegate to a specific package’s build setup (which will also likely be written in a compiled language)

That’s partially my point. You can never be 100% safe, but there’s a lot you can do to increase your safety besides just relying on intuition (edit: because intuition is usually the weakest link, see social engineering/phishing tactics). Anti viruses (when they aren’t just bloatware) are part of that.

Your second point about not meaningfully defending against backdoors and vulnerabilities is kind of against the point. You can totally defend against backdoors by not giving apps admin privileges, limiting network access, etc. so that damage can be limited even if an exploit happens. Then, if some backdoor or exploit is discovered, it’s only as dangerous as the permissions you give that app.

Linux gets viruses too (see recent xz-utils vulnerability that almost got into production environments) and its kind of a shame that corporate antivirus software like Norton and McAfee end up ruining the reputation of antiviruses. In theory the idea of having a software that can scan for common viruses is a great way to increase security, even if it shouldn’t replace common sense. I’m not too sure if there are any good FOSS antiviruses, but if there aren’t there should be.

Me during my exams this week

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.

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.

I love not having downvotes federated 😎

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

A lot of people here seem to think that Java code is awful and disgusting and no projects should ever use it. The thing about popular languages is that more code existing in a language inevitably means a lot of it ends up being bad. The same thing will likely happen to rust as it gets popular, but that isn’t exactly a problem. It’s possible to have a well-maintained Java codebase.

Debate between functionality of the actual programming languages at this point is pretty meaningless, if they have good development standards then a Java program could end up just as well maintained as rust. Any time saved by compiler enforcement of specific standards (like no using null) would be lost by the fact that the devs don’t know rust tooling. You could just have a requirement in PRs that null isn’t used. Both Java and Rust have usable frameworks for REST API development, so using one or the other comes down to familiarity.

The idea that programming languages make code suddenly good or bad is pretty silly. Different languages have different language-level guarantees which can help produce good or working code. That being said, it’s not like it’s impossible to write good Java code, just like it’s not impossible to write bad rust code. Most people seem to be conflating guaranteed functionality and safety with maintainability, stability, and readability. Rust is still a new language, so although it’s great, Java will probably be the better choice for the latter 3 qualities.

That being said, something like Kotlin would probably have been a better starting point since it can interact with Java (and works like Java in most cases) but also has some nice improvements like stricter null checking (Kotlin nulls are treated similarly to rust’s Option<T>, it’s just described as T? instead and the syntax is generally a lot more concise). There’s also the benefit of being able to write some code in Kotlin and some in Java since they are mostly cross-compatible.

I think they mentioned in another comment, but sublinks is developed in Java, so the .world team would be able to contribute more to the actual development/testing process (edit: since they aren’t familiar with rust).

Pretty sure the dev mentioned they were going to release the source code as well, so it won’t really be proprietary anymore. Either way I still prefer melonDS but at least there are options

True, I’m more worried about Citra since interest has kind of died down for that project. I’m kind of hoping some forks show up soon that get popular enough to be put onto a package manager since there aren’t many alternatives with the same compatibility/performance (from what I can tell Panda3ds isn’t very stable yet)