xryl669 a écrit 94 commentaires

Très probablement lié à ça. Très drôle.

Disons que Docker et les interfaces réseau, c'est un peu deux ennemis jurés. Dès que tu sors des 2 modes dans la doc (nat et proxy), t'es mort. Cloonix, c'est un peu plus fluide pour ça, à ce que j'ai compris (pas testé donc).

Aussi, docker propose bien plus que ce que Cloonix propose, notamment avec ses dépôts d'images. Le corolaire, c'est que le moindre conteneur est souvent énorme, vu que la majorité des utilisateurs se prennent pas la tête à le configurer au minimum de ce qu'il faut et démarre d'un Ubuntu ou un Alpine. Avec Cloonix, vu que c'est à la mano, je pense que tu ne mets rien en plus que nécessaire.

Auriez vous un exemple où un algorithme a été cassé du jour au lendemain avec un retour à 0 de la sécurité de l'algorithme ?

Pour moi, et je me trompe probablement, lorsqu'une faille est découverte, la sécurité diminue, mais ne passe pas à 0 d'un coup. Par exemple, le SHA1 qui a été "forgé/dupliqué" une première fois par Google en 6 mois de calcul et qui est maintenant attaquable en 2 mois sur des fermes de serveurs. Ce n'est pas top, c'est sûr, mais ce n'est pas comme si un principe mathématique nouveau rendait le hash réversible.

Ce qui laisse du temps au développeurs de changer leur fusil d'épaule.

AMHA, l'agilité cryptographique c'est important, mais seulement sur un set très limité d'algorithme et qui reste limité (genre 3 algos possibles, si un devient moins fiable, on le "deprecate" en le remplaçant par un autre et qui ne peut être utilisé que pour le décodage).

FreeCAD a fait d'énormes progrès concernant sa stabilité (mais c'est pas encore 100% parfait). J'arrive à modéliser des pièces vraiment complexes sans qu'il ne crashe ou me jette sur une fonction qu'il n'arrive pas à appliquer (ce qui n'était pas le cas avec la version 0.19).
Il est pas encore au niveau d'un Solidworks, mais il est très proche d'un OnShape.

Bientôt il devrait y avoir la correction du bug le plus pénible à mon sens: le topological naming issue qui est en passe d'être résolu.

C'est fondamental pour pouvoir vraiment parler de modéliseur paramétrique. Ainsi, si tu changes une variable sur une fonction en bas du stack (par exemple, la longueur d'un segment, ou le rayon d'un cercle), il ne casse plus toutes les fonctions suivantes.

Quand à la logique d'utilisation, c'est pareil pour tous les logiciels, il faut apprendre, puis après ça devient intuitif.

Solvespace est assez intuitif, il a des fonctions en plus que FreeCAD dans son sketcheur (notamment la possibilité d'appliquer une rotation multiplicative sur n'importe quel segment/curve) mais je me suis souvent retrouvé bloqué par le manque de fonctions "haut niveau".

En réalité, la seule énergie fondamentale provient de la seule force que nous ne comprenons pas complètement: la gravité

En effet, c'est uniquement que sous l'effet de la gravité que les conditions de pression (et donc de température) permettent la fusion nucléaire dans le soleil.

Le fait que le rayonnement électromagnétique du soleil nous parvienne et qu'il suffise à générer suffisamment d'énergie pour tous nos besoins n'est qu'une sorte d'anomalie, de résidu de la réaction de fusion. Nous pouvons tous vivre que parce que la réaction nucléaire de fusion n'est pas parfaite. On a une sacrée chance!

Si la masse du Soleil était encore plus grande, elle capturerait ses propres photons et nous n'aurions plus rien à voir/recevoir.

C'est également la gravité qui permet l'autre source d'énergie renouvelable non lumineuse: les marées. Pour ce faire, la Lune cède une partie de son énergie potentielle (colossale, il est vraie) à chaque marée, ce qui l'éloigne de la Terre un peu chaque jour.

La fission, les "énergies fossiles", la fusion, ne sont pas renouvelable. Seule la gravité (qui n'est pas une force, mais une déformation de l'espace, d'après la théorie de la relativité) est renouvelable.

Non je ne connaissais pas. Super cool, merci!

Il existe, en gros, 3 moteurs de CSG en open source actuellement. OpenCascade (OCCT) utilisé dans FreeCAD, OpenSCAD (qui est plus une sorte de POVRay du CAD) et Solvespace.

Du point de vue fonctionnalités, OCCT est plus utilisé car il a de nombreux outils/plugins (import/export, résolution des shells en solid, support du STEP214 en natif, etc…), mais ses limitations sont aussi son point faible, par exemple, il ne sait pas calculer l'intersection d'une surface NURBS avec une autre, ou supporter des contraintes géométriques sur des NURBS.
À noter que ce genre de calcul est extrêmement difficile (à leur décharge) car le nombre de cas particulier est très important. Il est possible que ça s'améliore dans le futur cependant.

Solvespace est utilise, quand à lui, son propre moteur CSG qui est vraiment très rapide et puissant. Il n'utilise pas des NURBS et au contraire, garde la représentation des surfaces sous forme polynomiale. Lorsque la résolution des contraintes n'est pas possible avec des solutions analytiques, il se défausse sur des solutions par approximations (comme Parasolid). Ce qui signifie que le résultat des fonctions présenté est très souvent le meilleur possible, mais que le nombre et type des fonctions est limité (par exemple, pas d'extrusion suivant une interpolation de profils, ou de sweep paramétrique etc…)

Enfin, il reste OpenSCAD. Honnêtement, je ne le connais pas bien, et la manière de modéliser dans OpenSCAD reste trop différente de ma manière de voir les pièces en 3D par fonctions successives.

Non

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…