Systemd: Don’t fallback to Google NTP and DNS
github.com
github.com
This fallback will only be used when:
* You have no DNS and NTP servers assigned via DHCP (your router does by default in 99.99% of cases) * You have no DNS configured in /etc/resolve.conf * Your distro does not change the defaults to nothing or something else (almost every distro does) * You still have internet connectivity (somehow)
In most cases, these conditions would simply not be met because everyone has DNS configured somehow. This isn't a fallback for when your DNS is unreachable, it's for when no DNS has been configured at all anywhere (including by distro upstream) but you still want to use the internet.
So in that rare circumstance, where your distro didn't change upstream defaults and you don't have any DNS configuration, it will fall back to Google DNS.
These are set for testing/development purposes. For which the priorities are availability/reliability/speed. For those criteria, Google/Cloudflare are empirically the best worldwide.
This literally is used for test-resolving that at best probably would identify a systemd-dev. Everyone else shouldn't care because it's overwritten by distro maintainers.
I assume some of these use it.
>why the tests can't be modified to set DNS/NTP?
I am not a systemd maintainer, they probably could be adjusted, but frankly I don't imagine they or I care enough to do so.
Like I said, this change only affects the devs, so why should it matter to anyone else.
It's working anyway, i think it's resolving off the root nameservers...
I guess... You couldn't go more private than that.
It’s /etc/resolv.conf, and systemd overwrites it, Network Manager overwrites it (like every 10 minutes), dhcp overwrites it, etc. What do they overwrite it to? Most just get it from the router even if the router has no assigned servers. These days manually managing /etc/resolv.conf by hand requires hooking into every service that overwrites it on most systemd distributions. So really the people this change would affect are those with misconfigured routers.
My issue is why they didn’t go with a more private DNS such as Open DNS or even Cloudfare DNS. Google’s privacy policy is worse than either of the two. It seems the questioner asked in bad faith but I would’ve hoped Poettering would respond to the validity and dismiss the malintent instead of dismissing the whole issue.
chattr +i /etc/resolv.conf
Both of them have yaml syntax though, which is imo extremely unfortunate for this kind of configuration.
It’s /etc/resolv.conf, and systemd overwrites it,
Network Manager overwrites it (like every 10 minutes),
dhcp overwrites it, etc. What do they overwrite it to?
/etc/resolv.conf is routinely touched by stuff like NetworkManager and other stuff. Systemd-resolved config seems like the correct place, but I'm not sure how that plays with network-manager.
chattr +i /etc/resolv.conf
I'm not sure I'm personally a fan, just saying it's something that might become more common based on my read of the systemd docs awhile back.
Not only that, with suitably configured nsswitch.conf, (e.g. with nss-resolve), you might find out that your /etc/resolv.conf is used only by apps that have their own resolver and ignore the glibc one.
NetworkManager? No it's in sysconfig/interfaces. No that was last release. Now it's in a netplan YAML file you get to learn all about.
So many terrific "improvements" every release!
If you are using NetworkManager, then in NetworkManager, per each connection. You can also configure which zones each of them can resolve, if they are not global.
So you can things like using your prefered global DNS and then have per-VPN DNS that can resolve hosts in whatever network you VPN into.
There isn't. There are half a dozen packages on a Linux install that each will reset the DNS settings as they wish.
Setting your network DHCP with the correct values tends to work, because everything queries it. But I still didn't manage to replace the upstream DNS on the DHCP server.
1. local resolving/forwarding proxy DNS server on loopback
2. resolving/forwarding proxy DNS server on another machine on the LAN with a known IP address
3. resolving/forwarding proxy DNS server on another machine on the LAN but only the LAN's DHCP server definitively knows what its IP address is
4. resolving/forwarding proxy DNS server out on the WAN with a known IP address
5. resolving/forwarding proxy DNS server out on the WAN but only the LAN's DHCP server definitively knows what its IP address is
There's scope for variation within each of these categories, moreover.
Part of the confusion is that most DHCP clients assume that you are doing #3 or #5, and continually switch over to them, until you turn that off by ignoring/superseding the relevant DHCP options. Traditionally in the Unix world one actually generally did #1, with a local BIND being as much a thing as a local Sendmail. Some DHCP clients can do a forwarding variant of #1, but only interoperate (easily) with a few forwarding proxy DNS server softwares. That nowadays #1 might be done with dnscache, or dnsmasq, or PowerDNS, or MaraDNS, or unbound, or something else, introduces configuration file variance but doesn't change the fundamental nature of #1.
systemd-resolved is mainly #1 too, but can operate in a mode where it is #3 or #5, in which case you have it and the DHCP clients doing overlapping work. One of the things that, in fairness, one can actually praise about systemd-resolved is that whilst conventional DHCP clients actually end up rewriting /etc/resolv.conf itself (via resolvconf and similar mechanisms) systemd-resolved instead rewrites two files of its own, and lets you rather choose to symbolically link /etc/resolv.conf to (one of) them. If the conventional DHCP clients also did this more, there'd be less of the conflict between #1/#2/#4 and #3/#5.
Why even bother covering this case? It seems most likely to come up when this situation is created intentionally, in which case you don't want to go and ruin it by trying to be clever.
It's sort of a sane/understandable default, considering all the context.
Though maybe they could switch to CloudFlare.
Google keeps Permanent Logs and doesn't make it easy for me to see whether that information can be shared and to whom.
Cloudflare only stores Public Resolver Logs, deletes them after 25 hours, and acknowledges it shares an anonymized subset of the data only with APNIC Labs.
Your comments about build pipeline and firmware are interesting, and to me fall into two rough camps:
* preventing bugs from leaking private info: to be honest, I trust neither on this, and I'm more worried about Google being sneaky in its ToS than Cloudflare being sloppy in their dev process.
* preventing infiltration from state actors and hackers -- this is a non-goal for me.
So for my goal of limiting the power of surveillance capitalism on my life, Cloudflare appears to be a clear winner.
On the other hand, if it does present the servers and it's still configurable, might be a bit of a different story.
In my experience with systemd-resolvd, things happen that make it _believe_ there is no DNS configured, and you end up with something incomprehensible (a "hidden default" or some such).
Please let it just fail so that one at least has a chance of understanding what's happening rather than some magic.
Typical systemd rationalization, imho: "should anything be perceived as wrong, perform hidden magic."
But I think hard failure is best approach in this case, because this behavior will also make it harder to troubleshoot issues, let say you are setting up a network and misconfigured your router that doesn't provide DNS now you will be puzzled why Internet works on some machines while it doesn't work on others.
Which is in fact the core of the problem. It's actually a fairly rare kind of proxy DNS server software, one for which there isn't really a sensible universal default for the unconfigured case.
As you mention, this _is_ a rare circumstance, and likely self-induced by some sort of "power user". I assume there are few of those power users who want the choice made for them.
Would be 9.9.9.9 instead of 8.8.8.8. If this would be better is probably a matter of preference. Google owns many, many servers, so maybe using the underdog eases the mind of some people.
Buried in the pointless flamewar is the maintainer's own reply which is the way forward:
> Anyway, if there's a well respected network of community DNS servers that can roughly match Cloudflare/Google we can add, sure.
That is the correct and initial response the maintainer should have given. It puts the onus on OP to show how their preferred DNS stacks up against Cloudfare/Google.
Instead, the maintainer plays dumb wrt the importance of defaults, essentially guaranteeing that OP will escalate the rhetoric. Worse, the maintainer responds in kind.
If the maintainer had gone the correct (and easy!) route, we'd all benefited by having learned how this non-profit DNS stacks up against the others from a technical standpoint. (How does it, anyway?)
And to cover my bases-- when spam gets through to the inbox, no serious person asks, "Why doesn't anyone ever talk about the spammer's responsibility to prevent spam? What about the spammer?" Similar logic applies for why I'm talking about maintainer and not OP.
I think "buried" is an OK description of that.
But the absolute correct behavior would be a hard failure, because if you have IP properly assigned and routing setup but no DNS, then you either purposefully set it up that way and don't want DNS to work, or you have misconfigured network setup which you should be aware about it, without having to troubleshoot why some machines don't have working Internet while others seem perfectly fine.
Probably the best way to get this "fixed" is to propose that resolved fall back to being a full recursive resolver. Poettering won't be able to resist adding more scope.
The Privacy Policy for Google's public DNS service explicitly says that they don't do that. If you really think Google is doing it then you should take it up with the FTC who would really enjoy making an example out of Google.
How do you prove it though? Google will not just give you the source code of their DNS infrastructure and even if they did there is no way to prove that it's indeed that code that is running and not a modified version that does collect data?
Where are you gathering that knowledge from? Can you cite a source please.
The problem is that ultimately there is a conflict of interest - Google is an advertising company that benefits from knowing as much as possible about people for ad targeting purposes, and as such some people (like me) might not be willing to trust them.
This quote is from Google's security infrastructure whitepaper:
"""Google’s source code is stored in a central repository where both current and past versions of the service are auditable. The infrastructure can additionally be configured to require that a service’s binaries be built from specific reviewed, checked in, and tested source code. Such code reviews require inspection and approval from at least one engineer other than the author, and the system enforces that code modifications to any system must be approved by the owners of that system. These requirements limit the ability of an insider or adversary to make malicious modifications to source code and also provide a forensic trail from a service back to its source. """
I don't think the conflict you mention exists. Google benefits when people use the open web. They run DNS because DNS is critical to web user experience and ISP DNS is garbage. Also, by the way, ISP DNS privacy story is a complete disaster.
Seems unlikely.
1: https://gizmodo.com/meet-the-woman-who-leads-nightwatch-goog...
Stop pretending like there's no regulatory capture going on. Otherwise we would already have antitrust cases going on with many of those big corporations.
I am being 100% serious when I ask: What bad does someone expect to happen as a result of this.
For fun uses of this data, I recently talked to a company that ties medical conditions derived from your browsing behavior to your online profile and then provides a platform for insurances companies to target you based on it.
Do you have any concrete evidence of what you claim?
I really don't understand why those DNS services are so popular. All you need is list of 13 root DNS servers[1] (you only need one, but 13 for resiliency) and a recursive resolver and you can run your own caching server.
> We do not correlate or associate personal information in Google Public DNS logs with your information from use of any other Google service except for addressing security and abuse.
Also, the wording implies they can aggregate data, then use it for other purposes (like spying on competitive web sites, etc.)
Finally, it implies they are retained, which means law enforcement has access to the logs (in many cases, without a subpoena).
Google is enriched when it can associate consumer IPs with DNS queries. Collecting that sort of information and compiling it into a advertising profile is part of Google's business. Giving state actors a view of that information part of Google's history.
Some people are just philosophically opposed to Google's information gathering mission. From such people's perspective, anything that directly helps Google learn something (or even make a little money) is bad.
> They specifically claim not to though
That additional vector for monetization still exists. I stand by the statement that the ability to make those ad-relevant associations enriches Google. They are not necessarily monetizing that part of their empire right now, but they've pivoted other products in the past from "we're just trying to improve the Internet for it's own sake" to "we use this for advertising".
Privacy policies change all the time, often with little warning. There'll be a post here on HN if it happens and a bunch more techie folks will switch their DNS to 1.1.1.1 or something, but lots of people will just stick with 8.8.8.8, many of them unknowingly. Perhaps unknowingly because the Google address has become so common that FOSS projects are using it as a default.
https://developers.google.com/speed/public-dns/privacy
Edit: let's suppose for a moment that Google is not evil, does not cooperate with the NSA and doesn't make bad use of that information. It's still a liability and any data leak will be a problem for anyone using Google's DNS. Some things are better not being logged at all or at least not permanently.
That’s not what your link says.
The permanent logs are a sampling of the temporary logs
> The permanent logs are a sampling of the temporary logs where your IP address is removed and replaced by a city or region-level location.
What I understood from it is that they replace your IP address with an approximate location but keep the rest of the data. Can you explain me how you interpreted it?
Temporarily Logs (2 days):
- Google logs the IP address of every device sending a DNS query.
- For DNS-over-HTTPS, logs Content-Type & Accept HTTP headers
Permanently Logs:
- Client's autonomous system number
- User's geolocation within 1 km^2 and 1000 people.
- Timestamp
- Requested Domain Name
- Request Domain type
- Transport Protocol
- EDNS version, option
- and a few more, essentially everything but your IP address.
This is enough permanent information to successfully identify the vast majority of people even if they never permanently log your IP - and that's just by itself, not including if you use other google services. Other services such as Cloudflare DNS or OpenDNS provide a higher degree of privacy and can even be faster than Google's DNS.
Google's DNS policy: https://developers.google.com/speed/public-dns/privacy
Cloudflare's DNS policy: https://developers.cloudflare.com/1.1.1.1/privacy/public-dns...
OpenDNS's policy: https://umbrella.cisco.com/blog/privacy-policy-update
How? I don't think this is true. You also reworded and omitted stuff from the disclaimer.
As for this not being enough information to identify someone, it really is. Lets assume you use Google's DNS and no google tools, block all trackers, etc. (which the vast majority of people do not do). Lets say the authorities grab your computer, and somehow have access to Google DNS data (CLOUD Act) and want to see what you did online. They can already filter down DNS queries to 1000 people (and thats assuming all 1000 people use google dns, which again they do not). They can figure out what software performed queries based on EDNS data. Timestamps further filter down the dataset if you have a general idea of a person's schedule. With ECS they can further narrow down by service provider. All of sudden those 1000 autonomous ids have been significantly narrowed down using just general techniques, if you're targeting a person you will almost certainly be able to use the rest of the data to tie an ID to machine. If you use other google services or even just visit sites with google analytics that ID is even easier to compromise. Every piece of data collected is a piece of data that can be used to identify you, that's the price of convenience.
EDIT: Would like to mention even the act of an machine going offline, which will occur if an authority confiscates your machine will narrow down IDs as now you only have to look for IDs that stopped communicating with Google's DNS at time of confiscation.
Distros/users are encouraged to change these defaults and many do.
Seems pretty clear cut and simple to me.
Especially when people are refusing to understand the reasoning and logic explained from last time. It's already been explained, a quick duckduckgo search can show quickly what the reasons are and why the whole privacy argument is irrelevant here.
Instead, he chooses drama.
Why would he change it?
He says it clearly that it's the responsibility of distro maintainers to modify these defaults which they are encouraged to do.
It's everyone else who is choosing drama. This is for development purposes, the entire privacy argument is completely irrelevant.
His way generates conspiracy and alienation.
>That's what good leaders do. Small price to pay to get good will and a large group of bystanders on your side.
I don't think he cares about people who are determined to stay ignorant. Especially of those who refuse to comprehend the needs/use cases for different parties.
Frankly considering he has received death threats about systemd, I am surprised he even put a response at this point. It would make sense to me if he just closed the ticket immediately with a link to the previous discussion.
Drama is irrelevant and wouldn't change anything. At worst, he gets his issue tracker filled. If it bothers you, then the only thing that you can do is change to Devuan or don't use systemd-networkd/systemd-resolved. Distros are going to continue using systemd irrespective of this nonsense drama.
That would have been overwhelmingly preferable to
> Christ, what's next? You accuse us of controlling people's minds with vaccinations we get directly from Bill Gates? And that systemd uses 5G to spread CoV-2?
, yes!
Some people are really bad at "information retrieval" (and some people are unusually non-worried about public pressure), so maybe finding a link into the previous discussion would've been more work for Poettering than what he actually did.
The part of the comment in question:
With the above response, might I ask the developers a question: has this project received any donations from Google?
Although the decision theoretically affects them, they shouldn't constantly nag the maintainers. (Not respecting their decision is not a sign of great character either.)
Haven't we learned enough over the years from projects like PHP and MySQL that having defaults "for developers" and expecting them to be changed for production use is a terrible idea?
The defaults should be sane, secure, and privacy-forward for the majority of users. If such defaults can't be agreed upon, there should be no defaults and the users should be forced to set it appropriately for their needs.
---
Personally I gave in to the Google monster years ago so it doesn't bother me, but I can certainly see why a lot of people would find these defaults concerning.
Beyond that, I definitely agree with those who are pointing out that the fallback behavior altogether is undesirable. If my chosen DNS servers fail to respond I don't want my system to go out and try some other random servers, I want it to indicate a failure and let me fix it.
EDIT: I assumed there were also runtime configs based on the name "fallback."
My question is primarily why you need compiled-in fallbacks, and secondarily why the fallback configs aren't pulled from config files.
As Lennart says, asking your distro vendor to set defaults or just doing it on your own system is much better. This issue is just being upset on behalf of the people that don't mind or care and just want working infrastructure.
https://www.freedesktop.org/software/systemd/man/systemd.net...
https://www.freedesktop.org/software/systemd/man/timesyncd.c...
So, in a few months to a few years, when systemd silently switches to DNS over HTTPS, what then? Maintain a (growing) blacklist of public DoH servers?
I'd much prefer my software to fail (and let me know), rather than assume some default someone, somewhere, somewhen thought a good idea.
To me this is more evidence that Systemd is really just "Poetteringd": whatever he feels like it should have, it has. Really disappointed that distros continue to use this software rather than start a community replacement that addresses its shortcomings.
If I re-did systemd, it would retain the same functionality, but not come enabled by default, and it'd be broken up into independent packages to be installed as needed. It would also use standard interfaces and do away with the binary formats, defer to existing system software rather than default to its own custom versions, de-complicate its awkward filesystem tree and simplify management of service configs, make the command-line interface more sane, and begin integrating more cloud-specific features to replace more complex cloud software (such as for service discovery, cluster management, and HA).
All these fixes would allow the "anti-systemd" crowd (of which I am a card-carrying member) to run a simple init system if they want, or extend it to the full range of systemd functionality. It would remove glaring pain points and user friction, embrace the existing system's default functionality (and backwards compatibility), and extend the software to be more useful in cluster environments. In addition, if this were maintained by the community, all distros could adopt it like they did systemd, and we don't have a half dozen different service systems like before.
Now please somebody reply and tell me why this is a terrible idea...
My theory is that the big distros are intentionally destroying forwards and backwards compatibility on the desktop as much as possible.
The more often window managers, desktop software, etc., stop working, the less their own teams have to compete with existing software. Wayland’s X11-as-a-second-class-citizen and gtk’s elimination of API stability are two other good examples of this.
Also, tearing down established standards is a great way to sabotage the various BSD’s out there.
What they don’t get is that sabotaging the rest of the community is undermining their own market share within Linux, even as it shrinks Linux’s market share.
I see this sentiment a lot and I don't get it. The developers I've talked to have been doing a lot of work to get XWayland working and to fix all the edge cases. And GTK has been API stable for years, the only thing that really seems to have broken was themes. And actually now GTK3 is feature complete and will not be receiving any more changes except bug fixes.
As far as init systems go, there seems to have never been any real standard and most distros always seem to have done their own thing. It does not seem like anything could be done there especially when a low level piece of software like this needs to use Linux- or BSD-specific APIs. It simply is not possible to have a portable standard there right now.
I have a humble request, please don't continue by promoting these unfounded theories and accusing people of sabotage. I personally would welcome a friendly fork of systemd to make some positive changes but it won't happen if people are doing it out of hostility. Many of the issues in the GP post have been brought up over the years. Upstream and the distros all have a stance on them and there is a reason why things are the way they are. It would be unwise to proceed without having substantial discussions with them to put resources where they are actually needed most. There was already a hostile fork that died because of not paying attention to this.
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?)
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.
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
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".
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.
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.
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.
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.
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.
Give Poettering a break! You have no clue what is to be in his shoes. ;)
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.
Not questioning if Google does it or not but I was made to believe that IP is not really useful for ads targeting because it just doesn't work great with multiples users behind a single IP. Now with CGNAT on both type of networks (fixed and mobile), using IP for targeting does not seem pertinent to me.
Fair response IMO, this is the type of issue that can attract a lot of noisy opinions so very reasonable to lock comments to contributors.
Both are called systemd but one is actually only a single module of the other.
/etc/systemd/resolved.conf.d/fallback_dns.conf
[Resolve]
FallbackDNS=1.1.1.1 1.0.0.1 2606:4700:4700::1111 2606:4700:4700::1001
/etc/systemd/timesyncd.conf
[Time]
FallbackNTP=time.cloudflare.com#FallbackNTP=0.arch.pool.ntp.org 1.arch.pool.ntp.org 2.arch.pool.ntp.org 3.arch.pool.ntp.org
That seems a very aggressive response to a perfectly valid question in modern times. Google pays Mozilla tens of millions to be their default search provider. Companies use money to influence things to their benefit all the time.
edit: Another example was all the extensions that Kite bought out and had their service offering added to (which sent all your code back to Kite servers).
It was more of a question whether there is a conflict of interest; "shill" is a more loaded term than what was used. And the answer was actually a qualified yes, so there was at least a sliver of validity to the question.
I guess @dang changed it with good intentions, but he accidentally destroyed the meaning. "We wanted the best, you know the rest."
> I will block discussions here now, since I don't think we need the input from the script kiddie peanut gallery here.
Ohh my what a toxic open source community. I can't imagine working on a software project where the lead dev/maintainer says things like that to people.
Edit: I suppose with all the downvotes apparently lot's of people here think such responses from the leader of a open source project is acceptable behavior.
How about we cut them a little slack for occassionally being human?
The guy is paid for his work so I would have expect he would act more professional, the excuse that he works for free in his spare time does not apply.
I’m upset that he has done more than any other developer to break my machines, and he keeps getting more authority so screw things up.
PulseAudio was bad enough, but at least it only broke one subsystem. SystemD has unapologetically broken: background process management, time keeping, network resolution, pam authentication, screen saver session management, x11 startup, logging, and probably more.
I may be wrong, but you should be blaming the ones who made the _actual_ decision of replacing whichever init system, with systemd.
systemd was developed under Red Hat's umbrella. Nowadays, the vast majority of mainstream Linux distributions use it, and I doubt it was because Red Hat/Poettering pressure them to do so.
I think it may be a mistake to extrapolate his attitude to the scale of "open source community", even though it is also fair to say he is not the only one with this problem either.
Edit:
> Christ, what's next? You accuse us of controlling people's minds with vaccinations we get directly from Bill Gates? And that systemd uses 5G to spread CoV-2?
A joke occurrs to me. Systemd already does so much. It wouldn't surprise me if that were in there too!
I'm largely ambivalent as to whether or not his behaviour here was acceptable, but I am pretty sure he has received death threats and other types of abuse from systemd haters in the past, so his complete lack of patience at baseless accusations does not surprise me at all.
On a related note, while I still skim Slashdot's front page daily, I just can't stand to look at the comments anymore. I think the trolls, "bitter sysadmins" and bigots have largely frightened away everyone else. For example, if you just mention you're actually alright with Microsoft Windows, then you're accused of being a shill who's life goal is to make everyone else's life miserable.
But have you ever written a unit file? So much better than writing an init shell script. That apparently excuses any other issue with systemd for a lot of people.
Have you ever added a daemon to OpenBSD? There are better options.
I’ve looked at Unit files in a futile attempt to debug a startup failure. They seem worse (much less debuggable or transparent) than the old init system Linux had in the 90’s and worlds away from modern implementations, like OpenBSD’s.
When discussing privacy and Google a common refrain is "just don't use Google products then". But Google's DNS is used as the default for a key system daemon in the majority of Linux systems?
I'm going to file this under "voting with your wallet is bullshit".
I also hope that the systemd team is watching the Google DNS ToS like a hawk because: "We may modify the Terms or any portion to, for example, reflect changes to the law or changes to our APIs. You should look at the Terms regularly."