Are you a lawyer? I've been reading the promise Microsoft made, and it's all gibberish to me. And I doubt that even the original lawyer who drafted it would actually understand what he had written.
As far as legalese goes, Microsoft's Community Promise is actually pretty clear.
Basically, they grant you the right to use their patents to the extent of implementing the standards they've released under the promise. But in order to qualify, you have to implement the whole standard. (This is not a 'gotcha' clause so they can sue you if you have a bug, it's a clause to ensure that you can't take the patent grant and use it in a totally different context by saying you started from the standard specification and removed functionality until only the patented piece was left, then re-expanded it out to a totally different thing.)
Once you've implemented the whole standard, you can even continue and add additional functionality to your implementation, so long as the original standard remains implemented. (This is in key contrast to Java's grants, which only apply if you implement exactly what they specify and nothing more -- that "and nothing more" part is what got Microsoft in trouble when they extended the syntax of J++ to include anonymous closures.)
If you ever sue Microsoft over any patents involved in the specification you're implementing under the promise, the protection of the promise and its patent grants to you dissolve. It's "don't sue us, and we won't sue you", just scoped to a single standard -- in other words, you could sue Microsoft over other patents not related to the standard without losing your patent grant.
It's also irrevocable. They can't just decide one day to no longer honor the (legally binding) promise.
Compared to Java's grant, which even ends up involving things like field-of-use restrictions once you get the TCK license involved, it's incredibly permissive. Under the Community Promise, had Google used C# in the same way they used Java, they would be completely in line with the terms of the promise.
You know that UAC thing people who use Windows like to complain about?
I have to laugh when I see self-proclaimed 'experts' disable UAC, solely because they're smart enough to know where the option to turn it off is; but apparently not smart enough to realize no matter how smart, competent, and safe of a user you think you are, it's never a good idea to run as root, even if you think you're Electronic Jesus who never makes mistakes. (There's considerable overlap between this group of 'experts' and the group of 'experts' who refuse to install MSE because they're 'too good' to need it.)
Microsoft can only go so far to protect its 'expert' users from themselves. At some point, the user's own stupidity is at fault. And a user's stupidity doesn't go away just because they're using a different OS.
> This attitude from Microsoft isn't new, but I don't really see them being able to execute the "extinguish" part of their normal plan on GPL/BSD/MIT licensed software. Instead I can see them at grassroots level trying to make their platform relevant and make sure people can hook into it, but they get left on the sidelines.
Microsoft is turning into IBM. Once the dominant player, but technology moved on and they didn't move fast enough to follow it and stay on top. IBM was blindsided by the PC revolution, Microsoft was blindsided by the mobile revolution.
I think it's the ultimate fate of any tech behemoth. As an organization grows in size, it naturally gets slower and less capable of rapid adaption to change; and in an ironic twist of fate, it also means the organization has enough resources to invest into research and toy projects that they end up pioneering the very paradigm shift that results in their downfall when they turn out to be incapable of embracing it.
IBM commercialized the PC and it spun out of their control when other people took the idea and iterated it faster and made it better. Microsoft has been toying with mobile/embedded/tablet ideas for well over a decade and in doing so undoubtedly laid the conceptual groundwork for what would become the iPhone and iPad. And unless the pace of technology innovation slows along with the fading of Moore's Law, Google, Facebook, and Apple -- today's behemoths -- will all likely end up in the same situation.
It's worth noting that Microsoft Research had the exact same idea back in 2007 with Volta, which was an implemention of the.NET CLR in Javascript so you could take the same.NET compiled assembly files that you run on your PC and run them without any plugins in a Javascript-capable browser.
They eventually ditched the idea in favor of a different approach with Script#, which is a C# compiler that compiles to Javascript instead of.NET bytecode; similar in concept to Google' GWT Java source to Javascript compiler.
> You mean as opposed to when he had the DoJ stand down over DOMA and got DADT repealed or used a tremendous amount of political capital to get healthcare reform?
A nearly full term presidency and you can only name three things he's done well (only one of which was a legislative 'victory', and I put 'victory' in quotes because healthcare reform should have ended up a lot less compromised than it ended up being; whereas DOMA and DADT were both Executive imperatives that he hemmed and hawed about for years -- and you can damn well expect the next Republican in the White House will just perform a complete about-face on DOMA enforcement and defense). So... talk about damning with faint praise.
Obama's problem is that he's been so anxious to compromise with the right on *everything*, that he starts the conversation with a compromise plan, which just ends up getting pulled even further to the right when the inevitable cries of "no that's not enough!" come out from the Repubs in response to it.
Who the hell thought it was a good idea to have dynamic content in a document description language? Notice you never hear about exploits-of-the-week like this for LaTeX !
That's a good question. Someone should be asking the people who put Javascript in Netscape the same thing! I mean, there's absolutely no use cases for having dynamic documents!
Take a look at the fundamental model. When you move a window in Windows, the app is notified and it has to respond. Try moving the window of an unresponsive app, it does not redraw because Windows is asking the app to redraw it.
Windows has had a retained-mode graphics system for the past 3 years as long as you don't disable desktop composition.
So really, even if MS adds the 2 standards to their Community Promise, that still doesn't mean you get anything useful - if you write a simple app that does nothing, you're fine. If you want DB access, or web serving, or a GUI.. you're still in the same problem as before.
Unless you're saying that you need Microsoft technology to provide useful software in the general sense, there's no reason to say that not being able to use ADO.NET makes C# any less useful of a language or Mono any less useful of a platform than the fact you can't use ADO.NET with C++ in GCC. Or with CPython. Or with Perl.
The CLI outlines a pretty thorough P/Invoke system which Mono supports, so you can use any DB library or GUI library you want with Mono. You're in no worse of a situation than you are with any other language.
GPL is certainly not the only free license. And what about people that go the "GPL\0for files in the \"GPL\" directory" way?
Well for the latter, obviously we'd fix the bug that allows poison null bytes to break a string, since that's a pretty serious security vulnerability in a web browser.
For the former, all of the following are valid in both HTML 4.01 Strict and XHTML 1.0:
Stallman is perfectly happy avoid using your service and resources. His issue is that he doesn't have an easy way to tell whether or not he *should* avoid you.
Sure he does. If Stallman wants to know whether a site's Javascript is under the GPL, he can just look for the text of the GPL included as a comment on the webpage or in the included JS file; since you're supposed to distribute a copy of the GPL along with any GPL'd code, right? I mean the requirement that the license is distributed along with the program is right there in section 1 of GPLv2.
It'd be fairly trivial for someone to put together a browser extension that refuses to execute any code that doesn't come with a copy of the GPL attached.
If the fact that nearly every HTTP response would end up at least 17k larger if the idea were to take off is too large to swallow; then just include a link to the GPL in one of a page's tags. It'd be just as easy for a user agent to check that as well.
Distribution compatibility and package management is a big problem for most, if not all developers, and has been for a very long time.
And it will be, for quite some time to come. Linux doesn't have a stable ABI, so it's very hard to deploy to. I'm pretty sure even the LSB's goals don't reach far enough to solve this fundamental problem.
If the companies can't survive without each other, what's the harm in letting them merge?
The companies might have a valid case about 'not being able to survive without each other' if they didn't make almost suicidally bad business decisions like paying Howard Stern 300 million dollars only to find out he can't bring in enough subscribers to even break even on his paycheck.
And if they were to have failed individually, I'm sure there are plenty of buyers who'd love to have gotten their assets and put together a profitable satellite radio company with their current subscriber numbers.
Instead they got what amounts to a bailout -- except instead of dollars, the currency of their bailout is fair competition to the benefit of consumers in a market that's now effectively being made into a government approved, privately maintained monopoly
Of course, the merger comes with strict conditions to keep things in the public interest.
Conditions like the conditions XM and Sirius were originally given when they were granted space on the spectrum. Conditions such as "these two companies may never, ever be allowed to merge".
Native programs are optimized for speed, Web Applications are optimized for Rapid Application Development
I think you're confusing Rapid Application Deployment with Rapid Application Development. There's nothing that's any more rapid about web app development than there is about traditional client development; in fact the tooling for traditional client app development is much better (as it's had a two decade head start).
I'm still a bit concerned about the supposed cross-platform-ness. Is the Javascript file Silverlight.js still used to initialize the Silverlight object in Silverlight 2? If that is the case it will never be truly cross-platform.
Silverlight initializes and runs just fine with just an <object> tag in the page with type="application/x-silverlight". There's no lockin here preventing a third-party implementation like Moonlight from registering the MIME type and handling it themselves.
Silverlight.js is just a helper script that adds some additional checks to verify that you have the required version of Silverlight and to display the install prompt HTML if you don't. In the end, it just generates that same <object> tag (with that same MIME type) and inserts it into the DOM.
Microsoft's plan isn't sustainable or elegant: they basically want the entire web-community to add another tag each time MS releases a new version of IE. (If they want a custom tag for the IE7->IE8 transition, they probably will want a new one for the next transition...)
The custom tag was designed with both future versioning and multiple browsers in mind. When IE 9 comes out, you don't need a new tag, you just need to change the "8" to a "9" in the existing tag to enable IE 9 to enable all the behaviorial updates that would have broken pages designed with IE 8 in mind.
The idea is that pages designed for IE 8 will continue to work unaltered in future versions of IE because they explicitly state they want IE 8's behavior. The entire web-community doesn't need to go back to all their old pages each time a new version of IE is released -- they only need to bump the version number in the meta tag up when they create or update a page and that page now needs access to the newer behavior.
There's also a version you can specify named "edge" which basically tells IE that it should always use the newest rendering behavior available. This is where the problem is.
The tag itself is not a bad thing. It makes sense to embed an implementation version into the data; especially in cases where content may be burned to disc and cannot be easily updated when technology moves forward to allow newer browsers to assume older layout to ensure it remains unchanged and unbroken in appearance. DOCTYPE itself does exactly the same function, but it does it at the published standard level. In a pragmatic world where no browser supports 100% of the published standards, having a separate version number for the implementation level is just good policy.
But going back to why IE took a good idea and made it a bad thing (and why they're sorta helpless about it): in the absence of the new meta tag, IE 8 behaves as if "IE=7" is specified. In order to opt into full standard support, you need to explicitly state "IE=edge". This is backwards to how it should be. "edge" should be the default unless a lower version is explicitly specified, because in the absence of the meta tag, the DOCTYPE has already said you expect the most fully standards-compliant rendering the browser can give you. The meta tag should be acting as a vehicle to further limit rendering, not as a requirement to fully open it up.
But Microsoft's in a difficult situation here. There are millions of pages already out there with a correct DOCTYPE, but no meta tag -- under the more correct way of using a meta tag, they'd default into the newest layout engine possible, which would cause the widespread breakage that is the reason why this meta tag was dreamed up in the first place. Microsoft is partially to blame for this because their older versions of IE had broken standards support; but blame also rests on the thousands of web designers who've relied on equally standards-breaking hacks to get the layout they wanted out of IE in the past.
Now, what would I do if I were Microsoft? This: Continue down the meta tag path, but change the default for pages served up in a standards-compliant way to "edge" instead of "7". Who cares if no other browser supports it that way -- it changes the whole meta tag idea into a value-add feature, instead of a compatibility hack. Yes, it will be painful dealing with the gnashing of teeth that will accompany the resulting page breakage, but we already dealt with that with IE 7. The worst is already over because IE 7's already out there breaking pages, and web designers are already on their toes that IE is a moving target again so the next rev won't be as bad because they've hopefully learned their lesson that you shouldn't work around browser limitations with ugly hacks because it'll bite you in the butt in the end.
Unfortunately, only the "Core CLR" will be ported, and only to the Mac OS (probably due in part to MS Office for Mac), not Linux, and not even older (PPC) Macs. I also seriously doubt there will be much in the way of developer tools for the(se) other platform(s).
A subset of the CLR similar to the Compact Framework is included in Silverlight; with a much simpler security model. It's not a replacement for the full.NET Framework by any stretch. There have been whispers about a Linux version of Silverlight as well (Flash has one, and Microsoft is trying to provide a superset of the Flash/Flex featureset).
As for developer tools, while it's not exactly developing on a Mac, per se, you can use Visual Studio to do remote debugging on CLR code running in a Silverlight app on a Mac client.
It's fairly straight forward to tune Javascript/DOM code to run in Mozilla, Opera, and Safari. But Internet Explorer? Meh. Let's just say that it adds another 30-50% to the project time.
Now Microsoft wants to broadcast their wonderful multimedia technology that will enhance the web, be cross-platform, show cool multimedia-type stuff that we can already do with SVG or Canvas.
Actually, the reason they're bundling the CLR is because the browser's own Javascript/DOM systems (which are also supported by Silverlight) are horrendously slow in comparison. At the MIX conference, they ran a demo where a Silverlight chess app had an identical AI player routine written in browser-run Javascript and CLR-run Javascript (I believe the exact same JS code was used for both), and the in-browser AI could only analyze a couple hundred moves in the same time the CLR version could analyze a million. That's four orders of magnitude faster.
That's why they're including the CLR as a code option. Because it's unbelievably faster.
Shouldn't Microsoft Logo certification do something about this? I mean, isn't there a clause saying "Thou shalt let users run thy program withoust being administratorths" or something?
Slashdot Mirror
Standing can be held either through harm incurred, or through the threat of imminent harm to be incurred.
It need not always be after the fact.
Are you a lawyer? I've been reading the promise Microsoft made, and it's all gibberish to me. And I doubt that even the original lawyer who drafted it would actually understand what he had written.
As far as legalese goes, Microsoft's Community Promise is actually pretty clear.
Basically, they grant you the right to use their patents to the extent of implementing the standards they've released under the promise. But in order to qualify, you have to implement the whole standard. (This is not a 'gotcha' clause so they can sue you if you have a bug, it's a clause to ensure that you can't take the patent grant and use it in a totally different context by saying you started from the standard specification and removed functionality until only the patented piece was left, then re-expanded it out to a totally different thing.)
Once you've implemented the whole standard, you can even continue and add additional functionality to your implementation, so long as the original standard remains implemented. (This is in key contrast to Java's grants, which only apply if you implement exactly what they specify and nothing more -- that "and nothing more" part is what got Microsoft in trouble when they extended the syntax of J++ to include anonymous closures.)
If you ever sue Microsoft over any patents involved in the specification you're implementing under the promise, the protection of the promise and its patent grants to you dissolve. It's "don't sue us, and we won't sue you", just scoped to a single standard -- in other words, you could sue Microsoft over other patents not related to the standard without losing your patent grant.
It's also irrevocable. They can't just decide one day to no longer honor the (legally binding) promise.
Compared to Java's grant, which even ends up involving things like field-of-use restrictions once you get the TCK license involved, it's incredibly permissive. Under the Community Promise, had Google used C# in the same way they used Java, they would be completely in line with the terms of the promise.
You know that UAC thing people who use Windows like to complain about?
I have to laugh when I see self-proclaimed 'experts' disable UAC, solely because they're smart enough to know where the option to turn it off is; but apparently not smart enough to realize no matter how smart, competent, and safe of a user you think you are, it's never a good idea to run as root, even if you think you're Electronic Jesus who never makes mistakes. (There's considerable overlap between this group of 'experts' and the group of 'experts' who refuse to install MSE because they're 'too good' to need it.)
Microsoft can only go so far to protect its 'expert' users from themselves. At some point, the user's own stupidity is at fault. And a user's stupidity doesn't go away just because they're using a different OS.
> This attitude from Microsoft isn't new, but I don't really see them being able to execute the "extinguish" part of their normal plan on GPL/BSD/MIT licensed software. Instead I can see them at grassroots level trying to make their platform relevant and make sure people can hook into it, but they get left on the sidelines.
Microsoft is turning into IBM. Once the dominant player, but technology moved on and they didn't move fast enough to follow it and stay on top. IBM was blindsided by the PC revolution, Microsoft was blindsided by the mobile revolution.
I think it's the ultimate fate of any tech behemoth. As an organization grows in size, it naturally gets slower and less capable of rapid adaption to change; and in an ironic twist of fate, it also means the organization has enough resources to invest into research and toy projects that they end up pioneering the very paradigm shift that results in their downfall when they turn out to be incapable of embracing it.
IBM commercialized the PC and it spun out of their control when other people took the idea and iterated it faster and made it better. Microsoft has been toying with mobile/embedded/tablet ideas for well over a decade and in doing so undoubtedly laid the conceptual groundwork for what would become the iPhone and iPad. And unless the pace of technology innovation slows along with the fading of Moore's Law, Google, Facebook, and Apple -- today's behemoths -- will all likely end up in the same situation.
It's worth noting that Microsoft Research had the exact same idea back in 2007 with Volta, which was an implemention of the .NET CLR in Javascript so you could take the same .NET compiled assembly files that you run on your PC and run them without any plugins in a Javascript-capable browser.
They eventually ditched the idea in favor of a different approach with Script#, which is a C# compiler that compiles to Javascript instead of .NET bytecode; similar in concept to Google' GWT Java source to Javascript compiler.
> You mean as opposed to when he had the DoJ stand down over DOMA and got DADT repealed or used a tremendous amount of political capital to get healthcare reform?
A nearly full term presidency and you can only name three things he's done well (only one of which was a legislative 'victory', and I put 'victory' in quotes because healthcare reform should have ended up a lot less compromised than it ended up being; whereas DOMA and DADT were both Executive imperatives that he hemmed and hawed about for years -- and you can damn well expect the next Republican in the White House will just perform a complete about-face on DOMA enforcement and defense). So... talk about damning with faint praise.
Obama's problem is that he's been so anxious to compromise with the right on *everything*, that he starts the conversation with a compromise plan, which just ends up getting pulled even further to the right when the inevitable cries of "no that's not enough!" come out from the Repubs in response to it.
He needs to grow a backbone.
Who the hell thought it was a good idea to have dynamic content in a document description language?
Notice you never hear about exploits-of-the-week like this for LaTeX !
That's a good question. Someone should be asking the people who put Javascript in Netscape the same thing! I mean, there's absolutely no use cases for having dynamic documents!
For the same reason your "web browser" can submit forms.
Take a look at the fundamental model. When you move a window in Windows, the app is notified and it has to respond. Try moving the window of an unresponsive app, it does not redraw because Windows is asking the app to redraw it.
Windows has had a retained-mode graphics system for the past 3 years as long as you don't disable desktop composition.
So really, even if MS adds the 2 standards to their Community Promise, that still doesn't mean you get anything useful - if you write a simple app that does nothing, you're fine. If you want DB access, or web serving, or a GUI.. you're still in the same problem as before.
Unless you're saying that you need Microsoft technology to provide useful software in the general sense, there's no reason to say that not being able to use ADO.NET makes C# any less useful of a language or Mono any less useful of a platform than the fact you can't use ADO.NET with C++ in GCC. Or with CPython. Or with Perl.
The CLI outlines a pretty thorough P/Invoke system which Mono supports, so you can use any DB library or GUI library you want with Mono. You're in no worse of a situation than you are with any other language.
me too.
GPL is certainly not the only free license. And what about people that go the "GPL\0for files in the \"GPL\" directory" way?
Well for the latter, obviously we'd fix the bug that allows poison null bytes to break a string, since that's a pretty serious security vulnerability in a web browser.
For the former, all of the following are valid in both HTML 4.01 Strict and XHTML 1.0:
<link rel="copyright" href="http://www.gnu.org/licenses/gpl.html" />
<link rel="copyright" href="http://www.opensource.org/licenses/mit-license.php" />
<link rel="copyright" href="http://www.microsoft.com/opensource/licenses.mspx#Ms-PL" />
And all of the following work in any included ECMAScript file:
You certainly have the freedom to alter your user agent to require any set of licenses you're comfortable with.
Stallman is perfectly happy avoid using your service and resources. His issue is that he doesn't have an easy way to tell whether or not he *should* avoid you.
Sure he does. If Stallman wants to know whether a site's Javascript is under the GPL, he can just look for the text of the GPL included as a comment on the webpage or in the included JS file; since you're supposed to distribute a copy of the GPL along with any GPL'd code, right? I mean the requirement that the license is distributed along with the program is right there in section 1 of GPLv2.
It'd be fairly trivial for someone to put together a browser extension that refuses to execute any code that doesn't come with a copy of the GPL attached.
If the fact that nearly every HTTP response would end up at least 17k larger if the idea were to take off is too large to swallow; then just include a link to the GPL in one of a page's tags. It'd be just as easy for a user agent to check that as well.
It's only feature creep if it's unnecessary. Youtube proves the contrary.
Actually, Youtube proves it is unnecessary bloat by showing that there's already a widely accepted and usable solution for putting video on a webpage.
Sounds like feature creep and bloat to me.
Don't worry, the pages that implement it will never get loaded into RAM because nobody will ever use it.
Distribution compatibility and package management is a big problem for most, if not all developers, and has been for a very long time.
And it will be, for quite some time to come. Linux doesn't have a stable ABI, so it's very hard to deploy to. I'm pretty sure even the LSB's goals don't reach far enough to solve this fundamental problem.
If the companies can't survive without each other, what's the harm in letting them merge?
The companies might have a valid case about 'not being able to survive without each other' if they didn't make almost suicidally bad business decisions like paying Howard Stern 300 million dollars only to find out he can't bring in enough subscribers to even break even on his paycheck.
And if they were to have failed individually, I'm sure there are plenty of buyers who'd love to have gotten their assets and put together a profitable satellite radio company with their current subscriber numbers.
Instead they got what amounts to a bailout -- except instead of dollars, the currency of their bailout is fair competition to the benefit of consumers in a market that's now effectively being made into a government approved, privately maintained monopoly
Of course, the merger comes with strict conditions to keep things in the public interest.
Conditions like the conditions XM and Sirius were originally given when they were granted space on the spectrum. Conditions such as "these two companies may never, ever be allowed to merge".
A trillion URLs, and still no sign of clownpenis.fart in the index anywhere!
At this rate it really will be the last one to go.
Native programs are optimized for speed, Web Applications are optimized for Rapid Application Development
I think you're confusing Rapid Application Deployment with Rapid Application Development. There's nothing that's any more rapid about web app development than there is about traditional client development; in fact the tooling for traditional client app development is much better (as it's had a two decade head start).
I'm still a bit concerned about the supposed cross-platform-ness. Is the Javascript file Silverlight.js still used to initialize the Silverlight object in Silverlight 2? If that is the case it will never be truly cross-platform.
Silverlight initializes and runs just fine with just an <object> tag in the page with type="application/x-silverlight". There's no lockin here preventing a third-party implementation like Moonlight from registering the MIME type and handling it themselves.
Silverlight.js is just a helper script that adds some additional checks to verify that you have the required version of Silverlight and to display the install prompt HTML if you don't. In the end, it just generates that same <object> tag (with that same MIME type) and inserts it into the DOM.
Microsoft's plan isn't sustainable or elegant: they basically want the entire web-community to add another tag each time MS releases a new version of IE. (If they want a custom tag for the IE7->IE8 transition, they probably will want a new one for the next transition...)
The custom tag was designed with both future versioning and multiple browsers in mind. When IE 9 comes out, you don't need a new tag, you just need to change the "8" to a "9" in the existing tag to enable IE 9 to enable all the behaviorial updates that would have broken pages designed with IE 8 in mind.
The idea is that pages designed for IE 8 will continue to work unaltered in future versions of IE because they explicitly state they want IE 8's behavior. The entire web-community doesn't need to go back to all their old pages each time a new version of IE is released -- they only need to bump the version number in the meta tag up when they create or update a page and that page now needs access to the newer behavior.
There's also a version you can specify named "edge" which basically tells IE that it should always use the newest rendering behavior available. This is where the problem is.
The tag itself is not a bad thing. It makes sense to embed an implementation version into the data; especially in cases where content may be burned to disc and cannot be easily updated when technology moves forward to allow newer browsers to assume older layout to ensure it remains unchanged and unbroken in appearance. DOCTYPE itself does exactly the same function, but it does it at the published standard level. In a pragmatic world where no browser supports 100% of the published standards, having a separate version number for the implementation level is just good policy.
But going back to why IE took a good idea and made it a bad thing (and why they're sorta helpless about it): in the absence of the new meta tag, IE 8 behaves as if "IE=7" is specified. In order to opt into full standard support, you need to explicitly state "IE=edge". This is backwards to how it should be. "edge" should be the default unless a lower version is explicitly specified, because in the absence of the meta tag, the DOCTYPE has already said you expect the most fully standards-compliant rendering the browser can give you. The meta tag should be acting as a vehicle to further limit rendering, not as a requirement to fully open it up.
But Microsoft's in a difficult situation here. There are millions of pages already out there with a correct DOCTYPE, but no meta tag -- under the more correct way of using a meta tag, they'd default into the newest layout engine possible, which would cause the widespread breakage that is the reason why this meta tag was dreamed up in the first place. Microsoft is partially to blame for this because their older versions of IE had broken standards support; but blame also rests on the thousands of web designers who've relied on equally standards-breaking hacks to get the layout they wanted out of IE in the past.
Now, what would I do if I were Microsoft? This: Continue down the meta tag path, but change the default for pages served up in a standards-compliant way to "edge" instead of "7". Who cares if no other browser supports it that way -- it changes the whole meta tag idea into a value-add feature, instead of a compatibility hack. Yes, it will be painful dealing with the gnashing of teeth that will accompany the resulting page breakage, but we already dealt with that with IE 7. The worst is already over because IE 7's already out there breaking pages, and web designers are already on their toes that IE is a moving target again so the next rev won't be as bad because they've hopefully learned their lesson that you shouldn't work around browser limitations with ugly hacks because it'll bite you in the butt in the end.
Unfortunately, only the "Core CLR" will be ported, and only to the Mac OS (probably due in part to MS Office for Mac), not Linux, and not even older (PPC) Macs. I also seriously doubt there will be much in the way of developer tools for the(se) other platform(s).
.NET Framework by any stretch. There have been whispers about a Linux version of Silverlight as well (Flash has one, and Microsoft is trying to provide a superset of the Flash/Flex featureset).
A subset of the CLR similar to the Compact Framework is included in Silverlight; with a much simpler security model. It's not a replacement for the full
As for developer tools, while it's not exactly developing on a Mac, per se, you can use Visual Studio to do remote debugging on CLR code running in a Silverlight app on a Mac client.
It's fairly straight forward to tune Javascript/DOM code to run in Mozilla, Opera, and Safari. But Internet Explorer? Meh. Let's just say that it adds another 30-50% to the project time.
Now Microsoft wants to broadcast their wonderful multimedia technology that will enhance the web, be cross-platform, show cool multimedia-type stuff that we can already do with SVG or Canvas.
Actually, the reason they're bundling the CLR is because the browser's own Javascript/DOM systems (which are also supported by Silverlight) are horrendously slow in comparison. At the MIX conference, they ran a demo where a Silverlight chess app had an identical AI player routine written in browser-run Javascript and CLR-run Javascript (I believe the exact same JS code was used for both), and the in-browser AI could only analyze a couple hundred moves in the same time the CLR version could analyze a million. That's four orders of magnitude faster.
That's why they're including the CLR as a code option. Because it's unbelievably faster.
Shouldn't Microsoft Logo certification do something about this? I mean, isn't there a clause saying "Thou shalt let users run thy program withoust being administratorths" or something?
It does. But who gets Logo certification anymore?