>rsshub

This has been one of the key programs for me to move 90% of my "timeline" into an rss reader.

If you self-host it, you can also pass it authentication tokens to RSSify things like:

- your twitter timeline

- github notifications, issues, commits

- discord messages

- youtube subscriptions

- spotify/twitch/steam/etc.

An to add another project in a similar vein (scraping to turn pages into RSS): https://rss-bridge.org/

>And I'd rather keep the library warning free instead of telling the users to switch warnings off.

Why not push/pop warnings to ignore in the library?

  _Pragma("GCC diagnostic push")
  _Pragma("GCC diagnostic ignored \"-Wshadow\"")
  int a = 1;
  {
      int a = 2;
  }
  _Pragma("GCC diagnostic pop")

This sort of thing is better set in CMake or equivalent with file specific flags to disable diagnostics. Then you don't have non-portable cruft littering the code, you don't have to touch third party code, and there is a more centralized accounting of what marginal code you're hacking around. The loss of specificity is rarely going to be a problem.

> with file specific flags

But you don't want to disable warnings throughout the file, just locally.

> Then you don't have non-portable cruft littering the code,

You can make it perfectly portable, with a little macro work. See, ,for example:

https://github.com/eyalroz/printf/blob/013db1e345cbb166a7eb7...

(this is from the standalone-no-libc-printf-family-implementation I maintain; the library is C, the test suite is C++ but it doesn't matter for the purposes of my point here.)

and that you only need to do once in your project (you can make it your own header). Even when it comes to use - you can place your warning-disabling within another macro, so that you end up only using a simple single macro for your actual code.

If you disable warnings in your makefile, you'll lose them for the entire C file. Pragma warnings as above allow them to be disabled for just the problematic code in question.

This probably isn't relevant anymore, but for now-old (4.x I think) versions of GCC, there are a couple of caveats:

* Some versions can only change compiler options at top level, not within a function.

* I had problems with trying to push/ignore/pop a warning around an expression in a macro, since the entire thing expands at a single ___location.

Can you elaborate? I'm not aware of musicbrainz having any recommendations/discovery features.

Sorry, I meant listenbrainz

Thanks, I'm checking it out right now and it looks really promising. It supports scrobbling (which apparently just means syncing your listening data) from various music players like navidrome & jellyfin.

>The 1880 queen and her daughter were drowning but no one could save them because looking at or touching the queen was forbidden by commoners. So they drowned while screaming for help.

Seems to be a myth: "There is an often repeated myth that the many witnesses to the accident did not dare to touch the queen, a capital offense—not even to save her life. However, this was not the case; the King's diary records that boatmen dived into the water, pulled the queen and her daughter from the entangling curtains, and carried them to another boat, where attendants worked in vain to resuscitate them."

Source: https://en.wikipedia.org/wiki/Sunanda_Kumariratana

packages on f-droid list all required permissions explicitly, and the mentioned permission seems to be listed as "query all packages: Allows an app to see all installed packages.". It doesn't mark the app as having "anti-features", but you can at least make a more informed decision this way.

That's pretty cool, but the article says that most apps that are doing this sort of thing aren't using the query all packages permission and instead are using the facility to provide a specific list of apps they're checking for, which is not permission-gated.

It is. It specifically says that the apps must be declared in the manifest like other permissions. So it's a specific permission for each app really. F-Droid could query that if it wants to (not sure if it does)

Did you stop reading before the post got to the MAIN loophole that doesn't require the list of apps in the manifest? How does F-droid describe MAIN?

Yeah I did as the article was a bit long. But I'm sure this is detectable too as it must be in the manifest.

The article already showed it is detectable. But it is not detected by Google and I am unclear if F-Droid detects it either...

> It doesn't mark the app as having "anti-features"

I suppose they must be too busy ticking off "anti-features" like "can communicate with non-Free services" to notice that sort of thing.

(No, really. F-Droid will tag applications like a Mastodon client as having "anti-feature: Non-Free Network Services", presumably because it can be configured to connect to servers running non-free software?)

>It stretches the definition of "two-factor"

I always considered the time aspect to be the more important "factor" of TOTP in practice. E.g., if somebody managed to peek over your shoulder or film you while typing in your password. With TOTP, they have under a minute to capitalize on that information. I still have that base covered with my password manager handling the secret key, so I never saw the appeal of tying TOTP to a phone.