Andréas Livet a écrit 254 commentaires

C'est en effet une fonctionnalité intéressante dont je parlerai dans le prochain article qui porte sur l'usage du gestionnaire de paquet.

Après, je n'avais pas mis cet élément trop en avant, si tu me le permet, je reprendrai une partie de ton commentaire dans mon prochain article.

Merci.

Merci pour ton commentaire, j'avoue avoir découvert Nix avec Guix, donc j'ai une mauvaise connaissance de ce projet et des différences entre les deux.

Sinon, c'est du détail mais je crois que "GuixSD" s'appelle maintenant "Guix System".

Je n'avais pas vu, j'aimerai éditer mon journal mais je ne sais pas comment faire… c'est le premier journal que j'écris sur linuxfr.

Oui, pour l'instant ce sont uniquement des outils en ligne de commande et la configuration du système se fait avec un éditeur de texte… Il y a tout de même un installeur "graphique" (en ligne de commande) pour la distribution mais je ne l'ai pas encore utilisé.

Donc ça reste des outils réservés à des utilisateurs avancés, voir très avancés pour certains.

Pour ce qui est du simple gestionnaire de paquet, si vous savez faire un apt install, vous saurez faire un guix install :).

Content d'avoir éveillé ta curiosité :).
Certains articles sont quasiment finis, d'autres en cours de rédaction et d'autres pas encore commencés.
Je ne sais pas si j'aurai l'énergie d'aller jusqu'au bout de ma démarche, à savoir de décrire toutes les applications potentielles de Guix avec un exemple concret à chaque fois.
Ça risque de prendre pas mal de temps, mais qui sait ? :)

Vraiment sympa l'idée, en plus le code est assez court

Oui, je me demande pourquoi d'autres l'ont pas eu avant !

En tout cas c'est torrent-stream qui fait quasi tout le boulot. C'est ce qui est utilisé dans Popcorn Time (Butter) et ça fonctionne étonnamment bien. Par contre, il me semble que c'est pas accepté par tous les trackers.

Ce projet m'a l'air bien intéressant et je me dis que ça pourrait être un parfait candidat pour intégré un projet que j'avais commencé, mais vite arrêté à cause des limitations des navigateurs et du manque de temps.

En fait, je cherchais à convertir les liens torrents ou magnet comme de simple url http avec derrière un petit serveur web qui tourne et torrent-stream (bon je sais cay mal de streamer les torrent mais je trouvais l'idée vraiment sympa).

De cette manière tu pouvais cliquer sur un lien torrent ou magnet et ça le téléchargeait avec le gestionnaire de téléchargement natif du navigateur. Pareil pour les vidéos, je pouvais les voir dans une balise classique (si le format était compatible). Les torrents contenants plusieurs fichiers étaient affichés avec une interface html générée à la volée.

Le problème c'est qu'il fallait lancer le serveur web à côté et que Firefox ne permet plus d'intégrer des binaires à ses plugins.

Voilà un POC vraiment fait à l'arrache du projet : https://github.com/dedesite/firefox-torrent

Bref, en tout cas Next à l'air vraiment sympa, bravo à toute l'équipe !

Bravo pour cette initiative !

C'est vraiment chouette de voir toutes ces aventures industrielles qui essayent d'avoir une démarche favorisant une utilisation plus conviviale (au sens d'Ivan Illich) de nos outils. Certes, ça reste limité à l'assemblage/réparation mais c'est déjà ça :).

Je rejoins les remarques concernant le fait que le système d’éjection n'est pas forcément le plus pertinent étant donné la grande simplicité des connecteurs actuels (SATA, RAM etc.).
Par contre, ça le devient beaucoup plus les pour les différentes nappes (écran, clavier, touchpad, caméra) car elles sont très fragile et pas toujours faciles à manipuler.

Pareil pour les connecteurs d'alimentation ou autres prises éthernet qui quand ça casse ne sont pas très marrants à réparer…

L'autre gros problème déjà soulevé est la durée de vie des sockets et autres connectiques et ça c'est hors du scope de votre projet vue que vous ne faites qu'acheter des pièces produites par d'autres. Mais, à terme, il faudrait que les industrielles soient capable de s'engager sur des standards à long terme pour permettre à des projets comme le votre d'exister.

Sinon on parlait d'autres retours d'aventures industrielle, je pense que vous connaissez tous le projet EOMA86 ? Si c'est pas le cas, la lecture des comptes rendu de la campagne de financement participatif et un régal :
https://www.crowdsupply.com/eoma68/micro-desktop/updates

Ils ont eu tellement de galère sur ce projet… et pourtant l'initiateur du projet n'est pas né de la dernière pluie.

Au plaisir de suivre l'avancée du projet.

Oui je sais bien que les dernières distrib sont compatibles UEFI.
Juste que j'ai jamais pris le temps de regarder et que j'utilise usb-creator-gtk pour créer mes clés bootables et qu'il ne prend pas en charge UEFI (en tout cas pas la dernière version que j'utilise), c'est sans doute pas la meilleure solution… mais c'est ce que j'ai l'habitude d'utiliser.

Donc bon, c'est plus de la "flemme" qu'autre chose :D.

Merci pour ce retour, j'ai eu le même genre de souci en installant Ubuntu 18.04 sur le récent portable d'une amie : la carte wifi était trop récente.

Heureusement, je bidouille un peu et j'ai rapidement trouver un driver plus à jour et en quelques minutes c'était réglé.

Par contre, n'étant pas à l'aise avec UEFI, j'avais désactivé l'option "Secure boot" de l'ordi et malheureusement quand il n'a plus du tout de batterie, cette option se réactive…

Ce qui fait que l'ordi ne veut plus booter ! Alors, encore une fois la solution est pas sorcière mais mon amie ne peut pas être autonome…

Elle a du le faire réinstaller quand je n'étais pas là (je soupçonne que c'était encore un problème de Secure boot mais bon) et la personne qui l'a remis n'a pas réussi à faire fonctionner le wifi alors qu'il s'y connaissait en Linux apparemment (à moins qu'il n'ait juste pas vu que le wifi ne fonctionnait pas).

Quoiqu'il en soit, Linux c'est génial et enseignant l'informatique à des néophytes, je peux vous dire que c'est une plaie d'avoir des machines sous Windows (y a toujours un truc qui va pas, un logiciel mal installer, ça rame dans tous les sens on sait pas pourquoi etc.), mais ça reste tout de même réserver à ceux qui connaissent.

Windows n'est pas en reste non plus, combien de fois j'ai eu a régler d'obscures problèmes de Mises à jour Windows qui ne se faisait pas, de drivers foireux, d'incompatibilités logiciel et j'en passe et des meilleurs. La différence avec Windows c'est qu'il n'y a qu'une plateforme (bon avec des versions différentes d'accord) et beaucoup d'utilisateurs, ce qui fait que la solution se trouve souvent plus facilement. Puis qu'elle passe rarement par la ligne de commande, ce qui est moins rédhibitoire pour les amoureux de la souris.

Perso, même sous Windows je préfère la ligne de commande et fais installer aux étudiants leurs outils via Chocolate (dont l'installation est pas des plus simples et a planter chez beaucoup pour d'obscures problèmes de droits… comme quoi !)

Je fais ça au fil de l'eau en fonction des besoins et des problèmes que je rencontre.

D'ailleurs, sous Xubuntu 18.04, j'ai toujours ces messages d'erreur :

bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)

J'ai trouvé ces notes qui parlent de ce problème, mais les solutions proposées n'ont pas tout résolu.

Bref, je ne sais pas quand ça sera fini.

Si ça t'intéresse, j'écris ça sur un pad HackMd : https://pad.lamyne.org/s/HJ5J3SWCN#

Sens toi libre de participer :)

Tu peux aussi regarder avec guix graph

Wow impressionnant cet outil :) !

Encore merci pour toutes ces précisions.

Un paquet peut avoir plusieurs sorties

Ah oui j'avais oublié ça, mais quand on télécharge le paquet par défaut, justement ça ne prend pas toutes les sorties, donc ça devrait être bon niveau taille non ?

Exemple avec le paquet glib qui ne télécharge pas la doc par défaut. Comme précisé dans la doc.

Ces paquets n'ont pas été séparés en bibliothèques / binaires / etc, mais ils pourraient l'être.

Je ne l'ai pas mal pris comme une critique :).

Pour mes articles, ça va être vraiment de l'introductif, genre comment je peux remplacer mes outils actuels en utilisant guix. Si tu es déjà habitué à Nixos, tu ne devrais pas apprendre grand chose je pense…

Merci pour toutes ces précisions.

A force de me documenter sur guix je commence à comprendre bien son fonctionnement et cela me ravie :).

Ces paquets n'ont pas été séparés en bibliothèques / binaires / etc, mais ils pourraient l'être.

Qu'entends tu par là ?

Maintenant, j'aimerais savoir si certains d'entre vous étaient développeurs (tous langage) et ont aussi fait une reconversion professionnelle ? si oui vers quoi ? quand ? pourquoi ? comment ?

Après quelques années à faire du C++ dans une boîte de JV avec des très bon techniciens (bonne connaissance de toutes les fonctionnalités C++), mais de très mauvais concepteurs (syndrome de l'"over design" comme disait un collègue), je suis passé d'abord par du dev d'applicatifs web. Puis, me rendant compte que je ressentais toujours la même chose : plus de goût pour les projets perso, difficulté avec les collègues car trop exigeant (sans doute pas à ton niveau) sur les projets, j'ai décidé de tout plaquer.

Pendant quelques mois, j'ai suivi une formation d'"Animateur en agroécologie", c'était vraiment génial ! J'ai aussi fait de l'éco construction en chantier participatif, une des plus belle expérience de ma vie.

De retour à la "réalité" (et oui j'avais besoin de sous), j'ai finalement trouvé un boulot d'accompagnateur pédagogique à Epitech, puis après responsable d'un cursus de dev web pour jeunes décrocheurs scolaires.

J'ai encore arrêté pour cause de déménagement et enfant, j'ai encore pris du temps pour ma famille et moi-même (c'est vraiment très important je trouve de reprendre le temps de faire autre chose que d'être productif).

Puis j'ai repris le dev tout en faisant de l'enseignement.

Aujourd'hui, j'ai trouvé le bon équilibre : je suis dans une CAE (Coopérative d'Activité et d'Emploi) qui me permet d'être indépendant tout en étant salarié de mon activité.

Je bosse quand je veux/peux et j'ai un salaire que je décide qui tombe tous les mois.

J'ai fais le choix de peu travailler et d'avoir un petit salaire (proche du SMIC) afin d'avoir du temps pour faire autre chose que du dev pour d'autres personnes.

Concrètement, je fais du dev quelques mois par an (ça va de 2 à 5 mois) et de la formation initiale et professionnelle de temps en temps. Avec ça, j'ai assez pour vivre toute l'année et le reste du temps je le passe avec mes enfants, à faire des travaux dans la maison (gros gros travaux), du jardinage, etc. Bref, plein de trucs chouettes !!

Je me sens vraiment moins frustré et quand je dev, je m'éclate vraiment. Je cherche toujours à découvrir une nouvelle techno et y aller bien à fond comme ça c'est super intéressant, je cherche à faire les choses le mieux que je peux (pas toujours évident avec les contraintes de temps) et, comme ça dure pas longtemps, c'est moins frustrant même si dès fois je suis sur des technos totalement à chier.

Voilà mon petit retour d'expérience, espérons que ça t'inspire :)

Andréas

Oui c'est vrai que c'est pas tout jeune… Mais je ne sais pas parfois, je ne porte pas intérêt à certaines choses et puis d'un coup, on prend plus le temps de lire une dépêche qui a priori ne nous intéresse pas trop (j'avoue, avoir un nouveau gestionnaire de paquet, ou une nouvelle distro, si il ne change pas fondamentalement mon usage de l'OS, ça m'importe peu) et PAF on s'en prend plein la gueule !

C'est ce que ça m'a fait avec Guix et je me rends compte maintenant de la puissance de l'outil et à quel point il est capable de remplacer avantageusement une pléthore d'autres outils. C'est vraiment impressionnant !

Je crois que j'ai toujours eu en tête de pouvoir faire ce genre de chose dans ma distrib sans avoir une once d'idée de par où commencer et quelle serait la meilleure méthode pour y arriver.

Avec Guix, le résultat est bluffant de simplicité si l'on compare à l'ensemble des technos que cela peut remplacer et la complexité qui s'empile dans nos "piles" (c'est bien le mot d'ailleurs !) de développement modernes.

J'ai toujours vu d'un œil un peu suspect les développements autour de snap, flatpack, Docker et autres. Ça m'a toujours paru bizarre aussi d'avoir des outils pour gérer mes version et mes dépendances en ruby, node, python, ou php. Certains, comme npm, étant en plus assez obscures (qui n'a pas déjà entendu : "essai de supprimer le dossier node_modules et recommence pour voir") et peu configurables (ex : le dossier node_modules est codé en dur…).

Aujourd'hui, nous avons vraisemblablement (pas encore assez pratiqué pour être sûr) une réponse élégante et unique à tous ces problèmes (et bien d'autres) et c'est tant mieux !

Je prépare un article en mode "Guix pour remplacer x, y ou z" avec des petits exemples à chaque fois.

Je le mettrai sur linuxfr si ça intéresse.

Ce chemin vers la bibliothèque standard C ne vient pas de nul part : le paquet est compilé à partir d'une recette qui vient d'une version précise de Guix. Le chemin est question est celui qui provient de la recette de glibc dans la même révision de Guix. Si une future révision de Guix met à jour la recette de glibc (par exemple en la mettant à jour), cela modifie l'entrée correspondante pour le paquet hello. Le paquet hello qui serait construit à partir de cette nouvelle version ferait alors référence directement à la glibc de cette nouvelle révision de Guix.

Merci pour cet éclaircissement, je vois maintenant la puissance du système !

Dernière question : comment précise-t-on dans le paquet qu'on veut être sur la dernière libc à jour ? J'imagine qu'il y a un système comme avec npm pour Node.js où l'on peut préciser que l'on veut une version fixe exemble (4.7.8) ou alors avoir les derniers correctifs seulement (ex 4.5.x) , ou bien carrément être toujours à la dernière version peu importe le numéro de version ? Ou alors c'est plus complexes que ça ?

Dans ton exemple, si hello se met à jour quand la libc se met à jour, qu'est ce qui me garanti que mon paquet nouvellement compilé va fonctionner ? Bon là c'est la libc dont l'api est pas souvent mis à jour, mais pour une lib plus "mouvante", ça pourrait être problématique non ? Même si le paquet compile, il se peut qu'il soit cassé, non ?

Bon en fait, j'ai encore plein d'autres questions :).

Je trouve Guix vraiment passionnant et j'aimerai creuser un peu plus le concept.

Là je l'ai installé sur ma distrib (Xubuntu 18.04) et par exemple en installant Scribus, il m'a téléchargé des trucs comme Wayland, Mesa, MariaDB ou PostgreSQL, y a-t-il vraiment toutes ces dépendances dans Scribus ?

Scribus installé avec Guix se lancera-t-il avec sa propre version de mesa et de Wayland (même si je suis sous X) ? Bien que je pense que ce soit impossible, ça m'a interloqué :).

Allez, je retourne lire la doc et j'arrête de poser des questions !

Merci pour tout, plus j'en lis dessus plus je me dis que c'est vraiment l'OS du futur !

Andréas

Impossible d'empaqueter des paquets binaires avec guix : tout doit utiliser des recettes

Je me permet de rebondir sur cette affirmation que je ne comprends pas.
Cela signifie-t-il qu'un paquet guix doit forcément être compilé ou empaqueté à partir de source ?

Pourtant, j'ai vu qu'il est possible d'inclure, par exemple, les modules non libres de linux qui contiennent des blobs binaires.

L'auteur de cet article parle aussi d'empaqueter des jeux propriétaires.

Est-ce que j'ai loupé quelque chose ?

Merci,
Andréas

Je continue de me documenter sur Guix.
J'ai trouvé ce merveilleux article qui m'éclaire un peu plus sur l'intérêt de la démarche et compare avec les solutions existantes.
https://ambrevar.xyz/guix-advance/

Néanmoins, il y a des choses que je n'arrive pas à comprendre.

Par exemple, l'auteur dis qu'à partir du moment ou un paquet fonction, il fonctionnera tout le temps.
Mais que se passe-t-il si par exemple, pour un jeu (vu qu'il cite les jeux en exemple), je met à jour mon kernel et mesa et ça casse la compatibilité binaire, voir juste rajoute des problèmes liés aux drivers ?

Mon paquet ne fonctionnera plus non ? Car pour une même machine on continue à n'avoir qu'un seul kernel ?

Le kernel et d'autres paquets comme le serveur d'affichage sont donc des dépendances transverses qui ne peuvent être isolées dans un environnement.

C'est là où j'ai du mal à comprendre.

Aussi, on dit toujours que les système comme snap, flatpak (et guix aussi) sont plus sécurisés car ils exécutent l'application dans un bac à sable dans lequel on choisit ce qu'ils ont droit de faire ou non.

Mais, un des trucs important pour moi dans les systèmes de paquet classiques c'est justement le fait d'avoir des dépendances partagées. De cette manière, s'il y a une faille dans OpenSSL par exemple, bah la correction est faite à un endroit (le paquet lib-openssl par exemple) et tous les paquets qui en dépendent en bénéficient.
Avec ces systèmes qui incluent leur propre dépendance, ce n'est plus possible, non ? Chaque paquet doit donc mettre à jour ses dépendances etc. Sans parler de la place en plus que ça prend sur le disque.

Bref, j'ai encore du mal à comprendre l'intérêt de certaines de ces approches, mais ça m'a tout l'air révolutionnaire sur beaucoup de points.

Merci,
Andréas

Merci pour ces précisions :). J'ai vu dans la dépêche qu'il était question de Nix aussi (que je ne connais pas non plus), tout ça m'a l'air vraiment enthousiasmant !

Comme je le disais, l'admin sys et le devops c'est pas trop mon dada, mais il faut bien reconnaître qu'il n'y a pas eu, à ma connaissance, d'innovation majeure dans le milieu des distributions linux depuis une quinzaine d'années, si ce n'est plus.

Bien sûr, tout l'écosystème a énormément évolué mais les fondements restent les mêmes. Certes, snap, flatpak et autre apporte tout de même des choses intéressantes, mais personnellement, je trouve que c'est plus contraignant qu'autre chose quand on utilise déjà une distribution basée sur un autre type de paquet.

Ca fait 2 (voir 3) méthodes d'installation, de configuration à retenir, un système encore plus hétérogène.

Là, on sent que le truc à vraiment été bien pensé et qu'il y a une grande cohérence entre tous les éléments, c'est ça qui m'attire.

Bref, je vais creuser tout ça, encore merci pour la dépêche.

PS : D'ailleurs, c'est drôle mais j'ai trouvé peu d'articles de vulgarisation qui en parle.

Merci pour ta réponse tout à fait pertinente, ça fait vraiment plaisir ! :)

Je suis tout à fait d'accord avec toi, les différentes solutions doivent être étudiées et, en effet, si l'électronique permet d'éviter des pièces mécaniques ou électromécaniques moins fiable, ça peut être intéressant.

Je suis juste un peu "obsédé" par le caractère non recyclables/non réutilisables de tous ces composants et chercherait donc à en limiter l'usage au strict nécessaire si j'avais à concevoir une machine.

Si le fait de pouvoir mettre à jour sa machine ajoute de la complexité, je ne sais pas si ça vaut le coût. Car, bon je ne sais pas s'il peut y avoir de grandes "percées technologiques" dans nos programmes de machines à lavée ?

Encore merci pour ta réponse,
Andréas

Bravo pour cette dépêche et cet ambitieux projet.

J'avoue ne pas trop être à la pointe de toutes les technos devops et ne pas non plus être super fan d'admin sys (plus de 15 de linux au quotidien donc à force je sais faire quelques trucs mais je suis plus un dev), donc je ne comprend pas tous les tenants et aboutissant de cette dépêche…

Néanmoins, j'ai vraiment l'impression que vous avez construit quelque chose d'unique qui répond à pas mal de problématiques actuelles.

Si je comprends bien, vous avez mis au point une distribution "from scratch" dont le système de paquet est vraiment "révolutionnaire" (dans le sens où il n'a pas d'égal en terme de fonctionnalités), permet notamment d'installer les paquets sans privilèges super utilisateur.

Ce système est aussi configurable via un langage que vous avez inventé et qui j'imagine après retranscrit ça en fichier de conf compatible ngnix, x11, gnome ou je ne sais quoi ? Si c'est le cas, c'est un truc de fou quand même, mais j'ai sans doute mal compris.

Il est aussi très facile de créer des environnement de dev virtuel, donc cool pour le développeur que je suis.

En plus, on peut installer l'environnement de bureau de notre choix, comme toute bonne distribution.

Franchement, vu comme ça (mais je pense que je rate des trucs et en comprends mal d'autres), ça m'a tout l'air d'être LA distribution du future.

En tout cas, tout m'a l'air très bien pensé, structuré, avec une conception globale (voir systémique), ce qui est super rare dans le monde libre (c'est plutôt plein de modules hétérogène qui "communiquent" entre eux tant bien que mal).

Je vais définitivement y regarder de plus près et peut-être l'adoptée si ce n'est pas trop difficile.

Avec hâte d'en apprendre d'avantage,
Andréas

Merci pour votre réponse, je comprends mieux la démarche du framework Atlas.

Quand je parlais de "code serveur" je voulais dire "back-end".

En tout cas, je trouve l'approche SPA bien plus attractive que les CGI en effet et c'est comme ça que j'anime mes cours de javascript.

Je suis d'accord avec vous, c'est un langage difficile d'accès pour les débutants et beaucoup sont perdu avec les différentes syntaxes, les callbacks etc.

Passé cette difficulté, j'ai l'impression d'arriver à faire des choses sympa (un paint, des petits jeux vidéo, un forum websockets etc.) en peu de lignes et cela quasi sans librairie tiers (en js vanilla donc).

S'il y a besoin d'un serveur, je fournis quelque chose de minimaliste afin de leur permettre de se concentrer sur l'interaction utilisateur.

C'est dans cette optique que je questionnais l'intérêt d'Atlas, mais vous avez très bien défendu ce projet et il m'apparaît pertinent dans le cadre d'un apprentissage de la programmation.

Je le vois, ce qui perturbe les apprenants c'est la masse de petites choses différentes à retenir, comprendre etc. et plus l'environnement est hétérogène (c'est le cas pour le web) et plus c'est difficile d'accès.

C'est pour cela aussi que quand je démarre sur Php, je leur fais faire des programme en ligne de commande avant de voir la génération du Html et l’interaction avec une base données SQL. Ce que beaucoup de tuto sur internet font en même temps. Résultat : les apprenants ne font pas la différence entre client et serveur et ont un mal fou à comprendre que le programme Php ne fait que générer du html (ou du json dans le cadre d'API web).

Bref, l'apprentissage de la programmation reste aujourd'hui quelque chose d'assez rude je trouve et j'en vois beaucoup qui décrochent. Sans doute que l’écart entre leur rapport quotidien avec l'informatique (les smartphones, des applis codées par des milliers de dev pendant plusieurs mois) et ce qu'ils arrivent péniblement à faire en cours. Si le toolkit Atlas peut faire la différence alors c'est top !

PS : Je me rappelle avoir codé en quelques heures maxi un jeu vidéo inspiré d'Angribirds en js avec mon fils qui faisait les dessins. Grace aux pages Github et autres services de mise en ligne, on avait quelque chose qu'on pouvait montrer facilement (pas testé sur smartphone mais ça devrait peut tourner) : http://dedesite.github.io/angry_birds_filo/

Est-ce que je suis le seul à penser qu'une machine à laver le linge qui "met à jour son logiciel" c'est pas vraiment durable ?

Pourquoi faire appel à de l’électronique quand on peut l'éviter ?

Pour moi, une machine durable et qui tente d'être plus écologique devrait limiter au maximum l'usage de matériaux rares et être le plus basique possible.

Puis ce qui consomme dans une machine à laver c'est aussi le fait de chauffer l'eau, toutes les machines à laver contiennent une résistance électrique. Le truc vraiment écolo serait de brancher la machine sur le réseau d'eau chaude alimenté par un chauffe eau solaire. Bon, je m'égare… en tout cas, c'est ce que je vais essayer de faire chez moi avec une vielle machine (retaper 3 fois déjà) achetée 40€ sur leboncoin qui ne se met pas à jour :).

Je reste convaincu que des projets comme ceux-ci peuvent être pertinent, juste faire attention où l'on place le curseur "high tech vs low tech".

Bravo pour tout ce travail !

Je m'intéresse aussi à tout ce qui touche la découverte de la programmation. De mon côté, j'ai mis au point un jeu de société (avec des pions en bois et tout) inspiré des blocks de Scratch mais basé sur une approche procédurale et non événementielle comme Scratch.

Concernant Atlas toolkit, je me demande si c'est vraiment plus simple d'accès que de faire une application web "vanilla" sans toolkit ?

Je n'ai pas regardé en détail le code mais il y a tout de même de l'HTML, du css et du code serveur.

Quand vous dites :

"Le développement d’applications mobiles nécessitant de solides connaissances en programmation, il est clair qu’il ne peut être abordé lors de ces ateliers. Et cela vaut aussi pour le développement d’applications Web"

N'est-on pas dans le même cas de figure avec atlas ?

Après, je n'ai peut-être pas compris le réel avantage d'Atlas…

Merci et bonne continuation,
Andréas

… en pensant que j'étais sur le serveur de dev… Heureusement, j'ai pu récupérer des backups !