pdw

Kim is also a shortened form of Joachim.

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.

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

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.

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.

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

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.

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.)

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

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

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.

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 :(

"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.