On Thu, 20.10.11 07:46, Matthew Miller (mattdm(a)mattdm.org) 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.