Bruno Michel a écrit 3285 commentaires

Ça dépend pas mal de ce que l'on appelle parallélisme. Rayon cité juste au-dessus permet de faire du parallélisme sur des données, ie utiliser facilement plusieurs coeurs CPU pour faire du calcul.

Par contre, si on parle de parallélisme dans un contexte avec beaucoup d'IO, il y a async/await et tokio. Et là, les avis sont beaucoup plus partagés, on va dire. Certains apprécient que Rust reste bas-niveau, tout en évitant les bugs où des données partagées peuvent être lues/écrites depuis plusieurs contextes d'exécution. D'autres regrettent que ça reste bas niveau et peu pratique à utiliser. Il y a https://bitbashing.io/async-rust.html qui a pas mal fait parler de lui ces derniers temps.

Le type error est concrètement juste une chaîne de caractères

Non, c'est une interface :

type error interface {
    Error() string
}

Source : https://go.dev/doc/effective_go#errors

En pratique, les erreurs sont souvent des chaînes de caractères, mais on peut trouver d'autres types d'erreurs. Par exemple, la bibliothèque standard a un type PathError dans io/fs défini ainsi :

type PathError struct {
    Op   string
    Path string
    Err  error
}

Source : https://pkg.go.dev/io/fs#PathError

sans module tiers tel que xerrors ou autre, impossible de déterminer le type de l'erreur

De nos jours, on peut faire ça avec le module errors fourni avec la bibliothèque standard : https://pkg.go.dev/errors

Au final, je préfère un type monadique, comme std::expected en C++ ou Result en Rust.

Ici : […] on est obligé de traiter l'erreur […]

Est-ce que faire un unwrap, ça compte vraiment comme traiter l'erreur ? Mon avis personnel est que ce n'est ni mieux ni pire que res, _ := foo(). Dans les deux cas, on ignore explicitement l'erreur sans la traiter.

Perso, je trouve la gestion des erreurs en Go assez bof, mais pas atroce non plus.

https://httptoolkit.com/blog/docker-image-registry-facade/ peut t'intéresser.

il faut se créer un compte sur l’instance CozyCloud du Grand Lyon

Le lien n'est pas bon, ça devrait être https://manager.cozygrandlyon.cloud/grdlyon/onboarding_ecolyo.

Si les experts CozyCloud de l’assistance (je sais qu’ils sont parmi nous !) veulent bien partager leur connaissance, peut-être pourront-ils dire s’il est possible de récupérer (facilement et de manière automatisée) les données d’une telle application de CozyCloud ?

Si c'est pour récupérer une fois les données, la solution rapide, c'est d'aller dans l'application Paramètres de son Cozy, puis de cliquer sur « Exporter mon Cozy ».

Si c'est pour automatiser, c'est faisable en se créant un client OAuth sur son Cozy (https://docs.cozy.io/en/cozy-stack/auth/#post-authregister), en lui donnant la permission sur les bons doctypes (https://docs.cozy.io/en/cozy-stack/auth/#get-authauthorize), puis en faisant des requêtes pour récupérer les données du Cozy (https://docs.cozy.io/en/cozy-stack/data-system/).

Voici un exemple de script pour faire ça : https://gist.github.com/clochix/48a7537b248f4272fc2513cd9722817f

Pour connaître les doctypes utilisés, on peut s'appuyer sur le manifeste de l'app Ecolyo (https://forge.grandlyon.com/web-et-numerique/llle_project/ecolyo/-/blob/dev/manifest.webapp#L183-255) et du code des connecteurs (https://forge.grandlyon.com/web-et-numerique/llle_project/egl-konnector/-/blob/master/src/index.js#L32-43).

L'historique sur Github remonte jusqu'à 2009, mais le travail était déjà bien avancé, vu le premier commit

Non, c'est vraiment ce jour là que le travail a commencé. Le premier commit est un peu gros, mais en fait, c'est juste le générateur de Rails pour créer un nouveau projet. Par contre, ça faisait un bout de temps que l'idée était dans l'air.

Je ne dis pas que tu as forcément tord, je dis juste que tu mélanges ton opinion avec des faits avérés. Les 2 décisions que tu as citées ne permettent pas à elles-seules d'affirmer la remise en cause de l'existence des services SaaS.

Pour moi, les services SaaS sont dans une zone floue, sujette à l’interprétation du RGPD par la CNIL et ses consœurs. J'ai tendance à penser que tant que les services SaaS ne cherchent pas à définir les finalités, et offrent à leurs clients un certain contrôle, ils vont pouvoir rester data processor (mais la ligne peut être rapidement franchie).

Note également que le paragraphe 28 des lignes directrices EDPB dit :

Even if the processor offers a service that is preliminary defined in a specific way, the controller has to be presented with a detailed description of the service and must make the final decision to actively approve the way the processing is carried out and to be able to request changes if necessary.

Pour moi, ça indique bien qu'un SaaS avec un service pré-existant peut quand même être un data processor (sous certaines conditions).

voir ici l’IAPD des Pays-Bas sur ce sujet pour Microsoft Office 365, § 16.2.4 Microsoft does not act as a data processor

Encore une fois, je pense que tu généralises un cas particulier sans que ça ne me paraisse très clair que ce soit vraiment généralisable. Dans la partie 5, l'IAPD fait valoir de nombreux arguments pour justifier que Microsoft n'est pas qu'un data contractor :

• le contrat est fait avec Microsoft Corporation (entreprise américaine) et les données personnelles sont envoyées aux États-Unis
• Microsoft fait appel à plus de 100 sous-traitants et le client n'a aucun droit de regard sur ces sous-traitants
• Microsoft ne fournit pas de copies de ses contrats avec ses sous-traitants
• Microsoft a refusé au client un droit d'audit sur l'utilisation des données personnelles
• Microsoft n'a pas de documentation exhaustive sur le type des données personnelles utilisées
• Microsoft s'autorise à rajouter des finalités (sous réserve qu'elles soient compatibles avec le traitement des données de diagnostic)
• etc.

Globalement, ce qui ressort, c'est que Microsoft empêche son client de pouvoir jouer son rôle de contrôle, et que du coup, il ne peut pas être qualifié de data processor. Mais je ne pense pas que l'on puisse étendre ça à tous les SaaS.

mais le texte est clair : c’est bien finalité OU moyens

Le point 331 dit pourtant :

En outre, on considère généralement que la définition des finalités du traitement l'emporte sur celle des moyens lorsqu'il s'agit d'établir la responsabilité d'une organisation.

Je ne partage pas ta lecture de cette décision.

Si on lit les considérants, en particulier à partir du 326-341, il devient vraiment assez difficile d’être sous-traitant dans une relation commerciale, et on endosse la responsabilité du traitement très très rapidement. Dès qu’on décide d’une modalité (326), dès qu’on vend/loue son produit (328), dès qu’on a décidé d’une orientation (330), en gros dès qu’on a développé une solution informatique (341), et ce y compris si on n’a pas accès directement aux données à caractère personnel (327), on est co-responsable avec son client de tous les traitements. Y compris des usages de son client du coup.

On peut comprendre ta phrase comme étant dès que l'on fait A ou dès que l'on fait B ou dès que l'on fait C, alors on est automatiquement caractérisé comme co-responsable de traitement. Alors, que pour moi, IAB Europe a voulu se défendre en indiquant qu'ils fournissaient des spécifications techniques et des documents de politiques (policies), un peu comme l'IETF pourrait le faire pour spécifier HTTP et les cookies, et l'APD vient démontrer que la position d'IAB Europe est bien large que ça et qu'elle recouvre ET les critères de A, de B et de C.

Le point 331 montre l'importance de la détermination des finalités de traitement pour désigner un responsable de traitement. Or, je ne pense pas que tous les services SaaS déterminent eux-mêmes les finalités pour leurs clients. Si un service fournit un chatbot, il peut servir pour des finalités commerciales, ou du support, ou d'autres raisons, et c'est au client de ce service de définir la finalité pour laquelle il compte utiliser le services en question.

Ça dépend du temps qu'il consacre à ça. S'il répond à 1 ou 2 tickets de temps en temps, ça peut être un moyen pour lui d'avoir une meilleure vision de ce que pense les clients de son produit et de ce qu'il faudrait améliorer en priorité. Mais, effectivement, il ne faudrait pas que ça lui prenne du temps plus utile par ailleurs.

le serveur Bitwarden ne manipule pas de mots de passe, uniquement des vaults

Non, le serveur Bitwarden peut bien manipuler des secrets (ça s'appelle des ciphers dans leur terminologie). Il faut voir un vault comme une base de données, et dedans chaque cipher est un enregistrement. Et on peut manipuler unitairement un enregistrement, pas obligatoirement toute la base.

Vous pouvez facilement vérifier ce point en regardant les points d’entrées d’API dans la documentation officielle qui ne liste que des points d’entrée permettant de manipuler des collections (et donc des vaults)

Je ne sais pas trop à quoi correspond cette doc, mais quand on regarde en détails, il n'y a pas de vault ou de ciphers dans les collections.

Je pense donc ne pas me tromper en disant que ce sont donc des vaults cryptés contenant un ensemble de mots de passe qui sont envoyés au serveur en cas d’update, et donc pas des mots de passe individuels. Si vous avez une information prouvant l’inverse, n’hésitez pas à partager.

Oui, on va prendre la source de vérité, le code. La jslib est la bibliothèque utilisée par le CLI en nodejs, les extensions navigateurs et l'interface web.

• Création d'un cipher : https://github.com/bitwarden/jslib/blob/ca5b057b43ddf1ad671385b589395a91acd808b6/common/src/services/api.service.ts#L586-L589
• Mise à jour d'un cipher : https://github.com/bitwarden/jslib/blob/ca5b057b43ddf1ad671385b589395a91acd808b6/common/src/services/api.service.ts#L601-L604
• Suppression d'un cipher : https://github.com/bitwarden/jslib/blob/ca5b057b43ddf1ad671385b589395a91acd808b6/common/src/services/api.service.ts#L611-L613

On retrouve ça dans vaultwarden (l'implémentation en Rust) :

• Création d'un cipher : https://github.com/dani-garcia/vaultwarden/blob/9a60eb04c20fcf1f43767290ee795efe946ef3eb/src/api/core/ciphers.rs#L268-L283
• Mise à jour d'un cipher : https://github.com/dani-garcia/vaultwarden/blob/9a60eb04c20fcf1f43767290ee795efe946ef3eb/src/api/core/ciphers.rs#L524-L545
• Suppression d'un cipher : https://github.com/dani-garcia/vaultwarden/blob/9a60eb04c20fcf1f43767290ee795efe946ef3eb/src/api/core/ciphers.rs#L1137-L1140

Pour la doc, j'avais trouvé https://github.com/jcs/rubywarden/blob/master/API.md#saving-a-new-item. C'est un document écrit par quelqu'un qui avait développé une implémentation server alternative à Bitwarden en Ruby. C'est vieux et plus maintenu à jour, mais ça explique bien les principes de base de bitwarden.

A ma connaissance, Bitwarden n’implémente pas de fonctionnalités similaires. Pouvez-vous confirmer?

Je confirme, la fonctionnalité de commentaires de Bitwarden est beaucoup plus basique. Ceci dit, je continue de penser que c'est trompeur de dire que Bitwarden ne permet pas de commenter un secret. En fait, j'aurais plutôt tendance à appeler la fonctionnalité de passbolt un chat que des commentaires.

il est nécessaire pour un utilisateur d’enclencher lui-même le mode “recovery” avant qu’un administrateur puisse débloquer sa clef

Oui, sauf si c'est l'administrateur a accès au serveur applicatif, à la base de données ou au serveur de mails. Et ça peut arriver assez vite pour un administrateur.

De plus, il est prévu pour bientôt un mode shamir qui permettra de n’activer ce superpouvoir que lorsque le quorum d’administrateurs sera atteint, justement pour pallier cette problématique.

C'est une super bonne idée d'utiliser un secret de Shamir pour ça. On avait réfléchi à faire ça pour Cozy Passwords, mais pour le moment, on manque de temps pour finaliser ça (surtout les parties expérience utilisateur où il faut bien expliquer l'utilisateur ce qui se passe et comment ça fonctionne).

Pour le transfert de la clé privée quand on configure un nouveau device, passbolt utilise des QR codes. Je vois assez bien comment ça peut marcher quand on a le client sur son PC et que l'on veut mettre en place l'application sur un mobile. Mais, dans l'autre sens, si on a d'abord configuré l'app mobile, est-ce que c'est possible aussi ? Uniquement si on a une webcam ?

Quelques précisions :

Du fait que passbolt gère les mots de passe individuellement sans utiliser de système de vault, cela lui confère certaines propriétés intéressantes. Par exemple, lorsqu’un mot de passe partagé est mis à jour, la version mise à jour est accessible immédiatement par l’ensemble des utilisateurs avec lesquels il est partagé. Sur Bitwarden, c’est un processus qui peut prendre un certain temps surtout si les vaults sont gros car il faut d’abord que le nouveau vault soit re-uploadé sur le serveur et qu’il soit ensuite re-téléchargé par les clients.

Pour bitwarden, quand un mot de passe est modifié, seul ce nouveau mot de passe est envoyé au serveur, pas tout le vault. En fait, j'aurais même tendance à penser que le temps-réel serait plus rapide avec Bitwarden qu'avec passbolt. Dans le cas de bitwarden, le mot de passe est chiffré une seule fois (avec la clé du vault partagé), et il n'y a que ça qui est envoyé au serveur, puis téléchargé par les autres utilisateurs. Alors qu'avec passbolt, le mot de passe va être chiffré une fois pour chacun des utilisateurs avec qui le mot de passe est partagé. Donc, si on partage un mot de passe avec un grand groupe d'utilisateur, ça pourrait être plus long. Ceci dit, en pratique, je pense que ça reste très rapide dans les deux cas.

Sur Passbolt il est possible de collaborer sur un mot de passe donné: de laisser des commentaires, de tagger un mot de passe comme expiré, ou encore d’organiser les mots de passe dans un système de dossiers imbriqués où chaque niveau peut avoir ses propres permissions d’accès. Ces fonctionnalités n’existent pas chez Bitwarden.

Bitwarden permet de laisser un commentaire sur un mot de passe donné. Pour ce qui est d'organiser les mots de passe, Bitwarden a pris le choix de laisser chacun organiser les mots de passe comme il le souhaite dans ses dossiers (sans imbrication possible).

Sur Passbolt, les opérations sont loguées par le serveur au moment où elles s’effectuent, avec contrôle d’integrité. La plupart des opérations de chiffrement sont également signées par les clefs utilisateurs.

Un petit bémol est que les administrateurs peuvent accéder aux clefs utilisateurs quand l'option de récupération de compte est activée, et donc se faire passer pour les utilisateurs.

Bitwarden pour sa part dérive les clefs à partir du mot de passe de l’utilisateur.

C'est un peu plus compliqué que ça : bitwarden génère aléatoirement une clé de chiffrement AES, et c'est cette clé qui est utilisée pour chiffrer les secrets dans la vault. Il utilise également un système de clés publique/privée en RSA pour partager des secrets avec d'autres utilisateurs. D'un point de vue crypto, c'est très solide (jusque là).

Et on arrive au mot de passe. Pour permettre à un utilisateur de configurer simplement plusieurs extensions navigateurs, clients mobiles ou lourds, Bitwarden a fait le choix de la simplicité de l'utilisateur (au détriment de la sécurité). L'utilisateur a un mot de passe et les clients en font 2 dérivations. Une dérivation sert à l'authentification au serveur. Et quand on est authentifié au serveur, on peut demander la clé AES. Cette clé n'est évidemment pas stocké en clair sur le serveur (elle donne accès à tous les secrets pour rappel), et c'est la seconde dérivation du mot de passe qui permet de la chiffrer/déchiffrer.

Cela signifie que deviner le mot de passe utilisateur “suffit” à usurper son compte

Du coup, oui, si on devine le mot de passe de l'utilisateur, on peut alors s'authentifier auprès du serveur, télécharger la clé AES chiffrée, la déchiffrer, télécharger la vault, et accéder aux secrets dedans.

Est-ce que cela concerne uniquement le client web ou aussi les extensions navigateurs ?

Cela concerne uniquement le client web, pas les extensions navigateur.

À propos de rclone, il sait faire du WebDAV, et NextCloud expose du WebDAV. Donc, il doit être possible d'utiliser rclone pour envoyer directement la sauvegarde à NextCloud.

Pour croiser les index, il y a également languish, qui s'appuie principalement sur les données de GitHub.

Salut,

j'ai bossé il y a quelques années sur le client desktop de synchro de fichiers pour Cozy Cloud, et même si je n'ai plus les mains dedans, je continue de suivre les développements, les retours des utilisateurs, et de réfléchir à des idées pour l'améliorer. C'est probablement l'un des projets les plus difficiles sur lequel j'ai eu à travailler, mais aussi l'un des plus intéressants. J'ai écrit une note à ce sujet (en anglais) : https://github.com/nono/cozy-desktop-experiments/blob/main/RFC/Interest.md.

Au début, ça a l'air plutôt facile, on arrive facilement à faire un truc qui fonctionne en local. Puis, on le met entre les mains des utilisateurs, et on découvre plein de bugs. On les corrige, et on recommence. Et, après quelques itérations, on se rend compte que c'est un système distribué que l'on est en train d'écrire, et que faire un truc fiable dans ce domaine ne s'improvise pas. Mon principal regret est de ne pas avoir écrit un simulateur au début (c'est beaucoup plus compliqué à faire a posteriori quand la base de code commence à être grosse) : https://lobste.rs/s/igiolo/learning_build_distributed_systems#c_nlpl7r explique bien le principe.

Je conseille aussi fortement la lecture de ces 2 articles de Dropbox, sur la refonte de leur client (en rust) :

• https://dropbox.tech/infrastructure/rewriting-the-heart-of-our-sync-engine
• https://dropbox.tech/infrastructure/-testing-our-new-sync-engine

doit pouvoir être déployé sur des machines quelconques (Linux, Windows, MacOS)

Bon courage ! Je vois que tu as commencé par Linux (tu parles d'inotify), c'est très bien, c'est l'OS le plus facile à mes yeux. Le système de fichiers est sensible à la casse, ce qui évite certains problèmes par exemple (HFS+ sur les anciens macOS fait de la normalisation unicode des chemins à l'aide d'un algorithme proche de NFD mais non standard, ça a nous a donné une tonne de bugs sur cozy-desktop).

Pour Linux, il faut faire attention à ne pas utiliser le numéro d'inode comme un identifiant de fichier de manière trop strict. Il y a 2 pièges à ça :

• quelques logiciels passent par un fichier temporaire quand on sauvegarde (genre vim ou libreoffice) : ils créent une copie du fichier avec la nouvelle version, puis quand ils ont fini d'écrire, ils suppriment l'original et déplacent la copie à l'emplacement de l'original => c'est le même fichier aux yeux de l'utilisateur, mais le numéro d'inode a changé

• les systèmes de fichiers réutilisent assez facilement les numéros d'inode :

$ echo foo > foo
$ stat foo      
  File: foo
  Size: 4           Blocks: 8          IO Block: 4096   regular file
Device: fd00h/64768d    Inode: 7870750     Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/    nono)   Gid: ( 1000/    nono)
Access: 2021-10-02 17:43:24.628613580 +0200
Modify: 2021-10-02 17:44:07.714126187 +0200
Change: 2021-10-02 17:44:07.714126187 +0200
 Birth: -
$ echo bar > bar
$ rm foo
$ echo baz > baz 
$ stat baz
  File: baz
  Size: 4           Blocks: 8          IO Block: 4096   regular file
Device: fd00h/64768d    Inode: 7870750     Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/    nono)   Gid: ( 1000/    nono)
Access: 2021-10-02 17:44:28.994866193 +0200
Modify: 2021-10-02 17:44:28.994866193 +0200
Change: 2021-10-02 17:44:28.994866193 +0200

foo et baz sont 2 fichiers différents, mais ils ont eu le même numéro d'inode (juste pas en même temps).

Voilà, j'espère que ça donne quelques pistes pour améliorer la fiabilité du trsync.

Ça ne serait pas la même chose que https://linuxfr.org/suivi/liens-markdown ?

Est-ce que la version de Ruby est plus vieille que celle disponible sur Debian Stretch (version 2.3.3) ?

C'est bien cette version.

linuxfr@prod:~$ ruby -v
ruby 2.3.3p222 (2016-11-21) [x86_64-linux-gnu]

pourquoi est-ce que l'on est passé au framework rspec2 ?

C'était une autre époque. Aujourd'hui, le choix entre rspec et le framework de tests officiel de Rails est principalement une question de goûts (la syntaxe n'est pas la même), mais les deux sont très complets et ont copié de l'autre tout ce qu'il y avait d'intéressant.

si je recommence de zéro, on pourrait à nouveau utiliser le framework de rails ?

Oui, pas de soucis.

est-ce que les tests qui étaient dans le dossier spec étaient vraiment trop cassé ? est-ce que je devrais recommencer de zéro ? étaient-ils utiles ?

Les tests n'étaient pas très cassés, j'aurais pu les corriger en moins d'une heure. Par contre, ils n'étaient pas vraiment utiles. Je ne pense pas qu'ils n'aient jamais trouvé le moindre bug. La couverture de tests était vraiment très faible et c'était surtout les mêmes pages que je regardais quand je développais des nouvelles fonctionnalités. Si la page d'accueil casse, je m'en rendais compte très très rapidement, sans avoir besoin de tests automatisés pour ça.

Mais, sans aucun tests, il est impossible de prendre la décision de fusionner les merge request.

Pour info, même avec des tests, je pense que ça reste compliqué de prendre la décision. Il faut avoir une bonne couverture de tests pour que ça aide et, pour ça, il faut y passer beaucoup de temps à écrire des tests, temps qui serait probablement plus utile ailleurs. Et il faut aussi faire très attention à la version de Ruby : on a une version de Ruby assez ancienne en prod et j'ai plusieurs fois dû faire des reverts à cause de ça.

Pareil, je ne connaissais pas du tout la location et j'aime beaucoup l'idée. En plus, une offre à base de FP3, c'est vraiment tentant !

Ça dépends "simpler" par rapport à quoi

Je suppose que c'était en comparaison du C. Mais, à part C++, j'ai du mal à voir quel point de comparaison mettrait Rust dans la catégorie "simpler". La grammaire de Rust est connue pour être riche et les efforts pour la documenter n'ont pas été très concluants jusque là (cf https://github.com/rust-lang/rfcs/blob/master/text/1331-grammar-is-canonical.md et https://github.com/rust-lang/wg-grammar par exemple).

Globalement, je vois bien pourquoi une personne peut vouloir créer un "better C" qui ne soit pas Rust. Rust est très complexe, non standardisé, et demande beaucoup d'efforts pour être appris. Il convient bien pour des projets complexes (genre des briques d'un navigateur web), mais il y a probablement une place pour un autre langage pour des projets plus simples et qui n'ont pas besoin de toute cette complexité.

C'est étrange, j'ai l'impression que c'est quasiment le même positionnement que Zig. Quelqu'un saurait dire la différence ?

More robust error handling via tagged unions

L'opérateur ! permet de créer des unions avec des erreurs dans ce but : https://ziglang.org/documentation/master/#Error-Union-Type.

Improved, Unicode-aware string support

Zig considère l'UTF-8 comme l'encodage par défaut des chaînes de caractères : https://ziglang.org/documentation/master/#String-Literals-and-Unicode-Code-Point-Literals

Memory safe array, slice, and pointer types (and unsafe versions, if needed)

Zig a des « sentinel-terminated pointers » (et de même pour les tableaux et slices) : https://ziglang.org/documentation/master/#Sentinel-Terminated-Pointers

Direct compatibility with the C ABI for trivial C interop

C'est un des gros points forts de Zig : https://ziglang.org/learn/overview/#integration-with-c-libraries-without-ffibindings

A simpler, context-free, expression-oriented syntax

La grammaire de Zig m'a l'air de répondre à ça : https://ziglang.org/documentation/master/#Grammar

A standard library free of the constraints of POSIX or the C standard

J'ai du mal à dire. La bibliothèque standard de Zig est là : https://ziglang.org/documentation/master/std/

L'objectif est d'avoir une version du langage finie et prête pour la production début 2022. Et que le compilateur supporte Linux, BSDs, Haiku et Plan 9; sur les architectures x86_64, aarch64, i686, riscv64, riscv32 et ppc64. Rien que ça.

Zig est en train de réécrire son compilateur en zig (avec ce qu'il faut pour bootstraper correctement le compilateur), donc ce n'est clairement pas encore prêt pour de la production. Mais ça paraît bien plus avancé que ce nouveau langage.

Côté plateforme, il doit manquer Plan 9 (https://github.com/ziglang/zig/issues/7153) et la prise en charge d'Haiku a l'air toute récente (https://github.com/ziglang/zig/pull/7546).

Pour les architectures :
https://ziglang.org/learn/overview/#wide-range-of-targets-supported (comme ça s'appuie sur LLVM, il y a déjà un paquet d'architectures prises en charge).

Ça va mieux avec https://github.com/linuxfrorg/linuxfr.org/commit/27561a03eecfb121c010132027140127bd06e35a

Ce code de démonstration me laisse perplexe et ne me donne pas envie d'essayer sérieusement le toolkit Atlas.

Déjà, le côté sécurité ne semble pas être pris en compte :

    html += f'<tr id="{contactId}" data-xdh-onevent="Select" style="cursor: pointer;">'
    for key in contact:
      html += f'<td>{contact[key]}</td>'
    html += '</td>'

Soit je rate quelque chose, soit il n'y a aucun échappement des caractères <, > et &. Et on perd aussi les retours à la ligne pour la note (il y a 2 lignes dans le textarea, mais une seule dans le tableau).

Et sur la partie visibilité des boutons, je suis perdu : pourquoi ajouter/retirer des balises <style> du DOM plutôt que d'ajouter/retirer directement les boutons ?

Ici, l’évènement est un clic sur une ligne du tableau contenant la liste des contacts, évènement auquel a été associée l’action Select via l’attribut data-xdh-onevent.

Je suppose que ça veut dire que l'on ne peut faire cette action qu'à la souris, pas au clavier. Bonjour l'accessibilité !

Et, franchement pour donner envie, ça aurait été bien de faire quelque chose d'un plus joli. Ce n'est quand même pas très compliqué de prendre un framework CSS comme bootstrap et l'utiliser ici.

Je ne suis probablement pas le public visé, mais je trouve que c'est assez difficile de comprendre comment ça fonctionne à la lecture de cet article (probablement, faute de repères par rapport à ce que j'ai l'habitude). Et j'ai l'impression que c'est vite limitant (comme faire des transitions CSS ? de l'infinite scroll ? gérer du routage avec différentes URL ?).

J'ai intégré la Pull Request et publié une version 0.1.3 de la gem avec les changements.