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."
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.
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.
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.
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.
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.
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?
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.
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.
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.
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
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.
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?
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.
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.
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. :)
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.
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?
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 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.
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. 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.
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.
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.
> 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.
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]
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.
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.
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?
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.
> 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.
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.
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.
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.
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.
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.
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 ;)
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.
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.
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.
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.
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.
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]
> 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.
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.
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!
(How this advice applies to this post will be left as an exercise for the reader.)