On Thu, Jan 8, 2009 at 2:19 PM, Timothy Murphy <gayleard@xxxxxxxxxx> wrote: > > The reason people are confused by NM is because > it is almost completely undocumented. > If something does not work it is doubly annoying > to be told that "it just works". What exactly are you looking for in terms of documentation? Or let me ask it another way. Is there any application that you can point to that uses GConf that you feel is well documented? NM uses GConf for configuration settings. is there any application that you can point to that uses gnome-keyring that's well documented? NM stores network credentials in gnome-keyring. Is there any service or application that uses D-Bus that you find is sufficiently documented? I do not think your confusion over NM is strictly a NM problem. I think its a paradigm shift problem around D-Bus as a critical system service. I think D-Bus is a paradigm shift in development that is happening much faster than sysadmins are really equipped to deal with adequately. I think all of the D-Bus related technologies which are superceding more traditional shell scripted approaches are breaking a lot of sysadmins muscle memory. Hal and gnome-mount, PolicyKit and ConsoleKit, and NetworkManager. I think all of these D-Bus utilizing technologies are confusing people, and I don't think the D-Bus centric paradigm has been adequately explained to sysadmins who are going to have to adapt and relearn to make sense of it. I think its something we should all muse over. D-Bus isn't going away and we need to find a way to help sysadmins find the benefit of these technologies over existing approaches. Have any of the D-Bus technologies started showing up in RHEL-centric certification training yet? That's going to be a watershed moment for sysadmin re-education. Once certs start requiring admins to know how to deal with NM or PolicyKit...etc.. then we'll gain some real traction on the sysadmin oriented documentation. > Has the classic network service improved recently? I've no idea. Doubtful. > I thought NM was introduced precisely because the old service > did not work properly. Work properly? the legacy tools wasn't designed for mobile roaming usage patterns as a target. You can get it to do what you want, but is it proper? What is proper anyways? Proper is relative to expectation. Expectations for servers and mobile devices are going to be different. 4 years ago I didn't have a computer that connected to 30 different wireless or wired networks over the course of a month. Now I do. And I'm not even an aggressive business traveller. NM aims to be a better solution for these sort of usage patterns as a primary function. Right now for me, and my usage patterns, since I do not run any services on my personal desktops and laptops, NM post-login network activity works perfectly fine for me and my commandline tools. My Centos 5.2 servers on the other hand are stilling using the older network service because they need network access at boot up..as they are servers. NM has a development roadmap, it includes pre-login system boot up. It takes time to implement that so the legacy network service will continue to be included in Fedora. We have come to a middle point in the evolution of the networking technology in linux where we have to support two different ways to do things, depending on the situation. We can only choose one of those ways as a default. NM is that default, because it best fits usage cases where the admin is going to be less comfortable doing reconfiguration. For situations where the legacy network service needs to be used still, the expectation is the admin will be able to figure out how to start the legacy network service if its not running by default. > I certainly found it infuriating. > I'm very grateful for NM, but don't really like to rely on magic. You'll have to pardon me, if I'm not particular empathetic to intense emotional feelings over the state of any software development. I reserve feeling intense rage for when sentient beings do something overtly malicious...like key my car when its in a parking lot. -jef -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
