Yes, for his setup (if I understand right). I'm suggesting having two hosts with ZFS snapshots running (independent of each other) with Syncthing between. So if you delete the files on one host and they get Syncthing'd across there will still be a ZFS snapshot history on the other host. I'd also have a cold storage backup on hand that is also ZFS. Having your backup as a regular filesystem is a very nice feature once it comes to recovery.
Even if you format your drive and Syncthing copies over the empty files you will still have a history of snapshots on the other host running ZFS snapshots.
I'm coming to the same conclusion. I was running Freenas and my file server died and then my files were locked up on that host. Luckily I was using Syncthing to the central file server but I just added new links between individual devices and then it didn't matter that my file server died (except for files that were not on any non-server device). File servers are annoying for disconnected usage. I was using duplicacy for backups but the storage format is annoying (not just regular files) and nothing is more reliable than regular file systems. So now with my new setup I'm using a Rpi4b with NixOS and ZFS data drive over a USB3 dual drive docking station with UASP. I can boot from a USB3 thumb drive (which I do) or an SSD in the docking station and still have another SATA port for the data drive. (The downside of this is RAID doesn't work over USB.)
I'll have two of the same RPi servers in different locations with all software running (like a hot swap) with Syncthing keeping them in sync while ZFS snapshots keeps a history. I can plug in a cold storage drive in the second dock slot once in a while too. I'll have a spare RPi4b on the shelf in case it dies. If my server dies I can take the off site hot backup home and reconfig the network and then it is my primary server. With remote duplicacy backup I'm days away from getting going again. So ZFS snapshots + Syncthing and cold storage is where I'm going (for home use). Also I want to stick with Linux because I set up Freenas 5 years ago and now I forget how to admin it so I'd rather just keep with ZFS and Linux (the zfs send from freenas to zfs recv on Linux works perfectly).
I believe the 3rd image is wrong in that the pink should always stay above the green. The basic idea is you take two loops and then wrap the loose end of the lace around the middle 4 strands twice (or three times) and then finish by putting the loose end between the 4 strands in the middle (pink pair on above, green pair below) and then pull/dress it tight. It helps using the instructions from the site with the broken links to interpret the imgur images:
1. Pick up the laces.
2. Cross the laces over like this... (but don't have them looping into each other like in the picture)
3. and back, leaving loops either side
4. Take the left lace underneath...
5. then back over the top...
6. and wrap round underneath again...
7. and back over the top again.
8. Now similarly with the other lace...
9. underneath, but the other way...
10. then wrapping round as before.
11. Push the lace through the four centre strands.
12. And the same with the other.
13. Then tighten the knot up.
14. Finally, here is an alternate one with an extra turn (at step 10.5).
This is a great shoelace knot as it loosens and cinches tight without untying.
My worst experience was doing a simple min/max of each signal took 7x longer than the simulation. I'd be so happy to toss TCL in the trash. I spent a long time debugging because TCL expr doesn't do -2^2 correctly. The error messages don't tell you the line number and I found no good way to debug. Things like that are just the tip of the iceberg of time wasted fighting with arcane tools. I suppose others have their own stories.
A lot of semi companies have built their own simulation environments because the EDA vendor's provided tools are very limited in what they can do and difficult to use. Many users go to Python, Excel or MATLAB because the programming/math capabilities of the EDA tools are inadequate. Over time these home-grown environments become a burden and the developer disowns it and it becomes a headache.
The EDA tools have no ecosystem you can hook into and they don't really care about the user trying to put the simulators into a flow to solve their problem. It is a bunch of point tools each with their own embedded interpreter that don't play together. I sure hope there is a plan to create a better set of tools so I can write custom netlist checks and do something novel (like get derivatives out of the simulator) and in-memory (no slow disks) and run custom Julia checks during simulation. Julia is a much better match because running Python or MATLAB code within the simulator is way too slow. I'll keep watch for sure.
Wonderful! The one untold story is the more I use it the better the programmer I become. It is so easy to benchmark and profile code. It has a great community that will help you how to write high performance code. Congrats!