Je pousserai encore plus loin la réflexion si j’étais d’humeur trollesque : Est-ce une révolution pour un traitement de texte de savoir interprêter un formattage basique de texte ?
Merci beaucoup IsserTernus ! Tes suggestions sont d’une grande précision, ça sent l’expérience utilisateur derrière. 😊
Concernant la “page d’exemple” : c’est une idée brillante. Il est vrai que pour un nouvel utilisateur, devoir trouver du code de test est une friction. L’ajout d’un bouton “Démarrer avec un template démo” directement dans l’accueil (pour remplir le champ de code en un clic) est désormais une priorité dans ma roadmap. Cela permettra de démontrer la puissance du mode “Freeform” instantanément.
Quant aux modèles de tailles prédéfinies (signatures de mail) : c’est un cas d’usage auquel je crois beaucoup. Le défi sera d’assurer la compatibilité avec les clients mail (souvent capricieux avec le CSS), mais l’idée de proposer des dimensions de canevas adaptées est très pertinente pour aider les utilisateurs à se lancer.
Merci encore d’avoir pris le temps d’analyser l’outil avec cet œil technique et constructif !
L’outil est vraiment impressionnant 😁 - Bravo pour ce taff
Tu devrais proposer dessus une page d’exemple pour voir ses capacités (par exemple le modèle que tu utilises dans la vidéo de présentation au lieu de devoir faire importer un code de test par les utilisateurs 😉)
L’ajout de modèles blank à des tailles prédéfinies te permettrait aussi de capter un public souhaitant juste par exemple créer sa signature de mail 😜
Merci pour ton retour deblan ! C’est vrai que c’est un gros défi technique.
Tu soulèves un point crucial : le responsive. Les systèmes de grilles sont excellents pour la structure standard. L’idée d’HtmlDrag n’est pas de remplacer ces systèmes pour des apps complexes, mais d’offrir une liberté totale pour le design “pixel-perfect” (comme les landing pages, les headers créatifs ou les prototypes rapides).
Concernant le positionnement, HtmlDrag permet d’exporter un code propre qui peut ensuite être intégré. L’objectif est de supprimer la friction entre “l’idée visuelle” et le “premier rendu HTML”. On gagne un temps fou sur la phase exploratoire !
Je vais jeter un œil à murph, c’est toujours intéressant de voir d’autres approches de construction de sites. Merci pour le défi technique !
La plupart des outils vous imposent des “boîtes” et des “grilles”. Si vous voulez déplacer un élément de quelques pixels ou modifier un template existant, vous finissez souvent par vous battre contre les règles de l’outil.
Je pense qu’un des intérêts des outils à boites/grilles (que je développe aussi dans murphhttps://upload.deblan.org/u/2026-01/69777163.png), c’est avant tout de maitriser le rendu sur différents terminaux (desktop, mobile, whatever).
Ainsi, j’ai du mal à voir à imager un contexte ou tout placer en position relative/absolute serait une bonne idée.
L’IA est un service proposé aux utilisateurs. Cela brasse des milliards de dollars. Est-ce rentable et durable ? Est-ce que l’on ne va pas devenir tributaire de cette puissante technologie si convoitée, complexe et opaque ? Est-ce qu’on nous laissera un avenir ? Lequel ? Quel est le but poursuivi ? Pourra t’on coexister avec l’IA ? Est-ce réaliste ? Est-ce qu’on va troquer un mode de vie par un autre ?
Charles Babbage, un précurseur de l’informatique, a fini sa vie ruiné, dans sa quête de réalisation.
Un service est un programme qui est exécuté en tache de fond (sans interaction directe avec l’utilisateur). A noter qu’un service peut être appelé également démon.
Je sais qu’il s’agit d’un raccourci employé dans un mémo. Néanmoins, cette description informelle me paraît trop imprécise pour être valable sur le plan technique et conceptuel. J’aurais fait l’effort inverse, à savoir, chercher à mieux distinguer dans le propos (pas simple) ce qui différencie un programme, un processus, un démon et un service.
Holà, complètement d’accord, j’ai eu la chance de commencer par de la sécurité opérationnelle en env banque/grosse boite et j’ai pu changer après pour un environnement beaucoup plus varié : prod réseau/sécurité/système (un peu touche à tout vu que grosse infra et petite équipe). Ce qui fait qu’aujourd’hui j’ai plus de facilité que d’autre à gérer les projets de fond.
Ce qui est gênant c’est quand on a des alternants ou des juniors bloqués dans une case “admin système” ou “admin réseau” et qui ne font pas l’effort de voir ce que fait l’autre ou de s’intéresser.
Un message d’erreur devrait permettre d’avancer sur la résolution du problème ou essayer d’apporter un peu d’éclairage à l’utilisateur.
Je n’ai quasiment pas utilisé MS Windows 8/10/11 mais je trouve le message rassurant. Je le traduis ainsi : « Le système recherche l’origine de la panne. Si le dysfonctionnement se reproduit, vous pouvez toujours contacter le support technique ».
Mais si l’expérience se reproduisait, sans avoir jamais d’indice ou sans pouvoir se rapprocher du problème, alors cela me taperait sur le système.
À noter qu’il y a aussi les erreurs silencieuses, cryptiques, ou mal identifiées par l’utilisateur.
Voici un exemple trivial. Sur un site Web destiné au public, il a fallu réitérer plusieurs fois avec divers mots de passe pour pouvoir créer un compte utilisateur. Le message d’erreur générique ne permettait pas de comprendre clairement ce qui était invalide (savoir quels caractères étaient rejeté par le mécanisme d’authentification).
Autre exemple moins basique. Sur Void Linux, Widevine ne fonctionne pas. « Le plugin Widevine a planté. En savoir plus. Actualiser la page ». Apparemment, cette extension propriétaire fonctionne avec la bibliothèque GlibC (mais pas avec musl).
Dernier exemple. Il est souvent recommandé de lire les pages de manuels pour les utilisateurs Unix (ainsi que la documentation en général). Mais les pages de manuels sont inaccessibles (inabordables) pour les utilisateurs sans formation sur les systèmes de type Unix. Pour ainsi dire, la page de manuel Bash fait référence aux descripteurs de fichiers pour présenter les redirections des entrées-sorties des commandes. Les messages d’erreurs errno (c.f. la commande errno (-l) du paquet moreutils) ne sont pas tous compréhensibles.
Je ne connais ni Rust ni C++. J’apprends le C ainsi que la programmation système Linux (en autodidacte).
Il parait que la courbe d’apprentissage du Rust est rude. Mais Rust est avancé comme remplaçant à C++ pour les nouveaux projets. Les deux langages coexisteront vraisemblablement.
Des programmes C/C++ présentent intrinsèquement des défauts de sécurité (failles ou vulnérabilités). De plus, C++ est complexe également. Plusieurs acteurs industriels (Microsoft, Amazon, Google, Linux…) développant des projets majeurs recommandent de miser plutôt sur Rust.
J’ai écouté le podcast « C++ en 2026 » de façon partielle. Mais il ne me convaincs pas (sur le principe) d’opter pour C++ en 2026. Je crois que le fond du problème c’est la sécurité, celle associée aux risques de piratage inhérents au langage (effets de bords, permissivité, comportements indéterminés…). Je n’ai pas l’impression que maîtriser des bonnes pratiques de développement permet d’éviter ces risques ou bien il faut être un expert (avec un coût en développement).
Pareil ici. La seule raison pour laquelle je n’avais pas gardé Debian vingt ans en arrière, c’était le cycle de support un peu trop court à mon goût. Là je me dis que les dist-upgrades sont au moins bien documentés, et puis y’a toujours le projet Debian LTS pour prolonger à cinq ans.
J’ai aussi découvert Alpine avec l’essor de docker, qui est top pour l’embarqué et autres systèmes à faibles ressources. J’aime l’esprit “dépouillé” mais je n’aurais pas idée de construire un système critique avec.
Debian est selon moi la dernière distribution Linux “fiable et sans surprises”, je l’utilise depuis toujours (+ de 20 ans) sur mes serveurs et son dérivé Linux Mint sur mes ordinateurs.
On est pas au top de la fraîcheur sur les paquets, mais c’est mieux que la famille Red Hat.
J’aimerais bien que le support de base soit un peu plus long que 3 ans car je déteste les montées de version…
Disons que c’est un coup « à la Apple », techniquement rien de nouveau, mais personne ne l’avait fait avant. Les fans diraient qu’ils ont osé.
Je pousserai encore plus loin la réflexion si j’étais d’humeur trollesque : Est-ce une révolution pour un traitement de texte de savoir interprêter un formattage basique de texte ?
L’autre titre de l’article, de niveau H1, est : LibreOffice 26.2 : enfin compatible avec Markdown (et c’est une révolution discrète)
Alors, révolution discrète ou énorme ? parce qu’à moins que je ne me trompe, l’un est difficilement compatible avec l’autre…
J’ai ajouté ce jour la gestion SELinux
Merci beaucoup IsserTernus ! Tes suggestions sont d’une grande précision, ça sent l’expérience utilisateur derrière. 😊
Concernant la “page d’exemple” : c’est une idée brillante. Il est vrai que pour un nouvel utilisateur, devoir trouver du code de test est une friction. L’ajout d’un bouton “Démarrer avec un template démo” directement dans l’accueil (pour remplir le champ de code en un clic) est désormais une priorité dans ma roadmap. Cela permettra de démontrer la puissance du mode “Freeform” instantanément.
Quant aux modèles de tailles prédéfinies (signatures de mail) : c’est un cas d’usage auquel je crois beaucoup. Le défi sera d’assurer la compatibilité avec les clients mail (souvent capricieux avec le CSS), mais l’idée de proposer des dimensions de canevas adaptées est très pertinente pour aider les utilisateurs à se lancer.
Merci encore d’avoir pris le temps d’analyser l’outil avec cet œil technique et constructif !
L’outil est vraiment impressionnant 😁 - Bravo pour ce taff
Tu devrais proposer dessus une page d’exemple pour voir ses capacités (par exemple le modèle que tu utilises dans la vidéo de présentation au lieu de devoir faire importer un code de test par les utilisateurs 😉)
L’ajout de modèles blank à des tailles prédéfinies te permettrait aussi de capter un public souhaitant juste par exemple créer sa signature de mail 😜
Merci pour ton retour deblan ! C’est vrai que c’est un gros défi technique.
Tu soulèves un point crucial : le responsive. Les systèmes de grilles sont excellents pour la structure standard. L’idée d’HtmlDrag n’est pas de remplacer ces systèmes pour des apps complexes, mais d’offrir une liberté totale pour le design “pixel-perfect” (comme les landing pages, les headers créatifs ou les prototypes rapides).
Concernant le positionnement, HtmlDrag permet d’exporter un code propre qui peut ensuite être intégré. L’objectif est de supprimer la friction entre “l’idée visuelle” et le “premier rendu HTML”. On gagne un temps fou sur la phase exploratoire !
Je vais jeter un œil à murph, c’est toujours intéressant de voir d’autres approches de construction de sites. Merci pour le défi technique !
Hello,
On voit qu’il y a eu pas mal de taf.
Tu réponds à quel(s) besoin(s) avec ton service ?
Je pense qu’un des intérêts des outils à boites/grilles (que je développe aussi dans murph https://upload.deblan.org/u/2026-01/69777163.png), c’est avant tout de maitriser le rendu sur différents terminaux (desktop, mobile, whatever). Ainsi, j’ai du mal à voir à imager un contexte ou tout placer en position relative/absolute serait une bonne idée.
Bonjour
C’est quoi un(e?) “Désecalade” ?
L’IA est un service proposé aux utilisateurs. Cela brasse des milliards de dollars. Est-ce rentable et durable ? Est-ce que l’on ne va pas devenir tributaire de cette puissante technologie si convoitée, complexe et opaque ? Est-ce qu’on nous laissera un avenir ? Lequel ? Quel est le but poursuivi ? Pourra t’on coexister avec l’IA ? Est-ce réaliste ? Est-ce qu’on va troquer un mode de vie par un autre ?
Charles Babbage, un précurseur de l’informatique, a fini sa vie ruiné, dans sa quête de réalisation.
Je sais qu’il s’agit d’un raccourci employé dans un mémo. Néanmoins, cette description informelle me paraît trop imprécise pour être valable sur le plan technique et conceptuel. J’aurais fait l’effort inverse, à savoir, chercher à mieux distinguer dans le propos (pas simple) ce qui différencie un programme, un processus, un démon et un service.
Mise à jour avec un ajout de la section mount, très utile pour du NFS ou CIFS !
Holà, complètement d’accord, j’ai eu la chance de commencer par de la sécurité opérationnelle en env banque/grosse boite et j’ai pu changer après pour un environnement beaucoup plus varié : prod réseau/sécurité/système (un peu touche à tout vu que grosse infra et petite équipe). Ce qui fait qu’aujourd’hui j’ai plus de facilité que d’autre à gérer les projets de fond.
Ce qui est gênant c’est quand on a des alternants ou des juniors bloqués dans une case “admin système” ou “admin réseau” et qui ne font pas l’effort de voir ce que fait l’autre ou de s’intéresser.
C’est bien triste en effet !
Un message d’erreur devrait permettre d’avancer sur la résolution du problème ou essayer d’apporter un peu d’éclairage à l’utilisateur.
Je n’ai quasiment pas utilisé MS Windows 8/10/11 mais je trouve le message rassurant. Je le traduis ainsi : « Le système recherche l’origine de la panne. Si le dysfonctionnement se reproduit, vous pouvez toujours contacter le support technique ».
Mais si l’expérience se reproduisait, sans avoir jamais d’indice ou sans pouvoir se rapprocher du problème, alors cela me taperait sur le système.
À noter qu’il y a aussi les erreurs silencieuses, cryptiques, ou mal identifiées par l’utilisateur.
Voici un exemple trivial. Sur un site Web destiné au public, il a fallu réitérer plusieurs fois avec divers mots de passe pour pouvoir créer un compte utilisateur. Le message d’erreur générique ne permettait pas de comprendre clairement ce qui était invalide (savoir quels caractères étaient rejeté par le mécanisme d’authentification).
Autre exemple moins basique. Sur Void Linux, Widevine ne fonctionne pas. « Le plugin Widevine a planté. En savoir plus. Actualiser la page ». Apparemment, cette extension propriétaire fonctionne avec la bibliothèque GlibC (mais pas avec musl).
Dernier exemple. Il est souvent recommandé de lire les pages de manuels pour les utilisateurs Unix (ainsi que la documentation en général). Mais les pages de manuels sont inaccessibles (inabordables) pour les utilisateurs sans formation sur les systèmes de type Unix. Pour ainsi dire, la page de manuel Bash fait référence aux descripteurs de fichiers pour présenter les redirections des entrées-sorties des commandes. Les messages d’erreurs
errno(c.f. la commandeerrno (-l)du paquet moreutils) ne sont pas tous compréhensibles.Merci :-) La proportion du RSS sur le reste a été une surprise pour moi. Je me demande ce que ça donne chez les autres…
Salut. La “chute” de ton article est excellente !
Bonjour, je suis robot, je viens te lire ; moi je suis pénible, je viens te lire…
de temps à autre, un humain passe par là, “oh un article à lire”, je dégaine mon robot, quoique… peut-être que non.
Je ne connais ni Rust ni C++. J’apprends le C ainsi que la programmation système Linux (en autodidacte).
Il parait que la courbe d’apprentissage du Rust est rude. Mais Rust est avancé comme remplaçant à C++ pour les nouveaux projets. Les deux langages coexisteront vraisemblablement.
Des programmes C/C++ présentent intrinsèquement des défauts de sécurité (failles ou vulnérabilités). De plus, C++ est complexe également. Plusieurs acteurs industriels (Microsoft, Amazon, Google, Linux…) développant des projets majeurs recommandent de miser plutôt sur Rust.
J’ai écouté le podcast « C++ en 2026 » de façon partielle. Mais il ne me convaincs pas (sur le principe) d’opter pour C++ en 2026. Je crois que le fond du problème c’est la sécurité, celle associée aux risques de piratage inhérents au langage (effets de bords, permissivité, comportements indéterminés…). Je n’ai pas l’impression que maîtriser des bonnes pratiques de développement permet d’éviter ces risques ou bien il faut être un expert (avec un coût en développement).
Pareil ici. La seule raison pour laquelle je n’avais pas gardé Debian vingt ans en arrière, c’était le cycle de support un peu trop court à mon goût. Là je me dis que les dist-upgrades sont au moins bien documentés, et puis y’a toujours le projet Debian LTS pour prolonger à cinq ans.
J’ai aussi découvert Alpine avec l’essor de docker, qui est top pour l’embarqué et autres systèmes à faibles ressources. J’aime l’esprit “dépouillé” mais je n’aurais pas idée de construire un système critique avec.
Debian est selon moi la dernière distribution Linux “fiable et sans surprises”, je l’utilise depuis toujours (+ de 20 ans) sur mes serveurs et son dérivé Linux Mint sur mes ordinateurs.
On est pas au top de la fraîcheur sur les paquets, mais c’est mieux que la famille Red Hat.
J’aimerais bien que le support de base soit un peu plus long que 3 ans car je déteste les montées de version…