Why and how we’re migrating many of our servers from Linux to the BSDs

The /dev naming is about are how FreeBSD handles block device aliases. Like Linux, FreeBSD creates a number of aliases based on the block devices labels and uuid. My favourite Linux alias is missing on FreeBSD - bus path (which how you unambiguously get to the you just connected at a cable). On Linux these aliases are just symlinks to the real device, which means all it takes is "ls -l" to see the relationship between devices and aliases. Simple, elegant and it means all devices have one true name, so in error logs and so on you always know what device it's talking about.

Under FreeBSD these aliases are device nodes, so there is no single true name. The real device an alias maps to is not at all obvious. Worse, it's not the same device major or minor, and worse still the aliases behave differently. So for example, it the OS mounts as CDROM using it's label alias (which would be /dev/iso9660/label on FreeBSD) you can't eject it because the alias device doesn't understand the eject ioctl. But the you may not be able to get to it at all, because it's been withered away.

Complicating the issue still further is zfs. It wants to take over the roles of /etc/fstab and /sbin/mount. This gets particularly interesting when you boot off zfs, so there is no /dev, so there are no aliases, so it has no obvious way of figuring out what those path names you gave to zpool meant. They kludged their way around that somehow, but it doesn't always work - which I think is the trigger behind the boot failures I mentioned earlier. They took me days to figure out a work around. It was to turn off some of the aliasing.

I am personally on board with using the various BSDs when it makes sense (though maybe just pick FreeBSD and stick with it, as opposed to fragmenting the install base, the same way how I've settled on Ubuntu LTS wherever possible; it's not ideal but it works), except the thing is that most job ads and such call for Linux experience in particular, same with tooling like Kubernetes and OCI/Docker containers and such. Ergo, that's where most of my time goes, I want to remain employable and also produce solutions that will be understandable to most people, instead of getting my DMs pinged whenever someone is confused by what they're seeing.

(S)he does, their employees explained it many times. They're very public about it.

> So they don't care if a random BTRFS instance borks itself.

They do, according to Christ Mason (IIRC) they investigate every instance of btrfs corruption, regardless of how unimportant the machine and data were. They're not any more frequent than with any other filesystem.

> Facebook probably employ the guy who invented BTRFS and an army of kernel developers on top of that

Not an "army" (only a few developers), but you're correct here.

> they STILL have not fixed RAID5 in BTRFS

Why would they? It's a niche technology that's only interesting to a few home users. I am a home user and have no use for it (or any of the alternatives like raidz).

There were though a lot of people who probably should have used a better DB but used mysql through knowing no better or nothing else being available on cheap shared hosts. Many got lucky and got by but more than a few ended up running into problems or spending time implementing things (complete with bugs for later joy) in their BLL that really belong in the data layer. Similarly using ORMs away from their areas of core advantage is asking for problems later (though one of their core advantages _is_ to help with a quick turnaround on an MVP or other PoC, especially if you aren't much knowledgeable about DB design considerations at the time, so I can't criticise that much).