31–40 of 120 posts
I don't think I can handle a CLI-based phone.
The external keyboard probably makes it tolerable, but yeah, it's likely hard to deal with. I'd love to see how it works in practice, and how long the author keeps it up.
Earlier quoted context omitted.
It's only CLI-based because the writer seems to be using the phone that way. That's how it appears to me anyway. Kind of like Linux on the desktop ... Everything I've seen about the PinePhone suggests that you can go full GUI.
Not in my experience with Arch on the pine phone. Arch was the only distro where almost everything worked, but I have to do CLI updates. The GUI isn't really there yet for all of the basic and necessary administration activities.
Advice for anyone considering it: * There are rough edges, but the basics are there: calling/SMS/4G/WiFi/audio/browsing/suspend. * If you want to try it, put https://xnux.eu/p-boot-demo/ on an SD card and plug that into your PinePhone. That has a bunch of different distros and UIs on it. * To keep up to date, follow https://www.pine64.org/blog/ and https://linmob.net/ I'm excited to use a community driven phone!
Did they ever fix the modem disappearing on suspend? I have the latest kernel (as of a month ago) and a build of bitkorgii's modem firmware from last year but I still need to reboot the phone every time I pull it out to check my texts. EDIT (I'm throttled and can't reply): I already have a script/service/runlevel that handles periodically waking the phone for notifications (I wrote it fall 2020 when I got mine.) I'm…
OP's setup looks actually pretty similar to my one, though where the pinephone really - really - shines is pentesting. The compatibility with external Wifi USB adapters and BT hardware like the ones from scott's gadgets make it an amazing pentesting device. For serious mobile-friendly usage I don't think that we can build UIs the way they're built on Linux systems anymore. I challenge every defender of that GTK/QT cr…
With amateur developers, their code becomes less reliable the further you get from their development environment. The effect is similar the further you move from a developer's primary keyboard/mouse/big screen computing interface. The difference between interfaces intentionally designed by specialists and functionality exposed through a GUI by a developer becomes more consequential. Sadly, most open source projects not run by larger funded organizations are kind of allergic to usability contributions from domain specialists, so that knowledge just doesn't get rolled in like it does with commercial projects.
Most of the other developer/designer types I know don't even bother submitting design and usability improvements to open source projects. It's just not worth fighting people to make their software less awful to people who aren't already experts in it. It's a lot of work to put into something that will just get bikeshedded into oblivion by people emotionally attached to a bad ui. I don't know any developer who'd submit code to a repo controlled by people hostile towards code improvements, either.
The Nielsen Norman group has some good stuff on usability within hierarchical organizations— I'd love to see similar organization-level reasoning about this stuff for small dev groups. I'm positive these two adjacent and necessary roles can function together without a product manager saying so. In their original usability matrix, "developer-centric usage" was directly above "usability hostile" but they've combined those categories, and especially with non-desktop platforms, that's absolutely the right move.
> 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 e…
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…
“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.
Advice for anyone considering it: * There are rough edges, but the basics are there: calling/SMS/4G/WiFi/audio/browsing/suspend. * If you want to try it, put https://xnux.eu/p-boot-demo/ on an SD card and plug that into your PinePhone. That has a bunch of different distros and UIs on it. * To keep up to date, follow https://www.pine64.org/blog/ and https://linmob.net/ I'm excited to use a community driven phone!
Did they ever fix the modem disappearing on suspend? I have the latest kernel (as of a month ago) and a build of bitkorgii's modem firmware from last year but I still need to reboot the phone every time I pull it out to check my texts. EDIT (I'm throttled and can't reply): I already have a script/service/runlevel that handles periodically waking the phone for notifications (I wrote it fall 2020 when I got mine.) I'm…
* biktorg's firmware (now flash able via GNOME Firmware or fwupdmgr)
* NetworkManager with --test-quick-resume-suspend flag.
* Crust/ATF as platform firmware (e.g. Tow-Boot)
* eg25-manager to manage the modem
This will be available transparently to most users, but some distros might not be there yet.
PostmarketOS and Mobian are safe bets.
Earlier quoted context omitted.
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…
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 t…
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.
OP's setup looks actually pretty similar to my one, though where the pinephone really - really - shines is pentesting. The compatibility with external Wifi USB adapters and BT hardware like the ones from scott's gadgets make it an amazing pentesting device. For serious mobile-friendly usage I don't think that we can build UIs the way they're built on Linux systems anymore. I challenge every defender of that GTK/QT cr…
> though where the pinephone really - really - shines is pentesting. Its worth having some near field communication pentesting apps on it, as many mental health hospitals use NFC bracelets for locking people up and to control what corridors they can get access to within the building so it could be an easy way to walk out of those sorts of establishments where lock and key are no longer used. https://en.wikipedia.org/…
So one would have to either DIY something through the pogo pins or go over USB as of now.
Earlier quoted context omitted.
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 t…
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.
It also will (effectively) restart the whole graphical session, e.g. close all GUI things, so not feasible to do every time you cycle the screen, at least for most people.
(some OSes and window servers like the Windows GUI stack can restart the GPU driver without killing the GUI, but Linux isn't ... particularly capable of this, at any part of the stack, AFAIK at least)
> 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 e…
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.