The convenience of binary executables is pretty clear in the DOS and Windows ecosystems, where games and native utilities have been distributed this way for decades. I have Windows binaries I've been carrying around for twenty years that still work on Windows 10, and old DOS programs run just fine in DOSBox. A key characteristic of such programs is that they include most of the libraries they use in the installation, with only a few common dependencies like the C runtime or Win32 left to the rest of the system. FFMPEG is a great example.
Well, you can do the same on Linux. The Linux kernel system call ABI doesn't usually break support for old software, and as long as you have a statically linked binary you can run even software that was compiled targeting Linux 2.4 (if I recall correctly).
The fact is that is usually done in the Linux ecosystem: if you have access to the source code, what is the pro? It's just simple to recompile the software targeting the release of the operating system you are using. By dynamically linking system libraries you will get smaller executable and save RAM since they are shared (not only on disk, but also in memory, that is what shared means!)
Well, the problem is that it's not simple to recompile. There's a number of different build systems. Dev libraries you might not have installed, and that might no longer exist. Warnings that turned into errors in your version of the compiler, and all sorts of other nastiness.
I dread every time I need to install a (older) package from source. I think around a quarter of the time it turns into a multiple hour adventure of frustration, only to discover the library it was missing is called $NAME-dev on my distro...
I have been personally and my whole professional life on Linux for 15y. And I have the exact same feeling when I have to compile something.
The waste of time to compile anything is staggering. And more often than not I give up on failure after 2h. Because one of the recursive depency is impossible to build. Or I got tired of git cloning or wget'ing 50 differents stuff.
As far as I know gcc doesn't turn warnings into errors from one release to another. In fact the default is that no warning is considered an error, unless you use options to force a different behavior. This is something that Apple seems to do (last time I used a mac I've seen that the Apple compiler that is a proprietary build of clang have some warning considered errors enabled by default), but I never seen in any Linux distribution.
For code, you can compile by specifying the correct C standard. Unless the build system is badly written and doesn't add the correct -std=cXY to gcc of course (but it's trivial to fix).
Regarding libraries, that is a real problem. Because to compile and old software you should use old version of the libraries, and they are usually not easy to get (and then it's a pain to compile them, and put the correct environment variables to make the software you are building link to that libraries and not the one in the system).
I'm always able to compile a software, even an old one, on my system, and it never took me more than a couple of minutes. But I recognize that I'm a pretty experienced Linux user, so sure for the average user having a binary package is more easy.
I'm guessing that they're talking about -Werror. (Which should never be specified in the build config you distribute, but is fine for tightly controlled environments like your DEV and CI environments.)
Can’t agree more. Especially when the source code you want to build has a lot of build dependencies, and they have version conflict problem with your environment.
Sometimes it will ends with: XXX is missing, required version mismatch, install correct version, your computer crash.
> ...only to discover the library it was missing is called $NAME-dev on my distro...
You lost me at this part: if the dependency is easy to install and the issue is you just don't know that all of the headers are in -dev packages this seems like the easiest problem to never have again. Really: right up until there I was rooting you on.
That's really not a great idea on Linux. A ton of stuff is handled in userspace. There's really no better way to distribute Linux apps than source code.
I dread the day we have to put together an installer for it. If we ever decide to use GTK on all platforms we'll have to since the GTK developers don't seem to think static linking is a useful thing for them to support.
GTK on Windows is one of those things that irk me to no end. I've installed several tools that come with the entirety of GTK (and even a dbus instance that tries to start on boot) in the program files folder for that specific program.
The GTK folks oppose static compilation, and that's a perfectly fine point of view because they can support their opinions quite well. However, without an official "Microsoft visual c++ runtime" equivalent, distribution of GTK apps is just so annoying on Windows! You can get the entire GTK library suite just fine on most Linux distros but when it comes to non-Linux platforms, you're left to your own devices, and that means every platform comes up with its own solution, incompatible with the rest.
Meanwhile, Apple has gone through two deprecations of CPU architectures: first PowerPC and then Intel. Macs are nice, but I wish they had the same commitment to backwards compatibility.
Well, 3 actually, you missed the 68000 architecture.
I'm not sure it really matters, in the end. How often would people want to run PowerPC-era Mac software on modern hardware natively if they could? The HN audience will include a disproportionate number of people who do, so you guys aren't included ;-)
I haven't used a Mac in several years but it seems like the whole Apple mindset is more appliance like, that if you bought old software you just keep running it on the original old hardware, and given the problems with Microsoft's eternal backwards compatibility approach (applications and the OS bundling forever ancient code and keeping ancient interfaces around forever, and ending up with a disproportionate number of API calls numbered foo2, foo3, foo4ex), I'm not sure either way is strictly superior to the other. There are trade-offs with both.
There are some universes where old software or hardware is still heavily used or valuable. One area where I dabble is electronic music. Sure there are lots of new things, but a 50 year old guitar is still a viable instrument, so why not a 30 year old synthesizer? So in this universe, some people go to great lengths to maintain software that supports these instruments. I have a Yamaha VL1. Released in the mid 90s, it was Yamaha’s flagship “tech preview” for waveguide physical modeling software. You could play the instrument and tweak some very basic parameters without a computer, but if you want to actually edit the modeling, you need the “expert editor” which requires MacOS System 7 and a direct serial MIDI port or Apples long gone “midi manager” software. I keep an old 68k laptop around for that purpose alone.
Korg released an audio DSP playground in a PCI card called the OasysPCI which never got OSX drivers, so I have a MDD PPC Mac to run that. There are probably better things running natively today, hey instruments are things that shouldn’t be obsoleted, since they all have their own sound. Most of the rest of the ancient software I run is run under Wine (which worked quite well up to Mojave, but became difficult when Apple killed 32 bit support) because Microsoft has done better at retaining backwards compatibility. So now I have a laptop permanently stuck on Mojave.
> How often would people want to run PowerPC-era Mac software on modern hardware natively if they could?
I think some creative people, e.g. writers, might like to be able to continue to run their favorite old word processors if they could. Every so often you'll hear about a writer who's still using Wordstar or WordPerfect or some other old software because they know it inside out and it does what they need.
Oh, definitely. I'm just wondering how many Mac people would want to run said software on new hardware, as opposed to using their old hardware.
Of course, using old hardware has plenty of disadvantages (the increasing scarcity over time as parts become impossible to acquire) but even now you can find power macs for cheap. Your average ebay listing is pretty ridiculous but I snatched a G4 ibook there 2 years back for $14 USD, essentially in like new condition.
Not PowerPC, but 32-bit programs are no longer supported since Big Sur - since they decided to no longer ship 32 bit libraries. There's software on the Mac that's 4-5 years old and cannot be run.
And it's not an academic one - a large percentage of somewhat older Mac-native Steam games don't even start.
> I'm not sure it really matters, in the end. How often would people want to run PowerPC-era Mac software on modern hardware natively if they could?
It includes much more recent software too. It seems like half the mac games on Steam are 32-bit binaries published before October 2019 that no longer run on modern versions of macOS.
For me, close to 30 years as some small utilities I wrote when I first started Win32, I still use regularly. Most of them are below 100KB and link to MSVCRT, the system C library.
