tychosmoose @ tychosmoose @lemm.ee

Posts

1

Comments

97

Joined

2 yr. ago

The port is forwarded from your router to the pi, right? If so, you could test for the router as the bottleneck using the router's WAN side IP address as the target.

This should give you a good data point for comparison. If it's also slow then you can focus on the router performance. Some are slow when doing hairpin NAT.

Definitely!

It's significantly immediate-er with induction - particularly going from cool to hot. Boil water in 2 minutes and handles don't get hot in the process. And since nothing is heating except the metal of the base of the pan there is no residual heat from the cooktop parts or the sides of the pan when you turn it off. The temperature drops much faster.

I went back to gas after 5 years cooking on induction and miss it a lot. Cooking something like pasta that requires boiling a sizeable quantity of water takes 2x or 3x longer on gas, even with a very powerful burner.

Does this media server need to be accessible when you are away from home? Will you store personal data on it?

Out of band management: this is a server feature that lets you access and manage the server even if the OS is down. That's important if you may be away from home and need to fix a boot problem.

You can simulate some of this with PiKVM (remote console access) and PDU solutions (remote power control).

Redundant power: servers often have redundant power supplies, so that if one fails it can still function.

You can simulate this, with short downtime, by having a replacement ready. Mini PCs make this easy by using relatively inexpensive laptop style external power bricks. But also think about the power circuit - is the server on the same breaker/fuse with something that could potentially take the circuit down while you are away?

ECC RAM: this is about data integrity. If there is a failure in non-ECC then a bit flip could cause data corruption.

You can't really get this without ECC. Using a file system that has anti-corruption features can help reduce some of the risk. You probably trust your data to consumer PC hardware, so this would be no different really. It's about risk mitigation.

And that's the main thing here, deciding on the use cases and prioritizing/budgeting how you mitigate risks to each.

I'd say your chances are very good. Even their high end rackmount models work with the usbhid-ups driver. Don't think they would change things up in this regard since they would also need to change their software.

Apron is a fun one. The Latin word for cloth, banner, tablecloth is mappa. It's the same word used in "mappa mundi" meaning map of the world (we contract that to just map now). French often changed Latin m to n, so mappa became nappe, then nape.

English borrowed nape directly for cloth and added it's native diminutive suffix -kin to refer to a small cloth, a napkin.

But there was also a similar diminutive in French - naperon. A cloth to keep your front clean. English borrowed that too, as napron. Then, sometime around the 15th century, "a napron" got mistaken for "an apron" since they sound identical. And that's what we have today. (Source etymonline and others)

It's probably still IPv6 related. If you use something like Network Analyzer on your phone while only connected to the mobile network you may find that it only shows an IPv6 address and DNS server, no IPv4 config. That could explain the difference. Particularly if you were using the maximum typically permissible MTU. Your provider might also be doing some 6to4 tunneling somewhere that adds overhead and causes size problems.

You might want to do a DNS leak test from your phone with the wireguard connection down and then with it up to make sure you're tunneling DNS. This will be clearer if you set pihole to use something upstream that an ISP is unlikely to use - quad9 for example.

Stated reasons are safety and security. They are officially still in a health quarantine, but the leadership has expressed that the security situation has been better with no migrants, and so it continues. The opposition and neighbor states disagree.

A spicy near-land entry by air is sure to lead to an even spicier exit procedure when the visa is checked!

You could, except that Azerbaijan has kept their land borders closed for entry since covid. You can depart on land, and you can arrive or depart by air, but you cannot arrive by land.

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.

It's not bad to get running, and the alerting is really flexible. You can add Nagios and syslog alerts easily too.

Using it here. Love the flexibility and features.

I'm running NUT on the host os - no container. If that's an option for you it will probably be much more reliable.

How will the worm in my brain survive without these nutritious bacteria‽

Huh. Losing USB access?