I really wish Fairphone 4 had GrapheneOS support, but after almost 4 years of Fairphone 3 I decided to go with a Pixel instead. Too many hardware bugs with the FP3 that were never acknowledged by the vendor and unhappy customers with bricked FP4's that requires sending them back in.
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.
To add to that last point, after some time being frustrated with an FP4 and browsing the FP forums: it's not just availability of spare parts to repair shops. There doesn't appear to be a single mention in the forums of a repair shop willing to work on the FP4. There are numerous mentions of repair shops that are unwilling to, and of people being unable to find repair shops. Warranty repair is actually outsourced to a generic warranty support company that appears to operate on standard, replace-everything basis.
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.
> There doesn't appear to be a single mention in the forums of a repair shop willing to work on the FP4.
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.
>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.
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.
A thousand tims this. When I moved away from stock Android and on to cuwtom ROMs a few years ago, I didnt find anything that met my needs but then I stumbled on GrapheneOS. I understand why it doesn't run on non Pixels but their approach to handling Google Services and preinstalled software in particulqr should really be copied by other ROM maintainers and developers (something I'll give a shot in a few short 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".
> My only gripe now on my 2nd Pixel with Graphene is exactly what Fairphone is fixing, which is easy hardware maintenance + 3.5mm jack.
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.
> Too many hardware bugs with the FP3 that were never acknowledged by the vendor
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.
* Easily damaged by moisture (even though they've claimed certain IP ratings), due to the printed conductor inside the plastic layers with pin connectors
* 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.
I see a lot of people mentioning Fairphones not being on par with phones by multi billion dollar companies.
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.
I bought a FP3+ a year ago and run it with LineageOS (with microG). I don't have any of the issues you list except for LED and brightness. However I do have random troubles with location, but that's probably due to being de-googled.
Regarding WiFi, did you try disabling the "battery optimizer"?
>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.
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.
I wished there was a Graphene/Lineage OS phone (OEM supported; not “flash it yourself” sorcery needed kinda thing).
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.
The Fairphone is going to be sold in the US in partnership with the e.Foundation which develops /e/OS (another deGoogled android fork), and is what's going to come preinstalled on the Fairphone https://murena.com/america/shop/smartphones/brand-new/murena...
I have been a happy user of an /e/OS Fairphone 3+ for two years. I just use it like my Samsung before, nothing special to do (other than choosing non Google apps, obviously).
I had an XZ1c and, despite the bezels, I still prefer it to the Zenfone 8 that succeeded it. Unfortunately my carrier forced me to "upgrade" otherwise I'd likely still be using it to this day. And my god it was robust. I did unspeakable things to that phone and it never chipped or cracked - and we're talking drops on to gravel, concrete, and steel.
Hopefully one day we'll see something similar again.
Apple tried to bring small phones back and not that many people bought the mini relative to the regular size iPhone. Other than a few attempts by android phone manufacturers the iPhone 13 mini will probably be the best small phone made.
The thing is, for people who want a small phone, the 13 mini still has a pretty hefty feel. Compared to the 5s/orig SE body it's massive and it's only a tiny bit shorter and narrower than the 8/new SE, while feeling thicker.
I was on 12 Mini. Was getting a crazy trade deal and the seller didn’t have 13 Mini. So I ended up buying 14.
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.
I don't think vendors can stop themselves from putting garbage in their ROMs. The OnePlus One had CyanogenOS, based on CyanogenMod. That didn't last long. Now I've heard the default ROM on OnePlus stuff is particularly bloated. I still use their hardware, but I only buy phones I can put another OS on, like LineageOS, or postmarketOS in the case of the PinePhone. I update the new-to-me phone right away to get the latest baseband firmware and such, then unlock/wipe/flash ASAP. Can't imagine doing it any other way now. If you buy a couple gens back of a OnePlus phone on eBay, they're pretty affordable.
As a note about repairability, ignoring various problems with the phone: while the FP4 does have more availability of parts from the manufacturer, is generally easier to repair, and is advertised as repairable, I found the Fairphone forums to be surprisingly and unexpectedly hostile to discussions of repair and repairability.
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.
Fairphone 4 has been my main and only phone for several months now. Great experience, very good battary life. Performance-wise, I haven't noticed any significant difference compared to traditional phones. The only drawbacks might be the camera and thickness, but honestly I don't care much.
Of course, much depends on your use case and expectations. YMMV.
I really want to love my Fairphone 4 but they really need to improve their software support. I have a bunch of bugs with my device: the screen dims after a short period making it unusable in bright daylight, NFC is erratic and needs a restart to fix, 5 GHz hotspot hasn't worked for months. The brightness bug is the biggest killer for me. There's a whole list of bugs tracked on the Fairphone website [0], and progress is unfortunately very slow.
I've been using my Fairphone 4 for around a year or so and it's been great.
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.
Fairphone is also tackling this. They guarantee 5 years but have been providing updates well past that. The Fairphone 2 from 2015 got upgrades to Android 6, 7, 9 and 10 with the latest security update in March this year. You can see their release notes here: https://support.fairphone.com/hc/en-us/articles/360019515018
I believe that the root problems are programs having direct access to environment, being compiled down to hardware instructions, and these instructions not being easily interpretable (without having access to an already made interpreter)
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
> In other word, my suggestion would be to create a new target platform that compile down to a very understandable instruction set and leave environment access out of the spec
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.
> The vast complexity of modern software and hardware comes from the ever more complex environment they interact with.
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.
> 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.
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.
> bf could, lambda calculus as well, or potentially cellular automata
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.
> Good luck turning those into silicon with any kind of performance.
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.
As a software engineer who spend the vast majority of his time on (successfully) putting newer Android versions on the vast majority of older Android devices:
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.
I fully understand your concerns, but still I believe that you aren't asking yourself the right question. Why do you need to port newer Android versions on older devices at all? It seems like the real problem to me.
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
As far as I know, that's wrong? You must "target" newer OS versions (to prevent loopholes as you mention), but you can still have whichever "min" OS version you want.
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.
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.
I think yes. It's not easy to design and manufacture a phone using sustainable materials and components from vetted sources who treat their employees fairly, unfortunately. And to do it in such a way as to be easily repairable. They've set themselves a high bar and I think they've done a great job
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
Doesn't that mean that buying the newest Fairphone in 2023 gets you 0 years of Android updates and 3 years of security updates? Compared to 4 years of each with a midrange Galaxy A?
The FP4 was out in 2021. That's 5 years. But you're right, and it's actually discounted 50 eur because of that. You can wait for the FP5 if you're not satisfied
That's not solving anything at all, what we need is hardware that doesn't need to have its software updated constantly. If you cannot have that, I wouldn't consider it ""sustainable"". There is nothing sustainable about depending on some company on the other side on the world to do the right thing continuously.
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?
This is because you are still assuming software being developed the same way. Could you give me an example of potential risk that is absolutely impossible to solve no matter how we change the entire computing process (from users running the app, to the app developer, and to the os developers)
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
Cryptographic functions for example. Today they might be cutting edge, but tomorrow someone might have found a critical exploit or the hardware has just become too powerful.
I will likely have some software compatibility/security issue by using a 10y old phone. Theoretically I do not have to, but software is designed with constant internal requirement changes.
> Every single useful device on earth that is connected to the internet needs to be updated regularly.
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.
Well said. Phones lose support long before their hardware is actually too weak. Also if we tried to optimize the software better, less of the hardware would feel weak.
I like that we're moving in the direction of repairability. I haven't needed to upgrade my pixel 2, and I would love it if I could simply replace parts as needed instead of buying a whole new phone. That said, it seems clear that phone makers would prefer you upgrade every two years. Wonder if we will see regulation around that in the coming years.
When people talk about the Fairphone there are always people bringing up the same or similar (often very valid) points. I would like to use this post sum up some Reddit discussion I took part in when the Fairphone 3 launched because the main points are still relevant for the Fairphone 4 launch:
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
Reading through the poems, one in particular stood out to me, ‘A screw Fell to the Ground.’ While it was done eight months before his suicide, the context seems to be relatable to how he may have been feeling—mostly the sound of “someone” plunging and nobody hearing.
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’
The poems, translated at the leftist website Libcom.org, are a wrenching echo of the alienation and hardship felt by countless people in modern China and, for that matter, in other parts of the developing world. They lament the grinding ennui of the assembly line, the squalor of a migrant worker's narrow, frustrated existence.
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.
It's not only the Asian workers! They also go to great pains to make sure the people mining the basic resources, for example in the Congo or in Peru, are paid more fairly than usual. That combined with pretty much what you said makes the price easily worth it for me.
> 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?!
Sounds like they are confusing it with "Phoneblocks", which went viral around the time the FP1 launched. Logos look similar, too.
So does it mean it's not possible to have popular apps like whatsapp or Tinder on this?
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.
I have been using a FP4 for about a year with /e/-os, and it has been pretty ok so far. I don't use many (if any) of the /e/-os cloud features, so can't speak for those. Other apps have been working fine w/ microG and the custom app store (which combines the play store and fdroid). The only issue I can think of off the top of my head is google translate not working. Other Gapps (Gmail, yt, lens, etc) seem to work fine, as do pretty much all others I have tried. Unsure how well in-app purchases work. Some /e/-os apps have UI quirks... But nothing is worse than "ok" in my view. Ymmv.
Not sure I buy that lightweight phones would necessarily be better for the environment? Surely repairability is key?
I've got a FP3 (so the older model) and I have had no problems with any app. I don't use Tinder, but Whatsapp works as good as on any phone I've ever owned.
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).
Or keep your phone. I’ve been using a iPhone 5s since 8 years now.
Support dropper a year ago iirc. So that’s not advisable anymore.
But I’m still happy with the phone and most things still work
I wasn't able to tell from a quick scroll over the homepage, but while they fix instead of replacing, teracube don't seem to include fairly sourced resources, which are a pretty big sales point for fairphone
Years ago this would've been interesting to me. But it took too long. Given that the Fairphone 4 has been out everywhere else for years now and there wasn't even a peep of it coming to the US, I decided to jump ship for an iPhone.
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.
GSM, CDMA and UMTS are all dead or on their way out in the US. In terms of LTE bands I think T-Mobile (or MVNO's depending on their network) is the sole choice.
It might work on verizon but it lacks their low bands so coverage won't be good. No way it works on AT&T due to their stupid IMEI whitelisting. Notably it's also missing T-Mobile's N25 which is probably going to be their main midband 5G band eventually, but it has all the others (no B26 LTE but that's old sprint towers almost entirely phased out)
I would just love a good Android based phone with a Blackberry style keyboard. I know there are a couple out there, but something from a current large manufacturer would be nice.
Got a fairphone 4 for somenody I care about and will likely get one for myself when my current unrepairable, glued-battery piece of e-waste becomes unusable.
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.
This is cool and all... I just wish someone would release a device with user replaceable battery and better OS update policies. Basically a pixel with slightly easier repair.
I think the modular aspect is cool, but seems like a gimmick that would be prone to failure. Just my opinion anyway.
Issues with microphone on the FP4 that are not explainable but the good news is? I can just change the mic for 20 euro!
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.
All modern smartphones have masses of proprietary stuff to turn gigabytes of raw data from the sensor into a beautiful photo.
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.
I'm not sure that it's truly all down to software, but as far as it is, you don't have start at zero -- there are excellent, competitive raw photo processors available as free software, like darktable and RawTherapee. Still a lot of work, though, no doubt.
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'.
If you wanted to do this 'opensource', your best bet is to try and get the GPU to do the work. You'd need hardware/HAL support for streaming raw data at ~15Gbits to GPU accessible memory, and after that you can probably do most of the rest using software without hardware/kernel involvement.
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...
My experience with fp4 has been pleasant. No problems. The only mild annoyance was the finger print unlock mechanism, which feels less user-friendly than my previous phones. But you get used to it.
Tester here. After some months of working out the kinks, this phone and OS pair are working great. I strongly recommend (if you are okay with a so-so camera).
People should focus more on waste avoidance and reuse instead of buying a new gadget allegedly made from recycled materials that only lasts 3 years. I say allegedly because making durable, nicely colored materials from waste is so hard that we don’t know what tricks were used or shortcuts were taken to make this happen.
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.