dani a écrit 116 commentaires

Tu fais preuve d'une insupportable condescendance, ça aide pas à convaincre (en fait, ça fait exactement l'inverse).

Entre les gens que tu insultes ("irresponsables sans éthique" pour désigner ceux qui osent être moins étroit d'esprit que toi), les amalgames idiots (que vient faire les histoires de démocratie là dedans ??) et les contre vérités (non, Github n'empêche personne de contribuer, c'est toi qui te refuse à le faire), ça en fait du charabia dénué de sens …

Au passage, Github a fait plus pour le libre que tu ne pourras jamais le faire, même si tu penses avoir une éthique supérieure

Troll identifié !

En alternative à dropbox, je recommande plutôt Seafile que ownCloud/NextCloud. Ça ne fait que la partie fichiers, mais ça l'a fait bien. Le client Seadrive a d'ailleurs été libéré récemment pour Linux (il existait un client libre déjà, mais Seadrive a une autre approche qui le rend beaucoup plus confortable). En plus, on peut y intégrer OnlyOffice (ou Collabora, mais ça je ne l'ai pas testé) pour avoir une solution web tout en un.

Oui, après avoir comparé pas mal de solutions libres (Keepass éliminé bien évidemment, parce que se taper la synchro par un autre moyen, c'est pas viable), je suis resté sur Bitwarden. Et l'implémentation Bitwarden_RS est légère, facile à autohéberger. En finaliste, il y avait aussi psono, qui a des fonctionnalités intéressantes (mais les extensions navigateurs et le client Android étaient pas assez soignés à l'époque, ça a peut être évolué depuis)

Et bien justement, générer un fichier de config YAML (ou JSON, même si je pense qu'utiliser JSON pour un fichier de config est une abomination) avec ansible c'est très simple : {{ my_conf_struct | to_nice_yaml(indent=2) }}. On a à la fois un truc simple à générer/automatiser/parser et simple à lire pour le crétin d'humain que je suis (oui parce que parfois, il faut débuguer, et là, il vaut mieux regarder la conf qui est réellement en place, pas celle que l'on pense qui est en place, mais qui est définit dans notre dépôt ansible, dans un autre format par exemple). Toujours en parlant d'ansible, un format à la YAML rend aussi très simple la modif que d'une partie du document, même sans connaître tout le reste.

J'ai beau avoir lu le journal, je ne comprend absolument pas l'intérêt du truc. La syntaxe est tellement peu lisible pour de la config …

Perso moi c'est l'inverse, je peste dès que je croise un logiciel qui utilise un langage de programmation comme syntaxe de configuration (Ejabberd, Prosody par exemple)

Ceux en charge du déploiement ne sont pas ceux en charge du développement. Ils n'ont pas besoin de connaître les syntaxes (qui parfois paraissent complètement absurdes) des langages utilisés. Et la lisibilité d'une fichier de config est hyper importante aussi.

Bref, je suis partisan du YAML pour la conf (qui est à la fois lisible par un humain, et facilement parsable pour une machine)

Bluemind, je l'ai testé pendant plusieurs mois. La solution a de bons points (et est française !) mais
- C'est affiché en gros et partout que c'est libre, ce qui est faux. Il est impossible de faire un déploiement avec uniquement les composants libres. Si on peut comprendre que les connecteurs AD ou Outlook soient propriétaires, l'outil de mise à jour par contre, c'est autre chose. Si tu veux faire un déploiement qu'avec les composants libres, à chaque version (même mise à jour mineur), tu réinstalles, tu exportes et importes tes données. Pas réaliste
- Ça consomme des ressources. Mais vraiment beaucoup de ressources. N'espérez pas le faire tourner correctement pour moins de 10 personnes avec < 20Go de RAM. Idem pour l'espace disque (~ 2x plus d'espace occupé que la même chose sous Zimbra). C'est principalement l'indexation elasticsearch de bluemind qui fait la différence
- La v4 quand elle est sortie était vraiment inutilisable. Trop de bugs. Des trucs essentiels comme la recherche qui ne fonctionnent pas, le mécanisme de réplication pour l'indexation hyper fragile (remonté au moins 4 cas différents qui créaient une boucle infinie, et quand ça pète, ben il n'y a plus grand chose qui fonctionne). Bref, ça s'est peut être amélioré depuis (quoi que j'en doute vu que le webmail a été entièrement ré-écrit, ça implique probablement toute une collection de nouveaux bugs), mais on a du arrêter de l'utiliser à cause de la fiabilité. C'est d'ailleurs comme ça que je suis sur Zimbra maintenant.

Le pb n'est pas que le mail est en perte de vitesse. Le pb c'est déployer sa propre solution vs passer chez gmail ou outlook …

RoundCube : pas la même catégorie. Ça n'est qu'un webmail. SOGo : je l'ai utilisé pendant des années, mais ce n'est pas une alternative non plus, car ne fournit pas la stack IMAP/SMTP, ne fournit pas la gestion des users / groupes, pas de gestion multi serveurs (à toi de te démerder à le faire). Les permissions sont très peu intuitives à mettre en place. Et la nouvelle interface depuis la v3 est comment dire … Bah en fait j'ai pas encore trouvé un seul utilisateur qui accepte d'utiliser ça. Donc non, je maintiens, pas d'alternative à Zimbra

Oui, et me servant de Zimbra (en déploiement perso, et aussi pro), je suis bien dég. Malheureusement, il n'y a pas vraiment d'alternatives fonctionnelles. À croire que sur ce segment, aucun acteur n'arrive à faire une solution libre qui soit pérenne.

Par rapport à un redis (qui peut faire du RAM only), quel est le gain ? Meilleurs perf ? Pour ce qui est du choix des commandes en français, perso ça me rebute un peu. C'est un logiciel destiné à être mis en place par des tech, pas du grand public. Donc l'anglais ne devrait pas être un frein.

Pour avoir développé un embryon d'app WebRTC (https://github.com/dani/vroom) : non, ça n'est pas juste une question de tester notre brouteur et le reste osef. À l'époque au moins (2014 ~ 2016), Firefox était très en retard par rapport à Chrome (conso CPU supérieur, des connexions qui ne s'établissent pas toujours, qualité de voix inférieure, manque de certaines fonctionnalités qui sont arrivées bien après Chrome, comme le partage d'écran). Peut être que l'écart s'est réduit depuis, je ne suis pas sûr, mais ça ne m'étonnerait pas que Chrome (ou Chromium) soit encore largement en avance sur le support du WebRTC

dans API il y a "public"

Heu, non

Il dit qu'il voit pas le rapport

C'est un peu hors sujet : mais Draw aussi est à des années lumière de Visio. Le rendu, les shapes de base, les performances … Pour moi, il est pas utilisable

Oh que si, mais tu ne connais pas.

Manqué parce que si, je connais (enfin, je l'ai évalué il y a quelques années). Et non, c'est pas libre dans son ensemble. Seul l'agent l'est (c'est un bon début, mais pas suffisant pour en faire une solution libre)

J'ai beau chercher, je ne trouve pas d'arguments montrant que ce ne sont pas des alternatives à TeamViewer.

Oui, on peut effectivement faire un concourt de mauvaise fois. Tant qu'à faire, on peut aussi dire que Dia est une alternative à MS Visio puisque c'est écrit quelque part sur Internet. Bon, ça le rend pas vrai pour autant.

Je suis vraiment un partisan du logiciel Libre. Mais nier ses lacunes (parce qu'il y en a), ça ne lui rend pas service. Et dans le domaine de la prise de contrôle à distance, il n'y a rien qui puisse concurrencer TV (le tech lance un client, l'utilisateur aussi, on transmet un code créé aléatoirement par téléphone, ça s'établie, on a pas à se soucier de quelque ouverture de port que ce soit)

Donc non il n'y a pas de solution clef en main mais il y a moyen de mettre ça en place et packager le tout correctement

Voilà bien le problème, et ce que je veux dire par "il n'existe pas d'alternative". Oui, on peut se bricoler quelque chose, mais :

• Ça demande du temps d'assembler ces briques, qui pourrait être investi à faire des choses plus productives (sans parler du temps pour le maintenir après sa mise en place)
• Moins simples pour les utilisateurs qui n'y connaissent rien
• Moins de fonctionnalités (tchat intégré, transfert de fichiers etc..)
• Plus fragile (et si le port 22 est bloqué ? Ben ça passe pas)

TightVNC ? TigerVNC ? Remmina ? X2Go ? Guacamole ? Dayon! ? Xrdp ?

Merci, je connais tout ça. Et je maintiens que non, ce ne sont pas des alternatives à Teamviewer (voir mon post plus haut). Ce ne sont que des briques élémentaires qui pourraient potentiellement être utilisées par une hypothétique solution libre alternative…. qui pour l'instant n'existe pas.

Non, ça ne répond pas du tout au besoin. J'utilise moi aussi du SSH+VNC et c'est clairement pas viable. Loin, très loin d'un Teamviewer, on peut pas dire que c'est une alternative. Il faut soit un serveur SSH accessible chez le client (tous les clients), et donc des renvois de ports. Soit du reverse VNC avec le SSH qui tourne du côté du support, mais dans ce cas c'est limité à une prise de contrôle à la fois. Il n'y a pas d'interface propre à déployer chez les clients. On peut contourner certains de ces problèmes avec d'autres couches à base de logiciels non maintenus (comme des réflecteurs VNC), mais c'est du bricolage, ça donne un ensemble fragile, et complexe à maintenir. Bref, dans le monde réel, les gens utilisent Teamviewer parce qu'il n'y a pas d'alternative.

On sent bien sans que ça soit dit explicitement que le problème soulevé ici est l'usage de Teamviewer. En même temps, même si le médecin et le support informatique étaient tous les deux sensibilisés à ça, quelle alternative ils pourraient utiliser ? (hint : en libre, il n'y a rien)

Oui, Red Hat est le sponsor principal de Fedora. Mais je vois pas de rapport avec la choucroute. D'une part parce que même si Fedora est sponsorisé, c'est un projet communautaire indépendant, et d'autre part parce que systemd n'est pas un projet Fedora non plus (Fedora a simplement été l'une des premières distributions majeure à l'adopter)

Nop. C'est Lennart seul qui a lancé systemd, sur son temps personnel. Il était employé de Red Hat, mais pas payé pour systemd. Red Hat a ensuite adopté systemd une fois qu'il était devenu l'init par défaut de pleins de distribution majeures (dont Fedora). En fait systemd n'est pas, et n'a jamais été un projet de Red Hat

Deux points :
- L'assertion "c'est impossible d'implémenter correctement" sur une dépêche qui annonce un logiciel libre qui l'implémente, je trouve ça assez cocasse. OnlyOffice n'implémente peut être pas parfaitement la norme, mais ça n'indique rien sur sa qualité. Comme j'ai déjà dit, LibreOffice n'implémente pas parfaitement la norme ODF non plus. Donc quoi ? La norme ODF est toute pourrie parce qu'on peut pas l'implémenter parfaitement ? Pour ce que ça vaut, le support OOXML d'OnlyOffice semble tenir la route, pour tous les documents que j'ai ouvert, les écarts de formatage étaient vraiment mineurs entre OnlyOffice et un MS Office 2016. Bien meilleurs qu'avec LibreOffice.
- Le format OOXML dans OnlyOffice est le format natif, interne. Le logiciel n'impose aucunement de n'utiliser que ce format, et permet de sauver en ODF (et exporter en PDF). Le format interne on n'est pas obligé de s'en soucier. On peut ouvrir en ODF, et sauvegarder en ODF. Si ça provoque des bugs (données perdues par exemple), il faut remonter un bug. Ça n'est pas du à l'usage de OOXML, n'importe quelle autre représentation interne pourrait introduire des bugs

Non, le fait que leur suite présente des bugs n'indique rien sur la qualité du standard (sinon ODF serait tout autant de la merde, puisque LibreOffice arrive aussi à avoir des bugs, sur une norme qui tient en seulement 600 pages …)