Effectivement les exceptions qui ne sont pas rattrapées et remontent implicitement la stack trace ne sont pas une solution satisfaisante. Mais je ne trouve pas que la solution proposée soit plus moderne. Ça ressemble plus à du sucre syntaxique avec des conventions implicites, ce qui le rendent moins lisible pour un novice, ce qui est un mauvais point selon moi.
C'est dommage parce que le langage s'inspire du go dont j'aime beaucoup la gestion d'erreur :
* c'est un type comme un autre, il n'y a pas de notion d'erreur dans la syntaxe du langage, c'est une convention, mais une convention explicite
* la gestion des erreurs est elle aussi explicite : si on veut tester si une erreur a été retournée, on teste si l'erreur est différente de nil. Il n'y a pas de "if" magique qui teste implicitement ce cas. Un "if" fonctionne uniquement avec un booléen.
Ça donne du code plutôt verbeux j'en conviens, mais tout est explicite. Et le fait que ça ne soit pas une feature de la syntaxe du langage fait une feature de moins à apprendre.
Le problème restant, et commun à toutes ces gestions d'erreur, c'est la question de comment savoir quelles erreurs peut retourner une fonction. Pour l'instant peu importe le modèle, je n'ai jamais rien vu de satisfaisant.
PS : je suis allé voir la gestion des erreurs en zig, c'est de l'implicite couplé à la gestion implicite des optional, ça me file la nausée ^
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
J'avais un peu suivi ce langage au début, et l'avantage principal (promis) c'était d'avoir l'expressivité du go mais avec des variables immutables par défaut (ce qui apporte plus de garanties) et sans garbage collector (ce qui améliore les perfs).
Malheureusement j'ai l'impression après la lecture de cette dépêche qu'une bonne partie du langage est encore à l'état de promesses.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
À noter que le sujet d'intégrer du Rust dans Linux (le kernel) a été évoqué récemment : https://lkml.org/lkml/2020/7/9/952. Ça serait un signe supplémentaire je pense pour la crédibilité de ce langage, si certain en doutait encore.
GIMP 2.10.12 est principalement une version corrective de divers problèmes particulièrement ennuyeux, ce qui est compréhensible après une 2.10.12 avec autant d'évolutions !
Je pense qu'il y a une erreur sur le second numéro de version.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
L'auto hébergement n'a pas beaucoup de sens avec ce projet selon moi. L'intérêt c'est que je mets mon avatar une fois dessus, et qu'ensuite ça fonctionne partout. Mais ça ne peut fonctionner que s'il y a une instance centrale sur laquelle tout le monde tape.
Si héberge ma propre instance, alors quoi ? Je fais des PR sur tous les projets que j'utilise pour ajouter l'URL de mon instance ? Ça ne peut pas marcher.
Une solution serait de fédérer les instances, mais on a alors un autre problème : comment garantir l'authenticité de l'information ? Si une instance me répond posséder les info concernant le mail X, une autre instance peut aussi prétendre la même chose. Qui a raison ? C'est un problème complexe, et c'est ce qui fait que dans le projet Matrix (communication décentralisée avec des serveurs fédérés) l'identity server (qui permet de mapper un mail ou numéro de téléphone à un utilisateur, pour retrouver ses contacts) est toujours centralisé (une seule instance fait foi).
Une fois qu'on est arrivé à ce constat, vient le second problème : comment maintenir une instance pour toute la communauté ? Dès qu'elle va être un peu utilisée ça va demander des ressources humaines et financières qui sont peu accessibles à un ou plusieurs bénévoles. Framasoft pour rappel à (au moins) un administrateur système embauché à plein temps.
Bref, la fin de ce projet m'inspire plein de réflexions concernant la viabilité de ces projets libres lancés par une personne dans son coin. J'apprécie l'initiative, mais la durée sur le long terme me paraît comprise.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
La solution qui semble avoir été retenue, est de séparer très fortement la mémoire du kernel et la mémoire des processus. De cette façon, il n'y a plus moyen d'accéder depuis un processus à la mémoire du kernel.
Ça fixe une des failles (lire la mémoire kernel depuis l'espace utilisateur), mais pas toutes. Ça n'empêche pas de s'échapper d'une sandbox ou d'un hyperviseur (exemple : accéder en js à toute la mémoire du navigateur). Dans ces cas il faut des patches par logiciel.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
Dans ta documentation (très complète d'ailleurs), on peut lire, dans la secttion "Why GIF?" :
While GIF is a very old format, it has seen some rise in usage again in recent years.
Je dirais plutôt que les fichiers animés de courte durée répétés en boucle ont connu un regain d'utilisateurs ces dernières années. Et dans la culture du net, on appelle ça un GIF. Mais techniquement la plupart des sites (tumblr, 9Gag, …) stockent et servent ça sous forme de fichiers WebM qui est un format beaucoup plus efficace.
Ce qui me fait me demander si l'affirmation suivante est réellement un argument en faveur du format GIF :
GIF files are supported nearly everywhere
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
Une transaction est une écriture dans la blockchain qui dit "X a versé Y bitcoins à Z".
Le truc, c'est que pour garantir l’intégrité de la blockchain (qui est un gros livre des comptes), toutes les transactions référencent la transaction précédente. Plus exactement, parce que faire ça transaction par transaction serait beaucoup trop laborieux, on réuni les transactions en blocs (qui ont une certaine taille maximale sujette à débats), et ce sont les blocs qui se référencent les un les autres.
Deuxième concept : la preuve de travail. Pour que quelqu'un de malveillant ne puisse pas générer de faux blocs, les ajouter à la blockchain et les envoyer à tout le monde, on introduit une contrainte que doit respecter chaque bloc. Cette contrainte implique des calculs suffisamment longs (mais pas spécialement complexes) afin de garantir qu'on ne puisse pas altérer la blockchain.
Bon c'est très grossièrement expliqué, et il faut ajouter des mécanismes de signature cryptographique (avec une clef publique et une clef privée) si on veut vraiment tout détailler.
La conclusion, c'est que quand les transactions arrivent à un mineur, ça lui coûte des ressources, et il choisit donc celles qu'il va empaqueter dans un bloc pour les ajouter à la blockchain. Et ce choix se fait notamment sur les frais liés à chaque transaction, ces frais allant dans la poche du mineur qui calcule le bloc. Plus il y a de transactions, plus les frais augmentent pour espérer voir sa transaction passer rapidement. Les frais plus les délais avant que la transaction arrive dans la blockchain (et soit donc vraiment validée) font partie des critiques du Bitcoin (et sont aussi liés à la taille des blocs : plus gros blocs, plus de transactions, introduction dans la blockchain plus rapide).
Enfin pour terminer (oui c'est une seconde conclusion), la citation de Wikipédia que tu cites fait référence au fait que lorsque qu'un mineur ajoute un bloc à la blockchain, le protocole prévoit qu'il puisse y ajouter une transaction qui transfère des Bitcoins de nul part vers son compte. C'est ainsi que les Bitcoins sont créés.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
C'est certes sans doute impossible pour une blockchain publique
En fait c'est possible, mais ça crée une nouvelle blockchain. Ça s'appelle un hard fork, et c'est déjà arrivé à l'Ethereum (ce qui a donné l'Ethereum (la nouvelle blockchain) et l'Ethereum Classic (l'ancienne)). À noter qu'à l'époque ce fork avait déjà eu lieu suite à une faille dans un contrat.
Bitcoin a aussi eu son hard fork cet été, avec le Bitcoin Cash (conflit sur la taille de blocs).
Le seul problème si la blockchain est publique, c'est qu'on ne peut pas décider tout seul d'utiliser la nouvelle. Il faut que le reste du monde l'accepte aussi (ou au moins une quantité de personnes suffisamment importante pour que la nouvelle blockchain reste intéressante).
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
On remarque notamment qu'il y a une méthode initMultiOwned, qui prend un tableau de propriétaires initiaux. Cette méthode utilise le modificateur only_uninitialized, pour empêcher de l'appeler plus d'une fois :
modifier only_uninitialized { if (m_numOwners > 0) throw; _; }
Sauf que dans le cas présent initMultiOwned (ou initWallet, qui l'appelle) n'avait jamais été appelé par les dev de Parity. Du coup devops199 l'a appellé, devenant propriétaire du contrat, et l'a détruit.
À noter qu'il existe un mécanisme dans Solidity (le compilateur vers le bytecode Ethereum utilisé) pour empêcher un contrat de disposer d'un espace mémoire (et en faire uniquement une bibliothèque donc). Il aurait fallu le définir ainsi : library WalletLibrary is WalletEvent { … } au lieu d'utiliser contract.
Pourquoi ça n'a pas été fait ? Bonne question. J'ai l'impression qu'une library ne peut pas déclencher de paiement, alors qu'ici WalletLibrary en fait, mais je ne suis pas sûr de moi.
Et comment on se sort de cette situation ? On ne s'en sort pas. Par définition, la blockchain ne peut pas être altérée. Ou alors il faut faire un nouvel hard fork, ce que certaines personnes semblent réclamer. Mais ça veut dire que le machin n'est quand même pas très stable…
En fait tout cela me fait m'interroger sur le concept même d'Ethereum. La blockchain c'est cool pour enregistrer des données statiques comme des transactions, mais pour du code ? Par son concept même, on en pourra jamais mettre à jour le code. Il faut donc être sacrément sûr de son code pour commencer à l'utiliser, parce qu'on ne pourra alors plus le changer. Et même si on prouve le code à 100%, on n'est pas à l'abri d'une erreur humaine (ici, oublier d'appeler une méthode d'initialisation).
Il y a des idées pour pouvoir mettre à jour du code, à base de proxy où on peut mettre à jour la véritable adresse du code. Mais ça implique soit de faire confiance au gars qui gère le proxy pour ne pas changer l'adresse de la lib n'importe comment, soit que chacun déploie son propre proxy. Et qu'en cas de mise à jour, chacun aille changer l'adresse dans son proxy. Ça peut être géré par le client (comme Parity qui publie déjà des contrats sans qu'on ait besoin d'y comprendre quelque chose) mais ça me semble quand même laborieux.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
Cette citation n'est pas vraiment très claire. Voilà ce que j'ai personnellement compris après un peu de recherche.
Ethereum
Ethereum est pour rappel un système de blockchain qui permet de stocker et exécuter du code (appelé contrat) dans la blockchain, en plus de porte-feuilles et transactions (comme Bitcoin).
À chaque exécution du contrat, le nouvel état de sa mémoire est stocké dans la blockchain (ça a donc un coup, qu'il faut payé en gas (ce qui peut donner l'exception out-of-gas si on ne paye pas assez pour finir l'exécution du contrat, exception qui me fait personnellement très rire)). Un contrat n'a pas a proprement parler de propriétaire, mais une pratique consiste simplement à enregistrer dans une variable l'adresse du créateur, pour lui permettre d'exécuter des actions avec plus de privilèges.
Trois points important à rajouter :
un contrat est aussi un porte-feuilles, et peut donc posséder de la monnaie ;
un contrat peut s'autodétruire, il y a un appel prévu pour dans la machine Virtuelle Ethereum (selfdestruct) ;
un contrat peut appeler du code d'un autre contrat mais l'exécuter avec son propre contexte d'appel (sans avoir besoin d'envoyer un message au contrat que l'on souhaite exécuter, ce qui changerait l'expéditeur) : c'est un mécanisme de bibliothèque.
Parity
Parity est un client Ethereum (en Rust). Une des fonctionnalité que propose ce client, c'est de créer des porte-feuilles multi-signés. Avec un tel porte-feuille, tous ses propriétaires doivent signer une transaction avant qu'elle puisse être effectuée.
Or ce genre de porte-feuille n'est pas du tout prévu de base. Comment faire ? Avec un contrat. Ce porte-feuille multi-signé est en réalité un contrat, avec sa propre monnaie, qui a enregistré les propriétaires et implémente les mécanismes souhaités pour effectuer une transaction de monnaie vers un autre compte.
Le problème
Pour implémenter leur porte-feuille multi-signé, les gars de Parity ont développé un contrat qu'ils ont inséré dans la blockchain et que tous les porte-feuilles multi-signés utilisent. Une bibliothèque donc.
Ce contrat a aussi une notion de propriétaire, ainsi qu'une méthode qui appelle selfdestruct, qui vérifie que c'est bien le propriétaire du contrat qui l'appelle. Là où ça devient drôle, c'est que ce fameux devops199 a réussi à se rendre propriétaire de ce contrat, et une fois fait il a appelé la méthode déclenchant l'autodestruction.
Résultat, les porte-feuilles multi-signés qui utilisent ce contrat ne fonctionnent tout simplement plus. Comme le disent les mecs de Parity eux-même : « This means that currently no funds can be moved out of the multi-sig wallets ». Mais à part ça, « We very much regret that yesterday’s incident has caused a great deal of stress » (toujours de Parity) :')
Cerise sur le gâteau, lorsque un contrat s'autodétruit, il peut envoyer le reste de sa monnaie à une adresse, ce qui pourrait donc être une solution pour récupérer son argent. Mais il semblerait que la méthode qui appelle l'autodestruction utilise elle aussi ce fameux contrat qui n'existe plus, et donc ne fonctionne pas non plus.
À débile, débile et demie. Je ne sais pas qui cueille encore gratuitement des pommes dans la nature : les pommiers sauvages ça n'existe pas des masses, dans le jardin de tes parents il y en a max un (s'il y en a un), et les millions de gens qui vivent en ville (dont je fais partie) n'ont pas vu de pommiers depuis des années :)
Plus sérieusement, ce commentaire est bien sûr assez trollesque mais je suis plutôt d'accord avec la majorité des points.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
Sérieusement, que la "copie carbone" soit une nouveauté en 2017 dans un logiciel de messagerie instantanée est un sérieux problème sur la compréhension entre ce qui est sensé être de base (Skype le faisait il y a 10 ans quand même…) et ce qui est est "cas particuliers", et répondre que c'est juste super et normal qu'il y ai des cas particulier est ne pas comprendre le pourquoi XMPP n'a pas marché (que ce soit protocole ou logiciels, l'utilisateur s'en fout, il voit juste que ça ne marche pas)
Il y avait un autre journal il y a peu qui se demandait pourquoi le XMPP ne perce pas, je pense qu'on a un début de réponse. Je suis du même avis : que la possibilité de suivre une conversation sur plusieurs devices soit une feature qui apparaît en 2017 est tout simplement aberrant.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
Syncthing c'est sympa, mais tu n'as qu'une image de tes données au moment du backup, tu n'as pas l'historique. Donc contre le ransomware, ça ne marche pas.
Personnellement j'utilise restic qui backup tout dans le cloud (sur un object storage). C'est chiffré, il y a de la déduplication, et j'ai l'historique de tous mes backups, je peux revenir à la version que je veux. Par contre ce n'est pas automatique, il faudrait que je vois comment faire ça tout en protégeant ma passphrase.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
Ce téléphone a aussi la particularité de vouloir être "IP-native". Ce que ça signifie c'est que pour toutes les fonctionnalités de communication, un service IP sera mis à avant par rapport aux classiques services GSM (SMS, voix). Et techniquement, ça sera basé sur Matrix ! Ce téléphone est donc l'occasion d'un partenariat entre Purism et la fondation Matrix.org.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
Matrix.org est (ou va devenir) une fondation à but non lucratif, principalement pour pouvoir accepter des dons (via le site de financement participatif patreon, mais aussi des sponsors de type entreprises).
Personnellement j'ai mon propre serveur matrix depuis 6 mois, et ça marche du tonnerre. Je l'utilise principalement avec le bridge IRC, ce qui me donne un IRC plus moderne (envoie d'images, aperçu des liens, notifications push, …).
Et concernant les problème de perf, ça tourne sur un kimsufi à 15€/mois (certes c'est pas le 1er à 2€ par mois) sans aucun soucis, même en rejoignant des grosses rooms comme Matrix HQ (et j'utilise toujours SQLite…). Par contre sur un raspberry pi c'est sûr que ça va galérer.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
Pour un usage personnel je trouve ça plutôt sympa, histoire de maîtriser un peu ce qu'il se passe sur sa machine. Au final je n'ai pas mille applications qui tournent, pour l'instant je me suis contenté de white lister thunderbird, firefox et apt et ça marche pas mal du tout.
Là où on voit que c'en est encore vraiment aux débuts c'est avec le fait que :
tout est dans un seul blob (pas de daemon, d'UI séparée, …)
les règles sont sauvegardées dans une bdd sqlite dans le dossier courant
Au passage je découvre les mécanismes qui permettent de faire fonctionner un tel soft, c'est tout bête :
une règle iptables pour rediriger les ouvertures de connexions vers la cible NFQUEUE
OpenSnitch écoute la queue en question et valide ou refuse la connexion
Et comme OpenSnitch écoute uniquement les ouvertures de connexion je suppose que l'impact sur les perf est relativement faible.
Bonus : c'est écrit en python !
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
Client de B&You, j'ai une box TV avec Android (et une surcouche bouygues horrible pour la partie TV). Kodi propose une version pour cette plateforme, c'est donc celle que j'utilise, avec un NAS qui partage son contenu en UPnP.
Par contre je ne sais pas si ça vient de la version Android, de la box, ou du fait de lire des medias en UPnP, mais je trouve ça horriblement instable, et j'ai même l'impression qu'il manque des features. En vrac :
je n'ai jamais réussi à trouver dans l'explorateur de plugins un plugin de visualisation pour la musique (excepté celui fourni par défaut)
impossible de rafraîchir la liste des contenus, il faut quitter et relancer l'application
impossible de charger des sous-titres locaux, ça fait crasher l'application
impossible de chercher des sous-titres en français, ça ne cherche qu'en anglais
lags dès qu'on essaye de lire du 1080p (mais là je suis presque sûr que ça vient de la box, j'ai le même soucis avec Plex)
Bref, c'est pas très agréable à utiliser. Je vais essayer d'installer ça sur une rapsberry pi pour voir si ça se passe mieux, mais pour l'instant mon expérience de Kodi a été assez décevante.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
# Une gestion d’erreur moderne ?
Posté par erdnaxeli (site web personnel) . En réponse à la dépêche À la découverte du langage V. Évalué à 5.
Effectivement les exceptions qui ne sont pas rattrapées et remontent implicitement la stack trace ne sont pas une solution satisfaisante. Mais je ne trouve pas que la solution proposée soit plus moderne. Ça ressemble plus à du sucre syntaxique avec des conventions implicites, ce qui le rendent moins lisible pour un novice, ce qui est un mauvais point selon moi.
C'est dommage parce que le langage s'inspire du go dont j'aime beaucoup la gestion d'erreur :
* c'est un type comme un autre, il n'y a pas de notion d'erreur dans la syntaxe du langage, c'est une convention, mais une convention explicite
* la gestion des erreurs est elle aussi explicite : si on veut tester si une erreur a été retournée, on teste si l'erreur est différente de nil. Il n'y a pas de "if" magique qui teste implicitement ce cas. Un "if" fonctionne uniquement avec un booléen.
Ça donne du code plutôt verbeux j'en conviens, mais tout est explicite. Et le fait que ça ne soit pas une feature de la syntaxe du langage fait une feature de moins à apprendre.
Le problème restant, et commun à toutes ces gestions d'erreur, c'est la question de comment savoir quelles erreurs peut retourner une fonction. Pour l'instant peu importe le modèle, je n'ai jamais rien vu de satisfaisant.
PS : je suis allé voir la gestion des erreurs en zig, c'est de l'implicite couplé à la gestion implicite des optional, ça me file la nausée ^
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
[^] # Re: go good enough
Posté par erdnaxeli (site web personnel) . En réponse à la dépêche À la découverte du langage V. Évalué à 5.
J'avais un peu suivi ce langage au début, et l'avantage principal (promis) c'était d'avoir l'expressivité du go mais avec des variables immutables par défaut (ce qui apporte plus de garanties) et sans garbage collector (ce qui améliore les perfs).
Malheureusement j'ai l'impression après la lecture de cette dépêche qu'une bonne partie du langage est encore à l'état de promesses.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
# Lien cassé
Posté par erdnaxeli (site web personnel) . En réponse à la dépêche Participez à la grande enquête du CNLL sur l'état de offre open source en France. Évalué à 3.
Il manque un
:dans le lien vers l'enquête :)Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
# Rust dans Linux
Posté par erdnaxeli (site web personnel) . En réponse à la dépêche Rust a 5 ans, rétrospective. Évalué à 10. Dernière modification le 03 septembre 2020 à 11:30.
À noter que le sujet d'intégrer du Rust dans Linux (le kernel) a été évoqué récemment : https://lkml.org/lkml/2020/7/9/952. Ça serait un signe supplémentaire je pense pour la crédibilité de ce langage, si certain en doutait encore.
L'idée ça serait aussi d'attirer de nouveaux développeurs qui ne veulent pas forcément faire du C : https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
# Typo
Posté par erdnaxeli (site web personnel) . En réponse à la dépêche GIMP 2.10.12 : libérons les bugs !. Évalué à 5.
Je pense qu'il y a une erreur sur le second numéro de version.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
[^] # Re: Victoire pour Framagit ... défaite pour Framasoft
Posté par erdnaxeli (site web personnel) . En réponse au journal Une victoire pour Framagit. Évalué à 5. Dernière modification le 22 mai 2018 à 11:22.
Je suis un peu d'accord. Je ne sais pas si c'est le cas pour tous leurs services, mais certains sont limités (en ressources voir même en nombre de comptes que l'on peut ouvrir) pour éviter cela (c'est notamment le cas des instances owncloud : https://framablog.org/2015/10/05/framadrive-conservez-et-synchronisez-2-go-sur-nos-serveurs/).
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
# Auto hébergement
Posté par erdnaxeli (site web personnel) . En réponse à la dépêche Libravatar — fin du service ou début du renouveau. Évalué à 6.
L'auto hébergement n'a pas beaucoup de sens avec ce projet selon moi. L'intérêt c'est que je mets mon avatar une fois dessus, et qu'ensuite ça fonctionne partout. Mais ça ne peut fonctionner que s'il y a une instance centrale sur laquelle tout le monde tape.
Si héberge ma propre instance, alors quoi ? Je fais des PR sur tous les projets que j'utilise pour ajouter l'URL de mon instance ? Ça ne peut pas marcher.
Une solution serait de fédérer les instances, mais on a alors un autre problème : comment garantir l'authenticité de l'information ? Si une instance me répond posséder les info concernant le mail X, une autre instance peut aussi prétendre la même chose. Qui a raison ? C'est un problème complexe, et c'est ce qui fait que dans le projet Matrix (communication décentralisée avec des serveurs fédérés) l'identity server (qui permet de mapper un mail ou numéro de téléphone à un utilisateur, pour retrouver ses contacts) est toujours centralisé (une seule instance fait foi).
Une fois qu'on est arrivé à ce constat, vient le second problème : comment maintenir une instance pour toute la communauté ? Dès qu'elle va être un peu utilisée ça va demander des ressources humaines et financières qui sont peu accessibles à un ou plusieurs bénévoles. Framasoft pour rappel à (au moins) un administrateur système embauché à plein temps.
Bref, la fin de ce projet m'inspire plein de réflexions concernant la viabilité de ces projets libres lancés par une personne dans son coin. J'apprécie l'initiative, mais la durée sur le long terme me paraît comprise.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
[^] # Re: Détails techniques
Posté par erdnaxeli (site web personnel) . En réponse au journal Ça sent pas bon chez Intel ?. Évalué à 3.
Ça fixe une des failles (lire la mémoire kernel depuis l'espace utilisateur), mais pas toutes. Ça n'empêche pas de s'échapper d'une sandbox ou d'un hyperviseur (exemple : accéder en js à toute la mémoire du navigateur). Dans ces cas il faut des patches par logiciel.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
# GIF
Posté par erdnaxeli (site web personnel) . En réponse au journal Peek, capture d'écran au plus simple. Évalué à 7. Dernière modification le 25 novembre 2017 à 13:39.
Dans ta documentation (très complète d'ailleurs), on peut lire, dans la secttion "Why GIF?" :
Je dirais plutôt que les fichiers animés de courte durée répétés en boucle ont connu un regain d'utilisateurs ces dernières années. Et dans la culture du net, on appelle ça un GIF. Mais techniquement la plupart des sites (tumblr, 9Gag, …) stockent et servent ça sous forme de fichiers WebM qui est un format beaucoup plus efficace.
Ce qui me fait me demander si l'affirmation suivante est réellement un argument en faveur du format GIF :
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
[^] # Re: C'est quoi une transaction ?
Posté par erdnaxeli (site web personnel) . En réponse au journal L'arnaque bitcoin. Évalué à 7.
Une transaction est une écriture dans la blockchain qui dit "X a versé Y bitcoins à Z".
Le truc, c'est que pour garantir l’intégrité de la blockchain (qui est un gros livre des comptes), toutes les transactions référencent la transaction précédente. Plus exactement, parce que faire ça transaction par transaction serait beaucoup trop laborieux, on réuni les transactions en blocs (qui ont une certaine taille maximale sujette à débats), et ce sont les blocs qui se référencent les un les autres.
Deuxième concept : la preuve de travail. Pour que quelqu'un de malveillant ne puisse pas générer de faux blocs, les ajouter à la blockchain et les envoyer à tout le monde, on introduit une contrainte que doit respecter chaque bloc. Cette contrainte implique des calculs suffisamment longs (mais pas spécialement complexes) afin de garantir qu'on ne puisse pas altérer la blockchain.
Bon c'est très grossièrement expliqué, et il faut ajouter des mécanismes de signature cryptographique (avec une clef publique et une clef privée) si on veut vraiment tout détailler.
La conclusion, c'est que quand les transactions arrivent à un mineur, ça lui coûte des ressources, et il choisit donc celles qu'il va empaqueter dans un bloc pour les ajouter à la blockchain. Et ce choix se fait notamment sur les frais liés à chaque transaction, ces frais allant dans la poche du mineur qui calcule le bloc. Plus il y a de transactions, plus les frais augmentent pour espérer voir sa transaction passer rapidement. Les frais plus les délais avant que la transaction arrive dans la blockchain (et soit donc vraiment validée) font partie des critiques du Bitcoin (et sont aussi liés à la taille des blocs : plus gros blocs, plus de transactions, introduction dans la blockchain plus rapide).
Enfin pour terminer (oui c'est une seconde conclusion), la citation de Wikipédia que tu cites fait référence au fait que lorsque qu'un mineur ajoute un bloc à la blockchain, le protocole prévoit qu'il puisse y ajouter une transaction qui transfère des Bitcoins de nul part vers son compte. C'est ainsi que les Bitcoins sont créés.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
[^] # Re: on vit une époque formidable
Posté par erdnaxeli (site web personnel) . En réponse au journal Comment bloquer 280M de dollars en éther . Évalué à 5. Dernière modification le 11 novembre 2017 à 15:22.
En fait c'est possible, mais ça crée une nouvelle blockchain. Ça s'appelle un hard fork, et c'est déjà arrivé à l'Ethereum (ce qui a donné l'Ethereum (la nouvelle blockchain) et l'Ethereum Classic (l'ancienne)). À noter qu'à l'époque ce fork avait déjà eu lieu suite à une faille dans un contrat.
Bitcoin a aussi eu son hard fork cet été, avec le Bitcoin Cash (conflit sur la taille de blocs).
Le seul problème si la blockchain est publique, c'est qu'on ne peut pas décider tout seul d'utiliser la nouvelle. Il faut que le reste du monde l'accepte aussi (ou au moins une quantité de personnes suffisamment importante pour que la nouvelle blockchain reste intéressante).
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
[^] # Re: on vit une époque formidable
Posté par erdnaxeli (site web personnel) . En réponse au journal Comment bloquer 280M de dollars en éther . Évalué à 10. Dernière modification le 24 août 2019 à 18:16.
Un peu plus de détails.
Le contrat qui a été supprimé était le suivant : x863df6bfa4469f3ead0be8f9f2aae51c91a907b4. Tout le code important se trouve dans le contrat
WalletLibrary.On remarque notamment qu'il y a une méthode
initMultiOwned, qui prend un tableau de propriétaires initiaux. Cette méthode utilise le modificateuronly_uninitialized, pour empêcher de l'appeler plus d'une fois :Sauf que dans le cas présent
initMultiOwned(ouinitWallet, qui l'appelle) n'avait jamais été appelé par les dev de Parity. Du coup devops199 l'a appellé, devenant propriétaire du contrat, et l'a détruit.À ce niveau là c'est même plus une faille de sécu, c'est une porte d'entrée. Commentaire d'un des gars de Parity : ça a été déployé à la rache, on a pas vu.
À noter qu'il existe un mécanisme dans Solidity (le compilateur vers le bytecode Ethereum utilisé) pour empêcher un contrat de disposer d'un espace mémoire (et en faire uniquement une bibliothèque donc). Il aurait fallu le définir ainsi :
library WalletLibrary is WalletEvent { … }au lieu d'utilisercontract.Pourquoi ça n'a pas été fait ? Bonne question. J'ai l'impression qu'une
libraryne peut pas déclencher de paiement, alors qu'iciWalletLibraryen fait, mais je ne suis pas sûr de moi.Et comment on se sort de cette situation ? On ne s'en sort pas. Par définition, la blockchain ne peut pas être altérée. Ou alors il faut faire un nouvel hard fork, ce que certaines personnes semblent réclamer. Mais ça veut dire que le machin n'est quand même pas très stable…
En fait tout cela me fait m'interroger sur le concept même d'Ethereum. La blockchain c'est cool pour enregistrer des données statiques comme des transactions, mais pour du code ? Par son concept même, on en pourra jamais mettre à jour le code. Il faut donc être sacrément sûr de son code pour commencer à l'utiliser, parce qu'on ne pourra alors plus le changer. Et même si on prouve le code à 100%, on n'est pas à l'abri d'une erreur humaine (ici, oublier d'appeler une méthode d'initialisation).
Il y a des idées pour pouvoir mettre à jour du code, à base de proxy où on peut mettre à jour la véritable adresse du code. Mais ça implique soit de faire confiance au gars qui gère le proxy pour ne pas changer l'adresse de la lib n'importe comment, soit que chacun déploie son propre proxy. Et qu'en cas de mise à jour, chacun aille changer l'adresse dans son proxy. Ça peut être géré par le client (comme Parity qui publie déjà des contrats sans qu'on ait besoin d'y comprendre quelque chose) mais ça me semble quand même laborieux.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
[^] # Re: on vit une époque formidable
Posté par erdnaxeli (site web personnel) . En réponse au journal Comment bloquer 280M de dollars en éther . Évalué à 10.
Cette citation n'est pas vraiment très claire. Voilà ce que j'ai personnellement compris après un peu de recherche.
Ethereum
Ethereum est pour rappel un système de blockchain qui permet de stocker et exécuter du code (appelé contrat) dans la blockchain, en plus de porte-feuilles et transactions (comme Bitcoin).
À chaque exécution du contrat, le nouvel état de sa mémoire est stocké dans la blockchain (ça a donc un coup, qu'il faut payé en gas (ce qui peut donner l'exception out-of-gas si on ne paye pas assez pour finir l'exécution du contrat, exception qui me fait personnellement très rire)). Un contrat n'a pas a proprement parler de propriétaire, mais une pratique consiste simplement à enregistrer dans une variable l'adresse du créateur, pour lui permettre d'exécuter des actions avec plus de privilèges.
Trois points important à rajouter :
Parity
Parity est un client Ethereum (en Rust). Une des fonctionnalité que propose ce client, c'est de créer des porte-feuilles multi-signés. Avec un tel porte-feuille, tous ses propriétaires doivent signer une transaction avant qu'elle puisse être effectuée.
Or ce genre de porte-feuille n'est pas du tout prévu de base. Comment faire ? Avec un contrat. Ce porte-feuille multi-signé est en réalité un contrat, avec sa propre monnaie, qui a enregistré les propriétaires et implémente les mécanismes souhaités pour effectuer une transaction de monnaie vers un autre compte.
Le problème
Pour implémenter leur porte-feuille multi-signé, les gars de Parity ont développé un contrat qu'ils ont inséré dans la blockchain et que tous les porte-feuilles multi-signés utilisent. Une bibliothèque donc.
Ce contrat a aussi une notion de propriétaire, ainsi qu'une méthode qui appelle selfdestruct, qui vérifie que c'est bien le propriétaire du contrat qui l'appelle. Là où ça devient drôle, c'est que ce fameux devops199 a réussi à se rendre propriétaire de ce contrat, et une fois fait il a appelé la méthode déclenchant l'autodestruction.
Résultat, les porte-feuilles multi-signés qui utilisent ce contrat ne fonctionnent tout simplement plus. Comme le disent les mecs de Parity eux-même : « This means that currently no funds can be moved out of the multi-sig wallets ». Mais à part ça, « We very much regret that yesterday’s incident has caused a great deal of stress » (toujours de Parity) :')
Cerise sur le gâteau, lorsque un contrat s'autodétruit, il peut envoyer le reste de sa monnaie à une adresse, ce qui pourrait donc être une solution pour récupérer son argent. Mais il semblerait que la méthode qui appelle l'autodestruction utilise elle aussi ce fameux contrat qui n'existe plus, et donc ne fonctionne pas non plus.
Conclusion
Faut tout compiler en statique :D
Pour continuer à s'amuser :
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
[^] # Re: C'est de la daube.
Posté par erdnaxeli (site web personnel) . En réponse au sondage Que pensez-vous des liseuses ?. Évalué à 2.
À débile, débile et demie. Je ne sais pas qui cueille encore gratuitement des pommes dans la nature : les pommiers sauvages ça n'existe pas des masses, dans le jardin de tes parents il y en a max un (s'il y en a un), et les millions de gens qui vivent en ville (dont je fais partie) n'ont pas vu de pommiers depuis des années :)
Plus sérieusement, ce commentaire est bien sûr assez trollesque mais je suis plutôt d'accord avec la majorité des points.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
[^] # Re: XMPP, Pas facile de s'y retrouver
Posté par erdnaxeli (site web personnel) . En réponse à la dépêche Sortie du très attendu Prosody 0.10. Évalué à 2.
Il y avait un autre journal il y a peu qui se demandait pourquoi le XMPP ne perce pas, je pense qu'on a un début de réponse. Je suis du même avis : que la possibilité de suivre une conversation sur plusieurs devices soit une feature qui apparaît en 2017 est tout simplement aberrant.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
[^] # Re: syncthing
Posté par erdnaxeli (site web personnel) . En réponse au journal RAID is no Backup!. Évalué à 3. Dernière modification le 01 octobre 2017 à 18:43.
Syncthing c'est sympa, mais tu n'as qu'une image de tes données au moment du backup, tu n'as pas l'historique. Donc contre le ransomware, ça ne marche pas.
Personnellement j'utilise restic qui backup tout dans le cloud (sur un object storage). C'est chiffré, il y a de la déduplication, et j'ai l'historique de tous mes backups, je peux revenir à la version que je veux. Par contre ce n'est pas automatique, il faudrait que je vois comment faire ça tout en protégeant ma passphrase.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
# Matrix
Posté par erdnaxeli (site web personnel) . En réponse à la dépêche Librem 5, un projet de téléphone mobile libre tournant sous GNU/Linux !. Évalué à 8.
Ce téléphone a aussi la particularité de vouloir être "IP-native". Ce que ça signifie c'est que pour toutes les fonctionnalités de communication, un service IP sera mis à avant par rapport aux classiques services GSM (SMS, voix). Et techniquement, ça sera basé sur Matrix ! Ce téléphone est donc l'occasion d'un partenariat entre Purism et la fondation Matrix.org.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
# Status
Posté par erdnaxeli (site web personnel) . En réponse à la dépêche Matrix pour décentraliser Skype, Whatsapp, Signal, Slack et Discord. Évalué à 4.
Matrix.org est (ou va devenir) une fondation à but non lucratif, principalement pour pouvoir accepter des dons (via le site de financement participatif patreon, mais aussi des sponsors de type entreprises).
Personnellement j'ai mon propre serveur matrix depuis 6 mois, et ça marche du tonnerre. Je l'utilise principalement avec le bridge IRC, ce qui me donne un IRC plus moderne (envoie d'images, aperçu des liens, notifications push, …).
Et concernant les problème de perf, ça tourne sur un kimsufi à 15€/mois (certes c'est pas le 1er à 2€ par mois) sans aucun soucis, même en rejoignant des grosses rooms comme Matrix HQ (et j'utilise toujours SQLite…). Par contre sur un raspberry pi c'est sûr que ça va galérer.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
# Sympa
Posté par erdnaxeli (site web personnel) . En réponse au journal OpenSnitch. Évalué à 10. Dernière modification le 06 mai 2017 à 14:51.
Pour un usage personnel je trouve ça plutôt sympa, histoire de maîtriser un peu ce qu'il se passe sur sa machine. Au final je n'ai pas mille applications qui tournent, pour l'instant je me suis contenté de white lister thunderbird, firefox et apt et ça marche pas mal du tout.
Là où on voit que c'en est encore vraiment aux débuts c'est avec le fait que :
Au passage je découvre les mécanismes qui permettent de faire fonctionner un tel soft, c'est tout bête :
Et comme OpenSnitch écoute uniquement les ouvertures de connexion je suppose que l'impact sur les perf est relativement faible.
Bonus : c'est écrit en python !
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
# Kodi sur AndroidTV
Posté par erdnaxeli (site web personnel) . En réponse au journal Sortie du media player KODI 17 krypton. Évalué à 1. Dernière modification le 15 avril 2017 à 16:36.
Client de B&You, j'ai une box TV avec Android (et une surcouche bouygues horrible pour la partie TV). Kodi propose une version pour cette plateforme, c'est donc celle que j'utilise, avec un NAS qui partage son contenu en UPnP.
Par contre je ne sais pas si ça vient de la version Android, de la box, ou du fait de lire des medias en UPnP, mais je trouve ça horriblement instable, et j'ai même l'impression qu'il manque des features. En vrac :
Bref, c'est pas très agréable à utiliser. Je vais essayer d'installer ça sur une rapsberry pi pour voir si ça se passe mieux, mais pour l'instant mon expérience de Kodi a été assez décevante.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
[^] # Re: C'est cool mais pas de la bière libre sans licence
Posté par erdnaxeli (site web personnel) . En réponse au journal Brew Dog : L'Open Source sans pression. Évalué à 3.
La punk IPA est assez répandue et vraiment bonne mais selon moi la hardcore IPA est un bon cran au-dessus.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
[^] # Re: C'est du génie !
Posté par erdnaxeli (site web personnel) . En réponse au journal Weboob devient Website Extractor Professional. Évalué à 4.
Y aura-t-il un module WEP pour WEP ?
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
# On s'en fiche
Posté par erdnaxeli (site web personnel) . En réponse au journal CamelCase ou lowercase_with_underscore. Évalué à 6.
L'important c'est d'avoir des conventions, que ça soit au niveau du langage ou juste du projet, et que tout le monde les respectes.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
# Wiki
Posté par erdnaxeli (site web personnel) . En réponse au journal [Tuto/HowTo] SSHFS : mises en place et montage. Évalué à 4.
Ceci devrait être une page du wiki.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
[^] # Re: En parlant de Git...
Posté par erdnaxeli (site web personnel) . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 2.
Je me répond à moi-même : ce n'est pas "leur" fonction, ça fait partie de la libc, je ne connaissais pas.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.