Readit NewsHere you go. I had it uploaded after hearing from the magospietato's comment but then saw you talk about the same so I am pasting the same image link here as well
The trick? It's not statically linked, but dynamically linked. And it doesn't like with anything other than glibc, X11 ... and bdb.
At this point I think people just do not know how binary compatibility works at all. Or they refer to a different problem that I am not familiar with.
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...
I don't get it. Suppose this scenario:
- Instead of big formations, replace each wagon with an electric minibus. - Instead of stopping in all stations, each minibus stops in, lets say 3 or 4. - Each passenger checks into the bus dinamically assigned to their stop. - Minibuses can surpass each other.
You have less dwell time, each ride is reduced to one third of the time.
That is often the argument that i see but people forget a lot:
Fast charging if often 20 > 80% for 20min. If you want 80 to 100, its a lot less fast (think how your phone slows down).
While you can drive down to 5% of less, it can become a issue if you do not find a charger. When the summer vacation happened, a lot of north traffic goes south, over France ( and reverse).
What happened? People ended up waiting 15 a 25min at the chargers traffic jam in their cars. Then they charged up to 80% (because the stations had people to manage the flow), and needed to drive out (or pay more/fine).
This resulted that your range was already reduced by 20%. You ended up wasting 15 a 25 minutes stuck in your car. And with airco's on because its summer, so more battery drain. Aka, you did not really tank X km range, but X - waiting usage - 20% less limit.
Its always fun to compare a gasoline engine 5 min tank job, vs "not a issue, we need to stretch our legs", but when the reality of long trips that often coincide with vacation periodes... Yea, then the disadvantages of that statement come into play.
So the irony is that, a EV with a realistic 500km range, got hit with a 20% at chargers, then another hit from the waiting, o and you had no choice, it was fast charge or no charge.
I remember warning people to not see EVs based only on short trips or long "out of season" trips but also on those typical school vacation trips that many take. Ironic part, if you drove a hybrid, 5 min tank job for 100% fuel at the regular price.
If Meta can provide a reasonable time frame for compliance, the judge may also choose to let the existing limit on reparations stand rather than increase it, despite them not complying the day they hit the 5 million euro mark.
It's all up to what the judge deems reasonable to make Meta comply with the court's orders.
AMD literally can't make enough chips to satisfy demand because nVidia buys up all the fab capacity at TSMC.
We use singularity in the HPCs (like Leonardo, LUMI, Fugaku, NeSI NZ, Levante) but some devs and researchers have apptainer installed locally.
We found a timezone bug a few days ago in our Python code (matplotlib,xarray,etc.), but that didn't happen with apptainer.
As the code bases are still a bit similar, I could confirm apptainer fixed it but singularity ce was still affected by the bug -- singularity replaces the UTC timezone file by the user's timezone, Helsinki EEST in our case in LUMI HPC.
Why "better than expected"? I can run the entire userspace from Debian Etch on a kernel built two days ago... some kernel settings need to be changed (because of the old glibc! but it's not glibc's fault: it's the kernel who broke things), but it works.
> Now running stuff compiled on modern Ubuntu or RHEL 10 on the older OS, now that's a whole different story...
But this is a different problem, and no one makes promises here (not the kernel, not musl). So all the talk of statically linking with musl to get such type of compatibility is bullshit (at some point, you're going to hit a syscall/instruction/whatever that the newer musl does that the older kernel/hardware does not support).