24 ms·
“Systemd should not default to using time{1,2,3,4}.google.com”
- deleted 11y ago[deleted]
- scrollaway 11y agosystemd-timesyncd is not an init daemon, so it's not really a question.
- sandGorgon 11y agothis 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/f3941a6f33cd325355c9669f49869267d582b6a1/configure.ac#L1023 https://github.com/systemd/systemd/blob/f3941a6f33cd325355c9...
- vezzy-fnord 11y agoThough 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.
- daurnimator 11y agosystemd-timesyncd may need systemd (the init system); but systemd (the init system) doesn't need systemd-timesyncd.
- bkeroack 11y agosystemd is basically a self-contained operating system at this point...
- krschultz 11y agoThat'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.
- drjesusphd 11y agoThen 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.
- programmernews3 11y agosystemd does logging, network config, time daemon, cron, etc better than the alternatives btw.
- caf 11y agoIn 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.
- digi_owl 11y agoSeems to be par of the course for systemd sub projects. Their dhcp client violates various security best practices in the name of speed (the whole thing was reminiscent of the Apple debacle related to iOS wifi). And their DNS client quietly grew a cache susceptible to poisoning. A problem known about and solved for a decade in DNS circles.
- gizmo686 11y agoSomewhat 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?
- plantain 11y agoIt is linear now - see http://googlecloudplatform.blogspot.com.au/2015/05/Got-a-second-A-leap-second-that-is-Be-ready-for-June-30th.html http://googlecloudplatform.blogspot.com.au/2015/05/Got-a-sec...
- DougMerritt 11y agoThat 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.
- plantain 11y ago"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.
- DougMerritt 11y agoI 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-leaping-seconds.html 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.
- Adaptive 11y agoAs 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.conf.html 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
- spankalee 11y agoThe 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.
- bahamat 11y agoEvery 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?
- reagency 11y agoBecause 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.
- oblio 11y agoWhat does Ubuntu have to do with this? What exactly are these fatal Ubuntu flaws?
- vezzy-fnord 11y agoLinked email from Lennart has some interesting reasoning for this: http://lists.freedesktop.org/archives/systemd-devel/2014-August/022575.html http://lists.freedesktop.org/archives/systemd-devel/2014-Aug...
- msandford 11y agoI 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.
- jsmthrowaway 11y agoIt'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/ https://people.freebsd.org/~phk/dlink/ Netgear hardcoded the University of Wisconsin even earlier than that: http://pages.cs.wisc.edu/~plonka/netgear-sntp/ 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.
- deleted 11y ago[deleted]
- scrollaway 11y agoCompanies 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.
- cbd1984 11y agohttps://devuan.org/ 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.
- busterarm 11y agoI jumped to OpenBSD. That's certainly a cool project and I point other people there, but it's not production ready yet.
- na85 11y agoBoneheaded default behavior in the systemd project? How surprising.
- scrollaway 11y agoUnnecessary 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.
- beedogs 11y agoIf you want some unnecessary inflammatory comments, take a look at how the issue was "closed".
- scrollaway 11y agoI 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.
- AdieuToLogic 11y agoSo 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 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.
- Lazare 11y agoAnd Poettering has closed the issue with a dismissive comment after utterly missing the point. I, for one, am shocked.
- vezzy-fnord 11y agoThe 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.
- bjourne 11y agoYou 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.
- vezzy-fnord 11y agobut 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.
- bjourne 11y agoI meant physical server infrastructure. Not the allegorical infrastructure formed by Linux packages communicating. Yes, I know the infrastructure word is horribly overloaded.
- 0xCMP 11y agoYea 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.
- userbinator 11y agoI wonder if there is also a privacy angle to consider here, as in the "yet another thing that phones home to Google".
- 0xCMP 11y agoGoogle 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.
- deleted 11y ago[deleted]
- MichaelCrawford 11y agoI dont want google knowing where I am all the, uh, time.
- beedogs 11y agoIs it too late to extricate systemd from distributions? I am really sick and tired of this project ruining Linux.
- vidarh 11y agoFeel 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)
- busterarm 11y agoOpenRC is great, tbh.
- digi_owl 11y agoYep, lets appeal to authority...
- vidarh 11y agoThere'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.
- johnny22 11y agoI sure hope so.. going back to the old ways would be terrible.
- 0xCMP 11y agoPottering has said his explanation was lost by github that he typed on his phone.
- stock_toaster 11y ago> 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.
- reagency 11y agoThat 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.
- dec0dedab0de 11y agoI seriously wouldn't be surprised if this ends up with google officially providing free "Google Time" for everyone.
- deleted 11y ago[deleted]
- reagency 11y agoThat's not his fault. That is the fault of his crappy phone keyboard.
- deleted 11y ago[deleted]
- beatpanda 11y agoCan someone explain to me what systemd detractors are actually worried about? In practical, not purely philosophical terms?
- toast0 11y agoI 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.
- beatpanda 11y agoSo, 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.
- digi_owl 11y agoHow 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...
- avian 11y agoOn a related note, systemd also hardcodes Google's DNS servers: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761658 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761658
- DiabloD3 11y agoThat 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.
- e12e 11y agoDoesn't work so well when you take your laptop with you on travvel to China?
- DiabloD3 11y agoYou 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 11y ago[deleted]
- Merovius 11y agoWhat other server do you suggest (or do you suggest none, which increases the 70% to 100%)?
- sandGorgon 11y agoEven 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-117433553 https://github.com/systemd/systemd/issues/437#issuecomment-1...
- mrweasel 11y agoI 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?
- SlashmanX 11y ago> 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:
- why-el 11y agoAs long as they get a vendor zone, that is. LP is against this, since he does not consider systemd to be a vendor.
- izacus 11y agoIt's probably also worth noting that Debian's systemd it (thankfully) configured to debian pool.org servers by default.
- vbezhenar 11y agoI don't understand his reasoning. What's wrong with registering systemd vendor? Does it put any obligations? It's just a DNS record.
- e12e 11y agoBetween this and this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761658 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.
- 0fucks 11y agoWHOEVER WANTS TO USE GOOGLE AS DEFAULT FOR ANYTHING IS SOMEONE TO BE FEARED AND MARGINALISED. NTP SHOULD NOT BE TRUSTED TO A CORPORATE GROUP THAT DOES MASS SURVEILLANCE AND CENSORSHIP, REGARDLESS OF HOW MANY SELF-DRIVING CARS OR SENTIENT IMAGE ANALYZERS THEY CAN COME UP WITH. WHOEVER THOUGHT THAT WAS A GOOD IDEA HAS BEEN ASLEEP AT THE WHEEL POST-SNOWDEN. OH THE HORROR, THE HORROR.
- sangnoir 11y agoThe problem is not a trust/surveillance issue. From the first comment: > We (Google) use this for systems outside of our datacenters that need to understand our concept of time. > Google (famously(1)) runs a non standard concept of time, that works well if everything in your infrastructure knows and understands this and is designed to work with this. If you mix and match NTP servers within a machine you'll run into problems (since Google's timeservers are deliberately false ticking). IIRC, Google handles leap-second changes by spreading it over a day (or two). This will not end well if you also use other NTP servers that do things differently
- 0fucks 11y agoYes I know that from a purely technical point it is not a trust issue but an issue with skewed time servers providing google-time instead of utc. My point is still that anyone who deliberately forces others to use google's services is a dangerous individual. System time is an identifier. I would never allow Google to control that. I take care never to use google for anything. This really upsets me. The thoughtlessness is beyond me.
- 0fucks 11y agoand for the -1 i just want to say ty. you're proving my point. most tech don't care about the users only their income and it's understandable. i know you are scared, either because you don't understand the implications of using a single entity's ntp or maybe i am just upsetting your status quo. either way relax. for the rest of us there's: https://github.com/Whonix/sdwdate https://github.com/Whonix/sdwdate
- bitJericho 11y agoWtf is the matter with these systemd guys? Why on earth does anybody put up with this software?
- jryan49 11y agoBecause 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.
- eleitl 11y agoI 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.
- busterarm 11y agoLikewise, but OpenBSD here.
- RexRollman 11y agoSystemD 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.
- jimktrains2 11y agoMy 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.
- toupeira 11y ago> 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.
- nextw33k 11y agoSounds 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-117440963 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 http://www.pool.ntp.org/en/vendors.html
- nihsyndrome2 11y agoHow 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!
- stefantalpalaru 11y agoHe 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 https://wiki.gentoo.org/wiki/OpenRC
- jcadam 11y agoNot 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).
- jcd748 11y agoI run FreeBSD on my desktop, and I was surprised by how easy it was to get set up, and how quickly it detected everything.
- jdub 11y agoHis 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.
- andmarios 11y agoThese 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).
- digi_owl 11y agoI 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.
- ajnin 11y ago> 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.
- diminishedprime 11y ago> 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.
- fixermark 11y agoI 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" ;) )
- lmm 11y 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.
- fixermark 11y ago
- jimktrains2 11y agoWait, why is systemd running an ntp client?
- digi_owl 11y agoAnd a DNS client, and a cron replacement, and a inetd replacement, and a session/seat tracker, and soon to be a tty replacement.
- jryan49 11y agoIt's optional and has to be enabled... systemd is a suite of programs not just an init system...
- jimktrains2 11y agoWasn't that originally how dbus was and is now required?
- jryan49 11y agoSo you're telling me a dependency on an entire framework/server for IPC is comparable to a small NTP client...
- jimktrains2 11y agoNo, I'm telling you that once optional things have a way of becoming less optional.
- jryan49 11y agodbus 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?
- jryan49 11y agoArch 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...
- htns 11y agoUbuntu and Debian are using their own pools (https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/rules?h=experimental 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.spec http://pkgs.fedoraproject.org/cgit/systemd.git/tree/systemd.... ctrl+f ntp). A lot of noice about nothing.
- fixermark 11y agoHonestly, 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.
- cuillevel3 11y agoI 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.
- fencepost 11y ago"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
- fixermark 11y agoIt'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 ;) ).
- jimktrains2 11y ago"Google doesn't provide timeX.google.com as a public service" seems pretty straight forward?
- kowdermeister 11y ago"poettering locked and limited conversation to collaborators 41 seconds ago" LOL, what a solution :)
- jryan49 11y agoIt should be only with collaborators. Just take a look at how useful this entire thread is. /s
- sudioStudio64 11y agoLP 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.
- fapjacks 11y agoWell, that's a surprise. Lennart just locked it.
- optik88 11y agoI 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 :(
- anonbanker 11y agoI'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.
- just2comment123 11y agowow... there's a lot of people being really rude to each other in here. too many chefs in the oss kitchen these days.