"What it could also mean is that despite it being free, people still choose to pay quite a bit for something else !"
Unix folks are moving to Linux.
Windows folks are (partly) staying with what they know *or* (partly) moving to Linux.
For a party that had a very short market share gaining market share is a win.
For a party that started with something very near to a monopoly situation having the market know there are other choices *and* having (even only *some*) people going for those other choices is a terrible loose.
"Client commits a change to Node A. Node A queues the change to be sent to node B. Node A explodes."
Then client either won't recieve an OK status for its transaction (since it won't be declared as commited till Node A recieves confirmation from node B and confirms again it has recieved that OK -we are talking now about 2PC, remember?) and it will retry or it will recieve that OK status from node B if the system is configured to do so in case of loosing node. It will then recieve either a timeout (if still trying against node A) or it will successfully commit via node B which still is up (if the system declared a transaction as effectively commited in such a case).
So what? The question still is that _under proper configuration_ loosing master-node doesn't mean loosing data (even worse: risking non-consolidated data)
"You won't get any dependency problems installing KDE on Breezy. That's a plain lie."
Well, you can tell *others* this is a lie, but you can't tell that to me.
I *did* install Ubuntu (which installed Gnome by default using the "standard" procedure), I *did* executed `apt-get update` and `apt-get install kde` and I *did* get a broken dependencies message.
You can believe it or not; you can even test it by yourself, but you *cannot* tell me what I did and what did I saw with my own eyes.
"Wrong: All Ubuntu releases, including the first one, was based on Debian Unstable."
Yes; on a date when Testing and Unstable were basically the same due to Debian being frozen and Unstable not accepting anything too critical due to this (like Xorg or gcc 4 which were going into Experimental).
I'll repeat it: the farer Ubuntu is from current Debian Stable, the more work Ubuntu people will have to do to insure stability and integration for their releases (since they won't be able to rely so much on the "parent" distribution), and it is still to be seen if Ubuntu will have the power/interest on doing it.
"because distributions and vendors should be targeting the Linux Standards Base"
Why they should? 1/ LSB's only benefit is with respecting binary closed source software. But there're no sign that closed source vendors are going to support LSB at all: there's almost no software that officially support say LSB 1.0, and even when a company won't tell you they support Red Hat, but Red Hat ES 3.0 for instance. 2/ Last I reviewed we were on a capitalist society, thus no company should be doing nothing (not legally bound to) but trying to maximize profit. The day companies see targeting LSB is a way for maximizing profit, don't worry, they'll do.
Ubuntu had an easy start since they had a ton of money and an almost finished product (that date's Debian Sarge, which was almost frozen). Now Ubuntu is going away from Debian Stable (since they more or less follow Testing/Unstable) and the effects of using a more beta-quality master are already noticeable: Breezy Badger (current Ubuntu) is quite unpolished (few days ago I made a "clean install" then I tried to install KDE just to see it was not possible due to broken dependencies, for instance; that would never happen with Debian: they'd either distribute a *functional* KDE or no KDE at all). For Ubuntu to stay the "up to date easy Debian-like distribution" they seem wanting to be, it will mean they will have to through more and more money and more and more human force (they will be able to take less and less directly from Debian). For companies like Red Hat or SuSE it meant being almost at bankruptcy for *years*. Since now Linux is much more known and widely deployed than in the days RH or SuSE started maybe Ubuntu has a chance to abandon red numbers faster but, well, as I said at the beginning of this, that's still to be seen: it can be a succesful "corporate distribution", or it can go the way of, say, Progeny (which already tried to take the same niche).
"How important are these kinds of certifications really?"
It is not important, but essential when working on corporate environments.
"I assume they are really just a fancy way of saying "we support our software on this platform and are prepared to sell support and consulting services for our system running on it"
No: it is more saying we WON'T sell support and consulting UNLESS we previously said so (via a certification).
While it should be less of an issue when talking about open software (others will do what you don't want to), it is a must when talking about privative software, like it it the current case.
And it is currently a "clever" path for a "corporate distribution" to follow. An example: I work for a consultancy firm and we usually go with Red Hat when a client needs/wants say Oracle support. I would prefer using Debian, but the client mandates (and rightly so) a certified platform when it wants to deploy Oracle. But then, it means that our bosses prefer to go with CentOS when certification/support is not an issue in order to take advantage of our Red Hat "know-how". In the end it means that our company is much more savvy with Red Hat-like distributions, so in the end Red Hat gains kind of a "lock in" on us.
Maybe Ubuntu going this path will mean that in the future we will be able to go with the Ubuntu/Debian tandem instead of Red Hat/CentOS.
We are not talking here about everyone, but about YOU and YOUR software. It is TO YOU the one the license YOU choose should fit!
I think you focused the problem the wrong way.
You should think FIRST how do you want your software to be used and distributed, only THEN you should think about which license you should distribute your software with in order to achieve YOUR goals.
There is nothing as a "license mess". A license is only a written agreement between you and the one you share your software with, think about that. And then, you are lucky enough that you are not the first person in the world that wants to share his software with other people so you can take other's example. There are some license "templates" so widely used that they are even known by a generic name, like "the BSD" or "the GPL", that's all.
If one of those alreadly publicly known agreements fits you and your interests, pick it; if not, you will do as with any other 'a priori' agreement you would get into with other people: you would write it down, you would have it reviwed by an attorney and you'd stick with it.
And now, since you didn't tell us how do you want your software to be distributed, well, it's clear we can't help you about telling if there already is a commonly known "license template" you could use.
"First off, Linux, or rather GNU/Linux, is an operating system KERNEL."
Bullshit! It is not true neither what you literally say nor what you try to imply.
Not even a completely drunken RMS would state that the Linux KERNEL should have to be called GNU/Linux.
On the other hand, while even a recently showed RMS would state for all and every Linux Operative Systems (o collection, or "distro", or whatever the name you prefer) to be known as GNU/Linux mainly because the "marketing hype", I'd say (first he tried Lignux, with no success), it is quite clear that only distros coming from the FSF or accepting to entrust its ideals and objectives should be known as GNU/Linux.
Thus, "Debian GNU/Linux", but "Red Hat Linux", for instance.
"The truth is that no more than 1% of home users use Linux on the desktop, and only a tiny minority don't dual-boot with Windows.
The few people who do 'convert' to Linux, imho, often do so because they want to run Unixy applications, not because they prefer it as a desktop environment"
Well, if there is so few peple that use Linux exclusively, then even my single opinion must be a signficant share of the total so, for the record:
* I use Linux on my desktop. * I don't dual-boot to Windows * I don't use Linux because I want to run "linuxy applications" * I do prefer KDE on Linux as my desktop environment of choice * I am quite glad with my choice and I don't know about what inadequacies that I should grudgingly tolerate or even hate are you talking about * Obviously you are absolutly and utterly wrong.
"Let's get real here. As much as I love TeX/LaTeX, it's not widely used."
OK, let's get real then. *He* was talking about why *he* choiced Linux. You, on the other hand, are just talking about your opinions regarding how *others* will go.
"As a reason for switching, it [LaTeX integration] probably ranks below toe fungus"
I bet it ranks a bit higher for those (like the parent poster) that *do* use LaTeX.
"Does the job description of the new employee now include all of those skills..."
There's one thing I really don't understand, and it is the stupid assumptions regarding "IT skills" people tend to do.
An "IT proffesional" without a strong unix background is not an IT proffesional. Full stop.
Reading comments like yours is as awesome as it would be reading about an "accountant" that only "knows" Ms Money, and being worried about deploying double ledger because, hey, next beancounter maybe won't know about that.
"What happens if a project dies and support disappears for an application that has been adopted?"
It will happen that if you have access to its code base (and rights to maintain, modify and redistribute it) you will have options, and if it is closed source based you will be effectively fucked off.
"Yes, because every developer is conversant with C"
If they are not, then they are not developers, but "aficionados" at most.
"and knows how to code kernels"
Maybe they don't but then, if choices are trying to learn a bit of kernel hacking, while a competent external consultant fix it so migth be next time they don't need her services, or stay hand over hand while, maybe, an external company fix the problem being sure next time a problem arises they will need their services again and again, what's the problem?
"And you already have regression testing set up before you start making changes?"
Have you ever read Microsoft's standard disclaimer regarding hotfixes per chance?
"If you replace the Windows boxes in an IT dept. you're gonna have to update Standard Operating Procedures, Business Continuity Plans and licence documents."
So what? That's IT territory (at least the part that it *is* IT territory). As long as it works what the hell is going to do with it, say, an HR PHB after all? On the other hand, how many times are you, as a techie, consulted about what are the objectives, tools and manners the commercial policy of the company has to be deployed? Surely noone. Why? Because you have nothing to or say about it. The reverse (non-technical staff opinions regarding technical deployments) is just equally true.
"I don't know why IT techys would be allowed to handle the MS licencing issues all by themselves"
They don't have to. Some beancounter decided each box within the company needs to be alotted an Ms license? Then go with it. I don't see how that would interfere with my ability to install say, OpenBSD onto some of them if I decided that was the right tool for the job to be done and the worst case scenario is the beancounter, not me, is trashing company money because it took resonsabilities well out from his duty and technical abilities.
"you certainly can't do this realistically without having to tell anyone on *application* servers."
That's your *opinion*. Fact is that Mr Uemura already has done what you thing its undoable. And that he did it to great success too.
"This kind of approach is typically the kind of thing that gets you hated when you leave a position"
How is that possible? That you didn't tell anything to beancounters, HR bosses or even the CEO doesn't mean it is not properly documented in technical terms for technical staff. Or is it that the beancounter, HR or CEO is going to undertake your obligations once you leave? I bet not. It will be another technician who, again, will have to deal with technical issues the technical way.
"you're going to leave them with an undocumented mess"
If that's true, you are not a proffesional , so you are going to leave an undocumented mess after you no matter what. We are not talking here about that kind of people.
"Often times managers are more than willing to consider improvements [...] Instead, provide them with an analysis"
Then, you missed the whole point for the article.
The [quite sensible] point is DON'T TELL THE MANAGERS. At all.
Unless we are talking about IT managers, they have nothing to say regarding IT deployment. At most, they have a saying regarding *what* they want to achive, not *how* to achieve it. The "how" is what they hired you in first place. Don't ever ask for technical-related questions. If once in a while, there are political implications that overweigth the mere technical circumnstances (just as it is explained in the article regarding checkpoint firewalls -you read it, don't you?) don't worry, they'll tell you in proper time.
Of course this is quite much easier to acomplish when you play the open source card, since not having to buy licenses of use previously to deployment you won't have to tell beancounters what and why do you need the money for before-the-fact.
All they are expected to do is support the trust they desposited over me when they hired or fire me if they loose that confidence.
While it seems a bit of a dangerous position, it is not. They are going to fire you anyway if they loose confidence on you, and you have better chances to gain their confidence by working the way you know and doing things the way you know they are going to work (of course, I'm talking from the position you *really* know how to do your job, not such a usual situation).
"Okay, go to the head of a data storage center for Wal-Mart or Amazon and propose a data storage solution and end the propostion with "granted, there will be some down time". See how they respond"
I *know* how they'll respond. Still, I'm sure some companies based at Twin Towers were sold 100% uptime solutions that didn't stand for their claims on some 9/11, and almost noone of them would stand a clever and coordinated sabotage plan from company inside (not to talk about the almigthy Total Nuclear War Scenario, of course).
There is NO 100% uptime no matter what, and EVERY solution should end with a "granted, there will be some downtime" for downtime there WILL be. It is the question about how many time "some" means, what the affordable risk is and how much money is reasonable to drop at it. Only when a salesdrone meets a moron PHB something like "100% uptime guaranteed" makes sense.
"I actually work on commercial DAS Disk systems and they are designed for 100% uptime"
"The companies and groups that need this kind of performance would laugh at you if you proposed a solution and ended it with "granted, there is some down time"."
That's exactly why PHBs will prefer to believe that pretty colourful brochure that tells "just buy our solution and you will reduce downtime to zero". Of course, the brochure lies there *are* downtimes, no matter what, and anyone that doesn't end his proposition with "granted, there is some down time" is simply a liar. It is about how much insurance are you wanting to buy for how much money but at the very end, granted, there will be some down time.
"So you know how to use a dictionary, just like everyone who produces Engrish"
It is not that I looked the dictionary to find a word to annoy you, but that I looked at it *after* the fact just to support my already taken position. I used a word with a meaning and within a context I felt apropiate. Merriam-Webster just came to support my case.
"I bet you use gay to mean happy"
I don't really think so. English (or Engrish, whatever it is) is not my mother language, so I don't tend to use "elevated" words (with the exception, maybe, of those with Latin or Ancient Greek roots, only because probably they are already used in Spanish with plain clear meanings).
"Language is supposed to be about communication, not the most pedantic use of words."
Quite true. Then, try to learn what those words mean, not only to you, but to anyone that uses English (or Engrish, whatever it is), so the tool can be used to its most efficiency.
From the Merriam-Webster online dictionary: politics: [...] 5a: the total complex of relations between people living in society b : relations or conduct in a particular area of experience [...]
On the other hand, knowing the etymology for a word allows you to understand the whole semantic field for it, so you don't think people is "using creative meanings for words" just because they are not used the way *you* actually use them in "real life".
But of course it's pure politics! It is about people in society (polys) trying to find and stablish ways for cooperation. There's no technical benefit about using, say rj45 connectors to plug in your network cable instead of [any other standard], but there's a clear political [==social] benefit about standardizing which one to use.
Slashdot Mirror
"What it could also mean is that despite it being free, people still choose to pay quite a bit for something else !"
Unix folks are moving to Linux.
Windows folks are (partly) staying with what they know *or* (partly) moving to Linux.
For a party that had a very short market share gaining market share is a win.
For a party that started with something very near to a monopoly situation having the market know there are other choices *and* having (even only *some*) people going for those other choices is a terrible loose.
"IMHO, if it was a third party app and it failed every day then you ought to have been in a position to work this out for yourselves."
Please, note that if a third party app manages to crash out the operative system, it is still the Operative System's fault.
"Client commits a change to Node A. Node A queues the change to be sent to node B.
Node A explodes."
Then client either won't recieve an OK status for its transaction (since it won't be declared as commited till Node A recieves confirmation from node B and confirms again it has recieved that OK -we are talking now about 2PC, remember?) and it will retry or it will recieve that OK status from node B if the system is configured to do so in case of loosing node. It will then recieve either a timeout (if still trying against node A) or it will successfully commit via node B which still is up (if the system declared a transaction as effectively commited in such a case).
So what? The question still is that _under proper configuration_ loosing master-node doesn't mean loosing data (even worse: risking non-consolidated data)
"so you lose data if your primary master fails"
No, you won't.
Two phase commit, remember?
"You won't get any dependency problems installing KDE on Breezy. That's a plain lie."
Well, you can tell *others* this is a lie, but you can't tell that to me.
I *did* install Ubuntu (which installed Gnome by default using the "standard" procedure), I *did* executed `apt-get update` and `apt-get install kde` and I *did* get a broken dependencies message.
You can believe it or not; you can even test it by yourself, but you *cannot* tell me what I did and what did I saw with my own eyes.
"Wrong: All Ubuntu releases, including the first one, was based on Debian Unstable."
Yes; on a date when Testing and Unstable were basically the same due to Debian being frozen and Unstable not accepting anything too critical due to this (like Xorg or gcc 4 which were going into Experimental).
I'll repeat it: the farer Ubuntu is from current Debian Stable, the more work Ubuntu people will have to do to insure stability and integration for their releases (since they won't be able to rely so much on the "parent" distribution), and it is still to be seen if Ubuntu will have the power/interest on doing it.
"because distributions and vendors should be targeting the Linux Standards Base"
Why they should?
1/ LSB's only benefit is with respecting binary closed source software. But there're no sign that closed source vendors are going to support LSB at all: there's almost no software that officially support say LSB 1.0, and even when a company won't tell you they support Red Hat, but Red Hat ES 3.0 for instance.
2/ Last I reviewed we were on a capitalist society, thus no company should be doing nothing (not legally bound to) but trying to maximize profit. The day companies see targeting LSB is a way for maximizing profit, don't worry, they'll do.
"Ubuntu isn't going anywhere"
That's still to be seen.
Ubuntu had an easy start since they had a ton of money and an almost finished product (that date's Debian Sarge, which was almost frozen). Now Ubuntu is going away from Debian Stable (since they more or less follow Testing/Unstable) and the effects of using a more beta-quality master are already noticeable: Breezy Badger (current Ubuntu) is quite unpolished (few days ago I made a "clean install" then I tried to install KDE just to see it was not possible due to broken dependencies, for instance; that would never happen with Debian: they'd either distribute a *functional* KDE or no KDE at all). For Ubuntu to stay the "up to date easy Debian-like distribution" they seem wanting to be, it will mean they will have to through more and more money and more and more human force (they will be able to take less and less directly from Debian). For companies like Red Hat or SuSE it meant being almost at bankruptcy for *years*. Since now Linux is much more known and widely deployed than in the days RH or SuSE started maybe Ubuntu has a chance to abandon red numbers faster but, well, as I said at the beginning of this, that's still to be seen: it can be a succesful "corporate distribution", or it can go the way of, say, Progeny (which already tried to take the same niche).
"How important are these kinds of certifications really?"
It is not important, but essential when working on corporate environments.
"I assume they are really just a fancy way of saying "we support our software on this platform and are prepared to sell support and consulting services for our system running on it"
No: it is more saying we WON'T sell support and consulting UNLESS we previously said so (via a certification).
While it should be less of an issue when talking about open software (others will do what you don't want to), it is a must when talking about privative software, like it it the current case.
And it is currently a "clever" path for a "corporate distribution" to follow. An example: I work for a consultancy firm and we usually go with Red Hat when a client needs/wants say Oracle support. I would prefer using Debian, but the client mandates (and rightly so) a certified platform when it wants to deploy Oracle. But then, it means that our bosses prefer to go with CentOS when certification/support is not an issue in order to take advantage of our Red Hat "know-how". In the end it means that our company is much more savvy with Red Hat-like distributions, so in the end Red Hat gains kind of a "lock in" on us.
Maybe Ubuntu going this path will mean that in the future we will be able to go with the Ubuntu/Debian tandem instead of Red Hat/CentOS.
So what????
We are not talking here about everyone, but about YOU and YOUR software. It is TO YOU the one the license YOU choose should fit!
I think you focused the problem the wrong way.
You should think FIRST how do you want your software to be used and distributed, only THEN you should think about which license you should distribute your software with in order to achieve YOUR goals.
There is nothing as a "license mess". A license is only a written agreement between you and the one you share your software with, think about that. And then, you are lucky enough that you are not the first person in the world that wants to share his software with other people so you can take other's example. There are some license "templates" so widely used that they are even known by a generic name, like "the BSD" or "the GPL", that's all.
If one of those alreadly publicly known agreements fits you and your interests, pick it; if not, you will do as with any other 'a priori' agreement you would get into with other people: you would write it down, you would have it reviwed by an attorney and you'd stick with it.
And now, since you didn't tell us how do you want your software to be distributed, well, it's clear we can't help you about telling if there already is a commonly known "license template" you could use.
"First off, Linux, or rather GNU/Linux, is an operating system KERNEL."
Bullshit! It is not true neither what you literally say nor what you try to imply.
Not even a completely drunken RMS would state that the Linux KERNEL should have to be called GNU/Linux.
On the other hand, while even a recently showed RMS would state for all and every Linux Operative Systems (o collection, or "distro", or whatever the name you prefer) to be known as GNU/Linux mainly because the "marketing hype", I'd say (first he tried Lignux, with no success), it is quite clear that only distros coming from the FSF or accepting to entrust its ideals and objectives should be known as GNU/Linux.
Thus, "Debian GNU/Linux", but "Red Hat Linux", for instance.
"The truth is that no more than 1% of home users use Linux on the desktop, and only a tiny minority don't dual-boot with Windows.
The few people who do 'convert' to Linux, imho, often do so because they want to run Unixy applications, not because they prefer it as a desktop environment"
Well, if there is so few peple that use Linux exclusively, then even my single opinion must be a signficant share of the total so, for the record:
* I use Linux on my desktop.
* I don't dual-boot to Windows
* I don't use Linux because I want to run "linuxy applications"
* I do prefer KDE on Linux as my desktop environment of choice
* I am quite glad with my choice and I don't know about what inadequacies that I should grudgingly tolerate or even hate are you talking about
* Obviously you are absolutly and utterly wrong.
"Let's get real here. As much as I love TeX/LaTeX, it's not widely used."
OK, let's get real then. *He* was talking about why *he* choiced Linux. You, on the other hand, are just talking about your opinions regarding how *others* will go.
"As a reason for switching, it [LaTeX integration] probably ranks below toe fungus"
I bet it ranks a bit higher for those (like the parent poster) that *do* use LaTeX.
"Does the job description of the new employee now include all of those skills..."
There's one thing I really don't understand, and it is the stupid assumptions regarding "IT skills" people tend to do.
An "IT proffesional" without a strong unix background is not an IT proffesional. Full stop.
Reading comments like yours is as awesome as it would be reading about an "accountant" that only "knows" Ms Money, and being worried about deploying double ledger because, hey, next beancounter maybe won't know about that.
"What happens if a project dies and support disappears for an application that has been adopted?"
It will happen that if you have access to its code base (and rights to maintain, modify and redistribute it) you will have options, and if it is closed source based you will be effectively fucked off.
"Yes, because every developer is conversant with C"
If they are not, then they are not developers, but "aficionados" at most.
"and knows how to code kernels"
Maybe they don't but then, if choices are trying to learn a bit of kernel hacking, while a competent external consultant fix it so migth be next time they don't need her services, or stay hand over hand while, maybe, an external company fix the problem being sure next time a problem arises they will need their services again and again, what's the problem?
"And you already have regression testing set up before you start making changes?"
Have you ever read Microsoft's standard disclaimer regarding hotfixes per chance?
"If you replace the Windows boxes in an IT dept. you're gonna have to update Standard Operating Procedures, Business Continuity Plans and licence documents."
So what? That's IT territory (at least the part that it *is* IT territory). As long as it works what the hell is going to do with it, say, an HR PHB after all? On the other hand, how many times are you, as a techie, consulted about what are the objectives, tools and manners the commercial policy of the company has to be deployed? Surely noone. Why? Because you have nothing to or say about it. The reverse (non-technical staff opinions regarding technical deployments) is just equally true.
"I don't know why IT techys would be allowed to handle the MS licencing issues all by themselves"
They don't have to. Some beancounter decided each box within the company needs to be alotted an Ms license? Then go with it. I don't see how that would interfere with my ability to install say, OpenBSD onto some of them if I decided that was the right tool for the job to be done and the worst case scenario is the beancounter, not me, is trashing company money because it took resonsabilities well out from his duty and technical abilities.
"you certainly can't do this realistically without having to tell anyone on *application* servers."
That's your *opinion*. Fact is that Mr Uemura already has done what you thing its undoable. And that he did it to great success too.
"This kind of approach is typically the kind of thing that gets you hated when you leave a position"
How is that possible? That you didn't tell anything to beancounters, HR bosses or even the CEO doesn't mean it is not properly documented in technical terms for technical staff. Or is it that the beancounter, HR or CEO is going to undertake your obligations once you leave? I bet not. It will be another technician who, again, will have to deal with technical issues the technical way.
"you're going to leave them with an undocumented mess"
If that's true, you are not a proffesional , so you are going to leave an undocumented mess after you no matter what. We are not talking here about that kind of people.
"Often times managers are more than willing to consider improvements [...] Instead, provide them with an analysis"
Then, you missed the whole point for the article.
The [quite sensible] point is DON'T TELL THE MANAGERS. At all.
Unless we are talking about IT managers, they have nothing to say regarding IT deployment. At most, they have a saying regarding *what* they want to achive, not *how* to achieve it. The "how" is what they hired you in first place. Don't ever ask for technical-related questions. If once in a while, there are political implications that overweigth the mere technical circumnstances (just as it is explained in the article regarding checkpoint firewalls -you read it, don't you?) don't worry, they'll tell you in proper time.
Of course this is quite much easier to acomplish when you play the open source card, since not having to buy licenses of use previously to deployment you won't have to tell beancounters what and why do you need the money for before-the-fact.
All they are expected to do is support the trust they desposited over me when they hired or fire me if they loose that confidence.
While it seems a bit of a dangerous position, it is not. They are going to fire you anyway if they loose confidence on you, and you have better chances to gain their confidence by working the way you know and doing things the way you know they are going to work (of course, I'm talking from the position you *really* know how to do your job, not such a usual situation).
"Actually, Windows is up to version 2003 these days!"
Oh, that's nothing!
It is XP the amazing one! Everybody and his old aunt knows X is ten in roman numbers. P must be Petasomething, then.
So Windows XP is version Petasomething and then ten more.
Beat that!
"Okay, go to the head of a data storage center for Wal-Mart or Amazon and propose a data storage solution and end the propostion with "granted, there will be some down time". See how they respond"
I *know* how they'll respond. Still, I'm sure some companies based at Twin Towers were sold 100% uptime solutions that didn't stand for their claims on some 9/11, and almost noone of them would stand a clever and coordinated sabotage plan from company inside (not to talk about the almigthy Total Nuclear War Scenario, of course).
There is NO 100% uptime no matter what, and EVERY solution should end with a "granted, there will be some downtime" for downtime there WILL be. It is the question about how many time "some" means, what the affordable risk is and how much money is reasonable to drop at it. Only when a salesdrone meets a moron PHB something like "100% uptime guaranteed" makes sense.
"I actually work on commercial DAS Disk systems and they are designed for 100% uptime"
See what I said about salesdrones and PHBs.
"The companies and groups that need this kind of performance would laugh at you if you proposed a solution and ended it with "granted, there is some down time"."
That's exactly why PHBs will prefer to believe that pretty colourful brochure that tells "just buy our solution and you will reduce downtime to zero". Of course, the brochure lies there *are* downtimes, no matter what, and anyone that doesn't end his proposition with "granted, there is some down time" is simply a liar. It is about how much insurance are you wanting to buy for how much money but at the very end, granted, there will be some down time.
"So you know how to use a dictionary, just like everyone who produces Engrish"
It is not that I looked the dictionary to find a word to annoy you, but that I looked at it *after* the fact just to support my already taken position. I used a word with a meaning and within a context I felt apropiate. Merriam-Webster just came to support my case.
"I bet you use gay to mean happy"
I don't really think so. English (or Engrish, whatever it is) is not my mother language, so I don't tend to use "elevated" words (with the exception, maybe, of those with Latin or Ancient Greek roots, only because probably they are already used in Spanish with plain clear meanings).
"Language is supposed to be about communication, not the most pedantic use of words."
Quite true. Then, try to learn what those words mean, not only to you, but to anyone that uses English (or Engrish, whatever it is), so the tool can be used to its most efficiency.
"I was speaking English"
Ok then.
From the Merriam-Webster online dictionary:
politics: [...] 5a: the total complex of relations between people living in society b : relations or conduct in a particular area of experience [...]
On the other hand, knowing the etymology for a word allows you to understand the whole semantic field for it, so you don't think people is "using creative meanings for words" just because they are not used the way *you* actually use them in "real life".
"Nah, it's pure politics."
But of course it's pure politics! It is about people in society (polys) trying to find and stablish ways for cooperation. There's no technical benefit about using, say rj45 connectors to plug in your network cable instead of [any other standard], but there's a clear political [==social] benefit about standardizing which one to use.
"The dependency problems I had with SuSE were not casued by RPM; they were caused by trying to use RPMs not packaged by SuSE"
Why don't you try to use them on Windows XP?
So you use them because 'hey, SuSE uses rpm too'?
Then, please, try to use them in Windows XP because 'hey, after all they are just programs, and Windows uses programs too, doesn't it?'
"Forcing everyone to support a [...] standard for pure politics is pointless."
Interestingly enough, most of the times there's no other way nor any other interest to create a standard but politics!