Once upon a time, Bill Nottingham <notting@xxxxxxxxxx> said: > How is NM-dispatcher a developer service? Similarly, nm-tool is > at least quicker than 'ip addr ls ; ip route ls ; cat /etc/resolv.conf'. Funny; when I opened my notebook just now, hald segfaulted and died and NM died for some unknown reason. Because of that, nm-tool was useless, but ifconfig still worked. The output of nm-tool is also not particularly parseable with a script, while ip has a good clean list. How would a system admin even configure NM? Where do I go to add an alias, a new route, or a new GRE tunnel? > As for resources... just to point out that NM (at least on my laptop) > uses 2.5MB resident... pretty much exactly the same amount as the 5 > unused mingetty processes that many 'server' admins screamed needed to be > kept always. I turn off unused gettys anyway, but that's not what I'm concerned about. The more daemons I have to have running, the more bugs that can break things, the more possible security issues there are, etc. How is a daemon (or set of daemons) useful for a static configuration that does not change? For the vast majority of my servers, the network config is set in the kickstart %post and not touched for the life of the server (which is typically many years; I've got a RHEL 3 server that hasn't had a network change since Feb 2004 for example). For servers, the simpler solution (that meets the needs) is always better, and running multiple daemons to configure the network is definately not simpler than a text file and "ifup". -- Chris Adams <cmadams@xxxxxxxxxx> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
