Thomas Petazzoni a écrit 629 commentaires

Nous ne serons malheureusement pas au Real Time Linux Workshop, donc les seules vidéos que nous posterons seront celles de l'Embedded Linux Conference Europe (ce qui représente quand même sans doute une cinquantaine de conférences).

Peux-tu donner des exemples précis ?

Normalement, dans un flux régional, tu n'as que les événements de la région concernée, sauf pour les événements à portée nationale, qui sont visibles dans les flux de toutes les régions. Et normalement, en dehors de quelques événements majeurs genre RMLL ou Solutions Linux, la portée nationale n'est positionnée que sur très peu d'événements.

Pour tous ces points, je vous invite à lancer des discussions sur la liste du projet, afin d'améliorer les choses au fur et à mesure. Pour s'inscrire à la liste: http://www.toulibre.org/cgi-bin/mailman/listinfo/devel. Je suis clairement intéressé par le retour des utilisateurs.

À noter aussi dans les kiosques, le troisième numéro de OpenSilicium, un magazine lancé par Diamond Editions (qui fait aussi GNU/Linux Magazine France, Linux Pratique, Misc, etc.). OpenSilicium est consacré à tout ce qui est électronique, embarqué, bas niveau. Et le troisième numéro confirme tout à fait les deux premiers: un magazine vraiment passionnant pour ceux qui s'intéressent à ces thématiques. Je le recommande vivement.

Le support Blackfin venant juste d'être ajouté, il est fort probable qu'il y ai encore des soucis. N'hésites pas à les remonter sur la liste, je suis sûr que Mike Frysinger sera très réactif pour y répondre.

Le projet a totalement changé depuis fin 2008 - début 2009. Jusqu'à cette date, il n'y avait pas de mainteneur clairement identifié, pas de releases stable, plein de développeurs qui committaient chacun dans leur coin dans un même dépôt SVN sans concertation, bref un projet sans mainteneur.

Depuis que Peter Korsgaard a repris le projet, une release stable a été publiée tous les trois mois, avec deux mois de développement et un mois de stabilisation. Nous faisons de nombreux tests de combinaison aléatoires de paquet (pour l'architecture ARM, on a un test qui tourne 24/24 7/7 sur une machine de la ferme GCC et qui teste des combinaisons aléatoires de paquets). Ce test nous a permis de corriger un très très grand nombre de problèmes. Je pense que la situation est donc bien, bien meilleure qu'il y a cinq ans. Sans parler des corrections des problèmes de build, la quasi-totalité de Buildroot a été ré-écrit, et beaucoup de choses ont été simpliées, l'arborescence est plus claire, les paquets plus homogènes, etc. On a aussi pas hésité à supprimer des paquets obsolètes, trop spécifiques, et qui ne compilaient pas depuis longtemps.

Cela dit, vu le nombre de combinaisons d'options de configuration qu'il y a, c'est juste impossible de couvrir tous les cas. Mais la communauté est maintenant bien active, on réagit en général rapidement aux problèmes remontés par les utilisateurs.

Il est clair que Buildroot est beaucoup plus simple et rapide à prendre en main, et que la compilation d'un système simple avec Buildroot prend beaucoup moins de temps qu'avec OpenEmbedded. Cela dit, il faut aussi reconnaître que Buildroot génère un système non-flexible (pas de gestion de paquets) et surtout oblige à de fréquents rebuilds complets du système (lorsque des changements importants de configuration sont réalisés).

En ce qui me concerne, je travaille surtout sur des systèmes à vocation "industrielle", avec souvent peu de composants (5 à 10 composants maximum), et pour ceux-là, un Buildroot convient très bien, et avoir une solution comme OpenEmbedded serait plutôt un fardeau qu'autre chose.

Concernant le format du paquet, nous n'avons rien décidé encore. Il y a beaucoup de choses à faire avant de décider du format du paquet, et j'ai presque envie de dire que c'est un "détail" par rapport à tout le reste du travail :-)

Concernant le système de fichiers en lecture seule, c'est effectivement ce qu'utilisent un certain nombre de systèmes embarqués, mais pas tous. Certains veulent pouvoir mettre à jour de manière partielle certains aspects du système, et dans ce cas, un système de fichiers en lecture/écriture est utilisé. Le monde de l'embarqué est tellement vaste qu'il y a rarement de "règles générales".

Les slides sont dispos quelque part ?

à voir avec ce que l'AdL peut proposer comme interface pour recuperer les infos

Actuellement, on a : du flux RSS (http://www.agendadulibre.org/rsslist.php), du calendrier iCal (http://www.agendadulibre.org/icallist.php) et XML (http://www.agendadulibre.org/xmllistevents.php).

Je suis prêt à ajouter n'importe quel format de sortie, selon les besoins.

« Ubuntu Party » serait-il un terme marketing pour attirer plus de monde à une journée qui parle en fait plutôt du libre, des ses applications et ses enjeux

Zut, je suis grillé :-)

Impossible. D'après le point 1) de http://opensource.org/docs/osd:

«
The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.
»

Donc tu ne trouveras aucune licence « open source » qui permet d'interdire la revente, puisque c'est tout simplement contradictoire avec la définition du mot « open source » par l'Open Source Initiative.

De plus, il serait souhaitable d'analyser les raisons pour lesquelles vous souhaitez "publier" le code. En effet, si l'objectif est de monter une communauté, pour bénéficier d'un effet de levier, de contributions, etc. alors le choix d'une licence interdisant la commercialisation est sans aucun doute très mauvais. Il est fort peu probable qu'avec une telle licence vous arriviez à interesser un nombre important de contributeurs.

On (Toulibre) est en train de voir avec les organisateurs pour faire une captation vidéo de la conférence.

Pour voir toutes les branches avec gitk: gitk --all

Regarde du coté des input utils, http://packages.debian.org/sid/input-utils. Il y a un outil input-events qui fait probablement ce que tu cherches. Sinon, tu peux écrire un programme C qui liste les évènements reçus, il y a de la doc dans le noyau, dans Documentation/input/input.txt.

Tiens, je ne connaissais pas de confcache. Qu'est-ce que ça apporte par rapport au mécanisme de cache intégré aux autotools ?

Concernant le fait d'être obligé d'accéder à la machine cible, les autotools permettent d'indiquer à ./configure le résultat qu'aurait un test si il était fait sur la machine cible, sans avoir besoin d'y accéder effectivement.

Par exemple, quand les autotools veulent tester si ta machine cible et big ou little endian, tu passes ac_cv_c_bigendian=yes quand tu es big endian, et ac_cv_c_bigendian=no quand tu es little endian, et le tour est joué. C'est le rôle du système de build autour de passer les options qui vont bien.

Et effectivement, je trouve aussi que Scratchbox est une approche overkill. D'ailleurs, avec la fusion entre Maemo et Moblin (pour donner MeeGo), ils ont annoncé l'abandon du format de paquet Debian (utilisé par Maemo) pour passer à RPM (utilisé par Moblin). Du coup, je me demande ce qu'il va rester de Scratchbox qui était quand même très fortement orienté paquet Debian.

c'est dans la section Logiciel et le thème Hardware, vu que c'est fortement lié à celui-ci et sert pour l'embarqué, tu aurais proposé quel autre thème ?

À mon avis, il manque un thème Embarqué. Et je n'ai jamais rien compris à la distinction section et thème faite par LinuxFr pour classer les dépêches.

Est-ce vraiment nécessaire? Est-ce que les systèmes comme buildroot, qui ont une vision globale de tous les paquets, ne pourraient pas factoriser les tests du ./configure?

Comme dit plus bas, c'est ce que nous faisons avec --cache-file. Voir http://www.gnu.org/software/hello/manual/autoconf/Cache-File(...)

C'est implémenté ici: http://git.buildroot.net/buildroot/tree/package/Makefile.aut(...)

Il pourrait presque être avantageux de cacher les résultats de ce genre de macros si on est sûr que c'est invariant suivant le paquet.

Et c'est exactement ce que nous faisons, grâce à l'option --cache-file des fichiers de configure. Nous faisons ainsi partager un fichier de cache entre tous les scripts configure, ce qui améliore effectivement significativement le temps d'exécution de ces scripts.

En dehors de ça, il n'y a pas vraiment grand chose que nous puissions faire, je le crains.

Claws Mail, anciennement Sylpheed Claws, est un fork de Sylpheed si j'ai bien compris l'historique des deux projets (à l'époque, il me semble que la raison du fork était que les développeurs de Sylpheed ne voulaient pas passer à Gtk2). Néanmoins, Sylpheed dispose désormais de deux améliorations importantes par rapport à Claws :
* Le support du format Maildir. Dans Claws, il y a plugin, mais même le site officiel du projet recommande de ne pas l'utiliser. Pourtant, pour utiliser offlineimap, le support du Maildir est indispensable (à moins d'installer un serveur IMAP en local, mais c'est pénible)
* Le support du multi-threading. Comme Claws ne gère pas le Maildir, je n'utilise pas offlineimap. Et alors là, Claws est parfois assez pénible à utiliser, car les opérations IMAP (lentes à cause de la latence) bloquent toute l'interface.
À quand un Claws à la hauteur de Sylpheed ? :-)

Cela demanderait ensuite un peu de post-traitement (synchronisation des pistes audio et vidéo), mais cela me semble assez raisonnable.

Faire ce type de synchronisation est particulièrement pénible. Il vaut mieux arriver à enregistrer le son et la vidéo en même temps, lors de la conférence. Rien d'impossible, il faut juste avoir le bon matériel.

hmmm, j'ai l'impression qu'il reste à proposer de la recherche dans les cartes déjà disponibles (le mode de visualisation trié par les dernières cartes générées sur http://www.maposmatic.org/maps/ prend un peu de temps en tant qu'utilisateur). Par exemple, une recherche sur les noms de villes déjà générées ou dans les descriptions pourrait être utile, voire afficher sur une carte OSM les zones déjà générées et disponibles, avec leurs différentes versions).

Nous avons effectivement prévu d'améliorer les pages listant les jobs en cours et les cartes déjà rendues. Le code est déjà en cours d'écriture.

J'espère que lorsque qu'une carte est demandée, il est vérifié qu'elle n'existe pas déjà (en gardant la possibilité de la regénérer, pour prendre en compte des mises à jour par exemple).

Oui, on vérifie qu'il n'existe pas un rendu datant de moins de 24 heures. Si un tel rendu existe, alors l'utilisateur est automatiquement redirigé dessus, avec un petit message le lui indiquant.

perso, j'ai perdu l'url de ma demande de rendu, en regardant les précédents, j'ai vu que ça prendrait de l'ordre de 2h pour l'avoir (maintenant c'est plutôt 4h). J'ai fini par le retrouver en parcourant http://www.maposmatic.org/jobs/ et en cherchant ma description dans les pages par dichotomie, en fonction de l'heure de la demande.

Ce délai est dû aux annonces qui ont été faites, ici sur LinuxFr.org, mais aussi sur d'autres sites (LWN.net) ou des listes de diffusion OSM. En temps normal (ce qui devrait être le cas dans quelques jours), la file d'attente ne dépasse jamais 2/3 entrées, ce qui fait un temps d'attente d'une dizaine de minutes maximum en général.

je rejoins le commentaire au-dessus qu'il manque des noms de rue sur le plan :/ (dans l'index c'est bon).

C'est un problème connu de Mapnik. Il est enregistré dans notre bugzilla: https://savannah.nongnu.org/bugs/?27467 et dans celui de Mapnik: http://trac.mapnik.org/ticket/13. On discutait hier sur #maposmatic avec une personne qui suit le développement de Mapnik de plus près que nous, et apparemment, du travail est en cours sur ce sujet.

En tout cas, merci pour tous ces commentaires !

Normalement, il devrait être capable de tenir la charge. Nous regardons en ce moment la configuration pour essayer de trouver une solution au problème.

"In contrast, the Intel SSD does about 8,500 4kB random writes per second. Yeah, that's over eight thousand IOps on random write accesses with a relevant block size, rather than some silly and unrealistic contiguous write test. That's what I call solid-state media."
C'est clair qu'une copie ou autre d'un fichier c'est vachement plus "silly and unrealistic" que 8500 opérations d'écriture par secondes sur un disque pour un usage bureautique...

Toi tu n'es peut être pas intéressé. Mais les gens qui font de la base de données, je peux te dire que le nombre de petites I/O aléatoires qu'un système de stockage peut engloutir par seconde, c'est *très* *très* important.

De manière plus anecdotique, la compilation d'un soft assez gros (noyau ou autre), c'est aussi pas mal de petites I/O aléatoires.

juste le pointeur qui permet d'y accéder, appelé un inode.

Raté, l'inode c'est ce qui référence les données. Le pointeur, c'est une entrée de répertoire, ou dentry dans la terminologie du noyau.