dani a écrit 50 commentaires

  • [^] # Re: FreeBSD

    Posté par . En réponse à la dépêche FreeBSD 11.2. Évalué à 2 (+1/-0).

    Je ne vois pas en quoi avoir à gérer un seul fichier avec plein de lignes serait plus dur que de gérer plein de fichiers avec peu de lignes dans chaque

    Parce que c'est bien plus fiable de générer le fichier entier que de le parser pour modifier uniquement certaines variables

    on parle de la configuration du système lui-même, de l’OS quoi

    Qui a quand même besoin d'être configuré…

    Un système simple à gérer « à la main » sera simple à gérer avec des outils comme Ansible ou Puppet, et inversement

    Je ne suis pas du tout d'accord. Ça peut très bien être adapté à une administration manuelle et pas du tout à de l'automatisation. La réponse suivante évoque les répertoires .d, ce qui supprime le pb par contre ;-)

  • [^] # Re: FreeBSD

    Posté par . En réponse à la dépêche FreeBSD 11.2. Évalué à 2 (+1/-0).

    simplicité et logique d'administration (toute la conf se passe dans un seul fichier ou presque)

    Je vois souvent cet argument. Ça me semble justement un énorme inconvénient. La configuration par des outils comme ansible devient pas un peu l'enfer ? C'est peut être bien pour un serveur isolé, géré "à la main", mais dès qu'on dépasse ce cadre….

  • # Il dit qu'il voit pas le rapport

    Posté par . En réponse au journal La colère des développeurs de crypto-monnaies après le rachat de Github par Microsoft. Évalué à 10 (+13/-0).

    En quoi les projet en rapport avec les crypto-monnaies seraient plus impactés que n'importe quel autre ?

  • [^] # Re: Pas tant de ressources

    Posté par . En réponse au journal L'État français adopte Matrix/Riot. Évalué à 1 (+0/-0).

    Parce qu'il n'y a pas que les messages, il y a énormément de meta données aussi

  • [^] # Re: Pas tant de ressources

    Posté par . En réponse au journal L'État français adopte Matrix/Riot. Évalué à 2 (+2/-1).

    Les spec que j'ai donné ne représentent pas la capacité nécessaire en continu. Mais elles permettent d'absorber le pic de charge quand un utilisateur joint un "gros" salon. Avec un plus petit dimensionnement ça va marcher aussi, le temps de jonction sera juste plus important. Ça reste accessible à pratiquement n'importe qui, c'est pas du tout réservé aux "gros".

  • # Pas tant de ressources

    Posté par . En réponse au journal L'État français adopte Matrix/Riot. Évalué à 2 (+2/-1).

    Pour utiliser Matrix depuis quelques mois, il ne faut pas tant de ressources que ça pour joindre les plus gros salons. Une VM avec 3Go de RAM, 2vCPU, et quelques Go de stockage pour la BDD et c'est bon. Certes, c'est plus que pour du Jabber, mais ça reste accessible à presque n'importe qui. Par contre, il faut déployer un serveur postgresql. SQLite3 lui ne suit pas

  • [^] # Re: Listons aussi ses qualités

    Posté par . En réponse au journal Thunderbird, mon premier contact est une déception !. Évalué à 5.

    Thunderbird est un MUA. Aucun rapport avec un quelconque problème de confidentialité. Tes mails passent d'abord par un hébergeur, et si tu les relèves en IMAP, ils y restent. Que tu utilises TB, Outlook, rainloop, SOGo, ou gmail, pour les lire ça ne change absolument rien.

  • [^] # Re: HS pourtant ...

    Posté par . En réponse au journal [PGP] Des failles de sécurité sous le sapin pour Thunderbird et Enigmail !. Évalué à 9.

    J'ai arrêté un peu avant. Quand ça s'est mis à parler de terroristes d'État. Ouf, j'ai échappé à l'écriture inclusive

  • # Rester loin d'XMPP

    Posté par . En réponse au journal Retour d’expérience (et tuto) XMPP. Évalué à 5.

    Merci pour le journal. Ça me conforte dans mon idée de rester loin d'xmpp. Perso j'ai choisi Matrix, mais je pense que peu importe, n'importe quelle solution fonctionnera mieux. Ce journal est un très bon exemple de pourquoi XMPP ne prends pas.

  • [^] # Re: testé un upgrade dans une VM

    Posté par . En réponse à la dépêche Parution de Fedora 27. Évalué à 2.

    Fedora est très bon là dessus, depuis des années. Mon desktop était installé en 14, et mis à jour par toutes les versions intermédiaires jusqu'à la 25 (j'ai fini par réinstaller pour passer sur un SSD). Dans l'ensemble très peu de problèmes, la plupart liés aux drivers NVIDIA proprio.

  • [^] # Re: commentaire link

    Posté par . En réponse au journal WPA2 est bronsonisé. Évalué à 1.

    Aha. Merci. J'ai ri !

  • [^] # Re: XMPP, Pas facile de s'y retrouver

    Posté par . En réponse à la dépêche Sortie du très attendu Prosody 0.10. Évalué à 2. Dernière modification le 12/10/17 à 13:00.

    Il est possible de le faire avec Prosody (qui n'est qu'une des implémentation d'un serveur XMPP) depuis 6 ans

    C'était possible avant, mais ce n'est que maintenant que c'est activé par défaut (d'ailleurs, est-ce que ça l'est, ou faut-il le configurer explicitement ?)

  • [^] # Re: XMPP, Pas facile de s'y retrouver

    Posté par . En réponse à la dépêche Sortie du très attendu Prosody 0.10. Évalué à 5.

    Sans fric, tu m'expliqueras comment tu fais pour promouvoir ton produit et gagner des part de marcher dans un contexte ultra concurrentiel.

    Que l'argent y joue, probablement. Mais ce n'est pas le cœur du problème. Ce qui pousse tout ces géants à se fermer à la fédération, même si ils utilisent XMPP, c'est pour contrôler l'expérience utilisateur, et assurer que tout fonctionnera. Comme XMPP a été créé pour être modulaire, et que tout est définie sous forme d'extensions, tu ne peux pas t'assurer que la personne en face supportera quoi que ce soit, en dehors des fonctions de base. Du coup, un utilisateur de ton service qui discute avec un autre, par la fédération aura l'impression que mon service est nul parce que "ça marche pas, je ne peux pas envoyer des fichiers", alors que le problème vient de son contact, qui utilise un serveur et/ou client qui n'implémente pas ce qu'il faut. Donc pour éviter ça, on coupe la fédération, et on garantie aux utilisateurs de notre service une expérience optimale. Et ça, c'est bien un problème qui provient de la modularité d'XMPP.

  • [^] # Re: XMPP, Pas facile de s'y retrouver

    Posté par . En réponse à la dépêche Sortie du très attendu Prosody 0.10. Évalué à 6.

    C'est très à la mode de critiquer le côté modulaire de XMPP alors que c'est au contraire son grand point fort.

    C'est à la fois son grand point fort, et son principal défaut

    si vous prenez comme étalon un trucs très récent et en cours de standardisation comme OMEMO, forcément ça n'est pas partout

    Non, je parle de fonctions de base, comme l'envoi de fichiers, ou les appels audio vidéo. Ou encore le carbon copy, l'historique côté serveur. Pour tout ça, c'est au bon vouloir de celui qui administre le serveur. Puis l'utilisateur doit vérifier si son client supporte ça aussi. C'est déjà trop compliqué (ou plutôt pénible) pour un technophile. C'est pas unique à XMPP, c'est simplement un fait. Sur un réseau fédéré, on est forcé de se limiter au dénominateur commun, c'est extraordinairement difficile d'évoluer ensuite. Le problème d'XMPP par contre (selon moi) est que ce dénominateur commun est trop limité. Tout est défini dans des XEP, et l'on ne peut pas garantir qu'elles seront disponibles sur toute la chaîne.

  • [^] # Re: XMPP, Pas facile de s'y retrouver

    Posté par . En réponse à la dépêche Sortie du très attendu Prosody 0.10. Évalué à 6.

    tu as le choix entre des dizaines/centaines de clients, mais ils fonctionnent tous ensemble.

    Qui fonctionnent partiellement et/ou peut être ensemble. C'est bien là le problème. Dans le cas de la messagerie instantanée (certes pas l'unique but de XMPP, mais un des principaux), selon ton client, ton serveur, et idem pour l'autre côté, les chances que les bonnes XEP soient implémentées, activées, et correctement configurées sont si faibles, que dans la pratique, on ne peut pas vraiment compter dessus. À moins de contrôler l'ensemble de la chaîne (donc, hors fédération), on est donc obligé de retomber sur les fonctions minimales, celles définies dans le core du protocole, et quelques XEP suffisamment anciennes et simples pour être disponibles à peu près partout.

  • [^] # Re: Parce que xmpp est un protocole

    Posté par . En réponse au journal Pourquoi Jabber n'a pas plus de succès, même chez les informaticiens?. Évalué à 3.

    Une des utilisations les plus originales que j'ai vu c'était le projet Archipel. Un orchestrateur de VM, dans lequel XMPP est utilisé pour tout. Malheureusement, le projet semble au point mort maintenant

  • [^] # Re: Un lecteur vidéos ?

    Posté par . En réponse à la dépêche Des nouvelles de GNOME à l’occasion de la 3.26. Évalué à 1.

    En effet. J'utilisais un COPR à l'époque, j'avais même pas remarqué que j'avais basculé sur la version fournie par RPMFusion. C'est donc une bonne nouvelle. J'ai plus qu'à attendre la prochaine version qui devrait intégrer le mode shuffle (indispensable pour moi)

  • [^] # Re: Un lecteur vidéos ?

    Posté par . En réponse à la dépêche Des nouvelles de GNOME à l’occasion de la 3.26. Évalué à 2.

    Moi je l'utilise, il me convient très bien.

    Ok, ça répond à ma question. Je me demandais si la nouvelle version pouvait convenir à certains :-)

  • [^] # Re: Un lecteur vidéos ?

    Posté par . En réponse à la dépêche Des nouvelles de GNOME à l’occasion de la 3.26. Évalué à 0.

    Mouais. VLC fait tout, c'est bien son défaut. Moi je veux juste un lecteur multimédia simple, avec playlist. Gnome MPV semble pas mal, mais pas encore dans les dépôts de Fedora (je sais pas pour les autres distrib)

  • # Un lecteur vidéos ?

    Posté par . En réponse à la dépêche Des nouvelles de GNOME à l’occasion de la 3.26. Évalué à 1.

    Dommage, il ne manque plus qu'un lecteur vidéos à cet environnement. Il y avait Totem qui était pas trop mal, avant qu'il ne soit saboté il y a quelques versions (entre autre, retrait de la playlist…). Et depuis ce sabotage, il ne bouge plus. Il y en a qui s'en servent de Gnome Vidéo maintenant ?

  • [^] # Re: Trop tard

    Posté par . En réponse au journal dino, un nouveau client jabber GTK+ façon GNOME 3. Évalué à 5.

    Ne jamais dire jamais!

    Tous les géants (Google, Facebook, Whatsapp, peut être d'autres) ont arrêté de faire de l'XMPP. Alors on peut dire qu'ils sont juste tous méchants et veulent enfermer les utilisateurs. Ou on peut regarder de façon plus pragmatique, et commencer à se demander si le problème ne viendrait pas d'XMPP. (Hint: gmail fait toujours parti du réseau fédéré SMTP…)

    Concernant la simplicité, je ne suis pas expert ni sur l'un ni sur l'autre, mais du peu que j'ai regardé, c'est sans commune mesure. Déjà, l'utilisation d'une API JSON au dessus d'HTTP rend le truc très simple à prototyper, avec absolument n'importe quel langage. Ensuite il n'y a pas 36 façons de faire les choses. Tu veux envoyer un fichier ? Il n'y a qu'une méthode. Tu n'as pas à essayer de découvrir quelle(s) XEP le serveur implémente, et idem pour le client d'en face, puis essayer de sélectionner la méthode la plus efficace. Non, juste tu envois. Enfin, tout est dans le core. Tu veux être compatible Matrix ? Tu implémentes les spec. C'est tout. L'extensibilité de XMPP c'est ce qui le tue. (ça évite toutes les questions du genre quelle XEP choisir pour implémenter une fonction ? Est-elle bien la dernière disponible ? A-t-elle était remplacée par une autre XEP ? Les clients les plus populaires ont implémentés laquelle ? etc..)

  • [^] # Re: XMPP et Matrix

    Posté par . En réponse au journal dino, un nouveau client jabber GTK+ façon GNOME 3. Évalué à 1.

    Mon usage, c'est principalement dans un cadre pro, on a besoin de s'envoyer rapidement des screenshots, ou des façades de baies par exemple. L'affichage inline des images est quasi impératif pour nous. Et on va l'étendre pour remonter sur un salon des logs ou autre fichiers quand on doit débuguer un problème à plusieurs. Et c'est l'un des avantages de Matrix: sa simplicité. En quelques heures, j'ai bricolé un petit client en ligne de commande qui me permet de faire tout ça et bien plus, genre:

    cat /var/log/messages | patrix
    patrix --send-file --file /etc/httpd/conf.d/riot.conf --file ~/error.png
    patrix --create-room --topic "Ticket #1234" --invite "@foo:bar.com" --invite "@blah:example.com"

    Alors bien sûr, c'est probablement possible avec XMPP, mais il m'aurait fallu bien plus longtemps pour le faire (sans parler de la fiabilité de l'envoi de fichiers…). Et c'est bien là je pense le 2° plus gros problème de XMPP (après les XEP): sa complexité, qui fait que pas assez de développeurs s'y sont intéressés.

  • [^] # Re: XMPP et Matrix

    Posté par . En réponse au journal dino, un nouveau client jabber GTK+ façon GNOME 3. Évalué à 0.

    Pas adapté ce xkcd. Matrix permet (enfin !) d'envoyer des fichiers simplement, depuis un mobile ou un client web. Il ne permet juste pas de l'effacer (pour l'instant). Ça reste un grand pas en avant. L'impossibilité d'effacer peu même être un avantage dans certaines situations.

  • [^] # Re: XMPP et Matrix

    Posté par . En réponse au journal dino, un nouveau client jabber GTK+ façon GNOME 3. Évalué à 1.

    C'est adapté Matrix pour s'échanger des fichiers ?
    Quand tu déposes un fichier dans un salon, il y reste presque pour l'éternité

    Oui, c'est un problème (pour l'instant). Mais l'espace disque, c'est pas cher comparé au temps perdu à uploader des fichiers pour s'envoyer des liens d'upload, puis à les récupérer de l'autre côté. Il y aura probablement des solutions à l'avenir. Pour moi, c'est surtout utile pour s'envoyer des photos et des petits fichiers, donc qu'ils soient conservés indéfiniment n'est pas bloquant. Je comprend par contre que ça puisse l'être pour certains.

  • [^] # Re: XMPP et Matrix

    Posté par . En réponse au journal dino, un nouveau client jabber GTK+ façon GNOME 3. Évalué à 3.

    Pour moi (j'utilise XMPP en interne dans mon entreprise depuis ~7 ans, avec Ejabberd comme serveur), ça marchotte parfois. Au doigts mouillé je dirai 10% du temps, avec des taux de transfert ridicules, et si les 2 sont sur le même LAN, en utilisant le même client et si la lune est descendante. Bref, on a arrêté d'essayer de transférer des fichiers par Jabber, on s'envoie des liens d'upload à la place (la honte…). C'est une des raisons pour lesquelles j'ai cherché une alternative (qui sera à priori Matrix, même si encore en phase de test)