Galène, un serveur de vidéoconférence libre

Posté par Juliusz Chroboczek . Édité par Nÿco et Xavier Teyssier. Modéré par Pierre Jarillon. Licence CC By‑SA.
Étiquettes :
72
22
déc.
2020
Éducation

Galène est un serveur de vidéoconférence conçu pour l'enseignement et les exposés scientifiques, développé à l'Université de Paris-Diderot par Juliusz Chroboczek. Galène 0.1 a été vient d'être publié sous la licence MIT.

Le développement de Galène a commencé lors du premier confinement. Galène était alors envisagée comme une alternative à BigBlueButton, moins coûteuse en ressources et plus facile à administrer. Après deux semestres de cours et une session d'examens, Galène a acquis un certain nombre de fonctionnalités utiles à l'enseignant :

  • possibilité de partager plusieurs documents simultanément (par exemple des transparents de cours, un éditeur de texte et un logiciel de dessin) ;
  • création automatique de sous-groupes (par exemple pour distribuer les étudiants en petits groupes lors des traveaux pratiques) ;
  • possibilité de jouer un fichier vidéo stocké sur disque.

Si Galène a été principalement conçue pour l'enseignement, elle s'est aussi avérée populaire pour permettre des réunions : plusieurs des conseils du laboratoire d'informatique ont régulièrement lieu sur Galène.

Aller plus loin

  • # Moins gourmand que BigBlueButton ?

    Posté par  . Évalué à 9.

    Alors finalement, est-ce que le but d'être moins gourmand que BigBlueButton est atteint ? Je vois des données sur les performances de Galène dans la dépêche, mais pas d'informations sur les performances de BigBlueButton pour comparer.

    En supposant que Galène est effectivement moins gourmand que BigBlueButton, est-ce que tu sais d'où vient la différence ?

    • [^] # Re: Moins gourmand que BigBlueButton ?

      Posté par  . Évalué à 10. Dernière modification le 22 décembre 2020 à 21:14.

      D'après https://docs.bigbluebutton.org/install#minimum-server-requirements, BBB recquiert:

      • 4 GB of memory with swap enabled (8 GB of memory is better)
      • 4 CPU cores (8 is better or more)

      L'instance de Galène tournant sur galene.org occuppe 10Mo d'espace disque:

      galene@galene:~$ echo $(( $(du -s . | cut -f1) - $(du -s ./recordings | cut -f1) ))
      10396

      et 46Mo de mémoire:

      galene@galene:~$ ps l 24280
      F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
      4 1001 24280 1 20 0 714792 46520 - Ssl ? 111:15 /home/galene/galene -redirect galene.org:8443

      En ce qui concerne le CPU, il s'agit d'un serveur avec un seul cœur (le VPS OVH bas de gamme), et nous nous en servons régulièrement pour faire des cours avec 70 étudiants présents.

      • [^] # Re: Moins gourmand que BigBlueButton ?

        Posté par  (site web personnel) . Évalué à 3. Dernière modification le 22 décembre 2020 à 23:31.

        la demande serait plutôt sur un munin ou autre système de mesure des consommations :-) (de part et d'autre)

        l’initiative reste intéressante et très pertinente, mais à prouver :p

        PS : et jch< tu peux t'inscrire gratuitement sur LinuxFr.org : cela te permettra de répondre aux commentaires, d'accroitre ton karma, toussa

      • [^] # Re: Moins gourmand que BigBlueButton ?

        Posté par  . Évalué à 2.

        Il me reste la question sur la raison de la différence. Est-ce que les algos utilisés sont meilleurs ? Il y a une différence de design qui permet plus d'efficacité ? Juste du code plus économe un peu partout, et ça s'additionne ?

        • [^] # Re: Moins gourmand que BigBlueButton ?

          Posté par  (site web personnel) . Évalué à 1.

          Est-ce que les algos utilisés sont meilleurs ?

          bah va construire ton moteur de recherche de malware :-)

        • [^] # Re: Moins gourmand que BigBlueButton ?

          Posté par  . Évalué à 10.

          BigBlueButton (BBB) a énormément de fonctionnalités avancées : passerelle SIP, interprétation des PDF, des document LibreOffice et Microsoft Office, annotation et tableau blanc partagé, etc. Chacune de ces fonctionnalités est implémentée par un binaire différent, et tous ces composants communiquent à travers un bus Redis:

          https://docs.bigbluebutton.org/2.2/architecture.html#high-level-architecture

          Galène a une architecture différente. Le serveur implémente le strict minimum de fonctionnalités : il se limite essentiellement à garantir la sécurité des échanges, à décider quelle donnée est destinée à quel client, et à pousser des flux RTP aussi efficacement que possible. Comme le serveur est de taille modeste, il est implémenté comme un seul binaire monolithique (multi-threadé), ce qui permet d'utiliser des structures de données partagées et donc de limiter la copie des données.

          Clairement, Galène n'est pas un concurrent de BBB: Galène ne sera jamais capable de supporter la plupart des fonctionnalités de ce dernier. Par exemple, Galène ne pourra jamais interpréter un document Microsoft Office: il n'est tout simplement pas raisonnable d'intégrer un interpréteur du format OOXML dans l'architecture de Galène. De même, Galène n'intégrera jamais une passerelle SIP: comme Galène n'interprète (presque) pas les flux qui la traversent, elle ne peut pas convertir le traffic WebRTC en un traffic compatible avec SIP.

          Je recommande que les gens qui ont besoin de fonctionnalités avancées continuent à utiliser BBB — c'est un excellent logiciel, qui domine tous les autres en nombre de fonctionnalités. Le but de Galène est d'être un logiciel simple, robuste et efficace aux fonctionnalités strictement limitées.

      • [^] # Re: Moins gourmand que BigBlueButton ?

        Posté par  . Évalué à 9.

        Est ce que Galène est du type MCU (Multipoint Conferencing Units) comme BigBlueButton ou SFU (Selective Forwarding Units) comme Jitsi ? Ce lien en anglais explique rapidement la différence entre les deux.

        • [^] # Re: Moins gourmand que BigBlueButton ?

          Posté par  . Évalué à 10.

          C'est un SFU.

          • [^] # Re: Moins gourmand que BigBlueButton ?

            Posté par  (site web personnel) . Évalué à 5. Dernière modification le 23 décembre 2020 à 14:21.

            concrètement, la question de Pilou< était plutôt :

            • avantages / inconvénients SFU / MFU du fait de ton expérience ?
            • limitations que cela apporte (plus factuellement : limité par la bande passante de celui qui n'a pas encore la fibre ?)
            • pourquoi ce choix ?
            • comment c'est utilisé au jour le jour ? (combien de locuteurs)

            bref, comment que ça fonctionne bien ?

            • [^] # Re: Moins gourmand que BigBlueButton ?

              Posté par  . Évalué à 10.

              Un SFU pousse les paquets sans les interpréter: toute l'intelligence est dans le client. Un MCU décode la vidéo qu'il reçoit, et la recode avant de l'envoyer au client.

              Il y a un seul serveur (qu'il faut payer) et de nombreux clients (qui ont déjà été payés). C'est donc a priori une bonne idée que de distribuer les opérations coûteuses en CPU (le codage de la vidéo) sur les clients et d'économiser le CPU du serveur — avantage au SFU. Par contre, si on recode la vidéo, on peut faire plein de choses malines, par exemple combiner plusieurs vidéos en une seule mosaïque à basse résolution, convertir l'audio en un format compatible avec SIP — avantage au MCU.

              Il me semble — mais je suis sans doute biaisé — que le modèle SFU est préférable lorsqu'on a assez de CPU et de débit côté client. Comme tu le fais remarquer, si le CPU est généralement disponible, ce n'est pas nécessairement le cas du débit. Galène contourne le problème en permettant au client de choisir quels flots il décide recevoir, par exemple uniquement l'audio, ou uniquement l'audio et la présentation.

              En pratique, nous avons deux serveurs: un serveur à un seul cœur (galene.org), utilisé pour l'enseignement, pour les réunions d'une association, et pour les apéritifs confinés, et un serveur à quatre cœurs, payé par le CNRS, et réservé aux activités de recherche. Le petit serveur commence à s'essouffler autour de 400 flots, mais Galène ne se plante pas: les vidéos commencent à freezer, puis reprennent lorsque les gens éteignent leurs caméras. Le gros serveur sert pour les réunions du laboratoire et pour les exposés scientifiques; il a aussi servi lors d'une conférence internationale (SOCS'2020). On ne l'a pas encore chargé suffisamment pour savoir comment il se comporte en situation de crise.

      • [^] # Re: Moins gourmand que BigBlueButton ?

        Posté par  (site web personnel) . Évalué à 5. Dernière modification le 23 décembre 2020 à 23:18.

        En ce qui concerne le CPU, il s'agit d'un serveur avec un seul cœur (le VPS OVH bas de gamme), et nous nous en servons régulièrement pour faire des cours avec 70 étudiants présents.

        Je suppose que c'est scénario d'usage du type 1 personne diffusant vers 70 autres, et éventuellement des discussions avec 2-5 vidéo allumées (pour des questions, …) ?
        Ou est-ce que c'est 70 webcam actives ?
        Des sous-groupes éventuellement ?

        Par rapport aux sous-groupes: est-ce que comme pour BigBlueButton, qu'il y ait 20 personnes (disons son + webcam) dans une seule salle ou dans 10, c'est la même charge côté serveur ?

        • [^] # Re: Moins gourmand que BigBlueButton ?

          Posté par  . Évalué à 9.

          Je suppose que c'est scénario d'usage du type 1 personne diffusant vers 70 autres,

          Oui.

          qu'il y ait 20 personnes […] dans une seule salle ou dans 10, c'est la même charge côté serveur ?

          Pas du tout.

          Avec 20 personnes dans un groupe, le serveur reçoit 20 flots, qu'il reémet chacun à 19 personnes. On a donc un total de 20+20*19 = 400 flots.

          Avec 10 groupes de deux personnes chacun, le serveur reçoit 20 flots qu'il reémet à une seule personne chacun, pour un total de 20+20=40 flots.

          Galène est capable, selon mes tests, de pousser de l'ordre de 400 flots par cœur. Sur un serveur à 4 cœurs, on devrait être capables de pousser 1600 flots, soit une réunion à 40 ou un amphi de 1600 personnes.

  • # Reverse proxy et matériel ARM64

    Posté par  . Évalué à 3.

    En lisant sa présentation sur le site et son README sur Github, je me pose ces deux questions:

    • Est-ce que Galène est prévu pour fonctionner derrière un reverse proxy ou un load-balancer ? Dans mon cas d'usage, j'ai un reverse proxy comme intermédiaire qui se charge de la connexion chiffrée entre les clients (ici, les navigateurs des participants) en WAN tout en communiquant de manière non-chiffrée avec le service de visioconférence en LAN pour les requêtes HTTP. Les paquets UDP pour les flux audio et vidéo sont transmis à part entre les clients et le service par le pare-feu.
    • Le site mentionne que Galène a fonctionné avec succès sur de l'ARM64. Quelles sont les cartes ARM64 qui ont été utilisées pour le faire fonctionner ?

    En tout cas, c'est prometteur pour avoir une alternative légère à l'usage et simple à maintenir par rapport à Big Blue Button. C'est ce genre d'alternative que je cherchais pour utiliser mes Olimex A64 comme serveurs de visioconférence.

    • [^] # Re: Reverse proxy et matériel ARM64

      Posté par  . Évalué à 10. Dernière modification le 23 décembre 2020 à 13:19.

      Est-ce que Galène est prévu pour fonctionner derrière un reverse proxy ou un load-balancer ?

      Galène utilise trois protocoles :

      • HTTPS pour le serveur web intégré ;
      • WSS (WebSocket au dessus de TLS) pour le chat et la signalisation ;
      • SRTP pour le traffic audio et vidéo.

      Pour le traffic HTTPS et WSS, tu fais comme d'habitude. Pour le traffic SRTP, il te faudra un serveur TURN, qui est essentiellement un proxy UDP. Le README inclus avec Galène donne quelques indications sur la mise en place.

      Galène va essayer d'établier un flot SRTP direct avant de se rabattre sur TURN après quelques centaines de millisecondes. Je vais ajouter une option qui indique que seul TURN doit être utilisé.

      Le site mentionne que Galène a fonctionné avec succès sur de l'ARM64. Quelles sont les cartes ARM64 qui ont été utilisées pour le faire fonctionner ?

      J'utilise des Olinuxino-A64 d'Olimex; la caractéristique importante pour Galène, c'est la crypto matérielle. J'ai décrit mes expériences ici : https://www.irif.fr/~jch/software/olimex-a64.html

  • # Pourquoi le choix GAFAM ?

    Posté par  . Évalué à -8. Dernière modification le 23 décembre 2020 à 22:43.

    Super, un logiciel libre \o/ Et zut, il est partagé sur une plateforme qui :
    - est non libre ;
    - exclut des millions d'utilisateurs sur décision d'un gouvernement (Patriot Act. Cloud Act., etc.) ;
    - impose de se soumettre au traçage de Microsoft ;
    - empêche la participation des libristes éthiques…

    N'est-ce pas contradictoire ?
    D'autres forges libres n'existent-elles pas ?
    Ne serait-il pas pédagogique de montrer qu'il existe autre chose en dehors des GAFAM ?

    • [^] # Re: Pourquoi le choix GAFAM ?

      Posté par  . Évalué à 2.

      Troll identifié !

    • [^] # Re: Pourquoi le choix GAFAM ?

      Posté par  . Évalué à 1.

      Il n'y pas de traçage sur GitHub.

      Troll confirmé.

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

      • [^] # Re: Pourquoi le choix GAFAM ?

        Posté par  . Évalué à 8.

        Je ne voudrais pas vous faire de peine mais avec toutes les techniques de profilage et le pistage côté serveur (Google Tag Manager entre-autres), nous n'en savons juste rien ; un peu de lecture à ce sujet.
        Ce n'est pas à charge contre Github spécifiquement, juste le garder à l'esprit.

      • [^] # Re: Pourquoi le choix GAFAM ?

        Posté par  . Évalué à 5.

        Pas besoin de mettre de cookie quand tu as directement les logs du serveur HTTP… :-(

    • [^] # Re: Pourquoi le choix GAFAM ?

      Posté par  . Évalué à 10.

      Je suis d'accord avec toi : c'est un compromis, voire une compromission.

      Dans une vie antérieure, j'ai essayé d'éviter GitHub. Le résultat, c'est que les gens ne contribuaient pas: ils ne me soumettaient pas de rapports de bugs (flemme de s'authentifier sur un autre site), ils se plaignaient qu'il fallait apprendre de nouvelles manières de soumettre un patch, ou, carrément, ils trollaient les forums en disant que le code n'est pas libre puisqu'il n'est pas sur GitHub.

      J'ai donc adopté un compromis: le code et le bug tracker sont sur GitHub, mais la liste de diffusion et la page web restent indépendantes. Comme tout compromis, il se fait critiquer des deux côtés : il y a des gens comme toi qui me critiquent pour mon utilisation de GitHub, et des gens qui se plaignent que je maintienne une page web au lieu d'utiliser un WiKi GitHub (regarde les archives de la liste de diffusion de Galène du 23 décembre).

      • [^] # Re: Pourquoi le choix GAFAM ?

        Posté par  . Évalué à -5.

        Tel est le chantage social mis en place par les GAFAM.
        S'y soumettre nous aidera-t-il à en sortir ?
        Les précédentes compromissions ne nous ont-elles pas justement menées là où nous en sommes ?
        Des irresponsables sans éthique sont-ils les contributeurs avec qui tu souhaites collaborer pour ton projet ?
        Ne faut-il pas répondre à un étudiant débutant (Antonin) la citation d'Albert Einstein « Faites simple mais pas simpliste. » et rappeler les dangers des GAFAM pour les utilisateurs, les développeurs, la démocratie… Et donc que si une fonctionnalité ou un usage paraissent pertinents, il ne faut pas leur sacrifier tout le reste pour autant !

        • [^] # Re: Pourquoi le choix GAFAM ?

          Posté par  (site web personnel, Mastodon) . Évalué à 5.

          Les personnes incapables de compromis sont souvent malheureuses. Je croise les doigts pour toi.

          #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo

          • [^] # Re: Pourquoi le choix GAFAM ?

            Posté par  . Évalué à -3.

            Refuser de tomber dans les pièges des GAFAM implique-t-il de ne jamais faire de compromis par ailleurs ?
            Comme le fait remarquer très justement jch, il y a une différence entre faire des compromis et se corrompre…

            • [^] # Re: Pourquoi le choix GAFAM ?

              Posté par  (site web personnel, Mastodon) . Évalué à 3.

              Des irresponsables sans éthique sont-ils les contributeurs avec qui tu souhaites collaborer pour ton projet ?

              Cette phrase ne laisse pas présager d'une grande ouverture d'esprit, d'où mon commentaire.

              il y a une différence entre faire des compromis et se corrompre…

              Cette phrase aussi, d'ailleurs.

              #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo

        • [^] # Re: Pourquoi le choix GAFAM ?

          Posté par  . Évalué à 6.

          L'alternative, c'est quoi? Bitbucket? C'était bien avant, mais avec toutes leurs refontes d'UI, c'est devenu pire, et pas qu'un peu, que github. Ça reste pas libre.
          Gitlab? Tant que c'est pas hébergé chez toi, pas libre.
          Sourceforge? On connaît, je pense.

          Ahhh sinon, y'a bien ça: savannah. Comment dire… même dans les années 2000, une interface de ce niveau était difficilement acceptable. La dernière solution, l'auto-hébergement, mais on t'a répondu pourquoi on peut ne pas vouloir (nouveaux identifiants).

          Bon, après, il y a peut-être une autre solution: auto-hébergement, avec une forge qui supporterait l'authentification via les SSO des… GAFAM. Doit être chiant à mettre en place ça, par contre.
          Tu as une piste? J'ai bien quelques projets persos à héberger, qui sont sur mon stagit perso, mais je doute qu'il y ait un jour une contribution, ce sont des gadget après tout.
          Si tu as une solution avec une authentification centralisée pour laquelle j'ai pas besoin de galérer des heures pour la mettre (et la maintenir) en place, pour laquelle je n'ai pas à charger trop ma pauvre VM cloud dont les 20Gig de disque sont déjà bien remplis, je me pencherai dessus.

          Oups, j'ai marché dedans.

          • [^] # Re: Pourquoi le choix GAFAM ?

            Posté par  . Évalué à -3.

            L'alternative, c'est quoi?

            GitlabCE et Gitea sont des alternatives libres intéressantes. Des instances sont trouvables sur le web :
            - https://framagit.org/
            - https://codeberg.org/
            - services du collectif CHATONS
            - …

            Ha oui, et sinon, je confirme qu'elles sont facilement auto-hébergeables.

            on t'a répondu pourquoi on peut ne pas vouloir (nouveaux identifiants).

            Sérieusement, si avoir un nouvel identifiant suffit à te freiner alors tes ambitions doivent être très faibles… Pour rappel, les gestionnaires de mots de passe, ça fonctionne très bien, même ceux intégrés aux navigateurs web, et les sessions longues durées aussi.

            Il y a une vie possible en dehors des GAFAM et elle est pleine de bonnes choses, essayez à l'occasion, vous risquez d'être surpris :o)

            • [^] # Re: Pourquoi le choix GAFAM ?

              Posté par  . Évalué à 5.

              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

            • [^] # Re: Pourquoi le choix GAFAM ?

              Posté par  . Évalué à 4.

              GitlabCE et Gitea sont des alternatives libres intéressantes

              Et rien ne prouve ni ne force que l'instance que tu utilises soit libre: c'est pas des licences AGPL (MIT et CC-BY-SA, à vue de nez).
              Triste, pour un extrémiste comme toi de ne pas avoir remarqué ce point.

              Sérieusement, si avoir un nouvel identifiant suffit à te freiner alors tes ambitions doivent être très faibles…

              Mes ambitions sont très bien ou elles sont, vois-tu. En fait, je pense que les DVCS c'est cool: je peux faire un code libre, le diffuser, et fork qui veut. Si ça veut poser une question, ça passe par le mail (oups, j'en ai un gafam…), si ça veut contribuer, idem.
              Même que j'hésite à utiliser fossil, pour avoir un truc plus sexy.

              Point de nouveaux identifiants, point d'usine à gaz web, c'est assez confortable, et mes ambitions apprécient ce petit monde cozy.

              Par contre, je comprend que ça ne soit pas le cas de tout le monde. Certains veulent coder en communauté sans être emmerdés par les insistances à utiliser GH, et je les comprend.

              Pour rappel, les gestionnaires de mots de passe, ça fonctionne très bien, même ceux intégrés aux navigateurs web, et les sessions longues durées aussi.

              Alors… en fait, je t'expliques: moi, je refuses catégoriquement de laisser un outil aussi complexe et bordélique qu'un navigateur web stocker des mots de passe. Idéalement, j'aimerai même ne pas avoir a passer par ces trucs pour quoique ce soit de sécurisé, tellement il me semble stupide de faire confiance a ces usines à gaz.
              Sur ce point, je fait ce qu'on appelle un compromis, tu devrais essayer.

              Ensuite, les gestionnaires de mots de passe… oui, faudrait que je fasse. Je me dis ça depuis des années, mais bon, j'ai plusieurs machines, et oui, j'ai la flemme de me trimballer une clé chiffrée sur moi qu'il me faille 1) avoir compatible windows (parce que je sais jamais quand je vais devoir intervenir sur un windows) 2) déchiffrer 3) espérer la compat des outils locaux… juste pour accéder à une forge, dont les informations sont toutes accessibles publiquement, de toute façon (parce que c'est le but. Oui, même le mail l'est, régulièrement).
              L'alternative, c'est synchroniser ses machines en permanence… ouai, en fait non, merci.

              Il y a une vie possible en dehors des GAFAM et elle est pleine de bonnes choses, essayez à l'occasion, vous risquez d'être surpris :o)

              Par exemple avoir mon propre VPS chez ovh pour héberger mes gadgets? Ouai, c'est déjà le cas, merci.

              PS: tu devrais essayer d'être moins extrême, c'est plein de bonne choses, tu risques d'être surpris :o)

              • [^] # Re: Pourquoi le choix GAFAM ?

                Posté par  . Évalué à 3.

                Franchement, même l’AGPL ne garantit rien. Au moins avec la GPL, même quand on a qu’un binaire, ou, plus vicieux mais moins commun, une source obfusquée, on a automatiquement le DROIT irrévocable partout dans le monde de faire de l’ingénieurie inverse, et de rendre ça plus lisible, et de PROUVER que c’est ce que le logiciel fait à la base. Mais avec un service, l’AGPL ne fait que te donner une garantie légale SI TU AVAIS un moyen de vérifier. Or il n’y en a aucun. La FSF elle-même met en garde contre ça, tout en mettant en garde contre le SaaSS en général, qui pour cette raison est largement pire que le logiciel privateur (c’est leur position officielle) : https://www.gnu.org/licenses/why-affero-gpl.html

                PS : c’est quoi le problème de l’extrêmisme ? :o tu es sûr que tu ne confonds pas avec l’agressivité ou le manque de pédagogie ?

                • [^] # Re: Pourquoi le choix GAFAM ?

                  Posté par  . Évalué à 3.

                  Franchement, même l’AGPL ne garantit rien. Au moins avec la GPL,

                  Ben, si la pré-condition légale est respectée, l'AGPL est «mieux» que la GPL, justement, puisque plus contraignante.
                  Mais bon, oui, il y a ce gros pré-requis que les gens respectent la loi…

                  PS : c’est quoi le problème de l’extrêmisme ? :o tu es sûr que tu ne confonds pas avec l’agressivité ou le manque de pédagogie ?

                  Pas faux :)

        • [^] # Re: Pourquoi le choix GAFAM ?

          Posté par  . Évalué à 7.

          Des irresponsables sans éthique sont-ils les contributeurs avec qui tu souhaites collaborer pour ton projet ?

          L'interface de Galène doit fonctionner sur tous les navigateurs: il est important qu'un étudiant qui a un problème d'ordinateur puisse suivre mon cours sur son smartphone. Comme je ne possède de smartphone moi-même, je dois compter sur la bonne volonté des utilisateurs pour me rapporter les problèmes avec Safari pour iOS — et cela alors même que, comme toi, j'ai des doutes sur les aspects éthiques de l'utilisation des systèmes d'Apple.

        • [^] # Re: Pourquoi le choix GAFAM ?

          Posté par  . Évalué à 5.

          « sans-éthique » ? pourquoi sans éthique ? je peux comprendre qu’on questionne le choix éthique de s’héberger sur github… mais si on parle de contributeurs qui ne savent que découvrir et contribuer via github… que font-ils de mal ? la victime dans l’histoire, c’est eux, qui sont victimes de surveillance et soumis à github. Même la FSF et rms disent qu’il n’y a rien d’amoral à utiliser un logiciel privateur, mais uniquement à en créer ou imposer un.

          https://www.gnu.org/philosophy/saying-no-even-once.html

          Il me semble qu’en plus d’agressivité et de manque de pédagogie (quoi que, ici on est plein de gens déjà convaincus ou dont l’opinion est déjà bien installée), tu moralises trop la question, au point de t’en prendre aux gens qui ne pensent ou agissent pas selon les mêmes règles morales… alors même que selon celles que tu semblerais suivre, ils ne font rien de mal :o

          Rappelons que le problème du logiciel privateur est qu’il vous prive de votre liberté, c’est dans le nom. C’est les utilisateurs les victimes, pas les bourreaux. Le logiciel privateur n’a pas de problèmes moraux « pour rien », juste « comme ça », pour des raisons sorties de nulle part, mais pour de bonnes raisons, des raisons politiques, qu’on peut analyser et questionner. Et ici il me semble que le choix politique est complexe.

          Genre, notamment… même en s’auto-hébergeant, la seule personne dont la liberté est garantie est l’hébergeur… mais les contributeurs utilisent toujours un logiciel qu’ils ne contrôlent pas… sauf à utiliser seulement git… mais auquel cas ils ont autant le contrôle de leur informatique qu’avec github (il reste un problème de surveillance, mais une forge libre (pour son proprio) qui n’est pas github a autant de pouvoir de surveillance que microsoft avec github… c’est juste qu’il s’agit d’une entité plus petite et donc moins puissante).

          • [^] # Re: Pourquoi le choix GAFAM ?

            Posté par  . Évalué à 2.

            sauf à utiliser seulement git… mais auquel cas ils ont autant le contrôle de leur informatique qu’avec github (il reste un problème de surveillance, mais une forge libre (pour son proprio) qui n’est pas github a autant de pouvoir de surveillance que microsoft avec github… c’est juste qu’il s’agit d’une entité plus petite et donc moins puissante).

            La solution, du coup, c'est fossil, non?

    • [^] # Re: Pourquoi le choix GAFAM ?

      Posté par  . Évalué à 2.

      Je pense que le principal problème c’est que techniquement github a la liberté de modifier les sources et les logs que voient tout le monde à n’importe quel moment. Par chance il ne l’a jamais fait et (peut-être pour ça) l’architecture de DVCS de git fait qu’un développeur quelconque qui a cloné le dépôt le verrait.

      Par contre quelque chose qui serait utile pour ça serait de miroiter le dépôt ailleurs, pour qu’on puisse le clôner sans passer par github (voire y autoriser le push à certaines personnes), et de fournir une liste mail où on puisse envoyer des patchs « à l’ancienne »… et comme une mailing-list indépendante est fournie, je pense que c’est une façon très efficace de procéder (vraiment pas loin d’annuler tout problème pour un contributeur qui bouderait github), même si je déplore… purement personnellement, l’usage de github.

      Car malheureusement, l’argument de Julius sur les contributions semble être un argument valide et de poids :/ Les commentaires sur cette page semblent en revanche montrer que ce n’est pas qu’un problème d’éducation politique mais aussi d’implémentation (ou d’éducation technique, mais c’est pareil, ça joue sur un même continuum)… donc le milieu déjà libriste n’est pas dans l’impasse !

      Il est vrai que l’interface de git est souvent mal expliquée, voire cryptique, et que les forges libres n’ont pas encore de système de fédération… néanmoins depuis Mastodon, les systèmes de fédération standards et ouverts comme GNU Social (aka statusnet) d’autrefois semblent regagner en activité… donc il y a sans-doute un espoir, niveau « authentification web unique ».

      Quant au reste, personnellement je ne suis pas un grand fan du web (git existe en dehors de celui-ci !!), et j’aimerais que de meilleurs clients à git et au mail existe, car le mail est en effet pas mal en train de mourir… en faveur à d’autres plateformes et protocoles toujours plus éphémères et instables… car les gens sont de moins en moins bien éduqués techniquement, et de plus en plus rendus dépendant de cages dorées du SaaSS. Mais là on touche un croisement entre éducation technique et éducation politique… et c’est donc évidemment pas un problème simple :/ qui demande au final beaucoup d’empathie (ça j’ai pas moi par exemple :') c’est pas toujours une compétence très simple ou répandue à ce niveau) et de pédagogie (pareil, tout le monde en a pas)… Mais il me semble que ce que semble nous montrer ce que dit Julius est qu’il y a un problème plus important de la part des contributrices/eurs (occasionnel·le·s ?) qui restent cantonné·e·s à github, que de la part des projets qui s’y limitent. Et comme il le dit, il va clairement au moins partiellement à contre-courant ici, donc garde une efficacité au moins positive.

      • [^] # Re: Pourquoi le choix GAFAM ?

        Posté par  . Évalué à 4.

        As-tu entendu parler de Source-Hut ? C'est une forge libre, basée sur git et les mailings list. N'importe qui peut participer sans compte sur la plate-forme, simplement avec Git et un client mail.

        Le projet avance bien et est déjà largement utilisable malgré le statut alpha.

        • [^] # Re: Pourquoi le choix GAFAM ?

          Posté par  . Évalué à 3. Dernière modification le 28 décembre 2020 à 08:17.

          Je serais preneur de retours sur l'utilisation de SourceHut dans un journal. Le projet est cool et je suis content d'en entendre parler, mais je l'imagine encore très pénible à utiliser donc je n'ai pas encore fait le pas.

          (Peut-être la prochaine fois que j'encadre un-e stagiaire, la dernière fois on a utilisé gitea pour voir, on pourrait essayer de partager du code par SourceHut.)

          P.S.: Gitea c'est raisonnable, l'interface ressemble énormément à celle de Github. Il manque certaines fonctionnalités auxquelles ont est habitué. La personne qui hébergeait me disait que c'était beaucoup plus facile/agréable à héberger que Gitlab. Points qui m'ont un peu gêné:

          • les notifications par email ne marchaient pas ou mal (peut-être lié à la configuration)
          • les commentaires dans les Pull Request ne se comportaient pas très bien quand le code de la PR changeait (ils restaient à l'emplacement initial alors que le code avait bougé.)

          • [^] # Re: Pourquoi le choix GAFAM ?

            Posté par  . Évalué à 2.

            J'ai pas de retour à faire sur la revue de code via Source-Hut, j'en ai jamais fait. Cependant c'est un paradigme différent de la revue de code via git(ea|hub|lab), c'est basé sur l'envoi de patch par e-mail, comme pour le kernel.

            La plate-forme fourni la mailing liste et permet de visualiser efficacement les patchs. Tu as aussi un CI qui te permet de tester ce qui arrive sur le dépôt et dans la mailing list aussi je crois.

            • [^] # Re: Pourquoi le choix GAFAM ?

              Posté par  . Évalué à 2.

              yep, on utilise ça pour le projet Gio (gioui.org).

              je dois avouer que venant de GitHub, l'adaptation d'impédance a été un poil déroutante au début (ainsi que la configuration de git-send-mail, probablement en grande partie à cause du fait de mon utilisation de ProtonMail).

              mais on s'y fait rapidement.

              commenter des patchs se fait juste en répondant au patch/mail, l'interface web se débrouille pour "recoller les morceaux" et associer un commentaire avec la bonne ligne du patch (côté présentation web du patch).

              le fait d'avoir une mailing liste associée au projet est un plus indéniable et permet de limiter le "détournement" du bug tracker comme un helpdesk.

              les patchs sont donc envoyés par mail, mais on peut également les envoyer depuis l'interface web, en sélectionnant le (ou la plage de) commit(s) que l'on veut soumettre au projet.

              • [^] # Re: Pourquoi le choix GAFAM ?

                Posté par  (Mastodon) . Évalué à 2.

                probablement en grande partie à cause du fait de mon utilisation de ProtonMail

                ?? Tu peux développer ? Il y a des incompatibilités avec ProtonMail ? (et avec d'autres services mail ?)

                Surtout, ne pas tout prendre au sérieux !

                • [^] # Re: Pourquoi le choix GAFAM ?

                  Posté par  . Évalué à 2.

                  à l'époque, proton-bridge était peu stable.
                  et il a fallu se démerdouiller un peu avec hydroxide.

                  maintenant ça marche.

                  le gros du problème était l'installation+configuration d'un serveur smtp+imap local pour récupérer+déchiffrer les mails depuis ProtonMail et pour les envoyer+chiffrer.

                  les instructions sont un peu plus claires:

                  et voici mon .gitconfig:

                  [sendemail]
    smtpserver = 127.0.0.1
    smtpuser = <proton-mail-user-name>
    smtpserverport = 1025
    smtppass = <pouet-pass-phrase>
    smtpsslcertpath = "~/.config/protonmail/bridge/cert.pem"

              • [^] # Re: Pourquoi le choix GAFAM ?

                Posté par  . Évalué à 3.

                J'ai essayé de regarder des exemples de revue de code sur le dépôt de sr.ht lui-même, mais c'est un dépôt avec assez peu de commentaires ligne-à-ligne sur les patches (ce qui éveille ma méfiance, en fait). Est-ce que votre dépôt est public, tu peux nous montrer un exemple de discussion autour d'un petit bout d'un diff comme on en aurait sur une forge git plus classique ?

                (J'ai compris que ça se fait par email, mais ce que j'aimerais voir c'est la vue à travers cet outil, comment ça se passe quand on fait un commentaire sur une sous-partie en particulier du ptach et qu'il y a une petite discussion suite à ce commentaire.)

  • # Merci de nous donner une alternative contre la fataliste course à la fonctionnalitée

    Posté par  . Évalué à 7.

    Oh mon dieu merci ! je pense vraiment que de telles nouvelles redonnent espoir dans la fatalité qu’était parfois de venue la visioconférence libre, surtout quand comme moi on est sur du vieux matos RYF, qui tend à être assez lent… Je pense que de nos jours la course à la fonctionnalité, au bloat, comme elle est très visible dans jitsi, BBB, et dans le web et la vidéo en général, est sans-doute une mauvaise chose pour l’innovation logicielle, surtout quand on se dit que la plupart des utilisateurs ignorent totalement la plupart des fonctionnalités qu’on leur propose (sans parler de tout le travail demandé derrière !) alors qu’ils vivent néanmoins le coût en performance et les limites que ça impose (comme les besoins croissants en débit internet) !

  • # Jitsi

    Posté par  (site web personnel) . Évalué à 5.

    Il me semble que l'architecture est au final assez proche de Jitsi (qui était aussi une initiative française).

    Question : pourquoi faire un nouveau logiciel ? Il n'était pas possible d'améliorer Jisti ? Question complémentaire : il y a du code commun entre les deux projets ?

    Perso, j'utilise souvent rendez-vous de RENATER (Jitsi) et c'est vrai que je le trouve plus simple que BBB globalement. Il est facile à trois personnes de partager leur écran et chacun va voir ce qui l'intéresse…

    Dans le cas de conf, le préchargement des PDF dans BBB est pas mal. Tout le monde se connecte en mode audio sauf l'orateur qui n'a même pas à partager son écran. Avec pas mal de personne dans la salle, je pense qu'on est meilleur en terme de tenue de charge.

    Il faudrait passer d'un mode SFU en MCU selon le nombre de personne ;-)

    Une fonctionnalité souvent demandé sous Jitsi et BBB, pouvoir diffuser simplement vers du webcast youtube ou autre. Pour une conf avec énormément de personne, on met les principaux intervenants dans la conf et tout le reste en podcast + chat ! L'interconnexion facile des deux mondes serait donc un sacré plus.

    • [^] # Re: Jitsi

      Posté par  . Évalué à 8.

      Il me semble que l'architecture est au final assez proche de Jitsi

      Oui, et aussi de Janus et de Ion-SFU, que je cite sur galene.org. Ce sont tous des SFU, et ils sont tous bien faits.

      Il n'était pas possible d'améliorer [Jitsi] ?

      Jitsi est écrit en Java, ce qui complique un peu sont déploiement (il faut installer un JRE sur le serveur), et augmente sensiblement la consommation de mémoire. Par contre, j'avais sérieusement considéré la possibilité de baser Galène sur Janus, qui est économe, propre, et écrit en C; j'ai finalement décidé de faire mon propre serveur, j'ai peut-être eu tort. Quant à Ion-SFU, il n'était pas encore prêt à l'époque.

      il y a du code commun entre les deux projets ?

      Nous collaborons régulièrement avec les auteurs de Ion-SFU, qui, comme Galène, est basé sur Pion WebRTC. Lorsqu'il y a du code qui peut être utile aux deux projets, nous essayons de le contribuer à Pion: c'est mieux que de faire du copier-coller, et ça profite à tous les projets basés sur Pion.

      Dans le cas de conf, le préchargement des PDF dans BBB est pas mal.
      […]
      Il faudrait passer d'un mode SFU en MCU selon le nombre de personne ;-)
      […]
      pouvoir diffuser simplement vers du webcast youtube ou autre

      Il faut faire attention à ne pas ajouter trop de fonctionnalités : le but de Galène est d'être un logiciel simple, efficace et robuste et dont les fonctionnalités sont strictement limitées.

      • [^] # Re: Jitsi

        Posté par  (site web personnel) . Évalué à 3. Dernière modification le 27 décembre 2020 à 15:25.

        Il faut faire attention à ne pas ajouter trop de fonctionnalités

        Oui. Cependant le support du webcast est quelque chose de très demandé. Dans un amphi de 100 personnes, une interconnexion Galène / Podcast Youtube (ou équivalent) serait un vrai plus. Pour le moment, tout le monde bricole en mettant un client dans la webconf qui rediffuse sur un podcast via capture du flux. Bilan, s'il n'y a pas un informaticien pour mettre en place la tuyauterie, c'est impossible à faire pour un prof.

        Idem pour les conf ou séminaire de labo… La webconférence en temps réel est pas envisageable dans les gros labo en terme de ressource, et puis cela n'a pas de sens écologique de le faire. 30 s de délais sont acceptable pour 90% des participants.

      • [^] # Re: Jitsi

        Posté par  (site web personnel) . Évalué à 2.

        Jitsi est écrit en Java, ce qui complique un peu sont déploiement (il faut installer un JRE sur le serveur)

        Qu'est-ce qui est compliqué dans apt install openjdk-11-jre ?

        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

        • [^] # Re: Jitsi

          Posté par  . Évalué à 5. Dernière modification le 13 janvier 2021 à 22:53.

          Bon après pour contribuer, faut avoir envie de faire du Java… :)

          (et pour déployer sur une toute petite machine ou un routeur, j'imagine aussi que c'est compliqué)

  • # App Yunohost

    Posté par  . Évalué à 4.

    Une app a été créée pour Yunohost pour ceux qui ne veulent pas mettre les mains dans le cambouis ! C'est tout frais donc peut-être que tout ne marche pas encore parfaitement du premier coup.

    aussi sur le salon xmpp:linuxfr@chat.jabberfr.org?join

Suivre le flux des commentaires

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