10 ms·

It's always mind-boggling to me that software engineers find ways to screw things up, and then hype up effectively bringing back features that would have existe

It's always mind-boggling to me that software engineers find ways to screw things up, and then hype up effectively bringing back features that would have existed if they had done nothing at all.

xmhsez 2y ago
I'm not familiar with the history here. What happened?
gjsman-1000 2y ago
Nonsense - Android's userland does not use GNU, at all; or Linux display servers; or the POSIX standard; or anything but the kernel. Apps on Android have no access, or ability, to directly call kernel functions. Android is deliberately designed so the kernel could, hypothetically, even be replaced one day without breaking anything. Forcing apps into an abstraction layer from the kernel is good design, preventing kernel quirks from being permanent features. Not using GNU is another design choice which can be debated, but it's completely valid, there's no requirement (moral or otherwise) to use the GNU userland with the Linux kernel. Most embedded devices also eschew the GNU userland by instead using Busybox.
- Vogtinator 2y ago
  > Apps on Android have no access, or ability, to directly call kernel functions. That is nonsense.
  - gjsman-1000 2y ago
    Technically, it's true, as far as I am aware. Android has low level functions which themselves then directly call Linux, but you are not allowed to make a direct Linux call. I could easily be completely wrong though.
    - fluoridation 2y ago
      What do you imagine happens when you call fopen()? At some point there's a transition from user mode into kernel mode. What can the system do to prevent normal "app" code from making the transition but not "low level" code, when it's all user mode stuff running in the same process?
      - gjsman-1000 2y ago
        [flagged]
        Jyaif 2y ago
        > Android's fopen() function is indeed an abstraction over the Linux fopen() system call Yikes, `fopen` is not a system call...
        AdelaideSimone 2y ago
        What exactly is it you're "right" about? How do you think any libc wrapper or direct syscall works? Syscalls are filtered for security reasons on many platforms, including Android. I mean, a syscall is literally an API itself to get a kernel's internals to do something for you. What you're suggesting is, as someone else said, non-sensical. Phrased without invincible ignorance, it's equivalent to saying, "Android prevents you from creating a new OS kernel to supplant its own control over hardware access," which is true of basically any OS. How helpful or secure would it be if you could make 0 guarantees about how your hardware is used? You can do direct hardware access through drivers that are integrated/interfaced with the kernel somehow, but this still is not an entirely arbitrary access, and is still going through the kernel in a way.
    - bri3d 2y ago
      In the Android-y part of Android, yes, they use ART, which is abstracted. But, they also give app authors the NDK. How do you think Android knows whether it's libc or your app making a syscall from native code? It doesn't - you're allowed access to full Linux-land. The syscall numbers and userland EABI for Android are the same as for any other Linux. They use a different `libc` from most GNU/Linux (one of a few places this wonderful turn of phrase actually makes sense) flavors, but this is no different from Alpine Linux using `musl` instead of `glibc` for example. As such, you can use `musl`, `glibc`, or non-libc based environments (Rust, Zig) on Android without issue. You can run any C you want, either by porting it to `bionic` (most termux apps, although they support glibc now), statically linking your own runtime (Rust, Zig, etc.), or abusing the dynamic linker into making glibc work (termux-glibc, I think).
- andrewmcwatters 2y ago
  All of which are more expensive decisions than working from existing foundations and building on top of them, not throwing out the baby with the bathwater and demolishing the bathtub, then designing a walk-in shower, adopting a new baby, putting a portable bathtub in the walk-in shower, and refilling it. Hey, but at least you can remove the tub whenever you want now.
  - gjsman-1000 2y ago
    Well, I think that it could be argued that GNU, and Xorg, and GTK, and all the rest, wasn’t the best foundation to build on in 2003. At a minimum, it would have required so much modification to run on mobile phones, that combined with the license (remembering that Android was originally a small company not part of Google), would not have led to a viable business model or platform. Even today, Xorg would be a terrible fit for a mobile device, and most embedded devices don’t use GNU.
    - ndiddy 2y ago
      The Nokia N900 was a production mobile phone that ran Linux (Debian-based) with a GNU userland, Xorg, and a GTK+ based graphical environment. It was very responsive, had a ton of features, and got great reviews (even outside the Linux enthusiast community). It failed in the market, but the reasons why it did had little to do with the choice in technology.

It's always mind-boggling to me that software engineers find ways to screw things up, and then hype up effectively bringing back features that would have existed if they had done nothing at all.

xmhsez 2y ago

I'm not familiar with the history here. What happened?

gjsman-1000 2y ago

Nonsense - Android's userland does not use GNU, at all; or Linux display servers; or the POSIX standard; or anything but the kernel. Apps on Android have no access, or ability, to directly call kernel functions. Android is deliberately designed so the kernel could, hypothetically, even be replaced one day without breaking anything. Forcing apps into an abstraction layer from the kernel is good design, preventing kernel quirks from being permanent features. Not using GNU is another design choice which can be debated, but it's completely valid, there's no requirement (moral or otherwise) to use the GNU userland with the Linux kernel. Most embedded devices also eschew the GNU userland by instead using Busybox.

Vogtinator 2y ago
> Apps on Android have no access, or ability, to directly call kernel functions. That is nonsense.
- gjsman-1000 2y ago
  Technically, it's true, as far as I am aware. Android has low level functions which themselves then directly call Linux, but you are not allowed to make a direct Linux call. I could easily be completely wrong though.
  - fluoridation 2y ago
    What do you imagine happens when you call fopen()? At some point there's a transition from user mode into kernel mode. What can the system do to prevent normal "app" code from making the transition but not "low level" code, when it's all user mode stuff running in the same process?
    - gjsman-1000 2y ago
      [flagged]
      - Jyaif 2y ago
        > Android's fopen() function is indeed an abstraction over the Linux fopen() system call Yikes, `fopen` is not a system call...
      - AdelaideSimone 2y ago
        What exactly is it you're "right" about? How do you think any libc wrapper or direct syscall works? Syscalls are filtered for security reasons on many platforms, including Android. I mean, a syscall is literally an API itself to get a kernel's internals to do something for you. What you're suggesting is, as someone else said, non-sensical. Phrased without invincible ignorance, it's equivalent to saying, "Android prevents you from creating a new OS kernel to supplant its own control over hardware access," which is true of basically any OS. How helpful or secure would it be if you could make 0 guarantees about how your hardware is used? You can do direct hardware access through drivers that are integrated/interfaced with the kernel somehow, but this still is not an entirely arbitrary access, and is still going through the kernel in a way.
  - bri3d 2y ago
    In the Android-y part of Android, yes, they use ART, which is abstracted. But, they also give app authors the NDK. How do you think Android knows whether it's libc or your app making a syscall from native code? It doesn't - you're allowed access to full Linux-land. The syscall numbers and userland EABI for Android are the same as for any other Linux. They use a different `libc` from most GNU/Linux (one of a few places this wonderful turn of phrase actually makes sense) flavors, but this is no different from Alpine Linux using `musl` instead of `glibc` for example. As such, you can use `musl`, `glibc`, or non-libc based environments (Rust, Zig) on Android without issue. You can run any C you want, either by porting it to `bionic` (most termux apps, although they support glibc now), statically linking your own runtime (Rust, Zig, etc.), or abusing the dynamic linker into making glibc work (termux-glibc, I think).
andrewmcwatters 2y ago
All of which are more expensive decisions than working from existing foundations and building on top of them, not throwing out the baby with the bathwater and demolishing the bathtub, then designing a walk-in shower, adopting a new baby, putting a portable bathtub in the walk-in shower, and refilling it. Hey, but at least you can remove the tub whenever you want now.
- gjsman-1000 2y ago
  Well, I think that it could be argued that GNU, and Xorg, and GTK, and all the rest, wasn’t the best foundation to build on in 2003. At a minimum, it would have required so much modification to run on mobile phones, that combined with the license (remembering that Android was originally a small company not part of Google), would not have led to a viable business model or platform. Even today, Xorg would be a terrible fit for a mobile device, and most embedded devices don’t use GNU.
  - ndiddy 2y ago
    The Nokia N900 was a production mobile phone that ran Linux (Debian-based) with a GNU userland, Xorg, and a GTK+ based graphical environment. It was very responsive, had a ton of features, and got great reviews (even outside the Linux enthusiast community). It failed in the market, but the reasons why it did had little to do with the choice in technology.