Re: ANN: DNS resolver changes in yakkety
On Tue, May 31, 2016 at 11:34:41AM +0200, Martin Pitt wrote:
> yesterday I landed [1] in Yakkety which changes how DNS resolution
> works -- i. e. how names like "www.ubuntu.com" get translated to an IP
> address like 1.2.3.4.
> Now DNS resolution goes via a new "libnss-resolve" NSS module which
> talks to resolved [2]. /etc/resolv.conf has the "real" nameservers,
> broken name servers are handled efficiently, and we have local DNS
> caching. NetworkManager now stops launching a dnsmasq instance.
Please forgive this email for rambling; it's length and lack of focus
may reflect questions and uncertaintyy the larger community may have,
however, so I'm sending it anyway. :)
== /etc/resolv.conf ==
/etc/resolv.conf appears to be both a resolved configuration file ("global
resolvers") as well as something it will publish for other programs to
consume (the symlink to /run/systemd/resolve/resolv.conf ).
- Which programs would consume data from this file? (My guess is 'native'
lookup routines in languages like perl, python, ruby, erlang, java. Is
this close? Who else would read from this file? Should we let them?)
- Would we want to stop using resolvconf? It feels like resolvconf's uses
would be drastically less important with good systemd-networkd
configuration instead. Would any cases remain where we want to keep
resolvconf?
- Will we go with the symlink route (i.e., resolved is the publisher) or
will we go with the regular file route (i.e., resolved is the consumer)?
== /etc/nsswitch.conf ==
> [2] This is configured in /etc/nsswitch.conf ("hosts: files ... resolve dns")
Do we even want to keep 'dns' on this line? If resolved fails to resolve
a request then falling back to DNS feels like it will simply push the
inevitable failure off by another six to eighteen seconds.
- When would 'hosts: .. resolve .. dns' be a better configuration than
'hosts: .. resolve ..' ?
== replace dnsmasq's combined dhcpd and "local" dns ==
- Will dhcp leases handed out by systemd's dhcp server be automatically
entered into the resolved database for lookups?
dnsmasq is used by many tools for these dual purposes and often times
chained together with resolveconf but the fact that it is _chained_
together means that e.g. containers can't look up VM names, or VMs
can't look up container names, when both VMs and containers are hosted
on one system.
I've spent enough time fighting dnsmasq and resolvconf that I'd quite
like to try replacing dnsmasq and resolvconf entirely. An NSS-based
interface may be able to do better.
Will we adapt lxd and libvirt and so on to use systemd-network so that
resolved and the systemd dhcp server stand a chance of replacing the other
tooling?
== LLDNS ==
Will we enable LLDNS? Do we want to? Responding too?
Thanks
signature.asc
Description: PGP signature
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: OpenGL to OpenGL ES change on arm64?
On Sat, Jun 04, 2016 at 02:00:04AM +0200, Matthias Klose wrote: > > There are two ways to make a GLES-enabled Qt stack available on arm64; the > > armhf way (build Qt exclusively for GLES), or the x86 way (build alternative > > stacks for both GL and GLES). > > Which we should pursue depends on whether there is a use case for OpenGL Qt > > software anywhere on ARM64. > > For the phone / embedded GPU case, we have no known chips providing > > accelerated OpenGL drivers. > > For the server / add-on GPU case, we have no known uses for GUI toolkits - > > only CUDA and GPU-accelerated computation. > > So from what I know, we should be fine to ship GLES-only Qt on ARM64, and > > delete any ARM64 binaries from the archive that require GL-enabled Qt. > so why change something, if we know we won't use it? If we see the need > for both stacks, why not keeping the current default, and then go the x86 > way later? You seem to propose a third way to do it, defaulting to GLES, > and then adding support for GL if needed. This looks like extra work, and > unique to arm64. I think you're confused here. We *are* going to be using the Qt GLES stack, for 64-bit ARM phones / devices. We have an immediate need for GLES-enabled Qt because these chips have accelerated GLES drivers, not accelerated GL drivers. And this is exactly the same thing that we already have on armhf, not a "third way". -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: OpenGL to OpenGL ES change on arm64?
On 04.06.2016 00:25, Steve Langasek wrote: > On Fri, Jun 03, 2016 at 03:56:14PM -0500, Kevin Gunn wrote: >>> Ubuntu supports a growing number of ARM servers that have PCIe slots, >>> so external GPUs can be added. CUDA is supported on those platforms >>> upstream: >>> https://developer.nvidia.com/cuda-toolkit-65 >>> And I do know there are users interested in CUDA on Ubuntu/arm64. > >>> I'm not experienced with CUDA myself - and don't have a card to test it >>> - but it would be good to know if we're breaking that use case ahead of >>> time. > >> That's fair enough. I guess that's back to the original statement about >> "Do we really have to cripple an architecture like this?" >> It's not about the arch per se it's more about having offerings that match >> Gpus attached to that arch. So does it make sense to leave them in place >> and just know you'll have build failures in some cases? > > There are two ways to make a GLES-enabled Qt stack available on arm64; the > armhf way (build Qt exclusively for GLES), or the x86 way (build alternative > stacks for both GL and GLES). > > Which we should pursue depends on whether there is a use case for OpenGL Qt > software anywhere on ARM64. > > For the phone / embedded GPU case, we have no known chips providing > accelerated OpenGL drivers. > > For the server / add-on GPU case, we have no known uses for GUI toolkits - > only CUDA and GPU-accelerated computation. > > So from what I know, we should be fine to ship GLES-only Qt on ARM64, and > delete any ARM64 binaries from the archive that require GL-enabled Qt. so why change something, if we know we won't use it? If we see the need for both stacks, why not keeping the current default, and then go the x86 way later? You seem to propose a third way to do it, defaulting to GLES, and then adding support for GL if needed. This looks like extra work, and unique to arm64. Matthias -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: OpenGL to OpenGL ES change on arm64?
On Fri, Jun 03, 2016 at 03:56:14PM -0500, Kevin Gunn wrote: > > Ubuntu supports a growing number of ARM servers that have PCIe slots, > > so external GPUs can be added. CUDA is supported on those platforms > > upstream: > > https://developer.nvidia.com/cuda-toolkit-65 > > And I do know there are users interested in CUDA on Ubuntu/arm64. > > I'm not experienced with CUDA myself - and don't have a card to test it > > - but it would be good to know if we're breaking that use case ahead of > > time. > That's fair enough. I guess that's back to the original statement about > "Do we really have to cripple an architecture like > >> this?" > It's not about the arch per se it's more about having offerings that match > Gpus attached to that arch. So does it make sense to leave them in place > and just know you'll have build failures in some cases? There are two ways to make a GLES-enabled Qt stack available on arm64; the armhf way (build Qt exclusively for GLES), or the x86 way (build alternative stacks for both GL and GLES). Which we should pursue depends on whether there is a use case for OpenGL Qt software anywhere on ARM64. For the phone / embedded GPU case, we have no known chips providing accelerated OpenGL drivers. For the server / add-on GPU case, we have no known uses for GUI toolkits - only CUDA and GPU-accelerated computation. So from what I know, we should be fine to ship GLES-only Qt on ARM64, and delete any ARM64 binaries from the archive that require GL-enabled Qt. Either way, we're not going to leave unbuildable binaries hanging around in the archive. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: OpenGL to OpenGL ES change on arm64?
On Fri, Jun 3, 2016 at 2:51 PM, Steve Langasek wrote: > On Fri, Jun 03, 2016 at 01:03:53PM -0600, Dann Frazier wrote: >> [ Reorganized to use inline replies ] >> On Fri, Jun 3, 2016 at 12:49 PM, Kevin Gunn wrote: >> > On Fri, Jun 3, 2016 at 10:47 AM, Matthias Klose wrote: > >> >> LP: #1586026 asks for the removal of binary packages on arm64 which >> >> cannot be built with OpenGL ES. Do we really have to cripple an >> >> architecture like this? I don't see any discussion about this. How >> >> does this affect things like GPU accelerators and CUDA aware packages? > >> > hey Matthias, >> > after reading the bug, it's implied the binaries being asked for removal >> > were somehow built with gl (possibly sw implementation of gl?)please >> > cmiiaw > >> > as to the request, never say never, but at least i've never seen an arm >> > chipset in the wild with a gl enabled gpu (like the bug indicates they're >> > all gles). >> > so i'm not sure of the value of having those binaries present where at >> > least >> > in real application, there's no gl ? > >> Ubuntu supports a growing number of ARM servers that have PCIe slots, >> so external GPUs can be added. CUDA is supported on those platforms >> upstream: >> https://developer.nvidia.com/cuda-toolkit-65 >> And I do know there are users interested in CUDA on Ubuntu/arm64. > >> I'm not experienced with CUDA myself - and don't have a card to test it - but >> it would be good to know if we're breaking that use case ahead of time. > > I agree that CUDA should be a concern on arm64. However, this bug report is > about changes to the Qt GL stack on arm64. Qt is a GUI toolkit; I don't see > any reason that building Qt for GLES instead of GL should impact CUDA, do > you? If this change goes no deeper than the Qt stack, then no. > And while ARM64 servers have PCIe slots and can take GPUs, I don't expect > this to mean that we want to support a desktop stack in such a > configuration. I don't know of any such use cases. -dann > -- > Steve Langasek Give me a lever long enough and a Free OS > Debian Developer to set it on, and I can move the world. > Ubuntu Developerhttp://www.debian.org/ > slanga...@ubuntu.com vor...@debian.org > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: OpenGL to OpenGL ES change on arm64?
On Friday, June 3, 2016, Dann Frazier wrote: > [ Reorganized to use inline replies ] > On Fri, Jun 3, 2016 at 12:49 PM, Kevin Gunn > wrote: > > On Fri, Jun 3, 2016 at 10:47 AM, Matthias Klose > wrote: > >> > >> LP: #1586026 asks for the removal of binary packages on arm64 which > cannot > >> be > >> built with OpenGL ES. Do we really have to cripple an architecture like > >> this? > >> I don't see any discussion about this. How does this affect things like > >> GPU > >> accelerators and CUDA aware packages? > > > > hey Matthias, > > after reading the bug, it's implied the binaries being asked for removal > > were somehow built with gl (possibly sw implementation of gl?)please > > cmiiaw > > > > as to the request, never say never, but at least i've never seen an arm > > chipset in the wild with a gl enabled gpu (like the bug indicates they're > > all gles). > > so i'm not sure of the value of having those binaries present where at > least > > in real application, there's no gl ? > > Ubuntu supports a growing number of ARM servers that have PCIe slots, > so external GPUs can be added. CUDA is supported on those platforms > upstream: > https://developer.nvidia.com/cuda-toolkit-65 > And I do know there are users interested in CUDA on Ubuntu/arm64. > > I'm not experienced with CUDA myself - and don't have a card to test it - > but > it would be good to know if we're breaking that use case ahead of time. > >-dann > That's fair enough. I guess that's back to the original statement about "Do we really have to cripple an architecture like >> this?" It's not about the arch per se it's more about having offerings that match Gpus attached to that arch. So does it make sense to leave them in place and just know you'll have build failures in some cases? -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: OpenGL to OpenGL ES change on arm64?
On Fri, Jun 03, 2016 at 01:03:53PM -0600, Dann Frazier wrote: > [ Reorganized to use inline replies ] > On Fri, Jun 3, 2016 at 12:49 PM, Kevin Gunn wrote: > > On Fri, Jun 3, 2016 at 10:47 AM, Matthias Klose wrote: > >> LP: #1586026 asks for the removal of binary packages on arm64 which > >> cannot be built with OpenGL ES. Do we really have to cripple an > >> architecture like this? I don't see any discussion about this. How > >> does this affect things like GPU accelerators and CUDA aware packages? > > hey Matthias, > > after reading the bug, it's implied the binaries being asked for removal > > were somehow built with gl (possibly sw implementation of gl?)please > > cmiiaw > > as to the request, never say never, but at least i've never seen an arm > > chipset in the wild with a gl enabled gpu (like the bug indicates they're > > all gles). > > so i'm not sure of the value of having those binaries present where at least > > in real application, there's no gl ? > Ubuntu supports a growing number of ARM servers that have PCIe slots, > so external GPUs can be added. CUDA is supported on those platforms > upstream: > https://developer.nvidia.com/cuda-toolkit-65 > And I do know there are users interested in CUDA on Ubuntu/arm64. > I'm not experienced with CUDA myself - and don't have a card to test it - but > it would be good to know if we're breaking that use case ahead of time. I agree that CUDA should be a concern on arm64. However, this bug report is about changes to the Qt GL stack on arm64. Qt is a GUI toolkit; I don't see any reason that building Qt for GLES instead of GL should impact CUDA, do you? And while ARM64 servers have PCIe slots and can take GPUs, I don't expect this to mean that we want to support a desktop stack in such a configuration. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: OpenGL to OpenGL ES change on arm64?
[ Reorganized to use inline replies ] On Fri, Jun 3, 2016 at 12:49 PM, Kevin Gunn wrote: > On Fri, Jun 3, 2016 at 10:47 AM, Matthias Klose wrote: >> >> LP: #1586026 asks for the removal of binary packages on arm64 which cannot >> be >> built with OpenGL ES. Do we really have to cripple an architecture like >> this? >> I don't see any discussion about this. How does this affect things like >> GPU >> accelerators and CUDA aware packages? > > hey Matthias, > after reading the bug, it's implied the binaries being asked for removal > were somehow built with gl (possibly sw implementation of gl?)please > cmiiaw > > as to the request, never say never, but at least i've never seen an arm > chipset in the wild with a gl enabled gpu (like the bug indicates they're > all gles). > so i'm not sure of the value of having those binaries present where at least > in real application, there's no gl ? Ubuntu supports a growing number of ARM servers that have PCIe slots, so external GPUs can be added. CUDA is supported on those platforms upstream: https://developer.nvidia.com/cuda-toolkit-65 And I do know there are users interested in CUDA on Ubuntu/arm64. I'm not experienced with CUDA myself - and don't have a card to test it - but it would be good to know if we're breaking that use case ahead of time. -dann -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: OpenGL to OpenGL ES change on arm64?
hey Matthias, after reading the bug, it's implied the binaries being asked for removal were somehow built with gl (possibly sw implementation of gl?)please cmiiaw as to the request, never say never, but at least i've never seen an arm chipset in the wild with a gl enabled gpu (like the bug indicates they're all gles). so i'm not sure of the value of having those binaries present where at least in real application, there's no gl ? br,kg On Fri, Jun 3, 2016 at 10:47 AM, Matthias Klose wrote: > LP: #1586026 asks for the removal of binary packages on arm64 which cannot > be > built with OpenGL ES. Do we really have to cripple an architecture like > this? > I don't see any discussion about this. How does this affect things like > GPU > accelerators and CUDA aware packages? > > Matthias > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
OpenGL to OpenGL ES change on arm64?
LP: #1586026 asks for the removal of binary packages on arm64 which cannot be built with OpenGL ES. Do we really have to cripple an architecture like this? I don't see any discussion about this. How does this affect things like GPU accelerators and CUDA aware packages? Matthias -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
