It's a very old API that was speced before promises were a thing. Once you ship an API, sites start using it, and if you change behavior, you break them. If your browser ships the behavior change first, and breaks a website, people just assume your browser is the one that's broken, and switch browser. So browsers don't like to change behavior, especially before other browsers have, or if other browsers won't.
At least in Firefox's case, it's hard to be confident that the decoders we use for H.264 (the most commonly used codec at the time) would support a given mime type.
Firefox uses the operating system's H.264 decoders, because we had a policy of not feeding the patent trolls. H.264 has a plethora of different levels, profiles and features [1]. The documentation for operating system's H.264 decoders often isn't very clear as to what profiles/levels/features they support. Sometimes the user has installed codec packs which affect what codecs are playable. Sometimes the user is on Windows K/N which ships without H.264 codecs. So the only way to give an accurate answer to the question, is to actually start up Windows Media Foundation, and run some video through them. This requires loading DLLs from disk, and obviously we don't want to be blocking on disk IO in the browser's JS event loop in order to accurately answer this question, and we might not have an example file for the specific combination of profile/level/features the script was asking about. In the end, we ended up doing a "test decode" on startup of the common profiles and caching the result in the user's profile. But again, if the user asks about an obscure profile or level combination we've not tried, we can't necessarily be confident that we'll actually be able to play this.
Saying "yes" optimistically and being wrong would be bad, as then the player would appear to be broken in your browser, leading users to switch browser. So the idea was script would try a few profile/level/feature combinations and pick the best to which the browser returned yes.
We probably could have done a more accurate job here if we had more time, but it's always a trade off between marginal benefits here, verses fixing something else.
I have the TP-Link AV2000 and found them good. My office has a bunch of metal laundry appliances and concrete walls between my desk and the wifi router, so wifi signal is terrible there. Solved it with the AV2000.
I also tried using a mesh wifi network, and was able to bounce a signal around the dead zone and get a WiFi signal with a higher bandwidth than the powerline ethernet, but I still found I got a lot of glitches in video calls, so went back to the powerline ethernet.
I've not noticed the problems other commenters here had with their adapters with the AV2000.
I initially tried a cheaper powerline ethernet, and it was worse than WiFi, so I'd recommend you buy the most expensive/best one that you can afford.
No one is saying you shouldn't wear them, the debate is whether or not countries should make it mandatory. If you require bicycle helmets then fewer people ride their bikes, leading to fewer people pushing for safe bicycling laws, more cars on the road, and a less active (and thus less healthy) population.
You're correct about what the evidence actually shows. But unfortunately quite a few people misinterpret it and end up saying that no one should wear a helmet at all, even voluntarily.
See for example this stupid article, which was originally titled "The Case for Ditching Your Helmet." I came across it because a friend posted it to Facebook as "proof" that wearing a helmet never made anyone safer.
But this isn't shown by the article. Cycling dropped, but there is no indication that this was caused by helmet laws. A much more detailed study would be required to determine the cause of reduced cycling.
Well, except that the same thing has been found in other studies as well. The results of this study are completely unsurprising to anyone who has read any other study of helmet laws in his/her life.
At some point you just have to accept the evidence.
It's not about accepting the evidence. It's about making sure we interpret it correctly.
The main question to ask is this: why exactly do mandatory helmet laws reduce bicycle usage, and what needs to be done to address it?
Is it that helmets are too expensive? (They aren't.)
Is it that they are too difficult to put on and take off? (They aren't.)
Is it that they are too uncomfortable? (Maybe, but not any more so than seat belts, and yet most people aren't arguing against seat belt laws.)
Essentially, I'm not against accepting the validity of the evidence from these studies. I'm simply against the mentality of "mandatory helmet laws reduce bicycle usage, therefore we must not have mandatory helmet laws." That conclusion is too simplistic. The topic requires further study.
Helmets are quite inconvenient. One's head gets sweaty, one's hair gets mussed, one can't hear anything for the wind noise, and seeing a helmet gives autocage drivers the psychological permission to leave about eight inches when passing. Those who chose to cycle without a helmet have their reasons, just like most other human beings who do as they choose.
Is it that they are too difficult to put on and take off? (They aren't.)
I wouldn't assume that. As far as I can remember, this is one of the main reasons cited for the reduction in cycling. Small things can change a persons behaviour significantly.
They're uncomfortable and inconvenient to keep with you once you're at your destination.
There is also potentially (depending on which studies you give credence) the danger of risk compensation causing helmeted cyclists to cycle more dangerously and automobile drivers to pass more closely to helmeted cyclists.
Obviously not scientific, but if you need some totally informal causative bro-science to allow you to swallow these empirical results:
Even if the benefits are "obvious", the large majority of people aren't self-improvement-focused supermen with significant reserves of willpower at their disposal. Even the smallest increase in the necessary "activation energy" (comfort, expense, convenience; whatever) necessary for a task is going to put a large chunk of the distribution on the "fuck it, I'll just drive" side of things.
This is why "engagement" and "user experience" are multibillion dollar industries. Compare abstinence-only education, condom usage, and (kinda, if you squint a bit) drug prohibition.
Ideally, you would want some survey data, although I think it might be hard to get people to say that they stopped riding their bike because wearing a helmet is inconvenient, even if it's true.
I don't think the argument is if bicycle helmets are good or bad, but rather bicycle helmet laws. You can be for wearing a helmet at all times and still against bicycle helmet laws. Much the same way you can be for the legalization of drugs but not be a drug user yourself.
I wouldn't try to convince you they're a bad idea, although I might try to convince you that they're just as good of an idea for pedestrians and people in automobiles, where they would almost certainly also save lives.
Gov't action to support bicycle helmets are a good thing - the point is that action to forbid non-helmeted biking turns out to be bad, as the main effect is not to nudge people from biking w/o helmet to biking with helmet, but to nudge people to not biking at all.
You are guided by faith, not data. You wore a helmet when you crashed, and you lived. You also wore socks and underwear.
EDIT: I realize that there is no debate, as I will "never convince (you) they're a bad idea." I'm talking to the people who are coming at this with an open mind.
The only time I've ever crashed on bicycle was the one time I wore a helmet. I have stopped wearing a helmet because of the same 'logic'. I use my bike to get to work.
One minute from now, someone is going to hit you in the head. You have the choice of whether to put on a helmet first, or not. Which would you choose? Thus the benefit of wearing a helmet is demonstrated.
Note H.264 support in Firefox is only available on Windows 7, and soon Vista. So if you want to support Windows XP, you will still need WebM, Ogg, or Flash fallback.
Use something like mediaelement.js which uses standard formats first and falls back to Flash if not - XP is a legacy platform so there's no point in investing time on it.
It depends. You'll get better integration into the browser if you transcode. But if you're doing the "YouTube testcase", just using a Flash player fallback (without transcoding) would probably suit your needs adequately.
You can install Cinnamon (the window manager used by Linux Mint), and it's very good. It behaves "traditionally" (i.e. like Windows 7), and it's much prettier than XFCE.
I recently switched to Cinnamon and couldn't be happier.
I never really liked Unity, i used Gnome Shell and it was usable ok. But for my work nothing seems to beat the good old taskbar-based design.
It's a very old API that was speced before promises were a thing. Once you ship an API, sites start using it, and if you change behavior, you break them. If your browser ships the behavior change first, and breaks a website, people just assume your browser is the one that's broken, and switch browser. So browsers don't like to change behavior, especially before other browsers have, or if other browsers won't.
At least in Firefox's case, it's hard to be confident that the decoders we use for H.264 (the most commonly used codec at the time) would support a given mime type.
Firefox uses the operating system's H.264 decoders, because we had a policy of not feeding the patent trolls. H.264 has a plethora of different levels, profiles and features [1]. The documentation for operating system's H.264 decoders often isn't very clear as to what profiles/levels/features they support. Sometimes the user has installed codec packs which affect what codecs are playable. Sometimes the user is on Windows K/N which ships without H.264 codecs. So the only way to give an accurate answer to the question, is to actually start up Windows Media Foundation, and run some video through them. This requires loading DLLs from disk, and obviously we don't want to be blocking on disk IO in the browser's JS event loop in order to accurately answer this question, and we might not have an example file for the specific combination of profile/level/features the script was asking about. In the end, we ended up doing a "test decode" on startup of the common profiles and caching the result in the user's profile. But again, if the user asks about an obscure profile or level combination we've not tried, we can't necessarily be confident that we'll actually be able to play this.
Saying "yes" optimistically and being wrong would be bad, as then the player would appear to be broken in your browser, leading users to switch browser. So the idea was script would try a few profile/level/feature combinations and pick the best to which the browser returned yes.
We probably could have done a more accurate job here if we had more time, but it's always a trade off between marginal benefits here, verses fixing something else.
[1] https://blog.pearce.org.nz/2013/11/what-does-h264avc1-codecs...