Language Selection

English French German Italian Portuguese Spanish

Updates on Librem 5 Shipping and Development

Filed under
GNU
Linux
Gadgets
  • Librem 5 Birch’s 10kΩ Resistor Fun, Devices Prepping for Shipping

    Purism is working to solve no shortage of problems; making a phone with a never-before used CPU for mobile, to authoring an entire mobile OS, to designing the hardware from scratch. Not to forget forging a social purpose company, avoiding toxic funding, and solving digital civil rights by creating products that are convenient to use and look good. All because of your continued support.

    Many of our customers are interested in what goes on behind the scenes when making a phone, so we wanted to share for transparency the kinds of issues that can come up. For instance, with our Birch batch, we sent our hardware engineers the very first phones off of the line ahead of schedule so they could perform quality control testing. We discovered a 10kΩ resistor was missing from the PCBA!

  • The Librem 5 "Birch" Batch Was Missing A Resistor But Now Fixed

    Librem 5 "Birch" batch was supposed to be shipping from 29 October to 26 November. They are now preparing to start shipping this second iteration of the Librem 5 Linux smartphone after early units in this batch were missing a resistor.

    The missing resistor on the Librem 5 phone PCB led to a non-working USB port. It's not clear how the resistor ended up missing from this batch or if it had been in place for the Aspen batch or not.

  • Librem 5 October 2019 Software Update

    The Librem 5 software team were busy in October, improving power consumption and heat generation through kernel and driver changes. The team also refactored and improved integration between various apps by using libfolks as a common foundation, added new features to keyboard, Settings, Shell and Compositor and squashed many bugs.

  • Purism Outlines Librem 5 Software Work During October - Including Battery / Thermal

    Purism has finally published their blog post outlining the software work they accomplished during October on bringing up the Librem 5 smartphone.

    October's software efforts included kernel items like working to improve the battery life and reduce the heat output of the work-in-progress Librem 5 as well as maturing their user-space components.

More in Tux Machines

The Yocto Project 3.0 release

The Yocto Project recently announced its 3.0 release, maintaining the spring/fall cadence it has followed for the past nine years. As well as the expected updates, it contains new thinking on getting the best of two worlds: source builds and prebuilt binaries. This fits well into a landscape where reproducibility and software traceability, all the way through to device updates, are increasingly important to handle complex security issues. This update contains the usual things people have come to expect from a Yocto Project release, such as upgrades to the latest versions of many of the software components including GCC 9.2, glibc 2.30, and the 5.2 and 4.19 kernels. But there is more to it than that. One major development in this release was the addition of the ability to run the toolchain test suites. The project is proud of its ability to run builds of complete Linux software stacks for multiple architectures from source, boot them under QEMU, and run extensive software tests on them, all in around five hours. In that time we can now include tests for GCC, glibc, and binutils on each of the principal architectures. As a result, the test report for the release now has around two-million test results. Read more

Librem Boot Freedom and Purism Closes $2.5m Note Series

  • coreboot 4.11: Leaving No Librem Behind

    One of Purism’s core beliefs is to ensure that to the best of our ability, all new features, fixes, and improvements will be applied to all products, past and present.

  • Purism Closes $2.5m Note Series

    Purism as a Social Purpose Company (SPC) ensures the rights of humanity by creating products that fully respect people, and that mission has garnered a lot of attention and growth. One of the reasons Purism registered as an SPC was so that we could accept inbound investment without the risk that a toxic investor could force us to violate our values for profit (a common problem in C corporations). As a social purpose company Purism enshrines in its articles of incorporation that we must do what is good for society, therefore avoiding any and all toxic funding by virtue of the strictness of those articles. Funding growth—in addition to the triple-digit (yes that is over doubling) shipped revenue growth year-over-year since 2014 that Purism has been fortunate to see—can come in many forms, be that inventory financing, lines of credit, investment, and equity financing, to name a few.

Switching from Gnome to a tiling window manager

After having thought about it since "forever", I finally decided to switch to a tiling window manager. I went with sway since it runs on wayland and since it seems to be the recommended "wayland version of i3", a tiling window manager that many of my tech friends use ;) After a few days of using sway, I'm pretty sure that I won't switch back anytime soon. It feels super convenient to have all windows tiled on the screen and being able to rearrange and resize them easily with a few keyboard shortcuts. There's still some things that didn't work instantly, so I'll try to document them here in hope that it's useful to others. Read more

Mozilla: GFX, JavaScript, DeepSpeech and RFC Process

  • Mozilla GFX: moz://gfx newsletter #49

    By way of introduction, I invite you to read Markus’ excellent post on this blog about CoreAnimation integration yielding substantial improvements in power usage if you haven’t already. Next steps in this OS compositor integration saga include taking advantage CoreAnimation with WebRender’s picture caching infrastructure (rendering tiles directly into CoreAnimation surfaces), as well as rendering using a similar mechanism on Windows via DirectComposition surfaces. Markus, Glenn and Sotaro are making good progress on all of these fronts.

  • JSConf JP 2019 - Tokyo, Japan

    I do not step often in JavaScript conference. The language is not my cup of tea. I go through minified, obfuscated broken code every day for webcompat work. JavaScript switched from language that "makes Web page inaccessible and non performant" to "waste of energy, cpu, and nightmare to debug". But this last week-end, I decided to participate to JSConf JP 2019 and I had a good time. I met cool and passionate people. I also felt old. You will understand later why.

  • DeepSpeech 0.6: Mozilla’s Speech-to-Text Engine Gets Fast, Lean, and Ubiquitous

    The Machine Learning team at Mozilla continues work on DeepSpeech, an automatic speech recognition (ASR) engine which aims to make speech recognition technology and trained models openly available to developers. DeepSpeech is a deep learning-based ASR engine with a simple API. We also provide pre-trained English models. Our latest release, version v0.6, offers the highest quality, most feature-packed model so far. In this overview, we’ll show how DeepSpeech can transform your applications by enabling client-side, low-latency, and privacy-preserving speech recognition capabilities.

  • AiC: Improving the pre-RFC process

    I want to write about an idea that Josh Triplett and I have been iterating on to revamp the lang team RFC process. I have written a draft of an RFC already, but this blog post aims to introduce the idea and some of the motivations. The key idea of the RFC is formalize the steps leading up to an RFC, as well as to capture the lang team operations around project groups. The hope is that, if this process works well, it can apply to teams beyond the lang team as well. [...] In general, you can think of the RFC process as a kind of “funnel” with a number of stages. We’ve traditionally thought of the process as beginning at the point where an RFC with a complete design is opened, but of course the design process really begins much earlier. Moreover, a single bit of design can often span multiple RFCs, at least for complex features – moreover, at least in our current process, we often have changes to the design that occur during the implementation stage as well. This can sometimes be difficult to keep up with, even for lang-team members. This post describes a revision to the process that aims to “intercept” proposals at an earlier stage. It also proposes to create “project groups” for design work and a dedicated repository that can house documents. For smaller designs, these groups and repositories might be small and simple. But for larger designs, they offer a space to include a lot more in the way of design notes and other documents. Assuming we adopt this process, one of the things I think we should be working on is developing “best practices” around these repositories. For example, I think that for every non-trivial design decision, we should be creating a summary document that describes the pros/cons and the eventual decision (along with, potentially, comments from people who disagreed with that decision outlining their reasoning).