There's gotta be a bit more subtlety going on here. DHCP leases include a lifetime:
$ ip address show dev br0 | grep -m 1 valid_lft
valid_lft 69133sec preferred_lft 69133sec
It's possible that older versions of macOS persisted the lease details across reboots and reused unexpired leases on subsequent network reconnections.
I am also fairly sure that I have never personally seen any evidence of any OS doing this, including macOS, including when it was still called Mac OS X. I suspect macOS simply brings up its networking stack earlier in the boot process, so the network connection is more likely to be ready and waiting by the time the desktop loads.
Using the same lease is better but still could cause IP conflict if the lease was revoked and reused (though I guess that’s much rarer)
that said I do agree with you that the behaviour was probably not as described or at least not present in current systems because it would wreak havoc on public wifi etc
I’ve never dhcp being any sort of bottleneck so I hope their just doing the regular dhcp thing
You're getting downvoted, but you're not wrong. If anyone else had come up with it, it would have been ignored completely. I don't think it's as bad as some people make it out to be, but it's not really that compelling for end users, either. As other folks in the thread have pointed out, WebP is basically the static image format that you get “for free” when you've already got a VP8 video decoder.
The funny thing is all the places where Google's own ecosystem has ignored WebP. E.g., the golang stdlib has a WebP decoder, but all of the encoders you'll find are CGo bindings to libwebp.
Just like you used to be able to provide storage drivers on a floppy disk, you can now provide NIC drivers on a USB stick. (IIRC, there's a button for it on the Microsoft account sign-in page of the OOBE.)
You're looking in the wrong place. They don't need to be listening for mail on the machine behind the A/AAAA records for the domain, because they have an MX record indicating that mail should be delivered elsewhere:
$ dig MX gmai.com +short
1 mail.h-email.net.
Port 25 is very rare these days, as it implies the possibility of unencrypted traffic; legitimate SMTP traffic uses port 587. That said, I checked a couple of the hosts that that name resolves to, and they all listen for both SMTP and secure SMTP traffic:
$ nmap -p 25,587 mail.h-email.net
Starting Nmap 7.95 ( https://nmap.org ) at 2025-12-18 16:31 UTC
Nmap scan report for mail.h-email.net (165.227.159.144)
Host is up (0.093s latency).
Other addresses for mail.h-email.net (not scanned): 91.107.214.206 165.227.156.49 167.235.143.33 5.75.171.74 5.161.194.135 178.62.199.248 5.161.98.212 162.55.164.116 49.13.4.90
rDNS record for 165.227.159.144: mail2.h-email.net
PORT STATE SERVICE
25/tcp open smtp
587/tcp open submission
As far as I've been able to research, these typesquatting domain traps started at the same time as Spamhaus CSS blacklist which was actually a company called Deteque.
If the MX has a large number of Hetzner IPs as mailservers, then it's probably Spamhaus.
Signing, notarization, and hash checking just ensures that what I run is the thing that you meant for me to run. Source availability permits me to ensure that what I run is the thing that I meant to run.
Not really: burstable (“t”) instances haven't been updated in years. The current generation (“t4g”) still use Graviton2 processors. I get the impression that they would vastly prefer cost-conscious users to use spot instances.
Ah, thank you for pointing these out! I'd missed the introduction of “flex” instance types (apparently in May last year[0] – still long overdue relative to the introduction of T4g in September 2020[1]). Curious that so far, they all appear to be Intel-based (C7i, M7i, C8i, M8i, and R8i). M7i-flex instances also cost 45% more than the corresponding T4g instances. That's sort of understandable, as the generational improvements probably bring more than 45% better performance for most workloads, but it also makes them harder to justify for the sorts of long-running,-mostly-idle duties they're being touted for.
If you're interested in the underlying technology of flex there's some reinvent talks from last year on YouTube where they acknowledge it's based on VM live migration which is I think the first public reference to AWS using migration in their products.
I suspect the burstable types were always priced too cheaply and were more about attracting the cheap market segment which they don't need now in the days of AI money.
Burstable pricing gets complex quick when adding in the option to burst to full usage. Flex seems a lot simpler which is great.
Wi-Fi is, ah, politely, not MikroTik's strong suit. They're only just completing their Wi-Fi 6 rollout (while the cAP ax was released a few years ago, the wAP ax was only released late last year, and they've only just launched the hAP ax S). And the performance of their devices is pretty poor by just about any metric. I will continue to buy it, however, because it does what it does very reliably, and history proves they will continue to support existing hardware in the field until the heat death of the universe.
This is what really kills me. I spent a lot of time in 2020 on a 4G connection throttled to 384 Kbps. Video calls? Fine (once you gave it a few seconds to notice the poor throughput and readjust its target bitrate). Most of the web? Not fine. Crazy reversal from the dial-up days when pushing even an audio call over the connection was difficult, and real-time video was a pipe dream that sunk more than one overly-enthusiastic would-be media streaming companies.
In theory, it's a wonderful idea, because it means you can run the same distro on your RPis as on the rest of your fleet (architecture differences notwithstanding), and therefore have consistent patching requirements, etc. In practice, as frustrating as it is that the RPi kernel patches haven't been upstreamed, they exist for a reason and I think by not having them, you're shooting yourself in the foot (even if you only hit a toe or two). Two things I observed recently when directly comparing stock Debian aarch64 with Raspberry Pi OS on an RPi4 was a 40%+ reduction in SD card read performance, and nonfunctional power control of the USB ports.
Fwiw I still have a “poor man's NAS” RPi4 running Debian, and it works great. (The SD card throughput deficiencies don't affect me there because the system boots from a USB-attached SSD.) If you're able to take the time to make a situation-specific assessment of what works (and what works “well enough”) vs. what doesn't, then in the long term, you can reap the benefits of not having to remember how to handle a single oddball OS in your fleet (especially given RPi OS' particularly consumer-oriented whims).
Worth noting that (so I've heard) the most impactful hardware change between the 12 mini and the 13 mini was improvements to the battery life. I've never struggled with the battery life on my 13 mini, either, but the handful of people I know with a 12 mini have always bemoaned it.
I am also fairly sure that I have never personally seen any evidence of any OS doing this, including macOS, including when it was still called Mac OS X. I suspect macOS simply brings up its networking stack earlier in the boot process, so the network connection is more likely to be ready and waiting by the time the desktop loads.
reply