I’m just this guy, you know?
Hi!
I’m OK, mostly.
Had some good Chinese takeaway tonight, which was a treat. Ate that while watching my countrymen descend into some kind of froth for dystopic, authoritarian autocracy. That’s kind of a bummer.
I abide. Trying to, anyway
For now.
I mean, we’re communicating over the Internet right now, which is pretty cool. Right?
On Lemmy. For now. Things will change. But for now it’s pretty cool. Um.
Hi. :waves:
WTF kind of question is this?
Is it a thing? OK, yeah? A concept of an idea, maybe.
Is it anything approaching moral, ethical or humane? No.
Nooo.
Nope.
Nuh-uh.
Thanks for coming to my TED talk.
There’s Gradle to crave joke to make here, but deploy keeps failing during dependency checks for humor.
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.
Not only does it need blocking on the wheels, but that thing’s also apt to be stolen with the hitch just sitting there like that. They might consider parking a car in front of it too.
Black eyed peas. I’m not gonna tellya twice.
Lol, thanks! I knew what I meant, so clearly everyone must know what I meant! :face palm:
The OPM hack a few years ago says they already can’t.
On the matter of information security, but also security in general:
Pick two.
Sometimes I add mashed potato to it and then I deep fry scoops of it to put on my ice cream. Its like a Thai version of latkes.
I also mix it with whiskey, variously bourbon or maple whiskey, maybe white dog, and use it for eye drops.
Or you can put it in a food dehydrator to dry it out and make a powder of it so you can snort it.
Ah, that makes sense. Fair enough, I guess Incan disable that plugin now.
Yeah, sorry… My head was in 1000 different places when I wrote that. Sloppy of me.
Overall I agree with the general statement that less code is better, except perhaps in this case it is not.
What I had been trying to say is in-browser privacy implementations are liable to be incomplete from the perspective of privacy minded users because the software publishers, say, Mozilla, are competing for market share of installed, default browsers. One way they maintain market share is by having the fastest and most accurate page renders for the widest base of use cases. To do this requires, in part, some cooperation from website developers whose vested interest in part is in driving ad serves.
Therefore, it’s in the browser publishers’ interest to implement enough privacy and blocking features to effectively stop malware and common nuisances, but not completely cripple ad blocking since ads are a key part of web site operators’ revenue. They’re trying not to alienate that part of the web economy such that their browser suddenly starts hitting those “please turn off you ad blocker or select another browser” paywalls.
Mozilla pretty much said this was the case a few years ago when they opted not to turn on the privacy features by default in new installs because the advertisers threatened to start hobbling websites for Mozilla browsers. I don’t know that the situation has really changed much since then.
Anyway, my point was that the in-browser privacy features are a good start and should be enabled, but also that they amount to little more than a fig leaf over the question of effectively blocking ads. Loading the adblockjng extensions accomplishes a few things for the user. First, the extensions grant a more complete, uncompromised blocking experience for the user. Second, it grants the user finer-grained control over the whole web experience, letting the user decide what ads and cross-site data sharing occurs. Finally, the code is independent of the browser and so it doesn’t alienate the site owners from the browser publisher.
For Mozilla, it shifts the responsibility of incomplete page loads and breakage onto the user, which in my opinion is where we want it.
That’s why I’m advocating for doing both in this case: because the browser publishers have a vested interest to remain relevant in an economy that wants you to see the ads, and will do everything it can to make you click them. The best defense against for the user that is a multilayered approach.
Finally, I do want to acknowledge that I’m using the terms “privacy” and “ad blocking” too loosely here since they are separate, distinctly nuanced topics. The extensions help more in the ad blocking space than the privacy space, but in what I wrote I think its fair to say that overall the extensions do improve outcomes where the two spaces intersect.
Anyway, nice chat. Thanks for keeping me honest
I like you. Never change.