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