Si tu es sur une approche multi gît je comprends pas l'idée de vouloir interdire la lecture à un bout (un dossier) d'un git. Dans ce cas la je mettrais justement ce dossier dans son propre git dédié (avec donc ces propres droits d'accès)
Sur une approche mono git je pourrais comprendre l'envie d'avoir une ségrégation au niveau dossier mais sur une approche multi git j'ai du mal à saisir l'intérêt puisque n'importe quel dossier peu être un git dédié. Après effectivement gît dédié veut dire aussi son propre historique gît.
Après côté yocto on utilise pas ces fonctions là parce que yocto n'ai pas un environnement de dev, c'est un environnement de génération de distribution.
Git hook peut très bien être implémenté côté serveur. Et pour diffuser des githook côté client tu peux très bien aussi utiliser repo manifest (ou kas) pour ça, un repo qui contient tes githook dans ton manifest de gits avec une petite règle d'installation.
Pour les droits en lecture pas sur de comprendre, ça ce gère côté serveur pour moi, si le git est déjà descendu côté client tu pourras toujours le lire en utilisant pas ton outil non ?
Pour faire du multi git/git forest,tu as repo manifest coté Android ou kas coté yocto.
Pour gérer les droits d'accès dans git lui même,tu peux tout a fait faire ça dans le même git dans une branche dédié (et dans un refspec dédié) avec quelques git hook, c'est fait comme ça dans gerrit.
Plus proche de nous on a déjà RED-DA qui sera obligatoire au 1er août 2025 sur n'importe quel produit sans fil communiquant qui mets un sacré bazard normatif !
Pas convaincu du truc, restera en démonstrateur dans son coin.
Pour le code legacy C existant je crois beaucoup plus a hw kasan sur am64 pour rendre l'exploitation quasiment impossible, manque une solution équivalente côté x86_64.
Pour le code nouveau avec un fort besoin cyber,rust a pris la place.
Assez d'accord, ipv6 a modifier trop en profondeur la topo réseaux avec le RA et le support dhcpv6 qui n'a été spécifié que plus tard. Ça a été trop ambitieux au début pour moi.
La question pour moi aujourd'hui n'est pas git ou pas git mais quel serveur git. Pull request Branch based (github, gitlab) vs commit based (gerrit, phabricator)
Perso j'ai adoré Gerrit, son utilisation des refspec que j'utilise encore manuellement ailleurs,son commit id pour tracer un fixe quand on supporte plusieurs version long terme etc…
Dommage que github est écrasé la concurrence, gerrit avait de bien meilleur idée mais une ihm vielotte
J'arrive pas à comprendre l'architecture, niveau etcd, c'est un seul partagé entre toute les instances ou plusieurs instances et comment leur synchro est assuré ?
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.
[^] # Re: Repo manifest ou kas
Posté par Tangi Colin . En réponse à la dépêche Première publication libre de Multigit. Évalué à 2 (+1/-0).
Si tu es sur une approche multi gît je comprends pas l'idée de vouloir interdire la lecture à un bout (un dossier) d'un git. Dans ce cas la je mettrais justement ce dossier dans son propre git dédié (avec donc ces propres droits d'accès)
Sur une approche mono git je pourrais comprendre l'envie d'avoir une ségrégation au niveau dossier mais sur une approche multi git j'ai du mal à saisir l'intérêt puisque n'importe quel dossier peu être un git dédié. Après effectivement gît dédié veut dire aussi son propre historique gît.
[^] # Re: sympa
Posté par Tangi Colin . En réponse à la dépêche Première publication libre de Multigit. Évalué à 3 (+2/-0).
Repo permet bien de gérer des worklow,
par example https://source.android.com/docs/setup/reference/repo?hl=fr#forall
Ou repo start pour crée le même nom de branche dans tout tes git.
Après côté yocto on utilise pas ces fonctions là parce que yocto n'ai pas un environnement de dev, c'est un environnement de génération de distribution.
[^] # Re: Repo manifest ou kas
Posté par Tangi Colin . En réponse à la dépêche Première publication libre de Multigit. Évalué à 1 (+0/-0).
Git hook peut très bien être implémenté côté serveur. Et pour diffuser des githook côté client tu peux très bien aussi utiliser repo manifest (ou kas) pour ça, un repo qui contient tes githook dans ton manifest de gits avec une petite règle d'installation.
Pour les droits en lecture pas sur de comprendre, ça ce gère côté serveur pour moi, si le git est déjà descendu côté client tu pourras toujours le lire en utilisant pas ton outil non ?
# Repo manifest ou kas
Posté par Tangi Colin . En réponse à la dépêche Première publication libre de Multigit. Évalué à 1 (+0/-0).
Pour faire du multi git/git forest,tu as repo manifest coté Android ou kas coté yocto.
Pour gérer les droits d'accès dans git lui même,tu peux tout a fait faire ça dans le même git dans une branche dédié (et dans un refspec dédié) avec quelques git hook, c'est fait comme ça dans gerrit.
[^] # Re: Merci !
Posté par Tangi Colin . En réponse à la dépêche Guide CNLL/inno³ sur le Cyber Resilience Act : êtes-vous prêts pour les échéances de 2026 et 2027 ?. Évalué à 1 (+0/-0).
Plus proche de nous on a déjà RED-DA qui sera obligatoire au 1er août 2025 sur n'importe quel produit sans fil communiquant qui mets un sacré bazard normatif !
# Mouais...
Posté par Tangi Colin . En réponse au lien [The Register] To kill memory safety bugs in C code, try the TrapC fork. Évalué à 2.
Pas convaincu du truc, restera en démonstrateur dans son coin.
Pour le code legacy C existant je crois beaucoup plus a hw kasan sur am64 pour rendre l'exploitation quasiment impossible, manque une solution équivalente côté x86_64.
Pour le code nouveau avec un fort besoin cyber,rust a pris la place.
[^] # Re: Non, HTTP/3 n'est pas vraiment sur UDP
Posté par Tangi Colin . En réponse à la dépêche 24 ans de libcurl. Évalué à 2.
Assez d'accord, ipv6 a modifier trop en profondeur la topo réseaux avec le RA et le support dhcpv6 qui n'a été spécifié que plus tard. Ça a été trop ambitieux au début pour moi.
[^] # Re: La suite
Posté par Tangi Colin . En réponse au lien A Git story: Not so fun this time. Évalué à 4.
La question pour moi aujourd'hui n'est pas git ou pas git mais quel serveur git. Pull request Branch based (github, gitlab) vs commit based (gerrit, phabricator)
Perso j'ai adoré Gerrit, son utilisation des refspec que j'utilise encore manuellement ailleurs,son commit id pour tracer un fixe quand on supporte plusieurs version long terme etc…
Dommage que github est écrasé la concurrence, gerrit avait de bien meilleur idée mais une ihm vielotte
# Ça marche comment ?
Posté par Tangi Colin . En réponse au lien Liqo : kubernetes multi cluster. Évalué à 2.
J'arrive pas à comprendre l'architecture, niveau etcd, c'est un seul partagé entre toute les instances ou plusieurs instances et comment leur synchro est assuré ?
# 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.
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.
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.
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.
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.
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