First release candidate of systemd 258 is here
- Reference: 1753470891
- News link: https://www.theregister.co.uk/2025/07/25/systemd_258_first_rc_here/
- Source link:
Version 257 of systemd [1]came out last December , and since the team tends to release new versions twice a year, you could interpret that as meaning that version 258 is slightly overdue. The reason could be that this is a major release, with a substantial amount of new functionality. We don't track these things especially closely, but The Reg FOSS desk has been reporting on new releases of the systemd suite since [2]version 251 in early 2022 , and off the cuff, we'd guess this is the biggest in that time.
Version 258-rc1, meaning release candidate 1 , just appeared on GitHub, and the [3]README file contains an impressive list of changes. Among the top ones are that it now needs at least Linux kernel 5.4, and support for cgroups version 1 is gone.
[4]
However, to get a feeling for what project lead Lennart Poettering feels are the significant changes, a better source could be his long series of posts on his [5]Mastodon account , in which he explains the important functional changes over a whopping series of 32 threads. We went through them so that you don't have to. That said, it's long, complicated, and "Agent P" is a very smart chap, so it's possible that we have misinterpreted some of them. A few of the comments we saw mentioned that certain posts sent people down research rabbit holes as they strove to understand, and they certainly have our sympathies. Some of the posts certainly describe a usage model that's profoundly different from how this vulture uses Linux computers, and we may have misunderstood some of his points. Do please let us know if you spot any howlers.
[6]
[7]
So now, buckle up for a long and bumpy ride…
[8]Post #1 tells us that there's a new switch to the command to start a service: systemctl start -v $COMMAND results in verbose startup messages in the log from that service. Apparently, this was quite complicated to achieve.
[9]
[10]Post #2 revolves around the somewhat controversial systemd-homed tool, which replaces the traditional Unix system of one home directory per user. Now, it supports multiple separate home directories for a user account, and provides a way to switch between them "by logging in specifying a user name of username%areaname at login time." He also notes that "this is a systemd-homed feature, it's not implemented for classic UNIX users." Jumping forward, this tool also crops up in [11]post #19 , which explains that systemd 258 allows PAM authentication inside service units – so, for instance, a service can ask for passwords during startup. This works with [12]systemd-homed for on-the-fly unlocking of encrypted home directories.
[13]Post #3 says that "the query-routing logic in systemd-resolved got substantially upgraded: in addition to routing queries to the DNS config of each interface (and optionally one additional global one), there's now the ability to define arbitrary numbers of additional 'delegate zones.' These are basically just combinations of DNS servers along with the domains to match queries with that shall be routed there." Jumping ahead, [14]post #13 introduces a new mechanism to be notified of DNS config changes.
DNS resolution is a common point of failure in 21st century computing systems. For reference, we recommend this handy reference site: [15]Is it DNS? . We've already seen [16]systemd-resolved causing people problems. It's about to get more complicated.
[17]
[18]Post #4 explains that today, many container systems use sub-UIDs and sub-GIDs. Agent P dislikes this, and now, he has a solution: "With v258 we are doing something about it: we set aside one fixed range of 64K host UIDs/GIDs that can now be used for container trees placed in regular directories. In other words: this allows container runtimes to place unpacked container trees in a user's $HOME." There are some new IPC calls for managing this, and the good news is that this is unprivileged.
[19]Post #5 introduces new support for dynamic hostnames. "If the /etc/hostname file contains question mark characters, those are implicitly and automatically replaced by hex digits hashed from /etc/machine-id when processed." Jumping ahead slightly, alongside this, [20]post #8 explains how the ConditionHost= unit-file setting now can operate on the randomly-generated boot ID, and on the vendor ID, as well as on the hostname and /etc/machineid . We can see these being handy for those managing lots of boxes or VMs.
[21]Post #6 introduces per-user quotas on space usage in the /tmp tree, so a single user account can't use more than 80 percent. This closes off a potential route for DDoS attacks, and he links to an [22]explanation of the rationale . Also trying to prevent system resource exhaustion, [23]post #7 explains some new workload-management tooling to try to prevent overloading the system by starting more things at once than it can handle.
[24]Post #9 explains that now, systemd exposes lots more meta-information about the currently executing process to terminal emulators via some [25]new ANSI extensions . However, for now, this doesn't include things invoked remotely over SSH. Improved terminal handling is clearly a point of interest: again leaping ahead slightly, [26]post #24 has a historical lecture on the failures of Unix terminal handling, by way of leading up to some new features in version 258. This adds two new terminal capability settings: $COLORTERM and $NO_COLOR (based on an [27]existing specification . Also, "we added support for limited auto-discovery of $TERM: as part of TTY initialization, systemd will now query the terminal for its terminfo database identifier, and then set $TERM to it."
This does seem to be an area ripe for improvement, but we can't help but feel that the idea of introducing more configuration options [28]reminds us of something .
[29]Post #10 explains that this release extends the formerly separate [30]systemd-boot bootloader to understand URLs to [31]UKI files over the network, thus embracing and extending UEFI's existing HTTP boot support. Also regarding UKIs, [32]post #15 explains that these all-in-one signed boot files can now include system firmware images too – again, mainly for more secure VMs.
New troubleshooting tools are always welcome, and [33]post #11 introduces a new feature that allows branching to an interactive shell – and waiting for it to exit before continuing – at lots more points during startup. Similarly, and again leaping ahead a bit, [34]post #30 explains a new systemd-analyze verb unit-shell , which opens a shell in that unit's context, for testing and troubleshooting.
[35]Post #12 explains a new method to tell systemd to [36]perform a full factory reset at the next boot. We are willing to bet someone somewhere is going to regret trying that one out.
[37]Post #14 explains a new mechanism by which systemd can now dynamically add entries to the systemd-boot startup menu, for troubleshooting and so on. This feature seems mainly for VMs.
[38]Post #16 explains a mechanism that adds aliases for usernames, which fixes what Agent P sees as an issue where more than one UID points to a single account.
[39]Post #17 explains that systemd now works with [40]verity-protected block devices and [41]Discoverable Disk Images (DDIs) to allow volumes to contain metadata about where they should be mounted. This does sound potentially handy to us – we've seen hard-to-fix failures caused by volumes being mounted in the wrong place – but this seems like a narrow implementation. However, adding metadata to the GPT partitioning scheme would be an epic undertaking.
[42]Post #18 explains that version 258 extends the mechanisms for cryptographic signing of OS images, for example, so that they can be built on other machines. It calls out SUSE's [43]Open Build Service by name, but for now, this can't build SUSE images, only ones using [44]Particle OS – but we suspect that support for these mechanisms will be added to other distros in time.
The change described in [45]post #20 allows mount options from more recent kernels, which older ones don't understand, to be suppressed, so the volumes still mount when running on an older kernel release. On the one hand, that should make things more robust, but on the other hand, it could conceivably also introduce some very hard-to-troubleshoot failures.
Continuing the eternally popular theme of system introducing new modules and functions, [46]post #21 describes a new service, systemd-userdb-load-credentials.service , which simplifies the process if you're using userdb to handle accounts using drop-in JSON files. It only runs under those conditions, though. More userdb fun is introduced in [47]post #28 , which explains how this and the previous systemd release offer tools over and above traditional Unix specifications. Currently, POSIX just allows matching a particular user account. Systemd 257 added user account filtering and matching against criteria, such as the GECOS field; for instance, you can configure things for ranges of accounts, or for a set of accounts matching a pattern. In version 258, this functionality is exposed via an IPC call as well.
Systemd has been able to start and manage containers on its own for over a decade – The Register first [48]mentioned the systemd-nspawn command back in 2014. It can also run full VMs using the analogous [49]systemd-vmspawn command. In [50]post #22 , Agent P explains that he uses this a lot and so has added a parameter to expand the new VM's filesystems. The new switch --grow-image= (or -G for short) does it for you, so you don't need to manually adjust the size with [51]truncate or [52]fallocate . This is something we've never once felt the urge to do, but perhaps it will be good news for someone somewhere.
Also in VM management, [53]post #31 explains that systemd VMs now show their [54]VSOCK context identifier or CID on startup. This makes it easier to connect to instances without going across the network.
[55]Post #23 explains that [56]systemd-notify can now fork off background processes and wait for them to complete.
Returning to its container-management functionality, [57]post #25 explains that while systemd-nspawn is starting a container, the keystrokes ^]^]^] will kill the container. Now in 258, there are two new commands as well: ^]^]r reboots the container, and ^]^]p powers it off. For this to work, though, you will need a compatible init inside the container.
[58]Post #26 has an unusually cautious tone, as it explains that ExecStart= takes flags "denoted via special characters, such as @ , - , : , + , and ! as the first character of the setting's values. (Yes, this is a bit cryptic, we have to admit that)."
Now, it takes | as well. The pipe character means "we invoke the shell and pass the specified command via the"-c" parameter to it." He notes that you could use this for passing scripts to the command, but that's a bad plan. The idea is to let systemd's new run0 command – its replacement for sudo – to pick up that account's shell.
By [59]post #27 things are starting to get arcane. The existing [60]systemd-sysext tool lets you layer DDI images to build a custom /usr tree, which is handy in immutable setups where you can't change it. In addition, systemd-confext does all this for /etc/ too. The objective is to provide tooling to manage configuration in immutable distros, without the need to modify their read-only filesystems. The layering concept will be immediately familiar to many sysadmins from Docker, as this is how container images are constructed.
The core function of systemd is to act as a service manager, and [61]post #29 explains that the service manager now gets disk space management to go with the existing management of CPU, RAM, I/O and so on.
Finally, after post #17 talked about verity protection for block devices, [62]post #32 discusses how the [63]systemd-repart tool now supports file-level [64]fs-verity checks in addition to the existing block-level [65]dm-verity ones.
This is a lot to digest, and we boiled it down as much as we were able. We are sure that the many folks who don't care for systemd will find plenty of fuel for their ire here. This version will also pose a challenge for distros such as the experimental [66]GNU-free Chimera Linux , which aim to replicate some of the more advanced functionality of systemd. Possibly not too much, though, given how many of the new features involve containers and virtual machines. You can expect to see system 258 in the distros that will appear later this year, including Ubuntu 25.10 and Fedora 43, and we suspect that some of its functionality will become integral to tools such as the next Ubuntu LTS, 26.04 (or possibly 28.04), and also to RHEL 11. ®
Get our [67]Tech Resources
[1] https://www.theregister.com/2024/12/13/systemd_257_gnu_shepherd/
[2] https://www.theregister.com/2022/05/24/version_251_of_systemd_released/
[3] https://github.com/systemd/systemd/releases/tag/v258-rc1
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2aIZNKCyOs7CxP-czG1HKKgAAAMw&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[5] https://mastodon.social/@pid_eins
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aIZNKCyOs7CxP-czG1HKKgAAAMw&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aIZNKCyOs7CxP-czG1HKKgAAAMw&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[8] https://mastodon.social/@pid_eins/114545892813068498
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aIZNKCyOs7CxP-czG1HKKgAAAMw&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[10] https://mastodon.social/@pid_eins/114550305394053015
[11] https://mastodon.social/@pid_eins/114710109344141459
[12] https://systemd.io/HOME_DIRECTORY/
[13] https://mastodon.social/@pid_eins/114556401535348313
[14] https://mastodon.social/@pid_eins/114658726594933395
[15] https://isitdns.com/
[16] https://www.freedesktop.org/software/systemd/man/latest/systemd-resolved.service.html
[17] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aIZNKCyOs7CxP-czG1HKKgAAAMw&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[18] https://mastodon.social/@pid_eins/114573005995694680
[19] https://mastodon.social/@pid_eins/114584855720355892
[20] https://mastodon.social/@pid_eins/114611768708184175
[21] https://mastodon.social/@pid_eins/114600936718520372
[22] https://systemd.io/TEMPORARY_DIRECTORIES/
[23] https://mastodon.social/@pid_eins/114606769582857046
[24] https://mastodon.social/@pid_eins/114618473677694301
[25] https://github.com/systemd/systemd/blob/main/docs/OSC-CONTEXT.md
[26] https://mastodon.social/@pid_eins/114771082006844631
[27] https://no-color.org/
[28] https://xkcd.com/927/
[29] https://mastodon.social/@pid_eins/114623820293284298
[30] https://wiki.archlinux.org/title/Systemd-boot
[31] https://www.theregister.com/2023/02/17/systemd_253/
[32] https://mastodon.social/@pid_eins/114669334251141174
[33] https://mastodon.social/@pid_eins/114629842058448119
[34] https://mastodon.social/@pid_eins/114823531154384369
[35] https://mastodon.social/@pid_eins/114635221853062454
[36] https://github.com/systemd/systemd/blob/main/docs/FACTORY_RESET.md
[37] https://mastodon.social/@pid_eins/114663599190570395
[38] https://mastodon.social/@pid_eins/114674923588128559
[39] https://mastodon.social/@pid_eins/114691782651088597
[40] https://docs.kernel.org/admin-guide/device-mapper/verity.html
[41] https://uapi-group.org/specifications/specs/discoverable_disk_image/
[42] https://mastodon.social/@pid_eins/114697642092211474
[43] https://openbuildservice.org/
[44] https://github.com/systemd/particleos
[45] https://mastodon.social/@pid_eins/114715785929761972
[46] https://mastodon.social/@pid_eins/114731475255410988
[47] https://mastodon.social/@pid_eins/114812166113613377
[48] https://www.theregister.com/2014/05/23/google_containerization_two_billion/
[49] https://www.freedesktop.org/software/systemd/man/255/systemd-vmspawn.html
[50] https://mastodon.social/@pid_eins/114748482077172097
[51] https://man7.org/linux/man-pages/man1/truncate.1.html
[52] https://man7.org/linux/man-pages/man1/fallocate.1.html
[53] https://mastodon.social/@pid_eins/114827645185448224
[54] https://man7.org/linux/man-pages/man7/vsock.7.html
[55] https://mastodon.social/@pid_eins/114754518632012480
[56] https://www.freedesktop.org/software/systemd/man/latest/systemd-notify.html
[57] https://mastodon.social/@pid_eins/114776832571027618
[58] https://mastodon.social/@pid_eins/114782700539340326
[59] https://mastodon.social/@pid_eins/114788278114378875
[60] https://www.freedesktop.org/software/systemd/man/latest/systemd-sysext.html
[61] https://mastodon.social/@pid_eins/114816786836736040
[62] https://mastodon.social/@pid_eins/114850389356673130
[63] https://www.freedesktop.org/software/systemd/man/latest/systemd-repart.html
[64] https://docs.kernel.org/filesystems/fsverity.html
[65] https://docs.kernel.org/admin-guide/device-mapper/verity.html
[66] https://www.theregister.com/2023/02/13/chimera_non_gnu_linux/
[67] https://whitepapers.theregister.com/
Re: hold on there
Checkout Devuan: Debian Linux with SystemD missing. Typing this on it - see, it works fine.
(OK OK I trust you were only joking)
Re: hold on there
Works here too, but I'm not a power user by any means.
The trouble is that if I need to search the net for how to do something, increasingly the answer involves systemd commands, most commonly to restart a service.
Most of the internet seems to ignore Devuan, even ventoy won't run it's installation ISO image (last time I tried). Looks like we're going to be left out in the cold.
Re: hold on there
There's also MX Linux - Debian-based with sysvinit by default, but can be booted with systemd if required (and includes systemd shims).
Re: hold on there
For the time being, the "activists" are beginning to clamour for systemd by default (they _do_ have it!), so be aware.
Re: hold on there
I have posted about Alpine here a few times - it was up against Void and I got it working first on a Pi5, but I havent given up on Void. That is another minimal distro, but is a bit more "alien" in terms of package manager and init system. I'll be trying it soon on an old Acer laptop.
Re: hold on there
This. So much. I guess we should start contributing to the Devuan forum, at least that would be a central place. I now try to document my problems and solution attempts locally, so I can retrace my steps when messing up because there is no documented fix for what I'm trying to do. Though Devuan mostly does what I need.
I have been burned by "Agent P's" software several times (pulseaudio... that was a steaming pile of mammoth droppings when it was forced upon me by some distro, seems more stable now, and the resolvd and networking portion, as well as some temp file stuff of systemd), more than by anything in my neigh on three decades of Linux use (except maybe sendmail? The configuration was a nightmare for me the first times), and while I get that the init system should be redesigned I don't think putting every functionality in it is the best way....
Re: hold on there
You'll be deighted to know {spit}pulseaudio has now been sidelined by pipewire
Re: hold on there
That was good for me as ALSA does not support dmix on RPi HDMI audio, so it was blocking. Pipewire drops in as a replacement, and still uses pavucontrol/xfce4 volume controls as PA.
Re: hold on there
Most of the internet seems to ignore Devuan ...
Indeed ...
Like it has been noted in more than one opportunity, here and elsewhere: there is a fantastic amount of moolah behind the making of systemd the de-facto init for the Linux ecosystem.
The likes of MS/IBM/RedHat have put all their weight behind it so it comes a no surprise when all search engines respond did you mean Debian? when you search for Devuan .
Soon they won't even ask ...
But the hoi polloi does not give a monkey's toss about all that and it makes sense that this is so.
Why should it be different?
With their mugs stuffed into a smartphone screen all day they get all they (think) they need.
Because, yes, it is so very convenient !
Systemd is nothing short of an MS registry for Linux, its main purpose being to turn Linux into a MS type OS, with Debian eventually being totally absorbed by it.
But there's really nothing new here: it is the old MS embrace, extend, and extinguish that has been going on for decades.
Only that now there's active participation and backing from IBM/RH, with all that it entails and cooperation from the inside, so to speak.
Devuan (and derivatives) is still holding on but who knows for how long this will be so.
Meanwhile, in Linux land, very few people remember what the principles of Unix philosophy are and stand on.
.
Soon they won't even ask ...
I hate home truths.
Re: hold on there
"Devuan (and derivatives) is still holding on but who knows for how long this will be so."
At that point it will be BSD for me
Re: hold on there
More like... it's installation image doesn't work with Ventoy, not the other way around. Ventoy is just a boot loader. I ran into one that didn't work, it was because the distro boot image was trying to mount its /sources directory internally and it was trying to mount one of the ventoy partitions instead. I had to write the image directly to a USB stick (I used dd).
Re: hold on there
I was under the impression that ventoy needed to "know" about each ISO it can boot, but maybe that's incorrect.
I've just had a quick search, it looks like whatever the problem is it's not getting fixed.
Re: hold on there
That's not a ventoy problem, it's because of the way the Devuan ISO is formatted. I think the live installer works.
The desktop live ISO works for me on Ventoy and my IODD...the netinstall ISO is a mixed bag though.
The trouble with these contrarian distros is that eventually they end up looking so far back they stray towards the line of not supported by anything.
The concept of these distros is fine, but in practice, they usually end up built around badly maintained forks of older tech, not the actual older tech itself...because they have to keep patching and fixing the old tech to ensure it still works with newer stuff. The folks maintaining these distro specific forks have neither the skill nor talent that the OG developers of the dead project possessed and you end up with something that is much worse than the original tech.
Re: hold on there
Devuan has a bug, which the team feels is not their problem, but only happens in their implementation.
On mate desktop using mate-media, the devuan implementation does not persist your audio device settings choice across reboots.
The problem does not occur if you install antix, or convert debian to devuan, but devuan think it is a but in mate??!
I personally cannot use devuan because of this bug.
Re: hold on there
So, we've moved on from "Do One Thing and Do it Well"
to
"Do everything and do it obtusely."
Is there any truth to the rumor that Systemd release 259 will include a spreadsheet and word processor?
Re: hold on there
" Is there any truth to the rumor that Systemd release 259 will include a spreadsheet and word processor? "
Those two applications are typically already baseline crap so probably no.
Next up is incorporating one of Microsoft's LLMs into systemd to second guess your system calls and shared library bindings amongst other unsolicited AI assistance. :)
Re: hold on there
The Singularity will come when Systemd version (whatever) incorporates an Emacs implementation.
Or perhaps it'll happen the other way around first, who knows.
Re: hold on there
Deathmatch!
Re: hold on there
This is the bit that surprised me: "it now needs at least Linux kernel 5.4"
It doesn't have its own already?
Re: hold on there ; Sub: kernel 5.4
Because systemd needs exFAT filesystem support??
What?
I'm sorry but why the ^^^^ would you want multiple Home folders for a single account? This is made especially pointless since you have to choose which one you want at login which means you could instead use 'child' accounts (Fred1, Fred2 for example) to get the same effect without needing to rewrite the core code.
In general this list of changes seems to be a traditional mix of WTF? ; single scenario value; someone's pet idea they have been trying to include for years and finally a sprinkling of probably useful but may already be possible in way everyone already understands
Its a kitchen sink feature
There are people out there who it, and this is added for them. That's what systemd is such an abomination. It is the ultimate kitchen sink application, that tries to do everything any two people somewhere in the world think needs to done.
Re: Its a kitchen sink feature
One person.
Re: Its a kitchen sink feature
I think it's one particular person's employer and a financial backer or two to assist their cloud offerings. Follow the money.
Re: Its a kitchen sink feature
It's not an "application", it's a lot of little commands that have well defined purposes that you are not required to use if your use case does not require you to run them.
Re: Its a kitchen sink feature
"it's a lot of little commands that have well defined purposes that you are not required to use if your use case does not require you to run them"
There's one small difference between that at Unix. With Unix they were separate commands, not bits sticking out of a hairball.
Re: Its a kitchen sink feature
*Separate programs.
Re: Its a kitchen sink feature
Though even in old /usr/bin there were multiple hard links to a single binary with different behaviours depending on its exec name.
Re: Its a kitchen sink feature
vi view ex will be the most familiar to many people.
Re: Its a kitchen sink feature
They're separate commands in systemd. This is quite obvious simply by looking at the source code. They might reside in a single repo. It doesn't mean there is dependencies between them and quite frankly it is why most of the raging about it is so comically wrong.
Re: Its a kitchen sink feature
So when they said the entire source bundle was neede to compile one of these separate commands they were telling porhies?
Re: Its a kitchen sink feature
Back in the day, they also worked – those little commands.
Need I mention my last run-in with systemd which ... er... broke `sudo`. Yes. It stopped `sudo` from working so I couldn't even fix it without booting from a live image, chroot, and then replacing the entire thing with Gentoo without systemd.
And, the WHOLE time, I was asking myself this question: WHY does anything have any reason, means or motivation to even be able to break `sudo` in the first place and, as a corollary, why should *I* need to know about its very existence?
Sure – there's a tonne of those old-back-in-the-day UNIX commands that I don't know and don't use – mostly, ones I've likely even forgotten I ever did know or did use because my memory's like that – but, if you don't call them, they do nothing. They do not break things that aren't in their realm and there is no requirement to learn about some facet of them because – surprise! – someone else made an executive decision that it should now break something you've always used, known, and relied upon.
(And, yes, it was `systemd-homed` that broke `sudo`!)
I got half way through this article and realised that I actually do not care to read about all the wide, sweeping, revolutionary changes. I do *not* want wide, sweeping, revolutionary changes on my Linux boxen and that's why I will not tolerate `systemd` on them, either. I just wish that more people in the Linux world would look at those massive piles of stuff that it's bringing to the table and ask: who wants that? Instead of 99,99% just going "systemd is everything" and swallowing it.
If anything ends the momentum of the Linux desktop, it isn't going to be nVIDIA's drivers, Wayland, Steam failing to bring gaming to Penguin-land, Microsoft indulging in anti-competitive malarkey or Linus pissing off one too many developer or contributor: it's going to be a complete collapse of the entire thing because nothing independent from systemd even exists any more and so the house of extremely inflammable cards not only grows but becomes more and more critical in the system. Any risk manager who's not jumping up and down about that should just buy macs for their server farm and office desks!
Re: Its a kitchen sink feature
After the systemd release that adds a kitchen sink will come the next release that supports adding multiple kitchen sinks.
Re: Its a kitchen sink feature
Alas, if that were true it would be very busy fucking itself.
(pardonnez mon Français...)
Snark aside, the relationship between these "features" and init-style concerns indeed seems tenuous at times.
Re: What?
>> why the ^^^^ would you want multiple Home folders for a single account
To make it more like Windows, where the user directories are more and .org obfuscated, and take directories like Documents or Pictures can be anywhere, and that files that look to be local are really remote (see OneDrive), and when you lose your internet connection, you lose access to your files.
I'll go back to FreeBSD before using systemd.
Re: What?
> I'll go back to FreeBSD before using systemd.
Don't make it sound like a bad thing!
Re: What?
Not a bad thing at all. Just a logical alternative.
Re: What?
This is needed when you want all people to have access to the same resources and you want to track their login/activity as separate activites.
Yes, this could all be handled by using chmod, groups, etc. but if you're from a Windows world (poor bastards) this is how they work.
I've didn't mind MS-DOS 3.x, but it all went downhill after that. Unix was always a better solution for everything but gaming. And now with Steam that's been fixed I see no reason to touch the OS that is the demon spawn of Redmond!
Re: What?
Actually Windows-95 wasn't all that bad -- After one installed about two dozen "Service Packs" (Service Pack=Massive collection of bug fixes). It was actually comprehensible to almost all users and could run for weeks without crashing. Of course it was really MSDOS 6.22 with a GUI shell. We have since devolved into the incomprehensible shambles that is Windows-11
Re: What?
Weeks? Things always seem better in the past than they actually were. Hours would be closer to the truth.
Re: What?
To be precise, 7.1 weeks. After that it would crash when its uptime counter rolled over.
Re: What?
"Unix was always a better solution for everything but gaming"
Unix was invented because Ken Thompson could play his Space Travel game.
Re: What?
Much as I hate systemd, and all my computers run systemd-free Linux or Unix, there *might* be a use for this feature, if each home folder has its own passphrase which can be disabled, deleted, set, etc. by system admin(s).
In a corporate environment, you desire a 1:1 mapping between users (human) and user accounts. This way, if someone is suspended or fired, Accounts/Security has just ONE account they need to find and disable.
Simultaneously, it happens that a single person may have multiple roles, or jobs within the company, each role or job having a separate set of valid filesystem accesses.
Further, there are things which happen in login scripts which may be required for Department A, yet should not happen for Department B.
The current kluge-workarounds are:
(1) multiple accounts, e.x., jonesf1, jonesf2, etc , which violate the desired person:account 1:1 mapping;
(2) file permissions granted via groups. The problems there are you still have the login script conflict, there are not enough groups, and group access is insufficiently fine-grained;
(3) AFAIK, not possible under Unix and Linux: file access permissions granted to specific users, as is possible under Novell Directory Services, and possibly (IDK) under Microsoft Active Directory. This is an administrative nightmare when a person is suspended from their job in Department A, but still works for Department B.
Systemd areanames might help resolve the issue.
One of the problems of systemd is that you are required to use and maintain the entire 218-square-mile Cape Canaveral launch complex, even if you're only shooting off a bottle-rocket.
Re: What?
> it happens that a single person may have multiple roles, or jobs within the company, each role or job having a separate set of valid filesystem accesses.
Which is what groups gives you.
> there are not enough groups, and group access is insufficiently fine-grained
This means you haven't bothered to analyse your requirements and defined, then created and used, enough groups to control your own specific environment. Ok, there are limitations from some file systems (NFS, IIRC) but kludgey careful use of groups gets around those (i.e. define the set of groups important to whatever is being accessed via (NFS or ...) to be within the range you can use there).
Nor is it clear how having a different home folder helps - aside from selecting which login script gets run and which ~/.myapp-config.d gets invoked, which are separate from shared resource access control, aren't they?
> Further, there are things which happen in login scripts which may be required for Department A, yet should not happen for Department B.
Can you elaborate on that, as it is not something I've encountered in practice (simply because I've not worked in every environment on the planet, not because it is necessarily unusual): do you mean w.r.t. job function - e.g. logging into the correct time management system? - or physical constraints - e.g. Dept A all use printer PrintA, Dept B uses PrintB?
Either way, it really isn't clear to me why adding this into the OS ((making it more complex for everyone) really helps in such situations instead of, say, shoving into their login scripts a question box that just asks "What are doing today" then does the necessary.
Re: What?
@ that one in the corner
My muddled post, above, is an example of why I should not try to compose text, on a cellphone, after an extended troubleshooting/repair situation where the caffeine no longer is working. :-(
Re: What?
I quite understand - he says, after re-reading his own post and noticing the odd missing word, some obtuse punctuation...
Re: What?
(3) AFAIK, not possible under Unix and Linux: file access permissions granted to specific users, as is possible under Novell Directory Services, and possibly (IDK) under Microsoft Active Directory. This is an administrative nightmare when a person is suspended from their job in Department A, but still works for Department B.
Of course you can , [1]facls .
[1] https://www.thegeekdiary.com/unix-linux-access-control-lists-acls-basics/
hold on there
Gee, just as I was deciding to switch to Linux...