3 ms·

But I think you could find a vocal minority (or several) to oppose ANY particular implementation. One of the reason the anti-systemd crowd has such a hard time

by cwyers 11y ago

But I think you could find a vocal minority (or several) to oppose ANY particular implementation. One of the reason the anti-systemd crowd has such a hard time gaining traction is because the only thing that unites all of them is opposition to systemd. They don't agree on what should be in its place instead -- some want to hold onto sysvinit, some want Upstart (although that's a dead end now), some want OpenRC, some want dmd, some want runit, some want something else or something that doesn't even exist yet.

weland 11y ago
It's very easy to agree that nuclear pulse propulsion is a bad idea for a vehicle, even among people who otherwise have very different preferences on what kind of engine they like on their vehicle. Unfortunately, yeah, the whole debate there is unproductive. Instead of focusing on real problems, it gets stuck into an endless debate on Unix philosophy, carried among a bunch of people who aren't really sure why it's a problem if something doesn't follow it and another bunch of people who insist that they're following because saying otherwise would be bad PR.
- yellowapple 11y ago
  > It's very easy to agree that nuclear pulse propulsion is a bad idea for a vehicle Speak for yourself. Who cares if my rocket is blanketing Earth in nuclear fallout if I get to ride it to Jupiter? :)
digi_owl 11y ago
Here is the thing. The problem is not systemd as init, it is systemd as, well, systemd. The constant addition of daemons and functionality to the overall systemd codebase by either subsuming or replacing existing, INDEPENDENT, projects. As such, who cares what init is used. The thing is that until systemd the other daemons/services started by init didn't particularly care what init it was. Previously you could piecemeal your changes. Didn't like syslog? Grab something else that talk the lingo and slot it into place. Sorry, but journald demands that the init is systemd. Want something to handle seats/sessions? Sorry, but logind only works with systemd as init. Etc etc etc! Going on and on and on about inits is a smokescreen.

by cwyers 11y ago

weland 11y ago

It's very easy to agree that nuclear pulse propulsion is a bad idea for a vehicle, even among people who otherwise have very different preferences on what kind of engine they like on their vehicle. Unfortunately, yeah, the whole debate there is unproductive. Instead of focusing on real problems, it gets stuck into an endless debate on Unix philosophy, carried among a bunch of people who aren't really sure why it's a problem if something doesn't follow it and another bunch of people who insist that they're following because saying otherwise would be bad PR.

yellowapple 11y ago
> It's very easy to agree that nuclear pulse propulsion is a bad idea for a vehicle Speak for yourself. Who cares if my rocket is blanketing Earth in nuclear fallout if I get to ride it to Jupiter? :)

digi_owl 11y ago

Here is the thing. The problem is not systemd as init, it is systemd as, well, systemd. The constant addition of daemons and functionality to the overall systemd codebase by either subsuming or replacing existing, INDEPENDENT, projects. As such, who cares what init is used. The thing is that until systemd the other daemons/services started by init didn't particularly care what init it was. Previously you could piecemeal your changes. Didn't like syslog? Grab something else that talk the lingo and slot it into place. Sorry, but journald demands that the init is systemd. Want something to handle seats/sessions? Sorry, but logind only works with systemd as init. Etc etc etc! Going on and on and on about inits is a smokescreen.