The biggest thing with FreeBSD is the overarching design of the system is based on "the principle of least astonishment." When you do something, the system should respond in a way that generally avoids you saying "what the #$%#$!". That means that when you do an upgrade the names of the network ports don't suddenly change and you have to do digging through random wikis to find out that you've been changed from network manager to network tools or some nonsense and now "eth0" is "en3p2". I cannot tell you how many times I've done an os update on Ubuntu to find I cannot boot or cannot ssh into the machine after booting. And these are simple VMs where I just installed the system, some software, and run "apt upgrade"... With FreeBSD, the experience on 14 is still quite similar to 2.2...
The stable versions are also not so stable that you get left way behind. FreeBSD is a full OS, not a kernel with libraries and tools. Everything should work together, and if it doesn't it's a bug. But most stuff is not in the base, only things needed to get up and running. Ports/packages are sometimes less nuanced than apt on Linux, but they get updated and all work together. That means you can have a stable base OS, but keep all the business end patched for security. The entire system is also well documented, so although blogs and google searches will turn up interesting ideas, most often the basics are in the Handbook.
That said, FreeBSD does not have the hardware support of Linux. If you're running on server hardware or a workstation you'll be OK, but on desktops and laptops it is harder to get all the pieces working well, and battery life will be bad... X and graphics cards are also finicky. The place FreeBSD really shines as a headless storage server. If you're used to Linux, FreeBSD also has the habit of putting things in different places or using different tools, but one cannot be consistent over a long period of time and also follow the latest fad.
The biggest thing with FreeBSD is the overarching design of the system is based on "the principle of least astonishment." When you do something, the system should respond in a way that generally avoids you saying "what the #$%#$!". That means that when you do an upgrade the names of the network ports don't suddenly change and you have to do digging through random wikis to find out that you've been changed from network manager to network tools or some nonsense and now "eth0" is "en3p2".
Like when Ubuntu decided the NT1 protocol should be disabled by default in Samba, despite it still being widely used. That really screwed up my home file server.
My favorite was when the maintainer of FVWM on Debian decided, in an incremental, standard, update, that the *only* reasonable way to handle windows was the stack of one at a time--and therefore overwrote the users.fvwmrc file without asking or keeping a backup . . .
[eyeroll]
"You shouldn't make my toaster angry."
-- Household security explained in "Johnny Quest"
Good reasons to switch? (Score:2)
I run Mint at home and it does what I need, but I'm curious what advantages there might be to switching to FreeBSD.
What might be some compelling reasons why someone would use or switch to FreeBSD from another Linux distro? Security, performance, stability...?
Re:Good reasons to switch? (Score:4, Interesting)
The biggest thing with FreeBSD is the overarching design of the system is based on "the principle of least astonishment." When you do something, the system should respond in a way that generally avoids you saying "what the #$%#$!". That means that when you do an upgrade the names of the network ports don't suddenly change and you have to do digging through random wikis to find out that you've been changed from network manager to network tools or some nonsense and now "eth0" is "en3p2". I cannot tell you how many times I've done an os update on Ubuntu to find I cannot boot or cannot ssh into the machine after booting. And these are simple VMs where I just installed the system, some software, and run "apt upgrade"... With FreeBSD, the experience on 14 is still quite similar to 2.2...
The stable versions are also not so stable that you get left way behind. FreeBSD is a full OS, not a kernel with libraries and tools. Everything should work together, and if it doesn't it's a bug. But most stuff is not in the base, only things needed to get up and running. Ports/packages are sometimes less nuanced than apt on Linux, but they get updated and all work together. That means you can have a stable base OS, but keep all the business end patched for security. The entire system is also well documented, so although blogs and google searches will turn up interesting ideas, most often the basics are in the Handbook.
That said, FreeBSD does not have the hardware support of Linux. If you're running on server hardware or a workstation you'll be OK, but on desktops and laptops it is harder to get all the pieces working well, and battery life will be bad... X and graphics cards are also finicky. The place FreeBSD really shines as a headless storage server. If you're used to Linux, FreeBSD also has the habit of putting things in different places or using different tools, but one cannot be consistent over a long period of time and also follow the latest fad.
Re: (Score:2)
The biggest thing with FreeBSD is the overarching design of the system is based on "the principle of least astonishment." When you do something, the system should respond in a way that generally avoids you saying "what the #$%#$!". That means that when you do an upgrade the names of the network ports don't suddenly change and you have to do digging through random wikis to find out that you've been changed from network manager to network tools or some nonsense and now "eth0" is "en3p2".
Like when Ubuntu decided the NT1 protocol should be disabled by default in Samba, despite it still being widely used. That really screwed up my home file server.
Re: (Score:2)
My favorite was when the maintainer of FVWM on Debian decided, in an incremental, standard, update, that the *only* reasonable way to handle windows was the stack of one at a time--and therefore overwrote the users .fvwmrc file without asking or keeping a backup . . .
[eyeroll]