Hacker News Reader

Comment by sametmax | Hacker News Reader

No that's just how IT works.

Your games don't work in windows XP anymore. Actually, your USB3 mouse doesn't work on windows 7 out of the box.

Centos have LTS, but still EOL.

Ubuntu init system was changed to upstart. Then to systemd. Also gnome, then unity, then with new menu/notif/systray semantics, then back to gnome (but shell), and soon wayland. It breaks a lot of things.

Firefox new addons don't work with some addons from last year.

NodeJS had 3 incompatible forks in it's short life.

Twitter and Facebook API breaks every sunday.

JS frameworks are just madness.

Python break compat, ONCE.

Once since 1990.

Also gave 10 years to migrate.

In our industry, that's not bad at all.

And the community hold. We worked. We wrote tools, doc, blog posts. We were there all the way. We have incredible libs like python-future to help.

And if any of that is not enough, well, Anaconda Continuum will be happy to do business with you.

It's how it is.

View on HN

> Your games don't work in windows XP anymore.

In fact I can play EarthSiege 2, a game from the 3.11/Win95 era, just fine on Win7 x64 with the only things not working being joystick input (I guess it does some shenanigans with the MIDI/joystick port in addition to using the windows joystick API) and the pause screen which shows your vehicle spinning around spins too fast (probably because its speed is tethered to CPU sppeed).

Microsoft takes, with the exception of drivers, a lot of effort to keep backwards compatibility. And that is why people like it, in contrast to Linux where "Things break" is the norm and even in OS X it's not unheard of. Oh, and also why big enterprises stay as far away as humanly possible from anything NodeJS or more modern than PHP and Java.

Enterprises want and need stability first.

Whenever this comes up I feel it is worth pointing out that Linux's "Things break" approach is a problem exclusive to the userland tooling built up around the kernel. Linus takes a very hardline stance against breaking kernel ABI compatibility (except for drivers), but pretty much every piece of software outside of that, including GLIBC, thinks it's totally ok to break things all the time.

It's really very sad that the Linux community never adopted Linus's view.

Because they are entirely different things. Breaking the kernel ABI doesn't just break a few packages for a popular language, it breaks the entire ecosystem. More importantly there's literally no reason to break compatibility in the kernel. There are perfectly valid reasons to break compatibility in programming languages.

Apples and oranges comparison.

Even the kernel occasionally breaks interfaces. Case in point, FUTEX_FD was introduced in 2.6.0 and retired in 2.6.26 [1].

I don't think anyone working on glibc is intent on breaking user space. Sometimes it's just the most pragmatic solution.

[1] http://man7.org/linux/man-pages/man2/futex.2.html

We can trade anecdotes on which games age well on which OSes all day.

https://en.wikipedia.org/wiki/Chaos_League

Released in 2004, you can't play on anything but Win XP because of Starforce DRM that didn't bother to patch for future compatibility.

I'm sure there is a community created solution for this. (a nice description of a "crack")

Yes and your Python 2.x code will still run after 2020. But going the other way - new programs might not run on older distro releases, which is what GP said.

Meanwhile I routinely use Lisp written before I was born (in 1986) that works out of the box in 2018. I’ve used Java packages (recently) from 1999. My company still uses python/pypy 2.7 and we see no compelling reason to upgrade. If there is any sort of upgrade, it will be off of python.

When, oh when will we ever finally unlearn "worse is better?" It's hard enough writing good code without having to fight your tooling (non-orthogonal, non-homoiconic, non-malleable, non-backwards-compatible languages, some with header files propagating changes upwards and breaking user code, and some with fascist type systems causing combinatorial explosions of containers and factories, ugh)

Python broke compatibility a lot more than once. Python 3.5 and Python 3.6 are not compatible, for example. There are even cases where code written for an older version of Python 3 will not work on a newer version of Python 3. For example, see PEP 479.

2.X would still be included as an optional package, correct? I couldn’t determine that from the link, but it seems like RedHat’s practice. Or, they could install it from source.

If so, 2.X users still have two years or so to migrate. That’s plenty of time in my opinion, even when all of your code is 2.X. There’s even a library for it.[1]

[1] https://docs.python.org/2/library/2to3.html

2to3 is a bad and outdated tool, please don't recommend it. You want http://python-future.org/ .

Thanks for posting this, I didn't know about python-future.

> 2.X would still be included as an optional package, correct?

I wouldn't bet on a RedHat provided 2.7 package. if they provide it, they will be stuck maintaining it, and their long term support contracts are very long term.

On the python side - From 2020-01-01 no commits will land on the 2.7 branch. RH is still supporting RHEL 4, which was released in 2005, and supported 3 from 2003 -> 2014, which (if they keep a similar timescale for RHEL 8) could cause them to try and maintain a working build / test / development system for py27 for an extra 10 years.

"And if any of that is not enough, well, Anaconda Continuum will be happy to do business with you."

Yes, this is a key point that seems to be forgotten. The Python development team will end their support on 1st January 2020, but there are other providers with Python expertise who will almost certainly pick up the commercial opportunity, e.g. ActiveState, and possibly even Red Hat with a separate product.

This is not the end of Python 2, it's going to be a transition to a different support model. Commercial users either pay to move up, pay to rewrite the Python code with something else, or pay for a super long-life version of Python 2.

The awkward part may be academic research, where there's a probably a lot of Python 2 code that has no maintenance budget. I would not be surprised if a project appears to build no-support versions of Python 2 with essential fixes after 2020.

Reply on news.ycombinator.com