Hacker News Reader

Comment by seagreen | Hacker News Reader

> software decays over time, a.k.a. entropy

This is similar advice to "always have your castle ready to withstand a siege". Both are excellent pieces of advice -- for 2010s software/the medieval ages respectively. But the advice is not timeless, once we get/got our crap together it stops making sense.

Software decays because we don't track all its inputs. Once we do it will no longer decay, when run in environment X it will give output Y, every time. There's already movement on this front with http://nixos.org and imitators -- I expect massive improvements on that front in our lifetimes.

Of course, you still need an x86-64 computer or whatever. I doubt they'll stop making them any time soon though=)

View on HN

You can track the environment all you want, but you still have to modify your software when the environment changes.

If your software has a web page, browsers are not under your control. You don't know what the next version of Firefox is going to do.

If your software runs on any cloud service, you don't know what they're going to do.

Also, even if the software stayed the same, business requirements will change. New security holes will be discovered. Customer expectations will change. Who knows, maybe IPv6 will finally happen?

Freezing your software is not an option for most people. The Internet is not done yet and it's not going to be done anytime soon.

It's possible that we will reach a point in computing history where we can run all historical software, and that this state of affairs will continue indefinitely. It just requires enough manpower put into "bootstrapping" of hardware in software (emulation). A decentralized Internet file system might help too.

In other words, the "digital dark age" [1] for code (in addition to documents) doesn't need to last forever.

You might compare it to things like farming, metallurgy, or plumbing. Many things in those areas were invented independently in different geographical areas, and some were altogether forgotten and reinvented later. But now we've reached a point in civilization where we're not going to forget them, because we have libraries, the Internet, and so forth.

Likewise, at some point we should stop forgetting how to run old software as well. Old software can be made runnable now through conscious effort, but the "default" is still for it to rot and be forgotten.

For web pages, the Internet Archive only does the server side... there does need to be an archive of web browsers as well, and there probably will be some day. I have no idea when that will be, but I think it will happen.

[1] https://en.wikipedia.org/wiki/Digital_dark_age

https://www.softwareheritage.org/

That's a great effort. Though their mission isn't exactly what I am describing, it's definitely on the way.

It seems like it is mostly about collecting source code at this point. But the harder problem is the build and runtime environments (and how to "bottom them out"). Without the ability to execute it, source code has limited utility.

"Given that any software component may turn out to be essential in the future, we do not make distinctions and collect all software that is publicly available in source code form."

The Debian snapshot service keeps binary packages too:

http://snapshot.debian.org/

The Ubuntu Launchpad system has something similar.

Fedora's build servers keep all packages for eternity IIRC.

If your software runs on a CPU, those are not under your control :)

I agree with all this:) I also enjoyed the article, "free as in baby" is a great phrase.

At the same time I think it's important to note that the entropy analogy is just an analogy. Software is not actually subject to the laws of entropy (at least no more than a book or a poem is). Sure, often we want to change programs for various reasons -- that's not entropy.

Most fields have to deal with actual entropy -- the fact that we don't should be super exciting. See chubot's adject comment for just some of the things this makes possible.

The inputs we don't track are the decisions that go into every bit of the code. Your memories are as important as the code, and your memory decays.

So the code rots, even though the text stays the same.

This is also why buying a software company and letting all the developers leave doesn't work. All that information disappears with them and you're stuck with a dead thing you have to try to reanimate.

The set of problems that any particular design will answer (it's a general thing, not just software) will change over time as economies change. That's why you probably don't own a horse, and certainly don't ride to work on one. Software may be 100% stable and yet will become gradually less accurate over time, doing work no-one needs and yet which places a cost on the project.

You cannot prevent this. The right thing to do is to learn to abandon old solutions when they're no longer economical, and to move rapidly to build new ones that fit the same APIs, yet know more about the modern world.

Hence your car seat is approximately the same API as a horse saddle, built on different technology.

> Of course, you still need an x86-64 computer or whatever. I doubt they'll stop making them any time soon though=)

There is plenty of hardware that would have been made 10 years ago that is no longer available.

So if your system is based on such hardware, eventually it will fail, only because you wont be able to find spare parts to keep it running.

Then as soon as you upgrade to newer hardware, you will run into OS issues where your older OS no longer works with the newer hardware.

That will force you to also do an OS upgrade and that upgrade will then cause issues with your old code, which no longer runs on the new OS.

So there is plenty of external factors, all outside of your control, which will cause decay in your software.

Reply on news.ycombinator.com