That's because you can't change anything meaningful in WOW. And you can't really claim that distinction when there's quite that many instances of your gaming environment.
Well, actually finishing 'Death Toll' and 'Dead Air' for multiplayer (it's _almost_ there) would be nice. I mean, you can play them already, but don't tend to because they're not on the 'standard list' and you have to arse about to get them to work - which is far too much like effort when firing off random games.
Especially if their 'new' versus levels are them finishing the job on Dead Air and Death Toll.
If they finish those off 'for free' and choose to charge a bit for two entirely new versus campaigns, then I'd be a little more tempted, but I'd much rather see a free update (of course)
EVE is a strategy game. It's not quite obvious, but it is. There's resource management - isks, minerals, logistics, pilot, skills, morale. Fleet/command dynamics, intelligence gathering, diplomacy, politics and... well, a whole load of stuff really.
It's not 'screwing you over' when I blow up your ACU in Supreme Commander. Nor is it griefing to try and trash your mass economy. The control perspective is unique - you're a 'unit' with a possibility to become a commander at various tactical levels, based on how good you are at it, and how well you can 'lead'.
Oh damn those players for competing with you. It's outrageous that there I am when playing chess, trying to make neato patterns on the chessboard, and then some fink comes and captures my queen! My pretty patterns are ruined, and they're totally only doing it to screw me over.
The biggest one being the players - they provide some of the content, and... well, lets face it, someone using rather strong/graphic language isn't exactly uncommon in a multiplayer game.
To be fair, it's not just America - corporate arse-covering, deceit and weasellyness are rife - being ethical is just fundamentally not compatible with 'big business' - full compliance with every regulation out there is next to impossible, so you end up having to 'fudge' them here and there, and from there... well, if you're fudging one that's 'ok' then why not fudge a few more that are just a pain to deliver on.
It's heartstoppingly easy to drop 'inconveniences' into the sea of bureacracy - most of which generated by the very legislation that's intended to protect against it. And for the odd occasion where that doesn't work? It's far more cost effective to scapegoat someone, and if you absolutely have to, pay them off in the process.
Now, in a room full of corrupt weasels, who do you think is higher on the list of scapegoats? The upstanding and ethical individual, or the rest who are prepared to sell him down river because that's better for them?
And if you're lucky, your pieces of silver will be enough to cover the fact that you'll never work again in the industry. Like it or not, no company will hire someone who's already ratted someone out - being certain you have no dirty laundry is next to impossible, so why take the risk on a fink?
It's much the same as taking someone to an employment tribunal - theoretically you have the right to kick up a stink about your rights. Practically, you're making massive career limiting maneuvers by doing so.
You know, if you go through life actually believing what you've just posted, you're either a sociopath or someone who is going to end up a sociopath's bitch.
Indeed. Whilst I've learned to tolerate some of the more common abuses of spelling or grammar, the difference between 'could' and 'could not' seems... well, rather fundamental to the meaning of the statement.
Anything that ties to a configuration attribute of your system is flawed. That's why configuration databases exist, and why we invented DNS in the first place - because accessing a system by it's mac or ip address wasn't very 'human friendly'.
That situation hasn't changed, no matter how much managers like nice neat looking spreadsheets.
Why are you trying to do that though? Use a configuration database to track your config, don't try and compress data into the hostname. We have hostnames in the first place, because their IP address or MAC address aren't particularly easy for a human to understand.
I'll put it to you like this. Why do you think we have a phonetic alphabet?
The reason we break it down to longer, but 'discrete' words is minimising transposition errors.
If I typo 'prod01' then with your naming convention there's several situations where I could end up with another hostname that's 'valid' with a single character error. Doubly so as numbers on a keyboard are close together, making it even more likely.
Where if my production servers are 'harry' and 'fred', then there is _no_ danger of doing this.
Your at least are pronouncable though, which is better than some I've seen.
It's not like re-imaging is necessary if you set up a box right in the first place. Or indeed that there is any need to keep one service per server - computers are quite clever, they can do several tasks at once.
More importantly, who cares? Your admin staff refer to hostnames, and to them having something uniquely defined and not prone to transposition errors is good.
Everything else, you've got a config database for. Or aliasing. Or hierarchical naming structures.
The more dynamic your environment, the less static naming based on a server attribute makes sense.
Well said. Compressing your config database into the host name is just not very clever. Aliasing based on 'ways you might want to access this system'... well, just makes so much more sense.
I have worked in places that named stuff for the sake of standardization. We have much the same thing as regards naming as you. The reason it frustrates me, is that the hostname is _not_ the place to be doing that - use your asset database to describe important server information. Use the name service + aliases to define what groups it's in, and what services run on it.
A hostname _needs_ to be sufficiently unique that you can understand it across a noisy datacentre.
Aliases and configuration management is where it's appropriate to record server attributes, not in the hostname.
By all means put a dns alias in for your server called budgie, such that you can hit is as 'mailserver1.company.com', or for that matter 'slot22.rack44.datacentre3.company.com', or 'pop3.company.com'. Maybe even 'budgie.linux.company.com'. But don't start trying to compress this information into your 8 character hostname - it's just plain doomed to failure.
I have a naming scheme, that has a whole list of server names that are virtually identical.
The reason we have this naming scheme is because it looks good in a spreadsheet. At best we get to pick that it's a generic application server, and a location for it. Y'know, the kind of thing that would be dead easy to get from the fact that it's also in.apps.site.company.com
There's far too many people making these decisions based on a 'flat file' approach to naming, when we've been able to to hierarchical for ages.
Hamming distance is communication theory to prevent transposition errors - it states that two symbols should be more than a certain distance apart to increase correctability of errors. A long list of nearly identical server names defeats this quite nicely, and ends up with you wondering if they said 'app47b' or 'app47d' in a noisy datacentre.
Slashdot Mirror
That's because you can't change anything meaningful in WOW. And you can't really claim that distinction when there's quite that many instances of your gaming environment.
And as for metagaming, sorry BoB ain't the kings of that - Goons are just as frequently doing that kind of thing.
Correct me if I'm wrong though, but doesn't that mean everyone joining your game can use cheats, and do massively irritating things?
Well, actually finishing 'Death Toll' and 'Dead Air' for multiplayer (it's _almost_ there) would be nice. I mean, you can play them already, but don't tend to because they're not on the 'standard list' and you have to arse about to get them to work - which is far too much like effort when firing off random games.
If they finish those off 'for free' and choose to charge a bit for two entirely new versus campaigns, then I'd be a little more tempted, but I'd much rather see a free update (of course)
Token cost for DLC is acceptable - 'expansion pack' pricing isn't.
It's not 'screwing you over' when I blow up your ACU in Supreme Commander. Nor is it griefing to try and trash your mass economy. The control perspective is unique - you're a 'unit' with a possibility to become a commander at various tactical levels, based on how good you are at it, and how well you can 'lead'.
That's why I like EVE.
Oh damn those players for competing with you. It's outrageous that there I am when playing chess, trying to make neato patterns on the chessboard, and then some fink comes and captures my queen! My pretty patterns are ruined, and they're totally only doing it to screw me over.
The biggest one being the players - they provide some of the content, and ... well, lets face it, someone using rather strong/graphic language isn't exactly uncommon in a multiplayer game.
To be fair, it's not just America - corporate arse-covering, deceit and weasellyness are rife - being ethical is just fundamentally not compatible with 'big business' - full compliance with every regulation out there is next to impossible, so you end up having to 'fudge' them here and there, and from there... well, if you're fudging one that's 'ok' then why not fudge a few more that are just a pain to deliver on.
It's heartstoppingly easy to drop 'inconveniences' into the sea of bureacracy - most of which generated by the very legislation that's intended to protect against it. And for the odd occasion where that doesn't work? It's far more cost effective to scapegoat someone, and if you absolutely have to, pay them off in the process.
Now, in a room full of corrupt weasels, who do you think is higher on the list of scapegoats? The upstanding and ethical individual, or the rest who are prepared to sell him down river because that's better for them?
And if you're lucky, your pieces of silver will be enough to cover the fact that you'll never work again in the industry. Like it or not, no company will hire someone who's already ratted someone out - being certain you have no dirty laundry is next to impossible, so why take the risk on a fink?
It's much the same as taking someone to an employment tribunal - theoretically you have the right to kick up a stink about your rights. Practically, you're making massive career limiting maneuvers by doing so.
Sadly, being an idealist doesn't pay the bills.
So... a manager or an employee then?
The best 'response' post I've found so far is this one: http://incompetech.com/gallimaufry/care_less.html
Inlining the 'caring continuum' image seems to work rather well to get the point across.
That situation hasn't changed, no matter how much managers like nice neat looking spreadsheets.
Why are you trying to do that though? Use a configuration database to track your config, don't try and compress data into the hostname. We have hostnames in the first place, because their IP address or MAC address aren't particularly easy for a human to understand.
The reason we break it down to longer, but 'discrete' words is minimising transposition errors.
If I typo 'prod01' then with your naming convention there's several situations where I could end up with another hostname that's 'valid' with a single character error. Doubly so as numbers on a keyboard are close together, making it even more likely.
Where if my production servers are 'harry' and 'fred', then there is _no_ danger of doing this.
Your at least are pronouncable though, which is better than some I've seen.
That only works in a trivial case. In the real world, linking a configuration attribute of your system to the hostname isn't very clever.
Naming after function is why CNAMEs and hierarchical naming structures exist.
It's not like re-imaging is necessary if you set up a box right in the first place. Or indeed that there is any need to keep one service per server - computers are quite clever, they can do several tasks at once.
Everything else, you've got a config database for. Or aliasing. Or hierarchical naming structures.
The more dynamic your environment, the less static naming based on a server attribute makes sense.
Well said. Compressing your config database into the host name is just not very clever. Aliasing based on 'ways you might want to access this system' ... well, just makes so much more sense.
Both because of informational limitations, and because then you end up with a long list of names very prone to transposition errors.
I don't get why _anyone_ thinks a 'symbol' name is any use whatsoever.
A hostname _needs_ to be sufficiently unique that you can understand it across a noisy datacentre.
Aliases and configuration management is where it's appropriate to record server attributes, not in the hostname.
By all means put a dns alias in for your server called budgie, such that you can hit is as 'mailserver1.company.com', or for that matter 'slot22.rack44.datacentre3.company.com', or 'pop3.company.com'. Maybe even 'budgie.linux.company.com'. But don't start trying to compress this information into your 8 character hostname - it's just plain doomed to failure.
The reason we have this naming scheme is because it looks good in a spreadsheet. At best we get to pick that it's a generic application server, and a location for it. Y'know, the kind of thing that would be dead easy to get from the fact that it's also in .apps.site.company.com
There's far too many people making these decisions based on a 'flat file' approach to naming, when we've been able to to hierarchical for ages.
Hamming distance is communication theory to prevent transposition errors - it states that two symbols should be more than a certain distance apart to increase correctability of errors. A long list of nearly identical server names defeats this quite nicely, and ends up with you wondering if they said 'app47b' or 'app47d' in a noisy datacentre.