[arch-releng] wifi configuration (was: 2010.04.05 snapshots ready for testing)
dieter at plaetinck.be
Fri Apr 16 12:28:24 EDT 2010
On Fri, 16 Apr 2010 10:46:55 -0500
Aaron Griffin <aaronmgriffin at gmail.com> wrote:
> On Fri, Apr 16, 2010 at 10:05 AM, Thomas Bächler
> <thomas at archlinux.org> wrote:
> > Am 16.04.2010 16:53, schrieb Aaron Griffin:
> >> Hm? I added my network to /etc/wpa_supplicant.conf, and ran
> >> wpa_supplicant -Dwext -something something something and the dhcpcd
> >> wlan0, and everything worked as expected. I'm not sure what you're
> >> talking about here
> > You did so _manually_. So basically you launched wpa_supplicant,
> > waited until it associated (or waited some time in the hope
> > association would be quick) and then ran dhcpcd.
> > If you want to use wireless on a daily basis, automating that
> > process is a necesity. I worked on that with autowifi and recently
> > ported everything I did over to netcfg-auto-wireless.
> > Autowifi actually works by configuring wpa_supplicant manually like
> > you suggest, but I deprecated that in favor of the more intuitive
> > configuration via network profiles that is now used in
> > net-auto-wireless.
> > What I am saying is, you cannot just launch wpa_supplicant and then
> > dhcpcd and expect it to work without further regard for connections
> > being established and lost, wireless networks being changed and so
> > on. We should encourage users to use these mechanisms implemented
> > in netcfg already during the installation - that is why I want to
> > encourage them to create netcfg profiles during installation. If a
> > user insists on messing with wpa_supplicant and dhcpcd manually,
> > then (s)he can do so, but it's not necessary to add this to the
> > installer as a recommendation when there's a superior method
> > available.
> Ok, I'll give you that. But I still fear an over-reliance on netcfg.
> The reason is that it is not "portable knowledge" and is only useful
> on Arch systems. This is one of the things is dislike about
> Debian/Ubuntu - a lot of the configuration stuff they do is unique to
> the system and that knowledge doesn't transcend operating systems.
i don't really use netcfg myself, but the explanation Thomas has given
above doesn't seem too arch specific; and from a quick glance at
http://wiki.archlinux.org/index.php/Netcfg it seems netcfg is not - or
at least should not have to be - very arch-specific. maybe we should
treat it more as a separate project (like pacman or libui-sh) and
integrate it into our initscripts like we already do.
Also there's this duality for a while that our networking initscripts
are really basic and limited, and netcfg should fix all that, but it's
not very "official" or "recommended" or whatever. maybe it's time to
unify things into 1 networking configuration utility (which, still
doesn't need to be bound to arch linux), it will make things easier for
everyone. so we could only use netcfg and drop the other limited stuff.
More information about the arch-releng