Notes on finishing my first large Rust project, a FUSE server implementation. Overall I quite like Rust the language, have mixed feelings about the quality of ancillary tooling, and have strong objections to some decisions made by the packaging system (Cargo + crates.io).
You've heard the euphemism tech debt, where like a car loan you hold a recurring obligation in exchange for immediate liquidity. But this is misleading: bad code is not merely overhead, it also reduces optionality for all teams that come in contact with it. Imagine being unable to get indoor plumbing because your neighbor has a mortgage!
Thus a better analogy for bad code is a haunted forest. Bad code negatively affects everything around it, so engineers will write ad-hoc scripts and shims to protect themselves from direct contact with the bad code. After the authors move to other projects, their hard work will join the forest.
I collect music by buying physical CDs, digitizing them with Exact Audio Copy, and scanning the artwork. This is sometimes challenging if the CD was self-published in a limited run in a foreign country ten years ago. It is very challenging if the CDs have an innate defect that renders some tracks unreadable.
“Plumbing the depths of obsession” – Jeff Atwood
Also see the follow-up post Error Beneath the WAVs for more investigation about what exactly is wrong with my discs, and info about which CD drives are capable of reading them.
This is a follow-up to Why I Ripped The Same CD 300 Times. By the end of that page I'd identified a fragment of audio data that could cause read errors even if it was isolated and burned to a fresh CD. This page explores how specific bit patterns named weak sectors can create corrupt physical media by tickling bad encoding logic in a CD burner.
I also explore dusty archives of the early 2000s game piracy scene, which was very concerned about mitigating weak sectors used as copy protection. With the power of a “two-sheep” LTR-40125S drive, I successfully ripped the original discs with bit-exact audio data and a matching AccurateRip report.
On UNIX-like operating systems, userland processes invoke kernel procedures using syscalls. Each syscall is identified by a unique number and has a short list of parameters, which both can vary betwen operating systems, hardware platforms, and configuration options.
Performing a syscall is usually done via a special assembly instruction, though some platforms use other mechanisms (e.g. a vDSO). This page is a catalog of how to invoke syscalls on different UNIX-like platforms.