Les recettes publicitaires que les journaux se font, ça ça bouge pas. De l'autre côté, Google via sa galaxie de services se fait des sous quand un utilisateur se balade sur Google News puis cherche une information qui l'intéresse dans la barre de recherche. C'est là (entre autres) que Google se fait de l'argent, et c'est une partie de cet argent que les journaux voulaient.
J'utilise peut-être mal le terme "gâteau", c'est vrai, "butin" est plus proche ?
ils trouvent que c'est anormal que Google profite d'eux
Pas du tout. Ils comprennent très bien que Google gagne à faire Google News, et que les journaux gagnent à ce que Google News existe. Ce qu'ils voulaient c'est une part du gâteau que Google mange, en prétextant avoir un levier de discussion en étant source, et en jouant avec leur proximité avec le gouvernement.
Ce qu'ils n'ont pas compris c'est qui avait les vrais leviers pour discuter. En gros, ils n'ont pas analysés correctement la situation. Ils ont voulu jouer, ils ont perdu, panpan dans le c*l.
Non, pas "peu importe". Là on parle du système offert par l'école, pour l'utilisation dans l'école donc. On peut faire le parallèle avec l'adresse mail offerte par une boite à ses employés, et je suis d'avis que cette adresse n'appartient pas à l'étudiant/employé mais bien à la boite, et que donc ce qu'il se passe dessus reste sous le contrôle de la boite/de l'école.
Si les étudiants veulent utiliser l'adresse de leur école pour des choses personnelles, ils doivent bien comprendre que c'est une erreur parce qu'ils n'ont pas le contrôle dessus. Cette adresse leur a été fournie dans un cadre précis.
Ce qu'il faut, c'est une bonne grosse dose d'éducation pour bien se mettre ça dans le crâne, et encore un peu plus pour chiffrer ses mails si on veut vraiment pas faire l'effort d'utiliser une deuxième adresse pour les conversations privées.
Oh et puis franchement, à l'ère d'internet, penser naïvement que les données seront automatiquement effacées au bout de X années parce que c'est la loi dans tel pays… c'est mal comprendre comment internet marche.
Tu étais pour moi le fervent défenseur de fossil. Que s'est-il passé ? fossil a-t-il mangé toutes tes données ? Est-ce que tu souhaitais leverager ton code source et le faire rentrer dans une pratique de gestion lean de développement horizontal plus adapté aux best practices de l'industrie ?
Et c'est pas grave: que le code soit ouvert ou ferme il n'entre pas dans la chaine de confiance, de la même manière que les routeurs entre le client et le serveur n'entrent pas dans la chaine de confiance. Si le code est ferme c'est pas grave.
En allant plus loin, c'est même un avantage que l'ouverture du code ne soit pas nécessaire: si le protocole est suffisamment compréhensible au point que les détails d'implémentation du serveur importent peu, ça veut dire que n'importe qui, particulier comme entreprise, peut fournir un service équivalent.
Par contre, on est d'accord sur le fait qu'avoir le code client soit nécessaire pour pouvoir garantir un minimum de sécurité.
Ben justement, si c'est du chiffrement de bout en bout ça veut dire qu'on s'en balance complet du code du serveur, puisque le chiffrement et la sécurité ne reposent pas dessus. Tout ce qu'on veut c'est un audit du code client + une manière d’être sur que c'est bien ce code-la et pas un autre qui tourne (et ça, ça va être difficile avec du code dans le navigateur)
Ce qui serait bien, c'est que les serveurs d'annuaires puissent communiquer entre eux, pour que si tu contacts l'un deux, il puisse te mettre en relation avec un utilisateur qui est enregistré sur un autre serveur. Bref un truc à la SMTP/XMPP, coté serveur
Euh non, les serveurs SMTP et XMPP ont la possibilité de communiquer entre eux parce que le client donne explicitement l'adresse du destinataire. On pourrait imaginer que les clients WebRTC aient une identité par serveur (@talky.io, @mozilla.com…) et que pour contacter quelqu'un tu tentes le serveur de rendez-vous indiqué dans l'adresse.
Si tu veux que ça soit automatique sans que l'utilisateur n'ait d'adresse en @qqch.com, il faut que tous les serveurs soient connectes ensembles (pas forcement 1 connexion par serveur hein, l'important est qu'il y ait un chemin d'un serveur a un autre) pour que la requête puisse être routée la ou il faut… et dans ce cas on se rapproche d'un système a la IRC. Le problème d'IRC c'est que la fédération de serveur en réseau est assez politique, et a l’échelle planétaire on n'a pas été capable de garder un seul et unique réseau, du coup chacun des réseaux aujourd'hui est comme un ilot, isole des autres.
Je te laisse imaginer ce qu'il se passerait si des entreprises entraient dans la danse.
OpenSSL via Heartbleed joue effectivement avec la mémoire, un peu trop même, et ce un peu trop aurait du être détecté par des outils de vérification qui font vachement gaffe a tout ce qui se passe sur la machine… sauf qu'OpenSSL a décidé de ne pas utiliser les outils standards et de ré-implémenter son propre malloc, qui ne pouvait donc pas être contrôlé par ces outils.
Déjà, ré-implémenter*malloc*, faut le faire… mais quand en plus la raison est que le malloc originel était trop lent sur une certaine plateforme (qui n'existe même plus de toute façon), la, c'est trop.
Car franchement, se prendre des erreurs à l'exécution qui n'auraient pas dépassé la phase de compilation en Java, c'est pénible
Facebook est sur la bonne lancée en ce moment. Après avoir lancé HHVM, le compilateur qui fournit du typage statique et des performances de malade à du PHP, après avoir réutilisé ces connaissances pour créer React et JSX et du coup fournir de la vérification syntaxique au HTML, vlà-ty pas qu'ils sortent Flow, un analyseur syntaxique pour javascript. J'ai pas essayé, mais pour ceux qui en ont marre de se taper des erreurs au runtime, ça devrait être intéressant.
Gros avantage par rapport aux typescript, atscript et autres articulations: ça n'est ni un nouveau langage, ni un système d'annotations à rajouter au code. Ça fonctionne avec du javascript absolument standard.
Je ne comprends même pas l’intérêt qu’il y a taper apt-get au lieu de pacman ou de yum, tout ça pour installer les mêmes logiciels que les autres
La raison n'est pas tant dans le logiciel utilisé mais dans la manière dont les paquets sont intégrés dans les repo de la distribution ou que tu as ajouté manuellement:
Archlinux accepte à peu près tout du moment que ça builde (en tout cas dans AUR), puis ça peut monter graduellement dans community jusqu'à core en fonction de l'utilité
Debian met un accent énorme sur la stabilité des paquets, quitte à être plusieurs versions de retard par rapport à upstream (surtout qu'ils sont à peu près tous bénévoles donc le travail d'intégration est fait en fonction de qui a le temps de bosser dessus le soir après le boulot)
Red Hat est une boîte commerciale. Les paquets inclus dans les repos doivent bien entendu être stables, mais je pense ne pas m'avance trop en disant que les clients de Red Hat ont sans doute plus de poids dans la décision des paquets inclus par défaut, et que Red Hat a sans doute beaucoup plus de moyens pour faire avancer les choses dans leur distribution que Debian.
Tout le problème vient de l'intégration entre les paquets et la gestion des dépendances, qui est différente dans chaque distribution… heureusement, Lennart a un plan pour ça.
A une époque j'utilisais Certificate Patrol, qui si mes souvenirs sont bons te disaient si le certificat pour un même hostname changeait. C'est considéré comme une mauvaise pratique, mais a la longue il y a du y avoir peut-être 1 site sur 100 qui faisait les choses correctement, pour tous les autres j'ai du accepter a la mano chaque certificat a chaque fois qu'il changeait…
Au final j'ai vite compris que l’authenticité offerte par le système est inutile si tu vérifies pas correctement (ce que le navigateur ne fait pas par défaut), et vue que je me retrouvais a tout accepter sans regarder, autant ne plus faire confiance a personne.
A mon avis, c'est plutôt "Rust est a Go ce que C++ est a Java".
Rust se veut être un langage oriente performances, qui donne un maximum de contrôle au développeur pour qu'il sache exactement ce qui se passe sur la machine, tout en le contraignant a ne pas faire des choses dangereuses. Si on veut écrire un programme embarque, ou temps-réel (au vrai sens du terme), c'est a mon avis l'outil qu'il faut utiliser.
Go, a l'inverse, est plus un langage dont le but est "Simple et efficace". Rien d'extraordinaire au niveaux des fonctionnalités, le plus innovant c'est les goroutines et tout ce qui tourne autour, qui ne sont pas une idée nouvelle mais juste implémentée de manière a ce que ça soit simple a utiliser. Ce que Go propose et qui est beaucoup plus intéressant, ce sont les a-cotes: les outils pour le programmeur, un déploiement simplifié, une compilation rapide… Bref, un langage qui répond plus que bien a 80-90% des besoins, et qui peut facilement être pris en cours de route par n'importe qui ayant bidouillé quelques lignes dans un langage C-like. Pour le reste, il y a possibilité de linker avec un bout de code en C.
Go a été créé entre autres comme langage a utiliser par défaut chez Google, non pas pour ses fonctionnalités, mais pour son rapport performance/facilite d'utilisation a échelle Google (que ni Java, ni C++, ni Python, les langages de prédilection, n'atteignent)
Du coup les deux langages sont beaucoup plus complémentaires qu'autre chose, ils n'ont pas du tout le même but. A mon avis ils sont mis en opposition sur des projets pour lesquels ni l'un ni l'autre n'apporte d'avantage énorme, du coup c'est pas simple de savoir lequel est le meilleur dans ce cas la. Mais si tu dois écrire un service qui coordonnent des requêtes de client pour des actions potentiellement longues, ou un moteur de rendu pour jeu video, le choix devrait être assez simple dans chacun des cas.
C'est très joli et a plutôt l'air de faire son boulot, mais l'interface d'édition n'est pas intuitive: On a par défaut un Form et un Paragraphe, et il faut cliquer sur les boutons à gauche pour ajouter un élément. Pour les différencier il faut passer la souris dessus pour voir les limites.. Mais ça ne montre que l'actuel pas les autres. Ça serait sympa d'avoir un cadre autour de chaque élément.
2e remarque: Il aurait été plus intuitif d'avoir un élément fictif vide à l'endroit où on ajoute des éléments, qui contiendrait la liste des éléments ajoutables, de manière a ce que lorsque je clique sur "Add Paragraph", l'élément fictif devienne un paragraphe. Comme ça on sait où son paragraphe est ajouté. En plus de ça cet élément fictif pourrait être mis à n'importe quel endroit, de sorte qu'on ne soit pas obligé de rajouter à la fin (mais au milieu aussi). En plus de ça, dans la version actuelle si le formulaire est trop long la barre de boutons de gauche ne suit pas le curseur, du coup il faut scroller à chaque fois.
J'ai naïvement voulu jeter un coup d’œil à l'étude. Quelle ne fut pas ma surprise de voir ceci:
Buy this report for $7,000
C'est dommage, j'aurais aimé voir s'ils avaient intégré ARM (la boîte) dans l'analyse. Parce que si ARM vend/licence (indirectement) les processeurs de 90% des machines, ça vaut le coup de voir où ils sont dans la grille, surtout pour comparer à Intel.
Bon et sinon la recopie des rumeurs sans vérification journalistique, ça n'a plus rien de nouveau.
Je ne suis pas un expert, mais si c'est pas écrit par des cryptographes reconnus et audités, c'est plus une faille de sécurité qu'autre chose. Du coup je vais rediriger vers Daniel Bernstein (ici) où il explique bien que du code qu'on a écrit soi-même pour tenter de générer de l'aléatoire est plus que dangereux: ça permet à un attaqueur d'influer sur les paramètres "secrets", qui sont en fait tout à fait exploitables par cet attaqueur… sans être détectables par la victime (puisque de loin ça a toujours l'air aléatoire).
Moralité: si vous devez générer de l'aléatoire, lisez /dev/urandom. Rien de plus, rien de moins.
Je ne connais pas grand monde qui se plaint de ce système.
En fait, en creusant plus loin et en ouvrant son Guide de la théorie des complots, on pourrait même dire qu'il y a des gens à qui ça ferait plaisir qu'on paie plus vite et plus facilement, parce que le consommateur serait alors plus enclin à faire encore plus de transactions, tu comprends, c'est tellement simple. Plus de consommation, plus d'argent dépensé, plus de sous qui rentrent pour les intermédiaires…
Sérieusement, je doute fortement que Zwipe ait été créé pour répondre à un besoin des clients/consommateurs, mais plutôt pour pas perdre l'avance énorme qu'ils ont encore face aux Google/Apple qui veulent mettre leur nez dans le business.
fournir du contenu moyen, et y coller des publicités, ça me semble totalement irréaliste.
Et pourtant, c'est le business model d'à peu près tous les médias de diffusion libre: radio, télé, sites web voire internet.
La différence avec internet c'est qu'on a enfin un moyen d'éviter les pubs, alors qu'avant on ne pouvait que se les farcir; on a donc enfin la possibilité de se poser la question "est-ce que ce service vaut la peine ? Est-ce que je veux bien lui donner de l'argent même si ça doit passer par la pub ?"
Et encore: là on parle entre nous, c’est-à-dire des gens qui ont les connaissances nécessaire pour savoir comment zapper les pubs, la grande grande majorité des utilisateurs les laissent passer dans un mélange de flemme/manque de connaissance/ça-me-dérange-pas. Du coup je pense que le modèle a encore un peu de temps devant lui même si ça commence à devenir chaud.
Mouais. Même si on partait du principe que LO remplissait les critères, je pense qu'on peut quand même inclure une formation. En plus de ça si support (avec contrat, hein) il y a, ça compte aussi.
Et en fait c'est valable pour 1 comme pour 2, indépendamment de la licence.
Je rêve ! On est bien en train d'assister a un concours de kekettes sur le temps de compilation d'un programme tellement trivial qu'il n'est pas représentatif d'un vrai programme ?
Euh nan, configure et make doivent absolument être lancés en tant qu'utilisateur non privilégié; ça n'a absolument pas besoin de droits supplémentaires.
make install n'a besoin des droits root que si tu installes l'application dans les répertoires "OS", genre /usr, /bin et tout le tintouin. Si tu as configuré l'install pour se faire dans un répertoire dans lequel tu as les droits (genre /home/chezmoi/monappli), tu n'as pas besoin des droits root. Mais, c'est vrai, un petit malin peut très bien avoir placé une commande pas drôle dans la cible install.
De manière générale cette discussion me fait un peu peur sur l'état général des déploiements au grand large des applications et sur l'absence d'un moyen-qui-marche-à-tous-les-coups si on sort des moyens privilégiés de son OS…
Heureusement que tu précises que t'es pas énervé, parce qu'on pourrait croire le contraire :)
Débattons, débattons !
J'aimerais juste rappeler le point de départ de la discussion, qui est la question intéressante posée par devnewton:
si vous deviez refaire un protocole depuis 0 aujourd'hui, est-ce que vous aboutiriez à un XMPP like ou à complètement autre chose?
À laquelle je réponds "XMPP c'est top, ça juste marche dans les cas où on l'utilise le plus, c'est extensible, c'est ouvert, c'est implémenté de milles et une manières et ça a pas l'air de s’essouffler de ce coté là". Bref, c'est bien, il faut aller dans ce sens et améliorer l'existant plutôt que réinventer la roue. Je suis d'accord avec toi. Si on devait recommencer de 0, on pourrait garder une grosse grosse majorité de ce qu'on a déjà.
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 !
Maintenant, quelques précisions:
Sur le routage
Je persiste et signe, XMPP est un protocole de routage, clairement pas au sens de "routage de paquets IP", mais bien "routage de fragment XML". La différence est qu'une table de routage, c'est à dire l'ensemble des routeurs qu'un routeur connaît et à qui il est capable de parler, c'est l'ensemble des domaines qui ont un serveur.
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.
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, et inversement pour la diffusion (Note que cette fois ce qui est routé c'est pas un stanza entier, c'est le(s) item(s))
Cas un peu plus compliqué: je veux parler à quelqu'un sur IRC. Ma ressource -> mon serveur -> le serveur qui héberge la passerelle -> la passerelle (possiblement en tant que composant) -> IRC
Je vois XMPP comme étant capable de beaucoup plus que juste amener les stanza d'un client à un autre: par exemple si un domaine héberge un "serveur" XMPP sur un cluster de serveurs, ça serait vraiment bien d'utiliser XMPP de bout en bout. Ça permettrait par exemple de construire "facilement" des clusters en prenant n'importe quelle implémentation qui respecte les standards pour se faire son n-ième SecretWhatSnapLine, et ainsi faire avancer le protocole (soit en participant au réseau, soit en améliorant les outils existants).
Ça va vachement plus loin que SMTP, qui s'arrête au To, là on a potentiellement plusieurs niveaux de routage qui permettent un adressage vraiment fin.
Sur le binaire
J'ai l'impression que tu fais le raccourci "binaire => gros machin qui bouche le tuyau".
C'est très certainement vrai si tu utilises la manière naïve, qui est de tout mettre dans un gros paquet, ce qui est à mon sens sacrément stupide. Dans ce cas-là tu segmentes ton binaire, tu l'envoies morceau par morceau avec la possibilité pour les messages non-binaires de passer. Mais c'est vrai, ça veut aussi dire qu'un participant à une MUC peut envoyer des méga-gifs de chatons qui vont juste embêter tout le monde. Au fond je me disais juste "qui peut le plus peut le moins": si le protocole pouvait utiliser du binaire, il pourrait faire passer n'importe quoi par dessus, y compris du XML structuré comme ce qu'on a aujourd'hui, mais aussi du HTML sans avoir à l'échapper ou un message chiffré/signé sans avoir à le base64.
Sur le parsing
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 (de manière à poser quelques pointeurs qui permettent un accès rapide aux différents éléments). Sauf que si c'est un serveur, le "sens" qui l'intéresse, il s'arrête au to; le sens de ce qu'il y a en dessous c'est surtout pour le niveau suivant, par exemple le module de pubsub, qui potentiellement peut être sur un autre serveur (routage, encore). Dans ce cas là on aura 2 "analyses" complètes du message…
Plus généralement
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. Je crois que la seule bonne conclusion qu'on peut avoir c'est si on repartait de 0, on arriverait largement à la même chose.
[^] # Re: Le beurre et l'argent du beurre
Posté par rakoo (site web personnel) . En réponse au journal Google News quitte l'Espagne. Évalué à 3.
Les recettes publicitaires que les journaux se font, ça ça bouge pas. De l'autre côté, Google via sa galaxie de services se fait des sous quand un utilisateur se balade sur Google News puis cherche une information qui l'intéresse dans la barre de recherche. C'est là (entre autres) que Google se fait de l'argent, et c'est une partie de cet argent que les journaux voulaient.
J'utilise peut-être mal le terme "gâteau", c'est vrai, "butin" est plus proche ?
[^] # Re: Le beurre et l'argent du beurre
Posté par rakoo (site web personnel) . En réponse au journal Google News quitte l'Espagne. Évalué à 6.
Pas du tout. Ils comprennent très bien que Google gagne à faire Google News, et que les journaux gagnent à ce que Google News existe. Ce qu'ils voulaient c'est une part du gâteau que Google mange, en prétextant avoir un levier de discussion en étant source, et en jouant avec leur proximité avec le gouvernement.
Ce qu'ils n'ont pas compris c'est qui avait les vrais leviers pour discuter. En gros, ils n'ont pas analysés correctement la situation. Ils ont voulu jouer, ils ont perdu, panpan dans le c*l.
[^] # Re: Politique de conservation des emails
Posté par rakoo (site web personnel) . En réponse au journal Au secours, l'école Centrale Paris a donné mes mails à Microsoft !. Évalué à 4.
Non, pas "peu importe". Là on parle du système offert par l'école, pour l'utilisation dans l'école donc. On peut faire le parallèle avec l'adresse mail offerte par une boite à ses employés, et je suis d'avis que cette adresse n'appartient pas à l'étudiant/employé mais bien à la boite, et que donc ce qu'il se passe dessus reste sous le contrôle de la boite/de l'école.
Si les étudiants veulent utiliser l'adresse de leur école pour des choses personnelles, ils doivent bien comprendre que c'est une erreur parce qu'ils n'ont pas le contrôle dessus. Cette adresse leur a été fournie dans un cadre précis.
Ce qu'il faut, c'est une bonne grosse dose d'éducation pour bien se mettre ça dans le crâne, et encore un peu plus pour chiffrer ses mails si on veut vraiment pas faire l'effort d'utiliser une deuxième adresse pour les conversations privées.
Oh et puis franchement, à l'ère d'internet, penser naïvement que les données seront automatiquement effacées au bout de X années parce que c'est la loi dans tel pays… c'est mal comprendre comment internet marche.
# Un mythe s'effondre
Posté par rakoo (site web personnel) . En réponse au journal jb3, la tribune des beaux gosses. Évalué à 4.
Tu étais pour moi le fervent défenseur de fossil. Que s'est-il passé ? fossil a-t-il mangé toutes tes données ? Est-ce que tu souhaitais leverager ton code source et le faire rentrer dans une pratique de gestion lean de développement horizontal plus adapté aux best practices de l'industrie ?
[^] # Re: Idée de qualité
Posté par rakoo (site web personnel) . En réponse au journal La longue route de protonmail vers le libre. Évalué à 6.
Et c'est pas grave: que le code soit ouvert ou ferme il n'entre pas dans la chaine de confiance, de la même manière que les routeurs entre le client et le serveur n'entrent pas dans la chaine de confiance. Si le code est ferme c'est pas grave.
En allant plus loin, c'est même un avantage que l'ouverture du code ne soit pas nécessaire: si le protocole est suffisamment compréhensible au point que les détails d'implémentation du serveur importent peu, ça veut dire que n'importe qui, particulier comme entreprise, peut fournir un service équivalent.
Par contre, on est d'accord sur le fait qu'avoir le code client soit nécessaire pour pouvoir garantir un minimum de sécurité.
[^] # Re: Idée de qualité
Posté par rakoo (site web personnel) . En réponse au journal La longue route de protonmail vers le libre. Évalué à 3.
Ben justement, si c'est du chiffrement de bout en bout ça veut dire qu'on s'en balance complet du code du serveur, puisque le chiffrement et la sécurité ne reposent pas dessus. Tout ce qu'on veut c'est un audit du code client + une manière d’être sur que c'est bien ce code-la et pas un autre qui tourne (et ça, ça va être difficile avec du code dans le navigateur)
[^] # Re: Hello et TokBox business model ?
Posté par rakoo (site web personnel) . En réponse à la dépêche Firefox 34, ce Hérault. Évalué à 3.
Euh non, les serveurs SMTP et XMPP ont la possibilité de communiquer entre eux parce que le client donne explicitement l'adresse du destinataire. On pourrait imaginer que les clients WebRTC aient une identité par serveur (@talky.io, @mozilla.com…) et que pour contacter quelqu'un tu tentes le serveur de rendez-vous indiqué dans l'adresse.
Si tu veux que ça soit automatique sans que l'utilisateur n'ait d'adresse en @qqch.com, il faut que tous les serveurs soient connectes ensembles (pas forcement 1 connexion par serveur hein, l'important est qu'il y ait un chemin d'un serveur a un autre) pour que la requête puisse être routée la ou il faut… et dans ce cas on se rapproche d'un système a la IRC. Le problème d'IRC c'est que la fédération de serveur en réseau est assez politique, et a l’échelle planétaire on n'a pas été capable de garder un seul et unique réseau, du coup chacun des réseaux aujourd'hui est comme un ilot, isole des autres.
Je te laisse imaginer ce qu'il se passerait si des entreprises entraient dans la danse.
# Petite précision
Posté par rakoo (site web personnel) . En réponse à la dépêche LibreSSL 2 est bien lancé. Évalué à 10.
Les évènements sont arrivés dans une période de temps assez courte, mais ca s'est pas passe exactement comme ca
OpenSSL via Heartbleed joue effectivement avec la mémoire, un peu trop même, et ce un peu trop aurait du être détecté par des outils de vérification qui font vachement gaffe a tout ce qui se passe sur la machine… sauf qu'OpenSSL a décidé de ne pas utiliser les outils standards et de ré-implémenter son propre malloc, qui ne pouvait donc pas être contrôlé par ces outils.
Déjà, ré-implémenter*malloc*, faut le faire… mais quand en plus la raison est que le malloc originel était trop lent sur une certaine plateforme (qui n'existe même plus de toute façon), la, c'est trop.
# Tout vient à point à qui sait attendre
Posté par rakoo (site web personnel) . En réponse au journal J'ai testé pour vous : la création d'un jeu pour Firefox OS. Évalué à 10. Dernière modification le 30 novembre 2014 à 16:29.
Facebook est sur la bonne lancée en ce moment. Après avoir lancé HHVM, le compilateur qui fournit du typage statique et des performances de malade à du PHP, après avoir réutilisé ces connaissances pour créer React et JSX et du coup fournir de la vérification syntaxique au HTML, vlà-ty pas qu'ils sortent Flow, un analyseur syntaxique pour javascript. J'ai pas essayé, mais pour ceux qui en ont marre de se taper des erreurs au runtime, ça devrait être intéressant.
Gros avantage par rapport aux typescript, atscript et autres articulations: ça n'est ni un nouveau langage, ni un système d'annotations à rajouter au code. Ça fonctionne avec du javascript absolument standard.
[^] # Re: Le choc ?
Posté par rakoo (site web personnel) . En réponse au journal Devuan forks Debian: un choc ou c'était inévitable?. Évalué à 5.
La raison n'est pas tant dans le logiciel utilisé mais dans la manière dont les paquets sont intégrés dans les repo de la distribution ou que tu as ajouté manuellement:
Tout le problème vient de l'intégration entre les paquets et la gestion des dépendances, qui est différente dans chaque distribution… heureusement, Lennart a un plan pour ça.
[^] # Re: auto signé
Posté par rakoo (site web personnel) . En réponse au sondage Comme autorité de certification pour linuxfr.org je préfèrerais.... Évalué à 4.
A une époque j'utilisais Certificate Patrol, qui si mes souvenirs sont bons te disaient si le certificat pour un même hostname changeait. C'est considéré comme une mauvaise pratique, mais a la longue il y a du y avoir peut-être 1 site sur 100 qui faisait les choses correctement, pour tous les autres j'ai du accepter a la mano chaque certificat a chaque fois qu'il changeait…
Au final j'ai vite compris que l’authenticité offerte par le système est inutile si tu vérifies pas correctement (ce que le navigateur ne fait pas par défaut), et vue que je me retrouvais a tout accepter sans regarder, autant ne plus faire confiance a personne.
[^] # Re: Rust vs Go
Posté par rakoo (site web personnel) . En réponse à la dépêche Rust 0.12 : non, pas le jeu vidéo, le langage !. Évalué à 10.
A mon avis, c'est plutôt "Rust est a Go ce que C++ est a Java".
Rust se veut être un langage oriente performances, qui donne un maximum de contrôle au développeur pour qu'il sache exactement ce qui se passe sur la machine, tout en le contraignant a ne pas faire des choses dangereuses. Si on veut écrire un programme embarque, ou temps-réel (au vrai sens du terme), c'est a mon avis l'outil qu'il faut utiliser.
Go, a l'inverse, est plus un langage dont le but est "Simple et efficace". Rien d'extraordinaire au niveaux des fonctionnalités, le plus innovant c'est les goroutines et tout ce qui tourne autour, qui ne sont pas une idée nouvelle mais juste implémentée de manière a ce que ça soit simple a utiliser. Ce que Go propose et qui est beaucoup plus intéressant, ce sont les a-cotes: les outils pour le programmeur, un déploiement simplifié, une compilation rapide… Bref, un langage qui répond plus que bien a 80-90% des besoins, et qui peut facilement être pris en cours de route par n'importe qui ayant bidouillé quelques lignes dans un langage C-like. Pour le reste, il y a possibilité de linker avec un bout de code en C.
Go a été créé entre autres comme langage a utiliser par défaut chez Google, non pas pour ses fonctionnalités, mais pour son rapport performance/facilite d'utilisation a échelle Google (que ni Java, ni C++, ni Python, les langages de prédilection, n'atteignent)
Du coup les deux langages sont beaucoup plus complémentaires qu'autre chose, ils n'ont pas du tout le même but. A mon avis ils sont mis en opposition sur des projets pour lesquels ni l'un ni l'autre n'apporte d'avantage énorme, du coup c'est pas simple de savoir lequel est le meilleur dans ce cas la. Mais si tu dois écrire un service qui coordonnent des requêtes de client pour des actions potentiellement longues, ou un moteur de rendu pour jeu video, le choix devrait être assez simple dans chacun des cas.
# Joli mais pas très intuitif
Posté par rakoo (site web personnel) . En réponse au journal Un générateur de formulaire qui vise à remplacer google forms. Évalué à 7.
C'est très joli et a plutôt l'air de faire son boulot, mais l'interface d'édition n'est pas intuitive: On a par défaut un Form et un Paragraphe, et il faut cliquer sur les boutons à gauche pour ajouter un élément. Pour les différencier il faut passer la souris dessus pour voir les limites.. Mais ça ne montre que l'actuel pas les autres. Ça serait sympa d'avoir un cadre autour de chaque élément.
2e remarque: Il aurait été plus intuitif d'avoir un élément fictif vide à l'endroit où on ajoute des éléments, qui contiendrait la liste des éléments ajoutables, de manière a ce que lorsque je clique sur "Add Paragraph", l'élément fictif devienne un paragraphe. Comme ça on sait où son paragraphe est ajouté. En plus de ça cet élément fictif pourrait être mis à n'importe quel endroit, de sorte qu'on ne soit pas obligé de rajouter à la fin (mais au milieu aussi). En plus de ça, dans la version actuelle si le formulaire est trop long la barre de boutons de gauche ne suit pas le curseur, du coup il faut scroller à chaque fois.
Joli boulot en tout cas !
# Et ARM ?
Posté par rakoo (site web personnel) . En réponse au journal Intel leader sur tablettes Android ! Mon oeil !. Évalué à 8.
J'ai naïvement voulu jeter un coup d’œil à l'étude. Quelle ne fut pas ma surprise de voir ceci:
C'est dommage, j'aurais aimé voir s'ils avaient intégré ARM (la boîte) dans l'analyse. Parce que si ARM vend/licence (indirectement) les processeurs de 90% des machines, ça vaut le coup de voir où ils sont dans la grille, surtout pour comparer à Intel.
Bon et sinon la recopie des rumeurs sans vérification journalistique, ça n'a plus rien de nouveau.
[^] # Re: Code
Posté par rakoo (site web personnel) . En réponse au journal Que penses-tu du service mail Mailden ?. Évalué à 4.
Je ne suis pas un expert, mais si c'est pas écrit par des cryptographes reconnus et audités, c'est plus une faille de sécurité qu'autre chose. Du coup je vais rediriger vers Daniel Bernstein (ici) où il explique bien que du code qu'on a écrit soi-même pour tenter de générer de l'aléatoire est plus que dangereux: ça permet à un attaqueur d'influer sur les paramètres "secrets", qui sont en fait tout à fait exploitables par cet attaqueur… sans être détectables par la victime (puisque de loin ça a toujours l'air aléatoire).
Moralité: si vous devez générer de l'aléatoire, lisez
/dev/urandom. Rien de plus, rien de moins.[^] # Re: Gandhi
Posté par rakoo (site web personnel) . En réponse au journal Les temps changent ?. Évalué à 10.
Then you ignore them
[^] # Re: On ne connait pas les mêmes personnes
Posté par rakoo (site web personnel) . En réponse au journal Identification versus authentification : l'embrouille de Zwipe et Mastercard.. Évalué à 7.
En fait, en creusant plus loin et en ouvrant son Guide de la théorie des complots, on pourrait même dire qu'il y a des gens à qui ça ferait plaisir qu'on paie plus vite et plus facilement, parce que le consommateur serait alors plus enclin à faire encore plus de transactions, tu comprends, c'est tellement simple. Plus de consommation, plus d'argent dépensé, plus de sous qui rentrent pour les intermédiaires…
Sérieusement, je doute fortement que Zwipe ait été créé pour répondre à un besoin des clients/consommateurs, mais plutôt pour pas perdre l'avance énorme qu'ils ont encore face aux Google/Apple qui veulent mettre leur nez dans le business.
[^] # Re: Oui allo j'écoute !
Posté par rakoo (site web personnel) . En réponse au journal Identification versus authentification : l'embrouille de Zwipe et Mastercard.. Évalué à 7.
Avec une vidéo qui marche
[^] # Re: Rentabilité
Posté par rakoo (site web personnel) . En réponse au journal La publicité "propre" ça existe ?. Évalué à 4.
Et pourtant, c'est le business model d'à peu près tous les médias de diffusion libre: radio, télé, sites web voire internet.
La différence avec internet c'est qu'on a enfin un moyen d'éviter les pubs, alors qu'avant on ne pouvait que se les farcir; on a donc enfin la possibilité de se poser la question "est-ce que ce service vaut la peine ? Est-ce que je veux bien lui donner de l'argent même si ça doit passer par la pub ?"
Et encore: là on parle entre nous, c’est-à-dire des gens qui ont les connaissances nécessaire pour savoir comment zapper les pubs, la grande grande majorité des utilisateurs les laissent passer dans un mélange de flemme/manque de connaissance/ça-me-dérange-pas. Du coup je pense que le modèle a encore un peu de temps devant lui même si ça commence à devenir chaud.
[^] # Re: Les applications sont bien, le site moins
Posté par rakoo (site web personnel) . En réponse au journal Framasoft aurait-il tout compris?. Évalué à 4.
Bien, tu vas pouvoir remonter tes observations.
[^] # Re: Présentation du budget
Posté par rakoo (site web personnel) . En réponse au journal Libre office, ça suçe des ours en Alaska.. Évalué à 4.
Mouais. Même si on partait du principe que LO remplissait les critères, je pense qu'on peut quand même inclure une formation. En plus de ça si support (avec contrat, hein) il y a, ça compte aussi.
Et en fait c'est valable pour 1 comme pour 2, indépendamment de la licence.
[^] # Re: Yahou peut être enfin des jeux qui marchent !
Posté par rakoo (site web personnel) . En réponse au journal Retour aux sources. Évalué à 10.
Je rêve ! On est bien en train d'assister a un concours de kekettes sur le temps de compilation d'un programme tellement trivial qu'il n'est pas représentatif d'un vrai programme ?
[^] # Re: Au secours !!!
Posté par rakoo (site web personnel) . En réponse au journal git-webui : une interface web pour vos repos git. Évalué à 3.
Euh nan,
configureetmakedoivent absolument être lancés en tant qu'utilisateur non privilégié; ça n'a absolument pas besoin de droits supplémentaires.make installn'a besoin des droits root que si tu installes l'application dans les répertoires "OS", genre/usr,/binet tout le tintouin. Si tu as configuré l'install pour se faire dans un répertoire dans lequel tu as les droits (genre/home/chezmoi/monappli), tu n'as pas besoin des droits root. Mais, c'est vrai, un petit malin peut très bien avoir placé une commande pas drôle dans la cibleinstall.De manière générale cette discussion me fait un peu peur sur l'état général des déploiements au grand large des applications et sur l'absence d'un moyen-qui-marche-à-tous-les-coups si on sort des moyens privilégiés de son OS…
[^] # Re: on refait le protocole
Posté par rakoo (site web personnel) . En réponse au journal Retour de Berlin. Évalué à 4.
Heureusement que tu précises que t'es pas énervé, parce qu'on pourrait croire le contraire :)
Débattons, débattons !
J'aimerais juste rappeler le point de départ de la discussion, qui est la question intéressante posée par devnewton:
À laquelle je réponds "XMPP c'est top, ça juste marche dans les cas où on l'utilise le plus, c'est extensible, c'est ouvert, c'est implémenté de milles et une manières et ça a pas l'air de s’essouffler de ce coté là". Bref, c'est bien, il faut aller dans ce sens et améliorer l'existant plutôt que réinventer la roue. Je suis d'accord avec toi. Si on devait recommencer de 0, on pourrait garder une grosse grosse majorité de ce qu'on a déjà.
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 !
Maintenant, quelques précisions:
Sur le routage
Je persiste et signe, XMPP est un protocole de routage, clairement pas au sens de "routage de paquets IP", mais bien "routage de fragment XML". La différence est qu'une table de routage, c'est à dire l'ensemble des routeurs qu'un routeur connaît et à qui il est capable de parler, c'est l'ensemble des domaines qui ont un serveur.
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.
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, et inversement pour la diffusion (Note que cette fois ce qui est routé c'est pas un stanza entier, c'est le(s) item(s))
Cas un peu plus compliqué: je veux parler à quelqu'un sur IRC. Ma ressource -> mon serveur -> le serveur qui héberge la passerelle -> la passerelle (possiblement en tant que composant) -> IRC
Je vois XMPP comme étant capable de beaucoup plus que juste amener les stanza d'un client à un autre: par exemple si un domaine héberge un "serveur" XMPP sur un cluster de serveurs, ça serait vraiment bien d'utiliser XMPP de bout en bout. Ça permettrait par exemple de construire "facilement" des clusters en prenant n'importe quelle implémentation qui respecte les standards pour se faire son n-ième SecretWhatSnapLine, et ainsi faire avancer le protocole (soit en participant au réseau, soit en améliorant les outils existants).
Ça va vachement plus loin que SMTP, qui s'arrête au To, là on a potentiellement plusieurs niveaux de routage qui permettent un adressage vraiment fin.
Sur le binaire
J'ai l'impression que tu fais le raccourci "binaire => gros machin qui bouche le tuyau".
C'est très certainement vrai si tu utilises la manière naïve, qui est de tout mettre dans un gros paquet, ce qui est à mon sens sacrément stupide. Dans ce cas-là tu segmentes ton binaire, tu l'envoies morceau par morceau avec la possibilité pour les messages non-binaires de passer. Mais c'est vrai, ça veut aussi dire qu'un participant à une MUC peut envoyer des méga-gifs de chatons qui vont juste embêter tout le monde. Au fond je me disais juste "qui peut le plus peut le moins": si le protocole pouvait utiliser du binaire, il pourrait faire passer n'importe quoi par dessus, y compris du XML structuré comme ce qu'on a aujourd'hui, mais aussi du HTML sans avoir à l'échapper ou un message chiffré/signé sans avoir à le base64.
Sur le parsing
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 (de manière à poser quelques pointeurs qui permettent un accès rapide aux différents éléments). Sauf que si c'est un serveur, le "sens" qui l'intéresse, il s'arrête au to; le sens de ce qu'il y a en dessous c'est surtout pour le niveau suivant, par exemple le module de pubsub, qui potentiellement peut être sur un autre serveur (routage, encore). Dans ce cas là on aura 2 "analyses" complètes du message…
Plus généralement
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. Je crois que la seule bonne conclusion qu'on peut avoir c'est si on repartait de 0, on arriverait largement à la même chose.
[^] # Re: ISO-8859-1 ???
Posté par rakoo (site web personnel) . En réponse au journal Le prix des carburants enfin en OpenData. Évalué à 4.