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…
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***).
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…
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…