Hacker News Reader

Comment by kitsunesoba | Hacker News Reader

As a dev myself, I agree. You can’t really expect to just toss a binary over the wall and forget about the project for the next decade.

Software is an ongoing commitment and periodic recompiles and fixes should factor into architecture and planning. Some decisions early on can save you a lot of pain. For instance, building your app with stock UI widgets to the greatest extent possible and limiting custom widgets and third party stuff to a minimum goes a LONG way for making your apps weather new OS versions better. These days my UIKit apps only need a handful of minor changes when a new OS version is released, making them trivial to maintain.

Choosing Unity was a big part of the problem in this case because Unity is terrible about maintaining particular versions of their engines over time. Devs need to start dumping Unity over this, because it’s the only way that Unity is ever going to fix it.

View on HN

> You can’t really expect to just toss a binary over the wall and forget about the project for the next decade.

You can on Windows. Microsoft has shown us what a three decades of maintaining an OS to that standard will do to a platform and its software ecosystem. There are definitely pros and cons to taking that approach. These days, as a user I'd much rather have decent emulators of older platforms and operating systems, rather than rely on the current OS to be completely and forever backwards compatible. But that doesn't seem like a good solution for mobile platforms or their app stores.

Windows really is the exception and not the rule, though. In fact in the free and open world of Linux, backwards compatibility is even worse… a binary compiled a year ago has a good chance of no longer working. Stuff like Flatpak is improving that situation a bit, but it’s still nowhere as backwards compatible as Windows.

An amazing sentiment calling the operating system used the most across the entire world an exception rather than it being a standard. And I don't know how you envoke the problem (yes problem) of broken dependencies on linux and think it adds to your argument on why this is a good move by Apple.

Windows may be the most commonly used OS, but nevertheless it is just one OS among many and the others have worse backwards compatibility… most considerably so.

Linux has excellent backwards compatibility if you bundle your dependencies the same way you do on Windows. Most low-level interfaces - the kernel, libc, X, GL - pay close attention to backwards compatibility.

> In fact in the free and open world of Linux, backwards compatibility is even worse…

I have linux binaries from 2001 that still work fine on recent Linux kernels.

If they're CLI C ones, or statically link all deps: sure....

If they link against libstdc++, Qt or Python, good luck...

Games usually bundle or statically link their dependencies (just like most software on Windows).

Those three you listed have definitely been the most problematic by far when trying to run things on Linux.

It is actually the oposite on Linux. You compile on older distro (e.g. CentOS 6), and it will work on later versions, (CentOS 7).

https://developers.redhat.com/blog/2019/08/01/how-the-gnu-c-...

And Windows also shows you what happens when you have layers upon layers of compatibility hacks and the security nightmares it brings. One of the first major IIS security issues happened because of the eight different string types and conversions between them to work with the various APIs.

You could “hack” a Windows server running IIS just by encoding DOS commands in the URL bar.

http://cd.textfiles.com/hmatrix/Tutorials/hTut_0239.htm

Also, by Apple eventually abandoning backwards compatibility, it was able to migrate Macs to different better processors four times.

By abandoning 32 bit software support, it was able to save space on its processors.

> Also, by Apple eventually abandoning backwards compatibility, it was able to migrate Macs to different better processors four times.

68k -> PPC actually did not break backwards compatibility at all. They realized it they had to make it good for the transition to work, so they built emulation right into the OS. A well-behaved app made for a 1984 Mac will run unmodified on the last version of old Mac OS, and on Mac OS X up to 10.4 under the Classic environment, that's over 20 years of compatibility. Apple could have maintained this level of compatibility until today, but they choose not to.

This is definitely not true. The 68K emulator didn’t support any 68K apps that required a floating point unit, apps that were not “32 bit clean”, or apps that used self modifying code. Even the introduction of the MultiFinder broke many old 68K apps.

Apple couldn’t maintain 32 bit app support with newer processors without wasting die space.

Gesturing towards an IIS bug discovered twenty years ago does not bolster your argument.

The 20 year old bug was caused by Microsoft not testing compatibility hacks and old deprecated code from 25+ years ago.

According to Raymond Chen (author of “The Old New Thing”) there was literally code scattered all through Windows of the affect:

   if app == “SimCity 2000” then doCompatibilityHack()

> You can’t really expect to just toss a binary over the wall and forget about the project for the next decade.

Auugghh! This is the wrongest thing I’ve read on HN since 2021 COVID threads. Sorry you get the distinction!

Software absolutely should keep working as it did the first day it was released. The binary is the same, no cosmic rays have flipped any bits, so why should it stop executing exactly the same, but for a deliberate choice made by the platform to break backwards compatibility?

This idea that software should have to get recompiled over and over with the latest SDK simply to keep doing the same thing is maybe the worst idea ever thought of in software: and Apple leads the charge.

Software doesn’t work in isolation. It’s like you’d expect to take a tape with binary recorded on it and then expect it to use it on Mars.

And Apple ecosystem is rapidly changing. OSes are changing every year. Phones get reiterated every year. 2 years of no updates mean 2 cycles behind. And Apple is very good with pushing updates on the users.

And to be technically correct - both software on the tape brought to Mars and removed games will work in the same hardware and running context exactly the same. But for Mars context made it not runnable anymore and for Apple we’re talking about taking it down from storefront (but all existing customers can still get it).

I’d recommend checking Emacs - Elisp is very stable and some code is working well for decades and yet with all the carefulness of the developers some thing breaks due to API changes.

Can people with older phones still buy a new copy of it though?

Much of the time decisions to break backwards compatibility are made to remove roadblocks in the OS development process. Keeping old software for the platform running forever has a high cost, and so I think that OS vendors wanting to limit how far back that compatibility goes is entirely reasonable.

If the argument is that OS vendors should include virtualized old OS environments for compatibility with old binaries to make sure OS development remains unencumbered, I could get behind that, but in that situation App Store listings of seldom updated apps should include a highly visible indicator that it’s been many years since the last update and as such expectations of significant bug fixes and support should be tempered.

I've quoted you in the past [0] and usually align with your takes. Consider attending our conference sometime :)

[0] https://media.handmade-seattle.com/self-hosted-conference/

This is simply false. Some software is an ongoing commitment. Other software can just be done and never need to be updated. An indie game with no online component falls squarely in the latter bucket.

I build my software to last.

Almost no one else seems to care, but I am too stubborn and lazy to do it any other way.

Worth noting that Unity now has a system of maintaining LTS versions of each of their major yearly releases. They’re doing a LOT of stuff wrong these days but at least they’ve improved on that front.

Reply on news.ycombinator.com