Linux systemd is now going to manage user /home directories.

I don't... I mean, I just can't...


Let me try again.

1) You are going to let a piece of software manage something which is freakishly sensitive and can create A LOT OF PROBLEMS down the line.

2) ALL software have bugs. Lots of them. And systemd is, shall we say, a highly complex piece of sotware, that contains a LOT of bugs.

What could possibly go wrong? ๐Ÿคฆโ€โ™‚๏ธ

ยท Web ยท 13 ยท 22 ยท 16

This just makes me more and more convinced that systemd needs to be avoided at all costs.

I will manage it for you if needed but I will never use anything with systemd in my own projects and servers.

Show thread

@ParadeGrotesque years ago some visionnaires told peuple this thing is an oger. They were blacklisted, they d'รฉtรฉ tinfoild hated.

Now Time has come to prompte non systemd distros or it won't be a grave but the future de choose

@ParadeGrotesque I was thinking, "What's the point of this?" but then I read the comments. I can see the use case in how they describe it in the comments, but two words come to mind with this...

Lock. In.

Seems to be a great tool for making home directories portable....if you use systemd. What if you want to move your home directory to a BSD or a non-systemd distribution?

Aye, there's the rub.


Precisely. Lock in is the correct term.

Systemd main dev is Lennart Poettering, who is a Red Hat employee, which means he works for IBM.

Sure, this thing is GPL licensed, but it's clearly an attempt to sink yet more things into systemd that should not be managed by it.

Soon, given the complete lack of experience a lot of devs have with "classic" UNIX, everything will be an evil and toxic "Linux only" monoculture.

@ParadeGrotesque I think the IBM-RH thing (other than him working for them) is stretching it a bit, but I do see systemd encroaching into more things that should probably be left alone. The comments in the Phoronix post definitely show that.

@ParadeGrotesque I wonder if there will be a breaking point for the Linux community where it would turn distros to removing it for something else that sticks with the UNIX philosophy.


It's too late for that. Gentoo, Slackware, Devuan and the BSDs are (as far as I know) the only options left, along with smaller players.

Gentoo attitude is interesting, since they support pretty much everything under the sun *and* provide docs for it:

@ParadeGrotesque @claudiom I would mention Artix as well. Being an Arch derivative with thousands of packages it is also one of the bigger projects.

Then there is Alpine Linux, which is small but well suited for smaller servers and routers (when building a DMZ I mostly choose it for the outer or inner firewall, the other one is OpenBSD)

And of course MX Linux, a Debian derivative and currently number one at @distrowatch


It may be stretching things a bit, but you have to remember that IBM was a master at Lock in.

The very first "IBM Compatible" were, after all, mainframe systems such as Amdahl.

I am not saying RH is trying the same thing, but it really, really looks like it. Linux Lock In.

Sad thing is, this is something that should be left to the user. A reasonable Linux should offer the admin a choice in init systems, from System III to systemd, with other options thrown in.

@ParadeGrotesque Agreed, it should be left to the user. In the end, I think it still is. This is basically a "feature" for those using systemd-based distros. However, if it's going to be "on by default" for all distros using systemd, then that might be a problem. Maybe you can still export things the old-fashioned way, but we'll have to see once it's out there officially.

@ParadeGrotesque And, yes, I do remember IBM locking people in to their PCs during the clone wars of the 80s and early 90s. Look at how well that worked for them. There might be a possibility, but most will catch on I believe.

@ParadeGrotesque @claudiom systemd was headed in this direction long before ibm acquired RedHat. Systemd should have focused on the init system that is was designed to replace only. All the rest of the stuff should be "plugins" to the init system. Not built in requirements to further enlarge the ever growing windows replacement.

@cobra2 those last two words; didn't Poettering work for Microsoft many years ago? @ParadeGrotesque

@ParadeGrotesque @claudiom
kinda reminds me of how most devs don't know classic internet protocols, so they put everything on top of HTTP

@ParadeGrotesque @claudiom Red Hat's been staging a coup for years on the rest of the Linux world, and systemd has been the vehicle for that coup. Debian, Arch, et al mad a Faustian bargain when they decided to adopt systemd, and the result is that Red Hat is increasingly calling the shots for Linux as a whole.

It's not even an original idea, though its scope beyond an init system and daemon supervisor is. For other examples see Solaris's SMF & Apple's launchd.


It was "just" LUKS does not even begin to cover it.

I have noticed systemd has a very nasty habit of keeping information to itself -- information that was previously held in human-readable log files (see: journald and friends).

Case in point: JSON is a terrible file format. And systemd-homed uses JSON.

It's another step in making everything a container, and a virtual machine, in which users are never created or even needed. Which, itself, is a very debatable trend.

@claudiom @FiXato

systemd has never and will never manage anything on any of my *nix devices.

@ParadeGrotesque Thanks for the link!

I fail to see the problem that's being solved here.

I just migrated from one machine to another. I copied my files over and put all the dot-files in a separate directory to re-use or not, depending on the circumstances.

I started using Linux precisely because I could understand and configure the system. It's probably time to switch to Devuan or Slackware, because I'm already getting systemd'd and starting to forget old ways of doing things.

I've recently migrated 10 production servers from Jessie -> ASCII -> Beowulf. It all went without a hitch. I did two reboots, one for changing the init system and the other because I upgraded the kernel (not required, but nice). Each migration took about 20 minutes.

I'll be moving all my other Debian servers to Devuan, in due course.


What are the quirks of using Devuan? Specifically with software install? Are you back to cobbling up your own init scripts?
@visiblink @ParadeGrotesque

I made a couple of changes to the dist provided SysV init scripts, nothing major. Now I think about it, I'm not sure where they came from, I'd need to check.

I actually use Runit, as well. I find it works well with my Python stuff and Gunicorn etc. For Runit I pretty much use one template and just modify to suit. Never had any trouble with it.

@visiblink @ParadeGrotesque

There aren't any Devuan quirks, it just works like old-style Debian with SysV init. If you run Devuan (or any non-systemd distro) some applications won't be available as they depend on systemd, notably most Gnome stuff. Wouldn't bother me as I use Xfce.

@visiblink @ParadeGrotesque

Oh yeah well that isn't a problem for me. I wonder if lxqt has any systemd requirements. Doubtful. Cool! I might have to go this route and get away from centos on my production stuff..
@visiblink @ParadeGrotesque

@fitheach @paulgatling @visiblink @ParadeGrotesque they dont just port over the changes the bsd's have to make for them to work with sysrc?

now they are going to break home diectories? what if you have user files outside of home?

when i heard systemd was written by the same guy who wrote pulseaudio, i thought "no wonder it is a piece of crap."

@ParadeGrotesque nothing could go wrong given i dont use poetteringd

he has the right problems in mind (well, arguably; some problems he proposes are legitimate in the unix world) with all the wrong solutions
@ParadeGrotesque Oh boy, can't wait for all the non-systemd distros needing "ehomed" for compatibility with modern software that uses systemd as a hard dependency

@ParadeGrotesque Sounds like I'm not updating systemd on my servers until I get some time to move to runit distros...


There's a lot of hate for SystemD but what I hear far less about is how those who don't like SystemD propose to address the problems that it solves.

The "if it ain't broke, don't fix it" argument only works if it ain't broke, but it is broke. Many things on a modern GNU/Linux sysstem have been broke, and are less broke now. User and home directory management is also broke, and so it's time to fix it.

If not with SystemD, then it'll be something that just does the same job.


My issue is that I'd really like to know what problems, exactly, is systemd "solving".

Log management? Nope.
Init? The only thing systemd is good for is speed.
User management? Oh please.
Disk management? Nope.

It seems to me systemd is more a solution looking for a problem than the other way around.

@ParadeGrotesque Have you read any of the docs on SystemD? It solves issues around power management, around services coming up and down properly.

The new stuff is around the unification of users and how there are so many separate systems around authentication, around information about users, resource limits, and how user information is spread across the system rather than being contained in the home directory.

If you want some presentations talking about the problems, I can point you to them.

@emacsen @ParadeGrotesque Being someone who is trying very hard to be systemd agnostic; I do think one thing that gets overlooked (which is an unspoken point of resentment.) Is that systemd is ultimately wresting a lot of architectural choices away from distributions.

Ultimately this is something of a design goal; it's trying to standardize and unify linux plumbing.

And I can even squint and see the benfits of standardzing some things across distributions about home directory management.

@emacsen @ParadeGrotesque But I gotta concede its always bound to create a lot of resistance. Distributions are a lot more than package managers. And their kind of being treated that way on multiple fronts these days.

Distributions and power users have been used to making those decisions about their OSes for a long time.

@emacsen @ParadeGrotesque

My personal preference is for architectural diversity. Having all the distros feel "samey" is honestly boring to me.

But Ive decided to concede that, that isn't in vogue and I need to get with the program.

@trashheap @ParadeGrotesque What benefit does architectual diversity provide you in this context?

As a developer I see architectual diversity without stable APIs as a barrier to software development or stability.

As a system integrator (sys-admin, devops, etc.) it means I have to remember or abstract away arcane knowledge.

There are some potential benefits in very specific circumstances, so I'm curious what you're thinking here?

@emacsen @ParadeGrotesque

No objective benefit whatsoever.

As a user and sys administrator, ive been very opinionated on architectural choicese; and ive picked my OS based along various personal prefrences ive agregated.

Sometimes adjusting those prefrences with experience.

This causes me to strongly identify with my choice of OS; and gives me lots of incentive from time to time to explore others.

But it's entirely subject and emotive on my part.

@emacsen @ParadeGrotesque I concede it's actually not important; and it's why ive tried to grudgingly embrace systemd on systems of mine where it lands.

@emacsen @ParadeGrotesque That being said; im surprised that among alternate OS enthusiasts, architectural diversity isn't as highly valued in and of itself as I first would have guessed.

@ParadeGrotesque Honestly that looks pretty sweet. systemd-homed looks like something I'd use.

@ParadeGrotesque no its not and you didnt read properly. movable homes it is. but Beissreflex is a nice thing to have.

Sign in to participate in the conversation
Mastodon @ SDF

"I appreciate SDF but it's a general-purpose server and the name doesn't make it obvious that it's about art." - Eugen Rochko