MertsA

I once wrote a PoC for reading data off of a dead Open Compute Grand Canyon server that wouldn't boot by sneaking it off of the HDDs through a sideband through the BMC. Never say never.

Even with "E2E" encryption with iMessage, you're still trusting Apple completely and totally with key distribution. If a new device is added to your account by an attacker or by Apple themselves, your existing devices will happily loop them in to share iMessage access with them. The vast, vast majority of iMessage users are never going to dig into the Apple keychain app to actually check what keys are being trusted and this is something that can be targeted to a single account so no one outside of Apple never even needs to know it happened.

How does this square with FOIA obligations? I get ICE sidestepping transparency by avoiding creating the responsive footage in the first place, but once the body cam footage exists, what basis could they use to withhold it other than redacting footage for the typical reasons?

That's going to be on the $20 plan. IIRC the $100 and $200 plans keep the 50% fable usage.

You need at least twice the frequency range for sample rate in order to represent the original signal. That's slightly misleading though, that's from the Nyquist-Shannon sampling theory and it's a mathematical fact but that is true for exact numerical samples, once you add in quantization that muddies the water a bit. Taken at the extreme, it's straightforward to see why a 1 bit quantization per sample at 44.1 kHz would not capture a perfect representation of some analog signal even if there's only a 1 kHz frequency component to the signal. If we instead decide to sample at 10 MHz but still one bit quantization, now that 1 kHz frequency component can be much more accurately represented even though we're still using the worst quantization possible. Don't think of quantization like a square wave or a step pattern, think of it as "the signal is closer to here than any other discrete value".

Now in terms of realistic audio encoding, 16 bit at 44.1 kHz is designed to be a faithful representation as far as human hearing is concerned. Can someone with a trained ear potentially tell the difference between that and 24 bit at 192 kHz? In a studio environment it's possible. Most audiophile claims are dubious and a blind A/B test catches them out on most of it but the Nyquist-Shannon sampling theorem does not directly apply to quantized samples, it's about exact samples and with quantization, sampling rate is intertwined somewhat with the quantization depth.

That's a halted firewall setup. Normally as part of shutdown you would tear down networking in SysVinit or systemd but you don't actually have to do that. When shutting down you can choose whether to power off or just to halt. It's basically like the old Windows "It is now safe to power off your PC".

Like when Runescape allowed you to purchase membership via a premium rate number. Lots of fraud going on back when that was a thing and a big part of why it's no longer a thing.

There are some typos like "if" instead of "of" that seem to imply at the very least, some of it is verbatim written by a person. Given the subject matter, I'd be extremely surprised if this was 100% AI but one thing I've totally done for similar technical writing is ask AI for help refining a rough draft. There's some suggestions I'd ignore but the larger grammatical and sentence structure suggestions I'd usually adopt.

A bootable container, kernel included, is not a container. Building a whole new OS image for patches isn't a bad idea, but depending on the workload this might be a non-starter. At the very least, make updates to the OS image incremental ala OSTree. kexec can also be a nice speedup on server hardware but that carries its own risks from kexec itself but also from lack of exercising cold boot. It's not nice to find out about a few percent of hosts failing to boot all at once because nothing tested it for months until the power outage.

IMHO, optimizing your update process and treating whole OS environments like we do containers is good, but there are plenty of environments like stateful services where a rolling reboot can still take months to complete if done in a naive way.

Thorium isn't fissile, it's fertile. All thorium reactors work by breeding that thorium into uranium.

While DAOS looks cool, from their roadmap it looks like they still don't have a fault domain larger than a server... Their erasure coding profiles also look pretty thin. I'm ex-Meta, our infra had vastly different availability and reliability requirements but that looks like it'd be painful to support at scale.

You can shrink XFS, but only the realtime volume. All you need is xfs_db and a steady hand. I once had to pull this off for a shortened test program for a new server platform at Meta. Works great except some of those filesystems did somehow get this weird corruption around used space tracking that xfs_repair couldn't detect... It was mostly fine.

If you already know the checksum for some huge chunk of the message then you don't need to recompute it to append some data and get a new checksum (at least for CRC). On the read side you would want to have checksums at whatever granularity you want to be able to read but for a larger combined CRC checksum you don't need to ever reread data to append or prepend to it.

Wifi would probably be the easiest. Either hide a dummy AP in the house or use a combination of multiple neighbors APs. If you don't see any beacon frames from the dummy SSID for a 30 second period then lock/shred the computer.