Python n'entre vraiment pas en ligne ici. Il est clair que pour développer une petite IHM, ou un petit script, ce sera plus vite fait avec Python (et bidouillé/adapté aux besoins). Néanmoins, surtout pour un gros projet, le code Python a la fâcheuse tendance à devenir instable et il est difficile de savoir quel type tu reçoit réellement (int ou string?) et il faut parfois rajouter du code pour gérér plusieurs cas qui en Rust ne seraient même pas survenus. Deplus sur un gros projet, impossible de tester tous les cas (surtout ceux qui sont la "au cas ou").
Mais dans tous les cas Rust perd le temps de la compilation (et donc du retour à la case dev) alors que Python peut être modifier en prod rapidement par un admin ce que Python perd en perfs. Et au final pour les projets "importants" on peut se demander si c'est un réel défaut puisque généralement les adminsys sont incapable de toucher à une virgule de code.
Reste qu'en pratique un langage interprété offre quand même un peu plus de souplesse et de possibilité notamment pour les non-devs ou pour des projets ou les specs changent souvent (typiquement une IHM web) et ou la stabilité du code n'est pas si critique (car au final un site web c'est un ensemble de pages web qui chacune est un "petit projet").
PS : C'est rapide de corriger les erreurs de compilation quand tu maîtrise ton langage.
Il se rammasse sur JS mais sur-performe sur WebAssembly…
Après très souvent sur les moteurs JS, il peut y en avoir un qui à un coup d'avance un temps. Peut-être que la prochaine version de FF rattrapera Chromium et Chromium prendra ensuite un autre coup d'avance. Enfin il y a aussi autre chose, ses dernières années FF a tendance a se laisser distancer. Il faut dire qu'ils n'ont pas les même moyens (Google + Microsoft + … )…
Pourquoi initialiser des variables s'il y a déjà des nuls ?
J'avoue, ça m'est arrivé mais c'est piégeux. C'est comme utiliser 4/8 au lieu de sizeof()… En fait on est habitué à compiler avec toujours le même cvompilateur (g++) sur seulement des Linux X86 64 bits… Alors on a parfois tendances à faire quelques racourcis. C'est comme le coup du bigendian/littleendian.
Le problème se posera quand on voudra utiliser un autre OS/Compilateur/architecture.
Le plus drôle c'est que même si ce n'est pas propre et tout et tout, la plus part des trucs peuvent arriver.
Désactiver les warnings, ça peut arriver au moins pour certains types de warning (par exemple en reprenant du vieux code pour un ajout/débug)
"Utilisez les caractères invisibles dans votre code", ça je trouve ça vraiment piège. Avec UTF-8 tu peux nommer des variables avec un caractère invisible mais aussi 2 variables avec des caractères très semblables… Ca il y a vraiment aucune raison que ce soit bon.
Le copyright ne s'applique pas qu'aux oeuvres de l'esprit. Par exemple Google qui cartographie la terre avec ses satellites ne receuille que des données factuelles. Il n'empêche qu'elles appartiennent à Google. Factuellement un imprécran de Google maps est sous licence alors qu'il n'y a pas d'oeuvre de l'esprit. Enfin pas au sens ou il y a "créativité".
Le copyright peut s'appliquer à tout. La seule réel limite est si c'est déjà considéré comme un bien comun. Genre tu ne peut pas breveter la marche humaine et demander à chaque humain de te payer des royalties pour marcher. Amazon a bien mis un cpopyright sur le mot 'Amazone'… (il y a quelques restriction pour l'usage commun mais pas pour une publicité) Nike à bien breveté la virgule… Aucune oeuvre de l'esprit la dedans. En tout cas certainement sans comune mesure avec les somme potentielement demandé s'il y a copie.
Sur le fond je suis d'accord mais en pratique avoue que s'il y a une panique, très vite tu n'aura plus de cash car tu ne pourra pas retirer ton salaire auprès de ta banque. Et quand bien même cela arricverait très vite les gens repratiqueront le troc et ressortiront une monaie.
Et puis de l'argent liquide, il faut l'imprimer, le transporter en fourgon très blindé, le compter, le stocker dans une caisse enregistreuse qui consomme plus d'énergie qu'il n'y avait pas de tirroir caisse et le détruire en fin de vie….
C'est plus une question d'Open-Source et de monopole qui me gène dans le cash Apple/Facebook. Une monaie virtuelle ok, mais si elle n'est poas contrôlé par un acteur privé et tracée.
Je pense que ça fais quelques années que j'en ai pas utilisé ni pièce ni billet
Eh bien mon pauvre, tu ne te rends pas compte de ce que tu perds. On dirait quelqu'un qui dis fièrement que les relation physique ne sont plus nécéssaire, il se contente de vivre dans le métavers et pour avoir des enfants fait appel à un médecin pour une IA en environnement façon GATACA.
Techniquement c'est certain ça marche… Pas sûr que ce soit un monde rêvé mais oui c'est un monde possible dominé par un consumériste surveillé à la 1984 de George Orwell ou les gens ont peur de ce qui est naturel. Peur de donner 1 euro à un inconnu pour lui acheter sa baguette de pain de peur que le pain soit empoisonné ou la monnaie rendue fausse.
Et pourtant sa baguette acheté au super-marché est de bien moins bonne qualité (même le plus haut de gamme) et bien plus souvent contaminée par des produits plus ou moins toxiques.
On peut payer des montants ridicules comme important en sans contact avec Apple Machin là
Moyennant une taxe à Apple et un contrôle de la firme sur ce que tu peux payer avec (Tu ne peux pas acheter avec un truc palestinien ou russe par exemple).
Donc tu est d'accord pour qu'Apple te taxe toutes tes transactions… Et puis si l'oncle Sam se fâche, il pourra empêcher tout paiement… Mais avant ça c'est un excellent arguement de pression politique sur la France.
Dis autrement, ce que tu décris à vraiment beaucoup plus d'inconvénients que l'argent liquide. Non seulement il permet le trafic vraiment sâle (il permet de payer directement depuis un paradi fiscal) mais en plus il centralise toutes les transactions entre les mains de 2-3 acteurs privés pas toujours compatibles entre eux.
Souhaites tu revenir au temps ou tu devais avoir toutes les prises et appareils électriques de la même marques (au début de l'électricité)?
"faciliter la vie de personnes malveillantes ne m'enchante pas", il n'y a pas que les personnes malveillantes, il y a ceux qui achètent un joint pour le week-end entre amis. Il y a l'achat de produit bio-local ne respectant les standard de mise sur le marché (Semences non validées et/ou non stérilisées)
As tu envie de te voir refuser toutes transaction car ton compte bancaires à été piraté et tu est donc susceptible d'être toi même un escroc et puis de toutes façon comme tu n'a plus d'argent sur ton compte?
N'as tu pas envie de pouvoir donner 3 euros à ton fils de 7 ans pour qu'il ailles s'acheter des bonbon et un tour de manège?
Je te propose une chose, interdit toi tout argent liquide pendant 1 an et tu devrait voir à quel point il est indispensable… PS : le chèque est pire puisque dèjà quasi-refuserr partout et encore plus falsifiable.
J'ai eu la même histoire sur le "port swapping" (je ne sais plus le nom mais je m'était renseigné à l'époque). Il s'agit de sécurité informatique mais que l'on retrouve aussi ailleurs (en radio par exemple) pour brouiller les attaques. Mon article était certes incomplet mais le sujet était passionnant et complexe. Il était trop pointu aux yeux de Wikipédia…
Les autres jeux equivalents libres sont présents sur Wikipédia (Tux_Racer, 0_A.D.) et inverssement de nombreux jeux non-libres à la durée de vie parfois brève et ou peu connus sont présent sur Wikipédia. Supprimer la page demanderait à minima un long paragraphe ailleurs.
Je ne conaissais pas et je trouve ça top. Dagger parrait plus simple dans son approche (je n'ai pas dis son implémentation) mais earthly me parrait bien plus puissant.
Sur les PC si cela fonctionne c'est en partie car le noyau Linux maintient un support sur du très long termes (plus de 25 ans pour les architectures), sur les smartphone il y a plus de pilote spécifiques.
Enfin les Fairphone 2 vont continuer à fonctionner et des mises à jour pourront être faites. C'est l'OS qui ne se mettra pas à jour ni les pilotes… mais il y a très peu de chances pour que les failles d'un système ancien (et donc très peu utilisé) intéresse les pirates et donc soient utilisées.
Je m'explique :
1) Les failles connu jusqu'a aujourd'hui ont été corrigé.
2) Les failles des OS/pilotes très anciens ne sont que peu recherchés
3) Les failles trouvées sur du matériel ont statiquement été introduites "récemment" (elles ne s'appliquent pas sur du vieux logiciel).
4) Si la failles est réellement ouverte sur le Fairphone, les pirates ne développeront sans doute pas d'attaque spécifique au Fairphone et donc leurs attaques ont peu de chances de fonctionner dessus…
Le risque 0 n'existe pas mais il est acceptable pour moi…
Je pense qu'aujourd'hui ne pas vouloir moderniser (dont mécaniser) participe au déclin démocratique (ce manque de volonté d'aller voter mais aussi d'organiser des votes). Bien sûr il ne faut pas que ce soit fait au détriment de la fiabilité & qualité.
Ça ne devrait même pas être un débat dans une démocratie
Dans une démocratie, tout peut faire parti du débat. Y compris la démocratie. C'est ainsi que l'on progresse. Cela ne veut pas dire qu'il faille changer les choses, mais toujours se poser la question
de ce que l'on peut faire progresser.
Le comptage manuel est bien moins fiable et bien plus lent. Une machine, aujourd'hui c'est très bien mettre de côté les bulletin litigieux pour éventuellement un "jugement" humain.
Je pense que l'on pourrait télé-voter par internet pour une consultation régulière sur des sujets "peu" critique (avec authentification/signature par impots.gouv.fr).
Et voter par papier et compter machine pour les élections critiques comme les présidentiels.
Mais dans le cas papier il est impossible de prouver qu'il n'y a pas eu de bourrage d'urne ou de vote détruit (problème d'identification des votant pour le pouvoir central).
Et dans le vote électronique il est impossible de prouver que l’algorithme est le bon (problème de confiance dans la machine pour les votants)…
Enfin la critique n'est pas vraiment contre le langage mais contre la compilation des langages optimisés. Etant les seuls utilisables la ou les ressources sont critiques (embarqué, OS, Jeux performants, et logiciels exigeants) il n'y a pas le choix.
Le temps perdu à la compilation est largement récupéré à l'exécution à condition de l'exécuter plusieurs fois…
On pourrait tout de même imaginer un mode de compilation "just in time" ou pas qui permette de l'exécuter comme un langage interprété en dev et compilé en prod. Il y a eu des tentatives je crois mais pas de réel mise en place à ma connaissances (https://stackoverflow.com/questions/56177318/is-there-a-rust-interpreter : MIRI?).
Qu'est ce qu'à de plus ton coffre-fort par rapport à ta boite mail? Pour moi c'est une petite entreprise aux compétences douteuses closed-source. C'est aussi une porte ouverte. J'ai plus confiance en GMail ou Protonmail…
C'est 2 choses différentes. Les factures, c'est juste pour te demander de payer, pas pour recevoir de l'argent. Pour changer ton RIB en général la démarche est autrement plus complexe. Si tu parles d'un mail qui te demande un prélèvement automatique, c'est totalement autre chose, l'un n'entraine pas l'autre. Ou alors je n'ai pas compris l'explication.
"Ça s’appelle digiposte. Mais ce sera privé" tu veux dire GMail… C'est la même chose : login/mdp et si c'est piraté… Aujourd'hui les boites mails sont les plus sécurisé (authentification double facteur et plus (lieu, terminal habituel…))
Et alors La Poste ne garanti pas la réception non plus (sauf recommendé pas utilisé pour les factures)… sauf qu'en pratique, si tu n'a pas reçu une facture ce n'est pas trop difficile de se connecter au site pour une réclamation… et cela n'arrive à peu près jamais.
J'approuve tout a fait dans le sens ou il est scandaleux de devoir se connecter à un serveur pour récupérer sa facture, son bulletin de salaire… C'est une tâche lourde qui n'est, selon moi, pas RGPD dans le sens ou de ce fait mon fournisseur sait si je regarde ma facture, quand et même de quel endroit (avec mon IP), il peut la changer sans me prévenir discrêtement…
Cependant plus qu'une couche supplémentaire, je voudrais militer pour un envoi par mail. C'est un protocole ouvert, standard, qui fonctionne extrêment bien et qui est le pendant numérique naturel du courrier. Alors pour simplifier le traitement on pourrait peut-être imaginer un standard d'envois. On pourrait même imaginer activer l'option pour l'envoyer en crypter si on transmet sa clé publique…
La croissance de RISC-V est exponentielle, et c'est une bonne nouvelle pour l'Open-Source, tout spécialement pour le hardware qui était avant son arrivé gêné par trop de verrous.
Androïd RISC-V, c'est avant tout, tout un éco-système non spécifique à Androïd qui va bénéficier de ce coup de pouce. Le smartphone évidement ce n'est pas pour demain (mais après-demain) et d'ici là Androïd RISC-V pourrait commencer par l'embarqué.
Les temps vont se faire de plus en plus dure pour ARM, lentement mais sûrement.
[^] # Re: Au sujet du « Ça marche du premier coup »
Posté par abriotde . En réponse au journal Intégration d'une fenêtre de debug live en Rust 🦀. Évalué à 3. Dernière modification le 07 mars 2023 à 05:51.
Python n'entre vraiment pas en ligne ici. Il est clair que pour développer une petite IHM, ou un petit script, ce sera plus vite fait avec Python (et bidouillé/adapté aux besoins). Néanmoins, surtout pour un gros projet, le code Python a la fâcheuse tendance à devenir instable et il est difficile de savoir quel type tu reçoit réellement (int ou string?) et il faut parfois rajouter du code pour gérér plusieurs cas qui en Rust ne seraient même pas survenus. Deplus sur un gros projet, impossible de tester tous les cas (surtout ceux qui sont la "au cas ou").
Mais dans tous les cas Rust perd le temps de la compilation (et donc du retour à la case dev) alors que Python peut être modifier en prod rapidement par un admin ce que Python perd en perfs. Et au final pour les projets "importants" on peut se demander si c'est un réel défaut puisque généralement les adminsys sont incapable de toucher à une virgule de code.
Reste qu'en pratique un langage interprété offre quand même un peu plus de souplesse et de possibilité notamment pour les non-devs ou pour des projets ou les specs changent souvent (typiquement une IHM web) et ou la stabilité du code n'est pas si critique (car au final un site web c'est un ensemble de pages web qui chacune est un "petit projet").
PS : C'est rapide de corriger les erreurs de compilation quand tu maîtrise ton langage.
[^] # Re: Très intéressant !
Posté par abriotde . En réponse au lien Benchmark : est-ce que ça vaut le coup d'utiliser WebAssembly plutôt que JavaScript ?. Évalué à 2.
Il se rammasse sur JS mais sur-performe sur WebAssembly…
Après très souvent sur les moteurs JS, il peut y en avoir un qui à un coup d'avance un temps. Peut-être que la prochaine version de FF rattrapera Chromium et Chromium prendra ensuite un autre coup d'avance. Enfin il y a aussi autre chose, ses dernières années FF a tendance a se laisser distancer. Il faut dire qu'ils n'ont pas les même moyens (Google + Microsoft + … )…
# initialiser des variables s'il y a déjà des nuls
Posté par abriotde . En réponse au journal 50 mauvais conseils de codage pour développeur C++. Évalué à 2.
J'avoue, ça m'est arrivé mais c'est piégeux. C'est comme utiliser 4/8 au lieu de sizeof()… En fait on est habitué à compiler avec toujours le même cvompilateur (g++) sur seulement des Linux X86 64 bits… Alors on a parfois tendances à faire quelques racourcis. C'est comme le coup du bigendian/littleendian.
Le problème se posera quand on voudra utiliser un autre OS/Compilateur/architecture.
[^] # Re: Ah le point 4 !
Posté par abriotde . En réponse au journal 50 mauvais conseils de codage pour développeur C++. Évalué à 5.
Le plus drôle c'est que même si ce n'est pas propre et tout et tout, la plus part des trucs peuvent arriver.
Désactiver les warnings, ça peut arriver au moins pour certains types de warning (par exemple en reprenant du vieux code pour un ajout/débug)
"Utilisez les caractères invisibles dans votre code", ça je trouve ça vraiment piège. Avec UTF-8 tu peux nommer des variables avec un caractère invisible mais aussi 2 variables avec des caractères très semblables… Ca il y a vraiment aucune raison que ce soit bon.
Connaissez-vous:
https://fr.wikipedia.org/wiki/International_Obfuscated_C_Code_Contest
[^] # Re: Pas compris
Posté par abriotde . En réponse au lien Bing Map Builder pose problème à la communauté OpenStreetMap. Évalué à 1.
Le copyright ne s'applique pas qu'aux oeuvres de l'esprit. Par exemple Google qui cartographie la terre avec ses satellites ne receuille que des données factuelles. Il n'empêche qu'elles appartiennent à Google. Factuellement un imprécran de Google maps est sous licence alors qu'il n'y a pas d'oeuvre de l'esprit. Enfin pas au sens ou il y a "créativité".
Le copyright peut s'appliquer à tout. La seule réel limite est si c'est déjà considéré comme un bien comun. Genre tu ne peut pas breveter la marche humaine et demander à chaque humain de te payer des royalties pour marcher. Amazon a bien mis un cpopyright sur le mot 'Amazone'… (il y a quelques restriction pour l'usage commun mais pas pour une publicité) Nike à bien breveté la virgule… Aucune oeuvre de l'esprit la dedans. En tout cas certainement sans comune mesure avec les somme potentielement demandé s'il y a copie.
[^] # Re: Moi j'aime l'argent liquide...
Posté par abriotde . En réponse au lien Le Mouvement de liberté suisse demande à sanctuariser l’argent liquide - letemps.ch. Évalué à 1.
Sur le fond je suis d'accord mais en pratique avoue que s'il y a une panique, très vite tu n'aura plus de cash car tu ne pourra pas retirer ton salaire auprès de ta banque. Et quand bien même cela arricverait très vite les gens repratiqueront le troc et ressortiront une monaie.
Et puis de l'argent liquide, il faut l'imprimer, le transporter en fourgon très blindé, le compter, le stocker dans une caisse enregistreuse qui consomme plus d'énergie qu'il n'y avait pas de tirroir caisse et le détruire en fin de vie….
C'est plus une question d'Open-Source et de monopole qui me gène dans le cash Apple/Facebook. Une monaie virtuelle ok, mais si elle n'est poas contrôlé par un acteur privé et tracée.
[^] # Re: moi j'aime pas l'argent liquide
Posté par abriotde . En réponse au lien Le Mouvement de liberté suisse demande à sanctuariser l’argent liquide - letemps.ch. Évalué à 1. Dernière modification le 09 février 2023 à 16:51.
Eh bien mon pauvre, tu ne te rends pas compte de ce que tu perds. On dirait quelqu'un qui dis fièrement que les relation physique ne sont plus nécéssaire, il se contente de vivre dans le métavers et pour avoir des enfants fait appel à un médecin pour une IA en environnement façon GATACA.
Techniquement c'est certain ça marche… Pas sûr que ce soit un monde rêvé mais oui c'est un monde possible dominé par un consumériste surveillé à la 1984 de George Orwell ou les gens ont peur de ce qui est naturel. Peur de donner 1 euro à un inconnu pour lui acheter sa baguette de pain de peur que le pain soit empoisonné ou la monnaie rendue fausse.
Et pourtant sa baguette acheté au super-marché est de bien moins bonne qualité (même le plus haut de gamme) et bien plus souvent contaminée par des produits plus ou moins toxiques.
[^] # Re: moi j'aime pas l'argent liquide
Posté par abriotde . En réponse au lien Le Mouvement de liberté suisse demande à sanctuariser l’argent liquide - letemps.ch. Évalué à 2.
Apple pay ou pas, la bourse ou la vie ça a toujours exister et ça existera toujours. Le plus efficace c'est même l'enlevement contre rançon.
[^] # Re: moi j'aime pas l'argent liquide
Posté par abriotde . En réponse au lien Le Mouvement de liberté suisse demande à sanctuariser l’argent liquide - letemps.ch. Évalué à 2.
Moyennant une taxe à Apple et un contrôle de la firme sur ce que tu peux payer avec (Tu ne peux pas acheter avec un truc palestinien ou russe par exemple).
[^] # Re: moi j'aime pas l'argent liquide
Posté par abriotde . En réponse au lien Le Mouvement de liberté suisse demande à sanctuariser l’argent liquide - letemps.ch. Évalué à 4.
Donc tu est d'accord pour qu'Apple te taxe toutes tes transactions… Et puis si l'oncle Sam se fâche, il pourra empêcher tout paiement… Mais avant ça c'est un excellent arguement de pression politique sur la France.
Dis autrement, ce que tu décris à vraiment beaucoup plus d'inconvénients que l'argent liquide. Non seulement il permet le trafic vraiment sâle (il permet de payer directement depuis un paradi fiscal) mais en plus il centralise toutes les transactions entre les mains de 2-3 acteurs privés pas toujours compatibles entre eux.
Souhaites tu revenir au temps ou tu devais avoir toutes les prises et appareils électriques de la même marques (au début de l'électricité)?
[^] # Re: moi j'aime pas l'argent liquide
Posté par abriotde . En réponse au lien Le Mouvement de liberté suisse demande à sanctuariser l’argent liquide - letemps.ch. Évalué à 1.
"faciliter la vie de personnes malveillantes ne m'enchante pas", il n'y a pas que les personnes malveillantes, il y a ceux qui achètent un joint pour le week-end entre amis. Il y a l'achat de produit bio-local ne respectant les standard de mise sur le marché (Semences non validées et/ou non stérilisées)
As tu envie de te voir refuser toutes transaction car ton compte bancaires à été piraté et tu est donc susceptible d'être toi même un escroc et puis de toutes façon comme tu n'a plus d'argent sur ton compte?
N'as tu pas envie de pouvoir donner 3 euros à ton fils de 7 ans pour qu'il ailles s'acheter des bonbon et un tour de manège?
Je te propose une chose, interdit toi tout argent liquide pendant 1 an et tu devrait voir à quel point il est indispensable… PS : le chèque est pire puisque dèjà quasi-refuserr partout et encore plus falsifiable.
[^] # Re: Combat sans fin
Posté par abriotde . En réponse au journal si on ne fait rien, Xonotic va disparaitre de wikipedia FR. Évalué à 8.
J'ai eu la même histoire sur le "port swapping" (je ne sais plus le nom mais je m'était renseigné à l'époque). Il s'agit de sécurité informatique mais que l'on retrouve aussi ailleurs (en radio par exemple) pour brouiller les attaques. Mon article était certes incomplet mais le sujet était passionnant et complexe. Il était trop pointu aux yeux de Wikipédia…
[^] # Re: a voté
Posté par abriotde . En réponse au journal si on ne fait rien, Xonotic va disparaitre de wikipedia FR. Évalué à 4.
J'ai aussi apporté ma contribution :
[^] # Re: Un peu hors sujet : makefile et docker
Posté par abriotde . En réponse au journal VSCodium & support python : pyright. Évalué à 1.
Je ne conaissais pas et je trouve ça top. Dagger parrait plus simple dans son approche (je n'ai pas dis son implémentation) mais earthly me parrait bien plus puissant.
[^] # Re: Quelqu'un saurait m'expliquer ?
Posté par abriotde . En réponse au lien Fin du support logiciel sur le Fairphone 2 (mars 2023). Évalué à 2. Dernière modification le 11 janvier 2023 à 18:03.
Sur les PC si cela fonctionne c'est en partie car le noyau Linux maintient un support sur du très long termes (plus de 25 ans pour les architectures), sur les smartphone il y a plus de pilote spécifiques.
Enfin les Fairphone 2 vont continuer à fonctionner et des mises à jour pourront être faites. C'est l'OS qui ne se mettra pas à jour ni les pilotes… mais il y a très peu de chances pour que les failles d'un système ancien (et donc très peu utilisé) intéresse les pirates et donc soient utilisées.
Je m'explique :
1) Les failles connu jusqu'a aujourd'hui ont été corrigé.
2) Les failles des OS/pilotes très anciens ne sont que peu recherchés
3) Les failles trouvées sur du matériel ont statiquement été introduites "récemment" (elles ne s'appliquent pas sur du vieux logiciel).
4) Si la failles est réellement ouverte sur le Fairphone, les pirates ne développeront sans doute pas d'attaque spécifique au Fairphone et donc leurs attaques ont peu de chances de fonctionner dessus…
Le risque 0 n'existe pas mais il est acceptable pour moi…
[^] # Re: La machine à compter
Posté par abriotde . En réponse au lien Pourquoi le code source des machines à voter doit être public (c'est valable pour tous les camps). Évalué à 1.
Si le dépouillement est manuel comment prouve tu plus les choses? Par l'oeil? Mais une caméra peut se mettre sur une machine.
[^] # Re: La machine à compter
Posté par abriotde . En réponse au lien Pourquoi le code source des machines à voter doit être public (c'est valable pour tous les camps). Évalué à 0.
Je pense qu'aujourd'hui ne pas vouloir moderniser (dont mécaniser) participe au déclin démocratique (ce manque de volonté d'aller voter mais aussi d'organiser des votes). Bien sûr il ne faut pas que ce soit fait au détriment de la fiabilité & qualité.
Dans une démocratie, tout peut faire parti du débat. Y compris la démocratie. C'est ainsi que l'on progresse. Cela ne veut pas dire qu'il faille changer les choses, mais toujours se poser la question
de ce que l'on peut faire progresser.
[^] # Re: La machine à compter
Posté par abriotde . En réponse au lien Pourquoi le code source des machines à voter doit être public (c'est valable pour tous les camps). Évalué à -3.
Le comptage manuel est bien moins fiable et bien plus lent. Une machine, aujourd'hui c'est très bien mettre de côté les bulletin litigieux pour éventuellement un "jugement" humain.
[^] # Re: Mauvais titre
Posté par abriotde . En réponse au lien Pourquoi le code source des machines à voter doit être public (c'est valable pour tous les camps). Évalué à 2. Dernière modification le 09 janvier 2023 à 22:04.
Je pense que l'on pourrait télé-voter par internet pour une consultation régulière sur des sujets "peu" critique (avec authentification/signature par impots.gouv.fr).
Et voter par papier et compter machine pour les élections critiques comme les présidentiels.
Mais dans le cas papier il est impossible de prouver qu'il n'y a pas eu de bourrage d'urne ou de vote détruit (problème d'identification des votant pour le pouvoir central).
Et dans le vote électronique il est impossible de prouver que l’algorithme est le bon (problème de confiance dans la machine pour les votants)…
# Compilation VS runtime
Posté par abriotde . En réponse au lien Is coding in Rust as bad as in C++?. Évalué à 2. Dernière modification le 09 janvier 2023 à 13:35.
Enfin la critique n'est pas vraiment contre le langage mais contre la compilation des langages optimisés. Etant les seuls utilisables la ou les ressources sont critiques (embarqué, OS, Jeux performants, et logiciels exigeants) il n'y a pas le choix.
Le temps perdu à la compilation est largement récupéré à l'exécution à condition de l'exécuter plusieurs fois…
On pourrait tout de même imaginer un mode de compilation "just in time" ou pas qui permette de l'exécuter comme un langage interprété en dev et compilé en prod. Il y a eu des tentatives je crois mais pas de réel mise en place à ma connaissances (https://stackoverflow.com/questions/56177318/is-there-a-rust-interpreter : MIRI?).
Le Go est certes un bon compromis sur ce point.
[^] # Re: Et le Mail
Posté par abriotde . En réponse au journal Une API normée pour accéder aux factures (1ere étape). Évalué à 0. Dernière modification le 07 janvier 2023 à 22:31.
Qu'est ce qu'à de plus ton coffre-fort par rapport à ta boite mail? Pour moi c'est une petite entreprise aux compétences douteuses closed-source. C'est aussi une porte ouverte. J'ai plus confiance en GMail ou Protonmail…
[^] # Re: Et le Mail
Posté par abriotde . En réponse au journal Une API normée pour accéder aux factures (1ere étape). Évalué à 4.
C'est 2 choses différentes. Les factures, c'est juste pour te demander de payer, pas pour recevoir de l'argent. Pour changer ton RIB en général la démarche est autrement plus complexe. Si tu parles d'un mail qui te demande un prélèvement automatique, c'est totalement autre chose, l'un n'entraine pas l'autre. Ou alors je n'ai pas compris l'explication.
[^] # Re: Et le Mail
Posté par abriotde . En réponse au journal Une API normée pour accéder aux factures (1ere étape). Évalué à 1.
"Ça s’appelle digiposte. Mais ce sera privé" tu veux dire GMail… C'est la même chose : login/mdp et si c'est piraté… Aujourd'hui les boites mails sont les plus sécurisé (authentification double facteur et plus (lieu, terminal habituel…))
Et alors La Poste ne garanti pas la réception non plus (sauf recommendé pas utilisé pour les factures)… sauf qu'en pratique, si tu n'a pas reçu une facture ce n'est pas trop difficile de se connecter au site pour une réclamation… et cela n'arrive à peu près jamais.
# Et le Mail
Posté par abriotde . En réponse au journal Une API normée pour accéder aux factures (1ere étape). Évalué à 4. Dernière modification le 05 janvier 2023 à 14:02.
J'approuve tout a fait dans le sens ou il est scandaleux de devoir se connecter à un serveur pour récupérer sa facture, son bulletin de salaire… C'est une tâche lourde qui n'est, selon moi, pas RGPD dans le sens ou de ce fait mon fournisseur sait si je regarde ma facture, quand et même de quel endroit (avec mon IP), il peut la changer sans me prévenir discrêtement…
Cependant plus qu'une couche supplémentaire, je voudrais militer pour un envoi par mail. C'est un protocole ouvert, standard, qui fonctionne extrêment bien et qui est le pendant numérique naturel du courrier. Alors pour simplifier le traitement on pourrait peut-être imaginer un standard d'envois. On pourrait même imaginer activer l'option pour l'envoyer en crypter si on transmet sa clé publique…
# Bonne nouvelle
Posté par abriotde . En réponse au lien Android will officially support the RISC-V architecture, and that's a big deal · Android Authority. Évalué à 6. Dernière modification le 05 janvier 2023 à 13:51.
La croissance de RISC-V est exponentielle, et c'est une bonne nouvelle pour l'Open-Source, tout spécialement pour le hardware qui était avant son arrivé gêné par trop de verrous.
Androïd RISC-V, c'est avant tout, tout un éco-système non spécifique à Androïd qui va bénéficier de ce coup de pouce. Le smartphone évidement ce n'est pas pour demain (mais après-demain) et d'ici là Androïd RISC-V pourrait commencer par l'embarqué.
Les temps vont se faire de plus en plus dure pour ARM, lentement mais sûrement.