Comment by kodah | Hacker News Reader

Comment by kodah | Hacker News Reader

Parent Full thread

> Heard about this ordeal on NPR a while back. It's crazy how dependent a community can become on a piece of software and at the same time no one takes measures on preservation or open sourcing that software.

I don't even think this necessarily has to do with open sourcing necessarily. This is a wider software conundrum as well. From the article:

> The first warning Shepard got was when she went to update her Mac, and the system warned her that TropeTrainer wouldn’t run on the newest OS

Operating System updates frequently break software. Operating System transitions break software a lot. This is a thorny issue, imo, because on the one hand when people buy software I doubt they're thinking about how it'll be useless if the Operating System's company (or community) think they can do better with new APIs and behavior. On the other hand, updates are part of moving something as vast as an OS forward, and at least some amount of the time they're necessary.

Windows provides some ways of running older software in a VM. I'd be curious if they've tried such a thing with this software. MacOS I'm not so sure of, since even the ISOs are somewhat controlled.

Open source means that anyone sufficiently able and sufficiently motivated can keep up with these changes. In that humans have to be touching code to keep up with api / abi changes, not letting humans touch code is the actual problem in this case. The human that did died, and the humans left kept it closed source.

That looks a lot like a claim that software only deserves to exist if it is made by, or attracts the fanatical devotion of, people who have a deep love of maintaining software against a moving target.

Ugh.

The expectation that once you've made something you can't expect it to keep working without endless catchup, attitudes like this one, are why I have completely given up making software for fun or to solve noncommercial problems for myself and others.

I'm not the only one.

> The expectation that once you've made something you can't expect it to keep working

I don't think there is a single type of item in the world for which you could expect it to keep existing indefinitely without maintenance. Machines rust, wood degrades, paintings need restoring every few centuries. And even when properly stored in controlled atmosphere etc, books from a few centuries ago are almost unreadable because the language has changed so much since then (see https://web.cn.edu/kwheeler/diagram_4english.html for example).

Everything in this world needs constant maintenance or it breaks down. Why would you expect software to be any different?

This is a wholly false analogy. If I store most things properly they decay only very slowly and most maintenance tasks are easy. The software equivalent of that is only making sure I don't lose something to bit rot. No software lasts long enough for that, I look away for a year or so and someone broke something it stands on. It's not analogous to keeping an old book in a safe, it's analogous to keeping an old book in the street while random strangers queue up to piss on it.

I have books up to 500 years old that are perfectly readable. I have programs I wrote single digit years ago that I'd need to give up a couple of days just to find out if I can get their build chain back and dig them out of dependency hell. Not worth it to buy, at best, a few years before I get to repeat the experience. Restoring and rebuilding old physical things is also far more rewarding because when I do it properly I never have to do it again.

You seem to be cherrypicking the heirloom quality physical items and comparing them to programs that were constructed with not nearly as much care.

I've owned physical objects that were worthless a few months (cheap throwaway), and have also worked on code that was over 5 decades old and still compiled just fine. If you construct the software with care it is entirely feasible to have something that you can run several decades from now, but that does mean that you shouldn't use dependencies which might disappear in that time. Curl or sqlite are probably fine, a dependency with a single maintainer is probably not fine. Network dependencies on DNS or NTP are probably fine, depending on the API of some 1-year old startup is almost certainly not fine.

I expect it to be different because it is different.

Machines rusting and painting needing restoration is because they oxidize. Wood does not magically degrade, it decomposes. These are physical phenomena confined to the physical world.

Your example of the book being unreadable because people's language changed, that is a closer example but even that falls short because language is a human to human communication pathway. We have to spend literal years training people to understand it, it is inherently chaotic and messy.

Software is math, it is engineered. We don't wake up to find that suddenly the coefficient of friction is different and now our tires fail to grip the road. Or more to the point, that our speed and feed calculators are now trash and will crash the endmill into material ruining the machine and part.

Computers and their ability to run or not run software after and update is completely in the control of the people programing the updates. The reason so much software fails is because either A. It was not well designed to begin with or B. the people creating the update did not design it well.

Thank you. You put it better than I did.

Except software isn’t math. Math is entirely self contained and self defining. Software has dependencies in hardware and other software that are not contained in the software. A better analogy is the symbolism of an algebra and way of expressing math. While calculus hasn’t changed for techniques known at the time, fluxions aren’t supported as a method and symbology while a derivation of liebnitz’ notation is. The math is invariant but the symbology and evaluation methods change with time.

Likewise hardware architectures change, and it’s absurd to assert machine code from the Eniac must run on every architecture, as well as every variation of every machine ever made on every future hardware in perpetuity. There are to this point many preservation efforts that create emulators that run on modern hardware or reference virtual machines that can be carried forward. But to expect this to be done in situ everywhere all the time for everything is on the surface absurd and unreasonable to an extreme.

Edit: the Eniac didn’t have machine code, but switches and wiring - even more to my point. While it’s still just math and logic, it’s not reasonable to carry forward all software configurations of the machine.

I feel you. But the challenge is supporting ancient apis and abis over time greatly complicates the underling runtime. There’s a natural tension between flexibility for the evolving system that adapts to modern needs and techniques and hardware and one that runs ancient runtimes in perpetuity. Things have gone back and forth over time and the winner tends to be the simplest one, which is apis stay stable over some lifetime until some well advertised horizon then things stop working if they don’t make the effort to evolve. Just like I don’t expect to be able to plug in a old mainframe RLO drive into my MacBook M2Max and have it work, you can’t plausibly expect ancient runtimes to work forever. That said, a lot of effort goes into writing emulators, and I’d expect this specific software will see a second life at some point

> Open source means that anyone sufficiently able and sufficiently motivated can keep up with these changes

Provided there is anybody with very rare combination of being developer proficient in whatever language was used to write this software and who knows how Torah is read/sang

I don’t think making it compile on a new architecture requires any understanding of the Torah.

Yes you can get very old software running in Windows using various compatibility tools. Like isn't it possible to get Windows 3.1 software running on the latest releases of Windows? There's definitely just a setting in Windows 10 to run compatibility modes back to Vista. Earlier versions of windows that can be run in HyperV can go further back.

Not so much MacOS after a few years, though they did release Rosetta and Rosetta 2 to handle the transitions to and away from Intel processors.

Yes, I'm running some proprietary software for my Nikon Coolscan film scanner. Compatibility mode and a some other stuff.

No, and it's much more thorny than you make it out to me. Windows Vista (I think... 7 for sure) and later cannot run 16bit exes at all.

While the software itself was 32bit, many of the intallers of that era were Intallshield/InstallerWise that were still actually 16bit, so while if you could get the thing installed...you can't.

Windows 7 included an "XP Mode" virtual machine which could run 16 bit applications.

Wrong, it's the 64 bit versions that can't run 16 bit software. But even Windows 10 can run 3.11 apps if you use the 32 bit release.

The only way you can get win311 software working on win10 is to install the 32 bit version (aside from emulation). Not sure win 11 has a 32 bit version. Also win311 apps can be wildly picky what sort of dlls are installed. So your mileage can vary.

There are workarounds, e.g. http://www.columbia.edu/~em36/ntvdmx64.html

On Linux, as long as the program is compatible with Wine[1] to begin with, Wine will support programs that that require basically any Windows version. Maybe this specific community needs to spin up some Ubuntu or OpenSuse boxes?

[1] https://www.winehq.org/

Running old versions of macOS with VMWare Fusion is pretty easy as long as you still have an Intel Mac. I've been doing it for years to build legacy software, and for testing software compatibility with old versions of macOS.

Reply on news.ycombinator.com