Btw: does anybody know what bad things actually happen if there is no metal cage that blocks all the radio?

Noise happens. Could be no problem, or it could hurt your wifi or mobile data connections, or maybe raise a neighbor’s ham radio noise floor. I saw this recently when setting up a pi to run BirdNet-Pi. The USB3 connection to an SSD caused enough noise in the 2.4GHz band that the onboard wifi radio could only connect on the 5GHz band.

To start - moving services from bare metal to rootless Podman containers running via quadlets. It’s something I have had in mind for a while but keep second guessing the distro choice. Long-ish release cadence, systemd-networkd and a recent Podman version in the native repos, well supported, and not Ubuntu.

So far openSUSE Leap seems like the winner. A testing machine is up to install everything, write some deployment scripts, and decide on a storage layout and partitioning scheme.

If anyone has another distro to recommend that checks these boxes let me know!

I like rolling release for the desktop, but only want critical patches in any given month for this server, and a major upgrade no more than every 3-4 years. Or an immutable server distro. But it doesn’t seem like networkd is an option for the ones I’ve looked at (Fedora CoreOS, openSUSE MicroOS), and I am not sure if I want to figure out Ignition/Combustion right now.

Next project - VLANs on Mikrotik.

OP - Navepoint makes good racks for reasonable money. I have a Pro series 9u from them and it went together without any problems. It’s on the wall with a pretty big ups in it.

My understanding of why is that it relates to their change to a scene-referred workflow. Up to v3, darktable used a display-referred workflow like other programs. In that model the image you start with is mapped on a tone curve from the start where 0 is pure black and 1 is pure white, and the midpoint is set to midway between. This is all from the standpoint of what your display can render. The scene-referred workflow in v4 doesn’t do that. All the tones are mapped in an unbounded and uncurved way. So images look flat, but you’ve retained maximum data, so you have more to work with. The developers assume that you want control and maximum fidelity. There’s a better explanation in the intro of the documentation. This impacts everything - especially the color balance.

One of the problems is that all of the display-referred tools remain as modules in the interface, and some are even used in the base processing, but you’re not supposed to use them. At least if you want to do things the ‘right’ way. We created a custom panel that has 90% of what we regularly use (shared UI with my partner). That plus creating some presets that work well with our cameras has made it very quick to get a satisfying output in a minute or less.

Honestly, if you want to do minor tweaks to a RAW and mostly want what the out of camera JPEG looks like, there are much easier tools. If you at least occasionally deal with really challenging photos, or you want to get creative in the processing of some of your RAW images, darktable opens up a lot of possibilities, while being free and open source. So I think it’s worth the effort to learn. Shooting with a colorchecker helped us get the presets we wanted for a variety of shooting conditions.

Same here. DigiKam and darktable.

Getting color balance with raw in darktable took quite a while for us. It was helped by using a Color Checker Passport in a few shooting conditions to use for reference and calibration. Once we got past that darktable has been great.

If you want to keep using networkd, you might want to consider if multiple interfaces are causing the wait. NM doesn’t care, but networkd gives more granular options for dependencies. If you have wired and wireless and only one in use the systemd-networkd-wait-online.service waits for a timeout period. You can find lots of info on it related to boot delays with that service.

Try the --any switch on the systemd-networkd-wait-online.service launch configuration. This will tell the wait-online service that any single routable interface is enough, you don’t need them all.

Run:

sudo systemctl edit systemd-networkd-wait-online.service

That adds the override.conf for the service. Add these lines:

[Service]
ExecStart=
ExecStart=/usr/lib/systemd/systemd-networkd-wait-online --any

The other possibility is if you have virtual .netdev devices configured (VPN, bridging, etc) and some of them are not essential for the machine to be online, you can set RequiredForOnline=no on the ones that aren’t essential.