considering that I run with noscript on permanently, if the site immediately breaks, I just close the tab. if the site generally works, I will take the time to consider if JS is warranted. thank you for making sites that dont break the web.

understood. I can upload something generic in place of, but that kinda modifies the author’s presentation. :-(

other than that, I don’t have a good solution to the ai graphic slop - even for mildly interesting pass-time content.

edit: interestingly, jerboa never shows youtube thumbnails and my workflow through newpipe doesn’t either - so I have zero idea what these thumbnails look like.

are they color coding torx bit sizes now?

honestly, I have always had pretty decent experiences with non-oem lead-acid batteries. my local battery place has a decent supply and longevity is roughly the same as the oem ones (3-4 years). I have never had any issues (type or frequency) that were not also an issue with oem batteries.

almost no UPS mfcr makes their own batteries, so if you strip off the labeling from the oem ones, you may even find an exact replacement.

edit: another advantage of a local place is the core-return rebate and disposal of your old batteries.

the attack should only have insight into the abstracted storage provided by the browser, so your idea of a virtual device that spits out random timing results is probably reasonable.

the issue is that timing being random, in and of itself, is a potential fingerprint when combined with other data from your browser - unless everyone is doing it as well.

all I can say is I give thanks for noscript every single day.

the latest colonization of prior human effort. I am not absolutely against LLMs and a push towards actual AI, but all financial proceeds from this effort must be shared equally and globally.

however, human nature being what it is, we will almost certainly empower the very worst outcome - because… of course!

edit: word

not a professional programmer, by any means - but PR’s (for me) slow development down to a point where code matches the philosophical/algorithmical goal. when code development is at the proper pace, it dramatically reduces the need for refactoring.

edit: upvoing this post, because the comments are particularly interesting - as with any “good” post :-)

rare good news!

agreed. you are using DNS-01 challenges. so the workflow is…

your local certbot machine initiates an https connection to the letsencrypt servers to start the DNS-01 challenge. during this HTTPS dialog, your local certbot is informed of the key material to insert into your DNS records. your local certbot then modifies your netcup DNS server (hosted remotely, not on your local network) with the keying material and the letsencrypt servers verify that the keys are actually there, proving that you control the domain. the letsencrypt serves then issue you the certificate (again, via HTTPS) and your local certbot stores it in your local host.

the issue is most likely stems from the initial HTTPS connection that certbot tries to make to the let’s encrypt servers. while your firewall allows this traffic out, it does not allow return traffic back in because of your explicit blocking of US (and perhaps other) based addresses.

even through your are using DNS for your domain autentocation, your local host - the machine running certbot - is unable to initiate the certificate transfer because of the firewall blocking return traffic.

the two external networks (and, therefore IP ranges/subnets/etc) that are important here are the let’s encrypt servers and the netcup DNS servers. certbot will have to talk to both of these in order to function.

not sure what you mean by external DNS

not hosting your own DNS server. specifically it sounds like your DNS server is hosted on your domain provider, not your own local network. you have set up certbot to automatically configure your remotely hosted DNS server for the DNS based renewal.

if DNS based recert was working before then it should be working now.

as I said in my edit, you are likely blocking the return https traffic from the US based let’s encrypt acme servers - so your initial diagnostic is correct. your local firewall is likely stopping the acme servers from talking back to your local host.

you are right back where you started, asking for info in how to allow-list the acme IP ranges. but at least we may now know why it is not working and you are seeing an https timeout even though you are using DNS based certificate renewals.

edit: typos

The DNS server/root isn’t in my home network

are you using external DNS hosting? is it in a (now) blocked country? if so, then your local certbot is unable to update the DNS server records (return traffic from your DNS host is being blocked by your iptables/nftables config).

error: HTTPSConnectionPool(host=‘acme-v02.api.letsencrypt.org’, port=443): Read timed out. (read timeout=45)

yeah, that would suggest an https renewal method. had you previously configured web server renewal at all before switching over to DNS? any other suspicious notifications in the logs?

edit: in thinking about this a little more… the renewal has to be initiated by your host, and that is likely done via https (you talk https to the acme server and tell it you want a renewal by DNS). so, if you are blocking the acme servers then the same issue applies - no return traffic.

unless something has changed drastically, I pretty sure LMDE is based on official Debian repos, not Ubuntu. LM adds their flavor on top.

die hard Debian user here here, but if LMDE fits the bill, I agree - go for it. its a great distribution.

but isn’t that just using tooling to de-obfuscate code that should be clear to begin with?

passing structs, dicts, whatever keeps the code clear, expressive and extensible. if I can bake-in flexibility and clarity without being overly focused on performance, I am choosing the former every time.

my understanding is that those (if strong enough to be detectable) would have arrived around the same time as the photons.

nothing? everything? we find the question to the answer for life, the universe and everything?

I do, however, know that the resulting cleanup (philosophical, psychological, physical, etc) will be epic!

as @CameronDev@programming.dev points out, the absurdity inherent in the art is quintessentially and wonderfully human.

V1 (current, open-source): Ship it. An LLM looks at HTML and draws what it thinks a browser would show. Technically a browser. Legally, probably also a browser. Morally, questionable.

V2: (oversubscribed $200m pre-seed, enterprise) The LLM writes a brand new browser engine from scratch every time you load a page. No bloat – the engine only supports exactly the features that page needs. Extremely efficient.

hilariously perfect.

old article, but…

The dbus-broker process, on seeing these failures, decided to just throw up its virtual hands and let the system collapse into a smoldering heap.

is pure poetry.

this was actually worth the time of you want something retro-cool playing in the background.

connecting you to hundreds of millennia of your fellow men. satisfyingly primal :-)

a long (and evolving) read but its seriously good. thanks for posting this.