As far as I've been able to tell, this is correct (though most articles reporting on EME totally fail to mention it).
EME is just a standard API for DRM platform-specific proprietary binary-blobs to work to. The real work (decrypting encrypted video streams) still happens in binary blobs. Which is to say, ultimately EME changes nothing, it will just create a situation where, rather than Netflix and co using Silverlight, they will instead each roll their own browser plug-in.
All that said, it's bullshit that EME might become a web standard. Berners-Lee's position is goddam ridiculous.
I suspect they won't be allowed to due to the lack of platform level DRM.
You mean Linux doesn't have a do not allow screen-capture 'feature'? Currently, Silverlight can be run through Wine (one suspects they could have deliberately broken this if they wanted to), and captured from there, so I'm not sure how much they care about that.
Your username is MobSwatter, but here you are suggesting sending an untrained mob into Afghanistan.
But realistically though, when we went into Afghanistan and did not have bin laden in our possession after two weeks I'd have decided to turn the place into a self illuminated glass parking lot.
You mean the whole country?
Killing thousands of innocents: totally fine, so long as we're the ones doing it, right? Remind you of anyone?
I would have telegraphed though, by quietly removing every US asset from the region without explanation, they would have figured that one out real quick and would have produced that prick on the spot.
Yeah, the locals must have known where he was. It's not like he was in hiding in a walled-off compound and never leaving.
You are either a troll, or a dangerously misguided racist moron.
Hmm. If there was a way to use slave-like treatment and 'pushing them harder' to take a two-man team and get the output of a full-size development studio, I suspect someone would've figure it out by now, but, well, there's not.
What about the home-based family business part? You don't think focussing on just one platform would make sense, given severely constrained developer resources?
The problem is that mistakes were made and the developers did not learn from those mistakes, did not seem to care about fixing those mistakes, and did not care about preventing similar mistakes from recurring.
To play Devil's advocate (or rather, advocate of the developers): if they were a properly resources software-development team, they might have been better able to pay off the technical-debt accumulating in the codebase. Hopefully this injection of resources will change things for the better. (The LibreSSL crew seem to be making good progress on the technical debt front, also.)
It's ok, there's still time to be cynical: perhaps they've just woken up to the fact that Cisco are hurting bad after they lost everyone's trust, and don't want to face the same downturn.
Don't ask me how they think they'll ever get a jet off the ground using solar, but I don't think they've even thought that far into it.
A straw-man so awful, it defeats itself.
You're right that for aircraft, there's no real contender to using oil-based fuels. Somehow you've taken this to mean we should continue to burn oil even where we don't need to.
Really? That's almost two miles of wire. No-one notices that stuff going missing? Can't the tech be fired for this indefensible waste of resources, not to mention deliberately worsening a customer's service out of petty personal spite?
Maybe I think too much of 'the system'...
Plus, if the tech didn't like that customer, surely they'd want to avoid going back on account of connection issues...
I'm pretty sure the endgame for the major content providers is to close that loophole.
Loophole? Bullshit. That's no less ridiculous than saying the endgame of Flash is to become a binay-blob in Firefox.
Firefox has long supported Flash, Silverlight, and Java, despite that they're proprietary (yes, except you, OpenJDK). No-one was crying then. All they've done now is implement a new way of having the DRM content tie itself into the browser.
I think it's absurd that there's such a thing in the HTML spec, but it is there, and Mozilla had a difficult choice:
- Support Encrypted Media Extensions and risk being viewed as soft by the Free Software hardcore
- Take a stand against DRM by not supporting it, and watch as real users leave Firefox for Chrome (and it's not much of a stand - they've supported Silverlight forever, and no-one's whining about that)
Mozilla stood to lose a lot more in not supporting 'EME' than in supporting it.
So that's OK. Somebody else will do it and Mozilla will be the next Opera.
'do it'? Do what? Create a browser which deliberately doesn't support EME? You do realise this is like saying Mozilla should build a browser which doesn't support Flash, right? This bears repeating, as you really seem to have missed the point: Firefox will not include DRM binary-blobs, it will merely support this new component interface by which Firefox will interface with the DRM blob, in much the same way Firefox interacts with the Flash binary-blob.
If you dislike DRM and/or the binary-blobs, it's really quite simple: Don't install Flash, Silverlight, or any other proprietary plugins. These new developments change nothing here. You gain nothing by engineering your browser to not support the plugins.
Also, regarding Mozilla will be the next Opera: you have a very distorted view of what matters to most Firefox users. Your average non-techie is not aware of the issues addressed by the Free Software movement. They want a browser which Just Works, ugly DRM and all.
The average user does not think Mozilla are supporting DRM? The traitors! No. They would, however, think Netflix doesn't work in Firefox anymore, so I'll go back to IE.
Mozilla is big enough that they could have fought this.
They're big enough that major DRM'ed content providers might have worked to special-case Firefox were it not to support 'EME', sure, but this isn't to say they're betraying their users by supporting EME.
The only real downside I can see is that if it makes it much easier to install a DRM blob, it's likely to result in many more DRM schemes, as opposed to the current situation of really just 3 major 'plugins': Java/Flash/Silverlight.
Are you SO bored or jealous of other people's achievements that you have nothing better to do than to sit around and nitpick the friggin' ad copy of a marketing page that was undoubtedly written not just for people who want to know the technical specifications of the product, but common usage applications for it also?
I'm a techie. Like many, I find vacuous marketing to be grating. That's really all I was trying to get across. It's a very minor detail, and a very minor dig. I'm not attacking your product.
(I can play at quasi-psychoanalysis though, if that's the game: are you so insecure about your product you have to rant at snarky Slashdotters, and imagine further insult which isn't there?)
What you're calling a "buzzword" is information that business wonks need to know when faced with the question, "Will this solve my problem/fulfill my needs?"
Other than a mention of JSON support, nowhere on the page are there any web-specific points being made. The section labelled 'Web 2.0' then goes on to discuss scalability. I get that scalability is what's being hinted at, but really this situation should be reversed.
I wasn't commenting about Postgres-XL, or PostGres. Indeed, I warm to Postgres - a rare example of a 'proper, grown-up DBMS' that prioritises correctness - and I like the general look of Postgres-XL.
It was a pretty awful film, with a pretty awful message. I remember an early scene where Jackson's character batters a fellow torturer for... enjoying it too much, or something.
As you say, Jackson's character kills the bad guy's wife... without giving him any forewarning. Doesn't that defeat the point? Tell me what I need to know or I'll kill your wife at least gives you leverage, but there's not much to be gained just outright killing her.
The film did at least cover that without an immediate way to verify claims, torture can yield false information. As you say though, the film really pushes the idea that the solution would have been more and better torture, because in letting up, they gave the bad guy time to regain his energy for resisting torture.... Pretty sure that no-one has ever lasted more than 3 minutes of waterboarding without 'breaking'.
I get the impression that entertainment like 24 has had a pretty dire effect on people's opinions on this stuff... (Unthinkable at least had the decency to be a genuinely awful film.)
The problem lies not in the lack of "native" C calls (you mean in-line C call sequences in jitted code, I presume)
Yes, just so. Getting high-speed calls to C was a big break for HotSpot, as JNI had long been a real performance problem. People would have to optimise their Java/JNI/C programs to minimise the number of calls between the two languages. (Calling Java from C is still somewhat slower, by nature - HotSpot isn't in the business of producing C functions.)
V8 can't inline and inter-procedurally optimize the DOM manipulation methods - because they're opaque blobs of compiled C++ code and not some intermediate form of it.
Deep inlining is nice, of course, but I can't imagine it being a total game-changer for something like this. In a typical C++ program, there's an 'inlining barrier' when you link against a binary library. I could be wrong though, and I don't have any numbers to hand, but if we look at today's C-family compilers, whole-program optimisation is a really great feature, but it's not revolutionary.
I don't see why the same approach should be inapplicable to Canvas and WebGL. Isn't there a lot of Canvas calls that simply change the drawing state for later operations?
In a happier alternative universe, Java wasn't a goddam disaster when it came to applets and desktop GUI.
Even ignoring the horrendous bloat and browser-crashing tendencies of the Java of old, the security model has always been - and will continue to be - a bad joke. The way they conflate a platform in which secure software can be effectively developed and a platform which effectively resists malicious input programs boggles the mind. Java has a really very good track-record in the former, but its horrific track-record in the latter rather mars it...
Sun's reasoning, as far as I can tell, went something like this:
Screen goes wobbly, camera pans to Sun Microsystems strategy meeting
You know how we could make fast, secure software? Efficiently-implemented high-level languages! We know that C-family languages are an awful choice for developing secure programs... Ok then, let's implement a high-performance virtual-machine for our 'Java' virtual platform. We'll write it in C++, because high-level languages are slow. I'm sure the security will be fine, after all, we're calling it a sandbox, and if we call it that, it's sure to be immune from attack by way of malicious bytecode. Most C++ programs are vulnerable to buffer-overflows, but ours is a sandbox, so it's sure to be just fine.
A few years pass
This is going great. Java has been a great success in 'enterprise' web servers, so we'll push most of our resources at that. We'll keep promoting Java applets though, and we'll ignore the unending stream of security flaws in our 'sandbox', because developing a decent server-side JVM is more important. We could put our money where our mouth is and develop a secure JVM, in, say, Java, but no, we'll keep pushing this bug-filled C++ monstrosity, and keep pretending the 'sandbox' is trustworthy. The bloat can stay too, the server crowd don't seem to mind.
What's that? Someone went and built a secure JVM, in Java? Jikes RVM, you say? With a full JIT compiler and all? Nah, we'll carry on pushing our server product as a secure in-browser sandbox. Applets are sure to catch on any day now, security laughing-stock or not.
Correct. In short, then: asm.js is working as intended.
I don't think the memory-allocations would be a major concern though. The fact that JavaScript is an all-round nightmare of a dynamic language is the hard-to-get-fast part, as it's very difficult for the compiler to reason about safe optimisations.
(See Lua for a non-nightmare dynamic language: it has a pretty damn fast JIT (LuaJIT), which was developed by just one man. Compare with: V8, which took a whole team of Google's engineers working for quite a while.)
Slashdot Mirror
As far as I've been able to tell, this is correct (though most articles reporting on EME totally fail to mention it).
EME is just a standard API for DRM platform-specific proprietary binary-blobs to work to. The real work (decrypting encrypted video streams) still happens in binary blobs. Which is to say, ultimately EME changes nothing, it will just create a situation where, rather than Netflix and co using Silverlight, they will instead each roll their own browser plug-in.
All that said, it's bullshit that EME might become a web standard. Berners-Lee's position is goddam ridiculous.
I suspect they won't be allowed to due to the lack of platform level DRM.
You mean Linux doesn't have a do not allow screen-capture 'feature'? Currently, Silverlight can be run through Wine (one suspects they could have deliberately broken this if they wanted to), and captured from there, so I'm not sure how much they care about that.
As if Yoda wasn't cryptic enough already.
Maybe a superlinear increase in the cost to file suits based on the number of suits you've filed?
Generally the law is meant to treat everyone as equal, though... (Unless, you know, you're rich, or something, but it's a nice ideal to aim for.)
Congratulations, you just went full retard.
Your username is MobSwatter, but here you are suggesting sending an untrained mob into Afghanistan.
But realistically though, when we went into Afghanistan and did not have bin laden in our possession after two weeks I'd have decided to turn the place into a self illuminated glass parking lot.
You mean the whole country?
Killing thousands of innocents: totally fine, so long as we're the ones doing it, right? Remind you of anyone?
I would have telegraphed though, by quietly removing every US asset from the region without explanation, they would have figured that one out real quick and would have produced that prick on the spot.
Yeah, the locals must have known where he was. It's not like he was in hiding in a walled-off compound and never leaving.
You are either a troll, or a dangerously misguided racist moron.
You're right, that's a rather, err, pessimistic, estimate.
My point stands, though.
Nope.
Are you not familiar with the idea of technical debt?
That I can recall, I've only ever seen it used by technical people, never by managers or marketers.
Hmm. If there was a way to use slave-like treatment and 'pushing them harder' to take a two-man team and get the output of a full-size development studio, I suspect someone would've figure it out by now, but, well, there's not.
What about the home-based family business part? You don't think focussing on just one platform would make sense, given severely constrained developer resources?
Meanwhile, in Git's crypto code.
(Linked from this blog entry.)
The problem is that mistakes were made and the developers did not learn from those mistakes, did not seem to care about fixing those mistakes, and did not care about preventing similar mistakes from recurring.
To play Devil's advocate (or rather, advocate of the developers): if they were a properly resources software-development team, they might have been better able to pay off the technical-debt accumulating in the codebase. Hopefully this injection of resources will change things for the better. (The LibreSSL crew seem to be making good progress on the technical debt front, also.)
It's ok, there's still time to be cynical: perhaps they've just woken up to the fact that Cisco are hurting bad after they lost everyone's trust, and don't want to face the same downturn.
Is a shark-portable version a possibility?
Don't ask me how they think they'll ever get a jet off the ground using solar, but I don't think they've even thought that far into it.
A straw-man so awful, it defeats itself.
You're right that for aircraft, there's no real contender to using oil-based fuels. Somehow you've taken this to mean we should continue to burn oil even where we don't need to.
10k foot
Really? That's almost two miles of wire. No-one notices that stuff going missing? Can't the tech be fired for this indefensible waste of resources, not to mention deliberately worsening a customer's service out of petty personal spite?
Maybe I think too much of 'the system'...
Plus, if the tech didn't like that customer, surely they'd want to avoid going back on account of connection issues...
Ah yes. The old because it actually works defence...
I'm pretty sure the endgame for the major content providers is to close that loophole.
Loophole? Bullshit. That's no less ridiculous than saying the endgame of Flash is to become a binay-blob in Firefox.
Firefox has long supported Flash, Silverlight, and Java, despite that they're proprietary (yes, except you, OpenJDK). No-one was crying then. All they've done now is implement a new way of having the DRM content tie itself into the browser.
I think it's absurd that there's such a thing in the HTML spec, but it is there, and Mozilla had a difficult choice:
Mozilla stood to lose a lot more in not supporting 'EME' than in supporting it.
So that's OK. Somebody else will do it and Mozilla will be the next Opera.
'do it'? Do what? Create a browser which deliberately doesn't support EME? You do realise this is like saying Mozilla should build a browser which doesn't support Flash, right? This bears repeating, as you really seem to have missed the point: Firefox will not include DRM binary-blobs, it will merely support this new component interface by which Firefox will interface with the DRM blob, in much the same way Firefox interacts with the Flash binary-blob.
If you dislike DRM and/or the binary-blobs, it's really quite simple: Don't install Flash, Silverlight, or any other proprietary plugins. These new developments change nothing here. You gain nothing by engineering your browser to not support the plugins.
Also, regarding Mozilla will be the next Opera: you have a very distorted view of what matters to most Firefox users. Your average non-techie is not aware of the issues addressed by the Free Software movement. They want a browser which Just Works, ugly DRM and all.
The average user does not think Mozilla are supporting DRM? The traitors! No. They would, however, think Netflix doesn't work in Firefox anymore, so I'll go back to IE.
Mozilla is big enough that they could have fought this.
They're big enough that major DRM'ed content providers might have worked to special-case Firefox were it not to support 'EME', sure, but this isn't to say they're betraying their users by supporting EME.
The only real downside I can see is that if it makes it much easier to install a DRM blob, it's likely to result in many more DRM schemes, as opposed to the current situation of really just 3 major 'plugins': Java/Flash/Silverlight.
The term 'tax-payer' has no meaning in this context.
The meaning seems pretty clear to me...
Are you SO bored or jealous of other people's achievements that you have nothing better to do than to sit around and nitpick the friggin' ad copy of a marketing page that was undoubtedly written not just for people who want to know the technical specifications of the product, but common usage applications for it also?
I'm a techie. Like many, I find vacuous marketing to be grating. That's really all I was trying to get across. It's a very minor detail, and a very minor dig. I'm not attacking your product.
(I can play at quasi-psychoanalysis though, if that's the game: are you so insecure about your product you have to rant at snarky Slashdotters, and imagine further insult which isn't there?)
What you're calling a "buzzword" is information that business wonks need to know when faced with the question, "Will this solve my problem/fulfill my needs?"
Other than a mention of JSON support, nowhere on the page are there any web-specific points being made. The section labelled 'Web 2.0' then goes on to discuss scalability. I get that scalability is what's being hinted at, but really this situation should be reversed.
I wasn't commenting about Postgres-XL, or PostGres. Indeed, I warm to Postgres - a rare example of a 'proper, grown-up DBMS' that prioritises correctness - and I like the general look of Postgres-XL.
I like the way the linked page uses Web 2.0 when it means scalability.
Great job with the buzzwords.
It was a pretty awful film, with a pretty awful message. I remember an early scene where Jackson's character batters a fellow torturer for... enjoying it too much, or something.
As you say, Jackson's character kills the bad guy's wife... without giving him any forewarning. Doesn't that defeat the point? Tell me what I need to know or I'll kill your wife at least gives you leverage, but there's not much to be gained just outright killing her.
The film did at least cover that without an immediate way to verify claims, torture can yield false information. As you say though, the film really pushes the idea that the solution would have been more and better torture, because in letting up, they gave the bad guy time to regain his energy for resisting torture.... Pretty sure that no-one has ever lasted more than 3 minutes of waterboarding without 'breaking'.
I get the impression that entertainment like 24 has had a pretty dire effect on people's opinions on this stuff... (Unthinkable at least had the decency to be a genuinely awful film.)
The problem lies not in the lack of "native" C calls (you mean in-line C call sequences in jitted code, I presume)
Yes, just so. Getting high-speed calls to C was a big break for HotSpot, as JNI had long been a real performance problem. People would have to optimise their Java/JNI/C programs to minimise the number of calls between the two languages. (Calling Java from C is still somewhat slower, by nature - HotSpot isn't in the business of producing C functions.)
V8 can't inline and inter-procedurally optimize the DOM manipulation methods - because they're opaque blobs of compiled C++ code and not some intermediate form of it.
Deep inlining is nice, of course, but I can't imagine it being a total game-changer for something like this. In a typical C++ program, there's an 'inlining barrier' when you link against a binary library. I could be wrong though, and I don't have any numbers to hand, but if we look at today's C-family compilers, whole-program optimisation is a really great feature, but it's not revolutionary.
I don't see why the same approach should be inapplicable to Canvas and WebGL. Isn't there a lot of Canvas calls that simply change the drawing state for later operations?
I don't get you.
In a happier alternative universe, Java wasn't a goddam disaster when it came to applets and desktop GUI.
Even ignoring the horrendous bloat and browser-crashing tendencies of the Java of old, the security model has always been - and will continue to be - a bad joke. The way they conflate a platform in which secure software can be effectively developed and a platform which effectively resists malicious input programs boggles the mind. Java has a really very good track-record in the former, but its horrific track-record in the latter rather mars it...
Sun's reasoning, as far as I can tell, went something like this:
Screen goes wobbly, camera pans to Sun Microsystems strategy meeting
You know how we could make fast, secure software? Efficiently-implemented high-level languages! We know that C-family languages are an awful choice for developing secure programs... Ok then, let's implement a high-performance virtual-machine for our 'Java' virtual platform. We'll write it in C++, because high-level languages are slow. I'm sure the security will be fine, after all, we're calling it a sandbox, and if we call it that, it's sure to be immune from attack by way of malicious bytecode. Most C++ programs are vulnerable to buffer-overflows, but ours is a sandbox, so it's sure to be just fine.
A few years pass
This is going great. Java has been a great success in 'enterprise' web servers, so we'll push most of our resources at that. We'll keep promoting Java applets though, and we'll ignore the unending stream of security flaws in our 'sandbox', because developing a decent server-side JVM is more important. We could put our money where our mouth is and develop a secure JVM, in, say, Java, but no, we'll keep pushing this bug-filled C++ monstrosity, and keep pretending the 'sandbox' is trustworthy. The bloat can stay too, the server crowd don't seem to mind.
What's that? Someone went and built a secure JVM, in Java? Jikes RVM, you say? With a full JIT compiler and all? Nah, we'll carry on pushing our server product as a secure in-browser sandbox. Applets are sure to catch on any day now, security laughing-stock or not.
Correct. In short, then: asm.js is working as intended.
I don't think the memory-allocations would be a major concern though. The fact that JavaScript is an all-round nightmare of a dynamic language is the hard-to-get-fast part, as it's very difficult for the compiler to reason about safe optimisations.
(See Lua for a non-nightmare dynamic language: it has a pretty damn fast JIT (LuaJIT), which was developed by just one man. Compare with: V8, which took a whole team of Google's engineers working for quite a while.)
This is relevant... how?
My comment was regarding the efficiency of asm.js. At what point did I turn the conversation to the relative merits of JavaScript and C++?
In ideal conditions, C++ compiled to JavaScript, using asm.js, can be almost as fast as an 'ordinary' build of the C++ code.