Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why pro-systemd and anti-systemd people will never get along

uselessd.darknedgy.net

Post reply on HN
Print view View original

41–50 of 113 posts

Re: Why pro-systemd and anti-systemd people will never get along

#41

Post by bkor »

rthomas6 wrote: post #36
deelowe wrote: post #16

Earlier quoted context omitted.

Linux/unix has a bit of an issue with it's init aging systems. One simple example is that they are serial, meaning that services start one by one with little to no concurrency. This causes several issues. Also, the most popular variant, system V is difficult to maintain having multiple directories for various run levels and other cumbersome features. I won't go into details here, just know that the popular init syste…

Could someone just fork systemd and make a version that relaces the init system and nothing else?

That's uselessd. Software however relies on the other bits, e.g. logind dbus interfaces. For that there is a systemd-shim, but was not there initially and used to lag behind systemd for a 6+ months. Apparently it was also quite buggy. Seems ok now though.

Re: Why pro-systemd and anti-systemd people will never get along

#42

Post by bkor »

pessimizer wrote: post #9

I have none of these objections to systemd. My objection is that it's both pervasive and unauditable. I can accept one or the other. I don't have to rely on 'many eyes' to tell me what's going on with init scripts, I can just look. systemd is sprawling, has no particular philosophy that I can notice, and all of its internal systems are heavily interconnected; this leads me to expect that very few people will be audit…

Red Hat has audited the code in the past. The boot time bit is an item from the linked article. The thing is that systemd provides more than just an init system. Stuff that's pretty useful.

Re: Why pro-systemd and anti-systemd people will never get along

#43

Post by exelius »

hello_there wrote: post #37

What I really dislike about these debates about systemd is that usually nobody mentions the alternatives. From reading the debate I get the impression that both sysvinit and systemd have major problems, but I'm never presented with a solution. So if I'm going to be against sysvinit as well as systemd, then what should i be supporting?

The main alternatives seem to be OpenRC and Upstart. One of the biggest criticisms of systemd by its detractors is that it's unproven and not stable; and neither of these address that concern.

Upstart was developed by Ubuntu, which has stopped supporting it and is adopting systemd because they recognized the need to standardize on a single system. After the Debian committee voted to go with systemd, Ubuntu (being a Debian derivative) followed suit.[1]

OpenRC isn't really a replacement for sysvinit; rather it bolts on some functionality on top of sysvinit. My understanding is that OpenRC is not an incredibly mature codebase and would have needed a lot of work to come up to feature/stability parity with systemd. Because it doesn't fully replace sysvinit, it also doesn't solve all of the same problems as systemd.

[1] http://www.markshuttleworth.com/archives/1316

Re: Why pro-systemd and anti-systemd people will never get along

#44

Post by bkor »

ck2 wrote: post #17
hk__2 wrote: post #2

Could someone ELI5 this pro-systemd/anti-systemd thing?

One person decided the way microsoft windows handles services was awesome and it would be a good idea to make the linux service manager work like that with complex binaries and binary logs instead of editable, standardized bash scripts and text logs. No vote, only veto. Very anti-linux.

According to the blogs it is based upon what Mac OS does as well as Solaris. So it is very UNIX in mind.

Re: Why pro-systemd and anti-systemd people will never get along

#45

Post by pessimizer »

bkor wrote: post #42
pessimizer wrote: post #9

I have none of these objections to systemd. My objection is that it's both pervasive and unauditable. I can accept one or the other. I don't have to rely on 'many eyes' to tell me what's going on with init scripts, I can just look. systemd is sprawling, has no particular philosophy that I can notice, and all of its internal systems are heavily interconnected; this leads me to expect that very few people will be audit…

Red Hat has audited the code in the past. The boot time bit is an item from the linked article. The thing is that systemd provides more than just an init system. Stuff that's pretty useful.

>very few people will be auditing the code that don't work for redhat,

Re: Why pro-systemd and anti-systemd people will never get along

#46

Post by exelius »

uselessdguy wrote: post #35
exelius wrote: post #31

Earlier quoted context omitted.

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 th…

Because they all largely did the same things that sysv did with a few bolt-on features. That is a total misrepresentation, I'm sorry. The fact is SysV was probably one of the weakest init systems around, besides deliberately minimal ones like busybox-init and sinit. I devoted the "sysvinit: the eternal red herring" section precisely to debunk that. I just want people to stop comparing everything to SysV, because it o…

I agree with you; my entire point that they were sysv with bolt-on features was to say that many of the alternate init systems really weren't very advanced and spent too much effort trying to replicate sysv for compatibility reasons when the entire thing should have been scrapped.

Anyway, I think the pro-systemd folks often think that anti-systemd folks would react the same way to any init system that isn't sysv. This is probably fair, because there haven't been many credible non-systemd alternatives to sysv.

Re: Why pro-systemd and anti-systemd people will never get along

#47

Post by hyperpape »

uselessdguy wrote: post #15
fidotron wrote: post #11

It will be very interesting to see how this all plays out in the long run, though the short term is utterly depressing. My hunch is Lennart will be vindicated, on the basis that systemd as it exists right now is not right, but it can be evolved into something much better, and while that may not have occurred to other projects here the stakes are enormous. There is a definite strand to the resistance that any change t…

Shell scripting isn't "archaic nonsense" at all, it's just that the warts from how most shells implement their command language (ksh/bash/POSIX sh) are holding us back. If you go look at Plan 9 rc shell scripts, you'll see how much cleaner they are. In addition, the s6 people have done some interesting things with execline (which looks kind of like Tcl), which works as a chain loader instead of holding the shell resi…

By Plan9 rc scripts, do you mean specific scripts that the OS used, or do you just mean rc as opposed to sh/bsh/ksh?

Re: Why pro-systemd and anti-systemd people will never get along

#48

Post by bkor »

uselessdguy wrote: post #35
exelius wrote: post #31

Earlier quoted context omitted.

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 th…

Because they all largely did the same things that sysv did with a few bolt-on features. That is a total misrepresentation, I'm sorry. The fact is SysV was probably one of the weakest init systems around, besides deliberately minimal ones like busybox-init and sinit. I devoted the "sysvinit: the eternal red herring" section precisely to debunk that. I just want people to stop comparing everything to SysV, because it o…

The GR is specifically about keeping support for sysvinit around. So comparisons to that are entirely logical IMO. Note that I find the GR to be very vague. There's a post on Planet Debian to explain how to interpret it (jeez!).

Re: Why pro-systemd and anti-systemd people will never get along

#49

Post by nanoscopic »

That was a very long and detailed explanation of the sides of the argument.

It misses one huge thing: Consistency.

The elephant in the room is that most people who dislike systemd simply dislike it because they learned and used init.d scripts, runlevels, and chkconfig, and that is the extent of their understanding.

The main hatred for systemd is coming from people simply being resistant to change. If it ain't broke, don't fix it.

I like systemd for it's technical merits. I personally would prefer to use a distribution like CentOS in a mode where there is no systemd, simply because I like simplicity and systemd is more confusing to me.

What I foresee happening: people who don't like systemd are going to go try other distributions that don't use it, and may abandon the ones that do because it is too much trouble to run them without it.

The statement that it will lead to divide between graphical linux users and minimalists is likely very true. Runlevels may be simplistic and outdated, but they are easy to remember.

Re: Why pro-systemd and anti-systemd people will never get along

#50

Post by bkor »

pessimizer wrote: post #45
bkor wrote: post #42

Earlier quoted context omitted.

Red Hat has audited the code in the past. The boot time bit is an item from the linked article. The thing is that systemd provides more than just an init system. Stuff that's pretty useful.

>very few people will be auditing the code that don't work for redhat,

You also said: > My objection is that it's both pervasive and unauditable.

You said it was unauditable, it has already been audited. Adding arbitrary limitations to this doesn't change that.

Post reply on HN