Wednesday, June 18, 2008

Live Mesh doesn't require UAC!

Live Mesh Logo

Today my three machines (2 Vista and 1 XP) which use Live Mesh asked to be updated. No information to what the updates include ... just that they wanted to plug back into the mother ship. I thought, "Could this be, the infamous Live Mesh update that removes the need for UAC"? After updating my Vista machines, I disabled UAC, rebooted, and ... Live Mesh still worked fine! Woohoo!

This should now convince more people to install and use Live Mesh.

PS: I searched the tubes for any announcement of this awesome update, and found nothing. Nothing. This guy had the same experience. However, today (a day after the update) at 11:30a a blog entry appeared on the Live Mesh blog announcing the service update.

Now, I suffer from the same delay-between-release-and-blogging syndrome that most project owners suffer from, but all projects are expected to have some explanation of what the release contains ... like release notes, etc. Live Mesh uses there blog as the release notes, so they have more of a need to be on-top of their blog.

Friday, June 13, 2008

The DLR will continue to be licensed under Ms-Pl

Yesterday The Register posted an article titled "Microsoft: keep your sticky mitts off our language runtime." It's a scary-sounding title, but simply says that the DLR will not accept contributions. Plus, it's got some interesting quotes from me (=P). Anyway, I'd like to use this post to clarify and emphasize certain points. First off, let me say this: The Dynamic Language Runtime (DLR) will continue to be licensed under the Microsoft Public License (Ms-Pl). Today the DLR is packaged in IronPython 2.0, IronRuby, and the Silverlight Dynamic Languages SDK, which are all licensed under Ms-Pl. When the DLR becomes 1.0 later in the year it will have it's own Codeplex project and will still retain the Ms-Pl license. And we don't plan on that changing in the future. Now for some clarifications:
"It's official: Microsoft will not accept any external code contributions to its planned Dynamic Language Runtime (DLR), which will run Microsoft's new scripting languages for the web and Silverlight content on .NET"
Today, IronRuby accepts contributions to the libraries, and will open up entirely after the DLR becomes 1.0. IronPython does not accept contributions, though in the future it will have the same fate as IronRuby. Now that the line between the languages and the DLR is a bit clearer, we've decided to let people know now that there are definitely no plans to accept contributions. Why no contributions?

"Closing off the DLR will potentially prevent unwanted and unaccounted IP from creeping into the code. [snip] The company could have left itself, and customers, open to IP claims from disgruntled code authors. [snip] Also, Microsoft does not want code that's distributed under copyleft licenses, such as GPL, creeping in. [snip] A copyleft license would compel Microsoft to ship the product source code and contribute changes back to the community. This is not a typical business model for Microsoft."

Microsoft cares more about IP getting in that IP getting out. Projects Microsoft wants to monetize, like Visual Studio, need to be more closed off to protect the IP. However, other projects that don't have any monetization plans, like IronRuby, Ajax Control Toolkit, etc, can be more lenient and eventually can become open-source. Why? Because the openness does benefit those projects:

"Microsoft will, though, continue to accept source-code contributions to its slowly emerging implementation of Ruby for .NET, IronRuby. Contributions are helping to build IronRuby and shepherd the language towards the first-full release."

So, this leads to the conclusion that the DLR is closing down because we want to monetize it? Not quite, but ...
"Microsoft is keeping the DLR closed because it will go into the next version of the .NET Framework, expected around the same time as Visual Studio 10. Microsoft had committed to release DLR 1.0 by the end of 2008."
Again, The DLR will 1.0 EOY 2008 and will stay Ms-Pl. The DLR is a bunch of services and tools for implementing languages with dynamic features on .NET. However, only the language/compiler services of the DLR will move into the .NET Framework in Visual Studio 10. The rest will still be distributed by languages/frameworks that want to use them. We're openly making this distinction today though; everywhere the DLR ships you will find two Microsoft.Scripting namespaces; Microsoft.Scripting and Microsoft.Scripting.Core. Microsoft.Scripting.Core is what we're staging for moving into the framework. I say staging because what's in that namespace isn't final, so it could change. The comments are also fun, but when are The Register comments not? =) I hope that cleared up any confusion; please let me know if you have any other questions.

Monday, June 09, 2008

Dynamic Languages in Silverlight 2 Beta 2

With the announcement of Silverlight 2 Beta 2, the Silverlight Dynamic Languages SDK has been updated as well! Download the Dynamic Languages SDK! What's new? There's a lot of new stuff here, from new versions of IronRuby, IronPython, Managed JScript, and the Dynamic Languages Runtime, to more samples and better packaging. Latest Bits This release packages up the latest bits for the three languages, as well as the DLR and Silverlight integration. The most noticeable difference is the extra DLL that is provided: Microsoft.Scripting.Core.dll. This contains the core functionality of the DLR, while Microsoft.Scripting.dll contains non-necessary pieces like helpers and Hosting API. More Samples Also, there is a whole slew of new samples! IronPython and Managed JScript have their fare-share of samples; IronRuby is lacking a bit but new ones are being added in during this week, so sit tight! Separate packages One difference from the last release is now there are three packages: SDK, SDK Source Code, and SDK Samples.
  • SDK: Necessary package to create dynamic language Silverlight applications.
  • SDK Source Code: If you want to modify the languages/DLR/Silverlight integration, you can do so here, and build using the given Solution file in Visual Studio. This will create a /bin directory with the identical binaries as the /bin directory in the SDK, however without DLL signing.
  • SDK Samples: a bunch of Ruby, Python, and JScript samples. Best bet is to unzip this in the SDK directory.
Future This release is important, as it marks the last time this package will be the main ship vehicle for dynamic languages in Silverlight. Every binary release of IronPython/IronRuby will distribute Silverlight binaries necessary to build applications with the language, and the distributed source code will build against Silverlight. They will always work with the latest released version of Silverlight. This package will always be available as the languages that share the same version of the DLR, until the DLR stabalizes. Then, who knows ... =) Alright, go make some awesome stuff!