6 ms·

Software rots if you can no longer set up the exact tool chain and environment (compiler, build tool, OS version, external database, etc) required to build and

Software rots if you can no longer set up the exact tool chain and environment (compiler, build tool, OS version, external database, etc) required to build and run it. Even interpreted languages suffer from this problem as features are subtlely changed - by design or accident. It doesn't matter if your project is using an ancient version of VC++ or a two year old version of NodeJS. If it doesn't keep up with the latest releases of the tools then it's already got one foot in the grave.

ArkyBeagle 10y ago
Through the miracle of virtual machines, this is much less so. VMs are the NAT of computer systems.
- jussaskin 10y ago
  Less so, I agree. But give it time - older VM image and container formats will probably rot as well.
  - smilekzs 10y ago
    VM formats are easier to migrate than the actual software they run. On the other hand this is a valid concern for containers.
  - specialist 10y ago
    Extending the digital entropy analogy: decay rate, half-lives.
- jussaskin 10y ago
  Even though the VM image and tooling may still be runnable, the world around it with which it must interact continues to evolve and can leave your software obsolete.
  - ArkyBeagle 10y ago
    One for one thing, another for another.
    - jussaskin 10y ago
      Fair enough.
- johannes1234321 10y ago
  While for current software, which depends to at least some degree on remote services (cloud?) This won't help at all.
- hueving 10y ago
  If devs have to download a VM running an old OS with old tooling, the barrier to entry is getting quite high. I wouldn't touch an OSS project that made me do that, I would assume it was effectively dead.
  - imtringued 10y ago
    It would be dead without the VM anyway.
- nickpsecurity 10y ago
  As jussaskin said, it can happen to them too. For example, VM/370 was among first virtualization schemes that could do all kinds of things PC/server virtualization bragged on later. Many key apps/OS's might be put in it. Yet, you'd be hard-pressed to run one of those with today's IT budgets if you couldn't afford a mainframe. Likewise, quite a lot of PC virtualization vendors came and went. The survivors occasionally have compatibility issues or corporations start going in different directions with less support of the older product. The product itself is often tied to a specific OS or HW combination that might go away. One can use virtualization to help future-proof apps. IBM's System/38 (later AS/400, iSeries, and IBM i) did this for decades. However, to be fully future-proof (esp for vendor level), the virtualization SW/HW solution itself needs to be immune to the problem. That means legally, easily-cloned HW with same for software and virtualization layer. Closest thing maybe NOVA microhypervisor on Loongson-style OSS CPU with x86 emulation if it's x86 apps. RISC-V w/ virtualization support otherwise. Guess what future-proof virtualization all the mainstream approaches aren't using, though? ;)
beat 10y ago
Some smart dude, don't remember who, said that every single line of code becomes technical debt the moment it is written.
- bostik 10y ago
  Legacy software is the code you wrote before lunch.[0] 0: http://www.russmiles.com/essais/dont-think-legacy-software-think-heritage http://www.russmiles.com/essais/dont-think-legacy-software-t...
  - beat 10y ago
    That's not the one I was thinking of, but it's a similar sentiment.
  - crucini 10y ago
    But strstr() doesn't seem rotten or "legacy" in a bad way.
    - xyzzyz 10y ago
      strcpy() does, though.
      - kazinator 10y ago
        What's wrong with strcpy? In a nutshell, we can only safely use it if we somehow know that the source string fits into the destination buffer. Those situations are few: basically, they involve fixed-length string literals being moved into buffers that are "obviously" larger. E.g. some widget_t object has a char name[256] field, and we initialize it by default with strcpy(new_widget->name, "<unnamed widget>"), or some bullshit like that. The literal is way shorter than 256 and nobody in their right mind will ever make it that long, or shorten [256] in widget_t so that this literal doesn't fit. In situations when we don't know the length of the source string, there are two cases: it is going into some buffer that is already allocated, or else we will be allocating one. In either situation, we must measure the length of the source string, to test whether it fits or to determine how much to allocate for it. In the case when the string doesn't fit into the target buffer, we cannot use strcpy, obviously, since it copies the entire string. We use some truncating-copying function, or we handle the situation in some other way (diagnose the problem and abort or whatever). In the case when we allocate, because we have calculated the length, we still should not use strcpy to finally copy the string. We should use memcpy, because memcpy doesn't wastefully examine every byte to see whether it is null. So the opportunities for a correct, non-wasteful use of strcpy are few.
joe_the_user 10y ago
Your claim does not really follow the standard meaning. Bit Rot is usually defined as all the ways that software can appear to stop serving it's function despite remaining the same, in the sense of being the same bits (or bytecode or interpreted code) run by the same computer. "the software does not actually decay, but rather suffers from a lack of being responsive and updated with respect to the changing environment in which it resides." See: https://en.wikipedia.org/wiki/Software_rot https://en.wikipedia.org/wiki/Software_rot Edit: Not being able to recreate or modify a given piece of software would an example of the bit of your tools/environment and this is one (but the only) source of bitrot in a piece of code.
codemac 10y ago
I think this is an interesting argument for something like scheme (r5rs or r7rs-small) where you could hypothetically implement an interpreter later for the same code base with much less trouble. Mind you, it probably won't perform well or do everything, but you can imagine it'd be easier than implementing an entire VM. Unless it's video games. People will write mountains of software to play an old video game.
specialist 10y ago
Digital entropy. Preserving order requires constant energy investment. Just an analogy, but I find it useful.
wwweston 10y ago
I think the big question with the storage space we've come into is... why don't we have all the toolchains/environments available? Why isn't having multiple versions of every dependency just part of how we do things now?

ArkyBeagle 10y ago

Through the miracle of virtual machines, this is much less so. VMs are the NAT of computer systems.

jussaskin 10y ago
Less so, I agree. But give it time - older VM image and container formats will probably rot as well.
- smilekzs 10y ago
  VM formats are easier to migrate than the actual software they run. On the other hand this is a valid concern for containers.
- specialist 10y ago
  Extending the digital entropy analogy: decay rate, half-lives.
jussaskin 10y ago
Even though the VM image and tooling may still be runnable, the world around it with which it must interact continues to evolve and can leave your software obsolete.
- ArkyBeagle 10y ago
  One for one thing, another for another.
  - jussaskin 10y ago
    Fair enough.
johannes1234321 10y ago
While for current software, which depends to at least some degree on remote services (cloud?) This won't help at all.
hueving 10y ago
If devs have to download a VM running an old OS with old tooling, the barrier to entry is getting quite high. I wouldn't touch an OSS project that made me do that, I would assume it was effectively dead.
- imtringued 10y ago
  It would be dead without the VM anyway.
nickpsecurity 10y ago
As jussaskin said, it can happen to them too. For example, VM/370 was among first virtualization schemes that could do all kinds of things PC/server virtualization bragged on later. Many key apps/OS's might be put in it. Yet, you'd be hard-pressed to run one of those with today's IT budgets if you couldn't afford a mainframe. Likewise, quite a lot of PC virtualization vendors came and went. The survivors occasionally have compatibility issues or corporations start going in different directions with less support of the older product. The product itself is often tied to a specific OS or HW combination that might go away. One can use virtualization to help future-proof apps. IBM's System/38 (later AS/400, iSeries, and IBM i) did this for decades. However, to be fully future-proof (esp for vendor level), the virtualization SW/HW solution itself needs to be immune to the problem. That means legally, easily-cloned HW with same for software and virtualization layer. Closest thing maybe NOVA microhypervisor on Loongson-style OSS CPU with x86 emulation if it's x86 apps. RISC-V w/ virtualization support otherwise. Guess what future-proof virtualization all the mainstream approaches aren't using, though? ;)

beat 10y ago

Some smart dude, don't remember who, said that every single line of code becomes technical debt the moment it is written.

bostik 10y ago
Legacy software is the code you wrote before lunch.[0] 0: http://www.russmiles.com/essais/dont-think-legacy-software-think-heritage http://www.russmiles.com/essais/dont-think-legacy-software-t...
- beat 10y ago
  That's not the one I was thinking of, but it's a similar sentiment.
- crucini 10y ago
  But strstr() doesn't seem rotten or "legacy" in a bad way.
  - xyzzyz 10y ago
    strcpy() does, though.
    - kazinator 10y ago
      What's wrong with strcpy? In a nutshell, we can only safely use it if we somehow know that the source string fits into the destination buffer. Those situations are few: basically, they involve fixed-length string literals being moved into buffers that are "obviously" larger. E.g. some widget_t object has a char name[256] field, and we initialize it by default with strcpy(new_widget->name, "<unnamed widget>"), or some bullshit like that. The literal is way shorter than 256 and nobody in their right mind will ever make it that long, or shorten [256] in widget_t so that this literal doesn't fit. In situations when we don't know the length of the source string, there are two cases: it is going into some buffer that is already allocated, or else we will be allocating one. In either situation, we must measure the length of the source string, to test whether it fits or to determine how much to allocate for it. In the case when the string doesn't fit into the target buffer, we cannot use strcpy, obviously, since it copies the entire string. We use some truncating-copying function, or we handle the situation in some other way (diagnose the problem and abort or whatever). In the case when we allocate, because we have calculated the length, we still should not use strcpy to finally copy the string. We should use memcpy, because memcpy doesn't wastefully examine every byte to see whether it is null. So the opportunities for a correct, non-wasteful use of strcpy are few.

joe_the_user 10y ago

Your claim does not really follow the standard meaning. Bit Rot is usually defined as all the ways that software can appear to stop serving it's function despite remaining the same, in the sense of being the same bits (or bytecode or interpreted code) run by the same computer. "the software does not actually decay, but rather suffers from a lack of being responsive and updated with respect to the changing environment in which it resides." See: https://en.wikipedia.org/wiki/Software_rot https://en.wikipedia.org/wiki/Software_rot Edit: Not being able to recreate or modify a given piece of software would an example of the bit of your tools/environment and this is one (but the only) source of bitrot in a piece of code.

codemac 10y ago

I think this is an interesting argument for something like scheme (r5rs or r7rs-small) where you could hypothetically implement an interpreter later for the same code base with much less trouble. Mind you, it probably won't perform well or do everything, but you can imagine it'd be easier than implementing an entire VM. Unless it's video games. People will write mountains of software to play an old video game.

specialist 10y ago

Digital entropy. Preserving order requires constant energy investment. Just an analogy, but I find it useful.

wwweston 10y ago

I think the big question with the storage space we've come into is... why don't we have all the toolchains/environments available? Why isn't having multiple versions of every dependency just part of how we do things now?