How not to interact with your community 101.
Defaults matter, because even if they are changeable via a build-time flag, most of the time they won't (how many people knew this was a default before now?)
On the contrary, I think he handled it perfectly.
I've become exhausted with most discussions on social media, because conversations frequently get hijacked by loud people with strong opinions that don't express them in good faith. Without strict moderation, it can become impossible to have a rational discussion on certain topics. For example, pretty much anything on HN involving Google devolves into worthless noise.
In the case discussed in the OP, Poettering clearly has no intention of changing the default configuration (at least based on the reasons given in the issue), and has provided a way of modifying the configuration for those that care enough to change it. There's no value in further debate, and closing the issue to further discussion keeps Poettering and other contributors from getting distracted/burned out by unproductive conversation.
If people don't like it, they're free to fork Systemd or start up their own competing software project, and then they can handle community interaction for their own project in whatever way suits them.
Frankly, I wish more discussion were handled this efficiently.
Something like: "we've discussed this a number of times, see #12345" closing now
would have closed the ticket and not made the front page.
By being a top draw dick about it (when the originator was at least being earnest) the debate rolls on.
He had given a full answer, he could have left it there, but chose not to.
its this kind of "rock star" and cheerleaders that give IT a bad smell.
He was perfectly reasonable. And I don't know if you've ever managed any popular open source projects, however it's best to close tickets fast instead of letting them linger on, especially when you have over 1000 opened issues and especially if, as a maintainer, you know that you won't change your mind about that issue.
Then he got accused of being funded by Google. He actually showed restraint.
[1] https://github.com/systemd/systemd/issues/12499#issuecomment...
> He was perfectly reasonable.
The original complaint had the form "this default should be changed for reason X". Poettering's response was "our defaults are Y, and you can change them". That's not perfectly reasonable. It's a non sequitur. Poettering's response passively-aggressively ignores what the original complaint was all about, instead of simply issuing a direct rejection.
While professional courtesy is recommended, maintainers don't really owe an explanation for their work when provided for free. Put that man on a payroll and you might deserve a more detailed answer.
then to go off on one here: https://github.com/systemd/systemd/issues/12499#issuecomment... its just being a dick. Its not even entertaining.
https://github.com/systemd/systemd/issues/12499#issuecomment...
As I said, he showed restraint.
I very much agree — and I would add that there's a strong entitlement complex among loud non-contributors.
If you don't contribute anything but opinions, then be respectful, respect the author's choices, or start your own fork, which is what open source is about.
Poettering never even acknowledged that there are privacy concerns. Simply saying "if you don't like the defaults, change it yourself" is in no way equivalent to saying "I don't care about or share your privacy concerns, but here's how to override the defaults if they bother you".
Denigrating your community as the "script kiddie peanut gallery" is, at best going to piss off your community and at worse make them less likely to work with you in the future.
Especially when he had to answer in the affirmative, that there is indeed a conflict of interest, but it's a really tiny one that hardly anyone would be bothered by.
In that case, the final comment in the discussion is correct: systemd itself should not have a default, and should require the distro maintainer to explicitly set these values to whatever default they want to use.
I agree. The default should be set (and required; without defaults) by the distro maintainers downstream. Just leave them out here.
It's not bad faith to ask that question, when raising the issue previously got a complete non-answer that failed to acknowledge that there was a reason behind wanting different defaults. "Why didn't you answer the question the first time?" is fair game; Poettering provoked that response.
Stuff magically failing, with no obvious reason why. The I realise that someone has cocked up the DNS config, its been silently rejected and is now defaulting back to the default DNS config.
I want it to fail, and fail loudly, not limp on and cause odd errors.
And they're fair assumptions - Google is well known for giving funding to open source projects to get their products set as defaults.
My example does not make the assertion that Google donated/bribed the systemd project, so no, it does not make the same assumptions. It intentionally leaves any implied motivations open ended.
> And they're fair assumptions - Google is well known for giving funding to open source projects to get their products set as defaults.
The only case I'm aware of is Firefox, which had a contract with Mozilla to have the Google search engine be the default. I'm curious to hear about more though.
The privacy concerns with Google DNS seem to be partially unfounded too [1]. Granted, that is coming from Google themselves, but privacy policies are legally binding. For the record, I don't think there should be a default at all, but I have no problems with how Poettering handled this.
[1]: https://developers.google.com/speed/public-dns/faq#privacy
That sounds very accusatory to me. It’s just worded as a question.
Just mentioning Google or money does not an accusation make.
1) how broadly Google spreads its money to open source projects to get its products set as defaults
2) that Redhat is a private company who does not disclose their funding sources
I think it's a perfectly reasonable question, given the situation (Google product set as a default in an open source project).
Red Hat's IPO was in 1999, and they were bought by IBM in 2019.
That would technically be a lie. The answer is actually a qualified "yes".
Maybe, but lowering a discussion to accusations of bribery is also not how to interact with project members.
But one person is a paid maintainer for the project, the other an (admittedly paranoid) non-paid user. The standards for a paid employee are (and should be) higher.
You don't get to be an asshole to open source maintainers just because they're "paid" and it's "their job".
If in either situation, a person is an asshole to the paid employee, said employee most definitely has a right to defend themselves.
But nowadays, a lot of restaurants will side with the waiter on such issues and they're damn right to do so.
I'll add that what you're seeing here is but the tip of the iceberg of abuse that Lennart has to deal with every day. I challenge you to put up with 1/100th of what he's putting up with without "raising your voice" or what have you.
Not accepting any discussion by blocking all community efforts is quite bad imo. Would like still like to start any discussion, put effort into making even smallest change, to be blocked? This is strong sign of ignorance.
I often contribute to OSS on gitlab and github. When a single/first MR is not merged OR commented on within a week I don't even try there again, waste of time.
I'm just surprised that people don't see how his communication style (in general and in the linked thread) makes interactions harder than it needs to be for himself and everyone involved.
Give Poettering a break! You have no clue what is to be in his shoes. ;)
EDIT: 172 distinct build-time options, in today's master. Not all appear to be used as part of the build, since the build script only references 142 of the options set in meson_options.txt.
Edit: Speaking as a package maintainer myself.
I expect that package maintainers are human, and put a fair bit of trust in the upstream developers, and will only tinker with build flags for issues which are specific to the distro. I also expect that they will miss changes to defaults, or new flags, or deprecated flags, quite often.
I looked at the systemd defaults to see this issue for myself, and the fact that Google's nameservers are in the DNS defaults didn't immediately pop out to me (it's a list of 8 mixed IPv4 and IPv6 addresses).
Absolutely. For a responsible package maintainer, reading changelogs and release notes of new releases is a must. For sensitive software (eg: key system libraries), I usually also look at the full diff between releases. I also run tests with dependent software before uploading my version, lest I break any packages that depend on mine. etc.
And this is quite typical of your average distribution package maintainer.
Someone posted the other day that an autotools/automake should canonically be run like this:
./configure
make
make install
./configure --help
(read "help" intently)
mkdir build_output_dir
cd build_output_dir
../configure [huge list of options for the build]
make
make install
Pretty much everyone who ever opened /etc/systemd/resolved.conf
That's a vanishingly small percentage of people who use systemd.
Also it's the answer to the question. The defaults are visible in config files as commented out lines. No need to check build scripts, etc.
The defaults being in a commented-out section in one of these four locations (and in a file whose name does not match the linux standard of resolv.conf) is, frankly, not a big help in identifying what's really being used.
https://jlk.fjfi.cvut.cz/arch/manpages/man/systemd-resolved....
If user wants to know what's really being used for name resolution he should go to /etc/nsswtich.conf and /etc/hosts and /etc/resolv.conf as usual.
But then if one is using, say, dnscache or dnsmasq or MaraDNS or BIND or PowerDNS or any other such software, one has to do the same thing. /etc/resolv.conf will list simply 127.0.0.1 or some such, and one has to go further to the configuration files of those softwares to find out what they are using for resolution/forwarding.
DNS softwares having their own configuration files is normal. falcolas is apparently getting at the fact that systemd-resolved uses the same style of configuration as the other systemd programs do: files and drop-in directories in /etc/systemd, /run/systemd, /usr/local/lib/systemd, /usr/lib/systemd, and (if configured) /lib/systemd, meaning that one has to read all of this together.
Anyway, in default config, there will be only the file I mentioned. And whole this issue is about default configuration.
You are pointing to the wrong manual page, incidentally. It's resolved.conf(5). This fails to list /usr/local/lib/systemd/resolved.conf.d/ , which is scanned before /usr/lib/systemd/resolved.conf.d/ (and if configured /lib/systemd/resolved.conf.d/).
He says the easiest way is to recompile systemd from source.
Presumably he knows more about systemd then the average Linux user.
Anyway, per his advice, here is how I worked with my Linux distribution to fix the problem: I switched away, and donated to ones that don’t use systemd.
In one side major linux distros took in systemd (as, ok, granted, the "less worse" of the options) so the point is moot. I mean everybody should know how LPs management of the project works.
At the same time I can understand trying to cut down on drama in online discussions (though I agree that default might make more sense as a run-time configurable, not as a build-time one).
(And yes defaults are important)
Yes, it does matter. It's being pushed out as the init system for a lot of linux systems, and I believe it's perfectly reasonable to expect that your fallback DNS resolver is not set to a for-profit data-collection organization.