I’m just this guy, you know?

  • 0 Posts
  • 10 Comments
Joined 2 years ago
cake
Cake day: June 12th, 2023

help-circle
  • For the F-droid enabled users, it seems there’s a Syncthing app in the Termux repos:

    ~ $ apt show syncthing
    Package: syncthing
    Version: 1.28.0
    Maintainer: @termux
    Installed-Size: 26.4 MB
    Homepage: https://syncthing.net/
    Download-Size: 7857 kB
    APT-Sources: https://packages.termux.dev/apt/termux-main stable/main aarch64 Packages
    Description: Decentralized file synchronization
    

  • No worries, the other poster was just wasn’t being helpful. And/or doesn’t understand statistics & databases, but I don’t care to speculate on that or to waste more of my time on them.

    The setting above maxes out at 24h in stock builds, but can be extended beyond that if you are willing to recompile the FTL database with different parameters to allow for a deeper look back window for your query log. Even at that point, a second database setting farther down that page sets the max age of all query logs to 1y, so at best you’d get a running tally of up to a year. This would probably at the expense of performance for dashboard page loads since the number is probably computed at page load. The live DB call is intended for relatively short windows vs database lifetime.

    If you want an all-time count, you’ll have to track it off box because FTL doesn’t provide an all-time metric, or deep enough data persistence. I was just offering up a methodology that could be an interesting and beneficial project for others with similar needs.

    Hey, this was fun. See you around.



  • #### MAXLOGAGE=24.0
    Up to how many hours of queries should be imported from the database and logs? Values greater than the hard-coded maximum of 24h need a locally compiled `FTL` with a changed compile-time value.
    

    I assume this is the setting you are suggesting can extend the query count period. It still will only give you the last N hours’ worth of queries, which is not what OP asked. I gather OP wants to see the cumulative total of blocked queries over all time, and I doubt the FTL database tracks the data in a usable way to arrive at that number.







  • SolidGrue@lemmy.worldtoF-Droid@lemmy.ml*Permanently Deleted*
    link
    fedilink
    English
    arrow-up
    4
    ·
    edit-2
    8 months ago

    Many apps can act as installer aps. Installing an app is basically the process of unpacking the APK file into a directory where all the other user.apps are stored and registering it with the system. The challenge, such as it is, is making sure two different installer apps aren’t trying to manage the same app package.

    So if you’ve installed an app that’s available from one of the F-Droid repos that’s also available on Play Store, both apps may try to update it. Its not a common conflict since the F-Droid versions tend to have a different signature than the Play Store versions, so the other installer tends not to try and overwrite it.

    As for how the F-Droid scene works, there are different collections of packages curated by different teams. These curated collections are called repositories, or repos as I mentioned above. Each repo tends to have a unique focus for the apps they support. They build and sign the apps so the installers know the provenance of a given package.

    As for the installer apps, they are simply clients that can subscribe to different repos and collate the indexes of applications available on each. When you search for an app, you’re really searching the index and in the event you get multiple hits, your client app should let you select which repo you want to pull the APK file from. That client app may then attempt to update that app as newer versions become available.

    Finally, to come to the point and answer your question: You can install the new app (e.g., Droid-ify) alongside F-Droid and begin configuring it. Maybe just only have auto-updates enabled in one of them. They will both provide similar functionality for supporting multiple repos, installing and auto-updating apps, though they have different UIs with different ergonomics and workflows.

    Myself, I have both F-Droid and Droid-ify installed, and I still use the Play Store. I mainly use Droid-ify because I like the cleaner UI, but I understand F-Droid finally updated their UI as well. (It was needed, IMO). Droid-ify has the auto-update job for now.

    edit: Apparently I forgot that I uninstalled F-Droid some time ago. Just checked and its not there anymore. Oops, I lied.

    Hope this helps;


  • SolidGrue@lemmy.worldtoF-Droid@lemmy.mlCountdown Calendar App?
    link
    fedilink
    English
    arrow-up
    3
    arrow-down
    1
    ·
    edit-2
    8 months ago

    It’s not FOSS but you can do this in Tasker easily enough.

    edit: I wasn’t satisfied with what I said, so here’s another approach using things available on F-Droid.

    With Termux, Termux:API, and Termux:boot, you can use termux-job-scheduler to run a script to calculate your remaining time to a target date-time (use UNIX timestamp for the calculation and strftime to format it) and then use termux-notification to publish a notification on your system bar. You’d use termux:boot to make sure the script gets (re-)scheduled after each reboot.

    Termux is just generally useful for a lot of things. I think its worth the storage to maintain it, and I use it quite a bit myself like I use Linux terminal on the daily.

    I also use Tasker quite a bit, and have your specific countdown use case implemented already. It was counting down the number of days remaining to 9am local time of a specific date, and would notify me every morning at 9am. I can share an export if you’d like.

    There’s also https://github.com/sk5s/countdateapp of you want to go the purely app-based route