Linux Mint 21 Is Going To Avoid systemd-oomd

[pWe00Iri3e7Z9lHOX2Qx]

On a server where I do not have a GUI (CLI or WebUI only), the "linearity" of the SysVInit design (using Devuan) works fine for my uses. Besides, who uses a GUI on their servers? Linux converts that were formerly Apple & Windows users, that's who, and it's because that is how they were taught; been there and unlearned all of that.

And yet, in the real world, probably 99% of all Linux servers in production are running a distro that is using systemd. RHEL and clones, SUSE, Debian / Ubuntu. I get the origin of the philosophical hate for it. But that ship has sailed. The world didn't fall apart. None of the "we are XYZ but without systemd!" distros are really of any consequence.

[pWe00Iri3e7Z9lHOX2Qx]

To be quite honest I think Canonical has good reasons to smash some of that extremely aging legacy stuff. 64 bit was the standard over 10 years ago.

If anything, Valve and Canonical have forced the advancement of many Linux elements moreso than any distro.

What is your rationale for this statement?

• GNOME? Oh wait, that was Red Hat.
• The init (+ a bunch of other stuff) system they made systemd? That's Red Hat too.
• Wayland? Red Hat.
• Pipewire? Red Hat again.
• Polkit? Red Hat.
• [...]

Outside of Snap and being the only major distro supporting ZFS out of the box, Canonical seems to be doing fuck all to actually move the Linux desktop forward. Red Hat is the driving force across the ecosystem, and I say this as someone who is typing this from Tumbleweed and wishes their was more diversity in that push.

Also will Steam actually leave its 32 bit husk someday or are we stuck with this thing forever? I know a fully native app with a marketplace connection, tons of features, friends list etc. is huge, and I imagine remaking it is a massive pain, but this is some 2003 or so software now. Surely there must be a solid dozen reasons to remake it with more modern stuff. What would a Qt5 based Steam be like?

As others have already mentioned, the launcher being 64 bit is essentially meaningless when a huge swath of the actual game library is still 32 bit.

[user1]

Sometimes, user criticism holds back progress...

So you mean users need to endure broken/buggy behavior for the sake of progress?

[Mike Frett]

Sometimes, user criticism holds back progress...

[Ermine]

I think the distros are the problem.

In the early days of Linux the distros made a reasonable effort to follow common standards on filesystem layouts (and long before SystemDeath came along), then scripts from the original developer seemed to need few changes and SysVInit worked just fine.

Then a number of different distros decided to go off into separate "camps" on their filesystem layouts (generally following their upstream primary distro designs) with each "camp" doing something different. That schism caused trouble for many original developer scripts and many of those developers moved over to using SystemDeath features because SystemDeath was common to most of those distros; it reduced the "distro customization & support hassle".

I personally cannot remember how many scripts I had to edit in fleet-wide migrations from Redhat to Arch, then Arch to Gentoo, and finally Gentoo to Debian. Each of those distros had their own ideas on where certain files were stored, and these were mostly config files for the apps that might have file location pointers stored within them.

SystemDeath makes sense on the desktop where lots of different stuff has to start, much of it dependent upon other stuff, and all of that stuff needs to "fly in formation together" for the desktop world to work.

On a server where I do not have a GUI (CLI or WebUI only), the "linearity" of the SysVInit design (using Devuan) works fine for my uses. Besides, who uses a GUI on their servers? Linux converts that were formerly Apple & Windows users, that's who, and it's because that is how they were taught; been there and unlearned all of that.

1) Software devs just need to produce software which is as filesystem layout agnostic as possible. Ideally, distro customization must happen at distro level. This seems hard, but it is worth it. Having variety of distros enable a) diverse set of layouts suitable to different use cases; b) experimental layouts (like at GoboLinux) which aimed to improve package management.

But yes, systemd enforced more or less the same layout on everyone subscribed.

On your experience of distro hopping: that was hard, but you had the reason to switch distro, didn't you?

2) Systemd on desktop: it is unnecessary on the desktop. MX Linux with sysvinit works just fine. As for boot times, it manages to compare to that of systemd distros. Also, systemd has a number of features (e.g. container management) which makes more sense on servers.

3) You still want to switch sysvinit to something more modern: supervision suites can restart your daemons if they crash, thus improving your server's fault tolerance. Also they offer another features, such as better and more reliable log management. You can get the good of systemd without the bad. I'm talking of daemontools-family suites, like daemontools itself, runit and primarily s6.

[NotMine999]

1) I wouldn't call sysvinit broken. I think 'outdated' is more suitable here. Anyway, sysvinit is apparently fine for end users, but it is a PITA for distro maintainers.

I think the distros are the problem.

In the early days of Linux the distros made a reasonable effort to follow common standards on filesystem layouts (and long before SystemDeath came along), then scripts from the original developer seemed to need few changes and SysVInit worked just fine.

Then a number of different distros decided to go off into separate "camps" on their filesystem layouts (generally following their upstream primary distro designs) with each "camp" doing something different. That schism caused trouble for many original developer scripts and many of those developers moved over to using SystemDeath features because SystemDeath was common to most of those distros; it reduced the "distro customization & support hassle".

I personally cannot remember how many scripts I had to edit in fleet-wide migrations from Redhat to Arch, then Arch to Gentoo, and finally Gentoo to Debian. Each of those distros had their own ideas on where certain files were stored, and these were mostly config files for the apps that might have file location pointers stored within them.

SystemDeath makes sense on the desktop where lots of different stuff has to start, much of it dependent upon other stuff, and all of that stuff needs to "fly in formation together" for the desktop world to work.

On a server where I do not have a GUI (CLI or WebUI only), the "linearity" of the SysVInit design (using Devuan) works fine for my uses. Besides, who uses a GUI on their servers? Linux converts that were formerly Apple & Windows users, that's who, and it's because that is how they were taught; been there and unlearned all of that.

[Sheldonari]

This news means the Linux Mint maintainers don't test software, and rely on old documentation, IMHO.

I suffered from these issues with systemd-oomd when I installed Ubuntu 22.04. It killed programs way too early. The actual bug was because it counted memory used as cache as being in use, when it should be considered, for memory pressure issues, as free.

This was fixed in Mon, 4 Apr by Debian maintainers, so it was available to all Debian based distros:

https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/tree/debian/patches/lp1966381-oomd-calculate-used-memory-with-MemAvailable-instead-of-M.patch?id=15fc4c53d726e1dcae7296a9306cfd453fd1a046

And it was published by Canonical in version systemd-oomd_249.11-0ubuntu3.3_amd64

https://ubuntu.pkgs.org/22.04/ubuntu-updates-main-amd64/systemd-oomd_249.11-0ubuntu3.3_amd64.deb.html

After this version was installed about a month ago, OOMD worked as intended and it has not been a problem since.

[unis_torvalds]

That's true, but the upstream is still important, such as when an app offers its package for multiple Ubuntu versions or you are searching the internet for a guide on how to do something, because Mint is still effectively Ubuntu and this stuff will apply to it as well in 99 % of cases.
So you still need to remember the Ubuntu version underneath or calculate it somehow (i.e. remembering the 20-20 match or something). It would be nicer to be able to tell the Ubuntu version right away instead, even though it's not a major inconvenience.

Yup. You've just changed my mind. That would be a better system.

[waxhead]

Ubuntu does it right with the YY:MM method. It's sweet, easy to read and once you learn that LTS is every april of an even year, you know all you need from 4 numbers.

Honestly I wish more software and OSes would switch to a date-based model for versioning.

Date based versioning has its benefits, and there are far worse versioning schemes, but really it is not very good. So I do not agree...

1. Calling it a VERSION is not very accurate
2. People think that just because something is a couple of years old means it is off less quality than newer software.

3. Semantic versioning gives you a much better idea what the developers did. Did they rewrite the entire thing possibly breaking compatibility? Did they revise a particular version with new features or major fixes? Or did they patch a minor bug?.... Try to understand that from a date based "versioning" scheme.

4. Date can be added to semantic versioning as well (and it should), just not part of the main version.revision.patch number.

[Ladis]

Valve has had more than enough time to figure out what to do and implement it as far as Steam 32bit => 64bit is concerned. Instead they sit on their ass barely doing much of anything significant with the platform. We know they can move when they're made to: ex. Apple forced the issue with dropping legacy 32 bit years ago. Otherwise they sit on their ass raking in money they no longer deserve on software with flaws and vulnerabilities that have never been fixed unless they directly affect their income. Valve was once a great developer house. Alex suggests they can still do it, but frankly, they're a shadow of what they used to be. Too big, too greedy, too sure of themselves. You'd think a company that so loves Linux would fix the glaring problems with Steam on Linux, starting with the stupidly wrong permissions it grants every game installed. Don't believe me, look at the file permissions on any given game installed by Steam. You'll find most if not all installed as "777".

You know most of the games are for Windows (run via Proton), so they expect the 777 permissions as a workaround for a different model between Windows and Linux? If you want to avoid vulnerabilities, uninstall all older games. Nobody updates them and Valve can't do that either (they don't have the source code of 3rd party games). Valve is actually working on the compaitiblity layers so you can run those games directly (not in a dualboot or virtual machine).