On Thu, Jul 22, 2010 at 8:52 AM, drago01 <drago01@xxxxxxxxx> wrote: > On Thu, Jul 22, 2010 at 3:22 PM, Matthew Miller <mattdm@xxxxxxxxxx> wrote: > >> (And >> that those who have to pay this cost are "crying".) > > Everyone has to pay this cost and everyone gets something in return. That's not what you are hearing from the system administrators on the list - especially those that manage larger groups of systems, or manage systems where there are several distributions in place. For the sysadmins who manage large groups of systems, what is the inherent benefit to systemd? All I've seen is alot of "hey, this is a cool feature and you should like it", and not alot of "this feature/capability will help with this specific problem". And there isn't much discussion on how implementing systemd will impact the traditional uses and implementation of a server system - things like: - application servers with connection pooling to databases to reduce response time. The "systemd manages the connections" seems to go against the current setups where the application handles manages the application server processes depending on parameters in the connection. How does the philosophy of having systemd start a process for each connection impact server response time for normal operations. Decreasing startup time is a nice-to-have - making sure the server responds as fast as possible during normal operations is required. - shared realms/shared memory for session tracking and inter-application communications - database startup and connections. I wouldn't want the Oracle or MySQL listeners start up with each connection, there's way too much overhead in that part of the process - monitoring (the port checking that many monitoring systems use will not work well with the "systemd manages the port and starts the service when it gets the connection" that I've seen described here. This is especially important when looking at high availability, where you need to know that you don't just get a connection, but you actually talk to the application that's supposed to be listening on that port. I'm sure there are other areas, but those are the first things that came to my mind. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
