LinuxPhoneApps(alpha.linuxphoneapps.org)
alpha.linuxphoneapps.org
LinuxPhoneApps
https://alpha.linuxphoneapps.org/
30 comments
Glad to see us moving more and more to a linux phone ecosystem. Obviously this ecosystem is still early but exciting to see the foundations being laid.
Most phone apps are better as web pages, what remains competes (poorly) with the already existing software library Linux has.
--a Pinephone user
--a Pinephone user
True. The way to get the users interested and increase adoption is by having the majority of Android apps being available on the Linux phone ecosystem fully working.
On top of that, they need to be quick or else Google will steam-roll them silently with Fuchsia and the Flutter ecosystem right under everyone's noses.
On top of that, they need to be quick or else Google will steam-roll them silently with Fuchsia and the Flutter ecosystem right under everyone's noses.
I’d prefer the steaming pile of android (surveillance) apps is kept out of the Linux phone eco-system.
There are high quality privacy preserving android apps on F-droid too.
Frankly, open-source phones need more powerful processors. The current ones can barely handle modern websites (and before people get in a tizzy about how the web is bloated, that’s too bad and people need it to work well since there won’t be a fleshed-out app ecosystem).
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"
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.
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.
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.
The "linux phone" movement is not about creating another AOSP fork.
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.
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.
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.
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.
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.
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.
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).
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).
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.
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.
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.
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.
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.
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?...
https://source.android.com/devices/tech/dalvik/jit-compiler?...
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.
Maybe glade will support Gtk4 still in this decade, meanwhile I rather use JetPack Composer.
AFAIK glade won't support Gtk4. Cambalache and drafting are major promises for that: https://blogs.gnome.org/xjuan/2021/02/28/cambalache/ https://gitlab.gnome.org/chergert/drafting
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.
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.
let’s hope they at least use Rust
Android dev here. If they want the developer's attention they need to provide tools. Flutter is an alternative, compose desktop would be another, it intellij makes it run on kotlin native. We don't want to learn gtkSomething or using low level languages like c.
I'd they don't than Linux on phones to be mainstream, then keep doing what they are doing.
Also they need a big player like Xiaomi or Samsung to make a Linux edition of their flagships. People will be willing to pay big money for a super fast Linux phone.
I'd they don't than Linux on phones to be mainstream, then keep doing what they are doing.
Also they need a big player like Xiaomi or Samsung to make a Linux edition of their flagships. People will be willing to pay big money for a super fast Linux phone.