C'est pas vraiment une distribution, c'est pour faire des appliances. Le but final étant d'avoir un périphérique embarqué (en readonly c'est encore mieux) gravé dans le marbre ou avec un système de mise à jour A/B pour assurer le fonctionnement à 100%.
S'il y a des gens qui utilisent buildroot en distribution desktop, je pense qu'ils doivent consulter.
Selon moi, cela correspond à une distribution linux : il y a un système de paquets et de dépendances entre eux, l’utilisateur à le choix dans ce qu’il veut installer sur son système.
La spécialisation sur les cartes embarquées ou le fait que le système soit figé après l’installation n’est pas un critère ! (et restreindre les distributions à des services desktop est… restrictif !)
La spécialisation sur les cartes embarquées ou le fait que le système soit figé après l’installation n’est pas un critère ! (et restreindre les distributions à des services desktop est… restrictif !)
J'ai volontairement exagéré la comparaison mais tu avais compris je pense. Utiliser buildroot pour un système de tous les jours (serveur, desktop) c'est vraiment pas une bonne idée. Simplement pour dire que buildroot c'est très bien mais c'est certainement pas fait pour être utilisé comme une distribution Linux au sens que tout le monde l'entend.
Il y a un système de paquets
Il n'y pas de système de paquets. Le système de construction de l'image a des dépendances mais l'image générée est gravée dans le marbre et buildroot déconseille fortement tout utilisation d'un gestionnaire de paquet au sein de l'image générée.
Merci de partager le débat et des précisions ! Je suis d’accord avec toi sur les points que tu relèves, et ça n’est bien sûr pas à mettre sur un bureau.
Oui, il n’y a pas de « gestionnaire » permettant de faire des mises à jour sur le système, mais le terme package est utilisé par le projet pour décrire la liste des éléments que l’on peut installer. Il y a des choix fait par les gestionnaires du projet (inclure telle version du noyau, intégrer ou non telle option dans la configuration), qui me font pencher quand même pour une qualification de distribution. C’est ce que j’ai voulu dire par "système", même si le terme n’est pas bien choisi (mais j’ai pas vraiment mieux…)
En fait, j’aime beaucoup buildroot justement pour ce côté ornithorynque : c’est difficilement classable, et ça oblige à reconsidérer les choses, et c’est super fun de jouer avec.
J’avais découvert de mon côté avec le projet showmewebcam pour transformer un pi0 en caméra usb, et le fait d’avoir un système immuable qui tourne sans s’occuper de sa maintenance est vraiment confortable.
(J’avais eu des déboires à obtenir le wifi sur un pi0-2, il faudra que je reteste si ça c’est amélioré avec cette nouvelle version).
En fait, j’aime beaucoup buildroot justement pour ce côté ornithorynque : c’est difficilement classable, et ça oblige à reconsidérer les choses, et c’est super fun de jouer avec.
Je ne comprends pas. Buildroot n'est pas une distribution, c'est une collection d'outils qui te permet de générer une distribution. Ce n'est pas compliqué à classer, buildroot a le même objectif que Yocto Projet et, avant eux, OpenEmbbedded, Linux Target Image Builder…
Avertissement: Je ne connais pas en pratique Buildroot/Yocto
il y a un système de paquets et de dépendances entre eux
si je comprends bien, il n'y a pas de apt install xyz (ou autre système à la mode "gestionnaire de paquets façon distribution"), mais un gestionnaire de dépendances qui fait que si on veut faire tourner un service quelconque (disons NGinx), les dépendances seront intégrées automagiquement dans le build.
Est ce que c'est ça qui s'en charge ?
j'en profite pour poser une autre question: je vois cross compilation dés le début.
Est ce nécessaire si le résultat de la compilation doit tourner sur la machine qui a fait le build ?
"Si tous les cons volaient, il ferait nuit" F. Dard
mais un gestionnaire de dépendances qui fait que si on veut faire tourner un service quelconque (disons NGinx), les dépendances seront intégrées automagiquement dans le build.
Pour vulgariser en masse, buildroot c'est comme emerge de gentoo mais pour une image finale. Ça compile tous les paquets demandés (après une configuration avec un assistant KConfig comme Linux) et ça génère une image finale sous différent format (un .cpio/.img/.rootfs). Mais forcément, tout ça est fait depuis un système hôte et le résultat est un système le plus léger possible : pas de page de manuel ni .info, pas de .h, pas de NLS et pas non plus de bibliothèque statique. J'ai réalisé des buildroot pour mon travail qui font même pas 30Mo tout compris (musl + sinit) et qui démarrent en moins d'une seconde. C'est tellement amusant d'optimiser le moindre octet et d'avoir le contrôle sur la totalité du système (jusqu'à faire son propre /etc/passwd).
Et comme c'est prévu pour l'embarqué il y a une panoplie de système préconfigurés avec la gestion de leur bootloader les plus funky (que je déteste i.MX et NXP).
Est ce nécessaire si le résultat de la compilation doit tourner sur la machine qui a fait le build ?
On peut utiliser des toolchains complet de l'extérieur d'ailleurs c'est souvent pratique quand on veut recompiler des images sans reconstruire le toolchain (qui n'a pas changé entre temps).
C'est un objectif possible mais ce n'est pas forcément le but à chaque fois. Tu peux très bien faire une image pour ton ordinateur (cible x86-64) et une gestion de mise à jour des paquets avec SWUpdate. Dans ce cas, que l'image fasse quelques Mo de plus ou de moins n'est pas très important.
Son utilisation est hors sujet par rapport à buildroot. On peut utiliser une image buildroot et la graver dans le marbre ou faire des mises à jour sous une autre forme.
Je pense qu'il est tout de même important d'avoir l'image la plus fine possible. Nous avons certains systèmes qui téléchargent les mises à jour en 4G alors si on peut payer le moins possible c'est mieux. Sur certains projets, on avait même une connexion satellitaire et là je t'assure qu'on calcule le moindre octet.
L'utilisation de SwUpdate me parait contradictoire avec ce que tu écrivais dans ce commentaire où tu disais que l'image est gravée dans le marbre. Alors oui, on peut faire un système read-only avec une petite partition de RW pour les logs ou de la config. C'est une utilisation possible. Tu l'écris de façon beaucoup plus explicite dans le commentaire auquel je réponds.
Sur certains projets, on avait même une connexion satellitaire et là je t'assure qu'on calcule le moindre octet.
Oui mais encore fois, c'est une utilisation possible et certainement la plus courante car dans l'embarqué, la mémoire est souvent comptée. Tu as raison mais je voulais ouvrir la vision en insistant sur le fait que ce n'est pas toujours le cas car en lisant ton commentaire, j'avais l'impression que tu excluais les autres cas d'utilisation. J'ai utilisé buildroot pour faire un OS custom sur un PC de bureau. Ce n'est pas l'utilisation la plus fréquente mais dans ce projet, je ne faisais pas beaucoup attention à la taille de l'image.
Oui et c'est bien le cas. L'image ne change pas et c'est pour ça qu'on utilise un système A/B le plus souvent avec swupdate.
La mise à jour consiste à remplacer l'intégralité de l'image générée verbatim sur le deuxième slot et tenter de booter dessus après. Si ça marche pas on reste sur le slot actif.
une configuration avec un assistant KConfig comme Linux
je n'ai pas vu si ce configurateur (on va l'appeler comme ça) permet d'intégrer des applications de plus haut niveau (genre NGinx pour reprendre l'exemple) et gérer toute la chaine des dépendances en conséquence.
A première vue, dans cette optique, Yocto me semble plus appropriée pour cela.
Concernant les toolchains, tout ça, je comprends qu'on en a besoin pour faire de la cross compilation. Mais
Est ce nécessaire si le résultat de la compilation doit tourner sur la machine qui a fait le build ?
J'imagine que non, mais la doc n'est pas très explicite à ce sujet.
Merci de m'éclairer :)
"Si tous les cons volaient, il ferait nuit" F. Dard
# Une distribution linux de niche
Posté par chimrod (site web personnel) . Évalué à 7 (+5/-0).
Ça n’est pas une distribution très populaire, et une dépêche n’est peut être pas nécessaire, mais elle mérite que l’on parle d’elle pour autant !
[^] # Re: Une distribution linux de niche
Posté par David Demelier (site web personnel) . Évalué à 5 (+4/-1).
C'est pas vraiment une distribution, c'est pour faire des appliances. Le but final étant d'avoir un périphérique embarqué (en readonly c'est encore mieux) gravé dans le marbre ou avec un système de mise à jour A/B pour assurer le fonctionnement à 100%.
S'il y a des gens qui utilisent buildroot en distribution desktop, je pense qu'ils doivent consulter.
Vive buildroot (buildroot > yocto).
AI is a mental disorder
[^] # Re: Une distribution linux de niche
Posté par chimrod (site web personnel) . Évalué à 5 (+3/-0).
Selon moi, cela correspond à une distribution linux : il y a un système de paquets et de dépendances entre eux, l’utilisateur à le choix dans ce qu’il veut installer sur son système.
La spécialisation sur les cartes embarquées ou le fait que le système soit figé après l’installation n’est pas un critère ! (et restreindre les distributions à des services desktop est… restrictif !)
[^] # Re: Une distribution linux de niche
Posté par David Demelier (site web personnel) . Évalué à 5 (+3/-0). Dernière modification le 05 mars 2026 à 15:51.
J'ai volontairement exagéré la comparaison mais tu avais compris je pense. Utiliser buildroot pour un système de tous les jours (serveur, desktop) c'est vraiment pas une bonne idée. Simplement pour dire que buildroot c'est très bien mais c'est certainement pas fait pour être utilisé comme une distribution Linux au sens que tout le monde l'entend.
Il n'y pas de système de paquets. Le système de construction de l'image a des dépendances mais l'image générée est gravée dans le marbre et buildroot déconseille fortement tout utilisation d'un gestionnaire de paquet au sein de l'image générée.
D'ailleurs les mots même de buildroot :
“Buildroot is not meant to be a distribution”
AI is a mental disorder
[^] # Re: Une distribution linux de niche
Posté par chimrod (site web personnel) . Évalué à 4 (+2/-0).
Merci de partager le débat et des précisions ! Je suis d’accord avec toi sur les points que tu relèves, et ça n’est bien sûr pas à mettre sur un bureau.
Oui, il n’y a pas de « gestionnaire » permettant de faire des mises à jour sur le système, mais le terme package est utilisé par le projet pour décrire la liste des éléments que l’on peut installer. Il y a des choix fait par les gestionnaires du projet (inclure telle version du noyau, intégrer ou non telle option dans la configuration), qui me font pencher quand même pour une qualification de distribution. C’est ce que j’ai voulu dire par "système", même si le terme n’est pas bien choisi (mais j’ai pas vraiment mieux…)
En fait, j’aime beaucoup buildroot justement pour ce côté ornithorynque : c’est difficilement classable, et ça oblige à reconsidérer les choses, et c’est super fun de jouer avec.
J’avais découvert de mon côté avec le projet showmewebcam pour transformer un pi0 en caméra usb, et le fait d’avoir un système immuable qui tourne sans s’occuper de sa maintenance est vraiment confortable.
(J’avais eu des déboires à obtenir le wifi sur un pi0-2, il faudra que je reteste si ça c’est amélioré avec cette nouvelle version).
[^] # Re: Une distribution linux de niche
Posté par nico4nicolas . Évalué à 3 (+1/-0).
Je ne comprends pas. Buildroot n'est pas une distribution, c'est une collection d'outils qui te permet de générer une distribution. Ce n'est pas compliqué à classer, buildroot a le même objectif que Yocto Projet et, avant eux, OpenEmbbedded, Linux Target Image Builder…
[^] # Re: Une distribution linux de niche
Posté par Luc-Skywalker . Évalué à 3 (+1/-0).
Avertissement: Je ne connais pas en pratique Buildroot/Yocto
si je comprends bien, il n'y a pas de apt install xyz (ou autre système à la mode "gestionnaire de paquets façon distribution"), mais un gestionnaire de dépendances qui fait que si on veut faire tourner un service quelconque (disons NGinx), les dépendances seront intégrées automagiquement dans le build.
Est ce que c'est ça qui s'en charge ?
j'en profite pour poser une autre question: je vois cross compilation dés le début.
Est ce nécessaire si le résultat de la compilation doit tourner sur la machine qui a fait le build ?
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: Une distribution linux de niche
Posté par David Demelier (site web personnel) . Évalué à 5 (+3/-0).
Pour vulgariser en masse, buildroot c'est comme emerge de gentoo mais pour une image finale. Ça compile tous les paquets demandés (après une configuration avec un assistant KConfig comme Linux) et ça génère une image finale sous différent format (un .cpio/.img/.rootfs). Mais forcément, tout ça est fait depuis un système hôte et le résultat est un système le plus léger possible : pas de page de manuel ni .info, pas de .h, pas de NLS et pas non plus de bibliothèque statique. J'ai réalisé des buildroot pour mon travail qui font même pas 30Mo tout compris (musl + sinit) et qui démarrent en moins d'une seconde. C'est tellement amusant d'optimiser le moindre octet et d'avoir le contrôle sur la totalité du système (jusqu'à faire son propre /etc/passwd).
Et comme c'est prévu pour l'embarqué il y a une panoplie de système préconfigurés avec la gestion de leur bootloader les plus funky (que je déteste i.MX et NXP).
On peut utiliser des toolchains complet de l'extérieur d'ailleurs c'est souvent pratique quand on veut recompiler des images sans reconstruire le toolchain (qui n'a pas changé entre temps).
AI is a mental disorder
[^] # Re: Une distribution linux de niche
Posté par nico4nicolas . Évalué à 2 (+0/-0).
C'est un objectif possible mais ce n'est pas forcément le but à chaque fois. Tu peux très bien faire une image pour ton ordinateur (cible x86-64) et une gestion de mise à jour des paquets avec SWUpdate. Dans ce cas, que l'image fasse quelques Mo de plus ou de moins n'est pas très important.
[^] # Re: Une distribution linux de niche
Posté par David Demelier (site web personnel) . Évalué à 3 (+1/-0).
On utilise swupdate (dans notre cas).
Son utilisation est hors sujet par rapport à buildroot. On peut utiliser une image buildroot et la graver dans le marbre ou faire des mises à jour sous une autre forme.
Je pense qu'il est tout de même important d'avoir l'image la plus fine possible. Nous avons certains systèmes qui téléchargent les mises à jour en 4G alors si on peut payer le moins possible c'est mieux. Sur certains projets, on avait même une connexion satellitaire et là je t'assure qu'on calcule le moindre octet.
AI is a mental disorder
[^] # Re: Une distribution linux de niche
Posté par nico4nicolas . Évalué à 2 (+0/-0).
L'utilisation de SwUpdate me parait contradictoire avec ce que tu écrivais dans ce commentaire où tu disais que l'image est gravée dans le marbre. Alors oui, on peut faire un système read-only avec une petite partition de RW pour les logs ou de la config. C'est une utilisation possible. Tu l'écris de façon beaucoup plus explicite dans le commentaire auquel je réponds.
Oui mais encore fois, c'est une utilisation possible et certainement la plus courante car dans l'embarqué, la mémoire est souvent comptée. Tu as raison mais je voulais ouvrir la vision en insistant sur le fait que ce n'est pas toujours le cas car en lisant ton commentaire, j'avais l'impression que tu excluais les autres cas d'utilisation. J'ai utilisé buildroot pour faire un OS custom sur un PC de bureau. Ce n'est pas l'utilisation la plus fréquente mais dans ce projet, je ne faisais pas beaucoup attention à la taille de l'image.
[^] # Re: Une distribution linux de niche
Posté par David Demelier (site web personnel) . Évalué à 3 (+1/-0).
Oui et c'est bien le cas. L'image ne change pas et c'est pour ça qu'on utilise un système A/B le plus souvent avec swupdate.
La mise à jour consiste à remplacer l'intégralité de l'image générée verbatim sur le deuxième slot et tenter de booter dessus après. Si ça marche pas on reste sur le slot actif.
AI is a mental disorder
[^] # Re: Une distribution linux de niche
Posté par Luc-Skywalker . Évalué à 2 (+0/-0).
Ok, merci.
je n'ai pas vu si ce configurateur (on va l'appeler comme ça) permet d'intégrer des applications de plus haut niveau (genre NGinx pour reprendre l'exemple) et gérer toute la chaine des dépendances en conséquence.
A première vue, dans cette optique, Yocto me semble plus appropriée pour cela.
Concernant les toolchains, tout ça, je comprends qu'on en a besoin pour faire de la cross compilation. Mais
J'imagine que non, mais la doc n'est pas très explicite à ce sujet.
Merci de m'éclairer :)
"Si tous les cons volaient, il ferait nuit" F. Dard
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.