Making Librem 5 Apps [video](puri.sm)
puri.sm
Making Librem 5 Apps [video]
https://puri.sm/posts/the-simplicity-of-making-librem-5-apps/
265 コメント
So, effectively—your phone is your computer? This is awesome. This is what general purpose computing was meant to be.
Marketing caused us to regress to the fragmented landscape of gimmicky special purpose devices that we have today.
Marketing caused us to regress to the fragmented landscape of gimmicky special purpose devices that we have today.
On recent droids this works surprisingly well. I have a keyboard in my bag instead of my laptop now.
The issue of display is the only thing that keeps me dragging a laptop around. I've been keeping an eye on monitor replacement AR glasses but looks like I'll be waiting another decade or so for anything consumer ready.
I have an ASUS Zenscreen MB16A. It's very portable, has a battery, touchscreen, speakers, input from either micro HDMI or USB C. The only disadvantage is that the battery will only last a few hours unless you have it plugged into usb-c charger, and I haven't worked out a way of charging it and giving it a usb-c signal at the same time yet (so when I'm using it at my desk I use the micro HDMI input).
I sort of agree. It wasn't marketing it was the failure of regulators to enforce the same sort of regulations they used against Microsoft to stop apple et al from becoming monstrous entities in the back of policies that stifle innovation and limit choice.
> I figure in a year or two it will let normal folks happily run their lives ios/android-free.
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 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.
> 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.
F-Droid and GNU/Linux repositories work flawlessly without any ads and, moreover, have much less malware, if at all.
F-Droid and GNU/Linux repositories work flawlessly without any ads and, moreover, have much less malware, if at all.
> 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.
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.
You’re a curmudgeon, Linux phones don’t need the success of Apple and Google to survive. As Purism is demonstrating, the work just needs to be done and open sourced. People who prefer Apple and Google phones can remain in that ecosystem just as people who would like to live outside of it in their personal PCs can today. You will see a schism in the market. It may not be dramatic enough to “cause disruption” but it’s enough of a market to sustain as Pine64 and Purism and System 76 and many others have proven. People want Linux devices.
You don't know whether people want to be challenged or not. Not everyone wants to be challenged at everything. You can be good at something and still both suck and not have any interest in other things. Brilliant programmers might have no idea how to cook anything. Brilliant doctors buy iPhones for the convenience because they have zero mental attention left to focus on things like tinkering with technology even at the slightest. Of course many people don't want to be "challenged" at all, but MOST have something that challenges them constantly, and I would say - a very important aspect you seem to neglect - the majority of people on earth, perhaps even in "developed" nations, have their hands full trying to survive and barely making ends meet, with no energy to spare on other less urgent matters.
> 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.
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.
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.
> I'm not sure that using a phone that exposes a full Linux system is the answer here
or the full list of vulns in the Linux kernel, for that matter.
or the full list of vulns in the Linux kernel, for that matter.
Of course, you're right.
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
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
> - 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?
https://www.hackers-game.com/2020/09/08/robocalls-fight-bots...
https://www.hackers-game.com/2020/09/08/robocalls-fight-bots...
aha, maybe it will happen sooner, not later!
I like the cut of your jib, friend.
A lot of things you're espousing, I'd like to see.
A lot of things you're espousing, I'd like to see.
> Most people are honestly pretty lazy and the sad simple fact is that they do not want to be challenged at all ever.
I (fellow curmudgeon perhaps) totally agree
I (fellow curmudgeon perhaps) totally agree
OR
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.
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.
Okay there's about a dozen reasons Librem 5 will never be more than a fun developer's toy. Here's just a few.
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?
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?
> ) It's difficult to use as a daily driver even for experienced people. It's impossible for the average person.
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.
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.
For a second, I thought, "Man is it really that slow to compile a hello-world Python GTK app?" I completely forgot he was doing this all on a phone.
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'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'm super impressed with the state of "convergence" here.
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...
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 is quite ridiculous. as a passionate Samsung DeX defender at first, I dove right into that ecosystem when the s8 came out and am now at a point where my s10 is never getting a software update BECAUSE ANDROID BROKE THE API FOR SAMSUNGS WSL. Termux was a victim too to a much lesser degree but Samsung had literally had Linux on Dex beta and I was absolutely free to just have my phone.
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
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 a shame, I thought at least Samsung have their DeX albeit with special hardware. So no more DeX? I presume some new Android phones at least support mirroring through USB-C.
No DeX still exists.
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.
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.
Perhaps because they removed exec() from userspace for apps targeting API 29 in Playstore.
I don't buy Samsung devices as they indulge in discriminatory behaviour in my country (Pre burned excessive data hoarding bloat apps).
I don't buy Samsung devices as they indulge in discriminatory behaviour in my country (Pre burned excessive data hoarding bloat apps).
> "Man is it really that slow to compile a hello-world Python GTK app?"
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 :)
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 :)
Now that a lot of GTK mindshare seems to be moving towards gtk-rs, I have a feeling that it's about to get a lot less 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.
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.
I believe this is actively being worked on; there's a compiler backend being built using Cranelift instead of LLVM that will supposedly improve debug built times by a fair amount, and then the full release builds will switch over to the LLVM-optimized version. Last I saw, the improvement between the existing rustc and Cranelift-based one was something like 15%, but that may have changed in the interim.
It is still way slower than using C++ with gtkmm.
Indeed - however, I'm usually compiling things straight on the phone, it's not that slow. Rust can be challenging in this regard, but works acceptably well once you get dependency crates already compiled (which can require adding some swap, unfortunately).
I've been making a hobby app with GTK Rust in GNOME Builder for Pinephone and eventually Librem 5.
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.
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.
> App runs well on Pinephone but building Rust GTK App on Pinephone takes forever.
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.
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.
Thanks for suggestion, haven't tried it before but I'll check it out.
Is it publicly available? If so, may I list it on https://LINMOBapps.frama.io?
Once I get at least close to an MVP I'll get in touch!
It's an exciting idea that as phones get more powerful, plugging the phone into a monitor could replace the desktop entirely for many home users.
> Dragging a window over from a full desktop monitor to the phone was exciting to watch.
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.
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.
> 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.
You can connect a keyboard to the phone as shown in the video. Bluetooth keyboards work too.
Now imagine an Android developer who wants to buy a new laptop and thinks they should be able to live with 4GBs of RAM for normal non-heavy usage. Then they remember they might want to use Android Studio as well. Then sky is the limit when it comes to RAM at least.
Android Studio is basically a space heater that accidentally produces an app now and then.
Java development is part of the stuff I do, on a laptop that doesn't have any issues dealing with VS, Netbeans or Eclipse, I can complety forget to even attempt to use Android Studio.
It's more doable from this standpoint to use IntelliJ to build Android apps, but not as straightforward (and from what I've experienced can be a source of conflict when some team members still use Android Studio).
Or just use VS Code alongside NDK, Flutter, Xamarin, Qt, their respecitive IDEs and Android CLI SDK.
I'm using a 4 years old laptop with 4GB as my main machine. As much as I want to develop Android apps, there's no way for me to do it with Android Studio. The IDE itself would consume much of the memory with glaring input lags, and there's gradle. The tooling isn't there outside the IDE. Kotlin-language-server and ktlint sadly isn't enough. I really wish android dev is more accessible.
Most of my Android development is either mobile Web, or NDK stuff.
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.
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.
yawnn.. ubuntu touch had convergence 5 yeas ago, nobody cared
Bullshit, respectfully.
Convergence has been held back by UX and UX alone.
It's the single most-requested feature at my bespoke secure technology firm.
Convergence has been held back by UX and UX alone.
It's the single most-requested feature at my bespoke secure technology firm.
> 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?
I'm curious now, is your firm going to order a bunch of Librem 5 phones?
No. Their security model does not meet the baseline security needs of our clients.
Would you mind elaborating on that? My understanding is from a verification point of view, the Librem 5 is functionally at the absolute top-tier in terms of OpSec concerns, with everything from the bootloader up being open and customized, full disk encryption available, and the only binary blobs (I think on the modem?) being completely sandboxed. Are there additional concerns, and what kind of solutions do they currently use that do meet those needs?
You can even set up a secure boot chain with your own encryption keys, see: https://boundarydevices.com/high-assurance-boot-hab-i-mx8m-e... (it's a tutorial for a board that uses SoC from the same family as the Librem 5)
The Librem 5 is not as open or libre as its marketing has tried to insinuate, simply having its binary blob signed and validated firmware saved in write-protected read-only memory and loaded by a secondary coprocessor to exploit a loophole in the definiton of "libre" hardware to allow it to qualify for the FSF's definiton of "Free" hardware. This renders the firmware unupdateable without shorting a connection. In the event a vulnerability is discovered in the modems or radios, the firmware cannot be updated without physically dismantling the phone. 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. 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.
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!
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!
> In the event a vulnerability is discovered in the modems or radios, the firmware cannot be updated without physically dismantling the phone.
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?
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?
> But wouldn't it make the phone more secure, since no malware can update the firmware without your knowledge?
No not really. Look up the boot ROM vulnerability on the Nintendo Switch. I'm sure Nintendo wishes they could update that.
No not really. Look up the boot ROM vulnerability on the Nintendo Switch. I'm sure Nintendo wishes they could update that.
I am not saying that total lack of updates is more secure. I am saying that special actions required for the update can make it more secure.
Ahh gotcha, that makes sense!
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.
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.
Chromebooks have this!
Some seriously forward thinking shit.
Some seriously forward thinking shit.
That's a massively inaccurate comment.
> 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 ;)
> 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 ;)
Is this person a Graphene OS dev?
I couldn't confirm that (from a cursory search), but if so, this massively undermines my confidence in using it on my Pixel.
I couldn't confirm that (from a cursory search), but if so, this massively undermines my confidence in using it on my Pixel.
The person who wrote the comment I replied to? I don't think so, they just copy'n'pasted and linked to a page written by a GrapheneOS dev. However, I have some history of communication with GOS devs on Twitter trying to correct their mistakes and they always confidently repeat their misconceptions despite of clearly not knowing what they're talking about and it ends up with "I'm not lying, you're lying" and me getting blocked, so...
(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 ;))
Gotcha.
> (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.
> (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.
LineageOS breaks the AOSP security model.
I wouldn't recommend this to anyone as a first choice.
I wouldn't recommend this to anyone as a first choice.
Not a dev, just a somewhat active community member — would be interested which dev you spoke to, and on what inaccuracy!
First time was with someone behind the official GrapheneOS twitter account, and second time was with Daniel Micay, both times about the hardware supposedly preventing the ability to update the firmware even when running alternative software.
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.
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.
Thanks for the info, I hadn't heard about the USB isolation architecture issue.
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'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?
Considering most of his other post is factually incorrect and/or out of date, I am skeptical of the claim to be frank.
Are you skeptical about bad security of USB? Here you go: https://www.qubes-os.org/doc/device-handling-security/#usb-s....
I'm skeptical of that person's claims, primarily because the document the individual sourced as "fact" was riddled with factual errors. I don't know enough about USB security to make a judgement one way or another.
Thank you for this source, I'll check it out!
Thank you for this source, I'll check it out!
So in reading that overview, the same attacks that would apply to USB apply PCIe:
> 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.
> 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.
> because the document the individual sourced as "fact" was riddled with factual errors.
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.
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.
"You're wrong!"
I can play that game, too!
I can play that game, too!
Skeptical != wrong
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.
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.
>The Librem 5 does not even support software encryption and no progress has been made toward adding even LUKS encryption.
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?
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?
Anyway, to actually answer your question, if you need a source that the Librem doesn't have an IOMMU, then frankly you're out of your depth for this conversation.
...are you going to address, you know, the rest of your comment being factually incorrect?
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.
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.
> ...are you going to address, you know, the rest of your comment being factually incorrect?
Just have elsewhere.
Just have elsewhere.
considering doing ctrl + f "atat7024" proves otherwise, you are simply not worth replying to anymore, seeing as how you cannot conduct basic research or you are willing spreading misinformation.
tl;dr No, I literally said it was from a URL, and provided it...and I'm supposed to trust your info?
The way you cited this URL indicated you believe it to be fact.
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!
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!
Actually you can customize the OS as you wish on this phone. Perhaps it's a big task though.
In theory this makes tons of sense but despite microbenchmarks your expensive phone is still a kind of mediocre little computer and for optimal usage needs more ports a display, keyboard, pointing device, and battery.
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.
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.
Not true in the Apple ecosystem. The Apple Silicon chips in recent iPhones can trounce desktop chips from a few years ago, and the next-gen iPhone should rival a high-spec desktop from today.
A high spec desktop from today has 32 3.7Ghz cores that 1 to 1 spank apple silicons 4 fast cores 32GB - 1TB of RAM and GBps of access up to TBs of storage or slower access to 10s of TB. It can use 1000W if need be and active cooling.
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.
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.
Sorry if it sounds like I’m moving the goalpost but no. Apple, Android doesn’t matter. They are all trash.
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?
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?
FWIW, the Librem 5 can fully work with no battery (including the cellular modem and WiFi, which often don't work with no battery on other phones) as long as it's connected to a powerful enough USB-PD power source. You can also reconfigure the battery charger directly via its I2C interface: https://www.ti.com/lit/ds/symlink/bq25895.pdf
I believe the reason is typically because they want to make the design of chargers cheaper and the circuitry inside simpler and ergo cheaper as well. What you want has a slightly higher unit cost and in 99.99% of cases doesn't impact the users usage.
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.
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.
> I believe the reason is typically because they want to make the design of chargers cheaper and the circuitry inside simpler and ergo cheaper as well. What you want has a slightly higher unit cost and in 99.99% of cases doesn't impact the users usage.
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.
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.
> 1. work off of external power directly
> 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%).
> 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%).
The USB-C port doesn't provide enough power for the Wi-Fi radio to work, but ethernet (via USB-C hub) would work fine. Excluding that (major) use-case, the Pinephone works just fine using external power instead of the battery. Hell, for that matter, I'm tempted to find out if an external Wi-Fi dongle would work...
The cellular modem also doesn't work without battery on the PinePhone (it does on the Librem 5 though). It's not a matter of providing enough power - on the PinePhone (and many other phones as well) those things are powered straight from the battery, because to make it work otherwise you have to provide enough capacitance to handle big power spikes (which the Librem 5 does, as it's not meant to optimize for low price or thickness).
Is it an OS thing or a hardware thing? I like the idea of using something like postmarketOS to repurpose an old smartphone, but I agree for long term use the battery might not be a good idea (especially if the hardware tries to keep it at 100%).
I have now fried two different phone batteries trying this: basically I wanted to set up old phones as time lapse photo capture using open camera but the battery swells up and becomes a fire hazard in a few weeks/months.
Old phones seem like a really nice cheap high quality camera shame it doesn't work. Have you tried setting up something like a single board computer + usb cam?
No, so far I've only tried what hardware I already have like an old Nexus 4 phone with a cracked back.
Respectfully, ubuntu touch is a terrible OS. When people ask for convergence on a phone they want a normal desktop Linux OS not an Android knockoff that can run some X11 apps.
and Motorola Atrix 4G sortof had that 10 years ago: https://en.wikipedia.org/wiki/Motorola_Atrix_4G#Webtop
This is not the same at all. Librem 5 runs desktop apps on a phone, not making mobile apps run on a big screen.
I've been doing that for about 12 years using https://en.wikipedia.org/wiki/Openmoko
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 :)
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 :)
GTA01 and GTA02 had no way to connect external screen though, and even if they had it it wouldn't be pleasant at all - Glamo was even too weak to drive the internal VGA screen :) But yeah - I'm working on the Librem 5 now, but I remember making my first steps in Python on the Openmoko Neo Freerunner back in 2008 while starting to contribute to SHR and it still has a special place in my heart!
[deleted]
This is also true of the pinephone. My entire dev set up for for the pinephone is on my pinephone. All I do is hook up a USB cable and SSH into it (which makes testing a lot easier since mmsd needs to talk to the modem).
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.
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.
I am looking to purchase either (or both) of those phones. Would you recommend buying one of them now or waiting until a future release? It seems that both companies have extended the release dates a bit.
I would say "Yes", but I also have two Pinephones and have a Librem 5 order in the queue. One pinephone is my "dev" phone (since mmsd tinkers with core mobile networking stuff, I don't want developing to interfere with my normal usage).
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).
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).
I care most about 2 android 9 apps I have that run in the background and use Bluetooth. Other than that sometimes I like to tinker and build small projects with the libraries available but am more concerned with the android 9 apps. Other primary usages are phone, text, and browsing.
In that case I would say either are stable enough for you to use. If you want something sooner than later I would get a Pinephone.
If you go with a pinephone get the 3 GB version, as anbox takes up a fair bit of RAM.
If you go with a pinephone get the 3 GB version, as anbox takes up a fair bit of RAM.
The version of the librem 5 that is shipping now is the "evergreen" model. Their next model is going to be named "fir" which is supposed to have a 14nm CPU[1] as opposed to the 28nm CPU in the evergreen model. This should mean better battery life, so if that is something that interests you then you might want to wait on the librem 5. Personally, I don't want to wait that long so I'm getting evergreen.
[1] https://puri.sm/posts/librem-5-shipping-announcement/
[1] https://puri.sm/posts/librem-5-shipping-announcement/
CPU is probably not going to be the only change for Fir: https://source.puri.sm/Librem5/community-wiki/-/wikis/Freque....
Not seeing anything new in that post. CPU is still the only confirmed change, and they go through the implications of the device using the i.MX 8M Plus.
It's not even confirmed that it's going to use the i.MX 8M Plus. The initial Fir "announcement" assumed a quite different reality where all Evergreens would have been shipped long time ago.
I'm personally waiting for the next PinePhone iteration with a better chipset, since the CPU is pretty slow for even budget phone standards.
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.
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.
Don’t hold your breath on the next PinePhone iteration. On the forums, people expect a new hardware generation to come in only 3–5 years from now. Pine64 seems to assume that the hardware is fine for now, it is only the software that hasn’t been developed and optimized enough.
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.
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.
> increasingly
Source? Even anecdata?
Less apps are required, in lieu of web apps on their websites.
Source? Even anecdata?
Less apps are required, in lieu of web apps on their websites.
If you want anecdotes, look at the LineageOS forums where people complain frequently that passing Safety Net on unGoogled phones is no longer possible even with the old workarounds, so now their bank apps won't work.
> 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.
> 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.
Also, I know these problems exist.
But you said increasingly. I disagree, I'm hearing less bitching about this than ever from people running Graphene or Lineage.
But you said increasingly. I disagree, I'm hearing less bitching about this than ever from people running Graphene or Lineage.
Switching banks is pretty trivial.
I'd never use a service that forced themselves into my device like that.
I'd never use a service that forced themselves into my device like that.
Not everywhere has a diversity of banks to choose from like e.g the US. Some countries are reduced to an oligopoly or even duopoly where the banks don't differ in terms of their expectation that you will use their iPhone or Android app.
Y'all probably struggle to get wild blueberries from Maine, too.
Still going to recommend them as a best practice! =D
Still going to recommend them as a best practice! =D
You can't compare performance on the pinephone to Android phones because the OSes and app ecosystems are completely different: You just run Linux desktop environments and apps that are designed to run without hardware acceleration.
I run FVWM and Firefox on mine and it works very well.
I run FVWM and Firefox on mine and it works very well.
FVWM sounds interesting. Would you like to share details of your setup? If so, I would like to interview you for my blog https://linmob.net!
And why wouldn't you order Librem 5 now?
The Librem 5 is a bit more than I'd want to spend on an alternate device.
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/ ).
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 have 3 android 9 apps that are important to me. Running those would allow me to switch forever. I went to the anbox site briefly but didn’t quite see a list of images.
If you order Librem 5 right now, you get it "in a few months", so the software will be much more mature (while hardware already is). Pine64 currently accepts preorders only for the "Beta-version" of Pinephone.
I see. It seems as though the price tag has gone up compared to the dev versions. With that price I imagine they’d want things to be stable. I haven’t looked to see if they have a vcs or chats to see what types of issues are being addressed.
Pinephone’s “Preorder” is mostly just to scare off people that want the software to work, from what I can tell.
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 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.
Pretty much. They really don't want regular consumers to be buying the PinePhone from them. They've been very upfront about this: the phone isn't priced for, and they aren't equipped to provide end user technical support. It's priced to get it in the hands of people willing to take some pain and help with the work of getting Linux where it needs to be on mobile.
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.
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.
The key takeaway to me is that developing mobile apps for the Librem 5 on the Librem 5 is a first class development workflow.
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.
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.
[deleted]
Can anyone explain to me the benefits of staying native, and not switching everything to web apps that use properly implemented web APIs for everything?
No signing also means that the workflow for developing malware for the platform is exactly the same, too. :)
My issue with the Apple ecosystem is not the cryptographic protections - it's with the fact that the keys aren't mine.
My issue with the Apple ecosystem is not the cryptographic protections - it's with the fact that the keys aren't mine.
I'm not sure I understand. Crypto won't protect you from malware by itself, it just creates a chain of custody. App store apps are not secure because they're signed, they're secure because they're signed by Apple.
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.
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.
Meh, signing by Apple really doesn't mean more than Apple looked (visually) at a running instance of the app and said "eh it doesn't look like it's breaking the rules."
They don't do any instrumentation and often the developers themselves don't even understand what all the binary dylibs they're including do.
They don't do any instrumentation and often the developers themselves don't even understand what all the binary dylibs they're including do.
I don't own an Apple device myself but don't they have a pretty good track record when it comes to the security of their apps? Plus all the guidelines they've been enforcing lately when it comes to user tracking etc...
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.
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.
The real reason iPhone apps are safe is because they run in a controlled sandbox with a very limited set of device APIs available to them. You could take away the app store and signing and things would mostly be the same.
Being able to outsource the decision about what is or isn't an "untrusted source" to a security expert is valuable.
Platforms that only run signed code permit that.
Platforms that only run signed code permit that.
> Platforms that only run signed code permit that.
Like GNU/Linux repositories?
Like GNU/Linux repositories?
No, those only distribute signed code. If unsigned code makes its way on to your system outside of those repositories, your GNU/Linux system will happily execute it, unsandboxed save for outdated POSIX uid/gid permissions.
Platforms that don't run only sign code also permit that.
You're mixing developing and distribution. You don't need any (meaningful) signing to develop for Android and not even for iOS (although testing is harder there). App signing comes in only when end-users are installing your apps.
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.
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.
I don't understand this line of thinking. There is loads of malware in the Apple Appstore.
https://www.techradar.com/news/apple-app-store-is-apparently...
https://www.techradar.com/news/apple-app-store-is-apparently...
there are tons of apps on iOS and Android app stores that are malware and they are signed
I'm reading a lot of the comments here and it seems the salient argument is that this will never replace Android or iOS because this or that.
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.
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.
> We've had that on the desktop but NEVER on our phones.
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.
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.
This phone and developer experience looks like it is ready now. My point is that we don't have to use a terrible developer experience to work on an open system now and we don't need to have it be a massive economic success either. This is what we've been waiting for and it's ready to hack on.
That's the right attitude, IMO. Most consumers respond to polish and 'wow!' factor. The Linux desktop doesn't even provide that compared to the competition... Linux on mobile is even further behind both from a hardware and software standpoint. For those who don't care, or are at least willing to overlook the limitations, Linux phones are becoming increasingly viable and provide a number of advantages that the average consumer doesn't value. But there are those who do so there is a market for them.
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.
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.
I'm a little annoyed it took this long to get reasonable smartphones, but I'm so glad they're finally here.
--A happy pinephone user
--A happy pinephone user
You are happy with a phone that won't run an authorized Signal app, takes 5–10 seconds just to open the screen to turn wi-fi on/off on Mobian, and whose map apps are all barebones tech demos compared to OSMAnd on Android? I have a PinePhone too and occasionally hack on it, but I wouldn’t call it a "reasonable" smartphone yet when the software is still so half-baked and, unfortunately, it hasn’t succeeded in attracting very much of a dev community (as the existing devs sometimes complain).
Maybe I’m so disappointed because I remember the Nokia N900. Now that was a reasonable Linux smartphone, except for the blobs.
Maybe I’m so disappointed because I remember the Nokia N900. Now that was a reasonable Linux smartphone, except for the blobs.
> phone that won't run an authorized Signal app
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.
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.
> It's the beta release. It's gonna be faster with GPU acceleration AFAIK.
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.
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.
> This is a fault of the Signal developer, not of the Pinephone.
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.
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.
> Whoever’s fault it is, is immaterial. The PinePhone is still lacking as a phone for at least those who use Signal.
You can run it in Anbox.
> Can you cite that?
https://news.ycombinator.com/item?id=26569666
You can run it in Anbox.
> Can you cite that?
https://news.ycombinator.com/item?id=26569666
> You can run it in Anbox.
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.
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.
You are right that I advocate for the GNU/Linux phones. However I advocate for Librem 5 more, and it should be performant enough for most use cases, including Signal in Anbox.
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).
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).
I mean its two different things: Nokia a mega corp (at the time) and Pine64 (a few hardware enthusiasts + small overworked dev community).
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/...
[1]: https://github.com/dreemurrs-embedded/Pine64-Arch
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/...
[1]: https://github.com/dreemurrs-embedded/Pine64-Arch
> mobian
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.
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.
Phosh gets way too much attention on the pinephone, it's not a good DE and it's very slow. You can run normal Linux X11 DEs with no compositing and they are very fast. I use FVWM and most things open very quickly, Firefox takes a couple seconds.
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.
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.
It's not the DE that makes things fast or slow (although disabling composition may indeed help with making GTK3 apps run faster on the PinePhone, but that's mostly because GTK3 renders in software and it bottlenecks on PinePhone's RAM bandwidth).
Out of curiousity, what distro are you running?
I guess it's SXMo.
That was my guess too. I've tried SXMO a couple of times but ended up going back to Phosh. Its probably me, but I could not figure out the UI of it.
I actually like SXMo very much and I wish I could choose it sometimes during the booting. I don't use it daily only because it relies on postmarketOS and not Debian.
I understand that.
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.
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.
Honestly, I have no idea why I'm so surprised. This is what happens when you put desktop dev tools on an (albeit modified) desktop desktop environment on an (albeit modified) desktop operating system on a phone. Can't wait for these devices to mature!
My phone has been at compute parity with my i5 Macbook air for at least the last two phones I've had. I've also been able to plug my phone in to a monitor/keyboard using the same usb-c dock I use for the air and be pretty productive in a pinch. Love the idea of having a real desktop environment instead of Android, though.
It's only a matter of time until we can develop smartwatch apps - on our smartwatch.
Why would you post that when it clearly can’t be programmed on device?
It shows the path to that. At least it can be programmed.
> At least it can be programmed.
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.
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.
> Most smartwatches can be programmed.
I am not aware of any other smartwatches where you can reflash the OS.
I am not aware of any other smartwatches where you can reflash the OS.
I’m not aware of any other smartwatches where you have to.
Look at Bangle JS, it has JS interpreter on it. There is no IDE on it, but I don't see it impossible that one connects a Bluetooth keyboard and opens up the console on it.
Check out:
https://asteroidos.org/
More of this, is exactly the competition Apple needs.
Why doesn’t Google make an on-device Android studio?
Why doesn’t Google make an on-device Android studio?
Samsung Galaxy used to have something like this that was in the right direction, but I don’t know if they ever did anything with it.
linux on dex? I seriously dont know why they pulled it off? I mean if they had put some effort into the whole thing, laptops would be a thing of the past. Plug your (13gb ram, 512 gb storage & powerful arm cpu) mobile to just about any display device with a keyboard and boom! You have a laptop. It was on Samsung Galaxy Note.
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.
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.
How does the write endurance of phone-grade flash memory compare with that of desktop SSDs?
This is quite impressive. I've always found the iOS development experience very smooth, but after seeing this I'm not sure about that anymore.
And of course the same goes for the PinePhone (albeit slower).
I especially like that you can choose different languages for development although this is not a Librem/PinePhone feature of course.
My dad is very suspicious of Google and concerned about privacy on his Android phone. Is there a Linux phone that's polished enough for the non-savvy user?
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.
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.
>> Is there a Linux phone that's polished enough for the non-savvy user?
No.
No.
As an owner of an Librem 5 I have to agree.
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.
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.
He could try running /e/ OS, which is a fully functional Android fork, with as much Google home-phoning removed as they could.
Sounds like an iPhone would be suitable then.
You could disable Google, etc., related apps via ADB and block internet access for applications with Netguard or something. I blacklist all by default and allow only those I need. Makes for improved security.
Just have him read GrapheneOS.org, look up terms, and ask questions in the chat room until he wants a Pixel, non ironically.
Google makes secure hardware!
Google makes secure hardware!
Imagine my excitement when I realized I could quickly develop apps for my PinePhone, on my PinePhone.
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!
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!
That's it. I'm ordering a Librem 5!
Just be aware of the long and untransparent waiting queue; afaik orders from 2017 backers are still being processed.
Why not wait until they have a stomachable security model?
Me being in control of my own encryption keys seems like a more stomachable security model than letting Google or Apple profile me based on every single thing that happens on my device. What would you like to see in Librem's security model?
> What would you like to see in Librem's security model?
This should cover it nicely: https://grapheneos.org/faq#future-devices
This should cover it nicely: https://grapheneos.org/faq#future-devices
Don't waste time reading that, it's mostly wrong: https://news.ycombinator.com/item?id=26778281
Disclaimer: above commenter is with Purism.
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.
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.
I will tell people to not read resources that state blatantly incorrect information as facts and don't even bother to cite where they got that information from, especially when the actual facts can be easily checked by anyone since all the information about how those firmwares work have been publicly available for many months now and the phone is already in hands of many users who can check it themselves on actual devices. It's not a matter of opinion or interpretation where my affiliation could actually make a difference, that post is just demonstrably false and not worth anyone's time (and if anything, the fact that I work for Purism on the Librem 5 makes my position stronger, because I know how these phones work).
A bibliography isn't going to find the Librem an IOMMU.
...and what benefit would exactly an IOMMU bring to a device with no PCIe and which's critical peripherals do not use DMA at all?
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.
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.
Do you think that hardware changes are needed for that? If it is only a matter of software, then buying now will not hurt.
For example, full disk encryption seems to be coming up: https://puri.sm/posts/sneak-peek-of-the-next-pureos-release-...
For example, full disk encryption seems to be coming up: https://puri.sm/posts/sneak-peek-of-the-next-pureos-release-...
See sibling comment!
Let me know how much it costed you, all in all, not just the price on their site. Also when you'll get it on your hands, physically, not what they say initially on the delivery note.
[deleted]
What about web app support on Librem 5? Is it possible to add web apps to homescreen? App development using web technologies might be more accessible for developers.
According to Microsoft's actions, PWA (progressive web apps) are "officially" first class citizens:
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...
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...
Yes, it supports web apps: https://puri.sm/posts/librem-5-web-apps/.
How easy would it be to build anbox, so you could run Android apps?
It already works for many apps: https://puri.sm/posts/anbox-on-the-librem-5/.
Why do people always want to run all their Android apps?! Why not iOS and Windows apps too??
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
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
Because access to mainstream proprietary mobile apps is becoming increasingly necessary to function in modern society, and people know that the iOS versions are a lost cause.
You're right, of course. And notably in the case of Android apps, they often also depend on Play Services and therefore require agreeing to Google's ToS.
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.)
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.)
> Why do people always want to run all their Android apps?! Why not iOS and Windows apps too??
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.
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.
Sadly often it's necessary for various proprietary apps like banking, government apps etc
Unfortunately, this discounts apps folks depend on made by a company that they need, and that company won't build an app like that.
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.
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.
> Why do people always want to run all their Android apps?
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.
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.
What do I need to know to develop Librem apps? Just Python?
There are multiple programming languages that can be used, as evidenced by the wide variety of apps listed on https://LINMOBapps.frama.io
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.
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.
Other languages can work too. Some tutorials: https://developer.puri.sm/Librem5/Apps/index.html.
Its the same as developing for a linux desktop. mmsd is written in C, and has python unit tests.
Librem runs Progressive Web Apps.
This is what I want. How good is the hardware?
Now this did turn me off. A 3GB RAM device from 2017?
The iPhone 8 was released in 2017 with 2GB of ram, the 8 plus with 3GB.
The amount of RAM is not the weakness of this device. The issue is the very outdated chipset (Allwinner A64) and its Mali 400 GPU (no GLES 3 support for instance).
Let's hope the pinephone2 will fix all that!
Let's hope the pinephone2 will fix all that!
You're talking about the PinePhone. The Librem 5 uses i.MX 8M Quad, which is a significantly more powerful SoC than A64.
But also significantly more power hungry SoC :(
Not really? Librem 5 easily beats the PinePhone when it comes to active usage time on battery (although it does have a battery with higher capacity). Where PinePhone currently wins is suspend time with the CPU completely turned off, as Librem 5 does not use suspend at all right now and just relies on cpuidle.
And larger battery.
You do not need a Java VM to run apps on GNU/Linux phones (unlike on Android). It works pretty well with this RAM according to many videos.
I don't know. If I'd buy a phone which I really could make mine, I'd love it to have a hardware which would still be well usable in about 5 years from now, even with my increased demand for resources as I expand my possibilities with the device.
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.
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.
Unfortunately such device does not currently exist. If you want it to be developed you better support the existing GNU/Linux phones...
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).
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).
Very cool demo!
I can see a future where Unix/Linux machines take the pro-device market.
I can see a future where Unix/Linux machines take the pro-device market.
I wonder if gtk will ever go declarative
Would love to be able to write apps in Typescript.
You can. GNOME has a JavaScript binding called gjs. It runs JavaScript (with SpiderMonkey) and has support for most of GNOME APIs.
https://gjs.guide/
https://gitlab.gnome.org/GNOME/gjs/-/blob/master/doc/Home.md
https://gjs.guide/
https://gitlab.gnome.org/GNOME/gjs/-/blob/master/doc/Home.md
What's stopping you then? If you can do it on your desktop, you can also do it on the Librem 5.
Does the IDE shown support it?
I have no idea - I'm using Qt Creator on my Librem 5. For TypeScript I guess you would probably like to run something like Atom or VSCode anyway.
You can, kinda: https://puri.sm/posts/librem-5-web-apps/
Had I put 600$ in the S&P500 when I ordered my Librem 5, I would have 1068$ in S&P500 shares. Now, I have occasional spam in my inbox about Librem 5 related blog posts. I expected to at least get a shipping date 2 years later. I understand the times have been tough, but nobody's told me if my order is cancelled or if it's still being worked on. I've seen some people receive their Evergreen phones. I'm OK with waiting, but being left out in the cold is starting to get to me.
Currently orders from the original 2017 campaign are still being fulfilled - they're all expected to be shipped by May and those people already got their shipping estimates long time ago. More recent orders should come in next few months, but there's no accurate shipping estimate for them just yet since there's a SoC shortage on the market that makes lead times fluctuate a lot at the moment. I think it's relatively safe to say that the goal is to handle the whole queue and have stock available at least by the end of the year, and if all goes well it should happen much sooner (but you can't really be sure about anything in this pandemic)
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.