为什么我在家用服务器上运行 FreeBSD?
Why I run FreeBSD for my home servers (2024)

原始链接: https://aumont.fr/posts/FreeBSD-Home-Server/

2024年,Linux作为桌面操作系统表现出色,得益于Valve/Steam等厂商的努力,用户体验友好,运行流畅。然而,作者认为Linux作为服务器操作系统却是一个“一团糟”,他指出了systemd的问题以及Docker和Kubernetes等过度抽象层带来的麻烦,这些层 often without clear justification(通常缺乏明确的理由)就被实施。 “勿使之简”的信条导致系统复杂,容易出错且难以调试。 日志管理被特别指出是一个问题,作者批评了不同发行版之间包管理和网络管理的复杂性。FreeBSD被认为是更好的服务器替代方案,因为它简单、稳定、文档完善且资源利用率高。其主要优点包括轻松的灾难恢复、用于服务管理的jail以及ZFS的高效性。 FreeBSD的主要缺点是越来越多的开发者只提供基于Docker的开源软件安装方式,而忽略了裸机或其他包格式。作者列举了一些受这种Docker中心化方法影响的软件,这阻碍了它们在FreeBSD上的部署。

Hacker News 最新 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录 我为什么在我的家庭服务器上运行 FreeBSD (aumont.fr) 19 分 psxuaw 3 小时前 | 隐藏 | 过去 | 收藏 | 讨论 加入我们,参加 6 月 16-17 日在旧金山举办的 AI 初创企业学校! 指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系我们 搜索:
相关文章

原文

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.
Event if you're a gamer, huge progress has been made, thanks in particular to Valve/Steam.

On daily basic I use EndeavourOS on my laptop and it is great distro.

Everything works fine.

And much like a Windows user, I don't care how a particular service is launched, how the Ram is managed, etc. 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 when it is necessary to use 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.

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

If you 2024 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 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 ?

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.

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.

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 ...
  • 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 sucks hard with there docker deploy mode : #

note 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 ...

联系我们 contact @ memedata.com