Tangi Colin a écrit 246 commentaires

En terme de rendu graphique qu'est ce qui est supporté ? Surtout coté embarqué, coté QT on a leur backend EGLFS pour utiliser le GPU en direct sans avoir besoin d'un serveur X/Wayland. A-t-on quelque chose d'équivalent coté slint ou est-ce uniquement un rendu via CPU ?

Tu peux clarifier pourquoi une méthode agile ne serait pas adapté à un OS X sur un hardware Y ? (z/Os ou autre d'ailleurs). J'ai du mal à comprendre pourquoi.

Après y a agile et agile, y a l'agile du manager/chef de projet qui trouve le terme cool comme cache-misère de la Rache et y a les vrais méthodologies agile, avec des rôles clairement définie, beaucoup de micro-management etc…

C'est surtout ce couper d'un très grand écosystème. Ne pas avoir accès à epbf pour de l'optimisation réseau alors que de plus en plus de smartnic en propose un offload hardware c'est dommage je trouve.

Pareille côté I/O, se passer del'api io_uring est vraiment dommage.

et personnellement, je suis bien plus intéressé par le travail pragmatique de Kernel Self Security Project (KSPP) de rajouter des contre-mesure de cyber/hardening du kernel qu'un hypothétique réécriture du kernel en Rust qui va prendre des dizaines d'années à minima.
J'attends avec impatience les 1er chips ARMv9 pour y activer du HW_KASAN (https://lwn.net/Articles/834937/) en production, ça sera bien plus efficace et disponible dès le premier trimestre 2022.
Malgré le fait d'avoir du code C et donc tous ces défauts lié à son veille âge, si tu as un kernel récent et que tu active toutes les contre-mesure existant : W^X, strong canary, PXN/PAN, KASLR, CFI, KASAN et que tu réduis la surface d'attaque de ton kernel via des containers (seccomp) tu es déjà bien protégé.

Je dirais surtout heureusement que le boulot fournie par kspp avec dernièrement CFI et demain HW_KASAN sur armv9, l'intérêt des patch grsecurity sont grandement diminués,un kernel récent, mainline sur la bonne archi et bien configuré est suffisant.

Tu aurais pu citer quelqu'un d'autre que grsecurity, car leur approche de la gpl est un peu borderline. Si en tant que client tu redistribue leur patch gpl, tu perds leur contrat de support. C'est pas illégale en soit mais c'est assez limite.

L'existant s'améliore de plus en plus avec le projet kernel self protection projet (KSPP) lead par Kees Cook. Certes, sa reste du C avec ces problèmes historiques mais si aujourd'hui tu active toutes les fonctionnalités orientées cyber : W ^ X, PAN/PXN, KASLR, CFI tu es déjà pas mal. J'attends avec impatience l'arrivée des puces armv9 pour rajouter MTE/KASAN_HW_TAG pour compléter tout ça.

Ça sera jamais aussi pur théoriquement qu'une réécriture from scratch en rust mais ça me paraît tellement plus réaliste et pragmatique comme approche.

La si j'ai bien compris on a une ABI posix/Linux très basique (fork, pipe…).
C'est clairement insuffisant pour du Linux moderne, quid de ebpf ? Quid des namespaces et cgroup ? Quid d'io_uring ?

Vaste sujet. Déjà je trouve les gens du gaz très fort pour trouver un nom marketing acceptable, après le gaz naturel (beaucoup plus sexy que propane/butane), on a le droit au "bio-gaz", puisque c'est bio c'est que c'est forcement bon non ?

Quand on regarde dans le détail, on trouve pas mal de situation ubuesque. Déjà mettre des sites industrielles de "biométhaniseur" chez des agriculteurs pose question pour la sureté des installations. On a déjà plusieurs retour d'expérience avec des dégâts important à la clefs (explosions, fuites et donc pollutions importantes des nappes etc…).
Voir : https://www.aria.developpement-durable.gouv.fr/?s=methaniseur&fwp_recherche=methaniseur (y a de tout la dedans, des incidents mineurs sans gravités à des accidents grave entrainant coupure de l'alimentation en eau de plusieurs communes sur plusieurs jours).
Comme toute industrie, il y a des risques, le gaz fait partie des industries lourde, bio ou pas, mal contrôlé ça peu faire pschitttt voir boum.
Maintenant si on regarde le sujet du "bio-gaz", ça implique une forte déconcentration, des méthaniseurs partout sur le territoire, dans plein de ferme agricole. Je suis vraiment septique sur la capacité à pouvoir contrôler et maintenir tout ça sur le long terme et de manière fiable et sure.

Si a ça on rajoute la folie économique actuelle, où entre les subventions économiques et le prix de rachat du bio-gaz, certains agriculteurs rachète tous le foin et paille du coin pour le mettre dans leur méthaniseur, privant de ce fait certains autres d'agriculteurs, d'éléments de base pour leur élevages…
Sur les digestats épandues dans les champs, il n'est pas encore claire si cela a ou n'a pas une incidence néfaste ou bénéfique sur la vie du sol à long terme. La littérature sur le sujet est encore jeune et on peut trouver du pour ou du contre. Il semblerai que si le méthaniseur incorpore des matériaux qui ne retournaient pas dans le sol avant, alors l'apport en carbone serait bénéfique, si c'est l'inverse (consommation importante de lisier par exemple) alors on serait plutôt perdant.

Si on rajoute à ça les tournée de camions/tracteurs avec remorques pour alimenter le méthaniseur, camions fonctionnant au gasoil, je suis pas persuadé que ça soit la solution du siècle, ni très pérenne sur le long terme.

Je suis pas un pro-nucléaire, je constate juste que sur le nucléaire, puisque c'est dangereux, il y a un certains nombre de contrainte réglementaire et contrôle fait dessus par l'ASN. Peu de site, beaucoup de contrôle. Niveau méthaniseur, bien que le niveau de risque soit inférieur, la filière manque clairement d'une instance de contrôle puissante pour le moment et vu le nombre de site, je doute qu'on arrive à faire mieux un jour (ça demanderai énormément d'agents pour contrôler tout ça).

Mettre un lien en provenance du site reporterre pour ce genre de sujet manque clairement d'objectivité je trouve. Dire que RTE oublie la sobriété est aussi un parti pris très critiquable. Le rapport commence par rappeler qu'il faut passer de 1600TWh d'énergie finale à 930TWh, si ça c'est pas de la sobriété je sais pas ce que c'est. Et on est actuellement pas sur la bonne pente pour tenir cette objectifs. Et on parle d'énergie finale, pas uniquement d'électricité, alors oui si on a pour réel objectif le climat, l'ennemi c'est le CO2 et donc c'est le pétrole et le gaz qu'il faut bannir, donc électrifier des pans majeurs de nos société (transport, agriculture, chauffage …) en plus de la sobriété.

Donc dire la consommation d'électricité va augmenter n'est pas incompatible avec la sobriété.

Même des "collapso" sont plus nuancé que reporterre sur ce rapport RTE, voir par exemple : https://twitter.com/AEffondrement/status/1452728645206913029

avec les regroupements de communes, cette longueur maximal n'est pas toujours la même dans le temps.

La solution ne sera pas que technique, la dessus on est d'accord. Sur le reste beaucoup moins.

Les gens vivent plus loin de leur lieu de travail, plus loin des écoles, parce qu'ils ont décidé qu'ils voulaient se le permettre

Moyennement d'accord la dessus, y a de tout, ce qui parte loin des villes pour avoir un bout de terrain on peut dire "qu'ils l'ont voulu" (et encore ça dépends des situations), ceux qui se retrouve en périphérie urbaine bétonisé à cause des loyers du centre ville trop élevés, j'ai du mal à dire : "ils l'ont choisis". Et en ile de france, la zone périphérique bétonnisé elle est sacrément large et souvent mal desservie en transport en commun.

Aujourd'hui le travail se trouve majoritairement dans les grands centres urbains, la ville n'est pas forcément le meilleur optimum énergétique. Tu peux te sentir "écolo" parce que tu fais 2km de vélotaf/transport en commun mais tout tes biens, à commencer par la nourriture que tu consomme tous les jours, ils ne sont pas produits en ville.

Personnellement je trouve ça pratique ce changement de mot de passe tous les 3 mois, j'utilise le pattern suivant : motdepasse_increment. ça me permet de me rappeler depuis quand je suis dans l'entreprise, j'ai juste à faire increment x 3.

Le débat "Intégration/utilité Docker par rapport à systemd" est un vieux débat qui n'est bientôt plus d'actualité je trouve.
Runc (le runtime utilisé entre autre par Docker) fournit depuis peu (beaucoup moins longtemps que lxc) un support de l'api kernel CgroupV2. Et pour cela, il peut déléguer la gestion des Cgroups (V2) à systemd via un appel Dbus.
Voir pour plus d'info : https://github.com/opencontainers/runc/blob/master/docs/cgroup-v2.md et https://github.com/opencontainers/runc/blob/master/docs/systemd.md

C'est pour le moment assez peu déployé, beaucoup de container tourne encore avec l'api CGroupV1 car pas mal de fonctionnalités intéressantes ne sont disponible que dans des versions récentes de systemd et du kernel donc comme toujours avant de retrouver ça en production ça va prendre des années (à moins que tu gère ta propre distrib/bsp).

La solution n'est pas encore parfaite, mais en soit, la voie est là. System-nspawn n'a qu'un support partiel de la spécification OCI et ce n'est pas une priorité des développeurs systemd de l'améliorer. En meme temps, il est logique que l'init gère les Cgroups (encore plus avec l'api V2 qui est hiérarchique). Donc le combo RunC qui parle à systemd via dbus est vraiment la bonne solution pour avoir la meilleur intégration je trouve.

Quelqu'un aurait plus d'info sur la faille ?
Du lien originel : https://www.wiz.io/blog/chaosdb-how-we-hacked-thousands-of-azure-customers-databases , on comprends qu'ils sont arrivés a passer d'un de leur notebook jupyter à celui d'une victime et donc a partir de la récupérer la clef primaire des db comos. Mais j'aimerai justement savoir comment ils sont passer d'un notebook à l'autre.

Les choses changent, par exemple en Isère, d'énorme travaux de sécurisation de l Isère ont été entrepris avec des zones agricole inondable en amont de Grenoble. Les agriculteurs seront indemnisés en cas d'utilisation de ces zones (et y gagnerons du limon sur leur terres)

Sur ce sujet, voir aussi l'intervention de benjamin bayart chez thinkerview au début de cette vidéo (les 10 premières minutes) : https://www.youtube.com/watch?v=EOWeewlc2CE sur le sujet "l'ordinateur est fatal".

Linux est peut être pas encore prêt pour le desktop (quoique) mais en tout cas entre docker, WSL et maintenant ePBF on voit que Linux est clairement prêt pour Windows !
Je sais pas qui aurait pu parier ça il y a 10 ans mais on voit clairement un changement de stratégie chez Windows depuis l'arrivé de la dernière CEO. Le dernier rachat de kinvolk.io en est un autre exemple.

Autant je trouve l'implémentation du live patching super intéressant (comment ça fonctionne en interne) mais j'ai vraiment du mal à voire le cas pratique, dans une architecture redondé / haute dispo, éteindre un spare pour faire une mise à jour kernel c'est pas un problème. Si tu ne le peux pas, c'est un SPOF je dirais, tu fait quoi le jour où il s'arrête /tombe malgré toi ?

Y a des cas d'usage que j'aurai raté ?

Et puis reboot de temps en temps d'un point de vue cybersecurite c'est pas mal aussi pour clean la mémoire, exercer le secure boot, etc…

Usine à presta, comme dans n'importes quelles grosses société française quelque soit le domaine (banque, industrie lourde, énergie…), c'est inhérent à ces organisations énormes où plus personnes ne maitrise rien, où les personnes sont complétement déresponsabilisés par un système hiérarchique abscons et "mutli-tranversal où le responsable c'est toujours l'autre" et avec les prestas au bas de l'échelle qui bricole, ce fatigue quelques années et vont voir ailleurs.

Tu as déjà quasiment cette fonctionnalité la sous gerrit. Un change-id fixe dans le message de commit. Avec ça tu peut facilement retrouver la 'branche de merge' qui est dans un namespace/ref git (afin de pas poluer le ref/heads courant)

Ça ce met assez facilement en place manuellement avec un script (information fixe dans le message de commit et sauvegarde de la branche dans un namespace dédié). Perso je mets ça en place dans tous les projets où j'ai un rôle d'intégrateur, gerrit ou pas.

Merci pour ces réponses, ça à l'air effectivement intéressant.
Il est vrai que git rerere ne marche pas toujours comme on le veut mais personnellement il assez rare que j'en ressente le besoin même dans un projet multi-personne. Si il y a deux évolutions majeures et assez longues à développer en parallèle qui vont toucher une même partie du code, on va réfléchir et s'organiser pour découper ça en plusieurs sous taches avec des dépendances entre elles et intégrer au plus tôt.
Meme sur un projet open source que je contrôle pas, si je sais que je vais casser une partie important de l'architecture/code, je vais commencer par une RFC/RequestForComment avant de me lancer dedans et je vais devoir réfléchir encore plus à découper mon travail en plusieurs changement indépendant intégrable au fil de l'eau.

Effectivement ici j'adapte mon workflow de travail à l'outil (petit commit régulier, intégrer le plus tôt possible par rapport à un gros commit intégré en mode big bang, ceci afin d'éviter les conflits).
Mais ce mode de fonctionnement actuelle me convient bien et convient bien aux équipes avec lequel j'ai travaillé.

J'ai vraiment du mal à m'imaginer si je changerai ma manière de travail avec darcs/pijul ou pas.
En soit si y deux branches qui divergence trop longtemps, le risque est grand de tomber dans un cas où il n'a pas de résolution automatique possible sans un choix fonctionnel et donc une décision humaine et donc je continuerai très certainement à utiliser mon fonctionnement actuel (petit commit, rebase régulier).

Automerge m'avait l'air merveilleux jusqu'à lire le paragraphe suivant : https://github.com/automerge/automerge#conflicting-changes

Par rapport à un 'gît merge-s ours' ça change quoi ? Parce ce que dire on sait faire des merge sans conflit parce que quand y en a on fait un choix arbitraire ça me paraît pas ouf, en tout cas pour un gestionnaire de version je préfère avoir un œil humain à ce moment là.

Mon commentaire portera uniquement sur la forme. Y a beaucoup trop de copier/coller et redite entre les différentes sections de la page. Si c'est pour écrire la même chose entre la section "Synthèse du projet" et la section "Objectifs du projet" autant en faire saute une des deux.

Sinon sur le fond ça a l'air cool mais très très jeune, j'attends de voir ce que ça peut donner.

Meme cette masse d'énergie je trouve ça critiquable comme valeur, en tout cas je n'en vois pas vraiment l’intérêt, le chiffre finale laissera entendre que c'est "léger". Ces 40 grammes d'énergie il a fallut combien de tonnes de charbon, fioul, panneau solaire, éolienne, nucléaire pour la fournir en permanence ?

Faudrait a coté de pertinent/inutile un troisième choix : "Devrait etre en section lien" qui le déplace automatiquement après un certains seuil :)