Duckstation(one of the most popular PS1 Emulators) dev plans on eventually dropping Linux support due to Linux users, especially Arch Linux users.
-
Refuse to build in Arch package environments. My license does not allow for packages
but it's not a package. On arch it downloads the source from his own git and it compiles it on the end user machine. He is a dev and doesn't know that? Or just pretending?
AUR is just (automated) instructions on how to compile (except -bin, in that case it's packaged)
A previous commit of the readme even said:
Linux users are encouraged to build from source when possible
yes, good luck building from source without documentation on what libraries do you need
He is a dev and doesn’t know that?
I think it's reasonable that he doesn't. He doesn't use Arch (or any Linux flavor), so isn't aware of how packaging for Arch works. I'm guessing someone submitted the PKGBUILD and he just accepted it, and now people come to him for support instead of the person who submitted it.
I 100% agree w/ removing the PKGBUILD, but he doesn't need to go out of his way to remove Linux support. Just state that the project doesn't officially support Linux, but is open to Linux-specific bug fixes. Then if anyone complains about a distro-specific issue, close the issue and move on. If someone opens what seems to be a legitimate bug w/ Linux, leave it open and move on.
That's really all the community should expect here.
-
On old Twitter, community notes was simply a function of raising a flag for tweets that got ratio'd. This would open those tweets up for Community Notes users to submit a fact check. Then, the fact check with the highest upvotes gets displayed as the default one.
Now? Not sure. Elon is a sneaky fucker. But I do think it could be implemented as a simple comment queue that admins and moderators could set user roles to help with.
wrote last edited by [email protected]Getting ratioed isn’t an reliable indicator though (see this post).
I guess there could be a “misleading” button that triggers a Community Notes section, but complicating the UI like that could push away many participants…
Maybe there should be a button to “mark” a comment as a correction during the posts, and if it gets enough upvotes it becomes visible under the title? That could work. Some useful comments might not get properly marked, but I think many would.
One issue is Lemmy comments are typically too long to fit under a title, so the “correction” comment would need its own structure: a short correction that fits under a post title, and context that lives in the comment section.
-
It's crazy that this is legal.
It's probably not, unless all contributors agreed to the license change.
-
I used to have this view but I've come around: change can be painful but it's also necessary. It's like a wildfire: it's destructive but it allows for new growth and it's a sign of a healthy, sustainable ecosystem. Suppressing change isn't healthy.
Do I think that every change from Gnome is a winner? Nope but I do think they're doing their best to move in the right direction, as they see it. And for that, I'll keep using Gnome and I wish them good luck.
Agreed. I use GNOME on one system and KDE on another, and I think it's good to have a group that's very opinionated since consistent systems are much easier to support and more intuitive for new users. I don't think GNOME itself is ideal, but I do think the ideas they're pushing are worth discussing.
That said, there's a reason I'm not all-in on GNOME.
-
For troubleshooting issues with his code. Not with broken packages created by others that he has no power to fix.
Which was due to HIS actions
-
Sounds like someone who uses Windows and is annoyed that anyone else uses anything other than Windows.
I dunno about anyone else, but that's a giant red flag for me when it comes to software devs
Eh, I use Linux and am annoyed at issues from users on other systems. I don't know Windows dev very well, so fixing issues on Windows is a pain for me. Likewise for macOS.
So I get it.
That said, the proper way to handle this is to make it explicit what platforms are supported and which are not, accept fixes for unsupported platforms that don't break supported platforms, close issues related to packaging and whatnot on other platforms, and leave open and ignore issues for unsupported platforms. Let the community support what they want, and focus on what you want.
-
Supporting something just means using something now.
People buy something they want, use it, enjoy it and then think that is support. It is ridiculous.
People knighting themselfs for being leech-consumers.
Exactly. I really don't understand this whole mentality.
If I supported this project, I'd either be donating money, code, or tech support time. Using something isn't "supporting" it, it's just using it.
-
I don't know who the bad guy is here because closing the source a while back makes me distrust this dev yet also I 100% believe Linux users (or at least the power users) are almost certainly insufferable in ways that would drive a reasonable dev out of development for Linux.
All users are insufferable, Linux has got nothing to do with it
-
Let me add to context:
This developer hates the FOSS spirit & tells users to fuck off when they complain. There, done.
As a linux user myself (arch) I wish the community would just pick a package manager and stick with it.
-
As a linux user myself (arch) I wish the community would just pick a package manager and stick with it.
Microsoft waiting in the wings to buy that package manager as soon as the community decides.
-
Like Aether all over again
Same dev. Different alias.
-
it genuinely seems like this guy hates developing duckstation at all.
I don't think you get it. He probably enjoys creating, and achieving something awesome. He has no obligation to deal with entitled users of what he gives away
You mean "self-entitled". "Entitled" means that you actually are owed something. It's like the difference between righteous and self-righteous.
-
If it's only available via appimage, as the reply to this comment states, then it will still run just fine on Arch.
Yeah... That's pretty terrible. I was meaning packaging patchsets for other distros. Hopefully the GPL-preserving fork is better.
-
In his defense, a LOT of emulator maintainers have this sentiment about RetroArch, so I can't fault him too much for that one in particular.
I do get the sense this is more common with emulators in general.
In his defense, a LOT of emulator maintainers have this sentiment about RetroArch, so I can’t fault him too much for that one in particular.
Then release your emulator as a paid app for iOS with a closed source and go nuts. Otherwise it's like going out naked during a rainy day and shouting you're getting wet.
-
He's upset because people are bothering him for packages that are out of his control. A similar thing happened recently with OBS where a distro was packaging it in a non-standard way, iirc.
Nah man I maintain a few decently sized packages on github and refusing support etc is perfectly normal but generally you don't go on this toxic rant and just say "nah man I can't afford to maintain this" which is very well accepted.
-
Too many FOSS users are toxicly entitled... It ruins things for everyone.
What are they entitled to? And how is it toxic?
-
but really would feel bad for any packager maintainers.
It's already unpackageable because of the license anyway.
The only "legit" way to get the emulator is their provided AppImage bundle, and nothing else. The author also has a rant about Flatpak being broken and unreliable and refusing to support that, so...
wrote last edited by [email protected]I have some issues with flatpak, myself, but that mainly stems from having trouble finding documentation to clear up how to properly use extensions and non-standard dependencies that are easy to do with OCI images.
Ex. I had a really hard time trying to get Vega Strike built as a flatpak.
-
Refuse to build in Arch package environments. My license does not allow for packages
but it's not a package. On arch it downloads the source from his own git and it compiles it on the end user machine. He is a dev and doesn't know that? Or just pretending?
AUR is just (automated) instructions on how to compile (except -bin, in that case it's packaged)
A previous commit of the readme even said:
Linux users are encouraged to build from source when possible
yes, good luck building from source without documentation on what libraries do you need
They know. The PKGBUILD they provided is exactly the kind of thing that's in the AUR. The dev's PKGBUILD wasn't in the AUR because they didn't want it to be — instead hoping arch users would go to the repository and use their maintained one. Arch users continued to try to use AUR instead, leading to the dev's frustration.
I don't expect this will help anything. If the AUR maintainer is active, they will probably just patch that restriction out.
-
It isn't toxic* entitlement to seek tech support on the platform the developer offers tech support on.
Edit: added "toxic" for clarification
Why wouldn't I be entitled to tech support if they're offering tech support?
-
You cannot forbid forking a public GitHub repository, per their terms of service
Yes. The license doesn't technically appear to forbid forking, just sharing the fork.
