The Librem 5: A Matrix-Native FLOSS Smartphone
matrix.org
matrix.org
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/
https://hackerfall.com/story/the-truth-about-purism-why-libr...
http://www.pcworld.com/article/2960524/laptop-computers/why-...
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
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.
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?
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.
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 ...
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.
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.
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.
I will definitely try and support this project as I'd love to be able to move to a more open phone.
Link to their crowd funding page: https://puri.sm/shop/librem-5/
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.
But even just for the software, it seems low.
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.
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.
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:
• Dropped calls
• Bad call quality
• Low speed data (anything less than 4G/LTE)
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.
[0] https://www.amazon.com/PCI-E-Adapter-Module-Support-connecto...
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.
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].
[0] http://osmocom.org/projects/baseband [1] http://www.freecalypso.org
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.
Not running apps you don't trust is an overly simplistic security model, and completely ignores exploits.
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.
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.
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.
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.
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."
That answer rubs me the wrong way.
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.
(Scroll a bit up, it seems their fixed header hides the question when directly linked)
they confirm payment when you back, but the charge doesn't happen until successful completion, at least on KS.
0: https://techcrunch.com/2015/01/06/kickstarter-2014-numbers/
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.
For those who are reading this and would like to help out please see the following blog post: https://matrix.org/blog/2017/07/19/status-update/
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.
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.
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.
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 smartphone in question runs Debian.
That said, I am excited about this - I love idea about pure OSS phone with hardware kill switches for mic and camera!
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.
This is the part that concerns me.
https://whispersystems.org/blog/the-ecosystem-is-moving/
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.
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.
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.
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.
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.
This certainly needs more thought :)
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.
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 eventually gave it up, solely because I wanted the ability to run specific Android applications.
But honestly, if I had the power of a full Debian-based system, I wouldn't need that.
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!
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'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.
P.S. Sorry if this post is a bit of a ramble I'm still waking up.
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?
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.
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.
They might succeed in this, and if they do, it might be awesome!
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.
[0] http://www.macworld.co.uk/feature/apple/where-are-apple-prod...
[1] https://images.apple.com/supplier-responsibility/pdf/Apple-S...
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.
Lets get new stuff on the table, please.
Were you planning on naming them or keeping us in suspense?
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:
http://penguindreams.org/blog/android-fragmentation/
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.
If we want a secure and user-friendly phone, it won't be Android.
> 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.
This is of course nonsense. I've run a "full linux desktop" on 1000mAh for more than a few hours, and I did it a decade ago.
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.
>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 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.
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.
I can run debian on windows as well, that doesn't mean I'm going to do it.
Why settle for a hacky second layer system, when you can just have the whole system?
And sure, I can make android look the way I want today, but I can't make it do what I want today, which is the important part.
In my experience, the most effective power management tool on any device is actually just airplane mode.
The way I set up my tuned profile is pretty simple:
sudo dnf install tuned-utils
sudo powertop2tuned -n laptop
[usb]
autosuspend = 1
Make it dual compatible, work with copperhead/AOSP android and whatever they are trying to invent.
Open hardware with hardware switches and a separated baseband is fairly interesting just by itself TBH.
the n9 debacle cemented my hatred for ms
> 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?
I'd like to know more about this separation. For example--can the phone boot without the baseband being powered on?
Sounds like they're planning a hardware kill switch for the baseband, so I would be surprised if the device couldn't boot without it.
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.
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.
If you could disable them, you could (possibly) trust your computer.
[citation needed]
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"
Big red flag right there.
In my opinion it is unethical to ask for money via crowdfunding when you haven't even bothered with finalizing the spec first.
I am really rooting for them and hope they get this right, being able to hack my phone like a desktop/laptop has been a dream of mine.
I really look forward to what the end result is and I hope they knock this out of the park!
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)
"WILL MY EXISTING SIM CARD WORK ON THE LIBREM 5?
We aim to support 3G and 4G for the most common international frequency bands and carriers. Exact specifications will follow."
Unfortunately, all my contacts communicate via regular phone numbers, so this is a feature that I need for a phone. "We aim" is not too reassuring.
Call me pessimistic but I don't think we will see a FOSS GPU driver anytime soon.
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!
Which makes me worried that this downstream project depends upon it.
First sentence of second paragraph of text: "based on Debian"
Why are you promoting the phone with a bunch of unrelated logos?