Systemd-homed: Systemd Now Working To Improve Home Directory Handling (phoronix.com) 238
Freshly Exhumed shares a report from Phoronix, detailing a new set of systemd capabilities shown off by lead developer Lennart Poettering at the annual All Systems Go conference: Improving the Linux handling of user home directories is the next ambition for systemd. Among the goals are allowing more easily migratable home directories, ensuring all data for users is self-contained to the home directories, UID assignments being handled to the local system, unified user password and encryption key handling, better data encryption handling in general, and other modernization efforts. Among the items being explored by systemd-homed are JSON-based user records, encrypted LUKS home directories in loop-back files, and other next-gen features to offering secure yet portable home directories. Systemd-homed is currently being developed in Lennart's Git tree but hopes to see it merged for either systemd 244 (the current cycle) or systemd 245.
Container homedir (Score:5, Insightful)
Re: (Score:3)
I, for one, welcome our containerized home directory management overlords.
Seriously. I like the idea of an encrypted container downloadable to whatever distros I set up. Would take a lot of the pain out of alias management at a minimum. Not sure of the pros/cons against the LUKS loopback file, though, other than that container encryption is optional.
That slide deck was painful, though. Slow reveal by building one slide over multiple slides is a bad way to do it.
Re:Container homedir (Score:5, Insightful)
Re:Container homedir (Score:5, Interesting)
This is my stance almost entirely.
I think the idea of a solid well integrated stack of stuff most linux installs are going to need isn't at all bad. A lot of the existing tools, while proven and mature, are also showing their age and the pile of glue required to hold everything together is getting ugly.
The way it is working towards becoming the only option and anyone trying to use anything else is a second class citizen is what pissed me off. It creates a culture where people are discouraged from trying to do their own thing, because "everyone just uses x" and makes it hard to just replace the one part of your system you personally care about. This to me is going to stifle any innovation that might happen in an environment where everyone was free and encouraged to reinvent whatever wheels in whatever way they felt like.
Re: (Score:3, Informative)
The init system, for one. SysV is a bloody mess with a custom script per distribution, random crap that can be in any of them, and inheriting the environment from the commandline. There are things like pid files, and processes that it's hard to figure out where they came from. With cgroups a process can't escape, so you always know where a process came from, and you always can kill everything that belongs to a service.
Logging, too. Parsing log files is an annoyance. With journald you can just ask it what ha
Re:Container homedir (Score:4, Insightful)
To me, it's part of Linux becoming more professional. Who wants to wake up at 3 AM to deal with that a stray pid file has stopped something critical from starting? Who wants to spend their time on parsing yet another log file? Screwing around with regular expressions and Perl is only cool when you're young and excited about being able to do at all something that's not even a thing in Windows. Now the world has caught up, and 'grep /var/log/messages' isn't cool, it's clunky. A lot of systemd is very, very nice if you do this for a living, and stuff like parsing log files lost its charm 15 years ago.
This mostly isn't going to happen, because systemd heavily caters to distros by making their jobs much easier. And you're saying "please make it even harder for yourselves by managing two systems rather than one". It's not going to appeal to application developers either. Personally as a dev, I'll just provide a .service file and be done with it, because that also makes my life easier. I want to work on my app, not to spend hours figuring out the idiosyncrasies of init scripts on SuSE, which I don't care for.
Re:Container homedir (Score:4, Insightful)
The trouble with that one problem is that it's a probabilistic one. SysV doesn't really know what's running. You kind of need to know that, because you don't want to start a service 3 times and to cause a mess. So they went with the easiest option possible: When a service starts, it writes its pid file to /var/run/service.pid. And when it stops, it deletes it.
But even for a thing so simple, the possible problems are many:
What if the system resets, and the pid file remains? Now everyone does /var/run/ on tmpfs, avoiding that issue. But I don't think that was there initially.
What if the process dies, and the pid file remains? Most services (but not all!) will check if the pid in the pid file is running. And most will leave it at that. This works 95% of the time, except when the pid happens to match something completely unrelated. A very few services will actually bother to check that the pid corresponds to the right process. But for the ones that don't go so far, you very randomly have a service that refuses to start once in a blue moon.
What if the init script is written badly, and uses start-stop-daemon, but doesn't take into account that the process forks and so the pid file ends up containing a pid that only existed for a millisecond?
What if somebody copies the init script to make their own and forgets to change the pid file's name that's 30 lines into the script?
You get quite a lot of this in SysV. Sure, it's simple in theory. But in actual practice there are significant issues, which are often not entirely fixed, which are fixed differently in different places, and often not consistently, and which might bite you in the ass once in a blue moon. And a lot of this stuff just got rolled into the list of things you need to know to be a sysadmin, rather than being seen as something that shouldn't ever happen.
Re:Container homedir (Score:4, Informative)
It's a giant monolithic block.
Not sure which distro you use, but all that I've tried not only have loadable modules including device drivers, but they can self-load on need. Quite modular that Linux is.
It's very hard to contribute to for various reasons,
Again, not sure what that means, unless you mean getting something into Linus' kernel tree, then sure, it needs to be difficult. But you're free to write your own drivers / modules.
there are zero alternatives if you want to run a Linux system.
There are tons and tons of pre-compiled kernels on the 'net for free download in the 2.x, 3.x, 4.x, and now 5.x versions. All kinds of compiled-in modules and drivers, or very low-overhead kernels with tons of /lib/modules dynamically loadable drivers.
Not even sure how many hundreds of distros are out there, but there are certainly dozens of great ones.
Re: (Score:2)
Re: (Score:2, Troll)
It sounds cool. For the cool kids. Way cool. Gee whiz wallakers, oh so cool. The latest fad in new fads.
There never was any problem which this abortion will solve. Like blockchain, it is a solution in search of a problem. And the cool new cool buzzword of the day for the cool kids. And it is written in Rust, so like double cool! And it has blockchain, so it has three really cool newfangled things for the cool kids to be all "ya like so cool" about.
What of that is new? (Score:4, Interesting)
My PC's home directory has been synced to my home server and laptop (and backups), and accessible from my phone, for a decade now.
Encrypting home directories is a standard feature of every Linux distribution, and trivial to set up nowadays. (Although pointless, when you can still alter the OS to spy on you after you decrypted it to use it.)
And home directories are "containers" by definition. (No write rights outside the directory, except places that can and will be deleted at any time. No read rights to other users' private areas, unless allowed.)
The rest is the kernel's job. E.g. using a RBAC solution.
Looks like more half-assed and cancer-injected NIH from the world's most arrogant case of the Dunning-Kruger effect.
Just make/ruin your own OS already! And leave actual Linux and actual professionals alone!
Can't wait for this (Score:3, Insightful)
Re:Can't wait for this (Score:5, Insightful)
Why don't they just spin it off into systemd-ux already and stop poisoning a perfectly usable OS with stupid crap...
Re: (Score:2)
stop poisoning a perfectly usable OS with stupid crap...
But they put a lot of effort into Unity. The goal was to make ubuntu great again.
Re:Can't wait for this (Score:5, Funny)
Why don't they just spin it off into systemd-ux already
Call it the Poettering Operation System, or POS for short.
Re: (Score:2)
Re:Can't wait for this (Score:5, Insightful)
Systemd is definitely a feature creep.
I think that Systemd should be separated from Linux completely and be its own OS so that anyone that loves that could tinker with it as much as they like without contaminating the world for others.
Re: (Score:3)
so that anyone that loves that could tinker with it
Sysmtemd is separate. The problem is the people who love it are the distribution maintainers since it solves problems *they* had. Linux isn't a democracy, rather it's the original westward expansion of the 19th century USA where you could either stay where you are and get what you are given, or migrate away from the rest of society and plot out your own bit of land to do your own thing.
Re: (Score:3)
Re: (Score:2)
What a coincidence (Score:5, Funny)
Just this morning I was pondering why my .bashrc file wasn't binary gibberish. Hopefully this fixes it!
Re:What a coincidence (Score:4, Funny)
At least it will make it easier to get real work done. Just rename your home directory container file to have a zero in the file name and systemd will give you full root access. No more having to pester the overworked admins!
portable ??? (Score:5, Insightful)
other next-gen features to offering secure yet portable home directories.
Portable to where ? Certainly not portable to non-systemd systems. This seems to be a complete redefinition of the meaning of the word "portable".
Re:portable ??? (Score:5, Funny)
other next-gen features to offering secure yet portable home directories.
Portable to where ? Certainly not portable to non-systemd systems. This seems to be a complete redefinition of the meaning of the word "portable".
I think he meant "potable" -- for those who like Kool-Aid.
Re: (Score:3)
At this point, the number of major distros not supporting systemd is rather small and continuing to decline. Slackware, perhaps? But RHEL/CentOS, Debian, Ubuntu, Fedora, Mint, and Arch all use systemd by default. For those choosing non-systemd platforms, the existing architectures should work just fine.
Re: portable ??? (Score:2)
FUD. Gentoo, Funtoo, Arch? all support openrc or sysv init as first-class install options. The branch of Linux is growing that supports whatever was supposedly 'essential' from systemd, without the hard dependency infection, is growing back.
It'll take more time but like a tree stump with healthy roots it will grow back if enough people want it -- and they do.
Re: portable ??? (Score:5, Insightful)
Also the non-Linux: BSD, Solaris, AIX... no systemd option at all.
Right now a home directory served off an NFS share will work for all those as well as Linux (provided you do a small amount of tinkering). That's pretty portable. I'll admit the encryption is a big value-add...
Re: portable ??? (Score:4, Insightful)
Home-dir encryption is mostly worthless, except in laptops and data-centers. It only protects data that is not accessed, i.e. the user is not logged in. The scenario for that is basically your disks being stolen. If somebody hacks your machine, they can just wait until you log in and then get all your data.
Re: portable ??? (Score:2)
You could probably hack around systemd in Arch, but it's definitely not first class. That said, you can do many things (like networking / DNS / etc) without systemd, but it's still required for init.
Re: (Score:2)
Alpine!
https://alpinelinux.org/ [alpinelinux.org]
https://distrowatch.com/table.php?distribution=alpine [distrowatch.com]
Yes, it starts with busybox but you can install any/all real packages in place of the busybox versions.
Re: (Score:3)
Re:portable ??? (Score:5, Interesting)
I've been able to do that for decades. So he's got to mean something else, and probably unpleasant.
Re: (Score:2)
Same here. Linux home-directories are "portable" as they are.
Re: (Score:2)
What it probably means is using some sort of key to identify the user, instead of just a numeric user id. That would have lots of uses, especially combined with encryption.
Mountable filesystems won't be going away, so it is just a use case enabled.
Re: (Score:2)
What it probably means is
Why don't you read the article and know instead of guessing?
Re: (Score:3)
I don't want etc to follow me from machine to machine. Etc is for system config files, not for user config files. If i wanted that I'd put a VM on a flash drive.
Re: (Score:3)
Yes, that's why this is trying to sort out what you want to follow you and what you don't want to follow you.
There's already a mechanism for sorting out what you want and don't want to follow you; it's called the Filesystem Hierarchy Standard.
/etc is a mix of machine-specific and live-state information. But you've already been told that live-state information is supposed to be in /var.
/etc/mtab, great except that's a softlink to /proc/mounts.
You said above that
If you want to point to something like
If you need something like the 1.2 million LOC in the feature-creep that is the init sytem "basic userspace
Re: (Score:3)
The issue is that, just like Windows, various apps store things in different places. Microsoft had a hell of a time sorting that out.
Re: (Score:2)
Aren't they already portable? I think they have been portable for decades.
Re: (Score:2)
I avoid systemd like the plague (Score:5, Interesting)
I develop embedded communications systems. The last thing we need is a tentacle like ecosystem that infects everything it touches (random distro packages require systemd for who knows wtf reason that have no buisiness doing so).
When something in the boot order doesn't start for some reason the box STILL NEEDS TO BOOT and not get locked up in systemd. With svsv, our internal self-healing will either fix the issue or be able to send us alerts that there is one because the boot up actually finished.
Theres plenty of other reasons too that are well documented.
More JSON misuse (Score:5, Interesting)
Why?
Re: (Score:2)
Re:More JSON misuse (Score:5, Insightful)
Re: (Score:2)
Why?
I'd actually rather it was XML as it's more self-descriptive and validation is easier to design in my experience. XML is old-fashioned, though, apparently.
Improve? (Score:3)
I'm sure there are interesting and creative ideas out there for home directories, but this sounds a lot like fixing something that isn't broken. Which is often a sign of someone (or some project) with no clue what they are doing.
Re:Improve? (Score:5, Interesting)
It's fixable, but always requires custom configuration. The new homed will automate it.
Re: (Score:3)
Got on a system that used NFS-mounted home directories for portability across multiple systems. That was...interesting.
And then they screwed up NFS permissions and a lot of stuff became visible that wasn't supposed to be.
Re: (Score:2)
Got on a system that used NFS-mounted home directories for portability across multiple systems. That was...interesting.
And then they screwed up NFS permissions and a lot of stuff became visible that wasn't supposed to be.
Seems like they understood ownership, but not groups.
Re:Improve? (Score:5, Informative)
Agree. Actually trying to be open minded about this one. A lot of the problems brought up (from what I could muscle through of that slide deck) are things I've complained about for years. In a world where having multiple devices and shared file systems is very much the norm, Linux feels like its in the dark ages. I said it below already, but it's crazy to me that I can't for instance have firefox open on my laptop and desktop at the same time on a mounted home directory without resorting to separate profiles.
When it comes to security, NFS has two security modes: swiss cheese UID based, secure but super complicated and fragile kerberos based. We've need a middle ground for home users that mostly just works with minimal setup.
I'll admit to some NIH kneejerk, especially around the encryption stuff, but that is largely because I've rolled my own over the years.. which is largely because a good out of the box solution still doesn't really exist. All the tools are there, but gluing them together is still harder then it aught to be. I'd welcome something that does a good job at just making this stuff work in some kind of sane manner.
Re: (Score:3)
Re: (Score:2)
OpenCloud?
Actually asking. Quick google search turned up nothing that seemed related.
I've spent a fair bit of time trying to accomplish the use case of:
- Live shared file system (actually shared, not synced dropbox style).
- Encrypted
- Reasonable performance
- Ideally centralized identity, though could live without this
I've yet to find anything that ticks all those boxed besides kerberos+ldap+nfs. I'm definitely interest if something actually exists or is on the verge of existing.
Re: (Score:3)
It probably will not work well for you if you already haven't had luck with a dropbox style setup since it does something similar. But it did mean we had one server with the shared home area and other machines mounted it like NFS. It worked for us, but our use case might have simply worked well with it. No one way, for instance, running firefox with it.
Re: (Score:2)
Ah, yeah that makes more sense.
I've looked into owncloud for other uses, but yeah, it doesn't really give me what I want as far as shared directories.
Re: (Score:3)
These days people just use Docker.
Re: (Score:3)
Yes, NFS is used quite a lot. My employer uses it to have shared home (and application and program) mount points between all the computes on the Linux network. There are thousands of users and machines on the network. LDAP is used for authentication and user management. I have a similar setup at home, though obviously with quite a few fewer machines and users :)
The biggest problem is that it is difficult if not impossible to have a laptop in this situation. The machines all like to be online all the ti
Re: Improve? (Score:2)
Don't use NFS, it's broken and has been forever.
Just designate a shared subdir within your homedir, sshfs mount that wherever (or us Next loud/sync tool of choice there) and Bob's yer Uncle.
Re: Improve? (Score:2)
Re: (Score:2)
Re: (Score:2)
Re:Improve? (Score:4, Insightful)
Can't that be said about many (most?) of the systemd modules?
Re: (Score:3, Insightful)
It can and with more than just a bit of justification. Systemd created problems, it does not solve them.
Re: (Score:3)
No json (Score:4, Insightful)
I don't really see what's broken for the vast majority of users about most of those things.
And please dear god no JSON. It is quite possibly the worst possible format for configuration information.
At least use YAML if we must do something so silly.
But really, can these people just stop fixing things that aren't broken?
Re: (Score:3)
Could be worse. Could be XML. At least JSON is (mostly) reasonably readable.
Re:No json (Score:5, Insightful)
You've obviously never misplaced a comma in your life. Lucky you.
Re: No json (Score:3)
Re: (Score:3)
I hope that's sarcasm. My ~/.bashrc executes a lot of things, especially at work where I have more going on. It uses 'bind' to modify the shell configuration. It interrogates the system to see if it is an interactive shell or just running a command, or if it is local or remote. It checks for the existence of files before doing things. It might execute ClearCase commands (at work) to ensure that views and VOBs are started. It runs 'fortune' to give me a nice joke on each new shell.
Arguably, most things
Re: (Score:2)
Re: (Score:2)
Solution seems overkill, but there is some truth in some of the problems.
I like mounted home directories, but a lot of programs (ex: firefox) can't handle being opened at the same time from multiple machines, and for a lot of things (ex: window managers) you'd want the same basic configuration but tuned on a machine by machine basis. Now these problems should be handled at the program level, but I'd welcome a kind of cleaner unionfs type deal where bits and pieces of your home directory are machine specific
Re: (Score:2)
The worst? Really? Worse than XML? Worse than the Windows Registry?
Ready for some real pain? Read on and on and on (Score:2)
SYSTEMCTL(1) systemctl
Lead developer Lennart Poettering (Score:4, Insightful)
Glitch once take everything down.
Just my 2 cents
I have a way to manage my home (Score:2)
Just my 2 cents
Re: (Score:3)
I have my home directories local and basically symlink out anything I want shared across machines. A bit of a pain, but its been my workaround for some time and I've gotten used to it.
I love the idea of just having my home directory on an nfs mount, but it (still) causes way too many problems.
A modestly inexpensive proposal (Score:5, Interesting)
Can we all agree to give Lennart, say, $5 each every year with the condition that he never develops software again.
Re: (Score:3)
rich (Score:2)
That would make him become super rich.
Re: (Score:3)
Christ, I'm in. I'll give him $10.
Re: (Score:3)
Count me in. I guess he was playing the long con, and we've finally given in.
analyzing why this upsets me (Score:5, Insightful)
Re:analyzing why this upsets me (Score:5, Informative)
It has always been a tricky balance. Having more than one way of doing things is great, but it does make things more complex and often less usable and reliable. A good well integrated all-in-one solution is going to have a much better chance of being usable and reliable, but at the expense of flexibility and as you said, diversity. There is a lot of value in having a bunch of disparate groups all coming up with their own ways to accomplish the same thing, but trying to glue all that together into a cohesive system for regular users is difficult.
I'm actually not as opposed as I once was to a big all encompassing stack of services that is designed to work well together. I'm not saying systemd is that in practice, but the concept at least is valid.
What would be really nice if if multiple people were also trying to achieve that same goal in different ways. Right now your options are basically to glue together a bunch of semi-compatible tools with piles of shell scripts like we've always done, or go with systemd.
Re:analyzing why this upsets me (Score:5, Interesting)
"Right now your options are basically to glue together a bunch of semi-compatible tools with piles of shell scripts like we've always done, or go with systemd."
Shell scripting is a CENTRAL UNIX FEATURE. Some people don't seem to understand that is a big deal. When Unix was invented, literally none of the stuff that characterizes it was common place. Flat files, everything's a file, unstructured file access, shell scripting, self hosting... All of that was unusual.
When people complain that their Unix system is built out of shell scripts, what they're doing is proving that they don't understand Unix.
When people laud systemd for unifying the various parts of Linux, they're proving it all over again. Systemd does nothing we couldn't do before, it doesn't make the system simpler, and it makes Linux less unixlike by failing to conform to the most basic law of Unix programs: do one thing, do it well, and do it interoperably. It's an attempt to make Linux into windows in spite of the fact that this is not a desirable outcome.
People who don't understand Unix and don't have the competence to reimplement it even poorly apparently have to settle for fucking it up for everyone else.
Re:analyzing why this upsets me (Score:4, Insightful)
I like diversity in general, but not in the base definitions/environment/infrastructure. Like do we drive on the left or right side of the road, do we read from left to right or right to left, do we use metric or imperial units, what shape is the electric plug and so on. The equivalent in computers are things like little or big endian, line endings, path delimiters, how do we do basic I/O and such. For the most part I try to use languages/libraries that abstract away the differences, not just between Linux distributions but between Win/Mac/Linux altogether and between different hardware and types of configurations. Like 99.999% of the time I don't care if the input comes from a PS/2 or USB or Bluetooth keyboard but the system obviously has to deal with it somehow. So far, I doubt I've said anything controversial.
You might say the answer is standards and libraries. But not everything can be solved by each application doing their own thing, for example audio. I'm not talking about Pulseaudio, I'm talking about OSS, ALSA, ESD, Jack etc. that existed before that to negotiate and mix sound between applications and hardware. Linux has many of them like timed, bluetoothd, inetd, crond that are all effectively mini-monopolies in their little corner. For that matter you can include X, almost everything that wants to draw to the screen talks one protocol with Wayland trying to make a do-over. Same with the file systems and the three-level, three type permissions (user/group/other with read/write/execute), the file system structure and the other foundations everything else rests on.
Part of me absolutely wants to throw all that micromanagement out the window and say have one "system environment version" that defines all the available services and their minimum versions. I guess it's something like Linux Standard Base, except it really never took off. Like it's the applications that are supposed to be diverse, not a dozen ways to play sound. The other part of me is worried that in that big grab bag some of the services will be lacking in features or rotten in quality but become the de facto standard simply by being part of the systemd family. But it is possible to work within one project and make it work well if you have the right person on top - after all the Linux kernel works that way not through competing forks. It's just that Lennart Poettering is no Linus Torvalds...
OK, then. Slackware it is. Or maybe Arch. (Score:3)
Once I get good information about how easy/hard it is to run KDE on either of those, I'll be planning my migrating off of systemd-based distributions. Enough is enough. I'm sick and tired of Poettering's bizarre Windows-inspired changes to Linux.
Re:OK, then. Slackware it is. Or maybe Arch. (Score:4, Informative)
Arch was one of the first to adopt systemd
Re: (Score:3)
I used to use it on Debian before systemd infected it and now I use it on Devuan
"Fixing" things that are not broken (Score:5, Insightful)
The major contribution of systemd, that nobody with a clue wants.
Microsoft (Score:2)
They don't use systemd in their WSL or WSL2 Linux builds.
It seems they aren't fans of it either.
Thought it sounded stupid at first (Score:3)
My main concern was how to prevent a random usb key with one of these home directories on it from letting anyone log in,
but he addresses that with signed user credentials.
How will that work in practice though if you want to change something? Do you have to send it to the server to get signed?
What if I want wheel but only one my personal machine, not on every pc in the lab?
"Aaaaaaarrrrrgh... SystemD! The devil! Kill them a (Score:3)
*sits back* *grabs popcorn*
OpenBSD, Slackware.... (Score:3)
Re: (Score:2)
The trouble is, no-one's come up with a better system. People complain about the issues with LDAP, Kerberos and NFS all the time, but no-one's actually produced a better solution. I hate to say it, but the "free software community" seems to be far better about complaining about systems and aping them than actually making something better. Where are the free software community's superior replacements for PGP, LDAP, Kerberos, SMB and NFS? They simply don't have any - just varying quality implementations o
Re: (Score:2)
I once became so frustrated with kerberos that I actually gave serious thought to giving it a go. I still may one day do so, but I know I'd be in way over my head. Anything to do with security and crypto is hard to do properly, and it's not my area.. nor is authentication. I have no illusions that any solution I could come up with would be good, let alone see any kind of adoption, but I'm tempted for the reason you describe.. it seems like no one else is doing it, and even if I just end up with some pseudo-
Re: (Score:2)
Yeah, I realise that. These are difficult problems, and solving them properly is difficult. Kerberos is necessarily complicated to deal with that. It makes plenty of compromises for pragmatism and to make implementation practical, but there's no way it's ever going to be simple because the problem it tries to solve is inherently complex. The only people who've really tried to make LDAP/Kerberos straightforward are Microsoft with Active Directory. But AD relies on a bunch of largely proprietary convenie
Re: (Score:3)
I think you nailed my main complaints with LDAP. It's the poster child case in how flexibility can become a detriment. Even the "defacto standard" ways of using LDAP are loaded with variations from setup to setup, and this adds so much complexity because every tool that deals with LDAP needs mechanisms to handle whatever arbitrary schema you are using. Also while admittedly clever, I really hate their whole "lets store our own configuration in ourselves" thing.
As far as kerberos complexity goes though, I th
Re:Non hardcore *nixer here (Score:5, Informative)
There was also a rather undemocratic element to it. RHEL and a few others really pushed for it based off the needs of their core developers and the types of clients they had, and with their larger share other major distros followed suit. This means it really pulled linux in a direction optimized for the type of user RHEL caters to, better when you maintain tons of servers on VMs, more frustrating when you use it in embedded systems or small sets of manually maintained servers. I hear it is also better for desktops/laptops in terms of boot time, but I'm less familiar with that.
Re: (Score:2)
You cant blame redhat. Every major distro jumped onto systemd, most before even redhat did
Re: (Score:3)
Funny that Redhat's income is from selling support and they are the ones who pushed it...
Re: (Score:3)
Who (besides you) claims people "hate" systemd? It is just inferior tech and not something people chose to use, given a choice. No reason to put any emotion into that.