Linux France

S'abonner à flux Linux France
Mis à jour : il y a 17 min 52 sec

PacketFence v4.2 maintenant disponible

Jeudi 8 Mai

Inverse annonce la sortie de la version 4.2 de PacketFence. PacketFence est une solution de conformité réseau (NAC) entièrement libre (GPL v2), supportée et reconnue. Procurant une grande liste de fonctionnalités telles un portail captif pour l'enregistrement ou la remédiation, une gestion centralisée des réseaux filaires et sans fil, le support pour le 802.1X, l'isolation niveau-2 des composantes problématiques, l'intégration au détecteur d'intrusions Snort et au détecteur de vulnérabilités Nessus - elle peut être utilisée pour sécuriser efficacement aussi bien des réseaux de petite taille que de très grands réseaux hétérogènes.

La version 4.2 de PacketFence apporte de nombreuses améliorations comme l'isolation de type hotspot, un nouveau portail captif s'adaptant plus facilement à des scénarios personnalisés complexes, plusieurs fonctionnalités pour les opérateurs cellulaires (WRIX, inline layer 3, page de statut pour prolonger l'accès réseau, etc.), un nouvel agent pour la configuration des appareils Android, la prise en charge de nouveaux équipements d'Enterasys, Huawei et Juniper Networks, une meilleure intégration Eduroam et plusieurs améliorations au niveau de la performance.

PacketFence possède un grand nombre de fonctionnalités. Parmi celles-ci, on retrouve :

  • l'enregistrement des composantes réseau grâce à un puissant portail captif ;
  • le blocage automatique, si souhaité, des appareils indésirables tels les Apple iPod, Sony PlayStation, bornes sans fil et plus encore ;
  • l'enrayement de la propagation de vers et virus informatiques ;
  • le freinage des attaques sur vos serveurs ou diverses composantes réseaux ;
  • la vérification de la conformité des postes présents sur le réseau (logiciels installés, configurations particulières, etc.) ;
  • la gestion simple et efficace des invités se connectant sur votre réseau ;
  • des sources d'authentification variées, incluant Facebook et Google.

PacketFence est une solution non-intrusive qui fonctionne avec une multitude d'équipements réseaux (filaire ou sans fil) tels ceux de 3Com, AeroHIVE, Allied Telesis, Aruba, BelAir/Ericsson, Brocade, Cisco, Dell/Force10, Enterasys, ExtremeNetworks, Extricom, Hewlett-Packard/H3C, Huawei, Intel, Juniper Networks/Trapeze, LG-Ericsson US, Meru Networks, Motorola, Netgear, Nortel/Avaya, Ruckus, Xirrus et plus encore.

Télécharger ce contenu au format Epub

Lire les commentaires

Warsow 1.5

Mercredi 7 Mai

Warsow est un jeu de tir en vue subjective (FPS) multijoueurs dans la veine d'un Quake 3 ou d'un Unreal Tournament. En proposant des graphismes cartoon et un style de jeu misant tout sur la vitesse et le déplacement, Warsow s'oppose aux ténors actuels s'inspirant des guerres modernes avec des styles de jeu réalistes et plutôt posés.

Licence

Warsow bien que multi-OS et gratuit divisera encore le libriste en proposant un jeu sous double licence.

  • GPL pour le code source. Le moteur jeu OpenGL de Warsow est basé sur QFusion lui même étant une version améliorée du moteur Quake II engine.
  • Warsow Content Licence, une licence propriétaire pour tout ce qui touche aux côtés artistiques : modèles, musiques, graphismes… ainsi qu'au contenu du site en lui même.
eSport

Warsow dont l'acronyme est Warsow is the Art of Respect and Sportsmanship Over the Web est soutenu par une base de joueurs satisfaisante : environ 40/50 à toute heure de la journée, particulièrement intéressés par l'eSport.

  • Le nombre de joueurs présents sur les serveurs est constamment visible dans l'entête du site officiel.
  • En s'enregistrant sur le site officiel, les joueurs peuvent profiter d'un système de statistiques très complet (cf. mon profil de débutant).
  • Un système pour créer des pick-up est disponible via irc. Les pick-up sont des matchs suivant les mêmes règles que lors de compétition, mais dont les équipes sont composées aléatoirement par des membres de la communauté ne faisant pas forcément partie d'équipes plus formelles engagées dans les tournois. Elle représente un moyen efficace d'introduire les nouveaux joueurs au monde de la compétition, mais elle permet également de faire vivre la scène compétitive, malgré une base de joueurs restreinte, en mixant les équipes et en proposant des rendez-vous compétitifs fréquents.
  • Le HUD pour Head-up display est particulièrement modifiable. Le HUD est la manière de gérer l'ensemble des informations importantes sur notre écran : points de vie et d'armure, nombre de balles restantes, nombre de coéquipiers en vie, temps…
  • Les graphismes sont également modifiables pour répondre aux goûts de tous. Les joueurs particulièrement attachés (tatillons) à l'eSport préféreront des surfaces lisses de toutes couleurs et des modèles de joueurs particulièrement contrastés. Les autres préfèrent généralement un jeu agréable à regarder avec des couleurs en adéquation avec l'univers cyberpunk.

Graphismes typiques pour un joueur ne souhaitant pas s’encombrer du moindre détail pouvant détourner son attention et graphismes de bases.

Nouveauté 1.5

Cette nouvelle version ne dépaysera pas les habitués, mais apporte un petit lot de nouveautés.

On notera, en plus des très nombreux correctifs, améliorations ergonomiques, détails graphiques et optimisation du code, quelques changements particulièrement remarquables.

  • Le modèle de joueur Jason Padpork a été retravaillé.
  • Malgré le deuil de la communauté suite au décès de Jihnsius alors artiste son, la version 1.5 est livrée avec pas moins de 5 nouvelles pistes audio.
  • Un énorme travail de traduction pour l'interface a été entamé avec 10 langues disponibles : anglais, russe, japonais, français, polonais, chinois, hollandais, espagnol, hongrois, allemand, italien et finnois.

Nouveau modèle pour Jason Padpork

Installation

Le jeu se télécharge de manière très pratique, mais étonnante : avec une archive unique pour tous les systèmes. Ne vous étonnez pas de trouver des .exe et autre dll dans votre archive. Ces fichiers ne sont bien évidemment pas nécessaires au fonctionnement du jeu et peuvent être supprimés. Pour lancer le jeu, rien de plus simple :

# On désarchive proprement notre tar.gz et on va à la racine du répertoire. cd /mon/dossier/warsow # On exécute tout simplement ./warsow

De très nombreuses cartes et modes de jeux sont disponibles (bomb, tdm, run…). L'un des plus joués est CA pour Clan Arena ; un Team Death Match par vague qui couronne d'un point l'équipe (Alpha vertes ou Bêta rouges) ayant éliminé tous les adversaires. La partie est limitée à 5 minutes, chaque mort est définitive, il y a 5 secondes d'échauffement en début de chaque partie permettant de croiser les ennemis avant même de pouvoir infliger des dégâts, la carte est vierge de tout point de santé, armure, l'équipement de base étant déjà disponible en quantité suffisante. C'est un style de jeu rapide récompensant plus la rapidité d'équipe et les exploits personnels que le contrôle des territoires de la carte.

Jouabilité

Warsow est un jeu basé sur le tir et le déplacement. L’immobilité signifie la mort assurée.

  • Le clic gauche permet de tirer.
  • Le clic droit est une touche spéciale qui permet de prendre de la vitesse à la réception des sauts, de changer de direction rapidement, de rebondir sur les murs et de glisser sur les barres.
  • La barre d'espace permet de sauter.
Quelques captures d'écran

Télécharger ce contenu au format Epub

Lire les commentaires

Distro Recipes 2014 : inscrivez-vous pour la deuxième édition

Mercredi 7 Mai

La première édition de Distro Recipes a eu lieu l'an dernier et a rassemblé une soixantaine de personnes. Vous pouvez consulter les supports à disposition en ligne.

La seconde édition aura lieu les 11 et 12 juin 2014, au Carrefour Numérique de La Villette à Paris. Pour cette nouvelle édition, une dizaine de conférences et des lightning talks (conférences éclair). Cette année encore seront représentées OpenSUSE, Fedora, Debian, Mageia, Arch Linux. Deux jours d'interventions sur des sujets variés :

  • infrastructure de build ;
  • tests automatisés et QA ;
  • nouvelles des distributions ;
  • retours d'expérience.

Ces 2 jours mettront l'accent sur les échanges entre les intervenants et les participants, qu'ils soient utilisateurs, contributeurs ou développeurs. La convivialité qui fut de mise lors de la première édition restera une priorité lors de ces 2 jours. Les discussions se prolongeront lors du déjeuner et du dîner organisé le 11 juin au soir.

Vous pouvez également participer à cet événement et proposer un lightning talk. Parlez-nous d'un projet qui vous tient à coeur, une expérience en lien avec les distributions Linux.

Les inscriptions sont ouvertes, pensez-y, le nombre de places est limité.

Télécharger ce contenu au format Epub

Lire les commentaires

Retour sur la journée internationale contre les DRM du 6 mai 2014

Mercredi 7 Mai

Petite revue de presse non exhaustive de cette journée internationale contre les DRM :

(source)

    (source traduite par l'April)

    Les différents articles ActuaLitté du DRMDay

    Bonus

    Quelques liens annexes liés au droit d'auteur et aux données personnelles :

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Thelia 2, le logiciel de vente en ligne est disponible

    Mardi 6 Mai

    Thelia 2 est un logiciel libre (LGPL) de vente en ligne ou e-commerce. Moins connu que Magento ou Prestashop, il a le bon goût d'avoir beaucoup de modules libres et faciles à ré-adapter. Il utilise la même syntaxe de boucle que Spip et s'intègre très bien à ce dernier.

    Depuis la sortie de Thelia 1 en 2005, les techniques de programmation ont évolué et les concepteurs ont préféré recréer Thelia 2 à partir d'une feuille blanche mais en mettant à profit leurs 8 ans d'expérience.

    C'est ainsi que Thelia 2 a été développé autour de standards que les développeurs apprécieront. Citons en particulier Symfony et les normes PSR. Le souci de faire un logiciel très propre dans le meilleur esprit du logiciel libre est évident. Les sources et la documentation technique sont en anglais de façon à avoir un développement international ouvert. Les demandes d'améliorations et les bugs sont gérés sur github.

    De nombreux modules de Thelia 1.5 sont intégrés dans la version de base de Thelia 2 mais certains sont encore en cours de ré-écriture. Il n'y a pas encore d'urgence à migrer mais un module de migration est d'ores et déjà disponible.

    Thelia est développé principalement par OpenStudio qui peut assurer la formation, le support des utilisateurs et le développement de nouveaux modules . Voyez l'article précédent pour plus de détails.

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Sortie du langage Pharo et de son environnement de développement en version 3.0

    Mardi 6 Mai

    Le projet Pharo est fier d’annoncer la sortie de Pharo 3.0 — un langage dynamique et son environnement de développement immersif. Pharo est un projet libre distribué sous licence MIT.

    Pharo consiste en un langage objet inspiré de Smalltalk extrêmement bien conçu et un environnement de développement intégré innovant. L'environnement de développement permet, entre autres, l'implémentation du programme, ainsi que l'inspection et la modification des objets durant l'exécution.

    Après 1 an de développement, Pharo 3.0 introduit de nombreuses nouveautés, détaillées dans l'annonce officielle et dans la liste des changements, dont :

    • Le nouveau compilateur modulaire Opal est maintenant le compilateur par défaut ;
    • Le canvas de dessin vectoriel Athens est intégré et il gère l'affichage avec Cairo sur toutes les plateformes ;
    • Beaucoup d'outils ont été réécrits avec Spec, un nouveau framework de conception d'interfaces graphiques ;
    • 2 nouveaux outils pour les développeurs ont été intégrés (Versionner et Kommiter) ;
    • Le nouveau mécanisme de paquetage (RPackage) a été amélioré et est maintenant complètement intégré au système ;
    • Le debugger a été complètement réécrit pour séparer la logique de l'interface ; l'inspecteur d'objet propose maintenant de multiples vues pour chaque objet et le navigateur de code gère les labels, facilite la recherche et intègre de nombreuses autres améliorations ;
    • La couche graphique (Morphic) a été largement nettoyée et le thème visuel a été rénové.

    Voilà les points les plus importants, mais les détails sont eux aussi importants. 2364 bugs ont été corrigés pour Pharo 3 (à comparer aux 1727 bugs corrigés pour Pharo 2).

    En parallèle, un nouveau site web a été développé grâce aux technologies Amber (un équivalent allégé de Pharo dans le navigateur web) et Marina (un prototype de CMS qui tourne sous Pharo côté serveur et sous Amber côté client).

    Télécharger ce contenu au format Epub

    Lire les commentaires

    OpenJDK JEP 180: HashMap, collisions & attaques par la complexité

    Mardi 6 Mai

    Cette dépêche parle de la JEP 180 d'OpenJDK 8 qui propose une solution intéressante aux problèmes d'attaques sur la complexité que rencontrent les tables de hachage.

    On a déjà parlé de ce sujet ici même à plusieurs reprises. Je vais cependant rapidement représenter le problème et l'évolution des discussions. Le lecteur averti sur le sujet ira directement au dernier paragraphe pour voir la proposition de la JEP 180.

    NdM : merci à ckyl pour son journal.

    Sommaire Présentation des tables de hachage

    Une table de hachage est une implémentation du type abstrait tableau associatif. Un tableau associatif permet d'associer une clé à une ou plusieurs valeurs, on le nomme aussi parfois dictionnaire. Il fait partie des types abstraits les plus utilisés avec les listes.

    Une table de hachage est une implémentation particulière d'un tableau associatif. Elle est aussi la plus courante. Basiquement il s'agit d'un tableau dont les cases contiennent un pointeur vers nil, un élément ou une liste d'élément. On détermine la case à utiliser en appliquant une fonction de hachage à la clé. Idéalement, chaque case ne pointera que vers un unique élément. Dans ce cas les opérations d'insertion, de consultation et de suppression se font en temps constant, noté , c'est à dire qui ne dépend pas du nombre d'éléments présents dans la table de hachage. Cependant si la fonction de hachage retourne deux fois la même valeur pour deux clés différentes, ce que l'on nomme collision, alors les deux valeurs sont généralement stockées comme une liste. C'est à dire que maintenant il va falloir parcourir toute cette liste. Dans le pire cas, la fonction de hachage retourne toujours la même valeur, toutes les valeurs vont donc être stockées dans la même case et l'on va devoir parcourir la liste pour chaque opération. La complexité est alors linéaire par rapport au nombre d'éléments dans la structure, noté , ce qui est très peu performant. Une table de hachage a donc une complexité moyenne d' mais un pire cas en . Il est donc crucial d'avoir une fonction de hachage performante. Les personnes n'étant pas à l'aise avec l'implémentation d'une table de hachage ou les concepts précédant auront tout intérêt à consulter la page Wikipédia qui est assez complète.

    Cet article s'accompagne d'un benchmark écrit avec JMH qui va nous permettre d'observer comment se comporte la classe HashMap de Java dans différentes circonstances. Le code de ce benchmark est extrêmement simple:

    @GenerateMicroBenchmark public int put() { HashMap<String, Object> map = new HashMap<String, Object>(); for (String s: strings) { map.put(s, s); } return map.size(); }

    Nous insérons une collection de chaîne de caractère dans une HashMap et nous mesurons le temps moyen de cette opération. Mesurer l'insertion est une métrique correcte pour ce que nous souhaitons mesurer car lors d'une insertion, dans le cas où la clé existe déjà il faut remplacer la valeur existante. Il faut donc rechercher parmi toutes les clés déjà existantes dans cette case. Les comportements en consultation et en suppressions seront similaires à celui que nous observons. Dans tous les cas, en cas de collision, il faudra traverser toutes les valeurs de cette case. Exemple du code de la méthode put():

    public V put(K key, V value) { if (key == null) return putForNullKey(value); int hash = hash(key.hashCode()); int i = indexFor(hash, table.length); for (Entry<K,V> e = table[i]; e != null; e = e.next) { Object k; if (e.hash == hash && ((k = e.key) == key || key.equals(k))) { V oldValue = e.value; e.value = value; e.recordAccess(this); return oldValue; } } modCount++; addEntry(hash, key, value, i); return null; }

    On peut clairement y voir les étapes suivantes:

    • On calcule le hash de la clé, qui va déterminer la case i
    • On itère sur toutes les clés présentes dans la case i pour regarder si une correspond à key
      • Si oui, alors on remplace la valeur existante par value
      • Sinon, on ajoute un nouvel élément pour cette clé à la fin de la liste

    Comme on le voit avec la ligne suivante int hash = hash(key.hashCode());, en Java la case est calculée à partir de la valeur retournée par hashCode(). On applique en plus la fonction hash() afin d'améliorer un peu la distribution des clés. En effet, i est calculé modulo la taille de la table qui est une puissance de deux, et il est facile d'avoir des effets néfastes:

    /** * Applies a supplemental hash function to a given hashCode, which * defends against poor quality hash functions. This is critical * because HashMap uses power-of-two length hash tables, that * otherwise encounter collisions for hashCodes that do not differ * in lower bits. Note: Null keys always map to hash 0, thus index 0. */ static int hash(int h) { // This function ensures that hashCodes that differ only by // constant multiples at each bit position have a bounded // number of collisions (approximately 8 at default load factor). h ^= (h >>> 20) ^ (h >>> 12); return h ^ (h >>> 7) ^ (h >>> 4); }

    Enfin le cas qui va nous intéresser particulièrement ici est celui des chaines de caractères comme clé car c'est une utilisation extrêmement courante et exposée aux attaques. Souvent les données fournies par l'utilisateur sont des chaînes de caractères plutôt que des objets complexes. Par exemple les en-tête HTTP sont souvent stockés dans un tableau associatif.

    Regardons donc comment est implémenté le hashCode de la classe String:

    /** * Returns a hash code for this string. The hash code for a * <code>String</code> object is computed as * <blockquote><pre> * s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1] * </pre></blockquote> * using <code>int</code> arithmetic, where <code>s[i]</code> is the * <i>i</i>th character of the string, <code>n</code> is the length of * the string, and <code>^</code> indicates exponentiation. * (The hash value of the empty string is zero.) * * @return a hash code value for this object. */ public int hashCode() { int h = hash; int len = count; if (h == 0 && len > 0) { int off = offset; char val[] = value; for (int i = 0; i < len; i++) { h = 31*h + val[off++]; } hash = h; } return h; }

    Cela correspond à une fonction de hachage non cryptographique très courante pour les chaînes de caractères. C'est une variante du Bernstein hash, aussi appelé djb2. Elle a ceci d'intéressant qu'elle est utilisée par beaucoup de plateformes et qu'expliquer pourquoi elle marche et comment et pourquoi ont été choisies les valeurs est assez difficile. Les gens intéressés pourront découvrir d'autres fonctions ainsi que passer beaucoup de temps à chercher les réponses à la question précédente.

    Dans tous les cas nous appellerons cette variante de dbj2 sous le doux nom de DJBX31A.

    Maintenant exécutons notre benchmark en utilisant Java 6u45 avec des chaines aléatoires de taille constante, 15 caractères, pour des collections allant de 10 à 30.000 éléments. Le résultat est le suivant:

    Dans ce cas nous avons le comportement normal attendu. Il y a peu de collisions. En moyenne le temps d'insertion est constant et ne dépend pas de la taille de la collection, . Nous voyons donc que la courbe est linéaire puisque nous répétons fois une opération prenant un temps donné. Nous voyons aussi que nous arrivons à insérer environ 20 000 éléments par milliseconde.

    Attaques par la complexité

    Si vous avez bien suivi la première partie, vous savez que la performance d'une table de hachage dépend du nombre de collisions et donc de la qualité de sa fonction de hachage. Par nature une table de hachage ne permet pas de garantir que les opérations seront en , il s'agit seulement du cas moyen quand tout se passe bien. La performance au pire cas est .

    Ce fait est connu de tout étudiant ayant suivi une introduction à l'algorithmique. Seulement il y a quelques années certains ont eu l'idée d'utiliser ce pire cas pour faire des dénis de service. C'est une attaque par la complexité. L'idée est simple, beaucoup d'applications stockent en mémoire des chaînes de caractères fournies par un utilisateur dans une table de hachage. S'il arrive à fournir des chaînes qui vont systématiquement créer des collisions, alors il va pouvoir ralentir très fortement le système.

    L'idée n'est pas nouvelle, elle a été parfaitement documentée en 2003 par Scott A. Crosby et Dan S. Wallach lors de l'Usenix-Sec. Ils avaient alors étudié Perl, qui avait réagi et fourni un correctif. Tout le monde a alors oublié cette histoire pendant quelques années.

    En 2011, Alexander Klink et Julian Wälde se souviennent de cette histoire et partent alors explorer ce qu'il est possible de faire avec presque 10 ans après. Les slides du 28C3 décrivent très bien ce qu'ils trouvent. En gros presque toutes les plateformes majeures sont vulnérables de PHP à Java en passant par Python puisque tout le monde ou presque utilise une variante de djb2, pour lequel il est très facile de générer des collisions. Le résultat c'est qu'on peut faire un déni de service sur à peu près n'importe quoi avec très peu de données. Avec 2 MB de données ils arrivent à occuper un processeur pendant plus d'une demi-heure.

    Le benchmark suivant compare la courbe précédente avec une où toutes les clés se retrouvent dans la même case car on génère spécialement les clés pour que DJBX31A retourne toujours la même valeur bien que les chaînes soient différentes.

    Comme on peut le voir l'effet est plutôt dramatique. Chaque insertion dépend donc maintenant du nombre d'éléments dans la table de hachage. Si vous vous rappelez du code de la méthode put(), nous avons à parcourir tous les éléments à chaque fois. Puisque nous allons insérer un nouvel élément, il faut vérifier tous les autres. La courbe devient donc quadratique. Pour 20 000 éléments on peut voir que l'on est déjà 1000 fois plus lent. Vous pouvez facilement extrapoler pour 50 000 ou 100 000.

    Java 7u6 & « alternative string-hashing »

    Comme la plupart des plateformes impactées par cette découverte, Java cherche une solution. Et beaucoup vont choisir une solution similaire. L'idée est qu'il faut empêcher un utilisateur de pouvoir générer des collisions. Une solution est d'utiliser des fonctions de hachage cryptographiques qui sont conçues pour cela. En pratique ce n'est pas possible car elles sont beaucoup trop lentes (grossièrement il y a au minimum un ordre de grandeur d'écart). Le consensus est alors de migrer vers une autre fonction de hachage: Murmur 2 ou 3. Murmur est une bonne fonction de hachage non cryptographique, elle est rapide et fournit de bons résultats. En plus on peut l'initialiser avec une graine qui va conditionner la valeur de sortie. L'idée est donc de générer la graine à l'exécution. Il devient alors compliqué pour l'utilisateur de générer des collisions car il a besoin de la graine et qu'il n'y a pas accès.

    Python utilise cette solution et décide de changer sa fonction de hachage pour Murmur.

    Java veut faire de même mais a un problème supplémentaire. La Javadoc de la méthode hashCode de String documente l'implémentation sous-jacente:

    /** * Returns a hash code for this string. The hash code for a * <code>String</code> object is computed as * <blockquote><pre> * s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1] * </pre></blockquote> * using <code>int</code> arithmetic, where <code>s[i]</code> is the * <i>i</i>th character of the string, <code>n</code> is the length of * the string, and <code>^</code> indicates exponentiation. * (The hash value of the empty string is zero.) * * @return a hash code value for this object. */

    DJBX31A fait donc partie du contrat de la classe, et on ne peut pas le changer sans risque de casser la compatibilité et le comportement des applications. C'est une règle stricte du côté de Java.

    Pour cette raison on imagine donc ce qui est pour moi l'un des patchs les plus dégueulasses de l'histoire du JDK qui a été livré en Java 7u6. En gros on ne touche à rien de ce qui existe. On rajoute une nouvelle méthode hash32 à la classe String qui repose sur Murmur.

    int hash32() { int h = hash32; if (0 == h) { // harmless data race on hash32 here. h = sun.misc.Hashing.murmur3_32(HASHING_SEED, value, 0, value.length); // ensure result is not zero to avoid recalcing h = (0 != h) ? h : 1; hash32 = h; } return h; }

    Maintenant on patche les collections utilisant des fonctions de hachage pour faire la chose suivante : on regarde le type de l'élément, si c'est String alors on invoque hash32 par une introspection dédiée car la méthode n'est pas publique, sinon on invoque hashCode. Seulement les String sont immutables, et la valeur de hashCode était cachée pour éviter de la recalculer à chaque fois. On doit donc faire de même avec hash32 qui impose donc 4 octets supplémentaire à chaque instance de String. Pour finir on initialise HASHING_SEED dynamiquement à l'initialisation pour empêcher les collisions.

    C'est cool on n'a pas touché à hashCode ! Seulement voilà le comportement des applications peut toujours changer même en remplaçant la fonction de hachage uniquement dans les collections. Alors on rajoute un flag pour décider si on veut oui ou non utiliser le alternative string-hash dans les collections.

    Voir le courriel sur la liste de discussion d'OpenJDK ainsi que le patch.

    Voilà ça pique les yeux mais ça fait le job ! Refaisons tourner le même benchmark avec Java 7u55:

    Ah oui j'ai dit qu'il y avait une option pour l'alternative string-hashing mais j'ai pas dit qu'elle était activée par défaut… Recommençons avec -Djdk.map.althashing.threshold=1

    C'est mieux non ? Bon OK par défaut on est toujours vulnérable trois ans après…

    Attaques par la complexité (bis)

    Seulement voilà, entre temps quelques-uns ont commencé à creuser le problème. Ils ont attaqué Murmur3 avec graine qui n'a pas tenu très longtemps. Ca a d'ailleurs été présenté au 29c3. Dans les speakers on notera DJB, oui c'est le même.

    Rebelote, tous ceux qui sont passés à Murmur sont impactés ainsi que quelques copains dont les fonctions ont aussi été cassées. C'est un peu moins trivial de générer des collisions avec Murmur mais le travail difficile a été fait pour nous. On n'a qu'à écrire le code…

    Essayons de refaire tourner notre benchmark en générant des collisions contre Murmur:

    Cette fois nous comparons le comportement usuel avec:

    • Des collisions contre DJBX31A sans l'alternative string-hashing
    • Des collisions contre Murmur3 avec l'alternative string-hashing

    (Je n'ai pas investigué les deux points à 15k et 25k qui sont très étranges. Le générateur passe les tests unitaires et les résultats eux sont stables…)

    C'est grosso modo la même chose. On a donc fait un patch moche qui ne sert plus à rien puisque dans les deux cas on est vulnérable…

    JEP 180: Une solution intéressante

    Maintenant qu'est-ce qu'on fait ?

    En même temps qu'ils ont cassé Murmur avec graine, DJB et ses potes ont proposé une nouvelle fonction de hachage: SipHash. Elle est vendue comme étant aussi rapide que les précédentes mais résistante aux attaques par collisions.

    La plupart des plateformes ont migré vers SipHash, Python par exemple. Et comme on s'est déjà fait avoir une fois on en profite pour faire la PEP 456 qui permet d'avoir des fonctions de hash interchangeable pour les chaîne de caractères et tableaux d'octets. On bascule à SipHash mais comme on sait que ça risque de recommencer, on prévoit le coup…

    Du côté de Java on a toujours le même problème avec hashCode, rechanger hash32 fait prendre quelques risques aussi et le patch initial étant "crado" on aimerait bien s'en débarrasser. On choisit donc une approche radicalement différente. Plutôt que de chercher une fonction de hachage parfaite, on rebascule sur DJBX31A. On s'applique plutôt à résoudre le problème du au pire cas. Le vient du fait que les collisions sont gérées avec une liste chaînée. Si on utilise un arbre balancé plutôt qu'une liste on passe en ce qui réduit drastiquement le problème.

    C'est ce que propose la JEP 180 et qui a été implémenté dans OpenJDK 8.

    Refaisons tourner notre benchmark sur OpenJDK 8:

    Cette fois ci nous comparons le comportement normal d'OpenJDK 8 et Java 7u55 ainsi que le comportement d'OpenJDK8 avec des collisions.

    Tout d'abord nous constatons que les performances dans le cas normal n'ont pas régressé. Ensuite nous voyons que contrairement à une solution qui vise a prévenir entièrement les collisions, l'utilisation d'arbre balancé a tout de même un coût. Les opérations passent de à . Cependant si on regarde les chiffres ce n'est pas dramatique. À 20 000 éléments nous sommes maintenant à ~10ms plutôt que ~1ms loin de la seconde initiale.

    Nous avons regardé le point de vue performance, cependant utiliser des arbres balancés a aussi un impact non négligeable sur la consommation mémoire. En effet au lieu d'avoir à stocker un bête pointeur sur l'élément suivant, on se retrouve avec quatre pointeurs et un booléen. Ce qui pourrait faire exploser la consommation mémoire. Cependant par défaut on utilise toujours une liste chaînée. Quand le nombre de collisions augmente dans une case et dépasse un seuil on convertit tout ou une partie de la liste en arbre balancé pour optimiser le ratio consommation mémoire/performance. Cette technique est appliquée à chaque feuille de l'arbre. On démarre avec une liste, puis on convertit la feuille en arbre quand elle devient trop grande. Quand on supprime des éléments on peut rebasculer vers une liste chaînée. Les seuils de conversion étant respectivement à 8 et 6 éléments.

    Si l'on observe la consommation mémoire avec Jol on peut voir que ça marche très bien:

    Ici on a fait attention à ce que les chaînes aient toujours la même taille dans les deux cas.

    En pratique dans une utilisation courante avec une fonction de hachage correcte, les collisions seront rares et les arbres balancés ne seront jamais utilisés. Par contre quand ils rentrent en action cela permet d'éviter les DOS ou simplement d'avoir de bonnes performances quand la fonction hashCode de l'utilisateur est biaisée.

    J'invite le lecteur intéressé à aller regarder le code. Le commentaire initial explique extrêmement clairement comment ça fonctionne et c'est plutôt rigolo à lire.

    Conclusion

    L'approche d'OpenJDK 8 est intéressante et différente des autres plateformes puisqu'elle ne cherche pas à résoudre le problème des collisions mais à améliorer le pire cas. Changer de fonction de hachage pour les String étant compliqué on peut comprendre ce choix. Ils ont fait le pari que les performances offertes par les arbres balancés suffiront à se protéger et à offrir une bonne robustesse aux mauvaises fonctions de hachage. En pratique, au pire cas on observe un ralentissement constant de ~10x quelque soit la taille de la collection.

    De l'autre côté beaucoup de plateformes ont changé de fonction de hachage pour éviter le pire cas mais n'ont pas chercher à l'améliorer et sont restés aux listes chainées. Ils se protègent donc des dénis de service selon les connaissances actuelles mais ne cherchent pas à se protéger pour le futur ni à offrir une réponse performante aux fonctions de hachage qui pourraient être légèrement biaisés pour certains autres type de données car implémentées par l'utilisateur.

    Dans l'idéal les deux techniques devraient être appliquées mais je ne connais pas de plateforme qui le fasse. Et vous les outils que vous utilisez ils ont fait quoi ?

    Voilà c'est un problème pas nouveau mais on en attendra certainement à nouveau parler. Dès qu'on lit une valeur du monde extérieur, celui-ci va s'arranger pour trouver un moyen de faire des choses "sympas". Les attaques algorithmiques permettent de varier un peu les plaisirs et forcent à s'interroger longuement à chaque fois qu'on stock une valeur que l'on ne contrôle pas.

    Note: Tout le matériel créé pour écrire l'article est en ligne.

    NdM : Pour ceux qui se demandent comment sont fait les graphiques, ils s'agit du mode xkcd de matplotlib comme expliqué par l'auteur dans les commentaires du journal à l'origine de la dépêche.

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Mons, le 15 mai : echo “Java” | sed ‘s/Jav/Scal/’

    Lundi 5 Mai

    Ce jeudi 15 mai 2014 à 19h se déroulera la 29ème séance montoise des Jeudis du Libre de Belgique :

    • le sujet de cette séance : echo "Java" | sed 's/Jav/Scal/' ;
    • thématique : programmation ;
    • public : développeurs, étudiants et académiques ;
    • l’animateur conférencier : Andy Petrella (WAJUG, NextLab).

    Dans cet exposé, nous allons rapidement et concrètement couvrir certaines particularités du langage de programmation Scala. Malgré la richesse qu’offre ce langage, nous verrons que l’on peut s’en tenir à ses fonctionnalités basiques tout en profitant de ses avantages sur le langage Java.

    N.B. : Scala est un langage compilé en Bytecode pour la JVM et donc un concurrent direct de Java sur son propre terrain… Scala est fortement typé, orienté objet et fonctionnel. Vous allez voir du code, un peu de slides, mais surtout du code !

    Lieu de cette séance : Université de Mons, Faculté Polytechnique, Site Houdain, Rue de Houdain, 9, auditoire 12 (cf. ce plan sur le site de l’UMONS, ou la carte OSM). Entrée par la porte principale, au fond de la cour d’honneur. Suivre le fléchage à partir de là.

    La participation sera gratuite et ne nécessitera que votre inscription nominative, de préférence préalable, ou à l’entrée de la séance. Cette séance sera suivie d’un verre de l’amitié, offert par NextLab (le tout sera terminé au plus tard à 22h).

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

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

    Télécharger ce contenu au format Epub

    Lire les commentaires

    TupperVim grenoblois le 14/05

    Lundi 5 Mai

    Après une longue hibernation, le TupperVim revient à Grenoble le mercredi 14 mai. Le TupperVim est une réunion pour amateurs de logiciels beaux, élégants et efficaces, Vi en première ligne, mais également d'autres outils dans le même esprit (bash, zsh, mutt, git, etc.).
    Comme le nom de l’événement ne l'indique pas forcément, les utilisateurs d'autres éditeurs de texte sont également les bienvenus.

    Le créateur des TupperVim sera même présent en guest star !

    Tout cela se passe à Cap Berriat (5 Rue Georges Jacquet, 38100 Grenoble) à partir de 20h.

    Entrée libre et gratuite mais pour mieux vous accueillir merci de vous inscrire sur le lien suivant : http://framadate.org/4hkyhyirnmnosmdd

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Publication de Pyramid 1.5

    Lundi 5 Mai

    Sept mois après la sortie de la version alpha, la version 1.5 est disponible en version stable. Pyramid est un framework Python (Python2 et Python3) pour le développement de sites web, développé avec le projet Pylons (qui regroupe justement des frameworks web), sous licence libre BSD.

    Sommaire Petite introduction

    La particularité de ce framework est d'être « sans opinion » : il ne fournit pas d'ORM ni de template par défaut et il n'est pas indispensable d'utiliser toutes les possibilités offertes. On ne « paye » que ce que l'on consomme. Cela lui permet de répondre aux petites applications se contentant d'un seul fichier. Il est également extrêmement flexible ce qui lui permet de développer les projets les plus complexes sans avoir à changer de framework en cours de route.

    Par exemple, on peut commencer un projet sans contrôle d'accès puis lui rajouter un système d'authentification simple et, ensuite, un système plus complet à base d'ACL ou d'autres systèmes extérieurs agencés pour Pyramid.

    Pratiquement toutes les fonctionnalités de Pyramid sont extensibles, que ce soit le système de routes (classique URL Dispatch ou sur un arbre de ressources Traversal), les sessions (sur cookie signé ou à l'aide d'un système externe, beaker, redis…), les templates (éventuellement plusieurs en fonction des vues), les vues (sous forme de fonction ou classes), les contrôles d'accès, etc.

    Un mécanisme de souscription permet d'insérer ses propres fonctionnalités à tous les niveaux. Du lancement de l'application au parcours de la requête (création de la requête, rendu, création de la réponse, etc.). Il est même possible d'ajouter ses propres évènements, d'y souscrire et de les lancer.

    Il est également possible de développer une application par morceaux à inclure, chacun défini avec un préfixe éventuel donné par la configuration principale config.include('package', route_prefix='/...') . Préfixe qui sera automatiquement utilisé par request.route_url('route_name')
    Par exemple, il sera possible de développer la partie admin d'un site à part puis de l'intégrer dans /admin par la suite.
    Cette partie incluse pourra également être redéfinie sur trois aspects. La redéfinition des vues pour en modifier le code, la redéfinition des routes pour diriger vers une autre vue et la redéfinition des 'assets' pour remplacer des données statiques et des templates.

    Tant et si bien que l'on peut utiliser Pyramid comme un jeu de mécano, pour construire son propre framework ou inversement passer d'un autre framework vers Pyramid. Sachant qu'il n'est absolument pas indispensable de connaître toutes ses possibilités pour se servir de Pyramid.

    La documentation couvre l'ensemble des fonctionnalités de manière exhaustive. En plus de cela, la raison de chaque choix technique est expliquée, ce qui en fait une documentation intéressante, à lire même pour ceux qui n'utilisent pas Pyramid. Dans le chapitre "Defending Pyramid's Design" une comparaison est faite avec les choix techniques des autres frameworks.

    Les nouveautés Aucun moteur de template par defaut

    Aucun moteur de template n'est maintenant installé par défaut. Les dépendances précédentes à Chameleon et Mako ne sont donc plus requises pour installer Pyramid. L'écosystème d'outils gagne alors deux nouveaux projets pour faire le lien avec chacun de ces moteurs: pyramid_chameleon et pyramid_mako, complétant le trio par pyramid_jinja2 pour Jinja2—qui leur préexiste depuis 2010.

    pdistreport est un script installé avec Pyramid qui fournit des informations sur la version de Python utilisée et les versions et emplacements des modules installés par pip ou easy_install.

    Un nouveau predicat : not_

    Un nouveau prédicat permet, comme son nom l'indique, d'inverser la directive qu'il contient. Il peut être utilisé pour l'ajout d'une vue : add_view, add_route, add_subscriber, view_config et subscriber7

    from pyramid.config import not_ @view_config(route_name='myroute', request_method=not_('POST')) def view(request): ...

    Ainsi, dans l'exemple ci-dessus, la vue view sera appelée sur toute requête HTTP autre que POST.

    Sessions Cookie de session signé

    SignedCookieSessionFactory remplace UnencryptedCookieSessionFactoryConfig (attention il y a incompatibilité sur les sessions en cours).

    Dépréciation de Beaker

    Beaker, le système de gestion de sessions et de cache, développé pour le framework Pylons, n'est plus recommandé pour gérer les sessions : on lui préférera Redis, via pyramid_redis_sessions. Pour gérer le cache, on pourra lui substituer dogpile.cache, développé par Mike Bayer (père de SQLAlchemy et Mako).

    pyramid_pluggable_session

    Pour remédier à l'obsolescence de Beaker, qui fait couler beaucoup d'encre sur la liste de discussion de Pyramid, un nouveau projet vient de naître : pyramid_pluggable_session, il permet d'ajouter facilement un système de persistance à l'aide d'un object IPlugSession comprenant deux méthodes loads(session, request) et dumps(session, request, session_data) . Un exemple de persistance en mémoire et sur fichier est déjà présent.

    Route externes

    Les routes peuvent maintenant référencer des routes externes. Ces routes sont implicitement statiques.
    Il est possible de ne pas spécifier le protocole (scheme) http ou https. Comme en Javascript, le protocole sera le même que celui de la requête.

    >>> config = Configurator() >>> config.add_route('youtube', '//youtube.com/watch/{video_id}') >>> request.route_url('youtube', video_id='oHg5SJYRHA0') "https://youtube.com/watch/oHg5SJYRHA0"

    Prise en charge de l'héritage dans la recherche des vues

    request.exception et request.exc_info ne sont plus effacés avant les finished_callback

    Ce bug a été corrigé, il permet maintenant de savoir lors d'un finished_callback si une exception a eu lieu ou pas.

    Exemple sur une transaction :

    def _connect(request): conn = request.registry.dbsession() def cleanup(request): if request.exception is not None: conn.rollback() else: conn.commit() conn.close() request.add_finished_callback(cleanup) return conn @subscriber(NewRequest) def new_request(event): request = event.request request.set_property(_connect, 'db', reify=True) Documentation

    La documentation du framework a toujours été à la fois un de ses atouts et un de ses défauts : extrêmement détaillée, elle a ravi les utilisateurs convaincus de l'outil, tout en faisant probablement fuir de nombreux débutants. L'équipe de développeurs en était bien consciente et avait lancé il y a plusieurs mois un appel aux dons pour la restructurer et la rendre plus accessible, mais le projet n'avait finalement pas démarré.

    L'idée a cependant été reprise récemment par Paul Everitt, qui a joint à la documentation existante deux nouveaux points d'entrée : un « Quick Tour » (visite rapide) du framework, et un « Quick Tutorial » (bref tutoriel).

    Nouveau thème pour les projets créés par scaffold

    Une autre des caractéristiques de Pyramid est d'offrir un ensemble de "template" de projets pour en démarrer un, utilisé par la commande pcreate (doc). Pour distinguer ces templates de ceux utilisés pour générer les réponses HTTP, la documentation les nomme "scaffolds". Pour cette version, les scaffolds fournissent, à la création d'un nouveau projet, un thème graphique entièrement retravaillé.

    En vrac
    • À l'occasion de cette sortie, l'artiste Felix Laflamme, graphiste attitré du projet, a créé un nouveau T-shirt qui fut très visible au Pycon. Vous pouvez retrouver les précédentes créations sur la page de la boutique.
    • La bibliothèque WSGI bas niveau de gestion des requêtes et réponses HTTP sur laquelle s'appuie le framework, WebOb, est maintenant requise à partir de sa version 1.3.1 (contre 1.2b3 pour Pyramid 1.4).

    Les changements sont trop nombreux pour tous les citer ici. Vous pouvez consulter les liens pour plus d'informations

    Télécharger ce contenu au format Epub

    Lire les commentaires

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

    Lundi 5 Mai

    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

    [Contrepoints] CSA, neutralité et gouvernance du Net

    Par h16, le dimanche 4 mai 2014. Extrait:

    Dans cette interview (que je fournis à la fin de cet article), Bayart qui se décrit lui-même comme un militant pour les libertés fondamentales dans la société de l’information, par la neutralité du net et le logiciel libre, est interrogé sur quelques domaines numériques connexes, et en profite pour passer en revue différents aspects de l’évolution de la société numérique, dans le monde en général et en France plus particulièrement.

    Lien vers l'article original: http://www.contrepoints.org/2014/05/04/164997-csa-neutralite-et-gouvernance-du-net

    Et aussi:

    [Libération.fr] Contre les discriminations, ne tirez pas sur Internet

    Par Rokhaya Diallo et Félix Tréguer, le samedi 3 mai 2014. Extrait:

    Dans plusieurs textes en cours de discussion au Parlement, et notamment le projet de loi sur l’égalité femmes-hommes, le gouvernement compte œuvrer au renforcement de la répression sur Internet.

    Lien vers l'article original: http://www.liberation.fr/societe/2014/04/27/contre-les-discriminations-ne-tirez-pas-sur-internet_1005778

    [Numerama] FreeBSD a sa faille Heartbleed. Et beaucoup de systèmes utilisent FreeBSD

    Par Guillaume Champeau, le jeudi 1 mai 2014. Extrait:

    FreeBSD a découvert qu'une faille dans sa gestion de flux TCP permettait, de façon "extrêmement difficile", d'obtenir à distance une copie d'informations stockées en mémoire dans le noyau. Mac OS X fait partie des systèmes qui utilisent le code réseau de FreeBSD.

    Lien vers l'article original: http://www.numerama.com/magazine/29253-freebsd-a-sa-faille-heartbleed-et-beaucoup-de-systemes-utilisent-freebsd.html

    Et aussi:

    [We Demain] Wikispeed, la première voiture open-source

    Par Benjamin Tincq, le mercredi 30 avril 2014. Extrait:

    Une équipe de bénévoles, un budget des plus modestes et, en à peine trois mois, une voiture à haute efficience énergétique. C'est le phénomène Wikispeed crée par l'Américain Joe Justice.

    Lien vers l'article original: http://www.wedemain.fr/Wikispeed-la-premiere-voiture-open-source_a509.html

    Et aussi:

    [clubic.com] Tails, le système qui voulait vous rendre vraiment anonyme

    Par Alexandre Laurent, le mercredi 30 avril 2014. Extrait:

    Basé sur Debian, le système d'exploitation Tails réunit tous les outils nécessaires à ceux qui souhaitent pouvoir surfer de façon vraiment anonyme sur Internet. C'est lui qu'a utilisé Edward Snowden pour communiquer au reste du monde ses révélations relatives à la surveillance généralisée mise en place par la NSA.

    Lien vers l'article original: http://www.clubic.com/antivirus-securite-informatique/virus-hacker-piratage/anonyme-internet/actualite-699478-tails-systeme-voulait-surfer-facon-anonyme.html

    [clubic.com] Smartphone: Bruxelles veut en finir avec les disputes de brevets

    Par Guillaume Belfiore, le mardi 29 avril 2014. Extrait:

    Face aux nombreuses actions en justice menées par les plus gros acteurs sur le secteur de la téléphonie, la Commission Européenne a décidé de limiter l'ampleur des prochains dépôts de plaintes.

    Lien vers l'article original: http://www.clubic.com/smartphone/actualite-699346-smartphone-bruxelles-finir-disputes-brevets.html

    [LeDevoir.com] Les ministères échouent à un test de FACIL

    Par Fabien Deglise, le mardi 29 avril 2014. Extrait:

    La preuve par l’expérimentation. Au terme d’une demande massive d’accès à l’information détenue par une vingtaine de ministères, l’Association pour l’appropriation de l’informatique libre (FACIL) est catégorique: «l’État québécois» est loin d’être «ouvert» et, du coup, «il reste encore beaucoup de verrous à faire sauter pour libérer l’information publique», résume le groupe qui vient toute juste de diffuser, de manière ouverte, les fruits de son enquête.

    Lien vers l'article original: http://www.ledevoir.com/politique/quebec/406801/acc

    [Numerama] Open Data: c'est officiel, il faut dire "Données Ouvertes"

    Par Guillaume Champeau, le samedi 3 mai 2014. Extrait:

    La Commission générale de terminologie et de néologie impose désormais aux administrations de ne plus utiliser le terme "Open Data", mais "Données Ouvertes". Elle en profite pour en donner une définition.

    Lien vers l'article original: http://www.numerama.com/magazine/29270-open-data-c-est-officiel-il-faut-dire-donnees-ouvertes.html

    Télécharger ce contenu au format Epub

    Lire les commentaires

    SliTaz GNU/Linux 5.0 RC1

    Lundi 5 Mai

    L'équipe SliTaz est heureuse d'annoncer la publication de la distribution SliTaz GNU/Linux 5.0 RC1. Cette version est très mature, mais nous poursuivons nos efforts afin de sortir au plus tôt la version 5.0 définitive. Pour rappel, SliTaz est une distribution Linux dont le système de fichiers est d'une taille de 100 Mo et l'image .iso de moins de 30 Mo.

    Divers bugs ont été corrigés et des améliorations ont été apportées dans cette version. Plus de 200 000 paquets ont été mis à jour, et 50 nouveaux paquets ont été ajoutés. Encore merci à tous ceux qui ont pris le temps de remonter les bugs.

    Les outils de configuration ont été retouchés afin que la configuration du système puisse se faire aisément même en mode texte. À noter également un meilleur support des langues, Tazpanel s'est vu apporter une cure de jouvence au niveau de l'interface, le support pour les anciens pilotes des disques ATA à été corrigé. Le bureau utilise de nouveau PCmanFM, qui dans sa nouvelle version apporte le support de la corbeille. Épaulé par gvfs/udisks, PCmanFM peut également gérer les disques amovibles.

    Le site principal adopte un nouveau style afin de vous fournir un moyen toujours plus facile pour naviguer et trouver l'information qu'il vous faut.

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Red Hat rachète la société Inktank à l'origine de Ceph

    Dimanche 4 Mai

    Ce 30 avril 2014, Red Hat annonce avoir engagé le rachat de Inktank, société à l'origine du système de fichiers distribué Ceph, pour la somme de 175 millions de dollars.

    Cette acquisition, accompagnée de celle de Gluster en octobre 2011, permet à Red Hat de se placer en tant que leader dans le domaine des systèmes de fichiers distribués libres. Gageons que ce rachat permettra au projet Ceph de se développer plus rapidement et de bénéficier de l'expertise de Red Hat dans l'écosystème autour du noyau Linux.

    Inktank

    Inktank, fondée en 2012, a pour but de promouvoir et de donner une direction au développement de Ceph, un système de fichiers distribué libre basé sur le stockage d'objets. La société propose ainsi des solutions permettant de déployer Ceph dans un environnement professionnel notamment utilisant une plateforme Red Hat.

    Parmi les services proposés se trouve l'application propriétaire Calamari, une interface graphique, qui permet de créer, gérer et suivre l'évolution de son cluster. Cette application ainsi que les autres développement propriétaires seront libérés par Red Hat suite à ce rachat.

    Ceph

    Ceph est un système de fichiers distribué basé sur le stockage d'objets et permet d'obtenir un service similaire à Amazon S3.

    La mise en place d'un cluster Ceph nécessite un minimum de trois hôtes : 1 moniteur et 2 serveurs de stockage. Le moniteur est le chef d'orchestre du cluster. Tout client souhaitant lire ou écrire un objet doit d'abord contacter un moniteur qui l'authentifiera et lui donnera les informations nécessaires pour contacter un serveur de stockage.

    Au nombre minimum de deux afin d'assurer la redondance des données, les serveurs de stockage se chargent d'écrire chaque objet sur le disque dur en utilisant les capacités du système de fichiers. Un objet se compose d'un identifiant, de données et de métadonnées.

    L'interaction avec un cluster Ceph se fait par l'intermédiaire de la librados qui permet de faire usage du cluster en fonction de ses besoins. Cependant, le projet fournit des services de base permettant ainsi d'utiliser Ceph comme périphérique block ou directement comme un système de fichiers POSIX.

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Nix 1.7, Nixpkgs, NixOS 14.04, Guix 0.6

    Dimanche 4 Mai

    Quelques mots d'introduction :

    • Nix est un système de paquets
    • nixpkgs la collection de paquets associée
    • NixOS la distribution construite avec nix et nixpkgs
    • Guix est un dérivé GNU de Nix

     

    Nix permet d'utiliser des paquets sources, comme sous Gentoo ou Arch, mais aussi des paquets binaires plus traditionnels. Comme presque tous les systèmes de gestion de paquets, il permet la gestion des dépendances entre paquets. Ses principes de fonctionnement originaux lui permettent d'implémenter de façon sûre des fonctionnalités souvent peu stables ou absentes des autres gestionnaires de paquets, notamment : installation de paquets dans le répertoire des utilisateurs, déploiement distribué, mélanges paquets sources et binaires et mises à jour réversibles. Il s'agit de la poursuite par la communauté du travail commencé par Eelco Dolstra dans sa thèse à la Technische Universiteit de Delft. La version 14.04 de NixOS est sortie le premier mai.

    Cette dépêche présentera l'écosystème Nix, puis les nouveautés de nixpkgs et NixOS 14.04, de Nix 1.7 ainsi que Guix, le dérivé GNU de Nix.

    Sommaire Pourquoi utiliser Nix et NixOS ?

    Nix emprunte sa philosophie « fonctionnelle pure » aux langages de programmation comme Haskell. Cela signifie que plutôt que de modifier en dur le système et ses fichiers, Nix permet de construire différentes « configurations » (un ensemble de paquets installés avec la configuration de la machine) et de basculer de l'une à l'autre. Grâce à cette spécificité, il propose son lot de fonctionnalités originales, absentes de la plupart des systèmes classiques de gestion de paquets :

    • possibilité d'annuler une mise à jour, de revenir à une ancienne version ;
    • pour procéder à une mise à jour ou une installation de paquet, on peut construire une machine virtuelle avec la nouvelle version du système, la tester, puis basculer le système si tout va bien ;
    • dépendances exactes ;
    • installation de paquets sans accès root ;
    • « USE FLAGS » façon Gentoo, compatibles avec des paquets binaires ;
    • cohabitation entre plusieurs versions du même paquet, ou de la même bibliothèque ;
    • builds reproductibles / purement fonctionnels.

    Le développement de nix et NixOS est très ouvert. Comme il sied à un projet de recherche en voie de pérennisation il passe par des projets github pour chacun des composants et les contributions sont bien acceptées.

    Les cousins 0install et pisi

    Le système 0install propose des fonctionnalités qui se rapprochent de celles de nix, en particulier la possibilité d'installer des paquets sans accès root. NixOS prend en charge toute la configuration du système (ou presque), tandis que 0install ne s'occupe que de paquets utilisateurs au sein d'un système hôte. Ainsi, 0install ne permet pas de rendre réversible la mise à jour des composants centraux du système, comme par exemple la libc. Il ne permet pas non plus d'intégrer l'installation et la configuration des paquets et encore moins de gérer le déploiement. De plus, 0install fonctionne en interceptant des appels système, ce qui le rend moins portable que nix.

    Tout comme avec 0install, nix permet de proposer des liens d'installation en un clic utilisables sans le mot de passe root. Cliquer sur un tel lien, par exemple celui pour quantumminigolf, permet d'installer un paquet et toutes ses dépendances.

    Une autre distribution Linux, Pardus, une distribution turque, a utilisé à un moment un gestionnaire de paquets un peu comparable avec nix, Pisi. Il propose une partie des fonctionnalités de nix, mais avec une approche moins théorisée. Pisi est aujourd'hui repris dans Pisi Linux, qui reste encore confidentiel. NixOS, Guix et Pisi Linux sont aujourd'hui les seules distributions à utiliser un système de paquet comparable à nix.

    Utilisation de nix et installation sur une distribution classique Survie sous nix Les commandes de base

    Les commandes de base de nix, détaillées dans le manuel sont assez semblables à celles d'autres gestionnaires de paquets:

    • nix-env --install firefox permet l'installation d'un paquet, binaire si une version binaire convenable est disponible, sinon depuis les sources. Notez l'absence de sudo…
    • nix-channel --update permet de mettre à jour la liste des paquets binaires disponibles ;
    • nix-env -qa '*' donne la liste de tous les paquets disponibles ;
    • nix-env -e hello permet de supprimer un paquet ;
    • nix-env -u '*' permet de mettre à jour tous les paquets.

    Les paquets sources sont dans un dépôt git qu'il faudra cloner et tenir à jour si l'on veut personnaliser ses paquets, comme l'arbre des ports sous freeBSD, par exemple.

    Où les choses deviennent intéressantes

    Nix propose aussi des opérations qui ne sont pas disponibles dans d'autres systèmes de gestion de paquets :

    • nix-env --rollback: si la dernière opération (par exemple un nix-env -u) n'a pas donné les résultats souhaités, elle permet de l'annuler ;
    • nix-env --switch-generation 82 permet de revenir à une ancienne configuration du système (nix-env --list-generations pour obtenir la liste de ces configurations) ;
    • nix-env -i juk --profile /nix/var/nix/profiles/music-lover permet d'installer un paquet dans un profil, et nix-env --switch-profile /nix/var/nix/profiles/music-lover permet de passer d'un profil à l'autre. Cela permet de disposer de plusieurs jeux de paquets entre lesquels on peut basculer suivant les besoins ou pour contourner d'éventuelles incompatibilités (par exemple entre deux versions d'un même paquet, dont on peut avoir besoin suivant le contexte). Ça permet aussi de créer des ensembles de paquets de référence pour utilisation ultérieure. Ainsi, dans une université, on crée un environnement logiciel spécifique à un TP et on peut le donner à tous les étudiants le temps de ce TP.

    L'un des avantages de nix, c'est que les simples utilisatrices et utilisateurs peuvent installer des paquets. Finies les re-compilations dans les home depuis les sources du paquet .deb ou .rpm parce qu'on n'a pas le droit d'écrire dans /usr ! Avec nix, le même paquet peut-être installé par root pour le système ou par un utilisateur ou une utilisatrice dans son home. En outre, si plusieurs personnes installent le même paquet (avec les mêmes options aux petits oignons et avec les mêmes versions des dépendances), elles partagent de façon sécurisée les binaires et autres fichiers de données du paquet.

    Installation sur une distribution classique

    De même, nix peut cohabiter avec un système de paquets classique pour permettre d'installer des paquets dans son home sur n'importe quelle distribution, avec le confort d'un vrai gestionnaire de paquets.

    Pour intaller nix sur un système Linux hôte autre que NixOS, il faut récupérer un paquet «classique» pour votre distribution sur le site de nix :

    Avec les paquets RPM et Debian, nix est alors installé en mode mono-utilisateur : seul root peut installer des paquets que tout le monde peut ensuite utiliser. C'est un peu dommage, car on perd une spécificité importante de nix.

    Il faut alors passer nix en mode multi-utilisateurs, comme indiqué dans le manuel. Pour cela, il faut :

    • créer des utilisateurs nixbld1, nixbld2, … qui pourront lancer les constructions de paquets qui seront ensuite partagés par tous ;
    • créer un groupe nixbld et y ajouter nixbld1, nixbld2 et seulement eux ;
    • donner au groupe nixbld les droits en écriture sur /nix/store :
    chgrp nixbld /nix/store chmod 1775 /nix/store
    • ajouter la ligne build-users-group = nixbld ;
    • lancer nix-daemon au démarrage de la machine ;
    • dans le .profile de chaque utilisateur ou utilisatrice de la machine, ajouter :
    export NIX_REMOTE=daemon source /etc/profile.d/nix.sh

    Ces solutions permettent de faire cohabiter nix avec un gestionnaire de paquets classique, à condition d'avoir un accès root pour installer nix. Dans le cas où les prosélytes de nix n'ont pas d'accès root à la machine, il leur est pour l'instant possible de l'utiliser, mais en perdant le bénéfice des paquets binaires. Il faut suivre une procédure décrite sur le wiki de nix. En effet, les paquets binaires de nix sont identifiés par un hash de leur contenu et de leurs dépendances ; ce hash tient donc notamment compte du préfixe du store nix, c'est à dire l'endroit où sont réellement stockés les fichiers de chaque paquet (cf. infra). Les hash des paquets (et de leur dépendances) vont donc différer entre la version standard (où le store est dans /nix/store) et une installation complètement dans /home/camille, où le store sera dans /home/camille/nix/store. Il arrive aussi que ces chemins se retrouvent codés en dur entre un paquet et ses dépendances. Il faut alors réécrire ces chemins à l'intérieur des binaires, ce qui n'est pour l'instant pas fait.

    Néanmoins, le projet Nix travaille dans nix et dans nixpkgs pour permettre de générer des paquets binaires portables vers les installations où le store est situé dans un endroit non standard, par exemple dans un répertoire home. Une fois ce projet abouti, il sera possible d'utiliser nix pour remplacer chacun des systèmes de paquets ad hoc fonctionnant utilisateur par utilisateur, qu'il s'agissent d'extensions firefox, emacs, ou eclipse, ou encore de bibliothèques Python (pip), Ruby (gems), Java (maven), OCaml (opam) ou Haskell (cabal). Le troll en moi dirait que chacun de ces systèmes ad hoc reproduit une version subtilement (ou pas) bugguée de nix, et que ces implémentations subtilement divergentes représentent une énorme quantité d'efforts vains (sans compter le temps perdu dans les bugs et défauts de conception de ces outils).

    Contenu de nixpkgs

    nixpkgs est la collection officielle de paquets (ou « dérivations ») pour nix et donc aussi pour NixOS. Elle contient tout type d'application, dont un bureau KDE complet. En revanche, Gnome3 n'était pas disponible jusqu'à la dernière version (14.04) : décrire la construction de cet environnement de bureau sous forme de dérivation nix, c'est-à-dire en donnant explicitement toutes les dépendances de construction s'était avéré trop complexe par rapport aux forces disponibles. Le choix de paquets est plus restreint que dans d'autres distributions plus populaires et l'on se retrouve rapidement à franchir la frontière entre utilisation passive et création ou amélioration de paquets. La version 14.04 de nixpkgs contient 4314 dérivations, qui correspondent (autant qu'il est possible pour la communauté) à une version récente et peu patchée des logiciels. On est donc plus dans la démarche d'Arch que dans celle de Debian. L'un des traits notable de la communauté nix, c'est son goût pour le langage Haskell ; dans ce domaine, c'est certainement l'une des collections de paquets les plus à jour qui soient.

    Chaque paquet est défini par une dérivation, c'est-à-dire une description de la façon de le construire à partir de ses dépendances. Chacune des dépendances peut être soit un autre paquet, soit une valeur (entier, booléen, chaîne de caractère…), ce qui permet de rendre les dérivations personnalisables, à la manière des use_flags de Gentoo. Pour ce faire, on va dans le fichier ~/.nixpkgs/config.nix et on peut y changer une variable comme config.pulseaudio pour désactiver pulseaudio et sa prise en charge dans toutes les applications (par défaut, nix construit des paquets qui utilisent pulseaudio).

    Le fichier ~/.nixpkgs/config.nix permet également via packageOverrides d'ajouter ses propres paquets à ceux de nixpkgs, voire de les substituer à ceux fournis par nixpkgs.

    Fonctionnement de nix Le store, l'environnement

    En utilisant nix, on se rend compte que si la première installation d'un paquet est une opération non-triviale (elle implique le téléchargement et la compilation éventuelle), en revanche, le passage d'un profil à un autre ou l'installation d'un paquet déjà installé dans un second profil est immédiate.

    C'est que nix stocke le contenu des paquets dans un endroit commun, quels que soient le ou les profils dans lesquels ce paquet est considéré comme installé. Cet endroit est le store, situé (sauf installations bidouillées jusqu'au trognon) dans /nix/store.

    Un which firefox sur un système où firefox est un paquet nix nous permet de constater que le cœur de nix est un empilement de liens symboliques:

    Ainsi, l'exécutable firefox est stocké dans un sous-répertoire de /nix/store différent pour chaque version présente sur le système ; s'il fait référence à une bibliothèque ou à un autre exécutable, celle-ci sera elle aussi dans son répertoire propre ; une mise à jour ne viendra donc pas modifier la version de la dépendance à laquelle firefox fait référence.

    Pour chaque paquet, le hash qui sert d'identifiant au répertoire contenant les données du paquet est un hash non seulement des sources du paquet, mais aussi de ses dépendances. Ceci garantit que deux exécutables de paquets ayant le même hash auront exactement le même comportement. On peut ainsi sans risque partager des paquets binaires en présence de « personnalisation » à la Gentoo.

    Lors d'une mise à jour, un nouveau répertoire est créé pour chaque paquet, avec une nouvelle version du paquet. Ensuite, un nouveau profil est créé, avec des liens pointant à l'intérieur de chacun des paquets du profil. Enfin, le profil personnel (~/.nix-profile) est mis à jour. Ainsi, plusieurs utilisateurs et utilisatrices peuvent partager des versions présentes dans différents sous-répertoires du store (/nix/store) et ne pas avoir à les recompiler de leur côté, sans qu'aucun n'ait d'accès root. Les mises à jour se font alors séparément, sauf pour les paquets système. Ainsi, les collègues qui passent à firefox 29 ne cassent pas le firefox 28 des autres.

    Anatomie d'une dérivation nix

    Pour construire un paquet, on part de ses dépendances et d'une dérivation qui indique comment assembler ces dépendances.

    Pour les logiciels les plus courants, pour l'installation desquels la séquence ./configure; make; make install suffit, les dérivations sont très faciles à écrire. Ainsi pour emboss, un logiciel de biologie moléculaire, on utilise le fichier suivant:

    {stdenv, fetchurl, readline, perl, libX11, libpng, libXt, zlib}:
    • une première ligne pour spécifier les dépendances. La dérivation étant une fonction, les dépendances sont ses arguments. S'il y avait des « use_flags », ils seraient aussi spécifiés comme arguments de la dérivation (ce n'est pas le cas ici). Dans la suite (le corps de la fonction), chacun des arguments — par exemple zlib — désignera le chemin vers le paquet correspondant dans le store — par exemple /nix/store/12345…zlib-1.2.3.
    stdenv.mkDerivation { - Un appel à la fonction standard `mkDerivation`, qui construit une dérivation à partir d'informations de base qui vont suivre. On remarque que cette fonction est définie dans `stdenv`, une des dépendances de la dérivation. name = "emboss-6.0.1"; src = fetchurl { url = ftp://emboss.open-bio.org/pub/EMBOSS/EMBOSS-6.0.1.tar.gz; sha256 = "0g939k9wmpvmy55hqmbbzj6kj6agg4izymv492zqiawxm812jd9y"; }; - L'argument de `mkDerivation` est une structure, avec des champs comme le nom du paquet construit par la dérivation, ou la localisation de sa source. La source est obtenue par un appel à la fonction `fetchurl`, elle aussi donnée dans les dépendances. buildInputs = [readline perl libpng libX11 libXt zlib]; - `buildInputs` indique lesquelles des dépendances sont mises dans l'environnement du constructeur (_builder_). Ici, les exécutables `readline` et `perl` seront placés dans son `PATH`, tandis que les chemins des en-têtes et fichiers objets des bibliothèques comme `libpng` seront dans les variables d'environnement du compilateur et de l'éditeur de liens. meta = { description = "EMBOSS is 'The European Molecular Biology Open Software Suite'"; longDescription = ''EMBOSS is a free Open Source software analysis package specially developed for the needs of the molecular biology (e.g. EMBnet) user community, including libraries. The software automatically copes with data in a variety of formats and even allows transparent retrieval of sequence data from the web.''; license = "GPL2"; homepage = http://emboss.sourceforge.net/; }; }
    • Finalement, on indique les méta-données de la dérivation ; c'est tout.

    Pour des paquets moins standards, on peut aussi changer une des étapes de construction, appliquer des patches ou autres, mais nous n'aborderons pas ces points ici, ils suivent la même logique.

    Cette dérivation est une fonction, pour pouvoir l'utiliser il faut lui passer ses arguments. C'est ce qui est fait dans le fichier pkgs/toplevel/all-packages.nix, où on trouvera les lignes :

    emboss = callPackage ../applications/science/biology/emboss { };

    On appelle la fonction définie par la dérivation pour emboss. La fonction callPackage passe par défaut à la dérivation les variables locales dont le nom correspond à ceux de ses arguments, donc la valeur de stdenv, perl, libpng etc. On aurait aussi pu écrire l'importation du fichier et l'appel explicitement :

    emboss = (import ../applications/science/biology/emboss) { stdenv = stdenv, perl = perl, …}; Dérivations engendrées automatiquement

    De nombreux langages de programmation proposent leur propre gestionnaire de paquets. Sur un système classique, cela permet de contourner l'impossibilité d'installer des paquets sans accès root, ainsi que de permettre de faire cohabiter des paquets « système » stables, et des versions de développement récentes. On a ainsi pip pour Python, npm pour Node.js, gems pour Ruby ou encore cabal pour Haskell.

    Sous un système nix, ces fonctionnalités ne sont pas nécessaires et ces systèmes sont donc redondants. Cependant, chacun des paquets qui y sont définis contiennent des informations de dépendances. Nix dispose d'outils pour les récupérer et définir automatiquement des dérivations ; on a ainsi cabal2nix pour Haskell ou npm2nix pour Node.

    Développement sous nix

    Nix et NixOS sont particulièrement adaptés pour les développeurs et développeuses dont les besoins en termes de configuration logicielle peuvent varier en fonction des projets, voire au sein de chacun d'entre eux. Il est possible sous nix de développer chaque projet dans son propre environnement logiciel, sans interférences et sans recourir à des machines virtuelles.

    La petite histoire de rsCoinCoin

    Supposons par exemple que nous décidions de lancer le projet rsCoinCoin de développement d'un client pour la tribune d'un site de nouvelles francophone sur l'actualité de Linux et des logiciels libres.

    Nous allons développer ce projet en Rust, un langage moderne et pas fini en évolution continue.

    On commence benoîtement par installer le compilateur Rust :

    jacques$ nix-env -i rust jacques$ rustc --version rustc 0.9 host: i686-unknown-linux-gnu

    Voilà, le compilateur Rust est installé. Nous avons fait l'installation dans notre profil ; les autres utilisateurs et utilisatrices de la machine n'y voient que du feu.

    jacques$ su denis denis$ rustc --version The program ‘rustc’ is currently not installed. You can install it by typing: nix-env -i rust Utilisation de nix pour gérer des « profils de développement »

    Ainsi donc, si parmi les utilisateurs de ce système NixOS, il y a une développeuse du compilateur Rust, Suzanne, qui utilise une version plus récente du langage, elle aura dans son profil une autre version de Rust :

    suzanne$ rustc --version rustc 0.10 host: i686-unknown-linux-gnu

    Cette situation est parfaitement normale sous nix, les paquets des deux personnes sont des paquets systèmes parfaitement normaux et il n'y a pas besoin de prévoir spécifiquement paquet par paquet que plusieurs versions puissent cohabiter.

    Création d'un nouveau profil

    Il est même possible de se créer plusieurs profils et de basculer de l'un à l'autre. Ainsi, lorsque notre développeuse veut repasser en Rust 0.9 pour participer au développement de rsCoinCoin, elle se crée un « profil » rust09 vers lequel elle basculera son shell pour développer rsCoinCoin.

    suzanne$ ls -ld ~/.nix-profile lrwxrwxrwx 1 user2 user2 46 22 avril 16:44 /home/suzanne/.nix-profile -> /nix/var/nix/profiles/per-user/suzanne/default suzanne$ export my_profiles_dir=/nix/var/nix/profiles/per-user/user2 suzanne$ nix-env -u rust-0.9 --always -p $my_profiles_dir/rust09 --from-profile $my_profiles_dir/default

    On a bien rust 0.9 dans ce profil :

    suzanne$ nix-env --switch-profile $my_profiles_dir/rust09 suzanne$ ls -ld ~/.nix-profile lrwxrwxrwx 1 user2 user2 46 22 avril 16:44 /home/suzanne/.nix-profile -> /nix/var/nix/profiles/per-user/suzanne/rust09 suzanne$ rustc --version rustc 0.9 host: i686-unknown-linux-gnu

    En revanche, dans le profil par défaut, on a toujours le 0.10 :

    suzanne$ nix-env --switch-profile $my_profiles_dir/default suzanne$ ls -ld ~/.nix-profile lrwxrwxrwx 1 user2 user2 46 22 avril 16:44 /home/suzanne/.nix-profile -> /nix/var/nix/profiles/per-user/suzanne/default suzanne$ rustc --version rustc 0.10 host: i686-unknown-linux-gnu

    Notons que comme Jacques et le profil rust09 de Suzanne utilisent la même version de rustc, l'exécutable n'est installé qu'une fois sur le système.

    nix-shell et le fichier rsCoinCoin/shell.nix

    Nous pouvons aller plus loin, et lier le changement d'environnement avec le projet. Pour cela, nous allons décrire l'environnement de construction et d'utilisation de rsCoinCoin avec un fichier shell.nix du même goût que le default.nix que nous avons vu plus haut pour emboss. Ce fichier nous permet de communiquer au reste du monde, développeuses et utilisateurs comment déployer rsCoinCoin. Il nous permet aussi de passer nous-même dans cet environnement de développement de rsCoinCoin avec un sous-shell. Comme nous nous apprêtons à écrire une dérivation qui va rester autonome vis-à-vis du reste de nixpkgs (pour l'instant), elle va prendre une forme un peu différente, avec une importation explicite des dépendances depuis nixpkgs :

    let nixpkgs = (import <nixpkgs> {}) inherit (nixpkgs) rust stdenv gtk; #… autres dépendances in stdenv.mkDerivation (self: { name = "rsCoinCoin"; # etc, cf ci dessus })

    On n'a plus ici une fonction, mais directement la définition d'une valeur-dérivation. À partir de celle-ci on a un environnement, et la commande nix-shell nous permet de lancer un shell dans cet environnement. On peut ainsi utiliser une version différente des bibliothèques pour différents projets sans conflits, et encore une version différente en tant qu'utilisateur final pour construire nos paquets quotidiens.

    NixOS et ses particularités techniques Présentation générale de NixOS

    Autour du gestionnaire de paquets nix, il existe une distribution GNU/Linux: NixOS. Utiliser NixOS permet de profiter des avantages de nix et de son approche purement fonctionnelle dans tous les aspects de la configuration du système. Pour le reste, y a-t-il réellement encore une différence entre distributions ?

    Utilisation de nixos-rebuild pour les mises à jour nixos-rebuild

    La mise à jour du système se fait par la commande nixos-rebuild, qui comme son nom l'indique permet de reconstruire le système avec de nouveaux paquets système ou une nouvelle configuration système. Elle assure le même rôle que nix-env, mais elle prend en charge la configuration d'un système complet, plutôt que simplement celle d'une collection de logiciels. Intéressons-nous d'abord au cas d'une mise à jour des paquets du système, sans changement de la configuration locale.

    On commence par mettre à jour le canal des paquets :

    $ sudo nix-channel --update

    soit l'équivalent de :

    $ sudo apt update L'opération switch (et rollback)

    Une fois les définitions de paquets mises à jour, on peut construire le nouveau système et y basculer :

    $ sudo nixos-rebuild switch

    ce qui correspond (superficiellement) à :

    $ sudo apt upgrade

    La différence avec un système classique, c'est qu'une telle mise à jour est réversible.

    Catastrophe ! La mise à jour à tout cassé, la police du terminal est passée en comic sans. Que faire ? Un simple

    $ sudo nixos-rebuild switch --rollback

    nous ramène à la version précédente.

    Diantre ! La mise à jour a tout cassé, le système ne boote plus. Pas de panique, la version précédente du système est accessible depuis le menu grub (la capture d'écran est un peu datée, un nixos récent utiliserait grub2) :

    L'opération build-vm

    Pour éviter les déconvenues du paragraphe précédent, nixos propose une opération
    nixos-rebuild build-vm qui crée une machine virtuelle correspondant à la nouvelle configuration. On peut ainsi en tester le fonctionnement par :

    $ nixos-rebuild build-vm $ ./result/bin/run-*-vm

    On pourra ensuite basculer le système hôte vers cette configuration si elle donne satisfaction.

    Profils système

    De même que les profils utilisateurs, on peut utiliser

    $ nixos-rebuild build -p autreProfil

    pour créer un nouveau profil système. Celui-ci apparaîtra dans le menu grub, mais ne modifiera pas le système par défaut.

    Le fichier /etc/nixos/configuration.nix

    L'idée centrale de nix, c'est que la composition et le fonctionnement de chaque composant du système ne dépend que des entrées de la dérivation correspondante. Comme nous venons de le voir, la commande nixos-rebuild prend en entrée une description du système que l'on souhaite obtenir, et le met en place (sur la machine ou dans une machine virtuelle).

    Le fichier /etc/nixos/configuration.nix permet de donner cette description complète du fonctionnement du système : chaque service qui peut tourner sur un système NixOS a une section dans ce fichier qui définit sa configuration. La commande nixos-rebuild aura pour effet de mettre en place les changements de configuration. Il est bien sûr possible d'utiliser import pour découper ce fichier, mais nixos n'impose pas de découpage, ce qui permet de grouper des outils liés.

    Voici par exemple la section consacrée à l'internationalisation :

    i18n = { consoleFont = "lat9w-16"; consoleKeyMap = "fr"; defaultLocale = "fr_FR.UTF-8"; };

    ou celle pour SLiM, un utilitaire de login graphique :

    services.xserver.displayManager.slim.enable = true; services.xserver.displayManager.slim.defaultUser = "dominique"; services.xserver.displayManager.slim.autoLogin = true;

    Avec ce système, il n'est théoriquement pas nécessaire d'apprendre d'autres langages de configuration que nix, qui a de plus l'avantage d'être Turing-puissant. Évidemment ce confort a des limites, avec des variables du type « machin.extraConfig : chaîne à ajouter à la fin du fichier /etc/machin.conf » et la nécessité d'écrire une couche de transformation entre le langage nix et le fichier de configuration.

    Ce système permet aussi d'intégrer la configuration du système et la définition des paquets à installer. Ainsi, la ligne suivante dans configuration.nix :

    fileSystems.myWindowsDisk.fsType = ntfs;

    indique que myWindowsDisk doit être monté en NTFS, mais elle provoquera aussi l'installation du paquet ntfs3G de manipulation de systèmes de fichiers NTFS.

    Enfin, comme tous les changements de configuration sont traités par nix, il est possible d'utiliser nixos-rebuild --rollback pour revenir sur les changements de configuration. Il est également possible d'utiliser des profils pour basculer entre plusieurs configurations. On a ainsi un système de gestion de version de la configuration qui sait quelles sont les opérations à faire (démons à relancer entre autres) pour basculer pour basculer d'une configuration à une autre. L'utilisation de systemd s'avère indispensable pour pouvoir faire cette bascule de façon fiable.

    NixOS contre la FHS


    Il existe une norme sur la disposition de la hiérarchie du système de fichiers des unix-like, la FHS (Filesystem Hierarchy Standard). Pour fonctionner correctement, NixOS a besoin de faire beaucoup d'entorses à ladite FHS, entre autres :

    • il n'y a pas de /usr, et /bin ne contient qu'un élément
    • /etc n'est pratiquement composé que de liens symboliques.

    On peut expliquer ce choix par le fait que nix résout de manière correcte le problème que la FHS tente de contourner : chaque composant logiciel doit pouvoir trouver où les autres composants ont mis leurs fichiers. La FHS résout ce problème de manière implicite avec des conventions (l'exécutable de wmcoincoin de référence sera dans /usr/bin ou une de ses variantes), tandis que nix le résout de manière explicite (on construit wmblinkingcoincoin avec en paramètre la référence de la version en usage de wmcoincoin).

    Nixops

    Un système nixos étant entièrement défini à partir de son fichier /etc/nixos/configuration.nix, on peut décrire simplement le déploiement d'un parc de machines : telle machine devra avoir la configuration décrite par tel fichier configuration.nix. C'est sur ce principe que repose l'outil de déploiement réseau et de distribution sur nuage nixops. Le 30 avril dernier, la version 1.2 de nixops est sortie. Le rédacteur de la dépêche doit avouer sa méconnaissance de nixops, au-delà de son principe alléchant. Le manuel et l'exemple d'utilisation pour déployer une application node permettent de se faire une idée de la chose.

    Nouveautés des dernières versions de l'écosystème nixos Nix 1.7

    La version 1.7, sortie le 11 avril 2014 apporte son lot de nouveautés par rapport à la 1.6 (septembre 2013):

    • nix-build --check permet de construire à nouveau une dérivation existante et de vérifier si le résultat est le même. On peut ainsi faire la chasse aux sources de non-déterminisme dans le processus de construction (date de la compilation qui se retrouve dans l'exécutable ou autres) ;
    • nix-shell -p permet de lancer un environnement contenant (uniquement) une liste de paquets de nixpkgs ;
    • nix-shell utilise shell.nix comme expression par défaut ; en revanche, nix-build utilise toujours default.nix, ce qui permet d'avoir plus facilement une expression pour construire un projet, et une autre pour travailler dans son environnement de développement ;
    • nix-env -q --json donne une représentation JSON des paquets installés ou disponibles ;
    • le ramasse-miette du store a été amélioré: on peut lui demander de libérer une quantité donnée d'espace, ou de préserver les paquets les plus récents, fussent-ils inutilisés ;
    • cette version introduit une gestion expérimentale des dépôts binaires crypto-signés.
    nixpkgs 14.04

    De même, nixpkgs 14.04 se renouvelle, avec notamment :

    • gcc 4.9
    • xorg-server 1.14
    • mesa 10.1
    • gtk 3.12
    • kde 4.12
    • gnome 3.10 (expérimental), il n'y avait pas de gnome du tout dans nixpkgs 13.10
    • par défaut, nixpkgs est maintenant une collection de logiciels libres : il faut passer la variable allowUnfree à true pour installer les dérivations de logiciels non-libres.
    NixOS 14.04

    La mise à jour vers NixOS 14.04 se fait tout simplement en pointant le channel système vers http://nixos.org/channels/nixos-14.04, puis en lançant nixos-rebuild switch. En plus des nouveautés héritées de nixpkg, les parties propres à NixOS ont changé :

    • par défaut, la gestion des comptes-utilisateurs peut se faire depuis configuration.nix plutôt que par useradd et userdel (de même pour les groupes) ;
    • l'installeur sait se débrouiller sur les machines UEFI ;
    • il est possible de créer des containers dans NixOS, sortes de machines virtuelles légères pour les besoins ponctuels en virtualisation ;
    • par défaut, un pare-feu est mis en place à l'installation, comme sous StarOffice ;
    • le reste des changements est visible dans la section idoine du manuel.
    Guix, le nix de GNU

    Ludovic Courtès, un hacker GNU particulièrement impliqué dans Guile a créé le premier dérivatif de NixOS, Guix. De nix, il a gardé les couches basses, c'est-à-dire le store et le démon nix-daemon. En revanche, la définition des paquets et de la configuration du système se fait en Guile, le dialecte Lisp de GNU.

    Du point de vue du contenu, nixpkgs est assez permissif avec les logiciels privateurs : ils sont présents dans nixpkgs et étaient installables par défaut jusque récemment. Guix, en tant que système GNU, est rigoureusement fidèle aux principes de la FSF ; il ne contient donc que des logiciels libres.

    Le slogan du projet est « Guix, the GNU system » (Guix, le système GNU), il s'agit donc d'une proposition pour réaliser une distribution du système GNU. À ce titre, il donne une place privilégiée, non seulement à Guile, mais aussi à d'autres briques logicielles GNU, comme dmd, un système d'init scriptable lui aussi en Guile. En revanche, il utilise pour le moment un noyau Linux et non Hurd.

    L'avantage recherché par Guix, c'est de se passer du langage nix, jugé ad-hoc, au profit de Guile (un langage lisp). Cela évite d'avoir à apprendre un nouveau langage pour écrire des dérivations (spécifications de paquets) et permet d'utiliser toutes les bibliothèques Guile dans la définition des dérivations. Cette démarche est expliquée dans le papier de Ludovic Courtès présentant Guix.

    Les nouveautés de la version 0.6, sortie le 9 avril ont donné lieu à un journal sur linuxfr. Les principaux changements sont indiqués dans l'annonce de cette version, ils concernent à la fois l'outil guix de gestion des paquets et le contenu de la collection de paquets. Cette version 0.6 ne permet toujours que l'exécution dans une machine virtuelle.

    Ludovic Courtès a indiqué le chemin restant à parcourir jusqu'à Guix 1.0 dans un message sur la liste de guix.

    Copylefts

    Les captures d'écrans et la figure explicative des liens enchaînés sont faites par Eelco Delstra, sous licence CC-By 4.0. La section « anatomie d'une dérivation » reprend la dérivation pkgs/applications/science/biology/emboss, qui est sous licence MIT.

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Appel à l'aide de l'équipe KDE de Debian

    Dimanche 4 Mai

    L'équipe KDE de Debian cherche de l'aide, je traduis donc l'appel de l'équipe, au cas ou des francophones seraient motivés…

    Salut,

    Depuis quelques temps déjà, l'équipe KDE est en sérieux sous-effectif. Nous maintenons de nombreux paquets, avec différents types de bugs, mais nous n'avons pas assez de personnes pour effectuer le travail. Des outils permettent d'automatiser les mises à jour depuis les développeurs amonts, mais ce n'est que la partie émergée de l'iceberg, nous invitons donc plus de personnes à s'impliquer dans l'équipe pour avoir les logiciels KDE en meilleur état dans Debian.

    Voici quelques tâches qui nous aideraient :

    • Tri des bugs : il y a énormément de bugs dans le BTS (NdT : le système de gestion de bugs de Debian). Nous avons besoin de personnes qui les analysent, comprennent les problèmes, essayent de les reproduire, confirment s'ils sont présents dans les dernières versions. En particulier, nous avons besoin de personnes pour les bugs qui affectent la version stable Wheezy.
    • Transferts de bug : nous sommes tellement en sous-effectif que nous demandons aux utilisateurs de transférer eux-mêmes leurs bugs aux développeurs amonts. Certains utilisateurs le font, d'autres non. Si certaines personnes pouvaient prendre ça en charge, ça nous aiderait beaucoup.
    • Transferts de patch : nous avons un certain nombre de patchs appliqués dans les paquets Debian qui mériteraient d'être appliqués en amont. Certains ne sont pas spécifiques à Debian. Ce travail nous ferait gagner du temps dans le futur, il est donc important qu'il soit fait.
    • Tests de mise à jour : par le passé les mises à jours d'une Debian stable vers une autre étaient assez traumatisantes pour les utilisateurs de logiciels KDE. Nous avons besoin de personnes qui testent les mises à jours depuis Wheezy (NdT : l'actuel stable) vers Jessie (NdT : la future stable), pour rapporter les bugs qu'ils rencontrent, afin de les résoudre avant la sortie de la nouvelle version.
    • Créations de patch : de nombreux bugs nécessitent de réécrire des patchs, certains faciles d'autre plus difficiles, mais toute aide est bonne à prendre.
    • Empaqueter d'autres applications KDE : nous empaquetons les composants principaux de KDE, mais d'autres composants pourraient être utiles.
    • Mise à jour de la page d'accueil du wiki, en ajoutant ces tâches et les futures, ainsi qu'en unifiant les listes de TODO :

    Si vous êtes intéressés, merci de rejoindre le canal IRC #debian-qt-kde sur irc.oftc.net ou la liste de diffusion (NdT : en anglais). Nous serons heureux de vous aider à démarrer.

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Libération d’outils pour développeur de jeu vidéo

    Dimanche 4 Mai

    Plusieurs outils à destination des développeurs de jeux vidéo ont été libérés récemment. Ces outils permettent de porter des jeux Direct3D vers OpenGL ou encore de les débugger ou mesurer leurs performances, ce qui facilite et encourage grandement le développement de jeux vidéos de qualité pour GNU/Linux. Ces outils sont publiés à destination des développeurs de jeux libres ou non (grâce à des licences très permissives).

    C'est l'occasion d’évoquer brièvement quelques ports sous GNU/Linux de moteurs de jeux notables (bien que non-libres) révélant l’intérêt grandissant porté par l’industrie du jeu vidéo pour cette plate-forme.

    ToGL

    ToGL est un outil libéré par Valve (l’éditeur de Steam). Cet outil sert de traducteur de Direct3D vers OpenGL (objets, shaders…), le code provient du jeu Dota 2. Valve a publié le code de ToGL sur GitHub dans le but d’aider d’autres développeurs de jeux à porter vers OpenGL leur code initialement développé pour Direct3D. Le code est sous licence MIT, une licence libre très permissive qui permet d’inclure le code dans un programme non-libre.

    Rappelons que Valve porte un intérêt majeur à la plate-forme GNU/Linux puisque la console de jeu Steam utilise une variante de Debian (SteamOS) et la plate-forme non-libre Steam a été portée sous GNU/Linux depuis plus d'un an déjà. La stratégie de Valve est donc de faciliter au maximum le port de jeux vers GNU/Linux.

    Si Steam n’est pas un logiciel libre, le poids d’un acteur comme Valve est non négligeable et il pousse ainsi de nombreux projets libres qui lui sont favorables. Par exemple, les développeurs de Valve collaborent étroitement avec les développeurs de pilotes graphiques (libres inclus) et les améliorations apportées profitent même à ceux qui ne sont pas clients de Valve.

    VOGL et VOGLperf

    Valve a d’abord publié un debugger OpenGL : VOGL. VOGL s’utilise de la même manière qu’APITrace, une autre application pour examiner un code OpenGL : il suffit de précharger une bibliothèque avec LD_PRELOAD avant de lancer un binaire pour que cette bibliothèque intercepte les appels OpenGL dudit binaire.

    Valve choisit des licences permissives pour couvrir les codes qu’ils publient afin de permettre la réutilisation de ces codes par les jeux non-libres. La volonté de Valve étant de voir le maximum de produits qu’il revend (majoritairement non-libres) portés sous GNU/Linux, une licence libre sans copyleft est ce qu’il y a de plus efficace pour cela.

    Ici le libre est réduit à n’être qu’un moyen technique efficace, mais ces codes profitent aussi aux projets qui font de la liberté un idéal. Par exemple le jeu libre Xonotic est connu pour se servir de VOGL, et il ne sera pas le dernier jeu libre à profiter de cet outil très utile.

    Après VOGL, Valve a publié VOGLperf. VOGLperf permet de récupérer les informations de trame (FPS, temps de la trame et valeurs min/max), seconde par seconde, lorsqu'une application utilisant OpenGL est lancée. L’outil permet ainsi de réaliser des benchmarks de jeux OpenGL sous GNU/Linux, et permet donc de mesurer finement des variations de performances dans un même jeu ou de comparer deux versions de développement, par exemple.

    HLSLParser

    Valve n’est pas le seul à libérer du code utile. Unknown Worlds, l’équipe qui développe Natural Selection 2, a libéré son outil HLSLParser qui sert à traduire des shaders HLSL (Microsoft High-Level Shader Language, utilisé dans Direct3D) vers des shaders GLSL (OpenGL Shader Language).

    Ces quatres outils, ToGL, VOGL, VOGLPerf et HLSLParser sont publiés sous licence MIT.

    Quelques ports notables

    Ces libérations s’inscrivent dans un mouvement plus global qui témoigne d’un intérêt grandissant pour la plate-forme GNU/Linux. C’est l’occasion de faire un point vers les travaux de portage en cours. Après les annonces de Valve on peut citer le port du CryEngine ou d’Unreal Engine 4 (qu’UrbanTerror HD a déjà annoncé vouloir utiliser).

    Si vous avez connaissance d’autres outils libérés récemment à destination des développeurs de jeu, ou si vous connaissez d’autres jeux majeurs en bon chemin vers GNU/Linux, n’hésitez pas à laisser un commentaire pertinent. ;-)

    Ça sera peut-être l’occasion d’initier un second épisode à cette dépêche d’avril 2013 : « État des jeux sous Linux ».

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Atelier hyperviseur Xen

    Samedi 3 Mai

    Dans le cadre de ses formations bi-mensuelles, l'association StarinuX vous convie à l'atelier « l'hyperviseur Xen ». Le programme est en seconde partie.

    • Date : le samedi 24 mai de 9h à 18h.
    • Lieu : 10 rue des terres au curé Paris 13ème, métro Olympiades.
    • Modalités : participation de 15 € (demandeurs d'emploi 7,50 €) , valable une année pour dix à douze ateliers.
    Le programme Introduction :

    Objectifs et présentation du contenu.

    Présentation technique :

    Pourquoi et comment virtualiser ?
    Préparation de l'environnement.

    Pratique :
    • Installation et présentation de Virtualbox.
    • Installation d'une machine virtuelle (VM) Android.
    • Installation de XEN.
    • Installation et présentation de l'hyperviseur XEN.
    • Installation et présentation du client OpenXenManager.
    • Importation d’une Appliance (CentOS).
    • Ajouter une licence à XenServer.
    • Création d'un Repository pour le stockage des fichiers ISO dans XenServer.
    • Création d'un VM (CentOS).
    • Installer les XenServer tools.
    • Passer son Linux de HVM à PV (Hardware-assisted Virtualization Manager & Para-Virtualization).
    Pour aller plus loin :

    Présentation d'un datacenter.
    Créer des machines virtuelles (VM) en datacenter.
    Pourquoi créer des grappes (clusters) de serveurs ?

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Synfig, le développement avance à grands pas, et continue sur sa lancée…

    Vendredi 2 Mai

    Synfig le logiciel libre d'animation 2D vectoriel bénéficie depuis plusieurs mois d'un coup d'accélérateur tout bonnement incroyable!

    La liste des choses à venir

    L'interface fenêtre unique, le mouvement basé sur la dynamique, la refonte de l'animation par ossature, l'optimisation du moteur de rendu vectoriel, le format de fichier englobant (et historique de révision), la permutation des calques dans les groupes, l'outil de transformation « User friendly », de nombreux autres raffinements et correctifs…

    Mais aussi, et c'est tout nouveau pour ce logiciel orienté vecteurs, l'ajout de fonctionnalités pour l'animation d'images matricielles, avec la capacité de modifier les images importées (support des brosses MyPaint), l'animation image par image et tout dernièrement l'arrivée de la déformation d'images par ossatures !

    Une véritable liste à la Prévert ? en fait non… tout un ensemble de nouveaux outils et fonctionnalités pour faire de Synfig un logiciel d'animation encore plus puissant qui vous permettra de réaliser des animations 2D de qualité ou de faire de la post-production vidéo libre.

    En plus des contributions de quelques développeurs (dont je fait partie), depuis la fin de l'année 2013 un financement participatif mensuel rémunère un codeur à temps plein sur le logiciel. Chaque mois, ce financement offre la possibilité d'orienter le développement vers telle ou telle fonctionnalité, c'est de cette façon que la majorité des nouveautés citées précédemment ont été réalisées. La version stable du logiciel est toujours la 0.64.1 qui est sortie en novembre 2013, la numérotation devrait faire un gros bond en avant avec tout ceci, alors que les versions de développement sont numérotées en 0.65.0, Synfig pourrait se rapprocher d'une version 1.0.

    Déformation d'images matricielles

    Je ne vais pas ici détailler toutes les fonctionnalités introduites depuis la dernière version stable, pour me concentrer sur l'ultime apparition : la déformation d'images matricielles par ossatures avec une démonstration réalisée par Konstantin Dmitriev (vidéo).

    Télécharger ce contenu au format Epub

    Lire les commentaires

    OpenBSD 5.5 : nous ne voulons pas retourner dans le passé !

    Vendredi 2 Mai

    Comme tous les 6 mois une nouvelle version d'OpenBSD est publiée.

    OpenBSD est un système d'exploitation orienté sécurité et réseau, dont les principaux avantages sont la stabilité, grâce aux audits sur le code source, mais également l'ensemble très large de fonctionnalités réseau qu'il fournit.

    Mises à jour Améliorations sur l'installeur

    L'installeur d'OpenBSD gère désormais l'installation automatisée (autoinstall). Cette installation automatisée permet de déployer ou mettre à jour rapidement OpenBSD par le réseau en spécifiant un fichier de réponses. Ce fichier est distribué via un serveur HTTP dont l'adresse est renseignée dans l'option next-server du DHCP. Cette installation est possible à la fois en installation par le réseau (netboot) et par le CD-ROM.

    time_t 64 bits

    Le problème actuel de la variable time_t est qu'elle est codée sur 32 bits dans tous les systèmes UNIX. Le 19 janvier 2038 à 3h14 et 7 secondes cette variable atteindra sa valeur limite, causant des problèmes graves, avec la réinitialisation de celle-ci à zéro.

    L'équipe d'OpenBSD a fait un énorme travail afin de convertir le type de variables en 64 bits, de corriger tous les programmes inclus dans la distribution et patcher/auditer les différents ports.

    Packet Filter
    • Packet Filter inclut désormais un nouveau système de queue afin de gérer la qualité de service.
    • Le paramètre received-on peut désormais prendre pour valeur any afin de correspondre à toutes les interfaces, excepté celles de loopback.
    • La politique de blocage par défaut dans le pf.conf de base est désormais un block return.
    Sécurité
    • OpenBSD ne garantissait pas la sécurité par la signature cryptographique des paquets. C'est désormais chose faite, les paquets et la distribution sont désormais signés via l'outil signify.
    • relayd gère désormais la fonction Perfect Forward Secrecy de TLS avec ECDHE (courbe elliptique Diffie-Hellman). Cette option est désormais activée par défaut.
    • Le générateur de nombres aléatoires est désormais initialisé par le bootloader.
    • Le protecteur de la pile du kernel est également initialisé par le bootloader.
    Réseau
    • Prise en charge de VxLAN
    • Amélioration de la gestion du déchargement des sommes de contrôles TCP/UDP/ICMP (checksum offload)
    • Activation de la prise en charge de domaines de routage IPv6 (ping6, traceroute6…)
    • tcpdump peut désormais détecter des sommes de contrôle incorrectes sur ICMP et ICMPv6
    • Diverses améliorations sur dhclient et dhcpd.
    Performances
    • Les relations entre le cache des tampons et le démon de swap ont été améliorées.
    Logiciels

    Voici une liste non exhaustive de logiciels inclus dans OpenBSD 5.5

    • Gnome 3.10.2
    • KDE 4.11.5
    • PostgreSQL 9.3.2
    • Postfix 2.11
    • PHP 5.4.24
    • Firefox 26
    • OpenSSH 6.6
    • OpenSMTPd 5.4.2
    Pilotes
    • Gestion des cartes réseau virtuelles VMware VMXNET3
    • Gestion des contrôleurs SCSI VMware Paravirtual
    • Gestion des contrôleurs SCSI virtio
    • Gestion des périphériques de nombres aléatoires virtio
    • Gestion des trackpad Broadcom présents dans les Macbook récents
    • KMS gère désormais les sorties DisplayPort
    • Ajout du système de fichiers tmpfs
    • Plusieurs améliorations sur la couche FUSE.
    Plateformes matérielles
    • alpha : gestion multi-processeur
    • aviion : gestion des processeurs AViiON
    • armv7 remplace la prise en charge de l'architecture Beagle.
    LibreSSL et HeartBleed

    Malgré la sortie de cette version 5.5 et le fork de la bibliothèque OpenSSL en LibreSSL, orchestré par l'équipe d'OpenBSD afin de nettoyer et auditer le code d'OpenSSL, le processus de sortie de la version 5.5 n'a pas permis de patcher la faille avant création de la distribution. Il faut ainsi patcher la libssl d'OpenBSD après mise à niveau/installation.

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Dogmazic a besoin de vous !

    Vendredi 2 Mai

    Bonjour à tous,

    L'Association Musique Libre qui porte le site Dogmazic.net change de projet. Le développement de la version 3 du site est trop coûteux en temps, en énergies, et en finances. L'association a donc décidé de recentrer ses activités vers du concret. Fini l'attente d'une hypothétique version 3 du site (le développement est toujours disponible sous licence libre et maintenu par son développeur sur github ). Nous avons décidé de nous recentrer autour de nos actions principales : les nouvelles informations autour de la musique libre, le forum, la documentation et notre archive 2004-2012.

    Pour cela, nous avons besoin de migrer vers un nouvel hébergeur nous correspondant mieux : Aquilenet. Malheureusement, nous avons beau être des musiciens, être sous diverses distributions Linux, et militants en faveur du libre depuis pas mal d'années, nous ne savons pas - encore - effectuer une migration de base de données et de sites complets.

    C'est pourquoi nous sollicitons vos bonnes volontés afin de nous y aider.

    Nous vous donnons rendez-vous sur notre chan IRC : irc.freenode.net #dogmazic (ou http://musique-libre.org:7778 )

    Merci !
    Aisyk pour l'Association Musique Libre !

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Pages