4 ms·

> All this time I was aware that the core of my phone, it's kernel, was closed source and probably out-of-date. Android runs the Linux kernel which is GPLv2 (a

> All this time I was aware that the core of my phone, it's kernel, was closed source and probably out-of-date. Android runs the Linux kernel which is GPLv2 (and thus open source). For a couple reasons this isn't seen as "true" Linux or open source. 1. Drivers are often proprietary 2. SoC manufactures release their versions of the Linux kernel without integrating them into the "upstream" manage by Linus Torvalds so even open source drivers are hard to use. 3. Android uses an non-standard user-space and UI (running apps in the DalvikVM). "Normal" or "desktop" Linux tends to use the GNU userspace with one of several Freedesktop.org compliant desktop interfaces on top. The use of the GNU userspace leads the FSF to call this GNU/Linux lead to the GNU/Linux naming controversy [0]. However, because Android uses the Linux kernel, it is possible to bring "real" or "desktop" Linux to old Android handsets. postmarketOS [1] is a project intending to do this. Several old Android SoCs now run a "close to mainline" "normal" Linux kernel and can be used as Linux phones. I actually use a OnePlus 6 running postmarketOS. [0] https://en.m.wikipedia.org/wiki/GNU/Linux_naming_controversy https://en.m.wikipedia.org/wiki/GNU/Linux_naming_controversy [1] https://postmarketos.org/ https://postmarketos.org/

zozbot234 5y ago
Note that both PinePhone and pmOS have yet to reach "daily driver" status, especially if you actually care about using the phone featureset, want to run a proper mainline (not vendor) kernel and (as for pmOS) want to go outside the narrow subset of hardware that's endorsed by that project as 'working properly'. Also, many users have noticed that phone/tablet/mobile hardware in general tends to become super flaky when you actively try to use it for intensive general-purpose workloads, as with mainstream Linux apps. It seems that some power and/or thermal limits are easily exceeded with no real warning, and lockups/reboots can result. Dealing with this would require extra features in the kernel and/or the basic system software to assess indicators of available resources, and throttle the system if it seems to be running outside "reasonable" conditions. Implementing this in a way that can work generally on different kinds of hardware is of course possible, but not easy by any means.
- chrismorgan 5y ago
  As an example of the flakiness: if I use my PinePhone heavily, the screen tends to stop working spontaneously, so that if on at the time of failure, it ceases to update, and when turned off and on again it will be black. Touch input still works. Restarting the graphical session (e.g. ssh in and run `systemctl restart phosh` for phosh or `systemctl restart tinydm` for sxmo) fixes it. “Heavily” tends to mean at least three of (a) heavy hotspot usage, (b) heavy CPU usage, (c) plugged in/charging, and (d) screen on, but if I’m physically using it it seems less likely to happen. Note that this is mostly with ambient temperatures of 25–30°C; come winter, I suspect it will happen less often. Plus there’s also the screen flickering thing, that sometimes, mostly when it’s been being used heavily but sometimes when it’s been idle and barely even warm, the screen is all flickery and ghosty when you turn it on one time, in which case it will normally stay like that for quite some time. That I observed right from the very start, under whatever the default OS was (Alpine, I think?, with Plasma; I subsequently switched to DanctNIX Arch with Phosh, and more recently from Phosh to sxmo). I have no idea if these things are typical or not, or if there are known solutions. I haven’t looked. They don’t tend to bother me much, I don’t really depend on a phone except for my internet supply.
  - robbedpeter 5y ago
    Maybe tie those systemctl commands to the power button and state, so it restarts the screen every time you blank the screen, or when coming back on use a restart for the service? I have a feeling mainstream phones use all sorts of these ux hacks in the background - it only looks good, under the hood is just as messy and chaotic as any other software/hardware collision.
    - megous 5y ago
      LCD controller is restarted/reinitialized every time you "blank" it. So this would be useless. Likely GPU driver/mesa/compositor crashing. I never have any issues with the screen when using i3wm (with GPU acceleration disabled). These bug reports would be more useful, if the OP did some debugging/log hunting.
    - 5y ago
js2 5y ago
> running apps in the DalvikVM Pedantic: The DalvikVM was replaced by the Android Runtime since Android 5.0. ART used ahead-of-time compilation of dex code to native code. https://en.wikipedia.org/wiki/Dalvik_(software) https://en.wikipedia.org/wiki/Dalvik_(software) https://en.wikipedia.org/wiki/Android_Runtime https://en.wikipedia.org/wiki/Android_Runtime
- blendergeek 5y ago
  Thank you for the pedantry. I learn new things every day.
DeathArrow 5y ago
Apart from a device called "Purism Librem 5" none of the listed devices have fully functional hardware. [1] This might be ok for some enthusiasts but not ok for someone wanting to use his phone at it's full capability. [1] https://wiki.postmarketos.org/wiki/Devices https://wiki.postmarketos.org/wiki/Devices

zozbot234 5y ago

Note that both PinePhone and pmOS have yet to reach "daily driver" status, especially if you actually care about using the phone featureset, want to run a proper mainline (not vendor) kernel and (as for pmOS) want to go outside the narrow subset of hardware that's endorsed by that project as 'working properly'. Also, many users have noticed that phone/tablet/mobile hardware in general tends to become super flaky when you actively try to use it for intensive general-purpose workloads, as with mainstream Linux apps. It seems that some power and/or thermal limits are easily exceeded with no real warning, and lockups/reboots can result. Dealing with this would require extra features in the kernel and/or the basic system software to assess indicators of available resources, and throttle the system if it seems to be running outside "reasonable" conditions. Implementing this in a way that can work generally on different kinds of hardware is of course possible, but not easy by any means.

chrismorgan 5y ago
As an example of the flakiness: if I use my PinePhone heavily, the screen tends to stop working spontaneously, so that if on at the time of failure, it ceases to update, and when turned off and on again it will be black. Touch input still works. Restarting the graphical session (e.g. ssh in and run `systemctl restart phosh` for phosh or `systemctl restart tinydm` for sxmo) fixes it. “Heavily” tends to mean at least three of (a) heavy hotspot usage, (b) heavy CPU usage, (c) plugged in/charging, and (d) screen on, but if I’m physically using it it seems less likely to happen. Note that this is mostly with ambient temperatures of 25–30°C; come winter, I suspect it will happen less often. Plus there’s also the screen flickering thing, that sometimes, mostly when it’s been being used heavily but sometimes when it’s been idle and barely even warm, the screen is all flickery and ghosty when you turn it on one time, in which case it will normally stay like that for quite some time. That I observed right from the very start, under whatever the default OS was (Alpine, I think?, with Plasma; I subsequently switched to DanctNIX Arch with Phosh, and more recently from Phosh to sxmo). I have no idea if these things are typical or not, or if there are known solutions. I haven’t looked. They don’t tend to bother me much, I don’t really depend on a phone except for my internet supply.
- robbedpeter 5y ago
  Maybe tie those systemctl commands to the power button and state, so it restarts the screen every time you blank the screen, or when coming back on use a restart for the service? I have a feeling mainstream phones use all sorts of these ux hacks in the background - it only looks good, under the hood is just as messy and chaotic as any other software/hardware collision.
  - megous 5y ago
    LCD controller is restarted/reinitialized every time you "blank" it. So this would be useless. Likely GPU driver/mesa/compositor crashing. I never have any issues with the screen when using i3wm (with GPU acceleration disabled). These bug reports would be more useful, if the OP did some debugging/log hunting.
  - 5y ago

js2 5y ago

> running apps in the DalvikVM Pedantic: The DalvikVM was replaced by the Android Runtime since Android 5.0. ART used ahead-of-time compilation of dex code to native code. https://en.wikipedia.org/wiki/Dalvik_(software) https://en.wikipedia.org/wiki/Dalvik_(software) https://en.wikipedia.org/wiki/Android_Runtime https://en.wikipedia.org/wiki/Android_Runtime

blendergeek 5y ago
Thank you for the pedantry. I learn new things every day.

DeathArrow 5y ago

Apart from a device called "Purism Librem 5" none of the listed devices have fully functional hardware. [1] This might be ok for some enthusiasts but not ok for someone wanting to use his phone at it's full capability. [1] https://wiki.postmarketos.org/wiki/Devices https://wiki.postmarketos.org/wiki/Devices