On Fri, May 30, 2008 at 3:38 PM, seth vidal <skvidal@xxxxxxxxxxxxxxxxx> wrote:Simo's point still holds though. What you've described above is a better
reason to have not designed nm around dbus not a reason why we should be
okay with our network services going away when we restart dbus.
If you want your operating system to be held together with shell script, duct tape, and ad-hoc use of Unix domain sockets that's cool, I'd rather have a reliable and stable system.
Let me reply with something a little less antagonistic - it's just frustrating because everyone sees "Oh another daemon, let me reboot it" and blames application developers, when it's just too hard of a problem to deal with.
DBus actually shares a lot of similarities with SCTP (http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol); it's a realization that message-oriented (as opposed to stream-oriented) is fundamentally more useful to applications. DBus just happens to be implemented in userspace, but that doesn't mean it's just another daemon, any more than TCP stacks that live in userspace in some old operating system designs could just be restarted at any time without any obvious side effects on the system.
Speaking of userspace kernel integration, I'd be pretty surprised if you could reliably stop the fuse service too; given all the discussion about nearly unfixable race condititons in rmmod that have (http://lwn.net/Articles/31474/).
Auditing every program and making them able to cleanly support restarts of system services like HAL, NetworkManager, and PackageKit would be a huge task, for similar reasons because these services build up state. It might sort of work most of the time, but what you *really* do not want is for the system to sometimes break when the user plugs in a USB key when the background package upgrade happened to restart the bus at just the wrong time.
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
