I wouldn't be suprised to see them switch to an architecture based on Win2000/IIS5/SQL7/Exchange6 next year sometime. (Even if it takes twice as much hardware!) Don't think they've dropped the idea.
I know they haven't dropped the idea. That was what the outages and problems at Hotmail earlier this year were about, IIRC. I just don't think they'll ever manage the switch. If they can more power to them, but my experience is that the fundamental architecture of the MS products is antithetical to high performance and high reliability. They keep throwing more and more into the OS, but the only way I've ever seen to get reliability and performance is to reduce the overhead and number of places bugs can occur by reducing the amount of stuff in the system.
And if it's next year before they have an OS and software capable of handling Hotmail, that means that Janus is 4-5 years out because Hotmail is a fraction what's needed for what Janus is promising.
First off, a well designed NT box is faster and more stable than Linux. Period. You can argue personal experience all you want, but all that means is that you don't know how to build an NT box.
OK, then, if NT is faster and more stable, why is it that Microsoft's premier high-volume mail service, Hotmail, is running on FreeBSD and (IIRC) Solaris boxes, using Apache, exim, Oracle and a home-brew network file system? Seems to me that if NT can be more stable and have higer performance then it'd be easy to switch Hotmail over, and that if anyone could build a stable, high-performance NT box Microsoft itself could. The fact that they have failed at this task twice (that I know of) seems to indicate that NT just isn't up to it.
Second, I wasn't even talking about NT... I was talking about the upcoming Janus (Datacenter... whatever.) If you bothered to look at the white papers, you may have seen some very promising features.
The important ones of which have been stumping the best in the industry for quite a few years now. I'm sorry, but I just don't believe anyone has that many geniuses that they could have solved that many intractable problems this quickly and not have applied some of that to their existing software.
In short, I'll believe their promises about Janus when they can switch Hotmail over to NT, IIS, MS SQL Server and Exchange.
Ever notice how a lot of the increase in non-MS options came after the trial started? I don't think that's coincidence. MS is losing market share right now precisely because, with the trial going on, they can't use their position to threaten vendors into avoiding non-MS options without giving DoJ fatal ammunition to use against them.
The reason for the difference in treatment isn't company size, it's market control. When several companies are in the market and none of them has overwhelming control, what they do and how they play is less important because if one gets out of hand customers have an option to not deal with them. MS, however, is in a position where everyone effectively has to deal with them. It's similar to the difference between UPS and the power company. If UPS won't deal with you then you just go to a competitor, so how UPS decides which customers they want to serve isn't a critical matter. If the power company won't deal with you then you can't get electricity at all, so the power company is required by law to consider all customers equally as long as they can pay because if they don't the customer has no remedy.
A monopolist is in a position where the playing field is intrinsically not level. To claim that it should remain tilted in their favor because you don't want to tilt it in favor of would-be competitors ignores the current condition of the field. And if the DoJ sued RedHat for antitrust violations right now I'd condemn DoJ, not because I liked RedHat, but because anyone can go get SuSE or Debian or Caldera or any other Linux distribution and get exactly what RedHat is selling and run all the third-party software they could run under RedHat, hence RedHat is not in a monopoly position.
You're right, though. MS should not be destroyed. The worst fate that could befall them coming out of the trial is to be forced to themselves abide by the same APIs and methods they recommend everyone else use, and to publish interface and protocol specs for everything they use. For example, IE exposes a COM interface. MS itself tells anyone needing to display HTML to use the COM interfaces to create IBrowser objects and display through them. If MS is simply required to have Windows itself create and use IBrowser objects rather than bypassing their own APIs, the whole issue of browser integration goes away and any company that wants to can tie their browser into Windows as tightly as IE is, as long as they implement all the right functionality per spec.
There's nothing currently protecting the artist's rights when the medium is vinyl records, or cassette tapes, or CDs. There's nothing to prevent me from taking any printed book and copying it. Broadcast television can readily be taped and the tape duplicated. It doesn't look to me like artists of any stripe have much protection.
Oh, I forgot. There's this pesky thing called "copyright law". If I do any of the above sorts of copying, the artist can haul me into court and collect damages. So precisely why won't this same thing work for MP3s and the like, when it works for everything else?
And yes, I know copying MP3s is easier. It's a lot easier to scan and reproduce a book than it was 20 years ago, too. That hasn't led to technical restrictions on photocopiers, has it?
Did you know that of the $15 or $16 you spend on a CD in most CD stores, about $1 of that actually goes to the artist? I have no problem paying for music (free speech not beer), especially if I'm paying the artist and not financing some VP's new yacht. And you've just hit on the reason SDMI will fail. If the artist sells direct at $5/copy and gets to keep $4 of it (the rest goes to paying for a server and such), then even if 75% of the copies out there are pirated they're still making as much as they would have off the label where they were getting $1/copy. That's not counting the people who would pirate at $15/CD but will pay $5 for a legit copy. The RIAA's whole argument is predicated on the idea that the number of pirated copies is more important than the dollars in the artist's pocket. From the artist's POV I don't think that's the case, and if it isn't then SDMI through the RIAA is not in the artist's best interests.
In reply to the person who said you need to know your com port for windows, you don't. Windows correctly support plug and play. In fact in windows you don't need to know the irq, dma, io, etc. of your sound card. It doesn't matter if you can or not, why should you have to?
Well, you don't have to know the IRQ of your sound card. Until, of course, Windows decides it would be nice to set your sound card to the same IRQ as your network card. Then your sound stops working, your network stops working, and all Windows has to say is "System has detected a hardware conflict.". The user has no idea what that means, has no clue how to find out what the conflict is, and couldn't fix it if they did find out because Windows will proceed to use PnP to reconfigure things back to the (broken) way it thinks things should be as soon as you reboot (and you have to reboot to make any fix you try take effect).
At this point the Windows user calls me up, and I go in and disable the PnP crud, jumper or otherwise force the cards to the correct settings, cram the settings down Windows' throat and the whole thing works again. At least until the next time he upgrades something, at which point my fixes get erased and the box breaks again and I get another call. One good thing about Microsoft products: the repeat business keeps me in beer and pretzels.
It isn't directly relevant, but then neither is the original test. In the basic test with a small number of pages being hit, the server can get everything out of a RAM cache and you get a cache hit rate approaching 100%. The random/10E6 test is designed to push the opposite extreme, forcing most hits to miss the cache and show how well the server performs when it mostly has to hit the disk. Neither extreme is in itself likely in the real world, but together they give you an idea of how performance varies so you can evaluate where your site falls along the curve.
It is called sharing. You should not EXPECT anything if you were truly sharing with others.
Sharing implies that it goes both ways. My objection to most of the people who don't like the GPL is that they want it to be all one way: they get all the benefit from everyone else's code without letting anyone benefit from their code in return. Hence my preference for the GPL, which prevents them from doing that unless they come to me and negotiate terms directly.
Who needs a license to teach morals? Law and morals don't get along.;)
Possibly this is the problem. The GPL was written specifically to enforce a set of ethics, in particular the idea that if you want other people to share with you you should be willing to share with them, and I have no problem with using it for that purpose. Those who don't want to share are free to come to me and negotiate different terms
For me, the problem would be that they are benefitting from code I released freely without contributing anything back. And because they aren't releasing their version of the code freely, we can't even know if they have made modifications that could benefit everyone else if released freely.
I guess it boils down, for me, to the fact that part of the reason I would release code freely is to contribute back to the code base that I've benefitted from. If someone wants to benefit from my code, they can either come to me and negotiate terms that benefit me in return for use of the code, or contribute to the code base themselves ( which I consider to be of benefit to me ).
Not quite. If you incorporate the GPLd code into your program, you have to release the program under the GPL as well. If you don't, you're violating your license to use the GPLd code. Code under the LGPL is under different terms, but someone still needs to be able to rebuild your app against a newer version of the LGPLd code or you're in violation of the license on the LGPLd code.
You're right in that you don't have to actively give your code to anyone you don't give the binaries to if you incorporate GPLd code, but you can't prevent them from giving it to anyone else per the GPL either.
I think the disagreement is more over whether the right to use someone else's work for your profit is your freedom or an usurpation of their original intent in releasing the code freely. I will admit to being biased, I prefer the GPL.
You're joking, right? Have you actually gone to the CEO of any company and told him/her that it's time to shut down marketing? "They can just take the next 2 months off while we re-engineer the back end systems."
And you seem to forget one thing: it is not a business decision what the capacity of the equipment is. If the equipment can support X users at once, the business types have precisely three choices:
Limit the usage to no more than X users.
Buy more/larger equipment to handle a larger number of users
Have the number of users reduced to 0 when the equipment dies under an overload.
And option 2 takes time, time to get the equipment in, time to configure and test it, and time to roll it into production cleanly. If the CEO doesn't like it, I'm sorry but that doesn't change reality.
True, but two points. First, the Linux box is only the gateway, not the management console or the managed boxes. You can still manage things from your NT desktop box, and manage NT, Unix and other types of boxes. Second, those large customers need Tivoli. It's much like word processing: if you need to use MS Word, you buy whatever OS MS Word runs on. Considering that it's one box out of hundreds that needs to be replaced if Tivoli goes to a Linux-only gateway, that's not a big deal.
And I doubt those large customers will mind not having to worry about the management gateway crashing on a weekly basis.
If it were just kids, that wouldn't be bad. The problem is that the filtering required also applies to adult patrons per the very first paragraph in the article. I'm sorry, but telling me, as an adult, that I cannot see anything unsuitable for a 10-year-old smacks of Mommy/Daddy/Nanny-knows-best. Think about it: much material on the Viet Nam war would definitely qualify as "harmful" ( again, the standard stated in the first paragraph of the article ) for a 10-year-old, so libraries would be required to filter this out for adults. This is Not A Good Thing.
Yes, being rude is your right as a reader. Many stupid things are your right. That doesn't mean you have to excercise those rights. If he's made errors, you get your message across better by politely but clearly outlining what they were and why they were errors. You don't have to pussyfoot around it, but coming across as polite and articulate and rational is better than coming across as an idiot.
And if you absolutely must flame someone, at least be creative about it. I'm sorry but I would frankly be embarrassed to have to admit that "You ****head!" was the best I could come up with. In fact I wouldn't admit it, I'd either come up with something better or forget the whole matter.
Suing is possible under several laws, but often not profitable. Your best bet is to track down who the spammer gets their connectivity from ( their upstream provider ) and complain to them. Look at traceroute for the network immediately before the spammer's machines, and use whois to find who owns that network.
Yes, I've seen the other coverage. That's why the tone of the article seems so strange. And you're right about Boies. He not only pulls these things off, he does them with just the right timing and theatrical sense. Thing is, though, that all else about the deal aside, if AOL, which MS says is now so powerful that they can challenge MS in the marketplace, is afraid to annoy MS by dropping MS's browser in favor of one AOL owns, that only shores up the proposition that MS has a monopoly. It certainly doesn't help MS's case any.
Well, perhaps I'm biased myself, not liking Microsoft's positions and attitudes, but I find it strange that an MSNBC article is the only one favoring Microsoft on Colburn's testimony and AOL's plans. Everyone else was reporting that the judge was openly skeptical of what point MS was trying to make with this issue, and generally not making it sound like MS scored any points.
Eg.: Colburn's memo about dropping IE, which MS tried to make much of. They weren't happy to have Case's response to that memo brought in as well, in which Case basically said that dropping IE wasn't feasible due to repercussions from MS if they did that.
I'd classify the "script kiddies" as dangerous. My system is pretty much immune to them, sure, but their attempts create so much security-related "noise" that the attacks by truly competent crackers get buried in the logs under tons of garbage.
One problem: AT&T isn't being expected to just turn over the infrastructure. All they're being required to do is sell access to it to anyone willing to pay for it, on the same terms as they sell it to themselves. If, for example, AOL wants to access AT&T's new cable network, AOL will have to buy the bandwidth from AT&T and foot the cost of co-locating equipment at AT&T's cabling center. All that's being required is that AT&T seperate the transport bandwidth from the ISP services and sell bandwidth to any ISP that wants to pay for it, nothing more.
Think of it in terms of the phone system. The local loop was severed from long-distance service. The local telcos must give any long-distance company access to the local loop, but they are not obliged to give it away for free ( see the RBOCs' screams about the fees they have to pay CLECs for access to the CLEC's local loops for a prime example ).
I went through the warranty information for a bunch of my appliances. The closest any of the dozen-plus warranties comes to disclaiming the implied warranties of merchantibility and fitness for purpose is to state that they are limited to the warranty period ( usually 60-90 days ). Better than half of them make no mention of any limitations on the implied M/FFP warranties. Not a single one attempted the sort of blanket disclaimer UCC2B/UCITA attempts to legalize.
Having read the drafts, I would say that UCITA is less unacceptable than the original UCC2B draft. OTOH, having one leg amputated at the hip is less unacceptable than having both legs amputated, too. Neither is desirable. The best that can be said is that UCITA, in a few spots, provides almost the same rights to the consumer as they would have under UCC. That's not acceptable.
And nobody has yet presented an argument for why software companies should be allowed to live up to even minimal standards. Even a used car sold as-is still has to meet certain minimum safety standards, yet UCITA wouldn't even hold software makers to that minimal standard.
I would note that the "limited warranty" in most products that you refer to typically does not limit the warranties of merchantibility and fitness for purpose, which are what the shrink-wrap licenses disclaim. UCC2 only addresses those two warranties, and IMHO applying the rules for other warranties to them isn't correct. The two are different, and are treated differently by UCC2 itself. Almost always, reference to those additional terms is made in the before-sale paperwork, and the terms are available before you pay if you wish to review them.
Also, you keep coming back to the point that all warranties can be disclaimed under UCC2, as if this is somehow relevant. It isn't. The point I make is not that warranties cannot be disclaimed, but that under UCC2 they cannot be disclaimed in the way that shrink-wrap licenses do it and the way that UCC2B/UCITA would allow, which is a completely different point.
One final question. If the current shrink-wrap licenses are actually so acceptable under UCC2, why are the software companies so interested in pushing UCC2B/UCITA through, and why with terms so different from UCC2 so explicitly spelled out? It would seem that, if 2-217 was the only problem, it would be simpler to just print the shrink-wrap license seperately and require it to be signed at the time of sale than to lobby for changes in the law. This suggests that the software companies are worried about someone bringing a case, not under the terms of the shrink-wrap, but as a straight UCC2 case.
We'll just have to agree to disagree, then. There is no obligation of "obviousness."
UCC Article 2, paragraph 2-316, subsection 2, and I quote:
(2) Subject to subsection (3), to exclude or modify the implied warranty of merchantability or any part of it the language must mention merchantability and in case of a writing must be conspicuous, and to exclude or modify any implied warranty of fitness the exclusion must be by a writing and conspicuous. Language to exclude all implied warranties of fitness is sufficient if it states, for example, that "There are no warranties which extend beyond the description on the face hereof."
The language specifically says both "written" and "obvious". I would say that hidden inside the box so that you cannot read it until after you have paid is the exact opposite of "obvious" and/or "conspicuous".
And yes, all warranties can be disclaimed under the UCC. However, under UCC2 they cannot be disclaimed after payment is tendered and the goods are delivered ( ie. after you pay for the software and have the box in your hands ). All the portions of the UCC are worded such that delivery of the goods and acceptance of them by the buyer is considered sufficient evidence of a contract. The only question would be whether delivery of the goods occurs when the buyer takes physical possession of the software, or when the buyer opens the package containing the diskettes. I would suggest that, if you bought a car, paid in full and took possession of the keys, then found a tag in the ignition that said that by removing it you agreed to certain other terms not in the agreement you signed before you paid, you would be hard-pressed to find a judge who would rule that the dealer could modify the contract unilaterally after closing the sale.
I suspect that would fall under another section of the UCC, since that was a case of attempting to return goods which you did not order. It was also not so much a matter of anyone saying that you couldn't get a refund as of the vendor saying the refund was MS's responsibility and MS saying it was the vendor's responsibility.
If you were attempting a return due to the product being defective, UCC2B/UCITA gives Microsoft's and the vendor's behavior the force of law. That would simply not be acceptable in the case of any other goods, and regardless of whether you can practically get a refund or not I don't see a good philosophical reason to establish law saying you aren't entitled to a refund for defective goods.
I would take exception to several points here, in particular your statements about vendors disclaiming warranties. Under UCC Article 2, a vendor can only disclaim warranties of merchantability and fitness for purpose if they do so very explicitly and obviously and before payment is made for the goods. If they fail to do this, then the buyer has the right to cancel their acceptance of the goods if defects are found that render the product unfit for use. Under UCC2, the current shrink-wrap license disclaimers would not be valid because they are not made before payment is tendered. UCC2B/UCITA would allow such disclaimers to be valid. I simply fail to see what's so different about software that the terms of UCC Article 2 need to change, especially on this point.
Slashdot Mirror
I wouldn't be suprised to see them switch to an architecture based on Win2000/IIS5/SQL7/Exchange6 next year sometime. (Even if it takes twice as much hardware!) Don't think they've dropped the idea.
I know they haven't dropped the idea. That was what the outages and problems at Hotmail earlier this year were about, IIRC. I just don't think they'll ever manage the switch. If they can more power to them, but my experience is that the fundamental architecture of the MS products is antithetical to high performance and high reliability. They keep throwing more and more into the OS, but the only way I've ever seen to get reliability and performance is to reduce the overhead and number of places bugs can occur by reducing the amount of stuff in the system.
And if it's next year before they have an OS and software capable of handling Hotmail, that means that Janus is 4-5 years out because Hotmail is a fraction what's needed for what Janus is promising.
First off, a well designed NT box is faster and more stable than Linux. Period. You can argue personal experience all you want, but all that means is that you don't know how to build an NT box.
OK, then, if NT is faster and more stable, why is it that Microsoft's premier high-volume mail service, Hotmail, is running on FreeBSD and (IIRC) Solaris boxes, using Apache, exim, Oracle and a home-brew network file system? Seems to me that if NT can be more stable and have higer performance then it'd be easy to switch Hotmail over, and that if anyone could build a stable, high-performance NT box Microsoft itself could. The fact that they have failed at this task twice (that I know of) seems to indicate that NT just isn't up to it.
Second, I wasn't even talking about NT... I was talking about the upcoming Janus (Datacenter... whatever.) If you bothered to look at the white papers, you may have seen some very promising features.
The important ones of which have been stumping the best in the industry for quite a few years now. I'm sorry, but I just don't believe anyone has that many geniuses that they could have solved that many intractable problems this quickly and not have applied some of that to their existing software.
In short, I'll believe their promises about Janus when they can switch Hotmail over to NT, IIS, MS SQL Server and Exchange.
Ever notice how a lot of the increase in non-MS options came after the trial started? I don't think that's coincidence. MS is losing market share right now precisely because, with the trial going on, they can't use their position to threaten vendors into avoiding non-MS options without giving DoJ fatal ammunition to use against them.
The reason for the difference in treatment isn't company size, it's market control. When several companies are in the market and none of them has overwhelming control, what they do and how they play is less important because if one gets out of hand customers have an option to not deal with them. MS, however, is in a position where everyone effectively has to deal with them. It's similar to the difference between UPS and the power company. If UPS won't deal with you then you just go to a competitor, so how UPS decides which customers they want to serve isn't a critical matter. If the power company won't deal with you then you can't get electricity at all, so the power company is required by law to consider all customers equally as long as they can pay because if they don't the customer has no remedy.
A monopolist is in a position where the playing field is intrinsically not level. To claim that it should remain tilted in their favor because you don't want to tilt it in favor of would-be competitors ignores the current condition of the field. And if the DoJ sued RedHat for antitrust violations right now I'd condemn DoJ, not because I liked RedHat, but because anyone can go get SuSE or Debian or Caldera or any other Linux distribution and get exactly what RedHat is selling and run all the third-party software they could run under RedHat, hence RedHat is not in a monopoly position.
You're right, though. MS should not be destroyed. The worst fate that could befall them coming out of the trial is to be forced to themselves abide by the same APIs and methods they recommend everyone else use, and to publish interface and protocol specs for everything they use. For example, IE exposes a COM interface. MS itself tells anyone needing to display HTML to use the COM interfaces to create IBrowser objects and display through them. If MS is simply required to have Windows itself create and use IBrowser objects rather than bypassing their own APIs, the whole issue of browser integration goes away and any company that wants to can tie their browser into Windows as tightly as IE is, as long as they implement all the right functionality per spec.
Why?
There's nothing currently protecting the artist's rights when the medium is vinyl records, or cassette tapes, or CDs. There's nothing to prevent me from taking any printed book and copying it. Broadcast television can readily be taped and the tape duplicated. It doesn't look to me like artists of any stripe have much protection.
Oh, I forgot. There's this pesky thing called "copyright law". If I do any of the above sorts of copying, the artist can haul me into court and collect damages. So precisely why won't this same thing work for MP3s and the like, when it works for everything else?
And yes, I know copying MP3s is easier. It's a lot easier to scan and reproduce a book than it was 20 years ago, too. That hasn't led to technical restrictions on photocopiers, has it?
Did you know that of the $15 or $16 you spend on a CD in most CD stores, about $1 of that actually goes to the artist? I have no problem paying for music (free speech not beer), especially if I'm paying the artist and not financing some VP's new yacht. And you've just hit on the reason SDMI will fail. If the artist sells direct at $5/copy and gets to keep $4 of it (the rest goes to paying for a server and such), then even if 75% of the copies out there are pirated they're still making as much as they would have off the label where they were getting $1/copy. That's not counting the people who would pirate at $15/CD but will pay $5 for a legit copy. The RIAA's whole argument is predicated on the idea that the number of pirated copies is more important than the dollars in the artist's pocket. From the artist's POV I don't think that's the case, and if it isn't then SDMI through the RIAA is not in the artist's best interests.
In reply to the person who said you need to know your com port for windows, you don't. Windows correctly support plug and play. In fact in windows you don't need to know the irq, dma, io, etc. of your sound card. It doesn't matter if you can or not, why should you have to?
Well, you don't have to know the IRQ of your sound card. Until, of course, Windows decides it would be nice to set your sound card to the same IRQ as your network card. Then your sound stops working, your network stops working, and all Windows has to say is "System has detected a hardware conflict.". The user has no idea what that means, has no clue how to find out what the conflict is, and couldn't fix it if they did find out because Windows will proceed to use PnP to reconfigure things back to the (broken) way it thinks things should be as soon as you reboot (and you have to reboot to make any fix you try take effect).
At this point the Windows user calls me up, and I go in and disable the PnP crud, jumper or otherwise force the cards to the correct settings, cram the settings down Windows' throat and the whole thing works again. At least until the next time he upgrades something, at which point my fixes get erased and the box breaks again and I get another call. One good thing about Microsoft products: the repeat business keeps me in beer and pretzels.
It isn't directly relevant, but then neither is the original test. In the basic test with a small number of pages being hit, the server can get everything out of a RAM cache and you get a cache hit rate approaching 100%. The random/10E6 test is designed to push the opposite extreme, forcing most hits to miss the cache and show how well the server performs when it mostly has to hit the disk. Neither extreme is in itself likely in the real world, but together they give you an idea of how performance varies so you can evaluate where your site falls along the curve.
It is called sharing. You should not EXPECT anything if you were truly sharing with others.
Sharing implies that it goes both ways. My objection to most of the people who don't like the GPL is that they want it to be all one way: they get all the benefit from everyone else's code without letting anyone benefit from their code in return. Hence my preference for the GPL, which prevents them from doing that unless they come to me and negotiate terms directly.
Who needs a license to teach morals? Law and morals don't get along. ;)
Possibly this is the problem. The GPL was written specifically to enforce a set of ethics, in particular the idea that if you want other people to share with you you should be willing to share with them, and I have no problem with using it for that purpose. Those who don't want to share are free to come to me and negotiate different terms
For me, the problem would be that they are benefitting from code I released freely without contributing anything back. And because they aren't releasing their version of the code freely, we can't even know if they have made modifications that could benefit everyone else if released freely.
I guess it boils down, for me, to the fact that part of the reason I would release code freely is to contribute back to the code base that I've benefitted from. If someone wants to benefit from my code, they can either come to me and negotiate terms that benefit me in return for use of the code, or contribute to the code base themselves ( which I consider to be of benefit to me ).
Not quite. If you incorporate the GPLd code into your program, you have to release the program under the GPL as well. If you don't, you're violating your license to use the GPLd code. Code under the LGPL is under different terms, but someone still needs to be able to rebuild your app against a newer version of the LGPLd code or you're in violation of the license on the LGPLd code.
You're right in that you don't have to actively give your code to anyone you don't give the binaries to if you incorporate GPLd code, but you can't prevent them from giving it to anyone else per the GPL either.
I think the disagreement is more over whether the right to use someone else's work for your profit is your freedom or an usurpation of their original intent in releasing the code freely. I will admit to being biased, I prefer the GPL.
You're joking, right? Have you actually gone to the CEO of any company and told him/her that it's time to shut down marketing? "They can just take the next 2 months off while we re-engineer the back end systems."
And you seem to forget one thing: it is not a business decision what the capacity of the equipment is. If the equipment can support X users at once, the business types have precisely three choices:
And option 2 takes time, time to get the equipment in, time to configure and test it, and time to roll it into production cleanly. If the CEO doesn't like it, I'm sorry but that doesn't change reality.
True, but two points. First, the Linux box is only the gateway, not the management console or the managed boxes. You can still manage things from your NT desktop box, and manage NT, Unix and other types of boxes. Second, those large customers need Tivoli. It's much like word processing: if you need to use MS Word, you buy whatever OS MS Word runs on. Considering that it's one box out of hundreds that needs to be replaced if Tivoli goes to a Linux-only gateway, that's not a big deal.
And I doubt those large customers will mind not having to worry about the management gateway crashing on a weekly basis.
If it were just kids, that wouldn't be bad. The problem is that the filtering required also applies to adult patrons per the very first paragraph in the article. I'm sorry, but telling me, as an adult, that I cannot see anything unsuitable for a 10-year-old smacks of Mommy/Daddy/Nanny-knows-best. Think about it: much material on the Viet Nam war would definitely qualify as "harmful" ( again, the standard stated in the first paragraph of the article ) for a 10-year-old, so libraries would be required to filter this out for adults. This is Not A Good Thing.
Yes, being rude is your right as a reader. Many stupid things are your right. That doesn't mean you have to excercise those rights. If he's made errors, you get your message across better by politely but clearly outlining what they were and why they were errors. You don't have to pussyfoot around it, but coming across as polite and articulate and rational is better than coming across as an idiot.
And if you absolutely must flame someone, at least be creative about it. I'm sorry but I would frankly be embarrassed to have to admit that "You ****head!" was the best I could come up with. In fact I wouldn't admit it, I'd either come up with something better or forget the whole matter.
Suing is possible under several laws, but often not profitable. Your best bet is to track down who the spammer gets their connectivity from ( their upstream provider ) and complain to them. Look at traceroute for the network immediately before the spammer's machines, and use whois to find who owns that network.
Yes, I've seen the other coverage. That's why the tone of the article seems so strange. And you're right about Boies. He not only pulls these things off, he does them with just the right timing and theatrical sense. Thing is, though, that all else about the deal aside, if AOL, which MS says is now so powerful that they can challenge MS in the marketplace, is afraid to annoy MS by dropping MS's browser in favor of one AOL owns, that only shores up the proposition that MS has a monopoly. It certainly doesn't help MS's case any.
Well, perhaps I'm biased myself, not liking Microsoft's positions and attitudes, but I find it strange that an MSNBC article is the only one favoring Microsoft on Colburn's testimony and AOL's plans. Everyone else was reporting that the judge was openly skeptical of what point MS was trying to make with this issue, and generally not making it sound like MS scored any points.
Eg.: Colburn's memo about dropping IE, which MS tried to make much of. They weren't happy to have Case's response to that memo brought in as well, in which Case basically said that dropping IE wasn't feasible due to repercussions from MS if they did that.
I'd classify the "script kiddies" as dangerous. My system is pretty much immune to them, sure, but their attempts create so much security-related "noise" that the attacks by truly competent crackers get buried in the logs under tons of garbage.
One problem: AT&T isn't being expected to just turn over the infrastructure. All they're being required to do is sell access to it to anyone willing to pay for it, on the same terms as they sell it to themselves. If, for example, AOL wants to access AT&T's new cable network, AOL will have to buy the bandwidth from AT&T and foot the cost of co-locating equipment at AT&T's cabling center. All that's being required is that AT&T seperate the transport bandwidth from the ISP services and sell bandwidth to any ISP that wants to pay for it, nothing more.
Think of it in terms of the phone system. The local loop was severed from long-distance service. The local telcos must give any long-distance company access to the local loop, but they are not obliged to give it away for free ( see the RBOCs' screams about the fees they have to pay CLECs for access to the CLEC's local loops for a prime example ).
I went through the warranty information for a bunch of my appliances. The closest any of the dozen-plus warranties comes to disclaiming the implied warranties of merchantibility and fitness for purpose is to state that they are limited to the warranty period ( usually 60-90 days ). Better than half of them make no mention of any limitations on the implied M/FFP warranties. Not a single one attempted the sort of blanket disclaimer UCC2B/UCITA attempts to legalize.
Having read the drafts, I would say that UCITA is less unacceptable than the original UCC2B draft. OTOH, having one leg amputated at the hip is less unacceptable than having both legs amputated, too. Neither is desirable. The best that can be said is that UCITA, in a few spots, provides almost the same rights to the consumer as they would have under UCC. That's not acceptable.
And nobody has yet presented an argument for why software companies should be allowed to live up to even minimal standards. Even a used car sold as-is still has to meet certain minimum safety standards, yet UCITA wouldn't even hold software makers to that minimal standard.
I would note that the "limited warranty" in most products that you refer to typically does not limit the warranties of merchantibility and fitness for purpose, which are what the shrink-wrap licenses disclaim. UCC2 only addresses those two warranties, and IMHO applying the rules for other warranties to them isn't correct. The two are different, and are treated differently by UCC2 itself. Almost always, reference to those additional terms is made in the before-sale paperwork, and the terms are available before you pay if you wish to review them.
Also, you keep coming back to the point that all warranties can be disclaimed under UCC2, as if this is somehow relevant. It isn't. The point I make is not that warranties cannot be disclaimed, but that under UCC2 they cannot be disclaimed in the way that shrink-wrap licenses do it and the way that UCC2B/UCITA would allow, which is a completely different point.
One final question. If the current shrink-wrap licenses are actually so acceptable under UCC2, why are the software companies so interested in pushing UCC2B/UCITA through, and why with terms so different from UCC2 so explicitly spelled out? It would seem that, if 2-217 was the only problem, it would be simpler to just print the shrink-wrap license seperately and require it to be signed at the time of sale than to lobby for changes in the law. This suggests that the software companies are worried about someone bringing a case, not under the terms of the shrink-wrap, but as a straight UCC2 case.
We'll just have to agree to disagree, then. There is no obligation of "obviousness."
UCC Article 2, paragraph 2-316, subsection 2, and I quote:
(2) Subject to subsection (3), to exclude or modify the implied warranty of merchantability or any part of it the language must mention merchantability and in case of a writing must be conspicuous, and to exclude or modify any implied warranty of fitness the exclusion must be by a writing and conspicuous. Language to exclude all implied warranties of fitness is sufficient if it states, for example, that "There are no warranties which extend beyond the description on the face hereof."
The language specifically says both "written" and "obvious". I would say that hidden inside the box so that you cannot read it until after you have paid is the exact opposite of "obvious" and/or "conspicuous".
And yes, all warranties can be disclaimed under the UCC. However, under UCC2 they cannot be disclaimed after payment is tendered and the goods are delivered ( ie. after you pay for the software and have the box in your hands ). All the portions of the UCC are worded such that delivery of the goods and acceptance of them by the buyer is considered sufficient evidence of a contract. The only question would be whether delivery of the goods occurs when the buyer takes physical possession of the software, or when the buyer opens the package containing the diskettes. I would suggest that, if you bought a car, paid in full and took possession of the keys, then found a tag in the ignition that said that by removing it you agreed to certain other terms not in the agreement you signed before you paid, you would be hard-pressed to find a judge who would rule that the dealer could modify the contract unilaterally after closing the sale.
I suspect that would fall under another section of the UCC, since that was a case of attempting to return goods which you did not order. It was also not so much a matter of anyone saying that you couldn't get a refund as of the vendor saying the refund was MS's responsibility and MS saying it was the vendor's responsibility.
If you were attempting a return due to the product being defective, UCC2B/UCITA gives Microsoft's and the vendor's behavior the force of law. That would simply not be acceptable in the case of any other goods, and regardless of whether you can practically get a refund or not I don't see a good philosophical reason to establish law saying you aren't entitled to a refund for defective goods.
I would take exception to several points here, in particular your statements about vendors disclaiming warranties. Under UCC Article 2, a vendor can only disclaim warranties of merchantability and fitness for purpose if they do so very explicitly and obviously and before payment is made for the goods. If they fail to do this, then the buyer has the right to cancel their acceptance of the goods if defects are found that render the product unfit for use. Under UCC2, the current shrink-wrap license disclaimers would not be valid because they are not made before payment is tendered. UCC2B/UCITA would allow such disclaimers to be valid. I simply fail to see what's so different about software that the terms of UCC Article 2 need to change, especially on this point.