If this campaign is as sketchy as their laptop was, no thanks. I already don't trust them because of their misdirection in that project, they have a ton of goodwill and trust to rebuild before they can be taken seriously.
Let's put it like this... many laptops can run a FLOSS operating system, but how many smartphones can you say the same about? There's only a handful I can think of, and most of those are no longer produced. Even if not every binary blob is removed, the opportunity to kickstart a FLOSS-based phone ecosystem is not one that comes along that often.
My problem isn't that they couldn't pull off a fully open laptop, it's that they lied and said they would, knowing from the start they were dealing with chips that were impossible to open source. Then, they doubled down and lied again. If I contribute to a campaign that says they will give me something, and they fail to come through not once but twice, I expect my money back. They are scam artists as far as I'm concerned.
If one guy[1] can pull off a truly, fully open hardware and software laptop, you'd think a fully funded startup could do better. It's embarrassing.
bunnie didn't pull that off. I don't remember the exact details, but there was some piece of hardware on that machine that kept the FSF from endorsing it, as well as an additional piece of hardware (perhaps the GPU?) that bunnie said the FSF hadn't even considered such that he didn't pursue the endorsement any further.
Also, the Novena isn't really a laptop, but more like an all-in-one with a hydraulic arm that raises the screen while exposing all the innards to the open air to accommodate tinkerers. The laptop bunnie offered was somewhere around $5,000 with an enclosure made of wood that was designed by a guest artist. I don't remember the final tally but I think there were less than 10 built, and that was it.
The Novena has a Xilinix FPGA that can only be programmed using proprietary software. I own a Novena and only run free software so I don't use that component at all.
They're not malicious, they're just not smart about software (even if their heart is in the right place).
I ordered the Librem 13 as soon as the crowdfunding for it started. I received it about 10 months later I think. It's real, it works.
But yes, all the software parts they were really supposed to focus on and get right, were a joke.
In one of their first updates, they talked about working on touchpad driver, and releasing it as GPLv3. I emailed them saying they probably had a typo, the linux kernel is GPLv2 only of course ... nope, they just didn't know what they were doing, they were like "hmm we'll ask the FSF about that". How could you not already know this if you are working professionally on this. Their touchpad driver was not finished and integrated upstream until over a year later. This is the easiest software part they had to do any work on. During that time, they didn't have good instructions for installing it as a separate module for an arbitrary kernel - some guy from another org set up a github repo with that. And after everything, they couldn't get the touchpad model detection working well enough (it looks like a plain ps/2 mouse to the system) so it doesn't even work by default with an upstream kernel, you have to echo "byd" into a sysfs file to tell the system it's this crappy model of touchpad, and then it mostly works, as a plain mouse (no two-finger scroll, just edge scroll, and no touchpad config/adjustment).
EDIT: by the way, their latest laptop models use a different touchpad with a good driver (which they didn't have to do any work on)
Up next, "PureOS", their debian based distro. I don't really care, but I was trying to use it for a bit so I could easily use their kernel with their touchpad driver while it wasn't upstream yet. My laptop came configured with nothing in the apt sources.list, it got no security updates. I had to figure out how to put debian stretch sources in there on my own. I later figured out how to add a source which had their custom packages (kernel, and useless old firefox variant). This wasn't written anywhere on their website! And it stopped working and moved to different URLs! I don't think their PureOS had proper stable apt sources for updates and general package installing, for 6 months after users started getting their laptops, which was long after their crowdfunding got going. I guess their "debian developer" can maintain a couple of packages for debian, but setting up some standard repo mirrors for their OS took about a full year longer than it should have. (I still wouldn't bother with their distro. They should have just installed plain debian stretch and avoided all this stuff they suck at.)
And finally, the firmware and ME. All the updates for the first 6 or 9 months talked about the progress on coreboot, and then that was paused for experiments on neutralizing the ME. But there was nothing to show for it until January THIS YEAR when they hired a new guy to pick up the work on it again. One and half years with empty hands, two years before delivering on the original coreboot promise. It turns out this new guy is smart and gets stuff done. Coreboot is ported, ME is neutralized. But it seems that everyone else Todd Weaver hired before that was not really capable. Or maybe their efforts were terribly mismanaged. Both are believable - Todd is a hardware/manufacturing guy, he doesn't really know software much.
This laptop isn't too bad, I'm not bitter about it. Just disappointed and frustrated about the missed potential. I really don't think Purism did anything malicious - they're just kinda dumb and unaware and simplistic. I agree, free/libre software on modern devices is important. But you have to have more than the ideal which you read about in some essay on the internet, you have to also know a thing or two about software, and they just don't. They're total newbies playing a rather difficult game.
"Here's to the crazy ones". Maybe dumb and newbies are naive enough to get into this. Maybe suboptimal but they are getting things executed. Let's hope they can make this phone and have gained enough experience to make it usable.
There's a whole thing about the Play Services absorbing more of the features, and I feel like it's a great indicator of the difficulties with open source.
A lot of people enjoy replacing the lowest level of the system with OSS. But consumers only notice that afterwards they have nothing on the highest level.
I think the Raspberry Pi took the right approach here accepting the binary blob GPU but having the software stack otherwise be free. They got adoption because things were useful! And now they "just" have to solve the GPU problem, instead of a "rewrite all software " problem.
I would be very excited by people who could offer a "skin " over Android (with its own set of apps) so the higher level stuff could be tackled. Once that part of the stack is nice, swapping out the backend will be an even easier pitch.
The counterpoints I can think of:
- If you do not trust the backend, hard to have proper security.
- People are doing what they want to do! Lots of people like writing kernel-y code more than a dialer UI
"People are doing what they want to do! Lots of people like writing kernel-y code more than a dialer UI"
erm, I think yes, those people who can write kernel-y code, probably want to do that more than UI. But when you take the whole crowd of (oss) developers, then all together there are much more people able and willing to write UI-Code, than kernel code ...
The bigger problem with unstructured FOSS development is probably more the boring parts, like maintenance, testing and bug fixing ...
> "There's a whole thing about the Play Services absorbing more of the features, and I feel like it's a great indicator of the difficulties with open source."
Let's imagine a hypothetical scenario where Play Services were open source. How would this hold back Google from maintaining/growing their market share?
As for developing for Android and swapping out the backend later, by that point your apps would be tied into the Android API calls, unless you intentionally make your apps cross-platform, at which point what do you gain from running Android? If it's just for the drivers then libhybris is an option. If you want the ability to run Android apps whilst you build up your own, this is something you can do with Sailfish OS, which you'll almost certainly be able to run on the Librem smartphone if it's released.
My point about Play Services was that, despite Android being OSS, it is not sufficient to just set up AOSP. People still want to use apps, so you have to get a copy of Play Services. But Play Services is a Google blob, phoning home and the works. The higher-level stuff is what "matters" to people.
If Play Services were open source, then someone could release forks of that which patch out the questionable parts of it (just like Chromium/Chrome, in reverse). Efforts could be combined on the open source parts of things, so that we don't spend our lives rewriting battery-efficient geofencing services.
the gain from running on Android is that you can concentrate on higher-level value-adds first, to build adoption of your stack.
You could build out some cross-platform thing too, it's just that Android tends to make things a bit easier for swapping things out.
Sailfish sounds like a good option for this, but what I'm reading is that the people making Librem are spending a lot of effort building out a new OS mostly from Linux?
Play services exists to give Google a way to deliver updates that isn't subject to carrier or oem interference. If it was open sourced, that would defeat the purpose.
To put it another way, giving the general public access to the source wouldn't make any difference to Google, but giving Samsung that access would make a big difference.
I have doubts, but I've been waiting for a phone like this for a long time. I hope it works out and gets enough funding. I'm glad they didn't make compromises on the OS, hardware switches, etc. I wish more companies would cater to passionate yet non-mainstream markets. It's crazy a truly hackable linux phone doesn't exist today.
I'm surprised you think that the funding target seems high. I personally believe their funding target is in the range of 10-20x too small to actually make a smart phone, especially when they plan to make all their own software and not simply reuse Android/Sailfish/Ubuntu as a starting point.
I expect that just the certifications for the radios, both for various countries/government agencies and various phone carriers, to cost them many hundreds of thousands of dollars. And that cost has nothing to do with actually designing any of the hardware or software.
There are two ways to interpret their funding goals: based on projected cost and based on projected backers. 1.5 million dollars may not be very much money for smartphone development, but it is very ambitious as a crowdfund goal. It basically requires around 2500 backers ($1.5MM / $600) to pay $600 out of pocket for a device that, at best, will be delivered in 18 months.
Given the success path of most hardware kickstarters, I'd be surprised if this fully funded. The price point is relatively high (even though it is a whole phone, I get that, it is just a lot of money). I'd also be surprised if it actually delivered in 18 months. That's basically saying: "we have the design all done and are in our final mass production engineering phase right now". I mean, if you follow any prior hardware kickstarters that include significant production parts (pebble, keyboardio to name just two), the one major lesson is: mass production takes a ton of time and money to get right.
> the one major lesson is: mass production takes a ton of time and money to get right.
True, but that said, Purism has plenty of experience with this entire process through their laptops. Hopefully the lessons they've learned there will help them a lot here.
I'm very happy with my Librem 13 laptop so far and pre-ordered a phone. I know there's some risk of failure but I'm happy to put my faith in Purism here, based on what I've seen from them so far.
It basically requires around 2500 backers ($1.5MM / $600) to pay $600 out of pocket for a device that, at best, will be delivered in 18 months.
There may also be a handful of people like me who think the idea is cool but don't necessarily want the device (or don't want it right away); I just donated $20.
JackPair is another example that's had tons of hardware issues. Stuff that a new device maker might not see coming. One that does lzptops might also get blindsided moving to mobile where there's extra challenges.
Don't think the phone is 100% in house. They're using a base OEM model from someone that happens to have opensource drivers for everything (which makes me think it's an older model).
> They're using a base OEM model from someone that happens to have opensource drivers for everything (which makes me think it's an older model).
I... don't think that's the case here.
In the specifications they state:
CPU separate from Baseband
My reading is that modem is connected to the CPU via USB. The only other project I know of that was looking at doing such a thing were the OpenMoko guys (GTA04 with an OMAP3xxx, I think? My memory is fuzzy on this).
AFIAK, there are no 3G/4G modems with an open source baseband. So the traditional route for libre/privacy conscious people has been to isolate the baseband from the application processor via USB. Normal phones have the baseband and SoC integrated on the same SoC and connected via a high speed serial bus.
On further reading, it's going to be an i.MX6 (because i.MX8 is not available yet and you don't typically use unreleased SoCs for your libre hardware) which is pretty inefficient by modern ARM SoC standards.
So this is essentially a small tablet running Linux with an integrated cellular modem.
"My reading is that modem is connected to the CPU via USB. The only other project I know of that was looking at doing such a thing were the OpenMoko guys (GTA04 with an OMAP3xxx, I think? My memory is fuzzy on this)."
First, modem connected via USB is a good thing - it's the least bad option with regard to closed basebands.
Second, it's not that rare of a configuration - I believe there are quite a few consumer smartphones that connect the baseband via a USB interface ... it's not like there's a little USB connector inside there...
"So this is essentially a small tablet running Linux with an integrated cellular modem."
I don't think that's exactly correct ...
It is indeed possible to stick a USB cellular modem onto a tablet device and even use it for telephony. The problem with this arrangement is that there are many other things (like echo cancellation and other voice enhancements that need realtime processing) the baseband processor does - and you lose those functions.
An integrated USB modem that is actually the integrated baseband of a mobile phone does not have those problems - even though the bus used is USB.
It will most likely be a USB-like connection; HSIC, I suppose. BTW, this is the condition that all Replicant phones have to meet in order to be ported to it. So quite a lot of phones already have such an architecture.
At least the Nokia N900 used the separate CPU and baseband configuration.
The osmocombb project [0] is an implementation of baseband modem functionality, but I'm not aware of anyone using it.
Old TI Calypso modems also have an open source firmware implementation [1].
> So this is essentially a small tablet running Linux with an integrated cellular modem.
This reminds me that the 3G version of the 2012 Nexus 7 tablet had the baseband processor separate from the CPU. It was generally said that this was one of the reasons it had sub-par battery life, but I don't know if that was true.
On their site: "will work with 2G/3G/4G, GSM, UMTS, and LTE"
If it's using something like this: http://a.co/9IVPmkI -- then maybe it's using the USB pins on a mini PCIe card.
I think it would be wise to wait until they have committed to a particular cell modem. Most people will not be able to use a phone day to day if it suffers from:
> then maybe it's using the USB pins on a mini PCIe card.
Every mini-PCIe cellular modem I've seen interfaces via USB and not via native PCIe. You can even buy adapters to use a mini-PCIe modem as a USB modem. [0] I don't think this is standardized, but it seems to be the defacto standard for all modems in this form factor.
Now this may change once LTE/5G speeds regularly exceed what USB 2.0 is capable of since mini-PCIe does not provide pins for USB 3.0, the standard is too old. I would guess they'll move to NGFF as that's already the case for newer business notebooks which offer a WWAN slot.
They say the hardware will use an i.MX6 or i.MX8 SoC, which I assume implies they are using the Freescale/NXP SoCs. i.MX6 isn't really intended for use in phones (afaik) and I don't know of any recent phones which use i.MX6 in them. i.MX8 isn't publicly available yet, but possibly they could leverage some other vendor's hardware phone design using i.MX8.
However, based on the schedule they show in the pledge info, they already have the "PureOS I (CPU)" step mostly completed and they plan to be booting the hardware before the end of 2017, so this seems to make i.MX8 unlikely imho.
Some Kindles may use i.MX6, likely simply because some i.MX6 versions have an integrated e-paper drive subsystem which avoids the need to use an external e-paper controller. I believe early Kindles used the Epson e-paper drive controller.
There isn't that much to write, Matchbox has enough to make X11 touchscreen friendly. Really it's just about all the hardware stuff which they've done before I'm sure.
Seeing as the screenshots are from Gnome, I'd be surprised if they used X11, considering Gnome's future is on Wayland. Not to mention the irony of shipping a "secure phone" with X11...
I still feel like being tied to X would be better than being tied to android. I use X11 on my laptop as do most people I know. Is it really that hard to just not run apps that you don't trust? There isn't that much out there that isn't built by a fairly popular open source project and is worth using.
With X11, an exploit in any GUI application can be turned into a privilege escalation vulnerability. On Wayland, to achieve the same, an exploit in a GUI application would need to exploit another application running with higher privileges to escalate.
Not running apps you don't trust is an overly simplistic security model, and completely ignores exploits.
I am sort of troubled by the crowdfund page. It is obviously designed to look like a kickstarter page, but it is in fact not a kickstarter. Say what you will about kickstarter, but I have questions.
Will the campaign charge you even if it doesn't reach its goal? There is no indication one way or the other on this page.
What are the refund / delivery guarantee policies here? KS ones are potentially controversial, but they at least are written down.
Are those pictures of the phone actual pictures or renders / mockups? KS has explicit policies about that, but this context makes that unclear.
Will the campaign charge you even if it doesn't reach its goal? There is no indication one way or the other on this page.
Just scroll down..
"What if you don’t reach the funding target?
It will show that there is not enough interest in producing a device that focuses on security, privacy, and digital rights, which will be a tremendous social disappointment. If we don’t reach our target then all contributions will be fully refunded."
Hmm, interesting. I will admit I missed that (as it was halfway through the FAQ, and I've got to say: passive aggressive). That said, they make it sound like you get charged up front when you back, and will get a refund if it fails to fully fund. This is a pretty significant departure from traditional crowdfund platforms (ks, igg) where you're charged when the campaign ends, only if it succeeds. Adding an extra two months of lockup to your money and "we promise we'll refund" just feels ... sketchy.
I mean: I like what the purism people are doing, don't get me wrong. I'm a fan of their librem stuff, ever since the crowdsupply days. But like: is there a reason they're not doing this on crowdsupply? Again, it just feels like a dark pattern to use these visual cues to suggest kickstarter while not adhering to standard crowdfund policy.
Giving them the benefit of the doubt, they may have started with crowd supply so they didn't have to worry about certain things (credit card, shipping) that crwod supply took care of, but took a portion of the proceeds. Now that they have done kickstarting a few times, they understand better how it works, or they are large enough that crowd supply no longer makes sense.
Thanks! I guess I must have never noticed the charges when the campaigns have ended so I'd always assumed it was in the beginning. That's good to know!
that's never happened to me - I know this because I've had several times when my credit card info changed between pledge and completion, and I had to update my cc info because the card was rejected at completion.
they confirm payment when you back, but the charge doesn't happen until successful completion, at least on KS.
Oh I see, so do they not even put a temporary hold? Otherwise doesn't that mean they might not be able to get a significant portion of their pledged funding (e.g. if people don't bother to update their cards)?
that is correct - some percentage of every KS campaign fails to collect due to rejected CC charges / chargebacks etc. According to this older (2015) article [0], in 2014 KS had $529 MM in pledges, but only collected $444 MM. So: that's like 83% successful charges? Then again, that might have included failed campaigns (since those would be pledges that didn't collect as well).
I support the whole idea, but I think it's premature.
The Riot app in my experience has a pretty unwelcoming UI/UX experience and is still insanely buggy. Things like Jitsi integration, widgets and a phone partnership should be after a solid, stable 1.0 MVP IMHO. Encryption is still opt-in and beta.
So super supportive of the environment, the momentum and a native matrix phone partnership is the right move eventually, but please get it stable, fast and polished first before branching out too far.
Moxie lays out a challenge to federation enthusiasts to prove him wrong that federated chat can be secure and have good usability. I would respectfully note that Matrix seems to be responding to the challenge with a chat client that is neither. Instead they seem to be doubling down on federation and integrations. Usability can be fixed, but the federation and multiple clients makes it a challenge. Security on the other hand is, again, concerning because it feels tacked on. It's not on by default because, again, it makes it complicated when you have multiple clients. Last time I tried, you could put in your password on the web client (browser encryption!) and join an existing conversation, and see all future posts by the people in the conversation, because suddenly they've accepted your new public key. I had to dig a little bit in the configs to find the current public keys for the clients in the conversation. Either they have to make a UX-friendly way of warning everybody that there's a new client, or accept that stealing an account password will let you snoop on conversations. I really appreciate their enthusiasm, and I hope someone gets federation right, but it just seemed like a mess.
By contrast, I think that Signal recognized that you can work around the security vs usability tradeoff by trading off on a third vector: feature set. I think that we won't get a federated system until someone heeds Moxie's warnings and does some careful, creative thinking.
> It's not on by default because, again, it makes it complicated when you have multiple clients
This is simply not true. The reason it's not on by default is because we're still developing it and it's in beta. It's not tacked on; we've designed in E2E from the outset - but implementing it well in a decentralised manner is a huge amount of work; probably 5-6x more than in a centralised system like Signal. We're not going to enable it by default until we are 99.999% sure that it won't cause regressions over the non-e2e client.
> Either they have to make a UX-friendly way of warning everybody that there's a new client
I think you must have tried it a (very long) while ago - we've had the UnknownDeviceDialog since February. It looks like this (https://matrix.org/_matrix/media/v1/download/matrix.org/mOOj...), and warns you every time a new device is added to the room, and gives you the option of blacklisting it from receiving your messages if you don't trust it.
Now, totally agreed that this UX is ugly and needs work, but this is NOTHING to do with the decentralised or federated nature of the protocol. It's simply that we currently are very resource constrained currently for working on web front-end issues.
That said, if your ONLY priority is security, then Moxie's "the ecosystem is moving" probably has a point. After all, in an open ecosystem like Matrix, it's possible someone will fire up a buggy/malicious client and inadvertently compromise a room. However, if you value freedom as well as privacy, Matrix or OMEMO are basically your only choices.
Alright, you make a convincing case that it's not tacked on and I'll give you the benefit of the doubt here. Unencrypted basically is just "dev mode".
Very glad to hear you patched up the hole with the unknown clients. Perhaps I'll try again down the line.
> Now, totally agreed that this UX is ugly and needs work, but this is NOTHING to do with the decentralised or federated nature of the protocol.
Well you have to design that dialogue that tells you new devices came on, right? And you have to deal with cases where some people accept a new client and some don't. And you have to explain to lay people what the heck an IRC bridge is. And so on. My point is just that you have a lot more things to explain to users, so you have a lot of UX work ahead that you wouldn't otherwise have. So I don't think it's unrelated. (Aside from the issue of explaining things, it's not particularly ugly actually, from what I remember).
> it's possible someone will fire up a buggy/malicious client and inadvertently compromise a room
I appreciate that you acknowledge that. It signals that you have things in perspective.
I actually think some people do consider freedom to be a security issue. They don't want Signal servers to go down, or get into malicious hands.
Also: Nothing strictly stops people from using rogue Signal clients either. There's just social pressure deterring it. By that same token, perhaps you could use social pressure to deter developers from lying about what client they are, and then have a vetting process for secure clients. And then warn users when an insecure one comes on. (And perhaps count web as "not recommended for especially sensitive discussions")
Anyway, thank you for addressing my points and accepting critique. I do hope to see you succeed.
> After all, in an open ecosystem like Matrix, it's possible someone will fire up a buggy/malicious client and inadvertently compromise a room.
Isn't this a case for building in some kind of system whereby clients can be signed and have their signatures revoked by their creators or, for lack of a better word, ostracized by the wider community? Sort of like a web of trust model, but for clients, not just users, to make it more clear when somebody is joining with an untrusted client and perhaps allow moderator control over whether to allow untrusted clients to join.
Possibly, but this is heading into seriously DRM territory. one would need to be running the app in some kind of secure enclave that could attest to the authenticity of the app (e.g. via SGX on Intel). There's something a bit unsavoury about saying that "only truly official signed apps are allowed to participate in this open network", and it gives a huge amount of power to those responsible for the secure enclave/trusted computing stuff. (There's also the approach that djb mentions in https://twitter.com/hashbreaker/status/732912508089032706)
It's possible that just relying on social mechanisms may be enough to discourage people from running known evil apps (similar to educating users not to install malware today, or do trusted operations with cybercafe computers, or whatever). Effectively, the verification process when going and explicitly trusting a new device needs to explicitly prompt the user to consider where on earth this app came from, and if it should be trusted.
The only alternative is really DRM, which just feels wrong.
>There's something a bit unsavoury about saying that "only truly official signed apps are allowed to participate in this open network", and it gives a huge amount of power to those responsible for the secure enclave/trusted computing stuff.
Maybe it's a bit naive, but isn't that what federation is supposed to solve? People who are more security-paranoid can forbid clients which don't have the highest security certification, and operators who aren't so diligent will be fine with signed clients being run on untrusted hardware.
I mean... is there any open-source software being developed today which enforces key security in secure hardware enclaves? Verifying the GPG signatures on binary packages is "good-enough" for most operators. Build reproduceability will help to further reduce trust of unverified hardware.
It seems to me the job of the protocol, and baseline/recommended UI/UX, is merely to help users make informed decisions. Security is a spectrum, and if signed clients improve security (while not fraudulently representing itself as perfect or near-perfect security, if it were running on trusted hardware), then that's a net benefit to the open network.
I may be missing something, but how do you prove that an app is running a trusted codebase? I know of no PGP clients for instance that sign messages to try to prove that they were sent from a trusted app (as opposed to a trusted user). The only way I know of to do this would be to hook into a trusted execution environment of some flavour like Intel's SGX or Apple's Secure Enclave, to let effectively the chip vendor sign off that you are running an official app installed by official means. You /could/ do this, but you are putting a lot of trust in the secure enclave implementation and those controlling it, and essentially putting all your eggs in one basket. It might also lure users into a false sense of security: just because a user is using an appstore signed copy of an app doesn't mean that app is actually trustworthy or bug free. And it would also artificially discriminate against legitimate apps which aren't part of a trusted execution environment, which seems dangerous - and effectively promoting DRM at the expense of FOSS.
We're working as hard as we can on improving Riot's UI/UX and getting crypto out of beta. As others have said, partnerships like this help fund the team to get the core stuff in place. After all, this project (assuming the campaign is successful) is 2 months away anyway.
What's the value proposition of building a whole new client? If your goal is to give people a client for your cool new protocol, why would you waste any development resources on squashing fiddly UI bugs of your own doing, rather than, say, providing a reference implementation by forking the Signal app and swapping out the pieces until it's talking Matrix instead of TextSecure?
I see this mistake constantly. The ring.cx folks did the same thing. Inevitably, everyone ends up commenting how poor the app is—some of them even saying how much they'd like to be able to use it and would if it weren't for the UI. It wouldn't be so silly if there weren't plenty of essentially ready-made solutions for the problem.
1. Signal doesn't have a native Linux app (other than Electron)
2. The hope is to piggyback on one of the existing native Matrix SDKs or clients rather than write a whole new one.
3. One of the biggest complaints we hear about Matrix is that there is no native desktop app with parity to Riot yet. So this is our chance to fix that.
> Signal doesn't have a native Linux app (other than Electron)
How is that an explanation for directing (apparently limited) resources into riot-android?
> there is no native desktop app with parity to Riot yet
Huh? The comparisons I made in my comment were to Signal and Ring, which are predominantly mobile messaging apps. The person you originally responded to was discussing Matrix on mobile. Why do you keep mentioning desktop? If there were any confusion, this is a thread about an announcement for a new smartphone.
Riot/Android doesn't run on Linux, so directing limited resources into it is fairly irrelevant. The point of this campaign is to fund us to work on a native app which can benefit desktop and handset users alike - whilst also supporting the core team so we can also work on the React, Android and iOS SDKs which power Riot. I keep mentioning desktop because this is a significant benefit of the campaign.
The idea of somehow ripping out the core of the Signal or Ring apps and trying to bolt their UI onto Matrix SDKs is an interesting one, but in practice both protocols have significant differences to Matrix, and at best this would be a pretty big impedance mismatch. Of course, someone in the community is welcome to try to do it. Meanwhile, we'll keep plugging away at trying to make Riot kick ass (via the underlying Matrix SDKs), and add a native app to the pantheon too :)
>The Riot app in my experience has a pretty unwelcoming UI/UX experience and is still insanely buggy.
I've setup my own Synapse server on a VPS and have my extended family of 12 people including an 85 year old grandmother using it on an iPad. It gets used daily for chat and picture sharing. I've come across a few minor problems on iOS, but overall I don't agree with that characterization.
I think, homeserver software is also still somewhat immature. I'm waiting for Dendrite.
I'm evaluating Synapse (as all the other servers say they're pre-alpha incomplete) for the last week or so, but one immediate issue I had is that when I had set it up, on my home low-power NAS it required more than 15 minutes (and 0.7GiB of memory out of 1GiB I've allocated to the container) at fully-saturated single CPU core to join #matrix:matrix.org. And it took no less than a minute to join a room with just 200 participants. Sure, that's just for the first time, but it still feels way too resource-heavy, compared to other chat systems.
The machine has 10-year old Atom 330 CPU - which makes it an ancient relic, but hey, it has more than enough power to run XMPP (w/various transports), mail and web servers, and it just sits on a shelf in a kitchen, with a barely audible humming.
Synapse's readme does try to spell out that it requires at least 2GB of RAM and a recent CPU. It is absolutely resource heavy, but not showstoppingly so in general. The comparison with XMPP is dubious as the protocols are completely different: it's like comparing a local filesystem with a distributed database and complaining that the DB is slower.
That said, Dendrite should improve things a lot; we should have more stats in the near future but it seems to idle around 150MB of RAM and should run much better on ancient hardware. We are not bothering optimising synapse much further in favour of focusing on finishing Dendrite. Needless to say, we expect Dendrite to be finished well in time for the Librem 5 to go live, 18 months from now!
Hardware wise, for its time maybe, it was perfect with its full qwerty keyboard.
Software was so bad it was tragic. You couldn't even trust phone calls to work.
Clearly I want a FOSS phone to work but the market is miniscule and therefore the product quality will likely remain on a hobbyist level.
Furthermore I tried the Jolla phone and that wasn't exactly FOSS but the small team could be compared to what you might see in a FOSS phone. And again it was barely useful.
I also tried the ZTE Firefox OS phone, it felt like a toy and the OS was crippled.
I think the plan here is to be hyperfocused on private/secure Comms and Browser and do that well. Many more apps can come from the wider Linux ecosystem as time goes on, but this is a very different proposition to another me-too FOSS alternative to iOS or Android.
Is this what the actual phone will look like? Some kind of context photo with a reference hand would be great, because the dimensions and shape otherwise suggest this would be comparable to holding a Kindle or Nexus 7 next to my head!
The details are available on the Purism[0] site. I really like that they are adding physical switches to control the microphone, camera, baseband, and bluetooth. And that they are giving a lot of thought to separating the baseband procecessor from the cpu. And that it will be an ip-based phone handset, which means I can use a regular linux os that respects my freedom. I'll have to learn more about PureOS!
With matrix's e2e encryption based on the OWS system, we may see the first reasonable take on a privacy conscious smartphone.
I was looking at the Dragonbox Pyra, but this seems even better. I'm pretty excited, I may actually upgrade from a dumbphone for the first time now if this comes out.
> I was looking at the Dragonbox Pyra, but this seems even better.
I've been following the Dragonbox Pyra for a while too -- I actually just sent a link to a co-worker this morning.
The Librem 5 does seem really awesome, but what I really like about the Pyra is the physical keyboard. If I could have the Librem 5-alike in a Blackberry KeyOne or Pyra-like form factor, I would be one happy camper.
In other words, I really want a device that could replace both my laptop and phone, in terms of productivity. It seems like the Dragonbox Pyra is more closely aligned to that ideal than the Librem 5.
I was thinking the same thing. I tend to see several people always mention they prefer smaller screens. I wonder how receptive people would be to a thicker phone versus a larger screen? The thinking here being people want larger batteries in their phones. I was thinking about this, this weekend, when one of my aunts was visiting. She owns some lower-end android trac phone. It has a much smaller screen than my 6P, and I am not sure how easy it would be to switch back. I mean it would fit nicely in my hand, but I've also gotten used to the amount of information displayed on my larger screen.
P.S. Sorry if this post is a bit of a ramble I'm still waking up.
but thats what every flagship phone did since 2015 and everyone kept buying. you can't find a flagship phone today that would not be called phablet in 2014.
As much as I want a FLOSS phone to succeed, I have my doubts. Then again, I'm not sure how all the Matrix stuff works, but if I can't simply give someone my phone number and expect it to just work, I don't see how this can happen.
Can someone explain it more simply? Does it completely forego SIM cards? Will it 'just work', or is it more of a 'we made progress in this area, but not a lot of people are going to find it practical' thing like Replicant?
In the crowdsourcing page, they say it can be used with a regular carrier number, or with mobile data plan + VoIP, or just WiFi + VoIP (see section "A No-Carrier Phone?").
I wish these guys would just use android from the get go. It's already running on i.mx6, so by switching now they would at least have a chance of making a decent product.
They are literally throwing away hundreds of millions of dollars of excellent work that has been put into power optimization for no good reason. I've told the ceo there this like at least 3x but he is stubborn.
> “Android is so frustrating! Trying to remove Google’s privacy invasion bit-by-bit removes functionality bit-by-bit, and you end up with a non-working phone. Purism will solve this by putting your privacy protection and security first.” — Zlatan Todorić, CTO
This quote is nonsense. There are at least 3 projects (replicant,copperhead & another) that are shipping trees like this.
It will be so much harder for them to create a phone that stays alive for more than an hour or two running a full linux desktop.
>If we want a secure and user-friendly phone, it won't be Android.
I don't think you realize what it takes to keep an operating system secure. If you really think this project is going to be more secure than Android then that's a wager I would take all day.
By using a real GNU/Linux distribution like Debian you can have up-to-date software with all known vulnerabilities patched. On Android, all the apps bundle dependencies which house tons of unknown vulnerabilities and then the phone vendor stops updating your phone when it's no longer in their business interests. Any GNU/Linux can be more secure than that terrible baseline.
And who is going to patch all of the userland exploits? The radio firmware exploits? The driver exploits? Keeping a phone secure is so much more than just downloading the latest Linux kernel security patches. Unless you have a large team of security engineers that dedicated to patching and enhancing your OS then you're going to be in for a world of hurt once your platform gains any popularity and, thus, nefarious interest.
>On Android, all the apps bundle dependencies which house tons of unknown vulnerabilities and then the phone vendor stops updating your phone when it's no longer in their business interests.
The same is true for any device that has been determined to be end of life by the OEM. Yes, it would be nice if devices were supported to perpetuity, but even Apple ends support for their devices after 5 years and more than 10 percent of their current install base isn't even on the latest OS version.
>Any GNU/Linux can be more secure than that terrible baseline.
Perhaps, but saying it and doing it are two very different things. I hope it works out because I think there's a niche for a phone that is always up to date and never written off by the OEM.
This won't be more user friendly than android. Google has invested a ton in ui r&d. They will have done very well if it doesn't crash frequently and you don't have to endure long waits to do stuff.
I kinda feel you on this. I am attached to the Android ecosystem. I know two people who have attempted to use open source phones (a rom without gapps + fdroid). They're not _really_ open source as your still have binary blog drivers, but that's as close as you're going to get really. I will give it to them, they were dedicated. One of them had done this for nearly a year, but she started to give up when she found herself writing several apps to replace stuff in that was already available in the play store.
At the same time, I would really love an alternative to Android/eyeOS. I wonder if we'd have more open source mobile tools had the Ubuntu Edge succeeded in getting funding?
One of the biggest reasons we don't see a Linux explosion on Android in the same way we saw developers using it on their desktops in the late 90s/early 2000s is because you can't just install a base Linux distribution on any phone. Unlike the PC which is a full platform, ARM devices are SoCs where every manufacture attaches random shit to random pins and creates non-upstreamable Kernels:
Almost every rom we see out there has to have a customized build for each specific phone. Maybe some of this will start to change with Oreo, but I think a bigger barrier to alternative OSes on phones is simply a standard platform.
The only reason I am willing to fund this phone is because it's not android. If I wanted "just another android", I'd get one. They are a dime a dozen, and all terrible, imo.
> This quote is nonsense.
Heavily disagree. I've worked with those projects, and they are terrible and severely limited systems.
Purism has been pushing for actual foss systems, which I would strongly argue Android is not, and is moving farther from every day.
Me and many other people have been begging for an actual linux phone, and I'm excited to see where this goes.
You can run debian on android today. You can make android look however you want it to look. What they are losing is doze, app standby, the compiler tech, they will have to redo wakelocks, the resource manager, etc.
In android, nothing is ever actually running other than background services and the foreground app.
Since I assume they don't want to tell their users "never start a second app" I wonder where all this infrastructure is going to come from. They will have to reinvent a whole new app paradigm.
> You can always just use the same old same old, but you aren’t gonna create something new - the thing of your dreams - by doing that.
One could argue the opposite — that you can build the thing of your dreams far better and faster by leveraging non-differentiating work done by others.
For example: Even a decade in, iPhones use lots of materials and components from other vendors.[0][1]
Maybe Android isn't the perfect OS choice. But building a phone without access to an ecosystem of apps relegates it to a curiosity for most, which seems like a shame.
To build a phone on top of Android, you would have to believe Android is a good system to build upon. I don't believe that is a fact though. There are lots of problems with Android. Sure, your phone gets access to a lot of apps from day one, but 99% of those apps are shit, so why bother.
We've got so few mobile consumer OSs in use today, and I don't think any of them are particularly great, although I believe one of them are much better than the other. I welcome completely new approaches to it instead of the way it is today where we have Apples stuff, and then we have numerous companies that makes shitty Android stuff, and a few that makes some okay great Android phones.
The power management app that comes with KDE/Plasma does a pretty good job with my laptop battery, certainly no worse than Windows did. It throttles back the CPU, dims the screen depending partly on user activity, has sensible policies and notifications for stretching out that last 10% of the battery. It also allows apps to request an exception from power management. What's wrong with the current OSS PM tools?
In my experience, the most effective power management tool on any device is actually just airplane mode.
On my laptops, tlp on Ubuntu/Debian/Arch (when I used those) and tuned on Fedora (which I've used since F25) have been awesome, so power management is unlikely to be the biggest issue with this phone.
I've used both on Fedora, and found tuned to be easier-to-use and more effective. tlp also does not work well with SELinux, and as such causes a flurry of errors every time you change the power state (sleep, resume, plug, unplug), which may be part of why I found it ineffective.
The way I set up my tuned profile is pretty simple:
Then, I edited the profile in `/etc/tuned/laptop/tuned.conf` and enabled things. On my Thinkpad X220, simply enabling everything worked great, but my Asus ROG laptop and my friend's Razer Blade had issues with that, so YMMV wrt what to enable. Then, I added USB autosuspend support by adding the following to the profile:
[usb]
autosuspend = 1
After that, I ran `sudo tuned-adm profile laptop`, which sets it and tells tuned to start on boot, and have had vastly improved battery life, good performance, and no hassles since.
Excellent, thank you. I've followed your instructions and am waiting to see how it all goes. My laptop is an X230, so should be similar to your experience.
There is no freedom in using Android. For the better part of a decade I've wanted to install phone software on a regular GNU/Linux distro and install it onto an ARM smartphone. A phone is a general-purpose computer and you ought to be able to use whatever distro you want on them. This project seems like the best shot of that happening.
best mobile experience of my life. saved many a flailing server from mine while my now-wife was in the bathroom, avoiding destroying the date atmosphere.
Just pre-ordered one. These folks have done a great job on their Librem laptop line, and I have wanted a "FLOSS-ier" phone for a while now. And if it goes nowhere I get my money back! (allegedly)
> that can also become a full desktop computer with an option for a compatible keyboard, mouse, and monitor ... It can be a desktop computer and phone all-in-one.
I'm interested to see their solution. How useable will the interface be?
It sounds like they haven't decided whether there will be free WiFi and Bluetooth drivers or not, and that would make a huge difference for me at least. Everything else seems to be totally free and open source, except for the baseband, which is separated from the system, can be disabled, and doesn't really have an open source option.
> The CPU will be an i.MX6/i.MX8, where we can separate the baseband modem from the main CPU, digging deeper and deeper to protect your privacy and isolate components for a strong security hardware stack.
I'd like to know more about this separation. For example--can the phone boot without the baseband being powered on?
It isn't hard to design a phone with a completely separate baseband processor and wireless subsystem.
People don't do it because it is more expensive than the integrated solutions. It also takes up more precious real estate on the PCBs. And uses more power.
So if you're willing to compromise on all that, it can be done.
> It also takes up more precious real estate on the PCBs.
There's no fundamental reason you have to use any more space to have the correct architecture (baseband as subordinate peripheral with no access to host); it's just a lot harder than buying a stock modem peripheral.
The fundamental reason is that no chipset mfn is going to separate the modem from host on a single IC. Thus you are adding a second complex BGA package and interconnects that take up space.
On power drain, it's an internet phone, the GSM/LTE module only needs to be active when you're not in range of wifi. Which for certain use cases such as being at home in an office, much of the day it can be switched off.
In urban areas, one might connect to wifi hotspots such as Fon (which in my country is branded by one of the telcos as Telstra Air).
Why on Earth would a device require a modem in order to boot? Even if the modem and the CPU are in the same package, the modem ought to have its own power and ground pins. How exactly does airplane mode work, in that type of package?
This seems like a really cool device. One that I would certainly purchase.
What weird stretch goals they have. I wonder if these are jokes?
"$8m = Signatures of entire team printed inside the phone case
$10m = Free encrypted VPN tunnel service for all backers for 1 year
$20m = Candy Crush (clone) available for free"
Do I understand correctly that it would be purely VoIP over GSM/2G/.../LTE? Where the particular VoIP implementation of choice is this "Matrix" protocol/ecosystem? Which potentially at some point (with enough financing?) may get some gateways enabling calls between Matrix phones like this one, and regular GSM/2G/... mobile phones?
The phone will have normal GSM in it, as well as being Matrix native when on IP (i.e. shipping a native Matrix.org client as the default dialler/messaging app, which will work whenever you have IP connectivity).
A stretch goal is to also provide Matrix<->PSTN connectivity, so that if you're on IP but don't have GSM (or don't have a SIM in the phone), then you could also place/receive calls with the PSTN from Matrix. (Obviously this would then be also available to the rest of the Matrix ecosystem too). (Source: I work on Matrix)
For those of us less informed: assuming a Matrix <-> PSTN bridge exists, does that mean that one would be able to send and receive phone calls and SMS to existing GSM numbers via a dedicated VOIP number? I don't understand PSTN at all, but wouldn't giving all matrix users dedicated VOIP numbers be difficult and costly?
Yup, that's the idea. Given this was the Matrix team's dayjob before getting sucked into Matrix, it's something relatively easy to do - although yes, we'd have to pass through the call/SMS and numbering costs. Now, if only Matrix had a payments ecosystem... https://matrix.org/blog/2017/08/22/thoughts-on-cryptocurrenc...
I think the "we aim" here refers to 3G/4G. The phone is going to have a baseband module, so yes, it will be able to do GSM phone calls & SMS like any old phone. I imagine that adding 3G/4G packet data in a FOSS manner may be harder however.
I think the "we aim" bit is more directed towards certain frequencies rather than "we're not sure if we can get 4G working". Take a look at any group of phones on https://willmyphonework.net and look at the differences between countries. Getting 3G/4G to work globally is a lot harder than just settling for US/Canada or US/Europe.
>The whole idea of the phone is to provide unprecedented privacy, security and autonomy by running an entirely FOSS Debian-based GNU/Linux stack (even including CPU & GPU drivers!)
Call me pessimistic but I don't think we will see a FOSS GPU driver anytime soon.
I can't really afford a new phone right now, but I really want this to be a thing, and I think we're running out of chances for a FLOSS phone to take off, so I ordered one. I really hope it meets its target.
Their UI looks like it's based on Gnome -- I wonder if they wrote some extensions to make Gnome more phone-friendly.
IMO great idea to use Matrix as the communication layer -- especially when double-ratchet is stable, it'll be able to provide the good UX of things like Signal on Android, iMessage, Google Duo, and FaceTime, but built on an open platform. Hope it does well!
This is a chicken and egg problem :) Support from Purism if this campaign is successful is one of many ways Matrix's funding can be secured going forwards!
That was a long time ago, and I think it's discontinued. Gnome Mobile and Embedded Initiative hasn't had an update presented at GUADEC or any other major FOSS conferences in 8 years.
I couldn't find the single most important piece of information for me, the battery life. Is that not decided yet or has it been omitted for marketing convenience? I was thinking of signing up to get one but with that missing bit I don't want to take the risk.
I think the whole point of the phone is that it's a FLOSS-friendly hardware platform which can run whatever Linux you like (even if the default supported one is PureOS, based on Debian).
Purism is doing some of the most exciting work in the field of personal privacy and consumer computing.
The tech blog is terrific, the laptops are coming along nicely, and the team is making inroads deeper into the chipsets and drivers.
Librem 5 crowdfunding: https://puri.sm/shop/librem-5/
Matrix on Patreon: https://www.patreon.com/matrixdotorg
Purism blog posts: https://puri.sm/posts/