Conversation

Replying to

Using Android isn't a reason for the lack of long-term support. It doesn't place limitations on that and isn't the reason for it. Comparing to Apple is entirely fair and Fairphone doesn't compare well to vendors shipping 3-4 years of proper updates according to schedule either.

1

3

Replying to

and

Compare the products and decisions made for them with the rhetoric and it doesn't hold up. Claiming to be offering 6 years of support while only being in the position to do it properly for 2 years and likely not even executing on that well is dishonest and is pretty much a scam.

1

4

Replying to

and

> just like 10 yr old laptops can run Linux and still be secure so will Fairphone This simply isn't true and isn't how things actually work. On a 10 year old laptop, where exactly are you getting updates for the firmware, and who is maintaining the driver code, etc. properly?

3

3

Replying to

and

So you say that Linux kernel doesn't support "driver code" properly?

1

Replying to

and

Linux kernel driver code mostly isn't tested or directly maintained. There are frequent API changes resulting in the driver code needing to be updated to continue building/running. It's one of the things that leads to the driver code rotting away without direct maintenance.

2

1

Replying to

and

Are vendor procedures any better? How do you know that?

1

Replying to

and

Not clear what you mean or who you think writes / maintains most of the drivers.

1

Replying to

and

I mean maintenance of vendor Android variants.

1

Replying to

and

I'm not following what you're trying to insinuate. The kernels for Android devices are generally based on the Android common kernel kept in sync with the upstream LTS releases. The upstream kernels take years to get poorly maintained, half working drivers for the components.

1

Replying to

and

Those are never well tested or maintained. They're rarely the subject of security research or hardening. Most of the work on them is done by the hardware vendors, but it's not what they use in practice and it's not a focus for them. They don't promptly upstream security fixes.

1

Replying to

and

You seem to be misunderstanding how Linux kernel driver development/maintenance tends to work and also how things work with platforms like Snapdragon. Upstream support for the hardware starts slowly coming together after launch and never reaches the point that a serious option.

6:37 PM · Oct 3, 2021Twitter Web App

Replying to

and

If you think upstream drivers for other platforms in the Linux kernel are well maintained, secure, or heavily reviewed you couldn't be more wrong. You've got a completely wrong impression of how it works. A driver being upstream just means it gets blindly ported to new APIs.

1

Replying to

and

Theoretically easier to use as a starting point to make a stable driver for a recent kernel because the people making the API changes kept it building, although often not actually working. Those drivers are often incomplete/broken in the first place. Not a marker of quality.