paulez a écrit 387 commentaires

Ça c'est une tuile si Daniel ne peut plus continuer à bosser sur Conversations !

J'utilise spacemacs qui permet d'utiliser Emacs comme Vim, avec tout un tas de modes et plugins déjà configurés. C'est mon IDE idéal depuis quelques temps déjà !

L'AGPL a des risques légaux trop importants, donc elle est bannie de pas mal d'entreprises. Donc forcément ça impacte la popularité des projets AGPL.

Un exemple avec Google :

WARNING: Code licensed under the GNU Affero General Public License (AGPL) MUST NOT be used at Google.

J'ai du mal à comprendre ce que fait le patch exactement, mais si j'en crois le test qui est ajouté il corrige le comportement dans le cas d'un fichier mp3 qui embarquerait un "cover art". Je suppose un mix d'erreur de validation qui permettrait d'extraire des données à partir d'un fichier corrompu (peut-être des métadonnées dans un fichier mp3 déguisées en covert art pour en extraire le contenu à un chemin spécifique).

Avec CVE-2023-36460 si tu peux écrire un fichier à un chemin arbitraire, tu peux potentiellement remplacer un exécutable (ou simplement un script PHP) et donc exécuter du code arbitraire par ce biais.

En effet il semble que ça soit l'UEFI qui s'occupe de faire les transitions mode réel, protégé et long (64 bits).
Donc ça n'impacterait que les OS qui peuvent démarrer seulement en mode BIOS (pour Windows antérieur à Windows Vista SP1).

Je pense que tout est assez clair dans l'annonce d'Intel: https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html

Les apps 32 bits sont toujours supportées d'après le tableau "Supported and unsupported modes in X86S". Les apps 16 bits ne le sont pas.

Le seul moment où ça parle de virtualisation c'est pour booter les OS "legacy" 64 bits. Logique, vu que la proposition modifie comment booter un CPU, les OSs qui utilisent l'ancienne séquence ne fonctionnent plus.

Là ce qui m'étonne c'est que personne n'a l'air de comprendre la même chose que moi, mais je pense que ça signifie que tous les OS actuels en l'état ne fonctionneront plus sur x86s.

Que ça soit Windows 11 (sans mise à jour), Debian 11, Windows XP, etc. ne booteront pas sur X86s, les démarrer nécessitera de la virtualisation (uniquement dans une VM donc).

C'est quand même un sacré cassage de compatibilité, vu qu'un PC moderne est censé pouvoir booter n'importe quel OS x86 (s'il supporte le mode BIOS).

J'utilise une solution de sauvegarde en plus de Nextcloud pour mes données. Nextcloud c'est uniquement un outil de synchronisation.

Exemple simple, je garde un fichier Keepass dans mon Nextcloud. Un client Keepass Android l'a écrasé avec un fichier vide, qui a été propagé par Nextcloud. J'ai pu rattraper le coup avec mes sauvegardes, en restaurant le fichier écrasé.

C'est dans la lib standard, pas téléchargé par Cargo à priori mais fourni directement par le compilateur.

Je ne sais en effet pas comment trouver si un programme est impacté, ça m'intéresse.

Oui car simplement savoir ce qui doit être redémarré ou pas n'est pas simple, il faut généralement utiliser un outil comme "needs-restarting" sous Fedora ou "needrestart" sous Debian. Donc si on veut automatiser ça la manière la plus sûre est de toujours redémarrer.

Il y a même des cas où une mise à jour peut avoir des effets très étranges sur tout le système avec dbus ou systemd, car le processus a déjà été lancé, mais il charge une librairie dynamique, et il peut y avoir une incompatibilité entre les deux après une mise à jour.

Du coup ce que fait Fedora Workstation qui demande systématiquement de redémarrer pour installer les mise à jours est en fait la méthode la plus fiable, même si c'est parfois un peu frustrant.

Sous Linux le processus continue à utiliser l'ancienne version du fichier, potentiellement vulnérable pour une mise à jour de sécurité. Donc au final il faut au moins redémarrer l'applicatif, ce qui revient vite au même.

En effet c'est un problème courant avec la JVM, surtout qu'on peut la configurer pour limiter la mémoire allouée pour le tas (la "heap" en langue de Shakespeare). C'est pour ça que ça peut rester invisible dans les métriques système.

Tu peux tester en augmentant cette limite avec le paramètre -Xmx.Tu peux aussi surveiller en temps réel le temps passé à utiliser le ramasse-miette (Garbage Collector) avec JMX et les métriques CollectionTime et CollectionCount.

Pour jouer avec une carte graphique NVidia tu devras utiliser leur pilote propriétaire, qui peut parfois être galère à installer ou poser des problèmes de compatibilité. Certaines distributions rendent son installation plus aisée que d'autres, par exemple sous Ubuntu tu ne devrais pas avoir trop de problème avec Nvidia.

Les cartes AMD sont supportées par les pilotes graphique standards et libres sous Linux, ce qui garantit une meilleure compatibilité. J'ai une vieille RX 480 et les performances dans les jeux sont excellentes.

Personnellement je n'achète que des cartes graphiques AMD pour cette raison, mais il reste tout à fait possible de jouer avec du Nvidia sous Linux.

Au niveau de la distro la plus performante pour jouer, à mon avis il n'y a pas trop de différence aujourd'hui. Je favoriserais plutôt la distro sur laquelle tu seras le plus à l'aise pour utiliser et installer tes jeux. Ubuntu est certainement celle sur laquelle tu trouveras le plus d'aide car très utilisée.

Personnellement j'utilise Fedora mais pour des raisons qui n'ont rien à voir avec le gaming. Si tu viens juste de quitter Windows, je te recommande de commencer par Ubuntu, Arch est un peu abrupte et difficile à appréhender comme première distribution.

"S'il y a ce genre de besoins" est-ce qu'il n'y a pas toujours besoin d'éviter les bogues ?

Je comprends qu'en C on n'a pas de mécanisme de protection, mais je demande quels seraient les outils à toujours utiliser aujourd'hui pour éviter 99% de ce type de problème (s'ils existent).

Pas mal !

Aux experts du C, quels sont les bons outils pour repérer automatiquement ce genre de bogue ? Je suppose qu'il y en a pas mal du genre qui traînent…

Il y a beaucoup de bonnes raisons pour mettre des data-centers en Irlande: bonne connectivité avec les États-Unis (beaucoup de câbles transatlantiques arrivent à l'ouest de l'Irlande), climat clément qui permet de refroidir sans clim, etc.

Le problème de l'Irlande c'est qu'étant une île les capacités de connexion avec le réseau Européen sont limitées, et il y a peu de capacité de production locale. Une bonne partie de l'électricité est importée du Royaume-Uni via le East-West Interconnector.

Ça doit bien faire depuis 2008 que j'utilise exclusivement les driver libres AMD/Radeon. Au début ça marchait pas top, mais depuis au moins Debian 9 les performances et la stabilité sont au rendez-vous.

En effet il vaut peut-être mieux utiliser la génération précédentes de cartes, la stabilité s'améliorant au fil du temps.

J'ai eu un instabilité chronique de mon système pendant quelques temps avec un CPU AMD, résolue en passant à un CPU Intel. Donc pour l'instant je considère le couple CPU Intel/GPU AMD comme le plus adapté sous Linux.

Dommage que AMD conserve une mauvaise réputation pour ses GPUs sous Linux, alors que c'est clairement mieux que NVidia depuis quelques temps déjà.

Si tu n'aimes pas les changements réguliers dans Firefox, la version ESR bouge moins, ça évite de devoir changer ses habitudes trop souvent !

Remarque c'est peut-être une bonne chose si c'est pour installer une mise à jour de sécurité évitant un potentiel défaut de confidentialité sur ta transaction bancaire.

Ah et j’oubliais, il n’y a pas de version non libre de MariaDB, donc c’est faux de dire que le support est pour la version non libre.

MySQL en son temps était disponible en licences libre mais aussi propriétaire, tout le code étant la propriété d’une entreprise (maintenant Oracle). MariaDB étant un fork de MySQL (autorisé par la GPL) n’a pas la propriété intellectuelle de l’intégralité du code, et ne peux donc pas le distribuer sous une licence non libre car ce serait une violation de la GPL.

La licence de SQLServer limite la garantie à 90 jours, et la garantie couvre simplement le remboursement de la licence. La licence précise bien que la garantie ne couvre pas les dommages liées à l’utilisation du logiciel, tout comme la GPL.

Donc au final avec SQLServer Microsoft peut te rembourser le prix de la licence dans le cadre de la garantie et c’est tout. Avec MariaDB pas de garantie mais la licence est gratuite. Où est donc l’avantage ?

Pour le reste il y a le support, et MariaDB qui est éditeur du logiciel MariaDB en fournit, comme Microsoft, mais aussi Oracle pour MySQL, RedHat pour RHEL, etc.

Le logiciel libre est né aux États-Unis, pays qui autorise la vente libre d’armes à feu.

Il y a différentes conceptions de la liberté de part le monde, et donc le libre de logiciel libre n’a pas le même sens pour tout le monde.

Un des arguments pour continuer d’autoriser la vente d’armes aux États-Unis est de garantir la liberté des citoyens. À mettre donc en parallèle avec l’argument que les logiciels doivent être libres.

Tout le monde n’a pas la même conception de la liberté, et donc je ne considère pas que chaque partisan du logiciel libre va avoir la même vision de ce qui est moral ou pas, voire probablement l’inverse.

Donc forcément si on veut restreindre l’utilisation d’un logiciel uniquement pour des causes morales, on est dans une situation qui ne va pas convenir à des nombreux partisans du logiciel libre.

C’est pas une question d’être pragmatique ou pas, c’est pour moi une question de divergences profondes sur des notions essentielles comme la liberté et la morale, très difficiles à concilier dans une communauté mondiale.

Le proprio, souvent décrié, a aussi des choses que l'on ne retrouve pas dans le libre, comme une garantie. Tu as un crash avec MariaDB et tu perds tes données ? Tu pleures. Tu as un crash avec SQL Server ? Microsoft est à tes côtés (oui oui, c'est pas des blagues, ni un troll, malgré qu'on soit trolldi).

Je ne pense pas que ça soit un bon exemple, tu peux très bien avoir du support avec MariaDB comme ne pas en avoir avec SQLServer si tu ne paies pas pour.
Je dirai plutôt que c’est un bon exemple d’une incompréhension du logiciel libre.

Ça dépend du droit du travail, mais dans certains cas l’employeur peut prétendre aux droits de propriété intellectuelle sur du logiciel créé par un employé pendant son temps libre. C’est le cas je crois dans certains états aux USA, mais pas tous.

En France il me semble que l’employeur ne peut pas le faire (à confirmer).

Comme quoi avoir un droit du travail protecteur, ça a du bon !

Les solutions pour livrer un logiciel avec un environnement fixe existent, AppImage comme tu l’as mentionné, Flatpak et Snap.
Livrer ses logiciels avec ses propres versions de lib c’est de la grosse bidouille qui n’a pas lieu d’être à mon avis maintenant que ces solutions existent. Donc je rejoins l’avis du mainteneur Fedora.
Le fait de livrer sa propre version d’OpenSSL ne pose pas problème uniquement pour le protocole SSL, n’importe quelle lib peut-être utilisée comme vecteur d’attaque, comme par exemple exécuter du code avec une vulnérabilité d’une lib PNG.

Au niveau des backports, chaque distro le fait plus moins pour diverses raisons, difficile donc de juger sans plus de contexte.