My Pinephone Setup
hamblingreen.gitlab.io
hamblingreen.gitlab.io
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
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.
“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.
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)
If the GPU and window server are still okay, you might get away with forcing a mode-switch. Maybe it's not the GPU itself but some supporting chip that handles the LCD driver, and changing the resolution or something else would reset it without destroying the session. Hmmm...
Actually, though, I’ve found something useful in dmesg, which is making me suspect that the other time I went looking I forgot to look there and only looked at journald.
[Mar14 21:17] [drm:lima_sched_timedout_job] *ERROR* lima job timeout
[ +3.422897] lima 1c40000.gpu: fail to save task state from sway pid 3227: error task list is full
[ +0.000115] lima 1c40000.gpu: gp task error int_state=0 status=0
Well, it’s something. Hmm, wonder if I can be bothered delving further. It doesn’t bother me as much as it possibly should, I really don’t interact with my phone directly all that much.
(Seems to be reported as https://gitlab.freedesktop.org/mesa/mesa/-/issues/6036.)
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.
Meh, I don't find such blanket statements compelling.
My Pinephone is a perfectly good "daily driver": I use it for phone calls, SMS, email, scanning QR codes, displaying QR codes (train tickets, parcel deliveries, etc.), Web browsing, etc.
People also said the same thing about OpenMoko, yet that was my "daily driver" for a decade.
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.
This might be ok for some enthusiasts but not ok for someone wanting to use his phone at it's full capability.
Ha I like this guy already. That’s my kind of crazy :)
It is an interesting experiment to be sure. I’m a big geek and love Linux but not sure I would go so far as to run i3 on my phone like this but more power to him and I’m glad there are people trying different things out and seeing how it goes.
I know I’m getting old because every year I appreciate a simpler phone. On the desktop sure I like to mix it up with less common approaches that give me more flexibility but for my phone I keep it simple. I don’t really want my phone to be a full on desktop computer experience tbh.
I use my phone for pretty basic tasks. Podcasts and music mostly. Some very casual web use and maybe a dozen apps. I don’t email on my phone (other than reading). I don’t message much on it either instead using a desktop app as I feel I have more “room to breath” and compose my messages more slowly unless it’s a short reply. And some light in the moment photography.
This is why I stick to an iPhone. It doesn’t allow me to tweak it to the max. It does what I want just fine and I am grateful for the restrictions rather than allowing me to build some handheld Frankenstein second computer. Right tool for the job and all that. For me anyway :)
But I am glad things like the PinePhone exist even if I don’t use them personally.
Compare that with the PC world. A laptop from 2011 can still both run Windows 10 and pretty much anything you want, assuming your hardware is able to process it fast enough - which for many use cases it is.
Unless you carry you 2011 laptop around in your pocket, that is.
Old Nokia phones that are 20+ years old can still be used. PCs and consoles from the 90s are still perfectly usable with their original software. Smartphones have been 'good enough' for nearly a decade - why is there not a legitimate 'buy it for life' version?
reason: https://www.boatinternational.com/yachts/editorial-features/...
very good? Nah.
At least the pendulum is swinging away from flashy and more towards useful with the MBP for the moment.
Consider the performance difference though.
Geekbench Geekbench Geekbench A15 A15
1-Thread N-Thread Metal ST %faster Metal %faster
iphone 5s 260 447 21 552% 67619%
iphone 6 306 567 450 454% 3060%
iphone 6s/SE 528 967 2411 221% 489%
iphone 7 723 1283 3094 134% 359%
iphone 8 910 1873 3732 86% 281%
iphone XR 1104 2190 5310 54% 167%
iphone 11/SE2 1311 3271 7330 29% 94%
iphone 12 1574 3878 9177 8% 55%
iphone 13/SE3 1695 4648 14221 ---- ----
I have a Dell Latitude laptop with a 3rd gen Intel i5, 8GB RAM and a 500GB SATA SSD that runs Fedora (any other other Linux) perfectly as well as Windows 10 (and 11 even though it apparently doesn't meet the new requirements). Sadly a Mac from 2011 cannot run Big Sur. Sure it is slow for heavy, modern development but for a lot of things it is just fine (well except that 768p screen oof)
Even more annoying is how cut throat Apple are with removing old technologies. It is a small pain point for me that I cannot run Plants vs Zombies on my Mac anymore because it is a 32bit program and Apple removed 32bit support a couple of years ago.
I understand why Apple does it but I also dislike it a lot. No system is perfect but Apple go out of their way to make things harder imho. Even more so with how frustrating it is to virtualise macOS and get performance anywhere close to what we can get with Windows or Linux in a VM.
It is a sad fact that I don't look at macOS nor iOS as some kind of long term investment. I use them for what they are right now and nothing more. I ensure I am not dependent on Apple's systems and services. I use them because right now they give me the least hassle (they work well, have good app support, etc) but I would happily switch away in the blink of an eye to something else should it come along. I have no loyalty to Apple. I use them because they are convenient to me, the moment they no longer are I will move on.
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 crap to build a swipeable sidebar into their native and responsive UI. If it takes more than 10 minutes, you lost, cause that's what it takes to use CSS, even without any IDE or toolkit.
I wish GTK wasn't built inhouse and would focus on using established toolchains instead of reinventing their own programming language ecosystem with every new release. Nobody wants to use vala. Nobody wants to use glade. Nobody wants to use any of the ecosystem, because it's much more pain than any established UI framework's methodology.
There's a reason why everyone uses electron, and the reasons are not the same why you think your GNOMey toolchains matter. And this has to stop. Otherwise everybody will hop on QT at some point.
I still hope that webkit, javascriptcore and nodejs can be combined into something that allows to easily call C-ABI compatible libraries without 300MB of build size like electron. [1]
Build it
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/wiki/Near-field_communication#Criti... https://resources.infosecinstitute.com/topic/near-field-comm...
So one would have to either DIY something through the pogo pins or go over USB as of now.
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.
Can you give a link?
What format does this take. My experience is that more often than not, design and usability improvements are abstract (mockups) and requires implementation by someone else. If the improvement is a working update to a QML file that improves the interface, I'd say chances are that it would be received well.
Sorry if this sounds defensive, but
> bikeshedded into oblivion by people emotionally attached to a bad ui
doesn't sound fair to me.
UI design as a discipline fundamentally assumes the person designing the interface doesn't intuitively understand what's better or what's worse— they should investigate, check, and confirm their strategies. Someone posting wireframes is almost certainly looking for feedback to test/refine their approach before they start coding because fixing is a whole lot more work in code than on a wireframe even if they can code. If they can't code and nobody feels compelled to implement it, then that's that— just like any other feature on an open source project.
As an aside, I get flack from other developers when I say designers and their contributions are usually considered less valuable. When I don't, "surely we couldn't suggest existing contributor's spend time on such tasks" is one of the first responses.
Thoughtfully facilitating task completion for humans vs exposing software functions in a UI is like designing good, scalable, maintainable software vs. making functions valid in a programming language that generally work together to accomplish a task. Consider an architecturally unsound project coded by folks with the most rudimentary development skills. Would you try fixing it in bite-sized PRs vetted by the people who made it— none of whom see a problem with the way it is? Even starting such an undertaking would be pointless.
Similarly, the chance of any significant usability improvement being miscible in the standard flow of bite-sized PRs isn't great. If a project is on year 7 of using their undesigned UI, most logical steps between A and Z, even if the code is functional, have broken interfaces. What are the chances of a project going with the flow, there? You'd need to love that software more than your spouse to take that on.
Beyond that, good usability is fundamentally informed by user needs, not architecture, library features, the existence of other elements, or developer preference. Also, UI changes are often fussy, require a ton of testing, and result in a ton of work that doesn't show up in the final code. That's true for all code to some extent, but developer reviewers see it more easily in a clever little algorithm than organizing elements in an input box. That makes them less likely to get the weight they deserve when encountering conflicts, even if the conflict is an uninformed opinion that nobody else around is informed enough to counter. I can't imagine any developer submitting code to a repo where the tables were turned.
> Sorry if this sounds defensive, but >> bikeshedded into oblivion by people emotionally attached to a bad ui > doesn't sound fair to me.
Not really sure how to respond to that. People are worse at taking critique for skills they aren't confident in. Ever give a brand new developer a code review? Yeah. That’s about what it’s like critiquing an open source project’s beloved “quirky” interface.
Even users become attached to bad interfaces because they put in the effort to learn how to use it and assume everybody else matches their use case. It's like bad UI Stockholm syndrome. I cite any discussion where people express frustration with the interfaces for git or Gimp. Even implying they aren't on par with the usability of commercial offerings, let alone insufficient for their basic tasks, will get you flamed.
I've seen this hostility many places, but I can think of one moderately popular app in particular that many non-developers come across. It's function requires fast, smooth input, and to facilitate that, has native clients on most platforms (including mobile) and is modestly funded by their very affordable, optional cloud storage service. In their discord board and issues, even contributors complain about clunkiness, counter-intuitive flows and inconsistencies between clients. Responses range from "eh, it's in the docs" to "it's idiomatic in that OS and totally unavoidable," to "yeah, we should really figure that out. It's on the usability project board." Actual usability discussions are rudderless, shoulder-shruggy, and fizzle out with things like conversations about which font people find most readable. I thought it would be a great place to contribute my expertise. I did one more search searching the forum for 'wireframe,' and every. single. thread. started by a designer posting nicely documented proposals w/user flow diagrams or mockups specifically asking to __kick off a conversation__ about how a more thoughtful UI might look was unceremoniously buried with comments like "what do you expect anyone here to do with this information?" and "the X to close that window is unnecessarily large according to X guidelines and XYZ elements are too close together, etc." and "please don't ruin my app by making it pretty."
If they were non-technical people talking about a technical proof of concept you posted, would you take the time to break it down into tiny bite-sized PRs and submit them? If most projects you wanted to contribute to acted like that, how soon would you stop trying? It's just not worth the hassle until design knowledge and labor are more valued, fundamentally.
I don't really know where I'm going with this, but do know that your expertise and labor carries value! And finding the right place to contribute can take some time.
Facing critique about work we aren't confident in sucks. Most people reflexively respond with defensiveness, dismissiveness, or just shut down and ignore it. Since most FOSS UIs were created by people without subject matter expertise, most who make decisions about them have the expected response. It's like giving a brand new developer a code review. Calmly explaining how to practically reason about algorithmic complexity won't stop many from insisting a thrice-embedded loop with database calls that gets called every time an event loop runs is the best possible solution— at least for a while. Sometimes you can argue them out of it. Sometimes you just have to say "trust me— it might not matter in your dev environment, but this is fundamentally broken and needs to change."
That doesn't work with FOSS projects, and even getting to that point in the design phase takes a significant amount of work!
Even at work where a project leader is assigning tasks based on quantifiable business needs, dev teams often see design as superfluous. Most FOSS projects don't have that level of oversight. Fighting glib, dismissive, patronizing arguments born from assumptions and egos of people who believe the topic is somewhere from back-burner importance to superfluous just isn't worth it. I'm certainly not going to spend a bunch of time logically analyzing user goals and figuring out the most logical paths and visual cues to help them achieve those goals when I have to fight through that to even start coding.
Sometimes a polished user flow really is superfluous— anyone who sets up procmail enough to care about its usability will soon learn their way past its inscrutable configuration. But most applications aren't like procmail, and most FOSS interfaces aren't sufficient for their purposes. It's sad to see commercial software consistently trounce functionally identical or superior FOSS because of usability. Word of mouth + free could trump damn near any marketing/advertising campaign if people actually liked using it.
How does a maintainer like me who isn't a domain expert tell the difference between:
1. A submission created by a domain specialist
2. A submission created by someone who became "emotionally attached to a bad ui" change/feature
?
Secondly, how would you, as a maintainer, vet a code change outside your best-known languages or paradigms? For that matter, how do you choose a mechanic if you're not a mechanic? How do you choose a caterer if you're not a chef?
Solicit outside evaluation assistance by asking for experienced design input on your repo page, newsletter, or other community gathering place. Look at previous work. Ask for portfolio links if you wish. Ask well-thought-out questions about: paths to accomplish tasks in the new vs the current setup; why specific changes are beneficial, to whom, and if it's deleterious to others; larger user goals or user groups seemingly left behind; important assumptions you think they made, fundamental implementation concerns without getting bogged down in inertia, etc. Experienced designers are used to having their work challenged and critiqued— that's true even for fresh college grads if they came from a design school.
Bikeshedding, overt dismissiveness, unnecessary defensiveness, tangentially-related gotcha questions to make the asker feel less insecure about not being the expert, and other defensive/ avoidant behaviors look the same without code involved. If you see your community engaging in them, politely ask them to change their tune or butt out. You'd do the same if a designer on your team started an ill-informed group dart-throwing session at someone sharing a technical proof-of-concept. If the person challenging the designer can't justify their assertion as well or better, you should consider if they're someone you should trust with that decision.
Thirdly, if you have to ask then it's probably never been a concern. Design is a communication field. Their proposal should be in plain language, logical, entirely justifiable, and almost certainly conceptual rather than in code. If they submit a cold PR out of nowhere with a significant interface modification and little to no justification, I wouldn't consider them a domain specialist regardless of what their portfolio looked like.
If you've got some detailed interface modification proposals you're just not sure about, a good
a) They have, b) it's definitely not rare, and c) it is an enormous time-drain and source of frustration for maintainers in the FOSS community. Such devs will simply feign expertise at every turn and choose to die on the hill of their submission. In fact my previous run-in with such a dev nearly burned me out on FOSS development altogether.
> Their proposal should be in plain language, logical, entirely justifiable, and almost certainly conceptual rather than in code.
It's difficult to exaggerate how much I'd welcome such a submission! In fact I have never read such a proposal in any issue tracker, including my own. Do you have a link to an extant example, preferably one that got implemented? I honestly don't care if it's FOSS or not, I just want to read the communication back and forth.
Typical commercial pre-wireframe research and proposal: https://web.stanford.edu/~eadolfo/cis-redesign/attachments/p...
More common in FOSS: https://github.com/openstreetmap/iD/issues/759 https://github.com/stashapp/stash/issues/1549 https://github.com/newrelic/nr1-groundskeeper/issues/3 https://github.com/creativecommons/creativecommons.github.io... https://github.com/godotengine/godot-proposals/issues/1823
(from google searching for things like site:github.com "wireframes" "design" "proposal")
> a) They have, b) it's definitely not rare, and c) it is an enormous time-drain and source of frustration for maintainers in the FOSS community.
I can't claim to be omniscient but I've been a constant open source contributor for 10 odd years and heavy user for nearly 25 and I've never seen that, or even heard people complain about it, let alone enough to be an enormous problem. I've seen ill-conceived gripe lists, superficial 'lets make this look cool,' and 'this font sucks' type issues periodically. None of those are serious design proposals any more than "make everything faster" or "I hate when your program does x" or "I think we should get rid of this and make it in react" are serious development proposals.
I'll happily put together a guide on cutting through bullshit UI change proposals if I could evaluate some issues/PRs for open source repos that constantly experience this problem.
You get this for free with Qt's QML Drawer type, and it's also a declarative UI, so you don't have to implement anything yourself[1]. It's swipeable by default.
You also get it for free with Flutter's NavDrawer.
[1] https://doc.qt.io/qt-5/qtquickcontrols-sidepanel-example.htm...
Have you seen Tauri?
(Happy user, for a couple of side tinkerings, not otherwise affiliated.)
My goal, compared to tauri (or webview/webview), is to offer an alternative, slimmed-down version that can be used to bundle apps on mobile and embedded devices. I mean, from a security point of view you have to assume that Edge and Chrome are compromised, so all your tauri apps will be compromised too.
So in retrokit I removed things like the massive plugin legacy in webkit, or pdfkit integrations and other stuff that was unnecessary, or webgl, or canvas, or the static geolocation API (which comes with a static copy of the ip<>geolocation database) etc.
* 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!
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 talking about the bug that causes the modem USB device to disappear and not get probed again after a random number of wakes from suspend. It's not an issue if you're only on WiFi and use VOIP but some people get annoyed that they can't call me while I'm driving.
* 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.
Oh, and if you have any questions at all, feel free to ask below or contact me through any means listed on my website. (email: hamblingreen@hotmail.com)
You get access to modern power-efficient hardware with a Google Pixel, a proper touch interface, a ton of hardening under the hood, and then to top it all off, Termux offers a very usable Linux environment.
That isn't true at all. Do you have a source for your implication that the Pixel's trusted boot chain is compromised, or that remote attestation of software+hardware is backdoored?
But the pinephone baseband literally does not have the physical/hardware capability. You don't have to trust software from Google or Qualcomm or Pine. https://www.pine64.org/2020/01/24/setting-the-record-straigh...
Your request for proof that Pixel's trusted boot chain is compromised or other things is irrelevant both because of the above, and because it's all controlled by the very company you have to worry about. The fox has the keys to the henhouse. It owns the henhouse.
Wait what? I never even considered this. I am in love with Sway. Having a tiling window manager on a phone might be quite the facinating use-case, mapping swipes to tiling actions similar to [1]. I think this article just won me over to try a linux phone.
Not what I was expecting to see when I opened this link!
Good write up, I'll have to grab one of these soon.
AFAIK: not without draining the battery you can't. You have to either disable the deep sleep mode ("CRUST") while the screen is blanked or leave the screen on, otherwise any Matrix client including gomuks won't run at all once you turn the screen off. (So no notifications for incoming messages.)
Maybe this isn't a problem if you're a very occasional Matrix user, and the battery drain even with everything running isn't too bad, but if you've been using it as long as I have and are in a lot of active rooms it's just not workable.
I would assume that suspending and waking, say, every 10 seconds could allow for detecting incoming calls but not be as energy efficient (or in the worst case, more detrimental than just keeping the phone on)?
imo I'd implement this by not suspending (except for some kind of 'battery saver' mode) and just keeping the screen at 0% brightness (which I assume is one of the primary consumers of energy from the battery cell)...
Look at the columns named "postmarketOS", "Kali Linux" and "Ubuntu Touch".
I remember that wen Nokia did N900, it was pretty compatible with mainline Linux.
Compared to that, android has a well-architected sandboxing with very gradual permissions, SELinux for the remaining features (sure, mainline linux distros also have it from time-to-time but it is not used there to its full extent. Android runs every application as a different user for example, making security boundaries much more explicit), so I would rather ask, why doesn’t mainline linux copy some things from android?
Also, don’t get me wrong, I really like using linux OSs, but they do have plenty of space to improve.
Because Android is actively interfering with:
- a shared filesystem where you can manage files from a graphical file manager, terminal, Git, editor/IDE, compiler, Python runtime, photo manager, and hex editor
- Being able to debug apps from other apps (Mac disables lldb altogether unless you disable SIP, then you need to type your password every time, and Android ships with no debugging tools at all)
There is absolutely zero reason for any random app to have access to arbitrary files on my computer. Why should a random bash script be able to wipe out all my family pictures?
Also, there is nothing inherent in the android model that would make a “shared filesystem” infeasible - it is just the wrong default. With specific access rights sure, it should be allowed.
The two more popular alternatives are Plasma Mobile and Phosh.
https://developer.puri.sm/Librem5/Software_Reference/Environ...
Everything I've seen about the PinePhone suggests that you can go full GUI.
Saying that actually you could achieve the same thing with `arch-install` which is now bundled in Arch's official images, you'd only briefly have to deal with its TUI option-based interactive installation, nothing manual.
This is Pinephone Pro Explorer Edition able to run VS Code. External display is buggy though. On Pinephone the lag is really bad for VSC but not so on PPP.
Mobian Phosh has best external display performance I found
KDE Plasma Mobile is the one that is closest to a phone IMO regarding UI/UX.
https://www.pine64.org/2022/01/31/pinephone-community-poll-r... shows most PinePhone users don't use the CLI-based interface.
I’d just like to know what my options are before settling on what to buy.
I’m just trying to assess what the options are before settling on what to buy.
I have a lot of interesting ideas that I've unfortunately been waiting for the WatchOS API's to catch up to, and I'd maybe be interested in getting on that PineTime train.
Has anyone purchased a PineTime? Can anyone give a bit of first-hand experience on what the experience is like? :)
I know it runs on some phones but you'd really have to check and/or ask on the forums: https://forum.sailfishos.org/
Maybe this thread is helpful: https://forum.sailfishos.org/t/sailfish-in-the-usa/5307
It was more than an year since I've last followed the progress on this topic. If someone here has some pratical experience on the topic, would love to hear your thoughts.
Google Apps: installed but not approved by Google. I am supposed to request access to Google but 30s after I made the request the error was still there. Will try again next weekend, hoping it was just a cache issue.