Even if Microsoft produces a DRM-encumbered operating system for the XO-1, what makes you think a country will choose it over the freely-available Sugar-on-Fedora that the XO currently runs?
Has it been so long since OOXML that that question can be asked with a straight face?
I just don't see the point of running Sugar on top of Windows or Windows on the OLPC.
There is little point from the perspective of the end user. The point from the perspective of government decisionmakers will be that they are responding to money from Microsoft. The point from the perspective of Microsoft is that it is a way of maintaining their OS monopoly.
I'm not sure what the point is from the perspective of Negroponte, though.
Well, this is the old openness/freedom dichotomy, isn't it?
Not really. The objection the "fundamentalists" have is to Negroponte's apparent desire to rederict development resources currently devoted to improving Sugar-on-Linux to developing Sugar-on-Windows.
I doubt as many of the "fundamentalists" would be upset if Negroponte merely endorsed a plan by Microsoft to use their own resources to develop software for the OLPC including their own port of Sugar.
Yes, it's important to have a completely open solution so that users can, if they wish, control their own destinies.
Yes, it is. Which is why resources should not be taken away from the development of the completely open solution and devoted to porting part of that open solution to run on an alternative, proprietary, operating system.
(Of course, since the solution is completely open, there is nothing preventing those with a vested financial interested in promoting the alternative, proprietary operating system from expending their own resources to port any components they want of the open system to run on their own platform.)
Do you use your control of the hardware and the Sugar ends of the sandwich to make it difficult for them to slip XP in between?
Since Sugar is open source, nothing stops Microsoft from porting Sugar to XP if they want to sell XP on the OLPC to people who still want to use Sugar.
There is, however, little, if any, benefit to the stated goals of the OLPC project from putting resources into Sugar-on-Windows to offset the setback that results from taking effort away from improving Sugar-on-Linux.
Are people whose needs are best met by Linux going to abandon ship if they can run Sugar on Windows?
Perhaps not, but people whose needs are best met by Sugar are less likely to have their needs best met by Linux if the reason they can run Sugar on Windows is that resources that otherwise would have gone to making Sugar do what they needed on Linux were instead devoted to doing that on Windows.
Yet what is becoming more explicit with the resignation of Walter Bender is that for many involved in the project there was a strong element of Linux advocacy, such that Negroponte's flirtation with Microsoft is felt to be pure sacrilege.
Negroponte himself, until recently, viewed openness of every component as a key principle of the project, which is why offers from both Apple and Microsoft to provide a free-as-in-beer customized version of their respective flagship OS's as the primary OS for the project were rejected out of hand.
It should be unsurprising that a project that, from the top, embraced openness as a central precept has attracted lots of people for whom such openness is an important ideal, and who are quite disappointed when the leader of the project suddenly embraces a proprietary technology and suggests shifting effort to supporting that technology.
Especially when the whole culture around things like Ruby on Rails is "Convention over Configuration" (thus, your code should always be indented properly anyway)
"Convention over configuration" has nothing to do with indentation or other code format issues, it has to do with the balance between explicit setup (configuration) and implicit setup (convention).
and "Don't Repeat Yourself" (tons of 'end' statements isn't particularly DRY).
DRY has only, at most, a tangential relationship to "end" statements: its about repeating vs. reusing code, not about not repeating keywords.
The biggest problem a cascade of end statements is likely to be symptomatic of is using methods that are too big. This often goes along with violations of DRY (because if you are using big methods, there's a fair chance that you haven't factored bits out that are used in different places), but its not necessarily the same thing.
(Of course, it can also be a result of using deeply nested classes/modules, since they use a similar block structure to methods and code blocks.)
The main interpreter for is written in C, JRuby (an alternative implementation that is very popular) is pure Java, HotRuby runs the bytecodes for the YARV (Ruby 1.9) VM on JavaScript/Flash.
Open source, he said, creates a license 'so that nobody can ever improve the software,' he claimed
Er? WTF?
I think he has closed source and open source software mixed up. Open source licenses, pretty much by definition, allow anybody to improve the software. Closed source licenses, not so much.
There is a legitimate philosophical debate about the ability to profit from creation, but as long as these kind of outright lies which are absolutely backwards are going to be spread instead of making serious cogent arguments for the potentially legitimate points which might support the closed-source model, there is not really much to discuss here. Gates is, instead of making a serious argument, simply spreading outright lies to create FUD around open-source. Its not surprising, given the amount of personal financial interest at stake and his past behavior on the issue, but its still breathtakingly dishonest even considering the source.
Product placement is, at best, a necessary evil to fund content that is expensive to produce.
No, the business of commercial "broadcasters" (including those who "broadcast" online) is not to produce quality content, which is supported to the extent necessary by sponsorship, it is to sell advertising, a goal to which the creation of content that attracts eyeballs is a necessary supporting chore.
My understanding is that the WOTC gaming licenses give you some extra rights (for instance, you could use their skill and magic descriptions verbatim), but takes away others (you are given certain restrictions, such as requiring use of the D20 logo).
There were two main licenses, the Open Gaming License was a copyright license which let you use the material covered by their copyright with some restrictions; it is loosely analogous to an open-source software license.
The d20 System Trademark License, that both required and allowed the use of the D20 logo and some other "product identity" that was specifically excluded by the OGL actually restricted the rights otherwise granted by the OGL (without going back and checking, one of the big ones is that you can't publish a game with character creation or advancement rules under the d20 STL -- this was to assure that a major function of d20-logo products was to serve as support for and sell WotC's core books.)
I'm not criticizing WOTC, just saying that using their licenses are not the only way to write compatible rules and expansions.
Just the only way to do it if you aren't able to afford the legal fees (and risk of losing) to test the limits of the rather fluid boundary between merely similar game rules and material that is derivative of WotC's expression of those rules. Not a lot of companies in the gaming business can afford that uncertainty.
The Faceboogle concept assumes that I want to search just for those things which already match my existing online footprint.
When I search, however, it's usually because I want to find information on something NEW.
New to you, sure; but that doesn't necessarily mean that its something that people who have an otherwise-similar online footprint to you aren't also interested in. So its conceivable that "Faceboogle" might have some utility.
Then again, I doubt the correlation between different users online footprints and interests good enough to do much useful; while "others who are interested in what you have actively shown interest in also seem interested in foo" techniques have some value as one tool among many in product recommendations and advertising, particularly when there is an already somewhat limited domain of interest, I can't see anything like that substantially displacing search for, well, any of the things people use internet searches for.
OTOH, it could be one factor among various others in ranking personalized results in traditional searches, and if tuned well might be useful there. But that's not going to displace Google; if it is useful, Google will be one of the leading users.
The main benefit of running an app on Google's AppEngine is that the data will be stored in Google's highly scalable storage infrastructure (presumably BigTable).
Google AppEngine's Datastore API seems (currently) less featurific than Amazon's (also highly scalable) SDB, and could probably be implemented easily on top of SDB if you really wanted too -- or you could just use SDB from an AppEngine application running on EC2 (or, for that matter, running on Google's servers) and get the additional functionality.
Of course, SDB is a limited beta, so features some of the same developer-accessibility problems as AppEngine itself.
Can an industry that redefines itself every 18 months be regulated by a government organization that takes 60+ months to pass legislation regulating said industry?
The government organization that does regulation doesn't pass legislation at all.
And, except perhaps from a PR standpoint, there is no industry that "redefines itself every 18 months".
When your carefully nurtured trademark enters popular usage as a generic term for your product or service you are in deep shit.
As long as its a term for your product or service, you are fine. When it enters popular usage as a generic term for products or services in your market (as happened with Xerox and Kleenex), you're screwed. While Google is often used as a verb for running internet searches, its not really clear to me that its used in a brand-generic sense (as "search on the internet") rather than a brand-specific but engine-generic sense (as "search on the applicable Google service"). Lots of people I know use "Google" as a verb, but they all use Google search engines as, if not their only, their primary engines for "generic" searches, so when they say "Google it" or "I Googled it", they really mean "search(ed) on Google", not "search(ed) on the internet".
If you happen to build the next killer app on Google's system, Google has the right to use all of your data and trademarks for advertising and publicity.
Well, except that "data" is nowhere in that term that you quote, and that they can only use it for advertizing and publicizing the fact that you use the service. And, you know what, if I happen to build the next killer app on Google AppEngine, I have no problem with Google doing that. In fact, I'd much rather Google have the right to do that if it means I can try out my ideas without paying a cent to anyone before my "killer app" is, well, a "killer app".
"If you are fantastically successful, Google will be able to milk it for free publicity for the platform of theirs you used to build that success" isn't much of a drawback.
Of course this could work in your favor as it may bring further publicity to you, but one may surmise that if you've created such a presence that Google is interested in using it for their own gain; you don't need to ride their coat tails.
One could also surmise that if you built that kind of presence, its not really going to hurt you that Google is getting a boost from using your trademarks to advertise that you use Google AppEngine.
The SDK includes a standalone web server, so if you decide to move it off of Google's service, all you need to do is find somewhere to run that server.
The development environment it provides has some significant limitations.
What you get from Google is the free hosting and access to the Google hardware.
And Google user accounts. Which seems to me to be the main area of tie-in.
As a software developer and business owner why would I want to leave myself at the mercy of Google like this by being tied to their service?
Because the risk of Google failure is offset by the reduced early financial investment of building your own datacenter to host your apps; this is particularly the case for a startup. A well-designed system (with this as an initial consideration) shouldn't be hard to migrate off AppEngine if necessary.
Unless your question is why rely on Google rather than, e.g., Amazon; in which case, the current offerings (generously describing AppEngine as "current") aren't really targetted at the same kind of use; certain kinds of apps would be easier to do with AppEngine that Amazon's offerings, many that would possible on Amazon's framework aren't possible at all on AppEngine without using outside resources.
If you own a substantial, well-capitalized business, AppEngine may not offer, for the forseeable future, much you'd be interested in.
Front page on Slashdot. Wow, they sure dodged that bullet.
You miss the point. Sure, people were already talking about the app and its similarity to Campfire, and they'll now (briefly) talk about Google taking it down. But with it down, there is nothing to keep that conversation alive more than a couple days, whereas as long as the app was up it would be a continued source of discussion distracting from the aspects of Google AppEngine that Google wants people to talk about, which aren't really the sample applications except so far as they illustrate the capacity. Any sample app that draws attention mostly for other reasons is a distraction, not a useful sample for Google.
The J language (see "jsoftware.com") will seem bizarre and intimidating to those of you who are computer literate*, but it's a great way to cut the chase and start actually using the computer instead of wading through unessential language junk.
Just looking at it, it seems to have a rather peculiar, unintuitive syntax, and to use lots of symbols in ways which conflict with what people will expect from use outside of programming even moreso than most programming languages. It seems, contrary to your description, to be filled with unintuitive "language junk" that must be waded through to get at meaning.
It's interpreted, so you get immediate feedback, and it incorporates a lot of important concepts succinctly.
The first isn't really a special feature: you get an immediate environment with that capacity for immediate feedback with Ruby, Python, many Scheme implementations, Erlang, and too many other languages to lists. And the second, well, perhaps "succinctly" (in seems to be fond of two character operators), but certainly not intuitively.
*Computer Literate, adj.: Tame, tractable; willing to compensate for software deficiencies. - Gerald Weinberg
Ah, yes, way to pre-emptively insult anyone who disagrees with you.
The first language you learn frequently affects how you look at programming for the rest of your life.
Given the fundamental role of the lambda calculus, that makes using a language that directly expresses it a good idea.
I've seen too many people write FORTRAN with C, Scheme with C++, or Perl with Java.
Insofar as that's a problem at all, its a problem the other way, too.
Making the first programming language a functional language seems unwise.
Given the increasing importance of functional languages, to the point where other languages are evolving in the direction of adopting more of their features, I would argue that making the first programming language not a functional language or one with strong functional programming features would be unwise, from a vocational programming point of view (which seems to be your concern expressed above.) OTOH, given the fundamental role of the lambda calculus, I think teaching a first computer science using a language like Scheme (or another member of the Lisp family, though Scheme is probably the best learning language in that family) makes a lot of sense.
I took computer science AB when I was in highschool and it was a great class if you looked past the god forsaken code project you had to modify that had something to do with fish. I learned all about algorithms, data structures and other important topics that I would not have gotten formal exposure to until, well, never because I didn't major in CS. One huge drawback is that it's taught in Java now, which is absolutely terrible for learning the fundamentals (I took it when it was C++)
Which, IMO, is also terrible for learning fundamentals, about as bad as C++, though for slightly different reasons. When I took it, it was taught in Pascal, which was not too bad, IMO, for learning the fundamentals, though if someone asked me today what language I thought should be used at that level, I'd suggest Scheme (using more with the How to Design Programs approach than the Structure and Interpretation of Computer Programs approach.)
I wouldn't. Even with that much oil it still is going to run out someday.
Really, climate change is a more pressing issue than adequacy of the oil supply, and a bigger reason to get off of it. But the supply concern, such as it is, isn't so much running out of oil, its the increasing cost to extract oil. Part of the reason this field is potentially viable at all is, of course, that technology to extract oil has gotten better, but part of it is that the cost of extracting oil from existing fields has gone up. The supply constraint is about absolutely exhausting the oil supply, its about a long-term escalation in what has to be sacrificed for each barrel of oil extracted. If you look at a long-term graph of oil prices (adjusted for inflation) reaching back into the 1800's, you see that it is phenomenally expensive in the late 1800's when lots of uses for it were being discovered and exploration and extraction hadn't caught up, then it fairly quickly comes down to a fairly low prices, has a lot of fluctuations, and then recently shoots up to prices not seen since the initial high price period before there was much knowledge of where oil could be found and how it could be extracted effectively, and there is no evidence that that trend isn't going to continue.
I am hoping one or two countries stand up and say that how this standard was passed shows that all ISO standards are worthless.
Why? What does that do besides saving Microsoft the money and effort of corrupting future standards votes? Most ISO standards don't get this degree of corrupting influence applied, because most aren't being pushed by organizations whose vested interests are diametrically opposed to useful standards that are using standardization as a PR push and have the money to corruptly influence a substantial number of the world's national standards bodies. Discrediting international standards is strategically a bigger win for Microsoft than successfully corrupting an individual standards vote.
Slashdot Mirror
Has it been so long since OOXML that that question can be asked with a straight face?
There is little point from the perspective of the end user. The point from the perspective of government decisionmakers will be that they are responding to money from Microsoft. The point from the perspective of Microsoft is that it is a way of maintaining their OS monopoly.
I'm not sure what the point is from the perspective of Negroponte, though.
Not really. The objection the "fundamentalists" have is to Negroponte's apparent desire to rederict development resources currently devoted to improving Sugar-on-Linux to developing Sugar-on-Windows.
I doubt as many of the "fundamentalists" would be upset if Negroponte merely endorsed a plan by Microsoft to use their own resources to develop software for the OLPC including their own port of Sugar.
Yes, it is. Which is why resources should not be taken away from the development of the completely open solution and devoted to porting part of that open solution to run on an alternative, proprietary, operating system.
(Of course, since the solution is completely open, there is nothing preventing those with a vested financial interested in promoting the alternative, proprietary operating system from expending their own resources to port any components they want of the open system to run on their own platform.)
Since Sugar is open source, nothing stops Microsoft from porting Sugar to XP if they want to sell XP on the OLPC to people who still want to use Sugar.
There is, however, little, if any, benefit to the stated goals of the OLPC project from putting resources into Sugar-on-Windows to offset the setback that results from taking effort away from improving Sugar-on-Linux.
Perhaps not, but people whose needs are best met by Sugar are less likely to have their needs best met by Linux if the reason they can run Sugar on Windows is that resources that otherwise would have gone to making Sugar do what they needed on Linux were instead devoted to doing that on Windows.
Ruby 1.9 is available, and is bytecode compiled.
Negroponte himself, until recently, viewed openness of every component as a key principle of the project, which is why offers from both Apple and Microsoft to provide a free-as-in-beer customized version of their respective flagship OS's as the primary OS for the project were rejected out of hand.
It should be unsurprising that a project that, from the top, embraced openness as a central precept has attracted lots of people for whom such openness is an important ideal, and who are quite disappointed when the leader of the project suddenly embraces a proprietary technology and suggests shifting effort to supporting that technology.
"Convention over configuration" has nothing to do with indentation or other code format issues, it has to do with the balance between explicit setup (configuration) and implicit setup (convention).
DRY has only, at most, a tangential relationship to "end" statements: its about repeating vs. reusing code, not about not repeating keywords.
The biggest problem a cascade of end statements is likely to be symptomatic of is using methods that are too big. This often goes along with violations of DRY (because if you are using big methods, there's a fair chance that you haven't factored bits out that are used in different places), but its not necessarily the same thing.
(Of course, it can also be a result of using deeply nested classes/modules, since they use a similar block structure to methods and code blocks.)
The main interpreter for is written in C, JRuby (an alternative implementation that is very popular) is pure Java, HotRuby runs the bytecodes for the YARV (Ruby 1.9) VM on JavaScript/Flash.
Er? WTF?
I think he has closed source and open source software mixed up. Open source licenses, pretty much by definition, allow anybody to improve the software. Closed source licenses, not so much.
There is a legitimate philosophical debate about the ability to profit from creation, but as long as these kind of outright lies which are absolutely backwards are going to be spread instead of making serious cogent arguments for the potentially legitimate points which might support the closed-source model, there is not really much to discuss here. Gates is, instead of making a serious argument, simply spreading outright lies to create FUD around open-source. Its not surprising, given the amount of personal financial interest at stake and his past behavior on the issue, but its still breathtakingly dishonest even considering the source.
No, the business of commercial "broadcasters" (including those who "broadcast" online) is not to produce quality content, which is supported to the extent necessary by sponsorship, it is to sell advertising, a goal to which the creation of content that attracts eyeballs is a necessary supporting chore.
Its the paying customer that drives the business.
There were two main licenses, the Open Gaming License was a copyright license which let you use the material covered by their copyright with some restrictions; it is loosely analogous to an open-source software license.
The d20 System Trademark License, that both required and allowed the use of the D20 logo and some other "product identity" that was specifically excluded by the OGL actually restricted the rights otherwise granted by the OGL (without going back and checking, one of the big ones is that you can't publish a game with character creation or advancement rules under the d20 STL -- this was to assure that a major function of d20-logo products was to serve as support for and sell WotC's core books.)
Just the only way to do it if you aren't able to afford the legal fees (and risk of losing) to test the limits of the rather fluid boundary between merely similar game rules and material that is derivative of WotC's expression of those rules. Not a lot of companies in the gaming business can afford that uncertainty.
New to you, sure; but that doesn't necessarily mean that its something that people who have an otherwise-similar online footprint to you aren't also interested in. So its conceivable that "Faceboogle" might have some utility.
Then again, I doubt the correlation between different users online footprints and interests good enough to do much useful; while "others who are interested in what you have actively shown interest in also seem interested in foo" techniques have some value as one tool among many in product recommendations and advertising, particularly when there is an already somewhat limited domain of interest, I can't see anything like that substantially displacing search for, well, any of the things people use internet searches for.
OTOH, it could be one factor among various others in ranking personalized results in traditional searches, and if tuned well might be useful there. But that's not going to displace Google; if it is useful, Google will be one of the leading users.
Google AppEngine's Datastore API seems (currently) less featurific than Amazon's (also highly scalable) SDB, and could probably be implemented easily on top of SDB if you really wanted too -- or you could just use SDB from an AppEngine application running on EC2 (or, for that matter, running on Google's servers) and get the additional functionality.
Of course, SDB is a limited beta, so features some of the same developer-accessibility problems as AppEngine itself.
The government organization that does regulation doesn't pass legislation at all.
And, except perhaps from a PR standpoint, there is no industry that "redefines itself every 18 months".
Um, "gregarious"? WTF? "Egregious", maybe?
As long as its a term for your product or service, you are fine. When it enters popular usage as a generic term for products or services in your market (as happened with Xerox and Kleenex), you're screwed. While Google is often used as a verb for running internet searches, its not really clear to me that its used in a brand-generic sense (as "search on the internet") rather than a brand-specific but engine-generic sense (as "search on the applicable Google service"). Lots of people I know use "Google" as a verb, but they all use Google search engines as, if not their only, their primary engines for "generic" searches, so when they say "Google it" or "I Googled it", they really mean "search(ed) on Google", not "search(ed) on the internet".
Well, except that "data" is nowhere in that term that you quote, and that they can only use it for advertizing and publicizing the fact that you use the service. And, you know what, if I happen to build the next killer app on Google AppEngine, I have no problem with Google doing that. In fact, I'd much rather Google have the right to do that if it means I can try out my ideas without paying a cent to anyone before my "killer app" is, well, a "killer app".
"If you are fantastically successful, Google will be able to milk it for free publicity for the platform of theirs you used to build that success" isn't much of a drawback.
One could also surmise that if you built that kind of presence, its not really going to hurt you that Google is getting a boost from using your trademarks to advertise that you use Google AppEngine.
If (as I suspect most apps on AppEngine will) you make use of the Google Accounts integration in AppEngine, that's at least a mild form of "lock-in".
The development environment it provides has some significant limitations.
And Google user accounts. Which seems to me to be the main area of tie-in.
Because the risk of Google failure is offset by the reduced early financial investment of building your own datacenter to host your apps; this is particularly the case for a startup. A well-designed system (with this as an initial consideration) shouldn't be hard to migrate off AppEngine if necessary.
Unless your question is why rely on Google rather than, e.g., Amazon; in which case, the current offerings (generously describing AppEngine as "current") aren't really targetted at the same kind of use; certain kinds of apps would be easier to do with AppEngine that Amazon's offerings, many that would possible on Amazon's framework aren't possible at all on AppEngine without using outside resources.
If you own a substantial, well-capitalized business, AppEngine may not offer, for the forseeable future, much you'd be interested in.
You miss the point. Sure, people were already talking about the app and its similarity to Campfire, and they'll now (briefly) talk about Google taking it down. But with it down, there is nothing to keep that conversation alive more than a couple days, whereas as long as the app was up it would be a continued source of discussion distracting from the aspects of Google AppEngine that Google wants people to talk about, which aren't really the sample applications except so far as they illustrate the capacity. Any sample app that draws attention mostly for other reasons is a distraction, not a useful sample for Google.
Just looking at it, it seems to have a rather peculiar, unintuitive syntax, and to use lots of symbols in ways which conflict with what people will expect from use outside of programming even moreso than most programming languages. It seems, contrary to your description, to be filled with unintuitive "language junk" that must be waded through to get at meaning.
The first isn't really a special feature: you get an immediate environment with that capacity for immediate feedback with Ruby, Python, many Scheme implementations, Erlang, and too many other languages to lists. And the second, well, perhaps "succinctly" (in seems to be fond of two character operators), but certainly not intuitively.
Ah, yes, way to pre-emptively insult anyone who disagrees with you.
Given the fundamental role of the lambda calculus, that makes using a language that directly expresses it a good idea.
Insofar as that's a problem at all, its a problem the other way, too.
Given the increasing importance of functional languages, to the point where other languages are evolving in the direction of adopting more of their features, I would argue that making the first programming language not a functional language or one with strong functional programming features would be unwise, from a vocational programming point of view (which seems to be your concern expressed above.) OTOH, given the fundamental role of the lambda calculus, I think teaching a first computer science using a language like Scheme (or another member of the Lisp family, though Scheme is probably the best learning language in that family) makes a lot of sense.
Which, IMO, is also terrible for learning fundamentals, about as bad as C++, though for slightly different reasons. When I took it, it was taught in Pascal, which was not too bad, IMO, for learning the fundamentals, though if someone asked me today what language I thought should be used at that level, I'd suggest Scheme (using more with the How to Design Programs approach than the Structure and Interpretation of Computer Programs approach.)
Really, climate change is a more pressing issue than adequacy of the oil supply, and a bigger reason to get off of it. But the supply concern, such as it is, isn't so much running out of oil, its the increasing cost to extract oil. Part of the reason this field is potentially viable at all is, of course, that technology to extract oil has gotten better, but part of it is that the cost of extracting oil from existing fields has gone up. The supply constraint is about absolutely exhausting the oil supply, its about a long-term escalation in what has to be sacrificed for each barrel of oil extracted. If you look at a long-term graph of oil prices (adjusted for inflation) reaching back into the 1800's, you see that it is phenomenally expensive in the late 1800's when lots of uses for it were being discovered and exploration and extraction hadn't caught up, then it fairly quickly comes down to a fairly low prices, has a lot of fluctuations, and then recently shoots up to prices not seen since the initial high price period before there was much knowledge of where oil could be found and how it could be extracted effectively, and there is no evidence that that trend isn't going to continue.
Why? What does that do besides saving Microsoft the money and effort of corrupting future standards votes? Most ISO standards don't get this degree of corrupting influence applied, because most aren't being pushed by organizations whose vested interests are diametrically opposed to useful standards that are using standardization as a PR push and have the money to corruptly influence a substantial number of the world's national standards bodies. Discrediting international standards is strategically a bigger win for Microsoft than successfully corrupting an individual standards vote.