Linux Mint 21 Is Going To Avoid systemd-oomd

[andyprough]

Going to be a shame to watch systemd die and everyone scrambling to update all their old sysvinit scripts.

Who am I kidding - it's going to be hilarious.

[unis_torvalds]

Mint's versioning utterly confuses me.

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.

Mint already copies Ubuntu in better, why go from Ubuntu 20 -> Mint 20 to Ubuntu 22 -> Mint 21? It's just needlessly confusing, and it's not like plain old versioning is a better way of doing this.

Mint always increments versions by one, not two. But because they only base on Ubuntu LTS, it's the Ubuntu versions that jump by twos because their LTSes release biennially.
Thus Mint 19 was based on Ubuntu 18 LTS, and Mint 18 was based on Ubuntu 16 LTS.
Yes it's confusing, but only if you're constantly thinking in terms of the upstream. If you're just looking at Mint, it's fairly straightforward: Mint 21 succeeds Mint 20 which succeeded Mint 19 which followed Mint 18 and so on. Couldn't be simpler actually. it was just a big coincidence that Mint 20 came out in 2020 the same as Ubuntu 20 LTS, not an intentional alignment of version numbers.

[Ermine]

Going to be a shame to watch systemd die and everyone scrambling to update all their old sysvinit scripts.

Who am I kidding - it's going to be hilarious.

Of course, because there's nothing else but sysvinit and systemd?

[user1]

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.

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?

Remember, it's not just Steam client itself that is 32 bit. There are still tons of native 32 bit ports like tf2. I know that on MacOS Steam client is already 64 bit for quite a while, but that's because since Catalina it completely removed 32 bit compatibility, so all 32 bit Mac ports don't work anymore and Steam was of course forced to switch to 64 bit client. On Linux however, there is probably no point for Valve to switch to 64 bit client because 32 bit games need 32 bit dependencies anyway. Even if you play a 32 bit windows game on Proton, you'll still need 32 bit dependencies like i386 Mesa drivers.

[direc85]

I used to have Linux Mint installed on my mums laptop, and as I want that thing to be rock solid without quirks, _not_ having systemd-oomd to mix things up is a good thing. I still like Linux Mint, but I need newer software (and I can't stand the complexity of .deb packaking).

[sinepgib]

I think it's a reasonable move. Default config seems inappropriate for the desktop and fine tuning may be more work than it's worth.

Re: systemd dying... Yeah, because a non-core component not being ideal for a specific use case will make the whole useless.
sysvinit was broken from the beginning, and if anything the triumph of systemd was the fault of the idiots denying its issues and feeding the false dichotomy that the only choice was between those two.
There are plenty of init systems/base systems that fixed sysvinit appropriately, and many actually respected muh Unix philosophy. But defend the utterly broken against the most vocal solution instead of any of the other solutions and the vocal solution will obviously prevail. Nobody wants the broken one but a few neckbeards.
I mean, how bad does your strategy need to be to willingly ignore* s6, runit, openrc and several others in that discussion because "sysvinit is fine"?

*I know some did point out those options, but AFAICT they were really few compared to the defendants of the status quo.

Re: abandoning Ubuntu.
I don't think it'd be madness for them to stop caring about the desktop. Their income (or at least what they clearly aim for income) comes from servers and IOT, not desktop.
The only two things they get out of providing a desktop nowadays are some development ease (you admin the same system you drive daily, so you form habits that translate between the two) and some mouth-to-mouth publicity. Considering any 32 bits Intel server out there is unlikely to upgrade and most IOT is probably using ARM or unsupported smaller arches, they could very well drop a lot of packages (say all i386) without disturbing those use cases if they were willing to ditch the desktop or at least focus on workstations only.
It would harm consumers, of course, I'm talking about the "what's in it for me" POV of Canonical.

[pabi]

Yes it's confusing, but only if you're constantly thinking in terms of the upstream. If you're just looking at Mint, it's fairly straightforward

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.

[Ermine]

I think it's a reasonable move. Default config seems inappropriate for the desktop and fine tuning may be more work than it's worth.

sysvinit was broken from the beginning, and if anything the triumph of systemd was the fault of the idiots denying its issues and feeding the false dichotomy that the only choice was between those two.

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.
2) Triumph of systemd has both political and technical sides. You are right. But also a) systemd provided a lot of policy that was previously handled by distros and that fast-tracked systemd adoption; b) some software, like GNOME, became dependent on systemd, so maintainers found themselves in position where they didn't choose whether to go with systemd, but how much of systemd they need to have; c) Back then, kdbus and single-writer cgroupv2 seemed inevitable. Systemd devs had plans to move udev to dbus-only interface once kdbus is merged into kernel, which meant that udev wouldn't be supported on non-systemd distros. It seemed like distros had to stick to systemd or become irrelevant.

V. R. have written an essay which describes systemd's rise to power and has its technical critique: https://blog.darknedgy.net/technolog...2/0/index.html

[RealNC]

Also will Steam actually leave its 32 bit husk someday or are we stuck with this thing forever?

Steam installs both 32-bit and 64-bit versions of itself (~/.steam/bin32 and ~/.steam/bin64). The 32-bit parts are needed to run 32-bit games.

[Ladis]

Remember, it's not just Steam client itself that is 32 bit. There are still tons of native 32 bit ports like tf2. I know that on MacOS Steam client is already 64 bit for quite a while, but that's because since Catalina it completely removed 32 bit compatibility, so all 32 bit Mac ports don't work anymore and Steam was of course forced to switch to 64 bit client. On Linux however, there is probably no point for Valve to switch to 64 bit client because 32 bit games need 32 bit dependencies anyway. Even if you play a 32 bit windows game on Proton, you'll still need 32 bit dependencies like i386 Mesa drivers.

Fun fact: Catalina still supports sending x86 instructions to the CPU, so you "just" need to copy 32bit libs from the previous macOS to run 32bit apps. The paid WINE (CodeWeavers) translates pointers 32<-->64bit and thus the 32bit apps run (passes forward 32bit instruction to the CPU) and the apps call 64bit system libs (no need to use the original 32bit ones - but adds some level of slowness, especially for games, where you draw a frame tens times a second).