Le fil de discussion que j'ai initié m'a permis de comprendre que mon patch avait des répercussions imprévues, notamment sur l'UI. Je suis d'ailleurs surpris que personne n'ait abordé dans le thread le problème des fichiers .po (i18n) dont la mise à jour doit être lourde.
Pour conclure, je me range à ton avis et vais proposer un patch "comme un grand", peut-être la semaine prochaine.
Très bien. :-)
Ensuite oui tu peux t'attendre à des rejets parfois (sur ce patch ou un autre), des incompréhensions, etc. Mais règle numéro 1: ne jamais le prendre mal, ni personnellement. Aussi il faut être prêt à revoir ton code.
Il n'y aussi aucun mal à insister un peu, mais toujours poliment et amicalement. Ça m'est déjà arrivé des fois d'avoir des patchs rejetés et le ticket fermé, et je le rouvre avec un commentaire expliquant davantage pourquoi j'estime que c'est important et que je suis prêt à modifier le patch pour m'adapter aux besoins et corriger les problèmes, des fois avec un nouveau patch si je sais déjà quel problème ont les dévs upstream avec mon premier patch. Et des fois, ça marche et ils acceptent l'idée évoluée.
Par exemple dans ton cas, peut-être qu'ils te diront effectivement qu'il faut une nouvelle option. Dans ce cas, tu dis que tu vas rééecrire sous la forme d'une nouvelle option. Peut-être qu'ils te diront que la liste des options est trop longue. Dans ce cas, dirige les vers le lien du forum avec le gars qui pense qu'il faut plein d'options, et tu peux aussi dire que tu as eu des retours d'utilisateurs qui ont dit que ton option particulière serait très utile, cela peut créer une discussion pour revoir la façon dont cette liste est présentée (comme je disais, je vois très bien un système de format pour que tout un chacun puisse créer son timing personnalisé).
Si on te répond pas vite, faut pas prendre mal, tu peux d'ailleurs te permettre de relancer de temps en temps (pas trop, attend quelques semaines entre les relances). Ça veut aussi dire que de ton côté aussi, rien ne presse. Personne ne t'en voudra si tu mets un peu de temps à répondre, et tu peux prendre tout le temps nécessaire pour rechercher le code et écrire proprement tes nouvelles versions de patch.
Au final la contribution au Logiciel Libre, c'est un peu une leçon de zen. Il faut essayer de jamais s'énerver (des fois, c'est dur), de ne rien prendre personnellement, de prendre son temps et être persistant en même temps. Et un jour, tu te rends compte que tout va bien en fait. Ces mecs en face, ils sont comme toi. Ils n'avaient rien contre toi ni ta fonctionnalité, ils avaient juste du mal à la comprendre.
Tout cela dit, peut-être au contraire que ta fonctionnalité va leur plaire et qu'ils l'accepteront d'entrée de jeu sans aucun problème. Je veux juste te préparer au "pire" parce que je sais que les premiers patchs rejetés peuvent être démoralisants quand on ne connaît pas encore. Ça peut arriver. Mais si t'es sûr de ton idée, hésite pas à revenir à la charge en proposant des alternatives. Des fois même après un an ou 2 s'il le faut, il arrive que les dévs revoient leur jugement (et en attendant, tu utilises ta version patchée juste pour toi).
Ou alors si tu te mets à proposer d'autres patchs régulièrement, tu deviendras peut-être toi-même core dév d'Audacity, et dans ce cas tu auras plus de poids pour reproposer ta modif plus tard. :-)
Tout est question de patience.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je suis d'accord avec gasche. Je suis de nombreuses mailing list, mais "de très haut", c'est à dire que de temps en temps, je jette un œil et vais répondre à 3/4 messages dans les derniers messages, ceux qui m'ont l'air le plus pertinent. Mais je sais que j'en aurai passé plein. Ce n'est pas grave, c'est le format des mailing lists (et les forums, c'est pareil): des discussions qui passent, s'éteignent, puis à un moment disparaissent dans des archives. D'ailleurs il m'est aussi arrivé très souvent de commencer une discussion à laquelle personne ne répond jamais et elle passe dans l'oubli. Je ne m'offusque pas. C'est le format attendu, comme j'ai dit.
Les outils de suivi, c'est un format totalement différent: un ticket ouvert y a 10 ans, mais que personne n'aura trouvé irraisonnable (mais qui n'a pas eu de résolution dans le code pour autant) sera encore en haut de la liste 10 ans après. Une entrée de suivi n'est oubliée que le jour où on décide soit que c'est une fonctionnalité inutile, soit qu'il y a une résolution (= patch).
Ensuite il y a des projets qui privilégient forums/mailing lists comme lieu de décision, et là c'est différent. Mais ça reste l'exception.
pour quelqu'un comme moi qui cherche à comprendre l'envers du décor et le processus de décision, le thread que j'ai créé est riche d'enseignements.
Soit dit en passant, j'ai jeté un œil au fil de discussion que tu donnes (au passage, le bon lien est: http://forum.audacityteam.org/viewtopic.php?f=20&t=82163 L'option finale du lien que tu as donné semble vouloir me forcer à entrer un login). J'ai l'impression qu'aucun des dévs ne t'a répondu, celui qui semble répondre le plus, Edgar, ayant l'air extérieur à l'équipe core d'après les termes qu'il choisit. À le lire, il semblerait qu'il ait lui-même des patchs perso et n'a jamais fait l'effort de les proposer.
Donc je vois pas quel enseignement tu peux en tirer, et surtout comment tu aies pu comprendre quoi que ce soit de "l'envers du décor". Tu restes du côté spectateur. Encore une fois, tu n'obtiens que des "on dit". C'est donc surtout du vent.
À un moment donné, il faut passer dans la cour des grands. Et c'est comme à l'école: une fois que tu y es passé, tu te rends compte que les "grands" ne sont pas différents des "petits" et qu'il n'y avait en fait aucune raison d'avoir peur. Les autres grands (car tu en es devenu un aussi à ce moment là) sont les mêmes, ils ont simplement changé de cour. Donc laisse tomber les "on dit", et essaie de soumettre ton patch plutôt que d'écouter un mec qui vraisemblablement n'a jamais essayé de changer de cour, même s'il avait les bonnes billes pour le faire.
Une fois que tu auras vraiment discuté avec les dévs, acteurs d'Audacity, là tu auras un aperçu de "l'envers du décor".
Au passage, vous pointez dans le fil de discussion la problématique de la longueur du menu quand on ajoute trop d'options. Voilà une bonne problématique en effet. Il n'est proposé qu'un dialogue comme seule alternative. Mais il y a mieux en fait: personnalisation totale du format. Par exemple, une liste assez limitée peut être donnée, mais avec la possibilité de personnaliser exactement le contenu avec une syntaxe custom. Par exemple il est classique d'utiliser une syntaxe dérivée du format de printf. Par exemple %h %m %s pour heure/minute/secondes. %S pour seconde avec décimales (donc on a les ms derrière la virgule), %M pour millisecondes, %f pour les frames en 24fps, etc. Donc l'utilisateur entre le format qu'il souhaite, il peut même avoir un mix de pleins d'infos en même temps s'il le souhaite, pourquoi pas!
Ce type de personnalisation permet simplicité (avec une liste de petite taille des usages les plus courants) + usage avancé (avec un format pour obtenir exactement ce que tu souhaites en tant qu'utilisateur avancé).
Peut-être peux-tu leur proposer quelque chose dans ce sens s'ils refusent ta première version de patch. Mais dans tous les cas, même là on s'avance trop. Dans un premier temps, envoie ton patch et parle avec les intéressés! Plus de "on dit", plus de "et si".
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ceci dit, la première chose à faire est d'en parler avec les développeurs d'Audacity. Tu (pas cosmocat, mais Xavier, l'auteur de la dépêche) sembles te baser entièrement sur une supposition pour ne même pas proposer un patch et t'imaginer qu'il sera rejeté de toutes façons. Alors oui il est tout à fait possible que des choses soient à revoir (ça arrive à tout le monde, dans tous les projets). Peut-être même qu'ils refuseront de but en blanc l'idée même du patch, qui sait! (je connais pas l'équipe d'Audacity ni s'ils sont arrangeants, ou braqués par exemple)
Mais tout ça t'en sauras rien si tu demandes pas. Va y humblement et diplomatiquement avec ton patch, et sois prêt à recevoir les critiques (s'il y a lieu, ça se trouve, ils le trouveront même bien tel quel, qui sait!) et améliorer le patch en conséquence. Et cela ira probablement.
Ceci dit, petit avis perso: ajouter des millisecondes ne me semble pas contredire le nom de la fonction "secondes" à ce point selon moi. Les millisecondes sont une variante (ou une subdvision) de l'unité seconde. Je ne vois pas de contradiction.
Mais peut-être que les dévs d'Audacity verront les choses autrement, j'en sais rien. Et dans ce cas là, ajouter une option peut en effet être une autre possibilité (ou encore changer le nom de la fonction). Et franchement je vois déjà une dizaine d'option pour l'affichage du temps, je doute que les dévs upstream aient un gros problème si tu souhaites en ajouter une avec une bonne raison (et tu en as une). Mais cela, je te conseille de voir cela directement avec les dévs du projet. Pas la peine de perdre ton temps pour du code qui sera pas pris.
Perso ma manière de travailler est la suivante quand je veux une fonctionnalité: je fais la base dans mon coin, car ça me sert de "preuve de concept", donc ça illustre bien mieux ce que je veux que du texte dans une requête de fonctionnalité, et surtout les dévs du projet me tiennent au sérieux dès le début car ils ont un patch à se mettre sous la dent et donc ils répondent beaucoup plus vite. Ça c'est ce que t'as fait et c'est très bien.
La seconde étape est de proposer ton patch de base une fois qu'il est un peu propre. Et à partir de là, la discussion avec upstream peut commencer et c'est le moment où tu fignoles, et où tu auras peut-être des concessions à faire en effet, ou bien du code à ajouter ou changer pour aller dans le sens du projet tout en intégrant ta nouvelle fonctionnalité intégralement.
Et quand c'est fait, le projet upstream est content et intègre ton patch. En général les projets sont contents d'avoir de nouvelles contributions. Ils espèrent même que les contributeurs restent et proposent plus de patchs à l'avenir. Faut pas croire mais la plupart des projets (même certains qui ont l'air gros, car connus à une certaine échelle) ont très peu de contributeurs. Je pense donc que tu as toutes tes chances.
Reste pas là sur linuxfr à piétiner et à te demander si oui ou non ils intègreront. Va direct sur leur logiciel de suivi, et donne ton patch. S'ils répondent pas vite, n'hésite pas à lancer un petit message sur la mailing list par exemple (ou autre de leurs canaux habituels de discussion, par exemple s'ils ont IRC), poliment et gentillement (genre "hey I submitted a patch a few days ago, would someone be kind enough to review it? I'm happy to change things if there are issues", un lien et quelques petits smileys bien placés). Et tout ira bien.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ok je vois, mais ça c'est du bidouillage. C'est acceptable si j'en ai besoin une fois et veut une solution un peu tarabiscotée mais rapide et sans me prendre la tête à chercher une vraie bonne solution de long terme. Si je vais dans ce sens là, je peux même faire encore plus simple: je n'ai pas besoin du VLC intermédiaire, je peux juste rediriger le flux directement du serveur vers le PC source.
Mais ça ne tient pas la distance: le PC source peut changer d'IP déjà parce que ma connexion n'a pas d'IP fixe contractuellement (même si dans les faits elle l'est habituellement); mais surtout quid si je me connecte depuis ailleurs? Et/ou avec un autre PC? Je dois à chaque fois refaire une manœuvre complexe? Et puis de nos jours, les foyers sont en général derrière un routeur, donc je dois rediriger les ports si je souhaite que le serveur puisse se connecter sur le PC source (puisque lui-même devenu serveur en attente de connexions). C'est possible (mais chiant) quand c'est chez moi et impossible si je souhaite me connecter depuis un réseau sur lequel je n'ai pas la main. Et même chez moi, je dois refaire la manœuvre si je souhaite utiliser un autre PC source.
Sans compter tous les problèmes de sécurité que l'on peut rencontrer dans ce genre de bidouillage où un serveur voudrait lire des données depuis une autre machine à travers le net sans aucune identification de la source ni sécurisation (c'est acceptable depuis un réseau local totalement sous contrôle uniquement).
En gros c'est pas du tout ce que je cherche. Ça je pouvais déjà bidouiller un système encore plus simplement avant de demander. Ce que je cherche, c'est une solution propre pour du long terme. C'est pour ça que je demande ce qu'il existe en solution existante et bien pensée. J'ai un serveur, il a une IP fixe accessible sur le net, et sans bidouillage à faire. Je veux juste lui installer un service maison de streaming, que j'associerai à un sous-domaine de mon domaine principal, de sorte qu'avec les logiciels adéquats, je suis capable de me connecter quand je veux en tant que "client source", depuis n'importe quel ordi et depuis n'importe où avec le login adéquat, et je peux donner une URI à des gens divers et variés sur le net pour que ces derniers puissent se connecter sur le serveur et y regarder ma vidéo en live (ces derniers n'ayant en général pas besoin de login par contre, bien qu'on puisse s'imaginer que des fois on veuille aussi limiter qui peut voir).
La solution BigBlueButton qui a été donné plus haut correspond bien plus (du peu que je peux lire). Et probablement IceCast aussi. Probablement FreeSee aussi. Maintenant je suis intéressé s'il existe d'autres solutions similaires et surtout par des retours d'expérience, et/ou des comparaisons de ces solutions.
Merci.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Oui mais c'est ce que je dis! VLC avec streaming HTTP, c'est pour la partie serveur. Là, ok on est d'accord. Mais il doit bien récupérer le stream du desktop d'une façon ou d'une autre (qui ne vient pas de la mēme machine, mais d'une autre). Soit c'est un fichier, et dans ce cas là, c'est plus du live; soit il existe un protocole qui connecte 2 VLC, celui du desktop qui sert de source (en enregistrant le bureau) et celui du serveur qui écoute sur un port et une IP donnée.
Dans les autres propositions, le streaming sur WMP ne me convient pas (je ne compte pas me limiter à un logiciel Windows seulement). On est sur linuxfr après tout! ;-)
RTP et UDP, c'est pour diffuser vers des addresses données (unicast/multicast).
Seul IceCast dans la liste semble correspondre au besoin, mais on n'est plus dans le cas "2 VLC" qu'on m'a présenté, mais dans celui plus classique VLC source + IceCast serveur que je connaissais déjà.
Donc j'essaie de comprendre ce cas "2 VLC" que vous me présentez comme répondant à ma problématique et qui n'est pas présenté dans cette liste.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je pense qu'il y a incompréhension. J'ai bien entendu lu le lien qui m'a été donné. Les méthodes de streaming sont: "affichage local", "fichier", "envoi vers Microsoft Windows Media Player" qui ne correspondent pas au problème; HTTP, qui si je comprends bien permet de streamer directement comme un serveur HTTP, et donc serait parfait si le serveur source et le serveur de streaming étaient la même machine (c'est la méthode que les gens semblent proposer avec vlc-nox — qui n'est qu'un VLC normal sans rien de particulier, hormis qu'il ne repose pas sur X — quand on veut faire un serveur de streaming media pour lequel on a déjà des fichiers en local), mais ce n'est pas mon cas d'usage; UDP et RDP dont je ne suis pas sûr mais c'est apparemment pour du unicast/multicast; et enfin IceCast dont je parle plus haut.
Vous semblez tous les deux dire qu'il y a apparemment un autre moyen en connectant 2 instances de VLC sur deux machines différentes, l'un servant de sources, l'autre de serveur de serveur de stream. Je veux bien vous croire, mais je ne trouve aucune information à ce sujet nulle part, et le lien donné ne parle pas de cette possibilité additionnelle. Donc je demande si vous avez des liens qui expliqueraient une telle chose (aussi, il va sans dire, mais j'attends une solution un minimum sécurisée. Je veux pas ouvrir un port qui accepte n'importe quelle source sans login, clé ou autre type d'identification car mon cas d'usage passe par le net, non au travers d'un réseau interne).
Edit: pour être plus clair, VLC permet en effet de streamer du desktop. Là n'est pas la question. Mais le serveur (la machine qui va gérer la partie streaming) n'a pas de desktop par définition. Il doit donc recevoir le média généré par un autre ordinateur. Il doit donc y avoir un protocole entre la machine "source" et la machine "streaming". Je n'ai pas l'impression que VLC puisse gérer un tel transport de média d'un VLC à l'autre. Ou du moins je trouve pas, et le lien donné n'indique pas cela. Donc je veux bien avoir d'autres liens si une telle chose existe.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Oh ok, vlc est donc capable d'envoyer un stream directement à l'instance distante de vlc-nox pour que celle-ci puisse le redistribuer? J'arrive pas à trouver de doc qui explique cela. Je ne trouve que des docs qui explique comment streamer des fichiers existants. Vous auriez des liens?
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Salut. Oui ça c'est pour le client source, mais dans le contexte d'un streaming pour que des gens hors du réseau puissent se connecter, hormis le cas où le client est aussi serveur http par exemple (cas simple d'un fichier déjà enregistré), il faudra encore un serveur icecast (je vois qu'y a une prise en charge d'icecast dans VLC en effet). Donc en gros, tu conseilles Icecast en tant que serveur et VLC en tant que client?
Mais puisque je vois que tu conseilles vlc-nox comme serveur de streaming, alors je me dis que tu conseilles peut-être plutôt d'encoder dans un fichier avec VLC sur le bureau, puis d'envoyer le fichier sur le serveur, puis là d'utiliser vlc-nox. Ce n'est donc plus du live mais du différé.
Ou alors j'ai pas compris une autre possibilité? Je rappelle que je veux pouvoir enregistrer et streamer en direct en passant par un serveur, car le client source d'enregistrement (un ordi pour utilisation desktop) enregistre mais n'est pas celui qui streame.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Le truc des films en VO ça revient tout le temps pour expliquer qu'on parle mieux dans d'autres pays. Comme si ça avait un rôle majeur. C'est bizarre que ça revienne si souvent, c'est comme si tous le monde était d'accord là-dessus, que c'était effectivement majeur.
Oui en effet, mais faut peut-être voir cela comme un tout. Plutôt que de se dire ce qui est majeur ou mineur, on peut voir le fait que dans le même pays où les gens sont très bon en anglais et comme par hasard le fait qu'ils aient une culture des films en VO non pas comme une coïncidence, non pas comme un lien de cause à effet, mais avec une relation tout de même. C'est un pays qui embrasse globalement une approche de la langue étrangère plus intensément.
En France, on a cette culture du tout VF, et ça correspond peut-être avec notre approche des langues étrangères au second plan et notre système scolaire non adapté probablement. Aux US, eux j'ai l'impression qu'ils s'intéressent très peu aux films étrangers tout court (donc ils ont même pas tellement besoin de doublage, du moins pas aussi souvent), et ça correspond au fait qu'ils s'intéressent assez peu aux langues étrangères aussi scolairement (ils en apprennent, mais le résultat paraît globalement pire qu'en France), semblerait-il.
En gros, ce sont plein de petites choses qui font un tout. Chercher un élément particulier avec un "rôle majeur" est probablement une erreur, selon moi. Effectivement passer tous les films en VO à la télé ne rendra pas soudainement la population française bilingue si on ne fait que cela. Mais ça y aidera si on l'additionne à d'autres "petites choses".
Le fait qu'on soit un peu au tout VF dans notre pays est donc symptomatique, plus qu'une cause "majeur".
Bon ensuite c'est juste une petite pensée comme ça. Je n'ai pas vraiment d'avis plus poussé sur le sujet et n'y ai jamais réfléchi intensément. C'est clairement pas un de mes chevaux de bataille. :-)
Je pense donc finir cette discussion sur cette mini réflexion, qui est peut-être totalement fausse, qui sait, et dans tous les cas très certainement superficielle!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Sinon en te lisant j'ai l'impression qu'au Danemark tu as dû t'exprimer en anglais. Ca serait pas ça le facteur majeur de progression de ton anglais ? Les clichés, quand on les a dans la tête, ils sont très difficiles à déloger. Même quand on a les preuves sous le nez.
Ben oui je parle aussi pas mal anglais dans diverses situations depuis des années (j'ai vagabondé pas mal, j'ai aussi vécu au Japon 2 ans et 1 an en Corée, et travaillait alors pour une boîte US, puis j'ai vécu 1 an en Nouvelle Zélande), et au Danemark aussi je parlais souvent anglais (j'avais pris des cours de danois, mais c'était dur d'en placer une, on me répondait en anglais dès qu'on comprenait que j'étais étranger). Aussi je suis développeur sur pas mal de projets Libres, donc ma langue principale sur le net, c'est l'anglais. J'ai jamais dit le contraire. Et je dis pas non plus que regarder des films en VO est une solution miracle (je dis même le contraire avec la blague de "l'anglais en 3 leçons").
Ce que je dis, c'est que la VO aide. Mais bien entendu, rien ne replace la discussion en vrai avec des gens qui parlent anglais. Ça me paraît tellement évident que ça me fait de la peine de devoir le préciser!
Et je ne dis rien non plus sur l'enseignement à l'école et quel est le meilleur modèle, etc. Je ne dis pas non plus que regarder des films en VO remplace l'école ou la vraie discussion d'ailleurs. Non c'est juste très complémentaire.
De manière générale, regarder des films en anglais, ça peut apporter pas mal de vocabulaire que tu n'auras pas forcément, même en vivant aux US/UK ou en parlant avec des anglophones régulièrement, tout simplement parce que chaque personne prend l'habitude d'utiliser son propre vocabulaire assez limité. Et puis dans les films, ils aiment bien créer des personnages un peu extrêmes qui parlent avec des tournures particulières. De la même façon qu'en regardant des films (ou lisant des livres) en français, j'apprends des fois des mots, ou réapprends des mots que j'avais presque oubliés (et ce, même si je parle français depuis la naissance). L'apport en vocabulaire s'applique aux médias vidéos (films, etc.) comme à la lecture (livres, etc.).
Ensuite ce que les films apportent et qu'on n'a pas dans la lecture, c'est le son, c'est à dire l'entraînement de la compréhension orale. Et ça tu ne l'as pas autant dans tes cours scolaires non plus, car le temps est plus limité (puisque les films, tu les regardes en général dans ton temps libre), mais surtout tu vas surtout parler avec des gens de ton niveau, ce qui n'est pas du tout la même chose.
De manière générale, beaucoup de gens ont ce niveau "intermédiaire" en France qui est qu'ils peuvent très convenablement s'exprimer en anglais acceptable (voire parfois très bon grammaticalement et en vocabulaire), mais que dès que quelqu'un leur parle avec un accent inhabituel, ou très vite, ou dans une grande salle avec un écho et du bruit et des gens qui parlent à côté, etc. ben ils sont paumés. Ben pour ça, rien ne vaut la pratique d'entendre de l'anglais. On peut le faire en vivant dans un pays anglophone, mais même là, cela reste limité car on entend en général des accents similaires selon son activité. Par contre les films apportent souvent une variété. La première fois que j'ai vu Snatch, je pensais devenir fou tellement certains persos sont incompréhensibles (et je faisais constamment retour arrière pour essayer de comprendre certains textes). Mais après avoir vu des dizaines de films de ce genre, soudain on se rend compte qu'on comprend un truc qu'on comprenait pas il y a peu. Avec un film, tu travailles la compréhension, reconnaître les accents (ça a l'air évident après coup, mais quand on débute, on ne reconnaît aucun accent. J'ai une amie qui débute en français et quand elle entend un accent très fort d'une autre région de la France, elle fait pas non plus de différence), etc.
Ensuite oui, rien ne remplace de dialoguer en anglais régulièrement. Et juste regarder des films en VO n'est pas suffisant pour parler anglais (d'ailleurs on ne parle pas, on écoute). Ça me paraît évident. Ça n'en enlève pas les apports des films.
De même, ce n'est pas un passage obligé. Il y a aussi d'autres moyens pour en arriver au même résultat (parler avec beaucoup de gens différents par exemple afin de capter la même diversité qu'on a dans les films sans bouger de sa chaise).
Enfin voilà, je sais pas pourquoi tu te braques et sembles vouloir absolument prouver coûte que coûte que regarder la VO ne sert absolument à rien.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Le cliché, c'est que les gens parlent tous bien anglais au Danemark ou c'est que regarder des films en VO aide beaucoup à la langue?
Parce que pour le premier, ben écoute, j'ai vécu un an au Danemark (pas à la capitale, mais à Ålborg, au nord). Je suis pas resté cloîtré h24 chez moi. J'allais aussi au supermarchés: les caissières parlent anglais parfaitement. J'allais dans des bars paumés: tout le monde, jusqu'à l'ivrogne sdf parle en anglais. J'ai traversé le pays entier en auto-stop, etc. En un an, je suis tombé que sur un gars qui ne parlait pas (ou ne voulait pas) anglais. Donc je dis pas que j'ai rencontré tous les danois, mais quand même. C'est loin d'un cliché.
Si c'est le second: je vais pas prétendre posséder la méthode ultime pour l'anglais, mais c'est justement lors de mon séjour au Danemark que je me suis mis à regarder tous mes films en VO sans sous-titre. Le "sans sous-titre" est probablement la clé. Comme je disais plus haut, les yeux sont attirés par les sous-titres et même quand on comprend, on va lire. Ça m'arrive même si je regarde un film en français avec sous-titre, pour dire! C'est même pire que tout car des fois, les sous-titres ne sont pas bien traduits, ce qui perturbe carrément le cerveau entre ce qu'on entend et lit.
Ben depuis lors, mon anglais a énormément progressé. Bien sûr ce n'est pas la seule raison, loin de là, et je vais pas prétendre que je sais à quel point ça joue (d'ailleurs pour ça que j'ai dit "très probablement"). Alors je me plante peut-être, mais en mon for intérieur, je pense que ça aide quand même pas mal.
Ensuite je le répète: même si regarder en vo sous-titré aide probablement aussi à mon avis, passer au VO tout court (sans sous-titre), là tu peux que progresser (d'après mon expérience perso, encore une fois, c'est pas une méthode "telle langue en 3 leçons"). Y a un monde entre les deux. Tu te concentres bien plus sur ce que les acteurs disent, et quand tu comprends pas, ton imagination gambade beaucoup plus pour essayer de deviner après coup ce qu'ils ont dit (car oui, selon moi l'imagination et essayer de "deviner" est extrêmement important dans l'apprentissage d'une langue pour la compréhension orale et l'appréhension des sons. Avec les sous-titres, on perd pas mal de cette partie là).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Perso je regarde en anglais sans sous-titre. Comme tu dis, les sous-titres sont une forme de "pollution visuelle", et surtout ça attire l'œil. Je me retrouve à lire les sous-titres quand y en a, même quand je comprends parfaitement la langue, et c'est très inconfortable.
Cependant même quand je comprends pas une langue (ou pas suffisamment pour être confortable à l'écoute), je préfère la VO avec sous-titres à la VF. Le fait est que la langue véhicule d'autres choses en plus du sens, culturelles notamment. Va écouter un film en Japonais. Le timing, les intonations, les accroches sont totalement différentes et c'est pas ou difficilement transférable (sans compter les multiples "sons", sans traduction, très typique du Japonais que les gens ne feront jamais en français). L'image même rend totalement différente quand on l'entend avec la VO et la VF dans ce genre de cas.
Peut-être ensuite que les gens qui ne sont pas du tout intéressés par les langues étrangères ne sont pas très sensibles à ce genre de "tics" culturels, et ne les remarquent pas vraiment en VO?
Mais je suis d'accord que le doublage peut aussi s'adresser à une autre catégorie: ceux qui ne lisent pas suffisamment vite, ou qui ne parle aucune langue étrangère (et sont donc bien moins réceptif à ces dernières de manière générale).
Aussi beaucoup de dessins animés passeront plutôt bien en doublage. Et c'est vrai que pour les gosses, leur imposer de la VO peut être rude (quoique d'autres diront que ça leur enseigne la langue. Par exemple dans certains pays, notamment nordique, presque tout reste en VO. Et ça participe très probablement au fait qu'au Danemark par exemple, où j'ai vécu un an, les gens parlent tous anglais parfaitement).
En conclusion, je suis pas contre le doublage, mais je pense qu'on en a quand même trop en France (mais t'es dans le business, forcément tu vas pas être d'accord, je le comprends bien! :p). Et pourtant j'ai moi-même été doubleur pendant de nombreuses années.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je lui ai pas reproché d'utiliser un protocole proprio. Je lui ai dit que ce serait cool d'avoir aussi une prise en charge du protocole qu'on utilise habituellement sous Linux et lui ai demandé s'il avait un projet dans ce sens. Faut arrêter de vouloir à chaque fois prendre les gens à revers.
C'est le dernier message que je t'adresse dans ce fil, Zenitram, car je sais que sinon tu vas essayer de faire partir la discussion dans tous les sens en présupposant sur ce que j'ai voulu dire en sous-entendu dans mon message. Zenitram, le troll ultime.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
J'ai lu un peu plus en détail et je lis "Sony 9 pin protocol, a serial cable and a video reference signal, our product synchronizes with audio recording software (Protools, Cubase, etc.)."
Moi dans le workflow évidémment tout-Libre que je souhaiterais développer, mon idée était plutôt de se synchroniser avec des logiciels comme Ardour, pas des logiciels proprio. Le protocol de synchro serait probablement Jack sous Linux. T'as des projets dans ce sens?
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Cela fait des années que je souhaitais justement faire ce logiciel (pas "celui ci" en particulier, mais un logiciel de doublage quoi). Mais j'attendais d'en avoir vraiment l'utilité (bientôt, j'espère).
J'ai aussi une dizaine d'années d'expérience, mais probablement de l'autre côté du micro (j'imagine que tu étais ingé son?).
Je vais regarder les détails quand j'aurais un peu de temps pour faire un système de build pour Linux. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Oui, en fait si vraiment y a pas assez de vente (genre du tout), on pourrait annuler (paypal permet de faire un remboursement dans les 60 jours). Ceci dit, avec les tarifs les plus raisonnables d'imprimeurs numériques (pour de l'offset, c'est si on fait au moins 100 voire 200 que ça devient plus avantageux), on peut payer les frais avec tout juste une vingtaine de calendriers apparemment, donc je ne pense pas que cela arrivera. Si cela arrivait, ce serait pas un succès clairement, mais donc au moins l'association n'y sera pas "de sa poche", ou pas trop. Ensuite c'est sûr, y a du temps perdu, mais c'est une expérience qui pourra servir. Donc de ce point de vue là, c'est pas réellement "perdu".
En fait je vois cela sous divers angles: déjà pour aider le Logiciel Libre, ensuite pour promouvoir l'Art Libre, mais aussi pour voir ce qui intéresse les gens sans trop de risques (parce que les "études de marché" dont nous parlent les banquiers, franchement c'est souvent bidon). Si certaines choses de cette sorte fonctionne, ça ou des posters, ou quelque chose d'autre, ben on en fera peut-être d'autre plus régulièrement. C'est donc un peu de l'expérimentation libriste.
Pour l'asso, clairement l'idée est que si on trouve quelque chose qui intéresse les gens et qui puisse nous aider à financer au moins partiellement certains de nos frais, c'est aussi un des buts. Ça nous permettrait de nous concentrer sur nos projets plus sérieux (comme faire des films d'animation par exemple). Donc ce sont des expérimentations aussi dans ce sens.
Pour les affiches, j'y ai pensé aussi d'ailleurs. Ça peut être sympa en effet.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ahahahaha. Oui j'avais oublié que la poste vend aussi ses calendriers.
Ceci dit, les pompiers sont passés chez nous y a quelques mois et ils demandaient juste de l'argent (y avait rien en échange). Enfin si, ils donnaient une facture si tu avais besoin, ce qui est encore moins moins glamour, même que les calendriers de chat ou de manchots. Je sais pas s'il faut s'attendre à les voir revenir encore, cette fois avec un calendrier "power-ranger", ou si c'est tout pour l'année. Peut-être que je suis d'une autre époque et que les calendriers c'est trop has-been? Avec toutes mes années à l'étranger, je suis devenu à la ramasse, maintenant on vend des apps, plus du papier. :P
Sinon les éboueurs sont passés, et eux laissent… un petit papier cartonné A6 avec toute l'année dessus avec une seule photo moche en minuscule dans un coin (ils savent que les gens payent de toutes façons, plus besoin de se faire chier à trouver de belles images et à faire un grand format?), en guise de calendrier que j'ai jeté direct après avoir payé la dîme. Les calendriers, des temps révolus!
Mais j'espère quand même que vous voudrez le notre! C'est pour la bonne cause! :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
N'hésite pas à me tenir au courant sur comment ça se passe.
Aussi j'ai déjà plusieurs évolutions sur ma copie locale. Dès que j'aurai un peu tout mis au propre et bien testé sur mes crossbuilds locaux, faudra que je sorte une v0.6 qui commencera à bien s'approcher d'un outil que je pense vraiment indispensable pour enfin se débarrasser de tous les scripts sales et non portables "par projet" que chacun fait dans son coin pour chaque cross-compilation.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Pour la cross-compilation, j'ai découvert depuis mon projet crossroad que c'est vraiment pas un problème du moment que tu fais du code ok et des Makefiles normaux (que ce soit autotools ou cmake), puis tu testes une cross-compilation régulièrement (avec crossroad, qui prend en charge justement autotools et cmake!) pour t'assurer que ça cross-compiles bien et corriger les éventuels accrocs.
Il m'est déjà arrivé de corriger des projets en un mini-patch qui n'avaient jamais même pensé que leur projet marcherait avec win32. C'est le cas par exemple de la bibliothèque GExiv2 (quand on s'est mis à utiliser Exiv2 et son wrapper GExiv2 pour GIMP, il fallait bien sûr que cela fonctionne sous Windows aussi). Ils utilisaient à l'époque un Makefile fait à la main, à l'ancienne. Je l'ai transposé en un Makefile.am + configure.ac tout à fait classiques. Je cross-compile. Pof! Ça marche! En un temps record, GExiv2 fut porté sous Windows (je pense même pas avoir eu à toucher une seule ligne de code). Les développeurs de cette bibliothèque m'ont dit qu'ils n'avaient jamais développé cette lib sur Windows, n'avaient jamais tenté de la compiler pour cette plateforme et ne s'étaient même pas dit que ce serait possible (puisqu'ils ne s'en préoccupaient pas depuis le début). C'est la magie des chaînes de compilation standards sous Linux (en tous cas, pour les 2 les plus répandus, autotools et cmake. Je n'ai jamais eu l'occasion d'en essayer d'autre dans un contexte de crossbuild).
Franchement, la cross-compilation, c'est pas un gros problème. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
…Et puis il fallait attendre le développement des négatifs en diapositive pour pouvoir projeter les images sur grand écran et voir si elles étaient bonnes ou ratées ! Et surtout il fallait demander explicitement au labo de ne pas couper la bande de diapositive après développement mais faire ça manuellement, auquel cas la machine du labo cherchait des zones claire pour identifier les vues, et ne voyant que des photos noires, coupait n’importe où… :p
Ah ça je sais pas. Je faisais jamais développer. On nous a enseigné à développer et tirer nous-même.
Bon par contre j’ai toujours vu le télescope de mon père avec un moteur… Et avec sa télécommande filaire il peut ralentir ou accélérer la rotation polaire pour ajuster le suivi des objets…
Oui enfin le moteur ne s'occupe en général que d'un axe (ou alors t'as un télescope très cher, j'imagine car j'ai pas vu de télescope amateur avec moteur sur tous les axes!), donc si y a une mise en station même minimement faussée, faut corriger. Ensuite clairement si tu fais des photos de 30 secs seulement, c'est clair que t'as pas à te fatiguer. Ça n'a pas le temps de se décaler même avec mise en station approximative.
Ceci dit, même sans moteur du tout, c'était très sympa de faire de super longue poses en tournant à la main progressivement pendant des dizaines de minutes. Il fait froid, c'est crevant, mais c'est gratifiant. Et puis si t'es avec des amis, tu peux toujours discuter et tu t'ennuies pas.
En fait oui les appareils sont plus sensibles à la lumière, et surtout on peut changer de sensibilité selon l’objet, donc on peut facilement faire la lune avec une faible sensibilité et une nébuleuse avec une plus haute sensibilité dans la même soirée.
Dans mes souvenirs, on montait jamais haut de toutes façons en sensibilité. Haute sensibilité à la lumière, ça signifie plus de grain, de bruit, etc.
Je vois que sur les schémas de l’Axiom il y a un petit ventilateur (je ne parles pas du gros ventilateur du prototype, mais du petit qui semble se placer juste au dessus à l’horizontal sur le boîtier sur l’Axiom Beta), c’est peut-être pour contrôler la chauffe du capteur puisque c’est destiné à de la vidéo ?
On n'est pas encore sûr si ce ventilateur sera vraiment nécessaire. Par contre il se peut que même s'il n'est pas nécessaire, cela améliore les caractéristiques du capteur, donc ça resterait utile. Le refroidissement a été prévu parce qu'il vaut mieux prévenir que guérir, mais il se peut qu'au final on se rende compte qu'il puisse être retiré. Aussi normalement le ventilateur et la cage du ventilateur pourra être retirée facilement dans le design prévu.
Je ne fais que retranscrire des choses qui ont été dites sur la liste de l'équipe y a environ 2 mois. Me demande pas plus de détails, j'en sais pas plus. :-)
Par contre, fabriquer un module pour placer et contrôler un Axiom sur le télescope, ça ça serait cool ! Et c’est typiquement le genre de cas où je veux bricoler pour les décennies à venir, et avoir le maximum de contrôle pour pouvoir construire sur l’acquis dans 20 ans.
Ben si l'Axiom se fait et qu'un jour, tu en viens là, tu partageras tes montages en OpenHardware, j'espère! :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
J’ai fait des photos cet été avec mon 5D3 sur le télescope de mon père (210mm de diamètre, ≈ 1300mm de focale, ≈ 6,5 d’ouverture), et pour les objets lointains comme Saturne, le simple mouvement de l’obturateur faisait bouger la photo (alors qu’il est très discret sur ce modèle). J’ai pourtant pris toutes les précautions : levée du miroir avant déclenchement, déclenchement télécommandé par radio… mais l’obturateur faisait suffisamment trembler l’appareil pour que ce soit gênant avec un objet aussi distant !
J'ai fait de l'astrophotographie. Bon c'était y a longtemps et en argentique. Déjà ça veut dire qu'on faisait des poses qui pouvait faire une heure ou plus (et pas toujours avec un moteur! Parfois on devait suivre à la main. Et encore même avec un moteur, faut régulièrement corriger en cas de mise en station imparfaite). Peut-être que cela a changé, j'imagine que les appareils numériques sont plus sensibles à la lumière et que les poses sont plus courtes, déjà, non?
En tous les cas, la solution pour ton problème est de cacher l'image le temps que la vibration de l'appareil se stabilise (tu peux mettre ton corps devant le tube du télescope, dans le noir complet et avec le réglage sur l'infini, c'est juste une absence de lumière donc ça ne gêne en rien). À l'époque, on n'avait pas de télécommande radio et y avait rien d'électronique dans les appareils, on avait un déclencheur filaire, entièrement mécanique (le "fil" appuyait physiquement sur le déclencheur!), donc c'était pire. Mais simplement boucher la vue marche très bien. La pellicule de prend pas de lumière pendant la vibration!
Et typiquement dans ce cas d’usage, j’imagine bien fabriquer un support pour un boîtier comme l’Axiom, avec une mise au point motorisée (déplacement du boîtier sur un rail et moteur pas à pas par exemple). En effet il est impossible de faire la mise au point manuellement sur un objet aussi lointain que Saturne, le fait de toucher le boîtier suffit à fausser la mise au point !
Sur des objets aussi lointain, tu mets pas constamment au point sur l'infini de toutes façons? Moi c'est le souvenir que j'en ai.
Sinon il existe un logiciel Libre très sympa pour contrôler un appareil photo numérique à travers la connexion USB. Ça s'appelle Entangle. Je sais que le mainteneur s'en sert notamment pour de l'astro-photographie lui-aussi d'ailleurs.
Avec ça tu peux contrôler la mise au point (et plein d'autres choses), avoir une prévisualisation de ta photo sur un écran plus grand que l'écran des appareils, puis prendre ta photo en cliquant juste "espace".
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Heureusement que tu précises que t'es pas énervé, parce qu'on pourrait croire le contraire :)
C'est pour ça que je précisais, je savais que ça pouvait en donner l'impression. :p
Mais (et ça n'est que mon avis), ça n'est pas parfait, et si je devais recommencer de 0 je changerais XML par autre chose. Encore une fois, expérience de pensée !
Ok, j'avais pas pigé cet aspect des choses. Continuons donc dans l'expérience de pensée.
Cas simple: je veux envoyer un message à edward@snowden.com; le seul qui sait comment faire c'est snowden.com. Je ne connais pas snowden.com, par contre mon serveur le connaît; j'envoie mon stanza à mon serveur qui transmet.
Mouais, mon serveur connaît pas plus. Il demande au DNS à quel IP ça correspond, puis ensuite il transmet aux protocoles du dessous (TCP/IP) qui vont s'occuper de tout le transport et routage. Je vois vraiment pas où le serveur a fait du routage là.
Cas MUC/Pubsub: c'est du multicast tout ce qu'il y a de plus connu. Ma ressource -> mon serveur -> le serveur qui héberge le service de pubsub -> le noeud pubsub
Ben… c'est exactement la même chose que ton cas simple: 2 serveurs et 2 entités finales. C'est aussi la même chose que SMTP (dans le cas habituel où on envoie pas l'email directement au serveur final, ce qui est faisable mais peut être flaggué comme spam rapidement).
Franchement c'est pas du routage ça, ton cas encore plus "compliqué" avec IRC non plus. Ou alors très vite fait un routage de super haut niveau, qui utilise en vrai un routage bien plus réel de bas niveau. Mais bon le même que l'ensemble des protocoles du net de nos jours. Et encore, c'est tiré par les cheveux. Enfin je vois vraiment pas où tu veux en venir.
Ah d'ailleurs je viens de me souvenir du terme. On va plutôt appeler cela du "relai" à ce niveau de protocole. De même que le protocole SMTP fait aussi du "relai" de messages électroniques.
Dans ce cas-là tu segmentes ton binaire, tu l'envoies morceau par morceau avec la possibilité pour les messages non-binaires de passer.
Moui, si tu as des milliers de ces petits morceaux (soit milliers de fichiers, soit un fichier si gros qu'il faut le couper beaucoup), ça va quand même boucher globalement la communication. Ensuite tu pourrais imaginer un système de priorité (réimplémenter un OS dans ton flux de données!) mais ça implique soudainement beaucoup plus de communication (le système de priorité ne peut pas être laissé au soin de l'envoyeur, sinon il fait ce qu'il veut et envoie toujours ses données en masse. Donc l'envoyeur attend que le destinataire lui donne le feu vert, cad lui envoie une requête "ok c'est bon, tu peux m'envoyer 2 paquets maintenant, mais pas plus"). Et puis ça va inutilement ralentir l'envoi du fichier par conséquent (déjà que les utilisateurs se plaignent que les chargements sont trop lents!) alors qu'on a des connexions de fous maintenant avec des bandes passantes suffisamment larges pour à la fois recevoir plein de données binaires et textuelles en parallèle sans percevoir le moindre ralentissement. Pourquoi faire compliqué, moins efficace, prône aux erreurs de protocole, d'implémentation hasardeuse et complexe, avec une sensation utilisateur "lente" à la fois pour l'envoi des binaires et le texte, etc. alors qu'on peut faire facile et efficace simplement avec deux flux parallèles (et on laisse l'OS gérer les I/O en simultané)? Je comprends même pas le but de la discussion. Ça apporte quoi que les données soient dans le flux? Je vois que des désavantages.
Bon c'est pas vrai: y en a qu'un seul d'avantage: si jamais on arrive pas à ouvrir un autre flux plus efficace (firewall, etc.), ben on n'a pas le choix. D'ailleurs je voudrais noter qu'il existe déjà depuis longtemps un tel transport binaire directement dans le flux, en base64, dans XMPP (transport "in-band" de Jingle). Mais franchement c'est à jamais utiliser si on a le choix de faire autrement (c'est d'ailleurs écrit clairement dans la XEP, c'est du "dernier recours" si on arrive pas à faire mieux). Proposer que ce genre de chose soit par défaut est d'après moi une aberration.
Parser, ça veut dire passer la suite d'octets reçus de la socket dans la moulinette pour en extraire une structure qui a du sens
Donc analyse des données (comme je disais, on peut donner plusieurs sens à "parser". Le serveur va effectivement lire tout le stanza pour la "syntaxe", car c'est un flux, mais pas pour le "sens" nécessairement).
Ok dans ce cas là, ça tombe bien, oui le serveur s'arrête au header du stanza: le to bien sûr, mais aussi le from (vérifier que le from correspond bien à ce qui a été envoyé, je rappelle que XMPP est un protocole sécurisé et authentifié, pas comme SMTP, et donc qu'un serveur ne se contente pas de relayer des messages, il en vérifie notamment la provenance, la syntaxe, etc.), et éventuellement un chouille plus si nécessaire (par exemple le type, l'id si y a une réponse à renvoyer, etc.). Mais oui pourquoi le serveur irait analyser ce qu'il y a dans le stanza (à part si serveur de la NSA qui cherche des infos!)? Bien sûr que non, il ne va pas en extraire une "structure qui a du sens". C'est d'autant plus vrai que dans beaucoup de cas, il ne pourrait même pas. Je rappelle que XMPP est fait de plein de fonctionnalités, libre à chaque entité de les implémenter. Si on envoie une donnée particulière destinée à un client final, qui gère une fonctionnalité donnée, le serveur peut tout à fait ne pas avoir d'implémentation pour la dite-fonctionnalité. D'ailleurs la plupart du temps, les serveurs n'implémenteront pas les mêmes fonctionnalités (ou pas les mêmes bouts de la fonctionnalité) que les clients car ça n'a pas de sens. Donc le serveur se contente de relayer.
Et donc ça tombe bien, le serveur s'arrête au "to", sans chercher "le sens de ce qu'il y a en dessous" qu'il ne comprendrait probablement même pas de toutes façons puisque c'est une XEP pour clients. Ça se passe exactement comme tu veux! Donc un argument qui tombe!
Encore une fois, je parle de ce qu'il y aurait à changer si on repartait de 0, mais c'est clairement du chipotage, et ça n'enlève en rien les qualités de XMPP.
Ok j'ai bien compris maintenant! ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Base64, l'un des principaux problèmes, c'est que ça augmente la taille d'un fichier d'environ le tiers. Donc déjà que les binaires peuvent être assez gros de nos jours (car souvent, ça implique des images, voire du son ou de la vidéo), ben là on envoie une version 1/3 plus grosse. C'est donc pas efficace.
La partie codage/décodage est très basique et n'est pas le problème. De nos jours, nos machines font plein d'autre codages beaucoup plus complexe sans qu'on s'en rende compte et en des temps tout à fait respectables. Note que d'autres choses peuvent augmenter la taille d'un fichier, par exemple si on chiffre la communication. Mais là c'est une perte de gain acceptée car ça a un intérêt (cacher les données). Par contre base64 n'a aucun autre intérêt que celui qu'on veut se forcer à passer par un canal texte pour transporter du binaire. D'ailleurs si on veut chiffrer tout en insérant notre fichier dans le canal texte, on chiffre d'abord puis on base64. Ça fait beaucoup d'overhead à la fin!
Non je pense vraiment que le vrai problème, c'est la taille, le temps que ça prend à charger, et par effet de bord, pour un flux de donnée, le fait que ça boucherait le tuyau.
Alors dans un email, c'est moins grave car ça n'a jamais été fait pour de l'instantané. Pour de l'instantané, je me demande comment cette équipe voit le mélange du binaire avec le reste. Ensuite j'ai pas lu du tout cette page. Je réponds juste à une pensée générale basé sur la seule phrase citée par devnewton. Peut-être qu'ils coupent le binaire en plein de petits bouts, comme rakoo dit plus haut, et mettent en place un système de priorité par exemple? Ou autre. Peut-être qu'ils ont d'autres idées intéressantes pour gérer cela. Ça devient super compliqué si tu pars dans ce genre d'idées ceci dit.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Comme écrit plus haut, je suis surtout intéressé par l’aspect « appareil photo libre et bidouillable » que « caméra libre et bidouillable », les images animées m’intéressent moins, mais vu les initiatives comme Magic Lantern et Nikon Hackers (j’utilise les deux), je me dis que je ne suis pas tout seul, il y a vraiment un marché. ;-)
Je suis certain d'avoir déjà lu quelque part (sur une voie de communication officielle) que cela était aussi une cible et pourrait être complètement une utilisation viable d'AXIOM (après tout, si on peut prendre 300 images par seconde, le matos est bien capable d'en prendre aussi une seule! :p). Bon je cherche pas parce que j'ai la flemme, mais je voulais quand même signaler que ce marché n'est pas totalement étranger à Apertus (même si clairement la cible et marché principaux sont bien le cinéma, en effet).
Ensuite si t'as pas l'argent, t'as pas l'argent. On peut rien y faire. Mais n'hésite pas à communiquer à qui pourrait! :-)
Ensuite pour ta remarque sur la réussite à lever les fonds, je peux confirmer qu'en interne aussi, c'est loin d'être considéré comme gagné et ceux qui sont les plus impliqués essaient vraiment de trouver les moyens de relancer la machine. Car eux aussi voient la possibilité de ne pas atteindre le but avec la courbe actuelle.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Contribution
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Modeste contribution à Audacity sur l'affichage des temps. Évalué à 5.
Très bien. :-)
Ensuite oui tu peux t'attendre à des rejets parfois (sur ce patch ou un autre), des incompréhensions, etc. Mais règle numéro 1: ne jamais le prendre mal, ni personnellement. Aussi il faut être prêt à revoir ton code.
Il n'y aussi aucun mal à insister un peu, mais toujours poliment et amicalement. Ça m'est déjà arrivé des fois d'avoir des patchs rejetés et le ticket fermé, et je le rouvre avec un commentaire expliquant davantage pourquoi j'estime que c'est important et que je suis prêt à modifier le patch pour m'adapter aux besoins et corriger les problèmes, des fois avec un nouveau patch si je sais déjà quel problème ont les dévs upstream avec mon premier patch. Et des fois, ça marche et ils acceptent l'idée évoluée.
Par exemple dans ton cas, peut-être qu'ils te diront effectivement qu'il faut une nouvelle option. Dans ce cas, tu dis que tu vas rééecrire sous la forme d'une nouvelle option. Peut-être qu'ils te diront que la liste des options est trop longue. Dans ce cas, dirige les vers le lien du forum avec le gars qui pense qu'il faut plein d'options, et tu peux aussi dire que tu as eu des retours d'utilisateurs qui ont dit que ton option particulière serait très utile, cela peut créer une discussion pour revoir la façon dont cette liste est présentée (comme je disais, je vois très bien un système de format pour que tout un chacun puisse créer son timing personnalisé).
Si on te répond pas vite, faut pas prendre mal, tu peux d'ailleurs te permettre de relancer de temps en temps (pas trop, attend quelques semaines entre les relances). Ça veut aussi dire que de ton côté aussi, rien ne presse. Personne ne t'en voudra si tu mets un peu de temps à répondre, et tu peux prendre tout le temps nécessaire pour rechercher le code et écrire proprement tes nouvelles versions de patch.
Au final la contribution au Logiciel Libre, c'est un peu une leçon de zen. Il faut essayer de jamais s'énerver (des fois, c'est dur), de ne rien prendre personnellement, de prendre son temps et être persistant en même temps. Et un jour, tu te rends compte que tout va bien en fait. Ces mecs en face, ils sont comme toi. Ils n'avaient rien contre toi ni ta fonctionnalité, ils avaient juste du mal à la comprendre.
Tout cela dit, peut-être au contraire que ta fonctionnalité va leur plaire et qu'ils l'accepteront d'entrée de jeu sans aucun problème. Je veux juste te préparer au "pire" parce que je sais que les premiers patchs rejetés peuvent être démoralisants quand on ne connaît pas encore. Ça peut arriver. Mais si t'es sûr de ton idée, hésite pas à revenir à la charge en proposant des alternatives. Des fois même après un an ou 2 s'il le faut, il arrive que les dévs revoient leur jugement (et en attendant, tu utilises ta version patchée juste pour toi).
Ou alors si tu te mets à proposer d'autres patchs régulièrement, tu deviendras peut-être toi-même core dév d'Audacity, et dans ce cas tu auras plus de poids pour reproposer ta modif plus tard. :-)
Tout est question de patience.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Contribution
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Modeste contribution à Audacity sur l'affichage des temps. Évalué à 10.
Je suis d'accord avec gasche. Je suis de nombreuses mailing list, mais "de très haut", c'est à dire que de temps en temps, je jette un œil et vais répondre à 3/4 messages dans les derniers messages, ceux qui m'ont l'air le plus pertinent. Mais je sais que j'en aurai passé plein. Ce n'est pas grave, c'est le format des mailing lists (et les forums, c'est pareil): des discussions qui passent, s'éteignent, puis à un moment disparaissent dans des archives. D'ailleurs il m'est aussi arrivé très souvent de commencer une discussion à laquelle personne ne répond jamais et elle passe dans l'oubli. Je ne m'offusque pas. C'est le format attendu, comme j'ai dit.
Les outils de suivi, c'est un format totalement différent: un ticket ouvert y a 10 ans, mais que personne n'aura trouvé irraisonnable (mais qui n'a pas eu de résolution dans le code pour autant) sera encore en haut de la liste 10 ans après. Une entrée de suivi n'est oubliée que le jour où on décide soit que c'est une fonctionnalité inutile, soit qu'il y a une résolution (= patch).
Ensuite il y a des projets qui privilégient forums/mailing lists comme lieu de décision, et là c'est différent. Mais ça reste l'exception.
Soit dit en passant, j'ai jeté un œil au fil de discussion que tu donnes (au passage, le bon lien est: http://forum.audacityteam.org/viewtopic.php?f=20&t=82163 L'option finale du lien que tu as donné semble vouloir me forcer à entrer un login). J'ai l'impression qu'aucun des dévs ne t'a répondu, celui qui semble répondre le plus, Edgar, ayant l'air extérieur à l'équipe core d'après les termes qu'il choisit. À le lire, il semblerait qu'il ait lui-même des patchs perso et n'a jamais fait l'effort de les proposer.
Donc je vois pas quel enseignement tu peux en tirer, et surtout comment tu aies pu comprendre quoi que ce soit de "l'envers du décor". Tu restes du côté spectateur. Encore une fois, tu n'obtiens que des "on dit". C'est donc surtout du vent.
À un moment donné, il faut passer dans la cour des grands. Et c'est comme à l'école: une fois que tu y es passé, tu te rends compte que les "grands" ne sont pas différents des "petits" et qu'il n'y avait en fait aucune raison d'avoir peur. Les autres grands (car tu en es devenu un aussi à ce moment là) sont les mêmes, ils ont simplement changé de cour. Donc laisse tomber les "on dit", et essaie de soumettre ton patch plutôt que d'écouter un mec qui vraisemblablement n'a jamais essayé de changer de cour, même s'il avait les bonnes billes pour le faire.
Une fois que tu auras vraiment discuté avec les dévs, acteurs d'Audacity, là tu auras un aperçu de "l'envers du décor".
Au passage, vous pointez dans le fil de discussion la problématique de la longueur du menu quand on ajoute trop d'options. Voilà une bonne problématique en effet. Il n'est proposé qu'un dialogue comme seule alternative. Mais il y a mieux en fait: personnalisation totale du format. Par exemple, une liste assez limitée peut être donnée, mais avec la possibilité de personnaliser exactement le contenu avec une syntaxe custom. Par exemple il est classique d'utiliser une syntaxe dérivée du format de printf. Par exemple %h %m %s pour heure/minute/secondes. %S pour seconde avec décimales (donc on a les ms derrière la virgule), %M pour millisecondes, %f pour les frames en 24fps, etc. Donc l'utilisateur entre le format qu'il souhaite, il peut même avoir un mix de pleins d'infos en même temps s'il le souhaite, pourquoi pas!
Ce type de personnalisation permet simplicité (avec une liste de petite taille des usages les plus courants) + usage avancé (avec un format pour obtenir exactement ce que tu souhaites en tant qu'utilisateur avancé).
Peut-être peux-tu leur proposer quelque chose dans ce sens s'ils refusent ta première version de patch. Mais dans tous les cas, même là on s'avance trop. Dans un premier temps, envoie ton patch et parle avec les intéressés! Plus de "on dit", plus de "et si".
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Contribution
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Modeste contribution à Audacity sur l'affichage des temps. Évalué à 10.
Ceci dit, la première chose à faire est d'en parler avec les développeurs d'Audacity. Tu (pas cosmocat, mais Xavier, l'auteur de la dépêche) sembles te baser entièrement sur une supposition pour ne même pas proposer un patch et t'imaginer qu'il sera rejeté de toutes façons. Alors oui il est tout à fait possible que des choses soient à revoir (ça arrive à tout le monde, dans tous les projets). Peut-être même qu'ils refuseront de but en blanc l'idée même du patch, qui sait! (je connais pas l'équipe d'Audacity ni s'ils sont arrangeants, ou braqués par exemple)
Mais tout ça t'en sauras rien si tu demandes pas. Va y humblement et diplomatiquement avec ton patch, et sois prêt à recevoir les critiques (s'il y a lieu, ça se trouve, ils le trouveront même bien tel quel, qui sait!) et améliorer le patch en conséquence. Et cela ira probablement.
Ceci dit, petit avis perso: ajouter des millisecondes ne me semble pas contredire le nom de la fonction "secondes" à ce point selon moi. Les millisecondes sont une variante (ou une subdvision) de l'unité seconde. Je ne vois pas de contradiction.
Mais peut-être que les dévs d'Audacity verront les choses autrement, j'en sais rien. Et dans ce cas là, ajouter une option peut en effet être une autre possibilité (ou encore changer le nom de la fonction). Et franchement je vois déjà une dizaine d'option pour l'affichage du temps, je doute que les dévs upstream aient un gros problème si tu souhaites en ajouter une avec une bonne raison (et tu en as une). Mais cela, je te conseille de voir cela directement avec les dévs du projet. Pas la peine de perdre ton temps pour du code qui sera pas pris.
Perso ma manière de travailler est la suivante quand je veux une fonctionnalité: je fais la base dans mon coin, car ça me sert de "preuve de concept", donc ça illustre bien mieux ce que je veux que du texte dans une requête de fonctionnalité, et surtout les dévs du projet me tiennent au sérieux dès le début car ils ont un patch à se mettre sous la dent et donc ils répondent beaucoup plus vite. Ça c'est ce que t'as fait et c'est très bien.
La seconde étape est de proposer ton patch de base une fois qu'il est un peu propre. Et à partir de là, la discussion avec upstream peut commencer et c'est le moment où tu fignoles, et où tu auras peut-être des concessions à faire en effet, ou bien du code à ajouter ou changer pour aller dans le sens du projet tout en intégrant ta nouvelle fonctionnalité intégralement.
Et quand c'est fait, le projet upstream est content et intègre ton patch. En général les projets sont contents d'avoir de nouvelles contributions. Ils espèrent même que les contributeurs restent et proposent plus de patchs à l'avenir. Faut pas croire mais la plupart des projets (même certains qui ont l'air gros, car connus à une certaine échelle) ont très peu de contributeurs. Je pense donc que tu as toutes tes chances.
Reste pas là sur linuxfr à piétiner et à te demander si oui ou non ils intègreront. Va direct sur leur logiciel de suivi, et donne ton patch. S'ils répondent pas vite, n'hésite pas à lancer un petit message sur la mailing list par exemple (ou autre de leurs canaux habituels de discussion, par exemple s'ils ont IRC), poliment et gentillement (genre "hey I submitted a patch a few days ago, would someone be kind enough to review it? I'm happy to change things if there are issues", un lien et quelques petits smileys bien placés). Et tout ira bien.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: VLC, what else !
Posté par Jehan (site web personnel, Mastodon) . En réponse au message Logiciel de Streaming vidéo en direct. Évalué à 2.
Salut,
Ok je vois, mais ça c'est du bidouillage. C'est acceptable si j'en ai besoin une fois et veut une solution un peu tarabiscotée mais rapide et sans me prendre la tête à chercher une vraie bonne solution de long terme. Si je vais dans ce sens là, je peux même faire encore plus simple: je n'ai pas besoin du VLC intermédiaire, je peux juste rediriger le flux directement du serveur vers le PC source.
Mais ça ne tient pas la distance: le PC source peut changer d'IP déjà parce que ma connexion n'a pas d'IP fixe contractuellement (même si dans les faits elle l'est habituellement); mais surtout quid si je me connecte depuis ailleurs? Et/ou avec un autre PC? Je dois à chaque fois refaire une manœuvre complexe? Et puis de nos jours, les foyers sont en général derrière un routeur, donc je dois rediriger les ports si je souhaite que le serveur puisse se connecter sur le PC source (puisque lui-même devenu serveur en attente de connexions). C'est possible (mais chiant) quand c'est chez moi et impossible si je souhaite me connecter depuis un réseau sur lequel je n'ai pas la main. Et même chez moi, je dois refaire la manœuvre si je souhaite utiliser un autre PC source.
Sans compter tous les problèmes de sécurité que l'on peut rencontrer dans ce genre de bidouillage où un serveur voudrait lire des données depuis une autre machine à travers le net sans aucune identification de la source ni sécurisation (c'est acceptable depuis un réseau local totalement sous contrôle uniquement).
En gros c'est pas du tout ce que je cherche. Ça je pouvais déjà bidouiller un système encore plus simplement avant de demander. Ce que je cherche, c'est une solution propre pour du long terme. C'est pour ça que je demande ce qu'il existe en solution existante et bien pensée. J'ai un serveur, il a une IP fixe accessible sur le net, et sans bidouillage à faire. Je veux juste lui installer un service maison de streaming, que j'associerai à un sous-domaine de mon domaine principal, de sorte qu'avec les logiciels adéquats, je suis capable de me connecter quand je veux en tant que "client source", depuis n'importe quel ordi et depuis n'importe où avec le login adéquat, et je peux donner une URI à des gens divers et variés sur le net pour que ces derniers puissent se connecter sur le serveur et y regarder ma vidéo en live (ces derniers n'ayant en général pas besoin de login par contre, bien qu'on puisse s'imaginer que des fois on veuille aussi limiter qui peut voir).
La solution BigBlueButton qui a été donné plus haut correspond bien plus (du peu que je peux lire). Et probablement IceCast aussi. Probablement FreeSee aussi. Maintenant je suis intéressé s'il existe d'autres solutions similaires et surtout par des retours d'expérience, et/ou des comparaisons de ces solutions.
Merci.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: VLC, what else !
Posté par Jehan (site web personnel, Mastodon) . En réponse au message Logiciel de Streaming vidéo en direct. Évalué à 2.
Oui mais c'est ce que je dis! VLC avec streaming HTTP, c'est pour la partie serveur. Là, ok on est d'accord. Mais il doit bien récupérer le stream du desktop d'une façon ou d'une autre (qui ne vient pas de la mēme machine, mais d'une autre). Soit c'est un fichier, et dans ce cas là, c'est plus du live; soit il existe un protocole qui connecte 2 VLC, celui du desktop qui sert de source (en enregistrant le bureau) et celui du serveur qui écoute sur un port et une IP donnée.
Dans les autres propositions, le streaming sur WMP ne me convient pas (je ne compte pas me limiter à un logiciel Windows seulement). On est sur linuxfr après tout! ;-)
RTP et UDP, c'est pour diffuser vers des addresses données (unicast/multicast).
Seul IceCast dans la liste semble correspondre au besoin, mais on n'est plus dans le cas "2 VLC" qu'on m'a présenté, mais dans celui plus classique VLC source + IceCast serveur que je connaissais déjà.
Donc j'essaie de comprendre ce cas "2 VLC" que vous me présentez comme répondant à ma problématique et qui n'est pas présenté dans cette liste.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: VLC, what else !
Posté par Jehan (site web personnel, Mastodon) . En réponse au message Logiciel de Streaming vidéo en direct. Évalué à 3. Dernière modification le 15 novembre 2014 à 23:53.
Je pense qu'il y a incompréhension. J'ai bien entendu lu le lien qui m'a été donné. Les méthodes de streaming sont: "affichage local", "fichier", "envoi vers Microsoft Windows Media Player" qui ne correspondent pas au problème; HTTP, qui si je comprends bien permet de streamer directement comme un serveur HTTP, et donc serait parfait si le serveur source et le serveur de streaming étaient la même machine (c'est la méthode que les gens semblent proposer avec vlc-nox — qui n'est qu'un VLC normal sans rien de particulier, hormis qu'il ne repose pas sur X — quand on veut faire un serveur de streaming media pour lequel on a déjà des fichiers en local), mais ce n'est pas mon cas d'usage; UDP et RDP dont je ne suis pas sûr mais c'est apparemment pour du unicast/multicast; et enfin IceCast dont je parle plus haut.
Vous semblez tous les deux dire qu'il y a apparemment un autre moyen en connectant 2 instances de VLC sur deux machines différentes, l'un servant de sources, l'autre de serveur de serveur de stream. Je veux bien vous croire, mais je ne trouve aucune information à ce sujet nulle part, et le lien donné ne parle pas de cette possibilité additionnelle. Donc je demande si vous avez des liens qui expliqueraient une telle chose (aussi, il va sans dire, mais j'attends une solution un minimum sécurisée. Je veux pas ouvrir un port qui accepte n'importe quelle source sans login, clé ou autre type d'identification car mon cas d'usage passe par le net, non au travers d'un réseau interne).
Edit: pour être plus clair, VLC permet en effet de streamer du desktop. Là n'est pas la question. Mais le serveur (la machine qui va gérer la partie streaming) n'a pas de desktop par définition. Il doit donc recevoir le média généré par un autre ordinateur. Il doit donc y avoir un protocole entre la machine "source" et la machine "streaming". Je n'ai pas l'impression que VLC puisse gérer un tel transport de média d'un VLC à l'autre. Ou du moins je trouve pas, et le lien donné n'indique pas cela. Donc je veux bien avoir d'autres liens si une telle chose existe.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: VLC, what else !
Posté par Jehan (site web personnel, Mastodon) . En réponse au message Logiciel de Streaming vidéo en direct. Évalué à 2.
Oh ok, vlc est donc capable d'envoyer un stream directement à l'instance distante de vlc-nox pour que celle-ci puisse le redistribuer? J'arrive pas à trouver de doc qui explique cela. Je ne trouve que des docs qui explique comment streamer des fichiers existants. Vous auriez des liens?
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: un autre produit : big blue button
Posté par Jehan (site web personnel, Mastodon) . En réponse au message Logiciel de Streaming vidéo en direct. Évalué à 2.
Ça a l'air sympa. J'y jetterai un œil un peu plus poussé. Merci.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: VLC, what else !
Posté par Jehan (site web personnel, Mastodon) . En réponse au message Logiciel de Streaming vidéo en direct. Évalué à 3.
Salut. Oui ça c'est pour le client source, mais dans le contexte d'un streaming pour que des gens hors du réseau puissent se connecter, hormis le cas où le client est aussi serveur http par exemple (cas simple d'un fichier déjà enregistré), il faudra encore un serveur icecast (je vois qu'y a une prise en charge d'icecast dans VLC en effet). Donc en gros, tu conseilles Icecast en tant que serveur et VLC en tant que client?
Mais puisque je vois que tu conseilles vlc-nox comme serveur de streaming, alors je me dis que tu conseilles peut-être plutôt d'encoder dans un fichier avec VLC sur le bureau, puis d'envoyer le fichier sur le serveur, puis là d'utiliser vlc-nox. Ce n'est donc plus du live mais du différé.
Ou alors j'ai pas compris une autre possibilité? Je rappelle que je veux pouvoir enregistrer et streamer en direct en passant par un serveur, car le client source d'enregistrement (un ordi pour utilisation desktop) enregistre mais n'est pas celui qui streame.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Personne pour lancer le troll?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Joker, un logiciel pour doubler des films sous licence GPL. Évalué à 4.
Oui en effet, mais faut peut-être voir cela comme un tout. Plutôt que de se dire ce qui est majeur ou mineur, on peut voir le fait que dans le même pays où les gens sont très bon en anglais et comme par hasard le fait qu'ils aient une culture des films en VO non pas comme une coïncidence, non pas comme un lien de cause à effet, mais avec une relation tout de même. C'est un pays qui embrasse globalement une approche de la langue étrangère plus intensément.
En France, on a cette culture du tout VF, et ça correspond peut-être avec notre approche des langues étrangères au second plan et notre système scolaire non adapté probablement. Aux US, eux j'ai l'impression qu'ils s'intéressent très peu aux films étrangers tout court (donc ils ont même pas tellement besoin de doublage, du moins pas aussi souvent), et ça correspond au fait qu'ils s'intéressent assez peu aux langues étrangères aussi scolairement (ils en apprennent, mais le résultat paraît globalement pire qu'en France), semblerait-il.
En gros, ce sont plein de petites choses qui font un tout. Chercher un élément particulier avec un "rôle majeur" est probablement une erreur, selon moi. Effectivement passer tous les films en VO à la télé ne rendra pas soudainement la population française bilingue si on ne fait que cela. Mais ça y aidera si on l'additionne à d'autres "petites choses".
Le fait qu'on soit un peu au tout VF dans notre pays est donc symptomatique, plus qu'une cause "majeur".
Bon ensuite c'est juste une petite pensée comme ça. Je n'ai pas vraiment d'avis plus poussé sur le sujet et n'y ai jamais réfléchi intensément. C'est clairement pas un de mes chevaux de bataille. :-)
Je pense donc finir cette discussion sur cette mini réflexion, qui est peut-être totalement fausse, qui sait, et dans tous les cas très certainement superficielle!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Personne pour lancer le troll?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Joker, un logiciel pour doubler des films sous licence GPL. Évalué à 10. Dernière modification le 08 novembre 2014 à 19:33.
Ben oui je parle aussi pas mal anglais dans diverses situations depuis des années (j'ai vagabondé pas mal, j'ai aussi vécu au Japon 2 ans et 1 an en Corée, et travaillait alors pour une boîte US, puis j'ai vécu 1 an en Nouvelle Zélande), et au Danemark aussi je parlais souvent anglais (j'avais pris des cours de danois, mais c'était dur d'en placer une, on me répondait en anglais dès qu'on comprenait que j'étais étranger). Aussi je suis développeur sur pas mal de projets Libres, donc ma langue principale sur le net, c'est l'anglais. J'ai jamais dit le contraire. Et je dis pas non plus que regarder des films en VO est une solution miracle (je dis même le contraire avec la blague de "l'anglais en 3 leçons").
Ce que je dis, c'est que la VO aide. Mais bien entendu, rien ne replace la discussion en vrai avec des gens qui parlent anglais. Ça me paraît tellement évident que ça me fait de la peine de devoir le préciser!
Et je ne dis rien non plus sur l'enseignement à l'école et quel est le meilleur modèle, etc. Je ne dis pas non plus que regarder des films en VO remplace l'école ou la vraie discussion d'ailleurs. Non c'est juste très complémentaire.
De manière générale, regarder des films en anglais, ça peut apporter pas mal de vocabulaire que tu n'auras pas forcément, même en vivant aux US/UK ou en parlant avec des anglophones régulièrement, tout simplement parce que chaque personne prend l'habitude d'utiliser son propre vocabulaire assez limité. Et puis dans les films, ils aiment bien créer des personnages un peu extrêmes qui parlent avec des tournures particulières. De la même façon qu'en regardant des films (ou lisant des livres) en français, j'apprends des fois des mots, ou réapprends des mots que j'avais presque oubliés (et ce, même si je parle français depuis la naissance). L'apport en vocabulaire s'applique aux médias vidéos (films, etc.) comme à la lecture (livres, etc.).
Ensuite ce que les films apportent et qu'on n'a pas dans la lecture, c'est le son, c'est à dire l'entraînement de la compréhension orale. Et ça tu ne l'as pas autant dans tes cours scolaires non plus, car le temps est plus limité (puisque les films, tu les regardes en général dans ton temps libre), mais surtout tu vas surtout parler avec des gens de ton niveau, ce qui n'est pas du tout la même chose.
De manière générale, beaucoup de gens ont ce niveau "intermédiaire" en France qui est qu'ils peuvent très convenablement s'exprimer en anglais acceptable (voire parfois très bon grammaticalement et en vocabulaire), mais que dès que quelqu'un leur parle avec un accent inhabituel, ou très vite, ou dans une grande salle avec un écho et du bruit et des gens qui parlent à côté, etc. ben ils sont paumés. Ben pour ça, rien ne vaut la pratique d'entendre de l'anglais. On peut le faire en vivant dans un pays anglophone, mais même là, cela reste limité car on entend en général des accents similaires selon son activité. Par contre les films apportent souvent une variété. La première fois que j'ai vu Snatch, je pensais devenir fou tellement certains persos sont incompréhensibles (et je faisais constamment retour arrière pour essayer de comprendre certains textes). Mais après avoir vu des dizaines de films de ce genre, soudain on se rend compte qu'on comprend un truc qu'on comprenait pas il y a peu. Avec un film, tu travailles la compréhension, reconnaître les accents (ça a l'air évident après coup, mais quand on débute, on ne reconnaît aucun accent. J'ai une amie qui débute en français et quand elle entend un accent très fort d'une autre région de la France, elle fait pas non plus de différence), etc.
Ensuite oui, rien ne remplace de dialoguer en anglais régulièrement. Et juste regarder des films en VO n'est pas suffisant pour parler anglais (d'ailleurs on ne parle pas, on écoute). Ça me paraît évident. Ça n'en enlève pas les apports des films.
De même, ce n'est pas un passage obligé. Il y a aussi d'autres moyens pour en arriver au même résultat (parler avec beaucoup de gens différents par exemple afin de capter la même diversité qu'on a dans les films sans bouger de sa chaise).
Enfin voilà, je sais pas pourquoi tu te braques et sembles vouloir absolument prouver coûte que coûte que regarder la VO ne sert absolument à rien.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Personne pour lancer le troll?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Joker, un logiciel pour doubler des films sous licence GPL. Évalué à 7.
Le cliché, c'est que les gens parlent tous bien anglais au Danemark ou c'est que regarder des films en VO aide beaucoup à la langue?
Parce que pour le premier, ben écoute, j'ai vécu un an au Danemark (pas à la capitale, mais à Ålborg, au nord). Je suis pas resté cloîtré h24 chez moi. J'allais aussi au supermarchés: les caissières parlent anglais parfaitement. J'allais dans des bars paumés: tout le monde, jusqu'à l'ivrogne sdf parle en anglais. J'ai traversé le pays entier en auto-stop, etc. En un an, je suis tombé que sur un gars qui ne parlait pas (ou ne voulait pas) anglais. Donc je dis pas que j'ai rencontré tous les danois, mais quand même. C'est loin d'un cliché.
Si c'est le second: je vais pas prétendre posséder la méthode ultime pour l'anglais, mais c'est justement lors de mon séjour au Danemark que je me suis mis à regarder tous mes films en VO sans sous-titre. Le "sans sous-titre" est probablement la clé. Comme je disais plus haut, les yeux sont attirés par les sous-titres et même quand on comprend, on va lire. Ça m'arrive même si je regarde un film en français avec sous-titre, pour dire! C'est même pire que tout car des fois, les sous-titres ne sont pas bien traduits, ce qui perturbe carrément le cerveau entre ce qu'on entend et lit.
Ben depuis lors, mon anglais a énormément progressé. Bien sûr ce n'est pas la seule raison, loin de là, et je vais pas prétendre que je sais à quel point ça joue (d'ailleurs pour ça que j'ai dit "très probablement"). Alors je me plante peut-être, mais en mon for intérieur, je pense que ça aide quand même pas mal.
Ensuite je le répète: même si regarder en vo sous-titré aide probablement aussi à mon avis, passer au VO tout court (sans sous-titre), là tu peux que progresser (d'après mon expérience perso, encore une fois, c'est pas une méthode "telle langue en 3 leçons"). Y a un monde entre les deux. Tu te concentres bien plus sur ce que les acteurs disent, et quand tu comprends pas, ton imagination gambade beaucoup plus pour essayer de deviner après coup ce qu'ils ont dit (car oui, selon moi l'imagination et essayer de "deviner" est extrêmement important dans l'apprentissage d'une langue pour la compréhension orale et l'appréhension des sons. Avec les sous-titres, on perd pas mal de cette partie là).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Personne pour lancer le troll?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Joker, un logiciel pour doubler des films sous licence GPL. Évalué à 9.
Je pense que vous avez tous les deux raisons.
Perso je regarde en anglais sans sous-titre. Comme tu dis, les sous-titres sont une forme de "pollution visuelle", et surtout ça attire l'œil. Je me retrouve à lire les sous-titres quand y en a, même quand je comprends parfaitement la langue, et c'est très inconfortable.
Cependant même quand je comprends pas une langue (ou pas suffisamment pour être confortable à l'écoute), je préfère la VO avec sous-titres à la VF. Le fait est que la langue véhicule d'autres choses en plus du sens, culturelles notamment. Va écouter un film en Japonais. Le timing, les intonations, les accroches sont totalement différentes et c'est pas ou difficilement transférable (sans compter les multiples "sons", sans traduction, très typique du Japonais que les gens ne feront jamais en français). L'image même rend totalement différente quand on l'entend avec la VO et la VF dans ce genre de cas.
Peut-être ensuite que les gens qui ne sont pas du tout intéressés par les langues étrangères ne sont pas très sensibles à ce genre de "tics" culturels, et ne les remarquent pas vraiment en VO?
Mais je suis d'accord que le doublage peut aussi s'adresser à une autre catégorie: ceux qui ne lisent pas suffisamment vite, ou qui ne parle aucune langue étrangère (et sont donc bien moins réceptif à ces dernières de manière générale).
Aussi beaucoup de dessins animés passeront plutôt bien en doublage. Et c'est vrai que pour les gosses, leur imposer de la VO peut être rude (quoique d'autres diront que ça leur enseigne la langue. Par exemple dans certains pays, notamment nordique, presque tout reste en VO. Et ça participe très probablement au fait qu'au Danemark par exemple, où j'ai vécu un an, les gens parlent tous anglais parfaitement).
En conclusion, je suis pas contre le doublage, mais je pense qu'on en a quand même trop en France (mais t'es dans le business, forcément tu vas pas être d'accord, je le comprends bien! :p). Et pourtant j'ai moi-même été doubleur pendant de nombreuses années.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Je voulais justement faire ce même logiciel!
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Joker, un logiciel pour doubler des films sous licence GPL. Évalué à 10. Dernière modification le 07 novembre 2014 à 16:13.
Je lui ai pas reproché d'utiliser un protocole proprio. Je lui ai dit que ce serait cool d'avoir aussi une prise en charge du protocole qu'on utilise habituellement sous Linux et lui ai demandé s'il avait un projet dans ce sens. Faut arrêter de vouloir à chaque fois prendre les gens à revers.
C'est le dernier message que je t'adresse dans ce fil, Zenitram, car je sais que sinon tu vas essayer de faire partir la discussion dans tous les sens en présupposant sur ce que j'ai voulu dire en sous-entendu dans mon message. Zenitram, le troll ultime.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Je voulais justement faire ce même logiciel!
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Joker, un logiciel pour doubler des films sous licence GPL. Évalué à 6.
J'ai lu un peu plus en détail et je lis "Sony 9 pin protocol, a serial cable and a video reference signal, our product synchronizes with audio recording software (Protools, Cubase, etc.)."
Moi dans le workflow évidémment tout-Libre que je souhaiterais développer, mon idée était plutôt de se synchroniser avec des logiciels comme Ardour, pas des logiciels proprio. Le protocol de synchro serait probablement Jack sous Linux. T'as des projets dans ce sens?
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Je voulais justement faire ce même logiciel!
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Joker, un logiciel pour doubler des films sous licence GPL. Évalué à 5.
Salut,
Cela fait des années que je souhaitais justement faire ce logiciel (pas "celui ci" en particulier, mais un logiciel de doublage quoi). Mais j'attendais d'en avoir vraiment l'utilité (bientôt, j'espère).
J'ai aussi une dizaine d'années d'expérience, mais probablement de l'autre côté du micro (j'imagine que tu étais ingé son?).
Je vais regarder les détails quand j'aurais un peu de temps pour faire un système de build pour Linux. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Bande d'amateurs…
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Calendrier du Libre 2015. Évalué à 3.
Oui, en fait si vraiment y a pas assez de vente (genre du tout), on pourrait annuler (paypal permet de faire un remboursement dans les 60 jours). Ceci dit, avec les tarifs les plus raisonnables d'imprimeurs numériques (pour de l'offset, c'est si on fait au moins 100 voire 200 que ça devient plus avantageux), on peut payer les frais avec tout juste une vingtaine de calendriers apparemment, donc je ne pense pas que cela arrivera. Si cela arrivait, ce serait pas un succès clairement, mais donc au moins l'association n'y sera pas "de sa poche", ou pas trop. Ensuite c'est sûr, y a du temps perdu, mais c'est une expérience qui pourra servir. Donc de ce point de vue là, c'est pas réellement "perdu".
En fait je vois cela sous divers angles: déjà pour aider le Logiciel Libre, ensuite pour promouvoir l'Art Libre, mais aussi pour voir ce qui intéresse les gens sans trop de risques (parce que les "études de marché" dont nous parlent les banquiers, franchement c'est souvent bidon). Si certaines choses de cette sorte fonctionne, ça ou des posters, ou quelque chose d'autre, ben on en fera peut-être d'autre plus régulièrement. C'est donc un peu de l'expérimentation libriste.
Pour l'asso, clairement l'idée est que si on trouve quelque chose qui intéresse les gens et qui puisse nous aider à financer au moins partiellement certains de nos frais, c'est aussi un des buts. Ça nous permettrait de nous concentrer sur nos projets plus sérieux (comme faire des films d'animation par exemple). Donc ce sont des expérimentations aussi dans ce sens.
Pour les affiches, j'y ai pensé aussi d'ailleurs. Ça peut être sympa en effet.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Bande d'amateurs…
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Calendrier du Libre 2015. Évalué à 3.
Ahahahaha. Oui j'avais oublié que la poste vend aussi ses calendriers.
Ceci dit, les pompiers sont passés chez nous y a quelques mois et ils demandaient juste de l'argent (y avait rien en échange). Enfin si, ils donnaient une facture si tu avais besoin, ce qui est encore moins moins glamour, même que les calendriers de chat ou de manchots. Je sais pas s'il faut s'attendre à les voir revenir encore, cette fois avec un calendrier "power-ranger", ou si c'est tout pour l'année. Peut-être que je suis d'une autre époque et que les calendriers c'est trop has-been? Avec toutes mes années à l'étranger, je suis devenu à la ramasse, maintenant on vend des apps, plus du papier. :P
Sinon les éboueurs sont passés, et eux laissent… un petit papier cartonné A6 avec toute l'année dessus avec une seule photo moche en minuscule dans un coin (ils savent que les gens payent de toutes façons, plus besoin de se faire chier à trouver de belles images et à faire un grand format?), en guise de calendrier que j'ai jeté direct après avoir payé la dîme. Les calendriers, des temps révolus!
Mais j'espère quand même que vous voudrez le notre! C'est pour la bonne cause! :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Cross-compilation
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Retour aux sources. Évalué à 2.
N'hésite pas à me tenir au courant sur comment ça se passe.
Aussi j'ai déjà plusieurs évolutions sur ma copie locale. Dès que j'aurai un peu tout mis au propre et bien testé sur mes crossbuilds locaux, faudra que je sorte une v0.6 qui commencera à bien s'approcher d'un outil que je pense vraiment indispensable pour enfin se débarrasser de tous les scripts sales et non portables "par projet" que chacun fait dans son coin pour chaque cross-compilation.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Cross-compilation
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Retour aux sources. Évalué à 10. Dernière modification le 26 septembre 2014 à 11:13.
Salut,
Pour la cross-compilation, j'ai découvert depuis mon projet crossroad que c'est vraiment pas un problème du moment que tu fais du code ok et des Makefiles normaux (que ce soit autotools ou cmake), puis tu testes une cross-compilation régulièrement (avec crossroad, qui prend en charge justement autotools et cmake!) pour t'assurer que ça cross-compiles bien et corriger les éventuels accrocs.
Il m'est déjà arrivé de corriger des projets en un mini-patch qui n'avaient jamais même pensé que leur projet marcherait avec win32. C'est le cas par exemple de la bibliothèque GExiv2 (quand on s'est mis à utiliser Exiv2 et son wrapper GExiv2 pour GIMP, il fallait bien sûr que cela fonctionne sous Windows aussi). Ils utilisaient à l'époque un Makefile fait à la main, à l'ancienne. Je l'ai transposé en un Makefile.am + configure.ac tout à fait classiques. Je cross-compile. Pof! Ça marche! En un temps record, GExiv2 fut porté sous Windows (je pense même pas avoir eu à toucher une seule ligne de code). Les développeurs de cette bibliothèque m'ont dit qu'ils n'avaient jamais développé cette lib sur Windows, n'avaient jamais tenté de la compiler pour cette plateforme et ne s'étaient même pas dit que ce serait possible (puisqu'ils ne s'en préoccupaient pas depuis le début). C'est la magie des chaînes de compilation standards sous Linux (en tous cas, pour les 2 les plus répandus, autotools et cmake. Je n'ai jamais eu l'occasion d'en essayer d'autre dans un contexte de crossbuild).
Franchement, la cross-compilation, c'est pas un gros problème. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: conception modulaire… photographie ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Lancement de la campagne de financement de la caméra libre AXIOM Beta 4K . Évalué à 2.
Ah ça je sais pas. Je faisais jamais développer. On nous a enseigné à développer et tirer nous-même.
Oui enfin le moteur ne s'occupe en général que d'un axe (ou alors t'as un télescope très cher, j'imagine car j'ai pas vu de télescope amateur avec moteur sur tous les axes!), donc si y a une mise en station même minimement faussée, faut corriger. Ensuite clairement si tu fais des photos de 30 secs seulement, c'est clair que t'as pas à te fatiguer. Ça n'a pas le temps de se décaler même avec mise en station approximative.
Ceci dit, même sans moteur du tout, c'était très sympa de faire de super longue poses en tournant à la main progressivement pendant des dizaines de minutes. Il fait froid, c'est crevant, mais c'est gratifiant. Et puis si t'es avec des amis, tu peux toujours discuter et tu t'ennuies pas.
Dans mes souvenirs, on montait jamais haut de toutes façons en sensibilité. Haute sensibilité à la lumière, ça signifie plus de grain, de bruit, etc.
On n'est pas encore sûr si ce ventilateur sera vraiment nécessaire. Par contre il se peut que même s'il n'est pas nécessaire, cela améliore les caractéristiques du capteur, donc ça resterait utile. Le refroidissement a été prévu parce qu'il vaut mieux prévenir que guérir, mais il se peut qu'au final on se rende compte qu'il puisse être retiré. Aussi normalement le ventilateur et la cage du ventilateur pourra être retirée facilement dans le design prévu.
Je ne fais que retranscrire des choses qui ont été dites sur la liste de l'équipe y a environ 2 mois. Me demande pas plus de détails, j'en sais pas plus. :-)
Ben si l'Axiom se fait et qu'un jour, tu en viens là, tu partageras tes montages en OpenHardware, j'espère! :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: conception modulaire… photographie ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Lancement de la campagne de financement de la caméra libre AXIOM Beta 4K . Évalué à 3.
J'ai fait de l'astrophotographie. Bon c'était y a longtemps et en argentique. Déjà ça veut dire qu'on faisait des poses qui pouvait faire une heure ou plus (et pas toujours avec un moteur! Parfois on devait suivre à la main. Et encore même avec un moteur, faut régulièrement corriger en cas de mise en station imparfaite). Peut-être que cela a changé, j'imagine que les appareils numériques sont plus sensibles à la lumière et que les poses sont plus courtes, déjà, non?
En tous les cas, la solution pour ton problème est de cacher l'image le temps que la vibration de l'appareil se stabilise (tu peux mettre ton corps devant le tube du télescope, dans le noir complet et avec le réglage sur l'infini, c'est juste une absence de lumière donc ça ne gêne en rien). À l'époque, on n'avait pas de télécommande radio et y avait rien d'électronique dans les appareils, on avait un déclencheur filaire, entièrement mécanique (le "fil" appuyait physiquement sur le déclencheur!), donc c'était pire. Mais simplement boucher la vue marche très bien. La pellicule de prend pas de lumière pendant la vibration!
Sur des objets aussi lointain, tu mets pas constamment au point sur l'infini de toutes façons? Moi c'est le souvenir que j'en ai.
Sinon il existe un logiciel Libre très sympa pour contrôler un appareil photo numérique à travers la connexion USB. Ça s'appelle Entangle. Je sais que le mainteneur s'en sert notamment pour de l'astro-photographie lui-aussi d'ailleurs.
Avec ça tu peux contrôler la mise au point (et plein d'autres choses), avoir une prévisualisation de ta photo sur un écran plus grand que l'écran des appareils, puis prendre ta photo en cliquant juste "espace".
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: on refait le protocole
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Retour de Berlin. Évalué à 4. Dernière modification le 19 septembre 2014 à 13:50.
C'est pour ça que je précisais, je savais que ça pouvait en donner l'impression. :p
Ok, j'avais pas pigé cet aspect des choses. Continuons donc dans l'expérience de pensée.
Mouais, mon serveur connaît pas plus. Il demande au DNS à quel IP ça correspond, puis ensuite il transmet aux protocoles du dessous (TCP/IP) qui vont s'occuper de tout le transport et routage. Je vois vraiment pas où le serveur a fait du routage là.
Ben… c'est exactement la même chose que ton cas simple: 2 serveurs et 2 entités finales. C'est aussi la même chose que SMTP (dans le cas habituel où on envoie pas l'email directement au serveur final, ce qui est faisable mais peut être flaggué comme spam rapidement).
Franchement c'est pas du routage ça, ton cas encore plus "compliqué" avec IRC non plus. Ou alors très vite fait un routage de super haut niveau, qui utilise en vrai un routage bien plus réel de bas niveau. Mais bon le même que l'ensemble des protocoles du net de nos jours. Et encore, c'est tiré par les cheveux. Enfin je vois vraiment pas où tu veux en venir.
Ah d'ailleurs je viens de me souvenir du terme. On va plutôt appeler cela du "relai" à ce niveau de protocole. De même que le protocole SMTP fait aussi du "relai" de messages électroniques.
Moui, si tu as des milliers de ces petits morceaux (soit milliers de fichiers, soit un fichier si gros qu'il faut le couper beaucoup), ça va quand même boucher globalement la communication. Ensuite tu pourrais imaginer un système de priorité (réimplémenter un OS dans ton flux de données!) mais ça implique soudainement beaucoup plus de communication (le système de priorité ne peut pas être laissé au soin de l'envoyeur, sinon il fait ce qu'il veut et envoie toujours ses données en masse. Donc l'envoyeur attend que le destinataire lui donne le feu vert, cad lui envoie une requête "ok c'est bon, tu peux m'envoyer 2 paquets maintenant, mais pas plus"). Et puis ça va inutilement ralentir l'envoi du fichier par conséquent (déjà que les utilisateurs se plaignent que les chargements sont trop lents!) alors qu'on a des connexions de fous maintenant avec des bandes passantes suffisamment larges pour à la fois recevoir plein de données binaires et textuelles en parallèle sans percevoir le moindre ralentissement. Pourquoi faire compliqué, moins efficace, prône aux erreurs de protocole, d'implémentation hasardeuse et complexe, avec une sensation utilisateur "lente" à la fois pour l'envoi des binaires et le texte, etc. alors qu'on peut faire facile et efficace simplement avec deux flux parallèles (et on laisse l'OS gérer les I/O en simultané)? Je comprends même pas le but de la discussion. Ça apporte quoi que les données soient dans le flux? Je vois que des désavantages.
Bon c'est pas vrai: y en a qu'un seul d'avantage: si jamais on arrive pas à ouvrir un autre flux plus efficace (firewall, etc.), ben on n'a pas le choix. D'ailleurs je voudrais noter qu'il existe déjà depuis longtemps un tel transport binaire directement dans le flux, en base64, dans XMPP (transport "in-band" de Jingle). Mais franchement c'est à jamais utiliser si on a le choix de faire autrement (c'est d'ailleurs écrit clairement dans la XEP, c'est du "dernier recours" si on arrive pas à faire mieux). Proposer que ce genre de chose soit par défaut est d'après moi une aberration.
Donc analyse des données (comme je disais, on peut donner plusieurs sens à "parser". Le serveur va effectivement lire tout le stanza pour la "syntaxe", car c'est un flux, mais pas pour le "sens" nécessairement).
Ok dans ce cas là, ça tombe bien, oui le serveur s'arrête au header du stanza: le to bien sûr, mais aussi le from (vérifier que le from correspond bien à ce qui a été envoyé, je rappelle que XMPP est un protocole sécurisé et authentifié, pas comme SMTP, et donc qu'un serveur ne se contente pas de relayer des messages, il en vérifie notamment la provenance, la syntaxe, etc.), et éventuellement un chouille plus si nécessaire (par exemple le type, l'id si y a une réponse à renvoyer, etc.). Mais oui pourquoi le serveur irait analyser ce qu'il y a dans le stanza (à part si serveur de la NSA qui cherche des infos!)? Bien sûr que non, il ne va pas en extraire une "structure qui a du sens". C'est d'autant plus vrai que dans beaucoup de cas, il ne pourrait même pas. Je rappelle que XMPP est fait de plein de fonctionnalités, libre à chaque entité de les implémenter. Si on envoie une donnée particulière destinée à un client final, qui gère une fonctionnalité donnée, le serveur peut tout à fait ne pas avoir d'implémentation pour la dite-fonctionnalité. D'ailleurs la plupart du temps, les serveurs n'implémenteront pas les mêmes fonctionnalités (ou pas les mêmes bouts de la fonctionnalité) que les clients car ça n'a pas de sens. Donc le serveur se contente de relayer.
Et donc ça tombe bien, le serveur s'arrête au "to", sans chercher "le sens de ce qu'il y a en dessous" qu'il ne comprendrait probablement même pas de toutes façons puisque c'est une XEP pour clients. Ça se passe exactement comme tu veux! Donc un argument qui tombe!
Ok j'ai bien compris maintenant! ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: on refait le protocole
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Retour de Berlin. Évalué à 4.
Base64, l'un des principaux problèmes, c'est que ça augmente la taille d'un fichier d'environ le tiers. Donc déjà que les binaires peuvent être assez gros de nos jours (car souvent, ça implique des images, voire du son ou de la vidéo), ben là on envoie une version 1/3 plus grosse. C'est donc pas efficace.
La partie codage/décodage est très basique et n'est pas le problème. De nos jours, nos machines font plein d'autre codages beaucoup plus complexe sans qu'on s'en rende compte et en des temps tout à fait respectables. Note que d'autres choses peuvent augmenter la taille d'un fichier, par exemple si on chiffre la communication. Mais là c'est une perte de gain acceptée car ça a un intérêt (cacher les données). Par contre base64 n'a aucun autre intérêt que celui qu'on veut se forcer à passer par un canal texte pour transporter du binaire. D'ailleurs si on veut chiffrer tout en insérant notre fichier dans le canal texte, on chiffre d'abord puis on base64. Ça fait beaucoup d'overhead à la fin!
Non je pense vraiment que le vrai problème, c'est la taille, le temps que ça prend à charger, et par effet de bord, pour un flux de donnée, le fait que ça boucherait le tuyau.
Alors dans un email, c'est moins grave car ça n'a jamais été fait pour de l'instantané. Pour de l'instantané, je me demande comment cette équipe voit le mélange du binaire avec le reste. Ensuite j'ai pas lu du tout cette page. Je réponds juste à une pensée générale basé sur la seule phrase citée par devnewton. Peut-être qu'ils coupent le binaire en plein de petits bouts, comme rakoo dit plus haut, et mettent en place un système de priorité par exemple? Ou autre. Peut-être qu'ils ont d'autres idées intéressantes pour gérer cela. Ça devient super compliqué si tu pars dans ce genre d'idées ceci dit.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: conception modulaire… photographie ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Lancement de la campagne de financement de la caméra libre AXIOM Beta 4K . Évalué à 2. Dernière modification le 18 septembre 2014 à 13:38.
Je suis certain d'avoir déjà lu quelque part (sur une voie de communication officielle) que cela était aussi une cible et pourrait être complètement une utilisation viable d'AXIOM (après tout, si on peut prendre 300 images par seconde, le matos est bien capable d'en prendre aussi une seule! :p). Bon je cherche pas parce que j'ai la flemme, mais je voulais quand même signaler que ce marché n'est pas totalement étranger à Apertus (même si clairement la cible et marché principaux sont bien le cinéma, en effet).
Ensuite si t'as pas l'argent, t'as pas l'argent. On peut rien y faire. Mais n'hésite pas à communiquer à qui pourrait! :-)
Ensuite pour ta remarque sur la réussite à lever les fonds, je peux confirmer qu'en interne aussi, c'est loin d'être considéré comme gagné et ceux qui sont les plus impliqués essaient vraiment de trouver les moyens de relancer la machine. Car eux aussi voient la possibilité de ne pas atteindre le but avec la courbe actuelle.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]