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
It just took a LOT of wasted time for him to believe it.
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.
And another legacy monster is born. Microsoft has a peculiar expertise for loading itself down with this kind of cruft.
The world's burning. Moped Jesus spotted on I50. Details at 11.
My lead developer wanted to adopt Silverlight a couple years back for a key application we were developing. I am sure he had strong technical reasons, but getting tied to a highly proprietary Microsoft technology just smelled bad. .NET is one thing, Silverlight scared the hell out of me. I pulled out one of my rarely used veto cards and I'm glad I did.
See my journal for slashdot ID's by year. Mine created in 2005. http://slashdot.org/journal/289875/slashdot-ids-by-year
"The Mono project is about the only group of people actively talking up .NET" -- You made this up, right? tiobe.com shows C++ at 9.8% and C# at 6.8%.
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.
Personally, I think that the hate that is felt towards DRM should be redirected towards proprietary DRM so we can break down platform lock-in and give the obscure platforms a chance with the average consumer.
Can't be done. Any open DRM platform will be trivially circumvented. In cryptographic terms, DRM is an attempt to send a message from Alice to Bob without it being read by Charlie. The problem is that in DRM, Bob and Charlie are the same person. The way DRM companies get around this is by hiding the private key in the software. If their DRM systems were open, then they would be unable to hide anything anywhere.
Give me Classic Slashdot or give me death!
.NET never was that huge for desktop apps for most users, but it is HUGE in the enterprise world. HTML5 is the path for Metro tile apps, but Microsoft isn't abandoning all their enterprise customers with internal apps. .NET isn't going away. Mono in theory could allow these customers to shift to Linux, but I'm not sure anyone has really tried that.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
Any form of DRM has to be proprietary, the entire premise is based on security through obscurity... If the platform is not obscure, then it becomes even more trivial to circumvent.
It is DRM that should be abandoned, it serves only to screw legitimate customers through lack of player choice and bugs etc... It does absolutely nothing to stop piracy, if anything it encourages it because it enables the pirates to offer a superior product...
DRM is inherently broken because you have to give users everything they need in order to play the stream, you just need to reverse engineer it and work out how to extract the data or keys. For any DRM scheme which has content worth pirating, this always happens, and it only takes one person to work it out and distribute his tools to the warez scene.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
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...
Personally, I think that the hate that is felt towards DRM should be redirected towards proprietary DRM so we can break down platform lock-in and give the obscure platforms a chance with the average consumer.
Trouble is, there is nothing but 'Proprietary DRM'. If DRM is 'open' it becomes quite trivial to produce a tool that is conformant in all respects, except that it silently ignores the various customer-hostile features(like those little HDMI converter boxes, that aren't supposed to exist, that report themselves as an HDCP compliant sink on one side; but spit out an unencrypted video stream on the other).
Thus, we see either single-party proprietary DRM(eg. 'Fairplay' where only one company holds the keys) or multi-party proprietary DRM(eg. WMDRM, where you can license the DRM system; but only by agreeing to cripple your product in specific ways). There might be a hypothetical 'open' DRM, developed under some sort of OSS model; but for it to remotely work in practice, it would just be rolled out on tivoized platforms only. And what good is 'open' in that case?
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.
HTML5 is the path for Metro tile apps
HTML5/JS is a path for Metro apps. You can also write them in .NET and C++. In fact, writing them in C# is the easiest of three, because Metro APIs are heavily asynchronous (continuation-passing style), and C# 5 has convenient syntactic sugar for CPS; whereas in both C++ and JS you have to write out callbacks explicitly as lambdas.
Most mobile games you play are using mono http://www.unity3d.com/ .
Games can be written 99% in OpenGL ES, and just the user controls will vary from platform to platform.
The part that needs to be rewritten are GUI panels, widgets, layout, etc. Since all these platforms have significantly different interaction models (not just appearance) then any attempt to use the same interface will result in very poor user experience. Furthermore, if you really do have an application that is just GUI forms, then it must not be a very complex, and shouldn't take long to redo.