It's worth noting this squeeze from Google only applies to Android if you have Google Play Services installed. With absolute rubbish like this coming from Google, secure systems like GrapheneOS are going to be the only way forward, as I see it. GrapheneOS implements secure, isolated sandboxes for Apps and App Stores to run in.

Unless I'm mistaken this allows you to run a normal Google Play app in one sandbox where it meets all of Google's silly requirements, and then F-Droid apps in another sandbox that is completely free of Google Play.

GrapheneOS is a bit of a hassle, which is why I have been putting it off. But now that Motorola is officially supporting GrapheneOS on some of their new phones, and with Google's corrupted desire to tax everything, I will soon have to bite the bullet and get GrapheneOS going.

That is very odd. I've used F-Droid for at least six years. Now running F-Droid on three devices currently and have not seen that problem on any of my devices so far.

Don't forget Fennec F-Droid, which is a clean build if Firefox mobile. With uBlock Origin and Privacy Badger browsing is a lot safer than with any chrome based browser.

There's zero chance the slate will be under $30k. In fact it's very possible it will be as much as $50k by the time you outfit it with the features you want, such as air conditioning. I hope I'm wrong.

Yeah I'm not surprised that's the way it is in Australia. Makes a ton of sense. In North America there's still an expectation by home owners that they'll make retail rates, which surely is unrealistic.

I have very mixed feelings about home solar and grid-tying. Particularly with two-way meters where you sell power. Pushing power into the grids from homes is a challenge for grid operators to balance, particularly when for residential areas peak solar doesn't coincide wit peak demand. And the idea that home owners should sell power to the grid at retail rates is pretty silly, honestly.

On the other hand I think solar is awesome ad we should have more of it, along with battery storage.

If these systems simply supplement in-home power demand with solar without pushing any out to the grid, and if they can do it safely, then I'm all in favor of such systems. It's not like the utilities can get upset if you turn lights off. You'll always pay for grid maintenance (connection and transmission fees), but at least the energy itself can be cut and money saved... at least if the solar panels themselves are ever paid off which is questionable for home owners.

Yes you're right. One militaristic state has indeed brought down the entire edifice of interconnectedness. But I don't think it's the one you imply.

As represented by this administration, there is very little moral window dressing now. They don't even try. Heck the president is talking openly about eugenics. Everything old is new again.

So yes. Perpetual war is inevitable in this post-global, tribal world we now have. So you hope the US "wins" somehow. And then what?

Of course they do. But only for them.

While that is certainly true, it leaves China as a whole in a really good place with regards to actually producing EVs in the future as Chinese cities transition the vast majority of cars to electric. They have the technology, know how, and experience now. Whereas we have none of those things.

Obviously the CCP knows that their distortion of the market ultimately puts us at a disadvantage and helps their corrupt buddies. But our governments are also good at distorting markets to help rich people, such as what's happening now in Iran and the price of oil, to say nothing about drumming up consumer demand for oil and ICE vehicles.

Linux support on the M series chips is not amazing, Asahi Linux notwithstanding. Since this is a iPhone CPU, I suspect Linux support will be even worse.

Although honestly the Linux experience on any ARM device is not great in my experience.

What I'd like to know is whether you can enable loading of unsigned kernel extensions with this CPU like you can with the normal Macs and their M chips. Or if the phone-style lock down of hardware is present here with this CPU.

To be fair, it's good practice to use as much RAM as possible for caching. Many programs will cache more things in their resident set if the memory is available.

Gleaning useful information on memory usage is difficult on modern OS's with advanced virtual memory systems. Disabling swap might reveal memory pressure more readily, or if swap is on, load average sometimes reveals it.

Add this rule to ublock origin:

||fsdn.com/con/*/floating-unit.js

Not sure if that works on uBlock Lite or not... Chrome really cripples what you can do.

When I asked Claude Opus to disassemble the code and add comments, it did that, yes. I'd post it here (with comments) but it would trip the lame lameness filter. Ironic that posting code to slashdot is considered "junk."

That's kind of interesting to consider that the model is large enough to encode an assembler and disassembler in its parameter matrix.

So after Opus 4.6 gave up, I finally gave it the list of bugs that Russinovich has in his post. After it was pointed out to it my instance of Opus confirmed the DORESTORE missing line-not-found check bug and explained why it was a problem. However it disagreed with one of the other issues found by Russinovich's Opus instance. It said: "Token comparison logic bug â" That other Opus instance was wrong here. The JMP $0314 goes to the CMP, not the LDA. The accumulator retains the token byte. It's correct." Funny to see it arguing with itself. So not sure what to make of all this.

I found his original code and I tried Opencode on it with OpenCode Zen Big Pickle, which is really a Chinese model called GLM. It did admirably. It disassembled the code and made some sort of sense out of it, but it definitely did not find the bugs.

On the other hand Claude Opus failed too for me. It claimed there was a bug that would prevent the example usage code given in the article from even working at all, which is clearly false. It did work. So it missed the bugs that Russinovich found with his Claude session. This is with Opus 4.6.