OT, but I sure wish papers like this included a publish date. This paper references a 2015 paper by Taylor Campbell, and mentions at least NetBSD 8, from which a date can be derived, but it’s annoying to not know the time of development this is addressing. Otherwise, it’s compelling - Joerg often tackles interesting problems in NetBSD.
I guess that’s another clue but I’m my address bar that’s buried away, and if I printed this out, could be permanently lost. Thanks for for hint though - now it’s a less frustrating read :)
That's fine if you find it at the 'original' URL, but if you find it in some random place somewhere else there's no internal information on the timeframe.
Apple has created a number of Mac compatibility layers (68K emulation, Classic, Carbon, PPC Emulation in Rosetta 1, x86 static translation in Rosetta 2) and the only one that is still around is Rosetta 2.
32-bit apps were also broken without any compatibility layer support.
The only practical way you can run Mac programs that depended on those discontinued features and compatibility layers is on an older OS: either on old hardware, on an emulator, or in a VM.
On iOS Apple hasn't really bothered with backward compatibility and is happy to break your apps every year and to offload a yearly maintenance burden onto developers. This is unfortunate because backward compatibility would have multiplicative benefit for thousands of apps and billions of iPhone users.
I apologize if “if you don’t pay NetBSD developers compatibility is cheap(er)” isn’t what you meant; perhaps I misinterpreted.
NetBSD development is not cheap - it’s accomplishments are hard fought design and implementation wins largely performed by talented volunteers. To me “cheap” in this context implies a certain ease, which I don’t think is a fair characterization of what happens with the project.
Then again, maybe I’m just being hypersensitive about respect for the project.
