Librem 5 Phone Progress Report(puri.sm) |
Librem 5 Phone Progress Report(puri.sm) |
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.
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.
I am not sure how things will be for the i.MX8, but I certainly hope that they will continue this practice.
Seems like it is available
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.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.
Even stuff like sd card images for their dev board disappeared off their site more or less immediately after the acquisition.
I consider it to be slow and outdated.
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.
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.
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.
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
In my own words:
> or is that milestone for the market still a ways off?
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...
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.
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.
By not using Android, they automatically have something better.
Yeah good luck with that.
Free software, or "why do anything once when you can do it twice for twice the cost and half as good?"
Or you could just contribute to a project you find suitable, for whatever reason. Should be fun for everyone.
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.
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.
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.
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.
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...
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.
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.
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 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.
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.
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.
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.
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).
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.
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.