Am 01.06.2015 um 22:57 schrieb Andrew Lutomirski:
On Mon, Jun 1, 2015 at 1:42 PM, drago01 <drago01@xxxxxxxxx> wrote:On Mon, Jun 1, 2015 at 9:28 PM, Andrew Lutomirski <luto@xxxxxxx> wrote:I agree it's not essential for a server, but it can be quite helpful to work around glibc bugs. For example, I've hit https://sourceware.org/bugzilla/show_bug.cgi?id=17802 several times in production. Yes, that's a glibc bug, and glibc should fix it. Nonetheless, bugs like that wouldn't matter as much if there were a local resolver.That's not how bugs should be dealt with ... if there is a bug it should be fixed where it is not duct taped this way.This is glibc we're talking about, though. Have you tried to get a glibc bug fixed? It's not a pleasant experience.
and hence you prefer put your head in the sand and burry it by anotehr layer increasing complexity?
For example, the bug I reported has a candidate patch. That patch isn't applied, and the patch looks like the bug might be a security issue. It's been in that state for months. This is not unusual for glibc.
that don't justify a local resolver on hundrets of servers as default to hide a bug somewhere else and frankly if that problem would affect naybody i would have faced it in the past 10 years but i did not
Anyway, even on a LAN, the overhead of a network round trip per cacheable DNS query may be non-negligable for some use cases. A local caching resolver fixes that, too
and here you go: because a change is fine for *some use cases* is not a justification for introduce an *additional* layer for a default setup
the strategy wrap layers over layers to mask something going wrong in the 5 layers below and if there is a problem somewhere two weeks later wrap anotehr 2 layers on top to mask the current outbreak in the "modern" system development is nothing else than stupidty resulting in each years complexer systems where *nobody* knows what they are doing and which component is really responsible if things are going wrong
congratulations - maybe if we follow that paradigms often and fast enough the whole ecosystem is ruined in a non reveratble way that it needs to rebuilt from scratch instead rwap anotehr 10 layers with 9 minor problems around
a sane system should be as simple as possible so that *one* human is able to determine what is happening without hire 10 specialists for each layer
in short: leave me in peace with defaults raising complexity more and more, i have enough with dbus, a now essential service which cant be restarted after updates of underlying libraries while it was no problem over many years to type "chkconfig messagebus off" on servers and have no single process except the services you installed and configured
Attachment:
signature.asc
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
