If Apple's RAM is on the cpu die, then they aren't beholden to any RAM supplier! As long as they have fab slots to make their M cpus, they have RAM too. So if demand for RAM is hurting their ability to get fabs to make their M series CPUs, then they are hurting way more than just for high RAM prices.

Adoption is a function of existing adoption and existing availability of resources.

Extremely good OS' and truly amazing computers have failed, not because they were too expensive or had issues, but because they were perceived to be unpopular OR simply lacked enough software that could run on them.

Extremely bad OS' and truly awful computers have succeeded for the opposite reason.

Linux has an extremely good architecture, at least for machines that are mostly operating with CPUs. When most of the work is done by the GPU, it's less obvious that Linux provides the necessary mechanisms to manage resources and abstract away the hardware specifics. That doesn't mean I expect Linux to start fading, but I don't think a centralised OS is necessarily where things will go. However, the reason it hasn't done better so far is simply because potential users and potential software houses had a negative view of it (even though actual users were almost invariably loving the system).

Windows is crashing now not because it is a slow, bug-ridden piece of spyware (which it is, but users have never cared about that in the past), but because it is perceived in increasingly negative light.

They can get vertical samples from space and the ground. What they can't get from space or the ground is how the internals of a system evolve.

The problem with "models" in the abstract is that there are a lot of them and some of the time the thing you want is to know the same point relative to the system and not to the mudball.

Lots of people have gut feelings about AI, positive or negative.

Most of the AI research I can see people doing is focusing on single-element problems (such as finding counter-examples to a mathematics hypothesis) or solving very simple engineering systems (at most a dozen or so components). Most of the benchmarks are even simpler (write a short story at the level generally asked in English classes of primary school kids).

As a result, I think that people have developed either a very cynical outlook or a very optimistic look. Neither of these is entirely realistic, for the simple reason that no actual useful problem fits any of those descriptions.

Digging much deeper, I'm finding that when problems get into the hundreds or thousands of elements, even ChatGPT Sol 5.6 and Claude Fable 5 struggle badly to keep track of accurate relationships, let alone any level of detail.

If you want to solve a relatively simple coupled system (whether to use solar panels or direct solar heating, and which side of the house to place them), I'm sure AI is fine. If you want AI to write a five hundred word story detailing a conversation between Kim Possible, Rufus, and a smoked herring, I'm sure it could cope. Just.

If you want it to do anything hard enough that a human could do with an assistant, the tests I've been using (meaningful rather than synthetic problems) suggest you've developed a fantastically expensive blue smoke generator. We are going to need to see the inference engines developed for previous generations of AI, and the reasoners developed for the semantic web, and perhaps tools that haven't begun to be imagined yet, before AI can do anything non-trivial.

This is true. And if you don't use any Google services with an alternate firmware, you still can.

Developer verification is enforced through Google Play Services, even for apps that are installed from other sources. It's a pretty neat way of allowing third-party app stores while still guaranteeing their cut.

Google is not allowed to do business at all in sanctioned nations, so devs there can't even access Google Play Services in the first place, which is where the developer verification takes places. No Google services, no Google Play, no Play Services, no developer verification. So there's no "exemption" at play. Surely Google never said any such thing as the headline and summary imply. By this logic, LineageOS or Android OSP without gapps installed is exempted from Google's developer verification program too.

Meant to say "interstate overpasses."

This German bridge costs millions of dollars too. And the speed with which it will be installed belies the time and money spent building it prefab, and in preparation for the install. Definitely an engineering feat to do the actual building in just six months, and install in four days without major disruptions.

The US builds interstate bridges in a similar way, to minimize disruption. Certainly costs more than traditional, in-place bridge construction.

I'm not sure they do work, though. All they seem to do is cement an unfriendly regime's power and make us out to be enemies in the eyes of their people.

A balloon is not static, it moves with the atmospheric system it is in. Ergo, it tells you how that system evolves. A drone cannot do this.

A drone can stay put, relative to the ground, telling you how a location's atmosphere evolves. A balloon cannot do this.

These are solving completely different types of problem.

You could, of course, construct a hybrid, as balloons are traditionally single-shot. If a balloon carries the measurement gear and a drone capable of carrying that same gear PLUS a deflated balloon, then you can have something that operates as a balloon until it reaches some pre-set location, whereupon the balloon's gas is released and the drone flies the ensemble to a collection point.

It obviously gives us guarantees in terms of what the source will do and what the compiled code should need.

These do not provide memory safety, so memory bugs would not be solved by these. They will find unexpected behavioural issues, though.

The precondition and postcondition statements are not cunningly-disguised assert statements because they're not asserted at runtime. They're enforced at static check and/or compile time.

The policy hints mean that if the kernel is doing something you're not expecting, you find this when testing the code. Equally, though, it means that users cannot cause the software to venture into realms unknown through many of the usual attack vectors because those will require permissions that aren't there.

AI tied itself in knots trying to explain how that happened, but I figured that we flew far enough north that at 35,000 feet we flew briefly where we could just barely see the midnight sun (the "sunrise"), and then flew back south into the dark, where eventually the sun caught up to us. I thought the experience was kind of cool.

I'm not sure how it happened exactly but I experienced a double sunrise on a June flight from Tel Aviv to JFK. Flight departed at or 4 in the morning. Flew northwest and saw the sunrise then outran it and it was dark again. By the time we were ready to land in NY the sun was just rising again.