starting Fedora Server SIG

[Jeremy Katz]

On Fri, 2008-11-14 at 14:08 -0600, Chris Adams wrote:
> Once upon a time, Jeremy Katz <katzj at redhat.com> 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