On Thu, 20.10.11 07:46, Matthew Miller (mattdm@xxxxxxxxxx) wrote: > > On Mon, Oct 17, 2011 at 07:10:04PM +0200, Lennart Poettering wrote: > > In general doing something like this is a bit backwards since networks > > come and go and come and go in todays world, and we also don't want to > > This seems like a very desktop-focused view of things. I appreciate that > that's important, but please keep the server room in mind as well. In our > environment, the network is like electricity -- if it's down, nothing is > running. Having the software designed to be robust against unexpected > network glitches is very useful, but if design decisions are constantly made > with the assumption that networks are a random transient resource, we'll end > up conceding our place in the data center in exchange for an incredibly tiny > slice of the desktop pie. If software can deal with networks changing then this benefits everybody, regardless which use case you have, i.e. whether it's a server, a desktop, a laptop, a tablet or whatever else. While network configuration is fairly static for servers, and very dynamic for tablets, it's not a binary thing, and you get everything in between too. Note that while servers seldom move physically, the network configuration might still change from time to time. If we make our software robust to deal with network changes, then we make its usage on servers more robust as well for the cases where the admin accidentaly trips of a cable, or he readjusts the wiring, or he renumbers his hosts, or renames, them or moves them to a different domain, or introduces a new DNS server, and so on, and so on. And that writing software that can deal with network changes is a good thing and doesn't make it useless for the server use case you can see by looking at bind, a service that much of the internet is running on and that is running in numerous enterprises, and that since a long long time listens to netlink and readjusts itself to network configuration changes. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel