Linux (fr)

  • Remplacer un (petit) cluster pour consommer bcp moins tout en gardant de la puissance (Journaux LinuxFR)

    Salut,

    je dois, pour des raisons de consommation, remplacer le (petit) cluster du boulot. Pour information, nous faisons du traitement scientifique d’images satellites. Nous avons besoin de puissance de calcul et d’I/O (aussi rapide que possible).
    Actuellement, on a 6 nœuds + un maître. 46 cœurs, 2 à 3.5go par cœur, 72 disques (12 à 24 disques par machine), pour un espace total de 140to (70 réellement utilisables avec la solution actuelle).
    Logiciellement parlant, on a:
    HTCondor pour la répartition des tâches.
    MooseFS pour le FS réparti (dont la version 1 n’est plus maintenue, la 2 n’est plus libre).
    Ganglia surveille le tout.
    Rien™ ne se charge de la configuration des machines sinon mes petits doigts.
    Le tout sur une plate-forme CentOS 6 x86_64.

    Je dois, si possible avoir mieux, tout en consommant (bcp) moins, le tout sans éclater le petit budget d’environ 20k€ HT.

    J’ai trouvé 3 solutions matérielles qui semblent correspondre (je mets les liens vers là où on achète nos bécanes habituellement, si vous connaissez mieux, ça m’intéresse, nous ne sommes liés en rien à la boite en question).

    1. Une grosse babasse gavée de CPU et de disques. 1800W, 4U. 18k€. 48 cœurs opteron 6xxx, 256 go (max) de ram (5.3go/cœur), 24 disques 6to. Le gros inconvénient, si la machine lâche, on a plus aucun moyen de production, ni d’accès aux données.
    2. Un Power Cloud R3PCA12-24, 1620W, 3U, 20k€. 96 cœurs opteron 3380 en 12 servers, 32 go (max) soit 4go/cœur, 2 disques par serveur soit 24 total (6to toujours). Beaucoup de CPU même si ce ne sont pas les plus rapides du monde, un déséquilibre cpu/disques qui me fait craindre un côté I/O surchargé et donc lent. Par contre, si une machine tombe, on ne perd que deux disques ce qui risque d’être peu problématique côté système de fichier réparti pour la disponibilité des données. Machines « maxées » (impossible d’ajouter plus de cpu ou de ram).
    3. Un FatTwin 12 disquse. 1620W, 4U, 23k€. 48 cœurs physiques/96 HT (intel xeon E5 2620v2) en 4 serveurs, 64 go (5.3 go/cœur), 256 max, 12 disques par serveur, 48 disques total. J’aime l’équilibre un disque/un cœur. J’aime beaucoup moins la chute d’une machine qui fait forcément que le FS réparti tombe avec (je ne connais pas de solution qui supporte à coût décent qu’un quart du volume disparaisse). La machine (à grands renforts de brouzoufs, intel n’y va vraiment pas avec le dos de la cuillère) peut évoluer en nombre de cpu (96 cœurs physiques max total) et en ram.

    Côté logiciel:
    1. On garderait HTCondor qui fait bien son travail.
    2. MooseFS est remplacé par une solution utilisant l’Erasure Code. Contrairement à MooseFS dont le coût est de 2 (réplicas) pour assurer un minimum de sécurité des données, cette technique permet un coût de 1.5 (je simplifie, pas la même de tergiverser). Je pense utiliser RozoFS, mais rien n’est gravé dans le marbre.
    3. Ganglia pourrait bien rester, HTCondor s’y intégrant bien (en théorie, j’ai pas eu le temps de faire la conf).
    4. J’hésite à mettre en place une solution type Ansible/Salt/Chef/Puppet bien que je les trouve assez overkill pour si peu de machines. J’aimerais trouver plus simple/plus rapide à déployer. et tant qu’à faire y intégrer les desktops utilisateurs (CentOS) ainsi que notre malheureux serveur web/bdd. soit 7 machines utilisateur (dont un windows), les serveurs au nombre de x + la gateway + le serveur web/bdd + le failover.
    Je passerais, dans la foulée, les machines utilisateurs/serveurs à CentOS 7.

    Voilà pour le topo. Merci pour vos lumières, je reste terriblement indécis. Le FatTwin me fait de l’œil, mais niveau HA c’est pas génial. Le microcloud me fait de l’œil, mais niveau I/O, c’est pas génial. Quelqu’un connaitrait-il une solution entre les deux ?
    Pour le côté résistance, j’aime bien AMD…et quand je vois les prix Intel…bref.
    Merci d’avance pour vos conseils et propositions. (inutile d’essayer de me « vendre » du debian ou ubuntu ou suse ou que sais-je. l’OS utilisé n’est pas en cause, merci :))

    Lire les commentaires

  • QRaidCODE, stocker des données sécurisée sur qrcodes (Journaux LinuxFR)

    Il y a un peu plus d'un an de ça, j'ai travaillé sur une application web de stockage de données sur qrcode utilisant un système proche du Raid des disques dur permettant de proposer à l'utilisateur de stocker des données sur une série de qrcode et de pouvoir n'utiliser qu'une fraction de ces qrcodes pour récupéré ses données.

    À l'époque, il s'agissait d'une application web qu'il était compliqué de déployer car nécessitant quelques binaires et notamment une version patché de zbarimg, j'avais l'idée de porter l'application en nodejs et faire une interface avec nodewebkit, mais je n'ai pas trouvé le temps et la motivation.

    Malgré ma fainéantise, docker me permet aujourd'hui de distribuer une version libre et fonctionnelle de l'application et de la proposer à tout un chacun pour jouer avec.

    La genèse du projet était de trouver un moyen de stocker des données importante sur le long terme comme un portefeuille de cryptomonnaie, une clé privé, etc, de permettre de distribuer le stockage des données entre plusieurs lieux ou personnes et de pouvoir récupérer ces données après une longue période de temps alors même qu'une fraction des qrcodes aurait été perdue. Les données sont chiffrées sur les qrcodes et il n'est pas possible d'accéder partiellement aux données avec un seul qrcode.

    D'un point de vu technique, il s'agit des mêmes algorithmes mis en œuvre dans le RAID 6, à savoir Reed-solomon, le développement de ce projet m'a été très formateur d'un point de vu mathématique, les corps de Galois utilisés pour calculer les données de parités ont des propriétés étonnantes.

    L'implémentation d'origine en PHP est disponible sur github, le projet est lourd car il est livré avec des matrices pré-calculées afin d'accélérer le codage et le décodage des données. Le Dockerfile est également disponible sur github et un container précompilé de l'application sur le hub docker.

    Il existe quelques limitations actuellement, il n'est pas possible de créer plus de 256 qrcodes (255 dans l'implémentation actuelle, un bug dont je n'ai pas identifié l'origine se produit lorsque l'on cherche à décoder 256 qrcodes), et la taille des données que l'on peut stocker au maximum n'est pas très importante (740 096 octets sans parités), une version permettant d'aller jusqu'à 65 536 qrcodes est définit mais pas encore implémentée (les matrices nécessaires au calcul prendrait plus de 4Go de ram et le temps de calcul pourrait être très important, limitant sont intérêt). Le format est spécifié sur le billet que j'avais publié l'année dernière.

    Il existe une démo sur un serveur pas très costaux avec un certificat auto-signé (ne pas l'utiliser avec des données sensibles).

    Si vous décidez d'héberger une instance derrière un proxy inverse, prenez garde au timeout qui peuvent se produire lors de la manipulation d'un nombre important de qrcodes.

    La licence du projet est la MIT licence. Toutes les contributions et commentaires sont les bienvenues bien entendu :)

    Lire les commentaires

  • Hack.lu 2014 (Journaux LinuxFR)

    Cher journal,

    Hack.lu, c'est fini, c'était la semaine passée. Alors, je vais te faire un résumé rapide des conférences que j'ai ou dont j'ai entendu parlées qui étaient particulièrement intéressantes. Vous pouvez retrouver une partie des supports de présentation dans les archives, elles n'étaient cependant pas filmées. Je ne vais pas détailler plus que ça parce que je n'ai pas forcément vu les conférences et puis, avec Google et le titre, vous trouverez plein d'informations si le sujet vous intéresse, si vous avez des questions, n'hésitez pas à utiliser le bouton carré avec écrit « Envoyer un commentaire ». Premièrement, les lightning talks de mardi. Elles commencent avec une démonstration par Philippe Teuwen pour montrer, à ceux qui en doutait encore, que le chiffrement ECB ne cache pas grand chose et que le CBC n'est pas forcément sûr non plus. Ensuite une démonstration d'Axelle Apvrille pour cacher un apk dans une image (développé avec Ange Albertini) et contourner ainsi beaucoup de systèmes de détection.

    La première conférence de mardi était faite par Filippo Valsorda qui a développé l'outil de test d'Heartbleed juste pour tester et qui s'est retrouvé submergé par les requêtes qui ne faisaient qu'augmenter au cours du temps. Il a notamment évoquer les extensions des navigateurs qui testaient les site pour vérifier s'ils étaient impactées qui, au final, lui envoyaient toute l'historique de navigation de ceux qui l'avaient installé. Ensuite, une explication sur le fonctionnement de l'application Android FinFisher par Attila Marosi, si jamais vous êtes infecté, vous pourrez la reconfigurer pour qu'elle s'autodétruise et être tranquille. Paul Jung nous a ensuite montré comment détecter l'exécution dans une machine virtuelle ou une sanbox, très utile si vous écrivez un malware ;) La conclusion est que pour éviter les virus, il vaut mieux avoir son système qui tourne en permanence dans ces environnement. Serge "sans paille" Guelton nous a parlé d'obfuscation de code Python. L'obfuscation de source n'est pas très utile dans ce langage, par contre, il existe d'autre technique pour éviter qu'on ne lise votre code trop simplement. La plus simple/efficace est de livrer un interpréteur modifié. Enfin, la journée s'est terminée avec une (longue) conférence de Xeno Kovah du MITRE explicant comment faire tourner un code en infectant l'UEFI et ayant le contrôle sur tout le système. L'exemple donnée est un programme qui scanne la mémoire en permanence à la recherche d'une signature particulière et qui exécute le code suivant cette signature. Cela veut dire qu'avec cela actif, il vous suffit d'un simple ping pour briquer le PC cible.

    Dans les lightning talks du mercredi, j'ai retenu celle de Philippe Teuwen sur les élection électronique belges, quelle était le bug et le portage sous Linux du système de vote pour le vérifier. Serge Guelton nous a encore parler d'obfuscation, il s'agissait ici d'une démonstration d'Epona, un outil de d'obfuscation basé sur LLVM. Il parait aussi que la conférence sur TR-069 était intéressante. Il s'agit un protocole utilisés par les routeurs domestiques (les box des FAI) pour se mettre à jour. Beaucoup d'implémentations sont très mauvaise au point de vue de la sécurité et il facile de pousser un firmware personnel sans accès physique. Xeno Kovah est aussi revenu pour nous parler de la suite la veille, et comment éviter la détection d'un BIOS modifié et comment éviter l'évitage de détection et… j'ai fais un stack overflow :). Au final, vos PC sont destinés à être hacké et vous ne pouvez pas faire grand chose pour contrer cela. La journée s'est terminée avec la fragmentation des paquets IPv6 et comment l'utiliser pour contourner les IDS (slides) par Enno Rey, les failles ont été rapportés aux différents dévelopeurs de ceux, mais comme chez Sourcefire, ils étaient trop occupés à compter leur stock options, plutôt qu'à répondre aux failles de sécurité, on a pu assisté à un beau 0day en direct. La conclusion est que les RFC sur IPv6 sont beaucoup trop bordéliques laxistes pour avoir une pile sûre (ou même respectant la norme).

    Je n'ai pas assisté aux conférences du jeudi mais il y en avait une sur Virtualbox et comment utiliser les instructions 3D pour en sortir des machines virtuelles. Saumil Shah a aussi jouer avec les images et a montré des exemples d'images qui sont aussi un fichier JavaScript valide ou même un JPEG qui est aussi du HTML et du JavaScript, une catastrophe pour la détection de comportement anormaux et le forensic d'une attaque.

    Je sais c'est un peu décousu mais moi je vous retranscris ça pèle-mêle aussi.

    Lire les commentaires

  • rv/hervé : recherche d’itinéraire vélo minimisant l'énergie en utilisant les données d'OSM (Journaux LinuxFR)

    Sommaire

    Introduction

    Il y a quelques temps, plus d'un an déjà, j'ai écrit un journal ici-même présentant un projet sur lequel je passais une partie de mon temps libre. Les choses ayant légèrement évolué depuis, je récidive. Bien que la lecture du précédent journal soit utile, elle n'est pas obligatoire pour comprendre celui-ci, sauf pour des points de détails, j'y ferai référence en temps voulu.

    Étant adepte du vélocipède en tant que moyen de transport, et comme tous les amateurs de cet activité merveilleuse, je suis régulièrement confronté à un problème de choix d'itinéraire. N'ayant qu'un amour modéré pour les côtes, et une haine, qui n'a d'égal que ma haine du café américain, pour les dépenses inutiles, comme par exemple monter pour redescendre alors qu'un détour minime permet d'éviter cette aberration, un choix de l'itinéraire basé uniquement sur la distance me paraît une absurdité comparable à celle d’apprécier la poutine.

    Il y a donc quelques années, mon Dieu que le temps passe vite, je me suis donc mis en tête de créer mon propre moteur de recherche d'itinéraire adapté à mes contraintes. Il est bien connu qu'on n'est servi de manière satisfaisante que par soi-même. En fait j'ai donc commencé à explorer, jouer avec les données, écrire du code, pour enfin obtenir un moteur de routage fonctionnel il y a environ un an et demi. Ce fut l'objet de mon précédent journal, et les choses ont peu évolué au niveau de ce moteur, principalement de la correction de bugs, un peu de réorganisation, et quelques nouvelles fonctionnalités. Rien de bien important. Puis n'ayant pas réussi à recruter de développeur de frontend, j'ai écrit une interface minimaliste et moche, pour montrer les possibilités du moteur.

    Je vais donc présenter, ici, de manière détaillée, mon moteur de routage, l'interface minimaliste et moche, et surtout lancer un appel à développeurs pour une interface non minimaliste et potentiellement non moche. Puis je vous présenterai les futures améliorations que je prévois d'apporter au moteur de routage, dans un avenir proche à lointain.

    rv, le moteur de routage

    Le moteur de routage se nomme rv. La seule raison profonde à ce nommage est mon incapacité à trouver des noms intéressants à mes projets. J'ai donc commencé par nommer mon dossier où je codais routage_velo, mais comme c'était trop long, je l'ai par la suite raccourci en rv. Le code du moteur de routage est disponible sur mon répo git. Si vous n'êtes intéressé que par l'utilisation du moteur de routage ou que par l’interfaçage, je vous conseille de sauter cette partie.

    Données

    Présentation des données

    Pour faire du routage, il me faut des données. Ainsi j'utilise deux types de données. Le premier est constitué de données cartographiques, instrument indispensable à du routage sur une carte. Je ne vous ferai pas l'affront de vous présenter de manière détaillée, en particulier parce que j'en suis incapable, le projet OpenStreetMap, dont l'objectif principal est de fournir une cartographie mondiale sous licence libre ODbL.

    Le second type de données est constitué des données altimétriques, puisque pour faire un routage en fonction de l'altitude, il me faut des données cartographiques avec des étiquettes altimétriques sur les points, informations que OpenStreetMap ne fournit pas. Pour ce faire j'utilise les données du projet SRTM de la NASA qui fournit pour l'ensemble du globe entre 60° et -60° de latitude des données altimétriques avec une précision au mètre suivant une grille de 3 secondes d'angle.

    Travail sur les données

    J'importe les données dans une base de donnée PostgreSQL avec les extensions PostGIS. Pour l'import des données cartographiques, j'utilise l'outil Osmosis, bien connu des utilisateurs d'OSM, et le schéma de base utilisé est pgsnapshot, tel que définit par Osmosis.

    Seules les données concernant des routes utilisables par les vélocipèdistes sont recopiées dans des tables personnelles, les tables du schéma pgsnapshot étant laissées intactes. En particulier, cela signifie que le moteur de routage peut cohabiter sur une même base de données utilisant le schéma pgsnapshot.

    J'importe également les données SRTM dans la base de données via un programme perso (fournit dans mon répo git). Certaines données sont manquantes (c'est assez rare), pour compléter les points manquants de la grille, j'utilise un algorithme des plus proches voisins une fois que ma grille est complète, je calcule l'altitude des nœuds fournit par OpenStreetMap via une interpolation bilinéaire. Cette étape est entièrement réalisée à l'aide de procédures postgres (plpgsql et plperl).

    La difficulté suivante sur les données se situe au niveau de la connexité. En effet, le graphe routier est constitué de plusieurs composantes connexes. Si certaines sont légitimes (comme celles représentant des îles non reliées au continent), certaines ne le sont pas (un parking que l'on a oublié de relier au monde extérieur). Il se trouve que si un utilisateur demande un routage entre deux composante connexe, celui-ci ne peut aboutir, et conduit l'algorithme, si il ne le sait pas, à explorer tout le graphe, ce qui est énorme et inutile. Ainsi les composantes connexes sont calculés et les nœuds sont étiquetés en fonction de leur composante connexe d'appartenance. Ainsi quand un utilisateur demande un routage entre deux points géographique, l'algorithme peut essayer de choisir les nœuds de départ et d'arrivée de telle sorte qu'ils soient sur la même composante connexe (dans l'exemple du parking, on projettera sur la route adjacente) si possible, et échouer avec un message d'erreur immédiatement si ça ne l'est pas (dans le cas d'un routage entre une île isolée et le continent par exemple). Ce calcul est entièrement effectué à l'aide d'une procédure postgres en plpgsql lors de l'import ou de la mise à jour des tables utilisées par le moteur de routage.

    Routage

    L'idée du routage est de minimiser un critère. Pour ce faire trois critères sont proposés :

    • Distance parcouru par le vélocipède

    • Dénivelé positif cumulé sur le trajet

    • Énergie dépensée par le vélocipédiste.

    Si vous avez bien suivi mon raisonnement et mon objectif, vous comprendrez que seul le troisième critère m'intéresse, le premier étant l'équivalent d'un routage bête et méchant, ne prenant pas en compte l'altitude, et le second correspondant à une recherche à tout prix d'évitement des côtes, même si cela implique un détour complètement absurde. Seul l'énergie dépensée par le cycliste prends en compte l'altitude et la distance parcourue, c'est un vrai compromis. Nous le savons tous, la solution se situe toujours dans le compromis, sauf vis-à-vis de la sanction appropriée concernant les amateurs de poutine.

    Toutefois j'ai implémenté dans mon routeur de routage les trois critères, principalement car cela permet de comparer le critère que je propose aux critères simplistes communément acceptés, et aussi car cela se faisait à moindre coût dans l'architecture du code. Dans la suite, je ne vais toutefois détailler que le modèle lié à l'énergie, le calcul de la distance ou du dénivelé positif ne nécessitant pas d'explications.

    Modèle physique pour le calcul de l'énergie

    Pour calculer l'énergie dépensée sur un trajet, j'ai utilisé un modèle physique, et j'ai utilisé les loi de la mécanique (du point). Il y a certaines hypothèses qu'il est nécessaire d'expliquer. Pour une vision en détail du modèle je vous conseille la lecture de mon précédent journal. Les hypothèses principales sont les suivantes.

    • L'animal fournit une puissance constante. Je considère que le cycliste sait se servir de ses vitesses, et les utilise de manière à fournir une puissance constante, que ça soit en côte ou en descente.

    • L'ensemble du cavalier et de sa monture est soumis à la pesanteur. C'est très important, c'est ce qui va faire varier l'énergie totale en fonction du relief.

    • Le cycle, et l'imbécile flanqué dessus, sont soumis à une résistance de l'air. La résistance est proportionnelle au carré de la vitesse relative par rapport à l'air. Vous pouvez trouver des infos sympa sur ce type de résistance ici.

    • Le vélocipède est soumis à une résistance au roulement. Cela provient de la déformation des pneus sur le sol. Cela dépend du type de sol, du type de pneu. Toutes choses égales par ailleurs, cette résistance est considérée comme proportionnelle au poids (je parle bien du poids de l'ensemble et non de la masse).

    • Il n'y a aucune perte d'énergie dans les virages. Cette hypothèse est fausse dans le cas où le cycliste est obligé de freiner à cause du rayon de courbure trop faible du virage par rapport à sa vitesse. Toutefois, c'est une hypothèse très utile pour le calcul.

    • Il n'y a aucun arrêt. Ce qu'il faut comprendre c'est que le cycliste ne s'arrête ni au feu, ni au stop.

    Certaines hypothèses peuvent paraître osées, c'est vrai, mais il faut dire qu'elles n'ont que peu d'influence sur le résultat final.

    Pour valider les hypothèses de résistance de l'air et résistance au roulement, j'ai fait des essais en descente avec un traceur GPS sur ma bicyclette sans fournir de puissance, et je peux affirmer avec confiance que ces hypothèses sont justifiées.

    Le modèle a donc plusieurs paramètres qui sont :

    • La masse roulante (bicyclette, animal, fret), elle influe sur l'inertie de l'ensemble en mouvement, sur le poids, et sur la résistance au roulement.

    • La vitesse sur le plat (qui, connaissant les autres paramètres sert à calculer la puissance constante à considérer)

    • La surface apparente et le coefficient de pénétration dans l'air (S.Cx) qui permet de calculer la résistance de l'air. Ce paramètre dépend principalement de la position du sportif sur son instrument de torture, mais peut aussi dépendre d'éléments extérieurs comme les sacoches ou un carénage tel qu'on voit dans les contre-la-montre.

    • Le coefficient de roulement. Il permet de calculer la résistance au roulement. Ce paramètre dépend principalement du type de pneu utilisé et du gonflage. Il est aussi influencé par le type de sol, mais il est supposé constant sur tout le trajet.

    • Le vent additionnel (vitesse et direction). À la discrétion de l'utilisateur pour prendre en compte un vent permanent et orienté dans le calcul du routage. Son influence est forte sur la valeur de l’énergie, mais faible sur le choix de l'itinéraire.

    Algorithme de routage

    Pour effectuer le routage dans un graphe, la première chose à quoi nous pensons est l'algorithme de Dijkstra. Toutefois cet algorithme est clairement lent, et je lui ai donc préféré l'algorithme A*, outre le fait d'être plus rapide, et d'être plus facile à orthographier, sous certaines conditions, l'algorithme A* est optimal de la même manière que l'algorithme de Dijkstra l'est.

    Pour résumer, l'algorithme A* et l'algorithme de Dijkstra consistent à explorer les voisins des nœuds connus en partant du nœud de départ. La différence c'est que l'algorithme A* va utiliser une heuristique qui estime le critère entre le nœud courant et le nœud d'arrivée pour choisir l'ordre d'exploration, et s'arrêter quand il aura exploré le nœud d'arrivé. Dans le cas général l'algorithme A* ne donne pas le résultat optimal. Toutefois si l'heuristique utilisée est admissible, c'est à dire si elle est une borne inférieur du critère, alors l'algorithme A* est optimal. Attention toutefois à avoir une heuristique informative, par exemple, prendre comme heuristique une fonction qui nous retourne 0, nous donne une heuristique admissible, mais dans ce cas cela revient à utiliser un algorithme de Dijkstra (à tous les niveaux dont au niveau temps).

    Dans mon cas, on peut pour chacun des critères avoir une heuristique admissible (et informative). Dans le cas de la distance, la distance à vol d'oiseau à l'arrivée est une minoration de la distance sur le graphe. Dans le cas du dénivelé positif cumulé, la partie positive de la différence d'altitude à l'arrivée est une minoration du critère (mais guère informative dans nombre de cas il faut l'avouer). Dans le cas de l’énergie, l’énergie dépensée sur un trajet en ligne droite à pente constante à l'arrivée sans prendre en compte la résistance de l'air (qui dépend de la vitesse que l'ont ne peut pas minorer, excepté par 0), est une minoration du critère.

    Au final, j'ai donc un algorithme, pas trop lent, et exact, pour choisir un itinéraire.

    Programme

    Le programme de routage est écrit en C++. Il fonctionne bien sous GNU/Linux. Il n'a pas été testé sur d'autres plate-formes.

    Pour lancer le routage, il faut écrire dans la base de donnée les paramètres, les points de départ, d'arrivé et les points de passage. Un job id est attribué par la base. Il faut ensuite lancer l'exécutable avec comme argument la chaîne de connexion à la base et le job id. Le programme lit les paramètres, lance l'algorithme de routage, écrit au fur et à mesure dans la base une estimation de l'avancement (ce n'est qu'une estimation, il n'est pas possible de prévoir le nombre de nœuds à parcourir à l'avance) et quand il a terminé écrit dans la base le résultat et termine.

    Dans les versions précédentes, il prenait ses arguments sur l'entrée standard et retournait avancement et résultat sur sa sortie standard, ceci a été modifié afin de permettre facilement un interfaçage à l'aide de scripts python.

    Interface web

    C'est là où les choses se gâtent. J'ai été pendant quelques temps satisfait de mon programme de routage, qui s'utilisait en ligne de commande. Même si guère pratique, ceci était suffisant pour mon usage, il apparaissait de manière assez évidente que ceci n'était pas satisfaisant pour l'usage général des utilisateurs de bicyclette.

    Non que j'accuse les vélocipèdistes d'être bêtes, même personnellement si j'affectionne les programmes en ligne de commande, il faut avouer que pour un usage cartographique, la ligne de commande ne semble pas ce qu'il y a de plus approprié.

    J'ai donc envisagé de greffer une interface au moteur de routage rv. Le fait que le moteur de routage demande d'avoir de manière accessible une base de données, implique qu'il est difficile de faire une interface sur un poste client pour un usage autonome, à moins d'installer en même temps la base de données et d'importer toutes les données nécessaires au routage. Il semble donc immédiat qu'une interface web est la solution adaptée, même si à titre personnel je ne suis pas satisfait du fait que de plus en plus d'outils se déplacent vers le web, induisant ainsi une dépendance et une difficulté d'usage déconnecté, je dois reconnaître qu'en l'espèce cela semble approprié.

    Dans mon précédent journal, j'ai lancé un appel à contribution, et même si j'ai eu des retours enthousiastes vis-à-vis du projet (qui m'ont fait très plaisir par ailleurs), je n'ai pas eu de volontaires pour le développement d'une interface web. La vie est triste.

    Précisons que ce n'est pas forcement facile de développer une interface web sur un moteur qu'on n'a pas concu et quand on ne voit pas exactement le but recherché, je me suis donc attelé à développer moi-même une interface web, de démonstration, pour montrer les possibilités du moteur, et l'idée générale. L'interface web que j'ai développée est donc une interface de démonstration, elle n'a pas vocation à rester, elle sert juste à montrer ce que fait le moteur de routage, et permet un usage minimaliste d'icelui.

    Comme d'habitude, je ne sais pas nommer mes projet, j'ai donc profité d'une similarité phonétique entre rv et le prénom hervé pour choisir le nom de mon interface, je l'ai donc nomée hervé. Vous avez le droit d'être affligés, je le suis aussi. Le nom étant trouvé, j'ai fait du développement web, cela faisait depuis 2005 que je n'avais pas fait de html et de javascript, je n'aimais pas cela, et cela n'a fait que ancrer mon opinion.

    Je n'ai pas dit que le développement web est mal, c'est juste que ce n'est pas ce que j'ai envie de faire, et comme c'est un projet que je fais sur mon temps libre, vous comprendrez très bien que je me concentre sur ce que j'ai envie de faire au détriment de ce qui m’horripile. C'est donc de l'html et du javascript pour l'interface client, avec utilisation de leaflet pour jouer avec les cartes, et c'est du python au niveau du serveur.

    L'interface de démonstration est accessible ici: Herve, limité au niveau de la France Métropolitaine. Cette interface est très moche, mais elle permet de montrer les fonctionnalités du moteur de routage. Cette instance est hébergée sur un serveur de test d'OpenStreetMap France, elle est volontairement limitée en ressource. C'est donc lent, et il y a un nombre de routage simultanés faible. De plus si vous avez la malchance d'accéder à l'interface alors que la base de données est froide, lent n'est plus le mot approprié, c'est pire. Cette interface refuse également de calculer des trajets d'une distance supérieure à 100 km à vol d'oiseau.

    Je vous invite à tester quelques trajets, et à vous amuser un peu. Pour une petite démonstration, sur la ville de Poitiers, dont le centre-ville est sur une colline, pour aller du bas de la colline au bas de la colline à l'opposé de la ville, voici deux résultats, montrant l'importance de la prise en compte de l'altitude dans le choix de l'itinéraire :

    On remarquera que Google Maps par exemple nous donne à peu près le même résultat que l'optimisation de la distance. Pour avoir vécu quelques années à Poitiers, le trajet que je préfère, et de loin, est celui résultant de l'optimisation de l'énergie.

    Documentation et code

    Tout le code du moteur, les scripts pour récupérer les données, et l'interface web est disponible sur mon répo git.

    Le répo git contient aussi la documentation (en français) sur comment se servir du tout. J'ai essayé de la faire aussi détaillée que possible, mais je doute que j'y sois complètement parvenu.

    Avenir et appel à contribution

    J'ai plusieurs rêves, et plusieurs envies.

    Interface web et API web

    J'aimerai en faire un service accessible à tout un chacun, via une interface web. Pour cela il me faudrait un ou des volontaires pour développer une vraie interface au moteur de routage, je serais bien entendu là, prêt à adapter le moteur au besoin, et à fournir toutes les explications nécessaires.

    Il est aussi envisageable de développer une API pour par exemple une utilisation via une appli de smartphone. Je n'utilise pas de smartphone, ça ne m'intéresse pas, je n'y connais rien, mais si quelqu'un est intéressé, je ne suis pas contre, même si l'interface web me paraît prioritaire.

    Il faudra aussi probablement voir du côté d'où héberger l'infrastructure. Jusqu'à maintenant l'infrastructure de test a été fournie par OpenStreetMap France, il est possible qu'ils soient volontaires pour fournir l'infrastructure.

    Moteur

    J'ai aussi plusieurs projets pour le moteur de routage

    • Abolir la règle puissance constante à vitesse élevée. C'est à dire permettre que l'utilisateur fournisse une information comme à partir de cette vitesse j'arrête de pédaler, et à partir de cette vitesse je freine. (Pour un souci de cohérence la seconde devra être supérieure à la première.)

    • Ajouter une notion d'accélération latérale maximum, ce qui implique de limiter la vitesse de passage dans un virage en fonction de son rayon de courbure. J'avais échoué par le passé à avoir quelque chose qui ne faisait pas n'importe quoi, mais j'ai réussi à tester une méthode d'approche du rayon de courbure qui donnait des résultats cohérents avec mes traces GPS (dès que je veux modifier mon modèle, j’essaie de le valider par un essai réel avec trace GPS)

    • Tenir compte du type de sol, et faire bouger le coefficient de roulement en fonction des tags OSM

    Documentation

    J'aimerais internationaliser le projet. Même si je n'ai pas de mal à écrire en anglais, j'ai rédigé la documentation en français (car j'ai plus de plaisir à écrire en français). Toutefois c'est une erreur, et je pense traduire la documentation en anglais. Bien entendu si quelqu'un veut la traduire, je profiterai du temps libéré pour faire autre chose, et j'accepterai donc avec plaisir cette contribution.

    Une fois que la documentation sera traduite, je pense supprimer la version française, déjà que c'est dur de garder la documentation à jour, si elle est présente dans les deux langues, c'est un coup à échouer.

    En bref

    • J'ai développé un moteur de routage basé sur l'énergie pour les vélocipèdistes utilisant les données d'OSM et SRTM, et j'ai encore des projets d'amélioration du moteur de routage.

    • Je propose une interface de démonstration, et je recherche des gens pour développer une vraie interface web. Au niveau licence, je demande juste une licence approuvée par l'OSI.

    • Le code et la documentation sont disponible sur un répo git. Tout est disponible sous licence BSD-2.

    • L'infrastructure jusqu'à maintenant à été fournie par OpenStreetMap France que je remercie vivement. Si vous avez envie de financièrement soutenir ce projet, c'est à OpenStreetMap France qu'il faut donner, c'est par ici.

    • Pour me contacter, vous pouvez répondre à ce journal, m'envoyer un courrier électronique (vous trouvez mon adresse dans les commits du répo git), ou encore venir me voir sur irc, je fréquente le salon #osm-fr sur oftc.

    Lire les commentaires

  • Gasoline 0.1, cadriciel applicatif pour OCaml (Journaux LinuxFR)

    Le projet Gasoline vise à implépementer un cadriciel pour le
    développement d'applications de type Unix avec OCaml. Il est
    distribué sous licence CeCILL-B.

    Les utilisateurs de Gasoline pourront:

    • Rapidement développer des applications types en utilisant des
      patrons d'application comme “filtre Unix” ou “compilateur”.

    • Écrire des application acquerrant leurs
      paramètres de configuration
      de sources variées, comme la ligne de commande, l'environnement ou
      des fichiers de configuration.

    • Écrire des applications organisées autour de
      composants logiciels
      aux responsabilités bien délimitées.

    • Amorcer et terminer facilement des applications complexes grâce à la
      gestion des dépendances pour les composants logiciels.

    • Émettre et filtrer des
      messages de diagnostic
      avec un granularité basée sur les composants logiciels.

    Liens

    Installation

    La procédure d'installation est décrite dans le fichier README du
    projet. Elle s'appuie sur BSD Make (souvent nommé bmake) et BSD
    Owl
    . Ma branche
    OPAM

    contient un package [gasoline] permettant l'installation de Gasoline.
    La procédure d'installation a été testée sous FreeBSD 10.0, Debian
    Jessie et Mac OS X.

    Qu'est-ce qu'un patron d'application

    Pour prendre un exemple simple et bien connu, l'écriture d'un filtre
    Unix devrait essentiellement se résumer à la préparation d'une
    fonction filter

    val filter : parameter -> in_channel -> out_channel -> unit

    implémentant le traitement réalisé par le filtre — parameter est le
    type fictif des paramètres contrôlant le filtre.

    Un patron d'application devrait prendre en charge les tâches
    d'intendance, comme l'initialisation des composants logiciels et
    l'acqusition des paramètres de configuration.

    Plusieurs patrons d'application sont prévus pour la version
    0.3.

    Exemples de programmes utilisant Gasoline

    Le dossier
    example
    contient trois exemples de programmes.

    Le programme
    punishment
    écrit 100 fois sur sa sortie standard la phrase

    I must not talk in class
    

    Il illustre la définition de paramètres de configuration et
    l'acquisition des paramètres de configuration depuis des sources
    variées.

    Le programme
    wordcount
    est une version à l'organisation sur-développée du classique programme
    wc(1). Il illustre l'utilisation de composants logiciels dans un
    exemple minimal et très petit.

    Le programme
    wordgen
    analyse une liste de mots et génère des mots supplémentaires ayant les
    mêmes caractéristiques. Le dossier de l'exemple contient une liste
    tolkien.text rassemblant une liste de noms provenant des œuvres de
    Tolkien. Pour générer des mots semblables, on analyse cette liste avec

    ./wordgen -d . -C tolkien.text

    puis on demande la génération de, disons, 16 mots, avec

    ./wordgen -d . -G tolkien.text -n 16
    galdal
    arathlor
    mirmilothor
    eoron
    echalad
    aerecthilmin
    foros
    erion
    cuarveranwen
    tiladhruil
    brint
    luindor
    marin
    sulkoron
    halia
    nengirhuri

    L'option -d spécifie le dossier qui doit être utilisé comme
    bibliothèque de listes de mots.

    Conclusion

    Vos commentaires, remarques, idées et bien-sûr vos contributions, sont
    les bienvenus!

    Lire les commentaires

  • FreshRSS, 2 ans et tout va bien. (Journaux LinuxFR)

    Sommaire

    Cher journal,

    Je sais que je ne t'écris pas souvent et que quand je le fais c'est pour te parler de FreshRSS, mais aujourd'hui c'est l'anniversaire du projet et je trouvais ça chouette de faire un petit bilan un an après le dernier. Cette fois-ci j'essaierai d'être plus succinct que la dernière fois mais je ne te garantis rien.

    Avant de partir à l'aventure de mon journal, je tiens à te rappeler que FreshRSS est un agrégateur et lecteur de flux RSS que tu peux héberger sur ton propre serveur si tu n'as pas peur de le tacher avec des traces de PHP. <instant promotion>Bien plus léger que le lourdeau TinyTinyRSS, plus puissant qu'un Selfoss titubant, plus dynamique que Leed ou Kriss Feed ; FreshRSS est la solution idéale pour suivre l'actualité !</instant promotion>

    Logo de FreshRSS

    Courte synthèse : retour en 2013.

    Histoire de comprendre encore mieux le chemin que j'ai parcouru en un an, je te propose de revoir rapidement ce que j'avais raconté dans mon journal de l'année dernière.

    • Alors que j'étais parti sur un projet développé en suivant la fameuse méthode Rache, j'ai vite découvert ses limites et sauté de la version 1.0-alpha a une plus modeste 0.1.
    • J'expliquais qu'avant de développer pour les autres, je me focalisais sur mes propres besoins. Un logiciel qui n'est pas utilisé par son développeur risque de foncer plus facilement dans le mur. Et comme je suis du genre pointilleux, je passe mon temps à régler les petits problèmes que les autres ne voient généralement pas.
    • Ma motivation avait pris un sacré coup et je n'y pouvais rien car ce n'est pas forcément quelque chose que l'on peut changer facilement. Heureusement un contributeur (Alkarex) avait alors commencé à prendre le relais pour les évolutions importantes.
    • Je pensais communiquer suffisamment sur le projet mais uniquement en français, ce que j'estimais limiter la portée de mes messages.
    • J'expliquais aussi que j'avais abandonné l'idée de tout développer de zéro.
    • Je concluais enfin en expliquant que FreshRSS était le projet que j'avais le plus à cœur, qu'il m'avait permis de créer ma première « communauté » et qu'il répondait à mon envie de créer des choses utiles pour les autres.

    Et aujourd'hui, qu'est-ce qui a changé ?

    Je n'ai pas été très actif durant le début de l'année jusqu'à juin et FreshRSS évoluait principalement grâce aux autres contributeurs. Depuis septembre, j'ai terminé mes études ainsi que mon contrat d'apprentissage et j'ai débuté ma période de chômage avec joie. Comme une version 1.0 est prévue pour la fin de l'année (ah ah ! Non, les délais ne sont pas tenables), le projet a pas mal évolué ces derniers temps. Petit tour des évolutions :

    • Les fonctionnalités : mode multi-utilisateurs, API (compatible Google Reader), différents thèmes (dont de magnifiques contributions externes), statistiques, support de SQLite en plus de MySQL/MariaDB, système de mise à jour automatique, etc. Nombre d'entre elles sont encore en train de grandir mais on peut dire que FreshRSS fait partie des lecteurs proposant le plus de fonctionnalités.
    • La maturité : un an de plus au compteur et de nombreux nouveaux utilisateurs satisfaits (disons-le !) me permettent d'affirmer que FreshRSS est relativement stable. Le système de mises à jour régulières que j'ai mis en place à la mi-juin semble être plutôt bien apprécié : les versions les plus stables (branche master) sortent lorsqu'elles sont prêtes tandis que des versions bêta sortent tous les mois pour les personnes en soif de nouveautés. Pour les plus impatients, la branche de développement est là malgré mes nombreuses mises en garde pour ne pas l'utiliser.
    • La qualité : j'ai entrepris depuis un mois de revoir l'ensemble du code pour stabiliser et séparer les morceaux qui ne me semblaient pas suffisamment bien écrits. Cela a conduit à la réécriture de fichiers entiers pour rendre le code plus lisible. Des commentaires ont été ajoutés au fur et à mesure de ce travail. La faiblesse réside encore aujourd'hui dans le manque de tests, mais un ticket est ouvert et je devrais me pencher dessus dans peu de temps.
    • La notoriété : forçant un peu plus sur la communication depuis les deux derniers mois, je vois aujourd'hui assez facilement les effets bénéfiques. Entre l'évocation de FreshRSS dans de plus en plus de billets de blogs francophones, la mention sur degooglisons-internet.org, le passage sur opensource.com et le tweet de nixCraft (plus de 34 000 abonnés), mes statistiques explosent… et c'est sans doute le plus enthousiasmant ces derniers jours.

    Screenshot de FreshRSS avec le thème Screwdriver
    Le thème Screwdriver écrit par Mister aiR anime la démo !

    Quelques leçons apprises pour réussir.

    Coder régulièrement.

    Le nerf de la guerre, c'est le développement ! Que ce soit un ou deux commits de temps en temps, ça montre aux autres que vous n'avez pas abandonné. Ça rassure sur la pérennité du projet. Ça fait deux ans que je développe FreshRSS et il n'y a jamais eu de grosse période sans nouveau code. Vous me direz qu'il n'est pas toujours facile de trouver le temps ou la motivation de coder et je n'ai pas de solution miracle à cela. Pour ma part, je sais que la motivation me revient quand je lance mon environnement de travail et que je commence à voir les effets de mes premières lignes de code. Pour repartir vite après une période de pause il vaut donc mieux se garder quelques tâches faciles et amusantes sous la main. Pour le temps à consacrer à mon projet… et bien j'en ai un bon paquet étant au chômage.

    Mettre en avant son travail est important et c'est pourquoi j'ai décidé de sortir des versions bêta de FreshRSS tous les mois. C'est ma manière à moi de dire « Coucou, le projet continue de vivre, venez tester les dernières nouveautés ! ». La branche bêta étant celle mise en avant sur le dépôt Github, le visiteur voit rapidement que je continue de travailler dessus. Rendez-vous vendredi prochain pour la prochaine bêta !

    Faire vivre son projet.

    Il y a un an, je pensais communiquer suffisamment. Mais c'est mal connaître les utilisateurs qui sont toujours friands de nouveautés. Pour cela j'ai commencé à parler au jour le jour des dernières avancées sur Diaspora*. Comme il existe une petite communauté d'utilisateurs sur le réseau, je maintiens de cette façon un certain niveau de curiosité pour le projet.

    De plus j'ai élargi mon public à la population anglophone qui est loin d'être négligeable. Cela passe par l'ensemble des commits et tickets que je rédige désormais en anglais, la page sur alternative.to et le site officiel rédigé en anglais. Pour ce qui est des annonces des sorties de versions, celles-ci se font encore en français car cela me demanderait trop de temps à accorder à leur rédaction. Enfin, j'ai ouvert un compte Twitter. Je ne sais pas encore trop si je vais l'utiliser mais il me permet au moins de répondre aux personnes qui ne sont pas sur Diaspora*.

    Interagir avec les personnes qui parlent de FreshRSS est primordial pour moi : mails, articles, réseaux sociaux, tout y passe ! J'essaye toujours de laisser un petit mot, ne serait-ce que pour remercier. Je veux montrer que la personne derrière tout ça est un humain comme tout le monde et que je suis même sympa ! :) Et à ceux qui ne connaissent pas encore, je les invite bien cordialement à venir essayer la version de démonstration. Si FreshRSS ne leur convient pas, je n'hésite pas à les rediriger vers d'autres projets comme Leed ou Kriss Feed.

    Donner un coup de main aux autres projets.

    Pour terminer ce long journal, la dernière leçon que j'ai apprise, c'est qu'il ne faut pas hésiter à donner un petit coup de main aux autres. Ainsi que ce soit Leed, Kriss Feed ou le petit dernier (mais prometteur) Freeder, je n'hésite pas à commenter sur les problèmes auxquels j'ai déjà fait face. Je ne considère pas être en compétition avec ces derniers mais plutôt comme un projet complémentaire et je trouve idiot de garder une information si je la possède et qu'elle peut leur être bénéfique. C'est aussi un geste d'ouverture et d’honnêteté de ma part qui bénéficie aussi à mon travail.

    Petite conclusion d'un journal déjà bien trop long.

    Si j'ai débuté FreshRSS comme un projet personnel sans aucune prétention, cette année aura vu la professionnalisation de mon logiciel avec des considérations tant au niveau de la qualité que de la communication. Parfois il m'arrive de me demander si je ne perds pas mon temps à m'obstiner sur ce logiciel : je me souviens de la blague d'un collègue « Si à 20 ans tu n'as pas codé ton agrégateur de flux RSS c'est que tu as raté ta vie ». Au final j'en arrive toujours à la conclusion que je fais ce qu'il me plaît, que ça m'amuse et que ça fera toujours une belle entrée sur mon CV. La visibilité acquise ces derniers mois me conforte dans mes choix.

    Si aujourd'hui j'ai envie de passer à autre chose, je n'ai pas envie de bâcler le travail (preuve en est l'attention portée ces derniers jours à la qualité du code). D'ici la fin de l'année j'espère avoir une version suffisamment aboutie pour que je puisse lui attribuer le numéro de version 1.0… Et ensuite ? Ensuite je ne sais pas si je continuerai à développer activement pour FreshRSS, je ne pense pas. Pour cette raison, je commence à me poser la question de la continuité du logiciel… mais je n'y suis pas encore ;).

    Merci de m'avoir lu et à bientôt cher 'nal !

    Lire les commentaires

  • Ubuntu is dying (Journaux LinuxFR)

    Comme vous le savez sans doute, la distribution pour neuneu^W^Wphare du monde du libre^W^W^W^W^Wdérivée de Debian est sortie.

    Pour autant, peu de monde s'est encore motivé pour compléter la dépêche en rédaction https://linuxfr.org/redaction/news/sortie-d-ubuntu-14-10 à croire que les TMS atteignent nos amis ubuntristes :/ (prompt rétablissement bersace< ! tu nous manques, visiblement).

    Ce n'est pas trop difficile d'y contribuer, comme cela était suggéré sur cette dépêche d'incitation à la participation en rédaction.

    Visiblement, c'est surtout la prochaine version qui intégrera une révolution du bureau sous Linux, 2015 l'année du bureau sous Linux ?

    Rha flûte, ce n'est déjà plus 'dredi et il y aura une heure de moins pour contribuer au libre ce week-end :/

    Note : ce journal contient des morceaux d'ironie pouvant choquer les plus sensibles, sa finalité est néanmoins d'inciter à la participation pour ceux se sentant motivés, bersace< a fixé la barre assez haute mais les dépêches noyaux ont bien trouvé leur pérennité, tout est donc possible !

    Lire les commentaires

  • fOSSa 2014, du 19 au 21 novembre 2014 à Rennes (Dépêches LinuxFR)

    Bonjour !

    Après une édition 2013 passionnée et intense en sujets innovants (open source journalism, open source vehicule, etc.), fOSSa (Free Open Source Software for Academia) revient en force pour une édition 2014 orientée vers les transitions en cours, leurs enjeux et le rôle de l'openness dans l'émergence de nouveaux écosystèmes.

    La 6e édition de fOSSa se tiendra à Rennes, les 19, 20 et 21 novembre prochain, au centre de recherche Inria Rennes-Bretagne Atlantique. Elle est organisée par l'Inria et la Fing, avec le soutien du FABLAB de Rennes et de La Cantine Numérique de Rennes. fOSSa est soutenu par Linux Mag et Programmez.com.

    fOSSa 2014, c'est :

    • trois jours intenses de conférences, de débats, d'ateliers et de rencontres participatives avec des experts internationaux ;
    • un lieu où les futures technologies ouvertes et leurs possibles impacts sur la société sont discutés, qu'il s'agisse d'open source, d'open hardware, d'open networks, et au-delà ;
    • des conférences thématiques (Monnaies complémentaires - The new hardware bazaar et Sciences participative) ;
    • des rendez-vous communautaires (tweetlunches, débat, Carrefour des possibles et un atelier de prospective organisé avec la Fing) ;
    • des démos (un village pour hacker).

    Retrouvez le programme de cette nouvelle édition sur https://fossa.inria.fr/program/. L'inscription est gratuite !

    Nous vous attendons nombreux et avec l'esprit et les yeux bien ouverts !

    Lire les commentaires

  • fOSSa 2014, Rennes, du 19 au 21 novembre 2014 (Dépêches LinuxFR)

    Bonjour !

    Après une édition 2013 passionnée et intense en sujets innovants (open source journalism, open source vehicule, etc.), fOSSa (Free Open Source Software for Academia) revient en force pour une édition 2014 orientée vers les transitions en cours, leurs enjeux et le rôle de l'openness dans l'émergence de nouveaux écosystèmes.

    La 6e édition de fOSSa se tiendra à Rennes, les 19, 20 et 21 novembre prochain, au centre de recherche Inria Rennes-Bretagne Atlantique. Elle est organisée par l'Inria et la Fing, avec le soutien du FABLAB de Rennes et de La Cantine Numérique de Rennes. fOSSa est soutenu par Linux Mag et Programmez.com.

    fOSSa 2014, c'est :

    • trois jours intenses de conférences, de débats, d'ateliers et de rencontres participatives avec des experts internationaux ;
    • un lieu où les futures technologies ouvertes et leurs possibles impacts sur la société sont discutés, qu'il s'agisse d'open source, d'open hardware, d'open networks, et au-delà ;
    • des conférences thématiques (Monnaies complémentaires - The new hardware bazaar et Sciences participative) ;
    • des rendez-vous communautaires (tweetlunches, débat, Carrefour des possibles et un atelier de prospective organisé avec la Fing) ;
    • des démos (un village pour hacker).

    Retrouvez le programme de cette nouvelle édition sur https://fossa.inria.fr/program/. L'inscription est gratuite !

    Nous vous attendons nombreux et avec l'esprit et les yeux bien ouverts !

    Lire les commentaires

  • Atelier CMS DRUPAL le 15 novembre à Puteaux - La Défense (Dépêches LinuxFR)

    L'association StarinuX vous convie à l'atelier : kickstart Hello Drupal

    Programme et objectif : apprenez à installer et gérer un site web CMS (Content Management System) sous Drupal, selon le niveau 1 "webmestre".

    • Animateur : Brice GATO, formateur officiel Drupal ;
    • Quand : 9h30 à 18h , samedi 15 novembre 2014 ;
    • Lieu : 80 rue Roques de Fillol 92800 Puteaux - La Défense ;
    • Métro : Esplanade de la Défense ;
    • Nombre maximum de places : 20 ;
    • Contact : events CHEZ starinux.org.

    Cet atelier est ouvert selon un soutien annuel de 20€ (10€ demandeurs d'emplois), valable pour plus de 15 ateliers.

    Préambule : Drupal possède trois niveaux de gestion

    1. webmaster (gérer un site Web),
    2. themer / integrator (intégrer des thèmes),
    3. contributor / publisher (développeur).

    Le niveau proposé de la journée Hello Drupal sera le niveau 1.

    Lire les commentaires

  • MicroAlg: langage et environnements pour l’algorithmique (Dépêches LinuxFR)

    Professeur de mathématiques et d’informatique, n’étant pas pleinement satisfait par les outils pédagogiques du moment, j’ai décidé de créer MicroAlg. Une des forces de MicroAlg est qu’il est utilisable dans un navigateur (voir la page d’accueil du site officiel ou la galerie).

    MicroAlg est un langage de programmation en « français » dédié à l’algorithmique et à son enseignement. Jeune (commencé fin mars 2014) et simple (des parenthèses pour seule syntaxe), il permet l’apprentissage des concepts les plus importants de l’algorithmique et de la programmation impérative.

    La licence retenue est la GPL2. Des bibliothèques sont sous MIT, LGPLv3, BSD et Apache2. Le site est sous CC By Sa 3.0.

    Exemple :

    (Afficher "Quel âge as-tu ?")
    (Si (< (Nombre (Demander)) 18)
     Alors (Afficher "Tu es mineur.")
     Sinon (Afficher "Tu prétends être majeur.")
    )

    Avis aux testeurs et aux contributeurs !

    Lire les commentaires

  • Open World Forum 2014, c'est le 30 et 31 octobre prochains #OWF14 (Dépêches LinuxFR)

    La semaine prochaine, les 30 et 31 octobre, aura lieu l'Open World Forum (aka OWF) à l'Eurosite Georges V à Paris ! Si vous ne connaissez pas encore l'OWF, c'est un événement annuel non commercial sur le Libre et l'Open Source qui est désormais dans sa 7ème année. Sa spécificité est d'être un des rares forums à regrouper sur les mêmes sujets les costumes-cravates et les jeans-t-shirt au travers de trois univers : Think / Code / Experiment.

    • Think : regroupe les sujets plus stratégiques, vision long terme, permet les échanges de points de vue sur les politiques publiques, l'innovation collaborative, l'éducation, l'emploi, les communautés, les femmes du numérique, etc.
    • Code : échanges et conférences plus techniques. Du concret ! Show me the code !
    • Experiment : le grand public est appelé à « toucher » le libre, qu'il soit matériel ou logiciel. C'est le royaume du DIY, des objets connectés du quotidien, des fablabs, etc.

    L'accès est gratuit même si l'inscription est requise.

    image OWF13

    Cette année encore le programme est riche et traverse les aspects business avec, notamment :

    mais aussi les aspects plus technologiques avec des moments forts sur :

    pour arriver aux usages grand publics, avec :

    Un des temps forts de l'édition de cette année sera le lancement du projet « Open Law » porté par l’Open World Forum, la Direction de l’Information Légale et Administrative (DILA), le Numa et Etablab. En réunissant les acteurs du monde juridique, ce projet permettra de réfléchir au droit dans notre société numérique tout en essayant de créer une communauté d'hackers du droit.

    La Student DemoCup sera un autre temps fort où les étudiants ayant proposé des projets pourront les présenter à un auditoire de l'écosystème. Le jury sélectionnera les meilleurs projets en lien avec l'écosystème du Libre qui se verront attribuer un prix.

    Tout cela agrémenté de sujets plus techniques tels que le Big Data, les outils du Cloud et du DevOps, PostgreSQL, Xen, le logiciel libre dans la téléphonie, les outils de déploiement tels que Rudder, les outils de suivi de code, etc.

    Deux sujets qui me tiennent particulièrement à cœur ont aussi leur tracks et conférences dédiées :

    LinuxFr.org est d'ailleurs très impliqué dans cette édition. Le président et son vice président sur la partie code sont aussi deux administrateurs de longue date du site ! Certains pourraient y voir une sorte d'entrisme ;-) Quoi qu'il en soit, nous vous attendons nombreux. Que vous soyez plutôt web et/ou big data, embedded et/ou cloud, vous trouverez forcément votre intérêt parmi les plus de 150 conférences, ateliers et tables rondes proposées.

    Lire les commentaires

  • Concours de programmation CodinGame le 25 Octobre 2014 (Dépêches LinuxFR)

    Le prochain challenge de code en ligne proposé par CodinGame aura lieu le samedi 25 octobre 2014 à 18h (heure de Paris).

    Titre de l'image

    L'événement accueillera des développeurs du monde entier pour leur permettre de passer un bon moment, défier leurs pairs, gagner des prix (iPhone 6 Plus, Robot "JD" de EZ-Robot) ou entrer en contact avec des sociétés qui leur plaisent et qui recrutent.

    Le thème de cette édition est « Don't Panic », autour du thème d'H2G2.

    L'objectif du challenge : résoudre deux problèmes de programmation dans le langage de son choix parmi les 20 proposés (C/C++, C#, Java, Javascript, PHP, Python, Python 3, Perl, Go, Dart, Scala, Haskell, Objective-C, Pascal, Ruby, Bash, Groovy, Clojure, VB.NET). La durée moyenne estimée de l'épreuve est de 2h30.

    Modalités de participation : c'est en ligne, c'est gratuit, et c'est anonyme pour ceux qui ne souhaitent pas communiquer leurs coordonnées. L’environnement de développement proposé donne accès à un éditeur de code et un shell Bash, pour lancer son programme depuis le navigateur.

    Lire les commentaires

  • Intel leader sur tablettes Android ! Mon oeil ! (Journaux LinuxFR)

    Désinformation volontaire ou involontaire ? Faiblesse éditoriale ? ou manipulation de l'information ?

    Plusieurs articles parus début octobre annoncent que les processeurs Intel sont leaders sur les tablettes Android, et que Intel n'a que Apple devant lui sur le marché des tablettes.

    Exemple: "Intel domine le secteur des processeurs pour tablettes Android !"
    Au delà d'une grosse contre-vérité : "l’entrée de gamme [des tablettes Android] où les processeurs Intel dominent très largement.", l'article s'appuie sur une étude de Strategy Analytics qui attribue à Apple 26% de part du marché des processeurs sur les tablettes, suivi de Intel 19%, puis Qualcomm 17%.

    Même constat sur PCWorld.fr: "Tablettes : Intel n'a plus qu'Apple devant lui", idem sur ZDNet.fr, le Comptoir du Hardware,…

    Pourtant, la réalité est tout autre si on prend la peine de lire le résumé de l'étude en question:
    "According to this Strategy Analytics report, Apple, Intel, Qualcomm, MediaTek and Samsung captured the top-five tablet AP revenue share spots in Q2 2014"

    En clair, Intel a réalisé 19% des revenus sur les processeurs des tablettes, ce qui ne veut absolument pas dire que 19% des tablettes vendues avaient un processeur Intel.

    Toujours d'après Strategy Analytics, au 2ème trimestre 2014, les parts de marchés sur les tablettes vendues sont:
    Android 70%, Apple 25%, Windows 5%.

    Sachant que :
    * Il y a peu de tablettes Android avec processeur Intel (quelques Asus, Acer Iconia 7', Samsung Galaxy Tab3 10.1', …)
    * La quasi-totalité des tablettes Android vendues utilisent des processeurs ARM
    * Il y a de nombreux fabricants de processeurs ARM (178 licences Cortex-A dont Apple, AMD, Samsung, Qualcomm, Broadcom, Mediatek, NVidia, STMicroelectronics, …)

    on peut conclure que :
    * la statistique de Strategy Analytics prête à confusion entre volume de tablettes vendues, part de marché sur les revenus des processeurs équipant les tablettes et systèmes d'exploitation utilisés.
    * Si on soustrait les tablettes Windows (5%, Windows RT est quasi-inexistant), Intel descend vers 14% et n'est plus le 1er sur les revenus des CPU des tablettes Android, .

    Ensuite, la vrai question est ARM vs x86.
    Si, en terme de revenus, Intel reçoit 19% contre 81% pour les processeurs ARM,
    sur les volumes vendus, Intel est à moins de 10% contre plus de 90% pour les processeurs ARM.

    Alors, que pensez-vous maintenant des gros titres comme "Intel domine le secteur des processeurs pour tablettes Android !", "Tablettes : Intel n'a plus qu'Apple devant lui", "Processeurs : Intel mène le marché des tablettes, hors iPad", "Intel roi du marché des tablettes, hors Apple et ses iPad",…

    Pourquoi vouloir faire croire que Intel (moins de 10% des tablettes vendues?) dominent le marché des tablettes ?

    De toute façon, le plus gros marché est celui des smartphones
    où Intel est actuellement inexistant (en attendant Sofia fabriqué pour Intel par TSMC ?).
    Intel reste un concurrent bienvenu face aux processeurs ARM tant qu'il n'y a pas de désinformation dans les médias.

    Lire les commentaires

  • Hackathon : Legends Of code le 15 novembre 2014 à Paris (Dépêches LinuxFR)

    La troisième édition du Legends Of Code aura lieu le 15 novembre 2014 dans les locaux de D2SI à Paris et est destinée aux étudiants de dernière année d'université ou d'école.

    D2SI, 29bis rue d’astorg, 75008 Paris
    Metro Ligne 9 : Saint Augustin

    Onze heures durant, il vous faudra, en binôme, peaufiner vos tactiques et faire évoluer votre algorithme en tenant compte des résultats des affrontements contre les bots des autres équipes. C'est également l'occasion de tester ses aptitudes (ou apt-get) dans l'écoconception logicielle, l'agilité et la performance.

    Tout au long de la journée, vous serez mis en situation réelle et votre capacité à réagir sera également prise en compte.

    L'énoncé du concours sera dévoilé le jour J.
    Quelques précisions techniques sont présentes en seconde partie de la dépêche.

    Les langages autorisés sont le Java, le C++, et le C#.

    Quel que soit le langage choisi, il est obligatoire d’installer Java 8 et Git. Quelques autres précisions selon le langage :

    • Java : installer Maven 3 ;
    • C++ : les utilisateurs de Windows doivent venir avec Visual Studio 2013 installé, pour ceux sous GNU/Linux, g++ et make seront nécessaires ;
    • C# : installer en plus Visual Studio 2010 et le framework .Net 4.0 ; si vous n’êtes pas sous Visual Studio 2010, les organisateurs seront en mesure de vous indiquer comment migrer vers cette version.

    Les lots de ce concours sont 4000 € ainsi que 5000 $ de crédits Amazon Web Services (partenaires de l'évènement).

    À noter, pour les étudiants en dehors de Paris, que vos frais de déplacement sont remboursés en partie, de 50% des frais de transport, dans la limite de 50 euros par participant.

    Bon hack !

    Lire les commentaires

  • Atelier CLI du lundi 27/10/2014 à Bordeaux (Dépêches LinuxFR)

    Le lundi 27 octobre, l'atelier CLI aura pour thème VLC.

    Les ateliers CLI ont lieu chaque lundi de 19h00 à 20h00 pour les utilisateurs débutants et de 19h00 à 21h30 pour les utilisateurs avancés, dans les locaux du Labx, à la Fabrique Pola (rue Marc Sangnier, 33130 Bègles).

    Les ateliers CLI (Command Line Interface) permettent de progresser en ligne de commande au sein d'un groupe, autour d'un outil ou d'un thème.

    Les ateliers consacrés aux débutants ont repris !

    Lire les commentaires

  • Conférence vie privée et smartphone à Grenoble, le 4 novembre (Dépêches LinuxFR)

    La Guilde organise une conférence autour des smartphones et des problématiques de vie privée.

    La conférence se tiendra le mardi 4 novembre à 19h, dans les locaux de l'ENSIMAG (681 Rue de la Passerelle, 38400 Saint-Martin-d'Hères).

    Cet exposé introduit le projet Mobilitics, mené conjointement par Inria/Privatics et la CNIL depuis 2012 et certains de ses résultats. Il en ressort que ces téléphones intelligents sont souvent de véritables mouchards de poche, d'autant plus dangereux que les informations personnelles ainsi captées sont la plupart du temps exfiltrées vers des serveurs à l'étranger, la législation Française (voire Européenne) devenant difficile à appliquer.

    L'évènement sera animé par Vincent Roca, de l'équipe PRIVATICS, à l'Inria Grenoble Rhône-Alpes. L'entrée sera libre et gratuite.

    Lire les commentaires

  • Docker (Journaux LinuxFR)

    Hello,

    J'aimerai connaître les principales differences avec les FreeBSD jails … Les plus, les moins. Qui parmi vous l'utilise dans un environnement professionnel ?

    Merci :-)

    Lire les commentaires

  • CPP Con sur Youtube (Journaux LinuxFR)

    Les vidéos prises lors de la CPP Con 2014, LA conférence C++ de l'année, à Bellevue WA, commencent à arriver sur Youtube.

    Parmi mes préférées, la présentation de l'équipe Microsoft Office sur leur approche pour partager autant de code que possible pour tourner sous Windows 32 et 64 bits, MacOSX, iOS, Android, WinRT, et peut-être un jour iWatch, était tout à fait intéressant. Bon, et manifestement, le support de GNU/Linux n'est pas sur leur feuille de route.

    D'autres présentations, par exemple sur le Join Strike Fighter ou encore sur le Mars rover, sont également à voir. En terme de processus qualité, c'est autre chose que le tertiaire!

    Pour les fondus de performances, voir également la présentation d'Andrei Alexandrescu, "Optimization tips". Étonnant les optimisations possibles dans un shared_ptr!

    La liste des vidéos de la CppCon

    Lire les commentaires

  • Une installation hi-fi de qualitay avec le Raspberry Pi (Arch, Pulseaudio, Shairport, trolls inside) (Journaux LinuxFR)

    Sommaire

    Bonjour,

    Aujourd'hui on va s'amuser avec le Raspberry Pi pour en faire une petite borne audio qui fera de nombreux jaloux dans vos soirées mondaines. Mais pas que ça, et c'est bien l'intérêt de la baser sur Arch, vous aurez en parallèle toute la flexibilité pour installer les autres projets qui vous chantent (au hasard : XBMC, Retropie, etc).

    Comprendre : vous pourriez obtenir plus ou moins la même chose avec plusieurs cartes SD flashées avec différentes iso spécialisées sous Raspbian, sauf que là vous avez tout sur un seul système, en bleeding edge (désolé pas de traduction) sans avoir besoin de redémarrer pour changer d'activité.

    Ainsi Volumio ou PiMusicBox sont de bonnes alternatives pour qui veut écouter de la musique avec son RPi sans se prendre la tête, et donc sans suivre ce tuto. Notez que ces distributions proposent un serveur MPD, ce qui n'est pas abordé dans ce tuto (il faut bien que Pulseaudio serve à quelque chose).

    J'ai quoi à la fin ?

    • Un Raspberry Pi branché à vos enceintes
    • Un serveur Pulseaudio qui permet à tous les postes sous Linux/Pulseaudio d'envoyer leurs flux
    • Un récepteur Airplay (audio) pour envoyer du son depuis Mac OS / iOS / Android
    • Rien pour Windows
    • Une qualité sonore au top (bon au moins non dégradée)
    • Une fiabilité plus que correcte
    • Une automatisation totale (tout est prêt au boot)
    • Un système Arch standard pour toutes vos envies futures

    Le matos

    • Bon ben un Pi
    • Une alimentation correcte, de type 5V 2A ou 2.5A
    • Une carte SD performante (classe 10 tant qu'à faire)
    • Un DAC USB, la sortie audio du Pi n'étant vraiment pas terrible (11 bits, souffle, claquement au démarrage et à l'extinction)
    • Un hub USB alimenté, le Pi ayant un peu de mal à gérer sur la longueur tout ce qui consomme plus qu'un clavier. Sans vouloir faire de pub, ThePiHut propose un bon hub 7 ports spécialement adapté (sans "backpower" pouvant endommager votre Pi si vous n'êtes pas très chanceux).

    Normalement vous vous en sortez pour moins de 100€.

    On installe Arch

    Outre le fait d'être l'une des deux seules distributions mère à être réellement maintenue pour le Pi avec Raspbian (Debian Stable), et donc la seule à être vraiment à jour, Arch Linux est également à remercier pour la formidable qualité de son wiki. J'hésite donc à faire un copier coller de la manip, mais vu qu'elle diffère d'un simple dd et qu'en plus je fais ce que je veux dans mon journal, la voici en version courte pour une carte SD sur /dev/sdb :

    En root :

    fdisk /dev/sdb
    o
    p
    n
    p
    1
    ENTER
    +100M
    ENTER
    t
    c
    n
    p
    2
    ENTER
    ENTER
    w

    Puis

    mkfs.vfat /dev/sdb1 && mkdir boot && mount /dev/sdb1 boot && mkfs.ext4 /dev/sdb2 && mkdir root && mount /dev/sdb2 root && wget http://archlinuxarm.org/os/ArchLinuxARM-rpi-latest.tar.gz && bsdtar -xpf ArchLinuxARM-rpi-latest.tar.gz -C root && sync && mv root/boot/* boot && umount boot root

    On peut ensuite insérer sa carte dans le Pi et le brancher.

    Configuration de base

    On modifie le mot de passe root (par défaut "root") :

    passwd root

    On ajoute un utilisateur :

    useradd -m -g users -G wheel -s /bin/bash pi
    passwd pi

    On met à jour sa distrib :

    pacman -Suy

    On installe quelques trucs :

    pacman -S git binutils arm-mem-git pulseaudio alsa-plugins alsa-firmware alsa-tools alsa-utils pulseaudio-alsa

    reboot

    On remplace Vi par nano (Arch ayant une certaine tendance à forcer l'utilisation de Vi - par exemple pour Cron) :

    pacman -Rns vi
    ln -s /usr/bin/nano /usr/bin/vi

    Configuration Alsa

    On blackliste le module audio du Pi pour laisser le champ libre au DAC :

    nano /etc/modules-load.d/raspberrypi.conf

    #snd-bcm2835

    On force l'id du DAC dans Alsa :

    nano /etc/modprobe.d/alsa-base.conf

    options snd-usb-audio index=0

    On donne quelques consignes à Alsa pour s'intégrer comme il faut avec Pulseaudio :

    nano /etc/asound.conf

        pcm.!default {
          type pulse
          fallback "sysdefault"
          rate_converter "samplerate_best" 
          hint {
            show on
            description "Default ALSA Output (currently PulseAudio Sound Server)"
          }
        }
    
       ctl.!default {
         type pulse
          fallback "sysdefault"
        }
    
        defaults.pcm.dmix.!rate 44100

    Configuration Pulseaudio

    Deux enjeux ici : lancer Pulseaudio en mode session (car le mode système c'est le mal) et le faire travailler en "real time", au plus près du noyau.

    On ajoute des groupes à notre utilisateur :

    groupadd pulse-rt
    usermod -aG pulse-rt pi
    usermod -aG audio pi

    On modifie les droits du groupe :

    nano /etc/security/limits.conf

    En ajoutant tout en bas :

    @pulse-rt       hard nice -20
    @pulse-rt       soft nice -20

    Et en modifiant ce qui existe pour @audio :

    @audio          -       rtprio          99
    @audio          -       nice           -19
    @audio          -       memlock         unlimited

    Quelques réglages dans Pulseaudio :

    nano /etc/pulse/default.pa

    ### Automatically load driver modules depending on the hardware available
    #.ifexists module-udev-detect.so
    #load-module module-udev-detect
    #.else
    ### Use the static hardware detection module (for systems that lack udev support)
    #load-module module-detect
    #.endif
    load-module module-alsa-card device_id=0 tsched=true tsched_buffer_size=2048576 tsched_buffer_watermark=262144

    Les valeurs tsched_buffer_size et tsched_buffer_watermark sont à modifier si vous essuyez de l'audio déformé ou une trop grosse latence. La doc sur le sujet étant inexistante j'avoue ne pas avoir une vraie idée des réglages optimaux.

    ### Network access (may be configured with paprefs, so leave this commented
    ### here if you plan to use paprefs)
    #load-module module-esound-protocol-tcp
    load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;192.168.0.0/24 auth-anonymous=1
    load-module module-zeroconf-publish

    Ici on profite d'avoir une distribution moderne pour virer le protocole legacy, puis on ajoute les autorisations pour que les autres Pulseaudio du réseau puissent se connecter.

    Enfin on peut aussi désactiver les modules inutiles, comme tout ce qui touche à Jack et qui ont tendance à se charger alors qu'on en veut pas :

    ### Automatically connect sink and source if JACK server is present
    #.ifexists module-jackdbus-detect.so
    #.nofail
    #load-module module-jackdbus-detect channels=2
    #.fail
    #.endif

    Installation et configuration Shairport

    Shairport est une implémentation rétro-ingénérée de Airplay, le protocole Apple. Le but est de démarrer Shairport au boot, qui appellera et démarrera Pulseaudio tout seul comme un grand (via l'option Pulseaudio autospawn, configurée sur "yes" par défaut).

    Compilation et installation :

    git clone https://github.com/abrasive/shairport.git shairport
    ./configure && make && sudo cp shairport /opt/shairport && sudo chmod a+x /opt/shairport

    Intégration à systemd

    Ici on va tenter de lancer Shairport au boot via systemd en mode --user (par l'utilisateur Pi dans notre cas). Pourquoi ne pas passer par un service systemd classique avec l'option User= ? Parce que dans ce cas Pulseaudio est lancé en system mode et ne peut pas obtenir la bonne priorité de la part du noyau. Ne me demandez pas pourquoi, je ne sais pas.

    mkdir ~/.config/systemd && mkdir ~/.config/systemd/user && nano shairport.service

    [Unit]
    Description=Shairport AirTunes receiver
    
    [Service]
    ExecStart=/opt/shairport -b 90 -a Salon -o pulse
    Restart=always
    
    [Install]
    WantedBy=default.target

    -b définit le buffer (par défaut 200, à vous de tester ce qui va le mieux chez vous)
    -a le nom de votre borne Airplay
    -o le pilote audio à utiliser (à préciser absolument dans notre cas)
    L'option Restart=always de systemd est très pratique, Shairport pouvant parfois planter, elle vous garantira un redémarrage automatique et instantané du service.

    Activer systemd --user

    systemd --user enable shairport.service
    loginctl enable-linger pi

    A ce niveau il n'est pas une mauvaise idée de passer Pulseaudio en mode verbose pour s'assurer que tout va bien :

    nano /etc/pulse/client.conf

    extra-arguments = --log-target=syslog -v

    reboot
    journalctl _COMM=pulseaudio -b

    Vous devriez voir quelque chose comme

    core-util.c: Successfully gained nice level -X
    Running in system mode: no

    Vous pouvez alors supprimer le mode verbose pour soulager journald :

    nano /etc/pulse/client.conf

    #extra-arguments = --log-target=syslog

    Et violà !

    Vous devriez déjà avoir vu apparaître votre serveur Airplay sur tous vos appareils compatibles ainsi que le "sink" Pulseaudio sur tous vos postes Linux/Pulseaudio (configurés via paprefs "make Pulseaudio network available locally" et éventuellement "make Apple Airtune network available locally").

    En réseau Pulseaudio classique, par exemple en utilisant Spotify depuis votre portable dans la cuisine, la consommation CPU du Pi s'élève à 10%, ce qui est très satisfaisant.
    Via Shairport ce n'est pas la même chose, on tourne plutôt autour des 50%.

    Enjoy !

    Lire les commentaires

  • 15 jours de cartographie OpenStreetMap à Dijon (Dépêches LinuxFR)

    Les associations COAGUL et les Amis de la Terre Côte-d'Or co-organisent un audit participatif de la présence publicitaire à Dijon du 21 octobre au 4 novembre 2014

    Cet audit participatif remplit deux objectifs :

    • Le premier est de recenser durant 2 semaines les panneaux de publicité de l'agglomération dijonnaise et de les ajouter dans OpenStreetMap. Les données seront chiffrées et mises en valeur sur une carte. Elles pourront ainsi être utilisées pour comparer le résultat, lors de l'enquête publique et/ou de la consultation prévue par la ville de Dijon, avec l'audit de la publicité commandé par celle-ci.
    • Le deuxième objectif est d'initier et de sensibiliser un maximum de personnes à la cartographie libre OpenStreetMap.

    Notre audit participatif aura lieu du 21 octobre au 4 novembre 2014 ; le lancement se fera mardi 21 à COAGUL, au tout début de la réunion hebdomadaire de l'association. Durant la première semaine, les participants seront invités à localiser des panneaux publicitaires (en relevant les informations pertinentes comme l'adresse précise, l'opérateur, et si possible en prenant une photographie).

    Le samedi 25 octobre sera une journée entièrement dédiée à la saisie des panneaux publicitaires dans la base de données OpenStreetMap (OSM). Ce jour-là, pendant que certains participants procéderont à la saisie des données, des ateliers d'initiation à la saisie seront organisés ainsi que des balades par deux en voiture, ou mieux à vélo ou encore à pied, pour cartographier la publicité.

    La deuxième semaine de l'audit participatif, les participants pourront saisir eux-mêmes les informations dans la base de données OSM depuis chez eux. À l'issue des 15 jours, le mardi 4 novembre, une soirée de clôture et de restitution de cette action sera proposée, à laquelle tous les participants seront conviés.

    Lire les commentaires

  • Capitole du Libre 2014 - le programme (Dépêches LinuxFR)

    Cette année encore, les libristes toulousains remettent le couvert pour le Capitole du Libre, l'événement du Libre à Toulouse.

    Capitole du Libre

    Le vendredi 14 novembre est une journée à destination des professionnels, organisée par l'association Solibre. Cette journée sera rythmée par des conférences, une table ronde et des ateliers.

    Les samedi 15 et dimanche 16 novembre, l'association Toulibre et les clubs de l'N7 vous donnent rendez-vous à l'ENSEEIHT pour des conférences, ateliers et démonstrations autour du Logiciel Libre, et vous proposent un village associatif où chacune et chacun aura l'occasion de discuter avec des acteurs du Logiciel Libre. Une vue synthétique du programme est consultable ici.

    Nous accueillerons cette année notamment Benjamin Bayart de la Fédération FDN, Adrienne Charmet de La Quadrature du Net, ou encore Sandrine Mathon de Toulouse Métropole à propos d'Open Data, Armony Altinier sur les aspects Accessibilité dans le Libre, et Lionel Maurel, juriste et documentaliste, ou encore Pierre-Yves Gosset de Framasoft qui propose de dégoogliser Internet (rien que ça), Pierre Ficheux et Christophe Blaess pour l'aspect embarqué, voire même Alex Marandon, chef-patate de l'équipe Smeuh.

    Le dimanche, plusieurs ateliers sont proposés à tous, tant pour les débutants que pour un public averti. Chacun pourra apprendre à utiliser Thunderbird, créer un jeu vidéo avec DreamEngine ou en apprendre plus sur ce qui se passe dans les tuyaux d'Internet, ainsi que deux ateliers autour de Blender.

    L'entrée est libre et gratuite ; les ateliers seront accessibles sur inscription en ligne.

    Le Capitole du Libre, c'est aussi

    Une install party pour découvrir et installer un système libre sur son ordinateur.

    Un « village du Libre » où les associations autour du Libre présenteront leurs activités.
    Vous pourrez y retrouver les stands Fedora représenté par l'association Borsalinux-FR, Debian mais également Haiku.

    Les groupes d'utilisateurs de la région représentés bien évidemment par Toulibre (groupe d'utilisateurs de logiciels libres de Toulouse), mais également par le CULTe (Club des utilisateurs de logiciels libres et de GNU/Linux de Toulouse et des environs) et l'ARU2L (Association rouergate des utilisateurs de logiciels libres).

    Des stands de démo et d'animations seront proposés au public tout le week-end : un stand open hardware pour découvrir les imprimantes 3D RepRap, la mini console Bitbox et le projet DraWall promu par le fablab toulousain Artilect.

    L'occasion de réunir des communautés du Libre pour des conférences ou des rencontres durant lesquels développeuses et développeurs se retrouvent autour d'un même projet. Cette année, le Capitole du Libre accueille Akademy-fr et un hackfest LibreOffice.

    Lire les commentaires

  • Mark Shuttleworth sera présent à Paris lors de l'OCP Summit (Dépêches LinuxFR)

    Le fondateur d'Ubuntu et de Canonical, Mark Shuttleworth, sera présent lors de l'OCP Summit le 31 Octobre à Paris. La Fondation Open Compute (OCP) a le plaisir d'annoncer l'organisation de son 1er sommet européen. Ce sommet aura lieu le jeudi 30 octobre et vendredi 31 octobre 2014 au sein de École Polytechnique sur le campus Paris-Saclay, France.

    Fondée par Facebook en 2011, la Fondation OCP s'est rapidement développée pour inclure Intel, Rackspace, Goldman Sachs et des sommités comme Andy Bechtolsheim. Elle compte aujourd'hui plus de 150 membres officiels, tels que AMD, ARM, Bloomberg, Box, Baidu, IBM, Intel, Dell, EMC, Fidelity, Microsoft, Orange, Rackspace, Salesforce, SanDisk, VMWare, et Western Digital.

    Organisation à but non lucratif, OCP est une communauté en pleine croissance, qui regroupe des ingénieurs à travers le monde, et dont la mission est de concevoir et de produire les matériels les plus efficaces : serveurs, stockage et centres de données pour les grands consommateurs de plateformes informatiques.

    La Fondation définit et régit huit projets de haut niveau pour soutenir ces développements et fournir une structure juridique qui accélère le rythme de l'innovation et l'expansion de ses technologies sur le marché.

    Lors de cet évènement de deux jours à Paris, l'OCP et ses membres présenteront les dernières tendances technologiques conçues par la communauté OCP y compris au niveau des serveurs, de la conception de puces, de l'intégration de logiciels et de leur certification. Une mise à jour sur l'état actuel de la charte européenne sera communiquée et les représentants des projets seront présents et animeront des ateliers d'ingénierie de premier plan.

    Le premier Hackathon OCP européen sera également organisé avec à la clé, un prix d'une valeur de 5,000 USD pour le gagnant.

    « Nous sommes extrêmement heureux que notre premier sommet international se tienne ici à Paris-Saclay. Nous voyons un net engouement se dessiner en Europe et nous travaillons en étroite collaboration avec nos partenaires distributeurs pour fournir des technologies Open Compute au marché européen. Ce dernier a toujours été créatif, avec de fortes communautés open source, nous n'avons aucun doute qu' OCP va changer les règles sur la façon dont les serveurs et centres de données seront conçus à l'aide de la communauté européenne » Cole Crawford, directeur exécutif de la Fondation OCP.

    Jean-Marie Verdun, actuel chef de file d'OCP en Europe, confirme : « La communauté européenne OCP est en pleine croissance, et accueillir cet évènement en France au sein du campus Paris-Saclay où la communauté OCP européenne est actuellement la plus active, est une vraie reconnaissance. La communauté locale aura l'occasion de présenter ses premiers projets de recherche avec notamment la démonstration d'une solution de refroidissement révolutionnaire et de son architecture, créant ainsi de nombreuses possibilités d'étendre ces travaux avec les membres de la communauté à l'étranger »

    Merci d'envoyer vos questions et vos demandes d'interview à press@opencompute.org

    N'hésitez pas à vous inscrire (inscription et participation gratuite) Vous pourrez également vous inscrire pour le Hackathon.

    Référence :
    http://www.opencompute.org/blog/mark-shuttleworth-of-canonical-to-keynote-ocp-european-summit-2014/

    Lire les commentaires

  • Install party à bordeaux (Journaux LinuxFR)

    Giroll, gironde logiciel libre, organise une Install Party.
    Celui-ci se déroulera le samedi 25 octobre au centre culturel st pierre à bordeaux.
    Pendant cette journée :
    - venez installer votre distribution Linux
    - trouvez de l'aide
    - discutez avec des libristes passionnés autour d'un verre.
    - assistez aux différentes présentations de la journée.

    Programmes :

    • 10h00 Présentation de la carte et de l'IDE arduino, avec initiation pendant l'install party

    • 10h45 Créer son studio radio. Présentation des éléments matériels et logiciels de la partie cliente du studio Giroll.

    • 11h30 Présentation de SteamOS

    • 13h45 Gimp pour les débutant

    • 14H30 Publishing avec FOP, Présentation générale de Apache FOP, illustrée d'exemples mis en production.

    • 14h30 Création musicale avec LMMS, Présentation et utilisation de LMMS, un logiciel de création musicale multi OS (Linux et Windows).

    • 15h15 Installation de GNU/Linux avec un BIOS UEFI

    • 16H00 Bonnes pratiques en Bash. Debug et TDD (Test Driven Development), paramètres d'expansion et autres outils du langage.

    • 16h45 Contribuer aux logiciels libres, plus qu'une liberté : une responsabilité Un utilisateur de Logiciel Libre compétent peut-il se contenter d'être simple consommateur ? Comment apporter sa pierre à l'édifice et encourager les contributions des créateurs de projets libres.

    Lire les commentaires

  • Réunion mensuelle Chtinux, le 28 octobre 2014 à Lille (Dépêches LinuxFR)

    L'association Chtinux propose sa réunion mensuelle autour du logiciel Libre (évidemment), le mardi 28 octobre à partir de 20h au Café Citoyen de Lille.

    Aussi, ce sera l'occasion de discuter de venir rencontrer les membres de l'association, en discuter et/ou adhérer à celle-ci en cette rentrée 2014, autour d'une consommation 100% bio!

    N'hésitez pas à faire passer le mot, et venez nombreux!

    (Et non, il ne s'agira pas de discuter sur Cafougnette et les gaufres, je vous vois venir! A moins que…)

    Lire les commentaires

L'homme est un être fragile, qui à besoin d'assistance quand il se lance
dans des activités dangeureusement incertaines comme la photographie. La
femme elle n'a besoin que d'arriver à se débarrasser du mâle bien
intentionné.
-+- Noëlle, sur fr.rec.photo -+-