On Fri, 2008-11-14 at 14:08 -0600, Chris Adams wrote: > Once upon a time, Jeremy Katz <katzj@xxxxxxxxxx> said: > > 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. > > Having developers say "pound sand, go the hell away, we don't want you > to be able to do things the way you've been doing them for 10+ years" > doesn't help either. I'm saying (... and have been saying for years) "let's find the gaps in _functionality_ and get them fixed so we can have one way in the future". I also say that just because it's the way it's always been done doesn't mean it's the way it should be done. > A stack of daemons cannot be as reliable as ifconfig/route. Having a > stack of daemons running for something that will not change is useless. ... a modular kernel cannot be as reliable as a monolithic one. Having modules loaded at boot-time for something that will not change is useless. A dynamically generate /dev cannot be as reliable as a static one. Having /dev generated at boot-time for something that will not change is useless. A dynamically configured authentication stack cannot be as reliable as one compiled into my program. Using PAM for auth configs that will not change is useless. </snark> Seriously, there is ZERO reason that it "cannot be as reliable". Is it newer and maybe has some bugs? Sure. But that doesn't fundamentally say anything about the reliability. > I do care about the desktop, and I use NM on my notebook (not on my > workstations that have a single interface with a single static IP). I > have to shut it down on my notebook sometimes because it doesn't handle > some of my normal usage (multiple wired NICs, wired and wireless to > different networks, etc.). > > I just don't see it as being useful or desired on my servers. Any > daemon that isn't useful should be disabled (that is sysadmin 101). And *this* is the crux of it -- the definition of "useful". Given that we have a general, multi-purpose system for things that include both desktops *and* servers, there is a lot of value in having one method of doing things. And ultimately, the cost of a daemon (to me) isn't something that I perceive as high enough to be worth the cost of maintaining two entirely separate systems in parallel. Especially when you take into account the (continuously growing) stack of feature requests for it. Also, there's this weird "running daemons are bad" mentality which I'm not really sure what the right way to approach is. But it's one that I'm not sure how true it is in our current world of increasingly moving functionality out of the kernel and into userspace in which case you have to have something running in addition to the kernel. Maybe to try some examples -- irqbalance is a daemon and not in the kernel anymore[1], does that make it "not useful"? Or for another side, various kernel threads are really just daemons... maybe we shouldn't run them either? Would it make the sysadmin in you feel better if a) the "daemon" were in the kernel as a kernel thread b) the daemon were auto-started in rc.sysinit (or equivalent) and thus wasn't seen as a "enable-able/disable-able service" and more "system functionality"? Jeremy -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
