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
- Description de Galène (2791 clics)
- Serveur de démonstration (2044 clics)
# Moins gourmand que BigBlueButton ?
Posté par gasche . É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 jch . É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:
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 BAud (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 gasche . É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 BAud (site web personnel) . Évalué à 1.
bah va construire ton moteur de recherche de malware :-)
[^] # Re: Moins gourmand que BigBlueButton ?
Posté par jch . É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 Pilou . É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 jch . Évalué à 10.
C'est un SFU.
[^] # Re: Moins gourmand que BigBlueButton ?
Posté par BAud (site web personnel) . Évalué à 5. Dernière modification le 23 décembre 2020 à 14:21.
concrètement, la question de Pilou< était plutôt :
bref, comment que ça fonctionne bien ?
[^] # Re: Moins gourmand que BigBlueButton ?
Posté par jch . É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 lapineige (site web personnel) . Évalué à 5. Dernière modification le 23 décembre 2020 à 23:18.
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 jch . Évalué à 9.
Oui.
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.
[^] # Re: Moins gourmand que BigBlueButton ?
Posté par lapineige (site web personnel) . Évalué à 4.
Merci pour ces informations ! :)
Ce qui me surprend c'est que, sauf erreur, BigBlueButton fait aussi du SFU, et que dans son cas qu'importe la répartition, c'est le nombre total de flux qui compte: https://docs.bigbluebutton.org/support/faq.html#how-many-simultaneous-users-can-bigbluebutton-support
Pourquoi une telle différence ?
Et pour préciser et situer: les tests ont été fait avec quel matériel ? Notamment pour savoir quel est la fréquence du cœur.
[^] # Re: Moins gourmand que BigBlueButton ?
Posté par jch . Évalué à 2.
Le VPS bas de gamme "Value" d'OVH: https://www.ovhcloud.com/fr/vps/compare/
D'après /proc/cpuinfo, c'est un Haswell à 2.4Ghz, mais c'est une machine virtuelle, et je ne sais pas dans quelle mesure ça réflète le matériel sous-jacent.
[^] # Re: Moins gourmand que BigBlueButton ?
Posté par lapineige (site web personnel) . Évalué à 2.
Merci pour cette réponse.
Ça semble être confirmé ici https://www.vpsbenchmarks.com/hosters/ovh_cloud/cpus
Donc ce n'est clairement pas un matériel des plus puissant, ce qui est plutôt bon signe quand aux performances :)
Dommage qu'un raspberry pi ne supporte pas la cryptographie matérielle (est-ce que ça pourrait fonctionner en mode logiciel, avec des performances correctes ?), y'aurait du potentiel (4x1,5Ghz).
[^] # Re: Moins gourmand que BigBlueButton ?
Posté par jch . Évalué à 4.
Sur un Raspberry Pi 4 — probablement, l'Ethernet est connecté en RGMII, et la librairie standard de Go implémente AES en assembleur NEON.
Sur un Raspberry Pi 1 — probablement pas, l'Ethernet est connecté en USB, le coût des entrées-sorties risque d'être prohibitif.
Si tu décides d'essayer, je serai reconnaissant si tu postes tes conclusions sur la liste de diffusion de Galène.
[^] # Re: Moins gourmand que BigBlueButton ?
Posté par lapineige (site web personnel) . Évalué à 1.
Je vais voir pour essayer d'installer tout ça, et si j'y arrive de le packager pour Yunohost, auquel cas le test sera possible pour moi (et d'autres) sur un Raspberry Pi 4 (et 3 aussi) et probablement d'autres matériels du genre (Olimex, …). J'essayerai de penser à vous faire un retour :)
Merci pour les infos ! :)
[^] # Re: Moins gourmand que BigBlueButton ?
Posté par lapineige (site web personnel) . Évalué à 1.
Un paquet pour Yunohost a été créé :) : https://github.com/YunoHost-Apps/galene_ynh
[^] # Re: Moins gourmand que BigBlueButton ?
Posté par jch . Évalué à 2.
N'hésite pas à envoyer une annonce à galene@lists.galene.org.
[^] # Re: Moins gourmand que BigBlueButton ?
Posté par lapineige (site web personnel) . Évalué à 1.
Je pourrais attendre un peu, le paquet n'est pas encore pleinement fonctionnel (il reste le serveur TURN ou STUN à configurer).
Vaut-il mieux attendre que ce soit pleinement fonctionnel, ou faire une première annonce comme appel à contribution ?
Question bonus: si j'envoie un message à la liste sans m'y abonner, je recevrai des réponses ?
# Reverse proxy et matériel ARM64
Posté par volts . Évalué à 3.
En lisant sa présentation sur le site et son README sur Github, je me pose ces deux questions:
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 jch . Évalué à 10. Dernière modification le 23 décembre 2020 à 13:19.
Galène utilise trois protocoles :
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é.
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
[^] # Re: Reverse proxy et matériel ARM64
Posté par Benjamin Henrion (site web personnel) . Évalué à 2.
Est-ce possible d'enlever la crypto? Ou est-ce qu'elle est obligatoire?
[^] # Re: Reverse proxy et matériel ARM64
Posté par jch . Évalué à 4.
Le protocole WebRTC (utilisé pour communiquer avec les navigateurs) chiffre et authentifie obligatoirement le traffic. On n'a donc pas le choix, il faut tout chiffrer.
Par curiosité — pourquoi as-tu besoin de communication en clair ? Est-ce pour des raisons légales ?
[^] # Re: Reverse proxy et matériel ARM64
Posté par Benjamin Henrion (site web personnel) . Évalué à 2.
Non, juste pouvoir le faire tourner sur des petites machines.
Je vais faire une image Docker.
[^] # Re: Reverse proxy et matériel ARM64
Posté par Axelos (site web personnel) . Évalué à 1.
Bonjour, cela m’intéresse beaucoup.
J’ai vu sur la liste de diffusion officielle que quelqu’un voulait aussi créer une telle image, mais je ne comprends pas trop ce qui est indiqué.
https://lists.galene.org/galene/0688ccc55ed16925427c08c0dfa9794e@kn1ght.org/T/#u
De ce que j’ai compris les images dockers sont multiplateformes, est-il possible de partager la création si vous y arrivez ?
Bien cordialement, Axel.
[^] # Re: Reverse proxy et matériel ARM64
Posté par lapineige (site web personnel) . Évalué à 1.
Je ne sais pas où chercher l'info sur le support de la cryptographie matérielle, alors à tout hasard : des tests ont été fait sur un Raspberry Pi ? Ça fonctionne ? Et si non, est-ce qu'il supporte cette crypto matérielle ?
[^] # Re: Reverse proxy et matériel ARM64
Posté par jch . Évalué à 4.
Apparemment pas : https://www.raspberrypi.org/forums/viewtopic.php?t=243410
# Pourquoi le choix GAFAM ?
Posté par cpm . É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 dani . Évalué à 2.
Troll identifié !
[^] # Re: Pourquoi le choix GAFAM ?
Posté par xcomcmdr . É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 Xanatos . É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 cpm . Évalué à 5.
Pas besoin de mettre de cookie quand tu as directement les logs du serveur HTTP… :-(
[^] # Re: Pourquoi le choix GAFAM ?
Posté par jch . É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 cpm . É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 LeBouquetin (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 cpm . É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 LeBouquetin (site web personnel, Mastodon) . Évalué à 3.
Cette phrase ne laisse pas présager d'une grande ouverture d'esprit, d'où mon commentaire.
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 freem . É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 cpm . Évalué à -3.
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.
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 dani . É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 cpm . Évalué à 3.
Les données collectées par des GAFAM ont permis l'élection de Trump et le Brexit par la manipulation ciblée des électeurs, voir le scandale Cambridge Analytica :
Si, si, Github exclut des millions d'utilisateurs :
Qu'à fait Github ? Poussé des libristes à mettre leurs projets libres sur une plateforme privatrice, espionnante et excluante alors qu'ils auraient pu continuer à être hébergés sur des plateformes libres ?
Le fait que tu en arrives à penser cela, voilà qui montre combien Github porte atteinte au Libre et à l'humanité :-(
[^] # Re: Pourquoi le choix GAFAM ?
Posté par freem . Évalué à 4.
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.
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.
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.
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 galex-713 . É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 freem . Évalué à 3.
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…
Pas faux :)
[^] # Re: Pourquoi le choix GAFAM ?
Posté par jch . Évalué à 7.
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 galex-713 . É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 freem . Évalué à 2.
La solution, du coup, c'est fossil, non?
[^] # Re: Pourquoi le choix GAFAM ?
Posté par galex-713 . É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 amdg . É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 gasche . É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é:
[^] # Re: Pourquoi le choix GAFAM ?
Posté par amdg . É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 Sebastien . É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 tisaac (Mastodon) . Évalué à 2.
?? 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 Sebastien . É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
:[^] # Re: Pourquoi le choix GAFAM ?
Posté par gasche . É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.)
[^] # Re: Pourquoi le choix GAFAM ?
Posté par Sebastien . Évalué à 1.
voici quelques exemples:
[^] # Re: Pourquoi le choix GAFAM ?
Posté par gasche . Évalué à 2.
Merci !
(La vue "archives" est bien meilleure pour voir les conversations, la vue "patchset" montre la dernière version du patch et quelques commentaires.)
# Merci de nous donner une alternative contre la fataliste course à la fonctionnalitée
Posté par galex-713 . É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) !
[^] # Re: Merci de nous donner une alternative contre la fataliste course à la fonctionnalitée
Posté par Benjamin Henrion (site web personnel) . Évalué à 0.
Enlever la crypto pour soulager le CPU?
# Jitsi
Posté par Sytoka Modon (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 jch . Évalué à 8.
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.
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.
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.
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 Sytoka Modon (site web personnel) . Évalué à 3. Dernière modification le 27 décembre 2020 à 15:25.
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 devnewton 🍺 (site web personnel) . Évalué à 2.
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 karteum59 . É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 anubis . É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.