"Open Source projects are of course particularly welcome to use the pool in their default setup, but we ask that you get a vendor zone when using the pool as a default configuration."
How on earth did the modern linux distro become so dependant on software from this guy, when he clearly has no real world idea of things. No wonder people are jumping ship to the various BSDs!
Linus: You can say the word "systemd", It's not a four-letter word. Seven letters. Count them.
I have to say, I don't really get the hatred of systemd. I think it improves a lot on the state of init, and no, I don't see myself getting into that whole area.
Yeah, it may have a few odd corners here and there, and I'm sure you'll find things to despise. That happens in every project. I'm not a huge fan of the binary logging, for example. But that's just an example. I much prefer systemd's infrastructure for starting services over traditional init, and I think that's a much bigger design decision.
Yeah, I've had some personality issues with some of the maintainers, but that's about how you handle bug reports and accept blame (or not) for when things go wrong. If people thought that meant that I dislike systemd, I will have to disappoint you guys.
More like defending the init part of systemd, but still mentioning personality issues with certain people involved with the project.
Sadly most of these debates gloss over that systemd has long since grown past being just a init replacement.
It has sprouted tentacles all over Linux userspace, and all of them are tightly connected to systemd sitting as init-in-chief.
Thus updating some higher level part of userspace, say the Desktop Environment, may well result in your Linux install getting a init-ectomy via the dependencies chain.
Perhaps it's generational? Maybe Mr. Poettering is a talented individual who lacks some specific experiences/history which requires re-learning some lessons from developing linux?
This isn't just SystemD. you should ask rasterman sometime about his stint at RH Labs. There was a great interview with him and Havoc Pennington back in 1999 or 2000 where HP couldn't say a nice thing about the guy or his code, because he just didn't fit in with the redhat culture (he liked to wear formal wear to work - a subtle protest of mandatory office attire).
The entire Red Hat corporation has been like this since about the 5.2 release, when they removed "Redneck" as a system language option.
He has Red Hat's support. Anyway, no need to jump ship to the BSD clones. Just use Gentoo - OpenRC is a great init system: https://wiki.gentoo.org/wiki/OpenRC
Not so sure about that. Since "mainstream" Linux is now on systemd, how long can some of these alternative init systems remain viable?
I always preferred the BSDs on the server anyway, systemd was just the final nudge I needed to get me to run it on my dev box (it actually makes things simpler anyway, I was not relishing the thought of having completely different init systems on my dev box and servers).
Speaking as a sysadmin, I find something like launchd/upstart/systemd a ridiculously superior alternative to init scripts, in every way. So this is a good thing. (For various values of "systemd-like".)
Also speaking as a sysadmin, I've found "every way" to be inaccurate. Initscripts have their limitations, but the most glaring issues with them (lots of boilerplate, hard to write, etc.) have been resolved in BSD Land for quite a while, thanks to things like rc.subr.
systemd does have some nice features that I've come to appreciate on my GNU/Linux boxen, but I'm still not exactly sold when my OpenBSD boxen have a mostly-sane rc system not subject to most of the problems the systemd crowd claims are inherent to initscript-based systems.
true, I'm talking about fairly generic Ubuntu VMs out in the fog. But basically, the facilities available cover my common use cases very nicely on the occasions I actually have to write a startup script - I'm finding an upstart config vastly preferable to cobbling together an init shell script, and have yet (out of about 5-10 cases) had to resort to a shell script.
That's not a problem. Even a good thing and the BSDs will build one properly.
The problem is how systemd came to be (through political games indeed of merit) and that it's not just an init replacement but that it gets its grubby fingers everywhere in the OS and that it's turning Linux into a Windows-like binary blob mess.
There's a difference between discussion regarding /a/ more in-depth system framework and discussion regarding a specific system framework. One of the constant things written about in these threads though is that they /don't/ want something "systemd-like" because it is such an intrusive, obstinate framework. I see some good ideas coming from the systemd framework, however, its consistent choice of poor defaults and byzantine structure leave me desiring something of a bit more lucid vision.
They are? That's interesting. Please provide details. What systemd-like systems are (to start with) the OpenBSD, DragonFly BSD, MirOS BSD, NetBSD, FreeBSD/PC-BSD, and Debian kFreeBSD people actively working on?
Uh, the entire presentation is about the need for a systemd-like system, and how the existing init system is not sufficient.
Did you listen to the presentation?
Look, snark aside, nobody can sanely suggest the existing init systems are sufficient in 2015+. New ideas present in systemd and launchd are exactly what people have desired for a long time. Maybe systemd doesn't float your particular boat, but that doesn't mean the old init system is superior.
I'd go 100% OpenBSD if it wasn't for my deep-seated love affair with GNU and it's concepts (if not the figurehead). I'm starting to see the GNU boat being sabotaged, though, so I might be forced to abandon my compromised vessel and build a new 3-clause ship.
Gentoo is honestly the best of both worlds; linux compatibility, tons of applications, can be rebuilt from source, and a version of ports that doesn't suck. Their steadfast refusal to adopt systemd is pretty much icing on the cake at that point.
As of late i have come to loath the user/developer distinction.
Any user is a potential developer given time and access to tools.
But as of late there has been more and more an attitude that developers has to go out of their way to protect users from themselves (user).
Thus you get the likes of ChromeOS where the default setup is highly restrictive. And flipping the "developer" switch either way wipes the device clean.
Thus there is a very big mental step to go "developer", rather than start out small with some scripts (thus getting familiar with code logic) and perhaps move on from there.
Then, I guess, the main Maintainer of pool.ntp.org, who explicitely stated¹ that he agrees with Lennart Poetterings reasoning also hasn't read that?
It is a really poor signal how much crap gets flung at the systemd people for this bugreport that is
a) not even a day old
b) entirely inconsequential for anyone but the systemd devs and maybe Google
c) is apparently completely misunderstood and/or misrepresented
In the response you link, "abh" agreed about a specific point in "Poettering's reasoning":
Lennarts reasons for not using
*.systemd.pool.ntp.org ("systemd isn't a
distribution") makes sense to me.
This is very different than agreeing that hard-coding a set of NTP servers into the code base is the way to go. To this point, "abh" wrote:
I'd suggest having no default NTP servers in
the systemd code...
Which is what many others have requested as well. If this were an isolated decision, it would be a different thing. But it is not, as several others in this thread have provided supporting evidence[1].
I am sorry if I was unclear in that. My comment (and similar comments in other threads) directly referred to criticism of Lennart for deciding that he doesn't want a vendor zone for systemd.
In regards to the DNS server comment: I said it elsewhere before, this is completely unrelated. You may disagree with the decision from a political viewpoint and that is totally fine. But from a technical viewpoint the usage of the Google DNS Servers is completely reasonable.
He's just being stubborn. The vendor registration requirement is really simple and entirely exists to give a way to control the situation of an NTP client goes crazy. I'm a little sympathetic to his argument that the distribution vendors like Red Hat should register instead. But if that's the goal then systemd needs to provide no default in the stock code and force the distributor to configure it.
From the Github comment you are referencing, dannyperson states, "When NTP Pool warns that pool.ntp.org should not be a default, this warning is directed to vendors, not open source projects." but the clause from http://www.pool.ntp.org/en/vendors.html IS talking about Open Source Projects. The heading is "Open source projects".
What is the difference between a default setup and a default configuration?
It isn't ambiguous at all.
If you're publishing something, whether it's open and free or commercial you're a vendor so you have to follow the policy ntp.org set-up for such entities.
That person on github is misunderstanding both Poettering and the ntp.org's policy.
They can use "the pool", i.e. the collection of NTP servers.
They could (register a "vendor zone") and use "[0-3].systemd.pool.ntp.org". They can, technically, even use "[0-3].pool.ntp.org", but the NTP Pool Project is saying they cannot use [the specific hostname] "pool.ntp.org".
That last part is what people are apparently not understanding.
Also, OpenBSD blatantly ignores it and uses "pool.ntp.org" anyways.
In essence open source projects are vendors as far as ntp.org is concerned and you can use their service but have to obtain a vendor zone for that. The formulations are indeed not as clear as they could be but after reading the ntp.org page a couple of times there isn't really any other meaningful way to parse it.
The implication that systemd is not a product strikes me as odd given that a core aspect of systemd's marketing and leverage was precisely that it supplied a ton of policy decisions as to how distributions should operate, as opposed to simply mechanism.
Lennart is controversial, but he usually provides more-or-less decent reasons for technical trade-offs. Here though? Complete copout.
You are comparing apples to oranges. systemd takes policy decisions but it doesn't provide infrastructure and a set of ntp servers is infrastructure. Likewise, a web server encodes a lot policies (most of which aren't set in stone by any standard) on how http requests should be handled but it doesn't come with a default cdn.
...How does it not? That's the point of systemd: provide a GNU/Linux middleware with lots of policy decisions on the structure of distros to supposedly bring integration and uniformity benefits.
The fact that it's core infrastructure but heavily delves outside of mechanism is what makes it so controversial.
I meant physical server infrastructure. Not the allegorical infrastructure formed by Linux packages communicating. Yes, I know the infrastructure word is horribly overloaded.
He has added further clarification which makes sense to me. Just like other pieces of NTP clients don't register for a vendor name in the pool (there's no chrony.pool.ntp.org), systems also doesn't need to.
However, they should IMHO still get rid of the Google default and instead blow up on compilation or start up if the NTP server is not set.
Blowing up is better than silently running with wrong data, much less with unauthorized use of resources.
It appears that LP has an incomplete grasp of English (no insult, it is not his native language) and is simply misunderstanding both NTP.org and Google's instructions regarding how to use their systems. NTP welcomes usage, Google does not, and LP misunderstood them both backwards.
I speak the same native language as Lennart and apparently I have the same misunderstandings of the language. I agree with his reading, that NTP welcomes usage (as a default in your open source project) iff you apply as a vendor. Can you point me to a better clarification on why this reading is wrong?
Lennart said in the linked thread that systemd was not allowed to use pool.
> Its up to the distros to register an ntp pool product. systemd is not a product. Its just some toolset people can build products from. We cannot use the ntp pool hence. If the googl time servers
In this post he says that systemd is not a product. In the context of whether they're allowed to use pool.ntp.org systemd is a product.
> Coreos should register its own product with the pool and use that. Systemd upstream is not a product, we shouldnt register it as one. distributions such as fedora have their own pool, debian has, ubuntu ha, arch hass. if downstream dont set the correct pool for their product then thats something to fix downstream.
Here he repeats the line that pools is forbidden:
> the ntp pool made very clear we cannot use them. As i read what is written above google just says the servers are crap but doesnt explicitly deny us to use them. Which is why id like to leave them in place because they are at least googd enough for testing purposes.
And here:
> We are an open source project, with no legal entity behind it and as such we are not the ones who can take responsibilty and not the ones who register as a vendor at the pool. [...] but right now the ntp pool is nothing we can use since the non-vendored pool is explicitly forbiddrn for us and the vendored pools dont apply to us since we arent a vendor.
He makes the claim several times in that thread.
But even if we accept that pools should not be used: that doesn't mean you can use Google's time servers. Google have asked systemd to stop using them and provided strong reasons.
That doesn't look at all like a language barrier problem. That looks like Lennart understood perfectly well, that usage of the pool is conditional on registering a vendor pool and that he has perfectly sound reasons not wanting a systemd vendor pool. And note, that the main Maintener of the NTP pool agreed with his reasoning.
I also somewhat agree with Lennart, that the reasons Google give don't really apply.
However, I also agree, that they shouldn't be used nevertheless :) Luckily, as I understand it, there seems to be somewhat of a concensus to not put a default and instead have fail the build if nothing was ./configure'd.
They're Google's servers. If they aren't meant for your use they can ask you to stop using them without any reason at all. The fact that they provided reasons at all is simply to inform people how they're systems are not going to operate normally.
To me it reads like a soft rule, especially amenable to something as big as systemd. Any decent project leader honestly looking for a solution in such a situation, would reach out to ntp.org and explain the problem. If he cared, of course.
> ...to provide a correction to someone saying pools can't be used.
Yes. Someone claimed (correctly), that *.pool.ntp.org can't be used. abh ammended that by saying, that however, a vendor zone can be used. I don't think anyone ever doubted that point. Notably, Lennart seemed to be aware of that point in his earlier mail.
> That's something that LP appears to have considered. I'm not sure why that isn't done.
The reason given before was, that tests and similar need some values. However, a PR implementing exactly this solution is currently in discussion (and afaik Lennart has not respondet to that yet). I would wait until the dust is settled on that, before I continue this discussion. The bug report (which is afaik the first time anyone has indicated that the Google servers shouldn't be used for this) is half a day old, that's basically nothing in FOSS-development (especially for a non-critical issue like this). Give it some time, if this isn't solved in a week, that may be a more appropriate time for pointing fingers and being unpatient.
I think the problem is not a language problem but rather both a set-theoretic and a technical issue specific to how NTP works.
Set-theoretic: what exactly is meant by "the pool"?
Is it: a) the set of all NTP servers on the Internet which cooperate with those on .pool.ntp.org, b) the subset of NTP servers with hostnames [0-9]+.pool.ntp.org, c) the subset of NTP servers with (one or more particular) "vendor" subdomains under .pool.ntp.org, d) a particular intersection or union of any of these sets?
Technical: Does the perceived restriction on who may or may not use "the pool" apply to NTP servers which wish to participate in "the pool", or to NTP clients which simply wish to synchronize their clocks?
I've found several documents, from ntp.org as well as from other sources, with varying levels of vagueness and contradictory language.
Why are people trying to parse written language on a website? Why doesn't someone at Red Hat just pick up the phone and call someone at the Network Time Foundation and ask them what they need to do in order to use ntp.org? Or call someone at Google and talk to them?
I know that tech companies don't like to take calls from random customers, but we're talking about a major Linux project sponsored by Red Hat. Someone for sure knows someone who can get real answers from a human.
"Someone at Google" has created GitHub issue (that is discussed in this thread), asking systemd project to stop using Google servers. No need for a call here.
I think a) the snark is unnecessary and b) you are mistaking disagreement with ignorance. From what I read in that issue, he did understand the point pretty well (from a technical standpoint), he just disagrees with the proposed solution (from a mainly political standpoint). You should be able to disagree with people without claiming malice or ignorance.
The former poster didn't say Poettering was ignorant nor malicious.
"missing the point" can equally be attributed to someone who disagrees (ie he disagreed that systemd is a vendor while missing pool.ntp.org's point that open source project's are welcome to register vendor IDs without themselves being vendors.
That doesn't mean that Poettering is ignorant nor malicious. Just that his political standpoint isn't relevant (in the OPs opinion) to the point that the NTP pool maintainers make about the usage of their time servers.
Yea that was kind of crazy. Especially with a really straight forward fix already there. Now CoreOS is jumping in to possibly get the vendor registration for systemd so they can use pool.ntp.org correctly.
> Is there a good reason for systemd to not use those pool servers?
Because they forbid using the non-vendored pools as defaults and Lennart doesn't want systemd to be a vendor or product.
> What happens if distros don't change the default away from .systemd.pool.ntp.org?
Lennarts argument is not, that this might break, but that he doesn't want .systemd.pool.ntp.org to exist, because that would imply some kind of responsibility of systemd.
I find it utterly reasonable, to avoid being made responsible for something, that is essentially a test-domain. Imagine, for example, that some domain server in .systemd.ntp.org would stop responding (for pretty much any* reason, including a cut cable in someones basement). Imagine some User™ gets an error message, saying, that 0.systemd.ntp.org wasn't reachable, googles systemd and creates bugreports against systemd for a broken ntp-server that a) isn't run by the systemd-folks, b) was never supposed to be used by anything else than the systemd test-suite, c) was registered by some third-party (CoreOS) and d) not one of the systemd-maintainers wanted.
I find it a reasonable position, that he wants to avoid such a situation.
So instead, he makes it google's problem. This is an even more unreasonable and irresponsible decision. If he doesn't feel his project has the manpower to handle support requests for default servers, then he shouldn't list any default servers.
Lennart has stated very clearly, that if someone where to propose some other publicly available server, that he would be happy to put that down instead.
Also note, that the reporter didn't write "don't use this, we can't handle the load", but "don't use this, weird stuff will happen to your server".
But yes, I agree, Googles NTP servers should be removed as a default. But a vendor pool also isn't a solution apparently. Luckily, there are people actively working on a PR to simply have no default. So everyone should just calm down and give the issue a while to resolve itself, instead of venting here on HN.
Except that the only time that vendor pool would be used outside of tests is when folks build systemd from source on their own. Each GNU/Linux distro overrides those defaults when building/packaging systemd, so the vast majority of users would be entirely unaffected.
In other words, the people who would run into the error you propose are the same people who know fully well what systemd is and is not (and - I'd hope - would know how to read the rest of that hostname and surmise that the issue is with an NTP pool and not systemd itself).
That doesn't mean he wasn't still dismissive. For one not to be considered "dismissive", one would have at least considered anothers arguments - even if the one sticks to his original conclusion. Poettering was anything but receptive to other opinions - he's already decided his method was the best regardless of the T&C's of the services he's using nor the feedback from the community.
But this has been pretty much his approach to systemd from the very start; which is why it's polarised the community so much.
> Even if the google servers dont provide time that
> is correct, its good enough to run testcases again.
> Products however of course shouldnt use it.
So, it seems that he wants to run out-of-the-box with some timeservers so that the developer/compile/testing machine doesn't have to specify them manually for tests. On the other hand he wants to require vendors to add a custom configuration so that they abide by the rules of, e.g. pool.ntp.org, by registering a vendor pool and configure systemd.
The only sane approach for me seems to be to discover the correct ntp-server in the scripts running the testcases, and leave the ntp-client in systemd unconfigured and untested if that's not possible.
Forcing developers to have a properly configured system is a much saner approach, because it affects way less people than potentially millions of users to whom a broken/wrong timesyncd.conf leaks caused by some snafu during configuration of the systemd timesyncd when packaging.
I love how in one sentence he accuses Poettering of being "convinced he has all the answers for everyone", and in another he states anyone who approves of systemd must be "naive or lazy or just plain clueless developers" lured by "the promise of making their lives easier".
No, absolutely not. Defaults that can cause subtle errors are worse than a program abort with an error message telling you to fill in a configuration value. Especially after reminding that Google servers run "a non standard concept of time" (what does that even mean?). It is not a reasonable default by any stretch of the imagination.
> Google servers run "a non standard concept of time" (what does that even mean?).
I know that one way they do this is through using what they call a leap smear instead of a leap second. Yesterday, instead of having 11:59:59 twice, they evenly distributed out the second over the course of the day.
I mean, technically speaking (unless there's an RFC, ISO, or ANSI that I'm unfamiliar with), having the same time twice is also "non-standard." The most correct course of action would be to have an 11:59:60, as per the actual leap-second standard.
The fact that basically no computer system in the world allows for a 61-second minute is just a failing in almost all time libraries to adhere to the standard.
(This is a fancy way of saying "Time is a quagmire and writing code to properly handle time is an exercise in optimizing ulcer generation" ;) )
On Unix, (OSX and I believe Linux, too) the man page for the tm structure specifies that tm_sec ranges from 0-60, so it does support 61 second minutes. I think this has been the case for a while. I recall noticing this years ago.
> I mean, technically speaking (unless there's an RFC, ISO, or ANSI that I'm unfamiliar with), having the same time twice is also "non-standard." The most correct course of action would be to have an 11:59:60, as per the actual leap-second standard.
I believe GP is incorrect (or rather, the overall point that most NTP servers followed the standard and Google's didn't is correct) and most NTP servers did have 11:59:60 as per the standard.
Leap seconds only date back to 1972. Computer systems, and especially the concept of time in computer systems, are older than that. Time smearing does appear to me to be the best way to compromise between the two worlds. Adopting a 61-second minute full out isn't making any compromises, and not only will it confuse computer systems (including those outside your control that you interoperate with, even if you somehow manage to get yours working perfectly with it), it will confuse PEOPLE.
Even if you waved a magic wand and made all computer systems in the world compatible with 61-second minutes, it'd still cause problems because people aren't going to know what to do with it. Imagine what happens when a non-technically-savvy person comes across a time that looks like 23:59:60.5 on something at their work. They'll immediately think that's some kind of error.
Hmm..what would happen if you were to attempt to write that time to an RTC in that window? I suppose some RTC parts might be designed to reject those writes. Does the RTC interface logic in the OS just not care about leap seconds and therefore misinterprets the time? Or does it need some sort of special correction for this case?
The OA lists some practical issues including a 400ms difference from UT lasting for some days on a regular basis. Depending on the use case for the server being configured, that could be important.
In a wider context have a look at an observational astronomy textbook for the chapter on time systems when you can spare a couple of hours. Its fascinating.
As has been noted, this is for timesyncd, usage of which is entirely optional. Additionally, as boneheaded as it is to use ntp servers from a single corporate entity when ntp.org exists, you can address this by setting your own ntp servers in the timesyncd conf file.
FWIW, I really like timesyncd being there out of the box with systemd. It is exactly what I want, and nothing more, about 99% of the time when dealing with ntp synchronization.
EDIT:
Let me add that if you want to specify ntp.org servers right now you can add or edit the following stanza to your /etc/systemd/timesyncd.conf file:
The issue is not that systemd is using NTP servers from a single corporate entity, it's that timeX.google.com are not meant to be public NTP servers: they do not provide UTC time they provide "Google time" and this difference will cause problems unless you intentionally want "Google time" and know what you're doing.
Another example of a defective software product with an egotistical maniac at the helm (Mark Shuttleworth)?
> What exactly are these fatal Ubuntu flaws?
Unity? Upstart? Mir? The Amazon Shopping lens? A general failure to listen to the very community Canonical markets as a selling point? A terminal case of Not-Invented-Here syndrome? An inability to prevent any Ubuntu-derived device (Ubuntu for Android, Ubuntu TV, and Ubuntu's mobile edition thus far) from being more-or-less commercial flops stuck permanently in development hell until they become vaporware?
For one, I'd argue that reasonable defaults mean that the defaults are not hardcoded into the ntp client, and don't point to some random company's servers. Additionally, given the many different places that configuration files could be located for this client, it makes debugging issues much more difficult, as you now have three directories and one file to look into if something starts going haywire. This is pretty much the opposite of well-designed.
That it's an optional and possibly little-used feature, makes it even more likely that a distro will forget to change the default, and that it will go unnoticed for a while, and then an end-user (end-sysadmin?) decides to use the feature... and is using NTP servers that _everyone_ involved agrees should not be used in production, and worse, the reasons they should not be used will not immediately apparent as soon as you use them, but are subtle and may result in confusing and difficult to diagnose problems in hard to predict ways.
I think this is why it offends some people's sensibilities so much to go down this route, you are leaving a very subtle and confusing hole for someone to fall into.
You only need to apply this "fix" if you are compiling systemd + timesyncd yourself and not using a distribution as source. Debian for example supply a different timesyncd.conf and include their own ntp servers.
seriously? this is as bad as leaving the default configuration path on a program as "C:\test.ini" and then telling people 'shut up and pass this and that parameter to change it, the problem is on you'
No, it is saying "don't build systemd from source unconfigured and then run it in production", which is an entirely reasonable point to make. systemd is meant to be, by self-description, "a toolbox to build an operating system", not "something you install and expect it to work". Distributions are expected to configure reasonable defaults amongst other configuration.
Your distribution will already have set different defaults. Various of the major distributions have done so. Lennart also said he'd accept a patch to add a big warning in configure if you fail to provide these defaults.
Linking to a bugreport with an ongoing discussion is a bit pointless IMO. It's still being discussed!
Any binary default is wrong and broken, period. It's especially wrong and broken to set that binary default to a server you have no control over. It's triply wrong and broken to set that binary default to a server you have no control over whose maintainer has asked that you not use in this way. At the very least, the systemd team should have the decency to document what this default is so that administrators trying to hunt down suspicious and/or unusual activity have some starting point to go from.
The defaults on my installation are *.debian.pool.ntp.org. Can you give me an example of an installation with less sensible defaults?
edit: Ah, I think I now know where the misunderstanding lies. My "if you don't" refers to "if you don't build it from source", not to "if you don't ./configure it".
> I really like timesyncd being there out of the box with systemd.
Does it still "spam" the journal with drift logs ? That might cause some extra wear on systems running on flash storage and it made me install ntpd instead.
Honestly, I think StoneCypher is spot-on with their comment on the thread.
"if you don't take this down, google will just remove the dns, and then you lose the ability to do this in a controlled way"
Remove the DNS or start filtering by IP address. In either case, the default is using a service in a way that isn't condoned by the service provider, and that's just begging for trouble at a time not convenient to the software maintainer in the future.
I disagree, nothing in the issues text says they are forbidden to use the server. It's not a problem for Google, it's a problem for distributions which don't change the default.
If Google removed the DNS entry they'd have to reconfigure all of their own servers, too. Not very probable.
"If Google removed the DNS entry they'd have to reconfigure all of their own servers, too. Not very probable."
That sounds suspiciously like you're saying "I'm going to keep telling everyone to use your service because it's too expensive for you to stop me or them."
I'm not sure it says anything about the other parties involved, but your willingness to knowingly externalize costs onto others says quite a bit about you
It's also almost certainly a bad assumption to make about Google, given that (a) they own the servers (so re-rigging them to just whitelist IPs is entirely possible) and (b) they are a search engine company (so finding the places where they used those servers to swap out the names is entirely possible ;) ).
Google's DNS servers are a product meant for public use, i.e. this use. I think it is entirely reasonable to not run your own public DNS servers as an Open Source software and instead use a well-maintained already existing one that has an excellent track-record of availability and low latency.
That in itself I'm not sure I have an issue with 100%...
It is the only DNS servers that are guaranteed to have accurate results and respond quickly. The only time I use local DNS inside of my LAN is when I need local LAN entries.
The issue I have is it not reading /etc/resolv.conf, but if resolv.conf isn't setup or setup properly, falling back to Google's is a good solution.
Also, at my company (we do DDoS mitigated dedicated servers), we deploy servers with Google's set by default: we have access to Google over Equinix IX, going out to 8.8.8.8 responds as fast or faster than it does with bind, dnsmasq, and unbound, even when the entry is clearly already cached, with the DNS cache daemon running on a server in the same rack; and for uncached, Google is usually much faster.
You shouldn't be taking electronics in or out of China, to be honest. Too much evidence that China is successfully MITMing SSL/TLS connections and physically tampering with electronics.
The issue is that if no configuration is available/found/readable things doesn't stop working with a sensible/expected error - but rather enters a new and unexpected (error) state. Error if you didn't want to use Google's resolvers.
Even if the google servers dont provide time that is correct, its good enough to run testcases again. Products however of course shouldnt use it.
the ntp pool made very clear we cannot use them. As i read what is written above google just says the servers are crap but doesnt explicitly deny us to use them. Which is why id like to leave them in place because they are at least googd enough for testing purposes.
Id be willing to take a patch that adds a big warning to configure if the default ntp server to use is not set when invoking configure. People who ignore that warning are then on their own.
> Open Source projects are of course particularly welcome to use the pool in their default setup, but we ask that you get a vendor zone when using the pool as a default configuration.
systemd are perfectly entitled to use ntp pool as defaults.
I basically read that as "this isn't our responsibility so we don't have to do anything" which is sort-of true.
I think if they didn't configure ANYTHING by default, well, in that case the distro HAS to figure something out or else it won't work. OK, that's legit.
I think if they wanted to pick an officially blessed config option then they should go through the necessary steps to have it be official and blessed. Whatever that means.
But this seems to be the worst of both worlds; we're going to pick something for you so it'll work without intervention, but then we'll tell you that you're idiots for not fixing a thing which isn't obviously broken to begin with.
Ship it broken, or ship it working but don't ship it working poorly and then tell people it's their own fault.
It's simpler than that. Knowingly hardcoding someone else's timeservers without even speaking with the operator of said timeservers is Internet hostility, particularly when your project is popular enough to be deployed on potentially millions of machines. D-Link hardcoded PHK's timeserver many years ago:
The best part about the Netgear one was it hit upwards of a quarter million packets per second and actively resisted mitigation by admins. Seriously, don't hardcode. Ever.
Companies won't learn until the time servers they shipped on hundreds of thousands of products stop working from one day to the next because the operator of the server didn't feel like offering them a free service.
I seem to recall reading about a French made program that had hardcoded the Linux source FTP server. Apparently it was used as part of a bandwidth test. And it got so popular that the server admins had to ban the French IP range...
> Distributions usually have a full NTP client installed by default, why
> should GNOME try to enable/disable an SNTP client that happens to be
> distributed with systemd?
Well, "usually" means right *now*, little else.
And:
> > This is really about being a *client*, and
> > not trying to outsmart servers.
>
> Outsmart servers how exactly?
By not trusting them...
To me, this provides insight into Poettering's mindset of systemd creating a fool's paradise[1] regarding coexistence with anything outside of its walled garden[2]. For an example supporting this, the not-too-subtle hint of system clients outside the systemd ecosphere (NTP in this quote) being slated for elimination in distributions should be sufficient.
BTW, love your use of the phrase "interesting reasoning".
Poettering's projects has basically turned into lightning rods for a group of devs that want Linux to have a one true way to do everything, as they see the bazaar way of doing things as a failure and something that is holding Linux back from wider adoption.
You know it, i know it, but as best i can tell they don't see it as "wide enough".
Damn it, GregKH has basically admitted that one big reason for pushing kdbus is that the automobile industry wants to adopt embedded Linux as a replacement for QNX.
And for some oddball reason they have adopted dbus as their replacement for whatever QNX RPC they used before. Except that said QNX RPC was higher performing than current dbus, in part because it was in kernel...
He hasn't explained why they chose Google in that thread, yet.
Moreover, his argument that it isn't their responsibility became invalid when they set a default preference. Same applies if they change it to ntp.org. That project, however, is explicitly intended for such purpose and is generally accepted by the majority.
As someone on the issue notes:
You cannot use pool.ntp.org either.. "You must absolutely not use the default pool.ntp.org zone names as the default configuration in your application or appliance." that's according to the pool's website...
Yes, but you can use [0-3].$vendor.pool.ntp.org. You simply request a "vendor zone" once, beforehand, and use it all you want. Apparently Lennart is opposed to that part of the process, however.
Actually my comment is correct. You can't use the standard public time servers. Systemd has expressed that they do not want to apply for a vendor pool, for good or for ill.
Which is a fair point, probably one of the few I agree with in the response. Systemd is just a software component. When you install ntpd and similar you'll find it almost always comes configured with a vendor pool for the distribution e.g. 0.ubuntu.pool.ntp.org
The same should be applying for systemd. That said, they really shouldn't be setting defaults like this, especially not broken ones.
> They are allowed to use pool, they just have to apply to use them.
Which has unclear (non-technical) implications. Which Lennart Poettering doesn't want to tolerate. Which I would consider a valid opinion.
> The linked thread has someone from Google telling systemd that systemd should stop using Google's time servers.
For technical reasons, that Lennart Poettering doesn't agree with (i.e. these defaults won't be used in production and if you use an unconfigured self-build of systemd in production, it's your own fault).
This doesn't address why not just leave it unconfigured.
He addressed that in another post. Basically from a testing and development POV he believes it's important to ship with some default that at least works out of the box, even if the default is completely unsuitable for production.
I think the worst issue here is that the result will be on the surface correct, unlike some other test settings that will show that the protocol/code works but that the settings needs to be changed to be useful.
Something akin to the blinking 0:00, that shows the time circuit is powered up but with no time set.
That's irrelevant, however. If systemd is going to ship with a default nameserver then it should be using the correct and public NTP pool, rather than servers from a random company who hasn't made any commitment to providing reliable UTC time to a public audience.
And if it's using a service like the NTP pool, it needs to have a vendor prefix. Not because this has anything at all to do with the notion of being a "distribution", but because the prefix provides a means for the pool to identify traffic originating from default-configured systemd instances, and cut it off if it suddenly starts to behave in a way that would degrade the rest of the network.
Or they can simply ship with no default. But you can't have it both ways, both setting a default server and claiming not to be a vendor in every sense meaningful to an NTP server operator.
The settings is according to the developers only for testing purposes, like using ipsum lorem or example.com.
The choices being debated seems are to have no settings by default, require that people who want to run test suites configures the software before testing, register a "vendor pool" for this purpose, find a better ntp server than google, or do nothing.
Except that isum lorem and example.com will both stand out as "working, but nonsense". If whatever time server they aimed the code at would constantly resolve to a date in the 1700s or something, it would be blatantly clear that setting has to be changed. But as it stands, it will give a correct response out of the box and thus give a false sense of nothing more needed being done.
That is not the case, you misread that response. What he rather is saying is:
a)
> Lennarts reasons for not using *.systemd.pool.ntp.org ("systemd isn't a distribution") makes sense to me.
b)
> If you kept reading you'd learn about getting a "vendor pool" setup specifically for your product/distribution.
i.e. he corrects, that pool.ntp.org can not be used, without applying for a vendor pool but that Lennarts reason for not doing that makes sense to him.
>The Network Time Protocol daemon (ntpd) is an operating system program that maintains the system time in synchronization with time servers using the Network Time Protocol (NTP).
> But quite frankly, we added timesyncd because we believe that installing
a full DNS server like ntpd/chrony on all client machines is absolute
overkill
Nobody else mentioned it because it is incredibly obvious that it's a typo or slip. Debate the technical merits, don't nitpick stuff that's completely inconsequential.
Somewhat off topic, but in the referenced Google blog describing their leap smearing technique, they say that their correction factor is "lie(t) = (1.0 - cos(pi * t / w)) / 2.0" (where w is the length of time over which they are smearing). Does anyone know why they do not just do a linear correction?
I'm guessing: that function has a continuous derivative. Simply running the clock uniformly faster during the interval would have a discontinuous derivative.
If it were just linear like AWS (https://news.ycombinator.com/item?id=9567761), then an NTP client pointed to a smearing NTP server will have an immediate 12ppm drift discontinuity (NTP continually models the hardware clock as a fast or slow clock with a linear drift from true time). Perhaps the NTP client’s control algorithm will bounce around as it tries to figure out the correct hardware clock drift, and perhaps this bounce is smoother when you use cos over a day. But I haven’t studied the NTP algorithm enough to tell for sure.
Edit: from other comments here, it looks like Google also uses a linear smear now (a linear drift over 20 hours is 14ppm).
My guess is they wanted time to deviate less at the start of the smear window, instead of deviating equally at all points during the window. But perhaps it turned out not to be an issue.
My guess is that they wanted to avoid a discontinuity in the time's derivative. At t=0 and t=w, lie'(t)=0, so the clock is smoothly transitioned into and out of a faster rate.
"During a 20-hour “smear window” centered on the leap second, we slightly slow all our servers’ system clocks (by approximately 14 parts per million). At the end of the smear window, the entire leap second has been added, and we are back in sync with civil time. (This method is a little simpler than the leap second handling we posted back in 2011. The outcome is the same: no time discontinuities.)"
I can see how that sounds like a linear adjustment, but you missed the key explanation.
Going back two sentences before the part you quoted, we find:
> We have a clever way of handling leap seconds that we posted [1] about back in 2011. Instead of repeating a second, we “smear” away the extra second. During a 20-hour “smear window” centered on the leap second...
> ...modulating this “lie” over a time window w before midnight:
> lie(t) = (1.0 - cos(pi * t / w)) / 2.0
That's the nonlinear smear that we [2] are referring to.
[2] see surrounding comments here on YC that agree that it is nonlinear.
Note that this is extremely similar to the various kinds of data weighting "windows" (Hamming etc.) that are necessarily used with the Fast Fourier Transform.
(Except that with those it is often undesirable for the window edges to go all the way to zero, and yet that is exactly what is desired for the time adjustment)
And in both, it is for what amounts to the same mathematical issues: to avoid discontinuities, in either the function or its derivatives, that give rise to undesirable artifacts.
> And in both, it is for what amounts to the same
> mathematical issues: to avoid discontinuities, in
> either the function or its derivatives, that give
> rise to undesirable artifacts.
My guess is that with the cos/sin modulation the time can be precisely followed by a stock ntp client that doesn't know anything about "google time" and needs some time to ramp up/down the observed clock drift, as you said: Because the derivative doesn't jump.
But if you deploy special ntp servers that know about your exact method of leap-second handling (as, I suppose, google does on all servers which are sensitive to sub-second time offsets) you don't need a steady derivative: you just set adjtimex(freq-14PPM) at -10 hours before the leap second and adjtimex(freq+14PPM) at the end. And this will lead to even tighter timing, as the percieved frequency offset (from the point of view of an NTP daemon doing time interval measurements relative to a server) will disappear completely. So maybe that's why they now use a simpler method?
The other explanation I could think of for introducing this simpler handling is that google may have switched to PTP on their networks: As the measurement precision is much higher (jitter much lower) than UDP based ntp even a simple NTP client will be able to quickly and precisely follow the discontinuous clock drift at the beginning and end of the smearing period.
Just for illustration purposes, here's aplot of the "google lie" clock offset going from 0...1 (cos...), and the modulation of the clock frequency (sin):
Lennart is a skilled dev with some excellent ideas and some controversial ideas. The stuff he designs eventually ends up being picked by distributions and defaulted.
And for creating software that simplifies the lives of distros and gets picked up, he is "not well regarded" as you say. But don't mince your words, people fucking hate him for it. They don't even know him yet they despise every fiber of his being. Have you seen some of the hate that goes on even here?
And everything he does or writes is getting analyzed like a teenager analyzes every character in his girlfriend's texts because "oh god I'm so in love". Look at this issue. He mis-presses send on a github comment and immediately you have 10 comments without even waiting for an explanation, calling the guy "absurd and stupid".
He's not the only one getting treated like that by the community. One day, one of those devs will kill themself, and people will rush him to talk further about them like they know them. Exactly like what happened to Aaron.
Yeah I sure would love to get treated like that for working full time on improving foss. /s
Edit: It's fucking appalling how I get immediately downvoted, without any reply, just for defending the guy as a human being. Really proves my point.
As someone who disagrees with but nonetheless respects LP, you seem to misrepresent his character. He isn't as sensitive or shallow as you portray him, he's a provocateur and he embraces it to his leverage. He's really skilled at using technical details while mixing them in with lies by omission, subtle distortions and personal opinion to create some formidably sly arguments that an inexperienced observer takes for granted. Skilled programmer and speaker.
That he makes distribution maintainers' lives easier is mostly true. This isn't really an argument in favor of systemd, though. The things that distro maintainers did with sysvinit for so long has been anathema to any good design principles, so just about anything is an improvement in comparison. Yet even still practical systemd integrations are quite flaky and unoptimized (https://wiki.freedesktop.org/www/Software/systemd/Optimizati...), as there are no magic bullets and systemd being an informal spec is breeding ground for lots of cargo cult wisdom.
I would like to see the face of a non-technical police officer that get to handle the reports of death threats. A person who develops and gives away software that makes people lives easier for free is so provocative that harassment, death threats and general hatred is directed at him. The actions of those people is then defended by a community because the developed software do not follow good design principles or is considered flaky and unoptimized.
That is a desperate non-sequitur. It might be easier to choose the worst person you can think of to reply to, but it's silly to pretend like this comment is a response to the comment above.
Lennart is very good at the political wrangling required to get code into distros and make it an unavoidable part of using Linux. His actual code quality is not so great. PulseAudio is still a mess a decade on, and I gave up even trying to figure out why it breaks because it's a nightmare of misleading variable names and uncommented code. I finally abandoned hope when I tracked down a crash, found that a patch that was literally unfinished and labelled as such had made it into a release before being backed out, realised they don't do stable releases and the next upstream release with the fix would have other major changes with new bugs, and eventually discovered that reverting it didn't even fix the problem. The underlying code was simply broken and there was no way to see how it was ever meant to have worked in the first place, because it was completely uncommented.
systemd seems to have slightly better code, probably because it has kernel developers on the team, but like PulseAudio there are no stable releases. It's up to individual distros to try and turn the stream of upstream releases into something that works. I think this is a Red Hat thing - they're happy to develop new features collaboratively and in the open, but actually turning software into stable, reliable working releases is their secret sauce that people pay them big dollars for. They're also the only major distro that doesn't co-operate with the upstream Linux kernel's process for stable and long-term releases.
I think your point about code quality is very poorly expressed, but I'll disregard that for now, I wanted to address this:
> I think this is a Red Hat thing - they're happy to develop new features collaboratively and in the open, but actually turning software into stable, reliable working releases is their secret sauce that people pay them big dollars for.
I'm not sure what you're talking about. Are you saying RH magically makes stuff stable only on their distro, and doesn't fix bugs in master? Because that's not only BS, it's not permitted by the software licenses they themselves choose.
And regardless, yeah, making stable releases is not an obligation. Never have been, never will be. It's a nice thing to do, and often it's useful, but still optional. Web Browsers don't do stable releases (in the LTS sense) anymore either.
> Look at this issue. He mis-presses send on a github comment and immediately you have 10 comments without even waiting for an explanation, calling the guy "absurd and stupid".
Why should people have to assume that he "mispressed" send? Isn't it more likely people would take his comment at face value and respond accordingly? If there is a problem with something he's said, that's on him for not being more concise and clear about his point.
> He's not the only one getting treated like that by the community. One day, one of those devs will kill themself, and people will rush him to talk further about them like they know them. Exactly like what happened to Aaron.
This is so overly dramatic and completely unrepresentative of what happened with Aaron Swartz. The fact you threw his name in is borderline offensive, seeing how with Aaron Swartz he was a victim of perverted justice, not abusive comments on Github. You're just trying to garner sympathy based on his name alone, shame on you.
I'm all for being reasonable and giving people the benefit of the doubt but your comment comes off as so fanboyish no wonder you're getting downvoted.
> Isn't it more likely people would take his comment at face value and respond accordingly?
Fine. Then the appropriate response is to step back, think to make sure one understands what is written, then ask him to clarify and verify that one actually understands his full opinion first if it seems to be absurd and stupid, before (or preferably instead of) calling him names.
In my experience, and I've no doubt done this myself too, developers are extremely quick to go for the heavy handed criticism and/or make it personal without first taking the time to ensure that we 1) understand the other side fully, 2) can be certain that the other side are digging their heels in for no valid reason and can't be reasoned with.
In other words: Far too often people don't try to resolve the issue before resorting to insults or behaviour that only serve to reduce the chance that an agreement can be reached.
I understand that it's frustrating to do that if you think you know how someone will respond, but the insults won't make anything better, and often makes things worse.
And very, very often people end up responding based on assumptions about the other person and the requirements and constraints the other person is working under that are flat out wrong. If you think people have made "absurd and stupid" claims, we should give them the chance to conclusively demonstrate that first before assuming so. And even then, there's rarely any reason for insults.
Frankly, a lot of the stuff that appears to be seen as perfectly acceptable and professional behaviour in tech circles would be written warning and HR supervision territory elsewhere (yes, I do recognise that a lot of people posting comments on these things are not involved in a professional setting, I still find a lot of this behaviour quite shocking)
I agree with you completely, people should be measured with how they respond to things they perceive negatively. Anything ad hominen has no relevance to the discussion.
Being called "absurd" and/or "stupid" to me (or my ideas) isn't a big deal to me. In responding I had not considered the point that for some that isn't an acceptable thing to say, which is totally fair.
I disagree with Lennart and am disgusted at the community for how they're treating other people. Human beings. That is some serious leap to fanboyism...
And I didn't imply anything regarding why Aaron killed himself but how the community reacted after he did. You should re-read the comment.
> Why should people have to assume that he "mispressed" send?
I dunno, maybe because it was clearly incomplete and ended in the middle of a word?
>And I didn't imply anything regarding why Aaron killed himself but how the community reacted after he did. You should re-read the comment.
YOU should reread your comment because the way you're phrasing it sounds /exactly/ like you're implying devs are going to start killing themselves because of abusive comments.
And honestly, even if we read your comment as how you're saying you intended it to sound, what's your point? People die and others might exaggerate their relation to the deceased? That happens with everyone, not just Aaron Swartz, or even celebrities as a whole. Your use of his name is without any relevance.
Your comment isn't "defending a human being". You're just pandering.
Sorry, I wasn't clear, when I said that I meant to say you were implying that Aaron Swartz's situation was the same as that based on how you tied him into that point.
So people who disagree with you are just trolls? That's a pretty good attitude.
To be honest, I've never seen anyone attacking Lennart as a person on HN. At least not in the not dead comments. Did I miss it?
There's a lot of attacks on what his doing, people despising him as a project leader, and criticizing him for the way he interacts with other projects. And what's wrong with that? I see what he's doing with his projects as replicating MS's EEE strategy.
Do we need to defend as a human being everyone who we think is doing something you can't stand? Do we need to write for example that Elsevier management hurt the world of research, but I'm sure they're sensitive and good as humans?
In the particular case of the linked article, it is a personal issue, not a software issue. The software is using bad defaults, referencing servers that the owners explicitly say not to reference. The response is, basically, "I'm too lazy to fix this issue". That's not a software problem, it's a problem with the lead dev's behaviour.
While we shouldn't resort to outright insults, we also shouldn't shy away from calling out bad behaviour, when it's related to the software at hand.
But this actually does not have anything to do with software. Parts of systemd are pretty good. For many people it's Lennart decisions and leadership that are the problem. This doesn't change even if systemd becomes a bugfree software masterpiece.
Systemd enjoys a steady stream of regular and new developers and pretty much all of them seem happy with Lennart.
The criticism comes from internet forums and other places, like this one here, which are completely disconnected from the people actually doing the work.
Same description applies to MS's EEE. (they retained and hired developers) Yet, we probably agree the results were terrible.
BTW, I'm somewhere in systemd changelog with a security bugfix to an issue in systemd resolver. So I became a "new developer" and I fixed it, because practically I have no choice of init in my system, not because I'm happy with Lennart. I still disagree that systemd should have its own resolver. (and the bug wouldn't even exist if they didn't decide to write their own resolver)
It's possible to attack a leadership style and the positions that leader takes without resorting to insults.
"Bob, you are being weird and stupid here" will not make Bob change his behaviour. If anything it will make him convinced that he's right and that anyone who opposes him is just another hater.
I'd actually never heard of Lennart, I'm not a systems programmer and don't generally follow what's going on in Linux politics.
Reading the OP PR thread, I get a very bad impression of him, not informed by any prior bias.
Perhaps he has settled into really negative communications and decision patterns as a result of being unfairly combatted so much in the past. But it's still there. His decision and behavior in this PR is pretty ridiculous, it in fact seemed even _more_ ridiculous to me not knowing what a 'big deal' he was.
He can be as technically skilled as there, but his approach to "problems" are ivory tower paternalism.
He is just better at covering it with words than his pal Sievers, who has managed to get Torvalds riled at more than one occasion for the same kind of paternalistic attitude.
"Lennart is a skilled dev with some excellent ideas and some controversial ideas. The stuff he designs eventually ends up being picked by distributions and defaulted."
He works for RedHat. That's why his generally-not-so-great software ends up in distributions.
That he has characterized the entire Open Source community as "full of assholes" really doesn't endear him to folks here and elsewhere, especially in light of his own behavior.
> He works for RedHat. That's why his generally-not-so-great software ends up in distributions.
As an archlinux TU, an LXDE/LXQt developer and someone close to a lot of distro maintainers, I can assure you, it's not. Systemd got popular because it's good, and it fixes and standardizes a lot of pain points.
Red Hat being behind the development just means the product gets actively developed. Not all software has the chance to flourish like that.
As a multi-platform Unix developer and someone often responsible for system administration, I can assure you that systemd does in fact "standardizes [sic] a lot of pain points." It being good is where we certainly disagree.
Red Hat funding the product means more than it being actively developed. It also implies control over the offering's compatibility, functionality, and direction. It means control over everything an OS using it can do as all processes will have systemd as its parent.
> He works for RedHat. That's why his generally-not-so-great software ends up in distributions.
Systemd was chosen by various distributions because it works and was way better than what was there before. Works for Red Hat is not a consideration in this.
Note: I actually follow Mageia, openSUSE, Debian, Fedora. In each of these distributions, the decision was not never "works for Red Hat".
Even for e.g. Ubuntu, the decision was more or less: "Debian chose it".
> That he has characterized the entire Open Source community as "full of assholes"
Can you provide evidence of that? He's pretty easy to deal with, that is one of the reasons. You get a clear answer each time. Might totally disagree with it, but that's different matter.
Given that Fedora is based on and sponsored by Red Hat, it's a significant stretch to suggest that their decision to move to systemd was made completely independently of RH. Just like Ubuntu's decision was "upstream chose it", the same goes for Fedora.
The comment I responded to said it was used because of Red Hat. You're changing it to "completely independently of RH". If you look at the history, systemd was rejected for various Fedora releases.
The suggestion here is that it is used because of Red Hat. While in practice even the Red Hat sponsored distribution rejected it various times. This distribution has the notion of being "first" with things.
> If you look at the history, systemd was rejected for various Fedora releases.
Perhaps for some pre-release stuff. In reality and in the long run, Fedora was arguably the first distro to adopt systemd (as I remember rather fondly, when I first tried Fedora primarily to give this newfangled "systemd" a whirl; boy, was that a goddamn mistake), and it being owned and operated by Red Hat is no coincidence.
Fedora is a testbed for RHEL. What you see in Fedora now is what you'll see in RHEL and CentOS (perhaps with some stabilization and testing) in the next couple years. Implying that Fedora's decision to incorporate systemd was in any way not influenced by the fact that Red Hat created it is absurd.
> He works for RedHat. That's why his generally-not-so-great software ends up in distributions.
That could possibly explain with it ends up in RedHat derivative distributions. It does not explain why so much of it ends up in a lot of the other big distro families, many of who have demonstrated perfect willingness to make choices that go actively against RedHat's direction in the past.
> That he has characterized the entire Open Source community as "full of assholes" really doesn't endear him to folks here and elsewhere, especially in light of his own behavior.
Given the amount of abuse he's taking, he clearly has sufficient evidence to justify making that statement. It might not endear him to people to actually make it, but why would he care to endear himself to people that are giving him everything from rather disgusting levels of abuse to death threats?
> It does not explain why so much of it ends up in a lot of the other big distro families, many of who have demonstrated perfect willingness to make choices that go actively against RedHat's direction in the past.
Sure it does. Like it or not, Red Hat is quite influential.
Most of the differences from Red Hat's direction stem from before Red Hat had started going in a particular direction, or were from before Red Hat was especially influential in the realm of GNU/Linux. Debian's package system, for example, predates RPMs by 3 years, which is why Debian didn't feel the need to adopt Red Hat's RPM. Meanwhile, most distros (that aren't direct descendants of Debian, at least) have adopted RPM instead of APT/dpkg as their package manager (with a few exceptions, namely the "SAG Trifecta" as I like to call them (Slackware, Arch, Gentoo), though Slackware's package system predates even Debian's, and Gentoo's is based on a BSD-style ports tree and isn't exactly a binary package system; even Slackware, however, ships with RPM tools in order to convert RPM packages to its own tarball-based package format).
If you look closely, very little modern development in the GNU/Linux distro world deviates particularly strongly from the Red Hat direction; most new developments tend to follow Red Hat (even Ubuntu, with its Not-Invented-Here syndrome raging relentlessly, has gradually begun to concede to the Red Hat way via Debian). The GNU/Linux world isn't like the BSD world, where enhancements are frequently traded between the BSDs (better networking drivers from OpenBSD here, a new hardware target from NetBSD here, some newfangled graphics stack improvements from FreeBSD there, etc.). Red Hat seems to be the epicenter of ideas for most distros nowadays (at least the ones that are universally adopted, in contrast with ideas from Novell and Canonical which tend to stay localized to SUSE and Ubuntu (respectively).
I believe he called them assholes after the threats moved from criticism to personal attacks. Though maybe I'm biased because I agree with him (well, part of the community anyway, you guys have always been alright).
You are taking comments made by a few people and claiming the entire community makes them. There were eight other responses to your comment excluding mine, all disagreeing with you in some way and doing so politely and largely dispassionately, but you focus on the single simplistic one that called him scum. One person could be described as hating him as you suggested, the other eight are hardly that passionate (nine, including me).
So yes, you are putting words in peoples' mouths by describing the community as being voiced by the one instead of the many.
> You're being kind of absurd and stupid here. Supplying a broken timeserver as a default is inane and silly. Please accept the pull request.
How persuasive is this type of language? How likely is this to change people's attitudes?
(Just for clarity: I'm not saying this is one way from not systemd to systemd. I recognize that plenty of systemd supporters use this style of communication.)
So that this thread accurately reflects the "stupid" statement, here are some of the comments using this term:
@poettering You're being kind of absurd and
stupid here. Supplying a broken timeserver as a
default is inane and silly. Please accept the pull
request. #439
Id be willing to take a patch that adds a big
warning to configure if the default ntp server to
use is not set when invoking configure. People who
ignore that warning are then on their own.
Which was followed up two minutes later with:
The issue is that the google time servers shouldn't
be used as a default, period. How does adding a
warning if you use the defaults fix the underlying
issue?
Addressed by Poettering with:
As i read what is written above google just says
the servers are crap but doesnt explicitly deny us
to use them. Which is why id like to leave them in
place because they are at least googd enough for
testing purposes.
And followed up with:
@poettering Then how about we delete the server
list entirely and let systemd crash and burn loudly
when ntp servers are not supplied. This seems
preferable to silent failures or silent hard to
find issues.
---
Characterizations of "absurd" and "stupid" may sound harsh, yet could be explained as commenters frustrated in the presence of unreasonable obstinance.
Poettering needs to either step up and stand behind the "we are going to make as many decisions for people who install systemd as we can" OR he can play the:
Systemd upstream is not a product
Card. But it cannot be both.
EDIT: Inserted newlines into the quotes to eliminate horizontal scroll bars and refined the characterization explanation to better convey original intent.
Why did you exclude the comment where he said that the google servers are bad and he would accept any servers which is better?
shitty servers as default are better than none.
If you let me know a set of servers that are openly
accessible, that do not require registration as
a vendor or product and are better then the shitty
servers then let me know and we can switch over.
> Why did you exclude the comment where he said that the google servers are bad and he would accept any servers which is better?
Because the quotes I presented were done so in context to provide a summary of why the caustic terms were used. I added my own opinion after a demarcation so that the duality would be clear.
It's funny that the quote you present both supports many people's belief that "he makes whatever decisions he can and everyone has to live with it", while still trying to play the "gee wiz, systemd isn't a product" card.
I find LP's argumentation in those lines you reproduced quite reasonable. Specifically, nobody tries to refute "google just says the servers are crap but doesnt explicitly deny us to use them". If that holds true, then half of the argument people use to get the servers removed is false. The other half seems to be "Supplying a broken timeserver as a default is inane and silly". In my opinion, this is successfully addressed by "willing to take a patch that adds a big warning" and make clear that those servers are meant exclusively for some build-and-test bots to have something to pull from - where one leap second more or less doesn't matter.
So in my opinion, unless someone refutes "google (...) doesnt explicitly deny us to use them" they might not have a valid argument.
The original PR message from a google engineer says:
> People should definitely /not/ be using these time servers by default without realising it. Please change systemd's default time servers to some service that is designed to provide a reliable public NTP service.
I guess it's not totally clear if this is "google" speaking, or just some google engineer's opinion. It's of course hard to get an "officially from google" answer to just about anything. But, whoever is speaking on wheover's behalf, does seem to be explicitly denying the use of the ntp servers, just doing so politely. Including the word 'please' does not make it less explicit.
I was heavily on the BSD bandwagon before wandering over to Linux due to commercial/job needs. I'm happy in pretty much both environments. But, personally, I believe systemd doesn't follow the UNIX philosophy of do one thing week. It is an ecosystem/environment/framework of it's own. Not my cup of tea.
Launchd on Mac seems a bit cleaner, from my experience, than systemd.
As part of the group (linux -> BSD adopters), I wouldn't be opposed to a better startup framework, but systemd has absorbed too many systems for my comfort. (Though I'm not a fan of it subsuming cron and inetd).
It won't. There were, like, three attempts to make launchd run on FreeBSD. All of them failed, because launchd is so full of Mach-isms/XNUisms/Darwinisms (lol) And pretty much everyone in the BSD community hates XML.
His reasoning is absolutely fine: It's an okay default which distributors should change (for which adding a configure warning would make sense). Direct users of the source don't have to care, or can make the configuration change themselves.
dbus is a server which applications use to talk to each other. Lots of applications started using it because it served their needs. dbus integration makes things go smoother since everybody else is already using it. The systemd NTP client is just another NTP client like any other you'd install. What could possibly make other parts of the system require that this specific service is running when it doesn't interact with applications?
I haven't yet used systemd, so maybe it works great, but here are the warning flags:
0) pulseaudio
1) there used to be many choices for startup that were relatively easy yo switch between. Systemd seems to be hard to switch to and back.
2) systemd seems to keep reimplimenting old things in its suite, without any regard for the previous experience.
Fundamentally, I worry that one day when in update my debian box, things are going to be super broken as a result of systemd subsuming many pieces of the system with new buggy versions that are not easy to stop using.
This is in contrast to openbsd: Their developers also have a poor attitude, and reimplement old ideas, but they develop in a modular fashion, and are conscious of past experience. By modular, I mean I can take their ntp server if i like it, without switching everything. And it's relative easy to switch between their https and others, etc.
So, a lot of that sounds like philosophical disagreement. The one practical concern in there is "I worry that one day when I update my debian box, things are going to be super broken", and it appears that by "broken" you mean "requiring systemd".
I'm not necessarily worried about 'requiring systemd', I'm more worried about requiring systemd-component X where component X replaces an existing service I had installed, and is a broken reimplementation, leading to system doesn't boot, doesn't bring up network, doesn't respect my previous settings, shares my data with the world, is susceptible to security bugs that were fixed in mainstream implementations many years ago, etc.
Update box, get systemd, fail to boot because of a fstab entry you barely remember was there that was acceptable to mount for years, but systemd stops the boot dead on.
Or stall on reboot/shutdown because they still can't get straight that NFS is a mount over the network, and so needs to be unmounted before taking the network down.
their DNS client that quietly grew a cache was found to be susceptible to cache poisoning. A issue that has been known about and protected against for a decade by more mature DNS implementations.
And i think their dhcp client (yep, it has that to) ignores a bunch of best practices/security in the name of speed.
The whole edifice is a NIH of cards.
This even though the project leadership is supposedly very keen on security...
Systemd correctly implements the "noauto" and "nofail" keywords in fstab(5) in the way they have always been documented: if neither of these is specified for a filesystem, then that file system will be mounted at boot time and a failed attempt to mount that filesystem implies a boot failure.
The fact that previous init scripts gladly ignored these failures does not reflect negatively on systemd but on those init scripts.
By the way, FreeBSD has the same options, except that "nofail" is called "failok".
Add a special mount option "failok" to indicate that the administrator wants
the system to proceed to boot without bailing out into single user mode,
even when the file system can not be successfully mounted.
Oh and people are of course invited to down-vote me again, I've got karma to burn, and the evidence that systemd is doing things in exactly the same way as FreeBSD clearly needs to be suppressed if we want to maintain our regular rituals of pointless outrage on this site.
And the fstab line is a copy and paste of the mount line on nofail. Basically it just suppresses the error code, and do not dictate any behavior for the larger system.
Arch doesn't have it set to google's servers by default. Do any of the other distributions? If that's the case I see most of the points on this thread being moot. In practice google's server's might be used much at all...
Google was saying something along the lines of "please don't use our time servers. They're not correct for your purposes and only if you know that and take that in to account (like we do) it'll mess everything up by about 0.04 at the moment"
They also mentioned it was not a public service that was meant to handle public loads.
I've been very critical of Poettering in the past, but after reading all the replies here, I'm starting to wonder if all if his terseness could be chalked up to extreme autism combined with social anxiety coping mechanisms (complete with memorization of pithy replies). This makes me feel really bad about that time he was "heckling" the guy at the conference, saying things like "if you don't like logind, you must hate the disabled"; he was taking the insults of his program very personally, and went for the political angle/fallacy as an attempt to shield a deep wound.
These choices are the reason for the criticism on systemd. It tries to do too much in too short. It seems to me that their moto is “code first, ask questions later”.
Another example is their choice of words for the mount units. Instead of standard industry terms (source, destination, device, directory, mountpoint, path) they chose to use the words “what” (for source/device) and “where” (for directory/mountpoint).
LP needs to know that there is basically nothing that he can say that the vitriolic people will accept. He will always be evil and out to get their "free-dums".
This is such a non-issue. How many people build systemd from scratch? Distro's all do their own thing for system time.
I think I'm just going to have to remove systemd from my Debian installs after all. Better to do it while the documentation on doing so is clear and old-stable etc is still fresh.
I had decided to give it a shot, but this is just absurd.
I agree with the fact that systemd is not a distribution to be honest however when I play devil's advocate I can totally see the reason they should be considered a vendor.
Suppose it is all interpretations at the end of the day :(
Just so everyone knows that the anti-systemd crowd has somewhere to jump, as opposed to just sitting around being angry about decisions which have already been made.
SystemD is a Linux cancer that continues to grow uncheked. If this keeps up, a base Linux system will be nothing more than the Kernel, Systemd, and Bash.
My biggest concern is that distros like Debian and CentOS, whose goals normally include stability to the point that they are often railed against for including old, sometimes too old software, have adopted Systemd before it had any real rollout and experience.
I could see distros like arch, that want to test new stuff and are known to work on bleeding edge software would make sense.
> My biggest concern is that distros like Debian and CentOS, whose goals normally include stability to the point that they are often railed against for including old, sometimes too old software, have adopted Systemd before it had any real rollout and experience.
That's a bit disingenuous, Fedora 15 (released May 2011) was the first distribution to enable systemd by default, so there were at least 2 years of "rollout and experience" when Debian 8 (April 2015) and CentOS 7 (July 2014) switched. And at least in the case of Debian, it was already available as an option since 2012.
2 years on one distro (that as far as I know, isn't popular for server-based infrastructure) is not what I would consider "real rollout or experience".
And yes, while available in debian, very few people used it for the reasons I'm talking about: it hasn't been heavily tested.
Which strengths the original point. RHEL is suppose to be rock-solid. systemd is not (technical issues aside, it's new and should be vetted more thoroughly), and I have no idea why RH and Debian are staking so much on it. That's what bothers me.
You are getting cancer from being offered some software for free? That sound a bit hyperbolic to me. No one is forced to used anything, the old alternatives are still there, and distributions like Debian supports both new and old.
They put up with it because other key parts of the Linux ecosystem now depend on it, like the Gnome desktop environment and soon udev which handles device detection on all desktop and server Linux systems.
Actually udev got merged with systemd some years back, as both past and current maintainer of udev is buddy buddy with Poettering (and staunch believers in one-true-way-ism).
This is what lead to Gentoo effectively forking udev into eudev, so that they could go on offering the distro users a choice in inits.
This because the process for extracting udev from the larger systemd code blob would change with every release, and thus requiring manual intervention.
In essence, the systemd devs are playing dirty. And because they are making the life of some other devs easier by offering tasty APIs, the project keeps agglomerating power like some kind of shoggoth.
I am damn sure that once kdbus comes into play, there will be moves made to make systemd the sole arbiter between kernel and userspace. Effectively enveloping the kernel.
Because it works, and works well and in 14 years it's the best I've ever had to deal with. Everyone is just throwing FUD around as per usual in a systemd thread.
I don't. The Linux ecosystem is no longer salvageable, so I've started moving to FreeBSD. This should buy me another 20 years, after which I won't be bothered anyway.
> We (Google) use this for systems outside of our datacenters that need to understand our concept of time.
> Google (famously(1)) runs a non standard concept of time, that works well if everything in your infrastructure knows and understands this and is designed to work with this. If you mix and match NTP servers within a machine you'll run into problems (since Google's timeservers are deliberately false ticking).
IIRC, Google handles leap-second changes by spreading it over a day (or two). This will not end well if you also use other NTP servers that do things differently
and for the -1 i just want to say ty. you're proving my point. most tech don't care about the users only their income and it's understandable.
i know you are scared, either because you don't understand the implications of using a single entity's ntp or maybe i am just upsetting your status quo. either way relax.
It's only "too late" in the sense that most distro maintainers appear to disagree with you about it ruining Linux so you'd face a very steep uphill battle to convince people (thankfully, in my opinion, given how much more pleasant systemd has been to deal with for me than the other existing alternatives so far)
There's no appeal to authority in my comment. While I believe systemd is a step up, I here merely pointed out that most distro managers disagree with him, but that this also only precludes him from using those distros - nothing stops him from forking one, or finding some suitable niche distro.
this is not for systemd the init daemon, but timesyncd - the optional network time synchronization daemon [1].
The bug is simply filed as part of the overall project.
Though it likely de facto requires the systemd init, since it allocates a Manager object with its cgroup hierarchy setup, signal handlers, loading the udev library context (remember that systemd-udevd's moving away from Netlink means it'll be systemd-only) and all that.
The first sentence on the systemd project overview is:
systemd is a suite of basic building blocks for a Linux system.
After describing the init system it goes on to say:
Other parts include a logging daemon, utilities to control basic system configuration like the hostname, date, locale, maintain a list of logged-in users and running containers and virtual machines, system accounts, runtime directories and settings, and daemons to manage simple network configuration, network time synchronization, log forwarding, and name resolution.
systemd is intentionally a much bigger project than just the systemd init system.
Then why does it seem like every Debian debate compared it (favorably) to upstart or sysvinit?
This is what annoys me about that debate. Systemd arguably _is_ a better init system. But no one asked for a new logger, network config, time daemon, cron, etc.
Now you're saying that's always been the intention? Perhaps, but this was not emphasized by the systemd team.
I don't know if that was always the intention. I don't know the original authors of systemd personally. The original announcement blog post definitely does not make any claims to be more than just an init system[1].
That said, at one point the Apache Foundation was just about a web server and the GNU project was just about a compiler.
I'm not arguing for or against systemd here, I'm just saying that the days of thinking about systemd as just an init system are over. They're building an entire framework for a Linux distro. You can agree or disagree with that, but talking about systemd today as an init system that has sprawled is obfuscating the situation. The systemd maintainers today are clearly trying to go beyond just an init system.
I think the tight coupling of programs is the main reason that systemd causes so much controversy. If it were just an init system, even an opinionated one, there wouldn't be so many people who cared.
Exactly. I didn't hear about it until i ran into a notice that consolekit was depreciated, and getting pointed to logind. And logind happened to be tightly coupled to systemd-as-pid1.
In the case of the time daemon, that does not actually seem to be the case. It appears to be a far less rigorous approach than that used by ntpd - basically it looks to be similar to running ntpdate in a loop.
Seems to be par of the course for systemd sub projects.
Their dhcp client violates various security best practices in the name of speed (the whole thing was reminiscent of the Apple debacle related to iOS wifi).
And their DNS client quietly grew a cache susceptible to poisoning. A problem known about and solved for a decade in DNS circles.
> systemd is a suite of basic building blocks for a Linux system.
Well, that's a stretch really. systemd is more like tightly coupled systems eating up more and more services and rewriting them systemd way. Things that do look like blocks (udev, journal, logind) are "take systemd way, or nothing".
Quite a few kernel devs NAKed it on basic security issues, serious design flaws, unnecessary complexity, and unwillingness to explain why kdbus is necessary (that is, why existing features were not inadequate). Instead of taking that hint addressing the serious design problems, GHK (et al) did the usual systemd-cabal tactic of pretending design doesn't matter, indirectly implying their existing design must be perfect and not open for discussion. They patched a few superficial bugs, made some vague posts on LKML about how the finished most of the outstanding issues (wtf/), as if the NAKs never happened. It's currently unclear what will happen now.
Then Lennart announces that the latest systemd has kdbus support force-enabled, while suggesting that distros should start testing kdbus with an out-of-tree patch to the kernel...
Just like this NTP server issue, the only thing that matters to Lennart is his own world. The issues and concerns of other people are never his problem.
This is a very distorted picture presented of kdbus. Like most systemd-hating posts, it focusses more on supposed personalities and "drama" than actual technology.
kdbus is a new feature. It is normal that it takes time to develop and has bugs and issues along the way. Linus specifically requested that it be enabled in systemd so that it starts to get more testing and exposure.
Constructing a grand conspiracy around kdbus is ludicrous.
> Like most systemd-hating posts, it focusses more on supposed personalities and "drama" than actual technology.
Like most systemd apparatchik, this post uses incorrect assumptions, multiple disparaging remarks, and a lot of broad, non-specific claims to try and re-frame the discussion.
> "drama"
As others in this thread have pointed out, the NTP issue is NOT about technology. Quite a few of the higher-profile problems with the systemd "cabal" are social/management problems, and like clockwork, whenever they are brought up people like you try to force the conversation away from those problems by insisting that the conversation can only be about "technical" issues. Often this is accompanied with blatant straw-men arguments, which is, unfortunately, a common tactic in many internet arguments.
I discussed Lennart's attitude, because that's the topic of the thread. Reputation matters, and the handling of this NTP issue is yet another data point.
> kdbus is a new feature
Obviously.
> It is normal that it takes time to develop and has bugs and issues along the way. L
Of course. Is it normal for the person submitting to completely ignore those issues? The fact that there were issues is not the problem. I'm talking about what happened afterwords, which was a confusing and unusual disregard of quite a few of the most serious issues brought up on LKML ( http://lkml.iu.edu//hypermail/linux/kernel/1504.1/03981.html ), and a disregard for regular kernel submission process ( https://lkml.org/lkml/2015/4/23/281 ).
This is a side issue, though, as my point was that the systemd cabal already made a lot of headway towards the "systemd-kernel" joke.
> grand conspiracy
What grand conspiracy? I'm talking about widely-known public statements, like the recent systemd v221 announcement, where Lennart said, "We encourage all downstream distributions to begin testing kdbus by adding it to the kernel images in the development distributions..."
This is especially amusing coming from someone who jsut accused me of focusing on "drama".
> Linus specifically requested that it be enabled
Unless I missed something, Linus only discussed that after Andy Lutomirski's question about systemd v221 (and the above quote requesting distributions to start testing now).
> actual technology
You want a discussion on the technology of kdbus? Then how about this question: why, exactly, is wrong with the already-existing TIPC plus a userspace library? It's been in the kernel for a while now? If it is indeed missing an imporant feature, would it not make more sense extend the features that already exist?
https://lwn.net/Articles/551969/ has GregKH talk about both Gnome's plans for a Android-like app containerization system, as well as the automobile industry wanting a higher performance dbus so they can replace QNX with embedded Linux.
Frankly i have come to read anything coming out of Gnome and Freedesktop as coming out of RH via a sock puppet.
Thing is that it may not be a willed plan inside RH. But they have enough people on payroll involved in both projects, and others, that it becomes a subconscious lockstep.
"German language source code comments are not acceptable in the systemd source tree, according to our coding style conventions. In preparation for merging LibreOffice into systemd I have thus started translating a few of their source code comments from German into English." - Lennart Poettering
That Lennart fellow is running an intentional DDOS attack on Google's servers. Google has every right to call for help from criminal authorities in Lennart's jurisdiction.
At the very least, Google reps should ask Red Hat reps to defend their reputation and reign in or sanction their rogue employee who is attacking be Internet in their name.
https://github.com/systemd/systemd/issues/437#issuecomment-1...
"Open Source projects are of course particularly welcome to use the pool in their default setup, but we ask that you get a vendor zone when using the pool as a default configuration."
http://www.pool.ntp.org/en/vendors.html