defer

README mentions it supports up to 4 guests at a time sharing the GPU.

No, the SMS is initiated by the device upon calling emergency, not requested by the emergency service. The standard is called AML.

The format is not secret either, it's just binary encoded.

They are huge because android has hundreds of smallish makefiles but the generated ninja file is a single flat file.

The advantage in android is that the different build systems will generate ninja, so they can interoperate.

This is hilarious to me:

  Android, which uses it for some large component of the system that I've never quite understood

Ninja is really a huge part of AOSP, the build system initially used makefiles. Things got complex really fast with a custom declarative build system (soong) and a failed/aborted migration to bazel. Google developed kati (https://github.com/google/kati) which converts Makefiles to ninja build files (or should I say file), which really is huge:

  λ wc -l out/build-qssi.ninja    
    3035442 out/build-qssi.ninja

Going from makefiles/soong to ninja is painful, it takes several minutes even in a modern machine but it simply flies once ninja picks it up.

JVM does garbage collection, this can stop all threads at safepoints while GC occurs.

Those stops can be enough to ruin your low latency requirements in the high percentiles. A common strategy is to divide workloads between jvms so that you meet the requirement.

You can generate binder wrappers from aidl, that would work. This is fairly common when doing platform work (for those like me who work on the operating system rather than on apps).

However, this would be a terrible idea because usually the android api is stable at the Java wrappers (I.e. ActivityManager), not at the aidl level, which would make this very fragile for app development across a multitude of devices and platform versions.

I also want to know this, but in reverse.

I build older android (the OS) versions inside docker containers because they have dependencies on older glibc versions.

This is a memory-heavy multi-threaded process and the OOM killer will kill build threads, making my build fail. However, there is plenty of available (but not free) memory in the docker host, but apparently not available in the container. If I drop caches on the host periodically, the build generally succeeds.

Well, it's understandable. If you talk about it with other linux-on-MacBook tinkerers I'm sure they'll be more sensible to your cause.

But generally, if you pointed that out to me I'd say the same, picking that hardware puts you in a harder path. Also, I'm not sure if Linux users in general have any interest in winning people over.

Definitely, I remember from reading the documentation that they could also target HTML5/css (https://docs.flutter.dev/development/tools/web-renderer) instead of canvas but I'm not sure how complete / coherent the output is.

I used a similar approach before working mostly remote, now I just curl to pushbullet to get the notification wherever I might be working.

This resonates. I usually wrap my long running commands in something that sends a push notification when they finish so that I don't jump around seeing if things completed or failed. I find the distraction of the push notification less disrupting than continually checking for completeness.

It's certainly possible, I honestly wouldn't know. Anedoctaly, I find it worse on my mental health to just sit around waiting for things to finish.

Yeah, I mentioned it because I see peers doing different things to be productive during compilation times while newcomers will stare at compiler output. Some will jump to writing documentation, take care of issue management, work on some other ticket entirely, etc.

Not quite, treble is more about separating hardware specifics in a versioned, backwards compatible way. It's more for replacing the previous HAL system which in itself already abstracted the kernel for driver support (not necessarily just the kernel because modern platforms run things like audio, sensors, telephony outside of the kernel purview in specialized dsps or secondary mcus).

But that's just the kernel. This is more akin to compiling the kernel plus all packages and applications that make up the operating system.

I'm very conflicted with flutter. The developer story is tempting, cross platform consistency but extendable to each system's specifics.

On the flip side there's the odd programming language, the bundle size, the game-engine like rendering (seemingly wasteful, but may improve as hardware evolves).

I'm not familiar with fuschia but those times are what I'd consider normal for an initial compilation of an operating system in regular consumer workstations.

I work on the android operating system and very rarely compile the whole thing from scratch in development environments. Incremental builds plus adb sync (think rsync between compiled artifacts in host and device) make it into a manageable workflow.

Even incrementally, it takes a few minutes to see your changes and that can be a source of frustration for newcomers who are used to instant feedback. Being productive requires making good decisions on how often and what to compile as well as strategies for filling up compilation time.

Oh, for sure. It's definitely not either/or. I've worked in fraud prevention software in the past and our clients would definitely see both.

I've been away from that world for a while but remember that more serious operations will separate the cashing out part (either money or goods) from their acquiring / validating operation because the former carries more risk.

There's also an interesting episode of the darknet diaries podcast (https://darknetdiaries.com/episode/85/) about card cloning which I found interesting.

Not exactly. Some people are in the business of gathering and selling valid credit cards.

They won't cash out on them or buy items. Instead, they'll collect cards from a source (skimming, hacking, whatever), validate them by adding them to a website that does an authorization (those $1 checks that never get committed). They can then sell them wholesale for a premium compared to non-verified cards.

Heh, I do android platform development for a living. Most devices are obviously ARM but you can't compile android on arm processors.

A small correction, Android does not use OpenJDK. It uses the ART runtime (https://source.android.com/devices/tech/dalvik) which will definitly need porting.

Slightly longer answer is that _some parts_ of the OpenJDK are used. Namely, LUNI (implementation of java.lang, java.util, java.net, java.io) run on the device, but those are high-level enough that they will require either none or minimal changes for risc-v.

Compiling applications also uses OpenJDK (or the Jack compiler in platform builds) but that is an intermediate step on the host. The produced JVM bytecode gets converted to Dex bytecode during the build process.

I think the effort for Android will be two-fold:

On the software side, Bionic (android's libc), Dalvik (runtime), LLVM, external dependencies (i.e. boringssl, lib{vpx,hecv,mpeg4,etc},) definitely need work.

On the hardware side it all lies on the practical availability of a SoC. While I have no doubt we'll have something similar to android-x86 running on discrete chips, commercial devices will need a more complete cpu+gpu+dsp+modem package.

This would support multiple vhosts.

Not really no, most of it is Android's + Qualcomm's modifications (which are usually public and easily available).

However, there are some HTC hardware-specific parts that are used mostly and needed by any serious third party android distribution (like CyanogenMod).