rootix a écrit 735 commentaires

Comme je l'ai indiqué, je ne réponds pas aux commentaires/questions ici.

L'IRC n'étant effectivement pas pratique, pas d'historique, etc,… j'ai un forum pour poursuivre la discussion.
Les étapes servent aussi là à filtrer les gens assez motivés.

Le forum s'authentifie sur une boutique en ligne donc :

• pour s'inscrire au forum, il faut commander un produit gratuit ici : https://christophegx.ovh/produit/christophegx-init
• mettre les bonnes informations dans la création du compte (adresse physique)
• attendre que je valide la commande, l'url est transmise avec la commande

Des réponses aux questions posées ici seront dans le forum.

J'ai ajouté deux pages la-dessus, j'en parle toute à l'heure.

J'ai ajouté une page la-dessus, j'en parle toute à l'heure.

Ce programme ne vise pas les experts et est découpé en 3 bouts pour une très bonne raison. J'apprends d'une part à enseigner Et en même temps à utiliser des déclencheurs émotionnels (partie marketing mais de façon transparente, surtout dans la dernière partie du webinaire n°3). Je connais la théorie de pleins de choses en marketing mais je ne vais pas appliquer tout cette fois-ci car ça me fait beaucoup d'un coup. Au bout de 20 webinaires, ça devrait être mieux :-)

La prochaine version de la session se fera en Avril/Mai et je pense supprimer la partie "choix d'un serveur" et la convertir en vidéos autonomes sur ma chaîne youtube que je vais démarrer.

Je changerai le mot quand cette page aura disparu de Wikipédia :-) Webinaire

Je vais annoncer un test technique pour le 15 octobre.

Les webinaires commenceront à l'heure (+ entre 30 secondes et 1 minute), je ne pourrais pas attendre 15 minutes que les gens installent flash. Il y a un protocole d'attente au début de quelques minutes mais ça commencera rapidement au bout de 5 minutes maximum. La durée de chaque webinaire n'est pas connue étant donné que c'est la première fois que je fais ça mais a priori, je suis censé faire plus ou moins 1h de contenu (sans les questions/réponses) à chaque fois pour un temps total de 1h30/2h.

Ce sera disponible en replay pendant quelques jours.

Je referais cette présentation 3 fois par an environ avec à chaque fois des améliorations avec l'expérience (et ajustant le contenu à chaque fois en fonction des remarques) et en conservant une partie en "live". La session suivante se fera fin Mars/début Avril.

Mes sondages me disent que les gens veulent installer un serveur sécurisé. J'ai donc écrit le titre en fonction de ce qu'ils veulent savoir mais le contenu sera plutôt orienté progressivement sur ce qui doivent savoir (les bonnes pratiques et un aperçu des étapes d'installation).
Je vais commencer tout juste à préparer le contenu des webinaires (j'ai déjà pré-préparé le contenu/structure). Y a plus ou moins 5 étapes, il fallait que je trouve un titre avec un chiffre assez rapidement pour faire les annonces. Je vais m'arrranger pour que ça fasse 5 à la fin :-)

:-)

Pour être transparent, les webconférences vont servir à préparer, à terme, la version sous forme écrite+vidéo. La version écrite sera terminée en Novembre avec les premiers volontaires et les vidéos seront remplacées par des webconférences privées (en attendant d'enregistrer des vidéos HD 1080p). Il y aura donc bien une autre version de la formation, en plus approfondie et sous forme d'enseignement "pur", associée avec un forum et un "truc" spécial en plus mais je réserve ça pour la dernier conférence à la fin.

Ces webconférences en particulier ne sont pas des MOOC, c'est un format particulier dont une partie est l'enseignement.

Si tu t'inscris, tu pourras revoir en replay les conférences jusqu'au 10 Novembre environ.

Je m'appuie sur une solution "saas" qui elle-même s'appuie sur google hangout et youtube live, qui a deux énormes défauts :
- il s'écoule 30 secondes entre moi et la réception du live. Il y a un salon/chat avec la vidéo, qui lui, est temps réel, mais pas la vidéo ce qui est problématique pour une petite interactivité.
- la deuxième partie du problème est la résolution de capture de mon écran qui est visiblement limitée par google hangout alors que j'ai assez de bande de passante pour être un peu au dessus. Et la résolution de réception s'adapte semble-t-il à la taille de la fenêtre. Mon terminal de commande capturé par hangout demande une haute résolution pour être lisible : j'ai essayé plusieurs tailles/polices/couleurs, j'ai trouvé la moins pire. C'est légèrement flou mais lisible, à condition que les gens agrandissent leur fenêtre pour faire basculer la résolution au niveau au dessus.

À ma connaissance, il n'y a pas pour l'instant de solutions s'appuyant sur du logiciel libre (pour le même prix) pour faire de la large diffusion (>50 personnes).

La solution idéale utiliserait sans doute bigbluebuttton + un truc pour faire la diffusion à large échelle.
Le plugin flash sert à lire le flux live provenant de youtube, ça ne marche pas en HTML5.

La conférence n'est pas une conf call. Même dans la réalité, les questions/réponses sont regroupées sinon ça serait le bordel.

La conférence va suivre une structure particulière, je sais que personne n'est habitué, ce ne sera pas comme dans une conférence style RMLL ou autres endroits. Je suis et j'apprends en même temps un protocole particulier.

Un développeur GNOME m'a effectivement dit que c'était corrigé : je vais devoir trouver du temps pour mettre à jour mon PC. Je pensais le faire semaine 43.

Non, je ne suis pas un diable. Je suis un ange !

J'ai deux fois la semaine 13 ! sans rire !

le passer à toutes les 5 secondes alors

Le Channel Viewer Protocol (CVP) (pour les gens qui veulent afficher des infos sur leur site) et le tableau de bord Mumble sur le site utilisent la même librairie pour avoir les infos des Mumbles et donc j'avais prévu dès le départ un système de cache qui fait que si tu reloads de force à moins de 30s, tu auras les mêmes infos qu'avant. Pour éviter un DDOS indirect des Mumbles (via le CVP surtout) ou trop de charge (je préfère être prudent). Les mises à jour, elles, sont directes mais bon je ne vais pas mettre un gendarme derrière tout le monde.

Je note les autres remarques, ça me parait bien.

j'ai même essayé de le renouveler (ça n'a pas l'air de vouloir fonctionner :/)

:-) J'ai prévu le cas du renouvellement pour les services gratuits Dans ce cas précis, ça ne rajoute pas du temps mais ça ajoute à la date de maintenant. Donc en principe, ça s'est prolongé juste un petit peu (au bout d'une minute d'attente).

Mumble fait la différence entre un utilisateur connecté et un utilisateur enregistré. Tu ne peux pas rendre admin un utilisateur qui n'est pas enregistré. Sinon, dans l'onglet 'Utilisateurs enregistrés', tu auras le bouton pour le mettre admin. C'est bien mis dans la doc peut-être avec d'autres mots :-)
En fait, j'avais l'intention (un jour) de faire un patch pour Mumble ICE permettant de mettre admin un utilisateur connecté et non enregistré (en gros, l'enregistrer à sa place et le mettre admin ensuite).

Le compteur est censé faire comprendre que les informations ne seront pas rafraîchies avant le zéro. Par exemple, si tu te connectes sur Mumble et que tu n'apparais pas dans l'interface, en principe le compteur sert à comprendre qu'il faut attendre zéro pour apparaître. Sinon pour l'histoire du compteur qui ne va pas forcément à zéro, c'est "normal". J'ai estimé 1s environ le temps de rechargement. Sinon je pourrais attendre zéro, afficher "Chargement" dans l'attente de la réponse de la requête mais ça va te stresser encore plus :-)

Je ne sais plus quelle version d'android j'avais essayé mais ça ne marchait pas. Je vais tester celui-là et étudier si ça marche aussi bien que sur les autres systèmes.

La confusion serveur/service Mumble est soit volontairement faite soit naïvement faite dans tous les sites qui proposent ça. Ce n'est pas complètement faux mais jusque là j'ai toujours réservé le terme serveur à l'OS et le terme service à un machin qui écoute derrière un port réseau. Donc j'ai volontairement fait l'erreur puisque sinon ça n'est pas compris. Le terme salon ne convient pas puisqu'il peut y avoir plusieurs salons par "serveur".

Sinon le reste sera corrigé :-)

Pour ta dernière phrase, je n'ai pas compris. Si les bouts doivent atterrir sur github, le premier sera la librairie ICE pour le pilotage de Mumble. J'ai "simplement" repris le projet django-mumble où tout est en vrac pour extraire ce qui était important et en faire un fichier plus petit mais je n'ai pas tout remis et je me pose encore des questions sur un point, je trouverai certainement la réponse lors des prochaines versions de Mumble.

Une autre chose intéressante aussi est comment transformer django-oscar, qui est prévu seulement pour une boutique de produit, en une boutique de service.

Et puis y a les fichiers javascript angularjs. J'ai ouvert la doc de angularjs pour la première fois y a moins de 3 semaines. Malgré que ce n'est pas vraiment entièrement clair pour moi, j'ai réussi à faire une interface qui marche.

Des choses que je pourrais mettre sur github, y en a des tonnes :-) Ensuite je n'ai pas envie de m'en occuper et les maintenir forcément. Et de toute façon, github je n'aime pas, on peut scanner le code pour trouver qui fait quoi, quand et avec qui, c'est une atteinte à la vie privée selon moi (j'espère ne choquer personne mais ce sujet a déjà évoqué quelque part).

Pour le mot de passe permettant de joindre un serveur, je sais qu'il est impossible à retenir et même difficile à transmettre, c'est pourquoi j'ai mis un autre bouton pour transmettre les infos par email (avec l'éventuel problème de temps de transmission à cause des listes grises des serveurs mails). Mais je pense que je vais trouver un générateur de mot simple pour ce mot de passe dont le but est simplement d'éviter la pollution du Mumble.

le compte est tout juste créé à 13h44, mais la page de gestion du compte indique que le serveur est lancé depuis 1H43

En fait, c'est bien le cas, un certain nombre de serveurs est lancé d'avance pour pouvoir être attribué immédiatement. Ils sont préparés à certaines heures automatiquement en fonction du stock restant. Je vais voir pour ajouter une info quelque part.

il manque un petit lien vers le logiciel "client"

Le lien est présent dans la partie documentation (l'énorme bouton bleu à 2 cm au dessus :-) )
Mon idée est de mettre la doc au plus proche du moment où on se pose la question, c'est donc encore trop loin !

En tout cas, merci pour le test !

On n'interdit pas (en tout cas pas moi) de mettre une signature avec un lien vers son entreprise. Si vous gagnez un client grâce à ça, tant mieux. Mais encore faut-il que ce lien soit dans la signature et non dans le message (comme c'était le cas ici) et qu'en plus le commentaire en soit vraiment un et non pas une phrase avec pour seul but d'y glisser un lien.

Je suis tagué administrateur parce que j'héberge le xmpp mais je n'ai aucun accès particulier sur la partie web. D'après ce que je suppose, seul le compte elasticsearch a été atteint et ça explique pourquoi rien d'autre n'a été coupé. Si "on" coupe le reste, pas sûr que ce soit relancé avant quelques semaines à cause des vacances. Il n'y a pas de solution idéale mais supposons un instant que des données soient volées, couper le service ne fera pas revenir les données comme les moutons du berger. Il faut attendre pour savoir ce qui a été fait et ensuite pour avertir si besoin mais j'ai seulement l'impression qu'il n'y a pas personne pour s'en occuper actuellement : tout le monde est bénévole, problème de vacances, et manque de temps libre.

Du code arbitraire a pu être exécuté depuis le début de la version RoR de linuxfr

-> Je ne crois pas que elasticsearch soit là depuis le début.

La faille a été exploitée pendant plus d'une semaine

-> La faille a consisté à (au moins) générer un flux UDP en sortie.

La réponse est uniquement de désactiver le service problématique

-> Non, la réponse immédiate est de désactiver le service. Il me semble que c'est la procédure normale, résoudre l'incident pour remettre en route et ensuite résoudre le problème pour une solution longue durée.

Il n'y a eu aucune vérification que le système n'est plus vérolé, aucune vérification…

-> Il faudrait utiliser l'outil de suivi pour voir si quelque chose est prévu mais faute de vacances, rien n'avance vite. Mais d'après ce que j'ai compris, elasticsearch tournait sur son propre utilisateur et le compte a été désactivé.

Je me demande si on ne pourrait pas faire d'une pierre deux coups en mettant deux champs optionnels pour la publication : publier entre [date de départ] et [date de fin]. La date de fin peut être la date de l'événement et le caractère urgent peut être déterminé en fonction de la proximité. La date de départ peut servir si une dépêche ne doit pas être publiée avant cette date. J'imagine que ça demande un peu plus de travail à programmer surtout pour proposer un beau popup pour choisir la date :-)

C'était un problème de limitation de la taille du titre. J'ai raccourci le titre pour pouvoir ajouter le s.

Les détenant de brevets sont nuisibles aux sociétés détenant aussi des brevets, qui elles, sont très très nuisibles aux logiciels libres. L'impact pourrait être davantage positif au bout du compte.

Tu as envoyé ton logo à qui ? Il semblerait que personne n'a vu passer la proposition.