Hacker News: xxs

New comment by xxs in "Lean proved this program correct; then I found a bug"

xxs — Tue, 14 Apr 2026 14:06:48 +0000

Generally if I see 'this' to refer to some unknown part in any title, I'd consider it low quality.

New comment by xxs in "Škoda DuoBell: A bicycle bell that penetrates noise-cancelling headphones"

xxs — Thu, 09 Apr 2026 07:14:17 +0000

trucks? Or they still considered cars?

New comment by xxs in "Škoda DuoBell: A bicycle bell that penetrates noise-cancelling headphones"

xxs — Wed, 08 Apr 2026 09:55:34 +0000

which part would you consider overengineered?

New comment by xxs in "Why Switzerland has 25 Gbit internet and America doesn't"

xxs — Mon, 06 Apr 2026 12:15:32 +0000

realistically the only part at half a gb/s I'd care is latency. Latency is a lot more important than the throughput.

New comment by xxs in "Good CTE, Bad CTE"

xxs — Tue, 31 Mar 2026 13:22:46 +0000

I read the article before the abbreviate definition inclusion as its very opening. I had never met the abbreviation before.

It'd be quite surprising the WITH statement in top a query to be the first feature to learn/use past basic SQL. Is it personal experience in some industry?

New comment by xxs in "When do we become adults, really?"

xxs — Sun, 29 Mar 2026 09:34:13 +0000

According to the article that's what 25% of people think.

New comment by xxs in "Gzip decompression in 250 lines of Rust"

xxs — Fri, 27 Mar 2026 15:53:08 +0000

That's java code, though... bit weird, esp. i % 8 (which is just i & 7). The compiler should be able to optimize it since 'i' is guaranteed to be non-negative, still awkward.

Java CRC32 nowadays uses intrinsics and avx128 for crc32.

New comment by xxs in "Gzip decompression in 250 lines of Rust"

xxs — Fri, 27 Mar 2026 15:51:17 +0000

Crc32 can be written in handful lines of code. Although it'd be better to use the vector instruction set - e.g. AVX when available.

New comment by xxs in "RX – a new random-access JSON alternative"

xxs — Thu, 19 Mar 2026 09:10:02 +0000

as parser: keep only indexes to the original file (input), dont copy strings or parse numbers at all (unless the strings fit in the index width, e.g. 32bit)

That would make parsing faster and there will be very little in terms on tree (json can't really contain full blow graphs) but it's rather complicated, and it will require hashing to allow navigation, though.

New comment by xxs in "RX – a new random-access JSON alternative"

xxs — Thu, 19 Mar 2026 09:08:18 +0000

what do you mean by little data, most communication protocols are not one off

New comment by xxs in "Java 26 is here"

xxs — Tue, 17 Mar 2026 19:22:56 +0000

That's a proper late 90s reference, props!

New comment by xxs in "Meta’s renewed commitment to jemalloc"

xxs — Tue, 17 Mar 2026 12:12:53 +0000

it's a reply to:

"To an outsider, that looks like the JVM heap just steadily growing, which is easy to mistake for a memory leak."

I cut the part that it's possible to make JVM return memory heap after compaction but usually it's not done, i.e. if something grew once, it's likely to do it again.

New comment by xxs in "Meta’s renewed commitment to jemalloc"

xxs — Tue, 17 Mar 2026 04:16:32 +0000

Overall if java hits the swap, it's a bad case. Windows is a like special beast when it comes to 'swapping', even if you don't truly needed it. On linux all (server) services run with swapoff.

New comment by xxs in "Meta’s renewed commitment to jemalloc"

xxs — Mon, 16 Mar 2026 20:47:28 +0000

Well, indeed - I thought that part was obvious reading it.

New comment by xxs in "Meta’s renewed commitment to jemalloc"

xxs — Mon, 16 Mar 2026 20:10:12 +0000

Java has a quite strict max heap setting, it's very uncommon to let it allocate up to 25% of the system memory (the default). It won't grow past that point, though.

Baring bugs/native leaks - Java has a very predictable memory allocation.

New comment by xxs in "Meta’s renewed commitment to jemalloc"

xxs — Mon, 16 Mar 2026 19:50:26 +0000

What do you mean - if Java returns memory to the OS? Which one - Java heap of the malloc/free by the JVM?

New comment by xxs in "Meta’s renewed commitment to jemalloc"

xxs — Mon, 16 Mar 2026 19:26:34 +0000

Refactor doesn't mean just artificial puff-up jobs, it's very likely internal changes and reorganization (hence 100s of hours).

There are not many engineers capable of working on memory allocators, so adding more burden by agentic stuff is unlikely to produce anything of value.

New comment by xxs in "Meta’s renewed commitment to jemalloc"

xxs — Mon, 16 Mar 2026 19:22:17 +0000

Few months back, some of the services switched to jemalloc for the Java VM. It took months (of memory dumps and tracing sys-calls) to blame the JVM, itself, for getting killed by the oom_killer.

Initially the idea was diagnostics, instead the the problem disappeared on its own.

New comment by xxs in "Bucketsquatting is finally dead"

xxs — Mon, 16 Mar 2026 11:40:28 +0000

Of course, any UUIDv4 would do it (or any random stuff in general). I suppose the idea was having a naming scheme, instead of sharing the paths explicitly (and having an internal mapping for them)

New comment by xxs in "Bucketsquatting is finally dead"

xxs — Fri, 13 Mar 2026 11:15:23 +0000

that doesn't help either. 'Salt' is public and usually different/unique per entry/name.

If you mean to use a "secret" prefix (i.e. pepper) then, that would generate effectively globally unique names each time (and unpredictable too) but you can't change the pepper and it's only a matter of time it'd leak.