Pinephone first steps(scattered-thoughts.net)
scattered-thoughts.net
Pinephone first steps
https://scattered-thoughts.net/writing/pinephone-first-steps/
17 comments
That is extremely cool. One point of hopefully constructive feedback: It's not clear to me how I can use this, or even if I can use it without re-engineering my system (i.e. can this be applied to an existing postmarketOS/ubports/whatever image, or does it have to be integrated into the image build process?). I'm perfectly comfortable using dd to overwrite a boot sector (heck, that's the syslinux install process on x86), but then do I just poke through my boot partition and build a config file that points at my existing kernel+initrd?
I'll add some tutorial file to the repository later on. Eventually yes, you'd also be able to use this the way you described if your boot partition will be a FAT partition.
ATM, p-boot uses its own filesystem format optimized for quick and simple loading of data from storage during boot.
So you'd have to either use some spare partition (for example if you have swap partition on eMMC) or replace the existing boot partition contents with this filesystem. (It must be a MBR style primary partition, not GPT)
Then it's just a question of writing p-boot.bin somewhere (preferably uSD card, so you can go back to your original bootloader easily) And writing a boot partition using the p-boot-conf command as is described in the README, with a single boot config file like (that you'd have to modify this to match your OS):
So in short:
- find a space for p-boot boot filesystem partition
- figure out a config file for your system's boot configuration
- format the boot partition using p-boot-conf tool
- dd the p-boot.bin to the boot location on SD or eMMC (or both)
- (you can do all this with just a spare SD card, while the booted OS is on eMMC, and roll-back by just removing the SD card)
ATM, p-boot uses its own filesystem format optimized for quick and simple loading of data from storage during boot.
So you'd have to either use some spare partition (for example if you have swap partition on eMMC) or replace the existing boot partition contents with this filesystem. (It must be a MBR style primary partition, not GPT)
Then it's just a question of writing p-boot.bin somewhere (preferably uSD card, so you can go back to your original bootloader easily) And writing a boot partition using the p-boot-conf command as is described in the README, with a single boot config file like (that you'd have to modify this to match your OS):
no=0
name=Arch Linux 5.7 (eMMC)
atf=fw.bin
linux=Image
dtb=board.dtb
bootargs=console=ttyS0,115200 console=tty1 root=/dev/mmcblk2p2 rootfstype=f2fs rootflags=fastboot rootwait rw panic=3 cma=256M
initramfs=initramfs.img
So in short:
- find a space for p-boot boot filesystem partition
- figure out a config file for your system's boot configuration
- format the boot partition using p-boot-conf tool
- dd the p-boot.bin to the boot location on SD or eMMC (or both)
- (you can do all this with just a spare SD card, while the booted OS is on eMMC, and roll-back by just removing the SD card)
Wow, that is fast! I was just getting over how messed up the screen protector looks and realised I'd have to restart the video because you'd finished!
^^ Well deserved self-promotion too. Quite a few of the mainline Linux patches for pinephone are written by megi, and iirc they were also one of the first to get calling working.
You can see all of their pinephone related work here: http://xnux.eu/devices/pine64-pinephone.html
You can see all of their pinephone related work here: http://xnux.eu/devices/pine64-pinephone.html
Wow, definitely going to try that out. It takes that long for my android phone just to unlock sometimes.
very nice!
I haven't had a lot of time to invest in working with my PinePhone yet, though I've heard a ton of improvements have been made since the last build I tested.
It's still kinda crazy to me that you can just now finally buy a phone that you can just... install a bunch of different OSes on, and not encumbered out of the box by Android. It's an exciting future for phones again for the first time in nearly a decade.
It's still kinda crazy to me that you can just now finally buy a phone that you can just... install a bunch of different OSes on, and not encumbered out of the box by Android. It's an exciting future for phones again for the first time in nearly a decade.
I've argued that so far we've been in an era with smart phones that resembles early name brand closed PCs like the Commodore 64, Apple II, TI/99, etc.
We may be about to enter an era more reminiscent of the PC clone era, which was more boring from an aesthetic point of view but far more exciting in terms of innovation and opportunity.
New platforms usually start closed and then open over time.
I think a similar transformation is slowly building in the cloud space, but it's very quiet and nowhere near critical mass. I'd keep an eye on cheap bare metal hosts like packet.net and OVH, things that make it really easy to self-host and self-manage K8S clusters, and truly RAIN (redundant array of inexpensive nodes) ready databases like CockroachDB. Pretty soon you'll be able to combine those things and host at roughly 1/10th the cost of AWS or less, with absolutely zero lock-in. At the very least it will kick off a price war in conventional cloud.
Alternately if Starlink brings much faster connectivity to the edge while simultaneously kicking terrestrial broadband in the butt to offer competitive offerings, we could see a move of some hosting back to the edge where 99.9%+ uptime is not really needed. That could include batch processing, model training, analytics, and other stuff that doesn't directly power real-time customer API or UI interactions.
We may be about to enter an era more reminiscent of the PC clone era, which was more boring from an aesthetic point of view but far more exciting in terms of innovation and opportunity.
New platforms usually start closed and then open over time.
I think a similar transformation is slowly building in the cloud space, but it's very quiet and nowhere near critical mass. I'd keep an eye on cheap bare metal hosts like packet.net and OVH, things that make it really easy to self-host and self-manage K8S clusters, and truly RAIN (redundant array of inexpensive nodes) ready databases like CockroachDB. Pretty soon you'll be able to combine those things and host at roughly 1/10th the cost of AWS or less, with absolutely zero lock-in. At the very least it will kick off a price war in conventional cloud.
Alternately if Starlink brings much faster connectivity to the edge while simultaneously kicking terrestrial broadband in the butt to offer competitive offerings, we could see a move of some hosting back to the edge where 99.9%+ uptime is not really needed. That could include batch processing, model training, analytics, and other stuff that doesn't directly power real-time customer API or UI interactions.
I have been waiting forever for phone manufacturers to finally standardize the booting process, hardware detection, and driver support for phone hardware. It's a decade overdue now. I would have thought the nightmare of supporting dozens of different phone models would push manufacturers to do this, but instead they just said "fuck supporting older models" and let them die young.
The old excuse that the hardware was too limited to support that kind of functionality is long since over. There is really no excuse anymore.
The old excuse that the hardware was too limited to support that kind of functionality is long since over. There is really no excuse anymore.
It's a problem on the whole ARM architecture and is one reason that ARM servers have not taken off. Every ARM board and chip is a special snowflake with its own weird boot and driver and hardware setup incantations. There's a bit of de-facto standardization but it's rough and not dependable at all.
The lack of proper boot and hardware standardisation is a huge issue. DTB tries to solve the fact different people put different peripherals on different ports, and there's no real hardware enumeration process to get around this.
But beneath this, one of the root issues at least in mobile devices is the system on chip nature of the design meaning you're at the mercy of the chipmaker to maintain appropriate drivers. These are invariably very very closed source on phones, as some areas like imaging and camera support were (and are now still, I guess) being bought in as super expensive IP blocks with serious NDAs and restrictions on what can be made available.
One reason Android is as fragmented as it was, was that they kept changing the system HAL, and chipset makers weren't providing upgraded drivers to support the new HAL as, from their perspective, the chip was end-of-life, old news, last year's model not making them any more money. I assume it isn't quite as bad on server, but single board computers running mainline Linux without patches, and with all peripheral and SoC component support are very rare, and noteworthy when they are found. Most still have pretty closed GPUs.
But when it's all on one chip, and you don't have any hardware discovery process, or even a standard way to boot the CPU, it's hard to see much of a generic future, as much as one would be great!
But beneath this, one of the root issues at least in mobile devices is the system on chip nature of the design meaning you're at the mercy of the chipmaker to maintain appropriate drivers. These are invariably very very closed source on phones, as some areas like imaging and camera support were (and are now still, I guess) being bought in as super expensive IP blocks with serious NDAs and restrictions on what can be made available.
One reason Android is as fragmented as it was, was that they kept changing the system HAL, and chipset makers weren't providing upgraded drivers to support the new HAL as, from their perspective, the chip was end-of-life, old news, last year's model not making them any more money. I assume it isn't quite as bad on server, but single board computers running mainline Linux without patches, and with all peripheral and SoC component support are very rare, and noteworthy when they are found. Most still have pretty closed GPUs.
But when it's all on one chip, and you don't have any hardware discovery process, or even a standard way to boot the CPU, it's hard to see much of a generic future, as much as one would be great!
There is a standard for ARM servers now, and it is basically UEFI + ACPI like x86 servers.
https://en.wikipedia.org/wiki/Server_Base_System_Architectur...
https://en.wikipedia.org/wiki/Server_Base_System_Architectur...
How were these early PCs any more closed than the IBM PC clones that followed? Some shipped with schematics and ROM listings. Smartphones have now been around longer than the entire pre-IBM PC era with no obvious movement towards any kind of opening outside of hobbyist devices. Game consoles have been around for decades without any such shift either.
> Some shipped with schematics and ROM listings.
They were more open than an iPhone, but they were not particularly open to anyone with less than a CE/EE level of computer and electronics expertise. They certainly were not designed to be modular and open like the clone PCs that came later.
They were more open than an iPhone, but they were not particularly open to anyone with less than a CE/EE level of computer and electronics expertise. They certainly were not designed to be modular and open like the clone PCs that came later.
I don't think that's accurate, just google up an Apple ][. But even if it were true, it wouldn't be strong evidence for your 'consumer hardware platforms become more open' theory given the reality of the longer-lasting smartphone era we live in now. Both the theory and the example used to support it seem starkly at odds with that reality, to me.
Game devices and smartphones were carefully designed to remain closed. Although the Pinephone and Librem 5 look like smartphones, and use many of the same components, they are far closer to phone-sized PCs. And so they're open from the start.
In addition to that concern, I would add that we've seen some of the opposite move happen - PCs change to be more like phones. The closed source OSes are all moving towards fenced off app marketplaces, with heavy sandboxing between apps. Even Ubuntu seems interested in this kind of move, with Snaps. We've also seen attempts to close the bootloader to "tampering", a restriction in place since the beginning of smartphones. We've also seen components like memory and batteries soldered into the computer instead of being replaceable. And so on.
I'm worried mobile phones are reducing the expectation that the average consumer has of being able to modify, upgrade, and repair their devices, and computer manufacturers are poised to take advantage of this, rather than the other way around.
I'm worried mobile phones are reducing the expectation that the average consumer has of being able to modify, upgrade, and repair their devices, and computer manufacturers are poised to take advantage of this, rather than the other way around.
And what would drive this transition? It won't be consumers, as before.
Agreed that the barrier to entry for mobile app dev is high enough to the point of excluding vast swathes of developers from building tools for themselves.
Ive been an iOS dev for 5 years and I'm now looking to move into web dev for a few reasons;
* making any mobile app is by default harder and more frustrating than making a web based equivalent.
* You can’t easily ‘remix’ an app, Inspect Element style learning is impossible.
* Native doesn’t really give you much in perf over web anymore (navigation and state refresh is still bad on web - but you can work to make it passable).
* SwiftUI is a huge step in the wrong direction. Its a poor mix between React and standard HTML, without the benefits of a styling markup.
* I am a rookie web dev, but a senior iOS dev and I find making web apps easier than a similar native app. After 5 years. Now sure this could say something about me - but I don’t think so as there is so much evidence based on the current state of adoption for the corresponding technologies. I have skin in the game when it comes to native and I have no doubts when I say it’s easier to make products with web tech.
* Xcode is tragically poor to then point where it is a consideration for me to stop working in the ecosystem, it is simply appallingly bad.
This is a bit of a rant, sorry about that, but I feel like there is a general mood in the spaces I dwell in the native has lost its appeal. Year to year the SDK updates become less relevant (you could argue last years SwiftUI is the biggest change in years but its not ready yet, it doesn’t make the ecosystem any nicer to work in given how long it takes to get from farm to fork with a mobile app, and anecdotally 100% of the devs I’ve talked to that have made an app in it have given up on it for their next idea for the time being)
Ive been an iOS dev for 5 years and I'm now looking to move into web dev for a few reasons;
* making any mobile app is by default harder and more frustrating than making a web based equivalent.
* You can’t easily ‘remix’ an app, Inspect Element style learning is impossible.
* Native doesn’t really give you much in perf over web anymore (navigation and state refresh is still bad on web - but you can work to make it passable).
* SwiftUI is a huge step in the wrong direction. Its a poor mix between React and standard HTML, without the benefits of a styling markup.
* I am a rookie web dev, but a senior iOS dev and I find making web apps easier than a similar native app. After 5 years. Now sure this could say something about me - but I don’t think so as there is so much evidence based on the current state of adoption for the corresponding technologies. I have skin in the game when it comes to native and I have no doubts when I say it’s easier to make products with web tech.
* Xcode is tragically poor to then point where it is a consideration for me to stop working in the ecosystem, it is simply appallingly bad.
This is a bit of a rant, sorry about that, but I feel like there is a general mood in the spaces I dwell in the native has lost its appeal. Year to year the SDK updates become less relevant (you could argue last years SwiftUI is the biggest change in years but its not ready yet, it doesn’t make the ecosystem any nicer to work in given how long it takes to get from farm to fork with a mobile app, and anecdotally 100% of the devs I’ve talked to that have made an app in it have given up on it for their next idea for the time being)
Things like this is when Firefox OS/Kai OS start to make sense. Make the OS a vehicle for web technologies. The application doesn't need to worry too much about OS specific quirks.
Unfortunately, Kai OS is such a huge departure in terms of interface so it doesn't really hit the sweet spot in terms of developer ease and user desires.
Unfortunately, Kai OS is such a huge departure in terms of interface so it doesn't really hit the sweet spot in terms of developer ease and user desires.
If you are interested in reviving the Firefox OS spirit on the PinePhone, join the #b2g channel on https://chat.mozilla.org/ . It's more active than ever these days :)
> * You can’t easily ‘remix’ an app, Inspect Element style learning is impossible.
Note quite, it's possible to inject FLEX into other apps and see what is going on:
https://github.com/Flipboard/FLEX
It isn't as easy as right clicking and inspecting element but it's not impossible.
Note quite, it's possible to inject FLEX into other apps and see what is going on:
https://github.com/Flipboard/FLEX
It isn't as easy as right clicking and inspecting element but it's not impossible.
SwiftUI is really great, it just needs more time in the oven. XCode is horrible though.
So I'm a bit confused how to get a Pine Phone at the moment - looking to the Pine store, I only see this:
https://store.pine64.org/?product=pinephone-community-editio...
It seems to be some Ubuports related edition of the Pine Phone & that's seems to be the only Pine Phone in their store.
Still the price matches (~150$) and while I don't have much interest in UbuPorts, I guess nothing should prevent me from flashing the Sailfish OS port, Fedora port or something else I'm interested in on the device.
And the UbuPorts logo on the back can be fixed by the ~5$ plain back cover (or a Sailfish OS or Fedora sticker).:)
https://store.pine64.org/?product=pinephone-community-editio...
It seems to be some Ubuports related edition of the Pine Phone & that's seems to be the only Pine Phone in their store.
Still the price matches (~150$) and while I don't have much interest in UbuPorts, I guess nothing should prevent me from flashing the Sailfish OS port, Fedora port or something else I'm interested in on the device.
And the UbuPorts logo on the back can be fixed by the ~5$ plain back cover (or a Sailfish OS or Fedora sticker).:)
Yes, at the moment that's your only option, but as you correctly call out there's no reason you can't install your own OS.
That's definitely the one you want as it has some hardware fixes based on learning from the Braveheart version. It's just vanilla PinePhone hardware with the UBPorts logo on the enclosure and should be shipping later this month.
Yeah, that seems to be the case, and I just ordered one even though I don't care about ubports.
Looking forward to leaving gps, camera, and microphone switches in the permanently off position and retiring the existing phone lacking such switches.
Looking forward to leaving gps, camera, and microphone switches in the permanently off position and retiring the existing phone lacking such switches.
Agreed. I ordered mine, but with all the excitement, the shipping is not going to happen until late May anyway. Still, it will be fun to play with.
I've already asked the question here and there but so far no good answer. I'm an old hacked : that is, I use a phone 99% of the time to send SMS and 1% of the time to give voice calls.
Everybody test various things : youtube, browser, camera, consoles, various OS'es, etc.
But does this pinephone can actually make phone calls (and receive phone calls) in a reliable way ? That's the only thing that prevents me from buying one.
(if you look on the web, you'll find a handful of comments about actually receiving phone calls and they are worrying at best)
Everybody test various things : youtube, browser, camera, consoles, various OS'es, etc.
But does this pinephone can actually make phone calls (and receive phone calls) in a reliable way ? That's the only thing that prevents me from buying one.
(if you look on the web, you'll find a handful of comments about actually receiving phone calls and they are worrying at best)
Yes, the HW can do that, and I've made them personally. Ubports will be able to make/receive calls soon if it does not already.
Though if you just want a phone for calling, you can get a dumbphone. I have that and it beats any smartphone anytime, including pinephone. "Charge and forget about for a month" is an unbeatable feature for people who don't call much or receive many calls.
I also developed a routing configuration for pinephone audio https://xnux.eu/devices/feature/audio-pp.html#toc-voice-call... that will eventually make this a very fascinating device and allow features (https://xnux.eu/ui/voice-calls-app.html) that no iPhone or Android will ever give you. So PinePhone has a potential to be a much more interesting phone device.
Though if you just want a phone for calling, you can get a dumbphone. I have that and it beats any smartphone anytime, including pinephone. "Charge and forget about for a month" is an unbeatable feature for people who don't call much or receive many calls.
I also developed a routing configuration for pinephone audio https://xnux.eu/devices/feature/audio-pp.html#toc-voice-call... that will eventually make this a very fascinating device and allow features (https://xnux.eu/ui/voice-calls-app.html) that no iPhone or Android will ever give you. So PinePhone has a potential to be a much more interesting phone device.
Quick question:
How is the pinephone software development coordinated and how did you get into it?
How is the pinephone software development coordinated and how did you get into it?
There's no single central development (aside from HW) effort, AFAIK. There are various individuals that work on particular aspects of the SoC/Phone support in the Linux kernel with some cross-over with linux-sunxi community.
And there are distribution/userspace efforts which I don't have much insight into, because I'm more focussed on the Linux kernel side of things. But from the edges it looks like a fairly small group of people pushing things forward.
I got originally interested in Linux kernel programming through various Xunlong Orange Pi boards (probably since Linux 4.6 times), Allwinner tablets, etc. I spent some years on it, and got to know a good bunch of Allwinner SoCs, and Linux driver development quite well. So when PinePhone got announced with Allwinner A64 in it, I was immediately interested. Pine64 community founder then offered me the developer unit, after noticing my interest. That was the start of it. ;)
And there are distribution/userspace efforts which I don't have much insight into, because I'm more focussed on the Linux kernel side of things. But from the edges it looks like a fairly small group of people pushing things forward.
I got originally interested in Linux kernel programming through various Xunlong Orange Pi boards (probably since Linux 4.6 times), Allwinner tablets, etc. I spent some years on it, and got to know a good bunch of Allwinner SoCs, and Linux driver development quite well. So when PinePhone got announced with Allwinner A64 in it, I was immediately interested. Pine64 community founder then offered me the developer unit, after noticing my interest. That was the start of it. ;)
I bought the Braveheart edition of the PinePhone and have played with various builds on it. I didn't try mobile nix, but I may give it a shot (though I've not used a Nix before so it might be a learning curve).
The PinePhone has a lot of potential IMHO. It's nowhere near ready to be your primary phone, but it's neat and at $150 it's a fun little toy.
IME, Fedora worked the best out of the box. I had issues with the battery not being recognized by postmarketOS (along with a few other things) though from what I've heard from others in chat rooms that's atypical (usually pmOS works great).
I'm super impressed with the PinePhone hardware wise. It looks and feels like a decent phone, and it's easy to remove the back and tinker or flip the hardware switches. You can tell they put a lot of thought and attention to getting it right. My only hope is that once things are working, I can buy one with specs comparable to the OnePlus 8 Pro (with similar price tag of course).
The PinePhone has a lot of potential IMHO. It's nowhere near ready to be your primary phone, but it's neat and at $150 it's a fun little toy.
IME, Fedora worked the best out of the box. I had issues with the battery not being recognized by postmarketOS (along with a few other things) though from what I've heard from others in chat rooms that's atypical (usually pmOS works great).
I'm super impressed with the PinePhone hardware wise. It looks and feels like a decent phone, and it's easy to remove the back and tinker or flip the hardware switches. You can tell they put a lot of thought and attention to getting it right. My only hope is that once things are working, I can buy one with specs comparable to the OnePlus 8 Pro (with similar price tag of course).
“It's nowhere near ready to be your primary phone”
May I ask why? I was about to look into the project and potentially purchase one.
May I ask why? I was about to look into the project and potentially purchase one.
In addition to the issues like MMS not working, there are lots of papercuts that collectively add up to a really annoying experience. I kept having issues with the battery being recognized one minute and not the next. The touch detection needs some polishing, as does the keyboard. They are usable but have some metaphorical rough edges that need metaphorical sanding. Battery life isn't great yet either, I assume because it's not optimized yet.
That said, go ahead and get one. They're cheap enough that they are fun toys, and it's a way to vote with some dollars. Even tho it's not ready for daily driving, I think it will be in a few months, or sooner given how fast things are moving in the community now that there's real hardware people can buy. You can help with development by reporting bugs and such. Also you get to be a part of history!
That said, go ahead and get one. They're cheap enough that they are fun toys, and it's a way to vote with some dollars. Even tho it's not ready for daily driving, I think it will be in a few months, or sooner given how fast things are moving in the community now that there's real hardware people can buy. You can help with development by reporting bugs and such. Also you get to be a part of history!
Gotcha. Many thanks!
The hardware should be solid as of the CE release (Braveheart was essentially the Beta release), it's the software that's a work-in-progress since there really hasn't been a widely used (open) Linux handset until now.
It sounds like the most important issues (i.e. battery life/suspend, camera support etc.) is getting resolved fairly quickly while sanding down the rough edges on the UI will probably take time. So it's usable, just not rock solid or feature complete from a software standpoint.
It sounds like the most important issues (i.e. battery life/suspend, camera support etc.) is getting resolved fairly quickly while sanding down the rough edges on the UI will probably take time. So it's usable, just not rock solid or feature complete from a software standpoint.
I see. Many thanks.
It doesn't run Android apps (well ... yet!), native apps are "meh", the UI quality is questionable and the battery life miserable. That's my last state of knowledge. Does anybody know how the power management stuff is going? I'm planning to build a mobile device with the very related SOPINE and think that project might profit from some lessons on that front.
And oh yeah, I'm totally planning to buy a PinePhone because because it's cool as hell.
And oh yeah, I'm totally planning to buy a PinePhone because because it's cool as hell.
Suspend to ram is working these days with crust firmware. It consumes some 150mW in suspend I think. So that should get a ~70h suspend time. That's most probably without a modem.
I still have to measure it a bit and play with it more. I've made a fake battery recently to measure power consumption in suspend independently: https://megous.com/dl/tmp/IMG_0047.JPG
I still have to measure it a bit and play with it more. I've made a fake battery recently to measure power consumption in suspend independently: https://megous.com/dl/tmp/IMG_0047.JPG
Cool stuff, thanks! Do you share more about this somewhere, say, on the fediverse (mastodon)?
I share some of my stuff on my website https://xnux.eu
Last I looked into that, most distros were able to run Crust on the embedded microcontroller, shutting down all cores and leaving it up to the uC to wake up the main CPU. This saves a substantial amount of power, and it seems that the device can now last around a full day.
So I'd say it can be used as a daily driver, unless you have strict requirements on app compatibility.
Speaking of which, I wonder how an emulated Android device (or even a real one) streaming video on my pinephone trough LTE would fare :)
So I'd say it can be used as a daily driver, unless you have strict requirements on app compatibility.
Speaking of which, I wonder how an emulated Android device (or even a real one) streaming video on my pinephone trough LTE would fare :)
> Speaking of which, I wonder how an emulated Android device (or even a real one) streaming video on my pinephone trough LTE would fare :)
Yeah, I keep meaning to glue together scrcpy+xvfb+x11vnc+guacamole when I get the time and motivation. Should be fun:)
Yeah, I keep meaning to glue together scrcpy+xvfb+x11vnc+guacamole when I get the time and motivation. Should be fun:)
Haven't looked up every project name you wrote, but that sounds like waypipe or xpra :)
Plainly put, none of the OSes do the basic features of a phone. Ubuntu Ports is the closest to being daily driver ready, and it cannot do MMS[0] (so group texts and picture texts are out). I cannot comment on the state of other OSes.
Even with that, most of them do not have a lot of basic features of what a vanilla smartphone would have either.
That isn't to say it will stay that way. I try out a few of the OSes about once a month or so, and the difference from when I first got it to now is astounding. I think (hope) that by the end of the year that I can use a Pinephone as my daily driver.
[0]https://gitlab.com/ubports/community-ports/pinephone
Even with that, most of them do not have a lot of basic features of what a vanilla smartphone would have either.
That isn't to say it will stay that way. I try out a few of the OSes about once a month or so, and the difference from when I first got it to now is astounding. I think (hope) that by the end of the year that I can use a Pinephone as my daily driver.
[0]https://gitlab.com/ubports/community-ports/pinephone
Thanks for the reply.
[deleted]
No verified boot.
If security (which is necessary for ensuring privacy) is of value to you, get a Pixel 3a, possibly with GrapheneOS.
Get both to support free software, the idea of free hardware, but don't compromise your phone security model just yet.
If security (which is necessary for ensuring privacy) is of value to you, get a Pixel 3a, possibly with GrapheneOS.
Get both to support free software, the idea of free hardware, but don't compromise your phone security model just yet.
I worry more about apps and weird SDKs that ping foreign servers all the time, which seems to be the custom on Android and iOS.
A64 can do secure boot, I'm sure. So if anyone will have interest in implementing it and locking down their device, it's possible.
Personally, it seems like too much trouble, for little benefit at this point in time.
A64 can do secure boot, I'm sure. So if anyone will have interest in implementing it and locking down their device, it's possible.
Personally, it seems like too much trouble, for little benefit at this point in time.
Please. Commercial phones "security model" is to protect themselves from the user, and that's about it.
The baseband itself is the main backdoor.
The chips are built to mitigate this now.
And upon reboot, a proper verified boot, as well as Auditor &or Attestation, lets you know, with cryptographic proof, whether your phone's firmware has been compromised by such a piece of hardware.
And upon reboot, a proper verified boot, as well as Auditor &or Attestation, lets you know, with cryptographic proof, whether your phone's firmware has been compromised by such a piece of hardware.
...and yet they are choke full of spyware.
In the context of a proprietary phone, secure boot and all of that is the new tivoization.
In the context of a proprietary phone, secure boot and all of that is the new tivoization.
Would there be anything illegal about modifying a phone such that the location data it submits looks like some random person in Sheboygan, Wisconsin, instead of reporting where I actually am? Pretty much all I want in a phone is the ability to spoof location data and act as a hotspot for a smarter device (that doesn't have location awareness built in) so I can access richer apps over a VPN in greater privacy.
The cellular network always has to know your approximate location, or else it can't get your data to you. But that doesn't use GPS.
Offhand (and I'm very far from an expert) the only situation I can think of that spoofing GPS might have legal ramifications is when using E911. In general, it's probably better to spoof a "I don't see enough satellites to get a fix, sorry" status than to spoof a "I'm definitely in Sheboygan" status.
Offhand (and I'm very far from an expert) the only situation I can think of that spoofing GPS might have legal ramifications is when using E911. In general, it's probably better to spoof a "I don't see enough satellites to get a fix, sorry" status than to spoof a "I'm definitely in Sheboygan" status.
> The cellular network always has to know your approximate location, or else it can't get your data to you.
Sure. But if the cellular radio is a separate device, that information isn't necessarily available to the OS.
If you use WiFi, that must also be a separate device, to prevent the OS from knowing what APs are available, and doing geolocation based on that.
Sure. But if the cellular radio is a separate device, that information isn't necessarily available to the OS.
If you use WiFi, that must also be a separate device, to prevent the OS from knowing what APs are available, and doing geolocation based on that.
If you're talking about GPS location, then don't use application software that reports your location. MicroG+LineageOS will suffice.
If you're talking about tower based location, there is no way to significantly spoof your location since you can only connect to local cell towers.
To mitigate the latter, what you actually want is a phone with smarter software that will communicate over Wifi most of the time (rotating macaddr of course), perhaps with the option to turn on a cell radio in case you really need to communicate out of wifi connectivity. Hopefully the freshly built software stack inspired by new platforms will end up being conducive to this usage.
If you're talking about tower based location, there is no way to significantly spoof your location since you can only connect to local cell towers.
To mitigate the latter, what you actually want is a phone with smarter software that will communicate over Wifi most of the time (rotating macaddr of course), perhaps with the option to turn on a cell radio in case you really need to communicate out of wifi connectivity. Hopefully the freshly built software stack inspired by new platforms will end up being conducive to this usage.
Fake GPS does it.
https://play.google.com/store/apps/details?id=com.blogspot.n...
https://play.google.com/store/apps/details?id=com.blogspot.n...
Perhaps.... but Google would still know your real location, no?
And your carrier, and anyone who does location based on IP, and anyone who does location based on inaudable noises only your phone can hear (https://arstechnica.com/tech-policy/2015/11/beware-of-ads-th...), and...
But, this would still help protect against the simplest way to steal your location data, which is what a lot of services do
But, this would still help protect against the simplest way to steal your location data, which is what a lot of services do
There's a hardware switch for the mic but yeah it's pretty hopeless to hide your location in those threat models.
Not sure if it would be easy to determine the legality, but you might be able to check EULAs and TOS of the services you plan to use to see if they have a clause establishing their ok-ness with false data.
Tangent - Sheboygan has excellent brats
Tangent - Sheboygan has excellent brats
Pinephone feels like the closest I might get to a completely open platform that would see everyday use. My phone is of course the device that sees the most use.
It would be excellent to review the source code but its intractable to review everything.
An idea: how feasible would it be to either use static analysis or some kind of call tracing on this platform?
For a simple task like “boot phone”, one could reduce the source code down to the bare minimum needed to review for individual actions.
One could just delete code at will I suppose to make something that boots and does nothing else but I suspect getting it to compile would be very difficult. Tracing execution feels a bit more doable.
It would be excellent to review the source code but its intractable to review everything.
An idea: how feasible would it be to either use static analysis or some kind of call tracing on this platform?
For a simple task like “boot phone”, one could reduce the source code down to the bare minimum needed to review for individual actions.
One could just delete code at will I suppose to make something that boots and does nothing else but I suspect getting it to compile would be very difficult. Tracing execution feels a bit more doable.
buildInputs = [
hostPkgs.pkg-config
hostPkgs.patchelf
targetPkgs.libGL.all
targetPkgs.SDL2.all
];
nativeBuildInputs = [
hostPkgs.pkg-config
hostPkgs.patchelf
];
buildInputs = [
targetPkgs.libGL.all
targetPkgs.SDL2.all
];
Does anyone know if the pinephone WiFi supports ad-hoc/mesh mode 802.11?
well, the driver seems to support ibss and p2p. hardmac though, with a blob
https://github.com/Icenowy/rtl8723cs/blob/master/core/rtw_io...
https://github.com/Icenowy/rtl8723cs/blob/master/core/rtw_io...
Really neat to see an application in the wild written in Zig, but it makes a lot of sense why it would be used for a cross-platform target. I've got my PinePhone on pre-order, I'll have to give doing something similar a shot when it gets arrives!
Oh, that's the language! Was having trouble figuring it out. Zig looks great.
This right here is what excites me the most about Linux phones
This is the future. If you're doing iOS or Android dev professionally, your days are numbered.
Imagine a board meeting at JP Morgan and the CEO pulls out a Pinephone. iOS and Android make up the vast majority of mobile devices and will for the forseeable future.
I can see Linux on the smartphone becoming about as popular als Linux on desktop. Appreciated and used by relatively few but enthusiastic people.
Think longer. Apple Inc. was founded 44 years ago. They were a PC company until 11 years ago. Can we be confident that in 2031 the libre phone will have gained no market share to the iPhone? What about in 2064?
If the UX does not vastly improve even beyond what is currently good by Linux standards I don’t see a reason for most people to switch.
It might not be the thing driving people to switch, but I'd be hesitant to claim that Desktop Linux is any worse than the competition. Like, I don't have the exposure to comment on Apple's products, but Windows is no better than XFCE, GNOME, MATE, or KDE these days, Android is a toy, and ChromeOS isn't better. Like... I know this is weak praise; Windows versions after 7 got worse as they fragmented (have they re-merged the control panels yet?), Android was born a mobile OS, and ChromeOS was always meant to be cut-down, but the result is that the playing field is level.
I don't know who the CEO of JP Morgan is, but I imagine he might be one of the few who would pull out a Pinephone with a his own custom software stack with encryption for all his communications and perhaps some other special tools.
You're imagining wrong
What a wonderful argument. Really shows your intellect.
[deleted]
Does anyone know if it works for GSM and CDMA sim cards?
Not sure what you mean exactly. But I have LTE disabled via my mobile operator, and modem works for me.
In the Specification section here: https://wiki.pine64.org/index.php/PinePhone there's a list of supported bands and standards.
In the Specification section here: https://wiki.pine64.org/index.php/PinePhone there's a list of supported bands and standards.
[deleted]
+1 for a cool name.
Having been reading Greek myths recently, I initially pronounced it to rhyme with "Persephone". I guess it's supposed to be "Pine" "Phone" though.
Why Pine? Like the email client?
Why Pine? Like the email client?
The company is Pine64. They also make PineBook and a bunch of single board computers.
A few days ago I've published my custom bootloader for PinePhone: https://megous.com/git/p-boot/about/
It's the one I use for a quick booting to Linux: https://www.youtube.com/watch?v=kxqdF7H_It8
Something to try if you have a pinephone and want to experience sub-second boot times.
Anyway, if you like bringing up new hardware, or optimizing things, this is as good an opportunity as it gets to get pinephone and have fun. There are lots and lots of areas that can be optimized and improved in usersapce and in the kernel and you can do whatever you fancy or want to learn about. It's all being developed by random people on the internet. ;)