Fairphone 4 is coming to the US
arstechnica.com
arstechnica.com
Also I would have hoped for them continuing the FP3 architecture, feels such a waste that they've now instead developed a much more expensive hardware again.
Building and maintaining an Android device is truly not trivial, kudos for that, but I don't think with their current company size they're truly up for the task.
Also buying a Fairphone instead of a wider used phone means you'll be able to repair it - but because all the internal parts are super customized, phone repair shops won't have their usual source of spare parts.
I have a FP3, and it has been my first and only Android smartphone. I now wonder if what I've experienced is the "normal Android experience" or if I would have experienced something different from another brand.
I'm also avoiding / disabling Google stuffs (I'm using f-droid, ...). I was occasionally surprised to see how a lot of people are flooded with ads / unsolicited messages and seemed not to care. I don't get it, though, it looks such an awful experience.
The main thing I've noticed is the long time it sometimes take for the picture-taking app to get on focus. But I thought it was due to the standard Android software.
Is there a place to list the FP3 bugs?
* Battery swelling after less than two years of operation (no way to source this battery locally since they've built a custom connector / redesigned an standard OEM battery)
* Overheating
* Touch screen glitches (they've resolved that after a year via software, support was super unhelpful with that problem)
* Wi-Fi 5 GHz broken/unreliable for many people
* Camera focus (not sure if FP3+ improved on that front)
* Broken fingerprint sensor (from the beginning, most common issue) and by broken I mean not functional at all
* self-disintegrating plastic parts (back and side covers), likely due to the fact they are using recycled plastic - they've changed the plastic chemistry with FP3+, for me the plastic became more and more brittle
-
In addition for me with software:
* charging LED can't be disabled, which is extremely bright when you're sleeping - community members shrugging this off with "you shouldn't use your phone in your bedroom anyway"
* screen brightness too bright / unreliable brightness sensor readings (they had several updates because it was so hard to tweak for them)
On the positive end:
Phone is quite durable, fell down on many occasions and because of it's plastic/design openness the battery falls out but screen never broke in bunch of occasions.
Edit: Formatting
This citicism is valid. But I think it leaves out a lot of the overall picture.
I have a Fairphone 3, and so far it survived being dropped into the bathtub (being submerged for a sec), being dropped on hard floors several times and being stepped on (screen got cracked, but it still works).
Like with the Fairphone 2 I had before that, I'm able to do repairs (part replacements) on my own with minimal effort. It gets support for years.
I have it running /e/ OS (terrible name) without Google Services and while that's not Graphene OS, I vastly prefer it to Google Android.
For me having minor frustrations with Wi-Fi is well worth having a less-unfree and more-ethical phone.
Regarding WiFi, did you try disabling the "battery optimizer"?
I run into this with family members occasionally. Their music player or file manager has started showing ads, I recommend them the one I use on F-Droid, saying it may or may not be on the Play Store. Usually they go straight to the Play Store anyway and ask if any of their top ten results have the right icon/author. I really do get a better experience with F-Droid stuff. Never have run into ads or malware or whatever, can't imagine people thinking that it's normal to have such a bad experience. I don't know how they live with it.
And something within the size of original iPhone SE or Mini with just even an above average battery. I’d pay a premium for that phone. It’s my wishful thinking about smartphones.
And the lightness!
Hopefully one day we'll see something similar again.
I wish Apple kept Mini alive. Maybe at a premium and with a better battery.
Yesterday, after months, I was inside an Apple reseller store and picked iPhone 13 Mini and was immediately made aware of the monstrosity that was in my pocket.
Yeah I think Mini is finally dead.
Apparently, for the FP4 (reportedly in a departure from some previous devices), all software development is also outsourced. Security patches are often months out of date. Known defects with basic functionality (camera hardware should be fine, but is almost unusable for many tasks because of poor firmware/software making, eg, focusing ridiculously slow; microphone noise and echo reduction has serious problems for calls, etc) go unaddressed, or, in worse cases, are acknowledged as something that won't be fixed, especially for the bizarre security flaw that the manufacturer's official OS is signed by test keys, and the device is set to trust test keys, something that apparently can't be changed, and makes the device one minor leak away from having secure boot entirely broken. This is apparently one of the reasons why GrapheneOS developers refuse to consider supporting it. At the same time, other flaws in the security design make it very easy to brick the device, as you point out, and FP charges for unbricking (the test key problem apparently makes it unsafe for them to release a fix): in one case on the forum, a user bricked the device by correctly following FP's own official instructions for updating the OS manually, and FP refused to unbrick it without charge.
I was astonishingly disappointed by the FP4, to be honest, and by Fairphone in general.
That's a good point as well, companies like Framework are doing a better job on that front (afair) with releasing detailed repair PDFs for shops that need the circuitry to debug electrical issues/replace parts. Haven't seen something from Fairphone yet.
> Apparently, for the FP4 (reportedly in a departure from some previous devices), all software development is also outsourced.
Oh, I haven't heard of that yet - till FP3 they had some significant in-house development ongoing. This would explain why FP3 will get an Android 13 upgrade (from 11) soon, while there is no announcement for Android 13 for the FP4 yet.
A frustrating thing is that Fairphone actually has released quite detailed information for the FP4 [1], I think to a significantly greater extent than Framework. It just doesn't actually seem to have developed a real culture of repair around it, or developed any real connections with independent repair shops beyond just putting up a detailed PDF, that isn't necessarily easy to find, on their website.
[1]: https://www.fairphone.com/wp-content/uploads/2022/09/FP4_Inf...
They made an excellent repairable/upgradeable laptop and I’m sure they’d build a great phone
I hade a Note 1. It was so bad Samsung had to replace it with the Note 2 in 6 months.
My only gripe now on my 2nd Pixel with Graphene is exactly what Fairphone is fixing, which is easy hardware maintenance + 3.5mm jack. I guess a modular/repairable smartphone with w non-invasive os is "the dream".
How does it work on Graphene?
The hardware maintenance is true (even though I suspect the repairability of the usb-c port is what made me need to replace it in the first place) but starting with the 4, Fairphone doesn't have a 3.5 mm jack.
Source: I have a Fairphone 4 and have so far replaced the screen, battery, usb-c port and back cover.
A significant portion of the forum userbase considers that Fairphone's primary focus is on fair trade, the treatment of workers, and the sourcing of raw materials. Regular posters, and highlighted users ("Fairphone Angels"), will often argue to users that the phone is not primarily meant to be repairable or longer-lasting than other phones. Concerns about outdated security updates and long-lasting, serious software problems with basic functionality often get responses about workers in phone manufacturing, and reminders that this is the point of the phone. This goes directly against Fairphone's own advertising, but it seems to be the general sense amongst users the company attaches their name to.
Coming from the Framework forums, this was astonishing and disappointing.
Of course, much depends on your use case and expectations. YMMV.
I only replaced my phone this year (S7 edge) because the battery was depleting too fast.
You cannot swap it "live" though, phone needs to be shut off and then booted.
Also, there's no external loading hardware. So some logistics needed to get the spare batteries full.
[0] https://forum.fairphone.com/t/known-reproducible-and-reporte...
An easily removable battery is a godsend and the phone is surprisingly durable as I've been dropping it a lot (me clumsy).
I haven't encountered any issue and the one complaint I have is the lack of 3.5 jack. It was quite hard to find a USB converter that worked and having to use an adapter is really annoying.
Still if this one breaks I can repair it and I would even buy a new one if I had to.
https://forum.fairphone.com/t/fp4-list-of-usb-c-to-3-5-audio...
There's also an adapter on the official site that they say should work (but I haven't tried it): https://shop.fairphone.com/shop/usb-c-to-mini-audio-jack-ada...
Having a phone with a new battery doesn't matter if I can't run the same apps as others.
https://support.fairphone.com/hc/en-us/articles/997918043739...
> For Fairphone 4, we guarantee software support until the end of 2026, this includes an upgrade to Android 12 and, later on, Android 13.
Now sure, you could answer that they are doing it better than others and you may be perfectly right, but is it really the way we want to solve it? Gossiping on every company on how often they update their software?
You sounds like a salesperson telling a dev "why didn't you make our software bug free and vulnerability free????"
You're free to use Windows XP and a Nokia 3310.
Could you explain me why?
I am not saying that developer should simply make software bug free, I know that this is impossible, I however believe that you could heavily reduce friction point by simply having less code, and reducing the software reliance on the hardware/OS
Monolithic projects like Android prevents it from happening, you have to depend on that huge codebase to run any software, and as every software must follow Android update path, you need to continuously update your hardware
Well for starters bug and vulnerabilities. Hundred of millions/or even billions of devices are hackable without that much effort, why? Because people use outdated versions of their software.
>Monolithic projects like Android prevents it from happening, you have to depend on that huge codebase to run any software,
You could say the same about any decent OS.
If you want no updates and don't care about features, get a Nokia 3310.
>you need to continuously update your hardware
No one is preventing you from using a 10 yo device with hundreds of vulnerabilities and 500mb of ram.
That's just not possible if you value security at all.
And even if it did, it would take so long to develop that it would never get released before it was already too old to be useful.
I am not suggesting anything that would increase development time, in fact it is the opposite. Having to explicitly support multiple platforms is hell for both developers AND users
Which I guess is better, but they are not tackling the root of the problem.
These problems cause software to depend on highly specific platforms [1] that prevent any hardware from being standalone-ly sustainable.
* Environment access creates the opportunity for security risks, and dependencies that cannot be fulfilled on different platforms (e.g. asking for touch input on a desktop device)
* Being compiled to hardware specific instructions obviously prevent the same software to run on different hardware, rendering them obsolete sooner than otherwise necessary
* These instructions being hard to implement prevent individual users from creating their own interpreter, therefore creating the need for a centralized entity to provide it.
In other word, my suggestion would be to create a new target platform that compile down to a very understandable instruction set ("understandable" referring to the amount of time it would take for a new developer to fully implement it) and leave environment access out of the spec (How the software convert an input request to your mouse position remains platform specific).
This way, all software becomes permanently available without depending on any external entity, but new devices would still be free to improve the process
[1] - https://support.discord.com/hc/en-us/articles/213491697-What...
This is already the case. The vast complexity of modern software and hardware comes from the ever more complex environment they interact with.
If you take a nice small instruction set - leaving environment access out of the spec, and then attach device specific cameras, modems, displays, sensors, accelerators, etc. and then build an OS with a web browser and apps that interact with all the extra hardware. What you've invented is the modern smart phone. It runs on ARM - an easily interpretable instruction set.
Discord not running on older phones is entirely due to them depending on newer operating system APIs. It's not the instructions that changed, the environment did.
100% agree, hence my suggestion to completely remove environment access from the instruction set. No syscall.
> It runs on ARM - an easily interpretable instruction set.
I give you 2 hours to write a brand new fully spec compliant ARMv8 interpreter, 3 hours to write an android VM to run on my windows laptop.
> Discord not running on older phones is entirely due to them depending on newer operating system APIs. It's not the instructions that changed, the environment did.
The instructions allowed them to depend on platform specific features, which is what I want to prevent.
Instead of calling some random android `external_is_switch_gesture` syscall the app should request a boolean/bit given a string "Has there been a switch gesture?" and expect the result of that syscall to be what they asked for.
Then, it would be up to the OS to decide how to interpret that request, maybe that the string is part of some standardized way to retrieve a gesture input in which way automate it, but if it is not you could simply prompt the user to chose what to give the application given a list of all the possible environment access.
2 hours is pushing it for pretty much anything. I am pretty confident I can make a 64bit risc-v interpreter that'll boot Linux in a few days. Wouldn't be fast and wouldn't have IO, but neither of those have any baring on how easy the instructions are to interpret. The spec is fairly easy to understand.
> The instructions allowed them to depend on platform specific features, which is what I want to prevent. > Instead of calling some random android `external_is_switch_gesture` syscall the app should request a boolean/bit given a string "Has there been a switch gesture?" and expect the result of that syscall to be what they asked for.
Ok so in order to make it fast we're not going to use strings, instead integers that we only ever increment for new syscalls (no conflicts, ever). Applications want to know whether the system has support for a syscall, so we return an error if they don't exist. This is how Linux syscalls work.
Lets use your hypothetical: I'm writing a game that makes heavy use of switch geatures. I make my game call the "Has there been a switch gesture?" syscall, but whoops switch gestures were added in version 6 but this customer is using version 5. The absense of this syscall is fundamentally incompatible with my game, so I guess I'll put "requires version 6" on the website.
This is the status quo. Nothing you've suggested is a fundamental change to how software/hardware works. As long as new things are being invented/written you can never have full backwards compatibility.
> but if it is not you could simply prompt the user to chose what to give the application given a list of all the possible environment access.
Just to be thorough this is fully possible right now - intercepting unknown syscalls and showing a prompt - but there's simply way too many and their behavior too complex for it to be of any use. Especially non-experts would have exactly zero chance.
bf could, lambda calculus as well, or potentially cellular automata. Also implementing IO is still important, as the apps depend on it. What I am saying in my case is that the hardware manufacturer should expose the basic hardware features as functions (so immutable, there is nothing to update here) and you would then be able to implement whatever your app is written in and reuse the primitive hardware functions.
> Ok so in order to make it fast we're not going to use strings,
Why would strings be slower? These would be part of the static binary. These calls being hint and not necessarily standardized is an important part. Standards are the same as environments, they always evolve.
> Applications want to know whether the system has support for a syscall, so we return an error if they don't exist. This is how Linux syscalls work.
You may want to do something with the call even if the guaranteed syscall isn't there. I am meaning the string as a hint, not as an api
> but whoops switch gestures were added in version 6 but this customer is using version 5. The absense of this syscall is fundamentally incompatible with my game, so I guess I'll put "requires version 6" on the website.
Switch gestures cannot be linked to a software version. It is hardware. As long as you can listen to touch input and optionally multi-touch you have physical support for all gestures. It being limited to version 6 or above is an arbitrary limitation, and indeed will cause the software to delimit what's supported. Whereas if your software only exposed a "has there been a switch gesture" visible to the users, they could decide that actually a button press should be considered as a switch, or they could use a separate library that convert touch inputs into a yes/no switch, or perhaps that their devices already come with some hardware accelerated switch gesture control that they can plug into it.
> As long as new things are being invented/written you can never have full backwards compatibility.
The problem is that when making software you are forced to reinvent the whole chain. I simply cannot make a calculator app with the guarantee that it will be able to run decades from now, I need to include the binary that open the window, get the OpenGL context, write the boilerplate so I can draw individual pixels, etc.
But what if my compiled program only contained basic flow logic and an input and output? Essentially a function. And when users run it, how that function behaves with the environment is device specific and as the calculator developer I couldn't care any less.
Obviously, if you make a VR game it will be pretty hard to emulate it on a gameboy, but there is nothing justifying that I cannot make my own discord port on an arduino (except speed, but this is a convenience)
> Just to be thorough this is fully possible right now - intercepting unknown syscalls and showing a prompt - but there's simply way too many and their behavior too complex for it to be of any use. Especially non-experts would have exactly zero chance.
I agree, that's because we do not assign proper meaning to these syscalls. Users wouldnt know what to do, I am not saying that we need to expose raw file descriptors or make the user handle async i/o. I however believe that we should make this option more viable, for example by allowing applications to transform whatever they want into an environment request so they become more straightforward. And the less syscall you do, the easier it will be for users to make their ports.
Good luck turning those into silicon with any kind of performance.
> Why would strings be slower? These would be part of the static binary. These calls being hint and not necessarily standardized is an important part.
Because string comparisons are slow. Non-standardized hints are not a basis upon which software can be built. What you've described are APIs with loose coupling, which is the current status quo.
> As long as you can listen to touch input and optionally multi-touch you have physical support for all gestures. It being limited to version 6 or above is an arbitrary limitation, and indeed will cause the software to delimit what's supported. Whereas if your software only exposed a "has there been a switch gesture" visible to the users, they could decide that actually a button press should be considered as a switch, or they could use a separate library that convert touch inputs into a yes/no switch, or perhaps that their devices already come with some hardware accelerated switch gesture control that they can plug into it.
This is again the status quo. I can write a library that implements all the APIs needed to run discord on older versions of Android. It's simply a non-trivial amount of work for little benefit and thus hasn't happened.
> The problem is that when making software you are forced to reinvent the whole chain. I simply cannot make a calculator app with the guarantee that it will be able to run decades from now, I need to include the binary that open the window, get the OpenGL context, write the boilerplate so I can draw individual pixels, etc. > But what if my compiled program only contained basic flow logic and an input and output? Essentially a function. And when users run it, how that function behaves with the environment is device specific and as the calculator developer I couldn't care any less.
Your OS can't design a GUI for you, unless you're assuming the OS is also an artificial general intelligence. So really what you're asking for already exists: the CLI.
GUI apps are complex to make because their behavior is complex. Take your simple input and output, make the input include all window events and the output the file system/display/etc. and you end up doing all the same things.
> Obviously, if you make a VR game it will be pretty hard to emulate it on a gameboy, but there is nothing justifying that I cannot make my own discord port on an arduino (except speed, but this is a convenience)
You can totally port discord to an arduino! Get it to boot linux, run a web browser and open discordapp.com. You'll run out of RAM long before you get there, but just hook up an SSD for swap. Performance is just a convenience after all.
> I agree, that's because we do not assign proper meaning to these syscalls. Users wouldnt know what to do, I am not saying that we need to expose raw file descriptors or make the user handle async i/o. I however believe that we should make this option more viable, for example by allowing applications to transform whatever they want into an environment request so they become more straightforward. And the less syscall you do, the easier it will be for users to make their ports.
All this is essentially doing is turning libraries into syscalls. It's a loosely coupled external dependency and has all the same problems that entails regardless of what form its in.
I think the core issue you're trying to address is fragmentation. Unfortunately it's a natural result of people interacting with one another, not something you can fix with good design or software. It ends up leading to a lot of wasted work, but it's also a massive drive to innovate.
I'm going to sign off here. Thanks for discussing this, I honestly do find your idea interesting.
It doesn't have to be the hardware ISA, nothing would prevent the hardware manufacturer from including a compiler.
> Because string comparisons are slow. Non-standardized hints are not a basis upon which software can be built.
The comparison will only happen once, I do not think that we should argue about 2-3 string comparisons heating our CPUs. And you can definitely build software this way, you just need to work on the way the user map its hardware to the software.
> I can write a library that implements all the APIs needed to run discord on older versions of Android
But the hardware is there, the problem is that the mapping must be done through low level code.
> Your OS can't design a GUI for you, unless you're assuming the OS is also an artificial general intelligence.
I am not speaking about AI, but I do believe that our OSs could help us draw an interface from data. There are many UI creation tool, but they aren't meant to be real-time.
> GUI apps are complex to make because their behavior is complex.
They are complex to write, but very simple to describe (if you accept to give up on some details). I could describe my HN page layout to you way faster using english than html/css. GUI apps are complex because we are trying to map them to weird standards. Good luck implementing a CSS parser.
> You can totally port discord to an arduino! Get it to boot linux, run a web browser and open discordapp.com.
You can theoretically do it yes, in the same way developers could in theory port their apps to every single platform current and future. But in practice it isn't the case, and my calculator app will likely stop working in 5 years because of some weird API change.
> I think the core issue you're trying to address is fragmentation. Unfortunately it's a natural result of people interacting with one another, not something you can fix with good design or software. It ends up leading to a lot of wasted work, but it's also a massive drive to innovate.
I believe otherwise, instead of fighting against new platforms by exposing restrictive standards, I want to embrace the different platforms by allowing developers to write what they app should do instead of how. If your apps want to draw pixels, they should just draw pixel. How the windows must open is completely irrelevant and the OS/user should be able to figure that out.
Yes the hardware is the bottleneck.
This pains me, because what I can do is software, not hardware, where I spend all of my time is software.
An app just needs to target Android 7 to target 95%+ of users (so "only" 5% additional e-waste). And for app developers, targeting Android 7 is fairly easy (and the vast majority do), because Google provide androidx which is a compatibility library that provides backward-compatible APIs for every new shiny things. It's not 0 effort, and I understand app developers preferring Apple ecosystem here, but most of the Android app developers I've seen do use androidx and do target around Android 7. [1]
So, you get reasonably 5-7 years of app that are still working. The average renewal rate still barely bulged and still is around 2 years. People are not renewing their devices because of apps that are no longer supported.
IMO things that make people renew:
- Things that are a bit broken but annoying enough and accumulate: Too many apps leading to slow down, USB-C port getting dust making the connection harder
- The phones always look shinier in-store (because of over-saturated, over-brightness-ed screen amongst other things), so I'm pretty sure stores would manage to sell the same device over and over again by just changing the name.
- Kinda the same: Despite Gorilla Glass 424 Ultra Pro Max, screen's glass do wear, and phones' screen look worse and worse over time (if you have a screen protection, the screen will still look shinier in-store, if you don't your screen will be weary, and the screen in-store will look shinier) -- I like what Rebel Tech is trying to do here, they are trying to replace exclusively the glass part of the screen. That's so much cheaper that you could do it every 6 months to make your device look new again.
- Completely random software bug (which could very well be BECAUSE the device got a software upgrade, or could be just a bug in the app, or just Google decided that this was the new Best User Experience) that make people think "yeah well I get it, my phone's old"
[1] I do know of one exception: Slack app. They are deprecating Android 7 and Android 8. They suck.
Why do running newer software must depend on a newer operating system? Do you believe that everything that is part of the android codebase is necessary to run a chat app?
Part of the problem is that we seemingly gave up on trying to make software stable, and now we are wrongly putting the blame on hardware manufacturers for not wanting to spend their whole life supporting it
Doing so is a privacy loophole, since newer OS's have stronger privacy protections.
There is no need to port newer Android versions on older devices. My point was literally that it doesn't make people keep their devices longer.
The designers of USB-C should be ashamed of themselves for not doing more durability testing. Both cables and sockets are big pain points for most users.
Phone is lost
Phone breaks beyond a reasonable cost of repair
Phone fills up with WhatsApp pictures and after months or years of deleting them they buy a new phone with double storage, which is already not enough.
Children grow, get the old phone of one of their parents and the parent buys a new one.
Fairphone has this (and so do some other phones). It works.
The software can be improved iteratively. Hopefully as they grow in new markets we'll see more investment in e-OS and (hopefully) find a viable competitor to Google that's open source
And of course they all have PR and websites devoted to how much they care about the environment, even positive ESG scores in some cases
Q: Wasn't the point of Fairphone to have ONE phone and then buy "extensions" or/and replacements only, aka modular - for the sake of preserving the environment, etc etc?!
A. No, it was always for repairability to ensure people can keep it for around five years without needing to replace the entire thing at once because the screen cracked or the audio jack broke.
This whole upgrade part stuff is something that get's hyped a lot in online discussions but from the very beginning Fairphone has been very honest and cautious when asked about possible upgrade modules in the future. They would love to offer crazy upgrade paths but cmon it's a small company in Amsterdam with limited resources.
However they did introduce an upgraded camera module in 2017.
I think the main takeaway I have for everybody regarding the Fairphone is: Don't let perfect be the enemy of good. I've preordered the Fairphone 2, got it in 2016. People ask me about it often. They usually get very excited only to get disappointed when they realize that the team behind it has to make compromises just like every other phone brand has to.
The fact that they got this product designed, launched and supported with <100 people is really amazing, so please don't feel disappointed by the fact that it doesn't offer something even Google couldn't get market ready.
These guys make really good phones that are not only as fair as it gets but also as innovative as it gets when it comes to the overall design. They introduced a camera upgrade module in 2017 which is amazing, other than that it's really just making your life easier when you want to replace parts.
I replaced the screen and the audio jack, the phone is still rock solid.
Q: What about Software? I keep my phones mostly 3 years, because even after 3 years, many LOS devs are jumping ship...?
A: They definitively do their homework. Security updates come usually ~3 weeks after Google releases them. Fairphone OS still gets bigger updates every ~2-3 months. They still support their Fairphone Open OS. Lineage OS is really popular on it and is well supported offering Android Pie for the Fairphone 2.
For the Fairphone 3, the manufacturer guaranteed five years of support. This means that replacement parts are available for five years and security updates are offered. In addition, the manufacturer promises a feature update to Android 10, but does not call for a date. Additional feature updates are planned but not guaranteed. For the sold out since March 2019 Fairphone 2 (available since the end of 2015), the manufacturer will continue to publish security updates and reserve spare parts for at least another three years.
The Fairphone 2 was delivered with Android 5.1, later came updates to 6.01 and 7.1.2 - the latter with great effort, because there were no official drivers for the Snapdragon 801 chipset used.
"Q": What an awful phone. Anyone who buys this is an idiot, you aren’t saving the world and all you’re doing is making yourself feel holier than thou because of your “ethical” decision which you can’t be quiet about.
Save your money and get a REAL phone with much better specs for the same price.
A: It's still a step in the right direction.
I also don't see the problem with feeling cool about "ethical" decisions.
I definetely think my Fairphone 2 is cool. I think it's tacky, chunky and technical look is beautiful and it sparks interesting conversations with other people that think it's cool. If fair and open... If having a seven year old phone that looks absolutely worn out becomes the new mainstream cool that would be the best thing to ever happen to us.
I for myself feel pretty cool when people ask me about my phone and how old it is. I also feel better, yes.
"Q": We shouldn’t care about the conditions our phones are made in. We should care about the best value for our money, performance and quality.
A: Well you know that's just like your opinion man.
"Q": YEA lol pay [price of the prior Fairphone] for a phone just to feel good about your enviromental impact. top kek.
A: As you may know the Fairphone is not only trying to improve the enviromental impact, the company is also doing as much as possible to improve the situation of the involved asian workers. I would like to use this moment of awareness created by the Fairphone 3 announcement to invite you to get a small glimpse into the live of Xu, your typical Foxconn phone assembly line worker. Please excuse that I just copy & pasted this together.
On the last day of September, a 24-year-old migrant worker in the southern Chinese city of Shenzhen killed himself. Xu Lizhi jumped out of a window of a residential dormitory run by his employer, Foxconn, the huge electronics manufacturing company with a million-strong workforce that makes the majority of the world's Apple iPhones.
In most cases, Xu's suicide would have been yet another footnote in the vast, sweeping story of China's economic boom and transformation. He is one of a legion of young Chinese migrants who emerge out of rural obscurity to find work in China's teeming cities, only to end up crushed by both the dullness and stress of factory jobs, insufficient wages and a steady accumulation of personal disappointments.
But Xu was a poet. And, after his death, his friends collected his work and got some published in a local Shenzhen newspaper.
《一颗螺丝掉在地上》 "A Screw Fell to the Ground"
一颗螺丝掉在地上 A screw fell to the ground
在这个加班的夜晚 In this dark night of overtime
垂直降落，轻轻一响 Plunging vertically, lightly clinking
不会引起任何人的注意 It won’t attract anyone’s attention
就像在此之前 Just like last time
某个相同的夜晚 On a night like this
有个人掉在地上 When someone plunged to the ground
-- 9 January 2014
We ran along the railway,
arriving in some place called ‘the City’
where we trade in our youth, and our muscle.
Finally we have nothing to trade, only a cough
and a skeleton nobody cares about.
‘Sleepless’
You can find more of his works here: https://libcom.org/blog/xulizhi-foxconn-suicide-poetry
You can also check out the complete cost breakdown of the Fairphone 2 here: https://www.fairphone.com/de/2015/09/09/cost-breakdown-of-th...
But don't let me guilt trip you into buying this phone. The Fairphone 2 was an amazing device and I am sure the Fairphone 3 will be a solid upgrade. This is a great phone line and not some shitty alternative. The Fairphone 2 definetely had some reliability issues. I believe it was the right decision to introduce more screws and flat cables to make it more reliable and decrease additional material was needed for all the pogo pin connectors that made the Fairphone 2 extremely quick and easy to disassemble but also prone to all the random connectivity issues.
The FP3 is still as good as it gets when it comes to repairability. The changes to the FP3 give me hope that it could finally become a reliable phone as well.
Every gripe I had about the Fairphone 2 after using it since 2015 got addressed in this new iteration.
Sounds like they are confusing it with "Phoneblocks", which went viral around the time the FP1 launched. Logos look similar, too.
I also wish it was just a phone with much less performance for a smaller price.
I want something durable and repairable, not something fast, Wirth's law is very important to consider when consider software and hardware. I hope they will make such phone, one day, because I am not spending that much money for a phone.
I bought a 150 euro phone and it already lasted 3 years, because even if a phone becomes obsolete, it is still cheaper, per year, to use crappy phones, than to use a durable expensive phone.
If your really care about fairness and the environment, make lightweight hardware and software.
As for the cheapness, I've been keeping a running tab of how much the repair is costing me vs how much it would have cost with a normal phone (ballpark estimate) and, considering the phone price, I'm currently saving about 200€, even factoring in the phone price. The biggest expense is shipping because I live in the middle of nowhere and I can easily get 10€ of shipping on a 15€ spare part (which is why I'm not replacing the protective cover even though it looks like shit).
Not sure I buy that lightweight phones would necessarily be better for the environment? Surely repairability is key?
Also a less powerful CPU has a longer battery life.
4-yr warranty, stock Android.
If their phones do work as good as that... Well...
If I couldn't get a truly repairable phone, then at least I could buy the one that would likely last the longest given the wide availability of official repair outlets (e.g. Apple Stores) and the history of solid software support for at least five years.
So that's where I am at. Thankfully things are looking a bit better on the laptop side of the repairability fence. I have every intention of pre-ordering a Framework 16 the second pre-orders open.
I have two questions though.
1. Bands: does it have all the bands for GSM carriers in the US? CDMA?
2. Can you use this phone powered solely by the charger with the battery removed? With a 65W Thinkpad charger?
I wish they would come preinstalled with something like kde plasma mobile though. I will never warm to android, no matter how "degoogled" it might become. There is something about its architecture that seems freakish. Like the entire digital universe that was created in the last decades.
I think the modular aspect is cool, but seems like a gimmick that would be prone to failure. Just my opinion anyway.
I'm taking a bet on not smashing the handset. €300 extra was just too much for a replaceable battery. Atleast for my usecase.
The real issue with the FP4 is the camera. Ugly pictures, and under bad lightning its like taking picture on android a decade ago.. Albeit the pixel number is enough.
If you want an opensource phone, you end up with crappy photos unless you have a camera team of 500 people to rewrite that stuff, and a big team of lawyers to deal with all the patent licensing you're going to have to do for the techniques you use.
Camera stacks on modern phones process many raw frames to make a single photo - sometimes as many as 100.
Collecting those frames is done in a second or so before and after the user clicks the shutter button. Thats a data rate of ~15 Gigabits - far faster than most phones can write to storage - and anyway would you be happy for each photo to take a few gigabytes of storage space until it was processed?
Therefore, the raw data needs to be processed (or at least preprocessed) in realtime. You can't store it and do it later.
And to do that, you typically need custom silicon - all the big phone manufacturers have ASICs dedicated to image processing.
And to make the trouble even worse, you often need to use data from some of the raw frames to adjust camera parameters for the next frame - for example adjusting amplifier gains. See patent US9196027B2 for an example of the sort of thing that is done 'in the loop'.
At a minimum, the GPU needs to be able to generate image scale pyramids, align them using optical flow, have a sensor noise model to detect misalignment, and take a running-mean of every non-misaligned pixel in each frame seen. This technique only needs enough ram for a handful of frames.
That should get you a good chunk of the way to a decent image.
As usual, the actual math is quite simple in python, but when you need it to run at 15 Gbits you'll be spending a really long time optimising assembly code for whatever GPU you're using...
> OS upgrades: 2 years of OS upgrades
> Security updates: 3 years of monthly security updates (From the global launch date of the device)
And I didn't see any iFixit rating. Aside from using recycled materials, don't see much in common on the surface.