10 ms·

Linux phone apps: "Let's reimplement all of Android's basic app system in a less secure language because Java isn't cool and Unix should be always in C"

by yyyk 5y ago

nsizx 5y ago
That's okay, nobody will ever use these applications, so they don't pose a security issue to anybody.
marcodiego 5y ago
Linux phones are much more about freedom, privacy, control, ownership and choice than about java not being cool. I watch the linux phones progress since qt greenphone and your comment is the worst one I've read about it more than a decade.
- yyyk 5y ago
  My comment wasn't about the Linux phone (I get what you wrote) but about Linux phone apps. The smarter play would have been to fork AOSP, but if not that, at least do not write the userland in C.
  - marcodiego 5y ago
    Using AOSP really looks like a smart move. F-droid is already a finely curated app repository and very clear about anti-features. Nevertheless, I don't think linux on phones, apart from the UI, is very different from linux on the desktop. So it can be stable and secure. If anbox manages to run well on these distros then there will be no lack of apps. The UI will take some time to mature but, after all, not using AOSP doesn't seems like a dumb move.
    - yyyk 5y ago
      The threat model is different, we really do have to lock down phones a bit more because they're used for user identification (but I think not to the draconian level Google and Apple do). The result of not using AOSP is having to reimplement stuff, and it's not like this ecosystem has a lot of free labour just waiting around. Yes, Google would have diverged, but so would the community. If you're already willing to go for a Linux phone, compatibility probably isn't your main concern. I still wish them luck. With the way Apple and Google are going, there may be no other choice eventually.
  - miohtama 5y ago
    I worked with Maemo (N900) and OpenMoko, back in a day. Before that with Nokia and MyOrigo. You are 100% correct, Apps need to be tightly coupled with the underlying UI framework. Outside AOSP, Only Flutter and Qt are credible contenders with the amount of developers and resources. It takes at least a team of 50 - 100 people to make a UI framework for a smart phone. Gnome and KDE can barely make it to desktop. Also, anything interpreted like JavaScript or Python is too slow for UI apps. Not because of CPU, but because of startup delay caused by the IO hit and getting the code running.
  - bubabug 5y ago
    If your goal was to make a worse version of android, that would be a smart play. But mobile linux can be more than a dumbed down mobile OS. Writing apps in this way makes it capable of "convergence", which means it can run a full desktop OS.
    - yyyk 5y ago
      Should we want convergence? 'Converging' OSs so far are horrible either for desktop or phone (e.g. Windows 8). Ordinary apps could have been kept in Java while still allowing a full developer environment with the typical C tools (something Android/iOS aren't interested at all to do).
      - fsflover 5y ago
        https://source.puri.sm/Librem5/community-wiki/-/wikis/Frequently-Asked-Questions#213-how-well-will-convergence-work-to-use-the-librem-5-as-a-desktop-pc https://source.puri.sm/Librem5/community-wiki/-/wikis/Freque...
  - SahAssar 5y ago
    If you define "Linux Phone" as including AOSP (android) then the term is basically meaningless since by that definition we have had linux phones for 15+ years. The "linux phone" movement is not about creating another AOSP fork.
- nine_k 5y ago
  I don't see how AOSP is not free enough, or is not Linux enough underneath. I think these programs are much less resource-hungry than a JVM-based phone suite. Though yes, I wish it wasn't C or C++, but Rust, Zig, Golang, D, what have you. The problem is that all GUI toolkits worth considering in the native space are either deeply C (GTK, fltk), or deeply C++ (Qt), and adapting them to these languages is neither idiomatic nor safe.
  - miohtama 5y ago
    Note that Android has been using ahead of time compiling, not JVM, for a better part of a decade now. Java does not imply JVM run-time.
  - pjmlp 5y ago
    Android doesn't use a JVM, and does a mix of JIT and AOT with PGO. https://source.android.com/devices/tech/dalvik/jit-compiler?hl=en https://source.android.com/devices/tech/dalvik/jit-compiler?...
bubabug 5y ago
We don't need to reinvent anything, just adapt desktop programs to a smaller screen. You can still run java programs if you prefer using a slow, overcomplicated programming language. However I will stick to GTK4.
- pjmlp 5y ago
  Maybe glade will support Gtk4 still in this decade, meanwhile I rather use JetPack Composer.
  - marcodiego 5y ago
    AFAIK glade won't support Gtk4. Cambalache and drafting are major promises for that: https://blogs.gnome.org/xjuan/2021/02/28/cambalache/ https://blogs.gnome.org/xjuan/2021/02/28/cambalache/ https://gitlab.gnome.org/chergert/drafting https://gitlab.gnome.org/chergert/drafting
    - pjmlp 5y ago
      It is a one man's job, and as per his GUADEC talk, still lots to be done to bring all glade features into the boat, and he also made a big plea for sponsorship, as otherwise he might not be able to keep working on it. Meanwhile even the old View based GUI editor in Eclipse had more features, let alone the last generation of graphical tooling for Android. This kind of tools just aren't on the same league, regional football teams feeling great just because they manage to be part of national cup, which will scored quite heavily when the match with first league teams come. But hey dreaming is good.
randyrand 5y ago
let’s hope they at least use Rust

Linux phone apps: "Let's reimplement all of Android's basic app system in a less secure language because Java isn't cool and Unix should be always in C"

by yyyk 5y ago

Linux phone apps: "Let's reimplement all of Android's basic app system in a less secure language because Java isn't cool and Unix should be always in C"

nsizx 5y ago

That's okay, nobody will ever use these applications, so they don't pose a security issue to anybody.

marcodiego 5y ago

Linux phones are much more about freedom, privacy, control, ownership and choice than about java not being cool. I watch the linux phones progress since qt greenphone and your comment is the worst one I've read about it more than a decade.

yyyk 5y ago
My comment wasn't about the Linux phone (I get what you wrote) but about Linux phone apps. The smarter play would have been to fork AOSP, but if not that, at least do not write the userland in C.
- marcodiego 5y ago
  Using AOSP really looks like a smart move. F-droid is already a finely curated app repository and very clear about anti-features. Nevertheless, I don't think linux on phones, apart from the UI, is very different from linux on the desktop. So it can be stable and secure. If anbox manages to run well on these distros then there will be no lack of apps. The UI will take some time to mature but, after all, not using AOSP doesn't seems like a dumb move.
  - yyyk 5y ago
    The threat model is different, we really do have to lock down phones a bit more because they're used for user identification (but I think not to the draconian level Google and Apple do). The result of not using AOSP is having to reimplement stuff, and it's not like this ecosystem has a lot of free labour just waiting around. Yes, Google would have diverged, but so would the community. If you're already willing to go for a Linux phone, compatibility probably isn't your main concern. I still wish them luck. With the way Apple and Google are going, there may be no other choice eventually.
- miohtama 5y ago
  I worked with Maemo (N900) and OpenMoko, back in a day. Before that with Nokia and MyOrigo. You are 100% correct, Apps need to be tightly coupled with the underlying UI framework. Outside AOSP, Only Flutter and Qt are credible contenders with the amount of developers and resources. It takes at least a team of 50 - 100 people to make a UI framework for a smart phone. Gnome and KDE can barely make it to desktop. Also, anything interpreted like JavaScript or Python is too slow for UI apps. Not because of CPU, but because of startup delay caused by the IO hit and getting the code running.
- bubabug 5y ago
  If your goal was to make a worse version of android, that would be a smart play. But mobile linux can be more than a dumbed down mobile OS. Writing apps in this way makes it capable of "convergence", which means it can run a full desktop OS.
  - yyyk 5y ago
    Should we want convergence? 'Converging' OSs so far are horrible either for desktop or phone (e.g. Windows 8). Ordinary apps could have been kept in Java while still allowing a full developer environment with the typical C tools (something Android/iOS aren't interested at all to do).
    - fsflover 5y ago
      https://source.puri.sm/Librem5/community-wiki/-/wikis/Frequently-Asked-Questions#213-how-well-will-convergence-work-to-use-the-librem-5-as-a-desktop-pc https://source.puri.sm/Librem5/community-wiki/-/wikis/Freque...
- SahAssar 5y ago
  If you define "Linux Phone" as including AOSP (android) then the term is basically meaningless since by that definition we have had linux phones for 15+ years. The "linux phone" movement is not about creating another AOSP fork.
nine_k 5y ago
I don't see how AOSP is not free enough, or is not Linux enough underneath. I think these programs are much less resource-hungry than a JVM-based phone suite. Though yes, I wish it wasn't C or C++, but Rust, Zig, Golang, D, what have you. The problem is that all GUI toolkits worth considering in the native space are either deeply C (GTK, fltk), or deeply C++ (Qt), and adapting them to these languages is neither idiomatic nor safe.
- miohtama 5y ago
  Note that Android has been using ahead of time compiling, not JVM, for a better part of a decade now. Java does not imply JVM run-time.
- pjmlp 5y ago
  Android doesn't use a JVM, and does a mix of JIT and AOT with PGO. https://source.android.com/devices/tech/dalvik/jit-compiler?hl=en https://source.android.com/devices/tech/dalvik/jit-compiler?...

bubabug 5y ago

We don't need to reinvent anything, just adapt desktop programs to a smaller screen. You can still run java programs if you prefer using a slow, overcomplicated programming language. However I will stick to GTK4.

pjmlp 5y ago
Maybe glade will support Gtk4 still in this decade, meanwhile I rather use JetPack Composer.
- marcodiego 5y ago
  AFAIK glade won't support Gtk4. Cambalache and drafting are major promises for that: https://blogs.gnome.org/xjuan/2021/02/28/cambalache/ https://blogs.gnome.org/xjuan/2021/02/28/cambalache/ https://gitlab.gnome.org/chergert/drafting https://gitlab.gnome.org/chergert/drafting
  - pjmlp 5y ago
    It is a one man's job, and as per his GUADEC talk, still lots to be done to bring all glade features into the boat, and he also made a big plea for sponsorship, as otherwise he might not be able to keep working on it. Meanwhile even the old View based GUI editor in Eclipse had more features, let alone the last generation of graphical tooling for Android. This kind of tools just aren't on the same league, regional football teams feeling great just because they manage to be part of national cup, which will scored quite heavily when the match with first league teams come. But hey dreaming is good.

randyrand 5y ago

let’s hope they at least use Rust