9 ms·

I see the whole pro/anti systemd as a philosophical debate. Basically each part is arguing where the complexity should be in the system and how dense it should

by erhardm 12y ago

I see the whole pro/anti systemd as a philosophical debate. Basically each part is arguing where the complexity should be in the system and how dense it should be distributed. I think we need two competing init systems to really know maybe in 5-10 years what the best trade-offs are. A modern sys V init and systemd.

fbt2lurker 12y ago
Why two? As many as people would write. There is already a bunch of em.
- erhardm 12y ago
  At least one of each side of the debate. Preferable there should be two, one on each side which implements the good/novel ideas and others where aggressive experimentation takes part.
  - kbenson 12y ago
    I think you have a much more stylized view of what a side of a debate is than reality suggests is the case. Creating an implementation for a side that wasn't already rallying around one would just exacerbate the differences in opinion on that side and fragment it into multiple smaller sides.
  - fbt2lurker 12y ago
    There aren't actually two sides of this. There are only in the scope of systemd vs everyone else (just because systemd is something that is pushed as THE solution). There are multiple solutions that all have their supporters. And we generally actually get along and work together pretty well. BEcause we don't think that one solution is necessarily better than the other in all aspects. It shouldn't be “provide a reasonable alternative to systemd and then we will compare”. “We” won't “compare” anything. Competition is awesome, “we” shouldn't “choose” just one implementation of anything just because the majority of distros uses it. It should be “let people do their thing and please don't hard-depend on this one init system or anything else without a really good reason to do so”.
  - fbt2lurker 12y ago
    Just to be clear: I know that among the bigger projects it's just GNOME3 that is planning to hard-depend on systemd and even they want a shim, externnal or internal, to accomodate systemd-less systems (not necessarily BSDs, maybe other linux distros too). Currently systemd is very much optional (opt-out, not opt-in, learn the difference) and I personally mantain an Arch flavour that uses sinit, smdev and a bunch of other small projects while still relying on Arch's package base. It's the attitude of the upstream that seems like a threat: “we want everyone to use systemd”. And if they succeed, developers of userspace software will be very much justified in hard-depending on it. Who cares if everyone uses it, right?
    - erhardm 12y ago
      TBH, I currently feel the same way because of the opt-out, not opt-in situation. On one machine running Debian Sid I just found myself running systemd after an dist-upgrade..blowing my mind considering that I didn't choose Arch in the first place for the rolling release machine because of the systemd. But GNOME3 is to blame making systemd a hard dependency(Even if they mostly seem to be from the same camp, RH).
      - bkor 12y ago
        systemd provides things and does things that are useful. That is why GNOME depends on those. Blaming us? Try actually understanding why. It's not a hard dependency btw, you still have ConsoleKit support. A project not maintained for almost 3 years or so. Then there is that systemd-shim. Initially very very buggy, but now ok-ish. OpenBSD is working on some shim thing as well.
        erhardm 12y ago
        Others working on systemd shims out of necessity is a sign, IMHO, that systemd is in reality a hard dependency in the near future (and developers trying to free from that dependency). I don't say systemd is not useful, GNOME using it shows also to good sides of it, but others feeling a little forced to choose systemd or The Unix Way I think is the wrong way to do it. Why can't we have both(modern init system and unix philosophy)? Not possible? Not enough interest/resources?
exelius 12y ago
I think the point is that you can't have two competing init systems: the market will eventually need to standardize on one of them or risk forking the entire Linux ecosystem. What you call "modern sysv" would look a lot like systemd depending on your definition of modern. I think that definition of what modern should look like is what's being debated here. The big features sysvinit are missing require user space applications to be able to interact with [generic launch system]. Those applications must use some sort of standard taxonomy and flow control. As applications are ported to [generic launch system], they cease working on sysvinit systems because sysv either doesn't support those features or supports them in a different manner. Sysvinit doesn't really do all that much, to be honest. So it's really easy for [generic init system] to emulate most of its functionality. [generic init system] does a lot more, so it's harder to copy. Even more, if you were to "clone" [generic init system], applications make big assumptions as to how [generic init system] functions, so your [generic init system] replacement would need to function nearly identically to [generic init system]. Basically, someone made a call and said "this is how a modern init system should function". There is a vocal group of people who disagree with that definition. But no matter what the definition is, people would disagree because different people have different ideas about what Linux is/should be. You would see the same problem if a sysvinit derivative was the leading candidate instead of systemd.
- vidarh 12y ago
  We've had multiple competing init systems for years without forking the entire Linux ecosystem any worse than before.
  - exelius 12y ago
    Because they all largely did the same things that sysv did with a few bolt-on features. After many years, it's become apparent that approach won't work when you need multiple processes to be able to coordinate and schedule threads, power management, etc. Things need to be done at the hardware level, and sometimes those need to be triggered from user applications. But you can't have random applications tinkering in the kernel, so systemd arose and took over a number of those functions. So I guess I can amend that to say "you can't have multiple init systems that do the things that systemd does".

by erhardm 12y ago

fbt2lurker 12y ago

Why two? As many as people would write. There is already a bunch of em.

erhardm 12y ago
At least one of each side of the debate. Preferable there should be two, one on each side which implements the good/novel ideas and others where aggressive experimentation takes part.
- kbenson 12y ago
  I think you have a much more stylized view of what a side of a debate is than reality suggests is the case. Creating an implementation for a side that wasn't already rallying around one would just exacerbate the differences in opinion on that side and fragment it into multiple smaller sides.
- fbt2lurker 12y ago
  There aren't actually two sides of this. There are only in the scope of systemd vs everyone else (just because systemd is something that is pushed as THE solution). There are multiple solutions that all have their supporters. And we generally actually get along and work together pretty well. BEcause we don't think that one solution is necessarily better than the other in all aspects. It shouldn't be “provide a reasonable alternative to systemd and then we will compare”. “We” won't “compare” anything. Competition is awesome, “we” shouldn't “choose” just one implementation of anything just because the majority of distros uses it. It should be “let people do their thing and please don't hard-depend on this one init system or anything else without a really good reason to do so”.
- fbt2lurker 12y ago
  Just to be clear: I know that among the bigger projects it's just GNOME3 that is planning to hard-depend on systemd and even they want a shim, externnal or internal, to accomodate systemd-less systems (not necessarily BSDs, maybe other linux distros too). Currently systemd is very much optional (opt-out, not opt-in, learn the difference) and I personally mantain an Arch flavour that uses sinit, smdev and a bunch of other small projects while still relying on Arch's package base. It's the attitude of the upstream that seems like a threat: “we want everyone to use systemd”. And if they succeed, developers of userspace software will be very much justified in hard-depending on it. Who cares if everyone uses it, right?
  - erhardm 12y ago
    TBH, I currently feel the same way because of the opt-out, not opt-in situation. On one machine running Debian Sid I just found myself running systemd after an dist-upgrade..blowing my mind considering that I didn't choose Arch in the first place for the rolling release machine because of the systemd. But GNOME3 is to blame making systemd a hard dependency(Even if they mostly seem to be from the same camp, RH).
    - bkor 12y ago
      systemd provides things and does things that are useful. That is why GNOME depends on those. Blaming us? Try actually understanding why. It's not a hard dependency btw, you still have ConsoleKit support. A project not maintained for almost 3 years or so. Then there is that systemd-shim. Initially very very buggy, but now ok-ish. OpenBSD is working on some shim thing as well.
      - erhardm 12y ago
        Others working on systemd shims out of necessity is a sign, IMHO, that systemd is in reality a hard dependency in the near future (and developers trying to free from that dependency). I don't say systemd is not useful, GNOME using it shows also to good sides of it, but others feeling a little forced to choose systemd or The Unix Way I think is the wrong way to do it. Why can't we have both(modern init system and unix philosophy)? Not possible? Not enough interest/resources?

exelius 12y ago

I think the point is that you can't have two competing init systems: the market will eventually need to standardize on one of them or risk forking the entire Linux ecosystem. What you call "modern sysv" would look a lot like systemd depending on your definition of modern. I think that definition of what modern should look like is what's being debated here. The big features sysvinit are missing require user space applications to be able to interact with [generic launch system]. Those applications must use some sort of standard taxonomy and flow control. As applications are ported to [generic launch system], they cease working on sysvinit systems because sysv either doesn't support those features or supports them in a different manner. Sysvinit doesn't really do all that much, to be honest. So it's really easy for [generic init system] to emulate most of its functionality. [generic init system] does a lot more, so it's harder to copy. Even more, if you were to "clone" [generic init system], applications make big assumptions as to how [generic init system] functions, so your [generic init system] replacement would need to function nearly identically to [generic init system]. Basically, someone made a call and said "this is how a modern init system should function". There is a vocal group of people who disagree with that definition. But no matter what the definition is, people would disagree because different people have different ideas about what Linux is/should be. You would see the same problem if a sysvinit derivative was the leading candidate instead of systemd.

vidarh 12y ago
We've had multiple competing init systems for years without forking the entire Linux ecosystem any worse than before.
- exelius 12y ago
  Because they all largely did the same things that sysv did with a few bolt-on features. After many years, it's become apparent that approach won't work when you need multiple processes to be able to coordinate and schedule threads, power management, etc. Things need to be done at the hardware level, and sometimes those need to be triggered from user applications. But you can't have random applications tinkering in the kernel, so systemd arose and took over a number of those functions. So I guess I can amend that to say "you can't have multiple init systems that do the things that systemd does".