blog: Remove inaccurate claim about rust and wasmpack that was based off a NixOS issue that turned out to be irrelevant

Author: kmeisthax

blog/_posts/2023-04-23-mozilla-extension-postmortem.markdown

@@ -34,7 +34,7 @@ For my own sanity, I only considered differences "up to ZIP isomorphism." The pa
 
 The first two problems were caused by various build system scripts relying on environment data that is only available during the nightly build process. Said scripts were changed to instead get that information from a version seal file, if available. The nightly build process would also generate special source ZIPs with this version seal present. A [few](https://github.com/ruffle-rs/ruffle/pull/9244) [rounds](https://github.com/ruffle-rs/ruffle/pull/9344) [of](https://github.com/ruffle-rs/ruffle/pull/9353) [back and](https://github.com/ruffle-rs/ruffle/pull/9570) [forth](https://github.com/ruffle-rs/ruffle/pull/9633) with GitHub Actions and this reproducibility hole was filled.
 
-The WASM files would be more complicated. Strictly speaking, nothing in rustc, wasm-pack, or Webpack is intended to be reproducible. When building my laptop running Ubuntu, I would only get the four bytes difference in WASM if I built with my clock set ahead by several days. It was two entries in a dispatch table that has been reordered, and this table only existed in *one* of the two WASM files. We'd recently added a "dual-WASM" mode that enabled better optimizations for newer browsers. Discussions in maintainer chat considered either disabling dual-WASM (divinity76 was busy [adding it to the Dockerfile](https://github.com/ruffle-rs/ruffle/pull/9121#issuecomment-1396261394)) or writing some complicated "WASM sorter" to ensure the table was ordered correctly.
+The WASM files would be more complicated. When building my laptop running Ubuntu, I would only get the four bytes difference in WASM if I built with my clock set ahead by several days. It was two entries in a dispatch table that has been reordered, and this table only existed in *one* of the two WASM files. We'd recently added a "dual-WASM" mode that enabled better optimizations for newer browsers. Discussions in maintainer chat considered either disabling dual-WASM (divinity76 was busy [adding it to the Dockerfile](https://github.com/ruffle-rs/ruffle/pull/9121#issuecomment-1396261394)) or writing some complicated "WASM sorter" to ensure the table was ordered correctly.
 
 It turned out that this difference was a fluke. Another test build done on February 2nd was identical across multiple runs. I submitted 0.1.0.742 the next day.