It would be funnier if it weren't somewhat true. IP addresses rarely change on servers once users/apps are dependent on them. Addresses also provide locality data with regard to network topology - the number of hops away.
Of course I'd much rather remember amazon.com than 72.21.203.1, but I'm a human. Systems deal with numbers much better with no lookup penalty or DNS accuracy issues.
This is the first post on the subject I actually agree with. The proper use of generic hostnames and subdomains is almost best approach for all environments - small to big. Keep hostnames generic and inline with the function (e.g. app01). Avoid project related names and anything else that changes with management whims. Then use DNS to fully quailfy as in:
app01.atl.some.com
or even:
app01.r03.atl.some.com
Most users/apps on the the same local subdomain don't need to know the FQDN. They can just reference app01 in this example. Less is more.
If you have dependable/accurate DNS and keep hostnames generic, migrations become super easy as as you don't have to go tinkering about the system to adjust, it just gets becomes part of the environment. You can then leverage the partially qualified domain name in system scripts.
For example, a tying/etc/resolv.conf on a typical *NIX box to atl.some.com makes scripting super easy.
Of course if you have a good DNS, using CNAME's to make everyone happy is always an option. That's the nice thing about names - you can have more than one.
One word:
virtualize
Imagine 32 core Xeon CPU's with 1T RAM carved up into bite size guest chunks that can be supersized as resource requirements increase.
Who can quote us the maximum CPU and RAM a 64bit OS can address? I know we're not due to be anywhere close for a while..
It's funny how many Slashdot readers immediately think of science fair type applications when something interesting like an open source voice reco app is released. Not that such applications don't have merit, but the when compared with high dollar speech application companies like Nuance (http://www.nuance.com/) and Holly (http://www.holly-connects.com/), the real value of open source speech recognition becomes apparent - it's another critical piece of software needed to create a truly open source voice platform. Asterisk is great, but isn't a complete solution for vxml apps.
Companies like Nuance know the open source alternatives to their own products are not yet ready for prime so they charge a huge premium for licenses. When open source can provide a complete and robust voice platform solution, these companies will know then end is near.
I couldn't agree more. As I grow older, I've learned there really is a time when something is "good enough" to satisfy known requirements. I find that many applications are over engineered to some pie in the sky version of what's right and good - usually at the expense of simplicity and stability. I've often heard Java folks talk about re-factoring code and that's fine if no one is using your app, but in the event that folks and money are dependent on it, then re-factoring really just increases risk to all involved. The best possible outcome is that no one will notice the changes.
It's definitely hard for more passionate developers to realize when time to value ratio has diminished to the point that your time is better spent on other projects. There's always one more thing to spruce up or optimize. Having been both a musician and developer, I like to think of my work as a reflection of me. Playing an instrument is similar in that there is always more to learn and practice on any given song, but sometimes you need to put it down and move along to other pieces. Even the best musicians play a variety of songs. I'm sure Eddie Van Halen could have perfected Eruption for the next 20 years after he recorded it, but he decided to spend his time on other works.
I couldn't agree more - Nagios has stood the test of time. The fact the No Starch Press is publishing a Nagios books is a good indication of just how widely used it is. I agree the we interface is a bit dated, but the real power of Nagios isn't in the front end - it's the robust notification and complete extensibility that keep me using it. I monitor jut over 500 servers representing about 5000 checks (around 10 per server). There has not been a n issue yet that I couldn't get Nagios to somehow monitor. The custom check plugins can be written in any language - just return -1, 0, 1, 2. Passive checking with syslog-ng regular expressions is also very powerful. It's trivial to write messages to the Nagios named pipe for custom alarming.
I also agree it's a pain to setup initially, but if you're smart with host and service groups then adding new hosts and checks is really pretty easy. I'm actually working on a pre-configured Nagios appliance using Xen. I'm hoping folks will have an easier time starting with a reasonably robust canned instance that includes graphing and other niceties. I haven't yet figured out how to distribute it.
I concur on the old weather info. I also find myself frequently waiting for news and weather updates (although the helpful news cat is charming). The Wii Shop channel is also painfully slow. I'd stay off Wii Shop, but those darn virtual console games like Super Mario World are too good pass up. Gotta love vintage games on a 42" plasma.
Slashdot Mirror
It would be funnier if it weren't somewhat true. IP addresses rarely change on servers once users/apps are dependent on them. Addresses also provide locality data with regard to network topology - the number of hops away. Of course I'd much rather remember amazon.com than 72.21.203.1, but I'm a human. Systems deal with numbers much better with no lookup penalty or DNS accuracy issues.
This is the first post on the subject I actually agree with. The proper use of generic hostnames and subdomains is almost best approach for all environments - small to big. Keep hostnames generic and inline with the function (e.g. app01). Avoid project related names and anything else that changes with management whims. Then use DNS to fully quailfy as in:
app01.atl.some.com
or even:
app01.r03.atl.some.com
Most users/apps on the the same local subdomain don't need to know the FQDN. They can just reference app01 in this example. Less is more.
If you have dependable/accurate DNS and keep hostnames generic, migrations become super easy as as you don't have to go tinkering about the system to adjust, it just gets becomes part of the environment. You can then leverage the partially qualified domain name in system scripts.
For example, a tying /etc/resolv.conf on a typical *NIX box to atl.some.com makes scripting super easy.
Of course if you have a good DNS, using CNAME's to make everyone happy is always an option. That's the nice thing about names - you can have more than one.
One word: virtualize Imagine 32 core Xeon CPU's with 1T RAM carved up into bite size guest chunks that can be supersized as resource requirements increase. Who can quote us the maximum CPU and RAM a 64bit OS can address? I know we're not due to be anywhere close for a while..
It's funny how many Slashdot readers immediately think of science fair type applications when something interesting like an open source voice reco app is released. Not that such applications don't have merit, but the when compared with high dollar speech application companies like Nuance (http://www.nuance.com/) and Holly (http://www.holly-connects.com/), the real value of open source speech recognition becomes apparent - it's another critical piece of software needed to create a truly open source voice platform. Asterisk is great, but isn't a complete solution for vxml apps.
Companies like Nuance know the open source alternatives to their own products are not yet ready for prime so they charge a huge premium for licenses. When open source can provide a complete and robust voice platform solution, these companies will know then end is near.
I couldn't agree more. As I grow older, I've learned there really is a time when something is "good enough" to satisfy known requirements. I find that many applications are over engineered to some pie in the sky version of what's right and good - usually at the expense of simplicity and stability. I've often heard Java folks talk about re-factoring code and that's fine if no one is using your app, but in the event that folks and money are dependent on it, then re-factoring really just increases risk to all involved. The best possible outcome is that no one will notice the changes.
It's definitely hard for more passionate developers to realize when time to value ratio has diminished to the point that your time is better spent on other projects. There's always one more thing to spruce up or optimize. Having been both a musician and developer, I like to think of my work as a reflection of me. Playing an instrument is similar in that there is always more to learn and practice on any given song, but sometimes you need to put it down and move along to other pieces. Even the best musicians play a variety of songs. I'm sure Eddie Van Halen could have perfected Eruption for the next 20 years after he recorded it, but he decided to spend his time on other works.
I couldn't agree more - Nagios has stood the test of time. The fact the No Starch Press is publishing a Nagios books is a good indication of just how widely used it is. I agree the we interface is a bit dated, but the real power of Nagios isn't in the front end - it's the robust notification and complete extensibility that keep me using it. I monitor jut over 500 servers representing about 5000 checks (around 10 per server). There has not been a n issue yet that I couldn't get Nagios to somehow monitor. The custom check plugins can be written in any language - just return -1, 0, 1, 2. Passive checking with syslog-ng regular expressions is also very powerful. It's trivial to write messages to the Nagios named pipe for custom alarming. I also agree it's a pain to setup initially, but if you're smart with host and service groups then adding new hosts and checks is really pretty easy. I'm actually working on a pre-configured Nagios appliance using Xen. I'm hoping folks will have an easier time starting with a reasonably robust canned instance that includes graphing and other niceties. I haven't yet figured out how to distribute it.
I concur on the old weather info. I also find myself frequently waiting for news and weather updates (although the helpful news cat is charming). The Wii Shop channel is also painfully slow. I'd stay off Wii Shop, but those darn virtual console games like Super Mario World are too good pass up. Gotta love vintage games on a 42" plasma.