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…
Le financement compliqué des projets open-source a toujours existé, ça fait presque partie du contrat social.
Par contre, je n’ai pas vu dans l’article une quelconque remise en question du modèle technique de Tailwind, qui s’assied allègrement sur toutes les conventions et bonnes pratiques de développement.
Le coup des composants, si c’est pour une entreprise, c’est l’entreprise qui paye. Un dev solo ne va pas lâcher 299 dollars pour quelques composants qui vont lui faire gagner 15 minutes de CSS s’il sait faire du CSS.
Tailwind va mal parce qu’ils ont vendu du rêve, et on commence à réaliser que ce rêve n’était pas si bien que ça. Pas la peine de sortir les violons “L’IA m’a tuer”.
Notez que je ne critique pas l’article en lui-même qui est bien fait, factuel et tout. Je dis juste que des gars qui font des projets open-source à succès, il y en a à la pelle sur le web, et quand ça ne va plus, c’est pas forcément à cause de l’IA.
Je rajoute encore que l’absence de relais de la licence, ce n’est pas que le problème de l’IA. l’IA ne va pas spontanément produire du code “tailwind” parce que l’utilisateur demande du CSS. L’utilisateur demande activement du Tailwind. Pour moi, c’est au développeur d’indiquer la licence des outils qu’il utilise. Donc s’il demande du code Tailwind, le dev doit se prendre par la main et apposer la licence qui va bien.
Google Antigravity est l’IDE agent-first qui automatise les tâches de développement complexes. J’ai testé pendant 3 semaines. Verdict : c’est le meilleur outil IA de développement en 2025, et voici pourquoi
Alpine Linux est connu pour être minimaliste et aussi un peu controversé (notamment dans le monde Docker) pour le remplacement de la glibc par musl (ce qui provoque parfois des surprises).
C’est une bibliothèque reconnue, surtout dans les systèmes embarqués, à l’inverse de GlibC qui est considérée trop lourde (complexe). Il y a même une intégration expérimentale dans systemd.
J’avais une préférence pour musl en terme d’apprentissage. Mais il faut connaître le langage C et avoir des connaissances en développement système Linux pour rectifier les erreurs (comprendre ce qu’affiche le compilateur, faire des recherches, lire les sources, apporter des modifications).
Hier, je compilais OpenWrt sur une Void Linux (merci à @kikinovak). J’ai eu ce problème. J’aurais pu étudier les sources mais j’ai recherché le correctif. J’ai également eu un autre problème « bad for loop variable » (le shell POSIX de Void n’interprète pas les boucles for de type C). Ce sont des problèmes mineurs mais qui peuvent potentiellement ralentir lorsqu’on a une tâche à réaliser : une méconnaissance de l’environnement peut amener à un blocage.
Je ne connais pas encore les conteneurs ni la virtualisation.
J’ai souris à l’allusion concernant le gestionnaire de paquet (j’ai le même ressenti concernant la gestion des paquets) ‘uv’ ; avoue qu’utiliser un binaire écrit dans un autre langage pour cette tâche est digne de l’humour IT !
Sinon, en conclusion, presque si “cracher du sang” au final ne te déplairait pas tant que cela ;)
(la tournure linguistique utilisé, pour “l’esprit pervers” que je suis, pourrais laisser à entendre que tu t’attendais à ce fait et que t’a aimé en ch***).
Concernant la commande apt autoremove --purge, c bien en soit ; maintenant comme le référence le manpage d’apt-get, la commande suivante est intéressante apt autopurge.
De même, il serait plus adéquate que l’étape 7 soit de type 6.1, car elle n’est nécessaire QUE si l’étape 6 est accomplie car cette étape est appelée automatiquement si des noyaux sont supprimés lors de l’étape 5. Dans l’état actuel du tuto, cela laisse à penser que c’est nécessaire comme étape alors qu’en soit, normalement, non.
J’utilise KDE depuis la version 2.4 sous Slackware 7.1 vingt-cinq ans en arrière. J’ai testé Cosmic, et effectivement c’est le bureau du futur. Je l’utiliserai donc dans le futur. :o)
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…
La réponse est pourtant bien simple, cela ne demande pas de matériel supplémentaire par rapport à ce que j’avais.
Le financement compliqué des projets open-source a toujours existé, ça fait presque partie du contrat social.
Par contre, je n’ai pas vu dans l’article une quelconque remise en question du modèle technique de Tailwind, qui s’assied allègrement sur toutes les conventions et bonnes pratiques de développement.
Le coup des composants, si c’est pour une entreprise, c’est l’entreprise qui paye. Un dev solo ne va pas lâcher 299 dollars pour quelques composants qui vont lui faire gagner 15 minutes de CSS s’il sait faire du CSS.
Tailwind va mal parce qu’ils ont vendu du rêve, et on commence à réaliser que ce rêve n’était pas si bien que ça. Pas la peine de sortir les violons “L’IA m’a tuer”.
J’en parlais déjà dans un rant datant de 2022.
Notez que je ne critique pas l’article en lui-même qui est bien fait, factuel et tout. Je dis juste que des gars qui font des projets open-source à succès, il y en a à la pelle sur le web, et quand ça ne va plus, c’est pas forcément à cause de l’IA.
Je rajoute encore que l’absence de relais de la licence, ce n’est pas que le problème de l’IA. l’IA ne va pas spontanément produire du code “tailwind” parce que l’utilisateur demande du CSS. L’utilisateur demande activement du Tailwind. Pour moi, c’est au développeur d’indiquer la licence des outils qu’il utilise. Donc s’il demande du code Tailwind, le dev doit se prendre par la main et apposer la licence qui va bien.
On verra comment l’outil se démocratise et si on a des demandes.
Tcho !
Intéressant. Je ne sais pas s’il faut l’ajouter à la discussion sur le relifting de l’architecture du jdh ? cc @cascador
Google Antigravity est l’IDE agent-first qui automatise les tâches de développement complexes. J’ai testé pendant 3 semaines. Verdict : c’est le meilleur outil IA de développement en 2025, et voici pourquoi
ici un article 100% factuel, basé sur les données réelles du marché tech algérien
Merci pour le retour. Ravi que la solution et l’explication aient été utiles.
Merci pour le partage, l’article est vraiment clair. Belle solution :)
C’est une bibliothèque reconnue, surtout dans les systèmes embarqués, à l’inverse de GlibC qui est considérée trop lourde (complexe). Il y a même une intégration expérimentale dans systemd.
J’avais une préférence pour musl en terme d’apprentissage. Mais il faut connaître le langage C et avoir des connaissances en développement système Linux pour rectifier les erreurs (comprendre ce qu’affiche le compilateur, faire des recherches, lire les sources, apporter des modifications).
Hier, je compilais OpenWrt sur une Void Linux (merci à @kikinovak). J’ai eu ce problème. J’aurais pu étudier les sources mais j’ai recherché le correctif. J’ai également eu un autre problème « bad for loop variable » (le shell POSIX de Void n’interprète pas les boucles for de type C). Ce sont des problèmes mineurs mais qui peuvent potentiellement ralentir lorsqu’on a une tâche à réaliser : une méconnaissance de l’environnement peut amener à un blocage.
Je ne connais pas encore les conteneurs ni la virtualisation.
Salut.
Merci pour l’article.
J’ai souris à l’allusion concernant le gestionnaire de paquet (j’ai le même ressenti concernant la gestion des paquets) ‘uv’ ; avoue qu’utiliser un binaire écrit dans un autre langage pour cette tâche est digne de l’humour IT !
Sinon, en conclusion, presque si “cracher du sang” au final ne te déplairait pas tant que cela ;) (la tournure linguistique utilisé, pour “l’esprit pervers” que je suis, pourrais laisser à entendre que tu t’attendais à ce fait et que t’a aimé en ch***).
Bon, beh, j’y-go…
Google frappe fort avec Nano Banana Pro. Alors j’avais envie de tester et avoir mon propre avis. et c’est la que j’ai découvert une mine d’or.
Bjr,
Concernant la commande
apt autoremove --purge, c bien en soit ; maintenant comme le référence le manpage d’apt-get, la commande suivante est intéressanteapt autopurge.Cf: https://manpages.debian.org/unstable/apt/apt-get.8.en.html ;)
De même, il serait plus adéquate que l’étape 7 soit de type 6.1, car elle n’est nécessaire QUE si l’étape 6 est accomplie car cette étape est appelée automatiquement si des noyaux sont supprimés lors de l’étape 5. Dans l’état actuel du tuto, cela laisse à penser que c’est nécessaire comme étape alors qu’en soit, normalement, non.
J’utilise KDE depuis la version 2.4 sous Slackware 7.1 vingt-cinq ans en arrière. J’ai testé Cosmic, et effectivement c’est le bureau du futur. Je l’utiliserai donc dans le futur. :o)
Merci, content que ça t’ait plu ☺️