Potentiellement est utilisé de façon assez créative dans cette phrase.
Aucune CVE n'ont été ouvertes pour les patchs de OpenSSL à ce que je sache.
Mozilla autorise l’utilisation de la marque firefox sous réserve que le source n’est pas modifié de façon non triviale
Ce qui impose des conditions sur la distribution du code, ce qui est contraire à l'esprit du libre et la philosophie de Debian.
Ce qui, oh, comme par hasard, me parait plutôt bien correspondre au concept de « patches non voulus ».
Sauf que quand tu distribue ton code sous une licence libre, le concept de "patch non voulu" est juste stupide. Et si tu distribue pas ton code sous une licence libre, tu sera jamais intégré dans les dépôts officiels de Debian.
Cela ne t'empêche pas de fournir ton propre dépôt APT, comme ce que fait NodeJS, MongoDB, et bien d'autres.
Pour citer l'article LWN que tu a mis en lien:
The issue at hand is trademarks. Mozilla Foundation software comes with trademarked names, and the use of those names is governed by the Mozilla Trademark Policy.
C'est bien dit explicitement, si tu veux distribuer un logiciel qui s'appelle "Mozilla Firefox" ou "Mozilla Thunderbird", c'est soumis à conditions. Donc le code n'est pas libre. Donc Debian fork, retire les choses qui sont soumises à la trademark, et boom Iceweasel lui est 100% libre ce qui correspond à la philosophie de Debian.
La réponse est donc là, tu veux pas de "patch non voulu" ? Tu mets pas ton code sous licence libre. AKA: Tu ne donnes pas la liberté de le faire. (Je sens qu'à force de répéter ça, je vais finir par invoquer Zenitram).
Après, comme j’ai dit plus haut, t’es clairement la juste pour me contredire, je suppose que t’as pas supporté que je dise que C est largement cantonné à l’embarqué et bas niveau, donc je vais passer sous silence tes autre remarques qui n’ont pas grand chose à voir avec la choucroute, et je vais me retirer de ce fil, pas grand chose de productif n’en sortira.
J'y peux rien si ça fait 2 threads ou tu rabâche un ramassis de connerie. Mais bon, à la base j'avais même pas fait le rapprochement.
Ok, mais ca aide pas avec les versions majeures. Tout le monde n'a pas forcement envie de se taper des gros changements comme ca. GTK3 n'est pas source compatible avec les version précédentes. GTK4 non plus.
C'est pour ça que les distros permettent d'avoir plusieurs versions d'une même lib en parallèle. libgtk.so.3, libgtk.so.4, …
Et Debian fait un travail phénoménal pour backporter les patchs de sécurités.
Je comprends bien la philosophie sous jacente qui pousse a faire des changements qui petent tout.
Sauf que non, c'est pas ça la philosophie d'une distro. La philosophie c'est de fournir un système cohérent ou chaque paquet est bien intégré avec le reste du système.
Devnewton demande pourquoi est ce qu'on pourrait vouloir embarquer un framework en statique, je lui dit pourquoi certains sont intéressés par du tout statique.
Sauf que tes arguments à l'encontre du dynamic linking sont erronés. Je ne remets pas en cause les avantages du static linking.
il me semble qu'OpenSSL a trouvé a redire sur un certain patch de Debian.
C'est anecdotique. OpenSSL a un process de code review assez strict, et les patchs fait par Debian bypassaient ce process, ce qui pouvait potentiellement introduire des failles de sécurités dont OpenSSL n'avait pas connaissance. Ce qui est critique dans le cas spécifique de OpenSSL. Mais pour le reste, osef un peu.
Iceweasel est né d'une dispute entre Mozilla et Debian au sujet des patches de Debian dans firefox
Non, Iceweasel est né d'une dispute concernant le licencing de certains assets (images / logos / …) de Mozilla. Debian ayant une philosophie "100% libre", il n'était pas possible d'intégrer ces assets dans les dépôts officiels de Debian. La seule différente donc entre Iceweasel et Firefox, c'est les images.
Apres, tu me crois, tu me crois pas. C'est toi qui voit.
C'est pas la question. Tu avances des propos incorrects et peint une image erronée de la situation.
Linus Torvarlds a l'air d'être du meme avis que moi, et tu serais mal venu de lui expliquer qu'il est ignorant a propos des problemes de link statique vs dynamique, les chaines de compilation ou comment les distributions fonctionnent.
Linus Torvalds n'est pas un dieu, il n'a pas la science infuse, ça lui arrive d'avoir tort. Dans l'extrait vidéo que tu cites, il explique qu'il n'y a qu'une distribution Windows, et qu'une distribution Mac OS, mais plein de distributions Linux, ce qui rend le packaging par le développeur compliqué. Il enchaîne en expliquant que Valve a opté pour "embarquer le runtime avec l'application".
Ça veut dire quoi ? Ça veut dire qu'en tant que développeur d'application, je peux fournir un tar.gz qui contient mon binaire et ses libs partagées, extraire ça dans /opt, et basta. Si les mainteneurs d'une distribution veulent intégrer le logiciel au système, c'est à eux de faire le travail de packaging et d'intégration.
De nombreux projets fournissent un .deb/.rpm pour la version la plus récente, mais tu trouvera aussi un .tar.gz contenant la version portable sur toutes les distros.
La solution du .tar.gz avec tes .so dedans, ça réduit les problématiques de déploiement/distribution au même niveau qu'un binaire statique. C'est la solution que Valve a choisit, c'est la solution que Flatpak et Snap ont choisit. C'est la solution que conda (pour Python) a choisi depuis des décénies.
Si je veux m'intégrer au système et distribuer moi même un paquet .deb / .rpm, je le fais en connaissance de cause. Et j'implémente les tests d'intégrations qui vont bien.
Sous Linux, dépendre de gtk/qt/whatever ça devient plus compliqué. C’est une jungle de différentes versions
Heureusement que les distros et les devs se chargent de garder l'ABI compatible entre les différentes versions mineures.
de différentes options de compilation
Juste le classique -lmalib
compilateur
Compilo différent, même standard. Osef
Si t’arrives a être intégré upstream, ça aide
Upstream d'une distro ? Ça va rien changer à ta chaine de compilation.
mais après tu te tapes des patches qui te plaisent pas forcemment
T'as des exemples de patch non voulu sur GTK / Qt ? Qui vont impacter négativement ton appli ?
tu contrôles pas quelle version est distribué
Ah oui, parce que tu peux pas spécifier une version de ta dépendance au niveau du gestionnaire de paquet.
ce genre de choses qui peuvent être un gros problème en fonction du projet
Non, car aucune de ces choses que tu as cité ne font sens.
Si t’es pas upstream, bon courage. Ça va être la foire à « Debian machin a gtk 42.31, mais on a linké a la version 43.21 et des choses bizarres se passent ».
Tu n'aurais pas pu prendre un pire exemple:
Debian, la distro LTS par excellence qui va faire en sorte de pouvoir maintenir plusieurs version de GTK en parallèle
GTK qui change de version majeure une fois tout les 10 ans
Et du coup, l’intérêt du link statique de go devient beaucoup plus apparent.
Ah oui, c'est vrai, c'était une discussion sur le static linking, et il a fallu que tu viennes dire des inepties sur le dynamic linking, faisant office de preuve de ton ignorance sur le sujet. Totalement HS.
une faille de sécurité dans un composant critique de 80% de l'infrastructure IT mondiale
Et
une faille de sécurité dans un logiciel utilisé de manière anecdotique par quelques utilisateurs
Oui, dans les 2 cas c'est des failles de sécurité. Non toutes les failles ne se valent pas en terme de criticité. Dans le cas de Gimp, soit c'est une nouvelle faille et dans ce cas tu rollback, soit c'est une ancienne et tu attends le fix.
Dans le cas d'un composant critique tel que OpenSSL ou la stack TCP du kernel, là, il y a urgence car des millions de personnes et des milliards de devices sont potentiellement en danger.
Il faut prendre en compte la taille du vecteur d'attaque quand tu évalue la criticité d'une faille. Non un buffer overflow dans Gimp qui permet l'exécution de code arbitraire n'est pas si grave. C'est pas comme si tu pouvais en faire un rootkit. L'attaque est difficile à industrialiser car il faut que tu puisse transmettre l'image vérolée à ta cible, et être sûr qu'il va l'ouvrir naïvement avec la bonne version de Gimp et que son anti-virus ne va pas détecter du code exécutable dans une image.
Mais oui, c'est vrai, je ne comprend rien au sujet, je suis un ignare, blah blah blah, dénigre autant que tu veux. Comportement très mature de ta part.
Écrire 10 lignes de C sans UB, ça demande un talent et un temps dont peu de personnes disposent.
Et alors ?
Il faut arrêter de voir le C comme un langage haut niveau du même type que le C++ ou Python.
Le C permet des choses formidables mais il amène de gros coûts, qui se résolvent très mal avec des yakas.
Aujourd'hui, si tu as besoin des performances du C, tu y vas tout en sachant qu'il y a des footguns, et tu mets les gardes fous en place pour t'empêcher de faire de la merde.
Coder en C, ce n'est pas avoir une épée de Damoclès au dessus de la tête en plein milieu d'un champ de mine. C'est le cas si tu code sur libopenssl ou un kernel. Mais un segfault dans gimp ? Osef total, bug tracker + fix à la prochaine release.
Il n'a aucune garantie que la prochaine version de son compilateur fasse la même chose
Lorsque l'on dépend d'un undefined behavior, on lit la spec du compilo avant de le mettre à jour.
Il n'a aucune garantie que le changement d'une option de son compilateur continuera à faire un programme qui a le même résultat.
On lit la spec du compilo avant de faire joujou avec ce qui fonctionne.
Il ne faut pas avoir d'UB en se disant "je sais ce que je fais".
C'est le principe même des Undefined Behavior.
Quand tu programme en C, tu programme en C + Compilo + CPU. C'est pour ça que tu as les mots clés volatile / register / etc… pour contrôler le comportement du compilo dans ton code.
Le C est un langage bas niveau, c'est de l'ASM avec une syntaxe moins dégueulasse. Si tu fais de l'ASM sans lire la doc de ton CPU, ton programme est certain de ne pas être valide. C'est pareil en C, que tu évite les undefined behavior ou non.
Non, un programme avec un UB n'est pas un programme valide.
A ce moment là, le simple fait d'utiliser int rend ton programme invalide, car sa taille change selon le CPU.
Sauf que la, le comportement dépend du set d'instruction du CPU. Tu dis "tomber sur un modulo" parce que tu as l'habitude de l'instruction add des x86.
C'est un undefined behavior justement parce que l'on peut imaginer créer un compilo pour target un CPU qui fait les choses différemment.
Le C te permet de maîtriser tout les aspects de ton programme, depuis la conception jusqu'à l'exécution.
Tu veux être portable sur toutes les archis ? Tu évites les undefined behavior.
Tu sais quel est ton CPU target, et ta toolchain (version/arch du compilo) ? Tu prend connaissance de leur spec, et tu peux utiliser les undefined behavior qui sont spécifiés à un autre niveau
Le undefined behavior n'est pas un bug. C'est une mise en garde au développeur pour lui communiquer qu'il est censé savoir ce qu'il fait.
il ne se passe pas plus de 3 ou 4 mois sans de nouvelles cve pointant des gestions de mémoires problématiques.
Et c'est une bonne chose, cela veut dire que l'outillage pour les trouver/détecter s'améliore de plus en plus. Intégrer ce mécanisme au processus de release (via de la CI/CD par exemple) se fait de plus en plus, et avec le temps, de moins en moins de CVE seront détectées post-prod.
Quant à la question de l'assembleur elle n'a pas de sens
Si elle a du sens. Les garanties que t'offrent ton langage sont dues à l'implémentation faite par un humain. La traduction Rust -> ASM, ou C -> ASM, ou XXX -> ASM n'est pas automatique. C'est un humain qui l'a implémenté. Si l'implémentation est erronée, tes garanties sont remises en cause.
mais sa sémantique ne permet pas de s'en assurer
Pas au niveau du compilateur certes, mais le bound-checking et le tracking d'allocations, ça fait des décennies qu'on sait le faire à l'aide d'outil d'analyse statique de code. Regarde la suite de test de SQLite si tu veux un bon exemple.
Je ne vois pas comment on peut correctement utiliser un langage sans accepter de voir ses défauts (et ils en ont tous).
Je ne dis pas que le C est un langage parfait, il a des défauts. Mais la gestion de la mémoire manuelle n'en n'est pas un, c'est une feature.
Je peux me casser un doigt avec un marteau, je dois abandonner l'idée de planter des clous ou j'apprend à m'en servir correctement ?
ok, super, t'as trouvé des softs écrits en C.
Je peux te sortir swiftc ou clang ou hotspot, tous écrits en C++, ca fera pas avancer le chimilimili.
Tu dis initialement que le C n'est plus utilisé que pour les kernel/drivers et l'embarqué. Je te cite des exemples pour contredire ta mésinformation. Si la vérité t'offense, c'est pas grave.
C'est le genre de code qui rentre dans "la montagne de code a porter" dont je parlais.
Pourquoi vouloir réécrire des choses qui fonctionnent bien, qui sont testées intensivement, juste parce que "un nouveau langage hype est apparu" ?
SQLite ne sera jamais réécrit en Rust par exemple. CPython non plus. Lua non plus. If it's not broken, don't fix it.
Une réécriture complète est un travail monstre, fastidieux et long pour arriver au même niveau fonctionnel. Personne dans son bon sens ne s'attèlera à une telle tâche, à part les prosélytes du langage hype X ou Y.
Surtout si il faut le faire tout les 5 ans à chaque fois qu'un nouveau langage sort avec comme argument "le langage XXX c'est le mal, il faut tout migrer vers YYY".
Ce qui est dommage avec le C c'est juste la gestion de la mémoire très difficile et sa propension a permettre les buffer overflow par exemple.
Encore cet argument…
C'est quand même dommage, l'assembleur il y a pas de gestion de mémoire non plus et pourtant 100% des langages compilés (Rust inclut) target ce langage.
Le langage C est un langage bas niveau, il te donne des armes puissantes et un contrôle total, pour que tu puisse optimiser au maximum et à tout les niveaux. Si tu choisis de te tirer une balle dans le pied, libre à toi, il est pas là pour te prendre par la main.
Quand tu fais un logiciel dans le langage hype X, tu utilises des tests unitaires, de l'analyse statique de code, et bien d'autres outils pour t'assurer de la qualité du code. Le C n'a pas attendu 50 ans pour avoir de tels outils dans son écosystème. Dans les années 80 ces outils existaient déjà. Et ils ont très certainement été l'inspiration pour les compilateurs d'aujourd'hui.
Il n'y a pas d'autres raisons à ça que son statut
Bonjour les oeillères.
Le langage qui est utilisé comme référence en terme de performance et auquel tout les langages se comparent
Le langage qui te permet de contrôler avec le plus de précision où et quand allouer / libérer de la mémoire (as tu déjà eu des problèmes avec le GIL de Python ou le GC de Go ?)
Le seul langage qui, un demi siècle plus tard, est encore l'un des plus utilisés dans l'industrie (finance, vidéo, embarqué, OS, …)
Le langage qui est considéré comme le plus portable qui existe
Le langage qui peut s'interfacer avec tout les autres langages qui existe
Oui, ce langage ne doit son succès qu'au fait que certaines libs offrent une API C.
Aujourd'hui je n'ai pas l'impression que c'est le langage de prédilection pour ce genre de logiciels.
Non effectivement, aujourd'hui la hype c'est TypeScript + React + Electron, et ainsi tu ouvres un chrome par application (cc Slack, Teams, Atom, VS Code, Lens, Spotify, …). Quel progrès, j'ai 24Go de RAM, 85% utilisés.
SQLite n'est ni un kernel, ni un driver, ni de l'embarqué, ni un hardware digne des années 80, et il a même pas la moitié de l'âge du langage C (22 ans).
NodeJS (via NVM pour supporter plusieurs versions) avec Yarn
Rust (via rustup)
CLang et CMake
Go 1.17
Je travaille intensément avec Docker et Kubernetes (KinD en local, DigitalOcean pour la (pre)prod).
Cela va faire 5-6 ans que je n'ai plus de Linux installé en natif autre part que sur des serveurs. Ca a commencé par un ordinateur fournit par un employeur qui était sous Windows 10. J'utilisais pas mal le Windows Subsystem Linux, au début. Maintenant je ne l'utilise que rarement.
L'OS de Microsoft a beaucoup évolué et me permet d'avoir un environnement de dev efficace. Et cela m'a permit de beaucoup progresser question portabilité.
J'ai fini par tomber amoureux par le manque de choix. Au lieu de passer mon temps à tout configurer au poil, ou a tester 30 000 alternatives, je prend ce qui est fournit et je me focus sur mon travail.
Les pluriels sont des déclinaisons d'un mot. Il est donc "normal" de ne pas le trouver dans un dictionnaire. Le mot c'est "tear".
Ce que je retiens de la plupart des retours que j'ai eu, c'est que pour rendre le jeu agréable il faut passer plus que 30 secondes sur la conception de la liste.
Certes Nomad est un excellent outil. Mais le comparer à Kubernetes n'est pas très correct.
Nomad est un outil d'orchestration de conteneur et de VM. Kubernetes est bien plus que ça. Kubernetes offre des fonctionnalités comme la gestion du traffic (Service, Ingress, NetworkPolicy, …), la gestion des secrets et de la configuration (ConfigMap, Secret), la gestion du stockage (PeristentVolume, PersistentVolumeClaim, …). Il permet de gérer précisément le scheduling, le monitoring (liveness/readiness probes), le service discovery, etc…
Les opérateurs Kubernetes qui existent permettent également d'augmenter les capacités de son API, on va avoir ainsi du Cert-Manager, du Tekton, du KubeDB, du ArgoCD, etc…
Kubernetes offre aussi la gestion de cluster (drainage des nodes, ajout de worker node depuis un peu partout, etc…),
Si on veut atteindre le même niveau de fonctionnalité avec les outils de Hashicorp, il va falloir mettre en place Nomad, Vault, Consul, Terraform, etc… Tout de suite, la complexité de l'infrastructure atteint celle d'une distribution Kubernetes.
[^] # Re: Go with C
Posté par David Delassus (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 4.
Aucune CVE n'ont été ouvertes pour les patchs de OpenSSL à ce que je sache.
Ce qui impose des conditions sur la distribution du code, ce qui est contraire à l'esprit du libre et la philosophie de Debian.
Sauf que quand tu distribue ton code sous une licence libre, le concept de "patch non voulu" est juste stupide. Et si tu distribue pas ton code sous une licence libre, tu sera jamais intégré dans les dépôts officiels de Debian.
Cela ne t'empêche pas de fournir ton propre dépôt APT, comme ce que fait NodeJS, MongoDB, et bien d'autres.
Pour citer l'article LWN que tu a mis en lien:
C'est bien dit explicitement, si tu veux distribuer un logiciel qui s'appelle "Mozilla Firefox" ou "Mozilla Thunderbird", c'est soumis à conditions. Donc le code n'est pas libre. Donc Debian fork, retire les choses qui sont soumises à la trademark, et boom Iceweasel lui est 100% libre ce qui correspond à la philosophie de Debian.
La réponse est donc là, tu veux pas de "patch non voulu" ? Tu mets pas ton code sous licence libre. AKA: Tu ne donnes pas la liberté de le faire. (Je sens qu'à force de répéter ça, je vais finir par invoquer Zenitram).
J'y peux rien si ça fait 2 threads ou tu rabâche un ramassis de connerie. Mais bon, à la base j'avais même pas fait le rapprochement.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Fourvoyé
Posté par David Delassus (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 4.
Si tu veux un jeu turing complet, je te conseil Magic the gathering.
https://beza1e1.tuxen.de/articles/accidentally_turing_complete.html
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Go with C
Posté par David Delassus (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 9.
C'est pour ça que les distros permettent d'avoir plusieurs versions d'une même lib en parallèle.
libgtk.so.3,libgtk.so.4, …Et Debian fait un travail phénoménal pour backporter les patchs de sécurités.
Sauf que non, c'est pas ça la philosophie d'une distro. La philosophie c'est de fournir un système cohérent ou chaque paquet est bien intégré avec le reste du système.
Sauf que tes arguments à l'encontre du dynamic linking sont erronés. Je ne remets pas en cause les avantages du static linking.
C'est anecdotique. OpenSSL a un process de code review assez strict, et les patchs fait par Debian bypassaient ce process, ce qui pouvait potentiellement introduire des failles de sécurités dont OpenSSL n'avait pas connaissance. Ce qui est critique dans le cas spécifique de OpenSSL. Mais pour le reste, osef un peu.
Non, Iceweasel est né d'une dispute concernant le licencing de certains assets (images / logos / …) de Mozilla. Debian ayant une philosophie "100% libre", il n'était pas possible d'intégrer ces assets dans les dépôts officiels de Debian. La seule différente donc entre Iceweasel et Firefox, c'est les images.
C'est pas la question. Tu avances des propos incorrects et peint une image erronée de la situation.
Linus Torvalds n'est pas un dieu, il n'a pas la science infuse, ça lui arrive d'avoir tort. Dans l'extrait vidéo que tu cites, il explique qu'il n'y a qu'une distribution Windows, et qu'une distribution Mac OS, mais plein de distributions Linux, ce qui rend le packaging par le développeur compliqué. Il enchaîne en expliquant que Valve a opté pour "embarquer le runtime avec l'application".
Ça veut dire quoi ? Ça veut dire qu'en tant que développeur d'application, je peux fournir un tar.gz qui contient mon binaire et ses libs partagées, extraire ça dans /opt, et basta. Si les mainteneurs d'une distribution veulent intégrer le logiciel au système, c'est à eux de faire le travail de packaging et d'intégration.
De nombreux projets fournissent un .deb/.rpm pour la version la plus récente, mais tu trouvera aussi un .tar.gz contenant la version portable sur toutes les distros.
La solution du .tar.gz avec tes .so dedans, ça réduit les problématiques de déploiement/distribution au même niveau qu'un binaire statique. C'est la solution que Valve a choisit, c'est la solution que Flatpak et Snap ont choisit. C'est la solution que conda (pour Python) a choisi depuis des décénies.
Si je veux m'intégrer au système et distribuer moi même un paquet .deb / .rpm, je le fais en connaissance de cause. Et j'implémente les tests d'intégrations qui vont bien.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Go with C
Posté par David Delassus (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 3.
Heureusement que les distros et les devs se chargent de garder l'ABI compatible entre les différentes versions mineures.
Juste le classique
-lmalibCompilo différent, même standard. Osef
Upstream d'une distro ? Ça va rien changer à ta chaine de compilation.
T'as des exemples de patch non voulu sur GTK / Qt ? Qui vont impacter négativement ton appli ?
Ah oui, parce que tu peux pas spécifier une version de ta dépendance au niveau du gestionnaire de paquet.
Non, car aucune de ces choses que tu as cité ne font sens.
Tu n'aurais pas pu prendre un pire exemple:
Ah oui, c'est vrai, c'était une discussion sur le static linking, et il a fallu que tu viennes dire des inepties sur le dynamic linking, faisant office de preuve de ton ignorance sur le sujet. Totalement HS.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: enfin ?
Posté par David Delassus (site web personnel) . En réponse au lien [Github] Include diagrams in your Markdown files with Mermaid. Évalué à 2.
J'attend le support des modèles C4 dans mermaid pour m'en servir : https://github.com/mermaid-js/mermaid/issues/1276
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Encenser le C? Non!
Posté par David Delassus (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 0.
Il y a une différence entre :
Et
Oui, dans les 2 cas c'est des failles de sécurité. Non toutes les failles ne se valent pas en terme de criticité. Dans le cas de Gimp, soit c'est une nouvelle faille et dans ce cas tu rollback, soit c'est une ancienne et tu attends le fix.
Dans le cas d'un composant critique tel que OpenSSL ou la stack TCP du kernel, là, il y a urgence car des millions de personnes et des milliards de devices sont potentiellement en danger.
Il faut prendre en compte la taille du vecteur d'attaque quand tu évalue la criticité d'une faille. Non un buffer overflow dans Gimp qui permet l'exécution de code arbitraire n'est pas si grave. C'est pas comme si tu pouvais en faire un rootkit. L'attaque est difficile à industrialiser car il faut que tu puisse transmettre l'image vérolée à ta cible, et être sûr qu'il va l'ouvrir naïvement avec la bonne version de Gimp et que son anti-virus ne va pas détecter du code exécutable dans une image.
Mais oui, c'est vrai, je ne comprend rien au sujet, je suis un ignare, blah blah blah, dénigre autant que tu veux. Comportement très mature de ta part.
J'arrête de débattre avec des sourds, tchao.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Encenser le C? Non!
Posté par David Delassus (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à -2.
Non, comme je l'ai dit précédemment, j'écris du C + Compilo + CPU. Par exemple :
Comme quoi, faut bien lire tout dans son ensemble pour comprendre un argument.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Encenser le C? Non!
Posté par David Delassus (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à -5.
Comment tu peux te faire pwn avec un programme qui accède pas à internet ? Tout les échecs ne sont pas critique.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Encenser le C? Non!
Posté par David Delassus (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 1.
Et alors ?
Il faut arrêter de voir le C comme un langage haut niveau du même type que le C++ ou Python.
Aujourd'hui, si tu as besoin des performances du C, tu y vas tout en sachant qu'il y a des footguns, et tu mets les gardes fous en place pour t'empêcher de faire de la merde.
Coder en C, ce n'est pas avoir une épée de Damoclès au dessus de la tête en plein milieu d'un champ de mine. C'est le cas si tu code sur libopenssl ou un kernel. Mais un segfault dans gimp ? Osef total, bug tracker + fix à la prochaine release.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Encenser le C? Non!
Posté par David Delassus (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 1.
Et donc dans ce cas la, tu évites les undefined behavior comme j'ai dit plus haut.
Dépendre des undefined behavior ne rend pas ton programme invalide, il le rend pas portable, c'est tout.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Encenser le C? Non!
Posté par David Delassus (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à -5.
Lorsque l'on dépend d'un undefined behavior, on lit la spec du compilo avant de le mettre à jour.
On lit la spec du compilo avant de faire joujou avec ce qui fonctionne.
C'est le principe même des Undefined Behavior.
Quand tu programme en C, tu programme en C + Compilo + CPU. C'est pour ça que tu as les mots clés volatile / register / etc… pour contrôler le comportement du compilo dans ton code.
Le C est un langage bas niveau, c'est de l'ASM avec une syntaxe moins dégueulasse. Si tu fais de l'ASM sans lire la doc de ton CPU, ton programme est certain de ne pas être valide. C'est pareil en C, que tu évite les undefined behavior ou non.
A ce moment là, le simple fait d'utiliser int rend ton programme invalide, car sa taille change selon le CPU.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Encenser le C? Non!
Posté par David Delassus (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 4.
Sauf que la, le comportement dépend du set d'instruction du CPU. Tu dis "tomber sur un modulo" parce que tu as l'habitude de l'instruction
adddes x86.C'est un undefined behavior justement parce que l'on peut imaginer créer un compilo pour target un CPU qui fait les choses différemment.
Le C te permet de maîtriser tout les aspects de ton programme, depuis la conception jusqu'à l'exécution.
Le undefined behavior n'est pas un bug. C'est une mise en garde au développeur pour lui communiquer qu'il est censé savoir ce qu'il fait.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Survivor
Posté par David Delassus (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 10.
Et c'est une bonne chose, cela veut dire que l'outillage pour les trouver/détecter s'améliore de plus en plus. Intégrer ce mécanisme au processus de release (via de la CI/CD par exemple) se fait de plus en plus, et avec le temps, de moins en moins de CVE seront détectées post-prod.
Si elle a du sens. Les garanties que t'offrent ton langage sont dues à l'implémentation faite par un humain. La traduction Rust -> ASM, ou C -> ASM, ou XXX -> ASM n'est pas automatique. C'est un humain qui l'a implémenté. Si l'implémentation est erronée, tes garanties sont remises en cause.
Pas au niveau du compilateur certes, mais le bound-checking et le tracking d'allocations, ça fait des décennies qu'on sait le faire à l'aide d'outil d'analyse statique de code. Regarde la suite de test de SQLite si tu veux un bon exemple.
Je ne dis pas que le C est un langage parfait, il a des défauts. Mais la gestion de la mémoire manuelle n'en n'est pas un, c'est une feature.
Je peux me casser un doigt avec un marteau, je dois abandonner l'idée de planter des clous ou j'apprend à m'en servir correctement ?
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Survivor
Posté par David Delassus (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 8. Dernière modification le 28 février 2022 à 23:45.
Tu dis initialement que le C n'est plus utilisé que pour les kernel/drivers et l'embarqué. Je te cite des exemples pour contredire ta mésinformation. Si la vérité t'offense, c'est pas grave.
Pourquoi vouloir réécrire des choses qui fonctionnent bien, qui sont testées intensivement, juste parce que "un nouveau langage hype est apparu" ?
SQLite ne sera jamais réécrit en Rust par exemple. CPython non plus. Lua non plus. If it's not broken, don't fix it.
Une réécriture complète est un travail monstre, fastidieux et long pour arriver au même niveau fonctionnel. Personne dans son bon sens ne s'attèlera à une telle tâche, à part les prosélytes du langage hype X ou Y.
Surtout si il faut le faire tout les 5 ans à chaque fois qu'un nouveau langage sort avec comme argument "le langage XXX c'est le mal, il faut tout migrer vers YYY".
Pour ceux qui ont envie de rire un coup : https://github.com/ansuz/RIIR/issues
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Survivor
Posté par David Delassus (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 10.
Encore cet argument…
C'est quand même dommage, l'assembleur il y a pas de gestion de mémoire non plus et pourtant 100% des langages compilés (Rust inclut) target ce langage.
Le langage C est un langage bas niveau, il te donne des armes puissantes et un contrôle total, pour que tu puisse optimiser au maximum et à tout les niveaux. Si tu choisis de te tirer une balle dans le pied, libre à toi, il est pas là pour te prendre par la main.
Quand tu fais un logiciel dans le langage hype X, tu utilises des tests unitaires, de l'analyse statique de code, et bien d'autres outils pour t'assurer de la qualité du code. Le C n'a pas attendu 50 ans pour avoir de tels outils dans son écosystème. Dans les années 80 ces outils existaient déjà. Et ils ont très certainement été l'inspiration pour les compilateurs d'aujourd'hui.
Bonjour les oeillères.
Oui, ce langage ne doit son succès qu'au fait que certaines libs offrent une API C.
Non effectivement, aujourd'hui la hype c'est TypeScript + React + Electron, et ainsi tu ouvres un chrome par application (cc Slack, Teams, Atom, VS Code, Lens, Spotify, …). Quel progrès, j'ai 24Go de RAM, 85% utilisés.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Survivor
Posté par David Delassus (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 8.
SQLite n'est ni un kernel, ni un driver, ni de l'embarqué, ni un hardware digne des années 80, et il a même pas la moitié de l'âge du langage C (22 ans).
https://sqlite.org/whyc.html
CPython par exemple, c'est pas un kernel, pas un driver, pas de l'embarqué, etc… Il existe PyPy pourtant, après tout Python n'est qu'une spec.
Ou alors Lua.
Ou alors tout le domaine de la finance qui a besoin de performance à la nanoseconde près.
C'est effectivement l'observation qu'on peut faire si on détourne le regard sur ce qu'apporte le C depuis maintenant 50 ans.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
# Survivor
Posté par David Delassus (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 10.
50 ans.
50 ans que chaque année un nouveau langage apparaît pour l'enterrer.
50 ans qu'il survit. Nay, que dis-je, 50 ans qu'il est en vie!
Un demi siècle, et toujours aucun signe de la retraite.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
# La Mutuelle des Étudiants
Posté par David Delassus (site web personnel) . En réponse au lien LMDE (Linux Mint Debian Edition) 5 Beta est maintenant disponible pour des tests publics. Évalué à 2.
J'ai eu comme un mauvais souvenir qui a refait surface sans crier gare en lisant le titre.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
# Je n'utilise plus Linux sur mon poste
Posté par David Delassus (site web personnel) . En réponse au sondage Développeur Libristes, oui ! mais macOS, Visual Studio et Azure ?. Évalué à -2.
Dans mon cas, Windows 11 avec VS Code.
Parmi les toolchains que j'ai :
Je travaille intensément avec Docker et Kubernetes (KinD en local, DigitalOcean pour la (pre)prod).
Cela va faire 5-6 ans que je n'ai plus de Linux installé en natif autre part que sur des serveurs. Ca a commencé par un ordinateur fournit par un employeur qui était sous Windows 10. J'utilisais pas mal le Windows Subsystem Linux, au début. Maintenant je ne l'utilise que rarement.
L'OS de Microsoft a beaucoup évolué et me permet d'avoir un environnement de dev efficace. Et cela m'a permit de beaucoup progresser question portabilité.
J'ai fini par tomber amoureux par le manque de choix. Au lieu de passer mon temps à tout configurer au poil, ou a tester 30 000 alternatives, je prend ce qui est fournit et je me focus sur mon travail.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: fuse
Posté par David Delassus (site web personnel) . En réponse au journal [LKML] Est-ce le moment de supprimer ReiserFS ?. Évalué à 1.
De mémoire, tu peux pas avoir ton RootFS qui utilise fuse.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Dur de résister, déso
Posté par David Delassus (site web personnel) . En réponse au journal [LKML] Est-ce le moment de supprimer ReiserFS ?. Évalué à 10.
Toi tu connais pas NPM (joke aussi)
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Deuxième mot
Posté par David Delassus (site web personnel) . En réponse au journal Wordle sans attendre 1 jour. Évalué à 1.
Les pluriels des mots n'apparaissent jamais dans un dictionnaire. Étant donné que c'est ma source, normal que cela ne soit pas pris en compte.
Faire une liste complète prendrait beaucoup de temps je pense.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: ouija
Posté par David Delassus (site web personnel) . En réponse au journal Wordle sans attendre 1 jour. Évalué à 3.
Les pluriels sont des déclinaisons d'un mot. Il est donc "normal" de ne pas le trouver dans un dictionnaire. Le mot c'est "tear".
Ce que je retiens de la plupart des retours que j'ai eu, c'est que pour rendre le jeu agréable il faut passer plus que 30 secondes sur la conception de la liste.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
# Ne pas mélanger les torchons et les serviettes
Posté par David Delassus (site web personnel) . En réponse au lien Nomad vs Kubernetes pour vos orchestrations de conteneurs Docker.. Évalué à 10.
Certes Nomad est un excellent outil. Mais le comparer à Kubernetes n'est pas très correct.
Nomad est un outil d'orchestration de conteneur et de VM. Kubernetes est bien plus que ça. Kubernetes offre des fonctionnalités comme la gestion du traffic (Service, Ingress, NetworkPolicy, …), la gestion des secrets et de la configuration (ConfigMap, Secret), la gestion du stockage (PeristentVolume, PersistentVolumeClaim, …). Il permet de gérer précisément le scheduling, le monitoring (liveness/readiness probes), le service discovery, etc…
Les opérateurs Kubernetes qui existent permettent également d'augmenter les capacités de son API, on va avoir ainsi du Cert-Manager, du Tekton, du KubeDB, du ArgoCD, etc…
Kubernetes offre aussi la gestion de cluster (drainage des nodes, ajout de worker node depuis un peu partout, etc…),
Si on veut atteindre le même niveau de fonctionnalité avec les outils de Hashicorp, il va falloir mettre en place Nomad, Vault, Consul, Terraform, etc… Tout de suite, la complexité de l'infrastructure atteint celle d'une distribution Kubernetes.
Bref, Nomad c'est bien mais non ce n'est pas la même chose que Kubernetes : https://www.nomadproject.io/docs/nomad-vs-kubernetes
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Dictionnaire restreint ?
Posté par David Delassus (site web personnel) . En réponse au journal Wordle sans attendre 1 jour. Évalué à 2.
~2500 mots de 5 lettres dans ma liste vs 12478 mots au scrabble anglais. Oui il m'en manque beaucoup.
J'ai pas cherché plus de 2min :
Bim.
Si tu trouves une liste plus complète, libre à toi de faire une PR :)
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg