The MX Linux team has officially released MX Linux 25 “Infinity”, the next major version of the popular Debian-based distribution, now built on Debian 13 “Trixie”.
The new version ships in several editions—Xfce, KDE Plasma, and Fluxbox—each updated to their latest stable versions. The release includes Xfce 4.20, Plasma 6.3.6, and Fluxbox 1.3.7.
Most ISO images come with the Linux kernel 6.12 LTS from Debian’s stable repositories, while the AHS (Advanced Hardware Support) variants feature the 6.16 Liquorix kernel for better performance on newer hardware.
The major change is that all releases now include systemd by default, although SysVinit variants of the Xfce and Fluxbox editions are still available for users who prefer the traditional init system. According to developers, this will improve compatibility and simplify future maintenance.
A non-technical person’s best attempt at a useful answer, please forgive and correct me if I get things wrong:
Systemd has become the defacto standard on linux, and was, to my understanding, kinda the first init system to do all its jobs consistently well enough. Though the way distros first implemented it sucked, or something along those lines.
Many people were frustrated by those early issues, and my impression is that its not exactly an elegant piece of software, instead managing to function well through more of just brute force and by being huge and complicated.
People in the linux world really care about the Unix principal, or Unix philosophy (each piece of software should do one thing, and do it well), which is what has enabled linux to be essentially modular, and facilitates tons of user choice, but also fragmentation
Systemd seems to kind of do too many things to really adhere to that principal, and with projects building dependency on it, some folks feel its bad for the linux ecosystem for one massive piece of software that does so much to get tied into every project so that other init systems aren’t usable anymore. It means that if systemd isn’t the best solution anymore, it doesn’t matter, better solutions may not get use anyway without building tons of workarounds for systemd dependencies.
Other folks are frustrated by the frequently overzealous hatred of systemd, and feel what it does to unify linux is more valuable than it’s potential abstract risk to the linux ecosystem, or very complex implementation and maximalist approach.