- The --purge switch of systemd-tmpfiles (which was added in v256) has been reworked: it will now only apply to tmpfiles.d/ lines marked with the new “$” flag. This is an incompatible change, and means any tmpfiles.d/ files which shall be used together with --purge need to be updated accordingly. This change has been made to make it harder to accidentally delete too many files when using --purge incorrectly.
- The systemd-creds ‘cat’ verb now expects base64-encoded encrypted credentials as input, for consistency with the ‘decrypt’ verb and the LoadCredentialEncrypted= service setting. Previously it could only read raw, unencoded binary data.
- Support for automatic flushing of the nscd user/group database caches has been dropped.
- The FileDescriptorName= setting for socket units is now honored by Accept=yes sockets too, where it was previously silently ignored and “connection” was used unconditionally.
- systemd-logind now always obeys block inhibitor locks, where previously it ignored locks taken by the caller or when the caller was root. A privileged caller can always close the other sessions, remove the inhibitor locks, or use --force or --check-inhibitors=no to ignore the inhibitors. This change thus doesn’t affect security, since everything that was possible before at a given privilege level is still possible, but it should make the inhibitor logic easier to use and understand, and also help avoiding accidental reboots and shutdowns. New ‘block-weak’ inhibitor modes were added, if taken they will make the inhibitor lock work as in the previous versions. Inhibitor locks can also be taken by remote users (subject to polkit policy).
- systemd-nspawn will now mount the unified cgroup hierarchy into a container if no systemd installation is found in a container’s root filesystem. $SYSTEMD_NSPAWN_UNIFIED_HIERARCHY=0 can be used to override this behavior.
- /dev/disk/by-id/nvme-* block device symlinks without an NVMe namespace identifier are now fixed to namespace 1 of the device. If no namespace 1 exists for a device no such symlink is created. Previously, these symlinks would point to an unspecified namespace, and thus not be strictly stable references to multi-namespace NVMe devices. These un-namespaced symlinks are mostly obsolete, users and applications should always use the ones with encoded namespace information instead. This change should not affect too many systems, because most NVMe devices only know a namespace 1 by default.
- Support for cgroup v1 (‘legacy’ and ‘hybrid’ hierarchies) is now considered obsolete and systemd by default will ignore configuration that enables them. To forcibly reenable cgroup v1 support, SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1 must additionally be set on the kernel command line.
I’d just like to interject for a moment. What you’re refering to as systemd, is in fact, systemd/Linux, or as I’ve recently taken to calling it, systemd plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning systemd system made useful by the systemd services, journald and vital system components comprising a full OS as defined by Poettering.
Many computer users run a modified version of systemd every day, without realizing it. Through a peculiar turn of events, the version of systemd which is widely used today is often called Linux, and many of its users are not aware that it is basically the systemd init service, developed by Lennart Poettering.
There really is a Linux, and these people are using it, but it is just a part of the system they use. Linux is the kernel: the program in the system that allocates the machine’s resources to the other programs that you run. The kernel is an essential part of an operating system, but useless by itself; it can only function in the context of a complete init system. Linux is normally used in combination with systemd: the whole system is basically systemd with Linux added, or systemd/Linux. All the so-called Linux distributions are really distributions of systemd/Linux!
This is great!
You mentioned the name of the developer of systemd and it sounded to me like there’s a problem with that person in particular. Is that what you meant? I’m aware people have their feelings about systemd, but haven’t heard anything about the developer, am I missing something or just overthinking it?
lol. I don’t like systemd, but this is just a modified version of the GNU/Linux copypasta. It’s just a light-hearted jab at the fact that systemd does so many things on Linux systems that it’s almost as important as the kernel and GNU utils.
I don’t actually know much about Poettering, so not much to say in that regard.
but are they really? how about distros without systemd what would you call those OpenRC/Linux? systemd is indeed a giant intricate project,which is why some people don’t like it or are against it,but all its components are working alongside the Linux kernel, without which there wouldn’t be a need for systemd. I would say it’s rather Linux with systemd,as systemd is optional.
edit: useless autocorrect