There’s places that still use Styrofoam for food? I haven’t seen it in a long time.

Stuff that’s out of copyright isn’t an issue though.

The reason AI companies are destroying books is because current US copyright caselaw (most recently the Anthropic lawsuit) doesn’t allow books to be copied, but considers it fair use if you transform the format of a legally purchased book (like from print to digital) without creating a new copy. By destroying the original book, they haven’t made a copy of it, and so they operate within US law.

This doesn’t apply to public domain books (books that are no longer copyrighted) as you can do whatever you want with public domain content.

“You’re absolutely right!”

My wife upgraded from a Samsung S21 Ultra to an S25 Ultra but uses it mostly same way.

The one new feature I have seen her use is the AI person/object removal in the gallery. Samsung’s AI tools can run entirely on-device, which is nice (avoids sending the photos to the cloud and using an AI data center for the processing). I tried them while in airplane mode to confirm they do indeed work with no internet connection.

She upgraded because the old one had a pretty scratched screen (we installed a screen protector on the new one!) and the battery wasn’t lasting long any more. The official repair store that Samsung use in the US, UBreakIFix, don’t stock S21 batteries any more, and I didn’t trust myself enough to replace it myself.

I really hope some phones are released with support for MicroSD Express.

One of the practical reasons companies started removing MicroSD slots is because SD cards were far slower than the internal storage, and installing apps onto them could make everything laggier. That’s mostly solved with MicroSD Express which is up to 9x faster than the legacy MicroSD standard.

Of course, there’s also the financial aspect, which the manufacturers love. If you can’t insert an SD card, you have to pay the manufacturer for more storage.

Here’s hoping the EU mandates that phones need to support removable storage.

The title of the page I linked to is “Websites using Cloudflare in the Top 100k Sites by Traffic” so I think my interpretation was correct.

Also, one domain can use multiple CDNs (eg one subdomain uses Cloudflare while another uses Bunny) so I’m not sure how their percentages work.

I’m also not sure how they count sites that use Cloudflare but not the CDN product (for example, if they disable caching and only use the WAF). That looks identical from a client side so there’s probably no way to tell.

Maybe I shouldn’t trust their data.

AWS(just 8% seems sus),

The chart wouldn’t be showing all of AWS, just Cloudfront (their CDN). There’s plenty of services that use AWS EC2 or Lightsail but front it with Cloudflare.

If you’re considering hosting Github Enterprise on-prem then it might be worth considering Forgejo too. It’s the system that powers Codeberg.

Codeberg doesn’t allow proprietary code, only open-source. You’d have to self-host Forgejo if you want to use it for private projects.

Something like 40% of the top 100k sites use Cloudflare. Builtwith says 44%: https://trends.builtwith.com/websitelist/Cloudflare/High-Traffic-Volume

The pricing on their paid plans is very competitive. For small to medium sites, it’s orders of magnitude cheaper than Akamai. The WAF and DDoS protection is pretty good too.

The largest sites like Google, Facebook, Netflix, etc have their own CDNs, including servers they provide to large ISPs for free since it significantly reduces upstream bandwidth usage (Netflix call this Open Connect; Meta’s is Facebook/Meta Network Appliance). Outside of the largest sites, you’d be surprised how many companies rely on Cloudflare. It’s kinda scary.

I usually use Clonezilla and have it verify the data after cloning. It works for local drives, but it can also clone a drive over the network by running it on both the source and destination system, which is very useful for remote servers (eg moving a VPS to a different location).

I usually use rsync -avHXS --numeric-ids --progress --delete

uBO can block things that DNS-based blocking can’t block. Some sites serve their ads from the same domain as the rest of their content, and some sites need custom JavaScript to block the ads.

I think that’d make sense. The trackers for public torrents are often at seemingly random domain names and nobody really pays much attention to who runs them.

The US military created Tor, so I don’t doubt the US government still runs a lot of the nodes.

I doubt it. It’s likely custom code that’s better suited to the task.

The *arrs watch RSS feeds to find new torrents. It wouldn’t be difficult to write a script that pulls the RSS feed and polls the tracker to collect data on the initial seeds/peers. They might use an actual torrent client for some of the data collection, since I’d guess they have to prove the person is actually uploading, rather than just being connected but not actually uploading or downloading.

Your comment isn’t entirely accurate.

in an overwhelming amount of cases, that host networking will be a “here’s a device-local subnet your containers can join to”, so no, a Docker container won’t by default “get it’s own IP address”

With the default NAT network, it gets its own IP in the 172.16.x.x range that Docker decides to use. That IP is accessible from the Docker host. It doesn’t matter that it’s not on your LAN - it’s still a dedicated IP. Port forwarding (or a reverse proxy) to it is a separate thing, and you can map a different port if you want to.

Plenty of Docker containers use the same port (often 80, 3000 or 8000), and the reason you can use multiple of those containers concurrently is because each one is on a separate IP.

The default NAT network isn’t commonly used for Home Assistant, though. It usually has a direct network connection to the LAN, since plenty of smart home devices rely on broadcasts for discovery.

Also claiming that “nothing else will use port 80” is a gross over-simplification.

It’s true for both the Home Assistant Docker container and for HAOS. In both cases, there’s no other web servers running in the container/VM. For the Docker container:

• If you’re using the default Docker NAT network, the port you use to expose it to other devices is completely unrelated to the port used in the container. When you expose a Docker port, you specify the host port and container port separately.

  • Sometimes the port isn’t exposed to the LAN at all, for example if you’re using a reverse proxy. In that case, you usually use the docker container name as the upstream in your Nginx config or whatever, like proxy_pass http://hass/

• If you bridge the Docker container to the LAN, it has its own IP on the LAN and no other web servers will be running on that IP.

The actual reason that Docker containers don’t use port 80 by default is so they’re able to run in rootless mode without any extra capability grants. I don’t think Home Assistant supports rootless mode though.

There’s two supported ways to run Home Assistant:

1. Home Assistant OS
2. Docker container

In both cases, it’s running on its own IP address, so nothing else will be using port 80.

With Docker, you’d normally either use its standard NAT network, or bridge it to your LAN using a macvlan or ipvlan network. Bridging is usually better because some devices rely on broadcasts.

You used to be able to run Home Assistant directly on an existing Linux system, but that’s been deprecated for over a year and unsupported since December last year.

I use healthchecks + runitor for notifications. Would recommend. I posted another comment about them.

OK, TIL you can just do <foo.txt. I didn’t think that worked. Thanks!

I’d recommend self-hosting healthchecks and using runitor for your cronjobs. Runitor pings healthchecks when the cronjob starts, then pings it again on completion with the status (success or fail) along with the stdout and stderr.

Healthchecks can be configured to expect a ping periodically (once per day, once per hour, whatever) and alert you if it doesn’t receive one.

For backups, Borgmatic has a healthchecks integration.

RFC3339 is better than ISO8601 since it doesn’t allow some of the esoteric formats, and allows some useful formats that ISO8601 doesn’t (like separating date and time by a space instead of by T)

For example, 2026-W32-1 is also a valid ISO8601 date: Monday on the 32nd week of 2026. That format isn’t allowed with RFC3339.

https://ijmacd.github.io/rfc3339-iso8601/

RFC3339 is better than ISO8601 since it doesn’t allow some of the esoteric formats, and allows some useful formats that ISO8601 doesn’t (like separating date and time by a space instead of by T)

For example, 2026-W32-1 is also a valid ISO8601 date: Monday on the 32nd week of 2026. That format isn’t allowed with RFC3339.

https://ijmacd.github.io/rfc3339-iso8601/