HN user

markus92

930 karma
Posts0
Comments338
View on HN
No posts found.

Better than expected as it's mixing userlands. We didn't put the entire /usr/lib of the old system in LD_LIBRARY_PATH but just some stuff like old libpng, libjpeg and the shebang. Taking an image of an old compute node still on RHEL 7 and then dumping it a container naturally worked, but at that point it's only the kernel interface you have to worry about, not different glibc, gtk, qt and that kind of stuff.

We (small HPC system) just upgraded our OS from RHEL 7 to RHEL 9. Most user apps are dynamically linked, too.

You don't want to believe how many old binaries broke. Lot of ABI upgrades like libpng, ncurses, heck even stuff like readline and libtiff all changed just enough for linker errors to occur.

Ironically all the statically compiled stuff was fine. Some small things like you mention only linking to glibc and X11 was fine too. Funnily enough grabbing some old .so files from the RHEL 7 install and dumping them into LD_LIBRARY_PATH also worked better than expected.

But yeah, now that I'm writing this out, glibc was never the problem in terms of forwards compatibility. Now running stuff compiled on modern Ubuntu or RHEL 10 on the older OS, now that's a whole different story...

Your capacity drops dramatically, by at least an order of magnitude if not more. The Jubilee line can do 30 trains per hour, 875 people per train is 26250 people per hour. Say an average minibus can hold 26 people, you'll literally need a thousand busses an hour to move everyone. And yes it all runs at capacity especially during rush hour.

Languages need a lot of upkeep if you want to keep speaking them fluently. On the other hand, just like muscle, once you've had it it's a lot easier to get back than having to put it on for the first time.

We run a ton of legacy cruft that's still on Java 8. Extended support is available until at least 2030. It's rock solid for us and migration is not easy unfortunately, even Java 11 is a challenge.

There were similar issues with Bunq in The Netherlands. You (or a scammer) could turn a savings account into a checking account pretty much immediately with one code, and then drain it in the matter of minutes. Lot of people lost their life savings over it and of course no one you could reach out to to rectify the situation. All other Dutch banks have waiting periods for this. E.g. ING has a four hour waiting period to increase your transaction limit, just so it buys time when potential scams are happening.

Of course it's easy to blame the user for this as they provide codes and stuff, but when one bank has this issue so much more than it should have given its amount of customers, something else is going on.