Hacker News: pdw

New comment by pdw in "sshole"

pdw — Fri, 06 Nov 2026 00:11:56 +0000

But it fits the common Linux implementation of the function... e.g. the Debian manpage says:

> Upon error, crypt_r, crypt_rn, and crypt_ra write an invalid hash to the _output_ field of their _data_ argument, and crypt writes an invalid hash to its static storage area. This string will be shorter than 13 characters, will begin with a ‘*’, and will not compare equal to _setting_.

New comment by pdw in "OpenSSH 10.6p2 has been released with a workaround for a critical vulnerability"

pdw — Fri, 06 Nov 2026 00:01:46 +0000

To the best of my knowledge, only OpenBSD and Fedora have a crypt(3) that returns NULL. Everybody else returns a string starting with "*" on error.

For example on Debian the manpage says:

> Upon error, crypt_r, crypt_rn, and crypt_ra write an _invalid_ hash to the output field of their _data_ argument, and crypt writes an invalid hash to its static storage area. This string will be shorter than 13 characters, will begin with a ‘*’, and will not compare equal to _setting_.

New comment by pdw in "US boy names that became girl names and vice versa"

pdw — Mon, 02 Nov 2026 21:56:50 +0000

Kim is also a shortened form of Joachim.

New comment by pdw in "StackOverflow now gets fewer than 1000 questions a month"

pdw — Thu, 29 Oct 2026 07:50:09 +0000

In my experience, any questions about an obscure or rare problem was likely to be marked as a duplicate if it sounded even vaguely similar to a common problem. My impression was that some moderators just were unwilling to admit they didn't know the answer to a question.

New comment by pdw in "Rabbits were a medieval royal luxury in England until the Black Death"

pdw — Mon, 19 Oct 2026 07:48:26 +0000

Right, commoners would initially only have known them as exotic burrowing hares.

New comment by pdw in "Apple/macOS removed from official Unix registry"

pdw — Sat, 10 Oct 2026 22:55:29 +0000

It's neither, really. OS X takes its command line utilities from BSD world, while Linux's mostly come from GNU. They're independent implementations, and GNU utilities are as a rule much more featureful than their BSD equivalents. Or much more bloated, depending on your point of view.

Both aim to conform to the POSIX, but POSIX is a very spartan spec, people routinely use non-POSIX features without realizing it.

New comment by pdw in "Apple/macOS removed from official Unix registry"

pdw — Sat, 10 Oct 2026 15:48:32 +0000

If you'd try to certify any modern Linux distribution, you'd end up with a very similar list.

- The Linux kernel also has timer coalescing

- Linux also has lazy atime ('relatime') by default

- No Linux distro installs uucp by default, and certainly not suid

- Desktop distros will also run a file indexer of some sort

etc.

New comment by pdw in "The scourge of x86 emulation"

pdw — Fri, 18 Sep 2026 08:57:57 +0000

The intro of this article repeats the common assertion that

> ARM is the most relaxed, allowing significant hardware optimizations; and x86 is the most strict, enforcing a very strong coherency model that doesn’t allow a lot of room for optimization

but I've seen some compelling arguments that a relaxed model doesn't necessarily have much of a benefit, https://fgiesen.wordpress.com/2026/08/25/memory-ordering-in-...

New comment by pdw in "Spaghettifying DRAM"

pdw — Thu, 13 Aug 2026 20:30:03 +0000

It's baffling but I'm starting to believe that some people genuinely cannot tell. It's like nails on chalkboard to me.

New comment by pdw in "To save C, we must save ABI (2022)"

pdw — Tue, 11 Aug 2026 10:15:48 +0000

Because it imagines that no library other than libc has an ABI that depends on intmax_t.

Suppose I have a libfoo that has a public function that takes an intmax_t parameter. Or that has a public struct with an intmax_t field. It will be compiled for a particular definition of intmax_t. If you try to link it with a program that uses a different definition, it will fail.

The article's solution with the "MY_LIBC_NEW_CODE" define cannot work because no existing C code knows about "MY_LIBC_NEW_CODE".

The proposed mechanism is somewhat useful to a library that wants to provide multiple incompatible implementations of a function. (But this is mostly only interesting for libc implementations that need to handle historic incompatibilities between all the various Unix specs. Other libraries can just give their new, incompatible function a new name.) It's useless if you want to make an incompatible change to a type definition.

New comment by pdw in "Copy That Floppy – Cambridge guide for preserving data from fragile floppy disks"

pdw — Wed, 08 Jul 2026 09:03:09 +0000

Floppy reliability dropped of a cliff in the mid-90s. It came to a point where it wasn't unusual to see I/O errors even on completely new floppies.

But with older drives and older media, produced to a higher standard, they were pretty reliable. (After all, IBM invented them to store CPU microcode, they had to be.)

New comment by pdw in "Sagrada Família Lego set"

pdw — Thu, 04 Jun 2026 17:47:53 +0000

I'm sad that the building instructions link doesn't work. I'd love to see them.

New comment by pdw in "The Visible Zorker: Zork 1"

pdw — Sun, 26 Apr 2026 21:14:26 +0000

Nothing to do with the VM. The game was designed that way, navigation is part of the puzzle.

New comment by pdw in "A word processor from 1990s for Atari ST/TOS is still supported by enthusiasts"

pdw — Thu, 19 Feb 2026 09:20:57 +0000

I think that's out of date. The banner at the top of the page says "you can request a free license for version 5.4 from us." According to archive.org that was added later than the text you quoted, somewhere between 2022 and 2024.

New comment by pdw in "Windows NT/OS2 Design Workbook"

pdw — Sun, 15 Feb 2026 19:46:46 +0000

In the early 90s Microsoft distributed the full Win32 API documentation as a WinHelp file. It felt very much as hyperlinked man-pages. Super fast too, even on machines of the time. WIN32.HLP can still be easily found, but modern Windows versions no longer ship WinHelp :(

New comment by pdw in "Let's compile Quake like it's 1997"

pdw — Mon, 09 Feb 2026 00:06:29 +0000

"Shipping" wouldn't be a problem, they could just run it from a network drive. Their PCs were networked, they needed to test deathmatches after all ;)

And the compilation speed difference wouldn't be small. The HP workstations they were using were "entry level" systems with (at max spec) a 100MHz CPU. Their Alpha server had four CPUs running at probably 275MHz. I know which system I would choose for compiles.

New comment by pdw in "1 kilobyte is precisely 1000 bytes?"

pdw — Tue, 03 Feb 2026 18:29:03 +0000

Even then it was not universal. For example, that Apple I ad that got posted a few days ago mentioned that "the system is expandable to 65K". https://upload.wikimedia.org/wikipedia/commons/4/48/Apple_1_...

New comment by pdw in "1 kilobyte is precisely 1000 bytes?"

pdw — Tue, 03 Feb 2026 18:17:33 +0000

Even in computing the binary definition is only used with memory sizes. E.g. storage, network speeds, clock rates use the standard definition.

New comment by pdw in "Recreating the lost SDK for a 42-year-old operating system: VisiCorp Visi On"

pdw — Sun, 07 Dec 2025 10:21:10 +0000

All of Microsoft's applications used to do that! The 16-bit versions of Word, Excel, PowerPoint, etc all were implemented using bytecode. That technology was only integrated in Microsoft C and made public in 1992 [1], before that the Microsoft applications group used their own private C toolchain. A copy of it can be found in the Word 1.1 source release [2] ("csl").

[1] https://sandsprite.com/vb-reversing/files/Microsoft%20P-Code... [2] https://github.com/danielcosta/MSWORD

New comment by pdw in "A time-travelling door bug in Half Life 2"

pdw — Sun, 23 Nov 2025 23:06:37 +0000

Rosetta uses software emulation for x87 floating point. That's slow, but in practice that doesn't matter much. Mac software never had a reason to use x87 FP, every Intel Mac had at least SSE3 support.