6 ms·

Systemd has admittedly grown on me, in the sense that the pros have begun to outweigh the cons, when divided by the amount of time since I began using it, multi

by aliqot 4y ago

Systemd has admittedly grown on me, in the sense that the pros have begun to outweigh the cons, when divided by the amount of time since I began using it, multiplied by the amount of time I'll likely still be using it. Homed might take another decade or so. Gives me the goosebumps on my arms just speaking about it.

andrewstuart 4y ago
>> Systemd has admittedly grown on me Not suggesting you are (were) a systemd hater, but all the systemd haters might find that systemd is actually damn awesome if they stopped their hating and learned about it. Here's an instant tasty systemd tip that I used yesterday ..... I had to prevent a forward proxy server from accessing local networks. How do you solve this without systemd? Well you have to start fiddling with iptables and descend into that level of hell wherein you are fundamentally fiddling with stuff you do not want to fiddle with, and beside that solution is going to be system wide. Or, you pull out systemd and get the job done by application IP address restrictions on a per application / service level: [Unit] Description=glider service After=multi-user.target [Install] WantedBy=multi-user.target [Service] IPAddressDeny=localhost IPAddressDeny=169.254.0.0/16 IPAddressDeny=192.168.0.0/16 IPAddressDeny=198.18.0.0/15 IPAddressDeny=172.16.0.0/12 IPAddressDeny=100.64.0.0/10 IPAddressDeny=10.0.0.0/8 ExecStart=<proxy command line goes here> systemd is chock full of super awesome stuff like this if you read the docs you'll find simple solutions to challenging problems everywhere. systemd is a beautiful, integrated work of art, and there's constant payoffs and benefits from the fact that it encompasses so much functionality previously split across a huge range of inconsistent small solutions to the various problems systemd solves. If the title GNU/Linux makes sense (which I don't think it does), then systemd/Linux makes much more sense. If Linux had started off with systemd and someone came along and said "better idea, lets tear systemd apart into a wide range of tiny applications all with different approaches, syntaxes, maintainers and functionality, with no overarching architecural approach and call it sysV", everyone would say "what a crazy idea, no thanks."
- deleted 4y ago
  [deleted]
- thaumaturgy 4y ago
  I have been pretty vocally opposed to systemd's gradual takeover of core Linux systems that I was previously familiar with, but it's clearly not going away and I'm gradually getting up to speed on it. In your example, I'm super comfortable with iptables and it would probably take me less time to solve it there than it would to discover that a systemd service could have ip address filters added to its unit file. When people say "just read its documentation" ... that seems really dismissive of both the volume and the inconsistent quality of it. I spent hours about a week ago working on a single service file for an encfs mount (not a mount unit, which is a different thing, which I also spent hours reading documentation on!). Ultimately it was only through trial-and-error that I discovered that it would only work with "Type=forking". The systemd docs do a fine job of describing the different "Type" values and how they matter to systemd, but don't fill in the blanks that certain things require certain Type values. Most of my interactions with systemd have required time with its documentation. It's fiddly and quirky and not a big improvement over historical tooling in that respect. But I recognize that it is capable of doing some things better than the old tooling could, and it's not gonna go away, so it'll just be another volume of arcana to memorize and I should get to it.
  - andrewstuart 4y ago
    You are correct. Systemd is not necessarily easy, but that because it is surfacing the power of linux and many of the concepts take some learning. Or you probably already know the concepts but do not yet know how or where systemd brings them out. It’s worth reading as much as you can stomach of the systemd documentation. Even if you’re just skimming over it, you’ll pick up useful things for the future. Like socket activation, file change activation, timers, nspawn and lots of other good stuff. You might even come to like it. Or at least forgive its sins.
  - traverseda 4y ago
    As a systemd hater, I have to say that I like the systemd approach here better than messing with iptables. The locality of behavior is nice.

by aliqot 4y ago

andrewstuart 4y ago

>> Systemd has admittedly grown on me Not suggesting you are (were) a systemd hater, but all the systemd haters might find that systemd is actually damn awesome if they stopped their hating and learned about it. Here's an instant tasty systemd tip that I used yesterday ..... I had to prevent a forward proxy server from accessing local networks. How do you solve this without systemd? Well you have to start fiddling with iptables and descend into that level of hell wherein you are fundamentally fiddling with stuff you do not want to fiddle with, and beside that solution is going to be system wide. Or, you pull out systemd and get the job done by application IP address restrictions on a per application / service level: [Unit] Description=glider service After=multi-user.target [Install] WantedBy=multi-user.target [Service] IPAddressDeny=localhost IPAddressDeny=169.254.0.0/16 IPAddressDeny=192.168.0.0/16 IPAddressDeny=198.18.0.0/15 IPAddressDeny=172.16.0.0/12 IPAddressDeny=100.64.0.0/10 IPAddressDeny=10.0.0.0/8 ExecStart=<proxy command line goes here> systemd is chock full of super awesome stuff like this if you read the docs you'll find simple solutions to challenging problems everywhere. systemd is a beautiful, integrated work of art, and there's constant payoffs and benefits from the fact that it encompasses so much functionality previously split across a huge range of inconsistent small solutions to the various problems systemd solves. If the title GNU/Linux makes sense (which I don't think it does), then systemd/Linux makes much more sense. If Linux had started off with systemd and someone came along and said "better idea, lets tear systemd apart into a wide range of tiny applications all with different approaches, syntaxes, maintainers and functionality, with no overarching architecural approach and call it sysV", everyone would say "what a crazy idea, no thanks."

deleted 4y ago
[deleted]
thaumaturgy 4y ago
I have been pretty vocally opposed to systemd's gradual takeover of core Linux systems that I was previously familiar with, but it's clearly not going away and I'm gradually getting up to speed on it. In your example, I'm super comfortable with iptables and it would probably take me less time to solve it there than it would to discover that a systemd service could have ip address filters added to its unit file. When people say "just read its documentation" ... that seems really dismissive of both the volume and the inconsistent quality of it. I spent hours about a week ago working on a single service file for an encfs mount (not a mount unit, which is a different thing, which I also spent hours reading documentation on!). Ultimately it was only through trial-and-error that I discovered that it would only work with "Type=forking". The systemd docs do a fine job of describing the different "Type" values and how they matter to systemd, but don't fill in the blanks that certain things require certain Type values. Most of my interactions with systemd have required time with its documentation. It's fiddly and quirky and not a big improvement over historical tooling in that respect. But I recognize that it is capable of doing some things better than the old tooling could, and it's not gonna go away, so it'll just be another volume of arcana to memorize and I should get to it.
- andrewstuart 4y ago
  You are correct. Systemd is not necessarily easy, but that because it is surfacing the power of linux and many of the concepts take some learning. Or you probably already know the concepts but do not yet know how or where systemd brings them out. It’s worth reading as much as you can stomach of the systemd documentation. Even if you’re just skimming over it, you’ll pick up useful things for the future. Like socket activation, file change activation, timers, nspawn and lots of other good stuff. You might even come to like it. Or at least forgive its sins.
- traverseda 4y ago
  As a systemd hater, I have to say that I like the systemd approach here better than messing with iptables. The locality of behavior is nice.