Ah... diving into the original MS article https://blogs.msdn.microsoft.com/vcblog/2018/01/15/spectre-mitigations-in-msvc/ I think the idea is as a defense-in-depth mitigation for *trusted* code that processes *untrusted data* (and thus might be tricked into doing something that accesses trusted data elsewhere in the process, on behalf of some untrusted code).
Am I really confused or does this description of MS compiler 'fix' for Spectre variant 1 seem really confused about which code is vulnerable and which is changed? IUIC you could just use a pointer of your choice and not even bother with the Spectre stuff if you can write arbitrary C code injected into a process...? Compiler changes for managed VM code would prevent use of "safe code" loaded in-process for exploiting the attack, though right? Or am I backwards?
#emscripten hack: on IE 11, the Math.imul polyfill is a bottleneck for VP8/VP9 decoding in #ogvjs. Replacing it with direct multiplication results in a noticeable speedup, but assumes no overflows will happen and breaks asm.js validation. ;)
Of course users will get far bigger performance gains from using Edge or Firefox or Chrome or Safari or anything other than IE 11. ;)
Object-oriented-style C is still kind of a pain. Nice that it doesn't hide the complexity, but annoying that I have to type a lot. Considering C++ for this polymorphic wrapper code. :P
Size overhead in emscripten output is minimal if i build with -fno-exceptions (don't need em in my code). But C++ grates too -- pure-virtual destructors must have a function body, for instance (wait what?)
Still pondering how much to directly share code between OGVKit (iOS, C/Obj-C) and ogv.js (web, JS + C/emscripten). Pretty solidly planning to share the demuxer and codec wrapper & support code more since I've been cribbing functions back and forth. But would it be worth doing the player logic in one C implementation with callbacks versus two Obj-C and JS implementations? Decisions, decisions.
Think of all the stuff that still uses gtk2.
Gtk2 is not unmaintained, but it's in life support mode, thanks to people who actually get paid to do it.
Apps that haven't (been able to) switch to gtk3, they are maintained by people who *don't* get paid to do it.
Meanwhile, end users absolutely depend on those apps. We don't have that many "big" applications in free software, and we don't have an infrastructure for people to pay for them.
This is fucked up.
ogv.js 1.5.6 now detects and works around wasm bug on iOS 11.2.2-11.2.5 automatically.
Or this version which I commented up and prettied as a cjs module to use in ogv.js :) https://github.com/brion/ogv.js/blob/master/src/js/WebAssemblyCheck.js
Refactored my test case for wasm fail on iOS 11.2.2+ to a single JS file that runs synchronously: https://github.com/brion/min-wasm-fail/blob/master/min-wasm-fail.js
Feel free to nick it to use in #emscripten projects that need to fall back to asm.js versions on iOS!
The default open-source nvidia graphics driver is a bit sluggish at 2160p, and more sluggish at 2x 2160p, but it'll do for now.
Also sometimes I have to reset the 200% scaling on my monitors, but that's probably because my monitor has crappy firmware. But I can now do that through the GNOME Settings app very easily, instead of manually running a command like I used to have to.
MediaWiki, ogv.js, OGVKit, mtpng, formerly StatusNet, human decency, puns.
This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!
Hosting costs are largely covered by our generous supporters on Patreon – thanks for all the help!