I never got far with FreeBSD on the desktop because every time I thought I would give it a try I ended up just thinking Linux is easier to use and my Mac is already basically the same thing but pre-configured, so it's a pretty expensive hobby unless you have a lot time or just really like playing with the details of your operating system. I agree there are philosophical reasons you might prefer FreeBSD to other operating systems. Anyway, my favorite part of that blog post is this:
# Handle Unicode on removable media
libiconv_load="YES"
libmchain_load="YES"
cd9660_iconv_load="YES"
msdosfs_iconv_load="YES"
"Linux is easier to use" heh. Well I mean Ubuntu is easy to use, sure. Until you want to change things, then it gets in your way.
Every time I try Linux, nothing makes sense to me. Why is there a weird, unfriendly `ip` command instead of `ifconfig`. Why is systemd doing the "* Waiting for some bullshit … [∞ seconds]" thing on shutdown instead of killing everything. Why does the bootloader (which is now part of the systemd project, of course) use EFI variables instead of just putting itself at /EFI/BOOT/BOOTX64.EFI. Why is there so much crap exposed as mounted filesystems. Why is there no separation between the base system and user packages (/usr/local).
Ifconfig had been deprecated for what... over 5 years now? It's a bit different, but if you need it often, you'll either learn in a few days or can just use an ifconfig-compatible wrapper. There are projects that do that already.
The kernel moved to rtnetlink and ifconfig simply doesn't work the same way. Interface labels vs multiple IPs is just one very visible difference.
ip over ifconfig doesn't bother me that much: they were both confusing and ill-documented in their Linux incarnations, IMHO. The mounted crap I think is kinda nice for system introspection, although BSD and Solaris users have been known to disagree.
As for everything in /usr/bin (and my stuff in ~/bin and /usr/local/bin), I think this was a good idea for Linux (but not the BSDs) to do: On Linux, there is no real separation between /usr/bin and /bin in any case (/usr/local/bin is another matter, but it's separate on my system. I think /sbin should have been kept separate as well, but I'm untangling that particular knot: I could do it, but it'd be a mess).
So yeah, systemd is the devil, but the rest I kinda like.
The whole thing with /efi/boot/bootx64.efi and EFI variables just tripped me up yesterday too. I still have no idea if I need to copy my kernel over to bootx64.efi for it to boot.
Basically, because a lot of data isn't safe and only manages to seem safe on average because the power is very reliable and data loss becomes an occasional race condition. :-)
They're sent SIGTERM via kill(1), then a short sleep, then any stragglers get SIGKILL. The idea is to clean up any non-responsive processes, or programs that intentionally ignore SIGTERM.
Note that kill(1) just sends an arbitrary signal to whatever process(es), it doesn't have to be SIGKILL.
Yeah I know how the old init systems work. I also know that the newer ones all try to keep track of which services they're starting so they can shut them down in the right order and wait until they're finished.
# Handle Unicode on removable media libiconv_load="YES" libmchain_load="YES" cd9660_iconv_load="YES" msdosfs_iconv_load="YES"