Ask HN: Anyone moved to PC-BSD (TrueOS) from macOS?

As to software disappearing. I think what might have been happening is that you'd go install something, but the upgrader had already run and created a new boot environment for the update based on a snapshot from before you'd installed the new pkg. So just as soon as you rebooted into the new BE, you'd "loose" the package. This is one of the reasons that they changed how the updates work, and only create the new BE when you're rebooting. I personally hate this, as I'd rather re-install something than wait 1/2 for the update to re-install pkgs in a singleuser-ish environment.

I second the notion that you might want to consider switching to Ubuntu, rather than going back to Windows. I've run ZFS on Linux for years on my old desktop (now my wife's) and never had a problem. The only "issue" I had was the transition from 14.04 to 16.04 was a bit rocky, as 16.04 includes ZFS natively, rather than using the zfs-on-linux ppa.

It's missing NFSv4 ACL support. It's missing per-dataset user and group permissions, forcing all operations to require root privs; on the other systems, the ZFS tools work for all users, with appropriate checks. No delegation of privileges e.g. to allow users to perform admin actions like snapshotting, send/recv. No transparent NFS export. It behaved badly when a disc glitched, requiring a reboot to resolve; the tools started getting stuck in D state when trying to investigate the fault. And just a few weeks ago it refused to mount all my datasets until I changed the mountpoint (for no discernable reason). FreeBSD and IllumOS provide a more mature, well integrated implementation.

Agreed, this is an amazing feature, as are jails to keep things compartmentalized. I hate having to clutter my FreeBSD home server root install with a billion dependencies for the various services it hosts, so I use jails as lightweight VMs to partition it into different service groups. It also makes it easy to back up and move jails whenever I upgrade because things are contained on ZFS subvols.

For people who don't know, snapshots are also well supported on Linux, and not just in ZFS. I use it with BTRFS on my main workstation and it's saved me a few times. There is a great tool called Snapper (by the SUSE people, but it works on other distros - I use it on Arch) that automates managing snapshots and can even e.g. hook into your package manager to automatically snapshot before an upgrade. It's like Windows System Restore Points done right.

https://wiki.archlinux.org/index.php/Snapper

(Not an expert in this field so please bear with me if I'm too fuzzy or not rigorous enough).

- COW[0] + snapshotting[1] basically give you git-like rollback/failsafe capability. You could e.g. trigger it manually before updating or tweaking stuff, or have it automated everytime you run some pacman/apt/yast/whatever.

- subvolumes[2] give you the features of partitioning without the physical/ordering limitations (each subvol can expand into free space, etc.) Combined with snapshots (you can snapshop each subvol discretely as its own fs), especially towards another physical btrfs drive, and some automation tool (like Snapper from openSUSE or simply crons), your 'machine-wide git' becomes an effective backup solution (1st order at least but you can snapshot to several machines including off-site obviously).

So it's a "set it up and forget it" very powerful filesystem base for your machine, regardless of what you do with it. Rollback instantly, automated backups, self-healing in case of corruption, and btrfs in single-disk or RAID 0/1/10 is incredibly performant. It basically allows you to utterly destroy your install and get it back up and running within minutes (if your snapshotting strategy is well devised, it can be as painless as a matter of changing the boot drive and fixing a single UUID entry in the /boot files, literally 5 minutes).

Note: on your root drive, on OS install you'd typically subvol /home, /var, /var/log (so as to debug externally), or domain folders like /var/www and so on and so forth. It basically makes most 'nix fs architectures constrain-free of most physical drive limitations.

[0]: https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Copy_o...

[1]: https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Snapsh...

[2]: https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Subvol...