The Pine Formula | Hacker News Reader

The Pine Formula

tuxphones.com

130 pointscunidev88 comments

The "killer app" of the Pine formula is that it reliably gets brand-new hackable devices into the hands of the community at an affordable price point. A PinePhone is $150 + a whole lot of shipping and import taxes, but many alternatives are:

- more expensive - the SHIFT6mq is 600 EUR, the Librem 5 starts (!) from EUR 1600 (!!!), the Fairphone 4 starts at 580 EUR. No way in fucking hell is anyone going to be buying these unless they are already in a well-paying tech job - which is automatically exclusionary towards all tech-curious teenagers worldwide, and working adults from lower-paid countries. Do we seriously want open(-ish) tech to be a toy only for the rich? I sure as hell don't.

- unreliable in production - open hardware is often (more often than not?) a limited-edition item. If you are there to order from the initial batch (or if you're lucky, the second batch), great - you can buy it. But discover it a few months/years too late, and the product is so unobtainable from the secondary market that it might as well have never existed.

- difficult to purchase across territories - USA-based (or alternatively, European-based) hackers get to enjoy having an open product, whereas the rest of the world merely gets to lick the shopfront window from across the ocean.

- less hackable - Can you flash an open firmware on any given Android phone? Anyone's guess. Can you do so for any random Pine product? Most likely, yes, even if it contains blobs. User freedom-wise, blobby but otherwise unrestricted firmware is heck of a lot better than any restricted firmware.

- not brand-new - hardware ages both in terms of specs (less powerful than the mainstream non-open alternatives - this is IMO part of what killed OpenMoko so badly), and in terms of actual hardware PCBs, batteries, screens etc aging slowly until it can no longer reliably operate/operate within spec.

I will be the first to criticise the fact that Pine seems to be increasingly leaning on the community to produce working software/firmware for their products, but I will also be the first to commend them for their ability to deliver open(-ish) hardware to more than just the globally well-off with cash to burn on their ideals (something that not all of us can do).

The alternative is just using one of the discarded phones most people already have in their drawer somewhere with postmarketOS. If you're in luck it's one of the well supported chipsets

Do the phones in most people's junk drawers have unlockable bootloaders?

yes or buy one on ebay for a fraction of the price of some libre maker flavor of the month soon to be ewaste

Many second hand phones go for <100$ and are unlockable.

It's word by word the story of how I got my first such phone. I told my colleagues that I'm looking for an old Galaxy phone, and one of them had one lying around.

The points above are indeed valid, but for example there is a line to be drawn between PinePhones and their secondary products.

Also, near the end it does explain/justify the need for a compromise in "libreness", as essentially anyone would agree on given the extraordinary price of "pure libre" hardware.

The main point in my opinion is not pushing for radical hardware, but rather accommodating the needs of developers and end users in a "libre-ish" lineup.

> I will be the first to criticise the fact that Pine seems to be increasingly leaning on the community to produce working software/firmware for their products

Isn't this a double standard? Linux is most commonly used on PCs and i do not think that PC/mainboard manufacturers are big into producing Linux (or other) OS/software for their products, they left it on wider ecosystem.

Pine64 just use the same approach that use PC/mainboard manufacturers, instead of 'consumer appliance' approach that use phone manufacturers.

PC/Mainboard manufacturers absolutely do create drivers and utility applications for their products, for Windows and Mac. The OS provides the rest of the functionality.

The issue with Pine64 economics is that such an OS doesn't exist yet, at least on their phones. What good are drivers if there's no dialer app available, for instance?

There exist several OSes with support for Allwinner A64 SoC used in Pinephone. Linux certainly has support for Pinephone. Dialer apps also exist.

Are any of these usable as a daily driver, and at least 90% as reliable as mainstream phones when it comes to placing/receiving calls, ringing, and notifying about new SMS messages?

Don't know whether there was an update to the fine article, but the article currently seems to mostly refute your points.

> Pine formula is that it reliably gets brand-new hackable devices into the hands of the community at an affordable price point

I guess this depends on the definition of hackable, but the revelation that I got from the article is that Pine actually doesn't operate that way, they just sell the cheapest hardware they can instead of "hackable" hardware.

IME The hardware is quite hackable. Schematics are usually available. SoC documentation is available, often times some kind of code is available, Pine64 listens to feedback, pine64 wiki has quite a lot of information, etc, etc. Some of these accessories to the main product surely feel like they started as someone hacking something together and writing about it on the forum, and Pine64 deciding to make it into an product. I guess fingerprint reader backcover for pinephone seems like it came about this way.

Author here. Can confirm that PINE64 is still way more hackable than COTS alternatives

(Also, the article wasn't updated, apart from a couple of dead link fixes)

Pointing to two tier-2/3 products as proof that they began shifting away from open/hackable hardware is misleading - it's far more likely that they are simply exploring, or made a product design misstep.

They have dozens of products at this point, and their SBCs, phones and laptops are the products people are most likely to care about. The amount of people who would object to less-than-open headphones or whatever is low, because the amount of interest is lower in the first place.

What do people with Linux phones do about banking apps? All my banks force me to do online banking through an app (at the very least used as a security token generator). I would really love to have a Linux phone but I'm stuck with Android because of that.

The best I can advise is try to access it via the online banking website, if available. Otherwise, you simply cannot use mobile banking apps unless you have some way to emulate a sufficiently "verified" Android environment somewhere (on your phone or some VM somewhere else), and use that to open the app.

I would never try to do online banking on my phone if possible.

The banks have however decided that issuing separate security dongles is too costly, so instead they forced us all to install an app that acts as a security token. So I cannot do online banking without the mobile app.

I changed banks over their requirement of having an android or apple phone. The clerk gaped when I told her I don't have a smartphone.

I would try to call them and flat-out tell them that you don't own a smartphone. Just tell them that you're using a dumb flipphone to communicate. Maybe they have a way to authenticate via SMS or alternative means. Else that would mean that peopler from an older generation who still don't have smartphones are just excluded from using this bank, which would be strange.

Else your only option is to buy a cheap android phone which you only use for this login. In a way that makes your banking activities even more secure because you're only using the device for 2FA codes :)

Except this insecure, non-updated device would also be sending tonns of data to Google continuously.

I know that security cracks will not like what follows - If you only use it for 2FA codes, does it really matter?

It matters, because your insecure device will be sending data to outside servers without your control, possibly with buggy software interceptable by hackers. So your 2FA codes could be technically intercepted before you know it.

Not everyone uses banking apps?

Are the requirements different in different parts of the world? I've never used a banking app, I just use a web browser on my desktop.

I didn't use banking apps when I used Windows Mobile for years, but the big thing I've since found handy is mobile deposit. Generally without a phone app, you have to drive your checks to the bank.

No good solution. Perhaps a cheap Android for $30 just for those apps... Maybe running Android in a VM inside a computer would work for that?

That's what I plan to do.

But $30?

~100€ is the minimum I've found. Do you have a link? Or maybe you meant non-Android...

$30 and even less is not uncommon for an older, slightly scuffed up, used phone. Or maybe you already have one, laying far back in your desk's drawer. Not a kind of phone most people would use as a daily driver. But as a dedicated bank-app thing - sure, why not.

Just don't connect it to untrusted wifi, disable bluetooth and all that. Chances are - that phone had its last OS update years ago, and could be pretty easily pwned [0]

[0] https://gist.github.com/jesux/64cf037c55c0d42196762c0ccacc73...

If SafetyNet checks are not a concern, several people used banking apps inside Android runtimes (like Waydroid) on their Pinephones. Clearly not ideal for everyday operation, but for occasional tasks it does the job decently well and the overhead is low

I guess it depends on how much you use it?

On the Linux phone itself, you can try out Waydroid https://waydro.id (and it seems to work on regular Linux too?).

I also think there are Android Distros you can install in a VM as well (though I admit I have not tried it).

Honestly I recommend switching banks. I don't use a linux phone yet but I just tested my credit union's web site[1]. Not only does it work but it has a mobile version that seems -- now that I look at it -- more functional than the app.

[1] Security Service Federal Credit Union

> more functional than the app

given the increasing insanity that is getting a mobile app published and updated, I'd say that this will be normal than not in the future.

you need a team devoted to keep up with the monthly threat of your app getting removed because some new requirement. the upkeep is terrible.

I use a local credit union as well and also just use their website.

Interesting to hear this. I'm getting a bit annoyed about too much reliance on iOS/Android apps myself, but at least for most banks around here I still have the option of alternatives. I do miss my printed out lists of verification numbers, but I could pay for SMS delivery or get one of those smartcard readers.

Which, now that I looked it up, seem to be a German peculiarity.

https://en.wikipedia.org/wiki/Transaction_authentication_num...

Another annoyance lately is traveling. I need two apps for the car sharing services, two for public transit, maybe another handful for scooters/bike rental etc.

Wonder could you write one with Plaid.

In what country? In the UK I've never been forced (or even encouraged) to install the banking app. Which is lucky, becuase I'd sooner switch bank.

In Finland, you have to use a bank's authentication service to do pretty much anything. Most people use a mobile app for that, but paper codes work as well.

Also in the UK and have no idea what you're on about.

All major banks require app-based authentication. Many also offer sms as an alternative, but this is being phased out across the board. A handful maaaay still allow you to do banking via physical cardreader verification if all else fails (and you have no record of having ever installed an app).

> All major banks require app-based authentication [...] A handful maaaay still allow you to do banking via physical cardreader verification [...]

Uhm no... I can personally attest to at least Barclays and Natwest allowing you to use a cardreader + website, no apps needed, all online services available through website. Those are 2 of the top 4 largest banks in the UK, I wouldn't be surprised if it was a similar story for the rest. I imagine they would get in pretty deep legal trouble if they forced people to use smart phones.

Just because you don't try to use stuff without an app doesn't mean it doesn't exist anymore, I don't have a smart phone - life is good in the UK.

These are all slowly being phased out. That's the point.

I'm on Natwest too, which is one of the banks I'm actually referring to. As soon as I installed the app (for unrelated reasons) it started requiring it for authentication, even though I never chose that as an option, and it persisted even after I had uninstalled it. It is not impossible to work around it, but it's definitely not a pleasant experience, especially not when dealing with payments.

My recent experience is that Natwest at least has been adding 'friction' for doing things without the app. Case in point, I needed to change my address recently. I explicitly wanted to avoid the app, because it mandated establishing a biometric password. I tried the website, the website redirected me to a telephone number. I called the number, 30 minutes later, it happily informed me that "Great. What you're trying to do is possible from the app. Why not download ...".

In the end I took half a day off from work and went to the bank in person and asked a human to update my details. But judging from other industries, and seeing how the app is being pushed, I have no expectations that "human customer support" is going to be a thing for much longer (except for the typical "Helloooo I'm here to walk you through the app via a script I cannot deviate from" annoying kind).

All I can say is that I bank with two mainstream high-street banks and use password + SMS authentication, with the option of a card reader.

Wait a second, (I'm curious because here in Australia this thing doesn't seem to exist) is this limited to their mobile site (you need app in order to log in on your phone), or you actually need to have a phone with you when you access online banking on your desktop? If it's the latter, that's crazy, what if you don't have a smartphone? That would be a complete deal breaker for me, I would switch to a different bank

Nordea gives you paper codes when you sign up. You can do everything through their website as long as you use those codes for MFA. Each time you authenticate, you have to use the next code in the series. Once you run out, you go to the bank and pick up another code book.

As someone who builds the banking apps of joinatmos.com, uses linux on desktop and aspires to use it on phone - I’ve been thinking about this too. Our react native build won’t support Linux (say, Flathub) very well at all, and building a separate GTK app is not cost effective for a startup. Flutter could work, or if we’d made our mobile app a wrapped website in Cordova or whatever that would have been an option I believe too.

For now, our mobile Linux users would be “stuck” with the mobile web experience, though we tried our hardest to make it a performant PWA that you can pin to your home screen. The main thing you lose is persistent biometric login, though many privacy conscious users seem to not trust biometric unlocking of your session in the first place (they mistakenly think their Face is being uploaded to our servers, which is of course not how the technology works on iOS/Android) so that may not be an issue.

Edit: From my time trying to use a dumbphone as a daily driver a few years ago, cash apps were a bigger problem (Venmo, etc) as theres a social component to “not paying someone back until later because I dont have a smartphone”.

I dunno about you, but I'd prefer it all just work via Firefox, so assuming that's functioning, you'd have my business.

though many privacy conscious users seem to not trust biometric unlocking of your session in the first place (they mistakenly think their Face is being uploaded to our servers, which is of course not how the technology works on iOS/Android)

For me, my hesitation with biometric unlocking is due to it being legally weaker than a passcode.

https://www.biometricupdate.com/202007/another-federal-court...

I see good point.

Instead of Cordova, you might want to try Tauri. https://tauri.app/

Genuinely curious here. Not trying to be critical. Why is a bank app necessary in the first place? Modern mobile browsers can run a pretty impressive HTML and JavaScript site, and I don’t have to worry about being forced to upgrade at an in opportune time.

Most banking sites log you out very aggressively, and a lot of them require some sort of 2FA during login. It's quite inconvenient to have to do this login dance every time you need to make a transaction -- with an app, you can use a PIN or biometrics to start using it.

PSD2 certification - you must have some way to implement 2FA and a lot of banks prefer using an app for this that they can also use to gather information about customers than using strong authentication methods.

I know a bank that makes you type your credit card PIN key after receiving an SMS in a mobile site... (cannot disclose which one).

Yes, it's insidious isn't it.

I wish I could say the answer is to find a bank that doesn't do it, but there don't seem to be any. The whole thing verges on apocalyptic.

Personally I hadn't heard about this until a minute ago, which means that luckily there are banks that don't require a mobile app...

The Venn diagram of Linux phone users and people who want to reduce proprietaries in their life is rather big. That's to say it's almost the point of the hardware to point you these problems. And in my opinion, frankly, your anecdote is more about your choice of bank and not which phone you use.

That being said, what about banks with open APIs? Wasn't there some EU legislation?

It's "open" api for some bullshit aggregation data slurping services, not for normal customers to access their data directly and easily for themselves on their own hardware in automated way. There are banks with nice XML/JSON based API specially made for easy syncing and login via API keys you generate in a normal bank web UI. But those are very rare.

If anything EU fucked up all my bank automation, except for this one bank, by requiring 2FA just for logging in, and not only for making transactions.

My bank (comdirect in Germany) fortunately has an okay mobile-friendly website and sells a tiny hardware device to generate the "TAN" for their weird proprietary way to secure transactions.

In the US in my experience, it seems like all banks rely on SMS or email-based 2-factor. I’m sure that will change but our financial institutions are perpetually behind the times. So at least for American users, the lack of banking apps isn’t much of an issue.

I stopped using my bank's online service the day they required a proprietary service[1] installed. It is very inconvenient, I have to go the physical agency to get info I could get from my pocket anywhere, but that is the price I'm willing to pay if they require me to continuously run proprietary code on my own device.

[1] https://seg.bb.com.br/passo-a-passo.html?system=Linux

Personally I don't do online banking on the phone, but your mileage may vary depending on your needs and how often you are away from a desktop.

My bank has a website where you can do banking online, and I use that.

Personally, I'm using Anbox to occasionally run a single Android app on my Librem 5 and it's a banking app (Polish mBank), which works fine with it.

For what it's worth, that app isn't actually necessary, but comes with some handy features that aren't available on their Web frontend like token-based payments that can be used in ATMs or shop terminals without using a card, which is what I'm using the app for (regular payments can be easily made via the browser).

I was going to write something similar, but this covers it pretty well actually. Hopefully there could be some more developer support in the future again like the community editions once were.

I am glad to see a growing chorus of people voicing similar concerns, which myself and others have long held. The article links to a similar article from Drew DeVault for instance (down at the bottom).

Perhaps if nothing changes after a while, it might become time to add your voice to the other public pleas. Or maybe speak to PINE64 directly/privately (I don't know how well you know them).

It’s worth noting that the quoted article was published on April 1 [1]. While the PineBuds were confirmed in the following community update [2], the PinePod plans are only mentioned in the description of the development board as a “platform for earbuds and a digital audio player”. It seems to me that the plans for a future DAP are still quite nebulous and I wouldn’t give that much weight to the wording used in the April Fools’ announcement.

[1]: https://www.pine64.org/2022/04/01/introducing-the-pinebuds-a... [2]: https://www.pine64.org/2022/04/15/april-update-no-more-unico...

I would not say the PinePod project is that nebulous, it has been officially proposed in the "serious" post, and even discussion internally regarding software support is already being done apparently

> Some days ago, I was sitting in a dark, neon-tinted, pleasingly nerdy computing club in Berlin, with several Linux hackers around me. Most of them either had a PinePhone or a PinePhone Pro, someone else had Librem 5s plugged into their laptop as they tested out new software.

I wish C-Base (the venue in question) were "pleasingly nerdy" enough to ban smoking indoors. Berlin is so maddeningly stuck in the uncivilized past in this regard; I would love to participate in these events and communities but cannot do so until this problem is fixed. There seems to be no will to do so in Berlin.

Please keep cbase (not ccc, standalone hackerspace) seperate from all hackerspaces in berlin. Spaces like xHain have banned smoking indoors while also being a lot more inclusive.

This. While C-base was a cute space architecturally, as a newcomer I did not find it terribly welcoming.

For one, there was an interesting elitarian aura around "members", versus us common "visitors", and the staff (very politely) asked me not to be seen around with a camera on my neck, although I was there with other ~8 people who I personally knew, and only took the "tunnel" picture at the top of the post.

Crazy they allow it. Even I, a dirty smoker, know not to smoke around electronics.

I thought C-Base banned smoking after the Ordnungsamt showed up?

> There seems to be no will to do so in Berlin.

X-Hain is your friend, it's small but people smoke outdoors.

> Most of the competition, at this point, is doing it: SHIFT, Purism, Framework, MNT Research, and Raspberry Pi are moving towards more openness, not less, as time passes.

I'm happy to consider that Pine should be doing better, but in what world is Raspberry Pi doing any better? AFAIK they still require closed blobs to boot, and it was my understanding that the company doesn't even consider this something to fix.

> Some competitors to PINE64 and Purism are now Precursor, SHIFT, MNT, and Fairphone among others

Great, more competitors - faster evolution. I'll definitely get a Linux phone in near future, just a bit scared about my free time if any update will break the caller or SMS app.

> It will not drive a good screen, it nor run high-resolution flacs or (probably?) support a high-quality, high-bandwidth codec.

What is this drivel? 900KB of RAM is plenty for all of the above and then some, if you know how to use it. An MP3 decoder's runtime footprint can fit into 16KB of RAM, aac needs just a bit more. A ui can be made of constant image pieces that never need to live in RAM, leaving ram only for things like rendering text.

Years ago i made an mp3 player with an OLED screen that properly rendered English, Cyrillic, and accented latin characters in a proportional font, all on a cortex-m3 microcontroller with 64KB flash and 32KB ram.

> Pinecil from the open-source TS100 iron

The Pinecil is Pine64’s most polished product, and I congratulate them for getting such a high-quality soldering iron down to such a low price point ($26).

https://www.pine64.org/pinecil/

Even if the Pinecil weren't open hardware running on open firmware, it would still be an incredible value. But it is, and my only criticism is that the rewritten firmware flashing tool does not yet support Linux (the older version does work). Other than this, the Pinecil is a gem and an example of the Pine formula at its best.

- Pinecil documentation and schematics: https://wiki.pine64.org/wiki/Pinecil

- IronOS: https://github.com/Ralim/IronOS

- PINE64 Updater: https://github.com/pine64/pine64_updater

I would really like to see someone raise the same questions this article does at the next community Q&A.

I wish MediaTek open-sourced their drivers so we could see a PineBook Pro with a relatively capable processor, that thing with a higher res screen and a Dimensity 9000 would be amazing.

I don't run Linux on any of my Pine64 devices, I'm happy with them just doing hardware.

Do you run anything on them then? I think the article's argument holds for any software, not just Linux.

I run NetBSD on my Pinebook and Quartz64.

Ditto all the Pine items.

Do you use TF-A and/or U-Boot?

> This product family will never run Linux, as developers will need to develop a new firmware from scratch. This is obviously not a problem for the earbuds, but a big limitation for the player

Perhaps not Linux, but I suspect there would be a place here for a Unix-like platform that feels familiar. If for example we could get wide-adoption of something like the JVM or wasm3 [0] on these platforms, code could become quite portable, despite wildly different architectures.

For example, Apache's NuttX [1] (that I first learned from Lupyuen [2], a guy making great progress working with Pine64 products).

> Processing wise, this chip is well sufficient for TWS headphones, but very inadequate for an audio player. It will not drive a good screen, it nor run high-resolution flacs or (probably?) support a high-quality, high-bandwidth codec. In fact, a first generation iPod Nano (retailing for $149 in 2006) had 16MB RAM, so over 16 times what the PinePod would offer. In fact, even the features of any custom firmware are limited from so little memory

I wouldn't call it time just yet. Displays can be interacted with intelligently (to reduce pixel bandwidth) and ultra high quality audio codecs offer diminishing returns, especially when you don't have a DAC or headphones to make the most of them.

My advice to Pine64 would be this:

1. Consolidate your product lines. The Pinebook is just a slower Pinebook Pro, just go with the Pinebook Pro. The PineTab is just a Pinebook without the keyboard, again I would consolidate this with the Pinebook Pro and just make the keyboard detachable.

2. The SBCs should just go straight into the device, thus creating a clear upgrade path for future products. If you want a PineBook Pro running Quartz, just swap the boards (of course with daughter boards for USB expansion, display driver, power, etc).

3. Don't be afraid to kill off products. The Pinebook and PineTab have never seen a new release. The PinePhone appears to be taking a back seat to the PinePhone Pro. The PineCube is basically DoA due to the processing power struggling to process the camera image.

More generally, try to do fewer things, but do them well.

[0] https://github.com/wasm3/wasm3

[1] https://nuttx.apache.org/docs/latest/

[2] https://lupyuen.github.io/articles/sensor

> Perhaps not Linux, but I suspect there would be a place here for a Unix-like platform that feels familiar.

It's just a tiny microcontroller, how could it run a Unix-like?

Checkout Apache's NuttX [1]. It's pretty impressive.

[1] https://nuttx.apache.org/docs/latest/

Pinephone is not taking backseat to Pinephone Pro. If they kill off Pinephone, they'll have no smartphone that actually works and will piss off anyone who did a lot of work on software thinking this device is LTS as they promised.

> If they kill off Pinephone, they'll have no smartphone that actually works and will piss off anyone who did a lot of work on software thinking this device is LTS as they promised.

It's not to say they will kill it, but the Pinephone Pro is clearly the device they will move forwards with and spend time to develop. The A64 is simply too slow.

That's not clear at all. It may simply turn out that RK3399 (as a tablet and notebook SoC) will be impossible to make power efficient enough, and with much much smaller userbase than original Pinephone, noone will work on fixing it.

Reply on news.ycombinator.com