On 07/02/2017 01:37 PM, Alessandro Vesely wrote: > On Sun 02/Jul/2017 12:37:33 +0200 Christian Seiler wrote: >> This bug has nothing to do with systemd as the init system, it's in an >> optional component that's disabled by default on Debian. In principle, >> I suspect that resolved could also be used on sysvinit, if you really >> wanted to, though I haven't tried it. >> >> Furthermore, the systemd versions of Wheezy and Jessie are too old to >> already include systemd-resolved, so they are not affected at all. > > Yet, there's a man page: > https://manpages.debian.org/jessie/systemd/systemd-resolved.service.8.en.html
Oh, my bad, it's shipped in Jessie, but in a very early state of development. I suspect that the functionality that has the bug wasn't already implemented in the Jessie version. I'm not completely sure about resolved, but networkd in Jessie is only shipped as a technical preview (see Jessie's release notes), by the way, so people shouldn't be using Jessie's networkd for production purposes anyway. > I'd be curious on why tools which don't even require that systemd be PID1 go > under the systemd umbrella. The technical reason (which has been mentioned multiple times by the systemd developers in various places) is that these utilties share code with systemd when it comes to basic utility functions, such as configuration file parsing, or wrappers around common tasks that are quite cumbersome to do with just the standard C library. And since they don't want to provide a stable API and ABI for C utility helper functions, these programs are put together in the same repository. The reasoning is very similar to how the Linux kernel works, albeit on a much smaller scale. Sure, some things are definitely things that do belong in the core kernel, but there are a _ton_ of drivers and other functionality that technically could be managed outside of the kernel tree. But for the very same reason (the kernel developers don't want to have to guarantee a stable ABI for modules) people are encouraged to only have out of tree kernel modules during the initial development, and that these should be merged into the mainline kernel at some point. How somewhat related projects should or shouldn't be bundled in the same repository has always been something that doesn't have a clear right or wrong answer, and a lot of that will depend on the personal tastes of the people working on this. For example: why are most standard shell utilities all bundled together in the 'coreutils' package, but e.g. find is in the separate 'findutils' package? And 'ps' in the 'procps' package? Wouldn't it also make sense to either unbundle all utilities into their own tiny packages, or bundle them all into a large global package? And the answer to that is simply: if you had to develop all of these tools from the ground up again, then you might choose one of the other schemes, or split it up differently altogether. But because of historic reasons, and because of how the developers of the respective utilities feel, the split is the way it is at the moment. There simply is no right or wrong answer here. > Doesn't that contribute to make systemd appear > like some kind of conspiracy? I don't know about the systemd developers, but I personally don't think it's fruitful to make decisions based on the irrational beliefs of other people. If a person came up to me in the supermarket and said I shouldn't buy a particular brand of milk because the company is affiliated with the Illuminati, I'm not going to base my decision whether I'm going to buy that brand or not on that statement. (To clarify: I'm not saying that people who don't like systemd can't be rational, but I do think that anyone who claims to see a conspiracy here is not taking a rational position.) > BTW, is resolved one of them or does it require systemd? I suspect it doesn't need systemd as PID1, but I'm not sure and I haven't tried it. I'm pretty sure it doesn't come with an init script though, so that you'd have to write yourself if you wanted to use it without systemd. Regards, Christian
