Suites aux remarques régulières des utilisateurs ici qui commencent à la fin de leur installation par supprimer ces Nepomuk - Akonadi - Baloo - …
-
C'est pratique, j'utilise régulièrement :
64(5.9 %)
-
J'utilise parfois :
120(11.1 %)
-
Jamais :
275(25.5 %)
-
Je désinstalle ou désactive systématiquement :
360(33.3 %)
-
Je n'utilise pas de bureau, juste la ligne de commande :
135(12.5 %)
-
« Ce ne sont pas ces fonctions là que vous recherchez » :
126(11.7 %)
Total : 1080 votes
# Jamais…
Posté par jyes . Évalué à 10.
… mais j’utilise beaucoup « locate » comme indexation automatique des fichiers, sans côté social ni sémantique.
[^] # Re: Jamais…
Posté par Ellendhel (site web personnel) . Évalué à 5.
Idem : avec des noms de fichiers et répertoires nommés "correctement" et une once de mémoire c'est très efficace. Et rapide.
[^] # Re: Jamais…
Posté par daeavelwyn . Évalué à 3.
Yes ! sudo updatedb et locate :-)
[^] # Re: Jamais…
Posté par deuzene (site web personnel) . Évalué à 8.
Je suis curieux de voir le résultat de cette commande.
Yes
Mais je doute qu'elle te soit très utile ;)
« Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »
[^] # Re: Jamais…
Posté par freem . Évalué à 2.
Moi c'est find.
Parce que mettre à jour une DB à chaque fois que je crée un fichier me paraît… excessif. Après, j'imagine que locate doit être plus rapide que find, mais est-ce capable, comme find, d'exécuter une commande sur chaque fichier trouvé ou sur le lot des fichiers trouvés? J'utilise souvent cette capacité de find, après tout (l'argument -exec) et je n'ai jamais vraiment compris le mode de fonctionnement de xargs (pourtant fournit avec le paquet find sous debian, donc j'imagine que ce doit être assez proche. Je devrais peut-être faire l'effort de lire le man au complet et de jouer avec quelques exemples?)…
[^] # Re: Jamais…
Posté par anaseto . Évalué à 7. Dernière modification le 03 décembre 2014 à 19:24.
Eh bien xargs dans l'idée c'est juste d'utiliser stdin comme source d'arguments pour une commande. Par défaut les séparateurs c'est les espaces/tabs et retours à la ligne :
équivalent à un
echo 1 2 3 4
. Tu peux limiter le nombre d'arguments avec l'option-n
pour qu'il exécute plusieurs fois echo.Et l'option
-I
de xargs, par exemple, permet de faire la même chose que le{}
du-exec
de find.qui remplace XXX par la ligne d'arguments.
Bref, xargs peut faire la même chose que
-exec
, mais est plus général (peut se combiner avec d'autres commandes).Là où le bât blesse, c'est que pour les fichiers c'est pas idéal (ils peuvent contenir des espaces), donc par défaut xargs n'est pas bon pour utiliser la sortie de find. C'est pour ça que find a une option
-print0
pour mettre des\0
entre les noms de fichiers plutôt, et xargs une option-0
qui définit le séparateur comme\0
aussi, et du coup ils peuvent travailler ensemble de façon sûre.[^] # Au sujet des séparateurs shell
Posté par freem . Évalué à 2.
Merci pour cette explication!
Hum.. je me trompe si je dis que ce que tu dis n'est valable que pour l'option {} si l'on utilise \; et non \+ en fin de commande?
===== ===== ===== ===== ===== =====
Sinon, vu que tu as l'air de toucher ta bille (en plus d'expliquer bien, je veux dire), permets-moi de profiter de ce sujet pour te demander comment tu ferais pour appliquer un traitement à chaque champ d'un fichier tabulé?
Awm permets des merveilles (je l'ai découvert récemment) mais moi, j'ai (j'avais en fait, car j'ai "réussi", mais je pense que le code qui résulte de mes tentatives est dégueu, et je ne supporte pas ça) besoin de miracles :)
Je veux dire, awk nécessite d'incorporer un nouveau langage dans une chaîne d'appel, et moi, je t'avoue que je tente de garder le code que je génère maintenable. C'est à dire que j'essaies d'utiliser le moins de langages possibles (et quand je dois en combiner plusieurs, j'essaie de les isoler dans des fichiers de code source différents ), car pour moi multiplier les langages, c'est encore pire que de multiplier les chemins d'exécution (parce que c'est toujours un humain, qui se farcit les évolutions).
Basiquement, je réceptionne un fichier tabulé (csv, pour être exact, pas toujours tabulé mais ça se gère) pouvant contenir des string.
Comment ferais-tu pour transformer les string en question en 'string', en imaginant que i puisse être un espace (mais pas une tabulation).
Au début, j'ai pensé à printf, qui est censé déprécier echo, et il s'agit d'une fonction pour laquelle j'ai… un certain amour, étant d'origine un développeur C recyclé en C++ (mais je n'ai jamais pu me résoudre à abandonner scanf/printf… rien, strictement rien en C++ n'ofre leur puissance et leur efficience (des regex dans un lecteur d'entrée C++, de façon aussi simple que scanf? J'attend…), ou alors c'est hors standard, donc hors de question puisqu'un standard fait la même.).
Sauf que le printf de sh considère les espaces comme des \0, des séparateurs de champs. Je pense que j'ai raté quelque chose, mais quoi?
Du coups j'utilise régulièrement awk comme un workaround à printf, mais on ne peut pas piper les commandes aussi aisément… par exemple si l'on veut virer les espaces non significatifs.
J'ai un peu lu au sujet de IFS, mais il semble que cette variable ne s'applique qu'a la fonction read, les autres outils utilisant indiféremment -f, -F, ou rien du tout (le plus souvent?).
Dans l'idéal, j'essaie de restreindre mes scripts à l'usage du standard (que ce soit POSIX ou ISO, malgré que je ne soit pas un expert, pour moi une non-conformité non-voulue ou inutile au standards du moment est un bug), même si je dois perdre 10 minutes de plus pour ça (je gagnerai 2H dans 3 ans, après tout). Je pense que seule la conformité aux standards permets de rendre un code portable, et rendre un code portable est une façon de le rendre maintenable (si c'est portable, c'est supporté par plus de langages, donc compris par plus de développeurs/admins, donc plus maintenable).
Saurais-tu comment résoudre élégamment le cas la transformation de fichiers tabulés, aux champs contenant potentiellement des espaces, en, par exemple, requêtes d'insertion sql? (peut importe le type du champ de destination, admettons que tout soit casté automatiquement)
Si utiliser perl est la seule option… peut-être que je me motiverais à l'apprendre sérieusement.
[^] # Re: Au sujet des séparateurs shell
Posté par anaseto . Évalué à 2.
Disons qu'en pratique le cas
\;
correspond à-n 1
et le cas\+
à ne pas mettre d'option. Ce n'est pas tout à fait exact, mais dans\+
de toutes façons, seul le dernier{}
est pris en compte. Après avec-I
il y a des limites de longueur à prendre en compte, en plus. Il n'y a pas une traduction parfaite entre les deux commandes non plus, c'est juste qu'en pratique on peut faire avec l'une ce qu'on veut faire avec l'autre, normalement.IFS est aussi utilisé pour la substitution de variables, mais je ne sais pas si ça t'aide.
Pour répondre au reste, je ne suis pas sûr de comprendre exactement ce qui te gêne, mais personnellement je n'aurais pas de scrupules pour utiliser un « autre langage » comme awk, sed ou perl quand ça m'a l'air plus adapté, je ne fais jamais du traitement de données non trivial purement en shell (et j'avoue que pour ça j'aurais besoin de consulter mes pages mans et réfléchir un moment). En plus le résultat a toutes les chances d'être plus lent et plus complexe au final, vu que ces autres langages sont pensés et optimisés pour ce genre de problèmes.
[^] # Re: Au sujet des séparateurs shell
Posté par freem . Évalué à 2.
Je n'ai de scrupules que quand il s'agit de mélanger les langages dans tous les sens. Par exemple, un script shell qui appelle un programme C (je veux dire, programme "maison" dont on à potentiellement perdu le source dans les brumes de l'histoire) puis passe la main à une procédure stockée qui charge un fichier, puis on repasse au shell qui envoie ce coups-ci du sql standard et qui finit par lancer un démon (fin).
Le genre de trucs que seul le dev d'origine sait, plus ou moins, qui fait quoi et comment. Juste plus ou moins, hein.
Après, mélanger les langages, ok, mais que ce ne soit pas une excuse pour faire du spaghetti, et que ce soit parce qu'il faut le faire, pas parce qu'on peut.
Au passage, j'ai du mal à considérer sed comme un langage, ou alors il peut faire des choses que je ne soupçonne même pas… ce qui ne serait pas spécialement surprenant, pour le coup.
Je pense que je devrais ré-apprendre un peu le perl, je ne serais pas étonné que ça me permette de réduire la complexité de certaines choses au taf.
# Recoll
Posté par Trollgouin . Évalué à 10.
J'ai installé Recoll pour indexer mon home. C'est un "indexeur" multi formats (en fait, ça traduit tout en texte) qui permet des recherches rapides et efficaces. Ça ne bouffe pas toute ma RAM au contraire du précédent logiciel en java que j'utilisais précédemment et dont j'ai oublié le nom.
Ça me sert peu souvent, mais quand ça me sert, ça me fait vraiment gagner du temps: un peu pour les fichiers à base de texte (markup/code/LaTeX/Mail…) mais surtout pour les formats non simplement grep-ables (pdf, ps, Opendocument, archives…).
Par contre, ça n'a aucune interaction avec mon gestionnaire de fenêtres (i3) ou avec d'autres outils (client mail, navigateur…), et je n'indexe pas en temps réel (c'est néanmoins une possibilité offerte) mais en cron la nuit.
# Tracker au désespoir
Posté par neitsab . Évalué à 4.
J'ai répondu "C'est pratique, j'utilise régulièrement" mais malheureusement après deux ans de Tracker (GNOME) qui passait sa vie à réindexer la moitié de mon disque dur à chaque redémarrage (et ce en dépit de l'ajustement des options), j'en ai eu marre et l'ai complètement désinstallé.
J'ai vu passer cinq versions de GNOME jusqu'à présent (sur la 3.14 actuellement) et ce problème ne s'est jamais amélioré, en dépit des nombreux rapports de bogues.
Cependant ça m'a fait tout drôle les premières fois où j'ai cherché à accéder directement à un dossier dans la vue des Activités !
locate
contraint à copier/coller manuellement le chemin du fichier pour l'ouvrir dans le gestionnaire de fichiers… C'est dommage, mais les performances étaient tout simplement intenables.[^] # Re: Tracker au désespoir
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 3.
J'ai également un souci avec Tracker, qui semble se crasher je ne sais quand exactement, et ne me permet pas d'accéder à toute ma musique dans gnome-music, ce qui rend cette dernière appli inutile. J'ai ce problème depuis que j'ai commencé à tester les nouvelles applis GNOME, depuis la 3.10 au moins.
Ça m'agace d'autant plus que Tracker est le fondement de la philosophie "Finding ans Reminding" de GNOME 3 : toutes les fonctionnalités intéressantes de ce bureau (une super-recherche qui trouve n'importe quel fichier, une base de données commune à toutes les applications, une suite d'applis pour naviguer parmi ses fichiers en fonction de leur type. comme sous iOS et Android, etc.) reposent sur Tracker. J'attends encore de voir cette base devenir le béton armé dont le projet a besoin.
[^] # Re: Tracker au désespoir
Posté par xcomcmdr . Évalué à 2.
On dirait les déboires de KDE4 avec Nepomuk/Baloo.
C'est tellement 2008. ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Tracker au désespoir
Posté par JoeltheLion (site web personnel) . Évalué à 2.
Est-ce que KDE a résolu le problème ?
[^] # Re: Tracker au désespoir
Posté par xcomcmdr . Évalué à 4.
Baloo est censé le résoudre et chez moi il n'y a rien à signaler
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Tracker au désespoir
Posté par JoeltheLion (site web personnel) . Évalué à 2.
Est-ce qu'il fait gratter le disque? Combien de temps met-il pour tout indexer?
[^] # Re: Tracker au désespoir
Posté par ariasuni . Évalué à 3.
Beaucoup moins de temps que Nepomuk.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Tracker au désespoir
Posté par gnumdk (site web personnel) . Évalué à 2.
Baloo fonctionne très bien et perso, je n'ai aucun problème avec Tracker…
[^] # Re: Tracker au désespoir
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 2.
Tu utilises les nouvelles applis GNOME ? Et/ou le partage de médias intégré, celui qui s'active via le Control Center ?
(ce ne sont pas des questions rhétoriques : je me demande simplement comment ces applis fonctionnent lorsque Tracker marche bien)
# Outils indispensables
Posté par xeuzuex . Évalué à 3.
Surtout lorsque tous les docs scannés l'ont été en OCR.
Perso j'ai beaucoup utilisé DocFetcher… assez simple, mais il doit y avoir mieux
[^] # Re: Outils indispensables
Posté par deuzene (site web personnel) . Évalué à 2.
Essaie Recoll. Je suis passé de l'un à l'autre, il est léger et rapide. Il utilise
xapian
pour l'indexation.« Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »
# Jamais
Posté par sebas . Évalué à 7.
Pas de ça dans XFCE. Pas à ma connaissance en tout cas. Et ça ne m'a jamais manqué.
Un bon petit find pour trouver les films, bouquins ou docs qui m'intéressent car je les nomme avec des noms signifiants ; et des grep dans les répertoires qui vont car je range mes fichiers dans des répertoires qui ont une structure logique.
Pour la musique, c'est classé par /data/music/genre/sous-genre/auteur
Pour les photos, c'est un cas à part car intégrer des tags dans les noms de fichiers peut être laborieux (mais comme je ne suis pas un fessebouquien ni un compulsif de la photo souvenir, c'est pourtant ce que je fais et ça me suffit bien : dossiers yymm_sujet puis fichiers yymm_sujet_nnnn_tag1-tag2-tagn.jpg. Sinon, pour un usage plus pointu, il y a des programmes de catalogue photos qui gèrent ça bien (et qui restent loin de la lourdeur d'un nepomuk-like).
Pour des usages simples, la meilleure base de donnée est le propre système de fichiers avec des fichiers bien rangés : c'est rapide et incassable.
[^] # Re: Jamais
Posté par jihele . Évalué à 3.
Je fais pareil, mais pour "vendre" Xfce à ses proches, c'est pas top.
Sans aller jusqu'à l'indexation des fichiers, une fonction de recherche serait pas mal. J'ajoute Catfish, mais l'intégration est manuelle et pas top, par rapport à une vraie fonction de recherche intégrée avec un trombone ou un chien.
J'ai essayé Mate, et j'ai vu une fonction de recherche simple et rapide dans le gestionnaire de fichier et un truc plus complet accessible en plus de clics. J'ai trouvé ça pas mal.
[^] # Re: Jamais
Posté par sebas . Évalué à 1.
Je n'avais jamais réalisé que cette fonction pouvait manquer pour un usager lambda, mais tu as raison, il devrait y avoir une fonction de recherche désactivable.
As-tu essayé synapse ? Il a une fonction de recherche de documents apparemment basée sur locate, peut-être cela pourrait remplir ce rôle pour tes amis.
# j'ai rien compris
Posté par Katyucha (site web personnel) . Évalué à 10.
Suis je le seul ? J'ai absolument rien compris… peut être parce que j'utilise i3wm …
[^] # Re: j'ai rien compris
Posté par patxidraks . Évalué à 2.
moi ytou, j'ai rien compris…
Il faut dire que je suis débutant sous Linux (distrib Mint) et je ne sais même pas si des outils d'indexation automatique sont intégrés…
[^] # Re: j'ai rien compris
Posté par Professeur Méphisto . Évalué à 4.
indexation des fichiers je comprend à peu près…
sémantique ça me parle depuis cette question là !
mais social ?? wtf ? je n'en comprend pas le concept. Peut-être parce-que je suis asocial justement
/me va googler les trois noms fournis en exemple
[^] # Re: j'ai rien compris
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 2.
Ce sont peut-être des termes un peu surannés.
Je connais mal Akonadi, Nepomuk et autres (ne sont-ce pas toutes des technologies KDE ?), mais je crois que ce que la plupart des bureaux modernes cherchent à avoir, c'est un système qui répertorie les fichiers présents sur l'ordi, pour pouvoir visionner et manipuler ces derniers selon des critères autres que leur seul placement dans l'arborescence (genre dans un outil de recherche intelligent, ou bien dans une appli comme celles que préparent Ubuntu ou GNOME).
Je réalise que là, je décris surtout ce que fait Tracker. Mais à moins qu'une feature ne m'échappe, je ne crois pas que cette description justifie l'emploi de buzzwords comme "bureau social" qui me semblent appartenir à une époque révolue (dit-on aujourd'hui d'OS X ou de Windows 8 qu'ils sont "sociaux" ou "sémantiques" ? Et des OS de smartphones ?)
[^] # Re: j'ai rien compris
Posté par Tonton Th (Mastodon) . Évalué à 4.
Ce n'est pas un peu ce que faisait BeOS ?
[^] # Re: j'ai rien compris
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Un bureau social, je pense que c'est un bureau avec quelque part un bouton bleu en forme de pouce levé.
[^] # Re: j'ai rien compris
Posté par Physche . Évalué à 3.
J'aurais pensé qu'un bureau social c'était un bureau dont la porte était toujours ouverte.
[^] # Re: j'ai rien compris
Posté par jihele . Évalué à 6.
Oui, pour foutre les salariés dehors avec un plan social.
# Très souvent
Posté par flan (site web personnel) . Évalué à 2.
Je n'utilise absolument pas le côté social (à vrai dire, je ne vois pas trop ce que c'est) mais très souvent le moteur d'indexation. Au début (en 2005), je l'utilisais assez peu, mais maintenant très souvent, que ce soit pour ouvrir un programme (en ne tapant que les deux voire trois premières lettres), trouver un fichier (avec le début de son nom ou un mot à l'intérieur) ou pour d'autres petites opérations. La barre de recherche est accessible avec un raccourci clavier (sinon, ça perd tout son intérêt), et me permet d'accéder à bien plus que mes fichiers vu qu'il essaie de trouver l'opération la mieux adaptée à ma requête :
En pratique, il arrive bien à deviner quelle réponse il doit proposer en premier (même si les autres sont bien évidemment accessibles).
Bien sûr, ça ne m'empêche pas d'avoir des dossiers bien rangés, mais les parcourir à la main reste plus lent, même en sachant exactement où est le fichier et quel est son nom.
[^] # Re: Très souvent
Posté par openbar . Évalué à 1.
Mais la vraie question est: Qu'as tu répondu, quel est cet outil qui fait tant de choses que tu utilises?
[^] # Re: Très souvent
Posté par dinomasque . Évalué à 3.
Spotlight d'Apple ?
BeOS le faisait il y a 20 ans !
[^] # Re: Très souvent
Posté par flan (site web personnel) . Évalué à 2.
En effet, c'est bien Spotlight.
[^] # Re: Très souvent
Posté par sebas . Évalué à 1.
Je ne sais pas ce que fait spotlight (je suis applephobique), mais synapse, sur linux, semble faire une bonne partie de ce que tu décris. Effectivement c'est un outil pratique, tout au moins pour la partie que j'en utilise.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.