The problem is that the main container can (and usually does) rely on other layers, and you may need to pull updates for those too. Updating one app can take 5-10 individual pulls.

What does “old network” and “new network” mean? What are they, LAN setup? Docker setup? Describe them better (netmasks, routing etc.)

Should probably add that a power line transmits network signal over the power plugs. OP may not be aware this is possible.

Isn’t 500€ a bit much for just the router?

There are two ways to use an .ics link:

• You can add it in Google Calendar using “add URL” and it will show up in the GC app. Downside is that you need to use the app… and also it refreshes the link when it wants (you can’t set it).
• You can use a calendar app that can import .ics links directly. The one I use is called Calengoo. This way you’ll be able to control when to refresh it, but it bypasses the normal Android calendars so it won’t be visible to other apps or widgets except the one that imported it.

I noticed what you said about not using Google services. The Calengoo app has a version you can download on their website (as opposed to Google Play) and purchase a license code with CC or PayPal, that is not tied to Google Play.

Maybe not necessarily Latex but they definitely shouldn’t keep their work as PDFs and edit PDFs. Should edit in something else and only export as PDF.

Typical problems with parity arrays are:

• They suffer from something called “write hole”. If power fails while information is being written to the array, different drives can end up with conflicting versions of the information and no way to reconcile it. The software solution is to use ZFS, but ZFS has a pretty steep learning curve and is not easy to manage. The hardware solution is to make sure power to the array never fails, by using either an UPS to the machine or connecting the drives through a PCI card with a battery, which allows them to always finish write operations even without power.
• Making up a 4 TB out of 2x2 TB is not a good idea, you’re basically doubling the failure probability of that particular “4 TB” drive.
• Parity arrays usually require drives to be all the same size. Meaning that if you want to upgrade your array you need to buy as many drives before you can take advantage of the increased space. There are parity schemes like Unraid that work around this by using only one large parity drive that computes parities across all the others regardless of their sizes; but Unraid is proprietary and requires a paid subscription.
• If a drive fails, rebuilding the array after replacing that drive requires an intensive pass through all the surviving members of the array. This can greatly increase the risk of another drive failing. A RAID5 array would be lost if that occured. That’s why people usually recommend RAID6, but RAID6 only makes sense with 5+ drives.

Unrelated to parity:

• Using a lot of small drives is very power-intensive and inefficient.
• Whenever designing arrays you have to consider what you’ll do in case of drive failure. Do you have a replacement on hand? Will you go out and buy another drive? How long will it take for it to reach you?
• What about backups?
• How much of your data is really essential and should be preserved at all costs?

You’d have to run several versions of several db engines side by side, which is not even doable easily in most distros. Not to mention some apps need special niche versions, Immich needs a version of Postgres with pg-vectors installed. Also they don’t tell you how they provision them — and usually I don’t care because that’s the whole point of using a docker stack so I don’t have to.

Last but not least there’s no reason to not run databases in docker.

I’ve replaced my “long ass script” I was using for rsync with a much shorter one that uses borg. 10/10 would recommend.

Not sure how much time it will save because in both cases the stuff that took the most time was figuring out each tool’s voodoo for including/excluding directories from backup.

It’s actually a big improvement for drives that don’t need a constant transfer rate. Fewer platters and/or higher data density. It’s helped push capacity up for 2.5" drives. I use a couple for cold backups and I appreciate the larger capacity in a small format.

Here you can check if a drive is CMR or SMR:

https://nascompares.com/answer/list-of-wd-cmr-and-smr-hard-drives-hdd/

I think you misunderstood the advice. If your goal is to open your services to the internet then any of the approaches can let in an attacker. It would depend on whether any of the things you expose to the internet has a remote exploitable vulnerability.

A long-standing software like SSH or WG that everybody relies on and everybody checks all the time will have fewer vulnerabilities than a service made by one person, that you expose over reverse proxy; but they’re not 100% foolproof either.

The Tailscale advice is about connecting your devices privately, on a private mesh network that is never exposed to the internet.

If you’re behind CGNAT and use a VPS to open up to the internet then any method you use to tunnel traffic from the VPS into your LAN will have the same risk because it’s the service inside that’s the most vulnerable not the tunnel itself.

There’s one additional problem with Picard and bands with a long history that have released the same song on multiple albums and compilations, it won’t make much of an effort to group them in as few albums as possible. You will end up with songs spread across many distinct albums. Sometimes it’s not even an album of the original artist but multi-artist compilations like “The sound of the 90s” and so on.

I wouldn’t call it normal. It’s the norm because the market is flooded with crappy drives using JMicron chips. Buy something with a Realtek or Asmedia chip and it will work fine without getting hot.

Why not keep the working files local, use a sync tool to get copies to the server, and backup/snapshot on the server as needed?

The Jellyfin streaming has been designed with HTTP so I don’t think it will benefit from a TCP proxy. Plus as you’ve noticed with TCP you lose the ability to route by domain name.

If you’re storing them for yourself I would recommend doing an online AB test to figure out at what bitrate you are capable of hearing a difference (assuming decent headphones or speakers). For some people anything above 256kbps is wasted (or even 128). If you find yourself in that category you can just use lossy formats and stop worrying about FLAC.

I wish there was some kind of place where we could croudsource impressions and fixes for new versions of docker images.

Manjaro does something like this for their releases. They also have a survey that indicates how well things went (although it’s participant biased to some degree since folks who had a problem tend to vote more than people who didn’t).

It would be amazing to be able to pop in and see that jellyfin had a couple of new releases, that one of them does much better than the others in terms of overall quality, and what kind of issues there are (and how to fix them).

I turn Tailscale on at their computers and ask them to turn on VNC when I need to assist them on the desktop. Or you can use anything else, there’s plenty of remote desktop apps once you waive the security requirement (because it’s private anyway due to Tailscale).

Don’t use them as the only storage maybe. There’s stories about Hetzner flagging accounts for false positives and they basically offer zero recourse. They close everything related to the account and cut all communication.