xryl669 a écrit 136 commentaires

C'est faux. KDE Connect utilise un protocole IP. C'est tout.
Le support bluetooth natif n'a, à ma connaissance, jamais fonctionné (et sans intérêt AMHA) donc pas vraiment développé ni supporté. Je l'ai compilé au début avant de me rendre compte qu'il ne servait à rien. Donc la version officielle fonctionne parfaitement.

Par contre, vu que c'est de l'IP et qu'il y a, par défaut le support de PAN (IP sur Bluetooth) dans Linux et sur les smartphones (Android sûr, iOS je ne sais pas), faire fonctionner KDE Connect est un jeu d'enfant. Tu actives la couche IP, partage via Bluetooth sur le smartphone (donc pas besoin de changer l'AP WIFI ou autre), et tu t'y connectes avec ton Linux, c'est fait.

Il y a même un tutoriel plus haut avec des screenshots.

Non, avec KDE Connect tu peux utiliser du bluetooth aussi, c'est pas très compliqué, c'est même expliqué ici. KDE Connect, c'est un peu une tuerie en comparaison. Il te permet de passer les fichiers, le presse papier, d'utiliser le téléphone comme un touchpad remote, d'utiliser le clavier de ton PC sous Android, et j'en passe.

Honnêtement, du point de vue utilisateur lambda, c'est la meilleure alternative OS pour smartphone.
Simplement… ça marche. Pas de complexité, pas besoin d'être un XDA addict pour l'installer, on suit l'installeur fourni, on clique là et là, on appuie sur les 2 boutons demandés et zou, c'est installé.

Ensuite, l'environnement, c'est du Ubuntu. C'est un peu fisher price, mais ça fonctionne.
Le gestionnaire de fichier est assez limité par rapport à l'excellent MiXplorer sur Android (notamment pour les connections réseaux, type SMB/CIFS ou SFTP) mais bon, rien n'empêche de lancer un terminal et de faire un sshfs (à part pour Mme Michu).

Les applications fonctionnent globalement bien. Et puis le fait qu'il n'y ait pas 150 000 applications pour la calculatrice ou la lampe torche dans le store, c'est vraiment bien.

En Golang, la classe IP est par défaut en IPv6, il faut instancier la classe IPv4 pour avoir du IPv4, donc c'est normal que la recherche pour IPv6 ne retourne rien.

C'est exactement le contraire dans mon cas. Libreoffice est plus que nul pour supporter du OOXML, dès qu'il y a un schéma, une table, des colonnes, du suivi des modifications, etc.. (tout ce qui fait la "force" de word), il foire et en plus, il casse le fichier. Impossible d'avoir une ancre qui fonctionne au passage Word => LO => Word (et ça, c'est le cas depuis au moins 10 ans, le bug rapporté étant classé en "pas le même modèle de document donc irréalisable")

OO en revanche supporte toutes ces fonctions (même s'il n'a pas encore d'interface graphique pour éditer cela) et ne casse pas le document. Bref, si on m'envoie un docx je peux l'ouvrir, le lire, le modifier (mais pas tout… pour l'instant) et le renvoyer sans que mon correspondant ne sache quel logiciel j'ai utilisé.
Si je fais la même opération avec LO, le document est cassé, le correspondant est furieux (car seul "word" et un bonne dose d'huile de coude est nécessaire à sa réparation).

Après, c'est pas certifié ISO trucmuche, mais perso, c'est pas l'ISO qui me nourri, c'est mon travail et le temps à réparer les erreurs de LO, c'est du temps perdu pour moi.

MD5, c'est le futur, c'est rapide, peut être pas autant qu'un bon CRC-32, mais bon, il faut quand même que l'ordinateur rame un peu lorsqu'il signe un very important mail sinon l'utilisateur pensera que c'est bidon le cryptage.

Vu le code, ça semble orienté vers de la crypto-monnaie uniquement.

Désolé pour la réponse tardive. Haraka n'est pas un serveur mail classique comme Procmail. C'est un outil de pre-processing de mail. Il y a des dizaines de fonctions pour préprocesser les mails qui entrent, les filtrer, les aliases, les modifier, etc…

Tu peux par exemple, passer un filtre anti-spam (classique) mais dans ce cas, activer le mode tarpit qui va mettre très longtemps à répondre (genre 1 octet par seconde), et ainsi retarder fortement le spammeur. Tu peux faire les alias comme j'ai indiqué, faire du DKIM verify avec action paramétrable si ça échoue, du DKIM sign, …

L'une des options intéressantes c'est de récupérer les mails pour les stocker en BDD, pour faire un service mail qui n'utilise pas les classiques IMAP mais au contraire JMAP ou autre. Bref, c'est une boite à outils, à toi de faire une application avec.

C'est un peu l’œuf et la poule ici malheureusement.

On a d'un côté Weboob qui a déjà fait un travail colossal pour unifier des interfaces très différentes entre les banques, et de l'autre une équipe qui fait un travail très prometteur mais qui a décidé de faire tout (le travail) dans le browser.

Résultat, soit il faut tout réimplémenter les "konnectors" dans l'API Cozy (c'est à dire ré-écrire weboob qui est en python en JS), soit faire un gros hack dans Weboob (c'est à dire faire un serveur HTTP en python avec une API, et écrire un "konnector" dans Cozy pour cette API). Mais ça veut dire configuration des comptes via ligne de commande… pas très user friendly.
Le travail de Budget Insight, c'est justement ça: une API au dessus de Weboob. Si Cozy rendait open-source leur connecteur avec cette API, alors un développeur qui la réimplémenterait en open-source mettrait Budget Insight sur la paille (je pense que c'est pas très cool vu le travail fourni par BI).

Honnêtement, je trouve que les choix qui ont été fait amènent à une situation de deadlock où les deux alternatives (tout réimplémenter, banque par banque ou faire un konnector vers une API http serveur Weboob) sont mauvaises.

J'ai installé une instance Cozy pour l'application Cozy Bank et j'ai été super déçu de me rendre compte que les connecteurs vers les banques ne sont pas fonctionnels ou disponibles pour l'auto hébergé.

Pour moi, si c'est pour avoir un n-ième fournisseur d'agrégateur bancaire propriétaire, j'utilise l'une de mes banques, elles proposent toutes la fonction maintenant.

C'est déjà le cas, tu peux l'activer dans les options (ce que j'ai fait, ça marche nickel)

Personnellement, vu le problème des a+b@domain.com qui ne sont, ni privés (n'importe quel programmeur peut décider de supprimer tout ce qui est entre + et @ pour avoir l'email source), ni acceptés partout, je suis tombé sur la solution open source Haraka.

Ça marche très bien. On peut choisir le format de la redirection (par exemple a.b@domain.com qui eux, sont acceptés partout, ou simplement b@siteinconnu.domain.com).

Ça ne consomme rien en ressources, et on peut faire des tas d'analyses, rejet des spams etc…

J'ai fait un tutoriel pour l'installer:
https://steemit.com/mail/@xryl669/forwarding-email-to-your-domain-to-your-personal-email-box-anti-challenge-1

Ça bouge pas mal côté FPGA et Opensource ces derniers temps.

Projet de "GCC" du FGPA: (par reverse engineering des architectures & outils)
https://symbiflow.github.io/

Nouveau FPGA (chinois) pas cher:
https://hackaday.com/2019/11/03/the-5-fpga/

Il est considéré qu'une dose de 20ppm de CO est la limite acceptable. Si l'on regarde la courbe du capteur MQ 135, cela correspond à une variation de 12% de la résistance du capteur (autant dire, pas grand chose).
Le problème c'est qu'une telle variation est obtenue avec 15ppm de CO2 dans l'air, c'est à dire que si tu mets un seuil trop faible pour la détection de CO, le simple fait d'allumer une bougie dans la pièce le fera franchir à cause du CO2.

C'est d'ailleurs le problème de ce genre de capteur, qui ne font aucune différence sur les composés qu'ils détectent.

Si tu regardes les détails des 3 failles, la première force l'ESP8266 à rebooter (ce qui n'est pas forcément un soucis de sécurité, seulement tu perds ton périphérique).
Les deux autres nécessitent que l'ESP8266 soit connecté en EAP (cas très très rare chez les particuliers).

Dans la pratique, ce n'est pas Hiroshima.

Non, ce n'est pas le cas. Le CO2 n'est pas détectable par les capteurs bon marché. Ce qu'ils détectent, c'est les particules de la fumée (donc il faut que ça "fume"). Il n'y a pas d'arnaque car ils sont bien vendus comme détecteur de fumée.
Leur technique de détection varie, mais c'est grosso modo soit la transparence de l'air qui est mesurée (lumière/capteur) ou pour les plus avancés ils détectent la variation électrique d'une source d'ions (souvent générés par un composé radioactif) qui sont perturbés par la fumée.

C'est quand même vachement simple de détecter ce genre de cas en C++.

class A
{
private:
    A() { throw new you_are_a_donkey_exception(); }
};

// Si ça, ça compile, c'est qu'il y a un soucis dans tes macros
A a;

Essaye OnlyOffice. Franchement, ça passe dans 99% des documents DOCX sans problème, le 1% restant, c'est dû aux polices qui ne sont pas présentes sur mon ordinateur, ou des intégrations OLE anciennes (ce qui est de plus en plus rare).

Par contre, avec LibreOffice, ouvrir un DOCX fonctionne dans quoi, peut être 1% des cas. Dès qu'il y a une illustration, c'est mort. Dès qu'il y a une numérotation automatique (genre 1. Titre 1, 1.1 Titre 2, etc…), c'est mort. Dès qu'il y a une table des matières c'est mort, etc…

Je ne suis responsable chez eux, mais dans ma boite, si le support est aussi nul, je ne l'active pas du tout, car ça dessert le logiciel qui est par ailleurs excellent, les utilisateurs ne retiennent que "ça ne marche pas".

Enfin, même si le document s'ouvre "à peu près" correctement, si tu l'enregistres en DOCX, plus aucun logiciel ne saura l'ouvrir comme il faut (pas même LibreOffice, ce qui montre que leur test sur ce type de format sont assez limités).

Après, c'est l'expérience dans la vraie vie, en étant pragmatique. Maintenant, oui c'est sûr ODF c'est plus "simple", c'est pas Microsoft, c'est … mais c'est surtout inutilisé.

Je suis passé à OnlyOffice il y a maintenant 2 ans, et je n'entends plus personne me poser la question de quel logiciel j'utilise (sous entendu, le document est cassé), voir me faire des remarques comme quoi les doc ne marchent plus. Et je peux te dire que j'en écris/relis/corrige des documents…

Ouais, enfin bon. Si tu as déjà regardé un document de dépot de brevet, tu as vu qu'il contient des schémas, des liens, des références, des tables, etc… Je te mets au défi de me montrer 2 logiciels sachant gérer de l'ODT sans casser la présentation. Pire encore avec le DOCX dans un logiciel dont le modèle de document est calqué sur l'ODT.

Dans la pratique, il existe des soft opensource qui font du DOCX en natif (je pense à OnlyOffice), je vois pas pourquoi il faudrait que toutes les personnes qui travaillent avec l'INPI doivent passer par des logiciels différents, avec moins de fonctionnalité pour faire de "ODT", alors que leur base de travail quotidienne est en DOCX.

Je ne comprends pas les ayatollah de l'ODT qui estiment que leur format est supérieur. Je peux comprendre qu'un format propriétaire et fermé soit inférieur, soit parce qu'il faut passer à la caisse, ou parce qu'on ne sait jamais si le document s'ouvrira encore dans la version 2030 du logiciel, mais ce n'est pas le cas du DOCX.

Il existe des soft open source qui l'ouvre parfaitement (puisque le format n'est pas propriétaire, ni fermé) et qui sont gratuits. À nous de nous adapter au monde extérieur et pas l'inverse!

1. Oui
2. Oui
3. docx, xlsx, pptx c'est le format (de fait) utilisé partout où les gens travaillent avec les outils et pas sur les outils.

Complètement d'accord avec le dernier point. Onlyoffice est pour l'instant plus limité dans son interface que LibreOffice ou MS Office (malgré le fait qu'il supporte quasiment toutes les fonctions dans les fichiers OOXML). C'est la suite que l'on attendait en open source, car ça marche avec les autres sans les obliger à changer leurs habitudes.
Le format ODT, c'est beau comme un poème, c'est à dire en théorie, mais sans pragmatisme. C'est un format issu d'une suite office (StarOffice/OpenOffice) qui était peu utilisée, incompatible de fait avec le format "de facto". Impossible de faire tenir OOXML dans ODT, donc c'est à perte pour l'utilisateur qui veut utiliser le format.
Je tire mon chapeau au dev LibreOffice, mais depuis que j'ai compris qu'il n'y a aucune chance qu'un document DOCX soit ouvert correctement avec, c'est fini pour moi. Le seul cas où je démarre encore LO, c'est pour les tableurs car il supporte les fonctions statistiques (ex. régressions linéaires) nativement (alors que OnlyOffice n'a pas d'interface pour créer la régression linéaire, mais si elle est présente dans le fichier source, il sait la tenir à jour).
LO est aussi mieux optimiser pour les très gros tableaux (genre 50k cellules) alors que le code d'OnlyOffice rejette le document.

Oui, enfin bon. Quand tu vis dans la vraie vie, le format ODF (ODT/ODS/ODP) ça ne marche pas, le DOCX et XLSX et PPTX oui, et seul OnlyOffice le supporte correctement.

D'ailleurs, en réalité, le format DOCX est le plus problématique. Pour les tableurs et présentations, ça marchouille suffisamment pour que ce soit acceptable. Mais pas pour les documents textes.

Après avoir cherché pourquoi LibreOffice, malgré les années et les nombreux contributeurs était toujours incapable d'ouvrir un DOCX non basique correctement (et encore moins de l'enregistrer sans le casser), j'ai trouvé que le problème d'OO ou LO, c'est le modèle de document (qui a servi de base au format ODF d'ailleurs).

Ce modèle ne supporte pas toutes les fonctions que l'on retrouve dans le format DOCX. Du coup, lors de l'ouverture d'un DOCX il essaye de mapper le modèle DOCX sur son modèle inférieur, perdant, au passage, beaucoup d'information. Par exemple, DOCX supporte les ancres relatives d'un objet par rapport à un autre. ODS ne supporte que les ancres relatives par rapport à la page, ou au paragraphe. Dans un dessin dans Word, impossible donc de l'ouvrir dans LO sans que ça ne le casse (sans parler du reflow lorsque l'on ajoute/modifie le texte). Je peux t'en citer plein d'autre comme ça.

Donc, l'argument comme quoi la spec ODF est plus simple, oui et heureusement car elle ne fait pas tout ce que fait la spec XMLX.

Honnêtement, entre l'interface OnlyOffice et LibreOffice, y a pas photo, je préfère largement la première malgré le manque de fonctions dans le frontend (paradoxalement, leur backend est super puissant)

Je veux pas jeter la pierre, mais Microsoft a passé largement plus de temps et d'amélioration pour que son format de document soit vraiment adapté à un maximum de cas concrets (l'avantage d'être le seul à le maîtriser vs devoir se coller à une spécification) et je vois pas comment LO pourra le rattraper sauf à modifier le modèle de document, ce qui est quasiment impossible lorsque celui-ci est normalisé.

Donc, pour moi, c'est une beau mouvement de la part de Microsoft, en publiant son format XMLX et poussant pour que l'ODF soit normalisé (en l'état, donc inférieur), il a bloqué toute compétition car l'ensemble des efforts de la communauté open source est maintenant perdue à vouloir se "conformer" à une norme inférieure.

En plus "joli", il y a SimpleEmail disponible sur F-Droid. Il a une interface material (avec les swipe pour effacer les messages, aperçu des messages etc…). C'est à la base un fork de FairEmail, mais avec un contributeur plus à l'écoute des besoins des utilisateurs.

Comment vous faîtes pour Edge qui ne supporte pas les SSE ? C'est du polling ?

Justement, je suis assez étonné de cette réponse "même par une extension".
Vu que ladite extension serait téléchargée hors de l'app store: (exemple, le store des extensions de chrome qui ne passent pas par l'App Store)
1) Comment Apple peut-il le savoir ?
2) Même s'il le sait, actuellement, le texte qui interdit d'utiliser un autre moteur que Webkit est celui ci (de https://developer.apple.com/app-store/review/guidelines/ :)

4.4 Extensions

Apps hosting or containing extensions must comply with the App Extension Programming Guide or the Safari Extensions Development Guide and should include some functionality, such as help screens and settings interfaces where possible. You should clearly and accurately disclose what extensions are made available in the app’s marketing text, and the extensions may not include marketing, advertising, or in-app purchases.
[...]
4.7 HTML5 Games, Bots, etc.

Apps may contain or run code that is not embedded in the binary (e.g. HTML5-based games, bots, etc.), as long as code distribution isn’t the main purpose of the app, the code is not offered in a store or store-like interface, and provided that the software (1) is free or purchased using in-app purchase; (2) only uses capabilities available in a standard WebKit view (e.g. it must open and run natively in Safari without modifications or additional software); your app must use WebKit and JavaScript Core to run third party software and should not attempt to extend or expose native platform APIs to third party software; 

Je comprends, du 4.4 qu'une extension est autorisée si il n'y a pas de marketing, pub, ou achat in-app.
Du 4.7, puisque l'extension n'est pas l'application principale (dans ce cas), qu'elle n'est pas fournie via un store, qu'elle serait gratuite, ça devrait passer. Après je ne suis pas un avocat.

Autant, c'est génial pour android, autant sur iOS, on se sent un peu seul.
D'un côté Apple verrouille à l'utilisation de son webkit limité/ant, de l'autre on voudrait de l'alternative (libre en plus).
Est-ce que vous envisagez de faire une version pour iOS de Focus avec Gecko ? (par exemple, comme une extension téléchargeable ultérieurement, afin de ne pas être backboulé par la pomme lors de l'upload de l'application  ?)

Ce serait une petite révolution sur iOS, qui le mériterait bien.

La monnaie libre a opté pour un système permettant une symétrie spatiale et temporelle en appliquant simplement une vitesse de croissance du DU. l’augmentation quantitative du DU permettant "d'oublier" progressivement les DU anciens. Un système simple et parfaitement efficace pour limiter les effets d'accaparement. La conséquence étant (dans un cas théorique sans échanges) une convergence naturelle des comptes vers la moyenne de la masse monétaire par individu. Les comptes élevés comme les compte très faibles convergent selon une asymptote vers cette moyenne d'autant plus fortement qu'ils en sont éloignés.
Un peu comme un élastique demande de plus en plus d'efforts pour s'éloigner de son point d'attache (la moyenne), l'enrichissement demandera de plus en plus d'efforts pour s'en éloigner.

Autant mathématiquement, cela pourrait revenir au même, autant psychologiquement, ce n'est pas le cas.

Lundi:

• Bonjour, combien pour la baguette de pain ?
• 10 G

Mardi:

• Bonjour, combien pour la baguette de pain ?
• 15 G

Mercredi:

• Bonjour, combien pour la baguette de pain ?
• 21 G

Pour moi, en tout cas, je préfère quand les valeurs sont stables, je peux plus facilement les comparer, les appréhender, m'en souvenir. Dans le scénario ci-dessus, je te mets au défi de savoir, de tête, combien va te coûter ta baguette dans 93 jours. Auras-tu assez d'argent de côté si tu épargnes maintenant ? Est-ce que mettre de l'argent en banque sera rentable, vu la "croissance" de la monnaie ?

Bref, une valeur qui varie est insupportable.
Paradoxalement, une valeur de référence qui se dévalue lors de l'échange l'est beaucoup moins. La baguette vaudra toujours 10 T, seulement si tu veux la payer avec l'argent de ton salaire de l'année dernière que tu as mis de côté, il faudra débourser 11 T. Après tout, c'est exactement ce qui se passe actuellement avec la monnaie-dette, sauf que l'opération est validé à la transaction, au lieu de la lourdeur des impôts (déclarations, TVA, etc…). Le 1T de différence repart dans le circuit économique comme un "impôt", une TVR (taxe sur la valeur retirée).

À propos des échanges extérieurs, c'est tout à fait possible de faire des échanges avec d'autres monnaies d'ailleurs, mais le taux de change dépendra de la valeur non dévaluée de référence, c'est à dire une valeur qui ne fait qu'augmenter avec le temps. C'est un peu le principe que vous appliquez à l'intérieur du DU, mais uniquement pour l'extérieur.

La notion de liberté est très utopique. Aucun système ne peut fonctionner sans "la mort et les taxes", car l'humain livré à lui-même est cupide et peu prévoyant en général. Il est difficile de sous réserve de liberté, laisser des personnes sans protection santé, sans assurance civile, etc… Il n'y a qu'à voir au USA ce qui se passe.
Le problème des taxes et autres, c'est dans l'iniquité de leur création/évaluation et l'utilisation qui en sont faites. Si le système de monnaie dévalue en fonction d'un vote démocratique qui a spécifié les taxes (montants, objets, résultats) et donc le taux de dévaluation, il n'y a plus d'iniquité. Évidemment, il ne faut pas concentrer le pouvoir de vote dans les mains d'un nombre limités d'acteurs comme c'est le cas dans notre démocratie, mais justement, le pouvoir des ordinateurs/algorithmes c'est de garantir la justice et l'équitabilité du vote.

La toile de confiance est trop "statique", voire binaire. C'est déjà pénible à créer au début, j'imagine combien se serait difficile à virer sa confiance dans un individu (pour que tout le monde le fasse).
Mon idée est plus granulaire, une personne qui améliore le système par son comportement est sujette à un meilleur retour du système qu'une personne qui, sciemment, dégrade le système. C'est l'effet nudge.