"right now, there are very few people, perhaps only dozens, for whom this phone is the right phone, given the current level of software support."
I think he greatly underestimates the number of people with the interest and ability to do this kind of work. If it's easily available, I'll probably get one and hack on it, and maybe contribute to some projects. And I'm far from something special or unusual.
You're right that the actual number is too low. But I think he, and Pine64, are just being responsible in managing expectations. The issue isn't just that the software isn't done, but also that the hardware may not be 100% there yet. This happens all the time with devices when something along the lines of 'oh crap, this power rail isn't stable in situation X and causes the device to reset' is discovered with pre-production hardware. The fix is usually trivial but often requires a PCB/component change.
I would absolutely have ordered one already if it sounded like the hardware were final... right now it merely sounds very, very close. The message I get from these warnings is the non-zero chance that there will be some annoying hardware issue that comes to light before going into volume production. This would not be unexpected since this is the first time a wider community is getting to work with it.
From personal experience, if the original Pine64 board is anything to go by, I wouldn't expect much on software and software updates from Pine itself (it would be up to the user to figure things out).
The following sentence "I am not using it as my daily driver, and I won’t for some time." and "the right phone" make me think that the dozens refer to those who might use this as their singular phone device. I'm sure many more people can afford to splurge on such a device and either play with it, or even forget about it for that matter.
This is why I ordered the Brave Heart edition as soon as it was available. I'd rather get it in my hands quickly, customize the software to my liking, and if I have to buy a second device to resolve some hardware issues later this year then I'm still only out 1/4 the cost of a new iPhone, plus I have a backup device for development.
I prefer going into it with the expectation of it being a "developer experience" rather than a prepackaged end-to-end solution. This, and the cost, is why I opted to go with Pine Phone over Purism Librem 5.
> This, and the cost, is why I opted to go with Pine Phone over Purism Librem 5
I am now considering purchasing a Pine Phone and the cost is definitely motivating. I only wish that the PinePhone had hardware kill switches like the Librem 5 has.
I did it again. I made the assumption that the PinePhone has no way of killing the GPS. In fact, this is incorrect. According to the PinePhone wiki [1] the hardware killswitch for the modem also kills the GPS:
> Modem: On enables 2G/3G/4G communication and GNSS hardware, off disables.
That is because the GPS is bundled with the modem.
> GNSS: GPS/GLONASS/BeiDou/Galileo/QZSS, with A-GPS
I shouldn't have just made the assumption that the PinePhone lacked kill switches. I like the fact that the PinePhone kill switches are hidden behind the back cover. It seems like kill switches on the outside might easily be switched by mistake. I also like that the PinePhone kill switches allows greater granularity, since it has six switches, allowing the cameras and microphone to be killed independently. On the other-hand, I really like that the Librem5 kill switches can cut the GPS. Of course, all three have to be switched to accomplish that, but it is still nice to have the option.
Both phones use a Qualcomm modem that is black boxed and connected via the USB so that the phones do not have to deal with the firmware. The downside of this approach is that, I am assuming again, the firmware can't be updated for the modem. So a vulnerability found in the modem's firmware would not be patchable. However; the Librem 5 modem is replaceable.
This. It may not (yet) be suitable for every-day use, but it is absolutely great for pet-projects or some tinkering. Also I would love to see enthusiasts creating alternative ecosystem around this, like open, federated social networking apps or maybe something with mesh-network support and hackernews reader app (of course). It won't get mainstream in general public, but could be sort-of mainstream among groups of open/free-everything enthusiasts.
1. The thing is reasonably cheap with "good enough" specs which makes it far easier to just buy it and accept that it may be just a toy in the worst case.
2. It's likely that the specs will be "good enough" for some time so the Hardware will not be terribly outdated the time the Software reaches a usable state.
3. Smartphone hardware and manufacturing matured a lot in general so it's likely easier to get sth. working with a limited budget. In comparison the Openmoko devices were reasonably advanced for their time but were also ridden by hardware bugs.
You don’t need your Raspberry PI to run your bank app, handle your payments or your bus-tickets. I’m not sure how I’d even purchase a non digital ticket for quite a few things in Denmark.
Don’t get me wrong, I really hope something like PinePhone sees enough adoption to get the apps I need a smartphone to run so I can break away from the two monopolies. I just don’t believe it will happen when Microsoft couldn’t do it.
Microsoft couldn't do it because everyone new (of the users) that even if they put in their effort to switch and wait for the ecosystem to grow, they will end up with just the same crap: another closed-source monopoly with it's own quirks. We won't have just two overlords, but instead 3 of the same. Wow such a difference...
Now an truly open system might make a difference. Not saying it will, it has it's own problems, but comparing it to Windows Phone is not really apples to apples.
The third party app platform was pretty slow and missing a lot of APIs relative to the others. The first party UI, which got praise from reviewers for being smooth, was written in a different language and framework.
In the first version, the default blank app from Visual Studio's "new project" wizard was slow to load. I think I measured it on the order of 500ms at the time. Not much room for third parties to add more stuff without being slow.
The only question I'd ask is : how many phones should they sell to break even ? Cos if they actually make some profit, that's just fine. Maybe they don't aim to go to mass market. And that's why MSFT may have failed : they tried to fight on Google's ground, head to head. Of course Pine can't do that. So if they just repeat what's been done for Raspberry, that's just great enough to have a living ecosystem.
I personaly just need SMS, voice and a browser. The rest, I can live without it (or program it :-)
You greatly overestimate the number of users who care about how closed or how open an ecosystem is.
If the user can't interact with their bank, whatchu YouTube, talk to their friends and parents over Snapchat or Skype, call Uber, play Spotify, etc etc etc, it doesn't matter in the least if your phone is 100% open source.
Microsoft had sunk billions into trying to get the ecosystem off the ground. What makes you think that "a truly open system" will get that ecosystem?
> If the user can't interact with their bank, whatchu YouTube, talk to their friends and parents over Snapchat or Skype, call Uber, play Spotify, etc etc etc, it doesn't matter in the least if your phone is 100% open source.
Most of this should be available on the PinePhone at launch (albeit not as nicely as on Android).
Bank - should have a website (and if they don't have a website they most likely don't have an app anyway)
YouTube - website again (youtube.com)
Skype - has a web app and a Electron app available for Linux (web.skype.com)
Uber - has a PWA that can be used for booking rides (m.uber.com)
Spotify - has a web app and a Electron app available for Linux (open.spotify.com)
My bank app has significantly better usability than the website because it can mostly cache credentials and support a short login procedure. Or use the fingerprint scanner.
Not really, among "normal" banks. This does seem to be the case with the new "challenger" banks like Monzo and Starling, which are all "mobile first" and are basically impossible to use if you don't have an Android/iPhone. But every regular bank in the UK has a website with online banking, often with more functionality than the apps, but maybe this is different in other countries - online banking in the UK has been commonplace since before mobile apps were really a thing.
Funnily enough, my last bank and two current ones, the app is increasingly a front for a mobile web version. With each new update I see more functionality moving to web.
I have an account with Bank of America and was not aware of this so thanks. That said, you can do pretty much everything else via the website. The opposite is also probably true, that there are some features on the website not available on the app (for example can you open a new CD in the app?).
The target audience isn't people who need to use Skype, Snapchat, or Uber. But I'm sure it will be possible to run some of those android apps through anbox. Spotify has a Linux client, and for YouTube there's the FreeTube client, which actually protects users' integrity.
I love them, thanks to it I have refocused on mobile Web, even though I tend to prefer native apps.
For traditional CRUD apps, PWAs are quite alright, and one avoids having to deal with Android's always changing "best practices", with a stagnant Android Java.
So how do people without phones participate in society? I don't use a google account on my phone, so that means no App Store. I'm trying to one day get rid of my google account too. It doesn't cause me many issues in the UK though I can't use things like Uber, and that's no loss to me.
The UK government "settled status" application procedure for EU nationals resident after Brexit was only available as an Android app. Otherwise you had to apply in person at a specific site.
There are a few things you cannot do. In some areas of Copenhagen you can't pay for parking without an app, I'm told (but I don't drive so I don't know for sure).
The biggest mobile-only thing is an app called MobilePay which is used mostly for person-to-person transfers, and a lot of people don't use cash at all anymore. I am starting to see classified ads that specify "MobilePay only", although I guess you could usually convince people to accept a bank transfer instead. A lot of shops also accept it, but there is a law that shops have to accept cash, but some places don't respect it. Very few shops don't accept credit cards, but these generally also like cash...
As for digitization in general, all communication with the municipality and state and things like your bank and insurance company is digital. You're required by law to have a bank account and to have it associated with your personal ID number (all Danish residents are tagged with their birthday + 4 digit code in the Central Person Register). This all goes via a website that works with all browsers, though, but I wouldn't be surprised if down the line some features started being smartphone/app store only.
"There are a few things you cannot do. In some areas of Copenhagen you can't pay for parking without an app, I'm told (but I don't drive so I don't know for sure)."
What are the permissions granted to these apps ?
Do they, as I fear, "require" full access to all contacts, all photos, location data ... ?
> So how do people without phones participate in society?
It's not super hard. Until ~3'ish years ago I did not have a smartphone here in DK.
Life is just so much easier with it.
I think they got rid of the 10x Bus ticket you would buy at a kiosk, so now you have to buy a single tickets with coins inside the bus. (depends on the city) Which means you need cash. DK society is very much cashless, I mostly see older people still using it.
Is the bus late or did you just miss it? Check the app to see the bus location.
Train Ticket? Now you have to print that out or buy it at the station. It's so easy to search, buy and show the ticket via the app.
Letter from most public authorities / government? There is an app for that. Or website.
Want to give your mate some money? -> MobilePay app. Now you have to get cash somewhere and convince him to take cash. Or go to a computer and transfer it. Which requires more information then just this number and takes longer.
Just buying a rejsekort (travel card - you put some money on it at some machine with your credit card and it pays automatically when you check out at the end of your trip. It also has a significant discount vs buying individual tickets) solve all the problems for buses, trains, metro, etc. You can also put your commuter card on it if you want, or you can receive a commuter card by text message which would even work with a dumb phone.
But it certainly helps a lot to have a smartphone, mainly for the government messages and the nem id app.
Sounds like Sweden. About 10 years ago I was very surprised to be able to pay for a bus journey using my (foreign) debit card. Now it's normal in the UK. And I have Swedish friends who have never seen the newly issued currency.
Crazy but it's the future. It's just a shame that it's gatekept by unaccountable duopolies such as Google...
Funny you should mention that, my Google account got somehow restricted yesterday due to Google Pay not liking my rooted phone. Now not only can I not pay with the phone, but I have to submit all my private information to a random Google web page, hope someone sees this, hope they agree it's correct, and hope that this was the problem in the first place (since all the app says is "this operation cannot be completed").
In summary, fuck Google. This is why I want cryptocurrency to succeed. I don't want corporations deciding how I spend my own money.
Imagine future cashless society with mobile-only payments. And a smart-car that needs a phone to open/start. And a smart-home with front-door unlocked with a phone. If you loose/break your phone - no problem, you can replace it with a new one, borrow one or use that old phone you keep in a drawer just in case. Not a huge deal. But if your account gets locked you have a problem. I'm afraid we as a society are giving too much control to a few corporations. It's not that of a problem yet of course
And that's the problem, that it's going to be insidiously gradual. These lockouts will mostly be seen as acts of God, things that happen to the less fortunate other people and not us. As long as they're kept rare enough, people won't bother solving them, like what happens with countless other things.
You don't need to wait! Visit China today. In all seriousness they are heading this way - you need a WeChat account to do or pay for just about anything, you will soon need face verification to sign in to any internet service, and fingerprint readers on doors are very much a thing.
According to the Lloyds website they (and other UK banks) are going to start sending an auth code to your phone as part of the web logon. Though I believe you can ask them to send you a security gadget as an alternative. It is a PITA though.
I'm in Canada and access Uber via their PWA. m.uber.com I think, I just did the "add to home screen" thing and it launches as a fullscreen web app. No need to have the app installed.
It has its own issues indeed, I don't deny that. But that used to be the same for Ubuntu when the Windows-only culture was at its highest. People who want this phone will use workarounds, custom apps, anbox or just web apps.
It wasn't that Microsoft couldn't do it, it's that they chose not to.
Through all of Windows phone 7, 8 and 8.1, the devices that were selling were low end devices -- things like the Lumia 520, especially in markets with more cost sensitivity. Because of software architecture differences, windows phone was often more responsive than android on bottom of the market phones, and that drove sales. But when it came time to release Windows Mobile 10, there were no low end phones.
Having to build out essentially three flavors of your app (one for 7, one for 8, and a 'universal' app for 10) isn't a great way to keep developers engaged either.
That's the point. You have a real computer, then you have a rpi to play with, do some hobby work around it, etc. If you're buying it as an analog to some flagship phone, don't.
I could see it being used for specific usage handheld devices. For example where I work, we sell train tickets and ship cheap Android phones with an app installed for tain conductors to scan the ticket barcodes. Something like this could be done with some "generic cheap Linux device with a touchscreen and mobile connection" locked down to a custom built app.
Not sure if that ends up being cost effective considering how cheap you can get low-end Android phones these days, and how easy it is to find Android developers, but I'm sure there are some applications along those lines that would be well suited for the equivalent of "a Raspberry Pi with a touchscreen and smaller form factor".
Mine was unusable until I installed Android, at which point I bought an Android phone a quarter of the thickness and mass, and better screen resolution (and likely better radios as well).
I too bought it because I thought I'd hack around and "maybe contribute" which quickly turn in "why am I wasting so much time on something that will probably never work".
For most people "quirks" are unacceptable in their mobile phones. Normally one can't afford to lose a call or to have the maps application crash when you're trying to get around.
Give FOSS phones the same media coverage of the iPhone, possibly including its ad induced reality distortion field, and they will sell like candies.
Seriously, once the software is ready, 30 seconds of any popular celebrity showing one would make it sell hundreds thousands in a week. Problem is the small manufacturers couldn't either pay for that level of advertising or satisfy the demand without turning themselves into what they're fighting against now (venture capital, investors etc. don't come free), so I welcome numbers as small as 13k or even much less if that means the product isn't polluted by the typical corporate mindset (close as much as possible to protect intellectual property, make it obsolete sooner to sell newer models, etc).
Oh and by having an unusual phone I can also play the elitist bastard with friends:*)
Interesting point. I have seen some friends happily using Windows phones but most of them were/are either Microsoft employees or working mostly with Windows software, so I guess they needed the deepest integration with the Windows ecosystem, which is understandable.
As for other users, it is possible that Windows phones had either some limitation compared to other platforms or they lacked the killer app that would make it appealing to other userbases.
Having never used one, I can only speculate that MS wanted to change too much too early by making an user interface very consistent with the one they introduced on PCs but hard to digest just like that one, and this could have brought users away both from the PC and mobile devices. I have always found in the past very hard to migrate non technical users from Windows to Linux, but the adoption of the new interfaces from Windows 8 onward made some people I know so furious that it became really easy to convince them to try Linux; in some cases it was them who asked me to install it. That would be unthinkable before Windows 8. In the mobile world I guess it was even harder to grow an userbase since the alternative was already mainstream.
They probably should have copied or mocked a mainstream mobile interface, that is, offer something an user from either Android or iOS would not find alien to use, then offer something more, say free Office apps, then after the userbase had grown start to build the rest.
> They probably should have copied or mocked a mainstream mobile interface, that is, offer something an user from either Android or iOS would not find alien to use, then offer something more, say free Office apps, then after the userbase had grown start to build the rest.
Why would the user base grow? The main problem Windows Phone had was the dearth of apps that users actually wanted. MS had to build their own YouTube client (and IIRC got into trouble with Google).
They've sunk billions into it: enticing developers, outright paying for the development of apps, creating apps on their own, spending huge amounts of money on advertisement (I remember at one point when half of popular TV shows featured Windows Phones). The result?
It did sell ~100 million phones in about 5 years and then discontinued the entire enterprise.
So, back to the original claim:
> Give FOSS phones the same media coverage of the iPhone, possibly including its ad induced reality distortion field, and they will sell like candies.
Why would it work for a FOSS phone when it didn't for MS?
Because the number of potential developers on this platform is at least an order of magnitude bigger than all Windows Mobile developers on this planet. Probably more. Developers also that happen to be the first users as well, an aspect very different from the one Windows Mobile had to struggle into.
If ths thing turns out as interesting as it promises there would be hundreds thousands of people willing to work on various tasks to bring it on par with other platforms. That day we'd have to find a benevolent dictator, sort of a mobile version of Linus Torvalds, which would direct them various teams right to the spot, since it's very likely that groups being working on say accounting software (just to name the most boring thing to me if I was in their shoes) would proceed at 1/4 speed compared to those working on say video acceleration or networking tools.
It will start as a community toy, then one day, possibly after the 2nd or 3rd model, normal phones users will start to notice that little thing that doesn't get advertising, doesn't ask for DNA when installing apps, doesn't spy what the user says, writes, buys or where he/she goes and when, consumes a fraction of their metered data plan since great part of it (ads/junk/telemetry) has been blocked or never requested/created by design, offers equivalent non spying apps etc, all at the cost of avoiding the usual social media apps (I assume FB/TW will never allow a port of their clients there, especially if sandboxed). For some people losing FB/TW or GMaps could be too much, but others wouldn't care. It will slowly but steadily gain a good mostly technical userbase. If I had a date to be concerned about, it will be the day its growing userbase size could raise a flag in some offices, so that the following day the folks that made it possible will get a huge offer to sell the entire operation. That eventuality would deem the project to become a copy of any other platform out there. There's hardware production involved; forking the blueprints wouldn't be enough.
> Because the number of potential developers on this platform is at least an order of magnitude bigger than all Windows Mobile developers on this planet.
Why? Where do these potential devs suddenly come from? Just fro the fact it's a FOSS phone? Looking at how Linux has struggled for years (and is still struggling) to get decent software, your premise seems broken.
> If ths thing turns out as interesting as it promises there would be hundreds thousands of people willing to work on various tasks to bring it on par with other platforms.
Why would they? Why would there be hundreds of thousands of such people? Especially considering that the vast majority of software is commercial software that needs users.
Users do not flock to something just because developers do.
> It will start as a community toy, then one day, possibly after the 2nd or 3rd model
And then you list dozens of things each of which has a very low probability of happening. And then those improbabilities compound.
> For some people losing FB/TW or GMaps could be too much, but others wouldn't care. It will slowly but steadily gain a good mostly technical userbase.
You underestimate the numbers in this "mostly technical userbase". It's not the first phone to cater to a "mostly technical userbase". None of these phones survived past a first iteration. Somehow, no thought is given to why these projects failed. But the new one will surely become popular, will have multiple iterations and a good user base.
Yeah, sure.
The definition of insanity: doing the same thing over and over again and expecting different results
It was working, but Microsoft didn't have the patience to wait, and wasn't willing to be number 3 for a long time. If Microsoft had continued the project they could have continued to be a distant third place making enough money to keep the lights on in that division - but it would never be insanely profitable and they were not willing to settle for that.
The market had already spoken by the time MS discontinued the project. Windows Phone reached a peak of about 3.5% of users and then started declining, quite rapidly.
Given that ~100% of money was going to the iOS and Android ecosystem, MS had no chance to retain even a few percent of the market: developers would not be interested in developing software for an obscure system that brings in no money, users would not be interested in a phone with little to no software.
Netscape was a commercial failure but Mozilla is still around. Similarly Blender only went open-source after a crowdfunding campaign.
CyanogenMod is another interesting example, mostly open source and mostly successful until it started trying to commercialize the code.
I think the community ends up being a big part of it. It's not like every PinePhone shipped is going to result in another developer for the OS, but there is some critical mass point where the software goes from broken to usable and it seems PinePhone might be getting there.
It's becoming easier and easier to develop new products in this space. Hell, there are a few "open source" phone projects out there that are just white label products imported from China.
The first Neo phone was released a year before the first Android smartphone even hit the market. It's a bit unfair to compare these new projects with something like OpenMoko.
I dual booted into DOS and Windows 3.1 for a long time after I first installed Linux. I would see a similar situation if I used a stock smartphone and had a free phone, I might use them interchangably for years before switching, but it would still be worthwhile.
An open internet-connected battery-powered computing device that looks great and can easily fit in pocket? I would gladly carry it along regardless of its phone functionalities. It looks perfect as smart remote for automating stuff around me, maybe one day even as voice-enabled personal assistant device.
"Of course, no one wants to place phone calls by typing a lengthy command into their terminal"
Are you kidding ? That is all I've ever wanted to do.
I have been asking, casually, for a "gnu-phoneutils" package for several years that would give us a small phone tooling suite ...
I have largely built this out myself with twilio and, in some ways, it is no longer necessary given that I have built my own little mini-telco inside of twilio, but still ...
Can you provide more info on this Twilio mini-telco? I’ve been working on something similar to work around the lack of well supported libraries for telephony
My phone uses a sim card from a verizon MVNO. I don't even know the phone number.
"My" phone number was provisioned, and has always lived, in Twilio.
I set up a simple call forward and SMS forward to my SIM number. When I land in a foreign country, I get a new sim card and just point the forwards to the new number. Easy.
I wrote a shell script that allows me to SMS from the command line from my phone number. So I can SMS people from an airplane even though my handset is off. If I lost my handset I could still SMS you.
It's also nice to have a proper date/time stamped SMS log that lives in /var/mail/sms ... I use this a lot.
My favorite thing about all of this is that I have finally removed voicemail from my life. Hint: you need to tell your carrier, with star-71, to forward to a "black hole" number at the end of your call sequence, otherwise verizon will jump in and say "the wireless blah blah voicemail box that is not set up blah blah ...". So my twilio number rings for X seconds (whatever I set the timeout to) but then the call progresses to verizon, but verizon has been instructed with star-71 command to forward calls to a second number I set up in twilio that does nothing but hang up. That's my "black hole" number and you can insert that into the end of a lot of workflows like this.
Calling has to be done with a voip app on your phone because, of course, you cannot call from your twilio number directly from your phone. Well, you could, if perhaps you called yourself and then set up some logic where you type in the phone number you really want and then twilio forwards you there, but I think it's easier to use a nice VOIP app ... I use groundwire, but whatever works.
I might try to formalize all of this and present it at Signal next year ... there are a lot of other neat things you can do ....
Neat! I have a similar setup, except a little more native support because of Twilio Wireless (not sure if you know about this? https://www.twilio.com/wireless)
I have the Twilio SIM (T-Mobile coverage) in my primary SIM (iPhone dual sim), and then Verizon/ATT/Sprint/TMobile on my e-sim. The e-sim is for data only, because data is expensive (and slow) on Twilio. If you don't have Dual Sim then the data element may be a bit of a roadblock for you to totally switch over to the Twilio SIM depending on your data needs. Tthe goal of my setup is to be completely cell phone agnostic. I wanted to be able to send a single signal into the PSTN over an IP connection OR over a cell-only connection (no data). The native support on this is great when you use the Twilio SIM, but with call forwarding and some other hacks you can get support without the Twilio SIM. Also, the great thing about the SIM is that I can pop it into a phone from 2002, and have it talk to the internet through a series of signals sent via SMS (e.g. server maintenance, open up a firewall for a few moments, etc). I wrote a server that I point the SIM endpoint to, and this server handles all of the forwarding/reception of voice and SMS.
I also built out a CLI for messaging (pulls in SMS history, deletes from Twilio, stores locally encrypted, lets you send out messages on a "convo" view, etc)... using the python API, and then built out a Web UI for making phone calls using client.js (receiving phone calls TBD). This has integrated support with my CardDav contacts (and depending on if someone is in my contacts, they get a different number on the caller ID), which makes for a more powerful (IMO) app than an iOS VOIP app, of which the options are fairly clunky and limited.
It is all pretty hacky but if you want to talk more about it I am curious to see what you have built out. I am not totally dependent on it for a few reasons, a big one being that I don't want to send all of my communications through the unencrypted telephone network.. The long-term goal here is to package it and open-source it so that people can easily "free" their communications, but it is pretty scattered right now.
Eagerly awaiting the PinePhone to give me more flexibility with all of this.
Yes, I do have some of the Twilio SIMs but I live in a verizon-only zone so ...
Interesting how you are sending SMS with different caller-ID based on contacts, but I am curious - without a VOIP dialer, can you place voice calls from your native dialer with different caller ID ?
Please, please email (or trouble ticket) twilio and ask them to add an "email" verb to twiml ...
That is one of the big missing links in all of this - you should be able to fire off email alerts/messages in your twiml workflow without any third-party[1] integration or other accounts/logins, etc.
[1] I would still consider sendgrid third party since I need a different login, account, etc.
> Interesting how you are sending SMS with different caller-ID based on contacts, but I am curious - without a VOIP dialer, can you place voice calls from your native dialer with different caller ID ?
Yes it is not very pleasant, and it is how you basically described it where you call a Twilio number, and then type in the destination. You could set up some sort of signaling where you activate the outbound number with an SMS which may be less cumbersome than dialing on a phone call, but for native support that is the only way I can think of -- just dialing the target number would of course route from your main Telco
A decent SIP app might be an alternative here, I haven't explored them thoroughly because of Twilio Wireless (last I checked they weren't spectacular, but SIP is good)
Here is a possible way to call from the native dialer in the event that data is not available...
One can prepend a calling card-like sequence, using hard and soft pauses, before the actual telephone number gets called so all calls get routed through twilio (or any VoIP carrier) for managing the caller id.
In other words, you are calling your personal calling card telephone number for every call so you will enter in your code and then enter the telephone number that you would like to call.
"You could set up some sort of signaling where you activate the outbound number with an SMS ..."
Thanks - that is a great idea and I might consider implementing that ...
I think a SIP/VOIP app might be cleaner, and I see that some VOIP apps now support SMS, if I understand correctly ? Call quality and volume issues are a side-effect of the voip dialers, though ...
For people who are looking for a similar setup, jmp.chat is an alternative service built on free software and a voip provider like twilio. They forward SMS over XMPP and you can make calls with any old SIP client. Its literally a bunch of ruby scripts, a very charming project. I jumped ship from twilio after they made payments without a credit card impossible for small-timers like myself.
We don't always provide our complete number list at https://jmp.chat/ - as an example, we usually have off-list numbers available in area codes like 416 and 212.
Just message the JMP support number (+1 416 993 8000) or my Jabber ID, denver@ozg.ca , to let us know which area code(s) you're interested in and we can send you a number list.
Google Voice (née GrandCentral) also has the phone number indirection-layer feature. It's a product and not a developer tool, so it lacks some of the more advanced features (eg command line access), but it's far more accessible to non-developers.
Google's uses Google Voice as part of GoogleFi, so hopeful it won't be killed off any time soon.
Similar to what the parents does, I use "conditional call forwarding" to send all non-answered calls to Google Voice. When I get a voicemail, GVoice then sends me a transcription of the message.
> if perhaps you called yourself and then set up some logic where you type in the phone number you really want and then twilio forwards you there
It would be cumbersome to have to do that manually, but have you looked into any of the 3rd-party dialer apps on Android? They'll dial the prefix specified before dialing the number that was entered.
Yes, I have - and indeed that would solve a major usability issue - however I live in a ATT/Tmobile dead-zone and the Twilio SIMs are issued by T-Mobile ...
So I have some weirdness in my workflow just to connect to VZW.
Oh, btw - if you use a verizon MVNO, use US Mobile and not straighttalk because straighttalk does not allow tethering whereas US Mobile does ...
EDIT: one more thing ... using a voip dialer instead of the native iOS dialer is a bit clunky but it also gives me the ability to dial from any of my twilio numbers. So I can pick my "from" number - either personal or rsync.net or (throwaway personal that we give to salespeople). So there is a pro/con involved in using a twilio SIM and the native dialer vs. using a voip dialer...
Certainly it costs some amount more because I pay for US Mobile (verizon MVNO) and then the twilio fees, but I think my monthly Twilio bill is negligible ...
I've used an OpenMoko Freerunner as my sole phone for about 10 years. Their freesmartphone.org API is pretty nice: it uses a daemon (the v1 reference implementation used Python, I think v2 uses Vala) which accepts commands over DBus.
There's a program called "cli-framework" for commandline interaction; it opens a Python terminal with a library that wraps the DBus API. I've not used the commandline for calls, but I have used it to read and delete SMS (when I'm too lazy to go and pick up the handset, so I SSH into it instead ;) ).
One project I've not gotten round to yet is an answering machine, so calls are immediately answered and audible (via headset), and I can choose whether or not to "pick up". This looks like it would be easy enough with the freesmartphone.org API, some Python and GTK+.
From what I can tell, this isn't possible on Android due to the API not allowing access to calls. Symbian allowed it, and it seems to have a few answering machine apps.
The only thing I would fix is the "lengthy" part. I want it to be a simple command (I suppose I could wrap it or alias it), but other than that it sounds perfect.
You might want to check out jmp.chat ... it does SMS via XMPP and can place phone calls via SIP all on a fully free-software stack that you could modify and use independently if desired.
That's extremely exciting news! Working LTE? No blobs? "Holy shit!" is an understatement.
Tangentially, what's an appropriate entry point for a reasonably capable C/C++/Unix systems programmer without prior mobile guts experience interested in working on software for this platform? I'm kind of assuming that'd be "grab a compatible device, clone postmarket, rtfm" but confirmation/pointers would be appreciated.
I hate to temper your excitement a little bit (I am excited too!), but I am not a bit surprised that LTE data works. Calling and SMS/MMS over LTE (for T-Mobile USA) are two things that at least that as of today, you need proprietary libraries to have it function on Android, and likely don't work on the Pinephone. I strongly suspect that other USA carriers will have the same issue (I say that because there are additionally several proprietary Verizon and Sprint blobs that are resident in factory images that need to be put in third party ROMs).
The Librem 5 has LTE mobile data as well, but it has those same issues (no VoLTE, SMS only over 3g, no MMS for T-Mobile USA). I am hopeful that between Purism and the Pinephone community that this is a solvable (but lengthy) issue.
Is that really where the goalpost is though? I thought everyone accepted that the modem itself would always be proprietary, and that was OK as long as it had a killswitch and no ability to directly interfere with the main processor or RAM. (The mostly-userland stack to drive the modem to send SMS etc. would be open.)
It seems right to me that the FCC et al shouldn't allow uncertified amateur radio firmwares.
"Is that really where the goalpost is though? I thought everyone accepted that the modem itself would always be proprietary, and that was OK as long as it had a killswitch and no ability to directly interfere with the main processor or RAM."
Most of the time when we speak about the baseband, we are talking about the telco network interface between your handset and the carrier ... and so it's tempting to think of the baseband as just some black-box modem that you can firewall yourself from.
However, the baseband processor also performs a number of real-time voice quality / noise cancelling / audio functions that really have nothing to do with the network interface, but are very important depending on how sensitive you are to call quality and things like echo, etc.
This is unfortunate because, like you, I would like to just wall of the baseband and use it as a modem and forget about it, but that perceptible difference in call-quality between "actual carrier" calls and VOIP calls is due to the baseband.
I believe that is all still true in the 2019 LTE era ...
Depends on the human defining where the goalpost is, what their threat model is and their philosophy etc. There are certainly folks who want open basebands enough to work on them, for example there are folks working on porting the Osmocom baseband codebase to Mediatek based phones.
VOIP over LTE has been rock solid in my experience with T-Mobile on the east coast. I regularly get on (hands-free) VOIP Zoom calls during my 20 mile commute and almost never have any latency or packet loss issues.
LTE latency is more than adequate for VoIP, with RTT latency to the tower being around 25ms. Adding another 40, 60, whatever, internet latency for VoIP is still well within the realm of good call quality.
Fair enough. I must have a shitty network. I see 150-200ms pings through LTE with occasional spikes up to 500ms, and any VOIP is both poor quality and we end up talking over each other because of the latency.
Don't all messaging apps like Viber, Whatsapp, telegram etc technically use VOIP, or at least the same type of technology as VOIP? The quality is quite good, for a lot of people.
T-Mobile USA's system is bog-standard IMS with RCS extensions. There are a few open source client stacks that support this, notably Doubango's. The trick is writing a frontend that uses regular Linux GUI libraries. As far as I know, nobody has done that yet...
Telepathy seems to be dying on desktop GNU/Linux, the existing clients in GNOME/etc are being replaced by protocol-specific applications. New protocol plugins seem to happen more in Pidgin/libpurple these days.
Well screw T-Mobile then honestly. This in addition to their (from what I understand) abuse of the FCC TV white space database kind of undoes any goodwill they had in my mind.
I don't know if it's just T-Mobile doing that. I've never tried using AT&T, Verizon, or Sprint with a purely AOSP (only compiled using the instructions on Android's website, not also including other proprietary blobls) or with my Librem 5, so I don't know if this is a T-Mobile only thing, or if it's industry wide.
Could I get more details on T-Mobile's abuse of the FCC's TV Whitespace database? I know they currently do spectrum hijacking with License Assisted Access in the 5Ghz band, I'm curious what their other abuses are tho.
Note that unlike other typical smartphones, this one has the modem as a separate module, so "no blobs" really means more that the FW for it is not easily accessible; but it's obviously there and working.
Drew (Or sircmpwn? Sorry I don't know how you prefer to be called) since I know you're on here, if I may ask:
- What provider are you using?
- Is it VoLTE that is working, or does it drop down to 3g for calls?
- Does SMS work in LTE mode or do you have to drop it down to 3g?
I have a Librem 5 birch, and from my experience in rolling my own Android AOSP version, that to get T-mobile to work with VoLTE, SMS/MMS with LTE, or WiFi Calling, you have to install proprietary blobs.
EDIT: I should add the Librem 5 Birch has LTE data on T-mobile, but I have to drop to 3G to get SMS and phone call functionality, and MMS is additionally non-functional at all on T-Mobile. Meant to post that for the Librem 5.
- SMS seems to work fine in LTE mode, but don't quote me on that. I tested everything once just to understand how it worked, then put it on the backburner to work on other stuff.
MMS is just a SMS with a hash or link which combined with a HTTP proxy is then automatically loaded. It is a way to remotely load a picture, on a remote device. Not sure I actually want that feature. I always disable it on my SIM card.
Not trying to downplay, other people might prefer it. VoLTE provides a security and usability benefit over 2G, as does not using 2G/3G as backward compatibility.
The killer feature I use MMS for is group texts. In an ideal world I could host my own matrix channel on my server to use, but I know that I would have exactly one user on it. I refuse to use WhatsApp/Facebook messenger/Viber/your favorite chat program, and MMS is the least common denominator.
- It's the least common dominator to chat with anyone with a Phone (if you have a smartphone, you can go MMS group chat).
- I am not giving another company personal data (Facebook, Google, etc.)
Ideally, I would prefer to run my own server for a chat program (i.e. Matrix, Nextcloud Chat), then I know where the traffic is coming to and from, and I have a lot of confidence that personal data isn't being leaked.
My second option would probably be Signal, as they seem to do to great lengths to avoid collecting data on you. However, trying to convince family/friends to use either is an uphill battle (a great deal of my family goes "why don't you just get an iPhone?"). So the pragmatist in me just uses MMS for group chat.
It doesn't bother me, don't get me wrong, I'm just curious. You have to start somewhere! I am really excited to see both this and the Librem 5 get off the ground.
VoLTE requires carrier support unless some very clever hacks I'm unaware. I am pretty sure that's the case with PinePhone as well, meaning it will drop to 3G.
I assume they want to support it, as well as any other carrier feature. I just have no knowledge on how difficult it is, nor in what state it is in now.
It's cool that he's writing his own shell but I think that Ubuntu Touch as maintained by Ubports is worth a mention as it's going to be one of the available options for the Pine Phone.
The UI is slick and well developed. The app ecosystem isn't amazing but you get a browser, choice of Telegram clients, Signal client etc. You can get an idea of the range of apps here https://open-store.io/?sort=-updated_date&type=app
HN readers might like to note that there is also an established developer community and resources like documentation.
Well worth a look if you're thinking of getting a Pinephone, and / or developing a anything for it.
I keep thinking that we might take this opportunity of rebuilding an OS from the ground up to implement something like Plan 9. The usual adoption issue of drivers and apps seems irrelevant here.
Fundamentally, its distributed nature would allow far greater integration between desktop and mobile hardware. Mobile + laptop + NAS would be so deeply integrated that they would better be considered a single computer with multiple more-or-less accessible terminals - and if a mobile device was part of that integration, it would represent a sea change in the utility of smartphones. I'm personally a big fan of how a mobile device could 'automatically' use the processing power of a Plan 9 desktop whenever they're both on the home network.
(just a plan 9 newbie that is enamoured of the system design)
Edit: BTW, pretty sure this is what Google's project fuschia is based on.
Except that the browser on UBT is bare-bones, allows no extension and has virtually no useful option. Ubuntu Touch could be almost be a usable system if it has a good enough browser, a good enough email client and a good enough chat application. It has none of them.
IMO, Librem5 and PinePhone are the most exciting news of this decade w.r.t mobile ecosystem for hackers, tinkerers, enthusiasts.
Librem5 stuck to its security, privacy first agenda and managed to build a phone with PC grade hardware. PinePhone stuck to its affordability first agenda, bringing a Linux capable smartphone hardware to the masses.
My only wish is that these project become commercially sustainable and attractive enough for the major smartphone brands to join open-source party to make a dent in the Appstore/Playstore duopoly.
I think Windows Mobile gave up just prior to the best chance of breaking the duopoly: PWAs. Most app developers will never want to support a half a dozen phone OSes. The solution will inevitably, eventually, be the web.
I'm not sure how much effort went into supporting PWAs for Windows Phone, I used to develop for that ecosystem during 8.x and the browser was a mess; cordova apps for WP required specific hacks to basic elements such as header, footer etc.
Besides, they where making good progress with supporting android apps in WP with 'Project Astoria' and iOS apps with 'Project islandwood'; both of those were pulled off abruptly. There was even a rumour in the WP community at that point that Project Astoria became too good that MS brass worried that native WP development may go extinct.
Btw, recently german WP enthusiasts managed to get Project Astoria working on several WP phones[1].
This is turning to "Linux for desktop" really fast. Or really slow depends how you look at it.
Even the web does not look like the web anymore. I am not even sure what do you mean by "the solution will inevitably be the web". The solution for supporting half a dozen phone OSes will be fewer phone OSes. If you think that nobody will want to develop half a dozen versions of the app natively, why do you think they will want to debug PWAs on half a dozen OSes?
I pre-ordered a braveheart and cannot wait to start contributing code to make mobile Linux more usable! Of course it's not the right phone for many people yet, but what the Pinephone symbolizes is the first affordable and (hopefully) widely available Linux phone. What made me pull the trigger is that, unlike others such as Librem, Pine64 seems to be taking a similar approach to the Raspberry Pi. Instead of reinventing the wheel and forcing users into custom software like Librem has done with Phosh, Pine64 is building a launchpad for existing projects such as PostmarketOS, Plasma Mobile, Manjaro ARM, UBports, and others to grow their visions. If you build it, they will come (and hopefully submit pull requests)!
I'm very enthusiastic about this device and have ordered the Brave Heart addition. I really like the price point of $150. It makes it pretty easy for casual developers to pick one up and should aid with getting new software written for it.
I'm sure the Librem 5 is also very nice, but it's higher price makes it much less accessible.
As long as I can run Firefox on it, and it got a micro-SIM, I'm good. There's a web alternative for most apps I use, where besides that I just need a tiny computer in my pocket with constant connection to the internet (hence, micro-SIM).
I use Firefox (desktop) on mine and it works quite well, and has good performance. I wonder if it can be configured to be a bit more mobile-friendly OOTB, maybe with some about:config flags?
There's a meta-bug on Bugzilla for adding a mobile-style frontend to desktop Firefox for the Librem 5 and Pinephone: https://bugzilla.mozilla.org/show_bug.cgi?id=1579348 Not a lot of work has been done since hardware has been scarce so it has not been a high priority.
The Boot 2 Gecko OS was the community-developed successor of FirefoxOS and KaiOS is the commercial proprietary fork of B2G but unfortunately B2G is no longer maintained:
Maybe it could be called a 3G modem platform instead of a phone.
To write UI software for a modern phone takes 150+ full time engineers in my experience. Only few organisations have this capability and this is why these things will never be phones people use.
purism already did it with a handful. Their new shell has a great design in my opinion and it runs ok. I'm not a fan of plasma mobile but it seems ok too. The hard part it seems to me is the layers below the actual UI, gpu support, energy consumption etc.
I'm confident these shells will get to the point where they are maybe better for the average phone user than desktop linux shells are for the average desktop user, mostly because reasonable phone UI patterns are more narrowly defined.
I'll bet apps support and camera quality will remain bigger deal killers after the shells mature some more.
> To write UI software for a modern phone takes 150+ full time engineers in my experience.
That's a bit like saying that you have to drive 150 km/h to get to Paris. What's the time budget? Where are they now? What are the goals? Surely you can imagine ways that the answers to these questions can vary enough between commercial and open source community projects that saying that you need 150+ engineers is a meaningless statement on its own.
Wouldn't be too pessimistic on the UI side. Building decent desktop UIs isn't easier and still people managed to do it without a (single) organization in the background.
It takes that much the first time you do it. A lot of time and energy goes not simply into writing the code, but into figuring out (through writing wrong code many times and then rebuilding it) how the UI really should work, feel, look, etc. But now they have the advantage of already seing all those results and knowing exactly what they need to build. This save a lot of time.
At least on the design side, this is a good opportunity for up and coming UX designers to build portfolio pieces while also being useful (instead of redesigning Spotify for the 1000th time).
The phone he always wanted is a phone that basically doesn’t work at all? Like, not even as an equivalence to a typical smartphone, but even a dumb phone?
I also yearn for a FOSS/Linux phone, and it feels like we’re getting closer, bit I feel like the author is fooling themself a bit.
> The phone he always wanted is a phone that basically doesn’t work at all?
I feel like it is intellectually dishonest to characterize the phone mainly as "not working" and question his decision on that basis. That's not the reason that he wants it. It's the prospect of helping build and eventually having a FOSS phone ecosystem that is the main draw.
> I also yearn for a FOSS/Linux phone, and it feels like we’re getting closer
Guess why. Is it because a) some driven developers buy this product long before it is generally useful to develop the software necessary to support a full-fledged FOSS phone, or b) because people like you are patiently waiting for that software to drop in your lap?
God, I want to mess around with one of these so, so, sooo badly. But with a 14 month-old toddling around the house it would probably end up just sitting, untouched, for a indeterminate amount of time. But still...
This! I am so sad to see that practically all mobile devices on the market right now are 5+ inches. I could even go with 5, which is considered "small" nowadays, but PinePhone and Librem5 are 5.95" and 5.7" respectively. Why did phablets become the norm, at least give us a choice... :(
Large screens are more usable, small screens are more portable. There's no way to have both unless we completely rethink the mobile platform itself moving away from the dream of having one big clunky jack of all trades, but rather as a group of devices, all interconnected (mesh PAN + shared storage) and equipped with the hardware they need for the task, so that one small screen device is used as a phone, a bigger one to navigate, read bigger documents, watch movies etc, one even smaller one to shoot photos and videos, one to listen to music, record it etc.
In my experience, having used smartphones since 2008 (Nokia N95, N900, then mostly Android since), I can confidently say that 4-5 inches is a sweet spot for usability/portability. Anything less than that becomes difficult to type on and larger than that obv improves readability but you can go up to 50 inches if you disregard portability and I haven't had a 5+ inch mobile that I haven't had problems with keeping put in my shorts pocket. And handling the phone with one hand gets increasingly more difficult when you go above 5. And I think I have slightly larger than average hands (good pianist fingers).
The idiocy is focusing on slim devices. Just make them a bit thicker if the chips/circuits don't fit otherwise (and increase battery life while at it).
And yeah this was more of a ramble, not directed at your post. But I agree. I already have an Amazfit Bip (~€60) with a 3-4 week battery life that I use solely to get notifications on my wrist instead of having to pick up my phone. A watch is completely usable for anything else than a passive reading device though (at least until speech-to-text or (some kind of) gestures makes leaps forward). If as you say the devices were more interconnected (Chromecast is a step in this direction, connecting screens/TV's) the form factor of one specific becomes less important.
But, since we don't have this now, why not give the consumer a choice? My main gripe is that everything is in the 5-6 range whereas a little while back (2-3 years?) you could find a broad range of smartphones between 4-6 inches. It's gone from 100/0 in <4" vs >4" to 0/100. I would be fine to even have 20/80.
My favorite Android phone ever was the Xperia Mini Pro sk17i - a 3-inch screen slider N900-alike. Despite its tiny portability, it was not difficult to type on at all, due to its hardware keyboard - in fact the keyboard is about 30% bigger than the onscreen keyboard in a portrait Galaxy S3. It was not the thinnest, but it was palm sized and palm shaped so the ergonomics were excellent. I miss it badly.
Conspiracy theory inbound: The size of the battery is precisely tuned such that after two years of degradation, it lasts less than a day (~16 hours), so people are driven to upgrade. All thickness "improvements" are incidental.
Haha, hate to be that guy, but that's too small. The iPhone SE is about as small as I would go in order to still be able to type somewhat comfortably on a keyboard in portrait mode.
Why? Not even Mozilla had faith in Firefox OS, and on a phone like this, it's barely powerful enough to. I'm not trying to attack you, I'm just genuinely confused at this viewpoint.
None of my below rants are directed at you personally!
FF OS lives on today as KaiOS and is extremely popular in the devloping world where even an Android Go device requires far too much hardware specs for the price a given set of locals want or can afford to pay.
If you look at some of the devices that run it like the JioPhone, you can see that it sits quite comfortably in the space formerly occupied by the BREW systems of the world, but has little touches like email sending, Google Assistant, etc.
Edit: just to give some scale to the Android Go bloat (let alone plain old Android), the HTC Desire Z (https://en.wikipedia.org/wiki/HTC_Desire_Z) has 512 MB of RAM and a paltry processor, not powerful even for its day.
That device ran the current set of Android OSes at the time, and if modded today, can even be made to run Android KitKat, where official support stopped at Android Gingerbread. Today, that device is barely considered Android Go compatible, mostly due to its CPU and storage limitations.
In 2010, we took pictures, checked emails, played games, browsed the mobile web, performed calls, texts, IMs, watched videos, streamed music, and drove/bussed/walked with navigation.
Today...we do much the same things, but in a 'once more, with ~~feeling~~ AI` manner. There are very few totally new things compared to 2010, we just let mobile apps bloat up to web development-level bloat.
In my cynical moments, I look at the processing power eaten on my OS, wasted on wakelocks and ads and think to myself that somewhere, Ralphie is in the ~~Magic School Bus~~ cell phone factory and spinning dials saying 'more RAM, more CPU, more network speed, I don't know what to do, the software is all slow!' because every time he ups a spec, the bloat absorbs it without reducing user latency one bit.
512MB is not even enough (on its own) to run a user-friendly Linux desktop these days - you'll need to setup some swap to make it workable. And that's without even launching a web browser, just light native apps. ISTM that the bloat is impacting way more than just mobile.
Mozilla did not want to maintain XUL or Fennec (which was hard to develop for, jumping between layers in C++ & javascript), but Qualcomm, Facebook, Google & the bevy of manufacturers and carriers that Mozilla had rallied behind FirefoxOS forked it and continued carrying on...
I still have two Firefox OS phones (Flame and Open C) and a Kai OS phone from India (though it's useless in the USA). It's a shame the project failed as it did.
Web might be the fastest and easiest way to build a gui without worrying about platform or codesharing (opinion). It also offers a massive community and easy customer acquisition when thinking about apps from a business perspective.
TK is definitely easier than the web. Also I thought you were talking from the perspective of the user, the web is absolutely not better for them for anything other than filling out forms (in which case you just need a web page and a normalized database, not an “app.”)
Looks pretty sweet, the review is encouraging. It is nice to see no blogs, very nice. I ordered the Braveheart edition, the moment they were available.
I am pretty excited about the possibly keyboard accessory talked about in the latest blog post from pine64.
I have a couple gtk apps in progress written in python for phones using purism's libhandy. gnome builder makes it pretty darn easy, though Gtk's docs could use some love.
Woah, I didn't realize that we can use it in Python already!
How do you go about using it? I see that there's Python mentioned on https://gitlab.gnome.org/Community/Purism/libhandy but would it still not work if the phone itself doesn't have libhandy? Would you be able to install libhandy on Ubuntu Touch or Plasma Mobile?
Why do these things (pine, librem) have so much trouble producing audio? It seems like that would have been one of the first things to have got working.
In the case of the PinePhone, they aren't doing any OS/application development. So it will be up to distro spinners and upstream developers to solve the software problem.
Part of what Pine64 is trying to do is kickstart an ecosystem that gets people working on these sorts of things. It's a chicken and egg problem: there aren't currently any widely available Linux smartphones so no one is working on drivers/applications, there is minimal driver support so there are no widely available Linux smartphones. By just shipping a reasonably priced, reasonably open (as much as it can be given the cellular modem situation) phone they are solving one of the biggest problems. 2020 should be a fun and interesting year for Open Source on mobile...
The Linux platform is really really really not famous for the convenience, ease of use, stability and reliability of its audio stack. Or of its stack of audio stacks, actually...
that's good to know, I think possibly if it was more powerful would be down to use it as a "single all around device" granted I'm not doing like hardcore video processing/gaming generally just software stuff.
If you're referring to desktop Linux, it's very much not this way, for the last 5 or so years.
Installation Just Works unless you're dual booting, in which case it Just Works until Windows updates and overwrites boot files because it assumes it's the only OS installed. Drivers Just Work as long as you're not using some obscure hardware. Installing apps Just Works. Anything web (and let's face it, that's a lot of things nowadays) Just Works.
The only times when "rumor has it someone made it work" happens, that I've come across, is running a subset of Windows games in wine. Specifically, games that use invasive client-side anticheat (eg, EAC, which loads a kernel driver to do its snooping).
There have been calls made with the PinePhone hardware, it just needs some more integration and we're having some issues with call audio on the speaker on the pinephone.
I had a neo freerunner and the excitement behind this post is similar to how I felt back then. It's just really depressing that it's a decade later and the realities of making an open phone is still... difficult.
Could someone who knows say how this compares to the Sony Xperia running Jolla / Sailfish? I guess that Jolla contains some binary blobs in the kernel still whereas this is fully free.
Sailfish OS uses Android driver blobs via libhybris on the Xperia. I guess on the PinePhone either open drivers or native compiled blobs are in use.
But from the user perspective likely the main change from the Xperia would be the missing Android emulation layer. This is only available on officially supported devices, which the xperias (X, XA2, 10). On community ports, which Sailfish OS for the PinePhone is at the moment, the Android emulation layer is not available. I guess that could change if there is enough demand to roll it in to the Sailfish X program, like the Gemini PDA.
BTW, other than the Android emulator a and two more things (MS Exchange, typing prediction) the community ports are pretty much identical to the officially supported devices, all native apps will work, etc.
Hey Drew: I have a suggestion for sway/mobile. How about a simple windowmanager that shows a webview on screen and that exports a simple js api for window operations like { min,max,restore,setxy } so that frontend guys could make their own window managers. I think we'd see so much innovation on both desktop & mobile.
I've never seen something more web-dev than asking someone else to do this much work for you so that you don't have to learn a new language. I don't want the "innovation" of having awful web ui on my desktop.
It's an idea to provoke discussion. If you read the blog post he's got a whole list of app-y type stuff planned. This might be a way for him to save time on all that.
I wish I could use that dream phone on Xfinity/Comcast mobile, but even if they use Verizon tower, they block most phones that are Verizon-compatible... they only allow BYOD if you have an iPhone, Samsung Galaxy or Google Pixel.
I have a phone that isn't supposed to work with Comcast mobile, but 4g works for about 30 minutes if I reboot... I wonder if it would be the same with this phone.
Drew lives in Philadelphia, and he notes that it works, so yes.
Here's a tip, though, if you ever get concerned about whether or not a phone will work with your carrier. Check what modem it has. In the PinePhone's case, it's the EG25-G.
This was a discussion with the Librem 5. I know that T-mobile USA does not whitelist phones (My Librem 5 makes calls, sends/recieves SMS, and gets LTE data on T-mobile). Calls/SMS don't work on LTE though (I think due to proprietary software, that is true at least on Android). The Pinephone Braveheart Edition is compatible with most of the LTE/3G/2G bands for T-Mobile.
However, I think Verizon at the least used to do this, and may still do it. Sprint also has some extra proprietary things on Android and I don't know their functionality.
It is amazing that they consistently produce these products, I'm continually impressed by them. They are doing exactly the right thing, at exactly the right price points to kick start some of these things (linux phone, arm laptops).
I think he greatly underestimates the number of people with the interest and ability to do this kind of work. If it's easily available, I'll probably get one and hack on it, and maybe contribute to some projects. And I'm far from something special or unusual.