RE: https://fosstodon.org/@furilabs/115777683365761046
> If you don’t want to follow my route and burn your money to test everything what is available you can also choose to pre-order the FLX1s and support most polished and complete linux smartphone today.
While this is a lovely statement, I would prefer to not burn money on Android based phone as FLX1s.
Having mainline support for your hardware isn't easy or nor cheap. It requires huge investment. I'll rather continue working on OnePlus 6/6T support until it can be daily driven by regular users.
The huge value of mainline based phones is the longevity and relatively low-cost of supporting the phone for many upcoming years. This cannot be reasonable done for Android based devices (at least not ar voluteering scale, without having many full-time employees).
@okias For these reasons I prefer to buy also the hardware from a company that works on mainlining like the #Librem5 by @purism.
And yes, developing the software and OS is a huge (thus costly) endeavor.
Therefore it is possible to support the development of #PureOS with a total optional subscription:
https://shop.puri.sm/?s=pureos+subscription
Also the development is in the open. Here you can see the milestones:
@janvlug @okias While I agree that @purism did A LOT for our community (and I praise them for that), their kernel mainlining efforts seem to have stalled a while ago; the L5 kernel is still on 6.6 (now 2 LTS releases behind, and to be EOL'ed 1 year from now) and it currently requires more patches (based on the 400-ish commit count) than any other community-supported phone, if I'm not mistaken.
Until that changes, "mainlining" is sadly no longer a valid argument for recommending the #Librem5.
@awai @janvlug @okias @purism Commit count is misleading - there are 86 commits just for the big cam sensor driver, which is rather small and these all would be squashed down into a single one if upstreamed; and further 20 commits on the Redpine driver are later nullified by importing its newer version.
Also, you only need a handful of commits to have a kernel that boots into something usable: https://source.puri.sm/martin.kepplinger/linux-next/-/commits/6.12.11/librem5_light
@awai @janvlug @okias @purism FYI just did a quick clean up to get some better numbers - dropping patches that are later reverted, squashing downstream driver commits, dropping debug/obsolete/devkit/packaging/CI stuff, things backported from upstream etc. - but not very thoroughly.
Ended up with 174 commits.
133 files changed, 33472 insertions(+), 1541 deletions(-)
When ignoring Cadence and Redpine drivers:
68 files changed, 5908 insertions(+), 369 deletions(-)
https://source.puri.sm/sebastian.krzyszkowiak/linux-next/-/commits/6.6.118-rebase
@awai @janvlug @okias @purism A good chunk of those should be trivially upstreamable, though personally I'm holding up with doing it until we're back on current trees, as that will make testing much easier.
Some of this stuff will still need a solid cleanup before going upstream though. There's also a handful of commits that add things that have been explicitly rejected by upstream, such as cpuidle, so I don't expect to ever be able to get to less than 10 commits or so.
