3 ms·

Regardless of marketing pitch, resolver is no job for systemd. Or any other init/pid 1 process. Systemd is known to but in into areas that are not / should not

Regardless of marketing pitch, resolver is no job for systemd. Or any other init/pid 1 process. Systemd is known to but in into areas that are not / should not be of concern for it. Also known to do stuff half baked or changing things because you can. So I'd very much love to see systemd fingers completely outside of dns resolver, that way we wouldn't have this conversation at all.

geofft 9y ago
> Regardless of marketing pitch, resolver is no job for systemd. Or any other init/pid 1 process. Correct, which is why it's not part of /bin/systemd or any other init/pid 1 process.
- binaryapparatus 9y ago
  You know, first thing that raised some flags with systemd for me, couple of years ago, is constant marketing push, like this one. Having one monolith executable or ten executables that increasingly demand each other is the same thing. Oh wait its name also suggests it is part of the package, being named Systemd-resolved. There is number of reality distortions like this one that systemd people tried to perform, during the several past years.
  - geofft 9y ago
    I don't know what you mean by "marketing". I am mentioning technical facts; you are saying things like "systemd tries hard to do stuff it doesn't really understand" and "reality distortions." Can we have a technical conversation?
    - SomeStupidPoint 9y ago
      Because being technically correct while strawmanning the other person's position for your comment to even be relevant is the worst, not best, kind of correct. Being technically correct is only the best kind of correct if your technical point is actually relevant. Having a "technical conversation" would require you engaged with the person you were replying to, not engaging in what can only be described as "technical trolling". For the record, the vocal "technical trolls" are why I don't like systemd, despite having little opinion on the technical merits.
      - geofft 9y ago
        That's a fair objection, thanks. I don't believe I am trolling or taking a strawman interpretation of 'binaryapparatus's arguments, but if I am I'd appreciate correction! I think it is relevant that the current state of affairs (with glibc) isn't actually better at preventing DNS leakage, and that systemd-networkd has relevant functionality specifically to address the underlying use case in a way that reliably blocks DNS leakage. I also think it is relevant that the functionality is not in pid 1 and (although I didn't say it, and maybe I should have) there is no particular obligation or desire on the part of systemd's pid 1 binary to use systemd-resolved. They're developed in the same project, and there are some nice things you get by using them together, but you don't have to, and you experience no loss of functionality as compared to the status quo ante systemd if you choose to use systemd as init plus the glibc stub resolver. (In particular, I think that's the standard way most distros configure systemd.) I was probably rude in my reply about how this functionality is not in pid 1, and for that I apologize, but I don't think I was irrelevant. Maybe I don't understand the objection to having systemd-resolved developed alongside an init system? (Developing everything together and using common routines where possible is the traditional UNIX approach, epitomized by the current BSDs.)
        SomeStupidPoint 9y ago
        > there is no particular obligation or desire on the part of systemd's pid 1 binary to use systemd-resolved > there are some nice things you get by using them together These two statements contradict each other, and you said them one after the other. The accusation of trolling stems from this behavior: if you're not even being consistent for the span of two sentences, why should I believe you're advancing a thoughtful, genuine argument? The evidence you present (by so flippantly contradicting yourself) is against that. > I was probably rude in my reply about how this functionality is not in pid 1, and for that I apologize, but I don't think I was irrelevant. I believe you misunderstood the objection to the two pieces of software being coupled in your rush to correct a technical point -- it's completely irrelevant if the two processes both run under the same pid as long as it's the case that "there are some nice things you get by using them together". The concern is that a process which shouldn't be coupled to the process of DNS resolution at all is injecting these "nice things" through coupling, and that systemd is making a whole suite of such software around their init system. Your reply, well, doesn't address that concern, and doesn't seem to even be aware that is the concern. > Maybe I don't understand the objection to having systemd-resolved developed alongside an init system? (Developing everything together and using common routines where possible is the traditional UNIX approach, epitomized by the current BSDs.) The concern is inappropriate coupling via these "nice things" that gives systemd inappropriate sway over what non-init portions of the system are, while degrading the overall resilience and versatility of components, and that over time, the process to replace systemd will require replacing substantial portions of the OS, rather than just the init system.
jryan49 9y ago
It's a separate program, it's not part of init.

geofft 9y ago

> Regardless of marketing pitch, resolver is no job for systemd. Or any other init/pid 1 process. Correct, which is why it's not part of /bin/systemd or any other init/pid 1 process.

binaryapparatus 9y ago
You know, first thing that raised some flags with systemd for me, couple of years ago, is constant marketing push, like this one. Having one monolith executable or ten executables that increasingly demand each other is the same thing. Oh wait its name also suggests it is part of the package, being named Systemd-resolved. There is number of reality distortions like this one that systemd people tried to perform, during the several past years.
- geofft 9y ago
  I don't know what you mean by "marketing". I am mentioning technical facts; you are saying things like "systemd tries hard to do stuff it doesn't really understand" and "reality distortions." Can we have a technical conversation?
  - SomeStupidPoint 9y ago
    Because being technically correct while strawmanning the other person's position for your comment to even be relevant is the worst, not best, kind of correct. Being technically correct is only the best kind of correct if your technical point is actually relevant. Having a "technical conversation" would require you engaged with the person you were replying to, not engaging in what can only be described as "technical trolling". For the record, the vocal "technical trolls" are why I don't like systemd, despite having little opinion on the technical merits.
    - geofft 9y ago
      That's a fair objection, thanks. I don't believe I am trolling or taking a strawman interpretation of 'binaryapparatus's arguments, but if I am I'd appreciate correction! I think it is relevant that the current state of affairs (with glibc) isn't actually better at preventing DNS leakage, and that systemd-networkd has relevant functionality specifically to address the underlying use case in a way that reliably blocks DNS leakage. I also think it is relevant that the functionality is not in pid 1 and (although I didn't say it, and maybe I should have) there is no particular obligation or desire on the part of systemd's pid 1 binary to use systemd-resolved. They're developed in the same project, and there are some nice things you get by using them together, but you don't have to, and you experience no loss of functionality as compared to the status quo ante systemd if you choose to use systemd as init plus the glibc stub resolver. (In particular, I think that's the standard way most distros configure systemd.) I was probably rude in my reply about how this functionality is not in pid 1, and for that I apologize, but I don't think I was irrelevant. Maybe I don't understand the objection to having systemd-resolved developed alongside an init system? (Developing everything together and using common routines where possible is the traditional UNIX approach, epitomized by the current BSDs.)
      - SomeStupidPoint 9y ago
        > there is no particular obligation or desire on the part of systemd's pid 1 binary to use systemd-resolved > there are some nice things you get by using them together These two statements contradict each other, and you said them one after the other. The accusation of trolling stems from this behavior: if you're not even being consistent for the span of two sentences, why should I believe you're advancing a thoughtful, genuine argument? The evidence you present (by so flippantly contradicting yourself) is against that. > I was probably rude in my reply about how this functionality is not in pid 1, and for that I apologize, but I don't think I was irrelevant. I believe you misunderstood the objection to the two pieces of software being coupled in your rush to correct a technical point -- it's completely irrelevant if the two processes both run under the same pid as long as it's the case that "there are some nice things you get by using them together". The concern is that a process which shouldn't be coupled to the process of DNS resolution at all is injecting these "nice things" through coupling, and that systemd is making a whole suite of such software around their init system. Your reply, well, doesn't address that concern, and doesn't seem to even be aware that is the concern. > Maybe I don't understand the objection to having systemd-resolved developed alongside an init system? (Developing everything together and using common routines where possible is the traditional UNIX approach, epitomized by the current BSDs.) The concern is inappropriate coupling via these "nice things" that gives systemd inappropriate sway over what non-init portions of the system are, while degrading the overall resilience and versatility of components, and that over time, the process to replace systemd will require replacing substantial portions of the OS, rather than just the init system.

jryan49 9y ago

It's a separate program, it's not part of init.