Linux is pretty nice as Desktop : #

In 2024 GNU/Linux is now a pretty nice OS as Desktop environnement you can absolutely runs everything without any issue.
Even if you're a gamer, huge progress has been made, thanks in particular to Valve/Steam.

As daily driver I use EndeavourOS on my laptop and it is great distro.

Everything works fine (Appart some annoying Waiting for service to be stopped : 10sec/1minute ... when I want to shutdown my laptop)

And much like a Windows user, I don't care how a particular service is launched, how the Ram is managed, ... I just want to install/remove programs, use Wifi, bluetooth devices, web applications, various remote control tools and some markdown / txt editors and have access to a shell.

As laptop user, the rest doesn't matter to me.

So yeah Linux is definitively a great OS Desktop.

And a big mess as Server OS : #

Like every other sys/{ops,admin,store}, my company/customers use RHEL or ~~Centos~~ Rocky when it is necessary to run a Linux
And to be honest after dozens of year of administration, troubleshooting, workarround. I still didn’t understand HOW this factory works.

And I've read tons of RedHat documentation / KB.

warning SystemD.
TLDR : the main problem is SYSTEMD, the secondary problem is the stacking of abstraction layers docker / kubersomething most of the time used of unknown reasons “just because it's modern”.

Don’t keep it Simple let’s do something complicated : #

Looks like this is the new mantra ! The new “MicroService” way of life that’s generated gigatons of logs impossible to debug when you have issue on production.

Another point : everything that systemD manages (i.e. the entire system) makes things complicated.

Simple things like device mounting, which you'd think would be handled entirely by /etc/fstab, can be bypassed by systemd options.
Also it becomes progressively larger and manages more and more things in spite of common sense. Moutpoint/NTP/DNS/Log Management and maybe SSH ... Richard please do something RedHat/IBM is eating GNU 😁

Complicated stuff = high probably of failure = Complicated issue to troubleshoot in production

If in 202x you'r a backend/system Product/Owner/Developpeur ... what ever please mark theses words !

warning Reminder :
In other words : Overall system reliability is therefore the product of the individual reliability of each component.
Thus, the more components there are in the system (excepted for redundancy), the greater the probability that at least one component will fail, reducing overall system reliability.

Example with a simple system the GNU/Linux log management : #

A simple log management
As you can see log management is pretty simple on SystemD/Linux.

When one of your service doesn’t trace anymore more the easiest way is to restart everything (journalct , syslog, rsyslog, syslog.socket ... who knows ?)

Also it’s pretty common on overloaded systemd to see journalctl consumming 100% of one core.
Could luck for trying to mitigate this.

I can ask you the same question what is the righ tool to use for Debian when you want deal with packages ? apt , aptitude, apt-get ? Ho I've also forgot snap packages or flapak ...

We can also talk about the network configuration which can be done with nmcli or by changing config file ...
It doesn't really matter in a desktop environment.
But on a server configuration, it does matter when 3 years later you have to reinstall the machine.

Yeah Debian ... 😁 #

Don’t talk me about SystemD/Debian please ...

Long time ago like a lot of people I was an sysadmin home user of Debian. I was running my services with “almost” RIP OpenVZ a paravirtualisation solution. At that time, Docker was just beginning to appear.

It was perfectly supported in 2.8 Kernel (Debian 8 or something even older) but for some reasons the Debian project choosen to not include the OpenVZ into the next Debian release as upstream solution. The only way to continue using OpenVZ was to ... downgrade its kernel to continue taking advantage of portability ?!!
And if you want to keep using OpenVZ you have to use Devian
What a joke.

So I have to redo all my “architecture” redeploy all my service into a new container solution ?! Rewrite/test the backup Script and so on ... Ho thank you and good bye Debian !

Professional distributions with which you can't even do a rolling upgrade (Rhel / Rocky) : #

That’s probably the biggest joke for a profesionnal distribution : if you want to jump from 1 main branch to another one you have to reinstall everything (or use tools like leap)

Yeah I know , you can do it with Debian/Fedora/Arch (which is rolling).

And with FreeBSD 😎 #

Everything is simple , everything is documented, everything make sense.
Ok things are probably a bit “old-school” and use the old Unix-way to do thing.

But this is what we like/needs in production : simplicity and stability !

I ran FreeBSD on my personnals server since 9.x released and so far upgrade after upgrade no breaking changes !
Everything works since the beginning.

By stability I mean everything that work in that way in 2025 will work in the same way in 2030.

Of course, I've changed physical servers several times and had to deal with disaster recovery situations.
Each time, the operation of restarting the services proved to be simple and effective.

This site for instance is hosted (with dozens of other services) with a small box powered with a Intel N100 with 16G of RAM. I do not host several XEON Core that host K8S on several servers.

I'm european and electriciy is expensive, I want to run low power machines. I don't like thing that brings too much unnecessarily overhead.
When I have ISP or Electricity outage, very rare, but it happens, there's not much point in switching the service into another machine in the same room, which also has no power ...
Yes, I could have a machine hosted elsewhere with a cloud provider ... but I don't like unnecessary subscriptions.

Restoring from disaster (macro plan) : #

Basically you have to :

Restore you /home or /root
Restore /etc/rc.conf
Restore your firewall configuration /etc/pf.conf
Restore your service that are all running into a jail

Et voila.

Pros : #

This is problably the main point : All is simple with FreeBSD.
All the programme will have there configuration files into /usr/local/etc
Memory / CPU footprint is minimal.
By default logs are managed by newsyslog not a labyrinthine system.
Jails are so powerfull to manage tons of services and still there since FreeBSD 6.x ... This is a nativ tool of FreeBSD. There are severals wrapper iocage/bastille/ezjail ... but basically this is still the same thing : jail and you can easily migrate from one wrapper to another. Build easy network setting or complicated secured stuff. Mount a NFS share within the jail ... You don’t have to choose between, lxd,lxc, docker,containerd ...
- Of course you can also run Ansible/Salt - Random new fashion automation tool - with FreeBSD to orchestrate all your jails.
Virtualisation is nice and powerfull with Bhyve : Post to follow on this topic.
Whole system configuration is done in /etc/rc.conf
The firewall solution availables are awesome (Packet Filter).
pkg to manage packets, that’s all.
You don’t have to cross your finger when you run an OS major upgrade.
The network stack is fast and efficient.
ZFS is more efficient on FreeBSD (Insert Source)

Cons : #

Probably a few sleepless nights to get things like bluethooth working ...
You'll have to be more adventurous to run a full desktop environment (even if it works!).
Still a bit Unix old-fashion way to manage things ? But is it a problem finally ?

The biggest issue with FreeBSD : The very bad habbit of developper to deploy OpenSource software only with Docker 😈 #

There is a new fashion on the OpenSource world. Developpers think Docker is the new de-facto standard and only propose to install the tools with Docker.
Most of the time they do no provide any DOCUMENTATION to install their software in a baremetal way.

At best, they offer an .rpm or .deb package for installation on a non-docker OS.
But most of the time it's a docker file.

Even worse, modern applications often deploy the code and database needed to run the code directly in the docker compose file.

At what point did these people think it was relevant to run 10 different databases when I'm hosting 10 applications ?

By chance the FreeBSD communauty is determined and competent and will alway try a way to create a packet for freeBSD 😇

Identified software that suck hard with there docker deploy mode : #

note
Maybe change this chapter into dedicated page if the list grows.

Immich : At least there is a doc to deploy on TrueNas but this is just Screeshot and nothing about how to deploy by hand (Also this app also deploy PostgreSQL ... Dude I have allready a mutualised MariaDB I just want to deploy your app into my database, not bootstrap tons of other components) :
Complexity level to deploy on FreeBSD : Medium / hard (Probably doable by spending some week end on this).
BunkerWeb : This is supposed to be a Nginx hardened on steroïds, On the Github there is any documentation to deploy / build the app from SOURCE, use docker / kub / rpm / .deb or NOTHING.
Complexity level to deploy on FreeBSD : Hard , I’ve tried to read the files on the .deb and this is tons of python scripts that installs dozen of lua/rpm module .. Why this is so complicated to deploy a Nginx with some Lua scripts ?
Silverbullet : Ho my god I love this app 😍 I use it on daily-basis as my note garden. I will probably create a page about this app later. I recently create a init scrip to start it and it works fine.
Complexity level to deploy on FreeBSD : Easy
List to be continued ...