Cyrille Pontvieux a écrit 529 commentaires

Sauf qu’il faut parfois plusieurs cartes. Impossible d’avoir plusieurs type de tickets sur la même carte carton, et je comprends bien techniquement pourquoi.
Le truc un peu difficile du coup, c’est savoir ce qu’il y a comme ticket sur la carte carton, et leur nombre. Ils n’ont pas prévu d’endroit où on puisse lire ces cartes cartons…

Le truc cool par contre c’est que ce n’est pas nominatif et qu’on peut faire passer plusieurs personnes sur la même carte. Il suffit de présenter la carte avec les personnes voyageant avec nous en cas de contrôle.

Sur la durée, je dois avoir une carte carton qui doit dater d’un an et qui fonctionne toujours.

À Lyon on peut également payer avec sa CB directement. Pareil, éventuellement pour plusieurs personnes en passant la carte plusieurs fois.

Par contre si tu veux prendre un bus et que tu n’as pas de carte (ni carte TCL, ni carte cartor, ni CB)… ben c’est plus possible d’acheter un ticket (ou carte carton) à la montée…

… mais DNS-01 à l’air dans les cartons : https://github.com/nginx/nginx-acme/issues/11

Probablement à travers une socket sur laquelle vient se greffer le plugin du provider DNS qui va bien. Bonne archi à mon avis.

Uniquement le challenge HTTP-01. Ça va sûrement de soit, mais je tiens à le préciser pour ceux qui utilisent le challenge DNS-01 par exemple.

Reste à savoir si F5 fournira des containers nginx avec se module pré-compilé. Actuellement quand on veut un module nginx, faut le compiler… en regard des sources de la version exacte de nginx. Un peu comme les modules du noyau Linux. Ça se traduit donc en général par une compilation de nginx et des modules nécessaires. Sans un ajout comme module directement disponible ça ne change pas trop la donne étant donné qu’il existait également d’autres modules nginx qui faisaient le job, juste pas éditée par F5.

Je croise donc les doigts pour que ce module soit dispo de base… (surtout qu’il n’est pas dans le même langage que le projet, donc il faut deux compilos)

Bon c’est rébarbatif mais c’est pas fou fou non plus (si on ne regarde que les fichiers .c ou .h)

Par contre c’est vrai que le vieux code est dur à lire parce que c’est du code C dégueu (rien à voir avec le fait que c’est vieux je pense)

++(__u32*)ptr;

C’est quand même pas évident de comprendre ce que ça fait. Je savais même pas qu’on pouvait faire cette syntaxe en C !

Ça veut dire incrémente le pointer ptr de la taille d’un entier non signé 32 bits si je ne me trompe pas.

Le LLM a proposé

ptr += sizeof(__u32);

Qui se lit quand même franchement mieux, même pour quelqu’un qui fait pas du C tous les jours…

Alors est-ce que sizeof n’a été disponible dans les compilo que tardivement ?

J’étais parti de cette source mais en effet on dirait que ça s’allonge… En même temps npm (le dépôt et la société qui est derrière) n’en n’est pas à son premier flop.

Oui l’article est très bon (mais un peu long).

J’ai toutefois du mal à croire que pour un driver de lecture de périphérique, dont on se fout des droits j’imagine, cela est évolué au point que ce soit complètement différent en terme de logique.

Donc il n’aurait probablement rien « appris ». Juste à trouver les changements d’API avec les options obsolètes et les nouvelles structures.

Toutefois il dit bien qu’il s’est fait aidé par le LLM mais qu’une personne n’ayant jamais fait de driver noyau n’aurait jamais pu se faire aider. Il est probable que le temps investi par rapport au gain n’en valait pas la chandelle sans aide. En gros, seul, il aurait peut-être abandonné avant d’avoir quelque chose qui marche. Mais à deux cerveaux humains qui s’entraident ça aurait pu également fonctionner peut-être…

Si vous utilisez yarn, voici ce que vous pouvez faire pour voir si vous avez un paquet infecté :

yarn list|grep -E 'ansi-styles@6.2.2|strip-ansi@7.1.1|ansi-regex@6.2.1|debug@4.4.2|color-convert@3.1.1|color-name@2.0.1|supports-color@10.2.1|chalk@5.6.1|wrap-ansi@9.0.1|slice-ansi@7.1.1|color@5.0.1|color-string@2.1.1|is-arrayish@0.3.3|simple-swizzle@0.2.3|supports-hyperlinks@4.1.1|has-ansi@6.0.1|chalk-template@1.1.1|backslash@0.2.1'

Pour npm, il faut remplacer par npm list --all, et pour pnpm par pnpm list --parseable

En effet, merci bien !

Je comptais justement envoyer ce qu’il faut ce soir. J’ai vu passer l’annonce fin Août mais j’attendais d’être rentré de vacances pour m’occuper de ça sérieusement.

Pour l’envoi de la candidature par email, il y a un accusé de lecture possible (que je sache que le mail est pas passé dans les spams) ?

En effet, mais si tu passes par le menu (graphique c’est également possible) et que tu laisses les options par défaut, tu as compilé un noyau sans savoir rien de comment compiler un fichier C ou du reste et tu as un truc qui marche. Ça reste simple par rapport à essayer de compiler genre kdenlive par exemple (avec l’enfer des dépendances et tout ça)

Oui en effet. C’est donc bien l’OS (ici Arch ou Debian) qui décide comment découper un projet monolithique en paquets.

Arch découpe peu Systemd, Debian le découpe plus. Mais les sources sont bien monolithiques. Idem pour vlc, tu ne compiles par un plugin vlc après la compilation de base. C’est juste le packageur de l’OS qui décide de découper les fichiers produits.

Bon je suis d’accord avec toi sur l’aspect gros truc monolithique de systemd. Même si effectivement ça fait le taff (mais je suis loin de tout connaître tellement c’est gros)

Par contre pour ce qui est des paquets et de l’aspect gros truc monolithique tes exemples avec vlc ou qemu sont en fait du même acabit.

Voici le lien vers le PKGBUILD source de systemd : https://gitlab.archlinux.org/archlinux/packaging/packages/systemd/-/blob/main/PKGBUILD

On voit que ça build une fois et ensuite ça fait plein de paquets en plaçant les fichiers au bon endroit.

Pour les néophytes d’un PKGBUILD c’est les parties package_qqch.

À comparer avec :
- celui de vlc : https://gitlab.archlinux.org/archlinux/packaging/packages/vlc/-/blob/main/PKGBUILD
- celui de qemu : https://gitlab.archlinux.org/archlinux/packaging/packages/qemu/-/blob/main/PKGBUILD

C’est un peu le même style. C’est même pire pour vlc et qemu que pour systemd…

Enfin c’était pas pour te contredire sur le fond, mais voilà vlc et qemu c’est pas mieux (mais ça tourne pas en root sur le PID 1)

Je vais donner mon point de vue également.

Linux Mint c’est de la merde,
C’est les bugs de Mint sur les bugs d’Ubuntu sur les bugs et vieux softs de Debian.

C’est pas donner envie d’aller sous Linux que de conseiller une distrib où chaque mise à jour plante.

Les avis, c’est comme les trous du cul, tout le monde en a un !

Contrairement a une idée répandue, c’est probablement le truc le plus simple à compiler.

Merci pour l’astuce du raccourci clavier avec xfce4-popup-clipman, je n’y avais jamais pensé et c’est bien pratique.

Juste pour information, le projet s’écrit Xfce, sans majuscule aux autres lettres (même si on les prononce effectivement une par une)

uv a un ticket sur cette PEP, indiquant qu’ils vont d’abord commencer par le gérer en tant que format d’export

https://github.com/astral-sh/uv/issues/12584

Par contre il semble qu’il manque une pièce ou deux dans le standard actuel pour accepter l’ensemble des options actuellement disponibles dans uv. C’est assez surprenant étant donné que les implémentations actuelles (uv, poetry, pdm) ont été consultées pour arriver à ce standard.

Je n’ai rien trouvé chez Poetry.

Oui je l’espère !

Par contre pas pipenv, qui n’utilise pas pyproject.toml.

Il n’est d’ailleurs pas cité dans la PEP.

Et il est lié à une version précise de Python, et un environnement précis (windows, linux, arm, …)

C’est, parmi les formats de lock existants (non-standard), le pire.

J’ai mis la touche Compose sur CapsLock également. Je suis sous Xfce.

C’est vraiment pratique. J’ai également un peu étoffé mon .XCompose.

Autant on est sur un site français et ça aurait du sens, autant vu que c’est dans la section Liens et que le lien est un article en anglais. Si on ne comprends pas l’anglais ça ne sert à rien de traduire en français uniquement le titre…

Si j’ai bien compris c’est deux cacas nerveux : 1. un qui veut pas intégrer une interface rust pour accéder à une interface C. 2. un qui veut pas gérer cette interface comme patch du kernel (le temps que le type en 1. décide de l’intégrer upstream).

C’est quand même un beau drama pour pas grand chose…

Par contre, je me demande si ça va pas freiner à mort la distribution de PC sous OS libre… étant donné que ça donnerait le statut de distributeur au vendeur de matos + OS (même si l’OS n’est pas monétisé) et donc ça le soumettrait au CRA.

J’ai pas trouvé d’exemple dans le rapport en regard de ce cas. Car évidemment, PERSONNE ne peut prendre en compte un OS libre, et donc tous les logiciels préinstallés, au titre du CRA…

Je vais citer une partie du rapport, que finalement j’ai lu, pour bien préciser une chose importante :

Le principe développé par le CRA est que seuls les produits distribués dans un cadre commercial
sont soumis aux exigences de cybersécurité du Règlement. L’activité commerciale est caractérisée
lorsqu’un produit est monétisé par son fabricant d’origine, mais il est tout à fait possible de
contribuer à un logiciel Open Source sans être dans un cadre commercial17. En droit européen, la
qualification d’une activité comme commerciale repose sur la notion d’activité économique, définie
par la Cour de justice de l’Union européenne (CJUE) comme « toute activité consistant à offrir des
biens ou des services sur un marché donné ». À ce titre, il apparaît que certaines activités d’acteurs
économiques (indépendamment de leur statut juridique et de leur mode de financement) peuvent être
considérées comme non commerciales, notamment s’il est possible de démontrer que :

1. la distribution est gratuite et sans objectif lucratif18 (c’est-à-dire sans contrepartie financière directe et sans intention de profit) ;
2. le financement est assuré par des dons ou des subventions (pour les projets Open Source soutenus par des contributions volontaires ou des subventions publiques sans revenus tirés de la vente de produits ou services) ;
3. l’absence de services payants associés (services associés tels que le support technique, la formation, l’hébergement ou la personnalisation).

En conclusion, il apparaît que de certaines pratiques d’acteurs de l’Open Source entrent dans les
situations qui ne sont pas nécessairement soumises aux nouvelles exigences du CRA compte tenu
de l’absence d’activité commerciale.

Ça veut dire que ça concerne pas beaucoup de logiciels libres. Ça va concerner nginx et mongodb/ferretdb par exemple, mais pas lighttpd ni pgmongo. En tout cas si j’ai bien compris ;-)

Il y a également Aliza MS et Weasis comme viewer de fichiers DICOM (tous les deux dispos en flatpak).

Je les ai utilisés récemment pour lire des radios ou des IRM, ça marche très bien. Après faut les connaissances pour interpréter…

… que c’est la bonne période pour que je fasse ces mises à jour Nextcloud que je reporte sans cesse…