What’s about the problems, described in the article below. Are they solved?
as the articles relies on the Dec’2023 Kuketz Review, this answer still has valid links: Is the feedback from Kuketz to /e/ OS taken into account? - #2 by tcecyk (and u/Undertakers summary/translation)
- Browser updates are more regular now, the filter lists are configurable and homed at cromite
- AppLounge isn’t delivering old Playstore apks. I think it can happen to fdroid apks but there’s no filed issue on this as far as I can see. Maybe in the feedback threads.
- microg switch in the initial setup wizard or a murena a-gps proxy: those are unaddressed. I’d think rather due to available resources than anything else
- deliberate product decisions: I haven’t seen the ota-id discussed much, there seems to be no pushback
- verifiedboot: as the article itself writes, you can do this on select models
there are straightforward actions you can take on most of the criticisms
Thank you for the detailed answer.
Accordingly, most of the points are outdated and it would probably only be necessary to check the microg switch during the initial installation.
Suggestion: It would be great if corresponding release notes were included with every update. Then even laymen like me could see what has been improved. Who would I have to address such a request to?
I’d say the majority is unaddressed and only a minority outdated. But yes, the gist is: more switches in the setup wizard can pre-empt the main thrust of the criticism.
As linked, there are 2 gitlab issues on switches in the setup wizard (microg and connectivity-check) - in both I pointed at code where it would happen. Users can vote on that or send a patch (more than 4 votes puts you already at the top of the list if re-opened).
Frankly I didn’t have the motivation myself, it’s not something I care about at heart - microg settings are a step away, connectivity check at murena is non-aggregated, I don’t see the threat. But it would add to murenas credibility to offer those switches - though I’m sure it will lead to more support burden with users turning microg off and running into difficulties.
I’ll have a look at gitlab to see how important these two points could be.
I can understand that the microg switch could lead to problems.
Perhaps it would be enough to point out the points during the installation process?
Ps. What is your opinion on release notes?
there are high level release notes - Settings Updater: Add link to release notes for upcoming release (#7500) · Issues · e / Backlog · GitLab (the bug is where the link leads when updating) - you can also just browse them at notes · v1-u · e / os / 🚀 Releases · GitLab (use branch of your Android version)
The desire to be able to easily remove pre-installed /e/ apps and microG in particular has been around in the community for years. A current Android distribution with LineageOS code base from the south of France shows us how easy this can be.
During the initial setup, the user can decide which app recommendations should be installed. But all pre-installed apps can also be uninstalled later during operation - including microG.
It is therefore a decision by Mur/e/na’s management that the pre-installed apps cannot simply be deactivated and uninstalled.
@MarcelloT I wouldn’t mark my answer as “solution” - in the context of your initial post the release notes are not a solution
@Xxpsilon uninstalling default apps isn’t part of that particular Kuketz/repost criticism. It comes up elsewhere, but this and linked threads are about that review in 2023. Yes, iodé has that microg switch in the setup wizard and in general I think it’s a good place for lots of decisions
If you are referring to IodéOS, I think it shows us how much work it takes to implement and maintain this functionality. It may be easier for users, but it’s significantly harder / more work for developers
Of course, it isn’t a solution, but for me it’s done. Thanks
Who can do it like Vincent, it’s easier. And of course it takes work and time. I appreciate this effort from vince31fr.