Hébergement web : FreeBSD vs Linux/Debian

(ou quand l’élégance technique cède face au pragmatisme de l’écosystème)

Il y a une ironie cruelle dans l’évolution de l’infrastructure web moderne. Après des années à administrer des serveurs en production, d’abord en bare metal puis virtualisés sous VMware et maintenant Proxmox, je dois me rendre à l’évidence : les systèmes BSD, pourtant techniquement supérieurs sur tant d’aspects, ont perdu la bataille de l’hébergement web face à Linux. Et plus spécifiquement face à Debian.

Ce constat ne me réjouit pas. FreeBSD m’a accompagné pendant des années, OpenBSD sécurisait mes firewalls avec une rigueur sans égale, et NetBSD se déployait partout où l’exotisme matériel l’exigeait. Mais pour héberger WordPress, gérer des stacks LAMP/LEMP, faire tourner PHP-FPM et MySQL/MariaDB en production ? Debian s’impose désormais comme l’évidence, et ce n’est pas un hasard.

L’élégance architecturale des BSD face à la réalité de l’écosystème

Les BSD incarnent une philosophie d’ingénierie que j’ai toujours admirée : cohérence du système de base, séparation nette entre kernel et userland, documentation exemplaire, licence permissive. FreeBSD livre un système complet, testé comme un tout. OpenBSD place la sécurité au-dessus de tout. NetBSD privilégie la portabilité universelle.

Comparé au patchwork historique de Linux (où le kernel est développé séparément de l’espace utilisateur, où chaque distribution fait ses propres choix, où systemd a provoqué des guerres de religion et a fait migrer plus d’admins vers BSD que n’importe quelle campagne de marketing de la FreeBSD Foundation), les BSD offrent une cohérence architecturale indéniable.

Alors pourquoi cette défaite dans le domaine de l’hébergement web ?

Le problème des dépendances : symptôme d’un écosystème déséquilibré

Quand on installe Apache, Nginx, PHP ou MySQL sur FreeBSD versus Debian, la différence de volume des dépendances est frappante. Sur Debian, une installation typique de PHP 8.x avec ses extensions courantes tire des dizaines de paquets, des librairies système, des wrappers, des outils de build. Sur FreeBSD via ports ou pkg ? Le volume est souvent moindre, mais au prix d’une complexité d’intégration supérieure.

Cette asymétrie révèle une réalité dérangeante : ces applications ne sont tout simplement pas développées avec BSD comme cible principale.

L’écosystème PHP : un enfant de Linux

PHP, l’épine dorsale de WordPress et d’une part colossale du web, est massivement développé et testé sur Linux. Les mainteneurs utilisent Linux, les CI/CD tournent sur Linux, les benchmarks officiels sont faits sur Linux. FreeBSD ? Un citoyen de seconde zone.

Regardez les tickets de bugs : combien de problèmes spécifiques BSD restent ouverts pendant des mois ? Combien de patches proposés par la communauté FreeBSD sont ignorés ou rejetés faute de mainteneur intéressé ? Le développement est optimisé pour l’écosystème dominant, c’est une loi d’airain du logiciel libre.

MySQL/MariaDB et le cauchemar du threading

Parlons technique. MySQL et MariaDB sont conçus autour du modèle de threading Linux, et c’est là que le bât blesse pour BSD.

Linux utilise NPTL (Native POSIX Thread Library) depuis les années 2000, une implémentation 1:1 où chaque thread utilisateur correspond à un thread kernel (ou plus précisément à une tâche kernel légère). Cette approche offre un scheduling très réactif et exploite parfaitement les architectures multi-cœurs modernes. Le scheduler CFS (Completely Fair Scheduler) de Linux gère ces milliers de threads avec une efficacité redoutable.

FreeBSD a longtemps utilisé un modèle M:N (plusieurs threads utilisateur mappés sur N threads kernel) avec sa libthr, avant de basculer vers un modèle 1:1 plus proche de Linux. Mais le scheduler FreeBSD, bien qu’excellent, n’a jamais été optimisé pour les patterns d’utilisation spécifiques de MySQL : création/destruction intensive de threads, contention sur les mutex, gestion des thread pools.

Résultat concret ? Sur une même machine avec un workload MySQL intensif, Linux affiche systématiquement de meilleures performances. Non pas parce que le code MySQL est mal écrit pour BSD, mais parce qu’il est écrit, testé et optimisé sur et pour Linux. Les appels à pthread_create(), les stratégies de locking, les optimisations de cache L2/L3 : tout est calibré pour glibc et le scheduler Linux.

OpenBSD, avec son approche sécurité-first et ses choix conservateurs, souffre encore plus : performances Threading correctes mais jamais exceptionnelles, parce que la performance n’est pas la priorité. Ce qui est parfaitement cohérent avec la philosophie du projet, mais désastreux pour des applications gourmandes comme MySQL.

ZFS : l’exception qui confirme la règle

Paradoxalement, ZFS est le domaine où FreeBSD écrase Linux, et c’est une illustration parfaite de mon propos sur l’importance de l’intégration native.

Sur FreeBSD, ZFS est un citoyen de première classe depuis la version 7.0 (2008). L’implémentation est mature, profondément intégrée au kernel, testée en production sur des milliers de serveurs. Le tuning ZFS sur FreeBSD est documenté, prévisible, et les paramètres comme vfs.zfs.arc_max ou les réglages de vdev fonctionnent exactement comme annoncé.

Sur Linux ? ZFS arrive via ZFS on Linux (OpenZFS), un port brillant techniquement mais qui reste un module externe au kernel. Résultat : incompatibilités subtiles avec certains kernels, performances parfois erratiques selon les versions, fonctionnalités en retard par rapport à FreeBSD (comme certaines features de déduplication ou de compression). Sans parler du cauchemar légal : ZFS est sous licence CDDL (incompatible avec GPL), donc Debian ne peut pas shipper ZFS activé par défaut. Il faut le compiler soi-même ou passer par des PPA/repos tiers.

Ironie suprême : le système de fichiers où FreeBSD excelle n’est pas celui utilisé massivement pour l’hébergement web. Les hébergeurs Linux préfèrent ext4, XFS ou Btrfs (des filesystems moins puissants que ZFS mais natifs, supportés, optimisés pour leur écosystème).

Encore une fois : l’excellence technique isolée perd face à l’intégration écosystémique.

L’effet réseau : pourquoi Linux a gagné

La supériorité technique ne suffit pas. L’adoption massive crée un effet d’entraînement irrésistible.

1. Le choix des hébergeurs

OVH, AWS, Google Cloud, Azure, DigitalOcean : tous proposent des images Linux pré-configurées pour les stacks web. FreeBSD ? Disponible, mais en marge, avec moins de templates, moins d’intégration, moins de support. Le marché de l’hébergement a tranché.

2. La documentation communautaire

Cherchez « optimiser PHP-FPM pour WordPress » sur Google. Vous trouverez des centaines de tutoriels, d’articles de blog, de discussions StackOverflow, presque tous basés sur Ubuntu/Debian. Pour FreeBSD ? Quelques ressources dispersées, souvent obsolètes, rédigées par des admins qui finissent par migrer vers Linux par lassitude.

Cette asymétrie documentaire crée un cercle vicieux : moins d’utilisateurs → moins de documentation → moins de nouveaux utilisateurs → les développeurs upstream s’en foutent encore plus.

3. Les Panel d’administration

cPanel, Plesk, ISPConfig, Webmin : tous ces outils de gestion d’hébergement mutualisé sont développés prioritairement pour Linux. Adapter un panel à FreeBSD demande un effort de développement que peu d’éditeurs jugent rentable. Résultat : vous vous privez d’outils essentiels pour gérer efficacement un parc de sites clients.

Et ne parlons même pas de Docker, Kubernetes, ou tout l’écosystème containerisation : pensé Linux, pour Linux, sur Linux. Les jails FreeBSD sont techniquement supérieurs ? Peu importe, personne ne développe d’orchestrateur pour eux.

Debian : le pragmatisme comme ligne directrice

Pourquoi Debian spécifiquement, et pas Ubuntu ou CentOS/Rocky ?

Debian incarne un équilibre rare : stabilité d’entreprise sans les contraintes commerciales de Red Hat, politique de release conservative mais prévisible, gestion des paquets robuste via APT (infiniment supérieur à yum/dnf), communauté massive. Pour de l’hébergement web en production, Debian Stable offre exactement le compromis nécessaire.

Ubuntu est trop agressif dans ses mises à jour, trop lié aux décisions parfois douteuses de Canonical (Snap, anyone?). CentOS/Rocky a perdu sa prévisibilité après le fiasco CentOS 8, quand Red Hat a décidé de saborder la distribution pour pousser RHEL. Debian reste le choix rationnel pour qui veut de la stabilité à long terme sans dépendre d’un éditeur commercial susceptible de changer les règles du jeu.

Et puis soyons honnêtes : apt-get est juste meilleur que pkg. La résolution de dépendances, les mises à jour, la gestion des backports : tout est plus fluide, plus rapide, mieux documenté sur Debian.

Les cas où BSD reste pertinent

Je ne renonce pas complètement aux BSD. Ils conservent des niches où leur supériorité demeure écrasante :

• Firewalls et routeurs : PF (Packet Filter) sous OpenBSD ou FreeBSD surpasse iptables/nftables en clarté, puissance et auditabilité. La syntaxe de PF est un modèle de lisibilité comparé au bordel de nftables. D’ailleurs, j’ai détaillé dans un article précédent sur le routage avancé avec OpenBSD comment combiner OpenOSPFD, OpenBGPD, PF, IPsec et CARP pour construire une infrastructure réseau de niveau professionnel. C’est exactement le type de cas d’usage où BSD montre toute sa puissance.
• Stockage avec ZFS : FreeBSD offre la meilleure implémentation de ZFS hors Solaris/Illumos. Pour un NAS, un serveur de fichiers, du stockage haute disponibilité, FreeBSD + ZFS reste imbattable.
• Appliances réseau : pfSense et OPNsense (basés sur FreeBSD) dominent le marché des firewalls open source. Et pour cause : stabilité, performance, interface claire.

Mais pour héberger des sites WordPress, gérer des e-commerces WooCommerce, faire tourner des applications PHP modernes ? Linux/Debian s’est imposé par la force de l’écosystème, pas par supériorité technique intrinsèque.

Accepter la défaite tactique sans renoncer aux principes

Cette évolution m’a obligé à revoir mes dogmes. J’ai migré progressivement mes serveurs web de FreeBSD vers Debian, non par conviction technique, mais par réalisme opérationnel. Moins de friction avec les applications, meilleures performances out-of-the-box pour MySQL/PHP, écosystème d’outils plus riche, documentation abondante, clients rassurés par un environnement mainstream.

Les BSD ne sont pas morts. Ils continuent d’innover, de maintenir des standards d’excellence que Linux ferait bien de copier plus souvent. Mais dans la bataille spécifique de l’hébergement web, l’effet réseau a écrasé l’excellence architecturale.

C’est une leçon d’humilité pour tout puriste technique : la meilleure technologie ne gagne pas toujours. L’écosystème, l’adoption, les effets réseau, les choix upstream des développeurs : ces forces économiques et sociales pèsent parfois plus lourd que l’élégance du code ou la cohérence architecturale.

Je garde mes FreeBSD pour le stockage et mes OpenBSD pour les firewalls. Mais mes serveurs web tournent désormais sur Debian. Pas par plaisir. Par pragmatisme. Et c’est peut-être ça, finalement, la vraie maturité d’un administrateur système : savoir quand l’idéalisme technique doit s’effacer devant l’efficacité opérationnelle.

Même si ça fait mal à l’ego.