Not coming here
See title.
Systemd 260 kills SysV, tells AI not to misbehave
The latest release of the most widely used Linux init system is here, and between dropping init script support and AI-assisted coding, we feel sure that this release will win it yet more admirers. Systemd 260 delivers one of the changes that the developers have been promising for at least a few years – we reported that init …
-
-
-
-
-
-
Wednesday 18th March 2026 20:10 GMT David 132
Re: Not coming here
Systemd still, after all these years, doesn't have web-browser functionality, or a Freecell game, or a video player, or even, for heaven's sakes, the most basic rudiments of a Customer Relationship Management or business intelligence backend.
Honestly, I don't know what's keeping Poettering.
(please note icon.)
-
Thursday 19th March 2026 00:59 GMT R Soul
Re: Not coming here
Give Poettering and the rest of the systemd weenies a break! They can't develop these things until that pile of shit has assimilated a COBOL compiler, its own windowing system and GUI, a couple of RDBMS, an X400 mail system, a replacement for Samba, a complete DECnet protocol stack, etc. And then re-written these in Rust or whatever is the next flavour-of-the-month programming fad. All of these vital components are taking longer than expected because they haven't yet had their AI hooks and agents added.
-
-
-
-
-
-
-
-
Wednesday 18th March 2026 18:08 GMT jake
Re: Does This Claude Feature Mean...
"less than half a year to remove systemd from all its Linux platforms?"
No. The smart ones[0] aren't using it in the first place.
Repeat after me: Linux is not the systemd-cancer. The systemd-cancer is not Linux.
Remember, during boot, one can change the init called by the kernel as PID1 to whatever one likes at the kernel command line, using init=/path/to/valid/program as a kernel boot parameter. Try using bash. The more adventurous among us might try EMACS or vi instead of bash. The systemd-cancer is not now, and never will be, a necessary part of a working Linux kernel based system.
Please note: Linux is already working just fine BEFORE the init is called.
[0] Rare as that might be in the current administration, holdouts exist. For now.
-
Thursday 19th March 2026 05:09 GMT Eric 9001
Re: Does This Claude Feature Mean...
Linux based system? You mean an GNU based system?
Linux cannot possibly work until it is loaded - typically the GNU GRUB OS loads first (especially so on a GNUbooted computer), which launches Linux, which is pretty hopeless at booting and often needs GNU and/or BusyBox in an initramfs to continue booting and then Linux needs an init to load, which then actually does the needed OS things Linux can't (after all, if Linux can't load an init, it can't do anything, therefore it shuts down and therefore it in fact does *not* work fine before the init is called).
When it comes to non-systemd init's, GNU shepherd or openrc works fine.
-
-
Thursday 19th March 2026 09:55 GMT Eric 9001
Re: Does This Claude Feature Mean...
That is totally unrelated to the topic, but that only proves my point further.
Yes, Android/Linux (or just Android - by the same lieu just GNU is a suitable name, but I have honor and don't go and cut credit out), is one OS that uses Linux as it's kernel without directly including GNU - as it lacks GNU, it's completely different despite using the same kernel.
As it lacks the feel of GNU, people tend to not refer to Android as "Linux" - what is referred to as "Linux" is GNU/Linux or GNU without Linux (i.e. Cywgin or MSYS2 or "WSL1").
As for Android's buildsystem OS and what Android software is typically programmed on, that's GNU/Linux.
-
-
-
Thursday 19th March 2026 10:10 GMT Eric 9001
Re: Does This Claude Feature Mean...
It's incredible how people who don't have a single clue will insult you after reading a clued up comment.
But I guess I need to handhold you.
>typically the GNU GRUB OS loads first
https://www.gnu.org/software/grub/
GRUB contains extensive functionality including a shell - therefore it is an OS - although it's designed primarily around booting other OS's.
>initramfs
https://wiki.gentoo.org/wiki/Custom_Initramfs - note that there's GNU bash and BusyBox there?
While you sometimes can go without a initramfs, there can be problems, for example Linux seriously cannot mount partitions by UUID (!) and it cannot ask the user for an unlock password - a initramfs is needed to do that.
It can mount partitions by PARTUUID, but that's not very helpful if you don't use a partition table, as you have only one partition (meanwhile GNU GRUB can find the root partition no problem).
>if Linux can't load an init, it can't do anything, therefore it shuts down
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/init/main.c#n1638
-
-
-
-
Wednesday 18th March 2026 18:21 GMT Groo The Wanderer - A Canuck
Between this and Wayland, IBM and the RedHat team would seem to be the source of the most ignorant decisions ever made about Linux; their whole disaster of code should be ripped out, because next up is embedding some damned kill switch under the guise of "think of the children" in the US. Unfortunately even my Debian system is infested with systemd. That garbage is almost everywhere!
-
-
-
-
-
Thursday 19th March 2026 15:19 GMT coredump
Yup. At this point the fileservers here are FreeBSD (from Debian, or CentOS (RIP)), and so far IMO ZFS alone was worth the price of admission.
Not that the price was high to begin with, since I've been running the network services servers on FreeBSD for years, so the setup procedures and such for this environment are already solid.
I still have 1 Debian server for backup DHCP, DNS, NTP/chrony and similar network services, the primaries are already FreeBSD. The path of least resistance is simply replacing that Debian with another FreeBSD, but first I decided to stand up a VM with Alpine for a test drive.
Turns out Alpine can handle those duties just fine, no surprise. My fingers aren't 100% used to 'apk' instead of 'apt' yet but it's improving. And OpenRC commands and syntax are no big hurdle at all.
Overall the Alpine server experience has been good; it takes a bit more to setup some things since e.g. the developers don't always bundle apk packages with full-featured *.conf files or example configs like Debian and FreeBSD typically do; but it's not hard to find pretty good info in the docs and Alpine wiki, so it's generally not an issue.
Where I'm not on solid ground yet is whether Alpine will work for my desktop/laptop. From reading the wiki I'm fairly sure it'll be more fiddly to setup the way I want, but it's apparent that people are doing it, including my preferred Xfce. I'm concerned my favorite X tools aren't available, e.g. I haven't found xxdiff in their repos, so FreeBSD may be the better fit there. Plus there's something to be said for running the same OS for server and desktop.
I like Alpine a lot so far, but it's somewhat bittersweet because every positive experience is also a reminder of what might have been if Debian had chosen a different path.
-
-
Thursday 19th March 2026 22:36 GMT coredump
> IBM and the RedHat team would seem to be the source of the most ignorant decisions ever made about Linux
While I understand the sentiment, I'm not sure I agree with "ignorant".
That is, I suspect Red Hat, and then IBM, are quite aware of what they are and have been doing to Linux. And I further expect it's entirely intentional. I don't imagine the product managers and big bosses at Red Hat would disavow systemd at this point, even if they could.
Damage done.
-
-
Wednesday 18th March 2026 19:01 GMT Henry Wertz 1
Remove rc.local? NOOOO....
Remove rc.local? NOOOO....
To be honest this could make some Ubuntu upgrades messy... I've got a few systems that have been upgraded from like Ubuntu 12 to 14 to 16 to 18 to 20 to 22 to 24 believe it or not. Is there still some random cruft on there using sysv init scripts? I have no idea, I didn't look to see if it migrated everything to systemd service files or not.
As for removing rc.local... I suppose I can add a service back in to add it back in. But why even remove it? Just disable it by default if they want. What are they saving, like 1KB? I have some miscellaneous tweaks (some settings get set in sysctl.conf, and the ones that aren't settable through sysctl, I've been setting in /etc/rc.local). It's a convenient place to stick some miscellaneous stuff you want to run at startup, but it's not a daemon where it makes sense to use a service file. (I almost called the daemon a service -- this is not Windows, I'll use proper UNIX terminology.)
"systemd is how I'd envisage Microsoft making a Linux-like operating system."
Indeed. I'm not QUITE bothered by it enough to get a "non -systemd" distro. It does work well enough, but I really don't like how it tentacles through the system, and from an aesthetic standpoint I'm very troubled by the unusual system requirements (why should a program that just starts up daemons and processes, plus the other basic functions it's tentacled it's way into taking over, have any particular kernel requirement? Not that someone is going to want to run systemd 260 on like a 2.6 kernel or whatever, but why shouldn't it be able to? Why a 5.5 minimum and 6.6 for full functionality?) The zeal to intentionally NOT do things the UNIX way is bothersome too; in some cases it really seems like they are just doing things their own way to do things their own way (i.e. no improvement in reliability, performance, or system complexity... in terms of troubleshooting, replacing a "does one thing and does it well" utility with yet more code in systemd doesn't help there.)
-
Thursday 19th March 2026 10:00 GMT James Marten
Re: Remove rc.local? NOOOO....
> I'm very troubled by the unusual system requirements (why should a program that just starts up daemons and processes, plus the other basic functions it's tentacled it's way into taking over, have any particular kernel requirement?
There's no malicious intent. At its lowest level systemd is a process manager. "Just starting up" and keeping track of Unix processes may seem easy, but keeping absolutely rigourous track of processes and their resources under all circumstances is very difficult, especially if it is desired to isolate their access to resources (CPU, filesystem, network etc) for security or performance. So systemd needs kernel features (cgroups, namespaces etc) to support that level of control.
-
Thursday 19th March 2026 10:08 GMT simpfeld
Re: Remove rc.local? NOOOO....
Yup pretty much everything doesn't need SysV init scripts (everything has switched).
But rc.local is really useful for a few lines to fix up a few boot funnies.
In my case, SELinux funnies with NFS daemons and a USB stick for LUKS keys.
Without putting in a ton of effort to dig into root cause of these minor issues.
Also there isn't really a better place to put qdisc setup.
I guess I'll be copying /lib/systemd/system/rc-local.service to /etc/systemd/system/rc-local.service before the next upgrade.
-
-
Wednesday 18th March 2026 19:58 GMT Paul Hovnanian
Wouldn't it be more accurate ...
... to state that distributions moving to systemd will be dropping SysV init?* systemd itself doesn't control the kernel configuration. Which is what launches the selected init handler as PID 1.
*And then name those distributions. So we'll know which to avoid.
-
-
Thursday 19th March 2026 09:53 GMT jake
Re: I'm relieved
"how did anyone pronounce the predecessor without sounding Mexican?"
The prior OS was pronounced System Three, but spelled System III. (There was no System IV, nor was there a System I or a System II).
The System V init was almost always called "the Sys Vee init" for brevity (possibly some Berkeley influence feeding back into Bell Labs, that.).
-
