[HN Gopher] LinuxPhoneApps
___________________________________________________________________
LinuxPhoneApps
Author : marcodiego
Score : 60 points
Date : 2021-08-15 18:38 UTC (4 hours ago)
(HTM) web link (alpha.linuxphoneapps.org)
(TXT) w3m dump (alpha.linuxphoneapps.org)
| nynx wrote:
| 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).
| yyyk wrote:
| 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"
| randyrand wrote:
| let's hope they at least use Rust
| bubabug wrote:
| 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 wrote:
| Maybe glade will support Gtk4 still in this decade, meanwhile
| I rather use JetPack Composer.
| marcodiego wrote:
| 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
| nsizx wrote:
| That's okay, nobody will ever use these applications, so they
| don't pose a security issue to anybody.
| marcodiego wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| https://source.puri.sm/Librem5/community-
| wiki/-/wikis/Freque...
| SahAssar wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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?...
| vorpalhex wrote:
| 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.
| rvz wrote:
| 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.
| okamiueru wrote:
| Wouldn't the flutter sdk be viable as a desktop target?
___________________________________________________________________
(page generated 2021-08-15 23:02 UTC)