One problem I see, specifically for the environment, is that "dev" is now a TLD (thanks Google!), so you have to be careful should you try to do a short cut like "web01.dev" you may get a surprise depending on your resolv.conf:
The article describes geographic sub-domains, and uses "nyc" as an example, but that's a TLD now as well. It may be better to use UN/LOCODE as a starting point:
Once I was moved to a new team at work, and the team leader really wanted a team name. I generated like 5 or 10 words from /usr/share/dict/words, one of which was profanity. I could tell that everyone liked Team Profanity, but no one was brave enough to adopt it. I really wish we had, because there was much cursing on that team.
I really like the functional naming part of this, but I don't like the idea of using random names.. I think that server names must be functional otherwise you will tend to think of them as an abstract box that, if you just install that little extra package, will be a fine webserver on top of that mailer.
Don't do it! If you're labeling hardware and need multiple functions, use virtualisation or containers, and then the host is named after that (e.g. we use Ganeti, so gnt-01, or say kube-01).
At home, I name machines after inspiring political figures and while I like the naming, it does discourage me into treating those machines as cattle, which I should do more.
This kind of naming is fine for small projects, and personal setups. In professional settings I would suggest using descriptive names and rely more on DNS.
It's not that I don't enjoy fun and personal naming schemes, it's just that it's a constant annoyance when dealing with a large number of different systems.
We've been hired to deal with different companies, who picks some random naming, cars, athletes, plants, cities and so on and it's confusing as hell. How am I suppose to remember that Ford and Volvo are your two web servers? Now I need to maintain a list mappings for your servers and look them up every time I need to change your web configuration. Just call them prod-web01.company.com and prod-web02.company.com, it's fine and everyone will be able to guess what those servers do.
You can also do web01.prod.company.com and web01.test.company.com, but while it looks cleaner (and I personally prefer it) is does hide the "prod" or "test" in most shells, so you constantly need to check that you're not messing with a production box.
Functional names for servers are IMHO one of the worst possible options, because functions drift over time.
Have individual hw named in unique way that isn't related to functionality it runs, then use CNAMEs specific to functionality - i.e. never point a DNS client at "freddy.dc.somecorp.com", you point it at "dns01.dc.somecorp.com".
The decision on what machines need unique names, not just pseudorandom IDs or similar crap, is well described by another comment here https://news.ycombinator.com/item?id=26054487 - which I like to put as "named systems are the systems you care about"
In fact, I'll go with seemingly unpopular opinion that there are only pets, never cattle. The pets just happen to have components, but at some level of the stack you're hitting a precious pet. Even if said pet is "us-east-1 Lambda service"
Cute naming schemes are a holdover from the days of physical servers when location, function, etc were subject to change so an immutable machine name couldn't contain them. Now that most things are virtual and easily created/destroyed there's no good reason _not_ to name functionally. The most common refrain I've heard in defense of these archaic naming practices is that "we don't want the hackers to know which server does what" but if they've managed to get your root DNS zone file or a shell on a box then you're already pretty far gone anyway (not to mention that nmap exists). All it does is impede productivity and create the illusion of security.
If you are dealing with assets in a physical environment then obviously the above doesn't apply.
As a side note: a long time ago (before I knew what I was doing) I ran a Windows Server environment for my dad's business. The main server was Jake and the off-site backup was Elwood.
You'll need a mapping for the server names anyway. If you have a large datacenter, I hope it's stored as configuration of your infrastructure as code tool, if it's small, you won't need to check it every time.
Anyway, is prod-web01 that server with an outdated web server that you keep because of that one system that couldn't migrate, the one with a Java server that runs those proprietary tools, the one with IIS that runs that FOSS code that the developer decided to write in C#, the one supporting your main applications or the one you insulated in a special network because it hosts a powerful API that you don't want to expose?
"prod-web02" implies that this is the second web server in a cluster of web servers. That makes a lot of sense in 2021, where "prod-web02" is likely an AWS instance or a docker VM that is doing nothing but serving web pages, and which exists in some cloud server where you will never see the physical machine it is running on.
This was written in 1990, though, and there was no cloud, and VMs were quite rare things, (and we had to walk to school uphill, both ways, in the snow). Machines were physical things, and no one had the budget to buy an entire computer to be the second production web server - a machine ran a lot of different daemons that did a lot of different things, and the roles and responsibilities of a given physical piece of hardware would change as time went on. Which is still true today, but today it's just that a machine runs a lot of docker containers instead of running a lot of daemons, and we don't care where the docker containers are running, whereas back then we very much cared what machine it was running on, because sometimes we had to go to that machine and reboot it or kick it or install more RAM.
At the time, I was working at Alcatel (before it was Alacatel-Lucent, before that became Nokia), on a 450Gbps switch which was used for things like routing satellite TV feeds or handling distribution from big fiber backhauls, or running LANe for small nations. On the third floor, we had several racks of these switches in "the lab" which we used for testing and development work. While you could push a new software load from the comfort of your desk, if you borked things badly enough you'd sometimes have to go downstairs and plug a serial cable into the front of the control card so you could go poke around and force the card into a sane state.
So, when a new hire came in, they might say, "Hey mrweasel, I uploaded a bad load to Spock, and it's stuck in a boot loop. Where can I find that physical machine?" And you'd say, "Head down to the third floor, turn left out of the elevators, walk to the second last row of racks. On your left there should be switches named "Picard", "Riker", "Deana", etc..., and on your right should be "Kirk", "McCoy", and friends. Spock is third on the right between McCoy and Uhuru."
That conversation is way more confusing if all of these machines are named "test01-test20". You couldn't even name them that - there were lots of different products in different areas of the lab, so you'd need the product name in there, and they'd be "rsp7670-test01" through "rsp7670-test20".
And, when you want to push a new build from your desk, it's way less likely you'll mistype "picard" when you want to update "data", but it's quite easy to accidentally clobber "rsp7670-test05" when you mean to overwrite "rsp7670-test06", which was sure to summon an angry developer to your desk asking why you just killed their 48 hour validation testing, 45 hours in.
Best naming scheme I ever saw was at Harbinger in the late nineties. They used the periodic system. The last octet of the IP address corresponded to the atomic number, and you could use the full element name, or the abbreviation. So carbon.harbinger.com was x.x.x.6 and c.harbinger.com was a CNAME to carbon. oxygen or o was .8 etcetera.
> So carbon.harbinger.com was x.x.x.6 and c.harbinger.com was a CNAME to carbon. oxygen or o was .8 etcetera.
No wonder helium was mostly hanging ...
Sorry, could not resist. It is a clever naming scheme. At one site a client used names from The Three Stooges, then they got the 6th server (exhausting the list of the lead characters).
One company that I worked at... while the hardware people had their boring "r17s4ad" type name (rack 17, shelf 4, application, development), our team used the naming scheme of Caribbean islands. This worked rather well.
Unfortunately, I only remember the test and production server names. The test systems were "Trinidad" and "Tobago". The production systems where "Nevis" and "Nassau" (the app started with an 'N').
The thing that made this work really well was that the first syllable hinted on what the rest of the word would be and then everything beyond that reinforced that you read it right. This even was the case that foreign accents, while slightly off still reinforced the "you heard this right".
The machines _also_ had names of "test01" and "test02" or similar... but we (as devs) never used those names because you had to listen to the end of it to be sure that you had the right machines.
Alternative method for Arch Linux: Install the `rfc` package, then find the RFC at /usr/share/doc/rfc/txt/rfc1178.txt. A very nice package to have installed when travelling far from an internet connection.
> Nobody expects to learn much about a person by their name.
That's a good point, but humans are very different to computers - machines (be they physical or virtual) are provisioned for a specific purpose (even if that is to be "Fred's PC"), whereas humans need time to grow and can decide for themselves what to do as a career / what their hobbies will be, and change it any time.
But realistically, yes, the RFC is right that you may end up with machines whose purpose changes or multiple machines have the same purpose etc. But when they don't, it is much easier to have meaningful names. If you will name them differently, then please make sure all developers can access the list/mapping document and it is kept updated. It's frustrating if you want to investigate some production problems but end up looking at the wrong server's logs because devops didn't tell anyone they moved an application /website etc.
I like someone else's comment about app01 being easier to reason about and recreate than something named more specifically, and in the modern world, its easy to spin up a new docker instance or VM so there's less need to "let's just add this small service on that machine because it has spare capacity" (where capacity could be CPU/RAM etc.)
A long-time personal favourite naming scheme of mine has been Pokemons (and by extension, Digimons).
There's a good selection, it's pretty varied and there's no shortage of em (assuming you don't exceed 100-200 new systems in a 3 year period). This also has an accidental side-benefit of not being tasked to name new hosts at work, unless your really want to call the new database server Stufful, for example.
Another thing to keep in mind with more descriptive hostnames like `database`, is to serialize them from the start. It's a very minor thing but after you have three hosts with one of them missing the serialization, it's going to stand out like a sore thumb and it could be a major undertaking on changing that name where it's used.
When it comes to project names, there is a certain level of permanence that name (or codename) is going to have. Once chosen, that name will be thrown around in the codebase almost universally. The same does apply to the hostnames, at least in part when it comes to configuration files (and by extension, certain hard-coded hostnames that could linger around in the code years after the host in question has been decommissioned).
> When it comes to project names, there is a certain level of permanence that name (or codename) is going to have. Once chosen, that name will be thrown around in the codebase almost universally. The same does apply to the hostnames, at least in part when it comes to configuration files (and by extension, certain hard-coded hostnames that could linger around in the code years after the host in question has been decommissioned).
The weirdest naming scheme for computers I've seen is the one used some years ago by my college: It named Linux workstations after Linux kernel committers' email usernames!
There were the better-known folks like linus (Linus Torvalds [1]) and gregkh (Greg Kroah-Hartman [2]), but also relatively more obscure people, like shemminger (Stephen Hemminger [3]) and stelian (Stelian Pop [4]).
I didn't recognize most of those names at the time, but now that I do, I wonder what those people would have thought about having a large organization's computers named after them. A bit creeped out, I would think.
The most sensible naming scheme for us was to distinguish them by index. But there were two important differences: TPUs have many sizes, which means some are larger than others; if you're using a v3-256, you're very likely the only researcher doing so. They are also distinguished by type; v3 is more powerful than v2. Finally, they are region-based; the less powerful v2's are in the US, whereas the v3 fleet is mainly EU based.
That led to the convention of tpu-v3-8-euw4a-1, tpu-v2-256-usc1a-0, and so on.
The "tpu-" prefix might seem redundant, but I find it's helpful in conversation. That's a personal preference though, and if I had to do it again I'd probably drop the tpu- prefix entirely.
I found this scheme was horrible for VMs though. TPUs are often used for specific training runs, and the scheme above is easily added to bash files / config scripts. But for VMs, you're often SSH'ing into them all the time.
Ultimately we started naming the VMs after the researchers who originally needed them. Our current primary training box is song.tensorfork.com, named after researcher songpeng who it was created for. So the SSH scheme was pleasant: [email protected] for him, [email protected] for me, arfa@, aydao@, etc.
When arfa neded a VM, I simply named it arfa.
All other more complicated naming schemes failed with time. No one (including me) could remember long VM names, let alone ones with numbers in them.
The other scheme that persisted was to use anime characters, as emersion mentioned. Tensorfork itself runs off of vegeta, which is my personal Hetzner server. "goku" was one of our primary workhorses at one point, due to its large VM size.
Our final two VMs are named "test" and "nuck", which also seem to work quite well (much to my surprise). "Is test down?" is almost completely unambiguous. And it's easy to remember which one is which: "nuck" is in Canada, so therefore "test" is the one in europe.
A pattern emerges here: most of our VM names are short, four-letter identifiers: arfa, song, test, nuck, goku, with vegeta being the standout. All other conventions failed with time.
For personal stuff (and even early machines for some companies which blurred the lines) I always chose the names of forests in the Magic: the Gathering multiverse. I try and help keep this page updated purely for that purpose:
These days, for work, it’s just boring unambiguous stuff. I think with more cloud infrastructure and the rarity of shared unix servers with home directories for people, it’s rare that I have any emotional investment in a machine. They’re basically soulless now.
To date, Dryad Arbor is still one of the coolest cards in MtG, simply because of both the simplicity and the universality of its quote. When it came out, I was very surprised by the idea that a land could also be a creature. These days we have way wonkier mechanics, but that novelty along with the quote has a special place in my heart.
For personal machines I use fiction locations from media I enjoy. My laptop is Hyrule, my desktop is Konoha, and my Pi is MotherBase, but I spell mine all lowercase.
For servers I use for my roommates and I (Jellyfin and the like), we name them after the quirky students that go to our university that we appreciate.
It's easy to be nostalgic for the days of big iron servers or clusters that were around for years as a sort of network landmarks. We used to have dev and QA clusters named after movie monsters and you'd get some great hallway conversations about who was using Godzilla that week.
Made for great mascot toys and posters on the rack doors.
That's a great scheme. I hope that one day amongst the university computer labs named for Greek/Roman mythology or rock artists, we have a lab of anime characters. At least at my uni, I think a lot of people would get a kick out of that.
For some reason, when doing a fresh OS install, the hostname step is the bottleneck and takes too long to complete. Distros should really prioritize optimizing this part of the installer!
Back when I was a sysadmin at a university CS department, we always picked namespaces for machines---everything in a given namespace had related names and were identical (or nearly identical) machines. If someone mentioned toque or glenfiddich, you could tell what lab they were in and what kind of machine they were.
I always wanted to use 'Starships from Iain M. Banks' science fiction', which is why no one ever listened to me.
For personal machines, I have been using adjectives that start with 'i'.
[+] [-] curtis3389|5 years ago|reply
I can't find the post that linked it, but it had a very nice scheme.
EDIT: found it: https://mnx.io/blog/a-proper-server-naming-scheme/
EDIT2: one-liner to get a random word from the file:
cat wordlist.txt | tail -n +2 | sed -E 's/\s*(\w+)\s+/\1\n/g' | sed -E '/^$/d' | shuf -n 1
i.e. <print file> | <skip first line> | <split lines into words> | <remove empty lines> | <choose random line>
[+] [-] throw0101a|5 years ago|reply
One problem I see, specifically for the environment, is that "dev" is now a TLD (thanks Google!), so you have to be careful should you try to do a short cut like "web01.dev" you may get a surprise depending on your resolv.conf:
* https://en.wikipedia.org/wiki/.dev
Lots of 'generic' TLDs now thanks to ICANN:
* https://en.wikipedia.org/wiki/List_of_Internet_top-level_dom...
There's both ".accountant" and ".accountants".
The article describes geographic sub-domains, and uses "nyc" as an example, but that's a TLD now as well. It may be better to use UN/LOCODE as a starting point:
* https://en.wikipedia.org/wiki/UN/LOCODE
If you don't need down to the city/municipal level, then ISO 3166-2 may be useful (<nation><hyphen><subnational>):
* https://en.wikipedia.org/wiki/ISO_3166-2
[+] [-] devoutsalsa|5 years ago|reply
[+] [-] gspr|5 years ago|reply
[+] [-] luckman212|5 years ago|reply
[+] [-] anarcat|5 years ago|reply
Don't do it! If you're labeling hardware and need multiple functions, use virtualisation or containers, and then the host is named after that (e.g. we use Ganeti, so gnt-01, or say kube-01).
At home, I name machines after inspiring political figures and while I like the naming, it does discourage me into treating those machines as cattle, which I should do more.
[+] [-] jsanders9|5 years ago|reply
It is fairly straightforward to incorporate into your infrastructure as code workflow for managing your "cattle".
[+] [-] mrweasel|5 years ago|reply
It's not that I don't enjoy fun and personal naming schemes, it's just that it's a constant annoyance when dealing with a large number of different systems.
We've been hired to deal with different companies, who picks some random naming, cars, athletes, plants, cities and so on and it's confusing as hell. How am I suppose to remember that Ford and Volvo are your two web servers? Now I need to maintain a list mappings for your servers and look them up every time I need to change your web configuration. Just call them prod-web01.company.com and prod-web02.company.com, it's fine and everyone will be able to guess what those servers do.
You can also do web01.prod.company.com and web01.test.company.com, but while it looks cleaner (and I personally prefer it) is does hide the "prod" or "test" in most shells, so you constantly need to check that you're not messing with a production box.
[+] [-] p_l|5 years ago|reply
Have individual hw named in unique way that isn't related to functionality it runs, then use CNAMEs specific to functionality - i.e. never point a DNS client at "freddy.dc.somecorp.com", you point it at "dns01.dc.somecorp.com".
The decision on what machines need unique names, not just pseudorandom IDs or similar crap, is well described by another comment here https://news.ycombinator.com/item?id=26054487 - which I like to put as "named systems are the systems you care about"
In fact, I'll go with seemingly unpopular opinion that there are only pets, never cattle. The pets just happen to have components, but at some level of the stack you're hitting a precious pet. Even if said pet is "us-east-1 Lambda service"
[+] [-] alexjplant|5 years ago|reply
If you are dealing with assets in a physical environment then obviously the above doesn't apply.
As a side note: a long time ago (before I knew what I was doing) I ran a Windows Server environment for my dad's business. The main server was Jake and the off-site backup was Elwood.
[+] [-] marcosdumay|5 years ago|reply
Anyway, is prod-web01 that server with an outdated web server that you keep because of that one system that couldn't migrate, the one with a Java server that runs those proprietary tools, the one with IIS that runs that FOSS code that the developer decided to write in C#, the one supporting your main applications or the one you insulated in a special network because it hosts a powerful API that you don't want to expose?
[+] [-] jwalton|5 years ago|reply
This was written in 1990, though, and there was no cloud, and VMs were quite rare things, (and we had to walk to school uphill, both ways, in the snow). Machines were physical things, and no one had the budget to buy an entire computer to be the second production web server - a machine ran a lot of different daemons that did a lot of different things, and the roles and responsibilities of a given physical piece of hardware would change as time went on. Which is still true today, but today it's just that a machine runs a lot of docker containers instead of running a lot of daemons, and we don't care where the docker containers are running, whereas back then we very much cared what machine it was running on, because sometimes we had to go to that machine and reboot it or kick it or install more RAM.
At the time, I was working at Alcatel (before it was Alacatel-Lucent, before that became Nokia), on a 450Gbps switch which was used for things like routing satellite TV feeds or handling distribution from big fiber backhauls, or running LANe for small nations. On the third floor, we had several racks of these switches in "the lab" which we used for testing and development work. While you could push a new software load from the comfort of your desk, if you borked things badly enough you'd sometimes have to go downstairs and plug a serial cable into the front of the control card so you could go poke around and force the card into a sane state.
So, when a new hire came in, they might say, "Hey mrweasel, I uploaded a bad load to Spock, and it's stuck in a boot loop. Where can I find that physical machine?" And you'd say, "Head down to the third floor, turn left out of the elevators, walk to the second last row of racks. On your left there should be switches named "Picard", "Riker", "Deana", etc..., and on your right should be "Kirk", "McCoy", and friends. Spock is third on the right between McCoy and Uhuru."
That conversation is way more confusing if all of these machines are named "test01-test20". You couldn't even name them that - there were lots of different products in different areas of the lab, so you'd need the product name in there, and they'd be "rsp7670-test01" through "rsp7670-test20".
And, when you want to push a new build from your desk, it's way less likely you'll mistype "picard" when you want to update "data", but it's quite easy to accidentally clobber "rsp7670-test05" when you mean to overwrite "rsp7670-test06", which was sure to summon an angry developer to your desk asking why you just killed their 48 hour validation testing, 45 hours in.
[+] [-] rgj|5 years ago|reply
[+] [-] koolba|5 years ago|reply
[+] [-] zoomablemind|5 years ago|reply
No wonder helium was mostly hanging ...
Sorry, could not resist. It is a clever naming scheme. At one site a client used names from The Three Stooges, then they got the 6th server (exhausting the list of the lead characters).
[+] [-] malobre|5 years ago|reply
[+] [-] jlgaddis|5 years ago|reply
[+] [-] einpoklum|5 years ago|reply
* Don't overload other terms already in common use.
* Don't choose a name after a project unique to that machine.
* Don't use your own name.
* Don't use long names.
* Avoid alternate spellings.
* Avoid domain names.
* Avoid domain-like names.
* Don't use antagonistic or otherwise embarrassing names.
* Don't use digits at the beginning of the name.
* Don't use non-alphanumeric characters in a name.
* Don't expect case to be preserved.
* Use words/names that are rarely used.
* Use theme names.
* Use real words.
* Don't worry about reusing someone else's hostname.
* There is always room for an exception.
[+] [-] shagie|5 years ago|reply
Unfortunately, I only remember the test and production server names. The test systems were "Trinidad" and "Tobago". The production systems where "Nevis" and "Nassau" (the app started with an 'N').
The thing that made this work really well was that the first syllable hinted on what the rest of the word would be and then everything beyond that reinforced that you read it right. This even was the case that foreign accents, while slightly off still reinforced the "you heard this right".
The machines _also_ had names of "test01" and "test02" or similar... but we (as devs) never used those names because you had to listen to the end of it to be sure that you had the right machines.
[+] [-] cy6erlion|5 years ago|reply
You will read this RFC like this:
$ ietf -n 1178
[+] [-] majewsky|5 years ago|reply
[+] [-] metalliqaz|5 years ago|reply
[+] [-] indentit|5 years ago|reply
That's a good point, but humans are very different to computers - machines (be they physical or virtual) are provisioned for a specific purpose (even if that is to be "Fred's PC"), whereas humans need time to grow and can decide for themselves what to do as a career / what their hobbies will be, and change it any time.
But realistically, yes, the RFC is right that you may end up with machines whose purpose changes or multiple machines have the same purpose etc. But when they don't, it is much easier to have meaningful names. If you will name them differently, then please make sure all developers can access the list/mapping document and it is kept updated. It's frustrating if you want to investigate some production problems but end up looking at the wrong server's logs because devops didn't tell anyone they moved an application /website etc.
I like someone else's comment about app01 being easier to reason about and recreate than something named more specifically, and in the modern world, its easy to spin up a new docker instance or VM so there's less need to "let's just add this small service on that machine because it has spare capacity" (where capacity could be CPU/RAM etc.)
[+] [-] diftraku|5 years ago|reply
There's a good selection, it's pretty varied and there's no shortage of em (assuming you don't exceed 100-200 new systems in a 3 year period). This also has an accidental side-benefit of not being tasked to name new hosts at work, unless your really want to call the new database server Stufful, for example.
Another thing to keep in mind with more descriptive hostnames like `database`, is to serialize them from the start. It's a very minor thing but after you have three hosts with one of them missing the serialization, it's going to stand out like a sore thumb and it could be a major undertaking on changing that name where it's used.
When it comes to project names, there is a certain level of permanence that name (or codename) is going to have. Once chosen, that name will be thrown around in the codebase almost universally. The same does apply to the hostnames, at least in part when it comes to configuration files (and by extension, certain hard-coded hostnames that could linger around in the code years after the host in question has been decommissioned).
[+] [-] MauranKilom|5 years ago|reply
Or, as told by xkcd: https://xkcd.com/910/
[+] [-] hyperrail|5 years ago|reply
There were the better-known folks like linus (Linus Torvalds [1]) and gregkh (Greg Kroah-Hartman [2]), but also relatively more obscure people, like shemminger (Stephen Hemminger [3]) and stelian (Stelian Pop [4]).
I didn't recognize most of those names at the time, but now that I do, I wonder what those people would have thought about having a large organization's computers named after them. A bit creeped out, I would think.
[1] https://github.com/torvalds
[2] http://www.kroah.com/log/
[3] https://www.linkedin.com/in/networkplumber/
[4] https://www.popies.net
[+] [-] sillysaurusx|5 years ago|reply
The most sensible naming scheme for us was to distinguish them by index. But there were two important differences: TPUs have many sizes, which means some are larger than others; if you're using a v3-256, you're very likely the only researcher doing so. They are also distinguished by type; v3 is more powerful than v2. Finally, they are region-based; the less powerful v2's are in the US, whereas the v3 fleet is mainly EU based.
That led to the convention of tpu-v3-8-euw4a-1, tpu-v2-256-usc1a-0, and so on.
The "tpu-" prefix might seem redundant, but I find it's helpful in conversation. That's a personal preference though, and if I had to do it again I'd probably drop the tpu- prefix entirely.
I found this scheme was horrible for VMs though. TPUs are often used for specific training runs, and the scheme above is easily added to bash files / config scripts. But for VMs, you're often SSH'ing into them all the time.
Ultimately we started naming the VMs after the researchers who originally needed them. Our current primary training box is song.tensorfork.com, named after researcher songpeng who it was created for. So the SSH scheme was pleasant: [email protected] for him, [email protected] for me, arfa@, aydao@, etc.
When arfa neded a VM, I simply named it arfa.
All other more complicated naming schemes failed with time. No one (including me) could remember long VM names, let alone ones with numbers in them.
The other scheme that persisted was to use anime characters, as emersion mentioned. Tensorfork itself runs off of vegeta, which is my personal Hetzner server. "goku" was one of our primary workhorses at one point, due to its large VM size.
Our final two VMs are named "test" and "nuck", which also seem to work quite well (much to my surprise). "Is test down?" is almost completely unambiguous. And it's easy to remember which one is which: "nuck" is in Canada, so therefore "test" is the one in europe.
A pattern emerges here: most of our VM names are short, four-letter identifiers: arfa, song, test, nuck, goku, with vegeta being the standout. All other conventions failed with time.
[+] [-] krallja|5 years ago|reply
[+] [-] rgj|5 years ago|reply
[+] [-] thom|5 years ago|reply
https://mtg.fandom.com/wiki/Forest
These days, for work, it’s just boring unambiguous stuff. I think with more cloud infrastructure and the rarity of shared unix servers with home directories for people, it’s rare that I have any emotional investment in a machine. They’re basically soulless now.
[+] [-] Etheryte|5 years ago|reply
[+] [-] jjice|5 years ago|reply
For servers I use for my roommates and I (Jellyfin and the like), we name them after the quirky students that go to our university that we appreciate.
[+] [-] kuter|5 years ago|reply
[0]https://en.wikipedia.org/wiki/April_Fools%27_Day_Request_for...
[+] [-] DanBC|5 years ago|reply
https://tools.ietf.org/html/rfc2468
("2 4 6 8, who do we appreciate")
[+] [-] TickleSteve|5 years ago|reply
(IP via pigeons).
[+] [-] modderation|5 years ago|reply
[1] The Naming of Servers https://tools.ietf.org/html/rfc2100
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] emersion|5 years ago|reply
[+] [-] netflixandkill|5 years ago|reply
Made for great mascot toys and posters on the rack doors.
[+] [-] jjice|5 years ago|reply
[+] [-] ddtaylor|5 years ago|reply
[+] [-] sellyme|5 years ago|reply
[+] [-] walrus01|5 years ago|reply
[+] [-] rbanffy|5 years ago|reply
It probably needs updating. It's been a while since the last large leak.
[+] [-] hoppla|5 years ago|reply
[+] [-] mcguire|5 years ago|reply
I always wanted to use 'Starships from Iain M. Banks' science fiction', which is why no one ever listened to me.
For personal machines, I have been using adjectives that start with 'i'.
[+] [-] vermilingua|5 years ago|reply
Wikipedia’s decision to delete the list was utterly ridiculous, thankfully they all made it over to the fandom wiki.
Unfortunately they’re now a finite resource, RIP.