Fim 1.1.0

Posté par . Édité par Nils Ratusznik et Benoît Sibaud. Modéré par ZeroHeure. Licence CC by-sa
31
2
nov.
2015
Ligne de commande

Fim (File Integrity Manager) est un gestionnaire de fichiers libre (licence GPLv3) qui permet de gérer beaucoup de fichiers de n'importe quelle taille. Il peut par exemple, gérer des photos ou des vidéos. Il est capable de gérer des centaines de milliers de fichiers occupant une taille totale de plusieurs téraoctets. Il peut détecter les fichiers dupliqués et aider à les effacer.

Logo de Fim

Les nouveautés de la version 1.1.0 :

  • réécriture de l'algorithme de hachage pour hacher un bloc au début, un au milieu et un à la fin (détails ici) ;
  • détection de corruption due au matériel ou de bug du système de fichiers (détails ici) ;
  • sauvegarde et restauration des permissions des fichiers, utilisation des labels SELinux si disponibles (détails ici) ;
  • prise en compte des fichiers .fimignore pour ignorer des fichiers ou des répertoires (détails ici).
  • # unison

    Posté par . Évalué à 7.

    Joli projet, bravo!

    J'ai lu ton commentaire sur Korben:

    Le but de Fim est de pouvoir gérer un espace de travail.
    Et de savoir où on en est dans les modifications que l'on est en train de faire.
    Quand on fait plein de truc en même temps, les choses prennent du temps et on en perd le fil.

    Personnellement j'utilise Fim pour gérer mes photos et mes vidéos.
    Quand j'ai des nouvelles photos, je les poses au bon endroit dans mon répertoire de photos et ensuite je fais "fim ci" depuis le sous répertoire qui contient les nouvelles photos pour enregistrer ce nouvel état. Comme j'aurais fait avec Git.
    Comme je fais cela depuis un sous répertoire le commit est super rapide car Fim ne hash que les nouveaux fichiers que j'ai ajouté et il ajoute les nouveaux hash a la liste des anciens.

    La commande "fim diff" me permet de savoir quand je le veux (super rapidement même) si quelque-chose à évolué dans mon répertoire de photos.

    Je peux repérer et effacer facilement les photos que j'aurais dupliquées ailleurs sur mon disque ou sur d'autre ordi avec la commande "fim rdup". Pour cela il faut juste que je recopie le répertoire .fim sur l'autre ordi. C'est super rapide.

    Cela me fait penser à unison que j'utilise pour synchroniser tous mes documents. Malheureusement celui-ci n'est plus activement développé mais comme il est mature cela ne pose pas trop de problème pour l'instant (je l'utilise quotidiennement depuis 2 ans sans aucun soucis). Je vais garder ton projet dans un coin en cas de problème dans le future :-)

    • [^] # Re: unison

      Posté par . Évalué à 10.

      Attention, le projet de recherche qui a donné naissance à Unison n'est plus activement développé, mais ça ne veut pas dire que le logiciel lui-même ne l'est pas. Je croise de temps en temps des développeurs Unison qui sont actifs sur la maintenance, implémentent parfois des améliorations, et seraient bien évidemment d'intégrer des contributions externes.

    • [^] # Re: unison

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

      Malheureusement celui-ci n'est plus activement développé

      Si si, il est maintenu, lentement mais sûrement. Le fait d'être écrit en OCaml n'aide pas.

      Il est très stable et il marche bien, les seules améliorations que j'aimerais voir sont des améliorations assez ponctuelles d'IHM.

      Je m'en sers en triangle entre mon desktop qui me sers moins en ce moment, mon disque dur externe qui me sert beaucoup en ce moment, et un serveur dédié qui sert de backup distant.

      • [^] # Re: unison

        Posté par . Évalué à 2.

        Je n'avais par vraiment cherché plus loin que cette page à vrai dire, mea culpa. Tant mieux si il est maintenu :-) J'en suis un utilisateur heureux et je ne compte pas en changer vu qu'il est, comme déjà dit, mature est stable.

  • # ceci n'est pas une cabale

    Posté par (page perso) . Évalué à 4. Dernière modification le 02/11/15 à 23:07.

    c'est un catalogue : http://linuxfr.org/news/katal-catalogue-de-fichiers

    Il peut détecter les fichiers dupliqués et aider à les effacer.

    Je savais que j'avais déjà vu la fonction pour trouver les » doublons » de fichiers avec peu de différences (tags EXIF ou mp3) ou des points communs…

    Cela doit être dans l'air du temps :-) (trier ses photos, trier sa musique…).

    • [^] # Re: ceci n'est pas une cabale

      Posté par . Évalué à 1.

      Oui en effet, c'est la préoccupation du moment.
      De plus en plus de choses sont dématérialisées (photos, vidéos, papiers en pdf).
      Il est important de savoir où ils sont et dans quel état.
      Fim est là pour gérer tout type de contenu dématérialisé.

  • # Il existe aussi Git-Annex

    Posté par . Évalué à 1.

    Git a inspiré git-annex

    Pour Gérer, Archiver ou Sauvegarder ses fichiers de manière totalement décentralisée (ou pas) à la Git
    (d’ailleurs il utilise Git)

    http://git-annex.branchable.com/.

    • [^] # Re: Il existe aussi Git-Annex

      Posté par . Évalué à 3.

      J'ai déjà eu l'occasion de tester ce soft pour mon propre cas d'utilisation que je décris :

      Gérer un catalogue de fichiers qui garde une trace des fichiers que j'ai déjà utilisés et volontairement effacés.
      Par exemple, si j'ai déjà visionné un podcast que j'ai mis de coté et que je le récupère à nouveau, je veux que le produit me le signale. S'il est nouveau, je veux qu'il l'insère et si c'est un doublon qu'il le ne rajoute pas au catalogue.

      De part sa conception qui s'appuie sur l'historique, il permet de visualiser chaque différence mais ne permet pas de comparer de manière agrégée au catalogue entier (englobant les déjà vu), je n'y suis pas parvenu. Je n'ai pas besoins des états intermédiaire mais bien de pouvoir compare à tout mon catalogue présent et passé.

      Du coup j'ai du mal à saisir l'intérêt.
      Pour checker l'intégrité de fichier Ok (encore que pas besoin d'historique) mais
      si c'est pour pouvoir gérer des gros fichiers avec Git, il vaut mieux se tourner vers un projet qui est soutenu par des grands du domaine (Github et Atlassian), qui ont uni leur force pour initier le projet suivant https://github.com/github/git-lfs
      Au moins ça reste compatible de base avec Git et on bénficie de toute la tuyauterie associée, non ?

      Plus d'info ici:
      http://www.infoq.com/news/2015/04/github-large-file-storage
      ```
      git lfs track "*.pdf"
      git add file.pdf
      git commit -m "Add design file"
      git push origin master

      • [^] # Re: Il existe aussi Git-Annex

        Posté par . Évalué à 2.

        Les deux outils (annex, git-lfs) semblent intéressant. J'ai essayé les deux. Je dirais même que lfs est vraiment très bien.
        Mais ils semblent répondre à des cas d'utilisation très poussés avec un remote.
        Fim à été créé pour être super simple mais puissant en même temps.
        Le hashage des fichiers est réalisé avec plusieurs thread en parallèle.
        Et on a facilement un status clair des fichiers renommé, déplacé ou dupliqués ce que je n'ai pas réussi à avoir simplement avec annex ou lfs.
        De plus Fim à la mode super fast.

  • # This is javaaa

    Posté par . Évalué à 2.

    This tool is written in Java.

    (smiley qui vomit)
    Pourquoi ? Pourquoi ? Sérieusement. 2015 bordel.

    • [^] # Re: This is javaaa

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

      Que proposes-tu d'autre ?

      • [^] # Re: This is javaaa

        Posté par . Évalué à 1.

        Tout sauf java et vb.

        • [^] # Re: This is javaaa

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

          Et pour quelle raison au fait ?

          • [^] # Re: This is javaaa

            Posté par . Évalué à 3.

            utilisez un truc sans jvm en 2015 surtout quand cette dernière est de la merde.

            • [^] # Re: This is javaaa

              Posté par . Évalué à 3.

              Source ?

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

              • [^] # Re: This is javaaa

                Posté par . Évalué à 8.

                L'expérience.

                En tant que sysadmin : Java et Tomcat sont des joyeusetés dont on aimerait se passer. Il faut provisionner un max de RAM et de CPU sur les serveurs pour des trucs qui pourraient fonctionner en Python ou même en PHP avec 4 fois moins de ressources. Sans compter les plantages avec les debug incompréhensibles.

                En tant que (ex) technicien helpdesk : Il faut faire cohabiter plusieurs versions de Java en fonction de ce que demande les applications, il faut désactiver les popup de mise à jour sur Java car de toutes manières ça marche jamais , il faut mettre à jour toutes les semaines pour combler les trous de sécurité, il faut renouveler les machines car afficher une simple fenêtre demande 200Mo de ram. Ah oui et j'adore me connecter sur un KVM IP ou un Switch et constater que son webui demande une version préhistorique de Java, genre la 1.5, sur laquelle il va falloir valider 450 Fois "êtes vous sur?" "cette application n'est pas signée" "voulez vous exécuter?" "voulez vous mettre à jour ou ignorer" ?

                Quand je vois parler d'optimisation avec JVM je comprends pourquoi nous en sommes rendus à des OS qui demandent 4GB de RAM minimum pour démarrer et des navigateurs qui en prennent 2 pour afficher 3 onglets. J'espère que Java suivra le même chemin que Flash, c'est pas évident car pour ce dernier il a fallu qu'un chauve puissant à col roulé dise que c'est de la merde pour qu'enfin tout le monde s'en rende compte.

                • [^] # Re: This is javaaa

                  Posté par . Évalué à 7.

                  Au risque de faire un bis repetita :

                  trucs qui pourraient fonctionner en Python ou même en PHP avec 4 fois moins de ressources.

                  Source ?

                  Non parce qu'en vrai Java consomme beaucoup moins de CPU que Python ou PHP. Beaucoup moins. Pour la RAM, je ne sais pas.
                  http://benchmarksgame.alioth.debian.org/u64q/python.html

                  Après hein, Java dans le navigateur, ça n'a pas été une grande réussite en effet. Paradoxalement, c'est au niveau backend/serveur que Java a particulièrement marché, bien que ça n'ai pas été sa cible originale.

                • [^] # Re: This is javaaa

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

                  Il faut faire cohabiter plusieurs versions de Java en fonction de ce que demande les applications

                  Comme Python (par exemple).

                  faut renouveler les machines car afficher une simple fenêtre demande 200Mo de ram

                  Ce n'est pas la JVM, ce sont les développeurs, ce sont les même qui demande 128M de ram pour faire un Hello world en PHP parce qu'ils sont copier-coller des dépendances un peu partout jusqu'à ce que ça marche.

                  constater que son webui demande une version préhistorique de Java, genre la 1.5

                  Donc ton fournisseurs de switch ne propose pas de mise à jour, mais c'est de la faute de Java ?

                  J'espère que Java suivra le même chemin que Flash, c'est pas évident car pour ce dernier il a fallu qu'un chauve puissant à col roulé dise que c'est de la merde pour qu'enfin tout le monde s'en rende compte.

                  Si tu parles des applet, la date de fin est annoncée. Et ce sera fini bien avant Flash.

                  « 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: This is javaaa

                    Posté par . Évalué à 2.

                    Comme Python (par exemple).

                    Bien moins de problèmes de cohabitation. Je n'ai qu'une seule version installée sur Debian et tout un tas de logiciels tournent dessus.

                    Ce n'est pas la JVM, ce sont les développeurs, ce sont les même qui demande 128M de ram pour faire un Hello world en PHP parce qu'ils sont copier-coller des dépendances un peu partout jusqu'à ce que ça marche.

                    D'expérience c'est systématique avec Java. Avec PHP c'est rare d'avoir un truc aussi lourd. On fait tourner du Wordpress sur à peu près n'importe quoi alors qu'un serveur Minecraft il faut plusieurs Go de ram. Autre comparaison avec deux produits à but identiques : ovirt et xencenter. ovirt c'est du tomcat et les spécifications demandent 4GB de ram sur le serveur. Xencenter est un client lourd Windows, il tourne avec 70Mo de RAM…

                    Donc ton fournisseurs de switch ne propose pas de mise à jour, mais c'est de la faute de Java ?

                    Le problème c'est que la machine virtuelle Java te harcèle pour te demander de confirmer sans cesse si tu veux exécuter l'application. Que ce soit un truc vieux ou récent.

                    Si tu parles des applet, la date de fin est annoncée. Et ce sera fini bien avant Flash.

                    Disons que Firefox va lui couper l'herbe sous le pied, ce qui aura pour effet uniquement d'emmerder les gens qui en ont besoin (typiquement les sysadmin/techniciens helpdesk qui vont devoir aider les gens à le réactiver). Donc c'est idiot, mais avec la fondation Mozilla on est habitués.

                    • [^] # Re: This is javaaa

                      Posté par . Évalué à 3. Dernière modification le 04/11/15 à 10:47.

                      On fait tourner du Wordpress sur à peu près n'importe quoi alors qu'un serveur Minecraft

                      Au fait, tu peux me donner un equivalent de Minecraft écrit en PHP ?

                      Ok Merci. CQFD

                      • [^] # Re: This is javaaa

                        Posté par . Évalué à 1.

                        Bien sûr qu'il n'existe pas d'application écrite dans deux langages. Donc la comparaison directe n'est jamais possible. Je prenais deux bons exemples de trucs mal faits ou bloatwarisés pour comparer.

                    • [^] # Re: This is javaaa

                      Posté par . Évalué à 10.

                      Aller je saute dedans…

                      Bien moins de problèmes de cohabitation. Je n'ai qu'une seule version installée sur Debian et tout un tas de logiciels tournent dessus.

                      Ou pas. C'est absolument trivial de choisir en temps qu'admin la version de Java que va utiliser une application. C'est l'histoire d'une variable d'environnement. En python tu va t'amuser entre ceux qui ont mis #!/usr/bin/python, #!/usr/bin/python2, #!/usr/bin/python3 ou #!/usr/bin/env python (ou python2 ou 3). Tu dois créer un virtalenv spécifique.

                      Le problème c'est que la machine virtuelle Java te harcèle pour te demander de confirmer sans cesse si tu veux exécuter l'application. Que ce soit un truc vieux ou récent.

                      Non, c'est uniquement si tu utilise l'installeur. Rien ne t'oblige à utiliser celui là et si tu es sysadmin je te conseil de ne pas l'utiliser et de lui préférer l'archive à décompresser. Il faut en plus toucher aux variables d'environnement. Ensuite c'est à toi de déployer les mises à jour quand tu le souhaite.

                      D'expérience c'est systématique avec Java. Avec PHP c'est rare d'avoir un truc aussi lourd. On fait tourner du Wordpress sur à peu près n'importe quoi alors qu'un serveur Minecraft il faut plusieurs Go de ram. Autre comparaison avec deux produits à but identiques : ovirt et xencenter. ovirt c'est du tomcat et les spécifications demandent 4GB de ram sur le serveur. Xencenter est un client lourd Windows, il tourne avec 70Mo de RAM…

                      Tu as tout en qualité. Demande toi pourquoi des choses comme spark, cassandra, lucene, hadoop, netty,… sont écris en Java. Des logiciels dont les utilisateurs sont très soucieux de la performance et de la consommation de ressource (gagner quelques pourcent de mémoire sur ce genre de grosse infrastructure ça représente une certaine somme d'argent).

                      Sur le bureau XMind par exemple est plutôt pas mal.

                      Ce qui est important c'est de comprendre l'outil. La JVM démarre relativement lentement et nécessite un petit temps de chauffe (il faut que HotSpot découvre ton usage du code pour l'optimiser correctement). Donc réécrire les binutils avec n'a pas de sens par exemple (grep te donne le résultat avant que la JVM n'ai le temps de démarrer). Il faut aussi savoir bien utiliser le langage et éviter certaines choses qui sont mauvaises niveau performance (les JSP voire les servlet si tu veux vraiment de la haute perf, les techno qui vont créer dynamiquemnt des proxy de tes objets, etc).

                      Le runtime est très souple ça permet de faire des choses impressionnantes (voir les ORM comme hibernate ou OSGi), mais c'est du coup facile d'en faire n'importe quoi.

                      Quand quelqu'un écris du mauvais code C++, il écris des bugs.
                      Quand quelqu'un écris du mauvais code Java, il écris un logiciel lent.

                      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                      • [^] # Re: This is javaaa

                        Posté par . Évalué à 0.

                        En python tu va t'amuser entre ceux qui ont mis #!/usr/bin/python, #!/usr/bin/python2, #!/usr/bin/python3 ou #!/usr/bin/env python (ou python2 ou 3).

                        pas vraiment correct. python et python2 c'est pareil. python doit pointer sur python2. Si un utilisateur veut ensurer python3 il faut ecrir /usr/bin/python3. En pratique je me souvient pas avoir eu de problemes. seulement quelques rare modules pas encore compatible python3 quand j'utilise pip et pas les paquets de la distrib.

                        • [^] # Re: This is javaaa

                          Posté par . Évalué à 3.

                          Cool et pour gérer les dépendances ?
                          Il y a autre chose que créer un virtualenv ?

                          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                        • [^] # Re: This is javaaa

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

                          pas vraiment correct. python et python2 c'est pareil.

                          Tu es au courant pour Archlinux ?

                          « 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: This is javaaa

                            Posté par . Évalué à 2.

                            Tu trouvera toujours un environement qui fait des trucs perso mais actuellement la recommendation officiel de python c est la https://www.python.org/dev/peps/pep-0394/
                            Ou tu peux lire
                            """
                            The more general python command should be installed whenever any version of Python 2 is installed and should invoke the same version of Python as the python2 command
                            """

                      • [^] # Re: This is javaaa

                        Posté par . Évalué à -3.

                        Bonjour,
                        autant prendre du C++11 voire C++14. Cassandra a été ré-écrit en C++ et cela tourne 10x plus vite (http://www.scylladb.com/).
                        De plus, je ne vois pas l'intérêt maintenant de Java vs C++. Les pointeurs ? la gestion mémoire ? bah ça fait longtemps, mais maintenant c'est "mieux" on utilise des smart-pointeurs (unique_prt / shared_ptr).
                        La gestion des boucles, les fonctions lambas tout est là maintenant. Et les bibliothèques vous allez me dire ? Qt ? STL ? Boost ? cela aide pas mal non ?
                        Bonne fin de journée

                        PS j'avais fait un programma simple en Java et le même en C++. J'avais eu le temps de lancer le programme C++ 22 fois avant que le programme Java ne fournisse sa réponse. Certes, je lançait en parallèle mais bon…

                        • [^] # Re: This is javaaa

                          Posté par . Évalué à 5.

                          autant prendre du C++11 voire C++14. Cassandra a été ré-écrit en C++ et cela tourne 10x plus vite (http://www.scylladb.com/).

                          J'ai vu. On verra ce que ça donne :)
                          (je ne l'ai pas encore essayé, apparemment c'est en janvier qu'ils vont sortir la version 1)

                          De plus, je ne vois pas l'intérêt maintenant de Java vs C++. Les pointeurs ? la gestion mémoire ? bah ça fait longtemps, mais maintenant c'est "mieux" on utilise des smart-pointeurs (unique_prt / shared_ptr).
                          La gestion des boucles, les fonctions lambas tout est là maintenant. Et les bibliothèques vous allez me dire ? Qt ? STL ? Boost ? cela aide pas mal non ?

                          Tu me semble avoir une vision très succincte des 2 langages. Ils sont extrêmement différents. Leur gestion de la généricité, leur gestion du parallélisme, la possibilité ou non d'avoir un code managé, l'écosystème,… Ils n'ont clairement pas les même finalités, ne couvrent pas les même besoin, n'intéressent pas les même développeurs, etc.

                          PS j'avais fait un programma simple en Java et le même en C++. J'avais eu le temps de lancer le programme C++ 22 fois avant que le programme Java ne fournisse sa réponse. Certes, je lançait en parallèle mais bon…

                          Et tu fais le même en C avec un unikernel et tu es quelques centaines de fois plus rapide, mais en vrai ça sert à quoi comme test ? Tu veux prouver que le runtime du C++ est plus léger que celui de Java ? Tu es bien le seul à en douter. Tu pointe justement le pire cas d'usage de Java.

                          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                    • [^] # Re: This is javaaa

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

                      Disons que Firefox va lui couper l'herbe sous le pied

                      Et Chrome l'a déjà fait, ainsi que Edge (le nouveau navigateur de MS). Il ne restera plus que IE. Autant dire pas tant d'utilisateur que ça.

                      « 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: This is javaaa

            Posté par . Évalué à 1.

            Je n'aime pas les pratiques en java:
            les abstractions qui ne font que compliquer la lecture, les interfaces n'ayant qu'une seule implémentation, les factory pour créer tout type d'objet
            l'utilisation systématique de getters/setters publics, qui exposent l'implémentation d'un objet

            Je n'aime pas les libs java:
            Il faut souvent créer 2 ou 3 objets intermédiaires pour des opérations simples comme la lecture de fichier
            Les interfaces graphiques ne s'intègrent pas facilement dans un environnement donné
            La distribution passe par la copie de .jar

            Je n'aime pas le langage java:
            Le langage ne connaît que les pointeurs, qui peuvent toujours être nuls
            Il n'y a pas de concept de "const" ou de fonctions pures
            La gestion des ressources doit être faite manuellement (sauf la mémoire), et sans destructeurs

            • [^] # Re: This is javaaa

              Posté par . Évalué à 5. Dernière modification le 04/11/15 à 11:58.

              les abstractions qui ne font que compliquer la lecture, les interfaces n'ayant qu'une seule implémentation, les factory pour créer tout type d'objet
              l'utilisation systématique de getters/setters publics, qui exposent l'implémentation d'un objet

              Regarde ce que font les gens de Vertx, de spark (autant le framework web que celui de traitement big data), etc (ou même spring d'ailleurs). Ça n'est aucunement une fatalité.

              Il faut souvent créer 2 ou 3 objets intermédiaires pour des opérations simples comme la lecture de fichier

              Dans la bibliothèque standard c'est un objet. Par contre maintenant la lib standard te donne la possibilité de faire des traitement asynchrone des fichier, ce que tu ne retrouve pas dans tous les langages.

              La distribution passe par la copie de .jar

              Oui et ? Tu parle d'avoir les libs qui ne sont pas packagés dans le jar en question ? C'est un choix du développeur. Tu peux très bien avoir un jar exécutable qui se lance directement.

              Le langage ne connaît que les pointeurs, qui peuvent toujours être nuls

              C'est dommage en effet, mais pas insurmontable (et vu le nombre de langage qui ont le problème de nul ça n'est pas très discriminant ^^).

              Il n'y a pas de concept de "const" ou de fonctions pures

              Tu as final, mais il ne joue que sur la référence et n'est pas profond.
              Perso j'ai pris l'habitude d'écrire des classes immutables. C'est plus simple et ça marche avec tous les langages statiques.

              Pour les fonctions pure, de quoi tu veux parler ? Tu voudrait quoi ? Une annotation qui t'empêche de faire référence à ton contexte ?
              Si tu parle d'optimisation de récursion terminale, tu ne l'a pas mais ce n'est pas très utilisé.

              La gestion des ressources doit être faite manuellement (sauf la mémoire), et sans destructeurs

              Faux depuis Java7 et les autoclosables. Tu as maintenant l'équivalent du with python avec le try-with-resource

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: This is javaaa

      Posté par . Évalué à 8.

      Pourquoi ?

      Parce que c'est un bon langage avec une JVM vachement optimisée ? Parce que c'est multiplateforme ? Parce que c'est pas un langage obscure ? Parce que le langage et la communauté autour est très active ?

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

      • [^] # Re: This is javaaa

        Posté par . Évalué à 8.

        Je ne me prononce pas sur le langage
        En revanche la jvm c'est de la grosse daube.
        Pété de failles, consomme un max de ram et plante.
        donc non merci. des que je vois un truc codé en java je passe directement.

        • [^] # Re: This is javaaa

          Posté par . Évalué à 8.

          Je plusse car malgré la trollitude d'OP, Java est connu comme étant un puits de failles comme en témoigne de nombreuses sources:

          Je vous laisse en trouver d'autres.

        • [^] # Re: This is javaaa

          Posté par (page perso) . Évalué à 9. Dernière modification le 03/11/15 à 17:54.

          Pété de failles

          Les failles, c'est surtout dans le plugin, pas mal dans la lib standard (mais est-ce plus que dans d'autres langages, toutes proportions gardées ?), et pas beaucoup dans la JVM.

          consomme un max de ram

          Ça dépend pas mal des réglages de la JVM et de la qualité du programme qui y tourne. Voir des logiciels de bureau comme yEd ou Astah pour des exemples de programmes de qualité qui consomment raisonnablement (en fonction des données que tu y mets bien entendu).

          et plante.

          La JVM elle-même ? Ça peut arriver, mais c'est assez rare quand même (surtout quand on la tient correctement à jour).

          Enfin bref, je pense pas que ce soit nettement pire que d'autres langages (voir les nombreuses mises à jour de sécurité .Net), et c'est en partie causé par la très grande popularité de Java et de la JVM, qui en fait une cible prioritaire.

  • # Des S

    Posté par . Évalué à 3.

    Salut,

    1ere phrase de github: "Fim manageSSS…"

    dans "why you need Fim":

    "the scrub command that readS all data… and verifIES…"

    "Fim haS a different use case"

    "Fim allowS you… with filesystems that DO not…"

    • [^] # Re: Des S

      Posté par . Évalué à 2.

      Merci pour les retours sur la Typo. J'apprécie.
      J'y fixe au plus tôt.

  • # Un peu sur le même principe

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

    Sur le même principe, j'ai créé doc l'autre jour pour répondre un peu au même besoin.

    L'idée était de pouvoir détecter les fichiers dupliqués et copier des arborescence de répertoire entre mon stockage amovible et mon disque sur mon ordinateur sans créer de doublons ou supprimer des fichiers uniques.

    L'usage est similaire, mais le hash du fichier est stocké dans des attributs étendus (il faut que le système de fichiers les supporte). On commence avec un doc commit pour générer le hash de tous les fichiers. Un doc status affichera les fichiers modifiés (non hashés ou ceux ayant une date de modification plus récente que le hash). doc check vérifiera le hash de chaque fichier, et doc cp permet de copier une arborescence source vers une arborescence destination.

    C'est écrit en Go, et si vous avez l'environnement de dev configuré, l'installation est aussi simple que go install github.com/mildred/doc.

    Les usages ne sont pas tout a fait les mêmes, mais je profite de cette dépêche pour en parler un peu.

    • [^] # Re: Un peu sur le même principe

      Posté par . Évalué à 3. Dernière modification le 03/11/15 à 21:49.

      Tout d'abord, je ne maitrise absolument pas go en tant que langage (je connais de nom)

      Après avoir cloné ton dépôt, il faut, je suppose, compiler tout ça ?

      Je viens d'installer golang puis tenter rapidement quelques commandes glanées sur le net mais sans succès (go build, generate, get , export de GOROOT / GOPATH etc)
      Il me semble avoir des problème de dépendances notamment ou alors je m'y prends mal (ce qui est probable car je n'ai pas trop insisté)

      Tout ça pour dire que si tu complétais ton readme avec un petit bloc howto compile avec les dépendances qui vont bien si elles existent, je serai ravi et sûrement d'autres néophytes en go aussi, histoire d'essayer "doc" pour comparer avec "fim" (qui lui fonctionne directement grâce (ou à cause ?) de java et sa jvm pour continuer dans le troll …

      Sinon, je bosserais un peu plus le manuel de go demain.

      Merci pour les partages.

      • [^] # Re: Un peu sur le même principe

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

        Il faut peut être faire un go get -u PACKAGE et un go build PACKAGE avant de faire un go install PACKAGE (README mis a jour).

        • [^] # Re: Un peu sur le même principe

          Posté par . Évalué à 2. Dernière modification le 04/11/15 à 18:37.

          C'est mieux avec le README. Ça fonctionne, je n'ai plus qu à tester.

          J'avais fait un "git clone" puis essayé de faire le "go build" qui criait du fait des dépendances mais comme ça c'est plus simple (très simple en fait : le go get qui récupère directement sur github, c'est bien pratique)

          Merci de ce rapide update

Suivre le flux des commentaires

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