Jouvence

I never called it a strength; I simply don't care how fast Python is because I don't need to. Reasoning about what is going on under the hood with Python is just easier than Julia - if it needs to be fast, it's a fast external library being used.

This is really a minor issue stemming from the relative maturity of the languages - if Julia becomes more established I would hope usage of external libraries which don't offer a performance advantage (ie everything besides C and Fortran) eventually gets replaced with native packages to preserve the sanity of the users.

I disagree; consistency is the most important part of this. With Python, you know where you stand - performance comes from elsewhere. With Julia it might be internal, a C/Fortran library, or apparently other things now too.

Lustre is not aligned at all with your requirements, so forget that one.

Ceph is much more complex than Gluster, but also more capable.

Honestly unless you are dealing with hundreds of TB of storage (and therefore need multiple servers anyway), I expect the complexity any distributed file-system adds is going to be detrimental to uptime and stability more often than it provides extra resilience. Use a single box with ZFS if you can, and add Gluster on top only if it can't be avoided.

The UK civil service agrees.

> There is no award for Longest Suffering Person, just a life of wasted opportunities.

Welp, I know what I'm going to be lying here thinking about for the next several hours.

That's true, but then it is surely better to cut out the middle-man and just not use fossil fuels for static generation in the first place.

The energy needs which are hard to meet with renewables (aviation, other large-scale transport) are the same places where CCS is non-viable due to the efficiency hit.

The best we can do is decarbonise as quickly as possible, and live with the fallout of our failure to act this far - unless a significant use for captured CO2 is identified, atmospheric capture technology will always struggle with commercial viability.

The same thing happens (or at least, did happen last year) if you don't have the correct app permissions set when using Bitwarden on a mobile device.

Sandboxing is fine, but it sounds like Snaps/Flatpaks don't actually do it because that would be too hard - so what's the point?

I get that some packages do actually have sandboxing, but unless it is mandatory and enforced I feel like I'm better off avoiding the ecosystem entirely and dealing with app isolation myself, using containers or VMs.

UV and Superdome are custom hardware for huge NUMA boxes,so not a great comparison. ScaleMP is definitely valid though - a real shame it is stuck behind a license fee, would be interesting to experiment with.

The repeated references to Breton Woods/petrodollar reminds me of when Nigel Farage kept banging on about Habeas Corpus during the Brexit debates. To put it another way, this sounds like the lunatic ramblings of a homeless man hanging around a bus station.

What happens if a month from now, some major governments decide "the environmental impacts of bitcoin have become ludicrous, have yourselves an 80% transaction tax to cover the CO2 cost"?

Blame HP for repeatedly over-promising on that one.

HAMR/MAMR have been well understood and just on the road to commercial viability since at least 2014 (probably long before, but that is when I came across them). Toshiba being such a small percentage of the disk market makes their later deployment of this stuff easy to understand simply from the standpoint of having a smaller research budget.

A subsequent technology to expect is the separation of magnetic domains into small islands on a non-magnetic substrate, rather than the current approach of applying the magnetic field to regions of a continuous all-magnetic medium. This would be paired with heating, in what I only remember being described as "heated dot magnetic recording".

That was where the technical roadmap for HDDs ended last time I checked. After that I guess platter additions will carry us to the end of the decade.

Agreed. I would rather just have Nim evolve into a Python successor, alas that doesn't seem too likely.

Nonsense. People are allowed to make bad trades every second of every day without protection from the platform; but now they develop a conscience and save people from themselves? If this is true, RH and other platforms pulling smiliar stunts should be sued out of existence. Might not be a bad idea to significantly increase taxation on derivatives trading too.

As individuals, we (mostly) want companies building open source to thrive, particularly if they aren't behemoths of the industry. Ultimately though, efficiency matters more than sentiment. Companies rightly prefer a "good enough" product from a single source; even just avoiding a second enterprise agreement negotiation would make the AWS version worthwhile. Throwing unusual licenses into the mix, I guess new custom for Elastic Co is mostly going to be passed along by the other cloud providers feeding the anti-AWS prejudice within some customers.