On Fri, 2008-11-14 at 13:13 -0500, Martin Langhoff wrote: > On Fri, Nov 14, 2008 at 11:08 AM, Jeremy Katz <katzj@xxxxxxxxxx> wrote: > > One of the things about progress and getting to a more mature *platform* > > that is suitable across a wide range of uses is change. I'm not saying > > that NetworkManager is perfect yet for the server needs. But having > > people that want to run a server say "pound sand, go the hell away, we > > don't want to run your new-fangled stuff" doesn't help us get to where > > it is. Maintaining two systems in parallel is very much a long-run > > losing position. > > I agree with the desire to maintain only one tool. However, NM is > extremely desktop oriented, and there seems to include no hint of an > intention to support the complex setups that are possible with the old > ifcfg infra. Really? Most of the work over the past couple of years in NM seems to be aimed at trying to support these cases as opposed to just the "simple" desktop case > Scripting is actually a great fit for network config policies. All the > NM goodies could be built into a much _much_ leaner program that can > orchestrate different network configurations dynamically (ifcfg > style). Right now it's a monolith -- I'm not tracking it closely, but > nm-tool is slowly getting some very basic functions, and there's no > scripting supported AFAICS. The NetworkManager dispatcher stuff has existed forever and is all about scripting. Not necessarily pre-interface bringup, but post. And depending on scripting slows things down and makes it a lot harder to have a deterministic view of what's been done. And rather than focusing on nm-tool and exactly what it exposes, it's probably more interesting to look at the dbus interfaces/daemon capabilities. Yes, I'll be one of the first to say it's painful to write code interacting with dbus :-) -- but, it is very flexible and then as what the real use cases that people care about become clearer, it's easier to write very lean, very specific tools to do what they need as long as the backend and dbus interfaces are sufficient Jeremy -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
