Making Librem 5 Apps [video]
puri.sm
puri.sm
At first I tried setting it up with a keyboard, mouse & monitor, but it was a little fiddly to get everything usable.
I had a USB-C hub from a macbook with PD + ethernet + hdmi, but I couldn't get the hdmi display to sync.
So I got another usb-c hub with ethernet + dp (+other ports) and that worked.
amazing: my phone desktop showing up on my 4k monitor!
So, that was pretty cool, but I still had a lot of fiddling to do - like which display the app comes up on, and how to switch things around. Also sometimes the display wasn't recognized when I wanted it do - I think I had to reboot with the display plugged in, because hotplug sometimes didn't work.
(There have been software updates since I tried this - it may be better now).
However, at the same time I ordered the second hub, I also got a $15 USB-C + PD + ethernet dongle.
Turns out that was really what I wanted. Let the phone be a phone, sit there charging and ssh/scp into it from my regular system. I can access the entire filesystem.
All of this really drives things home about Apple.
When the iPhone came out, apple was breaking new ground, so people even accepted web apps, because before they had nothing. And with quality/security, the app store made sense.
But after over a decade you realize that the apple ecosystem is more about control.
Why can't I write my own apps (without asking permission/eula). Why can't I run my own apps without either signing up as a developer and paying, or renew some certificate every 7 days? Why can't I plug all the things into USB and use them?
Apple has mindfully denied a lot of utility for their users. I thought maybe the mac usability would trickle over to iOS, but it seems the iOS lockdown has trickled over to the mac instead.
EDIT: wait. Let me say "Thank You" to the purism folks for doing this. It took a few years, but this phone makes me really really happy. I figure in a year or two it will let normal folks happily run their lives ios/android-free.
Marketing caused us to regress to the fragmented landscape of gimmicky special purpose devices that we have today.
I hate to be "that guy" - and it seems like I always have to be "that guy" - but this will never allow "normal" folks to happily run their lives iOS / Android free.
The reason is because the collection, categorization, and collation of data on smartphone users is what drives the whole thing forward. It's the gas. The petrol. The solar power. The wind turbines. Without apps collecting and using data about their users, everything ends up having to be monetized differently and people have already shown that's not going to happen. You can't even get people to pay a few dollars a month for the single most important "app" on the Internet - email.
Sorry, but Librem 5 will never be more than a fun developer's toy. Most people are honestly pretty lazy and the sad simple fact is that they do not want to be challenged at all ever. They want to show up somewhere... bang on their keyboard like a monkey, or swing their hammer like a chimp, or smack their buttons like a macaque, and go home eight hours later, and then in 7-14 days, collect their bananas and eat them while watching Ow! My Balls!, or a slightly more advanced version of it like, American Ninja Warrior.
While the rest of nature is in a desperate bid for survival-at-all-costs that is consistently wiping out the slowest and the dumbest, through our struggle, we've managed to regress... we allow the dumbest and the least fit to survive. I know a bunch of wannabe evolutionary biologists here are going to throw around ideas they don't really understand, like, "Fitness doesn't mean being the smartest or the strongest, just the organism most able to reproduce!" No, that's just one single strategy, and not even always an optimal one.
This isn't an argument for killing off the dumb and weak, of course. I'm merely pointing out that most people have zero desire to be truly challenged, on anything, ever. That's exactly why they want their Samsung walled Android experience and their Apple walled iOS experience.
I wish we lived in a world where everyone spent a few dozen to a few hundred hours learning hard stuff to thereby make their lives permanently easier, but we don't. Most would rather spend a few hours doing relatively monotonous stuff over and over than actually learn something new.
OR
Maybe I'm just being an old curmudgeon. I guess we'll see.
I get this, but I'm not sure that using a phone that exposes a full Linux system is the answer here. In fact I think for many people one could make the opposite argument – spend a few hours learning how to use an iPhone and never have to worry about many classes of problems.
Yes, many people use iPhones because they don't have the ability to make an informed decision, but many people also have all the skills to make that decision and still choose them. It's all trade-offs, and for some, walled gardens and EULAs are not a problem, and having a camera and (closed source) software that allows better photos of their kids is far more important.
or the full list of vulns in the Linux kernel, for that matter.
I (fellow curmudgeon perhaps) totally agree
F-Droid and GNU/Linux repositories work flawlessly without any ads and, moreover, have much less malware, if at all.
Backstabber's Knife Collection: A Review of Open Source Supply Chain Attacks - https://arxiv.org/abs/2005.09535
F-Droid's a great project, but needs to take security more seriously, even if that means accepting some help from adjacent projects.
Maybe I'm just being an old curmudgeon. I guess we'll see.
When predicting the future, ego gets involved. We invest at least a little of our pride. We want to be right.
The problem is you could be both right and wrong at the same time. The outcome could be what you foresee, but not for the reasons you think.
What if Librem 5 will never be more than a fun developer's toy, but for other unrelated reasons? Sorry, that's cheating.
1) It's difficult to use as a daily driver even for experienced people. It's impossible for the average person.
2) It's not a premium device with a big beautiful screen, lots of RAM, the fastest processor, tons of storage, etc. So it doesn't attract the non-technical enthusiast crowd.
3) It doesn't have brand appeal like Samsung or Apple. It's not consider a "status" item by the general population. So it doesn't attract a beautiful young fashion model who wants to be seen with an iPhone 12 Pro Max XL Super Duper.
4) It runs an operating system most people have never heard of - Linux. Most people know Android, most people know what iOS is, or have at least heard of it. The people I mentioned above don't know Linux. They especially don't understand what makes this brand of Linux "special".
5) In order to this to eventually overtake the world, the entire world has to shift to a paid model for literally everything, because how else are you going to fund it? Everybody's exchanging data with everyone. Data about users. No exchange means increased prices across the board, for everything, because no data means no targeted advertisement. Hell, you can barely do untargeted advertisement with no data.
How's that? Happy now?
Although true, this is a problem with software, which gets better every month. I'm sure within a year it's gonna be alright. (A year ago the phone could not even be charged while being powered on or receive calls.)
> 2) It's not a premium device with a big beautiful screen, lots of RAM, the fastest processor, tons of storage, etc. So it doesn't attract the non-technical enthusiast crowd.
Actually, it is in the world of GNU/Linux phones (the alternative being Pinephone). It is also powerful enough to drive GNU/Linux smoothly, play 3d games, videos on a big screen (which popular phone can do that?) and so on. It can also replace your laptop for most typical tasks.
> 3) It doesn't have brand appeal like Samsung or Apple. It's not consider a "status" item by the general population. So it doesn't attract a beautiful young fashion model who wants to be seen with an iPhone 12 Pro Max XL Super Duper.
Give it some time ;) It already has some brand value, despite a niche one.
> 4) It runs an operating system most people have never heard of - Linux. Most people know Android, most people know what iOS is, or have at least heard of it. The people I mentioned above don't know Linux. They especially don't understand what makes this brand of Linux "special".
People don't care whether they heard of it or not. Android runs Linux kernel just fine, so Linux is already popular. What makes it "special" is written on the official Librem 5 page. And it's not only for geeks: https://puri.sm/products/librem-5.
> 5) In order to this to eventually overtake the world, the entire world has to shift to a paid model for literally everything, because how else are you going to fund it? Everybody's exchanging data with everyone. Data about users. No exchange means increased prices across the board, for everything, because no data means no targeted advertisement.
GNU/Linux repositories work flawlessly without any ads and, moreover, have much less malware, if at all. It's not the whole world, but a large part of it nonetheless.
> Hell, you can barely do untargeted advertisement with no data.
This is how newspapers worked since forever.
It boggles my mind how so many people install alexa, ring, samsung tvs and all the brightly colored google things. Of course they'll buy whatever phone has neat features.
Human nature is human nature, and people want convenience not privacy.
But take it from me - one curmudgeon to another - after you've been hit over the head with ever more audacious privacy policies year after year, this phone is a relief.
I don't mind lowering my standards for functionality as long as there's a way forward.
I would recommend you try running a librem 5 or maybe a pinephone in a year or two. (though from pinephone videos I've seen, the librem stutters less if ever)
Back to normal people, I guess I was thinking of some of my friends who have bought phones and literally never installed an app. But some of them are millionaires who probably are tracked everywhere they go by the default apps and the default privacy policies. They get popups all the time and their phone rings with spam.
This phone is expensive for what it provides, so maybe it's a hard sell.
Out-of-the-box - the main functionality is a phone app, a messages app, a web browser, contacts, alarm clock and an app store.
There are a few more, and more pop up in the app store, but some core things are missing.
The ones that I hope will come out soon are a camera app, a maps app and some sort of media player. I'd personally like a todo list and a shopping list.
I think if you got those going, you could hand it to a normal person and they could use it. I don't think it would be that different from a basic android phone.
But what I REALLY look forward to are the things other phones aren't allowed to do.
I would like to see:
- smarter call handling - I think there could be smarter blocking. But I also wonder could your phone take a message and put it through if it meets conditions?
- rolling wifi - could you have a wifi access point that changes ssid on a timer? and your phone changes too?
- location based wifi - could your wifi go off when you leave home and come back on when you get nearby?
- a smart firewall - whitelist your traffic
- per-site web-browsers with sandboxing - could you have an icon that launches a web browser in a sandbox and talks to one and only one site? That might be the solution for big services - they all have web access, use that but control it.
- rsync your entire phone when you get home
A lot of things you're espousing, I'd like to see.
https://www.hackers-game.com/2020/09/08/robocalls-fight-bots...
I'm super impressed with the state of "convergence" here. Dragging a window over from a full desktop monitor to the phone was exciting to watch.
I doubt I would want to do development directly on the phone, but only because the phone is going to be underpowered compared to a desktop. But since it's just a standard linux distro on the phone, it probably wouldn't be too hard to set up the Librem to automatically pull the latest build from the desktop/laptop for testing purposes.
I still use it every day, since it has my two-factor auth credentials (in GPG); although I transferred my SIM to a PinePhone last Christmas :)
Convergence has been held back by UX and UX alone.
It's the single most-requested feature at my bespoke secure technology firm.
I'm curious now, is your firm going to order a bunch of Librem 5 phones?
Current releases of the Librem 5 have been plagued by thermal throttling issues and poor battery life which in some cases has clocked in at less than 1 hour at idle.
The Librem 5 does not even support software encryption and no progress has been made toward adding even LUKS encryption. The Librem 5 lacks a secure element for any hardware binding on the encryption and so would be entirely dependent on software-only encryption.
The rebranded version of Debian that the Librem 5 uses as an operating system uses the same security model as the desktop stack, which is a perimeter or "all or nothing" security model. In the future, applications may be installed utilizing FlatPak. The threat model and measures FlatPak takes to meet it are as of yet unclear and uncertain.
From https://github.com/Peter-Easton/GrapheneOS-Knowledge/blob/ma... which may be mildly out of date — but I doubt it.
tl;dr Wake me up when you have an IOMMU!
I'm not sure about the status of LUKS on PureOS, but I know that Mobian supports it and there is a supported build of Mobian for the Librem 5. First-hand, I've encrypted my Pinephone image, but don't have a Librem 5 so can't independently confirm that it actually includes that during the eMMC flashing process, although I don't have a reason to believe elsewise.
Not sure if it's bad practice to share, but then what options do you use? If Debian's security model isn't enough, do you roll your own Linux base from something else instead? What kind of hardware is there as an alternative?
I can play that game, too!
https://www.merriam-webster.com/dictionary/skepticism
https://www.merriam-webster.com/dictionary/wrong
If there are factual in accuracies with my claims, I am happy to be proven wrong. That's how I learn!
I just need proper citations.
Thank you for this source, I'll check it out!
> The connection of an untrusted USB device to dom0 is a security risk since the device can attack an arbitrary USB driver (which are included in the linux kernel), exploit bugs during partition-table-parsing or simply pretend to be a keyboard.
This would be the same for any PCIe device. PCIe does not have any cryptographic authentication scheme that I am aware of, and PCIe device drivers are likewise in the linux kernel.
> The whole USB stack is put to work to parse the data presented by the USB device in order to determine if it is a USB mass storage device, to read its configuration, etc. This happens even if the drive is then assigned and mounted in another qube.
I don't see how this would be different versus a PCIe device?
> If you connect USB input devices (keyboard and mouse) to a VM, that VM will effectively have control over your system.
USB controllers use PCIe in order to function.
It seems the primary difference between the two are which set of tools you go after to attck the system. The primary difference is that PCIe device attacks are less so in the wild (I do not know of a PCIe rubber ducky, but there is nothing stopping anyone from making it), and (depending on your system) involve more invasive physical access (USB is a physical port, but then again, Thunderport is effevtiely PCIe in a port: https://tidbits.com/2015/01/09/thunderstrike-proof-of-concep... . There is an example attack against PCIe).
As far an an IOMMU goes, that exists because PCIe uses DMA, so am IOMMU enforces boundaries so that a rogue PCIe device cannot do a DMA attack (here is one such exmaple: https://papers.put.as/papers/macosx/2006/ab_firewire_rux2k6-... . I skimmed through it so I am not sure if it is entrely correct, but the theme of the attack applies). But an IOMMU is typically software based too, so one can attack that and the DMA controller. USB does not use DMA.
Some of that outdated post's problems could be rectified. Some (important!) ones cannot.
As stated elsewhere: wake me up when you have an IOMMU.
OSK-SDL has been ported to the Librem 5 to the best of my knowledge (Source: talking to the actual dev working on it).
> The Librem 5 lacks a secure element for any hardware binding on the encryption and so would be entirely dependent on software-only encryption.
You do know it has a smartcard port right? That would be the whole point of having the smartcard: hardware binding encryption! Also see this: https://news.ycombinator.com/item?id=26773309
> Current releases of the Librem 5 have been plagued by thermal throttling issues and poor battery life which in some cases has clocked in at less than 1 hour at idle.
Actual citation needed please, as this contradicts you: https://puri.sm/posts/librem-5-4500mah-battery-upgrade/
> This renders the firmware unupdateable without shorting a connection.
That is simply incorrect: https://source.puri.sm/Librem5/redpine-firmware-nonfree https://source.puri.sm/Librem5/firmware-tps6598x-nonfree
Note how the update procedure doesn't call for "shorting a connection".
> Although the modems and radios are not attached to the host via DMA, they rely on USB for isolation, which simply shifts the trust from the kernel driver to the kernel USB stack, and USB was never designed with distrusting the device plugged into it in mind unlike SMMU/IOMMU, which is specifically designed to mitigate unconstrained DMA.
Do you have a citation for this beyond a repository that says: "Something I should mention off the bat right now is that this repository is a rough draft. Much of the information in it is very work-in-progress, and some of it needs to be looked at."
Being that off the top of my head I am able to contradict the most of your statements (with actual citations), I am skeptical of your claims, as laptops and other portable devices have to worry about rogue USB devices too, and this has been a known issue for over a decade.
It seems almost all your comment is either 1) out of date (And the last commit to the repository you posted to was 11 Feb 2020) or 2) flat out wrong.
tl;dr Did you do any real research on this topic?
https://news.ycombinator.com/item?id=26772189 When you make a claim like that, which I assumed meant your company did some sort of baseline research for this claim. Your reply directly contradicts that statement since your citation is riddled with errors.
I actually sourced all of my info (except for the OSK-SDL one...but I don't exactly know how to source a conversation between two people, so you'll have to trust me on that one. Alternatively, you are welcome to do your own research to counter my claim!). Are there problems with my citations? In the scientific community, this is why we cite sources. I don't have to trust the primary author when their sources are cited!
I am saying the rest of your document you cited was riddled with errors that I could show was wrong off hand (with citations!), so any claims you make that I don't know is right, I treat with skepticism.
I'm unconvinced that you have actually looked through the source of the Librem 5, considering you didn't know it supported encryption! Hell, did you look at their product page? You can see that it has a smartcard on their product page! And yet you claimed it doesn't have "hardware backed encryption".
So either you are a) completely unaware of how to do basic research and citations or b) willfully spreading misinformation.
Just have elsewhere.
All I can do is point.
But wouldn't it make the phone more secure, since no malware can update the firmware without your knowledge? (Although it's just not true as kop316 showed).
> Current releases of the Librem 5 have been plagued by thermal throttling issues and poor battery life which in some cases has clocked in at less than 1 hour at idle.
This was true about a year ago. Current state is 10-12 hours battery life without suspend. No thermal throttling issues anymore. https://source.puri.sm/Librem5/community-wiki/-/wikis/Freque...
> The Librem 5 does not even support software encryption
Yes, it does: https://puri.sm/posts/sneak-peek-of-the-next-pureos-release-....
> The Librem 5 lacks a secure element for any hardware binding on the encryption and so would be entirely dependent on software-only encryption.
Not true, it has a smartcard: https://puri.sm/posts/your-own-personal-enclave-the-smart-ca....
> uses the same security model as the desktop stack
Yes, this may be a problem. However, you do not have to use PureOS. You can install anything you like on this phone.
Concerning the USB isolation, you are probably right. How other phones deal with it? Couldn't you simply avoid connecting it to untrusted hosts?
No not really. Look up the boot ROM vulnerability on the Nintendo Switch. I'm sure Nintendo wishes they could update that.
I'm not sure if I agree or not to be honest. I think there's good things (like you said, make sure the user knows they are doing it), but I have never convinced myself it is absolutely superior.
EDIT: One example of why it may not be good. If there is friction to updating, it means less folks will update (or you have to now take special care to make it as easy to update as if the switch was not there).
But like I said, I'm not convinced one way or another. I think there's cases when it is true, but I lean to that being the exception, not the rule.
Some seriously forward thinking shit.
> This renders the firmware unupdateable without shorting a connection.
That's incorrect, the firmware can be updated by the user without having to modify the hardware.
> the firmware cannot be updated without physically dismantling the phone
Not true.
> Firmware initialization is also no longer under the control of the host operating system because the initialization is carried out from outside the OS: changing or updating software on the host will not address these design defects.
The OS can choose to not use the firmware stored on flash and load it directly from rootfs instead. postmarketOS does that already for WiFi firmware, for instance. Compiling u-boot that doesn't use the SPI flash for DDR blob is trivial as well. The point of having the flash is for the OS to not have to touch it, but nothing prevents the user from touching it if they really want, not even "having to short a connection".
> Current releases of the Librem 5 have been plagued by thermal throttling issues and poor battery life which in some cases has clocked in at less than 1 hour at idle.
That "current" means "fixed more than a year ago with software updates".
> The Librem 5 does not even support software encryption and no progress has been made toward adding even LUKS encryption.
Not true, LUKS works fine with PureOS Byzantium for months now.
> The Librem 5 lacks a secure element for any hardware binding on the encryption and so would be entirely dependent on software-only encryption.
There's a GPG smart card reader next to the battery compartment.
> which may be mildly out of date
...as seen above.
Don't trust any information about the Librem 5 coming from GrapheneOS developers, their reaction to pointing out their mistakes is to block the person that corrects them ;)
I couldn't confirm that (from a cursory search), but if so, this massively undermines my confidence in using it on my Pixel.
(granted, I'm probably not the best in non-violent communication, but they could at least try to do some research anyway ;))
> (granted, I'm probably not the best in non-violent communication, but they could at least try to do some research anyway ;))
Considering how badly incorrect the dev's page is, I agree. I gave them some credit since it was over a year old, but if they behave like that, it sounds like I need to reinstall LineageOS.
I wouldn't recommend this to anyone as a first choice.
Which is riddled with errors. Make a well cited annotation of the errors.
You say you addressed my comments "elsewhere" https://news.ycombinator.com/item?id=26783664
I ask you where.
Your response is a deflection: https://news.ycombinator.com/item?id=26784172
My interaction with you has only undermined my confidence in GrapheneOS (especially considering seba_dos1's perspective, and he is a person I have worked with and I trust his judgement). I have no idea why you think I would listen to you about LineageOS.
In reality, the only thing that prevents the firmware from being upgraded is the default software not implementing such features (because PureOS does not and will not distribute non-free software or firmware). A user who wants to do that can reflash everything without modifying the hardware in any way or even opening the case. Both WiFi flash and the M4 core-based solution described in https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurd... can be bypassed completely to load the firmware from rootfs just by using a different kernel and bootloader, and disabling SPI flash read-only protection is a single line of code change in the device tree.
Basically it needs everything but the motherboard/cpu/ram meaning you need a $500 peripheral to turn your awesome $1000 dollar phone into a merely OK computer.
If you really want to save money you probably have a $400 laptop and a $100 phone. If you have money to spend a $1000 phone AND a $1500 laptop will be a nicer experience.
With support for arm software better than ever before and better hardware available cheaper than ever before its better than it has ever been for this idea but it would still be a compromise that you have to convince your customer they ought to both pay substantially for and accept.
The fact that I can’t remove the battery, and have the phone working when connected to external power makes every single phone (even those with user serviceable battery) garbage.
I don’t know of a single recent phone that works off of external power. Personally, I think this is enough to prohibit sale of a device.
What I expect when a device is connected to power is for it to
1. work off of external power directly
2. charge the battery to an optimal level (possibly 60 to 80 percent?) and STOP charging
I’d have thought this was the default way all electronics works. I know for a fact that my 2006 MacBook just worked if I remove the battery. Same with my random Asus N61JVx2 notebook computer as well.
Why can’t new devices do this?
Laptops are designed to run off battery or power because this is how many people typically use laptops. They plug them in places where they use them for long periods of time whereas phones are virtually always charged for a short period of time often overnight and then carried around and used unplugged virtually all of the time.
I have found the best solution to be to acquire hardware with more than sufficient battery power so as to only worry about charging it every 2-3 days when I'm sleeping. Phones exist with up to 5AH of battery power.
Makes sense but really given how much every company harps about going green... I don’t know whether a lot of people use their phones while charging but I think they do. At least I do.
You brought up a good point though. I should just get a phone with a huge battery. So no pixel and no iPhone.
> 2. charge the battery to an optimal level (possibly 60 to 80 percent?) and STOP charging
Asus Rog phone 3 & 5 actually have this bypass charging, and to restrict charging level(but can only set between 80%-100%).
Claims that Apple is going to blow the rest of the market away usually revolve around
- Careful choice of chips usually involving only apple hardware running less than current generation hardware in thermally constrained situations
- Pretending that AMD doesn't exist
- Pretending that both Intel's slump in progress and Apple's progress are permanent unchangeable trajectories rather than the current status.
- Pretending that we can anticipate a fixed factor improvement over a given time based on changing power envelope. The just add power argument that suggests that future desktop chips will n times faster based on having n times the power and cooling an oversimplification an apple engineer is unlikely to make. You haven't made this one of course you think they will be able to blow away the 1000 watt desktop in 7 Watts. Which is more interesting yet.
- Pretending that a favorable microbenchmark chosen primary because it reflects desired reality rather than applicability proves not only anything about real world performance but everything.
The 2022 iphone still wouldn't make a great computer and the Apple atrix if it were to come to pass would still require you to buy hardware that is liable to be nearly as expensive to make and as bulky as a macbook for a worse experience. Why would a premium buyer want that?
Can you imagine Apple trying to make a laptop with a phone sticking out of it cool? Sliding it into something would be problematic for cooling. The sheer uncoolness is probably even more fatal than the performance.
Slightly related, there's a nice tool called x2x which combines two X displays on different machines, so moving the cursor off the side of one makes it appear on the other (AFAIK it works using a 1-pixel-wide window at the screen edge).
I used this to control my OpenMoko with keyboard and mouse (over SSH), in lieu of an external screen/'dock' like the article shows.
> But since it's just a standard linux distro on the phone, it probably wouldn't be too hard to set up the Librem to automatically pull the latest build from the desktop/laptop for testing purposes.
It's probably easiest to just SSH into the phone as needed, and use scp/rsync/sshfs/etc. to copy things across. If nothing else, it avoids the horrors of having to type commands via a touchscreen.
You can connect a keyboard to the phone as shown in the video. Bluetooth keyboards work too.
GNOME Builder uses Flatpak - when you press "run" button it does full flatpak packaging and runs the resulting package inside a sandbox. Of course you could still run such app natively, directly from the terminal, in which case it would be pretty much instantaneous :)
This isn't a swipe at Rust, per se: if you're using Rust you've probably already decided that build speed and portability aren't as important as memory safety and performance, and I'm sure that's often a valid trade-off.
I do think that "dev builds" should be much faster than release builds, and that means building natively should be default.
Convergence is great for productivity. Ubuntu Touch's main USP was that and I was even able to get it working in UBPorts on my nexus4[1].
It's a shame that convergence is still a hit or miss on android ecosystem, At this point of smartphone compute hardware & USB-C standardization we should be able to plug any smartphone to a monitor. At least Linux smartphone ecosystem is betting high on that.
[1] https://twitter.com/heavyinfo/status/1251048583190609920?s=2...
It was incredible going to school, sitting down at a random monitor and just having all of my vscode files and blender assets follow me around
What Samsung had was a a beta of running a Linux distro in a kind of isolated container on Android.
This also let you boot into Ubuntu 16.04 with external display and use things like VS Code.
Google changed something in their APIs preventing the beta from continuing on newer versions of android.
I don't buy Samsung devices as they indulge in discriminatory behaviour in my country (Pre burned excessive data hoarding bloat apps).
App runs well on Pinephone but building Rust GTK App on Pinephone takes forever. I did it once out of curiosity.
Luckily qemu cross compiling is easy to do on laptop and SCP it to phone, with native Linux SSH and root on phones it is refreshing.
Cannot wait for Librem 5 to get shipped, it's a lot more powerful than Pinephone, but I'm super happy to be experimenting on the future of Linux phones and convergence, regardless of where it ends up going.
Have you tried Lazarus on the Pinephone and the Librem5? It already runs on different ARM boards and apparently it does on the Pinephone too producing fast code.
https://forum.lazarus.freepascal.org/index.php?topic=52217.0
Check also the video on mega.nz linked in that thread.
This approach allows me to ignore of the Android development pain, mostly develop on desktop and just focus on the device for final testing.
Naturally on that case Koltin isn´t part of the story.
What is really neat though is any apps that I develop on my pinephone work on the librem 5 too! Some of the bugs found and fixed on mmsd are from Librem 5 users, and I have been collaborating with the chatty dev (I assume he has a Librem 5, I'm 90% sure he is a Purism employee) with the work I do on the pinephone.
If you order a pinephone today, they estimate they’ll ship it to you in late April.
Also, their “beta phone” is the Nth revision of shipping hardware.
If the phone hardware arrives defective/broken, that's one thing. If the issue is the state of whatever Linux distro you're running (including missing features/applications), that's not their problem.
Mine is from the first batch of 'final' hardware (i.e. the UBPorts CE) for over 6 months and the hardware is solid. The distros (all of them) have come a long way but still have a very long way to go.
Combined with software improvements that will hopefully give a relatively smooth experience.
Then again, the PinePhone is so cheap that it's not a big risk either way.
Online banking 2FA and some other apps sadly tie me to Android.
Although that might change if Anbox works ( https://puri.sm/posts/anbox-on-the-librem-5/ ).
I run FVWM and Firefox on mine and it works very well.
You mention Anbox in another post here. Don’t expect that to allow you to run banking apps on Librem/PinePhone, as banking apps increasingly require the Android phone to pass Safety Net, and Anbox doesn’t.
Source? Even anecdata?
Less apps are required, in lieu of web apps on their websites.
> Less apps are required, in lieu of web apps on their websites.
Some banks require you to install their phone app for 2FA – they have phased out separate code cards or code calculators now that everyone is assumed to carry a mainstream smartphone. So, even if you want to log into their online-banking website, you need an Android or Apple phone in order to authenticate.
I'd never use a service that forced themselves into my device like that.
Still going to recommend them as a best practice! =D
But you said increasingly. I disagree, I'm hearing less bitching about this than ever from people running Graphene or Lineage.
I do not think either the Pinephone nor Librem 5 will have any more significant hardware changes, so the Pinephone/Librem 5 you buy now will be the same one you buy in a year.
If you're unsure, I think buying a Pinephone is a safe bet since its $150 for you to try, and if its not for you, you can probably get your money back by selling it.
What do you want to use it for?
For me, Mobian/Pinephone does everything I need it to do for typical daily usage except for Chatty supporting MMS (and hopefully this will be fixed within a month or so).
If you go with a pinephone get the 3 GB version, as anbox takes up a fair bit of RAM.
This is great. Not having to worry about setting up toolchains on a separate platform, cross-compiling, and then signing/transferring apps and running remote debugging sessions makes it easy to just build and test apps.
My issue with the Apple ecosystem is not the cryptographic protections - it's with the fact that the keys aren't mine.
For the librem it's just like a desktop computer, don't install software from untrusted sources, keep your stuff updated and you should be fine.
They don't do any instrumentation and often the developers themselves don't even understand what all the binary dylibs they're including do.
At any rate my general point still stands I think, it doesn't really matter whether librem apps are signed or not, what matters is where you put your trust. I'm sure some package managers (first party or otherwise) will be able to provide a curated experience if the platform is successful, like what linux distros offer.
Platforms that only run signed code permit that.
Like GNU/Linux repositories?
As for malware installation on Librem, that is a separate question. If you don't give apps root access and only install from the repos, you're about as secure as on Android or iOS. Once you start installing from unknown sources, however, it's true that you're screwed - but that's because of the permission system, not signing.
https://www.techradar.com/news/apple-app-store-is-apparently...
99% sure those comments are correct.
But still, what gets me so hot and bothered is that it looks like purism and pine are making devices that cost almost the same as my other subsidized phone (android) AND might be a viable business EVEN IF there isn't a critical mass.
Linux gets better and better every year even though it will never replace Windows or OSX.
The big deal here is that we might finally have an amazing phone that gives us a complete and awesome developer experience AND respects privacy and the right to tinker fully with our phones.
We've had that on the desktop but NEVER on our phones. This is a sea change that seems worth getting excited about. And it doesn't matter if that doesn't destroy or beat out the alternatives.
This device will never be the marketplace where app developers try to sell my kids shitty apps. Who cares. It doesn't need to be the biggest to be interesting and incredible.
Give it some time. We've had to wait decades to see some people starting the transition from closed desktop systems to open ones, and we aren't nowhere close even to a tenth of the Windows/Mac userbase. Mobile platforms in comparison are newborns, and the industry after learning the PC lesson now is actively fighting against Open Source software and standards by producing software that refuses to run anywhere but their platforms (Whatsapp, banking software, etc) while they spend money to tight close their terminals so they can't be reflashed with Open Source operating systems, a practice that also creates pollution related issues. Time will tell; we probably need at least 5 more years and a couple killer apps that will make a significant number of users move to an open device such as the PinePhone or the Librem 5, or what device will we have by then, so that those figures can't be ignored anymore.
I don't even use my PinePhone as a phone that much... but it's a fantastic mobile computer. I'll continue to use it and be back for the 2nd gen PinePhone.
--A happy pinephone user
Maybe I’m so disappointed because I remember the Nokia N900. Now that was a reasonable Linux smartphone, except for the blobs.
This is a fault of the Signal developer, not of the Pinephone.
> takes 5–10 seconds just to open the screen to turn wi-fi on/off on Mobian
It's the beta release. It's gonna be faster with GPU acceleration AFAIK.
> Maybe I’m so disappointed because I remember the Nokia N900. Now that was a reasonable Linux smartphone, except for the blobs.
But how much time passed after the release until it became a reasonable smartphone? Give Pinephone some time.
Whoever’s fault it is, is immaterial. The PinePhone is still lacking as a phone for at least those who use Signal.
> It's the beta release. It's gonna be faster with GPU acceleration AFAIK.
Can you cite that? The problem is that Mobian's stack is based on a lot of GNOME libs that have not been optimized very much and run slow even on desktop, so GPU acceleration won’t help much. Before you mention the other available OSes on the PinePhone, UBports is obsolete, bitrotting tech.
> how much time passed after the release until it became a reasonable smartphone?
The N900 was a reasonable smartphone immediately upon its release, at least in terms of being responsive and having core apps and functionality that people expected at the time. Nokia had a larger team of developers working on Maemo than there are working on PinePhone OSes.
You can run it in Anbox.
> Can you cite that?
Anbox is not considered a reasonable standard solution for running anything on the PinePhone due to its resource requirements. Also, that citation you give supports my claim above.
I understand that you are running a single-issue advocacy account here on HN, but over the last several weeks you have been really embarrassing your own cause with these attempts to sweep major flaws under the carpet. Yes, the PinePhone may offer the prospect of someday being a reasonable libre phone alternative (assuming it isn’t a stillborn project, as I fear), but you keep painting a rosier picture of it now than is warranted.
Otherwise you are right and Pinephone is too slow for such things. But, again, this is a fault of Moxie and imo effectively shows that Signal is not free software (no freedom to run).
No it won't. A (the?) big problem with performance is that we're running desktop applications on a slow-ish mobile device. (all of it: slow CPU, slow GPU, slow RAM, slow flash etc.) To get a good experience you need to throw more (i.e. faster) hardware at it and re-architect and strip down key applications. Or write new ones from the ground up designed for mobile devices and the resource limitations that come with them.
The 'beta' label is an attempt to set expectations re: the state of the distros right now. When they change the label to 'final' people are still going to be complaining about performance.
I get your frustrations and as a PinePhone owner myself I would not consider it anywhere near usable as a real Smartphone replacement.
However after installing Arch it is pretty snappy and has certainly sparked some new hope in me. I really recommend you to check it out.
For Signal there is (or will be) Axolotl [-1] which looks promising and when it comes to developer support both KDE and GNOME devs show some support for it. E.g. GNOME recently announced libadwaita [0]. Give it some time and check out the Arch release for PinePhone: [1].
[-1]: https://github.com/nanu-c/axolotl
[0]: https://aplazas.pages.gitlab.gnome.org/blog/blog/2021/03/31/...
All people like me want is something that lets us run tmux and the rest of the apps we run on our thinkpads and the Pinephone does that very well.
I've tried pmOS a few times. I really like pmOS and they have a great community (I'm more active in the pmOS Matrix channel vs the Mobian channel), but unfortunately relying on muslc vs glibc can be a bit of a pain (mmsd has some sort of incompatibility due to this), and muslc precludes a lot of packages mobian has without manual patching.
If I may ask, I tried using SXMO a couple of times, but I never got used to it. Do I just need to stick with it for a little bit and it gets better, or what are your thoughts?
It’s hardly fair to blame pine for gtk issues when they’re shipping kde by default. I can install non-working software (even broken android) on any jailbreakable phone.
You say that as though it was an achievement.
Most smartwatches can be programmed. The pinetime is about the hardest one to develop for, with the least available resources.
I am not aware of any other smartwatches where you can reflash the OS.
Why doesn’t Google make an on-device Android studio?
I mean the first versions are of course not of the best quality. But in maybe 5 years, it would have be an universal feature.
Alas. They discontinued the project.
Also, I have a couple of simple containerized apps that I run on my home network. Would I have any trouble running these on a Pinephone? Would love to hear from anyone with experience.
No.
Don't get me wrong, I really like the device but it needs a few more years to be easy to use and maybe a new hardware revision to get better performance. I get about 9 hours standby time (wifi on, modem off), at least the screen on time is pretty good.
Google makes secure hardware!
1) ssh -X in to PinePhone over usb
2) start Emacs on my desktop's X desktop
3) code it up in Tcl/Tk
4) for testing, set DISPLAY=:0 and run the script
5) Profit from rapid, iterative development right on the device!
This should cover it nicely: https://grapheneos.org/faq#future-devices
See how easy that was?
Oh, and telling people not to read resources and decide for themselves is questionable behavior.
Doing it without being up front about who you are just makes it rude.
IOMMU is vital for devices where e.g. modem is tightly integrated on the SoC and uses the same RAM as your OS. This is not such device. Even if iMX8MQ had an IOMMU, the modem would still be connected to the SoC via USB2.0 and the WiFi card via SDIO, where you don't need an IOMMU to ensure boundaries and where having one wouldn't change anything at all.
For example, full disk encryption seems to be coming up: https://puri.sm/posts/sneak-peek-of-the-next-pureos-release-...
0) https://www.theverge.com/2019/11/26/20983886/microsoft-outlo...
1) https://www.windowslatest.com/2021/04/11/windows-10-taskbar-...
2) https://www.xda-developers.com/microsoft-clears-air-recent-o...
Hkw about we figure out which apps are missing and build them natively. Linux phones still need work to be opimized for the hardware, lets not add more abstractions and slow it down by emulating proprietary runtimes
Folks: if you don't like two major tech giants having so much power, push back against requiring apps like that when you see it. This is how they get so much power. (I'm especially worried about government apps requiring Android with Play Services or iOS.)
One example could be like a banking app.
One that really annoyed me was my school forced Duo Mobile on us. Duo Mobile uses HOTP, but they do not officially support third party 2FA.
I was lucky some folks already reverse engineered the protocol so I could use a third party 2FA app.
Android already has a complete set of phone-ready apps available.
> Why not iOS and Windows apps too??
We already have Wine for running Windows apps.
Yeah, that'd be great! Unfortunately Darling isn't running GUI apps yet even for desktop apps, but the start is there. Windows apps are frequently compiled for x86, so we'd need to plug together WINE+qemu, but it should work. Windows apps also aren't designed for mobile like Android, but in many cases I'd bet it can be made to work.
But much more secure.
Besides Python there’s C, C++, Java, Go, Rust and and ... anything that has toolkit bindings basically. I plan to add the main programming languages per app in a future revision of the list.
At least 8GB RAM for all this stuff to remain in memory. Fat Python processes collecting GPS and mobile connectivity data (like RSSI, which cell towers are nearby), storing this in a MongoDB instance on the device, collecting accelerometer data and processing+storing it, there's a lot I'd like to do.
Perhaps the next Librem 5 batch "Fir" will have more RAM: https://source.puri.sm/Librem5/community-wiki/-/wikis/Freque... (and you can preorder it now).
> was
> ran
Let's hope the pinephone2 will fix all that!
I can see a future where Unix/Linux machines take the pro-device market.
https://gitlab.gnome.org/GNOME/gjs/-/blob/master/doc/Home.md