Firstly, thank you for taking the time to answer. Some comments: > It doesn't. All this stuff is opt-in. If you don't want to use it, don't. I said I feared

Firstly, thank you for taking the time to answer. Some comments: > It doesn't. All this stuff is opt-in. If you don't want to use it, don't. I said I feared a package used it, because it made sense at packaging time. Let's be honest, upstream often has less than sane defaults. In that case, there will most likely be some hair-pulling on the user/sysadmin side before he figures what what's wrong. And then, he will definitely blame systemd (even though it's not really systemd's fault). > What's a bit unfair though is that you imply that the various technologies where equivalent in behaviour and would be different only in performance. That's really not the case. The eBPF stuff allows configuration of per-cgroup, i.e. per-service or per-container access control. And that's a massive advantage. Classic Netfilter doesn't allow that: you can't tell it to permit all traffic to bittorrentd.service, because service/container/cgroup information is not available to it. Yes, people have tried to make that work, and there was some support for it in the kernel, but only for egress, and that made it pretty useless ultimately. My bad. I mentioned the performance aspect because AFAIK, that's the main problem solved in the big players' case. I'm fully aware of Netfilter's limits. It is very powerful, no doubt about that, but it operates at the network level. Therefore, it has limited knowledge regarding the software running (unlike, say, the firewall integrated in Windows that can permit/deny depending on the process that attempts to contact the network). eBPF/XDP bridges that gap, which is an interesting feature for the user (as you rightly mentioned). > I know it is fashionable to blame systemd for everything, but seriously, eBPF+cgroups and all that kind of stuff is the result of the kernel's development scheme, and systemd only follows that and exposes what they came up with. If you don't like where kernel development goes, please complain about and to the kernel community, but systemd is just a consumer of what they do, and I couldn't care less if per-service firewalling is ultimately implemented based on netfilter, on nftables or on ebpf/cgroup. I didn't blame systemd for eBPF :-). I'm fully aware that the kernel community often has different concerns that what us user-peasants would like. I am bothered by the overlap between eBPF/XDP and Netfilter and more importantly, that the tooling seems to be lacking. Using it in systemd is opt-in, sure. However, a user that opts into this feature is not aware of the technology used underneath. When debugging time comes, he will be wondering what this magic is. > As it turns out only the latter ended up being capable enough to make this possible. And I accept that, and then made use of this. Why does systemd need to expose it ? As you said, it's fashionable to blame systemd for everything but I feel you're just making it easier by adding knobs for everything. What is the scope of systemd ? Where exactly does it stop ?