Petite précision supplémentaire par rapport au commentaire d'Alexandre : dans ma réponse précédente, il faut entendre distribution Poky comme l'ensemble des recettes disponibles à travers les recettes fournies.
Si par contre on prend poky comme les réglages de type distro (fichier conf/distro/poky.conf), alors Alexandre a raison : pour quelqu'un de suffisamment expérimenté, il peut être intéressant de créer sa propre distribution afin d'affiner/modifier les réglages spécifiés par le fichier poky.conf, et éventuellement de modifier les DISTRO_FEATURES pour adapter le contenu de l'image de base à ses pré-requis.
Par contre à ce niveau là on est dans de l'utilisation avancée, et de l'optimisation fine de l'image finale.
Globalement d'accord avec le fait que ce n'est pas simple (sinon proposer un atelier n'aurait pas de sens …).
Néanmoins est ce le fait de l'outil, ou bien est ce intrinsèque? J'ai l'habitude de dire aux gens que je forme que ce n'est pas parce qu'ils commencent à maîtriser l'outil que tout est gagné. En effet encore faut il savoir comment bâtir une distribution embarquée, et même comment arriver à un objectif fonctionnel à base de composants Linux.
Ceci se retrouve amplifié dans le cas assez fréquent d'un développement croisé, du fait de la dualité PC de développement / cible.
En l'absence des outils proposés par Yocto Project, on peut s'appuyer sur buildroot qui rendra un service similaire mais en étant plus léger (et donc moins ambitieux, il n'y a pas de miracle), ou bien travailler à la main (en mode Do It Yourself).
Pour avoir bâti pendant de nombreuses années des distributions Linux embarquées, il est clair que le mode Do It Yourself trouve vite ses limites dès lors que l'on veut ajouter du contenu logiciel riche dans la distribution, ce qui est de plus en plus fréquent.
Tout à fait d'accord sur les précisions de terminologie. D'ailleurs dans l'atelier j'indique que le terme consacré est Yocto Project, et que c'est par commodité (voire par abus) qu'on le raccourcit en Yocto.
Effectivement Yocto est le projet, qui offre des outils divers, mais également un très gros effort de documentation. Par contre dans les échanges force est de constater que c'est Yocto qui est utilisé et non Poky. Mes clients viennent me voir pour du support Yocto, et non du support Poky. Du coup c'est rapidement que le vocable impropre se banalise.
Concernant le fait de savoir si Poky est utilisé pour des tests ou un projet final, je pense que la distinction est plus fine. Ce qui fait le contenu logiciel du projet final, c'est la recette image qui est buildée puis installée. Donc ce n'est pas Poky qui est l'ensemble des possibles, mais l'image bâtie à partir des choix de Poky en terme de réglages, versionning etc…; et de la sélection des composants embarqués dans l'image.
Donc on a le choix entre choisir l'une des images de référence proposées par Poky, qui ne seront pas utilisables telles quelles effectivement (sauf à fin de test), ou bien créer sa propre recette d'image en sélectionnant les paquets ou groupes de paquets adaptés, et bien souvent en les customisant au passage.
A noter que dans tout les cas il manquera dans les recettes l'applicatif (ou les applicatifs) métier. Pour ma part j'encourage vivement à considérer l'applicatif métier comme le reste et à créer une ou des recettes pour lui, afin de le packager dès le build de l'image.
Tout à fait d'accord avec ton diagnostic. Une précision par rapport au coté industriel : le but du jeu est d'intégrer tous les réglages (logins, réseau, timezone etc…) dans l'image afin d'avoir un processus d'installation sur cible sans action manuelle (et donc sans aléa), ce qui suppose de modifier les recettes (typiquement par des append sur la recette).
Donc tirer pleinement partie de Yocto, c'est créer ses propres recettes et modifier les recettes existantes, mais ceci demande un peu d'apprentissage.
En effet, Yocto doit être utilisé par un rôle spécifique dans l'équipe de développement : celui du responsable de la distribution et du packaging.
Les développeurs n'ont pas besoin de se frotter directement à Yocto. Il "suffit" de générer un SDK et de leur fournir, afin qu'ils configurent et compilent leurs développements avec le même environnement que celui qu'ils trouveront sur la cible.
Après installation du SDK, le développeur source un fichier de définition de l'environnement, puis effectue son cycle ./configure, make dans l'environnement Yocto, mais sans avoir à toucher des recettes ou utiliser bitbake.
Si le développement cible une architecture Intel, il est possible de se passer de Yocto : développer en natif en s'assurant que l'on n'a pas de lien dur avec le PC de dév. (autotools bienvenus), puis lorsque c'est au point livrer le code source au packager qui l'intègre dans Yocto. Personnellement j'accompagne des clients qui bossent comme cela.
Encore faut il s'assurer que les différences de version entre le PC de développement et l'image finale générée par Yocto n'induisent pas de problème lors de l'intégration sur la cible.
Si par contre on cible une architecture non Intel, se replier sur le PC de développement n'est pas possible puisqu'il faut tester en croisé. Le SDK devient alors la solution.
Concernant les prérequis, c'est une erreur lors de la mise en ligne du programme. Merci de l'avoir signalé, je fais rectifier.
Bonjour, il n'y a rien de prévu en termes d'enregistrement. Par contre il est prévu que les slides soient diffusés sur Slideshare sous licence Creative Commons.
[^] # Re: Terminologie
Posté par Cch . En réponse à la dépêche Atelier « Concevoir un système embarqué Linux avec Yocto » en octobre 2015. Évalué à 1.
Petite précision supplémentaire par rapport au commentaire d'Alexandre : dans ma réponse précédente, il faut entendre distribution Poky comme l'ensemble des recettes disponibles à travers les recettes fournies.
Si par contre on prend poky comme les réglages de type distro (fichier conf/distro/poky.conf), alors Alexandre a raison : pour quelqu'un de suffisamment expérimenté, il peut être intéressant de créer sa propre distribution afin d'affiner/modifier les réglages spécifiés par le fichier poky.conf, et éventuellement de modifier les DISTRO_FEATURES pour adapter le contenu de l'image de base à ses pré-requis.
Par contre à ce niveau là on est dans de l'utilisation avancée, et de l'optimisation fine de l'image finale.
[^] # Re: Retour d'expérience
Posté par Cch . En réponse à la dépêche Atelier « Concevoir un système embarqué Linux avec Yocto » en octobre 2015. Évalué à 2.
Globalement d'accord avec le fait que ce n'est pas simple (sinon proposer un atelier n'aurait pas de sens …).
Néanmoins est ce le fait de l'outil, ou bien est ce intrinsèque? J'ai l'habitude de dire aux gens que je forme que ce n'est pas parce qu'ils commencent à maîtriser l'outil que tout est gagné. En effet encore faut il savoir comment bâtir une distribution embarquée, et même comment arriver à un objectif fonctionnel à base de composants Linux.
Ceci se retrouve amplifié dans le cas assez fréquent d'un développement croisé, du fait de la dualité PC de développement / cible.
En l'absence des outils proposés par Yocto Project, on peut s'appuyer sur buildroot qui rendra un service similaire mais en étant plus léger (et donc moins ambitieux, il n'y a pas de miracle), ou bien travailler à la main (en mode Do It Yourself).
Pour avoir bâti pendant de nombreuses années des distributions Linux embarquées, il est clair que le mode Do It Yourself trouve vite ses limites dès lors que l'on veut ajouter du contenu logiciel riche dans la distribution, ce qui est de plus en plus fréquent.
[^] # Re: Terminologie
Posté par Cch . En réponse à la dépêche Atelier « Concevoir un système embarqué Linux avec Yocto » en octobre 2015. Évalué à 2.
Tout à fait d'accord sur les précisions de terminologie. D'ailleurs dans l'atelier j'indique que le terme consacré est Yocto Project, et que c'est par commodité (voire par abus) qu'on le raccourcit en Yocto.
Effectivement Yocto est le projet, qui offre des outils divers, mais également un très gros effort de documentation. Par contre dans les échanges force est de constater que c'est Yocto qui est utilisé et non Poky. Mes clients viennent me voir pour du support Yocto, et non du support Poky. Du coup c'est rapidement que le vocable impropre se banalise.
Concernant le fait de savoir si Poky est utilisé pour des tests ou un projet final, je pense que la distinction est plus fine. Ce qui fait le contenu logiciel du projet final, c'est la recette image qui est buildée puis installée. Donc ce n'est pas Poky qui est l'ensemble des possibles, mais l'image bâtie à partir des choix de Poky en terme de réglages, versionning etc…; et de la sélection des composants embarqués dans l'image.
Donc on a le choix entre choisir l'une des images de référence proposées par Poky, qui ne seront pas utilisables telles quelles effectivement (sauf à fin de test), ou bien créer sa propre recette d'image en sélectionnant les paquets ou groupes de paquets adaptés, et bien souvent en les customisant au passage.
A noter que dans tout les cas il manquera dans les recettes l'applicatif (ou les applicatifs) métier. Pour ma part j'encourage vivement à considérer l'applicatif métier comme le reste et à créer une ou des recettes pour lui, afin de le packager dès le build de l'image.
[^] # Re: 3615 MaLife
Posté par Cch . En réponse à la dépêche Atelier « Concevoir un système embarqué Linux avec Yocto » en octobre 2015. Évalué à 1.
Tout à fait d'accord avec ton diagnostic. Une précision par rapport au coté industriel : le but du jeu est d'intégrer tous les réglages (logins, réseau, timezone etc…) dans l'image afin d'avoir un processus d'installation sur cible sans action manuelle (et donc sans aléa), ce qui suppose de modifier les recettes (typiquement par des append sur la recette).
Donc tirer pleinement partie de Yocto, c'est créer ses propres recettes et modifier les recettes existantes, mais ceci demande un peu d'apprentissage.
[^] # Re: 3615 MaLife
Posté par Cch . En réponse à la dépêche Atelier « Concevoir un système embarqué Linux avec Yocto » en octobre 2015. Évalué à 1.
En effet, Yocto doit être utilisé par un rôle spécifique dans l'équipe de développement : celui du responsable de la distribution et du packaging.
Les développeurs n'ont pas besoin de se frotter directement à Yocto. Il "suffit" de générer un SDK et de leur fournir, afin qu'ils configurent et compilent leurs développements avec le même environnement que celui qu'ils trouveront sur la cible.
Après installation du SDK, le développeur source un fichier de définition de l'environnement, puis effectue son cycle ./configure, make dans l'environnement Yocto, mais sans avoir à toucher des recettes ou utiliser bitbake.
Si le développement cible une architecture Intel, il est possible de se passer de Yocto : développer en natif en s'assurant que l'on n'a pas de lien dur avec le PC de dév. (autotools bienvenus), puis lorsque c'est au point livrer le code source au packager qui l'intègre dans Yocto. Personnellement j'accompagne des clients qui bossent comme cela.
Encore faut il s'assurer que les différences de version entre le PC de développement et l'image finale générée par Yocto n'induisent pas de problème lors de l'intégration sur la cible.
Si par contre on cible une architecture non Intel, se replier sur le PC de développement n'est pas possible puisqu'il faut tester en croisé. Le SDK devient alors la solution.
Concernant les prérequis, c'est une erreur lors de la mise en ligne du programme. Merci de l'avoir signalé, je fais rectifier.
[^] # Re: Enregistrement ?
Posté par Cch . En réponse à la dépêche Séminaire gratuit "Concevoir un système embarqué Linux avec Yocto" en décembre 2014. Évalué à 1.
Les slides du séminaire sont disponibles sur Slideshare : http://fr.slideshare.net/charreyre/seminaire-yocto-4decembre2014
[^] # Re: Enregistrement ?
Posté par Cch . En réponse à la dépêche Séminaire gratuit "Concevoir un système embarqué Linux avec Yocto" en décembre 2014. Évalué à 2.
Bonjour, il n'y a rien de prévu en termes d'enregistrement. Par contre il est prévu que les slides soient diffusés sur Slideshare sous licence Creative Commons.