starting Fedora Server SIG

[Les Mikesell]

Bill Nottingham wrote:
> 
> (Not that I actually believe that, but there's a fallacy here of
> conflating anecdotes and the existence of bugs with 'never use this'.)

I've tried to avoid doing that.  Stuff happens.  But conversely, don't 
use that as an excuse for shipping a bad design.

> Frankly, the part of this discussion that confuses me is the insistence
> that "NetworkManager is not useful for some server-based configs" yields
> the conclusion that "NetworkManager is not useful for any server-based
> configs" (complete with FUD about what it actually supports doing, which
> is a lot of this thread as well.) And it's not just NetworkManager that
> this applies to - the same discussion came up in this thread about
> encrypted filesystems.

The reason the discussion comes up is that it is not clear how the new 
stuff is layered on top of standard interfaces and how to avoid using it 
when you don't want it.  And how to keep user-session related stuff from 
getting intertwined with things that are really server/services (like 
needing a session to interactively provide an encryption key on a server 
where this is likely to be impossible).

> Heck, if you go back far enough, people complained about why PAM
> needed to be added. And I'm sure I'm missing others. It gets to a point
> where the only solution that would seem to be able to placate all the
> diverse admin users would be to never change anything, and we could
> just ship the equivalent of Slackware 3.2 with security fixes and go home.

I still have quite a few machines running a 2.4 kernel. Nothing fedora 
currently adds would improve the services they provide.  What are you 
suggesting as the benefit to the incompatible changes where they aren't 
needed.  And what excuse is there to not provide backward interface and 
command line compatibility when adding new things?  If you can't support 
the old functionality, the change is probably not an improvement.

> I tried to give some examples above, such as ways to give notification
> to other apps/services when network devices go up and down that don't
> rely on them catching SIGIO and then trying to guess what happened.
> (That's the notification mechanism currently provided by the initscripts.)
> While it may not be useful for all service cases, it certainly can
> be useful for some.

How have snmp traps worked all these years? It isn't just things with 
access to dbus on the local machine that need to know about interface 
issues.

-- 
   Les Mikesell
    lesmikesell at gmail.com