Linux France

S'abonner à flux Linux France
Mis à jour : il y a 12 min 13 sec

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

Mardi 22 Juillet

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

[Le Courrier picard] Beauvais, capitale mondiale du logiciel libre, l’été prochain

Par Mélanie Carnot, le vendredi 18 juillet 2014. Extrait:

Les geeks de la planète ont rendez-vous à Beauvais l’année prochaine. L’association Oisux et la CCI de l’Oise organiseront les Rencontres mondiales du logiciel libre, en juillet.

Lien vers l'article original: http://www.courrier-picard.fr/region/beauvais-capitale-mondiale-du-logiciel-libre-l-ete-prochain-ia186b0n407085

[Developpez.com] Le choix des logiciels Libres & Open source entraine t-il des gains importants

Par la rédaction, le vendredi 18 juillet 2014. Extrait:

Sur Internet, vous trouverez beaucoup d'études qui démontrent que les logiciels Libres & Open source entrainent des gains financiers importants, qui peuvent aller jusqu'à un facteur de 3. Des institutions ont déjà franchi le pas: la Gendarmerie, la ville de Munich, etc.

Lien vers l'article original: http://open-source.developpez.com/actu/73401/Le-choix-des-logiciels-Libres-Open-source-entraine-t-il-des-gains-importants-Quand-est-il-reellement

[ZDNet] Code à l’ecole: les associations dans le flou

Par Louis Adam, le jeudi 17 juillet 2014. Extrait:

Benoit Hamon annonçait dans le JDD sa volonté d’intégrer l’apprentissage du code à l’école primaire dès septembre. Cette première étape, prévue pour la rentrée 2014, devrait être dévolues aux associations qui proposeront leurs activités sur les temps périscolaires. Mais ces dernières cherchent encore l'appel à projets évoqué…

Lien vers l'article original: http://www.zdnet.fr/actualites/code-a-l-ecole-les-associations-dans-le-flou-39803961.htm

Et aussi:

[Le Monde Informatique] Systematic: bilan et perspectives du soutien au logiciel libre

Par Dominique Filippone, le jeudi 17 juillet 2014. Extrait:

Après 7 ans d'existence, le Groupe Thématique Logiciel Libre (GTLL) du pôle Systematic Paris Région a permis à 80 projets d'être labellisés et à près de la moitié d'entre eux d'obtenir des financements pour assurer leur développement. Big data, qualité logicielle et technologies de l'après PC constituent les principales priorités de soutien aux projets R&D en logiciels libres de GTLL pour les années à venir.

Lien vers l'article original: http://www.lemondeinformatique.fr/actualites/lire-systematic-bilan-et-perspectives-du-soutien-au-logiciel-libre-58108.html

[Numerama] L'April cherche des dons pour distribuer son Guide Libre Association

Par Guillaume Champeau, le mardi 15 juillet 2014. Extrait:

Alors que le gouvernement a fait de l'engagement associatif la grande cause nationale 2014, l'Association promouvoir et défendre le logiciel libre (April) aimerait faire distribuer auprès du maximum d'entre-elles le guide à destination des associations qu'elle a mis au point pour leur apprendre à connaître les logiciels libres qui peuvent leur être utile.

Lien vers l'article original: http://www.numerama.com/magazine/30004-l-april-cherche-des-dons-pour-distribuer-son-guide-libre-association.html

Et aussi:

Voir aussi:

[Next INpact] Un rapport parlementaire encourage au développement des logiciels libres

Par Xavier Berne, le mardi 15 juillet 2014. Extrait:

Un récent rapport sénatorial vient d’apporter un soutien de poids au développement des logiciels libres en France. Il y est en effet préconisé d’encourager le déploiement de ces programmes dont l'étude, la reproduction et la modification est autorisée, et ce à la fois «par leur intégration dans les marchés publics et par l’imposition de standards ouverts». Ce coup d’accélérateur pourrait avoir lieu à condition toutefois «de développer les compétences pour l’utilisation de ces logiciels et standards».

Lien vers l'article original: http://www.nextinpact.com/news/88675-un-rapport-parlementaire-encourage-au-developpement-logiciels-libres.htm

[Le Monde.fr] TiSA: un accord géant de libre-échange en discrètes négociations

Par Maxime Vaudano, le mercredi 9 juillet 2014. Extrait:

Réunis à Paris mardi 8 juillet pour préparer le prochain volet de la régulation financière européenne, les représentants du monde financier ne semblent pas être particulièrement au fait des négociations secrètes qui pourraient demain bloquer toute volonté régulatoire de 50 des plus grandes économies mondiales. Une perspective nommée TiSA, pour Trade in Services Agreement, ou Accord sur le commerce des services en français.

Lien vers l'article original: http://www.lemonde.fr/les-decodeurs/article/2014/07/09/tisa-quand-le-liberalisme-revient-par-la-porte-de-derriere_4452691_4355770.html

Et aussi:

Télécharger ce contenu au format Epub

Lire les commentaires

CHOUETTE, logiciel libre pour faciliter les échanges de données transports

Lundi 21 Juillet

CHOUETTE est le nom d’un logiciel libre dont le but est de faciliter les échanges de données transports entre différents systèmes d’information.
Ce logiciel est développé à l'initiative de l'Agence Française pour l’Information Multimodale et la Billettique, rattachée au Ministère en charge des Transports.

Contexte : un langage commun pour échanger les données transports

Les systèmes informatiques figurent parmi les outils permettant la planification, l’organisation, la régulation du transport collectif et l’information des usagers. Pour fonctionner et communiquer entre eux, ils utilisent un langage informatique.

La normalisation et les standards précisent des règles d’écriture des données composant ce langage afin de faciliter les échanges d’information entre les différents systèmes informatiques.

Le logiciel Chouette, permet de contrôler la bonne organisation des données selon les règles d’écriture définies par la normalisation et/ou par les standards.

Fonctionnalités de Chouette

Le logiciel Chouette permet de :

  • contrôler la conformité des données d’offre de transport avec la norme dite Neptune (Référence : NF P 99506)
  • importer / exporter / convertir les données d’offre de transport
  • gérer et mettre à jour les données d'offre de transport
  • visualiser les données transport sur fond cartographique (exemple : positionnement d’un arrêt de bus)
Un logiciel destiné à plusieurs types d’acteurs
  • les collectivités locales, Autorités Organisatrices de Transport (AOT),
  • les exploitants des réseaux de transport collectif, et leurs prestataires (bureaux d'étude ou société de services et éditeurs de logiciels),
  • les opérateurs/développeurs de services d'information,
  • les services de l'Etat,
  • etc.
Des apports concrets Pour les collectivités

Le logiciel Chouette contribue à :

  • Améliorer la qualité des services d’information multimodale aux usagers
  • Favoriser l’innovation de services à partir des données du transport (par exemple, permettre à des acteurs du tourisme de disposer de données transport de qualité pour réaliser une application mobile)
  • Améliorer la connaissance de la desserte des transports collectifs sur les territoires
Pour les développeurs de services d’information

Le logiciel Chouette contribue à :

  • Faciliter la construction de services basés sur des données multimodales
  • Étendre géographiquement les services proposés
  • Améliorer la qualité des données de mobilité de leurs services
Utiliser le logiciel Chouette

L'ensemble des informations fonctionnelles et techniques (documentations, code, données…) sur le logiciel Chouette est accessible depuis le site

Usages :

Le logiciel Chouette sous licence CeCILL-B est utilisable gratuitement de plusieurs façons :

  • directement en ligne sur le web en créant un compte utilisateur
  • sur votre poste : en tant que machine virtuelle à installer
  • sur votre serveur (Linux ou Windows) : en tant qu'application web à installer et pour les développeurs :
  • en ligne de commande (shell)
  • en Ruby
  • en tant que bibliothèque Java réutilisable

Les sources sont hébergés sur Github, pour la partie Ruby on Rails et la partie Java.

Extension IRYS (données en temps réel)

D'autres logiciels libres peuvent s'intégrer à Chouette, parmi lesquels IRYS.

IRYS est une extension, développée dans le but de faciliter les échanges de données « temps réel ». En s’adossant à la norme SIRI, IRYS permet de visualiser sur une carte des données transports en temps réel. Une version de démonstration est disponible en ligne et les codes sources sont téléchargeables à partir du site.

Pour en savoir plus…

L'ensemble des informations fonctionnelles et techniques (documentations, code, données…) sur chouette est accessible depuis le site.
Les informations relatives aux normes pour les données du transport collectif sont disponibles à partir d'un site dédié

N'hésitez pas à poser vos questions via le forum ou la rubrique « contact » du site

Télécharger ce contenu au format Epub

Lire les commentaires

ApéroMaison le 31 juillet à Nantes

Lundi 21 Juillet

Après avoir participé au Café vie privée1 du 5 juillet dernier, FAImaison, fournisseur d'accès à internet Nantais, vous propose un ApéroMaison le 31 juillet à 19h au bar l'Absence (rue La Noué Bras de Fer à Nantes), pour échanger de façon informelle et conviviale à propos d'Internet et ses usages, pour découvrir FAImaison en dehors des réunions hebdomadaires, etc.

L'évènement est ouvert à tous, entrée libre et gratuite.

  1. NdM : Nous somme désolé d'utiliser un raccourcisseur d'URL mais un problème avec les URL contenant des accents ne permet pas de mettre un lien direct 

Télécharger ce contenu au format Epub

Lire les commentaires

Campagne de financement participatif pour ProtonMail

Samedi 19 Juillet

ProtonMail est un service de messagerie web sécurisé créé en 2013 par Jason Stockman, Andy Yen et Wei Sun au CERN, situé à côté de Genève en Suisse. À l'opposé de nombreuses messageries web existantes (gmail.com, outlook.com…), ProtonMail chiffre les courriels avant qu'il ne soient envoyés au serveur. ProtonMail est actuellement en version bêta.

Depuis le 17 juin, une campagne de financement participative a été lancée par l'équipe de développeur dans le but d'atteindre 100 000$. Deux semaines plus tard, le projet avait déjà reçu 200 000$. La prochaine étape est d'atteindre 500 000$ afin que des applications pour iOS et Android soient développées. La campagne se termine le 31 juillet. ProtonMail accepte les paiements par carte bleue, paypal (voir plus bas) et bitcoin.

Détail de la sécurité

Les développeurs mettent en avant plusieurs points pour justifier de la sécurité de ce nouveau projet.

Tout d'abord, les serveurs de ProtonMail sont localisés en Suisse et dépendent donc de la législation suisse qui est l'une des plus protectrices au monde concernant les données personnelles (d'après les développeurs). Seul le tribunal cantonal de Genève ou le tribunal fédéral peuvent obliger ProtonMail à fournir les données extrêmement limitées qu'ils ont de leurs utilisateurs.

De plus, les données ne sont pas accessibles. Le système repose sur deux mots de passe. Le premier permet de se connecter à la messagerie. Celui-ci est connu par les administrateurs. Une fois connecté, les données sont envoyées chiffrées à l'utilisateur. Il utilise alors le deuxième mot de passe, connu de lui seul, pour déchiffrer les données au sein du navigateur. Ce deuxième mot de passe n'est pas envoyé au serveur, ni les données déchiffrées. Les données sont donc chiffrées de bout en bout et les serveurs de ProtonMail ne contiennent que des données chiffrées.

ProtonMail n'enregistre aucun log. Il ne sauvegarde aucune métadonnées, que ce soit les adresses IP à partir desquelles l'utilisateur se connecte, ou bien le temps durant lequel un compte est consulté. À noter que Google Analytics est utilisé mais uniquement sur la page d'accueil du site. Il n'est pas possible de faire correspondre les données avec un compte utilisateur spécifique.

Il est possible d'échanger des mails avec d'autres services de messagerie. Dans ce cas, votre correspondant recevra un lien vers le message chiffré qu'il pourra déchiffrer grâce à la phrase de passe que vous lui aurez auparavant communiqué par un moyen de communication sécurisé ;)

Enfin, il existe une option pour activer l'autodestruction des courriels au bout d'un certain délai.

Techniquement, sur quoi ça repose ?

Techniquement, le chiffrement des données est réalisé avec AES et RSA implémenté dans OpenPGP. Par ailleurs, des scripts vérifient régulièrement l'intégrité du code en exécution de sorte à détecter toute modification de celui-ci. Enfin, bien que les données transitant depuis le serveur vers votre navigateur web soient déjà chiffrées, la communication s'effectue via SSL pour ajouter une protection supplémentaire (attaque de l'homme du milieu).
Leur certificat SSL est fournit par SwissSign. Les développeurs publieront prochainement le hash SHA3 de leur clé publique SSL.

Enfin, l'équipe a choisi avec attention l'emplacement physique des serveurs. Ils sont situés dans des centres de traitement de données (datacenters) sécurisés et gardés aux côtés des serveurs de banques suisses. Du côté humain, aucune personne ne possède l'ensemble des mots de passe d'accès ; ils sont conservés par différents personnes de nationalités différentes.

Équivalent

À noter que tutanota, basé en Allemagne, propose le même genre de fonctionnalités.

Paypal pense que c'est illégal

En plein milieu de la campagne de financement, le 30 juin dernier, paypal décide unilatéralement de bloquer les dons pour ProtonMail. Paypal se demandait si ProtonMail était légal et s'ils avaient l'autorisation du gouvernement (lequel ?) pour chiffrer les courriels. Le blocage a été levé le lendemain dans l'après-midi.

Télécharger ce contenu au format Epub

Lire les commentaires

Une nouvelle version de l'Agenda du Libre vient d'être déployée!

Samedi 19 Juillet

En 2013, l'April a repris l'hébergement de l'Agenda du Libre. Afin de faire évoluer le projet, une nouvelle version a été écrite en Ruby on Rails. Celle-ci utilise actuellement rigoureusement la base de données et l'ergonomie de l'ancienne version.

Vous pouvez retrouver le code source dans son intégralité sur son dépôt Gitorious.

La période étant plutôt creuse et le code prêt, nous avons modifié la configuration Apache httpd pour que le site www.agendadulibre.org pointe vers la nouvelle version.

Cette nouvelle version comporte probablement encore beaucoup de bugs et oublis, mais apporte aussi :

  • une meilleure accessibilité ;
  • la validation W3C ;
  • des formulaires html5 ;
  • l'internationalisation ;
  • un outil d'administration ;
  • des dépendances vers des bibliothèques tierces ;
  • un système de migration de la base de données ;
  • des textes modifiables depuis la base de données ;
  • et enfin, des tests unitaires, fonctionnels et de sécurité.

Des tests ont été réalisés ; de plus les flux type RSS et iCal répondent avec les mêmes URL qu'avant, donc idéalement la plupart des sites référençant l'Agenda du Libre français ne devraient subir aucun désagrément.

Le script de soumission automatisée d'événements, en python, a été mis à jour, mais il faudra tout de même que les utilisateurs le téléchargent.

En fonction des remontées reçues, nous verrons pour les versions suisses et belges, qui utiliseront le même code mais une base de données séparée.

Nous sommes joignables par IRC sur #agendadulibre (sur freenode) ou par courriel à devel chez agendadulibre point org si vous avez le moindre souci ou si vous souhaitez des évolutions !

Télécharger ce contenu au format Epub

Lire les commentaires

L'événement libre à Toulouse : Le Capitole du Libre

Samedi 19 Juillet

L’édition 2014 du Capitole du Libre se tiendra cette année les samedi 15 et dimanche 16 novembre à l’ENSEEIHT de Toulouse. Le Capitole du Libre est un événement consacré aux Logiciels Libres, organisé par l’association Toulibre, orienté à la fois vers le grand public et le public spécialisé.

Il sera précédé d'une journée à destination des professionnels le vendredi 14 novembre, organisée par l'association Solibre.

Le Capitole du Libre est l'événement du libre toulousain. Des conférences et des ateliers auront lieu tout au long du week-end. Des stands et des animations seront proposés au public pour leur faire découvrir le monde du Libre.

Au programme du week-end du Capitole du Libre

Les thématiques suivantes seront abordées :

  • Grand Public et Enjeux du Libre (découverte, éducation, juridique, biens communs…) ;
  • Technique (système, développement, réseau…) ;
  • Multimédia & Bureautique (graphisme, vidéo, son, ainsi que les logiciels de bureau) ;
  • Internet Libre (outils libre pour l'auto-hébergement de site, de mail…) ;
  • Open Hardware et Embarqué (arduino, raspberry pi…) ;
  • DevOps (déploiement et intégration automatisée).

Deux événements de communautés du libre seront programmés :

  • Akademy-FR ;
  • Hackfest Libre Office.
Appel à Conférences et ateliers

L'appel à conférences et à ateliers est lancé ! Vous pouvez dès à présent faire vos propositions sur la page dédiée du Capitole du Libre. Le dossier de sponsoring est consultable en ligne.

Liens supplémentaires :

Restez connectés :

Télécharger ce contenu au format Epub

Lire les commentaires

Haka pour le traitement de flux réseau

Vendredi 18 Juillet

Haka est un framework/langage basé sur Lua et destiné à appliquer des règles sur du trafic réseau en temps réel. Il permet aussi bien de faire un pare-feu classique, filtrant « bêtement » sur les ports, qu'un pare-feu applicatif. Il utilise la notion de dissecteur qui, une fois la grammaire du langage décrite, permet de définir différents événements qui pourront être utilisés dans les règles définies.

Il faut noter que ce n'est que le tout début du langage, il manque encore certaines fonctionnalités critiques.

Haka est sous licence MPL 2.

Disclaimer : j'ai fait le workshop Haka aux RMLL et il se basait sur la version 0.2 en développement de Haka, c'est donc celle-ci qui est décrite.

À quoi ça sert ?

Vous pouvez bien sûr l'utiliser en tant que pare-feu classique, mais cela a peu d'intérêt. Il vaut mieux l'utiliser en tant que pare-feu applicatif qui va donc analyser le protocole de couche 7 ; cela peut aller de l'antispam à l'analyse de flux DNS pour, par exemple, lever une alerte en cas de détection d'attaque par cache poisoning. Mais il peut aussi faire de la modification de paquet, par exemple, pour éviter une attaque comme Heartbleed en corrigeant l'entête du message TLS afin qu'il ait bien la taille du message. Stéphane Bortzmeyer proposait même de l'utiliser pour mettre en place un proxy DANE.

Exemples

Un Hello World qui enverra un message de catégorie info dans les logs à chaque paquet IPv4 reçu :

local ipv4 = require('protocol/ipv4') haka.rule{ hook = ipv4.events.receive_packet, eval = function (self, pkt) haka.log('info', 'message receive from %s', pkt.src) end }

Un exemple un peu plus complexe qui remplace toutes les images qui transitent en HTTP par le logo de LinuxFr.org. On notera que c'est loin d'être parfait, il ne gère pas les images dont les tags sont sur plus d'une ligne et ne vérifie pas qu'il s'agit d'HTML qui transite. Il fonctionne en interceptant la requête au serveur pour éviter les caches et éviter un transfert gzippé qui ne peut (pour l'instant) être modifié avec Haka. Ensuite, il applique une simple expression régulière dans le contenu de la réponse du serveur.

local http = require('protocol/http') local rem = require('regexp/pcre') http.install_tcp_rule(80) haka.rule { hook = http.events.request, eval = function(conn, request) request.headers['Accept-Encoding'] = nil request.headers['Accept'] = '*/*' request.headers['If-Modified-Since'] = nil request.headers['If-None-Match'] = nil haka.log('info', 'request') end } -- La règle suivante permet d'éviter des problèmes de Content-Length qui ne serait plus cohérent haka.rule { hook = http.events.response, eval = function(conn, response) conn:enable_data_modification() end } local regexp = rem.re:compile('<img .*/>', rem.re.CASE_INSENSITIVE) haka.rule { hook = http.events.response_data, eval = function(flow, iter) local result = regexp:match(iter, true) haka.log('info', 'plop %s', result) if result then haka.log('info', 'plop') result:replace(haka.vbuffer_from('<img src="http://linuxfr.org/images/logos/logo-linuxfr-cadre-ombre.png"></img>')) end end } Débuggage

Premièrement, il est tout à fait possible d'utiliser des fichiers pcap au lieu d'un flux réel, très pratique pour faire des tests. Ensuite, l'outil de debug permet d'effectuer les opérations de manière interactive, ce qui permet de voir pas à pas comment se comporte le flux.

Test

Pour tester par vous-même, le projet a mis a disposition une image iso qui a été utilisée pour le workshop aux RMLL, il s'agit d'une Debian live qui s'ouvre sur un bureau XFCE. Sur le bureau, deux liens : la documentation et les instructions du workshop. Avec cela, pas besoin de passer du temps à l'installer sur votre système pour tester.

Développements futurs
  • il manque un dissecteur IPv6 ;
  • après la sortie de la version 0.2 qui devrait apporter suffisamment de fonctionnalités pour que l'outil soit utilisable, le travail va se tourner vers les performances.
Télécharger ce contenu au format Epub

Lire les commentaires

Ned et les maki 0.3

Jeudi 17 Juillet

Voici une nouvelle qui devrait faire plaisir à plus d’un : Ned et les maki continue son petit bonhomme de chemin et passe en version 0.3.

Ned et les maki, est un jeu vidéo créé par les Geeky Goblin Productions en collaboration avec devnewton et Natir. Il propose au joueur de prendre le contrôle de Ned, le koala masqué à chaussettes rayées, afin de ranger des maki dans des assiettes sur le modèle d'un sokoban amélioré. Il propose des graphismes très sympathiques, une histoire, un univers original et des mécaniques de jeu enrichies.

Les Nouveautés Juste un doigt…

Le jeu est désormais jouable entièrement à la souris, au touchpad ou avec un écran tactile.

Pour déplacer Ned, il suffit de cliquer ou tapoter sur l'écran et des boutons permettent d'annuler le dernier coup, de réinitialiser le niveau en cours ou de retourner au menu principal.

Game on throne

Nous sommes heureux d’annoncer qu’un premier portage de Ned et les maki a été effectué sous Android™. Vous pourrez ainsi vous adonner au rangement de maki dans les transports en commun, aux toilettes, au bureau ou dans la cour de récréation, et ainsi remplacer vos amis par votre koala masqué à chaussettes rayées préféré !

RMLL

Au début du mois, les GGP ont présenté cette version de Ned et les maki aux visiteurs lors du week-end grand public des Rencontres mondiales du logiciel libre à Montpellier. Un certain nombre de bugs ont été repérés et les joueurs ont proposé des idées fort intéressantes. Vous trouverez sur notre blog un retour d'impressions.

À suivre

Pour la version 0.4, nous prévoyons de corriger encore plus de bugs, et d’implémenter d'autres éléments de gameplay — de nouveaux objets, de nouveaux personnages, etc. La musique devrait également commencer à apparaître dans le jeu.

Télécharger ce contenu au format Epub

Lire les commentaires

Spacewalk 2.2

Jeudi 17 Juillet

Spacewalk est un logiciel de gestion des systèmes et de leurs mises à jour pour les distributions basées sur les paquets RPM. Ce nom ne vous dit peut-être rien, mais ce projet est en fait celui qui sert de base à Red Hat Network Satellite (RHN), ainsi qu'à SUSE Manager.

Le 16 juillet dernier est sortie la version 2.2 de ce logiciel, dont les changements principaux sont détaillés en deuxième partie de dépêche.

Améliorations

Les notes de versions démarrent en annonçant la prise en charge des clients RHEL 7 et CentOS 7. Attention cependant, le site de Spacewalk chez Red Hat indique bien que RHEL n'est pas pris en charge par Spacewalk en tant que client, la prise en charge est donc technique et valide que les outils clients fonctionnent. N'espérez pas connecter un Spacewalk à RHN !

On notera que le fonctionnement d'un serveur Spacewalk sur une base système RHEL 7 (ou CentOS 7) n'est pas opérationnel : cela est expliqué par l'absence, dans EPEL 7, de paquets indispensables (actuellement en stade bêta).

D'autres améliorations concernent l'API : en plus d'un certain nombre de nouvelles méthodes (42 listées dans l'annonce), il est possible de s'y connecter en lecture seule.

Spacewalk est capable d'exécuter des actions sur les machines clientes. L'amélioration consiste à pouvoir enchaîner plusieurs actions, par exemple pour des procédures de mise à jour complexes.

L'une des particularités de Spacewalk est qu'il est basé sur Cobbler. Ce dernier est capable d'agir, en association avec le matériel adéquat, sur l'alimentation des systèmes clients. Spacewalk 2.2 exploite maintenant cette fonctionnalité de Cobbler, permettant par exemple d'allumer depuis l'interface web un serveur éteint. Attention cependant, cette fonctionnalité n'est pas accessible sur les clients RHEL 5 ou CentOS 5, car le paquet fence-agents n'est pas disponible pour ces plateformes.

Spacewalk dispose d'un composant nommé Spacewalk Proxy. Lorsqu'il est mis en place, les clients effectuent leurs requêtes vers le proxy, qui les transmet au serveur Spacewalk. C'est par exemple utile dans le cas de restrictions réseau. Une nouvelle fonctionnalité fait son apparition dans Spacewalk Proxy, le Proxy Pre-Cache : cela permet de limiter le trafic réseau entre un Spacewalk et son proxy, en mettant en cache les requêtes vers des paquets RPM, qu'elles viennent de Yum ou d'Anaconda. Il est de plus possible de peupler manuellement le cache.

Côté sécurité, l'annonce met l'accent sur la prise en charge de FIPS 140-2. Il s'agit de pouvoir utiliser Spacewalk sur un serveur qui implémente ce standard et d'installer ou d'enregistrer des clients qui eux aussi l'implémentent.

Enfin, la gestion d'identités n'est pas en reste avec des améliorations de l'intégration d'une authentification externe (apparue en 2.1).

Suppressions futures

Si du côté des systèmes compatibles, rien n'est enlevé pour Spacewalk 2.2, ça bougera dans les prochaines versions, puisque la prise en charge de RHEL 5 et CentOS 5 sera supprimée, tout comme celle des systèmes Solaris.

À noter aussi, Spacewalk dispose de fonctionnalités de surveillance : si vous ne les utilisez pas, ne commencez pas, le composant qui les gère va également disparaître !

Télécharger ce contenu au format Epub

Lire les commentaires

Simplification des démarches administratives

Jeudi 17 Juillet

Jusqu'au 15 septembre 2014, on peut proposer des idées pour simplifier les démarches administratives. C'est l'occasion de proposer des idées qui peuvent faire avancer le Libre.

On peut par exemple suggérer de ne plus proposer le téléchargement du lecteur PDF d'Adobe Reader sur les sites Web des administrations mais des lecteurs PDF libres. Si vous avez d'autres idées pour faire progresser le libre, les formats ouverts, l'interopérabilité, l'accessibilité des sites Web, l'Open Data… il suffit de faire une proposition en tant que particulier ou entreprise. Chaque proposition est ensuite acceptée ou rejetée. Si elle est rejetée, vous pouvez quand même faire un commentaire (non soumis à modération).

Si vous avez posté une proposition ou si vous avez des idées, merci de les noter sur le Pad (éventuellement avec le lien vers votre proposition lorsqu'elle a été validée). La FSFE pourra ainsi faire un suivi des propositions.

Télécharger ce contenu au format Epub

Lire les commentaires

Sortie de Variation v1.0

Jeudi 17 Juillet

Variation est un logiciel de gestion de dossiers d'usagers adapté au secteur du social et médico-social. Il s'adresse par exemple aux structures d'hébergement ou d'emploi de personnes handicapées, au suivi à domicile d'adolescents en difficultés, aux maisons de retraite, etc.

Nous sommes heureux d'annoncer la sortie de la version 1.0 de Variation sous licence libre (AGPL).

Nous avons voulu développer une application la plus modulaire possible :

  • du côté métier, en définissant des briques élémentaires - champs de saisie, établissements, groupes, documents, événements, notes - que l'on peut arranger et paramétrer selon les besoins,
  • du côté technique, en se basant sur une API au niveau de la base de données, utilisée pour le développement de l'interface utilisateur web, de l'accès aux données via WebDAV et tout autre développement à venir.

Après quelques installations réalisées avec succès dans divers types d'établissements du social (MECS, SESSAD, suivi RSA, FAE), nous désirons libérer les sources de l'application afin de pouvoir nous concentrer sur le développement de nouvelles fonctionnalités.

D'après cette première expérience, l'installation d'une telle solution nécessite au moins deux compétences : une compétence métier pour paramétrer le logiciel selon les besoins de l'établissement et une seconde compétence technique pour installer la solution sur un serveur Linux et l'intégrer dans le système d'information en place (import des données, développement de tableaux spécifiques en se basant sur WebDAV ou l'API, développement de connecteurs avec d'autres applications du S.I., etc.).

Des instructions d'installation, un tutoriel de démarrage et une documentation de l'API sont disponibles au téléchargement depuis le site officiel. Nous espérons financer les futurs développements en mettant en vente différents manuels : un premier tome couvrant les concepts et l'utilisation du logiciel, un deuxième tome couvrant le paramétrage et l'administration.

Un troisième tome à venir couvrira les détails de l'installation, l'intégration et le développement (et dont la gratuité reste à débattre).

Télécharger ce contenu au format Epub

Lire les commentaires

Un rapport parlementaire recommande l'utilisation du logiciel libre

Mercredi 16 Juillet

Le Sénat vient de publier un rapport d’information rédigé par Mme Catherine Morin-Desailly, intitulé “Nouveau rôle et nouvelle stratégie pour l’Union européenne dans la gouvernance mondiale de l’Internet”. Le logiciel libre y est présenté comme “une alternative intéressante pour l’Europe et la France […] face à la progression des systèmes fermés et des considérations marchandes dans l’univers de l’Internet”.

L'importance de la filière du logiciel libre en France y est notée, de nombreux arguments en faveur de l'utilisation du logiciel libre sont avancés, et plusieurs propositions sont faites pour "encourager les compétences nationales par une politique adaptée" :

  • non brevetabilité des logiciels ;
  • intégrer les logiciels libres dans les marchés publics ;
  • imposer les standards ouverts ;
  • développer les compétences autour des logiciels libres et des standards ouverts, en encourageant notamment l'usage des logiciels libres dans les enseignements informatiques.

Le Conseil National du Logiciel Libre se réjouit de la prise en compte dans le rapport de la filière économique du logiciel libre en France, qu’il représente :

Le Conseil national du logiciel libre (CNLL) a rendu compte du succès croissant des formats libres de logiciels : représentant 6 % de l’ensemble des logiciels et services, soit une valeur de 2,5 milliards d’euros, ils occupent 30000 personnes – dont 3000 chez les « pure players » – réparties dans 300 entreprises, essentiellement des PME et TPE. La filière, qui a crû de 68 % en 2012, devrait avoir progressé de 83 % en 2013. [Note: ces chiffres sont extraits de l'enquête 2013 du CNLL, mais ont été mal interprétés.]

[…]

Depuis 2003, plusieurs clusters et associations d’entreprises du logiciel libre ont été mis en place en vue de fédérer les moyens et les projets développés dans le secteur : Prolibre, Libertis, Alliance libre, GTLL, PLOSS, PLOSS RA et Aquinetic, répartis sur l’ensemble du territoire et regroupés au sein du CNLL. Ce riche écosystème a donné naissance à plusieurs jeunes pousses en pleine ascension, à l’image de la première d’entre elles, l’éditeur de logiciels libres Talend.

Notre pays dispose donc d’importantes ressources et compétences dans le domaine du logiciel libre, qu’il lui faut aujourd’hui pousser davantage pour maintenir et conforter cet atout économique autant que stratégique.

De nombreux arguments en faveur des logiciel libres sont avancés dans le rapport :

  • ils sont “sources d’économies et de compétitivité” ;
  • ils permettent “d’innover à moindre coût” ;
  • ils permettent de “réduire la dépendance, stratégique et économique, de la France vis-à-vis de fournisseurs étrangers” ;
  • ils sont “plus protecteurs en termes de sécurité”.

Formellement, le rapport recommande l’approche suivante pour favoriser le développement du logiciel libre :

Proposition n° 43 : encourager le développement des logiciels libres par leur intégration dans les marchés publics et par l’imposition de standards ouverts, à condition de développer les compétences pour l’utilisation de ces logiciels et standards.

Il vient également appuyer un souci très ancien des écosystèmes du libre et de l’open source, en condamnant la brevetabilité des logiciels :

Proposition n° 42 : veiller à la préservation du principe européen de non-brevetabilité des logiciels.

Le rapport note à juste titre qu’il s’agit d’une promesse de campagne du Président Hollande.

Enfin, dans le domaine de l’éducation, il est noté que :

[…] il paraîtrait de bonne politique d’encourager l’usage des logiciels libres dans les enseignements informatiques. Basé sur l’ouverture et la collaboration, valeurs en phase avec la démarche scientifique, le logiciel libre peut être étudié librement de droits. Et la formation supérieure aux méthodes de création de logiciels libres peut conduire à d’importants débouchés professionnels.

Le CNLL se réjouit particulièrement du ton général de ce rapport, et de ces recommandations concrètes, qui rejoignent et renforcent les “10 propositions pour une politique du logiciel libre” qu’il a publié en 2012, et notamment ses propositions suivantes :

  • proposition 1 : obligation d'utiliser les standards ouverts ;
  • proposition 2 : recommandation d'utiliser le logiciel libre, à coût global, risques et efficacité comparables ;
  • proposition 4 : faire barrage aux brevets logiciels ;
  • proposition 5 : pour des standards ouverts vraiment ouverts ;
  • proposition 6 : agir pour préserver la neutralité du Net ;
  • proposition 9 : recommandations relatives au libre dans l'éducation.

Le rapport complet peut être téléchargé sur le site web du Sénat. Les pages qui concernent le plus spécifiquement le logiciel libre sont les pages 267 à 272.

Télécharger ce contenu au format Epub

Lire les commentaires

Cerberus 1.0.0 disponible.

Mercredi 16 Juillet

Nous sommes heureux d'annoncer la sortie de la version 1.0.0 de Cerberus. Pour mémoire, Cerberus est un outil de test pour les applications web, les applications back office et les tests d'infocentres et outils décisionnels.
Cette version majeure voit le jour suite à l'ajout de trois fonctionnalités :

  • la gestion de campagne de tests, lien essentiel entre les cas de tests et la Release ;
  • l'intégration de nouveaux frameworks de tests permettant des tester fonctionnellement des web services ;
  • l'affichage en temps réel de l'exécution des tests (même lancés sur un serveur distant).

Cerberus entend porter la méthodologie du développement piloté par les tests (Test Driven Development), en mettant à disposition des acteurs du développement (depuis les phases de définition jusqu'à la validation, en passant par la phase de développement elle-même) un socle d'information fonctionnelle et technique commun.

Finie l'utilisation de deux outils distincts pour décrire les tests et automatiser ceux-ci : décrire un cas de tests revient à implémenter celui-ci (de part l'utilisation de bibliothèques de données ou de groupement d'actions). Cette façon de structurer l'information rends les tests bien plus facilement maintenables dans le temps.

Les tests peuvent être lancés par tous via l'application, ou en mode batch pour une campagne de tests par exemple (sur plusieurs queues, plusieurs navigateurs et plusieurs environnements simultanément). Les compte-rendus d'exécution s'accompagnent désormais du code source des pages testées et des logs Selenium (vue serveur et vue navigateur), en plus des screenshots pleine page, ainsi que des logs Cerberus sur chaque action, permettant ainsi l'analyse des résultats par plusieurs personnes, à chacun selon son besoin.

Dans une prochaine version, nous intégrerons notamment une interface à framework de tests d'application mobile (Appuim), poursuivant notre stratégie de centraliser les tests quelques soient les technologies.

Télécharger ce contenu au format Epub

Lire les commentaires

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

Mardi 15 Juillet

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

[Le Point] L'enseignement du langage informatique proposé en primaire dès la rentrée

Par la rédaction, le dimanche 13 juillet 2014. Extrait:

L'enseignement du langage informatique sera proposé en primaire dès la rentrée de manière facultative, annonce dans une interview au Journal du dimanche le ministre de l'Education nationale Benoît Hamon, qui prévoit également de relier au haut débit hertzien 9.000 écoles dès septembre.

Lien vers l'article original: http://www.lepoint.fr/societe/l-enseignement-du-langage-informatique-propose-en-primaire-des-la-rentree-13-07-2014-1845757_23.php

[Slate.fr] Tor, de plus en plus partagé

Par Amaelle Guiton, le jeudi 10 juillet 2014. Extrait:

Boosté par les scandales de surveillance numérique, le réseau d'anonymisation enregistre depuis un an un afflux conséquent d'utilisateurs. Ce changement d'échelle et de périmètre pose à ses développeurs des défis complexes.

Lien vers l'article original: http://www.slate.fr/story/89673/tor

Et aussi:

[CitizenKane] Sécurité informatique: 4 bombes atomiques en 12 mois

Par David Nataf, le jeudi 10 juillet 2014. Extrait:

Nos systèmes de sécurité informatique sont bien plus nombreux et perfectionnés qu’il y a quelques années. Les normes de sécurité et leur intégration dans les entreprises sont de mieux en mieux implémentés. Et pourtant, ces derniers 12 mois ne nous ont pas gâté. Avec peut-être les 4 plus grandes bombes à retardement jamais vues en sécurité informatique.

Lien vers l'article original: http://citizenkane.fr/securite-informatique-4-bombes-atomiques-en-12-mois.html

[Solutions-Logiciels.com] Linux: trois événement majeurs lui seront consacrés du 13 au 15 octobre

Par Juliette Paoli, le jeudi 10 juillet 2014. Extrait:

Le créateur de Linux, Linus Torvalds, et les dirigeants d'Amazon et de ownCloud ont répondu présents aux prochains événements organisés par la Fondation Linux du 13 au 15 octobre au Centre des Congrès de Düsseldorf. Trois événements en un avec LinuxCon, CloudOpen et Embedded Linux Conference Europe.

Lien vers l'article original: http://www.solutions-logiciels.com/actualites.php?titre=Linux-trois-evenement-majeurs-lui-seront-consacres-du-13-au-15-octobre&actu=14806

[Next INpact] Suite au «fail» de la DILA, Regards Citoyens publie un guide sur l’Open Data

Par Xavier Berne, le mardi 8 juillet 2014. Extrait:

Suite aux différents problèmes qui ont accompagné la mise à disposition, gratuite, des données juridiques détenues par la Direction de l'information légale et administrative (DILA), l’association Regards Citoyens vient de publier un «petit guide à destination des administrations souhaitant basculer du payant à l’Open Data». L’occasion pour l’organisation de revenir de manière synthétique sur le processus d’ouverture et de partage de données publiques, tout en insistant sur le récent épisode de la DILA, qui est considéré comme «l’un des plus gros «fail» administratifs en matière d’Open Data».

Lien vers l'article original: http://www.nextinpact.com/news/88585-suite-au-fail-dila-regards-citoyens-publie-guide-sur-l-open-data.htm

[Wired] Out in the Open: The Crusade to Bring More Women to Open Source

Par Klint Finley, le lundi 7 juillet 2014. Extrait:

De récents rapports de Facebook et Google confirment ce que nous avons toujours su: les géants de la technologie ont un problème de diversité. Mais dans le monde open source, le problème est encore pire.

Lien vers l'article original: http://www.wired.com/2014/07/openhatch

Télécharger ce contenu au format Epub

Lire les commentaires

Sortie de KDE Frameworks 5

Lundi 14 Juillet

KDE Frameworks 5 (KF5) est sorti le 7 juillet 2014 ! Pour rappel, KF5 c’est le résultat de 3 ans d’efforts pour modulariser les KDElibs, les bibliothèques utilisées par la plupart des logiciels KDE. À cette occasion, elles ont été migrées vers Qt5 et améliorées. Une itération majeure donc, mais une évolution et pas une révolution, ce qui facilite la transition.

La modularisation est un objectif de longue date pour rendre les KDElibs utiles aux développeurs Qt. En effet, les bibliothèques KDE sont, au fur et à mesure de leur évolution, devenues un véritable cadriciel (framework) ou, plutôt, un ensemble de bibliothèques interdépendantes ; ce côté monolithique souvent reproché aux KDElibs limitait son utilité en dehors de KDE.

Note: Cette dépêche est essentiellement une traduction des notes de versions et d'un choix de documentations sur les API de KF5 issus du planet KDE, notamment ces trois .

Sommaire Historique

Quand KDE a été lancé, il y a 15 ans, le développement était centré sur les applications et les bibliothèques arrivaient ensuite, lorsqu’une fonctionnalité était utilisée dans plusieurs applications. Aujourd’hui, les bibliothèques KDE sont la base commune de presque toutes les applications KDE, fournissant des fonctionnalités haut niveau comme les barres d’outils ou les menus, la vérification orthographique et l’accès aux fichiers.

À l’heure actuelle, « KDELibs » est distribué comme un ensemble de bibliothèques interconnectées. Dans le cadre du travail sur KDE Frameworks 5, ces bibliothèques ont été méthodiquement réusinées en un ensemble de modules indépendants et multiplateformes qui seront accessibles à tous les développeurs Qt.

KDE Frameworks, conçu comme une extension à Qt, va enrichir l’environnement de développement de Qt avec des fonctions qui simplifient, accélèrent et réduisent le coût du développement Qt. Par exemple, KArchive (un des premiers cadriciels disponibles) offre la prise en charge de nombreux algorithmes de compression dans une bibliothèque indépendante et simple à utiliser. Envoyez-lui simplement des fichiers ; il n’y a pas besoin de réinventer une fonction d’archivage.

La transition de plateforme à Frameworks est en cours depuis presque 3 ans et est menée par les meilleurs contributeurs KDE. Il a été décidé que les versions de KF5 sortiraient avec un cycle plus adapté au développement des cadriciels de KF5, différent de celui de l’espace de travail Plasma. KF5 devient donc un projet à part de la communauté KDE.

Découpage et dépendances

Les cadriciels de KF5 sont classés selon deux axes :

  • Tiers :

    • tiers 1 : aucune dépendance aux autres composants KF5 ;
    • tiers 2 : dépendance possible aux tiers 1 ;
    • tiers 3 : dépendance possible à un autre tiers 3 et aux tiers en-dessous.
  • Type (voir plus bas) :

    • fonctionnel ;
    • intégration ;
    • solution.
Cadriciels fonctionnels

Ces cadriciels sont indépendants. Ils n’ont pas de dépendance à l’exécution, mais offrent une fonctionnalité de haut niveau. La liste suivante n'est pas exhaustive quant au nombre de cadriciels disponibles, elle en présente les principales nouveautés.

KArchive est un cadriciel qui prend en charge les archives compressées dans des formats populaires tels zip, 7z et tar, et propose une compression QIODevice pour gzip, bzip2 et xz. KArchive peut extraire n’importe quel fichier dans l’un des formats pré-cités.

KPlotting est un cadriciel de graphe simple qui gère l’anti-crénelage (anti-aliasing), l’empilage et la mise à jour. Il s’occupe de transformer les données soumises en un graphique avec ses axes et ses étiquettes (il prend en compte le passage de l’unité de départ vers les coordonnées en pixels à l’écran).

Threadweaver rend l’écriture de code multithreadé plus facile en utilisant des tâches de fond. Contrairement à QThreadPool, il prend en compte les dépendances entre tâches, les signaux done (réalisé), ainsi que les signaux globaux jobsDone. Il permet aux fils d’exécution d’être suspendus et arrêtés facilement et ne dépend que de QtCore.

KConfig enregistre et restitue des paramètres de configuration. Il présente une API orientée groupe. Il utilise des fichiers INI et des répertoires/annuaires conformes à la norme XDG. Il génère du code en se basant sur les fichiers XML.

KItemModels contient (entre autres) :

  • un modèle de filtrage récursif pour les vues en arbre ;
  • un modèle de proxy vérifiable pour les arbres et les listes ;
  • et un second modèle de proxy, pour restructurer un arbre en liste.

KCoreAddons dispose des éléments suivants (entre autres) :

  • KJob : une classe de base pour faire des API asynchrones ;
  • file handling classes: directory watching, backup handling, auto save files ;
  • Partage des données en cache sur le disque entre applications ;
  • des classes de gestion de texte: séparer des chaines de caractères entre les mots et ajouter des points de suspension.
Cadriciels d’intégration

Ceux-ci ont des dépendances en fonction de la plateforme pour l’intégration système.

Sonnet a un correcteur orthographique d’arrière-plan, ainsi que des widgets et des dialogues de configuration. Il fonctionne via des extensions et peut fonctionner avec aspell, hspell, hunspell et enchant.

Solid peut détecter le matériel et informer une application sur les périphériques de stockage et les volumes, le CPU, le statut de la batterie, la gestion d’énergie, le statut de la connexion Internet et des interfaces réseau, et le Bluetooth. Pour les partitions chiffrées, l’énergie et le réseau, des démons en fonctionnement sont nécessaires.

Cadriciels solution

Ceux-là nécessitent que leurs propres démons fonctionnent correctement.

KIO permet à l’utilisateur de parcourir et modifier des fichiers indépendamment du fait qu’ils soient locaux ou distants. Il prend en charge un grand nombre de protocoles (incluant ftp, samba, webdav et nfs), de nombreux formats de fichiers compressés, les miniatures, l’extraction de la musique audio, la corbeille et fish, une vue de gestion de fichiers au travers d'une connexion ssh.

KService est un cadriciel qui fournit des fonctionnalités avancées de gestion des greffons, y compris la recherche sur le disque de ceux-ci à la demande. Il est utile pour les architectures à base de composants, où il permet de charger lors de l’exécution les dépendances nécessaires. Il offre également des fonctions pour trouver les applications associées à un type de fichiers, telles que l’identification de l’application préférée de l’utilisateur pour visualiser les PDF.

Migrer vers KF5

Il existe pas mal de ressources pour migrer sans douleur une application fondée sur les bibliothèques de KDE. On peut :

  • lire l’API ;
  • examiner les notes de portage ;
  • s’aider des projets déjà portés ;
  • obtenir de l’aide sur le canal IRC #kde-devel et la liste de diffusion kde-frameworks-devel@kde.org.

Il y a aussi un exemple de projet utilisant KF5.

CMake

A noter, l'adoption des idiomes de CMake : les macros kde4_* ne sont plus utilisées pour créer des cibles, mais les macros CMake, par exemple kde4_add_executable → add_executable. Attention aux dépendances : ${KDE4_KDEUI_LIBS} est remplacé par KF5::WidgetAddons. Notez que ça n’est plus une variable et que, si vous utilisez CMake 3.0, vous obtiendrez un avertissement si elle n’a pas été trouvée. De plus, il n’est plus nécessaire d’utiliser include_directories() pour chaque dépendance, ce sont maintenant les cibles qui s’occupent de ça. Jetez un œil à Extra-cmake-modules : il y a des choses intéressantes dont vous pourriez avoir besoin un jour, de plus c’est une extension CMake, vous pouvez l’utiliser même si Qt ou C++ n’est pas utilisé dans votre projet.

Laurent Montel, développeur KDE – notamment de KDEPIM – a développé des scripts pour faciliter la migration.

C++

Problablement la partie la plus facile, il suffit d’essayer de le faire compiler et de regarder l’API quand cela ne fonctionne pas, puis de recommencer.

Pour commencer le port, c’est en général mieux de s’appuyer sur le cadriciel KDELibs4Support au début. C’est un cadriciel qui contient tous les modules obsolètes, parce que ce sont des fonctionnalités qui ont été déplacées dans Qt5 pour la plupart. Ça aidera à avoir un projet qui compile et, ensuite, vous pouvez supprimer les dépendances obsolètes une par une.

Si vous souhaitez développer en Qt4 pour un moment encore, il peut être utile de faire quelques portages d’abord, par exemple la migration KIcon → QIcon::fromTheme, ce qui réduira la divergence entre la branche Qt4 et la branche Qt5. Ça peut aussi vous aider de faire des tests unitaires avant de migrer, pour éviter de tester toutes les fonctionnalités à la main pendant le portage.

QML

Porter du QML n’est pas trivial, mais il n’y a que quelques projets qui l’utilisent sérieusement. Toutes les technologies sous-jacentes ont changé, ça peut donc devenir épineux. Pour le moment, dans Qt5, il y a deux implémentations de QML. QtQuick 1, qui est celle que nous utilisions dans Qt4 et QtQuick 2 qui est celle que vous voulez utiliser, qui utilise le graphe de scène Qt (Qt Scene Graph) et qui fait de la magie avec le GPU.

Vous pouvez tout d’abord décider de rester en QtQuick 1. Néanmoins, PlasmaComponents a été porté à QtQuick 2, vous devrez donc faire le changement complet pour les plasmoïdes.

Si vous avez avez besoin de faire un port vers QtQuick 2, il y a aussi quelques scripts que vous pouvez utiliser pour faciliter la transition. Pour commencer, vous devez simplement renommer toutes les classes commençant par QDeclarative* vers QQml* et QQuick* ; elles gardent en général le même nom. Par contre, si vous utilisiez les fonctionnalités de QGraphicsView, vous vous êtes fait avoir !

Pour porter le code QML/Javascript vers QtQuick 2, il faut mettre à jour tous les imports. Tous les imports Qt sont montés de version, vous devez donc changer import QtQuick 1.1 pour import QtQuick 2.2, et — dans la même logique — remplacer import org.kde.plasma.components 0.1 par import org.kde.plasma.components 2.0.

Apports

Qt 5 apporte de nombreux nouveaux concepts intéressants, comme QtWebSockets, QtWayland, QtWebEngine ou Qt3D. De plus, cela permet à votre projet d’intégrer correctement le code Qt avec les nouveaux concepts de C++11.

Porter votre projet vers KF5 va l’aider à devenir plus portable et à cibler différentes plateformes.

Amélioration de l’outillage

Séparer les bibliothèques et faire en sorte que le système de compilation fonctionne a provoqué de nombreux cassage de compatibilité. Pour être sûr que tout fonctionne et obtenir des cadriciels compilables et fonctionnels, il était nécessaire d’avoir de meilleurs outils. Une énorme amélioration est l’arrivée d’un système d’intégration continue. Pousser du code pour un cadriciel signifie désormais qu’il est compilé dans un environnement propre et que des tests automatisés sont lancés. C’est aussi utilisé pour construire ses dépendances, donc les problèmes dans le code qui ont pu échapper à l’attention du développeur sont la plupart du temps détectés automatiquement. Les résultats du système d’intégration continue sont souvent disponibles après quelques minutes et, si quelque chose casse, les développeurs reçoivent des notifications sur IRC ou par courriel. Ces courts cycles permettent de résoudre les problèmes quand les modifications effectuées sont encore fraiches dans la tête du développeur. On gagne également du temps, car en récupérant le dernier code en développement, il y a moins de risque d’avoir un code qui ne compile pas.

La compilation déclenche aussi les tests automatisés, qui ont déjà été améliorées récemment, mais restent encore assez loin d’une couverture complète. Avoir des tests automatisés permet de trouver plus facilement les problèmes et améliore la confiance dans le fait qu’un changement particulier ne cause de désastre nulle part.

Ni les compilations continues, ni les tests automatisés ne permettent d’être à 100% sûr que quelque chose ne cassera pas un jour, mais c’est beaucoup moins probable et cela économise du travail aux développeurs. Si un script détecte un problème, c’est probablement beaucoup plus efficace que le test manuel (qui reste nécessaire, évidemment).

Un aspect social de cela est que si quelque chose casse dans les compilations ou tests automatisés, il n’y a pas qu'une seule personne qui est en charge du problème ; ça doit au contraire être un évènement où on « arrête la chaine » et nécessite une attention immédiate — de tout le monde.

Conclusion

La migration vers Qt5, la modularisation et l’amélioration du code des fondations est une avancée technique majeure dans l’histoire de KDE.

Mais les avancées ne sont pas uniquement techniques, l’organisation du projet s’améliore notamment avec plus de relecture de code, une meilleure organisation des dépôts et une unification du flux de travail avec notamment une migration vers GitLab.

La prochaine version de Plasma sera la première à utiliser KDE Frameworks 5 et cela promet d’être intéressant, car, là où le passage de KDE 3 à KDE 4 et de GNOME 2 à GNOME 3 ont été un gros changement de paradigme et technique, il n’est pas prévu de gros changements niveau utilisateur.

Télécharger ce contenu au format Epub

Lire les commentaires

Encore une couche de rouille avec Rust 0.11

Lundi 14 Juillet

Rust 0.11 est sorti le 2 juillet 2014 ! Pour rappel, Rust est un langage de programmation système qui vise la performance et la sûreté. Il est développé par Mozilla, en parallèle d'un nouveau moteur de rendu expérimental écrit en Rust, Servo.

Rust est open source. Son développement est fait de façon ouverte sur GitHub et le code source est publié sous double licence Apache 2.0 et licence MIT.

Sommaire Rapide présentation de Rust Objectifs du langage

L’objectif de Rust est d’être un langage pour l’écriture de programmes systèmes, habituellement écrits en C++. Tout comme C++, Rust permet un contrôle explicite de la gestion de la mémoire et d’autres fonctionnalités du système d’exploitation et du matériel, pour écrire des programmes les plus efficaces possibles.

Rust diffère cependant de C++ en mettant l’accent sur la sûreté : grâce à un système de types fort et à l’intégration dans ce système de types de nombre d’idiomes de gestion de la mémoire (on y retrouve les sémantiques d’ownership, de move, mais également des concepts plus innovants comme l’analyse des lifetimes), le compilateur est capable de détecter à la compilation un très grand nombre d’erreurs qui en C++ auraient pu mener à des bugs, voire à des failles de sécurité potentielles.

En outre, Rust amène également au monde de la programmation système et impérative certaines fonctionnalités récentes issues de la programmation fonctionnelle : types algébriques, filtrage par motif (pattern matching), fermetures lexicales (closures), etc.

En bref, Rust se veut un remplaçant à C++ : moins complexe, plus sûr et plus moderne.

Rust étant développé au sein de Mozilla, on peut se demander s’il est prévu que Rust soit utilisé dans FirefoxOS, ce n’est pas encore le cas, bien que des essais aient été faits.

Exemple

Voilà un exemple d’une implémentation simpliste de ls :

use std::os; fn list_dir(path: &Path) { match std::io::fs::walk_dir(path) { // Le chemin donné par l’utilisateur n’est pas valide None => fail!("Unable to retrieve path: {}", path.display()), // Le chemin donné par l’utilisateur est valide, on liste les fichiers dedans Some(dir) => for file in dir { println!("{}", file.display()); } } } fn main() { // On récupère les arguments passé via la ligne de commande let argv = os::args(); // On vérifie que le nombre d’arguments donnés est bien conforme à ce qu’on attend. match argv.len() { // S’il n’y a pas d’argument, on utilise le répertoire courant comme répertoire à traiter 1 => list_dir(&os::getcwd()), // S’il y a un argument, on le considère comme répertoire à traiter. 2 => list_dir(&Path::new(argv[1])), // Sinon, on considère que l’utilisateur tape avec des moufles. _ => { println!("You must specify exactly zero or one path"); os::set_exit_status(1); } } } La communauté Rust

Rust est développé par Mozilla, qui emploie une équipe à plein temps pour travailler sur le langage, mais aussi par de très nombreux contributeurs : de 51 pour la version 0.1, 450 pour la 0.10 à 559 pour cette dernière version. Des statistiques plus détaillées sont disponibles sur le site RustStat.

Plusieurs moyens de communication existent sur Internet :

Rust a aussi des pages sur Google Plus et sur Facebook, ainsi qu’un mot-clé #rustlang, mais il n’y a pas d’activité particulière dans ces pages ; ce sont des rappels de Reddit.

On peut aussi remarquer que désormais LinuxFr.org fait partie de la mouvance avec sa propre étiquette rust ;) qui permet de retrouver facilement toutes les dépêches et tous les journaux abordant ce sujet.

Les échanges se font aussi directement lors d’évènemements.

Installation

Le tutoriel officiel détaille l’installation sur les différentes plateformes, cependant il faut aller dans le wiki pour avoir plus de détails.

Les procédures d’installation déjà en place pour la version 0.8 (pour Windows, Ubuntu, Arch Linux et Gentoo) décrites dans la dépêche ad hoc sont toujours valables et ont été mises à jour pour cette version. Dès l’annonce, les paquets pour Ubuntu ont été générés dans le PPA hansjorg/rust, une compilation pour Arch est disponible dans le dépôt community et pour Gentoo, l’overlay rust contient un ebuild pour cette version.

Voici rapidement les commandes à utiliser pour installer la dernière version :

# Sous tout type de Linux 64bits curl -O http://static.rust-lang.org/dist/rust-0.11.0-x86_64-unknown-linux-gnu.tar.gz tar xfz rust-0.11.0-x86_64-unknown-linux-gnu.tar.gz (cd rust-0.11.0-x86_64-unknown-linux-gnu/ && sudo ./install.sh) # Sous Arch, disponible dans les paquets officiels # Sous Gentoo sudo layman -a rust sudo emerge --autounmask =rust-0.11.0 # Sous Ubuntu sudo add-apt-repository ppa:hansjorg/rust sudo apt-get update sudo apt-get install rust-0.11

Pour Fedora, vous pouvez compiler en Rust en regardant ici ou .

Changements du langage

De nombreux changements de syntaxe, de sémantique, de bibliothèques sont advenus depuis la dernière version. Par exemple, le développeur de Angolmois a dénombré les changements qu’il a dû apporter à son code entre chaque version, depuis la 0.6. Moins de changements de code ont été nécessaires entre la 0.10 et la 0.11.

Syntaxe

Le symbole ~ a été remplacé par le type Box<T> pour dénoter les owned boxes, et par le mot-clé box pour l’allocation. De plus, les tableaux ~[T] et les chaines ~[str] ont été remplacées respectivement par Vec<T> et String. Comme il s’agit d’un changement très important et souvent mal compris par la communauté, voici une brève explication :

La précédente syntaxe causait de nombreuses confusions, du fait que ~[T] et ~str étaient en fait des structures particulières, et non pas de simple pointeurs ~ vers [T] ou str, ces derniers n’étant pas des types en Rust. Ceci menait à la bizarrerie syntaxique suivante :

// x est de type ~str, une chaîne allouée sur le tas, redimensionnable // du fait qu’elle possède la mémoire pointée // de même, y est de type ~[T], un vecteur redimensionnable alloué sur le tas let x = ~"foo"; let y = ~[1, 2, 3]; // x est de type ~(&'static str), un pointeur vers une zone allouée sur le // tas contenant un pointeur vers une chaîne statique // y est de type ~([T, .. 3]), un pointeur vers une zone allouée sur le tas // contenant un tableau statique à 3 éléments let x = ~("foo"); let y = ~([1, 2, 3]);

Les structures ~[T] et ~str étaient en fait des structures situées sur la pile, contenant 3 champs :

  • un pointeur vers une zone mémoire sur le tas ;
  • la taille de cette zone, ou « capacité » ;
  • et la partie de cette zone occupée par des données valides, soit la longueur de la chaine ou du tableau.

Ces structures implémentent des chaines et des tableaux dits « redimensionnables », car lors d’un ajout, si la capacité n’est plus suffisante, on met à jour le pointeur vers une zone plus grande, et on recopie depuis l’ancienne. Puisque ces structures possèdent leurs données et disposent de sémantiques de déplacement, personne ne possède de pointeur sur l’ancienne zone, qui peut alors être libérée en toute sûreté.

La sémantique de Rust étant devenue suffisamment puissante pour permettre d’exprimer ces propriétés sur des types tiers, ces structures ne nécessitent plus en aucun cas d’être intégrées au compilateur, et ont été déplacées vers la bibliothèque standard, sous les noms de String et de Vec<T>. On peut d’ailleurs noter que String n’est qu’une couche d’abstraction sur Vec<u8> fournissant des méthodes supplémentaires pour garantir que les données sont une chaîne UTF-8 valide.

De même, la syntaxe ~ pour représenter un simple pointeur vers le tas possédant la zone pointée (owned box, ou owning pointer), a été remplacée par Box<T> pour désigner le type et par l’expression box foo réalisant une allocation dynamique et renvoyant un Box<T>.

Cette syntaxe n’ayant plus rien en commun avec Stringet Vec, il n’y a plus de confusion possible. Si foo est de type T, box foo renverra toujours un Box<T> (équivalent de l’ancien ~T), de même que box (foo).

  • let x = box "foo"; // x est de type Box<&'static str>.
  • let x = box ("foo"); // pareil.
  • let x = box 5; // x est de type Box<int>.

Si l’on désire maintenant utiliser les chaînes et les tableaux redimensionnables, il faut être explicite et utiliser les noms String et Vec :

// la méthode from_str alloue une zone de mémoire suffisamment grande // et y recopie le contenu d’une autre chaine, ici une chaine statique // foo est de type String let foo = String::from_str("foo"); // from_slice alloue une zone de mémoire suffisamment grande et y recopie // le contenu d’un autre tableau, ici un tableau statique // bar est de type Vec<int> let bar = Vec::from_slice([1, 2, 3]); // on pourrait également utiliser cette version, équivalente, qui utilise // la macro vec!, fournissant une façon pratique d’initialiser des Vec let bar = vec!(1, 2, 3);

Cette nouvelle syntaxe montre bien que String et Vec sont en fait des structures sur la pile référençant une zone mémoire redimensionnable sur le tas.

Ces types sont munis d’un destructeur, ce qui garantit qu’ils disposent de déplacement (move semantics) et qu’ils possèdent les données pointées.

Ceci évite donc la confusion entre ces types et Box<T> qui n’ont rien à voir entre eux.

Par ailleurs, écrire let x = ~"foo" pouvait faire oublier au programmeur qu’il s’agissait d’une opération couteuse. On avait l’impression qu’il suffisait de prendre un pointeur sur une string, alors qu’il faut en fait allouer une zone sur le tas de la bonne taille, puis recopier la chaine. String::from_str est plus explicite, d’autant plus qu’elle est documentée, du fait qu’elle soit dans la bibliothèque standard et non une fonctionnalité intégrée au langage.

Enfin, bien que ~[] et ~str soient encore disponibles pour le moment, ils devraient être supprimés rapidement. Leur utilisation dans la base de code du compilateur et de la bibliothèque standard a déjà été pratiquement supprimée.

Notons que le pointeur @ qui a été placé derrière une feature gate (il devait être activé explicitement pour pouvoir être utilisé) lors de la sortie de rust 0.10 a été lui aussi été complètement supprimé.

Unboxed closures

Le système de fermetures (ou closures) de Rust a été complètement repensé.

Rust offrait actuellement deux types de fermetures : les stack closures et les « procédures ».

Les stack closures, qui capturaient les variables libres depuis leur environnement par référence. Ce type de fermetures était très utilisé dans du code Rust, mais du fait qu’elle ne possédaient pas leur environnement, elles n’étaient pas à proprement parler des valeurs de première classe. En particulier, il n’était possible de renvoyer une clôture sur la pile (stack closure) qu’à condition de la lier à une durée de vie (lifetime).

// la fonction get_adder prend un entier et renvoie une fermeture // additionnant cet entier (capturé) à un autre passé en argument fn get_adder(x: uint) -> (|uint| -> uint) { // on renvoie une fonction prenant y et renvoyant x + y // x est ici capturé par référence |y| { x + y } } fn main() { let add5 = get_adder(5); let r = add5(3); }

Ce code produisait une erreur du borrow-checker. Si ce code avait été exécuté, l’appel de add5 aurait tenté d’accéder à x via une référence pointant vers une zone mémoire qui n’est plus valide, x étant détruit à la fin de la fonction get_adder. On aurait pu paramétrer les types par des lifetimes et passer x à get_adder par référence, mais cela n’aurait pas totalement résolu le problème. Il n’aurait en aucun cas été possible d’utiliser add5 en dehors de la portée des variables capturées (ici, x).

Les « procédures » (notées proc), qui capturaient leur environnement par copie (en effectuant éventuellement un move). Ces fermetures étaient des valeurs de premier ordre, mais elles permettaient ensuite au code de la fermeture d’effectuer un move depuis les variables capturées au moment où la fermeture était exécutée. Ceci permettait à ces fermetures d’utiliser leur environnement de n’importe quelle façon, mais ne permettait de les appeler qu’une seule fois, car leur environnement était « consommé » par l’appel de la fermeture, du fait des moves possibles.

fn get_proc(x: uint) -> (proc(uint) -> uint) { proc(y) { x + y } // x a été capturé par valeur. Si x avait été // doté de move semantics, toute utilisation de // x ici aurait été une erreur car il aurait été // déplacé dans l’environnement de la fermeture } fn main() { let add5 = get_proc(5); let huit = add5(3); // erreur: l’appel de la procédure prend l’environnement par move // rustc détecte ici l’utilisation d’une valeur déplacée et émet // une erreur. Les procs ne sont donc appelables qu’une seule fois let neuf = add5(4); }

La proposition des unboxed closures rend le système de fermetures bien plus souple.

Toutes les fermetures captureront désormais leur environnement par copie. Les références étant des valeurs comme les autres en Rust, il sera toujours possible de capturer par référence en capturant explicitement une référence plutôt que la variable :

fn get_adder(x: uint) -> (|uint| -> uint) { // x est ici capturé par valeur (copie). Si x avait été // d’un type doté de sémantiques de déplacement, il n’aurait // plus été utilisable autrement que par la fermeture car // il aurait été déplacé vers son environnement, tout comme // dans l’exemple avec proc |y| { x + y } } // il est possible d’obtenir une capture par référence en capturant // explicitement une valeur dont le type est une référence. On fait // alors une copie de la référence // cet exemple reproduira le comportement précédent. La fermeture // est liée à la durée de vie de x fn get_adder_ref(x: uint) -> (|uint| -> uint) { // on crée explicitement une référence let ref_on_x = &x; // la fermeture capture une copie de la référence // et pas une copie de x |y| { *ref_on_x + y } }

Les unboxed closures seront implémentées comme des objets ayant chacun leur type unique contenant leur environnement. Pour refléter leur capacité à être invoquées comme des fonctions, elles devront maintenant implémenter un trait. Plusieurs traits seront introduits, pour représenter tous les cas possibles d’utilisation.

Tout d'abord, Fn : au moment de l’appel, le code reçoit son environnement via une référence mutable. La fermeture peut donc muter son environnement, mais ne peut pas effectuer de move depuis l’environnement. La fermeture est donc appelable plusieurs fois. Ce trait reflète les sémantiques d’appel des anciennes stack closures, tout en permettant de choisir au moment de la création de la fermeture si la copie se fait par copie ou par référence.

FnShared est similaire au précédent, à l’exception que la fermeture reçoit une référence immutable sur son environnement. Elle ne peut donc pas le modifier. L’avantage principal de ces fermetures est qu’elles peuvent être échangées de façon sûre entre différentes tâches s’exécutant de façon concurrente, d’où son nom.

Enfin, FnOnce implémente des sémantiques d’appel des anciennes procédures en passant à la fermeture son environnement par valeur. La fermeture peut alors librement effectuer des moves depuis l’environnement, qui est alors consommé. Une fermeture ne pourra être appelée qu’une seule fois via ce trait.

La syntaxe des fermetures ne sera donc plus que du sucre syntaxique sur la déclaration d’un type implémentant le trait approprié et la création d’une valeur unique de ce type. Mais il sera également possible de créer à la main de tels objets, et d’implémenter par exemple plusieurs comportements possibles. (à vérifier)

Le système de types de Rust ayant connaissance des sémantiques de déplacement, l’implémentation des unboxed closures ne requerra pratiquement aucune modification du système de types. Les règles actuelles garantissent déjà le comportement décrit ci-dessus en fonction de la façon dont l’environnement est passé au code de la fermeture lors de l’appel.

Bibliothèque standard

La bibliothèque standard a été découpée en plusieurs petites bibliothèques indépendantes. libcore, qui contient les fonctionnalités les plus basiques de la bibliothèque d’exécution (runtime library) du langage est ainsi autonome, et peut être utilisée dans des contextes tels que les systèmes d’exploitation ou la programmation embarquée.

Rust dispose maintenant d’une implémentation des expressions rationnelles, inspirée de RE2. Elle a été intégrée dans la distribution officielle en tant que libregex. libregex_macros fournit une extension de syntaxe, regex!, qui permet à rustc de compiler les expressions rationnelles en même temps que le reste du code.

En vrac, quelques autres modifications notables :

  • attention ! test::BenchHarness a été renommée en test::Bencher ;
  • la définition des vecteurs doit être plus précise : [1, 2] n’est plus acceptée, il faut spécifier le type, par exemple ainsi [1u, 2] ;
  • utilisation de Result<T, Error> dans les types de retour de l’interface Serialize ;
  • ajout d’une caisse GraphViz ;
  • réduction de la taille des exécutables ;
  • si vous vous demandez ce que Rust et Lovecraft on en commun, allez voir par ici ;
  • première bibliothèque stabilisée pour la version 1.0 : std::mem.
Autour du langage

Le code du dépôt Rust sur Github (compilateur, bibliothèque standard, tests unitaires et de performance ainsi que les tutoriels) a atteint les 30 000 commits le 25 juin. Voici un florilège des évènements notables :

Computer Language Benchmarks Game

Ce test de performance dont nous avions parlé dans la précédente dépêche sur Rust continue d’être mis à jour. Les sources des programmes de test sont en effet inclus dans les sources même de Rust (voir les fichiers shoutout-*). Les instructions SIMD sont ajoutées aux tests à l’aide du module std::unstable::simd, le test shootout-mandelbrot s’exécute ainsi presque deux fois plus vite.

Test × CPU secs Elapsed secs Memory KB Code B ≈ CPU Load Fasta 1.7 4.66 4.66 780 1283 0% - 1% - 1% - 100% Pidigits 7.2 12.48 12.49 1,708 677 0% - 1% - 0% - 100% Mandelbrot 10 52.22 52.23 780 633 1% - 100% - 0% - 0%

http://www.reddit.com/r/rust/comments/27dc75/what_happened_to_the_shootout_benchmarks/

Travis-CI

Les tests sur Travis-CI utilisant rust-nightly sont restés bloqués à la version du 18 avril. Travis-CI utilise Ubuntu Precise comme environnement et la construction automatique sur Launchpad s’est arrêtée car la version de gcc est trop ancienne. Le script configure de Rust ne prenait pas en charge la définition des variables d’environnement CC/CXX pour changer de version de compilateur. Des correctifs ont été proposés le 2 mai et intégrés depuis. La construction continue chez Launchpad a repris début juin.

Cargo

Cargo est le nouveau gestionnaire de paquets annoncé le 17 mars. Yehuda Katz et Carl Lerche réalisent son développement.

Le 21 juin, le gestionnaire n’est pas encore en version alpha mais permet de résoudre les dépendances et de les récupérer depuis Git. La version alpha est publiée le 23 juin en même temps que le site web associé pour sa documentation : crates.io. Un PPA pour Ubuntu est disponible à ppa:cmrx64/cargo, pour notamment pouvoir utiliser Cargo sur Travis-CI.

Servo

Servo est un projet expérimental de Mozilla visant à construire un moteur de navigateur Web pour la nouvelle génération d’appareils : téléphones portables, processeurs multicœurs et GPU haute-performance, en tirant parti de la sûreté de Rust, et de ses facilités pour exprimer la concurrence. Il est actuellement développé pour Mac OS X et Linux 64 bits. Il a récemment passé avec succès le test Acid2, comme planifié dans les objectifs du second trimestre.

Servo: Designing and Implementing a Parallel Browser.

Liens

Notes de version.

Récapitulatifs This Week in Rust

Si vous voulez suivre le mouvement de tout ce qui se passe à propos de Rust sans avoir à lire le détail des commits, des annonces sur la liste de diffusion, de Reddit ou de Twitter, le blog This Week in Rust fait une synthèse hebdomadaire des nouveautés et actualités autour de Rust :

Meeting Weekly

https://github.com/mozilla/rust/wiki/Meetings

Évènements

De nombreux évènements sont organisés autour de Rust. La rencontre parisienne se répète tous les 3es lundis du mois dans les locaux de Mozilla.

  • Paris, le 21 avril — Rust MeetUp ;
  • Londres, du 25 au 28 avril — Ludum Dare 29 ;
  • San Francisco, le 8 mai — Rust MeetUp : vidéos disponibles sur air.mozilla : Testing Rust and Fuzzing compilers de John Regehr, QuickCheck de Andrew Gallant et Testing Hackathon de Erick Tryzelaar ;
  • Paris, le 19 mai — Rust MeetUp, sur Servo ;
  • Pittsburgh, le 19 mai — Rust MeetUp : Code and Supply ;
  • Seattle, le 22 mai — Rust MeetUp  ;
  • Paris, le 16 juin — Rust MeetUp ;
  • San Francisco, le 10 juin — Dinnerup ;
  • Brooklyn, le 21 juin — Rust MeetUp ;
  • Pittsburgh, le 23 juin — Rust MeetUp : Code and Supply ;
  • Londres, le 26 juin — First Rust MeetUp in London : Awesome Rust, Servo: the parallel browser engine ;
  • San Francisco, le 26 juin — Rust Meetup, vidéos disponibles sur air.mozilla.org : Library Ecosystem for Rust Game Development, OpenGL and Rust, Voyager, Reducing VR latency with Rust ;
  • Lisbonne, le 2 juillet — Rust MeetUp : Goals and crash course through the tutorial ;
  • San Francisco, juillet — Rust Meetup : WebTech ;
  • Seattle, le 7 juillet — Rust MeetUp ;
  • Hanovre, le 10 juillet — Rust MeetUp ;
  • Paris, le 21 juillet — Rust MeetUp ;
Présentations

Il y aura peut-être bientôt des cours de Programmation Fonctionnelle Système en Rust à Mozilla Paris.

Tutoriels et documentation Projets Nouveaux projets Conclusion

La liste des améliorations pour cette version de Rust n’est pas bien longue: modification des types Vectors, et les Strings en préparation des types à taille dynamique (DST), la suppression de ~ et continuation du découpage de la bibliothèque standard de Rust. Tout cela a nécessité beaucoup de travail de fond, et c’est le signe que Rust gagne en maturité.

Côté communauté, on a des développeurs payés par Mozilla et Samsung qui travaillent sur Rust et Servo, des dizaines de nouveaux projets, la prise en charge de Rust dans de plus en plus de logiciels et d’environnements, et une présence sur le web toujours plus importante, Rust semble promis à un bel avenir.

Télécharger ce contenu au format Epub

Lire les commentaires

Festival des Vieilles Charrues : le Libre à l'honneur

Vendredi 11 Juillet

Le partenariat technique avec la section française d'Ubuntu a été reconduit pour le Festival de musique des Vieilles Charrues 2014 (du 17 au 20 juillet). L'association infothema aura le plaisir encore cette année de promouvoir la distribution Linux Ubuntu ainsi que les logiciels libres (présentations orientées grand public) dans l'imposant cybercafé géré à 100% avec du Libre. Merci à l'équipe Ubuntu pour sa confiance… et vivement le festival!

Accès au stand libre et gratuit
Localisation : Site de Kerampuil à Carhaix (Finistère - Bretagne)

Télécharger ce contenu au format Epub

Lire les commentaires

La folie Docker

Jeudi 10 Juillet

Docker, présenté ici même en mars dernier, est un conteneur ou isolateur, ou encore système de cloisonnement (plus de détails en seconde partie). Il se repose sur des systèmes comme LXC, les namespaces et les cgroups (control groups) de Linux, qui permettent de limiter et isoler l'utilisation des ressources de type processeur, mémoire, disque, etc. Docker se compare aux BSD Jails et aux zones de Solaris. Il est développé en Go, sous licence Apache 2.0, tout ce qu'il y a de plus libre.

La première version de Docker date du 20 mars 2013. 16 mois plus tard, 9,308 commits de 509 contributeurs, 2.75 million de téléchargements, plus de 14,000 applications “Dockerisées”, c'est la version 1.1.0. qui est livrée. La folie Docker s'est emparée d'Internet tout entier !

Sommaire Petite introduction

Les conteneurs ou isolateurs, ou encore systèmes de cloisonnement permettent de faire tourner plusieurs environnements de systèmes d'exploitation sur une seule et même machine physique. Ce type de logiciel se compare avantageusement aux hyperviseurs, virtualisateurs et émulateurs, par le fait que le seul noyau qui tourne est celui de la machine physique, et il n'y a pas de couche de « virtualisation ».

Isolateur :

Émulateur :

Benchmarks :

Changements entre la version 0.11 et 1.0 Building for Developers
  • Une nouvelle instruction de Docker build est apparue, COPY, qui copie les fichiers et dossiers en l'état depuis le build context;
  • Améliorations autour de l'instruction ADD, et les volumes conservent le propriétaire et les permissions des fichiers pendant le build des images.
Ops Tooling for Sysadmins
  • Docker a désormais la capacité de mettre en pause et redémarrer des conteneurs, permettant aux utilisateurs de récupérer des ressources CPU pour une gestion plus fine de celles-ci.
  • Mise à jour du profil de sécurité pour l'accès aux périphériques et des capacités pour les conteneurs.
  • Au niveau du stockage: amélioration du backend DeviceMapper, prise en charge de XFS, gestion des périphériques physiques et amélioration des performances de la suppression d'un conteneur.
  • L'IANA réserve les ports 2375, 2376 respectivement pour le trafic HTTP et HTTPS de l'API Docker.

En plus de la correction de 40 bugs et l'amélioration de la cohérence de l'API, la documentation a été entièrement ré-écrite.

Pour les plus intéressés :

Changements entre la version 1.0 et 1.1.0 Très attendue, la nouvelle fonctionnalité .dockerignore

Vous pouvez ajouter un fichier .dockerignore à côté de votre Dockerfile ; dans ce cas, Docker va ignorer les fichiers et répertoires indiqués dans ce fichier quand il enverra le "build context" au démon.

Exemple: https://github.com/dotcloud/docker/blob/master/.dockerignore

mettre en Pause des conteneurs pendant le commit

Auparavant, faire un commit sur un conteneur actif n'était pas recommandé, à cause du risque de fichiers dans un état corrompu (par exemple, si ces fichiers étaient en cours d'écriture pendant le commit).
Les conteneurs sont maintenant mis en pause quand un commit est lancé.

Vous pouvez dévalider cette fonctionnalité avec docker commit --pause=false <container_id>
.

Voir la fin des logs

Vous pouvez maintenant consulter la fin des logs d'un conteneur. Par exemple, pour avoir les dix dernières lignes d'un log, avec la commande docker logs --tail 10 . Vous pouvez aussi suivre en temps réel les logs d'un conteneur sans être obligé de lire le fichier complet avec docker logs --tail 0 -f <container_id>.

Un fichier tar peut être passé en tant que contexte pour docker build

Vous pouvez donner une archive tar à docker build en tant que contexte. Cela peut être utilisé pour automatiser les docker builds, par exemple : cat context.tar | docker build - ou docker run builder_image | docker build -

Monter/binder votre système de fichiers complet dans un conteneur

/ est maintenant autorisé en tant que source de --volumes. Cela signifie que vous pouvez binder/monter votre système de fichier complet dans un conteneur, si besoin. Par exemple :
docker run -v /:/my_host ubuntu:ro ls /my_host
Cependant il est maintenant interdit de monter vers /.

Autres améliorations et changements

L'allocation de port (utilisez la commande docker port pour voir le mapping) a été améliorée. Dans la version précédente, parfois Docker vous empêchait de démarrer un conteneur avec des ports précédemment alloués, que Docker croyait à tort encore alloués. Cela a été corrigé.

Un bug dans la commande docker save était apparu dans la dernière version. La commande docker save créait parfois des images avec des métadatas invalides. La commande crée maintenant des images avec des métadatas correctes.
La commande docker inspect lancée dans un conteneur affiche maintenant les conteneurs liés à ce conteneur.
Le flag de docker commit a amélioré sa validation, pour vous empêcher de commiter une image avec un nom comme -m. Les noms des images contenant des tirets peuvent entrer en conflit avec les flags de la ligne de commande.
L'API a maintenant des codes de retour améliorés pour start et stop. Essayer de démarrer un conteneur déjà démarré renvoie maintenant une erreur 304.
La performance a été globalement améliorée. Le démarrage d'un démon est plus rapide que dans les versions précédentes. La performance du démon a aussi été améliorée quand il gère un grand nombre d'images et de conteneurs.
Un problème avec les espaces et les multi-lignes dans les Dockerfiles a été corrigé.

Packaging

La version 1.0 est déjà disponible dans Debian Sid/Unstable.

boot2docker pour Mac OS X et Windows

http://boot2docker.io/

boot2docker est une distribution Linux très légère, basée sur Tiny Core Linux, et créée spécifiquement pour lancer des conteneurs Docker. Elle fonctionne complètement en RAM, pèse ~27MB et boote en moins de 5s (YMMV).

boot2docker s'installe sous Windows et sous OSX.

Annonces de la #dockercon

La version 1.0 a été annoncée à l'occasion de la toute première dockercon.

Pour une première édition, elle a réuni 600 personnes (avec 400 sur liste d'attente !), ce qui peut être considéré comme un beau succès marketing.

Cette conférence a notamment été l'occasion pour l'équipe Docker d'annoncer 3 bibliothèques :

libcontainer

Libcontainer permet aux conteneurs de travailler avec les espaces de noms Linux, les control groups, les capabilities, les profils de sécurité APPArmor, les interfaces réseaux et les règles de pare-feu d'une manière cohérente et prédictible.
Dans ce cas, les conteneurs ne s'appuient plus sur des composants de l'espace utilisateur Linux comme LXC, libvirt, ou systemd-nspawn. Docker déclare : « Cela réduit fortement le nombre de parties mouvantes et protège Docker des effets de bord introduits par les versions et distributions de LXC ».

libswarm

Décrit comme « une boite à outils pour créer des services réseaux », l'objet de libswarm est de simplifier les déploiements d'applications Docker dans des configurations multi-nœuds, les nœuds pouvant tourner sur des distributions Linux différentes..
Swarm (nom/verbe) signifie essaim ou essaimer.

Cela permettra en retour de faciliter l'adoption de Docker en entreprise pour les déploiements d'applications sans devoir choisir une plateforme de clustering. Solomon Hykes, fondateur de Docker et développeur de libswarm déclare dans un entretien récent avec Phil Whelan d'ActiveState: "Je ne crois pas qu'il devrait y avoir une seule plateforme de clustering dominante que tout le monde utiliserait".

Démo venant de Dockercon sur youtube :/

libchan

Libchan est une bibliothèque réseau ultra-légère qui permet aux services réseaux de communiquer de la même manière que les goroutines communiquent en utilisant des canaux :

  • Simple message passing
  • Synchronisation pour la programmation parallèle
  • Nesting : les canaux peuvent envoyer (vers) des canaux
  • Libchan gère les options de transport suivantes :
    • In-memory Go channel
    • Unix socket
    • Raw TCP
    • TLS
    • HTTP2/SPDY
    • Websocket

Voir cette discussion sur libchan avec le créateur de Docker (shykes pour Solomon Hykes)

Des spécifications sont précisées.

La folie Docker

Docker est super « à la mode » ! En 15 mois, à peine, et parti de quasiment rien, il devient un logiciel majeur dont tout le mode parle, même le PDG de Microsoft, Satya Nadella, qui a tweeté ce lien sur l'utilisation de Docker dans le cloud Azure de Microsoft !

Entretien avec Jérôme Petazzoni Peux-tu nous parler de ton parcours ?

Jérôme Petazzoni : j'ai eu un bac S en 1996. Après deux ans de prépa (Maths Sup' et Spé) où j'ai fait trop peu d'informatique à mon goût, je suis parti décrocher un Master d'informatique à l'Université de Marne-la-Vallée (qui depuis s'appelle "Paris Est"). Ensuite, j'ai fait un peu de tout, tant que ça touchait de près ou de loin à Linux ou l'Open Source ; avec une grosse préférence pour les projets d'infrastructure. Je ne vais pas copier-coller mon CV, je pense que ça ennuierait tout le monde. Mais une expérience importante pour la suite, ça a été de découvrir Xen en 2004. L'année suivante, je m'associe avec un ami pour monter Enix et miser à fond sur l'hébergement de VM.

C'est peu après cette époque que je rencontre Solomon, co-founder de dotCloud (l'ancien nom de Docker). Il avait besoin de serveurs, on en avait ; on cherchait une solution de déploiement, c'était justement ce sur quoi travaillait dotCloud : nous étions faits pour nous entendre. C'est comme ça qu'en 2010, il m'a proposé de le rejoindre à San Francisco pour s'occuper de l'infrastructure et des "ops" pour dotCloud, qui venait de déménager pour la Californie.

Tu fais quoi chez Docker ?

Jérôme Petazzoni : plein de choses ! Avant de lancer Docker, nous avons développé et opéré un PAAS (dotCloud, concurrent d'Heroku). Il existe encore et je fais partie de l'équipe qui s'en occupe.

Mais j'aide aussi régulièrement les "core maintainers" (qui travaillent à plein temps sur Docker) ainsi que ceux qui développent les produits SAAS que nous offrons autour de Docker. Tu es victime d'un bug kernel mystique qui fait rebooter ta machine quand tu démarres un conteneur orienté vers l'Ouest ? Ta partition BTRFS prétend être pleine alors que "df" indique le contraire ? Tes règles iptables repeignent en rouge le trafic multicast qui sort de tes conteneurs ? Je peux t'aider !

En parallèle, je fais beaucoup d' "évangélisme", en l'occurrence sous forme de présentations dans diverses conférences (LinuxCon, OSCON…) et dans d'innombrables meet-ups locaux afin de faire connaître Docker, rencontrer nos utilisateurs, et discuter avec eux de leurs besoins et leurs attentes vis-à-vis du projet.

Vous êtes combien d'employés chez Docker maintenant ? Et contributeurs ?

Jérôme Petazzoni : on est une quarantaine d'employés, mais je serais incapable de donner un chiffre précis, car on recrute sans arrêt ! 5 personnes travaillent à plein temps sur le "Docker Engine" (la partie Open Source), mais quasiment toute l'équipe a contribué à un moment ou à un autre, que ça soit une petite feature, un bug fix, de la documentation … Mais l'essentiel du développement est maintenant entre les mains de la communauté, avec plus de 500 contributeurs au total. Il arrive assez souvent que la "core team" ne fasse que de la revue de code des jours durant, pour gérer toutes les contributions que l'on reçoit.

Comment est-ce que vous arrivez à gérer un tel afflux de contributions ? (presque 2000 forks sur github)

Jérôme Petazzoni : tout d'abord, il y a un processus très clair. Le fichier CONTRIBUTING à la racine du dépôt du projet définit tout dans les détails. Pour simplifier, toutes les contributions passent par une "pull request" sur GitHub. Le code et la documentation doivent suivre certaines règles très strictes. Chaque partie du dépôt est gérée par des mainteneurs. Pour qu'une modification soit acceptée (qu'il s'agisse d'une contribution externe ou interne à Docker Inc.!), elle doit être validée par la majorité absolue des mainteneurs concernés. Si seule la documentation change, seuls les mainteneurs de la documentation sont impliqués ; si c'est la gestion du réseau, ça sera d'autres personnes, et ainsi de suite. Si une modification concerne plusieurs sections, il faut l'accord de tout le monde.

Détail intéressant : il y a plus de 20 mainteneurs à ce jour, et moins de la moitié sont employés par Docker Inc. ; ça montre que, le projet est bel et bien entre les mains de la communauté. D'ailleurs, on recherche en permanence de nouveaux mainteneurs pour aider à traiter ce flot de contributions. À bon entendeur …

Comme il y a souvent plus de 100 pull requests ouvertes à un instant donné, nous avons développé un outil en ligne de commande pour faciliter le processus ; par exemple, pour permettre à un mainteneur d'identifier les pull requests le concernant, et tout particulièrement celles ayant déjà reçu l'approbation d'autres mainteneurs (et donc proches d'être intégrées). Cet outil s'appelle Gordon (c'est aussi le nom de la tortue qui vit dans nos bureaux à San Francisco !), il est Open Source, et disponible sur https://github.com/dotcloud/gordon. Il utilise l'API GitHub ; autrement dit, il est utilisable pour d'autres projets souhaitant implémenter un processus similaire.

Pourquoi Go ? D'ailleurs, vous seriez pas le projet le plus important écrit dans ce langage ?

Jérôme Petazzoni : il y a des raisons techniques et non techniques. Sur le plan technique, Go gère nativement l'exécution concurrente, grâce aux goroutines (ça ressemble aux greenlets), tout en étant plus facile d'apprentissage que, par exemple, Erlang ou Haskell. De plus, par défaut, un programme Go se compile en un binaire massif embarquant presque toutes les bibliothèques nécessaires à son exécution. Cela veut dire que pour faire tourner un programme Go, il suffit de télécharger le binaire, l'exécuter, et ça marche. Pas besoin de yum/apt/emerge/pacman des bibliothèques supplémentaires, ou même d'exécuter un script d'installation. Cette caractéristique était très importante au début du projet, afin d'encourager les gens à le tester le plus simplement possible.

Sur le plan non technique, Go, c'est un peu la Suisse des langages modernes. Si on avait choisi Python, la communauté Ruby aurait grogné. Si on avait choisi Ruby, la communauté Python aurait grogné (et on serait probablement passés pour des imbéciles, car au début du projet, la majorité de l'équipe était plus à l'aise en Python qu'en Ruby). Si on avait choisi Java, tout le monde aurait râlé ! Plus sérieusement, Go était un moyen de ne pas choisir de camp. Bien sûr, c'était un pari risqué, surtout à l'époque ; mais même si la communauté Go est beaucoup plus restreinte, elle s'est avérée être très pointue dans les domaines qui nous intéressaient. Au final, même si c'est évidemment plus difficile de recruter des développeurs Go (plutôt que Python, Ruby ou Java), ceux qu'on trouve ont plus souvent le profil que l'on recherche.

Sommes-nous le projet le plus important en Go? Euh, c'est quoi, un projet important? Si on en croit les métriques de GitHub (forks, stars, contributeurs, activité…), oui, très probablement ! Mais il y a peut-être des projets encore plus gros dans les labos secrets de Google ou autre. Disons que c'est probablement le plus visible des projets Open Source écrits en Go!

Comment Docker s'articule-t-il avec LXC (Linux Containers) ?

Jérôme Petazzoni : Docker a parfois été décrit comme une surcouche de LXC. D'un point de vue strictement technique, c'était vrai au début, puisque Docker exécutait "lxc-start" pour lancer les conteneurs.

Cependant, depuis la version 0.9, Docker a ajouté un autre moteur d'exécution natif, basé sur libcontainer. Libcontainer est une bibliothèque Go, permettant de faire le travail de LXC, c'est-à-dire la gestion des namespaces et des control groups (les mécanismes du noyau Linux qui composent les conteneurs). Cette bibliothèque est réutilisable en dehors de Docker si nécessaire. Sous le capot, elle fonctionne exactement comme LXC et utilise les mêmes appels système. Mais elle est utilisée par défaut et, par conséquent, il n'est plus nécessaire d'installer les paquetages LXC pour faire tourner Docker. Ça simplifie l'installation.

Ensuite, par rapport à LXC, Docker offre une tonne d'autres fonctionnalités : une API REST, un système permettant de transférer des images depuis et vers une registry, le build avec les Dockerfiles … Aujourd'hui, Docker est une surcouche de LXC tout comme apt et yum sont des surcouches de tar, cpio, et wget !

Comment Docker se compare-t-il par rapport aux BSD Jails, zones de Solaris, OpenVZ Virtuozzo, et Linux-VServer ?

Jérôme Petazzoni : ces projets se comparent à LXC plutôt qu'à Docker. Docker ne va pas les remplacer, mais plutôt s'intégrer avec eux.

Parallels (la société qui développe OpenVZ) a annoncé qu'elle allait contribuer à libcontainer. Il est donc possible que Docker puisse prochainement lancer des VE OpenVZ. VServer, c'est nettement moins certain (et il y a certainement beaucoup moins de gens qui s'en servent encore).

Il est possible de porter Docker sur FreeBSD et Solaris. Beaucoup de fonctionalités doivent être adaptées : non seulement le moteur d'exécution, mais aussi la couche réseau (il faut adapter le système actuel, qui utilise iptables et un pont Ethernet) et le stockage (BTRFS, AUFS et DeviceMapper n'existent pas et seraient vraisemblablement remplacés par ZFS pour le système de copy-on-write).

On voit tous les jours des nouveaux projets démarrer, mais Docker a eu un succès rarement vu dans le monde du logiciel libre. C'est quoi la recette de cette réussite ?

Jérôme Petazzoni : un énorme coup de bol ! Être au bon endroit, au bon moment, avec la bonne techno et la bonne équipe. En 2008, dotCloud (avant d'être un PAAS) ressemblait énormément au Docker actuel. Mais il manquait plein de choses pour réussir : il fallait des noyaux spéciaux (avec, entre autres, OpenVZ et AUFS), la création d'images était beaucoup plus lourde … L'outil était génial, mais seulement pour des sysadmins très pointus et très motivés. Ça a servi de base pour construire le PAAS dotCloud.

Quelques millions de conteneurs plus tard, on avait acquis une solide expérience dans ce domaine ; cette expérience nous a permis d'aller très vite dans le développement de Docker. Le fait d'être à San Francisco a aussi contribué au décollage rapide, car on côtoyait sans cesse des gens construisant des grosses architectures distribuées, qui ont vu immédiatement le potentiel de Docker et nous ont énormément encouragés. Les conteneurs sont très adaptés, par exemple, aux micro-services.

Enfin, si on regarde en détail les fonctionalités bas niveau du noyau sur lesquelles reposent Docker (et les conteneurs en général), elles n'étaient pas aussi stables il y a ne serait-ce que deux ans (et encore aujourd'hui, elles continuent de s'améliorer sans cesse).

Ta fonctionnalité préférée de Docker ?

Jérôme Petazzoni : je vais dire une des rares que j'ai implémentées, le privileged mode ! Techniquement, rien de sorcier : c'est juste une option permettant de lancer un conteneur sans limiter ses droits d'accès. Il peut tout faire, y compris casser complètement la machine sur laquelle il tourne (comme l'utilisateur root). Mais grâce à ça, il y a plein de choses qu'on peut faire tourner dans Docker (et qu'on ne pouvait pas avant) : OpenVPN, Xorg, KVM, et même Docker lui-même (très utile pour l'intégration continue et le développement du projet).

Grâce à ça, on peut piquer le slogan de NetBSD, et dire "of course it runs in a container" :-)

Les nouveautés à venir dans les prochaines versions de docker (identity, authentification…) ?

Jérôme Petazzoni : d'un point de vue "devops", ce qui est le plus prometteur, c'est à mon avis libswarm. Libswarm permet d'interfacer ensemble des clients Docker (CLI ou utilisant directement l'API), des hôtes Docker (faisant tourner des conteneurs), et des ordonnanceurs de ressources (comme Mesos par exemple). Le but est de pouvoir dire "je veux 4 conteneurs basés sur l'image webfront42, chacun sur une machine différente, mais dans le même datacenter que mon conteneur dbfront69", et que le système choisisse tout seul où les placer en fonction des ressources (mémoire, CPU…) disponibles à un instant donné. Il y a ensuite une infinité de variantes sur ce thème : pouvoir relancer les conteneurs lorsqu'une machine est indisponible ; lancer automatiquement de nouvelles machines (si on est sur un IAAS) lorsqu'on manque de capacité ; s'interfacer correctement avec des load balancers ; etc.

Bien sûr, il va aussi y avoir plein d'améliorations pour une clientèle "enterprise" : signature des images pour en assurer la provenance ; analyse des graphes de dépendances entre images pour déterminer celles affectées par une vulnérabilité ; possibilité d'héberger en interne les services du "Docker Hub" …

Le fondateur (le français Solomon Hykes, Epitech 2006) a recruté un PDG, pris la fonction de CTO et reste actif sur https://github.com/shykes. En France, il aurait pris la fonction de PDG. Est-ce typique des US ?

Jérôme Petazzoni : aucune idée !

Tu peux nous expliquer et nous en dire plus sur l'exploit présent dans la version 0.11 ?

Jérôme Petazzoni : cette attaque utilise un appel système particulier, open_by_handle_at(). Cet appel système permet d'ouvrir un fichier en spécifiant non pas son chemin, mais un identifiant opaque. Cet identifiant opaque est normalement obtenu en utilisant un autre appel système, name_to_handle(). Le but est de faciliter l'implémentation de serveurs de fichiers en userspace (par exemple NFS ou 9P). Cette partie est expliquée dans cet article sur LWN.

Il se trouve que l'identifiant opaque en question est, dans la plupart des cas, l'inode du fichier. Il se trouve aussi que dans la plupart des systèmes de fichiers (incluant EXT2/3/4), l'inode de la racine est toujours 2. Il est alors enfantin d'utiliser open_by_handle_at() pour accéder à la racine du système de fichiers sur lequel se trouve un conteneur.

open_by_handle_at() est contrôlé par une capability, CAP_DAC_READ_SEARCH. Le problème, c'est que jusque Docker 0.11, au lieu d'enlever toutes les capabilities pour ne laisser que celles qui sont inoffensives, Docker enlevait celles qui étaient dangereuses pour laisser toutes les autres. Bilan, quand CAP_DAC_READ_SEARCH a été ajouté au noyau, on a oublié de le mettre dans la liste des permissions dangereuses.

« Mais pourquoi vous avez fait un truc pareil ? Tout le monde sait que la sécurité, ça marche pas comme ça ! Faut tout enlever, et donner uniquement les permissions nécessaires ! » Absolument. C'est un héritage des anciennes versions de LXC, dans lesquelles on ne pouvait spécifier que lxc.cap.drop. Les versions plus récentes permettent de spécifier à la place lxc.cap.keep, mais par souci de compatibilité avec les anciennes versions, on utilisait encore lxc.cap.drop. C'est d'ailleurs une des raisons qui nous ont poussé à développer libcontainer : gérer toutes les versions différentes de LXC devenait difficile.

Détail intéressant : l'exploit ne fonctionne a priori pas si vous utilisez BTRFS (car, au moins sur mes machines, le numéro d'inode de la racine n'est pas 2) ou si /var/lib/docker est sur un autre système de fichiers (l'exploit permet alors tout de même de sauter d'un conteneur à l'autre, en étant un peu créatif).

Enfin, nous avons toujours été assez clairs sur le fait qu'il fallait être prudent lorsqu'on fait tourner des processus en "root" dans des conteneurs ; en particulier du code arbitraire. Notre position est simple : les conteneurs seront un jour aussi fiables que les VM, mais ce jour n'est pas encore arrivé ; et en attendant, il faut utiliser des couches de sécurité additionnelles et/ou limiter le champ d'application des conteneurs. La bonne nouvelle, c'est que 99% des applications n'ont pas besoin des droits "root". Les conteneurs sont donc déjà tout à fait utilisables !

Télécharger ce contenu au format Epub

Lire les commentaires

Sortie de ROOT 6.00/00

Jeudi 10 Juillet

L'équipe ROOT a annoncé la sortie de la version 6.0 le 29 mai dernier. ROOT est un framework d'analyse de données très utilisé dans le domaine de la physique des particules et de la physique nucléaire. Les versions 6.00/01 et 6.00/02 sorties respectivement le 18 juin et le 3 juillet apportent des corrections à cette version 6.0.

Exemples d'utilisation

ROOT fournit un ensemble de bibliothèques facilitant l'analyse de données. Il permet la création de figures comme celles qui ont été présentées lors de l'annonce de la découverte du boson BEH, le boson de Higgs.

ROOT est également utilisé pour simuler des détecteurs, mais aussi créer des systèmes de visualisation des données en ligne…

Nouveautés Nouvel interpréteur

La principale nouveauté de ROOT 6, qui justifie le changement de version majeure, est le remplacement de l'ancien interpréteur de C/C++ CINT (300k lignes de code) par un nouvel interpréteur appelé Cling (5k lignes de code). La rétro-compatibilité avec CINT est assurée. Cling est basé sur la technologie LLVM JIT/Clang (et sera à terme basé sur LLVM MCJIT/Clang). Les développeurs justifient ce choix par le fait que CINT était vieux :

  • Il a été conçu il y a une vingtaine d'années pour prendre en charge le C. La prise en charge du C++ a été ajoutée par la suite avec néanmoins beaucoup de restrictions.
  • Le deuxième argument concerne sa maintenance. Le développeur originel n'est plus au CERN et la taille relativement importante du code (300 000 lignes) a décidé les développeurs à franchir le pas.
Compilation

Historiquement, ROOT se compilait avec le système « ./configure;make; ». Il est toujours possible d'utiliser ce moyen pour compiler ROOT 6.00. Cela dit, une compilation à l'aide du système « cmake » est maintenant également possible. Les informations sont disponibles ici.

Architectures prises en charge et compilateur requis

Du fait du passage à Cling et Clang/LLVM, le nombre d'architectures prises en charge a drastiquement diminué. ROOT 6.00 n'est disponible que sous Linux i32, x86-64 et x32 et OSX x86-64. À noter l'absence de Windows, mais ce dernier devrait être rapidement pris en charge dans les futures versions.
Au niveau compilateur, il est nécessaire de disposer au minimum de gcc 4.8 ou de Clang 3.4.

Nouvelles palettes de couleur et transparence

Cette version voit l'apparition de 5 nouvelles palettes de couleurs prédéfinies

Par ailleurs, une option « alpha » a été ajoutée afin de préciser le niveau de transparence d'un objet (TAttText, TAttMarket, TAttLine…) que l'on désire.

Changement de logo

Le passage à cette version 6 est aussi l'occasion de voir l'apparition d'un nouveau logo.
L'ancien logo qui datait d'octobre 1999 :

a été remplacé par celui-ci :

Autres nouveautés

D'autres changements importants ont également eu lieu :

  • une nouvelle bibliothèque réseau a été ajoutée,
  • une nouvelle classe TTreeReader a été ajoutée permettant un accès plus simple, plus sûr et plus rapide au contenu des TTree,
  • diverses améliorations dans PROOF, l'extension qui permet de paralléliser le traitement d'une analyse,
  • prise en charge des boîtes à moustaches,
  • le binding Python est entièrement pris en charge par ROOT 6. Ce n'est pas encore le cas du binding Ruby,
Télécharger ce contenu au format Epub

Lire les commentaires

Atelier du Samedi Libre les 26 juillet et 30 août 2014 à Marseille

Jeudi 10 Juillet

L'association CercLL vous invite à deux éditions de l'Atelier du Samedi Libre, qui se dérouleront les 26 juillet et 30 août prochains de 14h30 à 17h30, à la Fabulerie 4 rue de la Bibliothèque 13001 Marseille. Ces évènements sont toujours dans le cadre de la convention de partenariat qui lie l'association et la Fabulerie.

Ces ateliers se déroulent, en général, sur une séquence hebdomadaire de deux à trois séances de travail dédiés à un thème déterminé.

Comme le mot atelier le laisse présumer, dans ce cadre, nous proposons une approche pratique des outils libres.

Nous avons décidé de nous adresser à un public débutant qui cherche à mieux connaître son ordinateur et les applications les plus courantes que tout un chacun utilise.

Prérequis :

  • les personnes qui veulent participer à ces ateliers devront s’inscrire sur la Fabulerie ou directement via notre site ;
  • l'atelier n'aura lieu que si quatre personnes au moins sont inscrites ;
  • l'inscription équivaut à un engagement moral de participation.

Atelier « Découverte des Logiciels Libres »

Cet atelier s’adresse plus particulièrement aux débutants soucieux d’utiliser de manière plus rationnelle leur ordinateur. L'entrée est libre.

Télécharger ce contenu au format Epub

Lire les commentaires

Pages