Linux

12320 readers

350 users here now

A community for everything relating to the GNU/Linux operating system (except the memes!)

Also, check out:

Original icon base courtesy of lewing@isc.tamu.edu and The GIMP

founded 2 years ago

MODERATORS

Ategon@programming.dev

anzo@programming.dev

dwraf_of_ignorance@programming.dev

KaOS Linux Drops KDE Plasma After 12 Years for Niri/Noctalia to Escape systemd (9to5linux.com)

submitted 1 day ago by cm0002@mander.xyz to c/linux@programming.dev

16 comments fedilink hide all child comments

KaOS Linux 2026.02 was released today as the February 2026 ISO snapshot for this independent GNU/Linux distribution, which uses Arch Linux’s pacman package manager, and the first release to ship with the Niri Wayland compositor.

After using the KDE/Plasma desktop environment by default for more than 12 years since its initial release under the name of KdeOS, the KaOS Linux distribution will no longer ship with its unique Plasma desktop setup, as the devs do not want to use the systemd init system anymore in the distro.

Instead, they put a Niri/Noctalia setup into the KaOS Linux 2026.02 release, while retaining the distribution’s unique look and still offering users access to popular KDE applications that were shipped with the Plasma desktop. However, this release still ships with systemd as the default init system.

you are viewing a single comment's thread
view the rest of the comments

[–] Neptr@lemmy.blahaj.zone 2 points 15 hours ago* (last edited 14 hours ago)

Are these "other features" hard dependent on systemd? If yes, how are they modular (or portable)? "My program can be used on any system with a couple of small dependencies: Linux kernel, glibc, and the systemd Kernel" /j

There are some attempts to use systemd tools independent for it, like elogind and eudev, but see what I mean. Hard forks (with major rewrites) are required because these tools heavily depend on systemd, which fine I understand having dependency, but you cant just use part of systemd since it is to tangled together. It would be nice if mire of systemd code was available as separate libraries so you could further reduce attack surface by building a significantly slimmed version of systemd+feature. I am unsure if you meant modular as in "you can choose to enable them" or as in "you can build without them" or both.

Also, I never claimed systemd ran everything under pid1, just plenty more then the should be, like init plus service manager (and more), not every single systemd tool because that would be beyond stupid and systemd isnt made by idiots.