Linux France

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

Proxmox VE 3.3 mise sur la sécurité et une console HTML5

Lundi 1 Décembre

Proxmox VE est une solution de virtualisation serveur complètement open source basée sur KVM et des conteneurs. L'équipe Proxmox a annoncé la disponibilité de Proxmox VE 3.3 qui met l'accent sur le renforcement de la sécurité à travers un firewall et un système d'authentification à deux phases, ainsi que l'intégration d'une console HTML5.

Parmi les fonctionnalités notables attendues, on note :

  • Proxmox VE Firewall, complètement intégré avec l'interface graphique, cette fonctionnalité permettra aux administrateurs de mieux sécuriser les clusters, serveurs, ainsi que les conteneurs et les machines virtuelles.
  • Console HTML5 basée sur noVNC pour le Shell, les conteneurs et les machines virtuelles.
  • Authentification à deux phases avec mot de passe à usage unique (one-time password, OTP) et limité par le temps qui peut être basé sur OATH ou YubiKey
  • Prise en charge de QEMU 2.1
  • Nouveau noyau Linux, 3.10, basé sur Red Hat 7, la prise en charge d'OpenVZ reste pour le moment en suspens
  • D'autres mises à jour notables incluent la gestion de corosync et fence-agents.

Témoignages : Eric Blevins de la société KMI Learning (basée aux USA) utilise Proxmox VE sur 26 nœuds. Valentín Ortiz Ferretiz de la société Grupo Inversor Veracruzano S.A.P.I. (GRIVER) a déjà virtualisé 20 serveurs parmi leurs 50 serveurs physiques - lisez : http://www.proxmox.com/proxmox-ve/testimonials

Télécharger ce contenu au format Epub

Lire les commentaires

Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais

Dimanche 30 Novembre

Ce qui suit est la traduction d'un texte écrit par l'auteur de uselessd que j'ai trouvé particulièrement intéressant en ce qu'il ne cherche pas tant à déterminer qui des zélateurs ou des détracteurs de systemd a raison qu'à exposer pourquoi une telle question ne sera jamais tranchée.

Résumé pour le lecteur pressé ou saturé :

Nous assistons-là à une guerre culturelle, dans laquelle certains soutiennent que les baguettes c'est beaucoup mieux tandis que d'autres ne jurent que par couteaux et fourchettes, mais où personne ne parle en fait de la même cuisine. À la fin, ce sont ceux qui contrôlent la cantine qui vont gagner.

Sommaire Préface express du traducteur

On a encore vu récemment qu'il suffisait de mentionner systemd (sans même risquer un avis dessus) pour relancer un petit Verdun. Ceci n'aura donc pas la naïve prétention de faire asseoir le lion à côté de l'agneau, mais juste de donner à méditer à ceux qui sont las de tous ces pseudo-débats, éternellement reconduits à l'identique (dont, si on se pose la question, le traducteur lui-même se fout bien, étant depuis une décennie sous Slackware – comprendra qui lira).

Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais

L'écriture de ceci m'a été inspirée par les annonces récentes réclamant publiquement un fork de Debian, une idée que je trouve idiote et qui ne débouchera probablement pas sur énormément de travail technique.

Néanmoins, j'ai vu se dérouler le même débat sur systemd une fois encore. Je l'ai déjà vu un nombre incalculable de fois, et il n'y a eu virtuellement aucune variation par rapport à la formule type. Vous avez deux côtés ardents et bruyants, disposés grossièrement selon une dichotomie zélateurs/détracteurs, dont aucun n'a à dire quoi que ce soit d'éclairant avec cependant pour chacun son propre ensemble unique d'incompréhensions, qui ont mémétiquement muté en idées indépendantes empoisonnant virtuellement tout débat de cette nature.

J'évite largement les « débats » autour de systemd à présent. Ils me dépriment à cause de tous les raisonnements erronés et des détournements émergeant partout, mais j'ai senti que peut-être ce petit texte pourrait essayer d'expliquer le contexte et les causes amenant juste systemd à susciter autant de vitriol et de guerres de clochers.

Les erreurs habituelles faites par les zélateurs et les détracteurs

Les sophismes que font les détracteurs de systemd ont été mis en évidence tellement de fois qu'il n'est pas la peine d'en faire une revue exhaustive. Pour ce qui est de l'objet de cet exposé, nous relaterons en y répondant les arguments habituels pour et contre systemd, tels qu'ils se rencontrent dans presque toutes les « discussions policées et nuancées » à son sujet. Le but ici est de montrer que, contrairement à la croyance populaire, ce ne sont pas seulement les détracteurs, avec leurs agaçantes tirades sur la « philosophie Unix » et leur incrédulité technique, qui ont tort, mais qu'à peu près tous ceux impliqués dans cette dispute sont ignorants d'une manière ou d'une autre.

Les arguments idiots donnés par les supporters de systemd ont été largement laissés sans correction et libres de se propager de manière égale aux arguments idiots de leurs opposants, même si moins de monde le reconnaîtra. Cela a été le cas jusqu'à ce que, le 26 septembre 2014, Judec Nelson écrive un billet de blog exhaustif appelé « Systemd : les plus gros sophismes », qui est devenu énorme sur /r/linux et n'a reçu en comparaison que peu de réponses sur HN (NdT : Hacker News).

Jetons un œil à sa réception sur /r/linux.

Les commentaires les mieux évalués comprennent quelqu'un hurlant en retour « sophisme, sophisme », une réfutation partielle des arguments qui comporte des erreurs clés dans son raisonnement (comme échouer à distinguer le system d'init de ses scripts rc), et qui répond largement aux accroches des paragraphes mais pas aux élucidations plus profondes cachées à l'interieur, une personne qui fait une incohérence logique en répondant à une seule remarque d'une manière sans rapport avec son sens réel, un argument bidon sur la façon dont les gens devraient arrêter de crier au sujet des logiciels qu'ils préfèrent, et un peu de discussion positive ou nuancée mélangée partout dans tout ça. Très discutable est le vitriol rance jeté par un utilisateur qui qualifie l'auteur de « sale putain de troll manipulateur ».

Pour l'essentiel, nous voyons que presque tout le monde fait du mieux qu'il peut pour éviter de corriger quoi que ce soit, se mettant immédiatement sur la défensive.

Cela ne cherche pas à mettre en accusation les zélateurs de systemd, mais plutôt à montrer une chose : le débat autour de systemd est rarement une dispute technique quel que soit le côté, au lieu de cela, c'est une guerre idéologique et culturelle engagée entre deux populations opposées qui habitent la même sphère générale de Linux et du Libre. Ça n'est pas une question de qualités techniques, c'est une question de politique. Peu l'admettront, mais les gens qui se disputent ne sont pas réellement soucieux d'améliorer l'état des systèmes de gestion de processus. Ils sont impliqués dans un schisme philosophique sans précédent dans le logiciel libre, qui aura probablement quelques implications notables dans le futur. Les identités et les egos sont à l'œuvre ici.

En avant.

Architecture monolithique

« systemd est monolithique ! Il implémente tout dans PID 1 ! », dit le détracteur de systemd, en ayant tout faux.

« systemd n'est pas monolithique ! Songez aux 69 binaires ! », répond le zélateur de systemd, en ayant également tout faux.

Les disputes autour de l'architecture de systemd ont tendance à être des bouillies de jargon avec différentes interprétations, souvent avec des gens considérant que le caractère modulaire d'une chose la rend automatiquement non-monolithique. Le problème est que cela est en réalité correct selon certaines définitions. De l'autre côté, quelque chose étant et modulaire (à un degré au moins) et monolithique simultanément est également absolument possible et considéré comme une interprétation correcte pour divers logiciels tels X.Org, Busybox et le noyau Linux.

Cette espèce de guerre linguistique est typiquement ce qui détourne les esprits de certaines des décisions techniques les plus profondes prises par systemd, et conduit a des manques de compréhension mutuels auto-imposés. Les détracteurs refuseront souvent de lâcher le mensonge d'un énorme blob collé dans PID 1, mais les zélateurs refuseront pareillement d'admettre que la modularité de systemd n'est pas aussi étendue qu'elle pourrait l'être et que son PID 1 demeure quoi qu'il en soit plus gros que dans la plupart des autres systèmes.

Ce sale diable de Lennart

Souvent à l'initiative des détracteurs, qui vont se lamenter des horreurs de PulseAudio et mettre en évidence leur mépris pour Lennart Poettering. Cela est après coup devenu un faux prétexte habituel à l'usage des zélateurs pour balayer les critiques comme relevant d'attaques personnelles contre Lennart. Il est futile de même en discuter, mais c'est un élément important.

La personnalité de Lennart est en réalité, de temps en temps, un sujet pertinent. Essayer d'avoir une grande discussion autour de systemd sans l'invoquer est comme discuter du détail de la glibc sans jamais mentionner Ulrich Drepper. La plupart des gens prennent ça trop passionnément, de toute façon.

L'hypothèse d'un monde juste

Beaucoup des détracteurs de systemd vont s'exprimer au sujet d'une supposée prise de contrôle sur l'écosystème de Linux de la part de systemd, dans la mesure où ses auxiliaires (nécessitant tous d'être pilotés par l'init de systemd) exposent des APIs qui sont ensuite utilisées par d'autres logiciels de la pile bureautique, créant ainsi des liens de dépendance entre ceux-ci et systemd que les détracteurs jugent injustifiés. Ils vont aussi pointer du doigt la débâcle d'udev et citeront Lennart à l'occasion. Les détracteurs voient ça comme un comportement anti-compétitif et le compare à une pratique de type « adopter, étendre, étouffer ». Ils exagèrent souvent cependant et se laissent complètement emporter par leur vitriol à mesure qu'ils commencent sérieusement à envisager d'obscures conspirations chez Red Hat (il faut admettre que c'est plutôt drôle de prétendre que quiconque défend un logiciel est un homme de paille travaillant secrètement dessus, mais je digresse), laissant beaucoup de leurs sujets de préoccupation être ignorés et jugés ridicules par la même.

La modération est rarement de mise. La plupart des zélateurs essaient de convaincre en niant carrément toute interférence politique et en insistant sur le fait que systemd est adopté sur la seule base de ses qualités techniques et qu'un aussi large consensus parmi les distributions étant impossible à fabriquer, il doit y avoir derrière des raisons techniques valables qui montrent clairement la supériorité de systemd.

Aucun de ces points de vue n'est la stricte vérité. Il est très probable qu'il n'y a pas de conspiration de la part de Red Hat s'enracinant dans les bureaucraties de toutes les distributions (aussi amusant que cela sonne), mais dire que l'adoption de systemd est purement technique et pas du tout politique est également faux. Cela est particulièrement évident du fait qu'à peu près toutes les distributions (surtout Debian, cependant) ont une structure de gouvernement élaborée. Les décisions techniques et politiques s'entrecroisent très fréquemment (demandez juste à Microsoft ou à Oracle), et les logiciels libres ne sont pas nécessairement immunisés contre cela.

De plus, la communauté Linux est connue pour réinventer la roue carrée encore et plus encore. Le chaos est en même temps la plus grande force et la plus grande faiblesse de Linux. Vous vous souvenez de HAL ? L'adoption par les distros n'est pas tant l'indice que quelque chose est bon que du fait qu'il a suffisamment de publicité.

Cela dit, ce qui se passe n'est pas que les gens nient que des interférences politiques se produisent en matière de logiciel, mais plutôt qu'ils nient que cela arrive dans leur camp. Les détracteurs s'en rendent également coupables (comme lorsque Ian Jackson réouvre la résolution Debian sur systemd, ce qui était par nature brûlant, quelles qu'aient été ses intentions), même s'ils ne sont pas aussi influents.

S'attendre à ce que les débats autour de systemd n'impliquent rien de politique, en tant que tel, est plutôt auto-contradictoire. systemd est déjà le sujet le plus chargé politiquement dans l'histoire du logiciel libre, et ce n'est pas si arbitraire. Néanmoins, les deux côtés sont regrettablement obtus et nous analyserons plus tard leurs milieux types, pour comprendre pourquoi.

Portabilité

La portabilité des systèmes d'init est rare, principalement parce que les phases 1 (immédiatement après le lancement d'init(8) par le noyau) et 3 (extinction) sont intrinsèquement spécifiques au système. Ceci est également la cause pour laquelle il y a une forte prégnance philosophique dans la conception des inits, même si ce n'est que rarement exposé aussi explicitement.

Les zélateurs soutiennent avec raison que la non-portabilité de systemd est quelque chose de courant et que ce n'est pas un bon argument contre lui, mais les détracteurs mettent généralement en évidence les décisions politiques et la ramification des dépendances, en soutenant que systemd n'a pas besoin d'être un init et devrait juste être un superviseur de processus tournant au-dessus d'un init existant. Il y a des arguments à donner en faveur des deux options, même si l'architecture de systemd tend en général à en faire un init. Il fournit une plus grande sécurité contre les erreurs critiques au prix d'une surface plus large, contrairement à l'approche des daemontools où vous avez une séparation stricte entre la gestion du système et la gestion des services.

Pour autant que l'argument de la portabilité soit normalement un sophisme, l'exposition des APIs de systemd à l'usage d'autres paquets lui donne une pertinence. Bien sûr, « l'hypothèse d'un monde juste » joue un grand rôle ici, car du fait que cet argument est intrinsèquement politique, il est en conséquence souvent directement rejeté, générant encore un surplus de situations à se cogner la tête contre le mur (« Ce que nous avons ici est… une incapacité, à communiquer. Certains hommes, vous ne pouvez simplement pas les atteindre. » ) durant les débats.

C'est une question de choix

Généralement, un fier utilisateur de Gentoo, qui saisit l'importance de dérouler toutes les boucles lors de la compilation d'un paquet, va se lever et proclamer « Linux est une question de choix ! systemd s'immisce dans tous mes logiciels et confisque ma liberté de choix ! »

Il sera la plupart du temps immédiatement réfuté par quelqu'un l'envoyant sur islinuxaboutchoice.com, et allant même parfois jusqu'à lui expliquer pourquoi, en fait, le choix est une mauvaise chose et conduit au malheur. Si seulement nous avions tous voté pour le même parti politique, le monde serait meilleur.

Excusez les caricatures, mais le fond de tout cela est que ces deux approches sont fausses et ne conduisent nulle-part. Les zélateurs ont bon en ce que Linux n'est pas intrinsèquement une question de choix, mais ils ne parviennent également souvent pas à réaliser que la tradition Linux consistant à construire des systèmes en mélangeant et en ajustant des composants ouverts (du fait que Linux est seulement un noyau) a en fait joué un grand rôle dans la formation de sa culture, et est sans doute une raison pour laquelle beaucoup d'entreprises basent leurs infrastructures sur Linux, quand bien même il est couvert par une licence plus restrictive comparé aux BSDs.

Dans les faits, rien de cela n'a à voir avec le choix. Ce qu'on cherche réellement à dire est « ça casse les procédures de travail ».

Du cyanure dans la sémantique, ou la manipulation du langage

Il apparaît que beaucoup de gens ne savent même pas ce qu'est systemd. Je développe uselessd, et je ne sais pas non plus — sérieusement. Tout du moins, je ne peux penser à aucune explication concise qui décrirait proprement le champ d'application de systemd.

Lorsqu'ils se lamentent à propos de toutes les critiques (entendre : la haine sans limite) à propos de systemd, les zélateurs vont souvent demander « Pourquoi tant de gens se soucient-ils de l'init de leur système ? Je m'en moque, du moment que ça marche ! »

Les détracteurs feront alors entendre leurs préoccupations en disant quelque chose dans la veine de « Je n'aime pas la manière dont systemd gère tant de choses, telles que la connexion, les conteneurs, la locale, les comptes, les points de montage et d'auto-montage… »

Arrivé à ce point, une autre personne va crier « Mais systemd n'est pas qu'un système d'init, c'est un ensemble de démons et de services pour un système d'exploitation basé sur Linux ! »

En fait, nous verrons systemd compris tour à tour comme étant :

Habituellement, quand ses zélateurs essaieront de défendre systemd, ils vont insister sur le fait que c'est « juste un système d'init », mais quand ils seront contredits ils mentionneront à la place une des définitions plus larges.

Toutes les définitions ci-dessus sont techniquement correctes. Aucune d'entre elles n'est complète.

C'est ainsi que les débats sont condamnés à ne mener nulle part, dans la mesure où personne ne peut s'entendre sur une unique définition de systemd, et les développeurs n'ont aidé vraiment en rien en la matière. Être vague peut être une force, en ce que cela permet aux gens de diviser pour régner, mais c'est également improductif et conduit à des carnages inutiles. En sus, être vague donne carte blanche pour balayer les réserves et consolider les fonctionnalités, tout en entraînant aussi beaucoup d'ignorance chez les détracteurs comme chez les zélateurs.

Les temps de démarrage en toute justice

Les détracteurs de systemd partent fréquemment du principe que la seule raison pour laquelle les gens l'aiment tient dans ses temps de démarrage plus courts. C'est faux, même si le fait que ses fans vantent beaucoup cet aspect n'aide certainement pas, et ce bien que les développeurs de systemd eux-mêmes découragent l'utilisation de cet argument, insistant à la place sur la « bonne conception » à laquelle cela est dû (et ainsi le cycle des guerres ouvertes se poursuit).

Les développeurs reconnaissent que les temps de démarrages ne sont par défaut pas aussi fulgurants qu'ils pourraient l'être, et avec les années la plupart des distros Linux ont accumulé beaucoup d'expédients comme insserv et startpar, qui ont amélioré les performances de SysV en accélérant son exécution sérielle par des expédients de parallèlisation passant par le démarrage des services en tâches de fond.

La philosophie Unix

La philosophie Unix est elle-même un gigantesque champ de bataille. Elle est remarquablement chargée d'un point de vue politique. Beaucoup de gens seront d'accord avec une grande partie de ses principes si vous les présentez individuellement, et de fait une partie d'entre eux est devenu synonyme de « bonne conception », mais si vous les mentionnez derrière le paravent « philosophie Unix », les ennuis vont commencer.

La plupart des détracteurs de systemd essaient de convaincre en hurlant aveuglément « Phylozofie Hunixe » comme si cela signifiait quoi que ce soit sans élaborer un peu le sujet, mais beaucoup de zélateurs sont par ailleurs inhabituellement hostiles à son égard et la mécomprennent eux aussi. Une réfutation habituelle comme « Linux n'est pas Unix » est correcte uniquement du point de vue de la licence en ce que, en effet, Linux n'est pas une licence d'Unix. Cela n'invalide pas le fait que son architecture a intrinsèquement à voir avec celle d'un Unix.

Un courriel de réponse de la part de Lennart Poettering, que nous avons reçu à la suite d'une enquête de l'un des membres de notre forum, disait ce qui suit :

« Tout cela étant dit, je suis presque sûr que systemd amène Linux beaucoup plus près d'Unix que Linux ne l'a jamais été. Tous les vrais Unixes actuels (comme FreeBSD, Solaris, …) sont maintenus dans un lieu centralisé, en partageant l'infrastructure des dépôts de code, les cycles de vie et les schèmes de publication pour tous leurs composants, peu importe que ce soit le noyau, la libc, ou le reste de l'espace utilisateur. Sur les vrais Unixes, il est beaucoup plus facile de patcher le long de la pile entière depuis le noyau à jusqu'à l'espace utilisateur, parce que tout provient de la même source, et suit les mêmes cycles. Les vrais UNIXes ont tendance à paraître plus uniformes car les mêmes gens travaillent sur toute la pile, les choses sont faites d'une même main. Linux a toujours été différent, nos composants sont maintenus indépendamment, dans des dépôts différents, avec des styles de code différents, par des gens différents, suivant des cycles de publication différents. Ils sont maintenus plus ou moins bien, une bonne partie de notre pile est en réalité traditionnellement très mal maintenue, voire pas du tout.
« 
« Avec systemd nous essayons de trouver une sorte d'entre-deux, aller vers un schème plus proche d'UNIX sans tout coller dans le même dépôt comme le fait UNIX, mais seulement les éléments essentiels de l'espace utilisateur. Mais même au-delà des éléments de procédure, il y a beaucoup de domaines où systemd est plus proche des UNIX traditionnels que Linux ne l'a été. Par exemple, un des mantras d'Unix est « tout est fichier » (ce qui, au passage, est plutôt faux, car mon imprimante n'est pas un fichier, pas du tout), et on pourrait dire que systemd donne à voir l'un des concepts les plus fondamentaux d'un système Unix, à savoir les services/démons en tant que fichiers via la logique des cgroups. Donc ouais, si vous prétendez que nous ne somme pas UNIX, je vous dirais que nous sommes en réalité sous bien des aspects beaucoup plus proches d'Unix que nous ne l'avons jamais été.
« 
« Je suis presque sûr que la plupart des gens qui répètent constamment comme des perroquets que systemd n'est pas proche d'Unix n'ont en réalité aucune idée de ce qu'est vraiment UNIX… »

Apparemment, ce que Lennart a retenu d'Unix est qu'il est « développé au sein d'un unique dépôt » (bien que cela n'ait jamais été un pré-requis strict, c'est juste que les noyaux individuels des systèmes d'exploitation n'ont auparavant jamais vraiment décollé à la manière de Linux) et que systemd est plus unixifié que n'importe quoi avant lui parce qu'il utilise les cgroups… même si on doit la conception de cgroupsfs aux développeurs du noyau et pas à systemd (à eux et au système de fichiers à contrats de Solaris, qui a probablement été une source d'inspiration majeure pour les cgroups). De plus, il nous éclaire sur le fait que son imprimante n'est pas un fichier. À l'évidence, Lennart n'a jamais entendu parler de 9P (NdT : Plan 9 Filesystem Protocol), qui est un exemple de protocole simple ayant été mis en application avec succès pour exposer à peu près tous les ressources et services du système en tant que systèmes de fichiers virtuels, les rendant pilotables avec les appels système les plus basiques manipulant les descripteurs de fichiers.

Écrire une alternative

Après beaucoup d'arguties quelqu'un va tout simplement finir par lâcher que si les détracteurs n'aiment pas systemd, ils devraient lui écrire une alternative.

Bien entendu, au minimum plus au moins une douzaine de celles-ci existent déjà. Que signifie en réalité « Écrire une alternative » ?

systemd est vraiment au sein de l'espace utilisateur la couche intermédiaire qui prend place entre GNU et Linux. J'ai aussi entendu systemd comparé aux serveurs d'un micro-noyau, d'une manière très proche du Hurd. Cela a en fait plus de sens qu'il n'y paraît au premier regard, et avec les anciens composants du noyau comme la console Linux qui sont en train d'être déportés vers l'espace utilisateur (d'abord en tant que kmscon, puis en tant que systemd-consoled — ce qui n'implique pas que ce soit mauvais, au passage), cela donne quelque crédit à l'idée. Les composants de systemd implémentent souvent d'anciens outils indépendants en tant que démons auxiliaires, programmables.

En tant que tel, pour que quelqu'un écrive une alternative à systemd, un second systemd doit pour l'essentiel être écrit.

Ceci est déjà un dilemme insoluble, car c'est précisément ce que les détracteurs ne veulent pas. Beaucoup des anti-systemd techniquement compétents souscrivent à des philosophies entièrement différentes, comme l'approche des daemontools ou autre chose.

Plus encore, beaucoup ignorent qu'écrire un second systemd serait un risque énorme. Faire de la programmation système de bas niveau et de la plomberie en espace utilisateur n'est pas comme programmer des applications pour l'utilisateur final. Un superviseur de processus et un traitement de texte sont complètement différents. Le dernier peut-être remplacé très facilement s'il ne convient pas, le premier requiert une intégration et a des ramifications fondamentales dans la manière dont on interagit avec un système d'exploitation donné. La tâche n'est pas aisée et risque fort d'être entièrement vaine. Beaucoup de gens coderait plus volontiers des projets personnels plutôt que faire l'effort d'écrire de tels systèmes qu'ils pensent être largement compensés par des outils séparés et discrets (sans doute en ont-ils écrit certains).

De ce ce point de vue, l'argument « implémenter une alternative » conduit seulement à empoisonner les débats avec l'assomption implicite que la philosophie de systemd est bonne, rendant ainsi les choses encore largement plus politiques.

sysvinit : l'éternelle muleta

Il semble que par une sorte de destinée divine, tout débat autour de systemd se mue en dispute stérile autour des avantages de systemd sur sysvinit. Les zélateurs vont joyeusement parler des fonctionnalités géniales de systemd qui ont remplacé la base des affreux scripts shell, alors que les détracteurs vont proclamer la supériorité de sysvinit dûe à son minimalisme et à sa flexibilité infinie du fait qu'il délègue les services à un langage de commande interprété et Turing-complet.

Tous ont faux et manquent totalement l'essentiel.

Le constat que sysvinit est idiot et défectueux avec ses abstractions vieillotes comme son inittab et ses niveaux d'exécution n'est absolument pas nouveau. Richard Gooch a écrit un article dès 2002 intitulé « Les scripts de démarrage Linux, qui critiquait les approches de SysV et de BSD, en se basant sur son précédent travail sur simpleinit(8). Cela dit, sa solution restait fermement ancrée dans les philosophies de SysV et de BSD, mais il rendait ça plus élégant en fournissant des bases de modularité et en exprimant les dépendances.

Même avant cela, DJB (NdT : Daniel J. Bernstein) a écrit la fameuse suite des daemontools, qui a eu beaucoup de successeurs influencés par son approche, notamment s6, perp, runit et daemontools-encore. Les deux premiers sont des implémentations complètement indépendantes mais basées sur des principes similaires, avec il est vrai des améliorations significatives. Un article daté de 2007 intitulé « Les scripts d'init considérés comme néfastes » encourage cette approche et critique les scripts d'init.

Aux alentours de 2002, Richard Lightman a écrit depinit(8), qui a introduit le démarrage parallèle des services, un système de dépendances baptisé « groupes de services » au lieu de « niveaux d'exécution » (similaires aux « cibles » de systemd), sa propre logique de démontage des périphériques à l'extinction, des redirections arbitraires entre démons à des fins de journalisation, et plus encore. Il n'a pas réussi à se populariser et c'est maintenant une relique historique.

D'autres systèmes comme initng et eINIT sont venus après cela, lesquels étaient basés sur des architectures hautement modulaires à base de plugins, et implémentaient une grosse partie de leur logique en tant que plugins, pour une large palette d'actions que des logiciels comme systemd implémentent comme parties inamovibles de leurs socles. Quelqu'un pour parler d'Initmacs ?

Même Fefe, activiste anti-bloat phénoménal a écrit auparavant son propre système appelé minit, qui pouvait gérer les dépendances et le démarrage automatique. Comme d'habitude avec les logiciels de Fefe, c'est très douloureux à lire, vous donnant envie de vous faire seppuku avec une roulette à pizza.

Et tout ça juste pour Linux. Une liste partielle, évidemment.

En tout et pour tout, la comparaison avec sysvinit ne fait que montrer que vous avez vécu dans une grotte pendant des années. Qui plus est, il n'est un secret pour personne que la manière dont les distros ont pendant des années rédigé les scripts d'init a été une hérésie vis à vis des pratiques de base du développement, comme la modularisation et la réutilisation des fonctions communes. Cela parmi d'autres problèmes tels l'usage inadéquat d'abstractions déjà trouées comme start-stop-daemon(8). Même si sysvinit encourage jusqu'à un certain point un mauvais travail comme celui-là, ce sont les mainteneurs des distros qui porte le gros de la faute pour le désordre. Regardez les BSDs pour un bon exemple d'écriture de scripts d'init. OpenRC a été directement inspiré de l'exemple des BSDs. Astuce : c'est dans le nom – « RC ».

Le champ d'application plutôt énorme de systemd et son caractère intransigeant conduisent des gens à regretter l'époque de sysvinit. Une bonne part de cela tient à leur ignorance des bons principes de conception, mais pour beaucoup c'est aussi motivé par l'inaptitude à communiquer leur désir pour des systèmes simples et transparents. De la sorte, zélateurs et détracteurs sont pris dans des boucles de rétroaction consistant à ne déboucher sans cesse nulle part en partant en guerre ouverte autour d'une implémentation d'initd (qui s'est trouvée dominante) tout en ignorant complètement toutes les recherches précédentes sur l'amélioration des inits, dans la mesure où celles-ci ont toutes été au final abandonnées au sol. Plus encore, la plupart des gens n'arrivent pas à distinguer l'init des scripts rc et tiennent en quelque sorte sysvinit pour un équivalent des pauvres scripts que les distros ont écrits, et de tous les trucs qu'elles ont bricolés par dessus comme les en-têtes LSB ou startpar(2). C'est une mécompréhension majeure qui entraîne la perte de beaucoup d'énergie.

Ne discutez pas de sysvinit. Discutez de systemd à partir de ses propres qualités et des avantages ou désavantages de sa manière de résoudre les problèmes, ce en le mettant potentiellement en contraste avec d'autres systèmes d'init. Mais ne commencez pas immédiatement avec « les scripts d'init de SysV étaient une approche meilleure et bien plus configurable, je ne vois pas ce que systemd contribue à résoudre au-delà de temps de démarrage plus courts », ou de l'autre côté « systemd est une meilleure approche que sysvinit, regardez comme les unités sont propres comparées à ce script épouvantablement écrit que j'ai glané ! Pourquoi ne changeriez-vous pas ? »

Les milieux culturels et techniques des zélateurs/détracteurs

Maintenant que nous avons mis en évidence comment les débats autour de systemd se déroulaient en pratique et pourquoi y prendre part est habituellement une colossale perte de temps, faisons un grossier survol des personnalités qui rendent ce bordel possible.

Les parties techniquement compétentes tendent largement à tomber dans ces deux larges catégories :

  1. les zélateurs sont généralement montés dans le train du Bureau Linux moderne. Ils tournent avec les distributions dominantes contemporaines et les derniers logiciels, utilisant en y contribuant les initiatives des gros environnements de bureau et de leurs standards associés comme les *kits. Ils ne sont pas nécessairement focalisés sur le bureau Linux. Ils travaillent souvent sur des fonctionnalités destinées à la gestion des serveurs d'entreprise, à l'informatique dans les nuages, aux systèmes embarqués, et à d'autres besoins, mais la rhétorique selon laquelle on a besoin d'un meilleur bureau et qu'il faut suivre les exemples de Windows et d'OSX est largement répandue dans leurs rangs. Ils vont dénoncer ce qu'ils considèrent comme des « échecs d'intégration », de la « fragmentation », et sont généralement hostiles à l'égard des projets de recherche et de tout ce qu'ils perçoivent comme des « projets gadgets ». Ce sont des hackeurs, mais leur tournure d'esprit est largement orientée vers la réduction de la complexité des interfaces au lieu de celle des implémentations, et ils argumenteront souvent contre les prétendus dangers de trop de configurabilité, tout en regardant les ordinateurs comme des applications plutôt que des outils.
  2. les délateurs sortent de milieux un peu plus variés, mais viennent typiquement de distributions plus de niche comme Slackware, Gentoo, CRUX, et autres. Ils sont largement inintéressés par les « avancées » du bureau Linux, apprécient la configuration, le minimalisme, et se soucient plus de la malléabilité que de la convivialité. Ils sont souvent familiarisés avec beaucoup d'autres environnements apparentés à Unix en plus de Linux, bien que ce dernier garde leur faveur. Ils ont leurs propres projets fétiches et sont enclins à utiliser, à contribuer, ou au moins à suivre plein de petits projets dans le domaine de la plomberie système de bas niveau. Ils peuvent aller jusqu'à nommer au moins une douzaine d'alternatives aux GNU coreutils (je peux en nommer à peu près 7, je pense), approuvent généralement les principes Unix traditionnels et regardent les ordinateurs comme des outils. Ils sont les personnes les plus enclines à avoir de la sympathie pour des choses comme la philosophie suckless.

Il ne devrait être une surprise pour personne que le premier groupe est dominant. Ce sont eux qui façonnent largement l'expérience de l'utilisateur final. Par contraste, le second groupe est plutôt insensible à cet égard, voire critique. Qui plus est, le premier groupe a beaucoup plus de ressources humaines placées aux bons endroits. Les employés de Red Hat à eux seuls dominent le gros du noyau Linux, le système de base GNU, GNOME, NetworkManager, beaucoup de projets affiliés aux standards Freedesktop.org (Polkit, notamment) et plus encore. Il n'y a aucun moyen de concurrencer un vaste groupe d'individus rémunérés comme celui-ci.

Conclusion

« L'année du bureau Linux » est devenu un mème à présent, utilisé le plus souvent sarcastiquement. Cependant il demeure des gens qui y tiennent profondément et pensent que si seulement Linux avait un bon moteur d'abstraction pour les soubassements des gestionnaires de paquets, tous ces utilisateurs Windows tourneraient sous Fedora en un rien de temps.

Ce à quoi nous assistons est certainement un choc culturel entre deux pôles opposés qui coexistent dans la communauté Linux. Nous pouvons le voir en œuvre à travers le vitriol jeté sur les développeurs de Red Hat, et inversement dans la dérision envers les utilisateurs de Gentoo de la part de Lennart Poettering, Greg KH. et autres. Même s'il apparaît dans ce cas que « utilisateurs de Gentoo » est utilisé comme une métonymie pour les utilisateurs de Linux dont les besoins sortent de la palette des applications dominantes. Theo de Raadt a autrefois fielleusement ironisé sur le fait que Linux était pour « les gens qui détestent Microsoft », mais cette citation commence à présent à dater.

Beaucoup des gens les plus techniquement compétents avec des opinions critiques sur systemd sont restés plutôt silencieux en public, pour quelque raison. Probablement qu'ils réalisent que la direction prise par le Bureau Linux est inévitable et qu'en conséquence la critiquer est une entreprise futile. Il y a des gens qui pensent toujours que l'abandon de Sawfish par GNOME a été une erreur, donc oui.

Les gens qui ne se sentent pas concernés par le bureau ont encore leur propre espace, mais se sentent menacés par systemd à un degré ou à un autre. Reste que, personnellement, je ne vois pas leur nombre décroître. Ce que je crois qu'il va se passer, c'est qu'ils vont devenir encore plus ségrégués qu'il ne le sont déjà par le Linux dominant et qu'utiliser leurs logiciels va avoir l'air de plus en plus décalé à mesure que le temps passera.

Beaucoup prédisent une grande renaissance de BSD dans le sillage de systemd, mais je suis sceptique à ce sujet. Il y aura sans doute un gain d'intérêt, mais au total il semble que la majorité de la population anti-systemd s'investit encore profondément à rester sous Linux.

En tout dernier lieu, la cruelle ironie est que systemd, dans sa tentative de supposément unifier les distributions, a créé comme aucun autre un immense fossé et a exacerbé à des degrés absolument anormaux les hostilités latentes entre le camp du bureau Linux et celui du Linux minimaliste. Ce qui va advenir de systemd demeure inconnu. Étant donné l'inclination de Linux au chaos, il pourrait devenir le nouveau HAL, avec cependant des conséquences significativement plus pénibles, ou il pourrait poursuivre son gai bonhomme de chemin et devenir un standard Linux gravé dans la pierre, auquel cas la communauté Linux connaîtra une division idéologique intense. Ou peut-être pas. Peut-être que les choses vont continuer comme d'habitude suivant une spirale infinie de réinventions sans climax. Peut-être serons-nous condamnés à nous déchirer sur systemd pour toute l'éternité. Peut-être finalement nous en dégoûterons-nous et poursuivrons-nous nos propres chemins dans des directions différentes.

En tous les cas, je deviens de moins en moins adepte de politique concernant uselessd et je vois métaphoriquement les débats autour de systemd comme les accidents de voiture. Je n'y apporte probablement rien mais j'y participe de temps en temps, bien que je destine uselessd à tracer son propre chemin avec le temps.

© 2014 MrSpackMan (pour la présente traduction).
© 2014 the author/developer of uselessd (pour le texte originel).

Redistribution and use in source (SGML DocBook) and 'compiled' forms (SGML, HTML, PDF, PostScript, RTF and so forth) with or without modification, are permitted provided that the following conditions are met:

  1. Redistributions of source code (SGML DocBook) must retain the above copyright notice, this list of conditions and the following disclaimer as the first lines of this file unmodified.
  2. Redistributions in compiled form (transformed to other DTDs, converted to PDF, PostScript, RTF and other formats) must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

THIS DOCUMENTATION IS PROVIDED BY THE AUTHOR "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Télécharger ce contenu au format Epub

Lire les commentaires

Journée d'introduction au logiciel libre Rudder le 11 décembre !

Vendredi 28 Novembre

Rudder est un logiciel libre qui permet aux entreprises de déployer automatiquement des configurations sur leur Système Informatique et de vérifier qu’elles sont bien appliquées, de mettre à contribution toute leur équipe à l’automatisation, et de prouver la bonne application des règles de conformité.

Normation organise en ses locaux le jeudi 11 décembre de 9h à 17h30 une Journée d'introduction à Rudder afin de faire découvrir cet outil à ceux qui en ont déjà entendu parler et qui souhaitent en savoir plus, voire à ceux qui ont déjà envisagé de l’adopter dans leur entreprise ou encore à ceux qui ont une sensibilité Devops !

La journée débutera autour d’un petit déjeuner et se poursuivra par un tour d’horizon du domaine de l’automatisation en passant entre autre par le mouvement Devops, puis nous verrons comment se positionne Rudder dans tout ça.
Après le déjeuner, les participants l’installeront sur leur machine et pourront en découvrir les fonctionnalités et ses cas d’application grâce à l’aide d’un des experts de Normation.
En fin de journée, des ateliers libres sont organisés selon les intérêts de chacun afin de pouvoir répondre à des problématiques précises que les initiés pourraient avoir. La journée se clôturera autour d’un apéritif, ce moment sera l’occasion de discuter, débriefer, débattre autour d’un verre :-) !

Pour profiter au mieux de cette initiation à Rudder, les participants devront être familiers à GNU/Linux en ligne de commande et comprendre les principes de base de l’administration système. Aussi, ils devront bien entendu être munis d’un ordinateur portable sur lequel il est possible d’installer une ou deux machines virtuelles GNU/Linux (distributions Debian, Ubuntu, CentOS, Red Hat ou SLES).

Le petit déjeuner, café/thé et le déjeuner seront fournis sur place.

Programme :

9h00 - 9h30 : accueil autour d’un petit-déjeuner
9h30 - 10h45 : présentation du domaine et de Rudder
10h45 - 11h00 : pause café
11h00 - 12h30 : faisons connaissance avec Rudder
12h30 - 14h00 : déjeuner sur place
14h00 - 15h30 : tour d’horizon des configurations possibles avec Rudder
15h30 - 15h45 : pause café
15h45 - 16h30 : comment administrer l’outil ?
16h30 - 17h30 : ateliers libres selon les intérêts de chacun (quelques idées : reporting, création de techniques, approfondissement de l’outil…)
17h30 : clôture de l’événement autour d’un apéritif / discussion

Informations Pratiques :

Normation
87 rue Turbigo,
75003, Paris

Métro République ou Temple : lignes 3, 5, 8, 9 ou 11.

L'inscription se fait en ligne et obligatoirement à l'avance. 20€ de participation aux frais seront demandés pour couvrir les frais d’organisation. Le nombre de places étant limité, il est recommandé de s'inscrire dès que possible. Toutefois, si vous souhaitez venir et que cette date ne vous convient pas, d’autres sont proposées sur le site jusqu’en février.

Télécharger ce contenu au format Epub

Lire les commentaires

Install-Party Linux et Logiciels Libres à Lunel le 29 novembre 2014

Jeudi 27 Novembre

Une journée GNU/Linux Install-Party est organisée le samedi 29 novembre de 10h00 à 17h00 au 520, avenue des Abrivados, 34400 Lunel.

Bus Ligne 1, 2 et 3. Au départ de Montpellier T.E.R. Languedoc-Roussillon et de Castelnau-le-Lez station ND de Sablassou Hérault Transport ligne 101.

GPS : Latitude : 43.668982 | Longitude : 4.127814

Programme :

  • Rencontres des utilisateurs expérimentés des systèmes basés sur des logiciels libres et des novices.
  • Installer, configurer et agrémenter de nombreux logiciels, le tout gratuitement, librement et légalement avec l’association Montpel’libre.

Selon notre habitude, le matin nous vous proposerons un Café Numérique qui vous permettra de comprendre les nombreux avantages d’utiliser un système libre, de comprendre comment maintenir votre ordinateur et enfin choisir un environnement de bureau parmi les sept que nous vous présenterons, Unity, Gnome, KDE, Xfce, LXDE, Cinnamon et MATE. L’après-midi, nous procéderons ensemble à l’installation du nouveau système sur votre ordinateur.

Entrée libre et gratuite.

Télécharger ce contenu au format Epub

Lire les commentaires

Les jeux libres en liesse !

Jeudi 27 Novembre

Les jeux libres sont en liesse : en effet, voici un nouveau CD de jeux libres proposé par l'association LanPower, le premier CD de la sixième série. Pas moins de 19 jeux sont donc à l'affiche dont 4 provenant de contributeurs au site Linuxfr.org : CatchChallenger, FreeDink, Le Camion frigorifique et Power Manga. Voilà de quoi bien s'amuser avec les enfants à Noël.

Voici la liste des jeux sélectionnés :

  • Blubbels ;
  • Bombermaan ;
  • Bygfoot ;
  • CatchChallenger ;
  • CG Madness ;
  • FooBillard ;
  • FreeDink ;
  • IceBreaker ;
  • Lbreakout2 ;
  • Le Camion frigorifique ;
  • Mu-cade ;
  • Njam ;
  • Pax Britannica ;
  • Pengupop ;
  • PixFrogger ;
  • Power Manga ;
  • Super Methane Brothers ;
  • Vdrift ;
  • Z-lock.

Ce CD n'est pas destiné à être vendu, mais vous pouvez acheter nos précédents CD/DVD sur EnVenteLibre.

Note : le live CD de jeux dédié aux contributeurs du site Linuxfr.org n'étant pas prêt, le deuxième CD de l'année proposé par l'association est donc un CD Windows.

Télécharger ce contenu au format Epub

Lire les commentaires

Sortie de GLPI 0.85

Mercredi 26 Novembre

Après plusieurs mois de développement, l’équipe du projet GLPI a le plaisir de vous annoncer la sortie de GLPI version 0.85. Pour rappel, GLPI est une solution open-­source de gestion de parc informatique et de servicedesk, GLPI est une application Full Web pour gérer l’ensemble des problématiques de gestion de parc informatique : de la gestion de l’inventaire des composantes matérielles ou logicielles, à la gestion de l’assistance aux utilisateurs.

Beaucoup de nouveautés attendues depuis longtemps sont maintenant présentes dans cette dernière mouture, comme la prise en compte complète de la norme ITIL (ce qui inclut la gestion des changements) ou encore l'intégration de la gestion de projets directement dans le cœur de GLPI.

Voici une liste non exhaustive des nouveautés offertes par cette version :

  • servicedesk : gestion des changements ITIL ;
  • servicedesk : gestion de projets, tâches et graphiques de Gantt ;
  • servicedesk : amélioration de la gestion des SLA ;
  • inventaire : composants inventoriables ;
  • général : refonte de la gestion des profils et des droits ;
  • général : amélioration de l’import et de la création des tickets par mail ;
  • général : import, export et copie des règles ;
  • général : amélioration du système de notification par mail ;
  • général : système de rotation des logs ;
  • général : export en PDF en UTF8 ;
  • général : traduction des intitulés et des articles de bases de connaissances ;
  • général : photos des utilisateurs ;
  • ergonomie : migration vers la bibliothèque Jquery ;
  • et de nombreuses autres améliorations et corrections qui correspondent à plus de 105 tickets…
Télécharger ce contenu au format Epub

Lire les commentaires

Le projet Linux From Scratch déménage

Mercredi 26 Novembre

Nous vous l'annoncions depuis la rentrée, c'est désormais chose faite: la traduction du projet Linux From Scratch a déménagé ! Elle a quitté son gentil hébergeur traditionnel, Traduc.org, après dix ans de collaboration constructive et riche, pour rejoindre ses origines. La traduction est désormais hébergée directement sur les serveurs de LFS. A la clé, une intégration accrue pour un meilleur support, un travail d'équipe renforcé, une dépendance envers le projet source et non plus envers l'association qui le traduit.

Concrètement cette migration signifie que les adresses Web changent. Pour le site, allez désormais sur www.fr.linuxfromscratch.org qui sera le seul officiel et à jour. Pour le svn, c'est svn://svn.linuxfromscratch.org/fr-lfs

Tous les traducteurs sont invités à modifier les adresses de référence au projet francophone en conséquence. Tous les utilisateurs et lecteurs sont invités à mettre à jour leurs marque-pages.

Nous sommes en tout cas fiers de rejoindre au plus proche la grande famille à l'heure où elle vit des instants clés, liés à Systemd et après l'épisode clfs. Nous sommes la synthèse de toute cette histoire et espérons poursuivre avec l'équipe nos échanges.

N'hésitez pas à commenter, diffuser la nouvelle autour de vous!

Télécharger ce contenu au format Epub

Lire les commentaires

DragonFly BSD 4.0

Mercredi 26 Novembre

Après 3 RC, DragonFly BSD 4.0 a été annoncée par Justin Sherril. Elle est disponible au téléchargement en version finale depuis le 26 novembre 2014. Cette version comprend notamment la prise en charge des GPU de la famille Haswell ainsi que le support d'OpenGL et un nouveau générateur de nombres pseudo-aléatoires pour /dev/random. Plus d'informations se trouvent dans la suite de la dépêche.

Sommaire


DragonFly BSD 4.1 (version de développement) tournant sur un portable Thinkpad T420 avec environnement X et Xfce, via le pilote i915. Hammer est utilisé en tant que système de fichier principal.

Noyau Ajout de /dev/upmap et /dev/kpmap

Les fichiers spéciaux de périphériques /dev/upmap et /dev/kpmap ont été ajoutés. Ces deux périphériques projetables en mémoire avec mmap(2) permettent d'accéder à un espace mémoire partagé par processus ou global au noyau. L'objectif ici est de permettre l'obtention d'information de manière plus efficace qu'en passant par un appel système plus coûteux. Le fonctionnement est différent de VDSO sous Linux mais le but identique : éviter des appels systèmes. Alors que /dev/upmap est accessible en écriture et permet un mappage par processus utilisateur, /dev/kpmap est en lecture seule et peut être utilisé pour le mappage par CPU au niveau du noyau.

Le but initial était de répondre au même besoin que la fonctionnalité INHERIT_ZERO introduite par OpenBSD pour régler les problèmes liés aux générateurs de nombres pseudo-aléatoires en espace utilisateur. En effet, la bibliothèque de génération de nombres aléatoires conserve une amorce d'entropie dans un tableau, qui est utilisée comme état du générateur. Mais quand le processus forke, il faut réinitialiser cet état en obtenant de l'entropie auprès du noyau pour éviter que les nombres générés par le processus fils soient les mêmes que ceux générés par le processus parent, sinon cela pourrait mener à des failles de sécurité dans les logiciels utilisant le genérateur.

L'idée naïve consiste à conserver le numéro de processus (PID) de la dernière réinitialisation, et d'utiliser getpid() pour détecter un fork. Toutefois, comme les PID peuvent être réutilisés, il existe une petite (mal)chance en cas de double fork pour que le générateur ne soit pas réinitialisé. INHERIT_ZERO permet d'indiquer au noyau que des pages mémoires doivent être remplacées par des zéros lors d'un appel de fork. Mais cette solution n'a pas été jugée satisfaisante car elle introduit de la complexité dans le sous-sytème de gestion de la mémoire virtuelle pour une utilisation très limitée. À la place, la page umap contient un compteur qui est incrémenté à chaque fois que le processus fork. Ainsi, en comparant la valeur du compteur conservée dans l'état du générateur avec la valeur courante, il est possible de décider s'il faut le réinitialiser.

Ce mécanisme est en outre plus général et les 4 Kio de la page umap sont utilisés pour d'autres données. getpid(2), setproctitle(3) et clock_gettime(2) ont été adaptés pour tirer profit de cette nouveauté. Dans les faits, lorsque plus de 10 appels sont effectués sur l'une de ces fonctions, la prise en charge de upmap/kpmap est activée et les informations demandées sont obtenues via une projection en mémoire plutôt que via des appels système. Cela contribue grandement à réduire l'overhead de ces appels. À noter toutefois que gettimeofday(2) reste quant à lui un appel système, et devrait normalement le rester afin de pouvoir produire une valeur temporelle plus précise. Il est donc préférable, question performance, d'utiliser clock_gettime() plutôt que gettimeofday() lorsqu'un haut niveau de précision n'est pas nécessaire.

Ajout de reapctl(2) procctl(2)

L'appel système reapctl(2) a été ajouté par Matt Dillon, puis finalement renommé en procctl(2), afin de permettre de gérer le processus de contrôle des sous-processus.

Pour comprendre la raison du renommage, un bref historique est nécessaire. Baptiste Daroussin, membre de la core team FreeBSD et peut-être plus connu sous le pseudonyme Bapt (notamment sur LinuxFr.org), ne souhaitant pas réinventer la roue était venu demander sur le channel IRC du projet DragonFly si un équivalent des contrats Solaris existait déjà chez DragonFly. Matt Dillon ne connaissant pas les contrats Solaris, une discussion à la fois technique et sur la raison de la demande s'en est suivie, suite à quoi il proposa d'implémenter tout cela selon la discussion. « Cela me prendra 4 bonnes heures à écrire » avait-il dit, mais voilà que 2 heures plus tard, le code était poussé dans master. Pour la petite histoire, Markus Pfeiffer estimait la charge à environ 2 jours de travail pour lui, alors que Baptiste Daroussin pensait pouvoir implémenter cela en 1 mois ! Pour citer Justin Sherrill, qui s'occupe des releases de DragonFly, « Dillon is a special case : he sneezes and accidentally writes a program », que l'on pourrait traduire par « Dillon est un cas spécial : il éternue et écrit un programme accidentellement ».

Le renommage est donc intervenu par la suite, afin d'harmoniser les API de FreeBSD et DragonFly, alors que Bapt s'occupait d'intégrer cela dans FreeBSD et qu'après discussions avec d'autres développeurs FreeBSD, il a été choisi d’intégrer cela a procctl(2), apparu dans FreeBSD 10 et créé justement afin de fournir un appel système permettant de gérer les processus.

Afin d'expliquer cela, il faut savoir que sous Unix, chaque processus possède un processus père. Quand il se termine, c'est ce processus père qui va examiner son code de retour par une opération nommée reap. C'est le rôle des appels systèmes wait(2), waitpid(2), etc. Si le processus fils est toujours vivant quand le processus père termine, un nouveau père est désigné : il s'agit en général du pid 1, init. C'est ainsi que fonctionnent les démons, qui sont détachés et rattachés à init.

L'appel système procctl(2) permet de désigner le processus courant comme le processus auquel chaque descendant va être réattaché si son parent meurt avant lui. Il fonctionne récursivement, et peut être utilisé par un processus non privilégié. Il est à noter que linux possède déjà une fonctionnalité similaire en utilisant prctl depuis linux 3.4.

À terme, cette fonctionnalité pourra être utilisée pour implémenter un mécanisme similaire aux cgroups utilisés par systemd pour surveiller les démons. Le système d'init pourra lancer un processus de contrôle pour chaque démon (ce qui est très léger en ressources, d'autant plus que le code est partagé en mémoire) et designer ce processus comme le "pid 1" du sous-groupe des processus lancés par le démon. Ainsi, il est impossible que le démon échappe au contrôle d'init ; si le processus de contrôle est tué, tous les fils de celui-ci le seront aussi. De même, si le démon crash, le processus de contrôle sera en mesure de le détecter (avec l'appel système wait(2)) et de relancer le service ou de notifier l'utilisateur. Le travail pour intégrer ces mécanismes avec rcNG est en cours.

L'ajout de procctl(2) permet un début d'implémentation de svc(8), un gestionnaire de service. Celui-ci permettra donc, à terme, de créer, surveiller et gérer un environnement simple et d'exécuter une commande dans cet environnement.

Augmentation de la limite du nombre de CPU

DragonFly prend désormais en charge des systèmes possédant jusqu'à 256 CPU. La précédente limite était de 63 avec DragonFly 3.8. Des tests ont été effectués jusqu’à 255 CPU via QEMU.

Pilotes graphiques

François Tigeot a apporté de nombreuses améliorations à la pile DRM concernant le pilote i915. La plus notable est certainement l'ajout de la gestion des GPU des processeurs de la série Haswell. On note également la prise en charge de kqueue dans /dev/drm suite à un patch de Imre Vadasz qui permet notamment à OpenGL de fonctionner. Il est donc désormais possible de jouer a OpenArena ou encore Supertuxkart!

De nombreuses corrections de bugs ont été apportées au pilote drm/radeon et à son gestionnaire de mémoire ttm.

Le pilote drm/i915 est maintenant basé sur l'implémentation de Linux 3.8.13 et non plus celle de FreeBSD. De nombreuses interfaces de programmation et structures de données Linux ont été implémentées dans le noyau DragonFly afin de pouvoir réutiliser sans modification le plus de code possible du pilote i915 Linux.

Les pilotes drm suivants ont été supprimés : mach64, mga, r128, savage, sis et tdfx. Ils servaient à accélérer certaines opérations OpenGL sur d'anciens GPU datant des années 1990 à début 2000. La bibliothèque Mesa ayant abandonné leur prise en charge en 2011, ces pilotes n'avaient plus d'utilité.

Réseau

Sepherosa Ziehau a écrit un outil permettant de tester le taux de requêtes/réponse UDP. Parmi les conséquences directes, les améliorations de performances concernant UDP. À titre d'exemple, une augmentation de performance d'environ 19 % a été observée pour des requêtes et réponses UDP de 18 octets avec un Intel Core i7-3770 et une carte 10 Gigabit Ethernet Intel 82599ES (1,34 millions de transactions par seconde, contre 1,12 millions sans le patch).

Par ailleurs, le pilote urndis(4) a été importé depuis FreeBSD. Il permet de bénéficier de l'USB tethering ; cela signifie donc qu'un appareil disposant du partage de connexion via USB, tel un smartphone sous Android par exemple, peut être utilisé comme une carte réseau.

Le pilote if_lagg(4) a été porté depuis FreeBSD. Il permet notamment d’agréger plusieurs interfaces réseau sous la forme d'une seule interface en fournissant un mécanisme de répartition de charge entre les différents membres du groupe, ou d'avoir une interface maîtresse et des interfaces de secours qui seront utilisées automatiquement en cas de problème sur l'interface active. Il contient aussi une mise en œuvre du protocole IEEE 802.3ad (LACP), qui permet d'utiliser les mécanismes précédemment décrits en coopération avec des interfaces distantes, comme par exemple un commutateur.

Packet Filter (pf)

La majeure partie du pare-feu Packet Filter peut désormais opérer de manière parallèle.

Pilotes RAID

Le pilote mrsas(4) a été ajouté. Il permet la prise en charge des cartes RAID LSI Thunderbolt et de modèles plus récents (Invader et Fury).

Crypto

Alex Hornung a ajouté l'algorithme ChaCha, une variante améliorée du chiffrement de flux Salsa20, utilisé notamment pour BLAKE, l'un des cinq finalistes du concours du NIST pour élire l'algorithme SHA-3. ChaCha a été ajouté dans le but d'être utilisé pour le nouveau générateur de nombres pseudo-aléatoires (CSPRNG) basé sur Fortuna.
Un nouveau paramètre sysctl a d'ailleurs été ajouté afin de pouvoir choisir le générateur utilisé pour /dev/random. 3 modes sont ainsi possibles :

  1. csprng, afin d'utiliser Fortuna ;
  2. ibaa, pour utiliser l'ancien générateur IBAA ;
  3. mixed, valeur par défaut, où les sorties des deux générateurs sont agrégées (par un XOR).
Espace utilisateur Mises à jour diverses

Plusieurs outils ont été mis à jour dans le système de base :

Ajout de rcreload

Zachary Crownover a ajouté rcreload à rcrun(8), ce qui permet de recharger la configuration d'un démon sans le redémarrer.

Import de service(8)

Depuis la première version de DragonFly, rcrun(8) est utilisé afin de gérer les scripts rc. Cependant, service(8) a été importé depuis FreeBSD, afin que les administrateurs système habitués à cet outil répandu le retrouvent également sur DragonFly.

Divers Abandon de i386

Comme annoncé lors de la sortie de la précédente version, il n'existe désormais plus de version 32 bits de DragonFly BSD. Cela signifie qu'aucune image 32 bits n'est désormais générée et qu'aucun effort ne sera fait pour maintenir les anciennes fonctionnalités ou rendre compatibles les nouvelles fonctionnalités avec l'architecture i386. Pour rappel, plus aucun paquet binaire n'était créé pour l'architecture i386 depuis DragonFly BSD 3.8 et celle-ci ne bénéficiait déjà plus de certaines fonctionnalités présentes dans la version 64 bits, notamment en ce qui concerne la gestion de la mémoire pour les pilotes graphiques.

GNOME 3.x et Cinnamon débarquent

Les paquets pour les environnements de bureau GNOME 3.14 et Cinnamon 2.2 sont arrivés dans les dépôts. John Marino a en effet pu faire les ajustements nécessaires afin que ces environnements compilent. Pour rappel, Gnome 2 n'avait jamais compilé dans son intégralité sur DragonFly. En revanche, il reste certainement pas mal de boulot pour que ces environnements de bureaux soient pleinement utilisables. À noter que ces changements suivent ceux survenus dans les ports FreeBSD puisque les dports de DragonFly en dérivent.

Xfce et mate restent, et certainement pour un moment encore, les DE à privilégier pour une bonne expérience utilisateur.

Rust porté sous DragonFly BSD

Le langage de programmation Rust a été porté sous DragonFly BSD par Michael Neumann. Il détaille dans un article de blog le procédé qu'il a utilisé. Ce travail pourrait, selon lui, être intéressant afin de porter Rust vers d'autres BSD, notamment OpenBSD et NetBSD (Rust est déjà disponible pour FreeBSD). La difficulté du portage vient du fait que le compilateur Rust est écrit en… Rust et qu'il faut donc par conséquent passer par quelques étapes de cross-compilation depuis un système disposant déjà de Rust (Michael Neumann a utilisé Linux).

FreePascal est désormais disponible

On aurait tendance à croire que le langage Pascal, apparu pour la première fois en 1970 et mis au point par Niklaus Wirth, est devenu une relique du passé. Pourtant, un utilisateur de DragonFly semblait avoir désespérément besoin d'un compilateur pour ce langage. John Marino a réussi à porter le compilateur FreePascal sur DragonFly. Cela permet donc aux ports dépendants du compilateur fpc d'être finalement disponibles.

DragonFly se prépare a clang

DragonFly intègre deux compilateurs dans base. Pour le moment, les deux compilateurs sont GCC 4.4 et 4.7. GCC 4.4 n'étant plus vraiment utile, il est prévu de le remplacer par clang, probablement en version 3.5, pour la prochaine version de DragonFly. John Marino et Matt Dillon ont donc commencé un travail dans ce sens, afin de s'assurer que world et kernel compilent sans histoires avec clang.

Notes de mise à jour

La mise à jour vers DragonFly BSD 4.0 se fait de la manière habituelle :

cd /usr/src git fetch origin git branch DragonFly_RELEASE_4_0 origin/DragonFly_RELEASE_4_0 git checkout DragonFly_RELEASE_4_0 make buildworld && make buildkernel && make installkernel && make installworld && make upgrade reboot

Si le système a redémarré correctement, il est conseillé de faire une sauvegarde de l'initrd de secours via :

make rescue

Cette dernière étape était auparavant réalisée lors de make installworld, mais cela pouvant poser des problèmes avec le chargement du module noyau vn, cette étape a été dissociée et le module vn est désormais inclus dans le noyau.

Télécharger ce contenu au format Epub

Lire les commentaires

Install Party GNU/Linux le 29 novembre 2014 à Marseille

Mercredi 26 Novembre

L'association CercLL (CercLL d'Entraide et Réseau Coopératif autour des Logiciels Libres) vous invite à une install party GNU/Linux le samedi 29 novembre 2014 de 14h30 à 19h30 dans la salle de la Fabulerie au 4 rue de la bibliothèque, 13001 Marseille.

Vous avez envie de découvrir un système d'exploitation libre, simple d'utilisation, stable, rapide, sécurisé ? Vous vous sentez une affection naissante pour le Gnou et le Manchot, les mascottes GNU/Linux ? Alors venez assister à la présentation d'une nouvelle façon d'utiliser votre ordinateur!
Programme en deuxième partie de dépêche.

Au programme :
  • Découverte de l'univers des logiciels libres.
  • Installation d'un environnement GNU/Linux, ainsi que les meilleurs des logiciels libres.
  • Démonstration de jeux vidéo sous Linux.

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

Entrée Libre accessible aux débutantes et débutants.

  • Une participation de 2 euros est demandée.
  • L'adhésion à l'association est de 20 euros (annuelle).

Télécharger ce contenu au format Epub

Lire les commentaires

Sortie de la version 0.9.4 de la forge logicielle CodingTeam

Mardi 25 Novembre

Après quelques années de sommeil, une nouvelle version de la forge logicielle française CodingTeam a été publiée. Il s'agit de la version 0.9.4, qui est donc la sixième version d'un projet entamé en 2007. L'apport majeur de cette nouvelle version est le support de Git. Les nouveautés de cette version 0.9.4 sont listées en seconde partie de dépêche.

CodingTeam est une forge logicielle, c'est donc une solution qui permet de gérer vos projets et de travailler collaborativement sur ceux-ci. Parmi les outils de travail collaboratif et de communication fournis, on peut par exemple citer la chronologie (timeline), la feuille de route (roadmap), l'explorateur de code, le gestionnaire d'anomalies, le wiki, la traduction de votre application en ligne (via gettext), le forum, …

CodingTeam peut être utilisé sur la forge CodingTeam.net (parmi plus de 3 000 utilisateurs et plus de 380 projets) ou être installée en interne, sur votre serveur (comme le font d'ailleurs des développeurs isolés ou même quelques entreprises). CodingTeam est un logiciel libre écrit en PHP, distribué sous la licence GNU Affero General Public License. D'ailleurs, le service CodingTeam.net est offert gratuitement et sans publicité aux développeurs de logiciel libre.

La version 0.9.4 de CodingTeam, publiée le 24 novembre, apporte des fonctionnalités que les utilisateurs de la forge attendaient depuis un bon moment. Première d'entre elle, c'est le support de Git (en plus de Subversion et Mercurial). Si le support n'est que partiel dans l'explorateur de sources, il est désormais possible pour un projet développé grâce à la forge CodingTeam d'utiliser ce gestionnaire de versions décentralisé.

La possibilité pour les utilisateurs de la forge de s’agréger en équipes a été ajoutée. Fonctionnalité amenée à se développer par la suite, elle permet d'ores et déjà de lier un salon XMPP ou une liste de discussion à un ou plusieurs projets.

De même, les statistiques générées pour les projets ont été grandement améliorées. On peut désormais accéder à un récapitulatif global de l'activité du projet depuis sa création. Celui-ci reprend à la fois le nombre de commits, mais aussi de contributions plus diverses telles que les rapports d'anomalies ou les messages postés dans le forum. C'est aussi dans cette optique que la feuille de route (ou roadmap) a été elle aussi améliorée afin de produire des statistiques automatiques plus détaillées qu'auparavant sur la gestion des anomalies et des requêtes de fonctionnalité du projet.

Cette version se caractérise aussi par une apparence totalement retravaillée pour être plus moderne et agréable. Enfin, de nombreuses choses de moindre envergure sont au programme. On peut notamment citer : un support de Mercurial plus stable, l'avertissement automatique d'activité sur les projets de l'utilisateur, l'ajout de filtres dans le gestionnaire d'anomalies ou encore la mise en conformité du code avec les dernières évolutions de PHP 5.

Télécharger ce contenu au format Epub

Lire les commentaires

Jeudi du libre du 4 décembre 2014 à Lyon

Mardi 25 Novembre

C'est la coutume : le premier jeudi du mois, l'ALDIL, le GULL Lyonnais, organise son jeudi du libre, une conférence qui met cette fois à l'honneur le langage de programmation Python. L'exposé sera une introduction à Python pour non spécialistes et non programmeurs. Le but est seulement d'aiguiser l'appétit des auditeurs qui pourront ensuite trouver toute la documentation nécessaire sur le Web, de l'initiation aux constructions évoluées.
La conférence a lieu à la Maison Pour Tous / Salle des Rancy 249 rue Vendôme - 69003 LYON (Métro Saxe Gambetta). Elle débutera à 19h30. Venez nombreux, c'est libre, gratuit, ouvert à tous, et en général la soirée se poursuit de manière informelle au bar de la MPT.

Thierry Dumont, le conférencier, est co-fondateur de l'Aldil en 1997 (alors que Python existait déjà, mais de manière presque clandestine). Il est ingénieur de recherche à l'Institut Camille Jordan (mathématiques); son domaine d'activité est le calcul scientifique et le calcul hautes performances. Son intérêt pour Python provient de son investissement dans Sage, logiciel scientifique basé sur Python.

Télécharger ce contenu au format Epub

Lire les commentaires

ENI ouvre à nouveau l'accès à sa bibliothèque numérique pour 2 jours (+1 an pour le gagnant !)

Mardi 25 Novembre

Après une première opération en février dernier, les éditions ENI remettent en libre accès pendant deux jours l’ensemble de leur bibliothèque numérique, au format HTML, du 27 novembre à minuit au 28 novembre à 23 h 59, afin de mieux la faire connaître. Comme il y en a pour tous les goûts (ou presque), vous devriez trouver votre bonheur, même si vous évoluez contre votre gré dans un environnement propriétaire. On rappelle que parmi les auteurs, certains sont des lecteurs ou contributeurs de LinuxFr.org, comme Sébastien Rohaut, par exemple, qui vient de sortir la 4e édition de son livre sur l'administration système de Linux.

Leur catalogue ne manque donc pas d’ouvrages sur les technologies libres et open source, que ce soit, en vrac, sur :

  • GNU/Linux, principalement Debian, Ubuntu et Red Hat ;
  • les environnement LAMP et les SGC / CMS qui tournent dessus : WordPress, Joomla, Drupal, etc. ;
  • les bases de données relationnelles (MySQL, PostgreSQL, etc.) ;
  • le courriel : Zimbra, Postfix, Amavis, etc. ;
  • ou encore des outils dédiés : Alfresco, Talend, Squid, Piwik, Nagios (toujours pas d'ouvrage sur Shinken ? ;-)).

Bref, vous avez deux jours (sur vos pauses de boulot !) pour vous faire une idée sur le fond de leurs ouvrages, la forme de la bibliothèque numérique, voire choisir votre récompense pour votre prochaine contribution sur LinuxFr.org ! Et si vous voulez plus de temps, comme nous sommes des gars ultra sympa, on offre (enfin plutôt ENI), un abonnement d'un an à cette bibliothèque numérique à l'un des meilleurs commentaires de cette dépêche, basé entre autres selon le jugement des personnes qui notent (contrairement aux journaux ou dépêches, l'affichage des notes est borné [-10;+10] pour les commentaires).

Tout comme les éditions Eyrolles et Diamond (GNU/Linux Mag, aka GLMF), les éditions ENI font partie des amis de LinuxFr.org qui permettent de motiver et récompenser chaque mois les meilleurs contributeurs du site. D’ailleurs, chacun de ces éditeurs a déjà mis en place des solutions d’accès numérique à ses livres et/ou revues, que ce soient des livres électroniques au format EPUB, HTML, PDF ou des bases documentaires accessibles en ligne sous forme d’abonnement pour essayer de s’adapter aux nouveaux usages et nouveaux supports.

Règles et principes pour l'abonnement à gagner
  • le concours est ouvert jusqu’au 28 novembre 2014 à 23h59, l’heure de nos serveurs faisant foi ;
  • l'abonnement est limité à une seule personne par compte et mot de passe, accès 100% en ligne, valeur 49€/mois ;
  • pas besoin de nous informer de votre participation ;
  • l'équipe de modération choisira par consensus le gagnant parmi les commentaires ayant reçus une note d'au moins 7. Si aucun consensus ne se dégage, on invoquera /dev/random ;
  • si aucun commentaire n'atteint 7, on refilera l'abonnement à qui on veut… ou pas ;
  • l'abonnement sera attribué à la personne identifiée comme ayant la parenté du commentaire ("Posté par …") ;
  • en cas de contestation ou tout autre souci, l'équipe de modération est souveraine et sa décision est finale, aucun appel ne sera possible ;
  • on n'accepte pas les commentaires trollesques, ou alors s'il a bien fait rire l'équipe de modération. Cela reste à notre entière discrétion ;
  • l’acceptation d’une contribution ne respectant pas les principes ci-dessus sera laissée au libre choix (souverain et final) de l’équipe de modération.
Captures d'écran
  • Capture d’écran d’une recherche du terme Linux

  • Extrait d’un ouvrage

Télécharger ce contenu au format Epub

Lire les commentaires

Exploiter inotify, c'est simple

Lundi 24 Novembre

Intégré à partir de Linux 2.6.13, le mécanisme inotify permet de mettre en place des actions associées à l'évolution de l'état du système de fichiers. À l'occasion des 10 ans de ce projet, cette dépêche va vous donner des pistes pour exploiter ce mécanisme qui pourra vous simplifier bien des tâches d'administration.

Sommaire  Description du fonctionnement

Le mécanisme inotify permet de positionner un watch descriptor sur un fichier, qui enverra des notifications au système lorsque des événements affecteront le fichier suivi. Pour rappel, dans le monde Unix, un fichier peut aussi bien représenter un fichier simple qu'un répertoire, un périphérique, un lien, etc. Les principaux événements qui peuvent être suivis sont :

  • IN_ACCESS : le fichier est accédé en lecture
  • IN_MODIFY : le fichier est modifié
  • IN_ATTRIB : les attributs du fichiers sont modifiés
  • IN_OPEN : le fichier est ouvert
  • IN_CLOSE_WRITE : le fichier est fermé après avoir été ouvert en écriture
  • IN_CLOSE_NOWRITE : le fichier est fermé après avoir été ouvert en lecture
  • IN_MOVED_FROM / IN_MOVED_TO : le fichier a été déplacé ou renommé
  • IN_DELETE_SELF - le fichier a été supprimé
  • IN_DELETE : un fichier a été supprimé dans le répertoire surveillé
  • IN_CREATE - un fichier a été créé dans le répertoire surveillé

Dans le mécanisme standard de inotify, il n'y a pas de notion de récursivité : un événement dans /home/georgette/.ssh ne sera pas remonté par un watch descriptor surveillant /home ; cependant, les outils implémentant inotify gèrent en général eux-même cette récursivité (en positionnant des watch descriptors dans toute l'arborescence, et en ajoutant dynamiquement des watch descriptors à chaque fois qu'un événement IN_CREATE survient).

incron : mieux que des tâches planifiées, des tâches instantanées  Principe

Les administrateurs de systèmes GNU/Linux connaissent tous le gestionnaire de tâche planifié cron, qui permet de lancer des tâches selon une planification cyclique (par exemple tous les dimanche à 14h00) définie dans une crontab, c'est-à-dire un fichier indiquant la tâche à exécuter et l'heure à laquelle elle doit être exécutée. Le logiciel incron reprend ce principe, mais, plutôt que de se baser sur des événements temporels, il se base sur des événements inotify.

 Installation

Le logiciel incron est packagé pour la plupart des distributions, il suffit donc de l'installer à l'aide de votre gestionnaire de paquets préféré :
# pour Debian, Ubuntu, etc.
$ apt-get install incron

# pour Red Hat, CentOS etc. $ yum install incron

Une fois installé, il faut insérer les utilisateurs autorisés à utiliser incron dans le fichier /etc/incron.allow :

$ cat /etc/incron.allow
httpadm
nagios
georgette
## Utilisation ##
Pour créer une tâche dans la incrontab, lancer la commande incrontab -e, et y déclarer l'événement et la commande associée. Par exemple, on peut demander à lancer automatiquement la commande postalias lorsque /etc/aliases est modifié :

/etc/aliases IN_MODIFY postalias

Note : incron fait partie des logiciels qui n'implémentent pas la récursivité.

lsyncd : vers un système de fichiers distribué principe

Mettre en place un système de fichiers distribué peut s'avérer compliqué, puisque cela implique en général une phase de migration des données existantes dans un nouveau système de fichiers qu'il faut avoir installé sur de nouveaux disques, voire de nouveaux serveurs. Le logiciel lsyncd permet de simuler un système de fichiers distribué en synchronisant simplement les fichiers d'une arborescence, en utilisant rsync. L'avantage de lsyncd est que la synchronisation est faite à chaque modification, et dès que celle-ci intervient : cela simule presque parfaitement un système de fichier distribué synchrone

mise en place

lsyncd est packagé pour la plupart des distributions GNU/Linux, il suffit donc de l'installer via votre gestionnaire de paquets habituel. La configuration se fait à l'aide de scripts en langage Lua, si vous n'êtes pas habitué à utiliser ce langage, vous pouvez suivre les exemples donnés dans la documentation. Ici on va synchroniser /var/www/mon_site :

# cat /etc/lsyncd.conf.lua -- configuration de lsyncd settings{ statusFile = "/tmp/lsyncd.stat", statusInterval = 1, insist = 1, inotifyMode = "CloseWrite or Modify", } -- liste des serveurs vers lesquels synchroniser targetlist = { "web01::mon_site", "web02::mon_site", "web03::mon_site" } -- configuration de la synchronisation for _, server in ipairs(targetlist) do sync{ default.rsync, source="/var/www/mon_site", target=server } end

Pour que la synchronisation fonctionne, il faudra bien évidemment configurer rsync sur les serveurs web01, web02 et web03 pour que la destination mon_site pointe vers /var/www/mon_site.

 iwatch : ceci n'est pas une montre

Le logiciel iwatch permet de déclencher une action suite à un événement inotify. Il s'agit d'un logiciel destiné à l'origine à la surveillance, on s'en sert donc habituellement pour envoyer un email lorsqu'un fichier est modifié, par exemple pour prévenir georgette de chaque modification de /etc/shadow :

iwatch -m georgette@example.com /etc/shadow

Contrairement à incron, iwatch gère la récursivité (avec l'option -r) et les exclusions (avec l'option -x pour un chemin, et -X pour une regex), par exemple pour lancer l'antivirus pour chaque modification dans /var/www/upload (ou un de ses sous-répertoires) sauf des fichiers .png :

iwatch -r -X '\.png$' -c "clamscan %f" /var/www/upload

Ici, %f pointe vers le fichier ayant déclenché l'événement.

inotify-tools : mettez de l'inotify dans votre ligne de commande

Les inotify-tools permettent de faire des appels inotify directement en ligne de commande, quel que soit le shell utilisé.

inotifywait

La première commande fournie est inotifywait, qui permet d'attendre un événement avant de continuer une exécution, par exemple pour éviter qu'une commande ayant un fichier en prérequis tombe en erreur :

inotifywait -e close_write /var/run/jboss.pid && supervision_jboos.sh

L'option -t permet de mettre en place un timeout en secondes, pour par exemple sortir en erreur si un événement est trop long à arriver :

suavegarde.sh & ; inotifywait -e close_write -t 10000 rapport_sauvegarde || killall sauvegarde.sh

inotifywatch

La commande inotifywatch permet de faire un rapport d'activité des événements concernant les répertoires surveillés.
```
$ inotifywatch /var/cache/apt/archives &
[1] 18607
root@kamoulix:~# Establishing watches…
Finished establishing watches, now collecting statistics.

root@kamoulix:~# apt-get autoclean
root@kamoulix:~# kill %1
total access close_write close_nowrite open delete filename
1919 7 1 2 3 1906 /var/cache/apt/archives/

Par défaut inotifywatch s'arrêtera après avoir un reçu un signal d'interruption, on peut aussi le faire tourner juste pour un certain nombre de secondes avec l'option -t, par exemple pour voir l'activité du répertoire home de l'utilisateur georgette pendant une minute :

$ inotifywatch -r /home/georgette/ -t 20
Establishing watches…
Finished establishing watches, now collecting statistics.
total access modify close_write close_nowrite open moved_from moved_to create filename
16 3 3 2 0 2 2 2 2 /home/georgette/.mozilla/firefox/e3lq4lm3.default/
13 11 0 0 1 1 0 0 0 /home/georgette/.cache/myapp/mycache/

```# Codez avec inotify #
Les principaux langages de programmation proposent une bibliothèque pour travailler avec inotify, en voici une liste non exhaustive :

Télécharger ce contenu au format Epub

Lire les commentaires

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

Lundi 24 Novembre

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

[Rue89] En Corrèze, iPads pour tous à l’école: «Vous allez voir, ce sont des mages»

Par Rémi Noyon, le vendredi 21 novembre 2014. Extrait:

François Hollande veut généraliser l'usage des tablettes à l'école, comme il l'a fait en Corrèze. «Apologie du consumérisme» ou avenir de l'enseignement? Reportage à Tulle.

Lien vers l'article original: http://rue89.nouvelobs.com/2014/11/21/correze-ipads-tous-a-lecole-allez-voir-sont-mages-256094

[La Revue du Digital] “Travailler l’Open Data, c’est travailler la démocratie” pour le Chief Data Officer de la France

Par William El Kaim, le vendredi 21 novembre 2014. Extrait:

Les projets se multiplient au sein d’Etalab, le bras armé de l’état pour sa politique Open Data. Les premiers résultats sont désormais disponibles soit sous forme d’ouverture de données à destination de nouveaux écosystèmes soit sous la forme de nouvelles applications disponibles pour les citoyens.

Lien vers l'article original: http://www.larevuedudigital.com/2014/11/actu/travailler-lopen-data-cest-travailler-la-democratie-pour-le-chief-data-officer-de-la-france

[Le Monde.fr] Tails, l'outil détesté par la NSA, qui veut démocratiser l'anonymat en ligne

Par Amaëlle Guiton, le jeudi 20 novembre 2014. Extrait:

Nous avons rencontré les développeurs d'un outil craint par la NSA, utilisé par Edward Snowden et de plus en plus d'internautes désireux de se protéger sur Internet.

Lien vers l'article original: http://www.lemonde.fr/pixels/article/2014/11/20/tails-l-outil-deteste-par-la-nsa-qui-veut-democratiser-l-anonymat-en-ligne_4514650_4408996.html

Et aussi:

[Numerama] Mozilla choisit de défendre Mozilla, pas les valeurs du logiciel libre!

Par Guillaume Champeau, le jeudi 20 novembre 2014. Extrait:

Mozilla a annoncé la fin du contrat mondial qui le liait à Google, mais en faisant des choix hautement critiquables. Ainsi, Google restera proposé en Europe où il est déjà ultra-dominant, et en Chine c'est le moteur de recherche Baidu soumis à la censure étatique qui sera proposé par défaut aux internautes chinois. Mozilla a-t-il perdu son idéalisme au profit du seul réalisme économique?

Lien vers l'article original: http://www.numerama.com/magazine/31329-mozilla-choisit-de-defendre-mozilla-pas-les-valeurs-du-logiciel-libre.html

Et aussi:

[Next INpact] Au ministère de la Culture, craintes et revendications sur le chantier du droit d'auteur

Par Marc Rees, le jeudi 20 novembre 2014. Extrait:

Mardi, Fleur Pellerin est venue au Conseil Supérieur de la Propriété Littéraire et Artistique, qui tenait là sa séance plénière. À cette occasion, elle a salué les travaux du professeur de droit Pierre Sirinelli qui présentait ce jour son rapport d'étape (notre actualité) planchant sur une éventuelle révision de la directive de 2001 sur le droit d’auteur et les droits voisins.

Lien vers l'article original: http://www.nextinpact.com/news/91011-au-ministere-culture-craintes-et-revendications-sur-chantier-droit-d-auteur.htm

Et aussi:

[ZDNet France] Formats ouverts à l’école: l’April lance un appel

Par Louis Adam, le mardi 18 novembre 2014. Extrait:

L’April a lancé un appel en faveur de l’utilisation de formats ouverts au sein de l’éducation nationale. Leur cheval de bataille: l’interopérabilité des documents, qui se doivent d’être lisibles par tous les utilisateurs. Et bien sûr, protéger les élèves des «stratégies d’enfermement» des gros éditeurs.

Lien vers l'article original: http://www.zdnet.fr/actualites/formats-ouverts-a-l-ecole-l-april-lance-un-appel-39809713.htm

Et aussi:

Voir aussi:

[Vox] The courts set a new record for rejecting software patents in 2014

Par Timothy B. Lee, le lundi 17 novembre 2014. Extrait:

(Les tribunaux ont récemment été de plus en plus hostiles aux brevets logiciels) Courts have recently grown increasingly hostile to software patents. A June Supreme Court ruling significantly limited the kinds of software inventions that are eligible for patent protection. And even before that ruling, there had been a dramatic increase in the number of legal decisions holding that software-related inventions were unpatentable.

Lien vers l'article original: http://www.vox.com/2014/11/17/7222807/software-patent-invalid-record

[Gridam] Des actrices X expliquent la Net neutralité en vidéo

Par Emeric, le lundi 17 novembre 2014. Extrait:

Le site Funny or Die a fait appel à trois actrices X pour soutenir Barack Obama dans sa lutte pour la Net neutralité.

Lien vers l'article original: http://www.gridam.com/2014/11/actrices-x-expliquent-net-neutralite-en-video

Télécharger ce contenu au format Epub

Lire les commentaires

Haiku se lâche enfin

Lundi 24 Novembre

Le projet Haiku est une réminiscence de feu BeOS. Pour les plus jeunes, BeOS était un système d'exploitation propriétaire développé en C++ par Be Inc. de 1990 à 2000. Son architecture était totalement indépendante, tout en ayant beaucoup de traits POSIX, ce qui permettait avec peu de travail d'y retrouver Qt, Mozilla, SDL, QEMU, Bash et bon nombre d'autres références classiques aux côtés de la logithèque propre de BeOS.

Haiku, anciennement OpenBeOS, reprend donc le flambeau de BeOS, avec cette ré-écriture libre, entreprise en 2001, avec l'appui de l'association à but non lucratif créée à cet effet. D'après Wikipédia, « …une version alpha de Haiku R1 est distribuée le 14 septembre 2009. La R1 Alpha 2 est sortie le 9 mai 2010, la R1 Alpha 3 le 20 juin 2011, et la R1 Alpha 4 le 12 novembre 2012. ». Nous couvrons ici les plans pour Haiku Bêta 1 et R1. Pour information ou rappel, toujours d'après Wikipedia : « Le développement d'Haiku est actuellement focalisé sur la R1, qui doit être quasiment identique à la dernière version distribuée par Be, la R5. ».

Sommaire Haiku qu’est-ce donc ?

Il était une fois BeOS, un système d’exploitation propriétaire né sur les processeurs d'architecture Hobbit, puis porté sur PPC (en fait une machine hybride utilisant 2 Hobbits, 3 DSP et 2 PPC). C'était la période des BeBox.

BeOs a tenté l'aventure Intel sur un marché où seul Windows 9x dominait le Bureau, dans le but de sortir de la confidentialité. La philosophie de développement était de ne pas s'encombrer du passé, de toujours profiter au mieux du matériel récent.

  • BeOS était avant tout un OS orienté multimédia et performances temps réel (N.d.A. : à l'époque, je redémarrais sour BeOs pour lire les vidéos qui étaient trop lourdes pour mplayer sur mon pauvre Cyrix 133).
  • BeOS avait un système de fichiers journalisé transactionnel 64 bits appelé BFS qui fait encore rêver bien des concepteurs de systèmes de fichiers modernes.
  • BeOS démarrait en moins de temps qu'il ne faut à bien des OS récents pour sortir de veille, un certain Lennart en rêve encore.
  • BeOS, même s'il avait un véritable terminal, démarrait directement en mode graphique, un certain Rasterman en rêve encore. ;-)
  • BeOS imposait une structure multi-threadée au code des applications natives, ce qui leur donnait une réactivité impressionnante, même sur des machines aujourd'hui (et à l'époque) considérées comme limitées.

Pour la petite histoire, Be Inc. était dirigée par un français, Jean-Louis Gassée, qui a failli ravir la place de Steve Jobs durant les années creuses d'Apple. Oui, Mac OS X aurait pu être sur une base BeOS plutôt que NextStep.

La chose ne s'est point faite et Be Inc. ne trouvant pas sa place sur le marché a fini par sombrer. Une nouvelle Release 6 (dite Zeta) devait sortir et corriger bien des erreurs de jeunesses du système (comme sa gestion calamiteuse du réseau), mais Be Inc. fut rachetée et enterrée par Palm.

Et pour l'histoire encore plus petite, Le projet s'appelle Haiku car c'est sous cette forme poétique qu'étaient diffusés les messages d'erreurs du navigateur NetPositive.

Trop beau, trop tôt.

C'est en 2001 que Michael Phipps décide de lancer le projet Haiku (OpenBeOS au commencement). Son objectif pour la première release (dite R1) est d'être iso-fonctionnel avec BeOS R5. Cela implique de conserver la compatibilité binaire, le compilateur de reférence (gcc2), la configuration, toutes les API, les pilotes…

Où en sommes nous ?

Après quelques discussions enflammées sur la liste de diffusion Haiku, il y a quelques semaines, concernant la sortie d'une Nième alpha, il a été décidé lors du BeGeistert 2014 qu'il fallait accélérer les choses. Nombre de contributeurs se sentaient en effet coincés dans une logique d'archéologie concernant les contraintes techniques sus-citées du projet.

Nous sommes en 2014 et la Bêta 1 pointe le bout de son nez, après 4 alpha. Haiku est presque BeOS, parfois moins bien, souvent bien mieux. La pile TCP/IP issue de FreeBSD en est un bon exemple.

L'accent va désormais se porter rapidement sur la R2 et la gigantesque aire de jeux qu'elle représente pour les hackers de tous poils.

L’annonce de la bonne nouvelle

C'est Adrien Destugues qui a posté la bonne nouvelle ce 2 novembre, ce qui suit est une traduction libre :

Salut les devs,

Pendant le BeGeistert coding sprint nous avons eu une longue discussion avec Ingo, Oliver et Ithamar à propos du futur d'Haiku et des difficultés que nous avons à produire une release. Nous avons cherché à nous mettre d'accord et nous aimerions proposer un plan pour atteindre la R1 et passer à l'étape suivante du développement.

Les objectifs sont multiples :

  • Enfin fournir une version stable avec le nécessaire pour les développeurs
  • Mettre au point un cycle de développement plus efficace qui permettra des releases plus fréquentes
  • Permettre aux développeurs de travailler sur des choses plus passionnantes sans se sentir coupable de ne pas contribuer à l'objectif primaire de la R1

Notre raisonnement est qu'aujourd'hui la compatibilité binaire n’intéresse que peu de développeurs, probablement de même que les utilisateurs. Nous savons que la plupart des gens utilisent plus des applications Qt ou Java que natives de BeOs R5, d'autant qu'au cours des deux dernières années, l'équipe de HaikuArchives a été occupée à récupérer les sources de bon nombre d'applications BeOS, afin qu'elles puissent être mises à jour pour les prochaines releases. En outre, nous pensons qu'une R1 stable permettra d'inciter plus de développeurs à s'impliquer pour Haiku, apporter de nouvelles applications qui ne sont simplement pas concernées par la compatibilité binaire.

Nous avons fait un premier jet du plan qui assurera une transition douce vers le futur d'Haiku

Cela inclut la Bêta 1 puis les étapes vers la R1 incluant une branche de maintenance, ainsi que le développement pour la R2 et les choses amusantes qui vont descendre dans notre dépôt git comme d'habitude.

Pré-requis pour la Bêta1

À ce stade, nous avons atteint le checkpoint « fonctionnalités complètes » défini par le sondage « futures fonctionnalités de Haïku » de 2010. La dernière grande chose qui manquait était le gestionnaire des paquets, qui a été fusionné dans Haiku il y a un an et est maintenant stable et utilisable.

Il reste cependant quelques points de blocage qui empêchent la Beta 1 de passer la porte. La plupart ne sont pas les tâches de développement pour Haiku lui-même, et se rapportent à l'infrastructure PM. Nous avons besoin d'un processus automatisé pour construire les paquets à partir des applications produites par Haikuports afin de les intégrer aux releases. La pratique actuelle qui est de donner à un développeur un accès de commit pour télécharger des paquets n'est pas acceptable car il y a trop de travail et elle conduit à des problèmes de maintenance pour tous les paquets (un paquet est mis à jour, car il est une dépendance d'un autre, mais cela en casse un troisième qui ne peut fonctionner qu'avec une version plus ancienne, etc.).

Il y a aussi quelques questions ouvertes telles que l'absence de prise en charge IMAP dans les versions actuelles. Cela a disparu depuis l'Alpha3 et il existe des alternatives acceptables (en utilisant Beam ou un webmail), de sorte que la prise en charge d'IMAP pourrait être laissée de côté.

Plan pour la Bêta1

Sans les quelques points indiqués précédemment, il est inutile d'essayer de produire une release. Alors essayons d'abord de les résoudre. Oliver a travaillé pour y arriver, mais plus d'aide serait évidemment la bienvenue. Cela implique des travaux sur HaikuPorter (Python), ainsi que l'infrastructure serveur pour produire des builds. C'est peut-être le bon moment pour des non adeptes du C++ de rejoindre le projet.

Une fois ces points résolus, le temps de la release sera venu. Je prends la charge de coordinateur de release. Mon plan est d'utiliser plus ou moins le même schéma que pour les versions alpha et bêta.

Plans pour la R1

J'ai été mandaté pour mettre au point un plan pour la R1 et au-delà plutôt que des sorties au coup par coup chaque année des nouvelles Alpha. Voici ma proposition à cet effet.

À partir de la version bêta1, le tronc de Haiku sera consacré à la R2. Le contenu exact de cette nouvelle version doit être décidé entre les développeurs, mais il doit y avoir un consensus à passer à gcc4 ou clang comme compilateur principal, se débarrasser de notre ancienne libc customisée et la remplacer par une officielle et un peu de nettoyage des strates de l'API .
C++11 va également commencer à être plus utilisé.

La prise charge de l'API R1 et/ou la compatibilité BeOS R5/gcc2 dans R2 peuvent être maintenues si quelques-uns sont motivés pour le faire – aucun des participants du BeGeistert code sprinters n'est intéressé, mais d'autres développeurs peuvent vouloir le faire.
Cela n'a même pas besoin de rester dans le tronc d'Haiku, nous pourrions le fournir au besoin en third-party – similaire à la façon dont notre port Qt est actuellement distribué. Il reste quelques efforts pour y arriver et des gens devront en prendre soin.

Pendant ce temps, la branche de Bêta1 vit sa vie et deviendra un jour la R1. Ensuite, le plan est d'être à l'écoute des rapports de bugs des utilisateurs et développeurs et de rétroporter depuis la branche principale quand ce sera nécessaire. Quand la bêta1 sera complète, aucune nouvelle fonctionnalité ne sera plus jamais ajoutée. En tant que coordinateur de la Bêta1, je peux aussi prendre le rôle de responsable de la R1 et m'occuper du rétro-portage. Après un délai raisonnable (peut-être 3 à 6 mois - selon le nombre de bugs trouvés) après release de la Bêta1, une version R1 sera construite depuis cette même branche. Dès lors, la branche pourra vivre et produire de nouvelles version (R1.1, etc.) si de nouveaux problèmes sont détectés. Ou bien on peut basculer sur un mode « rolling release » où les mises à jour sont poussées en utilisant le gestionnaire de paquets. Aucune nouvelle fonctionnalité ne devra être ajoutée dans cette branche.

Nous pensons que ce plan permet une sortie de la R1 relativement indolore et à court terme. En tant que développeurs Haiku, nous devons admettre que ce ne sera pas une sortie parfaite. Il serait plus souple et lisse que les Bêtas s'appuient sur les branches des Alphas, mais il y aura forcement des bugs et limitations. Je ne pense pas qu'il y ait un moyen d'obtenir une release parfaite et sans bug dans un délai raisonnable avec notre main-d'œuvre actuelle.

Suite à la publication R1, la compatibilité BeOS R5 pourra continuer à exister dans la R2, soit dans une branche, soit comme un paquet externe.
La branche R1 continuera à recevoir des correctifs pour que ceux qui utilisent Haiku en production (nous pensons à TuneTracker) puissent compter sur une version solide et stable comme base pour leurs produits. De cette façon, les gens peuvent continuer à utiliser la R1 ou migrer vers la R2 et profiter de toutes les nouvelles fonctionnalités, mais au risque de découvrir de nouveaux bugs.

--
Adrien

Que faire maintenant ?

Haiku n'a d'avenir que s'il trouve ses utilisateurs. Il offre un environnement simple, rapide et efficace tout en donnant accès à des outils de qualité auprès desquels les habitués de GNU/Linux ne sont pas dépaysés.

Installez-le dans une VM ou sur une machine qui s'ennuie, vivez au quotidien avec et il deviendra vite votre indispensable compagnon.

Débusquez les bugs, remontez-les, proposez des corrections si vous le pouvez : le challenge est plus accessible qu'avec GNU/Linux, profitez en !

On n'attend plus que vous !

Télécharger ce contenu au format Epub

Lire les commentaires

Calendrier de l'Avent du domaine public 2015

Dimanche 23 Novembre

Mais qui donc entrera dans le domaine public en 2015 ?

Le collectif SavoirsCom1 vous invite à célébrer ensemble le domaine public en inaugurant la 3ème édition de son original calendrier de l'Avent, le lundi 1er décembre à Numa Paris à partir de 18h30.

À la place d’un éphémère petit chocolat, ce sera un(e) nouvel(le) auteur(e) entrant pour l'éternité dans le domaine public, qui sera dévoilé(e) chaque jour de décembre. Au final 31 noms dont les œuvres deviendront librement réutilisables. La durée du droit d'auteur étant de 70 ans post mortem en France, c'est la promotion des morts en 1944 que nous accueillons ici.

Une soirée animée par Xavier de La Porte. Parmi les intervenants : Lionel Maurel, Alexis Kauffmann, Hervé Le Crosnier, Julien Dorra… et Benjamin Sonntag qui apportera le BookScanner de La Quadrature pour l'occasion (démo en numérisant un livre d'un nouvel entrant à mettre en ligne le 1er janvier prochain).

Un événement coordonné par Romaine Lubrique marquant le top départ du 1er festival du domaine public qui se déroulera à Paris en janvier.

On notera que le domaine public a fait récemment l'actualité à l'Assemblée nationale, la députée Isabelle Attard essayant, en vain, d'en faire passer une définition positive et d'en finir avec ces exceptions bien françaises qui rallongent d'autant le droit d'auteur (Mort pour la France et prorogations de guerre).

Au programme du lundi 1er décembre à Numa
  • 18:30 Accueil
  • 19:00 Ouverture
    • Présentation du 1er festival du domaine public, par Alexis Kauffmann
    • C’est quoi le domaine public ? par Lionel Maurel
    • Calendrier : La genèse du projet, par Julien Dorra
    • Calendrier : Présentation générale du calendrier par Thomas Fourmeux et Silvère Mercier
    • Présentation du livre Pages Publiques par Hervé Le Crosnier et Nicolas Taffin
    • Présentation du BookScanner, par Benjamin Sonntag
    • Présentation des affiches réalisées pour l’occasion, par Sylvia Fredriksson et ses étudiants de La Sorbonne
  • 20:00 Lancement officiel du calendrier 2015 : Champagne !
    • Apéro en musique du domaine public
    • Numérisation de livres avec le BookScanner (apportez un vieux livre !)
Télécharger ce contenu au format Epub

Lire les commentaires

Calendrier du Libre 2015

Dimanche 23 Novembre

L'association LILA vous propose d'acheter le Calendrier du Libre 2015 pour 15 € (ou plus si le cœur vous en dit), un projet simple de calendrier, à l'ancienne comme vous les vendent les pompiers à cette période. Mais oui, vous savez bien : en papier, pas sur un écran !

Mais quelle est la différence avec votre calendrier de pompiers ? Eh bien, on ne sauve pas des vies et on ne pose pas nu derrière une lance à incendie — c'est sûr, c'est moins glamour — mais on fait de l'Art Libre avec des Logiciels Libres, ce qui a tout de même l'avantage d'être dans le thème de LinuxFr.org, non ?

Ce projet finance les artistes qui publieront une image dedans (illustrations, photos et rendus 3D) ainsi qu'une sélection de Logiciels Libres dédiés au graphisme (GIMP, Blender, Inkscape, Scribus), notamment sur nos chers systèmes d'exploitation Libres, et enfin l'association organisatrice.

Et si cette année, vous affichiez un calendrier entièrement Libre au dessus de votre bureau?

Les images seront sous une licence Creative Common Attribution 2.0, et nous fournirons même un lien vers les fichiers numériques haute définition aux acheteurs. Bien entendu, ce projet est fait entièrement avec des Logiciels Libres et chaque image a été créée avec des Logiciels Libres.

Les artistes

Cinq artistes de divers horizons participent au projet et fournissent deux œuvres chacun.

  • Aryeom Han est une réalisatrice d'animation et illustratrice coréenne. Utilisatrice de GIMP, Inkscape et divers autres Logiciels Libres, elle est actuellement en résidence d'artiste à l'association LILA.
  • Patrick David est un photographe américain très actif dans la communauté artistique libriste. Il est notamment le manager de la communauté "GIMP Users" sur Google+. Son workflow est principalement avec des Logiciels Libres.
  • Henri Hebeisen est un infographiste 3D français, certifié "Blender Foundation Certified Trainer".
  • Gustavo Deveze est un réalisateur d'animation et illustrateur en Argentine. Il utilise principalement GIMP et expérimente avec beaucoup d'autres Logiciels Libres.
  • Brian Beck travaille dans le système éducatif américain, où il promeut le Logiciel Libre sans relâche depuis plusieurs années. Il photographie essentiellement avec des Logiciels Libres.

En guise d'un sixième artiste, nous utiliserons deux rendus 3D haute définition fournis par la Fondation Blender.

L'association LILA

LILA est une association française déclarée (loi 1901) que j'ai cofondée avec un ami. Notre but originel était de promouvoir l'Art Libre. Nous sommes nous-même utilisateurs de Logiciels Libres, et pour ma part même développeur.
Bien que l'association existe depuis quelques temps, elle était principalement dormante, et c'est seulement récemment, de retour en France après plusieurs années à l'étranger, que nous essayons de l'activer davantage.

Ce calendrier est un petit projet mineur, sans grande importance en soi, mais qui nous permet de démarrer par quelque chose, de prendre un peu la température et de nous rapprocher de certains artistes.
Nous avons d'autres projets plus importants, et notamment avec l'artiste Aryeom Han qui participe aussi à ce Calendrier du Libre.

Notons que le Logiciel Libre n'est pas le but ultime. Je dirais qu'il est plus "une évidence". Pour moi, il s'agit d'une étape nécessaire pour avoir un écosystème logiciel sain. Mais au final si je contribue aux Logiciels Libres, c'est pour en faire quelque chose, pas comme une fin en soi.
C'est pourquoi s'il s'agit aussi d'une association libriste, c'est surtout une association artistique, puisque notre but est davantage de promouvoir les Arts et le partage de connaissance que les logiciels. Mais il est tout de même très triste de voir de grosses fondations ou associations libristes utiliser des logiciels de graphisme propriétaires à gogo, ce que j'ai constaté à de nombreuses reprises. La plupart des logiciels Libres pour le graphisme ont extrêmement peu de moyens, et pourtant sont souvent bien connus, même en dehors des sphères libristes. J'ai été très étonné ces dernières années de rencontrer pas mal de personnes qui connaissaient et avaient installé GIMP (alors qu'ils ne connaissaient le terme "logiciel Libre" que très vaguement, voire du tout).

Nous espérons donc que ce petit projet aidera un peu à la promotion de logiciels et d'artistes.

Reverser aux Logiciels Libres

Les Logiciels Libres sont donc nécessaires. C'est pourquoi nous décidons de reverser une part non négligeable des gains à une sélection de Logiciels Libres. Un huitième entier ira à la Fondation Blender puisque nous allons utiliser deux de leurs rendus haute définition comme des pages de calendrier. Par conséquent, nous intégrons le projet Blender comme un "artiste" à part entière dans ce projet.
Un second huitième était prévu pour trois autres logiciels, mais le photographe Patrick David ayant décidé de donner sa part aux projets de Logiciel Libre, finalement un quart des gains ira, en part égale, à trois autres projets du Libre:

  • GIMP: vous connaissez probablement tous GIMP, logiciel de manipulation d'images bitmap. Utilisé par beaucoup de photographes et d'illustrateurs, une des références du Logiciel Libre.

  • Inkscape: logiciel d'édition d'images vectorielles, une référence aussi dans le monde Libre.

  • Scribus: la référence du Libre en matière de mise en page professionnel. Le logiciel à intégrer dans votre workflow avant l'envoi à l'imprimeur.

Alors qui veut un petit calendrier?

Télécharger ce contenu au format Epub

Lire les commentaires

OpenDesk, l'Air du bois et SketchChair.cc : plans de meubles sous licence Creative Commons

Dimanche 23 Novembre

Les sites OpenDesk et L'Air du bois proposent des plans de meubles (bureaux, chaises, etc.) sous différentes licences Creative Commons (dont certaines sont libres et d'autres non-libres comme les CC NC et/ou ND).

Le journal de Victor STINNER à l'origine de la dépêche présentait OpenDesk, et un des commentaires évoquait L'Air du bois et un autre citait SketchChair.cc, ce qui a permis d'enrichir la dépêche. On mentionnera aussi le Mozilla Factory Space, avec un parquet explorant le concept de meuble libre.

OpenDesk

Le site OpenDesk propose de passer par un artisan pour faire fabriquer le meuble (dont plusieurs artisans français), mais documente aussi des moyens de le fabriquer soi-même.

La page Wikipédia OpenDesk rappelle qu'un des objectifs d'OpenDesk est de réduire les coûts de transport des produits finis en profitant d'une fabrication locale.

Notez bien qu'utiliser commercialement les plans Creative Commons - Attribution-NonCommercial impose de rémunérer l'auteur : "If you wish to use the design commercially please respect the right of the designer to be paid a royalty by working with a registered maker in the OpenDesk network."

Répartition des licences sur les 23 designs actuellement disponibles chez OpenDesk :

  • vingt non-libres (19 CC By NC et 1 CC By NC ND)
  • trois libres (2 CC By Sa et 1 CC 0)
Desk par Joni Steiner & Nick Ierodiaconou - CC By Sa

Rotational Stools par Anne Filson & Gary Rohrbacher - CC By Sa

Wiki Booth par Lynton Pepper - CC Zero

L'Air du bois

Le site L'Air du Bois se décrit comme « un portail de partage autour du travail du bois (menuiserie / ébénisterie amateur) ». Il s'agit d'un « projet personnel mené par Boris Beaulant dans le but de construire un espace d'échange autour de la passion du bois. » On y trouve des photos de réalisations ou d'ateliers, des plans, des tutoriels, etc.

Répartition des licences sur les 74 designs actuellement disponibles chez L'Air du bois :

  • soixante sept non-libres (38 CC By NC ND, 26 CC By NC Sa, 3 CC By NC)
  • sept libres (4 CC By Sa et 3 CC By)
Boîte japonaise par Zeloko - CC By

Table Basse Circulaire par mokozore - CC By Sa

Table à tiroir par mokozore - CC By Sa

Butaï(s), pour lire des Kamishibaïs par mokozore - CC By

Meuble à langer modulable par mokozore - CC By Sa

Meuble de salle de Bain - Sous Lavabo par mokozore - CC By

Meuble Télé par mokozore - CC By Sa

Sketchchair.cc

Le site Sketchchair.cc propose de concevoir, tester et produire son design de chaise ou de lit.

Répartition des licences sur les 44 designs actuellement disponibles chez Sketchchair.cc :

  • quarante non-libres (37 CC By NC Sa, 1 CC By NC et même 2 avec copyright de base)
  • quatre libres (2 CC By Sa, 2 dans le domain public)
sc.173 par naichieh - CC By Sa

Bed2 par bradjensen68 - domaine public

Small Comfy Chair v1.1 par Chu - CC By Sa

Télécharger ce contenu au format Epub

Lire les commentaires

Le Top 500 des supercalculateurs de novembre 2014

Dimanche 23 Novembre

Le quarante-quatrième Top 500 des supercalculateurs mondiaux est sorti en novembre 2014.

Rappelons que le Top 500 se base sur une soumission volontaire (de nombreuses machines puissantes mais classifiées ne participent pas à la course) et sur un comparateur de performances spécifique extrêmement parallélisable, le code LINPACK, qui concerne la résolution de systèmes d’équations linéaires.

Les Top 500 se suivent et se ressemblent ?

Pour la quatrième fois consécutive, le supercalculateur Tianhe-2 est en tête de liste avec son habituel score de 33,86 pétaFLOPS.

L’évolution par pays

Rien de nouveau sous le soleil (nihil novi sub sole), hormis une entrée en 10e place d'un Cray CS-Storm à 3,57 petaflop/s d'un site gouvernemental étasunien non représenté auparavant.

Statistiques sur la liste

C'est HP qui est en tête de liste suivi de près par IBM (plus de 60% à eux deux), Cray, SGI et Bull étant loin derrière (et Dell et Fujitsu, enterrés).

Les systèmes d’exploitation

Il reste un seul Windows, très en retrait. Le tableau synoptique est très clair, démontrant l'hégémonie des Linux dans le domaine des hautes performances :

Operating System Family Count System Share (%) Rmax (GFlops) Rpeak (GFlops) Cores Linux 485 97.0 303,377,333 446,928,067 22,851,693 Unix 13 2.6 5,101,679 6,118,142 196,224 Mixed 1 0.2 190,900 222,822 65,536 Windows 1 0.2 180,600 233,472 30,720 Télécharger ce contenu au format Epub

Lire les commentaires

Repas du Libre à Toulouse le 27 novembre 2014

Samedi 22 Novembre

Le groupe d'utilisateurs et utilisatrices de Logiciels Libres de Toulouse Toulibre en collaboration avec Tetaneutral.net fournisseur d'accès internet et hébergeur libre proposent aux sympathisants et sympathisantes de se retrouver l'un des mardis ou jeudis de chaque mois pour échanger autour des logiciels Libres, des réseaux libres, discuter de nos projets respectifs et lancer des initiatives locales autour du Libre. Ce repas est ouvert à toutes et à tous, amatrices et amateurs de l'esprit du Libre, débutantes et débutants ou technicien(ne)s chevronné(e)s.

Ce Qjelt aura lieu le jeudi 27 novembre 2014 à 20 heures, au restaurant Bois et Charbon situé au 64 rue de la Colombette à Toulouse. C'est à proximité de la place Saint Aubin accessible par le métro à la station Jean Jaurès (ligne A et B). Entrée/plat/dessert + 1/4 de vin à 18€. Pour des raisons de logistique, une inscription préalable avant la veille au soir est demandée.

Inscription demandée avant le mercredi soir à l'adresse http://www.toulibre.org/qjelt.

Télécharger ce contenu au format Epub

Lire les commentaires

Pages