archivator

I'd love to see a size comparison of the DWARF encoding vs the binary search map. I have a strong suspicion that there's a neat perfect hash solution to this problem - perfect hashes can encode keys in single digit #bits, and you get faster lookups.

> Note that seccomp has limited visibility into recvmsg / sendmsg args because bpf can't dereference syscall arg pointers.

BPF programs attached to syscalls (via kprobe or fentry) can read arguments via helpers (bpf_probe_read_{user,kernel}). Seccomp uses "classic BPF" which has no concept of helpers or calls.

That's fair, it's a better state than the previous attempts.

Still, it's not as tested as, say btrfs and ext4. Can't wait to see its particular quirks.

Except that's not how class linking works on Android :)

In particular, everything is compiled down to lookup tables and hash tables within each odex/oat. Your point still stands but the hit is much lower than you would think and given the slow speed of the superfluous reads, it ends up being a net positive for A LOT of cases.

This articles conflates a lot of things but it also has the priorities somewhat wrong.

1) fsync cost. Yes, fsyncs are dangerously slow in any Android app. (SQLite for example is a common culprit. Shared Prefs are another). HOWEVER, it's possible that flushes cause reads to be queued behind them (either in the kernel or on the device itself) which is even worse because

2) Random read cost is super super important. Android mmap's literally everything and demand paging is particularly common AND horrendous as a workflow. To add insult to injury, Android does not madvise the byte code or the resources as MADV_RANDOM, so read-ahead (or read-around) kicks in and you end up paging in 16KB-32KB where you only wanted 4KB.

Also, history has shown custom flash-based file system on Android to be a world of pain. yaffs, jffs have some pretty atrocious bugs/quirks. I'd much rather see the world unify on common file systems, optimized for flash-like storage, rather than OEMs shipping their own in-house broken file "systems" (I'm looking at you, Samsung).

> and in a mobile device OS and application SW are tightly coupled

I call bullshit. There's no reason Google can't update everything AOSP-y in /system - libc, libart, libwebkit etc.

> Google (and Apple and Microsoft) can totally do it for devices that manufactures and maintains on its own

That's a low bar. When you buy a Dell laptop, you continue to receive updates from Microsoft. This is the bar we should hold Google to.

As for the certification process, surely having one update that ships to N models is easier to test than N updates shipping to N models?

Trader Joe's has Unpasteurized Orange Juice which does taste like freshly squeezed juice. I wonder how real that is.

Last I looked, no, but the immediate cause of nondeterminism I saw was the zip entry timestamps in the apk. I didn't bother looking further down the chain.