C'est pas vendredi. Pour avoir longuement utilisé les deux, je propose d'apporter les précisions suivantes :
OpenVZ n'est pas upstream, c'est de leur faute s'ils n'ont longtemps supporté que le kernel 2.6.32, pas celle de Debian. Après des années et des années de "oui, on réécrit ça en upstream dans le kernel, c'est pour bientôt" je ne sais pas si ça a fini par évoluer. C'est dommage car oui c'est probablement le meilleur truc pour faire des vps bien isolés et pilotables.
La documentation de FreeBSD est bien mais : elle reste légère (pour les jails c'est pas très clair je trouve), elle ne couvre que le système de base (alors que dans la vraie vie tu va avoir besoin des ports/packages sinon tu fais pas grand chose). Tu va me dire qu'il y a les manpage, mais pour moi rien ne vaut des exemples pratiques pour comprendre une techno. Pour debian tu as une énorme communauté d'utilisateurs (blogs, stackoverflow, collègues...) qui n'est pas négligeable. J'accorde cependant que les logiciels de base de FreeBSD ont tous une conf humainement lisible et compréhensible.
Oui LXC c'est bancal, c'est un autre point que j'accorde. Je rajoute que sous Wheezy il y avait un bug qui faisait que certains templates ne marchait pas et le mainteneur était de mauvaise foi ("oui mais sous Sid ça marche"), les utilisateurs ont du monter un mini scandale pour que ce soit corrigé. Sous Linux on ne sait jamais quel système de container/virtualisation sera mature ou upstream l'année prochaine. Mais basiquement aujourd'hui tout le monde a les yeux rivés sur Docker pour les containers et KVM pour la virtualisation.
Iptables ça se discute, perso je suis habitué à leur syntaxe. Par contre je regrette qu'il n'y ait pas de daemon officiel pour charger les règles au démarrage, tout le monde y va de sa sauce (édition du /etc/rc.local, unit systemd...).
La base n'est pas mélangée avec les packets : bouais là encore l'intérêt se discute. Sur debian le même soin est apporté au système de base ou aux logiciels tiers (qui n'ont même pas de distinction). Sur FreeBSD, par expérience j'ai toujours fini par avoir des problèmes avec pkg upgrade à cause des logiciels tiers en rolling release. Le dernier en date c'était deluge (dépendance python ou liboost pétée je crois). Sous debian c'est figé il n'y a pas de surprise (ou rarement, et le mainteneur corrige). Ou encore cet aspect rolling release fait que les fichiers de conf peuvent changer, moi j'avais tout automatisé avec Ansible, et suite à une maj mon playbook ne fonctionnait plus (unbound qui intégrait deux lignes "listen" au lieu d'une, soudainement).
Le /etc/rc.conf : mouais, ça ne concerne que les logiciels de base de FreeBSD, par exemple si tu installe nginx à partir des ports tu aura toujours un /usr/local/etc/nginx/nginx.conf à gérer hein. Faut penser à tout l'écosystème qui va avec.
Point que je rajoute : FreeBSD n'a pas systemd. Si vous mettez de côté tout le FUD qu'on a fait sur cette techno et essayez d'écrire un service ou un container (systemd-nspawn) vous verrez que c'est génial, unifié, et qu'on gagne un temps fou. Jetez un oeil à l'init de nginx et à son unit systemd, le second est tellement plus simple et lisible. Chaque fois que j'ai du bidouiller un init pour FreeBSD je me suis dit "putain, j'y ai passé des heures alors qu'avec systemd j'aurais juste mis ma commande, mon user et hop".
Après c'est sûr que FreeBSD est un super OS, de part son support natif de ZFS, son développement rapide, sa grande compatibilité hardware, ses jails, ses services réseau. Mais perso par expérience j'en reviens toujours à Debian qui est plus universel, qui est figé (pas de rolling release), mais c'est un choix.
# C'est pas vendredi
Posté par MTux . En réponse au journal Debian sur mon serveur plus jamais, de chez jamais.. Évalué à 10. Dernière modification le 14 décembre 2017 à 12:19.
C'est pas vendredi. Pour avoir longuement utilisé les deux, je propose d'apporter les précisions suivantes :
OpenVZ n'est pas upstream, c'est de leur faute s'ils n'ont longtemps supporté que le kernel 2.6.32, pas celle de Debian. Après des années et des années de "oui, on réécrit ça en upstream dans le kernel, c'est pour bientôt" je ne sais pas si ça a fini par évoluer. C'est dommage car oui c'est probablement le meilleur truc pour faire des vps bien isolés et pilotables.
La documentation de FreeBSD est bien mais : elle reste légère (pour les jails c'est pas très clair je trouve), elle ne couvre que le système de base (alors que dans la vraie vie tu va avoir besoin des ports/packages sinon tu fais pas grand chose). Tu va me dire qu'il y a les manpage, mais pour moi rien ne vaut des exemples pratiques pour comprendre une techno. Pour debian tu as une énorme communauté d'utilisateurs (blogs, stackoverflow, collègues...) qui n'est pas négligeable. J'accorde cependant que les logiciels de base de FreeBSD ont tous une conf humainement lisible et compréhensible.
Oui LXC c'est bancal, c'est un autre point que j'accorde. Je rajoute que sous Wheezy il y avait un bug qui faisait que certains templates ne marchait pas et le mainteneur était de mauvaise foi ("oui mais sous Sid ça marche"), les utilisateurs ont du monter un mini scandale pour que ce soit corrigé. Sous Linux on ne sait jamais quel système de container/virtualisation sera mature ou upstream l'année prochaine. Mais basiquement aujourd'hui tout le monde a les yeux rivés sur Docker pour les containers et KVM pour la virtualisation.
Iptables ça se discute, perso je suis habitué à leur syntaxe. Par contre je regrette qu'il n'y ait pas de daemon officiel pour charger les règles au démarrage, tout le monde y va de sa sauce (édition du /etc/rc.local, unit systemd...).
La base n'est pas mélangée avec les packets : bouais là encore l'intérêt se discute. Sur debian le même soin est apporté au système de base ou aux logiciels tiers (qui n'ont même pas de distinction). Sur FreeBSD, par expérience j'ai toujours fini par avoir des problèmes avec pkg upgrade à cause des logiciels tiers en rolling release. Le dernier en date c'était deluge (dépendance python ou liboost pétée je crois). Sous debian c'est figé il n'y a pas de surprise (ou rarement, et le mainteneur corrige). Ou encore cet aspect rolling release fait que les fichiers de conf peuvent changer, moi j'avais tout automatisé avec Ansible, et suite à une maj mon playbook ne fonctionnait plus (unbound qui intégrait deux lignes "listen" au lieu d'une, soudainement).
Le /etc/rc.conf : mouais, ça ne concerne que les logiciels de base de FreeBSD, par exemple si tu installe nginx à partir des ports tu aura toujours un /usr/local/etc/nginx/nginx.conf à gérer hein. Faut penser à tout l'écosystème qui va avec.
Point que je rajoute : FreeBSD n'a pas systemd. Si vous mettez de côté tout le FUD qu'on a fait sur cette techno et essayez d'écrire un service ou un container (systemd-nspawn) vous verrez que c'est génial, unifié, et qu'on gagne un temps fou. Jetez un oeil à l'init de nginx et à son unit systemd, le second est tellement plus simple et lisible. Chaque fois que j'ai du bidouiller un init pour FreeBSD je me suis dit "putain, j'y ai passé des heures alors qu'avec systemd j'aurais juste mis ma commande, mon user et hop".
Après c'est sûr que FreeBSD est un super OS, de part son support natif de ZFS, son développement rapide, sa grande compatibilité hardware, ses jails, ses services réseau. Mais perso par expérience j'en reviens toujours à Debian qui est plus universel, qui est figé (pas de rolling release), mais c'est un choix.