HN user

MertsA

2,396 karma

email: andrew '\x40' andrewmerts.com

Posts3
Comments1,166
View on HN

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.

Boot Naked Linux 1 month ago

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".

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.

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.

Tectonic some KV store,

Tectonic is built on ZippyDB which is a distributed DB built on RocksDB.

What's important here with S3FS is that it supports (1) a fuse client - it just makes life so much easier

Tectonic also has a FUSE client built for GenAI workloads on clusters backed by 100% NVMe storage.

https://engineering.fb.com/2024/03/12/data-center-engineerin...

Personally what stands out to me for 3FS isn't just that it has a FUSE client, but that they made it more of a hybrid of FUSE client and native IO path. You open the file just like normal but once you have a fd you use their native library to do the actual IO. You still need to adapt whatever AI training code to use 3FS natively if you want to avoid FUSE overhead, but now you use your FUSE client for all the metadata operations that the native client would have needed to implement.

https://github.com/deepseek-ai/3FS/blob/ee9a5cee0a85c64f4797...

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.

iMessage is not on the same playing field as Whatsapp and Signal. Apple has full control over key distribution and virtually no one verifies Apple isn't acting as a MitM. Whatsapp and e2e encrypted messenger force you to handle securely linking multiple devices to your account and gives you the option to verify that Meta isn't providing bogus public keys to break the e2e encryption.

https://engineering.fb.com/2023/04/13/security/whatsapp-key-...

For iMessage, Apple can just add a fake iDevice to your account and now iMessage will happily encrypt everything to that new key as well and there's zero practical visibility to the user. If it was a targeted attack and not blanket surveillance then there's no way the target is going to notice. You can open up the keychain app and check for yourself but unless you regularly do this and compare the keys between all your Apple products you can't be sure. I don't even know how to do that on iPhone.

Perf Is Not Enough 2 years ago

I'm literally going from a house in Seattle to an office in SF right now. I left 48 minutes ago, I'll update when I arrive and I'll personally add a data point here lol.

Right, but the comment I was replying to was in response to this:

2 will tell you if they diverge, but you lose both if they do. 3 let's you retain 2 in operation if one does diverge.

If you care about resilience then you either need to settle with one and accept that you can't catch the class of errors that are persistent or go with three if you actually need resilience to those failures as well. If you don't need that kind of resilience like an aerospace application would need then you're probably better off with catching this at a higher layer in the overall distributed systems design. Rather than trying to make a resilient and perfectly accurate server, design your service to be resilient to hardware faults and stack checksums on checksums so you can catch errors (whether HW or software) where some invariant is violated. Meta also has a paper on their "Tectonic filesystem" where there's a checksum of every 4K chunk fragment, a checksum of the whole chunk, and a checksum of the erasure encoded block constructed out of the chunks. Once you add in yet another layer of replication above this then even when some machine is computing corrupt checksums or inconsistent checksums where the checksum and the data are corrupt then you can still catch it and you have a separate copy to avoid data loss.

A seasoned kernel developer

I think you should take another look at the author list. Chris Mason counts as a seasoned kernel developer in my book. Either way I think you're missing the point. Yes gcj would be different, but there's a decent chance it could hand you a binary that reproduces the issue that you can bisect to the root cause from there. It's one thing to run it through gcj and see if it reproduces, rewriting it in C is a ton of work compared to gcj for something that might not pan out.

wouldn't that classify as broken hardware requiring device change?

Yes but you need to catch it first to know what to take out of production.

That might be difficult if CPU is broken. How are you sure you actually computed 3 times if you can't trust the logic.

That's kind of my point. Either it's a heisen-bug and you never see those results again when you repeat the original program or it's permanently broken and you need to swap out the sketchy CPU. If you only care about the first case then you only need one core. If you care about the second case then you need 3 if you want to come up with an accurate result instead of just determining that one of them is faulty. It's like that old adage about clocks on ships. Either take one clock or take three, never two.

Disclaimer: I work at Meta and I know a couple of the authors of the paper but my work is completely unrelated to the subject of the paper.

That's not a technical error, they mean SRAM in the CPU itself. You're right about gcj but that's kind of a moot point when investigating some reproducible CPU bug like this. The paper mentions all the acrobatics they went through when trying to find the root cause but if gcj would have been practical then it also would have been immediately clear if the gcj output reproduced the error or not. If it didn't reproduce, no big deal, try another approach. You might be right about it being easier to root cause with gdb directly but I'm not so sure. Starting out, you have no idea which instructions under what state are triggering the issue so you'd be looking for a needle in a haystack. A crashdump or gdb doesn't let you bisect that haystack so good luck finding your needle.

But if it's a consistent fault, like the silent data corruption covered in the linked paper, redoing the computation is still going to end up with no way to identify which core is faulty. If it's an intermittent fault, then even for hard realtime you can accomplish that with one core, just compute 3x and go with majority result.

Actually it's not uncommon for there to be ECC used within components as a method to guard against stuff like this. I don't think it's practical to ever have complete coverage without going full blown dual/triple redundant CPU but for stuff like SSD controllers they have ECC coverage internally on the data path.

It's reasonable for displaying with nothing more than knowing the email on haveibeenpwned.com but for everyone subscribed to notifications it would have been very helpful to include the source in the notification email and that would have avoided the biggest part of the privacy implications. Right now for a lot of people the latest breach notification email is unactionable because there's no way to figure out what account may have been breached. For me personally I received the notification but when I checked the actual list directly, not only was it immediately clear that it wasn't an account I care about, it was also a password that I've used but never with the account listed. Had the email from HIBP included just a tiny bit of additional information I wouldn't have needed to waste my time on it, especially when it seems that this breach has some unknown amount of bogus data in it.

Backblaze B2 is their generic object storage platform similar to S3. You pay what you use and it scales into petabytes. There's no minimums so if you're only using small amounts, you get a small bill at the end of the month. It's not backup software, just the underlying cloud storage platform.

I think the charitable explanation here is that this was an undocumented debugging interface. Apple knew about it and did not disclose it in any publicly available material. The NSA almost certainly has access to Apple's source code and documentation. Just look at the Snowden leaks when it was disclosed that the NSA was mitming Google's DC to DC links. They already knew Google wasn't encrypting those links before they surreptitiously dug up the fiber and they already knew enough about the system architecture to make sense of that firehose of data. Clearly either through NSL or bribing some insiders, they already exfiltrated a bunch of internal documentation and source code. Why would Apple be any different?

I wouldn't expect them to have HSM keys or anything but a mirror of their VCS? Yeah the NSA probably has that.

Would Nvidia the company want to engage in this? No. Would some middle manager involved in poaching this guy from the competitor want to do it? I have my suspicions. It takes two to tango and Nvidia didn't catch this themselves which raises some red flags. How was he hired? What kind of compensation was he able to negotiate? Was it well above the compensation Nvidia would ordinarily pay for an engineer of his level? How did he introduce the code into Nvidia's version control? Were there obvious red flags about the "development" pace that should have raised eyebrows during peer review?

I work at a big tech company and if I tried something similar, I'm pretty sure it would be caught internally. Even if I managed to pull it off, all it could realistically give me is a foot in the door. Some sketchy hiring manager isn't going to be able to just sweep some $500,000 signing bonus under the rug and $100k isn't unheard of for regular engineers here anyways. As far as compensation and promotion opportunities afterwards it stands little chance of mattering for that either. For the first few months nothing I did was even used performance reviews and it's a peer driven process to rate/promote engineers.

Combined that means that even if I wanted to do this, and I found a corrupt hiring manager that wanted to play ball, I'd have to sit on that IP for a few months after being hired, slowly introduce it into the codebase, alter it in response to peer review and to fit the new code base's coding styles, etc. In the end, that would prove useful for a grand total of one peer review cycle and then it's sink or swim on my own merits from that point forward.

All that to say, yes Nvidia doesn't want this kind of thing as a company, but there are still individuals who potentially stand to benefit and there's a lot of opportunities for Nvidia to catch this before it's accidentally shown on screen to the competitor it was stolen from this far down the line. I don't know much about Nvidia's corporate structure but it kinda seems like they're trying to avoid finding out about it rather than trying to actually prevent it.