jellyfin-meta VS oomd

afaik this is really the latest update on it: https://github.com/jellyfin/jellyfin-meta/issues/26

We're still in the planning phase on GitHub, when the server side is added the apps will follow. https://github.com/jellyfin/jellyfin-meta/discussions/30

There are more substantial changes that will happen for an "API v2" rewrite, but it is still being debated how exactly that should be handled.

It's also been very unclear how to get on the team. The official stance was "Work on it and when we notice you and think you do good work, you'll get an invite". I get the idea and brought it up right before leaving (In a messy post on Github where my communication issues lead to it sounding a lot more harsh and accusatory than I intended. You can find it here if you're curious), and it's apparently changing at some point, but the meta issue hasn't moved since it was opened (Here). This kind of "we'll nominate you when we see you" thing goes against the "do-ocracy" principle, since it's all about "doing things", so you should be able to take on responsibilities by nominating yourself on the team (Exactly like the project where the inspiration for the structure and policies of Jellyfin come from works, by the way. That would be Debian). Regardless, it's seemingly changing at some point, so that a good thing.

I've been committed to keeping Jellyfin completely zero-cost since day one, and am baking it into our new project constitution as well. This "joke" isn't funny.

After deleting those it did work, and I could re-install Fanart+Kodi. Adding Gotify once again Broke Things though :-( I think https://github.com/jellyfin/jellyfin/issues/4690 covers the "Failing to load", although it isn't listed under 10.7 known issues. I guess I should create an issue in the Gotify Notification repo at least, is "Fails to upgrade" considered a plugin or a Jellyfin issue?

OOMKiller has a bunch of issues. Its heuristics don't apply well across the wide range of workloads Linux provides (webserver? Database server? build server? desktop client? Gaming machine?), each of which would require its own tuning. (random example: https://lwn.net/Articles/761118/)

That's why some orgs implemented their own solutions to avoid OOMKiller having to enter the picture, like Facebook's user-space oomd: https://github.com/facebookincubator/oomd

I use paru to install/update the softwares on my laptop. I usually update the system twice per week. But recently I've noticed that oomd-git package was showing in the AUR updates everytime I ran the paru command. So, I checked the upstream URL but the main branch shows no new commits since last month. I have no idea why is this happening and weather it's a paru issue or oomd-git issue.

Additionally, you might want to check this: https://github.com/facebookincubator/oomd

I think the distinction is that MemoryMax= is just an interface to the cgroupv2 setting, i.e., that rule is implemented inside the kernel and invokes the kernel's OOM killer within a cgroup. The manpage for systemd-oomd says, "systemd-oomd is a system service that uses cgroups-v2 and pressure stall information (PSI) to monitor and take action on processes before an OOM occurs in kernel space."

It looks like systemd-oomd is related to (based on? from the same people as?) Facebook's oomd https://github.com/facebookincubator/oomd , whose documentation gives a bunch of reasons as to why you would prefer a userspace oomd that takes in PSI data and can be configured to proactively kill misbehaving processes instead of just letting the kernel OOM killer handle it. The major reason is time to recovery: a misbehaving process can cause a system to be so far under pressure that the kernel OOM killer will take a long time to flush things out, but a userspace component can respond in advance with more configurable rules (and more flexibility, since the kernel doesn't believe you're at capacity yet).

oomd - developed by facebook and will be default in Fedora 34, it is part of Systemd 247 but still in experimental stage