Librem 5 Smartphone: Massive Progress, Exact CPU Selected, Shipping Adjustment
puri.sm
puri.sm
(How this advice applies to this post will be left as an exercise for the reader.)
"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."
If you've got a point to make, just make the point, and omit the useless "pro tip" preamble.
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.
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.
>> 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.
It didn't get delayed because of freedom though.
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.
"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.
doesn't seem like spin to me.
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.
Isn't this exactly what they did? The delay is in the title, you can't get anymore leading than that.
Good luck !
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.
Optimistic.
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.
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?
What's important to take away is that the devkit is stable enough to demo, the touchscreen, display, and backlight control are all working.
On the other hand: How good will it ever be? I'm really concerned about the UX.
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.
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.
It just looks like unoptimized software.
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. :)
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...
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.
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.
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.
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
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.
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.
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.
> 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...
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.
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
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.
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.
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.
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!
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...
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.
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.
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.
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.
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.
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.
> 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/
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.
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.
Edit: What I wanted to say is that much better UI perf is _definitely_ possible on this chip.
[1] https://www.fairphone.com/en/2015/09/09/cost-breakdown-of-th...
[0] https://forum.pine64.org/showthread.php?tid=7093&pid=43850#p...
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.
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.
What API design is there, beyond "Linux apps, probably GNOME with libhandy"?
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.
"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 ;)
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.
Fondly remembers Nokia N900
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.
[1] Available in Debian, and therefore by extension, PureOS [2] SailfishOS, the other mobile Linux OS, uses Qt/QML for its apps
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.
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."
It also seems to be running GNOME, which even manages to lag on my upper mid range laptop.
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/
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.
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.
This isn't good.
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.
It's not ready for anyone, yet.