Vous n'êtes pas identifié(e).
Vous pouvez effectuer une sauvegarde de votre profil, un exemple ici pour le navigateur firefox
Lorsque profile-sync-daemon est installé tapez dans le terminal
Cela créera le fichier psd.conf dans le répertoire /home/$USER/.config/psd/ et vous verrez alors ce message apparaître.
Éditez psd.conf (xxxx votre nom d'utilisateur)
Décommentez la ligne BROWSERS en enlevant le # et ajoutez votre ou vos navigateurs, exemple ci-dessous pour chromium et firefox
et sauvegardez la configuration (ctrl+o puis entrée et ctrl+x)
Activez et démarrez le service psd :
Vérifier si le service psd a été démarré ou non :
q pour quitter
Cependant il y a un bug sur debian concernant profile-sync-daemon et il faut modifier le fichier profile-sync-daemon qui se trouve dans /usr/bin/
et remplacer cette ligne
par
et sauvegardez (ctrl+o puis entrée et ctrl+x)
Vous pouvez maintenant avoir un aperçu de ce que fait exactement psd en passant l'option -p
exemple :
Par défaut, Profile-sync-daemon s'exécute toutes les heures. Vous pouvez cependant le modifier selon vos souhaits en configurant une tâche cron pour psd.
exemple pour une exécution toutes les 15 minutes (1 heure devrait suffire):
Pour nettoyer les instantanés de récupération vous pouvez vous servir de la commande
faites le seulement si vous n'avez plus besoin de ces instantanés.
Dernière modification par Anonyme-14 (07-01-2023 16:51:19)
remplacer cette ligne
[[ -h /sbin ]] || PATH=$PATH:/sbin
par[[ -h /usr/sbin ]] || PATH=$PATH:/usr/sbin
C'est absurde.
Le test -h est vrai si l'argument est un lien symbolique. La version originale ajoute /sbin au PATH si ce n'est pas un lien symbolique. Ce test est ridicule car si /sbin est un lien symbolique pointant vers /usr/sbin comme c'est le cas dans les systèmes avec /usr-merge (par défaut depuis Debian 10), alors l'ajouter au PATH marchera aussi bien que si c'est un vrai répertoire.
La version modifiée est encore plus absurde car /usr/sbin n'est jamais un lien symbolique donc le test est toujours faux et /usr/sbin est toujours ajouté au PATH. D'autre part si le but est d'exécuter modinfo (vu dans le rapport de bug cité), celui-ci est encore installé dans /sbin donc ça ne marchera pas avec un système sans /usr-merge.
La seule vraie solution fiable, c'est d'ajouter les deux répertoires au PATH inconditionnellement.
Dernière modification par raleur (07-01-2023 13:42:09)
Il vaut mieux montrer que raconter.
Hors ligne
tu verras l'erreur
Retour d'expérience puis lancé dans des recherches à corps perdu sur internet pour trouver la solution et y remédier
lis le lien concernant le bug, cela a été corrigé dans les nouvelles versions mais il semble que les paquets utilisent encore l'ancienne et toujours sur bullseye apparemment.
I think just adding following line could fix the problem.
Et la modification apportée dans testing/sid semble différente :
* Add /sbin to PATH. (Closes: #932345)
Edit: je n'ai pas vérifié dans le paquet Debian, mais la correction amont a consisté à remplacer la ligne par
https://github.com/graysky2/profile-syn … -daemon.in
Dernière modification par raleur (07-01-2023 14:39:40)
Il vaut mieux montrer que raconter.
Hors ligne
affichait le message d'erreur
une fois le chemin modifié cela affiche (j'ai remplacé toulibre par utilisateur)
je teste après ça et c'est le jour et la nuit.
Que suggèrerais-tu de mettre dans ce chemin ?
Je ne comprends pas tes arguments si tu ne mets pas la ligne complète.
Je ferais un test ensuite pour voir si tout est ok et je modifierais dans le tuto avec plaisir
Edit : ooops je n'avais pas vu le lien que tu proposes (différent du lien du bug que j'ai mis dans le tuto)
Dernière modification par Anonyme-14 (07-01-2023 16:47:18)
donc remplacé par
Merci
Niveau performance il est clair que c'est plus rapide, cela fonctionne c'est certain et je suis très content du résultat
(...) c'est le jour et la nuit.
A ce point ? J'aurais tendance à penser que de toute façon s'il y a assez de RAM tous ces fichiers vont finir de façon permanente dans le cache en RAM donc leur lecture sera aussi rapide que dans un tmpfs. Quant à l'écriture, grâce au cache elle ne devrait pas non plus ralentir les applications si celles-ci ne passent pas leur temps à faire des "sync" et attendre la synchronisation des écritures en cache vers le disque. La seule différence significative, c'est que psd fait l'équivalent de "précharger" (preload) les fichiers en RAM avant que les applications y accèdent.
Dernière modification par raleur (07-01-2023 19:41:04)
Il vaut mieux montrer que raconter.
Hors ligne
Si tout le monde pense pareil, c'est qu'aucune personne ne pense beaucoup.
Intel® Core™2 Duo E8500 × 2
4,0 Gio DDR3 - 1333 MHz
Et si vous cherchiez votre solution dans le wiki => https://debian-facile.org/accueil
Hors ligne
pas compliqué !
puis en allant dans l'onglet "Statistiques RCWN"
sans psd le nombre de fois où le cache est lent et le nombre de fois où le cache est rapide est à peu près égal même en continuant la navigation
avec psd le nombre de fois où le cache est rapide est plus important même en continuant la navigation
d'où ce ressenti de rapidité (?) m'enfin je ne suis pas un grand spécialiste de la question