The Sad Saga of Purism and the Librem 5(jaylittle.com)
jaylittle.com
The Sad Saga of Purism and the Librem 5
https://jaylittle.com/post/view/2019/10/the-sad-saga-of-purism-and-the-librem-5-part-1
193 comments
"... None of that is as bad as NO smartphone alternative to Google and Apple, let alone an open and privacy-focused alternative. ..."
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.
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.
> Just think of the huge decrease in pollution when a startup could take all those Android 2.0+ phones...and convert them say into home controllers, portable music players etc.
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.
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.
Up until Android 3 or so I think open source kernel drivers where actually required for most things, so you totally could do this for the older phones.
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.)
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.)
> 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. 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.)
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.)
There were plenty of Android phones with less than 512MB memory in the beginning. Xperia X10 Mini had 256MB to take one I owned. And that was not because it was a complete freak, the full size X10 had 384MB.
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.
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.
Sure you can run a Linux based OS in 64-128MB of ram.
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.
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.
If I'm not wrong, the fight for the right to repair if it were to succeed would facilitate this.
This doesn't make sense to me. If all those things about the company and its execs are true they are almost certainly not gonna deliver the alternative you are clamoring for. In the meanwhile your money is sitting with them instead of a team that actually might
Except that they are making progress. They've upstreamed some import work to the kernal, they've contributed to phosh and libhandy. They clearly aren't working as fast as they (or many others) would like, but they are working. And not many other people are.
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 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've seen third party developers demoing the devkit, from my understanding they really just need to stick it in a plastic shell and it's more or less good to go (outside of some bugs with gtk or video playback or whatever, phone calls and the shell works and that's all I want.)
Meego, Jolla, Puzzlephone, Firefox phone, Ubuntu phone, Librem, etc... Is there really that little demand that it's a nearly impossible task to get any "alternative" phone going?
It's exceedingly difficult to get traction and buy-in. As a freestanding effort, all but impossible. I'm holding out hope that as a side-gig / loss-leader (that is: rather unlike Purism's model, unfortunatley), it might be tractable.
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.
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.
Apple and Google will only be replaced when there is a disruptive innovation in the hardware form factor. Maybe AR goggles or something like that. As long as we stick with flat rectangular mobile devices there's just no room for other major competitors in the market.
Disruption, yes. Form-factor: not so sure.
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.
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.
Yes, and Amazon.
I'm not sure it's demand so much as extremely high barriers to entry. Android and iOS are both mature and have a lot of features, plus manufacturers like Apple and Samsung have a lot invested into the latest and greatest SoCs and other hardware features. Matching all that right out of the gate and building competitive hardware and an OS is hard, making it difficult to make something that the average consumer will notice.
Tbh, I have more hope in the Pinephone because they aren't trying to be too pure in that they're supporting Android to start but hopefully will allow other OS'es as well.
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.
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.
That handicap is also mitigated by a fanatical fanbase who will support a failing company to the end on principle.
You can't say that about most current manufacturers
You can't say that about most current manufacturers
plus paying for all the software patents
It's nearly impossible to get a "moonshot" phone going that attempts to displace iOS or Android. Most of these projects failed because they went too big. Making a phone is hard enough, but reinventing an entire ecosystem is pretty much impossible.
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.
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.
Firefox OS at least lives on as KaiOS, more successful market-wise than Mozilla ever was with it.
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.
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.
A modern smartphone phone needs an ecosystem aka apps. Even Microsoft is struggling with an ecosystem for Windows phones, and they sunk billions into them.
“An opensource phone that I can hack on” is a very, very, very niche market that can’t even cover the development costs.
“An opensource phone that I can hack on” is a very, very, very niche market that can’t even cover the development costs.
The problem is that it is very difficult for even a medium-sized business to make the economics work for a hardware business based on Free Software. As soon as someone releases a device that even remotely gets traction, just watch: there will seemingly overnight be a dozen knock-offs available both undercutting on price and adding features. Great as a consumer, lousy as a (medium/large) business.
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.
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.
This is just not a problem in practice. There are literally dozens of knockoffs of the Raspberry Pi (a Free Software-based endeavor if there ever was one!), but none of them with the quality or the support that the original gets.
It's not impossible as long as it can run the apps people use most. In my country I'd guess they are WhatsApp, Facebook, Instagram and obviously GMail and Chrome. And a lot of games.
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.
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.
[deleted]
Made a comment below to this effect, I don't think it's mere demand, there are possibly bigger hurdles to making an appealing product that can rival cheapo mobile phones.
[deleted]
The same part then says:
> 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.
> 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.
Going completely open takes a lot of money as you need to do the work yourself. Also it seems [0] that a lot of that work would be illegal in most (all?) countries. Starting to work on opening things up (RiscV cpu + everything that is not illegal/possible to open up, so I guess all but ble+wifi+gsm) opened up and then working with the authorities to open up those would be something I would put money into. Long term all this closed stuff in laptops, phones etc will be bad for many reasons.
[0] https://www.reddit.com/r/AskElectronics/comments/36aqdx/what...
[0] https://www.reddit.com/r/AskElectronics/comments/36aqdx/what...
I honestly think the LightPhone people have the right idea. They aren’t trying to compete with Google/Apple. They simply made a simple device whose idea is to not be a smartphone at all. It’s basically a feature phone, but far less distracting.
[deleted]
I don't think they're trying to be malicious, I just think that they have piss-poor public relations and are digging themselves into a bigger hole.
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.
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.
I don't think Purism is malicious, I just think they are just not sufficiently competent. There is just too much "fake it till you make it". I think they have had some very competent employees over the past few years, who joined due to the mission, and later left for various reasons (and they may still have a couple). But the management is not sufficiently competent with the technology. They see the need for marketing to keep the company alive, but they just don't know what claims or plans they can reasonably make.
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.
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.
When you've been doing development in consumer tech, some of these missteps are glaringly obvious and having proper engineering in place from the start would have avoided much of the problem. I, too, am a backer and keep hope alive, but I, too, am a hardware developer and half the things they are saying don't jive with the facts, or are omissions critical to the product's success (RAM timing, FCC certification, etc). Have to say, I'm a bit jaded now, but if it comes out, it comes out, and I'll be happy regardless. Doesn't mean I'm going to keep my trap shut when something is fishy, though.
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.
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.
> When you've been doing development in consumer tech, some of these missteps are glaringly obvious and having proper engineering in place from the start would have avoided much of the problem.
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 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.
I never expected them to build a decent phone. The Linux platform had already been out for a year prior, and yes, I did expect them to do so on schedule given the fact they have laptops that they have been shipping for some time now.
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 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.
> 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.
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.
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.
> Oh no, of course the individual(s) that promised those things aren't divorced from reality.
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 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)
>>> When you've been doing development in consumer tech, some of these missteps are glaringly obvious and having proper engineering in place from the start would have avoided much of the problem.
Maybe you could help them to prevent the next "glaringly obvious" issues ?
Maybe you could help them to prevent the next "glaringly obvious" issues ?
The problem isn't that they're somehow oblivious to the various problems... the problem seems to be from this guy's articles that they don't have money and manpower to tackle them.
Now this whole discussion reminds me of the game Star Citizen. Piles of social money go into it. But in exchange, Star Citizens delivers great demos :-) That's to a point wher I wonder : do people pay for the final product or just ofr the show, the dream it gives them (ie. exactly what you do when you pay for a good movie)...
Yep, the market just can't support this kind of product. So people who know what they're doing won't even touch it and Purism is trying to do their best with totally insufficient resources. And it sounds like their best isn't very good.
That's why they need to be super open about their technical stuff. Their experience might nurture others.
I would love to -- sadly, golden handcuffs and personal goals where I'm at right now make that impossible.
Sounds like "personal goals" might be misaligned with personal goals?
By "personal goals" I mean financial long term goals which take the front seat at the moment, as compared to things I would "like" to do.
> My big concern right now is that they're pushing hard to release before things are ready
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.
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.
Like at a Real Job®, the day the hounding starts is precisely the day you told them you would have it done. Or maybe a day or two beforehand: "Will it be done?"
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.
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.
Are there people hounding them to release it? This series of blog posts certainly isn't. All I've seen that could possibly be construed as hounding (this post included) is just asking for the honesty and transparency that they made a big deal about in their original campaign.
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.
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.
Usually you dont bypass engineering practices because customers are hounding you. The best way is to answer, demonstrate, and improve customer relations by showing them the facts. Answer a critic and you will better improve your relations. Customers can and do wait when the waiting is warranted.
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.
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 should also note: RMAs are literally taken off the profit line as a total loss in manufacturing -- if you ship something that doesnt work or has major issues, you are throwing money away.
So what do you think about allegation that they had ran out of money, and can't deliver to orignal backers, so they produce false information/hype to get more money from pre-orders to at least satisfy some of the original backers.
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 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 don't see why people are surprised, it's hardware and that stuff pretty much never gets delivered on time. I'm pretty sure the original raspberry pi came out a year at least after it was expected to and OH MY GOSH was the original pi hardware absolutely awful. I think mine was so unstable it could only reliably run for about 10 minutes with nothing plugged in.
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.
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 trolling might be the case, but given how many failures occur in these kinds of projects lead people to calling BS or grift when they see it, even if the trolls are just too cynical. You can't blame them for being a little critical.
I agree, this tone has been on their forums since the beginning.
I hope that they spend their resources building the product in these critical times, and just ignore trolls.
I hope that they spend their resources building the product in these critical times, and just ignore trolls.
I have to agree. Even if there are some problems with the phone, we need a good alternative to the Google/Apple duopoly. If you care about free and open communications, it's counterproductive to demand a refund at this point. An imperfect but mostly open device is better than a known spy in your pocket, and it will pave the way for future projects through Purism's software contributions.
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.
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.
> 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.
That applies to competitors.
When it's your customers laughing and fighting you, you're very much not winning.
stage 3 is "they fight you". (not laugh)
I guess what he meant by that is that being over-critical on many fronts is a way of fighting against Purism.
There have been some interesting technical developments with regard to the points Jay is making. For one, FCC certification should only be necessary for the baseboard -- the SOM and PCIe devices should carry their own certification. The fact that they are supposedly sending these out without certs for the baseboard is hugely concerning -- and illegal. If anything, this is the core reason why nothing has left their hands yet.
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.
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.
I can see a lot of mistakes or misconceptions here. You say
> 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.
> 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.
Okay, here we go: full disclosure, I'm an embedded software engineer that works at Google. My views are my own, and don't represent Google's opinions or views, yada yada.
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
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
> So... They have "shipped" and still haven't?
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.
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.
> That's also clarified in the blog post. Sorry, I haven't posted the link before: https://puri.sm/posts/supplying-the-demand/
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.
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.
>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.
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."
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."
[deleted]
what is RAM training? I googled this but google thinks 'training' means 'documentation' apparently
Fast buses operate at some multiple of a reference clock wired up to both sides, it's often 1/2 or 1/8th of the actual data rate which each side arrives at by feeding the reference clock to an on-die pll.
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.
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.
That seems so awfully analogue... :-/
It is... underneath all that shiny logical digital it's analogue all the way down in any real implementation.
Pace Fredkin.
It's hardware:) At that level, "digital" electronics... aren't.
Modern DDR PHYs require PLL training and adjustment to communicate to the RAM chips because DDR is runs at such high speeds that it is mostly operating in the analog domain these days.
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.
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.
Good article: https://blog.asset-intertech.com/test_data_out/2014/11/memor...
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.
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.
It seems that memory is “trained” on boot — the system does POST and checks that critical hardware is responding as expected. PC motherboards have some settings to adjust timing for enthusiasts, but I’m not sure that that’s a trend or even desirable in consumer electronics. So these expected values are probably “burnt in” to the design and difficult to change.
Maybe Purism has a way to do this?
I am not an expert!
Maybe Purism has a way to do this?
I am not an expert!
The memory isnt trained -- the PHY is. Its PLL and signal adjustment -- not too dissimilar to how a cable modem "trains" to get settings right for your specific line's characteristics.
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.
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.
[deleted]
[deleted]
it has now been made clear that the phone will have to use proprietary firmware blobs for a variety of onboard devices.
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.
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 was always my understanding that some of the hardware would not be open, but that hardware would be sufficiently isolated from the core of the device.
I think that is the key design aspect, since as other user stated, it is extremely difficult to get open source firmware unless you are willing to spend a lot of $$.
It is indeed a sad state for Purism 5 to be in.
It is indeed a sad state for Purism 5 to be in.
Agreed, having modems not sharing memory with the CPU would already be a big progress.
It's nice, but not enough. Modem will still have access to a lot of things, like all unencrypted communication, all metadata, content of all regular calls and SMS, etc.
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.
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.
I raised a concern about USB isolation about a year ago, both about the modem launching a fake USB attack and potential issues with USB peripherals via the USB C port. The underlying issue is that, unlike bluetooth, USB devices are approved and enabled automagically by the kernel.
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.
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.
It's already in Linux
https://www.kernel.org/doc/html/latest/usb/authorization.htm...
https://www.kernel.org/doc/html/latest/usb/authorization.htm...
[deleted]
Sadly, the modems are on PCIe, so this means they are sharing memory and address space with the host iMX8.
You can use an IOMMU to isolate DMA to a separate security domain. This is how Qubes OS works.
No iommu on the imx8mq.
That's unfortunate, since an IOMMU is an excellent solution to this kind of problem, especially when one considers all the potential Linux USB stack vulnerabilities that can be exploited if you assume the modem is untrustworthy.
Sadly, you're wrong, and the phone modem is on the USB bus precisely for that reason.
Sadly I am happy to be corrected! :D
Yea, if feels like if you wanted that kind of isolation, you'd actually need a second SoC on there with its own memory and some kind of communication back to the main processor.
When I was working in the mobile industry, I was told repeatedly that a 100% FOSS phone would be impossible. Not only is the existing tech proprietary and patent-encumbered, even if somehow you could get past that your GSM radio must be certified before going to market. And if your radio is FOSS-based that means an end-user can toy with the baseband, therefore you will never get your cert, period. The stuff at the lowest level must locked down before being allowed on a public mobile network.
You can release reproducible signed builds that the user can verify. You can be open source without allowing users to upload new blobs.
You can still accept PRs and stuff.
You can still accept PRs and stuff.
This is what caused me to totally dump nvidia. Their new cards require signed drivers to enable boosting behaviour, and they are unwilling to build and sign the nouveau driver. It's not like it's hard to set up a buildbot...
I wonder if you'd have to recertify after each pr merge
You would need to certify each signed release. Most likely, you wouldn't make a signed release for each PR, because of the time and expense involved, until you got to the point were changed were few and far between.
No, just before actually releasing it. Nobody cares about the code as long as it is not running on the devices.
I have no idea why anyone expected it any other way, even laptops need firmware blobs for the WiFi. (there are, I think two (2) WiFi cards with the beginnings of open source firmware for them, mine is actually one of them and I've taken the time to read through it. Lots of stuff is still totally unimplemented (a couple of popular encryption standards being the deal breaker for me personally.))
This link (Part 1) is outdated due to Purism's blog post the same day:
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.
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 recently put in a pre-order for a Librem 5 (like a month or so ago) based off the fact that their previous batches were shipping. I realized it might be 6 months to a year, but I recently have been really frustrated with my mobile experience and want out of the Android/iProduct ecosystems. My attempt to source an old Nexus 5X to run KDE Plasma off of eBay ended in a canceled order.
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.
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.
What I don't understand is why Purism and other vendors try to invent their own operating system instead of using Android or its parts which 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.
- 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.
1) 3 Gb of RAM is plenty for debian. I own lots of machines with less and they're just fine (just don't do anything stupid like running GNOME)
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.
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.
> google's solution was to just pay people to drive around and collect house numbers which no one is probably going to volunteer for
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.
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.
> 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.
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
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
Nobody is going to rewrite thousands of applications not to use Play Services either, so open-source Android doesn't actually get you much in the way of app support. Many of Android's features actually exist in a binary blob shipped by Google.
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.
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.
As far as I know, there are replacements for Play Services, and it might be easier to write and maintain them (the API is public, right?) than rewrite existing Linux apps for mobile screens.
For example, in China Google is blocked but they can use Android and applications from local stores.
For example, in China Google is blocked but they can use Android and applications from local stores.
The “replacement for Play Services” is MicroG, which does its magic with the rather ugly hack of certificate spoofing, and consequently no larger distribution wants to touch it so that the masses would be able to use it more easily. Mentioning MicroG can get you banned on LineageOS forums, not because the Lineage team thinks that MicroG is unwelcome competition, but rather because they don’t want Lineage to be identified with a project that takes that approach to getting around Google.
But Play Services and related libraries for analytics or ads have a documented API. Isn't it easier either to write an implementation of that API or put Play Services into a safe sandbox rather than find time to write or port thousands of apps (that would require millions of man-hours) you could take for free from Android ecosystem?
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.
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.
There is microG, but last time I attempt using it I run into issues installing their base services on a modern Lineage OS. Some people are using it successfully. It's kinda a shot in the dark really.
Android is a spyware delivery vehicle for google and others, I want an open and free phone that works for me not against me.
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.
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.
> Nobody is going to rewrite thousands of applications like Youtube, Telegram, Maps or Happy Farm for Debian.
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.
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 am concerned about the availability of a map app on Librem, but surely one of the existing libre OSM solutions could be ported over?
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.
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.
> You cannot use existing desktop apps on mobile without remaking their UI and refactoring them.
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”.
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”.
Different approaches: Daniel Micay's https://grapheneos.org is a step in the direction you're looking for.
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...
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...
Phh-Treble author here.
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
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
> and such a "new Smartphone OS" would probably need to be based on Android to be able to use Treble
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.)
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.)
Android is a bit of a siren... since there are many devices on current hardware working great, it looks like it should be possible to be the starting point for a lovely FOSS solution.
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.
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.
> 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
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.
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.
Could Treble enable a containerized environment for OSS distributions on certified Android-shipping hardware?
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.
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.
> smart engineers from Google
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.
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.
Because the whole point is to escape the Android monoculture.
I thought the whole point was to have an open-source, hackable device from top to bottom.
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.
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.
Yes, that too. I just don't consider Android hackable enough for me. Too constrained by design choices of others.
And there are plenty of unlocked Android devices out there that users can modify already.
And there are plenty of unlocked Android devices out there that users can modify already.
That might be not easy. Microsoft have failed to do this as I understand, though they had invested a lot of money into Windows Mobile.
You can escape the Android monoculture in different ways.
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.
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.
All the more reason.
There is also the /e/ initiative: https://e.foundation
Its not for nothing that Debian is called the Universal operating system. Last I checked, laptops on the International Space Station weren't said to be running Android, or even AOSP. They were in fact running Debian.
> 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.
> 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.
Because Android, even with all those apps is still severely limited to what you can do compared with an actual Linux distribution.
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.
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.
Not sure what you mean by "not near as polished" but reading it as "nowhere near as polished for mobile devices" perhaps.
I watched a lot of initiatives for community developed hardware, starting with FIC 1973.
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.
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.
"40+ years old men with attention span of an infant"
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.
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.
The kind of people that focus on software being licensed in a particular ideological way aren't going to be the most pragmatic folks out there.
Wow. Didn't realize this story was getting so much play over here. It has essentially failed to have an impact on reddit as nobody there apparently wants to be told that they are likely part of a Ponzi scheme.
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!
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!
Ponzi Scheme? It’s a major engineering project going over schedule. What do you expect them to say? I am so glad they have stepped up to try and get this done. As someone with a phone on order, I do appreciate you flagging the problem. I’d appreciate it more if the tone was less alarmist.
Definitely worth reading all 3 before you come here and comment on the subject. My takeaway is that the company needs to come clean, or it’s going to snowball into disaster.
I've worked directly with several people from Purism. I can confirm hearing about similar internal issues from first-party sources, as early as well over a year ago. I cancelled my Librem 5 pre-order several months ago, and it'd probably be wise for anyone who doesn't want to lose their money to do the same sooner rather than later.
> anyone who doesn't want to lose their money [would be] wise [to cancel their] Librem 5 pre-order
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.
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.
Did I not open by saying that I have more context than most people would? I have a Librem 5 dev board, too. They may end up shipping a phone to at least some of their customers, but it's going to be a disappointing product with crippling problems.
Please don’t keep us in the dark, then. Enlighten us with your secret knowledge, instead of giving us your conclusions of what you think everyone should do.
Anyone remember Neo900? That was the last project I saw that actually had some potential of being made into a working phone supporting its own OS. I threw them 100EUR for a device that was anticipated to balloon to 1000EUR in cost.
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.
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 have also been wondering about the lack of shipment and post regarding it. Some of these issues seem like they should have had a plan before announcing models.
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]
[0] https://puri.sm/posts/supplying-the-demand/
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]
[0] https://puri.sm/posts/supplying-the-demand/
Unfortunately the article is down, but I am deeply saddened to hear there are issues with Librem 5. I mean, I know its behind schedule, and that’s fine. But I really hope it comes to market.
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.
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.
My apologies. My posts have been largely ignored on reddit and I don't frequent ycombinator so I didn't realize that it was getting such play over here. Thus when some fellow nerd emailed me a few hours ago asking if I'd enable ipv6 for my site, I figured "Why not?"
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 :(
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 :(
I have so much hope in this project. Linux apps adding support for libhandy is so full filling to see. A long time dream seems to become true.
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.
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.
>So if you've been paying attention to Purism's website and do some digging, you'll realize that they've never actually [filed a Social Purpose Report]
>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.
>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.
Publicly traded companies have to file 10-K's, and failure to file ends in delisting. Similarly nonprofits have to file Form 990 or get their tax-exempt status revoked.
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.
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.
From all the previous failed crowdfunded hardware projects (like KDE Spark tablet, Jolla tablet and so on), I know one thing. Making mobile computer hardware is hard, when such companies depend on third parties for assembly and manufacturing. Those can pull the rug from under you at any point without even a blink. Especially when it's a tiny fish, which is nothing for them in comparison with clients that order magnitudes more.
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.
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.
From the other parts, it sounds like you might not have to worry about firmware at all - you won't get a phone.
I really hope more folks talk about how deeply disappointing the hardware of this company is relative to their price and sales pitch.
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.
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.
As someone who didn't back it (I got burned by the pandora people a few years ago and have shyied from helping people like this), it seems very possible the issues in producing a FOSS phone not only faces lack of will but really faces systemic challenges that have a price tag, like producing a phone with parts that don't require blobs just adds that many more constraints.
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.
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.
I've seen the phone actually make a phone call at the chaos camp this year.
Maybe the right starting point is to build a fully open USB cellular modem, rather than a fully open phone. You serve the same values and get to focus on the hardest part of the problem.
That's not really solveable.
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.
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.
It's probably an unsolvable problem without huge funding. Perhaps the better approach is to treat the cellular modem as part of the untrusted network.
For the people complaing about closed firmware, remember that obtaining FSF certifcation can be achieved by e.g. cutting off the hardware pins to make upgrading it impossible, turning the "firmware" into "hardware". This is what the OpenMoko project did https://www.fsf.org/blogs/community/task2-openmoko. Is this what you would prefer?
GTA04 isn't an Openmoko project (it just uses Openmoko Neo Freerunner's case), and the firmware injector project never went anywhere AFAIR.
Annecdata: I ordered the laptop a couple of years ago (with qubes installed). They missed SIX month-long deadlines to ship it before I finally gave up and asked for a refund.
Part 2 says (emphasis added):
> 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.
> 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.
[deleted]
[deleted]
The Librem 5 has long since gone off-course. Even before all of these supply/deliverability issues, they have never really attempted to deliver a "free" phone. What it seems they're actually trying to do is deliver a phone that the FSF will certify as "Respects your Freedom".
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.
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.
I feel for the backers but this was entirely predictable:
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.
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.
Brutal interview here with the former Purism CTO: https://www.phoronix.com/scan.php?page=news_item&px=Zlatan-T...
How I would have did 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.
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.
For someone so critical of Purism's dishonest PR, jaylittle should probably check his own hyperbolic grandstanding of being an "investor" entitled to internal information.
There's a stark economic difference in producing hardware versus software. A single person fueled with nothing but instant noodles and energy drinks can produce software that changes the world. There's no significant upfront costs and lots of room for mistakes.
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.
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.
A shitstorm must be a-brewin', because the "my account" pages at puri.sm are giving 502s right now (2019-10-27 12:59 PST).
No way this phone ships on time and working
Is it just me or is everyone hitting a 502 (Bad Gateway) error?
Should be resolved, sorry ;)
Sounds like a serious case of Elon Musk time and planning (missing deadlines, bad time estimates etc.). A small company like Purism delivering an ambitious first time project like the Librem 5 phone on time would be nothing short of a miracle. The clouds would have parted and jesus himself would have come down to congratulate them.
I'm willing to give them the benefit of the doubt and have some more patience.
It gives me a 502 bad gateway error if (and only if) I try to access it when connected to vpn.
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...