“Systemd should not default to using time{1,2,3,4}.google.com” | Hacker News Reader

“Systemd should not default to using time{1,2,3,4}.google.com”

github.com

369 pointspolemic342 comments

Sounds like Mr Poettering hasn't read the vendors page and has just gotten stuck on the word vendor:

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

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!

Here's Linus defending him on /. [1]

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.

1. http://linux.slashdot.org/story/15/06/30/0058243/interviews-...

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?

what generation is that? What counts as generational in something as fast moving as our ecosystem?

Unsure feelings when one of the first topics a community brings up about you is how you might need to be "re-educated".

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.

I guess someone at a TLA found the option offensive...

I sometimes lie awake at night asking myself that very same question.

you're certainly implying that lots of people do that, but really it's only a small vocal minority.

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).

I run FreeBSD on my desktop, and I was surprised by how easy it was to get set up, and how quickly it detected everything.

Don't forget that pretty much every BSD flavor is actively working on their own systemd-like system.

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".)

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?

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.

To be fair, if you want to run systemd on Gentoo, you can. It's all about choice. The user's choice.

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

[¹] https://github.com/systemd/systemd/issues/437#issuecomment-1...

Speaking of misrepresenting...

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].

1 - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761658

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.

I find that clause from http://www.pool.ntp.org/en/vendors.html to be incredibly ambiguous.

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.

MatejLach's elaborated on Poettering's point of view for that matter. https://github.com/systemd/systemd/issues/437#issuecomment-1...

The way I see it is:

* NTP Pool welcomes open source projects to use their servers

* They want vendors to register a vendor prefix

so there are two options, either systemd is a vendor, and can register and use systemd.pool.ntp.org, or it isn't, and can use pool.ntp.org

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.

And Poettering has closed the issue with a dismissive comment after utterly missing the point. I, for one, am shocked.

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.

but it doesn't provide infrastructure

...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.

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.

The maintainer of the NTP pool agreed with Lennarts Reasoning for not registering a vendor pool in the linked bugreport.

abh says:

> Lennarts reasons for not using *.systemd.pool.ntp.org ("systemd isn't a distribution") makes sense to me.

But goes on to say:

> @crrodriguez If you kept reading you'd learn about getting a "vendor pool" setup specifically for your product/distribution.

...to provide a correction to someone saying pools can't be used.

abh also says:

> I'd suggest having no default NTP servers in the systemd code; leave it to distributors to provide their own (possibly via the NTP Pool).

That's something that LP appears to have considered. I'm not sure why that isn't done.

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.

Some examples:

Server configurations should not use .pool.ntp.org servers (why?): http://www.ntppool.org/join/configuration.html#management-qu...

Client configurations may use .pool.ntp.org servers (when?): http://support.ntp.org/bin/view/Servers/NTPPoolServers

IMHO it is urgent that at least ntp.org official documents use much more precise language, in particular defining what exactly is meant by "the pool".

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.

> "missing the point" can equally be attributed to someone who disagrees

I disagree.

In regards to the rest of your comment: Note that the main maintainer of the NTP pool agreed with Lennarts reasoning: https://github.com/systemd/systemd/issues/437#issuecomment-1...

Ah you're just missing the point.

I kid.

He's elaborated further here: https://github.com/systemd/systemd/issues/437#issuecomment-1...

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?

What happens if distros don't change the default away from *.systemd.pool.ntp.org?

> 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.

>imply some kind of responsibility of systemd.

He's like the anti-Spider Man. With great power comes no responsibility.

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.

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 was anything but "dismissive". He clearly explains his reasoning.

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.

And rightly so. It's a non issue.

He just recently provided more info

I really don't get his points.

    > 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.

EDIT: Typos, wording.

Systemd is anything but sane. http://lkml.iu.edu//hypermail/linux/kernel/1408.1/02496.html

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".

Pot, meet kettle.

Surely that message must be a parody of the overzealous Linux user? I find it hard to believe that the author is serious there.

And it still doesn't make any sense. Don't use servers as a default if the server provider have told you not to. It really is as simple as that.

Colour me shocked as well...

> shitty servers as default are better than none

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.

I stand 100% corrected.

And oddly sad. ;)

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.

> Defaults that can cause subtle errors are worse than a program abort with an error message

Agreed. I've heard this expressed as "fail fast and fail loud", with a succinct elucidation found here:

http://www.faqs.org/docs/artu/ch01s06.html#id2878548

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.

http://www.freedesktop.org/software/systemd/man/timesyncd.co...

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:

    [Time]
    NTP=0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org 3.pool.ntp.org

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.

Every time I see someone point out a problem with systemd the response always seems to be "that's just <subcomponent>, and using it is optional".

Why can't systemd developers/apologists take responsibility for their bad design and horrible decisions?

Because Ubuntu become massively successful with its bad designs and horrible decisions, so now they have imitators.

Except Ubuntu did it by being good first and then attract a bunch of coattail riders to run the ship aground. Systemd got it backwards.

What does Ubuntu have to do with this?

What exactly are these fatal Ubuntu flaws?

> What does Ubuntu have to do with this?

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.

and where does it say that I have to configure it? and I'm quoting the man page here [1]:

"NTP This setting defaults to an empty list" "FallbackNTP If this option is not given, a compiled-in list of NTP servers is used instead"

"Files in /etc/ are reserved for the local administrator, who may use this logic to override the configuration files installed by vendor packages"

sorry but no: I'm not supposed to magically guess that the default setting is going to violate some term of services of a corporation, especially as:

" this list is combined with any per-interface NTP servers acquired from systemd-networkd.service(8)"

so all it say is it works trough discovery, be happy and configure the networkd service and all will be fine.

[1] http://www.freedesktop.org/software/systemd/man/timesyncd.co...

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.

"configured" as in "./configure". If you build systemd yourself, configure it. If you don't it will come with sensible defaults.

except default aren't anywhere close to sensible, which is the whole point really

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".

Why would this stuff be baked into the binary for the software?

And this seems to be a plague on Linux as of late.

I recall a few years back someone involved with a minor distro reached out to the X.org people for some assistance getting the thing to build.

The response was something akin to "Why would you do that?! Go install a big name distro already!".

There is something rotten in Linux userland...

You don't need to fix anything! You're distro should already have handled this for you!! This has almost NOTHING to do with end users.

> 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 doesn't provide timeX.google.com as a public service" seems pretty straight forward?

I read that as "It doesn't have the same quality as public Google services".

It links to some lengthy blog post about leap seconds, which ends with:

"Google does not offer an external NTP service that advertises smeared leap seconds."

I only skipped through the blog post, though. Maybe there is a more direct rule regarding the servers somewhere.

Being told "this is not a public service" seems to indicate that it's not supposed to be used by the public. That seems pretty cut and dry.

On a related note, systemd also hardcodes Google's DNS servers:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761658

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.

Am I missing something? In the linked thread they say it reads /etc/resolv.conf and its entries have precedence.

Doesn't work so well when you take your laptop with you on travvel to China?

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.

Deleted comment

What other server do you suggest (or do you suggest none, which increases the 70% to 100%)?

I suggest no servers. They aren't something that should be hardcoded.

How about their own servers and CDNs?

If you're getting the HTML from them, you could also get your JS dependencies from them.

If by "hardcodes" you mean "can be changed in the configuration file", then yes, that's true.

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.

sounds like a good enough reason to me

https://github.com/systemd/systemd/issues/437#issuecomment-1...

I wonder why they can't use ntp pool won't allow Systemd to use them? Maybe it's only for testing purposes that they can't be used.

If that's the case, they could maybe ship a product and a testing configuration file?

> 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.

Source: www.pool.ntp.org/en/vendors.html:

As long as they get a vendor zone, that is. LP is against this, since he does not consider systemd to be a vendor.

It's probably also worth noting that Debian's systemd it (thankfully) configured to debian pool.org servers by default.

Linked email from Lennart has some interesting reasoning for this: http://lists.freedesktop.org/archives/systemd-devel/2014-Aug...

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:

https://people.freebsd.org/~phk/dlink/

Netgear hardcoded the University of Wisconsin even earlier than that:

http://pages.cs.wisc.edu/~plonka/netgear-sntp/

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...

What I take away from the link is:

  > 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".

1 - http://www.phrases.org.uk/meanings/138800.html

2 - https://en.wikipedia.org/wiki/Closed_platform

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.

Linux is widely adopted.

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.

Still doesn't explain why Google instead of ntp.org.

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.

And Ask Bjørn Hansen, the primary developer of the NTP pool, corrected that user. Keep reading, because that's not correct.

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.

>they do not want to apply for a vendor pool

So apparently there's a super good reason for this. What exactly is it?

"systemd is not a distribution."

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.

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.

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.

So ntpd is a dns server?

>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).

Lennart says the following though

> 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.

He mentions typing this on his phone so it's possible it's the autocorrect (and "corrections" that kinda make sense are the worse.)

I wasn't nitpicking I thought I could learn something.

They also have a proxying DNS client in the systemd code somewhere.

One susceptible to a decade old vulnerability no less...

What degree of access does such a vulnerability afford you though?

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).

There was a discussion about HOW it works, but not WHY they chose that method: http://stackoverflow.com/questions/11279992/math-behind-goog...

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.

It is linear now - see http://googlecloudplatform.blogspot.com.au/2015/05/Got-a-sec...

That page doesn't say that it's linear, and the page that it links that gives the precise method shows that it's not at all linear.

It is now http://people.ntp.org/burnicki/leap-second-2015-06-30/time1....

"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.)"

From the article.

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...

[1] http://googleblog.blogspot.com/2011/09/time-technology-and-l...

...which says:

> ...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):

http://www.wolframalpha.com/input/?i=plot+%281.0+-+cos%28pi+...

Boneheaded default behavior in the systemd project? How surprising.

Unnecessary inflammatory comments aren't much better than bad default behavior in software.

I'd say they're a lot worse, actually.

Edit2: And now the entire thread is getting derailed with inflammatory comments. This is sad. I've come to expect more from HN.

For good or ill, Lennart Poettering is not well regarded in these circles.

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.

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.

A couple of issues with your position:

> 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 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?

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?

It's possible to vigorously and robustly attack software without resorting to insulting the people behind that software.

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.

> 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.

> 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?

Lennart's projects were picked up as dependencies of other open source projects and by major distributions long before he started working at Red Hat.

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're doing a good job of putting words in peoples' mouths, and then denouncing them for it. People "despise every fiber of his being"?

Do you disagree? Look at the comment right below you, calling him appalling scum.

Guess who wrote it? na85, the EXACT SAME PERSON I replied to.

I would LOVE to be hallucinating this. To be the lunatic in this story. But everything in this thread has proven that I'm not.

Pottering is an appalling human being though. Why would anyone defend him? I think he is scum.

Sure.

> 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.)

If you want some unnecessary inflammatory comments, take a look at how the issue was "closed".

I did, and I see people throwing words like "Absurd" and calling lennart "stupid", while he's providing a reasonable explanation.

I disagree with Lennart and I don't think Google should be default but his reasoning is still good.

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

(pull request located at: https://github.com/systemd/systemd/pull/439)

To which Poettering responded:

  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.

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.

No. A project that has pushed itself as it has, systemd should be open to direct criticism for poor choices, poor defaults and bad behavior.

It is sad distros are using it as default, but I'm glad it won't be infesting the BSDs.

All these reactionaries flocking to BSD are going to be very upset when launchd hits them.

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.

Probably just a pipe dream: http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/lau...

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).

Last time i checked Launchd has nothing close to the scope creep that systemd has.

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.

launchd is actually not bad, except for the XML.

> I've come to expect more from HN.

For a group of people who tend to get all stabby any time someone suggests that being nicer to people is a good idea, HN sure has sensitive feelings.

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.

Wait, why is systemd running an ntp client?

And a DNS client, and a cron replacement, and a inetd replacement, and a session/seat tracker, and soon to be a tty replacement.

Zawinski's law of software envelopment perhaps?

("Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.")

Because, ultimately, PID 1 runs everything?

Nope. But everything depends on a specific binary running as pid1, something that is quite new in Linux history.

Especially when thanks to dependencies on dependencies, desktops start requiring a specific binary as pid1.

It's optional and has to be enabled... systemd is a suite of programs not just an init system...

Wasn't that originally how dbus was and is now required?

So you're telling me a dependency on an entire framework/server for IPC is comparable to a small NTP client...

No, I'm telling you that once optional things have a way of becoming less optional.

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?

This seems to suggest you don't even need dbus daemon running to have things working: https://people.debian.org/~stapelberg/docs/systemd-dependenc... just using the library doesn't seem bad to me...

Can someone explain to me what systemd detractors are actually worried about? In practical, not purely philosophical terms?

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 still don't understand what the problem is.

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.

How is this for practical:

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".

Odd, i find nothing in the fstab man file about nofail.

And all that the mount man file says on it is that it suppresses error messages.

Neither dictates any specific behavior when said errors show up.

Ok, it is younger than I thought, it was added in 2008 so more conservative veteran UNIX admins might not have heard of it:

  Util-linux-ng 2.14 Release Notes (09-Jun-2008)
  ==============================================
  
  Release highlights
  ------------------

  mount(8) supports new "nofail" mount option.

Then it wasn't documented for 2 years, the commit that adds it to the fstab.5 man page is from 2010:

https://github.com/karelzak/util-linux/commit/abe3d704b6aeb6...

Interestingly, it pre-dates the similar FreeBSD parameter by 3 years:

https://svnweb.freebsd.org/base?view=revision&revision=22283...

  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.

"poettering locked and limited conversation to collaborators 41 seconds ago"

LOL, what a solution :)

It should be only with collaborators. Just take a look at how useful this entire thread is. /s

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...

Ubuntu and Debian are using their own pools (https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree...). Fedora and RHEL are using their own pools as well (http://pkgs.fedoraproject.org/cgit/systemd.git/tree/systemd.... ctrl+f ntp). A lot of noice about nothing.

I wonder if there is also a privacy angle to consider here, as in the "yet another thing that phones home to Google".

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.

I now kinda feel bad for the guy a little.

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).

I have taken to consider it the devops/web mentality.

I see it in how Google does Android (and to a lesser extent Chrome) as well.

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.

Pottering has said his explanation was lost by github that he typed on his phone.

  > Pottering has said his explanation was lost by
  > github that he typed on his phone

Clearly, it's up to the vendors to ship a completed explanation.

Between this and this:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761658

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.

Deleted comment

That's not his fault. That is the fault of his crappy phone keyboard.

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 :(

wow... there's a lot of people being really rude to each other in here. too many chefs in the oss kitchen these days.

I don't understand his reasoning. What's wrong with registering systemd vendor? Does it put any obligations? It's just a DNS record.

Well, that's a surprise. Lennart just locked it.

https://devuan.org/

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.

I jumped to OpenBSD. That's certainly a cool project and I point other people there, but it's not production ready yet.

Wtf is the matter with these systemd guys? Why on earth does anybody put up with this software?

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.

You can't blame CentOS for switching. Their goal is to create as close to a bit-for-bit rebuild of Red Hat Enterprise Linux as possible.

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.

RH can get away with it because they still offer support for the RHEL 6.x line.

Debian ramming systemd into stable like they did on the other hand...

Don't worry, I'm sure shelld is on the agenda. After all, why pass around text commands when your shell can send binary D-bus messages?

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.

Likewise, but OpenBSD here.

I dont want google knowing where I am all the, uh, time.

Is it too late to extricate systemd from distributions? I am really sick and tired of this project ruining Linux.

Feel free to fork a distro.

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)

Yep, lets appeal to authority...

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.

OpenRC is great, tbh.

I sure hope so.. going back to the old ways would be terrible.

Deleted comment

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.

[1] https://github.com/systemd/systemd/blob/f3941a6f33cd325355c9...

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.

systemd-timesyncd may need systemd (the init system); but systemd (the init system) doesn't need systemd-timesyncd.

systemd is basically a self-contained operating system at this point...

That's a feature not a bug.

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.

>Then why does it seem like every Debian debate compared it (favorably) to upstart

The debian technical committee vote on upstart vs systemd was split 50:50.

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.

[1] http://0pointer.de/blog/projects/systemd.html

>the GNU project was just about a compiler

The acronym itself is actually a big hint that this is incorrect.

https://groups.google.com/forum/#!msg/net.unix-wizards/8twfR...

>To begin with, GNU will be a kernel plus all the utilities needed to

>write and run C programs: editor, shell, C compiler, linker,

>assembler, and a few other things.

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.

systemd does logging, network config, time daemon, cron, etc better than the alternatives btw.

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.

I'd be in "eat my hat" territory if systemd was a better logger than syslog-ng.

> 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".

Uselessd is a basic building block.

uselessd is a dead project.

I don't think that's relevant. It's still an example of what a basic block is and that systemd could be split up.

I'm patiently waiting for systemd-kernel.

Too late, it's called "kdbus", which has been trying to get into the kernel for a while now.

( https://forums.gentoo.org/viewtopic-p-7767336.html#7767336 )

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://plus.google.com/u/0/+LennartPoetteringTheOneAndOnly/...

"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

Please don't give them any ideas!

systemd-timesyncd is not an init daemon, so it's not really a question.

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.

I seriously wouldn't be surprised if this ends up with google officially providing free "Google Time" for everyone.

Reply on news.ycombinator.com