Librem 5 Phone Progress Report
puri.smThey are likely to fail because they are under capitalized for what they are trying to do.
The manufacturing processes to produce a decent phone are fiendishly complex. The cost of equipment to do basic quality assurance of the hardware stretch into the millions of dollars.
If (and it's a HUGE if) they are able to ship, it's because they will have put all their trust into their manufacturer, and the manufacturer that built the product for them delivered.
> One of the big tasks of our software and design teams, working with our partners (GNOME, KDE, Matrix, Nextcloud, and Monero), will be to create a proper User Interface (UI) and User Experience (UX) for a phone screen.
No it's not. They should lay off all those people and spend all the money on QA / testing hw iterations. The strategy should be to try to spend the $2M as miserly as possible, until they have something that looks like a phone and passes a crapload of software QA tests. For what they have and because their prospects of raising vc cash are dim, burning 150K/month on ui & framework building is not a good strategy.
Thoughtful quality insight, hope it turns out wrong :)
I hope so too for their backers sake. There is another dimension to this too that I thought of after my last post.
Their potential partners can be grouped into two categories. Companies that have produced phones before and companies that haven't but may claim related expertise. The former group are competitors to Purism and have a strong economic incentive to stop the commodification of the phone platform, esp for a relatively small payday. For the latter group, they would be essentially funding another company's R&D process. Imo it would be a fatal mistake to choose a fabricator that hasn't produced a phone before. It's so crazy that the latter idea should be dismissed entirely.
The i.MX6 CPU is, by the way, the CPU that is used in the opensource Novena laptop. Apparently it is a reasonably powerful processor, but more importantly, it doesn't require an NDA to access the datasheet.
I am not sure how things will be for the i.MX8, but I certainly hope that they will continue this practice.
https://www.nxp.com/docs/en/reference-manual/IMX8MDQLQRM.pdf
Seems like it is available
Nice, I actually looked for it in December but it wasn't there yet. Looks like I just missed the boat.
There are no datasheets for the Vivante GPU that NXP integrate as a silicon blob.
Anyone able to comment on how Spectre is being addressed for this processor and/or even in general by its manufacturer?
https://community.nxp.com/thread/467234 (2018-01-11) basically says NXP will work with customers privately and end users should contact their OEMs.
https://puri.sm/posts/purism-patches-meltdown-and-spectre-va... appears to only cover Intel CPUs.
i.MX6 uses Cortex-A9 cores so is affected by spectre. ARM has some good info on how to deal with it: https://developer.arm.com/support/security-update
i.MX8M will use Cortex-A53 cores so is not affected by spectre.
EDIT: Clarified that i.MX8M only has Cortex-A53 cores. Some i.MX8 parts will have Cortex-A72 cores which are affected by spectre. i.MX8M is the version discussed by Purism's post.
Thanks much for investing the time to carefully reply!
Unfortunately NXP nuked a lot of the free support from orbit when they acquired Freescale.
Even stuff like sd card images for their dev board disappeared off their site more or less immediately after the acquisition.
Isnt the i.MX6 CPU comparable to the CPU in a Samsung Galaxy SIII phone?
I consider it to be slow and outdated.
It all depends on what software you run under it, certainly Java does not help in this context. A few days ago I had Debian+lxde running on one of those very small chinese mini netbooks; I can't check now what's the CPU, but it's a 300 MHz one with only 128MB RAM, and the system boots from the SD card (the laptop comes with Win CE). I wouldn't call it snappy for sure, but it's useable.
Not sure why this is being downvoted. I'm afraid you're right that many commercial, closed-source CPU's are faster, but (depending on your application) it's not that bad. CPU's in smartphones are ridiculously overpowered for 95% of the uses cases anyway. Anyway, it's the best 'open' (then documentation is openly available; the CPU is not open source!) processor available, AFAIK.
I'm excited to see how this goes. I've been lamenting to friends of late how I don't feel there is anyone out there innovating on hardware/software to compete with the likes of Apple/MS/Google, but I see a ray of hope in puri.sm.
IMO, Purism's biggest innovation is their business plan, they're profitable selling a small number of phones. The Ubuntu Edge failed their crowdfunding campaign with $12M pledged; the Purism succeeded with $2.5M.
The business plans of Nokia, OpenMoko, Firefox and Ubuntu all depended on selling millions of phones. Built on the ashes of those efforts, Purism appears to have a viable business plan making good profits selling many thousands.
Nokia's N770-N9 Maemo/Meego saga was profitable despite being a side-project and having little to no marketing.
It's the best mobile platform I've ever tried. After all, it was just a tweaked Debian distro.
It's exciting to see Purism might head the pure Linux stack way, not just a de-Googled Android route. I also wish Jolla eventually open sources Sailfish, or gets bought by someone who does this.
Nokia (Maemo) - not really, it was more of a side project that worked pretty well for them and still would with such volumes as it got. They had a chance to turn it into something bigger, but waited for too long, playing internal battles between Maemo and Symbian teams, so eventually Microsoft came and pulled out the plug.
OpenMoko - not really, it was major mismanagement in other areas (and some poor luck) that killed it, but AFAIR production volume was actually being predicted quite well.
Firefox OS, Ubuntu Edge - sure.
Totally agree, Nokia had it in its hand to create a third option. Nokia had lots of consumer good will, the N900 (and Maemo) was super well received specially by developers but it could even compete against Android for normal consumers as well.
They should have iterated on this with every flagship phone and push it to the cheaper phones as well.
I was so sad and angry when this never came together. They just spiraled out of control after that.
I think what's helping here is also gradual commoditization of mobile hardware components.
Almost a return to the 70s era of computer startups! I'm hopeful for their success.
I'm very happy with my Purism Libre 13. PureOS I don't care for, but Ubuntu Budgie runs like a dream and the hardware quality is great.
I wish them success. I didn't back it personally though, since hardware projects are very risky. Even Jolla tablet failed, and as a backer I'm still waiting for my money back. Mobile handsets are a whole level harder to make than tablets. But I'll surely buy Librem 5 once it will come out.
On a side note, when will they add etnaviv to Mesa's features.txt? So far it can't be shown in Mesa matrix: https://mesamatrix.net
I'm similarly worried about it not working out in the end (perhaps because they have my money now!), but the part that most gives me hope is that these guys have already worked out how to run a successful open hardware business at lower quantities. Given the terrible track record of others trying this route, that business knowledge seems very valuable. I remain hopeful and excited :)
I bought my purism laptop back in mid October and it still hasn’t been shipped yet. I can’t imagine the timeline for something that doesn’t have a processor picked out yet.
That sucks. What did they state about the shipping up front? How has their communication been?
Similar story for me, I think November. I checked back in I think in December and they told me they had run out of stock. I was told early January (well, here we are, still waiting). On the other hand my friend ordered just before me and she got hers pretty quick. I guess she got the last one, hah.
I ordered before they had them in stock. They estimated mid november to start shipping. They started shipping some late nov/early December. I asked for a TPM to be installed on my laptop, which they are apparently doing by hand. This is what they attributed the extra ~6 weeks and counting delay on top of the original delay to. Last I heard after I reached out to them (December) they hoped to ship “second half of January”. They did not mention this when I added the TPM to my order. Not super happy about this obviously :/
Has Purism allocated the resources necessary to both reverse-engineer the Vivante GC7000Lite and provide a fully working set of free software drivers for it?
Seems to me there would be lots of organizations out there, like corporations, that are deathly afraid of spying and hacking, and would love to be able to buy something like this.
I sincerely hope this project continues to forge ahead! But, I'm wondering if any thought is being given to the development of 5G devices by Purism, or is that milestone for the market still a ways off?
5G isn't even standardized, let alone having networks and devices ready for production. That's a ludicrous thing for the Librem 5 team to be concerned about.
Ludicrous? It was just a question guys...
In my own words:
> or is that milestone for the market still a ways off?
Are there any 5G chipsets available for purchase in the quantaties Purism can afford?
Are there any networks around yet?
> Are there any networks around yet?
Estonia has one. https://www.ericsson.com/en/news/2017/9/5g-goes-live-in-the-...
And Verizon announced that they want to build 5G networks in up to 5 US cities this year. https://www.verizon.com/about/news/verizon-launch-5g-residen...
I have no idea that's why I am asking HN.
From our contact from the Etnaviv developers we know that they are heavily working on the i.MX8M support so we can expect that Etnaviv will be working on it within the year.
What exactly are people funding Librem for if not to actually work on the most crucial component, the GPU driver?
I guess it doesn't really matter because if they want to have any hope of delivering they will be knee deep into Mesa and DRM before they know it. This isn't a blob you just copy into /vendor.
But their lax attitude kind of spells doom for the chances of this crowdfunding project.
Edit: whoops, they don't even want to use Android! But judging from their mockup renders they expect to have something just as good.
> Edit: whoops, they don't even want to use Android! But judging from their mockup renders they expect to have something just as good.
Their mockup renders were with actual software – the KDE and Gnome desktops already support mobile natively, and there’s more and more software for these environments available as well.
> Edit: whoops, they don't even want to use Android! But judging from their mockup renders they expect to have something just as good.
By not using Android, they automatically have something better.
Wait, so they're not using Android? They're going to try and make their own phone OS?!
Yeah good luck with that.
Maybe you want to read their crowdfunding page and homepage, because not being an android phone is the point from the start, so I'm not sure why you seem surprised :)
It's not the first attempt, either. Before them, there has been (in no particular order) firefox OS, ubuntu phone (Unity was initially meant as a "responsive" environment for mobile, laptop and desktop), QT mobile and maybe others. For a long time, opensource leaders wanted to build a "true" linux mobile OS, this is just a new step on that road, and I hope this will finally be a successful one.
I'm not sure why you consider it to be an impossible challenge, the hard part in building a new OS was building its kernel and coreutils, and this has been solved for about 30 years. Now, it needs to be adapted for mobile specificity.
I think it's worth asking ourselves if the hard part is _really_ the kernel and coreutils if as you say it's been a solved problem for 30 years.
I guess I should have said "the hardest part" :) I don't mean to make ARM devs and mobile UI interfacers work look casual.
Given even how Samsung is mis-managing Tizen, I don't have any hopes to any actual GNU/Linux based handset.
That's the point. No Android. They aren't going to make a whole new OS, they are using Linux but with conventional glibc and graphics stack (Mesa / Wayland). They are relying on Etnaviv: https://github.com/etnaviv
That's a good thing. There is more than enough Android around already, we need proper Wayland based mobile Linux with open drivers, that also works on a decent usable device (and that it's privacy respectful is a huge bonus too).
Jolla for example never opened up their SailfishOS despite multiple promises (it's just too hard and not a priority for them). So Librem 5 can be that option at last.
Would love to see OSes based on KDE Mobile or whatever it is called these days. Qt is a solid framework.
Fairphone Open [1] for FP2 is based on Android but completely open source. You can run it with GCM (which isn't open source) or without. You can run LineageOS (with or without microG), and there are unofficial ports of Ubuntu Touch and SailfishOS. The phone is also modular though the hardware is slightly out of date for 2018 standards.
[1] https://code.fairphone.com/projects/fairphone-2-official-rel...
> Would love to see OSes based on KDE Mobile or whatever it is called these days.
Purism said, they are working with KDE developers to support Plasma Mobile on Librem 5.
I wish though Plasma Mobile would get rid of those archaic on screen buttons, and would adopt SailfishOS style swipes navigation. Or at least they should make that an option. KDE is after all well known for customization.
> I wish though Plasma Mobile would get rid of those archaic on screen buttons, and would adopt SailfishOS style swipes navigation. Or at least they should make that an option. KDE is after all well known for customization.
I wish they won't, as it's hard to get right. In my personal opinion the Sailfish swipe UI was one of the probable reasons it failed in the market -- it was hard to explore, and error-prone to use.
Meanwhile the N9 swipes felt just right to me, so I think it's about having enough UX expertise at the design team. Which open source projects famously are short of.
Things are different now, though. The release of iPhone X has finally made such UI gestures mainstream.
Make it configurable, so users would be able to assign actions to any swipe and gesture. That should allow customizing it to your needs any way you want.
That works for technically oriented people, so maybe in this case it'd be fine. But in general configurations are avoided in end-user applications for a good reason, as they increase complexity both for developers and users.
KDE is famous for configurability while providing useful defaults at the same time. So it's only fitting.
Whilst I understand the need to make some bespoke UI components, I hope they don't get too much not-invented-here syndrome.
OpenMoko went down that route: the Freerunner shipped with a bespoke GTK UI (with support from Gnome; I seem to remember them being at GUADEC) but they'd already deprecated it in favour of a bespoke EFL UI. This meant a huge amount of churn, resulting in multiple half-finished projects, rather than a single reasonably-decent UI.
For the last 10 years my Freerunner has been running on 'qtmoko', which is just Debian with the QtMobile UI (which AFAIK was a Trolltech demo).
These days there are even more FOSS mobile UIs floating around (Maemo, Meego, Plasma, Unity, FirefoxOS, Android, QtMobile, etc.) so hopefully Librem will just pick a stable OS (Debian?); pick one of these UIs, or interoperable components from a few; add on their Matrix messenger thingy, and ship.
Even if, for some reason, the flagship OS isn't polished enough on launch, there are other OS options that are. I'd argue that, from what I've seen, Ubuntu Touch is already good enough, and thanks to the UBports team it's still under development.
> collaboration with GNOME and KDE
Free software, or "why do anything once when you can do it twice for twice the cost and half as good?"
If you want to make a committee and decide for everybody what should or shouldn't be worked on, by all means, go ahead. Or agitate against projects online, that works too. Should be a fun for you and funny for most others.
Or you could just contribute to a project you find suitable, for whatever reason. Should be fun for everyone.
This startup isn’t going to prevent things from being worked on by others, but if they can’t decide basic things like which gui toolkit to use, then they’ll burn through their (extremely limited) funding well before they have a working, let alone competitive, product.
The mistake of “support every option in the community for version 1.0” has happened before. I suggest reading an OpenMoko postmortem (especially if you are somehow involved with this project).
For this product to succeed they need to minimize the amount of time and resources they spend getting to a phone that works as a daily driver.
Someone else can port qt/gtk/elightenment/etc to it after that happens. Otherwise, there will be no sustainable hardware platform to port those things to.
Yeah, who needs choice! Let's appoint someone to decide for everyone. Are you available?
Not that this singular comment is going to help reform free software culture anytime soon, but this business of choice needs to be examined a bit. Simply adding more choices is not an advantage by itself. Have 10 choices which are all bad is not better than having 1 bad option.
In the case of free software, there is a limited resource of people's time and skills. Adding more choices means spreading that resource more thinly - you basically make things worse by having more choices.
Sadly the community is more fractious even than most political landscapes, so the probability of convergence and de-duplication of effort is basically zero and the linux desktop will always be a bit half-baked.
> Have 10 choices which are all bad is not better than having 1 bad option.
But having 10 good choices is clearly better than having 1 good choice, and that's closer to what my experience with FOSS has been.
> But having 10 good choices is clearly better
Not exactly.
tl;dr: Even if separate Lego pieces are really good by themselves, it's no good if you can't stack them together effortlessly.
------
The problem I see with GNU/Linux ecosystem is incompatibility issues. There are many ways to do one thing, but all of them are incompatible (completely or to a significant extent) with each other.
This is how modern GNU/Linux desktop is a Frankensten's monster made from ton of software pieces somehow glued together with duct tape and compatibility adapters. No consistency, every app works differently etc etc. There are higher-tier projects that try to unify different lower-level modules (e.g. NetworkManager or PulseAudio), but then something still relies on something else, like distro-specific stuff like ifup or netctl or wants raw ALSA, etc etc. Really, it's a mess, and even though I like GNU/Linux as my desktop it's sometimes quite painful to make it "just work", hoping for some sane levels of consistency.
I know, this is not about desktops but it's just most visible there. The actual point is, too many different incompatible implementations lead to integration fatigue. Or frustration because you have to make sacrifices (get either this or that but not both).
This problem is by no means unique or specific to GNU/Linux or FOSS, but it's most visible there.
> Even if separate Lego pieces are really good by themselves, it's no good if you can't stack them together effortlessly.
I think that's unnecessarily splitting hairs. Compatibility factors into being a good choice. You can cherry-pick counter-examples, and no one's denying that those exist. My experience (almost 20 years) with FOSS has been overwhelmingly positive.
In general there is plenty of good FOSS software, but there is also plenty of bad FOSS software. Specifically though, when it comes to user interfaces and linux desktop in particular, that is something that needs intensive work, extensive testing, and a strong design vision. These are all lacking, because they are difficult and expensive and if you spread what people you have between different projects you're not going to get the resources you need.
Case in point - every company that's tried seriously to build consumer-friendly linux products has basically had to re-build the interface themselves (Nokia/Jolla, Samsing Tizen, PalmOS, Google).
> In general there is plenty of good FOSS software, but there is also plenty of bad FOSS software
Yes. That's very different than saying there's 10 bad choices, though. IMO, the good outweighs the bad, but you won't get an argument from me about there being examples of bad FOSS.
> if you spread what people you have between different projects you're not going to get the resources you need
Personally, I'm very happy that I have the option to run XMonad. What @detaro wrote is spot on here: "You can not assume that all the people working on 10 alternatives otherwise would work on one project together. That might work with your employees and work projects, but not with volunteers" (https://news.ycombinator.com/item?id=16177915). I highly doubt the XMonad developers would even be interested in working on the WM that you're envisioning, so there's no loss in having them spend their efforts on a WM that does interest them. It's definitely made my life richer.
> Case in point - every company that's tried seriously to build consumer-friendly linux products has basically had to re-build the interface themselves (Nokia/Jolla, Samsing Tizen, PalmOS, Google).
That seems like an odd example to me, since you're arguing desktop interfaces but those are all examples of mobile interfaces. Are you sure there was even a FOSS mobile interface available for those companies to use if they wanted? I think that also overlooks that companies may choose to make a new interface to differentiate their product.
> In the case of free software, there is a limited resource of people's time and skills. Adding more choices means spreading that resource more thinly - you basically make things worse by having more choices.
You can not assume that all the people working on 10 alternatives otherwise would work on one project together. That might work with your employees and work projects, but not with volunteers.
Having a 'choice' of GUI toolkits is going to lead to a shitty experience for everyone. As a user, now I have to see if a particular app works with my chosen toolkit, or if I have to deal with a substandard experience, or something that prevents me from using it properly. As a developer, now I have to decide which one I take, or spend twice as long and have twice as many bugs to use both.