4 ms·

"You can't continue to evolve Windows 95 by yourself. That's not true with each and every open-source product or project out there." This benefit is a lot more

"You can't continue to evolve Windows 95 by yourself. That's not true with each and every open-source product or project out there." This benefit is a lot more hypothetical than real. Practically speaking you can't continue to evolve Linux 1.2.0 (the version in the Win95 timeframe) yourself either. That's the fulltime job of hundreds of people. In both situations you're relying on those behind the project to evolve them if you want to use them as a foundation of other software. And as the parent poster mentioned, in the real world you're far less likely to have had to evolve your own software to deal with changes in the underlying OS if you developed for Windows. Win32 apps that use the APIs correctly still work 16 years later. Good luck getting your coff/old-glibc/old-UI-lib Linux app from '95 running on modern Linux...

rbanffy 15y ago
In the real world, you are far less likely to have to evolve something the size of the Linux kernel (1.2 was, IIRC, orders of magnitude smaller than Win95), but it's really easy to continue maintaining smaller codebases (I pointed out Zope version 2 as an example of software that was obsoleted by their original authors but that has been evolving in the hands of a community that felt it would be too much work to port their software to Zope v3). It also helps that so much of the mission-critical software you run on Linux is also open-source and can be easily recompiled. And you only need to recompile when the software can't run directly: I have Python code running in production that was written originally for Python 1.5.2. Oddly enough, lots of mission-critical applications are written in Python, Perl, PHP and various flavors of shell that run directly on more or less any *nix machine. The fact is that dead ends in free software are so rare and so easy to get out of, this situation only rarely arises. When it does, you can always weight your options and, sometimes, opt to go with a fork. Like I said, it has happened in the past.
- CWuestefeld 15y ago
  And you only need to recompile when the software can't run directly You've come around to actually making my argument! :) As I said, as long as I have my installer for .Net, the software I write for that platform will still work.
  - rbanffy 15y ago
    > You've come around to actually making my argument! :) Not even close. Unless you can recompile your .NET installer for a new computer architecture. If you can't, it's as dead as my Apple II word processor. I can run that Python code on SPARC box I have. Can you do the same with your .net installer? Again, since you seem not to understand, there is a difference between being able to install your jurassic .net framework on a current version of Windows and having its source code, something that would allow you not only to run it on current computers but also on almost any future computer that may possibly exist. Forever.
    - CWuestefeld 15y ago
      there is a difference between being able to install your jurassic .net framework on a current version of Windows and having its source code, something that would allow you not only to run it on current computers but also on almost any future computer that may possibly exist. Forever. You're simply assuming that someone will continue to port Python 2 ad infinitum. Granted there's no reason to suspect that they will not (Except that at some point, Python 3 really catches on, and decades down the road people stop caring about 2. At that point you could port an interpreter -- but you won't, which is my point). But there's also no reason to expect that I'll be unable to run my MS-based code. I mean, MS has ensured compatibility for, say, ancient Visual Basic code for forever. Real world experience shows us that there's no reason to be concerned about future compatibility. You're right that in principle it might be left behind, but experience shows us that this doesn't happen. The code I wrote 16 years ago for Win95 (and much earlier, for that matter) still runs. That's the philosophical argument. The practical argument is Mono. It's open source, so anything good you can say about FOSS applies equally to .Net. It has the backing of both open source and corporate muscle. (although I have to grant that Mono doesn't cover 100% of the platform, I can plan my system to stay within those bounds) Why is it that you assume that MS will dump backwards compatibility, but you're also willing to assume that someone will be interested in keeping and old FOSS platform alive (and that the tools to do so will still be functional)? It seems that in this argument, you want to have your cake and eat it, too.
      - 15y ago

rbanffy 15y ago

In the real world, you are far less likely to have to evolve something the size of the Linux kernel (1.2 was, IIRC, orders of magnitude smaller than Win95), but it's really easy to continue maintaining smaller codebases (I pointed out Zope version 2 as an example of software that was obsoleted by their original authors but that has been evolving in the hands of a community that felt it would be too much work to port their software to Zope v3). It also helps that so much of the mission-critical software you run on Linux is also open-source and can be easily recompiled. And you only need to recompile when the software can't run directly: I have Python code running in production that was written originally for Python 1.5.2. Oddly enough, lots of mission-critical applications are written in Python, Perl, PHP and various flavors of shell that run directly on more or less any *nix machine. The fact is that dead ends in free software are so rare and so easy to get out of, this situation only rarely arises. When it does, you can always weight your options and, sometimes, opt to go with a fork. Like I said, it has happened in the past.

CWuestefeld 15y ago
And you only need to recompile when the software can't run directly You've come around to actually making my argument! :) As I said, as long as I have my installer for .Net, the software I write for that platform will still work.
- rbanffy 15y ago
  > You've come around to actually making my argument! :) Not even close. Unless you can recompile your .NET installer for a new computer architecture. If you can't, it's as dead as my Apple II word processor. I can run that Python code on SPARC box I have. Can you do the same with your .net installer? Again, since you seem not to understand, there is a difference between being able to install your jurassic .net framework on a current version of Windows and having its source code, something that would allow you not only to run it on current computers but also on almost any future computer that may possibly exist. Forever.
  - CWuestefeld 15y ago
    there is a difference between being able to install your jurassic .net framework on a current version of Windows and having its source code, something that would allow you not only to run it on current computers but also on almost any future computer that may possibly exist. Forever. You're simply assuming that someone will continue to port Python 2 ad infinitum. Granted there's no reason to suspect that they will not (Except that at some point, Python 3 really catches on, and decades down the road people stop caring about 2. At that point you could port an interpreter -- but you won't, which is my point). But there's also no reason to expect that I'll be unable to run my MS-based code. I mean, MS has ensured compatibility for, say, ancient Visual Basic code for forever. Real world experience shows us that there's no reason to be concerned about future compatibility. You're right that in principle it might be left behind, but experience shows us that this doesn't happen. The code I wrote 16 years ago for Win95 (and much earlier, for that matter) still runs. That's the philosophical argument. The practical argument is Mono. It's open source, so anything good you can say about FOSS applies equally to .Net. It has the backing of both open source and corporate muscle. (although I have to grant that Mono doesn't cover 100% of the platform, I can plan my system to stay within those bounds) Why is it that you assume that MS will dump backwards compatibility, but you're also willing to assume that someone will be interested in keeping and old FOSS platform alive (and that the tools to do so will still be functional)? It seems that in this argument, you want to have your cake and eat it, too.
    - 15y ago