See my before-last paragraph above: no, regarding hardware video acceleration, even Chrome doesn't do what you describe. What you describe stands for non-video content crashes, which isn't what's being discussed here. Could the technique you mention be applied to video gpu crashes? I personally don't know and I'd lean towards "nope" (else Mozilla & Google engineers wouldn't be so exceedingly cautious about it). If anyone is knowledgeable enough to precise / contradict this, please chime in.
At any rate, even Chrome is built with zero hardware video acceleration support on Linux (hardware acceleration yes, hardware video acceleration no). Chromium does offer the option, just as hidden behind flags as Firefox, and until last month you had to build it yourself with a VAAPI patch left unmerged for years by Chromium devs.
That sounds nice in theory, but only works if you can (reliably) detect the cause of a crash. This is one of those things that sound much easier than it actually is.
oh my fridging gawd, i am so triggered by this. the site linked to is supposed to advertise a book on ux with some example content and yet literally every comment here is suggesting a way to improve on the UX of that with some even just downright reformatting the content as a comment.
i hope they don't sell a single book as this serves as an example of how to not do UX.
Yeah, this article is assuming a competitive environment when in reality there exists an arsenal of state tools available for corporations to entrench themselves as monopolies: IP protections, subsidies/contracts, regulatory capture, etc etc.
algorithms don't matter for shit to the person that controls the (mandatory) updates.
its the same issue with all modern e2e apps like whatsapp or signal, if there is a single client implementation its not secure at all to these kind of attacks.
> signal [...]
> if there is a single client implementation its not secure at all to these kind of attacks.
There are (where?) actually multiple "distributions" of signal, like textSecure on f-droid. Last I checked it worked with signal, but that was a few years ago.
Showing the deprecation message before the API that replaces it is actually out? Isn't that a bit of an a-hole move? I know everyone here is a developer and hates code older than a month, but really? Nobody gonna call them out on that?
on a gel you see the size, something coming up with exactly the right size even at 35 cycles indicates that there was at least some of what you designed the primers on in the sample. if you want higher certainty, with three primers you can get two different sizes ruling out any doubt.
with the rtpcr machine readout which only gives you the signal corresponding to how much was amplified over time you need tricks like the dual labelling.
unix pipes (stdin, stdout) are bytes, files are bytes, filenames are bytes. yet, for some reason python3 thinks al of those are text. its not the coders that are wrong, it is the language.
No, it's Python 2 that thinks those are all text. Python 3 makes you explicitly say "convert this stream of bytes into a text encoded string", and from then on it's a str object.
Python 2 was happy to (try to) let you call text methods on a JPEG. Python 3 draws an appropriate distinction between the two.
Python 2's "str" is a bytestring. All of those are bytestrings in Python 2 as they should be. Python 3 makes them text and suddenly i can not output data over stdout anymore without extra steps of switching the mode of stdout from some arbitrary text default.
kstrauer is right, but I'll elaborate and say that places where you are interfacing with Unix threads are input boundaries, so having the programmer make a choice makes sense. Arbitrary switching within a program does not.
the issue is that the language arbitrarily decides those things should be treated as text with some arbitrary encoding when all of them are decidedly not text.
