“Systemd should not default to using time{1,2,3,4}.google.com”
github.com
github.com
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."
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).
systemd does have some nice features that I've come to appreciate on my GNU/Linux boxen, but I'm still not exactly sold when my OpenBSD boxen have a mostly-sane rc system not subject to most of the problems the systemd crowd claims are inherent to initscript-based systems.
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.
Did you listen to the presentation?
Look, snark aside, nobody can sanely suggest the existing init systems are sufficient in 2015+. New ideas present in systemd and launchd are exactly what people have desired for a long time. Maybe systemd doesn't float your particular boat, but that doesn't mean the old init system is superior.
I run OpenRC on servers, desktops, laptops and even a Banana Pro Single-board computer. It's perfectly sufficient.
Maybe for you...
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.
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.
The entire Red Hat corporation has been like this since about the 5.2 release, when they removed "Redneck" as a system language option.
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-...
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.
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?
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...
* 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 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.
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...
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.
I'd suggest having no default NTP servers in
the systemd code...
1 - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761658
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.
Lennart is controversial, but he usually provides more-or-less decent reasons for technical trade-offs. Here though? Complete copout.
...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.
What happens if distros don't change the default away from *.systemd.pool.ntp.org?
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.
He's like the anti-Spider Man. With great power comes no responsibility.
I find it a reasonable position, that he wants to avoid such a situation.
Also note, that the reporter didn't write "don't use this, we can't handle the load", but "don't use this, weird stuff will happen to your server".
But yes, I agree, Googles NTP servers should be removed as a default. But a vendor pool also isn't a solution apparently. Luckily, there are people actively working on a PR to simply have no default. So everyone should just calm down and give the issue a while to resolve itself, instead of venting here on HN.
>Google doesn't provide timeX.google.com as a public service.
That's the end of the conversation. How Google handles rare time events, whether it's reliable or scalable are all irrelevant.
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).
> 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 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.
Pot, meet kettle.
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.
> 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.
Yes. Someone claimed (correctly), that *.pool.ntp.org can't be used. abh ammended that by saying, that however, a vendor zone can be used. I don't think anyone ever doubted that point. Notably, Lennart seemed to be aware of that point in his earlier mail.
> That's something that LP appears to have considered. I'm not sure why that isn't done.
The reason given before was, that tests and similar need some values. However, a PR implementing exactly this solution is currently in discussion (and afaik Lennart has not respondet to that yet). I would wait until the dust is settled on that, before I continue this discussion. The bug report (which is afaik the first time anyone has indicated that the Google servers shouldn't be used for this) is half a day old, that's basically nothing in FOSS-development (especially for a non-critical issue like this). Give it some time, if this isn't solved in a week, that may be a more appropriate time for pointing fingers and being unpatient.
> 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.
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.
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".
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.
"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.
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...
I kid.
But this has been pretty much his approach to systemd from the very start; which is why it's polarised the community so much.
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.
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.
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" ;) )
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.
And oddly sad. ;)
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.
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.
Agreed. I've heard this expressed as "fail fast and fail loud", with a succinct elucidation found here:
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.orgWhy can't systemd developers/apologists take responsibility for their bad design and horrible decisions?
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 exactly are these fatal Ubuntu flaws?
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?
"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...
Linking to a bugreport with an ongoing discussion is a bit pointless IMO. It's still being discussed!
edit: Ah, I think I now know where the misunderstanding lies. My "if you don't" refers to "if you don't build it from source", not to "if you don't ./configure it".
I 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...
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.
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.
"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.
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 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.
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.
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...
If that's the case, they could maybe ship a product and a testing configuration file?
systemd are perfectly entitled to use ntp pool as defaults.
Source: www.pool.ntp.org/en/vendors.html:
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.
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.
So apparently there's a super good reason for this. What exactly is it?
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.
I'd buy this if they explicitly didn't set a default ntp server at all, but that's not a good reason to set it to Google rather than ntp.org.
The linked thread has someone from Google telling systemd that systemd should stop using Google's time servers.
Which has unclear (non-technical) implications. Which Lennart Poettering doesn't want to tolerate. Which I would consider a valid opinion.
> The linked thread has someone from Google telling systemd that systemd should stop using Google's time servers.
For technical reasons, that Lennart Poettering doesn't agree with (i.e. these defaults won't be used in production and if you use an unconfigured self-build of systemd in production, it's your own fault).
Unconfigured is better than a bad default.
He addressed that in another post. Basically from a testing and development POV he believes it's important to ship with some default that at least works out of the box, even if the default is completely unsuitable for production.
Something akin to the blinking 0:00, that shows the time circuit is powered up but with no time set.
And if it's using a service like the NTP pool, it needs to have a vendor prefix. Not because this has anything at all to do with the notion of being a "distribution", but because the prefix provides a means for the pool to identify traffic originating from default-configured systemd instances, and cut it off if it suddenly starts to behave in a way that would degrade the rest of the network.
Or they can simply ship with no default. But you can't have it both ways, both setting a default server and claiming not to be a vendor in every sense meaningful to an NTP server operator.
The 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.
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.
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.
> 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
One susceptible to a decade old vulnerability no less...
> 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.
> > This is really about being a *client*, and
> > not trying to outsmart servers.
>
> Outsmart servers how exactly?
By not trusting them...
BTW, love your use of the phrase "interesting reasoning".
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...
From the article.
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.
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+...
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.
Edit: from other comments here, it looks like Google also uses a linear smear now (a linear drift over 20 hours is 14ppm).
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.
I disagree with Lennart and I don't think Google should be default but his reasoning is still good.
@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
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.
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?
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.
@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
EDIT: Inserted newlines into the quotes to eliminate horizontal scroll bars and refined the characterization explanation to better convey original intent.
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.Because the quotes I presented were done so in context to provide a summary of why the caustic terms were used. I added my own opinion after a demarcation so that the duality would be clear.
It's funny that the quote you present both supports many people's belief that "he makes whatever decisions he can and everyone has to live with it", while still trying to play the "gee wiz, systemd isn't a product" card.
So in my opinion, unless someone refutes "google (...) doesnt explicitly deny us to use them" they might not have a valid argument.
> People should definitely /not/ be using these time servers by default without realising it. Please change systemd's default time servers to some service that is designed to provide a reliable public NTP service.
I guess it's not totally clear if this is "google" speaking, or just some google engineer's opinion. It's of course hard to get an "officially from google" answer to just about anything. But, whoever is speaking on wheover's behalf, does seem to be explicitly denying the use of the ntp servers, just doing so politely. Including the word 'please' does not make it less explicit.
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.
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.
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.
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.
Red Hat funding the product means more than it being actively developed. It also implies control over the offering's compatibility, functionality, and direction. It means control over everything an OS using it can do as all processes will have systemd as its parent.
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.
The suggestion here is that it is used because of Red Hat. While in practice even the Red Hat sponsored distribution rejected it various times. This distribution has the notion of being "first" with things.
Perhaps for some pre-release stuff. In reality and in the long run, Fedora was arguably the first distro to adopt systemd (as I remember rather fondly, when I first tried Fedora primarily to give this newfangled "systemd" a whirl; boy, was that a goddamn mistake), and it being owned and operated by Red Hat is no coincidence.
Fedora is a testbed for RHEL. What you see in Fedora now is what you'll see in RHEL and CentOS (perhaps with some stabilization and testing) in the next couple years. Implying that Fedora's decision to incorporate systemd was in any way not influenced by the fact that Red Hat created it is absurd.
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?
Sure it does. Like it or not, Red Hat is quite influential.
Most of the differences from Red Hat's direction stem from before Red Hat had started going in a particular direction, or were from before Red Hat was especially influential in the realm of GNU/Linux. Debian's package system, for example, predates RPMs by 3 years, which is why Debian didn't feel the need to adopt Red Hat's RPM. Meanwhile, most distros (that aren't direct descendants of Debian, at least) have adopted RPM instead of APT/dpkg as their package manager (with a few exceptions, namely the "SAG Trifecta" as I like to call them (Slackware, Arch, Gentoo), though Slackware's package system predates even Debian's, and Gentoo's is based on a BSD-style ports tree and isn't exactly a binary package system; even Slackware, however, ships with RPM tools in order to convert RPM packages to its own tarball-based package format).
If you look closely, very little modern development in the GNU/Linux distro world deviates particularly strongly from the Red Hat direction; most new developments tend to follow Red Hat (even Ubuntu, with its Not-Invented-Here syndrome raging relentlessly, has gradually begun to concede to the Red Hat way via Debian). The GNU/Linux world isn't like the BSD world, where enhancements are frequently traded between the BSDs (better networking drivers from OpenBSD here, a new hardware target from NetBSD here, some newfangled graphics stack improvements from FreeBSD there, etc.). Red Hat seems to be the epicenter of ideas for most distros nowadays (at least the ones that are universally adopted, in contrast with ideas from Novell and Canonical which tend to stay localized to SUSE and Ubuntu (respectively).
> 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.
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?
YOU should reread your comment because the way you're phrasing it sounds /exactly/ like you're implying devs are going to start killing themselves because of abusive comments.
And honestly, even if we read your comment as how you're saying you intended it to sound, what's your point? People die and others might exaggerate their relation to the deceased? That happens with everyone, not just Aaron Swartz, or even celebrities as a whole. Your use of his name is without any relevance.
Your comment isn't "defending a human being". You're just pandering.
And I maintain that. You seem to be missing my point.
> You're just pandering
Or maybe I'm just feeding a damn troll at this point. I'll stop.
So people who disagree with you are just trolls? That's a pretty good attitude.
I shouldn't have said that, you're right, sorry.
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)
Being called "absurd" and/or "stupid" to me (or my ideas) isn't a big deal to me. In responding I had not considered the point that for some that isn't an acceptable thing to say, which is totally fair.
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?
The criticism comes from internet forums and other places, like this one here, which are completely disconnected from the people actually doing the work.
Armchair problematism.
BTW, I'm somewhere in systemd changelog with a security bugfix to an issue in systemd resolver. So I became a "new developer" and I fixed it, because practically I have no choice of init in my system, not because I'm happy with Lennart. I still disagree that systemd should have its own resolver. (and the bug wouldn't even exist if they didn't decide to write their own resolver)
"Bob, you are being weird and stupid here" will not make Bob change his behaviour. If anything it will make him convinced that he's right and that anyone who opposes him is just another hater.
While we shouldn't resort to outright insults, we also shouldn't shy away from calling out bad behaviour, when it's related to the software at hand.
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.
So yes, you are putting words in peoples' mouths by describing the community as being voiced by the one instead of the many.
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.
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 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.
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.
> 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.)
It is sad distros are using it as default, but I'm glad it won't be infesting the BSDs.
launchd is actually not bad, except for the XML.
Launchd on Mac seems a bit cleaner, from my experience, than systemd.
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.
("Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.")
Especially when thanks to dependencies on dependencies, desktops start requiring a specific binary as pid1.
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.
I still don't understand what the problem is.
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...
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".
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.
Util-linux-ng 2.14 Release Notes (09-Jun-2008)
==============================================
Release highlights
------------------
mount(8) supports new "nofail" mount option.
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.
LOL, what a solution :)
They also mentioned it was not a public service that was meant to handle public loads.
I now kinda feel bad for the guy a little.
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 see it in how Google does Android (and to a lesser extent Chrome) as well.
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
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.
Suppose it is all interpretations at the end of the day :(
Just so everyone knows that the anti-systemd crowd has somewhere to jump, as opposed to just sitting around being angry about decisions which have already been made.
I could see distros like arch, that want to test new stuff and are known to work on bleeding edge software would make sense.
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.
And yes, while available in debian, very few people used it for the reasons I'm talking about: it hasn't been heavily tested.
Debian ramming systemd into stable like they did on the other hand...
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.
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)
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.