|
|
Subscribe / Log in / New account

Python discusses deprecations

Python discusses deprecations

Posted Dec 9, 2021 19:48 UTC (Thu) by dvdeug (guest, #10998)
In reply to: Python discusses deprecations by NYKevin
Parent article: Python discusses deprecations

Linux has been more focused on source-code compatibility than binary compatibility, and has never natively run on 16-bit systems. IBM System/360 computers were sold between 1965 and 1978, and the code written for those systems still runs on the IBM z15 system released in 2019.

More to the point, so what? The fact is that a working program in use stopped working, frustrating the user, and forcing them to find a replacement. Why does whether Debian does the same thing matter?


to post comments

Python discusses deprecations

Posted Dec 9, 2021 23:02 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (2 responses)

> Linux has been more focused on source-code compatibility than binary compatibility,

The average user does not know how to operate a compiler, so from their perspective, source compatibility is entirely worthless.

> More to the point, so what? The fact is that a working program in use stopped working, frustrating the user, and forcing them to find a replacement. Why does whether Debian does the same thing matter?

So what to your so what. The user wanted to keep using the same software indefinitely, but maintaining existing software (fixing security vulnerabilities, supporting new hardware, etc.) is expensive. Somebody has to pay for that work, and right now, it would seem that nobody is willing to do so, including the user in question. So why should I care if their software stopped working abruptly? More bluntly, what's in it for me?

Python discusses deprecations

Posted Dec 10, 2021 3:32 UTC (Fri) by dvdeug (guest, #10998) [Link] (1 responses)

> The average user does not know how to operate a compiler, so from their perspective, source compatibility is entirely worthless.

Which is a reason the average user doesn't use Linux. In any case, it's not entirely worthless; learning "./configure; make; make install" isn't that hard, and it makes it much easier to find someone who can make the program work.

> So why should I care if their software stopped working abruptly? More bluntly, what's in it for me?

So much for even dreams of "the year of Linux on the desktop". So much for dreams of free software taking over. Such an attitude will even drive away geek users; there's at least one user commenting on this article pointing out this is why they're using Go instead of Python, and comments on this thread have said that Python 2 was ANSI C and thus should still compile; surely the fact that ANSI C was stable and universal was part of the reason Python 2 was written in it.

At a more values-based level, this feels like digital vandalism. Instead of making a world where things work and someone can use a tool until something better comes along, it's making a world where planned obsolescence is built in, where code has to be rewritten regularly, not because it wasn't good, but because people decided to make some arbitrary changes, where everyone has to learn everything anew on a regular basis.

Python discusses deprecations

Posted Dec 10, 2021 4:35 UTC (Fri) by NYKevin (subscriber, #129325) [Link]

> So much for even dreams of "the year of Linux on the desktop". So much for dreams of free software taking over.

That's capitalism.

> Such an attitude will even drive away geek users; there's at least one user commenting on this article pointing out this is why they're using Go instead of Python,

Exactly. Vote with your wallet. Don't complain about X failing to meet your needs when you could just use Y instead of X.

> comments on this thread have said that Python 2 was ANSI C and thus should still compile; surely the fact that ANSI C was stable and universal was part of the reason Python 2 was written in it.

Sounds to me like Guido was already practicing this even back then.

> At a more values-based level, this feels like digital vandalism.

Nothing has been destroyed, at least on the FOSS side of things. All of the code still exists, is still publicly accessible, and can still be used, if you can only get it to run. Characterizing that as "vandalism" is ridiculous. If you can't get the code to run, that's your problem. This is the social contract on which all FOSS code has been founded ever since the FSF stuck a "THERE IS NO WARRANTY" disclaimer on the GPL.

> where code has to be rewritten regularly, not because it wasn't good, but because people decided to make some arbitrary changes, where everyone has to learn everything anew on a regular basis.

Unfortunately, we live in a society. If those changes were completely worthless, they would hopefully not be made. In most cases, they at least accomplish *something,* even if you personally think that thing is not worthwhile. You're always free to fork and revert, if you really think it's bad enough.

Python discusses deprecations

Posted Dec 15, 2021 18:03 UTC (Wed) by anton (subscriber, #25547) [Link]

Linux has been more focused on source-code compatibility than binary compatibility
It seems to me that Linux (the kernel) focusses on binary compatibility for the most part. Given that it does not include a compiler, there is no way for it to provide source-code compatibility.

That said, the Linux developers committed digital vandalism on a.out binaries on the switch to Linux-5.1, based on the excuse that core dumping of running a.out binaries was broken and nobody volunteered to fix it. Given that many systems (mine included) have a core file size limit of 0, core dumping is not an important functionality, certainly much less important than running a binary. Siegfried Pammer heroically implemented a partial user-space solution for this problem, but it's surprisingly hard to actually do that and the result still does not work as well as the kernel did before Linux-5.1.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds