Please learn to use your eyes properly.

I can be faster, and it is faster. At least my Windows XP that I need for some exotic old applications runs noticeably faster than from what I can remember on real hardware. Why can it be so? Because a virtual machine does not have that much hardware/devices like a real box. It can also optimize I/O of any kind with intelligent buffering of well-known access patterns (I don't know if it does it, but why else would vbox ask you what system you want to install in a given virtual machine?).

Just because you are some software vendors' bitch, it does not mean that other systems not running it are not professional.

When you have your dumb Windows-based utilities, use Windows. What problem do you have with it? I also use Windows XP (32 bit) in Virtualbox, because I need some crappy old software bundled to an old USB hardware, that is all not supported anymore, but my main system is still FreeBSD/amd64.

Unfortunately, I don't know any of these utilties except "Office" which is easily replaced by LibreOffice. The fact that I don't know them lies in the nature that don't solve anything of value for me. Maybe I am working differently from others. Instead of telling me product names, tell me what you do (I also don't want to know what you do with the products; it is wrong to describe your problems by providing me wrong approaches for solutions). There are plenty of solutions that can be used and you can also develop some for yourself for your special purpose.

What I need more is a reasonable terminal application, Xmonad as a desktop (UTF-8 support), easy integration of gnupg into a mailclient, I need ssh, tmux, text-based vim, a text-based IRC client, a full compiler suite which is ready-to-use. I also need inspection tools for all my system components. And I need a reasonable way to manage time (UTC), so when I travel around the world, I just setup the timezone and not the time itself.

And now tell me, I should install CygWin, because I don't know this poorly emulated Windows crapability layer.

Take a look at FreeBSD Gnome, for example. I am sure that their patches to make Gnome portable again flow back upstream.

When someone develops an desktop environment that does not restrict users to Linux, you should expect from them to make the system portable. The work to make it run should be minimal.

Wayland is being ported to FreeBSD, too. It is a bit useless though, because of Linuxisms in libinput and Weston.

OpenSSH is portable. This is the difference between Linux and BSD developers. BSD developers stick to the Unix concepts and portability has a high value here. Linux developers invent (mostly already existing) solutions by themselves, multiple times, multiple times in a wrong way and mostly for themselves, because... most Unices/BSDs already have the solutions for the problems and why should they accept something that has to be ported with a lot of effort? It is only being done with things that are worth to port.

Ok, I'll try...

Of course, as long as the kernel is patching itself, systemd will take over the kernel's role and keep your system running. Until next year, then the kernel won't get patches anymore, because systemd will fork it's own kernel service systemd-kerneld which will make Linux standalone kernel irrelevant.

FreeBSD user here since over a decade. Welcome.

You haven't seen FreeBSD crash? It only means that you haven't seen enough, yet. FreeBSD is a great system and I recommend it to everyone who can manage it, but you don't need to mention stability as a feature, because it is not the highlight about FreeBSD. You don't install a system and watch how stable it is, but how useful it is (for you and your special requirements).

The best thing about FreeBSD are the FreeBSD Ports and how much commitment there is to make every possible application work on the system. You have basically far more possibilities and options than on Linux distributions thanks to the great job they are doing on this system.

A second point is that it is easier to feel comfortable on the system, because the whole thing is consistent and easy to understand, provided you take some time and learn about the concepts.

You are partially right. I miss the good old dump/restore tools for ZFS, but zfs send/receive do their job (in a limited fashion) well.

I see ZFS as the best option to run larger systems. I've had some problems with it when it was still experimental on FreeBSD, but at the moment it is running fine. I had to replace 2 faulty drives recently. It was painless and has not cost me any bit of lost data. I cannot complain, because there is one administrative problem less that I have to care about.

It is not the task of a filesystem to recover data, but to keep the data as consistent as possible. UFS does not have any protections against bit rot or against hardware failures, so you'll never know if data is broken.

Data recovery is done with backups (which you'll always have, if the data is important for you). There is no way around it.

How exactly does fsck help, if it shows structural inconsistencies to you? It says "blabla... CLEAR [y/n]?" and when you press "y" something is lost and when you say "n"... the filesystem is still broken. And second thing is that when data is gone, it is gone on UFS and if you cannot describe (reliably!) in 5 lines on a display what is gone/affected, the user should always assume that a restore from backup is needed. And how exactly will UFS know if/what data is gone when it even cannot check its consistency? When you are lucky, you'll notice that libc is gone right after a reboot. When have bad luck, your system will notice a lot later that you valuable data is gone and your backups have been already overwritten because the backup tapes/disks are reused after a month or so.

ZFS has got "self-healing" and does not need fsck. It will probably destroy more data while a user cannot give hints with "y" or "n" during self-healing, but the filesystem will become stable and available. ZFS can of course become unrecoverable, like UFS can be un-fsck-able, because essential meta data might have become destroyed. You'll always need backups for important filesystems, no matter if it is UFS or ZFS, everything can get FUBAR.

Hard disks recover sectors with ECC all the time. There is nothing special about it.

I once had 2 drives having 2047 reallocated sector count (buggy firmware, but drive ok).

Also, generally you don't need to panic over this attribute. You should panic when it increases steadily.

Best indicator for failures is not SMART but a reasonable filesystem like ZFS, optionally protected by raidz (if you want to recover from failures, usually you want). zpool status shows very reliably errors. SMART sometimes can lie to you or can have bugs.