I've just realised my bridge is set up weird

jails and vms get an interface of their own which is then addm'd to the bridge

but the whole br0_N setup in my `rc.conf` is doing a different thing for my "local" interface

I wonder if that's been causing issues

rtprio, you want mine from 14.4-RELEASE-p4?

anyone using vultr with freebsd? have you ever had it decide to not boot freebsd (inc the ISOs), but will boot linux ISOs? It's loading the boot menu, then loads the kernel, then reboots.

tried 14.0 and 15.1 mini ISOs

I'm curious if someone has a notion of how to understand what's using so much space... I thought it might be all the firmware files, but it's not that. Full list: bpa.st/SCOA just the firmware: bpa.st/HKHQ

Hm, hm, Firefox and its dependencies are good for 2G of it by itself, but that leaves 3G, which seems like quite a lot.

Oooh. xscreensaver by itself is almost a gigabyte.

We have an unexpected winner: tint2! bpa.st/MLOA

Hm, a bunch of things have roughly that baseline.

CrtxReavr: i'll check it out from src

hi all

entrop, I am.

for freebsd servers/homelabs do you usually disable the weekly locate.updatedb job?

mvanbaak: nice!!! do bare in mind security of EOL devices though. But thats more than enough to run a small company on lol

I feel like the industry has kinda went mad. Startups needing racks and racks of servers...

I know of million dollar companies whos entire infra can fit on a single server rack (and an extra for backups and redundancy)

You would have thought companies would want more efficient code to drive down their overheads, which can either 1. increase profit margin or 2. decrease cost of consumer thus increase overall profits, raising the profits a shareholder gets

2. tends to be more profitable

I dont get why the industry burns money for no reason

Because it can

venture capital + capitalism.

entrop: contact their support (they are fast and IME, fairly well-versed in FreeBSD) - there was a big linux/KVM bug that required updates and reboots on their end. I had a few older instances enter a boot loop.

technically it's qemu crashing, that's why you just see a few lines of the kernel loading and... boom.

they'll go in and make a change in the backend that works properly for FreeBSD 14/15/16(?)

I generally dread dealing with support, but I'd burned *hours* figuring out why a wireguard tunnel was far too slow and they dug up a kvm bug with tx/rx offloading on the vtnet device and had that answer for me in like a half hour.

polarian: in reply of the security for eol devices. sure, this might be a thing. but I'm a lone dutch guy running a couple of things fro me and my wife. On top of that, I'm less worried with 'china will look at you' then 'murrica will look at you'

so they will know I'm running radarr. big deal