If you pay for support for 100 machines but are using that license to support 200 machines, I would guess that's illegal. Just because there's no tracking doesn't make it right. In any case, I won't dispute your numbers on the cost of the software or the support, as I never claimed either was cheaper. I was just pointing out that ESR was not addressing the actual argument at hand.
Also, are you seriously asking if MS provides support? Have you never heard of MS's Product Support Services (PSS)? That seems very hard for me to believe.
Once you've signed the agreement, Microsoft can come after you at will and blame you for folding their source into your product. You have to defend yourself, at great cost.
Assuming you actually did steal code and they could prove it, the same could be true of GPL'd code. I fail to see the significant difference.
Agreed, this is an important distinction in that there are options available. But what assurance do these companies have that someone out there will support it? And in practice, does this happen often? You have to keep in mind that the kind of companies MS is targeting with this campaign are generally very conservative.
In principle I agree with you. They *can* always switch to another provider or support it themselves. Unfortunately, the reality is that most enterprise level companies are very conservative and they *won't* do that. And I think it's those companies MS is targeting with this campaign.
I think ESR is being really disingenuous here and not really addressing the meat of MS's points at all. I wouldn't call it FUD, but he's certainly missing the argument and just responding snidely to them.
1. Claim that linux isn't free.
ESR seems to think all MS is talking about here is that it isn't free because it "has a nonzero TCO." Sure, that's part of it, but I think the argument goes deeper. The point is that the majority of corporate customers are not going to just download a freely available distribution of Linux, because most enterprise customers NEED support. Therefore, they are going to buy a supported distribution from a major Linux vendor, and that most certainly costs money. In that case it's most certainly not free (as in beer), and while it is still free (as in speech), those companies are not going to really exercise that freedom because they can't just modify their distribution and still expect support from the vendor.
2. Pretend that Shared source is the same as Open Source.
ESR's basically just belittles this statement, but again, there's some truth behind it. If you consider a company as above, namely, that they have bought a Linux vendor's distribution with support and they are not going to modify that distribution and lose their support. At that point, what IS the difference between 'Shared Source' and 'Open Source'? Either way, they're only looking at the source code and not modifying it. The only real difference I can see is that with Open Source (or really, Free Software) they could try to create a patch and get it into a future release in the hope that their vendor will pick it up and support it. This is really only marginally better than relying on your commercial software vendor for new features, because you're still dependent on some external entity (in this case, your vendor) and their decision making process to get that feature.
Quote on post: She explains why she feels Linux will overtake Windows as the number one operating system within the next three years.
Actual quote: Within the next three years I believe Linux will overtake Windows as the number one operating system based on new server shipments. [emphasis added]
But really, how many more total computers in the world could there be in three years compared to new servers? It's probably negligible.
It's beyond me why you think it's actually bad that you can P/Invoke into native code or use COM objects in managed code. Those are there for your benefit, precisely for the reason that MS knows they didn't (and couldn't) implement everything in the CLR libraries. Nobody is forcing you to use those features; they are there to help developers with backwards compatibility and to be able to use existing code without having to port it to the managed world. Sure, a lot of managed libraries are just wrappers to existing native code, but so what? As a developer writing in the managed world, you shouldn't care how the backend is implemented as long as it works as the contract specified.
Also, I have found the performance to be way better than any JVM, both in terms of pure running speed and GC intrusiveness. In fact, the runtime's generational GC algorithm is really quite elegant. So I'm really not sure what you have been looking at.
Calling it an "abomination" is beyond hyperbole. I mean, if.NET is so horrendously bad, where does that leave Java? It's extremely similar in syntax to C#, has far slower and clunkier windowing libraries, also allows you to invoke native code (albeit not as easily), is just as painfully slow (more, IMO), and the GC is worse. Going with your evaluation criteria, if.NET is an "abomination", than Java must be "vilest thing to ever spew from the bowels of the planet". I think we can agree that neither of those statements are true.
C# and the CLI are part of ongoing work by the ECMA standards group. Part of that is working on CLI extensions to C++. I can't say whether or not this is the same as what you saw in the C/C++ journal, since I haven't seen it and there is no link, but it could be.
So if they charge full price they get lambasted for ripping off non-profits and the education sector, and if they give discounts they get attacked for that, as well. If they gave it away for free we all know the same thing would happen, too.
Get off your high horse and give it a rest already.
Some people may be puzzled about why Microsoft is attacking Lindows and not doing the same for Red Hat - a leading Linux server company.
Some people may also be puzzled how anyone could possibly write this obviously false sentence and still sign their name. Trust me, Mike, no one is puzzled.
It's not fair use because the DMCA says its illegal. Fair use is not a constitutional right; it's granted by a specific piece of legislation. In this case, another piece of legislation has taken that right away. You're correct that it's not copyright infringment, but it's still illegal.
Actually it most certainly can be illegal because of something we call the DMCA. Don't confuse common sense with the law.
Logical fallacy
on
TiVo Will Die
·
· Score: 2, Insightful
Did anyone notice that the end made no sense with respect to the rest of the article? He goes through this whole argument about why TiVo will die, mostly centered around lower-priced competition coming in, but then his analysis is that the company is arrogant and unresponsive. Huh? Where did that come from? How did we get from Point A to Point B here? It sounds more like he feels snubbed, his poor journalistic pride got hurt, and so he decided to write an article on why this company is going down. Not that I think he's totally wrong, it's just that I think his motives are suspect and he's missing this thing called "logic" in his conclusion.
Yeah, it may be pretty insane how much effort they put into it, but many would argue that is one of the secrets to their success. Look at the difference between the Itanium and the Athlon64/Opteron now; the market does not seem to reward those who come up with completely new designs, even if they are superior.
One thing you're not considering is that they're not allowed to fix them. One of the rules in commercial apps is that you do not change API behavior after you've shipped it. This seems very strange to those who are accustomed to the Open Source world, but making sure you don't break customer's existing apps is more important than making sure an API always work correctly. The only exception to that rule is if the API is broken to the point of unusable AND there's no workaround. It's just different because non-commercial developers can just change the code so that it performs correctly without having too much concern for those who are relying on the incorrect behavior of an API. Commericial developers do not have that luxury.
In Windows NT 5.X, for example, the hard-wired nature of the one-second interval at which the balance set manager runs almost certainly allows an attacker with application-level access to crash the kernel more or less at will. Similarly, the hard 50:50 division of the available 32-bit memory space in NT 5.2 and earlier releases can be expected to cause serious application incompatibilities when some future service pack or new release changes that in the run-up to 64-bit system compatibility.
Anyone able to explain this quote? I'm fairly well versed in OS architecture, but I definitely don't see how an application could abuse that first point. I also don't understand how limiting an applications address space will cause compatibility problems in the future when there's more address space available. Can anyone explain?
Hear, hear. I think that's a spot on analysis of the differences between the OSs.
However, I think you're giving the author too much credit. For example, his underlying tone is that Unix is superior to Windows because of its tendency to keep designs more pure, up to date, and not to kludge as much. This completely overlooks the fact that Windows has put, up to now, HUGE emphasis on backwards compatibility, whereas Unix is far more accomodating to change. Again, this is also a reflection of Windows roots as a desktop OS (hardware is cheap, software base must be maintained) versus Unix roots on big iron (hardware is expensive, software can always be recompiled).
To build even more on what you said, you can see now that Windows is moving more towards the Unix camp with respect to application compatibility. This is evident in Win2K3 Server, which has no app compatability code in it at all, and even in the upcoming WinXP SP2, where MS has said that they will probably break some applications.
I don't think it's particularly wise to characterize either OS (or probably any OS, for that matter) as 'simple'. It's hard to say Linux is simple when you look at its monolithic kernel or X Windows, compared to Windows service model or GDI. Similarly, it's also difficult to say Windows is simple when looking at something like the registry compared to Linux's/etc/ files and nice state seperation.
The real answer to spam
on
Gates on Spam
·
· Score: 1
The only reason spammers continue to spam is that they make money on it. Why do they make money it? Because some small (or perhaps large, who knows) segment of people actually respond and buy stuff from it. If they were not making money off of it, they wouldn't do it.
So the ultimate solution to spam is for noone to ever click on it. Everytime you hear of someone falling for spam, they are hurting all of us. I really don't place too much blame on the spammers; they are just trying to make money. The people who respond are the ones who truly deserve the blame.
And, of course, all of the above also goes for telemarketers, as well.
Slashdot Mirror
Please don't be Alanis Morissette. There's nothing ironic about this. It just sucks, that's all.
If you pay for support for 100 machines but are using that license to support 200 machines, I would guess that's illegal. Just because there's no tracking doesn't make it right. In any case, I won't dispute your numbers on the cost of the software or the support, as I never claimed either was cheaper. I was just pointing out that ESR was not addressing the actual argument at hand.
Also, are you seriously asking if MS provides support? Have you never heard of MS's Product Support Services (PSS)? That seems very hard for me to believe.
Once you've signed the agreement, Microsoft can come after you at will and blame you for folding their source into your product. You have to defend yourself, at great cost.
Assuming you actually did steal code and they could prove it, the same could be true of GPL'd code. I fail to see the significant difference.
Agreed, this is an important distinction in that there are options available. But what assurance do these companies have that someone out there will support it? And in practice, does this happen often? You have to keep in mind that the kind of companies MS is targeting with this campaign are generally very conservative.
In principle I agree with you. They *can* always switch to another provider or support it themselves. Unfortunately, the reality is that most enterprise level companies are very conservative and they *won't* do that. And I think it's those companies MS is targeting with this campaign.
I think ESR is being really disingenuous here and not really addressing the meat of MS's points at all. I wouldn't call it FUD, but he's certainly missing the argument and just responding snidely to them.
1. Claim that linux isn't free.
ESR seems to think all MS is talking about here is that it isn't free because it "has a nonzero TCO." Sure, that's part of it, but I think the argument goes deeper. The point is that the majority of corporate customers are not going to just download a freely available distribution of Linux, because most enterprise customers NEED support. Therefore, they are going to buy a supported distribution from a major Linux vendor, and that most certainly costs money. In that case it's most certainly not free (as in beer), and while it is still free (as in speech), those companies are not going to really exercise that freedom because they can't just modify their distribution and still expect support from the vendor.
2. Pretend that Shared source is the same as Open Source.
ESR's basically just belittles this statement, but again, there's some truth behind it. If you consider a company as above, namely, that they have bought a Linux vendor's distribution with support and they are not going to modify that distribution and lose their support. At that point, what IS the difference between 'Shared Source' and 'Open Source'? Either way, they're only looking at the source code and not modifying it. The only real difference I can see is that with Open Source (or really, Free Software) they could try to create a patch and get it into a future release in the hope that their vendor will pick it up and support it. This is really only marginally better than relying on your commercial software vendor for new features, because you're still dependent on some external entity (in this case, your vendor) and their decision making process to get that feature.
She explains why she feels Linux will overtake Windows as the number one operating system within the next three years.
Actual quote:
Within the next three years I believe Linux will overtake Windows as the number one operating system based on new server shipments. [emphasis added]
But really, how many more total computers in the world could there be in three years compared to new servers? It's probably negligible.
What on earth are you talking about? Did you even read the post you're linking to?
Also, I have found the performance to be way better than any JVM, both in terms of pure running speed and GC intrusiveness. In fact, the runtime's generational GC algorithm is really quite elegant. So I'm really not sure what you have been looking at.
Calling it an "abomination" is beyond hyperbole. I mean, if .NET is so horrendously bad, where does that leave Java? It's extremely similar in syntax to C#, has far slower and clunkier windowing libraries, also allows you to invoke native code (albeit not as easily), is just as painfully slow (more, IMO), and the GC is worse. Going with your evaluation criteria, if .NET is an "abomination", than Java must be "vilest thing to ever spew from the bowels of the planet". I think we can agree that neither of those statements are true.
Wow, there's so much bullshit in that post I don't even know where to begin. And I thought the MS PR people were bad...
C# and the CLI are part of ongoing work by the ECMA standards group. Part of that is working on CLI extensions to C++. I can't say whether or not this is the same as what you saw in the C/C++ journal, since I haven't seen it and there is no link, but it could be.
Get off your high horse and give it a rest already.
Some people may also be puzzled how anyone could possibly write this obviously false sentence and still sign their name. Trust me, Mike, no one is puzzled.
It's not fair use because the DMCA says its illegal. Fair use is not a constitutional right; it's granted by a specific piece of legislation. In this case, another piece of legislation has taken that right away. You're correct that it's not copyright infringment, but it's still illegal.
Too bad he's still right.
Actually it most certainly can be illegal because of something we call the DMCA. Don't confuse common sense with the law.
Did anyone notice that the end made no sense with respect to the rest of the article? He goes through this whole argument about why TiVo will die, mostly centered around lower-priced competition coming in, but then his analysis is that the company is arrogant and unresponsive. Huh? Where did that come from? How did we get from Point A to Point B here? It sounds more like he feels snubbed, his poor journalistic pride got hurt, and so he decided to write an article on why this company is going down. Not that I think he's totally wrong, it's just that I think his motives are suspect and he's missing this thing called "logic" in his conclusion.
Yeah, it may be pretty insane how much effort they put into it, but many would argue that is one of the secrets to their success. Look at the difference between the Itanium and the Athlon64/Opteron now; the market does not seem to reward those who come up with completely new designs, even if they are superior.
One thing you're not considering is that they're not allowed to fix them. One of the rules in commercial apps is that you do not change API behavior after you've shipped it. This seems very strange to those who are accustomed to the Open Source world, but making sure you don't break customer's existing apps is more important than making sure an API always work correctly. The only exception to that rule is if the API is broken to the point of unusable AND there's no workaround. It's just different because non-commercial developers can just change the code so that it performs correctly without having too much concern for those who are relying on the incorrect behavior of an API. Commericial developers do not have that luxury.
Anyone able to explain this quote? I'm fairly well versed in OS architecture, but I definitely don't see how an application could abuse that first point. I also don't understand how limiting an applications address space will cause compatibility problems in the future when there's more address space available. Can anyone explain?
Pardon me, but how would you know how much attention Windows developers pay to any particular subsystem?
However, I think you're giving the author too much credit. For example, his underlying tone is that Unix is superior to Windows because of its tendency to keep designs more pure, up to date, and not to kludge as much. This completely overlooks the fact that Windows has put, up to now, HUGE emphasis on backwards compatibility, whereas Unix is far more accomodating to change. Again, this is also a reflection of Windows roots as a desktop OS (hardware is cheap, software base must be maintained) versus Unix roots on big iron (hardware is expensive, software can always be recompiled).
To build even more on what you said, you can see now that Windows is moving more towards the Unix camp with respect to application compatibility. This is evident in Win2K3 Server, which has no app compatability code in it at all, and even in the upcoming WinXP SP2, where MS has said that they will probably break some applications.
I don't think it's particularly wise to characterize either OS (or probably any OS, for that matter) as 'simple'. It's hard to say Linux is simple when you look at its monolithic kernel or X Windows, compared to Windows service model or GDI. Similarly, it's also difficult to say Windows is simple when looking at something like the registry compared to Linux's /etc/ files and nice state seperation.
1) is only true if you are a developer.
The only reason spammers continue to spam is that they make money on it. Why do they make money it? Because some small (or perhaps large, who knows) segment of people actually respond and buy stuff from it. If they were not making money off of it, they wouldn't do it.
So the ultimate solution to spam is for noone to ever click on it. Everytime you hear of someone falling for spam, they are hurting all of us. I really don't place too much blame on the spammers; they are just trying to make money. The people who respond are the ones who truly deserve the blame.
And, of course, all of the above also goes for telemarketers, as well.