Slashdot Mirror
Mono Abandons Open Source Silverlight
mikejuk writes "The Mono project is about the only group of people actively talking up .NET and developing it, but in an interview Miguel de Icaza has admitted that Moonlight, the Mono version of Silverlight, isn't worth the effort any more. He said, 'Silverlight has not gained much adoption on the web, so it did not become the must-have technology that I thought [it] would have to become. And Microsoft added artificial restrictions to Silverlight that made it useless for desktop programming. These days we no longer believe that Silverlight is a suitable platform for write-once-run-anywhere technology, there are just too many limitations for it to be useful.'"
Now, if only Netflix would abandon it so that I don't have to boot into windows to watch movies...if it can be done for android, why not PC?
Bits of code, random ramblings: jakimfett.com
1) Create new technology
2) Market the hell out of it
3) Everyone gets hyped up, next big thing etc
4) Microsoft drops technology
5) repeat step 1
This has been their standard order of business for decades. Watch for the same thing to happen to "Metro" Microsoft's latest big thing..
Silverlight really is a well thought out technology. It does a great job of abstracting the presentation layer from the code, and is pleasant to program. The tools for developing in Silverlight are nice, too. Too bad that it is showing signs of fading away - I think it had a lot of potential.
My comments are my own, and do not represent the views of my employer, my spouse, my children, or my cats.
Am I a bad person to experience a Schadenfreude rush everytime Miguel, Facebook, Zynga or Groupon fails?
@de_machina
I'm no fan of .NET, but I'm pretty sure the Mono developers aren't the only ones using it.
He is saying there is no future for Silverlight (the .NET based web plugin), not all of .NET. And that they won't put resouces into developing Moonlight (the open source version of Silverlight).
I know of two sites that use Silverlight, netflix and xfinity. They both use it just for the Microsoft DRM, afaik.
It isn't terribly surprising that Mono is abandoning Silverlight, since Microsoft seems to be doing much the same in favor of HTML 5.
The .NET Framework and tools in totality are a different story, though.
By the way, for those who haven't looked at it recently, MonoDevelop has come a -long- way. It's feature-comparable to Visual Studio, nowadays.
~ Whence do you come, slayer of men, or where are you going, conqueror of space?
This is just another sign of the industry converging to HTML5 as the primary display API. Flash is going away, now Silverlight is, too. Hopefully the companies will increase their efforts to allow users / developers to migrate existing applications to the new API.
"we no longer believe that Silverlight is a suitable platform for write-once-run-anywhere technology, there are just too many limitations for it to be useful."
If only someone could have warned you, oh wait someone did, _everyone_ in the world who has paid any attention to Microsoft's behavior over the last 20 years.
Miguel has supported:
the Microsoft "partnership" with Novell (disaster for Novell in the community)
OOXML/docx (deliberately obfuscated format mess)
C# (has a constant vague patent cloud over it that he dismisses)
Moonlight/Silverlight (a patent-encumbered flash clone, in an era when flash is going away, now shown to be a bad idea)
I used to wonder if Miguel was a Microsoft plant, now I wonder if he just has a learning disability.
Silverlight (and XNA, and Windows Phone 7, etc) basically refer to overlapping collections of .NET libraries (often referred to as profiles) which different environments support. The set of libraries that Xamarin provides for Android development is a superset of the libraries available in Silverlight 4. However the intent isn't for you to write Silverlight applications that happen to run on Android. The idea is to write all your common code using the .NET Base Class Libraries (BCL; which are included in the ECMA standard), and then write your interface using (wrappers) around the native libraries for Android (or iOS or WP7 or Silverlight or WPF or ASP), for each platform you release on.
The funniest part about that Talk page is that "JimTheFrog" is, according to his user page:
So basically, that entire talk page is about the lead of that DRM-centric disaster defending what is fundamentally a customer-hostile technology. I'd call him a shill but he's probably tasked with "maintaining the message" on places like Wikipedia to make UltraViolet seem less fundamentally shitty than it is. And his dickish attitude towards Linux seems unsurprising, given that he
That's why the Nook Tablet came with a locked bootloader, whereas the original Nook Color spawned a large ROM'mer community. Netflix required it in order to let them use their app. I think I'd rather deal with DRM for paid downloads than have my whole device locked down.
Posted from my Android phone. Oh, I can change this? There, that's better...
When it comes to DRM peddlers, it isn't clear that that will be the choice.
. Take a look at this 'Encrypted Media Extensions' proposal. Most of it just lays out a bunch of proposed javascript for requesting keys and passing them to a decryption module whose implementation is left vague(aside from the one, seemingly completely pointless, 'simple' case where a static, known, key is used for no obvious reason).
Now, have a look at the goodies: In the diagram at the beginning "CDM may use or defer to platform capabilities". And look also at section 8.5:
"Can I ensure the content key is protected without working with a content protection provider?"
"No. Protecting the content key would require that the browser's media stack have some secret that cannot easily be obtained. This is the type of thing DRM solutions provide. Establishing a standard mechanism to support this is beyond the scope of HTML5 standards and should be deferred to specific user agent solutions. In addition, it is not something that fully open source browsers could natively support."
"Can a user agent protect the rendering path or protect the uncompressed content after decoding?"
"Yes, a user agent could use platform-specific capabilities to protect the rendering path."
So, unless you want to use the (seemingly entirely pointless) 'clear-key' case, this 'open' proposal boils down to a mixture of hot air and admissions that the good stuff would necessarily be implemented in closed (probably 'platform', which increasingly means 'cryptographically locked firmware') sections.
Can an OSS browser protect the key from the user? No. The specification explicitly says as much. And if the key is known and the cyphertext has been downloaded, the game is over. Period. So, right there, only closed (either binary-only or OSS-tivoized) implementations of key handling need apply. Can an OSS media rendering path protect the content from the user? No. The specification says as much. Only if media rendering is handed off to a binary or hardware/firmware component can that be provided.
Essentially, this proposal achieves the magnificent breakthrough of allowing a DRM streaming stack to use the browser's HTTP transfer mechanisms instead of those in the flash plugin. Key handling and media path? Those are either completely in the clear, or necessarily handed off to user-opaque sections.
Further, if you want to 'protect the media path' and ensure key security(even in a binary module) that implies such radical capabilities as protected memory regions that cannot be read by even the highest-privilege user-controlled processes(so, either a locked kernel, or an 'open' kernel under a locked hypervisor, PS3 linux style) as well as locked audio and video output paths, potentially locked cache areas on mass storage devices, and so forth.
Given this, it really comes down one of two ways: The first option is Tivoization: Yeah, it's 'open'; as in 'you could build the code and run it on some other hardware without a locked bootloader'. The second is some sort of TPM-style 'secure remote attestation' setup: It's 'open' as in "yes, you can modify it if you want; but remote hosts will refuse to deal with you if your attestation signatures come back nonstandard"(see also: Google/android DRM and what happens if you root your device...)
For good or ill, you can't make a piece of hardware serve two masters. If you want DRM to work, the platform must ultimately be controlled by the vendor, possibly with little sandbox areas for the user to amuse himself. If you want the user to control the platform, DRM cannot be more than a (perhaps frustrating, perhaps trivial) exercise in obfuscation and cat-and-mouse trickery.