I thought about citing some text from your message and then go for dearest-to-Slashdot car analogy. But, heck, I'd need to cite the whole of your message!
Just re-read your message applied to the automotion industry. I'll start for you and you follow:
"In these days you don't know which distro is right for you, they all provide much the same functionality and all have little differences. I tried the major distros, KDE, Gnome, and landed on Ubuntu with Gnome because everyone was ranting and raving about it and I thought it was worth a closer look..."
In this days you don't know which car is right for you, they all provide much the same functionality and all have little differences. I tried the major brands, Ford, GM, and landed on BMW 318 because everyone was ranting and raving about it and I thought it was worth a closer look...
Now: everybody and his mother (except for our Soviet Russia overlords, of course) think that competition on the automotive industry is quite a good think. How is it the same doesn't applies to Linux distributions even when semantically it's clear you can substitute one for the other almost word by word?
"The lack of UI standardization is really making life unnecessarily hard. Getting Gnome somehow running on top of QT would be a big step in this direction."
How can be somebody so wrong and still being modded "+1 Insightful"?
1) What Shuttleworth said it's that Gnome's "philoshopy" (lack of -suppousedly, confusing options, lean and mean desktop) can certainly be built on top of Qt. 2) That's exactly what really differences KDE from Gnome on the user's eye. Gnome tries to be lean and mean on the understanment that the "standard user" only need a short and well chosen functionality set. KDE, on the other hand, bases it's development on the understanment that even if any given user will use 5% of the desktop possibilities, each user, or at least a significative percentage of users, will tend to use a different 5%, hence the desktop, while directly offered with a given configuration set preselected (which, theoretically could be more or less equivalent to that of a "standard" Gnome desktop, why not), should offer ample configurability. 3) Once understood that from the end-user point of view major differences between KDE and Gnome are of "philosophycal" nature, not technically based on the underlying graphical toolkit, it's both obvious that KDE could be written on top of Gtk+ and/or Gnome on top of Qt *and* that writting one desktop on top of the other's toolkit preserving their "philoshopycal" differences would do nothing in regards of "UI standardization". 4) Finally, while I understand the non-end-user related features that make Mr Shuttleworth push forward Gnome (mainly, that Gtk+ is LGPL distributed while Qt is dual-licensed, GPL and privative), I must say to him "thanks, but no thanks": I'm in favour of both the UI approach and the end-result of KDELibs being dual-licensed from KDE so, while he is absolutly free to push his money and as much people as he can towards his goals (which underneath, I bet they go more or less like "heck, the more I look at it, the more convinced I am that Qt is a much better toolkit than Gtk+... if only Qt were LGLP..."), I'm interested a zinch on Gnome's fate but I'm quite interested on KDE going into the future as it has gone since Qt became GPL for those interested.
"Which begs... What the hell are you doing getting paid for this then???"
This is not the point. The point is "what the hell is your company paying you for this then??".
The answer is obvious: the company pays such incompetent people because it profits from it. And as long as USA corporation execs are as naive or greedy as they are, that will be the case.
"We know why companies outsource, because it is cheaper!"
Then, you are wrong. Companies don't outsource because it's cheaper. They outsource because:
a) It *seems* cheaper, as in the outsourcing company goes at 25US$/hour while we go at 100US$/hour. That can be really cheaper or not depending how many hours do you need for a given deliverable (and that "fine" point usually isn't properly taken into account by managers when outsourcing or else, you wouldn't hear horror stories about outsourcing or even companies going again with local assets).
b) It's better (not cheaper) but not for the company but for the exec pushing the outsourcing (as it seems to be this very case where the CIO might be getting bonuses for each asset outsourced).
"As a customer how do you feel about a company that 'values' you so highly they dump you with the cheapest customer support they can get."
That is not the point *even* if outsourcing were the corporate dream high execs thought some years ago. The point is how the customer stands against cheaper production costs: do they go to our rivals or do they go from our rivals to us? If the former, market laws will go their way and the company either will embetter their customer support or eventually disappear; if the latter they are doing nothing but what their customer base claim even if unconciously. Given current market trends, it seems companies are doing nothing but what their customers want and expect in the end of the day.
"Even he agrees that the Indians, for the most part, are incapable of being creative and thinking for themselves"
And that's called "the inverse Ulysses syndrome".
"All of their work is performed in a "group" and they don't know how to do it themselves. "
That's exactly what is said about japaneses but see, it doesn't seem they are doing so bad on world economy.
On the other hand, India is well known for its mathematicians, hardly an environment for people non capable of being creative or thinking by themselves.
"Only a handful of universities in India are worth anything, the rest are diploma mills."
Maybe that fact that's exactly what (mainly) USA demands has something to do with it.
"You give it something, you will get back exactly what you asked for, but if it something outside of the realm of what was expected, it is not handled well."
Jesus Christ! they dare to do exactly what their contract clearly states! (that they are "do-as-I-say" drones, not creative workers). Chip their heads off, I say, chip their damn heads off!
"We as American tech workers need to stand up against this."
We? as in "some form of organized colective"?
"The first thing we need to do is to refuse to cooperate in any way with any Indian company. [...] Second, we need to actively talk with our managers [...] If we act now, we'll achieve true results."
So we as "some form of organized colective" should go to our managers to negotiate the way bussiness must be made.
Well, I'd say that is an invention of the XIX century. They called them labour unions or sindicates, but you know, they are so communists and anti-american...
"Debian security updates ONLY come from a trusted server (security.debian.org)"
So that means... 1) If I owned a single server (security.debian.org) I own all updating machines in the whole world (good to know). 2) If I DoS security.debian.org I'll win a window of opportunity to all debian servers in the whole world (good to know). 3) Since security.debian.org serves through http and ftp it's opened to a MiM attack (good to know).
"It is impossible to forge a "newer" version than those on the security.debian.org server, so you won't miss the patch."
Who told you that? Say that openssh-server is currently at version 1:4.3p2-9etch2. Say I own apt.mymirror.com and that you use it on your sources.list file. Then, if I host an 1:4.3p2-9etch2 on my mirror you will update it next time you aptitude update && aptitude upgrade. There's nothing within apt structure that will restrict updates to just those from security.debian.org.
Now, *if* security.debian.org provided a signed packages.list (both for the "base" distribution and security updates) through https *and* packages.list both provided current packages list *and* their checksums you would: a) Allow for security.debian.org to be securely mirrored (this way you'd avoid for the most part DoS, either deliberated or due to excess of "legal" traffic -I think to recall this already almost happened last year). Only packages.list would be forcibly downloaded from the security.debian.org master itself. b) Avoid MiM-based attacks c) A (currently to-be-developed) mechanism could be hooked to apt and related client-side utilities so for security update lists provided by a trusted source (https://security.debian.org by default) nothing but the package versions referred on that trusted packages.list would be accepted.
Note that even this wouldn't cope with the fact that if security.debian.org is owned, then everything is lost. But then again, security.debian.org would service just one port and service (https) and only a short list of trusted people would need access to it, so it could be reasonabily easy to secure against all but the most determined attacks.
"The telecoms have more money than the entertainment industry."
Yes, but that's not the only point: entertainment and telecoms have too much common ground (telecoms benefit from control and they can pass a good part of these legislations' burden directly to the end user).
"Not to be rude, but when will the open source crowd realise that no legal department is going to let a firm go to linux until there is somebody they can sue if everything goes belly up"
Of course you are a troll, but...
I still have to see a corp installation that at boot up says "here's Linux booting". They all say "Here Comes Red Hat", or "That's Novell SUSE coming", or "welcome to Canonical's Ubuntu", or something like that.
Are you implying that Microsoft can be sued but Red Hat, Novell or Canonical can't?
"That way they can't containerise you easily and therefore know fully the impact of you not being there any more"
So the manager will have on one side a savings for certain (your wages) against an uncertain loose.
*If* after the merger/aquisition management are pressed for savings (and you can bet most probably they will, since their own positions are as much in danger as yours) then who would you go against? Those you know their cost/revenue for certain or those whose costs are for certain but revenues ignored -so the company won't percieve it as a lost but too late if anytime?
Think like a manager: if I do not know what exactly is this guy doing for the company, he surely can't be so important.
"How perceptive! Full support for TCP/IP, long filenames, scripting, and robustness were gravy. What administrators really need are scalable fonts and cool screen savers!"
"Wasn't there something about expensive Qt licenses for development?"
No, there aren't. There are "(not so expensive) Qt licenses for PRIVATIVE LICENSE development". Not quite the same thing (as the KDE people can confirm).
"What's the difference if a company has to pay for Qt development as opposed to paying for Motif development?"
Qt itself. And the fact that due to its dual license Qt has a much bigger base of coders and a success case as relevant as KDE. Where has been Motif in the last, how many? twenty years?
"A recent study (blowed if I an find a link) seems to support your view; highly skilled chess players apparently don't think any further ahead than average players"
There was a Grand Master (while I can't recall it) that asked how many positions he looked forward answered: "just one: the best".
"I'm intrigued as to where you get this idea that throwing a punch is a bad idea in a fight and would strongly contest that boxing has no value in self-defence."
I don't think the problem is about the punch but about the implicit fact that I'll be punched but my opponent won't dare to kick my low parts so I don't need to take care of them thus making boxing too "artificial".
On the other hand, I can't accept his definition for "martial art"; he was defining "self-defense" quite related but still not quite the same. Not that I have a clear all-encompassing definition for "martial art" (if I define it by its intention, fencing is a martial art, but judo is not; if by its rules, nothing but vale-tudo and related would be martial arts; if by its current application, it would be only instinct shooting, etc.) but I have a clear "sense" where tae-kown-do is a sport as it is boxing while karate or judo or fencing (or even iai-do) are martial arts.
"* The RFC is only applicable to small systems. Obviously."
The RFC is *mainly* focused to small/medium system but it certainly is aplicable to all kind of systems. Tell me which point, either from the "don'ts" or the "dos" is of no application on large deployments. The only dubious one, out of a list of 11 "don'ts" and 5 "dos" is "use real words". And yes, "Use theme names" *is* of application: "make the name out of the main function, then the state code, then the inventory number" is both an algorithm *and* a theme, as it is a theme "the set of natural numbers" just like "the set of LOTR characters" is.
"Yep, DNS is technically a database, I know this since I am not a total moron."
Good to know.
"But that was not my point either. Most NOC-servers does not use DNS, but a specific database, to store system specific data, mostly for security, TTL, and availability/redundancy reasons(not all eggs in the same basket)."
I feed DNS data out of flat files, MySQL databases and BDB through LDAP. In the last two cases, the underlying database holds not only domain name data. Your point is, again?
"A file server is a server that serves files, this might or might not include an FTP server. I wasn't pretending to come up with a perfect standard. I said rough, remember?"
But you are ready to attack an RFC because it isn't a "perfect standard" either while nobody seem to have taken the time to produce a better one since 1990. You both failed to provide a better standard and to properly qualify the lacks from the current one (HINFO and TXT fields do cover the example you provided, don't they? Not that I myself find them of any use, but that's out of the question here).
"In larger systems, you seldom, if ever, change the role of a server(during it's 3 year life span)."
In larger systems you *seldom* change the role; the RFC both covers the case where you don't change the name and when you change it too; it's not judicious to use functional names in any case: you are "labelling" the system, not its function. Just as a lame comparation, since most delivered PCs comes with Windows, why we should take into account anything out of Windows world? (by the way, it would simplify the "fileserver" case: it would be a SMB fileserver since there's no other kind).
"But I would rename it, if that happened."
The old guy "now get off my lawn" story: Once upon a time we (as in the team I belonged by the time) did that. Usually a "server grade" PC started its life in a "heavy duty" environment (say, a fileserver) then some years down the line new faster hardware retired it from the front line and it were redeployed (different name) on a "second rank" role (say as a DNS, a test server, a cold backup, even in some cases as a user workstation, whatever). We managed some two hundred servers at the peak (not so big environment, but quite enough to find scale problems on not well fitted standards and protocols). On a five year cycle (by the end of my period on the team) we found by chance that our Dells were slightly but still significatively more problematic than our IBMs. Since we changed names when redeploying such a fact went under the radar for years; were we used the same name on the boxes for their whole life that fact would have just jumped out to our eyes (yes we used asset tags, that's how we discoverd, but while we used computer names day-in day-out, asset tags were something we had to explicitly look for, so the relationship between field attendances and computer brands went undiscovered for ages).
"1 & 2. The limitations of theme-based naming schemes does not stem from the number of available names, but the fact that it is impossible to read any information from the name of a server called "FIDO"."
Just as it is impossible to read job status from the name "John Smith"; the name "John Smith" is only meant to distinguish "this" guy from "that" guy. His job status is given by his job title "John Smith, CTO". By doing this -distinguishing individuality f
"And the RFC(1178) that someone pointed at was, at it's best, unhelpful."
Thank you for making all us aware of its limitations.
"If there was a standard(Something for OpenISO, perhaps?) that everybody used, it would be great."
An old time-tested RFC is unhelpul but if you stick an ISO number to it it would be somehow great. Yes, it makes sense.
"Then we would all only need to learn one standard. "
RFC-1178. On the other hand, RFCs are just that: Request For Comments. You are free to critizise 1178 or write up a new one to open it to other's critics to build an enhanced one more to your liking.
"Server names could also then be created automatically"
If that's your point, you can just give them random numbers, I mean, seriously.
"making some level of rough categorization possible(i.e. "list all file servers")"
What's a file server? Would you want to segregate NFS from AFS from SMB fileservers? Does FTP get into the "fileserver" category? On the other hand, you can stick whatever info you deem necessary to HINFO and/or TXT records.
"You might argue that that kind of data should be stored in a database, and not in a server name."
A name server *is* a database. You can even use a RDBM to feed your nameserver. You are aware of it, don't you?
"Then I ask you, why do server names exist at all, if not to define the server for it's users?"
DNS has its complexities that bring quite a big bunch of functionality with it. Did you ever read the "classic" O'Reilly's "DNS & Bind"?
"Regarding the location of the server, however, I don't think that should be in the server name(i'd rather put that in the subdomain). I mean, a mail server running Linux will continue to do so even if it is moved to a new location."
Yes, but your great Linux server won't serve mail once you delete it's mail serving software, add the NTP one and start serving as an NTP server... maybe at a different location too.
"But I have also been naming stuff after LOTR-caracters, Cartoon characters and whatever, too. That stopped working way back, when we passed the 20-server mark, though."
1) My last count on LOTR-caracters was over 400, not 20 (well, not LOTR but Tolkien's fictional universe). 2) Nobody said that using theme-based names limited you to use just *one* theme. 3) If you don't care about single machines, then there's no need to use clear identifications to distinguish each of them; numbers would do OK.
" If I want to print something, I want to find the printer nearest me and print, not guess whether "bilbo" is on this floor or not."
That's the point in naming it "bilbo", so you call your helpful helpdesk guy at the begining instead of later making it harder to debug your wrongly-chosen ppd filter. And even if you are one of those "do-it-myself" guys so adorable for IT staff, the label "bilbo" at the top of the printer would give you a hint.
"Old system: Ok, who set up the mail system in EMEA?
Frank?
Alright, when did Frank install it, during his scooby doo character phase? Or was it Bond Girls?
New system: I'll check MX1.emea.domain.ext "
Old System that has been working from the days we implemented TCP over carrying pidgeons: -No one in Europe can get mail. -OK, which system handles email for emea? dig example.com -t MX (well, in the old days we used nslookup, but...) mx1.emea.example.com 10 mx1.americas.example.com 20....
Ok, so it's scobydoo.example.net*1. Oh! and for you the trivia guys, since it's "scobydoo" you can bet it was deployed by Ted when he was on his scooby doo character phase, not that it is so important, but...
Regarding DNS and naming conventions it is *all* already invented. It's really awesome that such a trivial question has produced such a big number of -mostly uniformed, answers.
*1: Well, since we are talking e-mail system here, it would probably be easier than that since MTA on SMTP world asks for a "proper" A record for mail servers, not CNAMEs and the MTA name will directly point both directly and reversely to the same host. On the other hand, mail service is both critical and not so complex for the proper guys not having all its structure on his heads even at multinational scale.
Anyway, the general approach does hold it and it hasn't changed from 1990: * The machines are named following RFC-1178 (FYI-5) (from 1990; just mere 18 years ago, I think there have been time enough to have a look at it by now). * Each IP will have one and just one A record and both the A-record and its reverse PTR will be sincronized. * Use as many CNAMEs as it makes sense to hold service-base meaning. * Have a copy of "DNS&Bind" at hand to know when/how subdomaining and if it makes more sense for your organization to do it divisional-wise or geographically-wise.
Add to this an early plan about private subnetting as per RFC-1918 (BCP-5) (it's from 1996, so not a surprise, either) and you are almost done all the way from an early startup with just 5 PCs up to a multinational corporation.
Slashdot Mirror
I thought about citing some text from your message and then go for dearest-to-Slashdot car analogy. But, heck, I'd need to cite the whole of your message!
Just re-read your message applied to the automotion industry. I'll start for you and you follow:
"In these days you don't know which distro is right for you, they all provide much the same functionality and all have little differences. I tried the major distros, KDE, Gnome, and landed on Ubuntu with Gnome because everyone was ranting and raving about it and I thought it was worth a closer look..."
In this days you don't know which car is right for you, they all provide much the same functionality and all have little differences. I tried the major brands, Ford, GM, and landed on BMW 318 because everyone was ranting and raving about it and I thought it was worth a closer look...
Now: everybody and his mother (except for our Soviet Russia overlords, of course) think that competition on the automotive industry is quite a good think. How is it the same doesn't applies to Linux distributions even when semantically it's clear you can substitute one for the other almost word by word?
"The lack of UI standardization is really making life unnecessarily hard. Getting Gnome somehow running on top of QT would be a big step in this direction."
How can be somebody so wrong and still being modded "+1 Insightful"?
1) What Shuttleworth said it's that Gnome's "philoshopy" (lack of -suppousedly, confusing options, lean and mean desktop) can certainly be built on top of Qt.
2) That's exactly what really differences KDE from Gnome on the user's eye. Gnome tries to be lean and mean on the understanment that the "standard user" only need a short and well chosen functionality set. KDE, on the other hand, bases it's development on the understanment that even if any given user will use 5% of the desktop possibilities, each user, or at least a significative percentage of users, will tend to use a different 5%, hence the desktop, while directly offered with a given configuration set preselected (which, theoretically could be more or less equivalent to that of a "standard" Gnome desktop, why not), should offer ample configurability.
3) Once understood that from the end-user point of view major differences between KDE and Gnome are of "philosophycal" nature, not technically based on the underlying graphical toolkit, it's both obvious that KDE could be written on top of Gtk+ and/or Gnome on top of Qt *and* that writting one desktop on top of the other's toolkit preserving their "philoshopycal" differences would do nothing in regards of "UI standardization".
4) Finally, while I understand the non-end-user related features that make Mr Shuttleworth push forward Gnome (mainly, that Gtk+ is LGPL distributed while Qt is dual-licensed, GPL and privative), I must say to him "thanks, but no thanks": I'm in favour of both the UI approach and the end-result of KDELibs being dual-licensed from KDE so, while he is absolutly free to push his money and as much people as he can towards his goals (which underneath, I bet they go more or less like "heck, the more I look at it, the more convinced I am that Qt is a much better toolkit than Gtk+... if only Qt were LGLP..."), I'm interested a zinch on Gnome's fate but I'm quite interested on KDE going into the future as it has gone since Qt became GPL for those interested.
"KDELibs' biggest fault is that it's GPL"
KDELibs' biggest advantage is that it's GPL.
"Which begs... What the hell are you doing getting paid for this then???"
This is not the point. The point is "what the hell is your company paying you for this then??".
The answer is obvious: the company pays such incompetent people because it profits from it. And as long as USA corporation execs are as naive or greedy as they are, that will be the case.
"We know why companies outsource, because it is cheaper!"
Then, you are wrong. Companies don't outsource because it's cheaper. They outsource because:
a) It *seems* cheaper, as in the outsourcing company goes at 25US$/hour while we go at 100US$/hour. That can be really cheaper or not depending how many hours do you need for a given deliverable (and that "fine" point usually isn't properly taken into account by managers when outsourcing or else, you wouldn't hear horror stories about outsourcing or even companies going again with local assets).
b) It's better (not cheaper) but not for the company but for the exec pushing the outsourcing (as it seems to be this very case where the CIO might be getting bonuses for each asset outsourced).
"As a customer how do you feel about a company that 'values' you so highly they dump you with the cheapest customer support they can get."
That is not the point *even* if outsourcing were the corporate dream high execs thought some years ago. The point is how the customer stands against cheaper production costs: do they go to our rivals or do they go from our rivals to us? If the former, market laws will go their way and the company either will embetter their customer support or eventually disappear; if the latter they are doing nothing but what their customer base claim even if unconciously. Given current market trends, it seems companies are doing nothing but what their customers want and expect in the end of the day.
"Even he agrees that the Indians, for the most part, are incapable of being creative and thinking for themselves"
And that's called "the inverse Ulysses syndrome".
"All of their work is performed in a "group" and they don't know how to do it themselves. "
That's exactly what is said about japaneses but see, it doesn't seem they are doing so bad on world economy.
On the other hand, India is well known for its mathematicians, hardly an environment for people non capable of being creative or thinking by themselves.
"Only a handful of universities in India are worth anything, the rest are diploma mills."
Maybe that fact that's exactly what (mainly) USA demands has something to do with it.
"You give it something, you will get back exactly what you asked for, but if it something outside of the realm of what was expected, it is not handled well."
Jesus Christ! they dare to do exactly what their contract clearly states! (that they are "do-as-I-say" drones, not creative workers). Chip their heads off, I say, chip their damn heads off!
"We as American tech workers need to stand up against this."
We? as in "some form of organized colective"?
"The first thing we need to do is to refuse to cooperate in any way with any Indian company. [...] Second, we need to actively talk with our managers [...] If we act now, we'll achieve true results."
So we as "some form of organized colective" should go to our managers to negotiate the way bussiness must be made.
Well, I'd say that is an invention of the XIX century. They called them labour unions or sindicates, but you know, they are so communists and anti-american...
"40 years is way too short of a time-line and the US was not alone in playing that particular game."
Yes, you are right. We have to get it back to Rockefeller to have this fair.
"that's only due to a law forcing use of US-produced ships when shipping between US ports"
There goes the "free market" illusion by the USA.
"Debian security updates ONLY come from a trusted server (security.debian.org)"
So that means...
1) If I owned a single server (security.debian.org) I own all updating machines in the whole world (good to know).
2) If I DoS security.debian.org I'll win a window of opportunity to all debian servers in the whole world (good to know).
3) Since security.debian.org serves through http and ftp it's opened to a MiM attack (good to know).
"It is impossible to forge a "newer" version than those on the security.debian.org server, so you won't miss the patch."
Who told you that? Say that openssh-server is currently at version 1:4.3p2-9etch2. Say I own apt.mymirror.com and that you use it on your sources.list file. Then, if I host an 1:4.3p2-9etch2 on my mirror you will update it next time you aptitude update && aptitude upgrade. There's nothing within apt structure that will restrict updates to just those from security.debian.org.
Now, *if* security.debian.org provided a signed packages.list (both for the "base" distribution and security updates) through https *and* packages.list both provided current packages list *and* their checksums you would:
a) Allow for security.debian.org to be securely mirrored (this way you'd avoid for the most part DoS, either deliberated or due to excess of "legal" traffic -I think to recall this already almost happened last year). Only packages.list would be forcibly downloaded from the security.debian.org master itself.
b) Avoid MiM-based attacks
c) A (currently to-be-developed) mechanism could be hooked to apt and related client-side utilities so for security update lists provided by a trusted source (https://security.debian.org by default) nothing but the package versions referred on that trusted packages.list would be accepted.
Note that even this wouldn't cope with the fact that if security.debian.org is owned, then everything is lost. But then again, security.debian.org would service just one port and service (https) and only a short list of trusted people would need access to it, so it could be reasonabily easy to secure against all but the most determined attacks.
"The telecoms have more money than the entertainment industry."
Yes, but that's not the only point: entertainment and telecoms have too much common ground (telecoms benefit from control and they can pass a good part of these legislations' burden directly to the end user).
"policing the network is not something I would like to trust a private company wit."
The problem here is that there are companies with quite a lot more money than you that are licking at the idea.
"Not to be rude, but when will the open source crowd realise that no legal department is going to let a firm go to linux until there is somebody they can sue if everything goes belly up"
Of course you are a troll, but...
I still have to see a corp installation that at boot up says "here's Linux booting". They all say "Here Comes Red Hat", or "That's Novell SUSE coming", or "welcome to Canonical's Ubuntu", or something like that.
Are you implying that Microsoft can be sued but Red Hat, Novell or Canonical can't?
Dumb advise.
"That way they can't containerise you easily and therefore know fully the impact of you not being there any more"
So the manager will have on one side a savings for certain (your wages) against an uncertain loose.
*If* after the merger/aquisition management are pressed for savings (and you can bet most probably they will, since their own positions are as much in danger as yours) then who would you go against? Those you know their cost/revenue for certain or those whose costs are for certain but revenues ignored -so the company won't percieve it as a lost but too late if anytime?
Think like a manager: if I do not know what exactly is this guy doing for the company, he surely can't be so important.
"I want Kwrite working on windows without needing anything but windows QT."
That you won't get.
Kwrite is NOT a Qt app. It is a KDE app, so you can't get kwrite without KDE (foundation).
"How perceptive! Full support for TCP/IP, long filenames, scripting, and robustness were gravy. What administrators really need are scalable fonts and cool screen savers!"
Well, that's what facts support.
"Wasn't there something about expensive Qt licenses for development?"
No, there aren't. There are "(not so expensive) Qt licenses for PRIVATIVE LICENSE development". Not quite the same thing (as the KDE people can confirm).
"What's the difference if a company has to pay for Qt development as opposed to paying for Motif development?"
Qt itself. And the fact that due to its dual license Qt has a much bigger base of coders and a success case as relevant as KDE. Where has been Motif in the last, how many? twenty years?
"Not just brute force."
Where did you get the misinformed idea that boxing is "just brute force"?
"A recent study (blowed if I an find a link) seems to support your view; highly skilled chess players apparently don't think any further ahead than average players"
There was a Grand Master (while I can't recall it) that asked how many positions he looked forward answered: "just one: the best".
"I'm intrigued as to where you get this idea that throwing a punch is a bad idea in a fight and would strongly contest that boxing has no value in self-defence."
I don't think the problem is about the punch but about the implicit fact that I'll be punched but my opponent won't dare to kick my low parts so I don't need to take care of them thus making boxing too "artificial".
On the other hand, I can't accept his definition for "martial art"; he was defining "self-defense" quite related but still not quite the same. Not that I have a clear all-encompassing definition for "martial art" (if I define it by its intention, fencing is a martial art, but judo is not; if by its rules, nothing but vale-tudo and related would be martial arts; if by its current application, it would be only instinct shooting, etc.) but I have a clear "sense" where tae-kown-do is a sport as it is boxing while karate or judo or fencing (or even iai-do) are martial arts.
"* The RFC is only applicable to small systems. Obviously."
The RFC is *mainly* focused to small/medium system but it certainly is aplicable to all kind of systems. Tell me which point, either from the "don'ts" or the "dos" is of no application on large deployments. The only dubious one, out of a list of 11 "don'ts" and 5 "dos" is "use real words". And yes, "Use theme names" *is* of application: "make the name out of the main function, then the state code, then the inventory number" is both an algorithm *and* a theme, as it is a theme "the set of natural numbers" just like "the set of LOTR characters" is.
"Yep, DNS is technically a database, I know this since I am not a total moron."
Good to know.
"But that was not my point either. Most NOC-servers does not use DNS, but a specific database, to store system specific data, mostly for security, TTL, and availability/redundancy reasons(not all eggs in the same basket)."
I feed DNS data out of flat files, MySQL databases and BDB through LDAP. In the last two cases, the underlying database holds not only domain name data. Your point is, again?
"A file server is a server that serves files, this might or might not include an FTP server. I wasn't pretending to come up with a perfect standard. I said rough, remember?"
But you are ready to attack an RFC because it isn't a "perfect standard" either while nobody seem to have taken the time to produce a better one since 1990. You both failed to provide a better standard and to properly qualify the lacks from the current one (HINFO and TXT fields do cover the example you provided, don't they? Not that I myself find them of any use, but that's out of the question here).
"In larger systems, you seldom, if ever, change the role of a server(during it's 3 year life span)."
In larger systems you *seldom* change the role; the RFC both covers the case where you don't change the name and when you change it too; it's not judicious to use functional names in any case: you are "labelling" the system, not its function. Just as a lame comparation, since most delivered PCs comes with Windows, why we should take into account anything out of Windows world? (by the way, it would simplify the "fileserver" case: it would be a SMB fileserver since there's no other kind).
"But I would rename it, if that happened."
The old guy "now get off my lawn" story: Once upon a time we (as in the team I belonged by the time) did that. Usually a "server grade" PC started its life in a "heavy duty" environment (say, a fileserver) then some years down the line new faster hardware retired it from the front line and it were redeployed (different name) on a "second rank" role (say as a DNS, a test server, a cold backup, even in some cases as a user workstation, whatever). We managed some two hundred servers at the peak (not so big environment, but quite enough to find scale problems on not well fitted standards and protocols). On a five year cycle (by the end of my period on the team) we found by chance that our Dells were slightly but still significatively more problematic than our IBMs. Since we changed names when redeploying such a fact went under the radar for years; were we used the same name on the boxes for their whole life that fact would have just jumped out to our eyes (yes we used asset tags, that's how we discoverd, but while we used computer names day-in day-out, asset tags were something we had to explicitly look for, so the relationship between field attendances and computer brands went undiscovered for ages).
"1 & 2. The limitations of theme-based naming schemes does not stem from the number of available names, but the fact that it is impossible to read any information from the name of a server called "FIDO"."
Just as it is impossible to read job status from the name "John Smith"; the name "John Smith" is only meant to distinguish "this" guy from "that" guy. His job status is given by his job title "John Smith, CTO". By doing this -distinguishing individuality f
"And the RFC(1178) that someone pointed at was, at it's best, unhelpful."
Thank you for making all us aware of its limitations.
"If there was a standard(Something for OpenISO, perhaps?) that everybody used, it would be great."
An old time-tested RFC is unhelpul but if you stick an ISO number to it it would be somehow great. Yes, it makes sense.
"Then we would all only need to learn one standard. "
RFC-1178. On the other hand, RFCs are just that: Request For Comments. You are free to critizise 1178 or write up a new one to open it to other's critics to build an enhanced one more to your liking.
"Server names could also then be created automatically"
If that's your point, you can just give them random numbers, I mean, seriously.
"making some level of rough categorization possible(i.e. "list all file servers")"
What's a file server? Would you want to segregate NFS from AFS from SMB fileservers? Does FTP get into the "fileserver" category? On the other hand, you can stick whatever info you deem necessary to HINFO and/or TXT records.
"You might argue that that kind of data should be stored in a database, and not in a server name."
A name server *is* a database. You can even use a RDBM to feed your nameserver. You are aware of it, don't you?
"Then I ask you, why do server names exist at all, if not to define the server for it's users?"
DNS has its complexities that bring quite a big bunch of functionality with it. Did you ever read the "classic" O'Reilly's "DNS & Bind"?
"Regarding the location of the server, however, I don't think that should be in the server name(i'd rather put that in the subdomain). I mean, a mail server running Linux will continue to do so even if it is moved to a new location."
Yes, but your great Linux server won't serve mail once you delete it's mail serving software, add the NTP one and start serving as an NTP server... maybe at a different location too.
"But I have also been naming stuff after LOTR-caracters, Cartoon characters and whatever, too. That stopped working way back, when we passed the 20-server mark, though."
1) My last count on LOTR-caracters was over 400, not 20 (well, not LOTR but Tolkien's fictional universe).
2) Nobody said that using theme-based names limited you to use just *one* theme.
3) If you don't care about single machines, then there's no need to use clear identifications to distinguish each of them; numbers would do OK.
" If I want to print something, I want to find the printer nearest me and print, not guess whether "bilbo" is on this floor or not."
That's the point in naming it "bilbo", so you call your helpful helpdesk guy at the begining instead of later making it harder to debug your wrongly-chosen ppd filter. And even if you are one of those "do-it-myself" guys so adorable for IT staff, the label "bilbo" at the top of the printer would give you a hint.
"My personal favorite is to "name" servers using names like bob, sally, walter, joe."
So Joe is down? Not such a surprise, a divorce is always... oh, wait, what Joe are you talking about?
"I can't think of something more unprofessional than using given names for computers."
Indeed. It's so unprofessional we don't use them for persons either.
"Old system: Ok, who set up the mail system in EMEA?
Frank?
Alright, when did Frank install it, during his scooby doo character phase? Or was it Bond Girls?
New system: I'll check MX1.emea.domain.ext "
Old System that has been working from the days we implemented TCP over carrying pidgeons: ....
ping mx1.emea.example.com-No one in Europe can get mail.
-OK, which system handles email for emea?
dig example.com -t MX (well, in the old days we used nslookup, but...)
mx1.emea.example.com 10
mx1.americas.example.com 20
PING scobydoo.example.net (111.222.333.444)
Ok, so it's scobydoo.example.net*1. Oh! and for you the trivia guys, since it's "scobydoo" you can bet it was deployed by Ted when he was on his scooby doo character phase, not that it is so important, but...
Regarding DNS and naming conventions it is *all* already invented. It's really awesome that such a trivial question has produced such a big number of -mostly uniformed, answers.
*1: Well, since we are talking e-mail system here, it would probably be easier than that since MTA on SMTP world asks for a "proper" A record for mail servers, not CNAMEs and the MTA name will directly point both directly and reversely to the same host. On the other hand, mail service is both critical and not so complex for the proper guys not having all its structure on his heads even at multinational scale.
Anyway, the general approach does hold it and it hasn't changed from 1990:
* The machines are named following RFC-1178 (FYI-5) (from 1990; just mere 18 years ago, I think there have been time enough to have a look at it by now).
* Each IP will have one and just one A record and both the A-record and its reverse PTR will be sincronized.
* Use as many CNAMEs as it makes sense to hold service-base meaning.
* Have a copy of "DNS&Bind" at hand to know when/how subdomaining and if it makes more sense for your organization to do it divisional-wise or geographically-wise.
Add to this an early plan about private subnetting as per RFC-1918 (BCP-5) (it's from 1996, so not a surprise, either) and you are almost done all the way from an early startup with just 5 PCs up to a multinational corporation.