Hacker News new | past | comments | ask | show | jobs | submit login
Librem 5 Smartphone: Massive Progress, Exact CPU Selected, Shipping Adjustment (puri.sm)
264 points by fghtr 25 days ago | hide | past | web | favorite | 155 comments

Communications pro tip: if you've got bad news to report, just lead with the bad news, don't try to soften it by wrapping it in a bunch of unrelated positive-sounding stuff. All that does is leave the reader with a feeling of whiplash and a vague suspicion that you were hoping they'd miss the bad news inside all the fluffy packaging. It's better to just report the bad news up front so the reader can get past it and then you can both move on.

(How this advice applies to this post will be left as an exercise for the reader.)

And I'm sure there was an HN commenter waiting in the wings for the branch of reality where Purism did just that:

"Wow if their press release is this bleak, imagine how bad the reality is. Communications pro tip: explain up front why you missed the shipping date. Because after reading the I got the sense that they actually ran into some luck and didn't have to switch from their original hardware choice. Imagine what the shipping date would be if they had to move to the mini and essentially start all over."

"Communications pro tip: if you've got bad news to report, just lead with the bad news..."

If you've got a point to make, just make the point, and omit the useless "pro tip" preamble.

I have one pre ordered, I don't really consider that bad news. It's just an update about shipping. Hardware projects, even software projects are gonna move ship dates. The heating issue and video were more interesting to me, I glanced the shipping date as a good to know. Short of the project shutting down, I'm more interested in the progress.

What bad news are you talking about? The overheating that was solved by NXP releasing a new software stack for their chosen CPU?

That the ship date on the Librem 5 has been delayed (sorry, "adjusted") to Q3.

They wrote "the previous Q2 estimate is now confirmed for Q3 product shipping."

I haven't gone back to see what they said/estimated in the past, but going from an estimate to a ship date that's only off by 1 quarter seems acceptable to me.

It was moved from January 2019 (in the original kickstarter), to April, to Q2, and now finally to Q3.

That's a quite significant delay, but I personally don't mind as long as the final product arrives by the end of the year.

Yeah, that is a bit disappointing. I would probably be irritated if it went into Q4, but considering I wouldn't know where to begin if I were to build a phone from scratch, I can't complain... too loudly.

I answer here because I'm sure it's ommon amongst HN reader. If you think this :

>> I personally don't mind as long as the final product arrives by the end of the year.

Then it's useless to complaint that :

>> That's a quite significant delay, but

If freedom is at stake, then a few months later is of no importance.

>>If freedom is at stake, then a few months later is of no importance.

It didn't get delayed because of freedom though.

Not only is that acceptable, if they deliver a device that respects the user's software freedom, respects the user's privacy, leaves the user in control as much as they wish to pursue (with both software and user-serviceable hardware), and still deliver a device that can handle phone calls it will be far ahead of their competition. I'll be interested to see how far such an endeavor goes on those points.

That is how unique a privacy-centered tracker[1] is these days -- such a novelty when virtually all of the other comparable devices on the market routinely run proprietary code and lack the ability to physically disable connectivity completely under the user's control (and via hardware, not software).

[1] I call it a tracker because I believe that's a more honest name for what these devices do when they're enabled on wireless and phone networks -- they request their geolocation many times per minute (and, in so doing, allow others to track that location as well). Handling phone calls happens far less frequently.

It's still an estimate.

Do you have a source? They said "confirmed". Of course you could say everything is an estimate up until the point it actually happens.

Unless you have never paid attention to alternative phones / OSes over the past... twenty? years... of course it was delayed. These are insanely huge projects to undertake, even for the largest corporations in the world, so anyone trying to make a fresh mobile hardware / software experience will always take way longer than anyone wants to admit.

I guess this might be "whataboutism" but Tesla for example has missed manufacturing production targets regularly. Innovation isn't 100% predictable, and I think most people understand that.

They have attempted to weasel out of even saying that:

"the previous Q2 estimate is now confirmed for Q3 product shipping"

as if to say that the product, which isn't ready yet, has shipped in the future. Such mangling of logic doesn't inspire confidence in me that it will actually ship in Q3.

The first subheading in the post is 'Progress Report' and various details of progress in various areas are provided..

doesn't seem like spin to me.

I don't know is it really better? Obviously you'd prefer, and I think I would too, but the sort of thing you're complaining about might actually work. Apart from your personal feelings, is there anything else you are basing your claims on?

Someone who felt insecure about the matter decided this premature damage control was necessary. Why? I suppose we can only guess.

I don't see any damage control.

It's odd to me that people are nitpicking the negative news rather than the positive news.

They're making progress towards a privacy-respecting phone. I'm excited.

You can see this as damage control while still being excited about Purism's Librem 5 project. Heck, I am excited about the Librem 5 because it supports some ideals I find important. Despite seeing this news post as damage control, I still am excited about the Librem 5.

> if you've got bad news to report, just lead with the bad news, don't try to soften it by wrapping it in a bunch of unrelated positive-sounding stuff

Isn't this exactly what they did? The delay is in the title, you can't get anymore leading than that.

It's very unfortunate that this comment has been at the top of the thread for most of today. It has absolutely nothing to do with the Librem 5.

Yes. It is also needlessly condescending, while asserting a questionable opinion as if it were an established 'best practice.'

There is no substantial bad news in this article..

Also have a professional proofread your posts. 'Around the bend' is not the connotation you were looking for.

Q3 is in my opinion too optimistic. Based on the status of hardware (TBD) there is probably no chance to start shipping parts in Q3. The design should be locked today. Will they be able to source the tools, get reliable suppliers to source enough components in 3-4 months timline ? The rest of the time till Q3 should be used to ramp-up the production and sort out quality/production issues. Probably will be out of stock for at least till Q3/Q4 2020.

Good luck !

I wonder how many people pre-ordered the phone. It might be a small-enough order, that they don't need to reserve parts with any one supplier as any decent supplier could fill the order on short notice.

I'm hoping the experience and feedback they get from this product run will justify the economics for them to itterate and push out a new hardware version in the future.

Q3 ends in August, not in 3 months. I agree it's still optimistic but that looks doable.

February 2019 --> no design freeze, 3 to 4 months to source components and make tooling (very optimistic). May/July 2019 --> start of production. June/August 2019 --> debug, SOP, build stock, start shipping


I hope they are very determined, I like the product/idea but they started a very hard task.

I would rather take the most sold Android flagship device, reverse engineer the hardware and build a linux/bsd distro on top. Would not match their requirement (modem privacy etc.), but would take the really hard job of designing an up-to-date phone hardware.

Early adopters will pay a lot to get performance, good camera, battery life, screen quality. I will use it as a toy instead of a daily tool if too many compromises are made in the name of privacy.

Last day of September surely? So just over 7 months and 1 week from now.

It appears to be at least a 150ms lag from the motion of the finger to the scroll animation in the demo video.

Can someone who has a devkit do a detailed breakdown of the CPU usage during that 150ms? What processes are involved, who is waiting on whom, and how could it be improved?

That is absolutely brutal lag! It would feel like using a 10 year old phone with today's bloatware!

It's a devkit running in-development software, for all we know there's thousands of lines of logging being written somewhere while interacting with the display.

What's important to take away is that the devkit is stable enough to demo, the touchscreen, display, and backlight control are all working.

One one hand: Of course.

On the other hand: How good will it ever be? I'm really concerned about the UX.

Doesn't the ability to trivially iterate on the entire software stack running the device allay those concerns?

If a good chunk of the GNOME/free software community ends up with a librem5 in their pockets I think userspace progress should be pretty well covered.

That you can potentially read the code for the entire software stack doesn't mean you can trivially iterate on it.

For example, suppose the latency culprit were Firefox's CPU-based repainting. (I don't think it is as I can scroll just fine on my Chromebook with FF.) Changing Firefox to fill the scrolled area using the old Iphone checkerboard-style as someone mentioned above is non-trivial. There's nothing Gnome devs can do to make that happen, short of stopping work on Gnome, becoming FF devs, and submitting a large patch to FF.

On the other hand, having access to the entire software stack plus specs (and firmware?) for the entire phone definitely gives them a higher probability of cutting into that touch latency.

I would guess software rendering/compositing. Firefox on 4 core 1.3GHz ARMv7 with software rendering and no GPU acceleration on a FullHD monitor is qicker and has smoother scrolling than that devkit though. So who knows.

It just looks like unoptimized software.

How does that compare to an ARM Cortex-A17?

That's what I have in my rockchip chromebook running Firefox in a chroot with no GPU acceleration at all and it scrolls just fine. Moreoever there isn't the same amount of lag from touchpad to the start of the scroll event as there is in this demo.

And I'm so used to latency at this point that switching tabs in GPU-accelerated ChromeOS feels like it happens too soon. :)

I have no idea.

The Mesa driver is still under development.

I will buy this because it's the only device aligned with the principles of Free Software. I hope many here will do the same.

For those like me not willing to throw $600 there may be an option in the Pinephone [0] for $150. I expect that the Librem 5 will probably be better overall, but I also expect that for at least the first year both will be around beta level at best. With this in mind I'm more willing to give the cheaper option a chance, because it will not be my daily driver for some time.

Whatever will come from the next revision of both projects will probably be very interesting.

Either way they will share software and improvements in whole stack. So it's a win-win!

Also I'll probably buy the Pinebook Pro on the day it's available.

[0] https://forum.pine64.org/showthread.php?tid=7093&pid=43850#p...

What's the binary blob / firmware / accelerated gpu driver support story on the pine64 devices?

They say "mainline Linux". Lima the open source driver for Mali GPUs is mentioned. I don't know if it's already in Mesa. I would say WIP, but seems doable.

So the pinephone looks interesting, but genuinely asking, why is the only product lineup people link on a forum post? I would have figured they had a store or.something?

It's not yet released. It's maybe not as nice as a regular blog post, but forum they have, forum it is.

This looks awesome! I can't wait, been trying to buy a Pinebook but for some reason either they keep hitting my spam filter or I never hear back, just used my protonmail email to see if it's just that.

I preordered mine a few months ago :)

I love Purism, and have preordered a Librem 5, and this all sounds great, but I wish there was an update on the current state of the final hardware design.

It just seems like there's an awful lot of work left to do to get from a working devkit to a finished device shipped to users.

For me the librem 5 is to android what GNU Hurd is to linux. Why don't they do something more similar to what linux-libre is to linux to replace android rather than recreating the wheel.

AFAIK, android is open source, so why don't they just build on top of it while removing all non-free code/binary blobs from it.

Android is a bad operating system, for one. Second, it isn't, by any measure, a free one. Google has an iron grip over Android, OEMs are forbidden to produce phones that fork it, and most apps for Android won't run without Google's proprietary components.

Trying to build on Android is constantly following and fighting Google's changes. Purism is building on Linux, which is truly free from top to bottom.

> OEMs are forbidden to produce phones that fork it

Actually, OEMs are allowed to produce phones that fork it but they're forbidden from including gapps ( the google apps suit e.g play store, maps)

>most apps for Android won't run without Google's proprietary components

This isn't the case if you only use free software e.g. most of the apps on the fdroid main repo

This isn't true. OEMs have been forbidden from publishing "incompatible forks" of Android. Incompatible being: Not having Google's apps, which are required to pass the CTS. This is one of the reasons the EU levied it's record-breaking fine against Google for anticompetitive behavior. (It's likely EU MADA contracts have been revised to remove this requirement, but I wouldn't be surprised if they still enforce it elsewhere.)

F-Droid has a very tiny portion of apps, similar to as many as Purism itself will likely handle using it's own Linux-based system with an app store. Most common apps people expect require Google services on Android, as Google has let the open APIs languish and pushed everyone to use, for instance, Google Location Services, which is proprietary. Apps like Uber or Lyft, for instance, require Google. Hilariously, a lot of Microsoft's apps, such as Skype, require Google, despite being a competitor.

As long as Android's app library is primarily built on Google proprietary code, there's no point in bothering to maintain compatibility with a slow and sluggish, locked down Java-based OS.

>This isn't true. OEMs have been forbidden from publishing "incompatible forks" of Android.

From top of my head. Kindle fire, yandex.phone and most of phones for chinese market dont have gapps.

Google didn't allow to ship devices with gapps and without at the same time. You had to choose one or another.

HTC or Samsung aren't allowed to manufacture Kindle Fire devices per their Google contract

> This isn't true. OEMs have been forbidden from publishing "incompatible forks" of Android. Incompatible being: Not having Google's apps, which are required to pass the CTS.

I'm writing this message on a Fairphone 2 running an incompatible fork of Android that has all Google services removed. This fork is provided by the manufacturer of the phone.

That's not an incompatible fork; that's just AOSP with a few apps preinstalled. Likewise vendors like Samsung are able to add their own interfaces on top of Android, but that wouldn't do for Purism.

What's the definition of an incompatible fork then?

I'm not completely sure, but I think it's when you have to actually modify Android code, rather than changing some default settings - i.e. a fork of Android, rather than a distro.

Talking about the Fairphone, is there any news whatsoever about the Fairphone 3?

No, I think they're still mainly focused on the 2. The latest announcement was [1]:

> So, we’re excited to announce that nearly three years after the introduction of the Fairphone 2, we’re not releasing a new model just yet. Instead, we’re aiming to extend the life cycle of the phone as much as we can.

[1] https://www.fairphone.com/en/2018/05/08/keeping-your-phone-l...

They’re not allowed to use GApps on any of their devices if they ship a fork on one device, I thought. That’s a massive barrier.

> Actually, OEMs are allowed to produce phones that fork it but they're forbidden from including gapps ( the google apps suit e.g play store, maps)

how do you account for pretty much every chinese domestic version of android, which doesn't use google services or the play store, because they're blocked by the GFW? For instance the Chinese version of OnePlus' oxygenOS uses the domestic app stores.

Simple: Google isn't really worried about non-Google phones being sold in China, because they don't operate there. I expect this would change if Google did manage to re-enter the Chinese market.

None of this really addresses the question. Despite all this, its still a better option than starting from scratch with no hardware.

The problem is it's "not a better option", because the outcome is poorer. There are plenty of people offering hacked up versions of Android you can put on Android hardware. If you want that, it exists. Purism is aiming higher, and creating something we need to replace Android, not just leech off of it.

>For me the librem 5 is to android what GNU Hurd is to linux

I'm assuming you're talking about pureos, the default OS shipped with librem 5 They're not reinventing the wheel, it's a debian-based distro that has existed for quite some time and that is endorsed by the FSF If I'm not mistaken, purism made the OS specifically for their laptop lineup

>Why don't they do something more similar to what linux-libre is to linux to replace android

This project already exists, it is called Replicant[0]

>AFAIK, android is open source, so why don't they just build on top of it

There are many, many custom ROMs that do exactly that. But this doesn't hide the fact that android has severe problems like requiring huge system resources to build it (>100GB of disk space, 16GB of RAM etc.) Besides Google is working on another OS called fuchsia that's supposedly going to replace both android and chromeOS and it's not based on the Linux kernel thus it's better for the sake of choice to have some linux-based alternatives. The librem 5 isn't the first or the only effort to get non-android linux on smartphones, there's also most notably PostmarketOS[1]

For more arguments on why android sucks compared to other linux-based alternatives, check out https://postmarketos.org/static/slides/2018-akademy/#18

[0]: https://replicant.us/ [1]: https://postmarketos.org/

Variety is a good thing. Even if the alternative created isn't strictly better, it can brings new ideas to table and push innovation forward with alternative approaches.

I'm happy they're creating an alternative OS to Android and hope that it really takes off. Even if it is never strictly better than Android, it at least gives us options.

This is almost an exact parallel to the browser industry. I think most of us techies are in the boat that the existence of Firefox as a separate browser rendering engine from Chrome is a good thing for similar reasons, regardless of which can be argued to be functionally better.

There's already Replicant, Lineage, Copperhead, etc. The thing you're asking for has existed for a long time.

Yes, the problem is there is a lack of proper hardware integration. Cameras in particular don’t work well.

I use Lineage on a supported device and everything seems to work perfectly. My camera is blacktaped, but it did work fine when I tested once.

That would make it completely uninteresting for me. I can already run Replicant on GTA04.

Oh my God... That user interface is trash. It's so laggy!

As someone who designed a UI graphics stack almost from scratch, making a non-laggy UI has to be done from day 1, working with the EE's all the way up to the top most software stack.

It is hard, and any misteps along the way can doom everything. A single bus without enough bandwidth, not reserving enough CPU time for UI code, to not ensuring end to end performance of the touch system, any mistake and the UI will be sub-par.

The UX also needs to be informed by the hardware capabilities. Even simple things like whitespace around elements being scrolled can reduce HW load.

Honestly the animations don't look too bad, their touch layer however, it looks rather questionable. Doing touch right is a difficult task, it has taken modern smartphone platforms years to get latency down to where it is just barely visible. Now days early gesture recognition involves some amount of ML training that will a touch gesture recognizer that runs on the device, the recognizer is customized per model of touch panel/sensors. (Alternatively, one piece chips that do all of this for you exist, popping out already recognized gestures, they may or may not give better results, I haven't poked around in this space for a few years.)

On top of that, the touch panel needs to be running at a high enough refresh rate, and the entire UI needs to prioritize touch events over almost everything else! Audio Output > Video Playback > Touch Events == UI Updates > Rest of the world

Last system I worked on, touch events could be delivered to the UI up until the moment painting started, painting was capped at ~20ms (IIRC), running at 30fps.

The worst edge case saw 2 frames of latency before the UI responded. Average was around 1 frame of latency.

The other thing I'd have recommended they do for a v1 product is v-sync at 30FPS, and base everything off of that. A smooth 30fps is better than dropping frames at 60fps.

Treat it like a video game, you have a CPU budget in which everything must get done. The rest of the system must be running at a low enough CPU load that the render target can be hit every single frame.

But again, this all has to be started at day 1.

They didn't start at day 1 so here they are.

Wrt scrolling-- could they queue the repaints until the scroll reaches its final destination?

I could live with a phone that reacts "instantly" and scrolls with the animation I expect while showing me transient "placeholder" content.

If you remember early phone browsers, they did the checkerboard scroll thing.

Giving instant feedback to users is crucial. The repaint of content can wait!

The pull down gesture in the video looks like it triggers on touch up. Reminds me of the first gesture handling system I ever wrote. :)

I gave up on it and let someone who knew what they were doing rewrite it from scratch!

Right after the checkerboard (or from the start with Apple) came the rasterized content. That worked (and still works) pretty well.

I'm sure the amount of work that went into it must be huge (creating something like that from scratch is indeed a daunting task) but I wonder if this video really does them any service, your average human being is just going to see a crappy and laggy interface that will remind them of bootleg smartphones from 10 years ago.

On the technical side of things I wonder if the lag is due to the lack of hardware acceleration or if it's because of a very unoptimized early build. If it's the former it'll fix itself when they integrate the GPU, if it's the latter then it's slightly more worrying from a code quality perspective.

Beyond that the interface looks like pre-alpha status (most of the widgets look like placeholders, glitches everywhere etc...) and they want to ship that in 6 months? I hope that early PureOS adopters are ready for a very rough launch, this is going to be quite a ride...

This will be the downfall of this device. The kind of work required to provide a UI experience that even remotely resembles that of modern smartphones is a monumental task. It's one of the reasons desktop linux lags so far behind: the folks who have the time, interest and ability to do this work are not interested in using the platform.

> It's one of the reasons desktop linux lags so far behind

Umm, what? Linux desktop is considered by far to be the most efficient and responsive desktop user interfaces there are. We have DEs that run on 10 year old hardware with no delay and even tilling window managers that are as efficient as you could ever get with todays hardware.

Sure they are not average Joe friendly but to attack it's efficiency and responsiveness is preposterous.

If they are smart, they will have their margins adjusted to support a niche device. There are a few people (including myself) that are willing to sacrifice a beautiful UI for all the good things that go along with a user-respecting OS.

Also, they have a lot of time. I have made a few UI's myself back in the DOS days, before they were always readily available. First I would make it work, then I would make it look good.

> It's one of the reasons desktop linux lags so far behind

Behind what? I've been a daily linux user for the last decade or so, I've always felt the desktop experience was superior to to Windows and Mac. At least Gnome 2/3 has been.

I agree that the device looks like trash. But what's wrong with desktop linux? We have compositors, hardware acceleration from nvidia and AMD, and WMs that are just as good, if not better, than windows. What more could you want?

>What more could you want?

Consistent UI, consistent configuration schemes, working suspend-resume, reliable WiFi, reliable auto mount of USB storage, and easy file sharing over LAN for starters.

None of these things was I able to achieve on my ThinkPad even 3 years ago when I last gave Linux a try.

I mean, I’ve been using ThinkPads for years and have always ran Linux on them, and personally haven’t had any problems with them. ACPI, touchpad, screen, audio buttons, all worked out of the box or were just a few package installs away.I don’t like auto-mounting of drives, but I know it’s pretty easy to setup with hotplug. WiFi drivers are very good at this point, supporting pretty much any WiFi cards in any laptops. File sharing over LAN can easily done with Samba or SSHFS.

Linux has pretty good drivers at this point, and in my experience, often better and more complete than Windows.

Not saying you’re lying or incompetent or anything, but I do think you had a very atypical. Maybe you’re not familiar with Linux? Not trying to put you down, but maybe I find that Linux works Because I’ve been using it for over 15 years at this point.

I'm sure I could have got most of those things working by fiddling with fuse or xorg.conf or some other silliness but I don't count that as "working".

The number of times I've had network manager simply refuse to connect after opening the laptop lid makes me think we're just living in parallel universes.

I don’t use a network manager, and I don’t run a DE, I just have a simple window manager and the command line. Btw, I use Arch Linux which is of much higher quality than Ubuntu or whatever.

If we were talking about OpenBSD I would agree with you, but I can promise you all those are functional across many laptops and desktops I've used.

> Consistent UI, consistent configuration schemes

Have you used Windows?

> easy file sharing over LAN

Every install of Ubuntu for years has come with a "public" folder for easy LAN sharing (Samba). https://xkcd.com/949/

> It's one of the reasons desktop linux lags so far behind

You really can' fault desktop linux at least performance-wise. I have ~3ms input latency in vim on xterm. Good luck beating that on windows, or even a mac.

The reason linux on desktop lags behind is simple - 99% of desktops and laptops come pre-installed with either windows or macos.

Personally, I couldn't care less about animation. Remember when Windows used to only show a frame when you were dragging a window around or resizing it? That was fine.

The lag in that video is about the same as my cheap Moto G phone. Doesn't bother me in the slightest. I just want a phone that I can trust isn't spying on me 24x7.

I agree; I think this thread and a couple similar threads (basically repeating the same objection) are vastly overrated. Not spying + hardware and software under user control is far more important than whatever someone considers lagging video or anything that animates, particularly for a device people insist on calling "phones". I might prefer no animated GUI.

Yes. They were quite clear that the software stack is pre-beta quality at best.

Video looks like the interface is choppy. Debug build or something else?

I have a Librem5 devkit. I think that a lot of this comes down to the graphics driver, which Guido is working hard on improving. I can also assure you that there'll be a variety of interfaces available for the Librem5 with varying degrees of complexitude for you to choose from.

This is strange. While MNT Reform still uses the i.MX6QP which is much older, I haven't seen such bad UI performance on it. I've seen consistently better perf from Qt apps or SDL/GL stuff than Gnome on this platform, so I hope this won't become a problem.

Edit: What I wanted to say is that much better UI perf is _definitely_ possible on this chip.

Isn't the promise of gtk4 GPU-acceleration? Since that's still a WIP I presume the stack from the video is gtk3, so it's all being CPU-rendered except hopefully the compositing in phosh at least.

It’s apparently a pre-beta build.

I wish "compact" version of Librem 5 Smartphone existed: 4.5" screen, slower CPU, half or even quarter of storage. 200$ or lower price would attract more users and developers.

The BOM isn't likely the driving factor in the price, but rather the small number (relatively speaking) of units they'll sell. They have to amortize the cost of all the design and engineering over however many units they end up selling which is probably going to dominate the costs. Not just the labor for the finished product but every blind alley they've gone down, every failed prototype board etc. Then they have to mark the whole thing up (i.e. profit margin) to make it all worthwhile and allow them to do version 2. Version 2 or 3 is probably when they can start thinking about driving down costs.

For some interesting insight in this, Fairphone has published the cost breakdown of their phone [1]. It's quite a bit more expensive than similar phones, but only about €5 of that is justified by the "fair" part of the phone - most of it is just source materials being more expensive due to their small scale.

[1] https://www.fairphone.com/en/2015/09/09/cost-breakdown-of-th...

Thanks for posting this and it is quite informative re: BOM pricing. I suspect that Librem is having to do quite a bit more work on the software side than the Fairphone as their development costs appear pretty minuscule. Even so, based on this breakdown it's probably not as big a piece of the final price as I had guesstimated.

The best you can count on is the Pinephone [0]: $150, approx. 165x77mm (bigger than my Nexus 5x, so bigger than 5.2", but we all have lost here).

[0] https://forum.pine64.org/showthread.php?tid=7093&pid=43850#p...

I'm really excited about this. I'm not wealthy enough to preorder but I would love to have this as my next phone.

I wish Librem would let us vote on the features of the phone we wanted. I think they'd have more of a chance of success if they worked towards things that were most important to users instead of their assumptions.

For example, i've been saying it for years, but I would buy a phone with nothing but an e-ink touch screen in an instant. The only thing it wouldn't be suited for is movies, and phones aren't really suited for that anyways.

And that's exactly why they aren't taking votes on features. Your e-ink display would be a deal killer for people who consider video crucial. If you polled 1000 people for their ideal phone, you'd probably end up with 800 different models needed to satisfy them all. If you went with a majority wins voting system, most would be unhappy with the results. Design by committee rarely ends well.

An e-ink display isn't a very good example of a feature they're overlooking without a democratic process.

I use an e-reader every day and I'd say half my friends and family don't even understand why you'd want to read on one -- they just read on their phones/tablets.

This is very true. I have family members that just read on their phones while sitting on the beach, and when I explain to them why my kindle is better suited for the task they don't seem to understand why. "I just invert the colors and it makes it just like that." They say.

You mean something like the Light Phone?

Wow it exists! Might pick one up soon

They're sold out.

Q3 2019 still seems way too optimistic to me.

Even if they really know what they are doing, that sounds like a great way to create a lot of painful technical debt that will affect both end-UX and app devs. One one hand, maybe this is also a great way to get something in the hands of users, learn, and get it right in the next generation. But it's hard to go back on API design.

The software will (I believe) be a rolling release, so they only really have to get the hardware right before shipping.

What API design is there, beyond "Linux apps, probably GNOME with libhandy"?

> The software will (I believe) be a rolling release, so they only really have to get the hardware right before shipping.

PureOS is based on Debian testing so it is a RR. Aside of hardware there is a problem with baseband firmware because there is no way to change it after phones are built without attaching to the chip itself.

> What API design is there, beyond "Linux apps, probably GNOME with libhandy"?

None. Every internal part is supported in mainline kernel, the only thing not there is the library for calls, UI has 3 options as of yet.

The baseband they're using is PLS8, which offers firmware updates via its USB interface.

"Library for calls" is there - three options actually. ModemManager, oFono and freesmartphone.org. I've personally contributed PHS8 support to the latter a few years ago when preparing for a different PLS8-based project ;)

No RAM spec provided, also is it possible to connect an external display?

It's one of the core features and they have monitor and keyboard kits for preorder already.


RAM: 3 GB minimum (subject to change)


Does anyone here have one of their laptops? How does the hardware compare to similarly priced products from mainstream vendors?

It's quite expensive for the specs, but it's a niche product. You're looking at a 1.5x-2x markup for hardware prices. What you get is mainly a new laptop that can run coreboot. Other than chromebooks, there aren't any other devices that do that right now.

I don't have one, but I've been watching them for a while. They tend to lag a bit on new hardware; for example they just announced new laptops with 7th-gen Intel CPUs, which are not the latest (9th-gen is expected this year). But they need extra time to get coreboot running on the system, remove as much of the Intel ME as they can, etc. So they're always going to be a little behind and won't have the most recent hardware. If you're ok with that tradeoff, and paying higher prices for it (since it's a fairly niche product), then they seem to be a good deal.

What are their plans for application development? Will developers be expected to write their apps in C/GObject?

Essentially, it's GNOME. The shell is phosh instead of the GNOME Shell, but you can see from the video that the look and feel is intended to match GNOME Shell.

The default apps will be GNOME apps. You should be able to run other Linux apps just as easily, assuming they fit the touchscreen and CPU architecture.

Even if they don't fit the touchscreen you can run the thing as a desktop machine with a monitor. At that point it's just an ARM linux box.

> At that point it's just an ARM linux box.

Fondly remembers Nokia N900

GObject have bindings for virtually every language. (gobject bindings can mostly be autogenerated so it will be easy to provide bindings for librem specific libraries too)

> Will developers be expected to write their apps in C/GObject?

I think this will be the "default" and it's the thing I'm mostly excited about. I've been prototyping an app and it's a small simple c file, the android equivalent would be dozens of xml files and require an IDE.

There are a lot of bindings for gtk though, and they do like to push their xml gui builder abomination.

I imagine you'll be able to write apps in Qt/QML[1], which already provides a UI optimised for a phone[2].

[1] Available in Debian, and therefore by extension, PureOS [2] SailfishOS, the other mobile Linux OS, uses Qt/QML for its apps

Is there any list of apps expected to be available for PureOS soon after launch?

The closest I found was a few logos in the HTML5 Apps section of the product page[1]. Those look good, but I'm wondering what we can expect in terms of GPS/navigation and also ride-sharing services like Lyft.

[1] https://puri.sm/products/librem-5/

It runs FSF's guidelines-compatible Debian fork so it could run any Linux app with arm64 support + there is a project called Anbox which runs Android apps in containers. It has some GPS support via qemu virtual device but I don't know if it supports the real trackers.

It's possible to run Android apps in Linux.

I'm a fan of Purism for what they do, even though I don't own any of their products yet.

But how do they even justify this sentence, given that CPU design and fabrication are full of compromises?

"The i.MX8M Quad is the most powerful CPU that has both a good operating temperature and a good battery life."

That statement acknowledges the compromises within itself? There's also the unstated "freedom", "availability" and "documentation" constraints.

I think the worst of the delay in the browser really comes from actually scrolling the content instead of rasterizing beforehand, like most smartphones tend to do. The rest of the UI seems decently smooth.

It also seems to be running GNOME, which even manages to lag on my upper mid range laptop.

Wonder if they considered Sailfish? [0] And if they rejected, why?

Agree with other posters that building both hardware and UX from scratch is incredibly ambitious. Jolla tried to do the same and it almost killed them. They're still alive, now focused on Sailfish licensing (including, it would seem, the new Psion-like Gemini pda[1]). But they've exited the hardware business.

Both Purism + Jolla seem aligned on values: pro-privacy and open source. From an outsider's point of view, they'd seem like a good match.

Either way I wish Purism the best of luck. If they do deliver a phone that both respects privacy and is properly usable as a daily driver I won't hesitate.

[As a side note, looks like the Gemini is shipping now. Great result for them]

[0]: https://jolla.com/

[1]: https://store.planetcom.co.uk/collections/gemini-pda

> Both Purism + Jolla seem aligned on values: pro-privacy

Even if Jolla says they are pro-privacy, they are nowhere near as pro-privacy as Purism. Jolla happily licenses their OS to makers of bog-standard mobile phone hardware that use binary blobs and where the CPU and cellular modem share memory. Purism, on the other hand, aimed from the start at having the cellular modem separate from the rest of the system, and at offering hardware kill switches for the microphone and connectivity.

Also, a good amount of Jolla’s OS is closed-source.

Have something changed? Last time I checked Sailfish wasn't open source project. Almost all UI was closed source.

"5.5" - 5.7" HD display" - they've removed the resolution again. I wish they'd just call it a 720p display.

Hope they dont fall into the trap of pleasing everyone. People who are complaining about polish / fit / finish are likely to not switch to the first few iterations of this device anyway. I just hope that they actually ship (unlike Jolla), and dont end up delaying too much, while keeping the device mostly free(as in freedom).

People preorder something like this with missing specs? I like the philosophy of it but I'm not handing over $600+ without knowing all the hardware info. I'm not interested if all the specs don't exceed those of my Pixel 2, which will be at least two years old when the Librem 5 is released.

Yes, I did. And I fully expected the schedule to slip. And I fully expect it to slip again. (Hardware is hard, been there, collected the scars.) And I fully expect the software to be glitchy. And I fully expect the user experience to underwhelm.

So why preorder? Because I want to support the mission of a security-first, user-freedom-first, phone. I want to support the idea of a Linux phone. Unless those of us that want something like this, and can afford to front $600 to help the first iteration happen, do so, there will never be a second iteration.

Yes, I am one of them. They are not a fly-by-night company with a random Kickstarter. Of course it was a calculated risk, but it was worth it at the time, and it seems to be panning out in my favor. If you consider everything that people preorder on Kickstarter without due diligence, it would stand to reason there are some people that do due diligence and preorder something like this.

If risk/reward ratio is too high you could wait when they'd ship them and order one for yourself, I don't think they'd stop the production afterwards but the price would be the same due to the batch size.

I can tell you right now that traditional specs will be worse, but freedom specs will be better e.g. runs mainline Linux, hardware baseband isolation, kill switches etc.

I don't care one bit about the specs. The Librem 5 has so much more to offer.

> Front Camera TBD > Back Camera TBD

This isn't good.

When you compare this to what Samsung just announced yesterday it's so hard to justify this device. I want to use it, but I don't think I could deal with the sluggishness of the UI (if that is actually an issue at launch), what will presumably be a poor build quality, and all of the other bugs that will likely exist.

I need my phone to just work. I love the Linux desktop, but I just don't see how they can get a new mobile platform able to compete with iOS or Android.

> I need my phone to just work. I love the Linux desktop, but I just don't see how they can get a new mobile platform able to compete with iOS or Android.

Who says they need to compete with them at all? This isn't a big company relying on VC money that it needs to pay off, this is a small team that raised money from backers.

They need to provide a viable alternative for those of us that give enough of a fuck about privacy and... that's it. As long as they have a demand to keep up the supply, the product is successful. Their target group is willing to make some sacrifices for sure.

Not every company aims to be a trillion-dollar company and absolutely dominate its sector, and that's not a bad thing.

If they can do it, then it's great! I'm just skeptical that we will see a second iteration of this device. I hope they do succeed! I want to be able to use a device like this someday, but it's not ready for me yet. I hope you enjoy it!

It hasn't shipped yet, so that's good.

It's not ready for anyone, yet.

What is the relation with the new Samsung phones ? Apart that both are smartphones ?

They were just revealed yesterday, so I thought it was fitting. It's definitely the most no compromise phone feature wise too.

Well reboots are good sometimes. This phone is also uncompromising (in theory) on some aspects.

If an existing iOS or Android phone is even a viable option for you, you're not the target market.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact