Hacker News new | past | comments | ask | show | jobs | submit login

Can we stop talking about the init scripts? systemd does that well, we all got it. I personally was not overwhelmed when having to use it but it's step forward from sysv init scripts - no one sane doubts that.

All the recent talk about systemd is about the other components that replace certain basic userland compoments.

logind for sessions changed the default to kill background tasks on logout, now it's about the implementation of the dns resolver that comes with systemd. There are other implementations that replace cron, ntpd, syslog...etc.pp. All of this has a dependency on glibc and uses dbus.

This has nothing to do with init scripts. This is an attempt to improve on the status quo of userland tools close to the OS. systemd appears to provide some minimal userland that comes with a Linux kernel and aims to be a userland API. I personally think this is a bad idea but I kind of see the point why you might want to do this.

The IMHO absolutely warranted criticism for some of these replacements is that they are not better designed, that they create new dependencies and complicate things without reason and there is a tendency to create some systemd specific API that userland has to implement - breaking compatibility with other POSIX systems - something that was hard to do even before systemd.

So it's not about init scripts - it's about revamping essential userland tools in a way that's badly designed according to some.

Personally I hold no grudge against this but I'm not keen on using this or having to deal with this as a sysadmin. It's a undocumented black box once you have run into problems and you are busy reading C code or capturing dbus calls. I have usually better things to do.

And for the initscripts - you could have done this with runit/s6 and mkdir with cgroups in 2008 if you wanted. You could have used setsid before that. This was deprecated and now systemd (or something else that implements the kernel API) is the whole mananger of cgroups.

I personally think the systemd way is not the right direction to take as it's horrible inflexible and will bite Linux but I can understand why you might disagree here strongly.




It's interesting that at least twice in these comments someone has claimed that this was a desktop technology that was going to ruin servers, and when server using professionals reply that it's really good for servers they get what read to be quite angry responses.

I don't know much about it, but even from my position of ignorance it's clear that the level of debate is very low.


I wonder how many of those servers are web hosts.

There seems to be a line drawn where those that do web hosting and similar love systemd, while other server admins loath it for introducing needless complexities.

I have taken to thinking about web hosting as "uptime by machine gun". This in that they achieve uptime not by maintaining solid server configs, but by rapidly firing containers and/or VMs at the problem until it goes away.

http://www.commitstrip.com/en/2015/07/08/true-story-fixing-a...


Seems to be true since the famous "400 restarts a day is OK"

http://harmful.cat-v.org/software/ruby/rails/is-a-ghetto


dear deity...


Was my response angry? Was not my intention - I just wanted to point out where the grudge is coming from.

I guess the debate is so toxic because it's a perfect bikeshedding topic everyone that uses Linux can somehow participate in. Some sysadmins are surely frustrated because it breaks the way they worked in the past years, others are happy about the new features.

I'm undecided but if I read this https://news.ycombinator.com/item?id=11675129 I'm really feeling uncormfortable. Hitting this and debugging it seems like a nightmare. So I guess it's a win and eases a lot of pain points for ordinary users but make the live of specialists a lot harder. I can imagine how you hitting these bugs regularly turns you into posting something in the angry territory.

On the other hand the debate is now mostly technical (except some trolls).




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: