4 ms·

> If you replace the components as they wear out, you can still have a computer from the 1980's running fine. The OS and software still work exactly the same. W

> If you replace the components as they wear out, you can still have a computer from the 1980's running fine. The OS and software still work exactly the same. Whatever data will still exist as a perfect copy. Sadly, this is no longer the case, since nowadays OSes rely far too much on the Internet. For example, your Docker and VS Code repositories eventually will deprecate and remove certain versions of software that you might have been using. Furthermore, npm and pip packages will also decay in a similar manner and eventually Maven repositories will drop off the Internet one by one. Installing software from DVDs or flash memory is no longer the normal for all of the OS and the rise of the private package repositories without having the tooling in place to ensure that we can download .deb or similar files with all of their dependencies into an installable collection that can be persisted in such a manner is an utter failing of the modern age. For an example, just look at these: - https://superuser.com/questions/876727/how-to-download-deb-package-and-all-dependencies - https://stackoverflow.com/questions/13756800/how-to-download-all-dependencies-and-packages-to-directory They're not tools that have had a lot of consideration and attention given to them, prioritizing their development and testing. They're scripts that are exceedingly hacky, patched atop unsuitable methods of managing packages.

HWR_14 5y ago
>> If you replace the components as they wear out, you can still have a computer from the 1980's running fine. The OS and software still work exactly the same. Whatever data will still exist as a perfect copy. >Sadly, this is no longer the case, since nowadays OSes rely far too much on the Internet. That seems like an issue with current work, not with past work. And yes, it's an issue. Figuring out how to archive tools and buildchains is important. Although, do modern OSes rely too much on the Internet, or does the modern development ecosystem?
- KronisLV 5y ago
  > Although, do modern OSes rely too much on the Internet, or does the modern development ecosystem? I'd say both. Operating systems should be developed with offline first in mind, instead of giving into the prevalence of downloading things from the Internet. For example, Debian has apt-cdrom which allows updating /etc/apt/sources.list and adding packages from DVDs or CDs. That is good, the next logical progression of which would be doing the same for any storage medium - flash memory, HDDs, SSDs etc., just a set of tools to easily create package mirrors on these storage devices and to read them from the OS to make airgapped environments even easier. Instead, as things currently stand, downloading a package with all of its dependencies is perhaps needlessly hard if you don't want a full mirror, but only need something like gcc with everything it depends on in one gcc-with-all-dependencies.deb file. And the situation isn't necessarily much better with the way how Flatpak and Snap packages want to handle updates, while there are definitely valid arguments to be made about automatically updating packages over the internet, as Debian unattended upgrades already does, relying on it too much makes software brittle. For example, just look at this: https://unix.stackexchange.com/a/541583 https://unix.stackexchange.com/a/541583 It took Flatpak until 2020 to address this, i'm not even sure what the situation is with snap packages and using them in air gapped environments, since that's also only in beta: https://docs.ubuntu.com/snap-store-proxy/en/airgap https://docs.ubuntu.com/snap-store-proxy/en/airgap I apologize if the above sounds a bit like rambling, but the bottom line is that if developers truly cared about airgapped environments, then using and managing them would be as easy as the alternatives, not less so. Be it in regards to tools, to how packages are managed, or even just the day to day experience while using them. And that trend extends deeply both into the OS itself, as well as the software that's used by it (especially in cases of non-standard update mechanisms, like some browsers like to do), as it does with the development ecosystems nowadays. It's surprisingly how little pushback something like snap got, instead of the community delaying its utilization until all of the concerns have been addressed. I'm not saying that we shouldn't innovate in regards to package management, apt over apt-get showed that there definitely can be improvements in regards to usability, it's just that we as an industry should never be satisfied with using half baked solutions.

HWR_14 5y ago

>> If you replace the components as they wear out, you can still have a computer from the 1980's running fine. The OS and software still work exactly the same. Whatever data will still exist as a perfect copy. >Sadly, this is no longer the case, since nowadays OSes rely far too much on the Internet. That seems like an issue with current work, not with past work. And yes, it's an issue. Figuring out how to archive tools and buildchains is important. Although, do modern OSes rely too much on the Internet, or does the modern development ecosystem?

KronisLV 5y ago
> Although, do modern OSes rely too much on the Internet, or does the modern development ecosystem? I'd say both. Operating systems should be developed with offline first in mind, instead of giving into the prevalence of downloading things from the Internet. For example, Debian has apt-cdrom which allows updating /etc/apt/sources.list and adding packages from DVDs or CDs. That is good, the next logical progression of which would be doing the same for any storage medium - flash memory, HDDs, SSDs etc., just a set of tools to easily create package mirrors on these storage devices and to read them from the OS to make airgapped environments even easier. Instead, as things currently stand, downloading a package with all of its dependencies is perhaps needlessly hard if you don't want a full mirror, but only need something like gcc with everything it depends on in one gcc-with-all-dependencies.deb file. And the situation isn't necessarily much better with the way how Flatpak and Snap packages want to handle updates, while there are definitely valid arguments to be made about automatically updating packages over the internet, as Debian unattended upgrades already does, relying on it too much makes software brittle. For example, just look at this: https://unix.stackexchange.com/a/541583 https://unix.stackexchange.com/a/541583 It took Flatpak until 2020 to address this, i'm not even sure what the situation is with snap packages and using them in air gapped environments, since that's also only in beta: https://docs.ubuntu.com/snap-store-proxy/en/airgap https://docs.ubuntu.com/snap-store-proxy/en/airgap I apologize if the above sounds a bit like rambling, but the bottom line is that if developers truly cared about airgapped environments, then using and managing them would be as easy as the alternatives, not less so. Be it in regards to tools, to how packages are managed, or even just the day to day experience while using them. And that trend extends deeply both into the OS itself, as well as the software that's used by it (especially in cases of non-standard update mechanisms, like some browsers like to do), as it does with the development ecosystems nowadays. It's surprisingly how little pushback something like snap got, instead of the community delaying its utilization until all of the concerns have been addressed. I'm not saying that we shouldn't innovate in regards to package management, apt over apt-get showed that there definitely can be improvements in regards to usability, it's just that we as an industry should never be satisfied with using half baked solutions.