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.
Unless you are running at really large scales, or really small scales and trying to fit stuff that quite fit, memory compression may not be significant enough of an optimization to spend a lot of time experimenting a lot. But I'm bored and currently on an 8 GB device so here are my thoughts dumped out from my recent testing:
Zram vs Zswap (can be done at hypervisor or at host):
Kernel same page merging (KSM) (would be done at hypervisor level) (esxi also has an equivalent feature called something different):
In my opinion, the best thing is to enable zram or zswap at the virtual machine level and kernel same page merging at the hypervisor level, assuming you take into account and accept the marginal security risk and slightly weaker isolation that comes with KSM. There isn't any point running zswap at two layers, because the hypervisor is just gonna spend a lot of time trying to see if it can compress stuff that's already been compressed. Than KSM deduplicates memory across hosts. Although you may actually see worse savings overall if zram/zswap compression is only semi-deterministic and makes deduplication ahrder.
I agree with the other commenter as well about zram being weird with some workloads. Like I've heard of I think it was blender interacting weirdly with zram since zram is swap, making less total memory available in ram, whereas zswap compresses memory. If you really need to know you gotta test.