I believe they are claiming that with the new discoveries it’s pointless to keep trying. Whether that’s shared with other devs or not probably won’t affect their decision:

These three bugs basically ruin the whole point of arkenfox: // sec bugs: offscreencanvas / preconnect / cookie_exceptions

I’m not that familiar with them, but sounds like there’s no way to keep a sane balance between usability and privacy, and clearly upstream doesn’t help a bit, it’s like following the Borg advice “resistance is futile”. Battling the privacy fight is not an easy fight I guess. The only hope for those who are non experts as the arkenfox guys is that phoenix keeps up the good work. Overall I pretty much prefer arkenfox over phoenix, but fortunately Librewolf is neither arkenfox nor phoenix, even though they are discussing if they are better based of phoenix the are different projects making different decisions…

I wish frozen fennec didn’t die on the attempt, :( The current option is ironfox on LOS/AOSP based/…, and I don’t agree with several of their decisions. The amount of filter lists is so stubbornly huge, that there’s no time to deselect and/or remove them on low end phones for example, and the whole thing just slow things down. And I know it’s picky but I really like decisions like taking bad things off from build time if possible, even if they are opt-in… Any ways, to me it’s sad to see them closing the project, but I’m also hopeful some others as expert as they were on several of the topics they dealt with will fill up some of the the hole when they stop…

Cool, it never came back to arch/artix, however I see it on aur. I actually don’t use gui for mpd, I use ncmpcpp, but good to know it has quite good gui frontend. Aria is good as well, particularly if not much into Qt apps.

https://grapheneos.org/usage#sandboxed-google-play

I don’t know if your complain about serxng is something you’ll eventually get with 4get. Whatever works at any time. See google and other search engines had been playing awful to searxng. At some point google will notice 4get instances and will take on them as well. On searx[ng] on the side one can see what has been suspended, denied, timed out, etc.

Time wise, 4get allows for only 1 engine at a time. searx[ng] allows for several no wonders it can take time. BTW the user can choose any of the engines per search they want. That of course can take more time. The point is that right now all search engines have taken it on searx[ng], and options are welcome. Self hosting is working better maybe because the search engines don’t feel threaten by it.

The good thing is to have alternatives.

BTW, I thought google found the way to finally get rid of invidio, but it seems there are a couple of instances still working. Good !

DeGoogle doesn’t make sense if keeping google services and google play (this provides services any ways). For example grapheneOS as best as it is for security is not a DeGoogle experience. calyxOS would have been an option but it’s currently out of maintenance. LineageOS with f-droid basic, apkupdater (apkpure mirror) if needing proprietary stuff and maybe aurora store if apkpure doesn’t find something or you distrust it (it’ll be connecting to google play), and for them, if needing google push notifications (most of them do) and unavoidable services then microG.

Some FLOSS apps requiring push notifications allow to use unified push btw, like jami and davdroid (davx5), molly (signal client, though I no longer use signal), so no need for google push notifications, and for email imap has supported it’s own push notifications mechanism for way long (fairemail, thunderbird, etc). It’s on proprietary apps which mostly that’s not the case… Installing from official f-droid I believe gets rid of proprietary google stuff, including dependencies on google services library…

cantata is no longer maintained AFAIK, but as mentioned there are other clients such as ario, which on arch/artix it is build on gtk3, not gtk2

Not specific to grapheneos, and also battery friendly on LOS is localsend, and on gnu+linux I use instead localsend-go since it offers a CLI (what I use) and a rudimentary TUI which is missing some functionality but good enough (I prefer using it as CLI). But localsend also includes a windows app BTW. On gnu+linux some prefer kdeconnect, but I find it more battery intensive than localsend on the phone, and the extra functionality is not what I expected, like I originally guessed I could write sms from a gnu+linux box, or read past one, and that’s not what sms control means.

Don’t these alternatives work on grapheneos for some reason?

If you want to keep using google playstore and services, you no longer will be able to use f-droid, whether google or any aosp rom. grapheneOS claims it won’t be affected given their sandboxed google play and services. Though I’m not sure if eventually google would come up with a counter measure or it won’t ever care. They want to enforce that if anyone uses their proprietary stuff the apps interacting with it must be from register developers, which automatically exclude any libre/free app storage on which developers don’t want to register to google. GrepheneOS being the exception.

If you use microG with any custom rom, I guess that might work through fake registrations, but can’t be sure. But any custom rom without google play and services is supposed to be ok with f-droid. The thing is that google knows most if not all users need one app that depends on their stuff, perhaps bank apps, payment apps, and so on…

Papers or Zathura (+ required plugin)

Just so you know, if you like freetube, you can configure the external player to mpv, which underneath uses yt-dlp when streaming, and use the button to load the external player. Of course one can also launch smplayer, which underneath is using mpv, which underneath…

But the thing is content creators don’t move out of YT cause they’re there to monetize in the first place. So this thing seems never ending no matter alternatives like peertube exist.

Besides outertune there’s harmonymusic as well

None protect your IP if not using a non self hosted frontend like invidio or piped, cause if self hosted then you’re providing your IP any ways. So now a days actually private is kind of hard. But these applications for sure help a lot.

2025.09.26 can still do it without deno. Besides, when the change happens, node and bun (never heard about bun before) will be supported as well, not just deno, but they will require extra arguments passed to yt-dlp. If using yt-dlp directly, and already having node or bun installed, no need for deno then.

apkupdater installing from apkpure?

I’m wondering about LOS re-locking on particular devices. DivestOS used to allow that, not sure if only on pixels, but if divestOS which was based on LOS could, I don’t see how that code can not be ported over upstream LOS. Have anyone seen an effort similar to divestOS in this regard?

I’ve been a long term freetube user, but lately I’m finding pipeline built locally through AUR, formerly known as feetuber, a much better experience at least for me. I’ve set it up to use ytdlp and mpv all the time, so I don’t care about Piped sites. It supports Peertube already, and it’s way light, at least with mpv playing it is

There are a bunch of non bloated alternatives with whether wayland compositors and also X11 window managers, and there’s also kde/plasma, xfce and mate if still wanting full DE, plus a hybrid lxde-gtk3/lxqt (lxqt supports both X11 and wayland I believe).

If going the non bloated ways, distributions can offer some modifications on the system configurations files, so that users can start with working software out of the box, and can even offer installation meta packages for a complete set of i3/sway packages to have an equivalent DE experience. What would be left to users is custom settings to get more appealing aesthetics depending on the user, if not i3/sway, then openbox/labwc, and so on. For a DE experience including into the meta package a toolbar like yambar (works on X11 and wayland), dunst/mako, udiskie, redshift/wlsunset and so on. The missing part on non bloated alternatives is easy of configuring through buttons and widgets, and even so lxqt made an easy of configure software component for openbox, and there might be something similar for labwc.

So non systemd distributions are far from dying because of gnome’s hostility.

And if I recall correctly, several gnome users (not its huge base of course) are moving away from gnome any ways unhappy with its plugin support, given gnome is known to leave plugins unsupported on its releases and not caring about them.

Of course using another distro you want to emulate is much better.

But as it’s debian based, I’m wondering if a better approach would be to use repos from another close enough distro, like derivative distros which decide to build the stuff for the distro as much as possible (that maybe won’t prevent the need of flatpak and the like).

Another approach would be using a package manager that can work on top of any distro, like Guix, at least for FLOSS software.

I use artix, so if something is not in the official artix repos pacman also look on arch repos, then it looks my personal repos (I build some personal packages, but I also use aurutils, so there are packages on one of my personal repos that are really aur packages not mine). As I prefer to package the stuff I can’t find anywhere I haven’t found the need for something like Guix, but it might come handful if in order to include some software which depends on software way old for artix or something similar to that. Just a reminder that Guix and the like will work fine as package mechanism on top of any distro given their approach to keep the software out of the common unix path hierarchy.

Both Tubular and Libretube support SponsorBlock, in that regard both are cool. I would use Libretube first, and if no piped site works then use Tubular, but Libretube itself allow for using local connection or it could be set to only work that way as NewPipe/Tubular do, so perhaps there wouldn’t be a need for two apps.

The advantage to start with Libretube is a bit extra privacy by using a 3rd party piped site, so what youtube sees are requests from that site. But piped sites are more identifiable and therefore vulnerable to be rate limited or totally blocked. Though lately youtube has managed to block everything pretty close in time, Freetube, Pipeline, HarmonyMusic (a bit more resilient but also gets blocked), NewTube, Tubular, LibreTube, whatever.

Google is shortening the periods on which any of these frontends can be used to access youtube. Sadly, as Google offers some profit depending on the visits (more adds) then people seems not to be interested on leaving youtube, :(

uSo it doesn’t seem to be a frontend which is less prompt to functionality disruptions. Some times it takes less time and some times it takes long, but usually most if not all frontends get affected. In that regard I don’t see much difference, so that’s why I recommended Libretube first and then Tubular as an alternative. Given there’s not frontend supported by Google, in the end it’s almost a matter of taste, with any Piped solution offering a bit extra privacy if used with 3rd party piped sites, and if that site is blocked or rate limited, another one can be chosen, or even it can try on the run to connect locally, or you can actually stop using a 3rd party site at all and only connect locally. BTW, freetube can be set to use an invidio site as well, but there are way less invidio sites up and running that there are piped sites. One can self host, but then the requests to youtube will be yours any ways, though you get local subscription and nice stuff on all frontends.

I like to have an alternative though in case at least for a little while one mechanism works but the other doesn’t.

BTW, if interested on music, HarmonyMusic is a bit different frontend that can run on several platforms, gnu+linux, android and so on, and sometimes it keeps working while the other frontends don’t.

The battle is still there, and the GrapheneOS guy always bark at microG, like he really hates the whole concept of microG. What I have gotten from the discussion is that GrapheneOS is more secure, but although it sandboxes GPS denying some permissions, and some of those might be needed to be given away for some services any ways, it doesn’t try to fake anything, which microG does. In that sense my preference has been microG, and I don’t regret it.

That said, what you mentioned is true, both still access google app store, and still have to give some minimal information to google.

There’s a 3rd option the OP didn’t mentioned. If they are mainly interested in app store, and not the google services in general, there are a couple of somehow recognized 3rd party app store mirrors, which keep the same original signatures of the packages hosted by google app store, and they offer packages from other sources not provided by the google app store, in case interested on those packages: apkmirror and apkpure. From the two apkpure still allows to install and upgrade packages through FLOSS 3rd party apps like apkupdater, so that might be an option. For some months apkpure packages weren’t able to be installed through apkupdater, but it seems that got corrected already.

But in general, the OP would benefit from always looking for FLOSS packages on the F-Droid repo, then other non official F-Droid repos which can be used through the F-Droid app, then see if they can be installed from their web site and updated without intevention of any installer, and then if there’s no option but using proprietary software maybe looking for them on the apkpure/apkmirror sites or on apkpure through apkupdater or similar, and then aurora store, or if using grapheneOS finally google play if anything else fails, :)

I do understand the need for proprietary software, like bank OTP apps. It’s sad banks, governments, medical services and so on never look for FLOSS software, they always require users to get proprietary software. I don’t live in the EU, but I hope current hate/banning tendency ends up doing user a favor by starting to require banks, and the like to start using FLOSS apks, though doesn’t really helps me, I hope in the end it helps people in the EU.

This is a security feature. Other communication mechanisms having the keys somewhere else not owned by you is rather something I wouldn’t stand. And to me it’s unsafe that messages would be kept way long on the servers.

On xmpp the sync happens from server to all syncing clients, and the proper XEPs need to supported in both the client and the server.