Brian Lovin
/
Hacker News
Daily Digest email

Get the top HN stories in your inbox every day.

SkyMarshal

> The battery life seems short. I'm pretty sure that I charged it up to 99% when I plugged it in this afternoon. It's now 10pm and I just went to check something in Firefox and found that the battery has died already. And I haven't exactly been using it heavily. It's possible that I misunderstood how much I had charged it, but so far this is a bad sign.

Battery life is an area that may be difficult for smaller phone makers to compete on. I think Apple especially puts a ton of engineering effort and coordination into making iOS and their apps work efficiently with their hardware, reducing complexity, runtime cycles, and power consumption as much as possible, on top of already highly-efficient ARM hardware.

Over years of doing that (kaizen), the result is optimized hardware/software fusion with industry-leading battery life. But it seems like it takes a non-trivial amount of additional engineering time and effort to accomplish this, that will be difficult to match by smaller mobile tech startups.

I hope the open source community around Librem and Pine will be able to replicate that effort, but I'm not sure this kind of consistent incremental upgrade work is attractive enough to volunteer FOSS developers. And being maximally effective at it most certainly requires the parent company to coordinate the effort across hardware, software, internal teams, and external volunteers.

captainmuon

It depends. I think one or two dedicated engineers could spend some time and make a huge improvement.

I worked on an embedded system with an Allwinner chipset. We tried to reduce power consumption, not to save battery since it was a cabled system, but to reduce heat. It turns out nobody, not Allwinner who provided the BSP, not the board designer, nor the final customer who developed the application software cared to optimize the OS much. The CPU had four cores, but only one was occupied most of the time. But all cores were at 100% frequency. Configurable voltages were also all on the upper edge. I enabled frequency scaling, switched to the correct scheduler, and now the board was much cooler and ran with more than twice the performance.

I'm always surprized how many low-hanging fruit there are in these kind of systems.

stuaxo

Can attest to this in almost any field of optimisation, whether for power or other resource usage like space/memory/cpu.

squarefoot

> Battery life is an area that may be difficult for smaller phone makers to compete on.

It would become very easy if they realized that a lot of users who buy a Linux phone would probably be happy to trade thinness for battery life.

AnonCoward4

You could double the battery size and still only have one day of light to medium usage. Battery optimization especially in idle is important.

TheNewAndy

Have you seen how thick the librem 5 is? I think it is think because of the two m.2 slots in it, but I don't think you would want it any thicker.

stingraycharles

Very much agreed. The same is true for Laptops, by the way; I don’t nearly care as much about thinness as battery life / CPU speed.

I’d even go as far as saying that even with Apple’s efficiency and all, I’d still prefer it if they had bigger batteries.

prox

I was reading an article that also seems to indicate that dumbphones are making a bit of a comeback: https://www.bbc.com/news/business-60763168

And those are a lot thicker. Maybe Librem should not try to compete with Android and iOS at all in terms of design and just go for “privacy by default” as their campaign. (If they ever sort out delivery problems)

etbe

The Librem5 is twice as thick as any other phone I have owned in the last 10 years. In general I agree that thicker and heavier phones would be good but in this case they seem to have already got to the upper limits of what's considered acceptable nowadays.

dymk

When I worked at Apple, every day the topic of "What new knobs can we give to the battery life optimization team?" would come up

SkyMarshal

Yes that’s what I mean about coordination, every team is prioritizing this and coordinating with the battery life optimization team. The aggregate effect is essentially an army of engineers all working to optimize battery life. That’s difficult to compete with, probably even for Android who doesn’t fully control its hardware like Apple does.

It sounds like Librem and Pine, if they haven’t already, should do the same and create a battery life optimization team, responsible for coordinating that effort across hardware, software, internal teams, and external volunteers.

Hackbraten

I don’t think they’re going to be able to improve battery life for much. Not even with lots of FOSS developers throwing hours at it.

I’ve read somewhere recently that in order to keep the phone mostly free of proprietary firmware, Purism had no choice but pick lots of discrete components. That would be in contrast to most other smartphone designs with more closely integrated chipsets, they wrote.

That discrete-ness, according to the author, is likely to be an upper bound for battery lifetime on the Librem 5. After all, all those chips have to be powered at least part of the time, and that allegedly consumes more energy than a single package would.

In other words: the Librem 5 may never gain a decent battery lifetime. As drivers mature, battery usage may improve a little. But not much. Buyers may want to keep their hopes realistic.

fsflover

You are right about the lots of discrete components, but you are wrong about the battery life. Currently, Librem 5 works for ~10 hours and it has no suspend at all. One could probably expect 24 hours when suspend is fully implemented. More details: https://source.puri.sm/Librem5/community-wiki/-/wikis/Freque....

blihp

You underestimate how much other low hanging fruit there is. Yes, at some point using less integrated hardware (due to driver issues) will dominate but we are pretty far from that being the limiting factor.

rollcat

> I’ve read somewhere recently that in order to keep the phone mostly free of proprietary firmware, Purism had no choice but pick lots of discrete components.

This is only a half the story. The Purism still runs on proprietary firmware. The discrete components in question are an actual full auxiliary CPU core, its only purpose being to load the hard-coded blob to properly boot the primary SoC. This was done because under FSF's definition, if the end user cannot update the firmware blob, then the firmware is considered one with the hardware, and the hardware as a whole is "free enough".

So they took away the user's ability to update the firmware, fused it in a ROM with every possible bug and inefficiency frozen in place for the rest of eternity, wasted silicon and engineering time to do so, only to grant themselves an arbitrary, honorary badge.

This isn't even radicalism anymore, this is hypocrisy. As a power-user who values freedom, and a long-time Free Software sympathiser, I am personally offended, and won't give my money to either party until they reverse course on their user-hostility.

seba_dos1

> So they took away the user's ability to update the firmware, fused it in a ROM

That's simply not true. Users can upgrade those firmwares if they want (and absolutely no weird tricks like disassembling or soldering are necessary for that). PureOS doesn't distribute any non-free updates, but if you want, you absolutely can reflash these blobs.

tored

Reading the Librem app docs it seems like apps are GNOME programs packaged with an manifest. I can’t find anything about app lifecycle.

To be able to conserve battery apps works differently than programs, apps can be suspended. That is usually the problem with normal programs, they are not developed with battery conservation in mind.

I wonder how Librem have solved this, perhaps in their scheduler, or intends to solve this in the future.

https://developer.puri.sm/Librem5/Apps/Guides/Design/Constra...

etbe

All programs on the Librem5 appear to be in Debian packages and most of them seem to be identical to the ones in Debian. The document you cited has procedures for getting packages in PureOS independently of Debian, but it seems that most of it will be stock Debian. For my development it seems easier to just upload to Debian and wait for the next Debian release for it to be officially part of PureOS, I'll setup my own apt repository for the things I do and publish the URL for anyone who's interested.

As for apps being suspended, most apps are suspended when there's nothing to do. If a graphical application is minimised so it doesn't have to redraw the screen then it should either be doing nothing or occasionally polling a server if that's it's design.

Web browsers are an interesting corner case as web sites often have JavaScript that wants to run all the time and there's some trade-off between doing what the web site wants and saving CPU/energy. But that's probably not going to be an OS issue for PureOS but an Epiphany browser issue.

tored

Don't you need hooks on the application level so the app can handle the lifecycle to avoid polling?

https://developer.apple.com/documentation/uikit/app_and_envi...

https://developer.android.com/guide/components/activities/ac...

I'm not an app expert nor an expert on GNOME development either, but I got a bit sceptical when I read their app example code, python with GNOME, neither is famous for being snappy.

yeetsfromhell

Maybe. Android works across tons of devices and the difference in battery life doesn't jump out to me compared to the fruit company. Linux on a laptop gets similar battery life to Windows in my experience, and that's without using kernel patches and crazy settings, etc.

hutzlibu

"Linux on a laptop gets similar battery life to Windows in my experience, and that's without using kernel patches and crazy settings, etc."

Sadly I cannot confirm this for my 6+ different laptops I owned. And I tried all the crazy settings, grub, tlp, .. and even compiling the kernel myself.

It is hard to beat loads of dedicated engineers, who are paid regular and well and have access to all the proprietary device information and even manufacturing.

edit: maybe there was one time, when a linux stock install performed maybe equally than a stock windows install. But that was only because of the windows bloat, which linux does not ship. But I can easily remove most of the bloat, but I cannot just write a better gpu driver. But if windows continues its bloat path, it will be soon inferior despite way better drivers.

izacus

> Maybe. Android works across tons of devices and the difference in battery life doesn't jump out to me compared to the fruit company. Linux on a laptop gets similar battery life to Windows in my experience, and that's without using kernel patches and crazy settings, etc.

Google also invested a lot of time into optimizing battery consumption (which hackers and people like the guy from Commonsware derogatory call "War against background processing"). If you look up through history of Android releases, there isn't a single release where there would't be a pretty major change in how Android puts device to sleep and how it wakes it up again.

That stuff is really hard since a single bad service can drain your battery in matter of hours and needs seriously tight coordination between all software makers on your device to avoid problematic edge cases.

blihp

It's more often a case of misaligned incentives than being all that difficult. When your business model (both Google's and most 3rd party developers) depends on constantly streaming telemetry from a device to a server you're going to have battery life challenges. Much of Google's effort has gone to providing decent battery life while still providing the telemetry. No doubt that a fair amount of effort has gone into specific use cases like background streaming audio apps (i.e. phone/music/etc) but the hours those take are a drop in the bucket compared to making the whole advertising ecosystem work (efficiently enough) on mobile.

DeathArrow

>Maybe. Android works across tons of devices and the difference in battery life doesn't jump out to me compared to the fruit company.

I get two days of intensive use from my old Huawei P30 Pro.

xvector

Android phones have terrible battery efficiency compared to iPhones. The only reason you don't notice is because manufacturers cram in massive batteries to compensate.

Same with Linux/Windows versus Macs. It is only recently that Linux/Windows laptops have begun to approach Macs in terms of battery life, and their battery efficiency is still far behind, especially with Apple Silicon being a thing.

kop316

When I used a Pixel 3a with LineageOS, I recall never having to think about battery life unless I didn't plug it in overnight, and even then, it would survive just fine for a second day, it would just be at like 20-30%?

p1necone

I don't really give a damn about battery /efficiency/. I care about battery life. The impact on my power bill of charging up a 5000mah battery vs a 2500mah battery is completely insignificant.

If Apples battery efficiency is so good they should release a phone with a 5000mah battery /as well as/ said efficiency and market their battery life that beats all their competitors by multiple days, I'm sure a lot of people would buy that in a heartbeat.

green7ea

My oneplus 8t gets 3-6 days of batterry life with lineageos depending on screen use. It lasted only a day before lineage.

Android has great battery life, spyware doesn't ;-).

thrashh

I always thought that iPhones weren’t more efficient — they just dropped a major feature: running background apps.

I remember being able to run Ubuntu in the background on an unrooted Android phone while browsing the Internet. You can’t do that with iPhone.

That said, I rather have battery predictability over features, but I always thought that if Android dropped background apps, they would have the same battery usage as an iPhone.

dahfizz

It's not like you're going to run plasma OS on your iPhone, are you? You're running the Linux phone OS on the androids with the big batteries.

The point was that it's reasonable to expect the battery life of plasma OS and friends to be comparable to Android, similar to how Linux on a laptop is comparable to Windows.

tenuousemphasis

Got some of that data?

jorvi

I honestly think that getting 85% of the way there (basically where Android is) is very possible with concerted effort.

A nice by-effect will be that whatever tricks come out of the bag will almost equally be viable to boost the battery life on laptops.

massysett

"not sure this kind of consistent incremental upgrade work is attractive enough to volunteer FOSS developers."

It can't be possibly be attractive enough to compete with the billions of dollars that Apple can spend on this. The company has nearly $200 billion in cash sitting around. FOSS just can't compete with what Apple can invest on hardware development.

marcodiego

"WiFi works, no setup required beyond selecting a network and entering the password. Calling works, no setup required beyond installing a SIM card and rebooting. SMS works, no setup required beyond installing a SIM card and rebooting."

Interesting, possibly useful as a daily driver.

Also: link for the best pro comment about linux phones I've read on HN: https://news.ycombinator.com/item?id=26080871

branon

Thanks for the link. Most of those points are still true, except for the middle three about SMS/MMS.

If your distro ships the latest version of Chatty alongside mmsd-tng[0], SMS as well as MMS (both bidirectional) work supremely well, I trialed it as a daily driver for all of last month and didn't drop a single SMS/MMS. MMS attachments (images, didn't try video), group chats, everything was fine.

I still had to configure APN settings manually, but there was no faffing about on the command line, it just worked. All the other points, though, yeah... those are still accurate.

[0] https://gitlab.com/kop316/mmsd

Edit for clarity: this comment (and the link in the parent) references the PinePhone, not the Librem 5, though they're roughly comparable devices

kop316

I'm glad to hear MMS works so well for you! Usually other than my own usage, I don't hear too often about folks for whom it works for, usually only issues or help supporting it.

Chatty used to use a libpurple plugin, but the dev realized the issues that came with it (as the old comment outlined), and it was moved into Chatty proper, which also allowed for a much cleaner SMS/MMS implementation too.

> MMS attachments (images, didn't try video), group chats, everything was fine.

MMS on Chatty actually supports arbietrary attachments, so you could send a binary file, a PDF, Video, whatever. Android and iOS will not understand them, but you can send it to another Librem 5 or Pinephone. One neat thing I tried was to use GPG over MMS. It was successful, though very manually intensive. There was thought into making GPG over MMS transparent in Chatty: https://source.puri.sm/Librem5/chatty/-/issues/671

croutonwagon

I would be curious if this works as in "associated and holds on for dear life to 1 AP"

Or "is able to roam across a house with a few AP's or a business with many"

ad404b8a372f2b9

I'm curious how the pinephone pro compares, I've been thinking of buying it.

ge96

I have it (explorer edition), it's more powerful but right now camera does not work. Has a problem of waking from sleep too.

I've tried different setups eg. Manjaro/KDE (default), Arch/Mobian Phosh. KDE is more like a phone, Phosh is "more stable" and particularly my interest external display which is buggy.

Regarding battery I have now just started to remove them from the phone rather than putting it in Airplane mode because it still dies too fast.

The squad [0]

I have Mobian/Phosh running on SD card, see the 6 cores and 4 GB of RAM [1]

I use Tmobile for service cheap sms/call only plan

I don't use it as a daily driver yet, like install an email client and things like that. Was more interested in docked computing as a desktop. I know about Samsung Dex but I'm still onboard for a new OS, I'm particularly annoyed with forced bloat/permission issues (some understandable).

[0] https://i.imgur.com/5ngUibq.png

[1] https://i.imgur.com/A2x3x1t.png

kop316

The Pinephone Pro's software support is will a WIP. It mostly works, but there are still quite a few quirks before I would feel comfortable using at as a daily driver. (For comparision, I have no qualms using a Pinephone or Librem 5 as a daily driver, I currently am using my Librem 5 as my main phone).

cookiengineer

Can recommend to try out SXMO [1] which is very lightweight and doesn't have the same long lags as phosh has.

[1] https://sxmo.org

frankbreetz

Battery life seems to be the biggest thing holding it back from a daily driver for myself.

Afternoon to 10pm with light use, so around 8 hours. Would be curious to see how long it last with maps and music going.

seba_dos1

Around 8-10 hours is what I usually see myself as well. Up to 16 hours with everything off and idling (but without suspend, as that's not enabled yet).

[edit] I've been listening to music via Bluetooth on it for past three hours and it's at 75% right now.

BlueTemplar

Using several batteries seems to be the best option... but Purism doesn't seem to sell external battery chargers ?

seba_dos1

> If you don't care that your phone is spying on you, then the Librem 5 is not for you.

I don't agree - you may not care about spying much, but you can still want a handy fully hackable GNU/Linux computing device in your pocket as your mobile phone, that belongs to you and not the vendor; in which case, the Librem 5 may be the perfect choice for you as well :)

> Backups (...) "Unable to find supported SSH command"

Hah, sounds like a missing package dependency! Most likely missed because, well, who doesn't install ssh on their phone right away anyway? ;)

> I installed telegram-desktop with apt and it automatically shows up in the app launcher, which is a good sign, although it doesn't work.

Seems like `qtwayland5` package needs to be installed, otherwise Qt apps go through XWayland. I know that people are using telegram-desktop successfully.

> but by this time it was a bit darker, and this was the best I managed to do:

You may be interested in this blog post about how to take the most from Librem 5 camera: https://puri.sm/posts/librem-5-photo-processing-tutorial/

> It's more annoying than struggling with the autofocus on the OnePlus One.

There's an update coming that changes the focus scale in a way that makes it much easier to work with. Still not exactly pleasant, but it's definitely better :)

> I can't find an option to turn off notification sounds short of turning the volume down to 0.

It's in the quick settings accessible from the top bar - a bell icon allows you to toggle notifications between audible, vibration-only or completely silent.

> The browser has no "stop" button.

It's in the hamburger menu.

> the "please take me to the launcher" arrow being mere pixels away from the "please input a space" button

That's being taken care of, as the current implementation was always meant to be temporary - both top and bottom bars are supposed to be operated by swiping: https://social.librem.one/@agx/107220158614198549

Overall, glad to hear that you're happy with the phone :) Thanks for sharing!

etbe

By default qtwayland5 is not installed, should this be considered a bug?

qchris

I'm most curious how this impression is going to age over the next year or two, considering the new competition with the Pinephone Pro that's coming out. While Kudos to Purism is certainly due for developing the Librem 5 in the first place, and for kickstarting projects like Phosh[2] which is now used by many mobile Linux distros, they're really struggled (as mentioned re: timeline in this article) with shipping hardware.

Conversely, Pine64 hardware seems to have a pretty dedicated developer community among the various mobile Linux distros, and considering the significantly improved specs of the Pinephone Pro over the original model, I'm wondering how many people will opt for the even-more-expensive Librem 5 in the future after the Pro has been out for a bit and some of the early-adopter kinks have been worked out, considering the issues Purism has had seemed to have with reliably getting inventory out.

[1] https://www.pine64.org/pinephonepro/

[2] https://developer.puri.sm/Librem5/Software_Reference/Environ...

kop316

> considering the new competition with the Pinephone Pro that's coming out

Heh, with how the developers cooperate, you would never know there was competition.

But seriously, if you do want to fund Mobile Linux, buy a Librem 5. Purism funds dedicated GNOME/Phosh/etc. devs to work on making Mobile Linux a polish experience, and many of them also help to make sure it works on the Pinephone/Pinephone Pro. Heck, sometimes I think many of their employees spend more time helping out Mobian users on a Pinephone than they do Librem 5 users.

As much as I like Pine64 (I think making a $150 Linux Phone was an amazing idea!), they exclusively only fund the hardware development. Drew Devault has, IMO, a good overview of criticisms of Pine64: https://drewdevault.com/2022/01/18/Pine64s-weird-priorities....

ognarb

If you want to fund the Mobile Linux ecosystem, I believe it's better to buy a pinephone pro and donate the difference to GNOME, KDE or/and Ubport. Purism has some sketchy history (they refused to refund their customers and lied anawful lot of times) and if you buy a purism phone you will have a less powerful phone and will need to wait years before getting it.

amosbatto

It depends on your goals. If you donate to the GNOME Foundation, your donation won't help develop Phosh (which is the leading mobile Linux interface according to 3 different PinePhone user surveys) and it probably won't be used to make GTK/GNOME ecosystem become adaptive and mobile-friendly. If your goal is to advance mobile Linux on the GTK/GNOME/Phosh platform, then ordering the Librem 5 is the best way to get funds to the 10 software devs working on it at Purism. See: https://source.puri.sm/Librem5/community-wiki/-/wikis/Freque...

I own both the PinePhone and Librem 5 USA, and I'm seriously impressed by the amount of work the Purism devs do for PinePhone users (who are the majority of the Phosh users).

kop316

I personally tell you that the full time Purism devs were instrumental in helping me port MMS/VVM to Phosh/Chatty (without their help, MMS/VVM would not exist for Mobile Linux) and they have gone well beyond what I would expect any company would do to help out Mobian/pmOS/overall PP/PPP development (they no doubt help out other distros too, but I don't interact as much in those areas).

I also have an L5 sitting on my desk that I am using full time, and have had it for several months by now.

amelius

However ... Pine64 (Pine Store Limited) is a Hong Kong based company, and with China's appetite for mass privacy infringements (see their social credit system), there could be a problem there in the future, especially since privacy is the main selling feature of these phones.

megous

Pine64 doesn't provide any software.

fsflover

Can't hardware have backdoors? How about the firmware?

user_7832

It's an interesting article (and thanks to the author for putting it out) but I wonder what their end goal is. Is it to have a 100% secure/private phone? I'm not sure if that's possible with the proprietary firmware (though the hardware kill switches are certainly a good idea). Most importantly, the questionable usability means that either the Librem team needs to work much more, or... this becomes a "smarter" alternative to a dumb brick without giving data to Big Tech. (Ignoring the fact that a sim card automatically makes you lose privacy to the government/telecos).

When comparing against something like a Pixel running GrapheneOS, it's honestly a bit more puzzling to me. Granted, I'm definitely not the audience for this, but with G_OS you can do most things that a regular phone can do, without taking several minutes to install Firefox.

As much as I love privacy (going as far as having a semi-random username), this phone is a bit puzzling. I hope someone can throw more light on this.

blihp

The general idea behind any 'pure' Linux phone is to have a device that you can trust at least as much as a desktop running Linux. Security is definitely a key aspect for many. But it's also the flexibility of not being locked in to anything on the software side. Ideally, it also extends the useful life of the device as when vulnerabilities and bugs are found, they can be fixed rather than junking the device for lack of updates. It's still pretty early days re: 'full' Linux on mobile and so it doesn't look like much yet... it takes time. Desktop Linux didn't look like much in 1994 either.

I'm not familiar with GrapheneOS but I assume it follows the usual model when repurposing Android devices of taking various closed source blobs (i.e. drivers etc) and rebuilding the open source bits around them? If so, this approach usually locks you into a Linux kernel version to remain compatible with the blobs which limits you on kernel features and fixes as well as who knows what exposure the blobs have to offer, which also will likely never get updates.

kaba0

Linux desktops are not secure in any meaning of the word. Running everything as the same user is a catastrophe, see the recent “package-manager wiping out $HOME issue”. This should simply not happen in the 21st century, and we really should not make ourselves believe that we are safe just because desktop linux is seldom targeted and that the community is giving and well-intentioned for the most part. It is no longer a small village where everyone knows everyone and we could leave the doors open.

belorn

Every modern proprietary operative systems and mobile operative systems is designed to generate revenue for the developer when it is running on the users own hardware. Advertisement, selling personal information, tracking for marketing and r&d purposes, locking down for product positioning and upgrade/upsale paths, and occasionally discreet access for three letter agencies in order to keep politicians at bay. Linux desktops are not designed for that purpose.

Security can be many things for different people. Preventing criminals from abusing vulnerabilities in software is one kind of security. Preventing companies from black/grey hack patterns is an other. Making people feel less icky from ubiquitous tracking is one. Stopping advertisements from wasting peoples time and preventing planned e-waste is additional ones.

Maybe we need to invent a new word for security. Something about making people feel safe and preventing actions that would harm them.

fsflover

> Linux desktops are not secure in any meaning of the word.

Yes, they are: https://puri.sm/security and https://source.puri.sm/Librem5/community-wiki/-/wikis/Freque....

blihp

Sure, if you run (most of) them in their default configuration. However, they can trivially be made much more secure which is one of the appeals of Linux to some: you're not limited to whatever set of compromises a vendor decided was acceptable.

vinceguidry

They may not be secure in any absolute sense, but they are way safer than any proprietary OS.

user_7832

You've got valid points regarding the Linux usability aspect and kernel updates (I'm not exactly sure what Graphene does regarding kernels). But in such a context wouldn't it be more useful to say have a dumb phone and a separate laptop/tablet running Linux?

I'm just playing the devil's advocate/trying to understand why someone would actually use it. And yes if desktop Linux gets big that'll certainly make this entire comment seem stupid (which would be pretty nice:)

blihp

For around the house/office, a two (or more) device solution is fine for many. But when you're truly mobile people generally want to minimize the number of devices they have to deal with. For most Linux users, including myself, we're not there yet but the day is getting closer.

What is this 'if' of which you speak? I've been using Linux as my daily driver desktop for over a decade ;-) It's not likely to ever become a mainstream desktop, nor are these Linux phones, but there are a fair number of us who don't care if they do or not. We just want them for ourselves.

strcat

GrapheneOS and AOSP are Linux-based and there are no closed source kernel modules. They aren't somehow not actual Linux due to not using systemd, glibc, binutils, GCC, pulseaudio/pipewire, polkit, NetworkManager, GNOME, etc. If that's what you mean, you should say so, because those userspace components are not Linux and not using those doesn't make it any less of a Linux distribution. Is Alpine not a real Linux distribution? Is it only a real Linux distribution if it looks like what you're familiar with? More developers are familiar with Android than the desktop Linux software stack. More work goes into it. Far more apps are written for it, and that includes a very active open source app ecosystem.

Sticking to an LTS kernel branch for the lifetime of the device isn't due to anything closed source. GrapheneOS only supports devices with proper security support for all the firmware, drivers, etc. and again there are no closed source kernel drivers. We can support pretty much any mobile device with alternate OS support since any serious one will have AOSP support. Most devices have lackluster security and don't meet our requirements. We're working with a hardware vendor to get a non-Pixel phone actually meeting reasonable security requirements.

Librem 5 has a bunch of components where they are not shipping updates. You have things very much backwards on that front. The Librem 5 does not come close to meeting the security requirements to run GrapheneOS. It has a bunch of poorly secured and insecurely configured legacy hardware often without proper updates available, components that are not properly isolated via IOMMU, no secure element or all the stuff that comes along with that (HSM keystore with a nice API used by apps, Weaver to make disk encryption work for users without a high entropy passphrase like 7 diceware words, insider attack resistance, working attestation not depending on hard-wiring hashes and a lot more) and many other things. The OS they use has a near total lack of any systemic overall privacy/security work or privacy/security model and only falls further and further behind. The most exciting feature for securing devices right now is hardware memory tagging support in ARMv9, but there are years and years of tons of important privacy/security work done in a systemic way across hardware/firmware/software which are missing there before worrying about stuff like that.

Marketing something as private/secure and spreading tons of misinformation and outright lies about the mainstream options doesn't make it secure or more secure than those. It's actually pretty funny that they mislead people about the isolation of hardware components like the cellular baseband in other devices when the vast majority of mainstream phones (iPhone, Pixel, Qualcomm SoC devices, Exynos SoC devices) have it done quite well when they don't. Strange that they get away with these games of misrepresenting things, hiding the fact that they still have entirely proprietary hardware and near entirely proprietary firmware for the SoC and other hardware components, etc. Hiding proprietary stuff doesn't make it go away. Not updating it doesn't make it go away and simply ensures a highly insecure device.

blihp

> GrapheneOS and AOSP are Linux-based and there are no closed source kernel modules.

I ran AOSP builds for years and that's a half-truth at best. Sure for the kernel proper, you have the source. However, there are a fair number of closed source drivers for the GPU, modem, wifi etc. From the GrapheneOS Wikipedia page[1] it sure looks like they're following this model.

If I am mistaken and there is a miraculous state-of-the-art SoC with completely open source drivers being used by a major handset maker, do tell. You'll be a hero in the open source world for pointing out something everyone else has overlooked.

> Sticking to an LTS kernel branch for the lifetime of the device isn't due to anything closed source.

It has everything to do with things being closed source. Try doing a Linux kernel major version upgrade with binary-only drivers for key components sometime. It sounds like the only reason GrapheneOS works is because they're 'drafting' off of the kernel and driver work done by Google, not that they've cracked that particular nut themselves. Nothing wrong with that, but it does limit the useful life of a device to the first major security issue they can't fix due to a lack of source code.

Regarding the rest of your response, you're assuming that I was speaking to the Librem 5 specifically, I was not. Notice that I was only speaking about the goal of a 'pure' Linux phone since that was what seemed to be being asked about. Personally, I have a PinePhone[2] and wasn't interested in rehashing the various issues with the Librem 5.

[1] https://en.wikipedia.org/wiki/GrapheneOS

[2] which itself is far from perfect, but comes a lot closer to being a 'pure' Linux phone.

marcan_42

strcat is right here. Purism designs and markets their devices, effectively, to cater to a crowd that believes that devices with actual security are inherently evil, because they do not understand it. You can have better security with user control, but for that you need to look at the details. They don't care about the details; their story is all fluff under the guise of freedom and privacy.

Purism's marketing material is outright deceptive, e.g. they insist that in competing phones the baseband blob has access to system memory, which is a lie. The reality is that the baseband blob in the Librem 5 (which is every bit a giant blob as that in the competition) has access to the USB port of the AP and there is no filtering implemented yet, so the attack surface it is exposed to is every USB driver in the Linux kernel, which is much worse than systems with embedded basebands and proper memory firewalling where the baseband has no more inherent access, but is exposed to a smaller attack surface. That means that you are more vulnerable to giant blobs doing evil things with a Librem 5 than with, say, an Android phone running a free OS build.

Then there's the whole hilarious situation with the RAM initialization blob where Purism went and hid it behind two layers of CPUs (not execution, just handling it), because somehow doing that - which provides absolutely no benefit to the user, it's just a waste of engineering time - made it possible to certify the phone under the FSF's utterly broken and nonsensical "Respects your Freedom" program, even though precisely zero freedom was gained by doing this, since it still running the same blob on the same final CPU with the same access. All the while while reducing security, since the blob is then made no longer part of the normal OS image and is not validated with it, so it could be backdoored as part of a supply chain attack and you would be none the wiser.

The whole thing just stinks the more you look into it, and it is completely evident that the folks behind Purism are a mix of deliberately deceiving people and just clueless about security and modern embedded platforms.

jancsika

> Marketing something as private/secure and spreading tons of misinformation and outright lies about the mainstream options doesn't make it secure or more secure than those.

That's true and relevant to Purism.

Now, how about something true and relevant to your post wrt FOSS:

> GrapheneOS only supports devices with proper security support for all the firmware, drivers, etc. and again there are no closed source kernel drivers.

Tell me about the license for the source of "all the firmware." And keep in mind you found it important enough to reiterate the point about "no closed source" for the kernel drivers.

amosbatto

> More developers are familiar with Android than the desktop Linux software stack. More work goes into it. Far more apps are written for it, and that includes a very active open source app ecosystem.

The problem is that the Android app ecosystem has a very large number of apps which are based on collecting users' personal information and violating people's privacy, and it is hard for a normal user to avoid all the spyware and malware in Android. In my experience using CyanogenMod/LineageOS and the F-Droid repo since 2015, I inevitably fall back to installing some proprietary apps when using AOSP-derivatives, whereas my PinePhone and Librem 5 USA only have FOSS apps and drivers installed on them. If the goal is to use FOSS as much as possible, you are better off buying a Linux phone in my opinion.

By the way, one of the apps that I helped develop is on F-Droid (https://f-droid.org/en/packages/com.ketanolab.nusimi/ ) and I have given workshops on how to install LineageOS on phones, so I speak as someone who tries to promote the use of FOSS on Android phones, but the phone industry does put up a lot of barriers to make it difficult to install AOSP-derivatives.

> GrapheneOS only supports devices with proper security support for all the firmware, drivers, etc. and again there are no closed source kernel drivers. We can support pretty much any mobile device with alternate OS support since any serious one will have AOSP support. Most devices have lackluster security and don't meet our requirements.

The problem is that Google only sells Pixels in a very limited number of countries. Whereas Purism offers free worldwide shipping for the Librem 5, the Pixel 6 is only being sold in 8 countries (Australia, Canada, France, Germany, Japan, Taiwan, UK, USA), so your security requirements exclude over 90% of the world's population from being able to use GrapheneOS. Plus, many people don't want to financially support a company like Google which is based on Surveillance Capitalism.

> We're working with a hardware vendor to get a non-Pixel phone actually meeting reasonable security requirements.

Good to hear. I look forward to seeing it.

> Librem 5 has a bunch of components where they are not shipping updates.

Not true. Purism has promised to provide updates to the proprietary firmware on the Librem 5, and already provides instructions for how to update the firmware on the WiFi/BT and USB controller. See: https://source.puri.sm/Librem5/community-wiki/-/wikis/Freque...

> It has a bunch of poorly secured and insecurely configured legacy hardware often without proper updates available

What are you talking about? Purism purposely designed the Librem 5 to avoid planned obsolescence, so it looked for component suppliers who support their hardware for a long time. For example, NXP guarantees that that it will provide updates for the i.MX 8M Quad for 15 years (Jan. 2018 - Jan. 2033). See: https://source.puri.sm/Librem5/community-wiki/-/wikis/Freque...

In contrast, Google only promises to provide 3 years of OS updates and security updates for the Pixel 3/4/5, and 3 years of OS updates and 5 years of security updates for the Pixel 6. Qualcomm announced in Dec. 2020 that it will support its Snapdragon processors (which are used in Pixel devices) for 3 years of Android updates and 4 years of security updates.

Linux phones like the Librem 5 and PinePhone use separate components which are supported for many years by the manufacturers, whereas most Android phones (like the Pixels) use integrated mobile system-on-chips which are only manufactured for 1-2 years and only supported for 3-4 years by the manufacturer. Because Linux phones use components with long-term support by the component suppliers, the Librem 5 is the first phone to be sold with the guarantee of lifetime software updates, and PINE64 promised to manufacture the PinePhone for 5 years, which is longer than any other smartphone ever sold.

> components that are not properly isolated via IOMMU,

The Librem 5 doesn't need an IOMMU, because it uses separated components, and it uses serial buses (USB 2.0/3.0, SDIO, I2C and I2S) that don't allow direct memory access, so there is absolute no chance of the WiFi/BT, cellular modem, GNSS and USB controller being able to access the RAM or the SoC's cache. Unlike the Snapdragon processors in Pixels whose hardware is essentially a black box, we can independently verify by looking at the open source schematics that direct memory access is not possible in the Librem 5.

> but there are years and years of tons of important privacy/security work done in a systemic way across hardware/firmware/software which are missing there before worrying about stuff like that.

If you are talking about kernel hardening and running each app in its own sandbox with its own UID, then I would agree that Android/AOSP has more security features than Debian/PureOS, but the problem with your argument is that you are ignoring the fact that a mountain of spyware and malware has been created for the Android platform and users have to be very vigilant to not install any of it. According to AV-TEST, 3.38M pieces of malware and 3.18M potentially unwanted apps (mostly spyware) were created for the Android platform in 2021, whereas it is unlikely that any of that garbage will get into the Debian->PureOS repos to ever effect users of the Librem 5. Linux users rarely install anything from outside their distro's repo, whereas I often find myself installing apps whose code I can't verify when I use AOSP-derivatives because I can't find all the apps that I need in F-Droid.

Yes, Android/AOSP does have a lot more security built into its design than Debian->PureOS, but it is based on a model of letting all sorts of unverifiable and dangerous code run inside it. For more on the Librem 5's security, see: https://source.puri.sm/Librem5/community-wiki/-/wikis/Freque...

> Marketing something as private/secure and spreading tons of misinformation and outright lies about the mainstream options

Care to provide any evidence to prove that Purism or its employees are "spreading tons of misinformation and outright lies about the mainstream options"?

monkeycantype

Answering personally, I seem to be 'the swing voter' demographic for this phone - I have gone to their site many times, but have never paid them a dollar. I'm interested less because of what I could do with this phone - apple works great for me - but because I'm interested in how much the hardware can be open sourced, can a phone or laptop be built where only the low level components are sourced from existing manufacturers, without needing google or apple etc to curate the assembly. I like the idea of having what I have with apple, but not having apple or google or anyone own the ecosystem.

user_7832

If you bought it (assuming you would if you were impressed enough by their work and had the funds), would you be willing to daily it? (Perhaps assuming some bugs got fixed by then, but realistically not all)

monkeycantype

I enjoy pretending that I would.

vinceguidry

Apart from the fact that it's custom hardware designed to run Linux, (you buy this for the same reason you buy System76 or Purism's other hardware, even though you could build your own machine or install Linux on hardware built for Windows) I would much rather have a phone built on Linux than a phone built on Android. Android really doesn't offer anything more on a fundamental level than Google-made ease-of-use layers and a development platform that I can really take or leave.

I run Arch Linux on all my devices with no Desktop Environment. The simpler the system the better. Running Android Framework along with a runtime, even though it's all open source, I'd rather as much of it be free software as possible. If I could run my phone like this I absolutely would but the Librem 5 is as good as it gets while still having a device that fits in my pocket that can make calls and text.

fsflover

> (Ignoring the fact that a sim card automatically makes you lose privacy to the government/telecos).

https://puri.sm/products/librem-awesim/

kaba0

We really should not consider linux phones (and desktops!) secure. It’s only secure by obscurity and by not being a valuable target at all — they have no sane sandboxing, hardware kill switches are pretty much useless in that if you can’t trust the OS you are already lost, etc.

GrapheneOS is a secure option as well as ios. But security doesn’t come for free and not a binary thing.

braingenious

I laughed out loud at this:

“In February 2018 I placed an order for a Librem 5. Today it finally arrived.”

seba_dos1

For full context, it was a preorder for a crowdfunded device that was still in development. It started shipping in 2020, but the preorder queue is still being fulfilled (it was slowed down a lot due to the pandemic and its still ongoing chip shortage).

mike-cardwell

I had one on pre-order. There were multiple delays even before the pandemic started. The first delay when the pandemic started was the last straw for me and I got myself a refund.

seba_dos1

Yes, the initial projected release date was in 2019. It got delayed even before the pandemic for several reasons and in the end the final version was finished and started shipping late 2020 (with the first batches shipped to people who opted to receive them in late 2019), but at this point it turned out to be problematic to produce in enough quantity due to chip shortage, which is why the shipments are still ongoing.

anw

I ordered my phone October 10, 2017.

As of March 21, 2022, I have not received my order yet. When given the option, I selected to receive the completed phone, rather than a beta build. Thus, the delay.

Mainly, I did not order this to just have a phone (as I have several older Androids). I wanted to help fund an alternative to the Android / Apple ecosystems.

Hopefully soon.

seba_dos1

Unless you have chosen a "Fir" batch which is essentially what's going to be a next gen version, you should have already reached your place in the queue for the final, FCC certified and mass produced "Evergreen" batch at least a few months ago based on your order date. If you haven't chosen "Fir", then you should probably reach out to support, or check whether your address confirmation e-mail didn't end up in spam.

amosbatto

@anw, According to the Purism forum, the shipping queue for the Librem 5 has reached people who pre-ordered on October 20-25, 2017, so you should have gotten your phone by now. You should contact Purism support to ask about your order. See: https://forums.puri.sm/t/estimate-your-librem-5-shipping/112...

ThrashBeard

This, the fact that they keep increasing prices and that the phone is barely functional makes me feel that Librem is a failed project.

charcircuit

There are even people who ordered in 2017 who still haven't got their phones. Purism also doesn't want to give out refunds (despite having a refund policy). It takes people hundreds of days to get a refund.

seba_dos1

All 2017 orders should be shipped by now or are being shipped right now: https://forums.puri.sm/t/estimate-your-librem-5-shipping/112...

joosters

… i.e. ‘There are even people who ordered in 2017 who still haven't got their phones’ is completely accurate.

charcircuit

The first phone from 2018 in that table was shipped 1 week ago. As another commenter pointed out the last post in the thread is by someone who ordered in 2017 whose phone still has not shipped yet.

__d

I only laughed because I so nearly did the same thing.

I did order a Mycroft Mark II though, so I feel the pain.

macrael

I would argue that maps are the killer app for phones, this phone having a garbage map app is a death knell.

seba_dos1

Every app is the killer app for someone. I hardly ever use maps on my phone.

aflag

That may be, but I suspect most users expect a browser, a way to message friends (whatsapp or telegram in most western countries) and a maps app. Games are popular too. Being able to call and send SMS is secondary. I think not having a good maps is a big issue, hopefully they'll be able to patch that eventually. Until then, maybe google maps is not too bad on the mobile browser?

clan

While I do agree a maps app is very important indeed I find this statement completely bonkers:

> Being able to call and send SMS is secondary.

This is the basic definition of a mobile phone for me [1]. We can all have our opinions on what the "killer app" is. And some may rather want a pocket sized computer. The old grumpy man in me wants to shout "Get off my lawn" - please do not redefine what a "phone" is. How much we all may hate telcos they at least have ensured world wide communications. I accept the fact that many today are willing to trade that away to each their own favourite corporate garden be it Whatsapp, Telegram, Facetime et. al. However it does not a phone make. Sweet sweet E.164 [2].

It might be an unfair interpretation but as I read it calls should even be secondary to games!

So in my mind you argue the focus should be on a tablet [3].

You might be wishing for another device class which is fair. But this kind of redefinition I find troublesome.

[1] https://en.wikipedia.org/wiki/Mobile_phone

[2] https://en.wikipedia.org/wiki/E.164

[3] https://en.wikipedia.org/wiki/Tablet_computer

seba_dos1

GNOME Maps definitely needs and has a pending redesign to make it fit better on a phone screen. Meanwhile, Pure Maps has worked really well for me that one time I needed navigation during the past year :) https://flathub.org/apps/details/io.github.rinigus.PureMaps

gorgoiler

I wish VoIP was better supported on phones, but I’m guessing the phone manufacturers wouldn’t dare annoy the big carriers by offering alternatives?

Circuits on packets on circuits on packets is a problematic thing, I guess?

I don’t really want SMS, MMS, or raw calls if I can use email, IM, and VoIP.

Even in iOS the VoIP clients are pretty thin on the ground. Bria is still the best one? It feels like “wifi calling” is probably VoIP but it without the ability to change your sip provider. Argh!

linmob

The GNOME Calls app in the Librem 5 can do SIP calls, and the SMS/MMS app Chatty can do XMPP (OMEMO encryption is cuddly though) and Matrix support is being worked on (as in not enabled by default yet).

Razengan

A FOSS tablet/phablet-sized device with no phone/SIM functionality would be great. Discard the camera too.

It would reduce the complexity and price. I can’t recall the last time I really needed to make or take a “phone” call. That shit’s legacy now.

Just give me all the messaging apps and a good browser. Perhaps a clamshell design with a physical keyboard.

linmob

You can always get a PinePhone and switch those kill switches off ;-)

Delivering all the messaging apps on a GNU/Linux device seems like a difficult task though, from what I’ve gathered about apps that others and I tested [0].

[0] https://linuxphoneapps.org

DeathArrow

"Those who would give up Freedom, to purchase a little temporary Convenience, deserve neither Freedom nor Convenience."

I know that, but Librem it's still too rough for me. I hope it will get better in the next iterations and I applaud those who buy it now, knowing they are also funding R&D for better future phones.

raverbashing

This quote is one of the most taken out of context. It does not mean what people think it means. It is also naive.

But I agree, Librem does look a bit raw to me. I'm ok with 'apt get'ting stuff on my PC. Not on a phone

fsflover

It doesn't matter what was the intention of this quote. Its new meaning is pretty much right.

raverbashing

Here's another relevant saying: "those with glass ceilings shouldn't throw stones"

We do exchange "freedom" (whatever vague definition of it) for security and convenience a lot. Even without realizing it.

DeathArrow

The hardware isn't the best. It has many usability problems. But if it will get traction, things will improve for sure. Not only Librem might get better phones out, but it might inspire competitors.

fsflover

It already inspired Pinephone.

Hackbraten

PSA for anyone outside the US: you may never be able to buy a replacement battery for your Librem 5 due to IATA restrictions.

So the Linux kernel may support the Librem 5 for life, but what’s even the point of all that effort if the phone is just going to irrevocably die on you after a couple of years?

You may want to keep that in mind before you buy one. I ordered a Librem 5 last year but got aware of the issue only recently.

fsflover

> you may never be able to buy a replacement battery for your Librem 5 due to IATA restrictions.

Except if Purism opens a store in Europe. And they intend to (not that there is a big progress currently).

Daily Digest email

Get the top HN stories in your inbox every day.

Librem 5: First Impressions - Hacker News