Myth 31: "I heard it was written by web developers."
Systemd: The Biggest Myths
41–50 of 118 posts
Re: Systemd: The Biggest Myths
#42Earlier quoted context omitted.
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.
I disagree.
1. Not really. Most sysadmins have a decent template init file sitting around or you just steal another one on the machine and modify it. They are also more flexible as some startup processes aren't quite as simple as systemd thinks (consider lockfiles, temp data purging, permissions etc).
2. ulimit / selinux - per process. cgroup whilst funky looking is YET ANOTHER disposable mechanism which will no doubt get canned in 5 years like ipchains ipfwadm etc.
3. service --status-all
4. Concurrent startup yes. That really doesn't make much difference on a server with large IO and CPU capacity.
Re: Systemd: The Biggest Myths
#43Myth 31: "I heard it was written by web developers."
No, that's Gnome-shell.
Re: Systemd: The Biggest Myths
#44Earlier quoted context omitted.
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.
> 3. Easy to check which daemons are running and not.
How? This is one of the things that have really annoyed me as all the systemd services have gone from service --status-all.
Re: Systemd: The Biggest Myths
#45Earlier quoted context omitted.
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.
Regarding (1), I'll echo everything meaty said, and add that basic shell scripting is a valuable and generally useful tool to have anyway, so I'm skeptical of the benefits of replacing them with another, slightly different configuration file format.
For example: we use backuppc for automated network and remote server backups. The backuppc data volume is a TrueCrypt-encrypted drive. Creating an init script that checked to make sure that the volume was present and mounted before launching the backup daemon was fairly straightforward. I understand that I could still do this in systemd, but the catch is that I would have to do it with a shell script -- the same way I am now, except for a different, alien interface -- because the native system doesn't have support for things like that. (This is assuming that some combination of unit config parameters couldn't do it; the commands for finding the drive and checking its status were a little fiddly, and I honestly haven't tried to do this the systemd way. Still though: once you understand shell scripting, you can do anything on Linux.)
Re: Systemd: The Biggest Myths
#463. 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 wer…
Sure, but given that developer time is a bounded resource, we can't really expect to get both fewer restarts and faster restarts. I sympathize with your example, but I would expect that you had already seriously optimized your startup process, and since systemd doesn't make services start more quickly (it only does a better job of parallelizing them), I doubt that it would have made a huge difference in your case. Assuming even a very generous 5-second startup difference, that would have only made a $350 difference per incident.
Re: Systemd: The Biggest Myths
#47> 13. Myth: 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.
> 15. Myth: systemd could be ported to other kernels if its maintainers just wanted to.
> That is simply not true. Porting systemd to other kernel is not feasible. We just use too many Linux-specific interfaces.
So what happens to software written for Linux that can be (and currently is) ported to BSD when it starts to require systemd?
Re: Systemd: The Biggest Myths
#48Earlier quoted context omitted.
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.
> 3. Easy to check which daemons are running and not. How? This is one of the things that have really annoyed me as all the systemd services have gone from service --status-all.
Have you tried either
systemctl | grep running
systemctl --type=service
systemctl --type=service | grep running
Re: Systemd: The Biggest Myths
#49The 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.
"Most of the stuff he made is really nice, proven by the fact that it's being used widely without issues."
Without issues? PulseAudio is loaded with issues. The only time PA works correctly is when you are doing things the way Lennart thinks you should do them -- which is basically the way desktop Windows and Mac OS X users are expected to do things. Another way to put things is this: Lennart's software designs dictate how users should use their computer, to the exclusion of all other use-cases. Doing something cool or unusual with PulseAudio is like pulling teeth.
Re: Systemd: The Biggest Myths
#50The 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.
"Most of the stuff he made is really nice, proven by the fact that it's being used widely without issues." Without issues? PulseAudio is loaded with issues. The only time PA works correctly is when you are doing things the way Lennart thinks you should do them -- which is basically the way desktop Windows and Mac OS X users are expected to do things. Another way to put things is this: Lennart's software designs dicta…
Pulse Audio is not perfect but what before was. People were bitching about PA and wanted OSS back. I seriously doubt that many of those actually do anything reasonable with audio.