My uneducated guess is that crew members in the back galley could have been injured by unsecured items they were loading falling or sliding. The service cart itself is 200-250 lbs. With the rear galley accelerating upward, then a sudden halt to the acceleration when the front nose impacts the ground, I could imagine the cart lifting off the ground and landing on feet or legs. Or putting the cart aside, other items such as drink cans, galley appliances, etc. falling from cabinets or counters could cause injury
I'm seeing GitHub Actions runs not occurring. A colleague is experiencing 500s (angry unicorn) and issues with Codespaces.
I always check DownDetector and Updog whenever something seems strange about GitHub behavior, they tend to pick up issues before the official status page.
I've found Claude Code's built-in sandbox to strike a good balance between safety and autonomy on macOS. I think it's available on Windows via WSL2 (if you're looking for a middle ground between approving everything manually and --dangerously-skip-permissions)
Speculative decoding takes advantage of the fact that it's faster to validate that a big model would have produced a particular sequence of tokens than to generate that sequence of tokens from scratch, because validation can take more advantage of parallel processing. So the process is generate with small model -> validate with big model -> then generate with big model only if validation fails
100% agree on the better video hardware. I found out this weekend the Raspberry Pi 5 removes the dedicated video encoder present on the Pi 4B. I was getting 2-3 fps in OBS, which makes it unusable for my application. Any mini PC would do much better with dedicated encode capabilities.
To be fair, I haven't messed around with video encoding settings yet. I've seen claims the Pi 5 can do 1080p60 with 50% of the CPU. I could trade off quality for faster encoding, but with a mini PC I could get high quality encoding at real-time speeds.
I'm feeling some buyer's remorse with the Pi 5 right now...
Technically yes. But it can take months to years to experimentally obtain the structure for a single protein, and that assumes that it's possible to crystallize (X-ray), prepare grids (cryo-EM) or highly concentrate (NMR) the protein at all.
On the other hand, validating a predicted protein structure to a good level of accuracy is much easier (solvent accessibility, mutagenesis, etc.). So having a complex model that can be trained on a small dataset drastically expands the set of accurate protein structure samples available to future models, both through direct predictions and validated protein structures.
So technically yes, this dataset could have been collected solely experimentally, but in practice, AlphaFold is now part of the experimental process. Without it, the world would have less protein structure data, in terms of both directly predicted and experimentally verified protein structures
On my Framework (16), I've found that switching to GNOME's "Power Saver" mode strikes the right balance between thermals, battery usage and performance. I would recommend trying it. If you're not using GNOME, manually modifying `amd_pstate` and `amd_pstate_epp` (either via kernel boot parameters or runtime sysfs parameters) might help out.
I agree that it's unfortunate that the power usage isn't better tuned out of the box. An especially annoying aspect of GNOME's "Power Saver" mode is that it disables automatic software updates, so you can't have both automatic updates and efficient power usage at the same time (AFAIK)
Typer has a great feature that lets you optionally accept argument and flag values from environment variables by providing the environment variable name: