You'll have to compile from source, or update your distro to a maintained version. Ubuntu 22.04 ships glibc 2.35, and so Mint 21 should work.

Mostly commenting because while this isn't really a tech support channel, being able to identify glibc version mismatch errors comes up extremely often, even in this day and age.

1. Built to last only 50 years to save on materials (as the other commenter noted).

2. Built over literally the widest possible part of the Hudson because the governor got in a pissing contest with the Port Authority and wanted all the tolls to go to the state, which wouldn't have been the case had it been built like 2 miles south where the river is narrower.

3. Designed with zero redundancy, such that a "critical fracture could make the bridge fail completely because its supports couldn’t transfer the structure’s load to other supports." [0]

So yeah if we're being real, 50 years was quite optimistic.

The new Tappan Zee is apparently supposed to last 100 years, though given the incidents with substandard materials being used, as well as ever-increasing traffic, who knows.

That said, driving over a bridge 10 years past its planned EOL and being able to look down directly to the water through gaps in the concrete was always a nice feature though -- who needs coffee when you've got that to get your heart rate up!

[0]: https://en.wikipedia.org/wiki/Tappan_Zee_Bridge_(1955%E2%80%...

1. Because global objects are refcounted, CoW effectively isn't a thing on Linux. They did add a way to avoid this [0], but you have to manually call it once your main imports are done.

2. On Mac, turns out a lot of the system libs aren't actually fork-safe [1]. Since these get imported inadvertently all the time, Python on Mac actually uses `spawn` [2] -- so it's roughly as slow as on Windows.

I haven't worked in Python in a couple years, but handling concurrency while supporting the major OSes was a goddamn mess and a half.

[0]: https://docs.python.org/3.12/library/gc.html#gc.freeze

[1]: https://bugs.python.org/issue33725

[2]: https://docs.python.org/3.12/library/multiprocessing.html#co...

It's definitely not the densest design possible, but it certainly seemed to let them fit a lot of fairly spacious 1-2 BRs in not a lot of space back in the early 20th c., and the height can scale up pretty well (though the elevator probably becomes at least a soft requirement above 4-5 floors).

And if you're on a 64-bit system, you'll want to make sure it finds the 32-bit libc and libm binaries (see [1]). On Arch, the following worked for me:

    ./build/movcc -L/usr/lib32 test.c

[1]: https://github.com/xoreaxeaxeax/movfuscator/issues/39

From what I've heard, insurance companies are actually kinda souring on the business because it's incredibly bad from an actuarial perspective: many of those targeted are SMBs (i.e. they're not paying the kind of premiums that would make it worthwhile), but even for large corps as time passes the odds of a ransom event approach 1. I mean, can anyone think of a large non-tech enterprise that doesn't have that doesn't have that one load-bearing Windows Server 2008 machine in a closet?

So to an extent, this seemingly represents the industry collectively declaring that even massive monthly insurance premiums are insufficient for companies to get their security posture together, and so they're trying to cut it off at the source by making ransomware as an endeavor unprofitable.

I think it's a fair assumption to say that the author is aware of what Arcs are and how they work. I believe their point is more so that because of how async works in Rust, users have to reach for Arc over normal RAII far more often than in sync code. So at a certain point, if you have a program where 90% of objects are refcounted, you might as well use a tracing GC and not have the overhead of many small heap allocations/frees plus atomic ops.

Perhaps there are in fact ways around Arc-ing things for the author's use cases. But in my (limited) experience with Rust async I've definitely run into things like this, and plenty of example code out there seems to do the same thing [1].

For what it's worth, I've definitely wondered whether a real tracing GC (e.g. [2]) could meaningfully speed up many common async applications like HTTP servers. I'd assume that other async use cases like embedded state machines would likely have pretty different performance characteristics, though.

[0] https://en.wikipedia.org/wiki/Garbage_collection_(computer_s...

[1] https://tokio.rs/tokio/tutorial/shared-state

[2] https://manishearth.github.io/blog/2015/09/01/designing-a-gc...

    curl -L -H 'accept: application/activity+json' 'https://mastodon.social/users/Gargron/statuses/18614983'

The plant definitely had issues -- some due to age (construction started in 1956!), some due to mismanagement, and some due to dumb regulations [0]. My chem class went there on a field trip in high school, and the guy giving the tour definitely gave off "engineer who has been overruled by management in very dumb ways" vibes while explaining that their waste silos were almost full because they weren't allowed to transport the spent rods across state lines so that they could be recycled back into fissile materials.

As an aside, the control rooms had a real "retro-futurism" look. Lots of manual dials and brightly-colored plastics [1]. Gene Roddenberry eat your heart out, etc.

[0]: https://en.wikipedia.org/wiki/Indian_Point_Energy_Center#Saf...

[1]: https://www.lohud.com/story/opinion/2016/02/12/indian-point-...

If the popular consensus is that this is something that should be left up to the states, then federal legislation to that effect should be passed. The status quo is clearly farcical.

That said, my state has technically issued licenses for exactly two (2) dispensaries, and yet there's one on every corner. All of which accept card. So I have my doubts as to whether this is anything other than CYA by Mastercard.

I remember reading that clang was finally shipping std as a module, albeit experimentally. So this ought to be an interesting couple of years for C++ -- though I suppose it remains to be seen to what degree the ecosystem will keep up with all these changes vs using headers/exceptions/the traditional ways of doing things.

Under the Howey test (a security is "a contract, transaction or scheme whereby a person invests his money in a common enterprise and is led to expect profits solely from the efforts of the promoter or a third party") this is pretty clearly an unregistered security IMO. Whereas e.g. using Gemini solely to exchange N USD for M BTC with the customer retaining ownership the whole time is probably not. So had the Winklevi stuck to being a traditional exchange, they could have avoided this specific issue.

Of course, the SEC seems to believe that many shitcoins are also securities ("Buy this token for a % share in our company! Totally not equity!" is... not a convincing argument). But that's not what the complaint you linked is actually about.

As an illustrative example, consider the fancy pigeon (see [0] for some pics). One of Darwin's original areas of study was to prove that these birds, many of which have cool-looking but incredibly maladaptive traits, were actually the same species as the pigeons you'd see on a London street. Prior to that, the scientific consensus was that these were fully distinct species -- i.e. the artificial selection happened so long ago that it was lost to time. Given some breeds have trouble even eating (e.g. look at the beak on this guy [1]), I think it's a pretty safe assumption that this breeding did not happen without careful human intervention.

That's not to say that the kind/degree of artificial selection we see in industrial agriculture isn't worlds away from older forms. Once you've got the basics of evolution and the scale of capitalist production, you're starting down the road to the current world of 100 pound antibiotic-riddled chickens in rows of 10000 cages. But humans have been selectively breeding animals for food, utility, or just because we kinda felt like it since time immemorial.

[0] https://en.wikipedia.org/wiki/Fancy_pigeon

[1] https://en.wikipedia.org/wiki/Oriental_Frill

It's true that he won 67% of the vote in the actual election [0]. But this was effectively a foregone conclusion -- his Republican opponent, Curtis Sliwa, was a man best known for owning 15 cats [1] and faking his own kidnapping [2].

The "real" election was the primary -- notably the first ever election in the city to make use of ranked-choice voting. Wiley and Garcia, the runners-up in the first round, effectively split the "progressive" vote 50/50. Morales was a significant progressive up until a few weeks before the election, at which time her campaign staff walked out citing poor working conditions, effectively ending her campaign.

Looking at the final-round vote tally [3], it was 404,513 for Adams and 397,316 for Garcia -- a difference of just 7,197. He won, but just by the skin of his teeth. The population of NYC in 2021 was 8,468,000, with 4,992,792 registered to vote [4]. That doesn't exactly paint the picture of a resounding victory and a mandate to crack down on ne'er-do-wells that the Post would have you believe. It starts to look a bit more like a perceived centrist barely squeaking through by merit of being the best-known/least-objectionable candidate.

This of course speaks to OP's point: do the public really crave a paternalistic figure who will come and "crack down on crime" (i.e. sign off on more... questionable overtime pay for the NYPD) or is there, for some reason, undue weight given to the narrative that just by happenstance sounds identical to SBA/PBA talking points?

[0] https://www.cnn.com/election/2021/results/new-york-city/mayo...

[1] https://nypost.com/2021/06/23/an-inside-look-into-curtis-sli...

[2] https://www.latimes.com/archives/la-xpm-1992-11-25-mn-1060-s...

[3] https://www.nytimes.com/interactive/2021/06/22/us/elections/...

[4] https://vote.nyc/sites/default/files/pdf/vote/2021/county_fe...

[0]: https://github.com/pyston/pyston/blob/1d65d4831912179c26bb27...

> After a fruitful exchange with GitHub support staff, I was able to confirm the following (quoting with their permission):

>> I checked with our team and they confirmed that we can expect the checksums for repository release archives, found at /archive/refs/tags/$tag, to be stable going forward. That cannot be said, however, for repository code download archives found at archive/v6.0.4.

>> It's totally understandable that users have come to expect a stable and consistent checksum value for these archives, which would be the case most of the time. However, it is not meant to be reliable or a way to distribute software releases and nothing in the software stack is made to try to produce consistent archives. This is no different from creating a tarball locally and trying verify it with the hash of the tarball someone created on their own machine.

>> If you had only a tag with no associated release, you should still expect to have a consistent checksum for the archives at /archive/refs/tags/$tag.

> In summary: It is safe to reference archives of any kind via the /refs/tags endpoint, everything else enjoys no guarantees.

(posted 4 Feb 2022)

https://github.com/bazel-contrib/SIG-rules-authors/issues/11...

There's even a million linked PRs and issues where people went around and specifically updated their code to point to the URLs that were, nominally, stable.

I suspect that the GH employee who made these comments just misunderstood how these archives were being generated, or the behavior was depending on some internal implementation detail that got wiped away at some point. But if an employee at a big-ass company publicly says "yeah that's supported" to employees at another big-ass company, people are gonna take it as somewhat official.