Re: Best place to discuss other lightweight libraries?

[Rich Felker <dalias@aerifal.cx>]

On Tue, Apr 23, 2013 at 05:50:23PM -0400, Kurt H Maier wrote:
> On Tue, Apr 23, 2013 at 09:47:24AM -0400, Rich Felker wrote:
> > 
> > 1. Choosing which network to connect to.
> > 2. Managing keys.
> > 3. Logic for what to do when signal is lost.
> > 4. Automating nonsense click-through agreements on public wifi.
> > ...
> 
> wpa_supplicant can do 1., unless you mean choosing between ethernet and
> wifi.  but it supports priority weighting on access points..

OK.

> 2. is pretty trivial since you can easily wpa_cli >> /etc/wpa.conf or 
> similar.  I've never been sure why typing 'dhclient eth0' is seen as
> more onerous than running a polling daemon to save you the trouble.

Because you don't have a keyboard, you have a 3-4" touchscreen. And
you want it to keep working as you move from place to place without
any interaction.

> Can you elucidate more on 3?  if the signal is lost, wpa_supplicant
> rescans and connects to any configured network, or else sleeps and
> rescans later.

I'm not sure what the ideal behavior is, but I know all the existing
ones have bad behavior.

> 4. will never be solved satisfactorally, since that garbage is not
> predictable.  the database of tedious TOS crap will never stop
> expanding.

Agree, but it still needs to be solved, even if the solution requires
frequent updates to be fully effective. With decent heuristics though
I think it could be fully automated for most sites with just a few
exceptions for really weird ones..

> > 4. Minimal or no auto-click-through; even when it does work, you can
> > get burned if your web browser happens to attempt a load before it
> > succeeds. A correct one needs to encapsulate the connection somehow so
> > that no connection is exposed to the user at all until the
> > click-through succeeds.
> 
> There are lots of useful things that can be done with this concept of an
> encapsulated connection.  I get burned by this on my work laptop, which
> likes to spam VPN connection attempts back to corporate.

Agreed. I think really most users should _always_ be running in an
environment where only root sees the real network interfaces and
applications just see a virtual network routed through the real one.

Rich