Spacing a fire bomb is indeed not ideal. Perhaps venting the chute to the outside atmosphere would be sufficient. The chute would have to be constructed in a way to resist the high temperatures but that would not be hard. And we can still call it a chute if we preserve the ability to space items in addition to just venting. Having a safe place within an airplane to put items that are either igniting or perhaps just emitting toxic fumes does not sound like a bad idea.

As the market for HDD continues to shrink, the $/GB compared to SSDs will increase due to reduced incentives for manufacturers to spend money on R&D. HDD manufacturers will not improve their products at the same rate they have in the past. It requires too great an investment to be fighting for an ever decreasing market segment. So forget about forever - the value proposition of SSDs is only going to be accelerating.

Increased cost was expected and acceptable. One of the big reasons for having at least one plant in the US is due to US military requirements where all parts have to be manufactured domestically. There will be some exceptions - but for the most part this rule applies. If TSMC wants a piece of this then they have to manufacture at least some parts in the US.

But that is the issue - the 3D cache version has lower thermal limits. Not just the CPU - but the cache and CPU combined has lower thermal limits then a non-3D part. This works out great for efficiency, but not clock speeds. Turns out SRAM has very low power draw.

I can only assume that the additional cache between the CPU die and the IHS adds a non-trivial amount of thermal resistance. And with a reduced ability to shed heat, the CPU die will end up running hotter then a normal die given IHS at the same temperature. And with a hotter die, you get more heat being transferred through the interposer and into the motherboard. Hence my solution of attempting to transfer some heat from the interposer into the IHS / CPU cooling system.

Thanks, this sounds reasonable. But would they have really made this compromise if they knew it was going to impose a power limit? Adding requirements to a design for the first time will often cause issues. But this is supposed to be a second gen design - the requirements are not new. They should have observed these issues with their first gen parts so it is not like it was unexpected. I thought their second gen parts would solve this issue - but apparently not.

AMD did apparently increase the voltage range that the cache could operate on. The cache power rail was tied to the CPU core voltage which limited the max voltage on the original Zen3D CPU cores. So perhaps solving one problem made another more significant.

AMD should at least put some heat bridges between the interposer and the package cover. This would assist with pulling heat out of the interposer and putting it into the CPU cooler. The motherboard is surprisingly good at dissipating heat - but it is nothing compared to a CPU cooler.

I was also thinking of that, but they could just run vias through the cache. You might loose 5-10% of the cache but you can always just make the die a bit larger. The additional trace length would be negligible so there wouldn't be any signal integrity issues. So there must be something else...

There has to be a reason why AMD put the cache on top of the CPU die. My initial thought is to simply put the cache between the CPU die and the interposer. This would allow the CPU die to be as close to the cooler as possible. It should allow for the same sort of power draw / heat generation as with there non-3D parts.

But the engineers at AMD are not idiots and they would have certainly already thought of this. But it does beg the question as to why. Anyone have a good guess as to why?

Zig has null-terminated arrays of bytes for backwards compatibility with C. Native strings are structures with an array and a length. So in some ways it is more like Pascal.

The idea is to make it easy to write functions that do not overflow the array. When you do not have to scan for the string length it becomes a lot easier to write these functions in a safe manner.

I tried working with Zig for a while and found it to be initially quite bothersome. The documentation is actually there in one place or another - but it is not well organized and easy to find. That being said, after a while it started to grow on me and I can see it being safer and more productive then C. Sadly, support for ARM32 kind of sucks at the moment due to requiring the latest LLVM so I never ended up using it. But it is worth trying out.

As long as the company in question (it is not just VW) verifies the caller, an immediate response is acceptable. So the request has to pass through an official channel, be it phone, email, etc. The nature / reason for the request is irrelevant - the emergency personal determine if it is warranted and not the company in question.

So I am in agreement with what you have stated. However, I would add to your point that in addition to a report being generated, all information regarding this request should be forwarded to the owner of the vehicle. Then the owner can pursue legal proceedings against whichever entity initiated the request should the owner feel it is required.

Immediately provide information upon request - absolutely. But it should never be secret and those making the request will open themselves up to legal actions. In this example the owner would presumably give verbal approval which would be captured on a body cam thereby allowing the police to work without fear of legal actions.

Looks like the newest heat pumps can burn natural gas to assist in improving efficiency. If the waste heat is discarded in the house then this could have a big impact on cold weather operations. Details at energy.gov.

It is an interesting idea. In place of using just electricity to operate the cycle, natural gas (or any other heat source) plays a role to minimize the amount of electricity required. And by making the heat pump more efficient it becomes reasonable to operate at lower temperatures.

Apple provides an official VM framework which UTM can make use of. In theory, using the Apple VM framework will be the way to go in the long run.

I tried out UTM with the Apple VM framework and found that it worked fine. There are limitations around window scaling when using the Apple VM framework. It does not like to resize automatically - resolutions must be set manually. At least with Linux, I never tried Windows. On the plus side, you can make use of Rosetta from your Linux VM. I was quite excited until I realized that it only supports 64bit - 32bit binaries for x86 can not run. I also had issues with finding compatible libraries - but I believe that was just because they were not installed by default on the ARM Linux distro. It was a while ago so someone has probably solved this issue.

So revise how things are priced. This "real problem with solar and EVs" is a non-issue. It will be fixed once people decide to fix it - it is a political issue and not a technical one.

So you are correct in identifying the issue but the severity is being exaggerated.

Starlink still has to connect to a ground station which would be located in China. This does nothing to get around Chinese content laws.

If it implements LPDDR memory then for certain it will only support one per machine. Regular DDR memory operates on a memory bus where you can have two devices share a single bus. But with LPDDR memory you can only have one device. And since this will be designed around LPDDR memory - yes, only one per machine.

FYI, this is why some previous MacBook Pros (Intel) only went up to 16 Gig of RAM while other Windows laptops would go to 32. Apple wanted the power savings gained by using LPDDR memory. But using LPDDR memory also cuts the maximum allowed memory in half. I'm sure users loved the long battery life but they were sure pissed about the 16GB limit.

I doubt the chips Apple orders will only be produced in one factory. So they could be produced in the Arizona factory - in addition to several other factories. But at the very least, prototype production could occur in Arizona. It would keep prototype parts more secure and make for faster transport to California. But the real purpose for the Arizona factory must be military components as they typically come with a "must be made in America" requirement.