Hacker News Reader

Comment by reikonomusha | Hacker News Reader

One of the reasons I’m very for open-source (including all my code) is for the reason that porting is easier. It seems like the gripe should not be with Apple changing processors (or OS’s or hardware features or ...), but rather that (especially commercial) software is so fragile to medium-term environmental change. Binaries are just not very resilient artifacts, especially when they so closely depend on their surroundings. High-level programming language code, on the other hand, is much more resilient.

It’s also a reason I use Lisp: the spec doesn’t change and won’t change. Stuff runs forever.

View on HN

Bingo! It’s boil-the-ocean level crazy to attempt to recreate the environment for a particular file, when the sensible approach would be to just have the file format and it’s reader/viewer software be open so it can be recompiled or ported to any new platform. The blame/responsibility lies not with those innovating on hardware, but those who have created brittle software systems which have no ability to adapt to the changing environment.

Yet another example of how holding binary artifacts is not functional equivalent to “owning” software.

This is probably a path dependent outcome from the process that brought us the the "personal computing" era. It really kicked into gear and achieved ubiquity with Microsoft selling both the main operating system AND the "standard" productivity software suite that was the primary reason people owned computers. MS made their money back then selling upgrades to Microsoft Office that broke backwards compatibility. Part of the strategy was owning the environment so they could work in some amount of engineered obsolescence into the software lifecycle.

Of course, because Microsoft was a multi-headed chimera, Windows itself bent over backwards to keep everything not Office chugging along forever.

agree, the authors mention of hacking around activation servers on legacy products is as much the problem as anything. it’s an odd sort of expectation that we’d have to be able to emulate 3+ generations of hardware on top of one another just to access an old file. Should we expect to be able to do this as hardware gets more sophisticated? I’m not convinced we should.

"Adapting old programs to fit new machines usually means adapting new machines to behave like old ones."

Epigram 120, Alan Perlis.

http://www.cs.yale.edu/homes/perlis-alan/quotes.html

> adapting new machines to behave like old ones

There is a great DailyWTF somewhere about a company that was using an early IBM mainframe, which when it died, instead of porting their code to the newer mainframe, the wrote an emulator. And when AIX came around they wrote a mainframe emulator to run their old emulator...

This maybe the story I was misremembering the details of?: https://thedailywtf.com/articles/No_Need_to_Change_It!_

This is how IBM mainframes are still able to run COBOL binaries from many decades ago

> Binaries are just not very resilient artifacts, especially when they so closely depend on their surroundings.

Depends on the platform. I can run statically compiled Linux binaries that were released 20 years ago just fine. Similarly, I'm able play Windows games that were released over 20 years ago.

Not by accident... Linux, windows and intel have put in a lot of effort to ensure this holds, specifically because binaries are so incredibly fragile — hell, you’d have the same trouble Mac is having now if you tried to swap out to AMD on any OS; or tried to swap out OS on same hardware.

Really, you should generally be under the presumption that changing anything at all could screw up anything and everything; it’s really a marvel of human engineering anytime software runs successfully

Maybe the binary runs, but for any non-trivial I/O (GUI, 3D, specialized input devices) you're still dependent on specific interfaces which are probably not the same anymore.

Case in point: try running any of the Loki Linux game ports from 20 years ago on a modern distribution...

These are examples of binaries that explicitly don’t depend on so much of their surroundings. They depend on the existence of a processor and a binary executable format, and perhaps some very basic syscalls that had no business changing.

And when your Linux environment moves to ARM?

Which was, in fact, a lot of the impetus behind open source generally early on. And even the less formal sharing of Unix source code given that it was written in a high-level language and could therefore be relatively easily ported to new systems.

Binaries are just not very resilient artifacts, especially when they so closely depend on their surroundings. High-level programming language code, on the other hand, is much more resilient.

That’s a modern phenomenon. AS/400 or Solaris binaries were different.

Binaries on Microsoft Windows are more resilient than some GNU/Linux source code.

Except it's really the OS doing cartwheels to keep them going.

At one point I stopped caring how they do it. I just want them to do it. We can't all be everywhere at the stack at the same time. We have work to do.

Or maybe it's the OS refraining from doing cartwheels that keeps them going.

You're right in that a stable ABI goes a long way to keep old binaries working!

My point is about this sort of thing:

> [...] anybody who has read the Old New Thing blog (https://blogs.msdn.microsoft.com/oldnewthing/) or Raymond Chen's chapter on Windows backwards compatibility (http://ptgmedia.pearsoncmg.com/images/9780321440303/samplech..., PDF) will be both impressed and horrified at the lengths the Windows team went to in order to avoid breaking programs.

https://news.ycombinator.com/item?id=13450629

Will Lisp ever specify concurrency as part of the specification ? Standard well-supported concurrency is vital for any modern-day programming language. Without that, common LISP is relegated to the realm of gradually dying languages.

Exactly the reason I dipped my toes in Racket, loved it, then went back to Elixir (and Rust). Without a good runtime / libraries to tackle concurrency and parallelism in a transparent way -- as Erlang/Elixir and other BEAM VM languages do -- the other traits of a language take a back seat.

+1 right on.

I would like to see more companies open source their commercial products after maintaining them is not cost effective. I would like to see mostly open source code, period.

re: Lisps: I have been using Common Lisp since 1982 (and other Lisps before that) and I love it that my old code and archives of other peoples’ Common Lisp code usually runs with no problems.

Right... Let me know how Python 2.7 code runs ina few years.

… why would it not run fine? Python 2.7 is “no longer receiving updates”, not “ceasing to exist”. You can still download source code back to Python 1.5.1 if you really want to run code with old syntax (Which I just did for fun - the C code needed one tweak to avoid conflicting with a recently introduced standard library function; the python code was fine)

Indeed. The most stable long-term is probably a small C program, designed for pipes with stdin as input, and stdout as output. UNIX philosophy is great for longevity.

"Everything is a file" only works when TXT is the file format though. When things build up to PostScript or PDF, or Claris... then things get out of hand too quickly.

Id be very surprised, shocked if I cant run a vanilla stdlib only Python 2.7 script on all the major platforms in 10 years time, even 20 years time.

If the code isn't going to change, you could statically compile it and it will run just fine.

Reply on news.ycombinator.com