ZFS, Canonical et GPL

Posté par . Édité par ZeroHeure et Benoît Sibaud. Modéré par tankey. Licence CC by-sa
69
1
mar.
2016
Justice

Il y a quelques semaines, Canonical annonçait en fanfare que le support ZFS serait disponible par défaut dans Ubuntu 16.04 et deviendrait la solution de choix pour containers et virtualisation. Si face à cette annonce, on pouvait se réjouir de voir apparaître un support officiel de ZFS dans Ubuntu, la méthode choisie par Canonical pour fournir cette technologie n'allait pas laisser longtemps la communauté indifférente.

Après vérification, le Software Freedom Conservancy publie un avis concernant ce support de ZFS et pointe du doigt une violation de la clause de redistribution du code sous licence GPL: les spécificités des licences ZFS (CDDLv1) et noyau Linux (GPLv2) empêchent la redistribution de binaires compilés les combinant, et Canonical a choisi de livrer le module du noyau pour ZFS (zfs.ko) précompilé au sein du paquet linux-image plutôt que de le gérer dans un paquet séparé et de le compiler via DKMS.

Est-ce que Canonical est réellement dans son droit?

Selon Canonical, le module zfs.ko n'est pas un travail dérivatif du noyau mais un travail dérivatif de OpenZFS et peut donc être redistribué sans devoir changer la licence vers la GPLv2.

Selon le Software Freedom Conservancy, le module zfs.ko est un travail dérivatif du noyau car il est le résultat de la combinaison des deux projets (le module zfs.ko ne peut être compilé sans les entêtes du noyau), et la GPLv2 nécessite que tout travail dérivatif (lié statiquement ou dynamiquement) soit distribué sous licence GPLv2.

Bien que le Software Freedom Conservancy ait exprimé l'espoir de régler cette situation à l'amiable, il ne semble pas pour le moment que Canonical ait décidé de faire marche arrière.

  • # Base de la position de Canonical

    Posté par (page perso) . Évalué à 10.

    L’argumentaire complet de Canonical vient du Software Freedom Law Center. Certains points sont intéressants mais avec un gros bémol sur leur interprétation de « l’esprit » des 2 licences qu’ils disent être compatibles (voir aussi).
    En gros les arguments sont les suivants :

    • Linus (et les développeurs noyau ?) ont déjà déclaré publiquement que l’import d’un système de fichier issu d’un autre OS n’en faisait pas un travail dérivé de Linux (cas d’AFS).
    • La distribution des binaires en GPLv2 uniquement ne pose pas de problème (CDDLv1 permet de distribuer des binaires sous une autre licence).
    • Les sources Linux contienne déjà du code originellement licencié sous d’autres licences libres (non copyleft) dont les fichiers individuels gardent la licence original afin de permettre au projet amont de récupérer les améliorations ou corrections créées par les développeurs Linux.
    • L’esprit des 2 licences étant le même, tout devrait bien se passer…

    Le dernier point est à mon avis très litigieux. Et même si on aimerait tous voir ZFS intégré (au moins le temps que btrfs finisse de sécher) à nos distributions, ce n’est pas en y croyant très fort que les licences vont devenir compatibles.

    Après, Canonical cherche peut-être juste à pousser Oracle à réagir pour faire bouger les lignes…

    • [^] # Re: Base de la position de Canonical

      Posté par . Évalué à 7.

      au moins le temps que btrfs finisse de sécher

      Je ne comprends pas ce qui bloque, il ne semble plus beaucoup bouger (on a quitté la phase de développement intensive) et malgré ça depuis 2 ans c'est zfs qui a toutes les faveurs (alors que zfs est bien plus vieux que ça).

      Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

      • [^] # Re: Base de la position de Canonical

        Posté par (page perso) . Évalué à 10.

        À ma connaissance, Btrfs n'a pas encore été officiellement annoncé comme stable.

      • [^] # Re: Base de la position de Canonical

        Posté par . Évalué à 7.

        Je ne comprends pas ce qui bloque, [btrfs] ne semble plus beaucoup bouger (on a quitté la phase de développement intensive)

        Il est même utilisé en production dans quelques coins, notamment sur certains téléphones.

        et malgré ça depuis 2 ans c'est zfs qui a toutes les faveurs (alors que zfs est bien plus vieux que ça).

        D'un autre côté, une vieux système de fichier, ça a un côté rassurant, surtout que Sun s'est toujours bien débrouillé pour les IO.

        • [^] # Re: Base de la position de Canonical

          Posté par (page perso) . Évalué à 7.

          notamment sur certains téléphones.

          Malheureusement pas toujours avec succès.

          Chez jolla, le disque est sous-dimenssionné par rapport a ce que nécessite btrfs, et les utilisateurs qui ont trop rempli leur téléphone ont rencontré lenteur et blocage… La réponse qui a été donnée nécessite malheureusement de mettre les mains dans les rouages du téléphone.

        • [^] # Re: Base de la position de Canonical

          Posté par . Évalué à 1.

          D'un autre côté, une vieux système de fichier, ça a un côté rassurant

          Un peu comme ext?

      • [^] # Re: Base de la position de Canonical

        Posté par (page perso) . Évalué à 8.

        ZFS est stable depuis des lustres, et il est aussi facilement portable, et porté sous Illumos, FreeBSD, NetBSD, Linux et même MacOSX (quoique pour ce dernier je crois que c'est un peu mort). Btrfs lui n'est pas encore déclaré stable, n'est pas portable et ne fonctionne que sous Linux. Le choix est vite fait.

        • [^] # Re: Base de la position de Canonical

          Posté par (page perso) . Évalué à 4.

          Btrfs lui n'est pas encore déclaré stable

          Les fonctions un peu avancées sont même carrément incomplètes.
          RAID5/6 est archi pas terminé. Même RAID1 n'est pas au niveau de DM-RAID (mais il est plus rapide).
          La déduplication en temps réel ne fonctionne pas, mais ce n'est probablement pas un problème vu le peu de gain apporté.

          • [^] # Re: Base de la position de Canonical

            Posté par . Évalué à 3. Dernière modification le 08/03/16 à 11:26.

            Question : en adoptant le point de vue "faire une chose et le faire bien" cher aux systèmes *NIX, est-ce une bonne chose d'intégrer la gestion du RAID (=DM-RAID) et la gestion des volumes logiques (= LVM) directement dans le système de fichiers ?

            J'ai le sentiment que ça va au-delà de ce qu'un système de fichiers est censé faire, mais je n'ai pas d'argument technique, ce n'est qu'un ressenti.

            Des réflexions à ce sujet ?

            Merci à ceux qui répondront

            • [^] # Re: Base de la position de Canonical

              Posté par . Évalué à 4.

              Philosophiquement, je dirai non.

              Mais donner cette gestion à un FS ( qui n'est plus vraiment un FS simple mais plutôt un gestionnaire de volume au sens large ) permet de lui donner des capacités qu'il ne pourrai pas avoir autrement ou que la gestion serait plus difficile ou incompléte. Je pense notamment à la déduplication et à certaines fonctionnalité du snapshot.

              D'un point vue admin, cela réduit aussi les interfaces et il y a moins de couche, donc potentiellement moins de problème.

              Après philosophiquement, si on prend ZFS et BTRFS comme des gestionnaires de volume complets tout comme Ceph ou autre, ça me va.

            • [^] # Re: Base de la position de Canonical

              Posté par . Évalué à 6.

              En version courte : la reconstruction d'un raid5 DM-raid demande de se faire tout le disque, ce qui prend des heures, la reconstruction d'un raid5 FS prend en compte uniquement les données valides.

              En version longue, tu comprends bien le problème du 'dependancies hell' si un jour tu as joué avec les plugins Eclipse ou le tryptique linux/gcc/libC pour faire un cross compilateur vers une cible embarquée. Plus tu as de couches, plus tu as de probabilité d'une incompatibilité avec certaine combinaison de version.

              Cela dépend en fait beaucoup de la stabilité des interfaces. Si les interfaces sont stables, les couches se défendent sinon…

              Dans les FS, les raids deviennent trop gros pour se corriger simplement, les SSD ont changé totalement les optimisations d'accès au disque (plus de têtes mais un trim, à gérer)… On a changé le hard en dessous, ce qui implique de changer les interfaces logiciels, ce qui rend le modèle en couche moins efficace.

              "La première sécurité est la liberté"

            • [^] # Re: Base de la position de Canonical

              Posté par (page perso) . Évalué à 8. Dernière modification le 08/03/16 à 14:20.

              ta vision des choses est correcte quand chaque couche est bien isolée et que tu peux la remplacer sans affecter les autres couches.
              C'est le cas en réseau avec les couches les plus basses : tu peux changer ton Ethernet par du Wifi sans affecter les logiciels.

              En revanche, le RAID, les volumes logiques et le système de fichiers doivent savoir comment chacun fonctionne pour avoir des performances correctes (c'est d'ailleurs pour ça que les cartes RAID matérielles sont déconseillées avec ZFS). Un SSD, un RAID matériel ou un disque SATA classique (la couche la plus basse) ne demanderont pas les mêmes choses au système de fichiers (la couche la plus haute) pour être performants.
              Peut-être que le LVM aura aussi envie de connaître l'état des systèmes de fichiers pour faire ses volumes logiques (avec les fichiers creux qui ont une taille réelle plus petite que celle affichée ou les données dédupliquées, les fichiers compressés, les anciennes versions de fichier, la taille réellement utilisée n'est plus la même que celle théoriquement utilisée).

              Accessoirement, on peut considérer que l'ensemble des trois forme une seule couche. En tant qu'utilisateur, ça ne me choque pas plus que ça d'avoir un seul logiciel qui se débrouille pour prendre mes disques durs et me découper ça en une série de partitions, en mettant du LVM ou du RAID s'il veut.

            • [^] # Re: Base de la position de Canonical

              Posté par (page perso) . Évalué à 4.

              en adoptant le point de vue "faire une chose et le faire bien" cher aux systèmes *NIX, est-ce une bonne chose d'intégrer la gestion du RAID (=DM-RAID) et la gestion des volumes logiques (= LVM) directement dans le système de fichiers ?

              Je trouve que c'est un peu comme le principe des micro-noyaux : sur le papier c'est top, mais dans les faits personne n'a fait mieux que les noyaux monolithiques. Je simplifie mais en gros c'est ça.

              Pour le stockage c'est pareil : il est séduisant (et plus simple à coder) de séparer les fonctions, mais jusqu'à présent personne n'a fait mieux que zfs et btrfs question performances et efficacité.

              En regardant comment ça fonctionne sous le capot on comprend facilement que l'approche de zfs et de btrfs est plus adaptée, mais bien plus complexe au niveau du code. On comprend également qu'on pourrait garder le fonctionnement par couches, seulement il faut que des gens s'y mettent et c'est un chantier très important sur un sujet très sensible, et nécessitant des adaptations importantes partout dans la pile du stockage.

    • [^] # Re: Base de la position de Canonical

      Posté par . Évalué à 2.

      L'esprit des 2 licences est très différent, puisque la cddl autorise le brevet logiciel sur une portion de code, sans avoir besoin de signaler l'utilisation du brevet.

      Surtout qu'il s'agit d'Oracle, je ne m'inspirerai pas de leur code.

      • [^] # Re: Base de la position de Canonical

        Posté par (page perso) . Évalué à 2.

        Non il s'agit de Sun, racheté par Oracle. Oracle a abandonné OpenSolaris peu après le rachat et n'a pas touché au code libéré de ZFS (s'ils avaient libéré du code après le rachat on aurait le chiffrement à la volée dans ZFS).

        • [^] # Re: Base de la position de Canonical

          Posté par . Évalué à 2.

          Y'a deux versions de ZFS ?

          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

          • [^] # Re: Base de la position de Canonical

            Posté par . Évalué à 1.

            ZFS date de Solaris 10 / Open Solaris, c'était avant le rachat de Sun par Oracle.

            Mais aujourd'hui le code "appartient" à Oracle, alors pour moi c'est du pareil au même.

          • [^] # Re: Base de la position de Canonical

            Posté par (page perso) . Évalué à 3.

            Il me semble que Oracle ne publie plus les sources de ZFS. C’est pourquoi été créé OpenZFS et aussi pourquoi il y a un saut de version en passant de la version 28 à 5000.

            La différence repose surtout sur des fonctionnalités activées ou non et pas forcément compatibles avec l’implémentation d’Oracle.

            C’est ce que je comprend en lisant le wiki officiel :

            http://open-zfs.org/wiki/FAQ#Are_storage_pools_created_by_OpenZFS_compatible_with_ZEVO_and_with_Oracle.C2.AE_Solaris.3F

          • [^] # Re: Base de la position de Canonical

            Posté par (page perso) . Évalué à 3.

            Y'a deux versions de ZFS ?

            Oui. Celle développée ou pas par Oracle (Je ne sais pas trop ce qu'ils font de Solaris) et OpenZFS qui provient du code libéré par SUN.

            Il y a en plus diverses fonctionnalités à la marge telles que l'export iscsi auto, le scan antivirus, l'insensibilité à la casse qui ne sont pas forcément implémentées par tous les systèmes ou implémentés comme des noop.

            Tout cela est géré par des feature flags qui permettent de vérifier la compatibilité. Donc dans le pire des cas l'import de ton zpool échoue

  • # Un potentiel sacré bourbier

    Posté par . Évalué à 3.

    Canonical risque de se faire taper sur les doigts s'ils ne déplacent pas ce module.
    Qui plus est, je ne pense pas que cela soit tant gênant de mettre ce module à part puisque ce n'est pas monsieur tout le monde qui a besoin de ZFS.

    Pour savoir, comment les autres distributions ont-elles géré l'ajout de ZFS ?
    Sinon existe-t-il sur Linuxfr un article résumant rapidement les différentes licences ? Je sais qu'un tel document existe sur le site du projet GNU mais un autre "point de vue" ne pourrait pas être une mauvaise chose.

    • [^] # Re: Un potentiel sacré bourbier

      Posté par (page perso) . Évalué à 10.

      Sinon existe-t-il sur Linuxfr un article résumant rapidement les différentes licences ?

      Quand le diable se cache dans des détails précis, ce n'est pas le moment de travailler sur des résumés de seconde main. :)

      Adhérer à l'April, ça vous tente ?

    • [^] # Re: Un potentiel sacré bourbier

      Posté par (page perso) . Évalué à 10.

      Pour savoir, comment les autres distributions ont-elles géré l'ajout de ZFS ?

      Tout le monde s'oriente vers la même solution que pour nvidia il me semble, c'est à dire un paquetage dkms. Lors de l'installation, un bout est recompilé sur le poste même donc il n'y a plus de problème de licence puisque c'est l'utilisateur qui fait cette étape chez lui et pour lui. Bref, il n'y a pas de diffusion d'un programme binaire complet.

      • [^] # Re: Un potentiel sacré bourbier

        Posté par . Évalué à 7.

        C'est ce que je ne comprends pas dans cette histoire: qu'est-ce qui empêche Canonical de distribuer ZFS par DKMS, vu que c'est de toute manière totalement transparent pour l'utilisateur lambda?

        • [^] # Re: Un potentiel sacré bourbier

          Posté par (page perso) . Évalué à -2.

          Que ce n'est pas conseillé côté sécurité d'avoir un compilateur sur un serveur de production ?

          • [^] # Re: Un potentielsacrébourbier

            Posté par (page perso) . Évalué à 3.

            Pourquoi ?

            Si c'est parce que l'attaquant pourrait compiler ses outils, il pourrait aussi les forger avec ses petits doigts potelés.

            • [^] # Re: Un potentielsacrébourbier

              Posté par . Évalué à 1.

              P'tet parce que si on arrive à s'infiltrer sur une machine, avoir accès à un compilo pour planquer ses méfaits est une bonne chose?

              Pour rappel, un binaire exécutable comparé à un script (peu importe le langage, python, perl, sh, JS….) c'est:

              • moins lourd en mémoire
              • plus rapide

              et donc ça a plus de chances de passer inaperçu. Sans parler du fait qu'un binaire peut être transmis via un source obfusqué, "lent" à la compilation mais indétectable (au chargement réseau) par un AV (vous voulez un exemple du code obfuscation contest?) à condition d'être compilé en local, alors qu'un truc exécutable c'est quand même plus grillé (référence à des lib considérées sensibles).

              Accessoirement, nos p'tits systèmes étant codés en C pur (qui a un init codé avec les convention pascal pour les string, par exemple?) un compilo C permets d'exposer toutes les failles potentielles d'une glibc un peu ancienne.

              • [^] # Re: Unpotentielsacrébourbier

                Posté par (page perso) . Évalué à 4.

                Pour rappel, un binaire exécutable comparé à un script (peu importe le

                Un compilateur n'est pas le seul moyen de produire un binaire exécutable.

                • [^] # Re: Unpotentielsacrébourbier

                  Posté par . Évalué à 2.

                  C'est le plus simple, je trouve. En dehors du téléchargement bien sûr (mais est-ce vraiment produire?).

                  • [^] # Re: Unpotentielsacrébourbier

                    Posté par . Évalué à 3.

                    Tu peux écrire un assembleur en python ou en shell si tu veux (voir tout un compilateur, mais ça demande un peu plus de travail).

                    Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

            • [^] # Re: Un potentielsacrébourbier

              Posté par . Évalué à 0.

              Avec cette logique, on pourrait dire que si il n'a pas les droits root, il pourrait les acquérir…

          • [^] # Re: Un potentiel sacré bourbier

            Posté par . Évalué à 4.

            Si le pirate le désire il va bootstraper gcc…

        • [^] # Re: Un potentiel sacré bourbier

          Posté par (page perso) . Évalué à 2.

          C'est la soluce choisi par Débian mais j'ai lu (je ne sais plus ou) qu'Ubuntu ne souhaite pas mettre la chaîne de compilation sur un poste donc évite au maximum DKMS.

          Bilan : de l'énergie perdues puisque Debian et Ubuntu vont faire deux paquetages complètement différents.

          • [^] # Re: Un potentiel sacré bourbier

            Posté par (page perso) . Évalué à 1.

            Oui, enfin les noyaux sont déjà différents donc ça ne va pas changer grand chose en pratique de ce point de vue.

            • [^] # Re: Un potentiel sacré bourbier

              Posté par (page perso) . Évalué à 3.

              Il veut dire quoi le ckt dans les noyaux Debian ?

              « 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: Un potentiel sacré bourbier

            Posté par . Évalué à 8.

            C'est la soluce choisi par Débian

            Debian*

            Vous pouvez moinsser ;)

            • [^] # Re: Un potentiel sacré bourbier

              Posté par . Évalué à -10.

              Te moinsser pour une remarque inutile? Ok. (selon ma logique, je serai moi-même vite fait à -10, mais si ça peut te permettre de rendre compte de ta connerie, tant mieux)

              • [^] # Re: Un potentiel sacré bourbier

                Posté par . Évalué à 9.

                Ah bon, corriger une faute c'est de la connerie. Bravo.

                "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                • [^] # Re: Un potentiel sacré bourbier

                  Posté par . Évalué à -10.

                  Corriger une faute dans un commentaire, oui c'est de la connerie de Grammar Nazi.
                  On s'en fout.
                  Il aurait pu envoyer un message privé pour ca.
                  Oui moi aussi je pourrais le faire, mais vu qu'on est a polluer avec des commentaire inutiles hein allons y gaiment !

                  • [^] # Re: Un potentiel sacré bourbier

                    Posté par . Évalué à 10.

                    Il aurait pu envoyer un message privé pour ca.

                    • Aller sur son blog qui n'a pas bougé depuis 7 ans
                    • Ne pas y trouver d'adresse (ni mail, ni XMPP, ni autre)
                    • Se rendre compte que tu dis n'importe quoi…

                    Oui moi aussi je pourrais le faire[…]

                    Te taire ce serait encore plus simple :)

                    Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                    • [^] # Re: Un potentiel sacré bourbier

                      Posté par . Évalué à -10.

                      Au temps pour moi, je pensais que les pseudos etaient clickable pour pour envoyer des mp comme dans tout forum du genre un peu moderne. (n'activant pas le Javascript sur linuxfr et n'ayant jamais eu l'intention d'envoyer un mp, je ne me suis en fait jamais apercu que c'etait aussi archaique que ca)

                      Mais ca change rien au fond du probleme: on s'en fout, c'est de la pollution les posts de correction orthographique, ca n'apporte rien a qui/quoi que ce soit.

                      Te taire ce serait encore plus simple :)

                      Toi aussi figure toi :)

                      • [^] # Re: Un potentiel sacré bourbier

                        Posté par . Évalué à 10.

                        c'est de la pollution les posts de correction orthographique, ca n'apporte rien a qui/quoi que ce soit.

                        Ça apporte aux gens qui ont l'once d'intelligence nécessaire à comprendre que mieux écrire est équivalent à mieux communiquer, ça peut leur permettre de s'améliorer.
                        En tant que telle, déjà, l'amélioration de soi est un but noble, mais aider les autres à s'améliorer est une action altruiste et positive.

                        En ce sens les posts sur l'orthographe, la grammaire et les fautes de français en général sont positifs, et dénotent l'intérêt des gens qui les font pour l'amélioration générale de tout les lecteurs, de façon désintéressée, altruiste et généreuse.

                        Il convient donc de les remercier.
                        Et comme moi d'être incompréhensif face à ceux qui dénigrent, voire qui, à ton image, pensent que d'écrire correctement est une perte de temps inutile, et qui critiquent ce travail d'entraide productif, collaboratif, visant à faire de chacun d'entre nous des gens meilleurs. Ce qui est un comble quand on baigne comme ici dans le logiciel libre, soit l'ensemble le plus hétérogène, complexe, complet et merveilleux de travail collaboratif au monde.

                        Yth.

                        • [^] # Re: Un potentiel sacré bourbier

                          Posté par . Évalué à 10.

                          Il convient donc de les remercier.

                          Hum tu fais des généralités. Il y a aussi un bon paquet de trolls qui préfèrent attaquer la forme d'un message que son contenu. C'est aussi une bonne façon de rabaisser l'autre et de se flatter soit même.

                          Je « pertine » systématiquement les gens qui reprennent mon ortographe sur linuxfr, mais je ne dirais pas que tous les gens qui reprennent l'orthographe sur internet devraient être béatifier.

                          Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                          • [^] # Re: Un potentiel sacré bourbier

                            Posté par . Évalué à 10.

                            devraient être béatifier.

                            béatifiés.

                            Merci d'avance pour ton pertinentage :-)

                            ­La faculté de citer est un substitut commode à l'intelligence -- Somerset Maugham

                        • [^] # Commentaire supprimé

                          Posté par . Évalué à -10. Dernière modification le 07/03/16 à 20:10.

                          Ce commentaire a été supprimé par l'équipe de modération.

                        • [^] # Re: Un potentiel sacré bourbier

                          Posté par . Évalué à -10.

                          Ça apporte aux gens qui ont l'once d'intelligence nécessaire à comprendre que mieux écrire est équivalent à mieux communiquer,

                          logique deficiente. Un sophisme sans faute reste un sophisme.
                          Un raisonnement logique avec des fautes d'ortographe/grammaire reste juste.

                          A moins que pour toi, communiquer consiste surtout a raconter des conneries je prefere cent fois celui qui prend son temps pour tenir un raisonnement logique que d'ecrire correctmeent (qui est une competence tres peripherique ne servant que tres peu dans la vie courante)

                          Enfin sauf pour les plus inutiles, les grattes papiers, les politiciens etc etc. Bref des nuisibles en general..

                          En tant que telle, déjà, l'amélioration de soi est un but noble, mais aider les autres à s'améliorer est une action altruiste et positive.

                          Franchement, tu fais chier les gens a les reprendre a l'oral si ils prononcent mal un mot ? J'en doute, te prendre un pain dans la tronche au bout de la dixiemme correction alors qu'un type essaye de faire passer une idee t'arriverait trop vite je pense.
                          Je commence a penser que tu trolls tellement c'est gros.

                          En ce sens les posts sur l'orthographe, la grammaire et les fautes de français en général sont positifs, et dénotent l'intérêt des gens qui les font pour l'amélioration générale de tout les lecteurs, de façon désintéressée, altruiste et généreuse.

                          Non la c'est sur tu trolles :)

                          • [^] # Re: Un potentiel sacré bourbier

                            Posté par . Évalué à 4.

                            Franchement, tu fais chier les gens a les reprendre a l'oral si ils prononcent mal un mot ?

                            Oui, je le fais régulièrement.

                            J'en doute, te prendre un pain dans la tronche au bout de la dixiemme correction alors qu'un type essaye de faire passer une idee t'arriverait trop vite je pense.

                            Détrompe toi, tout le monde ne cherche pas à rester dans son ignorance, beaucoup de gens apprécient d’apprendre et de s’améliorer. C’est d’ailleurs mon cas, et je remercie les correcteurs qui m’ont permis d’énorme progrès en orthographe… même si ça ne se voit pas quand on me relie :'( mais j’ai espoir qu’un jour ce soit mieux.

                          • [^] # Re: Un potentiel sacré bourbier

                            Posté par . Évalué à 10.

                            Un raisonnement logique avec des fautes d'ortographe/grammaire reste juste.

                            Non. C'est faux en informatique avec un langage de programmation, c'est faux en mathématique - je ne crois pas avoir besoin d'expliquer ces deux cas : une faute dans ton code c'est un bug que tu dois corriger -, et en fait c'est faux aussi à l'écrit.
                            Trompe-toi de la mauvaise virgule et tu renverses le sens de ta phrase ou tu le changes complètement, donc ton raisonnement « écrit » n'est plus celui que tu avais en tête, ce qui est écrit n'a donc aucune raison d'être juste, c'est un autre raisonnement, pas le tiens, pas celui que tu voulais écrire.

                            Raconter des conneries ou des choses intelligente n'a pas de lien avec l'orthographe, la grammaire, la maîtrise du français, on peut faire les deux ou aucun des deux, ou juste l'un des deux. C'est d'ailleurs l'idée que tu défends il me semble.
                            Par contre si tu veux communiquer ton idée, alors la maîtrise de la langue est importante.

                            À l'instar du HTML la langue française est tolérante, et sa syntaxe a une certaine souplesse (bien plus que dans beaucoup d'autres langues). Mais à l'instar du HTML, si tu écris n'importe comment, ce qui sera communiqué, à ton prochain ou à ton navigateur, ne sera pas ce que tu voulais communiquer.
                            Une coquille, une inversion de lettres, gêneront peu ou pas la lecture, mais un message truffé de fautes est incompréhensible, c'est sûr qu'on va mal comprendre au moins une partie.
                            Et forcer les lecteurs à deviner le propos réel derrière est un certain manque de respect pour eux. D'autant plus que si l'accès à un message est plus difficile il sera mécaniquement moins lu, donc la qualité de la communication diminue de fait avec la qualité de la langue.
                            Il y a bien sûr un effet de seuil, une langue maîtrisée à la perfection ne fera pas réellement mieux passer un message qu'une langue simplement correcte, c'est en dessous que ça se gâte.

                            J'aime beaucoup cet exemple simple :
                            - Allons manger grand-mère.
                            - Allons manger, grand-mère.
                            Les deux sont syntaxiquement corrects, mais ne veulent pas du tout dire la même chose !

                            Franchement, tu fais chier les gens a les reprendre a l'oral si ils prononcent mal un mot ?

                            Là c'est toi qui trolle, on parle ici de corriger des fautes écrites, restons dans le sujet si tu veux bien…
                            Mais bon, si le type emploie des mots à la place d'autres, rapidement je vais l'interrompre pour lui dire que je ne comprend pas ce qu'il veut dire.

                            Non la c'est sur tu trolles :)

                            Pas vraiment, je fais dans le lyrisme, j'en rajoute une couche, exprès bien sûr, mais dans le fond je crois en ce que je dis. C'est noble d'apprendre et d'enseigner, de s'améliorer et d'aider les autres à s'améliorer.
                            Je suis indécrottablement optimiste, je ne dis jamais « je ne parle pas aux cons, ça les instruit » mais bien « je parle aux cons, ça les instruit ».

                            Et certes, Michel Barret juste au dessus indique que parfois ces arguments sont utilisés pour détourner le sujet, et aussi un terrain d'attaque. Critiquer la forme pour détourner l'attention du fond c'est déloyal.
                            Mais soyons honnêtes : ça ne se passe généralement pas comme ça ici, il y a un fil de discussion sur l'orthographe des dépêches, tout est regroupé dedans, les modérateurs corrigent, et il suffit d'ignorer ce fil et de lire le reste pour avoir une discussion sur le fond sans se préoccuper de la forme.
                            Donc les messages concernant l'orthographe (grammaire, conjugaison, syntaxe, ponctuation, etc.) sont positifs sur LinuxFR parce que fait la majeure partie du temps dans un but d'amélioration générale. Il convient donc de les encourager,ou au moins de les laisser faire.

                            • [^] # Re: Un potentiel sacré bourbier

                              Posté par . Évalué à 2.

                              J'aime beaucoup cet exemple simple :
                              - Allons manger grand-mère.
                              - Allons manger, grand-mère.
                              Les deux sont syntaxiquement corrects, mais ne veulent pas du tout dire la même chose !

                              Tout est question de personnage : cela dépend si l'on est le petit chaperon rouge ou le grand méchant loup; ce dernier ayant tout intérêt à entretenir la confusion. :-)

                              Hors les problématiques de ponctuation, les accents sont aussi porteur de sens et une erreur peut tout autant prêter à confusion. Par exemple, il y a des jours où je me demande si notre gouvernement croît en incompétence, ou bien s'il croit en incompétence. Quoique, dans une forme fléchie, cela permet d'assimiler la croissance à de la croyance. :-Þ

                              Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

                              • [^] # Re: Un potentiel sacré bourbier

                                Posté par . Évalué à 4.

                                Nan mais arrête, tu joues carrément avec l'écrit là !

                                Tu serais pas un « petit nobliaux fils de bourgeois trop con toi » ?
                                Tu fais ça que pour ton statut social avoue, juste pour ça !
                                En plus, t'es un grammar nazi. Quoi que ça puisse bien vouloir dire d'ailleurs.

                                T'imagine quoi ? Des gens qui joueraient avec les mots, leurs sens, pour faire passer des messages indirectement, ou pire pour s'amuser ou amuser les autres !
                                Un truc de dingue, faudrait carrément arrêter le langage écrit c'est trop dangereux, complètement séditieux, et ça entretient les différences de classes sociales.
                                D'ailleurs, comme l'écrivait Socrate : « J'écris donc je m'élève au dessus de la plèbe ».

                                Yth.

                                • [^] # Re: Un potentiel sacré bourbier

                                  Posté par . Évalué à 2.

                                  Nan mais arrête, tu joues carrément avec l'écrit là !

                                  Pour nous recentrer sur le sujet de l'article, et ne point prolonger le hors-sujet, on peut bien reconnaître que jouer avec les mots comme ne pas respecter leur orthographe sont bien des licences de penser que l'on peut accorder à tout un chacun. Question : sont-elles incompatibles ? doit-on s'attendre à un procès entre les deux parties en présence (surtout si l'on en vient aux mains) ou peut-on espérer un accord à l'amiable ?

                                  Tu serais pas un « petit nobliaux fils de bourgeois trop con toi » ?

                                  L'administration fiscale a encore moins d'humour. On a retrouvé, dans les archives de la police de Paris, deux lettres de Boris Vian à son percepteur, dont la seconde est :

                                  Mon Cher Contrôleur,

                                  Je suis un grand feignant, mais j'y comprends rien dans tous ces bouts de papier impossibles. Voilà ma déclaration, il y a un peu de retard; mais je suis plein de bonnes intentions.

                                  Encore mille excuses pour ce retard excusable et répandez mes bénédictions autour de vous.

                                  Je ne sais si le choix orthographique pour « feignant » a été relevé par le destinataire, mais le policier qui archiva les lettres nota dans son rapport : « On affirme que ces deux lettres, dont la dernière était rédigée sur l'imprimé de déclaration de revenus, auraient coûté, du point de vue fiscal, très cher à leur auteur. » source

                                  Vian était sans doute un petit nobliaux fils de bourgeois cherchant à échapper à l'impôt.

                                  :-)

                                  Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

                            • [^] # Re: Un potentiel sacré bourbier

                              Posté par . Évalué à -10.

                              Non. C'est faux en informatique avec un langage de programmation, c'est faux en mathématique - je ne crois pas avoir besoin d'expliquer ces deux cas :

                              Fail logique, comme je l'ai deja dit dans un commentaire du meme type:
                              Les "langages" mathematique et informatique ne sont pas des langages de communication.
                              Mais ca ne fait que confirmer tes problemes de raisonnement au sujet des langues humaines.

                              • [^] # Re: Un potentiel sacré bourbier

                                Posté par . Évalué à -10.

                                Trop tard pour modifier, mais le simple fait de dire qu'un raisonnement bon devient faux si il est mal ecrit est ridicule en soit:)

                                Si il est mal écrit, alors il est faux le raisonnement mathematique hein :) de base. Parce que encore une fois, les maths (et donc l'info qui en derive, puisque l'info ce n'est guere que de la logique booleene pour encore un petit moment..) n'est PAS un langage de communication.

                                Enfin…a depends, si tu me sors qu'un marteau est un langage de communication…ok…d'accord…

                                Tu me diras ce peux effectivement servir a passer certaines idees avec une certaine efficacite :)

                                • [^] # Re: Un potentiel sacré bourbier

                                  Posté par . Évalué à 5.

                                  Parce que encore une fois, les maths n'est PAS un langage de communication.

                                  C’est marrant, j’avais compris justement que pour les tentatives de communication extraterrestre on utilisait les maths comme langage universel.
                                  Les messages émis par radio télescope par exemple on un nombre de bit divisible que par 2 nombres premiers. Si on décompose le message en lignes d’un des deux nombres on obtient une image. Les plaques sur les sondes pionneer… sont des bons exemples également.

                                  • [^] # Re: Un potentiel sacré bourbier

                                    Posté par . Évalué à 2. Dernière modification le 09/03/16 à 10:07.

                                    Laisse tomber. Il est dans son monde et sa bêtise, et il n'en démordra pas.

                                    "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                                    • [^] # Re: Un potentiel sacré bourbier

                                      Posté par . Évalué à 3.

                                      A un point tel qu'il dis que je dis une connerie et pour le prouver répète exactement ce que je dis…

                                      Si il est mal écrit, alors il est faux le raisonnement mathematique hein :)

                                      C'est exactement le cœur du propos ici : tu as un raisonnement parfait dans ta tête, tu fais une faute au passage à l'écrit, et ton raisonnement écrit est faux.
                                      Et c'est valable pour les maths et le français…

                                      Hallucinant hein à quel point il n'écoute rien et se contente de dire « naaan t'as tort parce que t'as tort, je m'en fous du reste ! »

                                      Bref…

                                      Yth.

                                      • [^] # Re: Un potentiel sacré bourbier

                                        Posté par . Évalué à -10.

                                        Hallucinant hein à quel point il n'écoute rien

                                        Moi ce qui m'hallucine, c'est ton tel manque de logique que tu arrives a te persuader que je dis la meme chose que toi.
                                        Seulement ca je peux pas le changer par la parole….et comme tu penses serieusement que tes sophismes sont des raisonnements parce que tu les ecris bien ..que dire…

                                  • [^] # Re: Un potentiel sacré bourbier

                                    Posté par . Évalué à -10.

                                    C’est marrant, j’avais compris justement que pour les tentatives de communication extraterrestre on utilisait les maths comme langage universel.

                                    On pourrait utiliser un marteau et un burin aussi…
                                    Les maths ne sont pas un langage de communication, mais un simple support.
                                    Un erreur en mathematique va faire completemetn foire un algo.
                                    Une erreur d'ortographe ne changera absolument rien au sens du texte dans les plupar des cas.

                                    La preuve vous me comprenez parfaitement depuis le debut.

                                    • [^] # Re: Un potentiel sacré bourbier

                                      Posté par . Évalué à -10.

                                      Accesoirement: le langage de communication utilise c'est l'image.

                                      Les maths c'est le papier et le crayon pour la dessiner.

                                      Encore une fois vous confondez les deux…

                          • [^] # Re: Un potentiel sacré bourbier

                            Posté par (page perso) . Évalué à 5.

                            je prefere cent fois celui qui prend son temps pour tenir un raisonnement logique que d'ecrire correctmeent

                            Les gens font des suggestions d’orthographe pour permettre à celui qui écrit de tenir un raisonnement logique et de l’écrire correctement, pour permettre à celui qui écrit de ne pas devoir faire choisir ses lecteur entre la forme et le fond. Faire une suggestion d’orthographe, c’est dire « je veux que ton discours soit accessible à plus de monde, parce que tu le mérites », c’est dire « je veux que ton discours soit aussi facile à recevoir qu’il est sensé », c’est dire enfin « je veux que non seulement tu prononces ton discours, mais je veux aussi qu’il soit entendu ».

                            Faire une suggestion d’orthographe, c’est permettre à l’autre de ne pas avoir à choisir entre un raisonnement logique et une écriture correcte, c’est permettre à l’autre de ne pas avoir à faire choisir ses lecteurs entre un raisonnement logique et une écriture correcte, c’est permettre à l’autre de s’exprimer mieux et d’être entendu plus.

                            ce commentaire est sous licence cc by 4 et précédentes

                            • [^] # Re: Un potentiel sacré bourbier

                              Posté par . Évalué à -10.

                              à celui qui écrit de ne pas devoir faire choisir ses lecteur entre la forme et le fond. Faire une suggestion d’orthographe, c’est dire « je veux que ton discours soit accessible à plus de monde, parce que tu le mérites »

                              Quand la grammaire ou l'orthographe commence a modifier le sens d'une phrase, c'est deja un fail dans la communication.
                              Preuve irrefutable: une bonne partie de l'ortographe ou de la grammaire n'apparait absolument pas a l'oral.
                              Dont acte: l'ecrit n'est qu'une norme abstraite, sans logique, et sans utilite reele sinon a se faire coire intelligent ceux qui l'ont appris par coeur.

                              Pas pour rien que la maitrise de la langue fait bander les petits nobliaux et fils de bourgeois trop cons pour faire autre chose: ca au moins ils vont pouvoir l'apprendre par coeur, meme le plus con de leur rejeton pourra le faire.
                              ET voila pouquoi c'est pousse en avant.

                              Pas parce que ca a de l'importance, mais simplement pour maintenir le statut social d'une classe.

                              Il est fort amusant de constater a quel point non seulement cela fonctionne tres bien, mais a quel point ils sont aider par les couillons dans votre genre….

                              • [^] # Re: Un potentiel sacré bourbier

                                Posté par . Évalué à 10.

                                Preuve irrefutable: une bonne partie de l'ortographe ou de la grammaire n'apparait absolument pas a l'oral.
                                Dont acte: l'ecrit n'est qu'une norme abstraite, sans logique, et sans utilite reele sinon a se faire coire intelligent ceux qui l'ont appris par coeur.

                                Je m'inscris en faux contre une telle affirmation. J'en veux pour preuve cette extrait d'un discours de Gerard Huet Fondements de l'informatique, à la croisée des mathématiques, de la logique et de la linguistique. lors d'un colloque sur l'enseignement philosophique et les sciences.

                                On nous dit « il faut inculquer aux jeunes l’esprit scientifique ». Très bien, mais qu’est ce que ça veut dire au juste, au-delà d’une incantation un peu creuse ? Inculquer l’esprit scientifique ne se fait pas à coup de bourrage de crâne de connaissances scientifiques rebutantes, ce qui est au contraire la meilleure manière de faire fuir les élèves. De toutes façons, la science moderne est trop vaste et trop complexe pour que quiconque puisse tout connaître, on n’aura plus de Pic de la Mirandole, et c’est aussi bien. Par contre, on peut susciter la curiosité des élèves en mettant en valeur les figures de rhétorique développées par la science pour acquérir ces connaissances. Pour avoir prononcé ce terme de rhétorique devant vous, je devrais m’excuser, c’est un terme vieillot. Autrefois, il y avait des classes de rhétorique, et la notion de débat intellectuel était valorisée. Maintenant c’est terminé, on inculque des connaissances prédigérées, et la Science est imposée comme un prêche. On apprend par cœur des formules que l’on fait réciter, les exercices sont calibrés pour être résolus par application mécanique d’un cours bien saucissonné, l’esprit critique n’est pas encouragé. Ouvrons la fenêtre, discutons des méthodes qui permettent de raisonner droit, de comprendre comment poser des hypothèses, d’élaborer des conjectures, de chercher des contre-exemples. Ces méthodes sont transversales à toutes les matières enseignées, littéraires comme scientifiques. Il y a là un lien important entre philosophie et informatique, car la méthodologie informatique prolonge la rhétorique traditionnelle en tant que moyen légitime d’acquérir des connaissances. Ce sont ces préoccupations qui ont développé la logique, qui a finalement quitté la philosophie pour s’intégrer aux mathématiques, mais a perdu en passant sa finalité argumentative, qui est l’essence de la démarche scientifique. […]

                                Je vais prendre un autre exemple dans un domaine complètement différent, c’est l’analyse grammaticale dans la classe de français. Je ne sais pas si on fait encore beaucoup ça, mais de mon temps on décortiquait les phrases : toute phrase doit avoir un verbe, tout verbe doit avoir un sujet. Là, il y a un petit bout de raisonnement aussi. Comment est-ce que l’on obtient une phrase à partir d’un verbe ? Prenons d’abord un verbe intransitif. Un verbe intransitif a besoin d’un sujet pour exprimer son action. Donc, vous pouvez voir le rôle fonctionnel de ce verbe comme utilisant le syntagme nominal représentant le sujet pour construire la phrase représentant l’action. De même, un verbe transitif peut être vu comme une fonction qui prend son complément d’objet pour construire un syntagme verbal, se comportant comme un verbe intransitif. Vérifier que « le chat mange la souris » est une phase correcte devient un petit raisonnement où le verbe « mange » prend la souris pour construire « mange la souris », objet fonctionnel qui peut maintenant manger le chat, si je puis dire, pour donner la phrase. Le petit arbre de raisonnement, qui exprime la composition des deux fonctions en vérifiant leurs types, hé bien, c’est ce qu’on appelle l’analyse grammaticale de la phrase. Regardez de près, vous vous rendez compte que c’est exactement le même raisonnement que celui pour la machine à laver du cours de physique, avec deux étapes de modus ponens. L’analyse dimensionnelle devient l’analyse grammaticale. C’est important, en exhibant les procédés rhétoriques similaires on abstrait le raisonnement commun, pour lequel les deux disciplines fournissent des exemples concrets. Les deux exemples s’éclairent l’un l’autre, et on retient un procédé cognitif général qui peut servir pour toutes sortes d’autres investigations. En exhibant le procédé rhétorique commun, et en le réifiant dans deux disciplines supposées étanches l’une à l’autre, on apprend aux élèves que l’esprit scientifique transcende les matières enseignées et les présente comme des aventures intellectuelles cohérentes. Et puis, cela peut donner des idées. En classe de français on faisait de l’analyse grammaticale, mais on n’en faisait pas en classe d’anglais. Pourquoi ? Le même type de raisonnement s’applique, et on montre deux exemples du même phénomène, qui est ainsi mieux mémorisé. Par contre il y a des détails de grammaire qui ne sont pas les mêmes. Par exemple, en introduisant les paramètres morphologiques, on va pouvoir exprimer l’accord du verbe avec son sujet comme une contrainte sur les arbres d’analyse. En français comme en anglais. Par contre, l’adjectif est invariable en anglais, et donc ne s’accorde pas avec le nom qu’il qualifie. En mettant en lumière ces différences structurelles fondamentales, on éclaire les difficultés rencontrées par les élèves, les faux amis, les analogies erronées qui sont difficiles à déraciner. C’est important de le montrer en contraste avec le français. Parce que si vous leur apprenez l’analyse grammaticale du français, il y a une grande partie qu’ils vont pouvoir appliquer à l’anglais aussi, et les parties où cela ne s’applique pas, c’est justement les endroits où il faut faire attention à ne pas calquer d’une langue sur l’autre.

                                voir le texte aux pages 20 à 23

                                En d'autres termes, l'analyse grammaticale et morphologique d'une langue en révèle sa structure logique : comme le coup du verbe transitif qui revient à un double usage du modus ponens (si A alors B, or A, donc B). Pour illustrer cette exemple et son lien avec la logique et l'informatique (en réalité la théorie des types), je vais le coder (simplement) en OCaml

                                # let verb_trans verb ~suj ~comp =             
                                    Printf.printf "sujet : %s\n" suj;
                                    Printf.printf "verbe : %s\n" verb;
                                    Printf.printf "complément : %s\n" comp;
                                    Printf.printf "phrase : %s %s %s\n" suj verb comp
                                  ;;
                                val verb_trans : string -> suj:string -> comp:string -> unit = <fun>
                                # let manger = verb_trans "manger";;
                                val manger : suj:string -> comp:string -> unit = <fun>
                                # let manger_la_souris = manger ~comp:"la souris";;
                                val manger_la_souris : suj:string -> unit = <fun>
                                # let le_chat_mange = manger ~suj:"le chat";;
                                val le_chat_mange : comp:string -> unit = <fun>
                                # manger_la_souris "le chat";;
                                sujet : le chat
                                verbe : manger
                                complément : la souris
                                phrase : le chat manger la souris
                                - : unit = ()
                                # le_chat_mange "la souris";;
                                sujet : le chat
                                verbe : manger
                                complément : la souris
                                phrase : le chat manger la souris
                                - : unit = ()
                                # le_chat_mange "ses croquettes";;
                                sujet : le chat
                                verbe : manger
                                complément : ses croquettes
                                phrase : le chat manger ses croquettes
                                - : unit = ()
                                # manger_la_souris "le chien";;
                                sujet : le chien
                                verbe : manger
                                complément : la souris
                                phrase : le chien manger la souris
                                - : unit = ()
                                # manger ~suj:"la souris" ~comp:"le chien";;
                                sujet : la souris
                                verbe : manger
                                complément : le chien
                                phrase : la souris manger le chien
                                - : unit = ()

                                Alors assurément, la logique de la langue française (son système de type et de déclinaison) est plus sophistiqué que ce que je viens de coder, mais c'était pour illustrer autrement mon propos et celui de M. Huet. Donc non ! la grammaire n'a rien, mais absolument rien d'illogique. Bien au contraire, l'étude de la grammaire aiguise la compréhension de la logique, la montre sous un autre jour et évite de rester dans une compréhension étriquée de celle-ci.

                                J'avais d'ailleurs cité le même texte dans la dépêche où l'auteur de grammalecte (outil d'aide automatisée à la correction grammaticale) faisait une demande de financement participatif, afin de montrer que le problème algorithmique d'un tel outil est analogue à de l'inférence de type et à la correction automatique de démonstration. Et de fait, lorsque des grammairiens construisent un arbre d'analyse syntagmatique, la structure est très proche d'un AST ou Arbre de Syntaxe Abstrait.

                                Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

                                • [^] # Re: Un potentiel sacré bourbier

                                  Posté par . Évalué à 2.

                                  I hit the "pertinent" button like a motherfuckin' truck on a motherfuckin' wall !!1!one

                                  "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                                • [^] # Re: Un potentiel sacré bourbier

                                  Posté par . Évalué à -10. Dernière modification le 13/03/16 à 16:52.

                                  J'en veux pour preuve cette extrait d'un discours de Gerard Huet

                                  Oui et Descartes a prouvé l'existence de Dieu aussi hein…
                                  Tu vas donc aussi m'expliquer pourquoi l'imperatif des verbes du premier groupe a un regle differente des autres pourquoi le erbe boire ne se conjugue pas comme croire etc…(logiquement hein….)

                                  La logique ne souffre pas d'exception.
                                  Les langues en ont des tonnes…

                            • [^] # Re: Un potentiel sacré bourbier

                              Posté par . Évalué à -10. Dernière modification le 08/03/16 à 20:44.

                              Suffit de compter le nombre de verbe irregulier, le fait que les verbes du premier et du deuxieme groupe n'ont pas les meme regles a l'imperatif etc etc

                              Que des conneries inutiles a retenir, qui ne sont absolument pas porteuse de sens…

                              Et enfin finalement: si la personne ne vous a pas demande de la reprendre en cas d'erreur…c'est que vous pouvez garder vos reflexions pour vous…
                              Vous faites chier deux personnes: l'auteur du post, la personne qui perd du temps a lire votre correction, d'autant plus si elle a vu la faute vu donc que vous n'apportez rien a la conversation.
                              Et qui cherche desperemment a quoi vous pouvez bien servir dans la vie….

                              ET si vous voulez savoir a quoi serve mes posts la ? a me calmer les nerfs sur toute la pollutions visuelle que m'inflige les grammars nazis a longueur de forum.
                              A cote de ca, mes qqs posts a ce sujet, c'est franchemetn petit joueur.

                              reprendre quelqu'un en public que ce soit a l'ecrit ou a l'oral, c'est etre franchement un gros…

                              • [^] # Re: Un potentiel sacré bourbier

                                Posté par . Évalué à 10.

                                Faut être franc, venant de ta part, je prend ça comme un compliment d'être traité de con !

                                Bah, bah, aucune discussion possible avec toi, tu dis des âneries et tu n'en démords pas, et en plus tu es insultant.
                                Il n'est pire sourd que celui qui ne veut pas entendre.

                                Ça me fait penser à ma fille de trois ans : tu peux lui faire un discours complet sur plein de sujets pendant une demi-heure, au milieu tu dis une fois, une seule, rapidement, que demain on ira à la boulangerie lui acheter une sucette, elle va réussir à tout ignorer, et le lendemain matin au réveil te dire « on va à la boulangerie ? ».

                                Tu as tout lu, tout entendu, et tout compris, mais tu campes agressivement et de façon insultante sur tes positions que tu es même incapable de défendre. Il n'y a pas de dialogue possible, le « fail de communication » est là.

                                Mais c'est cohérent : tu ne cherches pas à communiquer, donc l'outil majeur servant à la communication sur un site web, à savoir la langue écrite, t'indiffère complètement. Logique puisque la communication n'est pas ton objectif !

                                Allez, dernier point : le français écrit et le français oral forment une même langue, mais ne sont pas le même langage, on écrit et on parle différemment, avec des tournures de phrases différentes, des façons de faire différentes, simplement parce que le média de transmission est différent et non équivalent.
                                Donc dire qu'on n'entend pas les fautes d'orthographe à l'oral signifie qu'on devrait les ignorer à l'écrit n'a aucun fondement.

                                De plus, tu fais les distinctions à l'oral : tu ne prononces pas é et è de la même façon, donc tu prononce l'accent à l'oral, l'omettre à l'écrit est donc une faute que tu ne commets même pas à l'oral !
                                Tu démontres donc que tu méprises l'écrit.
                                Or c'est le moyen de communication utilisé ici.
                                Ton objectif n'est donc pas de communiquer.
                                En l'occurrence tu le dis toi même, tu es juste là pour t'enflammer - un peu tout seul - et insulter les gens.
                                Bien heureux de constater que tu es le seul à t'énerver, trépignant dans ton coin, inutile et braillard. Passe donc ton chemin, si tu veux te défouler, joue à un jeu de shoot en ligne, fait du sport, c'est plus efficace.

                                Yth.

                • [^] # Re: Un potentiel sacré bourbier

                  Posté par . Évalué à 4.

                  Ce qui est de la connerie, c'est:

                  1. de faire les choses à moitié: C'est la soluce choisi par Débian, je vois 3 fautes: soluce/solution, choisi/choisie Débian/Debian.
                  2. de faire un message dont le seul intérêt est de corriger un texte pourtant tout à fait lisible.

                  Encore, le texte corrigé aurait été difficile à comprendre sans, j'aurais compris, mais même pas.

                  • [^] # Re: Un potentiel sacré bourbier

                    Posté par . Évalué à 3.

                    Ah, je me doutais que j'allais me faire moinsser, mais je ne pensais pas que j'allais déclencher une telle polémique ;)

                    Il y a plus que 3 fautes dans le commentaire d'origine, mais j'ai choisi de me concentrer sur Debian, c'est que je vois de plus en plus une tendance à ne pas épeler correctement les noms de projets (systemD, Androïd, etc). Alors OK, ce sont généralement de gros projets qui vont pas souffrir de ne pas avoir leur nom correctement écrit sur un obscur site français (troll caché), mais ça généralise une tendance qui peut aussi s'appliquer sur des plus petits projets. Et je trouve ça dommage que des développeurs des projets qui ont passé tant de temps à le choisir avec amour, moults débats, trolls et autres voient le résultat de leurs efforts massacrés, de façon certainement involontaires, lorsqu'on y fait référence.

                    La grammaire et l'orthographe, je laisse ça au gouvernement ;)

                    • [^] # Re: Un potentiel sacré bourbier

                      Posté par (page perso) . Évalué à 5.

                      Que celui qui n'écrit pas un commentaire un peu rapidement en fin de journée de boulot me jette la première pierre. A noter que j'ai bien écrit Debian dans ce même commentaire…

                      Un peu de tolérance dans ce monde de brute ne peut faire que du bien ;-)

                      Concernant mon blog, j'en ai un sous mon vrai nom et bien actif. Je ne souhaite pas qu'il y ai une relation trop directe entre mon pseudo et mon identité réelle, surtout que cela n'apportait rien au schmilblick. Cela dis, des personnes la connaisse notamment certains administrateurs de DLFP. Merci pour leurs discrétions au fils des ans.

                    • [^] # Re: Un potentiel sacré bourbier

                      Posté par . Évalué à 1.

                      Ho allez… genre tu n'as pas fait l'orthonazi sans penser à polémique… XD

                      Je l'ai déjà dit dans un sondage récent, pour moi, la polémique et le débat, ce sont des jeux, et c'est le premier qui s'énerve qui perd (sur le net, c'est difficile, les gens ont le droit à un deuxième souffle avant de poster, il faut être très doué pour énerver les gens, ou avoir affaire à des gens peu futés…). Et si on ne prend en compte que le fun, alors défendre des idées que l'on n'aime pas peut être particulièrement intéressant (un bon troll rends, il faut l'avouer, les discussions plus vivantes, parce quand tout le monde est d'accord, c'est chiant………….. avis personnel).

                      Pour ce qui est des noms de projet… pour avoir été impliqué dans quelques petits, je ne pense pas que les gens se sentent insultés par une faute de frappe, c'est même le contraire, ils sont déjà tellement heureux que l'on parle de ce qu'ils ont fait (pas d'eux, ça, s'ils pouvait éviter… ils seraient preneurs) qu'ils ne verront pas la différence. Mais je te rejoins, une bonne orthographe aide au référencement. Snif. Putain de robots. Mais que ferait-on sans eux….

                      Hm… au sujet des noms trop durs a trouver… je dirai… par exemple que quand on "crée" un projet, on est inspiré par un autre. Je veux dire, moi, quand je crée, je cherche a faire mieux que les autres en m'inspirant d'eux, en fonction de la licence (ben oui). Enfin, pas toujours, là, j'ai un projet qui cherche à faire justement moins qu'apt… mais bon.
                      Tu auras sûrement constaté la grande présence de jeux de mots dans les logiciels libres. Pourquoi donc tant de boutades? Genre, garçon, gigolo, suckless-tools, useless, même: less… des forks => redmine? chiliproject, bien sûr! OpenOffice => LibreOffice naturellement. Hum… apt -> aptitude… why not.

                      P'tit point de détail pour un de nos élus francophone qui tomberaient ici par hasard: de nombreux projets libres ont des noms francophones, je me demande si c'est pas grâce, justement, au fait que notre lange ait un certain attrait. Comment le conserver? Je n'en sais rien, demandez donc à des pro, il y a des linguistes pour ça.

                      • [^] # Re: Un potentiel sacré bourbier

                        Posté par . Évalué à 6.

                        (un bon troll rends, il faut l'avouer, les discussions plus vivantes, parce quand tout le monde est d'accord, c'est chiant………….. avis personnel).

                        Je ne suis pas d'accord, un troll pourri la discussions, il ne l'enrichit pas. Il n'hésite pas à utiliser la mauvaise fois, les attaques personnels, cela n'a rien d'intéressant.

                        "La première sécurité est la liberté"

                        • [^] # Re: Un potentiel sacré bourbier

                          Posté par . Évalué à 1.

                          Je ne suis pas d'accord, un troll pourri t la discussion s, il ne l'enrichit pas. Il n'hésite pas à utiliser la mauvaise foi s, les attaques personnel les, cela n'a rien d'intéressant.

                          Sans aucune volonté trolessque. ;-)
                          Cela étant, je t'accorde qu'un troll est pourri et n'hésite pas à recourir maintes fois à la mauvaise foi. Pour ce qui est des attaques contre le personnel, je ne pense pas qu'un troll aille jusque-là. :-)

                          La perte de foi dans l'orthographe arrive bien des fois mais tenter d'y remédier ne fait pas risquer des coups dans le foie — alors que, selon certain, ce peut être plus risqué à l'oral : faisons donc une petite chanson !

                          Il était une fois,
                          Une marchande de foie,
                          Qui vendait du foie,
                          Dans la ville de Foix…
                          Elle se dit ma foi,
                          C'est la première fois
                          Et la dernière fois,
                          Que je vends du foie,
                          Dans la ville de Foix

                          Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

  • # proxmox

    Posté par (page perso) . Évalué à 4.

    Il me semble que proxmox fait pareil : le module zfs.ko est distribué en binaire avec leur noyau pve-kernel. Le modinfo indique "author: OpenZFS on Linux" "License: CDDL"

    [réaction primaire et troll inside]
    Cette histoire de licence plus le mélange du fs avec des fonctions que je suis habitué à avoir par LVM et mdadm, ou le fait que zfs soit gourmand en ressources, le fait que certaines de ses fonctionnalités sont certes très intéressantes, mais que pour des usages spécifiques (qui a vraiment besoin de dédup' chez soi, vous hébergez des dizaines de VM ou des tonnes de choses redondantes ?…). Bref tout cela fait que je ne suis pas fan de ZFS.
    [/réaction primaire et troll inside]

    J'exprime juste mon avis par rapport à mes besoins et mes usages : je ne prétends pas avoir la vérité absolue et les défenseurs de ZFS ont surement de très bonnes raisons… pour eux ! ;-)

  • # Y a-t-il vraiment un risque ?

    Posté par (page perso) . Évalué à 10.

    Est-ce réellement un problème ? Avant de me moinser, lisez l'explication.

    Effectivement, en fonction de l'interprétation choisie, il peut y avoir violation de licence. Mais dans ce cas, qui peut agir ? Est-ce le Software Freedom Conservancy ? Non. Ce sont les détenteurs des droits des projets dont la licence a été violée. En l’occurrence ici, les détenteurs des droits sur le noyau linux.

    Or, comme rappelé dans ce commentaire, la position de Linus est bien connue

    Linus (et les développeurs noyau ?) ont déjà déclaré publiquement que l’import d’un système de fichier issu d’un autre OS n’en faisait pas un travail dérivé de Linux (cas d’AFS).

    Bref, même si la licence n'est pas respectée, que craint Canonical ? J'ai presque envie de dire… rien puisqu'il y a une sorte de "dérogation" implicite accordée par Linus

    • [^] # Re: Y a-t-il vraiment un risque ?

      Posté par . Évalué à 10.

      Sauf que Linus n'est pas le seul "proprio" du code. Il y a des milliers de contributeurs qui peuvent decider d'attaquer Canonical sur le sujet. Et si mes souvenirs sont bons, il me semble bien que Canonical n'a pas que des amis dedans…

    • [^] # Re: Y a-t-il vraiment un risque ?

      Posté par . Évalué à 7. Dernière modification le 02/03/16 à 10:41.

      Linus n'est pas le seul à décider de la façon de faire respecter la licence. Tous les contributeurs y ont un droit de regard. En ce sens, si la SFC était sollicitée par des contributeurs pour défendre leur vision de la licence, elle aurait alors une base pour attaquer une potentielle violation de la licence.

      edit: grilled

    • [^] # Re: Y a-t-il vraiment un risque ?

      Posté par . Évalué à 10.

      Bonjour, juste pour préciser,

      le Software Freedom Conservancy représente un certain nombre de développeurs du noyau (donc détenteurs de droits sur le noyau) via son "GPL Compliance Project For Linux Developers". Si ces développeurs décident que le SFC doit agir, il aura la légitimité pour le faire, tout comme il le fait déjà face à VMWare en Allemagne.

      Pour rappel, le noyau Linux n'est pas uniquement l’œuvre de Linus Torvalds et dans la mesure où il n'y a pas d'obligation pour les contributeurs de transférer leurs droits au projet ou à l'auteur principal, presque tous jouissent pleinement de leurs droits en tant qu'auteurs. C'est d'ailleurs ce côté qui protège le noyau contre un rachat par une société tierce (comme on a pu le voir avec des projets comme cups) mais rend un changement de license (par exemple vers GLPv3) impossible.

      Bien à toi.

    • [^] # Re: Y a-t-il vraiment un risque ?

      Posté par . Évalué à 10.

      En plus des réponses ci-dessus, j'ajouterais que tu créés un précédent :
      Si Canonical peut s'asseoir sur une licence, alors pourquoi pas d'autres, sur d'autres points de détails?
      Encore une fois, la licence doit être neutre et systématique, et non pas ajustable suivant le capital sympathie et le contexte de la violation.

      • [^] # Re: Y a-t-il vraiment un risque ?

        Posté par . Évalué à 1.

        Dans la pratique, il existe des milliers de précédents.

        La vraie question est de montrer quiqu'adublé, et assez pour foutre l'autre dans la merde histoire de pouvoir financer ses propres activités.

        Tiens, une question, peut-être, voire sûrement stupide: quelqu'un sait-il pourquoi Linus Torvalds à choisi la GPLv2 pour son kernel?
        Est-ce pour le copyleft? Et si oui, pourquoi est-ce si difficile de passer en v3 (que ce soit moralement, idéologiquement, ou légalement, je veux lire toutes les raisons)?
        Mr. Torvalds semble être quelqu'un de plus orienté (des rumeurs que j'ai lues) vers le pragmatisme, alors pourquoi avoir choisi une licence copyleft (et les emmerdes que ça implique)?

        Note: je ne remets pas en cause son choix: l'initiateur d'un projet est libre de choisir comment son code peut être distribué.

        • [^] # Re: Y a-t-il vraiment un risque ?

          Posté par (page perso) . Évalué à 4.

          Est-ce pour le copyleft?

          Oui, je vois que tu ne lis pas assez le site :)

          Et si oui, pourquoi est-ce si difficile de passer en v3

          Parce qu'il faut l'accord de tous les contributeurs ayant du code dans le noyau (et pour tous ceux qui refusent, il faut supprimer le code du noyau).

          Mr. Torvalds semble être quelqu'un de plus orienté (des rumeurs que j'ai lues) vers le pragmatisme, alors pourquoi avoir choisi une licence copyleft (et les emmerdes que ça implique)?

          cf lien plus haut.

          « 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: Y a-t-il vraiment un risque ?

            Posté par . Évalué à 4.

            Parce qu'il faut l'accord de tous les contributeurs ayant du code dans le noyau (et pour tous ceux qui refusent, il faut supprimer le code du noyau).

            Sachant que Linus n'aime pas la GPLv3 (cf ton lien), ça va être sympathique de remplacer toutes les sections incriminer :)

            Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

            • [^] # Re: Y a-t-il vraiment un risque ?

              Posté par (page perso) . Évalué à 3.

              Linus Torvalds a aujourd'hui très peu de lignes de code à son nom en réalité.

              • [^] # Re: Y a-t-il vraiment un risque ?

                Posté par . Évalué à 5.

                Il écrit très peu de nouvelles lignes, mais il met son grain de sel dans un paquet d'endroit et il y a des pans du noyau qui reste assez vieux (on ne réécris pas tout tout le temps). Dans le temps on prenait comme exemple le code des terminaux virtuels pour ça, je ne sais plus si ça a était réécris (et si oui dans quel mesure) lors de la suppression du BKL.

                Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

              • [^] # Re: Y a-t-il vraiment un risque ?

                Posté par . Évalué à 2.

                Ouhais mais lorsqu'il intervient c'est pour des trucs critiques et de tout de façon je suis presque sûr qu'il y a du code sous gpl2 de devs qui sont aujourd'hui non contactable…

                • [^] # Re: Y a-t-il vraiment un risque ?

                  Posté par . Évalué à 2.

                  Oui. Lorsqu'on lui avait demandé s'il voulait passer à GPLv3), Linus a déjà dit que ça n'arriverait pas, indépendamment d'un choix idéologique, car il y a des contributeurs qui sont décédés, et dont le code est toujours utilisé (or, pour passer le noyau en GPLv3, il faudrait que TOUS les contributeurs acceptent, sous peine de devoir récrire le code pour chaque portion dont l'auteur n'a pu être joint).

    • [^] # Re: Y a-t-il vraiment un risque ?

      Posté par (page perso) . Évalué à 3.

      Si c'est contre la licence de mélanger du code GPL avec du code CDDL, on peut supposer que les devs kernels vont raler, mais aussi les détenteurs des droits du coté de ZFS. Et c'est la ou ça deviens amusant, car c'est Oracle. Les mêmes à avoir tenter de faire un procès à Google sur Android.

      Bien sur, Canonical ne va pas avoir de souci directement. Les gens qui proposent Ubuntu et qui se font du blé, genre Amazon ou Microsoft, ç'est déjà autre chose, car ils ont un chouia plus de quoi payer les amendes.

  • # Zfs vs BTRFS

    Posté par . Évalué à 5.

    Pour ceux qui (comme moi) se posent la question "Où en est le sympathique btrfs face au sympathique Zfs" (on est pas vendredi), on a des pistes de réponse rapides dans une Comparaison wikipedia de systèmes de fichiers

    TL;DR: ce qui me semble le plus limitant est l'absence de chiffrement de btrfs, sinon, ça a l'air très proche dans l'avancement.

    Ceci dit, la comparaison est vraiment générale et les listes wikipedia sont parfois sujettes à erreurs. Voici donc d'autres sources:

    On a un test de perfs récents dans un rapport de projet de fin d'étude. Btrfs a l'air d'assurer de plus gros débits que Zfs, mais la question de la stabilité est posée.

    Il y a les slides d'un talk à la Linuxcon 2014 avec pas mal de détail, notamment sur la licence mais l'auteur est peut-être partial ;)

    Si vous avez d'autres bonnes sources récentes, je suis preneur :)

    • [^] # Re: Zfs vs BTRFS

      Posté par . Évalué à 7.

      TL;DR: ce qui me semble le plus limitant est l'absence de chiffrement de btrfs, sinon, ça a l'air très proche dans l'avancement.

      C'est pas surtout parce que c'est assuré par dm-crypt ?

      Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

    • [^] # Re: Zfs vs BTRFS

      Posté par . Évalué à 3.

      Je pensais la maturité. Mais je lis ZFS 2004, Btrfs 2007. Donc pas si pertinent.

      • [^] # Re: Zfs vs BTRFS

        Posté par . Évalué à 0.

        Il y a aussi le fait que ZFS couvre les fonctionnalités de LVM.
        Ce qui ne plaide pas vraiment pour lui IMHO.

        • [^] # Re: Zfs vs BTRFS

          Posté par . Évalué à 10.

          Justement non, le fait que ZFS couvre à la fois les fonctionnalités de LVM, mdadm …. est un grand +.
          Il n'y a pas de chaîne de confiance "aveugle" à la "FS <-> LVM <-> MDADM". La donnée est gérée de bout en bout par ZFS.
          Dans le fonctionnement en couche habituelle, chaque couche du dessus fait "confiance" à la couche du dessous. Le FS doit considérer que si LVM lui indique que l'écriture est OK, il doit lui faire confiance. LVM fait de même avec MDADM qui fait de même avec les disques. Ce genre de chose peut aboutir à une possible corruption "silencieuse" (le fameux writing hole du raid 5 par exemple). J'ai personnellement vécu ça avec un RAID6 (EXT4-LVM-MDADM).
          ZFS n'a, à ma connaissance, qu'un seul véritable concurrent: WAFL de Netapp. Ces 2 systèmes sont d'ailleurs franchement très similaire. Les 2 partagent d'ailleurs la fonctionnalité de ne jamais réécrire une donnée modifiée au même endroit que la donnée originale, ce qui permet en cas d'écriture incomplète, de certes perdre la donnée en cours d'écriture, mais de conserver l'ancienne donnée et non pas une donnée corrompue, le pointeur n'étant mis à jour que lors de l'écriture complète de la nouvelle donnée (cf RAID 5 writing hole).
          Par contre, tout çà à un coût niveau perf. Ce filesystem n'est pas fait pour obtenir les meilleures perf… mais plutôt garantir au maximum la cohérence et la pérénité de la donnée.
          Côté fonctionnalité, soyons clair:
          - La compression, ça fonctionne très bien, sous réserve de prévoir de la ressource CPU. Dans certain cas, on obtient d'ailleurs de meilleures perfs que sans, sur des disques mécaninques lents.
          - la dédup, étant online, est très consommatrice de RAM et "tue les perfs". Il faut l'utiliser avec parcimonie.
          - le checksummming, parfait pour garantir la cohérence de data très importante
          - le snapshot, sans perte de performance car ne fonctionnant pas en mode copy-on-write (contrairement à LVM, ce qui impose une utilisation temporaire des snaps et une impossibilité de les chainer sans effondrer les perfs)
          - le dump des datasets (zfs send/receive) pour transférer le contenu d'un dataset vers un autre dataset zfs (distant ou local) ou vers un fichier. Possibilité d'utiliser le send incrémentale entre 2 snapshots.
          - le scrubbing, vérification de l'intégrité des DATAs présentent dans le zpool.
          - à vous de voir pour les autres fonctionnalités…..
          Par contre, gros "mauvais point", pas de possibilité d'étendre des RAIDZ (1,2 ou 3). Il faut aggréger un nouveau RAIDZ (et de taille identique si possible, pour ne pas créer d'asymétrie au niveau IOs). Contrairement à WAFL qui a son RAID DP basé sur le RAID 4 (+1 parité supplémentaire), qui lui utilisant des disques dédiés aux paritées, permet l'ajout de disque à une grappe RAID.

          Voilà, en espérant avoir éclaircit la lanterne de certains sur ce FS qui mériterait vraiment une utilisation "large" tellement il offre de possibilités.

          • [^] # Re: Zfs vs BTRFS

            Posté par . Évalué à 1.

            Les 2 partagent d'ailleurs la fonctionnalité de ne jamais réécrire une donnée modifiée au même endroit que la donnée originale

            Sérieux, les autres ne le font pas?

            Côté fonctionnalité, soyons clair: […]

            Tu as l'air de bien connaître. Aurais-tu a tout hasard quelques docs sur le net qui me permettraient de combler mon manque de connaissances?
            J'ai personnellement toujours… bon, ok, c'est faux: depuis que je suis passé à linux, j'ai voulu prendre le plein contrôle de mon système, et essayer de faire les choix pertinents. Hors, il s'avère qu'un des choix qui me semblait et me semble toujours important est le partitionnement et les FS associés.
            Hors, c'est bien LE point sur lequel il y a LE MOINS d'infos. j'ai beau bricoler dans mon coin et codouiller du système, j'ai l'impression que tant que j'essaierai pas de taper dans le kernel (qui fait quand même peur) je ne pourrai jamais comprendre les avantages et inconvénients des différents FS… il n'y a juste aucune doc indiquant les points forts et faibles de ceux-ci.
            C'est encore pire quand on essaies de se documenter pour passer a des *BSD… au moins Debian ne propose que des extX, il "suffit" de prendre la version la plus récente quand on ne connais rien…

            • [^] # Re: Zfs vs BTRFS

              Posté par . Évalué à 9.

              Quand tu modifies une donnée, la plupart du temps, les FS réécrivent par dessus l'ancienne donnée (à part BTRFS, il me semble, car il est aussi un FS-ng), ça évite la fragmentation d'ailleurs.
              Petite précision, ZFS gérant aussi la couche RAID (WAFL aussi d'ailleurs), ce comportement est encore plus important pour éviter les corruptions silencieuses.

              Je connais un peu, car je suis admin stockage ;-). J'ai plus souvent l'habitude de travailler sur des baies (surtout NetAPP) que sur des FS de serveur. Mais je monte aussi des baies de stockage à partir de serveurs (quand on voit ce qu'est un contrôleur NetAPP, c'est de toute manière là même chose !).

              J'utilise ZFS à titre perso et pro, c'est quasi systématiquement mon choix quand il s'agit d'être sûr de la pérennité de la donnée. J'ai bien cru un moment à BTRFS dont les fonctionnalités sont très proches (du moins, tente de raccrocher les wagons avec ZFS, développé par ORACLE à l'origine d'ailleurs), mais ce FS me laisse un peu sur ma faim. L'histoire du balance à effectuer manuellement dans certains cas où ton système t'indique que tu as encore de la place mais qu'il te remonte qu'il n'y a plus de d'espace sur le device quand tu tentes une écriture, m'a plutôt échaudé (du moins pour ce qui concernerait une éventuelle mise en prod).

              Pour ce qui est des docs, je ne vais pas trop pouvoir t'aider, car j'ai plutôt glâner de l'infos à droite à gauche du fait de mon métier. Tu peux déjà chercher des comparos de FS sur wikipédia, ça résume les différences et spécificités des différents FS.
              il y a aussi Aaron Toponce https://pthree.org/category/zfs/ qui donne pas mal d'infos sur l'utilisation de ZFS.

              Contrairement à ce que tu penses, Debian (ou les linux) ne proposent pas que du extX par défaut, tu as un très grand nombre de FS dispos (peut⁻être pas à l'installation): XFS, reiserfs 3.5, reiserfs 4, btrfs… et beaucoup d'autres.

              Plus classiquement, tu choisis un FS selon le besoin que tu en as:
              - Snapshot: XFS,ext4, resiserfs… couplé à LVM… ou alors ZFS, BTRFS
              - Dédup: euh…. bah ZFS !! sinon, il y a les opendedup et autres couches, mais je ne suis pas convaincu.
              - Backup distant de FS (ou réplication asynchrone): ZFS, BTRFS…. éventuellement LVM + FS
              - compression: ZFS, BTRFS……
              - Quantité de fichiers sur les FS: XFS et reiserfs semblent bien disposés à ce genre de contrainte, ZFS aussi.

              Pas besoin de "taper dans le noyau", du moins dans un premier temps. Quand tu en arrives au tuning kernel, c'est que tu est déjà aller bien loin dans l'utilisation du FS ;-)

              • [^] # Re: Zfs vs BTRFS

                Posté par . Évalué à 4.

                Où est HAMMER FS dans le lot ? Il me semble qu'il a moins de fonctionnalité ?

                Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

              • [^] # Re: Zfs vs BTRFS

                Posté par . Évalué à 2.

                À défaut de documentation, il y avait une dépêche intéressante sur le sujet (avec de mémoire, quelques commentaires qui donnaient des explications pertinentes): https://linuxfr.org/news/et-si-la-meilleure-des-cartes-raid-etait-libre

              • [^] # Re: Zfs vs BTRFS

                Posté par . Évalué à 2.

                Contrairement à ce que tu penses, Debian (ou les linux) ne proposent pas que du extX par défaut, tu as un très grand nombre de FS dispos (peut⁻être pas à l'installation): XFS, reiserfs 3.5, reiserfs 4, btrfs… et beaucoup d'autres.

                Quand je dis par défaut, c'est à dire que c'est le choix par défaut, je ne dis pas qu'il n'y en a pas d'autres (d'ailleurs l'outil de partitionnement de l'installateur Debian est très bien foutu je trouve, ce n'est pas le cas de tous les installateurs).

                En tout cas merci pour ta réponse instructive.

              • [^] # Re: Zfs vs BTRFS

                Posté par (page perso) . Évalué à 2.

                Backup distant de FS (ou réplication asynchrone): ZFS, BTRFS…. éventuellement LVM + FS

                Marche pas mal avec lsyncd sur tout système de fichier. Cela ne répond pas à 100% des cas mais est suffisant dans de très nombreux cas.

          • [^] # Re: Zfs vs BTRFS

            Posté par . Évalué à 1.

            C'est quoi la "dédup" ?

            Est-ce que le checksumming sert réellement ? Après tout, le disque dur lui-même en utilise déjà un gros, qui est caché.

            Pourquoi le copy-on-write pose problème ?

            "dump de dataset" ? C'est un snapshot que tu peux récupérer telquel sur un autre disque ?

            Le scrubbing est réellement utile ? Je suis quasiment sûr qu'il existe un moyen de le faire faire au niveau du disque dure (genre un simple read doit provoquer l'équivalent d'un scrubbing au niveau hardware).

            "La première sécurité est la liberté"

            • [^] # Re: Zfs vs BTRFS

              Posté par (page perso) . Évalué à 5.

              La dédup est la déduplication. Le système de fichiers se rend compte tout seul que deux blocs (qui appartiennent probablement à deux fichiers différents) sont identiques. Du coup, il n'en stocke qu'un exemplaire. Quand tu n'as que des fichiers différents c'est bien sûr totalement inutile, mais quand tu stockes beaucoup de VM (par exemple), avec chacune un OS complet, tu as autant de copies du même fichier que de VM. Là ça peut apporter un gros gain de place.

            • [^] # Re: Zfs vs BTRFS

              Posté par . Évalué à 4.

              Pour la dédup, la réponse a déjà été apportée…
              Pour le checksumming, c'est une sécurité supplémentaire pour détecter des corruptions. Ca peut paraitre "ceinture-bretelle-caleçon blindé" mais étant donné que le FS ne peut pas totalement faire confiance au disque, cela permet d'être sûr qu'une écriture a bien été faite et surtout correctement, éventuellement de la corriger le cas échéant…
              Pour la COW (Copy-on-write), le problème vient du fait que lors de la création d'un snapshot… le snapshot n'est qu'une COW-table (en gros)… pour toute modif est sur l'élément original (un LV par exemple), on reporte d'abord la data avant modif dans la cow table… puis ensuite on vient remplacer la data original par la nouvelle data… pour faire simple… une écriture génère: une lecture + une écriture + écriture…. je vous laisse estime la charge que cela peut générer sur de pauvres disques mécaniques.. si vous chaînez les snap, c'est la fin du monde ;-)

              Le dump de dataset c'est à peu près "récupérer tel quel sur un autre disque" à ceci prêt qu'on ne peut pas parler de "disque"… en gros, tu peux dupliquer (ou dumper dans un fichier) ton dataset dans l'état du dernier snapshot que tu as fait.
              L'intérêt étant le dump différentiel permettant de ne transférer vers le dataset distant, que ce qui a changé depuis le dernier snapshot, d'où la notion de réplication asynchrone (car non temps-réél)

              Le scrubbing, c'est une assurance que tes données sont intègres. Encore une fois, c'est l'usage (prod ou non) qui fera que cela sera utile. Le scrubbing ne fait pas d'analyse de surface des disques, il fait une analyse de l'intégrité des données du zpool. Si ton zpool n'a que 3To d'utilisé sur 12To total, le scrub ne se fera que sur 3To. Donc, on n'a pas d'équivalent hardware du scrubbing, il faut plutôt voir le scrubbing comme un fsck en ligne (sur la partie data occupée).

              • [^] # Re: Zfs vs BTRFS

                Posté par . Évalué à -1.

                Les disques et les SSD disposent d'une énorme quantité de correcteur de code. Je ne sais plus la proportion, mais c'est plus de 20% de la mémoire stockée.

                Donc, le checksum parait inutile. Idem pour le scrubing.

                "La première sécurité est la liberté"

                • [^] # Re: Zfs vs BTRFS

                  Posté par . Évalué à 1.

                  ou alors, c'est pour gérer les erreurs plus gros qu'un bloc (4ko actuellement, il me semble). J'imagine que c'est les fameux bloc rempli de zéro que google a évoqué dans son rapport sur la fiabilité des disques dures.

                  "La première sécurité est la liberté"

                • [^] # Re: Zfs vs BTRFS

                  Posté par . Évalué à 5.

                  Encore une fois, ne pas confondre la partie block et la partie fichier.
                  Si le périphérique de block reçoit une data erronée qui peut avoir l'air correcte du point de vue de ses algos de correction, il écrira une donnée corrompue du point de vue fs mais correct du point de vue block.
                  Je dirais que le scrubbing et le checksum ne sont pas à envisager pour du disque unitaire, mais plutôt pour des RAID (Z1,Z2,Z3).
                  Il faut que l'intégralité des stripes+parité soient correctement écrites pour qu'une donnée soit valide. Chaque disque n'est capable de corriger que son stripe, si un disque dysfonctionne et n'écrit pas le stripe correctement mais indique un ACK sur cette dernière, au dessus, le FS (ou le RAID Hard ou Soft) pensera que tout s'est bien passé, hors une corruption a eu lieu (une corruption silencieuse). Le seul moyen de corriger sera d'effectuer un scrubbing et/ou d'effectuer une vérification du checksum de la donnée.
                  J'avoue que c'est ceinture-bretelle-caleçon blindée et que pour l'instant, même avec des arrêts élec sauvages, mon zpool n'a jamais indiqué d'erreur (réparée ou non). Mais encore une fois, tout dépend de l'importance des données stockées sur le zpool…

                  ZFS est orienté vers un stockage cohérent et sûr de la data. Mais effectivement, on peut se passer totalement de faire des scrubbings. On peut faire la même chose avec sa voiture ;-), tout dépend de ce qu'on peut se permettre de risquer !!!

              • [^] # Re: Zfs vs BTRFS

                Posté par . Évalué à 3.

                Pour la COW (Copy-on-write), le problème vient du fait que lors de la création d'un snapshot… le snapshot n'est qu'une COW-table (en gros)… pour toute modif est sur l'élément original (un LV par exemple), on reporte d'abord la data avant modif dans la cow table… puis ensuite on vient remplacer la data original par la nouvelle data… pour faire simple… une écriture génère: une lecture + une écriture + écriture…. je vous laisse estime la charge que cela peut générer sur de pauvres disques mécaniques.. si vous chaînez les snap, c'est la fin du monde ;-)

                Je ne comprends pas du tout…

                De ce que j'avais compris les snap BTRFS (et je présume que c'est pareil avec ZFS), c'est juste annoter tous les inodes/block/je-sais-plus et sur l'utilisation courante continue à écrire les données sur de nouvelles plages plutôt que de les modifier (comme tu le décris plus haut). C'est juste qu'avec cette annotation, on sait qu'on ne va pas libérer ce block/inode. Donc ça coûte l'annotation de tous les blocs lors de la création et rien pour l'utilisation courante. Et ça c'est déjà du COW.

                Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                • [^] # Re: Zfs vs BTRFS

                  Posté par . Évalué à 1.

                  Concernant BTRFS, je suis totalement d'accord avec toi, je ne vois pas pourquoi on utilise le terme COW… Effectivement, BTRFS-ZFS-WAFL lors de snapshot ne font que figer les blocks en fesant pointer le snapshot sur ces derniers, ce qui implique d'écrire les nouvelles données ailleurs. Ce n'est donc pas de la Copy-On-Write (comme on l'entend du moins pour LVM), car il n'y a pas d'opération de copy lors d'une écriture… Si quelqu'un sait pourquoi on utilise COW pour BTRFS, je suis preneur.

      • [^] # Re: Zfs vs BTRFS

        Posté par (page perso) . Évalué à 4.

        Attention, 2004 est la date d'introduction donc avec une version déjà fonctionnelle je dirais (je n'ai pas plus creusé que cela) alors que 2007 doit corresponde aux premiers commit dont un truc pas du tout du même niveau ;-)

        • [^] # Re: Zfs vs BTRFS

          Posté par . Évalué à 2.

          Ça confirmerai l'idée que je m'en faisais.
          Dans ce cas l'article WP est très imprécis.

    • [^] # BTRFS

      Posté par (page perso) . Évalué à 9.

      Il y a qq. années, j'avais testé Btrfs car j'ai lu que c'était trop super. Mais j'ai eu de gros problèmes de performances sur des machines virtuelles à cause du fonctionnement Copy-on-write. J'avais aussi eu des soucis de disque "plein" alors que non, 80% de l'espace disque (800 Go de mémoire) étaient libres. Il fallait faire qq. bidouilles. Ca m'avait saoulé, j'avais remis ext4.

      Il y a environ 1 an, j'ai remplacé mes deux disques durs en RAID 0 par un unique SSD. Le boot est passé d'environ 3 minutes à 10 secondes. À priori les I/O étaient le goulot d'étranglement, pas le CPU :-D

      J'en ai profité pour retenter btrfs. Déjà, j'ai crée une partition ext4 dédiée pour la virtualisation. Bien qu'entre temps, j'ai lu qu'on peut desactiver la fonctionnalité de Copy-On-Write (CoW) sur certains fichiers. Ca me semble pénible de devoir le faire sur chaque VM.

      Pour un PC de bureau, le principal gain que je vois avec Btrfs est la facilité pour créer un backup du système complet : un "snapshot". Ca ne protège ni du vol, ni de la casse matérielle, ni des catastrophes naturelles. Mais ça protège du "rm -rf" maladroit (oups, mauvais chemin, oups variable non initialisée en shell, etc.). Euh, de mon expérience, rm -rf est plus courant que les vols / casse / accidents :-) En 1 an, j'en ai déjà profité une fois ! J'ai pu récupérer mes photos du Japon effacées par erreur ! ("Tiens, j'ai supprimé la copie ou l'original ? Oups tiens l'original. Tiens où est la copie ? Y'a pas de copie ? Ah en fait, y'a plus aucune photo… Meeerde").

      Créer un snapshot est trivial. Accéder à un snapshot : bah c'est un vulgaire dossier en lecture seule sur le disque. On peut également rebooter l'OS sur un ancien snapshot.

      J'ai aussi lu que btrfs détecte les corruptions de données sur disque et sait récupérer une ancienne version d'un fichier dans les snapshots, mais je n'ai pas expérimenté ça. Je ne sais même pas si btrfs calcule effectivement un checksum des fichiers !?

      Ah sinon pour les perfs … Euh désolé mais pour mon utilisation, je m'en fous un peu hein :-) Ca me semble plus important d'éviter de perdre des données que de gagner 10% de perf ou autre.

      En tout cas, côté fonctionnalités, btrfs me semble supérieur à ext4.

      Pour finir, je n'ai jamais perdu le moindre fichier à cause de btrfs.

      • [^] # Re: BTRFS

        Posté par . Évalué à 2.

        Une question:

        Ça marche comment, les backup?

        • [^] # Re: BTRFS

          Posté par . Évalué à 9.

          Tu fais un snapshot en read only de la partition que tu veux sauvegarder (par exemple /home) :

          btrfs subvolume snapshot -r /home /home/.snapshots/$(date +"%Y%m%dT%H%M%S")

          Tu peux ensuite en faire ce que tu veux, par exemple l’envoyer en SSH sur un serveur distant :

          btrfs send /home/.snapshots/$date | gzip | ssh backups@srv-backup "cat > $date.gz"

          Tu peux même faire du backup incrémental :

          btrfs send -p /home/.snapshots/$previous /home/.snapshots/$date | gzip | ssh backups@srv-backup "cat > $previous-to-$date.gz"

          Pour restaurer, c’est un poil plus technique, mais rien d’insurmontable :

          cd /home
          mkdir .snapshots
          cd .snapshots
          ssh backups@srv-backup "cat $lastfull.gz $lastfull-to-${inc1}.gz ${inc1}-to-${inc2}.gz" | zcat | btrfs receive .
          
          # A partir de là on a récupéré le dernier snapshot en mode lecture seule.
          # On peut faire un gros copier bourrin cp -a /home/.snapshots/${inc2}/{*,.*} /home,
          # ou alors on peut faire ça plus finement et ordonner à btrfs d’utiliser
          # le dernier snapshot pour /home :
          
          # Faire une copie du snapshot à restaurer en mode lecture-écriture
          # (les snapshots récupéres par btrfs receive sont toujours en read-only
          btrfs subvolume snapshot ${inc2} last-rw
          
          # On récupère l’id de last-rw
          id=$(btrfs subvolume list /home | awk '/\/last-rw$/{print $2}')
          
          # On change le snapshot utilisé par /home, et on remonte
          btrfs subvolume set-default $id /home
          cd /; umount /home; mount /home
          • [^] # Re: BTRFS

            Posté par . Évalué à 2.

            Propre et simple, y'a pas à dire. Ça me motive déjà vachement plus que d'utiliser un logiciel tiers pour me mettre à la bonne pratique générale qui est de faire des backups réguliers (même si, bien sûr, ce type de backup n'affecte qu'une partition).

            Ce système est-il lié aux caractéristiques de la partition (enfin, du support de la partition, ça peut être un fichier, je sais) ou on peut restaurer un FS sur une partition totalement différente (taille différente, par exemple, en ayant bien entendu assez de place pour restaurer les données)?

            • [^] # Re: BTRFS

              Posté par . Évalué à 2.

              La sortie de btrfs send, c’est une liste d’opérations génériques (créer fichier, supprimer fichier, changer permissions, changer contenu). Tu peux donc le restaurer sur n’importe quel système de fichiers btrfs. Dans l’absolu tu pourrais même écrire un outil pour le restaurer sur une partition ext4/NTFS/whatever, mais à ma connaissance personne ne s’est fatigué à le faire.

    • [^] # Re: Zfs vs BTRFS

      Posté par . Évalué à -2.

      Hum… ZFS vs BTRFS vs WTFS… on s'en cogne non?

      Désolé, mais, la seule chose qui compte, c'est: qu'ont donc à apporter ZFS ou BTRFS ou WTFS comparé aux systèmes que l'on utilise actuellement au jour le jour? Dans le cas de nombre de linuxiens, je parle de ext3 ou 4, dans le cas des BSDistes, je ne sais pas.

      Mais, dans tous les cas, expliquez-moi donc quelle est la différence entre nos systèmes actuels (déjà entre eux, je serai content, vraiment) avec ces nouveaux systèmes ultra-super-révolutionnaires?
      Je suis vraiment preneur.
      Ah, petit détail, je ne suis pas un administrateur système (j'aimerai, mais je n'ai pas les compétences). Je me contente d'administrer 2-3 machines, dont une qui fait office de routeur, rien qui ne soit hors de portée d'un débutant quoi.

      • [^] # Re: Zfs vs BTRFS

        Posté par . Évalué à 5.

        Que tu t'en cognes…. pourquoi pas ;-)…. mais, tout dépend de ta préoccupation et de ton besoin.
        Si tu reprends mon post de réponse quelques lignes plus haut, j'explique "très sommairement" les avantages de ce FS-ng (je dis ng, car BTRFS-ZFS-WAFL ne sont pas "que" des FS, ils gèrent la couche stockage entière.
        Maintenant, clairement, si c'est pour une machine perso… tu n'y verras pas d'intérêt. Par contre, pour de la virtu, pour du serveur de fichier, pour du docker…. là, ça sera très intéressant.
        On peut prendre NTFS en exemple… tous les windowsiens ont un FS qui dans les dernières versions gèrent: la compression, le snapshot, la dédup…. simplement, ils n'en ont pas l'utilité… mais quand il s'agit d'une utilisation serveur, là, ces fonctionnalités deviennent importantes.

        • [^] # Re: Zfs vs BTRFS

          Posté par . Évalué à 3.

          Quand je dis que je m'en cogne, c'est pour provoquer (j'y peut rien, j'aime bien…).
          Les commentaires jusqu'ici on été déjà très instructifs pour le coup, ce qui était mon but (merci d'ailleurs) ;)

          Maintenant, clairement, si c'est pour une machine perso… tu n'y verras pas d'intérêt.

          J'ai quelques VMs sur ma machine perso, du coup j'y vois un intérêt en fait. Mais bon, c'est sûr que ma machine ne servira pas a la famille Michu.

          Pour ce qui est de windows, il me semble avoir entendu parler d'un nouveau FS, mais je ne me souviens plus du nom. En tout cas NTFS est un sacré progrès comparé aux FATs, que ce soit pour le stockage de gros fichiers ou la fragmentation réduite. Pour ceux qui bidouillent un peu plus, le système de droits est un plus aussi. Après… je serai complètement incapable de dire si c'est mieux que ext4 ou pas. Quoique, je vois un avantage à NTFS: il y a un défragmenteur officiel. On dit souvent qu'il n'y a pas de fragmentation sur ext*, mais ça m'a toujours paru très surprenant comme affirmation.

          quand il s'agit d'une utilisation serveur, là, ces fonctionnalités deviennent importantes.

          Forcément.

          • [^] # Re: Zfs vs BTRFS

            Posté par . Évalué à 1.

            Effectivement, ext* ne fragmente pas….. du moins dans de bonnes conditions ;-).
            Il faut un minimum d'espace pour que de nouvelles données soient écrites non-fragmentées.
            La diff entre ext* et les FS MS (du moins les FAT*) vient de leur logique lors de l'écriture.
            Logique MS (pour NTFS je n'ai pas l'info, mais vu la présence de defrag, je pense que c'est encore le cas !), j'ai un fichier à écrire, je prends les premiers blocks dispos et j'écris… du coup, je découpe pour remplir les trous
            Logique ext*, je cherche le premier espace assez grand pour contenir ma donnée entière (c'est plus long, mais mieux dans le long terme). Biensûr, cette approche est possible tant qu'il reste assez d'espace pour y mettre la donnée entière en un bloc.

            La plupart des FS (si ce n'est tous) n'aiment pas le manque d'espace, ZFS et WAFL ne font pas exception. Netapp indique clairement qu'il ne faut pas dépasser 90%-95% de remplissage des aggrégats sinon: dégradation de perf et nécessité de réallocation (et là, quand t'es en prod, tu sers les fesses pour ne pas créer trop de latence dans les applicatifs qui se servent de la baie)

            • [^] # Re: Zfs vs BTRFS

              Posté par . Évalué à 2.

              Logique MS (pour NTFS je n'ai pas l'info, mais vu la présence de defrag, je pense que c'est encore le cas !), j'ai un fichier à écrire, je prends les premiers blocks dispos et j'écris… du coup, je découpe pour remplir les trous

              NTFS utilise des extents, tout comme ext*. C'est la raison pour laquelle il fragmente largement moins que FAT*

              ext* auraient aussi de temps en temps besoin d'une défragmentation, même s'ils fragmentent encore moins que NTFS. NTFS le fait tout seul, lui (grâce à Windows, mais tout de même…).

              "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

              • [^] # Re: Zfs vs BTRFS

                Posté par . Évalué à 2.

                NTFS le fait tout seul

                Tu parle de lancer une tâche hebdomadaire pour faire un defrag ? Du coup tu peux aussi dire que FAT le fait aussi, hein ?

                Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                • [^] # Re: Zfs vs BTRFS

                  Posté par . Évalué à 2.

                  Bah non, vu que ça n'a jamais existé avant Vista, et que Vista n'est pas installable sur une partition en FAT*. :p

                  "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                  • [^] # Re: Zfs vs BTRFS

                    Posté par . Évalué à 1.

                    Le planificateur Windows existait déjà sous Windows 95… Et sous Windows NT 3.x. Où on avait aussi la formidable commande "at".

                    • [^] # Re: Zfs vs BTRFS

                      Posté par . Évalué à 2.

                      Certes.

                      Mais déjà, le défragmenteur intégré à Windows date de Windows NT 4.

                      Et au sein de la branche 9X, les tâches planifiées datent de Windows 98 (c'était précemment dans Microsoft Plus! on dirait, mais pas dans 95 de base).

                      Bref, toujours est il que la défragmentation planifiée et exécutée de manière automatique de base, ça date de Vista.. :)

                      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                      • [^] # Re: Zfs vs BTRFS

                        Posté par . Évalué à 5.

                        Euh… Ouai… C'est n'importe quoi. Tu peux le faire avec Vista et une partition FAT (même si ce n'est pas ta partition systèmes). Tu va expliquer qu'ext4 fait du rollback, parce qu'une distribution installe photorec en standard ?

                        Ntfs ne fait pas de defrag, Windows depuis Vista inclus de base une solution de contournement.

                        Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                        • [^] # Re: Zfs vs BTRFS

                          Posté par . Évalué à 1. Dernière modification le 03/03/16 à 22:32.

                          Ntfs ne fait pas de defrag

                          Non, il utilise des extents. Tout comme ext*. Et ext* ne fait pas de défrag non plus.

                          Windows depuis Vista inclus de base une solution de contournement.

                          C'est bien ce que j'ai dis dès le début.

                          Ce que j'ai dit (qui n'est pas ce que tu as cité) :

                          NTFS le fait tout seul, lui (grâce à Windows, mais tout de même…).

                          = L'utilisateur n'a pas à s'en soucier.

                          C'était un peu provoc', mais toujours est-il que quand j'ai une partition ext fragmentée, la solution n'est PAS :
                          1° tout déplacer ailleurs et remettre tout sur la partition (WUT ?! Sérieusement ?)
                          2° Un défragmenteur qui n'existe pas / que personne n'a testé.
                          3° Un défragmenteur pour ext2 qui fout la merde (LOL)
                          4° Acheter un SSD (z'avez vu le prix ?)

                          Tu peux le faire avec Vista et une partition FAT (même si ce n'est pas ta partition systèmes).

                          Si tu veux, mais on s'en fiche de FAT ! ->
                          1° Pourquoi tu utiliserais FAT pour ta partition système sous Windows ? Pour la nostalgie ? (par ailleurs l'installeur de Windows depuis Vista refuse. Pour lui c'est NTFS sinon rien).
                          2° L'usage de FAT32 est aujourd'hui restreint aux supports externes. Pour tout dire, aux clés USB (sur un HDD externe, NTFS est un choix tout à fait valable pour Linux et Windows). Et on ne risque pas de défragmenter une partition USB, à part pour la flinguer.

                          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                          • [^] # Re: Zfs vs BTRFS

                            Posté par . Évalué à 4.

                            L'usage de FAT32 est aujourd'hui restreint aux supports externes.

                            Il me semble que c'est aussi le format utilisé pour la partition de boot dans les systèmes utilisant secureboot. À confirmer.

                            • [^] # Re: Zfs vs BTRFS

                              Posté par . Évalué à 2.

                              C'est exact.

                              "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

      • [^] # Re: Zfs vs BTRFS

        Posté par . Évalué à 2.

        j'aimerai, mais je n'ai pas les compétences

        Ok mais tu as surement déjà entendu parler de wikipedia, non ?

        Ensuite ton propos récursif : pourquoi utiliser ext3/4 alors qu'il y a ext1/2 ? Et d'autre FS avant.

        Si toi tu t'en cogne, sache que les distro font ce travail de réflexion pour toi.
        Et du coup tu dois faire le choix de la distro (putain c'est encore récursif!).

        • [^] # Re: Zfs vs BTRFS

          Posté par . Évalué à 2. Dernière modification le 06/03/16 à 22:34.

          Ok mais tu as surement déjà entendu parler de wikipedia, non ?

          Non, qu'est-ce?

          Plus sérieusement, te conseilles d'être patient si tu veux avoir des informations correctes sur les FS sur wikipedia. Les diverses fois ou j'ai essayé, j'ai échoué.

    • [^] # Re: Zfs vs BTRFS

      Posté par . Évalué à 3. Dernière modification le 03/03/16 à 14:06.

      On a un test de perfs récents dans un rapport de projet de fin d'étude. Btrfs a l'air d'assurer de plus gros débits que Zfs, mais la question de la stabilité est posée.

      C'est clairement la question du choix du contrôleur utilisé pour les benchs qui est posé dans ce rapport. ZFS a besoin de connaître la géométrie réelle des disques (taille des secteurs notamment) , hors là, le test est fait avec une carte raid qui exporte chaque disque en disque logique RAID0 et il est très fortement conseillé de passer par des cartes HBA pour ZFS. En effet très souvent ces cartes raid remontent des informations fausses concernant la géométrie réelle des disques. Sans compter qu'en plus la P410i est connue pour être buggué avec certaines commande scsi. A noter que les disques eux mêmes peuvent remonter des fausses informations, certains indiquent qu'ils ont des blocs de 512o alors qu'ils bossent en interne en 4ko (ou l'inverse). Bref le choix des cartes controlleurs, des disques et des bonnes options à passer lors de la création d'un zpool est prépondérant à son bon fonctionnement.

      un exemple d'utilisation de la p410i avec zfs https://amk1.wordpress.com/2013/11/22/zfs-with-hp-smart-array-p410i/, rien qu'en activant le cache de la carte , il gagne 100% de débit lors des écritures .

  • # j'adore

    Posté par (page perso) . Évalué à 5.

    "Oracle is the primary copyright holder of ZFS, and, despite nearly eight years (going back to the days of Sun's control of the code) of the anti-license-proliferation community's urging, Oracle continues to license their code under their own, GPL-incompatible license."

    Arf arf. les pauv' petits qui supportent pas une autre licence incompatible. Les BSDistes aigris et mangeurs d'enfants apprécieront l'ironie.

    Sur ce je retourne à mon zpool…

    les pixels au peuple !

  • # Drôle d'argument

    Posté par (page perso) . Évalué à 2.

    le module zfs.ko ne peut être compilé sans les entêtes du noyau

    On peut dire cela de tout programme ou toute bibliothèque qui utilise des fonctions venant d'un tiers composant logiciel (ici le noyau). Si par exemple j'écris un programme qui utilise la zlib je vais devoir lire zlib.h dans mon programme, mais ça n'en fait pas un produit dérivé! Qu'est-ce que c'est que cet argument farfelu? Y-a-t'il un détail plus subtil?

    • [^] # Re: Drôle d'argument

      Posté par . Évalué à 5.

      " mais ça n'en fait pas un produit dérivé!"

      Si justement. Le principe est : est-ce que ton programme continue de tourner si tu vires zlib. Si oui, cela va, sinon tu es en violation de la licence.

      En gros, dans le cas de zlib, il faudrait pouvoir gérer d'autres lib de compression, que zlib ne soit qu'une sorte de plugin.

      zlib n'étant pas en GPL, le problème ne se pose pas.

      C'est exactement la différence entre GPL et LGPL. Il existe aussi la variante GPL + exclusion concernant certaines interfaces "public" (les bouts de code de gcc inclus dans les binaires).

      C'est aussi le but de Readline qui n'était fournis qu'en GPL pure, pour n'être utiliser qu'en GPL.

      On comprend aussi l'acceptation des codes de drivers Nvidia en format proprio, car c'est un code qui fonctionne d'abord sous windows, et n'a pas besoin de Linux pour être utile. C'est le cas aussi pour un vieux FS (celui de minix ?).

      "La première sécurité est la liberté"

      • [^] # Re: Drôle d'argument

        Posté par (page perso) . Évalué à 2.

        Si justement. Le principe est : est-ce que ton programme continue de tourner si tu vires zlib. Si oui, cela va, sinon tu es en violation de la licence.

        Merci pour cet éclaircissement. Je n'avais jamais réalisé que la définition de produit dérivé pour la GPL était si large!

      • [^] # Re: Drôle d'argument

        Posté par (page perso) . Évalué à 1. Dernière modification le 03/03/16 à 15:03.

        On comprend aussi l'acceptation des codes de drivers Nvidia en format proprio, car c'est un code qui fonctionne d'abord sous windows, et n'a pas besoin de Linux pour être utile. C'est le cas aussi pour un vieux FS (celui de minix ?).

        zfsonlinux est un portage du code existant chez BSD et Solaris (via le projet OpenZFS). La majorité du code est identique.
        Dans le git on voit passer des merges de FreeBSD et tout. Exemple.

        Je ne suis pas un juriste, mais pour moi on est exactement dans le même cas que tu cites pour Nvidia. Un grande partie du code est utilisé en dehors de Linux.

        • [^] # Re: Drôle d'argument

          Posté par . Évalué à 1.

          Non, le cas est complètement différent. Nvidia accèpte que son code soit exécuter dans Linux.

          Le code open source de ZFS dispose d'une licence qui est explicitement incompatible avec la GPL.

          "La première sécurité est la liberté"

          • [^] # Re: Drôle d'argument

            Posté par (page perso) . Évalué à 3.

            Je suis à peu près persuadé que le projet OpenZFS (qui soutient officiellement ZFS on Linux) accepte également que son code tourne sous Linux :-)
            Alors oui, ça se trouble en effet si on considère tous les contributeurs.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.