"Rounding is not a privilege you can just apply at will."
Yes I can, given the circumnstances.
"If you've studied engineering or physics"
I did.
"you know you that the amount of rounding you have to apply is precisely dictated by the precision of your input values and the calculations done on those numbers"
I know.
But!
"Either rounding too much or too adds unnecessary inaccuracy."
That's untrue. Well, exactly the untrue part is the "unnecessary" one. I am the one deciding how much accuracy I want for my published data. I can't offer better accuracy on the results than that from the input (so I can't sum up 3.5 plus 3.1 and say it's 6.60), but I can take out accuracy as much as I need/want it.
So yes: 9.890 *is* 9.9 as long as that's the precision I want/need for my result (note that I said it's 9.9, but I can't say it's 9.90).
"If you have to get there by rounding, you're cheating if you ask me"
Not at all: regarding physical measures, 99.9 covers everything from 99.85 to 99.94 when measured by more sensible means. 99.886 is well between the marks. Were I interested in the maximum "legal" precision, I'd have to say that 99.886 is 99.89, but if I don't want it, I'm safe. Heck, I could even say that 99.886% is 100% (three significative ciphers). It sound strange just because 100% "seems" to be nothing but the absolute celing but then, a measure of 49.886% is validly roundable to 50% if so I want (for whatever reason) to use only two significant ciphers (and now it doesn't sound extrange at all). What I can't do is operate that 50 and offer anything better than its significance.
"Anybody who knows they are/have been down 10 hours in a year know they didn't get to 99.900%, so if they round it and call it three nines, they are lying."
No, they are not: they are just reducing measure precision*1: a bridge 200m long doesn't become a bridge 200.25m long just by adding a 25cm brick at one side.
*1 Of course they can decide to reduce measure precision for some unveiled unethical reason but that's quite a different matter.
Obviously, five nines is better than four nines, exactly ten times better, but quite a lot of people would be satisfied enough with "only" four nines.
Not to talk about those people that want five nines but then are quite happy with the "for UNPLANNED downtime" clause, which makes only four nines or even less when "planned outime" is added to the equation.
It is NOT a breakthrough because ALL package dependency managers IN THE WORLD do exactly what Novell is announcing.
This is nothing but a marketroid bluff.
So "XASER3 Co" wants to upgrade in place to current Debian, Red Hat, SuSE, Ubuntu, Mandriva... you name it? They just need to publish a repository for that distribution and add it to the repository manager of choice (yum, apt, up2date... you name it). From that moment onwards, package A will only update if all their dependencies are met.
That, and nothing else, is what Novell is announcing as "breakthrough news". That if you deploy a Yast2-compatible repository and add it to the managed sources of the installation you can make a package (it really doesn't make difference if you distribute it under an open or a closed source) that depends exactly on kernel-image-2.4.37-1.0.3, so once installed, next security update from Novell, say kernel-image-2.4.37-1.1.0 won't install till you publish you new revision against it.
On Debian, to name one, exactly what Novell is announcing has been possible (and done by the people who knows his trade) for at least half a decade, probably more.
...Or, they can press the standards comitee so deb becomes a valid package format within ISO23360, or they could press the standards comitee so there appears some ISO23361 which uses deb instead of rpm, just for fun (or to see Red Hat raging, who knows), so your company can salivate even on deb packages, or...
As if "technical" had anything to do with "bussiness". Surprise: it doesn't.
"opposing forces have a much better chance of survival banding together and strategically cooperating in their efforts"
Who doubts it? It's only it won't happen because it can't happen.
"Bill Gates is sitting there thinking "Let them all fight each other. It saves us the effort"
Probably. But that's his advantage. No matter how clever a intimate collaboration between, say, Novell and Red Hat would be, that simply can't happen: they are two different companies which can't (*CAN'T*) collaborate on which is their central bussiness purpouse. They can collaborate (and do collaborate) on the kernel development, for instance, since while it's a central pillar within their structure is not their bussiness "raison d'etre"; but their central point is selling their image as "distributions"; they just can't loose their "significative advantage" to any collaborator.
"is one of Linux's biggest problems: Too much fragmentation. If distro developers could put their egos aside and combine forces to create distros with some semblance of popular recognition, Linux's fortunes may change."
As if Linux fortunes was of *any* interest of those that are in the market for the money.
If Mr Bill Gates could put his ego aside and combine forces with IBM's OS/2, or Digital's VAX, or even Sir Clive Sinclair's Spectrum, he could create some semblance of popular recognition (sounds ridiculous, doesn't it? And sounds ridiculous because it Mr Gates were there to "help" other companies, currently wouldn't be the fortune behemoth he is).
From a bussiness point of view, there isn't such a beast as "Linux".
There exists Red Hat; there exists Novell, there exists Canonical, just the same as there exists Microsoft. Gives Microsoft a dime about the future of, say, AutoDesk? Hell, no. Why it should?
Gives Red Hat a dime about Novell's future? Hell, no! who would expect anything else?
Red Hat has no more interest in aiding Novell than Windows 3.1 was to MacOS 5, and exactly for the same reasons: they are competing each other.
The fact that Microsoft has a current cuasi-monopoly on desktop computers doesn't add nothing to the fact that companies are there to figth each other for the money, not to create some semblance of anything.
"How can you have faith installing something you've never heard of?"
Through marketing forces, I suppouse. Exactly the same that Microsoft had to do back in its early days in order to create a market and cope it.
"Buy a windows pc and you're ready to go in 5 minutes"
Buy a red hat*1 pc and you're ready to go in 5 minutes.
"Install the OS and you're ready in a couple of hours"
You meant: "install a windows OS onto a pc which previously was tested for such a system and you're ready in a couple of hours (I personally know and use quite a lot of PCs you wouldn't be able to install Windows 95 to. I know and use quite a lot of PCs you wouldn't be able to install Windows XP to).
And now: install your red hat onto a red hat pc which previously was tested for such a system and you're ready in a couple of hours.
"But [Linux] it's nowhere near ready for the average home user."
So you take some facts out of context, extract the wrong conclusions out of it, and you still want to be taken seriously?
Now: the only think you could conclude out of your "study" is that there're quite more hardware "windows-ready" than "red hat ready". And that's news?
*1 You can change "red hat" for your favourity operative system of choice (note: not only linux-based; all what I said can be applied to *any* operative system).
"The crux of this article/interview is Linux 2.6 needs improving with old and/or less common hardware rigs. Your proposed extended solution is to radically refactor the entire kernel because, hey, modern hardware that the majority of us have can cope with it."
The crux of the proposition is that the problems on old/less common hardware are symptoms of a deep illness. Your standing is that we can forget about the illness because, hey, the symptoms don't affect so many people... currently.
"I can't tell you how many times the exact opposite has happened to me. I have had to spend hours getting X to work"
But did it crashed the entire machine? If not, then it isn't "the exact oposite".
"getting video up and running is much easier in Windows than Linux."
But when you have problems on Windows, did you learn something interesting that will help you next time, or is it time after time not about learning about how your OS works, but what's the current workaround for the problem at hand? For if it the second (and I bet it *is* the second) then again you are not in "the exact oposite" situation.
"my employer is a nonprofit which gets much of its project-specific funding from taxpayer dollars"
And your company is still doing this _for_a_profit_?
Now: The work is not yours, but your employer's (it's a "for hire"). Your employer is a nonprofit, then GPL is quite good for the case. And it reaches your objetives: you won't need an attorney at all to use it. You just need to follow the FSF guidelines.
"but have no idea how to even begin to put stuff on paper"
Don't you read your own words?
That's exactly the point when the software licensing attorney comes in. You already know what would you want to do with the software and know what the other part expects from the contract too. Know it's time for an attorney to translate it into legalesee.
"it's pretty sleazy to lock it away and claim that it's yours even after you've been paid for it"
Well, what does exactly mean "you have already been paid for it"?
Does this mean they will pay me for the hours it effectlively took me to write down the program? Is that enough?
What, then, about the costs in time and money it took me to learn my trade? What the time saving my client can get because I can reuse code from previous works? What if I feel proper that future clients will take advantage from the work already done?
Since there are so much variables (being the most important my ability to reuse my work, that doesn't exist in almost any other service) the only proper way to deal with it is negotiate a contract and bind to it. Maybe I will bill X if I only need to modify an already developed GPLed program (but then, we both have to bind to GPL terms); maybe I'll bill 2X if I code the whole bunch; maybe I will negotiate 3X if he wants non-exclusive rights to the source so he can ie, repackage and sell it to third parties; maybe my price will be 4X for an exclusive rights to the sources, maybe... Well, maybe we will have to discuss all the terms in extent and then clearly state them in a contract previous to start the works, yeah, this seems quite reasonable.
"None whatsoever, the client should retain the copyright"
Why? In any case, the client will know, not you.
Probably the computer you sent you message is full of software you don't own the copyright for (probably you don't have any single piece of software within you retain copyiright of) and, still, you are perfectly able to fullfill your needs about it. The fact we talk not about "off-the-shelve" but about "on-demand" software doesn't change the fact that the client *may* need full copyright passed to him, he may need non-exclusive access to the sources, maybe only guaranteed maintenance for a given period, or just a binary and then forget about you. Different situations, different needs.
"And what if they want to sell licenses to others to offset the cost they incurred?"
Due to current copyright laws, that's something that will have to be agreed upon by *both* parts, and accordingly expressed in a properly suited contract. Failing to have this clearly stated on advance may mean end up expending a lot of years and a lot of money to make it clear after the fact in front of a tribunal.
"The bottom line is if somebody pays you to create something to their specifications, then it's a work-for-hire, and they should get the copyright."
If that's your opinion, you just have to state it in legal form in the next contract to sign when you hire such a project. Other cases will vary.
"If you want to re-sell the work that they've already paid you for, then you should pay them for a license."
Maybe.
Or maybe *they* will have to pay me for a license if they want my technologies and know-how applied to the program they pay me to write.
All in all is a case-by-case scenario. As it has been already stated, there can't possible be an "EULA" on a "one-shot" project, since "EULA" are "pro-bono" license agreements which terms has been stated *previously* to the relationship between vendor and consumer. That's obvioulsy never the case on an "on-demand" work, so the case is easy: you talk with the client about her needs, you state what the rights you want to retain are, both parts negotiate and when an agreement is reached both parts pass the job to their respective legal representatives to reach a legal document that state the verbal agreement; both parts review the agreement and then sign on the marks.
"id you miss the part of my comment about Debian remaining compatible from release to release? Are you claiming Debian don't already do that?"
I do (in an aspect). While it is true that Debian tries hard to be compatible from release to release, compatible doesn't mean you can just take, let's say, Postfix from Potato and through it into Sarge (that's obviously true if we consider only the binary packages and their DLL dependencies, but it is equally true regarding package configuration tools, integration with other packages, etc.). What Debian means by "compatible from release to release" is that there will be a "soft" upgrade path from one Stable to the next.
But this comes at a prize. It is hard (and, sometimes, *real* hard) to find a proper upgrade path between versions (currently, for instance, Etch is going through one of these passages because they abandoned the hotplug/coldplug structure in favor of an all-udev one. XFree to XOrg won't be just overwritting one onto the other...). For some of those big changes it literally takes more than six months to find the *proper* upgrade path (it's good enough for other distributions just putting together some release notes saying you must manually uninstall some package and install and configure some other; not for Debian).
While it is true that there is quite a lothat can be done regarding the upgrading management systems from Debian (it uses the very logical "all frozen at a time" that made so good outputs in the past, but it shows now it can't properly scale to the behemoth Debian currently is), like defining "dependency rings", make heavy usage of "upgrade branches" and quite a lot of "dirty tricks" from configuration managers, I, like most Debian users, will prefer the old fashioned "all frozen at a time" to what most other distributions claim to be "stable" if there's no other path. But, of course I'd prefer even more a better paradigm that would insure faster upgrades (but probably no more than once a year), while only if that doesn't endangers current stability and multi-platform disponibility (seriously: it wouldn't be a charm finding that Etch on x86_64 doesn't work, sysadmin-wise, exactly the same than on a SPARC or an PA-RISC).
"Ok, so HOW does the SMS message get from your Exchange server to the cell phone exactly?"
He explicitly told he is not using Exchange, but Exim.
"the carrier's mail-to-sms gateway is up"
He explictly told he is sending SMSs directly from the Exim box through an old celullar connected to the server's serial port.
So: He is avoiding Exchange (quite a clever movement); he is avoiding the email-to-SMS gateway; he is avoiding the local Blackberry server, and he is avoiding the worldwide RIM NOC's.
All of them complex devices/structures (so they go agains the KISS principle, so they are error-prone) and terribly expensive.
Maybe on *some* situations, blackberry is the way to go, but there are *so* many situations and is the advantage *so* great to cover the great additional expenditures? I bet the answer for the most part is "a big NO".
Still, they are so cool and seems so modern, most PHB make their pants wet (on the other hand, unix MTA-to-SMS is so ugly and old fashioned... who minds it works for almost nihil?)
"As for sucky, I'd as easily interpret that to mean 'I am unfamiliar with the idiosyncrasies of this distro' or 'I am biased'."
You could. But not on a "professional environment", since talking about what you don't know is regarded as highly unprofessional in "my professional environment". By bloated I mean unnecessarily overfeatured in an non-organized fashion; by sucky, I mean that it sucks. Both are directly related to "fiscally irresponsible", as you put it.
"switch to a Debian-based distribution. Debian takes on the accountability for thorough testing and package integration"
And what makes you believe that such "thorough testing and package integration" will be found on other "Debian-based distributions", not being Debian itself?
"In a professional environment, you'd have a difficult time justifying your decisions using criteria such as 'bloated' and 'sucky'."
I wouldn't. 'Bloated and sucky' means 'error and bug-prone'. 'Error and bug-prone' means 'loosing money-prone', and 'loosing money-prone' means 'Big no-no' in every professional environment (at least when used in reference to making business decisions involving Linux).
"I dislike *using* RedHat OS'es because I don't like their admin tools (don't get along with hand-editing"
What you probably don't notize is that what you really dislike from Red Hat is that it has managed to be not "open" anymore. Of course the software is still open source-licensed but, as you yourself said, when you try to really *use* it, beyond the tone of redhat wizards and admin tools, you are pissed off; if you try to patch and recompile some tool you need, you loose "certificality" (whatever it means), so while its software is still open source, the distribution as a whole is much like Microsoft's "shared source": you can see it but, behold, you can't touch it.
"I have no problem with the company"
What you probably don't notize is that your disgust for the way Red Hat-the distribution works comes directly and unavoidingly because of the fact that Red Hat-the company *is* a sucessfull company. Being a company it is obvious it couldn't offer you support for whatever hack you migth do to the software they bundle; being a company they try really hard to reach as most niches as it can, and the biggest one is, obviously, that of Windows, and if taking the Windows niche means putting a lot of graphical wizards to ease things to the tone of mouse-driven sysadmins over there, so be it, even if that means you will never be able to use vi again on any file under/etc.
Slashdot Mirror
"Rounding is not a privilege you can just apply at will."
Yes I can, given the circumnstances.
"If you've studied engineering or physics"
I did.
"you know you that the amount of rounding you have to apply is precisely dictated by the precision of your input values and the calculations done on those numbers"
I know.
But!
"Either rounding too much or too adds unnecessary inaccuracy."
That's untrue. Well, exactly the untrue part is the "unnecessary" one. I am the one deciding how much accuracy I want for my published data. I can't offer better accuracy on the results than that from the input (so I can't sum up 3.5 plus 3.1 and say it's 6.60), but I can take out accuracy as much as I need/want it.
So yes: 9.890 *is* 9.9 as long as that's the precision I want/need for my result (note that I said it's 9.9, but I can't say it's 9.90).
"If you have to get there by rounding, you're cheating if you ask me"
Not at all: regarding physical measures, 99.9 covers everything from 99.85 to 99.94 when measured by more sensible means. 99.886 is well between the marks. Were I interested in the maximum "legal" precision, I'd have to say that 99.886 is 99.89, but if I don't want it, I'm safe. Heck, I could even say that 99.886% is 100% (three significative ciphers). It sound strange just because 100% "seems" to be nothing but the absolute celing but then, a measure of 49.886% is validly roundable to 50% if so I want (for whatever reason) to use only two significant ciphers (and now it doesn't sound extrange at all). What I can't do is operate that 50 and offer anything better than its significance.
"Anybody who knows they are/have been down 10 hours in a year know they didn't get to 99.900%, so if they round it and call it three nines, they are lying."
No, they are not: they are just reducing measure precision*1: a bridge 200m long doesn't become a bridge 200.25m long just by adding a 25cm brick at one side.
*1 Of course they can decide to reduce measure precision for some unveiled unethical reason but that's quite a different matter.
"SUSE is German"
No, it isn't. It's North American
"Of course, you can't find any bugs in Intel's driver because you can't see the source code"
Oh! that clearly explains why I find Windows XP being overly more bugfree than OpenBSD.
(/me ducks away)
"Use the preview button".
/me ducks
So I think I pressed "Submit" quite too fast.
Ok: 99.886% is three nines, but it is not four.
99.886->99.9->99.89.
"You mean for people who can't calculate."
Like you:
99.886% means 99.9% (three nines).
But, wait:
It means 99.99% too, and that's four nines!
Obviously, five nines is better than four nines, exactly ten times better, but quite a lot of people would be satisfied enough with "only" four nines.
Not to talk about those people that want five nines but then are quite happy with the "for UNPLANNED downtime" clause, which makes only four nines or even less when "planned outime" is added to the equation.
"My only experience with Exim is on Debian"
And certainly even that must be very short. Debconf actually asks you at install time if you want just one config file or a miriad.
"Never had any *verse package break my install."
Yet.
You've been warned.
"It is a breakthrough, because..."
It is NOT a breakthrough because ALL package dependency managers IN THE WORLD do exactly what Novell is announcing.
This is nothing but a marketroid bluff.
So "XASER3 Co" wants to upgrade in place to current Debian, Red Hat, SuSE, Ubuntu, Mandriva... you name it? They just need to publish a repository for that distribution and add it to the repository manager of choice (yum, apt, up2date... you name it). From that moment onwards, package A will only update if all their dependencies are met.
That, and nothing else, is what Novell is announcing as "breakthrough news". That if you deploy a Yast2-compatible repository and add it to the managed sources of the installation you can make a package (it really doesn't make difference if you distribute it under an open or a closed source) that depends exactly on kernel-image-2.4.37-1.0.3, so once installed, next security update from Novell, say kernel-image-2.4.37-1.1.0 won't install till you publish you new revision against it.
On Debian, to name one, exactly what Novell is announcing has been possible (and done by the people who knows his trade) for at least half a decade, probably more.
...Or, they can press the standards comitee so deb becomes a valid package format within ISO23360, or they could press the standards comitee so there appears some ISO23361 which uses deb instead of rpm, just for fun (or to see Red Hat raging, who knows), so your company can salivate even on deb packages, or...
"Actually, Debian universe and multiverse are in the /etc/apt.d/sources.list by default, they're just commented out by default"
Actually, they are commented out for a reason.
They surely will break your installation; it's only a matter of time.
And the more Ubuntu goes away from his Debian "father", the sooner "universe" will wreak havoc on your system.
"But from a technological standpoint"
As if "technical" had anything to do with "bussiness". Surprise: it doesn't.
"opposing forces have a much better chance of survival banding together and strategically cooperating in their efforts"
Who doubts it? It's only it won't happen because it can't happen.
"Bill Gates is sitting there thinking "Let them all fight each other. It saves us the effort"
Probably. But that's his advantage. No matter how clever a intimate collaboration between, say, Novell and Red Hat would be, that simply can't happen: they are two different companies which can't (*CAN'T*) collaborate on which is their central bussiness purpouse. They can collaborate (and do collaborate) on the kernel development, for instance, since while it's a central pillar within their structure is not their bussiness "raison d'etre"; but their central point is selling their image as "distributions"; they just can't loose their "significative advantage" to any collaborator.
"is one of Linux's biggest problems: Too much fragmentation. If distro developers could put their egos aside and combine forces to create distros with some semblance of popular recognition, Linux's fortunes may change."
As if Linux fortunes was of *any* interest of those that are in the market for the money.
If Mr Bill Gates could put his ego aside and combine forces with IBM's OS/2, or Digital's VAX, or even Sir Clive Sinclair's Spectrum, he could create some semblance of popular recognition (sounds ridiculous, doesn't it? And sounds ridiculous because it Mr Gates were there to "help" other companies, currently wouldn't be the fortune behemoth he is).
From a bussiness point of view, there isn't such a beast as "Linux".
There exists Red Hat; there exists Novell, there exists Canonical, just the same as there exists Microsoft. Gives Microsoft a dime about the future of, say, AutoDesk? Hell, no. Why it should?
Gives Red Hat a dime about Novell's future? Hell, no! who would expect anything else?
Red Hat has no more interest in aiding Novell than Windows 3.1 was to MacOS 5, and exactly for the same reasons: they are competing each other.
The fact that Microsoft has a current cuasi-monopoly on desktop computers doesn't add nothing to the fact that companies are there to figth each other for the money, not to create some semblance of anything.
"How can you have faith installing something you've never heard of?"
Through marketing forces, I suppouse. Exactly the same that Microsoft had to do back in its early days in order to create a market and cope it.
"Buy a windows pc and you're ready to go in 5 minutes"
Buy a red hat*1 pc and you're ready to go in 5 minutes.
"Install the OS and you're ready in a couple of hours"
You meant: "install a windows OS onto a pc which previously was tested for such a system and you're ready in a couple of hours (I personally know and use quite a lot of PCs you wouldn't be able to install Windows 95 to. I know and use quite a lot of PCs you wouldn't be able to install Windows XP to).
And now: install your red hat onto a red hat pc which previously was tested for such a system and you're ready in a couple of hours.
"But [Linux] it's nowhere near ready for the average home user."
So you take some facts out of context, extract the wrong conclusions out of it, and you still want to be taken seriously?
Now: the only think you could conclude out of your "study" is that there're quite more hardware "windows-ready" than "red hat ready". And that's news?
*1 You can change "red hat" for your favourity operative system of choice (note: not only linux-based; all what I said can be applied to *any* operative system).
"The crux of this article/interview is Linux 2.6 needs improving with old and/or less common hardware rigs. Your proposed extended solution is to radically refactor the entire kernel because, hey, modern hardware that the majority of us have can cope with it."
The crux of the proposition is that the problems on old/less common hardware are symptoms of a deep illness. Your standing is that we can forget about the illness because, hey, the symptoms don't affect so many people... currently.
"I can't tell you how many times the exact opposite has happened to me. I have had to spend hours getting X to work"
But did it crashed the entire machine? If not, then it isn't "the exact oposite".
"getting video up and running is much easier in Windows than Linux."
But when you have problems on Windows, did you learn something interesting that will help you next time, or is it time after time not about learning about how your OS works, but what's the current workaround for the problem at hand? For if it the second (and I bet it *is* the second) then again you are not in "the exact oposite" situation.
I think I don't get you.
"my employer is a nonprofit which gets much of its project-specific funding from taxpayer dollars"
And your company is still doing this _for_a_profit_?
Now: The work is not yours, but your employer's (it's a "for hire"). Your employer is a nonprofit, then GPL is quite good for the case. And it reaches your objetives: you won't need an attorney at all to use it. You just need to follow the FSF guidelines.
"but have no idea how to even begin to put stuff on paper"
Don't you read your own words?
That's exactly the point when the software licensing attorney comes in. You already know what would you want to do with the software and know what the other part expects from the contract too. Know it's time for an attorney to translate it into legalesee.
"it's pretty sleazy to lock it away and claim that it's yours even after you've been paid for it"
Well, what does exactly mean "you have already been paid for it"?
Does this mean they will pay me for the hours it effectlively took me to write down the program? Is that enough?
What, then, about the costs in time and money it took me to learn my trade? What the time saving my client can get because I can reuse code from previous works? What if I feel proper that future clients will take advantage from the work already done?
Since there are so much variables (being the most important my ability to reuse my work, that doesn't exist in almost any other service) the only proper way to deal with it is negotiate a contract and bind to it. Maybe I will bill X if I only need to modify an already developed GPLed program (but then, we both have to bind to GPL terms); maybe I'll bill 2X if I code the whole bunch; maybe I will negotiate 3X if he wants non-exclusive rights to the source so he can ie, repackage and sell it to third parties; maybe my price will be 4X for an exclusive rights to the sources, maybe... Well, maybe we will have to discuss all the terms in extent and then clearly state them in a contract previous to start the works, yeah, this seems quite reasonable.
"None whatsoever, the client should retain the copyright"
Why? In any case, the client will know, not you.
Probably the computer you sent you message is full of software you don't own the copyright for (probably you don't have any single piece of software within you retain copyiright of) and, still, you are perfectly able to fullfill your needs about it. The fact we talk not about "off-the-shelve" but about "on-demand" software doesn't change the fact that the client *may* need full copyright passed to him, he may need non-exclusive access to the sources, maybe only guaranteed maintenance for a given period, or just a binary and then forget about you. Different situations, different needs.
"And what if they want to sell licenses to others to offset the cost they incurred?"
Due to current copyright laws, that's something that will have to be agreed upon by *both* parts, and accordingly expressed in a properly suited contract. Failing to have this clearly stated on advance may mean end up expending a lot of years and a lot of money to make it clear after the fact in front of a tribunal.
"The bottom line is if somebody pays you to create something to their specifications, then it's a work-for-hire, and they should get the copyright."
If that's your opinion, you just have to state it in legal form in the next contract to sign when you hire such a project. Other cases will vary.
"If you want to re-sell the work that they've already paid you for, then you should pay them for a license."
Maybe.
Or maybe *they* will have to pay me for a license if they want my technologies and know-how applied to the program they pay me to write.
All in all is a case-by-case scenario. As it has been already stated, there can't possible be an "EULA" on a "one-shot" project, since "EULA" are "pro-bono" license agreements which terms has been stated *previously* to the relationship between vendor and consumer. That's obvioulsy never the case on an "on-demand" work, so the case is easy: you talk with the client about her needs, you state what the rights you want to retain are, both parts negotiate and when an agreement is reached both parts pass the job to their respective legal representatives to reach a legal document that state the verbal agreement; both parts review the agreement and then sign on the marks.
It's called a "contract".
"id you miss the part of my comment about Debian remaining compatible from release to release? Are you claiming Debian don't already do that?"
I do (in an aspect). While it is true that Debian tries hard to be compatible from release to release, compatible doesn't mean you can just take, let's say, Postfix from Potato and through it into Sarge (that's obviously true if we consider only the binary packages and their DLL dependencies, but it is equally true regarding package configuration tools, integration with other packages, etc.). What Debian means by "compatible from release to release" is that there will be a "soft" upgrade path from one Stable to the next.
But this comes at a prize. It is hard (and, sometimes, *real* hard) to find a proper upgrade path between versions (currently, for instance, Etch is going through one of these passages because they abandoned the hotplug/coldplug structure in favor of an all-udev one. XFree to XOrg won't be just overwritting one onto the other...). For some of those big changes it literally takes more than six months to find the *proper* upgrade path (it's good enough for other distributions just putting together some release notes saying you must manually uninstall some package and install and configure some other; not for Debian).
While it is true that there is quite a lothat can be done regarding the upgrading management systems from Debian (it uses the very logical "all frozen at a time" that made so good outputs in the past, but it shows now it can't properly scale to the behemoth Debian currently is), like defining "dependency rings", make heavy usage of "upgrade branches" and quite a lot of "dirty tricks" from configuration managers, I, like most Debian users, will prefer the old fashioned "all frozen at a time" to what most other distributions claim to be "stable" if there's no other path. But, of course I'd prefer even more a better paradigm that would insure faster upgrades (but probably no more than once a year), while only if that doesn't endangers current stability and multi-platform disponibility (seriously: it wouldn't be a charm finding that Etch on x86_64 doesn't work, sysadmin-wise, exactly the same than on a SPARC or an PA-RISC).
"Ok, so HOW does the SMS message get from your Exchange server to the cell phone exactly?"
He explicitly told he is not using Exchange, but Exim.
"the carrier's mail-to-sms gateway is up"
He explictly told he is sending SMSs directly from the Exim box through an old celullar connected to the server's serial port.
So: He is avoiding Exchange (quite a clever movement); he is avoiding the email-to-SMS gateway; he is avoiding the local Blackberry server, and he is avoiding the worldwide RIM NOC's.
All of them complex devices/structures (so they go agains the KISS principle, so they are error-prone) and terribly expensive.
Maybe on *some* situations, blackberry is the way to go, but there are *so* many situations and is the advantage *so* great to cover the great additional expenditures? I bet the answer for the most part is "a big NO".
Still, they are so cool and seems so modern, most PHB make their pants wet (on the other hand, unix MTA-to-SMS is so ugly and old fashioned... who minds it works for almost nihil?)
"As for sucky, I'd as easily interpret that to mean 'I am unfamiliar with the idiosyncrasies of this distro' or 'I am biased'."
You could. But not on a "professional environment", since talking about what you don't know is regarded as highly unprofessional in "my professional environment". By bloated I mean unnecessarily overfeatured in an non-organized fashion; by sucky, I mean that it sucks. Both are directly related to "fiscally irresponsible", as you put it.
"switch to a Debian-based distribution. Debian takes on the accountability for thorough testing and package integration"
And what makes you believe that such "thorough testing and package integration" will be found on other "Debian-based distributions", not being Debian itself?
"In a professional environment, you'd have a difficult time justifying your decisions using criteria such as 'bloated' and 'sucky'."
I wouldn't. 'Bloated and sucky' means 'error and bug-prone'. 'Error and bug-prone' means 'loosing money-prone', and 'loosing money-prone' means 'Big no-no' in every professional environment (at least when used in reference to making business decisions involving Linux).
"I dislike *using* RedHat OS'es because I don't like their admin tools (don't get along with hand-editing"
/etc.
What you probably don't notize is that what you really dislike from Red Hat is that it has managed to be not "open" anymore. Of course the software is still open source-licensed but, as you yourself said, when you try to really *use* it, beyond the tone of redhat wizards and admin tools, you are pissed off; if you try to patch and recompile some tool you need, you loose "certificality" (whatever it means), so while its software is still open source, the distribution as a whole is much like Microsoft's "shared source": you can see it but, behold, you can't touch it.
"I have no problem with the company"
What you probably don't notize is that your disgust for the way Red Hat-the distribution works comes directly and unavoidingly because of the fact that Red Hat-the company *is* a sucessfull company. Being a company it is obvious it couldn't offer you support for whatever hack you migth do to the software they bundle; being a company they try really hard to reach as most niches as it can, and the biggest one is, obviously, that of Windows, and if taking the Windows niche means putting a lot of graphical wizards to ease things to the tone of mouse-driven sysadmins over there, so be it, even if that means you will never be able to use vi again on any file under