> 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.
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.
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.
The "phone stuck with black screen" thing happened to me on every android phone I ever had though (and here I can't restart the x session, I have to reboot it or take off the physical battery when things go really bad), so maybe it's more of a kernel level issue ?
Yeah I was about to say I have a very similar problem with my Nokia 3.4. I can usually hold power to reboot though, which I think after long enough it does itself. Sometimes I'm only aware of it (not currently using it, certainly not heavily) because it suddenly reboots itself.
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.
In this case, what's happening (based on what GP says, not personal experience) is the window server (phosh as a wayland compositor or Xorg in sxmo's case) is crashing, possibly (probably?) due to a crash in the Mali driver or some sunxi component managing the physical display output. Restarting the window server here would "reset" the relevant GPU bits, and get the display back.
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)
Sway in sxmo’s case, actually. I’m not sure what exactly is falling over, but the session is all still there, with the compositor (Sway or Phosh) still responding to I/O, and, from my very limited probing, still working perfectly… except that its screen output is dead and it doesn’t realise it. Nothing interesting in the journal or dmesg, for example. If the compositor had crashed, it would have been restarted automatically.
Ah, interesting, I didn't know they'd built an alternative shell around wlroots, I'd only tried it back when it was a bunch of shell scripts around dwm.
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...
Hmm, would be nice to be able to get it back on its feet in these cases without killing the session, though I haven’t had it fall over for a couple of weeks because I’ve been barely using it (and possibly because summer is passes on to autumn). Next time it happens I’ll see if a `swaymsg output DSI-1 disable` / `swaymsg output DSI-1 enable` fixes it. Seems to do something, Firefox clearly changes its scaling from 2 to 1 and back to 2 in the process. (If not, I dunno; `swaymsg -t get_outputs` only mentions one mode, 720x1440 @ 60.006 Hz, and --custom doesn’t seem to be working. What’s with that frequency? I know the sordid tale of 59.94 Hz, but I’ve seen these higher frequencies of 30 and a bit and 60 and a bit a few times.))
Successfully triggered it (drained half the battery, plugged it in with a couple of infinite loops going and a bit of hotspot usage), and alas, attempts at mode switching aren’t solving it: `swaymsg output DSI-1 disable && swaymsg output DSI-1 enable`, `swaymsg -- output DIS-1 mode --custom 360x720`, all this kind of stuff causes the screen to turn off and back on again, but not start working again.
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
Then a trace, including pc and lr being inside lima_devfreq_record_idle, which might point towards something about it not happening when the device is in active use. And yeah, lima is GPU driver.
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.
> Note that both PinePhone and pmOS have yet to reach "daily driver" status
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.
> Lately, I've been learning C programming solely on my Pinephone.
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.
The biggest problem with the iPhone to me is forced obsolescence. A device from 2014 (iPhone 6) is no longer able to run many apps, because it doesn't support iOS versions past 12. Many of these apps are essentially just web pages, so in principle the hardware should be more than capable of running them. But instead you are pushed to ditch perfectly functional and capable hardware in favour of a new model.
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.
I totally agree. Not just iPhones either but the Mac too.
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.
Ahem. You should be comparing iPhone upgradability with Android upgradability, most of which get stuck after a year or so. If they receive any upgrades at all.
Unless you carry you 2011 laptop around in your pocket, that is.
I am not saying Android is better - just using Apple as an example. Although it does seem like there are more options of at least reusing the hardware in some way with an Android device. I am not sure where exactly the problem is or how to solve it, but there seems to be something fundamentally wrong about the whole thing.
A battery, arguably along with storage, needs a very very good reason to not be upgradeable.
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?
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 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]
Worth noting that it's not just the technical end of UI construction that's lacking. Many open-source web projects have crappy UIs, too. I'm a long-time full-time developer, decades-long linux user, and also wrapping up a BFA in design, so I think my perspective is pretty balanced, here.
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.
> submitting design and usability improvements to open source projects
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
> submitting design and usability improvements to open source projects
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.
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.
It sounds like you've had some bad experiences, sorry for the bad ones :( I've had my own experiences and perspective, some good some less so. It's important to remember that making anything concrete requires tradeoffs to be made - ie less clean code to address edge cases, more complicated UX to accommodate important features, less functionality to increase UX, etc. It's always on a spectrum of completely ideal vs really crappy. For code and UX. I've been on different parts of that spectrum, but I think I caused the more harm than good when I went close to the edges.
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.
Not many bad experiences— I looked before I leapt. It's not a hard resource constraint in many cases— the resources just opt out of contributing. Despite the unicorn moniker, many designers know how to code! I've worked as a full-time developer for 12 years, and did comparatively simple but non-trivial systems-focused scripting in sys admin/support roles prior to that. Especially among more UX-oriented designers, most started in other careers, and many of those careers were related to software in some way. A developer I worked with until recently had a BFA in New Media from a top-tier art school. Most designers/developers I know just don't contribute design to FOSS because interfacing with FOSS projects for anything other than bug fixes and feature implementations is often a giant PITA.
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.
Firstly, a developer emotionally attached to a bad UI is not likely to propose significant enough of a change in your interface for this to concern you.
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
> Firstly, a developer emotionally attached to a bad UI is not likely to propose significant enough of a change in your interface for this to concern you.
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.
(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.
> 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.
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.
Not to be pedantic, but I'm fairly sure it's also "for free" with GTK2/3's "stack" dialogue. Don't think it's still the case with GTK4 though, I'm pretty sure all that gesture functionality was broken out into a separate library...
> 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.
> 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.
Have you seen Tauri?
(Happy user, for a couple of side tinkerings, not otherwise affiliated.)
Yeah I've seen tauri, but they're just using the glib bindings for webkit-gtk. So they're just sharing the preinstalled browser for rendering inside a webview.
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.
> 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]
* 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.
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 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.
Yes, it works, but I think the situation is fluid at the moment depending on distro, config, etcetera. Latest Sxmo on pmOS it works OOTB. You can find many other reports in the wild, for example https://www.reddit.com/r/pinephone/comments/rp3c14/deep_slee...
Hello there! Thank you all for discussing my article in such great detail, I'm glad to have sparked healthy discussion around mobile linux. That being said, I'm aware that I represent a minority of mobile linux users, as can be seen by the community poll on Pine64's blog [1], and that is one of many reasons I decided to publish my ideas. I've added a few things to my website, like images to my first post and a todo list page so that you can see what i'm working on and give feedback. Thanks for your support.
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)
While PinePhone is definitely an interesting product, GrapheneOS + Termux is such a versatile combination I've stopped looking at these "real Linux" phones.
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's hardening against the user being able to do things, not against corporate or government threat models. Software can only do a little bit on megacorp smartphone hardware even if it tries to help the user instead of locking them out.
> Software can only do a little bit on megacorp smartphone hardware
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?
Google has attempted to make sure the Pixel's hardware baseband modem is properly isolated from user space. But you can't trust it completely because the Pixel's baseband computer does have access to userspace RAM in terms of physical ability in the hardware. The GraphemeOS FAQ explains it here: https://grapheneos.org/faq#baseband-isolation
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.
It's still more sandboxed WRT at least filesystem access, and I thought Google had made changes to selinux policies that would increasingly break it, although I'm not immediately seeing a source to back up that memory. And in fairness, a custom ROM could fix selinux policies, but it's extra work.
Thank you for this. Can you please link to any resources for getting started in this vein? I did a quick Google search and didn't come up with a clear path forward to explore this option.
It's so nice that you can replace the mainboard as a regular user, if it's broken... or even fix it yourself, since the level of integration is not terribly dense and there's no epoxy/glue anywhere, and the shielding is not soldered to the board.
> With the convenient icon next to the clock in Sway
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.
> Gomuks: Ever wanted to get Matrix protocol notifications on your Pinephone, without the sluggishness of an Electron UI? Now you can!
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.
How can one make the PinePhone detect incoming calls on a regular basis using this method? It looks like the code sleeps for minutes at a time, which is ideal for fetching notifications for IM apps etc. but not for detecting incoming calls (which usually last about 30 seconds iirc before timing out/going to voicemail).
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)...
That's handy, thanks for letting me know! I assume that applications that are resumed from suspension can then continue checking for incoming phone calls and alert the user when necessary, much like how (from my 'experiments' with the PinePhone) pressing the power button to wake the phone will still allow applications to capture the keypress event.
That's not necessarily true. Instead of just suspending you can make "suspend" a runlevel which includes a service that periodically wakes the phone up so apps can manage connections to servers that might push data to them. I wrote my own stuff that does that and I think many distros include something similar now.
Because Linux userspace arguably sucks. While the kernel is excellent, there is no sane sandboxing (and I can’t communicate enough how truly terrible linux desktop’s “security” is. A single bash script could break absolute havoc), the IPC mechanism used to communicate between programs is fragmented and in my opinion the insistence that C should be used everywhere really holds back the platform.
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.
> why doesn’t mainline linux copy some things from android?
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.
Most Linux distros have standardized on AppArmor which provides the same basic featureset as SELinux while being a lot easier to manage (e.g. no file system hacks required, everything is set up via standard configuration mechanisms!).
Android has different security guarantees compared to desktop/server Linux. E.g. people should expect that none of the installed software can hijack the phone completely and that most damage from malware should be mitigateable by uninstalling malicious app.
People would be right to expect that no installed software can hijack the desktop completely as well, but unfortunately that is very much not the case.
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.
Okay, perhaps some qualification needed: There are Linux distros, both for mobile and desktop, that can probably be run completely from the GUI. Arch Linux is not one of them, and is vanishingly unlikely to ever be one of them - consider that on desktop, Arch doesn't even install a GUI by default, and this is not considered even remotely a bug.
Arch can be run entirely from GUIs if you want that and so install them. There isn't one 'Arch GUI' no, but there's not really one '<distro> GUI' either, for your choice of value for distro. (At most some more exotic/niche ones might limit what can be easily installed?)
My point is that Arch culturally has an expectation that users will be comfortable with the shell. Perhaps you can run the system from the GUI once it's set up, but you have to get there which means setting the system up starting from a shell.
Yes, true, sure. Not to disagree with you, but just to say I'm pretty sure Manjaro (which is an Arch-derived distro with a bunch of packages/maybe bit of config chosen for you) can be GUI installed with whatever DE and probably never touch a shell just as well as Ubuntu or whatever.
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.
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.
Personally I far prefer the CLI even on a touch screen because I don't get controls popping/sliding/whizzing underneath my fingers when I'm trying to do something else.
Somewhat related to this, I’m planning a full switch away from Apple *OS to Linux this year, and am looking for a good replacement for my iPhone. I’m aware of the Pine Phone of course, but what other mobile phone players are in the market these days that are not android based? A robust, solid and stable Linux phone that can do at least the basics (calls, MMS, internet, Bluetooth audio, and camera) would be AWESOME.
I’d just like to know what my options are before settling on what to buy.
You can try one of many non-Google variants of Android (LineageOS, Calyx, /e/, Graphene) or go for Sailfish OS (the successor to Meego/Maemo). There's also postmarketOS, and Ubuntu Touch, but I'm unaware as to how well they're supported.
I actually was not aware of the PineTime. As a huge Apple Watch/WatchOS fangirl, I'd honestly love to check out a far less restrictive smartwatch environment to mess around with.
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? :)
Any news about running Android apps inside Pinephone?
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.
Not pratical: I'm using Waydroid on Fedora. Compared to Anbox, the only requirement that changed is the need for a Wayland compositor.
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.
Thanks, that is still progress. You mean the Play Store? A possible alternative is to use Aptoide for downloading APKs or maybe simply getting them directly from a cellphone.
Nice. Recently received my PinePhone keyboard add-on and am looking to replace my Android phone as a daily driver quite soon. This information will prove useful.
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
[1] https://postmarketos.org/