SolidGrue

Man, I got stuff to do. Lol.

I mean…

Steam? Maybe? I dunno, I don’t game but the Steam kids seem to prefer Arch. I’m sure they have their reasons.

Practically? Probably nothing terribly significant.

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

I have no specific basis to say so, but I distrust browser-based password managers on the principles of separation of function and mitigating risk. Strong my credentials in a browser just feels hinky, even with a master password. Too obvious of an attack vector. Rather, I use the KeepassDX variant with its MagicKeyboard feature. When I’m presented with a login prompt, I can use the keyboard switcher to launch KeepassDX, unlock my vault, and select the credentials entry. Then I can switch back to the browser (or app) and have MagicKeyboard enter the credentials for me.

It’s a few more taps than just that, but it’s a straightforward workflow that should mitigate leakage from my usual keyboard, clipboard snooping, and any hypothetical attacks against the in-browser vault workflow.

Plus, I know where my credentials are stored, can apply 2FA, and even back up the vault file to offline archives.

It works for me. “Cool story bro,” I guess, is my point.

Plus 1 for a refurb or gently used Dell Latitude series. My daily beater for the last 5 or 6 years has been a pre-2020 Dell Latitude 7390 13". Works really well with the *bian distros I’ve run on it, decent battery life, OK mic and speakers.

I’ve had to replace the battery once, and the keyboard once (which I damaged myself by applying a small amount of Coca Cola).

Refurb ThinkPads are also great, but they have a high resale value.

“Restricted” means the app has been limited by your Android on the amount of data it may transmit/receive as a background app. The app settings assume you’re on a meterd or low-volume data plan, and so they don’t transmit data except when they’re active, or up on your screen.

Their upload/download tallies will still count in your Network accounting. Frankly, your screenshot looks like something I’d expect. Nothing untoward seems to be occurring.

Let those other restricted apps 'run in background" (an app permission) and you’ll see a different picture.

Also, I’m very tired right now. I’ll explain stuff better later when I wake up.

If you’d bought a 2TB you could just dd image the windows disk to the new drive. If you can convince Windows to downsize its partition and then use a partition editor on a USB liveboot to identify the drive sectors you could maybe still image the windows disk. Big “if.”

As to the second question, use block IDs-- the filesystem’s UUID. Grub is lazy and assumes a single root (the first found) partition so if you want a particular boot entry to use a specific root slice, you’ll need to ensure each OS entry in grub uses the right UUID for its kernel root parameter. Loading the right root gets you the rigjt /etc/fstab to mount that root’s expected partitions

Honestly you’d be better off running your stuff in VMs. Dual-boot is a nightmare.

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.

Removed by mod

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

Ah, well if you know differently then please do share with the rest of us? I think the phrasing in my post makes it pretty clear I was open to being corrected.

So, like a running sum? No, I don’t think so, not in Pi-hole at least.

Pi-hole does have an API you could scrape, though. A Prometheus stack could track it and present a dashboard that shows the summation you want. There are other stats you could pull as well. This is a quick sample of what my home assistant integration sees

That counter, I believe, for the last 24 hours. It will fluctuate up and down across your active daily periods

Unless I misunderstand your question, draw.io can be downloaded as a standalone Linux application and run locally.

Likewise, the Xfig package should he available in most Linux repos. It’s old, but good enough for a quick sketch.

edit: aha. My mistake. My eyes slid over ‘open source’ in the title*, and even still I hadn’t realized it was an Apache license.

* Whaaat, it was pre-coffee? Let the purest among us cast the first stone.

This is pretty cool!

It works in Termux on Android too, you just need to uncomment the MacOS/Darwin cachefile line

It’s possible I’m mistaken on Flatpack vs. Snap. I don’t use either of them, myself.

Functionally they’re no different. LMDE draws its packages from Debian (probably stable) repos while mainline Mint draws from Ubuntu’s. So yes, Mint will have overall newer packages than LMDE but it’s generally rare for that to affect your ability to get work done unless some new feature you were waiting for gets introduced.

Ubuntu is the Enterprise fork of Debian backed by Canonical, and as such have contributed some controversy into the ecosystem.

Ubuntu leverages Snap packages which are considered ‘bloaty’ and ‘slow’ by a plurality of people with opinions on these matters. They work. Mint incorporates the Snap store into their package management. You might just need to turn it on in the settings.

With mainline Mint you get new base OS packages with Ububtu’s release cycle, and the Snap store.

In the case of LMDE then, you can run a stable base OS on Debian’s rock-solid foundation, their release cycle, and still get your fresh software from the Snap store.

IMO, they’re the same for like 85% of use cases. I find I end up going to extra measures to disable certain Ubuntu-isms on my own systems that run it, effectively reverting it to Debian by another name.

As a student and occasional gamer, the trade off is having a stable base for your learning needs, and still be able to get the latest user desktop apps from Snap.

Linux Mint Debian Edition (LMDE) is a solid pick. All the perks and integration of Mint, without Ubuntu.

…Ubuntu which, yes, is a Debian downstream. People have their opinions on it. It works. It has its nuisances, but it works.