The cell modem chosen [0] is a bit disappointing. With support for only 4 LTE bands (2/4/5/17), its going to work less-than-ideally on every US carrier. Zero sub-GHz bands are supported, meaning lousy indoor and rural coverage.
Good LTE band support is something you might take for granted if you are used to using flagship Android or iOS devices.
I'm really happy they got phone support working at all, this is the biggest stumbling blocks with alternative phones. Everyone can get a tablet working but few have got the phone/4g functionality.
At the moment I'm wishing I'd bought the dev kit, I'd be happy with it slapped into a 3D printed case as my phone.
This sounds to be just for the development board, right? My understanding was that they were aiming to use a USB interface or something for the radio connectivity so that you could get a radio that suited your needs hopefully, and was certified and approved independent of the phone itself.
The original crowdfunding page specified "We aim to support 3G and 4G for the most common international frequency bands and carriers, with an interchangeable module. Exact specifications will follow as we are evaluating the data+voice modems that will be used." and "Separate mobile baseband" as a key tech spec on https://puri.sm/shop/librem-5/
I know that, for instance, Verizon has certified a variety of modules to work on it's network, and a phone (or laptop) that uses that module need not be certified by Verizon to work on their network, for instance. Every Verizon compatible laptop doesn't get certified, it just tends to use one of a handful of Sierra Wireless LTE modems which are. Similarly, my understanding (and hope) is that Purism is going to support dropping in various LTE modems so that people can get support for the networks they need.
Mildly disappointing, if that. I would gladly give up optimal LTE performance for everything else this device promises (running legitimate Linux distros, physical sep. baseband/camera/etc).
I really hope the final product will support more bands! I’ve been putting off buying an Android phone since I heard about the Librem 5 and this will be a deal breaker.
I just ordered one of these last week. I'm stoked to have a phone that I control. It will be amazing as a dev to just write an application, scp it over, and have it draining my battery in no time.
> We’re still working with our potential manufacturer of the development boards to review the schematic developed by the Librem 5 hardware engineers and make suggested changes.
Last update we had was that the boards would ship August 2018. I'm wondering if they're still aiming to ship them this month.
Since the beginning, they have been rather heavily underestimating delays and potential problems for each step on the hardware side.
In this case, if we consider that it is still the 1st half of August, so a lot of companies are closed or on reduced activity with reduced personnel; that after the schematic is finished, the PCB has to be drawn, the PCB has to be built (that's quick), the PCB has to be populated with chips (it can be quick... if everything is in order, otherwise add a small delay); that the first boards have to undergo some minimal amount of testing before the full run is produced and shipped to customers to ensure that at least its major parts are working kind of OK ; that there was no prototype board before this run (IIRC) ; that if this testing does not go well, major issues will have to be found and corrected before shipping, possibly implying ditching the existing PCBs, correcting the schematics, rerouting the corresponding PCB parts, and starting a new batch of boards... I bet there is very little hope they keep their promise.
And globally, considering that their reports are always 95% about software and 5% about hardware which seems to be more and more outsourced, we can say it is one more time the case of a bunch of software developers and software designers underestimating the amount of work (people, time, and the cost of iterations in hardware compared to software) and the amount of experience needed to produce the hardware side. As it has already happened many, many times in similar projects, with similar goals, with similar people involved.
Definitely share your opinion. Every picture of every piece of hardware they have shared thus far has been off the shelf consumer boards and screens. I was at least expecting a phone prototype main board at this point.
I expect them to ship some 'development boards' eventually, but my hopes for an actual phone are seriously diminished.
I don't say this to put them down, I hope they succeed, but I am 100% skeptical of any crowd funded hardware device.
They announced recently that they will be about a month late for the dev kit on their Matrix channel. Not surprising, and if they are only one month late I would consider them on time :)
> The UI of Calls has made some strides to look like the mockups from the design team. Below you can see the implementation (left) next to the mockup (right).
Is there a reason the programmers couldn't just implement the design as given? They added a bunch of useless borders and gradients, and removed all the labels. This looks exactly like the Parable of the Concept Car: https://daringfireball.net/linked/2008/08/12/concept-cars
The outer border and shadow appears to be from the default window decorations, which I expect they'll remove in some non-app-specific method. The top bar is the standard window headerbar, which they'll probably remove as well, at least for the dialer screen. The gradients are part of the default GTK theme. Not sure about the button labels, as it's been a while since I touched GTK development - there may not be an easy way to add labels under an image in a button.
EDIT: designs almost always look nicer than the first pass at implementing them, as designers can put pixels wherever they want to make things look pretty, while developers are constrained by the technical restrictions of the frameworks being used.
> Is there a reason the programmers couldn't just implement the design as given? They added a bunch of useless borders and gradients, and removed all the labels.
Pretty sure they just used the existing GTK theme, the didn't add anything. If you're worried about how it looks you can install you're own theme and have it apply in every app.
I'm concerned about the combination of size and resolution:
Display: an LCD display that is 5.7″ at 720×1440 pixels
The size should be smaller, while the resolution should be probably higher.
They mention, that such resolution is caused by heat dissipation issues[1] (since they by design don't use integrated SoC). May be size is also caused by separate chips?
Regarding the browser, it would be nice to have something based on Servo, rather than Epiphany. Are there good mobile browsers that use Servo embedding and can work on normal Linux?
About a Servo based browser: I plan to get my in progress-but-really-unusable-so-far Servo based phone UI (https://github.com/fabricedesre/servonk) working on the Librem 5. But honestly it's frustrating to see how little general web compat work is happening in Servo right now, where most of the team effort is directed to VR/AR use cases. I'm not blaming the team, but it's hard to believe in Servo outside of niche use cases right now.
Thanks for the link, that's very interesting and I hope it will be usable!
Why is Servo team not focused on general Web compatibility? That sounds like a major must do before anything else. Don't Mozilla plan to replace Gecko in Firefox with WebRender from Servo anyway, so how can they achieve it without good Web compatibility?
That's probably why they're focusing on the VR/AR stuff, to put that into firefox once it's ready since it'll be a new set of features entirely and not have any legacy version they need to maintain bug compatibility with too.
WebRender is not a replacement for Gecko, it is replacement for the rendering subsystem of Gecko. As GP said they are replacing individual subsystems of FF/Gecko one at a time from Servo components. So the fact that Servo as a whole has major compatibility problems has no relevance to using Servo's rendering code in Firefox, as long as the rendering code itself works properly (which has obviously been a major focus of Mozilla for the past year or so).
All this being said, I won't be shocked if the end result of all of this work leads to Gecko being entirely replaced in a Ship of Theseus manner eventually. It'd let them get almost all the benefit of actually wholesale replacing it (they'll still end up with technical debt from the legacy interfaces) but they'll be able to get the benefits from it sooner than having to wait and essentially halt all other development to be able to bring it into place.
May be. Nexus 5 which is almost 5 years old now, is 4.95" / 1080 x 1920. It runs various mobile Linuxes, and I was thinking to replace it with Librem 5, but going to bigger size and lower resolution is a question.
It's not the end of the world, but I was subconsciously expecting 1080p or thereabouts. I agree, that resolution in 2018, especially for a 5.7" panel feels low. I had both the Nexus 5 and 5x that were 1080p.
It started out as 5" and that was large. This was in a world in which phones had bezels, but I am not quite confident they can get their bezels small enough to make the 5.7" not ridiculous.
That's plenty of room with a decent window manager. I had a small laptop with that resolution for most of last year and was comfortable even without external monitors.
Could it be that heating issues are also because of the choice of their UI toolkit?
It looked like they're writing their apps in gtk, using the CPU for any animation and rendering - as opposed to some OpenGL solution that would do this much more efficiently on the GPU..
For reference, Rendering a simple, animated bar chart using QtQuick canvas, at 720p@60fps maxed out our iMX6 cpus - while doing the same on the GPU took like 30% cpu and the result was much more smooth.
UI toolkit choice puzzles me. They should have used Qt or even partnered with Plasma Mobile to begin with. Regarding the GPU, they are supposedly working with Mesa/etnaviv, but it's in the very raw state so far. I don't think it even supports OpenGL 3.1 yet. And big question is about power management side of things.
I pretty much agree with your recommendations, but they didn't pick GTK+ per se — they wanted GNOME on a phone, so they picked GNOME and use its toolkit.
The (ever increasing) inflexibility, or perhaps more politely, extremely focused opinionatedness, of Gnome shell makes this seem an unfortunate choice for a project requiring so much adaptation and innovation.
Purism has always seemed a bit to me like snake oil. Isn't the baseband still totally opaque? Aren't there going to be blobs? Looks like they're going to be using a loophole to get the RYF certification:
I don't think we share the same definition of loophole. The co-processor is something the RYF certification allows exactly because binary blobs are often necessary. It's voluntary. The librem isn't shady for using it, that's what the exception is for! It allows running the blob in a jailed environment, thus ensuring the user's privacy is respected.
Which other smartphone runs mainline Linux and Debian? That's what Librem 5 is announced to be able to. Is it perfect? No. But it is not just snake oil.
It's possible with anbox, but it requires building the kernel with a non-standard config to enable the Binder protocol. Other than that, it works great though! Take a look: https://anbox.io/
They did actually include this as a stretch goal, bit it was something silly like a 6 times multiple of the funding point. Would something like this be difficult to adapt to different devices?
Making it work is pretty easy. Got some friends who got it to work on a GNU/Linux running on the Nintendo Switch. The trouble is to properly integrate it into your device. You'd want android apps to access your contacts, things like that. Those are certainly complicated to setup.
> some research was done on TrustZone, TPM and other related topics. There have also been some internal discussions about tamper-resistant boot, Heads, and alternate USB modes for video output. So we’re really starting to think hard about implementing security measures for the Librem 5.
Isn't it very late to start researching and thinking about those things? My general instinct is that security needs to be designed and built in from the start - what about the components they've already developed, and how they integrate with each other? - including as part of the development process and even as part of the culture.
I've thought that getting Xamarin Forms working on this thing could be interesting for jump-starting app development. There's already GTK support for XF[0][1].
What about the laptops? What happened to their ambition to free the entire chipset? They seem to have switched focus to phones; that's all they post about now.
I saw the mention in the post about video out. I really do hope they can do something with this, as I plan on ultimately replacing my carplay headunit with something homegrown to able utilize the phone as much as I can.
Good LTE band support is something you might take for granted if you are used to using flagship Android or iOS devices.
[0] http://simcomm2m.com/En/module/detail.aspx?id=84