Quoting: robvvI recently noticed that the suyu gitlab repo has been closed, too. Computers are supposed to be learning and creative tools, and instead we have this walled-garden situation created by greedy companies. Maybe devs should host their repos in countries that are not too bothered about what Nintendo says...

Suyu is still there guys: https://git.suyu.dev/suyu/suyu
The Gitlab one was taken down months ago: https://www.gamingonlinux.com/2024/03/gitlab-takes-down-nintendo-switch-emulator-suyu-due-to-the-dmca/

View this comment - View article - View full comments

F*ck Nintendo.
I still have a copy of the source code btw (not the most up to date but still), what you're gonna do Nintendo?

View this comment - View article - View full comments

Quoting: ExplosiveDiarrhea

Quoting: CyrilI find it awful to say that... Just because some devs did drop it doesn't mean that, when you see a new game with a Linux version, it's already a bad thing come on.

Software written for Windows is superior anyway.

Lol, ok you're just a troll.

View this comment - View article - View full comments

Quoting: ExplosiveDiarrheaNative Linux version? Hmmm, this makes me less likely to buy their game: we all know they will eventually drop/unsupport/lag-behind it...
Now, if they had a *supported* Proton version (whatever that means, I'm not really sure) that would be amazing!

I find it awful to say that... Just because some devs did drop it doesn't mean that, when you see a new game with a Linux version, it's already a bad thing come on. And some devs did drop the Proton Support too, a good support is still good support, either via Proton or native. Some devs do seriously have a good Linux support, thanks to them.

And about these devs particularly, do you have gripes about their Linux version of Project Hospital to say that?

View this comment - View article - View full comments

Quoting: EagleDelta

Quoting: CyrilNeovim is available in Arch-based repos at 0.10.1 version.

That's not an answer. Arch-based distros are not great for every person. I'm not complaining as I've found my way around the problem. My point is that System Packages are just that, they are for the System. The distro maintainers first and foremost are building the System packages based on what is needed to run the OS, NOT based on what users may/may not need.

But I'm not saying Arch-based are great for everybody, that was just an example where in this case the software with the right version is available in repos. From your last post I didn't know what repos specifically you were talking about (repos in general or repos in a particular distro). I read that as a complaint, if it wasn't then OK.

Quoting: EagleDeltaFinally, "Not a distro for you" is irrelevant when you are building software meant to run on all major distros.

It's not irrelevant as I was telling this solely for the neovim thing, nothing else. Neovim is not a dependency of a global software, it's a just a text editor that you need, it's not the same.

Quoting: EagleDeltaEspecially for Server or CLI tools. Sometimes, depending on the project or contribution, you are limited with language choice. For something like Rust or Go, you can usually just build a binary that contains everything needed to run the tool/server, unless it reaches out to a shared C library or uses a Foreign Function Interface (FFI) then you have to make sure that either the system contains the correct version of the library to run. With Server Distros being RHEL/OEL/CentOS Stream/Rocky, Ubuntu, Debian, and SUSE (major ones), none of those distros run the same versions of C, Python, Ruby, Perl, PHP, etc..... which usually means we have to find a repo ourselves, build those languages/libraries from source (pain to manage and removes the benefit of packages managers), package the application with EVERYTHING that it needs, or build a container to run it all.

Usually for an Open Source (or Commercial) software product, this means having to build an RPM for EL-based distros, a DEB for Ubuntu Server, and a Container at least. Sometimes a SUSE RPM and/or a debian-specific DEB package (if the Ubuntu one doesn't work). This is near impossible for most Open Source communities that aren't funded by one or more companies and have to be continually updated due to the rate at which bugs and security vulns are discovered.

I see... but it's still difficult for me to have a clear view about it, like a concrete example (but it's OK), as your explanations are very general for me (and it's the first time I read that kind of stance so I'm surprised).

Quoting: EagleDeltaSo, no, "Not the distro for you" doesn't work for what I'm trying to describe as we usually aren't building for just our laptops.

As I said, different topic.

View this comment - View article - View full comments

Quoting: sa666666Does anyone know if the Metro Franchise Bundle comes with Linux-native binaries, or is it only the Windows version?

There is no Metro game on GOG with Linux version (or macOS)... It sucks for singleplayer games.

View this comment - View article - View full comments

Quoting: hardpenguinHot take: GOG wouldn't be worth it for us Linux gamers if it wasn't for Heroic and the projects it relies on (like gogdl and comet).

So hot, I won't touch it.

View this comment - View article - View full comments

Quoting: EagleDelta

Quoting: CyrilTL;DR: so it's much of an Ubuntu problem than anything else...

While I can use whatever Tmux is in the repos for example, I cannot use whatever version of Neovim is provided as my config requires at least version 0.10.0 which I don't believe is in any repos yet.

Neovim is available in Arch-based repos at 0.10.1 version.

Quoting: EagleDeltaI ended up on a very long tangent addressing The Purple Guy's comments about System Libraries being good for Open Source Software and how, from my experience, that's not the case anymore.

But it does go back to the general issue we see with Game Devs. Many of them are used to relying on Windows system features/libraries built into the OS or Ecosystem, whereas in the Linux Ecosystem, those change more frequently than in Windows, but far slower than most server applications or CLI tools need these days.

I don't like to be that guy but... if you complain that your distro doesn't have the software you need in the repos (or the good version etc.), maybe that distro is just not for you.

I mean, you have to chose between "stable" and "very recent software", you can't have both. Because the Windows way, or Flatpak way, etc. have their own issues too...

"but far slower than most server applications or CLI tools need these days", I'm a bit dubious about this, or don't know what you have in mind when you say that, because precisely the vast majority of Linux servers run LTS distros (Debian, Ubuntu...) and it seems to be just fine. I didn't hear anybody, in my circle, complain about that.

Tell me if I'm wrong or If I didn't understand you correctly.

View this comment - View article - View full comments

Long live to this project, I wish it immortality.

View this comment - View article - View full comments

Quoting: EagleDelta

Quoting: Purple Library GuyIt's not optimal for open source software that's part of the general Linux software ecosystem; the expectation is that that stuff will keep on getting updated more or less forever and if it keeps upgrading to the latest libraries you'll get the best function, security and so on, and you avoid duplication by using system libraries. It's all kind of messy but has a lot of advantages, and it's pretty clear from the history of Linux that it can be made to work.

I can't speak to others experiences, but I can directly say, as someone who's been a part of an Open Source community for over a decade, having to build software (especially server software) using only libraries compatible with those packaged in the system. Namely, building software in C, Python, Ruby, Perl, etc - it's no feasible as in most cases, the communities responsible for those languages are not going to help you because what the distro packaged they took End Of Life anywhere from a year to a decade ago (depending on distro). Which leads back to packaging the tools together. It's not usually as bad with Python, but with other languages? There's a reason things like Puppet and Chef's official upstream Open Source repos (YUM, Apt, etc) all package Ruby within the tools.

Case in point - Ubuntu/Pop!_OS 22.04 ships with Puppet 5.5.22, which was End of Life in October of 2020..... 18 months before the LTS distro was even released. If you have issues with that version, The Puppet OSS Project, Puppet Company, nor the Vox Pupuli Community (which I'm a part of) will support you. None of them have the bandwidth to support stuff that old. So, no, it's not feasible for Open Source software either to ship only with System Libraries. One of the huge reasons I've seen Go and Rust tools take off in the CLI is because they can be compiled and ships many times as a single binary not reliant on anything in the system. They just work.

TL;DR: so it's much of an Ubuntu problem than anything else...

View this comment - View article - View full comments