Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fairphone 4 is coming to the US

arstechnica.com

Post reply on HN
Print view View original

71–80 of 133 posts

Re: Fairphone 4 is coming to the US

#71

Post by pSYoniK »

miduil wrote: post #12

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 expe…

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".

Re: Fairphone 4 is coming to the US

#72

Post by TheMode »

ben-schaaf wrote: post #68
TheMode wrote: post #39

Earlier quoted context omitted.

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…

> 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 attac…

> 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.

Re: Fairphone 4 is coming to the US

#73

Post by phh »

TheMode wrote: post #49
phh wrote: post #36

Earlier quoted context omitted.

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…

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 se…

Looks like I mis-explained.

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.

Re: Fairphone 4 is coming to the US

#74

Post by conradev »

miduil wrote: post #62
cge wrote: post #47

Earlier quoted context omitted.

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…

> 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 som…

You mentioned Framework: I hope they make a phone in 3-4 years.

They made an excellent repairable/upgradeable laptop and I’m sure they’d build a great phone

Re: Fairphone 4 is coming to the US

#75

Post by londons_explore »

londons_explore wrote: post #64
morsch wrote: post #50

Earlier quoted context omitted.

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.

heh - no. 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? Ther…

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...

Re: Fairphone 4 is coming to the US

#79

Post by dopidopHN »

jokoon wrote: post #46

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…

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

Re: Fairphone 4 is coming to the US

#80

Post by ben-schaaf »

TheMode wrote: post #72
ben-schaaf wrote: post #68

Earlier quoted context omitted.

> 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 attac…

> 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…

> 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.

Post reply on HN