Linux France

S'abonner à flux Linux France
Mis à jour : il y a 16 min 58 sec

Concours de programmation CodinGame le 28 juin 2014

Jeudi 19 Juin

La prochaine édition de CodinGame, le challenge de code en ligne, aura lieu le samedi 28 juin 2014 à 18h (heure de Paris).

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 ou entrer en contact avec des sociétés qui leur plaisent et qui recrutent.

Le thème de cette édition est « Shadows of the Knight » : incarnez le Chevalier Noir et nettoyez Gotham rongée par le mal et la corruption.

L'objectif du challenge : résoudre deux problèmes de programmation dans le langage de son choix parmi les 19 proposés (C/C++, C#, Java, Javascript, PHP, Python, Python 3, Perl, Go, Dart, Scala, Haskell, Objective-C, Pascal, Ruby, Bash, Groovy et Clojure). 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.

Comme d'habitude, le règlement prévoit que le code source des participants soit rendu public sous licence libre GPL v3 et affiché sur le site dès la fin du concours, pour que tout le monde puisse apprendre et progresser en consultant les solutions des autres.

Télécharger ce contenu au format Epub

Lire les commentaires

Sortie du connecteur Tuleap Agile Planner pour Eclipse en Open Source

Mercredi 18 Juin

Ericsson, Enalean et Obeo ont annoncé lors de la conférence EclipseCon France (18 et 19 juin 2014) à Toulouse la sortie prochaine du premier outil Open source de gestion de projet agile intégré à Eclipse.

Cette innovation a vu le jour grâce au partenariat avec Ericsson qui a participé au financement des développements, et à la collaboration technique des équipes d’Enalean et d’Obeo. Les ingénieurs Enalean ont complétement retravaillé l'API REST de Tuleap et Obeo s'est chargé de l'intégration dans Eclipse.

L'objectif de ce connecteur est d'accéder aux outils agiles de la forge logicielle Tuleap directement depuis l'environnement de développement Eclipse. Grâce au connecteur Tuleap Agile Planner pour Eclipse, les développeurs accèdent aux outils agile de Tuleap (versions, sprints, mur des tâches, graphique burndown) tout en restant dans Eclipse, évitant les allers-retours entre les différents outils.

Tuleap Agile Planner est intégré avec l'environnement Eclipse Mylyn. Il conserve ainsi l'expérience utilisateur d'Eclipse dénommée « interface centrée sur les tâches » (task-focused interface). Dans Eclipse, cette vue ne montre au développeur que ce qui concerne la tâche en cours, tout en apportant les fonctionnalités spécifiques de Tuleap pour la gestion de projet agile. Un développeur peut facilement lier un cas d'utilisation avec un nouvelle tâche et son code source ou mettre à jour ses cartes sur le mur des tâches par cliquer-glisser. Chacun peut suivre l'avancement d'un sprint ou d'une version ou consulter le graphique du reste à faire (burndown).

Tuleap est la première forge logicielle à proposer un connecteur agile pour Eclipse sous licence Open source.

Tuleap Agile Planner pour Eclipse est entièrement contribué en Open source sous licence EPL. Il sera disponible début juillet 2014. Vous pourrez l'installer en quelques clics depuis le marché Eclipse directement depuis l'interface Mylyn discovery.

Télécharger ce contenu au format Epub

Lire les commentaires

Whatever Apéro du 27 et 28 Juin 2014 - Rennes

Mercredi 18 Juin

Hackers, Hackeuses, actuels et en devenir,

Le hackerspace Breizh Entropy a le plaisir de vous inviter à une nouvelle édition des « Whatever Apéros », moment d'échanges, de rencontres, de diffusion et de création de savoirs autour de l'électronique, de l'informatique, de la vie privée, de la création numérique…

Cette Nième édition des « Whatever Apéros » (on a perdu le compte en route, désolé), sera aussi l'occasion de se décrasser un peu les oreilles et les yeux, car elle accueillera la 30eme édition des « Apéros Codelab » (qui eux arrivent à tenir un compte, même après 30 apéros, respect), suivie d'une soirée de concerts et de performances artistiques !

C'est Quand ?

Les vendredi 27 et samedi 28 Juin 2014

C'est où ?

Les ateliers et l’apéro auront lieu à l’Élaboratoire, à Rennes, 48 boulevard Villebois-Mareuil, dans le premier bâtiment à l’entrée sur la gauche, derrière le robot géant.

L'Apéro Codelab et les concerts auront lieu au théâtre de l'Élaboratoire, au 17 bis Avenue Chardonet.

Qu'est ce qu'il s'y passe ?

Vendredi et samedi, en journée :

  • des conférences (sur l'Art, la vie privée…)
  • des ateliers (sur la création numérique, les logiciels et systèmes libres, l'électronique…).

Un moment de rencontre et de discussion le vendredi soir.

Et le clou du spectacle, le samedi soir :

  • L'Apéro Codelab :
    • Soit un apéro + un forum d'art numérique, pour découvrir et partager des créations libres
    • Des concerts et des performances artistiques

Le programme détaillé est disponible.

Et, si vous êtes inspirés, que ce soit pour un atelier, une conférence, nous présenter votre dernier projet, ou venir faire du bruit à l'apéro codelab, n'hésitez pas à nous faire signe, il y aura toujours de la place !

Tous les ateliers et conférences organisés par le HackerSpace sont, ouverts à tous et à prix libre. L'entrée des concerts est payante (5€).

Venez nombreux, histoire de bien augmenter l'entropie locale !

Télécharger ce contenu au format Epub

Lire les commentaires

pod : un outil de travail collaboratif pour suivre et gérer tâches, documents et autres

Mercredi 18 Juin

POD est un outil de travail collaboratif conçu pour partager documents, tâches et données variés. Il est totalement versionné et propose une granularité fine de gestion des droits. Il est distribué sous licence AGPL.

L'intérêt de POD est d'augmenter la productivité du travail collaboratif :

  • en centralisant l'information (tâches, documents, commentaires, pièces jointes)
  • en implémentant la traçabilité sur vos données : tout est versionné, on ne travaille donc plus seulement avec des données « en l'état » mais également des données « qui ont vécu ».
  • en proposant un outil qui vous permet de gérer au même endroit vos bases de connaissances, vos listes de tâches, vos contacts
Sommaire Statut du projet

Initialement, il s'agissait d'un outil à cheval entre un wiki et un bug-tracker sans possibilité de partage. Désormais l'outil est collaboratif, permettant notamment de gérer les droits d'accès en lecture/écriture de manière fine sur chaque document, de travailler sur le contenu et de savoir qui fait quoi.

POD est à un stade alpha : il est utilisable mais a un périmètre d'utilisation limité car certaines fonctionnalités sont incomplètes, et des cas limite ne sont pas tout à fait correctement gérés. Il est fiable dans la mesure où vous ne perdrez pas de données.

Le code est sale, vous n'allez pas rêver ;) Un grand refactoring est nécessaire, en terme de maintenabilité et également d'architecture afin de découpler backend / frontend.

Les fonctionnalités en détail

Un peu à la manière de « tout est fichier » dans UNIX, POD implémente un modèle de données « tout est document ».

Les documents sont organisés sous forme arborescente, comme on organiserait des fichiers.

Les données que vous pouvez manipuler sont de différents types :

  • commentaire
  • contact (titre + détail du contact)
  • fichier (titre + description + contenu du fichier + nom du fichier)
  • document (titre + description + statut)

Sur ces données, vous pouvez :

  • créer / modifier / déplacer / supprimer des données
  • partager / gérer les droits d'accès à ces données
  • rechercher ces données et filtrer les résultats par type

À la manière d'un wiki, les données sont totalement versionnées ; l'avantage de pod réside dans les différents types de données disponibles.

Les droits d'accès sont gérés avec une granularité fine : chaque élément peut être partagé ou privé, s'il est partagé on peut définir finement les utilisateurs et groupes d'utilisateur y ayant accès en lecture ou lecture/écriture. On peut par exemple stocker au même endroit un document partagé avec toute l'équipe, un document personnel et un document partagé avec des clients.

Captures d'écran Création de documents et autres

Gestion des droits d'accès

Recherche et filtrage

Exemples d'utilisation Base de connaissances

On crééra simplement des documents, organisés sous forme arborescente. C'est un cas nominal.

Todo-list / gestion de tâches

On pourra créer une todo-list en opérant de la manière suivante :

  1. créer un document intitulé « Mes choses à faire »
  2. créer X sous-documents intitulés « Tâche A », « Tâche B »…
  3. lorsqu'on visualise "Mes choses à faire", l'onglet "sous documents" à droite contient la liste des tâches à réaliser et leur statut.

Si l'on modifie le document « Mes choses à faire » et qu'on lui attribue le statut « automatic », alors « Mes choses à faire » devient une « méta-tâche » dont le statut sera « terminé » lorsque toutes les sous-tâches seront dans le statut « terminé ».

Partage de données, données individuelles et collectives au même endroit

Un des intérêts de POD est de présenter un modèle de gestion de droits d'accès très granulaire. Chaque document peut être accessible en lecture ou lecture/écriture pour une liste de groupes et/ou de personnes. Concrètement, cela permet par exemple :

  • de partager un document en lecture avec vos clients mais en écriture avec vos partenaires
  • de stocker au même endroit les éléments à publier et les éléments internes à l'entreprise (ou l'équipe).
  • de stocker au même endroit des documents que vous partagez avec vos collaborateurs et d'autres qui vous sont personnels. Par exemple, vous mettrez un commentaire privé qui sera associé à un document partagé, ce commentaire sera visible de vous seul
Comment ça marche ?

Il s'agit d'une application web basée sur les technologies python3, TurboGears, PostgreSQL. Le thème est à la bootstrap, l'interface est +/- fonctionnelle sur téléphone mobile.

Tester pod, l'installer Test simple

Vous pouvez tester l'application en ligne à l'adresse suivante :

Test avancé

Pour tester l'aspect collaboratif, connectez-vous en demo@localhost, créez un compte via le menu admin -> users (l'adresse de courriel n'est pas vérifiée, aucun courriel n'est envoyé), et utilisez ce nouveau compte dans un onglet de navigation privée ou dans un autre navigateur.

Installation locale

Si vous souhaitez installer l'application, le code source est disponible sous licence AGPL sur un dépôt git sur Bitbucket : https://bitbucket.org/lebouquetin/pod.git

Le dépôt contient également la doc d'installation, qui inclut notamment les premiers pas à suivre pour les utilisateurs qui ne maîtrisent pas PostgreSQL !

La suite…

Plusieurs orientations s'offrent à nous pour transformer cette version en véritable application de travail collaboratif. Les évolutions que l'on envisage sont :

  • Implémenter un modèle de données générique donc personnalisable. Cela permettrait de personnaliser les données que l'on manipule, on peut par exemple imaginer :
    • un modèle de type « ouvrage » qui aurait un titre, un résumé, des auteurs, un numéro ISBN, etc
    • un modèle de type « Compte Rendu d'intervention » qui aurait un auteur, des intervenants, une date d'exécution, un champ description, des remarques, etc, etc
  • Implémenter une véritable API REST/JSON pour proposer un backend générique et permettre à chacun d'implémenter sa propre interface (ou des connexions avec le monde extérieur)
  • Enrichir les modèles de données actuels,
  • Développer une interface réellement responsive probablement en AngularJS,
  • Ajouter différentes fonctionnalités telles que notifications par courriel, tableau de bord, pagination sur la recherche, etc, etc.
  • Corriger les bugs ;)
Remarques, critiques et questions bienvenues

Nous sommes ouvert aux remarques, critiques et questions… c'est d'ailleurs pour cette raison que nous sommes là :-p

Télécharger ce contenu au format Epub

Lire les commentaires

ApéroLibre de Nantes le 03/07 : "Outils cartographiques" et "Samba4 comme AD"

Mercredi 18 Juin

Retrouvez-nous autour d'un apéro le jeudi 3 juillet (de 18h45 à 21h) à la Cantine Numérique de Nantes pour découvrir deux thématiques : « Outils cartographiques pour la gestion territoriale » et « Samba4 en complément ou en remplacement de Microsoft Active Directory ».

Vous vous intéressez aux logiciels libres ou plus généralement au monde du Libre ?

Alliance Libre vous propose un nouveau format de séminaire : les « ApéroLibres », généralement le troisième jeudi tous les deux mois impairs, de 18h45 à 21h à la Cantine Numérique de Nantes (Chaussée de la Madeleine - 11 Impasse Juton - 44000 Nantes) pour découvrir deux thématiques différentes.

Dates suivantes : les 18 septembre et 20 novembre.

Entrée libre et gratuite - le nombre de places est limité, si vous voulez être sûr d'avoir une place, inscrivez-vous à info AT alliance-libre DOT org.

Outils cartographiques pour la gestion territoriale

Intervenant : Marc Saboureau (Makina Corpus)

La cartographie est un outil qui permet de répondre à des thématiques variées : communication, mise en valeur des données publiques, gestion des territoires…

  • Au service de la communication et dans le cadre de l'exposition Loir-et-Cher 2020, le département a souhaité se présenter sous un nouveau jour à l'aide d'une carte interactive utilisable grâce à une table tactile, présentant l'ensemble des projets départementaux.
  • Afin de mettre en valeur ses données, le Conseil Général de Loire-Atlantique met à disposition de ces citoyens et partenaires, Vuduciel une application diffusant les photographies aériennes de son territoire.
  • Pour la gestion interne de ses sentiers, les trois parcs nationaux : Écrins, Mercantour, Alpi marittime utilisent Geotrek. Cela permet de référencer les tronçons, les points remarquables… et de valoriser la randonnée auprès du grand public.

L'ensemble de ces applications web ont été créées par Makina Corpus, expert en logiciels Open source, qui a exploité les technologies libres et innovantes : OpenStreetMap et les opendata des villes, le studio de conception cartographique TileMill et Leaflet pour l'affichage.

Samba4 en complément ou en remplacement de Microsoft Active Directory

Intervenants : Vincent Cardon et Frédéric Bonnier (Tranquil IT Systems)

Tranquil IT Systems vous propose de découvrir ou d'approfondir vos connaissances de la nouvelle version du logiciel Samba. Samba4 combine judicieusement les avantages de Linux et ceux d'Active Directory et continue de remplir sa promesse historique : « Opening Windows to a wider world ».

Nous vous présenterons nos expériences avec le logiciel et la manière dont il est utilisé en production pour :

  • gérer les comptes utilisateurs et les groupes ;
  • gérer les comptes machines et les GPO ;
  • gérer les partages de fichiers et les droits ;
  • gérer les DNS ;
  • authentifier de manière transparente les utilisateurs.
Télécharger ce contenu au format Epub

Lire les commentaires

RDV MariaDB Roadshow

Mercredi 18 Juin

Le fork de MySQL, MariaDB, fait son "MariaDB Roadshow" au Novotel Paris Les Halles, le 26 juin 2014. Il s'agit d'un événement à destination de tous les administrateurs de base de données (DBA), mais aussi des développeurs de tous les langages : PHP, Python, Perl, Java, Ruby, C…

Ce rendez-vous propose de vous faire atteindre de nouveaux sommets à travers des fonctionnalités éprouvées et des nouvelles technologies conviviales.

Cette demi-journée sera articulée autour des conférences suivantes :

  • 14h00 : inscription et café de bienvenue ;
  • 14h15 : allocution de bienvenue et introduction ;
  • 14h30 : la nouvelle offre MariaDB : MariaDB 10, MaxScale et plus encore ;
  • 15h15 : haute disponibilité avec MariaDB Enterprise ;
  • 15h45 : pause café ;
  • 16h00 : automatisation & gestion de cluster de base de données avec Severalnines ;
  • 16h30 : Big Data avec MariaDB10, TokuDB et Spider ;
  • 17h00 : évolutivité avec MariaDB et MaxScale : "atteindre de nouveaux sommets" ;
  • 17h45 : résumé et conclusions ;
  • 17h50 : networking & café-mignardises.

Ce rendez-vous est gratuit, mais sur réservation car le nombre de places est limité.

Télécharger ce contenu au format Epub

Lire les commentaires

Red Hat Software Collections 1.1

Mercredi 18 Juin

Red Hat a annoncé, le 4 juin dernier, les « Software Collections » en version 1.1. Il s'agit d'un canal (terminologie de Red Hat pour désigner un dépôt logiciel) contenant des logiciels dont les versions sont plus récentes que dans les canaux habituels de la distribution RHEL. La nouvelle est arrivée avant RHEL 7 mais a été quelque peu… éclipsée par la nouvelle version majeure du système phare de la firme de Raleigh.

Les principaux logiciels inclus

Comme pour la version 1.0, on retrouvera des composants parmi les principaux des plateformes LAMP : MySQL 5.5, MariaDB 5.5, PHP 5.4, Python 2.7 et 3.3. On retrouvera aussi Perl 5.16, PostgreSQL 9.2, Ruby 1.9.3 et Rails 3.2.8. Peu de nouveautés de ce côté, à part peut-être quelques précisions sur les versions utilisées, et le fait que cette version de PHP comporte Pear 1.9.4 ainsi que les extensions APC, memcache et Zend OPcache. Node.js est toujours présent, accompagné de npm.

Passons maintenant du côté des nouveautés : pour les langages, nous avons PHP 5.5 (en version 5.5.6), apportant avec lui memcache et Zend OPcache. On peut noter l'arrivée de Ruby 2.0.0, accompagné de Ruby on Rails 4.0.2.

Côté bases de données, il y a aussi du nouveau : MongoDB fait son entrée dans les Software Collections, avec la version 2.4.9, et Red Hat fournit l'extension PHP adéquate, pour PHP 5.5.

Beaucoup les réclamaient, ils ont été entendus : Apache 2.4 et Nginx 1.4 sont disponibles ! Attention toutefois, Nginx n'est disponible qu'en avant-première technologique.

Enfin, pour clore le chapitre des nouveautés, on peut aussi découvrir Thermostat en version 1, un outil de surveillance pour OpenJDK.

Distributions compatibles

Le chapitre 1.3 précise que les Software Collections sont disponibles pour les versions de RHEL 6 et 7 supportées (comprendre : les dernières versions mineures et les versions "z"), uniquement pour les architectures AMD64 et Intel 64.

Télécharger ce contenu au format Epub

Lire les commentaires

Revue de presse de l'April pour la semaine 24 de l'année 2014

Mardi 17 Juin

La revue de presse de l'April est régulièrement éditée par les membres de l'association. Elle couvre l'actualité de la presse en ligne, liée au logiciel libre. Il s'agit donc d'une sélection d'articles de presse et non de prises de position de l'association de promotion et de défense du logiciel libre.

Sommaire

[Télérama.fr] Le sens "commun", une alternative au capitalisme ?

Par Weronika Zarachowicz, le samedi 14 juin 2014. Extrait:

Partager les idées, les voitures, les connaissances, les maisons. Le “commun” inspire citoyens, philosophes ou juristes… Le philosophe Pierre Dardot et le sociologue Christian Laval nous éclairent sur cette aspiration grandissante.

Lien vers l'article original: http://www.telerama.fr/monde/le-sens-commun-une-alternative-au-capitalisme,113475.php

Et aussi:

[Slate.fr] Le Conseil national du numérique veut la «neutralité des plateformes». Ça veut dire quoi?

Par Andréa Fradin, le vendredi 13 juin 2014. Extrait:

Les «plateformes» du Net. Il faudra vous faire à cette expression, tant elle est aujourd'hui collée aux lèvres de toute personnalité, politique ou membre de comités de réflexion, en charge de réfléchir à la politique numérique en France et en Europe. Qui sont ces «plateformes»?…

Lien vers l'article original: http://www.slate.fr/story/88461/rapport-conseil-national-numerique-neutralite-plateformes

Et aussi:

[Numerama] Pourquoi les voitures Tesla passent à l'open-source

Par Guillaume Champeau, le vendredi 13 juin 2014. Extrait:

Elon Musk a annoncé que le fabricant de voitures électriques Tesla Motors allait renoncer à l'exclusivité de ses droits sur son portefeuille de brevets. Un choix industriel qui vise à dynamiser le marché, pour bénéficier à Tesla.

Lien vers l'article original: http://www.numerama.com/magazine/29681-pourquoi-les-voitures-tesla-passent-a-l-open-source.html

Et aussi:

[Mediapart] Étendre les libertés à l’âge du numérique

Par Edwy Plenel, le mercredi 11 juin 2014. Extrait:

A l’initiative de députés de tous bords, réunis autour du socialiste Christian Paul, l’Assemblée nationale met en place, mercredi 11 juin, une «Commission de réflexion et de propositions sur le droit et les libertés à l’âge du numérique», composée à parité de parlementaires et de représentants de la société civile. Saluant une initiative bienvenue et pluraliste, Mediapart et La Quadrature du net ont accepté d’y participer dans le respect de leur liberté de parole et dans le souci de la publicité des travaux.

Lien vers l'article original: http://blogs.mediapart.fr/edition/libres-enfants-du-numerique/article/110614/etendre-les-libertes-l-age-du-numerique

Et aussi:

[Distributique.com] Vente liée PC/OS: l'UFC-Que Choisir perd son combat contre HP

Par Oscar Barthe, le mercredi 11 juin 2014. Extrait:

Dans le duel judiciaire qui l'oppose à Hewlett Packard, l'association de consommateurs UFC-Que Choisir vient de se voit infliger un revers par la Cour d'Appel de Paris. Cette dernière a jugé que la vente liée d'un PC et d'un système d'exploitation n'était pas une pratique commerciale déloyale, à l'instar de la Cour de Cassation en juillet 2012.

Lien vers l'article original: http://www.distributique.com/actualites/lire-vente-liee-pc-os-l-ufc-que-choisir-perd-son-combat-contre-hp-21892.html

Et aussi:

Voir aussi:

[Miroir Mag] Cadoles : l’avenir en logiciel libre

Par Marion Chevassus, le mercredi 11 juin 2014. Extrait:

“J’ai attendu d’avoir Bac+2 avant de savoir me servir d’un traitement de texte”, Vincent Febvre pense qu’en France, on est très en retard, question informatique. Ce développeur trentenaire de Cadoles, une jeune entreprise dijonnaise, nous explique pourquoi et quelles conséquences pourraient bien avoir l’ignorance manifeste de la langue html sur notre destin. Un travail à reprendre depuis l’école.

Lien vers l'article original: http://www.miroir-mag.fr/61064-cadoles-lavenir-en-logiciel-libre

Et aussi:

[Next INpact] Isabelle Attard interroge Montebourg sur le projet d'un OS «Made in France»

Par David Legrand, le mardi 10 juin 2014. Extrait:

Il y a quelques semaines, L'Opinion nous apprenait que les services de Bercy se penchaient sur la question de la souveraineté numérique et qu'Arnaud Montebourg avait en tête un projet de système d'exploitation français. Bien que reprenant principalement des propos de Pierre Bellanger, l'article n'a pas tardéà faire réagir à tous les niveaux. Aujourd'hui, c'est la députée Isabelle Attard qui pose officiellement une question au ministre.

Lien vers l'article original: http://www.nextinpact.com/news/86938-isabelle-attard-interroge-montebourg-sur-projet-dun-os-made-in-france.htm

Et aussi:

Voir aussi:

[Rue89] J’ai pris le contrôle de votre caméra et je vous ai retrouvés

Par Gurvan Kristanadjaja, le lundi 9 juin 2014. Extrait:

Webcams, imprimantes, portes de garage… Vous n’avez pas protégé vos objets connectés? Dommage. Le moteur de recherche Shodan nous a permis d’en prendre les commandes. Nous avons pu prévenir certains d’entre vous.

Lien vers l'article original: http://rue89.nouvelobs.com/2014/06/09/jai-pris-les-commandes-camera-ai-retrouves-252793

[We Demain] La Paillasse, le labo citoyen qui se rêve en «MIT de l’open-source»

Par Côme Bastin, le lundi 9 juin 2014. Extrait:

Ce lieu d’innovation collaborative inaugurait samedi un nouvel espace parisien. Une étape clé pour ce «laboratoire de garage» né en 2011 dans un hackerspace de Vitry-sur-Seine.

Lien vers l'article original: http://www.wedemain.fr/La-Paillasse-le-labo-citoyen-qui-se-reve-en-MIT-de-l-open-source_a547.html

Télécharger ce contenu au format Epub

Lire les commentaires

Framasoft lance une campagne de crowdfunding pour financer le développement d'Etherpad

Lundi 16 Juin

Etherpad est une application libre d'édition de texte collaboratif en ligne et en temps réel. Framasoft a installé en 2011 une instance personnalisée d'Etherpad, baptisé Framapad, qui connaît un certain succès dans la sphère francophone (actuellement plus de 20.000 pads créés chaque mois).

Il est un service apprécié et proposé dans l'ancienne version d'Etherpad qui n'est plus présente dans la version actuelle : celle de pouvoir créer et administrer des groupes privés. Pour palier à cela, Framasoft a décidé de mener une campagne de financement participatif pour développer et maintenir le plugin « MyPads » permettant non seulement de retrouver cette fonctionnalité mais également d'avoir un compte personnel pour gérer et paramétrer ses groupes et ses pads.

L'objectif à atteindre est de 10000 €. Les détails de l'opération se trouvent sur la page de la campagne où Framasoft conclue ainsi son propos :

En installant Framapad, Framasoft a souhaité rendre un service libre (et gratuit) en incitant les internautes à faire l'expérience du travail collaboratif cher au logiciel libre. Il s'agit également de décentraliser le Web, puisque tout le monde peut installer son propre Etherpad sur son serveur, et de proposer des alternatives fiables et viables à Google et consorts dans un environnement de confiance soucieux du respect des données personnelles.
Etherpad participe au succès de Framasoft puisque Framapad est l'un de ses projets les plus actifs et dynamiques. En coordonnant cette campagne nous souhaitons rendre à Etherpad ce qu'il nous a donné en impliquant nos utilisateurs dans notre démarche et en faisant appel à tous ceux qui sont attachés au logiciel libre, à ses valeurs et à l'originalité de ses modèles économiques.

Télécharger ce contenu au format Epub

Lire les commentaires

Install Party GNU/Linux le 28 juin 2014 à Marseille

Dimanche 15 Juin

L’association CercLL (CercLL d’Entraide et Réseau Coopératif autour des Logiciels Libres) vous invite à une install party GNU/Linux, le samedi 28 juin 2014 de 14h30 à 19h30, dans la salle de la Fabulerie au 4 rue de la Bibliothèque 13001 Marseille (près du Conservatoire).

Vous avez envie de découvrir un système d’exploitation libre, simple d’utilisation, stable, rapide et sécurisé ? Une nouvelle façon d’utiliser votre ordinateur ? Vous vous sentez une affection naissante pour le Gnou et le Manchot, les mascottes de GNU/Linux ?

Au programme :

  • découverte de l’univers des logiciels libres ;
  • installation d’un environnement GNU/Linux, ainsi que le meilleur des logiciels libres ;
  • démonstration de jeux vidéo sous Linux.

Venez avec votre ordinateur nous installerons ensemble une distribution GNU/Linux avec un ensemble de logiciels libres et gratuits pour une utilisation quotidienne.

Entrée libre – accessible aux débutant-e-s.

Télécharger ce contenu au format Epub

Lire les commentaires

Retour d'expérience sur sql.js

Dimanche 15 Juin

J'aimerais parler ici de mon expérience lors du développement de sql.js, un port de SQLite en JavaScript. Pour ceux qui ne s’intéressent pas aux technologies du web, la deuxième partie de cette dépêche pourrait quand même vous intéresser, on va parler de SQLite.

Note : cette dépêche a initialement été postée en tant que journal.

Sommaire Web moderne

Ceux d'entre vous qui s'intéressent aux technologies modernes du web ont certainement entendu parler d’emscripten et d’asm.js.

Emscripten est un compilateur de bytecode LLVM en JavaScript. Il permet de compiler du code C ou C++ en JavaScript, très simplement. Le code JavaScript généré n’est bien sûr pas aussi rapide que le code natif équivalent, mais les performances sont assez bonnes. Sur Firefox, avec asm.js, le code tourne à peu près deux fois plus lentement que la version native. Le principal inconvénient que je trouve à emscripten est qu'il faut, pour l'utiliser sous Linux, télécharger et compiler sa propre version de LLVM et de clang, ce qui est long et pas pratique à mettre à jour.

asm.js, quant à lui, est un sous-ensemble de JavaScript conçu pour être facile à optimiser, et ainsi pouvoir s'exécuter rapidement. La syntaxe est dégueulasse, mais c'est pas grave, emscripten génère du code asm.js pour nous.

SQLite

Vous connaissez certainement déjà SQLite3, le moteur de bases de données le plus utilisé au monde. Si vous vous y êtes déjà un peu intéressé, vous connaissez sûrement ses caractéristiques, qui le rendent unique :

  • Une base de données est stockée dans un seul fichier.
  • Le binaire SQLite est minuscule (moins d'un Mo), et la bibliothèque SQLite peut être liée statiquement dans votre programme. Tout le code source tient dans un fichier sqlite3.c de 5 Mo.
  • Le code a été placé dans le domaine public.
  • Les données sont typées dynamiquement. Une même colonne peut contenir un entier, un nombre à virgule flottante, et une chaîne de caractères, par exemple.

Par contre, vous ne connaissez peut-être pas SQLite4, une évolution de SQLite3 (par les mêmes développeurs), qui n’a pas encore de version stable (et que j’ai aussi porté en JavaScript). Cette version apporte de bien meilleures performances, et surtout, elle utilise un système de base de données de type clef-valeur, que l'on peut changer à la volée.

Et ça, c’est génial ! Cela signifie que l'on pourra bientôt profiter de tous les avantages de SQLite même pour de grosses bases de données. Il suffira d’utiliser un système de base de données clef-valeur qui supporte les grands ensembles de données, comme LevelDB.

Quand on mélange les deux… sql.js, avant

sql.js, un port de SQLite en JavaScript, était au départ un projet de kripken, le créateur et principal mainteneur d’emscripten, qui date de début 2012. Le port fonctionnait, mais question fonctionnalités, on restait un peu sur sa faim : une seule méthode db.exec, qui exécutait du SQL et retournait les résultats dans un format pas pratique. Les données étaient toujours converties en chaînes de caractères avant d’être retournées. Le projet n’avait aucun test unitaire, le dernier commit date d’il y a plus d’un an, et l’auteur ne répond plus sur le bugtracker…

Pourtant, le projet semble avoir des utilisateurs. 104 forks et 883 stars sur github, et plusieurs téléchargements par jour sur npm à l’heure où j’écris ces lignes.

sql.js, maintenant

Je suis étudiant, et lors d’un TD, j’ai eu besoin de pouvoir tester des commandes en SQL, sur un ordi avec rien du tout d’installé. Je ne connaissais pas encore SQLfiddle, mais j’avais déjà entendu parler de sql.js, donc j’ai utilisé sa démonstration en ligne.

Le soir, en rentrant chez moi, très agaçé des petits défauts de la démonstration que j'avais utilisée, j'ai forké le projet, et commencé à travailler sur une meilleure interface graphique. Quand j'ai été content de moi, j’ai fait une pull request. Comme l’auteur tardait à répondre, j’ai commencé à bidouiller le reste du code. Et de fil en aiguille, j'ai fini par réécrire tout le code, à changer l’API pour avoir quelque chose de facile à utiliser, à ajouter des tests, de la documentation… Et je suis assez fier de l’état du projet aujourd’hui.

Il est utilisable sans modification à la fois depuis node.js, dans le navigateur, et en tant que web worker. Il est disponible sur npm, et s’utilise avec un simple :

var sql = require('sql.js'); var db = new sql.Database();

Il retourne les données dans leur format original, y-compris les BLOBs, retournés sous forme de tableau d’octets :

var res = db.exec("SELECT * FROM table1; SELECT * FROM table2"); // Ce qui peut retourner: [ {columns:['a','b'], values:[[0,'hello'],[1,'world']]}, //Le contenu de table1 {columns:['c','d'], values:[[null,[1,2,3]],[42,'blabla'],[666,666]]} //Celui de table2 // Et oui, la colonne d contient des données de types différents. C’est possible grâce à SQLite. C’est impossible avec presque tous les autres SGBD ]

Et il permet d'utiliser des requêtes préparées (prepared statements), auxquelles on associe les paramètres que l'on veut, sans risquer de vilaines injections SQL :

db.run("INSERT INTO table1 VALUES (?,?)", [3,[121,111,117,99,114,97,99,107,101,100,105,116]]);

Mais aussi :

var stmt = db.prepare("SELECT * FROM table1 WHERE a=$aval AND b=$bval"); var result = stmt.getAsObject({$aval : 1, $bval : 'world'}); // result contient maintenant: {a:1, b:'world'} Comment ça marche

SQLite est distribué sous différentes formes, dont une qui est particulièrement pratique : l’amalgamation. C’est un unique fichier .c de 5Mo qui contient tout le code, et que l’on peut compiler sans aucune bibliothèque externe:

gcc -DSQLITE_OMIT_LOAD_EXTENSION -DSQLITE_THREADSAFE=0 -c sqlite3.c

Et on peut aussi le compiler, sans aucune modification, avec emscripten. Il suffit de remplacer gcc par emcc dans la commande précédente, et le tour est joué.

Vous allez peut-être trouver bizarre que ça juste marche. En effet, le code de SQLite fait plein de trucs que l’on ne peut pas faire de base en JavaScript dans un navigateur, comme par exemple ouvrir des fichiers, ou simplement accéder à la mémoire à partir de pointeurs.

Heureusement, emscripten s’occupe de tout ça pour nous. Il fabrique un grand tableau d’entiers en JavaScript qui contiendra toute la mémoire de notre programme. Les performances ne sont pas trop mauvaises grâce aux [typed arrays (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Typed_arrays). Les pointeurs ne sont dès lors plus que des index dans ce tableau. Il implémente également les fonctions fopen, fwrite, etc. en émulant un système de fichiers entièrement en mémoire. L’inconvénient étant bien sûr que l’on a beaucoup moins de place pour stocker ses données.

Mon travail consiste alors uniquement à définir les bonnes options de compilation, et à écrire le code qui va faire l’interface entre les programmes en JavaScript et le code compilé, en JavaScript lui aussi. En effet, appeler directement le code résultant de la compilation par emscripten serait terriblement rebutant : ça parle de pointeurs partout, il faut allouer et désallouer de la mémoire dès que l’on veut faire des trucs compliqués, on n’a accès qu’à une série de fonctions, et pas à des objets qui contiennent des méthodes…

Pour avoir un code un peu plus léger, j’ai choisi le CoffeeScript, langage par excellence du web moderne.

Pour vous donner un exemple du genre de code qui fait l’interface, voilà la fonction prepare, qui permet de créer une requête préparée :

'prepare': (sql, params) -> setValue apiTemp, 0, 'i32' @handleError sqlite3_prepare_v2 @db, sql, -1, apiTemp, NULL pStmt = getValue apiTemp, 'i32' # pointer to a statement, or null if pStmt is NULL then throw 'Nothing to prepare' stmt = new Statement pStmt, this if params? then stmt.bind params @statements.push stmt return stmt

On voit bien que tout le vrai travail est fait par les fonctions compilées de SQLite, mon code se contentant de la gestion des erreurs, de la mémoire, et de la conversion des données dans un format utile au programmeur JavaScript.

Conclusion

Aujourd’hui, on fait tout ce qu’on veut sur le web, et bientôt, ce sera encore mieux. Les trucs funs qui sont pour bientôt : ECMASCRIPT 6, aka Harmony, emscripten SDK pour Linux, sqlite4.js

Télécharger ce contenu au format Epub

Lire les commentaires

Sortie de Glances version 2.0

Dimanche 15 Juin

Après plusieurs mois de développement (5 pour être précis), la nouvelle version majeure de Glances (version 2.0) arrive dans les bacs. Nous allons dans cette dépêche détailler les évolutions par rapport à la version précédente et effectuer un focus sur les nouveautés.

Avant de commencer et pour ceux qui ne connaissent pas encore Glances, voici une définition de l'objectif de ce logiciel: "Glances est un outil permettant d'identifier le plus simplement possible les problèmes de performance d'une machine".

Pour cela il dispose d'une interface regroupant le maximum de statistiques système utiles dans un minimum de place. Les interfaces mise à disposition de l'utilisateur dans cette version sont : interface texte (Curse) pour les consoles & terminaux, mode client/serveur, interface Web (pure HTML/CSS), interface programmatique via une API.

Glances est multiplate-forme: GNU/Linux, *BSD, OS X et Windows.

Sommaire

Les évolutions CLI

Le diable étant dans les détails. Une optimisation de l'affichage de chacun des modules a été effectuée. De plus, l'interface occupe tout l'espace disponible dans le terminal ou la console.

Pour les habitués de la version 1, voici quelques changements à prendre en compte:

  • la statistique "CPU steal" n'est plus loguée en cas de dépassement des limites, seules les statistiques CPU user, system et iowait le sont ;

  • le log de la charge de la machine est affiché sur la statistique 15 minutes et non plus sur 5 minutes et 15 minutes ;

  • afin d'améliorer la lisibilité, les statistiques "sensors" (température des disques et batteries) sont réunies dans un même bloc ;

  • les colonnes des statistiques des processus ont été ré-organisées ;

Fichier de configuration

La structure du fichier de configuration a été reprise. Ainsi, il va falloir adapter votre configuration existante pour cette nouvelle version. On trouve notamment une fonction permettant de fixer les alertes sur le débit des interfaces réseau. Par exemple pour une liaison ADSL :

# Default limits (in bits per second aka bps) for interface bitrate wlan0_rx_careful=4000000 wlan0_rx_warning=5000000 wlan0_rx_critical=6000000 wlan0_tx_careful=700000 wlan0_tx_warning=900000 wlan0_tx_critical=1000000 API

L'API a également été revue pour améliorer la sécurité. Ainsi, dans le mode client/serveur, plus aucun mot de passe ne transite en clair sur le réseau en plus d'un encodage SHA256.

La documentation de cette nouvelle version de l'API est disponible sur cette page.

Les nouveautés L'interface Web

Avant de me faire jeter des pierres par des barbus énervés, sachez que cette nouvelle interface est un réel besoin remonté par les utilisateurs. Ils souhaitaient disposer d'une interface Web pour surveiller leurs machines depuis n'importe quel poste fixe ou mobile. J'ai donc supprimé le mode d'exportation au format HTML (basé sur Jinja) pour le remplacer par un service Web intégré (utilisant le framework Bottle).

Une fois Glances lancé avec l'option -w, on dispose ainsi d'une interface Web "responsive":

$ glances -w Bottle v0.12.5 server starting up (using WSGIRefServer())... Listening on http://0.0.0.0:61208/ Hit Ctrl-C to quit.

Ce qui donne dans un navigateur Web d'un PC:

ou dans celui d'une tablette:

Les prochaines versions amélioreront encore cette interface avec notamment des fonctions de tri des colonnes, de configuration du taux de rafraîchissement (par défaut à 5 secondes) et de thèmes pour n'afficher que les informations que vous jugez utiles.

Le "fallback SNMP" dans le mode client/serveur

Depuis sa version 1.3, il est possible d'utiliser Glances en mode client/serveur afin de superviser ses machines à distance. Pour cela, il suffit de lancer le serveur avec l'option -s :

serveur$ glances -s Glances server is running on 0.0.0.0:61209

Puis le client sur une machine distante:

client$ glances -c <@IP serveur>

La version 2.0 apporte une nouvelle fonction de fallback SNMP au client. Ainsi, si le serveur Glances n'est pas detecté sur la machine serveur, Glances essaye de récupérer les statistiques en utilisant des requêtes SNMP.

Note: pour l'instant, ce mode est expérimental et ne fonctionne que dans certains cas (serveur SNMP v2/2c sous GNU/Linux). L'équipe de développement a besoin de contributeurs pour faire évoluer cette fonction et l'ouvrir à d'autres type de matériel (autres OS, routeurs Cisco…).

Gestion des limites au niveau serveur

Les limites (CAREFUL, WARNING et CRITICAL) sont maintenant fixées au niveau du serveur et non plus du client comme dans les versions précédentes. La méthode getAllLimits() de l'API permet de récupérer ces limites.

Comme dans la version 1.x, les limites peuvent être modifiées dans le fichier de configuration (/etc/glances/glances.conf par défaut sous GNU/Linux).

Et celles que l'on ne voit pas…

…ou celles qui ne sont pas vues par l'utilisateur final. Glances v2.0 n'est pas qu'une simple mise à jour de la version 1.0 mais une refonte complète de l'architecture logicielle. Ainsi, le découpage en plugins des différentes fonctions (d'entrées et de sorties) va permettre à l'équipe de développement une plus grande souplesse pour l'ajout de nouvelles fonctions dans les prochaines versions. Chaque fonction de récupération de statistiques est isolée dans un plugin disposant de méthodes (voir par exemple celui de récupération des statistiques de la mémoire vive).

Au niveau du processus de développement, le passage à cette deuxième version a coïncidé avec l'utilisation du workflow Git Flow. Une page a été rédigée dans le Wiki pour expliquer le workflow à suivre pour les corrections et les améliorations de la version de développement.

Installation et mise à jour de Glances

Glances est disponible dans les dépôts de la plupart des distributions GNU/Linux. En attendant que les packagers fassent leur boulot, il est possible d'installer cette dernière version via pip :

Installation:

pip install glances

Note : PsUtil, la bibliothèque Python permettant à Glances de récupérer les statistiques de votre machine, nécessite l'installation préalable des headers Python (apt-get install python-dev sous Debian). Pour une procédure d'installation plus détaillée, je vous conseille la lecture de la documentation officielle.

Mise à jour :

pip install --upgrade glances

Certaines fonctions (comme le mode serveur Web) nécessite l'installation de bibliothèques tierces (Glances vous alerte automatiquement s'il lui en manque une). Pour installer la totalité des bibliothèques vous pouvez saisir la commande suivante :

pip install glances pysnmp bottle batinfo https://bitbucket.org/gleb_zhulik/py3sensors/get/tip.tar.gz

Et après ?

L'équipe de développement a déjà quelques idées de nouvelles fonctionnalités : amélioration du mode fallback SNMP, création d'une API REST, refonte de l'IA pour une mise en évidence encore plus précise des problèmes…

Glances est un projet open-source sous licence LGPL. Il a donc besoin de contributeurs pour continuer à évoluer.

Télécharger ce contenu au format Epub

Lire les commentaires

Rendez-vous Python à Nantes le 24 Juin

Samedi 14 Juin

Après le premier rendez-vous d'avril qui avait permis de découvrir GrapheekDB, nous vous invitons à un deuxième rendez-vous des amateurs du langage Python, le mardi 24 juin à 19h à la cantine du numérique de Nantes.

Chacun sera invité a présenter qui il est, ses centres d'intérêts et pourquoi il est intéressé par Python (ou pas !). Les éventuelles présentations courtes de projets sont bienvenues.

Une key-signing party sera également proposée durant l'événement.

Qui veut prolongera l'événement autour d'une bière !

Télécharger ce contenu au format Epub

Lire les commentaires

Les rencontres Futurism

Samedi 14 Juin

Les rencontres Futurism se dérouleront les 28 et 29 juin 2014 au jardin Compans Caffarelli à Toulouse à l'occasion du festival Les Siestes Electroniques.

Futurism est un moment privilégié pour échanger autour de la musique aujourd’hui, de sa fabrication, de sa revalorisation par le numérique, de ses aspects esthétiques, économiques comme sociétaux. Ateliers, débats, démos… le tout gratuit, à l’ombre des arbres, pourquoi pas pieds nus, un café à la main…

Une intervention sur la musique libre, présentée par un membre de Framazic, sera notamment proposée.

Télécharger ce contenu au format Epub

Lire les commentaires

[ZOL] - ZFS On Linux 0.6.3 released

Samedi 14 Juin

La version 0.6.3 de ZOL (ZFS On Linux) vient fraîchement d'être mise à disposition. Bien que n'ayant que peu communiqué (sur la liste de discussion en tout cas), depuis la dernière version sortie en août 2013, les développeurs du projet n'ont pas chômé puisqu'il y a eu près de 200 corrections de bugs et de nombreuses fonctionnalités ajoutées au projet avec notamment : la compatibilité pour les noyaux Linux >= 3.14, la comptabilité avec les ACL POSIX et un nouvel outil de supervision dédié le ZED daemon.

Fonctionnalités clés :

  • Compatible avec les noyaux Linux jusqu'à la version 3.14.
  • Meilleure gestion du ralentissement en écriture pour maintenir les performances lors d'un forte charge.
  • Cache plus intelligent pour améliorer le taux d'accès à certains niveaux de charges.
  • Gestion des ACL type Posix.
  • Gestion des attributs immutable : les ajouts seuls sur les fichiers.
  • Possibilité de monter les systèmes de fichiers avec mise à jour à chaud.
  • Intégration SELinux à travers quatre nouveaux ensembles de propriétés.
  • Support de systemd.
  • Apparition du ZFS Event Daemon (ZED) pour gérer et surveiller.
  • Gestion des architectures arch64 et sparc64.
  • Beaucoup d'amélioration de performances.
  • Plus de 200 bug corrigés.
Télécharger ce contenu au format Epub

Lire les commentaires

Conférence Transformer et enrichir vos données avec OpenRefine (Mons, BE)

Samedi 14 Juin

Ce jeudi 19 juin 2014 à 19h se déroulera la 30ème séance montoise des Jeudis du Libre de Belgique.

Le sujet de cette séance : Transformer et enrichir vos données avec OpenRefine

Thématique : Traitement des données
Public visé : chefs de projet | entreprises | développeurs | étudiants
Animateur conférencier : Max De Wilde (ULB)

Description : Quel que soit le domaine d’application (scientifique, culturel, financier, biopharma, etc.), manipuler de gros volumes de données implique inévitablement une déperdition de leur qualité, surtout quand ces données ont été encodées par de nombreuses personnes, dans plusieurs langues et/ou sur un long laps de temps.

OpenRefine est un outil interactif de transformation qui permet de diagnostiquer les problèmes de qualité dans un jeu de données et de les corriger dans la foulée, ainsi que d’enrichir les données sémantiquement.

Cette présentation abordera successivement les points suivants :

  • Big Data vs Data Quality ou comment concilier quantité et qualité ?
  • De Google Refine à OpenRefine : historique d’un projet cédé à la communauté
  • Raffinement des données : du minerai brut au diamant pur
  • Vers un web de données : liaison avec le Linked Data Cloud
  • La représentation des connaissances, un enjeu économique et politique

Les différentes fonctionnalités du logiciel seront illustrées à l’aide d’une collection de données ouvertes issues du domaine muséal, mais suivant une méthodologie applicable à n’importe quel autre domaine. Les retombées opérationnelles de l’utilisation d’OpenRefine seront illustrées à travers le projet Free Your Metadata (freeyourmetadata.org).

Lieu de cette séance : HEPH Condorcet, Chemin du Champ de Mars, 15 – 7000 Mons – Auditorium 2 situé au rez de chaussée (cf. ce plan sur le site d’OpenStreetMap; ATTENTION, l’entrée est peu visible de la voie principale, elle se trouve dans l’angle formé par un très grand parking).

La participation sera gratuite et ne nécessitera que votre inscription nominative, de préférence préalable, ou à l’entrée de la séance. Merci d’indiquer votre intention en vous inscrivant via la page http://jeudisdulibre.fikket.com/

Cette séance sera suivie d’un verre de l’amitié, offert par la Catégorie Économique de la Haute École Condorcet.

Si vous êtes intéressé(e) par ce cycle mensuel, n’hésitez pas à consulter l’agenda et à vous inscrire sur la liste de diffusion afin de recevoir systématiquement les annonces.

Pour rappel, les Jeudis du Libre se veulent des rencontres autour de thématiques des Logiciels Libres. Les rencontres montoises se déroulent chaque troisième jeudi du mois, et sont organisées dans des locaux et en collaboration avec des Hautes Écoles et Facultés Universitaires du Pôle Hainuyer d’enseignement supérieur impliquées dans les formations d’informaticiens (UMONS, HEH et Condorcet), et avec le concours de l’A.S.B.L. LoLiGrUB, active dans la promotion des logiciels libres.

Télécharger ce contenu au format Epub

Lire les commentaires

Faites une bonne action : contactez vos élus territoriaux

Samedi 14 Juin

Contrairement à l'Etat et ses ministères qui passent tranquillement aux logiciels libres, au moins pour la bureautique, les collectivités territoriales ont un gros retard à ce sujet-là, et c'est là qu'on observe le plus de résistance au changement.

C'est pourtant le moment de contacter vos élus territoriaux sur ce thème (maires, adjoints et conseillers municipaux, conseillers généraux et régionaux, élus des communautés de communes). En effet, après les élections, ils ont tous reçu la bonne nouvelle de la baisse des « Dotations de l'État ». Qu'est-ce donc ? Il s'agit de sommes versées par l'État aux collectivités territoriales pour leur fonctionnement. Le problème est que les baisses sont importantes d'année en année (et dans les 5% cette année). Pour résumer, beaucoup sont ou seront financièrement en difficulté.

C'est donc le moment de les interpeller au sujet des logiciels libres, sources d'économies mais pas seulement (insister sur le « pas seulement »).

Les économies sont de quel ordre de grandeur ? C'est là que le cas de Munich peut vous aider. Un premier article de Zdnet a estimé le potentiel d'économies à 9€ par habitant, Munich comptant 1.3 million d'habitants. Un deuxième article annoncerait quant à lui un total 4 M€/an d'économies.

Or ces économies sont récurrentes, puisqu'à chaque renouvellement de poste (tous les 6 ans environ en logiciels propriétaires), il faut prévoir le renouvellement du Windows et de la plupart des logiciels propriétaires qui ne sont plus compatibles avec la nouvelle version de Windows installée.

Mais attention, l'argument économique n'est pas suffisant, il faut convaincre les élus et le personnel de la pertinence de la démarche : ce n'est pas gagné.

Télécharger ce contenu au format Epub

Lire les commentaires

Mise aux poings sur systemd

Vendredi 13 Juin

systemd est un gestionnaire du système et de services (aussi appelé « PID 1 », car c’est le premier processus à être lancé) pour Linux, compatible avec SysV et les scripts d’init LSB. systemd a des capacités de parallélisation énergiques. Il utilise les sockets et l’activation par D-Bus pour démarrer les services, permettant le démarrage à la demande des démons. Il surveille et commande les processus avec les groupes de contrôle (cgroups) Linux. Il prend en charge la construction d’instantanés et la restauration de l’état du système. Il maintient les points de montage et d’auto-montage, et implémente une logique de contrôle transactionnelle élaborée fondée sur les dépendances entre services.

systemd ne fait pas partie du projet freedesktop.org, bien qu’hébergé sur le site. Il est codé en langage C et publié sous licence GNU GPL 2.1+. Il a été lancé par Lennart Poettering, auteur de PulseAudio et d'Avahi entre autres, et est maintenant activement développé par plusieurs dizaines de développeurs.

La dernière dépêche concernant systemd a suscité de nombreuses réactions et certaines d'entre elles montraient une méconnaissance de ce logiciel : la dépêche se contentait, pour la majeure partie il est vrai, de traduire les notes de versions.

Je vais donc faire un point sur systemd, histoire d’en finir une bonne fois pour toutes avec les discussions sans fin sur systemd (l’espoir fait vivre).

Sommaire

Ce qui suit est en grande partie une traduction d’un article Les 30 plus grands mythes à propos de systemd paru en janvier 2013 sur le site de Lennart Poettering.

Donc à partir de maintenant et jusqu’à la fin, c’est Lennart Poettering qui (indirectement) parle !

Depuis la première proposition d’inclusion de systemd au sein des distributions, on en a fréquemment parlé sur de nombreux forums, listes de diffusion et conférences. Dans ces discussions, on peut souvent entendre certains mythes à propos de systemd, qui sont répétés encore et encore, sans que cette répétition ne les rende vrais pour autant. Prenons le temps d’en briser quelques-uns :

systemd est monolithique

systemd est constitué de plus de 70 binaires (NdT : 72 sur ma machine !) clairement séparés. D’une part, systemd a été conçu pour être sécurisé : chaque binaire effectue une tâche très spécifique avec des privilèges minimaux — en utilisant les capacités (capabilities) du noyau par exemple — pour réduire la surface d’attaque et l’impact de failles de sécurité. Cela rend également systemd plus robuste et plus facile à faire évoluer et à déboguer. D’autre part, cette séparation est essentielle pour que systemd puisse lancer ces binaires en parallèle. Beaucoup d'entre eux sont même si bien séparés qu’ils peuvent aussi être utiles en dehors de systemd (systemd-detect-virt, systemd-tmpfiles ou systemd-udevd, par exemple).

Un ensemble de plusieurs dizaines de binaires peut difficilement être qualifié de monolithique. À la différence de ce qui se pratiquait auparavant, les composants sont dans une seule archive, et ils sont tous maintenus en amont dans un seul dépôt avec un cycle de publication unifié — ce qui est sans doute bénéfique au bon fonctionnement de l’ensemble.

systemd a été conçu pour la vitesse

Oui, systemd est rapide (on peut obtenir un espace utilisateur presque complet en à peu près 900 ms !), mais c’est principalement un effet secondaire d’avoir fait les choses correctement. En fait, nous n’avons jamais essayé d’optimiser chaque parcelle de systemd ; au contraire, nous avons fréquemment choisi en toute connaissance de cause un code légèrement plus lent en faveur de la lisibilité du code. Cela ne veut pas dire que la vitesse ne nous intéresse pas, mais réduire systemd à sa vitesse est une idée fausse, car ce n’est pas du tout dans nos priorités.

La vitesse de systemd ne sert à rien pour les serveurs !

C’est complètement faux. Beaucoup d’administrateurs désirent réduire les temps d’arrêt des fenêtres de maintenance. Pour les configurations à haute disponibilité, c’est sympathique d’avoir une machine indisponible qui redevient très vite disponible (le besoin utilisateur étant « toujours disponible », même s’ils oublient les interventions techniques (montée de version de logiciel, d’OS…), vu qu’ils ont une approche « nos utilisateurs » pour lesquels une nouvelle version ne correspond qu’à des ajouts, pas des régressions…). Pour les configurations dans les nuages avec un nombre important de machines virtuelles ou de conteneurs, le cout d’un démarrage lent est multiplié par le nombre d’instances. Passer plusieurs minutes de temps CPU et d’entrées/sorties sur des démarrages très lents de milliers de machines virtuelles ou de conteneurs réduit la densité de votre système de façon importante, cela vous coute même plus d’énergie. Un démarrage lent peut vous couter beaucoup d’argent, alors qu’un démarrage rapide permet d’implémenter une logique d’activation de conteneurs par socket pour augmenter la densité de votre système dans les nuages.

Bien entendu, pour la plupart des configurations de serveur, le temps de démarrage n’est pas intéressant, mais systemd est censé couvrir le plus de cas possibles. Et oui, je suis au courant que c’est souvent le micrologiciel du serveur qui prend le plus de temps au démarrage, et que le système d’exploitation démarre vite en comparaison, mais tous les serveurs n’ont pas un aussi mauvais micrologiciel, et certainement pas les machines virtuelles ni les conteneurs, qui sont un type de machine virtuelle également.

Note : nous essayons de faire notre petite part pour rendre les micrologiciels meilleurs. En mettant les performances de démarrage du micrologiciel en évidence dans la sortie de systemd, nous espérons que la honte poussera les auteurs de micrologiciels à nettoyer leur travail.

systemd est incompatible avec les scripts shell

C’est complètement bidon. Nous ne les utilisons pas pour le processus de démarrage parce que nous pensons qu’ils ne sont pas le meilleur outil pour cette tâche spécifique, mais cela ne signifie pas que systemd n’est pas compatible avec eux. Vous pouvez facilement lancer des scripts shell en tant que service systemd, systemd n’a strictement rien à faire de ce qui est à l’intérieur de votre exécutable. De plus, nous utilisons énormément les scripts shell pour installer, construire et tester systemd. Et vous pouvez continuer à utiliser vos propres scripts très tôt dans le démarrage, les utiliser comme des services normaux, les lancer à l’extinction de la machine, il n’y a quasiment aucune limite.

systemd est compliqué

C’est aussi un non-sens total. Une plateforme systemd est en réalité beaucoup plus simple que les Linux traditionnels, car elle unifie le système d’objets et leurs dépendances en unités systemd. Le langage des fichiers de configuration est très simple et on se débarrasse des fichiers de configuration redondants. Nous fournissons des outils uniformes pour la plupart des tâches de configuration du système. Le système est beaucoup moins aggloméré que les Linux traditionnels. Nous avons également une documentation plutôt complète (tout est présent sur la page d’accueil) sur à peu près tous les détails de systemd, et cela ne couvre pas seulement les interfaces pour utilisateur et administrateur, mais également les API pour les développeurs.

systemd nécessite bien sûr un apprentissage. Comme toute chose. Cependant, nous aimons croire que c’est vraiment plus simple de comprendre systemd qu’un démarrage fondé sur des scripts shell pour la plupart des gens. Surpris de ces paroles ? Eh bien, il s’avère que le shell n’est pas un langage sympathique à apprendre, sa syntaxe est obscure et complexe. Les fichiers unités de systemd sont beaucoup plus simples à comprendre, ils ne nous exposent pas à un langage de programmation, mais sont simples et déclaratifs par nature. Cela dit, si vous avez de l’expérience en shell, en effet, adopter systemd vous demandera un petit peu d’apprentissage.

Afin de rendre l’apprentissage facile, nous avons fait notre maximum pour fournir une compatibilité avec les solutions précédentes. De plus, sur de nombreuses distributions, vous remarquerez que certains des outils traditionnels vous diront — en faisant ce que vous leur aviez demandé — comment vous pourriez le faire avec les nouveaux outils à la place, possiblement d’une façon plus agréable.

Bref, systemd ne peut probablement pas être plus simple qu’il ne l’est déjà pour la tâche qu’il remplit, et nous avons travaillé dur pour qu’il soit simple à apprendre. Alors oui, si vous connaissez sysvinit alors adopter systemd va vous demander un peu d’apprentissage ; mais franchement, si vous maitrisez sysvinit, alors systemd devrait être facile pour vous.

systemd n’est pas modulaire

Tout faux. À la compilation, il y a beaucoup d’options de configuration pour choisir ce que vous voulez compiler ou non. Et nous documentons comment sélectionner encore plus en détail ce dont vous avez besoin, en allant plus loin que les options de configuration.

Cette modularité n’est pas totalement différente de celle du noyau Linux, où vous pouvez sélectionner beaucoup de fonctionnalités individuellement à la compilation. Si le noyau est assez modulaire pour vous, alors systemd l’est probablement.

systemd est seulement pour les ordinateurs de bureau

Ce n’est certainement pas vrai. Avec systemd, nous essayons à peu près de couvrir la même portée que Linux. Alors, que nous tenons compte des usages bureautiques, nous tenons aussi compte des usages serveur, ainsi que des usages embarqués. Vous pouvez parier que Red Hat ne voudrait pas en faire une pièce centrale de RHEL 7 si ce n’était pas la meilleure option pour gérer les services des serveurs.

Des personnes de différentes entreprises travaillent sur systemd. Les fabricants de voitures l’intègrent dans leurs voitures, Red Hat l’utilise pour ses systèmes d’exploitation pour serveurs, et GNOME utilise nombre de ses interfaces afin d’améliorer le bureau. Vous le trouvez dans les jouets, les télescopes et dans les éoliennes.

La plupart des fonctionnalités sur lesquelles j’ai travaillé récemment, relèvent du domaine des serveurs, comme le support des conteneurs, le management des ressources ou des fonctionnalités de sécurité. Nous couvrons plutôt bien les systèmes bureautiques pour le moment, et il y a de nombreuses entreprises faisant du développement sur systemd pour l’embarqué, certaines offrent même des services de consultance pour lui.

systemd est un résultat du syndrome NIH (NdT : Not Invented Here, « Pas inventé ici »)

Ce n’est pas vrai. Avant que nous commencions à travailler sur systemd, nous poussions l’adoption à grande échelle d’Upstart (et Fedora/RHEL l’utilisent également depuis un moment). Cependant, nous sommes finalement arrivés à la conclusion que le cœur de sa conception présentait des défauts (au moins à nos yeux : plus fondamentalement, il laisse la gestion des dépendances à l’administrateur/au développeur, au lieu de résoudre ce problème difficile dans le code) et, si quelque chose ne va pas dans le cœur, il vaut mieux le remplacer que de le corriger. Ça n’est pas la seule raison cependant, d’autres choses ont joué, comme le bordel autour du CLA. NIH n’était cependant pas une des raisons…

Note : et puis, devinez quel projet inclut une bibliothèque « libnih » — Upstart ou systemd ? (indice : ça n’est pas systemd !)

systemd est un projet freedesktop.org

Ma foi, c’est vrai que systemd est hébergé sur fdo, mais freedesktop.org n’offre pas grand-chose de plus qu’un dépôt pour le code et la documentation. À peu près tous les développeurs peuvent demander de l’espace et déposer leurs affaires ici (à condition d’avoir un vague rapport avec l’infrastructure des systèmes libres). Il n’y a pas de cabale, pas de processus de standardisation, pas de vérification de projet, rien. C’est juste un hébergement sympa, gratuit et solide pour mettre un dépôt. De ce point de vue, c’est un peu comme sourceforge, github, kernel.org, mais de nature non commerciale et sans demandes excessives et donc, un bon endroit où mettre notre projet.

Donc oui, nous avons choisi fdo pour l’hébergement, mais l’hypothèse implicite de ce mythe, qu’il existe un groupe de gens qui se rencontrent et qui décident du futur des systèmes libres, est entièrement fausse.

systemd n’est pas UNIX

Il y a certainement du vrai en cela. Les sources de systemd ne contiennent pas une seule ligne de code héritée de l’UNIX originel. En revanche, notre inspiration nous vient d’UNIX et c’est pourquoi il y a beaucoup d’UNIX en systemd. Par exemple, l’idée d’UNIX du « tout est fichier » trouve son jumeau dans systemd où tous les services sont exposés au lancement dans un système de fichiers du noyau, le cgroupfs. Ensuite, une des fonctionnalités originelles d’UNIX était celle des multi-terminaux (multi-seat), basée sur la prise en charge des consoles (terminaux d'ordinateurs). Les consoles en mode texte ne sont pas vraiment la manière dont vous interagissez avec votre ordinateur de nos jours. Avec systemd, nous avons apporté le retour de la gestion des multi-terminaux, mais cette fois avec la gestion complète des composants modernes, des cartes graphiques aux souris, systèmes audio, webcams et bien plus, et tout cela complètement automatique, branchements à chaud et sans configuration. En effet, le design de systemd en tant que suite d’outils intégrés dont chacun a ses buts propres, voilà la philosophie du cœur d’UNIX. Ensuite, la façon dont notre projet est géré (c'est-à-dire maintenir la majeure partie du cœur de l’OS dans un unique répertoire git) est plus proche du modèle BSD (qui est un vrai UNIX, pas comme Linux) dans la façon de faire (où la plus grande partie du cœur de l’OS est conservé dans un seul répertoire CVS/SVN) que de la façon de faire de Linux.

Enfin, UNIX est quelque chose de différent pour chacun. Pour nous, les mainteneurs de systemd, c’est quelque chose dont nous nous inspirons. Pour d’autres, c’est une religion, et tout comme les autres religions du monde, il y a différentes façons de lire ou d’interpréter. Certains définissent UNIX comme un héritage de certains bouts de codes spécifiques, d’autres le voient juste comme un ensemble d’idées, d’autres comme un ensemble de commandes, et d’autres encore comme une définition de comportements. Bien sûr, il est impossible de faire en sorte que toutes ces personnes soient heureuses.

Finalement, la question de savoir si quelque chose est UNIX ou non importe vraiment peu. Être techniquement excellent n’est pas exclusif à UNIX. Pour nous, UNIX est une influence majeure (zut, la plus grosse), mais nous avons aussi d’autres influences. Ainsi, dans certains domaines systemd sera vraiment UNIX et dans d’autres un peu moins.

systemd est complexe

Il y a un fond de vérité à cela. Les ordinateurs modernes sont des choses complexes et le système qui tourne dessus doit donc être complexe aussi. Toutefois, systemd n’est pas plus complexe que les implémentations précédentes des mêmes composants. Au contraire, il est plus simple et réduit les redondances (voir plus haut). De plus, construire un système simple basé sur systemd impliquera moins de paquets qu’un système Linux traditionnel. Avoir moins de paquets facilite la construction du système et permet de se débarrasser des interdépendances et des comportements divergents de chaque composant impliqué.

systemd est une usine à gaz

Hé bien, il y a probablement plusieurs définitions de « usine à gaz ». Mais dans la plupart des définitions, systemd est probablement l’opposé d’une usine à gaz. Vu que les composants systemd partagent une base de code commune, ils ont tendance à partager plus de code pour les fonctions générales. Voici un exemple : dans une configuration Linux traditionnelle, sysvinit, start-stop-daemon, inetd, cron, dbus implémentent tous une façon de lancer des processus avec des options de configuration variées dans un environnement que l’on espère propre. Dans systemd, les fonctions pour tout ceci, que ce soit le parsing (NdT : analyse syntaxique si vous y tenez vraiment) de la configuration ou le lancement lui-même, sont partagées. Cela se traduit par moins de code, moins de place pour faire des erreurs, moins de mémoire occupée et moins de pression sur le cache, et donc c’est une très bonne chose. Et en plus, vous gagnez une tonne de nouvelles fonctionnalités grâce à ça.

Comme mentionné plus haut, systemd est aussi plutôt modulaire. Vous pouvez choisir à la compilation les composants dont vous avez besoin et ceux dont vous pouvez vous passer. De sorte que les gens peuvent choisir à quel point systemd est une « usine à gaz ».

Quand vous compilez systemd, il ne demande que 3 dépendances : glibc, libcap et dbus. C’est tout. Il peut utiliser beaucoup plus de dépendances, mais elles sont toutes entièrement optionnelles.

Donc oui, sous tous les angles, ce n’est vraiment pas une usine à gaz.

systemd seulement pour Linux, pas sympa pour les BSD

Complètement faux. Les gens de chez BSD ne sont pas vraiment intéressés par systemd. Si systemd était portable, cela n’aurait rien changé, ils ne voudraient pas l’adopter quand même. Et la même chose est vraie pour les autres Unix dans le monde. Solaris a SMF, BSD a son propre système rc, et ils l’ont toujours maintenu séparément de Linux. Le système d’initialisation est très proche du cœur du système d’exploitation. Et ces autres systèmes d’exploitation se définissent eux-mêmes, entre autres choses, par le cœur de leur espace utilisateur. L’hypothèse qu’ils aient adopté notre cœur d’espace utilisateur si nous l’avions juste rendu portable est sans aucun fondement.

systemd seulement pour Linux empêche son adoption comme système d’initialisation par défaut sur Debian

NdT : Debian est déjà passée à systemd, mais on traduit aussi cette partie pour le plaisir. :p

Debian prend en charge des noyaux non-Linux dans leur distribution. systemd ne fonctionnera pas sur ceux-ci. Est-ce que c’est cependant un problème, et cela doit-il gêner l’adoption de systemd par défaut ? Pas vraiment. Les gens qui ont porté Debian sur ces noyaux sont prêts à investir du temps dans un portage qui demande beaucoup de travail, ils ont mis en place des systèmes de tests et de compilation, patché et compilé de nombreux paquets pour atteindre ce but. La maintenance à la fois d’une unité systemd et d’un script d’initialisation classique pour les services empaquetés est une charge de travail négligeable comparé à cela, en particulier parce que le plus souvent ces scripts existent déjà.

systemd pourrait être porté sur d’autres noyaux si ces mainteneurs le voulaient

C’est tout simplement faux. Faire un portage de systemd sur d’autres noyaux n’est pas faisable. Nous utilisons trop d’interfaces spécifiques à Linux. Pour certaines, on peut trouver des remplacements sur les autres noyaux, pour d’autres nous pourrions les désactiver, mais pour la plupart, ce n’est vraiment pas possible. Voici une petite liste non exhaustive: cgroups, fanotify, umount2(), /proc/self/mountinfo (incluant les notifications), /dev/swaps (de même), udev, netlink, la structure de /sys, /proc/$PID/comm, /proc/$PID/cmdline, /proc/$PID/loginuid, /proc/$PID/stat, /proc/$PID/session, /proc/$PID/exe, /proc/$PID/fd, tmpfs, devtmpfs, capacités, espaces de nommages en tout genre, divers prctl()s, de nombreux ioctls, l’appel système mount() et sa sémantique, SELinux, audit, inotify, statfs, O_DIRECTORY, O_NOATIME, /proc/$PID/root, waitid(), SCM_CREDENTIALS, SCM_RIGHTS, mkostemp(), /dev/input, et ainsi de suite.

Si vous regardez cette liste et prenez les quelques éléments auxquels vous pouvez trouver un équivalent évident dans d’autres noyaux, alors réfléchissez à nouveau, et regardez ceux que vous n’avez pas considérés et la complexité nécessaire pour les remplacer.

systemd n’a pas de raison ne pas être portable

Ça n’a aucun sens ! Nous utilisons des fonctions spécifiques à Linux parce que nous en avons besoin pour implémenter ce que nous voulons. Linux a beaucoup de fonctionnalités qu’UNIX/POSIX n’a pas, et nous voulons que les utilisateurs puissent en tirer parti. Ces fonctions sont incroyablement utiles, mais seulement si elles sont offertes de manière conviviale à l’utilisateur et c’est ce que nous voulons faire avec systemd.

systemd utilise des fichiers de configuration binaire

Je n’ai aucune idée d’où est sorti ce mythe fou, mais ça n’est absolument pas vrai. systemd est configuré quasi exclusivement par de simples fichiers textes. Vous pouvez également modifier quelques options avec la ligne de commande du noyau ou par des variables d’environnement. Il n’y a rien de binaire dans sa configuration (même pas de XML). Seulement des fichiers en texte brut, simples, et faciles à lire.

systemd est un cauchemar de fonctionnalités

Eh bien, systemd couvre certainement plus de terrain que par le passé. Ce n’est plus uniquement un système d’initialisation, mais le bloc de base de l’espace utilisateur à partir duquel construire un système d’exploitation ; mais nous faisons attention de garder optionnelles la plupart des fonctionnalités. Vous pouvez en désactiver beaucoup lors de la compilation, et encore plus lors de l’exécution. Ainsi pouvez-vous choisir librement combien de fonctionnalités injecter.

systemd vous force à faire quelque chose

systemd n’est pas la mafia. C’est un logiciel libre, vous pouvez en faire ce que vous voulez, ce qui inclut ne pas l’utiliser. C’est plutôt l’opposé de « forcer ».

systemd rend impossible l’utilisation de syslog

C’est faux, nous avons fait attention lors de l’introduction du journal à ce que les informations soient transmises au serveur syslog. En fait, s’il y a bien une chose qui a changé, c’est surtout le fait que syslog reçoit maintenant plus d’informations, car nous nous occupons du début du démarrage système ainsi que des flux STDOUT/STDERR de tous les services du système.

systemd est incompatible

Nous faisons de notre mieux pour garantir la meilleure compatibilité possible avec sysvinit. En fait, la grande majorité des scripts d’initialisation fonctionne telle quelle sous systemd, sans modifications. Toutefois, il y a effectivement quelques incompatibilités, mais nous essayons de les documenter et d’expliquer comment y réagir. En fin de compte, tout système qui n’est pas systemd aura une certaine dose d’incompatibilité avec lui vu qu’il n’aura pas exactement la même structure d’exécution.

Notre but est que les différences entre les multiples distributions restent à un niveau minimum. Cela implique que les fichiers unité fonctionnent généralement bien sur une distribution différente de celle où ils ont été conçus, ce qui est un énorme progrès sur les scripts classiques d’initialisation qui sont très difficiles à écrire d’une façon portable à d’autres distributions Linux, compte tenu des nombreuses incompatibilités entre elles.

systemd n’est pas scriptable, à cause de son utilisation de D-Bus

Ce n’est pas vrai. Presque chaque interface D-BUS que fournit systemd est aussi accessible via un outil en ligne de commande, par exemple dans systemctl, loginctl, timedatectl, hostnamectl, localectl et autres. Vous pouvez aisément appeler ces outils depuis des scripts shell, ils donnent accès à pratiquement toute l’API depuis la ligne de commande avec des commandes faciles d’emploi.

Cela dit, D-Bus a aussi une interface (NdT : bindings) pour presque tous les langages de script de ce monde. Même depuis le shell on peut invoquer des méthodes D-Bus quelconques avec dbus-send ou gdbus. Finalement, cela facilite son utilisation dans des scripts grâce à la bonne gestion de D-Bus par les différents langages de script.

systemd requiert l’utilisation d’obscurs outils de configuration au lieu d’éditer des fichiers textes directement

Ce n’est pas vrai du tout. Nous proposons des outils de configuration, et leur utilisation vous fournit de quelques fonctionnalités complémentaires (par exemple, la complétion en ligne de commande de tous les paramètres !), mais ils ne sont en rien nécessaires. On peut toujours modifier les fichiers en question directement si on le souhaite, et c’est totalement accepté. Bien sûr que quelquefois on a besoin de recharger explicitement la configuration d’un démon après l’avoir modifiée, mais ceci est vrai de la plupart des services UNIX.

systemd est instable et bogué

Selon nos données, certainement pas. Nous analysons minutieusement le système de suivi de bogues (NdT : bugtracker) de Fedora (et d’autres) depuis longtemps. Le nombre de bogues est très faible pour un tel composant central du système d’exploitation, surtout si on en retranche les nombreuses propositions d’améliorations (NdT : RFE) que nous enregistrons dans ce projet. Nous sommes plutôt bons pour maintenir systemd hors de la liste des bugs bloquant la distribution. Notre cycle de développement est plutôt rapide avec principalement des modifications incrémentales pour conserver un haut niveau de qualité et de stabilité.

systemd n’est pas déboguable

Faux. Certains sous-entendent que le shell était un bon débogueur. Hé bien pas vraiment. Dans systemd nous vous fournissons de véritables capacités de débogage. Par exemple, le débogage interactif, une traçabilité détaillée, la possibilité de masquer n’importe quel composant pendant le démarrage et plus encore. Nous fournissons aussi la documentation associée.

Il est sans aucun doute parfaitement débogable, nous en avons nous-mêmes besoin pour notre propre développement. Cependant nous reconnaissons une chose : il utilise des outils de débogage différents, dont nous pensons qu'ils sont plus appropriés à l’objectif.

systemd fait des changements pour le plaisir de changer

Largement mensonger. Nous avons à peu près uniquement des raisons techniques aux différents changements apportés, et nous les expliquons dans les multiples documentations, pages de wiki, articles de blogues et annonces dans les listes de diffusion. Nous faisons un réel effort pour éviter les changements incompatibles, et si nous y sommes contraints, nous essayons d’en documenter en détail la cause et la modalité. Et s’il vous reste des questions, n’hésitez pas à nous les poser !

systemd est un projet uniquement dirigé par Red Hat, une propriété privée de quelques développeurs je-sais-tout, qui l’utilisent pour servir leur vision du monde

C’est faux. Actuellement (NdT : 2013-01-16), il y a 16 développeurs avec le droit de commit sur le dépôt git. Dans ces 16 développeurs, seulement 6 sont employés par Red Hat (NdT : le compte a changé depuis). Les 10 autres sont des gens d’ArchLinux, de Debian, de Mageia, d’Intel, de Pantheon et même de Canonical, ainsi qu’un certain nombre de gens de la communauté. Et ils font souvent de grosses modifications et des changements majeurs. Ensuite, il y a aussi les 374 particuliers avec des patchs dans notre dépôt. Ils viennent aussi d’horizons et d’entreprises variés et plusieurs ont bien plus qu’un seul patch dans le dépôt. Les discussions sur le futur de systemd sont faites de façon ouverte sur notre canal IRC (#systemd sur freenode, vous êtes les bienvenus), sur notre liste de discussion et lors de nos hackfests publiques (comme la prochaine qui aura lieu à Brno, où vous êtes cordialement invité). Nous assistons régulièrement à diverses conférences pour avoir des retours, pour expliquer ce que nous faisons et pour quelle raison, à un degré que peu de projets font. Nous gardons à jour les blogs, nous engageons la discussion sur les réseaux sociaux (nous avons du contenu assez intéressant sur Google+, et notre communauté Google+ est relativement vivante aussi), et nous tentons ardemment d’expliquer pourquoi et comment on fait les choses et on écoute les retours, afin de trouver où sont les soucis (par exemple, avec ces retours, nous avons écrit cette liste de mythes courants sur systemd…).

La plupart des contributeurs à systemd partagent probablement une idée grossière de ce à quoi un bon système d’exploitation devrait ressembler, ainsi que le désir de la voir se concrétiser. Cependant, par la nature Open Source même du projet et son implantation dans la communauté, systemd est simplement ce que les gens veulent qu’il soit et si ça n’est pas ce qu’ils veulent, ils peuvent influencer la direction du projet avec des patchs et du code, et si ça n’est pas possible, il y a alors de nombreuses autres options à épuiser. systemd n’est jamais fermé.

Un but de systemd est d’unifier un peu le paysage dispersé de Linux. Nous essayons de nous débarrasser de beaucoup des différences inutiles entre distributions dans différents domaines du cœur de l’OS. Dans ce cadre, nous adoptons parfois une méthode spécifique à une distribution et l’utilisons par défaut pour systemd dans le but de pousser gentiment tout le monde vers le même ensemble de configurations de base. Ce n’est cependant pas une obligation, les distributions peuvent continuer de le faire à leur manière. Cependant, si elles finissent par adopter le standard, leur travail devient plus simple et elles peuvent gagner une fonctionnalité ou deux. Actuellement, la plupart des standards que nous avons adoptés venaient de Debian plutôt que de Fedora/RHEL. Par exemple, les systèmes qui utilisent systemd stockent généralement leur nom d’hôte dans /etc/hostname, ce qui était auparavant spécifique à Debian et maintenant utilisé sur plusieurs distributions.

Une chose que je vous accorde cependant est que nous pouvons certaines fois avoir l’air de monsieur-je-sais-tout. Nous essayons d’être préparés à chaque fois que nous ouvrons notre bouche, dans le but de soutenir nos affirmations. Cela peut nous faire passer pour des monsieur-je-sais-tout.

De façon générale, effectivement, quelques-uns des plus influents contributeurs de systemd travaillent pour Red Hat. Cependant ils sont une minorité et systemd est une communauté saine et ouverte avec différents intérêts, différentes expériences, simplement unifiée par quelques idées grossières de la direction à prendre, une communauté où le code et sa conception comptent, mais certainement pas l’affiliation à une entreprise.

systemd ne gère pas l’utilisation d’un /usr séparé du répertoire racine

Absurde. Depuis ses débuts systemd gère l’option --with-rootprefix= pour son script configure, ce qui vous permet de dire à systemd de bien séparer les choses nécessaires au début du démarrage de celles nécessaires plus tard. Toute cette logique est complètement présente et nous la gardons à jour dans le système de compilation de systemd.

Bien sûr, nous ne pensons toujours pas qu’amorcer sans /usr disponible est une bonne idée, mais nous le prenons parfaitement en charge dans notre système de compilation. Cela ne corrigera pas les problèmes inhérents du procédé que vous rencontrerez partout, mais vous ne pouvez pas accuser de cela systemd, car dans systemd nous le gérons très bien.

systemd ne permet pas de remplacer ses composants

Faux, vous pouvez désactiver et remplacer à peu près n’importe quel bout de systemd, à de très rares exceptions près. Et ces exceptions (comme journald) en général vous permettent d’utiliser une alternative côte à côte tout en coopérant avec elle.

L’utilisation de D-Bus dans systemd au lieu de sockets le rend opaque

Cette affirmation est déjà contradictoire en elle-même : D-Bus utilise les sockets comme transport. Donc, chaque fois que D-Bus est utilisé pour envoyer quelque chose, une socket est utilisée. D-Bus est pour majeure partie une sérialisation standardisée de message à envoyer à travers ces sockets. Cela le rend plus transparent, car ce format de sérialisation est bien documenté, compris, et il y a de nombreux outils de traçage et des liaisons de langage (language bindings). C’est complètement à l’opposé des habituels protocoles maison que les divers démons Unix classiques utilisent pour communiquer localement.

Hum, ai-je écrit que je voulais briser juste « quelques » mythes ? Peut-être qu’il y en avait plus que quelques-uns… Quoi qu’il en soit, j’espère que j’ai réussi à éliminer certaines idées fausses. Merci de votre temps.

Télécharger ce contenu au format Epub

Lire les commentaires

eZ Server Monitor : un dashboard simple et léger en deux versions

Vendredi 13 Juin

eZ Server Monitor (eSM) permet d’afficher plusieurs informations de votre machine Unix afin de la monitorer. Il se décline en deux versions : Web (eSM`Web) et Bash (eSM`sh).

NdM : nous n'avons pas trouvé de licence.

eSM`Web

Dans sa version Web, eSM est un script PHP qui regroupe sur une seule page diverses informations séparées en blocs :

  • system : nom de la machine, OS, version du kernel, uptime, date du dernier démarrage, nombre d’utilisateur(s) connecté(s), date de la machine ;
  • load average : graphiques indiquant la charge CPU avec le pourcentage (1 minute, 5 minutes et 15 minutes) ;
  • network usage : affichage de l’adresse IP de chaque interface réseau avec les données transmises et reçues ;
  • CPU : modèle, fréquence, nombre de coeurs, cache L2, bogomips ;
  • disk usage : tableau représentant chaque point de montage avec l’espace disponible, utilisé et total ;
  • memory : tableau contenant la quantité disponible, utilisée et totale de la mémoire vive ;
  • swap : tableau contenant la quantité disponible, utilisée et totale du Swap ;
  • last login : affichage des 5 dernières connexions utilisateur ;
  • ping : effectue un ping sur les sites définis dans le fichier de configuration ;
  • services : affiche l’état (disponible ou non) des services définis dans le fichier de configuration.

Chaque bloc peut être actualisé manuellement.

Vous pouvez télécharger la dernière version en cliquant ici. Les pré-requis sont simples : une machine fonctionnant sur un environnement Unix, un serveur Web (Apache, Nginx…) et PHP.

eSM`sh

Quant à la version Bash (eSM`sh), elle vous permet également de retrouver ces informations sur votre terminal Unix.

Chaque bloc peut être affiché de manière indépendante grâce aux différentes options proposées :

  • -h, -u, --help or --usage : affiche l’aide ;
  • -v or --version : affiche la version du script ;
  • -C or --clear : efface le terminal (doit être inséré avant tout autre argument) ;
  • -a or --all : affiche tous les blocs ;
  • -s or --system : informations du système (OS et distribution, kernel, nom de la machine, uptime, nombre d’utilisateurs connectés, date du dernier démarrage, date de la machine) ;
  • -e or --services : vérifie la disponibilité d’un service (peut être configuré) ;
  • -n or --network : informations réseau (IP LAN ; IP WAN) ;
  • -p or --ping : ping sur quelques sites (peut être configuré) ;
  • -c or --cpu : informations du CPU (modèle, fréquence, cache L2, bogomips) ;
  • -m or --memory : informations mémoire vive (disponible et totale) ;
  • -l or --load : charge du CPU et nombre de processus ;
  • -t or --temperatures : affiche la température du CPU, système et des disques durs (facultatif et nécessite hddtemp et/ou lm-sensors d’installés ; peut être configuré) ;
  • -d or --disk : espace disque (top 5).

Ainsi, pour afficher l’ensemble des blocs, il suffit de lancer la commande suivante :

./eZServerMonitor.sh -Ca

La documentation détaille l’ensemble des possibilités du script.

Télécharger ce contenu au format Epub

Lire les commentaires

Makilab : Création d’un Fab Lab en Belgique francophone (Louvain-La-Neuve)

Vendredi 13 Juin

Un nouveau laboratoire de création numérique a vu le jour à Louvain-La-Neuve (Belgique, Brabant Wallon, à 20 min de Bruxelles).

Son nom : Makilab !

Pour rappel, les Fab Labs (FABrication LABoratory) sont des lieux dédiés à la fabrication numérique où tout le monde peut venir s’essayer à prototyper des projets, créer ou simplement personnaliser un objet. Et bien souvent, l'approche libre ou open hardware/source adoptée par les projets existants ou en devenir rendent ces lieux particulièrement intéressants.

L’ASBL (l'équivalent d'une association de Loi 1901 en France) en est à ses débuts, mais rencontre déjà un certain écho dans le monde académique, étudiant (Louvain-La-Neuve est une ville universitaire), citoyen et entrepreneurial. Le fait que l’initiative soit une première dans la province n’y est certainement pas étranger. Dans cette dynamique, nous avons lancé une campagne de financement participatif.

Au niveau technique, nous sommes actuellement équipés d'une découpe vinyle et d'une imprimante 3D, bientôt rejoints par une découpe laser et un scanner 3D. Bref, que vous soyez passionné, curieux ou simple bricoleur, n’hésitez pas à nous visiter.

Télécharger ce contenu au format Epub

Lire les commentaires

Pages