paradox2011

These are the kind of subtleties that people often miss, thank you for expressing them.

You end your comment by saying...

"Which makes one wonder why CalyxOS, with an entire team behind it, doesn't follow the same example"

When you already answered your question in the beginning...

"To understand the purpose of CalyxOS, you must understand the purpose of the project, of course"

If you compare CalyxOS to DivestOS or GrapheneOS, then you've missed the point of CalyxOS, "the purpose of the project". They are intended for different people, though there is some overlap. CalyxOS respects FOSS much more than does GrapheneOS, and to me that's a very valuable thing. They tighten privacy, but are not as focused on security alterations beyond stock android, beyond making it less leaky when it comes to personal data, which in its own way is a reinforcement of security.

Also, DivestOS has "divested" itself of participation in the privacy/security game and stopped all development. It's sad, but I'm happy that the developer is getting to live his life to a fuller degree now. He contributed a lot of value to the open source world in the past.

Thanks for the TL;DR, I figured it would be a uneducated take, you saved me the time of watching it 🫡

I'd suggest looking in to it farther. The commenter above basically covered it, but no, beeper is not all closed source. Their hosted server has never been open source, but all the self-hosted bridges have been, and continue to be. You can run your own, open source, self-hosted beeper server, just like you've always been able to. There's nothing embrace, extend extinguish about that.

Where did you read that? The github pages are all still open and receiving updates, you can still self-host the bridges and its under the apache-2.0 license, just like it's always been.

Sadly it doesn't 🥲. Copying app data is the hardest part of the process without a system level backup like seedvault, neobackup or traditional google backup services.

Only if you're currently running stock android.

NeoBackup is the only one I've run across that seems to really fill the role of backup and restore thoroughly. The trouble is, in order to work it needs root, so I've never actually been able to try it. Almost reason enough to root in my book 😅, I love a good back up system.

Seedvault is another fairly well developed option, but it needs to be hardcoded in to the OS by the ROM developer.

You'll probably benefit from a series of different backup apps in combination. Here's a few that I've used and benefited from:

SMS import/export - backs up all SMS, MMS, call logs and contacts. Does not backup RCS.

Applist backup - back up your installed app list. This includes data on where you installed the app from and where you can get it again along with other useful info. The apps still have to manually installed.

Aside from those two, most FOSS apps include a backup and restore function, such as: signal, neo launcher, fossify calendar, newpipe, metro (music player), aegis (2 factor), obtainium, etc...

I hope this helps. I tend to tinker and install various ROMs, so am well aquainted with the pain of setting up a fresh OS without a system wide backup program. Its not as bad as it seems though, and as long as you get your messages, contacts and call logs moved over it goes pretty smooth.

I do see a mention in that post about instead supporting the jellyfin client developers. They give this page as a reference for who to support based on which client you use.

From a pragmatic standpoint, yeah it would accomplish that goal. However, that discounts the intended purpose of the stars, which is to represent an individuals attribution of personal value and trust. They lose significance and become misleading if you can buy them, which holds true even for good software. When we see a github star is should represent someone who has used the software, finds value in it or who respects and trusts the project.

This interview with the developer of MicroG might be interesting if you'd like to learn more about it's benefits (or downsides) over sandboxed Google Play services. It debunks a lot of misconceptions or rumours about MicroG.

MicroG collects very little information about the user. It does less data collection than sandboxed Google Play despite it being a system app. MicroG is a more transparent, community driven piece of software that distances people from Google to a greater degree in my estimation, though I don't have developer level understanding of the software. Just basing my thoughts on interviews and published information like the video above.

Personally I prefer the privacy/open source oriented approach of MicroG, but I also run GrapheneOS so haven't been able to use it for a few years.

I think saying it's just as bad is an overstatement. MicroG sends fake data or no data in the majority of data calls from Google servers and only interacts with Google when it needs to in order to make a given app function. Sending drastically less data to Google is a win and fits many people's threat model just fine.