today we are all buttholes

I thought so too, but the article really delivered. I didn’t know I was living in The Butthole Era. I suspected it, but I didn’t know it.

Nice, I’ll check it out! I remember LMS and Squeezebox. Didn’t know it would sync between rooms, and I didn’t know it had been open sourced, that’s excellent.

At the time we started in the Sonos ecosystem we wanted easy, and it provided that. Now I’ve got multiple servers running, self-hosting services for the family, slowly working on removing our cloud service dependencies. So this would fit right in.

Yeah, I get what you’re saying. Definitely. It’s not complicated for one pair of speakers in one room. For one music source. For one person controlling it.

There just haven’t been any better cost-effective solutions with multi-room, control from your any phone convenience. And that’s a big plus for how we listen to music. Today there are a few contenders, but many of them are also cloud dependent. Really the small number of good options in this space is proof of how good Sonos was for a long time. Well and also of Spotify causing people ditch the idea of a offline digital music library.

Edit: And to be clear, aside from the “any computer networks” part, this is what the original Sonos device did. It could work without a home network, but worked best with a shared music library on a PC. Didn’t need cloud anything, internet connection, account, etc. You just hooked your normal speakers to it and it played music.

It can help to download your local map for offline use. The default basemap doesn’t have details like house numbers, but the downloaded maps should.

OsmAnd will do that. If you edit the destinations you can manually specify their order. Click sort there and choose door-to-door to get the most efficient routing.

The app takes some getting used to, but it works very well, and can act as a front-end for contributing to OpenStreetsMap.

See what’s using the space. This will list any dirs using >100MiB:

sudo du -h -d 5 -t 100M /var

Interesting. In NC here. Not sure if there’s a difference regionally. I was seeing that kind of RTT on ipv4, but ipv6 was slower. I’ll need to give it another try. The last time I did was at my last place where I had the BGW210. I have the BGW320 now and haven’t tried on that. Maybe that, or changes in their routing since then will make a difference.

Did I read right that it doesn’t use systemd?

AT&T is the same. And the last time I looked they don’t give you enough address space to host your own subnet. You get a /64 instead of a /56. And it’s slower than ipv4.

Every few months I try it out, complain and then switch it off.

Obligatory: Debian.

But I’d be tempted to put Proxmox on it and then run containers for each function. Then you get purpose-crafted solutions for each use case, but can easily plug new functions in or shut them down based on what you decide later.

So. Much.

Wasted

Space

Copy on write is the difference. As I understand it, a btrfs snapshot takes no space when it’s created (beyond the file system record). The filesystem is always writing changes to file chunks as a new copy of the chunk, which is then recorded as a replacement of the old chunk (which is still present on-disk). So a snapshot tracks all of these later changes, and the file system keeps the old file chunks preserved as long as you keep the snapshot. That’s why you can mount a btrfs snapshot. It just shows you the volume through the lens of all of these saved changes.

When you delete a snapshot you are then marking these preserved chunks as free space. So that is also quick.