Look up systemd-userdb (the systemd component that added this field). Like the sibling comment said, this is basically equivalent to adding a GECOS field. A totally optional field.
Because someone came with a pull request for this; this additional field was meant to support a feature in something else they were working on (an xdg portal). It was a simple PR that addressed a need that the programmer had. And it was accepted.
Is it some sort of well-known fact that Xi has some egotistical need to build some kind of strongman legacy? I’m no expert, but the China that he has built is one of extreme competence and long-term thinking. It’d seem contradictory to compromise that for some flashy but ultimately unhelpful actions.
Yeah, the field of software engineering has come a long way since then. But just because previous implementations of the analysis phase were flawed doesn't mean that the phase itself was flawed.
To the extend that Python is indeed "batteries included," that seems true. But just how "batteries included" is it? I'd argue that its batteries are pretty limited. Exhibit A: everybody uses the third-party requests instead of the stdlib urllib. Exhibit B: http.server isn't a production-ready webserver, so people use Flask or something beefier.
I'd contrast Python with Go, which has an amazing stdlib for the domains that Go targets. This last part is key--Go has a more focused scope than Python, and that makes it easier for its stdlib to succeed.
> http.server isn't a production-ready webserver, so people use Flask [...]
Nit, but relevant nit: Flask is also not a production-grade webserver. You could say it is also missing batteries ... and those batteries are often missing batteries too. Which is why you don't deploy flask, you deploy flask on top of gunicorn on top of nginx. It's missing batteries all the way down (or at least 3 levels down).
Appreciate the nit. Had no idea that Flask wasn't production-grade. Yeesh.
I really don't miss this part of the Python world. When I started on backend stuff ~10 years ago, the morass of runtime stuff for Python webservers felt bewildering. uWSGI? FastCGI? Gunicorn? Twisted? Like you say, missing batteries all the way down, presumably due to async/GIL related pains.
Then you step into the Go world and it's just the stdlib http package.
Anyway, ranting aside, batteries included is a real thing, and it's great. Python just doesn't have it.
> In Linux, all windows share the same message loop thread.
I'm no expert, but aren't you just talking about Xorg here? As far as my limited knowledge goes, there's nothing inherent in the Wayland protocol that would imply this.
Knot (as suggested by others) is good. As are BIND and PowerDNS. These are the big authoritative resolvers I think of at least, and all of them allow for basically hands-free DNSSEC; just flip a switch and you'll have it. I've run DNSSEC with all three and have no complaints.
And when using such turn-key DNSSEC support, I think there's very little risk to enabling it. While other commenters pointing out its marginal utility are correct, turn-key DNSSEC support that Just Works™ de-risks it enough for me that the relatively marginal utility just isn't a concern.
Plus, once you've got DNSSEC enabled, you can at the very least start to enjoy stuff like SSHFP records. DANE may not have any real-world traction, but who knows what the future may bring.
Not that I disagree with the fact that these risks exist, but how is that different than running any other service for a mission critical platform?
The main thing I can think of is DNS amplification attacks, but that's more your DNS server being used as part of a DDoS attack rather than being targeted for one. Also (afaik) resolvers are more common targets for DNS amplification than authoritative.
Large scale dns vendors have a multi million dollars worth of network layer traffic filtering equipment pipelined in front of their DNS servers (or in house solutions such as Google).
Yes, of course. But my question was why are you focusing on DNS here? Everything you've said so far is true of setting up literally any public service. Considering how cheap DNS is to serve in the common case, running an authoritative DNS server seems no less risky than running, say, a web server.
May or may not.
You open the UDP ports, you get flooded, they block all incoming traffic, and this way or another your assets are not resolvable.
One must distinguish between application layer attacks HTTP/S and UDP, cloud vendors won’t protect you implicitly for network layer attacks unless you purchased such service from them.
Unfortunately, it's more than that: the Linux installation instructions on the certbot website[0] give options for pip or snap. Distro packages are not mentioned.
I feel no need to. I'm quite certain that the certbot folks are aware of the existence of distro packages and even know how to check https://pkgs.org/download/certbot for availability. One might guess that they only want to supply instructions for upstream-managed distribution channels rather than dealing with e.g. some ancient version being shipped on Debian.
reply