Fedora on the PinePhone: Pipewire Calling
odysee.com
odysee.com
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.
Stretch question - any apps that work well between both "desktop" i.e. dock and "phone", i.e. dock-less modes?
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).
I wouldn’t say any apps work “well” on mobile - but everything that works on mobile is usable on desktop.
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?
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.
Each component had its own shell - making it bulky and very expensive.
Purism and Mobian-Pine64 are already collaborating on software development, so the projects aren't intentionally ignoring one another.
Because a common chassis could be good for such targeted market and it could reduce prices.
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.
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).
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.
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 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.
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.
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.
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.
> providing entropy to the kernel (KASLR and RNG seeds) via the DTB
I might as well add this feature to p-boot too. :)
Detailed comparison: https://forums.puri.sm/t/comparing-specs-of-upcoming-linux-p...
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!
That's like trying to standardize on one motherboard / case too early on.
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?
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.
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.
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.
Your experience sounds more like what I would have expected at this stage - we'll get there though!
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).
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.
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.
Note that Maemo is a decade-old codebase that has bitrotted, so running it on the PinePhone isn't a reasonable solution.
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).
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.
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)!
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.
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 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.
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.
- 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.
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.
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!
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.
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.
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?
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 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.
- 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.
edit: apparently this already exists: https://replicant.us
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 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.
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.
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.
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)
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.
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.
This. The formulated goal is short, self-contained, not overreaching, and to the point.
Security: Android is choke-full of spyware.
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.
E911 does not mean your phone is using GPS all the time, only while calling emergency services.
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.
Plasma mobile does seem to run a bit better than GNOME/Phosh: https://www.youtube.com/watch?v=qz_hRfkBnic