[gh copilot](https://docs.github.com/en/copilot/using-github-copilot/usin...) works okay.

I am also using this setup powered by chezmoi. It has brilliant secrets support and powerful templating allowing cross-platform setups. I do get lost in its state sometimes when updating `run_once_*` scripts and trying to make sure they still run. Another friction point is external tools installed via .chezmoiexternal.toml from GitHub.

Or nuclear power plants for the benefit of gas traders and entrepreneurs of heavily subsidised green energy technologies.

Also available on AmeriDroid: https://ameridroid.com/products/odroid-h2

I know people, who microwave their phones for a few secs to get them replaced by the carrier with a newer model, still not sure if you're joking or not.

They're not joking. They're essentially reflowing the PCB connections.

It _is_ only a temporary fix, though.

Solder melts at >180°C. This idea that putting electronics in an oven will reflow internal components is a commonly repeated meme[1].

In reality, putting electronics in an oven usually has the effect of heating up some chips which are heat-sensitive and might temporarily give them new life.

[1]: https://youtu.be/w57ObM3pYXw

Well, Windows only had Ctrl-Break for the thing you were thinking about, and it's probably still true.

Why is this being downvoted? Is there something that guarantees visibility of unknown devices linked to an iCloud-account?

Because it's missing the point that a sibling makes.

they may as well replace it with _today_ to make it future proof, at least for some decades.

This can't be intentional, right?

Google does not seem interested in making the NDK anything more than implementing Java native methods, 3D graphics, audio or porting code from other platforms.

Everything else should be done at Java level.

I understand from the point of view of security, but what is safer, provide bindings to libraries already validated and installed on the device or forcing devs to package something else?

Also even though they implement native APIs in nice C++ with RAII and stuff, it gets exposed as unsafe C APIs, so the security story isn't 100% correct.

Java APIs ARE C APIs, for obvious reasons. There doesn't have to be any difference in security.

It is quite normal and traditional though, for C/C++ developers to work with what they call statically built binaries. They're a bit bigger (may God provide mercy, and huge amounts of free diskspace to those fools that enable debug), but the odds of them working flawless on a given device are much higher.

> Java APIs ARE C APIs,

You lost me there. I wouldn't call JNI boilerplate a C API.

> It is quite normal and traditional though, for C/C++ developers to work with what they call statically built binaries.

Polyglot dev here, including C and C++.

The way a library is linked is orthogonal to be made available on the SDK.

Skia does not have a stable ABI, which is a requirement for inclusion in the NDK: https://github.com/google/skia/blob/master/experimental/c-ap...

It has a stable API for Java clients on Android, if Google actually would care they could expose that one.

And in any case, creating a 2D abstraction layer stable API on top of platforms specific version APIs, specially given that all NDK APIs are C based even if written in C++, it is not rocket science, rather a matter of wanting to do it.

I guess he means NeXT == Jobs