<story><title>A couple neat things about using chemical elements as hostnames</title><url>http://geoff.greer.fm/2009/06/17/hostnames/</url></story><parent_chain><item><author>lsc</author><text>Naming is a classic bikeshed.  Sure, a good naming system is  a good thing, and helps you recognize what box is where.  But once you hit between 20 and 200 hosts (depending on your memory)  you are going to need to stick &apos;em in a database and sort &apos;em into groups to manage them in a sane manner anyhow, and at that point, naming schemes won&apos;t mean much anyhow.&lt;p&gt;The problem is that as a bikeshed, /everyone/ has an opinion and everyone wants to have that opinion heard.  I&apos;ve been places where we spent more effort arguing about naming schemes than it would have taken to write the database and tools for retrieving groups of hosts.&lt;p&gt;So generally, when this comes up in situations where I&apos;m in charge,  I loudly declare it a bikeshed, and we choose the scheme essentially at random.</text></item></parent_chain><comment><author>peterwwillis</author><text>as a person who deals with tens of thousands of machines/network devices, i disagree that it&apos;s a bikeshed. yes you have to refer to a database for specific information. but it can be a huge time saver if the information that is most generally needed is just there, not needing to be looked up.&lt;p&gt;for us, we basically have 4 types of information in a fqdn: datacenter, lan, type of host (web server, database, filer, router, switch, etc) and an additional datacenter identifier. after the root domain comes the datacenter, and if there&apos;s an additional subdomain that&apos;s the lan. after that is the host name which is a number prefixed by the host type. the number is a randomly-selected number within a certain range. the range indicates what datacenter it&apos;s in, so 4000-5999 are in one place and 6000-7999 are in another place (incase whatever you&apos;re looking at did not include the subdomains). now we can refer to &apos;ws1234&apos; and know what it is and where it is. it still has much more specific information, but that can be looked up as necessary. since it&apos;s less random it&apos;s also easier to read hostnames to people and grep through logs.&lt;p&gt;after having worked with much more confusing naming conventions, i like this simple straightforward method because it&apos;s easy to read, talk about, and gives the basic information i need before i look up the specifics in the inventory db. can you do without it? of course. but does that make my job easier or harder?</text></comment>
<story><title>A couple neat things about using chemical elements as hostnames</title><url>http://geoff.greer.fm/2009/06/17/hostnames/</url></story><parent_chain><item><author>lsc</author><text>Naming is a classic bikeshed.  Sure, a good naming system is  a good thing, and helps you recognize what box is where.  But once you hit between 20 and 200 hosts (depending on your memory)  you are going to need to stick &apos;em in a database and sort &apos;em into groups to manage them in a sane manner anyhow, and at that point, naming schemes won&apos;t mean much anyhow.&lt;p&gt;The problem is that as a bikeshed, /everyone/ has an opinion and everyone wants to have that opinion heard.  I&apos;ve been places where we spent more effort arguing about naming schemes than it would have taken to write the database and tools for retrieving groups of hosts.&lt;p&gt;So generally, when this comes up in situations where I&apos;m in charge,  I loudly declare it a bikeshed, and we choose the scheme essentially at random.</text></item></parent_chain><comment><author>dasil003</author><text>Declaring bikeshed should be like calling shotgun--whoever declares it should make the decision.</text></comment>