4 ms·

Google should have innovated or they should have complied. Instead they built on POSIX's shoulders and then diverged only enough to harm portability. Not cool.

ndesaulniers 10y ago
> then diverged only enough to harm portability How so?
- pjmlp 10y ago
  ChromeOS might be built on top of a POSIX like kernel, but the actual application stack is the browser. Android is mostly Java, the NDK only white lists a restricted set of libraries that aren't POSIX related, Android 7 dynamic linker will kill any app that tries to link to device libraries not part of that list, the Linux fork lacks APIs like e.g. UNIX IPC. Android Things is even tighter. Only user space drivers are allowed, with C support just added this week. Before only Java drivers were allowed. Magenta/Fuchsia is a micro-kernel with Dart as main application stack.
  - jmgao 10y ago
    > the NDK only white lists a restricted set of libraries that aren't POSIX related Uh, libc? > Android 7 dynamic linker will kill any app that tries to link to device libraries not part of that list Yes, it prevents you from depending on things that aren't required to be there. Apps depending on the device's OpenSSL libssl.so were horribly broken when Android switched to BoringSSL after Heartbleed. Preventing apps from loading system libraries guarantees that they won't break when those libraries are changed or removed in future releases. > the Linux fork lacks APIs like e.g. UNIX IPC. POSIX/SysV IPC are unusable on any system with untrusted applications. They live in a global namespace not tied to a process, and there's no reasonable way of doing any sort of accounting on them. There isn't even a way to use them correctly. If you shm_open, and fail to shm_unlink (for example, if you're OOM killed), the shared memory object will live forever. In the specific case of shm, Android introduced a far superior API, ashmem, which tracks shared memory objects as file descriptors, instead of manually refcounting names in a global namespace (memfd was added in linux 3.17, which solves the same problem in the same way).
    - pjmlp 10y ago
      > Uh, libc? libc is the C runtime library, a subset of POSIX. A conforming ANSI C implementation is not required to provide headers like unistd, or any kind of POSIX compatibility beyond what ISO/IEC 9899 requires. > POSIX/SysV IPC are unusable on any system with untrusted applications..... Either POSIX compatibility matters, or it doesn't.
      - jmgao 10y ago
        > libc is the C runtime library, a subset of POSIX. > A conforming ANSI C implementation is not required to provide headers like unistd, or any kind of POSIX compatibility beyond what ISO/IEC 9899 requires. Yes, and Android's libc provides almost all of (all of? I don't know for sure) POSIX.1. > Either POSIX compatibility matters, or it doesn't. POSIX IPC is a non-mandatory option in POSIX. See http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap02.html#tag_02_01_05 http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_... if you want to be a language lawyer. More to the point, POSIX compatibility matters up to the point where it's useful. Implementing the shared memory functions by returning -1 and setting ENFILE is a perfectly compliant implementation. It's also worse than just not providing an implementation.

ndesaulniers 10y ago

> then diverged only enough to harm portability How so?

pjmlp 10y ago
ChromeOS might be built on top of a POSIX like kernel, but the actual application stack is the browser. Android is mostly Java, the NDK only white lists a restricted set of libraries that aren't POSIX related, Android 7 dynamic linker will kill any app that tries to link to device libraries not part of that list, the Linux fork lacks APIs like e.g. UNIX IPC. Android Things is even tighter. Only user space drivers are allowed, with C support just added this week. Before only Java drivers were allowed. Magenta/Fuchsia is a micro-kernel with Dart as main application stack.
- jmgao 10y ago
  > the NDK only white lists a restricted set of libraries that aren't POSIX related Uh, libc? > Android 7 dynamic linker will kill any app that tries to link to device libraries not part of that list Yes, it prevents you from depending on things that aren't required to be there. Apps depending on the device's OpenSSL libssl.so were horribly broken when Android switched to BoringSSL after Heartbleed. Preventing apps from loading system libraries guarantees that they won't break when those libraries are changed or removed in future releases. > the Linux fork lacks APIs like e.g. UNIX IPC. POSIX/SysV IPC are unusable on any system with untrusted applications. They live in a global namespace not tied to a process, and there's no reasonable way of doing any sort of accounting on them. There isn't even a way to use them correctly. If you shm_open, and fail to shm_unlink (for example, if you're OOM killed), the shared memory object will live forever. In the specific case of shm, Android introduced a far superior API, ashmem, which tracks shared memory objects as file descriptors, instead of manually refcounting names in a global namespace (memfd was added in linux 3.17, which solves the same problem in the same way).
  - pjmlp 10y ago
    > Uh, libc? libc is the C runtime library, a subset of POSIX. A conforming ANSI C implementation is not required to provide headers like unistd, or any kind of POSIX compatibility beyond what ISO/IEC 9899 requires. > POSIX/SysV IPC are unusable on any system with untrusted applications..... Either POSIX compatibility matters, or it doesn't.
    - jmgao 10y ago
      > libc is the C runtime library, a subset of POSIX. > A conforming ANSI C implementation is not required to provide headers like unistd, or any kind of POSIX compatibility beyond what ISO/IEC 9899 requires. Yes, and Android's libc provides almost all of (all of? I don't know for sure) POSIX.1. > Either POSIX compatibility matters, or it doesn't. POSIX IPC is a non-mandatory option in POSIX. See http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap02.html#tag_02_01_05 http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_... if you want to be a language lawyer. More to the point, POSIX compatibility matters up to the point where it's useful. Implementing the shared memory functions by returning -1 and setting ENFILE is a perfectly compliant implementation. It's also worse than just not providing an implementation.