FSF's statement: criticism, but also constructive ideas
FSF's statement: criticism, but also constructive ideas
Posted May 15, 2014 13:45 UTC (Thu) by Zack (guest, #37335)In reply to: FSF's statement: criticism, but also constructive ideas by khim
Parent article: Firefox gets closed-source DRM
There is no "because" in that line of reasoning.
As long as they stand for something, and there's one person listening, they're not irrelevant, in spite of your clamouring.
The only way for the FSF to become irrelevant is if they did the opposite of what they said they would do, like mozilla is doing right now.
I hope Mozilla will enjoy their market share, but really, why should I use firefox now? They're just another browser, warm fuzzies of the past notwithstanding.
They need the marketshare to "do good"? What "good" is there left to be done if the things you are doing to gain marketshare is contrary to the reason you exist?
Posted May 15, 2014 17:13 UTC (Thu)
by gerv (guest, #3376)
[Link] (23 responses)
You really think there's now nothing good that Mozilla could ever do? Forgive me for suggesting that this is hyperbole.
I've already seen one email that a high up person in Mozilla has received about plans to extend DRM to other things. I would not be surprised if all such emails were referred to the response given in the case of Arkell vs. Pressdram.
Posted May 15, 2014 18:50 UTC (Thu)
by coriordan (guest, #7544)
[Link] (17 responses)
First H264, then a weakened form a net neutrality, and now DRM - and with Adobe. These don't make Mozilla an enemy, but people are disappointed.
Each announcement has a paragraph with a regretful tone, but still presents these compromises as being good for users.
We've heard the bad news, that Mozilla is developing DRM, but can you give us the good news? Are there good fights Mozilla fighting behind the scenes? Surely the weak bargaining position that left Mozilla feeling it was forced to do something has hardened Mozilla's resolve to exterminate DRM - what's Mozilla doing on that front, what action is behind the paragraphs with regretful tones in the announcements?
What about FSF's suggestion for Mozilla to "devot[e] as many of their extensive resources to permanently eliminating DRM as they are now devoting to supporting it"?
Posted May 15, 2014 23:24 UTC (Thu)
by roc (subscriber, #30627)
[Link] (16 responses)
I haven't even listed anything the Mozilla Foundation is doing.
Posted May 16, 2014 2:00 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (15 responses)
Thanks a lot.
Posted May 16, 2014 2:53 UTC (Fri)
by roc (subscriber, #30627)
[Link] (14 responses)
asm.js apps run on all major browsers, because their behavior is entirely determined by existing Web standards (JS, WebGL, Web Audio, etc) already implemented by those browsers. That's about as far from "proprietary platform" as you can get. All we did is define a special subset of JS, document that subset, and optimize for it. Other browser vendors are also optimizing their engines for these apps.
You can call it dysfunctional if you like, but it's bringing stuff like Unreal Engine and Unity to run on a fully open source, open standards stack, so it's clear win for Mozilla's principles.
Posted May 16, 2014 3:02 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (13 responses)
So Mozilla just created yet-another-bytecode, and it is about as ugly as it gets.
What's more, WebKit is moving towards using LLVM for JavaScript optimization. So on those platforms asm.js is just unnecessary and stupid layer.
Posted May 16, 2014 15:55 UTC (Fri)
by raven667 (subscriber, #5198)
[Link] (3 responses)
Posted May 16, 2014 16:12 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
As any other bytecode, it needs a virtual machine/JIT for it. It's just fairly easy to adapt Mozilla's JIT to work with it, but some kind of special treatment is needed nonetheless.
Having JS as an extra layer above LLVM rather than thin PNaCl wrapper is simply stooopid.
Posted May 17, 2014 6:15 UTC (Sat)
by roc (subscriber, #30627)
[Link] (1 responses)
You keep repeating this, but it's not true. Every valid asm.js program is a valid JS program, and its behavior is the behavior defined in the JS spec, so any compliant JS engine will run it correctly.
Posted May 17, 2014 7:01 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted May 16, 2014 23:22 UTC (Fri)
by roc (subscriber, #30627)
[Link] (8 responses)
Exposing LLVM bitcode as a bytecode format is a poor technical decision. LLVM was not designed for this role. In particular LLVM bitcode exposes undefined behavior, so if your program accidentally relies on any undefined behaviors, its behavior can change any time Google updates the PNaCl implementation (i.e. every six weeks), as well as varying across CPU architectures. See https://developer.chrome.com/native-client/reference/pnac... for more information. Even more information here:
Posted May 16, 2014 23:44 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (6 responses)
> "Your version of Chrome is to old to run this content. You need at least Chrome 35. Press Ok if you wish to continue anyways."
Nope, doesn't work. And I have the newest version of Chrome. So thanks a lot for proving my point.
> Exposing LLVM bitcode as a bytecode format is a poor technical decision. LLVM was not designed for this role.
And consequently, all the PNaCl undefined behaviors are present in asm.js, except for the stuff with bitshifts (I think).
> The behavior of asm.js code is fully defined by the JS specification, which makes it the better technical solution for a portable code format.
Posted May 17, 2014 6:11 UTC (Sat)
by roc (subscriber, #30627)
[Link] (5 responses)
I tried it in Chrome dev (36) and it did work. I don't know why it doesn't work in Chrome 34, but I assume it's just a bug that Google fixed after that. They certainly didn't "add support for the asm.js platform" in 35.
> all the PNaCl undefined behaviors are present in asm.js
That is completely wrong. Every single behavior under the "Not Well-Defined" list on Google's page, if present in a C program compiled to asm.js via Emscripten, will produce a JS program which will have the same behavior on any spec-compliant JS engine. For example, an out-of-bounds pointer access in asm.js turns into an array-out-of-bounds exception that must fire in exactly the same way on all JS engines.
asm.js may be ugly, but it's still the technically superior solution.
Posted May 17, 2014 7:00 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
> That is completely wrong. Every single behavior under the "Not Well-Defined" list on Google's page, if present in a C program compiled to asm.js via Emscripten
Right, exactly the same as in PNaCl - you're at the mercy of the C++ compiler.
And as a bytecode, the Google's subset is almost completely deterministic. I.e. a program in PNaCl will work on all supported platforms similarly. If it doesn't then it's a bug.
> For example, an out-of-bounds pointer access in asm.js turns into an array-out-of-bounds exception that must fire in exactly the same way on all JS engines.
> struct Hello
And you'll get a good old undefined behavior in the C/C++ sense. Also dependent on compiler settings, like structure alignment.
> asm.js may be ugly, but it's still the technically superior solution.
Posted May 18, 2014 6:00 UTC (Sun)
by roc (subscriber, #30627)
[Link] (3 responses)
Given it's undefined behavior in C++, the C++ compiler can turn it into any JS it wants. But the JS it produces will run the same way on any spec-compliant JS implementation. For example, if the compiler generates the obvious JS code "2 << 32", the JS engine will compute 2, because the JS spec requires the shift count be masked by 0x1F before the shift:
> And as a bytecode, the Google's subset is almost completely
That's not true in this case. If you read the Google page I quoted, PNaCl does not specify the results of all shifts: "There is still some architecture-specific behavior." They say it's "potentially fixable" but there's no indication they intend to fix it. You could argue "it's a bug" but it's hard to distinguish between implementation bugs and design bugs in PNaCl since it has no fully detailed spec --- one of the reasons why it's an inferior solution.
> There are no pointer checks in asm.js, and you know it perfectly well.
The behavior of the C++ code is undefined. The behavior of its JS translation is defined. That matters because it means once you've tested it in one JS VM you'll get the same behavior in other VMs.
The threading stuff is an issue. We're working on it, and I think you'll be surprised by how simple we can make the solution.
Posted May 18, 2014 7:16 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
> The behavior of the C++ code is undefined. The behavior of its JS translation is defined. That matters because it means once you've tested it in one JS VM you'll get the same behavior in other VMs.
> The threading stuff is an issue. We're working on it, and I think you'll be surprised by how simple we can make the solution.
Posted May 18, 2014 11:43 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
Well, we already live in a world where direct access to such things can only (safely) happen from one thread anyways (Qt, GTK, and others I'm sure). Maybe they're working on something like signals and slots which work across threads? Or proxy objects to use in other threads?
Posted May 18, 2014 12:10 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link]
After all, PPAPI has only one fatal flaw - http://www.drdobbs.com/windows/a-brief-history-of-windows... I believe, that it describes the current Mozilla perfectly...
Posted May 22, 2014 1:15 UTC (Thu)
by foom (subscriber, #14868)
[Link]
Note that Chrome and Firefox do behave differently there: Chrome starts out slower, but ends up running the pypy-asmjs code faster than current-firefox.
Posted May 15, 2014 20:16 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link]
One notable example I've seen is the plans for Keurig to implement DRM such that only Keurig-approved K-cups will be brewed. Can you share what the other targets might be?
Posted May 15, 2014 20:59 UTC (Thu)
by Zack (guest, #37335)
[Link] (3 responses)
No, I think it doesn't matter anymore what Mozilla purports to be doing. Right now it's a money-burning organization that sits in between Google and Firefox, paid to wave an "open web" banner around. I might as well save Google the money.
You had *one* job, Mozilla...
Posted May 15, 2014 22:44 UTC (Thu)
by dlang (guest, #313)
[Link] (2 responses)
Posted May 15, 2014 23:41 UTC (Thu)
by Zack (guest, #37335)
[Link] (1 responses)
Now, with all vendors being more or less equal, one might as well take up gerv's own suggestion and use Chrome(ium), if only in the hope to send a signal to Google that they might consider to stop spending money on Mozilla so some people will get sacked, and a leaner and meaner Mozilla might do some soul searching about what their real role in the digital world is supposed to be.
Posted May 15, 2014 23:50 UTC (Thu)
by dlang (guest, #313)
[Link]
Mozilla never had the power to be the Steward of the Internet. If you are upset at them for compromising that position, then you just never understood their power in the first place.
FSF's statement: criticism, but also constructive ideas
http://en.wikipedia.org/wiki/Arkell_vs_Pressdram#Litigation
Can you tell us about Mozilla's anti-DRM efforts?
Can you tell us about Mozilla's anti-DRM efforts?
-- Standardizing and implementing improvements to Javascript to make Web apps better. Other vendors aren't so keen to do this since they have their own proprietary platforms to protect (.NET, Dart, PNaCl, etc).
-- With asm.js etc we're getting games off Flash and onto the Web (e.g. Unity) where they work across platforms without requiring closed-source components.
-- asm.js and other stuff we're doing is keeping developers on Web standards and off the Google-controlled PNaCl/Pepper platform.
-- Given Apple and Microsoft hardly engage at all in Web standards development, if not for Mozilla Google would be improving Web standards all by themselves --- but of course that doesn't really work. In particular because with only a single implementation of a standard its bugs become de facto part of the standard. (E.g. we fixed many broken things in the Web Audio spec.) After Opera dropped out, if Mozilla (or Google) were to drop out, the "two independent implementations" principle would enfeeble Web standards development.
-- Developing and deploying free audio and video codecs (Opus, Daala).
-- Developing new safer language (Rust) and browser engine (Servo) so one day Web security won't depend on millions of lines of C++ code.
-- Developing Shumway, the best open-source Flash replacement.
-- Providing a much more open-source alternative to Android for low-end phones. If nothing else this makes it harder for Google to fully impose their will on OEMs.
-- Pushing privacy features like DNT and Collusion/Lightbeam.
-- Building free geolocation service (Mozilla Location Service).
-- Specification and implementation of WebRTC so we can get people out of closed-source (and closed-network) services like Skype/Hangouts.
-- Investing in open source libraries like Harfbuzz that the entire open source community benefits from.
Can you tell us about Mozilla's anti-DRM efforts?
So Mozilla decided to create its own proprietary platform - asm.js. Complete with dysfunctional memory management, threading and graphics.
Can you tell us about Mozilla's anti-DRM efforts?
Can you tell us about Mozilla's anti-DRM efforts?
Can you tell us about Mozilla's anti-DRM efforts?
Can you tell us about Mozilla's anti-DRM efforts?
Can you tell us about Mozilla's anti-DRM efforts?
Can you tell us about Mozilla's anti-DRM efforts?
Can you tell us about Mozilla's anti-DRM efforts?
http://permalink.gmane.org/gmane.comp.compilers.llvm.deve...
The behavior of asm.js code is fully defined by the JS specification, which makes it the better technical solution for a portable code format.
Can you tell us about Mozilla's anti-DRM efforts?
And so? PNaCL seems to work fine with only minor modifications and restrictions for LLVM. I managed to hack a Rust-to-PNaCl compiler in a weekend, for example.
Yeah, except that JS spec was written by poo-flinging monkeys. If LLVM bitcode is simply a bit awkward in places, Asm.JS is just full-blown ugly.
Can you tell us about Mozilla's anti-DRM efforts?
> lot for proving my point.
Can you tell us about Mozilla's anti-DRM efforts?
They did just this, in effect. Safari also doesn't work, btw. Abusing corner cases of a spec to make a bytecode out of JS has its consequences.
So what would: "int a = (unsigned int)2<<32;" do in a C++ code compiled into asm.js?
There are no pointer checks in asm.js, and you know it perfectly well. It's totally possible to write something like this:
> {
> char buf[20];
> int some;
> } world = {0};
>
> memset(&world, 11, 22);
> assert(some == 0); //Hmm?
No, it's not. For example, it still lacks threading - which CAN NOT be added to asm.js without adding quite a lot of stuff to JS itself.
Can you tell us about Mozilla's anti-DRM efforts?
> into asm.js?
>
> Right, exactly the same as in PNaCl - you're at the mercy of the C++
> compiler.
http://www.ecma-international.org/ecma-262/5.1/#sec-11.7.1
> deterministic. I.e. a program in PNaCl will work on all supported
> platforms similarly. If it doesn't then it's a bug.
> It's totally possible to write something like this:
>
> struct Hello
> {
> char buf[20];
> int some;
> } world = {0};
>
> memset(&world, 11, 22);
> assert(some == 0); //Hmm?
>
> And you'll get a good old undefined behavior in the C/C++ sense. Also
> dependent on compiler settings, like structure alignment.
Can you tell us about Mozilla's anti-DRM efforts?
It's a bug and they're planning to fix this, once a good trade-off can be found. And you might notice that it's almost the only real issue. The rest are more of a kind: 'Your program will crash differently on various platforms if you try to do something stupid'.
So is PNaCl's behavior.
Without any modifications to JS? How about interfaces with sound, graphics and DOM?
Can you tell us about Mozilla's anti-DRM efforts?
Can you tell us about Mozilla's anti-DRM efforts?
Can you tell us about Mozilla's anti-DRM efforts?
https://rfk.id.au/blog/entry/pypy-js-faster-than-cpython/
FSF's statement: criticism, but also constructive ideas
FSF's statement: criticism, but also constructive ideas
FSF's statement: criticism, but also constructive ideas
FSF's statement: criticism, but also constructive ideas
FSF's statement: criticism, but also constructive ideas