AR7 a écrit 42 commentaires

Beyond Compare, mon préféré, mais c'est pas libre : https://www.scootersoftware.com/index.php.

Pour la config de git : https://www.scootersoftware.com/support.php?zz=kb_vcs#gitwindows.

Il est top je trouve pour la résolution de conflits.

Par ailleurs, il permet de faire facilement la comparaison de plein de types de fichiers, par exemple des d'archives (pas la peine de décompresser manuellement en amont, elles apparaissent comme des dossiers).

• unoconv --stdout -f csv <ton_fichier.ods>
• odt2txt <ton_fichier.ods>

Bonjour,

Je ne connais rien à ces problématiques mais de ce que je comprends du code, cliquer sur le bouton active sssd et pam dans la conf.

Quand il applique la conf, YaST réécrit /etc/sssd/sssd.conf et relance le service sssd.

Il fait aussi quelque chose au niveau de pam en appelant YaST::Pam.Add (qui fait un /usr/sbin/pam-config -a --sss). Il modifie aussi directement /etc/pam.d/common-auth après coup, je ne comprends pas exactement pourquoi.

Peut-être ça vaut le coup de comparer ton /etc/sssd/sssd.conf, la config de pam sous /etc/pam.d/ ainsi que l'état du service sssd avant/après avoir cocher cette case ?

Maintenant SLES va sauter de 12 à 15 pour se calquer sur openSUSE:

C'est pas SLE qui calque openSUSE, c'est openSUSE qui se cale sur SLE.

SUSE éviterait les séries 13 et 14 pour SLE pour des raisons marketing. Comme expliqué, openSUSE Leap préfère se synchroniser plutôt que de sortir une version 43 (ou 45).

Voir aussi le savoureux article de LWN à ce sujet 😋

La solution d'openSUSE est techniquement différente. Elle a ses propres limites et c'est pour ça que c'est intéressant de voir ce qui se fait ailleurs…

Je n'ai pas essayé grub-btrfs mais visiblement il faut régénérer le grub.cfg sur une restauration – je pense qu'il faudrait aussi régénérer le core.img en toute rigueur ou alors j'ai pas compris – mais ça a l'avantage de fonctionner avec un grub sans patch.

Ça me fait penser que j'avais construit une AppImage d'une version de développement de GIMP pour voir à quoi ressemblait le plugin GIMP Motion. C'était le haut de la branche wip/animation du coup, pas de la branche master.

Le dépôt est là. L'AppImage réussissait à se lancer sur openSUSE Tumbleweed, Leap 42.3 et sur Debian 9 quand j'avais testé. Mais je n'étais pas allé très loin après…

J'avais fait ça avec l'Open Build Service. Cela permet d'automatiser la récupération des sources depuis un dépôt git, la construction du paquet RPM et, du coup, la création d'une AppImage à partir du paquet RPM et de ses dépendances. Il crée aussi visiblement un fichier zsync, ça doit être utile pour mettre à jour l'AppImage.

Les sources sont là.

Matthias Kirschner de la FSFE donne des clés pour comprendre la décision de Munich de repasser à Windows dans cette conférence.

1/ Sais-tu si le format du flux obtenu par btrfs send est stable au changement de version de l’outil et/ou du noyau ?

Non, je n'en sais pas plus que toi maintenant… Le wiki dit effectivement qu'un format v2 est prévu mais il n'y a quasiment aucune information sur lui. Je n'ai pas l'impression que ce soit une priorité pour l'instant.

2/ Autre fonctionnalité très intéressante de btrfs, pas forcément pertinente pour ce journal, mais je profite pour le mentionner : la possibilité de mettre un système de fichier donné sur un device en lecture seule et un device en écriture incrémentale.

Le seed device c'est ça ? Oui ça a l'air intéressant, je n'ai jamais testé mais je prends note de l'intérêt 😉

J'avais vu passer un mail sur la liste de diffusion opensuse-factory par rapport à son utilité pour les live CD. Ça pourrait être une alternative à OverlayFS.

J'ai vu cependant que la nouvelle version de KIWI (l'outil pour générer des images de distributions utilisé par openSUSE dans le Build Service) ne prenait plus en charge cette fonctionnalité.

Merci ! Mais le script est revenu à la mauvaise version du coup… Il suffit de remplacer min=${2:-100} par min=${1:-100} et subvols=${1:-…} par subvols=${2:-…}.

Un grand merci aux personnes qui corrigent les coquilles. Par contre, ce serait cool de ne pas essayer de corriger plus qu'il n'en faut 😉

ainsi que dans le manuel de [mkfs.btrfs](https://btrfs.wiki.kernel.org/index.php/Manpage/mkfs.btrfs).

Lien cassé en voulant mettre en chasse fixe je suppose.

Par exemple, les bases de données — ne serait‐ce que les bases de données SQLite de Firefox —

Moi j'utilise du demi-cadratin (–), pas du cadratin (—). C'est mon droit, non ? 😋

envoyée par btrfs filesystem df. Si !

Il me semble bien avoir mis « Si. »…

Bref, ça ne me dérange pas vraiment. Mais quand même 😉

Arg, je n'ai pas copié-collé la bonne version pour le petit script checkfrag.sh. La bonne version est celle-là :

#!/bin/sh

#
# Inspiré de https://gist.github.com/kylemanna/b5cac22b6164b14aa967
#

# Seuil d'extents en dessous duquel les fichiers ne sont pas affichés
min=${1:-100}

# Chemin des sous-volumes à analyser
subvols=${2:-/ $(btrfs subvolume list / | grep -v snapshots | awk '{ print "/"$9 }')}

# Voilà
find ${subvols} -xdev -type f -exec filefrag '{}' \+ | awk "{ if ( \$(NF-2) > $min ) print \$0 }"

J'ai juste inversé les arguments (optionnels) : le premier argument est le seuil, le second les chemins à analyser. Ça permet de faire le checkfrag.sh 3000 plus bas au lieu de checkfrag.sh "$chemins" 3000.

Si je comprends bien le sous-entendu de cette phrase : du fait des temps d'accès d'un HDD, le CPU peut sans problème passer à un autre processus, en attendant d'avoir la réponse à sa demande, alors que face à un SSD, le CPU se retrouve à switcher de processus pour revenir très vite à celui qui avait nécessité la demande au SSD ?

Oui, enfin c'est ce que je me suis dit. Après ce n'est qu'une supposition hein, autrement je ne vois pas comment expliquer cette consommation du CPU.

Il y a une petite coquille au niveau du contenu du fichier /etc/grub.d/80_suse_btrfs_snapshot :

#! /bin/sh
set -e
if [ "x${SUSE_BTRFS_SNAPSHOT_BOOTING}" = "xtrue" ] &&
   [ "x${GRUB_FS}" = "xbtrfs" ] ; then
#      ici vvvv
    cat << \EOF
if [ -f "/.snapshots/grub-snapshot.cfg" ]; then
  source "/.snapshots/grub-snapshot.cfg"
fi
EOF
fi

J'avais rajouté un \ dans mon texte car le colorateur syntaxique markdown de gedit avait un peu de mal avec cet EOF. Le vrai script est bien sûr sans \:

#! /bin/sh
set -e
if [ "x${SUSE_BTRFS_SNAPSHOT_BOOTING}" = "xtrue" ] &&
   [ "x${GRUB_FS}" = "xbtrfs" ] ; then
    cat <<EOF
if [ -f "/.snapshots/grub-snapshot.cfg" ]; then
  source "/.snapshots/grub-snapshot.cfg"
fi
EOF
fi

mais alors est-ce que tu pense qu'il y a espoir de le corriger?
(la page snapper -> overview dit "Works with btrfs, ext4 and thin-provisioned LVM volumes")

Concernant ext4, l'implémentation faite dans snapper dépend d'une version d'ext4 patchée, réalisée dans le cadre d'un projet appelé Next4. Ce projet n'a visiblement pas abouti : wiki mort, rien de mergé, pas trouvé de trace du code. Donc à moins d'un miracle, je ne vois pas comment snapper peut marcher avec de l'ext4…

Je doute un peu que cela soit réparé, il n'y a pas trop d'activité sur #331.

est-ce que tu pense que snapper sera un jour applicable à d'autres FS encore?

Je n'ai pas regardé le code de snapper pour voir comment c'est fait, ce dont il a besoin et comment cela peut évoluer. En tout cas, je n'ai pas l'impression qu'il y ait actuellement une dynamique pour rajouter le support d'autres systèmes de fichiers.

J'ai écrit une bêtise dans la partie arbre B.

J'ai mis en inconvénient qu'il fallait régulièrement équilibrer l'arbre B. C'est faux. L'arbre B implémenté dans Btrfs s'équilibre tout seul.

Ta question me laisse un peu perplexe. Personnellement, je ne préfère pas Btrfs à un autre système de fichiers :-)

Je l'utilise simplement en ce moment parce qu'il offre des fonctionnalités qui peuvent m'être utiles et parce que je trouve intéressant d'apprendre de nouvelles choses. Que Btrfs s'impose ou non, que des gens l'apprécient ou non, je trouve qu'il y a des idées dedans qui pourront peut-être (me) servir plus tard.

Cette série de journaux n'a pas pour but :

• de faire une comparaison de systèmes de fichiers
• de dire qu'il faut préférer un fs par rapport à un autre
• d'inciter à utiliser tel ou tel fs

J'écris juste pour présenter comment je comprends Btrfs en tant qu'utilisateur.

Si jamais il y a des gens qui veulent découvrir Btrfs pour voir si ça pourrait leur servir, ces quelques journaux pourront peut-être leur faire gagner un peu de temps : soit à s'en détourner, soit à l'utiliser, en leur évitant d'avoir à rechercher certaines infos et trucs de base.

+1

Pour avoir testé rapidement, je n'arrive pas à fragmenter avec LibreOffice et gedit.

Par contre, pour des fichiers souvent modifiés "aléatoirement" (je pense aux vms et bases de données notamment), le CoW peut induire beaucoup de fragmentation. Cela vaut alors le coup de le désactiver. J'en parlerai dans le prochain épisode.

Il y aura un chapitre sur la récupération de données,ce genre de choses ?

Ce n'est pas prévu pour l'instant. Mais je prends note, ça peut être intéressant.

Merci

Avec plaisir ;-)

• je n'ai pas vraiment compris ton explication du CoW. Pour moi c'est simplement que l'on fait semblant de copier une donnée A en une donnée B au moment de la copie, et on ne fait réellement la copie que lorsque B est censé être modifié (et donc différent de A). Donc on ne copie que lorsque l'on modifie (Copy on Write !).

Oui, tu as raison, c'est sans doute plus clair comme ça :-)

J'ai essayé de donner une définition générale, inspirée entre autres de ce passage du wiki Btrfs, pour ne pas avoir exactement la même définition que pour la copie paresseuse. Mais au final, c'est du pareil au même.

Salut,

Pour compléter la réponse de cyberjunkie :

En 32 bits, il n'y a plus qu'openSUSE Tumbleweed, la variante en rolling release.

Pour avoir LXDE, tu peux alors télécharger parmi les images ISO de Tumbleweed :
- soit une image d'installation par le réseau (net-install)
- soit la grosse image DVD : il te faudra quand même une connexion réseau au moment de l'installation et activer les dépôts en ligne

Dans les deux cas, tu pourras sélectionner LXDE au moment de l'installation : sur la page Computer Role, sélectionner Custom, et cocher le schéma LXDE.

Note que cette partie Computer Role a changé récemment c'est pour ça que ce n'est pas encore traduit en français.
Note aussi que LXQt, le successeur de LXDE, est également disponible.

À+

Salut,

Pour info, c'est un problème intermittent qu'on a du mal à résoudre. On cherche d'ailleurs du monde capable d'aider notamment pour la maintenance technique du forum.

On aimerait bien à terme migrer sur Discourse, mais pour l'instant le projet est au point mort.

À+

PS : bizarrement il y a moins de database errors quand tu parcours le forum en étant connecté.

Vu le passé « douteux » de Suse, ça serait bien de rajouter un paragraphe pour faire un point sur les liens entre Suse et Microsoft, notamment sur la reconnaissance des brevets logiciels indélicats et du chantage aux brevets logiciels.

Oui ça aurait été bien :-) Mais malheureusement tu ne l'as pas fait.

mais ne le sont plus et c'est bien le probleme
ensuite oui, les distribs communautaires (donc non officielles, peuvent proposer des modes "LIVE"

Juste relis ce que j'ai écrit ;-)

non puisque celles qui sont dispos ne permettent pas d'essayer la distrib LIVE
et proposent uniquement l'installation.

Je parle des images Live que j'ai décrites dans mon premier commentaire…

apres tout depend des createurs de la distrib s'ils ont voulu faire un media LIVE ou un media d'INSTALLATION, ou un media MIXTE (qui propose de live et l'installation

En l'occurrence, avec cette définition, les images Live d'openSUSE sont « mixtes » (du moins les images officielles l'étaient).