"Open Source projects are of course particularly welcome to use the pool in their default setup, but we ask that you get a vendor zone when using the pool as a default configuration."
How on earth did the modern linux distro become so dependant on software from this guy, when he clearly has no real world idea of things. No wonder people are jumping ship to the various BSDs!
Linus: You can say the word "systemd", It's not a four-letter word. Seven letters. Count them.
I have to say, I don't really get the hatred of systemd. I think it improves a lot on the state of init, and no, I don't see myself getting into that whole area.
Yeah, it may have a few odd corners here and there, and I'm sure you'll find things to despise. That happens in every project. I'm not a huge fan of the binary logging, for example. But that's just an example. I much prefer systemd's infrastructure for starting services over traditional init, and I think that's a much bigger design decision.
Yeah, I've had some personality issues with some of the maintainers, but that's about how you handle bug reports and accept blame (or not) for when things go wrong. If people thought that meant that I dislike systemd, I will have to disappoint you guys.
More like defending the init part of systemd, but still mentioning personality issues with certain people involved with the project.
Sadly most of these debates gloss over that systemd has long since grown past being just a init replacement.
It has sprouted tentacles all over Linux userspace, and all of them are tightly connected to systemd sitting as init-in-chief.
Thus updating some higher level part of userspace, say the Desktop Environment, may well result in your Linux install getting a init-ectomy via the dependencies chain.
Perhaps it's generational? Maybe Mr. Poettering is a talented individual who lacks some specific experiences/history which requires re-learning some lessons from developing linux?
This isn't just SystemD. you should ask rasterman sometime about his stint at RH Labs. There was a great interview with him and Havoc Pennington back in 1999 or 2000 where HP couldn't say a nice thing about the guy or his code, because he just didn't fit in with the redhat culture (he liked to wear formal wear to work - a subtle protest of mandatory office attire).
The entire Red Hat corporation has been like this since about the 5.2 release, when they removed "Redneck" as a system language option.
He has Red Hat's support. Anyway, no need to jump ship to the BSD clones. Just use Gentoo - OpenRC is a great init system: https://wiki.gentoo.org/wiki/OpenRC
Not so sure about that. Since "mainstream" Linux is now on systemd, how long can some of these alternative init systems remain viable?
I always preferred the BSDs on the server anyway, systemd was just the final nudge I needed to get me to run it on my dev box (it actually makes things simpler anyway, I was not relishing the thought of having completely different init systems on my dev box and servers).
Speaking as a sysadmin, I find something like launchd/upstart/systemd a ridiculously superior alternative to init scripts, in every way. So this is a good thing. (For various values of "systemd-like".)
Also speaking as a sysadmin, I've found "every way" to be inaccurate. Initscripts have their limitations, but the most glaring issues with them (lots of boilerplate, hard to write, etc.) have been resolved in BSD Land for quite a while, thanks to things like rc.subr.
systemd does have some nice features that I've come to appreciate on my GNU/Linux boxen, but I'm still not exactly sold when my OpenBSD boxen have a mostly-sane rc system not subject to most of the problems the systemd crowd claims are inherent to initscript-based systems.
true, I'm talking about fairly generic Ubuntu VMs out in the fog. But basically, the facilities available cover my common use cases very nicely on the occasions I actually have to write a startup script - I'm finding an upstart config vastly preferable to cobbling together an init shell script, and have yet (out of about 5-10 cases) had to resort to a shell script.
That's not a problem. Even a good thing and the BSDs will build one properly.
The problem is how systemd came to be (through political games indeed of merit) and that it's not just an init replacement but that it gets its grubby fingers everywhere in the OS and that it's turning Linux into a Windows-like binary blob mess.
There's a difference between discussion regarding /a/ more in-depth system framework and discussion regarding a specific system framework. One of the constant things written about in these threads though is that they /don't/ want something "systemd-like" because it is such an intrusive, obstinate framework. I see some good ideas coming from the systemd framework, however, its consistent choice of poor defaults and byzantine structure leave me desiring something of a bit more lucid vision.
They are? That's interesting. Please provide details. What systemd-like systems are (to start with) the OpenBSD, DragonFly BSD, MirOS BSD, NetBSD, FreeBSD/PC-BSD, and Debian kFreeBSD people actively working on?
Uh, the entire presentation is about the need for a systemd-like system, and how the existing init system is not sufficient.
Did you listen to the presentation?
Look, snark aside, nobody can sanely suggest the existing init systems are sufficient in 2015+. New ideas present in systemd and launchd are exactly what people have desired for a long time. Maybe systemd doesn't float your particular boat, but that doesn't mean the old init system is superior.
I'd go 100% OpenBSD if it wasn't for my deep-seated love affair with GNU and it's concepts (if not the figurehead). I'm starting to see the GNU boat being sabotaged, though, so I might be forced to abandon my compromised vessel and build a new 3-clause ship.
Gentoo is honestly the best of both worlds; linux compatibility, tons of applications, can be rebuilt from source, and a version of ports that doesn't suck. Their steadfast refusal to adopt systemd is pretty much icing on the cake at that point.
As of late i have come to loath the user/developer distinction.
Any user is a potential developer given time and access to tools.
But as of late there has been more and more an attitude that developers has to go out of their way to protect users from themselves (user).
Thus you get the likes of ChromeOS where the default setup is highly restrictive. And flipping the "developer" switch either way wipes the device clean.
Thus there is a very big mental step to go "developer", rather than start out small with some scripts (thus getting familiar with code logic) and perhaps move on from there.
Then, I guess, the main Maintainer of pool.ntp.org, who explicitely stated¹ that he agrees with Lennart Poetterings reasoning also hasn't read that?
It is a really poor signal how much crap gets flung at the systemd people for this bugreport that is
a) not even a day old
b) entirely inconsequential for anyone but the systemd devs and maybe Google
c) is apparently completely misunderstood and/or misrepresented
In the response you link, "abh" agreed about a specific point in "Poettering's reasoning":
Lennarts reasons for not using
*.systemd.pool.ntp.org ("systemd isn't a
distribution") makes sense to me.
This is very different than agreeing that hard-coding a set of NTP servers into the code base is the way to go. To this point, "abh" wrote:
I'd suggest having no default NTP servers in
the systemd code...
Which is what many others have requested as well. If this were an isolated decision, it would be a different thing. But it is not, as several others in this thread have provided supporting evidence[1].
I am sorry if I was unclear in that. My comment (and similar comments in other threads) directly referred to criticism of Lennart for deciding that he doesn't want a vendor zone for systemd.
In regards to the DNS server comment: I said it elsewhere before, this is completely unrelated. You may disagree with the decision from a political viewpoint and that is totally fine. But from a technical viewpoint the usage of the Google DNS Servers is completely reasonable.
He's just being stubborn. The vendor registration requirement is really simple and entirely exists to give a way to control the situation of an NTP client goes crazy. I'm a little sympathetic to his argument that the distribution vendors like Red Hat should register instead. But if that's the goal then systemd needs to provide no default in the stock code and force the distributor to configure it.
From the Github comment you are referencing, dannyperson states, "When NTP Pool warns that pool.ntp.org should not be a default, this warning is directed to vendors, not open source projects." but the clause from http://www.pool.ntp.org/en/vendors.html IS talking about Open Source Projects. The heading is "Open source projects".
What is the difference between a default setup and a default configuration?
It isn't ambiguous at all.
If you're publishing something, whether it's open and free or commercial you're a vendor so you have to follow the policy ntp.org set-up for such entities.
That person on github is misunderstanding both Poettering and the ntp.org's policy.
They can use "the pool", i.e. the collection of NTP servers.
They could (register a "vendor zone") and use "[0-3].systemd.pool.ntp.org". They can, technically, even use "[0-3].pool.ntp.org", but the NTP Pool Project is saying they cannot use [the specific hostname] "pool.ntp.org".
That last part is what people are apparently not understanding.
Also, OpenBSD blatantly ignores it and uses "pool.ntp.org" anyways.
In essence open source projects are vendors as far as ntp.org is concerned and you can use their service but have to obtain a vendor zone for that. The formulations are indeed not as clear as they could be but after reading the ntp.org page a couple of times there isn't really any other meaningful way to parse it.
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