[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: starting Fedora Server SIG



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 gmail com


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]