Accueil › Agrégateur de nouvelles › Sources ›

Linuxfr.org

Version imprimableVersion imprimable
Syndiquer le contenu
URL: http://linuxfr.org/news
Mis à jour : il y a 19 heures 45 min

Revue de presse - décembre 2014

2 décembre, 2014 - 09:39

Les feuilles sont tombées, l'ensoleillement régresse, c'est l'automne et cette année il a un goût de framboise particulièrement prononcé à l'approche de l'hiver.

Planète Linux n°82 propose une sélection des distributions de saison : Ubuntu 14.10, OpenSUSE 13.2 et Deepin 2014. Un article original est destiné à ceux qui se seraient égarés du côté obscur ces derniers temps et souhaiteraient redécouvrir Linux. Pour ceux qui se demandent quel est le meilleur OS pour Raspberry Pi, un comparatif des solutions disponibles apporte des éléments de réponse. D'autres articles complètent ce numéro abordant l'installation d'un système GNU/Linux sur une clé USB ainsi que Linux On Android.

Les éditions Diamond publient un hors-série consacré au Raspberry Pi sous la forme d'un mook de 128 pages. Outre l'aspect matériel très détaillé, il y est également question de l'utilisation de GNU/Linux - majoritaire sur cette plate-forme. Le même éditeur publie également deux autres magazines abordant le Raspberry Pi : OpenSilicium n°13 et Hackable n°3.

Toujours chez le même éditeur, Linux Pratique n°86 aborde entre autre Rundeck (administration de serveurs), Drupal (CMS) et PrestaShop (application web pour le commerce en ligne). Quand à GNU/Linux Magazine France n°177, le dossier porte sur la cryptographie.

Tous ces magazines sont actuellement (ou seront très prochainement) chez les marchands de journaux avec également MISC n°76 qui s'interroge sur la sécurité du cloud et 100% Android n°12 qui balance comment votre smartphone vous espionne. Les sommaires complets sont en ligne via les liens ci-dessous.

Bonne lecture !

Télécharger ce contenu au format Epub

Lire les commentaires

Journée du Libre par Pullco et Corrèze Elab le samedi 13 décembre 2014 à Tulle

2 décembre, 2014 - 09:36

L'Association Pullco organise en collaboration avec Corrèze Elab une Journée du Libre au Centre Culturel et Social de Tulle (Salle Amérique – 36 Avenue Alsace Lorraine, 19000 Tulle) le samedi 13 décembre 2014 de 10h00 à 22h00.

Cette journée sera dédiée à l'impression 3D mais aussi à :

  • la découverte des logiciels libres, tels qu'OpenOffice ou LibreOffice, Firefox, VLC… et des systèmes d’exploitation alternatifs à OS X ou Windows : les distributions GNU/Linux ;
  • l'installation de logiciels libres et de distributions GNU/Linux sur les ordinateurs du public ;
  • l'exploration du monde des logiciels libres par le biais d’ateliers, de conférences, de revues ainsi que de CD mis à disposition du public et d’ordinateurs entièrement pourvus de logiciels et systèmes d’exploitation libres, en démonstration.

Pour plus de renseignements sur le programme, veuillez vous rendre sur le site web de Pullco.

Télécharger ce contenu au format Epub

Lire les commentaires

Install Party GNU/Linux le 20 décembre 2014 à Marseille

2 décembre, 2014 - 08:04

L'association CercLL (CercLL d'Entraide et Réseau Coopératif autour des Logiciels Libres) vous invite à une install party GNU/Linux le samedi 20 décembre 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.

L'entrée est libre, et une participation de 2 euros est demandée. De plus, l'évènement est accessible aux débutantes et débutants. Vous pourrez aussi adhérer à l'association durant un an, pour un montant de 20 euros.

Télécharger ce contenu au format Epub

Lire les commentaires

Mons, le 18 décembre 2014 : l’open hardware dans l’électronique (et au-delà…)

2 décembre, 2014 - 08:00

Ce jeudi 18 décembre 2014 à 19h se déroulera la 34e séance montoise des Jeudis du Libre de Belgique.

Thématique : open hardware

Public: Tout public | entreprises | étudiants

L’animateur conférencier: Robert Viseur est Docteur en Sciences Appliquées, Assistant dans le service d’Économie et de Management de l’Innovation à la Faculté Polytechnique de l’Université de Mons (UMONS) et Ingénieur de recherche Expert au Centre d’Excellence en Technologie de l’Information et de la Communication (CETIC) à Charleroi. Ses domaines d’expertise sont le management de l’Innovation, le logiciel libre et les technologies d’indexation (moteurs de recherche).

Description: depuis les années quatre-vingt, l’open source se développe dans le domaine logiciel avec des succès répétés et illustrés par des communautés populaires comme Linux, Mozilla ou Apache. Les pratiques open source en matière de licences, de modèles d’affaires et de méthodes de développement ont progressivement essaimé vers d’autres domaines que le logiciel, donnant naissance à l’open data, l’open content, l’open hardware ou encore l’open cloud. Les succès récents, dans le domaine de l’électronique, de familles de produits comme Arduino ou Elphel, démontrent que la révolution qui s’est opérée dans le domaine logiciel s’apprête aujourd’hui à se produire dans celui du matériel.
L’exposé proposera dès lors de faire le point sur les types de projets et les projets actuellement actifs dans le domaine de l’open hardware (OpenCollector, OpenCores, Arduino, BeagleBoard, NanoNote,…). Il inclura une présentation des moyens de protection généralement utilisés (Creative Commons, GPL, LGPL,…) ainsi que des entreprises actuellement actives dans ce secteur en développement (Arduino, Gaisler, Elphel,…).
En pratique, si l’open hardware est surtout connu pour ses applications dans le domaine électronique, il englobe également des objets de la vie quotidienne et concerne petit à petit des biens inattendus comme les automobiles. Le secteur automobile voit ainsi les pratiques de co-création se développer depuis quelques années, avec des initiatives telles que le concours de design Peugeot ou la plate-forme participative dédiée à la Fiat Mio. Les pratiques open source s’y développent également, avec des sociétés ou projets comme OSVehicule, Local Motors ou Wikispeed, mêlant création de “Commons”, utilisation de technologies open hardware, exploitation d’outils de fabrication numérique, mise en œuvre de méthodologies Agile et adoption d’architectures modulaires. Cette présentation fera également le point sur ces tendances émergentes et tentera d’en dresser les perspectives.

Lieu de cette séance: Université de Mons, Faculté Polytechnique, Site Houdain, Rue de Houdain, 9, auditoire 12. Entrée par la porte principale, au fond de la cour d’honneur. Suivre le fléchage à partir de là.

La participation sera gratuite et ne nécessitera que votre inscription nominative, de préférence préalable, ou à l’entrée de la séance. Merci d’indiquer votre intention en vous inscrivant via la page http://jeudisdulibre.fikket.com/. La séance sera suivie d’un verre de l’amitié (le tout sera terminé au plus tard à 22h).

Les Jeudis du Libre à Mons bénéficient aussi du soutien de nos partenaires : CETIC, Normation, OpenSides, MeaWeb, NextLab, Phonoid et Creative Monkeys.

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

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

Télécharger ce contenu au format Epub

Lire les commentaires

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

1 décembre, 2014 - 20:38

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

[Les Echos] Richard Stallman (GNU/Linux) défend le logiciel libre à l'Ecole Centrale

Par Florian Debes, le mercredi 26 novembre 2014. Extrait:

Richard Stallman, grand défenseur du logiciel libre et inventeur du système d’exploitation GNU/Linux, tenait conférence, vendredi 21 novembre 2014, devant les anciens élèves des Ecoles Centrales et Supélec. Il critique notamment l'utilisation des logiciels Saas.

Lien vers l'article original: http://business.lesechos.fr/directions-numeriques/0203965181304-richard-stallman-deconseille-le-cloud-public-aux-entreprises-105681.php

Et aussi:

[Bug Brother] Surveillance: pourquoi je suis assez optimiste (à moyen terme en tout cas)

Par Jean-Marc Manach, le mercredi 26 novembre 2014. Extrait:

Dans le prolongement de l’affaire Snowden, la revue Risques de la Fédération française des sociétés d'assurance m'a invité, le 24 juin dernier, à participer à une table ronde réunissant également Philippe Aigrain (@balaitous sur Twitter), co-fondateur de La Quadrature du Net, chercheur et essayiste, Antoine Lefébure (@segalen), auteur de L'affaire Snowden (Ed. La Découverte), Pierre-Olivier Sur, bâtonnier de Paris et Thierry van Santen, directeur général d’Allianz Global Corporate & Specialty SE France.

Lien vers l'article original: http://bugbrother.blog.lemonde.fr/2014/11/26/surveillance-pourquoi-je-suis-assez-optimiste-a-moyen-terme-en-tout-cas

[La Tribune] Démanteler Google: quand les politiques s’invitent dans un dossier de concurrence

Par Delphine Cuny, le mardi 25 novembre 2014. Extrait:

Le Parlement européen devrait se prononcer jeudi sur une motion proposant une scission du géant américain de l’Internet. Si Google n’a pas souhaité réagir officiellement, cette intrusion du politique dans l’enquête antitrust de la Commission l’inquiète. Décryptage

Lien vers l'article original: http://www.latribune.fr/technos-medias/internet/20141125tribc0e2f8db3/demanteler-google-quand-les-politiques-s-invitent-dans-un-dossier-de-concurrence.html

[Next INpact] Éducation: des élus s'inquiètent du coût des tablettes promises par Hollande

Par Xavier Berne, le mardi 25 novembre 2014. Extrait:

Le moins que l’on puisse dire, c’est que la promesse de François Hollande d’offrir des tablettes à tous les élèves de cinquième à partir de 2016 est loin de convaincre… Deux parlementaires de l’opposition ont récemment saisi la balle au bond pour pointer du doigt le coût et l’utilité d’un tel déploiement.

Lien vers l'article original: http://www.nextinpact.com/news/91022-education-elus-sinquietent-cout-tablettes-promises-par-hollande.htm

[Next INpact] Droit d'auteur: critiquée, l'eurodéputée du Parti Pirate répond à Fleur Pellerin

Par Marc Rees, le lundi 24 novembre 2014. Extrait:

Le 18 novembre dernier, devant les ayants droit du Conseil supérieur de la propriété littéraire et artistique, Fleur Pellerin a écorné la décision du Parlement européen de confier à Julia Reda, eurodéputée du Parti Pirate, la rédaction d’un rapport sur l’adaptation de la directive sur le droit d’auteur. Celle-ci vient de répondre à ses remarques.

Lien vers l'article original: http://www.nextinpact.com/news/91065-droit-dauteur-critiquee-eurodeputee-parti-pirate-repond-a-fleur-pellerin.htm

[Numerama] Face à l'omniprésent Wikipédia, Encyclopædia Universalis dépose le bilan

Par Julien L., le samedi 22 novembre 2014. Extrait:

La société éditant l'Encyclopædia Universalis a déposé le bilan, incapable de tenir la distance face à Wikipédia. Elle a été placée en redressement judiciaire et ses perspectives futures sont particulièrement sombres.

Lien vers l'article original: http://www.numerama.com/magazine/31360-face-a-l-omnipresent-wikipedia-encyclopadia-universalis-depose-le-bilan.html

Télécharger ce contenu au format Epub

Lire les commentaires

LibreSSL 2 est bien lancé

1 décembre, 2014 - 14:12

Suite à la découverte des failles sur OpenSSL, les développeurs d'OpenBSD ont publié les premières versions de leur fork LibreSSL : d'abord la 2.0.0 le 11 juillet 2014, puis la 2.1.0 le 12 octobre et la 2.1.1 le 16. Elles sont disponibles sur leur site FTP.
Les buts sont de moderniser la base de code, améliorer la sécurité, et appliquer les bonnes pratiques de développement (modernizing the codebase, improving security, and applying best practice development processes).

Plusieurs projets ont déjà cherché à remplacer OpenSSL. Par exemple, LibreSSL est censé fonctionner sous GNU/Linux, Solaris, Mac OS X ou FreeBSD.

Pour information ou rappel, LibreSSL et OpenSSL sont des implémentations logicielles des standards ouverts Secure Sockets Layer (SSL) et Transport Layer Security (TLS). SSL est l'ancienne version, obsolète. TLS est la version standardisée par l'IETF. Cela permet, par un jeu de clés asymétriques, de chiffrer les flux sur Internet, notamment les sites web, comme ceux des banques (et de LinuxFr.org).

Suite à la gigantesque faille Heartbleed, permettant à un « attaquant » de lire la mémoire d'un serveur ou d'un client pour récupérer, par exemple, les clés privées utilisées, l'équipe de OpenBSD a lancé ce fork de OpenSSL en partant du code de la version 1.0.1g. Les commits sont quasi journaliers et une foultitude de bugs sont rapportés, qui n'étaient pas corrigés depuis plusieurs années.

LibreSSL est composé de quatre parties :

  1. l'utilitaire OpenSSL, qui fournit les outils pour gérer les clés, les certificats, etc. ;
  2. libcrypto : une bibliothèque d'outils fondamentaux pour la cryptographie ;
  3. libssl : une bibliothèque TLS, compatible avec OpenSSL ;
  4. libtls : une nouvelle bibliothèque TLS, conçue pour rendre plus facile l'écriture d'applications infaillibles.

BoringSSL est un autre fork qui a été fait par Google. L’entreprise promet de partager du code et des informations avec le projet LibreSSL. Ce fork est maintenu à un rythme plutôt tranquille, étant né plus comme un repository de patches OpenSSL non-acceptés.

Télécharger ce contenu au format Epub

Lire les commentaires

Les journaux LinuxFr.org les mieux notés de novembre 2014

1 décembre, 2014 - 13:40

LinuxFr.org propose des dépêches et articles, soumis par tout un chacun, puis revus et corrigés par l'équipe de modération avant publication. C'est la partie la plus visible de LinuxFr.org, ce sont les dépêches qui sont le plus lues et suivies, sur le site, via Atom/RSS, ou bien via partage par messagerie instantanée, par courriel, ou encore via médias sociaux.

Ce que l’on sait moins, c’est que LinuxFr.org vous propose également à tous de tenir vos propres articles directement publiables, sans validation a priori des modérateurs. Ceux-ci s'appellent des journaux. Voici un florilège d'une dizaine de ces journaux parmi les mieux notés par les utilisateurs… qui notent. Lumière sur ceux du mois de novembre passé.

D'autres journaux ont dépassé la note fatidique de 25 et mériteraient de faire leur apparition à la une :

Cette extraction est issue de l'aide à la rédaction de dépêche des meilleurs journaux, comme cela est indiqué sur le modèle : cela permet ainsi de participer à LinuxFr.

Télécharger ce contenu au format Epub

Lire les commentaires

Sortie de la version 13.07.01 du logiciel Apache-OFBiz

1 décembre, 2014 - 10:06

La fondation Apache a publié la version 13.07.01 du logiciel Apache-OFBiz. Apache-OFBiz est un logiciel de gestion d'entreprise (ERP ou PGI en français) libre sous licence Apache 2.0, disponible sur système GNU/Linux, Windows et Mac.

Basé sur la technologie web, il permet la gestion de la comptabilité, l'administration des ventes, la gestion des relations client (CRM), la gestion de la chaîne logistique (SCM), la gestion de production (GPAO, MRP), la gestion d'un site e-commerce, la gestion des points de ventes (POS), etc.

Cette nouvelle version est optimisée pour Java 7 et utilise maintenant Log4J2.
De plus, elle n'est plus livrée avec les composants spécifiques (ebaystore, google-checkout, pos, etc.) sauf le composant e-commerce. Les composants spécifiques sont maintenant à télécharger à part. Cette version est identique à la RC de juillet 2013 + les correctifs. Elle devient maintenant la dernière version stable officielle et les utilisateurs de la version 12.04 sont invités à migrer vers celle-ci.

Télécharger ce contenu au format Epub

Lire les commentaires

Kit de construction du village global

1 décembre, 2014 - 09:50

Le précédent article de ce type (« Do It Yourself ») portait sur les fermes de fenêtres (« windowfarms »). Il s'agissait d'enchaîner verticalement et près des fenêtres, dans des bouteilles en plastique coupées, un véritable potager. Une autre conférence TED (Technology Entertainment Design, cycles de conférences sur « la science, les arts, la politique, les questions mondiales, l'architecture, la musique et plusieurs autres sphères de compétences. ») nous présente le « Kit de construction du village global ».

Appel à contributions LinuxFr.org : l'espace de rédaction collaborative est maintenant connu de tous, et très mûr. Nous vous encourageons à publier des articles sur le « bricolage » ou « Do It Yourself » libre et open source.

Le « Global Village Construction Set » (GVCS) est un projet exposé par Marcin Jakubowski : le « kit de construction du village global », ou « Global Village Construction Set » (GVCS) est une plateforme modulaire, à faire soi-même, à bas coût et haute performance, qui permet la fabrication facile de 50 machines industrielles nécessaires pour construire une civilisation petite et néanmoins durable avec le confort moderne. Nous sommes en train de développer des machines industrielles open source qui peuvent être fabriquées pour une partie des prix commerciaux, et partageons nos conceptions en ligne, gratuitement.

Planter une graine

Comme beaucoup de projets libres, celui-ci est né d'un seul homme : Marcin, polonais sur-diplômé (PhD in Fusion Energy), parti vivre aux USA, pour finalement se rendre compte que ses diplômes étaient inutiles, il a créé sa ferme. Mais son tracteur ayant lâché, il s'est retrouvé ruiné. Il a donc essayé et construit ses propres machines et publié ses conceptions en ligne sur un wiki, incluant les modèles 3D, les schémas, des tutoriels vidéo et même les budgets. Il a vu les contributions arriver progressivement, à base de prototypes.

50 machines

Ces 50 machines couvrent des domaines allant de l'agriculture à la génération d'énergie, du transport à l'hébergement, et cela inclut la fabrication de toutes ces machines. Par exemple, un four, une scie industrielle, une plate-forme de forage de puits, une turbine à vent, une scie laser, une micro-maison, et il y en a d'autres.

Décentralisation de la fabrication

Dans un monde commercial, basé sur la rareté et le renouvellement (certains appelleront cela l'obsolescence programmée), il est possible, grâce à l'OpenHardware et le DIY, de créer et fabriquer les machines les plus indispensables à l'humanité, de les maintenir et les réparer à des coûts bien moindres. Le but du projet GVCS est donc d'abaisser les barrières d'entrée, par la décentralisation, à la construction, la fabrication et l'agriculture.

Télécharger ce contenu au format Epub

Lire les commentaires

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

1 décembre, 2014 - 09:43

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

30 novembre, 2014 - 11:52

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 portent 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étracteurs 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 peu inté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 2014 à Paris

28 novembre, 2014 - 22:49

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

27 novembre, 2014 - 13:24

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 !

27 novembre, 2014 - 07:15

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

26 novembre, 2014 - 23:34

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 du référentiel de bonnes pratiques 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

26 novembre, 2014 - 18:10

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

26 novembre, 2014 - 16:07

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-systè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 canal 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 versions 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/s 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

26 novembre, 2014 - 16:06

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

25 novembre, 2014 - 15:37

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

25 novembre, 2014 - 12:00

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