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.
Aller plus loin
- Annonce de Canonical (239 clics)
- l'avis du Software Freedom Conservancy (194 clics)
- Réponse de Canonical aux questions relative à la licence (253 clics)
- Qu'est ce que ZFS? (798 clics)
- Qu'est ce que la CDDLv1? (467 clics)
# Base de la position de Canonical
Posté par Hobgoblins Master (Mastodon) . É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 :
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 barmic . Évalué à 7.
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).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Base de la position de Canonical
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
À ma connaissance, Btrfs n'a pas encore été officiellement annoncé comme stable.
[^] # Re: Base de la position de Canonical
Posté par Trollgouin . Évalué à 7.
Il est même utilisé en production dans quelques coins, notamment sur certains téléphones.
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 chimrod (site web personnel) . Évalué à 7.
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 freem . Évalué à 1.
Un peu comme ext?
[^] # Re: Base de la position de Canonical
Posté par peikk0 . É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 Kerro . Évalué à 4.
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 cluxter . Évalué à 3. Dernière modification le 08 mars 2016 à 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 KiKouN . É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 Nicolas Boulay (site web personnel) . É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 flan (site web personnel) . Évalué à 8. Dernière modification le 08 mars 2016 à 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 Kerro . Évalué à 4.
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 YBoy360 (site web personnel) . É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 peikk0 . É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 xcomcmdr . É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 YBoy360 (site web personnel) . É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 Ermaion (site web personnel) . É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 Joris Dedieu (site web personnel) . Évalué à 3.
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 Eiffel . É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 Pol' uX (site web personnel) . Évalué à 10.
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 Sytoka Modon (site web personnel) . Évalué à 10.
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 THE_ALF_ . É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 Christophe "CHiPs" PETIT (site web personnel) . É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 Juke (site web personnel) . É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 freem . É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:
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 Juke (site web personnel) . Évalué à 4.
Un compilateur n'est pas le seul moyen de produire un binaire exécutable.
[^] # Re: Unpotentielsacrébourbier
Posté par freem . É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 barmic . É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).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Un potentielsacrébourbier
Posté par kowalsky . Évalué à 0.
Avec cette logique, on pourrait dire que si il n'a pas les droits root, il pourrait les acquérir…
[^] # Re: Unpotentielsacrébourbier
Posté par Juke (site web personnel) . Évalué à 5.
non, ça n'a rien à voir.
faire un hexedit/dd/cp/vim/gcc ce n'est pas la meme chose que d'exploiter une faille.
[^] # Re: Un potentiel sacré bourbier
Posté par Romeo . Évalué à 4.
Si le pirate le désire il va bootstraper gcc…
[^] # Re: Un potentiel sacré bourbier
Posté par Sytoka Modon (site web personnel) . É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 Malizor . É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 claudex . É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 Storm . Évalué à 8.
Debian*
Vous pouvez moinsser ;)
[^] # Re: Un potentiel sacré bourbier
Posté par freem . É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 xcomcmdr . É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 !)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Un potentiel sacré bourbier
Posté par barmic . Évalué à 10.
Te taire ce serait encore plus simple :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Un potentiel sacré bourbier
Posté par Yth (Mastodon) . Évalué à 10.
Ç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 barmic . Évalué à 10.
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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Un potentiel sacré bourbier
Posté par plic . Évalué à 10.
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 Anonyme . Évalué à -10. Dernière modification le 07 mars 2016 à 20:10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Rappel des règles de modération en vigueur
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
Merci de rester courtois dans les échanges conformément aux règles de modération en vigueur sur le site.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Un potentiel sacré bourbier
Posté par Anthony Jaguenaud . Évalué à 4.
Oui, je le fais régulièrement.
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 Yth (Mastodon) . É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 : 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 !
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.
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 kantien . Évalué à 2.
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 Yth (Mastodon) . É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 kantien . Évalué à 2.
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 ?
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 :
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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Un potentiel sacré bourbier
Posté par Anthony Jaguenaud . Évalué à 5.
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 xcomcmdr . Évalué à 2. Dernière modification le 09 mars 2016 à 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 Yth (Mastodon) . É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…
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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Un potentiel sacré bourbier
Posté par Thomas Debesse (site web personnel) . Évalué à 5.
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
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Un potentiel sacré bourbier
Posté par kantien . Évalué à 10.
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.
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
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 xcomcmdr . É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 !)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10. Dernière modification le 13 mars 2016 à 16:52.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10. Dernière modification le 08 mars 2016 à 20:44.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Un potentiel sacré bourbier
Posté par Yth (Mastodon) . É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 freem . Évalué à 4.
Ce qui est de la connerie, c'est:
C'est la soluce choisi par Débian, je vois 3 fautes: soluce/solution, choisi/choisie Débian/Debian.Encore, le texte corrigé aurait été difficile à comprendre sans, j'aurais compris, mais même pas.
[^] # Re: Un potentiel sacré bourbier
Posté par Storm . É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 Sytoka Modon (site web personnel) . É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 freem . É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 Nicolas Boulay (site web personnel) . Évalué à 6.
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 kantien . Évalué à 1.
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 rictus (site web personnel) . É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 ! ;-)
# Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Y a-t-il vraiment un risque ?
Posté par Albert_ . É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 fredoche . Évalué à 7. Dernière modification le 02 mars 2016 à 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 SalvadorDalek . É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 Maclag . É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 freem . É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 claudex . Évalué à 4.
Oui, je vois que tu ne lis pas assez le site :)
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).
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 barmic . Évalué à 4.
Sachant que Linus n'aime pas la GPLv3 (cf ton lien), ça va être sympathique de remplacer toutes les sections incriminer :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Y a-t-il vraiment un risque ?
Posté par Renault (site web personnel) . É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 barmic . É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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Y a-t-il vraiment un risque ?
Posté par Albert_ . É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 lasher . É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 Misc (site web personnel) . É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.
[^] # Re: Y a-t-il vraiment un risque ?
Posté par groumly . Évalué à 6.
La cddl permet ce que fait ubuntu, c'est la gpl qui ne le permet.
Si c'etait pas le cas, les avocats d'oracle auraient deja enterre ubuntu.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Y a-t-il vraiment un risque ?
Posté par Misc (site web personnel) . Évalué à 5.
Oracle a aussi du code en GPL dans Linux (btrfs, oc2fs), donc ils sont globalement à pied d'égalité avec les autres personnes ayant la capacité de porter plainte (modulo le fait que eux, ils sont mieux équipés).
Ensuite, Oracle peut aussi avoir décidé pour le moment de pas utiliser ça et faire comme Microsoft et Android. À aucun moment Microsoft n'a été en frontal avec Google sur la question des brevets, car c'est bien plus rentable d'aller demander de l'argent à chaque OEM.
Cf:
http://thenextweb.com/microsoft/2013/05/07/inside-microsofts-android-patent-deals-how-much-money-is-the-company-making-in-reality-and-how-much-will-it-make-in-a-few-years/
http://arstechnica.com/tech-policy/2014/06/chinese-govt-reveals-microsofts-secret-list-of-android-killer-patents/
Attaquer Ubuntu, ça va juste rien apporter, la boite va pas être rentable. Aller voir Amazon ou Azure le jour ou ils respectent pas la license, ça, ça va être bien mieux (avec point bonus qu'Oracle va pouvoir dire "notre OS n'a pas de risque juridique").
# Zfs vs BTRFS
Posté par Trollgouin . É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 barmic . Évalué à 7.
C'est pas surtout parce que c'est assuré par dm-crypt ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Zfs vs BTRFS
Posté par steph1978 . Évalué à 3.
Je pensais la maturité. Mais je lis ZFS 2004, Btrfs 2007. Donc pas si pertinent.
[^] # Re: Zfs vs BTRFS
Posté par steph1978 . É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 marsupilamies . É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 freem . Évalué à 1.
Sérieux, les autres ne le font pas?
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 marsupilamies . É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 barmic . Évalué à 4.
Où est HAMMER FS dans le lot ? Il me semble qu'il a moins de fonctionnalité ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Zfs vs BTRFS
Posté par kna . É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 freem . Évalué à 2.
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 Sytoka Modon (site web personnel) . Évalué à 2.
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 Nicolas Boulay (site web personnel) . É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 flan (site web personnel) . É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 marsupilamies . É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 Nicolas Boulay (site web personnel) . É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 Nicolas Boulay (site web personnel) . É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 marsupilamies . É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 barmic . Évalué à 3.
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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Zfs vs BTRFS
Posté par marsupilamies . É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 marsupilamies . Évalué à 1.
Je me réponds à moi-même. Il semble que BTRFS-ZFS-WAFL soient des FS utilisant la fonction ROW (Redirect on Write), LVM est COW (Copy on write), pour le snapshot. Ouf, sinon, il faut que je change de métier !
http://ram.kossboss.com/zfs-btrfs-are-row-not-cow-redirect-on-write-not-copy-on-write/
[^] # Re: Zfs vs BTRFS
Posté par Sytoka Modon (site web personnel) . É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 steph1978 . É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 Victor STINNER (site web personnel) . É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 freem . Évalué à 2.
Une question:
Ça marche comment, les backup?
[^] # Re: BTRFS
Posté par Moonz . Évalué à 9.
Tu fais un snapshot en read only de la partition que tu veux sauvegarder (par exemple
/home) :Tu peux ensuite en faire ce que tu veux, par exemple l’envoyer en SSH sur un serveur distant :
Tu peux même faire du backup incrémental :
Pour restaurer, c’est un poil plus technique, mais rien d’insurmontable :
[^] # Re: BTRFS
Posté par freem . É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 Moonz . É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 fichiersbtrfs. 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 freem . É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 marsupilamies . É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 freem . É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) ;)
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.
Forcément.
[^] # Re: Zfs vs BTRFS
Posté par marsupilamies . É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 xcomcmdr . Évalué à 2.
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 barmic . Évalué à 2.
Tu parle de lancer une tâche hebdomadaire pour faire un defrag ? Du coup tu peux aussi dire que FAT le fait aussi, hein ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Zfs vs BTRFS
Posté par xcomcmdr . É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 Dring . É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 xcomcmdr . É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 barmic . É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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Zfs vs BTRFS
Posté par xcomcmdr . Évalué à 1. Dernière modification le 03 mars 2016 à 22:32.
Non, il utilise des extents. Tout comme ext*. Et ext* ne fait pas de défrag non plus.
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é) :
= 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 ?)
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 freem . Évalué à 4.
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 xcomcmdr . É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 steph1978 . Évalué à 2.
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 freem . Évalué à 2. Dernière modification le 06 mars 2016 à 22:34.
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 Prosper . Évalué à 3. Dernière modification le 03 mars 2016 à 14:06.
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 Patrick Lamaizière (site web personnel) . É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 Michaël (site web personnel) . Évalué à 2.
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 Nicolas Boulay (site web personnel) . Évalué à 5.
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 Michaël (site web personnel) . Évalué à 2.
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 Malizor . Évalué à 1. Dernière modification le 03 mars 2016 à 15:03.
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 Nicolas Boulay (site web personnel) . É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 Malizor . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.