pdw

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.

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

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.

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

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

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

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.

The signedness of `char` is implementation-defined, it is signed on x86 but unsigned on ARM. So assigning a plain char to a wider integer type is suspicious, did the programmer expect sign-extension or zero-extension?

The Nintendo GameCube and Wii also had IBM CPUs.

I wouldn't assume ABCL runs on Android. It's not listed as a supported runtime on their website.

A lot of game devs of that era sadly treated the Adlib/SoundBlaster OPL2 chip as nothing more than a very poor MIDI synth, but it was capable of much better. For example, listen to some of Stéphane Picq's music. https://vgmrips.net/packs/composer/stephane-picq

In those days malloc would use sbrk to allocate memory. And yes, mmap was designed to memory map files. Using it to allocate anonymous pages came later.

Are they in widespread use? They were deprecated in 1995.

I always wondered how secure AS/400 actually is. The original implementation might have checked tag bits in hardware (I don't know), but the current (PowerPC) implementation relies on the compiler generating a "check tag bits" every time a pointer is dereferenced [1]. So it seems that any arbitrary code execution vulnerability would be absolutely devastating. And the "SLIC" is not a small microkernel -- it also contains the compilers, the database and other system components. It'd be hard to believe there would no exploitable bugs in there.

[1] https://www.devever.net/~hl/ppcas

Debian woody (2002) shipped gnustep. I tried it back then, but as far as I remember, it was weird enough that anybody who didn't have NEXTSTEP experience would bounce right off. The floating menus, the weird scrollbars, etc. There were also no non-trivial applications that I can remember.

People back then were looking for something that would be familiar to Windows/Mac users. GNUStep (at least at the time) was not interested in being that.

Security researchers rarely fix bugs. They don't see it as their job, and it requires a very different skill set than finding or exploiting them anyway.

From that article:

> While similar, it is not the widely reported Asrock motherboard problem, as the motherboards we use are of a different make

The Windows 2000 launch is closer to the release of Altair 8800 than it is to today :/

Right, people forget that the xz-utils backdoor happened to a very traditional no-dependencies C project.