xryl669 a écrit 124 commentaires

Si tu as un téléphone avec 50Go d'appli, c'est que tu es tombé dans l'appaddictude. Et donc tu peux probablement tout faire déjà, sauf que ta mémoire ne sait plus où tu as mis tout ton merdier.

Une personne saine d'esprit n'installe pas 50Go d'applications. La grosse majorité des applications Android ne sont que des front-end (mal faits en plus) du site web. Elles n'apportent rien, elles n'ont pas besoin de quelque chose que le Web ne fournit pas. Les seules applications utiles à installer sont celles qui ont besoin d'une fonction que le web ne propose pas (comme accéder au lecteur NFC, à l'appareil photo, à un rendu direct sur GPU pour les jeux, …).

Si maintenant tu veux utiliser ton téléphone comme un PC linux, il y a justement plein de solutions comme évoquées plus haut. Tu peux rooter ton téléphone pour avoir ton "su" préféré. Sinon tu peux installer Termux, ou un container. Tout ça ne pendra pas plus que quelques centaines de MB.

Mais là, tu te rends compte que le clavier virtuel, c'est vraiment de la daube pour taper sur un terminal.
Tu te rends compte que ton PC, c'est de la daube pour faire une photo digne de ce nom (sans parler de l'aspect pratique). Tu te rends compte que l'écran 16" de ton PC, c'est quand même plus confortable pour lire des man pages, etc…

Bref tu peux pas faire d'une camionnette une voiture de course, c'est simplement deux conceptions différentes pour répondre à deux objectifs différents. Tu pourrais modifier tant que tu veux ta Ferrari, ça restera une bouse pour livrer du mélange à béton.

Je n'ai jamais installé d'application bancaire sur mon téléphone. Toutes mes banques m'envoient des SMS pour valider une transaction (ce que je trouve hilarant en termes de fausse sécurité, vu que les SMS sont interceptables même en 4G) c'est juste pour le spectacle, ils n'en ont rien à faire de la sécurité (la preuve, avant la directive Européenne DSP, aucune de mes banques n'implémentait le 2FA).

Le truc c'est de ne jamais installer leur appli, sinon, ils valident une sorte booléen dans leur système: "cet utilisateur utilise notre application" et après c'est fini, tu ne peux pas revenir en arrière (et bonne chance si tu perds ton téléphone, vu que c'est l'appli qui te permet de te connecter à la banque pour, justement, changer de téléphone).

Vu qu'envoyer des SMS est payant vs utiliser Google Push pour réveiller leur appli sur ton téléphone, ils ont un intérêt certain à te pousser à la deuxième solution.

Si c'était la sécurité qui les intéressait, ils autoriserait d'utiliser une application TOTP tierce ou une clé FIDO.

La notion de t'interdire d'être root est aussi une hérésie. Vas-tu, à un seul instant pouvoir modifier le solde de ton compte en décompilant leur application? Car c'est de ça qu'il s'agit: d'empêcher d'avoir une application qui ne fait pas ce pourquoi elle a été programmée.

Si c'est possible de mettre le bazar dans ce cas, c'est que leurs API et la partie serveur doit être sacrément faible et j'aurais, personnellement, pas confiance dans la banque dans ce cas.

Petite correction, Qualcomm était le seul Américain à proposer du modem 4G (et 5G). Il y a des concurrents coréens, chinois et japonais (et même européens). Mais ils ont préférés du national pourri à de l'international de qualité.

Comme le FLX1^S de Furilabs, qui est, une fois n'est pas coutume, un smartphone Linux utilisable avec un container Android pour la compatibilité (et non pas un AOSP linuxé).

Et contrairement à Ubuntu Touch (pour le software) sur un FairPhone ou autre Android refurbished, ou un LibreM, un PinePhone, le téléphone et/ou le logiciel n'est pas une grosse bouse, il est conçu comme un téléphone, par des gens qui l'utilisent comme téléphone principal journalier.

Le logiciel (basé sur Phosh / Gnome) est adapté pour l'utilisation mobile (bien qu'il y ait encore du travail d'ergonomie), il est actuellement utilisable et les bugs ou problème UX sont corrigés par l'équipe de dév.

Ils sont partis sur un processeur de smartphone Mediatek Dimensity 900, ce qui est à la fois top (en comparaison à LibreM et PinePhone avec leur processeur généraliste installé au format smartphone) et dommage de ne pas avoir visé un processeur plus récent.

Avec un Snapdragon 8 récent, je l'aurais acheté direct.

Pareil, mais la réponse est lunaire (en tout cas pour un politicien):

(En gros)

Google peut faire ce qu'il veut pour améliorer la sécurité donc nous n'interviendrons pas.

Machinifique.

Cf Liste des fabriquants de smartphone Européens

Comment fais-tu? La dernière fois que je l'ai tenté, ça ne fonctionnait pas avec mon email. En gros, lors de l'onboarding d'un smartphone, c'est compte Google ou rien.

Mais encore ?

Non, pas comme PNG. Il y a une transformation en palette (en interne) dans l'encodeur, c'est à dire que s'il voit que l'image en entrée n'utilise qu'une quantité limité de combinaison, il peut choisir de coder en palette, mais ce n'est qu'un encodage, ce n'est pas décrit dans le fichier généré et tu ne peux pas définir cette palette (vu que c'est interne à l'encodeur). Il n'y a rien qui te garantisse un 1:1 de la palette PNG vers la table de composantes internes à JPEGXL.

Tu peux avoir 256 couleurs dans ta palette PNG dont seulement 4 utilisées dans l'image. Après conversion JXL, tu n'auras que 4 "couleurs" dans ta palette, les autres couleurs seront perdues (et l'ordre sera aléatoire de toute façon).

Cela peut paraître être du détail, mais lorsque tu fais du pixel art, typiquement pour un jeu, tu veux que l'ensemble des ressources utilisent quasiment tous la même palette.

Ou, si tu enregistres des images thermiques 16 bits, la palette indique la température des pixels observés ou pas, ce qui n'est pas linéaire avec la valeur du pixel, tu ne veux donc pas la perdre.
etc…

Bref, JXL n'est pas LE format qui les remplace tous, peut être pour la grosse majorité des applications, mais pas toutes.

Je ne pense pas que JpegXL puisse remplacer PNG. Typiquement, tu peux stocker des images en 8bits (+ palette) en PNG ce que tu ne peux pas faire en JpegXL. Tu as une certaine liberté sur ce que tu peux mettre dans un PNG (tu mets les chunks que tu veux, ils sont ignorés par les clients), ce que, à ma connaissance, n'est pas possible en JpegXL.

Bref, le JPEGXL n'inclus pas la totalité du featureset du PNG (par choix, la majorité des fonctions sont là).

Il est aussi, beaucoup, beaucoup plus gros que le PNG (qui est plus gros que le JPEG) à implémenter. Donc plus difficile à mettre sur un système embarqué (IoT).

À voir donc dans le temps, il y a bien un développeur fou qui va faire une implémentation en 1000 lignes de code.

C'est surtout une description de réseau, avec Gateway, entrée des noeuds, retransmission, tailles de paquet limité en fonction du SF, etc… C'est très haut niveau et certainement pas quelque chose que tu veux faire chez toi (en général, tu implémentes un client LoRaWAN (sur ESP32, il y en a plusieurs) et tu le connecte à TTN/TTS (the things stack) ou Helium, qui eux, gère le merdier du WAN de protocole. Tu peux également installer une Gateway chez toi (ce que je recommande, ça étant le réseau pour tout le monde), c'est en gros 100€ la gateway qui fait la communication LoRaWAN / Internet.

Ici, il parle très probablement de point à point, avec des paquets libres, des communications libres entre les participants.

Petite coquille dans ton texte: Si la banque n'a pas vu Serial alors elle ne peut pas répondre à la question "Est-ce que Serial a été déposé".

La seule chose que la banque peut faire c'est fournir sa clé publique de signature et le marchand peut vérifier si Sign(Serial, BankPrivateKey) est valide, connaissant Serial. Ça ne permet pas de vérifier la double dépense.

Pour cela, il faut forcément que la pièce ((Serial + Signature)) soit enregistré par la banque, ce qui n'est pas le cas au début. Le marchand, doit donc déposer l'enregistrement de Serial + Signature lorsqu'il veut collecter la pièce. La banque peut vérifier la signature et valider que le Serial n'est pas dans sa BDD (double dépense) pour valider la transaction. Au final, elle ne saura pas qui a émit la pièce (anonymisation de la création de la pièce) mais elle sait qui la reçoit.

Le problème, "classique" ici, arrive lorsque 2 banques reçoivent une requête, simultanée, de collection des pièces par 2 acteurs différents et que la signature est créée par une banque tierce. Il faut contacter la banque tierce pour qu'elle valide la signature et procède à la transaction monétaire effective, donc on revient au système bancaire standard, avec ses délais, ses frais et ses défauts.

L'autre problème c'est l'échange des pièces sans collection, c'est à dire sans connexion à une banque (en gros, Bob passe 2€ à Alice qui passe 2€ à Eve qui paye le pain à la boulangère). Il est impossible de valider que ni Bob, ni Alice, n'a fait une double dépense puisque c'est la banque seule qui peut le faire (et du coup, il n'y a plus d'anonymat possible).

En gros, si j'ai bien compris le système, ce n'est rien d'autre que des "cartes prépayés" virtuelles (comme les tickets de cash en papier thermique).

Tu achètes des "coins" (des pièces virtuelles, GNU oblige, divisées en puissance de 2, 1 cent, 2 cents, 4 cents, etc…). Un serveur central identifie tes pièces et capture le montant que tu as mis dans un compte en banque. Lorsque tu dépenses, il faut forcément se connecter à ce serveur pour l'informer de la transaction. Il valide que la pièce n'a pas été dépensé 2x ou plus.

Le destinataire du paiement peut ensuite collecter l'ensemble de ses pièces pour les détruire et recevoir un virement (moins les frais) du montant lié aux pièces en question.

En gros, comme les cartes prépayées (sauf que pour ces dernières, elles sont disponibles chez tous les buralistes, le fonctionnement ne dépend pas d'une connexion à un serveur pour chaque transaction et c'est quelque chose de concret, manipulable).

Ils ne veulent pas que leur système soit utilisé pour le blanchiment d'argent (contrairement aux cartes), donc le serveur est obligatoire (et hyper sécurisé). Il y a donc aussi des frais pour les virements (même s'ils sont faibles, psychologiquement, ils ne sont pas nuls).

Bref, j'ai du mal à y voir un quelconque intérêt. C'est une monnaie de singe, virtuelle peut être, mais ça reste du billet de monopoly.

Pour remplacer le cash, il faut offrir au moins autant d'avantage que le cash, c'est à dire:
1. Simplicité d'utilisation
2. Anonymat des échanges
3. Pas de frais
4. Fongible
5. Accepté / Reconnu partout

Ici, on en est très très loin. Il n'y a que des contraintes, et aucun avantage supplémentaire.

J'ai des enceintes Bluetooth chez moi que j'ai faites fonctionner sans problème, en plus en multiroom. Il utilise pulseaudio par défaut et donc du moment qu'elle est associée (ce qu'il ne fait pas tout seul, tu dois le faire manuellement, une seule fois), elle apparaît comme une sortie audio comme les autres. En gros, c'est le job de pactl, je pense qu'avec Pipewire, c'est même encore plus simple.

Tout est dans le titre. Owntone fait tout ce que tu veux, avec une interface WAF-compatible. Il gère les enceintes AirPlay / Bluetooth / UPnP. Il est autonome tu peux aussi écouter tes musiques à distance via un client web assez cool, ou faire boomer la musique chez toi à 3h tu matin tout en étant au Vietnam.

Dans les 2 sens du terme. Je pense qu'une interface plus épurée suivant les "métiers" des utilisateurs serait bénéfique.

Connaissez vous un logiciel libre qui "sache" se connecter aux différentes banques pour récupérer automatiquement les relevés (et les opérations en cours)?

À l'époque, il y avait Weboob et Cozy. Mais les deux ont, finalement, baissé les bras devant la complexité de la tâche: il est quasiment impossible d'automatiser l'extraction de données via le site web des banques.

J'en connais des sociétés qui savent le faire, visiblement via une API standard inter banque, mais elles sont payantes (soit en monnaie, soit en données). Même la gestion multibanque via votre banque en ligne ne fonctionne pas vraiment. Je cherche une solution en open source.

Et encore, tu peux relancer le compositeur Wayland sans avoir à tuer les applications, vu que, in fine, ce sont les applications qui possèdent leur buffer d'affichage (contrairement à X11). Il existe probablement un protocole wayland pour cela, je ne sais pas s'il est implémenté dans les compositeurs actuels (au moins un, forcément). Rien n'empèche en pratique au compositeur d'avoir un signal qui lui indique de se sérialiser (dans un fichier temporaire) et de quitter pour relancer une autre version en lui passant le fichier temporaire. Au démarrage du nouveau compositeur, il désérialise l'état du système et c'est complètement transparent pour les applications.

De même pour Linux, il existe des tas de solutions pour changer le kernel en live sans redémarrer (typiquement ce qui est fait dans les serveurs cloud, les machines virtuelles ne sont pas interrompues lorsque le porteur redémarre son noyau). Il faut pour cela que les drivers soient capables de correctement sauvegarder leur état et/ou faire un reset propre. C'est exactement la même problématique pour la veille prolongée (hibernation), le noyau sauvegarde ses états sur disque et les recharge en redémarrant. Si tu supprimes la phase "boot" au passage (qui n'a rien à faire lors d'une mise à jour), tu as une mise à jour transparente pour l'utilisateur (au pire, un freeze de quelques secondes pour la récréation des zones mémoires).

Sur les TI aussi, il y avait la possibilité de faire de la programmation, directement en assembleur, via Fargo. De mémoire, il fallait utiliser un cable série jack 2.5mm (à faire soi même, j'en avais vendu quelques un…). Ensuite, installer Fargo, le launcher assembleur. Et zou, un nouveau monde s'ouvrait à vous, pour peu que vous compreniez l'assembleur du 68000.

La Ti92, c'était la classe, beaucoup de souvenir…

franchement en 3 mois la machine s'est presque payée toute seule vu le prix des pièces détachées pour ce genre de réparation.

Je dois pas vivre dans le même monde. Un siphon ~10€, une chasse d'eau ~30€ et un carénage de débroussailleuse ~40€, je vois pas comment ça couvre le prix de la machine, de l'électricité et du plastique (sans parler des essais ratés et du coût horaire du temps de modélisation).

Autant je suis d'accord avec toi sur le principe d'avoir une imprimante clé en main, c'est un gain de temps considérable (j'en ai 3 chez moi, dont la première qui ne tourne plus depuis 5 ans, la flemme de la réparer, une Ender 3 à 100€ que je me suis juré de ne pas modifier, et qui attend sa conversion en extrudeuse de PET et une plus récente Ender 3 SE qui marche très bien, à 200€). Mais là, la P1S est techniquement hors de prix (mettre 600€ dans une machine qui n'imprime pas plus gros que 25cm³). C'est injustifiable.

Safety net, c'est has been. Maintenant, il y a le play integrity, le "live app checking". En gros, ils ont compris qu'il est impossible de faire un DRM sur un téléphone rooté. Donc maintenant, ils (Gogole) maintiennent une base de données des hash des ROM officielles. Le Play service de Gogole calcule le hash de ta ROM et l'envoi pour recevoir une confirmation de la validation de l'authenticité d'un téléphone non rooté.

C'est malin, pour eux, car ça oblige chaque fabriquant à publier (et donc payer sa dime à Gogole pour l'utilisation d'Android) ses hashs pour avoir le badge "Play Integrity".

Quand à la solution technique, c'est de la bonne vieille obfuscation toute pourrie. Le SafetyNet / PlayIntegrity, c'est une sorte de machine virtuelle qui reçoie une charge virale logicielle des serveurs de Google qui est signée par leur clé privée. Si la signature passe, elle est exécutée et valide la signature de l'intégrité.

Ce que je ne comprends pas par contre, c'est pourquoi il n'y a pas un patch "live" qui remplace le retour de la fonction "IsThisPhoneRooted" par un "return false;" sur microG et bypassant tout le merdier.

Parce que:

assert.ok(isString(Object('foo')));


Après, est-ce utile?, tout est là.

Pas tunée, c'est la même build que le code source officiel. La différence étant de fournir des addons par défaut ainsi qu'une configuration de l'interface plus orientée UI/UX (ce que tu peux faire dans FreeCAD 1.0).

Ils ont aussi fait une sorte de thingiverse pour FreeCAD, appelé Lens, malheureusement, trop peu fourni pour que ça prenne (ce genre de projet nécessite des années pour que ça "tienne", difficile pour une entreprise commerciale).

Bref, c'est peut être un peu prématuré pour l'instant.

Je plussois fortement. On est exactement dans l'exemple d'une "norme" supplémentaire inutile, pondue par des parasites qui n'ont même pas eu le courage d'utiliser leur cerveau plus de 2 minutes.

Cette certification ne sert à rien, comme le dit Guillaume, si tu veux frauder, tu fais payer en espèce et rien ne sort informatiquement, comptablement ou par écrit. Tout autre moyen de paiement laisse une trace qui est facile à vérifier, sans aucune certification du code par un audit requise. Ainsi un chèque doit être déposé sur un compte (donc trace bancaire), un paiement par carte idem, etc… Vu que les banques sont certifiées, elles, il y a déjà un journal des transactions clair, légal, infalsifiable et consultable.

Les logiciels de caisse propriétaires de Point.x qui permettaient d'effacer des opérations n'empêchaient pas les problèmes de réconciliation bancaire, c'est à dire lorsqu'un comptable devait faire correspondre toutes les transaction du compte bancaire avec une ligne de recette/dépense.

La certification ici est donc, inutile car elle ne résout pas le problème qu'elle prétend solutionner, et une charge supplémentaire, in fine, pour les commerçants (et donc pour nous tous, leurs clients). Elle est injuste car une telle certification n'est pas requise pour un commerce en ligne ou dans un pays européen autre. (Ce qui veut dire qu'un commerce qui ne facture pas ses clients via une caisse n'a pas à subir cette taxe)

On est donc pile dans la maxime de Clémenceau; "planter des fonctionnaires, il poussera des impôts". Visiblement, ils n'ont toujours rien compris après les agriculteurs, les gilets jaunes, les bonnets rouges. Il ne reste plus qu'à arrêter de produire et de vendre, tout simplement, histoire que ceux qui pondent ce genre de texte soient obligés de manger leur milliers de pages de normes, lois et autres élucubrations inbuvables et inutiles. On verra comment ils vivent mieux dans leur monde.

Si le but était de limiter la fraude en limitant la facilité de frauder, au contraire, la législation aurait dû imposer que tous les logiciels de caisses soient open sources (mais pas forcément consultables par tout un chacun) et que les builds soient reproductives, conservées et signées. Ainsi si une version contient de la triche, il suffit alors de chercher le hash du binaire chez un commerçant suspecté de fraude et ainsi, en quelques secondes, vérifier si ça vaut de coup de faire la réconciliation et le contrôle fiscal. La vie des contrôleurs fiscaux serait simplifiée, les fraudeurs prévenus en quelques semaines et les logiciels remplacés par des versions sûres. En cas de contrôle faisant apparaître une triche, le hash du binaire est capturé lors du contrôle, partagés avec les autres contrôleurs, et ainsi ne peut s'étendre plus. Idéalement, le logiciel de caisse pourrait signer/hasher les transactions avec son propre hash, ce qui validerait toute la chaîne.

La certification logicielle par cryptographie est quand même bien maîtrisée, facile à faire, quasiment gratuite et difficilement falsifiable.

il force la récursivité

Ah, je vois pas de récursivité dans le code posté, au contraire, il est complètement itératif.
Par contre, il a des bugs, car is_dir suit les liens symboliques, donc il peut ne jamais sortir (et donc crasher par manque de mémoire) si tu as une boucle dans tes répertoires. Mais pour les besoins de l'auteur, qui maîtrise son arborescence de fichiers, c'est un bon compromis je suppose.