I have the Z Fold 4 (EU) and it performs well to this day. It even got the Android 16 upgrade.

Z Fold 3 here, going happily on 4-5 years.

Samsung has nice hardware quality, but no sense of UX, and that goes for their software and hardware.

On ChromeOS, Chrome is the window manager, compositor and desktop session all in one.

The linked document is not related to this incident.

There is no oversimplifying happening here. There is no documented procedure to switch to direct law in an Airbus.

In fact, the only way to get into direct law on a fully functional plane is to start pulling circuit breakers for the (redundant) flight computers and inertial reference units.

Google released their latest chat app 8 years ago.

Also: https://elixir.bootlin.com/linux/v6.17.9/source

Elixir works better on mobile despite being around for years.

Elixir also has working tags instead of just looking at a file at a time, so it is much better at the actual exploring part.

Thanks for the observation about mobile responsiveness, I will improve it!

There could very well be bitrot in your xz archive without xz detecting it: https://www.nongnu.org/lzip/xz_inadequate.html#checking

On the flip side, every Chromebook and Chromebox has a unlockable and open-spurce coreboot bootloader.

I love their mechanism where one opens the device and removes a screw to unlock it. Very novel and honestly kind of fun.

Chrome and Firefox use seccomp for sandboxing since more that 15 years: https://lwn.net/Articles/346902/

But only in very small sandboxes, right? Yes, seccomp could potentially be used for your JIT/interpreter sandbox. And because it inherently executes untrusted input, that's definitely the most important place.

But compare how many applications execute untrusted remote programs to how many programs that have had security vulnerabilities. Or indeed, how much code.

What percentage of code runs in chrome/firefox's sandbox? 0.0001%?

Have you tried to create a seccomp ruleset for a real program? I have. There are too many variations between machines and code paths that you'll necessarily need to leave wide open doors through your policy. Sure, the more you disable the "luck" you manufacture in case of a bug, preventing exploitation. But no, it's not fit for purpose outside these extremely niche use cases.

The post on lwn.net has some more context in the comments:

https://lwn.net/Articles/1044867/

Edit to add: no need to read the LWN comments, the article is crystal clear and to the point - no technical reading skills necessary (unlike some very involved Project Zero posts).

- - -

Make sure you get down to the comment by ardbiesheuvel, “linear map randomization was already broken”, past all the hot air about the lack of QA. This comment explains why hot pluggable memory causes issues with randomization.

Now off to read the article.

I’m a bit confused by your edit and I’m glad I ignored it to read the comment you initially highlighted because it does offer a strong counter to the Project Zero article.

There are some good points around how limited the entropy available here is, but it entirely skips over who the fuck needs hotplug memory in the first place. That is a very niche feature that has no application in the vast majority of devices and should never inform the defaults.

It made it very clear - virtualization builds where memory can be dynamically added and removed by the emulator. I haven't done this with Android but it can be quite useful for running lots of test emulators, they can adapt their memory to the workload to not overwhelm the host.

So you agree, it has no place or purpose when running on an actual device.