On Fri, Dec 14, 2012 at 01:35:49PM +0100, Philipp Kern wrote: > On Fri, Dec 14, 2012 at 12:18:31AM -0800, Steve Langasek wrote: > > (Furthermore, I think the whole idea of needing custom desktop > > infrastructure to tell apps whether they're online or not is silly; > > you're online if you have a default route. [...]
> I know that you put it in braces because it's not your main point. Still > I don't think this is true. Other proprietary (and some open) OSes now > have elaborate measurement facilities to check if they're online. They > detect captive portals and tell you to login, they detect if just IPv6 > is broken, but IPv4 works, the other way around, they might even detect > if DNS64 and NAT64 are in use. (Coming from an IPv6 background.) > I don't want applications to be stuck connecting to stuff if they're not > really online. Obviously TCP will retry the handshake for some time > but it will still require manual action of reconnecting pidgin if > the network access is finally granted. On the other hand one could > argue that the network resources pidgin would need could already be > available when there's no default route. > So centralizing the knowledge what it takes for a network connection to > be considered up (for which n-m gives you basic means like requiring > IPv4 and/oror requiring IPv6 to be up on a given interface) makes a lot > of sense. And it could still be improved. Fair point. The main idea I was trying to express wasn't that having such a higher-level network connectivity service was somehow redundant or useless, but the importance of failing *open* when the service is absent or operating with incomplete information. -- 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 Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
