[dns-operations] Sad news today: systemd-resolved to be deployed in Ubuntu 16.10

[Rick Wesson]

My plug for Devuan Jessie 1.0 Beta, it works really well and provides the
stuff you are looking for. I use it and it works well.

Alternatives are out there and I suggest giving it a try.

-rick


On Fri, Jun 3, 2016 at 9:23 AM, Ondřej Surý <ondrej.sury at nic.cz> wrote:

> This seems like a good topic for IETF hackathlon.
>
>
>
> On 3 June 2016 16:30:08 Florian Weimer <fweimer at redhat.com> wrote:
>
> On 06/03/2016 02:12 PM, Paul Vixie wrote:
>>
>>>
>>>
>>> Ondřej Surý wrote:
>>>
>>>> I already spoke to Martin, and he is very open about that decision
>>>> (it's still very early in the development cycle), so I think that
>>>> this still might be reverted if we don't slip into systemd-ranting
>>>> and provide reasons why this has bad design (not just bugs).
>>>>
>>>
>>> systemd, launchd, and libc, and mpr, and every other place where dns
>>> client logic is needed, should just link against getdns, and not try to
>>> understand or to improve upon the best available dns client logic.
>>>
>>
>> That's not very realistic, particularly for libc:
>>
>> $ ldd /usr/lib64/libgetdns.so.1
>>         linux-vdso.so.1 (0x00007ffdf7d85000)
>>         libunbound.so.2 => /lib64/libunbound.so.2 (0x00007f2c78da5000)
>>         libidn.so.11 => /lib64/libidn.so.11 (0x00007f2c78b71000)
>>         libssl.so.10 => /lib64/libssl.so.10 (0x00007f2c788ff000)
>>         libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f2c7849f000)
>>         libc.so.6 => /lib64/libc.so.6 (0x00007f2c780d8000)
>>         libevent-2.0.so.5 => /lib64/libevent-2.0.so.5 (0x00007f2c77e8d000)
>>         libpython3.5m.so.1.0 => /lib64/libpython3.5m.so.1.0
>> (0x00007f2c779be000)
>>         libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f2c777a1000)
>>         libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2
>> (0x00007f2c77554000)
>>         libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f2c7726e000)
>>         libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f2c7706a000)
>>         libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f2c76e36000)
>>         libdl.so.2 => /lib64/libdl.so.2 (0x00007f2c76c32000)
>>         libz.so.1 => /lib64/libz.so.1 (0x00007f2c76a1c000)
>>         /lib64/ld-linux-x86-64.so.2 (0x0000561536183000)
>>         libutil.so.1 => /lib64/libutil.so.1 (0x00007f2c76819000)
>>         libm.so.6 => /lib64/libm.so.6 (0x00007f2c7650f000)
>>         libkrb5support.so.0 => /lib64/libkrb5support.so.0
>> (0x00007f2c76300000)
>>         libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f2c760fa000)
>>         libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f2c75edf000)
>>         libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f2c75cb8000)
>>         libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f2c75a47000)
>>
>>
>> I have not investigated whether it is possible to trim things down.  It
>> would probably need custom builds of libunbound and OpenSSL with mangled
>> symbols.
>>
>> Florian
>>
>
>
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160603/8049c62b/attachment.html>