FreeBSD development is (still) driven by technical interests, not strictly commercial ones.
En gros, si ça ne lui convient pas, c'est que c'est une décision commercial. Et dire que MacOS est basé sur Freebsd, il faut quand même aller le chercher loin.
Linux has ext4, xfs, btrfs… (and zfs, but with some manual intervention). FreeBSD has UFS2 and ZFS
C'est quoi une "manual intervention" pour un fs ?
found (on average) better performance with this combination.
Sans donner des chiffres, ça ne donne pas vraiment d'indication.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Oui, il me semble que Linux supporte mieux beaucoup de configurations hardware (SMP, NUMA, hyperthreading) et que le scheduler est en général plus performant dès qu'il y a beacoup de cores.
D'ailleurs une des raisons pour que ça soit plus optimisé c'est effectivement qu'il y a plus de développeurs commerciaux qui travaillent sur leurs use-cases, et aussi les ajouts réguliers d'API et les changement d'outils user-space.
Il y a peut-être des cas sur des machines plus simples où FreeBSD pourrait éventuellement passer devant en terme de réseau, ou bien sur des use-cases précis, mais en général Linux est plus optimisé et a souvent des performances plus homogènes.
FreeBSD reste intéressant, mais les performances ne sont pas le critère principal je pense.
Le problème des benchmarks Phoronix, c'est qu'ils prennent une distribution / OS dans sa configuration par défaut, et cela n'est représentatif de rien, en fait.
Si tu veux une machine qui ait de bonnes performances dans un domaine précis, tu dois la rendre spécifique à cet usage, et cela va sûrement demander beaucoup de paramétrage et peut potentiellement la rendre moins performante dans certains autres usages.
Phoronix mesure en fait si la configuration par défaut fait le meilleur compromis dans les cas d'usages de ses benchmarks.
Ce qui serait intéressant, à mon avis, ce sont des benchmarks avec des machines configurées pour donner le meilleur dans un domaine (réseau par exemple).
C'est objectif : ZFS est mal supporté sous les distros Linux (à part sous Ubuntu, ils prennent les risque légal si j'ai bien suivi), alors que sous BSD c'est intégré si j'ai bien suivi (pas de problème de licence).
Pour Debian il semble qu'il faut télécharger à part et compiler chez soit.
La doc que tu donnes montre justement que c'est dans les dépôts et ce sera fait tout seul.
Essayer de migrer de CentOS à RHEL suite à changement de politique
Du coup, ce n'est pas l'installation de ZFS qui pose problème mais la migration vers RHEL. Il me semble que tu as le même problèmes avec certains dépôts externes.
C'est objectif : ZFS est mal supporté sous les distros Linux
Ton seul exemple où ça pose un soucis, c'est RHEL qui justement a un sous-ensemble très strict paquets supporté. SLES le supporte via un dépôt additionnel https://en.opensuse.org/OpenZFS#GUI_Installation
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Ton seul exemple où ça pose un soucis, c'est RHEL qui justement a un sous-ensemble très strict paquets supporté. SLES le supporte via un dépôt additionnel https://en.opensuse.org/OpenZFS#GUI_Installation
Non, c'est Linus lui même qui le dit ici, ça pose un soucis général avec le noyau, ça ne sera pas inclus dedans de manière officielle, donc ça nécessitera des opérations manuelles pour encore un bon moment.
C'est pas parce que Linus a un avis (forcément tranché, on connaît le bonhomme) que c'est Parole d'Évangile…
Il n'a jamais utilisé ou administré une machine contenant plus de quatre disques… Donc ça a autant de valeur à mes yeux que l'avis de mon boulanger sur mon choix de véhicule.
Proverbe Alien : Sauvez la terre ? Mangez des humains !
Je ne porte pas spécialement le personnage dans mon coeur, c'est simplement lui qui décide ce qui est intégré dans le noyau, ayant administré une machine à plus de quatre disques ou pas.
Non, c'est Linus lui même qui le dit ici, ça pose un soucis général avec le noyau, ça ne sera pas inclus dedans de manière officielle, donc ça nécessitera des opérations manuelles pour encore un bon moment.
Ce n'est pas parce que ce n'est pas dans le noyau que les distributions ne vont pas l'automatisé. Les drivers nvidia ne sont pas dans le noyau, mais les distrib fournissent des paquets qui les installent tout seul (et le problème de licence est encore plus compliqué qu'avec zfs). Donc, on, ça ne nécessite pas d'opérations manuelles, certaines distrib viennent avec zfs installée de base même.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
C'est objectif : ZFS est mal supporté sous les distros Linux (à part sous Ubuntu, ils prennent les risque légal si j'ai bien suivi), alors que sous BSD c'est intégré si j'ai bien suivi (pas de problème de licence).
Risque légal ? Qué risque légal ?
La CDDL est une licence libre. Par contre, elle a été écrite de façon a être incompatible avec la GPL (Merci Sun). C'est ça que tu appelle un "risque légal" ?
C'est ce qui fait qu'OpenZFS ne peut pas être diffusé sous forme de module binaire avec le noyau Linux. Mais il peut être compilé à l'installation.
J'appelle pas ça un risque légal, j'appelle ça une crotte technique.
Il n'y a que RH qui a un problème avec OpenZFS. Et ce problème s'appelle Stratis.
Proverbe Alien : Sauvez la terre ? Mangez des humains !
Posté par Misc (site web personnel) .
Évalué à 2.
Dernière modification le 25 janvier 2022 à 19:27.
En gros, si ça ne lui convient pas, c'est que c'est une
décision commercial. Et dire que MacOS est basé sur Freebsd, il
faut quand même aller le chercher loin.
C'est surtout assez triste, parce qu'un des arguments en faveur du logiciel libre, c'est d'éviter le vendor lock-in, à savoir de pouvoir payer quelqu'un pour ça.
C'est pas parfait (loin de la), mais ça veut surtout dire que le refus des "commercial interest", c'est aussi le refus de développement pour des personnes moins techniques, ou des besoins autre que ceux des contributeurs principaux.
C'est surtout ce couper d'un très grand écosystème. Ne pas avoir accès à epbf pour de l'optimisation réseau alors que de plus en plus de smartnic en propose un offload hardware c'est dommage je trouve.
Pareille côté I/O, se passer del'api io_uring est vraiment dommage.
Posté par steph1978 .
Évalué à 6.
Dernière modification le 25 janvier 2022 à 12:20.
J'ai lu l'article hier et je rejoints certains commentaires ici.
Ce n'est pas forcément une décision objective de sa part. C'est plus un ressenti. Je pense que soutenir une alternative *BSD à Linux aujourd'hui c'est un peu comme soutenir une alternative Linux à MSWinServer il y a 20 ans. C'est pour que l'alternative existe et se développe.
Je suppose que FreeBSD sera largement aussi bon dans la plupart des cas de prod, meilleurs dans certains (réseau ?) moins bon dans d'autre (il parle de garder 20% de Linux).
Et puis ce n'est pas un choix complètement ésotérique, il cite Netflix et Whatsapp comme gros utilisateurs, ce n'est sûrement pas seulement pour la beauté du geste.
Moi ça fait qques temps que l'idée me trotte dans la tête de passer qques un de mes serveur de Debian à FreeBSD, cet article me donne envie de m'y mettre. En particulier pour tester l'outillage autour des jails, comme alternative à Docker.
Comparer *BSD à GNU/Linux n'a pas de sens, mais comparer FreeBSD à Debian, FreeBSD à Arch Linux.. oui.
Ayant fait l'expérience de FreeBSD 11 il y a quelques années, j'ai été plutôt déçu de mon expérience personnelle.
La qualité des paquets FreeBSD, je suis tombé sur des paquets qui ne fonctionnaient tout simplement pas. Aussi des collisions d'UID entre deux paquets.
Pas d'installation par défaut. Sous Debian, quand j'installe le paquet Apache, j'ai un service Apache qui fonctionne. Sous FreeBSD faut tout faire à la main.
Dépendance des paquets parfois foireuse. J'ai un paquet A qui dépend d'un paquet B. Je mets à jour A, mais B n'est pas mis à jour. A ne fonctionne plus, à moins de mettre à jour B manuellement.
Fonctionnement en semi-rolling release qui pousse la dernière version d'un logiciel. J'installe un module Perl avec la commande pkg, cela met à jour Perl en une version majeure (genre de Perl 5.25 à Perl 5.26) et ça casse le fonctionnement de SpamAssassin. Sous Debian si vous êtes en Perl 5.28 vous resterez toujours avec cette version.
FreeBSD propose des ports (logiciels qu'on peut compiler avec des options) et des paquets binaires à installer. Cependant la mise à jour de paquets avec pkg upgrade ou même l'installation d'un paquet avec pkg install peut réinstaller une nouvelle version du paquet et effacer le port compilé avec les bonnes options.
Ensuite je ne suis pas un expert FreeBSD, mais quelques années à utiliser FreeBSD ne m'a pas du tout convaincu.
Pas d'installation par défaut. Sous Debian, quand j'installe le paquet Apache, j'ai un service Apache qui fonctionne. Sous FreeBSD faut tout faire à la main.
Marrant, je n'ai jamais compris la manie qu'à Debian de démarrer les services installés avec une conf par défaut (qui ne correspond pas à mes besoins dans 100% des cas).
FreeBSD propose des ports (logiciels qu'on peut compiler avec des options) et des paquets binaires à installer. Cependant la mise à jour de paquets avec pkg upgrade ou même l'installation d'un paquet avec pkg install peut réinstaller une nouvelle version du paquet et effacer le port compilé avec les bonnes options.
En fait que ce soit à partir des ports ou à directement avec pkg et les dépôts binaires, tu manipules la même base de données, donc c'est logique. Je pense que c'est la même chose sur Debian, si tu installes un paquet via dpkg et qu'ensuite tu fais apt update, si ce paquet existe dans les dépôts distants, il sera mis à jour.
L'alternative c'est de maintenir son propre dépôt et de construire les paquets à partir de l'arbre des sources des ports à l'aide de poudriere par exemple.
Posté par Zenitram (site web personnel) .
Évalué à -1.
Dernière modification le 25 janvier 2022 à 21:06.
Marrant, je n'ai jamais compris la manie qu'à Debian de démarrer les services installés avec une conf par défaut (qui ne correspond pas à mes besoins dans 100% des cas).
Marrant, je n'ai jamais compris la manie qu'ont certaines personnes de critiquer les choix par défauts en comparant à leur propre cas comme si leur cas était représentatif et que les mainteneurs seraient trop idiots de ne pas prendre leur cas comme référence.
La critique adressée à FreeBSD par l'auteur du poste auquel je réponds est du même ordre (il faut tout faire à la main, c'est la façon de faire de FreeBSD et ça ne me plait pas, les mainteneurs FreeBSD sont trop idiots pour automatiser tout ça), mais comme ça va dans le sens de ce que tu penses, ça doit moins te choquer.
Posté par Zenitram (site web personnel) .
Évalué à -2.
Dernière modification le 25 janvier 2022 à 21:56.
La critique était centrée sur la partie "qui ne correspond pas à mes besoins dans 100% des cas" dont on se fout complet car on ne parle pas de "mes besoins". Si critique il y a, il faut la faire en fonction de ce qu'a les mainteneurs, donc plein de gens et pas son perso. Ici, on a l'impression d'une personne qui a besoin de son cas perso pour critiquer et que donc c'est bon dans le cas général et du coup la défense de BSD devient une défense de Debian (et par la même occasion un critique de BSD) sans oser l'accepter…
Ramener à ce que je pense est hors sujet.
La remarque a été faite, ça ne vaut pas plus que ça, passons.
Ce n'est pas forcément une décision objective de sa part. C'est plus un ressenti. Je pense que soutenir une alternative *BSD à Linux aujourd'hui c'est un peu comme soutenir une alternative Linux à MSWinServer il y a 20 ans. C'est pour que l'alternative existe et se développe.
Ah mais c'est une raison tout à fait valable. Et même "je préfère bosser sous freebsd" est tout à fait valable. Mais il ne faut pas faire des comparaisons bancales.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Très subjectif
Posté par claudex . Évalué à 6.
J'ai lu en diagonal, mais ça ne donne pas envie.
En gros, si ça ne lui convient pas, c'est que c'est une décision commercial. Et dire que MacOS est basé sur Freebsd, il faut quand même aller le chercher loin.
C'est quoi une "manual intervention" pour un fs ?
Sans donner des chiffres, ça ne donne pas vraiment d'indication.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Très subjectif
Posté par Damien Thébault . Évalué à 6.
Oui, il me semble que Linux supporte mieux beaucoup de configurations hardware (SMP, NUMA, hyperthreading) et que le scheduler est en général plus performant dès qu'il y a beacoup de cores.
D'ailleurs une des raisons pour que ça soit plus optimisé c'est effectivement qu'il y a plus de développeurs commerciaux qui travaillent sur leurs use-cases, et aussi les ajouts réguliers d'API et les changement d'outils user-space.
Quelques exemples de benchmark sur Phoronix:
Il y a peut-être des cas sur des machines plus simples où FreeBSD pourrait éventuellement passer devant en terme de réseau, ou bien sur des use-cases précis, mais en général Linux est plus optimisé et a souvent des performances plus homogènes.
FreeBSD reste intéressant, mais les performances ne sont pas le critère principal je pense.
[^] # Re: Très subjectif
Posté par Pierre-Alain TORET (Mastodon) . Évalué à 3.
Le problème des benchmarks Phoronix, c'est qu'ils prennent une distribution / OS dans sa configuration par défaut, et cela n'est représentatif de rien, en fait.
Si tu veux une machine qui ait de bonnes performances dans un domaine précis, tu dois la rendre spécifique à cet usage, et cela va sûrement demander beaucoup de paramétrage et peut potentiellement la rendre moins performante dans certains autres usages.
Phoronix mesure en fait si la configuration par défaut fait le meilleur compromis dans les cas d'usages de ses benchmarks.
Ce qui serait intéressant, à mon avis, ce sont des benchmarks avec des machines configurées pour donner le meilleur dans un domaine (réseau par exemple).
[^] # Re: Très subjectif
Posté par Zenitram (site web personnel) . Évalué à 3.
Essayer de migrer de CentOS à RHEL suite à changement de politique, se faire refuser car ZFS
Désactiver ZFS
Migrer
Réactiver ZFS
Alors que sans ZFS c'est une étape.
Pour Debian il semble qu'il faut télécharger à part et compiler chez soit.
C'est objectif : ZFS est mal supporté sous les distros Linux (à part sous Ubuntu, ils prennent les risque légal si j'ai bien suivi), alors que sous BSD c'est intégré si j'ai bien suivi (pas de problème de licence).
[^] # Re: Très subjectif
Posté par claudex . Évalué à 5.
La doc que tu donnes montre justement que c'est dans les dépôts et ce sera fait tout seul.
Du coup, ce n'est pas l'installation de ZFS qui pose problème mais la migration vers RHEL. Il me semble que tu as le même problèmes avec certains dépôts externes.
Ton seul exemple où ça pose un soucis, c'est RHEL qui justement a un sous-ensemble très strict paquets supporté. SLES le supporte via un dépôt additionnel https://en.opensuse.org/OpenZFS#GUI_Installation
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Très subjectif
Posté par Pierre-Alain TORET (Mastodon) . Évalué à 3.
Non, c'est Linus lui même qui le dit ici, ça pose un soucis général avec le noyau, ça ne sera pas inclus dedans de manière officielle, donc ça nécessitera des opérations manuelles pour encore un bon moment.
[^] # Re: Très subjectif
Posté par Loïs Taulelle ࿋ (site web personnel) . Évalué à 0.
C'est pas parce que Linus a un avis (forcément tranché, on connaît le bonhomme) que c'est Parole d'Évangile…
Il n'a jamais utilisé ou administré une machine contenant plus de quatre disques… Donc ça a autant de valeur à mes yeux que l'avis de mon boulanger sur mon choix de véhicule.
Proverbe Alien : Sauvez la terre ? Mangez des humains !
[^] # Re: Très subjectif
Posté par Pierre-Alain TORET (Mastodon) . Évalué à 4.
Je ne porte pas spécialement le personnage dans mon coeur, c'est simplement lui qui décide ce qui est intégré dans le noyau, ayant administré une machine à plus de quatre disques ou pas.
[^] # Re: Très subjectif
Posté par claudex . Évalué à 4.
Ce n'est pas parce que ce n'est pas dans le noyau que les distributions ne vont pas l'automatisé. Les drivers nvidia ne sont pas dans le noyau, mais les distrib fournissent des paquets qui les installent tout seul (et le problème de licence est encore plus compliqué qu'avec zfs). Donc, on, ça ne nécessite pas d'opérations manuelles, certaines distrib viennent avec zfs installée de base même.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Très subjectif
Posté par Loïs Taulelle ࿋ (site web personnel) . Évalué à 5.
Risque légal ? Qué risque légal ?
La CDDL est une licence libre. Par contre, elle a été écrite de façon a être incompatible avec la GPL (Merci Sun). C'est ça que tu appelle un "risque légal" ?
C'est ce qui fait qu'OpenZFS ne peut pas être diffusé sous forme de module binaire avec le noyau Linux. Mais il peut être compilé à l'installation.
J'appelle pas ça un risque légal, j'appelle ça une crotte technique.
Il n'y a que RH qui a un problème avec OpenZFS. Et ce problème s'appelle Stratis.
Proverbe Alien : Sauvez la terre ? Mangez des humains !
[^] # Re: Très subjectif
Posté par Misc (site web personnel) . Évalué à 2. Dernière modification le 25 janvier 2022 à 19:27.
C'est surtout assez triste, parce qu'un des arguments en faveur du logiciel libre, c'est d'éviter le vendor lock-in, à savoir de pouvoir payer quelqu'un pour ça.
C'est pas parfait (loin de la), mais ça veut surtout dire que le refus des "commercial interest", c'est aussi le refus de développement pour des personnes moins techniques, ou des besoins autre que ceux des contributeurs principaux.
# Dommage pour les api Linux spécifique
Posté par Tangi Colin . Évalué à 5.
C'est surtout ce couper d'un très grand écosystème. Ne pas avoir accès à epbf pour de l'optimisation réseau alors que de plus en plus de smartnic en propose un offload hardware c'est dommage je trouve.
Pareille côté I/O, se passer del'api io_uring est vraiment dommage.
# subjectif
Posté par steph1978 . Évalué à 6. Dernière modification le 25 janvier 2022 à 12:20.
J'ai lu l'article hier et je rejoints certains commentaires ici.
Ce n'est pas forcément une décision objective de sa part. C'est plus un ressenti. Je pense que soutenir une alternative *BSD à Linux aujourd'hui c'est un peu comme soutenir une alternative Linux à MSWinServer il y a 20 ans. C'est pour que l'alternative existe et se développe.
Je suppose que FreeBSD sera largement aussi bon dans la plupart des cas de prod, meilleurs dans certains (réseau ?) moins bon dans d'autre (il parle de garder 20% de Linux).
Et puis ce n'est pas un choix complètement ésotérique, il cite Netflix et Whatsapp comme gros utilisateurs, ce n'est sûrement pas seulement pour la beauté du geste.
Moi ça fait qques temps que l'idée me trotte dans la tête de passer qques un de mes serveur de Debian à FreeBSD, cet article me donne envie de m'y mettre. En particulier pour tester l'outillage autour des jails, comme alternative à Docker.
[^] # Re: subjectif
Posté par Lawless . Évalué à 7.
Comparer *BSD à GNU/Linux n'a pas de sens, mais comparer FreeBSD à Debian, FreeBSD à Arch Linux.. oui.
Ayant fait l'expérience de FreeBSD 11 il y a quelques années, j'ai été plutôt déçu de mon expérience personnelle.
Ensuite je ne suis pas un expert FreeBSD, mais quelques années à utiliser FreeBSD ne m'a pas du tout convaincu.
[^] # Re: subjectif
Posté par Pierre-Alain TORET (Mastodon) . Évalué à -1.
Marrant, je n'ai jamais compris la manie qu'à Debian de démarrer les services installés avec une conf par défaut (qui ne correspond pas à mes besoins dans 100% des cas).
En fait que ce soit à partir des ports ou à directement avec pkg et les dépôts binaires, tu manipules la même base de données, donc c'est logique. Je pense que c'est la même chose sur Debian, si tu installes un paquet via dpkg et qu'ensuite tu fais apt update, si ce paquet existe dans les dépôts distants, il sera mis à jour.
L'alternative c'est de maintenir son propre dépôt et de construire les paquets à partir de l'arbre des sources des ports à l'aide de poudriere par exemple.
[^] # Re: subjectif
Posté par Zenitram (site web personnel) . Évalué à -1. Dernière modification le 25 janvier 2022 à 21:06.
Marrant, je n'ai jamais compris la manie qu'ont certaines personnes de critiquer les choix par défauts en comparant à leur propre cas comme si leur cas était représentatif et que les mainteneurs seraient trop idiots de ne pas prendre leur cas comme référence.
[^] # Re: subjectif
Posté par Pierre-Alain TORET (Mastodon) . Évalué à 2.
La critique adressée à FreeBSD par l'auteur du poste auquel je réponds est du même ordre (il faut tout faire à la main, c'est la façon de faire de FreeBSD et ça ne me plait pas, les mainteneurs FreeBSD sont trop idiots pour automatiser tout ça), mais comme ça va dans le sens de ce que tu penses, ça doit moins te choquer.
[^] # Re: subjectif
Posté par Zenitram (site web personnel) . Évalué à -2. Dernière modification le 25 janvier 2022 à 21:56.
La critique était centrée sur la partie "qui ne correspond pas à mes besoins dans 100% des cas" dont on se fout complet car on ne parle pas de "mes besoins". Si critique il y a, il faut la faire en fonction de ce qu'a les mainteneurs, donc plein de gens et pas son perso. Ici, on a l'impression d'une personne qui a besoin de son cas perso pour critiquer et que donc c'est bon dans le cas général et du coup la défense de BSD devient une défense de Debian (et par la même occasion un critique de BSD) sans oser l'accepter…
Ramener à ce que je pense est hors sujet.
La remarque a été faite, ça ne vaut pas plus que ça, passons.
[^] # Re: subjectif
Posté par claudex . Évalué à 7.
Ah mais c'est une raison tout à fait valable. Et même "je préfère bosser sous freebsd" est tout à fait valable. Mais il ne faut pas faire des comparaisons bancales.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.