3 ms·

I agree with most of this, especially the fact that complexity has simply been shifted to other places. It's much easier for me to read a systemd unit file tha

I agree with most of this, especially the fact that complexity has simply been shifted to other places. It's much easier for me to read a systemd unit file than it was for me to read a complex set of init scripts. The problem is that when I have 10 or 20 units with interlocking dependencies, it's an absolute nightmare to try and untangle because I have to jump between so many different files. Having to specify After=X and Requires=X seems like a prime example of optimizing for the 1% usecase. 99% of the time, when A must start after B, it's because A requires B. Having to specify both is something that is easily and often missed, and a hard problem to track down if you didn't read the documentation carefully. There's also the problem that it seems to be metastasizing and taking other parts of the OS. The longstanding /var/log/messages is now replaced by journalctl tool, and the logs are actually in binary. The venerable "hostname" command is now "hostnamectl" because it must go through systemd. They have also replaced chroot with systemd-nspawn, and made it so you cannot even use systemd while in a normal chroot!

vacri 11y ago
$0.02: journalctl isn't even tab-completable until you've nearly finished typing it. :)
- ibotty 11y ago
  depends on what you have in your path.
  - yellowapple 11y ago
    I feel like systemd's tools and Emacs are on a race to achieve the title of "only program(s) necessary in one's path to have a fully-featured operating system". :)
erikb 11y ago
Have you tried the systemd tooling that graphs depencies for you? I haven't worked on that area yet, but my colleagues made heavy use of that and actually could resolve problems with these quite fast thanks to the diagrams that systemd can create for you.
EmanueleAina 11y ago
> The problem is that when I have 10 or 20 units with interlocking dependencies, it's an absolute nightmare to try and untangle because I have to jump between so many different files How that's different from sysvinit? > The longstanding /var/log/messages is now replaced by journalctl tool, and the logs are actually in binary. `journalctl` prints plain text on its stdout, so you can think of it as a glorified `cat` if you don't want to use its extra features. On the contrary, if one needs its extra features on plain text log files one usually resolves to using fragile parsing hacks. > The venerable "hostname" command is now "hostnamectl" because it must go through systemd They do different things, `hostname` only reads the current hostname. `hostnamectl` is able to set the hostname, standardizing what used to be a per-distribution custom mechanism. Despite being shipped with systemd (to make sure everyone can rely on it) it doesn't actually depend on systemd and in no way goes through it. > They have also replaced chroot with systemd-nspawn, and made it so you cannot even use systemd while in a normal chroot. `chroot`'s purpose has never been the ability to run an init system inside it, no matter if it is sysvinit or systemd. On the other hand `systemd-nspawn` creates isolated containers, I'd be surprised you can't run sysvinit inside it. Again, you're comparing apples to whole orange trees as the systemd utilities do much more than the traditional ones you mentioned.
- keypusher 11y ago
  > How that's different from sysvinit? In sysv I can just make a list of startup tasks. A -> B -> C -> D. Easy. 10 things that must start in specific order? No problem, 10 things in list. There is no easy way to do this in systemd. I must create 10 different unit files, and then create a bunch of different dependencies (A depends on B and C, B depends only on D, can C then start at same time as D?, etc). When those dependencies change, I have to go look through a whole bunch of files or look at a graph tool to figure out what is even going on. > They do different things, `hostname` only reads the current hostname. That's... not true. From the first line of the hostname manpage: "Hostname is used to display the system's DNS name, and to display or set its hostname or NIS domain name." > chroot`'s purpose has never been the ability to run an init system inside it That's fine, but it worked under sysv and now it doesn't. When upgrading or working with different install roots, using chroot is common. Now I can't modify services during that time, unless I migrate everything over to use nspawn. > the systemd utilities do much more than the traditional ones you mentioned If I lived in a blue sky world, where I was fresh installing one new server with a simple set of services that I had built in systemd, I think I be quite happy with it. The problem is that I have thousands of servers, and a decade or more of accumulated infrastructure that relies on those traditional tools. Then systemd comes barging in and breaks a bunch of stuff, and that is frustrating. I'm not saying I hate systemd, in fact I agree that many of the new tools are quite nice. But it's kind of like the loud hipster that shows up at your party and starts talking shit about the music you are playing, and making fun of your choice in beer. Maybe my music does suck, and maybe these clothes aren't cool anymore, but we were sitting around having a fine time until he came around.

vacri 11y ago

$0.02: journalctl isn't even tab-completable until you've nearly finished typing it. :)

ibotty 11y ago
depends on what you have in your path.
- yellowapple 11y ago
  I feel like systemd's tools and Emacs are on a race to achieve the title of "only program(s) necessary in one's path to have a fully-featured operating system". :)

erikb 11y ago

Have you tried the systemd tooling that graphs depencies for you? I haven't worked on that area yet, but my colleagues made heavy use of that and actually could resolve problems with these quite fast thanks to the diagrams that systemd can create for you.

EmanueleAina 11y ago

> The problem is that when I have 10 or 20 units with interlocking dependencies, it's an absolute nightmare to try and untangle because I have to jump between so many different files How that's different from sysvinit? > The longstanding /var/log/messages is now replaced by journalctl tool, and the logs are actually in binary. `journalctl` prints plain text on its stdout, so you can think of it as a glorified `cat` if you don't want to use its extra features. On the contrary, if one needs its extra features on plain text log files one usually resolves to using fragile parsing hacks. > The venerable "hostname" command is now "hostnamectl" because it must go through systemd They do different things, `hostname` only reads the current hostname. `hostnamectl` is able to set the hostname, standardizing what used to be a per-distribution custom mechanism. Despite being shipped with systemd (to make sure everyone can rely on it) it doesn't actually depend on systemd and in no way goes through it. > They have also replaced chroot with systemd-nspawn, and made it so you cannot even use systemd while in a normal chroot. `chroot`'s purpose has never been the ability to run an init system inside it, no matter if it is sysvinit or systemd. On the other hand `systemd-nspawn` creates isolated containers, I'd be surprised you can't run sysvinit inside it. Again, you're comparing apples to whole orange trees as the systemd utilities do much more than the traditional ones you mentioned.

keypusher 11y ago
> How that's different from sysvinit? In sysv I can just make a list of startup tasks. A -> B -> C -> D. Easy. 10 things that must start in specific order? No problem, 10 things in list. There is no easy way to do this in systemd. I must create 10 different unit files, and then create a bunch of different dependencies (A depends on B and C, B depends only on D, can C then start at same time as D?, etc). When those dependencies change, I have to go look through a whole bunch of files or look at a graph tool to figure out what is even going on. > They do different things, `hostname` only reads the current hostname. That's... not true. From the first line of the hostname manpage: "Hostname is used to display the system's DNS name, and to display or set its hostname or NIS domain name." > chroot`'s purpose has never been the ability to run an init system inside it That's fine, but it worked under sysv and now it doesn't. When upgrading or working with different install roots, using chroot is common. Now I can't modify services during that time, unless I migrate everything over to use nspawn. > the systemd utilities do much more than the traditional ones you mentioned If I lived in a blue sky world, where I was fresh installing one new server with a simple set of services that I had built in systemd, I think I be quite happy with it. The problem is that I have thousands of servers, and a decade or more of accumulated infrastructure that relies on those traditional tools. Then systemd comes barging in and breaks a bunch of stuff, and that is frustrating. I'm not saying I hate systemd, in fact I agree that many of the new tools are quite nice. But it's kind of like the loud hipster that shows up at your party and starts talking shit about the music you are playing, and making fun of your choice in beer. Maybe my music does suck, and maybe these clothes aren't cool anymore, but we were sitting around having a fine time until he came around.