Linux France

S'abonner à flux Linux France
Mis à jour : il y a 5 min 45 sec

Install party lubuntu à Igny (91) les 16 novembre et 13 décembre 2014

Lundi 3 Novembre

Deux install parties lubuntu sont organisées à Igny (Essonne), par l'association SecondeViePC, dans la salle des fêtes de la mairie, pour recycler ses vieux PC. Elles auront lieu les 16 novembre et 13 décembre 2014, de 11h à 17h.

Comment donner une seconde vie à un PC vieux de 2 ans ou même de 10 ans ?

  • Votre ancien ordinateur rame, grogne, bref ne veut plus fonctionner ?
  • Vous avez envie de découvrir un système d’exploitation libre, simple, stable, rapide et sécurisé ?
  • Vous avez entendu parler d’Ubuntu (gnu/linux), mais vous n’osez pas vous lancer seul ?
  • Vous maîtrisez gnu/linux et souhaitez soutenir ceux qui veulent le maîtriser ?

L'évènement est ouvert à tous. Une participation aux frais de 15€ est demandée (clé usb fournie + pizza à midi).

Télécharger ce contenu au format Epub

Lire les commentaires

Documentaire "Les Gardiens du nouveau monde" de Flo Laval

Lundi 3 Novembre

Le 6 septembre dernier, lancelotsix publiait un journal sur le documentaire « Les Gardiens du nouveau monde » de Flo Laval (durée 55min), concernant « l’émergence d’une nouvelle génération de militants hacktivistes ». À l'époque, Mediapart avait publié un article dessus et les abonnés de ce journal pouvaient apprécier la publication en .webm/.ogg. Pour les autres, le DVD pouvait (et peut toujours) être obtenu via l'éditeur.

Dans les commentaires du journal précédent, un lien vers une vidéo non autorisée avait été donné (et bloqué par la maison d'édition), et le réalisateur était venu préciser sa position : « Je suis le premier désolé que ce film ne soit pas en CC. (…) Laissez nous le temps de rentrer dans nos frais, et dans quelques mois, je peux vous assurer que nous mettrons le film en ligne gratuitement ! Je vais même tout faire pour que le producteur le passe dans une licence CC. »

Non seulement il a tenu parole, mais en plus il est revenu l'annoncer : « le film est désormais disponible en consultation libre et licence CC » (CC By-NC-SA). Les esprits chagrins râleront sur la licence non-libre retenue et les autres auront à cœur de remercier l'auteur d'avoir tenu sa promesse et faciliter la diffusion du documentaire.

Et pour revenir au contenu du documentaire : « Le casting des intervenants est assez classique avec pour ne citer qu'eux Jean-Marc Manach ou Jérémie Zimmermann. Notons la présence importante de Okhin (membre de télécomix) aidant le documentaire à traiter des questions d'activisme sur et via internet. Il est également question de vie privée de protection des communications et des enjeux associés. »

« C'est un documentaire qu'il peut être intéressant de faire voir aux personnes peu au fait de ces questions pour les sensibiliser / attiser leur curiosité. »

Télécharger ce contenu au format Epub

Lire les commentaires

Points Libres GNU/Linux, Blender, Logiciels Libres le 3 novembre 2014 à Montpellier

Lundi 3 Novembre

Le lundi 3 novembre 2014 de 14h00 à 19h00 a lieu le rendez-vous mensuel Points Libres proposés par Montpel’libre.

Les Points Libres proposés par Montpel’libre prennent leurs quartiers à la Maison des Adolescents de l’Hérault MDA34 (9, rue de la République 34000 Montpellier). Tous les premiers lundis de chaque mois la MDA hébergera les Points Libres, dans les salles accueil cyberespace et partenaires.

Programme de l'évènement

14h00-16h00 : accueil à la Maison des Adolescents de l’Hérault des personnes qui souhaitent approfondir leurs connaissances sur les systèmes et logiciels libres, Linux ou utiliser librement les ressources numériques, salle accueil PC.

16h00-19h00 : toute une équipe de passionnés, vous proposent l’animation de l’atelier « Points Libres » par les membres de Montpel’libre. Permanence Logiciels Libres, discussions libres et accompagnements des utilisateurs aux systèmes exploitation libres, Linux, Haiku. Installation de Mint, Ubuntu, Emmabuntüs et HandyLinux sur le cyberespace de consultations libres.

16h00-17h00 : introduction à Blender, (inscriptions recommandées).

  • téléchargement et installation ;
  • généralités sur l’image 3D ;
  • présentation générale de l’interface ;
  • découverte des outils de base ;
  • configuration et préférences.

Pour les utilisateurs plus avancés, une aide sur des points précis ou blocages et possible, salle partenaires à l’étage.

Le fond documentaire de la bibliothèque de logiciels libres de Montpel’libre est disponible dans la salle des partenaires.

L'entrée est libre et gratuite pour tout public. De plus, le lieu est certifié « Accessibilité PMR ».

Télécharger ce contenu au format Epub

Lire les commentaires

Rust 0.12 : non, pas le jeu vidéo, le langage !

Lundi 3 Novembre

Le langage de programmation Rust continue son bonhomme de chemin et se prépare à une version bêta 1.0 avant la fin de l'année.

En attendant, Rust 0.12 est sorti le 9 octobre 2014 ! Pour rappel, Rust est un langage de programmation système qui vise la performance et la sûreté. Il est développé par Mozilla, en parallèle d'un nouveau moteur expérimental de rendu de pages web écrit en Rust : Servo.

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

Pour une meilleure compréhension des détails techniques de cette dépêche et des évolutions de Rust, il est conseillé de se référer à la dépêche sur Rust 0.8 (ainsi qu’aux suivantes que vous trouverez via les tags rust et langage_rust).

Sommaire

Évolutions

Depuis sa première sortie en 2012 (voir la dépêche sur la version 0.1), le langage a connu un développement rapide en intégrant des fonctionnalités qui incluent les types de données algébriques, les fermetures, l'inférence de type, la sécurité de la mémoire garantie et un environnement d'exécution minimal.

Depuis la version 0.11, les spécifications du langage ont peu changé.

Principaux changements

Voici une liste laconique des apports majeurs :

  • les annotations de durées de vie ne sont plus obligatoires dans plusieurs cas communs ;
  • clauses where ;
  • notation pour les tranches. C’est un opérateur surchargeable ;
  • travail sur les types à taille dynamique ;
  • plein d’autres RFC implantées, par exemple :
Prochains changements avant la version 1.0

Il y a un an, la version 1.0 était prévue pour la fin 2014. La feuille de route se remplit petit à petit. Cependant, il reste quelques points (attention, c’est un peu technique) :

  • types de taille dynamique : cette extension du système de type permet de gérer des types à taille fixe mais non connue à la compilation ;
  • fermetures unboxed ;
  • types associés ;
  • clauses where ;
  • traits Multidispatch ;
  • destructeurs ;
  • threads verts (green thread).

On trouve également des discussions sur les RFC pour implanter de l’héritage dans Rust.

Plateformes prises en charge

Rust fonctionne sous Windows (7, 8, Server 2008 R2) seulement x86, Linux (diverses distributions) ARM, x86 et x86-64, OSX 10.7 ("Lion") et ultérieurs x86 et x86-64, ainsi qu'Android. Nouveauté toute fraîche, un portage pour Dragonfly BSD a été réalisé avec succès.

Les procédures d'installation déjà en place pour la version 0.8 (pour Windows, Ubuntu, Arch Linux et Gentoo) décrites dans la dépêche d'il y a un an sont toujours valables et ont été mises à jour pour cette version. Dès l'annonce, les paquets pour Ubuntu ont été générés dans le PPA hansjorg/rust, une compilation pour Arch est disponible dans le dépôt [community] et pour Gentoo, l'overlay rust contient un ebuild pour cette version. Le guide — qui remplace le tutoriel — détaille aussi l'installation sur les différentes plateformes.

Des chiffres ! Projets utilisant Rust

OpenHub (anciennement Ohloh) tient des statistiques sur l'utilisation de Rust dans les projets qu'il recense, comme pour tout autre langage. On peut ainsi voir que le nombre de personnes qui modifient du code Rust est relativement faible, mais augmente (de 121 projets pour la version 0.10 à 165 dans les projets recensés et 1 007 386 lignes de code). Par ailleurs, le nombre de projets recensés sur GitHub passe de 1428, lors de la sortie de la 0.10, à 3262.

Computer Language Benchmark Game

Tout d’abord, quelques rappels sur le Computer Language Benchmark Game. C’est un test de performance entre différents langages sur différents tests. Le code source destiné au test pour chaque langage doit utiliser le même algorithme.

Lors de son entrée dans ce fameux test, mentionnée dans la dépêche sur 0.10, Rust montrait des performances inégales en fonction des tests, bons pour fasta (génération et écriture de séquences ADN aléatoires dans le format FASTA) (aussi bon que C++) mais mauvais pour pidgits (calcul de décimales de pi).

Avec la dernière version, le test sur pidgits place le langage à égalité en première place avec le C, avec tout de même une plus grande consommation mémoire. Le langage est même plus performant que C++ pour la moitié des tests.

Pour plus de détails sur les différents tests (algorithme, codes source pour les différents langages), vous pouvez consulter la page qui liste tous les tests.

Outils Gestionnaire cargo

Cargo s'occupe de télécharger les dépendances nécessaires au projet, teste le projet, démarre la compilation (et le binaire).

Par exemple, on peut commencer un nouveau projet avec cargo new bonjour_monde --bin. L'exécution est immédiatement possible avec cargo run.

Tests

Rust est livré avec un système de tests natif. Il prend la forme de directives directement intégrées dans le code source pour les tests unitaires, alors que les tests d'intégration nécessitent la création d'un fichier dédié.

L'exécution des tests fait appel à cargo via un simple cargo test.

Documentation rustdoc

Un autre utilitaire est livré gratuitement avec Rust : rustdoc permet de générer une jolie documentation écrite en Markdown. La syntaxe ne sera déroutante ni pour les moules, ni pour les utilisateurs de GitHub et StackExchange :

/// `bonjour` est une fonction qui souhaite le bonjour à la personne spécifiée en paramètre /// /// # Arguments /// /// * `nom` - Le nom de la personne que vous souhaitez accueillir. /// /// # Exemple /// /// ```rust /// let nom = "Roger"; /// bonjour(nom); // Affiche "Bonjour, Roger!" /// ``` fn bonjour(nom: &str) { println!("Bonjour, {}!", nom); } Formatage

À la manière de gofmt, rustfmt permet de standardiser la manière d'écrire du rust. C'est encore en développement, mais il est possible de le voir en action quand on utilise play.rust-lang.org et qu'on appuie sur le bouton format.

Des frameworks web

De nombreuses bibliothèques sont disponibles, seulement elles ne sont pas encore stabilisées. On compte par exemple, les cadriciels Iron et nickel.rs.

Il existe cependant quelques essais de développements, notamment TodoMVC, qui utilisent nickel.rs.

Liens Notes de version
  • Le Wiki dispose de notes de versions détaillées ;
  • le fichier RELEASES.txt contient aussi des informations sur cette version.
Conclusion

Depuis le début, le design de Rust a beaucoup été simplifié. Les différents symboles indiquant un type de pointeur, à part & et &mut, ont disparu, les clôtures prennent en charge moins d’options, etc. Ceci ne s’est pas fait au détriment de la praticité : on peut en faire autant qu’avant, voire plus.

Tout ces changements sont articulés autour des concepts centraux de propriété et d’emprunt. Introduit pour partager efficacement des données entre tâches, il s’est révélé que cela a permis de déplacer beaucoup de choses dans des bibliothèques.

Rust est donc maintenant beaucoup plus proche du métal qu’il n’était possible de l’imaginer avant. Toutes les constructions du langage se traduisent directement en opérations machines et le runtime est optionnel, permettant d’écrire (par exemple) des noyaux de système d’exploitation.

Note : le runtime est nécessaire pour la gestion des tâches, les pointeurs gérés par un ramasse-miettes, etc. — tout ce qui n’est pas géré par le programme ou les bibliothèques et nécessite un peu de gestion de l’extérieur.

Télécharger ce contenu au format Epub

Lire les commentaires

Les journaux LinuxFr.org les mieux notés du mois d'octobre 2014

Lundi 3 Novembre

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 d'octobre passé.

Ce mois-ci ayant été très prolifique, beaucoup d'autres journaux dépassent les 25 points et auraient pu être sélectionnés :

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.

Télécharger ce contenu au format Epub

Lire les commentaires

XQF 1.0.6, la résurrection

Dimanche 2 Novembre

En juillet 2013, MCMic proposait aux lecteurs de LinuxFr.org d’occuper leur été en contribuant à un jeu libre et proposait une liste de jeux intéressants qui avaient fortement besoin de contribution. J’avais rajouté en commentaire un autre projet qui n’était pas un jeu en lui-même, mais qui était très utile aux joueurs et qui avait grandement besoin de contributions : XQF.

Et voilà, finalement je m’y suis collé ! XQF est un logiciel libre qui liste des serveurs de jeu en ligne pour permettre au joueur de trouver facilement une partie qui lui plaît. XQF est certainement un des plus anciens dans sa catégorie (créé en 1998) et, oui, il est donc toujours actif, incroyable ! (tous les détails dans la suite de la dépêche)

Sommaire Résumé

8 ans après la publication de la version 1.0.5 et un petit peu plus d’un an après l’invitation de MCMic, voici la version 1.0.6 ressuscitée et remise à jour par votre serviteur ! XQF 1.0.6 a été publié le dimanche 26 octobre 2014 et une mise à jour 1.0.6.2 a été faite ce 2 novembre (il faut dire que fêter une résurrection le jour des défunts, ça a son charme).

De très nombreux jeux ont été ajoutés. Mais pendant tout ce temps, l’un a eu le temps d’être forké 4 ou 5 fois et l’autre de devenir libre, puis à nouveau propriétaire… Le gros défaut d’XQF était de ne plus proposer une liste de jeux pertinente ! Le code a été quelque peu rafraîchi et la traduction française a été complétée, et très soignée !

Il reste encore plein de vieilleries dans le code, mais XQF n’a jamais été aussi stable. Vous trouverez le détail de toutes ces bonnes choses dans la suite de la dépêche. Pour l’occasion le dépôt a migré de subversion vers git avec l’aval de l’équipe originelle, afin de faciliter les contributions (à commencer par les miennes).

À quoi sert XQF ?

Chaque jeu possède habituellement son propre explorateur de serveurs en ligne, intégré au jeu lui-même, mais cela signifie qu’il faut lancer chaque jeu un par un pour lister toutes les parties jouables de ces différents jeux.

XQF permet à l’utilisateur de lister les jeux multijoueurs qu’il a installés (et proposés par XQF) et, pour chacun de ces jeux, XQF fournit une liste de serveurs maîtres (modifiable). Les serveurs maîtres sont les serveurs qui listent les serveurs qui hébergent des parties jouables. XQF forme alors une liste unifiée de serveurs de jeu avec le nom du serveur, le type de jeu, le nombre de joueurs actuellement présents et la plupart du temps les noms des joueurs connectés. Les jeux (et les serveurs maîtres) sont affichés dans la colonne de gauche et la liste des serveurs disponibles est affichée à droite, en fonction de la sélection de l’utilisateur. Il suffit alors de double-cliquer sur un serveur ou de cliquer sur « Connexion » pour que XQF lance le jeu avec les bons paramètres.

Exemple d’explorateur de serveur de jeu intégré, celui d’Unvanquished. À l’heure où cette copie d’écran a été faite, il valait mieux chercher un autre jeu… XQF est là pour ça !

XQF centralise au même endroit les listes de plusieurs jeux, ainsi on peut par exemple décider de jouer à un jeu parce qu’il est fréquenté à ce moment là ou parce qu’un autre joueur particulier est présent et on peut donc savoir sur quel jeu il joue à cet instant.

Jeux ajoutés

De nombreux dérivés des moteurs id Tech ont été ajoutés, mais pas seulement !

  • Xonotic est un fork du jeu Nexuiz dont le développement a été arrêté par son développeur principal (et qui a revendu le nom), la communauté de joueurs a donc migré vers Xonotic. Les joueurs pouvaient configurer XQF pour traiter Xonotic sous le nom de Nexuiz, mais voici une solution plus adaptée.
  • Unvanquished, un fork en développement actif du jeu Tremulous désormais arrêté. La communauté de joueurs de Tremulous est très dispersée, entre ceux qui jouent toujours à l’antique Tremulous 1.1.0, ceux qui jouent à la GamePlayPreview du développement abandonné de Tremulous 2 et ceux qui jouent à ses mods comme TremFusion… Le jeu Tremulous était un des derniers jeux ajoutés avant que le développement d’XQF ne se mette en pause. J’ai donc ajouté Unvanquished, Tremulous GPP et TremFusion afin de permettre aux joueurs de rejoindre facilement un serveur peuplé, quelle que soit la version du jeu.


N’hésitez plus entre Unvanquished et Tremulous, jouez au jeu auquel d’autres jouent en même temps que vous.

  • Smokin'Guns, un jeu de tir à l’âge du Western américain, façon Le bon, la brute et le truand.
  • Urban Terror, un jeu qui exploite un scénario désormais très classique dans le genre : « forces spéciales contre terroristes ». Ce jeu avait été en fait ajouté dans la version 1.0.5.2, jamais annoncée et très peu distribuée en dehors du dépôt svn… À l’époque le jeu était basé sur ioquake3 et s’appelait ioUrbanTerror, désormais le moteur de jeu n’est plus libre et est basé sur le SDK d’id Software et une migration sur le nouvel Unreal Engine 4 est en cours… Autant dire que sans la publication de cette nouvelle version d’XQF, ce jeu aurait été ajouté pour rien !
  • OpenArena, un projet qui ambitionne d’être un clone libre de Quake Ⅲ Arena et donc de fournir des cartes libres en remplacement de celles de Quake 3. Il n’est peut-être pas aussi soigné, mais il est tout à fait jouable et on trouve beaucoup de serveurs disponibles.
  • World of Padman, un FPS très coloré.
  • ZEQ2 Lite qui emmène le joueur dans l’univers de Dragon Ball Z.
  • Alien Arena, un FPS se déroulant dans un univers de science fiction façon années 50 et avec des extra terrestres à la manière de Mars Attack, et basé sur le moteur CRX (un fork d’id Tech 2).
  • Quelques autres mods plus anecdotiques comme Reaction, Turtle Arena ou Q3 Rally.
  • Jedi Knight 2: Outcast, XQF proposait déjà la prise en charge de Jedi Knight 3: Academy et un contributeur avait proposé en 2008 un patch pour l’épisode précédent. Il aura fallu du temps pour qu’une personne y jette un œil, mais voilà, patch accepté !

  • OpenTTD, est une réécriture libre du jeu original Transport Tycoon Deluxe, un « jeu de simulation jeu de gestion et planification urbanistique ». Attention, pour interroger les serveurs de ce jeu une mise à jour de QStat est nécessaire. Cette mise à jour est déjà très ancienne mais beaucoup de distributions ne distribuent que des versions préhistoriques de QStat.
  • Enemy Territory: Quake Wars, un jeu dans la lignée de Wolfenstein:Enemy Teritory mais se passant dans l’univers de Quake.
  • Enemy Territory: Legacy, l’initiative qui maintient et améliore le code libre du jeu Wolfenstein: Enemy Territory.
Mises à jour et nouveautés
  • L’icône d’XQF a été redessinée en SVG, afin d’être rendue proprement sur nos bureaux modernes qui ont tendance à afficher de très grandes icônes !

  • XQF respecte désormais la spécification XDG pour les répertoires de base, en particulier les chemins des fichiers de configuration. Le dossier de configuration, anciennement nommé ~/.qf/, se trouve désormais dans $XDG_CONFIG_HOME/xqf/ (généralement ~/.config/xqf/). XQF 1.0.6 détecte automatiquement lorsqu’un ancien dossier de configuration existe et le déplace vers son nouveau chemin.

  • Unvanquished, Wolfenstein: Ennemy-Territory et Savage utilisent des codes couleurs étendus et XQF ne filtrait que les codes couleurs de Quake 3, ce qui avait pour conséquence de laisser apparaître les balises étendues dans les noms de serveurs ou de joueurs. C’est corrigé !

  • La liste des serveurs maîtres a été mise à jour (par exemple, le maître ioquake3 remplace celui d’id Sofware) et de nombreux jeux ont vu leur numéro de version de protocole actualisé (notamment War§ow qui change cela souvent…).

  • XQF ne plante plus lorsqu’un serveur envoie un caractère spécial. En fait, le bug est ancré très profondément : XQF lit la sortie de Qstat en mode raw et Qstat utilise le codage ISO-8859-1 en sortie raw. Or, XQF est localisé en UTF-8, et g_io_channel_read_chars retourne une erreur lorsqu’il reçoit un caractère non UTF-8. La solution élégante serait de réécrire toute cette partie en utilisant la sortie XML de Qstat qui peut être demandée en UTF-8, mais dans l’immédiat, un contournement simple et efficace a été trouvé : le flux brut de Qstat est lu en mode binaire (g_io_read_chars laisse alors tout passer) et les caractères non ASCII sont ensuite filtrés. Les serveurs qui retournent des caractères spéciaux sont rares et, en attendant une éventuelle prise en charge de la sortie XML de Qstat, on évite au moins de planter XQF parce qu’il y a un serveur allemand parmi mille sur cette planète qui envoie un caractère ß. Begrüßen !

Corrections et nettoyage

Le code obsolète est en cours de nettoyage ; il reste encore plein de choses à nettoyer, mais j’ai priorisé le nettoyage de code obsolète qui était devenu cassé à cause de changements dans des bibliothèques tierces (Glib je pense à toi). Ce qui marche en mode compatibilité est laissé en l’état pour cette version et sera corrigé à partir de cette publication. En effet, à défaut d’avoir pu faire du release early, release often, au moins je veux faire du oui, mais pas trop tard.

Mais surtout, en corrigeant plusieurs problèmes, je me suis rendu compte qu’au moins trois d’entre eux étaient présents dès le premier commit sur le tout premier dépôt CVS en l’an 2000…

Lorsque XQF filtrait les balises couleurs dans les noms de serveurs, il lisait parfois un caractère en dehors des limites d’une chaîne de caractères, ce qui provoquait plus tard une erreur de malloc à un moment toujours inattendu…

En portant le mécanisme de lecture de descripteur de fichier vars GIOchannel, j’ai corrigé un bug qui était dû à un Gobject nettoyé plusieurs fois (plus exactement le descripteur de fichier où XQF lisait la sortie de Qstat), ce qui signifie qu’avec un peu de malchance on essaie de libérer un zone déjà réutilisée et hop le segfault.

Plus anecdotique, il manquait une virgule dans une liste de paramètres de jeu de Quake 2, ce qui concaténait deux paramètres en un…

De nombreux patchs qui étaient maintenus par Debian en marge du projet ont été importés, afin de simplifier le travail de paquetage par les distributions. Avec le temps cette pile de patchs était devenue la seule version d’XQF compilable, désormais cette branche a été fusionnée avec le tronc commun. Un grand merci à Jordi Mallach de chez Debian pour avoir maintenu XQF pendant toutes ces années de vaches maigres !

Ce qui est abandonné

La prise en charge de GTK+1 est définitivement enterrée et seule la version GTK+2 est prise en charge. Le nettoyage du code a commencé, mais pour le moment, c’est plus une décision politique qu’une réalisation technique : il s’agit de se libérer d’une contrainte et de pouvoir continuer le développement la tête libre, sans se soucier des vieilleries. Ainsi, il devient plus facile de remplacer les appels de fonctions obsolètes.

Et oui il serait peut-être temps, on ne va pas attendre GTK+4 pour acter la migration vers GTK+2 !

Bugs connus

Pour le moment, XQF n’indique plus la progression de l’actualisation d’une liste de serveurs (mais XQF indique lorsqu’il a terminé de le faire). Cette régression est due à une réécriture de l'analyseur de liste de serveurs obtenue par les serveurs maîtres et de l'analyseur de description de chacun de ces serveurs. Ces analyseurs étaient cassés suite à l’obsolescence de plusieurs composants utilisés et le comportement était erratique. Le retour visuel de l’actualisation est encore manquant, mais l’urgence était de faire en sorte que XQF n’arrête pas cette actualisation en cours de route quand quelque chose lui déplaît…

Lorsque l’on met à jour une liste de serveurs et que l’option d’actualisation des information de ces mêmes serveurs est activée, l’actualisation se fait correctement sauf pour la liste des joueurs connectés. Une actualisation normale met à jour cette liste.

Ces bugs ne portent pas atteinte à la stabilité de XQF.

Télécharger XQF 1.0.6

Les sources d’XQF peuvent être téléchargées sur la page dédiées aux archives de version.

XQF 1.0.6 est déjà en cours d’intégration dans Debian et Ubuntu, les plus bidouilleurs pourront donc essayer d’installer les versions 1.0.6 déjà empaquetées par Debian ou par Ubuntu mais non encore officiellement distribuées.

Pour des raisons administratives, la version 1.0.6 correspond à la révision qui a été utilisée pour se faufiler in extremis avant le gel de Debian Jessie. La version 1.0.6.1 correspond à l’incorporation dans la branche principale d’un patch qui a été écrit pour permettre à Debian (et certainement d’autres distributions) d’empaqueter proprement XQF. La version 1.0.6.2 correspond à quelques corrections de langue française en vue de la présente dépêche.

Vous pouvez donc dès maintenant télécharger XQF 1.0.6.2 « édition spéciale LinuxFr.org » en cliquant sur le lien suivant :

Lien suivant. ;-)

Contribuer

Le dépôt a migré depuis un vieillissant dépôt subversion hébergé par SourceForge vers un tout nouveau dépôt git hébergé par GitHub.

Cette version n’ambitionne pas d’être parfaite, elle ambitionne seulement de remettre XQF sur les rails. Si de nouveaux jeux ont été ajoutés, il est possible que certains autres soient moins bien pris en charge maintenant qu’avant par la seule force du temps et de l’obsolescence. De nombreuses choses sont à améliorer et à réécrire dans le code.

Cette publication est donc aussi faite dans le but de soumettre XQF à quelques paires d’yeux supplémentaires. N’hésitez pas à vous servir d’XQF, et je vous invite fortement à rapporter des bugs (ici), et si vous trouvez une solution, n’hésitez pas à forker puis proposer vos corrections !

Télécharger ce contenu au format Epub

Lire les commentaires

OpenBSD 5.6

Dimanche 2 Novembre

Mois de novembre oblige, une nouvelle version d'OpenBSD est publiée. Nous sommes désormais en version 5.6.

OpenBSD est un système d'exploitation orienté sécurité et réseau, dont les principaux avantages sont la stabilité, grâce aux audits sur le code source, mais également l'ensemble très large de fonctionnalités réseau qu'il fournit. L'équipe d'OpenBSD s'est notamment illustrée cette année par son fork d'OpenSSL, LibreSSL

Mises à jour Logiciels
  • Xserver 1.15.2
  • Gnome 3.12.2
  • KDE 4.13.3
  • PostgreSQL 9.3.4
  • Firefox & Thunderbird 31
  • PHP 5.4.30 et 5.5.14
  • et bien d'autres…
Ajouts

Plusieurs logiciels ont été ajoutés, remplaçant certains anciens logiciels :

Suppressions

Plusieurs logiciels ont été supprimés de la distribution OpenBSD :

  • Spray.
  • Il n'est plus possible d'utiliser ppp dans l'espace utilisateur, et le daemon ppd a été supprimé.
  • Apache est supprimé, et on lui préfèrera nginx(8) (qui sera supprimé pour la version 5.7).
  • rsh(1) a été supprimé.
  • rdist(1) a été supprimé.
Améliorations
  • Les services prennent désormais en compte la variable daemon_timeout définissant une limite de temps d'allumage.
  • Une réécriture du programme apropos(1) a eu lieu ; on peut maintenant faire des recherches plus poussées à l'aide d'une base de données makewhatis(8).
Réseau
  • npppd, le démon PPTP/L2TP d'OpenBSD peut désormais écouter plusieurs interfaces réseau.
  • IPv6 est désormais désactivé par défaut sur les interfaces. Il s'active lors de l'ajout d'une adresse IPv6 sur celles-ci.
  • Le système de qualité de service ALTQ a été supprimé.
Sécurité
  • Relayd dispose d'une fonctionnalité de séparation des privilèges lors de l'utilisation de clefs privées.
  • Gestion des enregistrements DNS SSHFP pour les types de clef ED25519.
  • Suppression de Kerberos.
  • LibreSSL remplaçant OpenSSL, SSLv2 n'est plus supporté.
  • L'authentification MSChapv1 a été supprimée de pppd.
Packet Filter
  • Lors d'une translation de paquet d'une famille d'adressage à une autre, les paquets générés gardent le champ TOS/Traffic Class du paquet original.
  • pfctl interdit désormais les règles de translation d'adresse contenant à la fois des IPv4 et IPv6.
Pilotes
  • La prise en charge des cartes SCSI QLogic ISP HBAs a été ajoutée au travers du pilote qlw.
  • Prise en charge des cartes Realtek 8168G.
  • Meilleure gestion des disques 4k (growfs fsck_ffs tunefs…).
  • La prise en charge du bluetooth a été supprimée. Cela ne fonctionnait pas correctement.
  • Prise en charge du multi-chemin SCSI.
  • Des améliorations ont été apportées à la mise en veille et au retour de veille pour les cartes graphiques Intel et AMD.
Performances
  • Les appels à getuid, getgid, getresuid, setreuid and setuid ne nécessitent plus de verrou noyau.
  • Amélioration des performances d'hibernation.
Installeur
  • Il n'est plus possible d'installer OpenBSD via un FTP ou des cartouches.
Télécharger ce contenu au format Epub

Lire les commentaires

L'informatique pédagogique primaire à Genève avec GNU/Linux

Dimanche 2 Novembre

Le Département de l'instruction publique, de la culture et du sport du canton de Genève (Suisse) est heureux d'annoncer que, depuis janvier 2014, l'ensemble des 2 000 ordinateurs à usage pédagogique de l'enseignement primaire fonctionne exclusivement avec configuration libre.

Ceci après une année de validation de l'usage pédagogique d'une configuration basée sur GNU/Linux dans deux écoles pilotes volontaires, puis une année de validation globale du concept dont le déploiement et la gestion à distance dans plusieurs établissements primaires

L'opération consistant à installer une distribution GNU/Linux (Ubuntu) a été menée établissement par établissement durant toute l'année 2013.

Chaque ordinateur possède trois sessions :

  • une pour les élèves du cycle élémentaire ;
  • une pour ceux du cycle moyen ;
  • une pour les enseignant-e-s.

Télécharger ce contenu au format Epub

Lire les commentaires

Retrouvons-nous pour échanger autour des outils de développement de Firefox OS

Samedi 1 Novembre

Une petite news pour annoncer la création d'un groupe autour de Firefox OS. l'objectif est de se retrouver pour échanger sur Firefox OS. La première rencontre aura lieu le jeudi 6 novembre avec comme sujet les outils de développement de Mozilla Firefox OS.

Trois présentations auront lieu ce soir là, après une introduction par Tristan Nitot :

• présentation de l'architecture de Firefox OS : Gaia, Gecko, Gonk, par Loïc Cuguen ;
• sécurité : la gestion des app et des API, par Stéphanie Ouillon ;
• outils de développement : Firefox OS Developer Tools, par Jan Keromnes.

Cela se passe chez Mozilla, au 16 bis Boulevard Montmartre, Paris. Venez nombreux, on prévoit aussi un hackathon pour la fin de Novembre.

Télécharger ce contenu au format Epub

Lire les commentaires

Stand jeux libres au salon informatique de Lamballe le 29 novembre 2014

Samedi 1 Novembre

L'association LanPower tiendra un stand jeux libres au salon informatique de Lamballe (22) le 29 novembre. Ce salon local est organisé par Lamballe Communauté Numérique (LCN), situé à la Cyberbase de Lamballe. Absent de ce salon en 2013, nous y retournons pour la deuxième fois après un certain succès en 2012.

Comme la dernière fois nous présenterons le concept des jeux libres et l'ensemble des jeux référencés par l'association sur ses compilations, CD/DVD et clés USB. En outre l'association tiendra un atelier "Démonte tout !" qui consiste à démonter des objets pour découvrir ce qu'il y a à l'intérieur.

Télécharger ce contenu au format Epub

Lire les commentaires

Publication de supports de formation Yocto Project et OpenEmbedded

Samedi 1 Novembre

Dans le monde Linux embarqué, OpenEmbedded et Yocto Project font partie des build system parmi les plus populaires et les plus complets. Ces build system servent à automatiser la compilation croisée des différents composants d'un système Linux embarqué à partir des sources, permettant ainsi d'obtenir des systèmes beaucoup plus configurables et optimisés que ce qu'il serait possible d'obtenir avec des distributions pré-compilées telles que Debian.

La maîtrise de ces build system n'est en revanche pas aisée, et Free Electrons a donc développé une formation pour apprendre à utiliser ces outils. Comme Free Electrons le fait pour toutes ses formations, nous venons de publier sous license Creative Commons Attribution Share-Alike les supports de cette toute nouvelle formation :

  • slides de la formation, en PDF (1,5 Mo) ;
  • énoncé des travaux pratiques, en PDF (5 Mo) ;
  • agenda de la formation, en PDF (720 Ko) ;
  • données nécessaires pour les travaux pratiques, en tarball (28 Ko).

Nous publions également les sources LaTeX de ces supports, dans notre dépôt Git, dans lequel se trouve également les sources des supports de nos formations Linux embarqué, noyau Linux et Android. Tout un chacun peut donc profiter de ces supports pour se former sur ces thématiques !

Télécharger ce contenu au format Epub

Lire les commentaires

Red Hat Enterprise Linux 6.6

Vendredi 31 Octobre

Red Hat a annoncé le 14 octobre dernier la version 6.6 de Red Hat Enterprise Linux (RHEL), distribution commerciale destinée aux professionnels et aux entreprises. Pour rappel, RHEL 6 existe depuis novembre 2010 et, même si RHEL 7 est disponible depuis le mois de juin dernier, cette version est toujours maintenue.

Cette version 6.6 apporte malgré tout des améliorations, mais principalement du côté de la virtualisation et de la haute disponibilité. Red Hat avait annoncé la version bêta près de 5 mois auparavant, soit le 12 août dernier.

Une sélection des améliorations se trouve en deuxième partie de dépêche.

Matériel

Signe que cette version n'est plus le fer de lance de Red Hat, il y a moins d'ajout de nouveau matériel : les seules nouveautés sont l'ajout du contrôleur Intel Wildcat Point-LP PCH et celui du processeur VIA VX900.

Réseau

Si vous êtes utilisateur de l'addon High Performance Networking (HPN), sachez qu'il va y avoir un gros changement ! En effet, l'addon disparaît et ses fonctionnalités sont basculées dans le canal de base de la distribution.

À noter aussi un autre changement d'envergure, à savoir la mise à jour de l'implémentation du protocole RDMA over Converged Ethernet (RoCE).

Stockage

Une nouvelle cible du device mapper apparaît, nommée dm-cache : elle permet à des périphériques de stockage rapide d'agir en tant que cache pour des périphériques moins rapide. On peut comparer cette manière de faire à celle d'un disque dur hybride.

Autre nouveauté, mais cette fois-ci en avant-première technologique, présente dans le paquet device-mapper-persistent-data package : la fonctionnalité dm-era. Cela permet de garder une trace des blocs écrits sur un périphérique sur une durée pré-définie. Les logiciels de sauvegarde peuvent alors garder une trace des blocs modifiés par exemple.

Sécurité

Red Hat annonce la revalidation de plusieurs outils à la norme FIPS 140 de niveau 1. Cela concerne :

  • OpenSSH (client et server) ;
  • Openswan ;
  • dm-crypt ;
  • OpenSSL ;
  • Suite B Elliptic Curve Cryptography (ECC) ;
  • l'API de chiffrement du noyau ;
  • les chiffrements AES-GCM, AES-CTS et AES-CTR.

Moins vendeur, mais malgré tout important, AIDE, le logiciel HIDS par défaut de RHEL est mis à jour, et corrige deux problèmes : le premier est une mauvaise initialisation d'AIDE si des fichiers de type "prelink" sont détectés mais que le paquet prelink n'est pas installé. Le second quant à lui est un segfault causé par une mauvaise gestion du paramètre "report_attributes".

Virtualisation

Les nouveautés apportées par RHEL 7 du côté de la compatibilité avec la solution Hyper-V de Microsoft entrent dans RHEL 6 ! Cela commence par un nouveau paquet, nommé hyperv-daemons. Ce paquet inclut le démon Hyper-V KVP (autrefois fourni par le paquet hypervkvpd), mais aussi hv_fcopy (qui était fourni lui par le paquet hypervfcopyd).

Autre amélioration aussi, mais en avant-première technologique : RHEL 6.6 est utilisable comme machine virtuelle de génération 2 avec un hôte Microsoft Hyper-V Server 2012 R2.

Performances

Pour finir cette sélection des nouveautés de RHEL 6.6, un petit mot sur les performances avec l'apparition du PCP (pour Performance Co-Pilot). Le principe est d'apporter un cadriciel et des services pour surveiller et gérer les performances du système. PCP est décrit dans la note de version comme léger, ayant une architecture distribuée et adapté à une analyse centralisée de systèmes complexes.

Des métriques de performances peuvent être ajoutées grâce à des interfaces en Python, Perl ou C++. Des API sont disponibles pour les outils d'analyse. Les paquets correspondant à cette nouveauté sont pcp, pcp-doc et pcp-libs-devel.

Télécharger ce contenu au format Epub

Lire les commentaires

NetBSD 6.1.5 et 6.0.6

Vendredi 31 Octobre

La fondation NetBSD a annoncé le 6 octobre dernier deux nouvelles versions de leur système d'exploitation éponyme. Point de nouvelle fonctionnalité ici, il ne s'agit que de correctifs de bogues, et surtout de sécurité.

Ces deux nouvelles versions apportent d'ailleurs les mêmes correctifs et améliorations, qui seront détaillés en deuxième partie de dépêche.

Commençons par la liste des avis de sécurité corrigés dans ces deux versions :

Deux autres problèmes de sécurité ne nécessitant pas un avis ont été corrigés. Le premier concerne l'appel système mount, qui pouvait être utilisé par un utilisateur local pour causer un kernel panic. Le deuxième concerne OpenPAM, dont le parseur gérait mal les erreurs dans la policy PAM. Ce problème de sécurité est d'ailleurs identifié par un numéro de CVE : CVE-2014-3879.

Au niveau du noyau en lui-même, deux kernel panic ont été corrigés, ainsi que des débordements ou corruption de mémoire, tout cela accompagné d'une race condition dans tap(4).

Afin de profiter d'un système actuel, quelques mises à jour bienvenues sont poussées :

  • tzdata2014g ;
  • bozohttpd 20140708 ;
  • openssl 1.0.1i ;
  • named : le fichier root.cache en date du 2 juin 2014 est employé.

Certaines corrections ne sont applicables qu'à certaines architectures. Par exemple, si vous avez un système Alpha, l'installeur arrive maintenant à gérer correctement les labels disques Tru64 (port-alpha/48697). Une erreur de segmentation est corrigée dans le cas où vous auriez un noyau SPARC64 mais les outils utilisateurs en 32 bits.

Enfin, sur les architectures next68k, un cas de kernel panic a été corrigé en déplaçant les calculs de mémoire physique avant l'initialisation de nptpage (port-m68k/45915).

Télécharger ce contenu au format Epub

Lire les commentaires

Atelier « Découverte des Logiciels Libres Scribus »

Vendredi 31 Octobre

L'association CercLL en collaboration avec Yves Specht vous invite à l' Atelier du Samedi Libre qui se déroule le samedi 15 novembre 2014 de 14h30 à 17h30, à la Fabulerie, 4 rue de la Bibliothèque, 13001 Marseille.

Ces ateliers se déroulent en général sur une séquence hebdomadaire, de 2 à 3 séances de travail et sur un thème déterminé. Comme le mot atelier le laisse présumer, dans ce cadre, nous proposons une approche pratique des outils libres.

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

Scribus est un logiciel libre de Publication Assistée par Ordinateur (PAO), distribué sous licence GNU GPL. Il convient pour la réalisation de plaquettes, de livres et de magazines. Scribus est multiplate-formes.

Prérequis

Les personnes qui veulent participer à ces ateliers devront s’inscrire à la Fabulerie 4 rue de la Bibliothèque 13001 Marseille ou sur notre site CercLL au http://cercll.wordpress.com/contact/.

L'atelier n'aura lieu que si 4 personnes,au moins sont inscrites. L’inscription équivaut à un engagement moral de participation.

Télécharger ce contenu au format Epub

Lire les commentaires

Agility Training - Un site internet pour créer et partager des parcours d’agility

Vendredi 31 Octobre

Agility Training est un site internet permettant aux utilisateurs de créer et partager des parcours d’agility : http://agility-training.fr/fr/.

L'agility consiste à réaliser un parcours composé d'agrès avec son chien. Les agrès sont divers : saut, passerelle, tunnel… Le maître doit guider le chien afin qu'il réalise le parcours. Cette discipline est connue pour créer une grande complicité entre le maître et le chien.


source de l'image: Wikipedia

La discipline est de plus en plus populaire, il y a de plus en plus de compétiteurs et de concours. Les compétiteurs créent régulièrement de nouvelles méthodes d'entraînement et de nouveaux parcours. C'est ce dernier point qui nous intéresse.

Tous les jours de nouveaux parcours sont créés et partagés sur Internet, le partage se fait par le biais d'un fichier image qui est un dessin du parcours. L'idée est donc de créer un site internet permettant de créer des parcours en ligne, de les partager, les modifier et permettre de faire des recherches.

La première étape consistait à permettre la création et le partage d'un parcours. C'est aujourd'hui fini et utilisable sur le site internet Agility-Training.

La seconde étape va consister à permettre la recherche dans la bibliothèque de parcours, allant de la recherche par nom ou par tag jusqu'à la recherche sur des critères tels que le nombre d'obstacles. Beaucoup de personnes possèdent des obstacles chez eux à la maison mais sont limités ( 3 sauts, 1 tunnel, …), il est donc intéressant de leur permettre d'utiliser ce type de critères lors des recherches.

Informations techniques

Le site internet est écrit en Python avec le framework Django. L'éditeur de parcours est écrit en Javascript. Le code source et les médias sont sous licence Apache Version 2.

Le site internet Agility-Training est exactement le code disponible sur github, vous pouvez donc allez dessus pour voir l'application.

Télécharger ce contenu au format Epub

Lire les commentaires

Bug Squashing Party européenne chez Mozilla Paris

Vendredi 31 Octobre

Une Bug Squashing Party Mozilla, c'est un week-end consacré à la recherche et la résolution de bugs via Bugzilla (ou un autre logiciel de résolution de bugs des outils Mozilla). D'ailleurs, c'est ce week-end (1er et 2 novembre 2014) dans les bureaux de Mozilla à Paris.

Venez apprendre ce qu'est Bugzilla, comment ça marche, puis ouvrez votre premier bug, ou écrivez votre premier patch. :)

Vous voulez contribuer au code de Firefox OS ? Intervenir sur la machine virtuelle JavaScript ? Donner un coup de main sur le moteur de rendu graphique de Firefox ? Des employés de Mozilla seront là pour vous, partageront avec vous leur expérience, vous expliqueront les processus existants chez Mozilla et auront le plaisir de revoir votre code.

Un événement similaire se tiendra dans les bureaux de Mozilla Londres en parallèle, nous échangerons avec eux et tenterons de gagner le trophée mis en jeu pour cette première Bug Squashing Party européenne !

Vous n'avez jamais contribué au code de Mozilla mais pensez en avoir les compétences ? Alors ce week end est fait pour vous. Venez avec votre ordinateur et votre téléphone Firefox OS si vous en avez un :)

Voici les employés qui seront présents et de leurs spécialités :
- Nical travaille dans l'équipe GFX sur la partie graphique du moteur de rendu, écrite en C++. Cela correspond à l'accélération matérielle, compositing, WebGL … de Firefox (toutes plateformes confondues, dont FirefoxOS). Il sera disponible les deux jours. Plus d'informations.
- nbp travaille sur le moteur JavaScript, une machine virtuelle qui vise à évaluer le code JavaScript efficacement. Cette machine virtuelle est implémentée en C++, elle réalise deux compilations à la volée et une compilation à l'avance. Il sera disponible les deux jours. Plus d'informations. Encore plus d'informations
- Julien mentorera directement les bugs Firefox OS de l'application SMS/MMS. Il sera disponible le samedi. Plus d'informations.
- Johan fait partie de l'équipe QA (Quality Assurance). Utilisateur de Firefox OS ? Envie de chercher la petite bête et de trouver des bugs ? Durant son atelier, nous ferons le tour de ce que Mozilla fait pour chercher les bugs et comment vous pouvez aider à en trouver et surtout, à le faire savoir. Ensuite, une heure sera consacrée à l'installation de la dernière version de Firefox OS et des outils utiles. Amenez votre ordinateurs portables et, si vous en avez un, votre téléphone Flame. Disponible le samedi.
- Dietrich travaille sur Firefox OS, dont il est responsable technique. Il sera présent samedi pour mentorer les bugs sur tous les composants de Firefox OS. Les dialogues avec lui se feront en anglais.

Le programme : Samedi 13:30 - Ouverture 14:00 - Introduction 14:15 - Installation de l'environnement de développement & présentation de bons premiers bugs 16:00 - Écrasons des bugs ! 20:00 - Pizzas 21:00 - Plus de bugs pour ceux qui le veulent Dimanche 11:00 - Café & bugs 12:00 - Brunch 14:00 - Encore des bugs 18:00 - Apéro Télécharger ce contenu au format Epub

Lire les commentaires

systemd version 216

Vendredi 31 Octobre

Le programme d’init systemd est sorti dans une nouvelle version. Par tradition, cette version ne se contente pas des habituelles corrections de bogues et modifications mineures, mais inclut de nouvelles options qui peuvent affecter tout le monde (sauf les irréductibles de *BSD, bien sûr). Cette dépêche présente un aperçu rapide des changements, ainsi qu’une traduction complète du journal des modifications. La dernière section décrit brièvement mon expérience de systemd sous Gentoo.

Sommaire Les changements importants

Cette version confirme la vision de systemd comme le chef d’orchestre du système d’exploitation, englobant tous les domaines, pour le meilleur ou pour le pire.

Le réseau

De nombreuses nouveautés concernant le réseau ont été ajoutées dans cette version. Un nouvel outil, networkctl, permet d’obtenir les informations de configurations du réseau. Il est actuellement purement passif, mais devrait dans le futur permettre la configuration du réseau. En particulier, un effort a été apporté aux protocoles NTP, DNS et DHCP. Les deux premiers peuvent désormais utiliser plus d’informations provenant des requêtes DHCP. Les règles de nommage des interfaces ont aussi été changées. Si le noyau indique qu’il fournit un nom prédictible pour une interface, alors udev utilisera ce nom. Il s’agit ici de fournir à l’utilisateur une interface unique pour paramétrer et surveiller le réseau.

journald

journald peut désormais utiliser l’algorithme LZ4 pour la compression, afin d’améliorer ses performances. Par défaut, il ne transmet désormais plus ses données au démon syslog. Ce changement a été décidé puisque rsyslog n’attend plus cette transmission, mais pioche directement dans le journal. Enfin, la transmission du journal vers des machines distantes est facilitée grâce au nouvel outil systemd-journal-upload.

L’installation d’un nouveau système

Il est intéressant de noter l’apparition de l’utilitaire systemd-firstboot qui permet de configurer les informations de base d’un nouveau système. Voit‐on ici l’émergence d’un outil commun pour l’installation de nos distributions ? Dans le même état d’esprit, systemd_sysusers et /etc/machine-info disposent de nouvelles options permettant une plus grande flexibilité dans la configuration.

La traduction du journal des modifications
  • Désormais timedated ne lit plus les noms des implémentations de NTP autres que celle de systemd depuis les fichiers /usr/lib/systemd/ntp-units.d/*.list.
    Les autres implémentations de NTP doivent ajouter la ligne Conflicts=systemd-timesyncd.service à leur fichier unité pour prendre la priorité et remplacer l’implémentation de NTP de systemd qui est utilisée par défaut.

  • systemd-sysusers gagne un nouveau type de ligne, appelé r, pour configurer les gammes d’identifiants à allouer pour les utilisateurs et groupes système (UID et GID) .
    Les lignes de type u acceptent désormais une nouvelle colonne pour spécifier le répertoire HOME de l’utilisateur qui sera créé.
    En outre, systemd-sysusers peut lire les informations depuis l’entrée standard plutôt que depuis un fichier.
    C’est utile lorsque l’utilitaire est invoqué par les scripts de pré‐installation d’un paquet RPM (les scripts preinst) qui doivent créer l’utilisateur avant de pouvoir créer un fichier, puisque ces fichiers peuvent appartenir à ce nouvel utilisateur.
    Une nouvelle macro RPM appelée %sysusers_create_inline a été introduite pour réaliser cette opération.
    Enfin, systemd-sysusers met à jour le fichier /etc/shadow, ainsi que les bases de données des utilisateurs et des groupes.
    Ceci devrait améliorer la compatibilité avec certains outils tels que grpck.

  • Un certain nombre d’interfaces logicielles (API) du processus 1 (PID 1) peuvent désormais, sous certaines conditions, consulter PolicyKit pour donner l’accès à des clients ne disposant pas des privilèges nécessaires.
    L’authentification interactive n’est pour l’instant pas encore prise en charge. Cependant, cette fonctionnalité devrait être ajoutée dans le futur.

  • /etc/machine-info dispose désormais de nouveaux champs pour configurer l’environnement de déploiement de la machine ainsi que son emplacement.
    L’utilitaire hostnamectl a été mis à jour avec de nouvelles commandes pour modifier ces champs.

  • systemd-timesyncd a été mis à jour pour obtenir les informations à propos des serveurs NTP depuis systemd-networkd, qui peut lui‐même les obtenir à partir des requêtes DHCP.

  • systemd-resolved inclut désormais un cache DNS client qui possède une implémentation complète de la résolution de nom LLMNR.
    Un nouveau module NSS nss-resolve a été ajouté. Il utilise l’implémentation nss-dns de glibc pour résoudre les noms d’hôtes via systemd-resolved.
    Les noms d’hôtes, les adresses ou un enregistrement de ressource DNS peuvent être résolus via les API D-BUS de systemd-resolved.
    Contrairement au solveur interne de glibc, systemd-resolved est compatible avec des systèmes disposant de plusieurs interfaces :
    un serveur DNS et un cache sont maintenus pour chaque interface.
    Les requêtes sont envoyées simultanément sur chaque interface où un serveur DNS est configuré afin de correctement prendre en compte les réseaux privés virtuels (VPN) et les réseaux locaux (LAN) qui pourraient produire différents noms de domaines.
    systemd-resolved peut obtenir les informations des serveurs DNS depuis systemd-networkd automatiquement, qui peut les avoir obtenues à partir des informations DHCP.
    Un utilitaire systemd-resolve-host a été ajouté pour obtenir la méthode de résolution DNS du démon resolved.
    systemd-resolved implémente IDNA et choisit automatiquement l’encodage IDNA ou UTF-8 en fonction du protocole de transport, le DNS classique ou LLMNR.
    Dans la prochaine version, il est prévu d’inclure une implémentation DNSSEC et mDNS / DNS-SD à systemd-resolved.

  • Un nouveau module NSS nss-mymachines a été ajouté. Il résout automatiquement les noms de tous les conteneurs locaux enregistrés vers leurs adresses IP respectives.

  • Un nouvel outil client pour systemd-networkd, networkctl, a été ajouté. Il est actuellement purement passif et permet d’obtenir les configurations du réseau de udev, rtnetlink et networkd, et de les formater pour les présenter à l’utilisateur.
    Dans le futur, nous espérons l’étendre pour qu’il soit l’outil de contrôle de networkd.

  • Les unités .socket obtiennent un nouveau paramètre : DeferAcceptSec= qui contrôle l’option TCP_DEFER_ACCEPT pour les sockets TCP [N. D. T. : cette option est appelée un sockopt].
    De la même façon, la prise en charge du contrôle des paramètres keep-alive de TCP a été ajoutée (KeepAliveTimeSec=, KeepAliveIntervalSec=, KeepAliveProbes=). Enfin, la désactivation optionnelle de l’algorithme de Nagle pour TCP a été implémentée (NoDelay=).

  • logind a gagné une nouvelle session de type web, pour des projets comme Cockpit qui enregistrent des clients Web comme session PAM.

  • Les unités minuteries avec au moins un paramètre OnCalendar= sont désormais démarrées seulement après que la cible timer-sync.target a été atteinte.
    De cette façon, la limite de temps ne peut être atteinte avant que l’horloge système n’ait été corrigée, par exemple par un client NTP local.
    Ceci est particulièrement utile pour des machines embarquées sans RTC, qui ne disposent que d’une horloge système imprécise.

  • L’option --network-veth de systemd-nspawn devrait désormais fournir une adresse MAC stable pour les deux côtés de l’interface.

  • Une nouvelle option --volatile= a été ajoutée à systemd-nspawn pour exécuter des instances de conteneur avec les dossiers /etc ou /var vides.

  • Le code du client kdbus a été mis à jour pour utiliser le nouveau sous‐système memfd du noyau Linux 3.17 à la place de l’ancienne interface spécifique à kdbus.

  • Le client et le serveur DHCP de systemd-networkd connaissent désormais l’option FORCERENEW.
    De nouvelles options ont aussi été incluses pour configurer l’identifiant vendeur du client et le mode diffusion (broadcast) pour DHCP.

  • systemd n’informera plus le noyau de la zone horaire, puisque cette information est nécessairement incorrecte et hasardeuse, car le noyau n’a, par exemple, aucune connaissance de l’heure d’été. Cela signifie que les horodatages (timestamps) FAT seront toujours considérés comme en temps universel (UTC), ce qu’Android fait déjà. Enfin, lorsque l’horloge matérielle indique l’heure locale (plutôt qu’UTC), systemd ne la resynchronisera pas, puisque cela peut induire Windows en erreur lors du prochain démarrage.

  • Une nouvelle option verify a été incluse dans systemd-analyze pour valider hors ligne les fichiers unités.

  • Plusieurs paramètres ont été inclus dans systemd-network pour configurer l’amalgame d’interfaces réseau.

  • Le client DHCP de systemd-network ne demande plus la diffusion (broadcast) par défaut, puisque cela impactait négativement certains réseaux. Pour les matériels où la diffusion est requise, elle peut être réactivée en utilisant l’option RequestBroadcast=yes.

  • systemd-networkd va désormais configurer les adresses IPv4LL (si elles sont activées), même si DHCP a été configuré avec succès.

  • udev va désormais respecter les noms donnés par le noyau aux interfaces réseau, lorsque celui‐ci indique qu’ils sont prédictibles. Ce comportement peut être modifié en changeant l’option NamePolicy= dans le fichier .link correspondant.

  • Une nouvelle bibliothèque systemd-terminal a été ajoutée. Elle implémente un moteur complet d’analyse et de rendu des flux de type « terminal texte » (TTY).
    Cette bibliothèque a été pensée pour pouvoir implémenter un sous‐système de terminaux virtuels (VT) complet s’exécutant en espace utilisateur, pour remplacer l’implémentation actuelle du noyau.

  • Un nouvel outil, systemd-journal-upload permet d’envoyer les données du journal à une machine distante exécutant systemd-journal-remote.

  • journald ne transmettra plus toutes les données locales à un autre démon syslog. Ce changement a été décidé, car rsyslog (qui semble être l’implémentation la plus répandue de syslog de nos jours) n’utilise plus cette possibilité. À la place, il extrait directement les données depuis le journal.
    Puisque transmettre ces données à un serveur syslog non existant demande plus de ressources que nous le supposions, cette option a été désactivée.
    Si vous exécutez un serveur syslog qui n’est pas une version récente de rsyslog, vous devez activer cette option (ForwardToSyslog= dans le fichier journald.conf).

  • journald prend désormais en charge l’algorithme de compression LZ4 pour les gros champs du journal.
    Cette compression devrait être plus performante que XZ, la précédente option par défaut.

  • machinectl montre désormais l’adresse IP des conteneurs locaux s’il les connaît, ainsi que le nom de l’interface du conteneur.

  • Un nouvel outil systemd-escape a été ajouté. Il permet de facilement protéger les chaînes de caractères qui seront utilisées pour construire les noms d’unités.

  • Les messages sd_notify() peuvent désormais inclure un nouveau champ, ERRNO=, qui est lu et enregistré par systemd.
    Il sera affiché dans la sortie fournie par la commande systemctl status pour le service concerné.

  • Un nouveau composant systemd-firstboot permet de demander à l’utilisateur les informations de base de systemd (zone horaire, nom de la machine, mot de passe root) lors d’un premier démarrage. Il peut aussi être utilisé pour fournir ces informations à des images Linux installées dans des répertoires [N. D. T. : par exemple un chroot ou un conteneur].

  • Les exemples préinstallés de sysctl.d auront désormais l’option net.ipv4.conf.default.promote_secondaries=1, ceci afin de ne pas supprimer les adresses IP secondaires lorsque les adresses primaires l’ont été.

Les personnes suivantes ont contribué à cette version :

Ansgar Burchardt, Bastien Nocera, Colin Walters, Dan Dedrick, Daniel Buch, Daniel Korostil, Daniel Mack, Dan Williams, Dave Reisner, David Herrmann, Denis Kenzior, Eelco Dolstra, Eric Cook, Hannes Reinecke, Harald Hoyer, Hong Shick Pak, Hui Wang, Jean‐André Santoni, Jóhann B. Guðmundsson, Jon Severinsson, Karel Zak, Kay Sievers, Kevin Wells, Lennart Poettering, Lukas Nykryn, Mantas Mikulėnas, Marc‐Antoine Perennou, Martin Pitt, Michael Biebl, Michael Marineau, Michael Olbrich, Michal Schmidt, Michal Sekletar, Miguel Angel Ajo, Mike Gilbert, Olivier Brunel, Robert Schiele, Ronny Chevalier, Simon McVittie, Sjoerd Simons, Stef Walter, Steven Noonan, Susant Sahani, Tanu Kaskinen, Thomas Blume, Thomas Hindoe Paaboel Andersen, Timofey Titovets, Tobias Geerinckx‐Rice, Tomasz Torcz, Tom Gundersen, Umut Tezduyar Lindskog et Zbigniew Jędrzejewski‐Szmek.

systemd et Gentoo

La distribution Gentoo Linux fournit par défaut son propre système d’init : OpenRC. Une des forces d’OpenRC est son intégration avec le principe fondamental de Gentoo : la personnalisation. Jusqu’à cet été, j’ai vécu très heureux avec ce système. Néanmoins, Gentoo pousse la personnalisation du système jusqu’à proposer l’utilisation de systemd comme système d’init pour les utilisateurs qui le veulent (ou qui veulent utiliser toutes les possibilités de GNOME 3). Pour le plaisir de tester, j’ai basculé mon ordinateur portable sous systemd.

L’installation se fait facilement en suivant les étapes ci‐dessous :

  1. recompiler le noyau pour activer l’option OpenRC ou systemd fourni par l’équipe Gentoo, et reconstruire l’initramfs pour appeler l’exécutable systemd ;
  2. activer le profil systemd (ou activer manuellement les bons useflags — principalement USE=systemd -consolekit) ;
  3. recompiler son système (la partie la plus longue du processus) ;
  4. configurer (à la main ou en utilisant les utilitaires de systemd) ;
  5. profiter !

Une description détaillée de la procédure est disponible sur le wiki du projet Gentoo. Vous pourrez aussi trouver une rapide description des différents systèmes d’init.

Je n’ai malheureusement pas grand chose à dire de plus, car tout a fonctionné directement sans problème. Ce qui témoigne à la fois de la qualité de systemd, mais aussi et surtout de la qualité de l’intégration faite par l’équipe de développement de Gentoo. Il faut toutefois noter que systemd et OpenRC sont très différents dans leur configuration. Cependant, puisque systemd est très répandu, la documentation est abondante. L’apparition d’utilitaires comme systemd-firstboot devrait faciliter cette étape de configuration. Ce nouveau système est plus rapide, comme attendu. Cependant, je l’ai installé sur un nouveau SSD, la comparaison est donc légèrement biaisée.

Télécharger ce contenu au format Epub

Lire les commentaires

Meteor 1.0

Vendredi 31 Octobre

Meteor est une plate-forme open-source facilitant le développement d'applications modernes Internet et mobiles en JavaScript. Il offre des fonctions de mise à jour automatique des interfaces permettant le travail collaboratif temps réel et des interfaces intuitives assurant la même expérience utilisateur qu'une application de bureau. Ces applications peuvent s’exécuter dans un navigateur web, ainsi que sur tous les appareils mobiles (applications natives avec Cordova/PhoneGap).

Meteor 1.0 est sorti hier soir, annoncé par Matt DeBergalis du MDG (Meteor Developpement Group). Cette version assure la stabilité de l'API, qui jusqu'alors évoluait fortement entre chaque version.

Voyez sa description en seconde partie de l'article…

Meteor est composé d'une poignée de greffons noyau (core packages) développés par le MDG et de plus de 2400 greffons développés par la communauté, dont des membres de Meteor France. Afin de comprendre comment est constituée l'architecture logicielle de Meteor, nous vous invitons à consulter l'explication sur le site de Meteor.

Nouveau avec Meteor ? Les trois pistes suivantes devraient vous aider !

Tout d'abord, un nouveau tutoriel décrivant le développement pas à pas d'un outil collaboratif et introduisant chaque élément composant Meteor ;

Ensuite, de nouveaux exemples d'applications ont aussi fait leur apparition, afin que vous puissiez consulter leur architecture. La première est une application de "À faire" (TODO) avec des tâches privées et partagées. La deuxième est une application de marché local, avec partage de photos utilisées par des commerces de proximité afin de créer une véritable communauté autour de leur activité. Agrémenté d'une authentification Twitter et de la prise en charge des appareils photo sur mobile, cette application totalise moins de 1000 lignes de pur JavaScript.

Enfin, pour célébrer la sortie de la 1.0, les responsables de "Discover Meteor" ont lancé une édition gratuite de leur excellent livre en ligne. Vous avez 8 jours pour profiter de cette offre.

Meteor reçoit en France un soutien important de Morea et d'Amazon AWS qui sont les sponsors principaux des événements organisés par Meteor France via leur groupe Meetup Meteor Paris.

Télécharger ce contenu au format Epub

Lire les commentaires

Sortie de Tryton 3.4

Vendredi 31 Octobre

Comme à l'accoutumée, le mois d'octobre voit la sortie d'une nouvelle version de Tryton, la plate-forme de développement d'applications pour entreprise (progiciel de gestion intégré ou PGI mais aussi ERP).

Sur cette version, un gros travail a porté sur la partie comptabilité, mais aussi sur une multitude de petites améliorations pour simplifier la vie des développeurs de modules.

Et, bien évidement, la migration depuis les précédentes versions est assurée.

Vous pouvez venir découvrir toutes ces nouveautés à la conférence annuelle de la communauté qui se déroule cette année à Leipzig.

Détails des nouveautés Interface utilisateur

Les widgets des champs relations ont été retravaillés pour tirer avantage de l'auto-complétion en les simplifiant. Les boutons ont été remplacés par une icône dans le champs qui permet soit de rechercher, soit d'ouvrir le contenu.

Une prévalidation côté client a été ajoutée. Elle permet un meilleur retour à l'utilisateur par rapport à un message d'erreur. En effet, le client est capable de mettre en surbrillance les champs non valides.

Un complètement automatique entre le code postal et la ville est disponible sur les adresses. Les données de GeoNames peuvent être chargées dans la base de données via un script.

La fenêtre d'export d'enregistrement a été retravaillée afin de fournir une meilleur expérience à l'utilisateur. Elle s'ouvre avec les champs de la vue courante pré-sélectionés. Il est possible de modifier et de sauvegarder directement un export prédéfini. L'ordre des champs peut aussi être changé par glisser-déposer.

Outils pour développeur

Le patron commun dans Tryton de rechercher un enregistrement dans une liste suivant des critères sur des valeurs (de manière modulaire) a été généralisé dans un Mixin.

Un autre Mixin a ausi été ajouté, permettant de définir un nouveau modèle (objet) comme étant l'UNION (l'opérateur SQL) de plusieurs modèles.

Un descripteur a été ajouté aux champs de sélection, il permet d’accéder aux labels de ceux-ci au lieu de leurs valeurs internes.

Le fichier de configuration est maintenant extensible à volonté et donc il peut être utiliser pour le paramètrage des modules. C'est déjà le cas du module ldap_authentication qui va y chercher les paramètres de configuration du serveur LDAP.

Proteus (la bibliothèque pour accéder à Tryton comme le client) est maintenant capable d’exécuter les rapports. Et une méthode duplicate voit le jour qui imite la fonctionnalité de copie d'enregistrement du client.

Sécurité

Les droits d'accès ont été revus pour n'être appliqués que sur les appels RPC. Ceci simplifie grandement le développement, vu que les droits d'accès ne sont contrôlés qu'aux bordures du système et donc le développeur n'a plus à devoir basculer en utilisateur root pour effectuer certaines opérations.

Comptabilité

Un nouvel assistant de lettrage comptable fait son entrée. Il passe en revue tous les comptes et tiers qui contiennent des lignes à lettrer et fait une proposition de combinaison. L'utilisateur peut l'accepter tel quelle ou bien la modifier, ainsi que passer une partie en pertes et profits. Ce mode de fonctionnement accélère grandement cette tâche comptable.

Un autre assistant permet d'annuler rapidement une écriture comptable en passant l'écriture inverse. Une option permet de directement lettrer les entrées possibles.

Afin de rendre plus homogène l'utilisation du champ tiers sur les écritures comptables, ce champ est rendu obligatoire ou interdit en fonction du paramétrage du compte sur lequel l'écriture est passée. Ceci permet de configurer le système pour soit fonctionner avec des comptes groupés pour les tiers ou bien avec un compte par tiers. Tous les modules ont été vérifiés pour gérer correctement les deux cas de figures automatiquement.

Il est maintenant possible de choisir entre un arrondi des taxes « par ligne » ou « par document ». La méthode par défaut reste « par document ».

Les lignes des relevés comptables peuvent être ordonnées et numérotées afin de correspondre au mieux à la version papier. De nouvelles méthodes de validation des extraits sont disponibles : « balance », « montant » et « nombre de ligne ».

Il est maintenant possible de changer par année fiscale la méthode de valorisation perpétuelle du stock (« Continentale » ou « Anglo-Saxonne »).

Les paiements

Les paiements à l'état « réussi » peuvent maintenant être changés en « échoué ». C'est moins contraignant en cas d'erreur d'encodage.

La prise en charge du schéma « Business to Business » de la norme SEPA pour les prélèvements automatiques a été ajoutée. Les messages de notification de débit/crédit (CAMT.054) sont gérés. Le numéro d'identification et le formulaire de mandat sont configurés par défaut.

Un nouveau module account_payment_clearing permet de générer automatiquement un mouvement pour le paiement dans un compte d'attente de la banque. Ce mouvement sera par la suite compensé, lors de l'encodage de l'extrait de compte.

Télécharger ce contenu au format Epub

Lire les commentaires

Préparation de documents LaTeX avec BSD Owl

Vendredi 31 Octobre

À l'occasion de la sortie de BSD Owl 2.2.1 — le système de compilation portable pour BSD Make — je vous propose d'apprendre à utiliser BSD Owl pour préparer et publier vos documents LaTeX.

Ce texte est une traduction de la page du Wiki “Producing LaTeX documents”.

Sommaire Préparer des documents avec LaTeX

Vous apprendrez dans ce texte comment utiliser les scripts BSD owl (bsdowl) pour :

  • préparer des documents simples et les publier dans l'arborescence des fichiers;
  • préparer la bibliographie de vos documents LaTeX avec BIBTeX;
  • préparer des figures pour vos documents avec METAPOST;
  • gérer des documents dont certains éléments doivent être automatiquement régénérés;
  • gérer des documents dispersés dans différents répertoires.
  • gérer des collections comportant un grand nombre de documents.
Avertissement: travailler avec TeX ou LaTeX

Il y a de nombreux formats TeX, plain TeX et LaTeX en sont deux exemples. Le format LaTeX jouit d'une grande popularité et nous avons choisi d'utiliser le module latex.doc.mk dans les exemples. Cependant, ce qui suit s'applique aussi au module tex.doc.mk. Certains paragraphes dans la suite identifient les mécanismes spécifiques à latex.doc.mk.

Avertissement: BSD Make

Ne vous trompez pas de version de make : la plupart des distributions Linux installent GNU Make comme programme make principal, la version BSD de make est souvent appelée bmake et installable via un paquet du même nom. Sous les BSD, on trouve naturellement BSD Make comme commande make. Sous Mac OS X, c'est le programme bsdmake.

Utilisation simple

La préparation d'un document simple avec LaTeX est en elle-même particulièrement simple, l'utilisation de bsdowl pourrait donc sembler une complication inutile. Cependant, même dans ce cas, l'utilisation de bsdowl rend d'appréciables services, comme l'installation et l'horodatage des fichiers produits.

Néanmoins, la partie vraiment intéressante se situe dans la partie avancée.

La première fois

Supposons que le fichier script.tex contient notre texte et mettons-le dans un répertoire dédié. Créons un fichier Makefile (la majuscule compte) qui contient :

DOC = script.tex .include "latex.doc.mk"

de sorte que le répertoire dédié contient maintenant script.tex et ce Makefile. Rendons-nous avec un shell dans ce répertoire et tapons make:

% make make build ===> Multipass job for script.dvi (aux) latex script.tex This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) entering extended mode (./script.tex LaTeX2e <2003/12/01> ...

S'il n'y avait pas d'erreur dans script.tex, on se retrouve avec les fichiers "compilés" suivants dans le répertoire courant :

% ls Makefile script.log script.aux script.tex script.dvi script.toc

Lorsque les produits de compilation ne sont plus nécessaires, vous pouvez nettoyer le dossier de travail avec le mantra make clean:

% make clean rm -f script.dvi script.log script.aux script.toc

Le nettoyage du dossier de travail est une étape optionnelle qui évite de voir son dossier personnel rempli de données inutiles, qui peuvent rapidement être recréées. Les fichiers DVI sont habituellement très petits, de l'ordre de quelques centaines de kilobits, mais les fichiers PostScript ou PDF sont habituellement bien plus gros.

Installation ou publication

Avant de nettoyer votre dossier de travail avec le mantra make clean, vous pouvez vouloir copier ce document à un emplacement approprié du système de fichiers. Cette étape s'appelle installation du document, car elle est analogue à l'installation d'un programme nouvellement compilé. Vous installez le document grâce à la commande make install mais il faut auparavant dire à make quel emplacement du système de fichiers est approprié. Il faut pour cela assigner à la variable DOCUMENTDIR le chemin du dossier où vous voulez que vos fichiers soient copiés, comme l'illustre le Makefile suivant :

DOCUMENTDIR = ${HOME}/doc/report DOC = script.tex .include "latex.doc.mk"

Vous pouvez alors passer à la commande make install:

% make install install -d /home/michi/doc/report install -o michi -g michi -m 440 script.dvi /home/michi/doc/report

En comparaison avec la copie manuelle du document produit, vous vous épargnez la saisie récurrente du dossier de destination après chaque mise à jour du document. Mais confier cette tâche élémentaire au Makefile a d'autres avantages plus importants :

  • Cela simplifie l'organisation de votre bibliothèque de sources pour vos documents.
  • Cette stratégie s'adapte à une collection importante de documents, cf. Travailler avec une collection de documents plus bas.
  • En mode brouillon, un suffixe horodatant le fichier est automatiquement ajouté, comme expliqué plus bas.
Choix du format de sortie

La chaîne de production TeX est capable de produire des documents électroniques dans plusieurs formats, comme DVI, PostScript (PS) ou PDF. La variable TEXDEVICE commande le choix du format de sortie des documents préparés avec latex.doc.mk. Cette valeur est généralement dvi de sorte qu'un fichier DVI sera préparé à partir du document source. D'autres valeurs possibles sont ps ou pdf. Si vous avez configuré une imprimante PostScript avec texconfig(1), disons TEXPRINTER, vous pouvez utiliser ps.TEXPRINTER comme valeur de TEXDEVICE ce qui indique à dvips d'utiliser les réglages pour TEXPRINTER dans la traduction de DVI vers PostScript. Il est enfin possible d'assigner une liste de formats de sortie à TEXDEVICE.

Brouillons et traitements multiples

Certains formats — dont LaTeX — et certaines macros exigent de votre manuscrit qu'il soit traité plusieurs fois par TeX ou LaTeX avant que vous n'obteniez la version finale. Le module latex.tex.mk impose un traitement à multiples passes de votre manuscrit, car LaTeX s'appuie sur ce mécanisme pour produire les références croisées associées aux commandes label ou ref de votre manuscrit. Le module doc.tex.mk ne procède pas à un traitement multiple.

Dans les premiers jets d'un document, les modifications sont probablement fréquentes ; il est donc souhaitable d'éviter de longs traitements multiples. bsdowl a un mode brouillon, activé en assignant la valeur yes à la variable DRAFT de make. Ceci peut être fait en ajoutant la commande suivante dans le Makefile:

DRAFT?= yes DOC = script.tex .include "latex.doc.mk"

La commande DRAFT?= est une forme faible de l'assignement qui permet d'invoquer make DRAFT=no pour rétablir le traitement à plusieurs passes pour une unique invocation de make, sans modifier le Makefile.

Lorsque les derniers ajustements ont été faits au manuscrit, vous pouvez supprimer la commande manipulant DRAFT et votre texte est prêt pour une dernière exécution de make produisant la version finale de votre document. Si vous en êtes satisfait, vous pouvez l'installer.

Pendant la mise au point d'un document, il est utile de garder des copies des documents produits à certaines étapes de votre travail. Imaginez envoyer un exemplaire préliminaire de votre travail à un ami qui le lira attentivement et vous fera part de ses commentaires. Pendant ce temps, vous continuez de travailler sur votre texte, si bien que lorsque vous recevrez ses commentaires, votre document aura évolué. Pour pouvoir comparer les commentaires de votre ami à la version de votre document que vous lui avez envoyé, la meilleure manière de résoudre ce problème est probablement d'utiliser un outil de gestion des versions — un logiciel gardant note des différentes révisions d'un fichier. Si vous n'utilisez pas un tel système et désirez en essayer un, vous pourriez être intéressé par GIT, tout particulièrement si vous utilisez les courriels pour organiser votre collaboration.

Lorsque la variable DRAFT est positionnée à yes et la variable TEXDRAFTSTAMP n'est pas initialisée, elle reçoit la valeur -${TEXDRAFTTIMESTAMP} où le texte de remplacement de TEXDRAFTTIMESTAMP est la date à laquelle la commande make est appelée. Lorsque la variable TEXDRAFTSTAMP est initialisée et n'est pas vide, son texte de remplacement est ajouté à la fin de tous les documents installés par latex.doc.mk ou tex.doc.mk. Si vous ne souhaitez pas que le nom soit modifié, tout en utilisant le mode brouillon, il suffit d'affecter un texte vide à TEXDRAFTSTAMP.

Un document dans plusieurs fichiers

Si vous travaillez sur un document complexe, vous aurez certainement découpé votre manuscrit en plusieurs fichiers ; typiquement, un fichier par chapitre ou par section plus un fichier principal contenant le préambule et de multiples commandes input demandant à LaTeX de lire tous les fichiers représentant le véritable contenu du document.

Supposons donc que votre document est découpé entre un fichier principal galley.tex et deux fichiers part1.tex et part2.tex. Votre galley.tex ressemble probablement à ceci :

\documentclass{article} \begin{document} \input{part1} \input{part2} \end{document}

Le Makefile correspondant est alors :

DOC = galley.tex SRCS = part1.tex SRCS+= part2.tex .include "latex.doc.mk" Fonctions avancées Figures avec METAPOST

Les modules latex.doc.mk et tex.doc.mk prennent en charge
METAPOST agréablement. C'est un point particulièrement important à relever, car METAPOST est souvent l'outil le mieux adapté pour tracer des figures destinées à l'inclusion dans un document TeX. Cependant, il n'est que rarement pris en charge de façon adéquate par les interfaces graphiques LaTeX.

Ces modules font l'hypothèse que votre code METAPOST contient les lignes :

prologues := 3; outputtemplate := "%j-%c.mps";

La première déclaration paramètre l'inclusion des fontes dans le fichier résultat tandis que la seconde change le format des noms utilisés par les produits.

Supposons donc que vous ayez préparé les illustrations pour votre article avec METAPOST et réparti ces illustrations dans deux fichiers illustr1.mp et illustr2,mp. Pour indiquer à latex.doc.mk qu'il doit les utiliser pour produire leurs figures, définissez la variable FIGS dans votre Makefile:

DOC = galley.tex SRCS = part1.tex SRCS+= part2.tex FIGS = illustr1.mp FIGS+= illustr2.mp .include "latex.doc.mk"

Saisissez donc make à l'invite de commande. Le module latex.doc.mk analysera vos fichiers pour savoir quelles illustrations sont définies dans vos fichiers et produira les fichiers nécessaires à votre TEXDEVICE. Par exemple, si votre TEXDEVICE est dvi et que illustr1.mp contient la description de deux figures définies par beginfig(1) et beginfig(2), alors vous obtiendrez quatre fichiers :

% ls *.mps illustr1-1.mps illustr1-2.mps illustr1-1.eps illustr1-2.eps

Les deux premiers fichiers sont la sortie de METAPOST, des données intermédiaires dans un format PostScript spécifique. Les deux derniers sont en Encapsulated PostScript et adaptés à l'inclusion dans votre document.

En utilisant le paquet graphicx, l'inclusion d'image est aussi simple que possible :

\includegraphics{illustr1-1}%

Découvrez METAPOST. Il semblerait que de nombreuses personnes ne connaissent pas METAPOST. Si c'est votre cas mais que vous êtes intéressé par la découverte de cet outil merveilleux, la première bonne nouvelle est qu'il fait partie de la plupart — sinon de toutes — les installations de TeX, il est donc probablement déjà installé sur votre système.

La seconde bonne nouvelle est que de nombreuses informations peuvent être trouvées à son sujet sur le Web. Par exemple le TeX users group a une page dédiée à cet outil. La liste qui s'y trouve est particulièrement longue, j'ajouterai donc que j'ai lu et apprécié l'introduction de André Heck, elle est peut-être un bon point de départ pour vous !

Enfin n'oubliez pas d'essayer mon projet Metapost blueprint pour produire de splendides graphiques pour accompagner vos projets.

Bibliographie

bsdowl peut vous aider à préparer des bibliographies avec BibTeX. Tout d'abord vous devez vous assurer que TeX trouvera les base de données bibliographiques que vous avez énumérées dans vos commandes bibliography. Il est habituel de regrouper ses bases de données bibliographiques dans un dossier, par exemple ${HOME}/share/bib. Pour permettre à bibtex de trouver ses fichiers, il suffit d'ajouter le chemin ${HOME}/share/bib au contenu de la variable BIBINPUTS. Si votre base de données bibliographiques est dispersée dans plusieurs dossiers, vous n'avez qu'à mentionner chacun d'eux dans BIBINPUTS :

DOC = galley.tex SRCS = part1.tex SRCS+= part2.tex BIBINPUTS = ${HOME}/share/bib BIBINPUTS+= ../morebib .include "latex.doc.mk"

Notez que le mantra make clean laissera intacts les fichiers BBL produits par bibtex. Les éditeurs demandent parfois de leur envoyer ces fichiers, ainsi, la commande make clean ou make distclean placera votre dossier de travail dans un état où vous pourrez facilement le redistribuer. Pour vous débarrasser des fichiers BBL, vous devez vous en remettre au puissant mantra make realclean.

Plusieurs documents dans le même dossier

Bien qu'il soit souvent une bonne idée de réserver un dossier à chaque document, vous pouvez avoir des raisons de vouloir travailler avec plusieurs documents dans le même dossier. Vous avez vos raisons et elles sont probablement excellentes, et bsdowl fera donc de son mieux pour vous aider.

Supposons que vous ayez deux documents dont les sources se trouvent dans le même dossier, disons un article et une version abrégée de cet article. Ces deux documents ont en commun un fichier macro.tex, mais sont à part cela relativement indépendants du point de vue de LaTeX. Le texte de l'article est divisé dans deux fichiers section1.tex et section2.tex. Le résumé a un seul fichier summary.tex. Le Makefile correspondant ressemble à ceci :

DOC = article.tex DOC+= summary.tex SRCS = macros.tex SRCS.article.tex = section1.tex SRCS.article.tex+= section2.tex .include "latex.doc.mk" Génération automatique d'une portion de document

Supposons que vous travailliez sur un document contenant une table dont le contenu changera vraisemblablement plusieurs fois et devra donc être mis à jour. Une telle table pourrait être un budget : lorsque notre situation évolue, ainsi en va-t-il de notre budget. Il peut être assez délicat de saisir une table en LaTeX, la mettre à jour est encore plus vachard. Dans cette situation, on peut écrire et utiliser à profit un petit programme lisant les données brutes de notre budget et écrivant pour nous le code LaTeX de la table correspondante, contenant cette information brute et les données que nous pouvons en dériver. Écrire un tel programme est très facile, car on a seulement besoin de savoir travailler avec des fichiers texte.

Ainsi, vous avez rassemblé vos données brutes pour votre table dans le fichier table.raw et écrit un petit programme gentable qui écrit pour vous la table LaTeX sur sa sortie standard. Dans votre manuscrit, vous utilisez le nom table pour inclure le contenu de la table. Voici votre Makefile:

DOC = galley.tex table.tex: gentable table.raw ./gentable < table.raw > table.tex REALCLEANFILES+= table.tex .include "latex.doc.mk"

Cet exemple suppose que le programme gentable est un filtre, de sorte que l'entrée et la sortie sont effectuées par des redirections. D'autres programmes peuvent utiliser une convention différente pour définir la sortie et l'entrée.

Si vous envoyez vos fichiers à quelqu'un, cette personne ne voudra probablement pas exécuter votre programme gentable . Il semble donc préférable d'ajouter le nom du produit table.tex à REALCLEANFILES plutôt qu'à CLEANFILES : vous pouvez ainsi nettoyer votre dossier de travail avec make clean et faire une archive du contenu que vous enverrez à un tiers, sans avoir besoin de traiter le fichier table.tex avec une attention particulière.

Bien sûr, vous pouvez générer un code source pour METAPOST, typographier un fragment de code ou bien encore autre chose, au lieu de générer une table !

Code source réparti dans plusieurs répertoires

Certaines méthodes de travail requièrent que vos fichiers source ne soient pas situés dans un répertoire unique mais disséminés dans le système de fichiers.

Une raison pour travailler ainsi pourrait être que votre organisation utilise pour son courrier une classe de document personnalisée incluant quelques images. Vous ne souhaitez pas copier ces images dans chacun des dossiers utilisant cette classe de document, ni créer des liens symboliques vers ces images : vous souhaitez tout bonnement pouvoir ignorer leur existence ! Une solution à ce problème passe par la variable TEXINPUTS dont le contenu est une liste de dossiers que TeX doit examiner lorsqu'il recherche un fichier.

Une autre raison motivant la dissémination de fichiers sources dans plusieurs dossiers est la préparation d'un grand document, comme un livre. Si les fichiers de chaque chapitre sont contenus dans un dossier dédié, il est facile de traiter un chapitre isolé avec LaTeX pendant la phase de mise au point du manuscrit. TeX doit donc trouver tous les fichiers nécessaires lorsqu'il traite le fichier principal produisant le livre, ce qui est accompli en positionnant TEXINPUTS à la valeur adéquate, comme expliqué ci-dessous.

Vous pouvez définir la variable TEXINPUTS dans votre environnement, dans votre Makefile ou bien même écrire une version personalisée de latex.doc.mk définissant cette variable.

Supposons que l'image représentant visuellement votre organisation soit dans ${HOME}/share/texmf/tex/organisation/visual.eps, afin que TeX examine le dossier contenant cette image, vous écrivez une affectation à TEXINPUTS dans votre Makefile, comme ceci :

DOC = galley.tex TEXINPUTS = ${HOME}/share/texmf/organisation .include "latex.doc.mk"

Exécuter make dans le dossier contenant le Makefile fera apparaître ceci dans votre terminal :

% make make build ===> Multipass job for galley.dvi (aux) env TEXINPUTS=".:${HOME}/share/texmf/organization:" latex galley.tex This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) ...

Examinons la liaison associée à TEXINPUTS par la commande env. Elle se distingue notamment de la spécification du Makefile par la présence d'un élément . au début et d'un élément vide à la fin. Ceux-ci indiquent à TeX de rechercher aussi les fichiers dans le dossier courant et dans les dossiers de l'installation TeX.

Si dans un cas particulier vous souhaitez avoir un contrôle total sur TEXINPUTS, il vous suffit de positionner USE_STRICT_TEXINPUTS à yes dans votre Makefile. S'il trouve ce positionnement, bsdowl n'ajoutera pas le point et l'élément vide à TEXINPUTS.

La prise en charge de METAPOST tient compte des valeurs de TEXINPUTS ET USE_STRICT_TEXINPUTS. Une variable analogue nommée MPINPUTS et sa compagne USE_STRICT_MPINPUTS permettent de configurer le chemin de recherche des fichiers par METAPOST.

Travailler avec des collections contenant un grand nombre de documents

Nous montrons comment utiliser le module bps.subdir.mk pour organiser une collection de documents. Pour les besoins de cet exemple, nous supposerons que vous préparez un journal électronique et souhaitez distribuer chaque article du journal comme un document individuel. Vous utilisez l'organisation suivante :

  1. Vous avez préparé un répertoire contenant chaque numéro du journal, disons ${HOME}/journal.
  2. Chaque numéro du journal est matérialisé par un sous-répertoire du dossier précédent.
  3. Chaque article du journal est représenté par un sous-répertoire du dossier correspondant au numéro auquel il appartient.

Supposons que vous avez déjà préparé plusieurs articles, comme le suggère la commande suivante :

% find ./journal -type f ./journal/issue-2013-1/01-galdal/Makefile ./journal/issue-2013-1/01-galdal/article.tex ./journal/issue-2013-1/02-arathlor/Makefile ./journal/issue-2013-1/02-arathlor/article.tex ./journal/issue-2013-2/01-mirmilothor/Makefile ./journal/issue-2013-2/01-mirmilothor/article.tex ./journal/issue-2013-2/02-eoron/Makefile ./journal/issue-2013-2/02-eoron/article.tex ./journal/issue-2013-2/03-echalad/Makefile ./journal/issue-2013-2/03-echalad/article.tex

Les noms comme galdal, arathlor, etc. sont les noms des auteurs fictifs des articles non moins fictifs de votre journal. Chaque contribution est associée à un répertoire contenant le texte de l'article proprement dit article.tex et un Makefile semblable à ceux décrits plus haut dans cette dépêche et qui est utilisé pour préparer l'article correspondant.

Chacun de ces Makefile peut être aussi simple que:

DOC= article.tex .include "latex.doc.mk"

Pour coordonner la préparation de tous nos articles, il nous suffit d'écrire quelques Makefile supplémentaires :

./journal/Makefile ./journal/issue-2013-1/Makefile ./journal/issue-2013-2/Makefile ./journal/issue-2013-3/Makefile

Chaque Makefile contient essentiellement la liste des sous-répertoires que make doit explorer pour atteindre les cibles build, install ou clean. Ainsi le fichier ./journal/Makefile doit contenir :

SUBDIR= issue-2013-1 SUBDIR+= issue-2013-2 SUBDIR+= issue-2013-3 .include "bps.subdir.mk"

Quant à lui, ./journal/issue-2013-1/Makefile doit contenir :

SUBDIR= 01-galdal SUBDIR+= 02-arathlor .include "bps.subdir.mk"

Les fichiers restants ./journal/issue-2013-2/Makefile et ./journal/issue-2013-3/Makefile doivent être préparés de façon similaire. Avec ces ajustements, les cibles all, build, clean, distclean, realclean et install sont déléguées aux Makefile trouvés dans les dossiers énumérés par SUBDIR.

La variable _SUBDIR_PREFIX peut être utilisée pour personnaliser le dossier d'installation pour chaque article. Changeons le Makefile associé à chaque article en :

DOC= article.tex DOCDIR= ${HOME}/publish/journal${_SUBDIR_PREFIX} .include "latex.doc.mk"

Avec ce réglage, le document ./journal/issue-2013-1/01-galdal/article.dvi sera installé dans ${HOME}/publish/journal/issue-2013-1/01-galdal/article.dvi et ainsi de suite. Il est possible d'ajuster ceci pour utiliser un police de nommage complètement arbitraire pour l'installation des produits.

Contribuer

Le but de bsdowl est de fournir un système de déploiement de logiciel portable pour les systèmes UNIX modernes. Il se distingue d'autres approches par l'utilisation de simples fichiers Makefile et d'un programme standard : BSD Make. L'utilisateur de bsdowl écrit donc des fichiers Makefile, il n'est pas utile d'apprendre un énième langage de script pour écrire une spécification de compilation.

Pour la version 3.0 en préparation, je projette de réorganiser grandement le logiciel. Les projets sont :

  • Mise en avant des notions de module et de produit, pour se rapprocher du schéma d'organisation des projets dans les grands IDE classiques.
  • Concilier le point précédent avec une approche non bureaucratique pour les petits projets.
  • Utiliser de façon systématique un mode de développement axé sur les tests.

Si vous êtes intéressé(e) par bsdowl vous pouvez :

  • témoigner de votre intérêt en lui ajoutant une petite étoile dans GitHub ;
  • rapporter vos succès et vos infortunes, je suis notamment très intéressé par la préparation d'une liste de compatibilité.
  • contribuer des programmes de type hello-world ou de plus complexes pour m'aider à écrire des tests pour les langages que vous aimeriez voir pris en charge.
Télécharger ce contenu au format Epub

Lire les commentaires

Pages