Hacker News: jmillikin

New comment by jmillikin in "Meta reuses old RAM in new servers with custom bridge chip"

jmillikin — Thu, 09 Jul 2026 14:25:23 +0000

That's the idea behind Taalas (https://taalas.com), except as silicon rather than ROM. They run a demo at https://chatjimmy.ai/ which serves an old open weights model (Llama 3.1 8B) at something like 15,000 tokens per second.

Announcing Zstandard in Rust

jmillikin — Mon, 01 Jun 2026 13:10:56 +0000

Article URL: https://trifectatech.org/blog/announcing-zstandard-in-rust/

Comments URL: https://news.ycombinator.com/item?id=48356381

Points: 63

# Comments: 8

New comment by jmillikin in "A recent experience with ChatGPT 5.5 Pro"

jmillikin — Mon, 11 May 2026 10:15:36 +0000

  > The mathematician and the blog author are not the same person
  > (as you seem to understand). Nathanson (the mathematician) is
  > the one who is the expert verifier. He is the person who has
  > the higher value and won't be fired in some hypothetical.

The article's author is https://en.wikipedia.org/wiki/Timothy_Gowers

New comment by jmillikin in "Rewriting Every Syscall in a Linux Binary at Load Time"

jmillikin — Sat, 18 Apr 2026 07:31:01 +0000

This might be a very dumb question, but if the process is being run under KVM to catch `int 0x03` then couldn't you also use KVM to catch `syscall` and execute the original binary as-is? I don't understand what value the instruction rewriting is providing here.

New comment by jmillikin in "Lemonade by AMD: a fast and open source local LLM server using GPU and NPU"

jmillikin — Thu, 02 Apr 2026 12:42:38 +0000

Surprising that the Linux setup instructions for the server component don't include Docker/Podman as an option, its Snap/PPA for Ubuntu and RPM for Fedora.

Maybe the assumption is that container-oriented users can build their own if given native packages?

New comment by jmillikin in "Libbbf: Bound Book Format, A high-performance container for comics and manga"

jmillikin — Wed, 21 Jan 2026 14:14:19 +0000

It doesn't matter, though. xxhash is better than crc32 for hashing keys in a hash table, but both of them are inappropriate for file checksums -- especially as part of a data archival/durability strategy.

It's not obvious to me that per-page checksums in an archive format for comic books are useful at all, but if you really wanted them for some reason then crc32 (fast, common, should detect bad RAM or a decoder bug) or sha256 (slower, common, should detect any change to the bitstream) seem like reasonable choices and xxhash/xxh3 seems like LARPing.

New comment by jmillikin in "Libbbf: Bound Book Format, A high-performance container for comics and manga"

jmillikin — Wed, 21 Jan 2026 13:42:50 +0000

  > It seems that JPEG can be decoded on the GPU [1] [2]

Sure, but you wouldn't want to. Many algorithms can be executed on a GPU via CUDA/ROCm, but the use cases for on-GPU JPEG/PNG decoding (mostly AI model training? maybe some sort of giant megapixel texture?) are unrelated to anything you'd use CBZ for.

For a comic book the performance-sensitive part is loading the current and adjoining pages, which can be done fast enough to appear instant on the CPU. If the program does bulk loading then it's for thumbnail generation which would also be on the CPU.

Loading compressed comic pages directly to the GPU would be if you needed to ... I dunno, have some sort of VR library browser? It's difficult to think of a use case.

  > According to smhasher tests [3] CRC32 is not limited by memory bandwidth.
  > Even if we multiply CRC32 scores x4 (to estimate 512 bit wide SIMD from 128
  > bit wide results), we still don't get close to memory bandwidth.

Your link shows CRC32 at 7963.20 MiB/s (~7.77 GiB/s) which indicates it's either very old or isn't measuring pure CRC32 throughput (I see stuff about the C++ STL in the logs).

Look at https://github.com/corsix/fast-crc32 for example, which measures 85 GB/s (GB, GiB, eh close enough) on the Apple M1. That's fast enough that I'm comfortable calling it limited by memory bandwidth on real-world systems. Obviously if you solder a Raspberry Pi to some GDDR then the ratio differs.

  > The 32 bit hash of CRC32 is too low for file checksums. xxhash is definitely
  > an improvement over CRC32.

You don't want to use xxhash (or crc32, or cityhash, ...) for checksums of archived files, that's not what they're designed for. Use them as the key function for hash tables. That's why their output is 32- or 64-bits, they're designed to fit into a machine integer.

File checksums don't have the same size limit so it's fine to use 256- or 512-bit checksum algorithms, which means you're not limited to xxhash.

  > Why would you need to use a cryptographic hash function to check integrity
  > of archived files? Quality a non-cryptographic hash function will detect
  > corruptions due to things like bit-rot, bad RAM, etc. just the same.

I have personally seen bitrot and network transmission errors that were not caught by xxhash-type hash functions, but were caught by higher-level checksums. The performance properties of hash functions used for hash table keys make those same functions less appropriate for archival.

  > And why is 256 bits needed here? Kopia developers, for example, think 128
  > bit hashes are big enough for backup archives [4].

The checksum algorithm doesn't need to be cryptographically strong, but if you're using software written in the past decade then SHA256 is supported everywhere by everything so might as well use it by default unless there's a compelling reason not to.

For archival you only need to compute the checksums on file transfer and/or periodic archive scrubbing, so the overhead of SHA256 vs SHA1/MD5 doesn't really matter.

I don't know what kopia is, but according to your link it looks like their wire protocol involves each client downloading a complete index of the repository content, including a CAS identifier for every file. The semantics would be something like Git? Their list of supported algorithms looks reasonable (blake, sha2, sha3) so I wouldn't have the same concerns as I would if they were using xxhash or cityhash.

New comment by jmillikin in "Libbbf: Bound Book Format, A high-performance container for comics and manga"

jmillikin — Wed, 21 Jan 2026 08:24:31 +0000

I use CBZ to archive both physical and digital comic books so I was interested in the idea of an improved container format, but the claimed improvements here don't make sense.

---

For example they make a big deal about each archive entry being aligned to a 4 KiB boundary "allowing for DirectStorage transfers directly from disk to GPU memory", but the pages within a CBZ are going to be encoded (JPEG/PNG/etc) rather than just being bitmaps. They need to be decoded first, the GPU isn't going to let you create a texture directly from JPEG data.

Furthermore the README says "While folders allow memory mapping, individual images within them are rarely sector-aligned for optimized DirectStorage throughput" which ... what? If an image file needs to be sector-aligned (!?) then a BBF file would also need to be, else the 4 KiB alignment within the file doesn't work, so what is special about the format that causes the OS to place its files differently on disk?

Also in the official DirectStorage docs (https://github.com/microsoft/DirectStorage/blob/main/Docs/De...) it says this:

  > Don't worry about 4-KiB alignment restrictions
  > * Win32 has a restriction that asynchronous requests be aligned on a
  >   4-KiB boundary and be a multiple of 4-KiB in size.
  > * DirectStorage does not have a 4-KiB alignment or size restriction. This
  >   means you don't need to pad your data which just adds extra size to your
  >   package and internal buffers.

Where is the supposed 4 KiB alignment restriction even coming from?

There are zip-based formats that align files so they can be mmap'd as executable pages, but that's not what's happening here, and I've never heard of a JPEG/PNG/etc image decoder that requires aligned buffers for the input data.

Is the entire 4 KiB alignment requirement fictitious?

---

The README also talks about using xxhash instead of CRC32 for integrity checking (the OP calls it "verification"), claiming this is more performant for large collections, but this is insane:

  > ZIP/RAR use CRC32, which is aging, collision-prone, and significantly slower
  > to verify than XXH3 for large archival collections.  
  > [...]  
  > On multi-core systems, the verifier splits the asset table into chunks and
  > validates multiple pages simultaneously. This makes BBF verification up to
  > 10x faster than ZIP/RAR CRC checks.

CRC32 is limited by memory bandwidth if you're using a normal (i.e. SIMD) implementation. Assuming 100 GiB/s throughput, a typical comic book page (a few megabytes) will take like ... a millisecond? And there's no data dependency between file content checksums in the zip format, so for a CBZ you can run the CRC32 calculations in parallel for each page just like BBF says it does.

But that doesn't matter because to actually check the integrity of archived files you want to use something like sha256, not CRC32 or xxhash. Checksum each archive (not each page), store that checksum as a `.sha256` file (or whatever), and now you can (1) use normal tools to check that your archives are intact, and (2) record those checksums as metadata in the blob storage service you're using.

---

The Reddit thread has more comments from people who have noticed other sorts of discrepancies, and the author is having a really difficult time responding to them in a coherent way. The most charitable interpretation is that this whole project (supposed problems with CBZ, the readme, the code) is the output of an LLM.

New comment by jmillikin in "Chromium Has Merged JpegXL"

jmillikin — Tue, 13 Jan 2026 10:22:17 +0000

I'm not (only) talking about the general population, but major sites. As a quick sanity check, the following sites are serving images with the `image/jpeg` content type:

* CNN (cnn.com): News-related photos on their front page

* Reddit (www.reddit.com): User-provided images uploaded to their internal image hosting

* Amazon (amazon.com): Product categories on the front page (product images are in WebP)

I wouldn't expect to see a lot of WebP on personal homepages or old-style forums, but if bandwidth costs were a meaningful budget line item then I would expect to see ~100% adoption of WebP or AVIF for any image that gets recompressed by a publishing pipeline.

New comment by jmillikin in "Chromium Has Merged JpegXL"

jmillikin — Tue, 13 Jan 2026 09:12:47 +0000

Most of the code in WebP and AVIF is shared with VP8/AV1, which means if your browser supports contemporary video codecs then it also gets pretty good lossy image codecs for free. JPEG-XL is a separate codebase, so it's far more effort to implement and merely providing better compression might not be worth it absent other considerations. The continued widespread use of JPEG is evidence that many web publishers don't care that much about squeezing out a few bytes.

Also from a security perspective the reference implementation of JPEG-XL isn't great. It's over a hundred kLoC of C++, and given the public support for memory safety by both Google and Mozilla it would be extremely embarrassing if a security vulnerability in libjxl lead to a zero-click zero-day in either Chrome or Firefox.

The timing is probably a sign that Chrome considers the Rust implementation of JPEG-XL to be mature enough (or at least heading in that direction) to start kicking the tires.

First-class custom smart pointers

jmillikin — Thu, 13 Nov 2025 09:34:45 +0000

Article URL: https://nadrieril.github.io/blog/2025/11/11/truly-first-class-custom-smart-pointers.html

Comments URL: https://news.ycombinator.com/item?id=45912771

Points: 3

# Comments: 0

Progress update on Clang's new constant expression interpreter

jmillikin — Tue, 21 Oct 2025 11:20:41 +0000

Article URL: https://developers.redhat.com/articles/2025/10/15/clang-bytecode-interpreter-update

Comments URL: https://news.ycombinator.com/item?id=45654533

Points: 2

# Comments: 0

New comment by jmillikin in "Introduction to reverse-engineering vintage synth firmware"

jmillikin — Mon, 20 Oct 2025 06:27:51 +0000

The https://github.com/blackjetrock/ghidra-6303 repository your post links to (containing a SLEIGH spec for the HD6303) is no longer available, did you happen to save a local clone that could be re-uploaded somewhere?

Introduction to reverse-engineering vintage synth firmware

jmillikin — Mon, 20 Oct 2025 02:56:20 +0000

Article URL: https://ajxs.me/blog/Introduction_to_Reverse-Engineering_Vintage_Synth_Firmware.html

Comments URL: https://news.ycombinator.com/item?id=45639860

Points: 196

# Comments: 27

The biggest semantic mess in Futhark

jmillikin — Thu, 02 Oct 2025 00:38:38 +0000

Article URL: https://futhark-lang.org/blog/2025-09-26-the-biggest-semantic-mess.html

Comments URL: https://news.ycombinator.com/item?id=45445260

Points: 63

# Comments: 8

New comment by jmillikin in "Git: Introduce Rust and announce it will become mandatory in the build system"

jmillikin — Sat, 20 Sep 2025 13:50:02 +0000

There's at least one proprietary platform that supports Git built by via a vendor-provided C compiler, but for which no public documentation exists and therefore no LLVM support is possible.

Ctrl+F for "NonStop" in https://lwn.net/Articles/998115/

New comment by jmillikin in "JSON is not a YAML subset (2022)"

jmillikin — Fri, 01 Aug 2025 23:13:46 +0000

Among ecosystems based on YAML-formatted configuration defaulting to YAML 1.1 is nearly universal. The heyday of YAML was during the YAML 1.1 era, and those projects can't change their YAML parsers' default version to 1.2 without breaking extant config files.

By the time YAML 1.2 had been published and implementations written, greenfield projects were using either JSON5 (a true superset of JSON) or TOML.

  > While JSON numbers are grammatically simple, they're almost always distinct
  > from how you'd implement numbers in any language that has JSON parsers,
  > syntactically, exactness and precision-wise.

For statically-typed languages the range and precision is determined by the type of the destination value passed to the parser; it's straightforward to reject (or clamp) a JSON number `12345` being parsed into a `uint8_t`.

For dynamically-typed languages there's less emphasis on performance, so using an arbitrary-precision numeric type (Python's Decimal, Go's "math/big" types) provide lossless decoding.

The only language I know of that really struggles with JSON numbers is, ironically, JavaScript -- its BigInt type is relatively new and not well integrated with its JSON API[0], and it doesn't have an arbitrary-precision type.

[0] See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... for the incantation needed to encode a BigInt as a number.

Tracking source locations in the Futhark compiler

jmillikin — Thu, 31 Jul 2025 04:40:31 +0000

Article URL: https://futhark-lang.org/blog/2025-07-29-tracking-source-locations.html

Comments URL: https://news.ycombinator.com/item?id=44742359

Points: 43

# Comments: 0

Hacking Coroutines into C

jmillikin — Sun, 13 Jul 2025 01:12:37 +0000

Article URL: https://wiomoc.de/misc/posts/hacking_coroutines_into_c.html

Comments URL: https://news.ycombinator.com/item?id=44546640

Points: 160

# Comments: 42

Bin2Wrong: A fuzzer for uncovering semantic errors in binary-to-C decompilers [pdf]