The downside of distinctive hostnames

February 23, 2007

Recently a co-worker pointed out that the downside to giving machines distinctive hostnames is that users become attached to them, and when you introduce newer, better machines the users don't migrate to them. Once I thought about it, this made sense; after all, by naming things we make them distinct, and thus no longer quite so generic and equivalent.

(At this point I am tempted to think thoughts about brand loyalty and the distinctiveness of brand logos.)

One contributing factor is that with many generic naming schemes it is very easy to derive a bunch of machine names from a single memorized one. If I remember 'cluster3' I can easily predict that there is probably a 'cluster5' I can also use; the same is not true of a name like 'epoch'.

In hindsight, I've seen this behavior in action before, for example at times when users are slow to migrate from a loaded server to a less loaded one. I even do this myself; I have no idea of which of our Linux login servers is less loaded or faster, I just use the one I found first.

(As it turns out, I probably didn't pick the best one.)

However much I like distinctive hostnames, I was forced to admit that my co-worker had a convincing argument, so our future user visible generic machines are probably going to have generic names. (At least we won't have to come up with a suitable naming scheme.)

(Server machines that users don't use directly will probably keep getting distinctive names.)

Written on 23 February 2007.
« A simplified summary of Python's method resolution order
Some things to remember when implementing __getitem__ »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Feb 23 23:47:06 2007
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.