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

Systemd: The Biggest Myths

0pointer.de

Post reply on HN
Print view View original

31–40 of 118 posts

Re: Systemd: The Biggest Myths

#31

Post by X-Istence »

mhurron wrote: post #2

> systemd being Linux-only is not nice to the BSDs. >Completely wrong. The BSD folks are pretty much uninterested in systemd. If systemd was portable, this would change nothing, they still wouldn't adopt it systemd is not portable, it wasn't made to be portable, it relies on far too many linuxisms. Therefore the BSD's don't care about it. It is not 'the BSD's don't care about it so we didn't make it portable.'

The BSD folks may not be interested in systemd itself, we are still interested in running various bits and pieces of software on top of the platform. When software starts requiring systemd just to run we have no chance what so ever at porting that software.

The same is true for a lot of Linuxisms. I have spent an awful lot of time getting software that states on the tin it is written for POSIX to run on BSD because its source code uses all kinds of Linuxisms.

The same holds true for people assuming that /bin/sh is bash, which may be true on certain Linux distributions but isn't so most other systems. I've started noticing the same issues with other things as well, such as the symlink from /bin to /usr/bin, /sbin to /usr/bin ... whereby software believes all software lives in /usr/bin when in reality that isn't the case for the BSD's.

Re: Systemd: The Biggest Myths

#32

Post by meaty »

thaumaturgy wrote: post #25

3. I don't understand the desire to trim seconds off of boot-up time (even assuming that systemd does this; it didn't for me). The goal should be to restart less often, not to restart more quickly. 5. The systemd documentation is indeed very good, and that's probably one of the biggest drivers behind its adoption. However, it is also difficult. A big part of the pushback from people over systemd is that it also repla…

Regarding your last point, the main thing that systemd excels at is managing the mishmash of power events, other ACPI events, service management and integration with DBus (which everything seems to require these days).

However, I run Linux in three locations and here's where systemd fits for me:

1. Servers. No use whatsoever. There are two power states: off and on. None of this is really an improvement over SVR4 init. It's just another damn tool to learn.

2. Desktops: No use whatsoever. I run mine like servers simply because if I need remote access, trusting stuff like WOL and ACPI is just silly on Linux.

3. Laptops: No use whatsoever. This is simply down to the fact that the power management on Linux i.e. hibernate/sleep support is a bag of shit. I run mine as power states off and on, much as 1 and 2.

Regarding boot speed - my laptop boots in about 14 seconds (SSD). Who cares about making it faster?

I find that a shell script is far more useful i.e. it doesn't enforce constraints on you which have to then be added as features to systemd. Plus shell scripts are generic tools i.e. learning how to write them will be of more use globally than learning systemd guts.

So basically, screw it.

The problem that this outlines is that Linux's power management, event and ACPI state management is crappy. We don't need another layer of crap over the top of it to make it work properly.

Re: Systemd: The Biggest Myths

#33

Post by X-Istence »

cnvogel wrote: post #29
4ad wrote: post #15

Earlier quoted context omitted.

You can write software ignoring how it will be started and you (or others) can write init scripts for various traditional systems. This is way harder if you use systemd; suddenly you need to care about the init system, and you might sacrifice init independence for pragmatic reasons (I want to support systemd, but I don't want to write this yet-another-abstract-wrapper-layer so that someone else might use it with othe…

You always had to care about the init-system: There are some differences between e.g. debian and redhat (start-stop-daemon only on debian, tools for creating the symlinks to install a service), then there's upstart with a different shell-script-esque syntax. To support systemd, the number of configs you provide will go from maybe 4 to 5, not from 1 to 2! And, looking at the examples provided by ArchLinux, the systemd…

No, generally you didn't have to care about the init-system unless you wanted to provide an init script. But it didn't matter how your daemon was/is started. With systemd that is no longer the case, you can use certain systemd only features thereby locking out people that want to use your service/daemon without systemd.

Re: Systemd: The Biggest Myths

#34

Post by X-Istence »

diegocg wrote: post #18
mhurron wrote: post #16

Earlier quoted context omitted.

> I'm not sure why systemd not being portable to other operating systems is suddenly a big deal. Because software being written that has systemd as a dependency will be Linux only software.

> Because software being written that has systemd as a dependency will be Linux only software. And this is news, and suddenly it's systemd's fault? If you hate Linux-only software, software that depends on systemd is the last of your problems. Software that depends on glibc and the Linux kernel are probable the main offenders.

Generally when software relies on glibc or the Linux kernel it can be patched so that it works on the BSD's. In my time of porting to OS X for example I haven't had anyone not take my patch to fix a problem an upstream it with a "thanks!". This becomes more problematic with systemd, whereby we can't port systemd, and since the software depends on systemd (most likely for some reason or another the software developer thought it was a good idea) we can't easily replace/rip out those parts of the code and make it run on the BSD's.

Re: Systemd: The Biggest Myths

#35

Post by X-Istence »

mseepgood wrote: post #22
bitwize wrote: post #19

Earlier quoted context omitted.

He's this decade's Ulrich Drepper.

Drepper is a very nice and intelligent guy. I liked his recent foss.in talks: "Why knowing your hardware is important" http://www.youtube.com/watch?v=QUUdVFZBd5g "Scalable Parallel Programming Techniques" http://www.youtube.com/watch?v=jfimI7UC9Pg

Drepper may be intelligent, but I don't think I would put him into my "nice guy" list.

Re: Systemd: The Biggest Myths

#36

Post by lucian1900 »

The intensity of people's hate for this guy is mind-boggling. Most of the stuff he made is really nice, proven by the fact that it's being used widely without issues.

Even without such an impressive track-record, people should at least give him the benefit of the doubt.

Even a cursory look into systemd design debunks most of the "criticism" people have against it.

Re: Systemd: The Biggest Myths

#37

Post by ben0x539 »

4ad wrote: post #11
cout wrote: post #3

I don't want systemd because I don't trust Lennart Poettering to be able to write reliable code.

Downvoting this post is unwarranted. Everything that Lennart Poettering has ever done was an unreliable clusterfuck[1] astray from the Unix philosphy. There's nothing that he has ever done that is considered "good" by a majority of Unix-derivative users. [1] http://www.youtube.com/watch?v=ZTdUmlGxVo0

> There's nothing that he has ever done that is considered "good" by a majority of Unix-derivative users.

Is there really anything at all that a majority of Unix-derivative users can agree on?

Re: Systemd: The Biggest Myths

#38

Post by jeltz »

meaty wrote: post #32
thaumaturgy wrote: post #25

3. I don't understand the desire to trim seconds off of boot-up time (even assuming that systemd does this; it didn't for me). The goal should be to restart less often, not to restart more quickly. 5. The systemd documentation is indeed very good, and that's probably one of the biggest drivers behind its adoption. However, it is also difficult. A big part of the pushback from people over systemd is that it also repla…

Regarding your last point, the main thing that systemd excels at is managing the mishmash of power events, other ACPI events, service management and integration with DBus (which everything seems to require these days). However, I run Linux in three locations and here's where systemd fits for me: 1. Servers. No use whatsoever. There are two power states: off and on. None of this is really an improvement over SVR4 init…

To me systemd looks mainly useful for servers. Some of the nice server features:

1. It is way easier to write a systemd unit for an in house application than it is to write a correct sysvinit script.

2. Everything runs in a cgroup making it easier to add resource limits and see which process is started by which service.

3. Easy to check which daemons are running and not.

4. Reduced startup time for containers.

Re: Systemd: The Biggest Myths

#39

Post by sophacles »

thaumaturgy wrote: post #25

3. I don't understand the desire to trim seconds off of boot-up time (even assuming that systemd does this; it didn't for me). The goal should be to restart less often, not to restart more quickly. 5. The systemd documentation is indeed very good, and that's probably one of the biggest drivers behind its adoption. However, it is also difficult. A big part of the pushback from people over systemd is that it also repla…

Regarding your response to 3: I agree that system stability is a very important goal. However, there are also plenty of use cases for faster boot times, so it shouldn't be disregarded as a valid pursuit in system engineering.

Re: Systemd: The Biggest Myths

#40

Post by jmj42 »

thaumaturgy wrote: post #25

3. I don't understand the desire to trim seconds off of boot-up time (even assuming that systemd does this; it didn't for me). The goal should be to restart less often, not to restart more quickly. 5. The systemd documentation is indeed very good, and that's probably one of the biggest drivers behind its adoption. However, it is also difficult. A big part of the pushback from people over systemd is that it also repla…

> The goal should be to restart less often, not to restart more quickly.

No! These are not mutually exclusive. The goal should be to restart less ofter, but restart faster when it is necessary. Systems have to restart. Well run/maintained/designed systems may not need to restart ofter, but they do need to restart.

Consider: Many moons ago I was responsible for (among other things) the company's CRM systems. These were a couple of mid-range Suns that were extremely reliable. On an anual basis, the business operations department issues downdown cost estimates for business critical systems (these were used to develop inter-departmental SLAs), and estimated that the CRM database server cost the company about $250K per hour of down time, or, almost $4200 per minute. Or read another way: a 10 seat license for our software in a saturated (niche) market.

The point is, outages happen (no you can not account for all possible failure scenarios), and startup times matter.

Post reply on HN