On Fri, 16 Apr 2010 10:46:55 -0500 Aaron Griffin firstname.lastname@example.org wrote:
On Fri, Apr 16, 2010 at 10:05 AM, Thomas Bächler email@example.com 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.