I try not to context-switch between shows. However much of a show drops at a time is how much I watch before switching to a different show. Then I can just use the relevant platform’s “new episodes” alert to know when there’s something to slot into my viewing time.
Yeah, just have to be up front about it so people know what to expect.
That probably varies based on local culture. But I’ve never lived anywhere that it’s not the norm that unless otherwise stated in the invitation, the host is paying for the party.
The sun set earlier,
It didn’t. You just go up earlier and pretended.
We did year round DST in the 70s and it resulted in kids being hit by cars on the way to school in the winter.
Heart attacks and strokes are more frequent after DST starts
No they enacted permanent DST in the 70s. OP is asking for arguments against ending DST. The backlash against permanent DST in the 70s was because kids going to school in the early morning darkness were being hit y cars.
We already tried year-round DST in the 70s. It didn’t last through the first year because kids were getting hit by cars on the way to school in the early morning darkness.
I mean you’re not wrong.
It seems to have stabilized itself over the last 24 hours. I haven’t touched the configuration on either side. Weirdy McWeirdsalot.
It seems to have stabilized itself over the last 24 hours. I haven’t touched the configuration on either side. Weirdy McWeirdsalot.
Well, I haven’t actually touched the configuration on either the Firewalla or resolved yet, and it seems to have magically stabilized itself. Been resolving correctly for all day. Really appreciate you trying to help me out, regardless.
$ hostname -f
firefly
$ cat /etc/resolv.conf | grep -v -e '^#'
nameserver 127.0.0.53
options edns0 trust-ad
search lan
$ cat /etc/nsswitch.conf | grep -v -e '^#'
passwd: files systemd
shadow: files systemd
group: files [SUCCESS=merge] systemd
hosts: files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns
services: files
netgroup: files
automount: files
aliases: files
ethers: files
gshadow: files systemd
networks: files dns
protocols: files
publickey: files
rpc: files
I do actually have far more services deployed on the .50 IP than I do other servers with an explicit DNS rule defined. I have a TLS cert deployed with a wildcard SAN for *.home.example.com on that one server, and use reverse proxy to send the traffic to the right service based on hostname. The other couple of rules are just when I need to override that for a service on a different server (like running something on my Pi).
It would make sense that there’s a CNAME buried in there on the router, but the dig results going direct to the router don’t include that record. I’ll poke around to see if I can find where there’s a CNAME, though, and keep harping on it to Firewalla support.
I can promise you this is not a resolved issue. If it was, you’d be seeing posts like this everywhere. It’s behaving as it should.
I get what you’re saying, and it’s all logical and rational. But when consistently every one of several dozen other clients/devices on the network that aren’t using resolved are working, and only resolved is not, it’s kind of pointless to say everyone else is doing it wrong. Being technically correct doesn’t matter much at that point.
Resolution is just fixing your DNS to work properly.
What do you suggest I do for that? What records? I do have more manual control of it via the shell than what the UI offers, and it’s running dnsmasq under the covers. Note, I do also have a support ticket open with Firewalla, they’re pointing the finger at resolved.
From the docs you linked it specifically says it only works for A or AAAA records. Don’t know how your other machines are somehow working as you thought they would.
I assume it’s because of this, from the documentation
By default, if you enter a top-level domain (TLD), subdomains will be included automatically. If needed, configure separate Custom DNS Rules for subdomains to point at different IPs.
If I run lookups on subdomains which I have not explicitly defined a rule for, they work in systemd-resolved. It’s just the ones that I have explicitly defined a rule where systemd-resolved just keeps going to that CNAME result. I can resolvectl flush-caches and get the correct result briefly, but within like 15 minutes it goes back to the CNAME instead of the A record.
$ dig @192.168.68.1 bob.home.example.com foo.home.example.com
; <<>> DiG 9.18.44 <<>> @192.168.68.1 bob.home.example.com foo.home.example.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44860
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;bob.home.example.com. IN A
;; ANSWER SECTION:
bob.home.example.com. 0 IN A 192.168.68.50
;; Query time: 5 msec
;; SERVER: 192.168.68.1#53(192.168.68.1) (UDP)
;; WHEN: Thu Feb 19 15:12:17 CST 2026
;; MSG SIZE rcvd: 63
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15296
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;foo.home.example.com. IN A
;; ANSWER SECTION:
foo.home.example.com. 0 IN A 192.168.68.50
;; Query time: 5 msec
;; SERVER: 192.168.68.1#53(192.168.68.1) (UDP)
;; WHEN: Thu Feb 19 15:12:17 CST 2026
;; MSG SIZE rcvd: 63
There was a brief push for people to leave BlueSky right after a few people were banned right after the Charlie Kirk murder, but my observation is many people who flirted with Mastodon (look for the #fuckaas tag and accounts on the fuckaas.space instance) in that time stuck with BlueSky in the long run.
depends on the person.
could just be plain old ear muffs, for noise reduction.