Sur le bugzilla GNOME qui nous héberge, il y a le concept des bugs "GNOME-love" qui sont exactement ce dont tu parles (des bugs probablement faciles "pas trop compliqués" à corriger qui sont un bon point d'entrée dans un projet).
Ce serait en effet une bonne idée de mettre ce lien sur la page "Get Involved". En fait, comme de nombreuses autres pages, il faudrait clairement revoir le contenu de cette page, bien trop touffu. À l'heure actuelle, c'est simplement une reprise du contenu existant sur l'ancien site.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Sérieux? Je viens de regarder le site de ce logiciel, et dès la description du logiciel (emphases de moi):
Pixelmator for Mac is a powerful, fast, and easy-to-use image editor. It lets you enhance and touch up photos, sketch, draw and paint, add text and shapes, apply dazzling effects, and do so much more. Pixelmator is built and developed from the ground up for the Mac, taking full advantage of the latest OS X features and technologies.
Ils n'utilisent pas le mot "puissant"? Ah si, c'est le 6ème mot ("powerful") de la description! Je compte ce mot 9 fois sur la page principale (quasi à chaque description de fonctionnalité en fait).
C'est pas vague aussi "taking full advantage of the latest OS X features and technologies"?
L'ensemble de la page est du même acabit.
Note que je dis pas que c'est pas similaire sur la page de GIMP, mais je fais juste remarquer à quel point cette comparaison est vide de sens car le site de cet autre logiciel fait exactement ce que le gars dit qu'il ne fait pas.
Aussi je comprendrai jamais les gens qui se plaignent sans arrêt sans rien proposer en échange. On les attend les patchs! Le site web, tout comme GIMP lui-même, est un logiciel Libre. Y a un dépôt public et on a un bugtracker sur lequel on peut proposer des patchs.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Rien n'est évident en algorithmique. C'est la raison pour laquelle les algos naïfs (terme employé pour nommer justement les algorithmes "évidents") sont rarement les bons (ils sont suffisants pour commencer par contre et avoir quelque chose qui "marche" quand avant on avait juste rien, ça oui).
C'est la raison pour laquelle même si j'ai aussi moi-même diverses "croyances", je ne les considère pas comme évidentes et sûrement pas comme justes tant que je ne les ai pas implémentées, testées et comparées (quand il existe une autre implémentation). Encore moins quand je reprends un code sur lequel d'autres ont travaillés et se sont posés peut-être les mêmes questions.
En tous les cas, merci pour le patch. J'ai répondu. Je pense que le patch est sur la bonne voie mais il y a beaucoup de choses à changer plus en profondeur pour qu'il soit valide. Là tu casses l'utilisation des caractères de contrôle dans l'ensemble des codages single-byte. Or même s'ils sont rares et peu utilisés, les caractères de contrôle ne sont pas techniquement une erreur de codage. Ton patch risque de casser la détection de textes parfaitement valides dans n'importe lequel des codages single-byte pris en charge.
Ensuite peut-être que les caractères de contrôle peuvent être des séquences "négatives" (c'est à dire qu'ils feraient baisser la "confiance" en ce charset), bien que je ne sois pas sûr que ce soit utile (voire souhaitable) pour tous les caractères de contrôle en commun à tous les charsets (puisque baisser la confiance en tous les charsets n'apporte probablement rien, voire pourrait poser problème); mais ça peut l'être pour ceux qui sont uniques à quelques charsets. Ensuite encore une fois, ce serait à essayer et tester.
En tous les cas, si tu souhaites approfondir la question et proposer un patch plus complet, il est le bienvenu. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
là où je te rejoins c'est sur l'ergonomie du site, chez moi en tous cas les pages du nouveau site mettent un temps rédibitoire pour s'afficher, du coup téléphone ou ordi, ça ne le met pas en valeur
Ça a déjà été remarqué et n'a rien à voir avec l'ergonomie du site. En plus c'est un site tout en statique, et les images sont petites, franchement c'est dur de faire plus léger à moins de faire du texte pur (ce qui serait un choix intéressant pour promouvoir un logiciel de traitement et création d'images!). Je pense que faire un nouveau site pour un programme aussi connu que GIMP, ca se fait remarquer et qu'une quantité phénoménale de gens à travers le monde se connecte ces derniers jours, donc les serveurs ont du mal à tenir la charge. Tout simplement…
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
C'est faux, et je l'ai montré dans un commentaire précédent.
En effet. Je me basais sur le papier de recherche et j'ai eu tort. Tu sembles avoir raison sur le fait que l'implémentation n'a pas l'air d'être stricte. J'ai regardé un peu le code et je regarderai plus tard en détail les algos implémentés pour voir s'il y a une raison et si cela vaudra le coup d'essayer de rendre le test strict.
Ce n'est pas dit, et il faut bien se dire que les gens qui ont écrit ça à l'origine ont clairement testé eux-mêmes plusieurs implémentations (même dans le papier de recherche, ils citent déjà plusieurs types de tests et comment ils ont simplifié). Il faut bien voir que la rapidité et l'exhaustivité des langages est importante. Idéalement uchardet devrait être capable de détecter n'importe quel langage/charset et toujours rester rapide (voire très rapide). Si on se rend compte que certaines approximations peuvent accélérer la détection par 10 avec une qualité de détection très proche, clairement l'approximation vaut le coup.
Par exemple dans le papier, ils expliquent que l'approche naïve est de faire des stats par caractère, mais cela prend énormément de ressources CPU et mémoire. Au final, ils séparent juste la distribution en 2 groupes (caractères fréquemment et peu utilisés), ce qui rend le calcul beaucoup plus rapide et moins gourmand en ressource tout en gardant un résultat satisfaisant sur des textes d'une longueur minimale.
C'est certes moins précis, mais entre un résultat instantané et un calcul qui va charger des dizaines de dictionnaires en mémoire, créer un pic CPU, et prendre plusieurs secondes (pour ouvrir juste un bête fichier texte!), le choix est vite fait. Personne ne veut attendre plusieurs secondes à chaque ouverture d'un fichier dans gedit ou pour lancer son lecteur multimédia avec des sous-titres.
Je pense que le vrai problème de tes exemples est que ce sont des mots seuls et courts. uchardet ne sera probablement jamais efficace sur ce type de cas d'usage; et si c'est le tien principalement, alors uchardet n'est en effet pas fait pour toi.
Par contre uchardet sera toujours plus efficace à partir d'une ou deux phrases (plus efficace dans le sens où ce sera instantané tout en prenant en charge énormément plus de langages et charset; dans tous les cas, clairement si tu compares chaque mot avec un dictionnaire, ton algorithme sera toujours plus efficace, mais à quel prix!).
En tous les cas, merci pour le rapport de bug. Je regarderai si ça peut être amélioré avec un coût raisonnable quand je pourrai. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Par contre, on peut, et je pense qu'il faut, détecter les points de codes qui ne sont pas valides dans un encodage donné. Et ça, uchardet ne le fait visiblement pas.
Uchardet le fait.
Son algo est basé sur un papier de recherche qui combine 3 méthodes:
1/ le codage, c'est à dire la détection de séquences d'octets illégaux. Ce dont vous parlez. Il s'agit en fait de la méthode naïve la plus répandue quand quelqu'un va vouloir réimplémenter une détection de charset (par exemple gtksourceview utilisait grosso modo cet algorithme). Elle marche plutôt bien notamment pour les codages multi-bytes qui ont pas mal de séquences illégales. Par contre elle est très peu utile (voire souvent carrêment inutile) pour différencier les codages single-byte qui ont tous quasi les mêmes tableaux de caractères légaux (en particulier les ISO-8859-X).
Donc si uchardet le fait, bien entendu. Mais c'est loin d'être suffisant pour traiter la plupart des cas (il y a énormément de codages single-byte. En fait tous les langages européens sont codables sur une variante ISO-8859, et cet algo ne permet aucune détection pour un texte qui utilise une de ces variantes).
Notez pour l'anecdote, et c'est assez marrant, que Firefox rend mal la page même qui explique l'algo de leur ancienne méthode de détection (on voit des caractères cassés, typique d'un encodage raté). En fait, Mozilla n'utilise plus cet algo et a remplacé par une détection par langue.
Or un simple test avec uchardet montre que ce dernier détecte correctement le codage comme "WINDOWS-1252" (bon c'était probablement de l'ISO-8859-1, mais Windows-1252 est un superset donc acceptable). Comme quoi, je pense que c'était une erreur de la part de Mozilla d'abandonner cet algo.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Avec un nom comme Gimp, on suppose évidemment qu'à l'origine, les auteurs avaient en tête une suite de logiciels (Prochain sondage : qui laisse le SafeSearch activé sur Google ?).
Je pense que tu voulais dire "gimp suit" (en anglais "vêtement de gimp", sans 'e'). Et tu fais donc référence à Pulp Fiction. Je n'ai aucune idée si les auteurs originels avaient voulu faire une référence ou quoi. Et on nous demande très régulièrement de changer le nom du logiciel (troll récurrent qu'on a probablement tous les 6 mois sur l'une des listes de discussion dev ou user par quelqu'un d'outré par ce nom), et la réponse est invariablement la même: les gens connaissent "GIMP", le logiciel. Tu fais une recherche sur internet avec "gimp", tu ne trouves que des pages référençant le logiciel sur les X premières pages, dans toutes les langues. Tu ne trouves pas de truc sado-maso (et pas besoin de désactiver le safe search ou quoi que ce soit, c'est juste toujours le cas). On a même demandé à quelqu'un du milieu sado-maso si ce film avait vraiment créé une utilisation du mot, et même pas vraiment (c'est donc surtout dans la tête des gens qui se plaignent s'imaginant que gimp est utilisé quotidiennement dans ces milieux).
Les gens qui font le rapprochement et s'en trouvent choqués au point de dire qu'ils ne peuvent utiliser le logiciel avec un tel nom, ben franchement, j'ai envie de dire qu'ils font bien ce qu'ils veulent et qu'ils sont bien les seuls à penser à ça.
Je dis pas que c'est ton cas car je vois bien que tu fais des blagues dans le reste de ton post, mais je voulais juste éclaircir le fait que non, il n'y a aucune référence sado-maso dans le nom du soft. Et c'est pas parce qu'un film a utilisé un mot similaire pour un nom de personnage qu'on voit 5 minutes (nom dont personne ne se souvient même si les gens connaissent le film) dans un film y a 20 ans que ça a le moindre rapport.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Le numéro de version sur le bouton « Download » n'est pas très lisible. J'ai cru au début qu'il s'agissait d'un nombre de téléchargements. Il faudrait que les points qui séparent les chiffres soient plus visibles.
J'ai fait la même remarque à Patrick y a déjà plusieurs semaines. Il n'a en effet toujours pas corrigé. Je lui referai la remarque.
Je n'aime pas trop la manière dont les mots « GNU Image Manipulation Program » ont été placés, avec GNU Image en visibilité accrue.
Je n'avais pas fait gaffe, mais maintenant que tu le dis, je trouve que c'est une bonne remarque. Je ferai passer aussi.
Merci!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Tu ne donnes que cette chaîne de caractère à manger à uchardet? Ça, c'est sûr, tu lui donnes pas beaucoup de chances. Avec n'importe quel système de détection (même en utilisant un dico), tu peux trouver très facilement des cas d'erreur si ton texte en entrée est trop petit. Il faut au minimum avoir une petite phrase pour que ça commence à avoir du sens de comparer des systèmes de détection.
ISO-8859-1
Il n'y a pas encore de prise en charge de ce charset malheureusement.
Seul умный a un sens dans une langue (cela signifie intelligent en russe).
Ok en effet si ton cas d'usage est de détecter la langue/charset de mots courts, tous seul, alors il me paraît clair qu'un tel système de détection par dictionnaire uniquement sera fiable. Et encore, cela cassera à la moindre faute d'orthographe, en conjuguant ou accordant en genre/nombre, ou simplement si ton mot n'est pas dans le dico, comme un argot récent ou un mot très moderne. Choses qui peuvent être améliorées en ajoutant une prise en charge grammaticale. Bon au final tu implémentes du traitement de la langue! :-)
uchardet va le détecter en se rendant compte que les lettres у, м, н, ы, й sont plus fréquentes en russe que n'importe lesquelles des lettres des autres résultats dans n'importe quel langage.
Pas seulement, il utilise aussi les stats de fréquence de suites de 2 caractères.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je suis le mainteneur de uchardet depuis peu. C'est effectivement la meilleure alternative à l'heure actuelle pour la détection de charset en Libre. Les "classiques" (enca, libguess…) utilisés jusque là sont ridicules d'inefficacité, sans compter ceux qui essaient de réimplémenter une telle détection avec des algos naïfs (ex: gtksourceview, voire VLC, mais eux ne font pas vraiment de détection basé sur le fichier en fait).
Néanmoins la lib est encore loin d'être parfaite. Mais je vais essayer d'améliorer cela avec le temps.
Et voilà, on en arrive enfin à la raison pour laquelle j'ai écrit ce journal. uchardet utilise une méthode statistiques fondée sur la fréquence des lettres. C'est bien, parce que c'est rapide, et que ce n'est pas gros. Mais l'inconvénient, c'est qu'il lui arrive de se tromper, entre deux codecs proches et deux langues proches, quand le fichier comprend peu de caractères spéciaux.
Même si c'est possible que l'algo se trompe entre des codages proches sur certains textes, je pense que le vrai problème est que les données devraient être mises à jour pour certains codages, et surtout uchardet ne prend pas encore en charge tous les codages (même certains qui sont très courant). Un exemple simple, c'est que uchardet est nul pour le français par exemple si vous avez des vieux textes pas écrit en UTF-* (en français, historiquement on utilisait surtout ISO-8859-15, voire ISO-8859-1, y a encore pas si longtemps de cela. Or uchardet n'a de prise en charge d'aucun de ces deux charsets assez communs).
Mais ça devrait s'améliorer. Dans tous les cas, ça va dans le bon sens. mpv utilise dorénavant uchardet comme mode de détection par défaut (si c'est compilé avec). Ce qui fait que je peux enfin regarder mes films avec des sous-titres japonais ou coréen (ce qui était mon cas d'usage principal qui m'a poussé à regarder et tester ce qui existait, le pousser dans divers logiciels, pour finalement devenir le mainteneur d'uchardet) sans me prendre la tête à savoir si le créateur du fichier l'a fait en UTF-8, en EUC-KR ou quoi que ce soit d'autre…
gtksourceview sont sur le point de merger mes patchs, ce qui veut dire par exemple que gedit pourra enfin ouvrir mes fichiers non-UTF-8 sans que je me prenne la tête à sélectionner le bon charset dans une liste déroulante.
Etc.
Donc j'ai écrit un petit script python, qui se fonde sur l'utilsation d'un dictionnaire pour détecter la langue du fichier.
J'y avais pensé aussi. Par contre, ton approche est trop bourrine pour être facilement extensible. Utiliser un dico complet (en plus tu prends en charge que 3 langues, et ça ralentit déjà), c'est normal que ce soit lent. Par contre toutes les langues ont des mots très courants, et ceux-là, oui clairement c'est une approche très intéressante. En fait c'est une approche très proche de l'algo d'uchardet qui se base sur des stats de suites de deux ou trois lettres, ce que tu appliques à des mots complets. À partir de là se pose aussi la question de ce qu'est un mot.
Je vois que tu tokenizes tes mots avec l'expression régulières "\w". Ça marchera pour tes trois langues choisies (anglais, français, russe), mais par par exemple ça ne marchera pas avec du Japonais ou du Chinois qui ne séparent pas les mots avec des espaces.
Pour cela, il y a des segmenteurs (comme tinysegmenter que je maintiens aussi mais n'ai pas touché depuis longtemps).
En tous les cas, oui, utiliser une liste limitée des mots (pas tous les mots) très utilisés statistiquement dans un langage peut être très intéressant pour compléter d'autres méthodes de détection (uchardet lui-même combine plusieurs méthodes de détection d'ailleurs) et donner une note globale de "confiance" dans un résultat de détection.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Vous avez raison, c'est assez vulnérable.
Le vrai problème est que la plupart des gens veulent quelque chose de peu cher et rapide, voire quasi instantané (tout en parlant sécurité). Donc les CAs font des vérifs de ce genre passant par le DNS (un autre classique est aussi d'envoyer une vérif par email à une des adresses enregistrées pour ce domaine dans le DNS, ce qui est aussi tout à fait vulnérable à une interception).
Le top de la sécurité serait bien entendu que deux personnes (un représentant le domaine, l'autre le CA) se rencontrent en vrai, physiquement, pour s'échanger des informations d'identité puis — si tout semble en ordre — des infos d'identification au service. Mais ça prendrait du temps, et surtout ça coûterait une blinde (le temps humain est ce qui coûte le plus cher!). Cela va à l'encontre du besoin.
Donc des compromis sont faits. De toutes façons peu de gens comprennent vraiment ce qu'ils font avec HTTPS, même ceux qui sont payés pour cela.
Pour minimiser le risque ceci dit, la vérification de présence du fichier est faite sur le serveur en https (c'est à dire https://example.com, et non http://example.com). Voir la page d'explication des technos. Donc tant que le renouvellement se fait avec un certificat encore valide (ce devrait être le cas, puisqu'automatique), cela assure une certaine sécurité. Le risque de MITM n'apparaît donc qu'à la demande initiale. Bien sūr, l'attaquant pourrait alors demander à passer par un canal moins sécurisé (comme un enregistrement DNS), et ce serait donc bien si un possesseur/administrateur de domaine avait la possibilité de bloquer certains canaux de vérification.
Dans tous les cas, oui. Il y a toujours à un moment donné au moins 1 instant (l'échange initial) où la sécurité est faible et sujette à attaque si toutes communications passent par Internet. C'est le coût de tout faire à distance et c'est la raison pour laquelle les geeks sécurité font des "key signing party" pour s'échanger et signer leurs clés personnelles avec rencontre physique et vérification d'identité, afin d'éliminer ce risque de l'échange initial.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Il me semble n'être encore jamais venu à l'Open World Forum ou Solutions Linux (maintenant Open Source Summit), mais de ce que j'en entends dire et de la façon dont ils se présentent eux-même, c'est un évènement clairement orienté professionnel.
Par conséquent, je pense même que venir avec des CVs est bien vu, si tu cherches du boulot dans l'Open Source.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
On devait y être pour présenter le projet de film d'animation ZeMarmot. ;-(
Je viens d'appeler notre contact, et on nous a dit qu'ils allaient faire une réunion des organisateurs ce soir pour voir s'il n'y a pas possibilité de trouver un autre lieu pour faire tout de même une rencontre plus informelle ("à l'arrache"). Donc tout n'est pas perdu, même s'il vaut mieux ne pas se faire trop d'illusion.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
En même temps, ton "mendiant" (Wikipédia), tu es encore une fois allé le voir de toi-même pour lui redemander une autre information, comme il connaît tellement bien tout cela. Sans cela, tu n'aurais pas eu à subir sa "pub". C'est pas comme si t'étais tranquillement assis sur un banc et qu'il est venu te chercher (Wikipédia ne se connecte pas à ton ordi inopinément!). C'est l'inverse.
Ton argument ne vaut rien. Il permet de justifier la publicité agressive, ou toute aute forme d'incivilité sous pretexte de proposer quelque chose de gratuit.
Je ne suis pas à 100% à fond pour leur technique de campagne (ce n'est pas de la pub à propos!), et je la trouve un peu intrusive aussi. Et il y a clairement des choses à faire pour l'améliorer. En même temps, je ne vais pas cracher sur eux. Ça reste une fondation à but non lucrative qui fait des choses que je trouve extraordinaires et a réellement changé notre vision de l'encyclopédie et du partage de connaissance. Je me souviens encore quand j'étais petit, les gens ne juraient que par certaines grosses encyclopédies qui venaient en 50 volumes et coûtaient des fortunes. Puis y a eu des encyclopédies numériques comme Encarta et surtout Universalis (qui si je me souviens bien coûtait des milliers d'euros!).
C'était vraiment la connaissance réservée aux riches. Wikipédia a vraiment fait quelque chose d'assez grandiose dans ce domaine.
Donc tant qu'ils ne reviennent pas sur ces principes de la connaissance pour tous, alors je peux supporter quelques bandeaux une fois par an (et je donnerais si j'avais un salaire. Ce que j'ai déjà fait par le passé).
Donc oui, leur méthode de demande de don pourrait être améliorée. Peut-être qu'ils tâtonnent pour trouver la méthode idéale. Peut-être même qu'ils sont tous les ans proches de l'extinction car ils ont du mal à subvenir aux besoins du service proposé (ils sont quand même dans le top-10 des sites les plus vues au monde, c'est pas un petit serveur dans le placard qu'il faut pour soutenir la charge!) et que comme le problème se répète annuellement, ils se disent qu'ils veulent essayer quelque chose de différent l'an prochain. Donc ils essaient de nouveaux modes de demande de donation, un peu plus visibles en se disant qu'au moins ainsi les gens ignoreront moins.
Ils pourraient aussi engager du personnel marketing experts en techniques de démarchages plus subtiles, car ils connaissent tous les trucs pour soulager la bourse des gens sans même qu'ils s'en rendent compte. En même temps, s'ils utilisaient tout leur argent donné dans ce genre de pratique pour faire plaisir aux donateurs et les rendre confortables sans leur mettre un peu les yeux en face des trous de temps en temps, c'est là où je serais pas content.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Question de couche: pour moi le protocole doit être indépendant de la manière de le transporter.
Je comprends pas de quoi tu parles et le rapport avec la discussion. XMPP est indépendant de la couche de transport, qui est en effet TCP par défaut, mais peut-être ce que tu veux d'autre. Par exemple, y a du XMPP over BOSH (cad HTTP).
C'est même explicitement décrit dans la RFC 6120:
Informational Note: There is no necessary coupling of XML streams to TCP, and other transports are possible. For example, two entities could connect to each other by means of [HTTP] as specified in [XEP‑0124] and [XEP‑0206]. However, this specification defines only a binding of XMPP to TCP.
Si tu parles de la couche de transport pour les données, ben c'est aussi exactement ce que fait XMPP avec Jingle! Le protocole permet de définir divers transports, avec des connexions directs TCP, UDP, ou ce que tu veux, en passant par des intermédiaires ou en direct, etc. Et avec du transport inline dans XMPP en dernier recours.
Par exemple dans Mumble, les paquets peuvent être transférés sur deux connexions TCP+UDP ou sur une seule connexion TCP:
While the TCP connection is mandatory the UDP connection can be compensated by tunnelling the UDP packets through the TCP connection as described in the protocol description later.
Bon je peux dire une connerie car je connais pas Mumble et j'ai pas le temps ni l'envie de regarder en détail, mais la citation que tu fais… ben c'est exactement ce que fait XMPP et ce que je dis plus haut (bon sauf que XMPP fait bien plus que juste ces deux cas). Là ils semblent dire que la connexion UDP est le comportement par défaut, mais qu'elle peut être remplacée par la connexion TCP existante (j'imagine si l'établissement de la seconde connexion échoue). Ben c'est ce que fait XMPP avec son fallback inline.
Mais au final dans Mumble aussi, ils sont donc probablement conscients que si possible, ils préfèrent utiliser une connexion séparée.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je sais pas si ça existe, mais le problème est qu'un fichier, ça prend de la place. Quand tu transfères d'un compte à l'autre, ça n'utilise que de la bande passante. Si tu te mets à joindre des fichiers "en attente de connexion", faut bien le stocker quelque part, c'est à dire sur un des serveurs du fournisseur de service (sur celui de l'envoyeur ou du destinataire d'ailleurs?!).
En plus, beaucoup d'utilisateurs sur n'importe quel service sont des fantômes (ils s'inscrivent, utilisent — ou non — un temps, puis un jour ne reviennent jamais), donc ça peut entraîner des quantités phénoménales de données stockées qui ne désemplissent jamais avec le temps quand les destinataires ne se re-connectent jamais.
Donc au final, les fournisseurs de service en viennent rapidement à limiter. Va envoyer un fichier de 100 Go par email! Peu de services email (probablement aucun dans les services commerciaux) n'autoriseront. Prenons gmail par exemple, ils limitent à 25 Mo. Et même si votre fournisseur autorisait de grosses tailles, il n'est pas dit que le fournisseur du destinataire accepte l'email s'il a une limite inférieure! Tout de suite, ça limite.
Au final, le concept de pièce jointe reste intéressant mais très limité comparé à du transfert direct où on peut envoyer n'importe quelle taille. Ce ne sera jamais le protocole qui limitera sur le sujet, mais les implémentations car c'est un nid à problème.
Mais sinon oui, pour des petits fichiers, ce serait une fonctionnalité intéressante (si ça n'existe pas déjà), mais je préfèrerais voir le transfert de fichier direct marcher de façon fiable d'abord. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Aucun protocole moderne digne de ce nom ne prévoirait d'utiliser le canal principal pour l'échange binaire! Un échange binaire sur le même canal implique de bloquer la connexion le temps du transfert. Même le vieux ftp, qui est un protocole à la base fait pour transférer des fichiers (donc on pourrait naïvement penser "autant tout faire dans la même connexion: contrôles et transferts!") ouvre une connexion de données séparées, ce qui permet de continuer à naviguer dans l'arborescence et d'exécuter diverses commandes de contrôle.
Bien sûr, on peut aménager le protocole pour ne pas bloquer la connexion, par exemple en coupant en petits bouts le fichier (permettant pleins de petits transferts entre lesquelles des commandes peuvent se placer). Néanmoins cela a pour conséquence de donner une sensation de ralentissement à la fois du transfert (envoyer pleins de petits bouts avec des caractères de contrôle à chaque fois est plus lent qu'envoyer en un bloc) mais aussi le flux non binaire (si on doit constamment attendre le chargement d'un bout binaire, même les messages textes pourraient se mettre à prendre quelques secondes le temps que le bout en cours se termine).
Et c'est sans compter que ça oblige en général de réencoder (par ex avec base64 dans XMPP) parce qu'on ne contrôle pas le contenu d'un binaire et que le mettre direct dans le flux cassera ce dernier chaque fois qu'un contenu de fichier utilise un caractère de contrôle du protocole. Donc le fichier à envoyer est plus gros (de l'ordre du tiers avec base64, de mémoire, ce qui n'est pas rien si on envoie de très gros fichiers!). Ça rallonge d'autant la durée du transfert.
Tout ça, c'est vraiment se faire chier pour rien alors que les connexions, de nos jours, sont tout à fait capables d'encaisser même plusieurs transferts de fichiers en parallèle à pleine vitesse chacune sur leur canal, tout en gardant un canal de contrôle non-encombré, parfaitement fluide et rapide aussi.
Donc non, franchement un protocole qui commencerait avec l'idée de tout faire dans le même canal, j'aurais pas confiance. Ça ne peut pas monter en charge notamment.
Par contre oui, comme solution de secours si on n'arrive pas à initier un canal binaire, ça ok, en bridant si besoin le transfert pour pas qu'il gêne trop le reste de l'expérience utilisateurs. C'est d'ailleurs ce que fait XMPP.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Puisque les gens y vont des petites pubs, y a aussi Aryeom Han qui travaille exclusivement sous Linux avec des Logiciels Libres dernièrement. Voir notre film ZeMarmot: http://film.zemarmot.net/
Mais on n'a pas de forum. Par rapport à ce besoin en particulier, je rejoins la réponse plus haut au sujet de http://linuxgraphic.org.
Par contre nous participons à une association, LILA, avec des vrais gens qu'on peut rencontrer en chair et en os, sur Paris: http://libreart.info/
Mais on peine un peu à intéresser les gens.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Pourrais-tu être plus explicite stp? L'article ci-dessus ne parle pas de l'utilisation de mknod.
Alors je comprends que mknod sert à créer le fichier périphérique sous /dev/, et que donc tu me dis que cela permet de le créer manuellement et donc d'accéder à ma carte malgré que mon kernel ne semble pas le voir de lui-même.
Mais alors j'ai beau regarder la page man et diversespages, je trouve aucune info (ou alors anciennes et plus à jour) qui m'aide à comprendre comment on choisit les paramètres.
Si t'as une référence qui explique bien comment cela marche, je suis preneur.
à l'ancienne
Je pense que je suis pas assez ancien! :P
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Tu as essayé de formatter une clé USB avec ton image iso et de booter dessus?
Cela fait des années que je n'ai plus gravé de CD. Si j'ai besoin d'un périphérique bootable, je mets dans une clé USB. C'est plus simple, tu ne gâches pas de CD, tu peux réutiliser (plus qu'un CD réinscriptible), ça prend moins de place, tu peux même ajouter d'autres données dessus facilement, etc.
Perso j'utilise la méthode avec la commande console dd. Par contre faut bien comprendre ce qu'on fait, car si tu te plantes de périphérique, tu peux te retrouver à effacer ton disque dur! Les logiciels graphiques sont peut-être plus sûr si tu ne comprends pas bien les tenants et aboutissants.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Est-ce que la récupération de données marche pour une carte Compact Flash?
Et surtout, l'OS ne semble même plus la voir! Si je l'insère dans le lecteur, rien ne se passe, rien dans dmesg non plus. Donc a priori, je ne pense pas qu'un périphérique sous /dev/ lui est associé.
Quelles sont les possibilités dans un tel cas?
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
A priori, on s'oriente vers un oui (pour eux, c'est juste qu'ils ne comprennent pas forcément le pourquoi du comment. ça tombe bien, je peux prendre du temps pour expliquer :) )
C'est assez ironique, non? Ils font un doc sur les plateformes à CGUs déloyales et ils ne comprennent pas pourquoi vous préféreriez diffuser ailleurs que sur les dites plateformes?
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Attirer les nouveaux contributeurs
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP a 20 ans !. Évalué à 6.
Sur le bugzilla GNOME qui nous héberge, il y a le concept des bugs "GNOME-love" qui sont exactement ce dont tu parles (des bugs probablement
faciles"pas trop compliqués" à corriger qui sont un bon point d'entrée dans un projet).Tu y as accès par exemple avec le lien "GNOME-love bugs" à droite dans la page d'un projet sur le bugtracker: https://bugzilla.gnome.org/page.cgi?id=browse.html&product=GIMP
Le lien direct vers les bugs GNOME-love de GIMP
Ce serait en effet une bonne idée de mettre ce lien sur la page "Get Involved". En fait, comme de nombreuses autres pages, il faudrait clairement revoir le contenu de cette page, bien trop touffu. À l'heure actuelle, c'est simplement une reprise du contenu existant sur l'ancien site.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Merci, Gimp!
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP a 20 ans !. Évalué à 10. Dernière modification le 25 novembre 2015 à 01:07.
Sérieux? Je viens de regarder le site de ce logiciel, et dès la description du logiciel (emphases de moi):
Ils n'utilisent pas le mot "puissant"? Ah si, c'est le 6ème mot ("powerful") de la description! Je compte ce mot 9 fois sur la page principale (quasi à chaque description de fonctionnalité en fait).
C'est pas vague aussi "taking full advantage of the latest OS X features and technologies"?
L'ensemble de la page est du même acabit.
Note que je dis pas que c'est pas similaire sur la page de GIMP, mais je fais juste remarquer à quel point cette comparaison est vide de sens car le site de cet autre logiciel fait exactement ce que le gars dit qu'il ne fait pas.
Aussi je comprendrai jamais les gens qui se plaignent sans arrêt sans rien proposer en échange. On les attend les patchs! Le site web, tout comme GIMP lui-même, est un logiciel Libre. Y a un dépôt public et on a un bugtracker sur lequel on peut proposer des patchs.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: exemple
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal toutf8: autodétecter et convertir de n'importe quel encodage de caractères vers UTF8. Évalué à 4. Dernière modification le 24 novembre 2015 à 23:49.
Rien n'est évident en algorithmique. C'est la raison pour laquelle les algos naïfs (terme employé pour nommer justement les algorithmes "évidents") sont rarement les bons (ils sont suffisants pour commencer par contre et avoir quelque chose qui "marche" quand avant on avait juste rien, ça oui).
C'est la raison pour laquelle même si j'ai aussi moi-même diverses "croyances", je ne les considère pas comme évidentes et sûrement pas comme justes tant que je ne les ai pas implémentées, testées et comparées (quand il existe une autre implémentation). Encore moins quand je reprends un code sur lequel d'autres ont travaillés et se sont posés peut-être les mêmes questions.
En tous les cas, merci pour le patch. J'ai répondu. Je pense que le patch est sur la bonne voie mais il y a beaucoup de choses à changer plus en profondeur pour qu'il soit valide. Là tu casses l'utilisation des caractères de contrôle dans l'ensemble des codages single-byte. Or même s'ils sont rares et peu utilisés, les caractères de contrôle ne sont pas techniquement une erreur de codage. Ton patch risque de casser la détection de textes parfaitement valides dans n'importe lequel des codages single-byte pris en charge.
Ensuite peut-être que les caractères de contrôle peuvent être des séquences "négatives" (c'est à dire qu'ils feraient baisser la "confiance" en ce charset), bien que je ne sois pas sûr que ce soit utile (voire souhaitable) pour tous les caractères de contrôle en commun à tous les charsets (puisque baisser la confiance en tous les charsets n'apporte probablement rien, voire pourrait poser problème); mais ça peut l'être pour ceux qui sont uniques à quelques charsets. Ensuite encore une fois, ce serait à essayer et tester.
En tous les cas, si tu souhaites approfondir la question et proposer un patch plus complet, il est le bienvenu. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Merci, Gimp!
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP a 20 ans !. Évalué à 7.
Ça a déjà été remarqué et n'a rien à voir avec l'ergonomie du site. En plus c'est un site tout en statique, et les images sont petites, franchement c'est dur de faire plus léger à moins de faire du texte pur (ce qui serait un choix intéressant pour promouvoir un logiciel de traitement et création d'images!). Je pense que faire un nouveau site pour un programme aussi connu que GIMP, ca se fait remarquer et qu'une quantité phénoménale de gens à travers le monde se connecte ces derniers jours, donc les serveurs ont du mal à tenir la charge. Tout simplement…
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: exemple
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal toutf8: autodétecter et convertir de n'importe quel encodage de caractères vers UTF8. Évalué à 5.
En effet. Je me basais sur le papier de recherche et j'ai eu tort. Tu sembles avoir raison sur le fait que l'implémentation n'a pas l'air d'être stricte. J'ai regardé un peu le code et je regarderai plus tard en détail les algos implémentés pour voir s'il y a une raison et si cela vaudra le coup d'essayer de rendre le test strict.
Ce n'est pas dit, et il faut bien se dire que les gens qui ont écrit ça à l'origine ont clairement testé eux-mêmes plusieurs implémentations (même dans le papier de recherche, ils citent déjà plusieurs types de tests et comment ils ont simplifié). Il faut bien voir que la rapidité et l'exhaustivité des langages est importante. Idéalement uchardet devrait être capable de détecter n'importe quel langage/charset et toujours rester rapide (voire très rapide). Si on se rend compte que certaines approximations peuvent accélérer la détection par 10 avec une qualité de détection très proche, clairement l'approximation vaut le coup.
Par exemple dans le papier, ils expliquent que l'approche naïve est de faire des stats par caractère, mais cela prend énormément de ressources CPU et mémoire. Au final, ils séparent juste la distribution en 2 groupes (caractères fréquemment et peu utilisés), ce qui rend le calcul beaucoup plus rapide et moins gourmand en ressource tout en gardant un résultat satisfaisant sur des textes d'une longueur minimale.
C'est certes moins précis, mais entre un résultat instantané et un calcul qui va charger des dizaines de dictionnaires en mémoire, créer un pic CPU, et prendre plusieurs secondes (pour ouvrir juste un bête fichier texte!), le choix est vite fait. Personne ne veut attendre plusieurs secondes à chaque ouverture d'un fichier dans gedit ou pour lancer son lecteur multimédia avec des sous-titres.
Je pense que le vrai problème de tes exemples est que ce sont des mots seuls et courts. uchardet ne sera probablement jamais efficace sur ce type de cas d'usage; et si c'est le tien principalement, alors uchardet n'est en effet pas fait pour toi.
Par contre uchardet sera toujours plus efficace à partir d'une ou deux phrases (plus efficace dans le sens où ce sera instantané tout en prenant en charge énormément plus de langages et charset; dans tous les cas, clairement si tu compares chaque mot avec un dictionnaire, ton algorithme sera toujours plus efficace, mais à quel prix!).
En tous les cas, merci pour le rapport de bug. Je regarderai si ça peut être amélioré avec un coût raisonnable quand je pourrai. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: exemple
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal toutf8: autodétecter et convertir de n'importe quel encodage de caractères vers UTF8. Évalué à 5. Dernière modification le 24 novembre 2015 à 15:54.
Uchardet le fait.
Son algo est basé sur un papier de recherche qui combine 3 méthodes:
1/ le codage, c'est à dire la détection de séquences d'octets illégaux. Ce dont vous parlez. Il s'agit en fait de la méthode naïve la plus répandue quand quelqu'un va vouloir réimplémenter une détection de charset (par exemple gtksourceview utilisait grosso modo cet algorithme). Elle marche plutôt bien notamment pour les codages multi-bytes qui ont pas mal de séquences illégales. Par contre elle est très peu utile (voire souvent carrêment inutile) pour différencier les codages single-byte qui ont tous quasi les mêmes tableaux de caractères légaux (en particulier les ISO-8859-X).
Donc si uchardet le fait, bien entendu. Mais c'est loin d'être suffisant pour traiter la plupart des cas (il y a énormément de codages single-byte. En fait tous les langages européens sont codables sur une variante ISO-8859, et cet algo ne permet aucune détection pour un texte qui utilise une de ces variantes).
2/ La distribution de caractère.
3/ La distribution de suites de 2 caractères.
Voir le papier ici: http://www-archive.mozilla.org/projects/intl/UniversalCharsetDetection.html
Notez pour l'anecdote, et c'est assez marrant, que Firefox rend mal la page même qui explique l'algo de leur ancienne méthode de détection (on voit des caractères cassés, typique d'un encodage raté). En fait, Mozilla n'utilise plus cet algo et a remplacé par une détection par langue.
Or un simple test avec uchardet montre que ce dernier détecte correctement le codage comme "WINDOWS-1252" (bon c'était probablement de l'ISO-8859-1, mais Windows-1252 est un superset donc acceptable). Comme quoi, je pense que c'était une erreur de la part de Mozilla d'abandonner cet algo.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Linux et au dela
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP a 20 ans !. Évalué à 10.
Je pense que tu voulais dire "gimp suit" (en anglais "vêtement de gimp", sans 'e'). Et tu fais donc référence à Pulp Fiction. Je n'ai aucune idée si les auteurs originels avaient voulu faire une référence ou quoi. Et on nous demande très régulièrement de changer le nom du logiciel (troll récurrent qu'on a probablement tous les 6 mois sur l'une des listes de discussion dev ou user par quelqu'un d'outré par ce nom), et la réponse est invariablement la même: les gens connaissent "GIMP", le logiciel. Tu fais une recherche sur internet avec "gimp", tu ne trouves que des pages référençant le logiciel sur les X premières pages, dans toutes les langues. Tu ne trouves pas de truc sado-maso (et pas besoin de désactiver le safe search ou quoi que ce soit, c'est juste toujours le cas). On a même demandé à quelqu'un du milieu sado-maso si ce film avait vraiment créé une utilisation du mot, et même pas vraiment (c'est donc surtout dans la tête des gens qui se plaignent s'imaginant que gimp est utilisé quotidiennement dans ces milieux).
Les gens qui font le rapprochement et s'en trouvent choqués au point de dire qu'ils ne peuvent utiliser le logiciel avec un tel nom, ben franchement, j'ai envie de dire qu'ils font bien ce qu'ils veulent et qu'ils sont bien les seuls à penser à ça.
Je dis pas que c'est ton cas car je vois bien que tu fais des blagues dans le reste de ton post, mais je voulais juste éclaircir le fait que non, il n'y a aucune référence sado-maso dans le nom du soft. Et c'est pas parce qu'un film a utilisé un mot similaire pour un nom de personnage qu'on voit 5 minutes (nom dont personne ne se souvient même si les gens connaissent le film) dans un film y a 20 ans que ça a le moindre rapport.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Réaction à chaud
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP a 20 ans !. Évalué à 5.
Salut,
J'ai fait la même remarque à Patrick y a déjà plusieurs semaines. Il n'a en effet toujours pas corrigé. Je lui referai la remarque.
Je n'avais pas fait gaffe, mais maintenant que tu le dis, je trouve que c'est une bonne remarque. Je ferai passer aussi.
Merci!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: précision
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal toutf8: autodétecter et convertir de n'importe quel encodage de caractères vers UTF8. Évalué à 7.
Tu ne donnes que cette chaîne de caractère à manger à uchardet? Ça, c'est sûr, tu lui donnes pas beaucoup de chances. Avec n'importe quel système de détection (même en utilisant un dico), tu peux trouver très facilement des cas d'erreur si ton texte en entrée est trop petit. Il faut au minimum avoir une petite phrase pour que ça commence à avoir du sens de comparer des systèmes de détection.
Il n'y a pas encore de prise en charge de ce charset malheureusement.
Ok en effet si ton cas d'usage est de détecter la langue/charset de mots courts, tous seul, alors il me paraît clair qu'un tel système de détection par dictionnaire uniquement sera fiable. Et encore, cela cassera à la moindre faute d'orthographe, en conjuguant ou accordant en genre/nombre, ou simplement si ton mot n'est pas dans le dico, comme un argot récent ou un mot très moderne. Choses qui peuvent être améliorées en ajoutant une prise en charge grammaticale. Bon au final tu implémentes du traitement de la langue! :-)
Pas seulement, il utilise aussi les stats de fréquence de suites de 2 caractères.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Au sujet d'uchardet
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal toutf8: autodétecter et convertir de n'importe quel encodage de caractères vers UTF8. Évalué à 10.
Salut,
Je suis le mainteneur de uchardet depuis peu. C'est effectivement la meilleure alternative à l'heure actuelle pour la détection de charset en Libre. Les "classiques" (enca, libguess…) utilisés jusque là sont ridicules d'inefficacité, sans compter ceux qui essaient de réimplémenter une telle détection avec des algos naïfs (ex: gtksourceview, voire VLC, mais eux ne font pas vraiment de détection basé sur le fichier en fait).
Néanmoins la lib est encore loin d'être parfaite. Mais je vais essayer d'améliorer cela avec le temps.
Même si c'est possible que l'algo se trompe entre des codages proches sur certains textes, je pense que le vrai problème est que les données devraient être mises à jour pour certains codages, et surtout uchardet ne prend pas encore en charge tous les codages (même certains qui sont très courant). Un exemple simple, c'est que uchardet est nul pour le français par exemple si vous avez des vieux textes pas écrit en UTF-* (en français, historiquement on utilisait surtout ISO-8859-15, voire ISO-8859-1, y a encore pas si longtemps de cela. Or uchardet n'a de prise en charge d'aucun de ces deux charsets assez communs).
Mais ça devrait s'améliorer. Dans tous les cas, ça va dans le bon sens. mpv utilise dorénavant uchardet comme mode de détection par défaut (si c'est compilé avec). Ce qui fait que je peux enfin regarder mes films avec des sous-titres japonais ou coréen (ce qui était mon cas d'usage principal qui m'a poussé à regarder et tester ce qui existait, le pousser dans divers logiciels, pour finalement devenir le mainteneur d'uchardet) sans me prendre la tête à savoir si le créateur du fichier l'a fait en UTF-8, en EUC-KR ou quoi que ce soit d'autre…
gtksourceview sont sur le point de merger mes patchs, ce qui veut dire par exemple que gedit pourra enfin ouvrir mes fichiers non-UTF-8 sans que je me prenne la tête à sélectionner le bon charset dans une liste déroulante.
Etc.
J'y avais pensé aussi. Par contre, ton approche est trop bourrine pour être facilement extensible. Utiliser un dico complet (en plus tu prends en charge que 3 langues, et ça ralentit déjà), c'est normal que ce soit lent. Par contre toutes les langues ont des mots très courants, et ceux-là, oui clairement c'est une approche très intéressante. En fait c'est une approche très proche de l'algo d'uchardet qui se base sur des stats de suites de deux ou trois lettres, ce que tu appliques à des mots complets. À partir de là se pose aussi la question de ce qu'est un mot.
Je vois que tu tokenizes tes mots avec l'expression régulières "\w". Ça marchera pour tes trois langues choisies (anglais, français, russe), mais par par exemple ça ne marchera pas avec du Japonais ou du Chinois qui ne séparent pas les mots avec des espaces.
Pour cela, il y a des segmenteurs (comme tinysegmenter que je maintiens aussi mais n'ai pas touché depuis longtemps).
En tous les cas, oui, utiliser une liste limitée des mots (pas tous les mots) très utilisés statistiquement dans un langage peut être très intéressant pour compléter d'autres méthodes de détection (uchardet lui-même combine plusieurs méthodes de détection d'ailleurs) et donner une note globale de "confiance" dans un résultat de détection.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Automatisme ?!?
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Let’s Encrypt en bêta : petit retour d’expérience. Évalué à 2.
Vous avez raison, c'est assez vulnérable.
Le vrai problème est que la plupart des gens veulent quelque chose de peu cher et rapide, voire quasi instantané (tout en parlant sécurité). Donc les CAs font des vérifs de ce genre passant par le DNS (un autre classique est aussi d'envoyer une vérif par email à une des adresses enregistrées pour ce domaine dans le DNS, ce qui est aussi tout à fait vulnérable à une interception).
Le top de la sécurité serait bien entendu que deux personnes (un représentant le domaine, l'autre le CA) se rencontrent en vrai, physiquement, pour s'échanger des informations d'identité puis — si tout semble en ordre — des infos d'identification au service. Mais ça prendrait du temps, et surtout ça coûterait une blinde (le temps humain est ce qui coûte le plus cher!). Cela va à l'encontre du besoin.
Donc des compromis sont faits. De toutes façons peu de gens comprennent vraiment ce qu'ils font avec HTTPS, même ceux qui sont payés pour cela.
Pour minimiser le risque ceci dit, la vérification de présence du fichier est faite sur le serveur en https (c'est à dire https://example.com, et non http://example.com). Voir la page d'explication des technos. Donc tant que le renouvellement se fait avec un certificat encore valide (ce devrait être le cas, puisqu'automatique), cela assure une certaine sécurité. Le risque de MITM n'apparaît donc qu'à la demande initiale. Bien sūr, l'attaquant pourrait alors demander à passer par un canal moins sécurisé (comme un enregistrement DNS), et ce serait donc bien si un possesseur/administrateur de domaine avait la possibilité de bloquer certains canaux de vérification.
Dans tous les cas, oui. Il y a toujours à un moment donné au moins 1 instant (l'échange initial) où la sécurité est faible et sujette à attaque si toutes communications passent par Internet. C'est le coût de tout faire à distance et c'est la raison pour laquelle les geeks sécurité font des "key signing party" pour s'échanger et signer leurs clés personnelles avec rencontre physique et vérification d'identité, afin d'éliminer ce risque de l'échange initial.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Est-ce ouvert au visiteur ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Le Paris Open Source Summit arrive et LinuxFr.org sera là ! #OSSParis15. Évalué à 2.
Il me semble n'être encore jamais venu à l'Open World Forum ou Solutions Linux (maintenant Open Source Summit), mais de ce que j'en entends dire et de la façon dont ils se présentent eux-même, c'est un évènement clairement orienté professionnel.
Par conséquent, je pense même que venir avec des CVs est bien vu, si tu cherches du boulot dans l'Open Source.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Caramba ! Encore râté !
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Le Capitole du Libre 2015 n'est plus, vive le Bazar du libre !. Évalué à 5.
On devait y être pour présenter le projet de film d'animation ZeMarmot. ;-(
Je viens d'appeler notre contact, et on nous a dit qu'ils allaient faire une réunion des organisateurs ce soir pour voir s'il n'y a pas possibilité de trouver un autre lieu pour faire tout de même une rencontre plus informelle ("à l'arrache"). Donc tout n'est pas perdu, même s'il vaut mieux ne pas se faire trop d'illusion.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Wikipedia ....
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Quadrature Du Net !. Évalué à 6. Dernière modification le 11 novembre 2015 à 15:55.
En même temps, ton "mendiant" (Wikipédia), tu es encore une fois allé le voir de toi-même pour lui redemander une autre information, comme il connaît tellement bien tout cela. Sans cela, tu n'aurais pas eu à subir sa "pub". C'est pas comme si t'étais tranquillement assis sur un banc et qu'il est venu te chercher (Wikipédia ne se connecte pas à ton ordi inopinément!). C'est l'inverse.
Je ne suis pas à 100% à fond pour leur technique de campagne (ce n'est pas de la pub à propos!), et je la trouve un peu intrusive aussi. Et il y a clairement des choses à faire pour l'améliorer. En même temps, je ne vais pas cracher sur eux. Ça reste une fondation à but non lucrative qui fait des choses que je trouve extraordinaires et a réellement changé notre vision de l'encyclopédie et du partage de connaissance. Je me souviens encore quand j'étais petit, les gens ne juraient que par certaines grosses encyclopédies qui venaient en 50 volumes et coûtaient des fortunes. Puis y a eu des encyclopédies numériques comme Encarta et surtout Universalis (qui si je me souviens bien coûtait des milliers d'euros!).
C'était vraiment la connaissance réservée aux riches. Wikipédia a vraiment fait quelque chose d'assez grandiose dans ce domaine.
Donc tant qu'ils ne reviennent pas sur ces principes de la connaissance pour tous, alors je peux supporter quelques bandeaux une fois par an (et je donnerais si j'avais un salaire. Ce que j'ai déjà fait par le passé).
Donc oui, leur méthode de demande de don pourrait être améliorée. Peut-être qu'ils tâtonnent pour trouver la méthode idéale. Peut-être même qu'ils sont tous les ans proches de l'extinction car ils ont du mal à subvenir aux besoins du service proposé (ils sont quand même dans le top-10 des sites les plus vues au monde, c'est pas un petit serveur dans le placard qu'il faut pour soutenir la charge!) et que comme le problème se répète annuellement, ils se disent qu'ils veulent essayer quelque chose de différent l'an prochain. Donc ils essaient de nouveaux modes de demande de donation, un peu plus visibles en se disant qu'au moins ainsi les gens ignoreront moins.
Ils pourraient aussi engager du personnel marketing experts en techniques de démarchages plus subtiles, car ils connaissent tous les trucs pour soulager la bourse des gens sans même qu'ils s'en rendent compte. En même temps, s'ils utilisaient tout leur argent donné dans ce genre de pratique pour faire plaisir aux donateurs et les rendre confortables sans leur mettre un peu les yeux en face des trous de temps en temps, c'est là où je serais pas content.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Wikipedia ....
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Quadrature Du Net !. Évalué à 6.
Ce mendiant t'a-t-il donné des informations à chaque fois que tu en avais besoin et que tu allais lui demander toute l'année et gratuitement?
Je pense que c'est là la grosse différence. :)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Bibinaire
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Parlons XMPP - épisode 9 - copie de fichiers et Jingle. Évalué à 2.
Ah ça c'est fort probable. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Bibinaire
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Parlons XMPP - épisode 9 - copie de fichiers et Jingle. Évalué à 4. Dernière modification le 05 novembre 2015 à 18:03.
Je comprends pas de quoi tu parles et le rapport avec la discussion. XMPP est indépendant de la couche de transport, qui est en effet TCP par défaut, mais peut-être ce que tu veux d'autre. Par exemple, y a du XMPP over BOSH (cad HTTP).
C'est même explicitement décrit dans la RFC 6120:
Si tu parles de la couche de transport pour les données, ben c'est aussi exactement ce que fait XMPP avec Jingle! Le protocole permet de définir divers transports, avec des connexions directs TCP, UDP, ou ce que tu veux, en passant par des intermédiaires ou en direct, etc. Et avec du transport inline dans XMPP en dernier recours.
Bon je peux dire une connerie car je connais pas Mumble et j'ai pas le temps ni l'envie de regarder en détail, mais la citation que tu fais… ben c'est exactement ce que fait XMPP et ce que je dis plus haut (bon sauf que XMPP fait bien plus que juste ces deux cas). Là ils semblent dire que la connexion UDP est le comportement par défaut, mais qu'elle peut être remplacée par la connexion TCP existante (j'imagine si l'établissement de la seconde connexion échoue). Ben c'est ce que fait XMPP avec son fallback inline.
Mais au final dans Mumble aussi, ils sont donc probablement conscients que si possible, ils préfèrent utiliser une connexion séparée.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Pièce jointe
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Parlons XMPP - épisode 9 - copie de fichiers et Jingle. Évalué à 3.
Salut,
Je sais pas si ça existe, mais le problème est qu'un fichier, ça prend de la place. Quand tu transfères d'un compte à l'autre, ça n'utilise que de la bande passante. Si tu te mets à joindre des fichiers "en attente de connexion", faut bien le stocker quelque part, c'est à dire sur un des serveurs du fournisseur de service (sur celui de l'envoyeur ou du destinataire d'ailleurs?!).
En plus, beaucoup d'utilisateurs sur n'importe quel service sont des fantômes (ils s'inscrivent, utilisent — ou non — un temps, puis un jour ne reviennent jamais), donc ça peut entraîner des quantités phénoménales de données stockées qui ne désemplissent jamais avec le temps quand les destinataires ne se re-connectent jamais.
Donc au final, les fournisseurs de service en viennent rapidement à limiter. Va envoyer un fichier de 100 Go par email! Peu de services email (probablement aucun dans les services commerciaux) n'autoriseront. Prenons gmail par exemple, ils limitent à 25 Mo. Et même si votre fournisseur autorisait de grosses tailles, il n'est pas dit que le fournisseur du destinataire accepte l'email s'il a une limite inférieure! Tout de suite, ça limite.
Au final, le concept de pièce jointe reste intéressant mais très limité comparé à du transfert direct où on peut envoyer n'importe quelle taille. Ce ne sera jamais le protocole qui limitera sur le sujet, mais les implémentations car c'est un nid à problème.
Mais sinon oui, pour des petits fichiers, ce serait une fonctionnalité intéressante (si ça n'existe pas déjà), mais je préfèrerais voir le transfert de fichier direct marcher de façon fiable d'abord. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Bibinaire
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Parlons XMPP - épisode 9 - copie de fichiers et Jingle. Évalué à 7.
Aucun protocole moderne digne de ce nom ne prévoirait d'utiliser le canal principal pour l'échange binaire! Un échange binaire sur le même canal implique de bloquer la connexion le temps du transfert. Même le vieux ftp, qui est un protocole à la base fait pour transférer des fichiers (donc on pourrait naïvement penser "autant tout faire dans la même connexion: contrôles et transferts!") ouvre une connexion de données séparées, ce qui permet de continuer à naviguer dans l'arborescence et d'exécuter diverses commandes de contrôle.
Bien sûr, on peut aménager le protocole pour ne pas bloquer la connexion, par exemple en coupant en petits bouts le fichier (permettant pleins de petits transferts entre lesquelles des commandes peuvent se placer). Néanmoins cela a pour conséquence de donner une sensation de ralentissement à la fois du transfert (envoyer pleins de petits bouts avec des caractères de contrôle à chaque fois est plus lent qu'envoyer en un bloc) mais aussi le flux non binaire (si on doit constamment attendre le chargement d'un bout binaire, même les messages textes pourraient se mettre à prendre quelques secondes le temps que le bout en cours se termine).
Et c'est sans compter que ça oblige en général de réencoder (par ex avec base64 dans XMPP) parce qu'on ne contrôle pas le contenu d'un binaire et que le mettre direct dans le flux cassera ce dernier chaque fois qu'un contenu de fichier utilise un caractère de contrôle du protocole. Donc le fichier à envoyer est plus gros (de l'ordre du tiers avec base64, de mémoire, ce qui n'est pas rien si on envoie de très gros fichiers!). Ça rallonge d'autant la durée du transfert.
Tout ça, c'est vraiment se faire chier pour rien alors que les connexions, de nos jours, sont tout à fait capables d'encaisser même plusieurs transferts de fichiers en parallèle à pleine vitesse chacune sur leur canal, tout en gardant un canal de contrôle non-encombré, parfaitement fluide et rapide aussi.
Donc non, franchement un protocole qui commencerait avec l'idée de tout faire dans le même canal, j'aurais pas confiance. Ça ne peut pas monter en charge notamment.
Par contre oui, comme solution de secours si on n'arrive pas à initier un canal binaire, ça ok, en bridant si besoin le transfert pour pas qu'il gêne trop le reste de l'expérience utilisateurs. C'est d'ailleurs ce que fait XMPP.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Aryeom, ZeMarmot, LILA…
Posté par Jehan (site web personnel, Mastodon) . En réponse au message graphisme libre. Évalué à 2.
Puisque les gens y vont des petites pubs, y a aussi Aryeom Han qui travaille exclusivement sous Linux avec des Logiciels Libres dernièrement. Voir notre film ZeMarmot: http://film.zemarmot.net/
Mais on n'a pas de forum. Par rapport à ce besoin en particulier, je rejoins la réponse plus haut au sujet de http://linuxgraphic.org.
Par contre nous participons à une association, LILA, avec des vrais gens qu'on peut rencontrer en chair et en os, sur Paris: http://libreart.info/
Mais on peine un peu à intéresser les gens.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Mise en avant
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Libervia/Salut à Toi : campagne pour une version Android et de bureau. Évalué à 2. Dernière modification le 28 octobre 2015 à 22:44.
Vous devriez demander sur la "Tribune de rédaction". :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Et une carte Compact Flash?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche ddrescue, dd_rescue, myrescue : récupérer ses données après un crash disque. Évalué à 2.
Salut,
Pourrais-tu être plus explicite stp? L'article ci-dessus ne parle pas de l'utilisation de mknod.
Alors je comprends que
mknodsert à créer le fichier périphérique sous /dev/, et que donc tu me dis que cela permet de le créer manuellement et donc d'accéder à ma carte malgré que mon kernel ne semble pas le voir de lui-même.Mais alors j'ai beau regarder la page man et diverses pages, je trouve aucune info (ou alors anciennes et plus à jour) qui m'aide à comprendre comment on choisit les paramètres.
Si t'as une référence qui explique bien comment cela marche, je suis preneur.
Je pense que je suis pas assez ancien! :P
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# USB bootable?
Posté par Jehan (site web personnel, Mastodon) . En réponse au message cd d ubuntu envoie au maroc ?. Évalué à 5.
Salut,
Tu as essayé de formatter une clé USB avec ton image iso et de booter dessus?
Cela fait des années que je n'ai plus gravé de CD. Si j'ai besoin d'un périphérique bootable, je mets dans une clé USB. C'est plus simple, tu ne gâches pas de CD, tu peux réutiliser (plus qu'un CD réinscriptible), ça prend moins de place, tu peux même ajouter d'autres données dessus facilement, etc.
Y a plein de doc sur le web, c'est facile à faire, par exemple: https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB
Perso j'utilise la méthode avec la commande console
dd. Par contre faut bien comprendre ce qu'on fait, car si tu te plantes de périphérique, tu peux te retrouver à effacer ton disque dur! Les logiciels graphiques sont peut-être plus sûr si tu ne comprends pas bien les tenants et aboutissants.Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Et une carte Compact Flash?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche ddrescue, dd_rescue, myrescue : récupérer ses données après un crash disque. Évalué à 3.
Est-ce que la récupération de données marche pour une carte Compact Flash?
Et surtout, l'OS ne semble même plus la voir! Si je l'insère dans le lecteur, rien ne se passe, rien dans dmesg non plus. Donc a priori, je ne pense pas qu'un périphérique sous /dev/ lui est associé.
Quelles sont les possibilités dans un tel cas?
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: pub
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal « Les Nouveaux Loups du Web » : le doc qui dénonce les CGU déloyales (mais pas que).. Évalué à 7.
C'est assez ironique, non? Ils font un doc sur les plateformes à CGUs déloyales et ils ne comprennent pas pourquoi vous préféreriez diffuser ailleurs que sur les dites plateformes?
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]