The Sad Saga of Purism and the Librem 5
jaylittle.com
jaylittle.com
Let's assume the company is in jeopardy. Let's assume the project is over-promised and will be late and under-deliver. Let's assume the CEO is a fuckup and the Marketing Director is a liar. None of that is as bad as NO smartphone alternative to Google and Apple, let alone an open and privacy-focused alternative. I'm a Linux user and I very much want a Linux phone. And there has been so, so many false starts and near misses over almost a decade. My patience and goodwill for Purism and the Librem 5 is effectively infinite. It's not over until they shutter the doors or can the project. Until that happens I will continue to hope they limp over that finish line no matter what.
1. https://www.reddit.com/r/Purism/comments/dm2smy/is_the_libre...
I also support hardware projects like ZeroPhone, Pine Phone, and the Dragonbox Pyra and software projects like Plasma Mobile. When I saw Purism articulate a vision for what a phone could be I had to support them too.
I wish they collaborated and communicated better, and I wish they had made some different decisions regarding the stack, but at the end of the day they are slowly moving the ball forward. But when I gave them $600 I did it partly because they had a vision that I valued and I wanted to signal to others that it is a vision worth investing in.
So I'm disappointed when I hear these reports, but I'm still supporting them because they are part of a very small community doing very important work. And since it's free software, it's not work that's going to waste, it can always be picked up by someone else. That's part of why it's so important.
I couldn't agree more. Unfortunately not off the shelf hardware is expensive, software support for it (device drivers) is even more expensive if not plain impossible to obtain from manufacturers in the form of open documentation, and all off the shelf phones prevent any open operating system from running on them by design, therefore making a new platform from scratch is the only viable albeit very expensive solution.
I wish Purism, Pine64 and others best luck, however. In the meantime I can only dream of laws that would force hardware manufacturers to release technical data about hardware after either X years or once they declare it obsolete or some time after they stopped selling/supporting it. Just think of the huge decrease in pollution when a startup could take all those Android 2.0+ phones, all those junk iPhone clones from 5-7 years ago, and convert them say into home controllers, portable music players etc. Old phones became junk over time because the manufacturers programmed them to become as such by refusing any kind of repurposing.
When it comes to Android 2.0-or-so phones, this is already possible in many cases. Just grab an old CyanogenMod image from the archived version of the site, grab kernel sources from the Lineage OS git repository, and start hacking on support for that phone as part of the postmarketOS project. The real problem is that every single one of those phone models runs on bespoke hardware, there's no standardization like you would find on the PC platform. It's a lot of effort for an unclear gain. A startup is not going to do this, especially when those phones are irredeemably insecure against sophisticated attackers, due to proprietary implementations in the baseband and WiFi/BT radio components.
Unfortunately these phones are incredibly under powered, they come from a time when arguments for bizarre custom OSes like Android actually still made some sense (not much IMO and after the generation that used android 4 it was really all about politics, economics, and control more than a technical argument.) The outdated radios are another issue; even WiFi evolves to the point where old enough devices stop being able to join some networks but the cellular interfaces are particularly bad.
The whole bespoke hardware thing is only an issue when you're updating the kernel (I've heard device tree debugging has gotten much better so maybe this is an opportunity to try and fix that heh), as long as the arm chip is new enough to use the modern calling conventions all of the distribution binaries should just work (I guess some of the earliest phones can't do this like the really ancient freescale SOCs etc. For those you're just stuck building everything yourself but with modern user spaces this really isn't as bad as it sounds.)
Not much, IMO. As far as compute goes, those old phones were approximately as powerful as a Raspberry Pi 1 board, with plenty of RAM as well (512MB at a bare minimum). And a conventional Linux OS can run just fine on those specs, of course.
(GPU acceleration is actually more important to have, because you can't have a modern mobile UX without it. Even Purism is very possibly going to have issues on that front, BTW. GNOME-Mobile/Phosh is a nice prototype effort, but I do not regard it as genuinely usable just yet.)
I seem to remember a few phones with 128 meg, but looking at a few at GSM Arena they all have 192MB or more. I have my old Android dev phone (upgraded all the way to Cupcake!), and that has 192MB RAM. I wonder if that still starts.
The problem is that a lot of apps start misbehaving. Firefox and Libreoffice come to mind. Firefox is really impossible to replace too (IMO) I haven’t been able to log in to gmail from a gtk WebKit browser in years and medium doesn’t even work in them (it of course works in elinks.) You can run Firefox in <1GB of ram but it won’t be nice and it won’t run long.
I absolutely disagree with you about the GPU. As long as you’re not running gnome software graphics are plenty fast.
Doing the whole nine yards (in addition to trying to make the thing blob free) is going to take more than up front investment that other, already established manufacturers don't have to deal with, which is giving them a handicap in a fight they start behind in.
You can't say that about most current manufacturers
“An opensource phone that I can hack on” is a very, very, very niche market that can’t even cover the development costs.
Keep in mind that Microsoft and Facebook failed at this. That former industry giants Nokia and RIM were felled. That Sony Ericson is no longer free-standing. Palm has died.
It's a ruthlessly competitive market with huge winner-take-all dynamics. Apple and Google are the current incumbents. History's lesson is that they will probably fall, but only to be replaced by equally oppressive monopolies. This to me is not progress.
I'm hoping Purism does succeed.
The first mobile phones ... worked. Barely.
Innovations have come in service coverage, quality, pricing (flat-rate, unlimited calls, is now the norm), early app phones (Palm PDAs making the transition), integration with corporate email (RIM), Web access (from early on, but Apple made the breakthrough), and what really underpins the present mobile devices world: advertising.
It's the fact that Google can haul in about $100 billion a year in ads sales that makes Android viable. Apple is profitable on hardware, but even there, struggles to match in technology (though it's vastly ahead in UI/UX), and has a small fraction of the market of a niche it had created.
Microsoft lacks the ads tie-in, and faces obstacles to positioning itself as sole gatekeeper to its remaining desktop / enterprise software empire (practical, political, legal). Amazon's strength might be in leveraging devices as extensions of its storefront, but that's precisely the aspect of its devices that I found so off-putting. They've all the warmth and personal appeal of a third-tier shopping mall. Though if the company can get that right, and avoid Microsoft's 1990s antitrust experience, they're a considerable competitor.
Facebook's failure may be due to growing distrust of the company and of its second-tier status (after Google) in ads. There's not enough draw to the device, and not enough revenue to support development.
What opportunities this leaves for new entrants is an open question. It also raises the issue of Purism, or any other pure-play device firm's, future. Almost certainly aquisition by some party which is tied to a revenue or related-services or -systems model.
Given the incumbents, my bet would be first Amazon, secondary, if it is truely embracing Linux, Microsoft. Though there might be others. I discount Google or Apple. Facebook is a possibility, though given Purism's focus on freedom and privacy, would be fatal.
Outside the US: most device manufacturers are too strongly wedded to one of the incumbents to make a plausible play as this would imperil their Android or iPhone contracts, which would rule out Samsung, Sony, LG, etc. A non-US telco aquisition, possibly in Europe guided by privacy regimes, could be an option.
On reflection: focus on form factor is almost certainly a red herring. Look to the sustaining business model and positive/negative appeal factors.
None of those phones looked like it could run them. Furthermore it's pretty sure it won't run the next sensation, whatever it will be.
Fairphone barely (it seems) keeps surviving and might still count somewhat as an "alternative" phone, even if their primary platform is Android.
A new OS is a big task to get to market - non-open contenders have failed too. The combination of an more open phone (which likely comes with compromises) and a new OS just makes the task even harder, and while enthusiastic, I'm not sure the market of people who'd prefer that product is large enough to make it real, sadly.
As a result, no one with the resources to readily pull it off wants to do so. Eventually it will happen. Hopefully it will be Purism and/or Pine64 because I'm really fed up with the proprietary offerings.
In my opinion, what Purism and Pine64 are doing is the right approach. Make a low-volume device for an existing operating system, without an additional "platform" layer on top. There are enough privacy and tech enthusiasts to sustain a small-volume manufacturer if you can make a functional device and keep costs down (which admittedly is a difficult problem). It's similar to the current micro-laptops that are popping up, or e-ink tablets. There's not a ton of demand, but they aren't going bankrupt.
> However there are now so many signs that Purism isn't competent enough to be trusted with a phone, much less our privacy, that I cannot in good conscience do business with them.
Do you really want a badly executed Linux phone? If it ends up with major security vulnerabilities, vendor spyware and other nasty stuff, it will only harm the idea of Linux phone itself.
[0] https://www.reddit.com/r/AskElectronics/comments/36aqdx/what...
I understand that they're worfully behind schedule and that some people are mad, but...
I wish people would just let them focus on building the phone rather than hounding them which might cause them to cut even more corners and result in a worse product.
I paid them $600 or whatever two years ago, and I say let them keep building.
It's okay to be critical, but it seems like some people are bullying/trolling. Even in HN threads from months ago before shipping was even an issue.
My big concern right now is that they're pushing hard to release before things are ready, and with this SOC, that can easily be a death knell for the product they release.
Because people keep hounding them!
Do you do your best work when people keep interupting you asking when it'll be ready? You would still complete your task if people weren't interupting you, right? The interuptions might cause you to say 'fuck it' and just ship just to get it over with, even though you wanted to spend 10% or whatever more time to make it 50% better.
That's what I'm getting at.
Thus far, Purism has been omitting facts such as RAM performance, and sidestepping directed questions. These don't instill confidence in customers for an "open" company.
Moreover, hardware cannot be shipped this way. Schedules and the needs of the hardware dictate the control of the schedule. You literally cannot ship a PCB until regulatory requirements are satisfied and the boards are assembled.
I'm a backer. I have a devkit. I opted for Aspen, Birch, and Chestnut, in that order, just like the author. I had also been figuring I'd also end up buying a batch Fir (mech v2, Q4 2020) when it came out because I can't imagine there won't be shortcomings with the versions before that. I also already own a Neo Freerunner and a Firefox Flame. I say that all to show that I'm willing to put my money where my mouth is when I say I want an open source phone.
However, even I am considering requesting a refund. I've been burned on kickstarter before and this project is so far following the "this project isn't going to deliver" manual to a t.
What does every boss say? Please communicate as soon as possible if you think the date is going to slip. Then everybody can recalibrate their expectations and you might get another little period of not being hounded. Though unfortunately it won't be as free of hounding as before, because your 2nd estimate will be trusted somewhat less than your first one, which turned out to be wrong.
Some bosses, not the good ones, will say "You will meet the date, end of story." But what no boss ever says is "You need to meet this date, and if you can't, I don't want to know about it. Please obfuscate."
Everybody knows a completely open phone is a hard job, but that ironically is the reason nobody believes the happy-face blog posts saying "Hi, everything's great!" I backed this project and I smelled something fishy as soon as they announced the "iterative shipping schedule." Not because I'm a crybaby who wants his phone now (in fact I opted for the latest possible shipment knowing the earlier ones would have "issues"), but because of how they tried to cloak the obvious and expected ("We're not ready") in terms of something straight out of Animal Farm ("We always planned it this way.") You tryin' to say you ain't ready dawg? Just say that.
As usual the missing ingredient is leadership. You need somebody who's a compass needle, not a weathervane. You need somebody who's confident enough to tell the truth, warts and all, and who knows how to get everybody to love the warts. People will dump even more money and manpower in to help you if you do that.
Maybe you could help them to prevent the next "glaringly obvious" issues ?
Oh sure, that's the problem. Instead of improper engineering, they should've gone with proper engineering. They really should've known better.
In all seriousness, if you expect such a small company could build a decent phone, on a new Linux platform, on their first try, on schedule, then you're divorced from reality.
Version 1 of this thing was going to suck, no matter what. Remember, the first Android handsets by reputable manufacturers were utter garbage.
Oh no, of course the individual(s) that promised those things aren't divorced from reality. It's the consumer that paid money and expected the product they were that's divorced from reality...
Funny how quick you are to point the blame at someone who just went ahead and thought they'd get what they paid for, on time.
What a skewed perception.
I didn't say that. From a business standpoint, it seems like a very long shot.
What did you expect the advertising campaign to be like?
"We don't really know what we're doing, we're going to fuck this up, give us your money!"
CAVEAT EMPTOR (Kickstarter terms of service, paraphrased)
I used the original Android handsets -- the first first ones that never made it to market. I remember their quality (still have one), and I'd fully expect that as the first thing coming out of the gate from Purism.
I mean, it can work out if they can satisfy everyone in the end, but it may also end up pretty badly, and be viewed basically as defrauding of people who're making pre-orders now, not being fully aware their money are used to get phones to someone else, now, and whether they'll see anything themselves is a pretty big gamble.
I guess if they were open about this, people may make informed decision to take the gamble, but that's not the case here.
To me that seems somewhat malicious.
I was a backer of the original Librem 13. I can list lots of little details which individually should be forgiven for a company like this, but together are just ridiculous. It seems like every little thing was botched at least a little. Here's a really trivial one: in the initial news posts (before anything was shipped) it was written that the touchpad driver would be licensed gplv3 and submitted upstream. I sent an email "hey, you probably want to correct that typo (should be gplv2, or maybe gplv2+, obviously)" and the response was "we will consult with the FSF". Sure, consult with the FSF in general on the project, but who could be involved in this company, announcing details like this, and not know the license of the linux kernel? On its own that is nothing, but there is so much more. When I received the laptop, it came with slightly customized debian testing, and a broken apt/sources.list so updates did not work. I can fix that, of course. But they didn't have any working repo for a couple months, back then. (Which I only really needed for the kernel builds with the rather crappy touchpad driver. Later models switched to a different touchpad, and I suspect use no drivers that required any development work.) They hired the guy who did the majority of the coreboot customization and fixing needed, after I received the laptop, like 2 years after the project started. He no longer works there. And there's more.
I haven't been following the phone project closely. I can imagine that some (many?) supporters are very familiar with these technologies and issues, and when they read the news and claims from this project, they translate it internally to what it really means, given what is plain impossible and what is very unlikely. But still, it is ridiculous, and a bit embarrassing, for others who support free software and open hardware.
Now I have a number of pi3s that I permanently have installed and haven't had issues with. This is almost certainly going to go the same way and we just need to let them do their thing.
The old canard applies here: first they ignore you, then they laugh at you, then they fight you, then you win. I suppose Purism is entering stage 3 right now.
That applies to competitors.
When it's your customers laughing and fighting you, you're very much not winning.
I hope that they spend their resources building the product in these critical times, and just ignore trolls.
What else is concerning is that they are shipping the SOM without schematics or documentation -- even the dev units have no details on their construction. For reference, Purism only made the baseboard and mechanicals -- the actual SOC and RAM are on a module made by Elecom. I asked about this in their matrix channels and the best answer I could get was "it will be made open" -- a tall order, given the past history of Elecom keeping their designs close to their chest. This is most likely the core reason why their thermal and RAM performance sucks -- the community can't get in there to help.
Note that they aren't even running the RAM at full speed -- that's not something you can easily change without re-generating the training programs, and locking that in without proper burn-in or huge amounts of QA to validate is going to likely be the biggest hurdle they will face. Especially given the requirement that the program not be updated.
Source: built and shipped SOMs using the i.MX8MQ in the past and still supporting them now: RAM training is a huge problem.
Maybe Purism has a way to do this?
I am not an expert!
PCs have codified it mostly to a set of well known and understood timings that are interchangable, so in that domain its easy. But raw DDR chips used with SOCs is much much harder because you're not beholden to Intel's standards for the PHY or the RAM.
Often this is done by setting registers. The trick is that its hundreds of thousands of registers to alter the way the PHY behaves with regard to impedance and other parameters, and the vast majority are undocumented. So its done with a two stage thing: the first is a generative program that analyses the eye diagrams using feedback from the PHY over a long period of time to get the majority of the settings.
The second half is actually getting the PHY PLLs to sync with the clocks and the RAM, which is done by the PHY at runtime, every boot.
This can create ambiguity in which bit of the 2 or 8 or whatever is on the bus, and temperature, board design, bus length, humidity etc change the phase where the best sampling place is for the data signal. So there is 'training' to test which fine delay between the receiver pll clock and the data gives the lowest error rate when used to sample the incoming data. Periodically some buses must pause and do retraining to account for, eg, temperature changes.
Basically it's the memory chip bring up procedure of the memory controller. It figures out what kind of ram is on the bus, configures and even tests it so it's ready for use.
> The fact that they are supposedly sending these out without certs for the baseboard is hugely concerning -- and illegal.
and then
> this is the core reason why nothing has left their hands yet.
Wait, so are they sending them out or did nothing leave their hands? I'm confused.
> What else is concerning is that they are shipping the SOM without schematics or documentation
No one is shipping SOMs, the phone is a board with the SoC integrated.
> even the dev units have no details on their construction
What do you call Kicad schematics then? https://source.puri.sm/Librem5/dvk-mx8m-bsb/blob/master/dvk-...
> the actual SOC and RAM are on a module made by Elecom
Emcraft
> the best answer I could get was "it will be made open"
The phone schematics will be available to those with the phone in their hands. This is how GPL works as well, btw.
> a tall order, given the past history of Elecom keeping their designs close to their chest.
Apart from the phone having nothing to do with Elcom, it's also not using anything made by Emcraft, so no one has any say about schematics but Purism.
> thermal and RAM performance sucks -- the community can't get in there to help.
I wonder if other i.MX8 kernel contributors agree https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
> Note that they aren't even running the RAM at full speed
You've clearly not read the report in the first link. RAM running at full speed was the problem causing heat generation.
Source: work at Purism.
I have been working with the i.MX8MQ SOC for over two years now, fighting with various bits of how it behaves with different vendors of RAM and dealing with exactly the same problems Purism is running into. While I haven't managed to get things upstreamed into mainline yet, our source trees are open and up at http://coral.googlesource.com.
I'm also a backer of the Librem 5, and while I didn't ask for an Aspen, I do want the project to succeed. I just have concerns that nobody's been able to answer.
> I can see a lot of mistakes or misconceptions here.
Yeah, that's probably because I'm typing on my phone and fighting both HN and iOS's Safari. Apologies.
> Wait, so are they sending them out or did nothing leave their hands? I'm confused.
Well, my statements are that a) they are trying to ship something but don't have certifications in place, and b) they claim they've shipped Aspen, but there's no evidence of it.
So... They have "shipped" and still haven't?
> No one is shipping SOMs, the phone is a board with the SoC integrated.
That's news to me -- the dev units were shipped with SOMs. If they are flattening the SOM into the baseboard, that's new, and is not what I found in my research. If that's the case, awesome, glad to hear it! :D
Where are the flattened schematics with the i.MX8MQ SOC and RAM onboard? So far, I haven't been able to find them.
Also, where's the FCC certification? Flattening the SOM into the baseboard or just integrating the SOC now makes certification a much bigger problem.
> What do you call Kicad schematics then? https://source.puri.sm/Librem5/dvk-mx8m-bsb/blob/master/dvk-....
That's for the baseboard of the dev unit, according to https://source.puri.sm/Librem5/dvk-mx8m-bsb/blob/master/READ... and the first page of the schematic. Pulling down the source and opening it in KiCad, I can't find the i.MX8MQ anywhere in the schematic or the PCB board art -- only the EmCraft SOM symbol.
> \Emcraft
Yep. Guessing that was a typo from my phone. Apologies!
> Apart from the phone having nothing to do with Elcom, it's also not* using anything made by Emcraft, so no one has any say about schematics but Purism.
Typically when you lay out a board schematic and board art, you use prior proven designs or have the upstream vendor design that part of the board for you. I'd be surprised if Emcraft isn't involved -- and more concerned if they aren't, given that the dev board does use the Emcraft SOM as a starting point.
> I wonder if other i.MX8 kernel contributors agree https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin....
Given that these commits typically come from either Purism, NXP, or Google in this regard, I can say that analysis is about correct -- the only contributors I've ever seen are the ones who are developing commercially using SOMs or the SOC directly. Obviously these corps are part of the community, but this commit is only tantamount to my point: it was authored by someone from Purism -- not someone with a dev board who doesn't work at Purism.
I'm glad to see commits to the mainline kernel, though. Go Purism! (no snark intended here -- this is one of the things I like about Purism) I'll likely be attempting to get our commits (if any) submitted to mainline at some point as well.
> You've clearly not read the report in the first link. RAM running at full speed was the problem causing heat generation.
Ahh, my apologies then. My memory must have failed me. Glad to be corrected!
> Source: work at Purism.
See above. :D
That's also clarified in the blog post. Sorry, I haven't posted the link before: https://puri.sm/posts/supplying-the-demand/
> Where are the flattened schematics with the i.MX8MQ SOC and RAM onboard? So far, I haven't been able to find them.
They are and will be available to anyone owning the phone, just like I said in the previous post.
You said:
> even the dev units have no details on their construction
so I showed you the full open sourced design.
You said
> the community can't get in there to help.
so I proved that anyone with the willpower can engage. Now you're complaining that people don't want to engage. By saying:
> the only contributors I've ever seen are [...] -- not someone with a dev board who doesn't work at Purism.
you're moving the goal posts and making me look wrong.
> Ahh, my apologies then. My memory must have failed me. Glad to be corrected!
See, that's the problem with your posts here. I'd much rather have you get corrected by asking questions at the community channels, which are frequently answered by engineers rather than post under-researched false things on unrelated forums. By posting wrong things, you're undermining the project, which you yourself claim to support.
The blog post says one thing. Nobody in the community has posted anything about actually having an Aspen in hand and working on it yet.
> They are and will be available to anyone owning the phone, just like I said in the previous post.
Technically I own one because I plonked down the ~$500 or whatever it was to preorder one. I'm in the later batches, but I have paid for one. It would be nice to get at those schematics, if they exist publicly. Sadly, I haven't been able to find them, and you haven't been forthcoming except to point me to a schematic and board art for the dev board.
> You said: even the dev units have no details on their construction > so I showed you the full open sourced design.
Ah, sorry -- I should have been more clear in the first post. I was referring to the schematics for the EmCraft SOM, without which trying to manage thermals and manipulating device trees is going to be problematic.
Frankly, it's a bit disingenuous to call that a full open sourced design -- half the dev unit's board is missing and buried inside that EmCraft symbol.
> You said: the community can't get in there to help.
And they can't without schematics for the EmCraft SOM. I was prepping to actually help out at one point, but stopped because I couldn't find the EmCraft SOM schematic.
> you're moving the goal posts and making me look wrong.
No, you're reading too much into the original post. I said the community hasn't been able to help. Purism isn't the community, and your link points to a commit from a Purism account. I fail to see how I moved the goal posts here.
> See, that's the problem with your posts here. I'd much rather have you get corrected by asking questions at the community channels, which are frequently answered by engineers rather than post under-researched false things on unrelated forums. By posting wrong things, you're undermining the project, which you yourself claim to support.
I have asked in the community and dev board channels, on Matrix, and I have spoken with engineers involved. Some questions were answered, some weren't. Others were answered with handwavy "eventually" statements. I mentioned this in the first post I made about this.
I assume that's because none of the Aspen units went to non-staff members. From their blog post:
"We intended on the second revision of Aspen (black case) getting into the hands of backers, but due to the results of quality control tests against RAM clocking at full-speed (consuming power and generating heat), we made the decision to move those backers to Birch and deliver the rest of Aspen to developers and staff."
They worked with the FSF to make it certified. To my understanding, it's basically an impossible tasking to write open source firmware, not if you want to throw additional million of dollars(this is just a guess).
The compromise is that you basically cannot update those binary blobs.
It is indeed a sad state for Purism 5 to be in.
It's nice that it can't control other devices in the SoC, but that's of little value. Modem, given it's connected over USB can also immitate any other USB device, including keyboards, pointer devices, storage devices, display devices, etc. and actually control the UI.
It can even try to exploit Linux USB stack/drivers by providing specially crafted USB messages to less used/tested USB drivers.
It's somewhat disappointing people repeat this thing about direct memory access as the only way modem can attack the device. It's not nearly enough to use USB. A lot of other mitigations are needed, if you don't trust the modem.
In general this is desired since you really want your USB keyboard to work on system setup, or you can't do anything with the computer (unless, like me, you have a PS/2 keyboard). Also, the USB device gets initialized by the BIOS/UEFI on a typical computer, which means it could launch an attack before the kernel is even loaded.
Good news is neither you nor I are the first to spot this problem, and there is already a project which adds authentication/pairing for USB to the linux kernel. It doesn't solve the boot-time issue, but it does solve the USB stick (or USB 3g/4g card) pretending to be a keyboard+hdmi monitor issue.
https://www.kernel.org/doc/html/latest/usb/authorization.htm...
You can still accept PRs and stuff.
https://puri.sm/posts/supplying-the-demand/
I am an early backer of the Librem 5 and have been following the campaign as well as comments of jaylittle and others on related forums.
I think I speak for many users in feeling that jaylitte's somewhat extreme reaction is counterproductive. But at the same time we have been disappointed in Purism's lack of transparency bordering on deception regarding Aspen. We have been waiting a long time for this phone and are okay with waiting a bit longer, but not so okay with being deceived.
I am totally prepared to support a phone that runs Linux and would rather spend time writing my own apps to fill in the gaps of my needs for either PureOS or Plasma. I had seen Purism 5 development boards on my mastodon/fediverse feeds, so I was confident they were out in the wild (Purism does have an official fediverse server; although they were given flack for some of their code modifications).
PostmarketOS has done some amazing work, but it's still a long way from being able to run open operating systems practically on mobile devices. I don't even really care about the binary blob firmware honestly as long as I had a reasonable level of introspection on the rest of the operating system.
This post makes me really sad and wonder if I should have backed this project, or tried to keep sourcing old Nexus 5Xs or wait for the PinePhone. I hate how shitty of a (non)-platform ARM is, which makes it so difficult to just port Linux to it. Microsoft at least had mandated ARM+UEFI. There are people who have gotten past their bootloader locks, but there are still no FOSS drivers for any of the hardware. If Microsoft actually gave a shit about open source, they'd release kits for getting Linux working on their old mobile devices instead of letting them end up in landfills. I've done a full post on this before: https://battlepenguin.com/tech/android-fragmentation/
I know Purism has hit a lot of controversy before. I'm not all that mad that they can't make totally open hardware ... that is just plain difficult only any x86 hardware today because of all the stuff Intel/AMD will simply not let go of. But it is sad if they're being dishonest about their progress or outright lying to people. Most of their customers are engineers and people close to the software field; people who understand the unrealistic expectations of marketing and management--people who put up with enough bullshit as it is.
- designed by smart engineers from Google
- well-tested and maintained
- well-documented
- has development tools and debuggers with GUI, not text-only GDB
- uses GPU
- has permissions and isolation for apps which Debian doesn't have
- has several app stores including FDroid and lots of apps made by independent developers
Why don't they want to use at least Dalvik and userspace software like Phone or Calendar? Nobody is going to rewrite thousands of applications like Youtube, Telegram, Maps or Happy Farm for Debian. Debian is nowhere near as polished as Android.
For example, I watched a video about Pine64 which uses Ubuntu and UI doesn't look well-designed, the icons are hidden away from desktop, the thing that pulls down from top of screen looks inconvenient to use etc. It would be better if they just ripped iPhone's UI.
Are there some technical or licensing issues or is it just because someone doesn't like Google and everything they do? Is writing in Java less productive than in C/C++/GTK or whatever they use in Ubuntu?
UPD: Also 3 Gb of RAM might be not enough for Debian/Ubuntu based OS.
With Android 8 Google introduced Project Treble which kind of enforces that AOSP work out-of-the-box on every (!) Google Certified device. This has kick-started a popular project, phh-treble, by a senior XDA developer that I keep a keen eye on.
You could flash AOSP today on any (!) Google certified android phone that launched with Oreo+ with very few quirks, if any.
https://github.com/phhusson/treble_experimentations/wiki/Fre...
First, to outside looks, your post might be confusing: GrapheneOS and (Phh-)Treble are independent, and complementary. GrapheneOS is focusing on hardening Android (and tbh I'm impressed by Daniel Micay's work). Phh-Treble is about bringing AOSP (the fully opensource Android provided by Google) to the maximum of post-Oreo devices, but using OEM's proprietary drivers. It is technically possible to make a Phh-Treble GrapheneOS, to have an hardened Android that runs on any post-oreo Android device, though that's probably an heresy.
Going back to the subject, I have to say that (one of) my goal when doing Phh-Treble is that some people use my work to create a whole new "Smartphone OS". There are many restrictions, and such a "new Smartphone OS" would probably need to be based on Android to be able to use Treble, but still, imagination is the limit, and you don't need to worry about the drivers! You can just create whatever you think has value, and pretty much anyone can use it straight away! And I'm not just thinking of FLOSS-oriented, privacy-focused, I'd be happy to see alternative "Smartphone OS" emerge.
Looking at Android as it is today, and the opensource apps the community has made, it is possible to make a privacy-focused "Smartphone OS" that is usable to the masses without much effort.
Some other post mentioned /e/, who are people that actually are trying this route. (Though they are totally ignore Treble for the moment...) Though they get quite a bad reputation, for fairly good reason (for instance there are few google "trackers" inside AOSP. they are easy to remove, yet /e/ still have them)
I personly have tried to maintain a distribution of AOSP with pre-installed FLOSS apps to get out of Google's ecosystem, but I haven't had users for it.
Back to the subject of Purism and Librem 5, even though I'm happy such an initiative exists, I feel like they are trying to do too many things at the same time. In my understanding, they are trying to: 1. Make a secure hardware (cf modem over USB) 2. Create a brand new Smartphone OS, going down to drivers, up to applications themselves, basically from scratch. 3. Make a device that runs mainline kernel.
All of those steps can be done independently, and have much higher chances of success if done independently. Also the skill-set required for those are extremely different
Not really, one could most likely use libhybris and Halium to run Project Treble's userspace parts on a fairly ordinary Linux distribution. In fact, I'm surprised that people aren't starting to test this using the likes of Debian, or Arch, or even pmOS.
(One of the remaining issues is that Project Treble images aren't really as standard or unified as people assume them to be, there are a few varieties based on architecture (32- vs. 64-bit) the "hardware-native" Android version (Android 7, 8, 9, 10) that ships on the device, and "A-only" vs. "A+B" booting scheme. But it sure beats having to use one image per phone model, and having to include proprietary blobs in the image.)
But it isn't, due to the Android approach of piling together unmaintainable vendor junk like gpu driver and sensors on old kernel that doesn't work with FOSS gpu apis, radioactive horror story wifi / bt stack using non-upstream apis. The different kernels as a whole are individual flies in amber that are impossible to keep working on newer upstream basis.
Therefore your 'secure FOSS phone' becomes the usual Android security apocalypse as soon as the vendor stops patching the security holes found monthly; that's if your vendor even bothered patching and updating those pieces quarterly or even once.
Purism got it right that there's no way to get the needed result - that it's like putting linux on your x86_64 laptop - out of Android / existing devices. The story seems to be about whether their laptop business and the kickstarter gave them enough runway and ability to pay suppliers up front for initial production.
That's not the Android approach, it's just the embedded-on-ARM approach that Android inherited wholesale. Pre-Android Linux mobile/embedded OS's were just as bad. In fact, we're starting to see some improvements. The SoC's used in the latest Google Pixel (3 and 4) phones are getting mainline support in the Linux kernel.
I'm thinking of something using an upstream kernel with cgroups and other required options to run containers enabled, libhybris or similar for low-level drivers.
There would be a default e911-capable dialer that would provide basic phone capabilities when other containers aren't running.
The containers would share fullscreen access to a wayland socket or similar arbiter of the display device.
Users could support Android in a container, and any X or wayland-based userland.
Building a free-as-in-freedom ecosystem for phone software, that isn't connected to a single company, is really important as a goal. Purism's work is/was largely being upstreamed to major community projects like GNOME, where others can build on it and influence its direction.
For example, in China Google is blocked but they can use Android and applications from local stores.
Also, there are open source apps like Calendar, Gallery, Camera or Music that don't have ads and don't need proprietary components that you could use for free.
Funnily enough, the libre YouTube app of choice on Android, NewPipe, if I am not mistaken, just uses youtube-dl under the hood, which is a script that was originally written for desktop Linux.
With regard to Maps, the sort of people who want to buy a Librem phone are probably often the people who like to use OpenStreetMap-based apps like OSMAnd or Maps.Me. I am concerned about the availability of a map app on Librem, but surely one of the existing libre OSM solutions could be ported over?
> Also 3 Gb of RAM might be not enough for Debian/Ubuntu based OS.
The Raspberry Pi 3 has less and has still served people well for many uses.
I think that you underestimate the amount of work required to port applications for a new OS. You cannot use existing desktop apps on mobile without remaking their UI and refactoring them. Who is going to do it? Who will pay for it? Will Linux users who got used to free software, pay for apps?
I know how many time it takes developing a single mobile app, and it is not less than hundreds or thousands of man-hours for one app.
Android has a working model for developers to earn money which attracts them and motivates to write new software, and the costs are distributed across millions of users which allows to keep the prices low.
Privacy-oriented phones are unlikely to become a mass product quickly so they won't create an attractive market in the nearest future, and even if someone writes or ports an app, they won't be able to keep the price low.
And as I understand, this small market of privacy/freedom-oriented phones is going to be divided between several vendors with incompatible OS distributions.
That means that there won't be many third-party applications. There will be a Firefox-based browser, Terminal (not very usable on the phone), several built-in apps and that's all. There will be no games, no popular messenger apps, no bank apps, no apps to play music, no manga selling apps, no photo editing apps, no apps to buy clothes or order a taxi.
Regarding memory usage, Android has a system that can start or stop background services, unload applications to free memory while preserving their state. Linux applications are not written with this in mind, and you cannot unload them and restore back. So they will use more memory.
Supposedly the GNOME platform that Librem has chosen makes this much easier.
> There will be no games, no popular messenger apps, no bank apps, no apps to play music, no manga selling apps, no photo editing apps, no apps to buy clothes or order a taxi.
That sounds rather like how life already is for Android users who only get stuff through F-Droid. I don’t have games on my Android phone, I told my bank I don’t want their app and I use their other 2FA solution instead. I don’t read manga, so obviously I have no manga-related apps. When it comes to online shopping, I do all that through the browser – honestly, I have never even thought about installing a retailer’s own app.
When it comes to “popular messenger apps”, again, the sort of people who would be interested in Librem’s phone are probably the sort of people who are presently using Telegram or Signal on their Android phones. There are already Desktop Linux versions of those apps, and while the UI may be an issue, it is not hard to believe that usable ports will appear for Librem.
As for “apps to play music”, back on my old Nokia N900 I was very satisfied with using MPD to play music, which could be readily installed on Librem’s phone without even having to port it. I also know that whipping up a new MPD client for whatever UI is not that much work at all, definitely not “millions of man hours”.
Questionable.
> well-tested and maintained
Not really.
> well-documented
Not really.
> has permissions and isolation for apps which Debian doesn't have
Having compared google play and the apt-get ecosystem, I cannot trust the first.
Also, Debian has seccomp, cgroups and the tooling required to provide very fine-grained access control.
> has several app stores including FDroid and lots of apps made by independent developers
True
> Are there some technical or licensing issues
Concentration of power; monopoly; corporate surveillance
> Is writing in Java less productive than in C/C++/GTK or whatever they use in Ubuntu?
There is no "they use in Ubuntu". It's a distribution. It benefits from application written in two dozen languages and most people don't want to rewrite applications in java.
> UPD: Also 3 Gb of RAM might be not enough for Debian/Ubuntu based OS.
Nonsense. I was using it with 32MB of RAM. Now 4 and I have free memory while running 2 browsers.
Creating the clone of the whole business model as MS tried may be one way.
But I think a single lone dev can probably manage to make an app that will provide UI to call/sms/manage contacts, stream some frames from camera to display, and generally anything s/he dreams up on top. It can be as simple as a single app, that allows to play with interesting concepts like running everything on a PostgreSQL database runing on the phone and replicated to VPS or whatever.
There's nothing all that time intensive/insurmountable about that.
And if single dev can do that, more can be done by a community. I certainly don't care about creating a generic app ecosystem or some such. What I care about is experimenting with reducing the bloat as much as possible, and very tight integration of everything, even as much as having things that are typically in separate apps integrated in a single UI app, with all the possibilities that come from that.
It's a red flag when you have multiple areas you're trying to differentiate in with one product. Sometimes you can hit two birds with one elegant stone. Sometimes the two goals are so inextricable that you have no other choice. Most of the time, it's just a bad idea.
And there are plenty of unlocked Android devices out there that users can modify already.
> has permissions and isolation for apps which Debian doesn't have
"Debian buster has AppArmor enabled per default. AppArmor is a mandatory access control framework for restricting programs' capabilities (such as mount, ptrace, and signal permissions, or file read, write, and execute access) by defining per-program profiles. ..."
> Why don't they want to use at least Dalvik...
Dalvik is dead anyway. Modern AOSP versions use ART.
2) Android is a fucking awful mess: the whole thing is a single monolithic project that in general doesn't accept community contributions and is extremely difficult to build yourself. It's built expecting the user to be a danger to them self and handicaps them in ways that make it very difficult to run useful software. The devtools are pretty awful compared to what you have on GNU/Linux IMO, which is quite the achievement.
3) the people buying these phones are buying them because they don't want to deal with "polish" and are happy with something like debian or alpine.
4) there are almost no apps on android that are actually useful or can't be replaced with the companies web page or a small piece of (already available and much more mature) community maintained software that runs on debian. Youtube is an absolutely fantastic example of that, if I really want something native I have youtube-dl and ffplay. graphopper (the engine used on the librem5 for mapping) is arguably an improvement on google maps (except for geocoding heh. that's a different thing anyway and google's solution was to just pay people to drive around and collect house numbers which no one is probably going to volunteer for.)
5) f-droid is amazing compared to the play store but sucks compared to a real distribution package manager.
While Google’s Streetview cars were pretty nifty things, apparently the Streetview cars were not the source of house numbers in many countries. Instead, Google simply bought the rights to existing sources of information. National postal systems and municipalities had quietly created their own databases over the years.
People do volunteer to add house numbers to OpenStreetMap. My own city of half a million people got house numbers precisely because our local OSM club organized weekend outings where we would walk around town and add all the numbers. Then, when I moved out to the countryside, I would bicycle around to add all the house numbers for the surrounding villages.
theres the mozilla stumbler app that collects wifi ap's but I think the firefox app also collects the same thing unless you opt out. then there is opencellid as well.
i drove every road in my area capturing photos using mapillary with the end goal to use them to improve openstreetmap. i had the above apps running the whole time because why not. I'm sure other mappers do the same but if not I'm sure it would be easy enough to find a few people in most areas that would be willing to contribute
Development on android is absolutely horrible, tonnes of xml and java just to get a simple hello world working, a huge bloated IDE that's practically required to do anything, glacially slow emulators to debug with instead of just running the app natively. Java and all the performance problems from that.
> Nobody is going to rewrite thousands of applications like Youtube, Telegram, Maps or Happy Farm for Debian.
Good, they aren't wanted, I don't want to have to rely on malware and proprietary messaging apps from the play store. Once you get rid of that you don't need the crazy permissions system, the users that need that permissions system don't understand it anyway.
> Is writing in Java less productive than in C/C++/GTK or whatever they use in Ubuntu?
Yes, at least when coupled with the horrible android ecosystem. Compare a hellow world app with c + gtk (https://riptutorial.com/gtk3/example/18820/-c---hello-world-...) to one in android (https://www.tutorialspoint.com/android/android_hello_world_e...). Having a sane and performant environment to build apps in is the most promising aspect of the Librem 5.
Then the next problem is that Android itself is a mess to work with, it's not designed with an open-source community in mind, the barrier is high to make it work for this kind of use case.
The community people are repeating the same issue as the industry: too much time spent on drama and talks, to little on doing stuff; 40+ years old men with attention span of an infant; people being too absent minded.
It require some willpower to forcefully kick detractors from opensource projects, as much as kicking out bad managers in a commercial enterprise.
The Silicon Valley and the culture there does not teach people any good entrepreneurship. VCs and allegedly competent mentors do not really know how to run business properly, which in my understanding means running them profitably.
I had a talk with Tapabrata (Vathys) about the case of MP3 codec chip companies still making many megabucks of pure profit on relatively simple stuff. It was very good demonstration how most of "tech" industry looses out to plain, sound entrepreneurship:
The few remaining standalone MP3 decoder chips are a very good business for whomever is making them (chips sold at $10,) and it's an easy grab for just any fabless outfit, but not many people can pull even something this simple.
It is for the simple reason that "people who will screw up running a billion dollar tech startup are equally capable of screwing up a $10M a year business." Even simple, and easy business require solid executions.
When I was 40 years old my attention span wasn't too bad; I was managing a dev team and a support team at the same time, and earning good money for it. I reckon a 40-year-old woman could have done even better. The dev team was not meant to be a profit centre; but it's easy to run a profitable support operation.But that was working as paid help; my one (youthful) attempt at entrepreneurship was a washout. I didn't have the temperament for it.
Regarding the 502s: I was attempting to enable IPV6 and HTTP/2 for my website per a request I received from a fellow nerd over email. After two hours of pulling my hair out over intermittent non-availability, I just reverted back to my good ole trusty IPV4 non-HTTP/2 config and all is well again. Except for that guy. Sorry dude, maybe some other time.
Anyway, I would encourage everybody to read all three parts. Barring that, just read part 2 as it covers what my anonymous in-the-know source shared with me and my attempts to verify their claims with publicly available information. That's the real meat of the piece (at least it should be as I spent hours researching and cross checking data for it).
Thanks again for the support!
Anyone who has sent money to anyone has already “lost” that money, in a sense. What those who have pre-ordered expect is a phone. Are you claiming that Purism won’t ever send anyone a phone? Even the person who wrote the article doesn’t go that far.
Why did I believe it was possible? They had a base to work on with the N900. Ultimately, hardware is hard and it never shipped. I don't regret plunking down as it was an attempt in the right direction, I see it as support for projects like that. The people running the project were at least transparent about delays and problems. They never said the deposits weren't a 'risk-buy'.
I can't tell you how many people came to me and were like 'hur durr, just buy the librem 5, it's a real FOSS phone that's going to ship'. Yes... soon.
The Purism can join the textblade as hardware projects that will ship soon. Don't let anyone tell you hardware is easy, it's not. Pebble went under with a device that's a lot more simple.
I’m still hopeful. And for the record it looks like Librem has indicated some of the reasons Aspen and Birch models aren’t shipped to customers in a recent blog post (memory, performance, and battery issues). [0]
It’s actually funny. Seeing Gnome 3 run on a phone made me reach an epiphany: I actually don’t like Gnome 3 as a desktop environment, but it seems pretty decent as a phone environment.
I’m currently running an iPhone because Apple makes good hardware. But I am pretty much ready to take any compromise to get a phone that can ship conventional Linux out of the box. I know it’s not everyone’s favorite, but with the Linux desktop I feel in control.
The second best thing would be a phone running postmarket OS, but I don’t see too many promising options, and frankly I think in 2019 it’s unfortunate we can’t have a phone with mostly open source firmware.
Well the answer to that question turns out to be: I just spent the last few hours of my life dealing with intermittent website availability issues on nginx after attempting to configure ipv6. I have now reverted everything and we are back online.
Sorry :(
My thinking might be way to posetive but the fact that the post gets a lot of attention on HN might even help the project instead of letting it die.
>I filed a complaint with the State Attorney of Washington over the issue
>So yeah Purism is going to skate by on yet another clear and obvious lie. They are pretty much going out of their way to take advantage of people at this point. On a side note, its really sad and pathetic how little the state of Washington is willing to do to try and compel Purism to live up to their legally mandated expectations as an SPC.
Um, what were you expecting? The State Attorney is going to view this as "someone forgot to file a form." That isn't exactly priority #1.
Meanwhile "the failure to furnish a social purpose report does not affect the validity of any corporate action" (https://app.leg.wa.gov/RCW/default.aspx?cite=23B.25.150) and the sole remedy is for a shareholder to request production of a report after 2 years.
But failure to pay the annual filing fees is grounds for immediate dissolution (https://app.leg.wa.gov/RCW/default.aspx?cite=23.95.255)
I think the story is that Washington SPCs are LLCs in pretty much every aspect besides shareholder-board disputes.
So when dealing with such crowdfunding, don't get frustrated, treat it as a high risk investment and learn to be stoic. Most likely it fill fail. But if you are lucky, it won't.
You can't overprice your goods AND be a transparently unethical company betraying the values you claim to uphold on your sales pitch. But that's precisely what Purism has become. When you compare the quality of their goods and software to other competitors, they often fall short even on the stated extra goals (e.g., privacy).
I'm not sure how Purism's brand ends up being so untouchable. It's sort of like Brave, I think it just isn't popular enough for folks to remember exactly how ridiculously badly the company ends up behaving.
After seeing so many failures in this space, it's clear it might take something beyond the mere "backers-to-a-start-up-like-company" model. I'm not sure what that will take but it's happened enough that it appears it needs something more.
Their focus has been okay... the foss os stack, the gpu driver the apps... even if they fail other projects can pick these up.
It's just very difficult to get to the point you have enough pieces in good shape for a minimal usable set of functionality in 2019. A month or so ago on a devkit, the browser was crashy and juddery scrolling, not janky but going away to think on things for a bit, failing to update any more etc.
They're kind of responsible for all the pieces in the stack, unlike a normal phone company who get OOT kernel and drivers and gpu pieces handed to them all good by the soc vendor. if they can hold out and keep their nerve, it shows signs it will get there. But maybe in 2-5 years for the software imho.
> Purism has long since spent all of the initial crowdfunding income and is depending on new Librem 5 pre-orders for most of their revenue.
Is it possible that a healthy laptop business is subsidizing phone development? Presumably not if Purism is turning to Kickfurther, but it seems like a possibility that ought be analyzed.
Unfortunately, that certification is not just complete snake oil, but actually encourages devices that reduce your freedom. I made a Twitter want about how the Librem 5 is doing entirely the wrong thing here:
https://twitter.com/marcan42/status/1040626210999431168?s=19
TL;DR the FSF lets you have blobs as long as the user doesn't see them and the main CPU doesn't touch them (not run then, like, it can't even touch them/set them up/upload them to another CPU). This means that not only are you running proprietary firmware, you also don't know you're running it, you can't see it, you can't change it, you can't audit it, and you can never reverse engineer it and replace it with a free version.
Having a pile of blobs in /lib/firmware respects your freedom a hell of a lot more than that nonsense.
https://news.ycombinator.com/item?id=16182968 https://news.ycombinator.com/item?id=17913940 https://news.ycombinator.com/item?id=15090567 https://news.ycombinator.com/item?id=17140823 https://news.ycombinator.com/item?id=17913700
I even tried to warn Todd off his approach before the crowdfunding campaign kicked off. I knew no good would come of it.
1. (If possible) License a mediatek phone & ship an open source android image. Sell it for a low price. Pros: No risk, great phone, Cons: Might not be possible - though Fairphone did it for a high end phone.
2. Ship a Raspberry Pi Zero + Battery + LCD screen sandwiched together. Pros: A focus entirely on the mfg process might get you a slim mobile device. Cons: No 4G modem.
3. Don't do it at all. Pros: Save reputation. Cons: No Purism One funding.
The approach they took (custom everything) was insane.
Libre hardware can only work if there is strong and stable demand from users, and those users need to adjust their expectations. Writing long-winded critical blog-posts, burdening Purism with refunds and investigations on formalities unrelated to the phone - that isn't going to help. If anything, it's poisoning the well. It should be obvious that most companies aren't interested in pandering to FOSS-enthusiasts.