moonpiedumplings

Firstly, I would like to begin with the way Duckstation was relicensed from GPL to CC-by-NonCommercial-Noderivatives (non-foss license).

I've seen a lot of people incorrectly claiming that this violates the GPL, but the way the duckstation developer did this was not a violation of the GPL. The duckstation developer gained prior contributors approval, and/or rewrote all GPL code for which they didn't.

source: https://www.gamingonlinux.com/2024/09/playstation-1-emulator-duckstation-changes-license-for-no-commercial-use-and-no-derivatives/

I have the approval of prior contributors, and if I did somehow miss you, then please advise me so I can rewrite that code. I didn't spend several weekends rewriting various parts for no reason. I do not have, nor want a CLA, because I do not agree with taking away contributor's copyright.

It should be noted that the version the AUR package uses is the older, still GPL version of the program. There is a git version which uses the latest, and it seems to be okay, but I should note that part of the packaging process on many distros, is essentially forking the software and making a derivative — something incompatible with CC ND.

I have been following this drama for a while, specifically on the r/emulationonandroid reddit community, and there is even more context to be had.

Now, about the dropping of Linux support. The problem, goes a lot deeper than "Arch users annoying".

Firstly, I want to state that there is a running, widely believed theory that Stenzek, the developer of the AetherSX2 android emulator, Talred, are the same person. You see this manifest in comments/posts like this one, but it's all over the sub. (This comment states that Stenzek was never really harassed and I disagree, I will get to that later/)

The problem is that this developer has a pattern of insisting on having a discord community, but being unwilling/unable to moderate it properly, or appoint other/enough moderators to act as a shield between them in the community members.

Arch users are what is being complained about, but the android emulation community has some pretty bad members, due to the high prevalence of children. So they would go on the discord, troll, harass, and be annoying. For example, this instance here.

It culminated with a final update that added ads and decreased performance: https://www.reddit.com/r/EmulationOnAndroid/comments/11q726j/do_not_update_aethersx2_on_google_play_i_repeat/

Now, I do not condone harassment, and I think that the members of the community who are acting in bad faith are ultimately in the wrong here. But at the same time, you are not obligated to have a discord for your software project.

In my opinion, the real problem here is the flawed idea that every software needs to have a "community". I have watched around 3-4 projects die due to harassment on discord (not all of them related to emulation), and it's clear that moderating a community actually takes work that not everybody is willing/able to give, especially if you are interacting with children. And the r/emulationonandroid software is particularly forgetful about this, as they just repeat these patterns over and over again and it drives me nuts.

I'm currently watching the latest android switch emulator use a discord server for communications and do their releases on Github —after the previous iteration's discord server owner locked down the discord server (a lot of blame is placed on powertripping mods but this is the kinda thing that happens when people get fed up with dealing with children tbh). And before that, the Nintendo DMCA fiasco happened. But don't worry, I'm sure the latest switch emulators combination of discord + github will go well and nothing bad will happen at all.

In addition to that, right now I am in 100 discord servers (they don't let you join more without Nitro), because people treat discord as an issue tracker and distribution hub for their small software projects and it drives me nuts.

I would prefer small software projects to not create a community, and instead integrate into existing communities that already have established moderators, so that they protected from harassment and children being annoying.

cross-posted from: https://programming.dev/post/33535348

Nixgl: https://github.com/nix-community/nixGL

Also, it seems like this requires the latest "stateversion", since this is a new feature.

This is pretty big, because it makes it easy to use applications that use the GPU from nixpkgs on non Nixos systems.

cross-posted from: https://programming.dev/post/33535348

Nixgl: https://github.com/nix-community/nixGL

Also, it seems like this requires the latest "stateversion", since this is a new feature.

This is pretty big, because it makes it easy to use applications that use the GPU from nixpkgs on non Nixos systems.

Nixgl: https://github.com/nix-community/nixGL

Also, it seems like this requires the latest "stateversion", since this is a new feature.

This is pretty big, because it makes it easy to use applications that use the GPU from nixpkgs on non Nixos systems.

cross-posted from: https://programming.dev/post/32779890

I want to like, block interaction with a window that I am keeping on top of other windows so I can see it but still click to stuff behind it.

It turns out mpv already has this implemented. https://github.com/mpv-player/mpv/pull/8949

Technically no windows or mac support (presumably it's possible there; dunno), but OP only asked for linux stuff so I'll close this

And then I could remove the title bar if I really don't want to interact with the app.

cross-posted from: https://programming.dev/post/32779890

I want to like, block interaction with a window that I am keeping on top of other windows so I can see it but still click to stuff behind it.

It turns out mpv already has this implemented. https://github.com/mpv-player/mpv/pull/8949

Technically no windows or mac support (presumably it's possible there; dunno), but OP only asked for linux stuff so I'll close this

And then I could remove the title bar if I really don't want to interact with the app.

I want to like, block interaction with a window that I am keeping on top of other windows so I can see it but still click to stuff behind it.

It turns out mpv already has this implemented. https://github.com/mpv-player/mpv/pull/8949

Technically no windows or mac support (presumably it's possible there; dunno), but OP only asked for linux stuff so I'll close this

And then I could remove the title bar if I really don't want to interact with the app.

Older article (2019), but it introduced me to some things I didn't know. Like I didn't know that cockpit could manage Kubernetes.

So this is a pretty big deal to me (it looks recent, just put up last October). One of my big frustrations with Matrix was that they didn't offer helm charts for a kubernetes deployment, which makes it difficult for entities like nonprofits and community clubs to use it for their own purposes. Those entities need more hardware than an individual self hoster, and may want features like high availability, and kubernetes makes horizontal scaling and high availability easy.

Now, according to the site, many of these features seem to be "enterprise only" — but it's very strangely worded. I can't find anything that explicitly states these features aren't in the fully FOSS self hosted version of matrix-stack, and instead they seem to be only advertised as features of the enterprise version

My understanding of Kubernetes architecture is that it's difficult for people to not do high availability, which is why this makes me wonder.

Looking through the docs for the "enterprise version, it doesn't look like anything really stops me from doing this with the community addition.

They do claim to have rewritten synapse in rust though

Being built in Rust allows server workers to use multiple CPU cores for superior performance. It is fully Kubernetes-compatible, enabling scaling and resource allocation. By implementing shared data caches, Synapse Pro also significantly reduces RAM footprint and server costs. Compared to the community version of Synapse, it's at least 5x smaller for huge deployments.

And this part does not seem to be open source (unless it's rebranded conduit, but conduit doesn't seem to support the newer Matrix Authentication Service.)

So, it looks Matrix/Element has recently become simultaneously much more open source, but also more opaque.

So this is a pretty big deal to me (it looks recent, just put up last October). One of my big frustrations with Matrix was that they didn’t offer helm charts for a kubernetes deployment, which makes it difficult for entities like nonprofits and community clubs to use it for their own purposes. Those entities need more hardware than an individual self hoster, and may want features like high availability, and kubernetes makes horizontal scaling and high availability easy.

Now, according to the site, many of these features seem to be "enterprise only" — but it's very strangely worded. I can't find anything that explicitly states these features aren't in the fully FOSS self hosted version of matrix-stack, and instead they seem to be only advertised as features of the enterprise version

My understanding of Kubernetes architecture is that it's difficult for people to not do high availability, which is why this makes me wonder.

Looking through the docs for the "enterprise version, it doesn't look like anything really stops me from doing this with the community addition.

They do claim to have rewritten synapse in rust though

Being built in Rust allows server workers to use multiple CPU cores for superior performance. It is fully Kubernetes-compatible, enabling scaling and resource allocation. By implementing shared data caches, Synapse Pro also significantly reduces RAM footprint and server costs. Compared to the community version of Synapse, it's at least 5x smaller for huge deployments.

And this part does not seem to be open source (unless it's rebranded conduit, but conduit doesn't seem to support the newer Matrix Authentication Service.)

So, it looks Matrix/Element has recently become simultaneously much more open source, but also more opaque.

See title