Ode aux petites équipes bof bof, tout dépend le contexte. Les petites équipes dans leurs coins ça crée aussi beaucoup de silo et du reinventage de roue permanente et de la fragmentation. Difficile de créé des écosystème un poil complexe sans platforming/ équipe core qui puisqu'elles doivent supporter X clients (internes et externes) se doivent d'être pas trop petites pour éviter d'être le goulet d'étranglement. Typiquement en équipe côté tu trouves des gens qui specifie les interfaces, protocoles et api pour garantir la cohérence de l'ensemble.
Âpres tu as l'extrême inverse, avec le truc core/corporate du milieu qui est une usine à gaz inefficace.
Je suis toujours septique sur ce genre de projet, ça me fait penser à micropython, en dehors du challenge technique, y a vraiment des utilisateurs derrière ?
Parce que avoir un sous ensemble d'un langage avec un support limité de plates-formes matérielles avec, je vois pas trop l'intérêt.
Mais je me trompe peut être, si quelqu'un a des retours d'expériences sur ce genre d'approches, je suis preneur.
Merci pour la nouvelle. J'aurai une question mais je sais pas si tu auras la réponse.J'ai découvert sysbox que je ne connaissais pas. Je vois qu'il s'agit d'un fork de runC, le rachat par docker Inc laisse t-il envisager une réintégration du code dans runC ou est ce que le fork dévie trop de la spec OCI pour être envisageable ?
Je me permet de clarifier et compléter mon propos qui est pas mal détourné.
L'entretien technique est généralement fait en visio, 1h de créneau est demandé mais généralement ça dure que 30 minutes. L'idée est de ne pas faire perdre de temps à la fois au recruteur et à la fois au candidat. C'est le fait de vouloir faire les choses rapidement qui vous choque ?
Encore une fois, plus un processus est long et ou exigeant plus tu risques de perdre du monde en cours de route. Parce que ce que vous semblez oublier ici, c'est qu'un candidat a assez souvent plusieurs pistes en parallèle, si chaque société demande 4h de travail c'est vite infernal.
Et encore une fois, la période d'essai reste importante et elle est finalement le "vrai" test, travail au quotidien et sur le temps longs. Des deux côtés on veut se rassurer mais vouloir faire une "micro période essai" en amont de l'entretien ne me paraît vraiment pas mieux ni plus humain.
Parce que en période d'essai, la loi protège le salarié et c'est temps mieux, si jamais l'employeur te dit que ça le fait pas, tu te retrouve pas sans rien.
Je vois que mes explications ton choqué (tu dis que je t'ai fait sauter au plafond) et je m'en excuse alors mais je pense que tu as mal perçu mon propos, sans doute un soucis de passer par l'écris, je pense pas que tu aurais eu ce genre de réaction avec moi à l'oral. Je sais pas comment te convaincre mais je m'estime plutôt bienveillant pendant mes entretiens, j'explique le processus de question/réponse (qui n'ai pas un script fixe écrit à l'avance d'ailleurs mais plutôt un échange avec le candidat par rapport à son expérience passé et ses envies futures), qu'il n'y pas de mauvaise réponse, que rien n'est éliminatoire etc… Et j'ai plutôt des bon retours sur les candidats que j'auditionne par rapport à ma bienveillance donc bref je suis pas la bête inhumaine de recruteur que tu as lu entre mes lignes.
J'ai vu des personnes ultra stressé qui trouver plus leur mot, et à ce moment tu prends le temps pour justement éviter un avis trop hâtifs, tu tente de le rassurer, tu pose des questions lié à l'expérience du candidat avant de retourner à des questions plus pointus etc…
Dans ton commentaire, y a plusieurs points sur lesquels j'aimerai rebondir:
Ta réponse de dire:
"Je connais pas les notions théoriques/le nommage précis derrière les design pattern mais je m'en fiche parce que c'est pas ce que je fais au quotidien, je lis beaucoup de code existant et je sais m'intégrer avec et ceci dans des projets open-source important" est pour moi une réponse VALIDE.
On aurait échangé la dessus et j'aurais certainement mis un avis positif à la sortie. Ici je résume ma vision d'un entretien technique, en réel je pose plus que 3 questions mais quelques soit la questions aucune réponse même "mauvaise" n'est éliminatoire, c'est sur l'ensemble que j'apporte un jugement.
Alors le fait de porter un jugement sur quelqu'un t'hérisse peut être le poil mais c'est le but même d'un entretien, émettre un avis sur quelqu'un pour savoir si il pourra répondre au besoin ou non et je vais te choquer mais c'est en plus complétement subjectif comme processus, tu évalue à la fois la technique mais aussi la capacité de la personne à discuter de sa technique, parce que aujourd'hui je recrute des personnes pour du travail en équipe. ça m'est arrivé de mettre un avis négatif à un profil ultra compétant mais totalement imbue de sa personne et je voulais pas prendre le risque d'avoir un TechLead compétant mais toxique pour l'équipe (c'est que les Rh appelle soft & hard skill).
Concernant libuv tu m'as mal compris, c'était juste un exemple, je demande pas la maitrise de libuv ou libev ou autres, je demande la maitrise/compréhension des concepts de la programmation orienté asynchrone (avec des callback quoi si le terme "programmation asynchrone est trop théorique pour toi).
Pourquoi je le demande, parce que c'est rarement un mode de programmation qui est appris en école (les écoles s'arrête généralement au multithread avec mutex). Donc si la personne connait la programmation asynchrone pour du C bas niveau, ça montre une personne curieuse, qui regarde ce qui se fait ailleurs, bref fait une veille techno ce qui est pour moi un critère très important. Encore une fois ici, c'est un plus, un bon indicateur mais c'est pas éliminatoire.
Et pour revenir au débat initiale, le "faire un test 4 à 6H pour évaluer ton niveau technique" à faire chez soi est pas forcément plus humain, ça peut être vu comme vexant pour des profils expérimenter de devoir passer par ce "devoir à la maison". Bref y a pas de solution parfaite mais je trouve la moins invasive (tout en restant efficace) pour un candidat, reste encore l'entretient technique avec questions-réponses, partage d'expérience et des ses envies futures.
Par entretien technique j'entends des questions réponses, échange sur des problématiques, retour d'expériences etc…
Parce que les tests du genre : trouve l undefined behavior dans du code c d'exemples que tu aurais jamais écrit de cette manière là, niveau pertinence c'est bien nulle je trouve.
J'ai fait passer pas mal d'entretien tous niveau (plutôt orienté C embarquée), rien qu'avec quelques questions basique du style : Qu'est ce que les design pattern, citez en moi 3 et à quoi ils servent, tu vois vite le niveau.
Entre ceux qui savent même pas ce que c'est, ce qui te cite le singleton uniquement, ceux qui te sorte la factory mais maîtrise pas le concept et ceux qui maîtrise le sujet, tu le vois vite, pas besoin d'écrire la moindre ligne de code.
Et pour du niveau plus technique tu peux aller chercher le niveau de curiosité du profil, si pour du C orienté embarqué, la personne est capable de t'expliquer le programmation asynchrone (event loop /libuv base de nodejs) ou de t'expliquer le modèle derrière les goroutines de go, tu sais que tu as à faire à quelqu'un de curieux et qui est pas resté bloqué sur le seul modèle multithread/mutex appris à l'école.
Pas besoin de code pour ça.
Pour mesurer la capacité des gens à faire de l'analyse de bugfix, pas besoin d'exercices pour ça non plus.
Après je recherche des personnes au profil complet, je veux dire par là que sa capacité à "pisser" de la ligne de code n'est qu'une petite portion.
Personnellement devoir passer 4 à 6h de travail à la maison pour un recrutement me refroidis beaucoup, je n'ai pas se temps là de disponible. Les pseudo tests techniques pendant les entretiens je suis pas fan non plus, c'est souvent très scolaires (les coding games encore plus).
Bref je suis de la "veille école", entretien technique, échange et questions réponses suffise pour moi à se faire une idée de la personne. Et si on se trompe, la période d'essai est la pour ça, que ça soit côté salarié comme employeur.
On est sur un bête marché avec offres vs demandes. Si tu reçoit X candidatures spontanées par mois, tu peux te permettre de perde du monde par un processus trop long et trop exigeant. Mais si tu as du mal à recruter, demander un test de 6h, tu passe peu être à côté d'un bon profil qui a juste une vie familiale.
Pas forcément, la version n-1 peut être aussi mise à jour vers la version n (double mise à jour identique l'une après l'autre). Bon quand tu fais ça, faut laisser une plage temporelle suffisamment longue pour bien être sur que la 1er mise à jour c'est bien passé, ce qui évidemment te laisse une fenêtre où tu es vulnérable sur une attaque par repli.
Bref j'ai l'impression que leur système de mise à jour était en simple bank (download en ram et écrasement de la flash direct) et si c'est bien ça, c'est bien nul, gros soucis de design.
Quelqu'un aurait plus d'informations sur le type de mise à jour employé ?
Parce que normalement on spécifié les systèmes de mise à jour pour être robuste à une mise à jour foireuse. Soit on a une partition de mise à jour adhoc qui devrait donc encore permettre la mise à jour (outil et conf WiFi séparé), soit on est sur du double banque avec un mécanisme de rollback vers la version précédente (détection d'anomalie via auto test et/ou procédure manuelle).
Merci pour la réponse, c'est claire pour moi. Joli projet en tout cas, j'espère que vous aurez du succès et que le business modèle suivra, ça fait du bien de voir un compétiteur à QML émerger.
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 : WX, 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é.
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.
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)
[^] # Re: Conception anarchiste sous-jacente
Posté par Tangi Colin . En réponse au lien our CTO Should Actually Be Technical. Évalué à 6.
Ode aux petites équipes bof bof, tout dépend le contexte. Les petites équipes dans leurs coins ça crée aussi beaucoup de silo et du reinventage de roue permanente et de la fragmentation. Difficile de créé des écosystème un poil complexe sans platforming/ équipe core qui puisqu'elles doivent supporter X clients (internes et externes) se doivent d'être pas trop petites pour éviter d'être le goulet d'étranglement. Typiquement en équipe côté tu trouves des gens qui specifie les interfaces, protocoles et api pour garantir la cohérence de l'ensemble.
Âpres tu as l'extrême inverse, avec le truc core/corporate du milieu qui est une usine à gaz inefficace.
Y a un juste milieu à trouver
# Quelqu'un va vraiment utiliser ça en production ?
Posté par Tangi Colin . En réponse au lien Microvium : un tout petit javascript. Évalué à 1.
Je suis toujours septique sur ce genre de projet, ça me fait penser à micropython, en dehors du challenge technique, y a vraiment des utilisateurs derrière ?
Parce que avoir un sous ensemble d'un langage avec un support limité de plates-formes matérielles avec, je vois pas trop l'intérêt.
Mais je me trompe peut être, si quelqu'un a des retours d'expériences sur ce genre d'approches, je suis preneur.
# Intégration sysbox dans runC
Posté par Tangi Colin . En réponse au journal Docker Desktop 4 Linux et rootless containers. Évalué à 3.
Merci pour la nouvelle. J'aurai une question mais je sais pas si tu auras la réponse.J'ai découvert sysbox que je ne connaissais pas. Je vois qu'il s'agit d'un fork de runC, le rachat par docker Inc laisse t-il envisager une réintégration du code dans runC ou est ce que le fork dévie trop de la spec OCI pour être envisageable ?
[^] # Re: Chouette
Posté par Tangi Colin . En réponse au lien Avez vous déjà vu... ? (du recrutement, spécialement informatique). Évalué à 1.
Je me permet de clarifier et compléter mon propos qui est pas mal détourné.
L'entretien technique est généralement fait en visio, 1h de créneau est demandé mais généralement ça dure que 30 minutes. L'idée est de ne pas faire perdre de temps à la fois au recruteur et à la fois au candidat. C'est le fait de vouloir faire les choses rapidement qui vous choque ?
Encore une fois, plus un processus est long et ou exigeant plus tu risques de perdre du monde en cours de route. Parce que ce que vous semblez oublier ici, c'est qu'un candidat a assez souvent plusieurs pistes en parallèle, si chaque société demande 4h de travail c'est vite infernal.
Et encore une fois, la période d'essai reste importante et elle est finalement le "vrai" test, travail au quotidien et sur le temps longs. Des deux côtés on veut se rassurer mais vouloir faire une "micro période essai" en amont de l'entretien ne me paraît vraiment pas mieux ni plus humain.
Parce que en période d'essai, la loi protège le salarié et c'est temps mieux, si jamais l'employeur te dit que ça le fait pas, tu te retrouve pas sans rien.
[^] # Re: Chouette
Posté par Tangi Colin . En réponse au lien Avez vous déjà vu... ? (du recrutement, spécialement informatique). Évalué à 2.
Je vois que mes explications ton choqué (tu dis que je t'ai fait sauter au plafond) et je m'en excuse alors mais je pense que tu as mal perçu mon propos, sans doute un soucis de passer par l'écris, je pense pas que tu aurais eu ce genre de réaction avec moi à l'oral. Je sais pas comment te convaincre mais je m'estime plutôt bienveillant pendant mes entretiens, j'explique le processus de question/réponse (qui n'ai pas un script fixe écrit à l'avance d'ailleurs mais plutôt un échange avec le candidat par rapport à son expérience passé et ses envies futures), qu'il n'y pas de mauvaise réponse, que rien n'est éliminatoire etc… Et j'ai plutôt des bon retours sur les candidats que j'auditionne par rapport à ma bienveillance donc bref je suis pas la bête inhumaine de recruteur que tu as lu entre mes lignes.
J'ai vu des personnes ultra stressé qui trouver plus leur mot, et à ce moment tu prends le temps pour justement éviter un avis trop hâtifs, tu tente de le rassurer, tu pose des questions lié à l'expérience du candidat avant de retourner à des questions plus pointus etc…
Dans ton commentaire, y a plusieurs points sur lesquels j'aimerai rebondir:
Ta réponse de dire:
"Je connais pas les notions théoriques/le nommage précis derrière les design pattern mais je m'en fiche parce que c'est pas ce que je fais au quotidien, je lis beaucoup de code existant et je sais m'intégrer avec et ceci dans des projets open-source important" est pour moi une réponse VALIDE.
On aurait échangé la dessus et j'aurais certainement mis un avis positif à la sortie. Ici je résume ma vision d'un entretien technique, en réel je pose plus que 3 questions mais quelques soit la questions aucune réponse même "mauvaise" n'est éliminatoire, c'est sur l'ensemble que j'apporte un jugement.
Alors le fait de porter un jugement sur quelqu'un t'hérisse peut être le poil mais c'est le but même d'un entretien, émettre un avis sur quelqu'un pour savoir si il pourra répondre au besoin ou non et je vais te choquer mais c'est en plus complétement subjectif comme processus, tu évalue à la fois la technique mais aussi la capacité de la personne à discuter de sa technique, parce que aujourd'hui je recrute des personnes pour du travail en équipe. ça m'est arrivé de mettre un avis négatif à un profil ultra compétant mais totalement imbue de sa personne et je voulais pas prendre le risque d'avoir un TechLead compétant mais toxique pour l'équipe (c'est que les Rh appelle soft & hard skill).
Concernant libuv tu m'as mal compris, c'était juste un exemple, je demande pas la maitrise de libuv ou libev ou autres, je demande la maitrise/compréhension des concepts de la programmation orienté asynchrone (avec des callback quoi si le terme "programmation asynchrone est trop théorique pour toi).
Pourquoi je le demande, parce que c'est rarement un mode de programmation qui est appris en école (les écoles s'arrête généralement au multithread avec mutex). Donc si la personne connait la programmation asynchrone pour du C bas niveau, ça montre une personne curieuse, qui regarde ce qui se fait ailleurs, bref fait une veille techno ce qui est pour moi un critère très important. Encore une fois ici, c'est un plus, un bon indicateur mais c'est pas éliminatoire.
Et pour revenir au débat initiale, le "faire un test 4 à 6H pour évaluer ton niveau technique" à faire chez soi est pas forcément plus humain, ça peut être vu comme vexant pour des profils expérimenter de devoir passer par ce "devoir à la maison". Bref y a pas de solution parfaite mais je trouve la moins invasive (tout en restant efficace) pour un candidat, reste encore l'entretient technique avec questions-réponses, partage d'expérience et des ses envies futures.
[^] # Re: Chouette
Posté par Tangi Colin . En réponse au lien Avez vous déjà vu... ? (du recrutement, spécialement informatique). Évalué à 3.
Par entretien technique j'entends des questions réponses, échange sur des problématiques, retour d'expériences etc…
Parce que les tests du genre : trouve l undefined behavior dans du code c d'exemples que tu aurais jamais écrit de cette manière là, niveau pertinence c'est bien nulle je trouve.
J'ai fait passer pas mal d'entretien tous niveau (plutôt orienté C embarquée), rien qu'avec quelques questions basique du style : Qu'est ce que les design pattern, citez en moi 3 et à quoi ils servent, tu vois vite le niveau.
Entre ceux qui savent même pas ce que c'est, ce qui te cite le singleton uniquement, ceux qui te sorte la factory mais maîtrise pas le concept et ceux qui maîtrise le sujet, tu le vois vite, pas besoin d'écrire la moindre ligne de code.
Et pour du niveau plus technique tu peux aller chercher le niveau de curiosité du profil, si pour du C orienté embarqué, la personne est capable de t'expliquer le programmation asynchrone (event loop /libuv base de nodejs) ou de t'expliquer le modèle derrière les goroutines de go, tu sais que tu as à faire à quelqu'un de curieux et qui est pas resté bloqué sur le seul modèle multithread/mutex appris à l'école.
Pas besoin de code pour ça.
Pour mesurer la capacité des gens à faire de l'analyse de bugfix, pas besoin d'exercices pour ça non plus.
Après je recherche des personnes au profil complet, je veux dire par là que sa capacité à "pisser" de la ligne de code n'est qu'une petite portion.
[^] # Re: Chouette
Posté par Tangi Colin . En réponse au lien Avez vous déjà vu... ? (du recrutement, spécialement informatique). Évalué à 10.
Personnellement devoir passer 4 à 6h de travail à la maison pour un recrutement me refroidis beaucoup, je n'ai pas se temps là de disponible. Les pseudo tests techniques pendant les entretiens je suis pas fan non plus, c'est souvent très scolaires (les coding games encore plus).
Bref je suis de la "veille école", entretien technique, échange et questions réponses suffise pour moi à se faire une idée de la personne. Et si on se trompe, la période d'essai est la pour ça, que ça soit côté salarié comme employeur.
On est sur un bête marché avec offres vs demandes. Si tu reçoit X candidatures spontanées par mois, tu peux te permettre de perde du monde par un processus trop long et trop exigeant. Mais si tu as du mal à recruter, demander un test de 6h, tu passe peu être à côté d'un bon profil qui a juste une vie familiale.
[^] # Re: Détails techniques ?
Posté par Tangi Colin . En réponse au lien ... device thinks it is a steam oven .... Évalué à 1.
Pas forcément, la version n-1 peut être aussi mise à jour vers la version n (double mise à jour identique l'une après l'autre). Bon quand tu fais ça, faut laisser une plage temporelle suffisamment longue pour bien être sur que la 1er mise à jour c'est bien passé, ce qui évidemment te laisse une fenêtre où tu es vulnérable sur une attaque par repli.
Bref j'ai l'impression que leur système de mise à jour était en simple bank (download en ram et écrasement de la flash direct) et si c'est bien ça, c'est bien nul, gros soucis de design.
# Détails techniques ?
Posté par Tangi Colin . En réponse au lien ... device thinks it is a steam oven .... Évalué à 2.
Quelqu'un aurait plus d'informations sur le type de mise à jour employé ?
Parce que normalement on spécifié les systèmes de mise à jour pour être robuste à une mise à jour foireuse. Soit on a une partition de mise à jour adhoc qui devrait donc encore permettre la mise à jour (outil et conf WiFi séparé), soit on est sur du double banque avec un mécanisme de rollback vers la version précédente (détection d'anomalie via auto test et/ou procédure manuelle).
[^] # Re: Backend GPU ?
Posté par Tangi Colin . En réponse au journal Slint: Un toolkit pour interface graphiques natives. Évalué à 4.
Merci pour la réponse, c'est claire pour moi. Joli projet en tout cas, j'espère que vous aurez du succès et que le business modèle suivra, ça fait du bien de voir un compétiteur à QML émerger.
# Backend GPU ?
Posté par Tangi Colin . En réponse au journal Slint: Un toolkit pour interface graphiques natives. Évalué à 3.
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 ?
[^] # Re: Titre trompeur
Posté par Tangi Colin . En réponse au lien Le langage COBOL a-t-il encore du succès ? La réponse pourrait vous surprendre. Évalué à 4.
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…
# Dommage pour les api Linux spécifique
Posté par Tangi Colin . En réponse au lien Pourquoi migrer de Linux vers FreeBSD. Évalué à 5.
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.
[^] # Re: Un peu précipité…
Posté par Tangi Colin . En réponse au lien Rust fait un grand pas en avant en devenant le deuxième langage officiel de Linux. Évalué à 1.
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 : WX, 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é.
[^] # Re: Mélange de 2 idées différentes?
Posté par Tangi Colin . En réponse au journal Excellent livre sur l'open source !. Évalué à 1.
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.
[^] # Re: Mélange de 2 idées différentes?
Posté par Tangi Colin . En réponse au journal Excellent livre sur l'open source !. Évalué à 1.
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.
[^] # Re: Discussions intéressantes sur HackerNews
Posté par Tangi Colin . En réponse au lien Kerla : OS en Rust. Évalué à 0.
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 ?
[^] # Re: Manque d'objectivité.
Posté par Tangi Colin . En réponse au lien Scénarios RTE - Une seule trajectoire énergétique étudiée, en oubliant celle de la sobriété. Évalué à 5.
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).
# Manque d'objectivité.
Posté par Tangi Colin . En réponse au lien Scénarios RTE - Une seule trajectoire énergétique étudiée, en oubliant celle de la sobriété. Évalué à 10.
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
[^] # Re: Résumé
Posté par Tangi Colin . En réponse au lien Limite trop basse pour les noms de commune sur les CNI françaises. Évalué à 4. Dernière modification le 14 octobre 2021 à 09:32.
avec les regroupements de communes, cette longueur maximal n'est pas toujours la même dans le temps.
[^] # Re: distance travail/maison
Posté par Tangi Colin . En réponse au journal Le pétrole, le GPL, la voiture électrique, et mon portefeuille. Évalué à 8.
La solution ne sera pas que technique, la dessus on est d'accord. Sur le reste beaucoup moins.
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.
[^] # Re: Expiration des mots de passe
Posté par Tangi Colin . En réponse au lien Recommandations [de l'ANSSI] relatives à l’authentification multifacteur et aux mots de passe. Évalué à 3.
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.
[^] # Re: use case
Posté par Tangi Colin . En réponse au lien systemd portable services: parce que les conteneurs, c'est trop mainstream. Évalué à 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.
# Details complet de l'attaque ?
Posté par Tangi Colin . En réponse au lien Clown Computing chez les romuliens. Évalué à 4. Dernière modification le 30 août 2021 à 14:24.
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.
[^] # Re: Zones inondables
Posté par Tangi Colin . En réponse au lien Inondations : comment les Pays-Bas ont évité les morts - lalibre.be. Évalué à 5.
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)