9 ms·

Lennart came down from heaven (or, depending on your perspective, up from hell) and looked at the state of linux distributions. He said, "This sucks. Boot time

by throw7 4y ago

Lennart came down from heaven (or, depending on your perspective, up from hell) and looked at the state of linux distributions. He said, "This sucks. Boot times are slow. Distros have a mish-mash of init systems and shell scripts, all subtlety different. Linux features like cgroups, which are the bee's knees, are left as an exercise to the sysadmin. Why aren't user processes manageable? etc." Thus systemd decided it was going to standardize a new layer between the linux kernel and userspace using a declarative model for configuration for... like everything. This was a huge change in the linux world. A huge change was going to be controversial. Systemd is still controversial. Systemd won though.

throwaway0x7E6 4y ago
>He said, "This sucks. Boot times are slow https://www.google.com/search?q=a+start+job+is+running+for https://www.google.com/search?q=a+start+job+is+running+for
- nousermane 4y ago
  If only they paid equal attention to shutdown as well. It is relatively easy to inadvertently break a systemd install in such a way that reboot/shutdown would go through a number of grotesque "tasks" with very generous time-outs: - Unmounting filesystem /mnt/nfs (X seconds out of 1:30) - Waiting for D-Bus to terminate (Y seconds out of 4:00) ...and so forth. It's so bad, there is a special "C+A+D, 7 times in two seconds" key combination to deal with those. Which, I've seen fail as well.
  - creeble 4y ago
    +10 on this. The first thing I noticed years ago from running a systemd-based distro, is that shutdown (thus reboot) got stuck in "...waiting for xxx to terminate" for multiple minutes. This had never happened before, and there were never consequences from it not happening. So it was (and remains, in many hard-to-debug cases) strictly a drawback for systemd-based systems.
    - codedokode 4y ago
      It could be a bug in a third party service that didn't shut down properly or wasn't integrated with systemd properly. You should not put a blame on systemd without investagating first.
- orf 4y ago
  Sorry, what does that link have to do with anything?
  - throwaway0x7E6 4y ago
    with systemd, boot/shutdown time has a chance to be indefinite
vetinari 4y ago
> declarative model for configuration for... like everything. Here I find that many people look for the wrong thing. Their idea is 'do $stuff at boot'. However, systemd does 'do $stuff at $event', where 'boot' is one of the events in the set. They are not wrong though, we are used to cron is not a valid reason why it should not get unified.
- deathanatos 4y ago
  … but you can still just run your favorite crond, and keep doing exactly what you were before? I've still never run a cron job under systemd, and I've never hit trouble doing that. I.e., Systemd doesn't force you to use it for cron. Although, now that I'm looking at ArchWiki's "list of reasons you might want to do this" … it checks off basically every problem with traditional cron. I might need to start using this.

by throw7 4y ago

throwaway0x7E6 4y ago

>He said, "This sucks. Boot times are slow https://www.google.com/search?q=a+start+job+is+running+for https://www.google.com/search?q=a+start+job+is+running+for

nousermane 4y ago
If only they paid equal attention to shutdown as well. It is relatively easy to inadvertently break a systemd install in such a way that reboot/shutdown would go through a number of grotesque "tasks" with very generous time-outs: - Unmounting filesystem /mnt/nfs (X seconds out of 1:30) - Waiting for D-Bus to terminate (Y seconds out of 4:00) ...and so forth. It's so bad, there is a special "C+A+D, 7 times in two seconds" key combination to deal with those. Which, I've seen fail as well.
- creeble 4y ago
  +10 on this. The first thing I noticed years ago from running a systemd-based distro, is that shutdown (thus reboot) got stuck in "...waiting for xxx to terminate" for multiple minutes. This had never happened before, and there were never consequences from it not happening. So it was (and remains, in many hard-to-debug cases) strictly a drawback for systemd-based systems.
  - codedokode 4y ago
    It could be a bug in a third party service that didn't shut down properly or wasn't integrated with systemd properly. You should not put a blame on systemd without investagating first.
orf 4y ago
Sorry, what does that link have to do with anything?
- throwaway0x7E6 4y ago
  with systemd, boot/shutdown time has a chance to be indefinite

vetinari 4y ago

> declarative model for configuration for... like everything. Here I find that many people look for the wrong thing. Their idea is 'do $stuff at boot'. However, systemd does 'do $stuff at $event', where 'boot' is one of the events in the set. They are not wrong though, we are used to cron is not a valid reason why it should not get unified.

deathanatos 4y ago
… but you can still just run your favorite crond, and keep doing exactly what you were before? I've still never run a cron job under systemd, and I've never hit trouble doing that. I.e., Systemd doesn't force you to use it for cron. Although, now that I'm looking at ArchWiki's "list of reasons you might want to do this" … it checks off basically every problem with traditional cron. I might need to start using this.