[ art / civ / cult / cyb / diy / drg / feels / layer / lit / λ / q / r / sci / sec / tech / w / zzz ] archive provided by lainchan.jp

lainchan archive - /tech/ - 35807



File: 1490197525151.png (96.35 KB, 211x300, 5450548.jpg)

No.35807

So guys, what is your opinion on backwards compatibility? How old should an app be to be expecterd to work reasonably on a new OS?

Now obviously you can make an app that uses 0 external API's and that app will work for a pretty long time on any system, but I want the context of this post to be in the OS design context.

Ideally many people would like all apps to work eternally. While that is a nice idea, we all know how it ends up in reality. You add layers upon layers of boat called compatibility layers. Your innovation becomes close to 0 as you have to watch out for old standards, even some old de facto standards.

On the other hand we have the speedsters who are living on the bleeding edge. While that is also certainly a nice thing, in an extreme example it would be very uncomfy if most of your apps broke every month or so.

Windows is certainly closer to one end of the scale, while Linux is closer to the other.

Windows is generally known for its great backwards compatibility. You can be optimistic that most apps written for Windows 95 will work on Windows 10. They may not, but they probably will. Even older apps have a reasonable chance of working. However, anyone who knows his way around a computer knows that this is often a double edged sword. As I said, those compatibility layers and the stagnancy of the win32 API often add boat and are a headache for MS when changing or adding new stuff. Not to mention old DOS relics like drive letters. Or having to maintain two or more technologies at the same time.

Then there's Linux which is closer to the other end of the scale. Even the boated Linux distro's are far less boated than Windows. However, aany app that is older than the current stable release of Debian is a dice roll if it will work. Debian oldstable maybe... However, any app that is older than 5 years it very probably won't work. And for any app that is i.e. 20 year old, your only hope is to find an image of a supported distro that is also 20 year old and run it in a VM, and if you need dependencies, have luck finding online repository archives.

So guys, what is your stance on this?

  No.35808

>>35807
Of course Linux varies by distro, but generally you won't be able to run anything older than 5 years on 90% of the distros.

  No.35824

>However, any app that is older than 5 years it very probably won't work
This is simply not true. Stuff that was programmed following C standards and that didn't rely on gnu auto* hell will very likely still work. Also the stuff that doesn't work is usually fairly simple to fix.

There is plenty of stuff in both linux and BSD that probably hasn't been updated in 5 years that is still used frequently. It was stuff that was programmed properly and completed in a way that was simple enough to verify there were no bugs. In fact this was one of the major benefits of the UNIX philosophy.

Stuff that has to be "updated" and "fixed" frequently is usually the mark of a bad program.

  No.35826

>>35824
In other words 90% of stuff is broken.

  No.35827

>>35824
>Stuff that has to be "updated" and "fixed" frequently is usually the mark of a bad program.

or people thought it was "simple enough to verify there were no bugs" but it turned out that simple != bug-free and they had to keep working at it.

  No.35828

File: 1490219242684.png (1.49 MB, 200x200, 1488336042193.gif)

>>35807
>You can be optimistic that most apps written for Windows 95 will work on Windows 10

When will this meme die out? Games made for 95 barely works on XP. Some XP games don't work on 10 either or need crack/patch.

>However, any app that is older than 5 years it very probably won't work.


Quake3 still works on Linux. Sound may need a fix, but anyway it's great.

  No.35830

>>35828
I guess DirectX is one thing where MS doesn't care about backwards compatibility. Try some boring accounting software though.
>Quake 3
Yeah because it has an active community of devs keeping it up to date.

  No.35843

>>35828
>>35830
or the fact that quake was designed for linux

  No.35844

Everything is up to glibc and other part of userspace. If nothing else works, you can use chroot for ancient software, but compatibility isn't a kernel related problem. Red Hat gives support for a decade anyway.

>>35843
Besset's port needed, so not really.

  No.35845

Yeah, but so far none of you answered the questions in the OP. Let's not be that much off topic.

  No.35847

I mean OP even said that he isn't interested about backwards compatibility from an app design perspective, yet that is most of what you are talking about.

  No.35848

>>35845
Maybe because OP's question doesn't make any sense in OSS world.

  No.36031

>>35828
The extent of troubleshooting I've had to do is "Compatibility Mode", and that in extremely rare situations.

Granted, I haven't tried a VAST ARRAY of games, but still…most regular "software" justwerks on newer Win versions

  No.36032

>>35848
Bitrot is an equally valid concern with open-source software.

Only difference is that you have the additional troubleshooting tool of "poke at the source code" available to you (which can be very powerful), but the question is still 100% relevant.

  No.36034

Those girls have really cute faces, do you have an image where their bodies are not fuarrrked up?

  No.36139

>>36034
>neurosuggesting there is anything wrong with their bodies.

No this is the original.