How to break long-term compatibility in NetBSD [pdf] (2016) | Hacker News Reader

How to break long-term compatibility in NetBSD [pdf] (2016)

netbsd.org

24 pointsingve12 comments

It's from 2016, but still an interesting read. Is anyone still using NIS in 2022 though? I haven't considered using it in over a decade.

I did consider it a few times to auth my system users against LDAP, but never really got around to doing it. Details here (1)

(1) https://www.openbsd.org/faq/faq10.html#Dir

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.

You're absolutely right, but the URL should be a hint: AsiaBSDCon 2016 ;)

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.

Then it is missing 2016 in the title.

Isn’t this something that Windows and MacOS have done repeatedly, and managed via compatibility layers?

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.

Compatibility layers are cheaper if you are a company with thousands of programmers.

Compatibility layers (or any development activities) are cheaper (for you) if you don't pay your developers.

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.

Reply on news.ycombinator.com