On Thu, Oct 1, 2020 at 8:34 AM Peter Robinson <pbrobinson@xxxxxxxxx> wrote: > > On Wed, Sep 30, 2020 at 9:27 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > > > On Wed, Sep 30, 2020 at 3:42 PM Ian Pilcher <arequipeno@xxxxxxxxx> wrote: > > > > > > On 9/30/20 2:19 PM, Michael Catanzaro wrote: > > > > On Wed, Sep 30, 2020 at 2:00 pm, Ian Pilcher <arequipeno@xxxxxxxxx> wrote: > > > >> And what about places where NetworkManager isn't used? (Just because > > > >> it's the default, doesn't mean that it's used everywhere.) > > > > > > > > NetworkManager is used everywhere by default. If you want to disable it, > > > > you have to do manual work to do that. If you do manual work to disable > > > > NetworkManager, you can also do manual work to disable systemd-resolved. > > > > > > Indeed, but I was responding to this: > > > > > > On 9/30/20 1:35 PM, Neal Gompa wrote: > > > > Please, no more package splitting. And NetworkManager is used across > > > > all variants of Fedora, so resolved should be installed in all places > > > > where NetworkManager is used. > > > > > > Which (to my reading) says that because NetworkManager is the *default* > > > everywhere (even though it can be uninstalled), systemd-resolved should > > > be *installed* everywhere (and should not be uninstallable). I don't > > > follow that logic. > > > > There are not a ton of advantages for splitting it, since it's only a > > couple of binaries averaging 2MB with a few unit files. Given that we > > require it for default NetworkManager configurations now, there's not > > a lot of value in making that complicated. Splitting has a cost too, > > in the form of extra metadata, upgrade paths, etc. > > > > Moreover, *all* Fedora variants use NetworkManager. *ALL* OSTree > > variants, as shipped today, *MUST* use NetworkManager. > > NetworkManager's configuration will use resolved as a local resolver. > > Anything baked into an OSTree cannot be removed anyway. > > > > And like it or not, all our legacy network configuration mechanisms > > are deprecated and *will be removed eventually*. > > > > Literally the only reason networkd was split out was because Fedora > > CoreOS was chainsawing it out at image build time and making it > > impossible for people to use it. To be frank, I do not want more > > permutations this low in the stack. It makes life incredibly difficult > > for figuring out working network setups. > > > > My reply was aimed at Peter saying he'd like to not ship resolved, and > > I'm saying that we should *not* do that, because it makes things even > > harder and more complicated. > > So you're saying that if this doesn't work for IoT and actively causes > deployment problems, potentially across millions of devices, we can't > turn it off, change the option and have to basically suck it up and > deal with all the problems? Well that makes Fedora completely > unappealing and I feel against the project of people being able to > choose. It will make people go elsewhere and frankly so will I! If there are problems with our configuration for your use-case, the idea is to actually report the issue and/or fix them. It's not like we don't have systemd engineers in Fedora. If there is some fatal flaw, then I would *love* to know, but so far, there doesn't seem to be one. And throwing around "millons of devices" as a reason for me to care about IoT more than anything else is not a good way for me to care more about you. You can't prove it to me, and it's easy to prove more devices *not* running it than running it. To be blunt, I expect IoT environments to be even worse off in terms of taking advantage of DNS security features, because they often rely on mobile networks (which don't have any DNS security features) and tunnels over those networks (which usually can't have DNS security features) to communicate. In that case, what we have here would improve that situation for you. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
