On Thu, 2011-10-20 at 07:46 -0400, Matthew Miller 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 you architect a system that accounts for networking changing states,
then it works for *everyone*. If you depend on networking always being
there, then it only works for some subset of users that have one type of
installation. Having one architecture and one codebase (that handles
both cases) generally means easier maintenance, feature addition, and
fewer bugs.
It's certainly not a desktop view of things; many desktops stay on a
desk and are always connected to a network. It's more a view that tries
to account for more use-cases than static networking scripts ever did.
But that doesn't mean it compromises the always-connected-never-moving
case either.
Dan