Fedora on the PinePhone: Pipewire Calling(odysee.com)
odysee.com
Fedora on the PinePhone: Pipewire Calling
https://odysee.com/@linmob:3/fedora-on-the-pinephone-pipewire-calling:1
90 comments
UI responsiveness and polish is a lot better than what I would have expected. Pinephone and mobile Linux are coming a long way!
I unfortunately must disagree. I have had a Pinephone for over six months and I really dislike using it, in spite of my looking forward to getting a nearly completely libre phone. First of all, the UI is much less responsive than my old Nokia N900 that uses 12-year-old technology. On Phosh, it takes about five seconds just to show the screen where you can turn wifi on or off, for example.
Battery life is also a shambles; I thought about using my Pinephone at least as a music player, streaming the music to my Bluetooth headphone amp, but it often happens that playing a single album with the screen off completely depletes the battery.
Battery life is also a shambles; I thought about using my Pinephone at least as a music player, streaming the music to my Bluetooth headphone amp, but it often happens that playing a single album with the screen off completely depletes the battery.
Well, it is a community project and product. Remember: Nokia was a market leader back when the N900 came out, and they had developed Maemo for years with the 770 (2005), N800 and N810. The appropriate point of comparison IMO would be the OpenMoko Neo FreeRunner, and while that was fun the PinePhone is already doing a lot better.
BTW, if you miss Maemo, try Maemo Leste (https://leste.maemo.org, if you want to get a glimpse before trying see https://linmob.net/videos/#maemo-leste).
BTW, if you miss Maemo, try Maemo Leste (https://leste.maemo.org, if you want to get a glimpse before trying see https://linmob.net/videos/#maemo-leste).
Maybe maemo with modern ofono (derived from mer?) Would work on pinephone.
Maybe megous has a better idea, but I believe bt requires keeping the wifi radio powered as well? Is there something that could be done at the driver level to separate the power domains?
Maybe using mpd and disabling the UI when you don't need it will help. Most of the gnome players use gstreamer and trigger constant events in their UI.
Maybe megous has a better idea, but I believe bt requires keeping the wifi radio powered as well? Is there something that could be done at the driver level to separate the power domains?
Maybe using mpd and disabling the UI when you don't need it will help. Most of the gnome players use gstreamer and trigger constant events in their UI.
For what is worth, I am using MPD instead of any of the GUI-based music apps. It doesn’t matter: the battery quickly drains anyway, and the audio even stutters. How is it possible for this phone to have worse performance at playing music than my iPod Video from almost 15 years ago?
Note that Maemo is a decade-old codebase that has bitrotted, so running it on the PinePhone isn't a reasonable solution.
Note that Maemo is a decade-old codebase that has bitrotted, so running it on the PinePhone isn't a reasonable solution.
I wonder why the video makes it seem otherwise... Did he just cut every time he performed a UI action? :P
Your experience sounds more like what I would have expected at this stage - we'll get there though!
Your experience sounds more like what I would have expected at this stage - we'll get there though!
Creator of the video here - I don't do cuts like that.
Fedora felt quite good in terms of performance which in part may be due to the very new kernel and their use of F2FS.
Now if they can get that app scaling dialed in a bit more, then I can see myself using Fedora (I currently use mobile.danctnix.org, BTW).
Now if they can get that app scaling dialed in a bit more, then I can see myself using Fedora (I currently use mobile.danctnix.org, BTW).
I have found that the UI is sluggish when one first boots up the Pinephone, and the experience seems to vary greatly between distros. My experience on Mobian is the same as the video (with the exception of start up).
I tried the purism phone and it was fine. Really, it was snappy and responsive and h/w accelerated.
What I did notice is that gnome isn't dialed into phones (so to speak). For example I tried setting the date/time and you have to press +/- on the hour and minute to get to the time you want. The popup for month had a long list of months, but it put jan-mar off the top of the screen.
What I did notice is that gnome isn't dialed into phones (so to speak). For example I tried setting the date/time and you have to press +/- on the hour and minute to get to the time you want. The popup for month had a long list of months, but it put jan-mar off the top of the screen.
Funny how perspectives can differ. I was just coming to comment how the UI was clearly not as polished as the competition. It's just the obvious stuff:
Typing in a passcode: dots are too small, not spaced out enough
Keyboard: it feels like the characters are about to run into the borders
Camera: lots of just empty black space around the picture--I'd rather they just overscan it a bit to fill up the entire screen.
Lack of a splash screen, icons in the app drawer are a bit too large, many of the prompts obviously expecting a mouse input, screens where responsiveness to the screen form factor is just broken.
I am overall impressed with how far Linux on a phone has come--it's also still a long way to the top.
Typing in a passcode: dots are too small, not spaced out enough
Keyboard: it feels like the characters are about to run into the borders
Camera: lots of just empty black space around the picture--I'd rather they just overscan it a bit to fill up the entire screen.
Lack of a splash screen, icons in the app drawer are a bit too large, many of the prompts obviously expecting a mouse input, screens where responsiveness to the screen form factor is just broken.
I am overall impressed with how far Linux on a phone has come--it's also still a long way to the top.
The most jarring thing is probably the lack of touch feedback when you tap on screen. There's no confirmation that phone actually registered the tap.
Interesting, I hadn't noticed this because haptic feedback using the vibrator is the first thing I disable on any phone (because of the noise).
I didn't mean haptic, but visual feedback.
On most OSes when you press your mouse or finger on an interactive element, that element highlights in some manner (e.g. text color changes, ripple appears, background color changes).
That's critical for proper feedback and feel of a UI. It's almost entirely missing in that demo video.
On most OSes when you press your mouse or finger on an interactive element, that element highlights in some manner (e.g. text color changes, ripple appears, background color changes).
That's critical for proper feedback and feel of a UI. It's almost entirely missing in that demo video.
Oh, ok. I'm quite sensitive to having feedback and that does not seem to be an issue on the PinePhone. Except for when you open an app on Phosh. Then, no clue that the app is loading.
I do it because I find it annoying and distracting. It feels like I did something wrong. I'm already staring at the screen so visual feedback is all I need.
Why will someone use it? It looks like first android phones. I mean usability and security.
I use a PinePhone as a daily driver.
- its camera is not good
- its battery life is not good
- its call quality is not good
- SMSes are not completely reliable
- receiving MMSes works, but you need to use a custom command line tool that you might have written yourself for that
- sending MMSes, I have not even tried. Probably possible, but impractical
- it's barely usable for GPS navigation
- it's a bit slow
- Web browsing is a bit clunky but is largely usable
- its overall usability is not very good
It's a prototype.
But it is a bet for the future. A future in which there are usable phones running OSes whose roadmap do not depend on corporations that close everything in a walled garden or who depend on massively tracking people. A future in which every single line of code running on the phone can be studied, improved and shared. A future in which updates are not at the mercy of the manufacturer.
Actually, you can already have one foot in this future thanks to this phone, and many things are being fixed at a remarkable pace. I hope we will see higher-end hardware for the OSes running on the PinePhone soon.
- its camera is not good
- its battery life is not good
- its call quality is not good
- SMSes are not completely reliable
- receiving MMSes works, but you need to use a custom command line tool that you might have written yourself for that
- sending MMSes, I have not even tried. Probably possible, but impractical
- it's barely usable for GPS navigation
- it's a bit slow
- Web browsing is a bit clunky but is largely usable
- its overall usability is not very good
It's a prototype.
But it is a bet for the future. A future in which there are usable phones running OSes whose roadmap do not depend on corporations that close everything in a walled garden or who depend on massively tracking people. A future in which every single line of code running on the phone can be studied, improved and shared. A future in which updates are not at the mercy of the manufacturer.
Actually, you can already have one foot in this future thanks to this phone, and many things are being fixed at a remarkable pace. I hope we will see higher-end hardware for the OSes running on the PinePhone soon.
I never really got this... Surely just forking Android and replacing all the closed source Google apps with open source alternatives would be easier? Why build an entirely new operating system, when Android already uses the Linux kernel and is open source. A free software fork of Android could accomplish all the of the same goals as PinePhone while providing all the benefits of the existing support and ecosystem.
edit: apparently this already exists: https://replicant.us
edit: apparently this already exists: https://replicant.us
A few reasons:
After a few years (3 if you are lucky), your phone will stop getting updates. I have a Nexus 5 with the last "official" update over 4 years ago. I have a Nexus 5x that stopped getting updates 2 years ago.
https://support.google.com/pixelphone/answer/4457705
To compare, I have a laptop from 2008 (A Thinkpad x200) that runs mainline Debian no problems, and bit the thing will die before it stops getting mainline support. I want a phone where I can like that too.
In all but a select, very few devices, Android is not fully open source, nor will it ever be.
On a Pixel 3a, if you follow the offical compiling guide, there is a HUGE (~400 MB) vendor.img file you are forced to install, and you have to integrate several other proprietary libraries to get the Pixel 3a to even boot.
On top of that, pure AOSP cripples the phone (and by that mean SMS breaks with LTE, you lose voLTE, Wi-Fi calling, etc.) A lot of Android ROMS have to scrape official images to get the binary bits (and it is nor a fun needle in a haystack excerise) to get basically phone functionality in Android.
Running Android without Play Services cripples your phone in a number of ways.
After a few years (3 if you are lucky), your phone will stop getting updates. I have a Nexus 5 with the last "official" update over 4 years ago. I have a Nexus 5x that stopped getting updates 2 years ago.
https://support.google.com/pixelphone/answer/4457705
To compare, I have a laptop from 2008 (A Thinkpad x200) that runs mainline Debian no problems, and bit the thing will die before it stops getting mainline support. I want a phone where I can like that too.
In all but a select, very few devices, Android is not fully open source, nor will it ever be.
On a Pixel 3a, if you follow the offical compiling guide, there is a HUGE (~400 MB) vendor.img file you are forced to install, and you have to integrate several other proprietary libraries to get the Pixel 3a to even boot.
On top of that, pure AOSP cripples the phone (and by that mean SMS breaks with LTE, you lose voLTE, Wi-Fi calling, etc.) A lot of Android ROMS have to scrape official images to get the binary bits (and it is nor a fun needle in a haystack excerise) to get basically phone functionality in Android.
Running Android without Play Services cripples your phone in a number of ways.
And anyway, Android, even the free software part, will always do what Google wants to do. One may fork Android, but maintaining an ever diverging fork would have an ever growing cost.
And there are aspects of newer Android versions that are less than ideal. For instance, one can see how Termux is struggling to keep working: it is not possible to run binaries that are not part of an Android package (APK) anymore. This is a security feature, but it's not always relevant depending on how you use and manage your OS.
Plus, developing for Android is a pain. You need to download, setup and use a bloated SDK with a non-free license. There's Android Rebuilds [1], but it's not complete.
I trust GNU/Linux distros like Debian, Fedora, openSUSE, Arch, Manjaro to evolve in a direction I like. postmarketOS probably too, but I'm not familiar with it as well.
[1] https://android-rebuilds.beuc.net/
And there are aspects of newer Android versions that are less than ideal. For instance, one can see how Termux is struggling to keep working: it is not possible to run binaries that are not part of an Android package (APK) anymore. This is a security feature, but it's not always relevant depending on how you use and manage your OS.
Plus, developing for Android is a pain. You need to download, setup and use a bloated SDK with a non-free license. There's Android Rebuilds [1], but it's not complete.
I trust GNU/Linux distros like Debian, Fedora, openSUSE, Arch, Manjaro to evolve in a direction I like. postmarketOS probably too, but I'm not familiar with it as well.
[1] https://android-rebuilds.beuc.net/
Hasn't the ios equivalent moved to emulation at this point?
Kernel support is there waiting to compiled for user namespace isolated containers. It would just require an official way to launch them as a normal user.
Kernel support is there waiting to compiled for user namespace isolated containers. It would just require an official way to launch them as a normal user.
All good points too.
Developing for the Pinephone has been nice! I have been using Mobian for it over SSH, and I am pretty happy with how well it has been going.
Developing for the Pinephone has been nice! I have been using Mobian for it over SSH, and I am pretty happy with how well it has been going.
The same reason Firefox and Safari don't use Google V8 & Blink. They (mostly Safari) are the only opposition to Google monopolistic control on the web.
You will always be under control of others if you don't take your independence and open-source means little when it is in practice controlled by only one entity.
If you build an OS on top of Android like /e/, replicant & Lineage & etc. , you are doomed to be living in Google' shadow . They'll shut you down anytime you do something they don't like. And even if it is open-source, if you disagree, you'll never have the financial means to maintain an up to date Android fork. Once/if they abandon Android for Fushia, it's going to be hard maintaining all abandoned Android legacy code alone.
Then, there are also technical reasons. We could ask "why create a new UI lib from scratch when we have QT ?". Yes for the end-user it's mostly the same (a bunch of text and buttons), yet people are developing custom UI lib (eg. Blender/Godot), Flutter, React, Svelte, Druid, Moxie, Makepad, etc. This is needed for innovation and/or to fit your own needs.
Real Linux has lots of potential : it can run Blender, Krita, Godot, VsCode, Steam games, any language, FreeCad, KiCad, Matlab, etc. (None of them have mobile UIs, but still are an asset for tablets & convergence). It is not governed by Google or Apple and it has already quite some drivers for several devices (I could just install Bitwig on a Linux tablet, plug a MIDI keyboard and make music).
So there are definitely reasons to take this path and personally I find this far more exciting than Lineage (although I use Lineage daily & I'm super grateful to that it exists)
You will always be under control of others if you don't take your independence and open-source means little when it is in practice controlled by only one entity.
If you build an OS on top of Android like /e/, replicant & Lineage & etc. , you are doomed to be living in Google' shadow . They'll shut you down anytime you do something they don't like. And even if it is open-source, if you disagree, you'll never have the financial means to maintain an up to date Android fork. Once/if they abandon Android for Fushia, it's going to be hard maintaining all abandoned Android legacy code alone.
Then, there are also technical reasons. We could ask "why create a new UI lib from scratch when we have QT ?". Yes for the end-user it's mostly the same (a bunch of text and buttons), yet people are developing custom UI lib (eg. Blender/Godot), Flutter, React, Svelte, Druid, Moxie, Makepad, etc. This is needed for innovation and/or to fit your own needs.
Real Linux has lots of potential : it can run Blender, Krita, Godot, VsCode, Steam games, any language, FreeCad, KiCad, Matlab, etc. (None of them have mobile UIs, but still are an asset for tablets & convergence). It is not governed by Google or Apple and it has already quite some drivers for several devices (I could just install Bitwig on a Linux tablet, plug a MIDI keyboard and make music).
So there are definitely reasons to take this path and personally I find this far more exciting than Lineage (although I use Lineage daily & I'm super grateful to that it exists)
Why would you run Android on an old underpowered SoC if you can buy a new Android phone with much better specs for the same price or cheaper locally, with much easier to attain warranty and better delivery times?
Pinephone is only interesting because it is getting a progressively better mainline Linux support every day, can run normal Linux distros, has fairly open hardware and a manufacturer that accepts feedback, and works on interesting stuff, like a kinda unique planned external keyboard+battery shell for it.
It's a real pocket computer with HW that I can control without restrictions, SW that I can trust, and don't have to run everything in a sandbox, just like on my workstation.
Pinephone is only interesting because it is getting a progressively better mainline Linux support every day, can run normal Linux distros, has fairly open hardware and a manufacturer that accepts feedback, and works on interesting stuff, like a kinda unique planned external keyboard+battery shell for it.
It's a real pocket computer with HW that I can control without restrictions, SW that I can trust, and don't have to run everything in a sandbox, just like on my workstation.
> Why would you run Android on an old underpowered SoC if you can buy a new Android phone with much better specs for the same price or cheaper locally, with much easier to attain warranty and better delivery times?
The absence of proprietary blobs running on the main CPU alone is already a great deal. This also means that the phone isn't stuck on an old version of Android because of some nasty blob.
The absence of proprietary blobs running on the main CPU alone is already a great deal. This also means that the phone isn't stuck on an old version of Android because of some nasty blob.
> The absence of proprietary blobs running on the main CPU alone is already a great deal.
This. The formulated goal is short, self-contained, not overreaching, and to the point.
This. The formulated goal is short, self-contained, not overreaching, and to the point.
...and completely uninteresting - at least for me. Having used GNU/Linux smartphones as my main phones exclusively since 2008 I'm really not interested in any kind of Android device.
Don't newer Android versions have specific GPU requirements? I doubt latest Android will work smoothly on Mali 400.
Best pro argument I ever read about it. Will try to re-use it when people complain that I'm paying more for a hardware that does less.
> I hope we will see higher-end hardware for the OSes running on the Pinephone soon.
According to discussions on the Pine64 boards, it will probably take 4-5 years before we see an upgrade to the underpowered and obsolete A64 chip inside the PinePhone, and when that happens, even that new chip may already seem antiquated.
According to discussions on the Pine64 boards, it will probably take 4-5 years before we see an upgrade to the underpowered and obsolete A64 chip inside the PinePhone, and when that happens, even that new chip may already seem antiquated.
Yeah, this sucks a bit. Those phones need hardware that does not depend on proprietary blobs to work, and such hardware is not very common. Even the hardware in the PinePhone is not perfect in this regard: the modem runs a closed firmware (though people are getting mainline Linux to run on the modem so there's hope!), and the Wi-Fi/Bluetooth chip too (like in most regular laptops anyway…)
In the meantime though, I would be happy with an outdated SoC but a decent camera and good call quality for people you call. 5 GHz Wi-Fi would be wonderful. 3G of RAM is already comfortable. A better screen would be fantastic but the one on the PinePhone is more than usable.
Better battery life would be nice too, but it is coming to the PinePhone with a custom case that will also provide a keyboard, and you can always carry a power tank or a spare battery since the one in the PinePhone is removable!
In the meantime though, I would be happy with an outdated SoC but a decent camera and good call quality for people you call. 5 GHz Wi-Fi would be wonderful. 3G of RAM is already comfortable. A better screen would be fantastic but the one on the PinePhone is more than usable.
Better battery life would be nice too, but it is coming to the PinePhone with a custom case that will also provide a keyboard, and you can always carry a power tank or a spare battery since the one in the PinePhone is removable!
I don't agree that 3G of RAM is comfortable. The problem with phones these days is that many people don't really use them for calling over the public telephone network, instead they are running chat apps like Signal. Launching Signal's desktop app (which is Electron-based) or trying to emulate Signal's Android app through Anbox already places big demands on RAM, and a person can reasonably expect from a phone that they can also use their browser and their map app at the same time.
The same is also true of map apps. There just isn't enough developer manpower to make vanilla-Linux mapping apps as featureful as OSMAnd or Maps.me's open-source fork, and therefore the best thing to do would be to emulate them using Anbox, but the Pinephone's hardware is just too underpowered to comfortably do this.
The same is also true of map apps. There just isn't enough developer manpower to make vanilla-Linux mapping apps as featureful as OSMAnd or Maps.me's open-source fork, and therefore the best thing to do would be to emulate them using Anbox, but the Pinephone's hardware is just too underpowered to comfortably do this.
> The same is also true of map apps
Either you haven't heard of or used Gnome Maps (which is wonderful, highly recommend), or it doesn't fit your criteria. Assuming the latter, what do you consider missing?
Either you haven't heard of or used Gnome Maps (which is wonderful, highly recommend), or it doesn't fit your criteria. Assuming the latter, what do you consider missing?
Gnome Maps is not even remotely competitive for offline use. It requires internet lookups for everything. Because OSMAnd maintains its own OSM database on your device, looking up opening hours for businesses can be done with no internet access.
OSMAnd is able to show all kinds of details about roads (such as the road surface – important for cyclists interested in asphalt/unpaved riding).
Gnome Maps also uses GraphHopper for routing. OSMAnd, on the other hand, allows you to extend its routing with plugins, so long-distance cyclists can install the Brouter routing engine that is superior for this kind of travel.
OSMAnd is able to show all kinds of details about roads (such as the road surface – important for cyclists interested in asphalt/unpaved riding).
Gnome Maps also uses GraphHopper for routing. OSMAnd, on the other hand, allows you to extend its routing with plugins, so long-distance cyclists can install the Brouter routing engine that is superior for this kind of travel.
I agree with electron apps and Anbox being slow to the point of being unusable.
Anbox being slow is not a big surprise though: it literally runs a complete Android system on top of your OS.
We need native, lightweight apps for the phone and that requires a big amount of work for sure.
There's an Android port for the PinePhone that I want to try one of these days. Back to an OS whose roadmap depends on Google, but at least without the proprietary blobs. But I don't plan to settle on it. As someone said elsewhere in this thread, it's less and less hackable, and I hope that GNU/Linux-based OSes work out.
Anbox being slow is not a big surprise though: it literally runs a complete Android system on top of your OS.
We need native, lightweight apps for the phone and that requires a big amount of work for sure.
There's an Android port for the PinePhone that I want to try one of these days. Back to an OS whose roadmap depends on Google, but at least without the proprietary blobs. But I don't plan to settle on it. As someone said elsewhere in this thread, it's less and less hackable, and I hope that GNU/Linux-based OSes work out.
Sounds like you are searching for https://puri.sm/products/librem-5 (see the comparison in my other comment here)
Mine is out for delivery today - I share your sentiments.
I don't expect it to be a great phone. I do think it's fairly incredibly that it exists at all, and I want to support both the manufacturers putting it out, as well as pick up some slack and add some of my spare time as development hours towards making the experience better.
This is one of the very, very few mobile devices on the market right now that places the user in the driver's seat, instead of treating them merely like a wallet to suck money from in any way possible.
I don't expect it to be a great phone. I do think it's fairly incredibly that it exists at all, and I want to support both the manufacturers putting it out, as well as pick up some slack and add some of my spare time as development hours towards making the experience better.
This is one of the very, very few mobile devices on the market right now that places the user in the driver's seat, instead of treating them merely like a wallet to suck money from in any way possible.
There are a few things that are already better than on an Android or iOS phone that you could appreciate as a developer / advanced user:
- No heavy SDK. Just use whatever you want to build software for it, it's not complicated.
- on $distro, you access any package provided by $distro. And when $distro is Mobian, you have everything Debian has.
- You can script anything with a regular shell script.
- There's Avahi, so you can discover things on your network and your computers can access services running on the phone.
- You can display the SMS app on your computer screen through ssh -Y, and this is amazing.
- Since the sound is managed by PulseAudio, you can use its networking features. Play sound from your phone on your computer or vice versa.
The dock is pretty cool too, and allows running things like on a regular computer, though the phone is a bit slow.
- No heavy SDK. Just use whatever you want to build software for it, it's not complicated.
- on $distro, you access any package provided by $distro. And when $distro is Mobian, you have everything Debian has.
- You can script anything with a regular shell script.
- There's Avahi, so you can discover things on your network and your computers can access services running on the phone.
- You can display the SMS app on your computer screen through ssh -Y, and this is amazing.
- Since the sound is managed by PulseAudio, you can use its networking features. Play sound from your phone on your computer or vice versa.
The dock is pretty cool too, and allows running things like on a regular computer, though the phone is a bit slow.
It's a handy portable linux device. A phone that lets you treat it like a real computer, not a locked down consumer device.
Usability: being able to do apt-get and write Python scripts on my phone makes it a portable automation and computing tool rather than a phone.
Security: Android is choke-full of spyware.
Security: Android is choke-full of spyware.
And yet people used the first android phones.
Tables stakes is now a lot higher than what was offered by the first Android phones. Unfortunately the barrier to entry into the mobile phone market has risen considerably since then.
Yeah yeah that's fair. But every time a new product comes along that isn't _yet_ as good as Android or iPhone HN commentators reflexively dismiss it.
I get that that when its some new proprietary product trying to enter the market, but when its something grass roots and community driven line the pinephone with classic linux distribution on it... I dunno, I guess I just expect HN to have more intellectual curiosity in technical projects, rather than surface level critique of packaged goods. That's the sort of thing I spend time on this site for, but those sorts of discussions are far and few between. Maybe its just time to move on, I can't relate to 90% of HN comments anymore.
I get that that when its some new proprietary product trying to enter the market, but when its something grass roots and community driven line the pinephone with classic linux distribution on it... I dunno, I guess I just expect HN to have more intellectual curiosity in technical projects, rather than surface level critique of packaged goods. That's the sort of thing I spend time on this site for, but those sorts of discussions are far and few between. Maybe its just time to move on, I can't relate to 90% of HN comments anymore.
"Back when they were the pinnacle of technology", he thought but didn't say.
The computer in my pocket doesn't needs to be the "pinnacle of technology". It just needs to be "good enough". But, until we arrive there, some people will have to be willing to accept options which are still not "good enough" or else we'll never arrive there.
It is sad that pioneers and early adopters often suffer more and are anonymous heroes that enable advanced user-respecting technology for the rest of the people.
Think of this like the people who used KHTML based browsers. Their compromise allowed us to have the quick browsers we enjoy today but they had to endure broken websites for years.
It is sad that pioneers and early adopters often suffer more and are anonymous heroes that enable advanced user-respecting technology for the rest of the people.
Think of this like the people who used KHTML based browsers. Their compromise allowed us to have the quick browsers we enjoy today but they had to endure broken websites for years.
Aside from the standard reason of ideals regarding FOSS and freedom-respecting hardware/software, Android is getting less and less hacker friendly in many ways. I won't likely switch as a daily driver for some time as my phone is critical to my business, but I'll support these efforts and plan to switch eventually. Until then I'll probably have two phones :-D
I've just got my KDE CE PinePhone.
I love it because of what it represents, but as a phone it's not there yet.
The more "eyes" on this device, the better.
I have seen phones want to succeed and fail so many times.
It isn't the distro that matters, it's the software running on that distro which can then be a universal package for all Linux devices.
It's OK making ofono or Wayland run great on device A, but don't forget that wpa_supplicant and X11 run on every Thinkpad and Raspberry Pi we install on.
The work we do today benefits the ecosystem, not just the community.
Sorry for just saying thank you to everyone. I guess I should have had a point?
I love it because of what it represents, but as a phone it's not there yet.
The more "eyes" on this device, the better.
I have seen phones want to succeed and fail so many times.
It isn't the distro that matters, it's the software running on that distro which can then be a universal package for all Linux devices.
It's OK making ofono or Wayland run great on device A, but don't forget that wpa_supplicant and X11 run on every Thinkpad and Raspberry Pi we install on.
The work we do today benefits the ecosystem, not just the community.
Sorry for just saying thank you to everyone. I guess I should have had a point?
Can these Linux phones prevent the mobile phone company ( i.e. Verizon, AT&T or the owner of the tower) from tracking you and selling ( or "renting" )
your location information?
Location from cell towers is not as accurate as GPS. I wonder for what purpose they sell the data. They need to track you, that's a technical requirement of a mobile network. (Ie someone calls you, the network needs to know where your mobile device is to forward the call)
Yes, if you use the kill switches (but then you will not have mobile connection).
No. Cell sites will always know your location. Additionally, in the U.S. all cellphone are required to support E911 which requires GPS location. Any phone out of compliance can have its IMEI blocked on that network.
The benefit of open source phones in this regard could potentially be additional control over which apps can access GPS or additional visibility into which apps are requesting it. This already exists on closed source phones, but the devs could make permissions more obvious and potentially give more privacy tips if they so desired. Maybe even do something cool like have a red icon on your home screen that warns you may be giving apps too many permissions or if permissions changed without your interaction.
The benefit of open source phones in this regard could potentially be additional control over which apps can access GPS or additional visibility into which apps are requesting it. This already exists on closed source phones, but the devs could make permissions more obvious and potentially give more privacy tips if they so desired. Maybe even do something cool like have a red icon on your home screen that warns you may be giving apps too many permissions or if permissions changed without your interaction.
Cell sites have coarse location information only.
E911 does not mean your phone is using GPS all the time, only while calling emergency services.
E911 does not mean your phone is using GPS all the time, only while calling emergency services.
Agreed, I just meant that the phones baseband is required to be connected to a GPS receiver. With an open hardware / open source phone, you might have more visibility into what is going on.
I think it has nothing to do with privacy. Pipewire is like the 'new soundserver" for linux distros. Just that.
Wouldn't it be possible for Pine64, Purism and Fairphone agree on a common chassis to reduce costs of their phones?
Why can't it be like PC's where the user can buy a bunch of separate parts from different manufacturers and build his/her own computer?
Why can't it be like PC's where the user can buy a bunch of separate parts from different manufacturers and build his/her own computer?
Because this era of "separate parts" comes to an end. Now everything is single SoC that are only compatible with big tech proprietary OS.
Google has on purpose made Android different enough so that no Android SoC could run mainline Linux.
Today, no decent SoC can run real Linux, the "best" SoC that can run mainline Linux are :
- Rockship (PinePhone) which is reversed engineered so only old SoC have support and it require massive effort from the community.
- NXP (Librem 5) which are thick power hungry slow SoC (because they are made for automobile I guess)
- Broadcom (Raspberry Pi) which is still super slow compared to most modern smartphone.
In any case the manufacturers of decent SoC don't give a crap about Linux, they only support Android and any Linux support must be done by someone else, often through reverse engineering.
This is a totally anticompetitive situation which is far from what we had on the desktop side.
But even on the laptop/desktop side, this is also coming to an end : Microsoft custom chip & Surfaces, Apple M1, etc. Soon this will be the same as on mobile.
FairPhone makes no special effort about the choice SoC, they just use a SoC which supports Android and which obviously doesn't support Linux.
On the other hand Librem & PinePhone use the only SoC that have Linux support, and they often must develop support themselves through reverse eng. because the manufacturer doesn't care.
Unless we pass laws about it or unless Pine64/Purism become very successful, it is the end of any hope for alternative as no mobile device is able to run anything else than IOS & Android (or HarmonyOS, Fushia or whatever next privacy hell OS is coming from those big tech)
Even in Planes & Cars , the entertainment systems are now powered by Android and not Linux.
Mainline Linux will disappear until it only exist in a emulated VM running on a M1 mac, or on a headless datacenter server.
Purism & Pine64 are currently our only hope for alternative and I encourage anyone to support them. They represent the ugly reality of what is available to the competition, it is slow, thick, power hungry and old but that's all we have.
Google has on purpose made Android different enough so that no Android SoC could run mainline Linux.
Today, no decent SoC can run real Linux, the "best" SoC that can run mainline Linux are :
- Rockship (PinePhone) which is reversed engineered so only old SoC have support and it require massive effort from the community.
- NXP (Librem 5) which are thick power hungry slow SoC (because they are made for automobile I guess)
- Broadcom (Raspberry Pi) which is still super slow compared to most modern smartphone.
In any case the manufacturers of decent SoC don't give a crap about Linux, they only support Android and any Linux support must be done by someone else, often through reverse engineering.
This is a totally anticompetitive situation which is far from what we had on the desktop side.
But even on the laptop/desktop side, this is also coming to an end : Microsoft custom chip & Surfaces, Apple M1, etc. Soon this will be the same as on mobile.
FairPhone makes no special effort about the choice SoC, they just use a SoC which supports Android and which obviously doesn't support Linux.
On the other hand Librem & PinePhone use the only SoC that have Linux support, and they often must develop support themselves through reverse eng. because the manufacturer doesn't care.
Unless we pass laws about it or unless Pine64/Purism become very successful, it is the end of any hope for alternative as no mobile device is able to run anything else than IOS & Android (or HarmonyOS, Fushia or whatever next privacy hell OS is coming from those big tech)
Even in Planes & Cars , the entertainment systems are now powered by Android and not Linux.
Mainline Linux will disappear until it only exist in a emulated VM running on a M1 mac, or on a headless datacenter server.
Purism & Pine64 are currently our only hope for alternative and I encourage anyone to support them. They represent the ugly reality of what is available to the competition, it is slow, thick, power hungry and old but that's all we have.
> Rockship (PinePhone) which is reversed engineered so only old SoC have support and it require massive effort from the community.
PinePhone has Allwinner A64. [0]
And Rockchip SoCs have a quite decent track record of not only supporting mainline linux but even running without proprietary firmware - as does their current top level SoC (RK3399, featured in Pine64's ROCKPro64).
[0] https://wiki.pine64.org/wiki/PinePhone#Specifications
PinePhone has Allwinner A64. [0]
And Rockchip SoCs have a quite decent track record of not only supporting mainline linux but even running without proprietary firmware - as does their current top level SoC (RK3399, featured in Pine64's ROCKPro64).
[0] https://wiki.pine64.org/wiki/PinePhone#Specifications
But the point is your looking at a SoC with A53's, which is a 9 year old in-order design. Or for that matter, the rk3399's A72's which is a 5 year old design. That puts them at somewhere between an 6x->4x (geekbench) slower per core vs a modern smartphone depending on which benchmark you compare.
Then you add in the overhead of not being a mobile optimized OS, and your also burning massively more power.
The market share for these phones will remain geeks who want to have a more "open" phone and are willing to deal with a slow, buggy, inefficient device.
Frankly, this won't change until Qualcomm/etc decide to make their SoC's more open, so that smaller companies can build products like these without signing piles of NDAs and shipping android BSP kernels. But then again, that might cut into their business because they won't be able to deprecate 2 year old phones by simply refusing to provide security updates.
Most geeks would be better off picking up a year or two old phone and running lineageOs. At least the devices tend to work, even if they have a dozen or so proprietary blobs.
Then you add in the overhead of not being a mobile optimized OS, and your also burning massively more power.
The market share for these phones will remain geeks who want to have a more "open" phone and are willing to deal with a slow, buggy, inefficient device.
Frankly, this won't change until Qualcomm/etc decide to make their SoC's more open, so that smaller companies can build products like these without signing piles of NDAs and shipping android BSP kernels. But then again, that might cut into their business because they won't be able to deprecate 2 year old phones by simply refusing to provide security updates.
Most geeks would be better off picking up a year or two old phone and running lineageOs. At least the devices tend to work, even if they have a dozen or so proprietary blobs.
Yes, unfortunately you're right in that there's lots of room for improvement. Nevertheless I'd call the rk3399 a decent SoC, but then for me the fact that it runs without proprietary firmware is certainly more important than pure performance. What I'd really like to have though, is more RAM - I run my desktop on the rk3399. And I already use the PinePhone as a daily driver although I see that it's not there for most of the people.
But maybe this could not only change at the big vendors' whim, but also if more people express their wish for systems that are less locked in by changing their priorities.
But maybe this could not only change at the big vendors' whim, but also if more people express their wish for systems that are less locked in by changing their priorities.
Rockchip certainly does not have access to the smaller processes or newer designs like Qualcomm and Samsung do.
But at least their new SoCs will have A55 and A76s! It's progress, no matter how slow.
Maybe we will see an rk3566 tablet out and about one day.
But at least their new SoCs will have A55 and A76s! It's progress, no matter how slow.
Maybe we will see an rk3566 tablet out and about one day.
> And Rockchip SoCs have a quite decent track record of not only supporting mainline linux but even running without proprietary firmware - as does their current top level SoC (RK3399, featured in Pine64's ROCKPro64).
Last time I tried, RK3399 was dog slow to boot on Pinebook Pro (only thanks to https://gitlab.com/DeltaGem/levinboot is this changing) and development once Google stopped doing it seems almost entirely stagnant. Just look at ATF history, or U-Boot history, etc.
Pinebook Pro doesn't suspend to ram to this day. Only whatever Google implemented for their chromebooks works.
Last time I tried, RK3399 was dog slow to boot on Pinebook Pro (only thanks to https://gitlab.com/DeltaGem/levinboot is this changing) and development once Google stopped doing it seems almost entirely stagnant. Just look at ATF history, or U-Boot history, etc.
Pinebook Pro doesn't suspend to ram to this day. Only whatever Google implemented for their chromebooks works.
My PBP with mostly stock uboot and kernel boots in ~15 seconds.
Not great (especially without s2ram) but not 'dog slow' in my opinion.
No altmode typec in mainline is a big issue for me. Very sad that there is no usable video output.
Not great (especially without s2ram) but not 'dog slow' in my opinion.
No altmode typec in mainline is a big issue for me. Very sad that there is no usable video output.
U-Boot has no business taking > 1-2s to boot PBP. More than that is kinda ridiculous. I was shocked seeing it take 8s when I first booted Manjaro. (My allwinner boards boot in ~2s, and those are all way slower than RK3399) With some older levinboot version, PBP boots to initramfs FDE password prompt in ~4s [1]. It's probably even faster now. I wish it would take 2s to that prompt, because then I can open PBP, enter password right away, and then just do something else waiting for the desktop to load. But 3-4s is already pretty nice.
[1] https://xnux.eu/log/#015
At least suspend to idle works as a sort of replacement for suspend to ram. PBP can stay for long enough in that state, so it's usable on the go even without suspend to RAM.
[1] https://xnux.eu/log/#015
At least suspend to idle works as a sort of replacement for suspend to ram. PBP can stay for long enough in that state, so it's usable on the go even without suspend to RAM.
Haven't heard of levinboot yet, LGTM, thanks for the hint!
Where do you get your entropy from? Does levinboot provide some (enough?) to the kernel? Right now I delay booting via a sleep in the initramfs so that I have time to randomly press as many keys as possible to get crng initialized before cryptsetup is called. Configuring my U-Boot build to provide entropy to the kernel is still on my to do list, haven't looked into it yet and don't know whether it already does or not. At least last time I checked I observed that KASLR didn't work due to missing entropy (the artificial delay won't work here as KASLR happens way before calling init).
It's in the feature list: https://gitlab.com/DeltaGem/levinboot
> providing entropy to the kernel (KASLR and RNG seeds) via the DTB
I might as well add this feature to p-boot too. :)
> providing entropy to the kernel (KASLR and RNG seeds) via the DTB
I might as well add this feature to p-boot too. :)
> Purism & Pine64 are currently our only hope for alternative and I encourage anyone to support them.
Detailed comparison: https://forums.puri.sm/t/comparing-specs-of-upcoming-linux-p...
Detailed comparison: https://forums.puri.sm/t/comparing-specs-of-upcoming-linux-p...
> Google has on purpose made Android different enough so that no Android SoC could run mainline Linux.
daily reminder that this is only possible because the very people in this site, "did not care about GPL or tainted kernel" as long as they had their nvidia GTX working to play quake.
ha!
daily reminder that this is only possible because the very people in this site, "did not care about GPL or tainted kernel" as long as they had their nvidia GTX working to play quake.
ha!
We must have different definitions of “real Linux” if you think this. For example NXP makes arm chips [1] and I have put a bitbake OS on there that I absolutely considered “real Linux,” 4.18 kernel, coreutils etc.
Why would they agree on a common chassis when they have already been focusing on different market segments? Purism's offering is rather higher-end, so the feel of its products will be superior to PinePhone, which is aiming at pretty rock-bottom prices.
Purism and Mobian-Pine64 are already collaborating on software development, so the projects aren't intentionally ignoring one another.
Purism and Mobian-Pine64 are already collaborating on software development, so the projects aren't intentionally ignoring one another.
> Why would they agree on a common chassis when they have already been focusing on different market segments?
Because a common chassis could be good for such targeted market and it could reduce prices.
Because a common chassis could be good for such targeted market and it could reduce prices.
You're not the first one to think of this. See: Phonebloks [1]. It failed mostly because there wasn't enough demand, but I wonder if they could make a comeback.
[1]: https://en.m.wikipedia.org/wiki/Phonebloks
[1]: https://en.m.wikipedia.org/wiki/Phonebloks
The librem 5 is somewhat modular. IIRC, you can disconnect and replace the modem and wifi card. So, I think a common chassis could have a screen, IMU, PMIC, battery, cameras, speakers, mics, leds, buttons, headphone jack, usb port and sensors (barometer, thermometers, light sensor, proximity...).
The mainboard could connect to the chassis using some standardized common connectors for the devices provided by the chassis. Other devices could be connected to the mainboard: modem, wifi card, bluetooth and sd-card.
That is not a giant leap from what librem 5 is.
The mainboard could connect to the chassis using some standardized common connectors for the devices provided by the chassis. Other devices could be connected to the mainboard: modem, wifi card, bluetooth and sd-card.
That is not a giant leap from what librem 5 is.
Phonebloks has a questionable design:
Each component had its own shell - making it bulky and very expensive.
Each component had its own shell - making it bulky and very expensive.
And maybe phones could be as large as PCs as well?! While I'm all for repairability, it's just not feasible to build a small device such as a phone when you just put together lego blocks
Once you separate the phone into its parts you can only improve the parts, not the whole phone. I would think that's the problem from the manufacturer's side.
they do use m.2 cards afaik. The chassis might be harder.
That's like trying to standardize on one motherboard / case too early on.
That's like trying to standardize on one motherboard / case too early on.
Oh hey, this is a project I started a while ago. It's a little buggier than the other PinePhone distributions because most of our apps are straight from the "Real" Fedora repository and aren't patched. [1]
General sentiment in the thread is that this is not a replacement for Android or iOS: you are correct.
I can answer questions if people have any.
[1]: https://github.com/nikhiljha/pp-fedora-sdsetup
General sentiment in the thread is that this is not a replacement for Android or iOS: you are correct.
I can answer questions if people have any.
[1]: https://github.com/nikhiljha/pp-fedora-sdsetup
Given proximity to "real" fedora, is this any good with USB-C dock (and external keyboard, mouse, and monitor)?
Stretch question - any apps that work well between both "desktop" i.e. dock and "phone", i.e. dock-less modes?
Stretch question - any apps that work well between both "desktop" i.e. dock and "phone", i.e. dock-less modes?
I can't answer for Fedora, but for Mobian (Mobile Debian). It works reasonably well with a USB-C dock and external keyboard/mouse/monitor.
A lot of apps works well between both of you use phosh. Purism (the software dev behind phosh) developed libraries to enable apps to switch between desktop and phone mode (it's called libhandy).
A lot of apps works well between both of you use phosh. Purism (the software dev behind phosh) developed libraries to enable apps to switch between desktop and phone mode (it's called libhandy).
Yup, others have done the docked thing after installing gnome-shell. Haven’t tested it myself since I have an older PinePhone where this wasn’t functional.
I wouldn’t say any apps work “well” on mobile - but everything that works on mobile is usable on desktop.
I wouldn’t say any apps work “well” on mobile - but everything that works on mobile is usable on desktop.
I have a pine phone.
Have had it a week.
Still excited, thrilled!
But it is not a useable phone in day to day life. I have successfully made one call so far.
I recommend going out and buying one today.
Have had it a week.
Still excited, thrilled!
But it is not a useable phone in day to day life. I have successfully made one call so far.
I recommend going out and buying one today.
Yeah I have one too, using Mobian right now.
I got VS Code ARM to run on it haha it's so slow 3-5 second lag... still. Also going to try running a small VM through QEMU on it.
I got VS Code ARM to run on it haha it's so slow 3-5 second lag... still. Also going to try running a small VM through QEMU on it.
I own a PineTab (based on similar hardware - A64 and 2GB RAM). These devices are very cool, if not a little under-powered [1]. For the price point, there is no competition in this space in terms of what is offered in value and quality. I really hope Pine continue to fight the good fight!
[1] https://coffeespace.org.uk/projects/review-pinetab.html
[1] https://coffeespace.org.uk/projects/review-pinetab.html
How do these go with OS support? Not much in the way of reviews on Youtube but I've seen a few where the driver support leaves a bit to be desired.
Mostly okay, the OSes are really getting there. Most of them are shared with that of the PinePhones.
The driver support is also mostly there. I believe for the PinePhones pretty much the entire hardware is working and usable. They are still not daily drivers, but it gets closer each day.
The driver support is also mostly there. I believe for the PinePhones pretty much the entire hardware is working and usable. They are still not daily drivers, but it gets closer each day.
Is there any way to squeeze a bit more performance from current applications on PinePhone, or do we have to wait for better hardware?
Supposedly a lot of the performance issues are down to GTK3 not really making much use of GPU acceleration and apps getting ported to GTK4 should improve things.
Plasma mobile does seem to run a bit better than GNOME/Phosh: https://www.youtube.com/watch?v=qz_hRfkBnic
Plasma mobile does seem to run a bit better than GNOME/Phosh: https://www.youtube.com/watch?v=qz_hRfkBnic
GTK4 may eventually improve things - while I am happily adding more and more GTK4 apps to https://linmobapps.frama.io, they don't profit from GPU acceleration due to the Mali 400 graphics in the PinePhone only supporting OpenGL(ES) 2.
Well I don't think waiting for better hardware take any less time than improving the software that these phones run. In the video, you can see that these phones are still running desktop versions of these applications, so there is a lot of room for improvement and optimizations for these mobile Linux platforms (things like Firefox running at the right size, better GTK and touchscreen support, etc.).
One of the cool things about these phones is that the battery is removable, so I would imagine these phones will last a while and only get better over time, as their operating systems mature.
One of the cool things about these phones is that the battery is removable, so I would imagine these phones will last a while and only get better over time, as their operating systems mature.
I have also been writing weekly updates (well, link lists) that try to capture what’s happening in this space, you can find the latest one here: https://linmob.net/2021/02/07/linbits31-weekly-linux-phone-n...
The most important thing I do in this space IMO is the app list at https://LINMOBapps.frama.io
I look forward to your questions, ideas, feedback and contributions – the best way to reach me is via email currently (which you can find on my blog)!