systemd 257-rc1 Released With A Ton Of New Features & Changes

[phoronix]

Phoronix: systemd 257-rc1 Released With A Ton Of New Features & Changes

Systemd 257-rc1 is out today as a big feature update for this release that brings many new features and other refinements to this key piece of the Linux operating system stack...

https://www.phoronix.com/news/systemd-257-rc1

[caligula]

Wow, musl compatibility means even distros without a shitty libc (glibc) could use systemd.

[usta]

🍿🍿🍿🍿🍿 <- grab one it is open corn for everyone

[intelfx]

Wow, musl compatibility means even distros without a shitty libc (glibc) could use systemd.

Surely you meant to say "distros with a shitty libc"?

[pWe00Iri3e7Z9lHOX2Qx]

I spent way too many hours last weekend trying to figure why my all AMD Zen 4 system was hard crashing when resuming from sleep on kernel 6.11.x. After lots of farking about with UEFI settings, different AMD GPUs, etc., I eventually found this systemd issue thread...

https://github.com/systemd/systemd/issues/33626

Looks like there are some bugs between 6.11 and systemd 256. I love the 'we know basic functionality is badly broken for some people, but we decided to not change our behavior in hopes that the kernel will fix their bugs eventually' response .

[intelfx]

Looks like there are some bugs between 6.11 and systemd 256. I love the 'we know basic functionality is badly broken for some people, but we decided to not change our behavior in hopes that the kernel will fix their bugs eventually' response .

Bugs have to be fixed where they happen (i.e., in the kernel), not papered over where it's most convenient in the short term.

If you demand zero bugs or a short-term-optimal response to them, use a stable / QA-ed distribution (and probably pay for that privilege).

[8-bit memories]

And this is part of why systemd is the question, not the answer. The answer is "no", because this steaming pile is an ever-moving target.

for i in stop disable mask; do systemctl ${i} systemd.service; done

[Espionage724]

I like the changelog!

I'm imaging a use-case for the volume rocker support where I can boot systemd-boot as UEFI directly (or more-directly) on a OnePlus 6 with postmarketOS; possibly avoiding needing GRUB. Not sure if it'd at all be directly-useful for that though currently.

My limited experience with UEFI boot on OP6 was Renegade Project booting Windows ARM as-is, so it sounds like something like that could be done with Fedora and its systemd-boot support. I imagine it could be useful for other distros or even postmartketOS/Alpine (although I suspect they've already got something efficient down for that default).

And I guess more Secure Boot hook-up can't hurt!

Looks like there are some bugs between 6.11 and systemd 256. I love the 'we know basic functionality is badly broken for some people, but we decided to not change our behavior in hopes that the kernel will fix their bugs eventually' response .

I like that response too. Fix the kernel instead of duct-tape fixing the kernel issue elsewhere and having it remain broken outside of systemd or some weird compatibility flag later Zen 9 might run slower with after someone forgot about it years earlier

Dare I ask what wheel re-inventing AMD did to cause a suspend issue on newer platforms that presumably doesn't exist on older platforms, Intel, or Windows?

I also like the last comment where the user used less-problematic s2idle too instead of S3. For me, any issues with suspend -> Right to s2idle (unless faking Windows OSI solves it easy )

And in-general: That is a power-saving issue. Trying to run hardware in lower-power states has been problematic and inconsistent forever. I'll just shut down my laptop when I'm not using it before trying to guess if my NVMe drive comes out of the right power state (between what it/firmware and ACPI decides) to not throw data errors because someone cares about an extra few watts of power on my hardware as if I'm affecting the environment to want to gamble with my data integrity

[q2dg]

Next systemd version should be released with no new features but just with most of its more than 2000 issues resolved: it would be a great release

[intelfx]

I like that response too. Fix the kernel instead of duct-tape fixing the kernel issue elsewhere and having it remain broken outside of systemd or some weird compatibility flag later Zen 9 might run slower with after someone forgot about it years earlier

Dare I ask what wheel re-inventing AMD did to cause a suspend issue on newer platforms that presumably doesn't exist on older platforms, Intel, or Windows?

There seems to be two separate issues with the same outcome:

1. processes using io_uring cannot be frozen and get livelocked (this was fixed during 6.11 rc weeks);
2. KVM threads simply cannot be frozen (this was not fixed).

The latter one seems to be related to AMD, at least according to Luca. But nothing of this is related to PM specifically, it's just process freezing issues in 6.11.