Great analogy. Li-ion batteries have several layers of defense against exploding, one of which are vents that, if all else fails, let the hydrogen gas safely escape rather than building up. It's perfectly fair for independent testers to say "we haven't found any flaws in the protection circuitry yet, but we should bypass it to see if the vents work as designed".
To each their own. I find soldering (with a nice iron!) very therapeutic, much like knitting. I'll put on a good album or catch up with some friends on the phone.
If you're impatient, plenty of fab houses (like JLCPCB) will do all the soldering for you, for about 0.1 cents per SMD joint or 2 cents per THT joint...
That's effectively time-based request sharding which seems sensible but you'd still have to reconcile trades and any open positions (etc) across the time boundary where one system stops accepting requests and the other one starts. And keep the databases synchronous (ie have some system to make sure they're in sync at the changeover time) - or have a few minutes/hours of downtime between weekends and weekdays while you copy the whole production database from one system to another. The devil is in the details!
I can't find the original source, but I remember reading a study showing that this rise was closely correlated to states which had legalised or loosened laws on gambling!
Above 400MHz or so, the on-die/on-chip capacitance starts being the most important thing (you're going to have inductance through the legs or balls of the chip).
Putting your decoupling capacitors next to the power pins _does_ cost. Not just in board space, but I've seen and reviewed layouts where the signal traces had to snake around decoupling caps or in some cases through vias because the designer believes that putting the caps close to the pins was the most important thing...
Truly! As someone who's worked with HPC and GPUs in a scientific research context, trying to get a service like this to work reliably is a different ballgame to your usual webapp stack...
This is probably a good place to debunk the usual wisdom that "decoupling capacitors must be placed very close to the IC pins". If you're using a solid power plane, rather than routing power through traces (and honestly 4/6 layer boards are cheap enough these days) it really doesn't matter where you place decoupling capacitors for most uses - keep the via traces short or ideally in the pad, and you can put all your decoupling capacitors in one place on the boards a way away from the chip and focus on good routing of your signals. Figure 15 on this paper (and the whole paper!) explains it well: https://scholarsmine.mst.edu/cgi/viewcontent.cgi?article=221...
So, the concentration is 1000x less than the carcinogenic threshold in mice, and it's possible that our carcinogenic threshold is even higher than that, but the advice is "be careful how you store your potatoes and don't fry them too much and don't eat charred toast"? Surely the correct response is "it's probably totally fine"
"I went through about a dozen AI tools I've personally authorized in the last year after reading this. Nine of them have Google Workspace OAuth permissions that include reading all emails and accessing all Drive files. Nine. I authorized every one of them without reading the permissions because the onboarding flow asked and I was in a hurry."
Do other (tech-literate) people do this?! Giving anything access to my emails and Google Drive would keep me up at night and I try and be very granular with permissions and revoke them when I don't use an app any more. I would assume that anything confidential/NDA in my emails had been compromised and leaked well before this point!
It's hard to avoid, but there are steps we can make towards fixing it. I spent years in academia building open-source data processing pipelines for neuroscience data and helping other researchers do the same. Most quantitative research goes through "lossy" steps between raw data and final results involving Excel spreadsheets, one-off MATLAB commands, copy pasting the results, etc.
In a lot of cases (where data is being collected by humans with a tape measure, say) there is room for error. But one of the things that's getting traction in some fields is open-source publication of both raw datasets and the evaluation/processing methods (in a Jupyter Notebook, say) in a way that lets other people run their analysis on your data, your analysis on their data, or at least re-run your start-to-finish pipeline and look for errors!
As is often the case, the holdups are mostly political: methods papers are less prestigious than the "real science" ones, and it takes journals / funders to mandate these things and provide funding/hosting for datasets for 10+ years, etc - researchers are a time-poor bunch and often won't do things unless there's an incentive to!
I'm always curious what RoI analysis goes into this kind of decision - whether to leave on-prem and join the cloud, or vice versa. The numbers always seem huge, and in opposite directions. "Moving from onsite datacenters to AWS saved us $2m/year!"
Has something changed with AWS' pricing recently, have their business needs changed over the years, or were the calculations (to use AWS) just wrong to begin with?
This is called a "series hybrid" rather than the more common "parallel hybrid" (eg Toyota Prius) and has been around for a while, including the BMW i3 with range extender (and London buses, and various other vehicles!). It's more expensive largely because the battery pack needs to be sized much larger to be able to provide enough current for all propulsion / regen. On the other hand, the combustion engine can be undersized and run at its most efficient RPM continuously - the BMW range extender is a 600cc little scooter engine that can provide enough power for continuous highway driving.
It's ironic that Backblaze themselves wrote a blog post a couple of years ago explaining why Dropbox isn't enough as a backup service and you need Backblaze as an additional layer of protection: https://www.backblaze.com/blog/whats-wrong-with-google-drive...
In other "incorrect calendars" bugs, there's the Rockchip RK808 RTC, where the engineers thought that November had 31 days, needing a Linux kernel patch to this day that translates between Gregorian and Rockchip calendars (which are gradually diverging over time).
Good $3 MEMS gyros are about 100x better than that now - look at anything new made by Invensense in the past couple years. And their drift is pretty Gaussian-distributed, so the error scales as sqrt(n). If you combine 8+ of them on one board you can get about 5deg/hour stability...