51–60 of 449 posts
I don't like it when my process init and logging system also tries to manage my volume mounts. If I unmount a device, I don't want systemd going behind my back and remounting it for me. It's non standard behavior changes like this that drive systemd hate.
The big thing, for me, that systemd brings to the table is consistency. Managing services on CentOS is the same as managing them on Debian which is the same as managing them on OpenSUSE. This makes it a lot easier to deal with the various different Linuxes.
Also, it seems to make writing a service a lot easier. Instead of the service needing to daemonize, write out a PID file, or whatever, it can just be a program that does its thing without forking, sends its output to stdout/stderr and systemd takes care of the details. I tried to go through this exercise on a FreeBSD system and ended up just installing 'pm2' to do it for me. I subsequently figured out what I did wrong, but pm2 is working and I see no need to change it.
Obviously systemd isn't suited for every use-case, but it doesn't seem nearly as bad as some people make it out to be.
Based on my experience and all the anti-systemd posts online, I expected to dislike it.
But on it's merits I really like the consistency it brings to the "system layer" of the OS.
I find it's shame when developers skip over systemd for consideration, adding extra layers of complexity when systemd alone would have been sufficient: For example, using Docker when the basic isolation features of systemd would do, or using "forever.js" to manage Node.js processes, when systemd could could be saving 15% memory overhead per process, using software already installed in the base system.
On the other hand, I do support diversity of software and am glad to see some other options still being promoted and used. The dangers and weaknesses of monoculture in the physical world apply to software systems as well.
I get no end of bemusement from open source advocates that think it makes any kind of rational sense to campaign against an open source project. THIS IS ALL OPEN SOURCE. Freedom and choice is the whole point, isn't it? If you prefer an alternative or forebear to systemd, that is great. Use it. Advocate for the system you prefer. Convince people that the choice you have made is better. Meanwhile the vast majority of d…
Open standards are more important than open source. Choice is indeed the whole point, but systemd is designed to take my choice away. It doesn't matter how good an init system I make, if it starts getting any traction then systemd will come up with a new incompatible API for doing something, Gnome will take a hard dependency on that API, and distributions won't be able to ship my init system. It's worth realising tha…
It's all open source.
It's laughable to worry about Gnome taking a hard dependency on an API when hundreds of software programs take a hard dependency on Gnome. Hypocrisy, much?
Meanwhile if the maintainers of GNOME betray your trust, it sounds like you should hate this hypothetical GNOME for the same reasons you apparently hate systemd. Or rather than hating it, you could just fork it. If enough people agree with you, a disentangled fork will inevitably be maintained. Hell, people maintain forks of GNOME for BSD—and that's even more impressive since there is no open source monoculture more monolithic than the Linux kernel API dependency.
You could quite possibly be right that the open source movement couldn't have have started with the design principles of systemd[0] but it's naive to assume that what was good for open source in its infancy is still what's best for open source in its coming maturity.
[0] Given that the open source movement has monumentally benefited from monolithic design principles in the form of the Linux kernel, I think that hypothesis is demonstrably absurd and easily rejected.
Earlier quoted context omitted.
>And you can't have a distro out there without GNOME, so... LxQt and any KDE-powered distro would beg to differ. But I agree, in general, that KDE-default distros are few and far between. And the KDE team probably has better things to do with their time than try to maintain a systemd-less fork.
They're rare in the US. KDE-as-default is close to the norm in Europe. KDE has long been a more crossplatform system than Gnome (much better windows support (and even e.g. solaris), BSD is treated as first-class) so I'd hope they'll continue to avoid being systemd-dependent.
Based on what?
The most recent reason I found to hate systemd was it replaced my system DNS resolver with its own (thus requiring me to modify /etc/systemd/resolved.conf, and doing the daemon-reload-service-restart-hokey-pokey, to get a host to function on a network+VPN like it did before). The only reason systemd has its own resolver is they wanted extra DNS functionality. Did I ask for these features? Did I want a new resolver? N…
WSL!
WSL somewhat annoyingly has a custom/proprietary init system. Partially due to it's "interesting" integration with windows, and partially because it's not even really a full linux system yet.
I'm curious if with the switch to WSL2 where they will begin shipping a full linux kernel if systemd will be included or will they stick with their current custom solution?
I get that not everybody likes systemd, but a lot of the criticisms seem misguided and looking at sysvinit with role-colored glasses. For example, people are complaining about logind being included, but forget that consolekit was unmaintained before that. Yes, there's parts to systemd that not everyone will use, like container support, but in that case you can pretty safely ignore that use case. For me, systemd has p…
> I can't say I miss sysvinit. Distros that choose not to employ systemd do not necessarily retain sysvinit.
I guess it's part of the confusion too, most of the systemd work was replacing the "rc bits" (process startup and management) not replacing PID1 itself.
The most recent reason I found to hate systemd was it replaced my system DNS resolver with its own (thus requiring me to modify /etc/systemd/resolved.conf, and doing the daemon-reload-service-restart-hokey-pokey, to get a host to function on a network+VPN like it did before). The only reason systemd has its own resolver is they wanted extra DNS functionality. Did I ask for these features? Did I want a new resolver? N…
I don't think being angry at anyone will solve the problem. Using and advocating non-systemd distributions might help much more.
I do find it funny that people crap all over systemd, but don't seem to have a huge problem with launchd, despite the fact that systemd was almost a direct port of it. Personally, while I do think that systemd's scope might have been a bit too ambitious, I do find it easier than something like Upstart
I also think upstart was a bit nuts... but how do you think about openrc vs systemd?
I remember liking how easy it was to set up startup scripts in FreeBSD, so I think I like it? I'll admit I haven't used it as much as systemd or Upstart, so I can't give a strong opinion.