I’m just this guy, you know?

  • 4 Posts
  • 87 Comments
Joined 1 year ago
cake
Cake day: June 12th, 2023

help-circle

  • Termux (on F-droid) is a userland environment that runs on top of your Android device’s kernel. It has Debian/Ubuntu-like package management system that pulls from repos maintained by the termux team. If the package is available for aarch64, its probably available in the termux repos. Its not so much of an app as it is an alternate userland that runs on top of the same kernel, but can interact with Android a couple of different ways.

    The main Termux app gets you a basic command line environment with the usual tools included in a headless Linux install. From there you can select your preferred repos, do package updates, installs, etc, just like on a desktop or laptop. You could even install a desktop environment and use RDP to access it.

    Then there are some companion apps that are useful:

    • Termux:boot is like a primitive rc.d feature that executes upon boot up any scripts found in the termux ~/.termux/boot directory. You could use the feature to launch an SSH server, or perhaps start your syncthing service when the phone starts up.
    • Termux:Tasker is a Tasker plugin that allows Tasker to launch scripts in .termux/tasker based on whatever triggers or profiles you define in Tasker. For example, stop or start selected services when connected to your home WiFi
    • Termux:API is a set of termux utilities to interact with the Android API, and do things like send messages, interact with the camera or battery, and manipulate system settings.

    So you could install the syncthing package in Termux and (after setting up Termux access for your internal storage) configure it to sync folders from your phone to wherever syncthing syncs. You’d set up a start script under Termux:boot to launch it when your phone starts, or Tasker to start/stop the service on your home WiFi.


  • 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.









  • Of course you’re right, but this time America-- significantly, the part that votes Democratic-- is pretty divided over it and that plays to Trump’s strength. By agreeing to keep the war going until next year, Bibi can accomplish at least two things simultaneously. First, it keeps the Democratic base divided between supporting the Israeli state vs doing anything substantive about the death, destruction and genocide occurring in Gaza. Any Democratic candidate that takes a stance against the war publicly will suddenly find their opponent very well funded. Meanwhile a key bloc of voters remains alienated by the party’s policy. It’s a heavy albatross hung about the necks of the Democrats. Harris has to campaign with that as a backdrop, and of course the Republicans will make hay over it.

    Second, if and once Trump back is in office then Israel will be free to roll through Gaza and perhaps even the West Bank, completely wiping out any chance of a Palestinian state. The war ends, and Trump gets to say he resolved the conflict, which means “he won.”

    So, yes. Different than 1980, but not really. All Republican dirty tricks-- and violations of the Logan Act-- to muddy up an election for fun and profit.





  • More, shelter.

    There’s no atmosphere to attenuate hard radiation, so rock overhead is the next best thing.

    There’s no gravity to contain an atmosphere, and domes are expensive and time consuming to build. Meanwhile the crews are exposed to radiation.

    There’s nothing but regolith on the surface of the moon-- finely powdered rock of unknown (and likely poor) assay for vital ores and minerals useful to bootstrap a colony.

    A cave provides shelter, more assay-ably dense ore resources, potentially water in the form of subsurface ice, and potentially a vitrable (melted, glassified rock) cavity to contain a viable, pressurized atmosphere on the quick.

    A cave on the moon is a find. Given the potential for neocolonialism in the next decade or three, it’s a boon for whatever program discovers one.

    edit: typos