xryl669 a écrit 106 commentaires

Je vois beaucoup de news sur LibreOffice, mais quasiment aucune sur OnlyOffice, qui est, pour moi, bien meilleur (surtout niveau interopérabilité DOCX/XLSX, interface, ergonomie, collaboration, etc).

C'est bien dommage. C'est pas pour critiquer LibreOffice, mais vous faîtes un petit tour des solutions alternative et vous ne citez pas son principal concurrent en open source, c'est sacrément dommage.

Bon, c'est vrai, mais il y a aussi tout ce que tu peux faire en C++ et que tu ne peux pas faire en Rust justement parce que le compilateur tient à forcer une seule méthode de gestion des données.

Par exemple, une liste doublement chaînée, en Rust, sans unsafe, c'est la galère, vu qu'il y a 2 pointeur pour un seul objet. Un structure récursive aussi c'est difficile à implémenter, tu passes un temps fou à te battre avec le compilateur pour qu'il accepte ce que tu lui décris (mais ça c'est grandement amélioré ces dernières années).

En C++, tu peux te tirer une bombe dans le pied avec une seule ligne de code, mais dès que tu as un peu d'expérience, ça devient bien plus rare et de toute façon, assez facile à débugger. La programmation template, aussi c'est franchement le top (mais c'est imbuvable) pour créer du code assez magique et optimal.

En Rust, tu as le pouvoir des macros qui franchement manque au C++ avec le pre-processeur tout pourri.

Ça n'empêche pas en théorie de faire des choses comme de l'adressage dynamique, même si j'ai du mal à voir l'intérêt de la chose.

Moi aussi, et c'est aussi l'avis de l'auteur. Mais malgré tout, il existe wg-dynamic pour la gestion des IP dynamiques.

WG c'est plutôt comme un bridge à l'usage. Tu as ta carte Ethernet/Wifi connecté à l'internet et WG crée une interface virtuelle (wg0) avec une IP privée (type 10.x.x.x) et une règle de routage entre les réseaux de telle façon à ce que tu puisses parler, via ce réseau privé (10.x.x.x) aux autres membres du réseau (10.x.x.y et 10.x.x.z etc…).

J'ai du mal à voir l'intérêt d'un proxy ARP ou NDP qui sont au niveau 2 (MAC) sur ce genre de montage, vu que ce genre de proxy sert justement lorsque tu n'as pas de table de routage (c'est quand même hachement plus simple de faire un ip route add via que d'avoir à mettre en place un proxy ARP). D'autant plus que l'ARP c'est du broadcast, donc pas top pour du VPN un peu étendu. Après si tu y tiens absolument, il y a OpenDaylight.

Par internet ? Comme n'importe quel autre logiciel en fait. Wireguard c'est un tunnel crypté, fourni soit avec le noyau ou à côté, comme module, ou en user space, bref, t'as l'embarras du choix.

Vu que c'est level 3, aucune des fonctions que tu listes n'entre dans le champ technique de WG. Rien ne t'empêche de faire de l'IP dynamique, du LDAP, du TURN, ce que tu veux.

Oublie WG un instant et demande toi comment faire ça avec une simple carte Ethernet, wg est une interface en plus, ça marche pareil.

Donc oui, tu peux avoir un DHCP sur WG, ce serveur DHCP peut consulter un annuaire pour assigner les IP, tu peux utiliser TURN pour passer le double NAT et ensuite démarrer WG à travers le trou (et c'est même assez simple avec systemd d'ailleurs)

Ce n'est pas le rôle de WG de faire ça (à la Unix-style: WG fait un seul truc et bien). D'ailleurs, je ne pense pas que OpenVPN ne le fasse aussi.

Je pense que tu confuses. Wireguard c'est un outil qui utilise de nombreuse primitives cryptographiques: (ChaCha20 pour le chiffrage symétrique, Curve25519 pour DH, BLAKE2S pour le hashing, HKDF pour la dérivation des mot de passe/clés, …). Tu remarquera qu'il s'agit des primitives "à la mode", c'est à dire celle qui sont le plus efficace et sécurisées pour le moment.

Mais, contrairement à TLS, il n'y a pas de négociation d'algorithmes et de capacités (ce qui est plus source de problème plus que d'intercompatibilité, AMHA), vu que le protocole défini les primitives utilisées.

Si, à l'avenir, une primitive s'avère problématique, je suppose qu'ils feront avancer la version du protocole pour échanger une primitive avec une autre, en rendant obsolète la primitive à problème.

Pourquoi un bash -c ? Tu peux directement lancer /bin/ssh. Par contre, ce genre de service est assez dangereux (lancer en restart automatique un ssh en root, c'est s'exposer à des failles type TOCTOU vu le nombre de fichier parcourus par ssh pour démarrer). Je pense que stunnel est dans ce cas bien plus adapté (ou mieux, Wireguard)

Pour l'animation vectorielle, je te conseille pas Synfig, mais plutôt glaxnimate qui est excellent et produit des animations très légères (comparé à Synfig). L'interface est très proche d'Inkscape, ce qui est un vrai plus.

Liste des erreurs:
1. Payload dans MQTT non typé (et pas forcément JSON)
2. Authentification forte: à partir de MQTTv5 pour une version non basée sur utilisateur/mot de passe
3. AMQP n'est pas similaire à MQTT. C'est un protocole de messagerie, et pas de transfert de paquets avec résilience
4. Les versions MQTT sont rétrocompatibles car la session est taggué par la version du protocole utilisé, ce qui veut dire qu'un broker MQTTv5 peut dialoguer avec un client MQTT v3.1.1. Après, un client MQTTv5 ne peut qu'implémenter MQTTv5 et pas MQTTv3.1.1 (principalement pour des raisons de ressources, pas de difficultés particulières pour supporter une version précédente). Les brokers MQTTv3.1.1 uniquement sont de plus en plus rares et difficilement gérable pour une flotte IoT.
5. MQTT est n'est pas un service de messagerie (car il ne stocke pas les messages, tout au plus le dernier). C'est un service de transfert de paquets avec résilience (c'est à dire avec des garanties sur la livraison d'un paquet et ou d'un état d'un système).

Une des avancées majeure de MQTTv5 c'est la possibilité ajouter des propriétés aux paquets. Dans ces propriétés, on trouve la possibilité de déclarer la taille maximale d'un paquet que le client déclare supporter (contrairement à MQTT v3.1.1 qui autorisait un paquet de 250Mo à transiter), mais également les méthodes d'authentifications supportés (type négociation SSH), le type des données transmises, etc…

Pour envoyer une image, il suffit simplement de définir le payload sur les octets de l'image encodée. Soit tu décides que le topic/sujet sur lequel tu envois ces paquets est associé à un type MIME et dans ce cas, c'est fini, soit tu autorises différents type et dans ce cas, tu ajoutes une propriété Content Type avec le type MIME (de telle façon à ce que le client puisse décoder le flux).

En C++ récent, le code devient très vite cryptique, d'autant plus qu'il faut contourner les interprétation fallacieuse du standard par les différents compilateurs.

Pour cela, il y a cppinsights.io qui explique comment un meta programme est interprété (compris) par le compilateur.

Cela permet d'écrire du code template plus robuste, plus complet et plus lisible parfois.

Le payload MQTT est complètement libre, ce n'est pas forcément du JSON. Tu peux y mettre du binaire (pour l'OTA ou pas) ou ce que tu veux. Tu n'es pas du tout obligé d'encoder en base64 des images pour les transmettre.

MQTT existe en différentes version, la 3.1 et la 5 sont actuellement les plus utilisées. La version 5 permet des authentification forte (c'est à dire type Diffie Helman, sans le fâcheux username/password qui doit être stocké en dur dans le client, donc hackable facilement). Il gère également les propriétés sur chaque packet, ce qui permet de réaliser beaucoup plus de chose que la version 3.

Pour les clients MQTT, je te recommande eMQTT5 qui est un client MQTTv5 en C++ pour l'embarqué, type ESP32, (mais fonctionnant également sur Linux / OSX / Windows) et très léger (moins de 80kB sur x86, et 17kB sur Xtensa).

Il possède également un parseur de packet MQTT ce qui est très pratique pour déboguer une communication qui échoue.

De plus à la différence des autres protocoles, MQTT impose au broker de stocker l'état d'un client et d'éxécuter ses dernières volontés en cas de déconnexion, ce qui est super pratique pour l'IoT (qui peut ainsi s'assurer d'avoir un status "connecté/déconnecté" fiable) et permet aussi de récupérer sa session lors d'un connexion ultérieure (pratique pour le roaming, ip changeante, etc…)

Aucun des autres protocoles ne permet ceci (ou alors, c'est en plus, non standard).

Le fonctionnement sur Hellobank / BNP est identique, voire moins sécurisé, vu qu'ils demandent le mot de passe du compte avant d'envoyer le SMS (il n'y a pas de petites économies, hein?)

Ce qui me rends dingue, c'est qu'il n'y a pas de moyen d'éviter cette daube.

Comment un informaticien peut coder ça, sérieux ?
Une simple capture du HTML + CSS et c'est le paradis du phishing.
1. Tu proposes un site bidon avec de la vente de produit pas moins cher que d'habitude.
2. Puis tu demandes de payer avec ta CB. Avec les 4 premiers numéro de la CB, tu identifies que la CB provient du réseau BNP.
3. Tu balances une fausse iframe avec les bons logos et autre DOM/CSS que tu as capturé, et une iframe (inaccessible, dans la marge) sur le site d'Hellobank/BNP pour capturer les formulaires enregistrés (l'identifiant du compte n'est pas codé, il est en clair).
4. L'utilisateur va entrer son mot de passe de connexion. Avec l'identifiant capturé dans l'iframe plus le mot de passe de l'utilisateur, tu te loggues sur Hellobank.
5. Hellobank/BNP va détecter que ce n'est pas la même origine que d'habitude et va donc t'envoyer un SMS avec un code de connexion.
6. Tu demandes à l'utilisateur sur le deuxième page de l'iframe le code reçu.
7. L'utilisateur va entrer le code, forcément (même si le montant de l'achat n'est pas spécifié, car quoi, lui ne sait pas comment doit être le SMS).
8. Voilà, tu peux donc accéder au compte de l'utilisateur. Lui pomper ces données et ses sous.
9. Si tu veux pousser le vice encore plus, tu envoies un pseudo message d'erreur à l'utilisateur dans la troisième page de l'iframe, avec un bouton pour qu'il demande le renvoi du code reçu. (Forcément, aucune banque n'accepte de retaper un code, c'est supposé être du one-shot)
10. L'utilisateur va très probablement cliquer sur le bouton. Parallèlement tu procèdes à un vrai achat pendant ce temps, vu que tu as tout ce qu'il te faut (mot de passe + code SMS entré par l'utilisateur, cette fois pour le "vrai" achat).
11. Voilà, l'utilisateur va recevoir un mail légitime de la banque lui indiquant qu'il a dépensé X€ chez machin chose.

Toi, t'as gagné un accès direct sur son compte pour 3 mois.

C'est franchement donner le bâton pour se faire battre à ce niveau.

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.