xryl669 a écrit 114 commentaires

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…

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 ?