4 ms·
> Source code, binary assets, third-party libraries, and even compiler toolchains. Everything. How far down the stack of turtles do you go, though? Should you
by adrianmonk 3y ago
> Source code, binary assets, third-party libraries, and even compiler toolchains. Everything.
How far down the stack of turtles do you go, though?
Should you include the libc that the compiler requires to run? Other parts of the operating system? The kernel? An emulator for hardware that can run that kernel?
Eventually, all of those things will stop being produced or easy to find. Even if you have the libraries and compiler in version control, can you build a game that ran on MS-DOS 5.x or CP/M or DEC VMS?
My point is that you may want to just designate a stable interface somewhere (a language standard, some libc ABI, etc.) as the part you expect to not change. Be aware of what it is, and account for it in your plans. If a language is the interface that you expect to be stable, then don't upgrade to a compiler version that breaks compatibility. Or do upgrade, but do it in an orderly manner in conjunction with porting your code over.
If you want your code to be runnable by our descendants 1000 years from now, you should probably have an incredibly simple VM that can be described in a picture and a binary that will run on that VM. (In other words, you go down so many turtles that you reach "anyone who knows how to code or build machines can implement this VM".)
- lebean 3y agoEverything! Check in your OS's system files! Build a new PC with parts identical to the one you're building on! Build many of them, one for each commit, and put them all in a warehouse!
- adrianmonk 3y agoI mean, if you're the military, this might be the right answer. If you're making a personal web site, probably not.
- hducy4 3y agoThis is a strawman. You're extending their argument to an extreme so it sounds silly when it's not what has been proposed. The argument is clearly to keep direct dependencies required for building in source control so that if you have a working build system, you can build the software indefinitely and independently from the internet. Build systems and operating systems don't disappear overnight. Leftpad does.
- adrianmonk 3y agoWell, I wasn't trying to mock them or disagree, although I can see how it might have sounded that way. What I am trying to do is point out that you can't just say "everything" without defining what that means and knowing why. Maybe you need less or maybe you need more. IMHO, you should do it by looking for places that might be stable and then (consciously) choosing one that meets your needs. I've actually been in a situation where our source, all the libraries in our build, and the toolchain were not enough. It turned out that one of the libraries we used was itself dependent on another library, a certain dynamic library (which I'll call libfoo.so) included in the Linux install. We got new hardware, but it would not boot the same version of that Linux distro, probably due to lack of drivers. It would boot a newer version of the same Linux distro, but that included libfoo-v2.so, not libfoo.so. Since libfoo-v2.so was a different major version with breaking API changes, our project wouldn't compile.
- deleted 3y ago[deleted]
- ClumsyPilot 3y agoThe VMs have a reasonably standard interface, so do container images, so kinda either could work as your ‘everything’. Alternatively just make a system image of the entire PC, setup exactly how you want it, with some common hardware that you can expect to be available in 10 years -like a standard intel cpu.
- maksimur 3y agoI've been thinking for a while how fragile computers are, from the software down to the hardware. I've been wondering if maybe it would be better to keep some things on paper, but paper doesn't last long too, and if it does, then you have the ink to think about. This drives me crazy sometimes.
- rocqua 3y agoComputers are fragile, but they are copyable. Quite easily and exactly copieable. Consider how books written 1000 years ago still survive today. They were diligently copied. Now compare the effort (and accuracy) of such book copying to computer copying. Next Consider error correction and error detection that is trivially built in to digital data. Nothing physical is permanent, but with just a little upkeep, information can live indefinitely.