Au passage, j'ai discuté avec Thomas Petazzoni qui est un mainteneur Buildroot, il m'a clairement dit que c'est bien gentil Buildroot, mais dès que tu veux bosser sérieusement, c'est Yocto (il m'avait sorti un truc style "Yocto c'est Buildroot dopé aux emphétamines" je crois). En pro, il utilise quasi exclusivement Yocto.
Oula oula. Je suis cité ici, pourtant je ne pense pas avoir jamais dit ça. Nous utilisons Buildroot professionnellement à Bootlin pour de nombreux projets clients, un certain nombre de nos clients demandent explicitement Buildroot car ils n'ont pas besoin de la puissance de Yocto, et n'ont pas l'envie, l'intérêt ou l'expertise pour aller gravir la raide courbe d'apprentissage que Yocto nécessite. Bref, à Bootlin, nous faisons à la fois du Yocto et du Buildroot, selon les demandes de nos clients et le type des projets.
Et c'est tout à fait possible de bosser sérieusement avec Buildroot. Des petites entreprises comme Google, Tesla, Rockwell Collins utilisent Buildroot pour des produits.
Oh, je sais qu'on est pas vendredi, mais je précise quand même : Buildroot, c'est avec un bon vieil /etc/inittab des familles, et c'est sans systemd !!!
Juste pour précider: Buildroot supporte effectivement l'init de Busybox (choix par défault), l'init SysV classique, mais aussi systemd.
Effectivement, il y a du support pour le Armada 3700 dans le kernel mainline. Tout n'est pas supporté dans le kernel 4.6: seulement le support de base. Mais nous continuons d'y ajouter de nouvelles fonctionnalités. Par exemple, Linux 4.8 sorti hier apporte le support du PCIe sur l'Armada 3700. Et nous travaillons sur les autres fonctionnalités.
Donc le support en mainline n'est clairement pas complet à l'heure actuelle, mais il le sera d'ici quelques mois.
It will be nice that this card not to be obsolete in one year because of the GPU unusable with future Linux Kernels.
En pratique, avec le driver Mali, ça ne marche pas si mal, même avec des kernels récents. Mon collègue Maxime Ripard a fait fonctionner le driver Mali propriétaire de ARM sur le dernier kernel (4.4 à l'époque), par dessus le driver DRM/KMS qu'il a écrit pour les SoCs Allwinner. Le fait que la partie kernel du driver soit livrée avec les sources permet de l'adapter, et donc de ne pas être coincée. Seule la partie en userspace est fermée (c'est bien sûr la partie la plus importante, mais d'un point de vue strictement technique, le fait qu'elle soit fermée n'empêche pas de faire évoluer la partie kernel).
Évidemment, ce serait bien mieux si toute la partie userspace était disponible sous licence libre.
D'après ce que je comprends ils ont sollicité free-electrons
Non, nous ne travaillons pas sur le PINE64. Nous travaillons sur le C.H.I.P de Allwinner, c'est ce qui est indiqué dans les commentaires du post CNX-Software dans le lien.
Donc oui, Nextthing a une vraie approche upstream pour le support Linux. Par contre pour le PINE64, je ne sais pas du tout quelle sera leur approche.
Je n'ai qu'une chose à dire: tout est dans le titre!
Plus sérieusement, je suis vraiment content de voir que l'Agenda du Libre continue à évoluer, et que cette idée qui a effectivement été discutée depuis longtemps se concrétise enfin. Bravo à tous ceux qui continuent à faire vivre et revivre l'Agenda du Libre aujourd'hui, et merci à vous!
Il existe une solution "push button". Il suffit d'aller dans le menu "Linux kernel", et de sélectionner Xenomai. Évidemment, Xenomai prennant la forme de patches disponibles uniquement pour certaines versions bien précises du kernel, il faudra indiquer à Buildroot une version du kernel pour laquelle un patch Xenomai existe.
Par contre, ce qui est clair, c'est qu'utiliser un outil tel que Buildroot en tant que root, ça me semble à la fois inutile, et possiblement dangereux.
Euh, la BeagleBoneBlack qui ne peut pas faire tourner Quake ? La BBB utilise un TI AM3358, qui a un accélérateur 3D, le PowerVR d'Imagination Technologies. Donc bon, faire tourner Quake, ça me semble clairement dans les cordes de cette plateforme, largement plus puissante qu'une RPi.
Effectivement, la définition d'embarqué varie d'un domaine à l'autre. Mais quand tu dis que la Rasberry Pi n'est pas de l'embarqué car très puissant, alors effectivement, on peut dire que je ne suis pas d'accord. Un grand nombre de nos clients utilisent des plateformes bien plus puissantes que la Rasberry Pi (qui est en fait une brouette poussive comparée à ce qui se fait actuellement dans le monde ARM), et ce pour des applications vraiment embarquées/enfouies.
Et effectivement, il n'est pas forcément nécessaire d'avoir une expérience embarquée en tant que tel. Je dis toujours qu'un bon Linuxien (qui a déjà recompilé son noyau sur son desktop, a fait un peu de développement userspace, connaît bien le fonctionnement de sa distro et l'architecture de Linux) sera un meilleur développeur Linux embarqué, qu'un développeur qui a beaucoup d'expérience embarqué sur d'autres OS (ou pas d'OS) et qui veut faire du Linux. En effet, dans "Linux embarqué", c'est clairement la partie "Linux" qui est la plus important. Qu'on soit sur ARM ou x86, compiler le kernel c'est quasiment la même chose. Le développement d'application ou kernel, c'est la même chose quelque soit l'architecture.
Nous sommes très attentifs à l'expérience "hors travail". Donc si tu as déjà bidouillé des liseuses ARM ou d'autres plateformes embarqués sur ton temps perso, que tu es capable d'en parler, d'expliquer ce que tu as fait, ce que tu as compris et appris, pour nous, c'est de l'expérience.
Après, la meilleure façon de montrer cette expérience c'est d'avoir des contributions ici ou là (quelques patches dans tel ou tel projet relatif au domaine). Mais je sais que ce n'est vraiment pas facile de contribuer lorsque l'on a pas de projet concret en tête.
En tout cas, pour les candidats au profil plutôt débutant, nous sommes super intéressés par ce que le candidat a pu faire dans son temps perso. Par exemple, un candidat débutant qui dit avoir bidouiller des trucs sur une Rasberry Pi ou avoir connecté deux LEDs sur sa BeagleBone attirera clairement notre attention.
Formulation foireuse, je l'avoue. Mais tout le monde l'aura compris, je voulais dire "s'installer dans la région de Toulouse ou la région d'Orange, où les bureaux de la société sont actuellement situés".
Le salaire est fonction de l'expérience du candidat, de ses contributions existantes à des projets libres du domaine, etc. Globalement, je pense que Free Electrons paie plutôt correctement pour une petite structure, mais demande en échange l'implication nécessaire dans une petite société: plutôt forte :)
Il faut aussi voir que Free Electrons envoie tous ses ingénieurs à deux conférences chaque année: Embedded Linux Conference, et Embedded Linux Conference Europe, et offre des facilités pour aller à d'autres conférences (mon collègue Maxime Ripard était à Linux Plumbers à la Nouvelle Orléans la semaine dernière, j'étais à Linaro Connect en juillet à Dublin et à Kernel Recipes ces deux derniers jours à Paris). Elle offre également, pour beaucoup de projets, des possibilités de contribution upstream. Tout cela donne de la visibilité à chaque personne dans la communauté, ce qui ne peut être que bénéfique pour le reste de sa carrière. De mon point de vue, c'est un point à ne pas négliger par rapport à du boulot complètement caché dans d'autres boîtes, qui interdisent les contributions, n'envoient jamais à des confs, etc.
Sinon, toujours avec un ARMv7 de chez Marvell, mais cette fois-ci un dual core, il y a l'OpenBlocks AX3, http://openblocks.plathome.com/products/ax3/. Supporté aussi par le kernel mainline. C'est plus cher, et un peu plus difficile à se procurer en Europe.
systemd intègre des fonctionnalités similaires à celles offertes par crond et atd. Il n'intègre pas crond et atd. Vu ce que fait systemd: réagir aux événements sur les devices (intégration d'udev), réagir aux événements sur les sockets (intégration inetd, socket activations, etc.), ça paraît assez logique qu'il réagisse aux événements "d'heure" et soit capable de déclencher des "choses" à des heures données.
Visiblement, l'auteur du journal n'était pas à la conférence de Lennart à FOSDEM. J'y étais. Donc quand l'auteur de ce journal dit:
Lennart qualifie d'obsolètes les composants suivant : ConsoleKit, sysvinit, initscripts, pm-utils, inetd, acpid, syslog, watchdog, cgrulesd, cron, atd.
Alors il interprète mal les slides de Lennart. Dans sa conférence, Lennart dit que systemd rend ces composants obsolètes/inutiles. Si systemd n'est pas utilisé, alors ces composants sont toujours utiles. Évidemment, l'objectif de Lennart est que le plus de monde possible utilise systemd, et que donc ces composants deviennent de moins en moins utiles vu que les fonctionnalités qu'ils proposaient sont intégrés à systemd. Ce qui semble assez logique, et il n'y a pas besoin de crier au loup pour cela.
Donc il faut comprendre le slide de Lennart comme "systemd rend inutile la présence de ces composants dans le système, car systemd intègre directement les fonctionnalités de ces composants", et non comme "ces composants sont obsolètes".
L'article sur le programme helloworld de l'IOCCC est vraiment excellent. Il décortique pas à pas toutes les arnaques qui ont été utilisées pour rendre le programme bien obfusqué, et c'est très intéressant car ça permet de découvrir des façons subtiles d'utiliser le langage C. J'ai envoyé un e-mail à l'auteur (David Odin) pour le féliciter, et apparemment, il est prévu d'autres articles sur d'autres programmes de l'IOCCC. J'attends ça avec impatience.
[^] # Re: Annuaire des Gull
Posté par Thomas Petazzoni (site web personnel) . En réponse au journal Le Tour des GULLs de Bookynette. Évalué à 7.
https://www.agendadulibre.org/orgas
[^] # Re: Vraiment utilisé ? find et grep only ? Buildroot n'est-il pas mieux ?
Posté par Thomas Petazzoni (site web personnel) . En réponse à la dépêche Yocto Zeus. Évalué à 6.
Au passage, j'ai discuté avec Thomas Petazzoni qui est un mainteneur Buildroot, il m'a clairement dit que c'est bien gentil Buildroot, mais dès que tu veux bosser sérieusement, c'est Yocto (il m'avait sorti un truc style "Yocto c'est Buildroot dopé aux emphétamines" je crois). En pro, il utilise quasi exclusivement Yocto.
Oula oula. Je suis cité ici, pourtant je ne pense pas avoir jamais dit ça. Nous utilisons Buildroot professionnellement à Bootlin pour de nombreux projets clients, un certain nombre de nos clients demandent explicitement Buildroot car ils n'ont pas besoin de la puissance de Yocto, et n'ont pas l'envie, l'intérêt ou l'expertise pour aller gravir la raide courbe d'apprentissage que Yocto nécessite. Bref, à Bootlin, nous faisons à la fois du Yocto et du Buildroot, selon les demandes de nos clients et le type des projets.
Et c'est tout à fait possible de bosser sérieusement avec Buildroot. Des petites entreprises comme Google, Tesla, Rockwell Collins utilisent Buildroot pour des produits.
[^] # Re: Vraiment utilisé ? find et grep only ? Buildroot n'est-il pas mieux ?
Posté par Thomas Petazzoni (site web personnel) . En réponse à la dépêche Yocto Zeus. Évalué à 8.
Oh, je sais qu'on est pas vendredi, mais je précise quand même : Buildroot, c'est avec un bon vieil /etc/inittab des familles, et c'est sans systemd !!!
Juste pour précider: Buildroot supporte effectivement l'init de Busybox (choix par défault), l'init SysV classique, mais aussi systemd.
[^] # Re: Qui viendra ??
Posté par Thomas Petazzoni (site web personnel) . En réponse à la dépêche Capitole du Libre 2017 : programme des festivités des 18 et 19 novembre. Évalué à 3.
o/
[^] # Re: Another One
Posté par Thomas Petazzoni (site web personnel) . En réponse au journal Encore une «mini board». Évalué à 10.
Effectivement, il y a du support pour le Armada 3700 dans le kernel mainline. Tout n'est pas supporté dans le kernel 4.6: seulement le support de base. Mais nous continuons d'y ajouter de nouvelles fonctionnalités. Par exemple, Linux 4.8 sorti hier apporte le support du PCIe sur l'Armada 3700. Et nous travaillons sur les autres fonctionnalités.
Donc le support en mainline n'est clairement pas complet à l'heure actuelle, mais il le sera d'ici quelques mois.
[^] # Re: Compatible Linux ?
Posté par Thomas Petazzoni (site web personnel) . En réponse au journal Et sinon, il y a toujours le Pine A64+. Évalué à 8.
It will be nice that this card not to be obsolete in one year because of the GPU unusable with future Linux Kernels.
En pratique, avec le driver Mali, ça ne marche pas si mal, même avec des kernels récents. Mon collègue Maxime Ripard a fait fonctionner le driver Mali propriétaire de ARM sur le dernier kernel (4.4 à l'époque), par dessus le driver DRM/KMS qu'il a écrit pour les SoCs Allwinner. Le fait que la partie kernel du driver soit livrée avec les sources permet de l'adapter, et donc de ne pas être coincée. Seule la partie en userspace est fermée (c'est bien sûr la partie la plus importante, mais d'un point de vue strictement technique, le fait qu'elle soit fermée n'empêche pas de faire évoluer la partie kernel).
Évidemment, ce serait bien mieux si toute la partie userspace était disponible sous licence libre.
[^] # Re: Compatible Linux ?
Posté par Thomas Petazzoni (site web personnel) . En réponse au journal Et sinon, il y a toujours le Pine A64+. Évalué à 10.
D'après ce que je comprends ils ont sollicité free-electrons
Non, nous ne travaillons pas sur le PINE64. Nous travaillons sur le C.H.I.P de Allwinner, c'est ce qui est indiqué dans les commentaires du post CNX-Software dans le lien.
Donc oui, Nextthing a une vraie approche upstream pour le support Linux. Par contre pour le PINE64, je ne sais pas du tout quelle sera leur approche.
# Trop de la balle!
Posté par Thomas Petazzoni (site web personnel) . En réponse à la dépêche Mieux diffuser vos évènements sur LinuxFr.org avec l'Agenda du Libre. Évalué à 9.
Je n'ai qu'une chose à dire: tout est dans le titre!
Plus sérieusement, je suis vraiment content de voir que l'Agenda du Libre continue à évoluer, et que cette idée qui a effectivement été discutée depuis longtemps se concrétise enfin. Bravo à tous ceux qui continuent à faire vivre et revivre l'Agenda du Libre aujourd'hui, et merci à vous!
[^] # Re: Explication
Posté par Thomas Petazzoni (site web personnel) . En réponse au journal Busybox retire le support de systemd ?. Évalué à 9.
Absolument aucun rapport. Le bug que tu pointes est un bug de Buildroot, pas de Busybox.
[^] # Re: Supports accessibles?
Posté par Thomas Petazzoni (site web personnel) . En réponse à la dépêche Meetup sur la gestion des flashs NAND dans Linux le 23 juin 2015 à Toulouse. Évalué à 3.
Les supports sont en fait déjà en ligne, car c'est une partie de notre formation "Développement Linux embarqué" sur le sujet, que nous avons mis à jour récemment. Voir slide 257 et suivants de http://free-electrons.com/doc/training/embedded-linux/embedded-linux-slides.pdf.
Il n'y aura par contre pas de flux vidéo, nous n'avons pas la logistique aujourd'hui pour enregistrer les meetups.
[^] # Re: Salut cousin :-)
Posté par Thomas Petazzoni (site web personnel) . En réponse à la dépêche La folie Docker. Évalué à 1.
Oui, c'est mon frère.
# Salut cousin :-)
Posté par Thomas Petazzoni (site web personnel) . En réponse à la dépêche La folie Docker. Évalué à 7.
Tout est dans le titre.
[^] # Re: Question
Posté par Thomas Petazzoni (site web personnel) . En réponse à la dépêche Sortie de Buildroot 2014.02. Évalué à 6.
Il existe une solution "push button". Il suffit d'aller dans le menu "Linux kernel", et de sélectionner Xenomai. Évidemment, Xenomai prennant la forme de patches disponibles uniquement pour certaines versions bien précises du kernel, il faudra indiquer à Buildroot une version du kernel pour laquelle un patch Xenomai existe.
[^] # Re: Sur la Rasberry Pi
Posté par Thomas Petazzoni (site web personnel) . En réponse à la dépêche Sortie de Buildroot 2014.02. Évalué à 10.
Effectivement, il y a une erreur dans la dépêche.
Par contre, ce qui est clair, c'est qu'utiliser un outil tel que Buildroot en tant que root, ça me semble à la fois inutile, et possiblement dangereux.
[^] # Re: Sur la Rasberry Pi
Posté par Thomas Petazzoni (site web personnel) . En réponse à la dépêche Sortie de Buildroot 2014.02. Évalué à 3.
Ah mince, effectivement. Est-ce qu'un modérateur peut corriger la dépêche ?
[^] # Re: Révolution
Posté par Thomas Petazzoni (site web personnel) . En réponse au journal Donc maintenant Broadcom aime l'open source et les specs ouverte ?. Évalué à 5.
Euh, la BeagleBoneBlack qui ne peut pas faire tourner Quake ? La BBB utilise un TI AM3358, qui a un accélérateur 3D, le PowerVR d'Imagination Technologies. Donc bon, faire tourner Quake, ça me semble clairement dans les cordes de cette plateforme, largement plus puissante qu'une RPi.
[^] # Re: Formation
Posté par Thomas Petazzoni (site web personnel) . En réponse au message Free Electrons recrute. Évalué à 4.
Effectivement, la définition d'embarqué varie d'un domaine à l'autre. Mais quand tu dis que la Rasberry Pi n'est pas de l'embarqué car très puissant, alors effectivement, on peut dire que je ne suis pas d'accord. Un grand nombre de nos clients utilisent des plateformes bien plus puissantes que la Rasberry Pi (qui est en fait une brouette poussive comparée à ce qui se fait actuellement dans le monde ARM), et ce pour des applications vraiment embarquées/enfouies.
Et effectivement, il n'est pas forcément nécessaire d'avoir une expérience embarquée en tant que tel. Je dis toujours qu'un bon Linuxien (qui a déjà recompilé son noyau sur son desktop, a fait un peu de développement userspace, connaît bien le fonctionnement de sa distro et l'architecture de Linux) sera un meilleur développeur Linux embarqué, qu'un développeur qui a beaucoup d'expérience embarqué sur d'autres OS (ou pas d'OS) et qui veut faire du Linux. En effet, dans "Linux embarqué", c'est clairement la partie "Linux" qui est la plus important. Qu'on soit sur ARM ou x86, compiler le kernel c'est quasiment la même chose. Le développement d'application ou kernel, c'est la même chose quelque soit l'architecture.
[^] # Re: Formation
Posté par Thomas Petazzoni (site web personnel) . En réponse au message Free Electrons recrute. Évalué à 4.
Nous sommes très attentifs à l'expérience "hors travail". Donc si tu as déjà bidouillé des liseuses ARM ou d'autres plateformes embarqués sur ton temps perso, que tu es capable d'en parler, d'expliquer ce que tu as fait, ce que tu as compris et appris, pour nous, c'est de l'expérience.
Après, la meilleure façon de montrer cette expérience c'est d'avoir des contributions ici ou là (quelques patches dans tel ou tel projet relatif au domaine). Mais je sais que ce n'est vraiment pas facile de contribuer lorsque l'on a pas de projet concret en tête.
En tout cas, pour les candidats au profil plutôt débutant, nous sommes super intéressés par ce que le candidat a pu faire dans son temps perso. Par exemple, un candidat débutant qui dit avoir bidouiller des trucs sur une Rasberry Pi ou avoir connecté deux LEDs sur sa BeagleBone attirera clairement notre attention.
[^] # Re: logement
Posté par Thomas Petazzoni (site web personnel) . En réponse au message Free Electrons recrute. Évalué à 6.
Formulation foireuse, je l'avoue. Mais tout le monde l'aura compris, je voulais dire "s'installer dans la région de Toulouse ou la région d'Orange, où les bureaux de la société sont actuellement situés".
[^] # Re: Salaire
Posté par Thomas Petazzoni (site web personnel) . En réponse au message Free Electrons recrute. Évalué à 10.
Le salaire est fonction de l'expérience du candidat, de ses contributions existantes à des projets libres du domaine, etc. Globalement, je pense que Free Electrons paie plutôt correctement pour une petite structure, mais demande en échange l'implication nécessaire dans une petite société: plutôt forte :)
Il faut aussi voir que Free Electrons envoie tous ses ingénieurs à deux conférences chaque année: Embedded Linux Conference, et Embedded Linux Conference Europe, et offre des facilités pour aller à d'autres conférences (mon collègue Maxime Ripard était à Linux Plumbers à la Nouvelle Orléans la semaine dernière, j'étais à Linaro Connect en juillet à Dublin et à Kernel Recipes ces deux derniers jours à Paris). Elle offre également, pour beaucoup de projets, des possibilités de contribution upstream. Tout cela donne de la visibilité à chaque personne dans la communauté, ce qui ne peut être que bénéfique pour le reste de sa carrière. De mon point de vue, c'est un point à ne pas négliger par rapport à du boulot complètement caché dans d'autres boîtes, qui interdisent les contributions, n'envoient jamais à des confs, etc.
À vous de voir, moi j'ai choisi mon camp :-)
[^] # Re: Ça c'est de l'info !
Posté par Thomas Petazzoni (site web personnel) . En réponse au journal Minnow Board. Évalué à 7.
Euh, sauf erreur, le GPU 3D est à base de PowerVR, donc les pilotes ne sont pas libres.
[^] # Re: singularité de cette carte
Posté par Thomas Petazzoni (site web personnel) . En réponse au journal Minnow Board. Évalué à 6.
Pour le coté multiples interfaces Gigabit:
Avec du processeur ARMv7 de chez Marvell, il y a la Mirabox avec 2 ports Gigabit, et 2 ports USB 3.0, voir http://www.globalscaletechnologies.com/p-58-mirabox-development-kit.aspx. Supporté par Linux en mainline. Ça coûte $149.
Sinon, toujours avec un ARMv7 de chez Marvell, mais cette fois-ci un dual core, il y a l'OpenBlocks AX3, http://openblocks.plathome.com/products/ax3/. Supporté aussi par le kernel mainline. C'est plus cher, et un peu plus difficile à se procurer en Europe.
[^] # Re: Mauvaise interprétation
Posté par Thomas Petazzoni (site web personnel) . En réponse au journal Systemd dans Debian. Évalué à 10.
systemd intègre des fonctionnalités similaires à celles offertes par crond et atd. Il n'intègre pas crond et atd. Vu ce que fait systemd: réagir aux événements sur les devices (intégration d'udev), réagir aux événements sur les sockets (intégration inetd, socket activations, etc.), ça paraît assez logique qu'il réagisse aux événements "d'heure" et soit capable de déclencher des "choses" à des heures données.
# Mauvaise interprétation
Posté par Thomas Petazzoni (site web personnel) . En réponse au journal Systemd dans Debian. Évalué à 10.
Visiblement, l'auteur du journal n'était pas à la conférence de Lennart à FOSDEM. J'y étais. Donc quand l'auteur de ce journal dit:
Alors il interprète mal les slides de Lennart. Dans sa conférence, Lennart dit que systemd rend ces composants obsolètes/inutiles. Si systemd n'est pas utilisé, alors ces composants sont toujours utiles. Évidemment, l'objectif de Lennart est que le plus de monde possible utilise systemd, et que donc ces composants deviennent de moins en moins utiles vu que les fonctionnalités qu'ils proposaient sont intégrés à systemd. Ce qui semble assez logique, et il n'y a pas besoin de crier au loup pour cela.
Donc il faut comprendre le slide de Lennart comme "systemd rend inutile la présence de ces composants dans le système, car systemd intègre directement les fonctionnalités de ces composants", et non comme "ces composants sont obsolètes".
# Étude du helloworld de l'IOCCC
Posté par Thomas Petazzoni (site web personnel) . En réponse à la dépêche Revue de presse — décembre 2012. Évalué à 3.
L'article sur le programme helloworld de l'IOCCC est vraiment excellent. Il décortique pas à pas toutes les arnaques qui ont été utilisées pour rendre le programme bien obfusqué, et c'est très intéressant car ça permet de découvrir des façons subtiles d'utiliser le langage C. J'ai envoyé un e-mail à l'auteur (David Odin) pour le féliciter, et apparemment, il est prévu d'autres articles sur d'autres programmes de l'IOCCC. J'attends ça avec impatience.