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@xxxxxxxxx -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
