On Tue, 2006-01-10 at 03:40 +0000, David Woodhouse wrote: > What I object to is the fact that it no longer supports the _normal_ > form of operation, where the network is a system-wide resource, set up > automatically at boot time. I have to actually log in and enter a > password now in order for my machine to connect to the network, and > that's a serious regression. I've maintained all along that if users and/or administrators wish to delegate keys to all users of the system, that's quite acceptable. What's _doesn't_ exist right now is a mechanism to store those keys in a system-wide location, and to give those keys to NetworkManager on demand. Stuff we've tossed around: 1) GConf: either through mandatory/default settings, or a 'nobody' user's GConf settings, a system-wide org.freedesktop.NetworkManagerInfo service runs from bootup to shutdown. When a user-session asks for the service, the system-level one gives the service up. It reacquires the service when the user-level service drops. It provides default/system-wide settings to NetworkManager just like the user-session one does. 2) Text files in /etc like we have now. Haha. No way. 3) Some other system-wide configuration framework. Sure, as long as its not text files in /etc like we have now. The nice stuff about GConf and everything else is that it's -structured- and easily accessed by a sane API. I don't want to write text-file parsing tools for every damn thing that needs system-wide config access. (1) has to happen anyway for power management too, how do you manage power if nobody is logged in? Again, system-wide settings and prefs. But to keep a consistent architecture and not build different system-settings parsing crap into every daemon, we have a nicer option in the dbus-enabled world. But then again, why can't these daemons that need network on boot start _not_ needing network on bootup? Why can't they gracefully fail when they don't have network, and do whatever they do when the network shows up? Yeah, it's new to lots of people that a Linux system just might not have networking 100% of the time, but that's the reality client-side, and daemon developers have to suck it up and deal with it. Dan -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list