People want to, but few but you have the life setup to do it full time.
If I do manage to hit escape velocity one of the first things I would do is double down on helping people like you and supporting open hardware targets.
Until then it is deciding what is most tolerable.
Conversation
The Librem 5 and Pinephone are not open hardware targets though. Librem 5 is even closed in ways that the Pixel hardware is not. Pinephone at least doesn't do destructive things making things substantially worse to play stupid semantic games to get a meaningless certification.
2
1
The librem laptops/desktops ship coreboot/heads firmware, neutered ME, and run with no OS blobs.. Give me that in a 5 inch form factor even without a cdllular modem and we are getting closer... But no such luck yet.
1
So, still entirely closed hardware / firmware, just with some bits of the firmware supposedly disabled. Pure security theater incomplete form of verified boot / attestation that's there for marketing instead of as a meaningful or usable implementation (it's neither).
1
1
Not sure why you care so much about proprietary components for device support in the OS that are not obfuscated and have full symbols available. It doesn't matter if the code is open or closed source beyond barrier to entry in working on it and people don't work on either anyway.
1
I care about those blobs because they represent a massive amount of attack surface that, as you admit, no one has time to reimplement and/or audit.
At least Google reviews the code they write, but it is obvious they don't review blobs either given vendor quality.
1
Google and other vendors are given the source code for these components and get to build them from source. The reason these things don't get attention is because they are specific to a hardware generation and no one cares to invest much time in something that becomes obsolete.
1
1
It doesn't particularly matter whether this code is open or closed source. Either way, people are not working on it much. Most effort goes into the device independent code. AOSP doesn't have blobs. Devices have blobs, whether or not you run AOSP using those or something else.
2
Mostly I guess I express frustration in the daunting volume of blobs in current gen devices. Google creates so so much work for the community with their vendor release approach.
Keeping up with them properly would be multiple full time jobs.
I overall take your points though.
1
Far less of those things are actually blobs than it appears. It's largely Google creating this problem by simply releasing the vendor image for Pixels rather than putting support for it in AOSP. You don't need to include any of the components in the system image. Just omit them.
2
1
The vendor image is largely either open source or unnecessary. The proprietary components in the system image can be omitted with little loss in functionality (VoLTE, Wi-Fi calling, RCS for various carriers which don't generally work anyway, fancier Bluetooth audio, is about it).
The actual blobs that are required are for the radio functionality, GPU, camera drivers and so on. Most of the stuff there is either open source or cruft that's never even loaded / used with AOSP in practice. Lots is never even used with the stock OS. It's the whole SoC SDK.