3 ms·

The issue I noticed are - systemd supporters are mainly desktop users, so their opinions are irrelevant because as a desktop user the only thing you might do i

The issue I noticed are - systemd supporters are mainly desktop users, so their opinions are irrelevant because as a desktop user the only thing you might do is restart a service, is important to listen to server admins that know what they are talking about - GNOME (other Red Hat tech) depends on a systemd component and refuses patches to make it independent, so basically GNOME is forcing systemd adoption and is trying to block alternatives by refusing patches - systemd projects and fans will ask you to create a better alternative to systemd if you don't like it, but if you try to promote an alternative they will try to block the alternatives by refusing to accept patches to keep projects systemd independent. Monoclultures are bad, when systemd will o longer be popular and we want to implement a better succesor we will discover that many things are hard coded to depend on some it's many components. About what is the best init system, I don't know , I am desktop user, and as I said all desktop users opinions are probably "it works for me so you are wrong"

doublerabbit 7y ago
I dislike it for the fact if a process hangs or if your network isn’t ready you get “Starting process - 2/5minutes” If your trying to hastely safe shutdown “Waiting for process to stop - 3/8minutes” Sure, you can alter the timer but that’s then just another task I shouldn’t need to do. Dependencies within unit files It’s own log formatting in a binary format It’s icky, it feels clunky and while it works it doesn’t feel smooth.
- PlutoIsAPlanet 7y ago
  This isn't actually an issue with systemd, it's just how the distro has configured it. systemd is really good at doing what it's told, if it's told something bad it will do something bad.
ninkendo 7y ago
> systemd supporters are mainly desktop users > is important to listen to server admins that know what they are talking about Huh? I got on the systemd train when race conditions with pidfiles caused essential services not to restart correctly for the umpteenth time on a small subset of the thousands of bare metal servers I managed. Not a single sysadmin I worked with liked anything about sysvinit. Nearly every distro-provided init script for the services we cared about had some sort of subtle bug which we had to manually fix with our configuration management. Or maybe somebody had been diagnosing an issue and manually run “sudo /etc/init.d/someservice start” and now congratulations, the service inherited the cwd of the person who ran the init script. Or you have to deal with inconsistent log rotation behavior, or the service coming up before the network was ready on boot (better rename the symlink to 99_myservice!) I don’t know where people get the idea that sysadmins prefer sysvinit. Maybe ones that only run one or two servers? After having managed tens of thousands of them across many datacenters, systemd is a clear and obvious win.
- simion314 7y ago
  I am not saying that all/most sysadmins hate systemd , I am just annoyed but the random Joe Desktop Linux users throwing his opinion. I like reading sysadmin experience and what issues they have like you but also ones that had issues with systemd bugs and behavior and a random Fedora user will show up and repeat something he has no clue about. I personally had no issue with systemd or upstart or any other I used so I would wish desktop user like me would read more and comment less about what is better.
  - xnyan 7y ago
    Are the uninformed opinions of joe user really influencing decision makers? The internet is mostly filled with people spouting uninformed opinions, it does not seem worth it to spend any energy caring about it.
    - simion314 7y ago
      I don't think the decisions made in Debian were influenced a lot by the average joe user, my complaint is about the discussions, my complaint is that say if I find a thread that compares all the init systems I would prefer to read expert opinions on it, people that had success with systemd but also people that had trouble with systemd , but you get average joe pasting same shit all the time on both sides. But yeah you are right(this always happens on the internet), I was also guilty of this, I remember back when C# appeared and I was sure is the best thing ever and it will soon replace all the other languages. I think at my past enthusiasm for C# when I see Rust/Go/CoolLang evangelizing why X is better and in 3 years it will dominate.
pinopinopino 7y ago
My problem with systemd is that it is not just a init system. It goes further than that and it exposes apis that third parties use. It is tempting to use systemd functionality as developer, but then you are no longer portable to bsd, darwin or other systems. I think systemd is bad because it will break links between the various unixes. That being said, as system administrator, I found systemd mostly to be ok, but sometimes you run in non reproducable problems. I have sometimes that servers don't come up, because the network unit didn't get started. Restarting fixes it. I haven't been able to reproduce it and the logs are also not very helpful.
- jbverschoor 7y ago
  I don't know.. your application can and should be portable.. But if you want to support systemd, sysvinit, launchd, windows-services or whatever, that's up to you. It's this tiny part where you need to commit to some piece of technology. I don't see the difference between creating a systemd config file, which is super clear and managed properly and to create a bunch of init scripts that depend on pid-files which might be stale and where those directories are abitrary.
  - kdmccormick 7y ago
    If I understand correctly, GP is saying that systemd also provides non-init-related functionality. If a package you develop relies on only systemd's init capabilities, it'd probably be pretty straightforward for someone to port it to an OS with a different init system (like BSD). If your package relies on other systemd capabilities, though, the task of porting gets much harder.
    - majewsky 7y ago
      > If your package relies on other systemd capabilities Such as? Which other "systemd capability" besides the init system part exposes an API to general user-space applications? The only one I can think of is logind, for which an alternative implementation (elogind) exists.
bonzini 7y ago
> depends on a systemd component It depends on a systemd API and there is an independent implementation, elogind. GNOME runs just fine in the BSDs, so its dependency on systemd is a strawman.
cturner 7y ago
For Init, desktop use-cases can be challenging. They can cover hot-swap networking, hot-swap hardware, sleep/restart. Scenario: a user is playing an audio stream that comes over the network. They put their computer to sleep. They restore it later, at another site. Consider the dependency calculation to restore that mixing pipeline, without sending clicking noises to the user.
jbverschoor 7y ago
I only use linux on servers, and have been doing that since I used redhat and slack in the '90s. After that I moved to FreeBSD and since about 15 years, I'm on Debian. sysvinit scripts are horrible to create and operate. It's easy to set tup dependencies for network or other services. I haven't used it to run cron-like tasks, or inetd-type servers, but I don't have a need for that.

doublerabbit 7y ago

I dislike it for the fact if a process hangs or if your network isn’t ready you get “Starting process - 2/5minutes” If your trying to hastely safe shutdown “Waiting for process to stop - 3/8minutes” Sure, you can alter the timer but that’s then just another task I shouldn’t need to do. Dependencies within unit files It’s own log formatting in a binary format It’s icky, it feels clunky and while it works it doesn’t feel smooth.

PlutoIsAPlanet 7y ago
This isn't actually an issue with systemd, it's just how the distro has configured it. systemd is really good at doing what it's told, if it's told something bad it will do something bad.

ninkendo 7y ago

> systemd supporters are mainly desktop users > is important to listen to server admins that know what they are talking about Huh? I got on the systemd train when race conditions with pidfiles caused essential services not to restart correctly for the umpteenth time on a small subset of the thousands of bare metal servers I managed. Not a single sysadmin I worked with liked anything about sysvinit. Nearly every distro-provided init script for the services we cared about had some sort of subtle bug which we had to manually fix with our configuration management. Or maybe somebody had been diagnosing an issue and manually run “sudo /etc/init.d/someservice start” and now congratulations, the service inherited the cwd of the person who ran the init script. Or you have to deal with inconsistent log rotation behavior, or the service coming up before the network was ready on boot (better rename the symlink to 99_myservice!) I don’t know where people get the idea that sysadmins prefer sysvinit. Maybe ones that only run one or two servers? After having managed tens of thousands of them across many datacenters, systemd is a clear and obvious win.

simion314 7y ago
I am not saying that all/most sysadmins hate systemd , I am just annoyed but the random Joe Desktop Linux users throwing his opinion. I like reading sysadmin experience and what issues they have like you but also ones that had issues with systemd bugs and behavior and a random Fedora user will show up and repeat something he has no clue about. I personally had no issue with systemd or upstart or any other I used so I would wish desktop user like me would read more and comment less about what is better.
- xnyan 7y ago
  Are the uninformed opinions of joe user really influencing decision makers? The internet is mostly filled with people spouting uninformed opinions, it does not seem worth it to spend any energy caring about it.
  - simion314 7y ago
    I don't think the decisions made in Debian were influenced a lot by the average joe user, my complaint is about the discussions, my complaint is that say if I find a thread that compares all the init systems I would prefer to read expert opinions on it, people that had success with systemd but also people that had trouble with systemd , but you get average joe pasting same shit all the time on both sides. But yeah you are right(this always happens on the internet), I was also guilty of this, I remember back when C# appeared and I was sure is the best thing ever and it will soon replace all the other languages. I think at my past enthusiasm for C# when I see Rust/Go/CoolLang evangelizing why X is better and in 3 years it will dominate.

pinopinopino 7y ago

My problem with systemd is that it is not just a init system. It goes further than that and it exposes apis that third parties use. It is tempting to use systemd functionality as developer, but then you are no longer portable to bsd, darwin or other systems. I think systemd is bad because it will break links between the various unixes. That being said, as system administrator, I found systemd mostly to be ok, but sometimes you run in non reproducable problems. I have sometimes that servers don't come up, because the network unit didn't get started. Restarting fixes it. I haven't been able to reproduce it and the logs are also not very helpful.

jbverschoor 7y ago
I don't know.. your application can and should be portable.. But if you want to support systemd, sysvinit, launchd, windows-services or whatever, that's up to you. It's this tiny part where you need to commit to some piece of technology. I don't see the difference between creating a systemd config file, which is super clear and managed properly and to create a bunch of init scripts that depend on pid-files which might be stale and where those directories are abitrary.
- kdmccormick 7y ago
  If I understand correctly, GP is saying that systemd also provides non-init-related functionality. If a package you develop relies on only systemd's init capabilities, it'd probably be pretty straightforward for someone to port it to an OS with a different init system (like BSD). If your package relies on other systemd capabilities, though, the task of porting gets much harder.
  - majewsky 7y ago
    > If your package relies on other systemd capabilities Such as? Which other "systemd capability" besides the init system part exposes an API to general user-space applications? The only one I can think of is logind, for which an alternative implementation (elogind) exists.

bonzini 7y ago

> depends on a systemd component It depends on a systemd API and there is an independent implementation, elogind. GNOME runs just fine in the BSDs, so its dependency on systemd is a strawman.

cturner 7y ago

For Init, desktop use-cases can be challenging. They can cover hot-swap networking, hot-swap hardware, sleep/restart. Scenario: a user is playing an audio stream that comes over the network. They put their computer to sleep. They restore it later, at another site. Consider the dependency calculation to restore that mixing pipeline, without sending clicking noises to the user.

jbverschoor 7y ago

I only use linux on servers, and have been doing that since I used redhat and slack in the '90s. After that I moved to FreeBSD and since about 15 years, I'm on Debian. sysvinit scripts are horrible to create and operate. It's easy to set tup dependencies for network or other services. I haven't used it to run cron-like tasks, or inetd-type servers, but I don't have a need for that.