I did the same but was skeptical since Arch is an only systemd system so there's no point it would affect Arch anyways

I did the same even though I had seen this headline before

It's a large and very complicated piece of software with a single implementation. It's practically impossible to fork, so users are forced to adopt whatever changes the maintainers decide to implement. This could include things like forced dependencies (incompatible with mulb libc for example), or other poor design choices (like binary logging, which is very controversial). And it forces its adoption in places that do not want it (as in cases like the one we're discussing here, where it's becoming harder and harder for Gnome to be used without it).

I'm not going to argue about whether systemd is good software or not. But the biggest problem with it is that it's basically a way for Red Hat to exert control over the entire Linux ecosystem.

Think of it like Chrome/Chromium. Everybody naïvely thought we were never be where we are today when it was announced, but look at where we are today. While it's technically open source and an excellent browser, above all, it's a tool for Google to exert its control over the WWW, such as disabling adblockers, implementing DRM, deciding which CSS/Javascript APIs should (or should not) be adopted, etc. systemd could very well be Red Hat's vehicle for imposing similar requirements on desktop Linux.

It does too many things too well.

My guess (i dont understand it all that well) is that people are less again using systemd, than against a growing dependency on systemd. If something bad happens to it, it could drag down other big elements of the linux ecosystem with itself.

Linux people hate change and think software written in 1970 is the perfect software for modern desktops.

It will keep coming.

For GNOME, I think Chimera Linux is working in something with Turnstile that non-Systemd distros can use to get it working again.

My understanding is that it is fixable by just implementing a couple of APIs, but Artix barely has the resources to fix their own init system, so they aren't able to support such compatibility.

I feel like Void devs will first wait it out. Perhaps Chimera Linux' devs will come up with some workaround by then. A possible workaround could be to make Duncaen's systemd fork official. Though I'm not sure if maintaining 2 init systems would be less work than to patch the systemd API specific stuff.

Isn't systemd that open standard though?

Same with Wayland?

Linux itself is entirely "corporate-aligned." It exists and is developed almost entirely by and for corporations.

Not really, I'm using kde.

Boo, troll dich.

This isn't a secret plot by systemd, this is gnome making dependency choices and a distro that explicitly doesn't support the new dependency being left in the cold. That's just how dependencies work.

I'm really hoping GNOME on void remains possible, even though I'd understand why if they chose to drop it 🥲

My brain might as well be hardwired to the ux of gnome, but the way the project runs... Is frustrating. And tiring. In a number of respects.

LXQT is also good for people who want a Qt based enviroment but don't like kwin.

*BSD is looking better and better.

Agreed in the long term, linux is becoming a mess imo.

You could always swap out crons, syslog, init systems, and it would not affect Gnome.

That just isn't true. Both GNOME and KDE already have hard dependencies on systemd-logind. GNOME hasn't supported non-systemd Unixes since 2015! The only reason it works is that the elogind project provides a systemd-logind implementation decoupled from the rest of systemd. The GNOME team has elected to give users of elogind (despite not being officially supported) advance warning that they'll have to do some amount of extra work in the future if they want to ship GNOME 50. Honestly I think that's quite fair of them.

There are more GNOME features that don't work without systemd even if it launches, like application isolation using systemd scopes. Fundamentally this is about not having to reinvent the world. Why should every DE have bespoke implementations of user, login and service managers instead of just using the ones that 99% of user systems already have?