Titre racoleur, quand tu lis l'article c'est vachement plus nuancé. Qu'une PWA s'ouvre dans un navigateur et pas dans un format app like c'est loin d'être choquant et pas sur que ça change grand chose au micro marché des PWA.
Déjà avant, soit tu veux la meilleur intégration ux/ui avec le système et tu fais du natif, sois tu veux un bon support multi device web compris sans recoder 4 fois et tu fais du PWA.
Google a bien amélioré la situation du support long terme avec leur projet Generic kernel image, en offrant des api interne stable à grand coup de padding reserved dans les structure du kernel. Bien qu'il ai peu de chance que leur solution soit un jour mainline, leur travail est loin d'être bête et ils ont fait beaucoup pour améliorer la situation.
Et puis si le support Android te concerne vraiment, tu achète un pixel et tu retrouve la même "intégration vertical" que tu peux trouver chez Apple. Et avant y avait Motorola.
Très bonne question. Quand on me laisse le droit de le faire (codé est de plus en plus une activité collective) j'utilise goto (language C) pour tous ce qui est gestion d'erreur au sein de ma fonction, pour désinitialiser mes allocations par example. Cela permet d'avoir un code "linéaire" avec peu de profondeur par rapport à un enfer de if/else en profondeur.
Le seul truc que j'ai trouvé de mieux c'est les "defer" à la golang ou swift, que j'aimerai beaucoup avoir dans une futur version de C.
Si j'ai bien suivi ça gère des sources git, quel est alors la différence avec un gestionnaire de multiple git tel que Android repo ?
Mélanger gestionnaire de source et build système ma toujours parue un mauvais mélange en dehors des cas particuliers d'un méta build système comme yocto mais on est plus dans le même cas d'usage, on fait de la création de distro pas de dev de code.
Il y a aujourd'hui plusieurs standard en compétition pour standardiser la séquence de boot sur ARM.
La société ARM pousse avec Linaro pour implémenter la spec UEFI (ou la sous spécification d'UEFI qui est Embedded Base Boot Requirements pour être précis).
C'est très certainement le "sens" de l'histoire, ARM voulant de plus en plus se positionner aussi dans le monde des serveurs, on veut unifier avec le monde de X86 d'où l'UEFI et aussi de plus en plus de board avec support ACPI à la place des "Device tree".
Pour une état des lieux du support U-boot associé, ce billet de blog est un bon point de départ : https://www.linaro.org/blog/journey-to-systemready-compliance-in-u-boot/
Je suis pas sur que l'embarqué en sorte gagnant, la moindre spécification UEFI fait 2000 pages et tu vas te retrouver avec des "EFI Stub" à charger et qui tournent en fond et qui seront certainement de beau binaire boite noire.
Je préfère encore la complexité d'un build custom par board u-boot avec les bon dts à charger. Ce qu'on va gagner en "simplicité (just work)", on va le perdre en capacité à bidouiller.
Ma préférence va pour ce second "standard", j'espère qu'il sera de plus en plus connue et utilisé par les différents vendeurs de SOC.
Après quand je vois le temps qu'il a fallut pour que le format FIT soit connue et utilisé, la route est encore longue.
C'est pour moi un basique de règle de design orienté object. La
composotion doit être la règle, l'héritage l'exception. Malheureusement les 1er cours en école commence toujours par expliquer les principes orienté objet par l'héritage. J'ai vu passer des générations de développeur débutant avec ce biais de conception ancré en eux. Dommage que beaucoup d'école ne poussent pas à la veille techno, n'évoque jamais les uncle Bob ou martin fowler… Il y a sans doute des exceptions et de bon professeur en école supérieur mais force de constater que ce n'est pas la règle.
Un truc que je suis de prêt aussi c'est le partenariat entre elektrobit(filiale continental, très gros fournisseur de solution automotive) et ubuntu qui pour le coup n'est pas basé sur snap mais sur de l'oci (podman et crun) et où tu peux customizer ta distro depuis un layer yocto. https://www.elektrobit.com/products/ecu/eb-corbos/linux/
J'ai pas eu encore l'occasion de tester mais ça semble être un très bon compromis. Du yocto et du crun donc très bien orienté pour l'embarqué tout en ayant un support kernel "Ubuntu" sur 15 ans.
Tout n'est pas noir ou blanc. Je suis d'accord, on est pas obligé de faire du cloud avec multi zone. Tout dépends les objectifs et les moyens 100% d'accord.
J'ai la même soucis côté big/fast data, le nombre de projet que j'ai vu avec un système SMACK (artillerie lourde) pour un besoin finalement faible où un simple postgresql avec la sur couche timescaledb aurait largement suffit.
Quand tu as un marteau tous ressemble à un clou.
Après j'aime bien l'approche Paas/kubernetes, tu as pas besoin d'avoir des expert cyber, ou réseau ou db dans chaque projet, ils sont toujours là mais côté plate-forme et au dessus tu as besoin de moins de compétences infra et tu peux mettre plus de moyen pure métier et UX/UI. Juste d'avoir des règles claire sur les bonnes pratiques et bien définir les responsabilités entre équipe plate-forme/core et équipe projet.
Merci j'avais raté l'info concernant le Google Nest Hub. Donc oui le terme "jouet" est un peu trop fort. Mon point sur le manque d'un écosystème autour reste valable. Un seul projet commercial fait par google lui même. Je miserai pas mes propres projets embarqués la dessus, Zephyr me semble un choix bien plus pertinent et pérenne.
Après je peux me tromper et j'aimerai me tromper car techniquement ce que propose Fushia est intéressant. Y a quelques années j'avais misé sur Mbed pour la force de l'écosystème qu'il avait embarqué autour de lui. Bon c'est plus le cas aujourd'hui. Les quelques trucs intéressant comme litteFS sont aujourd'hui repris dans Zephyr.
Pour réduire la taille de binaire GO pour de l'embarqué, j'utilise UPX pour info : https://github.com/upx/upx . Tu as une légère pénalité au démarrage due à la décompression mais ça remplie plutôt bien son role.
Et concernant le fait que Rust soit plus adapté niveau mémoire pour faire du bas niveau ça dépends des cas, qu'on on veut vraiment optimiser le rendu assembleur du code pour le moment y a de grosse surprise sur les choix que fait le compilateur Rust. Voir pour plus d'info : https://lwn.net/Articles/907876/ ou https://twitter.com/LinaAsahi/status/1567752082060619776
J'espère me tromper mais Google commence à avoir le meme track record que Mozilla pour les projets abandonnés. Y a quelques années ça faisait beaucoup de bruit autour de FushiaOS, on en entendais même certains le prédire en remplaçant de Linux pour Android. Aujourd'hui FushiaOS reste un jouet et le restera certainement pour toujours, y a pas d'écosystème autour.
Je pense aussi au projet Ara avec le protocole greybus, beaucoup de travail, code mainliné par Greg K.H, idée sympa etc… Le projet a été tué avant sa sortie.
Donc bon, je vais continuer à mettre un billet sur Zephyr pour les prochaines années, ça me semble un choix bien plus sur.
Ça existe déjà est en bien plus complet. Y a plusieurs implémentation de la spécification OCI(open container initiative) tels que runc (golang et utilisé par docker à travers containerd), crun (C fait par redhat) et youki (rust)
J'avoue que ça fait un moment que j'essaie de voir les cas d'usage que va permettre WASM et WASI. J'entends partout que c'est le futur mais je restais pour le moment assez peu convaincu, l'application QT qu'on va compiler pour tourner tel quelle en WASM dans un navigateur j'y crois pas trop coté expérience UX/UI.
Mais là pour le coup, la DB Sqlite en WASM via un site statique je l'avais pas vu venir. J'ai du mal à percevoir si en dehors de l'exploit technique ça donnera vraiment quelques choses mais ça force à réfléchir autrement. Qui sais, ça sera peut être réellement le futur WASM !
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.
# Solution technique
Posté par Tangi Colin . En réponse au lien Le SF6, un gaz à effet de serre 24 000 fois plus puissant que le CO2. Évalué à 2 (+1/-0).
Pour info des solutions techniques sans sf6 existent, voir par exemple airset schneider
[^] # Re: Apple n'est donc pas une entreprise mature ;)
Posté par Tangi Colin . En réponse au lien Apple intentionally kills web applications for EU users in iOS 17.4 onward to spite its EU users. Évalué à 1 (+0/-0).
Titre racoleur, quand tu lis l'article c'est vachement plus nuancé. Qu'une PWA s'ouvre dans un navigateur et pas dans un format app like c'est loin d'être choquant et pas sur que ça change grand chose au micro marché des PWA.
Déjà avant, soit tu veux la meilleur intégration ux/ui avec le système et tu fais du natif, sois tu veux un bon support multi device web compris sans recoder 4 fois et tu fais du PWA.
[^] # Re: Argument dérivé
Posté par Tangi Colin . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à 3 (+2/-0).
Google a bien amélioré la situation du support long terme avec leur projet Generic kernel image, en offrant des api interne stable à grand coup de padding reserved dans les structure du kernel. Bien qu'il ai peu de chance que leur solution soit un jour mainline, leur travail est loin d'être bête et ils ont fait beaucoup pour améliorer la situation.
Et puis si le support Android te concerne vraiment, tu achète un pixel et tu retrouve la même "intégration vertical" que tu peux trouver chez Apple. Et avant y avait Motorola.
# très bonne question
Posté par Tangi Colin . En réponse au journal Is return the new goto ?. Évalué à 10 (+9/-0).
Très bonne question. Quand on me laisse le droit de le faire (codé est de plus en plus une activité collective) j'utilise goto (language C) pour tous ce qui est gestion d'erreur au sein de ma fonction, pour désinitialiser mes allocations par example. Cela permet d'avoir un code "linéaire" avec peu de profondeur par rapport à un enfer de if/else en profondeur.
Le seul truc que j'ai trouvé de mieux c'est les "defer" à la golang ou swift, que j'aimerai beaucoup avoir dans une futur version de C.
# Question ?
Posté par Tangi Colin . En réponse au lien shipp: Deadly simple package manager for your C/C++ projects, written in Rust. Évalué à 2 (+1/-0).
Si j'ai bien suivi ça gère des sources git, quel est alors la différence avec un gestionnaire de multiple git tel que Android repo ?
Mélanger gestionnaire de source et build système ma toujours parue un mauvais mélange en dehors des cas particuliers d'un méta build système comme yocto mais on est plus dans le même cas d'usage, on fait de la création de distro pas de dev de code.
# Standardiser le boot sur équipements embarqué/arm.
Posté par Tangi Colin . En réponse au journal Petitboot sur ARM, le bon, le bad et le ugly. Évalué à 10.
Il y a aujourd'hui plusieurs standard en compétition pour standardiser la séquence de boot sur ARM.
La société ARM pousse avec Linaro pour implémenter la spec UEFI (ou la sous spécification d'UEFI qui est Embedded Base Boot Requirements pour être précis).
C'est très certainement le "sens" de l'histoire, ARM voulant de plus en plus se positionner aussi dans le monde des serveurs, on veut unifier avec le monde de X86 d'où l'UEFI et aussi de plus en plus de board avec support ACPI à la place des "Device tree".
Pour une état des lieux du support U-boot associé, ce billet de blog est un bon point de départ :
https://www.linaro.org/blog/journey-to-systemready-compliance-in-u-boot/
Je suis pas sur que l'embarqué en sorte gagnant, la moindre spécification UEFI fait 2000 pages et tu vas te retrouver avec des "EFI Stub" à charger et qui tournent en fond et qui seront certainement de beau binaire boite noire.
Je préfère encore la complexité d'un build custom par board u-boot avec les bon dts à charger. Ce qu'on va gagner en "simplicité (just work)", on va le perdre en capacité à bidouiller.
Heureusement un autre standard tente de se faire sa place en se reposant sur les mécanisme existant mais récent d'u-boot (FIT et bootflow), il s'agit de "Verified Boot for Embedded" : https://talks.osfc.io/media/osfc2022/submissions/ZTGCJG/resources/osfc22_VBE_-_Verified_Boot_for_Embedded_1BUma3C.pdf
Ma préférence va pour ce second "standard", j'espère qu'il sera de plus en plus connue et utilisé par les différents vendeurs de SOC.
Après quand je vois le temps qu'il a fallut pour que le format FIT soit connue et utilisé, la route est encore longue.
Un autre "standard" a noter est coté systemd (maintenant UAPI) concernant l'auto-discovery de partition : https://uapi-group.org/specifications/specs/boot_loader_specification/
# Un cas d'école
Posté par Tangi Colin . En réponse au lien Composition Over Inheritance: A Banking Example in Golang. Évalué à 5.
C'est pour moi un basique de règle de design orienté object. La
composotion doit être la règle, l'héritage l'exception. Malheureusement les 1er cours en école commence toujours par expliquer les principes orienté objet par l'héritage. J'ai vu passer des générations de développeur débutant avec ce biais de conception ancré en eux. Dommage que beaucoup d'école ne poussent pas à la veille techno, n'évoque jamais les uncle Bob ou martin fowler… Il y a sans doute des exceptions et de bon professeur en école supérieur mais force de constater que ce n'est pas la règle.
# Avenir pour wpe ?
Posté par Tangi Colin . En réponse au lien Igalia investit dans le moteur de rendu Web en Rust Servo, lequel rejoint la Linux Foundation Europe. Évalué à 2.
Intéressant à suivre comme évolution et voir si igalia continuera à investir dans wpe et cog (https://wpewebkit.org/) ou pas par la suite.
[^] # Re: Une effervescence
Posté par Tangi Colin . En réponse au lien According to one Canonical developer: Ubuntu is going all Snap & fully immutable in 24.04.. Évalué à 3.
Un truc que je suis de prêt aussi c'est le partenariat entre elektrobit(filiale continental, très gros fournisseur de solution automotive) et ubuntu qui pour le coup n'est pas basé sur snap mais sur de l'oci (podman et crun) et où tu peux customizer ta distro depuis un layer yocto. https://www.elektrobit.com/products/ecu/eb-corbos/linux/
J'ai pas eu encore l'occasion de tester mais ça semble être un très bon compromis. Du yocto et du crun donc très bien orienté pour l'embarqué tout en ayant un support kernel "Ubuntu" sur 15 ans.
# Un peu de nuance
Posté par Tangi Colin . En réponse au journal Le cloud ça scale bien. Évalué à 5.
Tout n'est pas noir ou blanc. Je suis d'accord, on est pas obligé de faire du cloud avec multi zone. Tout dépends les objectifs et les moyens 100% d'accord.
J'ai la même soucis côté big/fast data, le nombre de projet que j'ai vu avec un système SMACK (artillerie lourde) pour un besoin finalement faible où un simple postgresql avec la sur couche timescaledb aurait largement suffit.
Quand tu as un marteau tous ressemble à un clou.
Après j'aime bien l'approche Paas/kubernetes, tu as pas besoin d'avoir des expert cyber, ou réseau ou db dans chaque projet, ils sont toujours là mais côté plate-forme et au dessus tu as besoin de moins de compétences infra et tu peux mettre plus de moyen pure métier et UX/UI. Juste d'avoir des règles claire sur les bonnes pratiques et bien définir les responsabilités entre équipe plate-forme/core et équipe projet.
[^] # Re: Combien de temps avant son abandon ?
Posté par Tangi Colin . En réponse au journal KataOS, un OS sécurisé basé sur SeL4 écrit en Rust ... par Google. Évalué à 5.
Merci j'avais raté l'info concernant le Google Nest Hub. Donc oui le terme "jouet" est un peu trop fort. Mon point sur le manque d'un écosystème autour reste valable. Un seul projet commercial fait par google lui même. Je miserai pas mes propres projets embarqués la dessus, Zephyr me semble un choix bien plus pertinent et pérenne.
Après je peux me tromper et j'aimerai me tromper car techniquement ce que propose Fushia est intéressant. Y a quelques années j'avais misé sur Mbed pour la force de l'écosystème qu'il avait embarqué autour de lui. Bon c'est plus le cas aujourd'hui. Les quelques trucs intéressant comme litteFS sont aujourd'hui repris dans Zephyr.
[^] # Re: Go et Rust
Posté par Tangi Colin . En réponse au journal KataOS, un OS sécurisé basé sur SeL4 écrit en Rust ... par Google. Évalué à 3.
Pour réduire la taille de binaire GO pour de l'embarqué, j'utilise UPX pour info : https://github.com/upx/upx . Tu as une légère pénalité au démarrage due à la décompression mais ça remplie plutôt bien son role.
Et concernant le fait que Rust soit plus adapté niveau mémoire pour faire du bas niveau ça dépends des cas, qu'on on veut vraiment optimiser le rendu assembleur du code pour le moment y a de grosse surprise sur les choix que fait le compilateur Rust. Voir pour plus d'info : https://lwn.net/Articles/907876/ ou https://twitter.com/LinaAsahi/status/1567752082060619776
# Combien de temps avant son abandon ?
Posté par Tangi Colin . En réponse au journal KataOS, un OS sécurisé basé sur SeL4 écrit en Rust ... par Google. Évalué à 10.
J'espère me tromper mais Google commence à avoir le meme track record que Mozilla pour les projets abandonnés. Y a quelques années ça faisait beaucoup de bruit autour de FushiaOS, on en entendais même certains le prédire en remplaçant de Linux pour Android. Aujourd'hui FushiaOS reste un jouet et le restera certainement pour toujours, y a pas d'écosystème autour.
Je pense aussi au projet Ara avec le protocole greybus, beaucoup de travail, code mainliné par Greg K.H, idée sympa etc… Le projet a été tué avant sa sortie.
Donc bon, je vais continuer à mettre un billet sur Zephyr pour les prochaines années, ça me semble un choix bien plus sur.
[^] # Re: successeur de TapTempo ?
Posté par Tangi Colin . En réponse au lien Bocker : Docker implemented in around 100 lines of bash [2015]. Évalué à 6.
Ça existe déjà est en bien plus complet. Y a plusieurs implémentation de la spécification OCI(open container initiative) tels que runc (golang et utilisé par docker à travers containerd), crun (C fait par redhat) et youki (rust)
[^] # Re: Quelle bonne idée
Posté par Tangi Colin . En réponse au lien Héberger une base de données SQLite sur Github Pages (ou un autre hébergement statique). Évalué à 3.
J'avoue que ça fait un moment que j'essaie de voir les cas d'usage que va permettre WASM et WASI. J'entends partout que c'est le futur mais je restais pour le moment assez peu convaincu, l'application QT qu'on va compiler pour tourner tel quelle en WASM dans un navigateur j'y crois pas trop coté expérience UX/UI.
Mais là pour le coup, la DB Sqlite en WASM via un site statique je l'avais pas vu venir. J'ai du mal à percevoir si en dehors de l'exploit technique ça donnera vraiment quelques choses mais ça force à réfléchir autrement. Qui sais, ça sera peut être réellement le futur WASM !
[^] # 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.