Why do people think that the universality of decay can be stopped? I would even question the assumption that it should be stopped.
On a long enough timeline, the survival rate of all APIs goes to zero. (Except Lisp, which is Eternal).
On a long enough timeline, the survival rate of all APIs goes to zero. (Except Lisp, which is Eternal).
Theory: A lot of those people tend to survive by jumping from metaphorical ship to ship (API or software or whatever). So to them, the reality is that the ship you're currently on pretty much always feels like it's sinking, and you're always looking out for signs. You write articles lamenting sinking ships, because that's your reality.
These people also may feel like the universality of decay can be stopped in the current context, by moving away from a decaying ship/system. It's more of a question of where the decay isn't as bad, or as seemingly needless.
Example Pro: After a while you can get really good at evaluating ships. Con: It feels useless to build your own ship; you're afraid you'd have to jump from your own ship and wouldn't that feel awful.
Other people survive by building ships. They're cool with decay, because building new stuff that works better is interesting. Their job is to support their stuff, and to a lesser degree to patch others' stuff, like maybe their supply ship, or a friend's ship. To people like this, the reality is that holes just happen. So you learn to deal. Maybe you even learn to love patching holes, and you get so good at building ships that your ship's holes are downright fascinating anyway.
These people aren't usually as worried about decay. But they may have a problem of eventually going down with their ship, or finding that their ship is no longer just a ship but also a lot like a baroque form of floating junk pile.
Example Pro: Obvs, you can build ships. Con: People will try to jump on your ship, and they'll probably tell you they think it's sinking, and expect you to do something about it.
For a second, ignoring safety concerns, what should change in how we serve some HTML, JS, CSS and some images in 20 years? Sure, there are plenty optimizations and new technologies to utilize for sites that need high performance or to use certain hardware functionality, but when you just want to display some simple content, none of that is really relevant. Why couldn't i build my personal website with some mostly static content and have it work for many years, while i'm not tied down with constantly maintaining it?
Even now, that's not the case. I decided to build my own site in Ruby on Rails, since it feels mostly stable - however i need the exact same version of Ruby both on my local machine and the server for it to work (using containers for development isn't always a pleasant experience, even though using them for packaged software is great). I also need to rely on dozens if not hundreds of packages, as well as bunches of native extensions, for example, to connect with a SQLite database to serve some simple dynamic content. Of course, i also need to update the OS (thankfully Debian unattended upgrades are pretty stable, except for the one time when they broke GRUB entirely and the server couldn't boot), as well as the web server and there's no guarantee that the SSL/TLS certificate provisioning from Let's Encrypt also won't change in the future.
To that end, the above goal is impossible - i can't just keep building new things, since i have to spend time maintaining what i've already built, even if nothing changes about what i need from these projects functionally, just because sooner or later a rug will be pulled out from under my feet.
Edit: i've actually written a blog post on the topic of updates, called "Never update anything": https://blog.kronis.dev/articles/never-update-anything
Doesn't sound so stable to me…
> Why couldn't i build my personal website with some mostly static content and have it work for many years, while i'm not tied down with constantly maintaining it?
You can, HTTP still works and even oldschool HTML mostly works¹.
If you only need sqlite as a db you could easily compile a static binary that will run forever (as in foreseeable future) and serve content via unencrypted HTTP. If you then use a reverse proxy that can be automated with certbot you will have a system where all the maintenance work is done by the EFF, the reverse proxy developers and your distro's packaging team.
I can understand why they'd complain about version mismatches when installing dependencies, since in those circumstances failing fast prevents me from running into deprecated functions down the road, as would happen with PHP. However, the fact that different versions of Ruby/Rails are available in different OS distros and such basically mandates that i use containers OR that i just change the contents of my Gemfile to reflect the version that i will be using during build, which carries the aforementioned risks.
That said, Ruby and Rails are both far more stable than the current npm or pip ecosystems, given that the development has slowed down in Rails somewhat and isn't broken every week due to some package introducing breaking changes. That's not to say that it's better in most conceivable ways (for example, in regards to scalability), but as far as batteries included solutions go, it's pretty okay.
> If you only need sqlite as a db you could easily compile a static binary that will run forever (as in foreseeable future) and serve content via unencrypted HTTP.
Actually, static binaries are perhaps one of the better ways to ship software, especially with static linking, as long as you're ready to take certain security risks in the name of long term stability, though that doesn't prevent you from building new versions in an automated fashion either, at least before something breaks down the line and hopefully your tests alert you about needing manual intervention.
It feels like Java sort of tried to be this, as did .NET, but there is too much functionality that depends on reflection and standard library classes out there, that many projects are stuck on JDK 8, and the whole .NET/Mono --> .NET Core --> .NET cycle is as promising as it is also problematic to deal with. As for actually workable options nowadays, i'm not too sure - most ways to encapsulate scripts in static binaries fail miserably (containers allowing to mitigate this, but don't address the root issue) and otherwise there aren't too many technologies that are good for this out there.
If i wanted to go down that route, i'd probably go with Go, since it doesn't have the problem of needing JDK (and GraalVM is still brittle, for example with Spring Boot, an issue that Go doesn't have). Any other options that you can think of? I really like the idea behind Lazarus/FreePascal, though their web server offerings are really lacking, which is sad.
As for HTTP, i largely agree - read only sites don't necessarily have to be encrypted, even if that can hurt SEO.
> If you then use a reverse proxy that can be automated with certbot you will have a system where all the maintenance work is done by the EFF, the reverse proxy developers and your distro's packaging team.
I am already doing this, but as the Caddy v1 --> v2 migration showed, even web servers and their integrations are subject to churn and change. I'd say that it's only a question of time until Apache/Nginx/Traefik + Certbot run into similar issues, either with new methods for getting certificates being needed, or something changing elsewhere in the supply chain. And even then, your OSes root CA might need to change, which may or may not cause problems. Old Android phones have essentially been cut off from internet for this very reason - the fact that i can't (easily) install Linux on those devices and use them as small monitoring nodes for my homelab disappoints me greatly, especially since custom ROMs brick hardware devices due to lacking driver support.
So sadly if i get hit by a bus tomorrow, it's only a matter of time until my homepage stops functioning and the memory of me disappears forever. Of course, that's just a silly thought experiment, since i recall another article on Hacker News which pondered how someone could keep code running for centuries. It didn't look too doable.
I meant compile your whole logic and libraries into one (big) binary so you won't depend on any runtime that might ever change except for your operating systems syscalls.
> most ways to encapsulate scripts in static binaries fail miserably [...] and otherwise there aren't too many technologies that are good for this out there.
LUA is about as stable as it gets, (minimal) WASM runtimes will also probably live forever. (Or are, most likely, interchangeable if not) For both of them you'll need to build the interface yourself, so any breaking change will at least be your own fault.
> Any other options that you can think of?
Rust, or if you are a bit masochistic C or even C++. Rocket 0.5 (Rust) looks really nice (as in ergonomic) as a webserver and iirc you can statically link with musl instead of glibc.
> I'd say that it's only a question of time until Apache/Nginx/Traefik + Certbot run into similar issues
But then youll at least have http as a fallback
> So sadly if i get hit by a bus tomorrow, it's only a matter of time until my homepage stops functioning and the memory of me disappears forever.
I think what you want is a trust fund :D
Because information can be perfectly copied? 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.
(In fact, rumors are that George RR Martin does exactly that, and sends whatever he writes to his publisher on 3.5" floppies)
Nothing we store digitally need ever be lost so long as some basic stewardship is performed. For now that means moving data to newer storage formats, making redundant copies, using error-correcting codes, etc. Maybe eventually we'll get the mythical "store all your data in a diamond" 3D / 5D holographic storage that always seems to be a few years off.
Somehow, we've managed to take that natural feature away.
That being said, in an archival sense, it would be a shame and seems unnecessary to lose anything, since perfect preservation is achievable. But archival preservation, is different from staying in active use with a healthy community of practitioners perpetually ad infinitum.
So even if you have good reasons to remove an API or feature, you should also provide means or resources to those who wish to preserve and archive the data. And this is something that could be factored into the original design without committing the project to the technical overhead of supporting it forever.
Additionally reducing the problem to humans just chasing shiny new things is simply not true. There’s no denying that some implementations are just bad or dangerous security wise or the world has completely changed in some way.
Not letting things decay could risk the whole platform dying as a result, not just the feature. It could even get to the point where adding anything new is way too risky because of long term support obligations, so decay could be made worse because of efforts to prevent decay!
Obviously we can still make sure great consideration is made both before adding something new and before removing it.
There’s no getting away from the balancing act between change and conservation.
There's the physical degradation of mechanisms and data storage substrates themselves. That's ... not insignificant, but a minor part of the whole situation.
The short-term strength and long-term technical debt of digital is dependencies. Sure, you can spin up some bare-metal or virtualised instance of a system from last month, or five years ago, or twenty years, ago, or fifty. Odds are that the emulation will run faster than the original.[1]
But with time and complexity, dependencies started to expand.
One of the underheralded changes of the 1990s wasn't so much Free Software as what it wrought: an ever expanding and accelerating increase in the number and specificity of dependencies. Tarball distribution gave way to packages, with dependency-resolution, some better (APT), some worse (RPM). Crucially, dependencies didn't simply have to be resolved at build time, once in the lifecycle of an executable, but at install time, once per installation.
The explosion of Web apps and frameworks triggered another violent expansion of the situation with both even more dependencies, more deeply nested ones, but runtime dependencies where prerequisites are identified and fetched from remote hosts.
At runtime.
Which makes the current appified-web immensely flexible and convenient, but also fantastically brittle.
(Of course, the old-school type scan extend this story back to interpreted vs. compiled languages, JIT, hardware-specific variations, high-level vs. machine langauge, binary, and toggling in programmes. It's been a long process.)
But as bits of that infrastructure fall apart, you'll find that digital does in fact decay.
________________________________
Notes:
1. At a gig some years back, a cow-orker told of a uni prof they'd studied under, who did work on the the B and BCPL programming languages. Those are precursors to C. Back in the day when auto manufacturers were looking at automated systems controls, he convinced them that C was far too complex and high-level, and that they should use the more performant BCPL. Which they did. And still do (or did as of a decade or two back), running under several generations of emulation. Faster than the initial hardware implementation. Mind I'm taking them at their word....
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
>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?
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
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
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.
Because web pages and simple web scripting is often done by non-professionals, who cannot be expected to follow standards processes in perpetuity to keep their pages/scripts working. They often author a few pages and move on with other things in life, which is why browsers being ultra-conservative about breaking stuff is important for the robustness of the Web.
FWIW although I'm actually a fan of decay, I think its a terrible idea to deprecate `alert()`. I get it that it's abused, but it's also an important part of learning js -- it's the easiest way to make a side-effect. (No, `console.log()` isn't easy because you have to open dev tools, which is scary and hard. A simple modal dialog is far friendlier and immediate and visceral and gives a feeling of power.)
I am a professional software engineer at my day job, and we strive to keep our software up to date etc as the world changes.
But I am also exactly this non-professional developer in my after-hours. I have written a number of little web apps that solve some small need, and I really have zero interest in maintaining them over time.
When I wear that hat, I really appreciate the conservatism of most web stuff.
Professionals can't keep up with standards processes either. Because Chrome employs people to work on them. Who's going to pay me to keep track of literally hundreds of standards currently in development?
The philosophies around entropy isn't really relevant here IMO. The web should continue to be evergreen.
Something completely new would fasttrack innovation. It could leave out all the quirky workarounds and get advanced features built in or easily extensible. When adoption is high enough it could include a legacy box, to run good old HTML based content.
Have any attempts at this sort of thing ever been made?
Something like websockets is not exactly accessible to a beginner, but there is a huge need for online content that supports live interaction.
You are right that it's not going to be easy to get everyone on board, but that should not be a reason to stop trying.
Of course, what's junk and what's not might be controversial, but that's where it got its start.
I think that's pretty impressive as far as API age.
I'd rather say that the "universality of decay" is a U-shaped curve. Just have a look at old arcade and console games... they went out of fashion, the hardware (sometimes literally) rotted, but emulator technology is getting better and better all the time - the result is you can use any modern computer or many smartphones (!) to run all that stuff that is sometimes many decades old.
All that any kind of technology needs to survive into modern ages is one (single or group of) person that engineers an appropriate abstraction layer. Polyfills, virtual machines and other emulators, FPGA-based hybrids... the list is endless.
<3