FWIW restic repository format already has two independent implementations. Restic (in Go) and Rustic (Rust), so the chances of both going unmaintained is hopefully pretty low.

I’m curious. How would you identify who’s guest and who’s not in this case?

With multiple networks it’s pretty easy as they are on a different network.

In Tailscale you can set up an exit node which lets you access the entire internet via its internet connection.

You could set up an exit node that would let you access the internet via some (anonymizing) VPN providers like Mullvad or any other.

This sounds like Tailscale is simply setting up this exit node for Mullvad on their side and providing it as a service. So it’s not like using another VPN anonymizers is impossible, it’s just convenient to use Mullvad.

RAID is not backup. RAID is used for increased capacity, throughput or uptime. (Depending on configuration)

Multiple volumes would likely get corrupted just as much with faulty RAM as RAID would. Besides RAM there’s controller, CPU, power supply and possibly more single points of failure in that NAS, that would destroy both RAID and multiple volumes.

So assuming you have external backup, I’d go with RAID for better uptime as opposed to some custom multi volume pseudo-RAID for the same.

If it’s really early 2000s, you might want to put it on eBay. There are retro gamers out there that could use it as good Windows 9x era gaming PC. You could give that HW a new life in someone’s retro setup.

It’s great HW for occasional gaming, but it’s very inefficient for 24/7 operation. You want to be somewhere after 2015-ish for something that is supposed to run constantly.

Moving off from port 22 is effectively just security by obscurity. It will save you some logs but the bandwidth and CPU time saving is negligible - especially with fail2ban.

Cries in TBW endurance, but also yes please!

Oh wow, thanks. I’ve read about bcachefs long time ago. I didn’t realize it go that far since. That’s definitely something I’m very curious to try.

The author is upset that btrfs RAID arrays don’t function as he anticipated. However, btrfs isn’t ZFS or mdadm; it’s its own system and should be understood as such.

I’d say it’s quite reasonable critique, because RAID1 is kind of industry standard. I can’t think of any other RAID (HW or SW) that would do RAID1 in this way. If btrfs decided to call their implementation raid1 while it really isn’t raid1 in some major way, it was very bad idea. I don’t agree it’s documentation issue, it’s really bad name choice. ZFS has raidz that does something similar to btrfs raid1 and the name does not lead to confusion. RAID1 system should never lead to decreased reliability with increasing number of drives.

The author points out that btrfs won’t auto-mount an array if a drive fails, while ZFS will. This is actually a protective measure. By not auto-mounting, it minimizes the risk of further drive failures, prioritizing data preservation.

RAID is uptime preserving mechanism. If anyone uses RAID for data preservation purposes, they are setting themselves for a nasty surprise. RAID system that does not mount in reduced redundancy situation is very bad design. It effectively sacrifices usability of RAID to serve other purpose that RAID system does not really need nor should be used for.

He attempts ZFS recovery methods on btrfs and is surprised when they don’t work.

I felt that way as well, but I think they raised one important point - there was no indication that the array was still in reduced redundancy state after their “attempt at recovery”. ZFS is very clear about the state of array at every step. Same for other RAID systems including some HW based ones. Every single one I’ve used were very clear about the fact that array isn’t fully redundant.

In summary, the article’s author seems primarily upset that btrfs isn’t a ZFS clone.

FWIW I didn’t have that impression. I have experience with multiple RAID controllers and multiple SW RAID systems and his points would be valid with any of those.

Anyways thank you for your reply. It’s not the answer I was hoping for and I don’t agree with your views on some of these issues. But it gives me pretty good idea of the current state of the filesystem.

Out of curiosity in your experience, are issues mentioned in this article actually fixed now? They mention the write hole, so that was fixed. What about the rest?

In context of self hosting it’s probably worth pointing out, that SQLite specifically mentions NFS on their How To Corrupt An SQLite Database File page.

SQLite is used in many popular services people run at home. Often as only or default option, because it does not require external service to work.

To be fair, the onboarding experience in the app is impressively good. It’s extremely straightforward with no unnecessary buttons or steps. So I kind of see why they might be hesitant to add complexity by supporting self-hosted backend as an option.

It looks interesting as an app, but in context of self-hosting there are couple of speed bumps:

• The server side is quite complicated. (compared to Joplin for example) It’s multiple services and it also needs Mongo, Redis and S3. Makes sense for them to do it this way to be able to scale up, but for few users hosted locally it’s quite a lot of moving parts.
• You need to compile client apps to self-host. This effectively kills this as an option on iOS.

You can’t really go wrong with any of those. They are both very solid options. Having said that, if I had to recommend one, I’d go with Adguard, because:

• The interface is better. Most notably the query log interface. Searching the logs with some long time span makes Pihole spike in memory usage and is super slow. (there’s no server-side pagination)
• Custom filters are more powerful thanks to modifiers, which AFAIK Pihole does not support. Some of it can be configured via dnsmasq (without user friendly interface), some I had not found any solution for. Good example is dnstype modifier, which I sometimes use to block AAAA responses for sites, that have set AAAA records, but the service actually does not work over IPv6. So I can disable IPv6 for certain domains if I need to. (or other way around, force IPv6 only)

Some of the above might have changed, I haven’t used Pihole for about a year.

Yes, no problem with IPv6.

This project is using Home Assistant, but the ESPHome configuration is really simple, so perhaps you could adapt it to work without HA?

I’m sort of working on something similar but it’s not complete at all. The idea is that my doorbell will post message to MQTT where I have automation in place to snap a picture and post message to Matrix that someone’s at the door.

The esp32 devices have pretty limited HW, so you have to keep your expectations low if you don’t want to outsource the automation to some external system. You could however definitely do simple things like HTTP post on button press. Which is enough to send a message via some chat or push notification to your phone.

I have some blog post WIP around this that is specifically trying to avoid Home Assistant because there are a ton of tutorials out there for HA already.