Syndiquer le contenu
Mis à jour : il y a 2 heures 26 min

Meilleures contributions LinuxFr.org : les primées de juin 2016

24 juillet, 2016 - 23:27

Nous continuons sur notre lancée de récompenser ceux qui chaque mois contribuent au site LinuxFr.org (dépêches, commentaires, logo, journaux, patchs, etc.). Vous n'êtes pas sans risquer de gagner un abonnement à GNU/Linux Magazine France ou encore un livre des éditions Eyrolles ou ENI. Voici les gagnants du mois de juin 2016 :

Abonnement d'un an à Linux Magazine France

Livres des éditions Eyrolles et ENI

Les livres qu'ils ont sélectionnés sont en seconde partie de la dépêche. N'oubliez pas de contribuer, LinuxFr.org vit pour vous et par vous !

Certains gagnants n'ont pas pu être joints ou n'ont pas répondu. Les lots ont été ré-attribués automatiquement. N'oubliez pas de mettre une adresse de courriel valable dans votre compte ou lors de la proposition d'une dépêche. En effet, c'est notre seul moyen de vous contacter, que ce soit pour les lots ou des questions sur votre dépêche lors de sa modération. Tous nos remerciements aux contributeurs du site ainsi qu'à GNU/Linux Magazine France, aux éditions Eyrolles et ENI.

Les livres sélectionnés par les gagnants :

                        Télécharger ce contenu au format Epub

Lire les commentaires

Icestudio 0.2, du schéma au verilog

24 juillet, 2016 - 23:26

IceStudio est un logiciel graphique permettant de concevoir un design FPGA à la manière d’un schéma électronique. Le logiciel est encore largement expérimental et centré sur les FPGA ice40 de chez lattice. Écrit en JavaScript autour de Nodejs, le logiciel permet de dessiner son projet au moyen de blocs reliés entre eux par des signaux.

IceStudio est sous licence GPLv2.

NdM : à noter, ce projet bénéficie d'un soutien du fabricant espagnol BQ (connu également pour fournir des matériels avec Ubuntu pré-installée)

IceStudio se veut une extension graphique au projet IceStorm (chaine de synthèse/place&route/bitstream opensource), qui a été développé par ingénierie inversée. Voir la présentation du projet lors du 32C3. Le projet IceStorm est composé de trois logiciels distincts : IceStorm, Arachne-PnR pour construire le routage des signaux, et Yosis permettant de synthétiser/compiler le verilog.

Les blocs peuvent être pris dans une bibliothèque fournie avec le logiciel, mais il est également possible de créer des blocs «vierges» dans lesquels on écrira le code verilog correspondant au comportement souhaité.

Le format de sauvegarde du projet est en JSON, un outils de conversion permet ensuite de le transformer en code Verilog pour la synthèse.

Le projet est encore jeune mais très prometteur. Espérons que nous verrons rapidement l’intégration de nouvelles plateformes/FPGA.

Télécharger ce contenu au format Epub

Lire les commentaires

jXBattle, Xbattle en Java, nouvelle mouture !

22 juillet, 2016 - 10:09

Après 4 ans de sommeil, jXBattle profite de la torpeur estivale pour refaire surface.

Il s'agit de la réécriture de XBattle, un jeu de stratégie temps réel multi joueur où des liquides de couleur s'affrontent sur une grille. Le jeu n'a pas la climatisation, mais il rafraîchit par ses quelques nouveautés :

  • un seul exécutable pour le client et le serveur ;
  • une interface remaniée ;
  • des canons et des parachutes ;
  • des raccourcis claviers en plus ;
  • un code en grande partie réécrit.

Au départ écrit pour Unix, cette version est en Java et possède une interface graphique (de mignons petits fichiers de conf étaient là pour retarder votre plaisir de jouer…). J'ai réécrit ce jeu par pur plaisir (et la frustration de voir ramer l'original, pourtant en C, quand on commence à jouer à beaucoup).

Ce qui ne change pas non plus, c'est la licence : GPLv3.

Merci pour les retours (cf. adresse de contact sur le site) !

Télécharger ce contenu au format Epub

Lire les commentaires

Authentifiez-vous sans mot de passe grâce à XMPP !

22 juillet, 2016 - 09:43

L’authentification HTTP via XMPP est une extension du protocole XMPP (XEP).
Elle permet de s’authentifier sur un site Internet sans avoir besoin de mot de passe : le site en question envoie une demande de confirmation à l’utilisateur du compte XMPP qui autorise ou non l’accès.

Des implémentations sont récemment apparues ou en cours, plus de détails en deuxième partie de dépêche.

Introduction

XMPP permet d’authentifier une requête HTTP via XMPP, ou en d’autres termes de valider qu’une requête sur un site web (ou autre) est bien faite par le possesseur d’un identifiant Jabber jid.

Le processus est décrit dans la XEP-0070.

Cette extension (antérieure à OpenID) a l’avantage d’être basée sur un protocole déjà répandu, dont certains serveurs sont très faciles à installer, et qui fourni beaucoup d’autres services (on n’installe pas juste un serveur d’authentification).

Comment ça marche pour l’utilisateur ?

D’un point de vue de l’utilisateur, c’est très simple : lors que l’on visite un site (ou autre), on donne son identifiant XMPP (jid). Le serveur va alors faire une demande qui apparaîtra sur le client XMPP de l’utilisateur, qui peut être sur son bureau, sur un site ouvert à côté, sur son téléphone, etc.

Un code affiché sur le client et le site doit être vérifié (ou entré dans le client selon les implémentations) par l’utilisateur, afin de s’assurer qu’il valide bien sa propre requête.

L’intérêt est multiple : non seulement il n'y pas besoin de retenir un nouveau mot de passe, mais c’est également une sécurité supplémentaire pour qui se connecte depuis un lieu public ou une machine étrangère (bibliothèque, ordinateur d’un ami, etc).

Une implémentation facile

Cette XEP est donc très intéressante. Cependant, elle est relativement difficile à mettre en place si on compare avec un système d’authentification plus classique, car cela nécessite des connaissances sur le protocole XMPP, et implémenter un client qui se chargerait de faire le travail. J’ai donc récemment implémenté cette XEP côté serveur sous la forme d’un composant et essayé de simplifier au maximum son utilisation pour qui voudrait profiter de ce type d’authentification. Il suffit de faire une requête HTTP sur le composant qui s’occupe de toute la partie XMPP. Ensuite, le code de retour de la requête HTTP détermine l’autorisation ou non, donnée par l’utilisateur.

L’avantage de cette implémentation est que l’on peut installer ce service sur une « autorité de confiance » qui dispose d’un serveur XMPP. Ensuite, un site Internet qui voudrait bénéficier de ce système d’authentification sans pour autant se préoccuper du XMPP, a la possibilité de le faire de manière très simple.

Cette implémentation n’entre pas non plus en contradiction avec la nature décentralisée du réseau XMPP. Tout le monde peut installer ce composant sur un serveur XMPP et l’utiliser pour soi. Ce serait bien triste de devoir faire confiance à une seule autorité…

Tour d’horizon des clients compatibles

Certains clients implémentent déjà cette XEP, et d’autres sont en cours d’implémentation :

Cependant, un client qui n’implémente pas la XEP n’est pas pénalisé pour autant. Un moyen de secours est prévu dans le standard, mais son implémentation n’est pas obligatoire (c’est au développeur d’en prendre l’initiative, ce qui est le cas pour l’extension susmentionnée). Espérons tout de même que d’autres clients viendront s’ajouter à cette liste, notamment sur appareils portables.

Ci-dessous, deux exemples de clients (Gajim et Salut à Toi) qui reçoivent une demande de confirmation.

Exemple de Gajim

Exemple de Salut à Toi (Primitivus)

Et maintenant ?

Jehan a écrit un plugin WordPress qui implémente cette XEP. Il serait donc intéressant de voir d’autres initiatives de ce genre fleurir, et que des sites Internet emboîtent le pas et mettent en place ce système d’authentification au même titre que l’authentification par Facebook ou OpenID.

Si vous connaissez (ou voulez apprendre) Ruby et si vous voulez contribuer à la fois à DLFP et à XMPP, c’est le moment ! Une entrée de suivi est ouverte pour implémenter l’authentification XMPP sur LinuxFr.org. Avec le composant mentionné plus haut, l’implémentation devrait être relativement aisée. Ceci pourrait inciter d’autres sites Internet à faire de même et amorcer l’effet boule de neige.

Télécharger ce contenu au format Epub

Lire les commentaires

Sortie de it-edit (Integrated Terminals Editor) 2.91

21 juillet, 2016 - 14:04

IT-Edit (Integrated Terminals Editor) est disponible en version 2.91.

Cette nouvelle version n'apporte pas de nombreuses améliorations par rapport à la version 2.0, mais constitue une étape importante, car elle est désormais basée sur la nouvelle version majeure de la bibliothèque libvte (bibliothèque implémentant un widget d'émulateur de terminal, utilisé par Gnome-terminal.) IT-Edit se met donc à niveau. À cette occasion, de nombreux bugs et imperfections ont été corrigés.

La plus importante des améliorations étant l'utilisation du chargeur de fichiers intégré à la bibliothèque gtksourceview3.0, qui permet de charger des fichiers codés dans tous les jeux de caractères (pas seulement UTF-8) ; l'éditeur s'est bien sûr amélioré avec le temps et la sortie des nouvelles moutures d'Ubuntu (Xenial) et de Debian (Jessie) ayant bien évolué depuis les versions précédentes.

Une intégration de la coloration syntaxique pour de nouveaux langages a été faite, comme par exemple le ReST sur lequel se base le générateur de documentation sphinx.

Concernant cette dernière (sur laquelle le nouveau gnome-terminal est basé) de nouvelles fonctionnalités apparaissent dans les menus contextuels des terminaux de it-edit :

  • ouvrir un nouvel onglet dans le panneau latéral de terminaux ;
  • fermer l'onglet actuel depuis ce panneau latéral ;
  • incrémenter la taille de la police (Font-scale, aussi configurable depuis le panneau de configuration) ;
  • décrémenter la taille de la police (Font-scale, aussi configurable depuis le panneau de configuration) ;
  • réinitialiser le terminal ;
  • et d'autres, accessibles depuis le panneau de configuration ;
  • la mauvaise nouvelle étant que libvte ne permet plus de mettre des images en arrière-plan des terminaux…

Mais je vous invite à tester ou à mettre à jour vers cette nouvelle version de it-edit en espérant que vous en serez satisfait(e). Je pense qu'il est utile de réellement tester un outil avant de l'adopter.

PS: it-edit ne se limite pas aux distributions de la famille Debian, il suffit de disposer des bibliothèques nécessaires par le biais du build de it-edit-2.91 basé sur les autotools.

Télécharger ce contenu au format Epub

Lire les commentaires

Faites votre promo avec CoLibre (appel à projets tuteurés)

21 juillet, 2016 - 10:21

Cette année encore, la licence pro CoLibre fait son appel à projet tuteuré.

C'est l'occasion de proposer à nos étudiant·e·s en communication, baigné·e·s dans le libre, votre besoin d'action de communication pour valoriser, promouvoir, accompagner, magnifier, planifier la visibilité et la diffusion de votre projet. Ces actions peuvent être autour de projet de développement, de l'animation d'une communauté, la production de supports visuels, audio-vidéos, documentation aussi bien dans le monde du logiciel libre que dans l'univers associatif ou dans le champ de l'économie sociale solidaire et durable. Les projets tuteurés peuvent donner lieu à des analyses, expertises, prescriptions mais aussi des réalisations.

Les projets démarrent en octobre et sont présentés début avril.

Veuillez consulter les liens pour plus de détails sur les conditions de soumission d'un projet.

Tous les projets ne sont pas retenus, mais l'équipe pédagogique essaye de piocher dans le lot des propositions des morceaux de projet qui pourraient servir d'appui pédagogique à un ou plusieurs enseignements.

Les projets sont à soumettre jusqu'au 10 septembre 2016

La licence pro CoLibre «Métiers de la communication : Chef de projet : Logiciels Libres et Conduite de projet» est un parcours de formation universitaire professionnalisant proposé par l'Université Lyon2.

En un an, il forme des étudiant·e·s ayant un bac+2 à la pratique de la communication et de la conduite de projet.

Petite particularité mais non des moindre, les outils numériques utilisés sont exclusivement des logiciels libres dans un environnement libre : une approche à la fois pédagogique de la place de l'outil, mais aussi éthique, économique et pratique.

Télécharger ce contenu au format Epub

Lire les commentaires

Agenda du Libre pour la semaine 29 de l'année 2016

19 juillet, 2016 - 09:33

Calendrier web, regroupant des évènements liés au Libre (logiciel, salon, atelier, install party, conférence) en France, annoncés par leurs organisateurs. Voici un récapitulatif de la semaine à venir. Le détail de chacun de ces 7 événements est en seconde partie de dépêche.

Sommaire Agenda du Libre pour la semaine 29 de l'année 2016 [Paris] Atelier Silex : faire des sites internet - Le mardi 19 juillet 2016 de 19h00 à 21h00.

Atelier Silex en mode contributhon à Mediabox
19 juillet @ 19:00 - 21:00
Suite aux 2 Master Class CV Web Silex organisées à l’E2C95 et à l’Espace Multimédia de Boulogne, on vous propose de se retrouver pour faire du Silex tous ensemble en mode contributhon.

[Ajaccio] Open Source Corsican Users - Le jeudi 21 juillet 2016 de 19h00 à 22h00.

Nous organisons notre 1er meetup d'utilisateurs de logiciels open source à Ajaccio.
L'été n'est peut être pas le meilleur moment pour lancer un meetup… à moins de se retrouver à une paillote… suggestions bienvenues !

[Paris] Soirée de Contribution au Libre - Le jeudi 21 juillet 2016 de 19h30 à 22h30.

Parinux propose aux utilisateurs de logiciels libres de se réunir régulièrement afin de contribuer à des projets libres. En effet, un logiciel libre est souvent porté par une communauté de bénévoles et dépend d'eux pour que le logiciel évolue.
Nous nous réunissons donc tous les jeudis soirs dans un environnement propice au travail (pas de facebook, pas de télé, pas de jeux vidéos, pas de zombies).
Vous aurez très probablement besoin d'un ordinateur portable, mais électricité et réseau fournis.

[Tours] L'auto-hébergement et pourquoi pas chez-vous ? - Le jeudi 21 juillet 2016 de 20h00 à 22h00.

Touraine Data Network dans le cadre de son objet "la défense et la promotion du réseau des réseaux Internet" vous propose un atelier sur l'auto-hébergement.
Venez découvrir les principes de l'auto-hébergement de ses propres services numériques: Pourquoi et comment ? L'essayer et pourquoi pas l'adopter !
Des ateliers complémentaires peuvent être organisés sur d'autres créneaux (essentiellement pour la mise en pratique l'atelier du jeudi soir étant la pour la découverte).

[Montpellier] Permanence « Les logiciels libres, parlons-en ! » - Le vendredi 22 juillet 2016 de 17h00 à 19h00.

Le Faubourg Marché, qu’est-ce que c’est ?
Le Faubourg Marché est une permanence partagée qui permet aux associations d’accueillir ensemble, les publics de ces associations une fois par semaine, le vendredi entre 17h00 et 19h00 (ou au delà sous réserve d’accord préalable), au 19, rue du Faubourg de Nîmes, 34000 Montpellier.
L’idée est de s’informer et d’informer les adhérents des diverses associations sur le fonctionnement du lieu et des associations, et notamment sur les 5 partenaires qui l’animent et lui permettent ainsi d’exister (autour.com, L’Accorderie, enercoop, modulauto, La Nef). Lors de cette permanence partagée vous pourrez rencontrer les associations La Graine (monnaie locale de Montpellier), éCOhabitons, Montpellier à pied, et bien sûr Montpel’libre.

[Marseille] Repair Café - Le vendredi 22 juillet 2016 de 17h30 à 19h30.

Pour lutter contre l’obsolescence programmée et favoriser le recyclage créatif, Repair Cafés et l’association CercLL (CercLL d’Entraide et Réseau Coopératif autour des Logiciels Libres).
Le vendredi 22 juillet 2016, de 17h30 à 19h30, réparons ensemble nos outils informatiques, chez Tulavu l'Artyshop 5 rue Félix Éboué Marseille 13002
Repair Café Marseille est une initiative citoyenne qui s’inscrit dans le contexte de la transition énergétique.

[Villeneuve d'Ascq] Libre à Vous - Le samedi 23 juillet 2016 de 09h00 à 12h00.

Vous souhaitez tester GNU/Linux sur votre ordinateur, vous recherchez un logiciel pour une fonction précise, des conseils ou de l'aide sur les logiciels libres ?
Libre à Vous est une permanence destinée à vous faciliter l'utilisation de l'informatique. Vous repartirez avec « le plein » de logiciels libres, fiables, évolutifs, performants et gratuits.
C'est chaque samedi matin au Centre d'Infos Jeunes à la ferme Dupire, 80 rue Yves Decugis à Villeneuve d'Ascq (métro Triolo) de 9h00 à 12h00.

Télécharger ce contenu au format Epub

Lire les commentaires

pkgsrc 2016Q2

19 juillet, 2016 - 09:28

Dans un message à des listes de diffusion pkgsrc et NetBSD, Jonathan Perkin a annoncé le 12 juillet 2016 la disponibilité de la branche pkgsrc-2016Q2. Pkgsrc (prononcer package source) est une infrastructure de construction de logiciels tiers pour NetBSD, ainsi que pour d’autres systèmes de type UNIX. Il permet donc à NetBSD, mais aussi à GNU/Linux, SmartOS, Minix, OS X et de nombreux autres systèmes d’exploitation de disposer de nombreux logiciels sous forme source, mais aussi sous forme binaire.

Les développeurs de pkgsrc fournissent une nouvelle version stable chaque trimestre. Comme son nom l’indique, pkgsrc 2016Q2 est donc la deuxième de l’année 2016.

Plus de détails sur cette version, en particulier en seconde partie de dépêche, qui reprend grandement le courriel d’annonce.

La piqûre de rappel

pkgsrc, c’est le système de paquets logiciels pour NetBSD, issu d’un fork en 1997 de celui de FreeBSD. Nos amis au drapeau orange étant adeptes de la portabilité, il est logique que leur système de paquets puisse fonctionner ailleurs et compte toujours plus d’une vingtaine de plates‐formes compatibles, allant des systèmes BSD à Windows (grâce à Cygwin/Interix/Services For Unix) en passant par GNU/Linux, OS X et Solaris.

Pour être plus concret sur la portabilité de pkgsrc, certaines personnes maintiennent des dépôts de paquets binaires en dehors de ceux pour NetBSD. Ainsi, le dépôt de la société Joyent contient des ensembles de paquets pour SmartOS, GNU/Linux (CentOS & RHEL 6) mais aussi  OS X, en plus du nécessaire de bootstrap.

Enfin, ces initiatives ne sauraient être couronnées de succès sans pkgin, gestionnaire de paquets créé par iMil et maintenu entre autres par Jonathan Perkin, actuellement en version 0.9.4.

La continuité dans la synthèse

Pour ce trimestre, Jonathan Perkin a continué dans le même style synthétique que celui initié par Alistair Crooks pour 2016Q1, limitant les statistiques aux informations suivantes :

  • 301 paquets logiciels ont été ajoutés ;
  • 1727 paquets ont été mis à jour.
Les changements

Les changements marquants côté logiciels sont les suivants :

Actualités diverses

Deux actualités viennent compléter cette dépêche. Tout d'abord, la disponibilité de NetBSD 7.0.1, qui vient surtout corriger des vulnérabilités, dont OpenSSL, Xen, NTP et bozohttpd.

La deuxième actualité concerne la mise en place d'un CDN pour rendre plus rapide le téléchargement des fichiers du projet NetBSD, mis en place chez Fastly. Pour l'utiliser dans pkgsrc, il suffit de remplacer dans vos fichiers de configuration les URL en ftp://ftp.netbsd.org par http://cdn.netbsd.org. Le protocole HTTPS est aussi pris en charge. Des liens de téléchargement d'images ISO sont aussi disponibles via le CDN, comme ici.

Télécharger ce contenu au format Epub

Lire les commentaires

SDL ou SFML ? Ne choisissez plus, prenez Gamedev Framework (gf)

19 juillet, 2016 - 09:26

Gamedev Framework (gf) est un framework de développement de jeu vidéo 2D en C++11. Il est basé sur SDL et OpenGL ES 2.0 et s'inspire très largement de l'API du module graphique de SFML avec quelques différences mineures et surtout en ajoutant des fonctionnalités non-présentes dans SFML.

La première version publique 0.1.0 de ce framework est sortie le 14 juillet 2016.

Gamedev Framework (gf) est publié sous licence zlib/libpng, identique à celle de SDL et SFML.

Sommaire

Dans cette deuxième partie, je vais vous raconter l'histoire de gf, d'où je suis parti et comment j'en suis arrivé à aujourd'hui. Je ne vais pas vous présenter l'API ou les fonctionnalités. Peut-être dans une prochaine dépêche, quand la bibliothèque aura bien mûri. Vous pouvez déjà avoir un aperçu avec la documentation.

Pourquoi et comment ?

Pourquoi avoir fait ce framework ? Dès qu'on veut faire un jeu en C++ sans moteur de jeu complet, on se retrouve très vite face à deux choix : SDL ou SFML. C'est une question récurrente que j'avais déjà posée en 2013, à l'heure où je commençais Akagoria.

Les arguments sont bien connus : SDL est écrite en C, est très portable, avec des API robustes et bien faites, mais assez bas niveau. Il y a bien quelques fonctions pour afficher des choses mais ça reste assez limité. En revanche, SDL est souvent utilisée pour obtenir un contexte OpenGL et la gestion des événements utilisateurs et ensuite, on peut utiliser directement OpenGL. De son côté, SFML est écrite en C++, est un peu plus haut niveau et est surtout assez adapté quand on débute parce qu'elle offre de très bonnes abstractions.

Depuis le début, j'avais choisi SFML pour Akagoria. L'idée de gf est venue des limitations de SFML. Depuis quelques temps, que ce soit pour Akagoria ou pour des game jams, je me retrouvais à devoir refaire quelques classes de bases, toujours les mêmes. J'en ai fait un projet à part : gameskel. Pour certaines parties, l'intégration avec SFML était assez pénible. Par exemple, j'avais des classes pour avoir des vues qui s'adaptent automatiquement au redimensionnement de la fenêtre. Mais impossible de faire uniquement des classes dérivées de sf::View, ce qui aurait été le plus logique et le plus simple. Du coup, j'étais obligé dans certains cas de faire des contorsions pour arriver à faire ce que je voulais. C'était de plus en plus compliqué.

Le déclic est venu quand j'ai parcouru le forum de SFML à propos des nouvelles fonctionnalités. J'ai été complètement ahuri de voir le conservatisme de certains développeurs de SFML. La moindre demande de fonctionnalité est quasi-systématiquement rejetée, y compris des fonctionnalités complètement triviales, avec des arguments limite fallacieux. Par exemple, un utilisateur demande l'ajout d'un sf::Line pour tracer une ligne entre deux points. Les réponses qu'il obtient, c'est qu'il devrait utiliser sf::Rectangle (pas super simple) ou alors recopier le bout de code qui se trouve sur le wiki ou alors utiliser une bibliothèque externe d'un des développeurs de SFML qui contient une ligne. Il y a aussi cet autre utilisateur qui demande à avoir une surcharge de la fonction scale() qui prend normalement deux paramètres: un pour x, un pour y. Sauf que dans 95% des cas, c'est le même paramètre (par exemple, quand on zoome ou qu'on dézoome). Le bout de code à ajouter fait littéralement 3 lignes. Mais non, on lui répond qu'on ne va pas ajouter ce cas trivial. Et il y en a des dizaines comme ça dans le forum. Et puis, il y a ce refrain qui revient comme quoi SFML ne serait qu'un framework multimedia et pas une bibliothèque pour développer des jeux (même si ça représente la quasi-totalité des cas d'utilisation).

À partir de là, je me suis dit que j'allais laisser tomber SFML.

OpenGL et fenêtrage

Ça tombe bien, j'avais envie de m'intéresser à OpenGL. Le choix a donc été vite fait pour ce qui concerne l'API graphique. Après, j'ai un peu tâtonné avant de me décider. En effet, OpenGL seul est inutilisable, il faut avoir un contexte OpenGL et pour ça, il n'y a pas d'API standard, chaque système a sa manière propre de créer un contexte. Sans compter qu'au delà du contexte, il y a toute la gestion des fenêtres et des entrées utilisateurs (clavier, souris, etc).

Là, on a plusieurs solutions. La première, c'est de réinventer la roue carrée, comme SFML et de recoder toute cette couche à la main. Autant dire que cette solution a été très vite évacuée parce que quand je vois la quantité et la complexité du code qu'il y a dans SFML juste pour cette partie, je me dis que c'est un boulot à part entière. Donc, je suis plutôt parti sur une bibliothèque qui fait déjà le boulot.

Mon premier choix s'est porté sur GLFW qui est une bibliothèque portable qui gère toute la partie fenêtre et entrée, et crée un contexte OpenGL. J'ai commencé et j'avais fait pas mal de trucs, ça marchait. Et puis, j'ai arrêté pour une raison simple : la gestion des manettes de jeu. Cette gestion est très aléatoire, dans le sens où pour chaque manette, la correspondance entre les touches et les identifiants ne sont jamais les mêmes.

Mon second choix a alors été SDL. De la même manière, SDL gère toute la partie fenêtre et entrée et crée un contexte OpenGL. De plus, SDL est connue pour avoir une très bonne gestion des manettes. J'ai donc repris une bonne partie de ce que j'avais déjà fait et j'ai tout porté vers SDL. En fait, SDL est beaucoup plus simple à utiliser. GLFW est basée sur des fonctions de rappel pour gérer les entrées utilisateurs et c'est assez pénible.

Au final, je ne regrette absolument pas le choix de SDL, bien au contraire.

OpenGL moderne

Après avoir un contexte OpenGL, il faut utiliser l'API. Mais quelle version ? Mon choix s'est portée sur OpenGL ES 2.0. Pourquoi ?

OpenGL ES 2.0 est une API plutôt vieille (elle date de 2007) et elle est présente quasiment partout des ordinateurs de bureau aux derniers ordiphones. OpenGL ES 3.0 à l'inverse est un peu trop récente (2012). De plus, WebGL est basée sur OpenGL ES 2.0, donc dès qu'on a un navigateur qui gère WebGL, on a un pilote capable de gérer OpenGL ES 2.0, ce qui fait beaucoup de matériel. Ensuite, OpenGL ES 2.0 est la version moderne d'OpenGL, celle où tout passe par un shader. Enfin, pour nous les libristes, Mesa3D prend en charge OpenGL ES 2.0 depuis Mesa 8.0 en 2012 donc même sur une Debian stable, on a ce qu'il faut en terme de pilote.

Alors certes, il manque des fonctionnalités à OpenGL ES 2.0 mais pour faire de la 2D, ça suffit amplement. Et puis, je préfère exploiter complètement la petite API d'OpenGL ES 2.0 plutôt que d'utiliser 50% d'une API plus évoluée. Voici quelques pointeurs vers de la documentation qui m'a été bien utile pour comprendre comment fonctionne OpenGL et la bonne manière de programmer avec OpenGL.

Choix de l'API

Plutôt que de réinventer une API, je suis très vite parti dans l'idée de cloner autant que faire se peut l'API de SFML. Les avantages, c'est qu'il n'y a pas besoin de réfléchir beaucoup au design de l'API, et que pour ceux qui voudraient passer de SFML à gf, l'effort sera très minime (remplacer sf par gf).

L'adaptation n'a pas toujours été de tout repos. SFML utilise de l'OpenGL à papa, c'est-à-dire sans aucun shader. Et donc, il a fallu mettre en place tout l'attirail de base quasiment de zéro. Pour ceux qui se demandent où ça se situe, c'est dans la fonction gf::RenderTarget::draw(). Après cette base, beaucoup de choses étaient semblables et j'ai repris pas mal de code de SFML en modernisant un peu le code (notamment en profitant du fait d'utiliser C++11).

Une des principales différences avec SFML est l'ajout des classes Vector et Matrix complètement génériques. Je me suis inspiré d'un article de Nathan Reed de 2013 qui explique un design à peu près standard pour ce genre de classes. J'ai ajouté tout un tas de fonctions classiques liées à ces classes (souvent des fonctions dont j'avais directement besoin dans la bibliothèque ou que j'avais déjà utilisées par ailleurs). Au final, le fichier Vector.h est un des plus gros fichiers : plus de 1600 lignes.

Portabilité windows

Un challenge que je me suis fixé était la portabilité sur Windows, et plus précisément avec MSVC. En effet, si je veux que ma bibliothèque puisse être utilisée le plus largement possible, il est nécessaire qu'elle soit utilisable sur Windows via Visual Studio. Après un gros effort d'adaptation du code, je n'aurai qu'un constat : quelle plaie !

Il faut être clair Visual Studio et son compilateur sont autant aimés que détestés. Et comme la dernière mouture de Visual Studio (2015) a une version Community gratuite, je me suis lancé. Personnellement, je trouve que le compilateur est mauvais. Pourtant, les développeurs ont annoncé une meilleure prise en charge de C++11, mais dans les faits, ils sont clairement à la traîne. Voici quelques adaptations que j'ai dû faire et que je n'aurais pas dû faire parce que le code d'origine était du code C++11 valide.

La première adaptation, c'est un truc que j'ai mis deux jours à comprendre. Ça se passe au niveau des constructeurs par copie et par déplacement qui sont générés implicitement (ou pas). J'avais dans ma classe un membre de type std::vector<std::unique_ptr<Foo>>. Or, il n'est pas possible de copier ce membre puisqu'il n'est pas possible de copier un std::unique_ptr. Donc, dans ce cas, normalement, le compilateur ne doit pas générer implicitement de constructeur par copie (puisqu'il ne peut pas le faire). Or, MSVC lui le génère. Sauf qu'après, et bien il essaie de l'utiliser et forcément, il sort une erreur : pas de le droit de recopier. L'astuce ici consiste à supprimer explicitement le constructeur par copie (alors que ça ne devrait pas être nécessaire). Deux jours sur cette connerie !

Ensuite, MSVC est connu pour très mal gérer les templates. En effet, il ne fait pas ce qu'on appelle le «two-phase lookup», ce qui a plein de conséquences très désagréables. Mais dans mon cas, il a très mal géré ce qu'on appelle par le doux nom de SFINAE, «Substitution Failure Is Not An Error». En gros, on définit une série de templates et à l'instanciation, le compilateur va essayer toute la série en substituant le type en paramètre par le type réel pour trouver le bon appel. Si le compilateur n'arrive pas à instancier correctement un des templates, ce n'est pas considéré comme une erreur, c'est juste que le type réel n'est pas adapté et donc ce template est éliminé de la liste des appels possibles. Avec MSVC, patatras, on obtient une erreur. Il instancie, ça ne marche pas, mais non, il considère que c'est une erreur. Du coup, il a fallu forcer l'élimination à grand coup de std::enable_if complétement superflus.

Dernier exemple, l'instanciation explicite de template. Avant C++11, quand on avait des classes templates, on pouvait instancier explicitement dans le code source (histoire de générer tout le code à un endroit) mais on ne pouvait pas dire qu'on avait instancié explicitement. Et donc, au final, ça ne servait pas à grand chose. En C++11, cette fonctionnalité a été ajoutée, ça s'appelle extern template. Sauf que pour MSVC, ça ne marche pas bien. Ça ne se marie pas très bien avec les dllimport/dllexport qu'on doit ajouter juste pour MSVC. Et du coup, j'ai fait pareil que dans le code de Chromium, j'ai désactivé les instanciations explicites pour MSVC (et il le vit bien).

Alors ouais, on pourrait me dire que ce sont des cas très particuliers. Mais je ne pense pas avoir fait du code très complexe. J'ai quand même passé une bonne semaine, je pense, à comprendre et corriger toutes les erreurs de compilation de MSVC. J'ai laissé de côté les avertissements (plus de 2000 !).

Un truc assez pénible à gérer avec Windows, c'est qu'il n'y a pas de paquets. Il faut donc tout installer à la main et ensuite, prier pour que ça fonctionne correctement. En particulier quand on utilise CMake. En définissant les bonnes variables d'environnement, on arrive presque à s'en sortir. Mais il reste que trouver les paquets binaires de bibliothèques assez communes est parfois compliqué. Par exemple, pour Freetype, le seul paquet binaire à disposition est en version 2.3.5 (qui date de 2007) alors que Freetype en est à la version 2.6.5. Ça pique.

Intégration continue

C'est la mode, il faut faire de l'intégration continue. Et puis, comme j'avais confiance dans mon code, j'ai tenté le coup.

Dans le monde libre, il existe Travis-CI qui permet à n'importe quel projet libre hébergé sur GitHub de profiter de l'infrastructure et de faire de l'intégration continue. J'avais déjà pu essayer ce service sur un autre projet donc je n'étais pas en terre inconnue. Sauf que depuis que je l'ai testé il y a quelques années, il n'a pas beaucoup évolué, et c'est bien le problème ! Proposer par défaut en 2016 une Ubuntu 12.04 (donc sorti en 2012), même Debian est à la pointe en comparaison. Ha oui, on peut utiliser une Ubuntu 14.04, mais c'est du bêta… Quel est le problème ? He bien les version de paquets ne sont pas du tout à jour. Chez moi, j'ai une Debian stable, ça m'a posé un problème parce qu'il n'y a pas SDL 2.0.4 mais uniquement SDL 2.0.2 (il manque quelques fonctions sympathiques). Mais là, on est sur une autre planète : sur Ubuntu 12.04, il n'y a même pas SDL2, uniquement SDL1. Du coup, j'ai quand même forcé l'utilisation d'Ubuntu 14.04.

Ensuite, il y a eu le problème des versions des compilateurs par défaut. Sur une Ubuntu 14.04, on a droit à GCC 4.8.4… qui ne gère pas complètement C++11. Heureusement, Travis-CI permet d'installer des paquet provenant de ppa, et notamment des paquets de compilateurs récents. Pour GCC, aucun problème. Mais pour Clang, il y avait un problème de vérification et donc impossible d'installer les dernières versions. Pas de souci, Clang 3.5 gère C++11 donc ça passe quand même. Et donc, j'ai trois configurations: GCC 4.9, GCC 5, Clang 3.5. Mais il faut croire que ce problème de vieux compilateurs ne gêne pas que moi.

Après ça, je me suis intéressé à AppVeyor qui est la même chose que Travis-CI mais pour le système Windows. Là, l'infrastructure est plus récente donc pas plus de souci qu'avec mon Visual Studio local. Mais on se retrouve avec le problème des paquets binaires. Parce que là, ça devient funky : il faut, dans le script appelé par l'instance AppVeyor qui va compiler le code, télécharger les paquets binaires et les décompresser et mettre en place toutes les variables d'environnement qui vont bien et appeler CMake. Et surtout invoquer l'esprit de Turing pour que tout fonctionne de manière déterministe. Et après quelques hésitations, ça fonctionne !

Au final, ça vaut quand même le coup de passer du temps à tout bien configurer. Ça permet d'avoir un CMakeLists.txt à peu près portable, d'être sûr qu'on n'introduit pas de régression fatale, d'avoir une recette pour construire la bibliothèque. Et puis, on peut afficher de beaux petits badges pour montrer qu'on a bien fait son boulot.

Documentation

Dernier point que j'aimerais aborder : la documentation. C'est long ! Je pense qu'au final, j'ai dû passer à peu près un tiers du temps total sur l'écriture de la documentation. Déjà, il y a la documentation Doxygen du code. Certes, ça ne suffit pas mais c'est quand même nécessaire. Là aussi, vu que j'ai cloné l'API de SFML, j'ai également cloné une bonne partie de la documentation Doxygen. Maintenant, je ne souhaite pas aller plus loin dans le clonage, en particulier, je pense que je ne clonerai pas les tutoriels de SFML qui sont pourtant d'excellente qualité. J'ai donc entrepris de compléter la documentation Doxygen par des petits articles sur des ensembles de classes. Ce n'est pas fini mais ça avance petit à petit. L'idée, c'est aussi de commencer par faire des trucs simples et rapides et de les compléter au fur et à mesure, en fonction des retours.

L'objectif à terme, c'est d'avoir une documentation assez complète mais vivante. Et surtout accessible aux néophytes, comme par exemple mes étudiants.

Et maintenant ?

Avant la version 1.0, il y a encore du travail. Comme déjà dit, j'aimerais compléter la documentation au mieux. Puis, j'aimerais ajouter des fonctionnalités. J'ai déjà quelques idées, et j'ai fait un peu de prospection et il y a des trucs que j'aimerais bien essayer. Mais ça, ça sera pour une prochaine fois. Et puis surtout, je vais porter Akagoria sur ce framework, histoire de ne pas faire un framework pour faire un framework. Et pour utiliser toutes ces magnifiques fonctionnalités !

Télécharger ce contenu au format Epub

Lire les commentaires

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

18 juillet, 2016 - 22:39

La revue de presse de l'April est régulièrement éditée par les membres de l'association. Elle couvre l'actualité de la presse en ligne, liée au logiciel libre. Il s'agit donc d'une sélection d'articles de presse et non de prises de position de l'association de promotion et de défense du logiciel libre.

Sommaire

[Le Monde Informatique] Collectivités territoriales: Le label libre plus disponible au 1er octobre

Par Didier Barathon, le vendredi 15 juillet 2016. Extrait:

L'Adullact, avec le soutien de l'Etat et de la DINSIC, propose depuis le 1er juillet aux collectivités territoriales qui le souhaitent de se doter du label Territoire numérique libre pour signifier leur engagement envers les technologies ouvertes. La date limite de dépôt des dossiers est fixée au 30 septembre.

Lien vers l'article original: http://www.lemondeinformatique.fr/actualites/lire-collectivites-territoriales-le-label-libre-plus-disponible-au-1er-octobre-65421.html

Et aussi:

Voir aussi:

[ZDNet France] AbulEdu, des logiciels libres pour l'enseignement sauvés par crowdfunding

Par Thierry Noisette, le jeudi 14 juillet 2016. Extrait:

Créé en 2001 par des enseignants et des informaticiens libristes, cet ensemble d'outils logiciels devrait être pérennisé grâce à une campagne réussie.

Lien vers l'article original: http://www.zdnet.fr/actualites/abuledu-des-logiciels-libres-pour-l-enseignement-sauves-par-crowdfunding-39839724.htm

Voir aussi:

[Les Echos] Pour une Équipe France du numérique

Par Grégory Pascal, le mercredi 13 juillet 2016. Extrait:

En politique, économie, pour un seul secteur professionnel, il n’existe pas d'"équipe". Une équipe suppose à sa tête un modèle de référence sur lequel on peut, si ce n’est, copier, du moins, compter. Avons-nous donc un leader, capable de créer l’"Équipe France" du numérique qui saura positionner le pays sur les devants de la scène internationale? La question est posée, mais la réponse est loin d’être facile.

Lien vers l'article original: http://www.lesechos.fr/idees-debats/cercle/cercle-158896-pour-une-equipe-france-du-numerique-2014279.php

[Le Monde.fr] A peine adopté, l’accord Privacy Shield sur les données personnelles est déjà menacé

Par Martin Untersinger, le mercredi 13 juillet 2016. Extrait:

Le nouveau cadre négocié entre l’Union européenne et les Etats-Unis pour remplacer Safe Harbour pourrait se retrouver bientôt devant la justice.

Lien vers l'article original: http://www.lemonde.fr/pixels/article/2016/07/13/a-peine-adopte-l-accord-privacy-shield-sur-les-donnees-personnelles-est-deja-menace_4969020_4408996.html

Voir aussi:

[Prat!que] La loi numérique fait débat

Par Charlotte Jouss, le mardi 12 juillet 2016. Extrait:

Dans le cadre de la loi Numérique, mercredi 29 juin dernier, la commission mixte paritaire (CMP) composée de 7 députés, 7 sénateurs ainsi que de nombreux membres suppléants, a réussi à mettre en place un accord pour que les administrations encouragent "l’utilisation des logiciels libres et des formats ouverts lors du développement". Celui-ci fait débat.

Lien vers l'article original: http://www.pratique.fr/actu/la-loi-numerique-fait-debat-1563076.html

Et aussi:

[Next INpact] Java: Oracle ne veut pas laisser passer la victoire de Google

Par Vincent Hermann, le mardi 12 juillet 2016. Extrait:

En mai, Google a infligé une défaite retentissante à Oracle. Ce dernier réclamait 9 milliards de dollars pour avoir violé le copyright de Java et s’en être servi pour assurer le succès d’Android. Un juge en a finalement décidé autrement: il s’agit bien d’un cas de fair use. Qu’Oracle conteste à présent.

Lien vers l'article original: http://www.nextinpact.com/news/100607-java-oracle-ne-veut-pas-laisser-passer-victoire-google.htm

Et aussi:

[Developpez.com] La ville de Grenoble compte faire migrer huit autres écoles sur Linux cette année

Par Olivier Famien, le lundi 11 juillet 2016. Extrait:

En juin 2015, les autorités de la ville de Grenoble ont présenté leur projet de remplacer les systèmes d’exploitation propriétaires équipant actuellement les appareils dans les écoles de la ville par le système d’exploitation Linux. Quelques mois plus tard, et plus précisément en décembre dernier, la ville de Grenoble a encore annoncé son adhésion à l’association April, ayant pour vocation de défendre et promouvoir les logiciels libres.

Lien vers l'article original: http://www.developpez.com/actu/101131/La-ville-de-Grenoble-compte-faire-migrer-huit-autres-ecoles-sur-Linux-cette-annee-et-prevoit-de-basculer-plusieurs-autres-ecoles-d-ici-2018

[la Croix] «Les communautés du Web collaboratif restent peu visibles du grand public»

Par Julien Duriez, le vendredi 8 juillet 2016. Extrait:

Cet été, La Croix fait le portrait des communautés des bénévoles de l’Internet libre et collaboratif. En guise d’introduction, entretien avec Dominique Cardon (1). Ce sociologue de la technique, spécialiste des rapports entre nouvelles technologies et mobilisation politique, suit les militants du Web collaboratif depuis leurs débuts.

Lien vers l'article original: http://www.la-croix.com/Sciences/Numerique/Les-communautes-Web-collaboratif-restent-visibles-grand-public-2016-07-08-1200774524

Télécharger ce contenu au format Epub

Lire les commentaires

Sortie de la version 8.9.0 des applications bureautiques OnlyOffice

18 juillet, 2016 - 21:56

Ascensio System Sia a annoncé le 07 juillet 2016 la sortie de la nouvelle version de OnlyOffice, une suite bureautique libre qui inclut des éditeurs de textes, de classeurs et de présentations (OnlyOffice Document Server déjà présenté sur LinuxFR.org ) complétés par les applications de gestion de documents, de projets, de clients, de communauté, de courriels, de contacts (OnlyOfficeCommunity Server) et le serveur de messagerie (OnlyOfficeMail Server). Cette dépêche revient sur les principales nouveautés de cette version.

Nouveautés

La version 4.0.0 des éditeurs de document OnlyOffice (Document Server) change : le code fonctionnant côté serveur abandonne ASP.NET pour passer à Node.js. Il offre un grand nombre de nouvelles fonctionnalités :

  • ajout des commentaires ;
  • tchat intégré ;
  • édition à plusieurs, rapide en temps réel comme dans Google Docs ;
  • révision et suivi des changements ;
  • historique des versions ;
  • fusion et publipostage ;
  • texte artistique ;
  • plages nommées ;
  • ajout, suppression et modification de styles ;
  • prise en charge des paramètres de localisation.

Document Server est distribué sous licence GNU Affero General Public v3.

La version 8.9.0 du système collaboratif OnlyOffice (Community Server) fournit de nouvelles fonctions de collaboration :

  • intégration de Calendrier et Mail ;
  • envoi des invitations à un événement à tout utilisateur Internet en utilisant son adresse électronique ;
  • réception des notifications d’acceptation ou de refus de l'invitation par courriel ;
  • notification des invités par courriel sur les modifications apportées à l’événement ;
  • reçu des invitations provenant des calendriers tiers ;
  • partage de documents en mode révision ;
  • courriel ;
  • carnet d'adresses pour la gestion des contacts personnels ;
  • réponse automatique à tous les messages entrants lorsqu'on est absent ;
  • création d'un nouveau contact CRM à partir du courriel.

Community Server est distribué sous licence GNU GPL v.3.

Comment l'installer

Outre des options communes, telles que la compilation du code source disponible sur GitHub, le téléchargement des paquets pré-installés de SourceForge et des images Docker, OnlyOffice offre le script Docker qui permet de configurer les conteneurs Docker avec tous les composants nécessaires pour un fonctionnement correct de OnlyOffice, ainsi que les machines virtuelles avec OnlyOffice préinstallé.

Installation à l'aide du script Docker :

Etape 1 : Téléchargez le script Docker (NdM.: le téléchargement n'est pas disponible en https contrairement à la page qui le propose, attention donc à ce que vous téléchargerez, avant de l'exécuter)

$ wget http://download.onlyoffice.com/install/opensource-install.sh

Etape 2 : Installez OnlyOffice

$ chmod +x opensource-install.sh $ ./opensource-install.sh -md "votredomaine.fr.example.com"

votredomaine.fr.example.com est un nom de domaine pour serveur de courriel.

Pour plus de détails, consultez la documentation officielle.

Pour des problèmes techniques, visitez le forum.

Télécharger ce contenu au format Epub

Lire les commentaires

Une grosse tuile pour GNOME Maps

16 juillet, 2016 - 17:24

GNOME Maps est une application bureau pour parcourir et éditer la carte d'OpenStreetMap. Elle propose également un service de routage (via GraphHopper).

L'application a été construite de manière à aller chercher les tuiles nécessaires chez MapQuest, qui était un service gratuit. Néanmoins, il y avait un risque que cela change.

C'est exactement ce qui est arrivé le 11 juillet 2016. Vu que la source des tuiles est propre à GNOME Maps, toutes les versions distribuées (de 3.12 à 3.20) sont donc devenues inutilisables.

NdM : Merci à Arthur pour le titre de cette dépêche.

Un rapport de bogue est déjà présent, mais ce n'est pas encore prêt. La communauté envisage soit de trouver un fournisseur autre, comme OpenStreetMap lui-même, mais une autorisation est nécessaire sans quoi GNOME Maps se ferait bannir. L'autre solution envisagée serait d'ouvrir un serveur de tuile propre pour GNOME Maps, ce qui offrirait l'avantage de modifier l'apparence des cartes plus facilement, mais il n'y a ni financement pour cela, ni personne pour l'administrer.

Vous pensez pouvoir aider à résoudre la situation ? N'hésitez-pas à apporter votre aide d'une manière ou d'une autre dans le rapport de bogue.

Télécharger ce contenu au format Epub

Lire les commentaires

Protéger sa vie privée avec l’IPv6

15 juillet, 2016 - 14:13

Le futur d'Internet est l'adressage IPv6 en lieu et place de l'actuel protocole IPv4, puisque nous sommes en train d'atteindre les limites de ce dernier.

Malgré ses indéniables atouts, le protocole IPv6 pose certaines questions sur le respect de la vie privée lors de sa configuration automatique. Nous proposons dans cette dépêche de passer en revue les problèmes et d'esquisser des solutions afin de mieux protéger sa vie privée avec IPv6.

Sommaire

Le protocole IPv6 a un très grand avantage sur son ancêtre : la taille des adresses passe de 32 à 128 bits. Ça n'a l'air de rien comme ça, mais cette profusion d'adresses résout beaucoup de problèmes d'IPv4 sans nécessiter la complexité de ce dernier :

  • il n'y a plus besoin de créer des réseaux « privés » (avec un NAT) puisque le nombre d'adresses disponibles est largement suffisant. Ainsi, si les règles de routage le permettent, les clients peuvent être connectés directement entre eux (ce qui facilite l'adoption des connexions P2P). Ne pas avoir à configurer de NAT est un grand avantage également pour l'auto-hébergement, car il n'y a pas besoin de gérer l'ouverture et la redirection des ports du routeur, ce qui simplifie grandement sa configuration, puisque "seul" le pare-feu doit être géré ;
  • il n'y a plus de nécessité de coordinateur central pour gérer les baux d'adresses d'un sous-réseau (DHCP), puisqu'il suffit de tester si une adresse tirée au hasard est disponible, tester si quelqu'un l'utilise et l'utiliser (ou tester une nouvelle) ;
  • les cartes réseau peuvent louer autant d'adresses que désiré, puisque les sous-réseaux contiennent suffisamment d'adresses disponibles (bien plus que les fameuses 255 adresses fournies par les réseaux privés installés par défaut) ;
  • le routeur est capable de s'annoncer directement sur le réseau pour tous les appareils lui étant connectés par le réseau « lien-local » (i.e. physiquement branché sur le même réseau). Ainsi, les clients peuvent se configurer automatiquement pour avoir accès au reste d'Internet. Ceci est possible grâce à la possibilité d'avoir plusieurs adresses par interface : une adresse lien-local utilisée pour recevoir les informations et mises à jour du réseau local et une adresse globale pour se connecter au reste d'Internet.

Malgré tous ces avantages, un des inconvénients connus d'IPv6 est que le fichage du trafic des ordinateurs particuliers est plus aisé par les attaquants. En effet, une des propriétés du protocole NAT était d'utiliser une seule adresse IPv4 publique pour plusieurs appareils, ce qui rendait un peu plus difficile le fichage des utilisateurs, puisque plusieurs d'entre eux utilisaient la même adresse pour se connecter à Internet.

Avec IPv6, chaque ordinateur ayant sa propre adresse publique, l'attaquant peut faire un lien direct entre une adresse et un utilisateur particulier.

Un attaquant pourrait être un homme du milieu qui écouterait le trafic IP ou une personne ayant accès à des logs de différents serveurs. Avec de telles informations, l'attaquant pourrait faire des liens entre les différentes activités des utilisateurs, bien qu'elles ne soient pas liées directement.

Par exemple, il pourrait savoir quand un employé travaille sur Internet ou quand une personne est présente chez elle.

Il faudrait donc veiller à ce que les machines du réseau changent d'adresse IP publique régulièrement pour rendre le fichage plus difficile. Il pourrait changer à travers le temps et/ou selon le réseau auquel il se connecte.

Dans la suite de cette dépêche, nous vous proposons d'analyser les moyens à disposition des utilisateurs pour rendre difficile le fichage des utilisateurs par les serveurs au moyen d'adresses IPv6.

Connexion aux réseaux en IPv6 avec l'autoconfiguration

Pour commencer, il faut savoir que les adresses IPv6 sont définies en deux parties :

  • le préfixe réseau qui est défini par le FAI. Il est annoncé sur le réseau par le routeur au moyen des adresses de type lien-local.
  • l'identifiant d'interface qui se compose des bits restants et qui identifie une interface d'une machine dans le réseau.

Quand un appareil connecte son interface sur un réseau, ce dernier crée automatiquement une adresse de type lien-local avec le préfixe réseau [fe80::]/10. Ces adresses ne doivent être utilisées qu'à l'intérieur d'un même réseau (donc les routeurs ne doivent pas permettre de connexion sortante) et permettent de découvrir les autres appareils connectés sur le même réseau.

Grâce à cette adresse locale, la machine peut écouter les annonces diffusées par le routeur sur le réseau. Avec ces annonces, la machine reçoit de la part du routeur le préfixe réseau à utiliser pour communiquer avec l'extérieur.

Comme l'appareil est connecté au réseau local, il peut aussi communiquer avec les autres appareils du réseau et contrôler quels identifiants d'interface sont déjà utilisés par les autres (il crée un identifiant d'interface, il annonce qu'il souhaite l'utiliser et il peut l'utiliser si aucun des voisins ne l'utilise déjà).

Afin de trouver plus rapidement un identifiant d'interface réseau non-utilisé, si la taille du préfixe réseau le permet (inférieure ou égale à 64 bits), la machine peut tenter d'utiliser l'adresse MAC de son interface réseau comme identifiant. Cependant, comme l'adresse MAC devrait être unique à l'interface réseau de la machine, l'adresse IP trouvée sera non seulement globalement unique (après contrôles avec son voisinage), mais également invariable.

Les deux RFCs que nous allons analyser proposent des solutions pour ce système de configuration automatique qui utilise les adresses MAC, afin d'utiliser des identifiants moins constants à travers le temps et les réseaux. Leur objectif est de ne plus utiliser directement sur le réseau une adresse IP invariable, afin de protéger l'utilisateur d'un potentiel fichage.

RFC 4941 : rendre les adresses auto-configurées temporaires

Cet RFC propose de rendre le pistage du trafic d'un client IPv6 plus difficile en étendant la définition des types d'adresses IPv6 avec un type temporaire.

Il propose une solution pour résoudre les problèmes suivants :

  • Comme l'identifiant d'interface reste constant à travers tous les réseaux auxquels le client se connecte, un attaquant, qui aurait accès aux logs de différents serveurs, peut trouver des corrélations entre les différentes activités du client.
  • Un attaquant qui écouterait le trafic du réseau peut facilement retrouver les communications d'un client précis en lisant les données IPv6 des paquets réseau.

Il identifie également que sa solution ne peut pas résoudre la découverte de corrélation utilisant :

  • les données utiles transportées par les paquets
  • les caractéristiques des paquets telles que leur taille et leur chronologie
  • le préfixe réseau pour les réseaux avec peu de machines (tels que ceux de nos domiciles) ; dans ce cas, la « confidentialité » permise serait la même qu'avec l'utilisation d'un NAT sur IPv4.

Pour résoudre les problèmes identifiés, le RFC propose de créer le principe de type d'adresse « temporaire », c'est-à-dire des adresses qui auront l'obligation de passer à un statut obsolète après un certain temps et qui ne seront pas devinables en utilisant des informations disponibles sur le réseau.

Ce RFC précise donc un algorithme qui remplacera l'utilisation de l'adresse MAC pour trouver rapidement un identifiant unique par l'utilisation du hasard. Il conserve les autres principes de l'auto-configuration, mais permet de créer directement un ensemble d'adresses temporaires (au lieu d'une seule adresse) et détermine une période de regénération et remplacement de ces adresses.

Cependant, il a été décidé que, par défaut, la génération des adresses temporaires crée une seule adresse par préfixe réseau pour lequel l’auto-configuration est active. Créer un nombre limité d'adresses évite d'obliger le client à rejoindre trop de groupes multicast (prévus par IPv6 et obligatoires), ce qui permet de ne pas avoir trop d'inquiétudes par rapport aux performances.

L'idée générale de l'algorithme est de tirer un nombre au hasard, de le coller à l'identifiant d'interface existant, d'appliquer une fonction de hashage sur ce nombre (MD5 est proposé, mais l'utilisation d'un autre algorithme est ouvert). Du résultat du hash, on prend les 64 bits les plus à gauche pour les utiliser comme bit d'interface et le reste est conservé comme nombre aléatoire pour la prochaine itération (qui arrivera au moins pour le renouvellement de l'adresse temporaire ou pour le prochain redémarrage de la machine).

Il aurait été possible de ne faire que le tirage de nombre aléatoire, mais il est difficile de trouver un nombre réellement aléatoire. C'est pour ça que l'algorithme a été prévu pour ne le calculer que la première fois et d'utiliser un historique pour générer les nombres suivants.

RFC 7217 : créer par défaut des identifiants d'interface non-prédictibles et stables

Le RFC précédent définit les adresses temporaires pour des communications sortantes, mais elles nécessitent toujours les adresses IP crées avec les adresses MAC pour l'établissement des communications entrantes (fonctionnalités de type serveur).

Le RFC 7217 propose une solution pour rendre plus opaques ces adresses stables nécessaires aux fonctions de type serveur. En effet, l'utilisation de l'adresse MAC permet encore à un attaquant de trouver des corrélations d'activités sur Internet et il peut également plus facilement réduire le nombre d'adresses en cours d'utilisation à scanner (puisque l'adresse MAC réduit le nombre d'identifiants possibles, notamment en connaissant le constructeur des interfaces réseau).

Comme ce RFC travaille sur les adresses stables, il peut être utilisé de manière complémentaire aux adresses temporaires, sans en être dépendant. Ainsi, si un réseau interdit l'usage des adresses temporaires, les risques de découverte d'adresses utilisées et de corrélations d'activité peuvent quand même être réduites.

Dans les grandes lignes, l'algorithme produit des identifiants d'interface stables pour un réseau donné. C'est à dire qu'à chaque changement de réseau, les identifiants changent, mais lors du retour sur un réseau, il devrait reprendre la même valeur qu'auparavant (si l'identifiant n'a pas été utilisé par un autre appareil entre temps). Malgré cette stabilité, les identifiants ne sont pas prédictibles, car l'algorithme utilise une clé privée connue uniquement par le système local.

Ainsi, l'algorithme est capable de créer des identifiants d'interfaces assez stables pour des fonctionnalités de type serveur (connexion entrantes) pour un réseau donné. Il permet d'éviter la corrélation des activités sur différents réseaux (par exemple, l'activité au bureau et à la maison d'une machine portable n'est plus liée par une adresse unique), tout en permettant d'utiliser une adresse non-temporaire pour certains services de la machine.

Conclusion

Finalement, avec l'activation de ces 2 RFCs dans les gestionnaires de réseau des machines, il est possible d'avoir les avantages de l'auto-configuration d'IPv6 avec une protection de la vie privée au moins égale à celle de l'utilisation d'un NAT avec IPv4.

En effet, le RFC 7217 permet de toujours créer des adresses non-prédictibles (et différentes sur chaque réseau) et le RFC 4941 permet de créer des adresses temporaires qui auront l'obligation d'être abandonnées après un certain temps d'utilisation.

Le travail des attaquants est donc rendu bien plus difficile pour créer des corrélations des activités d'une machine sur les réseaux tout en gardant l'avantage d'IPv6 où la configuration manuelle n'est pas nécessaire et où les adresses IPs utilisées sur le réseau sont toutes des adresses publiques facilitant le P2P.

Cette dépêche a été proposée car un développeur de Network Manager a annoncé l'implémentation de ces 2 RFCs pour la release 1.2.

Télécharger ce contenu au format Epub

Lire les commentaires

Fwomaj 0.3 : Vidéos à la coupe au rayon frais

14 juillet, 2016 - 17:59

Fwomaj est un lecteur multimédia qui permet la sélection rapide de fichiers vidéo au retour d'une séance de tournage (on dit « dérusher ») pour un montage ultérieur. Fwomaj est sous licence GPL 2.

Sommaire

En premier lieu, il affiche la forme d'onde de la piste audio du fichier, afin de savoir tout de suite s'il s'y trouve du son, et à quel endroit.

Il permet également le transcodage de la vidéo en H264, et sa sauvegarde dans les trois containers courants: Matroska (.mkv) MPEG-4 (.mp4) et AVI (.avi) que l'utilisateur choisit à l'aide d'un menu.

Et enfin, il permet de couper le début et la fin de la vidéo à l'aide de contrôles visuels.

En bonus, il fournit également une fenêtre d'information qui liste les caractéristiques multimedia du fichier de façon exhaustive.

Code

Fwomaj est en Python 3, l'interface est en Gtk 3. Le moteur vidéo (et audio) est GStreamer 1.0.

Dépendances Son & Lumières

C'est bien sûr FFmpeg qui fait le gros du travail : c'est lui qui génère l'image de la forme d'onde, lui encore qui découpe le fichier de temps à temps+n, et lui enfin qui encode tout ça, à son rythme de supertanker.

Au moment où l'utilisateur appuie sur Encode on récupère les valeurs des menus (qui sont par défaut aux valeurs que moi, j'utilise : 30 images / secondes, Matroska) et celles des deux réglettes début/fin, et on construit la commande FFmpeg (et le nom du fichier de destination) avec tout ça :

out_file = '{}_{}-{}_{}fps.{}'.format(filename, str(start_time), str(end_time), self.frame_rate, self.file_format) command = [FFMPEG, '-y', '-i', filename, '-r', self.frame_rate, '-strict', '-2', '-c:v', 'libx264', '-ss', start_time, '-to', end_time, out_file]

Et on envoie tout ça à une classe qui

  • lance le process (en asynchrone, et rend la main) ;
  • vérifie toutes les secondes qu'il n'est pas fini ;
  • avertit l'utilisateur quand il est fini.

Le fichier de destination est sauvé dans le répertoire du fichier d'origine.

Au chargement d'un fichier multimedia – au lancement du programme ou après – c'est le même processus qui gère la génération de la forme d'ondes, qui s'affiche quand elle est prête (pour un gros fichier, ça peut prendre plusieurs longues secondes) sans ralentir l'interface.

Êtes-vous sûr de ne pas vouloir arrêter le processus d'annulation ?

Du coup, comme je ne lis pas la sortie de FFmpeg (je vérifie juste les codes de retour) je suis en asynchrone, yay, mais je perds la possibilité d'informer l'utilisateur de l'avancement du travail en cours, bouh ; juste un bidule qui pulse pour indiquer qu'il se passe quelque chose. Notez que FFmpeg lui-même ne le fait pas, mais il indique quelle image il est en train de traiter, or moi, j'ai plein de moyens de savoir combien d'images fait mon fichier, à commencer par Mediainfo. Eh. Dommage.

Pour arrêter un job FFmpeg qui prendrait trop de temps, il faut quitter le programme. Je ne suis pas en train de décrire un choix d'implémentation là, hein, mais la conséquence du choix de ne rien implémenter du tout pour le moment.

Chez moi, ça marche (tm) :) mais je vais quand même, c'est sûr, à un moment, faire une entrée de menu avec un raccourci clavier pour envoyer q au process FFmpeg en cours (oui, il écoute stdin – à la fois des pipes nommés pour le streaming ET le clavier pour les commandes – et s'exprime exclusivement sur stderr, il est spé' FFmpeg) j’attends de voir un peu comment ça se passe au niveau ergonomique.

Genre de style d'UI

Afficher une image, l'étirer sur toute la largeur de la fenêtre principale, puis la re-dimensionner quand change la taille de cette dernière, est un processus assez lourd, qui implique une gestion relativement fine des événements, si on veut faire ça en utilisant les classes et méthodes de Gtk lui-même (Gtk.image, Gtk.Pixbuf, Gtk.DrawingArea, Gtk.ScrolledWindow etc.) c'est ainsi que marchait la première version en Python2/Gtk2, mais le principe est le même.

Mais Gtk3 intègre CSS3, ce qui a permis de remplacer ce genre de machin :

def on_resize(self, widget, event, window): allocation = widget.get_allocation() if self.temp_height != allocation.height or self.temp_width != allocation.width: self.temp_height = allocation.height self.temp_width = allocation.width pixbuf = self.waveform_image.get_pixbuf().scale_simple(allocation.width, allocation.height, gtk.gdk.INTERP_NEAREST) widget.set_from_pixbuf(pixbuf)

Oui oui, c'est bien ça, à chaque événement (cette fonction est un callback sur l'événement on_resize de la fenêtre, donc des centaines de fois par seconde, dans la joie) on re-crée un pixbuf en attrapant celui de l'image en place, on le retaille aux dimensions XY de la fenêtre, et on le remet dans l'image, qu'on remet dans le widget, ouf :/ c'est comme ça qu'on fait, au centre hippique PyGtk.

Par quelque chose comme ça:

CSS = '#WBox {background-size:100% 100%;background-image: url("{}");}'.format(uri) style_provider.load_from_data(CSS)

Quand j'ai percuté (je suis développeur web, moi, à la base) genre sous la douche, je me suis dit c'est pas possible, ça peut pas être si simple, ça a marché au premier essai.

Mediainfo

…Est le meilleur outil d'analyse de fichiers multimédia, oui du monde, même sans les mains, point final. J'avais commencé à implémenter une usine à mazout en utilisant les fonctions de "découverte" de GStreamer, pour éviter une dépendance, mais sa souplesse et son intelligence relative étaient ridicules face aux capacités d'introspection de Mediainfo.

Bugs

Quoi ? Naaan :) Si. On commence par les petits.

Blanker (Gtk)

Quand on passe en plein écran, les contrôles disparaissent, ainsi qu'il est d'usage. Ce n'est pas du vrai plein écran d'ailleurs, au sens où on l'entend : Le gestionnaire de fenêtre n'est pas averti, pour commencer, enfin je crois, je maximise juste la Gtk.DrawingArea où j'affiche les pixels qu'envoie le pipeline de GStreamer.

Quand on bouge la souris, ces contrôles réapparaissent, toujours selon les protocoles en vigueur. Mais je n'ai pas réussi (j'y ai passé toute une soirée !) à démarrer un timer à ce moment, pour qu'au bout de, mettons 10 secondes d'inactivité de la souris ou du clavier, lesdits contrôles disparaissent à nouveau. Je parie que c'est une tarte à la crème, un classique du développement d'interfaces graphiques, et que quelqu'un ici va bien nous trouver une solution :)

Rendu (GStreamer)

Ça n'a bien sur pas d'incidence sur le fichier produit, mais le rendu vidéo est bordé d'un pixel de couleur, variable, comme une sorte de somme spectrale de l'image en cours, et ça bouzille le noir qui est d'usage autour de tout film décent. Mon implémentation est bancale, clairement. Je déteste ce bug minuscule et en même temps énorme, il me donne l'impression de ne rien contrôler du tout.

C'est évidemment un bout de code que j'ai copié collé de je ne sais plus d'où, car c'est pas du tout comme s'il existait ne serait-ce qu'une page dans tous les interfubles qui dit "bon, voilà, GStreamer 1.0 est sorti, même gst-launch a été renommé gst-launch-1.0 pour qu'on comprenne bien que plus rien n'est compatible, et donc voilà quelques exemples d'usage en Python3 / Gtk3 oh rien du tout, juste une implémentation de base.

On peut faire plein de choses avec GStreamer. C'est un langage de pipes vidéo assez fascinant, qu'on prototype à l'aide de l'utilitaire gst-launch, pour construire des "tuyaux" d'images qui bougent:

gst-launch-1.0 videotestsrc pattern=1 ! video/x-raw,format=AYUV,framerate=\(fraction\)10/1,width=100,height=100 ! videobox border-alpha=0 top=-70 bottom=-70 right=-220 ! videomixer name=mix sink_0::alpha=0.7 sink_1::alpha=0.5 ! videoconvert ! xvimagesink videotestsrc ! video/x-raw,format=AYUV,framerate=\(fraction\)5/1,width=320,height=240 ! mix.

Mais GStreamer est si complexe que sa documentation plane dans les limbes…

Du coup GStreamer est… magique :

Sur cette image prise en plein écran (la sublime ouverture de « Michael Clayton  », T. Gilroy 2007) on remarque deux choses : l’agaçante bande de couleur évoquée plus haut (deux pixels mauves à gauches, et une sorte de frange verte intermittente d'un pixel tout autour) et les sous-titres… attend, quoi ?

Sous-titres (anti-bug, GStreamer)

Oui. GStreamer, sans que j'ai fait quoi que ce soit pour ça, m'extrait avec force diligence les sous-titres du container du film en question (Matroska, en l'occurence, qui est réputé pour ça entre autres) et me les affiche, synchronisés, en Times, c'est trop chou, mais, heu, comment je contrôle ça ? Une fonction (et pas n'importe quoi, la gestion des sous-titres je voulais même pas seulement y penser) qui tombe en marche par accident, c'est un bug aussi, non ? GStreamer 0.10 ne faisait pas ça ; on va pas se plaindre trop fort non plus, allez.

États (non-bug, Python)

Mon usage de Fwomaj est le suivant : Je double-clique sur un fichier vidéo, je le regarde ou je l'édite, bref je fais ce que j'ai à faire avec, et je le ferme. Et ça, ça marche très bien. Mais d'autres peuvent vouloir l'utiliser différemment. C'est dans cet esprit que j'ai codé un « Open File » dont je me sers jamais, par exemple ; quand on a fini d'encoder une vidéo, l'état de Fwomaj n'est pas vraiment net-net. Si ça se trouve, ça marche très bien, mais je n'ai pas testé cet usage (ouvrir un fichier, et l'encoder plein de fois avec plein de paramètres différents, puis en ouvrir un autre, dans la même instance, tiens, rien que le fait d'écraser le fichier — c'est ce qu'on fait maintenant : mêmes paramètres, même début, même fin = même nom de fichier, on écrase — c'est bien gentil, ça marche, mais si j'étais responsable Debian (par exemple) je ne laisserais clairement pas passer Fwomaj dans les dépôts officiels, à cause de ce genre de détail.

Ça vient de ma façon de coder, procédurale sinon déclarative (on dit aussi « travail de goret » par chez moi) et c'est vrai que je voulais juste un lecteur pour visionner, couper mes rushes et en harmoniser les caractéristiques pour pouvoir les monter sans devenir encore plus dingue (intermède : si tu achètes un SONY Alpha Nex5 au Japon ou aux USA, il fait des vidéos en 30 et 60 images/secondes. Si tu as la mauvaise idée de l'acheter en Europe, c'est une autre machine, modifiée en dur pour produire des vidéos en 25/50 images/secondes, et je ne ferai pas d'autre commentaire là-dessus, c'est mieux pour la tenue de cette dépêche) et que ce lecteur, je l'ai, super.

Maintenant, si j'avais un vœu pour ce petit bout de logiciel au-delà de ce qu'il m'apporte maintenant, c'est qu'un de ces gourous qui traînent par ici (nan mais vous pouvez filer en douce, trop tard hein, on lit vos commentaires, vous croyez quoi ?) se penche sur son berceau pour en ré-usiner (tiens, ça claque encore mieux en français dis-donc) le code en profondeur, oui. Fwomaj 0.3, en l'état, est un prototype. Qui marche pas mal, mais un prototype quand même. Il me semble que c'était ça l'idée de Python, non, de bricoler vite fait des trucs qui marchottent pas mal ? Bon, ben c'est réussi, merci les gars :)

Installation

En pratique, je n'ai testé Fwomaj 0.3 que sous Ubuntu 14.04 et 16.04, avec les environnements de bureau Unity et XFCE.

Debian wget https://bitbucket.org/philipyassin/fwomaj/downloads/fwomaj_0.3_all.deb && sudo gdebi fwomaj_0.3_all.deb

Oui, je n'ai pas trouvé comment installer les dépendances d'un paquet (duh) avec dpgk..?

Ou on peut aussi construire soi-même le paquet. Ne pas se laisser abuser par le répertoire ./debian, Fwomaj est juste un script Python de 800 lignes et une icône.

git clone https://philipyassin@bitbucket.org/philipyassin/fwomaj.git cd fwomaj ./build_package.sh sudo gdebi -i ../fwomaj_0.3_all.deb Et les autres systèmes?

Pour les autres Linux, ça doit être assez trivial. À minima, le script peut être lancé tel quel sur une machine où sont installées les quatre dépendances, il n'aura juste pas d'icône. Les outils qui servent à créer des paquets pour d'autres distributions n'auront probablement aucun mal à se débrouiller avec les éléments présents :

  • exécutable ;
  • page de man (minimale, exigée par Lintian) ;
  • icônes ;
  • journal (changelog) ;
  • et éventuellement les fichiers de contrôle/description, tout ça n'est guère spécifique.

Pour les autre systèmes, honnêtement, je ne sais pas. Bien sûr, on doit pouvoir faire tourner Gtk3 sous Windows, FFmpeg aussi mais GStreamer, je suis moins sûr.

En tout cas, les spécificités du système d'exploitation sont abstraites autant que faire se peut :

unique_file = os.path.join(tempfile.gettempdir(), 'fwomaj-{}.png'.format(time.time()))

Devrait marcher partout, en principe.

Il parait qu'il y a Python sous AmigaOS, maintenant :|

J'utilise Fwomaj depuis une petite quinzaine comme lecteur principal, j'ai préparé une demi-douzaine d'épisodes avec, et encodé un grand nombre de fichiers d'origines diverses, ça marche bien.

Allez-y, testez ;)

Télécharger ce contenu au format Epub

Lire les commentaires

Nouvelle version de développement de GIMP: 2.9.4

14 juillet, 2016 - 14:31

Une nouvelle version de développement de GIMP vient de sortir : la version 2.9.4.

Pour une belle annonce en français, on attendra la sortie d'une version stable (la dépêche pour GIMP 2.10 est en préparation dans l'espace de rédaction, n'hésitez pas à participer).

Mais regardez en deuxième partie, quand même, en guise d'aguiche, quelques copies d'écran des fonctionnalités les plus visuelles.

Sommaire Les nouveaux thèmes et icones

La prévisualisation des effets

Pour ceux qui se souviennent, les "effets" sont remplacés dans GIMP 2.9/10 par des opérations GEGL, le nouveau moteur de GIMP où tout traitement d'image est un graphe.

L'un des premiers effets visibles est la prévisualisation sur le canevas en direct, permettant de tester les paramètres avant de valider, et depuis 2.9.4, la prévisualisation peut être découpée comme un "rideau", soit horizontal, soit vertical, pour voir une partie de son image avec, et sans l'effet. Voici en capture d'écran ce que ça fait (l'image dedans est d'Aryeom Han, la réalisatrice de ZeMarmot).

Peinture symétrique

Vous vous en souvenez peut-être, j'avais aussi travaillé sur la peinture symétrique, ce qui est maintenant disponible dans GIMP, en 3 modes: miroir (symétrie axiale et centrale), tuile (symétrie de translation) et mandala (symétrie de rotation). Voici un petit gribouillis fait en moins d'une minute par Aryeom Han, encore, pour montrer ce qu'on peut faire avec :

Notamment cela rend le dessin de tuiles continues bien plus simple, puisqu'il y a rendu immédiat de l'effet. Cela ne remplace pas totalement les méthodes classiques, quand on part d'une image existante par exemple, mais peut être très utile quand on souhaite dessiner ses tuiles à partir de rien, ou pour créer des motifs à répétition sympathiques. :-)

Autres

Sinon y a quelques fonctionnalités sympas, notamment pour la sélection (le remplissage de trous est vraiment sympa, je suis sûr qu'on a tous eu ces sélections « magiques » qui ont plein de trous), ou le traitement par batch d'images en ligne de commande, mais aussi et surtout un support très avancé de la gestion des couleurs au cœur de GIMP (cela existait déjà, mais sous forme de module et avec énormément moins de fonctionnalités).

Il y a aussi une meilleure prise en charge des méthodes d'entrée de texte (pour écrire en langages non-occidentaux, en général avec Ibus sous GNU/Linux par exemple) dans l'outil texte, qui laissait vraiment à désirer.

Voilà. Je vous laisse jeter un œil aux liens pour les détails et pour avoir une liste plus exhaustives des changements car je passe exprès sur le détail. Cette dépêche n'est pas une note de version. :-)

Par contre, je sais, c'est pénible: nous n'avons pas de binaires pour Linux. Vous devrez soit espérer que votre distribution fasse un paquet (mais c'est une version de développement alors les chances sont maigres), soit trouver une méthode alternative (y a un PPA pour Ubuntu, mais on ne le gère pas!), soit compiler. Windows et OSX auront des installeurs, probablement d'ici quelques jours.

C'est la vie. Je suis le premier à en être triste et j'aimerais bien un Flatpak (anciennement xdg-app) pour nos versions de sorties (et pas seulement nos nightly).

Pour ceux qui veulent compiler, le code est dispo en téléchargement.

Est-ce utilisable en « production » ?

Alors c'est une version étiquetée « instable » donc je ne vous dirai jamais de remplacer et que tout ira parfaitement. Cela reste à vos risques et périls et si vous perdez des images ou des heures de travail, ou que sais-je encore, ce n'est pas de ma faute ! :P

Mais soyons clair, pour le film ZeMarmot, depuis bien un an, nous n'utilisons que la version de développement. Je parle d'utilisation intensive, plusieurs heures par jour, tous les jours de l'année. Donc pour moi, oui c'est stable, et il n'y a aucune chance de me voir retourner sous GIMP 2.8. GIMP 2.9 est tellement 1000 fois plus confortable d'utilisation. Et je fais une de mes priorités d'exterminer les crashs. Par contre même si je corrige des bugs Windows de temps en temps, la stabilité est moins garantie sous Windows. On recherche toujours des développeurs Windows, car c'est vraiment la pénurie (chez nous, ils sont — laissez moi compter — 0?). C'est pas énormément mieux pour OSX d'ailleurs.

Pour ceux qui se rappellent mon outil de cross-compilation Crossroad, j'ai d'ailleurs récemment fait un petit article pour cross-compiler GIMP pour Windows avec crossroad. Si des gens sont intéressés, nous accueillons à bras grands ouverts les développeurs Windows (mais bon, on est sur LinuxFr.org, donc les chances sont minces).

ZeMarmot comme projet contributeur

Et pour finir, un peu d'auto-promotion de projet ! Vous le savez, je « travaille » sur le projet ZeMarmot, un film d'animation fait avec GIMP, et sous licence Creative Commons by-sa.

Toutes mes contributions à GIMP (192 commits depuis la sortie de 2.9.2 soit en environ 6 mois, c'est à dire un peu plus de 14% des commits de l'intervalle) viennent plus ou moins directement de ma participation au projet ZeMarmot (même si des fois, je corrige juste un bug « comme ça », cela vient de notre utilisation quotidienne de cet outil). Parmi les nouvelles fonctionnalités, je suis le développeur de la peinture en symétrie, gros contributeur sur l'intégration des brosses MyPaint, le développeur de la bonne prise en charge des méthodes d'entrées dans l'outil texte (Aryeom est coréenne, alors forcément, pouvoir écrire en coréen dans l'outil texte était important), celui qui a fait revivre le greffon de courriel, mais aussi l'instigateur du renouveau des thèmes/icônes, donc en charge de gérer les contributions de nouveaux thèmes et d'icônes. Mais encore relecteur de nombreux patchs, mainteneur de certains morceaux de code, etc…

Pourquoi je dis ça ? Parce que nous avons des difficultés à financer notre projet de film, qui, bien qu'associatif, souhaite rémunérer tous les contributeurs dans une optique d'un art libre professionnel (de même que pour le logiciel libre). Nous avons réussi un premier financement, vous vous en souvenez sûrement, mais les sommes récoltés ne vont pas très loin et nous cherchons des financements complémentaires.

Donc si vous aimez ce que je fais pour GIMP, ou si vous aimez GIMP même, et appréciez qu'il évolue plus vite, ou simplement si vous aimez le projet ZeMarmot, alors ce serait vraiment cool de contribuer à notre financement mensuel. Nous sommes pour cela sur la plateforme Tipeee, où vous pouvez vous inscrire même pour donner quelques euros par mois.

Si certains préfèrent payer en dollar US, nous sommes aussi sur la plateforme Patreon.

Si vous souscrivez à ZeMarmot pour quelques euros ou dollars par mois, non seulement ça nous ferait plaisir d'avoir plus de soutiens, mais en plus cela renforce notre position vis-à-vis de plus gros financeurs (fondations, organismes de financement…), et finalement vous financez du logiciel ET de l'art libre ! :-)

Dans tous les cas, j'espère que vous apprécierez cette nouvelle version de développement de GIMP pour laquelle nous avons mis beaucoup de cœur à l'ouvrage. Et désolé pour la page pub ! ;-)

Télécharger ce contenu au format Epub

Lire les commentaires

Sortie de IPython 5.0

14 juillet, 2016 - 12:48

IPython est un terminal interactif pour Python qui améliore l'expérience utilisateur lors de l'usage en ligne de commande. Entre les versions 0.12 et 3.x incluses, IPython contenait aussi un grand nombre de fonctionnalités liées au "Notebook" qui fait maintenant partie du "Project Jupyter" – voir dépêche précédente. Cette nouvelle version 5.0 est donc en partie un retour aux sources qui se concentre sur l'interface en ligne de commande de IPython.

Ce qui suit est une adaptation approximative de l’annonce faite sur le blog de Jupyter.

Grand merci à palm123, Storm, M5oul et en particulier à Lucas qui a fait plus de la moitié de la traduction pendant que je suis à SciPy 2016 à Austin, Texas.

Sommaire Sortie de IPython 5.0-LTS

Nous sommes heureux d'announcer la sortie de IPython 5.0 LTS (support à long terme). IPython est le noyau Python pour Jupyter, et le terminal interactif pour Python ; il apporte un grand nombre de fonctionnalités simplifiant le calcul interactif dans un terminal Python, dans le Notebook Jupyter, ainsi que d’autre clients.

Cette version apporte quelques nouvelles fonctionnalités excitantes et de nouveaux développements (227 commits par 27 contributeurs sur 191 Pull Requests). Les améliorations ont principalement porté sur la console en ligne de commande.

Comme d’habitude, vous pouvez mettre à jour IPython avec :

$ pip install ipython --upgrade

La mise à jour devrait être disponible au travers de conda et autres gestionnaires de paquets dans les prochain jours.

Note : IPython et les multiples composants de Jupyter sont maintenus par le même groupe de développeurs, mais avec des calendriers de publication indépendants. Cette mise à jour concerne uniquement IPython en ligne de commande et le noyau Python. La majorité des changements n’affecte que les utilisateurs de la ligne de commande.

Une nouvelle interface en ligne de commande

Séparer IPython du notebook Jupyter a permis à l’équipe de développement de se re-concentrer sur l’interface en ligne de commande. La dépendance envers pyreadline pour Windows et gnureadline pour Mac a poussé Thomas Kluyver à remplacer cette vieille implémentation par une nouvelle implémentation uniquement codée en Python : prompt_toolkit.

Le package prompt_toolkit est une bibliothèque géniale de Jonathan Slenders qui est depuis peu en version 1.0. Allant au-delà de readline, prompt_toolkit fournit de nombreuses fonctionnalités nouvelles pour l’édition de texte dans le terminal, ce qui améliore nettement l’expérience utilisateur. Comme cette bibliothèque est multi-plateforme, tous nos utilisateurs, qu’ils soient sous Linux/Unix, macOS ou Windows, vont profiter de ces améliorations. Grâce à prompt_toolkit, IPython gère maintenant :

  • la coloration syntaxique lors de la frappe ;
  • une véritable édition multi-ligne (flèche en haut et en bas pour se déplacer entre les lignes) ;
  • le collage multi-ligne sans perdre l’indentation et sans exécuter immédiatement le code ;
  • une meilleur interface de complétion (nous prévoyons d'améliorer encore ce point) ;
  • la souris de manière optionnelle.

Nous n’utilisons pas encore toutes les fonctionnalités du prompt_toolkit, mais après quelques semaines d’utilisation, cela choque d’utiliser de vieilles versions de IPython sans ces améliorations. Nous espérons que vous les apprécierez aussi. Nous remercions Jonathan Slenders, qui a été très réceptif à nos questions et demandes de nouvelles fonctionnalités !

Vous pouvez consulter une liste des changements plus détaillée : "Quoi de neuf dans IPython 5.0 (EN)".

Console Jupyter

La console Jupyter fournit l’expérience interactive côté client de IPython dans le terminal, mais offre aussi la possibilité de se connecter à tout noyau Jupyter de plus de IPython. Ceci vous permet de tester n’importe que noyau Jupyter installé dans le terminal, sans avoir besoin de lancer un notebook complet juste pour cela. La console Jupyter propose aussi la quasi-totalité des fonctionnalités décrites ci-dessus et utilise prompt_toolkit.

La version 5.0 de la console Jupyter est sortie, apportant la compatibilité avec IPython 5. Si vous utilisez la console Jupyter, vous devrez la mettre à jour elle aussi.

$ pip install jupyter_console --upgrade Long Term Support (LTS)

Habituellement, seul le support de la version majeure en cours de IPython est assuré. Dès qu’une nouvelle version majeure sort, les versions majeures précédentes cessent de recevoir des corrections de bugs. Pour cette série de versions 5.x, nous faisons une exception à cette règle : l’équipe fera de son mieux pour fournir des corrections pour les bugs critiques des versions de la série 5.x jusque fin 2017. Au-delà de cette date, nous baisserons la priorité de ce travail de maintenance, mais nous continuerons à accepter les pull requests de la communauté visant à corriger des problèmes durant 2018 et 2019, et nous publierons des versions quand cela sera nécessaire.

Nous espérons que cette politique aidera les utilisateurs qui ont besoin d’un support sur le long terme avec IPython 5.x.

Fin de la prise en charge de Python 2

IPthon est compatible avec Python 3 depuis déjà plusieurs années, depuis que Thomas Kluyver a porté le code en utilisant 2to3 en 2011, et nous avons une seule base de code pour Python 2 et 3 depuis 2013. Le développement quotidien de IPython est réalisé désormais uniquement pour Python 3 et nous commençons à casser la compatibilité avec Python 2 jusqu’à ce que nous testions ou que des utilisateurs nous le remontent. Nous sommes aussi plutôt enthousiastes à l’idée d’utiliser les fonctionnalités de Python 3, comme les annotations de type, yield from, asyncio, async def, await et d’autres améliorations que le langage et sa bibliothèque standard ont gagné ces dernières années.

Nous avons ainsi décidé que IPython 5.x sera la dernière version majeure à prendre en charge Python 2.

Cette décision est bien évidemment la raison pour laquelle nous avons décidé de fournir un support plus long que la normale pour IPython 5.x. Nous sommes conscients du fait que de nombreuses personnes utilisent encore Python 2, et ils pourront continuer ainsi durant plusieurs années en disposant d'une version maintenue de IPython, avant de passer à Python 3 à leur convenance. Après fin 2017 nous souhaitons fournir des version mineures de correctifs pour IPython 5.x via des patches fournis par la communauté. Un point important à noter est que nous n’ajouterons plus de nouvelles fonctionnalités à une version prenant en charge Python 2 après la version 5.0 à venir.

Ainsi la prochaine version majeure de IPython, IPython 6.x, nécessitera Python 3. Cette version commencera à utiliser la nouvelle syntaxe et perdra la couche de compatibilité mise en place.

Si vous êtes un utilisateur de Python 2, soyez rassuré, nous ferons en sorte que la mise à jour n’installe pas IPython 6.x de manière inopinée en cassant votre système. Vous pouvez décider de garder plus longtemps IPython 5.x LTS et de sauter plusieurs versions de IPython le jour où vous passerez à Python 3. Cependant nous recommandons de garder à jour les versions stables quand elles sortent, et bien sûr de passer à Python3 quand c’est possible.

IPython est le premier projet IPython/Jupyter à laisser tomber la prise en charge de Python 2, mais vous pouvez vous attendre à ce que d’autres composants IPython/Jupyter suivent. Depuis sa conception, JupyterHub par exemple a été compatible Python 3 seulement.

Il est important de noter que les utilisateurs pourront toujours utiliser un noyau Python 2 avec le Notebook Jupyter, même lorsque tous nos projets auront franchi le pas vers Python 3. Dans le cadre de nos engagements de support à long terme, nous réaliserons les mises à jour nécessaires au noyau IPython afin qu’il puisse continuer à fonctionner dans un Notebook Jupyter durant la période de support LTS.

Aidez nous à passer à Python 3

Nous sommes conscients que passer à Python 3 peut être difficile pour de nombreuses raisons, et que planifier cette transition est souvent nécessaire. C’est pour cette raison que nous aidons à construire une liste non exhaustive de projets ayant décidé de supprimer la prise en charge de Python 2 d’ici à 2020, lors de la fin du support de Python 2.7 lui même. Des projets tels que Matplotlib et SymPy ont déjà décidé de laisser tomber Python 2 dans les années à venir, tandis que d’autre projets comme Scikit-Bio ont pris de l’avance sur nous et devraient devenir compatibles Python 3 seulement prochainement.

Ainsi, nous avons décidé de signer la Déclaration Python3 qui propose une liste des projets qui font ce pas, ainsi que le calendrier des sorties qui seront encore compatibles Python 2 lorsque cela est possible, et quelles versions seront compatibles Python 3 seulement.

Si vous souhaitez ajouter votre projet à cette page, ou si vous connaissez un projet qui songe à la transition vers Python 3, merci de prendre contact sur ce site. Nous croyons que donner le maximum d’informations le plus tôt possible aux utilisateurs de Python facilitera la transition.

Télécharger ce contenu au format Epub

Lire les commentaires

HandyLinux rejoint Debian-Facile pour mieux aider les novices

13 juillet, 2016 - 11:38

Debian-Facile est une plate-forme d'entraide pour l'utilisation de Debian, et HandyLinux migre vers ce support.
L'histoire de HandyLinux, une distribution GNU/Linux pédagogique pouvant être définie par — Debian sans se prendre la tête —, a commencé sur le forum de Crunchbanglinux-fr le 18 juillet 2013 et continue sur le forum de Debian-Facile.

Ce regroupement va simplifier la tâche de tous : développeurs, utilisateurs, administrateurs, modérateurs. La composition d'un manuel du grand débutant qui débute a commencé. Le concept d'une version pré-configurée, libre et légère de Debian pour les novices est repris par l'équipe HandyLinux associée à l'équipe Debian-Facile pour en faire un outil d'apprentissage. Pendant la période de transition, HandyLinux restera stable et maintenue jusqu'en mai 2018.

Sommaire Une nouvelle maison


Merci Péhä :)

Le support de Debian-Facile c'est : La contribution de HandyLinux c'est :
  • une distribution Debian simple à installer comme support d'apprentissage ;
  • une documentation complète pédagogique ;
  • une communauté de contributeurs motivés.
Les enjeux

Cette fusion intervient à un moment particulier de l'histoire des deux communautés :

D'un côté, HandyLinux a atteint une stabilité reconnue mais se trouve "bloquée" sur son espace "handylinux.org" et, alors que sa priorité est de faire passer les utilisateurs à Debian sans se prendre la tête, HandyLinux devient un fork de plus, un nom de plus sur distrowatch. HandyLinux n'a jamais été créée dans ce but et l'équipe s'est rendue compte que la distribution allait tout simplement stagner là.

Dans le même temps, l'équipe Debian-Facile avait mis en place une dérivée Debian sous format ISO (une distribution ;) ) qui n'arrivait pas à se trouver de nouveaux contributeurs pour être finalisée.
L'idée d'une probable coopération entre les deux communautés a reçu un accueil enthousiaste et l'équipe Debian-Facile a tout fait pour favoriser ce rapprochement ; les complémentarités sont apparues comme des évidences :

  • La communauté HandyLinux projetait depuis quelques temps de monter une association, Debian-Facile est soutenue par une association ;
  • La communauté Debian-Facile a besoin de dev/g33ks pour contribuer au forum/outils mis en place et surtout, à la documentation. La documentation HandyLinux est terminée, les rédacteurs sont libres pour participer à la documentation de Debian-Facile ;
  • La communauté Debian-Facile avait relancé la rédaction du "manuel du grand débutant qui débute", HandyLinux vient de publier son manuel complet pour l'utilisateur.
  • Nous n'avons pas fini de découvrir toutes les possibilités offertes par cette fusion.

Désormais Debian-facile et HandyLinux mettent en commun leurs ressources, permettant même au débutant de retrouver clairement ses repères :

  • Documentation : enrichie de ce qui vient de Debian-facile ainsi que des particularités de HandyLinux ;
  • Support communautaire : plus d'utilisateurs et d'experts de distributions différentes ayant beaucoup en commun ;
  • Des moyens de communication rationalisés ;
  • Un seul site, un seul serveur.

Chaque catégorie d'utilisateurs venant de chacune des communautés est pris en compte pour optimiser l'efficacité, participer aux autres communautés similaires, mieux les connaître pour aller chercher les relais des utilisateurs avancés participant déjà eux-mêmes à plusieurs communautés d'entraide.

Le rêve de fin de soirée…

Car oui, on rigole bien sur Debian-Facile, mais l'enjeu final est de mettre en place un programme complet et francophone basé sur Debian, intégrant une distribution, une initiation à l'informatique, la documentation de base (le manuel des débutants), un forum de support et un plan d'apprentissage. Cette base de travail communautaire pourra servir de support pour tout projet francophone basé sur Debian avec plusieurs avantages :

  • éviter aux petites équipes de se taper la documentation en français pour les débutants et profiter des images ISO fournies pour réaliser des forks ajustés à leurs besoins ;
  • permettre aux associations de disposer d'une distribution officielle Debian francophone prête à l'emploi, agrémentée d'outils communautaires et pouvant également servir au reconditionnement des vieux ordinateurs (comme l'excellente Emmabuntüs mais en moins garnie) et à l'initiation à l'informatique ou aux logiciels libres ;
  • disposer enfin d'une plate-forme commune d'apprentissage pour Debian en français ;
  • inverser la tendance de la dispersion des forces dans le logiciel libre.

…. le (doux) rêve d'une fin de soirée … :)

HandyLinux maintenue jusqu'en mai 2018

La version actuelle de HandyLinux sera maintenue jusqu'en mai 2018. Ses utilisateurs peuvent trouver de l'aide dans la documentation complète intégrée et sur le forum debian-facile que les membres « actifs » de la communauté HandyLinux ont rejoint.

Le forum actuel HandyLinux sera fermé aux inscriptions pour faciliter la transition, avec une redirection proposée aux nouveaux arrivants. Il reste cependant ouvert en lecture à tous car il reste à faire passer les tutoriels, astuces et autres sujets [Résolu] sur Debian-Facile.

La version suivante sera une version simplifiée et adaptée de Debian, intégrant un outil d'apprentissage pour les novices. Ses utilisateurs seront mieux entourés et aidés par une communauté plus grande chez Debian-Facile.

Premiers pas sur le forum de Debian-Facile
  • La section du nouvel arrivant : la catégorie pour démarrer sur debian-facile vous présente les règles du forum, les outils disponibles, sans oublier les points chocolats !
  • Le petit sas de décompression pour les handylinuxiens : vous découvrez le forum debian-facile en venant d'handylinux ? Un petit mémo de bienvenue a été concocté pour vous ;)
  • La section de présentation : parce que c'est toujours sympa de faire coucou en arrivant ;)
  • L'ambiance de Debian-Facile : histoire de savoir où tu mets les pieds.
  • Les outils pratiques mis à disposition des utilisateurs Debian-Facile : un pad collaboratif, un paste sécurisé, un hébergement d'images…
  • Les administrateurs se présentent et sont facilement joignables directement depuis le forum.

DFLinux un projet initié par Debian-Facile

DFLinux a pour but d'offrir une version pré-configurée, libre et légère de Debian pour les novices. Cette distribution tourne pour l'instant avec le bureau LXDE pour assurer une légèreté maximale et pouvoir ainsi être testée sur la grande majorité des machines. L'équipe HandyLinux associée à l'équipe Debian-Facile reprend ce concept avec quelques nouveautés : DFLinux sera distribuée sous 3 versions afin de respecter les différents choix et obligations de chaque utilisateur :

  • DFLinux-light : une version Debian avec le bureau LXDE, très légère, libre et agrémentée d'un minimum d'applications pour utiliser son ordinateur. Cette version sera aussi parfaite pour tester rapidement votre matériel en session d'essai Live.
  • DFLinux-base : une version Debian avec le bureau XFCE, légère, libre et livrée avec une suite de logiciels pour les applications courantes. C'est la version de base utilisée pour le plan d'apprentissage.
  • DFLinux-full : une version Debian avec un bureau au choix, les pilotes non-libres intégrés, une suite complète d'applications. C'est la version "clone" d'HandyLinux.

Les trois versions intégreront une documentation complète, un manuel du débutant et tous les liens vers les tutoriels textes/vidéos du portail Debian-Facile. Elles seront distribuées en i386 (double noyau pour le non-PAE) et amd64 ce qui offrira, en plus des images ISO officielles Debian, une série d'ISOs francophones pré-configurées.

Le plan d'apprentissage

Ce projet initié par Starsheep, prévoit d'allier une documentation, des tutoriels et une distribution au sein d'un processus d'apprentissage progressif : au lieu de présenter la documentation classée par thèmes ou catégories, le plan d'apprentissage sera gradué en fonction du niveau de l'utilisateur. Ainsi, à son rythme, chacun pourra acquérir l'autonomie numérique en s'aidant de petits cours, tutoriels texte et vidéos et surtout, un accès direct aux travaux pratiques grâce à DFLinux comme support de base.

Les versions de DFLinux seront toutes intégrées dans ce processus qui permettra d'ouvrir une porte plus large sur Debian pour les novices et/ou utilisateurs de systèmes propriétaires.

Le but du plan d'apprentissage est de permettre à l'apprenant de le stopper à tout moment, dès que le niveau atteint le satisfait. Le système progressif du plan d'apprentissage est spécialement conçu pour pouvoir être interrompu : une série de petits modules pédagogiques simples s'enchaînent, une fois l'utilisation informatique couverte par le plan, l'apprenant peut arrêter, il sait utiliser son ordinateur pour ses tâches usuelles.

S'il est plus curieux ou désire mieux contrôler son environnement numérique, Le novice peut continuer le plan d'apprentissage, améliorer ses connaissances, et contribuer aux logiciels libres.

Conclusion

Difficile de conclure sur le début d'une aventure… mais, quoi qu'il arrive, les deux communautés sont motivées pour travailler ensemble à rendre Debian plus facile à installer… sans se prendre la tête ;) Toute aide est la bienvenue si vous êtes intéressé : la coopération inter-communauté étant le premier pas pour se connaître, puis travailler ensemble pour des populations d'utilisateurs diverses (dont certaines ayant besoin d'aide en français, par des francophones).

Télécharger ce contenu au format Epub

Lire les commentaires

OpenFL 4.0

13 juillet, 2016 - 11:03

OpenFL est une API graphique libre et gratuite, permettant de créer des jeux et des applications cross-platform. Il y a quelques jours, une nouvelle version majeure de OpenFL, la version 4, a été publiée. Cette dépêche profite de l'occasion pour faire un tour des possibilités offertes par cette API.

OpenFL est donc capable de compiler nativement pour les plateformes Linux, Windows, MacOS, iOS, Android, Raspberry PI, BlackBerryOS, Firefox OS, HTML5, Tizen, Wii U, PS3, PS Vita, PS4, et Xbox One, tout en profitant de l'accélération GPU via OpenGL, OpenGL ES, WebGL, Stage3D, et un moteur de rendu spécifique pour les consoles de jeu.

Parce qu’il a un historique important dans le développement de jeux vidéo et parce qu'il est naturellement orienté multi-plateforme, OpenFL utilise Haxe comme langage de programmation.

OpenFL Architecture

OpenFL est une API comme OpenGL l'est aussi. Elle repose essentiellement sur l'API Flash et s'oriente naturellement vers la production de contenus interactifs, d’applications, de jeux, d’interfaces 2D et d'animations.

Elle s'appuie sur la bibliothèque Lime qui se charge de toute la mécanique de compilation croisée. On va y revenir.

Moteur de jeu

C'est clairement dans le jeu vidéo que cette API se développe le plus.
Le célèbre jeu “Papers, Please”, gagnant d’un Bafta et fort de quelques 30 récompenses utilise OpenFL. Electronic Arts, le géant du jeu vidéo, a récemment substitué OpenFL à Scaleform pour produire son dernier jeu vidéo mobile, (John Madden NFL). Une grande majorité des essais au Ludum Dare exploite cette API. OpenFL a par ailleurs concentré ses efforts pour ouvrir la porte du développement sur consoles de jeu.

HaxeFlixel, construit par-dessus OpenFL, est un framework de développement de jeux vidéo 2D populaire.
Personnellement j'attends avec impatience la sortie de Defender's Quest 2 et Yummy Circus.

Stencyl va encore plus loin en offrant tout un environnement de développement en plus d'un très bon moteur de jeux.

Interfaces

Dans le domaine des IHM, on retrouve HaxeUI qui propose une solution efficace pour construire des interfaces. Il est à noter que la V2 devrait bientôt sortir.

Ian Harrigan, le principal développeur, a présenté lors du dernier WWX cette nouvelle version. En attendant la vidéo, vous pouvez retrouver ses interviews et ses supports de présentation.

Lime

Lime est la bibliothèque gratuite et open-source, qui sert de fondation à OpenFL et à d'autres projets.
Elle s'occupe de la partie multi-platforme. Elle expose les contextes Canvas, DOM, GL (WebGL, OpenGL, OpenGLES) en fonction des plateformes et unifie les I/O pour OpenFL (clavier, souris, écrans, joystick…) via SDL. Lime offre également une API audio mais expose OpenAL pour ceux qui veulent quelque chose de plus bas niveau. Elle supporte :

  • Windowing
  • Input
  • Events
  • Audio
  • Render contexts
  • Network access
  • Assets
Heaps

Heaps est un framework de développement de jeu 3D qui repose directement sur Lime.

Evoland et NorthGard sont de très bons exemples de ce que peut faire Heaps.

Pour bien commencer

Le plus simple reste d'utiliser Haxe Develop. Intellij Idea, Sublime Text, ou VsCode supportent aussi très bien les développements Haxe et OpenFL. NdM : Ou vim ou emacs ou Ed.

Ensuite le site de OpenFL propose une série de tutoriels plutôt efficaces. Celui sur le jeu pong est pas mal du tout.

Vous pouvez également lire ce très bon billet «Flash is Dead, Long Live OpenFL» de Lars Doucet sur OpenFL et tout son écosystème

En bref, OpenFL est une très belle technologie à découvrir ou redécouvrir.

Télécharger ce contenu au format Epub

Lire les commentaires

FusionDirectory 1.0.14 est sorti & Argonaut 0.9.7 suit !

12 juillet, 2016 - 21:10

L’équipe de FusionDirectory est heureuse de vous annoncer la publication de la version 1.0.14 de FusionDirectory. Pour ceux qui ne connaissent pas FusionDirectory, il s’agit d’un gestionnaire d’infrastructure. Il est à LDAP ce que Webmin pouvait être à NIS/NIS+ : une interface Web modulaire de gestion complète d’un annuaire LDAP. Sa modularité permet d’offrir aussi la gestion de services qui ne sont pas directement interopérables avec LDAP.

De plus, la même équipe de FusionDirectory est également heureuse de vous annoncer la publication de la version 0.9.7 de Argonaut. Pour ceux qui ne connaissent pas Argonaut, il s’agit d’un système client/serveur qui permet de faire du provisioning et de l'orchestration en collaboration avec FusionDirectory (gestionnaire d'annuaire LDAP). Argonaut permet aussi de s'interfacer avec des outils de déploiement tels que FAI (Fully Automated Install) ou OPSI (Open PC Server Integration).

FusionDirectory 1.0.14 Nouvelles fonctionnalités
  • Breezy est dorénavant le thème par défaut
  • Un contributeur a commencé à traduire FusionDirectory en finnois
  • Les modèles peuvent être utilisés de manière centrale ou dans des branches et être restreints avec des ACL FusionDirectory
Principales corrections
  • FusionDirectory est compatible PHP7
  • Amélioration et test complet du plugin quota
  • Amélioration et test complet du plugin autofs
  • Les objets imprimantes ont été convertis en simpleplugin
  • Les imprimantes ont été enlevées des objets poste de travail
  • Le webservice a été améliore pour le rendre plus robuste et plus logique
  • Les hooks ont été corrigés pour l’éventualité de l’exécution de code arbitraire
  • Le service de base IMAP/POP3 a été remis pour éviter des régressions dans certains cas
Corrections mineures
  • L’import CVS et LDIF a été amélioré
  • Le système de récupération de mot de passe a été corrigé afin de ne pas montrer de mauvais messages d’erreurs dans certains cas
Plugin supprimé
  • Le plugin game a été supprimé car il était obsolète
Paquets pour les distributions :

Des paquets logiciels pré-compilés sont disponibles pour Debian Wheezy et Jessie, CentOS 6 et 7, Scientific Linux 6 et 7, Suse SLES 11 SP3, Mageia Cauldron ainsi qu'ArchLinux.

Argonaut 0.9.7

La version 0.9.7 est concentrée autour de deux plugins de FusionDirectory, user-reminder et audit.

À dater de cette version, en plus de ses fonctionnalités de gestion des systèmes, des services et des outils de déploiement, Argonaut devient le framework officiel pour tous les scripts combinés à des plugins FusionDirectory.

Nouvelles fonctionnalités
  • argonaut-clean-audit est un script qui sert à nettoyer la branche d’audit gérée par le plugin audit de FusionDirectory
  • argonaut-user-reminder est un script qui gère le renouvellement automatique des comptes utilisateurs gérés par le plugin user-reminder de FusionDirectory

Argonaut est supporté sur Debian Wheezy & Jessie / Centos 7 & Rhel 7 & Scientific Linux 7

Télécharger ce contenu au format Epub

Lire les commentaires

GNU/Linux a son OCR de qualité

12 juillet, 2016 - 11:16

Un des grands reproches faits aux systèmes GNU/Linux par les utilisateurs déficients visuels était l'absence d'un logiciel de reconnaissance optique de caractères (OCR). Après avoir simplifié l'accès à GNU/Linux et avant d'y avoir implémenté des synthèses vocales de haut niveau, la société Hypra a résolu la question de l'OCR. En partenariat avec l'entreprise Abbyy, elle propose désormais un outil pour reconnaître les documents images issus du Web ou les documents numérisés et afficher leur contenu dans LibreOffice plutôt que dans un visionneur d'images.

L'outil est fourni sous forme d'un binaire. Puis chacun peut le lancer en ligne de commande. Pour ceux qui ont MATE et qui veulent du très simple, Hypra fournit un paquet Debian, installable sur tous systèmes. Il ajoute l'entrée au menu contextuel de caja, le gestionnaire de fichiers. Hypra fournit aussi, avec le paquet, la ligne à ajouter à ses raccourcis pour lancer le scanner par simple raccourci clavier (fonctionne sur tous les bureaux). Ce dispositif installé en fait la suite OCR la plus simple du monde PC puisqu'un raccourci ou une commande du menu contextuel suffit à lancer le scanner, la reconnaissance et l'affichage dans LibreOffice. Avec stockage des images.

Enfin, précisons que l'outil est bien sûr disponible dans le Système à Accès Universel.

Et le prix? Il est vendu 150€. Légèrement moins cher que Nuance OmniPage ou Abbyy FineReader (tous deux propriétaires) sous Windows dans leur version complète, il est la seule offre illimitée, sur GNU/Linux, à ce prix. Jusqu'ici Abbyy proposait simplement une version en ligne de commandes limitée à 12000 pages par an. La version illimitée coûtait 3000 €. C'est donc un bon début insufflé par cette entreprise sociale et solidaire, qui contribue à rendre le monde du libre accessible à tous en retirant les barrières à l'entrée.

NdM.: il est ici question d'une couche d'interface libre pour ajouter la gestion d'un moteur OCR propriétaire à ocrizer. Il existe par ailleurs d'autres moteurs libres d'OCR, plus ou moins avancés et/ou maintenus.

$ dpkg --info ocrizer-finereader_0.1.4-8_all.deb (...) Section: contrib/graphics (...) Description: Finereader engine support for ocrizer This package installs the glue between the abby proprietary command line tool and ocrizer, and makes finereader an available engine. Télécharger ce contenu au format Epub

Lire les commentaires