[dgdsgdsg]

for me it seems that most people complaining/crying out loud come from a system admin perspective.

For example the author of this blog article does not seem to have contribute a lot of code to any project and is more "just" an admin and not a dev.

for me it looks like they don't like new stuff love the linux world how they knew it and don't want things to get easier or even change.

[linuxydave]

>for me it seems that most people complaining/crying out loud come from a system admin perspective.

Sysadmins complaining about it is pretty important, as at the end of the day they are the ones who are maintaining the systems.

Personally, I have a strong dislike for Systemd. I don't believe it's the right replacement for sysvinit however it's not going away so we'll have to try and work around its warts. Also, currently it's buggy as hell so I will use Centos 6/Ubuntu 14.04 for a few more years to see if the many problems are sorted by then.

[general_failure]

That's exactly as intended. People who want to help out systemd will use latestbsoftware, report bugs and fix it because you know thats how free software works.

People who don't want to help out use the most recent stable and have nothing to worry about.

[linuxydave]

TBH with the current direction systemd is going in I'll probably end up using one of the BSDs. However, I doubt I'd be able to use a *BSD in a production environment as I am a contractor and all of my clients only want Linux.

[edwintorok]

I don't think they would complain if things became easier. All I hear about is problems with systemd, and having to solve problems (and learn how systemd and all its components interact so you can debug it) is not easier.

[general_failure]

Yeahz they all spend like 20 mins and come out crying without spending at least a week understanding it.

Which software stack do you know that you instantly get in 20 mins. I for one cannot understand the sysvinit or upstart in 20 mins (ie) to develop and debug. How do you debug sysvinit anyway? Echo's I place in the code do not appear on the screen. Can i claim 'Oh shit this is so broken...'?

[edwintorok]

You can start the daemon manually to check why it fails, or check logs, or put echo in the code like you say, or run the script with -x, there are many possibilities. sysvinit is quite easy to get, because you just apply what you already know (running shell scripts, running shell scripts with -x, read (log) files, etc.) and there isn't a layer in front of you that you don't know how to debug or trace.

And yes LSB init scripts are broken under systemd, exactly because of what you describe (placing echo doesn't show) because it redirects the execution through systemd, and stores the output in journald. Try writing (or debugging) an init script on a non-systemd system and see how much easier it is.

systemd also tries to act "smart" and remember the last state a service was in which makes developing LSB init scripts on a systemd system ... complicated. If an init scripts exits with success (perhaps because the deamon wasn't configured yet) then systemd will remember that and the next time you issue a 'start' it'll be a noop, and claim it was successful. Which leads to countless hours wasted until you figure out what really happened: systemd never even run your script again. So then you run 'restart' on the init script and all is well again.

[icantthinkofone]

Complaining and crying from a system admin perspective is pretty significant.

[hawleyal]

Agree. However, admins and devs often have competing interests. Admins want stability and ease of maintenance. Devs want features, agility, and speed of development. Admins often disregard or downplay technical debt in light of "has been working in production for X years". Devs often don't care enough about backwards compatibility.