No, it's not. That's natural selection, which is a subtly but distinctly different thing.
If you'd said that you came back the next summer and suddenly the rabbits in your field had been unable to successfully breed with other rabbits, that would have been something like evolution. (Speciation, anyway.) And if you'd said that all the rabbits had become leopards or something, that would have been evolution in action.
The point is that it's silly to deny that natural selection happens. Look at human beings and CCR5-(delta)32. That mutation makes a person resistant or immune to bubonic plague, and also incidentally to AIDS. Because the plague wiped out so many Europeans in the 14th century, the occurrance of CCR5-(delta)32 in people of European extraction is much, much higher than it is in people of other ethnicities. This explains why AIDS is much more devastating in Africa and Asia than it is in Europe and America. Natural selection happened in the European population 600 years ago. The people without resistance to plague and AIDS died in the late 1300's, so now their descendants are less susceptable to the disease.
But it's not the evolution that everybody gets up in arms about. We have seen organisms change over generations, through natural selection. We have even observed speciation, indirectly. But we have never seen an entire class or order of organisms evolve into a different class or order. We've never seen a rabbit evolve into a leopard. Not even through the fossil record have we seen this happen.
For obvious reasons: that sort of change happens, if it happens at all, over a timeline that's far too long for humans to observe.
Personally I think evolution is as good a theory as any. But it's not a fact. Not yet, anyway. And there's still plenty of room for belief in divine creation as opposed to evolution for explaining how we got here.
5. Therefore, free software's financial advantage is greater than the initial purchase price difference might imply.
You don't seem to be listening. Software licensing is a recurring charge in the same sense that real estate is a recurring charge: buildings fail (burn down, get old, whatever) or stop being sufficient, and must be replaced from time to time. That doesn't make real estate a recurring charge. It's a capital expense. The same is true of computer hardware and software. Why don't you understand this?
Free software has no financial advantage other than the initial purchase price, because you only pay for each software license one time. You don't have to pay for a software license more than once. Just like you don't have to pay for a building more than once. Buying one building this year, then moving to another building next year, does not mean you paid for any building twice. It means you made two capital expenditures on real estate in two consecutive calendar years. That's all.
Please stop confusing the issue by talking about replacement or upgrading as if it were a recurring charge. It's getting tiresome.
In fact, let's just put a stop to this right now. You're obviously confused-- you actually compared software licensing fees, which are capital expenses, to office supply costs, which are operating expenses. Computer hardware and software are not expendable, "just like office supplies," because when you buy a computer it becomes an asset and you carry the value of the asset on your books until it is depreciated. You don't carry the value of your office supply closet as an asset; it's not accounted for that way. And as for your argument that computer parts can't be replaced... that's simply bull. I refuse to accept that there are no "Vesa Local Bus RAID controllers" (whatever the hell that is) left on Earth. The truth, instead, is that you are unwilling to spend the time or money to acquire one. This makes sense if and only if it costs more to acquire a new "Vesa Local Bus RAID controller" than it costs to replace the entire computer in question, including all software, including the costs of implementing and integrating that new software. (Hint: that's probably not the case.) But whichever way you go, you're making a capital expenditure, not a recurring operating expenditure.
I don't know a better way to explain this, so I'm just going to give up now.
If you want to continue this argument, I suggest you find an accountant. Try to convince him that software licensing costs are operating expenses and should be accounted that way. He'll set you straight in short order, I'm quite certain.
The reason why we're talking past each other here is because you're not using the phrase "recurring charge" correctly. A recurring charge is something like a lease payment, or payroll: something that occurs more than once in a regular cycle and for which money is budgeted in advance. That's a recurring charge. If Company X charges you $10 per year to use their software-- using time-based nodelocked licensing, so the software stops working if you don't renew it-- that's a recurring charge.
What you're talking about is replacement, or enhancement. You gave two basic examples in your post: you talk about replacing a computer that "dies" with one that can't run your current software, and you also talk about replacing all or part of an existing system because your business requirements have changed. These are not examples of recurring charges; they're examples of replacement, or of enhancement.
If a computer dies-- no, wait, let's stop right there. There's really no such thing, you do realize that? A computer doesn't simply "die." A component-- even multiple components-- can fail. When that happens, it might be very expensive to replace the failed component. It's conceivable that it might even be impossible to replace it at all, but that's hard to imagine. So the real scenario you're proposing is that one or another component of a computer system has failed, and it's too expensive (in either dollars or in time spent) to replace it. So instead of replacing it, you just buy a whole new computer system that happens to be incompatible with your existing software.
That's fine and good. But it's a terrible way to run a business; replacing the failed component would certainly have been the more cost effective solution to your problem, once you figure in the time and energy needed to deploy new software on the new hardware. But if that's the path you choose to take, so be it. But it's not a recurring charge. It's a capital expenditure.
The same thing is true of your second example. If your business needs change and you decide to buy new hardware or software for your database server, that's a capital expenditure. It's not a recurring charge.
Let's draw an analogy here between software licensing costs and real estate costs. Your company buys a building; that's a one-time charge. (Assume for the moment that you buy it outright, instead of financing or leasing it.) If your company later outgrows that building and has to buy a newer, bigger one, that doesn't mean your real estate expenses are recurring charges. It just means you needed more than you had, so you had to buy it. The same is true if your building burns down. Rebuilding it doesn't make your real estate expenses into recurring charges.
Software licensing is not a recurring charge. The fact that you might plan to buy new software to replace existing software as the years go by doesn't mean software licensing fees-- a one-time capital expenditure-- are suddenly recurring charges. It just means that your software "wore out," so to speak, so you replaced or augmented it.
Back in the day, I used to work with some 3D animation houses as a sysadmin and all-around helpful guy. They were using Alias|WaveFront's PowerCaster and PowerTracer software to render single frames across multiple processors in an SGI server. The server had 24 R4400 processors running at, I think, 150 MHz each. For fun, I did a test where I rendered a frame on just one processor, then rendered the same frame on all 24 processors at once.
The 24-processor render was almost exactly 24 times faster than the 1-processor render. I mean, within a decimal point or something. It was uncanny.
Now, let's speculate. What if there were such a thing as a 3.6 GHz R4400? Would it have rendered that frame 24 times faster than the single 150 MHz R4400? Well, no, not unless it also had 24 times the cache and 24 times the memory bandwidth. The CPU would have just sat there waiting on data most of the time.
With a well-tuned algorithm, SMP across two processors can be considerably faster than simply doubling the clock speed of a single processor.
And then there's the issue of context switching in a single-processor environment. Right now I'm compiling on one CPU as I type this. If I had only one CPU, every time I did anything interactive, the CPU would have to context switch out of the compiler and into another process, handle my action, then switch back. Having two CPUs means context switches are reduced, making the system as a whole more efficient.
I dare say my 2 x 1 GHz box is better in most ways than a 1 x 2 GHz box would be.
Dude, I don't mean to be rude here, but you've got it wrong. As I said before, a warranty says, "In the event of failure, here's what we can do to help." An SLA says, "Within the given parameters, there will be no failure. If there is, we'll be in big trouble." They're totally different.
You also seem to be ignoring the fact that neither Microsoft nor Red Hat offer an SLA for their software. Given that fact, I have to wonder why we're having this conversation at all.
I think we're on the same side, here. I wouldn't base my business on Linux any more than I'd hire little Jimmy from down the street to be my CTO. But I think talking about SLAs just clouds the issue.
So if I want to upgrade my operating system from NT4 to Win2k
Stop right there. What is it, exactly, about Windows 2000 that makes Windows NT 4.0 servers stop working? You say Windows 2000 includes "bugfixes... that I require for continued operation," but you don't give any hint as to what that means. I'm sure if you did it would boil down to one of two things: you believe Windows 2000 is more secure than Windows NT 4.0, and you have cheerfully overlooked the more appropriate solution of keeping your servers behind a robust firewall; or you see new features or changes in Windows 2000 that you want, and are calling that a need.
I hate to keep bringing up this example, but my girlfriend's laptop hasn't been upgraded or changed in any way since 1999, when I bought it for her. She's happy with the laptop just the way it is; from the looks of things, she'll never upgrade.
Now, if she wanted to do something new with her laptop-- like run SQL Server 7.0 or something-- she'd need to replace it. That's obvious. But that's not the same as a recurring charge. She never has to pay anybody to use her laptop-- barring the electricity to charge the thing-- ever again.
Product end of life is something everyone has to deal with sooner or later, so the only way software license fees won't be recurring is if the upgrades are all free.
You've gone and done it again. A product upgrade is just that; an upgrade. It's a new thing, a thing that you haven't bought yet. If you want it, you have to pay for it. But you only have to pay for it if you want it. Nobody forces you to upgrade. Your remarks about trying to run SQL Server 7.0 under Windows NT 3 just illustrate the point: the only reason, in that example, for you to upgrade the NT 3 machine would be to add additional functionality that you didn't have before.
If./configure says clearly that I need a library and I can go to freshmeat or the application's website and download and install that library, I don't consider that to be a "problem".
Reconsider your definition of "problem." What you're describing is most definitely a dependency problem. It's just that you're happy with solving dependency problems.
Dude, you're just plain wrong. Windows server licenses charges are not recurring charges. You don't have to pay anybody if you want to continue using the same software you currently use. If people choose to buy software again-- for a new version or a second machine or whatever-- that's not the same thing as a recurring charge.
So wait, I'm confused. Are we talking about getting things fixed, or getting things for free? They're two different things. If we're talking about getting things fixed, I still say that there is no clear correlation between speed of bug fixes in the open source versus commercial models. You can find both instances of both fast and slow fixes in products from both sides of that fence.
I'm not saying this is what you're doing, but it just annoys me when I talk to open source advocates-- zealots, often, to be honest-- who propose a number of arguments in favor of open source non-commercial software, only to find that their arguments all boil down to either politics or cost. I do hope that's not what's going on here.
You know, you don't have to subscribe to software assurance. If you (as a company) prefer, you can just pay the one-time license fee per computer. You only run into SA if you take Microsoft up on one of their volume licensing plans.
Lots of people complain about the new licensing. But let's not forget that nobody's got a gun to your head. If you want, you can just pay full price for every computer in your company and be done with Microsoft forever.
Even MS is publicly admitting that their TCO is higher than the non-monopoly products, and that they must compete on value.
That's not true. MS says their price is higher, and that they must therefore compete on value. As we've already discussed elsewhere, price and total cost of ownership are very, very different things.
But that model brings up important questions of trust, reliability, and control. Just because anybody and his sister could release patches or updates to a product doesn't mean that I would accept them. How do I know the fix that John Doe #231 made is reliable? In order for me to trust it, it's going to have to go through a central authority that checks it, ensures compatibility with other fixes from other John Does, and stands behind their conclusions. This is basically no different from the closed-source model: one group, company, organization, or person has to sign off on all the code changes before I, as a user, am willing to depend on them.
I say that the "open source leads to faster fixes" argument just doesn't stand up to careful examination. It may be true that some open source projects fix their bugs very quickly, but it's equally true to say that some commercial software vendors fix their bugs very quickly. I don't accept that there's a strict correlation between the two things.
Slashdot Mirror
check out the excellent Foobar2000 win32 multiformat audio player
My lawyers will be contacting them shortly.
Evolution in action.
No, it's not. That's natural selection, which is a subtly but distinctly different thing.
If you'd said that you came back the next summer and suddenly the rabbits in your field had been unable to successfully breed with other rabbits, that would have been something like evolution. (Speciation, anyway.) And if you'd said that all the rabbits had become leopards or something, that would have been evolution in action.
The point is that it's silly to deny that natural selection happens. Look at human beings and CCR5-(delta)32. That mutation makes a person resistant or immune to bubonic plague, and also incidentally to AIDS. Because the plague wiped out so many Europeans in the 14th century, the occurrance of CCR5-(delta)32 in people of European extraction is much, much higher than it is in people of other ethnicities. This explains why AIDS is much more devastating in Africa and Asia than it is in Europe and America. Natural selection happened in the European population 600 years ago. The people without resistance to plague and AIDS died in the late 1300's, so now their descendants are less susceptable to the disease.
But it's not the evolution that everybody gets up in arms about. We have seen organisms change over generations, through natural selection. We have even observed speciation, indirectly. But we have never seen an entire class or order of organisms evolve into a different class or order. We've never seen a rabbit evolve into a leopard. Not even through the fossil record have we seen this happen.
For obvious reasons: that sort of change happens, if it happens at all, over a timeline that's far too long for humans to observe.
Personally I think evolution is as good a theory as any. But it's not a fact. Not yet, anyway. And there's still plenty of room for belief in divine creation as opposed to evolution for explaining how we got here.
5. Therefore, free software's financial advantage is greater than the initial purchase price difference might imply.
You don't seem to be listening. Software licensing is a recurring charge in the same sense that real estate is a recurring charge: buildings fail (burn down, get old, whatever) or stop being sufficient, and must be replaced from time to time. That doesn't make real estate a recurring charge. It's a capital expense. The same is true of computer hardware and software. Why don't you understand this?
Free software has no financial advantage other than the initial purchase price, because you only pay for each software license one time. You don't have to pay for a software license more than once. Just like you don't have to pay for a building more than once. Buying one building this year, then moving to another building next year, does not mean you paid for any building twice. It means you made two capital expenditures on real estate in two consecutive calendar years. That's all.
Please stop confusing the issue by talking about replacement or upgrading as if it were a recurring charge. It's getting tiresome.
In fact, let's just put a stop to this right now. You're obviously confused-- you actually compared software licensing fees, which are capital expenses, to office supply costs, which are operating expenses. Computer hardware and software are not expendable, "just like office supplies," because when you buy a computer it becomes an asset and you carry the value of the asset on your books until it is depreciated. You don't carry the value of your office supply closet as an asset; it's not accounted for that way. And as for your argument that computer parts can't be replaced... that's simply bull. I refuse to accept that there are no "Vesa Local Bus RAID controllers" (whatever the hell that is) left on Earth. The truth, instead, is that you are unwilling to spend the time or money to acquire one. This makes sense if and only if it costs more to acquire a new "Vesa Local Bus RAID controller" than it costs to replace the entire computer in question, including all software, including the costs of implementing and integrating that new software. (Hint: that's probably not the case.) But whichever way you go, you're making a capital expenditure, not a recurring operating expenditure.
I don't know a better way to explain this, so I'm just going to give up now.
If you want to continue this argument, I suggest you find an accountant. Try to convince him that software licensing costs are operating expenses and should be accounted that way. He'll set you straight in short order, I'm quite certain.
The reason why we're talking past each other here is because you're not using the phrase "recurring charge" correctly. A recurring charge is something like a lease payment, or payroll: something that occurs more than once in a regular cycle and for which money is budgeted in advance. That's a recurring charge. If Company X charges you $10 per year to use their software-- using time-based nodelocked licensing, so the software stops working if you don't renew it-- that's a recurring charge.
What you're talking about is replacement, or enhancement. You gave two basic examples in your post: you talk about replacing a computer that "dies" with one that can't run your current software, and you also talk about replacing all or part of an existing system because your business requirements have changed. These are not examples of recurring charges; they're examples of replacement, or of enhancement.
If a computer dies-- no, wait, let's stop right there. There's really no such thing, you do realize that? A computer doesn't simply "die." A component-- even multiple components-- can fail. When that happens, it might be very expensive to replace the failed component. It's conceivable that it might even be impossible to replace it at all, but that's hard to imagine. So the real scenario you're proposing is that one or another component of a computer system has failed, and it's too expensive (in either dollars or in time spent) to replace it. So instead of replacing it, you just buy a whole new computer system that happens to be incompatible with your existing software.
That's fine and good. But it's a terrible way to run a business; replacing the failed component would certainly have been the more cost effective solution to your problem, once you figure in the time and energy needed to deploy new software on the new hardware. But if that's the path you choose to take, so be it. But it's not a recurring charge. It's a capital expenditure.
The same thing is true of your second example. If your business needs change and you decide to buy new hardware or software for your database server, that's a capital expenditure. It's not a recurring charge.
Let's draw an analogy here between software licensing costs and real estate costs. Your company buys a building; that's a one-time charge. (Assume for the moment that you buy it outright, instead of financing or leasing it.) If your company later outgrows that building and has to buy a newer, bigger one, that doesn't mean your real estate expenses are recurring charges. It just means you needed more than you had, so you had to buy it. The same is true if your building burns down. Rebuilding it doesn't make your real estate expenses into recurring charges.
Software licensing is not a recurring charge. The fact that you might plan to buy new software to replace existing software as the years go by doesn't mean software licensing fees-- a one-time capital expenditure-- are suddenly recurring charges. It just means that your software "wore out," so to speak, so you replaced or augmented it.
Um...Isn't looking to Jefferson for the definitive answer in effect having one generation control the next?
When I find somebody presently living who's as wise as Jefferson was, I'll listen to him. Until then, the dead white male trumps.
Back in the day, I used to work with some 3D animation houses as a sysadmin and all-around helpful guy. They were using Alias|WaveFront's PowerCaster and PowerTracer software to render single frames across multiple processors in an SGI server. The server had 24 R4400 processors running at, I think, 150 MHz each. For fun, I did a test where I rendered a frame on just one processor, then rendered the same frame on all 24 processors at once.
The 24-processor render was almost exactly 24 times faster than the 1-processor render. I mean, within a decimal point or something. It was uncanny.
Now, let's speculate. What if there were such a thing as a 3.6 GHz R4400? Would it have rendered that frame 24 times faster than the single 150 MHz R4400? Well, no, not unless it also had 24 times the cache and 24 times the memory bandwidth. The CPU would have just sat there waiting on data most of the time.
With a well-tuned algorithm, SMP across two processors can be considerably faster than simply doubling the clock speed of a single processor.
And then there's the issue of context switching in a single-processor environment. Right now I'm compiling on one CPU as I type this. If I had only one CPU, every time I did anything interactive, the CPU would have to context switch out of the compiler and into another process, handle my action, then switch back. Having two CPUs means context switches are reduced, making the system as a whole more efficient.
I dare say my 2 x 1 GHz box is better in most ways than a 1 x 2 GHz box would be.
Perhaps the next thing we need is skinnable Swing? :-)
I think you typo'd here. Surely you meant to say, "the last thing we need is skinnable Swing."
The President nominates Supreme Court candidates, which are then confirmed by the Senate. It's not a party-based thing.
The SLA says what they will and won't cover.
Dude, I don't mean to be rude here, but you've got it wrong. As I said before, a warranty says, "In the event of failure, here's what we can do to help." An SLA says, "Within the given parameters, there will be no failure. If there is, we'll be in big trouble." They're totally different.
You also seem to be ignoring the fact that neither Microsoft nor Red Hat offer an SLA for their software. Given that fact, I have to wonder why we're having this conversation at all.
I think we're on the same side, here. I wouldn't base my business on Linux any more than I'd hire little Jimmy from down the street to be my CTO. But I think talking about SLAs just clouds the issue.
So if I want to upgrade my operating system from NT4 to Win2k
Stop right there. What is it, exactly, about Windows 2000 that makes Windows NT 4.0 servers stop working? You say Windows 2000 includes "bugfixes... that I require for continued operation," but you don't give any hint as to what that means. I'm sure if you did it would boil down to one of two things: you believe Windows 2000 is more secure than Windows NT 4.0, and you have cheerfully overlooked the more appropriate solution of keeping your servers behind a robust firewall; or you see new features or changes in Windows 2000 that you want, and are calling that a need.
I hate to keep bringing up this example, but my girlfriend's laptop hasn't been upgraded or changed in any way since 1999, when I bought it for her. She's happy with the laptop just the way it is; from the looks of things, she'll never upgrade.
Now, if she wanted to do something new with her laptop-- like run SQL Server 7.0 or something-- she'd need to replace it. That's obvious. But that's not the same as a recurring charge. She never has to pay anybody to use her laptop-- barring the electricity to charge the thing-- ever again.
Product end of life is something everyone has to deal with sooner or later, so the only way software license fees won't be recurring is if the upgrades are all free.
You've gone and done it again. A product upgrade is just that; an upgrade. It's a new thing, a thing that you haven't bought yet. If you want it, you have to pay for it. But you only have to pay for it if you want it. Nobody forces you to upgrade. Your remarks about trying to run SQL Server 7.0 under Windows NT 3 just illustrate the point: the only reason, in that example, for you to upgrade the NT 3 machine would be to add additional functionality that you didn't have before.
Never tell me the odds.
Would somebody please shoot this guy?
reentering our atmosphere and burining up like...FISHY FIREBALLS!
Not to be confused with the local Szechuan restaurant's seafood special, FIERY FISHBALLS!
Give a man a fish, you feed him for a day. Give a man a block of sodium he can fish with, you feed him for life.
Not a very impressive trick, considering his life span will be measured in hours at that point....
If ./configure says clearly that I need a library and I can go to freshmeat or the application's website and download and install that library, I don't consider that to be a "problem".
Reconsider your definition of "problem." What you're describing is most definitely a dependency problem. It's just that you're happy with solving dependency problems.
You claim to be fixing an error on my part by throwing out the phrase "for which they couldn't charge for?" That takes balls, dude.
Dude, you're just plain wrong. Windows server licenses charges are not recurring charges. You don't have to pay anybody if you want to continue using the same software you currently use. If people choose to buy software again-- for a new version or a second machine or whatever-- that's not the same thing as a recurring charge.
So wait, I'm confused. Are we talking about getting things fixed, or getting things for free? They're two different things. If we're talking about getting things fixed, I still say that there is no clear correlation between speed of bug fixes in the open source versus commercial models. You can find both instances of both fast and slow fixes in products from both sides of that fence.
I'm not saying this is what you're doing, but it just annoys me when I talk to open source advocates-- zealots, often, to be honest-- who propose a number of arguments in favor of open source non-commercial software, only to find that their arguments all boil down to either politics or cost. I do hope that's not what's going on here.
But it wasn't supposed to be a complaint, it was just supposed to be silly. Don't forget to laugh.
You seem to have forgotten to include the part where it was funny at all, though.
Microsoft is charging for something that should be free? When did this start?
About the same time they started giving away something for which they should have charged.
Jeebus, do we have to have another conversation about the difference between SMP and clustering??
Um. Hate to break it to you, but I have a 2 GHz Power Mac G4 right now.
Yup. Two processors at 1 GHz each. Works great.
You know, you don't have to subscribe to software assurance. If you (as a company) prefer, you can just pay the one-time license fee per computer. You only run into SA if you take Microsoft up on one of their volume licensing plans.
Lots of people complain about the new licensing. But let's not forget that nobody's got a gun to your head. If you want, you can just pay full price for every computer in your company and be done with Microsoft forever.
Even MS is publicly admitting that their TCO is higher than the non-monopoly products, and that they must compete on value.
That's not true. MS says their price is higher, and that they must therefore compete on value. As we've already discussed elsewhere, price and total cost of ownership are very, very different things.
But that model brings up important questions of trust, reliability, and control. Just because anybody and his sister could release patches or updates to a product doesn't mean that I would accept them. How do I know the fix that John Doe #231 made is reliable? In order for me to trust it, it's going to have to go through a central authority that checks it, ensures compatibility with other fixes from other John Does, and stands behind their conclusions. This is basically no different from the closed-source model: one group, company, organization, or person has to sign off on all the code changes before I, as a user, am willing to depend on them.
I say that the "open source leads to faster fixes" argument just doesn't stand up to careful examination. It may be true that some open source projects fix their bugs very quickly, but it's equally true to say that some commercial software vendors fix their bugs very quickly. I don't accept that there's a strict correlation between the two things.