Thomas Petazzoni a écrit 629 commentaires

  • [^] # Re: Qui viendra ??

    Posté par (page perso) . 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 (page perso) . 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 (page perso) . 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 (page perso) . 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 (page perso) . 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 (page perso) . 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 (page perso) . 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 (page perso) . En réponse à la dépêche La folie Docker. Évalué à 1.

    Oui, c'est mon frère.

  • # Salut cousin :-)

    Posté par (page perso) . En réponse à la dépêche La folie Docker. Évalué à 7.

    Tout est dans le titre.

  • [^] # Re: Question

    Posté par (page perso) . 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 (page perso) . 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 (page perso) . 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 (page perso) . 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 (page perso) . 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 (page perso) . 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 (page perso) . 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 (page perso) . 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 (page perso) . 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 (page perso) . 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 (page perso) . 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 (page perso) . 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:

    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".

  • # Étude du helloworld de l'IOCCC

    Posté par (page perso) . 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.

  • [^] # Re: video

    Posté par (page perso) . En réponse au journal Confs de Martin Peres sur la pile graphique Linux.. Évalué à 5.

  • # Dépêche en attente

    Posté par (page perso) . En réponse au journal Evenement capitole du libre à Toulouse les 24/25 Novembre 2012.. Évalué à 4.

    Pour info, j'ai soumis une dépêche pour LinuxFr.org, donc j'imagine qu'elle sera prochainement visible sur le site.

  • # Mise à jour depuis 0.63

    Posté par (page perso) . En réponse à la dépêche Galette 0.7.1(.x) : Maman, ça brûle !. Évalué à 4.

    Est-ce qu'un mécanisme de migration des données depuis Galette 0.63 est prévu? Si oui, est-ce qu'il marche bien?