TS is a lot easier to set up than WG and does not require a publicly accessible IP address nor any public whatsoever. It’s not really comparable to setting WG up yourself; especially w.r.t. security.

As it says on the website, this is still in development and not actually ready for use by mere mortals quite yet. It hopefully will be at some point though as that is its explicit goal.

It’s a central server (that you could actually self-host publicly if you wanted to) whose purpose it is to facilitate P2P connections between your devices.

If you were outside your home network and wanted to connect to your server from your laptop, both devices would be connected to the TS server independently. When attempting to send IP packets between the devices, the initiating device (i.e. your laptop) would establish a direct wireguard tunnel to the receiving device. This process is managed by the individual devices while the central TS service merely facilitates communication between the devices for the purpose of establishing this connection.

If you’re worried about that, I can recommend a service like Tailscale which does not require permanently open ports to the outside world, offering quite a bit more security than an exposed traditional VPN server.

;)

Good luck packaging new stuff

Packaging is generally hard on any distro.

Compared to a traditional distro, the packaging difficulty distribution is quite skewed with Nix though as packages that follow common conventions are quite a lot easier to package due to the abstractions Nixpkgs has built for said conventions while some packages are near impossible to package due to the unique constraints Nix (rightfully) enforces.

good luck creating new options

Creating options is really simple actually. Had I known you could do that earlier, I would have done so when I was starting out.

Creating good options APIs is an art to be mastered but you don’t need to do that to get something going.

good luck cross-compiling

Have you ever tried cross-compiling on a traditional distro? Cross-compiling using Nixpkgs is quite easy in comparison.

actually good luck understanding how to configure existing packages

Yeah, no way to do so other than to read the source.

It’s usually quite understandable without knowing the exact details though; just look at the function arguments.

Also beats having no option to configure packages at all. Good luck slightly modifying an Arch package. It has no abstractions for this whatsoever; you have to copy and edit the source. Oh and you need to keep it up to date yourself too.

Gentoo-like standardised flags would be great and are being worked on.

good luck getting any kind of PR merged without the say-so of a chosen few

Hi, one of the “chosen few” here: That’s a security feature.

Not a particularly good one, mind you, but a security feature nonetheless.

There’s also now a merge bot now running in the wild allowing maintainers of packages to merge automatic updates on their maintained packages though which alleviates this a bit.

have fun understanding why some random package is being installed and/or compiled when you switch to a new configuration.

It can be mysterious sometimes but once you know the tools, you can directly introspect the dependency tree that is core to the concept of Nix and figure out exactly what’s happening.

I’m not aware of the existence of any such tools in traditional distros though. What do you do on i.e. Arch if your hourly shot of -Syu goes off and fetches some package you’ve never seen before due to an update to some other package? Manually look at PKGBUILDs?

Yes, yes they will. If you’re the sole user, they’d identify you from your behaviour anyways.

I don’t think internet proxy won’t help very much w.r.t. privacy but it will make you a lot more susceptible to being blocked.

I do like the idea of using USB drives for storage, though…

I wholeheartedly don’t.

They are quite solid but be aware that the web UI is dog slow and the menus weirdly designed.

Well that depends on how you define malware ;)

That is just a specific type of drive failure and only certain software RAID solutions are able to even detect corruption through the use of checksums. Typical “dumb” RAID will happily pass on corrupted data returned by the drives.

RAID only serves to prevent downtime due to drive failure. If your system has very high uptime requirements and a drive just dropping out must not affect the availability of your system, that’s where you use RAID.

If you want to preserve data however, there are much greater hazards than drive failure: Ransomware, user error, machine failure (PSU blows up), facility failure (basement flooded) are all similarly likely. RAID protects against exactly none of those.

Proper backups do provide at least decent mitigation against most of these hazards in addition to failure of any one drive.

If love your data, you make backups of it.

With a handful of modern drives (<~10) and a restore time of 1 week, you can expect storage uptime of >99.68%. If you don’t need more than that, you don’t need RAID. I’d also argue that if you do indeed need more than that, you probably also need higher uptime in other components than the drives through redundant computers at which point the benefit of RAID in any one of those redundant computers diminishes.

Without any cold hard data, this isn’t worth discussing.

The problem is that it’s not just 15W; I merely used that as an example of how even just two “low power” devices can cause an effect that you can measure in euros rather than cents.

Yes. Low power draws add up. 5W here 10W there and you’re already looking at >3€ per month.

You probably could. Though I don’t see the point in powering a home server over PoE.

A random SBC in the closet? WAP? Sure. Not a home server though.

If you’re using containers for everything anyways, the distro you use doesn’t much matter.

If Ubuntu works for you and switching away would mean significant effort, I see no reason to switch outside of curiosity.

The operating system is explicitly not virtualised with containers.

What you’ve described is closer to paravirtualisation where it’s still a separate operating system in the guest but the hardware doesn’t pretend to be physical anymore and is explicitly a software interface.

Do you have a media center and/or server already? It’s a bit overkill for the former but would be well suited as the latter with its dedicated GPU that your NAS might not have/you may not want to have in your NAS.

Glad I could save you some money :)

NixOS packages only work with NixOS system. They’re harder to setup than just copying a docker-compose file over and they do use container technology.

It’s interesting how none of that is true.

Nixpkgs work on practically any Linux kernel.

Whether NixOS modules are easier to set up and maintain than unsustainably copying docker-compose files is subjective.

Neither Nixpkgs nor NixOS use container technology for their core functionality.
NixOS has the nixos-container framework to optionally run NixOS inside of containerised environments (systemd-nspawn) but that’s rather niche actually. Nixpkgs does make use of bubblewrap for a small set of stubborn packages but it’s also not at all core to how it works.

Totally beside the point though; even if you don’t think NixOS is simpler, that still doesn’t mean containers are the only possible mean by which you could possibly achieve “easy” deployments.

Also without containers you don’t solve the biggest problems such as incompatible database versions between multiple services.

Ah, so you have indeed not even done the bare minimum of research into what Nix/NixOS are before you dismissed it. Nice going there.

as robust in terms of configurations

Docker compose is about the opposite of a robust configuration system.